このブログは 2023 年 11 月 27 日に Doug Buser 氏によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 AWS re:Invent にて、Riot Games のグローバルインフラストラクチャとオペレーションの責任者である Brent Rich 氏が、同社が 2024 年初頭で完了予定の数年にわたるグローバル規模なデータセンター廃止の取り組みの最終段階にあることを発表しました。Riot Games は『リーグ・オブ・レジェンド』・『VALORANT』・『リーグ・オブ・レジェンド：ワイルドリフト』・『チームファイト タクティクス（TFT）』や『レジェンド・オブ・ルーンテラ』などのゲームタイトルを運営しており、この取り組みにより、Riot はこれまでにないほどプレイヤーの近くにサーバを配置できるようになりました。 2017 年、Riot Games は自社のデータセンターを廃止しアマゾン ウェブ サービス（AWS）クラウドに完全に移行する意思決定をしました。その後、14 のデータセンターが閉鎖され、先月にもラスベガスとチリのデータセンターが閉鎖されています。Riot は向こう数ヶ月内にブラジルとトルコの残りのデータセンターも閉鎖する予定です。 AWS は Riot の公式のクラウドサービスプロバイダーであると同時に、公式のクラウド人工知能（Artificial Intelligence、AI）・クラウド機械学習（Machine Learning、ML）・クラウド深層学習（Deep Learning、DL）プロバイダーでもあります。 Riot が会社として成長し続け、テレビ番組や音楽・eスポーツ放送などのプレイヤーを楽しませるための新しい道を模索している中、Rich 氏はチームにクラウドファーストのマインドセットを持つよう促しています。「壁にぶつかった時、昔は『自分たちで頑張ろう』と考えるのが普通だったが、今ではまず『AWS に相談してみよう』とみんな思うようになりました」 Riot と AWS のコラボレーションの歴史を振り返り、クラウドの導入にあたって Riot が取った段階的なアプローチがいかにして社内で最もクラウドに対して懐疑的な人たちさえも味方につけられたかについて見ていきましょう。 物語のはじまり 「2015 年の Riot は破竹の勢いでした」と Rich 氏は振り返りました。「『リーグ・オブ・レジェンド（LoL）』が大ヒットし、当時の Riot はパフォーマンスとプレイヤー体験を最優先事項としていました」 2015 年から 2018 年にかけて、Riot は隔週で『LoL』のアップデートをリリースし、プレイヤーを熱中させるゲームであり続けるよう注力しました。この時 Riot のデータセンターで使われているテクノロジーは 10 年ほど昔の古いものでした。ライフサイクルアップグレードや古めのソフトウェアサービスの AWS 上での仮想化は行なったものの、Riot は依然としてオンプレミスのインフラストラクチャに依存していました。 2019 年が差し迫るころ、Riot ではスタンドアローンのモバイルゲーム『チームファイト タクティクス（TFT）』のローンチと 2020 年の次の大型タイトル『VALORANT』のリリースが控えていました。『VALORANT』では世界中のプレイヤーに遊んでもらうため、当初の計画では世界各地の 40 拠点でデータセンターを構える予定でした。レイテンシの低いソリューションの採用は『VALORANT』の成功の絶対条件でした。『VALORANT』では開発の初期段階から、ピーカーズアドバンテージの排除をプレイヤーにとっての中核となる価値の一つとして位置づけていました。（ピーカーズアドバンテージとは、プレイヤー間のレイテンシのばらつきによりサーバがプレイヤーの入力を受け付けるタイムラグにずれが生じ、一部のプレイヤーがわずかに有利になる現象です。） Rich 氏は「当時、パフォーマンスを出したいならベアメタルだという考え方が主流でした。一方、データセンターを所有・運用するのは途方もなく複雑なことで、自動化しようと思うのならなおのことです。我々はクラウドでもベアメタルと同等なパフォーマンスを引き出す方法を探っていました」と語りました。 Riot Games の『リーグ・オブ・レジェンド』シニアプリンシパルソフトウェアエンジニア兼テックリードの David Press 氏はこのように述べました。「これまで以上にキャパシティの柔軟な増減が必要でした。オンプレミスだと数ヶ月のプランニングが必要で、そうするとプロジェクトはウォーターフォール志向にならざるをえませんでした。我々はもっとアジャイルでいきたいと考えました」 Riot は運用の簡素化・効率向上によるイテレーションの高速化と負荷試験の自動化を目標とし、クラウドをオンプレミスのデータセンターの拡張として利用することを検討しはじめました。目標達成のため、Rich 氏と彼のチームは AWS との協力に踏み出し、プランの策定・実行に移りました。 「当時も今も AWS はクラウド業界のトッププレイヤーです。当時、我々はすでに数年間 AWS と仕事してきて、彼らの Customer Obsession（カスタマーオブセッション）を実感してきました。だからこそ、彼らは我々にとって素晴らしい戦略的パートナーになると確信していました」と Rich 氏は語りました。 『VALORANT』の攻めのレイテンシ要件を前に、Riot は Amazon Elastic Kubernetes（ Amazon EKS ）のサービスチームと連携し Riot と Riot ゲームのプレイヤーが求めるような機能やサポート、そして体験を提供するためのロードマップを策定しました。 段階的なアプローチ 2019 年 6 月、Riot は『TFT』を皮切りにゲーム開発のアプローチをクラウドに移し始めました。Rich 氏曰く『TFT』は「AWS 生まれのゲームだった」とのことです。一方『VALORANT』は大きな試練でした。Riot チームは『VALORANT』のローンチに向けて 18 か所でのグローバル展開に決定しました。そのうち 14 か所は AWS、4 か所は Riot のデータセンターを活用することになりました。2020 年初頭、『VALORANT』のクローズドベータが開始し、期間中の 4 月から 5 月にかけては 1 日あたり約 300 万人のプレイヤーがゲームをプレイしました。これは正式リリースとほぼ同等の規模感でした。 「3 月から全面的にクラウドを活用し、クラウドの超大規模スケーリングを頼るようになりました」と Rich 氏は語りました。 『VALORANT』はクラウドベースで正式のパブリックローンチを果たし、瞬く間に Riot の新たな数十億規模のフランチャイズとなりました。その後も Riot はいくつかの規模の小さめのゲームをクラウドでローンチしました。これらのローンチの成功を経て、Riot は残りのサーバも AWS に移行すると舵を切りました。 社内合意を得る Rich 氏は時間をかけてコンセプトを徐々に実証していくアプローチを取ったことが、当初懐疑的な CXO クラスの役員たちの信頼を得るための鍵となったと説明しました。「クラウドで新しいものをきちんと動かせることを証明しなければなりませんでした。一番のポイントはユーザーデータグラムプロトコル（UDP）のレイテンシとパケットロスが許容範囲内に収まることを証明することでした。パケットロスは一旦発生すると回復不可能で、ゲームプレイ中にパケットロスが発生すると自キャラがテレポートしているかのように見えてしまいます」 Rich 氏はプロジェクトを始めると、最初にチームメンバーにクラウド採用に関する懸念事項を全て挙げてもらい、集まったものを一つ一つ検証していきました。「彼らの懸念はいずれも正当なものでした。我々はこれらについて調査し、全て対処できるものだと証明しました」と Rich 氏が語りました。「『TFT』はクラウドから直接ゲーム体験を提供しています。これによりクラウドの処理能力に問題はないと証明でき、クラウドはデータセンターと同等の品質だったということです」 Riot の CTO・Derek DeFields 氏は Rich 氏の段階的なアプローチを支持し、新しいデータセンターをこれからも作るべきだと主張する人たちにも働きかけました。「全員が全員納得してくれたわけではなく、中には予備として設備を買っておきたい人もいました。『TFT』や『VALORANT』を AWS 上に載せる際オールインするとは一度も口にしませんでしたが、AWS との良好な関係と彼らからの協力は我々に大きな影響を与えました」 Press 氏によると「オンプレミスで運用していたころは、ハードウェア障害が起きるたびに 90 分間のサービス停止が発生していました。AWS に移行し RDS を使うようになってからは、ハードウェア障害がなくなったわけではないのですが、サービスの停止時間はわずか 30 秒となりました」 Rich 氏は、レガシーゲームの AWS 移行を担当するリードエンジニアリングチームが Rich 氏のチームからプロジェクトを引き継ぎたいと申し出た時、プロジェクトの成功を確信したと述べました。「彼らがプロジェクトを引き受けられるように、我々は 2 年間努力を重ねてきました。これをもって移行プロジェクトの最後のチェック項目もクリアできました」 新しいマインドセット クラウド移行によってどんな新しい道が開かれたかと質問された時、Rich 氏は発想を逆転しこう述べました。「むしろ何が閉ざされるのかが重要です。一つの物語が幕を閉じました。データセンターで生まれたものはほとんど消え去り、クラウドが我々の目標達成に有効であることが実証された今、昔ながらのデータセンターマインドセットも変わりました」 Riot は自社の多くのプロジェクトを支援するために、Amazon EKS サービスチームと定期的に機能プランニングセッションを行いツールや新機能の開発を続けています。「戦略的パートナーなしでは非常に難しいこともあります。我々と AWS と我々のインテグレーションパートナーである Slalom 社との連携を例にあげると、我々は三社で一つの『LoL』の綿密な自動化ランブックを共有しています。新しいリージョンで何かを立ち上げる際数週間もあれば事足ります。こうしたパートナーシップは非常に貴重なものだと言えます」 翻訳はソリューションアーキテクトのBaixiao Linが担当しました。

はじめに コンタクトセンターの管理者は、エージェントと顧客のやりとりの改善に向け、エージェントのコーチングの必要性の正確な特定という課題をよく抱えています。この課題に対処するため、Amazon Connect では一連のパフォーマンス評価機能を提供しています。これらの機能により、フォーム作成と評価プロセスの両方を自動化して、エージェントの評価に必要な手動プロセスを削減できます。さらに、Amazon Connect には技術的な評価機能のパブリック API も提供しており、フォーム作成と評価プロセスの両方を自動化できるため、エージェントの評価に必要な手動プロセスをさらに削減できます。 これらのAPIを使用することで、エージェントのパフォーマンスについて、他の側面を反映する外部のデータをエージェント評価プロセスに組み込むことができ、 Amazon Connect の外部にあるシステムから取得した情報でパフォーマンスに関する洞察を補うことができます。このブログ投稿では、これらの API の使用方法について説明します。 概要 この記事では、次のシナリオを使用して、API (アプリケーションプログラミングインターフェイス) の使用方法を示します。 AnyCompany は自動車保険会社で、コンタクトセンターに1000人以上のエージェントを擁し、保険サービスに関わる顧客からの通話を日常的に処理しています。同社では、エージェントに会社のポリシーに従い、カスタマーサービスの通話中、前向きな感情を保つことを求めています そのため、コンタクトセンターのスーパーバイザーは、エージェントが会社のポリシーを遵守していることを確認するために、エージェントのパフォーマンスを定期的に評価する必要があります。エージェントのパフォーマンスを評価するには、スーパーバイザーはエージェントと顧客の電話を聞いたり、チャットの記録を読んだりした後、電子フォームを使って電話やチャットでのやり取り中のエージェントのパフォーマンスに関して回答する必要があります ただし、コール数、エージェントの数が多く、実施される評価の数が少なすぎて、有意義な洞察を得たり、エージェントのパフォーマンスを向上させたりすることができていません。そのため、AnyCompany は、エージェントを自動的に評価し、スーパーバイザーが通話を聞いたり、通話の記録を読んだりしなくても、評価が確認できるシステムが必要です このブログ記事では、電子評価フォームをプログラムで作成し、Amazon Connect が最近リリースした API を使用してフォームに対してエージェントのパフォーマンスを評価するソリューションについて説明します。以下の図と手順は、この記事が従うワークフローを示しています (図 1 、図 2)。 図 1: API による評価フォームの作成 ステップ 1: API を活用して評価フォームを作成し、 Amazon Connect に保存します。このワークフローは上の図 1 に示されています。このワークフローにおける顧客とのやりとりを以下の図 2 に示します。 図 2: 顧客とのやりとりを示す概要図 ステップ 2: 発信者（顧客）が既存の自動車保険のサービスを受けるために電話をかけてきます ステップ 3: 発信者がエージェントと話し、やり取りが完了してエージェントが電話を切ると、発信者は通話後のアンケートオプションを選択し、アンケートに回答します。回答は 問い合わせ属性 としてキャプチャされ、その通話の 問い合わせレコード に保存されます ステップ 4: Amazon Connect が、この通話のトランスクリプトを S3 バケットに自動的にアップロードします ステップ 5: トランスクリプトファイルがアップロードされると Lambda 関数がトリガーされます ステップ 6: Lambda 関数が問い合わせ属性からアンケートのスコアを抽出します。また、トランスクリプトファイルから感情スコアを抽出します ステップ 7.1: Lambda 関数が評価フォームの質問を、アンケートの質問への回答と呼び出しのセンチメントスコアで更新します。 ステップ 7.2: Lambda 関数がこの通話の評価を送信します 前提条件 この手順では、以下について理解、アクセスできることを前提としています。 AWS アカウント Amazon Connect インスタンス Amazon Connect インスタンスで取得済みの電話番号 AWS IAM によるポリシーとロールの作成 Amazon S3 でバケットを作成する Stack を実行するための AWS CloudFormation Amazon Connect Contact Lens ソリューションのデプロイ 注:この投稿では、ネストされた CloudFormation テンプレート (CFT) のセットを使用しています。 メインの CFT は、他の 3 つのネストされた CFT を自動的に呼び出してデプロイを完了します。 手順の概要 : ソリューションのデプロイは、次の 2 つの手順で構成されます。 ここから CloudFormation スタックをデプロイ します 機能の確認 : テスト通話を行い、結果を確認します CloudFormation スタックのデプロイ ステップ 1: AWS マネジメントコンソール にログインします ステップ 2: CloudFormation スタックをデプロイします ステップ 2.1: 手順の概要に記載の 「 ここから CloudFormation スタックをデプロイ 」をクリックします ステップ 2.2: 図 3 のように一意なスタック名を入力します ( 例 : create-ef-assets) 図 3: CloudFormation のパラメータ設定 パラメータ “AmazonConnectInstanceArn” と “BasicQueueArn” は Amazon Connect インスタンスからコピーする必要があります。以下の手順では、これらを取得する方法について説明します。 ステップ 2.3: AmazonConnectInstanceARN : Amazon Connect インスタンスの ARN を取得する方法については、 こちら を参照してください。ARN をコピーし、下の図 4 に示すように CloudFormation のフォームに貼り付けます。 図 4: Amazon Connect インスタンスの ARN の確認 ステップ 2.4: BasicQueueARN : Amazon Connect コンソールからキューの ARN を取得する方法については、以下の図 5 を参照してください。Amazon Connect でキューを設定していない場合は、キューの設定方法について こちら を参照してください。Amazon Connect インスタンスが作成されると、“ Basic Queue “ がデフォルトで作成されます。このブログ用にインストールしたサンプルフローでは、このキューを使用して API の使用方法を説明しています。キューを設定したら、キューの ARN をコピーして、ステップ 2.3 と同様に CloudFormation フォームの BasicQueueArn に貼り付けます。 図 5: Queue ARN の取得 ステップ 2.5: S3BucketName : 通話録音が保存されている S3 バケットの名前。 次に示す ようにインスタンスページに移動します。通話録音を保存する S3 バケットは、「データストレージ」→「通話記録」の下に表示されます。 (下の図 6 を参照)このフィールドに必要なのはバケット名だけです。例 – amazon-connect-beXXXXXXXXXX (下の図 6 を参照してください。最初の「/」より前にあるものはすべてS3バケット名の一部であり、 CloudFormation テンプレートへの入力として指定する必要があります) 図 6: 通話記録の S3 バケット 図 7 のように CloudFormation テンプレートに貼り付けます。 図 7: CloudFormation の入力欄に S3 バケット名を貼り付け ステップ 3: 次のページで “ 次へ ” をクリックし、もう一度 “ 次へ ” をクリックします ステップ 4: 次のページの一番下までスクロールする ステップ 4.1:「 AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。 」のチェックボックスをオンにします。 ステップ 4.2:「 AWS CloudFormation によって、次の機能が要求される場合があることを承認します: CAPABILITY_AUTO_EXPAND 」のチェックボックスをオンにします。 ステップ 4.3: “スタックの作成“ をクリックします。 ステップ 5: AWS CloudFormation テンプレート がすべてのリソースを作成するのに 5 ～ 10 分かかる場合があります。完了すると、ステータスが CREATE_COMPLETE と表示されます。 注意: これは ネストされた CloudFormation テンプレート です。メインスタックは他の 3 つのスタックに依存しています。以下の図 8 は、これらの各スタックによって作成されるリソースを示しています。必要なのはベーススタック (install_ef_api_assets.yml) を実行することだけです。他のスタックはベーススタックによって自動的に呼び出されます。 図 8: CloudFormation テンプレートによってインストールされたアセット ステップ 6: このブログ記事は Amazon Connect Contact Lens を使用しています。Amazon Connect インスタンスにログインし、 Contact Lens が有効になっていることを確認します(下の図 9 を参照) 図 9: Contact Lens の有効化 機能のテスト このセクションでは、 CloudFormation テンプレート によってデプロイされたアセットの概要を説明し、その結果をテスト、検証します。 CloudFormation テンプレートによってデプロイされたアセット アセット 1: 評価フォーム: ステップ 1: コンソール内の評価フォームに移動し、 CloudFormation テンプレート によって作成されたフォームを探します (下記の図 10 と図 11 を参照) 図 10: Amazon Connect コンソールメニュー内の評価フォームの位置 図 11: 自動的に作成された評価フォームテンプレート ステップ 2: “ バージョン 1 ” をクリックして評価フォームを開き、作成された質問を確認します (下の図 12 を参照) 図 12: API を介して作成された評価フォーム アセット 2: コンタクトフロー 「フロー」セクションに移動し、テンプレートによって 2 つのフローが作成されたことを確認します (図 13) 図 13: テンプレートによって作成された 2 つのフロー 結果のテストと検証 ソリューションをテストする方法は以下の通りです。 ステップ 1: リンク先 の手順で、 BasicContactFlow で終わる問い合わせフローに電話番号を割り当てます ステップ 2: ユーザーを作成し、 リンク先 の手順で Basic Routing Profile  に割り当てます ステップ 3: リンク先 の手順で、エージェントとしてコンタクトコントロールパネルにログインし、ステータスが Available であることを確認します ステップ4: 上記のステップ 1 の電話番号に顧客として電話をかけ、CCP 経由でエージェントとして電話に出ます。45～50秒以上会話を続けてください。この後、以下の手順に従ってください。 ステップ 5: エージェント側で電話を切り、 Available に戻ります ステップ 6: 顧客側で通話を続けてください。次のようなアンケートのメッセージが流れます。 “ How did we perform, on a scale of one to five. One being bad and five being amazing. ” (私たちの対応を 1 から 5 で評価してください。悪ければ 1 、素晴らしければ 5 を選んでください) ステップ 7: 顧客側の電話のキーパッドで 1 から 5 までの数字 (3 など) を押します。 ステップ 8: システムからの返答 “ Thank you for rating us 3. Good bye. ” (3 の評価ありがとうございました、さようなら)を確認し電話を切ります ステップ9：1～3分待ってから、図 14-a に示すようにコンタクトの検索に移動し、かけた通話を検索し、通話を開いて詳細を表示します ステップ 10: 連絡先の詳細ページには、コンタクトが評価され、評価が自動的に送信されたことが表示されます。図 14-b を参照してください。また、評価に割り当てられたスコアも表示されます (この場合は 10% 、下の図 14-c を参照)。 図 14-a: コンタクトの検索画面 図 14-b: 連絡先の詳細画面に、自動的な評価結果が表示されている様子 図 14-c: 自動評価の詳細 API 呼び出しシーケンス 通話が終了すると、図 15 の順序で評価フォーム API が呼び出されます。 図 15: API 呼び出しのシーケンス図 クリーンアップ 評価フォームによるコンタクトの評価にはコストがかかります。さらに、電話の着信や Contact Lens に関する費用もかかります。Amazon Connect の料金は こちら に記載されています。今後課金されないようにするには: ステップ 1: 電話番号とコンタクトフローの関連付けを解除します ステップ 2: コンソールから「 電話番号を表示 」に移動します (図 16) 図 16: 電話番号を表示する ステップ 3: このテストで使用した電話番号を選択します (図 17) 図 17: 電話番号を選択 ステップ 4: 問い合わせフローの横にある「x」をクリックして、電話番号を問い合わせフローから切り離し (図 18)、「 保存 」をクリックします 訳注 : 電話番号の維持にもコストが発生します。電話番号をこのテストのために取得した場合は、 電話番号のリリース を検討してください 図 18: 問い合わせフローから電話番号の関連付けを切り離す ステップ 5: AWS CloudFormation のスタックを削除 し、作成したリソースを削除します 結論 スコアリングと評価は、エージェントの品質を管理するためのコンタクトセンターの運営に欠かせないものです。このブログ記事では、Amazon Connect API を使用して評価フォームを作成し、問い合わせを評価、送信する方法の例を示しました。評価に関する API の全リストは こちら をご覧ください。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

AWS Amplify の新しい コードファースト開発者エクスペリエンス は、ウェブ開発の未来を形作ることに貢献しています。このアプローチでは、AWS サービスの力を活用しながら、シームレスなデベロッパーエクスペリエンス（DX）に焦点を当てて、アプリファーストの考え方で構築することに重点が置かれています。このアプローチを採用することで、開発者は顧客のニーズを満たす堅牢でスケーラブルなフルスタックアプリケーションを作成できます。このブログ記事では、開発者がアプリを開発、拡張、デリバリーする際に直面するストレスの原因と、Amplify がこれらの課題をどのように解決するかについて詳しく説明します。コード生成から拡張性の実現、デプロイの合理化まで、Amplify にはフルスタックのアプリケーションをクラウドで構築するために必要なものがすべて揃っています。 この記事では、AWS Amplify のコードファーストアプローチの背後にある要件と主な利点について説明します。 ストレスの原因 開発者が開発プロセスにおけるストレスを経験すると、新機能の提供、バグの解決、顧客の問題への対応などが遅れる可能性があります。これはひいてはカスタマーエクスペリエンス全体に影響します。デベロッパーエクスペリエンス(以下 DX)の低下は、通常、次の 3 つの領域のいずれかに分類されます。 開発 あなたのウェブ開発者としての時間は、ウェブアプリの機能構築に費やされます。この構築過程を自動化したり、コーディング体験を向上させるベンダーのツールやサービスは、生産性と効率を大幅に向上させることができます。しかし、これらが意識的に設計されていない場合、それらは貧弱なエクスペリエンスの一因となる可能性があります。 ここでは、開発者のソフトウェア構築を支援するツールが考慮すべき、優れた DX のための一般的な考慮事項を紹介します： 冗長性の排除：CRUD API や UI コンポーネントのような冗長なコードを、ツールやサービスが生成する シームレスなパフォーマンス：導入してしてすぐ（Out-of-the-box）に効果を得られるようにする 型の安全性：TypeScript は新しい標準であり、支持されるに十分な理由がある 拡張 デフォルト設定は便利ですが、特定のアーキテクチャの決定を強制するものであり、将来、その決定が古くなる可能性があります。開発者のエクスペリエンスを向上させようとするあまり、ベンダーは自分のスタイルに合わないデフォルトに縛り付けてしまう可能性があります。 拡張性のある API：API を拡張できるだけでなく、ベンダーはパズルのピースを公開し、そこにあなた自身のピースをはめ込めるようになっているべき ロジックの持ち込み：ベンダーの API の一部を利用せず、代わりに独自のロジックを持ち込めるべきである （原文を尊重し、表現を直訳しています） デリバリー ウェブ開発者として完全に自動化すべきことが 1 つあるとすれば、それはプロダクトデリバリーです。残念なことに、私たちの多くはインフラストラクチャの設定に関してスキルギャップを抱えていますが、それは問題ありません。なぜなら、あなたの責任は開発に集中しているからです。 自動化: ホスティング機能だけでは不十分です。使い慣れた言語の CI/CD パイプラインを通じて、変更を加えて自動的にロールアウトできる必要があります 親しみある言語でのインフラストラクチャ設定: インフラストラクチャの設定経験は、ウェブ開発者に合わせて調整されるべきです。JavaScript 開発者の場合は JS を使用し、YAML の記述方法を理解して知っている場合は YAML を使用してサーバーを構成できる必要があります それぞれの DX に関する考慮事項についてより深いレベルで説明し、AWS Amplify がそれぞれをどのように解決するかについても見ていきましょう。 開発: Amplify の型安全性 TypeScript の人気は最近急上昇し、 2023 年 の Stack Overflow Developer Survey で 5 番目に愛されている言語になりました。TypeScript の人気は、ウェブ開発における柔軟性と堅牢性の両方を備えた言語を好むトレンドを反映しています。開発者は、エラーを早期に発見し、共同作業を合理化し、大規模なコードベースに明確な構造を提供する TypeScript の機能を高く評価しています。 型安全性により、実行時ではなく開発中にエラーを検出できるため、デバッグやテストにかかる時間を大幅に節約できます。また、コードを通じた明確なコミュニケーションが鍵となるコラボレーション環境では、コードの可読性と保守性が向上します。 ウェブ開発における TypeScript の人気と利点に加えて、TypeScript の Isomorphic 機能は急速に人気を集めています。TypeScript の Isomorphic 機能を使うと、開発者はサーバーコードとクライアントコードの両方からアクセスできる型を作成できます。つまり、開発者はサーバーとクライアント間でコードを共有できるため、コードの重複が減り、保守が容易になります。AWS Amplify は、これらすべての DX が組み込まれ、型安全性ファースト（タイプセーフファースト）になりました。 開発: 自動化されたパフォーマンス 私たちが Nuxt.js や Next.js をデフォルトにしている究極の理由は、SSR や SSG などのためではありません。100/100 のパフォーマンススコアの結果として、素晴らしい体験をお客様に提供したいからです。私は、Next.js、Astro、Nuxt、Remix が何をするか以上にパフォーマンスを気にするよう提唱していますが、基礎を正しくすることを心配する必要がないのは、すがすがしいことです。 React と Vue はブラウザで実行できる JavaScript を生成し、あらゆるパフォーマンスと SEO コストが発生する中で簡単にデプロイ/提供できるようにします。しかし、クライアントでハイドレートする前に、まずサーバーでページをレンダリングする必要がある場合、SSR のビルドプロセスと出力を制御する必要が出てきます。ここで Amplify Hosting の出番です。SSR のデプロイを気にすることなく、SSR フレームワークを使用してパフォーマンスを重視した構築が可能になります。ほとんどの場合、必要なのはリポジトリを接続することだけです。 AWS Amplify は Next.js アプリをすぐにサポートし、 Nuxt アプリもホスティング できるようになりました。 開発: コード生成 Web 開発での CRUD (作成、読み取り、更新、削除) の実装は反復的な作業で、多くの場合はこれらの開発にかなりの時間がかかります。この課題に対処するため、TypeScript 開発者はこれらのタスクを自動化してワークフローを合理化するコードジェネレーターに目を向けました。 コードジェネレーターは、データモデル、API クライアント、UI コンポーネント、フォーム UI を生成する場合に特に役立ちます。このような反復的なタスクを自動化することで、プロジェクトのより複雑でクリエイティブな側面に集中できます。さらに、コードジェネレーターは型の安全性を導入し、コード品質を向上させることで、DX を向上させることができます。 Amplify Gen 2 では、コードの記述時にロジックと型が自動的に生成され、CLI コマンドを明示的に実行する必要がなくなるため、自動化がさらに一歩進んでいます。Gen 2 は TypeScript ファーストで、フロントエンドコード用の「データクライアント」をデータスキーマから生成することができます。その結果、開発者はこのクライアントを利用して CRUDL (作成、読み取り、更新、削除、一覧表示) 処理を記述するだけでよくなり、CRUD のための関数を書くという、これまで行ってきた反復的な作業から解放されます。 以下のコードスニペットは、Gen 2 でスキーマを定義する方法を示しています。 DefineData 関数を使用してデータのスキーマと認証モードを設定します。これは、Gen 2 がバックエンドのデータモデル定義を型の安全性で合理化する方法を示しています。 // Backend import { type ClientSchema, a, defineData } from "@aws-amplify/backend"; const schema = a.schema({ Todo: a .model({ content: a.string(), done: a.boolean(), priority: a.enum(["low", "medium", "high"]), }) .authorization([a.allow.owner()]), }); export type Schema = ClientSchema<typeof schema>; export const data = defineData({ schema, authorizationModes: { defaultAuthorizationMode: "userPool", apiKeyAuthorizationMode: { expiresInDays: 30, }, }, }); 以下のコードスニペットは、 aws-amplify/data の generateClient 関数を利用して、バックエンドとやり取りするための型付きクライアントインスタンスを作成する React コンポーネントです。 // Frontend import { useState, useEffect } from 'react'; import { generateClient } from 'aws-amplify/data'; import { Schema } from '@/../amplify/data/resource'; export default function HomePage() { const client = generateClient<Schema>(); const [todos, setTodos] = useState<Schema['Todo'][]>([]); useEffect(() => { async function listTodos() { // fetch all todos const { data } = await client.models.Todo.list(); setTodos(data); } listTodos(); }, []); useEffect(() => { const sub = client.models.Todo.observeQuery() .subscribe(({ items }) => setTodos([...items])) return () => sub.unsubscribe() }, []); return ( <main> <h1>Hello, Amplify 👋</h1> <button onClick={async () => { // create a new Todo with the following attributes const { errors, data: newTodo } = await client.models.Todo.create({ content: "This is the todo content", done: false, priority: 'medium' }) console.log(errors, newTodo); }}>Create </button> <ul> {todos.map((todo) => ( <li key={todo.id}>{todo.content}</li> ))} </ul> </main> ); } 拡張: Hooks Hooks は、拡張性を付与する実装ツールです。拡張性とは、カスタマイズ、スケーラビリティ、将来を見据えたもの、効率性、そしてコラボレーションを意味します。 Amplify Functions は AWS Lambda に支えられており、サーバーサイドの拡張性を提供します。基盤となるインフラストラクチャを管理せず、アプリケーションにバックエンド機能を拡張できます。Amplify Gen 2 により、開発者は Amazon Cognito でのユーザー認証など、さまざまなイベントに対応するカスタム機能を作成できます。顧客がサインアップした後にビジネスロジックを実行したい状況を考えてみましょう。開発者は Amazon Cognito で post-confirmation トリガーを作成し、カスタムサーバーレス関数で認証フローを強化できます。 // amplify/backend.ts import * as url from 'node:url'; import * as cognito from 'aws-cdk-lib/aws-cognito'; import * as lambda from 'aws-cdk-lib/aws-lambda-nodejs'; import { defineBackend } from '@aws-amplify/backend'; import { auth } from './auth/resource.js'; import { data } from './data/resource.js'; const backend = defineBackend({ auth, data }); // create function stack for the auth triggers const authTriggerStack = backend.createStack('AuthTriggerStack'); // create the PostConfirmation trigger const postConfirmationTrigger = new lambda.NodejsFunction( authTriggerStack, 'PostConfirmation', { entry: url.fileURLToPath( new URL('./custom/post-confirmation.ts', import.meta.url) ) } ); // add the newly created trigger to the auth resource const userPool = backend.resources.auth.resources.userPool as cognito.UserPool; userPool.addTrigger( cognito.UserPoolOperation.POST_CONFIRMATION, postConfirmationTrigger ); Amplify Hub イベントはフロントエンドの拡張性を提供します。これにより、フロントエンドアプリケーションのさまざまな部分がリアルタイムで相互通信できるようになります。これは、アプリケーションの状態の変化やユーザー操作に迅速に対応する必要がある、動的で応答性の高いユーザーインターフェイスを作成する場合に特に役立ちます。たとえば、ユーザーがログインすると、フロントエンドのさまざまなコンポーネントがこのイベントに直ちに応答し、それに応じて UI を更新できます。 import { Hub } from "aws-amplify/utils"; const hubListenerCancel = Hub.listen("auth", ({ payload }) => { switch (payload.event) { case "signedIn": console.log("user have been signedIn successfully."); break; case "signedOut": console.log("user have been signedOut successfully."); break; case "tokenRefresh": console.log("auth tokens have been refreshed."); break; case "tokenRefresh_failure": console.log("failure while refreshing auth tokens."); break; case "signInWithRedirect": console.log("signInWithRedirect API has successfully been resolved."); break; case "signInWithRedirect_failure": console.log("failure while trying to resolve signInWithRedirect API."); break; case "customOAuthState": logger.info("custom state returned from CognitoHosted UI"); break; } }); hubListenerCancel(); // stop listening for messages Amplify Gen2 において、Hooks (サーバーレス関数と UI イベント) は後回しにされるものではなく、意図的にソリューションに組み込まれています。この統合により、開発者は順応性と拡張性に優れ、将来を見据えたアプリケーションを作成するためのツールを手に入れることができます。Amplify Hub イベントによるリアルタイムのインタラクションでフロントエンドを強化するにしても、サーバーレス機能でバックエンドを拡張するにしても、Amplify Gen2 は、現代のアプリケーション開発の限界を押し広げる柔軟性と能力を開発者に提供するように設計されています。 拡張: サービス 開発者は、新しいサービスをアプリケーションに統合するよりも、ソリューションの構築に時間を費やすことを好みます。一般的に、AWS サービスのオーケストレーションをアプリケーションコードに組み込む必要がある場合、多くのコンテキストスイッチが必要です。これらのサービスは手動で作成および管理する必要があり、各サービスの制約を事前に理解しておく必要があります。 この問題を解決し、開発者のエクスペリエンスを向上させるために、Amplify Gen2 は AWS Cloud Development Kit (CDK) の上に階層化されています。つまり、Amplify が生成するリソースを拡張するのに特別な設定は必要ないということです。たとえば、CDK を使用して LocationMapStack というカスタムスタックを作成し、アプリケーションに必要な Amazon Location Service リソースを定義できます。その後、このスタックを amplify/backend.ts ファイルに含めることで、アプリケーションの一部として確実にデプロイできます。 import { CfnOutput, Stack, StackProps } from "aws-cdk-lib"; import * as locations from "aws-cdk-lib/aws-location"; import { Construct } from "constructs"; export class LocationMapStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); // Create the map resource const map = new locations.CfnMap(this, "LocationMap", { configuration: { style: "VectorEsriStreets", // map style }, description: "My Location Map", mapName: "MyMap", }); new CfnOutput(this, "mapArn", { value: map.attrArn, exportName: "mapArn", }); } } // In amplify/backend.ts const locationStack = backend.createStack("locationStack"); new LocationMapStack(locationStack, "locationstack"); これの最大の利点は、コードエディターを離れる必要がないことです。Amplify の機能を既存の AWS リソースと統合できるため、既存のインフラストラクチャを Amplify の機能とともに活用できます。また、CDK が型を持っているため、 Intellisense から洞察を得ることができ、サービスのドキュメントを事前に読む必要はありません。 デリバリー: Time to Production（TTP） Qovery （トップクラスの社内開発者プラットフォーム）は、” Overcoming Shared Environment Bottlenecks “で、かつてはコラボレーションに効果的だった共有開発環境が、今では生産性のボトルネックを引き起こすことで知られていると書いています。このような環境では、プロジェクトの停滞や開発チームの妨げとなる競合やリソース競合が発生することがよくあります。4 人の開発者が単独でフルスタックの機能に取り組んでいるが、1 つの開発環境を共有しているところを想像してみてください。このような共有環境は、ストレスや遅延の原因となります。各開発者がそれぞれのコンポーネントに変更を加える際には、競合を避け、変更によってアプリケーション全体が損なわれないように、チームメイトと慎重に調整する必要があります。 このシナリオでは、開発者 A はバックエンドコードを熱心に更新しますが、開発者 C がデータベースの変更を完了するまで待つ必要があります。一方、UI を全面的に見直した開発者 B はジレンマに直面しています。コードをプッシュする必要があるが、開発者 D の進行中の統合作業とのコンフリクトの可能性には警戒しているということです。この共有開発環境は、コラボレーションを促進するどころか、進行を妨げ、開発サイクル全体を遅らせるボトルネックになります。 Amplify Gen 2 では、開発者ごとのクラウドサンドボックス環境が導入されています。ローカル開発向けに調整されたこれらの環境では、忠実度の高い AWS バックエンドがリアルタイムでデプロイされるため、開発者は本番環境に近い開発環境で機能を繰り返し開発できます。 このアプローチは、チームがクラウドアプリケーションで共同作業したり反復したりする方法に革命をもたらし、開発時間を大幅に短縮し、本番稼働までの時間（TTP）を短縮します。このプロセスのシンプルさも同様に画期的です。コードの変更を保存するだけで、コードをサンドボックス環境に簡単にデプロイできます。この 4 人の開発者が、お互いの変更によって環境が乱されることなく、フルスタックの機能を個別にシームレスに開発しているところを想像してみてください。 デリバリー: インラインバックエンド 従来のウェブ開発では、フロントエンドとバックエンドの両方のコンポーネントをデプロイするには、多くの設定と複数のステップが必要であり、ストレスの原因となる可能性があります。インラインバックエンドは、フロントエンドとバックエンドを別々にデプロイする必要がないため、デプロイプロセスを合理化し、アプリケーションを本番環境に移行するのに必要なステップを大幅に削減します。この合理化されたアプローチにより、開発者の時間と労力が節約され、デプロイエラーのリスクが最小限に抑えられるため、より信頼性が高く一貫性のある開発環境が保証されます。 Amplify Gen 2 では、コードをコミットするたびにフロントエンドとバックエンドをまとめてデプロイできます。コードファーストアプローチでは、Git リポジトリがフルスタックアプリケーションの状態の信頼できる情報源となることが保証されます。バックエンドのリソースはすべてコードとして再定義され、ブランチ間の再現性と移植性が促進されます。これと環境変数とシークレットの一元管理を組み合わせることで、下位環境から上位環境への昇格ワークフローが簡素化されます。Amplify Gen 2 は、単一プロジェクトのデプロイアプローチを導入し、Git ブランチを共有環境として活用し、コードファーストの理念を採用し、環境変数とシークレットの一元管理を実装することで、フルスタックのアプリケーションデプロイに革命をもたらします。 デリバリー: TypeScript でインフラストラクチャを追加する AWS Amplify Gen 2 はこの変化を利用して、「使い慣れたコードのみ」をモットーとする新しい方法論を提供しています。このアプローチにより、従来のインフラストラクチャ管理ツールや言語に付随する手間が省け、フルスタックの開発者は使い慣れた TypeScript を使用してアプリケーションインフラストラクチャを定義できるようになります。 これまで、インフラストラクチャをセットアップするには、AWS コンソールをナビゲートするか、多数の CLI コマンドを実行する必要がありました。その結果、セットアップの予測が難しくなり、エラーが発生しやすくなることがよくありました。Amplify Gen2 では、Amplify がこのプロセスを変革し、インフラストラクチャの設定を予測可能にし、データ、認証、ストレージサービスなどをサポートするコードと同じ場所に配置できるようになりました。この変更により、インフラストラクチャーの複雑さが制御不能になり、予測不能の原因になりかねないという大きな課題が解決されます。 パスベースの規約 ( amplify/auth/resource.ts や amplify/data/resource.ts など) に従って TypeScript としてインフラストラクチャをファイルに作成することで、開発者は Visual Studio Code の厳密な型指定と IntelliSense を活用してエラーを最小限に抑えることができます。バックエンドに重大な変更があった場合、フロントエンドコードで型エラーが発生し、開発者へ即座にフィードバックされます。このフィードバックループによってフロントエンドコードの信頼性を確保し、開発者が自信を持って開発を進めることができます。 import { defineAuth } from "@aws-amplify/backend"; import secret from "@aws-amplify/backend"; export const auth = defineAuth({ loginWith: { email: { verificationEmailSubject: "Welcome, verify your email", }, externalProviders: { loginWithAmazon: { clientId: secret("LOGINWITHAMAZON_CLIENT_ID"), clientSecret: secret("LOGINWITHAMAZON_CLIENT_SECRET"), }, }, }, multifactor: { mode: "OPTIONAL", sms: { smsMessage: (code) => `Your verification code is ${code}`, }, }, userAttributes: { profilePicture: { mutable: true, required: false, }, }, }); Amplify Gen2 の TypeScript のインフラストラクチャは、「設定より規約」の原則を体現しており、インフラストラクチャを管理するための明確で体系的な方法を提供します。つまり、開発者はコードエディターで快適に操作でき、その場でドキュメントにアクセスでき、コンテキストの切り替えによる中断を回避できます。 まとめ AWS Amplify のコードファーストアプローチは、カスタマーエクスペリエンスを優先し、AWS サービスを活用することで、ウェブ開発に革命をもたらしています。このアプローチにより、開発者は顧客のニーズを満たす堅牢でスケーラブルなフルスタックアプリケーションを作成できます。 このアプローチの主なメッセージには、コードからのインフラストラクチャ機能、インフラストラクチャを定義するコードを記述する機能、フルスタック開発用の TypeScript、保存時の変更のプレビュー、コード生成、設定不要のフルスタックデプロイなどがあります。これらのパラダイムを採用することで、開発者は TypeScript を使用してアプリケーションを構築し、迅速に開発サイクルを反復して、アプリケーションを簡単にスケーリングできます。AWS Amplify のコードファーストアプローチは、開発者に強力なツールとシームレスな開発体験を提供することで、ウェブ開発の未来を形作っています。 この記事は Christian Nwamba による “ The future of web development: AWS Amplify’s Code First Approach ” を和訳したものです。翻訳はソリューションアーキテクトの 髙柴 が担当しました。

