理論

ハンズオン前の前提知識整理

1. フェイルオーバーとは

2. Amazon API Gateway

概要

フェイルオーバーでの活用

• 複数リージョンにデプロイ：API Gatewayを各リージョンに展開することで、障害時の切り替えを容易にします。

• エンドポイントの種類：
• リージョン API （エンドポイント）：特定のリージョンに固定されたエンドポイント。
• エッジ最適化 API （エンドポイント）：グローバル配信に適したエンドポイント。
• プライベート API：プライベート API には VPC からのみアクセスできます。

3. AWS Lambda

概要

応用例

ライフサイクル

フェイルオーバーでの活用

• 各リージョンで同じLambda関数をデプロイし、API Gatewayから呼び出します。

• バックエンドロジックを柔軟に構築可能。

4. Amazon DynamoDB

概要

1. LSI（ローカルセカンダリインデックス）
• Partition Key は元のテーブルと同じ。
• Sort Key のみをカスタマイズ可能。
• クエリ時は必ず元の Partition Key を指定する必要がある。
• パーティション内のデータに対する補助的な検索に使用される。

2. GSI（グローバルセカンダリインデックス）
• Partition Key と Sort Key の両方を元のテーブルと独立して設定可能。
• クエリ時に独自の Partition Key で検索可能。
• テーブル全体のデータに対する広範囲な検索に適している。

• LSI は「ファイルキャビネットの中の引き出し（Partition Key）」内で「異なる仕切り（Sort Key）」を使って整理するイメージ。

• GSI は「キャビネットとは別の場所に、自由に整理された新しいキャビネット」を設置するようなもの。

グローバルテーブル

• DynamoDBのグローバルテーブルを利用すると、データを複数のリージョン間で自動的に同期できます。

• 高可用性を実現するために必要な設定。

5. Amazon Route 53

概要

重要な設定

• フェイルオーバーレコード：
• プライマリとセカンダリのエンドポイントを定義し、プライマリが障害を検出した際にセカンダリへ切り替え。

• ターゲットヘルスモニタリング：
• エンドポイントの稼働状況を監視し、障害検出をサポート。

6. 高可用性API構築の基本ステップ

1. 複数リージョンへのデプロイ
• API GatewayとLambda関数を各リージョンにデプロイする。

2. DynamoDBのグローバルテーブル化
• データの一貫性と可用性を確保するために設定。

3. Route 53でフェイルオーバー設定
• フェイルオーバーレコードを利用して、障害発生時の自動切り替えを構築。

4. 監視とテスト
• 障害時の切り替えが正常に動作するか、定期的にテストを実施。

まとめ

実践

目標

• API Gateway を使用して、サーバーレスREST APIを作成し、2つのAWSリージョンで冗長化。

• AWS Lambda を使用して、APIのバックエンドロジックを実装。

• Amazon DynamoDB のグローバルテーブルを使って、データの高可用性を確保。

• Amazon Route 53 を利用し、DNSフェイルオーバー機能を実装。

使用するAWSサービス

• AWS Lambda: サーバーレスコンピューティングサービス。バックエンドロジックをLambda関数で処理します。

• Amazon API Gateway: REST APIを作成・管理するサービス。リクエストをLambda関数に転送します。

• Amazon DynamoDB: NoSQLデータベース。データを格納し、グローバルテーブルでデータの冗長化を実現します。

• Amazon Route 53: DNSサービス。フェイルオーバー機能を使用して、異常が発生した際に他のリージョンへ切り替えます。

ステップ 1: API GatewayでのREST API作成

基本的な使い方をおさらいください

---

---

---

---

---

---

---

---

1. API Gateway操作画面でREST APIを作成
• 新規に下記のREST APIを作成する。
• バックエンドはまだ用意されていないため、モック設定を使用。

