本ブログ記事は Flexible Compute を担当する プリンシパルソリューションアーキテクトの Ahmed Nada と Amazon EC2 Auto Scaling を担当する プリンシパルプロダクトマネージャーの Kevin OConnor による共著です。 Amazon Web Services (AWS) を利用する世界中のお客様は Amazon EC2 Auto Scaling を使用して、自身のワークロードのための Amazon Elastic Compute Cloud (Amazon EC2) キャパシティをプロビジョニングし、スケールさせ、管理しています。新しい EC2  Amazon Machine Images (AMIs) のデプロイ、EC2 インスタンスタイプの変更、自身のコードの最新化を確実に実施するために Amazon EC2 Auto Scaling インスタンス更新を利用しています。 現在、EC2 Auto Scaling はインスタンスの置き換えが発生する要因によって「終了する前に起動（launch before terminate）」や「終了してから起動（terminate and launch）」という振る舞いをしています。EC2 Auto Scaling を利用するお客様からは、アクティブなインスタンスが置き換えられることによる潜在的な中断を最小限にするために、新しいインスタンスの起動を今まで以上に制御できるようにしたいという声を頂いてきました。こういった要望に対応する Amazon EC2 Auto Scaling のインスタンスメンテナンスポリシーを導入できることを嬉しく思います。この機能は、お客様が EC2 インスタンスの置き換えプロセスをより細かく制御できるようにし、Amazon EC2 のコストを最小限に抑えながら、パフォーマンスの優先順位と運用に合った方法でインスタンスを置き換えられるようにする拡張機能です。 本ブログ記事では、インスタンスメンテナンスポリシーを設定し、Amazon EC2 Auto Scaling グループで使用する様々な方法を紹介します。 背景 AWS は、Amazon EC2 キャパシティを管理するプロセスを簡素化することを目的として、2009 年に Amazon EC2 Auto Scaling をローンチしました。それ以来、 予測スケーリング 、 属性ベースのインスタンスタイプの選択 、 ウォームプール などの高度な機能の導入による改善を続けてきました。 Amazon EC2 Auto Scaling は基本機能の 1 つとして、インスタンスの状態、 Amazon EC2 スポットインスタンス の中断、インスタンスの更新オペレーションへの応答、によってインスタンスを置き換えます。インスタンスの置き換え機能により、Amazon EC2 Auto Scaling グループ内の正常で高性能な EC2 インスタンス群を維持できます。状況によっては、代替インスタンスを起動する前にインスタンスを終了するとパフォーマンスに影響が出たり、最悪の場合、アプリケーションのダウンタイムが発生したりする可能性があります。要件がどのようなものであれ、インスタンスメンテナンスポリシーにより、特定のニーズに合わせてインスタンスの置き換えプロセスを微調整できます。 概要 インスタンスメンテナンスポリシーにより、最小正常率 ( MinHealthyPercentage ) と最大正常率 ( MaxHealthyPercentage ) という 2 つの新しい Amazon EC2 Auto Scaling グループ設定が追加されています。これらの値は、インスタンスの置き換え時に正常で実行中の状態でなければならないグループの希望容量の割合を表します。 MinHealthyPercentage の値は 0 ～ 100%、 MaxHealthyPercentage の値は 100 ～ 200% の範囲です。これらの設定は、 ヘルスチェックベースの置き換え 、 インスタンスの最大存続期間 、 EC2 スポットキャパシティの再調整 、 アベイラビリティーゾーンの再調整 、インスタンス購入オプションの再調整、 インスタンスの更新 など、インスタンスの置き換えにつながるすべてのイベントに適用されます。また、特定のデプロイユースケースに合わせて、インスタンスの更新操作において、グループレベルのインスタンスメンテナンスポリシーを上書きすることもできます。 インスタンスメンテナンスポリシーを使用しない場合、Amazon EC2 Auto Scaling グループはインスタンスを置き換えるときに前述の動作を使用します。インスタンスメンテナンスポリシーの MinHealthyPercentage を 100% に、 MaxHealthyPercentage を 100% より大きい値に設定すると、Amazon EC2 Auto Scaling グループはまず代替インスタンスを起動し、それらが使用可能になるのを待ってから、置き換え対象のインスタンスを終了します。 インスタンスメンテナンスポリシーの設定 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI)、AWS SDK、 AWS CloudFormation 、および Terraform を使用して、新規または既存の Amazon EC2 Auto Scaling グループにインスタンスメンテナンスポリシーを追加することができます。 コンソールで Amazon EC2 Auto Scaling グループを作成または編集する場合、インスタンスメンテナンスポリシーの置き換え動作を定義する 4 つのオプションが表示されます。これらのオプションには、Amazon EC2 Auto Scaling サービスが現在使用しているデフォルトのインスタンス置き換え設定を維持できる ポリシーなし というオプションが含まれます。 図 1: 「Auto Scaling グループの作成」ウィザード内のインスタンスメンテナンスポリシー機能の画面 アプリケーションの可用性を高めるためのインスタンスメンテナンスポリシーの使用 Amazon EC2 Auto Scaling グループキャパシティの可用性を優先したい場合は、 終了する前に起動 ポリシーを選択するのが適切です。このポリシー設定は、グループの容量を一時的に増やすことで、置き換え操作中に新しいインスタンスを起動します。Amazon EC2 コンソールにて、置き換え方法として 終了する前に起動 を選択した後、必要な MaxHealthyPercentage 値を設定することで、インスタンスの置き換え中に追加で起動するインスタンスの数を決定します。 例えば、インスタンスの置き換え時に可用性を優先する必要があるワークロードを管理している場合は、 MinHealthyPercentage を 100% に設定して 終了する前に起動 ポリシータイプを選択します。 MaxHealthyPercentage を 150% に設定すると、Amazon EC2 Auto Scaling は、置き換え対象のインスタンスを終了する前に、代替インスタンスを起動します。必要な可用性を確保するために、置き換え中は希望する容量がグループの最大容量を超えて 50% 増加するときもあります。次の図のグラフは、 終了する前に起動 ポリシーでインスタンスの更新操作がどのように動作するかを示しています。 図 2: 終了する前に起動ポリシーを使用したインスタンス置き換えプロセス インスタンス更新時のインスタンスメンテナンスポリシー上書き インスタンスメンテナンスポリシー設定はすべてのインスタンス置き換え操作に適用されますが、新しいインスタンスの更新操作の開始時に上書きすることができます。インスタンスメンテナンスポリシーの上書きは、不適切なコードがデプロイされた際に、ダウンタイムなしで置き換える必要があるような場合に役立ちます。問題のあるコードを含むインスタンスを終了する前に、まったく新しいグループ分のインスタンスを稼働させるようにインスタンスメンテナンスポリシーを設定できます。この場合、インスタンスの更新操作の MaxHealthyPercentage を 200% に設定すると、不正コードの問題に迅速に対処するために、1 サイクルで置換が行われます。 MaxHealthyPercentage を 200% に設定すると、インスタンス置き換え方法の設定が Auto Scaling Group の最大キャパシティ値を超えることが許容されますが、アカウントレベルのクォータによる制約を受けるため、この機能を適用する際には必ずこれらを考慮に入れてください。次の図は、この操作が視覚的にどのように動作するかを示しています。 図 3: 新しいデプロイを高速化するように設定されたポリシーを使用したインスタンス置き換えプロセス 置き換えとデプロイ時のコスト管理 終了してから起動 ポリシーオプションを使用すると、インスタンス置き換え時のコスト管理を優先できます。このポリシータイプを設定すると、Amazon EC2 Auto Scaling は既存のインスタンスを終了し、置き換えプロセス中に新しいインスタンスを起動します。 終了してから起動 ポリシーを設定するには、 MinHealthyPercentage を指定して容量がどの程度低下してもよいか指定し、 MaxHealthyPercentage を 100% に設定します。この設定では、Auto Scaling グループの容量を、希望する容量もしくはそれ以下の状態に保ちます。 次の図は、 MinHealthyPercentage を 80% に設定したときの動作を示しています。インスタンスの置き換えプロセスにて、Auto Scaling グループはグループの正常な容量を一時的に 80% に減らすことで、最初にインスタンスの 20% を終了し、すぐに代替インスタンスを起動します。グループは、新しいインスタンスが設定されたヘルスチェックを通過して ウォームアップ が完了するのを待ってから、残りのインスタンス置き換えのバッチに進みます。 図 4: 終了して起動ポリシーを使用したインスタンス置き換えプロセス MinHealthyPercentage と MaxHealthyPercentage の値の違いは、インスタンス置き換えプロセスのスピードに影響することに注意してください。上の図では、Amazon EC2 Auto Scaling グループが各サイクルで 20% のインスタンスを置き換えています。 MinHealthyPercentage と MaxHealthyPercentage の間のギャップが大きいほど、置き換え処理は速くなります。 最大限の柔軟性を実現するカスタムポリシーの使用 MinHealthyPercentage と MaxHealthyPercentage の値を任意に設定できる カスタム動作 オプションも採用することもできます。このポリシータイプを使用すると、独自のニーズに合わせてインスタンスのメンテナンスポリシーを調整でき、置き換え動作を微調整したり、Amazon EC2 Auto Scaling グループ内のインスタンスの容量を制御したりすることができます。 置き換え処理における端数計算はどのようになるのか? Amazon EC2 Auto Scaling は、インスタンスの置き換えを実行するときは常に可用性を優先します。インスタンスメンテナンスポリシーが設定されている場合、Amazon EC2 Auto Scaling は MinHealthyPercentage を下回ることよりも、新しいインスタンスの起動を優先します。たとえば、希望容量が 10 インスタンスの Amazon EC2 Auto Scaling グループで、 MinHealthyPercentage が 99% に設定され、 MaxHealthyPercentage が 100% に設定されているインスタンスメンテナンスポリシーでは、1 つのインスタンス容量も減らすことはできません。そのため、Amazon EC2 Auto Scaling は終了前に起動することを優先し、置き換えが必要なインスタンスを終了する前に 1 つの新しいインスタンスを起動します。 インスタンスメンテナンスポリシーの設定は必須ではありません。インスタンスメンテナンスポリシーを使用するように Amazon EC2 Auto Scaling グループを設定しなければ、Amazon EC2 Auto Scaling グループの既存のインスタンス置き換えプロセスの動作に変更はありません。 CloudFormation または Terraform テンプレートを使用して、グループレベルのインスタンスメンテナンスポリシーを設定できます。テンプレート内で MinHealthyPercentage と MaxHealthyPercentage の両方の値を設定して、Amazon EC2 Auto Scaling グループの要件に沿ったインスタンス置き換え動作を決定する必要があります。 結論 本ブログ記事では、Amazon EC2 Auto Scaling グループの新しいインスタンスメンテナンスポリシー機能を紹介し、使用方法の例を示しました。インスタンスメンテナンスポリシー設定はすべてのインスタンス置き換えプロセスに適用され、インスタンスの更新機能の実行毎に設定を上書きすることもできます。インスタンスメンテナンスポリシーを設定することで、Amazon EC2 Auto Scaling グループ内のインスタンスの起動とライフサイクルを制御し、アプリケーションの可用性を高め、手動による介入を減らし、Amazon EC2 の使用に関するコスト管理を改善できます。 この機能の詳細と使用を開始する方法については、Amazon EC2 Auto Scaling ユーザーガイド を参照してください。 翻訳は Partner Solutions Architect 塩飽が担当しました。原文は こちら です。