AWS Glue は、分析、機械学習 (ML)、アプリケーション開発のためのデータを発見、準備、組み合わせることを簡単にする、サーバーレスなデータインテグレーションサービスです。AWS Glue を使用すると、データインテグレーションと ETL (Extract, Transform, Load) のパイプラインを作成、実行、モニタリングし、複数のデータストアにわたるアセットをカタログ化することができます。 AWS Glue for Spark についてお客様から最もよくいただくご質問のひとつに、ワークロードのコストを効果的にモニタリングし、最適化する方法があります。AWS Glue では、コストに関係するオプションが多数提供されているため、データワークロードのコストを効果的に管理しながら、ビジネスニーズに応じたパフォーマンスとキャパシティを維持できます。AWS Glue ワークロードのコストを最適化するには、ジョブ実行をモニタリングして、実際にかかったコストと使用状況を分析し、節約できるポイントを見つけ、コードや構成の改善に向けたアクションを取ります。 この投稿では、AWS Glue ワークロードの上にモニタリングと最適化技術を用いることで、コストを管理および削減するためのアプローチを紹介します。 AWS Glue for Apache Spark の全体的なコストのモニタリング AWS Glue for Apache Spark は、データ処理単位 (DPU) の数に基づいて最低 1 秒から 1 分単位の課金となります。 詳細は AWS Glue の料金 をご覧ください。このセクションでは、AWS Glue for Apache Spark の全体的なコストをモニタリングする方法について説明します。 AWS Cost Explorer AWS Cost Explorer で、DPU 時間の全体的な傾向を確認できます。次のステップを実行してください: Cost Explorer コンソールで、新しいコストと使用状況のレポートを作成します。 サービス として、 Glue を選択します。 使用タイプ として、次のオプションを選択します。 標準ジョブの場合は <Region>-ETL-DPU-Hour (DPU-Hour) を選択します。 Flex ジョブの場合は <Region>-ETL-Flex-DPU-Hour (DPU-Hour) を選択します。 インタラクティブセッションの場合は <Region>-GlueInteractiveSession-DPU-Hour (DPU-Hour) を選択します。 適用 を選択します。 詳しくは AWS Cost Explorerを用いてコストを分析する をご確認ください。 個々のジョブ実行コストのモニタリング このセクションでは、AWS Glue 上の Apache Spark ジョブの個々のジョブ実行コストをモニタリングする方法について説明します。これを実現するには 2 つのオプションがあります。 AWS Glue Studio の Monitoring ページ AWS Glue Studio の Monitoring ページで、特定のジョブ実行に費やした DPU 時間をモニタリングできます。 次のスクリーンショットは、同じデータセットを処理した 3 つのジョブ実行を示しています。1 回目のジョブ実行では 0.66 DPU 時間、2 回目のジョブ実行では 0.44 DPU 時間を費やしました。Flex を使用した 3 回目は、わずか 0.32 DPU 時間で済みました。 GetJobRun および GetJobRuns API ジョブ実行ごとの DPU 時間の値は、AWS API を通じて取得できます。 Auto Scaling ジョブと Flex ジョブの場合、 DPUSeconds フィールドは GetJobRun API と GetJobRuns API のレスポンスで利用できます: $ aws glue get-job-run --job-name ghcn --run-id jr_ccf6c31cc32184cea60b63b15c72035e31e62296846bad11cd1894d785f671f4 { "JobRun" : { "Id" : "jr_ccf6c31cc32184cea60b63b15c72035e31e62296846bad11cd1894d785f671f4" , "Attempt" : 0 , "JobName" : "ghcn" , "StartedOn" : "2023-02-08T19:14:53.821000+09:00" , "LastModifiedOn" : "2023-02-08T19:19:35.995000+09:00" , "CompletedOn" : "2023-02-08T19:19:35.995000+09:00" , "JobRunState" : "SUCCEEDED" , "PredecessorRuns" : [ ] , "AllocatedCapacity" : 10 , "ExecutionTime" : 274 , "Timeout" : 2880 , "MaxCapacity" : 10.0 , "WorkerType" : "G.1X" , "NumberOfWorkers" : 10 , "LogGroupName" : "/aws-glue/jobs" , "GlueVersion" : "3.0" , "ExecutionClass" : "FLEX" , "DPUSeconds" : 1137.0 } } Bash DPUSeconds フィールドは 1137.0 を返します。これは 1137.0/(60*60)=0.32 で計算できる 0.32 DPU 時間を意味します。 Auto Scaling のない他の標準ジョブの場合、 DPUSeconds フィールドは利用できません: $ aws glue get-job-run --job-name ghcn --run-id jr_10dfa93fcbfdd997dd9492187584b07d305275531ff87b10b47f92c0c3bd6264 { "JobRun" : { "Id" : "jr_10dfa93fcbfdd997dd9492187584b07d305275531ff87b10b47f92c0c3bd6264" , "Attempt" : 0 , "JobName" : "ghcn" , "StartedOn" : "2023-02-07T16:38:05.155000+09:00" , "LastModifiedOn" : "2023-02-07T16:40:48.575000+09:00" , "CompletedOn" : "2023-02-07T16:40:48.575000+09:00" , "JobRunState" : "SUCCEEDED" , "PredecessorRuns" : [ ] , "AllocatedCapacity" : 10 , "ExecutionTime" : 157 , "Timeout" : 2880 , "MaxCapacity" : 10.0 , "WorkerType" : "G.1X" , "NumberOfWorkers" : 10 , "LogGroupName" : "/aws-glue/jobs" , "GlueVersion" : "3.0" , "ExecutionClass" : "STANDARD" } } Bash これらのジョブの場合、DPU 時間は ExecutionTime*MaxCapacity/(60*60) で計算できます。そうすると 157*10/(60*60)=0.44 で 0.44 DPU 時間が得られます。AWS Glue バージョン 2.0 以降は 1 分が課金の最小単位であることに注意してください。 AWS CloudFormation テンプレート DPU 時間は GetJobRun API や GetJobRuns API で取得できるため、これを Amazon CloudWatch などの他のサービスと統合して、消費された DPU 時間の傾向を経時的にモニタリングできます。 たとえば、AWS Glue ジョブの実行が完了するたびに AWS Lambda 関数を呼び出して CloudWatch メトリクスを公開する Amazon EventBridge ルールを設定できます。 これを素早く設定するために、 AWS CloudFormation テンプレートを提供しています。このテンプレートは、ニーズに合わせて見直しやカスタマイズできます。このスタックがデプロイするリソースの一部は、使用時にコストが発生します。 CloudFormation テンプレートは、次のリソースを生成します: AWS Identity and Access Management (IAM) ロール Lambda 関数 EventBridge ルール リソースを作成するには、次のステップを完了してください: AWS CloudFormation コンソールにサインインします。 Launch Stack を選択します。 次へ を選択します。 次へ を選択します。 次のページで、 次へ を選択します。 最終ページの詳細を確認し、 AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します を選択します。 スタックの作成 を選択します。 スタックの作成には最大 3 分かかります。 スタックの作成が完了した後、AWS Glue ジョブが完了すると、次の DPUHours メトリクスが CloudWatch の Glue 名前空間に発行されます: 集計メトリクス – ディメンション=[JobType、GlueVersion、ExecutionClass] ジョブごとのメトリクス – ディメンション=[JobName、JobRunId=ALL] ジョブ実行ごとのメトリクス – ディメンション=[JobName、JobRunId] 集計メトリクスとジョブごとのメトリクスは、次のスクリーンショットのように表示されます。 各データポイントは個々のジョブ実行ごとの DPU 時間数を表しているため、CloudWatch メトリクスの有効な統計は SUM です。CloudWatch メトリクスを使用することで、DPU 時間数を詳細に確認することができます。 コスト最適化のオプション このセクションでは、Apache Spark 上の AWS Glue でコストを最適化するための主要なオプションについて説明します。 最新バージョンへのアップグレード Auto Scaling Flex ジョブのタイムアウト期間の適切な設定 インタラクティブセッション ストリーミングジョブ用の小さいワーカータイプ 個々のオプションについて詳しく見ていきます。 最新バージョンへのアップグレード AWS Glue ジョブを最新バージョンで実行することで、Apache Spark などのサポートされているエンジンのアップグレードバージョンで提供される最新の機能と改善を利用できます。 たとえば、AWS Glue 4.0 には、最適化された新しい Apache Spark 3.3.0 ランタイムが含まれており、ビルトインの pandas API のサポートに加え、Apache Hudi、Apache Iceberg、Delta Lake フォーマットへのネイティブサポートなど、データの分析と保存のためのより多くのオプションが使用できます。 また、TPC-DS ベンチマークで 10 倍高速な Amazon Redshift コネクタも含まれています。 Auto Scaling コスト削減のための最も一般的な課題の 1 つは、ジョブを実行するのに適切なリソース量を特定することです。 ユーザーはリソース関連の問題を回避するためにワーカーを必要以上に確保する傾向がありますが、それらの DPU の一部は使用されず、不必要にコストが増加します。 バージョン 3.0 以降の AWS Glue では、Auto Scaling により、バッチジョブとストリーミングジョブの両方でワークロードに基づいてリソースを動的に増減することができます。 Auto Scaling は、ジョブにリソースを過剰にプロビジョニングしたり、アイドル状態のワーカーに料金を支払ったりしないようワーカー数を最適化する必要性を軽減します。 AWS Glue Studio で Auto Scaling を有効にするには、AWS Glue ジョブの Job Details タブに移動し、 Automatically scale number of workers を選択します。 詳細は、 Introducing AWS Glue Auto Scaling: Automatically resize serverless computing resources for lower cost with optimized Apache Spark をご覧ください。 Flex 迅速なジョブ開始が必要ない場合や、ジョブの失敗時に再実行をする余裕のある緊急性の低いデータインテグレーションのワークロード場合は、 Flex が良い選択肢となります。 Flex を使用するジョブの開始時間とランタイムは、すぐに利用できる余剰コンピューティングリソースが常にあるわけではなく、ジョブの実行中に回収される可能性があるため異なります。 Flex ベースのジョブは、カスタムコネクタへのアクセス、ビジュアルジョブ作成エクスペリエンス、ジョブスケジューリングシステムなど、同じ機能を提供します。 Flex オプションを使用することで、ワークロードのコストを最大 34% 削減できます。 AWS Glue Studio で Flex を有効にするには、ジョブの Job Details タブに移動し、 Flex execution を選択します。 詳細は、 Introducing AWS Glue Flex jobs: Cost savings on ETL workloads をご覧ください。 インタラクティブセッション AWS Glue ジョブのスクリプトを開発する際には、コードに変更を加えるたびにジョブを繰り返し実行するのが一般的です。しかし、ジョブに割り当てられたワーカーの数と実行回数によってはコスト効率が良くない場合があります。また、このアプローチではジョブの実行完了を待つ必要があるため、開発に時間がかかってしまう可能性があります。この問題に対処するために、2022年に AWS Glue インタラクティブセッション をリリースしました。この機能により、開発者は Jupyter ベースのノートブックや IDE を使用してインタラクティブにデータを処理できます。セッションは数秒で開始でき、ビルトインのコスト管理機能があります。AWS Glue ジョブと同様に、使用したリソースに対してのみ課金されます。インタラクティブセッションを使用すると、コード全体を実行することなく、コードの変更をテストするためにコードを 1 行ずつテストできます。 ジョブのタイムアウト期間の適切な設定 設定の問題、スクリプトのコーディングエラー、データの異常などのため、AWS Glue ジョブが異常に長い時間がかかったり、データの処理に苦労することがあります。これによって予期しない課金が発生する可能性があります。AWS Glue では、任意のジョブに対してタイムアウト値を設定できます。デフォルトでは、AWS Glue ジョブは 48 時間のタイムアウト値で設定されていますが、任意のタイムアウトを指定できます。ジョブの平均実行時間を特定し、それに基づいて適切なタイムアウト期間を設定することをおすすめします。こうすることで、ジョブ実行ごとのコストを制御し、予期しない課金を防ぐことができます。また、ジョブに関連する問題をより早期に検出できます。 AWS Glue Studio のタイムアウト値を変更するには、ジョブの Job Details タブに移動し、 Job timeout に値を入力します。 インタラクティブセッションでは、セッションのアイドルタイムアウト値を設定することもできます。Spark ETL セッションのデフォルトのアイドルタイムアウト値は 2880 分 (48 時間) です。タイムアウト値を変更するには、 %idle_timeout magic を使用できます。 ストリーミングジョブ用の小さいワーカータイプ リアルタイムデータ処理はお客様にとって一般的なユースケースですが、これらのストリームには断続的でデータ量の少ないものもあります。特にストリーミングジョブを 24 時間 365 日実行する必要がある場合、G.1X や G.2X のワーカータイプがワークロードに対して大きすぎる可能性があります。コスト削減を支援するために、2022 年にストリーミング ETL ジョブのための 1/4 DPU ワーカータイプである G.025X をリリースしました。この新しいワーカータイプを使用することで、データ量の少ないストリームを 1/4 のコストで処理できます。 AWS Glue Studio で G.025X ワーカータイプを選択するには、ジョブの Job Details タブに移動します。 Type で Spark Streaming を選択した後、 Worker type で G 0.25X を選択します。 詳細は、 Best practices to optimize cost and performance for AWS Glue streaming ETL jobs をご覧ください。 コスト最適化のためのパフォーマンス調整 パフォーマンスチューニングはコスト削減において重要な役割を果たします。 パフォーマンスチューニングの第一歩は、ボトルネックを特定することです。 パフォーマンスを測定せず、ボトルネックを特定せずにコスト効果的な最適化を行うことは現実的ではありません。 CloudWatch メトリクス は簡単なビューを提供し、迅速な分析を可能にします。また、 Spark UI はパフォーマンスチューニングのためのより深いビューを提供します。 ジョブで Spark UI を有効 にし、UI を表示してボトルネックを特定することを強くおすすめします。 コストを最適化するための戦略の概要は以下のとおりです。 クラスターキャパシティのスケール スキャンするデータ量の削減 タスクの並列化 シャッフルの最適化 データの偏りを克服 クエリプランニングの高速化 この投稿では、スキャンするデータ量を減らし、タスクを並列化する技術について説明します。 スキャンデータ量の削減: ジョブブックマークの有効化 AWS Glue ジョブのブックマーク は、ジョブを定期的な間隔で複数回実行する場合に、データを増分的に処理する機能です。ユースケースが増分データロードの場合、すべてのジョブ実行のフルスキャンを避け、最後のジョブ実行からの差分のみを処理するために、ジョブのブックマークを有効にできます。これにより、スキャンするデータ量が削減され、個々のジョブ実行が加速されます。 データスキャン量の削減: パーティションのプルーニング 入力データがあらかじめパーティション分割されている場合は、パーティションの切り捨てによってスキャンするデータ量を減らすことができます。 AWS Glue DynamicFrame の場合、次のコード例のように push_down_predicate (と catalogPartitionPredicate ) を設定します。詳細は、 AWS Glue での ETL 出力のパーティションの管理 をご覧ください。 # DynamicFrame dyf = Glue_context . create_dynamic_frame . from_catalog ( database = src_database_name , table_name = src_table_name , push_down_predicate = "year='2023' and month ='03'" , ) Python Spark DataFrame (または Spark SQL) の場合、where 句や filter 句を設定してパーティションを剪定します。 # DataFrame df = spark . read . format ( "json" ) . load ( "s3://<YourBucket>/year=2023/month=03/*/*.gz" ) # SparkSQL df = spark . sql ( "SELECT * FROM <Table> WHERE year= '2023' and month = '03'" ) Python タスクの並列化: JDBC読み込みの並列化 JDBC ソースからの同時読み取り数は、構成によって決定されます。 デフォルトでは、単一の JDBC 接続が SELECT クエリを介してソースからすべてのデータを読み取ることに注意してください。 AWS Glue DynamicFrame と Spark DataFrame の両方が、データセットを分割することにより、複数のタスクにわたるデータスキャンを並列化してサポートしています。 AWS Glue DynamicFrame の場合、 hashfield または hashexpression と hashpartition を設定します。 詳細は、 JDBC テーブルからの並列読み取り をご覧ください。 Spark DataFrame の場合、 numPartitions 、 partitionColumn 、 lowerBound 、 upperBound を設定します。 詳細は、 JDBC To Other Databases をご覧ください。 まとめ この投稿では、AWS Glue for Apache Spark のコストをモニタリングおよび最適化する方法論について説明しました。これらの手法により、AWS Glue for Spark のコストを効果的にモニタリングし、最適化できます。 付録: Amazon CloudWatch の料金 AWS Glue ジョブで Amazon CloudWatch を使用する場合、CloudWatch メトリクスと CloudWatch ログに対して標準料金が請求されます。 詳細は Amazon CloudWatch の料金 をご確認ください。 ジョブのメトリクス : ジョブメトリクスを有効にすると追加料金が発生し、CloudWatch カスタムメトリクスが作成されます。 アプリケーションログ : CloudWatch ロググループ /aws-glue/jobs/output と /aws-glue/jobs/error の集計アプリケーションログについて追加料金が発生します。 連続ログ記録 : 連続ログ記録を有効にすると追加料金が発生し、CloudWatch ログイベントが CloudWatch ロググループ /aws-glue/jobs/logs-v2 に出力されます。 Glue ジョブに関連する CloudWatch の料金を最適化したい場合、まずは AWS Cost Explorer で内訳を確認する必要があります。 CloudWatch メトリクスのコスト最適化 メトリクスの料金を削減するために、ジョブメトリクスを無効にすることができます。 この投稿で提供されている CloudFormation テンプレートはカスタムメトリクスを作成するため、さらに追加の料金が発生することに注意してください。 CloudWatch ログのコスト最適化 CloudWatch Logs の料金設定は、主に取り込みとアーカイブストレージで定義されます。 ログ取り込みの料金を削減するために、次のことができます: ジョブスクリプト内の不要なログ出力を減らしてください。 print() 、 df.show() 、 カスタムロガー呼び出し などです no filter ではなく、 standard log filter を設定してください 本番ジョブのログレベルを DEBUG に設定しないでください ログアーカイブストレージの料金を削減するために、ロググループの保持期間を設定することができます。 詳細は、 CloudWatch Logs でログデータ保管期間を変更する をご覧ください。 本記事は、Leonardo Gómez、関山宜孝による “ Monitor and optimize cost on AWS Glue for Apache Spark ” を翻訳したものです。 翻訳はソリューションアーキテクトの高橋が担当しました。