2. マッピングテンプレートを設定
• マッピングテンプレートに以下のコードを設定してモックレスポンスを返すようにする：
マッピングテンプレートとは、API Gatewayでリクエストやレスポンスのデータ形式を変換するための設定です。APIとクライアント（フロントエンド）やバックエンド間のデータのやり取りをカスタマイズするために使います。

3. APIをデプロイ
• APIをステージにデプロイする（例: devステージ）。

4. デプロイしたエンドポイントにアクセス
• ブラウザやPostmanなどのツールでAPIエンドポイントにリクエストを送信してレスポンスを確認。

ステップ 2: Lambda関数の作成

基本的な使い方をおさらいください

---

---

実際の操作手順:

1. Lambdaサービスの選択
サービス検索バーで「Lambda」と入力して選択。

2. 新しい関数の作成
• 一から作成するオプションを選択。
• 関数名（例: translater-function）を設定。
• ランタイムはPython 3.9を選択。
• IAMロールは自動生成を選択。

3. メモリやタイムアウトの設定変更
• メモリを256MBに変更。
• タイムアウトを5秒に設定。
• 保存ボタンを忘れずにクリック。

4. ログ設定の追加
• ソースコードにloggingライブラリをインポート。
• ロガーを設定し、イベント内容をログに出力。
• 保存してからテストを実行。

5. テストの実行と確認
• サンプルイベントを作成。
• 実行結果を確認し、ログにイベントの中身が正しく出力されていることを確認。

ステップ 3: DynamoDBの設定

• テーブル名: TranslaterLogs

• プライマリキー:
• パーティションキー: Timestamp（ユニークな値として指定。例: APIが呼び出された時刻）。
• Sort Keyは使用しない。

• キャパシティ設定:
• リード/ライトキャパシティを「1」に指定（オンデマンドは使用しない）。
• セカンダリインデックスは設定しない。

1. テーブル作成後、「項目の作成」ボタンをクリック。

2. データ項目: API呼び出し時の以下の情報を保存:
• 呼び出し時間
• 日本語の入力テキスト（Input Text）
• 翻訳結果の英語テキスト（Output Text）

3. 以下の情報を入力:
• Timestamp: 例: 202412051720
• input_text: 例: ★こんにちは
• output_text: 例: ★Hello

4. 「保存」をクリックするとデータが追加される。

3. 注意点

• Timestampはプライマリキーとしてユニークである必要がある。

• 環境によってテーブル作成に少し時間がかかる場合がある。

ステップ 4: API GatewayとLambdaとDynamoDB 統合

• Lambda Function の修正:
• DynamoDB へのデータ追加には、AWS SDK を利用します。
• DynamoDB テーブルを操作するために、PutItem メソッドを使用します。
• PutItem では、API 呼び出し履歴として以下の情報をテーブルに保存します:
• 入力テキスト (inputText): API 呼び出し時の入力データ
• 出力テキスト (outputText): API 呼び出し結果
• タイムスタンプ: 呼び出し時刻
以下のコードを Lambda Function に追加します：

• 修正したらdeployをしてください

• Lambda 関数に DynamoDB へのアクセス権限を付与します。DynamoDBFullAccess TranslateFullAccess ポリシーを IAM ロールに追加します。

• ALambdaとDynamoDB の統合テスト

• Lambda Function を修正後、テストイベント実行し、DynamoDB テーブルにアイテムが追加されているかを確認します。

• API Gatewayと統合
API GatewayのメソッドをMockからLambda 統合に変更する

統合テスト

拡張オプション

ステップ 5: 両リージョンでの高可用性構築

1. API Gateway、Lambda、DynamoDB の複製

• Aリージョンで設定済みのリソースを、Bリージョンにもデプロイします。
• API Gateway: 同じエンドポイント構成で作成。
• Lambda: 同じコードと設定をデプロイ。
• DynamoDB: 必要に応じてグローバルテーブルを利用し、データの同期を自動化。

2. Route 53でフェイルオーバー設定を構築