昨今のデータドリブンな世界では、組織は拡大し続けるデータエコシステムから貴重な洞察を管理し、抽出する上で、前例のない課題に直面しています。データ資産とユーザーの数が増えるにつれ、データ管理とガバナンスに対する従来のアプローチではもはや間に合いません。顧客は現在、権限管理を分散化するためのより高度なアーキテクチャを構築しています。これにより、中央のガバナンスチームに律速されることなく、個々のユーザーグループが独自のデータ製品を構築して管理できるようになります。 AWS Lake Formation のコア機能の1つは、 AWS Glue Data Catalog のデータベース、テーブル、カラムなどのリソースのサブセットに対する権限をデータスチュワードに委任することです。これにより、誰がリソースにアクセスできるかを決定できるようになり、データレイクの権限管理を分散化できます。 Lake Formation にはデータスチュワードが 独自の Lake Formation タグを作成してアクセス権を管理できる機能 が追加されました。 Lake Formation タグベースアクセス制御 (LF-TBAC) は、属性に基づいて権限を定義する認証戦略です。 Lake Formation ではこれらの属性を LF タグと呼びます。 LF-TBAC は、データカタログリソースが多数ある場合に Lake Formation の権限を付与する方法として推奨されます。 LF-TBAC は、名前付きリソース方式よりスケーラブルで、権限管理のオーバヘッドも少なくて済みます。 この記事では、 LF タグの作成、管理、権限付与をデータスチュワードに委任するプロセスについて説明します。 Lake Formation は AWS アナリティクス全体にわたって大規模なユーザーのセキュリティ管理とガバナンスを簡素化することで、これらの高度なアーキテクチャの基盤として機能します。 Lake Formation は AWS アカウントかんの安全な共有と、権限を拡張できるタグベースのアクセス制御を提供することでこれらの課題に対処するように設計されています。特性とプロパティに基づいてデータ資産にタグを割り当てることにより、組織は特定のデータ属性に合わせたアクセス制御ポリシーを実装できます。これにより、権限のある個人またはチームのみがドメインに関連するデータにアクセスして操作できるようになります。例えば、顧客はデータ資産に「Confidential」というタグを付け、機密データにアクセスすべきユーザーにのみその LF タグへのアクセスを許可することができます。タグベースのアクセス制御は、データセキュリティとプライバシーを強化するだけでなく、効率的なコラボレーションとナレッジシェアリングを促進します。 単一アカウント、ハブアンドスポーク、中央ガバナンスによるデータメッシュなど、どのアーキテクチャを選択したとしてもデータガバナンスにおけるプロデューサーの自律性と分散型のタグ作成および委任の必要性は最も重要です。一元的なタグ作成とガバナンスのみに依存していると、ボトルネックが生じ、アジリティが妨げられ、イノベーションが阻害される可能性があります。プロデューサーとデータスチュワードに、特定のドメインに関連するタグを作成および管理する自律性を付与することで、組織はプロデューサーチーム間のオーナーシップと説明責任の意識を育むことができます。この分散型アプローチにより、変化する要件に迅速に適応して対応できます。この方法論は、組織が中央ガバナンスとプロデューサーオーナシップのバランスを取るのに役立ち、ガバナンスの向上、データ品質の向上、そしてデータ民主化につながります。 Lake Formation はこれらの課題に対処するためのタグ委任機能を発表しました。この機能により、 Lake Formation の管理者は AWS Identity and Access Management (IAM) ユーザーとロールにタグの作成、関連付け、そしてタグ表現の管理を行う権限を与えることができます。 ソリューションの概要 この記事では、複数のグループが私用している中央データレイクを持つ組織の例を検討します。このケースでは2人のペルソナがいます。1人は Lake Formation の管理者 LFAdmin で、データレイクを管理し、様々なグループにオンボーディングを行います。もう一方は組織内のセールスグループのリソースを所有し管理も行うデータスチュワード LFDataSteward-Sales です。ここでのゴールはデータスチュワードに権限を付与して、 LF タグを使用して所有するリソースに権限を付与できるようにすることです。さらに、組織には Confidentiality と Department と呼ばれる共通 LF タグがあり、データスチュワードはこれらを使用できます。 次の図はソリューションを実装するためのワークフローを示しています。 大まかな手順は以下の通りです。 LF タグを作成する権限を Lake Formation 管理者ではないユーザー用の IAM ロール LFDataSteward-Sales に付与します。 組織の共通の LF タグを LFDataSteward-Sales ロールに関連付ける権限を付与します。 LFDataSteward-Sales ロールを使って新しい LF タグを作成します。 LFDataSteward-Sales ロールを使って新しい一般的な LF タグをリソースに関連づけます。 LFDataSteward-Sales ロールを使って他のユーザーに権限を付与します。 前提条件 このチュートリアルは以下のものが必要です。 AWS アカウント Lake Formation の使い方と Lake Formation が一連のテーブルに対する権限を管理できるようにする方法に関する知識 Lake Formation 管理権限を有する IAM ロール。この記事では、その IAM ロールを LFAdmin とする。 LFAdmin によって作成された2つの LF タグ Confidentiality をキーとするバリュー PII と Public Department をキーとするバリュー Sales と Marketing 組織のデータスチュワードである IAM ロール。この記事では、その IAM ロールを LFDataSteward-Sales とする。 データスチュワードは少なくとも1つのデータベースに対してスーパーユーザーのアクセス権を持っている必要があります。この記事では、データスチュワードは3つのデータベース（ sales-ml-data 、 sales-processed-data 、 sales-raw-data ）へのアクセス権を持っています。 データスチュワードが LF タグを使用する権限を付与するユーザーとしての役割を果たす IAM ロール。この記事では、その IAM ロールを LFAnalysts-MLScientist とします。 データスチュワードに LF タグを作成できるよう権限を付与する 以下の手順を実行して LFDataSteward-Sales に LF タグを作成する権限を付与します。 LFAdmin ロールとして、 Lake Formation コンソールを開きます。 ナビゲーションペインの Permissions の下の LF-Tags and permissions を選択します。 LF-Tags では、 LFAdmin としてログインしているためアカウント内で作成されたすべてのタグを確認できます。 Confidentiality の LF タグと Department の LF タグ、そしてそれぞれのタグに指定できるバリューが表示されます。 LF-Tag creators タブで Add LF-Tag creators を選択します。 IAM users and roles では LFDataSteward-Sales の IAM ロールを指定します。 Permission では Create LF-Tag を選択します。 このデータスチュワードが他のユーザーに LF タグの作成権限を付与できるようにするには Grantable permission で Create LF-Tag を選択します。 Add を選択します。 LFDataSteward-Sales の IAM ロール独自の LF タグを作成する権限が付与されるようになりました。 一般的な LF タグが使えるようデータスチュワードに権限を付与する ここで Confidentiality と Department タグを使ってタグ付ける権限をデータスチュワードに付与したいと思います。以下の手順を実施します。 LFAdmin ロールとして、 Lake Formation コンソールを開きます。 ナビゲーションペインの Permissions の下の LF-Tags and permissions を選択します。 LF-Tag permissions タブで Grant permissions を選択します。 Permission type として LF-Tag key-value permission を選択します。 LF-Tag permission オプションは LF タグを変更または削除する権限を付与しますが、このユースケースでは適用されません。 IAM users and roles を選択し、 LFDataSteward-Sales の IAM ロールを指定します。 Confidentiality の LF タグではすべてのバリューを選択し、 Department の LF タグでは Sales のみを選択します。 Permissions では Describe 、 Associate 、 Grant with LF-Tag expression を選択します。 Grant permissions を選択します。 これにより、 LFDataSteward-Sales ロールは Confidentiality タグとそのすべてのバリューを使ってリソースにタグを付けることができ、 Department タグには Sales のバリューのみを使ってタグを付けることができるようになりました。 データスチュワードロールを使って新しい LF タグを作成する この手順では LFDataSteward-Sales のロールが独自の LF タグを作成する方法を示します。 LFDataSteward-Sales のロールとして、 Lake Formation コンソールを開きます。 ナビゲーションペインの Permissions の下の LF-Tags and permissions を選択します。 LF-Tags セクションには、 Confidentiality タグと、 Sales のバリューのみの Department タグが表示されます。データスチュワードとして、権限付与を簡単にするために独自の LF タグを作成したいと思います。 Add LF-Tag を選択します。 Key には Sales-Subgroups と入力します。 Values には DataScientists 、 DataEngineers 、 MachineLearningEngineers を入力します。 Add LF-Tag を選択します。 LF タグの作成者として、データスチュワードは自分が作成したタグに対する全ての権限を持っています。データスチュワードがアクセスできる全てのタグを見ることができます。 データスチュワードとして LF タグをリソースに関連付ける 機械学習エンジニアが sales-ml-data のリソースにアクセスできるように、先ほど作成した LF タグにリソースを関連付けます。 LFDataSteward-Sales ロールとして、 Lake Formation コンソールを開きます。 ナビゲーションペインで Databases を選択します。 sales-ml-data を選択し Action メニューから Edit LF-Tags を選択します。 以下の LF タグとバリューを追加します。 キーは Sales-Subgroups 、バリューは MachineLearningEngineers キーは Department 、バリューは analytics キーは Confidentiality 、バリューは Public Save を選択します。 データスチュワードとして LF タグを使って権限を付与する LF タグを使って権限を付与するためには、以下の手順を実施します。 LFDataSteward-Sales のロールとして、 Lake Formation コンソールを開きます。 ナビゲーションペインの Permissions の下の Data lake permissions を選択します。 Grant を選択します。 IAM users and roles を選択しアクセス権を付与する IAM プリンシパルを選択します（この例では Sales-MLScientist ロール）。 LF-Tags or catalog resources セクションで、 Resources matched by LF-Tags を選択します。 以下のタグ設定を入力します。 Department LF タグのバリューとして Sales Sales-Subgroups LF タグのバリューとして MachineLearningEngineers Confidentiality LF タグのバリューとして Public このロールは機械学習とデータサイエンスユーザーなので、データベースの管理とテーブル作成ができるように全ての権限を付与しようと思います。 Database permissions で Super を選択し、 Table permissions も Super を選択します。 Grant を選択します。 設定された LF-Tag expressions が表示されます。 ユーザーに付与された権限を検証する Amazon Athena を使ってアクセス権を確認するために、 Sales-MLScientist のロールとして Athena コンソールに移動します。 Sales-MLScientist のロールが sales-ml-data データベースと全てのテーブルにアクセスできるようになったことがわかります。このケースでは、テーブルは sales-report 1つのみ存在します。 クリーンアップ リソースをクリーンアップするために、以下を削除します。 この記事の内容に従って作成した IAM ロール 作成した LF タグ まとめ この記事では、分散型タグ管理のメリットと、新しい Lake Formation の機能がこれを実装するのにどのように役立つかについて説明しました。プロデューサーチームのデータスチュワードにタグ管理の権限を付与することで、組織は各自のドメイン知識を活用してデータの微妙な違いを効果的に把握できるようになります。さらに、データスチュワードに権限を付与すると、データスチュワードがタグ付けの主導権を握ることができ、正確性と関連性が確保されます。 この記事ではデータスチュワードに LF タグの作成や一般的な LF タグの使用許可を与えるなど、分散型の Lake Formation タグ管理に関連する様々な手順について説明しました。また、データスチュワードが独自の LF タグを作成し、タグをリソースに関連づけ、タグを使用して権限を付与する方法を示しました。 新しい分散型の Lake Formation タグ管理機能をぜひ試してみてください。詳細については、 Lake Formation tag-based access control をご参照ください。 本記事は、Ramkumar Nottath、Mert Hocanin による Decentralize LF-tag management with AWS Lake Formation を翻訳したものです。 翻訳はソリューションアーキテクトのJang Soohyeongが担当しました。