この記事は Amazon EKS now supports Kubernetes version 1.29 (記事公開日: 2024 年 1 月 23 日) を翻訳したものです。 はじめに Amazon Elastic Kubernetes Service ( Amazon EKS ) チームは、 Amazon EKS 、 Amazon EKS Distro および Amazon EKS Anywhere (リリース 0.19.0) における Kubernetes バージョン 1.29 のサポートを発表できることを嬉しく思います。このバージョンのテーマは、美しい芸術形式である「曼荼羅」で、それは宇宙の完璧さを象徴しています。そのため、リリース名は「Mandala」です。Kubernetes リリースチームは公式リリース発表の中で、このリリースは「コミュニティの相互接続性、熱狂的なファンや専門家によって織り上げられた活気に満ちたタペストリー」を反映していると述べています。 アップグレードの前提条件 Amazon EKS で Kubernetes v1.29 にアップグレードする前に、完了する必要がある重要なタスクがいくつかあります。次のセクションでは、アップグレード前に対処する必要がある変更点の概要を説明します。 FlowSchema と PriorityLevelConfiguration の API バージョンを更新してください。 非推奨の flowcontrol.apiserver.k8s.io/v1beta2 API バージョンの FlowSchema および PriorityLevelConfiguration は、Kubernetes v1.29 では提供されなくなりました。 非推奨のベータ API グループを使用するマニフェストまたはクライアントソフトウェアがある場合は、v1.29 にアップグレードする前にこれらを変更する必要があります。 詳細については、 Deprecated API Migration Guide を参照してください。 Kubernetes 1.29 のハイライト この記事では、Kubernetes バージョン 1.29 リリースの注目すべき機能強化、および削除と非推奨の一部について説明します。まず、このリリースでは v1beta2 Flow control API グループの削除など、いくつかの重要な変更がもたらされることに注意することが重要です。これは、v1.29 にアップグレードする前に、非推奨 API グループを使用しているマニフェストまたはクライアントソフトウェアを更新する必要があることを意味します。最後に、v1.29 には、SidecarContainers のベータ版サポートなど、私たちが楽しみにしている機能強化がいくつかあります。Kubernetes バージョン 1.29 の変更とアップデートの完全なリストについては、Kubernetes の 変更ログ を確認してください。 以下は、v1.29 のリリースに関して私たち技術コミュニティが興奮しているいくつかの機能強化です。完全なリストは こちら を参照してください。 高度な Pod 管理機能がベータ版に到達 Kubernetes v1.29 では、一連の高度なポッド管理機能が導入されます。これらは強力な機能ですが、その影響を総合的にテストし、問題が発生した場合のロールバック計画を立てておくことをお勧めします。何らかの問題が発生した場合は、機能を無効にして kubelet を再起動することをお勧めします。 #753 がベータ版に移行し、SidecarContainers フィーチャーゲートがデフォルトで有効になりました。この機能により、Init コンテナを Pod が終了するまで実行し続けることができ、事実上、Init コンテナをサイドカーコンテナに変えることができます。これは、Pod 内のメインコンテナと並行して実行する必要がある、長時間実行する補助プロセスの管理の問題を解決します。たとえば、Pod にメインアプリケーションコンテナと、メインアプリケーションからログを収集して転送するロギングコンテナがある場合、ロギングコンテナをサイドカーコンテナとして定義できます。これにより、メインアプリケーションコンテナが実行されている間、ロギングコンテナは実行とログの収集を継続し、継続的なログの収集と転送を行うことができます。 セキュリティ強化 #2799 がベータ版に移行し、LegacyServiceAccountTokenCleanUp フィーチャーゲートがデフォルトで有効になりました。この機能により、Secret ベースの未使用の従来のサービスアカウントトークンを自動的にクリーンアップできます。具体的には、従来の自動生成された Secret ベースのトークンが長期間 (デフォルトで 1 年間) 使用されていない場合、無効であるとラベル付けし、無効であるとマークされた後、長期間 (デフォルトでさらに1年間) 使用が試みられなかった場合、自動的に削除します。例えば、Kubernetes クラスターが v1.22 で作成され、自動生成された Secret ベースのサービスアカウントトークンがあった場合、v1.29 にアップグレードした後でも、それらのレガシートークンが残っている可能性があります。この機能は、不要になった古い未使用トークンを自動的にクリーンアップし、潜在的な攻撃対象領域を減らすのに役立ちます。未使用のトークンを使用しているかどうかを確認するには、以下のコマンドを実行してください。 kubectl get cm kube-apiserver-legacy-service-account-token-tracking -nkube-system #3299 が安定版に移行し、Kubernetes v1.29では、KMSv2 および KMSv2KDF フィーチャーゲートがデフォルトで有効になりました。しかし、KMSv2 は現在 Amazon EKS ではサポートされていないことに注意してください。 これは、Kubernetes v1.29 で安定版に移行した最もクールな機能の完全なリストではありません。完全なリストについては、 Graduations to stable を参照してください。 削除された API バージョンと機能 現在では、Kubernetes の新しいバージョンがリリースされると、Kubernetes API のバージョンや機能が非推奨になったり、削除されたりすることは珍しくありません。このような場合、 v1.29 にアップグレードする 前に、すべてのマニフェストとコントローラーをこのセクションに記載されている新しいバージョンと機能に更新することが不可欠です。以下は v1.29 リリースの重要な注意点です。完全なリストについては、すべての Deprecations and removals in Kubernetes v1.29 を参照してください。 ノードの status.nodeInfo.kubeProxyVersion フィールドの非推奨化 Node オブジェクトの .status.kubeProxyVersion フィールドは現在非推奨となり、Kubernetes プロジェクトは将来のリリースでこのフィールドを削除することを提案しています。この非推奨フィールドは正確ではなく、歴史的には kubelet によって管理されてきましたが、実際には kubelet は kube-proxy のバージョンや kube-proxy が実行されているかどうかを知りません。クライアントソフトウェアでこのフィールドを使用している場合は、使用を中止してください。情報は信頼できず、このフィールドは非推奨になりました。 Amazon EKS の Kubernetes バージョンサポート Amazon EKS は現在、7 つの Kubernetes バージョン (v1.23 〜 v1.29) を サポート しています。Kubernetes v1.24 〜 v1.29 は標準サポートで、v1.23 は現在延長サポート中です。Kubernetes バージョン 1.24 は、2024 年 2 月 1 日に延長サポートに入ります。Amazon EKS の延長バージョンサポートについては、 こちらのブログ記事 と FAQ をご覧ください。延長サポートを利用したくない場合は、標準サポートの Kubernetes バージョンへのアップグレードをご検討ください。 まとめ この記事では、Kubernetes バージョン v1.29 の注目すべき変更点を説明し、利用可能となった最もエキサイティングな機能のいくつかを紹介しました。 Kubernetes v1.29 リリースノート に記載されているその他の改善点もぜひチェックしてください。クラスターを最新の Amazon EKS バージョンにアップグレードする際にサポートが必要な場合は、 こちら のドキュメントを参照してください。 簡単なアンケート にご参加いただき、今後のブログ記事でご覧になりたい情報をお知らせください。 翻訳はプロフェッショナルサービスの杉田が担当しました。原文は こちら です。

