監視はあらゆるリレーショナルデータベース管理システム (RDBMS) にとって重要な側面です。監視設定が適切であればデータベース設定の可視性と制御性が向上します。AWS のお客様の多くは、 Amazon CloudWatch メトリクスと Amazon Relational Database Service (Amazon RDS) のイベント通知を使用して、さまざまなメトリクスやイベントをモニタリングしています。 Amazon RDS イベントサブスクリプションは、 Amazon RDS for SQL Server のインスタンスレベルのモニタリングとアラートを提供します。ただし、データベースがオフラインになったり、オンラインに戻ったりしたときにアラートを出す直接的なメカニズムはありません。この記事では、RDS for SQL Server インスタンスがオンラインまたはオフラインになったときに Amazon Simple Notification Service (Amazon SNS) の通知を受け取る方法を説明します。 ソリューション概要 このソリューションでは、エラーログを Amazon CloudWatch ログに発行するように Amazon RDS for SQL Server を設定し、データベースの状態がオフラインまたはオンラインのときはいつでも Amazon SNS によるアラートを生成できるようにフィルタを設定します。 次の図は、ソリューションのアーキテクチャを示しています。 このソリューションの大まかな手順は次のとおりです。 Amazon RDS for SQL Server のエラーログを CloudWatch に公開します。 オフラインデータベースまたはオンラインデータベース用のフィルタパターンを作成します。 フィルターされたメトリクスのアラームを作成します。 前提条件 前提条件として、Amazon RDS for SQL Server をセットアップし、CloudWatch と Amazon SNS にアクセスできる必要があります。 Amazon RDS for SQL Server のエラーログを CloudWatch に公開 Amazon RDS for SQL Server のエラーログを CloudWatch に公開するには、DB インスタンスを変更する必要があります。以下のステップを完了してください。 このソリューションのコストについては、 Amazon RDS for SQL Server 、 Amazon CloudWatch 、 Amazon SNS の料金ページを参照してください。 Amazon RDS コンソール のナビゲーションペインで [ データベース ] を選択し、変更する必要がある DB インスタンスを選択します。 [ 変更 ] を選択します。 「 ログのエクスポート 」セクションで、CloudWatch への公開を開始するログを選択します。 [ エラーログ ] を選択します。 (オプション) [すぐに適用] を選択すると、変更がすぐに適用されます。 確認ページで、変更内容を確認します。内容が正しければ、[DB インスタンスを変更] を選択して変更を保存します。または、[戻る] を選択して変更を編集するか、[キャンセル] を選択して変更をキャンセルします。 オフラインまたはオンラインのデータベース用のフィルターパターンを作成 Amazon RDS for SQL Server のエラーログを CloudWatch に公開したので、次のステップはフィルターパターンを作成することです。以下のステップを完了してください。 CloudWatch console を開き、ナビゲーションペインの「ログ」セクションから ロググループ を選択します。お使いの DB インスタンスの Amazon RDS for SQL Server エラーログ (この記事では /aws/rds/instance/sql-database-ee/error ) を選択します。 [アクション] で [ メトリクスフィルターを作成 ] を選択します。 フィルターパターン に「 OFFLINE 」と入力します。 (オプション) 次の手順を使用して パターンをテスト できます。 「パターンをテスト」セクションの「テストするログデータを選択」ドロップダウンからテストするログデータを選択します (この場合は sql-database-ee.node2 ) [パターンをテスト] をクリックします。 [パターンをテスト] は、データベースの1つが OFFLINE 状態で、対応するエントリがエラーログにある場合にのみ機能します。 [ Next ] をクリックします。 フィルター名 、 メトリクス名前空間 、 メトリクス名 に「 OFFLINE Database(s)」と入力します。 メトリクス値 に「1」を入力します。 [ Next ] をクリックします。 [ メトリクスフィルターを作成 ] をクリックします。 同じ手順に従って、ONLINE データベース用のメトリクスフィルターを作成します。 フィルターパターン、フィルター名、メトリクス名前空間、メトリクス名を適宜変更します。 ユースケースに応じて、フィルター名、メトリクス名前空間、メトリクス名をカスタマイズできます。 フィルターされたメトリクスのアラームを作成 フィルターされたメトリクスのアラームを作成するには、次の手順を実行します。 OFFLINE Database(s) のフィルターを選択し、[ アラームを作成 ] をクリックします。 メトリクス名を入力します(この投稿では OFFLINE Database(s) )。 統計 で [ 最小 ] を選択し、 期間 を [ 30 秒 ] またはユースケースに応じて適切な値に設定します。 しきい値の種類 で [ 静的 ] を選択します。 [ より大きい ] を選択し、「0」を入力します。 [ 次へ ] をクリックします。 アラーム状態トリガー には [ アラーム状態 ] を選択します。 次の SNS トピック に通知を送信 で [ 新しいトピックの作成 ] を選択し、トピック名を入力します。(既存のトピックを使用することもできます)。 通知を受信するための有効なメールアドレスを入力してください。 [ トピックの作成 ] をクリックして、[ 次へ ] をクリックします。 アラーム名 に名前を入力します。 設定を確認して、[ アラームの作成 ] をクリックします。 SNS トピックが作成されたので、メールの Confirm subscription リンクをクリックしてサブスクリプションを確認してください。 同じ手順を繰り返してオンラインデータベースのアラームを作成し、それに応じて条件を調整します。 ソリューションのテスト ここで、SQL Server Management Studio (SSMS) を使用して Amazon RDS for SQL Server インスタンスに接続します。 次のスクリーンショットに示すように、データベース DemoDB を使用します。 Alter Database Set コマンドを使用して DemoDB データベースをオフラインにします。 次のスクリーンショットに示すように、SSMS でデータベースの状態を確認できます。 Alter Database Set コマンドを使用して DemoDB データベースをオフラインにします。 また、サブスクライブした E メール ID に通知メールが届きます。 次に、 rdsadmin.dbo.rds_set_database_online を使用して DemoDB をオンラインにします。 Alter Database db_name Set Online は Amazon RDS for SQL Server では機能しないため、このコマンドを実行すると次のエラーが表示されることに注意してください。 ただし、 rdsadmin.dbo.rds_set_database_online は正常に動作します。詳細については、「 Microsoft SQL Server データベースをオフラインからオンラインに切り替える 」を参照してください。 SSMS を使用してデータベースのステータスを確認できます。 また、データベースがオンラインであることを知らせるメールアラートも届きます。 主な考慮事項 シングル AZ の Amazon RDS for SQL Server を使用してこのソリューションを実演しました。インスタンスを再起動しても、オンラインまたはオフラインのデータベース通知は届かないことに注意することが重要です。これは、SQL Server が再起動後にデータベースの回復プロセスが実行されるためです。そのため、通知を受け取りたい場合は、Starting up database または Recovery is complete というフィルターパターンを使用してユースケースに応じたメトリクスフィルターを作成する必要があります。 SQL Server エラーログの抜粋を次に示します。 2023-04-13 05:17:19.570 spid29s Starting up database 'DemoDB'. ....... 2023-04-13 05:17:21.050 spid9s Recovery is complete. This is an informational message only. No user action is required. 後片付け 料金が発生しないようにこのソリューションを環境内でテスト目的で使用していた場合は、Amazon RDS for SQL Server インスタンスと CloudWatch ログをクリーンアップしてください。 CloudWatch ログを削除するには、次の手順を実行します。 Amazon CloudWatch コンソール に移動します。 左側のナビゲーションペインで、「ログ」セクションからロググループを選択します。 ロググループの検索フィールドにデータベース名を入力します (例 : sql-database-ee )。 ロググループ をクリックします。 [ アクション ] メニューから [ロググループの 削除 ] を選択します。 DB インスタンスを削除するには、 AWS マネジメントコンソール 、 AWS CLI 、または Amazon RDS API を使用します。RDS インスタンスを削除するのに必要な時間は、削除するデータ量、バックアップ保持期間 (削除するバックアップの数、最終スナップショットを取る必要があるかどうか) によって変わります。 Amazon RDS for SQL Server DB インスタンスを削除するには、下記のステップに従う必要があります。 Amazon RDS コンソール にアクセスしてください。削除保護が有効になっている場合はチェックを外し、次のステップに進む前にデータベースインスタンスを変更してください。有効になっていない場合は次のステップに進みます。 ナビゲーションペインで [ データベース ] を選択し、削除する DB インスタンスを選択します。 [ アクション ] メニューで [ 削除 ] を選択し、 [ 最終スナップショットを作成 ] を選択して、DB インスタンスの最終的な DB スナップショットを作成します。 最終スナップショットを作成する場合は、最終スナップショット名に名前を入力します。 自動バックアップを保持するには、[ 自動バックアップを保持 ] を選択します。 テキストフィールドに delete me と入力します。 [ 削除 ] をクリックします。 最後に、 SNS トピックとサブスクリプションを削除します 。 結論 この記事では、Amazon RDS for SQL Server のエラーログを CloudWatch に発行する方法、データベースがオフラインまたはオンラインのときに使用するメトリクスフィルタを作成する方法、SNS 通知と CloudWatch アラームを使用して E メールアラートを送信する方法について説明しました。このソリューションはこの記事で説明した内容に限定されません。メトリクスフィルタを使用して Amazon RDS for SQL Server のエラーログをスキャンして必要に応じてアラートを設定することができます。 Amazon RDS for SQL Server の詳細については、 Amazon RDS for Microsoft SQL Server を参照してください。この投稿についてコメントや質問がある場合は、コメントセクションに送信してください。 著者について Kanchan Bhattacharyya は、アマゾンウェブサービスのシニアデータベーススペシャリストテクニカルアカウントマネージャーです。彼は企業のお客様と連携して、データベースの運用パフォーマンスに関する技術支援を提供したり、データベースのベストプラクティスを共有したりしています。Amazon RDS for SQL Server、Amazon RDS for PostgreSQL、Amazon RDS for MySQL、Amazon を専門としています。     翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

はじめに AWS 上にシステム環境を展開する際に、アカウント単位でワークロードを分割するマルチアカウントという戦略があります。 マルチアカウント戦略 のベストプラクティスとして、ソフトウェア開発ライフサイクルごとにワークロードを分割することについて説明されています。その中で、開発環境、ステージング環境、本番環境がそれぞれ独自のアカウントを持つ戦略が推奨されています。 各環境に、アプリケーションをデプロイする際には、継続的インテグレーション/継続的デプロイ (CI/CD) パイプラインを活用してデプロイしたり、本番環境へのデプロイ前のテストや確認を行ったりします。 Amazon CodeCatalyst は、ソフトウェア開発チームが AWS でアプリケーションの計画、コーディング、ビルド、テスト、デプロイを始めるために必要なすべてをまとめた統合ソフトウェア開発サービスです。CodeCatalyst を利用することで、複数の AWS アカウントへの CI/CD パイプラインをセキュアで簡単に実現することができます。 本ブログでは、CodeCatalyst で Environment を利用した マルチアカウントデプロイの紹介をします。 前提条件 デプロイするための 2 つの AWS アカウントがあること。 CodeCatalyst にサインインするための AWS Builder ID を持っていること。 スペースに所属し、そのスペースの管理者ロールが自分に割り当てられていること。詳細は、「 Amazon CodeCatalyst でのスペースの作成 」、「 スペースのメンバーの管理 」、「 スペース管理者ロール 」を参照してください。 スペースに関連付けられた AWS アカウントを持ち、そのアカウントで IAM ロールを持っていること。ロールとロールポリシーの詳細については、「 CodeCatalyst サービスロールの作成 」を参照してください。 チュートリアル 概要 下記手順と図のように CodeCatalyst の CI/CD ワークフローから複数の AWS アカウントへデプロイするチュートリアルを行います。 CodeCatalyst のスペースに AWS アカウントを追加 デプロイ先となる AWS アカウントを Environment で設定 CodeCatalyst ワークフローの作成 複数の AWS アカウントへのデプロイの確認 CodeCatalyst の各用語について CodeCatalyst のコンセプト をご参照ください。 図1. CodeCatalyst から 開発環境と本番環境にデプロイ アプリケーションと AWS 環境は、Modern three-tier web application ブループリント を使用します。 CodeCatalyst ブループリントは、新しいプロジェクトのテンプレートを提供します。以下に沿って進める場合、「 Amazon CodeCatalyst でのスペースの作成 」で説明されているとおり、ブループリントを起動することができます。 これにより、以下に示すアーキテクチャがデプロイされます。本プログラムで使うブループリントの詳細は こちら をご確認ください。 図2. Modern three-tier web application ブループリントでデプロイされるアーキテクチャ CodeCatalyst のスペースに AWS アカウントを追加 ここでは、システムのデプロイ先となる AWS アカウントを CodeCatalyst のスペースに追加していきます。 AWS アカウントをスペースに追加することで、デプロイ先 AWS アカウントを増やしたり、CodeCatalyst の請求アカウントを管理したりすることができます。 下記手順に従って、CodeCatalyst のスペースに AWS アカウントを追加します。 CodeCatalyst スペースの画面に移動 Settings > AWS accounts に移動 追加する AWS account ID、CodeCatalyst で表示する display name、description を入力 Associate AWS account から追加 図3. CodeCatalyst スペースに AWS アカウントを追加する画面 Environment  の概要と各環境の設定 Environment では、アプリケーションがデプロイされる AWS アカウントの管理をすることができます。Environment には、develop、test、staging、production など、任意の名前を付けることができます。CodeCatalyst から Environment へのデプロイは、次項の手順にある CodeCatalyst ワークフロー内で定義する各 アクション に紐づけることで実現することができます。CodeCatalyst から Environment へのデプロイは、すべて Environment ページに表示されます。Environment を設定するには、 production などの名前を付け、それをスペースに追加した AWS アカウントに関連付けます。Environment では、デプロイメントのターゲット AWS アカウント、アクティビティ、デプロイメントターゲットの Amazon CloudFormation Stack 一覧をまとめて管理することができます。 Dev Environment と混同しないようにしてください。Dev Environment は、CodeCatalyst で利用できるクラウドベースの開発環境で、プロジェクトのソースリポジトリに保存されているコードに対してすばやく作業することができます。 下記手順に従って、Environment の作成をします。 ブループリントから立ち上げたプロジェクトの画面に移動 CI/CD > Environments に移動 ブループリントから作成された Environment に development があることを確認 図4. ブループリントから作成された Environment の画面 Create environment から新しく Production 用の Environment を作成 Environment name を「production」、Environment type を「Production」に設定 スペースに追加した AWS アカウントを AWS account connection に設定 Create environment から作成 図5. Environment の作成画面 CodeCatalyst ワークフローの設定 CodeCatalyst ワークフローでは、アプリケーションのビルド、テスト、デプロイを容易に行うことができます。ブループリントから立ち上げたプロジェクトの画面で、CI/CD > Workflows に移動します。既に、対象の ブループリントで定義されている CI/CD ワークフローである ApplicationDeploymentPipeline が確認できるかと思います。既にある ApplicationDeploymentPipeline に加えて、Production 環境にデプロイする CI/CD ワークフローを作成していきます。 最終的には、下記の図のように、Development 環境の Environment が関連づけられた CI/CD ワークフロー(左)、Production 環境の Environment が関連づけられた CI/CD ワークフロー(右) の2つのワークフローが存在する形になります。 図6. Development 環境と Production 環境のワークフロー 下記手順に従って、ワークフローの修正と作成をします。 既にある ApplicationDeploymentPipeline のワークフローのトリガーとなるブランチを main から development に変更 ApplicationDeploymentPipeline のワークフローをコピー & ペーストして新しい ApplicationDeploymentPipelineProduction という名前のファイルを同じディレクトリ内に作成 トリガーとなるブランチを development から main に変更 下記の変更のように、各 Environment に記載されている Name と Connections の Name を production に変更 図7. ApplicationDeploymentPipelineProduction ワークフローの変更内容 マルチアカウントデプロイ ここまでで、development ブランチにマージされた時に、Environment で定義した development 用の AWS アカウント に、main ブランチにマージされた時には、 Environment で定義した production 用の AWS アカウントへデプロイされます。 ここからは、実際に動作を確認してみます。Modern three-tier web application ブループリントの Readme にある Sample Change に従って変更し、デプロイをします。 development ブランチを作成 development ブランチから feature ブランチを作成 feature ブランチで 、Modern three-tier web application ブループリントの Readme にある Sample Change に従って変更 development ブランチへのマージ development 環境の Web サイトの確認 main ブランチに development ブランチをマージ production 環境の Web サイトの確認 各 Environment ごとのアクティビティを、Environment のページから確認することができます。 図8. Environment (development) のデプロイアクティビティの画面 図9. Environment (production) のデプロイアクティビティの画面 クリーンアップ このチュートリアルに従っていた場合、引き続き料金が発生しないように、デプロイしたリソースを削除する必要があります。まず、ブループリントを起動したときに関連付けた AWS アカウントで、CDK が AWS CloudFormation コンソールを使用してデプロイした 2 つのスタックを削除します。これらのスタックは、mysfitsXXXXXWebStack や mysfitsXXXXXAppStack のような名前を持っています。次に、Project settings に移動して Delete project ボタンをクリックし、CodeCatalyst からプロジェクトを削除します。 CodeCatalyst で発生する料金の 詳細は価格ページを参照してください 。 まとめ 本ブログでは、CodeCatalyst でマルチアカウントデプロイを実装しました。CodeCatalyst で、アプリケーションのデプロイ先 AWS アカウントの管理と CI/CD ワークフローに、AWS アカウントと関連づけた Environment を設定することで、簡単にマルチアカウントデプロイが可能となります。Environment を活用し、利用しているブランチ戦略に従ってマルチアカウントデプロイを実現してみましょう。 この記事の著者について 柳久保 友貴 ソリューションアーキテクトとして、ISV/SaaS 領域のお客様の技術支援を行っています。好きなサービスは Code シリーズです。好きな食べ物は、ラーメンです。

こんにちは！ アマゾン ウェブ サービス (AWS) でシニア ソリューション アーキテクトをしております、櫻田です。 普段はテクニカルな面から研究者の皆様のクラウド活用をサポートさせて頂いております。 シリーズでお送りしております「 高等教育機関におけるスケーラブルなセキュリティの必要性 」「 高等教育機関におけるサイバー攻撃に対する予防と準備 」はお読みいただけましたでしょうか。 前回までのブログでは 「Hartnell College」の事例 についてお伝えしました。これは大学がサイバーアタックを受け、ランサムウェアにより学内システムのサーバがロックされてしまった状況から、AWS を利用してシステムの復旧を迅速に行った事例でした。 海外での事例でしたので、 日本の研究コミュニティでは具体的にはセキュリティにどのようなリスクを抱えているか 疑問に思った方も少なからずいらっしゃるかと思います。 そこで今回はサイバー攻撃への対応準備のためのバックアップとリカバリについて考えてみたいと思います。 サイバーアタックには復旧のための新しい環境が必要になる Hartnell College の事例では全部のバックアップが揃っているわけでは無かったようですが、ゼロから AWS 上でシステムを立ち上げていき、大学の業務や講義を行えるよう迅速にシステムを構築されています。天災等で被害を受けハードウェアに被害が及んだ場合は、代替の環境が必要となることは容易に想像がつくでしょう。AWS を利用することで代替の環境をすぐに用意していくことが可能です。 ではサイバーアタックを受けた場合はどうでしょうか。 サイバーアタックを受けた場合には、手元のハードウェア自体は物理的には壊れていないことが多いでしょう。 そのため一見すると復旧するための環境が残っているため、天災等で被害を受けた場合と比べて復旧が容易と考える方もいらっしゃるかもしれません。 しかし本当にそうでしょうか。 実際は被害の状況の確認や他への被害拡大を防ぐために環境を隔離することが多いでしょう。 そうすると既存の環境は隔離されてしまうので、復旧には利用出来なくなります。また周辺の環境についても、どこまで侵害を受けているかが分からないため必要に応じて別の新しい環境が必要です。 迅速に復旧するには、このように 既存の環境とは別の新しい環境を用意しなければなりません 。AWSのクラウドを使えば、新しい環境を迅速に用意できます。 バックアップ自体が攻撃されていることも考慮が必要 さてバックアップはどうしょうでしょうか。 既にかなり前からシステムに侵入されてしまっていた場合、攻撃された後のデータが自動バックアップされて、最悪そのバックアップしか残っていない場合も考えられますし、 バックアップ領域自体も攻撃対象になりデータを損失してしまう可能性 も考えられます。 バックアップ領域が攻撃されたとしてもデータを守るには、Write Once Read Many ( WORM ) や Vault Lock 機能を使ってデータを改ざんから守ることが考えられます。 Amazon S3 や AWS Backup 等を使うことで、これらの機能は手軽に利用できますので、AWSを現在利用していない場合でも、バックアップを例えば Amazon S3 へ送ってこれら機能を活用することでデータを守ることができると考えられます。また平常時にバックアップからシステムを復旧する訓練は、復旧手順だけでなく、万が一バックアップデータの不足があったとしても気づくことができ有用ですのでお勧め致します。 また、AWS には Amazon GuardDuty、AWS CloudTrail や AWS Trusted Advisor などをはじめとしたセキュリティのベストプラクティスに対応していくための様々なサービスもありますので是非活用いただき、より安心できるシステムの運用をしていただければと思います。 この事例では、既存システムを単にAWS上で再構築をしただけでなく、新たに Amazon AppStream 2.0 を取り入れた事も記載されていました。 これにより学生は例えば CAD やデザインソフトウェアを使うためだけにコンピュータ教室に行く必要はなくなり、どこからでも手元の PC からソフトウェアにアクセスできるようになりました。学生の学びの環境の改善にもつながっているようです。このように新しいサービスを取り入れて環境を改善していくことも AWS を使えば容易になります。 最後に 今回のブログは前回のブログ「高等教育機関におけるサイバー攻撃に対する予防と準備」でお伝えした事例を元に、AWS を活用することで、データを守り、万が一何か起こった際にも迅速にシステムを再構築していくには何かできるかについてお伝えしました。安定的な運用だけでなく、新しい IT サービスの提供にも AWS を活用していただければと思います 相談したいことや疑問や思うことも多いかと思いますが、そのような時は お気軽に AWS までお問い合わせ頂ければと思います。 ご連絡はは下記よりお気軽にお問い合わせください 関連情報 サイト、問い合わせ お問い合わせ マイクロサイト : 大学・研究機関のための AWS 資料 教育・研究機関におけるAWS のはじめ⽅ 関連投稿 高等教育機関におけるスケーラブルなセキュリティの必要性 高等教育機関におけるサイバー攻撃に対する予防と準備 この記事を書いた人 櫻田 武嗣 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター シニアソリューション アーキテクト “業務や研究内容に適したシステム構成のディスカッション等を通して技術面から皆様にご支援をしております”

こんにちは！ アマゾン ウェブ サービス (AWS) で事業開発を担当しております、吉田です。 先に公開されました「 高等教育機関におけるスケーラブルなセキュリティの必要性 」ではグローバルにおける教育コミュニティで昨今重要視されている「セキュリティ」についてレポートのご紹介と一緒に詳細をご紹介させて頂きました。 さて、みなさんはこちらのお話どのように感じられたでしょうか？ 多くの方が研究活動においてセキュリティが大切であることは共感されたのではないかと思います。 今回は Hartnell College の事例から サイバー攻撃に対する予防と準備のために検討する項目 について触れてみたいと思います。 事例詳細は “ カリフォルニアの複数の拠点を持つコミュニティカレッジが、壊滅的なサイバー攻撃からどのように迅速に回復したか ” で詳しく説明しておりますので、フォームからダウンロードください。 サイバー攻撃は残念ながら高等教育において一般的な出来事となりつつあります。しかし、サイバーイベントが発生した場合に教育機関がレジリエンス（回復力）を発揮できるよう、リーダーの方々には先を見越して準備する方法があります。Hartnell College の経験から得た教訓に基づき、高等教育機関のリーダーは、サイバーイベントに対するより良い予防と準備のために、以下のステップを検討することができます。 1. IT 部門のプロセスの棚卸しと文書化 多くの大学や専門学校は、敷地内に大規模な IT インフラのフットプリントを有しています。 IT インフラ、ソフトウェア、セキュリティ対策を、（通常）小規模な IT 部門で最新の状態に保つことは、困難なことです。Hartnell Collegeの経験から、復旧に不可欠な要素は、最新の バックアップ目録ドキュメント 一式でした。このドキュメントを作成することは、サイバー問題またはイベントが発生した場合に回復するための最初のステップです。 2. リカバリー戦略を加速させるために、専門家に実装をアウトソーシングする。 多くの小規模な高等教育機関は、IT インフラをクラウドにうまく移行するための専門知識、リソース、経験を持っていません。 AWS パートナーとの連携 により、クラウドコンピューティングへの移行における参入障壁を減らし、取り除くことができます。 AWS パートナーネットワーク（APN）には、150 カ国以上から 10 万人以上のパートナーが参加しており、お客様はクラウドへの移行を加速させ、AWS が提供するサービスを最大限に活用することが可能になっています。 Hartnell College の近代化計画の一環として、Pham 博士はすでにカレッジの AWS アカウントチームと関わっており、高等教育での勤務経験を考慮して、AWS Select Tier Services Partner である Ferrilli のチームとカレッジの近代化計画に関する会話を始めていました。 サイバーインシデント発生後、Pham 博士は AWS と Ferrilli に連絡し、行動計画の策定を開始しました。1ヶ月足らずで、博士とそのチームは、AWS Control Tower と AWS Organizations を使用して、AWS 上のインフラをセットアップすることができたのです。Pham 博士は、Hartnell College のデジタルインフラをクラウドに移行することができたのは、AWS と Ferrilli のおかげであると評価しています。 3. バックアップとリカバリーの計画を立て、それを実践する Pham 博士は、最悪のシナリオにきちんと備えることを提唱しています。Hartnell にとって、AWS はクラウドで迅速に復旧するために重要な役割を果たしました。 AWS Well-Architected Framework の 5 つの柱の 1 つは信頼性で、 ディザスターリカバリー（DR）のための計画 の必要性が強調されています。 バックアップを AWS Backup に保存し、復旧に必要なリソースを迅速に利用頂くというオプションを、AWS は教育機関のお客様へ提供しています。また、AWS Elastic Disaster Recovery は、AWS への復旧によりダウンタイムやデータ損失を最小限に抑えるサービスです。教育機関のバックアップ戦略の範囲にかかわらず、AWS はプロセスを文書化し、緊急時に備えて復旧を実践することを推奨しています。 4. リーダーシップ、サポート、チームの結束が迅速な変革の鍵 Pham 博士は、サイバーインシデントやクラウドコンピューティングへの移行という困難な状況下で、Hartnell のリーダーシップチーム、Hartnell のコミュニティの学生や教職員のサポート、そして IT スタッフが団結し、サポートし、前進することができたと評価しています。 信頼関係があり、オープンマインドを備えた結束力のあるリーダーシップチームを持つことで、より速いスピードで変化を起こすことができます。Hartnell の IT インフラは現在、AWS でホストされています。Hartnell は、AWS の幅広いサービスを活用し、アクセシビリティとアジリティを向上させることで学生の成功をさらに高めるために、他の AWS マネージドサービスの機能についても検討を始めています。 このようにサイバー攻撃に対応するための準備は IT システムの棚卸しからはじまり、バックアップやリカバリー計画だけでなく、 リーダシップチームのサポートや組織作り も鍵となります。 最後に こうやって紐解いていくと、「備え有れば患い無し」ということがよくわかりますね。 次回は本記事でお話した中から、皆様がよく関心を持たれるバックアップを中心にお話を進めてみたいと思います。 関連情報 サイト、問い合わせ お問い合わせ マイクロサイト : 大学・研究機関のための AWS 資料 カリフォルニアの複数の拠点を持つコミュニティカレッジが、壊滅的なサイバー攻撃からどのように迅速に回復したか 関連投稿 高等教育機関におけるスケーラブルなセキュリティの必要性 高等教育機関におけるバックアップとリカバリ計画の考慮点 この記事を書いた人 吉田　尚子 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 事業開発マネージャー “AWSのサービスが、公共のお客様にどのような価値を提供できるのか、海外の事例を取り入れなが分かりやすくお届けいたします”