昨今のデータドリブンな世界では、様々なプラットフォーム間でデータを簡単に移動して分析できることが不可欠です。フルマネージド型のデータ統合サービスである Amazon AppFlow は AWS サービスと SaaS アプリケーション間のデータ転送を効率化する最前線に立ってきており、現在は Google BigQuery にも対応しています。このブログ記事では、Amazon AppFlowの Google BigQuery コネクタ がGoogle のデータウェアハウスから Amazon Simple Storage Service (Amazon S3) にデータを転送するプロセスを簡略化する手法と、マルチクラウドデータアクセスの民主化を含めたデータ専門家や組織にとっての大きなメリットについて解説します。 Amazon AppFlow の概要 Amazon AppFlow は Google BigQuery 、 Salesforce 、 SAP 、 Hubspot 、 ServiceNow などの SaaS アプリケーションと、 Amazon S3 や Amazon Redshift などの AWS サービスの間におけるデータの安全な転送を数回のクリックで実現できるフルマネージドなデータ統合サービスです。 Amazon AppFlow では、ほぼ全ての規模のデータフローを任意の頻度（定期実行、ビジネスイベントへの対応、オンデマンド）で実行できます。フィルタリングや検証などのデータ変換機能の設定だけで、すぐに使用できる豊富なデータをフローの一部として生成できます。 Amazon AppFlow では転送中のデータが自動的に暗号化され、 AWS PrivateLink と統合された SaaS アプリケーションではデータがパブリックなインターネットを通るのを制限できるため、セキュリティ上の脅威にさらされるリスクが軽減されます。 Google BigQuery コネクタのご紹介 Google BigQuery コネクタ は Google のデータウェアハウスの分析機能を利用し、 BigQuery からのデータを簡単に統合、分析、保存、または追加の処理を行い、実用的なインサイトに変換したいと考えている組織に可能性をもたらします。 アーキテクチャ Amazon AppFlow を使って Google BigQuery から Amazon S3 にデータを転送するアーキテクチャを確認してみましょう。 データソースを選択する： Amazon AppFlow でデータソースとして Google BigQuery を選択します。データを抽出するテーブルまたはデータセットを指定します。 フィールドマッピングと変換： Amazon AppFlow の直感的なビジュアルインターフェースを使ってデータ転送を設定します。必要に応じてデータフィールドをマッピングし、変換を適用してデータを要件に合わせることができます。 転送頻度：データ転送の頻度（毎日、毎週、毎月など）を設定できます。柔軟に設定でき、自動化に役立ちます。 送信先：データの送信先として S3 バケットを指定します。 Amazon AppFlow は効率的にデータを転送し、 Amazon S3 ストレージからデータにアクセスできるようにします。 消費： Amazon Athena を利用して Amazon S3 上のデータを分析します。 前提条件 このソリューションで使われるデータセットは合成患者集団シミュレータであり Apache License 2.0 に基づくオープンソースプロジェクトである Synthea により生成されるものです。 Amazon AppFlow と Google BigQuery アカウントの接続 この投稿では、 Google アカウント、適切な権限を持つ OAuth クライアント、および Google BigQuery データを利用します。 Amazon AppFlow から Google BigQuery にアクセスできるようにするには、事前に新しい OAuth クライアントを設定する必要があります。設定手順については、 Google BigQuery connector for Amazon AppFlow をご参照ください。 Amazon S3 の設定 Amazon S3 の全てのオブジェクトはバケットに保存されます。 Amazon S3 にデータを保存する前に、結果を保存する S3 バケットを作成する 必要があります。 Amazon AppFlow の結果を保存するための新しいS3バケットの作成 S3 バケットを作成するために、以下の手順を実施します。 Amazon S3 の AWS マネジメントコンソールから バケットを作成 をクリックします。 グローバルで一意の バケット名 を入力します（例： appflow-bq-sample ）。 バケットを作成 をクリックします。 Amazon Athena の結果を保存するための新しい S3 バケットの作成 S3 バケットを作成するために、以下の手順を実施します。 Amazon S3 の AWS マネジメントコンソールから バケットを作成 をクリックします。 グローバルで一意の バケット名 を入力します（例： athena-results ）。 バケットを作成 をクリックします。 AWS Glue データカタログのユーザーロール（ IAM ロール） フローとともに転送されるデータをカタログ化するためには、 AWS Identity and Access Management (IAM) における適切なユーザーロールが必要です。このロールを Amazon AppFlow に提供して、 AWS Glue Data Catalog 、テーブル、データベース、およびパーティションを作成するために必要なアクセス権限を付与します。 必要なアクセス権限を持つ IAM ポリシーの例については、 Identity-based policy examples for Amazon AppFlow をご参照ください。 デザインのチュートリアル それでは、実際のユースケースから Amazon AppFlow の Google BigQuery コネクタがどのように動くかを見てみましょう。このユースケースでは、 Amazon AppFlow を使って Google BigQuery からの履歴データを Amazon S3 にアーカイブし長期保存と分析を行います。 Amazon AppFlow の設定 Google アナリティクスから Amazon S3 にデータを転送するための新しい Amazon AppFlow フローを作成します。 Amazon AppFlow コンソール で フローを作成 をクリックします。 フロー名を入力します（例： my-bq-flow ）。 必要な タグ を追加します。例えば、 キー には env 、 値 には dev と入力します。 次へ をクリックします。 送信元名 で Google BigQuery を選択します。 新規接続を作成 をクリックします。 OAuth クライアント ID と クライアントシークレット 、そして接続名を入力します（例： bq-connection ）。 ポップアップウィンドウで、 amazon.com が Google BigQuery API にアクセスすることを許可するかと聞かれたら許可を選択します。 Google BigQuery オブジェクトを選択 で テーブル を選択します。 Google BigQuery サブオブジェクトを選択 で BigQuery プロジェクト名 を選択します。 Google BigQuery サブオブジェクトを選択 で データベース名 を選択します。 Google BigQuery サブオブジェクトを選択 で テーブル名 を選択します。 送信先名 で Amazon S3 を選択します。 バケットの詳細 では、前提条件として Amazon AppFlow の結果を保存するために作成した Amazon S3 バケットを選択します。 プレフィックス として raw を入力します。 次に、 AWS Glue データカタログ の設定を指定して、さらに分析するためのテーブルを作成します。 前提条件で作成した ユーザーロール （ IAM ロール）を選択します。 新しい データベース を作成します（例： healthcare ）。 テーブルプレフィックス を指定します（例： bq ）。 オンデマンドで実行 を選択します。 次へ をクリックします。 手動でフィールドをマッピングする を選択します。 Allergies テーブルから 送信元フィールド名 として次の6つのフィールドを選択します。 Start Patient Code Description Type Category フィールドを直接マッピングする を選択します。 次へ をクリックします。 フィルターを追加する セクションで、 次へ をクリックします。 フローを作成 をクリックします。 フローの実行 新しいフローを作成したら、オンデマンドで実行できます。 Amazon AppFlow コンソール で、 my-bq-flow を選択します。 フローを実行 をクリックします。 このチュートリアルでは、分かりやすいようにジョブのオンデマンド実行を選択してください。実際には、スケジュールされたジョブを選択して、新しく追加されたデータのみを定期的に抽出できます。 Amazon Athena を経由したクエリ オプションの AWS Glue データカタログ設定を選択すると、データカタログが作成され Amazon Athena からクエリを実行できるようになります。 クエリ結果の保存場所を設定するように求められたら、 設定 タブに移動して 管理 を選択します。 設定を管理 で、前提条件で作成したAthena結果バケットを選択し、 保存 を選択します。 Amazon Athena コンソール でデータソースとして AWSDataCatalog を選択します。 次に、 データベース として healthcare を選択します。 これで AWS Glue クローラーによって作成されたテーブルを選択してプレビューできます。 次のようなカスタムクエリを実行し上位10のアレルギーを検索することもできます。 注 ：以下のクエリから、テーブル名（ここでは bq_appflow_mybqflow_1693588670_latest ）を実際生成されたテーブル名に置き換えてください。 SELECT type, category, "description", count(*) as number_of_cases FROM "healthcare"."bq_appflow_mybqflow_1693588670_latest" GROUP BY type, category, "description" ORDER BY number_of_cases DESC LIMIT 10; 実行 をクリックします。 クエリの結果として件数で上位10のアレルギーが表示されます。 クリーンアップ 料金が発生しないようにするには、次の手順を実行して AWS アカウント内のリソースをクリーンアップしてください。 Amazon AppFlow コンソールのナビゲーションペインで フロー を選択します。 フローのリストから、 my-bq-flow を選択し削除をクリックします。 削除と入力しフローを削除します。 ナビゲーションペインから 接続 を選択します。 コネクタから Google BigQuery を選択し、 bq-connector を選択した上で削除をクリックします。 削除と入力し接続を削除します。 IAM コンソールのナビゲーションペインから ロール を選択し、 AWS Glue クローラーのために作成したロールを選択した上で削除をクリックします。 Amazon Athena コンソールを開きます。 AWS Glue クローラーが作成した healthcare データベース配下のテーブルを削除します。 healthcare データベースを削除します。 Amazon S3 コンソールで Amazon AppFlow の結果バケットを検索し、 空にする をクリックしてバケット内のオブジェクトを削除ます。その後、バケットを削除します。 Amazon S3 コンソールで Amazon Athena の結果バケットを検索し、 空にする をクリックしてバケット内のオブジェクトを削除ます。その後、バケットを削除します。 Google BigQuery リソースを含むプロジェクトを削除して Google アカウントのリソースをクリーンアップします。 クリーンアップ の手順に従ってリソースを削除します。 まとめ Amazon AppFlow の Google BigQuery コネクタは、 Google のデータウェアハウスから Amazon S3 へのデータ転送プロセスを効率化します。この統合により、分析、機械学習、アーカイブ、長期保存が簡素化され、 Google と AWS 両方のプラットフォームの分析機能を活用しようとしているデータ専門家や組織に大きなメリットをもたらします。 Amazon AppFlow を利用すると、データ統合の煩雑さが解消され、データから実用的な洞察を引き出すことに集中できます。履歴データをアーカイブする場合でも、複雑な分析を行う場合でも、機械学習のためのデータを準備する場合でも、このコネクタがプロセスを簡素化し、幅広いデータ専門家が利用できるようにします。 Amazon AppFlow を利用して Google BigQuery から Amazon S3 にデータを転送する方法に興味がある場合は、こちらの ビデオチュートリアル をご覧ください。このチュートリアルでは、接続の設定からデータ転送フローの実行までの全体のプロセスを説明します。 Amazon AppFlow のより詳細な情報は こちらのページ をご確認ください。 本記事は、Kartikay Khator、Kamen Sharlandjiev による Simplify data transfer: Google BigQuery to Amazon S3 using Amazon AppFlow を翻訳したものです。 翻訳はソリューションアーキテクトのJang Soohyeongが担当しました。