AI/ML（機械学習）の技術を実ビジネスに活用できるか検証するPoC（Proof of Concept：概念実証）フェーズにおいては、対象範囲を絞った小さなデータセットでMLモデルの構築・評価を行うことがあります。例えば小売業において、特定の店舗や商品カテゴリに絞り、需要予測モデルを構築してみるケースなどです。 PoCでよい結果が得られれば、全店展開や全商品展開など実ビジネスへの導入にむけてプロジェクトが動きますが、ここで課題が発生します。大規模データが対象になったことによる処理時間やコストの増大です。大規模データ処理基盤をいちから検討すると工数がかかり、本番導入への障壁になる可能性もあります。 このような課題解決に向けて、私たちは 小売業で売り上げ数量の予測を実現するサンプルソリューションを公開しました 。この記事では、Amazon Redshift Serverless と Amazon SageMaker を使用した大規模データ活用ソリューションで、実際にさまざまなサイズのデータで検証を行い、本ソリューション利用にかかるコストや時間を示すとともに、検証から得られたソリューション利用のポイントを解説します。 ソリューション 大規模データ処理を高速かつ低コストに実現するためのソリューションを GitHub で公開しています。このソリューションは、小売業を想定したサンプルデータセットを併せて用意しており、店舗別、商品別の売上個数の予測値を算出します。アーキテクチャの詳細は こちら を参照してください。 主な処理は、Amazon Redshift Serverless によるデータの前処理や特徴量生成、Amazon SageMaker によるMLモデルのトレーニング、SageMaker による推論（店別・商品別の売り上げ数量予測）の3つです。 Amazon Redshift Serverless は、大規模なデータに対する分析や加工をコスト効率よく高速に実行できるデータウェアハウスのサービスです。機械学習に必要な前処理をSQLで手軽に実行することができます。また、Serverless であることからインフラストラクチャーの管理が不要であるため、運用にあたってインフラストラクチャーの専門家を配置する必要はありません。 Amazon SageMaker は、高性能かつ低コストの機械学習をあらゆるユースケースで実現するための、包括的なツールセットを提供するフルマネージドサービスです。SageMakerを使用することで、ノートブック、デバッガー、プロファイラー、パイプライン、MLOpsなどのツールを使って、スケール可能なMLモデルの構築、トレーニング、デプロイができます。また、データサイエンティストやMLエンジニアが機械学習モデルのトレーニングとデプロイを迅速に開始できるようにする組み込みアルゴリズムスイートを提供しています。 本ソリューションでは SageMaker ビルトインアルゴリズムの LightGBM を利用しています。売り上げ数量予測は夜間にバッチ処理にて計算する運用を想定し、SageMaker バッチ変換ジョブを用いています。データ規模に対する処理時間とコストのベンチマークのため、MLモデルの予測精度は評価対象外としています。 サンプルデータセット ソリューションには、下の表に示すような商品マスタ、店舗マスタ、イベントカレンダ情報、天気情報、トランザクション（会計）データなどが用意されています。これらのデータは人工的に作成しています。データのさらなる詳細については こちら をご参照ください。 ファイル名 データ名 概要 categories.csv 商品カテゴリマスタ 商品の大分類、中分類、小分類などのカテゴリに関する情報 event_calendar.csv イベントカレンダ 祝日や、全社的なイベントに関する情報。店舗からの入力が必要な「店舗別イベント情報」は用いない。 products.csv 商品マスタ 商品名、カテゴリ、価格などの商品に関する情報 stores.csv 店舗マスタ 店舗タイプや所在地などの店舗に関する情報 transactions.csv 会計記録 1会計処理(トランザクション)を1レコードで記録。購買商品詳細はtransaction_details.csvに記録 transaction_details.csv 会計明細 会計内容の詳細、購買商品の種類ごとにレコードを持つ weather.csv 天気情報 外部システムから取得した日別、都道府県別の天気に関する情報 GitHubにあるサンプルデータ は、10MB程度の小さなものです。今回の検証ではより大きなデータセットを作成し、4つのデータセットに対して検証を行います。データセット名と特徴は以下の通りです。 retail_small : GitHubにある小規模データセット。20商品、3店舗、トランザクション5分に1回。 retail_medium : 中規模データセット。3500商品、200店舗、トランザクション1分に1回。 retail_large : 大規模データセット。3500商品、2000店舗、トランザクション1分に1回。 retail_extra_large : 特大規模データセット。3500商品、20000店舗、トランザクション1分に1回。 各データセットにおける各ファイルの詳細を以下に示します。 ファイル名をクリックするとダウンロードすることができます。   データセット ファイル名 レコード数 サイズ(.csv) サイズ(.csv.gz) 説明 retail_small categories.csv 14 864 B – – event_calendar.csv 19 1.6 KB – – products.csv 20 1.4 KB – 20商品 store.csv 3 200 B – 3店舗 weather.csv 90 6.4 KB – – transactions.csv 25059 2.1 MB – 各店舗5分に1回発生 transaction_details.csv 137559 8.2 MB – – TOTAL 約 16 万 10.3 MB – – retail_medium categories.csv 250 15.9 KB – – event_calendar.csv 19 1.9 KB – – products.csv 3500 267.1 KB – 3500商品 store.csv 200 16 KB – 200店舗 weather.csv 1410 99.8 KB – – transactions.csv.gz 8352200 726 MB 100 MB 各店舗1分に1回発生 transaction_details.csv.gz 45999200 2.9 GB 310 MB – TOTAL 約 0.46 億 3.7 GB 0.4 GB – retail_large categories.csv 250 15.9 KB – – event_calendar.csv 19 1.9 KB – – products.csv 3500 267.1 KB – 3500商品 store.csv 2000 157 KB – 2000店舗 weather.csv 1410 99.8 KB – – transactions.csv.gz 83522000 7.2 GB 992 MB 各店舗1分に1回発生 transaction_details.csv.gz 459992000 30 GB 3.1GB – TOTAL 約 4.6 億 37 GB 4 GB – retail_extra_large categories.csv 250 15.9 KB – – event_calendar.csv 19 1.9 KB – – products.csv 3500 267.1 KB – 3500商品 store.csv 20000 1.6 MB – 20000店舗 weather.csv 1410 99.8 KB – – transactions.csv.gz 835220000 74 GB 9.7 GB 各店舗1分に1回発生 transaction_details_storeid_1_2000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_2001_4000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_4001_6000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_6001_8000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_8001_10000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_10001_12000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_12001_14000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_14001_16000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_16001_18000.csv.gz 459992000 30 GB 3.1 GB – transaction_details_storeid_18001_20000.csv.gz 459992000 30 GB 3.1 GB – TOTAL 約 46 億 374 GB 40 GB – retail_extra_largeデータセットのtransaction_details.csvについては、2000店舗ごとにファイルを分けています。データ内容はstore_id以外は各店舗で同一です。 実験：処理時間とコストの計測 4つのデータセットに対して、Redshift Serverless による前処理、SageMaker による学習、SageMaker による推論の処理時間とコストを計測しました。 実施手順 GitHub上に準備されているretail_smallデータセットに対しては、 クイックスタートガイド に従って実施することができます。その他3つのデータセットに対しては、データセットをダウンロードして実施する必要があります。以下にretail_extra_largeのケースについてガイドします。 retail_extra_largeデータセットの検証ガイド クイックスタートガイド:デプロイの準備 「4. 実行環境の準備」において、AWS Cloud9 のリサイズは 500GB とします。データセットのダウンロードで必要なためです。（retail_medium、retail_largeは 100GB で十分） クイックスタートガイド:How to deploy 「1. cdk.jsonを編集」において、パラメータの編集を行います。 “trainingInstanceType”の、”ml.m5.xlarge”を”ml.m5.4xlarge”に変更します。（SageMaker学習ジョブでのメモリ枯渇に対応。retail_medium、retail_largeは変更不要） クイックスタートガイド:Operation 「3. テストデータをアップロード」において、データセットのダウンロード、.gzファイルの解凍、S3へのアップロードを行います。 まず、Cloud9 のターミナルで以下のコマンドを実行し、ファイルのダウンロードを行います。(retail_medium、retail_largeの場合は、-Pオプションの格納先ディレクトリと、ダウンロードURLを変更してください。） <Cloud9 ターミナルで実行> cd /home/ec2-user/environment/retail-large-data-ml-e2e/test wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/categories.csv wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/event_calendar.csv wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/products.csv wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/store.csv wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/weather.csv wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transactions.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_1_2000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_2001_4000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_4001_6000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_6001_8000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_8001_10000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_10001_12000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_12001_14000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_14001_16000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_16001_18000.csv.gz wget -P ./extralargedata/ https://d3rhanl4x81lsu.cloudfront.net/retail_extra_large/transaction_details_storeid_18001_20000.csv.gz ダウンロードファイルに含まれる.gzファイルを解凍します。 <Cloud9 ターミナルで実行> gunzip extralargedata/*.gz 解凍したデータセットをCloud9からS3にアップロードします。まず、以下の upload_s3.sh  ファイルを作成します。 <Cloud9 ターミナルで実行> cd /home/ec2-user/environment/retail-large-data-ml-e2e/test touch upload_s3.sh upload_s3.sh を開き、以下の内容を記載します。 <upload_s3.shの中身> #!/bin/bash echo "create prefix in ${INPUTBUCKET}" echo "data size is ${DIR_SIZE}" aws s3 cp ${DIR_SIZE}/categories.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/categories/categories.csv aws s3 cp ${DIR_SIZE}/event_calendar.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/event_calendar/event_calendar.csv aws s3 cp ${DIR_SIZE}/products.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/products/products.csv aws s3 cp ${DIR_SIZE}/store.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/stores/store.csv aws s3 cp ${DIR_SIZE}/weather.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/weather/weather.csv aws s3 cp ${DIR_SIZE}/transactions.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transactions/transactions.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_1_2000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_1_2000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_2001_4000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_2001_4000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_4001_6000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_4001_6000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_6001_8000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_6001_8000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_8001_10000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_8001_10000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_10001_12000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_10001_12000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_12001_14000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_12001_14000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_14001_16000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_14001_16000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_16001_18000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_16001_18000.csv aws s3 cp ${DIR_SIZE}/transaction_details_storeid_18001_20000.csv s3://${INPUTBUCKET}/${PROCESSINGDATE}/transaction_details/transaction_details_storeid_18001_20000.csv この、 upload_s3.sh をターミナルから以下のコマンドで使用します。INPUTBUCKET変数にはS3バケット名(retaildatasolutionstack-inputbucketXXXの正しい名称)を記載してください。 <Cloud9 ターミナルで実行> ### バケット名置き換える export INPUTBUCKET=retaildatasolutionstack-inputbucketXXXXXXXX-XXXXXXXXXXXXX ### Cloud9のデータセットディレクトリ export DIR_SIZE=extralargedata for GENDATE in 2023-04-01 2023-04-15 2023-04-16 2023-04-17 do export PROCESSINGDATE=${GENDATE} bash upload_s3.sh done この後は、 クイックスタートガイド:Operation 「4. ワークフローキック」から手順通りに実行します。 計測方法 Redshift Serverlessについては、AWS Step Functionsの”WakeUpRedshift”から”TrainingKicker”までを処理時間とします。この中で”WaitForWakeUp”は600秒待つ設定となっているので、処理時間から600秒を引いて算出します。 Redshift Serverlessのコストについては、4回ジョブを実行するので、合計コストを4で割った値とします。 SageMaker学習については、SageMakerトレーニングジョブの詳細画面から「請求可能な時間（秒）」を取得し、 インスタンスの単価 から算出します。 SageMaker推論はバッチ変換ジョブの詳細画面から「およそのバッチ変換所要時間」を取得し、インスタンスの単価と数から算出します。 その他条件 リージョン:東京リージョン(ap-northeast-1） 学習インスタンスタイプ: ml.m5.xlarge (retail_extra_largeのみ検証ガイドで述べた通りml.m5.4xlarge) 推論インスタンスタイプ: ml.m5.xlarge cdk.jsonのパラメータ”inferenceInstanceCount”は1とし、負荷分散しない場合の推論処理時間を計測する。 計測結果 計測は2023年12月〜2024年1月のものであり、最新の状況では異なる可能性があることをご留意ください。 東京リージョンにおけるml.m5.xlargeの時間あたり料金は0.298USD、ml.m5.4xlargeは1.19USDになります。（トレーニング、バッチ変換ともに） データセット データサイズ Redshift Serverless 処理時間 [秒] Redshift Serverless コスト [ドル] SageMaker学習 処理時間 [秒] SageMaker学習 コスト [ドル] SageMaker推論 処理時間 [秒] SageMaker推論 コスト [ドル] TOTAL 処理時間 [秒] TOTAL コスト [ドル] retail_small 10.3 MB 259 4.48 77 0.00637 120 0.00993 456 4.4963 retail_medium 3.7 GB 558 7.755 167 0.01382 240 0.01987 965 7.78869 retail_large 37 GB 2159 28.295 924 0.07649 1320 0.10927 4403 28.48076 retail_extra_large 374 GB 4136 70.58 2584 0.85416 12420 1.0281 19140 72.46226 処理時間を [秒] から [時分秒] へ、コストを [ドル] から[円] へ変換して以下に示します。(1ドル = 150円換算) コストは少数第2以下切り捨てで表示しています。 データセット データサイズ Redshift Serverless 処理時間 [時分秒] Redshift Serverless コスト [円] SageMaker学習 処理時間 [時分秒] SageMaker学習 コスト [円] SageMaker推論 処理時間 [時分秒] SageMaker推論 コスト [円] TOTAL 処理時間 [時分秒] TOTAL コスト [円] retail_small 10.3 MB 4分19秒 672.0 1分17秒 0.9 2分0秒 1.4 7分36秒 674.4 retail_medium 3.7 GB 9分18秒 1163.2 2分47秒 2.0 4分0秒 2.9 16分5秒 1168.3 retail_large 37 GB 35分59秒 4244.2 15分24秒 11.4 22分0秒 16.3 1時間13分23秒 4272.1 retail_extra_large 374 GB 1時間8分56秒 10587.0 43分4秒 128.1 3時間27分0秒 154.2 5時間19分0秒 10869.3 さらに処理時間を短縮するために 前処理に関しては、データの規模がさらに大きくなり、処理時間が問題になってきた場合は、Amazon Redshift Serverlessの処理能力をスケールさせることで対応することができます。Amazon Redshift Serverlessではベースの処理能力をRPU (Redshift Processing Unit) という単位で設定することができます。この値を大きくすることで処理能力を増大させ、処理の実行時間を短縮することができます。Amazon Redshift Serverlessの料金体系はRPUとクエリ実行時間を掛け合わせたものであるため、例えばRPUを2倍にすることで実行時間を半分にできたとすると、合計の料金が変わることなく実行時間を短縮することができます。 SageMaker学習に関しては、今回は1インスタンスで実施したが、長時間になることはありませんでした。しかし特徴量の数やハイパーパラメータによっては長時間化する可能性があります。その場合の選択肢として、 SageMakerビルトインアルゴリズムのLightGBMは分散学習機能を実装 しています。 SageMaker推論に関しては、retail_extra_large場合でも5時間強、10000円強程度であったことは、夜間のバッチ処理を想定しても実用に耐えうる値と思われます。また、今回は推論インスタンスを１で実施しましたが、”inferenceInstanceCount”パラメータを1より大きくすることで分散して推論処理を得られることができます。参考に、”inferenceInstanceCount”を4にした場合、3時間27分が55分となりました。単純に1/4の時間にはなりませんが、処理時間をパラメータ変更のみで大きく短縮することができます。 まとめ 本稿では、「 小売業で売り上げ数量の予測を実現するサンプルソリューション 」を活用することで、コストを抑えつつ、大規模データを短時間で処理できることを示すために検証を行いました。POCのデータサイズでは問題にならなくても、大規模データを利用する本番環境ではコストや時間が課題になることがあります。 今回の検証では、データサイズの増加にあたって並列度をあげることで時間が短縮できること、370GB、47億レコードのデータに対して5時間強、10000円強程度で処理が可能という結果を得ました。これは本ソリューションが大規模データにおいて高いコストパフォーマンスを提供することを示しています。 一方で、あくまで今回のデータセットに対しての結果であり、別データでも同じ性能が出るとは限らない点に注意が必要です。データや前処理ロジック、モデルパラメータで異なりますので。本稿を参考に、自社のデータでも試していただければと思います。 著者について 伊藤 芳幸(Ito Yoshiyuki), シニア機械学習ソリューションアーキテクト 生成AIを含むAI/ML技術の支援を担当しています。事業会社での経験を生かし、ビジネス上の課題を解決するためのAI/MLソリューションの提案や導入支援に努めています。新しい技術に触れることは楽しみの一つで、積極的に手を動かしています。 プライベートでは育児に忙しい日々を送っていますが、フットサルやジム通いを通じてストレスを発散しています。 秋田 仁雅(Akita Yoshinori), プロトタイピングエンジニア 普段は AWS を用いてプロトタイプを開発することでお客様の課題を解決するプロトタイピングエンジニアという業務を担当。 平間 大輔(Hirama Daisuke), Redshift スペシャリストソリューションアーキテクト AWSでは主にデータウェアハウスサービスのAmazon Redshiftに関する技術支援を担当。パフォーマンスチューニングが大好物。プライベートでは最近レトロPCいじりにハマっています。 下佐粉 昭(Shimosako Akira, @simosako ), シニアソリューションアーキテクト (アナリティクス) AWS ではデータレイク、データウェアハウス、BI 等アナリティクス領域専門のエンジニアとして活動。分析システムを AWS 上で稼働させるための技術支援を行いつつ、オンラインセミナーやイベントを通じて、新しい考え方や技術を広くを伝える活動をしている。 最近は「週刊 AWS」で、AWS の最新情報を伝える活動も行っている。プライベートは完全なインドア派でスポーツ観戦・観劇・絵画や映画の鑑賞と体を動かさないことに時間を費やしているが、そろそろ運動する習慣を作らないとヤバいのではと焦る日々。

このブログでは、大規模言語モデル（LLM）、Amazon Bedrock、Amazon OpenSearch Service を使用しておすすめの映画を教えてくれるチャットボットを作成する方法をご紹介します。このデモンストレーションでは、幅広いエンターテイメントのメタデータを提供する IMDb and Box Office Mojo Movies/TV/OTT のライセンス可能なデータパッケージを使用します。Amazon Web Services（AWS）の Media & Entertainment（M&E）のお客様の多くは、 AWS Data Exchange を通じて IMDb データのライセンスを取得しています。これにより、コンテンツが見つけやすくなり、顧客エンゲージメントと定着率が高まります。完全一致クエリとセマンティック一致クエリの両方において、IMDb データセット上に検索拡張生成（RAG）チャットボットを構築する方法について説明していきます。 背景 映画やテレビ番組を見ているときに、「他にもこのような映画がないかな？」、「この映画の俳優は他にどんな映画に出演しているのかな？」などと思ったことはありませんか？このブログ記事では、Amazon Bedrock サービスの LLM と IMDb などの外部データソースを使ってこれらの質問に答える方法をご紹介します。 この記事では、オンラインの M&E プラットフォームで会話型検索を有効にして、使いやすいユーザーエクスペリエンスを提供する方法について順を追って説明します。昨今、LLM はさまざまな自然言語処理や自然言語理解（NLP/NLU）タスクの分野で画期的な成果を上げています。LLM は、未加工のユーザーの意図を正確に理解し、特定のコンテキストに沿った結果を生成することができます。また、いくつかの例（few-shot 学習）を与えることで、RAG 技術を通じてナレッジベースに基づいて質問に答えることができます。これらの技術と IMDb のようなデータセットを併用することで、ストリーミングプラットフォームのユーザーは「トム・クルーズが出演するコメディー映画」や「ロンドンで撮影されたトム・ホランド出演のスパイダーマンの映画」などの高度な検索クエリを作成することができます。さらに、LLM の会話機能のおかげで、ユーザーは洗練されたクエリから始める必要がなくなります。ユーザーは LLM に一連の探索的なクエリを実行し、興味のある映画を絞り込むことができます。 IMDb と Box Office Mojo Movie/TV/OTT のライセンス可能なデータセット AWS Data Exchange の IMDb データセットは、16 億件を超えるユーザー評価、1,300 万人を超えるキャストとクルーのクレジット、1,000 万本もの映画/テレビ/エンターテイメント作品、ならびに 60 か国以上の世界の興行収入レポートデータを保持しています。 大規模言語モデル（LLM） 大規模言語モデル（LLM）は、一連の単語やフレーズを予測できるように、膨大な量のテキストデータを用いた広範囲にわたるトレーニングされた人工知能（AI）モデルです。これらのモデルは、言語翻訳、テキスト生成、感情分析など、さまざまな自然言語処理業務に精通しています。特にラベル付けされたデータが不十分な状況で真価を発揮し、ラベル付けされていないデータから単語の適切な文脈や解釈を予測できるため、人の言葉に近いテキストを作成することができます。 検索拡張生成（RAG） 検索拡張生成（RAG）は、コンテンツの検索と生成を組み合わせたニューラルテキスト生成手法です。LLM の最近の進歩により、一貫性のある流暢なテキストを生成できるようになりました。しかしながら、これらのモデルは生成機能のみに依存しているため、事実に即した正確で一貫性のあるテキストの生成は苦手です。この問題を克服するために、研究者たちは、ニューラルテキスト生成とニューラル情報検索を組み合わせた RAG を提案しました。まず、検索モデルを使用してナレッジソースから関連情報を取得します。ここで取得した情報が、その後のテキスト生成プロセスに情報を提供する基盤となります。次に、取得した情報はニューラルテキスト生成モデルに統合されます。この統合は、生成プロセスをガイドし、制約を課す役割を果たします。この方法を組み合わせた結果、生成モデルは、取得した情報と一貫性のある、より事実に即した出力を生成できるようになります。 Amazon OpenSearch Service Amazon OpenSearch Service は、インタラクティブなログ分析、リアルタイムのアプリケーションモニタリング、ウェブサイト検索などを簡単に実行できるフルマネージドサービスです。OpenSearch は、Elasticsearch から派生したオープンソースの分散型検索および分析パッケージソフトです。OpenSearch Service は、OpenSearch の最新バージョンに加え、19 バージョンものElasticsearch（バージョン 1.5 から 7.10）をサポートしているほか、OpenSearch Dashboards と Kibana（バージョン1.5から7.10）を利用した視覚化機能も提供しています。 アーキテクチャ IMDb and Box Office Mojo Movie/TV/OTT のデータセットを使って会話型検索とチャットがどのように行われるかを見てみましょう。 次の図は、（1）ユーザークエリを受信して結果を表示するフロントエンドとして機能する Streamlit アプリ、（2）クエリを処理してレスポンスを得る多数のバックエンドコンポーネントで構成されるソリューションアーキテクチャを示しています。 まずユーザーは、Streamlit アプリを操作して検索するユースケースに関連するクエリを入力します（上図に青丸で表示）。これには、特定のジャンルや特定の俳優が演じる映画を検索する質問などが含まれます。 バックエンドでは、Amazon Bedrock の LLM を使用して、ユーザークエリを OpenSearch ドメイン固有言語（DSL）クエリまたはエンベディングに変換します。たとえば、下記のユーザー検索クエリ： "What movies are starring Tom Cruise?" （トム・クルーズが主演している映画は？） は下記の検索クエリに変換されます。 {"query":{"bool":{"must":[{"terms":{"stars.keyword": ["Tom Cruise"]}}]}}, "sort": [{"rating": {"order": "desc","missing":"_last", "unmapped_type" : "long"}}]} 検索クエリは、OpenSearch インデックス（ここでは、全文インデックスと kNN ベースインデックスの両方を作成します）に保存されている IMDb and Box Office Mojo データセット内の最も類似した記録を返します。レスポンスには、映画のプロット、公開日、ジャンル、ロケーション、評価、監督、プロデューサーなど、関連する映画に関する情報が含まれます。 目的の出力を得るための理想的なプロンプトや指示（プロンプトエンジニアリング）は、LLM によって異なる場合があることに注意してください。 こちら で指示を変更して、選択した LLM に合わせて最適化することができます。 検索結果を受け取った後、ユーザーは仮想エージェントのアクティブ化を選択できます。このエージェントは、検索クエリに対するレスポンスドキュメントと LLM を使用して、検索結果で見つかった映画に関するいかなる質問にも回答できます。さらに、チャットインタラクションにはセッション固有のメモリが保持されるので、仮想エージェントは回答する際に以前のユーザー検索クエリを参照することができます。 前提条件 このソリューションを実装するには、AWS アカウントが必要であり、OpenSearch サービスと Bedrock に精通している必要があります。このアプリケーションをテストするための大まかな手順は次のとおりです。 IMDb データセットの作成 IMDb エンベディングの生成 OpenSearch インデックスの作成 Streamlit アプリケーションのローンチとテスト AWS CloudFormation によるリソースのプロビジョニング ソリューションの構造をご理解頂いたところで、ソリューションをアカウントにデプロイしてサンプルワークフローを実行することができます。このワークフローは、Amazon OpenSearch Service と Amazon SageMaker Studio ドメインを適切な設定の VPC モードで起動します。 スタックは、GitHub リポジトリの cloudformation template を使用して、AWS CloudFormation コンソールの AWS Region us-east-1 上でローンチできます。 1.     IMDb データセットの作成 1.1 データを Amazon S3 にエクスポートする IMDb データセットを使用するには、以下の手順に従います。 Step 1: AWS Data Exchange で IMDb データにサブスクライブする こちらのリンク（ https://console.aws.amazon.com/ ）から AWS Management Console にログインする。 検索バーで AWS Data Exchange を検索し、 [AWS Data Exchange] をクリックする。 左側のパネルの [Browse catalog] をクリックする。 [Browse catalog] の検索ボックスに [IMDb] と入力する。 IMDb and Box Office Mojo Movie/TV/OTT Data（SAMPLE） または IMDb and Box Office Mojo Movie /TV/OTT Data（PAID） のいずれかにサブスクライブする。 IMDb は毎日 1 回、データセットを AWS Data Exchange に公開しています。 Step 2: IMDb データを ADX から Amazon S3 にエクスポートする こちらの ワークショップ の手順に従い、IMDb データを ADX から Amazon S3 にエクスポートする。 Step 3: ファイルを解凍して title_essential_v1_complete.jsonl および name_essential_v1_complete.jsonl を取得する 1.2 IMDb データセットを処理する IMDbデータをインデックス作成に使用するには、未加工データを表形式に処理する必要があります。まず、IMDbファイルを統合して映画のタイトル情報を映画のキャスト/スタッフの情報とマージし、俳優や監督などのすべての名前を1つのデータセットにまとめます。次に、それをMovieLensデータに含まれる映画の小さめのセットと合わせてサブセットを作成し、映画の数を減らして小さなカタログ状にします。このサブセットの作成は任意であり、データセット全体を処理することも可能です。 2つのIMDbデータセット（code）をマージする手順は次のとおりです。   title_essential データセットを列でフィルタリングする： `[‘image’, ‘titleId’, ‘originalTitle’, ‘titleDisplay’, ‘principalCastMembers’, ‘principalCrewMembers’, ‘genres’, ‘keywordsV2’, ‘locations’, ‘plot’, ‘plotShort’, ‘plotMedium’, ‘plotLong’, ‘imdbRating’, ‘year’, ‘titleType’]` 列 principalCastMembers  列をカテゴリ別に分割し、Actors、Directors、Producers の 3 つの列を新たに作成する。（これらの列には数字のIDしか含まれていません） name_essential データセットのマッピングからキャストメンバー（俳優、監督、プロデューサー）の実際の名前を含めて、映画データセットに追加する。 キーワード、ロケーション、ポスター URL の処理済みバージョンを追加する。 結果を Parquet ファイルとして S3 に保存する。（例：s3://<bucket>/<folder>/movies.parquet） IMDb データセットが作成されると、追加の処理ではデータセットのサイズを小さくするために、小さい方の MovieLens データセット（ml-latest-small.zip）の映画だけが保持されます。データスキーマの一貫性を保ちつつ、大きな IMDb データセットを処理したい場合は、このステップを省略できます。 こちら のノートブックから、以下のステップを実行してください。 未加工のIMDbデータセット全体をフィルタリングして、Movie Lens データセットに含まれる映画のみにする。 ロケーションを処理して、都市名と国名の重複を削除する。 結果を Parquet ファイルとして S3 に保存する。このファイルへのデフォルトパスは s3://<bucket>/<folder>/imdb_ml_data.parquetです。 以下は、サンプルデータセットのサブセットのスナップショットです。 2.     エンベディングの作成 前述のデータセットは、「トム・ハンクスの映画にはどんなものがある？」などのクエリをフィルタリングするのに役立つかもしれませんが、「スナイパーアクション映画にはどんなものがある？」などのクエリに答えるためには、データセットを豊富なセマンティック情報でさらに強化する必要があります。 そのためには、 こちら のノートブックの指示に従い、以下のタスクを実行してください。 1.     movielens-20m データセット からの信頼性の高いキーワードで  IMDb キーワードを強化する。このステップは任意です。 2.     T5 large モデルの sentence-transformer を使用して、「プロット」、「キーワード」、「プロット+キーワード」列のエンベディング（サイズ 768）を生成する。 3.     エンベディングを元の映画データセットに追加し、Parquet ファイルとして S3 に保存する。 次に、 リポジトリ に戻り、 src/ フォルダで以下を実行します。 python index_creation.py このコマンドは以下のタスクを実行します。 Boto3 Python ライブラリを使用して OpenSearch Service クライアントを初期化する。 IMDb データセットの空白のエントリを NULL で埋める。 テキストと kNN エンベディング検索用に 2 つのインデックスを作成し、ingest_data_into_os 関数を使用して結合されたデータフレームからデータを一括アップロードする。 インデックスが作成されたら、 config.yml のドメイン名とインデックス名を更新します。 このデータ取り込みプロセスには 5～10 分かかります。この例では、テキストベースの検索と kNN エンベディングベースの検索を可能にする 2 つのインデックスが作成されます。テキスト検索は、ユーザーが入力する自由形式のクエリを映画のメタデータにマッピングします。「クリストファー・ノーラン監督の映画」、「俳優トム・ハンクスが出ている映画」などのクエリは、監督やプロデューサーなどの特定のメタデータにマッピングされるため、直接テキスト検索に使用されます。しかし、「スナイパーアクション映画にはどんなものがある？」などの自由形式のクエリは、エンベディングベースのセマンティック検索にルーティングされます。kNN エンベディング検索では、エンベディングの潜在空間から最も近い k 本の映画を見つけて出力として返します。 OpenSearch インデックスの詳細については、 こちらのブログ記事 を参照してください。 3.     Streamlit アプリを作成 OpenSearch でテキスト検索と kNN インデックスが動作するようになったので、このユースケースのフロントエンドを作成する Python パッケージである Streamlit を使用して ML を利用したアプリケーションを構築できます。 コードを実行するには、まず Streamlit と aws_requests_auth が Python 環境（EC2 や ECS コンテナなどの適切なコンピューティングインフラストラクチャ）にインストールされていることを確認する。提供されている コードリポジトリ は Amazon SageMaker Studio 上で Streamlit を実行します。以下のコマンドを使用して要件をインストールします。 pip install -r requirements.txt streamlit/フォルダーに移動して以下を実行し、Streamlit アプリの SageMaker Studio の URL を取得する。 sh run.sh 次に、Streamlit アプリケーションを実行してポート番号を取得する。 streamlit run chat.py SageMaker Studio の URL とポート番号を{sm_studio_url}/{ port_number }/ のように組み合わせます。 Streamlit アプリでは次のように表示されます。 検索とチャット IMDb 会話型検索アプリケーションに移動したら、以下を選択できます。 LLM このデモンストレーションでは、LangChain を使用して、LLM として Amazon Bedrock（Claude-V1）を利用しています。 Task type（タスクタイプ） 「検索（Search）」または「検索とチャット（Search and Chat）」。特定のクエリにサブスクライブしている IMDb データセット内の映画だけを特定したい場合は、「検索」を選択します。検索クエリで出力された映画についてさらに質問できるようにチャットボットにもアクセスしたい場合は、「検索とチャット」を選択します。検索およびチャット機能は、選択した特定の LLM によって実行されます。 Question（質問） 検索のユースケースに対する質問を選択します（タスクタイプに「検索」を選択した場合も、「検索とチャット」を選択した場合も）。アプリケーションには一連のデフォルトの質問のほか、次に示すように独自の質問を追加するオプションが用意されています。 検索のユースケースに対する質問は、次のいずれかに分類されます。 完全一致:ロケーション、俳優、プロット、評価、監督などに基づいた映画の検索 セマンティック一致:他と似ている映画の検索 たとえば、「トム・クルーズが主演するアクション映画にはどのようなものがありますか？」という質問をした場合、LLM は、IMDb データセット内の映画の中で、これと完全に一致するものを検索し、次の出力を生成します。 さらに、「検索とチャット」機能を選択した場合、次のチャットインターフェースがアプリケーションに出力されます。 現在、チャットチェーンはコンテキストの長さを維持するために一度に 5 つの質問に対応しています。ただし、コンテキストの長さを一定に保つために、コンテキストをチャンク化したり、最後の k 件の会話履歴をストーリー化するなどの高度な方法を試すこともできます。 レコメンデーションによる検索結果の強化 現在のシステムは検索インデックスからコンテンツを汎用的に取得しますが、 Amazon Personalize のリランキング サービスなどの別のツールと連携させて、これまでにキャプチャされたユーザー履歴に基づいて検索結果を並べ替えることもできます。 まとめ 本記事では、Bedrock と OpenSearch サービスによるテキスト検索と kNN ベースの検索を使用して、IMDb データセットの上に会話型検索を構築するソリューションを構築する方法について説明しました。このアプリケーションは LLM を使用して、ユーザーの質問を OpenSearch 経由でクエリできるコマンドに変換し、また特定の映画についてさらに質問するための会話型仮想エージェントを提供します。 この記事のコードサンプルの詳細については、 GitHub リポジトリをご覧ください。 参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は BD 山口、SA 石井が担当しました。原文は こちら をご覧ください。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 最近本当に寒くなりましたね。毎朝ウォーキングをしていたのですが、最近は零度を下回ることもあり、代わりに昼休憩にウォーキングをするようになりました。春になるまでは昼ウォーキングにして、春になったらまた朝に戻そうと思っています。 さて、AWSでは、AWS re:Inventの内容をまとめて日本語でお伝えするAWS re:Invent Recapを年初に実施していますが、今年はインダストリー編（業界ごと）とソリューション編（AWSサービスごと）の２つに分けて実施予定です。インダストリー・ソリューション別に時間を区切っているので、興味があるところに出やすい構成にしています。ぜひご参加ください。 – AWS re:Invent Recap – インダストリー編 2024 年 1 月 30 日（火）〜 2 月 1 日（木） – AWS re:Invent Recap – ソリューション編 2024 年 2 月 6 日（火）〜 9 日（金） それでは、先週の主なアップデートについて振り返っていきましょう。 2024年1月15日週の主要なアップデート 1/15(月) 米国祝日のためこの日の発表はありませんでした 1/16(火) AWS Transfer Family provides static IP addresses for SFTP connectors AWS Transfer for SFTP connector で固定的なIPアドレス設定がサポートされました。SFTP Connector は、リモートのSFTPサーバーとS3間のファイル連携を提供するTransfer for SFTP の機能です。この新機能はConnectorを作成する際に自動的に複数の固定IPアドレスが付与されるもので、リモートのSFTPサーバーでのIPアドレスフィルタリングを容易にします。 Amazon Corretto January, 2024 quarterly updates Amazon の無料 OpenJDK ディストリビューション Amazon Corretto の四半期アップデートが公開されました。Corretto 21.0.2, 17.0.10, 11.0.22, 8u402 がリリースされています。それぞれバグフィックス・セキュリティフィックスを含むため、早めの更新をお勧めします。 Amazon RDS for MySQL now supports multi-source replication Amazon RDS for MySQL でマルチソースレプリケーションがサポートされました。名前の通り、最大15のソースDBから1つのDBへのレプリケーションをサポートします。本機能はRDS for MySQL 5.7.44以降、もしくは8.0.35以降で利用可能です。 1/17(水) GLIDE for Redis, an OSS Redis client sponsored by AWS, now available in preview GLIDE (General Language Independent Driver for the Enterprise) for Redis という、OSSのRedisクライアント実装が公開されました。RESP (Redis Serialization Protocol) を高い信頼性・性能で提供すえることを目標に開発されており、OSSのRedisや、 Amazon ElastiCache for Redis、 Amazon MemoryDB for Redisへの接続に利用可能です。 こちらのGithubレポジトリで公開 されています。 Amazon RDS for SQL Server Supports TempDB configuration replication Amazon RDS for SQL Server で Multi-AZ構成を組んでいる際に TempDB の設定（名前、増加サイズ等）、がプライマリーからセカンダリーに同期されるようになりました。 これにより、プライマリー側で設定変更した際には、ユーザが操作しなくてもセカンダリーでも同じ設定でTempDBが利用されるようになります。 1/18(木) Simplify AWS Marketplace renewals with new future dated agreements feature AWS Marketplaceに将来の日付を指定した契約・契約更新の機能が追加されました。この機能により、AWS Marketplace の販売者は SaaS プライベートオファー作成プロセスの一環として未来の「開始日」を指定できます。購入者がオファーが受理すると、 ‘future dated’ agreement (将来の日付指定契約)が作成され、指定された開始日からユーザーがサービスを利用可能になります。詳細は こちらのドキュメント をご覧ください。 Amazon FSx for Windows File Server increases maximum IOPS level to 400,000 Amazon FSx for Windows File Server で、4Gb/s～12Gb/s のスループット容量レベルの際、従来より14%高い、最大400,000IOPSが提供可能になりました。また、この新機能による追加のコストは発生しません。 Amazon SNS now supports FCM HTTP V1 API for delivering mobile push notifications Amazon SNS のモバイルプッシュ機能において Google Firebase のHTTP V1 APIを使ったプッシュ通知がサポートされました。トークンベースの認証を行う既存もしくは新規のアプリケーションで利用可能です。 Google は 2024年6月1日から、従来の FCM v1 API を使用したモバイルプッシュ通知を送信する機能を廃止する予定のため、6月1日までに移行することをおすすめします。What’s newに各種ドキュメントへのリンクがありますので、それらを参照してください。 AWS CodeBuild announces support for reserved capacity AWS CodeBuild は、コンパイル・テスト・ビルドを自動実行する環境を提供するフルマネージド型のサービスです。今回リザーブドキャパシティ機能が追加されました。これにより、コンパイルやテストに必要なリソースを事前にプロビジョニングしておけるため、繰り返しビルドを行う際の時間を短縮可能です。リザーブドキャパシティについては こちらのドキュメント をご覧ください。 1/19(金) Amazon RDS for Db2 now supports Cross-Region Automated Backups Amazon RDS for Db2 でクロスリージョン自動バックアップがサポートされました。Snapshotのデータを自動的に他リージョンにコピーすることで、遠隔地リカバリー等のニーズに対応するものです。東京・大阪リージョンともに、ソース・ターゲット双方のリージョンとして設定可能です。 AWS announces higher read IOPS for Amazon Elastic File System Amazon Elastic File System (Amazon EFS) のIO性能向上がアナウンスされました。これまでは頻繁にアクセスされるデータおよびメタデータは、最大リード250,000IPOS、それ以外のデータは最大リード65,000IOPSでしたが、この65,000IOPSが90,000IOPSに40%性能向上しました。 Stream data into Snowflake using Kinesis Data Firehose and Snowflake Snowpipe Streaming (Preview) Amazon Kinesis Data Firehose で、 Snowflake データウェアハウスへのデータインジェクションのPreviewがアナウンスがされました。Snowpipeによるマイクロバッチ、およびSnowpipe Streamingによるストリーミング挿入の双方をサポートします。PreviewはN. Virginia、Oregon、Irelandリージョンで利用可能です。 それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (twitter – @simosako )

企業はクラウド移行の加速を常に追求しています。Infrastrcture as Code (IaC) は、クラウドリソースを効率的に自動化および管理するうえで不可欠です。 AWS Cloud Development Kit(AWS CDK) を使用すると、お気に入りのプログラミング言語でクラウドインフラストラクチャをコードとして定義し、 AWS CloudFormation を使用してデプロイできます。この記事では、組織内での CDK の採用を加速するための戦略とベストプラクティスについて説明します。この記事での議論は、組織がパイロットプロジェクトを成功裏に完了した後に始まります。この記事を読むことで、パイロットプロジェクトから得た教訓をプラットフォームエンジニアリングを通じて組織全体に広げる方法を学ぶことができます。再利用可能なコンポーネントの構築を通じて複雑さを軽減し、開発者ツールを介した高速かつ安全なデプロイ、内部開発者ポータル(IDP) によるプロジェクトのスタートアップの加速などの方法を学びます。CDK コミュニティへの参加とそこからのメリットについても述べます。 はじめに、テクノロジーの新しいトレンドであるプラットフォームエンジニアリングについて簡単に説明します。 DevOps のプラクティスは、IT 部門がより頻繁に、より高品質のソフトウェアを顧客に提供するのに役立っています。 DevOps の最近の進化は、ワークロードチーム (業務部門) をサポートするサービス、ツールチェーン、ドキュメントを構築するためのプラットフォームエンジニアリングチームの導入です。 プラットフォームエンジニアリングチームの重要な責任の 1 つは、ソフトウェアデリバリープロセスの管理です。 Amazon では、プラットフォームエンジニアリングを活用してデプロイメントを加速させてきた長い歴史があります。 これにより、年間 1 億 5 千万回のデプロイ を行いながら、 143 ものコンプライアンス 認定を取得できています。 プラットフォームエンジニアリングは、生産性を向上させ、アイデアと実装の間の摩擦を軽減し、セルフサービスポータルや開発者ツールを通じて安全でスケーラブルで再利用可能なリソースとコンポーネントのセットを介してワークロードの提供を加速することで、アジリティを向上させます。 プラットフォームエンジニアリングは、プラットフォームアーキテクチャ、データアーキテクチャ、プラットフォーム製品エンジニアリング、データエンジニアリング、プロビジョニングとオーケストレーション、モダンアプリ開発、CI/CDの 7 つの機能で構成されています。 プラットフォームエンジニアリングの詳細については、 AWS Cloud Adoption Framework をご覧ください。 これらの機能を確立するには、複数のプラットフォームチームとワークロードチームが協力する必要があります。 オペレーティングモデルの観点から、ワークロードチームはプラットフォームエンジニアリングと次の 3 つの方法のいずれかで対話しています (詳細については、 Building your Cloud Operating Model を参照してください)。 再利用可能なコンポーネントによる開発者の複雑さと認知負荷の軽減 では、プラットフォームチームはどのように CDK を利用して目標を達成できるのでしょうか。 プラットフォームエンジニアリングチームの一般的な目的の 1 つは、 コンストラクト と呼ばれる再利用可能なパターンを公開および提供することです。 コンストラクトは、複数のチームとプロジェクトで共有できる再利用可能な拡張可能な一般的なコンポーネントを作成するメカニズムを提供します。 多くのお客様は、暗号化や特定の AWS Identity and Access Management ポリシーなどのセキュリティのベストプラクティスを適用するために、独自のコンストラクト実装を記述しています。 例えば、デフォルトの Amazon S3 バケットコンストラクトの代わりに、組織のセキュリティ要件を実装した MyCompanyBucket を作成するかもしれません。このバケット構成は、セキュリティおよびコンプライアンスチームによって検証されたコンポーネントを使用していることを確認するために、複数のチームによって実装および拡張できます。 データガバナンスに焦点を当てるお客様の場合、CDK コンストラクトを使用することで、バックアップとアーキテクチャが組織のレジリエンスポリシーを満たすことを保証し、目標復旧時間 (RTO) と目標復旧時点 (RPO) のベストプラクティスを自動的に取り入れられるようになります。 データライフサイクルポリシーを適用したいユーザーの場合、統一されたアクセス制御を作成したり、必要な KPI を出力したりすることができます。CDK コンストラクトでは、デフォルトで安全でセキュアな構成を作成するための手段を提供できます。 CDK コンストラクトを DataOps に適用することで、データ系列のメタデータが保持され、データクレンジングが行われるテンプレート化された ETL パイプラインのメリットを享受できます。 お客様は AWS リソース以外のリソースのコンストラクトも作成しています。チームは、サードパーティの開発者ツール、可観測性システム、テストツールなどのコンストラクトを作成できます。このようにして、ワークロードチームは、1つのコードベースで AWS リソースと非 AWS リソースをコード化できます。独自のコンストラクトを書く際には、標準化を考慮しつつ、CDK パッケージのエコシステムの成長を活用する自由度と柔軟性のバランスが必要です。このバランスの例として、 AWS Solutions Constructs があります。これらは通常、標準のコンストラクトに基づいて作成されます。標準のコンストラクトを拡張せずに作成したコンストラクトは、ユーザーがより大きな CDK エコシステムと統合するのが難しくなります。 Construct Hub は、CDK 向けに定義されたクラウドアプリケーションの設計パターンとリファレンスアーキテクチャを発見および共有するための主要な場です。これらは AWS コミュニティによって構築および公開されています。AWS はパブリックな Construct Hub を提供していますが、企業は独自の AWS アカウント内にプライベートな Construct Hub を維持管理できます ( construct-hub 、 GitHub リポジトリ、または CDK ワークショップ で詳細を確認できます)。いずれの場合でも、主な目的は一貫しています。その目的とは、異なるワークロードチームが容易に利用できる共有ライブラリを提供することです。このアプローチにより、一貫性、再利用性が向上し、最終的にコスト削減と開発期間の短縮につながります。 このアプローチを活用する際にしばしばつまずく落とし穴の 1 つは、プラットフォームエンジニアリングチームが最新のテクノロジーを活用するための再利用可能なコンポーネントの構築が追いつかないことです。ここでパイロットプロジェクトからの教訓を活かすことが役立ちます。パイロットプロジェクトチームは、プラットフォームエンジニアリングチームと協力して、セキュリティのベストプラクティスを研究および実装します。一部のお客様は、プラットフォームエンジニアリングチームを新しいコンストラクトの作成者だけでなく、承認者としても機能させています。このモデルでは、パイロットプロジェクトチームは新しいテクノロジーのコンストラクトの構築にも取り組みます。プラットフォームエンジニアが新しいコンストラクトをレビューして承認します。プラットフォームエンジニアは、パイロットプロジェクトチームが保存時の暗号化、転送時の暗号化、最小特権などの必要な基準を満たしていることを確認します。承認されると、パイロットプロジェクトチームは新しいコンストラクトを Construct Hub に公開できます。このようにして、プラットフォームエンジニアリングは実験と革新を促進します。さらに、プラットフォームエンジニアリングチームは、コンストラクトの唯一の作成者ではなく、コンストラクトの作成についてインナーソース (訳註: 企業内でのソフトウェア開発にオープンソースソフトウェア開発の手法を取り入れること。) を推進できます。 DevSecOps のベストプラクティスを使用したアプリケーションのデプロイ アプリケーション開発者は、ビジネスの課題に直接対処するコードの作成に専門知識が集中すると、最も生産的になります。 組織の基準に沿ってアプリケーションをデプロイおよび運用する複雑なタスクは、特に新しいメンバーにとっては圧倒されるようなタスクになるかもしれません。 この複雑さはしばしばボトルネックとなり、実験的な開発プロセスを遅らせ、新しいアプリケーションの取り組みによる価値の提供を遅らせることがあります。 この課題への解決策は、デプロイパイプラインと運用モデルの自動化にあります。 徹底的にテストされた CDK コンポーネントをチーム間で共有し、堅牢な CI/CD (継続的インテグレーション/継続的デプロイ) プロセスを通じて検証することで、開発者への負担が大幅に軽減されます。 開発者はもはや組織のデプロイ戦略の複雑さに立ち入る必要がなくなり、独創的で革新的なコードの作成に集中できるようになります。 このアプローチは、開発プロセスを効率化するだけでなく、開発と運用の間のギャップを埋め、より緊密なチームとより迅速で効率的なリリースを実現します。 高品質なソフトウェアデリバリーの鍵の 1 つは、適切な継続的インテグレーションと継続的デリバリー (CI/CD)プロセスを整備することです。 実践的な例については、 CDK Pipelines: AWS CDK Continuous delivery for AWS CDK applications を参照できます。 この高レベルなコンストラクトは AWS CodePipeline によって動作し、 cdk deploy コマンドによるテストデプロイを超えて、異なるリージョンやアカウントの複数の環境への本番デプロイのための自動パイプラインを構築するのに役立ちます。 AWS CDK アプリケーションのソースコードを AWS CodeCommit 、GitHub、GitLab、BitBucket、または Amazon CodeCatalyst のソースリポジトリにコミットするたびに、AWS CDK Pipelines が自動的にアプリケーションの新しいバージョンをビルド、テスト、デプロイします。 このパイプラインは、スタック内のリソースが変更されたり、デプロイされる環境が変更されたりすると、パイプラインが自動的に再設定されます。 GitHub Actions ユーザーの場合は、 CDK Pipelines for GitHub Workflows をご覧ください。 複数のチームがこれらのパイプラインを拡張し、独自のステージを追加することで、デプロイされたコードが組織の品質、セキュリティ、リスク、コンプライアンス、クラウド財務管理の基準を満たすことを保証します。 パイプライン内にどのような自動化を組み込むかのベストプラクティスについては、 AWS Deployment Pipeline Reference Architecture を参照してください。 完全に機能するパイプラインを作成することで、プラットフォームエンジニアリングチームは、開発チームへの認知的負荷を軽減し、開発者体験を向上させることができます。 この戦略には 2 つの実装があります: クイックスタートパイプラインとゴールデンパイプラインです。 クイックスタートパイプラインでは、パイプラインは Construct Hub のコンストラクトとして作成され、再利用可能なコンポーネントに関する上記の議論と同様に扱われます。 パイプラインはシンプルなインターフェースと認知負荷の軽減を提供しますが、ワークロードチームはパイプラインを自身で制御し、自由に変更することができます。 その結果、セキュリティやコンプライアンス検証ツールのような品質管理の仕組みは、ワークロード チームによって無効にされ、パイプライン内のコントロールは保証できなくなります。 これは、コンプライアンスと監査のコストを削減したい組織にとっては望ましくありません。 コンストラクトのバージョン数が増えるにつれて、プラットフォームエンジニアリングチームは、ワークロードチームがどのバージョンを使用しているかを管理することが困難になる可能性があります。 ゴールデンパイプラインでは、パイプラインはコンストラクトとして作成されますが、中央集権化されたチームによって管理されます。 ワークロードチームはこれらのパイプラインを制御したり変更したりすることができません。したがって、セキュリティやコンプライアンスのツールのような品質管理の仕組みは無効化できません。 これらのコントロールは、監査人などのセキュリティ、リスク、コンプライアンスのステークホルダーに対して検証可能なものになります。 一方で、ワークロードチームからのアクセス許可を削除することにはコストが伴います。 ゴールデンパイプラインでは、プラットフォームエンジニアリングチームはしばしば、ワークロードチームのデプロイのトラブルシューティングに時間の大半を費やすことになります。 プラットフォームエンジニアリングチームはトラブルシューティングに時間を費やすことが増え、セキュリティと品質の基準を上げる新しいツールの導入、環境設定と組織の一貫性の改善、監査証跡と実施体制の強化などに時間を割くことがほとんどできなくなります。 2 つのメカニズムがこれらの戦略を補完します。 昔ながらの変更管理委員会 (CCB) は、証拠の収集と実施が困難な状況で検証可能性を提供します。 CCB は、パイプラインとアカウント作成プロセスに IT サービスマネジメント (ITSM) の承認とフリート管理プロセスを統合する CDK コンストラクトの恩恵を受けることができます。 一方で、ソフトウェアアーティファクトのためのサプライチェーンレベル (Supply chain Levels for Software Artifacts, SLSA) に関する新しい話題もあります。 これらのアーティファクトはデジタル証明として使用できます。 Kubernetes では、 Tekton chains のようなツールでこのパターンが見られます。OCI イメージに関連付けられた証明書や、証明書の存在を保証するために Kyverno が使用されています (詳細は Protect the pipe! Secure CI/CD pipelines with a policy-based approach using Tekton and Kyverno を参照)。 CDK によるマルチアカウントとクロスリージョンデプロイ DevOps のベストプラクティスは、本番へのデプロイ前に複数のステージでデプロイとテストを行うことを推奨しています。 さらに、AWS はステージごとに専用のアカウントの利用を推奨しています。これにより、リソースの分離とアクセス制御が容易になります。 このマルチアカウント戦略により、組織は AWS リソースを最大限に活用でき、詳細な制御が可能になります( Recommended OUs and accounts を参照)。 多くの場合、ワークロードごとに指定された AWS アカウントがあり、すべての CI/CD パイプラインがそこに存在します。 開発、ステージング、本番などの段階に対応する他の AWS アカウントにデプロイするために、これらのパイプラインによって実行されます。 AWS 上の CI/CD パイプラインを参照したクロスアカウント戦略の詳細については、 Building a Secure Cross-Account Continuous Delivery Pipeline をご覧ください。 自動化されたガバナンス 多くの企業は、CDK を利用してセキュリティ制御とポリシーを適用したり、デプロイパイプラインの一部としてコード解析ツールを使ってデプロイ前にセキュリティ上の問題を未然に防いだりしています。業界標準のツールである cdk-nag を利用することで、多くのチームが利用可能なルールセットを使ってアプリケーションのベストプラクティスをチェックしています。また、企業ではデプロイしたリソースを管理・整理するためのタグ付けの要件など、追加の要件を適用する独自の Aspect を作成している例も見受けられます。 お客様は、 CDK によって合成された CloudFormation テンプレート を作成し、 CloudFormation Guard を使用して、Policy as Code のドメイン固有言語 (DSL) ルールを使って出力を検証するための追加のチェックポイントを作成できます。プラットフォームエンジニアリングチームは、ルールを作成できます。ワークロードチームは、それらのルールを利用し、パイプライン内で CloudFormation Guard を実行できます。アプリケーションに CloudFormation Guard チェックを簡単に追加できる 公式コンストラクト があります。 AWS CDK では、インフラストラクチャはコードそのものです。 したがって、品質を確保し、開発者体験を向上させるために、すでに使用している標準的なツールを CDK でも使用する必要があります。 組織にコード品質プログラムがある場合は、CDK アプリケーションを Web アプリケーションやマイクロサービスと同様に扱う必要があります。 同様に、 Amazon CodeGuru Security と Amazon CodeWhisperer を使用することで、開発者は他アプリケーションと同様に、CDK コードのセキュリティと品質の改善に役立つ実行可能な推奨事項を得ることができます。 Aspects 、cdk-nag、コード品質ツールを使用することで、組織はデプロイ前にセキュリティの問題を防ぐことができますが、デプロイ後に機能するコントロールを作成することも重要です。 AWS CloudFormation Hooks を使用することで、お客様は CloudFormation スタックや CDK アプリケーションの作成、更新、削除の前にリソースを検査することができます。 CloudFormation Hooks を使用することで、プラットフォームエンジニアリングチームは、基準に沿っていないリソースのプロビジョニングに対して警告を出したり、防止することができます。 これらのフックは CDK で作成できます (詳細はこちらの Build and Deploy CloudFormation Hooks using A CI/CD Pipeline を参照)。 最後に、CDK を介して AWS Config のコンプライアンスチェックのルールセットをデプロイできます。 これらのルールのコレクションにより、組織は大規模にセキュリティ基準を要求できます。 組織がカスタムルールを作成したい場合、チームは AWS Config ルール のための高レベルのコンストラクトを使用してリアクティブコントロールを作成できます。 これらのパターンの多くは CDK よりも前から存在していましたが、CDK は企業内またはコミュニティ全体で共有されている再利用可能なコンポーネントを活用することにより、クラウドアプリケーションとコントロールの構築とデプロイを加速します。 アプリケーションの運用と可観測性 オープンソースコミュニティは、CDK アプリケーションの基本的なモニタリング機能を拡張する高レベルのコンストラクトライブラリを提供しています。 cdk-monitoring-constructs プロジェクトを使用すると、CDK アプリのモニタリングが簡単になります。同様に、 CDKWakeful はそれを一歩進め、多くのサービスを追加し、 Incident ManagerAWS Systems Manager Incident Manager 、 AWS Chatbot 、 Amazon Simple Notification Service による通知を自動的に受信するための、簡単に構成できるインターフェイスを提供します。オープンソースコミュニティからの既製ソリューションを活用することで、ビジネスロジックを中心としたカスタムメトリクスとしきい値に集中することができます。プラットフォームエンジニアリングチームは、オープンソースプロジェクトを変更および拡張して、ワークロードチームが運用を簡素化し、ヘルスステータスを集中システムに送信できるように支援できます。 内部開発者プラットフォームによる新規プロジェクトのスタートアップの加速 内部開発者プラットフォーム (Internal Developer Platform, IDP) は、プラットフォームエンジニアリングチームによって構築され、ゴールデンパスを構築し、開発者のセルフサービスを可能にします。これらのゴールデンパスは、ソースコントロールリポジトリとリポジトリ内に格納されたファイルを作成する一連のテンプレートとして表現されます。IDP がこれらのテンプレートを使用してソースコードリポジトリを作成すると、作成されたリポジトリには次のものが含まれる必要があります: チュートリアル (通常は README.md に記載) リファレンスドキュメント スケルトンソースコード 依存関係管理 CI/CD パイプラインテンプレート IaC テンプレート 可観測性の設定 CDK を使用すると、CI/CD パイプライン、IaC テンプレート、可観測性設定はすべて、単一の CDK アプリケーションの一部として構築できます。 プラットフォームエンジニアリングチームは、 Backstage 、 Humanitec 、 Port などのツールを使用して、ゴールデンパスを構築し公開します。 ゴールデンパスの構築には、基盤となるプロジェクト構造について 2 つの一般的なアプローチがあります。 一部の組織では、IaC コードリポジトリをアプリケーションコードから分離するアプローチを選択します。 他の組織では、すべてを 1 つのリポジトリに含めることを選択します。 ゴールデンパスと再利用可能なコンポーネントのどちらにどの程度配置するかについて、それぞれにトレードオフがあります。 両方のアプローチで、プラットフォームエンジニアリングチームは、CDKを活用することでコードの重複を回避できます。 組織が選択するアプローチによって、再利用可能なコンポーネントの整理方法が決まります。 以下では、両方のアプローチと再利用可能なコンストラクトへの影響について説明します。 アプローチ 1: 全てを一つのリポジトリに含める このアプローチでは、インフラストラクチャ、アプリケーション、設定、デプロイメントのすべてのコードが 1 つのリポジトリに含まれます。このアプローチにより、開発者はコラボレーションし、機能を構築し、迅速にイノベーションを起こすことができるため、推奨されるアプローチです。 詳細については、 ベストプラクティスのドキュメント を参照してください。 例については、 AWS Deployment Reference Architecture for Applications をご覧ください。 このアプローチは、バリューストリームに沿った (Stream-aligned な) チームで最も効果的です。 バリューストリームに沿ったチームは、同じチーム内に開発と運用の能力を備えています。 これらのチームは、技術的な機能ではなく、顧客の課題を解決することを目的として組織化されています。 プロジェクト内では、チームはアプリケーション階層 (API、データベースなど) やビジネス機能 (注文管理、製品カタログ、配送サービスなど) などの論理単位で組織化できます。 バリューストリームに沿った組織では、大規模で高度に標準化された再利用可能なコンポーネントがより適しています。 このタイプのコンストラクトの極端な例は、マイクロサービス全体のコードを含む単一のコンストラクトです。これらのチームでは、認知負荷は顧客の課題に集中しているため、アプリケーションの開発の複雑さを減らすことが成功の鍵となります。 アプローチ 2: アプリケーションコードのパイプラインを分離する この代替アプローチでは、アプリケーションコードとインフラストラクチャを別リポジトリに格納し、パイプラインを分離します。 パイプラインを分離すると、機能開発に焦点を当てるワークロード担当者と、それらのアプリケーションが実行されるインフラストラクチャの構築に注力するインフラエンジニアの間で、サイロ化やコラボレーションの減少につながることがしばしばあります。 このアプローチは、「マトリックス型」のチームで最もうまく機能します。 マトリックス型組織は、技術的な能力 (開発、運用、セキュリティ、ビジネスなど) を中心に構築されています。 こうした場合、高度に標準化されたコンストラクトよりも、よりモジュール型のコンストラクトの方がうまく機能します。 各組織のエキスパートは、CDK コンストラクトをメカニズムとして使用して、組織全体に自らの専門知識を共有できます。 この種のコンストラクトの例としては、集中型の監視にプラグインするためのフックを備えた、監視、アラート、セキュリティのためのコンストラクトなどがあります。 プラットフォームエンジニアリングによるコミュニティ・オブ・プラクティスの構築 大規模な組織内で新しいテクノロジーをスケールするには、コラボレーションを促進し、ベストプラクティスを確立し、エコシステムの変化に対応したコミュニティの構築と拡大が必要です。組織内にこれらのコミュニティ・オブ・プラクティスを作成できるようにするために、AWS は CDK ユーザーを教育するコンテンツの作成を中心とした複数のパブリックコミュニティをサポートしています。組織のコミュニティ・オブ・プラクティスのメンバーは、これらのパブリックな AWS サポートコミュニティを通じて、世界中の他の CDK 開発チームとつながることができます。 コミュニティ・オブ・プラクティス コミュニティ・オブ・プラクティス (CoP) は、非公式な交流や知識共有を通じて、特定のドメインで学習、協働、専門性を高めるために集まる、共通の関心事を持つ人々のグループです。 組織内で CDK を中心としたコミュニティ・オブ・プラクティスを確立することは、メンタリング、問題解決、再利用可能なアセットの実現につながることが証明されています。 はじめに、CDK を使用した再利用可能なコンストラクトと開発者ツールの作成者であるプラットフォームエンジニアリングチームが、コミュニティ・オブ・プラクティスの初期のコンテンツ作成者となります。 これにより、CDK の作成者が CoP を通じて自分の成果を公開するというフィードバックループが確立されます。 ユーザーは作成者に対して質問したり、直接的な指導をすることができます。 CoP がそれを確立した初期グループによって持続可能な形で拡大したら、CoP 内でハッカソンや Game Day を開始することができます。これによりイノベーションがもたらされ、組織全体の課題が解決されます。 完全に成熟したコミュニティ・オブ・プラクティスは、Wiki や知識のデータベースを所有しています。 タウンホール、オフィスアワー、ニュースレター、チャットチャネルなどのメカニズムを使用して、コミュニティを最新の状態に保ちます。 このようにして、CDK の専門知識が組織全体に広まっていきます。 AWS では、この専門知識の拡散により、プラットフォームエンジニアリング以外のチームも再利用可能なコンストラクトの作成者となっています。 再利用可能なコンストラクトを作成できる人を広げることで、自社のイノベーションを加速できます。 コミュニティ CDKをサポートするコミュニティは成長しつつあり、コンテンツ、コード、サンプル、ミートアップなど、さまざまなプラットフォームが利用できます。 CDK は現在 AWS によってメンテナンスされており、 AWS CDK GitHub ページ ではコミュニティのサポートのもと、プラットフォームへの貢献、イシューの提起、バックログの確認、アクティブなコミュニティメンバーとのディスカッションへの参加ができます。 CDK.dev は、CDK エコシステムを取り巻くコミュニティ主導のハブです。このサイトでは、最新のブログ、ビデオ、教育コンテンツをまとめています。また、 Slack プラットフォームへの参加リンクも提供しています。 CDK Patterns は、開発者が使用できる CDK で構築された AWS サーバーレスアーキテクチャパターンの オープンソースコレクション を提供しています。 これらのパターンは、 AWS コミュニティビルダー / AWS ヒーロー を通じて提供されています。 最後に、 AWS re:Post は、コミュニティが解決するための質問応答ポータルを提供します。 AWS コミュニティビルダー プログラムは、知識を共有しテクニカルコミュニティとつながることに情熱を持つ人々に対して、テクニカルリソース、教育、ネットワーキングの機会を提供しています。 コミュニティ・オブ・プラクティスは、cdk.dev のような AWS パブリックコミュニティを活用して、知識のギャップを埋めることができます。 タウンホールミーティングは、AWS Heroes やコミュニティビルダー、GitHub や re:Post への頻繁なコントリビューター、 CDK Day のスピーカーなどから恩恵を受けることができます。 ニュースレターは、すべてのAWS チャネルからの最新ニュースを集約および要約できます。 コミュニティ・オブ・プラクティスが CDK の専門知識を確立すると、このコラボレーションは双方向にもなります。 たとえば、組織のコミュニティのエキスパートは、 AWS Heroes になることができます。 成功事例は、 CDK Day 、ゲストブログ投稿を通じて共有でき、 AWS Summit 、 AWS re:Invent 、 AWS re:Inforce 、 AWS re:Mars などの主要イベントのいずれかで講演する可能性さえあります。 おわりに このブログ全体を通して述べてきたように、CDK ではインフラストラクチャはコードそのものです。 これによりインフラストラクチャ管理のパラダイムシフトが可能になりました。 今日、 Liberty Mutual 、 Scenario 、 Checkmarx 、 Registers of Scotland など、多くのお客様が CDK を使って成熟したエコシステムを構築しています。アクティブなオープンソースコミュニティ、長期サポートのための AWS 開発チーム、知識共有のための複数のプラットフォームがあるため、開発者は迅速に学習、構築、革新することができます。 成功したパイロットプロジェクトにより、CDK を採用した多くの組織が、よりアジャイルに、より速く革新できるようになりました。 これは Amazon でもまさに起こったことで、CDK は新しいサービス構築の第一選択肢です。 組織はしばしば、プラットフォームエンジニアリングを通じてスケールと複雑さの削減を実現します。 これらのチームは、ベストプラクティスを適用することで高レベルなコンストラクトを構築し、CI/CD パイプラインを提供してデプロイメントを加速します。 インフラストラクチャのコードに対するユニットテストや、各段階 (作成から運用まで) の構築者へのガイダンスを提供する堅牢なセキュリティ管理を用いることで、デプロイメントの安全性が高まります。 最後に、コミュニティを構築することで、組織は成熟したエコシステムを構築できるようになります。 内部コミュニティとオープンソースコミュニティの両方を通じて、開発者はつながり、新たな発見や成長が実現されます。 この記事は David Hassler, Amritha Shetty, Chris Scudder, Kumar Karra による Best practices for scaling AWS CDK adoption within your organization を翻訳したものです。 翻訳は Solutions Architect の山崎宏紀が担当しました。

現代のクラウドコンピューティングにおいて、Infrastrcture as Code (IaC) は、クラウドリソースのデプロイと管理に不可欠な要素となっています。 AWS Cloud Development Kit (AWS CDK) は、開発者が馴染みのあるプログラミング言語を使用してクラウドリソースを定義できるようにする、人気のオープンソースフレームワークです。関連するオープンソースツールである Projen は、複雑なソフトウェア設定の管理を簡素化する強力なプロジェクト生成ツールです。この記事では、Projen と AWS CDK を使用するための基本的な使い方について学び、Projen を使用することのメリットや課題について議論します。 Projen とは 高品質でモダンなソフトウェアを構築するには、lint、テスト、リリースの自動化などのタスクを処理するために、たくさんのツールと設定ファイルが必要です。各ツールには、JSON や YAML のような固有の設定インターフェースと構文があり、メンテナンスの複雑さが増します。 新しいプロジェクトを始めるとき、ゼロから始めることはめったになく、しばしばプロジェクト生成ツール (例えば、 create-react-app ) を使用して新しいプロジェクトを生成します。大量の設定が自動的に作成され、それらのファイルの所有権が付与されます。さらに、プロジェクト生成ツールは多数存在し、毎日のように新しいツールが公開されています。 Projen は、開発者がプロジェクトの設定ファイルを効率的に管理し、高品質なソフトウェアを構築できるよう支援するプロジェクト生成ツールです。コード内でプロジェクト構造と設定を定義できるため、さまざまな環境とプロジェクト間でのメンテナンスと共有が容易になります。 Projen は、AWS CDK コンストラクトライブラリ、React アプリケーション、Java プロジェクト、Python プロジェクトなど、 複数のプロジェクトタイプ をサポートしています。新しいプロジェクトタイプはコントリビューターによって追加され、プロジェクトは複数のプログラミング言語での開発が可能です。 Projen は、 jsii ライブラリを使用しています。これにより、API を一度記述すると、複数のプログラミング言語でライブラリを生成できます。さらに、Projen は projenrc ファイルを通じて、プロジェクト全体の設定を管理する単一のインターフェイスを提供します！ 次の図は、Projen を使用した AWS クラウドリソースのデプロイプロセスの概要を示しています: この例では、Projen を使用して、たとえば新しい CDK TypeScript アプリケーションなどの新しいプロジェクトを生成できます。 開発者は、AWS CDK リソースを使用してインフラストラクチャとアプリケーションコードを定義します。プロジェクト構成を変更するために、開発者は package.json などのファイルを直接編集する代わりに、 projenrc ファイルを使用します。 プロジェクトは CloudFormation テンプレートを生成します。 CloudFormation テンプレートは AWS アカウントにデプロイされ、AWS クラウドリソースをプロビジョニングします。 図1 – Projen の提供する機能: Projen はプロジェクトの開始をサポートし、プロジェクトの他の要素を気にする代わりにコーディングに集中できるようにします。lint、ユニットテストとコードカバレッジ、リリースとバージョニング、依存関係管理のための複数のGitHub アクションがすぐに利用できます。 Projen のメリットと課題 メリット 一貫性 : Projen を使用することで、標準的なプロジェクトテンプレートを定義できるため、異なるプロジェクト間での一貫性を確保できます。異なるプロジェクト生成ツールを使用する必要がなく、Projen のみを使用できます。 バージョン管理 : プロジェクト設定がコードで定義されているため、変更履歴の追跡や他者とのコラボレーションが容易になります。 拡張性 : Projen は、さまざまなプラグインと拡張機能をサポートしているため、特定のニーズに合わせてプロジェクト設定をカスタマイズできます。 AWS CDK との統合 : Projen は AWS CDK とのシームレスな統合を提供し、クラウドリソースの定義とデプロイプロセスを簡略化します。 多言語対応 CDK コンストラクトライブラリ : 一度のビルドによって、複数のランタイムで実行できます。Projen は、TypeScript で開発された CDK コンストラクトを、JSII のサポートにより Java (Maven) や Python (PyPI) に変換および公開できます。 API ドキュメント : CDK コンストラクトの構築時には、コメントから API ドキュメントを生成します。 課題 Microsoft Windows のサポート。Projen が Windows 環境で完全に動作しないという未解決の issue がいくつかあります ( https://github.com/projen/projen/issues/2427 と https://github.com/projen/projen/issues/498 )。 フレームワークの Projen は、アーキテクチャ、ベストプラクティス、規約についてのいくつかの前提が存在します。 Projen はまだ GA (General Availability、正式リリース版) ではなく、この記事を書いている時点でのバージョンは v0.77.5 です。 Projen の利用手順 ステップ1: 前提条件の設定 AWS アカウント Node のダウンロードとインストール yarn のインストール AWS CLI : 資格情報の設定 AWS CDK を使用したスタックのデプロイには、専用の Amazon S3 バケットやその他のコンテナが、デプロイ中に AWS CloudFormation で利用できるようにしておく必要があります ( 詳細情報 )。 注 : Projen をグローバルにインストールする必要はありません。 npx を使用して Projen を実行するので、必要なすべてのセットアップステップが処理されます。 npx は、次の npm パッケージを実行するツールです。 ローカルの node_modules フォルダ内に存在する グローバルにインストールされていない npx は npm バージョン 5.2+ にバンドルされています ステップ2: 新しい Projen プロジェクトの作成 次のコマンドを使用して、新しい Projen プロジェクトを作成できます: mkdir test_project && cd test_project npx projen new awscdk-app-ts このコマンドは、AWS CDK サポートが含まれた新しい TypeScript プロジェクトを作成します。サポートされているプロジェクトタイプの完全なリストは、公式ドキュメント Projen.io 、またはプロジェクトタイプを指定せずに npx projen new コマンドを実行することで参照できます。また、 npx projen new awscdk-construct を使用して再利用可能なコンストラクトを作成し、それを他のパッケージマネージャに公開することもできます。 作成されたプロジェクト構造は次のようになります: test_project | .github/ | .projen/ | src/ | test/ | .eslintrc | .gitattributes | .gitignore | .mergify.yml | .npmignore | .projenrc.js | cdk.json | LICENSE | package.json | README.md | tsconfig.dev.json | yarn.lock Projen は次のものを含む新しいプロジェクトを生成しました: GitHub のワークフローファイルを使用してプロジェクトをビルドおよびアップグレードできる空の git リポジトリ。リリースワークフローは projen のタスクでカスタマイズできます。 .projenrc.js はプロジェクトの主な設定ファイルです Visual Studio Code との統合のための tasks.json ファイル 空の CDK スタックを含む src フォルダ License と README ファイル package.json には、名前、バージョン、依存関係など、プロジェクトに関する機能的なメタデータが含まれています git でファイルを管理するための .gitignore 、 .gitattributes ファイル JavaScript でのパターンを特定する .eslintrc パッケージマネージャからファイルを除外するための .npmignore プルリクエストを管理するための .mergify.yml コンパイラオプションを設定する tsconfig.json 生成されたファイルのほとんどには、次のような免責事項が含まれています: # ~~ Generated by projen. To modify, edit .projenrc.js and run "npx projen". Projen の力は、その単一の設定ファイル .projenrc.js にあります。 このファイルを編集することで、プロジェクトの lint ルール、依存関係、 .gitignore などを管理できます。 Projen は変更をすべての生成されたファイルに反映させることで、プロジェクト全体の依存関係管理を簡素化および統一します。 Projen によって生成されたファイルは手動で編集することを意図していません。 手動で変更を加えた場合、次に npx projen コマンドを実行したときに上書きされます。 プロジェクト設定を編集するには、単純に .projenrc.js を編集し、再生成のために npx projen を実行してください。 Projen API の詳細については、 こちらのドキュメント を参照してください: 。 Projen は projenrc.js ファイルの設定を使用して、基本的なメタデータ(プロジェクト名、CDK バージョン、デフォルトのリリースブランチなど)を持つ新しい AwsCdkTypeScriptApp をインスタンス化します。 このプロジェクトタイプでは、カスタマイズのために追加の API が利用できます(例: ランタイム依存関係の追加)。 プロパティを変更して、Projen の反応を確認してみましょう。 例として、 projenrc.js のプロジェクト名を更新します: name: 'test_project_2', その後、 npx projen コマンドを実行します。 完了したら、プロジェクト名が package.json ファイルで更新されたことがわかります。 ステップ 3: AWS CDK リソースの定義 Projen プロジェクト内で、TypeScript などの開発者が馴染みのあるプログラミング言語を使用して AWS CDK リソースを定義できます。 たとえば、 Amazon Simple Storage Service(Amazon S3) バケットを定義する例を次に示します: 1. src/ ディレクトリの main.ts ファイルに移動します。 2. ファイルの先頭のインポートを次のように変更します: import { App, CfnOutput, Stack, StackProps } from 'aws-cdk-lib'; import * as s3 from 'aws-cdk-lib/aws-s3'; import { Construct } from 'constructs'; 3. 行 9 の「 // define resources here... 」を次のコードに置き換えます: const bucket = new s3.Bucket(this, 'MyBucket', { versioned: true, }); new CfnOutput(this, 'TestBucket', { value: bucket.bucketArn }); ステップ 4: 合成とデプロイ 次に、 アプリケーションのブートストラップ を実行します。ターミナルで以下を実行してください。 $ npx cdk bootstrap リソースを定義したら、CloudFormation テンプレート(アプリケーションによっては複数)を含むクラウドアセンブリを合成できます。(訳註: linter の仕様上、 main.ts の25行目でスタック名を test-project-devに変更する必要があります。) $ npx projen build npx projen build はいくつかのアクションを実行します。 アプリケーションのビルド CloudFormation テンプレートの生成 テストとリンターの実行 Projen の synth() メソッドは、Projen によって管理されているすべての設定ファイルの実際の合成(および更新)を実行します。これは、Projen で管理されているすべてのファイルを削除し(ファイルがある場合)、ユーザーが指定した最新の設定に基づいてそれらを再合成することによって実現されます。 利用可能な npx projen コマンドの完全なリストは、 .projen/tasks.json で確認できます。また、プロジェクト API project.addTask を使用して、必要なカスタムアクションを実行する新しいタスクを追加することもできます! タスクは、シェルスクリプトでバックアップされたプロジェクトコマンドシステムを定義するプロジェクトレベルの機能です。 CDK アプリケーションのデプロイ $ npx projen deploy Projen は、CDK によって生成されたテンプレートに基づいて変更セットを作成し実行することで、設定された AWS アカウントに CloudFormation スタックをデプロイするために cdk deploy コマンドを使用します。上記のステップの出力は次のようになるはずです。 deploy | cdk deploy ✨ Synthesis time: 3.28s toto-dev: start: Building 387a3a724050aec67aa083b74c69485b08a876f038078ec7ea1018c7131f4605:263905523351-us-east-1 toto-dev: success: Built 387a3a724050aec67aa083b74c69485b08a876f038078ec7ea1018c7131f4605:263905523351-us-east-1 toto-dev: start: Publishing 387a3a724050aec67aa083b74c69485b08a876f038078ec7ea1018c7131f4605:263905523351-us-east-1 toto-dev: success: Published 387a3a724050aec67aa083b74c69485b08a876f038078ec7ea1018c7131f4605:263905523351-us-east-1 toto-dev: deploying... [1/1] toto-dev: creating CloudFormation changeset... ✅ testproject-dev ✨ Deployment time: 33.48s Outputs: testproject-dev.TestBucket = arn:aws:s3:::testproject-dev-mybucketf68f3ff0-1xy2f0vk0ve4r Stack ARN: arn:aws:cloudformation:us-east-1:263905523351:stack/testproject-dev/007e7b20-48df-11ee-b38d-0aa3a92c162d ✨ Total time: 36.76s アプリケーションは、設定された AWS アカウントに正常にデプロイされました。また、作成された S3 バケットの Amazon リソースネーム (ARN) は、CloudFormation のスタックの出力タブから利用でき、ターミナルの「Outputs」セクションに表示されます。 クリーンアップ CloudFormation スタックの削除 ワークショップのこのセクションで作成したリソースをクリーンアップするには、CloudFormation コンソールに移動し、作成したスタックを削除します。プログラムで同じタスクを実行することもできます。 $ npx projen destroy 次の出力が表示されるはずです。 destroy | cdk destroy Are you sure you want to delete: testproject-dev (y/n)? y testproject-dev: destroying... [1/1] ✅ testproject-dev: destroyed S3 バケットの削除 S3 バケットは保持ポリシーが RETAIN に設定されているため削除されません。S3 コンソールに移動し、作成したバケットを削除してください。そのバケットにファイルを追加した場合は、削除する前に空にする必要があります。詳細は、 バケットの削除 を参照してください。 おわりに Projen と AWS CDK は、クラウドリソースとプロジェクト構成を管理するための強力な組み合わせを提供します。Projen を利用することで、プロジェクト間の一貫性、バージョン管理、拡張性を確保できます。AWS CDK との統合により、開発者に馴染みのあるプログラミング言語を使用してクラウドリソースを定義およびデプロイできるため、プロセス全体がより開発者フレンドリーなものになります。 クラウド開発のベテランであれ初心者であれ、Projen と AWS CDK は、クラウドリソース管理の合理化されたアプローチを提供します。Infrastructure as Code のメリットを、柔軟でパワフルなモダン開発ツールとともに体験してみてください。 この記事は、Alain Krok, Dinesh Sajwan, Michael Tran らによる Getting started with Projen and AWS CDK を翻訳したものです。 翻訳は Solutions Architect の山崎宏紀が担当しました。

こんにちは。元メーカー生産技術出身でAWSへ転身した、変わり種ソリューションアーキテクトの岩根と黒田です。 ものづくり白書2023 では、日本の製造業について「我が国の生産現場は、高度なオペレーション・熟練技能者の存在によって、現場の最適化・高い生産性に強みを持つ」と分析しており、熟練技能者がクラフトマンシップを発揮して高い現場力を維持していることが強みという認識が示されています。一方で、「海外の先進企業は、データ連携や生産技術のデジタル化・ 標準化に強みを持ち、企業の枠を越えた最適化を実現」という表現で日本と海外先進企業の違いを分析しています。日本の製造業が今後さらに競争力を高めていくためには、高い現場力による部分最適と、データ連携によるデータドリブンなオペレーションと全体最適とを両立させることが鍵となりそうです。本ブログでは、部分最適と全体最適という一見すると相反したものを目指すデータドリブンとクラフトマンシップが交わるのか？について考察していきます。 なぜデータドリブンが必要なのか？ なぜ、今データドリブンな意思決定が必要なのでしょうか。工場オペレーションの効率化や加工精度の追求には引き続きクラフトマンシップが欠かせないでしょう。一方、若年者の減少、非正規雇用の増加、雇用流動性の高まりを考えると、これまでと同じやり方での技能伝承も課題になってくるでしょう。さらには、サプライチェーンはグローバル規模に拡大し、炭素排出量のような新たに把握が求められる情報についても増加の一途をたどっています。広範囲かつ多岐にわたる情報のトレーサビリティを求められ、個人の勘・コツで管理できる範疇を超えてきていると感じる方も多いのではないでしょうか。このような理由により、意思決定は複雑化し「現場の高度なオペレーション・熟練技能者の存在 による現場の部分最適・高い生産性」だけで競争力を保つのは困難になりつつあります。加えて、スマートプロダクトやSoftware-Defined-Vehicle（SDV）のような、「売ってから進化するプロダクト」の登場により、競争力を保つために求められる改善スピードが格段に速くなっていることも拍車をかけていると言えそうです。こうした課題に立ち向かうための武器が “データ” であると考えます。客観的なデータをもとに意思決定することで、より迅速に、説明性・再現性をもたせることが可能になります。 データドリブンを実装するためのアプローチ ここで二つの寓話をご紹介します。「製造業と関係ない！」と感じられるかもしれませんが、まずはお読みください。 寓話1： 老舗鰻店の決断 創業100年を超える老舗鰻店のA鰻店では、コロナ禍で悪化した経営状況から、地方で飲食チェーンを展開するB社の傘下に入り営業を続けていた。A店では創業以来継ぎ足し続けた秘伝のタレが味の秘訣であり、4代続く板前に代々引き継がれてきた。ある日B社の幹部がA店を訪れ、「A鰻店の2号店を出したい。ゆくゆくはチェーン展開も考えている。自慢のタレの成分分析をして、工場で生産できるようにしたい。協力してくれないか」と持ちかけた。 寓話2: ファイターの意思決定 とある人気アニメで主人公のライバルとなる戦闘民族は、相対する相手と戦う際に、相手の強さが数値でわかるスマートグラス機器を装着している。そこで相手の強さが定量的にわかる上に、自身の強さも把握しておくことで、有利に戦闘を進めることができるようになっている。 何が言いたいのか？ 2つの寓話で私は何を言いたかったのでしょうか。鰻店の話では、オーナー企業の投げかけに対してA店側がどんな反応だったか描いていませんが、ネガティブな反応が出ることは想像に難くありません。職人が辞めるかもしれません。ではB社のアプローチは間違っているのでしょうか？データをもとに味を再現可能にする、目指すこととしてなんら間違ってはいませんね。では何が間違っていたのか。私は急激に変えようとし過ぎているところに問題があると思います。熟練技能者の意向を無視して、彼らの「技」をデータソースとしてしか捉えておらず、リスペクトがありません。いずれは熟練技能者が不在でも成立する世界観を確立するにしても、現状は匠が存在している以上、彼らの意思決定を支援する方向にこそデータドリブンアプローチは向いていると言えないでしょうか。それを表現したのが寓話2です。ここに出てくる戦闘民族は、自身の強さと言う絶対的な技能を持ちつつ、データをも手中にすることで、さらにその強さに磨きをかけることに成功していそうです。要は、 初めはデータを活用する主体を熟練技能者にする 受益者＝提供者から始める そこで得られた知見を再活用できるパイプラインを整える 情報を集約する ことが重要になってくるのではないでしょうか。 図1: 情報の集約順序と受益する順序 具体例 ： 設備保全技術者の悩み 寓話が続いたので、工場の生産設備の保全技術者を主役に据えて具体例でお話します。保全業務のミッションは、設備の稼働率と製品の品質を維持・向上することです。生産設備は通常、構造物やアクチュエータなどのメカ部品と、それを制御するためのプログラマブルロジックコントローラー（PLC）、PLC上で設備の動作を制御するラダープログラムなどで構成されます。優れた保全技術者は、自身が担当する設備のメカ・制御に精通し、必要に応じてその両方を改修する必要があります。いわゆる多能工ですね。前職で彼らの動きを実際に追いかけた経験があるのですが、何か設備に異常があって止まったときの集中力やスピード感、仮説検証の速さなどは目を見張るものがあります。まさに熟練技能者と言えるでしょう。その熟練技能者である保全技術者が、最も手を焼くトラブルはなんでしょうか？いくつかありますが、ここでは2つほど挙げてみましょう。1つ目は「ダンマリ停止」という現象です。一見すると、明らかなメカの破損があったり、PLCがエラーを発報しているわけではなく、ただ「止まっている」状態です。しかも、リセットして再起動すると正常に動いたりもする。それが散発的に起きるので、原因を追いにくいと言うわけです。2つ目は、長納期部品の破損トラブルです。設備を稼働させるために重要かつ長納期のメカ部品が壊れると、復旧に時間がかかり生産の影響が大きくなります。これらを工場長目線で見る場合には、どのラインがどれだけ稼働しているか、という情報が必要ですが、保全技術者は1つ1つの設備に対してアクションが必要なため、いつ・何が・どんな理由で止まったか、といったより具体的な情報が必要です。 図2: 設備の保全技術者は熟練技能者 解決策は？ それでは保全技術者の悩みをどのように解決すれば良いのでしょうか？ まずはダンマリ停止のような事象を正しく捉えることが先決です。特に複合設備で構成されるラインにおいては、停止の原因も様々です。例えば前工程からのワーク（製造品）が届かない「ワーク待ち」の状態や、後工程のサイクルタイムが何らかの原因で長くなり、ワークの渋滞で払い出せないなども考えられます。また、純粋にPLCのエラー検出ロジックに抜け漏れがあり、想定していない状態により停止することもあります。それらの状態を複合的に把握して「何が起きていたのか」を正しく捉えることが重要です。そのためには、各設備のPLCの情報を集約して一元化し可視化する、ときにはカメラなども有効活用して停止時の状態を捉える、などの仕掛けが必要となります。 AWS IoT SiteWise を用いると、PLC やセンサーなどの時系列情報の集約化・可視化が容易に行えます。動画の分析が必要な場合には、 Kinesis Video Streams を用いることで、クラウド上でデータの分析を行うことができます。重要部品の予知保全などに向けては、 Amazon Monitron を用いた回転機械の予知保全や、収集データを Amazon SageMaker で学習し独自の推論モデルをデプロイするなどの方策が考えられます。これらはもちろん、熟練技能者に還元できるデータ基盤ですし、さらにそのデータを集約することで、より上位のレイヤーでの意思決定にも使えるデータ群であるはずです。 図3: つながる工場のリファレンスアーキテクチャ 裾野から上位レイヤーへ こうして、熟練技能者に還元できるデータ活用の基盤を整えることは、そのまま工場長レベル、経営レベルのデータドリブンな意思決定を行うための礎になります。集めたデータを集約し、 Amazon QuickSight などで各レイヤーに必要な切り口で可視化することで、あらゆるレイヤーの意思決定に役立ちます。2023年の AWS Summit Tokyo で展示した 製造ダッシュボード は、キャッシュフローの観点から工場の健康状態を可視化する事例として開発しました。これらのデータソースには、当然ながら先述の製造現場の情報も含まれています。詳細は 別ブログ に譲りますが、現場のデータと基幹システムのデータを掛け合わせて、図5のような可視化を行うことができる、という事例として好評を得ました。 図4: 製造ダッシュボードの簡易アーキテクチャ図 図5: 現場レベルのデータと基幹システムデータを合わせた意思決定のための可視化の例 まとめ 今回は保全技術者を例に挙げて説明しましたが、他にも組立作業者や設備のオペレータ、検査員など、現場レベルでデータドリブンの恩恵を受けられる人たちは大勢いると思います。その人たちに、「上位の意思決定のためにデータを集めろ！」とトップダウンで落とすのではなく、彼らに恩恵のある形でデータ基盤を整えていくと、熟練技能者のクラフトマンシップという、日本の宝を傷つけることなく、「データドリブンとクラフトマンシップが交わる」と言えるのではないでしょうか。また、それらデータを現場に還元しつつ集約するパイプラインを整えることで、より全体最適に向けたデータドリブンな経営に歩を進めることができるのではないでしょうか。それこそが、データドリブンで先を行く海外製造業との差別化要因になると思います。 著者紹介 岩根 義忠 (Yoshitada Iwane) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 自動車メーカーの生産技術開発部門を経て AWS Japan に入社し、エンタープライズ事業本部でソリューションアーキテクトとして活動中。前職でソフトウェア開発のアジャイル/スクラムに出逢い、自部門での導入やスケールを主導したことにより、モダンな開発手法やクラウドに目覚める。 趣味はバイクの他にギター演奏、自分の部屋の飾り付けなど。二児の父だが二人とも実家を出ているため、現在は妻と気楽な二人暮らし。栃木県那須塩原市在住。 黒田 雄大 (Yuta Kuroda) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 自動車部品サプライヤーの生産技術部門、情報システム部門、Smart Factory プロジェクトを経て AWS Japan に入社。エンタープライズ事業本部でソリューションアーキテクトとして東海圏の製造業のお客様を中心に技術支援しています。

クラウド移行の停滞は、クラウド採用のビジネス価値を損なう可能性があります。したがって、早期警告サインに注意を払い、タイムリーに修正アクションを取ることが重要です。このブログ記事では、すべてのクラウド移行リーダーが認識しておくべき 5 つの大きな落とし穴について紹介します。これらの問題を早期に発見すれば、停滞を回避することができます。 落とし穴 #1: ステークホルダーの合意の欠如 進捗が順調でない兆候の 1 つは、移行の対象となる業務アプリケーションのリストが変わり続けていることです。一部のアプリケーション オーナー達は、自身のアプリケーションが移行の対象であることを十分に認識していない可能性があります。そのため、彼らは移行作業を保留にして、移行のタイミングを疑問視したり、追加の準備作業を要求したりします。こうした状況が積み重なり、プロジェクトスポンサーから進捗不足についてエスカレーションされた問い合わせが行われることがよくあります。この問題の根本的な原因は、通常、アプリケーションとビジネスチームからの賛同と合意形成の欠如にあります。明確なトップダウンの方針指示なしに、クラウド移行イニシアチブへの投資を行おうとしているためです。 これに対処するには、ビジネスによるスポンサーシップを優先し、プロジェクトのコミットメントを行う際は、アプリケーションおよびビジネスチームからの賛同を得ることが必要です。これを後回しにすると、解決するのがさらに困難になるでしょう。ビジネス成果を達成するための クラウド採用メリット を強調することにより、ビジネスチーム内でのコンセンサスを構築してください。また、クラウド移行するチームにインセンティブを提供することを検討してください。早期に移行するチームに対しては、最初の 6 ヶ月間のクラウドコストの配賦を免除する、といった方法があります。移行プロジェクトのスポンサーとなる上級役職者のリストを作成し、チームのサポートをコミットし、彼らがそれぞれの事業部門におけるプロジェクト完遂の責任を負っていることを明確にしましょう。 落とし穴 #2: 移行ウェーブの計画が常に変動している クラウド移行が停滞するもう 1 つの兆候は、移行ウェーブ (訳註：一つのグループとしてまとめて移行するサーバー群またはアプリケーション群) の計画が変わり続けている時です。適切に定義されたウェーブ計画は、アプリケーション間の依存関係に基づいて、各フェーズまたはウェーブで移行されるものを優先順位付けします。多数のアプリケーション グループによって使用される共有アプリケーションやサービスがある場合、ウェーブの範囲が大きくなり過ぎて一度にすべてを移行できなくなります。このような依存関係を後になって発見したチームは、通常、関連するすべてのアプリケーションを移行ウェーブから削除し、再計画のためにバックログに追加してしまいます。その結果、移行チームは効果的に利用されず、遅延とコスト超過を招きます。 プロジェクトスポンサーは、移行ウェーブの範囲縮小に疑問を抱き、過度に保守的なアプローチであるとみなして、移行速度を上げるようクラウド移行リーダーに圧力をかけます。この問題のよくある根本原因は、移行ウェーブの計画時にアプリケーションポートフォリオに関する十分なインベントリデータがないことです。 これを緩和するには、移行の開始時に、優先度の高いアプリケーションのチームとの設計レビューを実施します。 AWS Migration Hub を介する AWS ディスカバリツール (訳註：アプリケーションおよびサーバー情報の収集ツール) のような、 ツールベースのアプリケーションディスカバリプロセス を移行ウェーブ計画の前に実施してください。アプリケーションディスカバリの結果に基づいて、文書化され正式に拘束力のある プロジェクトベースライン を確立します。 変更を管理および監視し、ベースラインからの逸脱について早期にエスカレーションできるよう、正式な変更管理プロセスを実装します。 落とし穴 #3: 移行アプローチがアプリケーションによって異なる 移行プロセスにおける重要な懸念事項は、移行アプローチがアプリケーションごとに大きく異なる場合です。これにより移行方法論に一貫性がなくなり、チームが延々と議論を続けたり、設計上の決定を後から見直したり、決定済みの移行範囲を都合よく改変してしまったりすることになります。この落とし穴は、規模の経済や一貫した成果の達成を阻害するため、移行プロジェクトに重大な悪影響を及ぼします。クラウドへの移行に伴って技術的な最適化に過度に重点を置くと、移行の全体的な進行が遅くなります。また、元のビジネスケースで予測された価値を実現することも難しくなります。 この課題を克服するには、事前の対策が不可欠です。標準的な 移行アプローチ とターゲット アーキテクチャ パターンを定義して移行方法論を標準化し、スケールする基盤を構築します。また、合理化プロセスの一環として、共通の移行戦略に基づいてアプリケーションをグループ化します。 メインフレームアプリケーション のリファクタリングのような、かなりの変更を必要とするワークロードに対しては、ツールによる自動化を標準的に利用し、カスタマイズした移行作業をできるだけ減らします。停滞を避けるため、 一貫した設計決定アプローチ をクラウド移行の初期フェーズで確立してください。 落とし穴 #4: 効果の無いエスカレーション 移行が計画通りに進んでいない場合は、可視性とリーダーシップの支持を得るためのエスカレーションプロセスを用意することが不可欠です。プログラムマネジメント会議は、多くの場合、リーダーシップの助けを必要とするリスクや課題について話し合い、対処する場です。共有サービスチーム (訳注：認証機能やログ収集機能など、多くの業務アプリケーションが共通して利用するサービスの担当チーム) のリーダーなどの適切なステークホルダーがこれらの重要な会議に参加しないと、移行イニシアチブの進捗に悪影響を及ぼします。 したがって、プロジェクトのキックオフ前に包括的な コミュニケーション計画 と ガバナンス構造 を確立する必要があります。これにより、課題に十分な注意が払われ、障害を取り除くことができる適切な人物が会議に参加することを確実にできます。共有サービスチームと、緊急解決時間の定義や、ファイアウォール更新のような標準的なリクエストの受付担当者のアサインを交渉することも検討して下さい。これにより、移行チームはアジャイルスプリントでの作業を続けることができ、停滞を防ぐことができます。 落とし穴 #5: 移行に関する問題認識の遅れ 移行プロセスにおける問題表出の遅れは、懸念すべきことです。これはいくつかの症状から明らかになります。移行の進捗状況に関する極めて重要なアップデートが、プロジェクトリーダーに積極的に伝えられていない場合があります。実際に遅延が発生して初めて、問題に気づくということがよく起きているかもしれません。すると、プロジェクトスポンサーは、プロジェクトチームがクラウド移行を管理できているという信頼を失い始めます。問題が素早く対処されないため、ビジネス成果が達成できないリスクがあります。 これに対処するには、クラウド移行開始時の 移行統制メカニズム に対する合意が重要です。これらのメカニズムは通常、 効果的な設計決定アプローチ と 移行プロセス や ツール の確立、 ベースライン計画の作成 、移行チームの技術リーダーの任命、効果的な エスカレーションパス の構築を含みます。移行統制メカニズムは、監督の強化、課題の早期発見、移行の円滑化に役立ちます。 まとめ このブログ記事では、クラウド移行リーダーが注意すべき 5 つの重要な落とし穴に焦点を当てています。これらは、移行プロセスとビジネス成果の実現を妨げる可能性があります。クラウド移行のジャーニーを成功させるには、これらの落とし穴を早期に認識して対処することが不可欠です。よりスムーズな移行体験への道を開くための重要なポイントは次のとおりです。 移行プロジェクトのキックオフ前に、テクノロジーチームおよびビジネスチームと、移行に対するトップダウンの方針指示内容を確認する。 移行範囲のベースラインを作成し、プロジェクトの変更管理を正式化する。 移行に対するトップダウンの目標と技術戦略の整合性を取る。 プロジェクトの初日から効果的なエスカレーションパスを構築する。 移行を円滑に進めるための主要なプロジェクト管理メカニズムについて合意する。 さらなる学習リソース Guide for AWS large migrations Cloud migration health-check matrix How to migrate AWS Migration Acceleration Program Cloud-driven enterprise transformation on AWS 著者について Rostislav Markov Rostislav は AWS プロフェッショナルサービスのプリンシパルアーキテクトです。テクニカルリーダーとして、AWS のお客様やパートナーのクラウドトランスフォーメーションプログラムに取り組んでいます。仕事以外では、家族と屋外で過ごしたり、テニスをしたり、スキーを楽しんだりしています。 この記事はアマゾンウェブサービスジャパンの大塚信男が翻訳を担当しました。（オリジナルは こちら ）

この記事は、 Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3 を翻訳したものです。 多くの software-as-a-service (SaaS)アプリケーションはマルチテナントデータを Amazon Simple Storage Service(Amazon S3) に保存しています。Amazon S3 にマルチテナントデータを配置するには、バケットとキーにテナントデータをどのように分散させるかを考える必要があります。それは、SaaS ソリューションのセキュリティ、管理性、パフォーマンスを損なうことなく行う必要があります。 この記事では、Amazon S3 でテナントデータをパーティション化する際に適用できるさまざまな戦略を説明します。これらの戦略を自社のソリューションに適用する際に影響を与える可能性のある考慮事項を明示し、パーティション戦略がテナント分離と S3 オブジェクトへのアクセス制限にどのような影響を与えるかを見ていきます。 Amazon S3 データパーティション化 マルチテナントデータを表現するためのさまざまなアーキテクチャパターンを検討する際、そのデータをどう編成するか決める必要があります。このようなマルチテナントストレージメカニズムとパターンを通常、 データのパーティション化 と呼びます。 各 Amazon Web Services (AWS) ストレージ技術は通常、データパーティショニングモデルの独自のコレクションを持っています。これはソリューションのさまざまなニーズをサポートするためにテナントオブジェクトをどのように編成できるかを検討する際、 Amazon S3 においても言えることです。 どのパターンを選択するかは、いくつかの要因に影響を受けることに注意することが重要です。推定総テナント数、テナント環境の分離モデル、アプリケーションのアクセスパターンは、選択するオプションに影響を与える可能性のある考慮事項の 1 つです。 以下のセクションでは、一般的なマルチテナント S3 戦略を見ていき、これらの戦略がどんなケースでどのように適用されるかに焦点を当てます。 テナント専用バケットモデル (Bucket-Per-Tenant) テナントデータを Amazon S3 でパーティション化する最も単純なアプローチは、テナント毎に個別のバケットを割り当てることです。以下の図は、このモデルの例を示しています。 このアプローチでは、各テナントにデータを保持するバケットが割り当てられます。このバケットには、テナントと一意に結びつく名前が付けられます。 このモデルは、少数のテナント (数十または数百) を扱う場合にうまく機能します。しかし、はるかに多くのテナントをサポートする必要のある環境には適していません。Amazon S3 には、AWS アカウント毎にデフォルトで最大 100 バケットの制限があります (ハード制限は 1000) があります。 もう 1 つの考慮事項は、バケット名です。各 S3 バケット名はすべての AWS アカウント全体でグローバルに一意である必要があるため、テナント毎のバケットモデルではこの要件をサポートする命名規則が必要になります。 バケット名は公開されているため、一般にテナント固有の情報を含む名前は避けるべきです。 最後に、S3 バケット数の制限は、この SaaS アプリケーション固有のものではありません。他の環境 (本番、ステージング、開発) や専用のバケットを必要とする AWS サービスがクォータの一部を利用している可能性があります。 全体として、テナント毎のバケットモデルはシンプルですが、 SaaS 環境のスケールと俊敏性に影響を与える可能性のあることは明白です。 テナント毎のオブジェクトキープレフィックス モデル SaaS プロバイダーはテナント専用バケットモデルの制限を克服し、より大規模な展開を実現するために、キーのプレフィックスを使用してオブジェクトをテナントと関連付ける場合があります。このアプローチによりデータパーティション構造や編成を損なうことなく、はるかに大規模なテナントコレクションに拡張できます。 ここでは、 2 つのテナントが 1 つのバケットを共有しています。各テナントには、そのテナントに属するオブジェクトを識別する一意のプレフィックスがあります。幸いなことに、バケットに格納できるオブジェクト数やプレフィックス数には 制限がない です。 表面化する可能性のある課題の 1 つは、S3 キーに対する操作がテナント全体で均等に分散している可能性が低いことです。パーティション分割されたプレフィックス毎に、ソリューションは 1 秒間に数千のトランザクション を実現できます。個々のテナントのプレフィックスをシャーディングすることで、負荷をより分散させることができます。 データベースでマッピングしたテナントオブジェクト 場合によってはアプリケーションのオブジェクトアクセスパターンが S3 オブジェクトのパーティション分割方法の選択に影響することがあります。アプリケーション固有の基準 (たとえば、project-a に属する tenant-1 オブジェクトをすべて検索する) を満たすテナントのオブジェクトを検索したいシナリオを想像してみましょう。 ここでのアイデアは、検索可能な要素をデータベースに移動し、そのデータベースを検索して S3 オブジェクトへの参照を見つけ出す、ということです。以下の図は、このユースケースの例を示しています。 この例では、S3 オブジェクトのリクエストを処理するオブジェクトアクセスサービスを図に導入しました。このサービスは、アプリケーションで管理されているいくつかの基準に基づいて S3 オブジェクトをリクエストする機能をサポートするアプリケーションのマイクロサービスになります。 テナントはパラメーターを指定してリクエストを送信し、サービスは識別されたテナントとクエリに必要なパラメーター (ProjectID など) を含むデータベースにクエリを実行します。これらのパラメーターは、データベースをクエリして特定のテナントの S3 オブジェクトを参照するために使用されます。 データベースを使用して S3 オブジェクトへのアクセスを管理しているため、この例ではすべてのテナントの S3 オブジェクトをフラットな階層に混在して格納しています。これらのオブジェクトを常にデータベースから見ることができるのであれば、データベース内のテナント ID の列は、テナント ID に基づいて分離が適用されるパーティショニングモデルを表している可能性があります。これにより、S3 オブジェクトを、このマッピングデータベーステーブルを介してテナントに接続されたオブジェクトのグローバルプールとして保存できます。フラットな構造では、 リクエストスロットリング を避けるためにプレフィックスがランダムな固有のオブジェクトキーが必要です。 さらに、このアプローチは、テナントオブジェクトをプレフィックスで分割した、テナント毎のプレフィックスと組み合わせたハイブリッドモデルでもかまいません。その他に S3 オブジェクトタグを使用して、格納されている各オブジェクトにテナントのメタデータを追加する方法があります。 Amazon S3 オブジェクトのタグ付 けには追加料金がかかります。 顧客による直接アクセスや AWS サービス統合など、オブジェクトアクセスサービスの外部に他のアクセスパターンがある場合は、オブジェクトにキープレフィックスまたはタグを追加するとよいでしょう。 テナント分離 テナントの分離 は、すべての SaaS プロバイダーが対処しなければならない基本的なトピックの 1 つです。これは、あるテナントが別のテナントのリソースにアクセスできないようにするアーキテクチャの仕組みです。ここで障害が発生すると、SaaS ビジネスにとって重大で回復不能な事態になる可能性があります。 S3 データパーティション化のモデルを選択する際には、特定のパーティション化モデルがソリューションのテナント分離フットプリントにどのように影響するかも考慮する必要があります。テナント単位およびテナント単位のプレフィックス戦略では、テナント固有の AWS Identity and Access Management (IAM) ポリシーを定義できます。これにより、サービス固有の リソース、アクション、条件コンテキストキー を使用して、テナント間でリソースにアクセスできないようにすることができます。 さまざまなパーティション化モデルに使用される IAM ポリシーは、SaaS 環境のニーズとポリシーサイズ制限に基づいて、静的に作成することも、動的に生成することもできます。この戦略の詳細については、「 動的に生成された IAM ポリシーによる SaaS テナントの分離 」をご覧ください。 エンドポイントベースのパーティション化と分離 Amazon S3 アクセスポイント は、S3 オブジェクトへのアクセスを可能にする名前付きのネットワークエンドポイントです。これにより、S3 データを一連のバケットやキーと見なす必要がなくなります。代わりに、アクセスポイントを使用して各テナントのデータへのアクセスを制御することに焦点が移ります。デフォルトでは、1 つのアカウントに設定できるアクセスポイントのクォータは 1,000 個です。 この方法では、特定のテナントに関連付けられているオブジェクトへのアクセスを管理できるポリシーを使用して、個々のテナントのエンドポイントを定義できます。アクセスポイントは、S3 バケット名、オブジェクトキープレフィックス、またはオブジェクトタグ制限をサポートする静的に設定された IAM ポリシーを使用します。 これにより、テナントの分離を維持しながら、他の AWS サービスまたはアカウントから S3 オブジェクトにアクセスできます。アクセスポイントは AWS のサービスや機能の一部で動作しますが、すべてではありません。また、SaaS のお客様が自分の AWS アカウントから S3 オブジェクトに直接アクセスできるようにすることもできます。 暗号化キーによるテナントオブジェクトの保護 SaaS ソリューションの S3 パーティション化モデルは、追加のセキュリティ上の考慮事項の影響を受ける可能性があます。環境によっては、組織のコンプライアンスやデータ機密性のニーズにより、暗号化によるオブジェクトの保護をさらに強化する必要があります。 ここでは、各テナントに データを保護するキー をどのように提供できるかに重点をおきます。このようなシナリオでは、Amazon S3 を AWS Key Management Service (AWS KMS) と組み合わせて使用すると、S3 オブジェクトをサーバー側で暗号化できます。 採用した S3 パーティション化モデルは、キーの適用方法に影響します。たとえば、テナント単位のバケットモデルでは、バケット毎に固有の暗号化キーを割り当てることができます。 テナント毎のプレフィックスモデルでも、 エンベロープ暗号化 を使用してルート暗号化キーを共有し、各オブジェクトを個別に暗号化できます。エンベロープ暗号化とは、プレーンテキストデータをデータキーで暗号化し、そのデータキーをルートキーで暗号化することです。 アプリケーションコードがオブジェクトの書き込みリクエストを処理する場合、オブジェクトごとに暗号化に使用する AWS KMS キーを指定できます。AWS アカウントの各リージョンで、最大 10,000 個のカスタマー管理キーを使用できます。また、オプションでオブジェクト毎に追加の暗号化コンテキストを指定し、 認証化された暗号化 をサポートすることもできます。 AWS Key Management Service によるサーバー側の暗号化 (SSE-KMS) を使用すると、 Amazon S3 バケットキー により AWS KMS リクエストのコストを最大 99% 削減できます。この S3 バケットキーは S3 内で一定期間使用され、同じ AWS KMS キーで暗号化されたオブジェクトの S3 バケットキーのみが共有されます。これにより、KMS API のリクエスト数の制限を下回ることができます。 暗号化と IAM ポリシーは、全体的なセキュリティとテナント分離モデルの一部として組み合わせることができます。 テナントの活動と利用量 SaaS ソリューションは多くの場合、製品のコストが顧客の利用プロファイルに基づいて決定される従量課金制モデルで販売されます。テナントレベルでコスト情報を追跡することで、メータリングや価格設定を利用量ベースで決定できます。 テナント単位のバケットモデルでは、 コスト配分タグ を使用して個別の S3 バケットにラベルを付けることで、テナントのストレージコストを追跡できます。 テナント毎のプレフィックスアプローチでは、 Amazon S3 インベントリ を使用して S3 の利用量を追跡できます。これには、ソースバケット内のオブジェクトのリストと各オブジェクトのメタデータが含まれます。メタデータフィールドにはキー名とサイズが含まれます。ただし、インベントリリストにはオブジェクトタグは含まれていません。S3 バケットまたは共有プレフィックスのインベントリは、日単位または週単位で生成できます。 インベントリ完了時の Amazon S3 イベント通知 を設定できます。Amazon S3 インベントリには追加料金がかかります。 Amazon Athena を使用すると、 S3 インベントリをすばやく分析してクエリを実行する こともできます。Athena では実行したクエリに対してのみ支払いが発生し、各クエリでスキャンされたデータ量に基づいて課金されます。 サーバーアクセスログ は、S3 バケットに対して行われたリクエストの詳細な記録を提供します。これらのログを使用してテナントの API リクエストとデータ転送コストの両方に関する S3 請求額を分析できます。これは、Amazon Athena を使用して サーバーアクセスログの分析とクエリを行う ことができる一例です。ログレコードフィールドには、時間、バケット、キー、送信バイト数、オブジェクトサイズが含まれますが、オブジェクトタグは含まれません。 これらのログは ベストエフォート方式で配信 されることに注意してください。ログレコードが失われることはほとんどないですが、リクエストが実際に処理されてから特定のリクエストのログレコードの配信されるまで時間がかかることがあります。 ライフサイクル設定ルールの利用 Amazon S3 では、S3 オブジェクトの ライフサイクルを定義する こともできます。SaaS 環境ではテナント毎に (ティアやその他のアプリケーションに対する要件に基づいて) 異なるライフサイクルポリシーを提供することもできます。 これらの S3 ライフサイクル管理ルールを使用して、オブジェクトを別のストレージモデルに移行するタイミングがいつ期限切れになるか判断できます。たとえば、プレミアム階層のテナントには、基本階層のテナントとは異なる移行ルールが適用される場合があります。 ライフサイクルルールは、ライフサイクルルールで指定した <Filter> 要素に基づいて、バケット内のすべてまたは一部のオブジェクトに適用できます。キープレフィックス、オブジェクトタグ、またはその両方の組み合わせでオブジェクトをフィルタリングできます。S3 ライフサイクル設定には最大 1,000 個のルールを設定できますが、この制限は調整できません。 S3 バケットのその他の設定 Amazon S3 のセキュリティとアクセス管理 に関する AWS re: Invent 2021 セッションは、マルチテナントの SaaS アプリケーションで使用されているもの含め、すべての Amazon S3 バケットにおけるコストとセキュリティ管理に有益です。 Amazon S3 Intelligent-Tiering ストレージクラスは、アクセスパターンが変化すると、運用上のオーバーヘッドやパフォーマンスへの影響なしに、データを最も費用対効果の高いアクセス階層に自動的に移動することで、ストレージコストを最適化するように設計されています。 S3 バケットのアクセスコントロールリスト (ACL) を無効にすることをお勧めします。 アカウント管理者とバケット所有者は、 S3 Block Public Access を使用することで、リソースの作成方法に関係なく S3 リソースへのパブリックアクセス制限を簡単に一元管理できます。 まとめ Amazon S3 にマルチテナントデータを正しく保存することは、多くの SaaS アプリケーションにとって重要です。この記事では、データパーティション化の複数のオプションとその主な考慮事項について説明しました。アクセスポリシーや暗号化など、テナント分離をサポートする戦略を言及しました。 テナントのアクティビティとコストトラッキング、オブジェクトのライフサイクル管理、その他のバケットセキュリティ設定に関する関連情報も含まれています。 AWS SaaS Factory について AWS SaaS Factory は、SaaS 導入のどの段階の企業でも支援します。新製品の構築、既存のアプリケーションの移行、AWS 上での SaaS ソリューションの最適化など、どのようなご要望にもお応えします。 AWS SaaS Factory Insights Hub では、技術的、ビジネス的なコンテンツやベストプラクティスをご覧いただけます。 また、SaaS 開発者の方は、エンゲージメントモデルや AWS SaaS Factory チームとの連携について、アカウント担当者にお問い合わせください。 こちら にご登録いただくと、最新の SaaS on AWS ニュース、リソース、イベントの情報を入手できます。 翻訳はテクニカルソリューションアーキテクトの呉( @kkam0907 ) が担当しました。原文は こちら です。

この記事は An Overview of Bulk Sender Changes at Yahoo/Gmail (記事公開日: 2024 年 1 月 12 日) を翻訳したものです。 Gmail と Yahoo Mail は、ユーザーの受信トレイを保護するための取り組みとして、2024 年 2 月から送信者に関する新たな要件を発表しました。これらの要件を満たすために Amazon Simple Email Service (Amazon SES) を利用するお客様が具体的に何をすべきかを詳しく見ていきましょう。 新しいメール送信者の要件は何ですか? 新しい要件には、メールボックスプロバイダーへの良好な配信を実現するために、すべてのメール送信者が従うべき長年培われてきたベストプラクティスが含まれています。Gmail、Yahoo Mail、その他のメールボックスプロバイダーに対して、1 日に 5000 件を超える大量のメッセージ (バルクメール) を送信する場合や、多くのの受信者がそのメールを迷惑メールとして報告する場合に、これらのベストプラクティスに従う必要があるという点が新しい点です。 新しい要件は、1) ドメイン認証の厳守、2) バルクメールの購読を簡単に解除する方法の提供、3) 迷惑メールの苦情率を監視して 0.3% 未満に抑えるという 3 つのカテゴリに分類できます。 * このブログは元々 2023 年 11 月に公開されたもので、タイムラインを明確にし、その他のリソースへのリンクを提供するために 2024 年 1 月 12 日に更新されました。 1. ドメイン認証 メールボックスプロバイダーは、DKIM と SPF によるドメインに合わせた認証を要求し、メッセージの From ヘッダーで使用されるドメインに DMARC ポリシーを適用することを要求します。たとえば、 gmail.com は隔離を行う DMARC ポリシーを公開します。これは Gmail から送信されたと主張する不正なメッセージは、迷惑メールフォルダに送信されることを意味します。 SPF と DKIM のドメインアライメントについて理解を深め、ドメインの DMARC ポリシーから最大限の価値を引き出すには、 Amazon SES: Email Authentication and Getting Value out of Your DMARC Policy をご覧ください。 次のステップは、Amazon SES を利用するお客様がドメイン認証要件をどのように遵守できるかを概説したものです。 ドメイン ID の採用: 現在 Amazon SES で E メールアドレス ID を主に使用しているお客様は、メールボックスプロバイダーへの配信性を向上させるために、検証済みのドメイン ID を採用する必要があります。SES で 検証済みのドメイン ID を使用すると、メッセージにはドメインに合わせた DKIM 署名が付きます。 どのドメインを使うべきかわかりませんか？認証済み E メールの送信に関するその他のベストプラクティスガイダンスについては、 Choosing the Right Domain for Optimal Deliverability with Amazon SES を参照してください。 カスタム MAIL FROM ドメインの設定: ベストプラクティスにさらに沿うために、SES を利用するお客様は SPF がドメインにアライメントするように カスタム MAIL FROM ドメインも設定する必要があります。 以下の表は、Amazon SES で使用する ID のタイプに基づいた 3 つのシナリオを示しています。 From ヘッダーに example.com を使用するシナリオ DKIM で認証される ID SPF で認証される ID DMARC 認証の結果 検証済みのメールアドレス ID として foo@example.com を使用 amazonses.com email.amazonses.com 失敗 — 送信ドメインに一致する DKIM 署名または SPF レコードがないため、DMARC 認証が失敗します。 検証済みドメイン ID として example.com を使用 example.com email.amazonses.com 成功 — DKIM 署名が送信ドメインと一致しているため、DMARC 認証に合格します。 検証済みドメイン ID として example.com 使用し、カスタム MAIL FROM ドメインとして bounce.example.com を使用 example.com bounce.example.com 成功 — DKIM と SPF は送信ドメインと一致しているため合格します。 表 1: Amazon SES で使用される ID のタイプに基づく 3 つのシナリオ。検証済みのドメイン ID を使用し、なおかつカスタム MAIL FROM ドメインを設定すると、DKIM と SPF の両方が From ヘッダードメインの DMARC ポリシーに準拠することになります。 サブドメインを戦略的に使用する: Amazon SES を利用するお客様は、さまざまな E メール送信のユースケースに応じて、From ヘッダーで使用されるドメインとサブドメインへの戦略的なアプローチを検討する必要があります。例えば、マーケティングメールの送信には 検証済みドメイン ID marketing.example.com を使用し、トランザクションメールの送信には 検証済みドメイン ID receipts.example.com を使用するといった具合にです。 なぜドメインを区別するのでしょうか? マーケティングメッセージは迷惑メールの苦情率が高くなる場合があり、一括送信者の要件を満たす必要がありますが、購入領収書などのトランザクションメールでは、必ずしもバルクメールに分類されるほど迷惑メール苦情が多くなるとは限りません。 DMARCポリシーを公開する: ドメインの DMARC ポリシーを公開します。メッセージの From ヘッダーに使用するドメインには、DNS 内のドメインの DMARC ポリシーに p= タグを設定したポリシーが必要です。このポリシーは「p=none」に設定することで一括送信の要件を満たすことができます。そのドメインを使用するすべての E メールが DKIM または SPF ドメインに整合する認証済み識別子で認証されたことを確認したら、後で隔離 (p=quarantine) または拒否 (p=reject) に変更できます。 2. E メール受信者が簡単に配信停止できるように設定する 一括送信者には、メッセージ内に見つけやすいリンクを追加して購読を解除するメカニズムを含めることが期待されます。2024 年 2 月から適用されるメールボックスプロバイダーのルールでは、送信者は RFC 2369 と RFC 8058 で定義されているワンクリック購読解除ヘッダーを追加することが要求されます。これらのヘッダーを使用すると受信者が簡単に購読を解除できるようになり、受信者がメッセージを迷惑メールとしてマークして苦情を申し立てる頻度が減ります。 メールボックスプロバイダーがバルクメールと判断する要因は様々です。1 日あたり 5,000 件を超える量も 1 つの要因ですが、メールボックスプロバイダーが使用する主な要因は、受信者が本当にそのメールを受け取ることを望んでいるかどうかです。 メールがバルクと見なされるかどうかわからない場合は、迷惑メールの苦情率を監視してください。苦情率が高い場合や増え続けている場合は、受信者が簡単に購読を解除できる方法を提供する必要があることを示しています。 簡単に購読解除を行えるようにする要件を順守する方法 次のステップは、Amazon SES を利用するお客様が簡単に購読解除できる要件を満たす方法をまとめたものです。 送信するメッセージにワンクリック購読解除ヘッダーを追加する: Amazon SES を利用するお客様が、大量または迷惑と思われる可能性のあるメッセージを送信する場合には、受信者が簡単に購読を解除できる方法を実装する必要があります。これには SES の 購読管理機能 を使用することができます。 メールボックスプロバイダーは、一括送信者に対し、受信者がワンクリック購読解除ヘッダーを使用してワンクリックでバルクメールの購読を解除できるようにすることを要求しています。ただし、メッセージ内の購読解除リンクを使用して、受信者がオプトアウトの設定を行うためのランディングページに受信者を誘導してもかまいません。 SES の購読管理機能を使用せずにワンクリック購読解除を設定するには、送信メッセージに次の両方のヘッダーを含めてください: List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: <https://example.com/unsubscribe/example> 受信者がワンクリックで購読を解除すると、次の POST リクエストが届きます: POST /unsubscribe/example HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Content-Length: 26 List-Unsubscribe=One-Click Gmail の FAQ と Yahoo の FAQ はどちらも、一括送信者が各メッセージのフッターに、機能する登録解除リンクを明確に表示している限り、ワンクリックの登録解除要件は 2024 年 6 月まで適用されないことを明確にしています。 配信停止リクエストを 2 日以内に受け付ける: 購読解除手続きを行うと、受信者が今後同様のメッセージを受信しなくなることを確認してください。メールボックスプロバイダーは、一括送信者が受信者にワンクリックで E メールの購読を解除できるようにすること、および送信者が購読解除要求を 2 日以内に処理することを要求しています。 SES の購読管理機能を採用する場合は、受信者のオプトアウト設定をメール送信リストのソースと必ず統合してください。独自のワンクリック購読解除を実装する場合 (Amazon API Gateway と AWS Lambda 関数を使用する場合など) は、ソースとなるメーリングリストからその E メールアドレスへの送信が抑制するように設計されていることを確認してください。 メーリングリストの作成方法を見直す: メーリングリストの購入を控えること、オプトインフォームをボットの悪用から保護すること、確認メッセージで受信者の好みを確認すること、要求されていないカテゴリに受信者を自動的に登録しないようにすることなど、責任ある E メールの取り扱いを行ってください。 新しく義務付けられたベストプラクティスを順守する前に、迷惑メールの苦情率が高くならないようにするには、メーリングリストのオプトインを適切に行うことが最善の方法です。詳細については、 What is a Spam Trap, and Why You Should Care をご覧ください。 3. 迷惑メール率を監視する メールボックスプロバイダーは、自分の E メールがメールボックスプロバイダーによって迷惑メールとして扱われないように、すべての送信者に迷惑メールの苦情率を 0.3% 未満に抑えるよう要求します。次のステップは、Amazon SES を使用するお客様が迷惑メール苦情率の要件を満たす方法をまとめたものです。 Google ポストマスターツールへの登録: Amazon SES を利用するお客様は、Gmail 受信者に対する迷惑メールの苦情率を監視するために Google ポストマスターツール に登録することが推奨されます。 Gmail では、迷惑メールの苦情率を 0.1% 未満に抑えることを推奨しています。Gmail の受信者と他のメールボックスプロバイダーの受信者が混在して送信する場合、Gmail の Postmaster Tools によって報告される迷惑メール苦情率は、指標を確認できないメールボックスプロバイダーでの迷惑メール苦情率を示す良い指標となります。 Amazon SES の Virtual Deliverability Manager を有効にする: Amazon SES アカウントで Virtual Deliverability Manager (VDM) を有効にします。お客様は VDM を使用して、多くのメールボックスプロバイダーのバウンス率と苦情率をモニタリングできます。Amazon SES では、 レピュテーションメトリクスを監視し、苦情率を 0.1% 未満に抑えること をお客様に推奨しています。 設定セットを使用して送信を分離し保護する: Amazon SES を利用するお客様は、送信ユースケースをドメインごとに分離することに加えて、送信ユースケース毎に異なる 設定セット を使用することが推奨されます。 設定セットを使用すると、よりきめ細かく 送信アクティビティをモニタリング し、 制限を実装 できます。迷惑メールの苦情率が許容範囲を超えた場合は、 設定セットを使用する送信を自動的に一時停止する こともできます。 まとめ これらの変更は 2024 年 2 月に予定されていますが、各メールボックスプロバイダーが変更を適用する正確なタイミングと方法は異なる場合があることに注意してください。2 月より前にいずれかのメールボックスプロバイダーで配信に関する問題が発生した場合は、最初のステップとしてこれらの必要なベストプラクティスを順守することが最善の方法です。 このブログが、この変更に関して混乱している部分を明らかにし、2024 年 2 月に向けて準備しておくべき情報を皆様に提供できることを願っています！ 参考リンク: Gmail のお知らせ: https://blog.google/products/gmail/gmail-security-authentication-spam-protection/ Yahoo のお知らせ: https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-less-spam DMARC ポリシーに関するブログ: Amazon SES: Email Authentication and Getting Value out of Your DMARC Policy 適切なドメインの選択に関するブログ: Choosing the Right Domain for Optimal Deliverability with Amazon SES 翻訳はクラウドサポートエンジニアの富岡が担当しました。原文は こちら です。