• Route 53コンソールで新しいホストゾーンを作成します（例: weather.example.com）。

• DNSレコードを設定：
• プライマリレコード: Aリージョンの API Gateway エンドポイントを設定。
• セカンダリレコード: Bリージョンの API Gateway エンドポイントを設定。

3. ヘルスチェックの有効化

• ヘルスチェックを設定して、各 API Gateway エンドポイントの稼働状況を監視。
• プライマリリージョンのエンドポイントがダウンした場合、自動的にセカンダリリージョンのエンドポイントにリクエストを切り替えます。

ステップ 5: テスト

1. Postmanやcurlを使って、weather.example.com にリクエストを送信します。
• リージョン 1が正常な場合、そのエンドポイントから応答が返ります。

2. リージョン 1を意図的に停止し、Route 53がフェイルオーバーして、リージョン 2から応答が返ることを確認します。

ハンズオンの成果

• 高可用性を持つサーバーレスREST APIの構築。

• リージョン間のフェイルオーバー機能を実装。

• DynamoDBグローバルテーブルによるデータの冗長化。

一門道場

選択肢

A.

• 新しいリージョンにLambda関数をデプロイ。

• API Gatewayをエッジ最適化エンドポイントに更新し、両リージョンのLambda関数をターゲットとして設定。

• DynamoDBをグローバルテーブル化。

B.

• 新しいリージョンにAPI GatewayとLambda関数をデプロイ。

• Route 53のDNSレコードをマルチバリューアンサーに変更し、両API Gatewayをアンサーに追加。マルチバリューアンサー (Multi-Value Answer) とは、AWS Route 53 のルーティングポリシーの一つで、DNS クエリに対して複数の値 (IP アドレスやエンドポイント) を返す仕組みを指します。

• ターゲットヘルスモニタリングを有効化。

• DynamoDBをグローバルテーブル化。

C.

• 新しいリージョンにAPI GatewayとLambda関数をデプロイ。

• Route 53のDNSレコードをフェイルオーバーレコードに変更。

• ターゲットヘルスモニタリングを有効化。

• DynamoDBをグローバルテーブル化。

D.

• 新しいリージョンにAPI Gatewayをデプロイ。

• Lambda関数をグローバル関数に変更。

• Route 53のDNSレコードをマルチバリューアンサーに変更し、両API Gatewayをアンサーに追加。

• ターゲットヘルスモニタリングを有効化。

• DynamoDBをグローバルテーブル化。

解説：正解はC

1. 新しいリージョンにAPI GatewayとLambda関数をデプロイ

• API GatewayとLambda関数を新しいリージョンに複製して冗長構成を確立。

• 高可用性を実現する基盤を構築。

2. Route 53のDNSレコードをフェイルオーバーレコードに変更

• フェイルオーバーレコードを利用することで、プライマリリージョンに障害が発生した場合、自動的にセカンダリリージョンへトラフィックを切り替え可能。

3. ターゲットヘルスモニタリングを有効化

• Route 53がプライマリリージョンのAPI Gatewayの状態を監視。

• 障害検知時に迅速な切り替えを実現。

4. DynamoDBをグローバルテーブル化

• 複数リージョンでのデータ同期を自動化し、一貫性を確保。

• プライマリリージョンで書き込まれたデータがセカンダリリージョンでも即座に反映。

他の選択肢が不適切な理由

A. エッジ最適化エンドポイントを利用

• 問題点：フェイルオーバーを保証する仕組みがない。

B. マルチバリューアンサーを使用

• 問題点：フェイルオーバーではなく負荷分散向け。障害発生時に特定のリージョンを無効化できない。

D. Lambda関数をグローバル関数に変更

• 問題点：Lambdaに「グローバル関数」という設定は存在しない。

結論

• フェイルオーバー構成をAWSベストプラクティスに基づいて実現。

• 高可用性、データ一貫性、自動切り替えを確保でき、要件を満たします。