いつものことですが、1月22日週、 Amazon Web Services (AWS) の世界では多くのことが起こりました。また、世界中で開催されている AWS コミュニティ のイベントやイニシアチブにも興奮を隠せません。一緒に見ていきましょう! 1月22日週のリリース 私が注目したリリースを以下に記載しました。 Amazon Elastic Container Service (Amazon ECS) がマネージドインスタンスドレインのサポートを開始 – マネージドインスタンスドレインでは、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにデプロイされたワークロードを安全に停止して、終了していない他のインスタンスに再スケジュールすることで、正常にシャットダウンできます。この新機能を使用すると、新しい AMI バージョンのデプロイなどのインフラストラクチャのメンテナンスが合理化され、ワークロードを中断せずにインスタンスをシャットダウンするカスタムソリューションが不要になります。詳細については、Nathan の AWS Containers のブログ 投稿を参照してください。 Amazon Relational Database Service (Amazon RDS) for MySQL がマルチソースレプリケーションのサポートを開始 – マルチソースレプリケーションを使用すると複数の RDS for MySQL データベースインスタンスを 1 つのターゲットデータベースインスタンスのソースとして設定できます。この機能により、単一のターゲットへの複数のシャードのマージ、分析を目的としたデータの統合、単一の RDS for MySQL インスタンス内での長期バックアップの作成などのタスクが容易になります。詳細については、「 Amazon RDS for MySQL ユーザーガイド 」を参照してください。 Amazon EMR Studio での作成エクスペリエンスが簡素化され、起動時間が向上 – EMR Studio を作成するためのコンソール操作が簡素化され、インタラクティブなワークロードやバッチワークロードをデフォルト設定でより簡単に起動できるようになりました。起動時間が改善されたことで、EMR Studio ワークスペースを起動してノートブックでインタラクティブな分析を数秒で実行できるようになりました。詳細については、「 Amazon EMR ユーザーガイド 」を参照してください。 AWS のお知らせの完全なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 興味深いと思われるその他のプロジェクト、プログラム、ニュース項目をいくつかご紹介いたします。 Amazon Bedrock を使ってニュースを要約 – 同僚の Danilo が、 Amazon Bedrock を使用して RSS または Atom フィードから最新のニュースを要約する アプリケーション を構築しました。このアプリケーションは AWS Lambda 関数としてデプロイされます。この関数は、RSS または Atom フィードから最新のエントリをダウンロードし、リンクされたコンテンツのダウンロード、テキストの抽出、そして要約の作成を行います。 AWS コミュニティビルダープログラム  – AWS コミュニティビルダープログラムにご参加ください。 2024 年の応募締め切りは 1 月 28 日です 。AWS コミュニティビルダープログラムは、知識の共有と技術コミュニティとのつながりに熱心な AWS 技術愛好家に技術リソース、教育、ネットワーキングの機会を提供します。 AWS ユーザーグループ – AWS ユーザーグループ Yaounde Cameroon が 12 週間のワークショップチャレンジを開催しました。参加者は 12 週間にわたって、アーキテクチャ、セキュリティ、ストレージなど、AWS とクラウドコンピューティングのさまざまな側面を確認するとともに、スキルを磨いて知識を共有しました。このすばらしいイニシアチブの詳細については、 LinkedIn の投稿 を参照してください。 AWS オープンソースニュースと更新情報 – 私の同僚の Ricardo が 週刊のオープンソースニュースレター を執筆し、AWS コミュニティの新しいオープンソースプロジェクト、ツール、デモを紹介しています。 近日開催される AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Innovate: AI/ML and Data Edition – 2024 年 2 月 22 日に開催される アジアパシフィックおよび日本の AWS Innovate オンラインカンファレンス に登録して、人工知能 (AI) と機械学習 (ML) でイノベーションを生み出す方法を参照、検索、学習してください。3 か国語で提供される 50 以上のセッションから選択し、生成 AI ビルダー向けのテクニカルデモを実際に体験してください。 AWS コミュニティ re:Invent re:Caps – 世界中の AWS ユーザーグループと AWS クラウドクラブのボランティアが主催する コミュニティ re:Cap イベント に参加して、AWS re:Invent の最新の発表をご確認ください。 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます。 今週はここまでです。1月29日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください。 –  Antje この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