はじめに Amazon Elastic Cotainer Service (Amazon ECS) は、AWS 上で毎週何十億ものアプリケーションコンテナのライフサイクルを管理しているコンテナオーケストレーションサービスです。Amazon ECS の主な目標の 1 つは、運用者にかかる諸々の負担を取り除くことです。Amazon ECS はアプリケーションコンテナを 24 時間 365 日監視し、予期しない変化に人間よりも迅速かつ適切に対応できます。Amazon ECS は、アプリケーションコンテナのデプロイを継続的に自己修復してあるべき状態に戻すことで、アプリケーションのクラッシュやハードウェア障害などの望ましくない変更に対応します。また、トラフィックの急増など、アプリケーションが停止する原因となる外部要因もあります。こうした要因には対処が難しい場合があります。この投稿では、Amazon ECS がタスクの正常性の問題とタスク置換を処理する方法に最近加えられた変更と、これらの変更によって Amazon ECS でオーケストレーションされたアプリケーションの可用性がどのように向上するかについて詳しく説明します。 タスクの正常性評価 Amazon ECS はいくつかの基準に基づいてタスクの正常性を評価します。 まず、タスクが正常であるためには、必須とマークされているすべてのコンテナが実行されている必要があります。すべての Amazon ECS タスクには、少なくとも 1 つの必須コンテナが必要です。ベストプラクティスに則ったコンテナは 1 つのアプリケーションプロセスを実行し、重大なランタイム例外によってそのプロセスが終了すると、コンテナは停止します。停止したコンテナが必須とマークされていた場合は、タスク全体が正常でないと見なされ、タスクを置き換える必要があります。 Amazon ECS タスク定義を使用して、Amazon ECS エージェントがコンテナ内で定期的に実行する内部ヘルスチェックコマンドのオプションを設定できます。このコマンドは、成功を示す終了コード 0 を返すことが期待されています。0 以外の終了コードが返された場合は、失敗したことを意味します。その場合コンテナは異常と見なされます。必須コンテナに異常があるためタスクも異常と見なされ、Amazon ECS がタスクを置き換えます。 Amazon ECS サービスを使用して、アプリケーションコンテナと他の AWS サービスとの間のアタッチメントを設定できます。たとえば、コンテナデプロイを Elastic Load Balancing ( ELB ) または AWS Cloud Map に関連づけることができます。これらのサービスは独自の外部ヘルスチェックを行います。たとえば、ELB は定期的にコンテナへの接続を開いてテストリクエストを送信しようとします。その接続を開くことができない場合や、コンテナが予期しない応答を返した場合、またはコンテナの応答に時間がかかりすぎる場合、ELB はターゲットコンテナが異常であると見なします。Amazon ECS は、Amazon ECS タスクが正常か異常かを判断する際に、この外部のヘルスステータスも考慮します。ELB ヘルスチェックに異常があると、タスクは置き換えられます。 タスクが正常であるためには、すべてのヘルスステータスのソースが正常と評価されなければなりません。いずれかのソースが異常ステータスを返した場合、Amazon ECS タスクは異常と見なされ、置き換えられます。 タスク置換動作 Amazon ECS タスクの置換は、主に次の 2 つの状況で行われます。 UpdateService API コールによって新しいデプロイがトリガーされる場合。以前のデプロイに含まれる既存のタスクを、新しいデプロイに含まれる新しいタスクに置き換える必要があります。 アクティブなデプロイの内、既存のタスクに異常が生じた場合。正常なタスクの数を維持するには、異常なタスクを置き換える必要があります。 Amazon ECS は黎明期から、ローリングデプロイ中のタスク置換の動作については、Amazon ECS サービスの 2 つのプロパティを使用して設定可能でした。 maximumPercent – これにより、Amazon ECS がサービスの希望するタスク数を超えて起動できる追加タスクの数がコントロールされます。たとえば、 maximumPercent が 200% で、サービスの希望するタスク数が 8 タスクの場合、Amazon ECS は合計で 16 タスクまで追加タスクを起動できます。 minimumHealthyPercent – これにより、デプロイ中に Amazon ECS サービスの希望するタスク数を下回ることが許される割合がコントロールされます。たとえば、 minimumHealthyPercent は 75% で、サービスに必要なタスク数は 8 タスクとします。その場合、Amazon ECS は 2 つのタスクを停止して、サービスのデプロイメントを実行中のタスクを 6 つに減らすことができます。 maximumPercent と minimumHealthyPercent は、Amazon Elastic Compute Cloud ( Amazon EC2 ) 上で Amazon ECS タスクを実行するときに、ローリングデプロイの動作を微調整するための効率的な制御として長年機能してきました。しかし、これらのデプロイコントロールは、ますます多くの Amazon ECS ユーザーがサーバーレスの AWS Fargate を選択している世界ではあまり意味がありません。AWS Fargate の使用率は、クラスターに登録した Amazon EC2 インスタンスの数によって制約されないため、モダンアプリケーションではローリングデプロイ中に実行タスク数が希望する数を下回ったり、起動される追加タスクの数を減らしたりすることを Amazon ECS に要求する必要がありません。 さらに、問題のあるタスクを置き換えるという点では、もともと maximumPercent と minimumHealthyPercent によるコントロールは無視されていました。タスクが異常になると、サービスの必要数が minimumHealthyPercent で定義されたしきい値を大幅に下回る可能性があります。たとえば、8 つのタスクを実行していて、そのうちの 4 つに異常が生じた場合、Amazon ECS は 4 つの異常なタスクを終了し、4 つの代替タスクを起動します。実行中のタスクの数は、一時的に必要な数の 50% まで下がってしまいます。 Amazon ECS による異常なタスクの置き換え方法がアップデートされました 2023 年 10 月 20 日より、Amazon ECS は異常なタスクを置き換えるときに可能な限り maximumPercent を使用するようになりました。この仕組みを理解するために、いくつかのシナリオを見てみましょう。 タスクのクラッシュ あなたは希望するタスク数が 8 つ、最大パーセントが 200% のサービスを実行しています。8 つのタスクのうちの 4 つに重大な実行時例外が発生しています。そのプロセスがクラッシュして終了し、重要なコンテナが終了してしまいました。Amazon ECS は、必須コンテナが終了したことで 8 つのタスクのうちの 4 つに異常が発生したことを観測しました。残念なことに、異常なコンテナがクラッシュしたため、Amazon ECS の正常稼働率が 100% を下回ることを避けられません。実行中タスクの数は一時的に希望の数の 50% まで下がりますが、Amazon ECS は実行中タスクの数を希望の 8 タスクに戻すために、できるだけ早く 4 つの代替タスクを開始します。 フリーズされたタスク あなたは希望するタスク数が 8 つ、最大パーセントが 200% のサービスを実行しています。コード内の無限ループが原因で、8 つのタスクのうちの 4 つはフリーズしますが、プロセスは実行されたままです。アタッチされたロードバランサーはサービスにヘルスチェックリクエストを送信し、ターゲットコンテナがヘルスチェックリクエストに応答しなくなったため、ターゲットに異常があるとマークしました。Amazon ECS は、これら 4 つのフリーズされたタスクを異常と見なします。サービスの最大パーセントでは、最大 16 個のタスクを処理できます。Amazon ECS は、異常な 4 つのタスクに対する 4 つの代替タスクを起動し、実行中タスクは合計 12 個になります。追加した 4 つのタスクが正常になると、Amazon ECS は異常な 4 つのタスクを停止します。これにより、実行中のタスク数は必要な 8 タスクに戻ります。 過負荷のタスク あなたは希望するタスク数が 8 つ、最大パーセントが 150% のサービスを実行しています。サービスには Auto Scaling ルールがアタッチされています。また、ロードバランサーも接続されており、ロードバランサーを経由して大量のトラフィックが流入します。トラフィックが急増するため、タスクからの応答時間が大幅に遅くなります。応答時間が遅くなると、ロードバランサーのヘルスチェックが失敗し、ELB は 8 つのターゲットすべてを異常とマークします。ELB は正常なターゲットがないため オープンに失敗 し、すべてのターゲットにトラフィックを分散し続けます。 Amazon ECS は、8 つのタスクすべてが正常でないことを観測します。そして、Amazon ECS はこれらの異常なタスクを置き換えようとします。最大パーセントを 150% に設定すると、サービスは最大 12 個の実行中タスクを起動できます。そのため、Amazon ECS は異常な実行中タスクを直ちに停止することはしません。代わりに、既存の 8 つの正常でないタスクと並行して 4 つの代替タスクを起動します。幸いこれらの 4 つの追加タスクにより、ELB はより多くのターゲットにトラフィックを分散できるようになります。実行中の 12 個のタスクはすべてタイムアウトすることなく受信トラフィックを処理できるようになり、正常性が安定します。Amazon ECS は、正常に実行されているタスクが 12 個であることを観測します。 同時に、元の 8 つの実行中タスクの CPU 使用率が高いことが観測されたことに基づいて、アプリケーションの Auto Scaling ルールが実行されました。このルールにより、Amazon ECS サービスに必要な実行中タスクの数が 8 個から 10 個に更新されました。そのため、Amazon ECS は 12 個の正常に実行されているタスクのうちの 2 つだけを停止します。これにより、タスク数は必要な実行中タスク数である 10 個まで減少します。 制限された最大パーセント あなたは必要なタスク数が 8 つのサービスを実行していますが、ダウンストリームの制限またはインフラストラクチャの制約により、最大パーセントを 100% に設定しています。これでは、実行中の 8 つのタスクと並行して、Amazon ECS が追加のタスクを起動することはできません。このデプロイのタスクがフリーズしたり、過負荷になってヘルスチェックに失敗し始めたら、Amazon ECS はそのタスクを置き換える必要があります。Amazon ECS はまず異常なタスクを停止し、異常なタスクが停止された後に代替タスクを起動します。つまり、実行中のタスク数は依然として一時的に必要な数を下回っています。 ローリングデプロイ中にタスクがヘルスチェックに失敗 あなたは希望するタスク数が 8 つ、最大パーセントが 150% のサービスを実行しています。ローリングデプロイを行い、新しいタスク定義に基づいて実行中タスクを更新しました。最大パーセントは 150% なので、Amazon ECS は現在実行中のタスクと並行して追加のタスクを起動できます。ローリングデプロイでは、すでに 4 つの追加タスクの起動がトリガーされています。現在、このサービスには 12 個の実行中タスク (8 個の古いタスクと 4 つの新しいタスク) があります。 このローリングデプロイの最中に、予期しないバグが原因で、古いタスクの一部がヘルスチェックに失敗してしまいました。アクティブなローリングデプロイが行われているため、Amazon ECS は異常なタスクを直ちに終了し、できるだけ早く新しいタスクのインスタンスに置き換えます。ローリングデプロイ中、Amazon ECS は常に失敗したタスクを新しいアクティブなデプロイのタスクに置き換えようとします。 外部要因による継続的なタスク障害 あなたは希望するタスク数が 8 つ、最大パーセントが 150% のサービスを実行しています。コードが依存しているダウンストリームサービスの 1 つが予期しない応答を返し始め、その結果、コードがヘルスチェックに失敗し始めました。Amazon ECS は 8 つのタスクに異常があり、置き換える必要があると判断したため、8 つの初期タスクと並行して、4 つの代替タスクを追加で起動します。この時点で、12 個のタスクが実行されています。8 個は元のタスク、4 個は代替タスクです。残念ながら、代替タスクは元のタスクと同じ信頼性の低いダウンストリームサービスに依存しているため、12 個のタスクはすべて正常ではありません。 代替タスクが安定せず、Amazon ECS は異常なタスクの数がサービスに必要な数よりも多いと判断したため、異常なタスクの数を必要な数に戻すために、異常なタスクの 4 つをランダムに停止します。Amazon ECS は、問題のあるタスクのうちどのタスクが「元のタスク」で、どのタスクが「代替タスク」であったかについて、ステートフルな情報を保持していません。異常なタスクが十分に停止され、さらにタスクを追加する余地ができたら、ECS は代替タスクを再び開始しようとします。これは、ダウンストリームのサービスが再び信頼できる状態になるか、障害状態をより適切に処理するコード更新が UpdateService API 呼び出しによってロールアウトされるまで、無限に続きます。 ヘルスチェックとワークロードの急増への迅速な対応 以前は、Amazon ECS は常に異常なタスクを最初に停止し、次に代替タスクを起動していました。この動作は、既存のタスクを停止せずに代替タスクを起動する余地がない、静的なサイズの Amazon EC2 インスタンスからなるクラスターにタスクが密集して binpack ( タスク配置戦略 の 1 つ) されている世界では理にかなっています。しかし、最近では、サーバーレスの AWS Fargate キャパシティーを使用して実行されているコンテナワークロードが増えています。AWS Fargate は必要に応じてオンデマンドのコンテナ容量を提供できるため、実行中タスクを中断して代替タスクのための余地を作る必要はありません。さらに、Amazon EC2 上で Amazon ECS を利用しているお客様の多くは、Amazon EC2 インスタンスからなる静的なサイズを持つクラスターにデプロイするのではなく、Amazon ECS キャパシティプロバイダーを利用してオンデマンドで追加の Amazon EC2 インスタンスを起動するようにしています。そのため、現在 Amazon ECS ではサービスの maximumPercent の使用を優先し、代替タスクが正常になるまで異常なタスクを可能な限り実行し続けます。 さらに、Amazon ECS の新しいタスク置換動作により、高負荷なタスクが終了するのを防ぐことができます。ワークロードが急増すると、場合によってはデプロイの内のいくつかのタスクが異常になり、その結果タスクが置き換えられてしまいます。しかし、Amazon ECS が代替タスクを起動するために異常なタスクを停止すると、ロードバランサーは残りの正常なタスクに多くのワークロードを移してしまい、その結果、それらのタスクは異常な状態になります。短時間のうちに、全ての正常なタスクに負荷がかかると、ヘルスチェックの失敗が次々に発生し、すべてのタスクに異常が生じてしまいます。 最終的には、アプリケーションの Auto Scaling ルールが実行され、デプロイメントがワークロードを処理するのに十分なサイズにスケールアップされます。しかし、ほとんどの場合、トラフィックが急増すると集計されたリソース消費量に基づくオートスケールがトリガーされる前に、ロードバランサーのヘルスチェックが失敗します。Auto Scaling ルールは、コンテナデプロイメントをスケールアウトして対応する前に、少なくとも 1 分間の高い平均リソース使用率を監視する必要があります。ただし、過負荷のタスクでは、ロードバランサーのヘルスチェックがすぐに失敗する可能性があります。 大量のワークロードを処理しているためにタスクが正常でないシナリオでは、Amazon ECS の新しいタスク置換動作により、サービスの可用性と信頼性が大幅に向上します。Amazon ECS はヘルスチェックの失敗を検知し、Auto Scaling ルールがトリガーされる前に、入ってくるワークロードの急増に対応できるようにするための代替タスクを事前に並行起動します。Auto Scaling ルールがトリガーされると、代替タスクと元のタスクの両方が正常でサービスの現在の必要なタスク数を満たしていれば、両方のタスクを保持します。 結論 この投稿では、異常なタスクを処理するときの Amazon ECS の新しい動作について説明しました。ミッションクリティカルなアプリケーションに Amazon ECS を採用するお客様が増えるにつれ、私たちは常に困難で新しいオーケストレーション問題に大規模に取り組むことに喜びを感じています。この最新のタスク置換動作は、規模の大小を問わずお客様のニーズに応えられるように設計されています。これにより、アプリケーションの障害やトラフィックの急増などの不利な状況でも、コンテナのデプロイメントをオンラインかつ可用性の高い状態に保つことができます。 Amazon ECS の今後の追加機能の詳細や、独自の課題を作成して変更や新機能をリクエストするには、 Amazon ECS パブリックロードマップ をご覧ください。 Amazon ECS スケジューラーの動作の詳細については、公式ドキュメントの サービススケジューラーの概念 を参照してください。 本記事は A deep dive into Amazon ECS task health and task replacement (2023 年 11 月 3 日公開) を翻訳したものです。翻訳は、ソリューションアーキテクトの吉田が担当しました。