こんにちは！ アマゾン ウェブ サービス (AWS) で事業開発を担当しております、吉田です。 私は AWS の先進的なサービスを、いかに公共のお客様が抱えていらっしゃる課題解決の手段としてご利用頂けるかということを、お客様との対話、社内外への情報発信、提案素材の作成といった活動を通して、AWS が皆様へどのような価値を提供できるのかということを分かりやすくお届けするサポートをさせて頂いております。 こちらの記事では「セキュリティ」についてご紹介します。 セキュリティは、世界中の公共のお客様にとって優先事項の一つです。 研究分野では国境を越えた共同研究も活発化しており、研究データをいかにデジタル攻撃から安全に保護するかということは、教育機関の皆様にとっても考えていかねばならない項目となりつつあります。 また、関連資料として、グローバルに教育で取り組みべきことがどのように話されているのかをレポートにした資料もご紹介しており、このレポートではより詳細な情報が掲載されております。ぜひご確認下さい！ 2023 年 3 月 20 日に AWS Public Sector Blog 内で投稿された『 The top 3 innovation drivers in higher education in 2023 』という記事の中で、AWS の高等教育機関のお客様が、イノベーションを推進するための鍵として、2023 年に何を最優先事項としているかということを説明されています。 テーマは 3 つ挙げられており １つ目は『教育・学習における選択の幅を広げ、学生中心主義にする』 ２つ目が『研究コミュニティにおけるスケーラブルなセキュリティの必要性』 ３つ目が『組織のリーダーシップに新たに必要とされているサステナビリティ』 です。 今回はこの中で２つ目の『研究コミュニティにおけるスケーラブルなセキュリティの必要性』をご紹介いたします。 計算機研究がユビキタス化し、キャンパスや国境を越えてオンラインで共同研究を行う研究者が増えるにつれ、研究データを保護する必要性は、IT部門だけでなく教育機関のリーダーシップにとっても優先事項となっています。セキュリティに関する政府の要求により、教育機関では、貴重な知的財産を保護するためのスケーラブルなシステムとコントロールの確立を包括的に考える必要性がさらに強まっています。 サイバー攻撃は、高等教育機関における業務のあらゆる側面を脅かし、特に研究業務に深刻なリスクをもたらします。 科学の研究方法が変化したことで、数十年前とは異なるまったく新しいリスクが生まれており、これらの攻撃は、攻撃者へ支払われる金銭以上の影響を組織にもたらします。 カナダの British Columbia 大学の情報技術担当副学長兼最高情報責任者である Jennifer Burns 氏は、次のように述べています。 コストは、身代金だけではありません。取締役会、経営陣、ITチームがクリーンアップに費やす時間と労力もコストであり、例え迅速に対応したとしても６か月間かかる可能性があります。それはクリーンアップの請負業者にかかるコストでもああります。また、他の優先すべき事項への注意がおろそかになり、全体として考えた時に、これらの攻撃は多大な影響を与えるのです。 最新のレポート「 高等教育機関におけるイノベーションの鍵 」で、これらの優先事項の詳細や、教育機関のリーダーがどのようにクラウド技術を利用して最大の課題を解決し、教育機関の将来性を高めようと考えているかをご確認頂けます。 セキュリティの重要性を再確認できましたので、実際にオンプレミスで管理されていた大学のシステムがサイバー攻撃の対象となり、それをきっかけにAWSクラウドへの移行を迅速に推進されたという海外の事例 ( How Hartnell College recovered critical systems using AWS after a cyber attack ) をご紹介したいと思います。 サイバー攻撃後、Hartnell CollegeがAWSを使って重要なシステムを復旧させた方法 Hartnell College は、カリフォルニア州サリナスにある公立のコミュニティ・カレッジで、7,500 人以上の学部生が在籍しています（2020-2021）。2022 年春に最高情報システム責任者の Chelsy Pham 博士が着任したとき、カレッジは IT インフラの近代化の必要性を認識していました。Pham 博士と彼女のチームは、Amazon Web Services（AWS）への移行という長期的なビジョンを持っており、近代化を促進するためのクラウド戦略を策定している最中でした。 これが一変したのは、2022 年 10 月 2 日（日）午前 6 時のことでした。ネットワーク障害が発生したことから、サイバー攻撃の発生が疑われ、Hartnell の IT 部門はすべての内部ネットワークを停止させました。一時的に外部のウェブサイトやサービスにアクセスできなくなり、学内の教室のプロジェクターも使用できなくなりました。Hartnell College はサイバー調査員に依頼し、予備調査の結果、Hartnell College が高度なランサムウェア攻撃の被害を受けたことが判明しました。 同大学は可能な限りの復旧を行い、AWS 上でシステムの再構築を開始しました。AWS コンサルティングパートナーである Ferrilli のチームの協力により、中核となる学生情報システム（SIS）はすぐにクラウド上で稼働し、その後基盤インフラもクラウド上で稼働することになりました。これが Hartnell の IT チームが IT インフラを再構築して復旧をするはじまりとなりました。 彼らの復旧・再構築戦略の詳細については、ケーススタディ “ カリフォルニアの複数の拠点を持つコミュニティカレッジが、壊滅的なサイバー攻撃からどのように迅速に回復したか ” で詳しく説明しております。フォームからダウンロード可能です。 最後に いかがでしたでしょうか？ 日本においても同じような課題感があるのではないかと思います。 こちらの記事ではグローバルの取り組みや事例についてご紹介させて頂きましたので、次回はサイバー攻撃に対する予防と準備のために検討しておく項目をHartnell Collegeの事例から読み解いてみたいと思います。 関連情報 サイト、問い合わせ お問い合わせ マイクロサイト : 大学・研究機関のための AWS 資料 高等教育機関におけるイノベーションの鍵 カリフォルニアの複数の拠点を持つコミュニティカレッジが、壊滅的なサイバー攻撃からどのように迅速に回復したか 関連投稿 高等教育機関におけるサイバー攻撃に対する予防と準備 高等教育機関におけるバックアップとリカバリ計画の考慮点 この記事を書いた人 吉田　尚子 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 事業開発マネージャー “AWSのサービスが、公共のお客様にどのような価値を提供できるのか、海外の事例を取り入れなが分かりやすくお届けいたします”

8月28日週は AWS Summit Mexico で多くのお客様とパートナーにお会いする予定です。ほとんどの時間は、コミュニティラウンジと F1 Game Day で過ごします。機会があれば声をかけてください。AWS での開発経験について語り、AWS での構築についての皆さんのお話を伺うことを楽しみにしています。 8月21日週のリリース サービスチームが AWS イスラエル (テルアビブ) リージョン とも呼ばれる新しい il-central-1 リージョンにサービスを驚くほど迅速にデプロイしました。。8 月 1 日のリージョン提供開始以来、先週の 10 のサービスを始めとして 25 以上の新しいサービス発表 がありました。 新しいリージョンでのこれらの開発に加えて、8月21日週、私が注目したローンチをいくつかご紹介します。 AWS Dedicated Local Zones – Local Zones と同様に、 Dedicated Local Zones は、AWS によって完全に管理される AWS インフラストラクチャです。しかし、Local Zones とは異なり、お客様またはコミュニティ専用に構築されていて、規制要件を満たすためにお客様が指定した場所またはデータセンターに配置されます。これらは専用の AWS インフラストラクチャの一部だと考えることができます。 AWS re:Post の検索機能の強化 – AWS re:Post はクラウドナレッジサービスです。強化された検索機能を使用すると、回答や記事をよりすばやく見つけることができます。検索結果は、re:Post のすべての AWS ナレッジの統合ビューを表します。ビューには、検索クエリに関連する AWS ナレッジセンターの記事、質問と回答、コミュニティの記事が表示されます。 スケジュールされたプログラムによる Microsoft Excel へのエクスポートを Amazon QuickSight がサポート – Amazon QuickSight のダッシュボードのシートから複数のテーブルとピボットテーブルビジュアルを選択して Excel ワークブックのスケジュール生成を行うことができるようになりました。ページ分割 PDF と CSV に加えて、 Snapshot Export API が Excel 形式へのプログラムによるエクスポート をサポートするようになりました。 Amazon WorkSpaces が Ubuntu 20.04 と 22.04 をサポートする新しいクライアントを発表 – WorkSpaces Streaming Protocol (WSP) を搭載し、強化されたウェブ会議機能、マルチモニターサポートの向上、よりユーザーフレンドリーなインターフェイスを提供する新しいクライアントでは、リモートデスクトップエクスペリエンスが向上します。使用を開始するには、 Amazon WorkSpaces クライアントダウンロードのウェブサイト から新しい Linux クライアントバージョンをダウンロードしてください。 Amazon Sagemaker CPU/GPU プロファイラー – 大規模な深層学習ワークロード向けの高度なオブザーバビリティツールである Amazon SageMaker Profiler のプレビュー がローンチされました。この新機能を使用すると、コンピューティングハードウェアに関連するきめ細かいプロファイルインサイトにアクセスして、 モデルトレーニング のパフォーマンスを最適化することができます。 Amazon Sagemaker のローリングデプロイ戦略 –  ローリングデプロイ戦略を使用して Amazon SageMaker エンドポイントを更新できるようになりました。 ローリングデプロイ では、多数の一般的な高速コンピューティングインスタンスにデプロイされ、完全にスケールしたエンドポイントを簡単に更新できます。 AWS のお知らせの完全なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 皆さんが見逃した可能性があるその他の更新情報とニュースを紹介します。 AWS Lambda でのオンデマンドコンテナローディング – これは8月28日週の新しいトピックでははありませんが、休暇中に見つけました。 Marc Brooker のチームが「 On-demand Container Loading in AWS Lambda 」(pdf) で USENIX Association の Best Paper アワードを受賞しました。チームは、このドキュメントで AWS Lambda で (大規模な) コンテナイメージを読み込む際の課題について詳しく解説しました。 Lambda 関数が背後でどのように機能するか を知りたい方は必読です (pdf)。 AWS の公式ポッドキャスト  – 最新の AWS ニュースや興味深いユースケースの詳細情報を毎週お届けします。AWS の公式ポッドキャストは、数か国語で配信されています。 フランス語 、 ドイツ語 、 イタリア語 、および スペイン語 のポッドキャストもぜひご利用ください。 AWS オープンソースに関するニュースと最新情報  – 私の同僚である Ricardo  が厳選した情報をお届けする ニュースレター では、最新のオープンソースプロジェクト、記事、イベントなどが取り上げられています。 AWS の今後のイベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Hybrid Cloud & Edge Day (8 月 30 日) – 無料で参加できる 1 日のバーチャルイベントに参加して、ハイブリッドクラウドとエッジコンピューティングの最新のトレンドと新しいテクノロジーに関する講演を聴き、AWS リーダー、お客様、業界アナリストが紹介するベストプラクティスを学習してくだだい。詳細については、 詳細なアジェンダを参照して、今すぐ登録 してください。 AWS グローバルサミット – 2023 年の AWS Summit シーズンを締めくくるのは、 メキシコシティ  (8 月 30 日) と ヨハネスブルグ  (9 月 26 日) の 2 回の対面イベントです。 AWS re:Invent – re:Invent シーズン (11 月 27 日～12 月 1 日) が間もなく始まります。ぜひご参加ください。AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。  登録が開始されました 。 AWS Community Day   – AWS ユーザーグループが主催し、お住まいの地域のコミュニティが主導するカンファレンスにご参加ください。 ニュージーランド  (9 月 6 日)、 レバノン  (9 月 9 日)、 ミュンヘン  (9 月 14 日)、 アルゼンチン (9 月 16 日)、 スペイン (9 月 23 日)、 チリ (9 月 30 日) で開催されます。ランディングページにアクセスして、今後開催されるすべての AWS Community Day をチェックしてください。 CDK Day (9 月 29 日) – CDK と関連プロジェクトに関するコミュニティ主導の完全バーチャルのイベントです (英語とスペイン語)。 詳細については、ウェブサイトを参照してください 。 今週はここまでです。9月4日週に再びアクセスして、新たな Week in Review をぜひお読みください! この記事は、Week in Review シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! — seb 原文は こちら です。

2023/08/10 に「最新のサイバー攻撃の現状と Web セキュリティ対策 (WAF/DDoS対策) 実例セミナー」を開催いたしました。このセミナーでは最新のサイバー攻撃の現状および AWS が提供する Web セキュリティ対策サービスを AWS からご紹介し、AWS のサービスを組み合わせて、どのように Web セキュリティ対策を講じたかをお客様よりご説明いただきました。 それではここから当日のセッション内容について簡単にご紹介していきます。 2023第一四半期サイバー攻撃動向アップデート : 動画 アマゾン ウェブ サービス ジャパン合同会社 Edge Services ソリューションアーキテクト マネージャー 中谷 喜久 最初のセッションでは、前半は AWS Threat Intelligence について説明をしました。インターネットでは DDoS 攻撃、アプリケーションの脆弱性を突いた攻撃や悪質なボットによる攻撃等のリスクにさらされています。AWS では Threat Intelligence チーム（脅威分析チーム）と呼ばれる部隊がインフラを安心してご利用いただくために疑わしい IP や C2/Command and Control への通信経路など様々な脅威となる情報を収集し対応を行っています。これらで得られた知見を元に AWS ウェブアプリケーションファイアウォール (AWS WAF) , AWS Shield , Amazon GuardDuty などの AWS のサービスにフィードバックを行っていることをご紹介しました。また後半では、AWS Edge Services / Perimeter Protection と DDoS トレンドについて説明しました。AWS が観測したデータによると昨年に引き続き DDoS は大きな脅威であり、アプリケーションレイヤーへの DDoS 攻撃は 48% を占め、年間の DDoS 発生件数は 40% 増と増加傾向であり、2023年 Q1 での帯域とパケットにおける攻撃の最大値は 996 Gbps(bits)/480 Mpps(packets per second) であったことを紹介しました。最後に AWS Shield Global Threat Dashboard を見ることで Mpps、Gbps、Krps の値を見ながら DDoS のトレンドが確認できることをご紹介しました。 ウェブアプリケーションのセキュリティ向上に貢献する Amazon CloudFront と AWS WAF の最新機能のご紹介 : 動画 アマゾン ウェブ サービス ジャパン合同会社 Edge Services ソリューションアーキテクト 岡 豊 続いてのセッションでは 、エッジネットワークサービスである Amazon CloudFront と AWS WAF を活用した Web セキュリティ対策をご紹介しました。前のセッションでもお伝えしましたが、DDoS 攻撃、アプリケーションの脆弱性を突いた攻撃や悪質なボットによる攻撃等は年々増加する傾向にあります。 まず最初に Amazon CloudFront できる対策として、 HTTP メソッドやプロトコルの制限、アプリケーション特有のヘッダーを削除する CloudFront の設定 オリジン直接の攻撃からの保護方法として、 オリジンアクセスコントロール (OAC) および CloudFront マネージドプレフィックスリスト さらに AWS WAF を CloudFront にアタッチすることで、 事前定義済みのルールセットであるマネージドルールやカスタムルールの作成 不正ログイン対策として Account Takeover Prevention (ATP) Bot 対策として AWS WAF Bot Control DDoS 対策としてのレートベースルール 等、様々な機能が利用できることをご説明しました。また、 不正アカウント対策をする Account Creation Fraud Prevention (ACFP) 検査するボディサイズの拡張 等の AWS WAF の最新アップデートもご紹介しました。これらの機能を活用することでコスト効率を高め、セキュリティレベルを向上できることをお伝えしております。 以降のセッションでは Web セキュリティ対策についてお客様が取り組まれた事例をご紹介いただきました。 BookLiveにおけるWebセキュリティ対策 ～安心して読書を楽しめる環境を守る～ : 動画 株式会社BookLive 技術・開発本部システム開発部 SRE チーム マネージャー 日向野 達郎 様 株式会社BookLive 様は「ブックライブ」をはじめとした電子書籍ストアを運営するストア事業を含む 4 つの事業を運営されており、お客様がいつでも安心して読書を楽しめる環境を守るために、サイバー攻撃に対して素早く・柔軟に対応するための様々な取り組みを行われています。本セッションではこの取り組みについてご紹介いただきました。2016 年に AWS 完全移行が完了し安定稼働した状態でしたが、セキュリティに関して「知名度向上に伴ってサイバー攻撃を受けるリスクが高くなる」、「悪性 Bot による WEB サーバの負荷増やエラーレートの増加」という課題をお持ちでした。 この課題解決のために、 AWS WAF+WafCharm によるサイバー攻撃に対して柔軟かつ素早く対策する環境の構築 AWS Shield Advanced による、DDoS 攻撃の緩和 AWS WAF のレートベースルールによって、Bot による過剰なリクエストの抑制 を実現され、セキュリティ対策を行われています。更に Bot 対策では、将来的なリスク低減のために、IP アドレス以外を条件としたレートベースルールや AWS WAF Bot Control の導入をご検討されています。最後に、「 BookLive ではお客様がいつでも安心して読書を楽しめる環境を守るために、これからも積極的にセキュリティ対策のアップデートを実施していきます。」とのコメントを頂きました。 ココナラが膨大なセキュリティログの可視化と分析を実現するまで : 動画 株式会社ココナラ様は事業として「知識・スキル・経験」を売り買いできるスキルマーケットを中心に 4 つのプロダクトを展開されており、現在はココナラビジネスの領域が伸びている状況で会員数も右肩上がりになっています。2021 年 9 月に立ち上げた CSIRT は 2 名の組織（2023 年 8 月時点）で、セキュリティ施策の企画からモニタリング運用まで担当されています。そのため、優先度の高い施策を効率的に遂行することが不可欠となっています。本セッションではセキュリティログの分析の課題や勘所をご説明いただきました。AWS WAF や Elastic Load Balancing（ELB） のセキュリティログ分析には難しい点が 2 つあります。1 つ目はそのままのログ形式では読みづらく他のログとの相関関係が判断しにくいという点、2 つ目はログの量が膨大であり人力で確認することが非現実的という点です。その解決策としてアクセス状況や攻撃・インシデントの可視化・予測を行うことを目的として SIEM on Amazon OpenSearch Service を導入されました。結果、可視化 → 分析 → 改善とサイクルを回せるようになり、累計 1000 万回以上の悪意のあるアクセスをブロックし、正規ユーザーのアクセスを守ることができています。最後に、一度導入して終わりではなく運用後の改善やリアクティブではなくプロアクティブな仕掛け、セキュリティ強化を進めていくために経営層にセキュリティ対策の必要性・効果を理解してもらうことが重要であるとご説明いただきました。 おわりに 本ブログでは 2023/08/10 に開催された「最新のサイバー攻撃の現状と Web セキュリティ対策 (WAF/DDoS 対策) 実例セミナー」の内容についてご紹介しました。AWS からの最新情報発信だけでなく、お客様から事例をご紹介いただいた非常に学びの多いセミナーでした。最後に今回セミナーに参加いただいた皆さま誠にありがとうございました。引き続きの皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 このブログはソリューションアーキテクトの長谷川純也が担当しました。

この記事は、AWS の Sr. Security Partner Strategist である Cheryl Cage および AWS SaaS Factory チーム Sr. Partner Solutions Architect の Bill Tarr が執筆した  Importance and Impact of Compliance for SaaS Solutions on AWS を翻訳したものです。 Software-as-a-Service (SaaS) プロバイダーであれば、顧客が信頼のおける SaaS ソリューションを採用しようとしていることをよくご存知でしょう。貴社のソリューションが信頼でき、ニーズに合わせて拡張可能である中で、最も重要なことは、顧客の貴重なデータ資産を保護できるという信頼です。 セキュリティとプライバシーの標準に準拠することは、そのソリューションが業界標準を満たし、顧客の期待に沿ってユーザーデータを取り扱っていることを顧客に伝える効果的な方法です。 セキュリティポスチャを改善し、SaaS ビジネスを成長させる上で、コンプライアンスは戦略の重要な一部となり得ます。 法的要件: SaaS 企業は、データ保護、プライバシー、セキュリティに関連する様々な規制や法律の適用を受けることが多くあります。これらの規制を遵守することは、法的に義務付けられているだけでなく、高額な罰金や法的措置の回避にもつながります。 信頼と評判:  顧客は SaaS 企業に機密データを託し、それが保護されることを期待しています。業界標準や規制に準拠することは、信頼の構築と維持に役立ちます。 新規市場への参入: 特に規制の厳しい業界では、新規市場への参入や特定の顧客との取引に際して、特定の基準や規制の遵守が求められる場合があります。 リスク管理: コンプライアンスは、SaaS 企業がデータ保護とセキュリティに関連するリスクを特定し、管理するのに役立ちます。その要件には、リスクを軽減し、データ侵害を防止するためのポリシー、手順、およびコントロールの実装が含まれることがよくあります。 コンプライアンスに対応した計画を構築することは、SaaS ソリューションの設計やアーキテクチャにも影響を与え、将来的な技術的負債を回避するのにも役立ちます。 この記事では、SaaS プロバイダーがコンプライアンスに準拠したソリューションを設計・構築する際に考慮する必要があるいくつかの要素を分類し、それらに関連する Amazon Web Services (AWS) 内のリソースやサービスをご紹介します。 セキュリティ基盤としてのコンプライアンス セキュリティとプライバシーのフレームワークは、サイバーセキュリティプログラムを構築し、ポリシーと手順を確立するためのツールを提供し、情報の機密性、可用性、完全性を保護するために必要な技術的な管理を実装します。これらのフレームワークは、リスクを管理し、脆弱性を低減するための青写真を提供し、組織が直面するリスクと攻撃者がセキュリティの弱点をどのように悪用するかを考慮するように設計されています。 SaaS プロバイダーにとって、これらのフレームワークは自社のソリューションが、政府の法律や特定業界の規制に関わらず、顧客のセキュリティ要件を満たしていることを証明するために使用することができます。 場合によっては、企業は業務改善や競争力強化のために、Service Organization Control 2 (SOC2: サービス組織の統制) や International Organization for Standardization 27001 (ISO27001: 情報セキュリティマネジメント) などの認定や認証を取得することがあります。また、支払いカード情報や個人情報 (PII) や、その他のセンシティブなデータをどのように取り扱うかについて、規制遵守義務を果たし法律を遵守しなければならない場合もあります。 フレームワークのセキュリティ要件は、一般的にセキュリティのある側面を定義する一群の統制に対応します。これらの管理策は、準拠の自己宣誓を要求する場合もあれば、第三者による宣誓を要求する場合もあります。第三者による宣誓の場合は、定期的なレビュー形式をとる場合もあれば、管理策の準拠状況を監視するシステムによる継続的な準拠を要求する場合もあります。 コンプライアンスの達成は継続的なプロセスとなりますが、定期的なモニタリングとレポーティングを行うことで、これらのフレームワークの遵守をビジネス運営の標準的な部分とすることができます。適切なセキュリティ管理、データプライバシー、データ管理は、SaaS アプリケーションの最初から基本的な構成要素であるべきです。 責任共有モデルとコンプライアンス AWS 上に SaaS を構築されるプロバイダーにとって、コンプライアンスの観点から 責任共有モデル を理解することは重要です。AWS は継続的に監査を受けており、SOC 2、ISO 27001、 Federal Risk and Authorization Management Program (FedRAMP: 米国政府機関におけるクラウドセキュリティ認証制度)、 Payment Card Industry Data Security Standard (PCI DSS: クレジットカード業界の情報セキュリティ基準) など、 世界中の認証や認定 を維持し、顧客がセキュリティやコンプライアンス要件を満たせるよう支援しています。 AWS クラウド上でシステムを構築する場合、AWS とお客様 (SaaS プロバイダー) はこれらのコンプライアンス責任を共有します。以下の 図 1 で示すように、コントロールによっては AWS から継承されたり、共有されたり、あるいは顧客の責任となるものもあります。 AWS が SOC 2 認証、FedRAMP 認証、ISO 認証を持っているように、コンプライアンスが必要な SaaS プロバイダーも同じコンプライアンスプロセスを経なければなりません。SaaS プロバイダーは、自社の環境を構成するサービスの範囲内で、どのコンポーネントに責任があるのかを理解することが重要なのです。 図 1 – AWS の責任共有モデル SaaS アーキテクチャを計画する上で重要なリソースをいくつか挙げてみます。 Customer Compliance Guides (CCG) は、AWS サービスの設定可能なオプションと、一般的なフレームワーク (SOC 2、ISO 27001、FedRAMP、 National Institute of Standards and Technology Cybersecurity Framework (NIST CSF)) にマッピングされたコンプライアンスのトピックとコントロール要件に基づいて、AWS のセキュリティプラクティスの統合ビューを提供します。 コンプライアンスプログラムによる対象範囲内の AWS のサービス は、特定のコンプライアンスフレームワークや規制に対して評価され、承認されたサービスのリストです。例えば、 Health Insurance Portability and Accountability Act  (HIPAA: 米国の医療保険の携行性と説明責任に関する法律) については、お客様は HIPAA アカウントとして指定されたアカウントで AWS サービスを使用することができますが、このページおよび Business Associate Addendum (BAA: 業務提携補遺) で定義された HIPAA 適格サービスにおいてのみ、保護されるべき医療情報 (PHI) を処理、保存、送信することができます。 AWS Artifact は、AWS のコンプライアンスレポートへのアクセスを提供し、AWS と SaaS プロバイダーであるお客様との間で、コンプライアンスに関する監査から要求される可能性のあるアグリーメントを提供します。一部のレポートでは、「クラウドの」継承可能なコントロールがリストアップされ、共有されるコントロールの範囲とその責任をお客様が理解するのに役立ちます。 SaaS アーキテクチャにおけるコンプライアンスの影響 以降のセクションでは、コンプライアンスに関する懸念が、SaaS における数々のコアコンセプトに関する考え方に、どのような影響を与えるかを検証していきます。その際、 SaaS アーキテクチャの基礎 に関する AWS ホワイトペーパーと、 AWS Well-Architected Framework の SaaS レンズ を参照していきます。一般的な SaaS ガイダンスとして、これらのガイドを参照してください。 テナント分離の意味 テナントの分離とは、テナントのリソースを保護し、他のテナントのリソースへのアクセスを拒否するプロセスです。SaaS においてテナントインフラを分離する選択肢は、主に「サイロ」と「プール」に分けられます。SaaS ホワイトペーパーの「フルスタックのサイロとプール」セクションにてその背景をご確認ください。 図 2 – サイロ型とプール型のテナント分離モデル コンプライアンスフレームワークや規制、特に規制の厳しい業界を対象とするコンプライアンスフレームワークや規制が、プールされたリソースの使用を禁止しているというのは誤解です。実際、ほとんどのフレームワークではテナントの分離に関するガイダンスは提供されておらず、FedRAMP でさえ、主に「あるテナントの暫定的なアクセスを使用して別のテナントを侵害しようとする完全なアプリケーションテスト」( FedRAMP Penetration Test Guidance ) を指定しています。 「アーキテクチャの全レイヤーにわたって分離戦略を導入し、テナントリソースへのアクセスの試みが現在のテナントコンテキストに対して有効であることを保証する、特定の構造を提供する」( SaaS Lens ) ことを証明できるように準備してください。 リソースをプールするのであれば、アプリケーションの各レイヤーで分離ポリシーが適用されていることが重要です。図 3 では、API、コンピュート、ストレージの各レイヤーでどのように分離ポリシーを適用する必要があるかがわかります。 AWS Identity and Access Management (IAM) はプールされたリソースの分離に不可欠であり、 Dynamic Policy Generation (動的なポリシーの生成) や Attribute Based Access Control (ABAC: 属性ベースのアクセス制御) のような技術は、分離ポリシーを適用するメカニズムを提供します。 図 3 – SaaS ソリューションにおける分離ポリシー ほとんどのコンプライアンスフレームワークでは、プールされたリソースを明示的に禁止していないにもかかわらず、規制の厳しい業界にサービスを提供する SaaS プロバイダーは、顧客の要望に対応する必要がある場合があります。このようなサイロ型リソースのリクエストに対応するために、より高コストの価格設定階層としてサイロ型リソースが必要になる場合があります。 コンプライアンスを遵守したテナントオンボーディング サイロ環境では、すべてのテナント環境で同じ準拠バージョンのソフトウェアを実行していることを確認する必要があります。新しいテナントが加わり、ソフトウェアの新バージョンを展開する際には、すべてのテナントが実行しているバージョンがコンプライアンス基準を満たしていることを保証する必要があります。 図 4 – コンプライアンスを遵守したテナントのオンボーディング AWS Organizations と AWS Control Tower は、テナントの一元的なプロビジョニングと、アカウントの偶発的な変更を防止する サービスコントロールポリシー (SCP) のガードレールの設定を支援します。また、 Landing Zones Accelerator on AWS (LZA) は、 ログアーカイブと監査アカウント によるセキュリティ構成の設定を支援し、アクティビティの証跡を監査が利用できるようにします。 データストレージにおけるコンプライアンスの影響 SaaS ソリューションにおけるデータに関する議論は、テナントデータのパーティショニング方法を理解することから始まります。ある意味、これはテナントの分離と似ていますが、次のことを考慮してください。「データパーティショニングとテナント分離は、しばしば互換性があるとみなされがちです。この 2 つの概念は等価なものではありません。データパーティショニングというのは、個々のテナントのデータをどのように保存するかということです。」( SaaS ホワイトペーパー ) テナントの分離と同様に、コンプライアンス目的でデータをどのように分割するかを検討する必要があります。これには分離の問題だけでなく、データの機密性に基づいて分離を決定することも含まれます。 図 5 – センシティブな SaaS データの分離 データパーティショニングの決定は、データの暗号化要件、バックアップとリストアのポリシー、データ保持、データ主権、オフボーディングに関与する可能性があります。 例えば、 Amazon Simple Storage Service (Amazon S3) のバケットとそのフォルダは、デフォルトで AWS Key Management Service (AWS KMS) で暗号化するように設定することができ、テナント固有のキーで暗号化されたデータのオプションを提供します。 図 6 – テナント Amazon S3 データの暗号化 マルチテナントの監査、ログ、モニタリング ログ、トレース、メトリクスを含め、アプリケーションが出力するすべてのものにテナントの概念をインジェクトする必要があります。コンプライアンス目的のためには、ログが一元化されたログソリューションに集約され、監査アカウントでログへのアクセスが制限されていることを確認することが重要です。 リソースへのアクセス履歴を確認するためはに、すべてのアカウントとリージョンに対して AWS CloudTrail をオンにします。例えば、 Amazon API Gateway への呼び出しのログ記録 や Amazon Cognito API 呼び出しのログ などです。 テナントアイデンティティの管理 テナントユーザーとその SaaS ソリューションへのアクセスも管理する必要があります。これには、ユーザーが認証され、特定のテナントコンテキストに接続されていることを確認することも含まれます。このコンテキストには、先ほど説明したロギングやモニタリングなど、アプリケーションの各レイヤーに渡す情報が含まれます。 テナントのサービスやロジックがソリューション全体に分散するのではなく、テナントのアイデンティティを一元管理することで、コンプライアンスに関するストーリーが強化されます。ID プロバイダ (IdP) を活用することで、アイデンティティ管理に継承可能なコントロールを提供し、コンプライアンス遵守への道筋を簡素化することができます。 セキュリティとコンプライアンスを始める SaaS のコンプライアンスが困難である理由をいくつか見てきました。多くの SaaS プロバイダーにとって、これは顧客がどのようなコンプライアンスフレームワークを要求するかがまだ分からなくても、少しずつ前進することを意味するかもしれません。 コンプライアンスフレームワークによって定義された多くのコントロールと要件は、クラウドアーキテクチャのベストプラクティスに基づいています。AWS は、お客様のソリューションがベストプラクティスに従っていることを確認できる無償のリソースをいくつか提供しており、それらは将来のコンプライアンス要件を見越してアーキテクチャを準備するのに役立ちます。 AWSスタートアップセキュリティベースライン : 初期段階のスタートアップ企業のニーズに合わせてカスタマイズされた、最小限の無料コントロールセットです。 AWS Well-Architected Tool : AWS のベストプラクティスを AWS コンソールですぐに確認でき、 SaaS レンズ のような追加レビューもここから確認することができます。 AWS ファンデーショナルテクニカルレビュー (FTR): AWSパートナー向けの FTR は、自己評価と SaaS ワークロードの AWS における検証を組み合わせたものです。 Center for Internet Security (CIS) AWS Benchmarks と CIS Controls : AWS CIS Benchmarks は、業界のセキュリティ専門家によって合意されたセキュアな設定のベースラインを提供し、CIS Controls は、システムとネットワークセキュリティのための包括的なベストプラクティスガイドです。 AWS パートナーネットワーク (APN) のメンバーは、 AWS Global Security and Compliance Accelerator (GSCA) を含む、SaaS プロバイダーが顧客のコンプライアンスニーズを満たすためのプログラムを活用することができます。 AWS SaaS Factory プログラムは、SaaS のあらゆる段階で SaaS プロバイダーに専門的なガイダンスを提供します。 まとめ この記事では、AWS におけるコンプライアンスの様々な側面を検証し、SaaS のベストプラクティスとコンプライアンス要件を照らし合わせながら、SaaS アプリケーションを設計、構築する際に留意すべき事項について検証してきました。 SaaS ソリューションを構築する際に、コンプライアンスのベストプラクティスに合わせるために活用できる数多くの無償リソースをご紹介し、最後に、AWS コンプライアンスサービスを使用してソリューションを監視する方法について説明しました。 AWS SaaS Factory について AWS SaaS Factory は、SaaS 導入のどの段階の企業でも支援します。新製品の構築、既存のアプリケーションの移行、AWS 上での SaaS ソリューションの最適化など、どのようなご要望にもお応えします。 AWS SaaS Factory Insights Hub では、技術的、ビジネス的なコンテンツやベストプラクティスをご覧いただけます。 また、SaaS 開発者の方は、エンゲージメントモデルや AWS SaaS Factory チームとの連携について、アカウント担当者にお問い合わせください。 こちらにご登録 いただくと、最新の SaaS on AWS ニュース、リソース、イベントの情報を入手できます。 AWS Global Security and Compliance Acceleration について Global Security and Compliance Acceleration on AWS Program (GSCA) は、金融サービス、ヘルスケア、プライバシー、公共部門のセキュリティ、プライバシー、コンプライアンス要件を満たす必要のあるビジネスを、グローバルにサポートします。これには商業部門と公共部門の両方のワークロードが含まれます。 AWS パートナーは、コンプライアンスプログラムの要件を理解し、GSCA チームと連携するために、担当者に連絡を取ることをお勧めします。 翻訳はソリューションアーキテクト 杉本 晋吾 が担当しました。原文は こちら です。