アマゾン ウェブ サービス (AWS) は Amazon Bedrock を初めとした生成 AI サービスを提供しています。Amazon Bedrock では、Amazon の基盤モデルだけでなく、Anthropic、Stability AI、Meta といった代表的な生成 AI モデルプロバイダーの基盤モデルが利用可能です。一方で、日本語という言語の特殊性などへの対応のため、国内事業者により日本語特化の大規模言語モデル (LLM) の開発が進められています。AWS ジャパンは、 LLM 開発支援プログラム などを通じて、お客様にとってのモデルの選択肢を拡充する活動を行っています。この度、LLM を AWS 上で簡単にデプロイしたりファインチューニングできるサービスである Amazon SageMaker JumpStart において、Stability AI 社が開発した日本語 LLM である Japanese Stable LM Instruct Alpha 7B v2 が利用可能になりました。SageMaker JumpStart に日本語 LLM を掲載するのは、 rinna 社に続いて 2 社目の事例となります。今回のモデル登録も AWS ジャパンとしての活動から生まれました。 本記事では、SageMaker JumpStart を通じて Japanese Stable LM Instruct Alpha 7B v2 モデルを探して、ノーコード、および SageMaker Python SDK でデプロイする方法を解説します。 Japanese Stable LM Instruct Alpha 7B v2 とは Japanese Stable LM Instruct Alpha 7B v2 は、Stability AI Japan によって開発された 70 億パラメータを持つ大規模言語モデルです。Transformer モデルのデコーダーのみで構成される自己回帰言語モデルである、 Japanese Stable LM Base Alpha 7B の事前学習モデルをベースに構築されており、さらにさまざまな指示 (instruction) データセットを用いて微調整されています。指示データセットを用いた微調整により、テキスト生成、テキスト要約、質問応答など、さまざまなゼロショットおよび少数ショット (few-shot) の自然言語処理タスクを実行することができるようになっています。Apache License 2.0 の条項に従い、無料かつ商用利用可能でオープンなモデルであることも特徴です。 SageMaker JumpStart とは SageMaker JumpStart は、機械学習の開発運用のプロセスを加速させることができるハブのサービスです。SageMaker JumpStart ではモデルカタログの機能も提供しており、幅広いタイプの基盤モデルが掲載されています。例えば、機械学習エンジニアの方々は、ネットワークから隔離された環境から専用の SageMaker インスタンスに基盤モデルをデプロイしたり、 SageMaker 上でモデルのトレーニングを実行してカスタマイズすることができます。なお、同じく複数の基盤モデルにアクセスできるサービスとして Amazon Bedrock がありますが、Amazon Bedrock はサーバーレスのサービスであり、インフラを考慮ぜずに使えるのが特徴です。逆に、SageMaker JumpStart ではニーズに合わせてインフラをコントロールできる点が異なります。 以降で解説するように、SageMaker Studio の GUI で数回クリックするか、SageMaker Python SDK を介してプログラム的に Japanese Stable LM Instruct Alpha 7B v2 をご自身の環境にデプロイすることができます。また、 SageMaker Pipelines などの SageMaker の MLOps 機能を使用して基盤モデルの運用を高度化することも可能です。モデルは AWS のセキュアな環境にデプロイされ、お客様の VPC 管理下に置くことも可能です。そのため、データセキュリティが確保されます。Japanese Stable LM Instruct Alpha 7B v2 モデルは、東京リージョン ( ap-northeast-1 ) を含めた複数のリージョンで利用可能です。 SageMaker JumpStart で Japanese Stable LM Instruct Alpha v2 をノーコードでデプロイする SageMaker Studio の GUI から SageMaker JumpStart を開くか、もしくは SageMaker Python SDK を利用して基盤モデルにアクセスすることができます。このセクションでは、SageMaker Studio でモデルを探す方法について説明します。 SageMaker Studio は統合開発環境 (IDE) であり、データの準備から機械学習モデルの構築、トレーニング、デプロイ、監視まで、機械学習の開発運用ライフサイクル全体をカバーする Web ベースのビジュアルインターフェイスを提供します。SageMaker Studio の開始方法とセットアップ方法の詳細については 開発者ドキュメント を参照してください。 SageMaker Studio にアクセスすると、左側のメニューより SageMaker JumpStart にアクセスできます。 SageMaker JumpStart を開くと、さまざまなモデルハブやモデルプロバイダーのリストが表示されます。今回は Stability AI のカードをクリックします。 Stability AI のページでは画像生成モデルである Stable Diffusion のいくつかのバージョンが選択できますが、それだけではなく、新しい Japanese Stable LM Instruct Alpha 7B v2 も表示されています。 Japanese Stable LM Instruct Alpha 7B v2 のカードを開くとモデルの詳細を確認できます。ここではモデルの説明、トレーニングに使われたデータセット、ライセンスなどが確認できます。右上の Deploy をクリックするとモデルデプロイ用の画面に遷移します。 推論エンドポイントの名前、インスタンスタイプ、インスタンス数、その他オプションをセットした上で右下の Deploy ボタンを押すとモデルのデプロイが開始されます。ちなみに、ここで選択している ml.g5.2xlarge は NVIDIA A10G Tensor Core GPU (GPU メモリ 24 GiB) が 1 台搭載されており、東京リージョンでは 1 時間あたり 2.197 USD で利用できる、推論用途に適したインスタンスです。インスタンスタイプごとの特徴は こちら 、SageMaker の料金は こちら を参照してください。 5-10 分ほど待機して、ステータスが In service に変わればデプロイは成功です。 SageMaker Python SDK でデプロイする もちろん GUI からモデルをデプロイするだけでなく、SageMaker Python SDK を用いてプログラム的にデプロイすることもできます。その際には、SageMaker Python SDK の JumpStartModel クラスで対象のモデル ID を指定し、 deploy() メソッドを呼ぶことで実行できます。 import sagemaker from sagemaker.jumpstart.model import JumpStartModel model_id = "model-textgenerationjp-japanese-stablelm-instruct-alpha-7b-v2" model = JumpStartModel(model_id=model_id) predictor = model.deploy() 後述するように、こちらの返り値の predictor を用いて推論自体を実行することもできます。 Japanese Stable LM Instruct Alpha 7B v2 で推論を実行する Japanese Stable LM Instruct Alpha 7B v2 は以下のような形式で入力を受け取ることを前提にチューニングされています。「 以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。 」という文章は常に固定であり、「 ### 指示: 」のセクションに質問事項や解きたいタスクの説明を与え、「 ### 入力: 」のセクションはオプション変数として指示に関する詳細情報や選択肢などの補足情報を必要に応じて与えます。そして、「 ### 応答: 」のセクションに LLM からの応答が入るという構成になっています。 以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。 ### 指示: 与えられたことわざの意味を小学生でも分かるように教えてください。 ### 入力: 情けは人のためならず ### 応答: このプロンプトの形式を一定に保つため、以下のように build_prompt 関数を用意し、 instruction と input のキーを持つ辞書をインプットとして、プロンプトを構築するような仕組みを用意することをおすすめします。以降のコードは SageMaker Studio から Code Editor などを開いて実行 してください。 input1 = { "instruction": "与えられたことわざの意味を小学生でも分かるように教えてください。", "input": "情けは人のためならず", } def build_prompt(instruction, input="", sep="\n\n### "): sys_msg = "以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。" p = sys_msg roles = ["指示", "応答"] msgs = [": \n" + instruction, ": \n"] if input: roles.insert(1, "入力") msgs.insert(1, ": \n" + input) for role, msg in zip(roles, msgs): p += sep + role + msg return p prompt1 = build_prompt(input1["instruction"], input1["input"]) プロンプトは JSON 形式にエンコードしていきます。 text_inputs キーにプロンプトの文字列を渡します。その他、 LLM の推論に関わるパラメーター も同時に渡すことができます。 payload = { "text_inputs": prompt1, "early_stopping": True, "no_repeat_ngram_size": 4, "max_new_tokens": 128, "do_sample": True, "temperature": 1.0, "top_p": 0.95, } 推論を実行するには、SageMaker のランタイムのクライアントを用意し、 invoke_endpoint API を実行します。 EndpointName には推論エンドポイントの名前、 ContentType には application/json 、 Body には JSON エンコードした上記のペイロードを渡します。すると、推論エンドポイントからのレスポンスが返ってきます。 import json import boto3 from pprint import pprint client = boto3.client("runtime.sagemaker", region_name=region_name) response = client.invoke_endpoint( EndpointName=endpoint_name, ContentType="application/json", Body=json.dumps(payload).encode("utf-8"), ) なお、Japanese Stable LM Instruct Alpha 7B v2 を ml.g5.2xlarge インスタンス 1 台にデプロイした推論エンドポイントを上記のスクリプトで 700 回実行して推論にかかる時間の統計を取ったところ、今回の設定では 2.09 s ± 102 ms (平均値 ± 標準偏差) という結果になりました。この結果は、インスタンスタイプや、インスタンス数、推論パラメーター (特に出力文の長さを調整する max_new_tokens ) に依存する点にはご注意ください。 さて、LLM からの出力 (completion) は Body キーに StreamingBody 形式で格納されているので、 read() で読み込みます。 prediction = json.loads(response["Body"].read()) generated_text = prediction[0][0]["generated_text"] pprint(generated_text) 生成されたテキストは以下のようになっています。今回は推論パラメーターの top_p (上位 p % のトークンを取得) と temperature (確率分布の散らばり具合を調整) をそれぞれランダム性が出るように設定しているため、推論を実行するたびに異なった出力文が生成されます。 # generated_text の中身 ('以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。\n' '\n' '### 指示: \n' '与えられたことわざの意味を小学生でも分かるように教えてください。\n' '\n' '### 入力: \n' '情けは人のためならず\n' '\n' '### 応答: \n' '「情けは人の為ならず」は、情けは他人のためを思ってかけるものですが、結果として、自分に恩恵が戻ってくるという意味です。') 応答部分だけ抜き出すと『 「情けは人の為ならず」は、情けは他人のためを思ってかけるものですが、結果として、自分に恩恵が戻ってくるという意味です。 』となっています。「情けは人の為ならず」ということわざは、三省堂のスーパー大辞林では『情けを人にかけておけば，巡り巡って自分によい報いが来るということ。』という意味であると説明されています。誤用されがちなことわざではありますが、Japanese Stable LM Instruct Alpha 7B v2 も辞書と同等の説明ができていることがわかります。 SageMaker Python SDK でモデルをデプロイした場合の推論方法 SageMaker Python SDK の JumpStartModel クラスの deploy() メソッドを用いてモデルをデプロイした場合、返り値の predictor を用いて推論を実行することができます。裏側では上記の方法と同様に invoke_endpoint が呼ばれていますが、複数の処理が隠蔽されており、シンプルな API で推論を実行することができます。 predictor.content_type = "application/json" prediction = predictor.predict( json.dumps(payload).encode("utf-8"), ) あと片付け SageMaker のリアルタイム推論エンドポイントは、起動中に課金され続けるため、検証が終わったら忘れずに削除してください。 sagemaker_client = boto3.client("sagemaker", region_name=region_name) # 推論エンドポイントの削除 sagemaker_client.delete_endpoint(EndpointName=endpoint_name) # SageMaker Python SDK を利用した場合 predictor.delete_endpoint() まとめ 本記事では、SageMaker Studio から SageMaker JumpStart に掲載されている Japanese Stable LM Instruct Alpha 7B v2 モデルを使い始める方法を紹介しました。SageMaker JumpStart を使うことで、動作が保証されているインスタンス上で最適化された推論コードを用いた推論エンドポイントの作成を行うことができます。基盤モデルは事前にトレーニングされているため、追加のトレーニングを行うことなく、ユースケースに合わせてすぐ利用を開始することができます。ぜひみなさんも SageMaker JumpStart から Japanese Stable LM Instruct Alpha 7B v2 を試してみてください！ 著者について 本橋 和貴 (Kazuki Motohashi) は、AWS Japan の機械学習パートナーソリューションアーキテクトです。AWS 上で機械学習関連のソフトウェアを開発しているパートナー企業の技術支援を担当をしています。好きなサービスは Amazon SageMaker です。週末は某世界旅行すごろく系ゲームを 1 人で 100 年分走り切る修行をしていましたが、挫折しています。