この記事は Amazon EKS extended support for Kubernetes versions pricing (記事公開日: 2024 年 1 月 16 日) を翻訳したものです。 Introduction 2023 年 10 月 4 日、 Amazon Elastic Kubernetes Service (Amazon EKS) は、Kubernetes バージョンに対する延長サポートの パブリックプレビューを発表 しました。これは Kubernetes のマイナーバージョンのサポート期間を 12 ヶ月延長します。そして本日、延長サポートの料金設定を発表します。延長サポート期間中の Kubernetes バージョンを実行している Amazon EKS クラスターは、クラスターあたり 0.60 USD / 1 hour の料金が発生します。この料金は 2024 年 4 月の請求サイクル (2024 年 4 月 1 日開始) から適用されます。標準サポート期間中の Kubernetes バージョンを実行しているクラスター料金の変更ありません。引き続き、クラスターあたり 0.10 USD / 1 hourの料金が適用されます。 この価格設定には、Kubernetes のコントロールプレーンを実行するためのコストが含まれています。別途、Kubernetes のワーカーノードを実行したり、その他のクラスター機能をサポートするために作成する AWS リソース (Amazon Elastic Compute Cloud [ Amazon EC2 ] インスタンス、 AWS Fargate 、Amazon Elastic Block Store [ Amazon EBS ] ボリューム、 AWS Outposts キャパシティなど) の料金も発生します。使用した分だけ支払う方式で、最低料金はなく、前払いのコミットメントもありません。 Amazon EKS では、Kubernetes バージョン 1.23 以降のバージョンに対して延長サポートが利用できます。各バージョンの標準サポート期間と拡張サポート期間は、Amazon EKS の リリースカレンダー を参照してください。 Kubernetes バージョンに対する Amazon EKS の延長サポートとは何ですか? Amazon EKS の延長サポートは、Kubernetes のマイナーバージョンが Amazon EKS で利用開始になった時点から最大 26 ヶ月間のサポートを提供します。Amazon EKS の延長サポート期間中のバージョンは、Amazon EKS が管理する Kubernetes コントロールプレーンの継続的なセキュリティパッチを受け取ります。さらに、Amazon EKS は Amazon VPC CNI、kube-proxy、CoreDNS アドオン、AWS が提供する Amazon EKS 最適化 Amazon Linux AMI、Bottlerocket、Amazon EKS 最適化 Windows AMI、Amazon EKS Fargate ノードの重要なパッチをリリースします。 (注: AWS が提供する Amazon EKS 最適化 Windows AMI のサポートは、Kubernetesバージョン 1.24 以降で利用できます)。 AWS は、標準サポートまたは延長サポート両方で提供されるすべての Amazon EKS バージョンを完全なテクニカルサポートでバックアップします。Kubernetes バージョンの延長サポートは、Amazon EKS が利用できるすべての AWS リージョン ( GovCloud (US) リージョン含む) で利用できます。 Amazon EKS バージョンはいつ標準サポートまたは延長サポートの対象になりますか? 標準サポートは Kuberenetes バージョンが Amazon EKS で利用可能になった時点から開始され、アップストリームの Kubernetes のマイナーバージョンサポート期間と同様に 14 ヶ月間継続します。Amazon EKS の延長サポートは、標準サポートが終了した直後から開始され、12 ヶ月間継続します。Kubernetes のバージョン 1.23 以降は、Amazon EKS の延長サポートの対象となります。 延長サポートにはどれくらいの費用がかかりますか? Amazon EKS クラスターの実行コストはコントロールプレーンの Kubernetes マイナーバージョンに基づいています。Amazon EKS クラスターで標準サポートの Kubernetes バージョンを実行している場合、クラスターあたり 0.10 USD / 1 hour の料金をお支払いいただきます。Amazon EKS クラスターで延長サポートの Kubernetes バージョンを実行している場合、クラスターあたり 0.60 USD / 1 hour の料金 をお支払いいただきます。 延長サポートの仕組みをわかりやすく説明するシナリオをいくつか紹介します Amazon EKS クラスターが大量にあり、それらが異なる Kubernetes バージョンが実行されている場合、標準サポートのバージョンを実行しているクラスターにはクラスターあたり 0.10 USD / 1 hour が請求され、延長サポートのバージョンを実行しているクラスターには、クラスターあたり 0.60 USD / 1 hour が請求されます。 延長サポート対象の Kubernetes バージョンを使用して新しい Amazon EKS クラスターを作成する場合、0.60 USD / 1 hour を支払うことになります。 延長サポートの Kubernetes バージョンを使用して Amazon EKS クラスターを実行していて、そのクラスターのコントロールプレーンを標準サポートの Kubernetes バージョンにアップグレードする場合、アップグレード前にクラスターが延長サポートバージョンを実行していた時間に対して 0.60 USD / 1 hour 、アップグレード後は 0.10 USD / 1 hour を支払うことになります。 標準サポート期間と延長サポート期間での Amazon EKS の請求を説明する例をいくつか示します。 例 1: Amazon EKS が Kubernetes の新しいバージョンをリリースしたその日に、そのバージョンの Amazon EKS クラスターを作成し、コントロールプレーンのバージョンをアップグレードせずにそのクラスターを 26 か月間実行するとします。バージョンが標準サポートの対象となる最初の 14 か月間は、 0.10 USD / 1 hour を支払うことになります。14 か月後、Kubernetes バージョンは延長サポートに移行します。これで、残りの 12 か月間は 0.60 USD / 1 hour を支払うことになります。26 か月間のこのクラスターの実行には、平均して 0.33 USD / 1 hour を支払うことになります。 サポートタイプ 利用期間 (月) 料金 (クラスター 1 hour あたり) 標準サポート 14 0.10 USD 延長サポート 12 0.60　USD 26 か月間のサポートの平均費用 0.33 USD   例 2: 標準サポート期間を 4 ヶ月経過した Kubernetes のバージョン (つまり、そのバージョンの標準サポート期間が残り 10 ヶ月) で Amazon EKS クラスターを作成したとします。このバージョンの標準サポートが終了し、次の標準サポートの対象となる次のバージョンにアップグレードする前に、6 か月間の延長サポートを利用することにしました。このクラスターを実行した 16 か月間は、最初の 10 か月は 0.10 USD / 1 hour、残りの 6 か月は 0.60 USD / 1 hour を支払います。このクラスターを 16 か月間実行するには、平均して 0.29 USD / 1 hour を支払うことになります。 (注: クラスターを標準サポートの Kubernetes バージョンにアップグレードすると、請求額はクラスターあたり 0.10 USD / 1 hour に戻ります)。 サポートタイプ 利用期間 (月) 料金 (クラスター 1 hour あたり) 標準サポート 10 0.10 USD 延長サポート 6 0.60　USD 16 か月間のサポートの平均費用 0.29 USD   例 3: 新しいバージョンをすぐに採用し、Amazon EKS クラスターの定期的なアップグレードサイクルに従うことで、14 か月の標準サポート期間を超えて Kubernetes バージョンを使用しないとします。この場合、現在の Amazon EKS の請求に変更はありません。クラスターには引き続き 0.10 USD / 1 hour をお支払いいただきます。 サポートタイプ 利用期間 (月) 料金 (クラスター 1 hour あたり) 標準サポート 14 0.10 USD 延長サポート 0 0.60　USD 14 か月間のサポートの平均費用 0.10 USD   次の表と図は、Amazon EKS で現在利用可能な Kubernetes バージョンのサポート終了日と料金をまとめたものです。 サポートタイプ 期間 料金 (クラスター 1 hour あたり) 標準サポート Amazon EKS で Kubernetes バージョンが利用可能になった日から 14 か月間 0.10 USD 延長サポート Amazon EKS の標準サポート終了日から 12 か月間 0.60 USD Kubernetes version 標準サポートの期間 延長サポートの期間 1.23 2022 年 8 月 – 2023 年 10 月 2023 年 10 月 – 2024 年 10 月 1.24 2022 年 11 月 – 2024 年 1 月 2024 年 1 月 – 2025 年 1 月 1.25 2023 年 2 月 – 2024 年 5 月 2024 年 5 月 – 2025 年 5 月 1.26 2023 年 4 月 – 2024 年 6 月 2024 年 6 月 – 2025 年 6 月 1.27 2023 年 5 月 – 2024 年 7 月 2024 年 7 月 – 2025 年 7 月 1.28 2023 年 9 月 – 2024 年 11 月 2024 年 11 月 – 2025 年 11 月 * 正確な日付については、Amazon EKS Kubernetes リリースカレンダー を参照してください。このカレンダーは定期的に更新されるので、正確かつ最終的なバージョンサポート日を知るには信頼できる情報源と考えてください。 Next Steps Kubernetes バージョンの延長サポートは、現在 Amazon EKS のすべてのお客様にプレビュー版として追加費用なしでご利用いただけます。2024 年 4 月の請求サイクル (2024 年 4 月 1 日から) から、延長サポート対象の Kubernetes バージョンで実行されている Amazon EKS クラスターには、クラスターあたり 0.60 USD / 1 hour が課金されます。クラスターはいつでも標準サポートのバージョンに アップグレード できることを忘れないでください。標準サポートの料金に変更はなく、クラスターあたり 0.10 USD / 1 hour のままです。Amazon EKS リリースカレンダー を使用して、バージョンサポートの最新の日付を確認してください。 翻訳はソリューションアーキテクトの加治が担当しました。原文は こちら です。