低品質に起因するコスト (外部サイトリンク) は、メーカーにとって最も重要な事項です。品質に不良があると、スクラップや再加工のコストが増加し、生産スループットが低下し、顧客や企業の評価に影響を与える可能性があります。生産ラインでの品質検査は、品質基準を維持するために不可欠です。多くの場合、品質評価や欠陥の検出には人による目視検査が用いられますが、人間の検査員の限界により、ラインのスループットが制限されてしまうことがあります。 機械学習 (ML) と人工知能 (AI) の出現により、コンピュータービジョン (CV) ML モデルを使用した外観検査が可能になりました。人間による検査を CV ベースの ML で補完することで、検出ミスを減らし、生産をスピードアップし、品質コストを削減し、顧客に対しプラスの影響を与えることができます。CV ML モデルの構築には通常、データサイエンスとコーディングの専門知識が必要ですが、多くの場合、これらは製造業の組織では希少なリソースです。しかし今では、品質エンジニアと現場の方々も、ノーコードのMLサービスを使用して機械学習モデルを構築および評価できるようになり、より広範な製造業務においてモデルの探索と導入を行うことができるようになりました。 Amazon SageMaker Canvas は、品質管理、生産技術のエンジニアが正確な ML 予測を自分で生成できるビジュアルインターフェイスを備えています。ML の経験が一切なくても、またコードを 1 行たりとも記述する必要もありません。SageMaker Canvas を使用すると、独自の画像データセットを使用して一般的な製造上の欠陥を特定するための単一ラベルの画像分類モデルを作成できます。この記事では、SageMaker Canvas を使用して単一ラベルの画像分類モデルを構築し、製造された永久磁石タイルの欠陥をその画像に基づいて識別する方法について説明します。 ソリューション概要 この記事は、CV ML検査を検討している品質エンジニアの視点を前提としており、永久磁石タイル画像のサンプルデータを用いて、品質チェック用のタイルの欠陥を予測する画像分類MLモデルを構築します。データセットには、ブローホール (blowhole) 、破損 (break) 、クラック (crack) 、擦れ (fray) 、不均一な表面 (uneven surface) などの欠陥がある永久磁石タイルの画像が1,200枚以上含まれています。以下の画像は、単一ラベルの欠陥分類の例です。左側はクラック (crack) の入ったタイル、右側は欠陥のないタイルです。 このような実際の画像は、生産ラインの完成品から収集できます。この記事では、SageMaker Canvas を使用して、特定の永久磁石タイル画像の欠陥を予測して分類する単一ラベルの画像分類モデルを構築します。SageMaker Canvas はローカルマシンのファイルまたは Amazon Simple Storage Service (Amazon S3) から画像データをインポートできます。この記事では、S3 バケットに複数のフォルダー (ブローホール (blowhole) 、破損 (break) 、クラック (crack) などの欠陥タイプごとに 1 つ) が作成され、永久磁石タイル画像がそれぞれのフォルダーにアップロードされています。 Free というフォルダーには、欠陥のない画像が含まれています。 SageMaker Canvas を使用した ML モデルの構築は、 4 つのステップからなります。 画像のデータセットをインポートする モデルを構築してトレーニングします 精度などのモデルインサイトを分析します 予測を行う 前提条件 ステップを開始する前に、SageMaker Canvas をセットアップして起動する必要があります。この設定は IT 管理者が行い、次の 3 つのステップで構成されます。 Amazon SageMaker ドメインをセットアップします ユーザーを作成します SageMaker Canvas の特定の機能を使用する権限を設定します 組織に合わせて SageMaker Canvas を設定するには、 Amazon SageMaker Canvasの使用を開始する 、 Amazon SageMaker Canvas のセットアップと管理 (IT 管理者向け) を参照してください。 SageMaker Canvas を設定すると、ユーザーは SageMaker コンソールに移動し、ナビゲーションペインで Canvas を選択し、 Canvasを開く を選択して SageMaker Canvas を起動できます。 SageMaker Canvas アプリケーションが新しいブラウザーウィンドウで起動されます。 SageMaker Canvas アプリケーションが起動したら、ML モデルを構築するステップを開始します。 データセットのインポート データセットのインポートは、SageMaker Canvas で ML モデルを構築する最初のステップです。 SageMaker Canvas アプリケーションで、ナビゲーションペインの Datasets を選択します。 Create メニューで Image を選択します。 Dataset name に Magnetic-Tiles-Dataset などの名前を入力します。 Create を選択してデータセットを作成します。 データセットを作成したら、データセットの画像をインポートします。 インポートページで、 Amazon S3 を選択します (永久磁石タイルの画像は S3 バケットにある想定です)。ローカルマシンから画像をアップロードすることもできます。 永久磁石タイル画像が保存されている S3 バケット内のフォルダーを選択し、 Import Data を選択します。 SageMaker Canvas がデータセットへの画像のインポートを開始します。インポートが完了すると、1,266 枚の画像で構成された画像データセットが表示されます。 データセットを選択して、画像のプレビューや欠陥タイプのラベルなどの詳細を確認できます。画像はフォルダー毎に整理され、各フォルダーには欠陥タイプの名前が付けられているため、SageMaker Canvas はフォルダー名に基づいて画像のラベル付けを自動的に行います。別の方法として、ラベルの付いていない画像をインポートし、ラベル名を追加し、個々の画像にラベルを紐づけることもできます。また既存のラベル付き画像のラベルを変更することもできます。 画像のインポートが完了し、SageMaker Canvas に画像データセットが作成されました。次のステップに進んで、永久磁石タイルの欠陥を予測する ML モデルを構築できます。 モデルの構築とトレーニング インポートしたデータセットを使用してモデルをトレーニングします。 データセット ( Magnetic-tiles-Dataset ) を選択し、 Create a model を選択します Model name に、 Magnetic-Tiles-Defect-Model などの名前を入力します ML 問題の種類として Image analysis を選択し、 Create を選択します モデルの Build タブでは、ラベル分布、ラベル付き画像とラベルなし画像の数、モデルタイプ (今回の場合は単一ラベルの画像予測) のような、データセットに関するさまざまな詳細を確認できます。ラベルの付いていない画像をインポートした場合や、特定の画像のラベルを変更または修正したい場合は、 Edit dataset を選択してラベルを変更できます。 モデルを構築するには、クイックビルドまたはスタンダードビルドのいずれかを選択できます。クイックビルドのオプションでは、精度よりも速度が優先されます。モデルのトレーニングは 15 ～ 30 分で完了します。このモデルは予測には使用できますが、共有することはできません。与えられたデータセットを使ってモデルをトレーニングすることの実現可能性と精度をすばやく確認するのに適したオプションです。スタンダードビルドでは速度よりも精度が優先され、モデルトレーニングには 2 ～ 4 時間かかる場合があります。今回は、スタンダードビルドを使用してモデルをトレーニングします。 Build タブの Standard build を選択して、モデルのトレーニングを開始します。 モデルトレーニングはすぐに開始されます。予想されるビルド時間とトレーニングの進行状況は Analyze タブで確認できます。 モデルのトレーニング完了を待って、モデルのパフォーマンスを分析して精度を調べることができます。 モデルの分析 今回の場合、モデルトレーニングを完了するのにかかった時間は 1 時間未満でした。モデルトレーニングが完了したら、 Analyze タブでモデルの精度を確認して、モデルが欠陥を正確に予測できるかどうかを判断できます。この場合、モデル全体の精度は 97.7% であることがわかります。また、個々のラベルや欠陥タイプごとにモデル精度を確認することもできます。たとえば、擦れ (Fray) や不均一な表面 (Uneven) の場合は 100%、ブローホール (Blowhole) の場合は約 95% です。このレベルの精度は良好な結果です。このまま評価を続けます。 モデルをよりよく理解し、信頼性を高めるには、ヒートマップ ( Heatmap ) を有効にして、モデルがラベルを区別するために着目している画像内の領域を確認してください。これはクラスアクティベーションマップ (CAM) 技術に基づいています。ヒートマップを使用すると、誤って予測された画像からパターンを特定でき、モデルの品質を向上させるのに役立ちます。 Scoring タブでは、各ラベル (またはクラス、または欠陥タイプ) のモデルの精度 (Precision) と再現率 (Recall) を確認できます。精度と再現率とは、バイナリ分類モデルやマルチクラス分類モデルの性能を測定するために使用される評価指標です。精度は、モデルが特定のクラス (この例では欠陥タイプ) をどれだけうまく予測できるかを示します。Recall は、モデルが特定のクラスを何回検出できたかを示します。 モデル分析は、予測に使用する前にモデルの精度を理解するのに役立ちます。 予測の実行 モデル分析が完了すると、このモデルを使用して予測を行い、永久磁石タイルの欠陥を特定できるようになります。 Predict タブでは、単一予測 ( Single prediction ) と バッチ予測 ( Batch prediction ) を選択できます。単一予測では、ローカルマシンまたは S3 バケットから 1 つの画像をインポートして欠陥に関する予測を行います。バッチ予測では、SageMaker Canvas データセットに保存されている複数の画像について予測を行うことができます。SageMaker Canvas では、バッチ予測用のテスト画像または推論画像を含む別のデータセットを作成できます。この記事では、単一予測とバッチ予測の両方を使用します。 単一予測の場合は、 Predict タブで Single prediction を選択し、 Import image を選択して、ローカルマシンからテスト画像または推論画像をアップロードします。 画像がインポートされると、モデルは欠陥について予測を行います。初回の推論では、モデルが初めて読み込まれるため、数分かかる場合があります。モデルが読み込まれた後は、画像に関する予測が即座に行われます。各ラベルタイプの予測の画像と信頼度を確認できます。たとえば今回の場合、永久磁石タイル画像には不均一な表面欠陥 ( Uneven ラベル) があると予測され、モデルはその欠陥について 94% の信頼度を示しています。 同様に、他の画像や画像のデータセットを使用して、欠陥に関する予測を行うことができます。 バッチ予測には、 Magnetic-Tiles-Test-Dataset と呼ばれるラベルのない画像のデータセットを使用し、ローカルマシンからデータセットに12枚のテスト画像をアップロードします。 Predict タブで、 Batch prediction を選択し、 Select dataset を選択します。 Magnetic-Tiles-Test-Dataset をデータセットとして選択し、 Generate predictions を選択します。 すべての画像の予測を生成するにはしばらく時間がかかります。ステータスが Ready になったら、データセットのリンクを選択して予測を確認します。 すべての画像の予測を信頼度とともに表示できます。個々の画像のいずれかを選択すると、画像レベルの予測の詳細を確認できます。 予測を CSV または .zip ファイル形式でダウンロードして、オフラインで作業できます。予測されたラベルを検証してトレーニングデータセットに追加することもできます。予測されたラベルを検証するには、 Verify prediction を選択します。 予測データセットでは、予測されたラベルが正しくない場合は、個々の画像のラベルを更新できます。必要に応じてラベルを更新したら、 Add to trained dataset を選択して画像をトレーニングデータセット (この例では Magnetic-Tiles-Dataset ) にマージします。 これにより、既存のトレーニング画像と予測ラベル付きの新しい画像の両方を含むトレーニングデータセットが更新されます。更新されたデータセットを使用して新しいモデルバージョンをトレーニングすると、モデルのパフォーマンスが向上する可能性があります。新しいモデルバージョンはインクリメンタルトレーニングではなく、更新されたデータセットを使用してゼロから新しいトレーニングを行うものです。この方法をとることで、新しいデータソースでモデルを更新し続けることができます。 クリーンアップ SageMaker Canvas での作業が完了したら、 Log out を選択してセッションを終了すると、それ以上のコストは発生しません。 もし直接ブラウザーを閉じてしまった場合は、必ずCanvasに戻ってきて Log out ボタンからログアウトするようにしてください。 ログアウトしても、データセットやモデルなどの作業は保存されているので、SageMaker Canvas セッションを再度起動して後で作業を続けることができます。 SageMaker Canvas によって予測のための SageMaker 非同期推論エンドポイントが作成されます。 SageMaker Canvas によって作成されたエンドポイント、エンドポイント設定、モデルを削除するには、 エンドポイントとリソースの削除 を参照してください。 まとめ この記事では、SageMaker Canvasを使用して画像分類モデルを構築し、製造された製品の欠陥を予測し、目視検査の品質プロセスを補完および改善する方法を学びました。SageMaker Canvas を製造環境のさまざまな画像データセットと組み合わせて、予知保全、パッケージ検査、作業者の安全、商品追跡などの用途に合わせたモデルを構築できます。SageMaker Canvas では、コードを記述しなくても ML を使用して予測を生成できるため、CV ML 機能の評価と適用を迅速に行うことが出来ます。 SageMaker Canvas の使用を始めるには、また、詳細な情報を得るには、以下のリソースを参照してください。 Amazon SageMaker Canvasデベロッパーガイド Amazon SageMaker Canvas を発表 – ビジネスアナリスト向けの視覚的でノーコードの機械学習機能 著者について Brajendra Singh は、アマゾンウェブサービスのソリューションアーキテクトで、企業のお客様と仕事をしています。開発者としてのバックグラウンドが強く、データや機械学習のソリューションに熱心な愛好家です。 Danny Smith は、自動車および製造業界のプリンシパル兼MLストラテジストであり、顧客の戦略的アドバイザーを務めています。彼のキャリアの焦点は、役員室から製造現場に至るまで、主要な意思決定者がデータ、テクノロジー、数学を活用してより良い意思決定を行えるよう支援することでした。最近の彼の会話のほとんどは、機械学習とジェネレーティブ AI の民主化に関するものです。 Davide Gallitelli は、EMEA 地域の AI/ML のスペシャリストソリューションアーキテクトです。ブリュッセルに拠点を置き、ベネルクス全域の顧客と緊密に連携しています。彼は幼い頃から開発者をしていて、7 歳の時にコーディングを始めました。大学で AI/ML を学び始め、それ以来AI/MLに夢中になっています。 翻訳はAWSソリューションアーキテクトの矢永が担当しました。原文は こちら です。