ガバメントクラウドに関する情報は AWS も含めてさまざまな方面から毎日のように発信されており、どの情報を追ったらいいのか、何を気にするべきなのかわからなくなってくることもあるかと思います。 そこで、このブログでは「ガバメントクラウドの道案内」と題して自治体ガバメントクラウドに携わる方がそれぞれ何を検討すべきで、どの資料を確認した方がいいのかを役割別にまとめています。 本ブログは自治体に業務システムを提供するベンダーの方へ向けた「ASP&運用管理補助者編」です。 そのほかの方に向けたブログに関しては以下リンクをご参照ください。 ガバメントクラウドの道案内: 『自治体職員編』 ガバメントクラウドの道案内: 『統合運用管理補助者編』 ガバメントクラウドの道案内: 『ネットワーク構築運用補助者編』 ガバメントクラウドの道案内:『ASP＆運用管理補助者編』(本ブログ) ガバメントクラウドではガバメントクラウドの個別領域 (AWS アカウント) の運用管理を行う事業者を「ガバメントクラウド運用管理補助者」、業務システムの構築・提供・運用保守など行う事業者を ASP として定義しています。 どちらか片方、もしくは両方に該当する事業者の方にご参考いただける内容となっています。 ここでは気にするべきポイントをステップに分けて紹介します。 「共同利用方式」か「単独利用方式」かを考える 自社の作業範囲を明確にする (共同利用方式の場合) 団体間の分離方式を確認する 運用保守経路を確保する モダナイズを検討する 利用できるベストプラクティスやサンプルがないか確認する それぞれの対応方法について概要と、どのように考えていくかをお伝えします。 (1) 「単独利用方式」か「共同利用方式」かを考える まずはガバメントクラウドの利用方式として「単独利用方式」か「共同利用方式」のどちらで自治体へ環境を提供するか考える必要があります。 単独利用方式の場合、自治体職員にも AWS アカウントの権限が払い出されます。共同利用方式の場合、ベンダーにのみ AWS アカウントを利用する権限が払い出されます。 共同利用方式では自治体が AWS アカウントの運用管理を個別に行わない前提となっているため、各自治体で要件の差が出づらいと考えられます。そのため複数の自治体へ業務システムを提供する場合、共同利用方式を選択し、 AWS CDK などの IaC や、監視のダッシュボード等を共通化しておくことにより、運用保守の工数や構築の初期費用を削減できることがあります。 「 地方公共団体情報システムのガバメントクラウドの利用に関する基準 【第 1.0 版】 」でもいくつかの理由から共同利用方式が推奨されています。 一方で、 Direct Connect ・ AWS Transit Gateway 等のネットワークを管理するアカウントは、自治体個別の要件が発生することが多いため単独利用方式になることが多いと考えられます。 ガバメントクラウドの道案内: 第 1 回『自治体職員編』: (4) 「共同利用方式」か「単独利用方式」かを考える では自治体職員の方の立場から 2 つの利用方式の違いについて記載しているため、こちらも併せてご参照ください。 (2) 自社の作業範囲を明確にする 自治体のガバメントクラウドの利用環境は、複数の事業者によって構成されるマルチベンダーの環境になることがほとんどです。 そのため、自社の作業範囲としてどこまでを担うか自治体の方と協議して決定する必要があります。それぞれの事業者の詳細な役割分担については、AWS Blog 自治体のお客様向け「ガバメントクラウド利用タスクリスト」を公開します をご参照ください。 例えば、以下の作業項目は自治体の方針に合わせて構成が変わってくるポイントのため、まずはじめに確認しておくことをお勧めします。 a. ASP 、運用管理補助者それぞれの役割の有無 まず、自社が AWS アカウントの管理を実施する「ガバメントクラウド運用管理補助者」としての業務、アプリケーションの構築・提供を行う「ASP」としての業務のどちらを担うか確認します。傾向としては、1 つの事業者が運用管理補助者と ASP を両方担うケースが多いようです。 運用管理補助者の業務も実施する場合、業務を提供する自治体が ガバメントクラウドの道案内:『統合運用管理補助者編』 に記載されている統合運用管理補助者を採用していないか確認し、統合運用管理補助者が実施する業務を確認し、それを基に運用管理補助者として実施しなければいけない業務を設計していきます。 b. 庁舎との接続 自治体から基幹業務システムを利用するためには、自治体庁舎と AWS 間を専用線で接続する必要があります。 以下の構成例は一例ですが、庁舎 – AWS 間を接続するために、 Direct Connect ・ AWS Transit Gateway を管理する事業者が必要です。 本ブログでは、庁舎との接続などネットワーク関連の作業を担当する事業者を「ネットワーク構築運用補助者」と呼びます。ネットワーク構築運用補助者の詳細については ガバメントクラウドの道案内:『ネットワーク構築運用補助者編』 をご確認ください。 自治体へネットワーク構築運用補助者に該当する事業者を採用しているか確認し、採用している場合はネットワーク構築運用補助者へ連絡を取り、自社で実施しなければならないネットワーク関連のタスクについて確認しましょう。 c. DNS サーバー 自治体の個人番号利用事務系ネットワーク内では、システムの名前解決にインターネットを利用することができないため、クライアントに提供されるシステムの名前解決を行う手段を提供する必要があります。 Amazon Route 53 Resolver インバウンドエンドポイントを利用することで、閉域網から AWS 上に構築されたシステムの名前解決を行うことが可能です。 インバウンドエンドポイントは、各 ASP・運用管理補助者が個別に管理する場合と、ネットワーク構築運用補助者や統合運用管理補助者が統合的に管理する場合が考えられるため、自治体の方針を確認し、自社のシステムの名前解決をどのように提供することになるか事前に把握しておく必要があります。 詳しくは ガバメントクラウドの道案内:『ネットワーク構築運用補助者編』 の「 DNS の設計について」をご確認ください。 d. Private CA 自治体の基幹システムの実装では「 地方公共団体情報システム非機能要件の標準 」において、すべての伝送データの暗号化をするように記載されています。 そのため、内部ネットワークからアクセスされる個人番号利用事務系のシステムでも TLS を利用した実装が必要です。TLS で通信を暗号化するために TLS サーバー証明書が必要となりますが、内部ネットワークでサーバー証明書を利用する場合 Private CA が必要となります。 ネットワーク構築運用補助者や統合運用管理補助者が統合的に Private CA を管理し各ベンダーにサーバー証明書を配布する場合と、各 ASP・運用管理補助者が個別に Private CA を管理する場合があるため、自治体の方針を確認し自社のタスクについて整理します。 AWS で Private CA を構築する場合、 AWS Private CA をご利用いただくことができます。 e. 認証認可サーバー (データ連携の方針) 「 地方公共団体情報システム共通機能標準仕様書 」にデータ連携機能の標準仕様が定められ、各標準準拠システムは一部の例外を除き、ガバメントクラウドの CSP が提供するオブジェクトストレージと REST API を利用したデータ連携が求められることとなりました。 ガバメントクラウド上のシステムとオンプレミスのシステムとの連携や、複数の CSP にシステムが分散している場合などでは、システム間の認証認可をどのように行うかが課題となります。標準仕様では自治体ごとに一台の認証認可サーバーを運用していくことが求められており、この認証認可サーバーの運用を行っているベンダーと連携をとる必要があります。 f. Active Directory との連携 業務システムのうち、ファイルサーバーなど Active Directory との連携が必要な場合があります。その場合、自治体で管理している Active Directory と連携が必要です。どのベンダーが Active Directory を管理しているのか、どの方式で Active Directory が構築されているのか (オンプレミス、 Amazon EC2 上の Active Directory、 AWS Managed Microsoft Active Directory ) を確認し、Active Directory と連携ができることを確認します。 (3) 団体間の分離方式を決定する 共同利用方式で業務システムの提供を行う場合、主に 3 種類の団体間のシステム分離方法が考えられます。 団体ごとに専用のアカウントを用意し、団体に関係するリソースをアカウントレベルで分離 (アカウント分離) 複数の団体でアカウントを共有、団体専用の VPC (閉域論理ネットワーク: Amazon VPC ) を用意し、主要なリソースを VPC レベルで分離 (ネットワーク分離) 複数の団体でアカウント、VPC、主要なリソースを共有し、アプリケーションレベルで分離 (アプリケーション分離) このうち、アプリケーション分離を採用できるかどうかはシステムやアプリケーションの実装に大きく依存することになるため、アカウント分離やネットワーク分離が採用されることが多くなることが想定されます。 ネットワーク分離では一部のサービスを団体間で共有することが可能でアカウント分離と比べると一定のコスト抑制効果を期待でき、アカウント分離では団体ごとの範囲を明確化することができる点、アカウントごとのクォータを気にする必要がない点がメリットと言えます。 それぞれの方式の特徴を把握し、提供する業務システムに合わせて選択します。 (4) 運用保守経路を確保する ガバメントクラウド上で構築した業務システムへの運用保守経路を構築します。自治体の基幹業務ではインターネット経由でシステムの運用保守を行うことができないため、以下のいずれかの方法を利用して業務システムの運用保守をする必要があります。 自治体庁舎へ赴き、自治体が保有している回線を利用して保守 ベンダの拠点と自治体庁舎が専用線で接続されている場合、自治体庁舎を経由して自治体が保有している回線を利用して保守 ベンダーが独自に専用線を利用してクラウドへの運用保守経路を構築 共同利用方式を選択している場合、3 の方法を選択する場合でも、自治体の数と同じ専用線を契約する必要はなく、1 つの専用線で複数の自治体の業務システムを運用保守できます。 3 の方法では、1 ベンダーが複数の自治体システムの運用保守を行うことが想定されます。その場合、複数の自治体のネットワークと運用保守 VPC の CIDR 重複が発生し得ます。 AWS PrivateLink を利用すれば、ネットワークアドレスが重複していても各業務システムと通信が行えるため、上記の図は AWS PrivateLink の利用を踏まえた構成図となっております。 (5) モダナイズを検討する ガバメントクラウドに構築するシステムは、ガバメントクラウドへの移行のタイミングをはじめ、継続的にシステムのモダナイズを検討することが求められます。これは一般的なシステムについても同様で、システムの構築後、適切なモニタリングを実施することで改善点を見つけ、より堅牢で効率の良いクラウドネイティブなシステムへと改善を繰り返すサイクルを構築することが重要です。 このサイクルを構築するために、主に 3 つの観点でモダナイズを検討していくことをお勧めいたします。 運用・監視業務のモダナイズ Amazon CloudWatch などのマネージドサービスを利用してシステム全体やアプリケーションの稼働状況を観測可能にします。 AWS における運用・監視について包括的に学ぶには One Observability Workshop の実施がおすすめです。 One Observability Workshop https://catalog.us-east-1.prod.workshops.aws/workshops/31676d37-bbe9-4992-9cd1-ceae13c5116c/ja-JP インフラストラクチャ構築・システム構築のモダナイズ AWS CloudFormation や AWS CDK を利用しインフラストラクチャの構築を自動化し、AWS Code シリーズによる CI/CD を実施しシステムのデプロイを自動化することで、高頻度のリリースをミスなく実行する環境を構築します。 AWS CDK について初歩から学ぶには、 TypeScript の基礎から始める AWS CDK 開発入門 がおすすめです。 TypeScript の基礎から始める AWS CDK 開発入門 https://catalog.workshops.aws/typescript-and-cdk-for-beginner/ja-JP アプリケーションのモダナイズ Amazon ECS や Amazon EKS を利用したアプリケーションのコンテナ化の検討や、 AWS Lambda を利用した機能のマイクロサービス化、 AWS Step Functions を利用したバッチ処理のマネージド化を検討します。 特に、アプリケーションをコンテナ化する上では以下の資料・ワークショップが参考になります。 クラウドにリフトしたアプリケーション をコンテナ化するためのアプローチ https://pages.awscloud.com/rs/112-TZM-766/images/AWS-48_Container_Modernization_KMD36.pdf コンテナ化のためのリアーキテクチャ https://catalog.us-east-1.prod.workshops.aws/workshops/a49e50ba-7473-4348-ba5d-6166385ad91d/ja-JP また、AWS ではこういったシステムのモダナイズを検討する上で指針となる情報を様々な形で発信しています。ぜひご活用ください。 AWS クラウドでのアプリケーションモダナイゼーション戦略 https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/strategy-modernizing-applications/welcome.html 今から始める！ AWS におけるクラウドのシステム運用入門 2020 年版 (動画) https://resources.awscloud.com/aws-summit-online-japan-2020-on-demand-aws-sessions-3-44912/aws-05-aws-summit-online-japan-2020-720p (6) 利用できるベストプラクティスやサンプルがないか確認する AWS では様々なシステムのサンプルアプリケーションおよびサンプルテンプレートを公開しており、標準準拠システムをガバメントクラウドに構築する際に重要となる閉域網におけるサンプルも提供しています。 閉域網アプリケーション サンプルテンプレート https://aws.amazon.com/jp/blogs/news/announcing-template-for-closed-network-system-workloads-on-aws/ 閉域網マルチテナントアプリケーション サンプルテンプレート https://aws.amazon.com/jp/blogs/news/multitenancy-app-with-keycloak-closed-network/ また、ガバメントクラウド向けのテンプレートがデジタル庁からも提供されており、Government Cloud Assistant Service (GCAS) などを通じて入手することが可能です。 ガバメントクラウド利用における推奨構成 (AWS 編) 地方公共団体情報システム認証機能に関するリファレンスガイド(AWS 編) このほか、AWS では継続してガバメントクラウドや標準準拠システムに資するサンプルテンプレートを公開していく予定です。 まとめ 本ブログでは、ASP・運用管理補助者となる事業者の方向けにガバメントクラウド上で業務システムを構築するうえで検討すべきポイントをご紹介しました。ガバメントクラウドを利用する際の不明点が少しでも取り除けていたら幸いです。 自治体に所属している方、または関連するベンダーパートナーの方でこのブログに関して追記した方がいいことやご不明点などございましたらお気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へお気軽にご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、全ての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介したタスクリストに関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

このブログは 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 翻訳はクラウドサポートエンジニアの富岡が担当しました。原文は こちら です。