この記事は、 Achieve high availability in Amazon OpenSearch Multi-AZ with Standby enabled domains: A deep dive into failovers を翻訳したものです。 Amazon OpenSearch Service は最近、 Multi-AZ with Standby を導入しました。これは重要なワークロードに対して、強化された可用性と一貫したパフォーマンスをビジネスに提供するために設計されたデプロイメントオプションです。この機能により、マネージドクラスターはゾーンのインフラストラクチャ障害に対する回復力を保ちながら、99.99% の可用性を実現できます。 この投稿では、Multi-AZ with Standby での検索とインデックスの仕組みと、その信頼性、シンプルさ、耐障害性をもたらす基盤メカニズムについて掘り下げます。 背景 Multi-AZ with Standby では、OpenSearch Service ドメインのインスタンスを 3 つのアベイラビリティーゾーンにまたがってデプロイします。そのうち 2 つのゾーンがアクティブ、1 つがスタンバイとして指定されます。この構成により、すべてのゾーンで同じキャパシティを維持することで、ゾーン障害が発生した場合でも一貫したパフォーマンスが確保されます。特に、このスタンバイゾーンは 静的に安定した設計 に従うため、障害時のキャパシティのプロビジョニングやデータ移動の必要がなくなります。 通常の運用中、アクティブゾーンは読み込みと書き込みのリクエストのためのコーディネータートラフィック、およびシャードクエリトラフィックを処理します。一方、スタンバイゾーンはレプリケーショントラフィックのみを受信します。 OpenSearch Service は、書き込みリクエストに同期レプリケーションプロトコルを利用します。 これにより、障害が発生した場合にスタンバイゾーンをアクティブな状態にすばやく昇格させることができます (フェイルオーバーまでの平均時間は 1 分以内)。これを ゾーンフェイルオーバー と呼びます。 以前にアクティブだったゾーンはスタンバイモードに降格され、正常な状態を回復するためのリカバリ操作が開始されます。 検索トラフィックのルーティングとフェイルオーバーによる高可用性の保証 OpenSearch Service ドメインにおいて、 コーディネータ とは、特にインデックス作成と検索リクエストを扱う HTTP(S) リクエストを処理するすべてのノードです。Multi-AZ with Standby を有効化したドメインでは、アクティブゾーンのデータノードが検索リクエストのコーディネータとして機能します。 検索リクエストのクエリの段階では、コーディネータはクエリ対象のシャードを決定し、そのシャードコピーをホストしているデータノードにリクエストを送信します。クエリは各シャードでローカルに実行され、マッチしたドキュメントがコーディネータノードに返されます。シャードコピーを含むノードにリクエストを送信する責務を持つコーディネータノードは、プロセスを 2 つのステップで実行します。 まず、シャードコピーにトラフィックが均一に分散されるように、シャードコピーをクエリするためにノードを問い合わせる順序を定義するイテレータを作成します。 その後、リクエストが関連するノードに送信されます。 シャードコピーのクエリ対象ノードの順序付きリストを作成するために、コーディネータノードはさまざまなアルゴリズムを使用します。 これらのアルゴリズムには、ラウンドロビン選択、適応型レプリカ選択、優先度ベースのシャードルーティング、 重み付きラウンドロビン が含まれます。 Multi-AZ with Standby の場合、シャードコピーの選択には重み付きラウンドロビンアルゴリズムが使用されます。このアプローチでは、アクティブゾーンには重み 1 が割り当てられ、スタンバイゾーンには重み 0 が割り当てられます。これにより、スタンバイアベイラビリティーゾーンのデータノードに読み取りトラフィックが送信されないことが保証されます。 重みはクラスター状態メタデータ内に JSON オブジェクトとして保存されます: "weighted_shard_routing": {     "awareness": {         "zone": {             "us-east-1b": 0,             "us-east-1d": 1,             "us-east-1c": 1          }      },      "_version": 3 } 次のスクリーンショットに示すように、 us-east-1b リージョンのゾーンステータスが StandBy となっており、このアベイラビリティーゾーン内のデータノードがスタンバイ状態であり、ロードバランサーからの検索やインデックス要求を受信していないことを示しています。 定常状態の運用を維持するために、スタンバイのアベイラビリティーゾーンは 30 分ごとにローテーションされ、すべてのネットワークパーツがアベイラビリティーゾーン全体でカバーされていることが保証されます。このプロアクティブなアプローチは、読み取りパスの可用性を検証し、潜在的な障害時のシステムの回復力をさらに強化します。次の図は、このアーキテクチャを示しています。 前の図では、Zone-C の重み付きラウンドロビンの重みが 0 に設定されています。これにより、スタンバイゾーンのデータノードがインデックス作成や検索トラフィックを受信しないことが保証されます。 コーディネータがシャードコピーのクエリをデータノードに対して行うとき、クエリを送信するノードの順序を決定するために、重み付きラウンドロビンの重みが使用されます。 スタンバイアベイラビリティーゾーンの重みが 0 であるため、コーディネータのリクエストは送信されません。 OpenSearch Service クラスターでは、次のスクリーンショットに示すように、アベイラビリティーゾーンのローテーションメトリクスを使用して、アクティブゾーンとスタンバイゾーンをいつでも確認できます。 ゾーン障害時には、スタンバイアベイラビリティーゾーンがシームレスにフェイルオープンモードに切り替わり、検索リクエストを処理します。 これは、アクティブなアベイラビリティーゾーンで正常なシャードコピーが利用できない場合、スタンバイを含むすべてのアベイラビリティーゾーンにシャードクエリのトラフィックがルーティングされることを意味します。 このフェイルオープンアプローチにより、障害時の検索リクエストが中断されることから保護され、サービスの連続性が確保されます。次の図は、このアーキテクチャを示しています。 前の図では、定常状態時に、シャードクエリのトラフィックは、アクティブなアベイラビリティゾーン (ゾーン A とゾーン B) のデータノードに送信されます。 ゾーン A のノード障害が発生すると、スタンバイのアベイラビリティゾーン (ゾーンC) がオープンになってシャードクエリのトラフィックを受け取るため、検索リクエストに影響はありません。 最終的に、ゾーン A が不健全と検出されると、読み込みフェイルオーバーがスタンバイをゾーン A に切り替えます。 フェイルオーバーが書き込み障害時に高可用性を確保する方法 OpenSearch Service のレプリケーションモデルは、プライマリバックアップモデルに従っており、ユーザーの書き込みリクエストを承認する前に、すべてのシャードコピーからの承認が必要となる同期的な性質を特徴としています。このレプリケーションモデルの顕著な短所の 1 つは、書き込みパスに何らかの障害が発生した場合の低速化に対する脆弱性です。これらのシステムは、アクティブなリーダーノードに依存して、障害や遅延を特定し、その情報をすべてのノードにブロードキャストします。これらの問題を検出するのにかかる時間 (平均検出時間) と、その後解決するのにかかる時間 (平均修復時間) が、システムが障害状態で動作する時間を大きく左右します。さらに、ゾーン間通信に影響を与えるネットワークイベントは、レプリケーションの同期的な性質のため、書き込みリクエストを大幅に阻害する可能性があります。 OpenSearch Service は、書き込みトラフィックをレプリケートし、メタデータの更新を調整するために、選出されたリーダーを通じて内部のノード間通信プロトコルを利用します。 したがって、ストレスを受けているゾーンをスタンバイにすることは、書き込み障害の問題に効果的に対処することにはなりません。 ゾーンの書き込みフェイルオーバー: ゾーン間レプリケーショントラフィックの遮断 Multi-AZ with Standby の場合、想定外のゾーン障害やネットワークイベントなどで発生する可能性のあるパフォーマンスの問題を軽減するために、ゾーン間の書き込みフェイルオーバーは効果的なアプローチです。このアプローチでは、影響を受けたゾーン内のノードをクラスターから正常に削除することで、ゾーン間の入出力トラフィックを効果的に遮断します。ゾーン間のレプリケーショントラフィックを遮断することで、ゾーン障害の影響を影響を受けたゾーン内に限定することができます。これにより、お客様により予測可能な体験を提供し、システムが信頼性高く稼働し続けることを確実にします。 グレースフルな書き込みフェイルオーバー OpenSearch Service 内の書き込みフェイルオーバーのオーケストレーションは、選出されたリーダーノードによって、明確に定義されたメカニズムを通じて実行されます。 このメカニズムには、クラスター状態の公開のためのコンセンサスプロトコルが含まれており、すべてのノードが一致して、常に 1 つのゾーンのみを廃止対象として指定することに同意します。 重要なことに、影響を受けたゾーンに関連するメタデータは、障害の発生時に完全な再起動があったとしても、その永続性を確保するために、すべてのノード間でレプリケートされます。 さらに、リーダーノードは I/O フェンシングを始める前に、まず影響を受けるゾーン内のノードを 5 分間スタンバイ状態に置くことで、スムーズで正常な移行を保証します。この意図的なアプローチにより、影響を受けたゾーン内のノードに新しいコーディネータトラフィックやシャードクエリトラフィックが向けられるのを防ぎます。これにより、これらのノードは進行中のタスクを正常に完了し、サービスから外される前に未処理のリクエストを徐々に処理できるようになります。次の図は、このアーキテクチャを示しています。 リーダーノードの書き込みフェイルオーバーを実装するプロセスで、OpenSearch Serviceは次の主要なステップに従います。 リーダーの譲位 – リーダーノードが書き込みフェイルオーバーがスケジュールされているゾーンに位置している場合、システムはリーダーノードが自発的にリーダーシップの役割から下りることを保証します。この譲位は管理された方法で実行され、プロセス全体が別の適格なノードに引き継がれ、必要なアクションを担当します。 廃止予定のリーダーの再選を防ぐ – 書き込みフェイルオーバーがマークされたゾーンからのリーダーの再選を防ぐために、適格なリーダーノードが書き込みフェイルオーバーアクションを開始すると、廃止予定のリーダーノードがさらなる選挙に参加しないようにする措置を講じます。これは、廃止予定のリーダーノードを投票設定から除外することによって実現され、クラスターの運用の重要なフェーズでの投票を効果的に防ぎます。 書き込みフェイルオーバーゾーンに関連するメタデータはクラスター状態内に保存されます。この情報は、分散された OpenSearch Service クラスター内のすべてのノードに次のように公開されます。 "decommissionedAttribute": {     "awareness": {         "zone": "us-east-1c"      },      "status": "successful",      "requestID": "FLoyf5v9RVSsaAquRNKxIw" } 次のスクリーンショットは、ゾーンでネットワークの低速化が発生した際、書き込みフェイルオーバーが可用性の回復に役立つことを示しています。 ゾーン回復後の書き込みフェイルオーバー ゾーンの再起動プロセスは、ゾーンの書き込みフェイルオーバー後のリカバリフェーズで重要な役割を果たします。 影響を受けたゾーンが復旧し、安定していると見なされた後、以前に廃止されたノードがクラスターに再参加します。 この再参加は通常、ゾーンが再起動されてから 2 分以内の時間枠で発生します。 これにより、ピアノードとの同期が可能になり、レプリカシャードのリカバリプロセスが開始されるため、クラスターは目的の状態に効果的に復元されます。 結論 OpenSearch Service は Multi-AZ with Standby の導入により、重要なワークロードの高可用性と一貫したパフォーマンスを実現するための強力なソリューションが企業に提供されます。このデプロイオプションを使用することで、企業はインフラストラクチャの回復力を強化し、クラスタの構成と管理を簡素化し、ベストプラクティスを適用できます。 重み付きラウンドロビンによるシャードコピー選択、プロアクティブなフェイルオーバーメカニズム、フェイルオープンなスタンバイアベイラビリティゾーンなどの機能により、OpenSearch Service の Multi-AZ with Standby は、要求の厳しいエンタープライズ環境において、信頼性が高く効率的な検索エクスペリエンスを実現します。 Multi-AZ with Standby の詳細については、 Amazon OpenSearch Service Under the Hood: Multi-AZ with Standby を参照してください。