このブログは、AWSとNovartis AGの戦略的コラボレーションのもと、AWSプロフェッショナルサービスチームがBuying Engineプラットフォームを構築したことを紹介する4部構成のシリーズ第2回の記事を取り出して翻訳したものです。このシリーズの内容は以下の通りです。 Part 1: ノバルティスAGがAWS機械学習を使用して、どのようにSMARTをスマート調達に取り入れたか(英文) Part 2: ノバルティスAG、Amazon SageMakerと Amazon Neptuneを使い、BERTによるナレッジグラフの構築と充実を図る (本記事) Part 3: ノバルティスAGは、Amazon OpenSearch Service用 k-NN (k近傍法)とAmazon SageMakerを使用して検索とレコメンデーションを強化 (英文) Part 4: ノバルティスAGにおけるAmazon SageMakerとGluontsによる需要予測(英文) この記事では、ビジネスアナリストにカタログデータの全体ビューとインサイトを提供する購買エンジンのナレッジベースに焦点を当てています。Novartis AGが TensorFlow 2や Amazon Neptune とともに、 Amazon SageMaker をどのように併用してインハウスのナレッジベースの構築と充実を図っているかについて詳しく説明します。 Amazon SageMakerは、機械学習 (ML) モデルを迅速に構築、トレーニング、デプロイする機能を開発者とデータサイエンティストに提供するフルマネージドサービスです。Amazon SageMakerは、機械学習プロセスの各ステップから面倒な作業を取り除き、高品質なモデルを容易に開発することを可能にします。 SageMaker Python SDK は、いくつかの異なる機械学習およびディープラーニングフレームワークを使用して、Amazon SageMakerでのモデルのトレーニングとデプロイを可能にするオープンソース API とコンテナを提供します。コードの実行には、Amazon SageMaker ノートブックインスタンスを使用します。Amazon SageMakerノートブックインスタンスの使用方法については、 AWS Documentation を参照してください。 Amazon Neptuneは高速かつ信頼性の高いフルマネージド型グラフデータベースサービスです。このサービスでは、高度に接続されたデータセットと連携するアプリケーションを簡単に構築および実行できます。Neptuneの中核となるのは専用の高性能グラフデータベースエンジンです。このエンジンは、数十億の関係を保存し、ミリ秒単位のレイテンシーでグラフをクエリできるよう最適化されています。Neptuneは、推奨エンジン、不正検出、ナレッジグラフ、創薬、ネットワークセキュリティなどのグラフのユースケースを強化します。 プロジェクトの動機 ナレッジベースを構築するために、Amazon Neptune、 Amazon DynamoDB または Amazon S3 など、いくつかのオプションを検討しました。お客様の要件を起点に逆算して考えたところ、Amazon Neptuneのナレッジグラフを使用すると、ユースケースにより適切に対処できることがわかりました。ナレッジグラフは、概念の定義、そのプロパティ、それらの間の関係、および想定される論理的制約のセットを用いて、特定のドメインのセマンティクスをキャプチャします。たとえば、製品とプロパティの間の関連性やつながりは、グラフとして見た方がわかりやすくなります。これは、より良いアイテムの選択やレコメンデーションにつながります。さらに、グラフには、複数のレイヤー（製品レイヤー、クリックストリームデータレイヤー）が含まれている場合があり、プロセスの過程でそれらのデータによる充実が図られます。詳細については、「 Knowledge Graphs on AWS 」を参照してください。 Novartisの購買エンジンカタログには、さまざまなベンダーやサプライヤーの製品が含まれています。製品は、構造化されていないテキストによる記述と一貫性のないプロパティマッピングで構成されることが多いため、このような一元化されたグラフ表現を構築する場合、一貫性を確保することは困難です。この課題に対処するために、SageMakerを活用して、BERTに基づくカスタマイズされた固有表現抽出 (NER) モデルを構築し、トレーニングします。これにより、製品属性を抽出し、それをナレッジグラフの標準化された入力として使用することが可能になります。 この記事では、同様の課題に取り組むデータサイエンティストのために、固有表現抽出の技術を使用してナレッジグラフを構築し、データを充実させるための技術ガイドラインを提供します。 また、これ以降の内容においては、次の手順について紹介します。 ノートブックのセットアップ SageMaker上のNER BERTのためのカスタムトレーニングスクリプト SageMakerで大規模に推論をデプロイするためのカスタム推論スクリプト ナレッジグラフのセットアップとNeptuneを使用したクエリの実行 ノートブックのセットアップ S3バケットを作成します。これは、サンプルとして生成されたファイルを保存するためにノートブック全体で使用されます。 SageMakerノートブックインスタンスを作成します。次の点に注意してください。 ステップ1で作成したS3バケットからの読み取り/書き込みができるよう、実行ロールに追加の権限を付与する必要があります。 ノートブックインスタンスをVirtual Private Cloud (VPC) 内に配置する場合は、VPCがパブリックPypiリポジトリとaws-samples/リポジトリへのアクセスを許可していることを確認してください。 次のスクリーンショットにある通り、 このGitリポジトリ をノートブックに添付してください。 BERTおよびAmazonSageMakerを使用して NERモデルをトレーニングする 固有表現抽出アルゴリズムを構築するために、私たちはBERTの使用を決めました。 BERT は、大規模なテキストコーパスを用いて事前にトレーニングされた Transformerエンコーダの基本アーキテクチャ を転移学習に活用することで広く知られているNLPモデルです。これにより、ラボ用品の製品特性に対する固有表現抽出など、具体的なタスクとデータに対応できます。 また、私たちはGitHubの pos-tagger-bert よりインスピレーションを得ました。これは、KerasとTensorFlow2での固有表現抽出にBERTを用いるための優れた総合的な入門書と言えます。 arxiv:1810.04805 から引用した図 必要なカスタマイズのレベルと柔軟性を考慮したところ、私たちはカスタムディープラーニングモデルを構築するために Amazon SageMaker Python SDK を使用することにしました。これにより、事前に構築された Amazon SageMaker TensorFlow コンテナ を使用できるようになり、トレーニングと推論コードを簡単にまとめることが可能です。 そのためには、まずBERTに必要な前処理を適用するトレーニングエントリポイントを指定します。次に、Kerasを使用してモデルを構築し、トレーニングを行います。最後に、SageMaker TensorFlow Servingコンテナで使用できるように、ウエイトとアーキテクチャを適切な形式に保存します。 コードをさらに読みやすくするために、大半の関数はリポジトリの「ソース」フォルダのモジュールに保存されます。 SageMaker スクリプトモードで実行するトレーニングスクリプトの作成 BERTの前処理 BERTは、入力が単語のリスト形式であることを想定しています。たとえば、製品の説明に関する 「General Purpose Couplings with valve, PMC Series, Acetal」 、およびそれに関連するタグは、次のリストに変換されます。 [(“General”, Type), (“Purpose”, Type), (“Couplings”, Product), (“with”, Other), (“valve”, Addon), (“PMC”, Other), (“Series”, Other), (“Acetal”, Other)], BERTの入力には、最大シーケンス長の制約があります。これにより、長い記述が適切な長さに分割されることがあります。max_sequence_lengthを3にした場合、今回のデータは次のようになります。 [[(“General”, Type),  (“Purpose”, Type), (“Couplings”, Product)], [(“with”, O), (“valve”, Addon), (“PMC”, O)], [(“Series”, O), (“Acetal”, O)], デフォルトでは、BERTの最大入力長は512です。ただし、計算時間は入力の長さに対して二次関数的に増加します。このため、大きな入力を使用して大きなコンテキストを利用する場合、現実的な処理時間で精度を高めるためにはスイートスポットを見つける必要があります。今回の場合には、max_sequence_lengthが64であれば、計算時間を比較的低く抑えながら良好な結果が得られることがわかりました。 最後に、BERTにフィードするために、単語は WordPiece トークナイザ によってトークン化されます。このトークナイザは、トレーニングで使われた語彙から単語を見つけ出すと、単語が2つ以上のサブワード (Johnson→John ##son) に分割されることがあります。トークナイザを使用すると、記述内の各単語は input_ids (単語/サブワードの語彙ID) に変換されます。これらに加えて、BERTには input_mask (パディング入力と実際の単語を区別) と segment_ids (ここでの設定は0) が必要です。 また、このコードは、ラベルをワンホットエンコードされたベクトルに変換し、 label_ids も生成します。これがトレーニングタスクのターゲットになります。 # Read the data train_sentences = pd.read_csv(os.path.join(args.train, 'train.csv'), engine='python') val_sentences = pd.read_csv(os.path.join(args.validation, 'val.csv'), engine='python') # Create the labels dictionnaries from the data tag2int, int2tag = prepro.create_tag_dictionnaries(train_sentences, val_sentences) # Reading the parameters passed to the training job and saving for inference MAX_SEQUENCE_LENGTH=args.max_sequence_length BERT_PATH=args.bert_path save_parameters_for_inference(MAX_SEQUENCE_LENGTH, BERT_PATH, tag2int, int2tag) # Sequence pre-processing # Splitting the sequences train_sentences, val_sentences = prepro.split(train_sentences, val_sentences, MAX_SEQUENCE_LENGTH) # Separating text and labels train_text, val_text = prepro.text_sequence(train_sentences, val_sentences) train_label, val_label = prepro.tag_sequence(train_sentences, val_sentences) # BERT pre-processing # Instantiate tokenizer tokenizer = prepro.create_tokenizer_from_hub_module(BERT_PATH) # Convert to BERT features (train_input_ids, train_input_masks, train_segment_ids, train_labels ) = prepro.convert_examples_to_features(tokenizer, train_text,   train_label,   tag2int,   max_seq_length=MAX_SEQUENCE_LENGTH+2) (val_input_ids, val_input_masks, val_segment_ids, val_labels ) = prepro.convert_examples_to_features(tokenizer,   val_text,   val_label,   tag2int,   max_seq_length=MAX_SEQUENCE_LENGTH+2) 推論時とトレーニング時の前処理が同じになるように、このステップで前処理パラメータを保存します。これは、後に生成されるトレーニングウェイトとともに、 SM_MODEL_DIRフォルダの下に保存されます。また、これらは、トレーニングジョブの最後に指定するAmazon S3バケットに保存されます。トレーニング済みモデルを SageMakerモデルとしてデプロイするために必要なものは、すべてSM_MODEL_DIRに保存されます。 モデルの構築とトレーニング BERT入力への変換が終了すると、Kerasを使用してモデルが構築され、トレーニングされます。 TensorFlowハブからBERTの事前にトレーニングされたウエイトをロードするのに、ここではデフォルトの小文字のみ(uncased)の English BERT が使用されます。アーキテクチャの詳細は ソースコード で参照できます。 #Building a keras model based on the previous section model = build_model(max_seq_length = MAX_SEQUENCE_LENGTH+2, n_tags=len(tag2int), lr=args.learning_rate, drop_out=args.drop_out, bert_path=args.bert_path, loss=args.loss ) model_dir = "/opt/ml/model" checkpoint = ModelCheckpoint(filepath=os.path.join(model_dir, "ner_model.h5"), monitor='val_acc', save_best_only=True, save_weights_only=True, verbose=1) history = model.fit(training_data=([train_input_ids, train_input_masks, train_segment_ids], train_labels), validation_data=([val_input_ids, val_input_masks, val_segment_ids], val_labels), epochs=args.epochs, batch_size=args.batch_size, shuffle=True, verbose=1, callbacks=[checkpoint,   EarlyStopping(monitor = 'val_accuracy', patience = 5)]) TensorFlow Servingのモデルを保存する トレーニングが終了すると、最適なウエイトがロードされます。ウエイトと一緒にモデルがProtobuff形式に変換され、SageMaker TensorFlow Servingコンテナで使用できるように適切なフォルダに保存されます。次のコードは、モデルを保存する方法の詳細を示しています。 # Reload best saved checkpoint: model.load_weights(os.path.join(model_dir, 'ner_model.h5')) # Note: This directory structure will need to be followed model_version = '1' export_dir = os.path.join(model_dir, 'model/', model_version) tf.saved_model.save(obj=model, export_dir=export_dir) 製品プロパティを抽出する推論スクリプトの作成 NERモデルのトレーニングが完了したら、製品プロパティの生成に進み、ナレッジグラフを作成します。 SageMakerエンドポイントをデプロイするか、バッチ推論を実行して大規模に推論を実行するには、SageMaker Python SDKで作成されるTensorflow SageMakerコンテナで動作する推論スクリプトを作成する必要があります。次のセクションでは、このスクリプトの作成方法を紹介します。 PyTorchコンテナとApache/MXNet SageMakerコンテナでは、model_fnを変更することでモデルをロードする方法を指定できます。一方、SageMaker TensorFlow Servingコンテナのモデルデプロイメントは「暗黙的」であり、前セクションで定義したフォルダ構造と設定された名前を前提としています。ただし、特定の入出力処理、つまり input_handlerとoutput_handlerへの対応においては、二つの関数を変更することができます。ここにおいて、特定のBERT入力前処理を行い、出力のフォーマットを実行します。 前処理パラメータの読み込み 推論スクリプトの最初のステップは、トレーニング中にダンプされたパラメータを読み取って前処理を再現し、同じトークナイザをインスタンス化することです。モデルを呼び出すたびにトークナイザがインスタンス化されないようにするには、これを input_handler 関数と output_handler 関数の外に配置することが重要です。 # Reading BERT processing input parameters with open('/opt/ml/model/int2tag.json') as f: int2tag = json.load(f) with open('/opt/ml/model/tag2int.json') as f: tag2int = json.load(f) n_tags = len(tag2int) with open('/opt/ml/model/max_sequence_length.txt') as f: MAX_SEQUENCE_LENGTH = int(f.read()) with open('/opt/ml/model/bert_path.txt') as f: bert_path = f.read() # Instantiate tokenizer (outside input_handler()) tokenizer = create_tokenizer_from_hub_module(BERT_PATH) 入力ハンドラ 入力ハンドラ関数は、予測リクエスト毎に呼び出されます。予測ペイロードで指定されたテキストデータは、トレーニングの段階で使用されたものと同じ前処理を受けます。 これにより「入力」テンソルが生成され、その後TensorFlow Serving REST APIに送信されます。次のコードは、モデルに到達する前のデータ処理の詳細を示しています。 def input_handler(data, context): if context.request_content_type == 'application/json': d = json.load(data) # Splitting input into words global sentences sentences = [line.split() for line in d] # Sentence preprocessing (split with max sequence length)" global split_sentences global split_idx split_sentences, split_idx = prepro.split_and_duplicate_index(sentences,   MAX_SEQUENCE_LENGTH) # Creating tags placement for unlabelled data (-PAD-)") tags_placement = [] for sentence in split_sentences: tags_placement.append(['-PAD-']*len(sentence)) # BERT pre-processing (input_ids, input_masks, segment_ids, _ ) = prepro.convert_examples_to_features(tokenizer, split_sentences, tags_placement, tag2int, max_seq_length=MAX_SEQUENCE_LENGTH+2) # Convert BERT features to necessary format for TensorFlow Serving input_ids = input_ids.tolist() input_masks = input_masks.tolist() segment_ids = segment_ids.tolist() result={ 'inputs':{ "input_word_ids": input_ids, "input_mask": input_masks, "input_type_ids": segment_ids } } return json.dumps(result) BERTでは、記述がモデルの入力サイズよりも大きい場合は記述を分割する必要があるため、元の記述を追跡できることが重要です。これを可能にするために、 split_and_duplicate_index () は元の各シーケンスのインデックスを作成します。このインデックスは、後で予測を元の記述にマッピングし直すために使用されます。インデックスと元のシーケンスの両方が、 output_handler で使用できるグローバル変数として保存されます。 出力ハンドラ input_handler によって生成された入力がモデルに送信された後、TensorFlowモデルはタグインデックスに対応する数値配列の形式で予測を出力します。 output_handler を使用すると、いくつかの後処理ステップを追加できます（すなわち、予測をラベルに戻し、分割されたセンテンスを再グループ化し、各シーケンス予測をタグと値の読みやすい辞書に変換します）。 def output_handler(data, context): if data.status_code != 200: raise ValueError(data.content.decode('utf-8')) # Reading model predictions as data.content response_content_type = context.accept_header prediction = data.content pred = json.loads(prediction.decode('utf-8')) # Select the tag prediction with the highest score for each word pred_max = [list(np.array(k).argmax(-1)) for k in pred['outputs']] # Convert label_ids (y) to labels y_pred = postpro.y2label(pred_max, int2tag, mask=0) # Remapping split sequences to origin index" flat_y_pred, _ = postpro.map_split_preds_to_idx(y_pred, split_idx) # Format output to dicts for compatibility with Knowledge graph nerc_prop_list = [postpro.preds_to_dict_single_lower(s,y) for s,y in zip(sentences,flat_y_pred)] pred_dict_list = [{'ner_properties':nerc_prop_list[i]} for i, x in enumerate(sentences)] return json.dumps(pred_dict_list), response_content_type 推論スクリプトをこのように構築すると、ナレッジグラフへの入力が簡単になります。 各製品には、値が付けられた複数の文字が関連付けられています。 (これは、このブログ記事の最初の画像に示されています。) ナレッジグラフを構築し、データの充実を図る Amazon Neptune は高速かつ信頼性の高いフルマネージドグラフデータベースサービスです。このサービスでは、高度に接続されたデータセットと連携するアプリケーションを簡単に構築および実行できます。Amazon Neptuneは、数十億の関係を保存し、ミリ秒単位のレイテンシーでグラフをクエリするために設計されています。このユースケースでは、リソース記述フレームワーク（RDF）を使用してデータをモデル化し、 SPARQLを使用してクエリします。 製品説明の記述から製品プロパティを抽出した後、ナレッジグラフモデルを定義し、Amazon Neptuneを設定し、SPARQLを使用してクエリを実行できます。データ処理の完全なコードについては、 GitHubリポジトリ を参照してください。 ナレッジグラフモデル 形式的に構造化されたグラフモデルは、製品とその価値を表します。このグラフモデルには、hasPropertyリレーションシップによって表されるプロパティ、および価格、製造元、通貨などの製品の他のフィールドが含まれます。 各プロパティは、ノード、タイプ (つまり、色、マテリアル)、および値で表されます。 また、このプロパティがNERモデルの結果である場合、またはベンダーデータから定義されたプロパティである場合は、それを示すフラグも含まれます。プロパティ値とプロパティタイプの組み合わせは、プロパティノードの一意の識別子として使用されます。これにより、他の製品からの参照が可能になります。 Amazon Neptuneのセットアップ Neptuneクラスターを設定するには、CloudFormationスタックを使用し、Getting started with Neptune（Neptuneの開始方法）のドキュメントを参照してください。スタックがデプロイされると、Neptuneインスタンスのステータスを確認することができます。 その後、NERモデルの出力は、ナレッジグラフを構築するためのグラフィカルデータベースとしてNeptuneにフィードされます。SPARQLが私たちのプロジェクトの言語として選択されたため、JSONの出力はRDFトリプルに変換されました。 グラフモデルで定義されているとおりにトリプルが作成されたら、Neptuneのロードエンドポイントを使用して一括ロードを実行します。 SPARQLを使用してAmazon Neptuneのクエリを実行 Neptune Workbench を使用して、グラフに対してクエリを実行します。たとえば、ID-012345の製品と他の製品に共通するつながりの数に基づいて類似製品を検索するには、次のクエリを使用できます。 BASE <http://example.com/> PREFIX pr: <resource/product/> SELECT ?similar (COUNT(?p) as ?similarity) ( group_concat(?p; separator=",") as ?relationships) FROM <products> WHERE { VALUES ?product { pr:012345 } ?similar ?p ?o . ?product ?p ?o . } GROUP BY ?similar ?product HAVING ( COUNT(?p) > 1 ) ORDER BY DESC(?similarity) LIMIT 5 次の画像は、このクエリの出力を示しています。 次の画像は、上位2つの製品がNeptune Workbenchからどのように視覚化されるかを示しています。 クリーンアップ この演習を終了したら、次の手順でリソースを削除します。 ノートブックインスタンスと作成したエンドポイントを削除 オプションで、登録されたモデルを削除 オプションで、SageMaker実行ロールを削除 オプションで、S3バケットを空にして削除、または必要なものは保持 サマリー これで、BERTとSageMakerスクリプトモードでカスタム固有表現抽出モデルを構築し、トレーニングと推論を大規模に実行するための基礎知識が得られたでしょう。 さらに、これらの予測を使用してナレッジグラフを構築し、クエリすることでNeptuneの製品に関するインサイトを分析し、抽出することができます。 このブログ記事にて抜粋をご覧いただきましたが、AWSプロフェッショナルサービスによるモデルは、本番環境に対応した機械翻訳（ML）ソリューションを提供する機会を実現しました。また、Novartis AGチームがMLの取り組みを維持、反復、改善できるように、MLのベストプラクティスの本番化に向けて彼らをトレーニングする機会も私たちは得ることができました。提供されたリソースがあれば、彼らは将来考えられる他のユースケースにも拡大することができるでしょう。 今すぐ使用を開始しましょう！ Amazon SageMakerコンソール にアクセスして SageMakerについて詳しく学び、独自の機械学習ソリューションを開始することができます。 AWSでは皆様からのフィードバックをお待ちしています。ご質問やコメントをお寄せください。 Buying Engineプロジェクトに携わったNovartisチームに心より感謝します。また、 このブログ記事にご協力いただいた次の方々に心より感謝します。 Srayanta Mukherjee : Srayantaは、NovartisのData Science & Artificial IntelligenceチームのDirector of Data Scienceです。Novartis Buying Engineの納入時には、データサイエンスの責任者を務めていました。 Petr Hantych : PetrはNovartis ITのPrincipal Data Scientistです。立ち上げから最終的なアプリケーションを提供するまでこのプロジェクトに携わりました。余暇には、最後にフィニッシュしないことを心がけながら、トライアスロンレースを楽しんでいます。 Adithya N : AdithyaはNovartis ITのData Scientistで、開始段階から工業化段階まで、データサイエンスソリューションの開発に取り組んでいます。Adithyaは自由時間に、複数の楽器を演奏したり、チェスをしたり、行動経済学のジャンルの本を読んだりすることを楽しんでいます。 Othmane Hamzaoui Othmane Hamzaouiは、AWSプロフェッショナルサービスチームで働くData Scientistです。彼は機械学習を使用してお客様の課題を解決することに情熱を注いでおり、研究とビジネスのギャップを埋めて、インパクトのある結果を達成することに重点を置いています。余暇には、美しいパリの街でランニングをしたり、新しいコーヒーショップを発掘したりすることを楽しんでいます。 Fatema Alkhanaizi Fatema Alkhanaiziは、AWSプロフェッショナルサービスのML Engineerです。彼女は新しい技術について学ぶことや複雑な技術的問題を解決することを楽しんでいます。 余暇には、今まで行ったことのない場所を歩いて回ることを楽しんでいます。 Viktor Malesevic Viktor Malesevicは、AWSプロフェッショナルサービスのData Scientistで、自然言語処理とMLOpsに情熱を注いでいます。彼はお客様と協力して、挑戦しがいのあるディープラーニングモデルを開発し、AWSの本番環境に導入しています。余暇には、赤ワインやチーズを友達とともに楽しんでいます。 本ブログの翻訳はソリューションアーキテクトの五十嵐が担当しました。原文は こちらのリンク から参照できます。

この記事は “ Highlights from the AWS Life Sciences Executive Symposium 2023: Unlocking access to and insights from data ” を翻訳したものです。 5 月 15 日にボストンで AWS ライフサイエンスエグゼクティブシンポジウム を開催しました。そこで、 「データへのアクセスとインサイトの活用」 をテーマにしたトラックを私がリードしました。100の組織から集まった300人以上のライフサイエンス担当幹部がこの半日のオンサイトイベントに参加し、クラウド上の強固なデータ基盤と機械学習（ML）を通じたイノベーションを推進する方法を探りました。 いくつかの新しいトレンドの高まりにより、データに焦点を当てたこのトラックは非常にタイムリーなものになりました。第一に、ライフサイエンス企業は、より限られたリソースでより多くの成果をあげなければならないという大きなプレッシャーにさらされています。「インフレ抑制法」、期限切れをむかえる特許、研究開発のスピードアップの必要性などに対応するため、企業はデータをより有効に活用して市場投入までの時間を短縮し、オペレーションの俊敏性を向上させる方法を模索しています。第二に、今日生成される医療データのほぼ 97% は、保存と管理が不十分なため、未使用のままになっています。チームは、最大 80% の時間をデータの検索、購入、クリーニングに費やしており、インサイトやエビデンスの生成、科学的またはビジネス上の課題への回答に費やしている時間は 20% に過ぎないと報告しています。第三に、企業は、データ主権とGxPコンプライアンスを維持しながら、データのカタログ化、管理、共有、コラボレーションをより効率的に行うためのソリューションと、自社にとって重要な機密情報を開示することなく複数の関係者によるコラボレーションを可能にする機能を求めています。効果的なコラボレーションソリューションの必要性は急務であり、現在市場に参入している対応策の 50% 以上は、製薬会社、スタートアップ、大学、コンソーシアム間のパートナーシップによるものです。最後に、企業はバリューチェーン全体でイノベーションを促進するために、生成系AIと大規模言語モデル（LLM）の可能性を模索する競争を繰り広げています。そのため、差し迫ったデータに関する課題への緊急性がさらに高まっています。 シンポジウムのオープニング基調講演では、マルチモーダルデータの効率的な保管、分析、カタログ作成、共有のための専用サービスとソリューションによって、AWS がお客様の課題解決をどのように支援しているかを紹介しました。 参加者は、業界固有のストレージと分析のニーズに合わせて特別に設計された 3 つの製品、Amazon HealthLake (訳注: 現在のAWS HealthLake) 、Amazon HealthLake Imaging (訳注: 現在のAWS HealthImaging)、Amazon Omics (訳注: 現在のAWS HealthOmics) についてのインサイトを得ました。 Amazon HealthLake は HIPAA 適格サービスで、ユーザーは個人または患者の健康データを時系列で表示して大規模なクエリや分析を行うと同時に、医師のメモなどの非構造化臨床データを構造化データに自動的に変換します。 Amazon HealthLake Imaging を使用すると、プロバイダーは医用画像ストレージのコストを最大 40% 削減でき、複数のユーザーがその画像の同じコピーにアクセスして 1 秒もかからずに画像を取得できるようになります。また、 Amazon Omics は、ゲノミクス、トランスクリプトミクス、およびその他のオミクスデータを保存、クエリ、分析して、科学的発見を進めるためのより深いインサイトを生み出すのに役立ちます。これらのサービスにより、データを分析や機械学習に数分以内に利用できるようになり、 Amazon Athena 、 Amazon Redshift 、 Amazon SageMaker などの使い慣れたツールや、Tableau やデロイトの ConvergeHealth MINER などのサードパーティツールで使用できるようになります。 データカタログ作成では、 Amazon DataZone がビルトインのガバナンスによって企業独自のデータを活用するうえでどのように役立つかをデモしました。Amazon DataZone を使用すると、企業はエンタープライズデータエコシステム (データメッシュプラットフォームのような) を構築し、研究開発やコマーシャルなどの分野にまたがる複数のチームが効果的にコラボレーションできるようになります。統合データ分析ポータルへのプロジェクトレベルのアクセスにより、ユーザーはすべてのデータをパーソナライズされた360度ビューで確認できると同時に、厳格なガバナンスとコンプライアンスポリシーを適用できます。また、カスタムメタデータを含むデータ製品の一覧と、品質指標やプロファイリングに関する情報を追加できるため、ユーザーは数週間ではなく数日で作業を開始できます。 医療機関やライフサイエンス企業は、バイオマーカーやパスウェイの研究、臨床試験の設計、有効性に関するリアルワールドデータの分析など、外部ソースからのデータにアクセスする必要があることも理解しています。しかし、企業は多くの場合、購入するデータの単一コホートの定義に数週間を費やし、サードパーティデータのライセンスに毎年数百万ドルを費やし、社内に持ち込んだデータを変換して使用できるように数百時間を費やす必要があります。 Amazon Data Exchange はユーザーが、1 つのユーザーインターフェイスから 3500 以上のデータセットにアクセスできることができ、簡単に検索、購入、使用できるように構築されており、このサービスを紹介したときには多くの参加者が興奮していました。一方で、データを交換できない（またはしたくない）企業のために、 Amazon Clean Rooms を紹介しました。これは、企業とそのパートナーが、互いの基礎データを共有したりコピーしたりすることなく、より簡単かつ安全に共同作業して集合データセットを分析できるようにするためです。 また、 生成AIにおけるデータの役割 についても議論しました。AWS は長い間、人工知能 (AI) と ML が患者の治療成績を改善するものであるというお客様の期待を信じ、それを共有してきました。私たちは 20 年以上にわたり ML によるイノベーションに取り組んできましたが、その勢いは衰えていません。これは Amazon の伝統、精神、そして未来の一部であり、世界の製薬企業の上位 10 社のうち 9 社が AWS を分析と機械学習に使用しているのはそのためです。 振り返ってみると、私たちは機械学習の民主化において重要な役割を果たしてきました。ライフサイエンスのユースケースに特化した、最も幅広く深い一連のAIおよび機械学習サービスにアクセスして、お客様がより迅速にイノベーションを起こすのを支援してきました。また、生成AIにも同じアプローチを採用しています。つまり、 ライフサイエンス企業がビジネスで生成AIを簡単に、費用対効果が高く、実用に値する斬新なイノベーションを提供しています 。 適切なモデルを見つけることから、モデルを安全にカスタマイズすること、既存のアプリケーションにモデルを統合することまで、 AWS が基盤モデル (FM) を使用して構築するのが最も簡単な場所である ことを確認することに重点を置いています。そこで Amazon Bedrock を導入しました。これは、お客様が FM を使用して生成AIベースのアプリケーションを簡単に構築およびスケーリングできるようにし、すべてのビルダーが誰でもアクセスできるようにするためです。Amazon Bedrock では、データを非公開かつ安全に保つための安全なカスタマイズをサポートしています。お客様は Amazon S3 のラベル付けされたいくつかのサンプルを Amazon Bedrock に適用するだけで、大量のデータにラベルを付けることなく、特定のタスクに合わせてモデルを調整できます。また、エンドツーエンドのデータ戦略を策定するという当社の包括的なテーマに沿って、使い慣れたコントロールと Amazon SageMaker や Amazon S3 などの AWS の深くて幅広い機能との統合により、お客様が AWS 上で実行されているアプリケーションやワークロードに FM を簡単に統合してデプロイできるようにしています。 Amazon Bedrockがいかに簡単に使い始められるかを楽しみにしている一方で、多くのお客様がすでに生成AI のユースケースで既存の AWS サービスを活用していることも認識しています。たとえば、お客様は Amazon SageMaker Jumpstart と Amazon SageMaker Studio を使用して FM のトレーニング、ファインチューニング、デプロイ、および運用を大規模に行っています。また、 AWS を活用したタンパク質フォールディングのガイダンス を使用すると、オープンソースの分子モデルを使用してワークフローを俊敏かつ大規模に実行できます。研究開発セッションにおける生成AIについて詳しく知るには、「 ML による創薬研究の加速 」の まとめ をご覧ください。 データのトラックには、思慮深く準備されたライトニングトークから魅力的な座談会まで、他にも8つのセッションが用意されていました。先見の明のあるリーダーたちがステージに上がり、AWS を使用して重要な課題にどのように取り組んでいるかについて、刺激的な実例と共に紹介しました。また、AWS 主導のセッションも行われ、お客様の現在および将来のニーズを満たす新しい機能を紹介しました。 最初に、世界最大級のバイオバンクを構築するにあたり、AWS を使用して データストアを最適化 することで精密医療を加速させる方法を Ovation が紹介しました。参加者は、Amazon Omicsをどのように活用して、リンクされたオミクスやフェノタイプデータを安全かつ効率的に保存、クエリし、大規模に顧客に配信しているのかを知ることができました。Ovation は、AWS Data Exchange を介して、匿名化されリンクされたオミクスおよびフェノタイプデータへのアクセスと分析が、信頼性が高くコスト効率が高いことを説明します。研究者は、Ovation のオミックスやフェノタイプデータを自分の環境に直接取り込み、そのデータを AWS Step Functions と AWS Lake Formation を使用してデータレイクと Amazon Omics のバリアントストアにインポートできます。このデータは Amazon SageMaker ですぐに利用でき、複数の AI または ML モデルを構築してデプロイし、患者のオミクスプロファイルと疾患リスク、疾患の進行、治療結果との関係などのインサイトを得ることができます。 Ovation のセッションの後、 Amazon Omicsの5つの新機能 が発表されました。これにより、企業は定価によるワークフロー実行による予測可能な価格設定でワークロードをより簡単に構築、実行、スケーリングできるようになります。これには以下が含まれます。1/ Ready2Run のワークフロー 、顧客が数回のクリックまたは 1 回の API 呼び出しで分析用の事前構築済みパイプラインを実行できる、2/ NVIDIA Parabricks とオープンソースのプロテインフォールディングパイプラインによる AI ベースのゲノミクス解析を高速化するための Omics プライベートワークフローにおける NVIDIA T4 および a10 グラフィカルプロセッシングユニット (GPU) のサポート 、3/ FASTQ、BAM、CRAMファイルをコストパフォーマンスの高い価格で大規模に保存するための新しい取り込みAPIを使用したOmicsストレージへの 直接データ取り込み 、4/ 簡単にバリアントコールファイル (VCF) とアノテーションデータを変換してマルチオミック分析やマルチモーダル分析に使用できるようにすることで、自動バリアントデータ解析によるクエリと分析、5/ イベント駆動型アプリケーションと Amazon EventBridge の統合により、Amazon Omics が公開したイベントは、ラボ情報管理システム (LIMS) や診断レポートシステムなどの他の AWS サービスやソフトウェアアプリケーションと簡単に統合できます。これらの新機能は、Kite Pharma、コロンビア大学医療センター、FYR Diagnosticsなどのお客様ですでに使用されており、変更を加えることなく業界標準の分析ワークフローを実行できるようになっています。 ガバナンス の重要な側面を取り上げなければ、データに関する議論は包括的とは言えません。 Collibra は、データドリブンな組織文化を構築し、スチュワードシップ管理、包括的なビジネス用語集、一元的なポリシー管理、そして最も重要なこととして、安全で管理されたデータアクセスの簡素化などのセルフサービス方式を通じてデータを容易に入手できるようにするためのベストプラクティスについてのインサイトを共有しました。 それに続き、2 つのバイオ医薬品企業である Eli Lilly と Foundation Medicine が、自社データの価値を引き出すためのライトニングトークを発表しました。140 年以上前に設立された Lilly は、AWS上で社内データをあたかも製品として扱うような重厚なデータエコシステムを形成し、(FAIR の原則に沿った) 広範なマルチモーダルデータランドスケープを活用することで、いかに研究開発を加速させているかについて紹介しました。ハイライトは、研究データプラットフォームがどのようにさまざまな AWS サービスを使用してデータストレージ、データアクセス、データ製品レイヤーを構築し、研究者がポートフォリオの意思決定に関するインサイトをより迅速かつ効率的に得ることができるかを詳しく説明したことです。Lilly はまた、LLMや会話型AIを創薬に活用する今後の取り組みについても話しました。一方、Foundation Medicineは、自社のエンタープライズデータプラットフォームがどのようにFDAの承認を早め、医学研究機関とのより緊密なコラボレーションを促進しているかを共有しました。 コラボレーションの流れに続き、次のセッションでは、AWS とパートナーの Datavant が、 AWS Clean Rooms が HIPAA 適格になったこと を発表しました。医療機関やライフサイエンス企業は、パートナーと数分でAWS Clean Roomsのコラボレーションを構築し、基礎となるデータを共有したり、AWSの外に移動したりすることなく、集合的なデータセットを分析できます。 Datavantは、データの匿名化とトークン化機能のデモを実施しました。 これにより、顧客は識別可能な患者情報を、リバースエンジニアリングして元の情報を明らかにできない暗号化された「トークン」に置き換えることができるため、集団分析が容易になり、新しいインサイトを得ることができます。 また、学術機関、非営利団体、連邦政府機関の研究者に対し、今年1月から NIHが資金提供したすべての研究データを一般に公開する ことを義務付ける 米国政府の新しい規制変更 についても取り上げました。この画期的な執行規制は、臨床研究とライフサイエンスに幅広い影響を及ぼします。技術開発拠点の1つに指定されている MITRE は、これらの変化が Cancer Moonshot Initiative などの主要プログラムにどのように影響するかを発表しました。彼らは、25年以内にがんによる死亡率を50％削減するという国の取り組みにおいて、クラウドインフラストラクチャとソフトウェアソリューションを使用することで、データ収集と共有のメカニズムがどのように強化されるかを説明しました。参加者は、ポータブルで共有可能で標準化されたがん医療記録を作成するプログラムであるCC-Direct、あらゆるタイプのがんのEHRデータの質を向上させるデータ標準であるmCode、mCodeに関する相互運用可能なデータモデリングと実装を加速し、がん治療の段階的な改善につながるプラットフォームであるCoDexについて意見を聞きました。 最後に、AWSのパートナーである TrinetX が、 投資に見合った価値を備えたリアルワールドデータ製品を作る という彼らの革新的なアプローチについて発表しました。参加者は、AWS 上に構築された、200 を超える医療機関の 1 億5,000万人以上の患者からのリンクされたデータで構成される、大規模なリアルワールドデータエコシステムを垣間見ることができました。製薬会社はTrinetXと協力して、臨床試験からエビデンス生成まで、さまざまなユースケースに対応するHCOのグローバルネットワークから患者コホートにアクセスできます。Amazon S3 と Amazon Redshift 経由の Amazon Data Exchange を使用すると、組織はインフラストラクチャを維持する必要なく、このデータに簡単にアクセスして数分でインサイトを引き出すことができます。 セッション中に提示されたすべての内容が、お客様にとって実行可能なものであることを確認することが私たちにとって極めて重要でした。その一環として、セッション終了後に Ask-the-Expert デモとネットワーキングエキスポを開催しました。参加者は AWS の専門家と面談して、当社サービスの詳細なデモを見たり、不明な点があれば質問したりしました。 最後に考えたのは、17 年前に AWS を立ち上げたときから、臨床およびライフサイエンスの研究者がクラウド利用の最前線にいたということです。そして、シンポジウムで業界のリーダーたちが団結し、個別化医療に向けて大きな一歩を踏み出すのを目の当たりにしたことは、私たちが「the art of the possible」と呼ぶものの真の姿でした。 当社の包括的なデータサービスの詳細については、 AWS Health for Data ウェブサイトをご覧ください。特定のビジネスニーズについて AWS スペシャリストと 1 対 1 で話し合いたい場合は、 こちら からお問い合わせください。 Valerie Delva Valerie Delvaは、AWS の Data/AI/ML 戦略およびソリューション担当のワールドワイドヘッドです。彼女はヘルスケアとライフサイエンスのエグゼクティブであり、データ製品の開発と提供、市場開拓と事業開発の先頭に立ち、規制対象の業界が交差する場所で新しいベンチャーを立ち上げ、学際的なチームを率いた経験があります。AWS に入社する前は、Foundation Medicine、Gilead Sciences、米国保健社会福祉省など、民間部門と公共部門の両方で上級職を歴任しました。彼女は、データの力を最大限に活用して、医療をより予防的、パーソナライズされた、利用しやすいものにすることに全力を注いでいます。 翻訳はソリューションアーキテクトの松永と事業開発の亀田が担当しました。

5 月 15 日、ボストンで AWS ライフサイエンス・エグゼクティブ・シンポジウム が開催され、その中で私は「機械学習（ML）による創薬の加速」というテーマでトラックを担当しました。この半日の対面イベントには、100 を超える組織から 300 人以上のライフサイエンス企業のエグゼクティブが参加し、堅牢なデータ基盤とクラウド上の機械学習によってどのようにイノベーションを推進できるかを探りました。 本シンポジウムのオープニングセッションでは、AWS がどのようにライフサイエンス企業が創薬にジェネレーティブ AI, Foundation Models　(FMs), LLM　（Large Language Models）を活用することを可能にしているか、潜在的な副作用の特定や臨床試験データセットの検索などのユースケースを通して紹介しました。私たちは、オープンソースの様々な分子モデルに対して、簡単に実行できるタンパク質アルゴリズムを発表し、AWS が使用可能なタンパク質構造を生成するために必要なコストと時間を大幅に削減できることを実証しました。参加者は、AlphaFold と ESMFold アルゴリズムを単一の API またはコンソールでデプロイするための Amazon Omics サービス内の Ready2Run ワークフローに、透過的で実行ベースの価格設定とスケーラブルなインフラストラクチャでアクセスできることに注目していました。また、DiffDock, RFDesign, RFDiffusion, ProteinMPNN, AlphaFold, OpenFold, OmegaFold, ESMFold を含む複数のアルゴリズムを共有ユーザーインターフェースでサポートする、 AWS Batch Architecture for Protein Folding and Design に基づく AWS の Drug Discovery Workbench のプレビューも行いました。 また、AWS が、適切なモデルの検索から、安全なカスタマイズ、既存のアプリケーションへの統合まで、FMs を使った構築が最も容易な場所である理由も示しました。AWS のジェネレーティブ AI に対するアプローチは ML と同じで、ライフサイエンス企業がジェネレーティブ AI を簡単に、コスト効率よく、実用的に活用できるような新しいイノベーションを提供することです。実際、AWS のお客様は、反復タスクのスピードアップから、タンパク質や疾患経路に関する新たな知見の発見まで、さまざまなユースケースですでにジェネレーティブ AI を活用しています。シンポジウムでは、 Amazon HealthLake チャットボットや、 Amazon Kendra と LLM を活用した臨床試験チャットボットなど、私たちが事前に訓練したモデルの一部を参加者にこっそりお見せしました。お客様は、今日からこれらの事前学習済みモデルを使い始めることができます。 セッションでは、基盤モデル、組み込みアルゴリズム、および事前に構築された ML ソリューションを備えた機械学習（ML）ハブである Amazon SageMaker JumpStart を、ユーザーがわずか数クリックで開始できるようにする方法について説明しました。さまざまな業界のビルダーが、JumpStart で事前に訓練されたモデルを使用して、記事の要約や画像生成などのさまざまなタスクを実行しています。これらのモデルは、データを使用するあらゆるユースケースに合わせて完全にカスタマイズすることができ、ユーザーインターフェースまたは SDK を使用して本番環境に簡単に導入することができます。また、すべてのデータは暗号化され、仮想プライベートクラウド（VPC）を離れることがないため、データのプライバシーと機密性が保たれることが信頼できます。 同時に、ジェネレーティブAI を構築する際には選択肢が重要であることも理解しています。それが Amazon Bedrock を導入した理由です。Amazon Bedrock は、Foundation Models（FMs）を使ってジェネレーティブ AI アプリケーションを構築し、拡張する最も簡単な方法です。Amazon Bedrock は、AI21 Labs, Anthropic, Stability AI, および Amazon の FMs を API 経由でアクセス可能にし、独自のモデルを構築しているかサードパーティのものをライセンス供与しているかに関わらず、すべての構築者のアクセスを民主化します。また、セキュアなカスタマイズにも対応しているため、データはプライベートかつセキュアに保たれます。Amazon Bedrock は、 Amazon S3 にあるいくつかのラベル付けされた例を示すだけで、大量のデータに注釈を付けることなく、タスクのモデルをファインチューニングすることができます。そして、エンド・ツー・エンドのデータ戦略を構築するという我々の包括的なテーマに沿って、私たちは、顧客が使い慣れたコントロールと Amazon SageMaker や Amazon S3 のような AWS の深さと幅のある機能との統合を使用して、AWS 上で実行されているアプリケーションとワークロードに FM を容易に統合し、デプロイできるようにしています。Amazon Bedrock は、1 つのソリューションや 1 つのモデルでは、お客様が直面する全てのビジネス上の問題を解決することは難しいというシンプルな事実に対応しています。 LLM やジェネレーティブ AI が、新しい治療法を発見するまでの時間を短縮するのに役立つことは間違いありません。しかし、研究の未来に多くの希望を生み出す一方で、現実の研究開発現場でのこれらの技術の採用はまだ限られています。 「Reverie Labs と Recursion Bio による誇大広告対希望のパネルディスカッション」がタイムリーであったのはこのためであり、研究においてジェネレーティブ AI の適用を成功させるための推進力と考慮事項、そして最も有望な分野について、参加者に明確な理解を提供しました。我々はまだジェネレーティブ AI の黎明期にあり、知識統合革命の始まりにいます。FMs と LLM は、その応用方法において大きな可能性を示しており、今後も斬新な応用や産業界での採用が拡大していくと考えられます。そして、アマゾンの Day 1 の文化に則り、これからも多くのことが起こるでしょう。 「創薬のための今後の ML イノベーションのセッション」では、今後勢いを増すと思われるエキサイティングな進歩について、聴衆を魅了する見解を示しました。これには、疾患遺伝子予測への FMs の利用、Meta AI ESM を用いた新規薬剤合成、拡散モデルを用いた創薬などが含まれます。また、共有された ML モデルを共同でトレーニングするために、組織内または組織間のデータセットへのプライバシーを保持したアクセスを提供する、連合学習についても取り上げました。さらに、ディープフェノタイピングとディープラーニングを画像解析に利用することで、デジタル病理学においてより高い精度、効率性、拡張性を実現する方法についても解説しました。 AWS の AI/ML サービスに関する話題は、AWS の著名なゲストスピーカーによるセッションへと続きました。先進的な企業数社のリーダーがステージに参加し、AWS 上の機械学習によって日常的な課題に対処し、新薬をより早く世に送り出す方法について、刺激的な実例を共有しました。 Bristol Myers Squibb 社は、「AWS を利用したハイパフォーマンス・コンピューティングとクライオ電子顕微鏡で、どのように生産性とスケールを最大化しているか」を紹介しました。高度に最適化されたアーキテクチャーを構築することで、これらの計算集約的なワークフローをオンプレミスで実行する際に一般的に直面する課題である、膨大な資産要件、GPU の老朽化、データセンターの可用性の制約、弾力性の欠如をうまく乗り越えています。BMS の目的に合ったクライオ電子顕微鏡ワークフローは、処理と解析のために顕微鏡から AWS に動画を転送し、コスト、スケール、スループットを最適化します。これにより、同社は医薬品開発期間を 10 年から 6 年に短縮するという目標に向けて前進しています。 Regeneron 社は、「AI を活用したタンパク質構造予測」による標的創薬プロセスの改善について発表しました。タンパク質の構造を特定することは、多くの創薬ワークフローの重要な部分ですが、高価であり、時間がかかることが多いです。ML でこの課題に対処するため、Regeneron 社は最先端のツールを科学者に提供し、複数のアプローチをテスト・比較し、原子レベルの精度まで数分でタンパク質の形状を予測できるようにしています。AWS は、データに適切なコンピュートリソースを提供し、コストを管理する弾力性を提供し、物理インフラストラクチャを管理する差別化にならない重労働を取り除くことで、同社がこれらのワークロードを拡張するのを支援しています。 Pfizer 社は、「セマンティックラーニングのためのナレッジグラフ（KG）を活用した組織内の情報を統合」についての洞察を共有しました。彼らのセッションは、データの標準化を通じてナレッジグラフの使いやすさを向上させることに光を当て、What-if シナリオとその潜在的な影響を探るためにKG の上にAI/ML を統合することを探求しました。レガシー製品のpH研究をサポートするための6年前のラボデータの検索や、臨床試験で使用される製品のロット系譜の研究など、さまざまなナレッジグラフのユースケースを通じて、KG が実験の繰り返しを防ぎ、材料費や人件費を数百万ドル節約するのに役立っていることを説明しました。特にエキサイティングなアプリケーションは、フルマネージド・データベース・サービスである Amazon Neptune を使用して、Graph explorer を介して化学反応の経路を理解することでした。 そして最後に、Generate Biomedicines 社は、ML を活用した計算ツールを用いて新規タンパク質治療薬を生成することで、従来の試行錯誤的な創薬手法の必要性を排除していることを説明しました。同社のジェネレーティブ AI プラットフォームである Chroma が、Protein Data Bank からパターンを学習し、幾何学的および機能的プログラミング命令に基づいて新しいタンパク質分子を生成する方法を紹介しました。Chroma は、GPU1 つで非常に大きなタンパク質やタンパク質複合体（自然界で見られるようなもの）を数分で生成することができ、その後、薬としての有効性をさらに研究することができます。このセッションは、ウェット・ドライを統合した「未来のラボ」が、いかに創薬を真に計算科学的・技術的な追求に変えることができるかを例証するものでした。 一日を通して、AWS が AI/ML サービス、インフラ、実装リソースの最も包括的なセットで、創薬の旅のあらゆる段階で、あらゆる規模の企業をどのように支援しているかを強調するセッションが行われました。しかし、私たちにとって重要だったのは、セッション中に発表されたすべての内容を簡素化し、お客様にとって実用的なものにすることでした。そのために、セッション終了後に専門家に質問するネットワーキングエキスポを開催し、参加者は AWS の専門家と会い、私たちが提供するサービスの詳細なデモを見たり、明確な質問をしたりしました。 ライフサイエンス企業が機械学習を効果的に推進するために克服しなければならない最大の課題の一つは、 データの活用です。このため、シンポジウムでは「データへのアクセスと洞察の活用」をテーマにしたトラックも並行して開催し、マルチモーダルデータの効率的な保存、分析、カタログ化、共有のためのさまざまな目的別サービスとソリューションを紹介しました。データ・トラックのハイライトは こちら をご覧ください。 17 年前に AWS を立ち上げたとき、ライフサイエンスの研究者はクラウド導入の最前線にいました。今日、製薬会社のトップ 10 のうち 9 社がデータ分析や機械学習に AWS を使用しています。私たちのシンポジウムで業界のリーダーたちが団結するのを目の当たりにし、感銘を受けました。それは、私たちが “the art of the possible”（可能性の芸術 ）と呼ぶものの真の描写でした。 AWS が提供するライフサイエンス分野の包括的なサービスの詳細については、 AWS for Life Sciences のウェブサイトをご覧ください。AWS のスペシャリストと一対一でお客様のビジネスニーズについてご相談されたい場合は、 こちら からお問い合わせください。 著者について Lisa McFerrin Lisa McFerrinは、Amazon Web Servicesの　研究、発見、トランスレーショナルメディシンのためのHealthcare and Lifesciencesチームの　WW　Lead　です。Lisaは数学とコンピュータサイエンスのバックグラウンドを持ち、バイオインフォマティクスの博士号を取得しています。がん生物学の理解を深め、患者ケアを改善するために、生物医学データを橋渡しするソフトウェアと手法において15年以上の経験があります。共同研究や再現性のある研究を促進するため、データ解析の障壁を下げることに尽力しています。 Ujjwal Ratan Ujjwal Ratanは、Amazon Web ServicesのGlobal Healthcare and LifesciencesチームのPrincipal Machine Learning Specialistです。医療画像、非構造化臨床テキスト、ゲノミクス、精密医療、臨床試験、医療の質向上など、実世界の業界問題への機械学習と深層学習の応用に従事しています。AWSクラウド上での機械学習/ディープラーニングアルゴリズムのスケーリングに精通し、トレーニングや推論を高速化をおこなっています。趣味は音楽を聴くこと（および演奏すること）と、家族と計画を立てずにドライブ旅行をすることです。 翻訳は Solutions Architect の原田が担当しました。原文は こちら です。

Cox Automotive Inc. は、自動車の購入、販売、所有、利用をすべての人にとってより簡単にする会社です。グローバル企業である同社は34,000以上のチームメンバーと、Autotrader®、Clutch Technologies、Dealer.com®、Dealertrack®、Kelley Blue Book®、Manheim®、NextGear Capital®、VinSolutions®、vAuto®、Xtime® などのブランドファミリーを有しています。5大陸にまたがる数百万の自動車購入予定者や、クライアントである4万の自動車ディーラー、その他多くの自動車関連企業が、今後、何世代にもわたって繁栄できるよう支援することに情熱を注いでいます。 Dealer.comなどのプラットフォームでeコマースのウェブサイトを運営している自動車ディーラーは、サイト訪問者をターゲットに、関連性の高いパーソナライズされたコンテンツを提供する革新的な方法を必要としています。ディーラーは、パーソナライズされたコンテンツを提供するために、買い物客をセグメント化し、関連する広告を表示し、さらにさまざまな買い物客のセグメントごとにパーソナライズされたEメールのドリップキャンペーンを実施するためのツールを必要としています。 従来、ウェブサイト訪問者は、サードパーティCookieを使用して複数のドメインにまたがり追跡されていました。既にいくつかのブラウザはサードパーティCookieの段階的廃止を完了しており、残りのブラウザは2022年までに段階的に廃止される予定です。この変更は、Cox Automotiveがオンラインの買い物客にパーソナライズされたコンテンツを提供する方法に大きく影響を及ぼすものです。 Cox Automotiveの各事業部門は、買収によって統合された後、サイロ化した状態で発展してきました。そのため、事業部門間のデータを統合し、消費者世帯の全体的な360度ビューを作成する必要性が高まっています。 Consumer Insightsのチームは、ブランドをまたいで買い物客のパーソナライゼーションサービスを提供することに注力しています。そのソフトウェアは、消費者、自動車販売店、自動車OEMに提供されています。 2019年10月にConsumer Insightsのチームは、サードパーティのCookieへの依存度を下げつつ、ビジネスユニット間で活用できる世帯の360度ビューを構築するニーズの高まりに対応するため、IDグラフのアプローチを使用することを決定しました。チームは、このIDグラフのニーズに対して、Amazon Neptuneを使用することを決定しました。 Neptuneはフルマネージド型のグラフデータベースサービスです。このサービスでは、高度に接続されたデータセットを使用したアプリケーションを簡単に構築および実行できます。Neptuneは、数十億のリレーションシップを保存し、ミリ秒単位のレイテンシーでグラフをクエリするために最適化された、専用の高性能グラフデータベースエンジンです。Neptuneは、Property Graphと Resource Description Framework (RDF) 標準の両方をサポートしています。 Consumer Insightsのチームはパーソナライゼーション機能を構築するために、IDグラフで、下記を含むいくつかのデータソースを使用しています。 Pixall Dataと呼ばれるCox Automotive独自のデータ 車両の在庫 消費者の閲覧履歴 車両の取引 車両のリード 最初のフェーズでConsumer Insightsのチームは、消費者の閲覧履歴をCRM内のデータ（リードとトランザクション）と結びつけるIDグラフを構築しました。次の図は、チームのアプローチの概要を示しています。それは、マルチチャネルマーケティングのパーソナライゼーションのあらゆる側面を推進するようなIDグラフのビジョンを作り上げながら、現在の課題に対処するアプローチです。 Neptuneが選ばれる理由 Consumer Insightsのチームは、実験として、IDグラフの接続されたデータセットを、マネージド型リレーショナルデータベースやキーバリューストア、インメモリデータベース、グラフデータベースで保存してみました。この実験では、パフォーマンスとTCOに焦点が当てられました。その結果、Neptuneに有利となる重要な技術的側面が2点、明らかとなりました。 データモデリングの簡素化 — 従来のリレーショナル・データベースは、その厳格なスキーマと関係性から、グラフ問題のデータモデルを構築する上で難題となっていました。Consumer Insightsのチームは、適切なデータモデルを構築するために何度も試行錯誤を繰り返しました。このデータモデルは、新しい頂点や辺が特定される際にクエリーのパフォーマンスやSQLで目的のクエリーを書くことが難しく、拡張することが困難でした。一方で、データをグラフでモデリングすることで、ビジネスのユースケースを模倣することができました。これは、Neptuneがユースケースに自然にフィットしていることを示す最初の兆候でした。 クエリのパフォーマンス — Neptuneはすぐに使用でき、チームのニーズを満たすクエリパフォーマンスを提供することで、チームが最適化に費やす時間を節約してくれました。エッジと頂点が追加されても、クエリのパフォーマンスは悪化しないまま拡張することができました。 IDグラフ Neptuneが提供するデータモデルの簡略化を明らかにするために、Consumer InsightsチームはIDグラフを下図のように視覚化しました。これは、Cookie、IP アドレス、CRM IDの3つのエンティティ (頂点) 間のリレーションシップを示しています。 この図は、IDグラフで実際に使用されるGremlinクエリを示しています。次に示すクエリは、簡単な手順によってビジターのID解決を容易にするものです。このクエリは、最初に与えられたビジター (request.uid) に対して、グラフを走査し、そのビジターへのエッジを持つCRM IDの頂点を見つけます。そしてそのCRM IDに接続するエッジを持つすべてのビジターIDを特定します。 この時点で、前述の2つのビジターIDが特定されています。この２つのビジターを基に、そのビジターへのエッジを持つすべてのIPアドレスを特定します。そのIPアドレスを基に、IPアドレスに接続されたエッジを持つすべてのビジターIDを見つけることができます。前図では、1件のビジターIDが、グラフを辿ると6件のビジターIDになります。 IDグラフを強化するビジネスプロセス データベースとしてNeptuneを選択した後、Consumer Insightsのチームは、次のステップとして実際にIDグラフを構築することに着手しました。 IDグラフは、ID解決を提供するパーソナライズマーケティングの中核をなすものです。これは、householding（世帯単位のデータの関連付け）とリードマッピングという、消費者と世帯の360度ビューを作成するための2つの異なるステップ上に構築されています。 Householding Householdingとは、買い物客や買い物見込みに関するデータについて、「世帯」を特定して結びつけるプロセスのことです。Householdingでは、さまざまなウェブサイト、デバイス、インターネット接続にまたがる匿名の消費者アクティビティ（Cookie）を結びつけることができます。 Cox Automotiveのデータサイエンスチームは、複数のAI/MLベースの確率的プロセス（確率論に基づくプロセス）を実行し、データを拡充し、まとめてマッピングしています。確率的プロセスのアウトプットでは、IPアドレス (IDグラフの頂点) とビジターID (Cookie) の間に1対多のリレーションシップが作成されます。 拡充されたhouseholdingデータにより、Neptuneへ一括ロードするための3つのファイルが作成されます。 IPアドレス (頂点) ビジターID (頂点) リレーションシップ (エッジ) 次の表に、IPアドレスの頂点を含むファイルを示しています。 ~id ~label createTime:String(single) Name:String(single) 0.0.0.0_ipAddress ipAddress 7/10/2020 2:00 PM 0.0.0.0 1.1.1.1_ipAddress ipAddress 7/11/2020 2:00 PM 1.1.1.1 2.2.2.2_ipAddress ipAddress 7/12/2020 2:00 PM 2.2.2.2 次の表は、ビジターIDの頂点を含むファイルを示しています。 ~id ~label createTime:String(single) Name:String(single) abc_visitor visitor 7/10/2020 2:00 PM abc def_visitor visitor 7/11/2020 2:00 PM def ghi_visitor visitor 7/12/2020 2:00 PM ghi 次の表は、IPからビジターへのエッジを含むファイルを示しています。 ~id ~from ~to ~label abc_visitor_0.0.0.0_ipAddress abc_visitor 0.0.0.0_ipAddress hasIPAddress def_visitor_1.1.1.1_ipAddress def_visitor 1.1.1.1_ipAddress hasIPAddress ghi_visitor_2.2.2.2_ipAddress ghi_visitor 2.2.2.2_ipAddress hasIPAddress リードマッピング リードマッピングのプロセスでは、Cox Automotiveブランドのサイトで記入されたリードフォームからデータが収集されます。リードフォームは、内部で生成されたcrm_id (IDグラフの頂点) とビジターID (自動車購入予定者のCookie) にマッピングされます。 リードマッピングのプロセスにより、Neptuneへ一括ロードするための3つのファイルが作成されます。 CRM ID (頂点) ビジターID (頂点) リレーションシップ (エッジ) 次の表は、CRM IDの頂点を含むファイルを示しています。 ~id ~label createTime:String(single) Name:String(single) 123_crmid crmid 7/10/2020 2:00 PM 123 456_crmid crmid 7/11/2020 2:00 PM 456 次の表は、リードビジターIDの頂点を含むファイルを示しています。 ~id ~label createTime:String(single) Name:String(single) abc_visitor visitor 7/10/2020 2:00 PM abc def_visitor visitor 7/11/2020 2:00 PM def ghi_visitor visitor 7/12/2020 2:00 PM ghi 次の表は、CRM IDからビジターへのエッジを含むファイルを示しています。 ~id ~from ~to ~label abc_visitor_123_crmid abc_visitor 123_crmid hasCRMid ghi_visitor_456_crmid ghi_visitor 456_crmid hasCRMid IDグラフをインクリメンタルに更新 この記事の執筆時点では、アイデンティグラフは約5億個のエッジと約4億個の頂点からなり、db.r5.2xlargeインスタンスタイプのNeptuneクラスター上で実行されています。 Householdingのプロセスでは、毎日完全なデータセットが作成され、Amazon Simple Storage Service (Amazon S3) バケットに保存されます。Neptuneのパフォーマンスを最適化するために、Consumer InsightsのチームはAmazon EMRのジョブを開始します。このジョブは、今日の完全なデータと前日のデータセットとの差分ファイルを毎日作成しています。新規の追加や変更は、Neptune バルクロードAPIを使用してNeptuneに一括アップロードするようスケジューリングされています。バルクロードが完了すると、別のEMRジョブが開始され、Gremlin APIを使用して新規の削除が処理されます。最後に、EMRジョブはGremlin APIを使用して、孤立した頂点をすべて削除します。 リードマッピングのデータプロセスでは、増分データセットが作成されS3バケットに格納されます。EMRジョブの始動により、リードマッピングデータセットは毎晩Neptuneへ一括ロードされます。 全体的なソリューションアーキテクチャ 次のブロック図は、Consumer Insightsのチームがビジネスユニットに完全なパーソナライゼーション機能を提供する計画の概要を示しています。この機能は、Neptuneからの世帯とリードのマッチング、そしてDynamoDBからの閲覧履歴を、買い物客のセグメンテーションと車両のレコメンデーションと組み合わせます。Autotrader®、Dealer.com®、Kelley Blue Book®、VinSolutions®などのビジネスユニットにまたがり利用されるダウンストリームのプロセスは、統合された世帯のビューに基づいてコンテンツのパーソナライゼーション、広告ターゲティング、リマーケティング、店舗でのパーソナライゼーションを促進します。黄色で強調表示されたブロックは、IDグラフの基本要素です。このセクションでは、さらにdeep diveし、IDグラフに使用されるアーキテクチャについて紹介します。 NeptuneによるID解決は、その下流のプロセスに対してリアルタイムのクエリ・応答を提供しているため、パーソナライゼーションAPIにとっては、ミッションクリティカルな要素です。したがって、耐障害性、高可用性、およびオペレーションの拡張性は、Consumer Insightsのチームにとって非常に重要です。これらの技術目標を容易にするために、Neptuneのライターノードはdb.r5.2xlargeインスタンスを使用し、複数のアベイラビリティゾーンにまたがる2つのリードレプリカを備えています。いずれのリードレプリカもライターノードと同じインスタンスタイプを使用しています。すべてのREST APIデータのルックアップは、両方のリードレプリカによって処理されます。水平なスケールアウトを可能にするために、クライアントアプリケーションはNeptuneのリーダーノードに直接アクセスするのではなく、Neptuneに組み込まれた負荷分散リーダーエンドポイントを使用します。 次の図は、IDグラフのソリューションアーキテクチャを示すもので、グラフ (Amazon S3、Amazon EMR、バルクローダーを使用)、Multi-AZ のNeptuneリードレプリカ、および組み込みのロードバランサーを段階的に更新する手順を示しています。 結論 Consumer InsightsのチームがNeptuneベースのID解決を展開した結果、個々の Cookieを使用した場合と比較して、平均で1世帯あたり2倍の閲覧履歴を得ることができました。これは、自動車購入予定者に向けた高度にパーソナライズされたコンテンツの作成を直接影響するもので、その結果、エンゲージメントやクリックスルー率、Eメール開封率が向上すると、チームは考えています。 執筆時点では、サードパーティCookieへの依存を減らし、消費者世帯の360度ビューを構築するという当面の目標には対処できています。広告セグメンテーションや車両レコメンデーションといったダウンストリームシステムは、新しいIDグラフと統合されつつあります。これらのダウンストリームプロセスのビジネスへの影響は、その統合が完了した後に定量化されるでしょう。 推奨事項 Consumer Insightsのチームは、IDグラフの構築と統合の9か月にわたるジャーニーを振り返って、グラフのユースケースに着手する他の企業、ソフトウェアアーキテクト、またはソフトウェアエンジニアを支援するために、次の教訓と推奨事項をまとめました。 トレーニングへの投資 チームにはグラフデータベースやNeptuneに関する社内のスキルセットはありませんでした。当初、チームはAWSと協力して12人のSDEを対象とした1日のトレーニングセッションを計画しました。トレーニングでは、GremlinおよびNeptuneのベストプラクティスに則ったグラフデータモデリングとクエリに焦点が当てられました。このトレーニングは、チームのグラフジャーニーにおいて非常に価値あるステップでした。 ベストプラクティスを理解する ビジネスユースケースを理解し、既存のグラフの実装例から学ぶことは、予期しない誤りを回避する最善策の1つです。チームは、Best Practices: Getting the most out of Neptuneが、最適な技術設計に最も役立ったリソースの1つであると感じました。 PoC のためのNeptuneインスタンスの適正なサイジング設定 PoC を行う際に適切なインスタンスタイプを選択することは、PoCの総コスト、およびデモアプリケーションの構築に費やすエンジニアリングチーム全体の時間に大きな影響を与える場合があります。経験則として、PoCで既存のデータをNeptuneに一括ロードする場合、最大のインスタンスを確保することで、データの一括ロードにかかる全体時間を短縮し、全体のエンジニアリング時間とコンピューティングコストを削減することができます。一括ロードが完了した後に、インスタンスサイズをより小さいインスタンスタイプに切り替えることで、貴重なリソースを節約することができます。 著者について Carlos Rendon氏はCox AutomotiveのPrincipal Technical Architectです。過去8年間、KBB.com、Autotrader.com、Dealer.com、およびVinSolutionsにおいて、消費者のリアルタイムパーソナライゼーション、車両レコメンデーション、および広告ターゲティングの提供に取り組んできました。 Niraj Jetly氏は、Amazon Web ServicesのNeptune担当のSoftware Development Managerです。AWSに入社以前は15年以上にわたり、CTO、VP-Engineering、Head of Product Managementとして、複数のプロダクトチーム、エンジニアリングチームを率いてきました。Niraj氏は、2014年にCIO of the year、2013年と2016年にトップ100人のCIOに選ばれるなど、15を超えるイノベーション賞を受賞しています。いくつかのカンファレンスで頻繁に講演しており、過去にはNPR、WSJ、The Boston Globeで引用されています。   本ブログの翻訳はソリューションアーキテクトの五十嵐が担当しました。原文は こちらのリンク から参照できます。

はじめに Amazon Elastic Container Service (Amazon ECS) や Amazon Elastic Kubernetes Service (Amazon EKS) で稼働するワークロードに様々なフォールトインジェクション (障害注入) ができる AWS Fault Injection Simulator (FIS) の新機能をお知らせします。このブログでは、Amazon ECS に関する新しい AWS FIS アクションの利用方法を紹介します。 AWS FIS は、アプリケーションの耐障害性を試験するためのフルマネージドサービスです。AWS FIS はカオスエンジニアリングの原則に従っており、AWS 環境における障害をシミュレートできます。ネットワーク停止、インフラ障害、サービス中断などをシミュレートできます。AWS FIS を活用した障害試験は、本番環境で障害が発生する前に潜在的な問題を発見し修正するのに役立ちます。 Amazon ECS タスクの新しいアクション Amazon ECS ワークロードを対象に、新しく 6 個のフォールトインジェクションアクションを追加しました。新しい Amazon ECS タスクアクションには、「CPU 負荷をかける」「ストレージ I/O 負荷をかける」「プロセスの停止」「ネットワークトラフィックの停止」「ネットワークレイテンシーの増加」「パケットロス」などがあります。これらの新しいアクションにより、さまざなま障害シナリオによるアプリケーションの信頼性や回復力を簡単に評価できるようになりました。なお、 AWS Fargate を利用している場合は、「CPU 負荷をかける」「ストレージ I/O 負荷をかける」のアクションは利用できますが、それ以外のアクションは利用できません。 アクション名 説明 利用できるコンピュートリソース aws:ecs:task-cpu-stress CPU 負荷をシミュレート 設定できるパラメーターは、負荷をかける期間・目標の CPU 使用率・使用するストレッサーの数 Amazon EC2、AWS Fargate aws:ecs:task-io-stress ストレージ I/O 負荷 をシミュレート設定できるパラメーターは、負荷をかける期間・負荷をかける際のファイルシステムの空き容量の割合・様々な I/O 負荷をかけるストレッサーの数 Amazon EC2、AWS Fargate aws:ecs:task-kill-process 特定のプロセスを停止するシミュレート 設定できるパラメーターは、停止するプロセスの名前・送信するシグナル名 Amazon EC2 のみ aws:ecs:task-network-blackhole-port ネットワークトラフィックの停止 設定できるパラメーターは、停止する期間・対象のポート番号やプロトコル Amazon EC2 のみ aws:ecs:task-network-latency ネットワークレイテンシーのシミュレート 設定できるパラメーターは、ネットワークレイテンシーを追加する期間・対象のネットワークインターフェース・追加する遅延やジッタ―のミリ秒・送信元の指定 Amazon EC2 のみ aws:ecs:task-network-packet-loss ネットワークパケットロスのシミュレート 設定できるパラメーターは、パケットロスを実行する期間・対象のネットワークインターフェース・パケットロスの割合・送信元の指定 Amazon EC2 のみ Amazon ECS タスクにフォールトインジェクションを行う仕組み 次の図は、AWS FIS が Amazon ECS タスクにフォールトインジェクションをどのように行うかを表現しています。AWS FIS は AWS Systems Manager SSM Agent を使って、 フォールトインジェクション を実行しています。Amazon ECS タスク内で、サイドカーとして SSM Agent を動かすことで、AWS FIS がフォールトインジェクションを実行できるようにしています。これにより、Systems Manager の Run Command 経由で様々な障害試験を行うことで、潜在的な問題を発見し改善しやすくなります。AWS FIS のフォールトインジェクションを行うために、ECS のタスク定義に、SSM Agent のサイドカーを追加する必要があります。 ウォークスルー 次のステップで、AWS FIS を使ったフォールトインジェクションを体験できます。 CDK を使用して、インフラストラクチャの構築とサンプルアプリケーションのデプロイ CDK によって自動生成された、ECS のタスク定義の確認 AWS FIS にフォールトインジェクションを行うための権限設定 CPU に負荷を与える試験 ECS タスク内のプロセスを停止する試験 前提条件 このウォークスルーを行うためには、次の環境が必要です。 AWS CLI Version 2 AWS CDK Tooklit Python で AWS CDK を動かす環境 Node.js バージョン 14.15.0 以上 Python バージョン 3.6 以上 Step 1: インフラストラクチャの構築 AWS FIS を活用した障害試験を行うため、 AWS CDK を利用して、Amazon VPC (Amazon Virtual Private Cloud) や Amazon ECS クラスター、Amazon ECS Service、AWS IAM (AWS Identity and Access Management) ロール、2 つのAmazon EC2 インスタンスを作成します。CDK コードは、GitHub リポジトリに公開されている ECS Blueprints を利用します。 サンプルコードをリポジトリからクローンします。 git clone https://github.com/aws-ia/ecs-blueprints.git cd ecs-blueprints/cdk/examples/fis_service/ 利用している環境に合わせて、AWS アカウントとリージョンの環境変数を設定します。次に、ECS Blueprints の CDK テンプレートで利用する .env ファイルを生成します。この記事では、オレゴンリージョン (us-west-2) を利用していきます。 export AWS_ACCOUNT=$(aws sts get-caller-identity --query 'Account' --output text) export AWS_REGION=${AWS_REGION:=us-west-2} sed -e "s/<ACCOUNT_NUMBER>/$AWS_ACCOUNT/g" \ -e "s/<REGION>/$AWS_REGION/g" sample.env > .env 次のコマンドを実行します。 # virtualenv を作成 python3 -m venv .venv # virtualenv を有効化 source .venv/bin/activate # 依存しているライブラリをインストール python -m pip install -r ../../requirements.txt 初めて CDK でインフラストラクチャを作成する場合は、Bootstrap を実行します。 cdk bootstrap aws://${AWS_ACCOUNT}/${AWS_REGION} CDK を利用して、Amazon ECS クラスター を作成し、AWS FIS で試験を行うためのサンプルアプリケーションを稼働します。次のデプロイは、検証環境などで行うことを推奨します。 次のコマンドで、CDK スタックのデプロイを行います。 cdk deploy --all --require-approval never Step 2: 生成された Amazon ECS タスク定義の確認 CDK を利用して、Amazon ECS クラスター・タスク定義・2 つの m5.large EC2 インスタンス・ロードバランサーを作成しました。このタスク定義は、Web アプリケーションと SSM Agent サイドカー で構成されています。SSM Agent サイドカーは、タスク定義で「必須 (essential)」と設定されています。そのため、サイドカーを停止すると Amazon ECS はタスク全体を停止して、タスクの再作成を行います。サイドカーは、 activation script を実行して、Amazon ECS タスクを AWS Systems Manager のマネージドインスタンスとして登録します。 サイドカーは、IAM ロール (名前がFISService-SSMManagedInstanceRole から始まるもの) を利用して Amazon ECS タスクを AWS Systems Manager のマネージドインスタンスとして登録します。AWS FIS は AWS Systems Manager を利用して、Amazon ECS タスクにフォールトインジェクションを行います。この IAM ロールは AmazonSSMManagedInstanceCore ポリシー と、次の権限が付与されています。 { "Version": "2012-10-17", "Statement": [ { "Action": "ssm:DeleteActivation", "Resource": "*", "Effect": "Allow" }, { "Action": "ssm:DeregisterManagedInstance", "Resource": "arn:aws:ssm:${AWS_REGION}:${AWS_ACCOUNT}:managed-instance/*", "Effect": "Allow" } ] } Amazon ECS タスクは、次の権限が付与されている IAM ロール を利用します。 { "Version": "2012-10-17", "Statement": [ { "Action": "iam:PassRole", "Resource": "arn:aws:iam::${AWS_ACCOUNT}:role/{MANAGED_INSTANCE_ROLE_NAME}", "Effect": "Allow" }, { "Action": [ "ssm:CreateActivation", "ssm:AddTagsToResource" ], "Resource": "*", "Effect": "Allow" } ] } Step 3: AWS FIS で障害試験を行うための権限設定 AWS FIS がお客様の AWS アカウントで障害試験を行うために、IAM ロールが必要です。まず、AWS FIS が利用する IAM ロールで必要な信頼ポリシーを作成します。 cat > fis-trust-policy.json << EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "fis.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } EOF 次に、AWS FIS が利用する IAM Role を作成します。 aws iam create-role --role-name ecs-fis-role \ --assume-role-policy-document file://fis-trust-policy.json フォールトインジェクションを行うには、ECS タスクに権限の追加が必要です。権限の追加を行うためのファイルを作成します。 cat > fis-ecs-experiment-policy.json << EOF { "Version": "2012-10-17", "Statement": [ { "Action": [ "ssm:SendCommand", "ssm:ListCommands", "ssm:CancelCommand" ], "Effect": "Allow", "Resource": "*" } ] } EOF IAM ロールにフォールトインジェクションに必要な権限を追加します。 aws iam put-role-policy --role-name ecs-fis-role \ --policy-name ecs-fis-policy \ --policy-document file://fis-ecs-experiment-policy.json AWS FIS は、障害試験を安全に実行するためのコントロールとガードレールを提供します。 Amazon CloudWatch のアラームに基づいた停止条件を設定し、アラームがトリガーされた時に障害試験を停止させることができます。 実行中のタスクの数を基に、障害試験の停止条件を設定できます。サンプルサービスはデフォルトで 3 つのタスクを稼働しています。もし障害試験によってタスクに障害が発生し、タスクのレプリカ数が 3 未満になった場合、AWS FIS はそれ以上のサービス停止を防ぐために障害試験を即座に終了します。 CloudWatch アラームを作成します。 aws cloudwatch put-metric-alarm \ --alarm-name 'ECS Sample service task count alarm' \ --actions-enabled \ --metric-name 'RunningTaskCount' \ --namespace 'ECS/ContainerInsights' \ --statistic 'Average' \ --dimensions '[{"Name":"ServiceName","Value":"fis-service"},{"Name":"ClusterName","Value":"ecs-blueprint-infra"}]' \ --period 300 \ --evaluation-periods 1 \ --datapoints-to-alarm 1 \ --threshold 3 \ --comparison-operator 'LessThanThreshold' \ --treat-missing-data 'missing' \ --region $AWS_REGION Step 4: CPU に負荷を与える試験を行う CPU に負荷を与える試験は、CPU の負荷が高い状況でアプリケーションにどのようなパフォーマンス影響があるのか分析できます。例えば、アプリケーションが必要な CPU を利用できない場合、レスポンス時間の増加が発生する場合があります。CPU に負荷を与える試験は、基盤となるシステムが高負荷にさらされている場合に、ワークロードの堅牢性とお客様への影響を把握できます。負荷を与えている時に、アプリケーションの動作を観察することで、システムの改善点を発見できます。 例えば、CPU の負荷が高い状況でアプリケーションがリモートプロシージャーコールを行うと、操作が完了するまで時間がかかる場合があります。時間がかかることが問題となる場合、タイムアウト時間の調整やリトライを実装することが考えられます。また、レスポンスに時間が掛かる問題を改善するために、アプリケーションをスケールする方法も考えられます。 Amazon ECS サービスの配下で稼働している 3 つの ECS タスクに、AWS FIS のテンプレートを利用して 66 % の CPU 負荷 (2/3) をかけてみましょう。対象の Amazon ECS タスクを指定する際に、ARN・タグ・フィルター・クラスター名やサービス名といったパラメーターを利用できます。 66 % の負荷を指定する理由 : このクラスターは、2 つの Amazon EC2 インスタンス上で、3 つのタスクが稼働しています。100 % を指定すると、片方の EC2 インスタンスの負荷が高くなるため、均等に負荷を与えることを意識して 66 % と指定します。自身のクラスターで試験を行う際は、クラスターの状況に適した負荷の割合を指定してください。 AWS FIS の実験テンプレートを作成します。 cat > fis-ecs-experiment-template-cpu-stress.json << EOF { "description": "ecs-task-cpu-stress", "targets": { "Tasks-Target-1": { "resourceType": "aws:ecs:task", "parameters": { "cluster": "ecs-blueprint-infra", "service": "fis-service" }, "selectionMode": "PERCENT(66)" } }, "actions": { "ecs-task-cpu": { "actionId": "aws:ecs:task-cpu-stress", "parameters": { "duration": "PT5M" }, "targets": { "Tasks": "Tasks-Target-1" } } }, "stopConditions": [ { "source": "aws:cloudwatch:alarm", "value": "arn:aws:cloudwatch:${AWS_REGION}:${AWS_ACCOUNT}:alarm:ECS Sample service task count alarm" } ], "roleArn": "arn:aws:iam::${AWS_ACCOUNT}:role/ecs-fis-role", "tags": {} } EOF FIS_EXPERIMENT_TEMPLATE_ID=$(aws fis create-experiment-template \ --region $AWS_REGION \ --tags Name=ecs-cpu-stress \ --cli-input-json file://fis-ecs-experiment-template-cpu-stress.json \ --query 'experimentTemplate.id' \ --output text) この試験の対象は、前の手順で作成したサンプルアプリケーションに紐づくすべてのタスクです。試験を 5 分間動かします。 試験を開始します。 aws fis start-experiment \ --experiment-template-id $FIS_EXPERIMENT_TEMPLATE_ID \ --region $AWS_REGION AWS マネジメントコンソールで、 Amazon ECS の画面 を開き、ecs-blueprint-infra をクリックし、サービスタブから fis-service をクリックし、正常性とメトリクス のタブを開きます。 試験を実行してから 5 ~ 10 分ほど待つと、CPU の負荷が高くなっている事を確認できます。5 分ほど待機すると、グラフが更新されるはずです。 試験を行っている間、レスポンス時間の 95 %は、約 200 ミリ秒から、約 430 ミリ秒に増加していることがわかります。こういったレスポンス時間の増加に対応するために、CPU が不足している場合は、Amazon EC2 インスタンスをスケールアップするか、トラフィックを処理するタスク数を増やすことが考えられます。 5 分ほど待機して試験が終了するのを待つか、手動で試験を停止させたあとに、次のステップに進みます。 Step 5: AWS FIS を使って稼働中のプロセスを停止 次の試験は、AWS FIS を使ってタスクとして稼働しているプロセスを停止します。デプロイしたサンプルアプリケーションは、Flask を利用している Web アプリケーションです。この Web アプリケーションのコンテナは、タスク定義の中で「必須 (essential)」と定義されています。Python プロセスを停止すると、Amazon ECS はタスク全体を停止し、タスクを再作成します。AWS FIS を使って、Web アプリケーションのコンテナで稼働している Python プロセスを停止し、Amazon ECS が新しいタスクを再作成する様子を確認します。 AWS FIS を利用してプロセスの停止する試験を実施することで、実際の環境でプロセスが停止してしまった時のビジネス影響を評価するのに役立ちます。停止したプロセスがサービス提供において重要なコンポーネントの場合、Amazon ECS が停止したタスクの代わりに新しいタスクを再作成している間、サービス停止などの影響が発生し得ます。もし復旧までの時間が長く、ビジネスに影響がある場合は、予期しない障害を考慮してレプリカ数を増やすことが考えられます。また、正常な終了処理 (グレースフル・ターミネーション) を実装し、中断による影響を最小限に抑えることも重要です。 サンプルアプリケーションでは、3 つのタスクを実行しています。3 つタスクのうち 1 タスクを対象にして、「必須 (essential)」と定義されているプロセスを停止します。アプリケーションは 1/3 のキャパシティが減ることで、レスポンス時間の増加や、タイムアウト (ALB の 5xx エラー) などの影響が予想できます。 AWS FIS の実験テンプレートを作成します。 cat > fis-ecs-experiment-template-kill-proc.json << EOF { "description": "ecs-task-kill-process", "targets": { "Tasks-Target-1": { "resourceType": "aws:ecs:task", "parameters": { "cluster": "ecs-blueprint-infra", "service": "fis-service" }, "selectionMode": "COUNT(1)" } }, "actions": { "ecs-task-kill-proc": { "actionId": "aws:ecs:task-kill-process", "parameters": { "processName": "python" }, "targets": { "Tasks": "Tasks-Target-1" } } }, "stopConditions": [ { "source": "none" } ], "roleArn": "arn:aws:iam::${AWS_ACCOUNT}:role/ecs-fis-role", "tags": {} } EOF FIS_EXPERIMENT_ID=$(aws fis create-experiment-template \ --region $AWS_REGION \ --tags Name=ECS-kill-process \ --cli-input-json file://fis-ecs-experiment-template-kill-proc.json \ --query 'experimentTemplate.id' \ --output text) Amazon ECS の画面に戻り、fis-service という名前の ECS サービスを選択し、タスクタブに移動します。下の画像のように、フィルタ条件を「実行中のタスク」から「すべてのタスク」に変更することで、次の手順で試験を実行したときに、タスクが 1 個停止される様子が確認しやすくなります。 試験を開始しましょう。 aws fis start-experiment \ --experiment-template-id $FIS_EXPERIMENT_ID \ --region $AWS_REGION 数秒後、AWS FIS が「必須 (essential)」と設定されているコンテナ内の python プロセスを停止したため、Amazon ECS はタスク全体を停止します。Amazon ECS の画面で停止したタスクの詳細画面を開くと、以下のエラーメッセージが表示されています。 試験の影響を可視化するために、 Locust を使ってウェブアプリケーションにリクエストを投げた結果が以下の通りです。ご覧の通り、AWS FIS で「必須 (essential)」と設定されたプロセスを停止した場合、ウェブサイトへのアクセス中にエラーが発生しました。また、リクエストを処理するために十分なタスクがなかったため、95 パーセンタイルのレイテンシが増加しました。 Amazon ECS がタスクを再作成している間、ALB メトリクスで、5xx エラーが発生していることがわかります。 注意点 : aws:ecs:task-kill-process アクションは、Amazon ECS のタスク定義で、 pidMode の値を task に設定する 必要があります。Amazon ECS は、デフォルトでタスク内のコンテナをそれぞれ個別の PID namespace で実行します。pidMode を task に設定した場合、タスク内のすべてのコンテナは PID namespace を共有します。それにより、サイドカーコンテナはタスク内で実行されている他のコンテナのプロセスを参照・停止できるようになります。 作成した環境の削除 export AWS_PAGER="" # Get experiment ids # AWS FIS の実験テンプレート ID を取得 fis_expmt1=$(aws fis list-experiment-templates --query 'experimentTemplates[?description == `ecs-task-kill-process`].id' --output text) fis_expmt2=$(aws fis list-experiment-templates --query 'experimentTemplates[?description == `ecs-task-cpu-stress`].id' --output text) # Delete the alarm # CloudWatch Alarm の削除 aws cloudwatch delete-alarms --alarm-names 'ECS Sample service task count alarm' --region $AWS_REGION # Delete experiments # AWS FIS の実験を削除 aws fis delete-experiment-template --id $fis_expmt1 aws fis delete-experiment-template --id $fis_expmt2 # Delete ecs-fis IAM role # IAM Role ecs-fis の削除 aws iam delete-role-policy --role-name ecs-fis-role --policy-name ecs-fis-policy aws iam delete-role --role-name ecs-fis-role # Destroy CDK stack # CDK スタックの削除 cdk destroy --force –all 料金 AWS FIS は利用した分だけお支払い頂く従量課金です。初期費用や最低料金はかかりません。フォールトインジェクションのアクションがアクティブな期間に応じて料金が発生します。詳しくは、 AWS FIS の料金ページ をご参照ください。 aws:ecs:task-kill-process アクションは、実行期間を持たないので無料です。 初期状態では、AWS FIS で必要以上のリソースを作成してしまうことを防ぐために、アクションごとのタスク数にクォータがあります。このクォータは AWS マネージメントコンソールから、引き上げるリクエスト を申請できます。 まとめ こちらの記事では、Amazon ECS を利用しているお客様がカオスエンジニアリングを簡単に始められる AWS FIS アクションを紹介しました。Amazon ECS タスクの CPU に負荷をかける方法や、プロセスを停止する方法を紹介しました。AWS FIS は様々な障害試験を柔軟に設定でき、フォールトインジェクションを簡単に行えます。AWS FIS は、特定の条件を満たしたときに自動的に試験をロールバック、もしくは停止するといった本番環境で求められるガードレールを提供します。新しい AWS FIS のアクションは、Amazon ECS クラスターで稼働するアプリケーションが持つ、潜在的な問題を発見するために役立ちます。 Amazon ECS のアクションは、AWS GovCloud (米国) リージョンを含む、AWS FIS が利用可能なすべての AWS リージョンで利用可能です。 執筆者 Jooyoung Kim Re Alvarez-Parmar 翻訳はソリューションアーキテクトの杉山 卓が担当しました。原文は こちら です。

本記事は https://aws.amazon.com/jp/blogs/gametech/compiling-unreal-engine-5-dedicated-servers-for-aws-graviton-ec2-instances/ (2023 年 6 月 15 日公開) を翻訳した記事となります。 Epic Games (Epic) はインタラクティブエンターテイメントの大手企業であり、Unreal Engine (UE) の開発もしています。Unreal Engine は Fortnite をはじめとする世界有数のゲームを支える最もオープンで高度なリアルタイム 3D 制作ツールの 1 つであり、さまざまな業界のクリエイターによって最先端の体験を提供するために利用されています。 Epic Games と AWS は Unreal Engine 向けの AWS Graviton インスタンスのサポートを発表いたしました。この発表には Graviton2 プロセッサと比較して最大 25% 高いパフォーマンスで、最大 2 倍の浮動小数点パフォーマンス、および最先端の DDR5 メモリ テクノロジに基づくメモリアクセスを実現する最新世代の AWS Graviton3 に対する対応も含まれています。Graviton3 は同等のパフォーマンスを持つ EC2 インスタンスと比較して最大 60% エネルギーしか消費しないため、二酸化炭素排出量の削減も可能です。 一晩にしてゲームが口コミで広まって大ヒットしたとき、ビジネスが成功するかどうかは、プレイヤーの需要に応じてサーバーが柔軟に拡張できるかに懸かっています。ゲームサーバーを自分で構築したり、既存のツールと統合したり、Amazon GameLift のようなフルマネージドサービスに移行したりするような場合の全てにおいて、 AWS はクラウドベースのコンピューティングオプションを提供します。 Amazon EC2 Graviton3 Instance の発表により、お客様は専用ゲームサーバーをホストするための新しいオプションが利用可能になりました。 Unreal Engine 5 では、専用のゲームサーバーコードを ARM64 互換になるように簡単に再コンパイルすることができます。 この記事では、初めての Unreal Engine 専用ゲームサーバーを AWS Graviton3 インスタンス上で稼働させる方法を紹介します。 前提条件 専用 GPU のある Windows ワークステーション Visual Studio 2022 Visual Studio 2022 Game Development with C++ Module Installed All Visual Studio 2022 .NET Framework 4.6.x Components Installed 開発環境のセットアップ このセクションでは Unreal Engine 5 専用サーバーを AWS Graviton3 インスタンスと互換性のある LinuxArm64 環境でコンパイルする方法をステップごとにご紹介します。 1. Unreal Engine のソースコードアクセス権の取得 Unreal Engine 専用ゲームサーバーのコンパイルのためには Unreal Engine をソースコードからビルドする必要があります。Unreal Engine 5 のソースコードへアクセスするために、 こちらの手順 を完了させた後に本ガイドに戻ります。 2. Unreal Engine のソースコードをダウンロード GitHub にログインして、Unreal Engine の GitHub Repository を開き、バージョン 5.1.1 以降のバーションをダウンロードします。バージョン 4.27.2 より後の全てのバージョンで AWS Graviton 用の専用ゲームサーバーをサポートしていますが、本ガイドでは Unreal Engine 5 用の手順を紹介します。 Source code (zip) に加えて、Commit.gitdeps.xml もダウンロードしておいて下さい。 3. クロスコンパイル依存関係のインストール Unreal Engine を Linux Distributions に向けて Windows 上でバイナリをコンパイルするために、クロスコンパイルツールチェインをインストールする必要があります。Unreal Engine ドキュメントの Linux ゲームの開発 のページを開いてて、v20 toolchain をダウンロードしてインストールして下さい。 4. Unreal Engine のソースからのコンパイル 7zip をインストールして、Unreal Engine のソースコードの zip ファイルを解凍します。ここでは次のフォルダに解凍していきます C:\Users\Administrator\Documents\UnrealEngine また、解凍後のフォルダ内の Engine/Build/Commit.gitdeps.xml を先程ダウンロードした Commit.gitdeps.xml で置き換えておきます。 次に、 Windows Powershell を管理者モードを実行します。 C:\Users\Administrator\Documents\UnrealEngine\ に移動します。 Setup.bat を実行して完了するまでしばらく待ちます。 GenerateProjectFiles.bat スクリプトを実行します。 C:\Users\Administrator\Documents\UnrealEngine に UE5.sln ファイルが新たに生成されていることを確認し、Visual Studio 2022 で開きます。 Visual Studio 2022 で追加コンポーネントのインストールを推奨された場合、それらをインストールしておきます。全てのインストールが終わったあとに、Solutions Configuration を Development Editor に設定して、Platform を Win64 に設定します。 トップメニューの Build メニューを開いて、 Build Solution を実行します。 Unreal Engine のビルドには多少時間がかかるため、コーヒーを片手にしばらく休憩を取るとよいでしょう。 5. Unreal Engine の起動 C:\Users\Administrator\Documents\UnrealEngine\Engine\Binaries\Win64 をエクスプローラーで開き、 UnrealEditor.exe を起動します。 Lyra サンプルゲームの初期設定 Epic 社から、クライアントとサーバーを含む全てのアセットやコードが含まれているマルチプレイヤー用のサンプルゲームが提供されています。このプロジェクトを利用することで、今回のデモのために追加のアセットやコードの開発をしなくて済むようになります。 1.Lyra サンプルゲームを Epic Game Store からダウンロードする Epic Games は Unreal Engine 5 用の無料のデモゲームを Epic Games Store で提供しています。このプロジェクトは Lyra サンプルゲーム と呼ばれており、サンプルゲームのダウンロードのために Epic Games Launcher のダウンロードとインストールを行う必要があります。Epic Games Launcher のインストールが完了後、左側のペインから Store の中にある Unreal Engine を選択します。 Samples のペインから Lyra Starter Game を選択します。 プロジェクトを作成するボタンを押して、Unreal Engine バージョン 5.1 を選びます。 2. Visual Studio ファイルの生成とプロジェクト設定 はじめに、 Lyra 用の Visual Studio プロジェクトファイルを生成します。この作業により後ほど専用ゲームサーバーのビルドや変更が可能になります。 前述の手順で Lyra Starter Game を保存したディレクトリを開きます。次に、 LyraStarterGame.uproject を右クリックして、 Generate Visual Studio project files を選びます。 LyraStarterGame.uproject ファイルを Unreal Editor で開くことで Lyra を起動します。Lyra サンプルゲーム用の専用ゲームサーバーとクライアントをビルドする前にいくつかの設定を行う必要があります。まず、Server Default Map 設定を L_Expanse に設定します。次に、ボットのスポーン数を 0 にすることで、クライアントがサーバー接続時に即座にボットから攻撃されることを防ぎます。ボットの数を減らすことで、どのタイミングでクライアントがサーバーに接続できたり、切断されたかがわかりやすくなります。ボットの数は後ほどたくさん増やしていけます！ 3. Server Default Map の設定 メニューバー内の Edit から Project Settings を選択します。 Maps ＆ Modes を選択して、Default Maps 内の Server Default Map を L_Expanse に設定します。設定後は Project Settings の画面を閉じて構いません。 次にデフォルト設定となっているボットの数を変更します。エディタ画面の左下の Content Drawer を選択します。 プラグインディレクトリを開いて、 B_ShooterBotSpawner を検索します。そこで表示される B_ShooterBotSpawner Blueprint クラスを選びます。 チーム内の Num Bots to Create を 0 に設定し、左上の Compile ボタンを押して設定を適用します。 これで、プロジェクトの設定を正しく終えることができました。Unreal Editor を閉じて、Visual Studio で作業を続けます。 4. ビルドクライアントとサーバーの設定 ファイルエクスプローラーから LyraStarterGame.sln ファイルを選択して、今回のゲームプロジェクトとして Visual Studio で開きます。 プロジェクトのソースディレクトリに LyraServer.Target.cs ファイルがあることを確認します。見つからなかった場合には新しく作る必要があります。見つかった場合、 Development Server を Solution Configuration ツールバーから選択していきます。 メニューバーの Build 内から Build Solution を選択します。 ビルドが完了した後に、Solution Configuration ツールバーを  DevelopmentClient に変更して、先程と同じように Build Solution を実行します。 5. コンテンツのクック ゲームをプレイする前に、コンテンツのクック処理をおこないます。この処理に向けて LyraStarterGame プロジェクトを Unreal Editor で再度開きます。Platforms のドロップダウンから Windows 内の Binary Configuration が Development になっていて、Build Target が LyraServer になっていることを確認してから Cook Content を実行します。このクック処理により、サーバー用コンテンツを Windowsサーバー上で実行できるようになります。クック処理が終わると、プロジェクトの Binary ディレクトリにサーバーのバイナリが保存されます。ここでは、次のようなパスとなります。 Documents/Unreal Projects/LyraStarterGame/Binaries/Win64/LyraServer.exe クライアント用コンテンツのクックも必要となります。Build Target を LyraClient として、再度  Cook Content を選択します。 5. Windows 上でのサーバーのテスト Powershell で Lyra プロジェクトのソースディレクトリを開いて、次のコマンドを実行します。 .\Binaries\Win64\LyraServer.exe -log -port 7777 このコマンドで専用ゲームサーバーが 7777 ポートを使って起動します。2 つめのターミナルが起動されて専用ゲームサーバーのログファイルが表示されます。 元々の Powershell の画面で以下のコマンドを実行することで、ゲームインスタンスを起動しサーバーに接続します。サーバーのウィンドウを閉じたり、サーバープロセスを止めたりしないでください。 .\Binares\Win64\LyraClient.exe 127.0.0.1:7777 -WINDOWED -ResX=800 -ResY=450 次の画面のように、ゲームを起動して遊ぶことができます。 6. AWS Graviton インスタンス向け専用ゲームサーバーのビルドとパッケージング これでゲームと専用サーバーが正常に動くことを確認できたので、AWS Graviton EC2 インスタンス向けに専用ゲームサーバーのビルドとパッケージング処理を行います。Unreal Engine エディタを開いて、Platforms のドロップダウンから LinuxArm64 を選択します。Binary Configuration が Development になっており、Build Target が LyraServer になっていることを確認したうえで、 Cook Content を実行します。 ここで、異なるホストマシンやオペレーティングシステムでサーバーを実行するために、パッケージング処理を行っています。Platforms のドロップダウンを再度選択して、LinuxArm64 内の Package Content を実行します。ポップアップされたファイルエクスプローラーの画面で Binaries ディレクトリを選択します。この処理により、プロジェクトの Binaries フォルダ内に LinuxArm64Server が作られます。 サーバーのバイナリを AWS Graviton EC2 インスタンスにコピーするために、フォルダ全体を zip ファイルに圧縮します。 専用ゲームサーバーの設定 1. AWS Graviton EC2 インスタンスの起動 専用ゲームサーバーのために今回は c7g.xlarge EC2 インスタンス で Amazon Linux 2023 を起動します。ここでは任意の AWS Graviton インスタンスを選ぶことができますが、今回はデモのために c7g.xlarge を選んでいます。 Amazon EC2 Console を開いて、開発用のインスタンスを起動します。Graviton2 インスタンスを起動するためには AMI が ARM と互換性があるものを指定します。 Linux ベースの EC2 インスタンスの起動に困った場合は、 Linux 用 EC2 ユーザーガイド を参考にすることができます。インスタンス起動時に、 セキュリティグループの設定 を確認して手元の Windows 開発環境から専用ゲームサーバーに対して UDP 7777 番と TCP 22 番のポートが疎通していることを確認して下さい。7777 番ポートはゲーム用の通信で利用し、22 番ポートは SSH のために使われます。 インスタンスが起動した後に、手元の Windows 開発環境の ZIP ファイルを AWS Graviton c7g.xlarge インスタンスにお好きな方法でコピーします。 2. 専用ゲームサーバーの起動スクリプトの実行 ZIP 化された専用ゲームサーバーのバイナリを Graviton EC2 インスタンスにコピーしたあと、幾つかのステップを踏んでセットアップを続行します。まず、 インスタンスに接続 して ZIP ファイルを解凍します。ファイルを保存したディレクトリに移動して、 unzip ./LinuxAArch64Server.zip  のコマンドを実行します。 ZIP ファイルが解凍されると新しいディレクトリが利用可能になります。 新しく作られたディレクトリに cd LinuxArm64Server/  のコマンドで移動すると、次のようなディレクトリ構成になっています。 専用ゲームサーバーを実行するために、実行権限を LyraServer-Arm64.sh という起動用シェルスクリプトに付与します。次のコマンドを実行して下さい。 chmod +x LyraServer-Arm64.sh これで、 ./LyraServer-Arm64.sh というシェルスクリプトを実行するとゲームプロセスを開始できるようになりました。プロセスの開始後は次のような画面が表示されます。 3. AWS Graviton インスタンスで実行される専用ゲームサーバーへの接続 これでゲームサーバーが起動して、新しいコネクションを受け付けられるようになりました。ゲームを遊ぶために、手元にある Windows 開発環境からサーバーに接続してみます。以前のローカルサーバーへの接続と似た形でゲームに接続していきますが、IP アドレスの部分をあなたが起動した AWS Graviton サーバーのものに変更する必要があります。 .\Binares\Win64\LyraClient.exe 10.2.23.25:7777 ゲームが即座に開始しなかった場合、専用ゲームサーバーのプロセスがスリープ状態になっている可能性があります。その場合はサーバーのプロセスを再起動することで簡単につなぎ直すことが可能です。ゲームがサーバーと通信できるようになると、次のような画面が表示されます。 まとめ こうしてサンプルゲームを起動して動かすことができました。遊び終わったあとはリソースを削除しておきます。このチュートリアルで作成した全てのリソースを削除されているかを確認し、不要なリソースへの課金を防いでおきましょう。 Project Lyra のサンプルゲームを Windows と AWS Graviton インスタンスの両方でビルドし、コンパイルを行いました。専用ゲームサーバーを AWS Graviton インスタンス で起動することで、現行世代の x86 ベースのサーバーと比較して最大 40% のコストパフォーマンスを享受できます。このチュートリアルで AWS Graviton 互換のゲームサーバーをコンパイルする方法を学んだので、ぜひあなたの作ったゲームも AWS Graviton インスタンスで動かしてみましょう！

イントロダクション 今日のモダンなクラウド時代では、アプリケーションは、一日に何回も自動的にビルドされ、テストされ、デプロイされます。このソフトウェア開発のサイクルにおける一般的なシナリオは、機能やバグフィックスやその他アップデートをエンドユーザに対して素早く提供します。継続的なデプロイメントの重要な側面の一つに セマンティックバージョニング があります。これは、ソフトウェアのリリースにバージョンナンバーを割り当てる仕組みです。セマンティックバージョニングでは、リリースにおける変更度合いを伝える標準的なフォーマットを利用します。それにより、開発者やユーザはアップデートの潜在的なインパクトを理解することができます。セマンティックバージョニングなしでは、次のバージョンへの移行を妨げる破壊的変更を追跡するのは困難です。 このブログでは、 AWS App Runner が提供する継続的インテグレーション (CI) / 継続的デプロイメント (CD) 機能とセマンティックバージョニングを組み合わせて使用し、新しいバージョンのアプリケーションを自動的にデプロイする方法を説明します。 セマンティックバージョニング セマンティックバージョニングは、ソフトウェアリリースにバージョン番号を付与する方法です。これは、変更度合いを表す指標であり、開発者やユーザはアップデートの潜在的なインパクトを理解することができます。セマンティックバージョンナンバーの基本的なフォーマットは、MAJOR.MiNOR.PATCHで、それぞれの数字は正の整数です。 ここでは、セマンティックバージョニングの一般的なルールを記載します。 当該リリースが後方互換を含まない場合 (API コンストラクトの破棄など)、MAJOR バージョンをインクリメントします。 当該リリースが後方互換を含む場合、MINOR バージョンをインクリメントします。 当該リリースがバグフィックスのみ含まれる場合、PATCH バージョンをインクリメントします。 セマンティックバージョニングを用いることで、開発者はユーザにリリースのインパクトを伝えることができます。ユーザは新しいバージョンを利用する際のリスクやメリットを容易に理解することができます。 問題提起 AWS App Runner は、ソースコードリポジトリからコンテナ化されたアプリケーションを迅速かつ簡単にデプロイできるフルマネージドなコンテナサービスです。AWS App Runner は、コンテナ化されたアプリケーションの構築、実行、スケーリングするための完全に制御された環境を提供します。また、新しいバージョンのアプリケーションを自動的に構築、デプロイするためのフルマネージドな CI/CD パイプラインも提供します。AWS App Runnerを活用することで、Amazon Elastic Container Registry ( Amazon ECR ) リポジトリにプッシュされる特定のタグ ( 例：LATEST ) が付いたイメージを継続的に監視し、AWS App Runner にアプリケーションを自動的にデプロイできます。 しかしこのアプローチでは、新しいバージョンのアプリケーションの監視やデプロイが、セマンティックバージョニングに基づいてできません。顧客が、>= MAJOR1.MINOR2.PATCH3 のようなパターンに基づいて、新しいバージョンのアプリケーションを AWS App Runner に対して自動的にデプロイしたい場合、既存のAWS App Runner の機能では難しいです。 ソリューションの概要 このソリューションでは、以下の AWS サービスを利用します。 AWS App Runner – ソースコードリポジトリからコンテナ化されたアプリケーションを素早くデプロイすることが容易な、フルマネージドなコンテナアプリケーションサービス AWS Lambda – サーバを構築/運用することなくコードを実行することが可能なサーバレスコンピュートサービス Amazon Elastic Container Registry (Amazon ECR) – 開発者が容易に Docker コンテナイメージを保存、管理、デプロイできるフルマネージドな Docker コンテナレジストリ Amazon EventBridge – 自社のアプリケーションや Software-as-a-Service (SaaS) アプリケーション、AWSサービスのデータをアプリケーション間で容易にやり取りするフルマネージドなイベントバス Amazon Simple Storage Service (Amazon S3) – 業界をリードするスケーラビリティやデータの可用性、セキュリティ、パフォーマンスを提供するフルマネージドなオブジェクトストレージサービス Amazon Simple Queue Service ( Amazon SQS ) – マイクロサービスや分散システム、サーバレスアプリケーションのためのフルマネージドなメッセージキュー 以下の図に、ソリューションの全体像を示します。 このソリューションは、Amazon ECR の PUSH イベントをキャッチするために EventBridge ルールを用います。図に示す通り、PUSH イベントをキャッチすると、Amazon SQS キューを経由して AWS Lambda 関数によって処理されます。AWS Lambda 関数は AWS App Runner (Application Programming interface) の API を利用して、現在デプロイされているアプリケーションのイメージタグを取得し、Amazon ECR リポジトリにプッシュされたイメージのタグと比較します。これらがマッチした場合、AWS Lambda 関数は 新しいバージョンのアプリケーションをデプロイするために、AWS App Runner サービスをアップデートします。ユーザは、Amazon S3 バケット内にJSONファイル(以下、サンプル)の形式で格納することで、AWS Lambda 関数のインプットパラメータとしてマッチパターンを提供できます。 [ { "repository": "hello-World-AppRunner-Repo", "semVersion": ">1.2.3", "serviceArn": "arn:aws:apprunner:us-east-1:123456789123:service/Hello-World-Service/2d0032a93cbb4cbdaef0966607052336" } ] 当該ソリューションは、Node Package Manager(NPM) 形式のバージョニングチェックをサポートします。以下に、サポートするマッチパターンの例を記載します。 >1.2.3 – 1.2.3 以上の どのバージョンにもマッチ 1.1 || 1.2.3 – 2.0.0 – バージョン1.1.1 または 1.2.3 から2.0.0の どのバージョンにもマッチ 1.* – 1.1以上の どのバージョンにもマッチ ~1.2.1 – 1.2.1 以上 1.3.0 未満の どのバージョンにもマッチ ^1.2.1 – 1.2.1 以上 2.0.0未満 の どのバージョンにもマッチ 以下の環境変数を AWS Lambda 関数に設定する必要があります。 QUEUE_NAME – Amazon ECR の PUSH イベントを受け取り、AWS Lambda 関数をトリガーする Amazon SQS キュー名 CONFIG_BUCKET – マッチパターンが記載された JSON ファイルを含む Amazon S3 bucket 名 CONFIG_FILE – マッチパターンを含む JSON ファイル名 ( config フォルダの下にサンプルが提供されています ) 以下のシーケンス図は、新しいバージョンのアプリケーションが Amazon ECR リポジトリにプッシュされた際に、ソリューションで利用するコンポーネント同士のやり取りを示しています。 当該ソリューションは、リトライロジックが備わっています。同一のAmazon ECR リポジトリへ複数回 PUSH イベントがされた場合、ターゲットの AWS App Runner サービスがアップデート進行中であれば、AWS Lambda 関数は待機します。AWS Lambda 関数は、10分間に最大3回リトライします。 前提条件 当該ソリューションを導入するために、以下の前提条件を満たす必要があります。 AWS Command Line Interface (AWS CLI) AWS CDK Git jq Docker ウォークスルー Amazon ECR リポジトリと AWS App Runner サービスのセットアップ AWS App Runner のドキュメントのサンプルアプリケーションを使って、ソリューションのデモンストレーションをしましょう。 環境変数にAWS アカウント番号をセットします。 AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text) AWS_REGION=us-east-1 # Change this to region of your choice もし、リージョンが設定されていない場合、 aws configure を用いて設定してください。 GitHub からサンプルアプリケーションをチェックアウトしてください。 git clone https://github.com/aws-containers/hello-app-runner.git cd hello-app-runner 新しい Amazon ECR リポジトリを作成します。 aws ecr create-repository --repository-name hello-world-apprunner-repo リポジトリを作成すると、下記のようなテキストが出力されます。 { "repository": { "repositoryArn": "arn:aws:ecr:us-east-1:<<account>>:repository/hello-world-apprunner-repo", "registryId": "<<account>>", "repositoryName": "hello-world-apprunner-repo", "repositoryUri": "<<account>>.dkr.ecr.us-east-1.amazonaws.com/hello-world-apprunner-repo", "createdAt": "2023-01-02T15:20:14-08:00", "imageTagMutability": "MUTABLE", "imageScanningConfiguration": { "scanOnPush": false }, "encryptionConfiguration": { "encryptionType": "AES256" } } } Amazon ECR リポジトリにログインします。 aws ecr get-login-password --region $AWS_REGION | \ docker login --username AWS --password-stdin \ $AWS_ACCOUNT_ID.dkr.ecr.${AWS_REGION}.amazonaws.com コンテナイメージをビルドし、Amazon ECR リポジトリにプッシュします。 docker build --platform linux/amd64 -t hello-world-apprunner-repo . docker tag hello-world-apprunner-repo:latest ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/hello-world-apprunner-repo:1.2.3 docker push ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/hello-world-apprunner-repo:1.2.3 注： ハードウェアやネットワーク構成によっては、Docker build が完了まで数分かかる可能性があります。 AWS App Runner へのアクセスロールを作成し、Amazon ECR アクセスポリシーをロールにアタッチします。 export TP_FILE=$(mktemp) export ROLE_NAME=AppRunnerSemVarAccessRole cat <<EOF | tee $TP_FILE { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "build.apprunner.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } EOF aws iam create-role --role-name $ROLE_NAME --assume-role-policy-document file://$TP_FILE rm $TP_FILE aws iam attach-role-policy --role-name $ROLE_NAME --policy-arn arn:aws:iam::aws:policy/service-role/AWSAppRunnerServicePolicyForECRAccess 先ほどの手順で作成した Amazon ECR リポジトリを使用して、新しい AWS App Runner サービスを作成します。 AWS App Runner サービスの構成ファイルを作成します。 cat > input.json << EOF { "ServiceName": "hello-world-service", "SourceConfiguration": { "AuthenticationConfiguration": { "AccessRoleArn": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ROLE_NAME}" }, "ImageRepository": { "ImageIdentifier": "${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/hello-world-apprunner-repo:1.2.3", "ImageConfiguration": { "Port": "8000" }, "ImageRepositoryType": "ECR" } }, "InstanceConfiguration": { "Cpu": "1 vCPU", "Memory": "3 GB" } } EOF SERVICE_ARN=$(aws apprunner create-service --cli-input-json file://input.json \ --output text \ --query 'Service.ServiceArn') SERVICE_ID=$(aws apprunner describe-service --service-arn ${SERVICE_ARN} | jq -r '.Service.ServiceId') SERVICE_URL=$(aws apprunner describe-service --service-arn ${SERVICE_ARN} | jq -r '.Service.ServiceUrl') echo $SERVICE_URL ## Run describe service command to check the status aws apprunner describe-service --service-arn \ arn:aws:apprunner:${AWS_REGION}:${AWS_ACCOUNT_ID}:service/hello-world-service/${SERVICE_ID} | jq -r '.Service.Status' AWS App Runner サービスが作成された後、$SERVICE_URL にブラウザでアクセスしてください。サンプルアプリケーションが表示されます。以下は、そのスクリーンショットです。 ソリューションのデプロイ GitHub からソリューションをチェックアウトします。 git clone https://github.com/aws-samples/containers-blog-maelstrom.git cd containers-blog-maelstrom/sem-var-ecr-watcher-app-runner config/ ディレクトリに ServiceArn を含む 以下のような config ファイルを作成します。 cat > config/config.json<< EOF [ { "repository": "hello-world-apprunner-repo", "semVersion": ">1.2.2", "serviceArn": "arn:aws:apprunner:${AWS_REGION}:${AWS_ACCOUNT_ID}:service/hello-world-service/${SERVICE_ID}" } ] EOF もし 初めて AWS CDK を実行する場合は、AWS CDK 環境を ブートストラップ します (AWS アカウント ID と AWS リージョンを指定します)。 npm i cdk bootstrap \ --template bootstrap-template.yaml \ aws://${AWS_ACCOUNT_ID}/${AWS_REGION} 注：ブートストラップは、1 回だけ必要です ( 既に実施している場合、このステップをスキップしてください )。 コードをデプロイするために、以下のコマンドを実行してください。 npm i cdk deploy --requires-approval テスト ソリューションのテストをするために、新しいバージョンのアプリケーションを Amazon ECR へプッシュしてください。最新のバージョンは、Amazon S3 バケット内の config.json ファイルで指定した、セマンティックバージョニングパターン (>1.2.3) に一致する必要があります。 templates\index.html を開き、“And we’re live!“ の行を ”And we’re live, one more time! v1.2.4” と書き換え、hello world アプリケーションをアップデートします。 docker イメージをビルドし、 Amazon ECR リポジトリにプッシュします。 cd .. VERSION=1.2.4 docker build --platform linux/amd64 -t hello-world-apprunner-repo . docker tag hello-world-apprunner-repo:latest ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/hello-world-apprunner-repo:${VERSION} docker push ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/hello-world-apprunner-repo:${VERSION} 上記のアクションにより Amazon ECR のイベントがトリガーされ、AWS Lambda 関数が当該イベントをキャッチします。そして AWS Lambda 関数は、数秒以内に AWS App Runner サービスを新しいコンテナイメージでアップデートします。下記のコマンドで動作を確認することができます。 aws apprunner describe-service --service-arn \ arn:aws:apprunner:${AWS_REGION}:${AWS_ACCOUNT_ID}:service/hello-world-service/${SERVICE_ID} | jq -r '.Service.Status' 出力 OPERATION_IN_PROGRESS AWS App Runner サービスのイベントログを見ると、ソリューションによってアップデートがトリガーされていることが確認できます。 12-30-2022 01:55:48 PM [CI/CD] Semantic version >1.2.2 matched with the recent ECR push 1.2.4, so updating the service to the deploy from the latest version アップデートが成功したら、AWS App Runner サービスへ適用された変更を含む以下のアウトプットが表示されます。 メリット 以下に、当該ソリューションを利用した際のメリットの一部を記載します。 セマンティックバージョニングは、リリースの影響をユーザに伝えます。そのため、ユーザは新しいバージョンへアップデートする際のリスクとメリットを容易に理解することができます。 AWS App Runner は、セマンティックバージョニングに基づき、新しいバージョンのアプリケーションを自動的にデプロイします。 アプリケーションのそれぞれのバージョンに (build ID, git commit hashに基づいた) ユニークなタグを利用できます。それゆえ、アプリケーションのバージョンの追跡や管理が簡単になります。 このアプローチにより、ソフトウェアのバージョン管理とリリースのベストプラクティスに従うことができます。さらに、インフラを心配することなくエンドユーザへソフトウェアの変更をロールアウトするために、AWS App Runner を活用することができます。 概説した当該ソリューションは、スケーラブルであり、複数のアプリケーションをデプロイ可能です。 考慮事項 このソリューションを利用する上で考慮すべき必須項目をいくつか以下に記載します。 当該ソリューションは、新しいバージョンのアプリケーションをデプロイする際に AWS App Runner APIs を call します。つまり、ソリューション自体はフルマネージドではありません。AWS CDK スタックや AWS Lambda 関数を管理する必要があります。 当該ソリューションは、latest タグの追跡をサポートしません。latest タグや任意のタグを利用したい場合、AWS App Runner ネイティブの CI/CD 機能を使用することをお勧めします。 当該ソリューションは、セマンティックバージョンパターンを追跡するために、さまざまな AWS サービス (Amazon Eventbridge, Amazon SQS, and AWS Lambda 等) を利用します。そのため、複数のAWS App Runner サービスや Amazon ECR リポジトリを追跡すると複数のイベント、 Amazon SQSのメッセージング、関数呼び出しが発生するため、コストが高くなる可能性があります。 当該ソリューションは、現状のまま提供され、プロダクションレディではありません。利用する前に、検証環境でソリューションをテストしてください。 当該ソリューションは、同一リポジトリを用いた複数の AWS App Runner サービスの追跡をサポートしていません。もし、複数の AWS App Runner で同一リポジトリを利用したい場合は、ソリューション コードを更新する必要があります。 クリーンアップ AWS内に作成したインフラを削除するまでコストがかかり続けます。以下のコマンドを用いて、リソースを削除しましょう。 cdk destroy aws ecr delete-repository --repository-name hello-world-apprunner-repo --force aws iam detach-role-policy --role-name ${ROLE_NAME} --policy-arn arn:aws:iam::aws:policy/service-role/AWSAppRunnerServicePolicyForECRAccess aws iam delete-role --role-name ${ROLE_NAME} aws apprunner delete-service --service-arn ${SERVICE_ARN} rm -rf ../../../hello-app-runner さいごに このブログでは、セマンティックバージョニングに基づいてリリースパイプラインを強化する方法 及び 新しいバージョンのアプリケーションを完全に自動化してエンドユーザに配信する方法について記載しました。AWS App Runner は、 AWS Secrets Manager や AWS Systems Manager Parameter Store などの多くの AWS サービスと統合し、安全にアプリケーションをデプロイ/実行するために設定データを参照します。 AWS App Runner VPC support を利用すれば、アプリケーション周りのネットワークセキュリティを強化することもできます。そして、Amazon Virtual Private Cloud ( Amazon VPC ) 内にホストされた DB や他のアプリケーションに閉域で通信が可能になります。AWS App Runner のサービスを利用して AWS 上で適切に設計されたソリューションを構築する方法の詳細については、AWS App Runner の投稿を参照してください。 詳細は、以下を参照してください。 AWS App Runner Semantic Versioning AWS CDK Build a Continuous Delivery Pipeline for Your Container Images with Amazon ECR as Source 翻訳はソリューションアーキテクト祖父江が担当しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 先週から AWS デジタル社会実現ツアー 2023 が開始されました。「地域創生を“さらに”一歩進めるには？」をテーマに全国13都市で開催されるリアルイベントです。10月4日まで各地域で開催されるので、ご興味のある方は是非チェックしてみてください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2023年8月21日週の主要なアップデート 8/21(月) Amazon Aurora Global Database introduces Global Database Failover Amazon Aurora Global Databaseがリージョン停止等　計画外のイベントに対してのリージョン間のデータベースフェイルオーバーに対応しました。これまでも計画的なリージョン間のフェイルオーバーは実施することが可能でしたが、今回のアップデートにより計画外のイベントの場合も通常1分でセカンダリリージョンを新しいプライマリリージョンに変換することが可能となります。詳細については こちらのブログ も是非ご参考ください。 AWS Elemental MediaConvert now available in the Osaka and Melbourne regions ブロードキャストグレードの機能を備えた動画変換サービスであるAWS Elemental MediaConvertが新たに大阪リージョンととメルボルンリージョンで使えるようになりました。 AWS PrivateLink announces support for user defined IP on VPC endpoints AWS PrivateLink VPC endpointのIPアドレスを選択できるようになりました。AWS PrivateLinkはVPC・AWSサービス・およびお客様のオンプレミスネットワーク間のプライベート接続をトラフィックをインターネットに公開することなく接続するためのサービスです。これまでは作成時にランダムなIPアドレスが割り振られていましたが、この更新によりIPv4とIPv6のIPアドレスを選択することが可能になりました。 8/22(火) Amazon VPC Reachability Analyzer and Amazon VPC Network Access Analyzer are now available in an additional region ご要望頂いていた皆様お待たせいたしました。大阪リージョンでVPC Reachability AnalyzerとVPC Network Access Analyzerをご利用いただけるようになりました！ 8/23(水) AWS Certificate Manager introduces Enterprise Controls to help govern certificate issuance AWS Certificate Manager(ACM)でAWS IAMの条件コンテキストキーを使用できるようになりました。このアップデートによりユーザが組織の公開鍵基盤のガイドラインに準拠した証明書を発行していることを確認できます。例えば、特定の証明書の検証のみを許可することや、サブドメインやワイルドカード名などの特定ドメイン名の証明書をリクエストできるユーザを認証することができます。その他詳細については こちらのドキュメント をご参照ください。この機能は、ACM が利用可能なすべての AWS リージョンで利用できます。 Announcing AWS Dedicated Local Zones AWS Dedicated Local Zonesが発表されました。データレジデンシー等の規制要件を満たすのを目的としてお客様が指定した場所もしくはデータセンターに専用のインフラストラクチャを配置するサービスで、Amazon EC2, Amazon VPC, Amazon EBS, ELB, Amazon ECS, Amazon EKS, AWS Direct Connect等が利用可能です。想定する利用目的、AWS Outpostsとの違い等は　 FAQs もご参考にしてください！ 8/24(木) Amazon RDS for PostgreSQL supports minor versions 15.4, 14.9, 13.12, 12.16, and 11.21 Amazon RDS for PostgreSQLがPostgreSQL 15.4、14.9、13.12、12.16、11.21 のマイナーバージョンをサポートするようになりました。これらのバージョンでは既知のセキュリティ脆弱性の修正、およびバグ修正、パフォーマンスの向上に加え、地理的インデックスシステムの新しい拡張機能 h3-pg などの新機能もサポートされています。 Amazon SageMaker announces preview of GPU/CPU profiler tooling for deep learning model development Amazon SageMaker Profilerのプレビュー公開がアナウンスされました。ディープラーニングのモデル開発のためのオブザーバビリティツールであるAmazon SageMaker ProfilerはGPUとCPU の使用率メトリクス、高解像度の GPU/CPU トレースプロット、カスタムアノテーション 他を可視化しボトルネックの特定やオーバーヘッドの削減などの最適化を支援するツールです。プレビュー期間中、オハイオ、バージニア北部、オレゴン、フランクフルト、アイルランドリージョンにて無料で利用可能です。 8/25(金) Amazon Connect launches granular access controls for the agent activity audit report Amazon Connectのエージェントアクティビティ監査レポートのきめ細かい権限管理ができるようになりました。これにより特定のエージェントの過去のステータス等を付与したタグベースで制御可能になります。この機能は東京を含む９つのリージョンで利用可能です。 Amazon QuickSight adds scheduled and programmatic export to Excel format Amazon QuickSightでダッシュボードの任意のシートから複数のテーブルやピボットテーブルをExcel形式でスケジュール生成することができるようになりました。同時にプログラム経由の実行で使うSnapshot Export APIもPDF, CSVに加えてExcel形式をサポートしました。この機能を使うにはAmazon QuickSight Enterprise エディションとページ分割レポートのサブスクリプションが必要です。 皆さん AWS Workshops をご存知でしょうか？ AWSの様々なサービスのワークショップをこちらから利用可能です。日本語対応しているものは こちら にもまとまっていますので是非ご活用ください。最近日本語化されたものだと Redshift Immersion Labs などがございます。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 (twitter – @rr250r_smr )

2021年には、全国の16,000以上のコースで 2,500万人 以上がゴルフラウンドをプレーしました。これらの各ラウンドにおいて、ゴルフカートはプレイヤー体験において引き続き大きな役割を果たしています。ヤーデージやコースGPS、レザーバックシート、そして最も重要なゴルフクラブを運ぶための十分な収納スペースまで、ゴルフカートはプレイヤー体験の重要な要素です。一方で、ゴルフカート市場は、プレイヤー体験をはるかに超えて、 15億ドル規模の業界 を誇り、急成長を続けています。 お客様について : 全国のゴルファーにデジタル体験を提供 市場最大手のクラブカーにとって、パーソナライゼーションと臨場感あふれるメディア体験は、次の未開拓のイノベーション領域です。 快適なゴルフカートから、最新のサッカーの試合を聴いたり、ニュースやスポーツのハイライトを見たり、アプローチに使用するクラブを情報に基づいて決定したり、ホール間の昼食を注文したりできるとしたらどうでしょうか。 1958年に設立された Club Car は、個人用、ビジネス用、商業用のさまざまな用途に対応するゴルフカートとユーティリティビークル (スポーツ用多目的車両) の大手メーカーです。Club Car は、パーソナライズされたメディアやエンターテイメント機器を各車両に組み込むため、デンバーに本拠を置くデジタル屋外広告（DOOH）を専門とするインタラクティブ・ソフトウェア企業、Edison Interactive の支援を受けました。 現在、Edison Interactive のソフトウェアは、 Verizon が提供する Shark Experience を通じて、450のコースロケーションにある41,000台のゴルフカートで利用されています。各車両には、タッチスクリーンディスプレイ、内蔵スピーカー、Bluetooth接続、Yahoo Finance、スポーツ中継などのプレミアムエンターテイメント機能が搭載されています。 課題：統一された没入型体験を大規模に実現 ヤーデージ、ニュース、広告のデータをすべて配信するために、関連するゴルフコースデータをすべて 1 つのクラウドリージョンに集約しました。これにより、Edison チームは管理と運用を簡単化できましたが、地理的に分散されたコンピューティングとデータノードがないため、場所によっては非常に遅延が大きく、ユーザーエクスペリエンスが低下していました。そこで、Edison Interactive は、タッチスクリーンの応答時間を短縮して全体的にシームレスなゴルフ体験を実現できる、最も信頼性の高い接続ソリューションとクラウドソリューションを探し始めました。 さらに、Edison は、今後数か月でさらに数千台のゴルフカートへの搭載を見込んでいたため、コストを指数関数的に増加させずにキャパシティの増大に対応するための決定論的アプローチが必要でした。 また、Edison Interactive のゴルフカートの画面数が急速に拡大するにつれて、エンドユーザーにより効率的にコンテンツを提供するための費用対効果の高い方法も必要になりました。 3.5万 83億 1,643テラバイト 25.3万 Edison Interactive フリート内のゴルフカートの合計 月間リクエスト数合計 LTE 経由のスループット月間リクエストの合計 ゴルフカート 1 台あたりの月間累積リクエスト数 このワークフローを大規模に対応させるため、Edison Interactive は HarperDB クラウドを選択しました。 AWS Wavelength 上に構築される HarperDB の Database-as-a-Service (DaaS) プラットフォームにより、Edison Interactive は 19 の Wavelength Zone すべてを活用して大規模にエンドユーザーに対してデータノードを近接配置し、パフォーマンスを10倍以上向上させました。 「モバイルエッジコンピューティングにより、AI 主導の分析をユーザーに提供して、ユーザーのゴルフの試合を支援できるようになりました。データのリアルタイム転送により、最終的にはグリーングラスゴルフコースのデジタルキャディー向けの機能セットを提供できるようになります。」— Edison Interactive の CRO 兼共同創設者、ニック・スタニッツ・ハーパー アーキテクチャの概要 可用性が高く、レイテンシーの低いソリューションを提供するために、Edison はマルチリージョンアプローチを採用し、カスタム API キャッシュレイヤーを活用して全19の Wavelength Zone をローンチしました。各 Wavelength Zone では、HarperDB の カスタム関数 開発プラットフォームを使用して、レイテンシーを 5 秒以上から 20 ミリ秒以下に短縮する API キャッシュレイヤーを作成しました。各ゴルフカートのレイテンシーを最小限に抑えるため、エッジディスカバリーサービスを活用して、各 Wavelength Zone で最も近い AWS キャリア IP アドレスを特定します。 カスタム関数は HarperDB データレイヤーに直接アクセスできるユーザー定義の API エンドポイントです。これにより、スタンドアロン API からデータベースへの余分なホップが不要になります。その結果、レイテンシーを低減し、複雑さを軽減し、費用対効果の高い水平スケールにも柔軟に対応したアプリケーションとデータの完全なパッケージが完成します。従来モデルでは、モノリシックなデータストアの垂直スケーリングには指数関数的にコスト増加となる点が課題でしたが、この新しい仕組みによって Edison はプラットフォームに対してコースやカートを効率的に追加できるようになりました。 プロビジョニングと監視 19 の Wavelength Zone すべてに HarperDB ノードを効率的にプロビジョニングするために、 AWS Lambda と AWS CloudFormation を利用して Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、 Amazon Elastic Block Store (Amazon EBS) ボリューム、および Amazon Route53 DNS レコードを作成します。CloudFormation は、各 Wavelength Zone の作成の一貫性を担保しながらデプロイを加速させるために不可欠でした。さらにWavelength Zone の数は今後も増加することが見込まれるため、CloudFormation によって一貫性のあるスケーリングテンプレートを提供します。 ノードが構築されると、 Amazon CloudWatch は各ノードのオブザーバビリティとモニタリングを行い、システムの整合性を確認します。リソース使用率が高いなどの特定のシナリオでは、Amazon CloudWatch は HarperDB と Edison Interactive のカスタマーサポートチームにカスタム通知を送信する AWS Lambda 関数をトリガーします。AWS Lambda を使用してカスタムアラートを柔軟に作成できることは、HarperDB チームが Edison Interactive と共同でデプロイを管理するうえで非常に重要でした。 結論 クラブカーの全国各地の車両に低遅延の外出体験を提供するには、AWS Wavelength と HarperDB が必要です。AWS Wavelength を利用するゴルフカートは、低遅延のマルチリージョン接続の最先端にあります。AWS Wavelength はネットワーク遅延を低減しつつ、HarperDB はデータとアプリケーションの両方の配信を管理します。AWS Wavelength と HarperDB の併用は、家庭外（OOH）でのデジタル体験の可能性を再定義した洗練されたソリューションです。 高品質で臨場感あふれるスポーツ体験について詳しくは、こちらをご覧ください。 Verizon が提供する Shark Experience メディアとエンターテイメント向けの 5G と AWS Wavelength を探る HarperDB を使い始めましょう TAGS: telecom , Telecommunications , Wavelength Robert Belson Robert は、AWS エッジコンピューティングを専門とする AWS ワールドワイドテレコムビジネスユニットのデベロッパーアドボケイトです。開発者コミュニティや大企業のお客様と協力して、自動化、ハイブリッドネットワーキング、エッジクラウドを使用してビジネス上の課題を解決することに重点を置いています。 Stephen Goldberg HarperDB の CEO 兼共同創設者である Stephen Goldberg は、スタートアップ企業の CTO 兼 CEO として働き、Red Hat などの大規模組織で複数の役職を歴任し、さまざまな業種の多くのフォーチュン500企業でデジタル変革プロジェクトを主導してきました。データ管理とエッジコンピューティングの分野で定評のあるオピニオンリーダーであり、Tech Target などのサイトに掲載されたり、Forbes や ZDNet などの多くの記事や出版物で引用されたりしています。IoT World、SAP Sapphire、Salesforce.com の Dreamforce などで講演を行ってきました。Stephen は共同創設者の Kyle と Zach と共に 2 件の特許を保有しています。 原文は こちら です。 翻訳はソリューションアーキテクトの鈴木 浩之が担当しました。

DoGet App は、友人と直接会って時間を共有するためのモバイルアプリケーションです。 この投稿では、DoGet Appが彼らのユースケースに対応し、リアルタイムのアクティビティ提案とマッチメイキングを可能にする Amazon Neptune に支えられたグラフデータモデルをどのように採用したかについて紹介します。 この目的のために構築されたデータベースに対するアプローチにより、彼らのサーバーレスアーキテクチャは、AWS AppSync、AWS Amplify、AWS Lambda、 Amazon Simple Storage Service (Amazon S3)を使用し、ローンチ時のスケールと1日あたり数千の新規ユーザーをサービス利用可能にすることを可能にしました。AWSのマネージドサービス上に構築することで、DoGet Appは開発開始からローンチまでわずか6ヶ月と、市場投入までの時間を大幅に短縮することができ、同時にローンチ前の開発工数とローンチ後の運用オーバーヘッドを統合することができました。 上へスワイプすると、そのアクティビティに興味がないことを示し、下へスワイプすると、興味があることを示し、ユーザーがいつ参加できるか（明日や今週など）のフォローアップを促します。そして、DoGet Appは、同じ時間に同じ体験を共有することに興味がある友人をマッチングします。 アプリケーションの設計と立ち上げ時の課題 DoGet Appは、アプリケーションを設計する際にいくつかの課題に直面しました。 まず第一に、多くのマッチメイキング・アプリケーションは、リアルタイム性を考慮することなく、データの読み込み時間を短縮するために事前に提案を生成します。一方、DoGet Appは、過去の習慣や好みだけでなく、他にも多くの提案を生成します。コンテンツの要素は、ユーザーの現在地、天候、友人からの反応を取り入れるため、リアルタイムで提案を生成する必要がありました。 この課題に取り組むため、DoGet Appは自社のアルゴリズムに合わせたグラフデータモデルを持つAmazon Neptuneを使用しました。Amazon Neptuneのグラフデータベースには、ユーザーのすべての人間関係、興味、交流の全体的な状態が一貫してリアルタイム性の高い状態で表現することができ、それに基づいて提案やマッチングがリアルタイムで作成されます。 DoGet Appは、ユースケースに適したデータモデルを選択することに加え、ゼロからユーザーベースのアプリケーションを構築する必要があったため、予測不可能な負荷やトラフィックの増加に対応できるスケーラブルなソリューションが必要でした。また、ユーザーを増やしながら得られた新たな洞察に基づいて、グラフデータモデルと対応するアルゴリズムを迅速に反復構築できる運用モデルも必要でした。 ソリューションの概要 このセクションでは、アプリケーション・アーキテクチャのハイレベルな概要を説明します。 次の図は、アプリケーションのフロントエンドとバックエンド、およびデータ分析機能を含むアーキテクチャ図です。 モバイルアプリケーションのフロントエンドは、 AWS Amplify クライアントライブラリを使用して、AWSクラウドのバックエンドリソースに接続します。典型的なリクエストの流れは以下のようになります。 モバイルクライアントは、静的なフロントエンドアセットを Amazon S3 から取得します Amazon Cognito への認証後、 AWS AppSync が提供するバックエンドAPIにアクセスできるようになります リクエストはその後、 AWS Lambda 関数によって処理されます Amazon DynamoDB と Amazon Neptune から情報を照会し、APIリクエストに対するレスポンスを生成します これらのリクエストに対応する過程で、分析データはAmazon S3のデータレイクに保存されます そこから Amazon Athena で分析を行います グラフデータモデル DoGet Appの機能の中核は、フルマネージド・グラフデータベース・サービスであるAmazon Neptuneに支えられた専用グラフデータベースです。Neptuneを利用することで、DoGet Appは、メンテナンス、バックアップ、スケーリングなどの運用タスクをオフロードすることで、アプリケーションに関連する実際のデータモデルとアルゴリズム設計に集中することができます。 DoGet Appのユースケースにどのようなメリットがあるかを理解するために、グラフデータモデルを深く掘り下げてみましょう。基本的に、グラフのノードはアプリケーションのエンティティを表し、エッジはそれらの間の関係を表します。次の図は、アプリのデータモデルにおける一般的なエンティティを示しています。 この例では、ユーザー Lisa 、 Sophie 、 Benny を表す3つの人物ノードを示しています。人物ノード間のエッジは、それらの友好関係を表します。そして、3つのトピック・クラスタ・ノード（ Outdoor 、 Nature Lover 、 Hiking ）に関連する1つのアクティビティ・ノード（ Explore unknown paths in the surrounding by bike ）があります。 データモデルには、 ジオハッシュ の形で位置情報も組み込まれています（このアプローチでは正確な位置情報は必要ありません）。この情報は、以下の図に示すように、地域ノードによってグラフデータモデルで表現されます。 位置は、その地域に適したアクティビティや天候、また現在地や過去地 点のユーザーと関連しています。エッジの重みは、関係の強さをモデル化するために使用されます。DoGet Appはユーザーを直接つなぐことを目的としているため、位置情報は提案やマッチメイキングを生成する際に特に関連性が高く、特に天候情報を組み込むためにも使用できます。 リアルタイムで提案を生成 ユーザーがその日初めてDoGet Appを開くたびに、一連のアルゴリズムが30～50の活動提案を生成します。これらのアルゴリズムはすべて、Neptuneに保存されているリアルタイムのグラフ表現を直接または間接的に使用しています。バランスの取れた提案のために、さまざまなアルゴリズムを組み合わせて使用します。例えば、新しいアクティビティでユーザーの興味を引くことを目的とするアルゴリズムもあれば、最近友達に好かれたアクティビティを優先してマッチングの可能性を高めるアルゴリズムもあれば、グラフ内の他のエンティティに対するユーザーの最も強い関係を利用するアルゴリズムもあります。 後者に焦点を当てたアルゴリズムの例を探ってみましょう。このアルゴリズムは、ユーザーから出発して、ユーザーがグラフ内で（直接的あるいは間接的に）接続しているアクティビティへのさまざまなパスを探索します。接続の強さとそのタイプ（直接的か間接的か、たとえば友人経由かトピック・クラスタ経由か）に応じて、アルゴリズムはこれらのアクティビティに対するメトリクスを計算し、次の図に示すように、それに基づいて提案を生成します。 このアルゴリズムは、あらゆる種類のコネクションを組み込んでいますが、他のアルゴリズムでは、特定の側面、例えば、地域の活動やその地域で現在起こっているイベントの提案を提供するために、ユーザーの現在地を重視しています。 アルゴリズムに関係なく、グラフデータ構造はリアルタイムで提案を生成するDoGet Appに最適です。さらに、グラフはマッチメイキングにも適しています。ユーザーがアクティビティに興味を示すたびに、マッチング候補がグラフの近くに表示され、すでに友達が気に入っているすべてのアクティビティが含まれ、効率的にクエリできます。 新しいコンテンツを取り入れ、より深い洞察を得る グラフ内のほとんどの関係と対応するエッジの重みは、ユーザーの嗜好と過去の行動に従って時間の経過とともに確立されますが、他のものは明示的にモデル化されます。たとえば、ユーザーがアクティビティに「いいね！」を押して興味を示すと、そのアクティビティと関連するノードとの関係が強化され、接続エッジの重みが増加します。特にローンチ時には、新しいコンテンツ要素の提案を生成することは困難であることが判明しました。前のセクションで説明したように、新しいアクティビティを統合するための1つのアプローチは、アルゴリズムの組み合わせです。 DoGet Appが現在評価しているもう1つのアプローチは、 Amazon Neptune ML を使用することで、グラフ内の関係だけでなく、例えばアクティビティのテキスト記述の類似性などに基づいて提案を行うことです。 最後に、DoGet Appは、アクティビティ提案という点で、提供するコンテンツの改善を常に行っています。そのために、アプリの利用データはAmazon S3に保存され、Athenaで分析して洞察を得ることができます。しかし、グラフのエッジの重みは、嗜好や過去の利用状況を反映して動的に適用されるため、DoGet Appは、最も強いエッジを調べることで、グラフに基づいて分析クエリを実行することもできます。例えば、特定の地域で最も人気のある3つのアクティビティを見つけるには、以下のGremlinクエリを実行し、接続されたアクティビティのエッジの強さで順序付けることができます。 %% gremlin g.V('target-region') .outE().has(label,'goodFor') .order().by('strength',desc).limit(3) .inV().unfold().values('name') DoGet Appは、従来のアナリティクスと併用して、これらの洞察をサービスの改善に活用しています。 まとめ Amazon Neptuneによって、DoGet Appは独自のグラフデータベース管理システムの管理に伴う複雑さを伴うことなく、グラフデータモデルを中心にアプリケーションを構築することができました。このデータモデルと関連アルゴリズムは、DoGet Appが卓越したユーザー・エクスペリエンスを実現するのに役立ちました。グラフアルゴリズムに基づくサジェストは、約25パーセントの受け入れ率を実現しています。さらに、彼らのマッチメイキング・アルゴリズムは、アクティブな友達を持つユーザーとの毎日のマッチングを実現しています。AWSのマネージドサービスを利用することで、DoGet Appはアプリケーションデザインやコンテンツ作成といった差別化に集中することで、ビジネス価値を迅速に生み出すことができます。 この記事を読んで、あなたのユースケースに合ったグラフデータモデルを評価してみたくなりましたか？ それなら、 Amazon Neptune の ユーザーガイド をチェックし、 GitHubでNeptuneのサンプル をハンズオンしてみましょう。 著者について Michael Meidlinger は、AWSのシニア・ソリューション・アーキテクトで、規制産業のエンタープライズ顧客を担当しています。信号処理、統計、ネットワーキング、組み込みシステム開発、Linuxシステム管理のバックグラウンドを持ち、電気通信工学の博士号を取得しました。AWS入社以前は、ミッションクリティカルなコンピュートシステムと安全なクラウドコンピューティングコンセプトに従事しています。 Nils Müller は、オーストリアで生まれで、ウィーナー・ノイシュタットで経営工学を学びました。在学中の2000年に1000PS Internet GmbHを設立しました。1000PSというブランドで、同社はモーターサイクルをテーマとする世界有数のコンテンツプロバイダーとなりました。COVID-19の流行時に、DoGetアプリのアイデアを思いつきました。 本記事は 2023/06/03に投稿された Generate suggestions for leisure activities in real time with Amazon Neptune を翻訳した記事です。翻訳はソリューションアーキテクトの木村 達也が行いました。

このブログは Manish Singh（シニアテクニカルアカウントマネージャー）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 急速に変化するデータ環境（例：大規模なデータが頻繁に作成、共有、複製される状況）により、データストレージの需要が高まっています。多くのお客様は、費用対効果の高いデータの保存方法や、費用をかけずにデータから必要となるすべての情報を入手できる最適な方法を探しています。 クラウドストレージは、「従量課金」モデルによる柔軟なオプションを提供しています。 Amazon Simple Storage Service（Amazon S3） は、業界をリードするレベルのスケーラビリティ、可用性、セキュリティ、そしてパフォーマンスを提供するオブジェクトストレージサービスです。Amazon S3 に移行することで、俊敏性を向上し、過剰なプロビジョニングが不要になることでコストが最適化され、無制限のスケールを享受することができます。 あらゆる規模のお客様が、さまざまなワークロードやユースケースで Amazon S3 を活用しています。そして多くのお客様は、ワークロードに適した ストレージクラス を特定し、 S3 ライフサイクル を設定してストレージコストを削減することを心地よく思います。一方でお客様は、アプリケーションパフォーマンスに影響を与えたり運用上のオーバーヘッドを発生させたりすることなく、Amazon S3 のコストを詳細に調査し、料金を最適化する新しい手段を知りたいと考えています。 このブログでは、適切なストレージクラスを使用するだけではなく、Amazon S3 の料金を最適化する方法についても紹介します。API リクエスト（オペレーション）に関連する Amazon S3 の料金 を可視化する方法、API リクエストが多く発生しているバケットを特定する方法、S3 バケットへの API コールを詳しく調査する方法、API リクエスト費用を最適化する一般的な手順について詳しく説明します。コストを最適化する際の多くに共通することですが、今回紹介する情報は特に Amazon S3 の料金モデルを理解するのに役立つはずです。そして、料金の監視と分析に利用可能なさまざまなツールを使用したり、詳細を確認することができるようになります。 Amazon S3 の料金体系 Amazon S3 に関連する料金 は以下の 6 つに分類できます。 ストレージクラスの GB 単価に基づいて課金される、保存されたデータ容量に対するストレージ料金。 API リクエスト料金とも呼ばれるリクエストとデータ取得料金。例えば、GET、PUT、LIST といった操作で、行われる API の呼び出し回数に基づきます。 インターネットや他リージョンにデータを転送する際のデータ転送料金。 アカウントのバケットに対して有効化する、ストレージ管理と分析機能（S3 インベントリ、S3 ストレージクラス分析、S3 Storage Lens、S3 オブジェクトタグ）の料金。 S3 クロスリージョンレプリケーション、同一リージョンのレプリケーション、および S3 バッチオペレーションに関連する料金。 S3 Object Lambda の料金。 ストレージ料金やデータ転送料金を別にすると、GET、PUT、LIST、HEAD やライフサイクル移行などの API リクエストは Amazon S3 における料金の特に大きな部分を占めています。現在の Amazon S3 コスト最適化手法のほとんどは、適切なストレージクラスの特定やデータ転送の最適化に重きを置いており、API リクエスト料金については考慮に漏れがちです。 リクエストとデータ取得（API リクエスト）の料金は、以下の 2 つの要素に基づきます。 S3 バケットやオブジェクトに対して行われる、GET、PUT、ライフサイクル移行などの API リクエストの種類。1000 リクエスト毎の料金については、 Amazon S3 料金ページ の「リクエストとデータ取り出し」セクションを参照してください。 S3 バケットに対して行われた API リクエスト数。API リクエストの料金はリクエスト数に基づき、データのサイズやリクエストがコンソールや CLI、SDK のいずれを介して実行されたかは関係ありません。例えば、コンソールからの GET リクエストと CLI からの GET リクエストの料金は同じになります。同様に、1 KB のファイルと 1 MB のファイルの GET リクエスト料金は同じになります。 API リクエストに関連する料金は、 AWS Cost Explorer や AWS コストと使用状況レポート （AWS CUR）において、PutObject や ListObject などの名前で確認することができます。 AWS Cost Explorer を使用し Amazon S3 の料金を可視化する AWS Cost Explorer は Amazon S3 の API リクエスト料金を可視化し、料金に大きく影響している API リクエストの絞り込みに役立ちます。 AWS Cost Management にサインインし、 Cost Explorer に移動します。 フィルターセクション の サービス から、 S3（Simple Storage Service） を選択します。 適用 をクリックします。 フィルターセクション の 使用タイプグループ から、 S3: API Requests – Glacier、S3: API Requests – Standard、S3: API Requests – Standard Infrequent Access、 S3: Data Retrieval – Standard Infrequent Access  などの状況に適したフィルターを選択します。 適用 をクリックします。 API リクエストの種類を分析するために、 グループ化の条件セクション にて API オペレーション を選択します。 分析したい 日付範囲 を選択し、 適用 をクリックします。 これにより、さまざまな API リクエストのコストと利用状況を示すグラフが表示されます。 CSV 形式でダウンロード を選択することで、API リクエスト数と関連料金をより自由に分析できます。 API リクエスト料金が発生しているバケットを特定する Amazon S3 の料金を大きく占める API を特定したら、 コストと使用状況レポート のデータを使用することで、バケットレベルの詳細を取得できます。以下は Amazon Athena を使用してコストと使用状況のデータを分析し、API リクエストが行われたバケットを特定する方法です。 コストと使用状況レポートの作成 に従って、コストと使用状況レポートを有効化します。この時、バケットの詳細を取得する必要があるので、 リソース ID を含める を選択します。 Amazon Athena を使用したコストと使用状況レポートのクエリ に従って、コストと使用状況レポートを Amazon Athena と統合します。 コストと使用状況レポートを有効化して Amazon Athena と統合できたら、次のクエリを実行し、バケット情報と関連する API リクエストとその料金の詳細を取得します。 SELECT "line_item_operation" as API , "line_item_resource_id" as Bucket , SUM ( "line_item_blended_cost" ) as Cost FROM << CUR_TABLE_NAME >> WHERE "product_product_name" = 'Amazon Simple Storage Service' AND "line_item_usage_type" not like '%Byte%' AND "line_item_resource_id" != '' AND line_item_usage_start_date >= CAST ( 'YYYY-MM-DD 00:00:00' AS TIMESTAMP ) AND line_item_usage_start_date < CAST ( 'YYYY-MM-DD 00:00:00' AS TIMESTAMP ) GROUP BY "line_item_operation" , "line_item_resource_id" ORDER BY SUM ( "line_item_blended_cost" ) DESC SQL CUR_TABLE_NAME と日付の範囲（ YYYY-MM-DD 00:00:00 ）を変更し、さまざまなバケットごとの API 料金を取得します。この情報は、バケットとそれに関連する API リクエスト料金の特定に役立ちます。 結果は次の表のようになります。 API Bucket Cost S3-GlacierTransition Bucket 1 $$$ ListBucket Bucket 2 $$$ PutObject Bucket 3 $$$ バケットに対して行われた API リクエストの分析 Amazon S3 サーバーアクセスログ は、バケットに行われたリクエストの詳細を記録します。サーバーアクセスログを有効化し、 Amazon Athena を使用して API リクエストを分析します。 サーバーアクセスログを有効化し、Amazon Athena と統合します。詳細は Amazon Athena を使用して Amazon S3 サーバーアクセスログを分析する を参照してください。 次のクエリを実行して、API リクエスト数の多い IP アドレスを特定します。 SELECT remoteip , requester , useragent , COUNT ( * ) AS remote_count FROM << access_log_bucket >> WHERE Operation = 'api_call_to_review' AND parse_datetime ( RequestDateTime , 'dd/MMM/yyyy:HH:mm:ss Z' ) BETWEEN parse_datetime ( '2021-08-08:00:00:00' , 'yyyy-MM-dd:HH:mm:ss' ) AND parse_datetime ( '2021-10-08:00:00:00' , 'yyyy-MM-dd:HH:mm:ss' ) GROUP BY remoteip , requester , useragent order by remote_count desc SQL ステップ 1 にて作成したテーブルを access_log_bucket  にて指定し、 REST.GET.BUCKET 、 REST.GET.LIFECYCLE 、 REST.GET.OBJECT 、 REST.PUT.OBJECT 、 REST.HEAD.OBJECT 等のトラックしたい要素を api_call_to_review にて指定します。また分析を行いたい時間の範囲も適宜指定してください。 API リクエストをさらに詳しく分析する際に使用できる他の列名について理解したい場合は、 サーバーアクセスログのフォーマット に関するドキュメントを参照してください。 API 料金を最適化するさまざまな方法 コスト最適化を行いたい API コールとバケットを特定したら、以下の一般的なコスト最適化手法を参照してください。 GetObject と PutObject GetObject と PutObject リクエストは、それぞれ S3 バケットからオブジェクトを取得、S3 バケットにオブジェクトを追加するために使用され、これらは頻繁に使用されます。GET および PUT API のコストは、追加および取得されるオブジェクト数に依存し、サイズは影響しないことを踏まえて戦略を検討します。 小さなオブジェクトが多数存在する場合、GET および PUT API のコストが高くなる可能性があります。アプリケーションのアーキテクチャを見直し、複数の小さなオブジェクトから、1 つの大きなオブジェクトに置き換えられないか検討してください。例えば、1 分ごとにファイルを作成する代わりに、過去 15 分間、もしくは 30 分間に加えられた変更データを使用するなど、より長い時間に基づいてファイルを作成しましょう。 .tar や .zip ファイルを作成して、オブジェクトを 1 つのファイルにまとめます。この時、まとめられたファイル内における個々のオブジェクトの識別や、アクセスのしやすさを考慮する必要があります。 S3 パブリックアクセスブロック を使用することで、バケットレベルもしくはアカウントレベルでオブジェクトへのパブリックアクセスをブロックし、不正アクセスや予期しない API 料金の発生を防ぐことができます。 静的オブジェクトが多数を占める場合、 Amazon CloudFront を使用した GET リクエスト数の削減を検討してください。この場合、費用対効果の分析を別途行い、Amazon CloudFront を導入することでコストが削減され期待に応えることができるか判断する必要があります。 コストと使用状況レポートを使用して、S3 バケットのストレージ料金と API リクエスト料金（GET、PUT、LIST）を比較します。S3 バケットの料金のうち API リクエストが多くを占める場合、最適なストレージクラスが選択できているのか、もしくは Amazon DynamoDB といった他の選択肢がワークロードに適しているのか検討する必要があります。 ListBucket ListBucket は特定のバケットにおけるオブジェクトの一覧を表示するために使用されます。特定の S3 バケットにおいて ListBucket の料金が高い場合は、アプリケーションの設計を再確認し、この操作を頻繁に利用する理由を確認してください。またその理由を基に、HEAD リクエストで代替できないか検討してください。 S3 ライフサイクル移行 S3 ライフサイクル移行ルールは、オブジェクトを別のストレージクラスへ移行する際や期限切れにする際に使用されます。ライフサイクルの移行ルールの内容に応じて、次の 2 種類の料金が発生します。 移行料金：あるストレージクラスから別のストレージクラスに移行されたオブジェクト数に基づきます。 早期削除料金：一部ストレージクラスに定められた最小ストレージ期間を満たさない場合、 削除料金 が発生します。 S3 ライフサイクル移行ルールをバケット全体に適用するだけではなく、プレフィックスやオブジェクトタグ、オブジェクトサイズに基づいたフィルタリングを設定することで、移行料金を削減することができます。S3 ライフサイクル移行に関連するコストを管理するには、以下の 4 つのオプションを参考にしてください。 移行するオブジェクト数を減らす ライフサイクル移行ルールを適用するためにアクセスパターンを分析し、適切な S3 バケットとプレフィックスの範囲、および適切なストレージクラスを特定します。ライフサイクル移行ルールを設定する前に、 S3 ストレージクラス分析 や S3 Storage Lens などのツールを使用してアクセスパターンを監視し、オブジェクトサイズや総オブジェクト数などのさまざまなメトリクスを確認します。 ライフサイクル移行する前に、小さなオブジェクトを大きなファイル（.tar、.zip）にまとめてください。移行コストは移行されるオブジェクト数に基づくため、小さなオブジェクトを大きなファイルにまとめることで料金を削減できます。複数のオブジェクトをまとめる際は、検索性の考慮が必要になります。 オブジェクトタグはオブジェクトに関連づけられるキーと値のペアです。プレフィックスや 1 つ以上のオブジェクトタグ、またはその両方を使ってライフサイクル移行ルールにフィルターを定義し、移行または期限切れになるオブジェクト数を制限します。詳細については、 S3 ライフサイクル移行ルールの設定 に関するブログも参照ください。例えば、key が transition、value が glacier のオブジェクトのみを、 Amazon S3 Glacier ストレージクラス のいずれかに移行するといったことができます。以下は詳細な手順となります。 Amazon S3 コンソールにアクセスし、設定したいバケットの 管理タブ に移動します。 ライフサイクルルールを作成する を選択します。 フィルターを指定するため、 ルールスコープを選択 にて 1 つ以上のフィルターを使用してこのルールのスコープを制限する を選択します。 フィルタータイプのセクションにて プレフィックス を指定し、ルールの適用範囲を絞り込みます。 同じくフィルタータイプのセクションにて、 オブジェクトタグ の下にある タグの追加 を選択します。各タグはキーと値（任意）の両方に一致する必要があります。また、指定されたすべてのタグを持つオブジェクトに対してのみ、ルールが適用されます。もしオブジェクトに他のタグが存在していても、ルールは適用されます。 ライフサイクル移行ルールの目的でタグを追加する前に、費用対効果の分析を行って、オブジェクトタグを含めた費用削減効果を見積もってください。オブジェクトタグに関連する費用の詳細については、 Amazon S3 の料金 を参照してください。 ライフサイクル移行ルールを適用する前に、最小オブジェクトサイズと請求要件を理解してください。S3 Standard-Infrequent Access（S3 Standard-IA）および S3 One Zone-IA ストレージクラスの課金対象最小オブジェクトサイズは 128 KB です。つまり、128 KB 未満のオブジェクトを S3 Standard-IA や S3 One Zone-IA に移行しても、期待通りのコスト削減は果たせません。ストレージクラスごとに定められた最小オブジェクトサイズを確認するには S3 ストレージクラスのパフォーマンスチャート を参照してください。 ライフサイクル移行ルールは、オブジェクトサイズを基にしてフィルターを定義できます。コストを節約するために小さいファイルを移行したくない場合は、最小、最大オブジェクトサイズに基づいたフィルターが活用できます。 オブジェクトを移行、または期限切れにする S3 ライフサイクルルールを作成する前に、アクセスパターンに加えて、データ保持要件と各ストレージクラスの最小ストレージ期間を確認してください。例えば、S3 Standard-IA や S3 One Zone-IA には 30 日間の最小ストレージ期間が、S3 Glacier Instant Retrieval や S3 Glacier Flexible Retrieval には 90 日間の最小ストレージ期間が設けられ課金されます。ストレージクラスごとの最小ストレージ期間を確認するには S3 ストレージクラスのパフォーマンスチャート を参照してください。最小ストレージ期間を経過せずにオブジェクトの移行や期限切れを行った場合、最小ストレージ期間に満たない日数分が日割りで DeleteObject 料金として発生します。 S3 Storage Lens を使用することで、オブジェクトストレージの使用状況とアクティビティの傾向を可視化できます。S3 Storage Lens は、オブジェクト数、平均オブジェクトサイズ、PUT リクエスト、GET リクエスト、LIST リクエストなど 30 を超えるメトリクスを提供しており、ライフサイクル移行ルールの微調整や API リクエスト料金の最適化に役立ちます。以下は S3 Storage Lens を活用する手順の一例です。 S3 Storage Lens に関するブログ を参考に、ダッシュボードを作成します。 ダッシュボードを開きタブの中から バケット を選択します。特定のプレフィックスを分析したい場合は、 プレフィックス を選択してください。 総ストレージ量 、 オブジェクト数 、 オブジェクトサイズの平均 等のメトリクスを確認し、移行コストを見積もってライフサイクル移行ルールを決定します。 メトリクスのカテゴリからアクティビティを選択し、 GET リクエスト 、 PUT リクエスト 、 HEAD リクエスト 、 LIST リクエスト などのメトリクスを確認して、API リクエストを分析します。 クリーンアップ 継続的に課金されないようにするには、このブログを基に作成したリソースを削除してください。 Amazon S3 の サーバーアクセスログ を停止してください。 S3 ストレージクラス分析や S3 Storage Lens などの Amazon S3 の管理および分析ツールを停止してください。 まとめ このブログでは、様々な Amazon S3 の API リクエストに関連する料金の可視化と分析について説明しました。そして、AWS Cost Explorer やコストと使用状況レポート、サーバーアクセスログをそれぞれ使用して、S3 バケットに関連する API リクエスト料金を特定する方法を示し、料金を最適化するための複数のアプローチを確認しました。 Amazon S3 を使用するお客様は、適切なストレージクラスの活用やデータ削除を行うことで、長年コストを最適化してきました。Amazon S3 へのリクエストや取り出し（API リクエスト）がどのように課金されるのか、また API リクエスト料金を削減するための一般的なアプローチを理解することで、さらなるコストの最適化が達成できます。API リクエストの料金体系を理解することで、管理者や開発チームは正しいアーキテクチャを設計でき、予想外の料金を回避することができます。 Amazon S3 のコストを削減するための、リクエスト料金とデータ取得料金の最適化に関するこのブログをお読みいただきありがとうございました。 Manish Singh Manish Singh は Amazon Web Service のインド、バンガロール拠点に所属する、シニアテクニカルアカウントマネージャーです。Manish は 19 年以上の業界経験を持ち、クラウドアーキテクチャと IT システム設計に関する専門知識を備えています。彼はクラウド財務管理ソリューションに強い関心を持っており、AWS エンタープライズサポートのお客様に向けてコスト最適化の提案を行っています。