ガバメントクラウドに関する情報は AWS も含めてさまざまな方面から毎日のように発信されており、どの情報を追ったらいいのか、何を気にするべきなのかわからなくなってくることもあるかと思います。 そこで、このブログでは「ガバメントクラウドの道案内」と題して自治体ガバメントクラウドに携わる方がそれぞれ何を検討すべきで、そのためにどの資料を確認した方がいいのかを役割別にまとめていきます。 本ブログは自治体においてガバクラ利用を検討されているお客様に向けた「自治体職員編」です。 そのほかの方に向けたブログに関しては以下リンクをご参照ください。 ガバメントクラウドの道案内: 『自治体職員編』 (本ブログ) ガバメントクラウドの道案内: 『統合運用管理補助者編』 ガバメントクラウドの道案内: 『ネットワーク構築補助者編』 ガバメントクラウドの道案内: 『 ASP ＆運用管理補助者編』 本ブログの構成 ここでは気にするべきポイントをステップに分けて紹介します。 AWS について学ぶ ガバクラで使用するネットワーク範囲を考える どの範囲までアプリケーションをガバメントクラウドに移行するか考える 「共同利用方式」か「単独利用方式」かを考える 各事業者の役割を理解する (単独利用方式の場合) 統合運用補助事業者を立てる必要があるか確認する ネットワーク接続方式を考える 費用の算出方法を考える それぞれの対応方法について概要と、どのように考えていくかをお伝えします。 (1) AWS について学ぶ ガバクラを利用するにあたり、もし AWS の利用をお考えであればまずは AWS でできることについて知る必要があります。 AWS では月に1回ウェビナーを開催し、AWS の概要から利用できるサービスの概要、想定される構成などガバメントクラウドでの利用に必要な内容についてご紹介しています。 ぜひ一度こちらをご覧いただき、AWS の理解を深めていただけると嬉しいです。 自治体向けオンライントレーニング 〜ガバメントクラウド（AWS編）対応版〜 直近の参加が難しい方はオンデマンド版もご用意しております。 お手数ですが担当営業にご連絡いただくか、本ブログ末尾のお問い合わせ窓口よりご連絡ください。 (2) ガバクラで使用するネットワーク範囲を考える ガバメントクラウドで AWS を利用する場合、AWS 上で使用する IP アドレス範囲はお客様側で自由に決定することが可能です。 (一部の共同利用方式では ASP と連携しながら IP アドレスを決める必要があります。後述します) 一方で、AWS とオンプレミス (庁舎など) は L3 レベルで接続されるため、AWS に割り当てる IP アドレスはオンプレミスで使用していない IP アドレスである必要があります。 そこで、ガバメントクラウドを利用するにあたってはオンプレミスで使用していない IP アドレス範囲を確認し、割り当てる必要があります。 AWS のネットワークの考え方についてより知識を深めたい方は [AWS Black Belt Online Seminar] Amazon VPC をご覧ください。 (3) どの範囲までアプリケーションをガバメントクラウドに移行するか考える 個人番号利用事務系に属する 20 業務がガバメントクラウドの移行対象となっていますが、関連システムについてもガバメントクラウドへ移行することが可能とされています。 AWS からオンプレミスへの通信と AWS 内部での通信では下図のように通信料金が異なりますため、データ連携が多く発生するシステムに関しては 20 業務以外のシステムでも AWS へ移行する方が費用が抑えられる場合があります。 ※上記費用は 2024 年 1 月現在のものです。また、通信に関わる費用は上記料金以外にもございます。詳しくは ネットワーク運用補助事業者の方向けのブログ および使用するサービスのドキュメントをご参照ください。 「20 業務のシステムとデータ連携がどの程度発生するか」を検討した上で 20 業務のシステム以外まで視野を含めてどのシステムをガバメントクラウド移行対象とするかを検討していく必要があります。 (4) 「共同利用方式」か「単独利用方式」かを考える ガバメントクラウドの利用方式は大きく分けて「共同利用方式」と「単独利用方式」の二つがあります。 共同利用方式 パッケージベンダーがアカウントを持った上でシステムを構築し、SaaS 形式で利用できるようにする方式 単独利用方式 自治体がアカウントを持った上で、そのアカウント上にシステムの構築を依頼して利用する方式 利用方式に応じて、自治体の責任範囲・自由度が異なりますため、ガバメントクラウド上で実現したい内容に合わせて適宜選択いただく必要があります。 また、パッケージによっては単独利用方式・共同利用方式のどちらかしか採用できない場合があります。 利用方式を決定する際にはパッケージベンダーとも会話しながら進めていくことが望ましいです。 以下にそれぞれの利用方式の参考となる比較表を記載します。 (5) 各事業者の役割を理解する ガバメントクラウドではパッケージベンダーの他に、運用補助事業者やネットワーク構築運用補助者など複数の事業者が紐づく形で構築されることが多いかと考えます。 各登場人物の役割分担については 以前公開したブログ にタスクリストのダウンロードに関する記載がありますので、こちらをご確認ください。 (6) (単独利用方式の場合) 統合運用補助事業者を立てる必要があるか確認する 採用した利用方式が単独利用方式の場合、かつマルチベンダー (マルチアカウント) でパッケージが構築される場合、複数のアカウントを跨ぐ形でメトリクスを取得しダッシュボードを作成するなど統合的に運用管理を行う事業者が必要となる場合があります。 単独利用方式の場合、これを実施する「統合運用管理補助者」を立てるかどうかを検討する必要があります。 統合運用補助者の役割および必要となると考えられる作業に関してはブログ「 ガバメントクラウドの道案内『統合運用管理補助者編』 」をご確認ください。 (7) ネットワーク接続方式を考える オンプレミスから AWS への接続に関しては専用線が必要となります。 専用線をどう利用するかに関してはいくつか検討できる方式があります。以下は一例です。 自治体が個別に専用線を契約する方式 自治体が回線業者と契約することで AWS まで専用線を敷設する方式 自治体が単独で契約するためスピード感を持って敷設することができ、専用線を占有することができる。 複数団体で専用線を共有する方式 現在複数自治体でデータセンターを共有していたり、情報ハイウェイ等自治体共有のネットワークがある場合、そこから専用線を伸ばして AWS へ接続する方式 複数の自治体でネットワークを共有するため、コストを按分することが可能となる LGWAN を利用する方式 次期 LGWAN ではガバメントクラウドへの接続サービスの提供が予定されているため、それを利用する方式 今後公開される詳細情報を確認しながら検討 以上の方式の中から、どの選択が実現可能か検討いただければと思います。 (8) 費用の算出方法を考える ガバメントクラウドでは費用に関しては各 CSP の計算ツールを利用することが求められています。 AWS では Pricing Calculator を用意しておりますため、これを使用していただくことが可能です。 Pricing Calculator の使い方についてはウェビナー「 Pricing Calculator ～見積の仕方と自治体のモデルケース～ 」をご覧ください。 上記ウェビナーでご確認いただける通り、Pricing Calculator を使用できるのはあくまで「AWS で稼働させるシステムが利用するサービス・スペックがわかっている場合」のみになります。 今回20業務のシステムに関してはパッケージベンダーが新規に構築する場合が多いかと思いますので、可能であればパッケージベンダーの方に問い合わせていただき、Calculator を使用した見積もりを共有いただくと現実に即した費用感が得られやすいかと考えます。 上記方法が難しそうであった場合、既存のリソース表を基に Pricing Calculator に入力いただく必要が出てきます まとめ 本ブログでは、自治体のお客様がガバメントクラウドを利用するにあたって検討すべきポイントをご紹介しました。 検討すべきポイントの整理と、検討すべきポイントがわかっていてもどの資料を見ると理解が深められるかわからなかった方に対するサポートがこのブログでできていれば嬉しいです。 自治体に所属している方、または関連するベンダー・パートナーの方でこのブログに関して追記した方がいい事項やご不明点などございましたらお気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へお気軽にご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、全ての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介したタスクリストに関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

自治体のお客様において、現在ガバメントクラウドの利用検討が進んでいます。ガバメントクラウドを利用するうえでは、さまざまな事業者が分担して作業することが多いと思います。 例えば、「ネットワーク構築運用補助者」がネットワーク経路を整備し、「運用管理補助者」が運用管理を行う個別領域上に、「ASP」がシステムを構築します。それぞれの事業者の詳細な役割分担については、 こちらのブログ をご参照ください。 本ブログは自治体においてガバメントクラウド利用を検討されているお客様に向けた「ネットワーク構築運用補助者編」です。ネットワーク構築運用補助者がネットワーク構築や運用管理を行っていく上で、気にするべき点や、参考となる資料をまとめています。作業内容の確認等に、ご利用いただければと思います。 その他の方に向けたブログに関しては以下リンクをご参照ください。 ガバメントクラウドの道案内: 『自治体職員編』 ガバメントクラウドの道案内: 『統合運用管理補助者編』 ガバメントクラウドの道案内: 『ネットワーク構築運用補助者編』(本ブログ) ガバメントクラウドの道案内: 『ASP＆運用管理補助者編』 また、本ブログは以下のような方を対象として記述しています。 ネットワーク構築運用補助者を担う事業者の方 ネットワーク構築運用補助者を立てることをご検討されており、詳細を知りたい自治体の方 本ブログの構成 ここからはネットワーク構築運用補助者について以下のような章立てでお話しします。 ネットワーク構築運用補助者の役割と担当する事業者について 地方公共団体からガバメントクラウドへの接続パターンについて ネットワークを集約する構成について まとめ 免責事項 ガバメントクラウドに関するお問い合わせ ネットワーク構築運用補助者の役割と担当する事業者について 多くの地方公共団体の基幹システムは、マルチベンダーで構成されており、ガバメントクラウド上ではマルチアカウント構成になることが多いと思います。 マルチベンダー・マルチアカウントの構成の場合には、AWS Transit Gateway の設置と運用を行うベンダーが必要です。すべての基幹システムが共同利用方式でも、ネットワークアカウント (ネットワーク構築運用補助者) は必要となると考えます。 ネットワーク構築運用補助者は、具体的には 自治体からガバメントクラウドへの接続 マルチベンダー環境 (マルチアカウント含む) 利用時における、 AWS Transit Gateway 等を用いた接続設定 Windows Server Update Services (WSUS) 等ガバメントクラウド向け・庁内環境向けのアップデート用サーバを置いた場合のインターネット接続設定 等を行う場合に必要となるかと考えます。 また、ネットワーク構築運用補助者がガバメントクラウド全体の運用管理補助業務を担う場合、ネットワーク構築運用補助者が運用管理補助業務を兼任することが想定されます。これは、ネットワーク構築運用補助者はもともとガバメントクラウド全体のネットワークを管理することが求められているため、セキュリティについての管理も兼任しやすいと考えています。その場合は、 こちらのブログ をご参照ください。 地方公共団体からガバメントクラウドへの接続パターンについて 地方公共団体とガバメントクラウドとの接続方法は、各拠点から敷設する専用回線及び閉域ネットワークの利用形態によって、主に 5 パターンが想定されます。各パターンの特徴や考慮事項を踏まえて、適した接続方法を下記またはそれ以外のパターンから検討する必要があります。 地方公共団体から専用線で接続する方法 各地方公共団体団体から個別に専用線・Direct Connect を敷設し、ガバメントクラウドへ接続する方法です。回線を共同利用する場合と比較して、回線費用の負担が大きくなる可能性があります。 ASP のデータセンタから専用線で接続する方法 既存の地域回線等を利用し、各地方公共団体からデータセンタへ専用線を集約する方法です。個別に接続する場合と比較して、回線費用の負担を抑えられる可能性があります。また団体間でIPアドレス帯が重複する場合は、トンネリング等の対応が必要となります。 都道府県 WAN を経由して接続する方法 地方公共団体において都道府県 WAN 事業者の回線を利用する方法です。個別に接続する場合と比較して、回線費用の負担を抑えられる可能性があります。また団体間で IP アドレス帯が重複する場合は、トンネリング等の対応が必要となります。 既に接続しているパブリッククラウドの接続回線で接続する方法 既設環境でパブリッククラウドに接続している場合、その回線を利用する方法です。アクセス回線の帯域について、新たに接続するクラウドサービスの通信等を再検討する必要があります。 LGWAN を経由して接続する方法 各地方公共団体から LGWAN を利用し、ガバメントクラウドへ接続する方法です。ガバメントクラウドに接続するためのクラウド接続サービスは LGWAN で構築予定のため、クラウド接続サービスに係る新規調達等が不要になりイニシャルコストを抑えられる可能性があります。 ネットワークを集約する構成について 上記の地方公共団体からガバメントクラウドへの接続パターンについて、2 や 3 の場合に回線を集約してガバメントクラウドへ接続を検討する事業者様もいらっしゃるかと存じます。以下がイメージです。 その際に、以下の項目が、ネットワークを検討する際に気になる点と考えます。各項目について参考となる情報をまとめています。 DNS の設計 IP アドレス範囲重複への対応 ネットワーク関連の費用 DNSの設計について 地方公共団体からガバメントクラウド環境のシステムの名前解決を行う場合に、Amazon Route 53 のインバウンドエンドポイントを地方公共団体の基幹ネットワークのオンプレミス DNS サーバに、フォワーダーとして設定することで名前解決することが可能です。Amazon Route 53 のインバウンドエンドポイントを使用しない場合は、Amazon (provided) DNS にフォワードする DNS サーバを別途構築する必要があります。AWS の Amazon Route 53 Resolver の知識を深めたい方は [AWS Black Belt Online Seminar] Amazon Route 53 Resolver をご覧ください。 また、Amazon Route 53 Resolver を使用してマルチアカウント環境で DNS 管理を一元化するソリューションは こちらのブログ をご参照ください。 IP アドレス範囲重複への対応 複数の地方公共団体から同一の閉域ネットワークに接続する際、各拠点の IP アドレス範囲は重複させることができず、もし重複する場合にはガバメントクラウドに接続するための対応が別途必要となります。 地方公共団体からガバメントクラウドへの接続を閉域ネットワーク共同利用で行う場合を例として、対応方法を以下に示します。 地方公共団体から本番アカウントの Transit Gateway まで、Site-to-Site VPN を利用して IPsec トンネルを構成して接続することで対応可能です。Private IP VPN を利用して IPsec トンネルを構成して接続します。技術詳細については、 こちらのブログ をご参照ください。また Transit Gateway Connect を利用して GRE over IPsec トンネルを構成して接続することで対応も可能です。 団体間で VPN Tunnel IP と Transit Gateway のルートテーブルを分けて管理することで、団体の庁舎の CIDR や 、宛先の VPC の CIDR が重複していても、ルーティングすることが可能となります。 詳しくは、毎月開催している自治体向けオンライントレーニングの ウェビナー (11：ガバメントクラウド利用におけるネットワーク構成例と作業内容の整理) でもご紹介しております。ぜひご確認ください。 ネットワーク関連の費用 ネットワークアカウントとアプリケーションアカウントにそれぞれどのようにネットワーク関連の費用がかかるのかを気にされている自治体や事業者の方が多くいらっしゃるかと存じます。 ネットワーク構成によって、以下の例をご参考にネットワーク関連の料金を整理いただければと思います。 (2024 年 1 月時点でのサービス内容及び価格に基づいたスライドや説明になっています。最新の情報は AWS公式ウェブサイト にてご確認ください。) ネットワークアカウント (図のアカウント A) AWS VPN の費用 サイト間 VPN 接続の従量課金費用 データ転送アウト費用 AWS Direct Connect の費用 接続ポート時間費用 ※契約形態に依る AWS Transit Gateway の費用 AWS Transit Gateway VPN アタッチメント費用 AWS Direct Connect アタッチメント費用 Direct Connect ゲートウェイ-AWS Transit Gateway データ処理費用 アプリケーションアカウント (図のアカウント B) AWS Direct Connect の費用 データ転送アウト費用 AWS Transit Gateway の費用 AWS Transit Gateway アタッチメント費用 TAWS Transit Gateway アタッチメント-AWS Transit Gateway データ処理費用 まとめ このブログではネットワーク構築運用補助者となる事業者の方向けに役割範囲や作業内容についてご説明いたしました。ガバメントクラウドではガバメントクラウド固有の事情や制約等が発生し、初めて触れる事業者の方には難しいものとなっているかと思います。そんな中、ネットワーク構築運用補助者の作業内容を理解し、複数のガバメントクラウド個別領域全体を安全に運用管理していくためにこのブログをお役立ていただけると大変嬉しく思います。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、全ての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 上記ご了承の上、ご利用ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介したタスクリストに関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

この記事は、 Amazon OpenSearch Service now supports 99.99% availability using Multi-AZ with Standby を翻訳したものです。 お客様は、ミッションクリティカルなアプリケーションや監視に Amazon OpenSearch Service を使用しています。しかし、OpenSearch Service自体が利用できない場合はどうなるのでしょうか? たとえば、E コマースの検索がダウンした場合、収益が失われます。アプリケーションをOpenSearch Serviceで監視している場合、利用できなくなると、アプリケーションの問題を検出、診断、修復する能力が低下します。これらのケースでは、収益の損失、顧客の不満、生産性の低下、あるいは組織の評判へのダメージを被る可能性があります。 OpenSearch Service は、 ベストプラクティス に従うことで 99.9% の可用性のSLAを提供します。しかし、それらのプラクティスを実践するのは複雑で、OpenSearch のデータ配置と管理に関する知識と経験が必要となります。また、OpenSearch Service が AWS のアベイラビリティゾーンやネットワーク、分散システム、OpenSearch の自己回復能力、回復方法とどのように相互作用するかについての理解も必要です。さらに、ノードが応答しなくなるなどの問題が発生した場合、OpenSearch Service は欠落したシャード (データ) を再作成することで回復しますが、これによりドメイン内で大量のデータ移動が発生する可能性があります。 このデータ移動はクラスターのリソース使用量を増加させ、パフォーマンスに影響を及ぼす可能性があります。 クラスターのサイズが適切でない場合、可用性が低下し、3 つのアベイラビリティーゾーンにプロビジョニングする目的を達成できなくなります。 AWS は OpenSearch Service の新しいデプロイメントオプションである Multi-AZ with Standby を発表しました。これにより、高頻度の監視、迅速な障害検出、障害からの迅速な回復などの重労働を軽減し、インフラ障害が発生した場合でもドメインの可用性とパフォーマンスを維持できるようになります。Multi-AZ with Standby を使用すると、ドメインは 99.99% の可用性と一貫したパフォーマンスを実現できます。 この記事では、この新しいオプションのメリットと、Multi-AZ with Standby で OpenSearch クラスターを設定する方法について説明します。 ソリューション概要 OpenSearch Service チームは、お客様のために数万のドメインを運用する中で得た経験を、Multi-AZ with Standby 機能に組み込みました。Multi-AZ with Standby を採用すると、OpenSearch Service は 3 つのアベイラビリティゾーンにまたがるクラスターを作成し、各アベイラビリティゾーンにはクラスター内のデータの完全なコピーが含まれます含めます。次に、OpenSearch Service は1つのアベイラビリティゾーンをスタンバイモードにし、すべてのクエリを他の 2 つのアベイラビリティゾーンにルーティングします。ハードウェア関連の障害を検出すると、OpenSearch Service は 1 分以内にスタンバイプールのノードをアクティブに昇格させます。Multi-AZ with Standby を使用すると、OpenSearch Service は失われたノードからデータを再分配または再作成する必要がありません。その結果、クラスターのパフォーマンスは影響を受けず、可用性が低下するリスクを排除します。 前提条件 Multi-AZ with Standby には、以下の前提条件が必要です : ドメインは OpenSearch 1.3 以上で実行する必要があります ドメインは 3 つのアベイラビリティゾーンにまたがってデプロイされる必要があります ドメインには 3 つ (または 3 の倍数) のデータノードが必要です 3 つの専用クラスターマネージャー (マスター) ノードを使用する必要があります ドメインと専用マスターノードのサイジングのガイダンスについては、 Amazon OpenSearch Service ドメインのサイジング を参照してください。 Multi-AZ with Standby を使用した OpenSearch クラスターの設定 Multi-AZ with Standby は、新しいドメインを作成するときにも、既存のドメインに追加するときにも使用できます。 AWS Management Console を使用して新しいドメインを作成する場合、新しい Easy create オプションまたは従来の Standard create オプションを選択することで、Multi-AZ with Standby を使用して作成できます。既存のドメインは、ドメイン設定を編集することで Multi-AZ with Standby を使用するように更新できます。 Easy create オプションは、名前が示すように、ほとんどの設定をベストプラクティスの選択肢にデフォルトすることで、ドメインの作成を容易にします (大部分は後から変更可能です) 。ドメインは最初から高可用に設定され、Multi-AZ with Standby としてデプロイされます。 データノードを選択する際は、各アベイラビリティゾーンに均等に分散されるように、3 つ (または 3 の倍数) のデータノードを選択する必要があります。OpenSearch Service コンソールの Data nodes テーブルは、アベイラビリティゾーンの 1 つがスタンバイになることを視覚的に表しています。 同様に、専用マスターノードを選択する際には、計画しているデータノード、インデックス、シャードの数を考慮して、インスタンスサイズを決定することをお勧めします。 ドメインが作成されたら、OpenSearch Service コンソールの Cluster configuration で、デプロイメントタイプを確認できます。以下のスクリーンショットを参照してください。 インデックスを作成する際は、コピー数 (プライマリとレプリカ) が 3 の倍数になるようにしてください。レプリカ数を指定しない場合、サービスはデフォルトで 2 を設定します。これは、各アベイラビリティゾーンにデータのコピーが少なくとも 1 つ存在することを保証するために重要です。ログワークロードの場合は、 index template などを使用することをお勧めします。 OpenSearch Service は、ノードとデータコピーを 3 つのアベイラビリティゾーンに均等に分散させます。通常の運用では、スタンバイノードは検索リクエストを受信しません。2 つのアクティブなアベイラビリティゾーンがすべての検索リクエストに応答します。ただし、データはこれらのスタンバイノードにレプリケートされるため、常に各アベイラビリティゾーンにデータの完全なコピーが存在することが保証されます。 インフラ障害イベントへの対応 OpenSearch Service は、ノード障害、ディスク障害、アベイラビリティゾーン障害などのイベントについてドメインを継続的に監視します。アベイラビリティゾーン障害などのインフラ障害が発生した場合、OpenSearch Service は影響を受けたアベイラビリティゾーンが回復する間、スタンバイノードをアクティブに昇格させます。影響を受けたアベイラビリティゾーンからのトラフィックは1分以内に転送されるため、影響 (がある場合) は実行中のリクエストに限定されます。 ドメインのステータス、アクティブおよびスタンバイのデータノードメトリクス、アベイラビリティゾーンのローテーションメトリクスは、 Cluster health タブで確認できます。以下のスクリーンショットは、Cluster health とデータノードのメトリクス ( CPU 利用率、JVM memory pressure 、ストレージなど) を示しています。 以下のスクリーンショットは、 AZ Rotation Metrics セクション ( Cluster health タブの下にあります) で、アベイラビリティゾーンの read と write のステータスを示しています。OpenSearch Service は、イベントに対応できるように準備ができていることを確認するために、30 分ごとにスタンバイのアベイラビリティゾーンをローテーションさせます。トラフィックに応答しているアベイラビリティゾーンは値が 1 で、スタンバイのアベイラビリティゾーンは値が 0 です。 考慮事項 この機能には、より高い可用性を提供し、パフォーマンスを維持するいくつかの改善とガードレールが実装されています。ノードあたりのシャード数、ドメインのシャード数、シャードのサイズに関する特定の静的な制限が適用されています。OpenSearch Service はデフォルトで Auto-Tune も有効にします。Multi-AZ with Standby は、最もコスト効果的で高パフォーマンスなストレージオプションである GP3 または SSD-backed インスタンスにストレージを制限します。さらに、不正なクエリを検出する高度なトラフィックシェイピングメカニズムを導入しており、これによりドメインの信頼性がさらに向上します。 高可用性とパフォーマンスを実現するために、お客様のワークロードに基づいてドメインインフラストラクチャのニーズを評価することをお勧めします。 まとめ Multi-AZ with Standby は、US West (N. California)、 AWS GovCloud (US-Gov-East, US-Gov-West) を除いた OpenSearch Service が利用できるすべてのAWSリージョンで利用できるようになりました。お試しいただき、 AWS re:Post for Amazon OpenSearch Service または通常の AWS サポート窓口までフィードバックをお送りください。 翻訳は Solutions Architect 川岸が担当しました。