Gartner は 2024 年 8 月 19 日に、 Amazon Web Services (AWS) が含まれる Gartner 初の Magic Quadrant for AI Code Assistants を公開しました。 Amazon Q Developer は、2024 年 4 月 30 日に 一般提供 が開始されたことから審査対象要件を満たしており、AWS はその実行能力とビジョンの完全性からリーダーとしてランク付けされました。 私たちは、このリーダーとしての位置付けが、エンタープライズグレードのアクセスコントロールとセキュリティを用いてソフトウェア開発ライフサイクル全体を容易にし、開発者の生産性を向上させる、AWS の 急ペースのイノベーション を反映していると考えています。 Gartner のマジッククアドラントは、実行能力とビジョンの完全性に基づいて 12 の AI コードアシスタントを評価しています。Gartner の「 How Markets and Vendors Are Evaluated in Gartner Magic Quadrants 」レポートによると、実行能力は製品とサービスを効果的に提供するベンダーの能力を測定し、ビジョンの完全性はベンダーによる市場の理解と将来的な成長に向けた戦略を評価するものです。 以下は、2024 年 Gartner Magic Quadrant for AI Code Assistants のグラフです。 以下は、Gartner のレポートからの引用です。 Amazon Web Services (AWS) は、本マジッククアドラントのリーダーです。その製品である Amazon Q Developer (旧 CodeWhisperer) は、AI を使用して開発者のタスクを支援し、自動化することに重点を置いています。例えば、Amazon Q Developer はコードの提案と変換、テストとセキュリティ、および機能開発を支援します。その運用は地理的多様性を備え、あらゆる規模のクライアントを対象としています。AWS は、ソフトウェア開発ライフサイクル (SDLC) を強化する AI 主導型ソリューションの提供、複雑なタスクの自動化、パフォーマンスの最適化、セキュリティの確保、およびイノベーションの促進を重視しています。 私のチームは、 Amazon Q Developer Center と Community.aws で、ソフトウェア開発者のジョブ理論 (Jobs-To-Be-Done) を直接サポートし、生成 AI によって実現および強化される、Amazon Q Developer 関連のコンテンツを作成することに焦点を当てています。 私は、お客様と会話して、Amazon Q Developer を選ぶ理由をたずねる機会を得ました。お客様は、コーディング、テスト、アップグレードから、トラブルシューティング、セキュリティスキャンと修正の実行、AWS リソースの最適化、そしてデータエンジニアリングパイプラインの作成におよぶ、一般的な AI コードアシスタントをはるかに超えた SDLC 全体でのタスクの加速と完了に利用できることだと答えています。 以下は、お客様がより頻繁に言及した重要点です。 必要に応じてどこからでも利用可能 – Amazon Q Developer は、 Visual Studio Code 、 JetBrains IDEs 、 AWS Toolkit with Amazon Q 、 JupyterLab 、 Amazon EMR Studio 、 Amazon SageMaker Studio 、または AWS Glue Studio などの任意の統合開発環境 (IDE) で使用できます。Amazon Q Developer は、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS ドキュメント 、 AWS サポート 、 AWS コンソールモバイルアプリケーション 、 Amazon CodeCatalyst で使用したり、 AWS Chatbot が設定された Slack および Microsoft Teams 経由で使用したりすることもできます。Safe Software は、「Amazon Q は AWS が提供する多数のツールの活用方法をすべて理解しています。より多くの事柄を達成できるようになったため、私たちは自動化を他の AWS サービスに拡張し、Amazon Q を活用して、目標の実現に役立てることができるでしょう」と話しています。 詳細については、 Amazon Q Developer の機能 と Amazon Q Developer のお客様 をご覧ください。 コード推奨のカスタマイズ – 社内のコードベースに基づいたコード推奨を取得できます。Amazon Q Developer は、社内のライブラリ、API、ベストプラクティス、アーキテクチャパターンを認識させることによって、新しいコードベースへのオンボーディングを迅速化し、より関連性の高いインラインコード推奨とチャット応答 (プレビュー中) を生成します。組織の管理者は、社内のコードベースに Amazon Q Developer をセキュアに接続して、複数のカスタマイゼーションを作成できます。 National Australia Bank (NAB) によると、NAB はそのコーディング標準に合わせてカスタマイズされた、Amazon Q のカスタマイゼーション機能を使用する固有の提案を追加しました。カスタマイゼーションにより、NAB では受け入れ率が 60% 向上しています。詳細については、AWS ドキュメントの「 Customizing suggestions 」を参照してください。 Java アプリケーションのアップグレード – Amazon Q Developer Agent for Code Transformation は、レガシー Java アプリケーションをアップグレードして変換するプロセスを自動化します。 Amazon の社内調査 によると、Amazon は Amazon Q Developer による支援を使用して、何万もの本番環境アプリケーションを Java 8 または 11 から Java 17 に移行しました。これは、1,000 人を超える開発者の 4,500 年を超える開発作業時間の節約 (手動アップグレードと比較した場合) と、年間コスト削減額 2 億 6,000 万 USD に相当するパフォーマンス向上に値します。Windows からクロスプラットフォーム .NET への変換も間もなく開始される予定です! 詳細については、AWS ドキュメントの「 Upgrading language versions with the Amazon Q Developer Agent for code transformation 」を参照してください。 詳細については、 2024 年 Gartner Magic Quadrant for AI Code Assistants レポート 全文をお読みください。 – Channy 原文は こちら です。 Gartner Magic Quadrant for AI Code Assistants (アナリスト: Arun Batchu、Philip Walsh、Matt Brasier、Haritha Khandabattu)、2024 年 8 月 19 日。 Gartner は、その調査出版物に記載されているベンダー、製品、またはサービスを推薦するものではなく、最高評価やその他認定を受けたベンダーのみを選択するようテクノロジーユーザーに勧告するものでもありません。Gartner の調査出版物は、Gartner の調査組織による見解で書かれたものであり、事実を表明するものではありません。Gartner は、商品性または特定目的適合性に関するいかなる保証も含め、この調査に関する明示黙示の如何を問わず、あらゆる保証の適用を排除します。 GARTNER は、Gartner の登録商標およびサービスマークです。Magic Quadrant は、米国およびその他の国における Gartner および/またはその関連会社の登録商標であり、許可を得て使用しています。All rights reserved.

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 関東は、秋めいた日も増えたように感じますが皆さんの地域はいかがでしょうか？ この時期になるとre:Inventが楽しみな気持ちもありつつ、その前にもいくつかイベントが予定されています。 その一つが10月31日に開催されるAWS AI Dayです。本日からオンサイト参加の登録サイトがオープンしました。 “AWS のテクノロジーで加速する生成 AI のプロダクション活用”について学べる機会ですので、ぜひご活用ください。 2024年10月31日 14:00-18:00 – AWS AI DAY 〜AWS のテクノロジーで加速する生成 AI のプロダクション活用〜 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年8月12日週の主要なアップデート 9/2(月) 米国祝日のためこの日の発表はありませんでした。 9/3(火) Amazon DynamoDB announces support for Attribute-Based Access Control Amazon DynamoDBがテーブルとインデックスの属性ベースのアクセス制御(Attribute-Based Access Control, ABAC)をサポートしました。この機能ではタグを使用してアクセス権とポリシーを設定が可能です。AWS ID およびアクセス管理 (IAM) プリンシパルのタグが Amazon DynamoDB テーブルのタグと一致する場合、タグベースのアクセス条件を使用して特定のアクションを許可または拒否できます。タグベースの条件を柔軟に使用できるようになったため、組織構造に基づいてより詳細なアクセス権限を設定できるようになりました。この機能は米国東部 (オハイオ)、米国東部 (バージニア)、および米国西部 (北カリフォルニア) の3つのリージョンでリミテッドプレビューとして利用可能です。リミテッドプレビューへのアクセスリクエストは こちらのページ をご確認ください。 Introducing sagemaker-core: A New Object-Oriented SDK for Amazon SageMaker SageMakerのリソースを操作するための新しいオブジェクト指向インターフェイスを提供するPython SDKであるsagemaker-coreが発表されました。sagemaker-coreはSageMaker APIと完全に同等のソリューションとして、すべてのSageMakerの機能を直接操作、活用することが可能です。また、sagemaker-coreはリソースの状態遷移やポーリングロジックなどの低レベル操作を抽象化しており、開発者の認知負荷を低減して複雑なパラメーター構造の管理を最小限に操作可能にします。詳細については サンプルノートブック や ドキュメント をご確認ください。 Amazon EBS direct APIs now supports IPv6 in AWS PrivateLink AWS PrivateLink経由でVPCからAmazon EBS direct APIを呼び出す際に、EBS direct APIがIPv6をサポートしました。EBS direct APIはAPI経由でEBSのスタップショット作成や読み取りを行うことができるAPIです。今回の対応により、IPv6ベースのオンプレミス・アプリケーションとの統合が可能になり、IPv4とIPv6間のアドレス変換を処理するための高価なネットワーク機器が不要になります。このアップデートはEBS direct APIが利用可能なすべてのAWSリージョンで利用可能です。 AWS Glue now provides job queuing AWS Glueにジョブのキューが追加されました。これまでアカウントレベルのクォータやリミットを意識する必要がありましたが、今回のアップデートにより、クォータやリミットを監視し、Glueが自動的にジョブをキューに入れ、再試行するようになります。これによりオペレーションが簡略化されます。この機能はマネジメントコンソールまたは API/CLI を使用して有効化が可能です。詳細については ドキュメント や ブログ をご確認ください。 AWS Network Load Balancer now supports configurable TCP idle timeout AWS Network Load Balancer (NLB)のTCPアイドルタイムアウトはこれまで350秒の固定値でしたが、60〜6000秒の値を柔軟に設定できるようになりました。これによりデータベースやERPなど存続時間の長いフローを使用するアプリケーションでの利用時に起きるトラフィックフローの中断を減らすことができます。この機能は、すべての AWS 商用リージョンと AWS GovCloud (米国) リージョンで利用可能です。詳細についてはこちらの ブログ もご確認ください。後述していますが、GWLBに関しても9/5に同様のアップデートがされています。 9/4(水) Bedrock Agents on Sonnet 3.5 生成AIと組み合わせた複雑なタスクの作成や社内のナレッジベースと連携したアプリケーションの作成を簡単に行えるAgents for Amazon Bedrockが、Claude 3.5 Sonnetに対応しました。東京、シンガポール、フランクフルト、オレゴン、バージニア北部の５つのリージョンで利用可能です。Bedrock Agentsについてや対応するモデル等の情報は ドキュメント をご確認ください。 Stability AI’s Top 3 Text-to-Image Models Now Available in Amazon Bedrock Stable Image Ultra, Stable Diffusion 3 Large (SD3 Large), and Stable Image Coreの３つのモデルが新たにAmazon Bedrockで一般提供されました。メディア、マーケティング、小売、ゲーム開発など、幅広い業種のお客様でこれまでにないスピードと精度で高品質のビジュアルを生成できるようになります。Stable Image Ultraは最高品質でフォトリアリスティックな出力、Stable Diffusion 3 Largeは生成速度と出力品質のバランス、Stable Image Core — 高速で手頃な価格の画像生成、に各々最適化されているいます。これらのモデルは、米国西部 (オレゴン) で利用可能です。 Use Apache Spark on Amazon EMR Serverless directly from Amazon Sagemaker Studio Amazon SageMaker Studio ノートブックから直接Amazon EMR サーバレスに接続できるようになりました。これによりEMR サーバレスで扱うペタバイト規模のデータにSpark SQL、Scala、Python を使用してインタラクティブにデータをクエリ、調査、視覚化したり、ノートブックからApache Spark ジョブを実行してデータを処理することができます。これらの機能は SageMaker ディストリビューション 1.10 以降で、SageMaker Studio が利用可能なすべてのAWSリージョンで利用可能です。詳細については、こちらの ブログ もご確認ください。 9/5(木) Announcing Storage Browser for Amazon S3 for your web applications (alpha release) Storage Browser for S3がアルファ版としてリリースされました。Storage Browser for S3はオープンソースのUIコンポーネントで、エンドユーザーがS3上のデータにアクセスするためのシンプルなインターフェースを提供します。リクエストを自動的に最適化して高スループットのデータ転送を実現する他、エンドユーザーのIDに基づくデータへのアクセス制御が可能です。現時点ではAWS Amplify JavaScript および React クライアントライブラリに対応しています。詳細は Github をご確認ください。 Amazon RDS Custom for SQL Server supports Cross-region Snapshot Copying Amazon RDS Custom for SQL Serverがスナップショットのクロスリージョンコピーに対応しました。これによりディザスターリカバリーを必要とするミッションクリティカルなサービスでもこれまでよりも簡単にAmazon RDS Custom for SQL Serverを活用いただくことが可能になります。この機能は、Amazon RDS Custom for SQL Serverが提供されているすべての商用 AWS リージョンでご利用いただけます。詳細は ドキュメント をご確認ください。 AWS Gateway Load Balancer now supports configurable TCP idle timeout AWS Gateway Load Balancer (GWLB) のTCPアイドルタイムアウトはこれまで350秒の固定値でしたが、60〜6000秒の値を柔軟に設定できるようになりました。これによりデータベースやERPなど存続時間の長いフローを使用するアプリケーションでの利用時に起きるトラフィックフローの中断を減らすことができます。この機能は、すべての AWS 商用リージョンと AWS GovCloud (米国) リージョンで利用可能です。詳細はこちらの Blog もご確認ください。 Amazon WorkSpaces Pools now allows you to bring your Windows 10 or 11 licenses Amazon WorkSpaces プールがMicrosoft Windows 10及び11のBYOLに対応しました。これにより対象となる企業向けMicrosoft 365 Appsをサポートされるため、オンプレミスデスクトップと仮想デスクトップを切り替えた場合でも、一貫した体験が可能になります。このオプションを利用するには、マイクロソフトのライセンス要件を満たしている必要と、特定のAWS リージョンで毎月最低数の WorkSpacesの利用のコミットが必要です。詳細については「 AWS リージョン WorkSpaces プールの とアベイラビリティーゾーン 」とドキュメントの BYOLに関する項目 をご確認ください。 Amazon RDS for Oracle now supports OEM and OLS options with Multitenant configuration Amazon RDS for Oracleがマルチテナント設定でOracle エンタープライズマネージャー (OEM) と Oracle ラベルセキュリティ (OLS) オプションをサポートするようになりました。OEMは、Oracle インフラストラクチャを 1 つのコンソールから監視および管理できる機能で、OLSは個々のテーブルまたは行へのアクセスをきめ細かく制御するポリシーベースの管理機能です。各々、OEMの有効化に関してはこちらの ドキュメント を、OLSの有効化に関してはこちらの ドキュメント をご確認ください。 9/6(金) Amazon ECS now supports AWS Graviton-based Spot compute with AWS Fargate Amazon ECSでAWS Fargate Spotを利用時にAWS Gravitonを選択できるようになりました。AWS GravitonはAmazonが開発するARMベースのプロセッサで、Intel等他のCPU対比で電力効率やコストパフォーマンスが高いCPUです。これまでもFargateでGravitonを使うことは可能でしたが、Fargate SpotではIntel等他のCPUのみ利用可能だったためARM用にビルドしたコンテナでFargate spotを使うことはできませんでした。今回の対応によりARMベースのアプリケーションもFargate Spotで実行可能になり、中断や再開が許容できるアプリケーションはFargateと比較し最大70％割引でコンテナ実行が可能になります。この機能は、すべての商用リージョンと AWS GovCloud (米国) リージョンの AWS Fargate プラットフォームバージョン 1.4.0 以降で実行されている Amazon ECS タスクで利用可能です。詳細に関しては ドキュメント をご確認ください。 Amazon RDS Custom for SQL Server is now available in 3 additional AWS Regions Amazon RDS Custom for SQL Serverが大阪、パリ、北カリフォルニアの3つのリージョンで別時間になりました。Amazon RDS Custom for SQL Serverはマネージド型サービスでありつつ、通常のRDSでは操作できない特権アクセスを必要とする機能や設定変更に対応したサービスです。詳細については ドキュメント をご確認ください。 CloudWatch Application Signals now supports request based Service Level Objectives (SLOs) CloudWatch Application Signalsはメトリクス、トレース、ログのテレメトリとアプリケーションを関連づけ、可視化やSLOの管理を行うことができるサービスです。今回、CloudWatch Application SignalsがリクエストベースのSLOをサポートしました。例えば 200 ミリ秒未満のレイテンシーを満たすことをSLOとして定義する場合、リクエスト全体のうち満たしたリクエストの数を把握、監視が可能になります。詳細についてはこちらの ドキュメント をご確認ください。 それでは、また来週！ 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

Sansan株式会社（以降 Sansan と記載）は、名刺や企業情報、営業履歴を一元管理して全社で共有できるようにすることで、売上拡大とコスト削減を同時に実現する営業 DX サービス「 Sansan 」を展開しています。その他にも、インボイス管理サービスとして「 Bill One 」を展開しており、郵送やメール添付などあらゆる形式の請求書をオンラインで受け取り可能にし、正確なデータ化を通じて請求書業務の DX を促進するサービスとなっています。 Sansan では、Bill One の認証基盤を「 Auth0 」で実現していましたが、プロダクト原価のコスト増につながっており、認証基盤を独自構築することで、費用削減を狙うプロジェクトが発足しました。認証基盤の構築プロジェクトは、6カ月という短期間で開発を完了しており、AWS 上で実現されたワークロードとなります。この認証基盤では、データベースサービスとして、 Aurora Serverless v2 を使用しています。本ブログでは、Aurora Serverless v2 を導入した効果について、お客様の声をご紹介します。 Aurora Serverless v2 の導入経緯 Sansan ではマネージドな DB が選択肢としてあがることが多く、Sansan の代表的な名刺アプリ「Eight」 では Aurora を使っています。他部署でもAuroraを利用しており、一度 Aurora Serverless v2 が検討の俎上にのぼったことはありましたが、コスト的な観点でプロビジョンドのAurora が選択されました。 今回開発した認証基盤の要件は以下の通りです。 Bill One のサービスレベルを満たすため、障害時にも業務が継続できる高い可用性 深夜の利用は極端に少ないなど、時間帯や曜日で変動要素が大きいワークロード ユーザー数の増加や想定外のピーク特性を考慮しつつ、少ないメンバーでも運用できる低い運用負荷 上記の要件を満たすサービスを検討した結果、可用性の高い Aurora PostgreSQL を採用することに決めました。さらに、Aurora Serverless v2を利用することで、トラフィックの需要に合わせてリソースのスケールアップ/ダウンが可能になり、開発者の限られたリソースの中で運用負荷を最低限に抑えられると判断しました。 Aurora Serverless v2 の開発/運用フェーズ上のメリット 少人数の体制でも 6 カ月間という短い期間で開発を完了できました。短い期間で達成できた一つの要因として、Aurora Serverless v2 を採用したことがあります。これにより信頼性/性能設計やテストの工数を大幅に削減でき、実際に負荷テストの段階で大きな性能トラブルもなく予定通り 1 週間 で終えられました。 今までは、Bill One の特性上、月末/月初にサービスへの負荷が集中するため、ピーク時期に備えて事前にデータベースのスケールアップを実施する必要があり、夜間作業が発生していました。今回の認証基盤では、Aurora Serverless v2 を選択したことで夜間作業がゼロになり、本来やるべき改善作業にリソースを集中できています。また、従来のデータベースでは、スケールアップなどの運用作業の際にダウンタイムが発生し、ユーザーへの影響が懸念されていましたが、Aurora Serverless v2ではダウンタイムもなくスケールアップできることが大きなメリットです。 また、日々の監視作業も楽になりました。従来のプロビジョンドだと、ピーク時に想定以上のユーザートラフィックがあった場合に OS リソースが不足していないかなど、重点的に監視する作業が発生していました。Aurora Serverless v2 はトラフィックに応じて柔軟にスケールアップしてくれるため、現状のところ月末/月初にも特に大きなトラブルなく運用できています。また、トラフィックが少なくなるとスケールダウンもしてくれるため、コスト最適化にもつながっています。 Aurora Serverless v2 の運用上の留意点 先ほども述べたように Aurora Serverless v2 は、 ほったらかしても大きなトラブルなく稼働 してくれますが、最大 ACU を超えないように監視することが重要です。Bill One の認証基盤では、当初最大 ACU を 16 ACU に設定していました。ある月初のタイミングでリソースの使用状況を確認したところ、ユーザー数の増加により、近いうちに上限を超えてしまう兆候が見えたため、最大 ACU を 32 ACU に拡張しました。その際にも再起動が不要なので、ユーザーへの影響なくスケールアップできました。 一方で、処理負荷の高いクエリが実行されると、簡単にスケールアップしてしまい、コスト増加に直結する傾向があります。ユーザー体験の悪化は防げますが、コストが高止まりする懸念があるため、認証基盤の運用でも定期的に Performance Insights を監視し、処理負荷の高いクエリをチューニングしています。 例えば、Row-Level Security を利用しているテーブルをスキャンするクエリで関数インデックスがうまく使われず、フルスキャンが発生してしまうことがありました。インデックスが利用されるようにするため、関数インデックスで使っていた関数を生成列として作成し、そのカラムにインデックスを作成してチューニングを行いました。そのようなチューニングを行うことで、サービスレベルの向上につながり、最大で 87％ の ACU 削減（=コスト削減）に成功しました。このように、定期的にパフォーマンス状況を監視し、チューニングを行っていくことで、コストが高止まりしないような運用を継続していこうと考えています。 将来の展望 今回開発した認証基盤は、現在Bill Oneでのみ利用していますが、将来的には他のプロダクトでも利用する可能性があります。さらにBill One自体のユーザー数も年間で約 2 倍の伸びを見せています。よって今後、新規プロダクトがこの認証基盤を利用したり、Bill Oneのユーザー数が急激に増加したりした場合、これまで以上にダウンタイムが許容されなくなることが予想されます。また、予想していないようなアクセスパターンへの対応など、より堅牢なシステムに昇華させていく必要があると考えています。 仮にデータベースにプロビジョンドインスタンスを利用していて、新規プロダクトを追加する場合、システムを増強するためにユーザー調整や運用作業が発生すると考えられるため、無停止で拡張できるのは非常にありがたいです。 また、Bill Oneはサービスをグローバルに展開しています。現在はアジア圏が中心のため夜間帯がオフタイムになり、Aurora Serverless v2 のコストはそこまでシステム原価に影響していませんが、今後アジア圏以外でも利用が拡大すると、「Follow the Sun」にもあるようにオフタイムという概念がなくなる可能性があります。コスト低減の観点で、リザーブドインスタンス（RI）や Savings Plan による割引プランなどがでてくると、24/365 で稼働する他システムでも利用しやすくなると考えています。   ソフトウェアエンジニア 樋口 礼人 様 Auth0 のコスト削減するのが目的で、認証システムを開発しています。そのため、認証システムのコストは今後も注視していく必要がありますが、少ない人数である意味ほったらかした状態 でデータベースを運用することができています。 サービスが成長していく中で、 Aurora Serverless v2 を選択したことは、メリットがあったと感じています。 チーフアーキテクト 加藤 耕太 様 AWS のアカウントチームの方々には、アーキテクチャレビューなどさまざまなサポートをしていただきました。リリース後もTrusted Advisor による Resilience の向上やコスト最適化に寄与いただいて、非常に助かっています。 著者 藤川 貞信（ISV/SaaS Business ソリューションアーキテクト） 高橋 佑里子（ISV/SaaS Business ソリューションアーキテクト） 内山 義夫（シニアデータベーススペシャリスト） 曽根田 隆司（アカウントマネージャー）

本記事は 2024 年 7 月 2 日に公開された記事 “ Modernize your Java application with Amazon Q Developer “ を翻訳したものです。 多くの組織には、保守がますます困難となっている重要なレガシー Java アプリケーションがあります。これらのアプリケーションのモダナイゼーションは必要不可欠ですが、新しい価値や機能を生み出すことに重点を置かない、困難かつリスクの高い作業です。このモダナイゼーションには、ドキュメント化されていないコード、古いフレームワークやライブラリ、セキュリティの脆弱性、ロギングやエラー処理、入力値チェックの欠如が含まれます。 Amazon Q Developer は、既存の Java アプリケーションのモダナイゼーションを簡素化し、加速させます。具体的には、コードを分析して改善余地のある領域を浮き彫りにしたり、技術的負債の解消を支援したり、コードの最適化を提案したり、現在のフレームワークやライブラリへの移行を促進したりすることができます。 このブログ記事では、Amazon Q Developer を使用してレガシー Java アプリケーションをモダナイズする方法について説明します。 Amazon Elastic Compute Cloud (Amazon EC2) 上で動作する Java 8 を搭載した Java アプリケーションである Unicorn Store API の例を取り上げます。まず、基盤となるランタイムを Java 8 から Java 17 へ、そして Spring を含む一般的な技術スタックをアップグレードします。次に、モジュール構成とロギングを改善することで、コード内の技術的負債を減らします。最後に、モダンなコンピューティングオプションである AWS Fargate を使用して、このアプリケーションをコンテナイメージに再デプロイします。 Maven でビルドされている Unicorn Store API は、データベース内のレコードを管理するための CRUD 操作を提供します。以下の手順に沿って Amazon Q Developer を使用して、このアプリケーションをモダナイズし、Fargate へ移行します。 最新の機能を活用し、アプリケーションを Java 17 へアップグレードします。 コードベース上にある既存の技術的負債を減らします。 アプリケーションをクラウドネイティブ化して AWS にデプロイします。 このチュートリアルでは、IntelliJ IDEA の統合開発環境と Amazon Q Developer plugin for IntelliJ IDEA を使用しています。 Java 8 から Java 17 へのアップグレード 古いアプリケーションでは、セキュリティと安定性を維持するためにより多くの労力が必要です。開発者は、以前のアップグレードで発見されたフレームワークの変更や最適化について、継続的な再学習が求められます。アプリケーションのメンテナンスに労力が割かれるため、必要なアップグレードと新しい機能追加とのバランスを取ることが困難です。 Amazon Q Developer agent for code transformation を使用すると、わずか数ステップでアプリケーションを最新の状態に保ち続けることができます。これにより、サポートされていないバージョンにおける脆弱性が取り除かれ、パフォーマンスが向上し、新しい機能開発に集中できるようになります。Amazon Q Developer agent for code transformation によって、アプリケーションのメンテナンス、アップグレード、移行を迅速に行うことができます。開発者は差別化要因とならない作業の多くを排除することができ、古い言語バージョンからの移行に伴う作業を最大で数日から数か月分節約できます。 最新の機能で最適化するため Amazon Q Developer agent for code transformation を使用し、Unicorn Store API を Java 8 から Java 17 へアップグレードしてみましょう。IntelliJ IDE にて、Amazon Q チャットパネルに「/transform」と入力し、Amazon Q Developer がプロジェクトのアップグレードを開始するために必要な詳細情報を入力します。 Amazon Q Developer agent for code transformation は、既存のコードを自動的に分析し、変換計画を生成、計画に沿った変換タスクを完了します。その際、Spring、Spring Boot、JUnit、JakartaEE、Mockito、Hibernate、Log4j などの一般的なライブラリとフレームワークを、Java 17 と互換性のある最新のメジャーバージョンにアップグレードします。また、Java 17 の推奨事項に従って、廃止予定のコードコンポーネントを更新します。Amazon Q Developer agent によるコード変換を始めるには、 Amazon Q Developer Agent for code transformation による言語バージョンのアップグレード の手順を読み、それに従ってください。 変換が完了したら、変更を受け入れる前に、変換済みコードとビルド及びテスト結果を確認することができます。 コードベース上の技術的負債の削減 技術的負債は、時間の経過とともにどのコードベースにも蓄積されます。技術的負債の中には、期日を守るために受け入れざるを得ないものもありますが、後で返済するためにも追跡して優先順位を付けておく必要があります。管理されないままにしておくと技術的負債が重なり、より開発が遅くなり費用もかかります。技術的負債の削減は、チームの継続的な取り組みであるべきですが、他の優先事項によって後回しになることがよくあります。Amazon Q Developer は、技術的負債を特定して修正することで、レガシー Java コードのモダナイゼーションを効率化します。コードベース上の技術的負債の原因となる問題のリストを提供することで、コードの分析にかかる時間とリソースを削減します。これにより、ソフトウェア開発チームは技術的負債の項目に優先順位を付け、どの問題から最初に対処すべきかについて情報に基づいた決定を下すことができます。 Unicorn Store API で技術的負債のリストを見つけてみましょう。IntelliJ IDE では、Send to Prompt オプションを使用してハイライトされたコードを Amazon Q チャットパネルに送信し、すべての技術的負債のリストを提供するよう求めるプロンプトを表示します。Amazon Q Developer は、すべての技術的負債を詳細にリストします。 技術的負債を特定したら、次のステップはそれらを徐々に改善することです。Amazon Q Developer は、技術的負債を修復するためのコードの実装にかかる時間を短縮します。開発者は、IDE 内の Amazon Q Developer agent for software development とやり取りして、達成しようとしている特定のタスクに関するコードの提案について支援を受けることができます。プロジェクト全体のコードをコンテキストとして使用し、プロジェクト内のすべてのファイルに対して行う予定の実装計画を提供します。計画を確認し、内容に問題がなければ、Amazon Q Developer に提案された計画に基づいてコードを生成するよう依頼できます。これにより、手動更新と比べて開発者の労力を節約できます。 上記のステップで特定された Unicorn Store API の技術的負債について、Amazon Q Developer を使用してロギングの問題に対処してみましょう。IntelliJ IDE で Amazon Q のチャットパネルに「/dev」と入力し、ロギングの技術的負債の詳細を記入します。Amazon Q Developer は、プロジェクト全体のコンテキストに基づいて実装計画とログを追加するためのコードを生成します。Amazon Q Developer agent for software development の使用を開始するには、「 Amazon Q Developer agent for software development を使用してソフトウェアを開発する 」の手順を参照してください。 従来の Java コードをモダナイズするには、品質を段階的に向上させ、時間の経過とともに技術的負債が蓄積されないようにするための継続的なリファクタリングが必要です。Amazon Q Developer は、リファクタリング機能によってこの反復プロセスを簡素化します。選択したコードに対して、リファクタリングされたコードと各変更点、そのコーディング上の利点についての説明を提供してくれるため、変更点を理解するのに役立ちます。この機能の詳細については、「 Amazon Q Developer によるコードの説明と更新 」を参照してください。 この機能を活用して、Unicorn Store API プロジェクトの UnicornController クラスのメソッドを改良してみましょう。Amazon Q Developer は、更新後のレビューのために、可読性や効率性などの点でよりよいコードを生成します。 アプリケーションをクラウドネイティブ化して AWS にデプロイ モダナイゼーションの最終ステップは、アプリケーションをクラウドネイティブ化して AWS にデプロイすることです。クラウドネイティブとは、クラウドコンピューティング環境で最新のアプリケーションを構築、デプロイ、および管理するソフトウェアアプローチです。これらのテクノロジーは、サービス提供に影響を与えることなく、アプリケーションへの迅速かつ頻繁な変更をサポートし、企業に競争上の優位性をもたらします。Amazon Q Developer が Unicorn Store API プロジェクトのクラウドネイティブ化をどのように支援できるかを見てみましょう。 IntelliJ IDE で Amazon Q チャットを開き、プロジェクトをクラウドネイティブ化して AWS にデプロイするための推奨アプローチを提供するよう Amazon Q Developer に依頼します。 Amazon Q Developer がコードを分析し、このアプリケーションをクラウドネイティブ化する手順を詳しく説明します。詳細な手順には、アプリケーションのコンテナ化、 Amazon Elastic Container Service (Amazon ECS) などの AWS サービスへのコンテナアプリケーションのデプロイ、サーバーレス方式でコンテナを実行するための Fargate、コンテナイメージをプッシュするための Amazon Elastic Container Registry (Amazon ECR) 、 AWS Application Load Balancer (ALB) を介したアプリケーションへのアクセス、 モニタリング用の Amazon CloudWatch 、及び Amazon Virtual Private Cloud (VPC) やサブネットなどの関連サービスが含まれます。 Amazon Q Developer に、先程のチャットで会話した手順を実行するよう依頼しましょう。まず、Amazon Q Developer へアプリケーションをコンテナ化するための docker ファイルの作成を依頼してください。コンテナ化のプロセスでは、基盤となるハードウェアやその他の依存関係からソフトウェアを切り離すことで、アプリケーション開発を効率化します。このアプローチは、コンテナ化された環境内のさまざまなコンポーネントを分離することにより、開発スピード、効率、及びセキュリティを強化します。 コンテナベースのアプリケーションの開発に成功したら、Amazon Q Developer の機能を活用して AWS CloudFormation テンプレートを生成してみましょう。このテンプレートにより、コードとしてのインフラストラクチャ (IaC) を使用して必要なリソースを AWS にデプロイできるようになります。IaC を使うと、コンピューティングインフラストラクチャをプログラム的にプロビジョニングして管理できるため、手作業によるプロセスや設定が不要になります。手作業によるインフラストラクチャ管理は、特に大規模なアプリケーションを扱う場合、時間がかかり属人的な作業ミスも起こりやすくなります。 CloudFormation テンプレートを作成するために、これまでの会話から得た提案を見直し、AWS でプロビジョニングする必要があるリソースのリストをまとめましょう。このリストを作成したら、Amazon Q Developer にこれらのリソース要件に基づいて CloudFormation テンプレートを生成するよう依頼できます。 Amazon Q Developer は、コンテナを AWS へ安全で信頼性が高くスケーラブルな方法でデプロイするように、必要なすべてのリソースを含む CloudFormation テンプレートを生成できます。 CloudFormation テンプレートが用意できたので、Unicorn Store API のローカル docker イメージを Amazon ECR にプッシュし、AWS でアプリケーションを実行するために必要な Fargate タスクを開始しましょう。 このように Amazon Q Developer によって、クラウドにデプロイするステップを設計することでアプリケーションをクラウドネイティブ化したり、コンテナベースのソリューションに移行できるよう支援したり、アプリケーションを AWS にデプロイするための IaC のスクリプトを記述したりすることができます。 まとめ Amazon Q Developer を利用することで、開発者はレガシー Java アプリケーションのモダナイゼーションを簡素化および加速できます。また、開発者は古いアプリケーションを現在のフレームワークに適用し、クラウドネイティブな構成で AWS にデプロイできます。これによりプロセスが合理化され、必要な労力やリスクが軽減されます。開発者は時間とリソースを大幅に節約できるため、技術的負債を管理するよりも、新しい機能の構築とモダナイズされたアプリケーションの強化に集中できるようになります。 Amazon Q Developer の詳細については、以下のリソースを参照してください。 Amazon Q の使用を開始する Amazon Q Developer ユーザーガイド Amazon Q Developer agent for code transformation Amazon Q Developer agent for software development Amazon Q Developer の機能 Chetan Makvana Chetan Makvana は、アマゾンウェブサービスのシニアソリューションアーキテクトです。AWS のパートナーやお客様と協力して、スケーラブルなアーキテクチャを構築し、AWS サービスの運用を促進する戦略を実装するためのアーキテクチャガイダンスを提供しています。彼はテクノロジー愛好家であり、生成 AI、サーバーレス、DevOps に関連する分野を中核とするビルダーでもあります。仕事以外では、ショーの鑑賞、旅行、音楽を楽しんでいます。 Venugopalan Vasudevan Venugopalan Vasudevan は、アマゾンウェブサービスのシニアスペシャリストソリューションアーキテクトで、生成 AI サービスを専門としています。彼の専門は、お客様が Amazon Q や Amazon Bedrock などの最先端のサービスを活用して、開発プロセスを合理化し、イノベーションを加速し、デジタル変革を推進できるよう支援することです。Venugopalan は生成 AI をワークフローに統合することで、開発者がより効率的かつ創造的に作業できるよう、次世代の開発者体験を向上させることに専念しています。 Surabhi Tandon Surabhi Tandon は、アマゾンウェブサービスのシニアテクニカルアカウントマネージャーです。彼女は戦略的な技術ガイダンスを提供することで、お客様が優れたオペレーションを実現できるようサポートし、AWS へのクラウド移行を支援しています。Surabhi は生成 AI、自動化、DevOps に関心を持つビルダーです。仕事以外では、ハイキング、読書、家族や友人との時間を楽しんでいます。 この記事は、ソリューションアーキテクトの戸巻 健が翻訳を担当しました。

本稿は、2024 年 2 月 26 日に AWS Security Blog で公開された “ How to use Regional AWS STS endpoints ” を翻訳したものです。 このブログ記事では、グローバル (レガシー) AWS Security Token Service (AWS STS) エンドポイントで、可用性が担保できない場合の回復力の向上に役立つ推奨事項を提供しています。グローバル (レガシー) AWS STS エンドポイント https://sts.amazonaws.com の可用性は高いですが、米国東部 (バージニア北部) という単一の AWS リージョンでホストされており、他のエンドポイントと同様に、他のリージョンのエンドポイントへの自動フェイルオーバーは提供されていません。この投稿では、設定にリージョナル AWS STS エンドポイントを使用することで、ワークロードのパフォーマンスと耐障害性を向上させる方法を紹介します。 認証には、認証情報の不注意による開示、共有、盗難などのリスクを減らすために、長期間の認証情報の代わりに 一時的な認証情報 を使用するのが最善です。AWS STS を使用すると、信頼できるユーザーは、権限が制限された一時的な認証情報をリクエストして、 AWS リソースにアクセスできます 。 一時的な認証情報には、アクセスキーペアとセッショントークンが含まれます。アクセスキーペアは、アクセスキー ID とシークレットキーで構成されています。AWS STS は一時的な認証情報を動的に生成し、要求に応じてユーザーに提供します。これにより、長期間の保管が不要になります。一時的な認証情報には有効期間が限られているため、管理したりローテーションしたりする必要はありません。 これらの認証情報を取得するには、いくつかの方法があります。 ロール、ユーザー、サービスなどの AWS プリンシパル 外部 ID プロバイダー の SAML を使用したフェデレーション OAuth 2.0 や OpenID Connect (OIDC) アプリケーションによって提供されるようなウェブトークン 図 1: AWS STS に認証情報をリクエストする方法 グローバル (レガシー) とリージョナル AWS STS エンドポイント AWS のサービスにプログラムから接続するには、エンドポイントを使用します。 エンドポイント は、AWS STS のエントリポイントの URL です。 AWS STS は、すべてのリージョンにリージョナル AWS STS エンドポイントを提供します。AWS は当初、米国東部 (バージニア北部) リージョン ( us-east-1 ) でホストされているグローバル AWS STS エンドポイント (現在はレガシー) https://sts.amazonaws.com を使用して AWS STS を構築しました。リージョナル AWS STS エンドポイントは、AWS アカウントの中で デフォルトで有効になっているリージョン では、デフォルトで有効になっています。たとえば、 https://sts.ap-northeast-1.amazonaws.com はアジアパシフィック (東京) のリージョナル AWS STS エンドポイントです。デフォルトでは、AWS サービスはリージョナル AWS STS エンドポイントを使用します。たとえば、 IAM Roles Anywhere は、 トラストアンカー に対応するリージョナル AWS STS エンドポイントを使用します。各リージョンの AWS STS エンドポイントの完全なリストについては、「 AWS Security Token Service エンドポイントとクォータ 」を参照してください。リージョンが無効になっている場合は、AWS STS エンドポイントをアクティブ化することはできません。デフォルトでアクティブ化される AWS STS エンドポイントと、アクティブ化または非アクティブ化できるエンドポイントの詳細については、「 リージョンとエンドポイント 」を参照してください。 前述のように、グローバル (レガシー) AWS STS エンドポイント https://sts.amazonaws.com は、米国東部 (バージニア北部) という単一のリージョンでホストされており、他のエンドポイントと同様に、他のリージョンのエンドポイントへの自動フェイルオーバーは提供されていません。AWS または AWS 外のワークロードがグローバル (レガシー) AWS STS エンドポイント https://sts.amazonaws.com を使用するように設定されている場合は、米国東部 (バージニア北部) という単一のリージョンに依存することになります。万が一、そのリージョンでエンドポイントが使用できなくなったり、リソースとそのリージョンの間の接続が失われたりした場合、ワークロードは AWS STS を使用して一時的な認証情報を取得できなくなり、ワークロードに可用性のリスクが生じます。 AWS では、グローバル (レガシー) AWS STS エンドポイントではなく、リージョナル AWS STS エンドポイント ( https://sts. <リージョン名> .amazonaws.com ) を使用することを推奨しています。 回復力の向上に加えて、リージョナル AWS STS エンドポイントには他の利点もあります。 隔離と封じ込め — ワークロードと同じリージョンのリージョナル AWS STS エンドポイントにリクエストを送信することで、リージョン間の依存関係を最小限に抑え、リソースの範囲を一時的な認証情報の範囲に合わせて、可用性とセキュリティ上の懸念に対処できます。たとえば、ワークロードがアジアパシフィック (東京) リージョンで実行されている場合、アジアパシフィック (東京) リージョン ( ap-northeast-1 ) のリージョナル AWS STS エンドポイントをターゲットにして、他のリージョンへの依存関係を削除できます。 パフォーマンス — サービスやアプリケーションに近いエンドポイントにAWS STS リクエストを送信することで、より低いレイテンシーと短い応答時間で AWS STS にアクセスできます。 図2は、一時的な認証情報のセットを返すAWS STS AssumeRole API を呼び出すことで、AWS のプリンシパルが AWS Identity and Access Management (IAM) ロールを引き受けるプロセスを示しています。 図2: リージョナル AWS STS エンドポイントを使用して API を呼び出し、IAM ロールを引き受ける 同じリージョン内のリージョナル AWS STS への呼び出し 特定のリージョン内のワークロードを、そのリージョンのリージョナル AWS STS エンドポイントのみを使用するように設定する必要があります。リージョナル AWS STS エンドポイントを使用すると、ワークロードと同じリージョンで AWS STS を使用でき、リージョン間の依存関係がなくなります。たとえば、アジアパシフィック (東京) リージョンのワークロードは、リージョナルエンドポイント https://sts.ap-northeast-1.amazonaws.com のみを使用して AWS STS を呼び出す必要があります。リージョナル AWS STS エンドポイントにアクセスできなくなった場合、ワークロードは運用リージョン外のリージョナル AWS STS エンドポイントを呼び出すべきではありません。ワークロードにマルチリージョンの耐障害性要件がある場合、他のアクティブリージョンまたはスタンバイリージョンは、 そのリージョンのリージョナルAWS STSエンドポイントを使用 し、リージョンに障害が発生してもアプリケーションが機能するようにデプロイする必要があります。STSへのトラフィックは、 他のリージョンから隔離された独立した 同じリージョン内のリージョナル STS エンドポイントに送り、グローバル (レガシー) AWS STS エンドポイントへの依存関係を削除する必要があります。 AWS の外部から AWS STS への呼び出し AWS 外のワークロードは、AWS 外にあるワークロードのレイテンシーが最も低い適切なリージョナル AWS STS エンドポイントを呼び出すように設定する必要があります。ワークロードにマルチリージョンの耐障害性要件がある場合は、リージョナル AWS STS エンドポイントにアクセスできなくなった場合に備えて、他のリージョンのリージョナル AWS STS エンドポイントへのフェイルオーバーロジックを構築してください。リージョナル AWS STS エンドポイントから取得した一時的な認証情報は、デフォルトの セッション期間 、または指定した期間の間、 全てのリージョンで有効 です。 AWS CLI や SDK でリージョナル AWS STS エンドポイントを設定する方法 AWS STS API を呼び出すには、 AWS コマンドラインインターフェイス (CLI) または AWS SDK の最新のメジャー バージョン を使用することをお勧めします。 AWS CLI デフォルトでは、 AWS CLI バージョン 2 は、現在設定されているリージョンのリージョナル AWS STS エンドポイントに AWS STS API リクエストを送信します。AWS CLI v2 を使用している場合は、追加の変更を加える必要はありません。 AWS CLI v1 は、デフォルトでは AWS STS リクエストをグローバル (レガシー) AWS STS エンドポイントに送信します。使用している AWS CLI のバージョンを確認するには、次のコマンドを実行します。 $ aws --version AWS CLI コマンドを実行すると、AWS CLI は 特定の順序 で認証情報の設定を探します。最初はシェルの環境変数で、次にローカルの AWS 設定ファイル ( ~/.aws/config ) の設定を探します。 AWS SDK AWS SDK は、 さまざまなプログラミング言語 と環境で利用できます。2022 年 7 月以降、AWS SDK の主要な新バージョンはデフォルトでリージョナル AWS STS エンドポイントに設定され、現在設定されているリージョンに対応するエンドポイントを使用します。2022 年 7 月以降にリリースされた AWS SDK のメジャーバージョンを使用する場合は、追加の変更を加える必要はありません。 AWS SDKは、認証情報の設定値が見つかるまで、さまざまな 設定場所 を探します。たとえば、AWS SDK for Python ( Boto3 ) は、ソースを介して設定値を探す場合、次の探索順序に従います。 SDK のクライアント作成時に、AWS 設定パラメータとして渡される設定オブジェクト 環境変数 AWS 設定ファイル ~/.aws/config まだ AWS CLI v1 を使用している場合、または AWS SDK バージョンがデフォルトでリージョナル AWS STS エンドポイントに設定されていない場合は、以下のオプションでリージョナル AWS STS エンドポイントを設定できます。 オプション1 — 共有の AWS 設定ファイルを使用する AWS 設定ファイル は、LinuxまたはmacOSでは ~/.aws/config にあり、 Windows では C:\Users\USERNAME\.aws\config にあります。リージョナル AWS STS エンドポイントを使用するには、 sts_regional_endpoints パラメータを追加してください。 次の例は、AWS 設定ファイルのデフォルトプロファイルを使用して、アジアパシフィック (東京) リージョン ( ap-northeast-1 ) のリージョナル AWS STS エンドポイントの値を設定する方法を示しています。 [default] region = ap-northeast-1 sts_regional_endpoints = regional AWS STS エンドポイントパラメータ ( sts_regional_endpoints ) の有効値は次のとおりです。 legacy — グローバル (レガシー) AWS STSエンドポイント sts.amazonaws.com を使用します。 regional — 現在設定されているリージョンのリージョナル AWS STS エンドポイント sts. <リージョン名> .amazonaws.com を使用します。 注: 2022 年 7 月以降、AWS SDK の主要な新バージョンはデフォルトでリージョナル AWS STS エンドポイントに設定され、現在設定されているリージョンに対応するエンドポイントを使用します。AWS CLI v1 を使用している場合、AWS STS エンドポイントパラメータを使用するにはバージョン 1.16.266 以降を使用する必要があります。 AWS CLI コマンドで --debug オプションを使用すると、デバッグログを受け取り、どの AWS STS エンドポイントが使用されたかを検証できます。 $ aws sts get-caller-identity \ > --region ap-northeast-1 \ > --debug デバッグログで useGlobalEndpoint を検索すると、 useGlobalEndpoint パラメータが False に設定されていることがわかります。共有 AWS 設定ファイルまたは環境変数でリージョナル AWS STS エンドポイントが設定されている場合は、リージョナル AWS STS エンドポイントプロバイダーの完全修飾ドメイン名 (FQDN) が表示されます。 2024-09-05 12:14:12,870 - MainThread - botocore.regions - DEBUG - Calling endpoint provider with parameters: {'Region': 'ap-northeast-1', 'UseDualStack': False, 'UseFIPS': False, 'UseGlobalEndpoint': False} 2024-09-05 12:14:12,871 - MainThread - botocore.regions - DEBUG - Endpoint provider result: https://sts.ap-northeast-1.amazonaws.com リージョナル AWS STS エンドポイントの共有 AWS 設定ファイル設定をサポートする AWS SDK のリストについては、「 AWS SDK との互換性 」を参照してください。 オプション2 — 環境変数を使用する 環境変数 は、認証情報の設定を指定する別の方法を提供します。環境変数は、シェルセッション内でグローバルに AWS サービスへの呼び出しに影響します。ほとんどの SDK は環境変数をサポートしています。環境変数を設定すると、SDK はシェルセッションが終了するまで、または変数を別の値に設定するまで、その値を使用します。変数を今後のセッションでも維持するには、シェルの起動スクリプトで変数を設定します。 次の例は、環境変数を使用してアジアパシフィック (東京) リージョン ( ap-northeast-1 ) のリージョナル AWS STS エンドポイントの値を設定する方法を示しています。 Linux または macOS $ export AWS_DEFAULT_REGION=ap-northeast-1 $ export AWS_STS_REGIONAL_ENDPOINTS=regional 以下のコマンドを実行して、環境変数を確認できます。 $ (echo $AWS_DEFAULT_REGION; echo $AWS_STS_REGIONAL_ENDPOINTS) 出力は次のようになります。 ap-northeast-1 regional Windows C:\> set AWS_DEFAULT_REGION=ap-northeast-1 C:\> set AWS_STS_REGIONAL_ENDPOINTS=regional 次の例は、環境変数を設定して、 AWS SDK for Python (Boto3) で STS クライアント がリージョナル AWS STS エンドポイントを使用するように設定する方法を示しています。 import boto3 import os os.environ["AWS_DEFAULT_REGION"] = "ap-northeast-1" os.environ["AWS_STS_REGIONAL_ENDPOINTS"] = "regional" メタデータ属性 sts_client.meta.endpoint_url を確認して、STS クライアントがどのように構成されているかを調べたり、検証したりできます。出力は次のようになります。 >>> sts_client = boto3.client("sts") >>> sts_client.meta.endpoint_url 'https://sts.ap-northeast-1.amazonaws.com' リージョナル AWS STS エンドポイントの環境変数設定をサポートする AWS SDKのリストについては、「 AWS SDK との互換性 」を参照してください。 オプション 3 — エンドポイント URL を指定する 特定のリージョナル AWS STS エンドポイントのエンドポイント URL を手動で指定することもできます。 次の例は、特定のエンドポイント URL を設定することで、AWS SDK for Python (Boto3) で STS クライアント がリージョナルの AWS STS エンドポイントを使用するように設定する方法を示しています。 import boto3 sts_client = boto3.client('sts', region_name='ap-northeast-1', endpoint_url='https://sts.ap-northeast-1.amazonaws.com') AWS STS で VPC エンドポイントを使用する Amazon VPC にデプロイしたリソースから、AWS STS へのプライベート接続を作成できます。AWS STS は、 インターフェイス VPC エンドポイント を使用して AWS PrivateLink と統合します。AWS PrivateLink の ネットワークトラフィック は、 グローバルAWSネットワークのバックボーン にとどまり、パブリックインターネットを経由しません。AWS STS の VPC エンドポイントを設定すると、リージョナル AWS STS エンドポイントのトラフィックはその VPC エンドポイントを使用して通信を行います。 デフォルトでは、VPC の DNS はリージョナル AWS STS エンドポイントのエントリを更新して、VPC 内の AWS STS の VPC エンドポイントのプライベート IP アドレスに解決します。 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上で実行した以下のコマンドの結果は、AWS STS エンドポイントの DNS 名が、AWS STS の VPC エンドポイントのプライベート IP アドレスに解決されることを示しています。 [ec2-user@ip-10-120-136-166 ~]$ nslookup sts.ap-northeast-1.amazonaws.com Server: 10.120.0.2 Address: 10.120.0.2#53 Non-authoritative answer: Name: sts.ap-northeast-1.amazonaws.com Address: 10.120.138.148 使用しているリージョンで AWS STS の インターフェイス VPC エンドポイントを作成 したら、同じリージョンの AWS STS にアクセスするために、環境変数を使用してそれぞれのリージョナル AWS STS エンドポイントの値を設定します。 次のログの出力は、リージョナル AWS STS エンドポイントに対して AWS STS 呼び出しが行われたことを示しています。 POST / content-type:application/x-www-form-urlencoded; charset=utf-8 host:sts.ap-northeast-1.amazonaws.com AWS STS リクエストのログ AWS CloudTrail イベントを使用して、 AWS STS に使用されたリクエストとエンドポイントに関する情報を取得できます 。この情報は、AWS STS のリクエストパターンを特定し、グローバル (レガシー) STS エンドポイントをまだ使用しているかどうかを確認するのに役立ちます。 CloudTrail のイベントは、AWS アカウントでのアクティビティの記録です。CloudTrail イベントは、 AWS マネジメントコンソール 、AWS SDK、コマンドラインツール、その他の AWS サービスを通じて行われた API と非 API の両方のアクティビティの履歴を提供します。 ログの場所 リージョナル AWS STS エンドポイント https://sts. <リージョン名> .amazonaws.com へのリクエストは、それぞれのリージョン内のCloudTrailに記録されます。 グローバル (レガシー) AWS STS エンドポイント sts.amazonaws.com へのリクエストは、米国東部 (バージニア北部) リージョン ( us-east-1 ) に記録されます。 ログフィールド リージョナル AWS STS エンドポイントとグローバル (レガシー) AWS STS エンドポイントへのリクエストは、CloudTrail の tlsDetails フィールドに記録されます。このフィールドを使用して、リクエストがリージョナル AWS STS エンドポイントに送信されたのか、グローバル (レガシー) AWS STS エンドポイントに対して行われたのかを判断できます。 VPC エンドポイントからのリクエストは、CloudTrail の vpcEndpointId フィールドに記録されます。 次の例は、VPC エンドポイントを持つリージョナル AWS STS エンドポイントへの STS リクエストの CloudTrail イベントを示しています。 "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "vpcEndpointId": " vpce-021345abcdef6789" ", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.2", "cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256", "clientProvidedHostHeader": " sts.ap-northeast-1.amazonaws.com " } 次の例は、グローバル (レガシー) AWS STS エンドポイントへの STS リクエストの CloudTrail イベントを示しています。 "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.2", "cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256", "clientProvidedHostHeader": " sts.amazonaws.com " } AWS STSのログデータをインタラクティブに検索して分析するには、 Amazon CloudWatch Logs Insights または Amazon Athena を使用してください。 Amazon CloudWatch Logs Insights 次の例は、CloudWatch Logs Insightsクエリを実行して、グローバル (レガシー) AWS STS エンドポイントに対して行われた API 呼び出しを探す方法を示しています。CloudTrail イベントをクエリする前に、 CloudWatch Logs にイベントを送信する ように CloudTrail の証跡を設定する必要があります。 filter eventSource="sts.amazonaws.com" and tlsDetails.clientProvidedHostHeader="sts.amazonaws.com" | fields eventTime, recipientAccountId, eventName, tlsDetails.clientProvidedHostHeader, sourceIPAddress, userIdentity.arn, @message | sort eventTime desc クエリ出力には、グローバル (レガシー) AWS STS エンドポイント https://sts.amazonaws.com に対して行われた AWS STS 呼び出しのイベントの詳細が表示されます。 図 3: CloudWatch Logs Insights のクエリを使用して STS API 呼び出しを検索します Amazon Athena 次の例は、Amazon Athena で CloudTrail イベントをクエリし、グローバル (レガシー) AWS STS エンドポイントに対して行われた API 呼び出しを検索する方法を示しています。 SELECT eventtime, recipientaccountid, eventname, tlsdetails.clientProvidedHostHeader, sourceipaddress, eventid, useridentity.arn FROM "cloudtrail_logs" WHERE eventsource = 'sts.amazonaws.com' AND tlsdetails.clientProvidedHostHeader = 'sts.amazonaws.com' ORDER BY eventtime DESC クエリ出力には、グローバル (レガシー) AWS STS エンドポイント https://sts.amazonaws.com に対して行われた STS 呼び出しが表示されます。 図 4: Athena を使用して STS API 呼び出しを検索し、STS エンドポイントを特定します まとめ この投稿では、リージョナル AWS STS エンドポイントを使用して、AWS で使用しているリージョンの回復力を高め、レイテンシーを減らし、セッショントークンの有用性を向上する方法を学びました。 環境内の AWS STS エンドポイントの設定と使用状況を確認し、CloudTrail ログで AWS STS のアクティビティを検証し、リージョナル AWS STS エンドポイントが使用されていることを確認することをおすすめします。 質問がある場合は、 セキュリティ、アイデンティティ、コンプライアンスの re:Post トピックに投稿するか、 AWS サポート に連絡してください。 著者について Darius Januskis は AWS の Senior Solutions Architect で、世界中の金融サービスを提供しているお客様のクラウドへの移行を支援しています。彼は情熱的なテクノロジー愛好家で、お客様と協力し、well-architected なソリューションを構築できるよう支援することを楽しんでいます。彼の関心事には、セキュリティ、DevOps、自動化、サーバーレステクノロジーが含まれます。   翻訳はクラウドサポートエンジニアの森永が担当し、大金がレビューしました。

年に 1 度の International Broadcasting Convention (IBC) が目前に迫る中、Amazon Web Services (AWS) は、人工知能 (AI) からライブクラウドプロダクションソリューションまでの最新のメディア & エンターテインメント (M&E) の革新を披露する準備を整えています。9 月 13 日から 16 日まで、RAI の Hall 5 にある二階建ての AWS ブース (5.C90) で会議やデモを行うだけでなく、NVIDIA と協力して Hall 14 の Innovation Village と IBC AI Tech Zone のスポンサーも務めます。 参加される方々は、9 月 14 日 (土) に Hall 8 で、業界をリードする識者による 1 日の啓発的なセッションにも参加できるほか、イベント期間中に AWS が協賛するその他のイベントにも参加できます。 IBC 期間中に AWS 専門家との会議をリクエストするには、 こちらからお問い合わせ ください。また、AWS のサービス、ソリューション、パートナーの出展場所については、以下のリストをご確認ください。 特別なイベント AWS Women in M&E Mixer : AWS は再び 9 月 13 日 (金) の 17:45 から 19:30 に、アムステルダムの Soho House で交流イベントを主催します。会話のテーマは、M&E 業界でのルールを書き換えていく女性リーダーについてです。まだ参加登録していない方は、 こちらからご登録 ください。 IBC Showcase Theater : AWS のセッションが、 9 月 14 日 (土) に Hall 8、スタンド A01 の IBC Showcase Theater の中央ステージで開催されます。 当日は 7 つのセッションが予定されており、生成 AI、収益化、ライブクラウドプロダクション、スポーツ、没入型の体験、ゲームなどをテーマとしています。NBCUniversal、Formula 1、Sky などのお客様にご参加いただきます。 IBC Keynote – Building a future-ready tech stack for an evolving media landscape :   9 月 14 日 (土) 10:00 から 11:00 に、Vice President of Prime Video & Amazon MGM Studios Technology の Girish Bajaj がカンファレンスルーム 1 でインサイトを交えた講演を行い、メディア・放送業界向けの適切な基盤テクノロジーの構築方法について解説します。 主な見どころ IBC 2024 では、AWS は 50 件のデモを展示し、AWS ブースで 60 社のパートナーを紹介します。デモでは、コンテンツの制作、配信、および収益化のための主要な M&E ワークロードをハイライトし、そのうち半分以上が AWS の生成 AI 技術を活用しています。ブースを訪れた方は、 Amazon Bedrock 、 Amazon Q 、 PartyRock アプリケーションを紹介する専用ポッドをご覧いただけます。 ブースに訪れた方は、制作現場の専門家に馴染みのある見た目、オーディオ、スクリーンを備えた実際の編集施設を模した、インタラクティブな編集およびカラーグレーディングスイートを探索することもできます。 拡大された Builder Zone では、参加者が AWS ソリューションを技術的に深く理解し、実験することができます。 AWS Elemental サービス、AWS ストレージサービス ( Amazon S3 、 Amazon S3 Glacier 、 Amazon FSx ) および Amazon GameLift 、さらには AWS の生成 AI サービスと Amazon Personalize を実際に体験できます。 IBC 全体に広がる生成 AI AWS は 5.C90 のブースで 29 の生成 AI デモを提供しているほか、NVIDIA とともに Hall 14 のブース A13 にイノベーションビレッジを出展しています。このビレッジでは、AWS 上の生成 AI サービスおよびソリューションを使用している共有パートナーとその実績が紹介されます。参加者はデモポッドを見て回ったり、AWS のお客様やパートナーによるシアター形式のプレゼンテーションを見ることができます。また、クラウドを使用して 8K や没入型のコンテンツをライブまたは事前に録画したものを制作できるワークフローも体験できます。会場では、対話型の AI を使用して絵を描く「Sir Martian」という名の動く人形ロボットとも会話できます。 さらに、AWS は Hall 14 の IBC の AI Tech Zone (AIA01 ブース) の共同スポンサーになっています。 この特設エリアでは、AI の有識者、ソリューションプロバイダー、クリエイターにスポットライトを当てます。 IBC で AWS とつながる IBC 2024 の日程を立てる際には、必ずブース番号 5.C90 を訪れ、M&E ワークフローのためのクラウド技術の最新のイノベーションをご覧ください。エキスパートとお話しいただき、放送ワークロードを最大限の俊敏性、弾力性、拡張性、信頼性をもって実行し、ダイレクト・トゥ・コンシューマーおよびストリーミングワークロードのためのイノベーションを加速させる新しい方法を見つけていただきたいと思います。 AWS チームは、広告収益の最大化、顧客エンゲージメントの促進、生成 AI の活用、高品質のコンテンツ配信を維持しつつコンテンツ配信コスト削減など、さまざまな点でガイダンスを提供できます。 最新情報については AWS IBC 2024 イベントページ をご覧ください。 AWS at IBC 参加者ガイド をダウンロードしたり、 LinkedIn の AWS for M&E をフォローしてください。 翻訳はソリューションアーキテクトの加藤・石井が担当しました。 原文は こちら をご覧ください。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先:  awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

メディア & エンターテインメント (M&E) 業界は、消費者の期待の変化、競合するストリーミングプラットフォームの台頭、データ駆動型のインサイトの重要性の高まりによって大きな変革を経験しています。コンテンツライブラリーが 継続的に拡大するつれ、多くのメディア企業は、貴重な既存コンテンツ資産をクラウドに移行する必要性を認識しています。そうすることで、持続可能なビジネス成長の機会、サプライチェーン業務の最適化、消費者エクスペリエンスの向上を実現できます。 IBC 2024 で Amazon Web Services (AWS) は、M&E 企業の業界変革を支援する 6 つの実例を紹介する予定です。コンテンツ移行と収益化にむけた自動化、クラウドベースのオーケストレーションワークフロー、高度なローカライゼーション機能など、業界が直面する最も重要な課題に対するソリューションのデモ展示を行います。 AWS メディアワークロードのデモは IBC 5.C90 ブースでご覧ください。 アーカイブの移行 ローコードでのワークフロー自動化 AWS 上のニュースルームとデイタイムクラウド制作 メディアのためのデータレイクとメタデータレイク インテリジェント QC とサステナビリティ コンテンツのローカライゼーションとアクセシビリティ Migrate to monetize : 収益化に向けた移行 メディアアーカイブには貴重な知的財産が含まれていますが、多くのメディア企業は、膨大なライブラリの動画、オーディオ、テキストベースのコンテンツを効果的に収益化することに苦慮しています。「Migrate to monetize：収益化に向けた移行」ではシームレスな移行から収益化までのクラウドベースのワークフローを実現するために、AWS のサービスとパートナーソリューションを統合したデモを実演予定です。 このワークフローは、コンテンツを AWS に移行することから始まります。ローコード/ノーコードのソリューションにより、オペレーションチームがオーケストレーションを修正可能です。移行したコンテンツ、メタデータは、複数の分散したビジネスユニットがアクセスできるアセット管理システムに格納されます。 Demonstration: Archive Migration: Unlock the hidden value in your content archives：アーカイブ移行: コンテンツアーカイブの隠された価値を解き放つ このデモンストレーションは、データをクラウドに移行するための Cloudfirst の archive migration as a service (AMaaS) からスタートします。AMaaS は、コンテンツを次世代のデジタルアーカイブに移行するための効率的で低リスクな方法です。次に、 PwC の AI 駆動のアノテーションソリューションが、AWS の大規模言語モデル (LLM) を活用して、権利契約から条件と規定を抽出することで、契約を digital intelligence に変換します。 Media2Cloud on AWS は、クラウドへのメディアアセットの移行プロセスを簡素化します。Media2Cloud で、コアメタデータの抽出を自動化し、インテリジェントな要約を生成することで、アーカイブされたメディアの収益化の可能性を引き出すことが可能になります。 Rightsline の包括的な権利プラットフォームにより、コンテンツライブラリの追跡、管理、収益化 が可能になります。Vidinet メディア管理エンジンは、 Vidispine から提供され、移行したアセットを制作およびディストリビューション用途に整理・インデックス化します。 Vubiquity の MetaVu は、メタデータ管理を簡素化し、さまざまな標準フォーマットと 2,000 を超えるディストリビューションエンドポイントをサポートし、コンテンツの検索性と業務効率を向上させます。 これらのソリューションを組み合わせることで、インテリジェントなメタデータ抽出、先進的なアナリティクス、ターゲットを絞ったコンテンツ配信を活用し、メディアアーカイブからの新たな収益機会を特定できます。 Demonstration:Low-Code Workflow Automation: Streamline content production and distribution：ローコード でのワークフロー自動化: コンテンツ制作とディストリビューションを合理化する このデモンストレーションでは、4 つのパートナーソリューションにわたるローコードによるワークフロー自動化を紹介します。 ローコード/ノーコード のプラットフォームにより、ユーザーは最小限のコーディングで独自のアプリケーションを構築・展開できるため、技術チーム以外のチームでもワークフローを最適化しやすくなります。 デモンストレーションでは、アセットのライフサイクルを案内し、制作済みのマスターファイルから始まります。インテリジェント品質管理 (QC) を活用して、ワークフローは高度な QC チェックを実行し、コンテンツが技術仕様と編集基準を満たしていることを確認できます。 Embrace Pulse-IT のローコードプラットフォームは、このワークフローのための高度な自動化、オーケストレーション、コラボレーション機能を提供し、 Codemill Accurate.Video プレーヤーを使用して QC の例外をタイムドメタデータを使用してレビューできます。 QC 分析が成功すると、コンテンツは C2PA 仕様で署名され、デジタルメディアの出所と整合性を認証します。 Veritone の Digital Media Hub は、AI 駆動のコンテンツ最適化、収益化、シンジケーション向けソリューションで、ビジネス間 (B2B) のコンテンツ取得ポータルで販売用にコンテンツをパッケージ化します。 ご来場いただくお客様には、制作からディストリビューションまでのエンドツーエンドのスケーラブルなワークフローをご確認いただけます。これにより、メディアチームは創造性とエディトリアルの取り組みに集中しつつ、オペレーションの効率化と出荷までの時間の短縮を実現できます。 Demonstration: Newsroom and Daytime Cloud Production on AWS: Enable cost-effective live and file-based workflows：AWS 上でのニュースルームとデイタイムクラウド制作: コストパフォーマンスの高いライブとファイルベースのワークフローの実現 ニュース放送局やメディア組織にとって、魅力的で、費用対効果の高いデイタイムのプログラムを提供することが、ますます重要になっています。AWS は、ライブクラウド拠点からファイナルプログラム配信までのニュースルームと制作のライフサイクル全体にわたる、エンドツーエンドのクラウドソリューションを紹介します。 ご来場いただくお客様には、 Amazon Elastic File System (Amazon EFS)、 Amazon FSx for Windows File Server、 Amazon Simple Storage Service (Amazon S3)、 Amazon Elastic Compute Cloud (Amazon EC2) などの AWS サービスが、シームレスで、クラウドによるデイタイムの番組やニュースルームの制作ワークフローを可能にするための AWS パートナーソリューションとどのように統合されているかご確認いただけます。主なパートナーには、Production Asset Management (PAM) に Mimir 、Newsroom Control System (NRCS) に Dina 、cloud-based editing に Cuttingroom 、CG と virtual studio integrationに Vizrt 、高度な編集ニーズに向けた Adobe Premiere が含まれます。 AWS のスケーラビリティ、信頼性、コストパフォーマンスを活用することで、メディア企業は、変化するコンテンツ需要や視聴者の好みに迅速に対応できる柔軟なクラウドベースの制作環境を構築できます。このデモンストレーションでは、ライブおよびファイルベースのワークフローを合理化し、オペレーションコストを削減、オンプレミスの容量制限を軽減しつつ、高品質のデイタイムおよびニュースルーム番組を配信する方法をご紹介いたします。 Media insights, search, and analysis：メディアのインサイト、検索、分析 現在のデータ駆動型なメディア業界において、包括的なコンテンツ戦略を構築するには、カスタムメタデータを統合、分析、実行可能なインサイトを抽出する必要があります。AWS は、そのサービスとパートナーソリューションを活用して、先進的なメディアインテリジェンス機能を実現し、コンテンツクリエイター、ディストリビューター、マーケッターの意思決定に役立つデータを活用できるようにしています。 Demonstration: Data Lake for Media and Metadata Lake: Unlock the power of consolidated data strategies: メディアとメタデータのデータレイク: 統合されたデータ戦略の力を引き出す このソリューションのコアは、ビジネスインテリジェンス機能を提供する Amazon QuickSight 、業界データフィードを提供する AWS Data Exchange 、リアルタイムデータストリーム処理を行う Amazon Kinesis 、データ統合および ETL に利用する AWS Glue 、メディア資産からのメタデータを自動抽出する Media2Cloud on AWS を統合したものです。 Twelve Labs や IMDb などの業界リーダーとのパートナーシップにより、AWS は、最先端の自然言語処理、コンピュータービジョン、マルチモーダル検索機能を活用して、コンテンツライブラリから豊富なインサイトを引き出す方法をデモします。ビジターは、制作からディストリビューションまでのメディアサプライチェーン全体で、シームレスなコンテンツ検索、メディアの重複排除、ターゲティングされたマーケティングキャンペーン、データ駆動の意思決定を可能にする、中央集約されたデータ戦略を設計する方法をご確認いただけます。 Localization, accessibility, and compliance：ローカライゼーション、アクセシビリティ、コンプライアンス メディアコンテンツを世界中の視聴者に届けるために、ローカライゼーション、アクセシビリティ、進化する規制への準拠を確保することが不可欠になっています。AWS は、従来の技術的な QC (Quality Control) を超えて、言語、アクセシビリティ、コンテンツ認証要件に対処するマルチベンダーの QC ワークフローを紹介します。 Demonstration: Intelligent QC & Sustainability: Comprehensive Global Content QC：インテリジェント QC とサステナビリティ: 包括的なグローバルコンテンツ QC コンテンツの品質、コンプライアンス、出所の保証は、コンテンツディストリビューターにとって非常に重要です。「インテリジェント QC」は、従来の技術的チェックを超えて、コンテンツ検証要件の複雑性の高まりに対応する包括的な QC ワークフローです。AWS サーバーレスサービスとパートナーソリューションを統合することで、このデモンストレーションは、メディア企業が QC プロセスをシームレスにスケールし、最高水準の QC とサステナビリティを維持する方法を示します。 ご来場いただくお客様には、ビデオ、言語、コンプライアンスなど、包括的なチェックを実行するための、Media2Cloud on AWS と Venera Quasar 、 Spherex AI などのパートナーソリューションを統合したマルチベンダーの QC ワークフローを紹介いたします。この QC ソリューションは、コンテンツの法令順守要件の高度化に対応するためにスケールすることができます。これには、地域の規制への準拠チェックや、European Corporate Sustainability Reporting Directive (CSRD) に基づく炭素排出の報告なども含まれます。 このワークフローの鍵は、Apptek の高度な言語 AI 機能を含む AWS パートナーテクノロジーの統合です。技術的 QC と、このようなコンテキストおよびコンプライアンスに重点を置いたチェックを組み合わせることで、メディア企業はコンテンツが世界中の視聴者と規制当局が期待する厳格な品質基準を満たしていることを確認できます。 Demonstration: Content Localization & Audience Accessibility: Ensure global reach and regulatory adherence: コンテンツのローカライゼーション & オーディエンスアクセシビリティ: グローバルな浸透と規制順守を確保する メディア企業がグローバルへ市場を広げるにつれ、国際市場向けのコンテンツのローカライズや、障害を持つ視聴者のアクセシビリティを改善することの重要性が高まっています。AWS は、コンテンツの長さ、レーティング、地域別の分類を特定するためのサービスとパートナーソリューションを提供しています。 このデモンストレーションでは、ローカル言語への翻訳や聴覚障害者向けの字幕、音声解説、視覚サインの生成など、コンテンツへのアクセシビリティを向上させるためのガイダンスをご紹介いたします。このガイダンスは、アクセシビリティ基準に対処するのに役立ちます。 ローカライゼーションとアクセシビリティのワークフローでは、 AWS Step Functions と AWS Lambda を使ってプロセスステップをオーケストレーションしています。 AudioShake Dialogue、Music、& Effects Separation によるオーディオトラックの分離、 DeepDub Go による AI 駆動のダビングと言語翻訳など、注目のパートナーが含まれています。AWS サービスと AWS パートナーソリューションを統合することで、メディア企業は、多様な世界中の視聴者の要件を満たし、アクセシビリティ規制に準拠しながら、コンテンツを効率的にグローバル展開できるようになります。 おわりに コンテンツアーカイブの隠れた価値を引き出したい、制作プロセスを合理化したい、世界中の視聴者にとってよりアクセスしやすくローカライズされたコンテンツを提供したい、などのニーズに対し、AWS は包括的なサービスとパートナーソリューションをご提供いたします。クラウドのスケーラビリティ、信頼性、コストパフォーマンスを活用することで、メディア企業は、変化する市場のニーズと視聴者の好みに迅速に対応できる柔軟なデータ駆動型のメディアサプライチェーンとアーカイブのエコシステムを構築可能です。 IBC 2024 の AWS スタンド 5.C90 で、これらのデモンストレーションを実際に体験してください。AWS メディアサプライチェーンとアーカイブチームとの 面談をスケジュール するか、AWS 担当者に連絡して詳細をご確認ください。一緒に、進化するメディア業界の中で、どのようにAWSがお客様の組織の成長を後押しするのかを探求しましょう。 アムステルダムでお会いできることを楽しみにしています! 翻訳はメディアソリューションアーキテクトの安司・石井が担当しました。 原文は こちら をご覧ください。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

こんにちは、Amazon Connect ソリューションアーキテクトの清水です。 2024 年 7 月のアップデート まとめはいかがでしたでしょうか。今後もコンタクトセンターや Amazon Connect に係わる方々へ気づきが得られる情報を発信したいと思いますので、記事を基に実際に皆様の環境でお試しいただき、是非フィードバックをお寄せ頂きたいと思います。 今月はアップデート以外に Amazon Connect のスキルアップに役立つトレーニングをお知らせいたします。 それでは今号も以下の内容をお届けします。皆さんのお役に立つ内容があれば幸いです！ 注目のアップデートとトレーニングについて 2024 年 8 月のアップデート一覧 AWS Contact Center Blog のご紹介 1.注目のアップデートとトレーニングについて 注目#1 Amazon Connect Communications Specialist Learning Plan (Amazon Connect の新しい学習プランが公開) 従来より AWS は Amazon Connect に関するデジタルトレーニングを提供していましたが、製品にフォーカスしていたり、Amazon Connect の新機能の追加によりコンテンツが陳腐化するという課題がありました。新しい学習プランは、1 つのアプリケーションやサービスに関連するすべての概念を学ぶのではなく、自分の立場・役割に役立つ複数のアプリケーション、サービス、製品に関する特定の概念だけを学ぶことが可能になります。最初の学習プランではコンタクトセンターのエンジニア、通信エンジニア、IVR エンジニア、テレフォニー管理者を対象とした Amazon Connect Communications Specialist を公開しました。学習しやすいようにシリーズは 30 分～60 分で区切られており、テレフォニー、IVR、フロー、ルーティング、オムニチャネルデプロイ、および AWS サービスとの統合を学ぶことができます( 中でもAmazon Connect ソリューションアーキテクトが特におすすめするのは「 Amazon Connect Optimizing Routing Solutions 」です！ )。 このカリキュラムを修了し、ナレッジチェックを 80% 以上のスコアで合格すると Credly から Amazon Connect Communications Specialist バッジを獲得できます。これはクラウドスキルや経験を伝えるために役立てることができます。 このトレーニングは無償で利用可能で、現在は英語で提供しています。学習には AWS Skill Builder のアカウントが必要です。 注目#2 Amazon Connect provides new ways to configure callbacks (Amazon Connect でコールバックの新しい設定が追加) Amazon Connect では営業時間外の問い合わせやエージェントが対応できないため待ち時間が発生する状況に対しコールバックキューを利用して、エージェントが対応可能になり次第、順次顧客へのコールバックを行う機能があります。今回コールバックの設定でフローが設定可能になったことにより、例えば営業時間外にかかってきた問い合わせがコールバックキューに入った後、コールバック時にフローから顧客データを参照して、もし顧客が既にボットや FAQ によって問題を解決済みであればコールバックを中止し、エージェントと顧客の不要な通話を抑えることができます。 コールバックのフローは、「キューへ転送」ボックスの「オプションのパラメータ」－「作成フローを指定」で設定することができます。 2. 2024年8月のアップデート一覧 Amazon Connect provides new ways to configure callbacks (Amazon Connect でコールバックの新しい設定が追加) – 08/23/2024 Amazon Connect では、コールバックの作成前やキューにある間にアクションを実行するようにフローを設定できるようになりました。たとえば、コールバック前に SMS 経由で顧客に自動的に通知を送信したり、最新の顧客データに基づいてコールバック属性を更新したり、既に問題が解決された場合はコールバックを終了したりできるようになりました。また Customer Profiles やサードパーティアプリケーションからの顧客情報に基づいて、コールバックまでの時間がかかる場合に、コールバックの優先順位を動的に変更したり別のキューにコールバックを転送するフローを実行できるようになりました。 関連リンク 管理者ガイド Amazon Connect in-app, web, and video calling is now available in Africa (Cape Town) region (アプリ内通話、ウェブ通話、ビデオ通話がアフリカ(ケープタウン)リージョンをサポート) – 08/20/2024 Amazon Connect では、アフリカ (ケープタウン) リージョンでアプリ内通話、ウェブ通話、ビデオ通話機能が提供されるようになりました。これにより、ウェブサイトやモバイルアプリケーションで、よりパーソナライズされた音声およびビデオ通話を簡単に提供できるようになります。これらの音声およびビデオ機能により、顧客はウェブサイトやモバイルアプリケーションを切り替えることなく通話を開始することができます。この機能を使用してコンテキスト情報を Amazon Connect に渡すことができるため、顧客のプロフィール、認証ステータス、アプリ内で以前に実行されたアクションなどの属性に基づいて顧客体験をパーソナライズできます。 関連リンク 管理者ガイド Amazon Connect outbound campaigns now supports Mexico (Amazon Connect アウトバウンドキャンペーンがメキシコのサポートを開始) – 08/14/2024 Amazon Connect で米国東部 (バージニア) および米国西部 (オレゴン) リージョンにおけるメキシコへの outbound campaigns コールがサポートされるようになりました。これにより配達通知、マーケティングプロモーション、予約通知、債権回収などのユースケースで、音声、SMS、E メールによるコミュニケーションが容易になります。この機能には、ダイヤル状態の確認、時間帯、タイムゾーン、連絡先ごとの試行回数、留守番電話検出機能を備えたプレディクティブダイヤルなどの機能が含まれます。Amazon Pinpoint が提供するリスト管理機能を使用して、カスタマージャーニーやマルチチャネルのユーザーコンタクトエクスペリエンスを構築することもできます。 関連リンク Amazon Connect Telecoms Country Coverage Guide Amazon Connect Contact Lens generative AI-powered agent performance evaluations (preview) now available in 6 new regions (Amazon Connect Contact Lens の生成 AI を活用したエージェントのパフォーマンス評価機能 (プレビュー版) が 6 つの新しいリージョンで利用可能に) – 08/13/2024 Amazon Connect Contact Lens 生成 AI を活用したエージェントパフォーマンス評価 (プレビュー) が、ヨーロッパ (フランクフルト)、ヨーロッパ (ロンドン)、カナダ (中央)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、およびアジアパシフィック (シンガポール) の AWS リージョン で利用可能になりました。これにより管理者は、エージェントの行動に関する追加のインサイト(例：エージェントが悪い知らせを顧客に伝える際に共感を示したか)を得ることが可能になり、推奨された回答のコンテキストと正当性（回答を提供するために使用された文字起こしからの参照ポイント）を確認することで、より迅速かつ正確に評価を行うことができます。今回の提供開始により、Contact Lens 生成 AI を活用したエージェントパフォーマンス評価は、既存の米国東部（バージニア北部）、米国西部（オレゴン）リージョンを含む 8 つの AWS リージョンで利用できるようになりました。なお、評価対象の言語は現在英語をサポートしています。 関連リンク 管理者ガイド Amazon Connect now provides an API to update routing criteria on a queued contact (Amazon Connect にキュー内のコンタクトのルーティング条件を更新する API が提供) – 08/10/2024 Amazon Connect で、現在キューにあるコンタクトのルーティング条件を更新する API が提供されました。ルーティング条件を使用すると、特定の言語での習熟度などの属性に基づいて、特定の優先エージェントまたはエージェントのリストに対しコンタクトをターゲットにすることができます。この API を使用すると、キューに入っているコンタクトのルーティング条件を外部システムから直接更新できます。例えば、エージェントが顧客名などの属性に基づいて次にルーティングするコンタクトをキューから選択できるダッシュボードを構築し、この API を使用してルーティング指示をConnect に送信することができます。この機能は、Amazon Connect が提供されているすべての AWS リージョンで利用できます。 関連リンク 管理者ガイド Release Notes API Reference Amazon Connect now supports additional agent scheduling staffing rules (Amazon Connect が、追加のエージェントスケジューリング人員配置ルールのサポートを開始) – 08/06/2024 Amazon Connect で、労働、組合、その他の契約上のルールに従いながらエージェントを簡単にスケジュールできる追加のエージェントスケジューリングルールがサポートされました。これにより、Amazon Connect でエージェントのスケジューリングを行う際に、5 つの新しいルール (シフト間の最小休憩時間、1 週間あたりの最小休憩時間、連続勤務日数の上限、連続勤務日の上限) を設定できるようになりました。一度設定すると、これらのルールは新しいスケジュールが生成されたときだけでなく、既存のスケジュールを編集するときにも適用されます。これらの追加ルールにより、管理者はエージェントスケジュールに関する日々の管理が容易になります。この機能は、Amazon Connect スケジューリングが利用可能なすべての AWS リージョンで利用できます。 関連リンク 管理者ガイド Amazon Connect now supports audio optimization for Amazon WorkSpaces cloud desktops (Amazon Connect が、Amazon WorkSpaces クラウドデスクトップに対するオーディオ最適化のサポートを開始) – 08/06/2024 Amazon Connect は、Amazon WorkSpaces 仮想デスクトップインフラストラクチャ (VDI) 環境で高品質の音声を簡単に提供可能になりました。Amazon Connect は、エージェントのローカルデスクトップから Connect にメディアをリダイレクトすることで音声を自動的に最適化し、エージェントの操作を簡素化し、ネットワークホップを減らすことで音質を向上させます。エージェントは、Windows デバイス、ウェブブラウザ、または Amazon WorkSpaces シンクライアント用の Amazon WorkSpaces クライアントアプリケーションにログインするだけで、Amazon Connect オープンソース JavaScript ライブラリの API を使用して、カスタムコンタクトコントロールパネルを使用した通話を開始できます。これらの新機能は、Amazon Connect が提供されているすべての AWS リージョンで利用できます。 関連リンク 管理者ガイド Release Notes Amazon Connect launches the ability to configure when whisper flows are used (Amazon Connect が、ウィスパーフローを使用するタイミングを設定する機能をリリース) – 08/03/2024 Amazon Connect では、フローのパフォーマンスを最適化するために、コンタクト中に ウィスパーフロー を使用するタイミングを設定する機能がサポートされました。ウィスパーフローは、お客様またはエージェントが音声またはチャットでお互いに接続されている間の体験を定義します。今回のリリースにより、ウィスパーフローをオフにできるようになったため、フローのパフォーマンスをさらに最適化し、コンタクト時間を短縮できます。たとえば、アウトバウンドまたはコールバックのシナリオではウィスパーフローをオフにして、エージェントとお客様が通話を開始するまでの時間を短縮できます。この機能は、Amazon Connect が提供されているすべての AWS リージョンで利用できます。 関連リンク 管理者ガイド Amazon Connect now enables agents to view pre-approved windows when scheduling time off (Amazon Connect で、エージェントが休暇をスケジュールする際に、事前に承認された期間を確認できるように) – 08/01/2024 Amazon Connect では、エージェントが自身のスタッフィンググループの事前に承認された休暇期間 (グループ許可) を確認できるようになりました。これにより、エージェントは休暇をリクエストするときに利用可能なオプションを簡単に特定できます。たとえば、午前 8 時から午後 12 時までの休暇申請を作成する場合、午前 8 時から午前 11 時までは利用可能なグループ許可があるが、午前 11 時から午後 12 時までの許可がないことを確認することができます。これに基づき、エージェントは提出前に休暇申請を変更したり、スーパーバイザーへ上書きをリクエストすることができます。今回の発表により、エージェントはリクエストを送信する前にどの日に必要な許可があるかを評価できるため、エージェントの休暇手続きが簡単になります。この機能は、Amazon Connect エージェントのスケジューリングが利用可能なすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド 3. AWS Contact Center Blog のご紹介 2024 年の Amazon Connect の新機能 : カスタマーエクスペリエンスの変革に力を (日本語翻訳) 今日の急速に変化するビジネス環境において、優れた顧客体験を提供することは最重要課題です。顧客は、すべての接点で、シームレスでパーソナライズされたサポートを期待しており、これらの進化する要求に応えるため、企業は新しい方法を常に探し求めています。AI を活用したクラウドコンタクトセンターソリューションである Amazon Connect は、業界を問わず企業が最新の技術の進歩を活用し、エージェントを支援し、顧客データから洞察を抽出し、エンドユーザーを喜ばせるオムニチャネルサポートを提供できるよう支援しています。このブログでは、 Customer Contact Week (CCW) で発表されたものを含め Amazon Connect の最新の機能、そしてお客様サービスの提供を革新的に変えている先進的な企業の事例をご紹介します。 Manage cancelled callback to reduce agent handle time with Amazon Connect (英語記事) コールバックは、顧客が電話機を持ったまま待たせることなくキュー内の位置を予約できるため、コンタクトセンターでは重要な役割を果たします。これにより、待ち時間が短縮されてカスタマーサービスが強化されるだけでなく、電話のコストとエージェントの稼働率も最適化されます。コールバックが顧客によってリクエストされた場合、キャンセルされるか、顧客がエージェントに接続されるまでコールバックは キュー に残ります。このブログ記事では、すでにキューに入っているが不要となったコールバックを処理するさまざまな方法について説明します。さらに、顧客が以前にコールバックを要求したかどうかを確認し、複数のコールバックを設定できないようにする機能についても解説します。 CX Insights – Generative AI delivering results now (英語記事) 2023 年の夏、 生成 AI が正確で自動化された会話結果を顧客にいつ提供できるかという疑問が持たれていました。Gartner は 2023 年の Gartner® Market Trend Report において「2023 年にはバーチャルエージェントの投資が約 2％ だったが、2030 年までには人間のエージェントへの投資を上回るだろう」という戦略的計画の前提を置いています。現在はこのレポートから 1 年も経過していないことを考えると、バーチャルエージェントへの移行はさらに早く起こるかもしれません。生成 AI は、予想よりも早く企業規模の本番環境において、真の顧客体験（CX）の成果をもたらしつつあります。このブログ記事では、2023年の夏から実現可能性に関する疑問は何だったのか、そしてそれ以来どのような変化があったのかを解説します。 Enabling generative AI for better customer experience can be easy with Amazon Connect (英語記事) 生成 AI の話題は2024年になっても勢いは衰えることはありません。この注目すべきテクノロジーの新たなイノベーションと創造的なユースケースが日々登場しています。顧客体験 (CX) のユースケースにおける生成 AI の有望性は明確でエキサイティングです。ただし、新しいアイデアには、責任を持って安全に使用する方法と、結果を最大化する方法についての考慮事項があります。3 部構成となるブログシリーズの 第 1 部 では、生成 AI がコンタクトセンターの運営の 3 つの主要部分である、エージェント効率改善、分析と品質モニタリングの改善、顧客セルフサービスの改善にどのように影響するかについて説明しました。シリーズの 第 2 部 では、これら 3 つの領域、生成 AI の活用に伴う課題と、価値を最大化しながらリスクを軽減するためのアプローチ方法について詳しく説明しました。この第 3 部では、顧客サービスのユースケースで生成 AI を迅速かつ簡単に有効化する方法を紹介します。 Providing great customer experiences using real-time sentiment analysis with Amazon Connect (英語記事) コンタクトセンターのエージェントとスーパーバイザーは、顧客に対し常に優れたカスタマーサービスを提供するよう努めています。現代のコンタクトセンターでは、通常、自動音声応答 (IVR) システムが、サポートを求める顧客の最初の窓口となります。そのため顧客が IVR とやり取りしている間に、優れた顧客体験を提供することが重要です。しかしコンタクトセンターの運用チームは、顧客が IVR とやり取りしている間に顧客の意図を予測して適切なアクションを取るのに苦労することがよくあります。このような問題点があると、顧客は不満を抱き、問い合わせを適切に解決できないままコンタクトを切断してしまう可能性があります。このブログ記事では、 Amazon Connect を使用して組織が AI 主導の会話分析の力を活用し、発信者の感情を理解し、情報に基づいた意思決定をリアルタイムで下せるようにする方法を探ります。また、 Amazon Q in Connect がどのように生成 AI を使用してエージェントに顧客の質問への回答やアクションを提案し、より迅速な問題解決と顧客満足度の向上を実現するかについても説明します。 Elevating Amazon Connect digital enablement with learning plans and badges (英語記事) ペースの速いクラウドイノベーションの世界では、時代を先取りすることは困難な場合があります。 Amazon Connect では、お客様やパートナーに包括的で最新のトレーニングリソースを提供する必要性を認識しており、この度新しいデジタル支援戦略を再設計しました。学習プランは、AWS 教育を可能な限り最も効率的な方法で導くためのカスタマイズされたロードマップを提供します。1 つのアプリケーションやサービスに関連するすべての概念を学ぶのではなく、自分の役割を効果的に果たすのに役立つ複数のアプリケーション、サービス、製品に関する特定の概念だけを学ぶことになります。この学習アプローチは、目標とする役割に必要な分野のみに焦点を当てることにより、時間を節約します。 A repeatable approach to building contact centers with Amazon Connect (英語記事) 効果的なコンタクトセンターソリューションの導入は、特に独自の要件を持つ企業にとっては複雑です。このブログ記事では、発見、文書化、開発への標準化されたアプローチを含む基本的なプロセスの概要を説明しています。このアプローチに従うことで、企業は現在のニーズを満たし、長期にわたって簡単に維持および強化できる、信頼性が高くスケーラブルなコンタクトセンターを確立できます。 Standard Bank optimizes operational efficiency with Amazon Connect (英語記事) Standard Bank はアフリカ最大の銀行の 1 つで、5 万人以上の従業員を擁し、20 か国の 1,800 万人以上の顧客にサービスを提供しています。1862 年に設立された当行は、個人および企業向けバンキング、ウェルスマネジメント、アドバイザリーサービスなどを提供する大手ファイナンスサービス組織に成長しました。Standard Bank のコンタクトセンター業務は、多様な銀行ポートフォリオにわたるカスタマーサービスの提供を支えています。5,500 人以上のエージェントが年間 4,000 万件近くの顧客とのやり取りを処理しており、コンタクトセンターは重要なタッチポイントでした。しかし銀行が使用していたオンプレミスのコンタクトセンタープラットフォームがサポート終了を迎えたことにより、デジタルトランスフォーメーションの目標を達成する上で、大きなオペレーションリスクが生じました。このブログ記事では、Standard Bank が Amazon Connect を活用し、コンタクトセンターのモダナイズを実現し、顧客体験（CX）の向上やオペレーションの効率化など、様々な成果を上げた事例を紹介します。 Scale your contact center effectively with Amazon Connect and Service Quotas (英語記事) Amazon Connect のワークロードが増大するにつれて、お客様はスケーリングを効率的に管理し、デプロイの失敗やサービスの中断が制限を超えないようにするために、クォータを可視化する必要があります。Amazon Connect を サービスクォータ と統合することで、インスタンスのサービスクォータの管理が改善されます。サービスクォータは、AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス （AWS CLI）のどちらを使用しても、クォータを効率的に管理および追跡するためのハブとして機能します。この統合により、Amazon Connect ではアカウントとリソースクォータ割り当てのナビゲートと最適化をより柔軟に制御できるようになります。サービスクォータを使用すると、Connect のクォータを 1 か所で管理できるため、複数のソースにアクセスする必要がなくなります。サポートされているクォータについては、 Amazon CloudWatch との統合により、設定可能なアラームによるプロアクティブな管理が可能になり、指定されたクォータに近づくとタイムリーにアラートが送信されます。 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせ頂けますと幸いです。 Amazon Connect ソリューションアーキテクト 清水 幸典

本ブログは、KDDIアジャイル開発センター株式会社 プロダクトオーナーリード 佐々木 祥氏、同 エンジニア 大坪 悠氏、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 新谷 が共同で執筆しました。 KDDIアジャイル開発センター株式会社 （以下、KAG）は、サービスデザインとアジャイル開発手法によりビジネス創出からプロダクト開発を一貫してサポートするプロフェッショナル集団です。同社は Amazon Bedrock 統合の Slack チャットボット を開発する等、生成 AI を活用した社内外の課題解決に積極的に取り組んでいます。本ブログでは KAG の寄稿により、Amazon Bedrock を活用した営業支援プロダクト「議事録パックン」で、一連の営業活動を効率化し、営業知見の収集と利活用サイクルを構築した事例をご紹介します。実際に KDDI株式会社（以下、KDDI）の営業担当者が本プロダクトを利用し、議事録と提案書の作成時間を最大 1 時間短縮できるという効果が得られています。 導入背景 本事例は KDDI の営業社員が感じていた課題感を起点としています。営業活動は、過去のアプローチや商談結果に基づく知見を利活用して提案内容を検討することがありますが、この営業知見の原資となるのが個人の「日報」です。しかし、営業社員が忙しさから日報を書き残す時間を十分に取れなかったり、日報を収集して有効に利活用できるメカニズムを構築できていない点が課題でした。実際に、営業社員へのインタビューの中でも「議事録と日報作成の手間」や「情報共有が属人的」等の点に課題感を感じているという声が上がっています。そこで、KAG は日報の重要性とその作成負担を鑑み、日々の営業活動の自動収集・知見出力の自動化に取り組み、営業活動全体の業務フローを一気通貫で支援、改善できるプロダクトの開発を開始しました。 生成 AI で営業活動を一気通貫に支援「議事録パックン」 KAG は、営業活動の業務フローを生成 AI で一気通貫に支援するプロダクト「議事録パックン」を開発しました。日々の営業活動では ① 議事録作成を通じて活動履歴を残し ② 議事内容から商材検討の上顧客提案を行い ③ 日報・週報の作成通じて知見を利活用可能にする、というサイクルが重要です。各フェーズに対し「議事録パックン」は生成 AI を活用し ①’ 議事録生成機能 ②’ 提案骨子生成機能 ③‘ 日報・週報生成機能 を提供します。 1. 議事録生成機能 会議の録音・録画 ファイル、又は電話会議ツールの書き起こしテキストファイルをアップロードすることで、議事録を出力できる機能です。議事録は「参加者」「概要」「結論」「次回の議題」のように項目に沿って要点が提供されます。工夫した点として、一度出力された議事録に対しても、ユーザーが項目別に修正方針を入力し、再整形することが可能です。例えば「結論」の項目を「箇条書きにして」等と指示すると、指示に従って再整形した議事録を出力し直します。 2. 提案骨子生成機能 生成した議事録を活用し、提案骨子を出力できる機能です。ユーザーが案件名や対象とする議事録を入力すると、自動的に社内で保有している関連商材や他社の競合製品を検索し、比較表を生成します。このような流れで収集した情報に基づき、最終的には次回の顧客訪問に向けた提案骨子を生成します。 3. 日報・週報生成機能 日報・週報を出力できる機能です。ユーザーが期間を入力すると、案件毎にその期間で「議事録パックン」を通じて生成した情報に基づき活動履歴を要約し、日報・週報を生成します。 導入効果 実際に KDDI 営業担当にて本プロダクトを活用し評価を行なった結果、議事録と提案書の作成時間を最大 1 時間短縮することができました。また、生成された「議事録」「提案骨子」「日報」に対して「そのまま営業日報に使えるレベル」「部内の横展開もしやすく、業務品質は上がると思う」「提案材料を探す手間が減り、どう提案するかに力がさけるようになる」等のポジティブな声が多くあり、本プロダクトが営業活動を効率化し知見蓄積を促すために有効であることが確認できました。一方で、録音文化の醸成やファイルアップロードの待ち時間、具体的な知見の利活用などの観点での課題もフィードバックされており、これらの点は改善の余地があります。 アーキテクチャ 「議事録パックン」のプロジェクトは 企画から開発、評価に至るまで約 3 ヶ月で完了しました。そのうち、実際の開発期間は約 2 週間です。 Amazon Bedrock を中心に AWS マネージドサービスをフル活用したことで、短期間で生成 AI アプリケーションを開発することができました。そんな「議事録パックン」のアーキテクチャをご紹介します。 まず、議事録生成機能では、会議の音声データがアップロードされると、Amazon Elastic Container Service (ECS) で起動したコンテナが、Amazon Transcribe を呼び出して書き起こしテキストを取得します。このテキストを元に、 Amazon Bedrock の Claude 3 Opus に要約を指示して議事録を生成させます。議事録に対しユーザーから再整形を指示された際は、指示内容をプロンプトに付与して再度 Amazon Bedrock を呼び出します。提案骨子生成機能では、 LangChain の ReAct Agent を活用し、必要な社内外の情報を動的に取得しています。 Agent は、社内文書を格納している Amazon Bedrock Knowledge Bases から自社商材を検索する Tool や、他社製品や業界情報を取得するために Google 検索を行う Tool を使いながら、提案商材の検討・比較を行います。最終的には、取得した情報と議事録に基づき提案骨子を生成します。生成された情報は Amazon DynamoDB に蓄積し、日報・週報生成機能で利用しています。ユーザーに指定された期間の生成物を Amazon Bedrock に要約させることで、日報・週報を生成します。運用面では、 Langfuse を活用し、生成内容をトレースしながら評価やプロンプト管理ができるようにしました。 所感と今後の展望 Claude3 Opus の日本語生成精度が大変優秀だったため、当初時間を要すると思われた LLM のプロンプトやコンテキストの入れ方に関するチューニングがほぼ不要であった点が開発を一段と簡単にさせました。特に議事録生成機能は利用部門で好評となっており、営業メンバー本人が書く議事録と遜色がないレベルとのコメントも頂いております。プロダクト開発初期から Langfuse などのオブザーバビリティにも力をいれていた点も、開発速度向上に繋がりました。オブザーバビリティについては、より一層 Amazon Bedrock との親和性が高いマネージドサービスが出てくることを期待したいです。 （KDDIアジャイル開発センター株式会社 エンジニア 大坪 悠氏） 今回は議事録生成および議事内容から推測される次の打ち手の骨子程度の提案までにとどまりましたが、今後はさらにその先の、会社の戦略・ビジョンに関わる提案の支援や、プレゼン資料自体の作成等まで発展させ、利益創出の原動力となるプロダクトを目指したいです。その上でエージェント機能の進展は欠かせないと感じています。 AWS らしいカスタマイズ性は残しつつ、多岐にわたる知見の自律的活用が可能な AI 機能拡張に期待したいです。 （KDDIアジャイル開発センター株式会社 プロダクトオーナーリード 佐々木 祥氏） まとめ 本ブログでは、KDDIアジャイル開発センター株式会社の Amazon Bedrock 活用事例「議事録パックン」をご紹介しました。議事録や日報作成といった、日々の活動記録・レポートに上手く生成 AI の力を取り入れることで、営業活動全体を効率化しています。社内業務の課題を起点とした生成 AI ユースケースとして、皆様の参考になれば幸いです。 著者 佐々木 祥 KDDIアジャイル開発センター株式会社 ビジネスデザイン部 プロダクトオーナーリード 大坪 悠 KDDIアジャイル開発センター株式会社 開発5部 エンジニア 新谷 歩生 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ シニアソリューションアーキテクト

今日の変化の激しいデジタル環境においては、企業や開発者が Web アプリケーションを迅速かつ安全にデプロイする効率的な方法を常に求めています。 AWS Amplify Gen2 は、 GitLab の堅牢なバージョン管理システムと組み合わせることで、このチャレンジに対する効果的なソリューションを提供します。 AWS Amplify Hosting では様々な リポジトリの選択肢 をサポートしていますが、このブログでは GitLab をリポジトリとして使う AWS Amplify Hosting でのアプリケーションのデプロイ方法をご紹介します。 AWS Amplify Gen2 は、フロントエンド開発者が AWS 上でフルスタック アプリケーションを構築する方法を提供しています。TypeScript、ファイル規約、Git ブランチベースの環境を使用して、フロントエンドとバックエンドを定義できます。GitLab の強力なバージョン管理および継続的インテグレーションと継続的デプロイ (CI/CD) 機能と組み合わせることで、このソリューションは Web アプリケーションのシームレスで自動化されたデプロイを可能にし、一貫性を確保し、手動操作によるエラーのリスクを低減します。 このブログでは、GitLab をリポジトリとして使用し、AWS Amplify Hosting をデプロイプラットフォームとして使用して Web アプリケーションをデプロイするプロセスを説明します。このワークフローの簡素さと効率を活用する方法を学び、AWS Amplify Gen 2 がデプロイの複雑さを処理しながら、優れたアプリケーションの構築に集中できるようになります。 前提条件 はじめに必要な作業は次のとおりです。 GitLab アカウントと プロジェクト を作成する: GitLab に登録し、新しいプロジェクトを作成します。 IDE を開く: お好みの開発環境を起動します。 React TypeScript + Vite アプリと Amplify Gen 2 バックエンドをセットアップする: ターミナルでコマンド npm create vite@latest react-amplify-gen2 -- --template react-ts を使用して、Vite で TypeScript を使用する新しい React アプリを作成します。 コマンド cd react-amplify-gen2 で新しく作成したディレクトリに移動し、 npm install でプロジェクトの依存関係をインストールします。 npm create amplify@latest を実行して、GitLab リポジトリで Amplify Gen2 を設定します。このコマンドは、GitLab リポジトリで Amplify Gen2 の設定を検出するために不可欠です。 AWS アカウントを設定 し、Amplify で使用するために AWS プロファイルをローカルに設定します。 変更をコミットしてプッシュする セットアップが完了したら、 変更をすべてコミット し、GitLab リポジトリにプッシュします。 前提条件を完了した後、以下の手順を実行します。 AWS Amplify Hosting にホストするアプリケーションの作成 GitLab アカウントへの AWS Amplify のアクセスを承認 リポジトリとして GitLab を使用したサンプルアプリのデプロイ React アプリケーションを AWS Amplify Hosting にホスティングする方法 始めるには、 Amplify コンソール にサインインしてください。AWS Amplify のホームページから始める場合は、図 1 に示されているように、ページの上部にある Create new app を選択します。 図 1: AWS Amplify で新規のアプリケーション作成 すでに存在する Amplify アプリがある場合は、単に All apps タブから Create new app を選択します (図 2)。まず初めに、ソースコードプロバイダを選びましょう。図 3 に示すように、Choose source code provider ウィンドウで GitLab を選択してください。 図 2: AWS Amplify で新規のアプリケーションを追加 GitLab をソースコードプロバイダとして選択したら、下にスクロールして 次へ を選択してください。 まずはリポジトリブランチを追加しましょう。AWS Amplify は GitLab にサインインしてアクセス許可を得るためのポップアップウィンドウを開きます (図 4)。 前提条件の手順 1 「GitLab アカウントとプロジェクトを作成」で作成した資格情報を使って GitLab にサインインしてください。 図 3: AWS Amplify でソースコードプロバイダの選択 GitLab アカウントにサインインすると、認証ページにリダイレクトされます。 GitLab 認証ページで、図 5 で示すように Authorize を選択してください。 図 5: GitLab アカウントに AWS Amplify がアクセスできるように承認 注意 — Amplify コンソールを Bitbucket、GitLab、または AWS CodeCommit で認証すると、Amplify はリポジトリプロバイダからアクセストークンを取得しますが、そのトークンは AWS サーバーに保存されません。Amplify は特定のリポジトリにインストールされているデプロイキーを使用してリポジトリにアクセスします。 次に、 Add repository branch (図 6) でリポジトリとブランチを選択します。Amplify Gen 2 は、Nx や Yarn Workspaces などのモノレポツールを使用したフルスタックビルドのための monorepo ワークフローをサポートしていることに注目する価値があります。 図 6: AWS Amplify でリポジトリとブランチを選択 リポジトリブランチを追加するための必須項目を入力したら、 Next を選択してください。 アプリケーション設定を見直しましょう。AWS Amplify は自動的にアプリ名、フロントエンドのビルドコマンド、ビルド出力ディレクトリを設定し、必要なサービスロールを作成します。 また、必要に応じてアプリ名、フロントエンドのビルドコマンド、ビルド出力ディレクトリなど、Amplify が設定した項目を変更することもできます (図 7)。 図 7: AWS Amplify でアプリケーションの設定をレビュー AWS Amplify コンソールの Service role と Advanced settings  を確認してください。サービスロールは、ユーザーに代わってアクションを実行するために必要です。 また、高度な設定では、デフォルトのビルドコンテナを使用するか、 自身で作成したコンテナーイメージ を使用することもでき、環境変数を追加したり、アプリケーションのためのパッケージやツールのインストール済みバージョンを上書きすることができます。 終わったら、 Next  を選択してください。 アプリケーションの詳細を確認しましょう。アプリケーションをデプロイする前に設定ミスがある場合は、修正することができます。修正が必要なフィールドでは Edit を選択してください (図 8)。 図8: AWS Amplify 経由でデプロイする前のアプリの詳細と設定の確認 Save and deploy  を選択してください。 AWS Amplify が Web アプリケーションをデプロイするのに数分かかります。 図 9: ホスティングされたアプリへのアクセス アプリケーションをデプロイしたら、 Visit deployed URL を選択するか、 Domain の下に提供された URL にアクセスすることで、図 9 のように Web アプリケーションを表示できます！ アプリケーションコードの更新 (オプション) Amplify Hosting をコード リポジトリに接続すると、各コミットで、アプリケーションフロントエンドとバックエンドの両方をデプロイするワークフローが 1 つトリガーされます。この方法により、フロントエンドとバックエンドの不整合を防ぐために、Web アプリケーションは正常にデプロイされた後にのみ更新されます。 IDE で App.tsx ファイルに移動し、コンテンツを自分のコードで置き換えてください。アプリケーションコードを更新したら、変更をコミットしてプッシュしてください。 数分後、変更がデプロイされます。 クリーンアップ このブログで作成したリソース (含む GitLab プロジェクト ) を削除しないと、追加料金が発生する可能性があるので注意してください。 AWS Amplify コンソール に移動し、このブログで作成したアプリケーションについて View App  を選択します。 次に App settings に移動し、その後 General settings  を選択します。 最後に Delete app を選択して、アプリケーションと関連リソースを削除します (図 10)。 図 10: AWS Amplify アプリの削除 終わりに このブログ記事では、開発者が GitLab と AWS Amplify Hosting を使用して Web アプリをデプロイする方法を説明しました。GitLab のような Git プラットフォームと統合することで、AWS Amplify はデプロイメントを効率化し、効率的な CI/CD パイプラインの簡素化に重点を置きます。AWS Amplify Gen 2 は monorepo、ブランチデプロイ、カスタムパイプラインなど、さまざまなフルスタックワークフローをサポートしており、ウェブアプリを素早くデプロイできます。AWS Amplify Gen 2 の機能を活用し、デプロイプロセスを合理化するには、 AWS Amplify Gen 2 ドキュメント を参照し、実践的な AWS Amplify Gen 2 ワークショップ を試し、 AWS Amplify Hosting コンソール にアクセスして開始してください。 著者について Ben-Amin York Jr. Ben-Amin is a Solutions Architect at AWS, specializing in Frontend Web & Mobile technologies. He focuses on the impact of AI/GenAI/ML across industries and provides technical guidance to enterprise customers in the Automotive & Manufacturing sector to achieve their business goals. 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

9 月が到来し、 AWS re:Invent 2024 の開催まであと 3 か月となりました。カンファレンスで発表される新しいサービスやお知らせが、とても楽しみです。新型コロナウイルス感染症のパンデミックの直前、re: Invent 2019 に参加したことを思い出します。60,000 人以上の参加者を集めた最大の対面式 re:Invent で、私がこのイベントに参加するのは 2 回目でした。熱い雰囲気を感じることができ、すばらしい体験となりました! 現在、AWS re:Invent 2024 の 登録 を受け付けています。ラスベガスで、5 日間のエキサイティングな基調講演、ブレイクアウトセッション、チョークトーク、インタラクティブな学習の機会、キャリアを変えるようなつながりを楽しみましょう! では、8月26日週の新しい発表を見てみましょう。 8月26日週のリリース 私が注目したいくつかのリリースをご紹介します。 AWS Parallel Computing Service の発表 – AWS Parallel Computing Service (AWS PCS) は、ハイパフォーマンスコンピューティング (HPC) ワークロードを AWS で実行およびスケールできる、新しいマネージドサービスです。テクニカルサポートと豊富なカスタマイズオプションが組み込まれたフルマネージドの Slurm スケジューラを使用して、科学モデルやエンジニアリングモデルを構築し、シミュレーションを実行できます。HPC 環境を特定のニーズに合わせてカスタマイズし、お好みのソフトウェアスタックと統合することも可能です。また、コンピューティング、ストレージ、ネットワーク、視覚化リソースを統合する完全な HPC クラスターを構築し、インスタンスを 0 個から数千個までシームレスにスケールできます。詳細については、 AWS Parallel Computing Service と Channy のブログ投稿 をご覧ください。 Amazon EC2 ステータスチェックで、アタッチされた EBS ボリュームの到達可能性状態のサポートを開始 – Amazon EC2 ステータスチェックを使用して、インスタンスにアタッチされている Amazon EBS ボリュームが到達可能で、入出力操作を完了できるかどうかを直接モニタリングできるようになりました。この新しいステータスチェックでは、Amazon EC2 インスタンスで実行されているアプリケーションのパフォーマンスに影響を与える可能性のある、添付ファイルの問題やボリュームの障害をすばやく検出できます。さらに、これらのステータスチェックを Auto Scaling グループ内で統合して、EC2 インスタンスの状態をモニタリングし、影響を受けたインスタンスを置き換えて、アプリケーションの高可用性と信頼性を確保できます。アタッチされた EBS ステータスチェックを、インスタンスステータスチェックおよびシステムステータスチェックと併用して、インスタンスの状態をモニタリングすることもできます。詳細については、「 Amazon EC2 インスタンスのステータスチェック 」ドキュメントを参照してください。 Amazon QuickSight で埋め込みダッシュボードのビュー共有のサポートを開始 – Amazon QuickSight で、埋め込みダッシュボードのビューを共有できるようになりました。この機能では、組み込みの QuickSight ダッシュボードを使用して、より多くのコラボレーション機能をアプリケーションで有効にできます。さらに、匿名ユーザーのブックマークなどのパーソナライズ機能も有効にできます。アプリケーションから離れずに、変更のみを表示する一意のリンクを共有したり、ダッシュボードまたはコンソールの埋め込みを使用して、 QuickSight Embedding SDK を利用するカプセル化された QuickSight のリファレンスを含むアプリケーションページへの共有可能なリンクを生成したりできます。さらに、QuickSight の読者は、この共有可能なリンクをピアに送信することが可能です。ピアが共有リンクにアクセスすると、埋め込まれた QuickSight ダッシュボードを含むアプリケーションのページに移動します。詳細については、 埋め込みビューのドキュメント を参照してください。 Amazon Q Business がユーザー ID 認証のための IAM フェデレーションをリリース – Amazon Q Business は、エンタープライズデータ向けに生成 AI ビジネスエキスパートをデプロイする、フルマネージドサービスです。Amazon Q Business IAM フェデレーション機能を使用すると、アプリケーションを直接 ID プロバイダーに接続し、これらのアプリケーションのユーザー ID とユーザー属性を取得できます。以前は、ID プロバイダーからのユーザー ID 情報を AWS IAM アイデンティティセンター に同期し、Amazon Q Business アプリケーションを IAM アイデンティティセンターに接続して、ユーザー認証を行う必要がありました。リリース時点で、Amazon Q Business IAM フェデレーションは ID プロバイダー接続用の OpenID Connect (OIDC) プロトコルと SAML2.0 プロトコルをサポートする予定です。詳細については、 Amazon Q Business のドキュメント をご覧ください。 Amazon Bedrock がクロスリージョン推論のサポートを開始 – Amazon Bedrock は、異なる AWS リージョンのコンピューティングを利用して、トラフィックバーストをシームレスに管理できるオプション機能である、クロスリージョン推論のサポートを発表しました。オンデマンドモードを使用している場合、クロスリージョン推論を使用することにより、より高いスループット制限 (リージョン内で割り当てられたクォータの最大 2 倍) を実現し、ピーク需要時のレジリエンスを強化できます。オプトインすると、需要の変動を予測するために時間と手間を費やす必要がなくなります。クロスリージョン推論は、トラフィックを複数のリージョンに動的にルーティングし、各リクエストの可用性を最適化して、使用率の高い期間でもスムーズなパフォーマンスを実現します。事前定義済みのリージョンのセットから選択することで、推論データのフロー先を管理できるため、適用されるデータレジデンシー要件や主権法への準拠が容易になります。リストについては、「 サポートされているリージョンとクロスリージョン推論のモデル 」を参照してください。開始するには、 Amazon Bedrock のドキュメント またはこの 機械学習ブログ を参照してください。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 追加のリージョンで既存のサービスとインスタンスタイプの提供を開始しました。 Amazon EC2 の C6gd インスタンスと R6gd インスタンスが AWS 欧州 (スペイン) リージョンで利用できるようになりました。 C6gd インスタンスは、ハイパフォーマンスコンピューティング (HPC)、バッチ処理、CPU ベースの機械学習推論などの計算集約型ワークロードに適しています。R6gd インスタンスは、オープンソースデータベース、インメモリキャッシュ、リアルタイムのビッグデータ分析などの、メモリ集約型ワークロードを実行するために構築されています。 Amazon OpenSearch Serverless が AWS GovCloud (米国西部) リージョンで利用できるようになりました。 OpenSearch Serverless は Amazon OpenSearch Service のサーバーレスデプロイオプションです。複雑なインフラストラクチャ管理を必要とすることなく、検索と分析のワークロードを簡単に実行できます。 AWS Global Accelerator は、エジプトのカイロに新しいエッジロケーションを開設します。 AWS Global Accelerator は、グローバルユーザーに提供するアプリケーションの可用性とパフォーマンスの向上をサポートする、ネットワーキングサービスです。 Amazon Redshift Serverless が AWS アジアパシフィック (ジャカルタ) リージョンで利用できるようになりました。 Amazon Redshift Serverless は Amazon Redshift のサーバーレスオプションで、データウェアハウスインフラストラクチャをセットアップして管理することなく、分析をほんの数秒でより効率的に実行およびスケールすることができます。 Amazon OpenSearch Service が Graviton3 (C7g、M7g、R7g、R7gd) インスタンスのサポートを開始しました。 Amazon OpenSearch Service が AWS Graviton3 インスタンスのサポートを開始しました。これにより、Graviton2 ベースのインスタンスと比較して、パフォーマンスが最大 25% 向上します。 AWS Config 適合パックが、新たに 12 の AWS リージョンで利用できるようになりました。 適合パックを使用すると、 AWS Config ルールとそれらに関連付けられた修復アクションを 1 つのパッケージにまとめることができるため、大規模なデプロイが簡素化されます。これらの機能は、アジアパシフィック (ジャカルタ)、アフリカ (ケープタウン)、中東 (UAE)、アジアパシフィック (ハイデラバード)、アジアパシフィック (大阪)、欧州 (ミラノ)、イスラエル (テルアビブ)、カナダ西部 (カルガリー)、欧州 (スペイン)、欧州 (チューリッヒ)、AWS GovCloud (米国東部)、AWS GovCloud (米国西部) に追加されました。 その他の AWS イベント AWS GenAI Loft は、クラウドと AI に関する AWS の専門知識を示すコラボレーションスペースと没入型体験です。また、スタートアップや開発者に、AI 製品やサービスへの実践的なアクセス、業界のリーダーとの限定セッション、投資家や仲間との貴重なネットワーキングの機会を提供します。 お近くの GenAI Loft の開催地を見つけて 、ご登録ください。 提供: Antje Barth 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit は、クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントです。今年の AWS Summit は終了間近です。まだご登録いただけるのは、 ジャカルタ (9 月 5 日)、 トロント (9 月 11 日)、 オタワ (10 月 9 日) の 3 つです。 AWS Community Day では、世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されます。AWS Summit 2024 は間もなく終了しますが、AWS Community Day は大いに盛り上がっています。今後開催される AWS Community Day は、 ベルファスト (9 月 6 日)、Antje Barth が基調講演を行う サンフランシスコベイエリア (9 月 13 日)、 アルゼンチン (9 月 14 日)、 アルメニア (9 月 14 日) です。 近日中に開催されるすべての AWS による対面およびバーチャルイベント は、こちらで閲覧することができます。 9月2日週はここまでです。9月9日週の Weekly Roundup もお楽しみに! — Esra この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

AWS Amplify Hosting は、キャッシュの効率性の大幅な改善を発表することを喜ばしく思います。最適化されたキャッシュルールと、キャッシュキーからクッキーを削除することによる高いキャッシュヒット率をお客様に提供します。また、Next.js の国際化 (i18n) サポートなどのユースケースを可能にする、追加のヘッダーへのアクセスも提供しています。この変更により、エンドユーザーはコンテンツを高速かつ効率的に受け取れ、より優れたユーザーエクスペリエンスが実現できるようになります。 改善ハイライト 最適化されたキャッシュポリシー キャッシュキーから Cookie を削除する機能 追加の CloudFront ヘッダーの転送 Next.js 国際化 (i18n) をサポート Brotli 圧縮を有効化 パフォーマンス改善 追加のキャッシュポリシー Amplify Hosting は、世界中のエッジロケーションのネットワークを利用して、低レイテンシーでコンテンツを配信する Amazon CloudFront Global Edge Network を活用しています。 Amazon CloudFront は、エンドユーザーのリクエストが最も近いエッジロケーションから返されるようにします。その結果、Web リクエストが短い距離を移動するため、パフォーマンスが向上します。エッジロケーションにキャッシュされていないファイルの場合、Amazon CloudFront はオリジンサーバーからファイルを可能な限り速く取得できるロジックを維持しています。キャッシュポリシーによってキャッシュキーが決まり、キャッシュされたコンテンツがサービスされるかどうかが判断されます。一方、オリジンリクエストポリシーは、キャッシュミスの際にどの Cookie、クエリ文字列、ヘッダーをオリジンサーバーに転送するかを指定します。 特定の種類のコンテンツに最適な キャッシュ戦略と Time To Live (TTL) の延長により、キャッシュヒット率が高くなり、エンドユーザーにより早い応答時間を提供できるようになります。現在、Amplify Hosting は、静的コンテンツ、サーバーサイドレンダリングされたコンテンツ、画像の最適化コンテンツに対して、次のキャッシュ戦略を実装しています。 これらの変更が以前のバージョンとどのように比較されるかについては、 ドキュメントの詳細な表 を参照してください。 コンテンツ タイプ キャッシュ期間 キャッシュキーに含まれるもの 静的コンテンツ 最大 1 年 Authorization および Host ヘッダー Cookie – なし クエリ文字列 – なし SSR コンテンツおよびリバースプロキシ 最大 1 年 Accept 、 Authorization 、 CloudFront-Viewer-Country 、および Host ヘッダー Cookie – すべて クエリ文字列 – すべて 画像最適化コンテンツ 最大 1 年 Accept 、 Authorization 、および Host ヘッダー Cookie – なし クエリ文字列: すべて ( 詳細 ) キャッシュは、デプロイ後や、カスタムヘッダーまたは Basic 認証設定が更新されるたびに無効化されます。これらのキャッシュ戦略の詳細については、キャッシュに関するドキュメントを参照してください。 キャッシュキーから Cookie を削除 キャッシュキーから Cookie を削除することができるようになりました。キャッシュキーは、コンテンツデリバリーネットワーク（CDN）がキャッシュされたコンテンツを効率的に保存および取得するために使用する固有の識別子で、ユーザーがアプリケーションの正しいバージョンを迅速に受け取れるようにします。キャッシュキーからCookieを削除する機能は非常に重要です。なぜなら、Google Analytics などのサービスからのウェブリクエストに含まれる Cookie は、各 Cookie に固有のハッシュが含まれているため、キャッシング戦略を妨げる可能性があるからです。 例えば、URL リクエストが次のように構築される場合は以下のようになります。 www.amplify.com Cookie: ga-session-id=abcdef キャッシュキーから Cookie を削除することで、ユーザーごとの固有のハッシュが排除され、キャッシュヒット率が大幅に向上します。この最適化により、キャッシュヒット率が高まり、より多くのコンテンツをエッジロケーションから直接配信できるようになります。その結果、パフォーマンスが向上し、コンテンツの配信が高速化され、ユーザーの待ち時間が短縮されます。 既存のアプリと新しいアプリは、本日からこの改善を活用できます。既存のアプリでは、概要ペインから Hosting を選択し、次に Custom headers and cache → Cache key settings を選んでキャッシュキーに Cookie を保持するかどうかを有効または無効にしてください。新しいアプリの場合は、 Advanced settings でこの設定を構成できます。この構成は API からも利用できます。 ベンチマーキング これらのパフォーマンス改善を評価するために、静的および SSR ルートの両方を含む Next.js 14 hello world アプリをベンチマークしました。SSR ルートは通常キャッシュされないため、静的アセットに関連する改善点にフォーカスしました。実際のお客様の動作をシミュレートするため、Google Analytics からリクエストごとにユニークな Cookie を導入しました。これらの CDN の改善を有効にすると、応答時間の 95 % タイルと平均の両方で約 98 %の改善と、99.99 %のキャッシュヒット率の大幅な改善を確認しました。アプリの複雑さとフレームワークによってはさまざまですが、このベーシックな hello world アプリでは、特に静的アセットに対してこれらの CDN キャッシュの最適化を有効にすることで、大幅なパフォーマンス向上が得られる可能性があることを強く示しています。 実際の例として、Next.js の SSG を使用し、GitHub でオープンソース化されている Amplify フレームワークのドキュメントサイト https://docs.amplify.aws/ のパフォーマンスを分析しました。静的サイトでありながら、著しく低いレイテンシと 90 % を超えるキャッシュヒット率という劇的な改善がみられました。 追加機能 CloudFront ヘッダー Amplify Hosting は、CloudFront が提供する追加のヘッダーを転送するようになりました。ヘッダーの詳細なリストは CloudFront のドキュメント でご確認いただけます。これらのヘッダーを利用可能にすることで、以下のようなさまざまなユースケースが可能になります。 user-agent ヘッダーは、コンテンツの最適化やパーソナライズのために、エンドユーザーのデバイス情報を把握することをユーザーに許可します。 referer ヘッダーは、リクエストの発信元を示すため、ウェブサイトはトラフィックソースを追跡できます。 エンドユーザーの地理情報を取得するための cloudfront-viewer-* ヘッダー (例: cloudfront-viewer-city) これらのヘッダーの一部にアクセスするには、サーバー側からのアクセスが必要になる可能性があります。たとえば、Next.js Amplify アプリの User-Agent ヘッダーは、Next.js の headers() 関数を使用して取得できます。これにより、開発者はサーバー側でヘッダー情報を取得し、クライアントのデバイスやブラウザに基づいてカスタムロジックを実装することができます。以下のコードスニペットは、このヘッダーを取得する方法を示しています。 import { headers } from 'next/headers' export default function Page() { const headersList = headers() const userAgent = headersList.get('user-agent') return <div>User Agent: {userAgent}</div> } Next.js の国際化 (i18n) Next.js の国際化 (i18n) が現在ネイティブにサポートされています。accept-language ヘッダをオリジンサーバに転送することで、Next.js アプリケーションは、ブラウザリクエストから直接ユーザの言語設定を検出できます。この機能強化により、多言語サイトのユーザーエクスペリエンスが大幅に向上しました。 Brotli 圧縮の有効化 このリリースにより、 Brotli 圧縮 が Amplify Hosting アプリで有効化され、アプリケーションのパフォーマンスが大幅に向上します。Brotli 圧縮は、非常に効率的なアルゴリズムで、ファイルサイズを縮小し、データ転送用に優れた圧縮を提供します。これにより、Web ページの読み込み時間が短縮され、データ使用量が削減されます。この機能強化により、特にモバイルユーザーや低速回線の接続環境でユーザー体験が改善され、帯域幅コストも削減できます。高速な読み込みにより、検索エンジンに優先されるため、SEO 順位も向上します。さらに、最新のブラウザーが Brotli をサポートしているため、互換性が確保され、パフォーマンス改善が最大化されます。この機能は、すべてのアプリで自動的に有効になります。 結論 新しいアプリではこれらの変更がすぐに適用されます。既存のアプリでは、これらのキャッシングの改善を適用するために新しいビルドをトリガーする必要があります。 適用されるキャッシュの変更に関する情報は、アプリのビルドログに表示されます。これらの改善点の詳細は、 ドキュメントを参照 してください。 本記事は「 CDN Caching Improvements for Better App Performance with AWS Amplify Hosting 」を翻訳したものです。 著者について Zachary Goldberg Zach Goldberg is a Software Development Engineer at AWS Amplify Hosting. Zach builds features that make it easier for customers to host front-end web applications backed by the reliability and convenience of AWS. In his free time, Zach enjoys running, snowboarding, and baking bread. Jay Raval Jay Raval is a Solutions Architect on the AWS Amplify team. He ’ s passionate about solving complex customer problems in the front-end, web and mobile domain and addresses real-world architecture problems for development using front-end technologies and AWS. In his free time, he enjoys traveling and sports. You can find Jay on X @ _Jay_Raval_ Matt Auerbach Matt Auerbach is a NYC-based Product Manager on the AWS Amplify Team. He educates developers regarding products and offerings, and acts as the primary point of contact for assistance and feedback. Matt is a mild-mannered programmer who enjoys using technology to solve problems and making people ’ s lives easier. B night, however … well he does pretty much the same thing. You can find Matt on X @ mauerbac . He previously worked at Twitch, Optimizely & Twilio. 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

クラスターから直接ロードバランサーをプロビジョニングすることは、サービスを公開するための Kubernetes ネイティブの方法でしたが、場合によってはアプリケーションのアーキテクチャと合わないプロビジョニングプロセスになることがあります。そのため、別のメカニズムが必要とされます。この投稿で説明するユースケースでは、新しいロードバランサーをプロビジョニングせず、既存の Application Load Balancer (ALB)/ Network Load Balancer (NLB) のトラフィックを直接 service にルーティングする機能を提供します。 TargetGroupBinding と呼ばれるこの機能は、 カスタムリソース (CR) で、既存の ALB TargetGroup または NLB TargetGroup を使用して pod を公開できます。AWS Load Balancer Controller は、ingress および service リソースのサポート機能としても内部的に TargetGroupBinding を使用しています。TargetGroupBinding を使用すると、ユーザーはロードバランサーの作成と削除を service と ingress のライフサイクルから切り離すことができます。その結果、ユーザーは AWS インフラストラクチャのロードバランサーをネイティブの Kubernetes リソースから抽象化し、分離することができます。 図1 – TargetGroupBindingを使ってロードバランサーからEKSワークロードに接続 TargetGroupBinding は、インスタンスまたは IP の ターゲットタイプ のターゲットグループをサポートしています。ターゲットタイプが明示的に指定されていない場合、mutating webhook が自動的にターゲットグループのターゲットタイプを検出して正しい値に設定します。 明示的にロードバランサーのインフラストラクチャをプロビジョニングおよび管理するユースケースでは、Kubernetes ingress との分離が必要です。そして、TargetGroupBinding を使用すると、それぞれの service へのトラフィックをルーティングするための完全にダイナミックなソリューションを実現できます。 TargetGroupBinding パターン この記事では、Kubernetes ネイティブリソースでロードバランサーのライフサイクルを管理することが理想的でない使用例とアーキテクチャパターンを探ります。そのような場合、Kubernetes ネイティブリソース外でロードバランサーインフラストラクチャを管理する必要があり、TargetGroupBinding を使用して構成を動的に保つことができます。ハンズオンガイドについては、 このコンテナ記事 を参照してください。この記事では、AWS Load Balancer Controller における TargetGroupBinding と ingress リソース共有について詳しく説明しています。 グローバルトラフィックの分散 Kubernetes ワークロードに対するグローバルロードバランシングソリューションを探しているユーザーは、 AWS Global Accelerator と統合したロードバランサーの管理方法を必要としています。AWS Global Accelerator は、グローバルユーザーに提供するアプリケーションの可用性とパフォーマンスを向上させるネットワークサービスです。 次に、ユーザーは AWS Global Accelerator とロードバランサーを Kubernetes リソースプロビジョニングサイクルの外で作成および管理する必要があり、Kubernetes ワークロードにトラフィックをルーティングする方法が必要です。完全にダイナミックなソリューションを実現するには、TargetGroupBinding を使用すると、外部で管理される AWS Global Acceleratorとロードバランサーを Kubernetes service に連携させることができます。ユーザーは、選択した Infrastructure-as-Code (IaC) ツールで AWS Global Accelerator、ロードバランサー、 Amazon Elastic Kubernetes Service (Amazon EKS) インフラストラクチャをプロビジョニングし、TargetGroupBinding を使用してロードバランサーのターゲットグループを Amazon EKS に動的に関連付けることができます。 図 2 – AWS Global Accelerator と TargetGroupBinding を使用した Load Balancer を経由して EKS ワークロードへ Amazon EKS と AWS Global Accelerator を使用してマルチリージョンのグローバルアプリケーションを運用する詳細については、 こちらの投稿 を参照してください。完全にダイナミックなソリューションを実現するには、TargetGroupBinding を使用できます。 L4 および L7 リクエストの単一エンドポイント ユーザーは、この ネットワーキングとコンテンツ配信の投稿 で説明されているように、ALB の前に NLB を設定する必要がさまざまな理由で生じる場合があります。このような設定では、アプリケーションが L4 と L7 の両方で単一のエンドポイントを共有する必要がある場合や、アプリケーションの静的 IP アドレスを公開する場合や、ALB 用のエンドポイントを提供する必要がある場合があります。つまり、Kubernetes service の管理ライフサイクル (NLB から ALB へのルーティングの構成など) に関係なく、NLB と ALB の両方がプロビジョニングされ、構成されていることを確認する必要があります。この場合、TargetGroupBinding は、静的または事前定義された負荷分散構成を持つための機能を提供し、pod をターゲットとして動的に登録できるようになります。 図 3 – TargetGroupBinding を使用した EKS ワークロードへのレイヤー 7 とレイヤー 4 のトラフィックルーティング クラスターの blue/green アップグレード 多くの場合、ローリングアップデートを使用して EKS クラスターを直接アップグレードできます。ただし、ダウンタイムを減らし、前の状態に素早くロールバックできるようにするために、ユーザーは blue/green のアップグレードを好む場合があります。ユーザーは、新しい EKS クラスターを作成し、新旧クラスターで同一のロードバランサーを利用することで、blue/green のアップグレード戦略を実現できます。ユーザーは、各 EKS クラスター用に 1 つずつターゲットグループを作成したロードバランサーを使用できます。次に、TargetGroupBinding CRD を使用すると、Amazon EKS を作成されたターゲットグループに動的に関連付けることができます。ロードバランサーの ルール 内で、各ターゲットグループに送信するリクエストの重みを設定して、クラスター間のリクエストの移行を制御します。このソリューションの利点は、ユーザーがドメインネームサーバー (DNS)、存続可能時間 (TTL)、またはクライアントマシン上のキャッシュに依存しないことです。 図 4 – TargetGroupBinding を用いた EKS ワークロードへの blue/green トラフィックルーティング ハイブリッドデプロイ blue/green デプロイメントの場合と同様に、Amazon EKS ベースのアプリケーションと Amazon EKS ベースでないアプリケーション ( Amazon Elastic Compute Cloud (Amazon EC2 ) ベースのアプリケーションや AWS 外のアプリケーション) を並行して実行する必要がある場合、このパターンが役立ちます。TargetGroupBinding を使用すると、同じロードバランサーを使って並列の EKS クラスターにユーザートラフィックをルーティングできます。このパターンでは、TargetGroupBinding ユーザーは新しいターゲットグループを追加することで、同一のロードバランサーを使って新しい Amazon EKS ワークロードにトラフィックをルーティングできます。CR は、作成されたターゲットグループに service を動的にバインドする処理を行います。 図 5 – TargetGroupBinding を使用したハイブリッド (EKS と非 EKS) ワークロードへのトラフィックルーティング この同じ戦略は、コンテナ化されていない環境、オンプレミス環境、または他のコンテナプラットフォームから Amazon EKS へのワークロードトラフィックの移行を計画する際にも適用できます。 まとめ この投稿では、ALB と Kubernetes service のライフサイクルを分離することが最適な一般的なユースケースについて説明しました。これにより、AWS Load Balancer Controller で TargetGroupBinding 機能を使用するタイミングを選択できます。アプリケーションに最適なアーキテクチャを設計することをお勧めします。Kubernetes service/ingress 構成のライフサイクルに合わせて「無理に」設計する必要はありません。ただし、アプリケーションのルーティング構成を実装する場合は、すべての構成にメリットとデメリットがあることに注意してください。TargetGroupBinding を使用すると、Kubernetes 外で作成される ALB/NLB に Kubernetes service をバインドする明示的な手段の恩恵を受けられる一方で、Kubernetes インストールに付属していないカスタム CRD 実装 (ローカル開発クラスターなど) を使用する必要があります。ALB と TargetGroupBinding のすべての潜在的な構成の詳細については、 ドキュメント を参照してください。 翻訳はソリューションアーキテクト祖父江が担当しました。原文は こちら です。

はじめに 自動車業界がコネクティッドカーと自動運転の未来を目指して急ピッチで進む中、サイバーセキュリティは重要な課題となっています。車両がソフトウェア、センサー、接続性に依存するようになるにつれ、サイバー攻撃の標的にもなりかねません。この課題を認識して、国際連合欧州経済委員会 (UNECE) は、自動車に関する法的調和のための世界フォーラム (WP.29) を導入し、コネクティッドカーのサイバーセキュリティとソフトウェアアップデートに関する画期的な規制を策定しました。 UNECE WP.29 の概要 国際連合欧州経済委員会 (UNECE) の車両規則統一世界フォーラム ( WP.29 ) は、国家間の車両規制の統一化を目指すグローバルなフォーラムです。自動車業界向けにサイバーセキュリティの規制とガイドラインである UNECE WP.29 を策定しています。 これらの規制は、以下のようなネットワーク接続された車両のサイバーセキュリティの様々な側面をカバーしています。 リスク管理 安全なソフトウェアアップデート セキュアな通信 インシデント対応 テストとアセスメント 具体的には、サイバーセキュリティに関する UN 規則第 155 号と、ソフトウェアアップデートに関する UN 規則第 156 号は、自動車業界の姿を変えるものとなるでしょう。 これらの規則により、メーカーには、車両のライフサイクル全体を通してサイバーセキュリティ管理システム (CSMS) とソフトウェアアップデート管理システム (SUMS) を確実に実装することが義務付けられます。 この変化に対応するには、堅牢で拡張性とセキュリティを備えた IoT インフラストラクチャが必要不可欠です。この要求に Amazon Web Services (AWS) IoT がうまく対応できるよう整備されています。 なぜ重要なのか: 自動車のサイバーセキュリティ に関する UNECE 規則第 155 号により、2024 年 7 月以降、EU 加盟国、英国、日本、韓国を含む 54 カ国の OEM によって生産するすべての車両は、WP.29 国連車両規則調和世界フォーラムが定めた厳しいサイバーセキュリティ要件を満たす必要があります。この規制は、コネクティッドカーのサイバーセキュリティを確保し、運用の混乱、データ漏えい、安全リスクなど、深刻な結果を招くサイバー脅威から守ることを目的としています。 AWS IoT の概要 AWS IoT は、自動車メーカーが UNECE WP.29 の要件を満たし、それを超えることを支援する一連のサービスを提供します。 これらの機能は、WP.29 の安全な通信チャネルおよび「セキュリティ・バイ・デザイン」の原則に重点を置いたものです。 デバイス接続とメッセージング: AWS IoT Core は MQTTなどのプロトコルをサポートし、x.509証明書による安全なデバイス認証を実現します。 デバイス管理: AWS IoT Device Management は、オンボーディング、組織化、監視、リモート管理、および OTA 更新を提供し、UN 規則第 156 号に従ったソフトウェアセキュリティの維持に不可欠です。 セキュリティ監視: AWS IoT Device Defender は、車両の異常な挙動を監視し、逸脱があった場合に警告を発し、 UN 規則第 155 号で義務付けられているリスク評価とインシデント対応をサポートします。 データ処理と分析: Amazon Kinesis Data Analytics ストリームは、車両の挙動とユーザーパターンを理解するのを支援し、車両全体のセキュリティ脅威と脆弱性を特定するのに役立ちます。 アーキテクチャの概要 このアーキテクチャでは、 AWS IoT Core を使用してコネクティッドカーへの接続と認証を行います。 AWS IoT Device Management の一部である AWS IoT Jobs により、スケジューリング、リトライやステータスレポートなどを含む、ソフトウェアアップデートの展開やリモート操作を管理できます。 AWS IoT Device Defender は車両の異常を監査および監視し、 AWS IoT Rules によりデータを Amazon Kinesis Data Streams に送信し、リアルタイム分析を行います。 図 1.0 : AWS サービスを使用して WP.29 準拠するコネクティッドカー 前提条件 AWS IoT ワークショップ の開始に従って AWS 開発環境のセットアップ を実施するか、あるいは独自の EC2 開発環境をセットアップして、手順をすすめることができます。 バージョン管理が有効になっている Amazon Simple Storage Service (Amazon S3) のアーティファクトバケットに、テストアプリケーションを格納します。 AWS IoT Core の モノ としてのへコネクティッドカー。この記事では、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上に AWS IoT Device Client ソフトウェアをインストールすることで、仮想のコネクティッドカーをシミュレートします。 AWS IoT ワークショップの開始 では、シュミレートした仮想 IoT デバイスの設定について詳しい手順が示されています。 手順 この手順では、シミュレートされたコネクティッドカーをセットアップし、OTA を実行し、車両の動作を積極的に監視し、車両のデータに分析を適用します。 AWS IoT やその他の AWS サービスを利用して、WP.29 要件を満たす機能を実演します。 前提条件を満たしていれば、AWS Cloud9 の環境が用意できています。これを使用して、仮想のコネクティッドカーをセットアップし、AWS IoT に接続します。 AWS IoT コネクティッドカーの作成 (AWS コンソール) ステップ 1: シミュレートされたコネクティッドカーを作成 (AWS IoT Thing) AWS IoT Core コンソール を開きます ナビゲーションペインの 管理 の下にある すべてのデバイス を選択します モノ を選択します モノを作成 を選択し、 1 つのモノを作成 を選択します モノの名前に SimulatedConnectedVehicle を入力します 図 1.1 : AWS IoT Thing の作成 デバイス証明書については、推奨オプションを使用します。（図 1.2 参照） 図 1.2: デバイス証明書の選択 ステップ 2: ポリシーを作成して AWS IoT のモノに割り当て ポリシーをアタッチのセクションで、 ポリシーを作成 を選択します ポリシー名に wp29TestPolicy を入力し、 JSON を選択します 以下の JSON コンテンツに置き換えます region、your-account-id を適宜更新します 作成 を選択し、ポリシー作成を完了します { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iot:Connect", "iot:Subscribe", "iot:Receive", "iot:Publish" ], "Resource": [ "arn:aws:iot:eu-west-1:your-account-id:client/SimulatedConnectedVehicle", "arn:aws:iot:eu-west-1:your-account-id:thing/SimulatedConnectedVehicle", "arn:aws:iot:eu-west-1:your-account-id:topic/*", "arn:aws:iot:eu-west-1:your-account-id:topicfilter/*" ] }, { "Effect": "Allow", "Action": [ "iot:DescribeJob", "iot:CreateJob", "iot:UpdateJob", "iot:DeleteJob", "iot:CancelJob", "iot:StartNextPendingJobExecution", "iot:DescribeJobExecution", "iot:UpdateJobExecution", "iot:DeleteJobExecution" ], "Resource": [ "arn:aws:iot:eu-west-1:your-account-id:job/*", "arn:aws:iot:eu-west-1:your-account-id:thing/SimulatedConnectedVehicle", "arn:aws:iot:eu-west-1:your-account-id:jobexecution/*" ] } ] } JSON ステップ 3: コネクティッドカーのモノへポリシーを割り当て 前のステップでポリシーの作成が完了したら、このポリシーをモノに割り当て、モノを作成します。 (図 1.3 参照) 図 1.3 :ポリシーをモノに割り当て ステップ 4: デバイス証明書と鍵をダウンロード ダウンロードプロンプトからダウンロードします。 (図 1.4 参照) デバイス証明書 パブリックキーファイル プライベートキーファイル Amazon ルート CA 図 1.4 :証明書とキーをダウンロード これらの認証情報は、 SimulatedConnectedVehicle を AWS IoT に接続し、AWS 開発環境 (上で作成) にアップロードするために使用するので、安全に保存します。 ステップ 5: AWS IoT Device Client をインストール AWS IoT デバイスクライアントワークショップのセクションに従い、 ここに記載されている 手順に従ってデバイスクライアントをインストールします。 このブログの前のステップで作成した認証情報を使用し、 Specify thing name (Also used as Client ID) が出力されたら、前に作成した SimulatedConnectedVehicle というモノの名前を使用します。 Over-the-air(OTA) アップデートのリモート操作 デバイスが相互に接続された現代の世界では、ファームウェアを最新の状態に保つことがセキュリティ、パフォーマンス、機能面で極めて重要です。 Over-the-Air (OTA) アップデートは、デバイスを遠隔でアップデートするシームレスな方法を提供し、物理的なアクセスを必要とせずに、常に最新のソフトウェアを常に実行できるようにします。 AWS IoT Device Management Jobs を使用して、コネクティッドカーのファームウェアを更新する OTA アップデートを行う方法を見ていきましょう。 このワークショップ で説明されている手順を実行し、Jobs が AWS 管理のテンプレートを提供していることにより、AWS IoT Core に接続されたデバイスへのリモート操作がとても簡単で効率的かを見てみましょう。 ここ に記載されている手順にしたがって、独自カスタム Jobs の手順とウォークスルーを作成することもできます。 積極的なセキュリティ監視 ： コネクテッドカーの安全性とコンプライアンスを確保 AWS IoT Device Defender を使用すると、継続的なセキュリティ監視を確立でき、全体的なセキュリティを強化できます。 このサービスは、送受信するメッセージの増加 (「おしゃべり」なデバイスであることを示す) 、車両からの頻繁な接続試行、または急速かつ頻繁な切断などの異常を検出することができます。これらの異常がトリガーを促し、潜在的な安全保障上の脅威に対する積極的な対応を可能にします。このアプローチは、継続的なリスク評価をサポートするだけでなく、UN 規則第 155 号の厳格な基準にも沿っています。 このワークショップ で説明されている手順に従って、AWS IoT Device Defender を使用して積極的なセキュリティ監視と監査を実現する方法を確認します。 ストリーミングデータ分析: Amazon Kinesis Data Analytics (Apache Flink) の使用 Amazon Kinesis Data Analytics の ストリームを使ったデータ分析は、車両の動作とユーザーの行動パターンを理解する上で非常に重要です。 このデータを分析することで、車両全体の新たな傾向とパターンを特定することができ、より多くの情報に基づいた意思決定と全体的なパフォーマンス向上が可能になります。 Amazon Kinesis Data AnalyticsにデータをファンアウトするためにAWS IoT Rulesをセットアップしましょう ステップ 1: AWS IoT デバイスクライアントの設定を変更 AWS IoT デバイス クライアント設定を変更して、 publish-on-change を含めるようにします。この機能は、指定されたパブリッシュファイル ( /home/ubuntu/workshop_dc/pubfile.txt ) にデータを書き込むたびにパブリッシュアクションがトリガーされます。 AWS IoT デバイスクライアントはこの変更を検知し、 /topic/workshop/dc/pub トピックとして AWS IoT Core に送信します。 次のコマンドを実行して、設定ファイルを編集します: sudo vim /etc/.aws-iot-device-client/aws-iot-device-client.conf 以下を追加します: “publish-on-change”: true サンプルセクションの設定は、” Publish-on-change ” を追加すると次のようになります: 図 1.5: AWS IoT デバイスクライアントの設定変更 ステップ 2: AWS IoT デバイスクライアントを再起動 前のステップで publish-on-change を追加して設定を変更したら、AWS IoT デバイスクライアントを再起動します。 次のコマンドを実行して再起動します: sudo systemctl restart aws-iot-device-client Bash ステップ 3: 車両データのシミュレーション コネクテッドカーのシミュレーションデータジェネレーターを設定し、AWS IoT Core にストリーミングします。ファイル ( vehicle_data_generator.py ) を作成し、これを実行すると、車両の状態、DTC (故障診断コード)、位置情報、ドライバーの行動、バッテリー状態を含むランダムデータが常にストリーミングされます。 ファイルを設定するために次のコマンドを実行し、コードをダウンロードします: cd /home/ubuntu/workshop_dc vim vehicle_data_generator.py Bash ファイル ( vehicle_data_generator.py ) に次のコードを入力します: import json import time import random import logging from datetime import datetime , timezone from pathlib import Path # Set up logging logging . basicConfig ( level = logging . INFO , format = '%(asctime)s - %(levelname)s - %(message)s' ) logger = logging . getLogger ( __name__ ) # File path FILE_PATH = Path ( "/home/ubuntu/workshop_dc/pubfile.txt" ) def generate_vehicle_status ( ) : return { "vehicleId" : "VIN123456789" , "timestamp" : datetime . now ( timezone . utc ) . isoformat ( ) , "status" : { "ignition" : random . choice ( [ "ON" , "OFF" ] ) , "speed" : round ( random . uniform ( 0 , 120 ) , 1 ) , "fuelLevel" : round ( random . uniform ( 0 , 100 ) , 1 ) , "batteryLevel" : round ( random . uniform ( 0 , 100 ) , 1 ) , "odometer" : round ( random . uniform ( 0 , 100000 ) , 1 ) , "engineTemp" : round ( random . uniform ( 70 , 110 ) , 1 ) , "tirePressure" : { "frontLeft" : round ( random . uniform ( 30 , 35 ) , 1 ) , "frontRight" : round ( random . uniform ( 30 , 35 ) , 1 ) , "rearLeft" : round ( random . uniform ( 30 , 35 ) , 1 ) , "rearRight" : round ( random . uniform ( 30 , 35 ) , 1 ) } } } def generate_dtcs ( ) : return { "vehicleId" : "VIN987654321" , "timestamp" : datetime . now ( timezone . utc ) . isoformat ( ) , "dtcs" : [ { "code" : "P0" + str ( random . randint ( 100 , 999 ) ) , "description" : "Random DTC Description" , "severity" : random . choice ( [ "WARNING" , "CRITICAL" , "INFO" ] ) } ] } def generate_location ( ) : return { "vehicleId" : "VIN246813579" , "timestamp" : datetime . now ( timezone . utc ) . isoformat ( ) , "location" : { "latitude" : round ( random . uniform ( 30 , 45 ) , 4 ) , "longitude" : round ( random . uniform ( - 125 , - 70 ) , 4 ) , "altitude" : round ( random . uniform ( 0 , 1000 ) , 1 ) , "heading" : round ( random . uniform ( 0 , 359 ) , 1 ) , "speed" : round ( random . uniform ( 0 , 120 ) , 1 ) } } def generate_driver_behavior ( ) : return { "vehicleId" : "VIN135792468" , "timestamp" : datetime . now ( timezone . utc ) . isoformat ( ) , "driverBehavior" : { "harshAccelerations" : random . randint ( 0 , 5 ) , "harshBraking" : random . randint ( 0 , 5 ) , "speedingEvents" : random . randint ( 0 , 10 ) , "averageSpeed" : round ( random . uniform ( 40 , 80 ) , 1 ) , "idlingTime" : random . randint ( 0 , 600 ) , "fuelEfficiency" : round ( random . uniform ( 20 , 40 ) , 1 ) } } def generate_battery_status ( ) : return { "vehicleId" : "VIN753951456" , "timestamp" : datetime . now ( timezone . utc ) . isoformat ( ) , "batteryStatus" : { "stateOfCharge" : round ( random . uniform ( 0 , 100 ) , 1 ) , "range" : round ( random . uniform ( 0 , 300 ) , 1 ) , "chargingStatus" : random . choice ( [ "CHARGING" , "NOT_CHARGING" ] ) , "voltage" : round ( random . uniform ( 350 , 400 ) , 1 ) , "current" : round ( random . uniform ( - 200 , 200 ) , 1 ) , "temperature" : round ( random . uniform ( 20 , 40 ) , 1 ) , "healthStatus" : random . choice ( [ "GOOD" , "FAIR" , "POOR" ] ) } } def write_to_file ( data ) : try : # Ensure the directory exists FILE_PATH . parent . mkdir ( parents = True , exist_ok = True ) # Write the data to the file with FILE_PATH . open ( 'w' ) as f : json . dump ( data , f ) logger . info ( f"Successfully wrote data to { FILE_PATH } " ) except PermissionError : logger . error ( f"Permission denied when trying to write to { FILE_PATH } " ) except IOError as e : logger . error ( f"I/O error occurred when writing to { FILE_PATH } : { e } " ) except Exception as e : logger . error ( f"Unexpected error occurred when writing to { FILE_PATH } : { e } " ) def main ( ) : generators = [ generate_vehicle_status , generate_dtcs , generate_location , generate_driver_behavior , generate_battery_status ] while True : try : data = random . choice ( generators ) ( ) write_to_file ( data ) time . sleep ( 10 ) except KeyboardInterrupt : logger . info ( "Script terminated by user" ) break except Exception as e : logger . error ( f"An unexpected error occurred: { e } " ) time . sleep ( 10 ) # Wait before retrying if __name__ == "__main__" : try : main ( ) except Exception as e : logger . critical ( f"Critical error occurred: { e } " ) Python コード (またはファイル) をコピーしたら、次のコマンドでコードを実行します。 python3 vehicle_data_generator.py 実行に成功すると、以下のように表示されます: INFO – Successfully wrote data to /home/ubuntu/workshop_dc/pubfile.txt AWS IoT Core コンソールで以下に移動します: テスト MQTT テストクライアント トピックをサブスクライブする: /topic/workshop/dc/pub 到着しているデータのストリームが確認できるはずです; このデータは分析に使用するものと同じです。 図 1.6: AWS IoT Core に到着するデータを示す MQTT トピック ステップ 4: AWS IoT Rule を作成 AWS IoT Core にデータが到着することが分かれば、BI 目的で AWS 分析サービスにデータをルーティングするための AWS IoT Rules をセットアップできます。 AWS IoT Core コンソール に移動します ナビゲーションペインの 管理 の下にある メッセージのルーティング を選択します ルール を選択します ルールを作成 を選択します 適切なルール名とルールの説明を入力し、「次へ」を選択します 。(図 1.7 参照) 図 1.7: AWS IoT Rule を作成 SQL ステートメントを設定 セクションで、以下の SQL ステートメントを入力し、 次へ を選択します: SELECT * FROM '/topic/workshop/dc/pub' ルールアクションをアタッチ セクションで、Kinesis Data Stream を選択し、以下を作成します: アクション 1 名前を指定してストリームを作成: simulatedVehicleData パーティションキー: ${newuuid()} IAMロールの選択と作成: simulatedVehicleRole エラーアクション AWS IoTトピックへのリパブリッシュを選択: /topic/workshop/dc/streamError IAM ロールを選択: simulatedVehicleRole 完了したら進んで 作成 を選択します。 図 1.8: AWS IoT Rules アクション ステップ 5: Apache Flink と Apache Zeppelin を使って Amazon Kinesis Data Streams のストリーミングデータを確認 この段階では、Amazon Kinesis Data Streams ( simulatedVehicleData ) にデータがストリーミングされます。 コンソールで Amazon Kinesis Data Streams に移動し、ストリームを選択します。 (図 1.9 参照) 図 1.9: シミュレーションされた車両データのストリーム データ分析タブを選択し、 I agree を選択した後、 Create notebook を選択します。 (図 2.0 参照) 図 2.0: Apache Flink Studio ノートブックの作成 Studio ノートブックが作成されたら、ストリーミングデータを選択して表示できるはずです。 (図 2.1 参照) 図 2.1: ストリーミングデータビュー これで、ストリーミングデータの可視化を作成できるはずです。 クリーンアップ 不要な請求を避けるために、メインの CloudFormation テンプレート (ネストされたスタックではない)、Amazon EC2 インスタンス (開発用に作成した場合)、Amazon S3 バケット (このブログ用に新しく作成した場合)、IoT のモノと関連するポリシー、Kinesis Data Stream (AWS 管理の Apache Flink と Apache Zeppelin を含む) を削除します。 まとめ UNECE WP.29 規制は、コネクティッドカーのサイバーセキュリティを確保する上で重要なステップを示しています。この規制は、自動車業界に対し、車両の設計、製造、運用のあらゆる側面にセキュリティを組み込むよう要求しています。AWS IoT サービスは、これらの課題に対処するための包括的でスケーラブル、かつセキュアな基盤を提供します。 コネクティッドかつ自動運転の未来には、UNECE WP.29 などの厳格な規制を革新的なテクノロジーとシームレスに統合することを要求します。 AWS IoT では、この連携を効果的に実現するサービスを提供しています。 この統合は単なる規制への準拠を超えたものです; 消費者の信頼を気づき、相互接続が進む世界における安全性を確保するものです。 サイバーセキュリティの懸念に積極的に取り組むことで、個々の車両の安全性を確保するだけでなく、将来のモビリティ基盤そのものを守ることができるのです。 関連するリンク Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system AWS IoT Zero Trust workshop 著者について Syed Rehan Sysed Rehan は、Amazon Web Services(AWS)のIoTセキュリティ組織内で活動するシニアサイバーセキュリティ製品マネージャーです。AWS IoT 、機械学習、サイバーセキュリティに関する書籍の著者として、グローバルな役割に幅広い専門知識をもたらしています。サイードは、セキュリティ専門家、CISO、開発者、セキュリティ意思決定者と協力し、AWS セキュリティサービスとソリューションの採用を促進するために、多様な顧客層を抱えています。サイバーセキュリティ、機械学習、人工知能、IoT 、クラウド技術に関する深い知識を持ち、新興企業から大企業まで幅広い顧客を支援しています。AWS 環境内で安全な IoT 、ML 、AI ベースのソリューションを構築できるようにしています。 この記事は Sysed Rehan によって書かれた Securing the future of mobility: UNECE WP.29 and AWS IoT for connected vehicle cybersecurity の日本語訳です。この記事は 広域事業統括本部 ソリューションアーキテクト 久次米が翻訳しました。

デジタルカスタマーエンゲージメントを実現し、ユーザーを満足させ、新たな収益源を生み出すような、スマートでコネクテッド製品・装置を開発することは大変な挑戦です。これには、セキュアなアプリケーションを構築し、機器のデータを取り込み、必要に応じてスケールアップやダウンができる必要があります。また、製品や装置の使用状況や動作状態を可視化する必要があります。機械学習、アナリティクス、IoT (Internet of Things) などの先進技術を活用し、クラウド上にデータを取り込み、分析し、管理することで、これらの課題に対応できます。 製造業がデジタル化の新時代に入る中、テクノロジーの進化に先駆けて対応することが重要です。この進化の最前線にあるのが、アメリカ最大規模の製造テクノロジーの展示会「 IMTS (International Manufacturing Technology Show) 」です。2024年9月9日から14日まで、シカゴで開催される今年の IMTS は、装置メーカーや製造業の企業が生産性と収益性を向上させるための革新的なテクノロジーに触れられる展示会となることをお約束します。 この展示会に Amazon Web Services(AWS)も出展し、最新の産業データフレームワークがいかにスマートで高品質な製品につながるかをご紹介します。 North Building, Level 3 – Booth 236217 にご来訪ください。 IMTS 2024でAWSブースにご来訪いただく理由 AWS の IMTS 2024 での出展の中心は、革新性とテクノロジーを実演するインタラクティブなデモブースです。来場者は、e-bike のスマート工場デモ( こちら でプレビューをご覧になれます)、AWS サービスやソリューションを紹介するインタラクティブなキオスク、パートナーのキオスク、IoT デバイスウォール、 ブース内の講演会場など を体験できます。製品やマシンのデータを、生成 AI、機械学習、コンピュータービジョン、IoT などの技術と組み合わせて活用し、製品設計プロセスの改善、スマートな製品の創造、スマート製造の推進方法を学んでいただけます。 あらゆるデジタルトランスフォーメーションの取り組みにおいて、一つの重要なテーマが浮かび上がります。堅牢で現代的なデータ戦略の必要性です。AWS の産業データファブリックソリューションは、スケーラブルで、一元化され、統合された仕組みでデータを活用できるデータ管理アーキテクチャを実現します。高品質なデータセットに対し、経済的で、安全、簡単なアクセスを提供することで、ビジネスリーダーがデジタル産業トランスフォーメーションの基盤を構築し、保全、資材管理、プロセス最適化、スマート製品の導入などの幅広いユースケースで業務を最適化することを可能にします。 カンファレンスセッション AWS の IMTS 2024 での活動の目玉の1つが、IMTS カンファレンスの木曜日午前9時の「生成 AI が製造業のスキルギャップ解消に貢献する方法 (“ How Generative AI Can Help Close the Manufacturing Skills Gap ”) 」セッションです。このセッションでは、生成 AI がどのように製造業の深刻なスキルギャップに対処できるかを探ります。ブースではその他の生成 AI のユースケースも紹介しますので、ぜひお立ち寄りください。 また、AWS は北ホールのオートメーションステージでも2つのセッションを行います。水曜日午後2時に、AWS と Siemens が共同で「エッジからクラウドへの統合によるスマート製造の再構築:持続可能で知的な工場への Siemens の取り組み (“Reimagining Manufacturing with Edge-to-Cloud Integration: Siemens’ Journey to Sustainable, Intelligent Factories”) 」を発表します。同日午後2時には、AWS のお客様である INVISTA が「生成 AI のパワーでマシンオペレーターの体験を向上 (“Elevated machine operator experience with the power of generative AI.”)」と題して発表します。 パートナーエコシステム AWS は、イノベーションを推進する上でのコラボレーションの重要性を認識しており、AWS のパートナーは製造業界への先端ソリューションを提供する上で不可欠な役割を果たしています。IMTS 2024 では、AWS のブースやステージセッションでパートナーソリューションを紹介し、これらのコラボレーションがいかに迅速な成果を生み出し、製造業の未来を形作るかについて洞察を得ることができます。 イノベーションを直接体験下さい 製造業がデジタルトランスフォーメーションを受け入れる中、AWS は、製造業のお客様が最新の動向をリードできるようなソリューションとサービスを提供し続けています。生成 AI、機械学習、クラウドコンピューティングの力によって、装置メーカーや製造業の企業は、これまでにないレベルの効率性、品質、イノベーションを実現できるようになります。 IMTS 2024 は、製造業のお客様が AWS の変革力を直接体験する絶好の機会です。AWS のブースを訪れ、講演セッションに参加し、幅広いサービスやパートナーの提案を探求することで、AWS がいかにイノベーションを推進し、製造業の未来を形作っているかについての貴重な洞察が得られます。 e-bike のデモを実際に体験したり、 AWS for Industrial について詳しく学んだりするため、IMTS 会場の AWS ブース( North Building, Level 3 – 236217 – Automation ) にぜひお立ち寄りください。そして、あなたの事業とプロセスのデジタルトランスフォーメーションを始めましょう。 本ブログは、 Experience manufacturing innovation with AWS at IMTS 2024 を翻訳したものです。翻訳はソリューションアーキテクトの山本が担当しました。 Tiffany Pfremmer Tiffany は、Amazon Web Services のシニアマーケティングマネージャーで、製造業およびインダストリー分野を担当しています。Rockwell Automation で15年以上の経験を持ち、マーケティング、品質、サービスの様々な役割を経験しています。Tiffany は、製造業者のバリューチェーンのあらゆる側面にわたって、マーケティングとカスタマーフォーカスのソリューション提供に注力してきました。

はじめに サプライチェーンの俊敏性は、組織が競争力を維持するために不可欠です。消費者の需要、新しい技術、経済の状況によって、需要と供給のバランスが崩れる可能性があります。需要計画、つまり顧客需要を満たすために必要な製品、原材料、部品の数量を正確に見積もることは、サプライチェーンの主要な課題の 1 つです。効果的な需要計画を立てることで、組織が在庫切れを回避し、過剰在庫を最小限に抑え、リソースの活用を最適化するのに役立ちます。この課題は幅広い業界に影響します。医療分野では、クリニック、病院、医療流通網全体にわたる分断されたデータと制限された可視性により、消費量と在庫レベルを正確に把握することが問題となっています。これにより、倉庫スペースへの過剰な投資や、在庫管理の不備による回収対象商品や期限切れ製品を使用してしまうなどのコストがかかる可能性があります。小売業界でも、動的な消費者行動と需要のシフトに対する準備不足もあり、実際の顧客需要の規格化されたエンドツーエンドの可視性を実現し、適切な製品在庫を適切な場所に配置することが困難です。製造業や自動車産業では、さまざまなパートナーが運営する多様ななシステムにまたがった部品・完成品のグローバルサプライチェーンネットワークにより、時間の遅れ、データの断片化、データ形式の不一致が生じます。これにより、正確な在庫の見通しが曖昧になり、最適な在庫レベルと配置を決定することが非常に困難になります。その影響は深刻で、出荷の遅れ、部品不足、輸送の混乱が損失を発生させ、混乱を引き起こす可能性があります。 ある医療技術企業は、供給計画で使用されていた不正確な契約ベンダーのリードタイムデータが在庫水準、供給計画の精度、および顧客注文の充足率に悪影響を及ぼすという事業上の課題に直面していました。ベンダーのリードタイム検出を改善するための社内イニシアチブが進行中でしたが、これらの手作業の取り組みには多大な時間と投資が必要で検証されていませんでした。AI 活用のビジネス戦略に沿って、同社は AWS Supply Chain の Vendor Lead Time Insights を導入しました。これにより、機械学習 (ML) モデルを活用して、運用に影響を与えるベンダーのリードタイム問題を特定する検証済みで実証された迅速なソリューションが提供されました。 この企業は、サプライチェーン運営の可視性を向上させるために、AWS Supply Chain の Vendor Lead Time Insights を選択しました。明確な ML ベースの洞察により、最も問題のあるベンダーが明らかにされ、供給計画の改善に向けた集中的な対策が可能になりました。調達した製品の平均で、契約上の予定リードタイムを大幅に超過し、予定よりも遅れて納品されていることが判明しました。この貴重な洞察により、企業は契約リードタイムを大幅に超過したケースの大部分を占めるベンダーを特定することができました。このデータ主導のインテリジェンスを活用し、この企業は計画システムのマスターデータの更新や、より大きな影響力をもってベンダーと交渉するなど、対象を絞った対策を講じることができます。 この企業は、供給計画プロセスのための正確で最新の情報を維持するため、最新の取引データを四半期ごとに追加して、Vendor Lead Time Insights を継続的に更新します。さらに、同社は自社内のリードタイムにも同様の可視性を提供するために AWS Supply Chain の拡張を検討しており、これによりサプライチェーンの回復力がさらに強化されます。 このブログ記事では、AWS Supply Chain の Vendor Lead Time Insights がベンダーのリードタイムの可視性を向上させ、供給計画の精度を高め、サプライチェーン運用を合理化する方法について説明しています。また、Vendor Lead Time Insights の概要を簡単に紹介し、この機能が在庫管理の最適化と顧客満足度の向上につながる役割を果たすことを明らかにしています。 Vendor Lead Time Insights を活用した供給計画の改善 AWS Supply Chain は、サプライチェーン全体でのリードタイム変動を検出することで、計画の精度を向上させるクラウドベースのアプリケーションです。これにより企業は顧客満足度を損なうことなく、より良いコスト管理戦略を実施できるようになります。AWS Supply Chain の Vendor Lead Time Insights は、過去の受注データ、出荷、在庫移動、季節性パターンなどの関連要因を分析することで、実際のベンダーリードタイムに関する洞察をデータに基づいて作り出します。ML モデルはこのデータから継続的に学習し、予想リードタイムからの逸脱を検出し、特定のサイト、製品、輸送方法に合わせて契約書面上の大まかな見積りに頼らず、データに基づく最新の予測を提供します。 従来、プランナーは供給業者からの平均リードタイムと需要予測を使用して、必要在庫レベルを決定してきました。しかし、この方法では、輸送の遅延、港湾の混雑、または供給業者の活動停止による実際の変動を考慮できません。これを補うため、プランナーは多くの場合、任意の安全在庫バッファを追加しますが、これは企業に過剰在庫を抱えさせることになり、非効率的で費用がかかるアプローチとなっています。平均値に依存すると、リードタイムが予想より長くても短くても、正確な計画を立てることができません。ベンダーリードタイムインサイトの ML 対応機能により、企業の担当者は詳細な洞察を得て、的確な意思決定を行い、計画プロセスを改善できるようになります。例えば、過去のデータから特定の配送センターへの出荷で、ベンダーが常に見積もりより 5 日遅れて納品していることがわかれば、ML モデルはリードタイム見積もりを適宜調整することを推奨します。組織は、製品 – サイト – ロケーションの組み合わせすべてについて、ワンクリックでベンダーリードタイム推奨値を生成およびエクスポートできるため、データに基づいたサプライチェーン計画と実行が可能になります。 以前の ブログ をご覧いただき、AWS Supply Chain インスタンスの作成前提条件と初期設定手順についてご確認ください。また、モジュールの詳細な設定情報については、Insights の ユーザガイド を参照してください。次のスクリーンショットは、Lead Time Insights のダッシュボードを示しており、ベンダーの輸送方法や発注元の位置など、重要な要因に着目して、製品のリードタイム逸脱をお知らせします。このアプリケーションでは、特定の洞察ウォッチリストで設定されたすべての製品 – サイト – ベンダーのリードタイム推奨事項を可視化し、エクスポート可能なファイルも提供されます。ダッシュボード上の任意の行を選択すると、詳細情報を確認できます。 行をダブルクリックすると、部品やサプライヤーの購買発注納品実績の詳細が表示される画面に移動します。また、アプリケーションには、製品、サイト、ベンダーに合わせて、過去の実績に基づいて ML で生成されたリードタイム推奨値が提供されます。 AWS Supply Chain の Lead Time Insights を使用すると、より正確にリードタイムの変動を検出できるようになります。&nbsp; まとめ 今日の絶え間なく進化するビジネス環境において、効果的なサプライチェーン管理は重要な差別化要因となっています。企業は、急速に変化する消費者の需要、技術の進歩、経済の変動、そして激しい競争に適応しなければなりません。平均リードタイムに依存する従来の供給計画手法では、これらの動的な課題に対処することが困難です。しかし、機械学習 (ML) を供給計画プロセスに統合することで、運用効率を向上させる AWS Supply Chain の Vendor Lead Time Insights の恩恵を受けることで企業はデータ主導の意思決定を可能になります。 前述の医療技術企業は、AWS Supply Chain の Vendor Lead Time Insights から大きな成果を上げており、サプライヤーとの効果的な交渉と計画システムにおける正確なリードタイム データの実現に注力できました。また、以下の分野で継続的な改善が期待されています。 在庫の最適化と運転資金の効率化: リードタイムの変動を正確に把握することで、在庫水準の改善と過剰在庫を削減し、運転資金を他の戦略的投資に振り向けることができます。 サプライヤーの契約遵守とパフォーマンス管理: データに基づくベンダーのリードタイム実績の分析により、遵守違反の問題を積極的に特定し対処することで、サプライヤーとの良好な関係と説明責任を育むことができます。 計画の信頼性向上による顧客サービスレベルの向上: ML によるリードタイム予測の精度と信頼性が高まることで、顧客サービスレベルが向上します。 AWS Supply Chain の Vendor Lead Time Insights は、供給計画に変革をもたらすアプローチです。強力な機械学習アルゴリズムを利用可能なデータに適用することで、組織がリードタイム平均に基づく計画に依存しないようにします。そして組織はリードタイム予測に関して、より正確なデータ主導のアプローチを採用できます。このアプローチは在庫水準を最適化し、可視性と説明可能性の向上を通じてベンダーとの強固な関係を育みます。組織は過剰在庫と関連コストを削減することで収益性を高めることができます。最終的に、AWS Supply Chain の Vendor Lead Time Insights によって可能になるサプライチェーン能力の向上は、顧客満足度の向上につながります。 AWS Supply Chain を始めるのは簡単で、前払いのライセンス料や長期契約は必要ありません。以下の 3 ステップで始められます。 AWS Supply Chain について学ぶ: AWS Supply Chain の ウェブサイト を訪れ、製品の機能と能力を理解する。 技術的な概要を知る: AWS Workshop Studio で自分のペースで進められる技術的なウォークスルーを探索する。インスタンスの作成、データの取り込み、ユーザーインターフェースの操作、インサイトの作成、需要計画の生成方法を学ぶ。 AWS Supply Chain を使い始める: 準備ができたら、 AWS Console にアクセスし、AWS Supply Chain の効率的でデータ主導の管理ツールを使って、サプライチェーンの運用を合理化する。詳細な設定手順と追加のガイダンスについては ユーザーガイド にアクセスしてください。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 <!-- '"` --> 著者について Shree Vivek Selvaraj は、AWS Supply Chain のシニアスペシャリストソリューションアーキテクトです。彼の役割は、サプライチェーン幹部と技術アーキテクトと協力し、顧客の問題を理解し、意図したビジネス成果を達成するための適切なソリューションを提案することです。彼は、重工業、バイオ製薬、ハイテク、小売りEコマースなど、フォーチュン 500 企業の幅広い業界で、オペレーション、サプライチェーン、リーン &amp; シックスシグマ、コア製品管理を通じて14年以上の業界経験を持っています。Shree はグレーターオースティンエリアに拠点を置いています。 <!-- '"` -->

はじめに AWS Customer Solutions Manager の甲斐です。オンプレミスから AWS へのシステム移行は、単純なシステム変更に留まらずプロセス変革やチームの役割の変更を伴うため、これらに最適化した組織体制の構築が重要です。システムが AWS に移行したとしても、組織が旧来型のオンプレミス前提のままでは、AWS のメリットを最大限享受できません。本ブログでは、AWS への組織体系の変更における考慮点を具体的な例を交えて 前編 ／後編に分けて提示します 後編では、AWS 活用に伴い発足する新たな組織の位置づけと組織文化の変化について記載していきます。 5．横断組織 (CCoE)の必要性 AWS の活用を通して、従来必要だった工数やタスクの負担が軽減されるものの、新たな役割も必要となります。まず重要なのが、ユーザー管理、権限管理、コスト管理を一元的に行う役割です。AWS アカウントの一元的な管理できず各事業部が自由に利用している場合、セキュリティ上のリスクや想定外のコストが発生する可能性があります。AWS では、これらの課題を解決するためのサービスが提供されています。例えば複数のアカウントの管理には AWS Control Tower などが活用できます。 また、AWS の従量課金モデルに伴い、利用コストの見える化と管理も重要になります。オンプレミスでは一度購買すればコストの変化は小さいですが、AWS では利用料に応じた課金となるため、コストの消費状況を監視・最適化する必要があります。AWS では AWS Cost Explorer や AWS Budgets など、コスト状況を可視化するサービスを提供しています。コストが想定以上に上振れている場合には、最適なインスタンスサイズの選択や不要なリソースの削除、起動時間の調整、Savings Plans の活用などを検討します。 さらに、AWS サービスが絶えず更新されていくため、自社のサービスもタイムリーにアップデートする役割が求められます。サービスの更新情報を把握し、利用者への周知・啓発を行うことで、最新のサービスを活用できるようになります。 ( 参考： AWS サービスアップデートまとめ ) これらの役割を組み込んだ組織を組成することで、AWS を安全かつ効果的に活用することができます。CCoE ( Cloud Center of Excellence ) の設立は有効な選択肢の1つです。CCoE は従来のインフラ部門の立ち位置とは異なり、AWS を活用してビジネス価値をもたらすために、利用者のよき相談役として機能することが理想です。CCoE は最初から正式組織として立ち上げる必要はなく、まずはバーチャル組織で展開し、次のステップで正式組織化する、といったステップも考えられます。組織の現状に合わせ、必要な役割を認識した上で、CCoE の立ち上げ方を検討するのが良いでしょう。CCoE についてはこちらのBlog も参照ください。( 参考： CCoE 活動検討のはじめの一歩 ） 6．組織変化を支える文化 組織体系の変化は、単なる構造の変更にとどまらず、組織の文化やメンバーの行動に深く影響を与えます。新しい価値観やプロセスが導入されることで、従来のやり方や考え方が見直され、組織全体に変革がもたらされます。この変化は、組織の一体感を強化し、より柔軟で効率的な業務運営を可能にするものです。本章では、組織文化への考慮すべきポイントについて記述します。 エグゼクティブのスポンサーシップ: エグゼクティブがクリアなビジョンと具体的な目標を示し、達成状況の追跡とリソース提供を行うことで、組織全体が変化に協力する文化が醸成されます。スポンサーシップが欠けると、変化への推進力が低下し、組織の目標達成が困難になります。 権限委譲と説明責任: メンバーに明確な所有権と説明責任を与えることで、意思決定が迅速化され、組織全体での改善が進みます。これにより、メンバーは組織の目標に向けて主体的に行動し、リスクを取ることが奨励され、継続的な改善が促進されます。一方で、権限や責任が不明確だと、対応の遅れや改善の停滞を引き起こします。権限委譲と説明責任の明確化は、組織の柔軟性と生産性を高める鍵となります。 オープンなエスカレーション: 組織内でエスカレーションが円滑に行われる文化を育むことが重要です。問題が早期に報告されることで、リスク管理が強化され、重大な問題に迅速に対処できるようになります。エスカレーションを奨励し、問題解決に真摯に取り組む姿勢を示すことで、健全な組織文化が構築され、メンバーは問題を隠さずに積極的に報告するようになります。 タイムリーで明確、かつ実用的なコミュニケーション: 組織全体に適時かつ明確なコミュニケーションを行うことで、変化に対する適応力を高めることができます。メンバーは変化の目的や意義を理解し、必要な情報をタイムリーに受け取ることで、業務をスムーズに遂行できます。コミュニケーションが不足すると、変化が遅れたり、メンバー間の理解が不十分になり、組織の目標達成に悪影響を及ぼす可能性があります。 実験の奨励: 組織がイノベーションを推進するためには、メンバーが新しいアイデアを試し、失敗から学ぶ文化を奨励することが重要です。適切な実験環境や機会を提供し、メンバーが安心して挑戦できるようにすることで、学習が加速し、組織の進化が促進されます。これにより、ビジネスの成果が向上し、組織全体でのイノベーションが進展します。 継続的な学習: 組織全体でスキル向上と知識の深化を支援する文化を構築することは、長期的な競争力の強化に不可欠です。体系的な教育プログラムや業界認証の取得を支援することで、メンバーのスキルが維持・向上し、組織のイノベーション力が高まります。継続的な学習を奨励することで、組織は変化に迅速に対応し、持続的な成長を遂げることができます。 適切なリソース配分: 効率的な運用を実現するためには、メンバーに適切なリソースを提供し、負担を適切に管理する文化が重要です。必要な人材やツールを適切に配置することで、チームの生産性と満足度が向上し、組織全体の運営が効率化されます。一方で、リソースが適切に配分されない場合、ヒューマンエラーや士気低下が発生し、組織の運営に悪影響を与える可能性があります。 これらの要素を組織文化に取り入れることで、AWS 移行に伴う組織変化と AWS のメリットを最大限に活用することが可能になります。 Well-Architected Frameworkの運用の優秀性の柱 (組織カルチャー) に上記ポイントにおけるメリットや実装ガイダンスも記載していますのでご活用ください。 7．まとめ オンプレミスから AWS へのシステム移行は、単なるシステム変更にとどまらず、組織プロセスやチームの役割変更を伴います。オンプレミスの組織文化とAWS での文化は大きく異なるため、これに最適化した組織体制の構築が重要です。 オンプレミスではIT 部門のインフラ担当がハードウェアの調達から運用管理を担当していましたが、AWS ではマネージドサービスの活用で運用負荷が軽減されます。アプリケーション部門がインフラ設定を自律的に推進し、DevOps の導入で開発と運用が一体化し、高速なアプリケーションリリースが可能になります。 さらに、AWS 移行に伴い新たな役割も必要となります。AWS アカウントの一元管理、コストの最適化、サービスアップデートへの追従など、AWS 活用を最大化する CCoE の設立が重要です。 また、AWS を最大限に活用するためには、 組織体系の変化だけでなく、組織文化も考慮する必要があります。エスカレーションの容認や実験の推奨などの要素を組織文化に取り入れるには、エグゼクティブによる強力なリーダーシップと組織全体の意識改革が不可欠となります。 ファーストステップとしては、組織として達成したいビジネス目標を定義し、組織として取り組むニーズの優先順位を明確することを推奨します。その際、 Well-Architected Framework の運用の優秀性の柱 (組織の優先順位) の活用も有効です。AWS の経験とベストプラクティスを活用できるため、合わせてご検討ください。 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー (CSM) 甲斐 裕之、山崎 徹 参考 Well-Architected Framework 運用上の優秀性の柱 https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/welcome.html CCoE 活動検討のはじめの一歩 https://aws.amazon.com/jp/blogs/news/how-to-define-your-own-ccoe-tasks/ 責任共有モデル https://aws.amazon.com/jp/compliance/shared-responsibility-model/ 責任共有モデルとは何か、を改めて考える https://aws.amazon.com/jp/blogs/news/rethinksharedresponsibility/ AWS Control Tower でコントロールを適用する際のベストプラクティス https://aws.amazon.com/jp/blogs/news/best-practices-for-applying-controls-with-aws-control-tower/

１．はじめに AWS Customer Solutions Manager の甲斐です。オンプレミスから AWS へのシステム移行は、単純なシステム変更に留まらず、プロセスやチームの役割の変更を伴うため、これらに最適化した組織体制の構築が重要です。組織体制が旧来型のオンプレミス前提のままでもシステムをAWSに移行できますが、移行後の運用フェーズでAWSのメリットを最大限享受することはできません。本ブログでは、AWS への組織体系の変更における考慮点を具体的な例を交えて前編／ 後編 に分けて提示します。前編では従来の組織における変化点についてご説明していきます。 ２．オンプレミスと AWS の違い 従来のオンプレミスでは、ハードウェアの調達から設定、運用までを自力で行う必要がありました。これらを担うIT部門のインフラ担当は、見積や調達・設置・運用保守など、広範な知識と複雑なプロセスが必要でした。AWS を利用する場合、数クリック、数分間でリソースを増減できるため、オンプレミスのような購買調達プロセスが簡略化されます。ハードウェアは AWS のサービスをインターネット経由で利用するため、自前での調達・設置、数年先を見据えた計画立案などが不要になります。さらに、マネージドサービスやサーバーレスなどのサービスを活用することで OS、ミドルウェアの設定・運用保守の運用負荷も軽減できます。 セキュリティについても、従来のオンプレミス環境とは異なる視点が必要です。AWS では、AWS 側とお客様側で責任範囲が分かれる「責任共有モデル」を理解する必要があります。AWS がクラウド環境自体の責任を、お客様にはクラウド内のセキュリティに対する責任と管理を担っていただきます。この共有モデルは、AWS がホストオペレーティングシステムの仮想化レイヤーからサービスが運用されている施設の物理的なセキュリティに至るまでの要素を AWS が運用、管理、および制御することから、お客様の運用上の負担の軽減に役立ちます。 ３．IT 部門の変化 ３－１．アプリケーション部門・インフラ部門の変化 IT 部門では、アプリケーション担当とインフラ担当の役割が明確に分かれているのが一般的です。システム開発においてはアプリケーション担当とインフラ担当の調整が発生し、開発スピードを低下させる要因となっていました。例えば、アプリケーション部門が新たな開発環境を調達する際、インフラ部門による構築・検証の完了を待つ必要があり、依頼からリードタイムが発生します。一方、AWS ではサーバーレス、マネージドサービス、IaC ( Infrastructure as Code )による環境の複製など、操作が容易で開発スピードを向上させるサービスが提供されています。アプリケーション部門がこれらの AWS サービスを有効活用することにより、インフラ部門の対応を待つことなく自力で環境を作ることができ、開発スピードの加速が可能となります。つまり、AWS の活用によって、従来の IT 部門組織における開発スピードの課題を解決することができるのです。アプリケーション部門が AWS サービスを活用することで、開発プロセスの効率化と迅速化が期待できます。 ３－２．運用部門の変化 開発スピードを向上するためには、開発と運用が一体となった DevOps 組織の編成が効果的です。DevOps は、従来の開発部門と運用部門の垣根を取り払い、両者が協力して素早くアプリケーションの改善を行うアプローチであり、クラウドの特性と適合しています。両者が分かれている場合、開発部門は目標としてリリース頻度や変更容易性を重視しますが、運用部門はシステムの安定性と効率化を重視する傾向があるため、部門間の対立・調整が課題となっていました。DevOps では開発と運用に取り組むメンバーが、同一の組織としてアプリケーションのライフサイクル全体を推進することで、目標が対立することなく開発を進めることができます。DevOps では自動化が重要な役割を果たします。アプリケーションのビルド、テスト、デプロイなどの工程を自動化することで、ヒューマンエラーを排除し、高速かつ安定したリリースサイクルを実現できます。 ３－３．組織の運用モデル AWSの Well-Architected Frameworkの運用の優秀性の柱 では、運用モデル 2 x 2 が表現されており、チーム間の関係を理解するのに役立ちます。また、モデルごとのガバナンスや意思決定プロセスについても提示しています。現在各チームがモデルの中でどの位置にいるか、チームの関係と責任がどのように変わるか、変更が組織への影響に見合っているかどうかを確認します。いずれのモデルにもメリット・デメリットがあるため、組織として達成したいビジネスゴールを設計・共有したうえで、優先度を判断し、選択することが重要です。 ４．セキュリティ部門の変化 オンプレミスの環境におけるセキュリティ部門の主な業務は、システムやネットワークの監視・管理、ファイアウォールやエンドポイントセキュリティなどのソフトウェア設定と運用、物理的なアクセスの管理などです。さらに、社内の基盤システムに関わるセキュリティ対策として、データバックアップ、侵入検知や脆弱性管理、ID・アクセス管理なども行います。つまり、オンプレミスの環境ではシステム基盤自体のセキュリティ管理が重要な役割となります。 一方、AWS では、AWS が大部分のセキュリティ機能を提供するため、セキュリティ部門の役割が大きく変わってきます。AWS 環境では「責任共有モデル」が適用され、AWS 側とお客様側で適切にセキュリティの責任を共有する必要があります。具体的には、AWS がネットワーク、ストレージ、データセンターなどのインフラストラクチャのセキュリティを担当し、お客様側が AWS 上のデータやアプリケーション、ID・アクセス管理などを担当することになります。 責任共有モデル このため、AWS 環境でのセキュリティ部門の役割は、AWS 上のデータやアプリケーションの保護、ID 管理やアクセス管理、脆弱性管理やモニタリングなど、AWS 上のリソース管理が中心となります。具体的な AWS のセキュリティサービスには、 AWS Shield 、 AWS WAF 、 Amazon GuardDuty などがあり、DDoS 攻撃の防御や Web アプリケーションファイアウォール、高度な脅威検知などを提供しています。また、 AWS Control Tower のガードレール機能を活用すれば、ベストプラクティスに沿った自動的なリソース設定の維持管理も可能です。 このような 変化に対応するため、セキュリティポリシーの見直しが必要になる場合があります。 オンプレミスのセキュリティポリシーは、社内ネットワークや物理的リソースへのアクセス管理を前提としていますが、AWS ではインターネット経由でのアクセスが前提となり、外部からの脅威にも対応できるようなポリシーへの変更が求められます。例えば、アクセス制御においては、多要素認証（MFA）の導入や最小限のアクセス権限の付与といった、 AWS のベストプラクティス を考慮することが重要です。 この責任共有モデルを組織に適切に組み込むためには、まず AWS セキュリティチームを設置し、AWS とお客様側の責任分界線を明確にする必要があります。そして、セキュリティポリシーの見直しや利用部門や開発部門への教育、定期的な監査とコンプライアンスの確認に取り組みます。 このように、オンプレミスと AWS では、セキュリティ部門の役割やセキュリティポリシーが大きく異なります。特に AWS 環境では、AWS のセキュリティ機能を最大限活用しつつ、お客様側の責任範囲におけるセキュリティ管理を適切に行うことが重要となります。 まとめ 前編では、従来のオンプレミスとAWS の違いから、IT 部門、セキュリティ部門の変化について整理しました。 後編 では、AWS によって新たに組成する組織や、組織文化の変更についてご紹介していきます。 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー (CSM) 甲斐 裕之、山崎 徹

はじめに みなさん、こんにちは。シニアマイグレーションスペシャリストの富松です。 2024年8月8日に「 ベストプラクティスから学ぶクラウド移行の勘所セミナー ～何千もの顧客をクラウドに移行した AWS の経験に基づく、包括的で実績のあるベストプラクティス～ 」を開催しました。 このブログでは、当日参加できなかった方や、参加したけれども内容を振り返りたい方に向けて、ご自身の取り組みの参考としていただくために当日のセッション内容のまとめを紹介します。 セッション内容の紹介 クラウドジャーニーを成功へ導く移行プロジェクトのベストプラクティス – 松尾 康博、アマゾン ウェブ サービス ジャパン合同会社 アジアパシフィックジャパン マイグレーション アンド モダナイゼーション技術統括本部 プリンシパルソリューションアーキテクト 本セッションでは、 これまで長年にわたって多くのお客様のクラウドジャーニーをご支援してきた中から、ほとんどのお客様がお悩みになるポイントをピックアップし、それらについて普段AWSがご案内している「考え方」や「心構え」について紹介しました。 クラウドジャーニーでは、クラウド移行完了までに大きく「移行検討」「プロジェクト立ち上げ」」「プロジェクト推進」の3つのフェーズに分解できます。それぞれのフェーズでよくあるお悩みとしては以下があります。 移行検討フェーズ：何から考えれば良いか？ プロジェクト立ち上げフェーズ：どう始めれば良いか？ プロジェクト推進フェーズ：うまく進めるために何をすれば良いか？ 本セッションの冒頭でこの課題定義をした後、各フェーズでの考え方や心構えを提示しています。 移行検討フェーズでは、3つの指標「戦略(Why?)」「スコープ(What?)」「タイムライン(When?)」を、ビジネス価値から考えて関係者全員で共有することの重要性を説明しました。クラウドへ移行することのビジネス価値を考えるための補助線としてクラウドバリューフレームワークを紹介し、その具体的な作成例としてKPIによる定量的な定義をご紹介しました。 プロジェクト立ち上げフェーズでは、「人」「プロセス」「技術」の3つの観点で並行して準備を進めることをベストプラクティスとしてご紹介しました。中でも、人はCCoE (Cloud Center of Excelense)の立ち上げと人材育成といった組織開発が重要であることと、移行プロセスの準備のためにやるべき事前作業や検討内容についてご紹介しています。 プロジェクト推進フェーズでは、一括移行ではなく立ち上げフェーズで定義した段階的移行（ウェーブ）の中でも特に移行リハーサルの重要性を説明しました。 移行完了後も継続的に改善することでクラウドのメリットを最大化できます。継続的改善の考え方は、本セッションでここまで説明した戦略策定や立ち上げフェーズの考え方を短く早いサイクルで回し続けることで可能であることを最後にご紹介しました。 資料のダウンロードは こちら から VMware 仮想環境、次の一手はどうする？ 〜仮想マシン (VM) と仮想デスクトップ環境 (VDI) の AWS への移行方式〜 – 武田 紘一、アマゾン ウェブ サービス ジャパン合同会社 エンタープライズアプリケーション本部 シニアスペシャリストソリューションアーキテクト 本セッションでは、昨今の VMware ワークロードを取り巻く状況変化に伴い「次の一手」を検討しているお客様に向けて AWS が推奨する移行オプションについてお伝えしました。VMware への対応のみならず、Windows Server 2016 の EoS が迫っている現状は、視点を変えると新しいプラットフォームに目を向けるチャンスでもあります。 Amazon EC2 は AWS Nitro System という独自のハードウェア、ハイパーバイザーで最適化された仮想マシンサービスです。物理層がハイパーバイザーで抽象化されているため、OS の目線で考えると実はオンプレミスの VMware 仮想マシンもクラウド上の Amazon EC2 も多くの共通点があります。Amazon EC2 に移行する手法を検討する際には AWS Application Migration Service (MGN) が第一に候補に挙がります。最近では、クラウドバックアップの応用系として AWS Backup を利用してオンプレミスの VMware 仮想マシンから Amazon EC2 に変換する手法も注目されています。 仮想デスクトップ環境 (VDI) のクラウド移行に目を向けると、すでに数十万のアクティブユーザーにご利用いただいている Amazon WorkSpaces が候補となります。オンプレミスの Horizon 環境など既存の VDI ソリューションを活かしつつクラウドに拡張する際には、Amazon WorkSpaces Core も選択肢となりえます。2024 年 6 月には非永続デスクトップ型の Amazon WorkSpaces Pools をリリースし、さらに多くのお客様のご要望に応えています。 AWS はこれからもみなさまの「次の一手」に伴走していきます。 資料のダウンロードは こちら から データドリブン経営を実現し生成AIの価値を最大化するためのデータプラットフォームの実現に向けて – 大塚 信男、アマゾン ウェブ サービス ジャパン合同会社 アジアパシフィックジャパン マイグレーション アンド モダナイゼーション技術統括本部 シニアソリューションアーキテクト 本セッションでは、まず、データドリブン経営を実現するためのデータプラットフォームのテクノロジー要件をご説明し、AWS上でクラウドネイティブなサービスを活用してモダンなデータプラットフォームを構築することにより、これらの要件を高いレベルで満たすことができることをお伝えしました。また、価値の高い生成 AI アプリケーションを作成するには、自社が保有するデータを最大限活用するためのバックエンドの仕組みが必要であり、データプラットフォームがモダナイズされていることが重要であることもお伝えしました。 これからクラウド上でデータプラットフォームの強化や刷新をお考えのお客様に対しては、最初のステップとして、AWSから無償のDPMODA (Data Platform Modernization Assessment) による現状評価支援をご提供させていただくことが可能です。（※実施には条件がございます。）DPMODAはAWSモダンデータアーキテクチャをベンチマークとすることで、お客様の現行環境のハイレベルな課題を抽出し、モダナイズによる改善策をご提案するアプローチです。質問シートへの事前の回答記入後にAWS技術者からのヒアリングを行わせていただき、約2週間後に報告会を開催いたします。DPMODAを通して現状の課題を可視化し、改善の一歩を踏み出していただくことができれば幸いです。 資料のダウンロードは こちら から AWSへの大規模移行を包括的にご支援 ～ITトランスフォーメーションパッケージの全貌～ – 諏佐 嘉之、アマゾン ウェブ サービス ジャパン合同会社 サービス＆テクノロジー統括本部 マイグレーション＆モダナイゼーションビジネス本部 シニアマイグレーションスペシャリスト 本セッションでは、お客様がクラウドへの移行をスムーズに遂行できるよう、AWSから提供できるご支援内容について説明いたしました。 AWSでは、従来から様々なプログラムやソリューションでお客様のクラウド活用をご支援してまいりました。それらのプログラムやソリューションをクラウド移行やクラウドネイティブ化という文脈でまとめ、「ITトランスフォーメーションパッケージ (ITX)」として提供しています。ITXは、移行の方式やお客様の特性などに応じて、ITX for Cloud First、ITX for Cloud Native、ITX for MCP Parter、ITX Lite、ITX for PSという5つのパッケージを提供しています。この中から、お客様の移行の要件に応じてご選択頂けます。 このセッションの中では、クラウド移行においてお客様がどのような立ち位置にいらっしゃるのか、どのようなポイントで悩まれているのかなどのケースに応じたITXの活用方法をご紹介いたしました。ITXで提供しているプログラムの多くは無償でご利用頂けます。 ITXが、お客様のスムーズなクラウド移行の一助となれば幸いです。 資料のダウンロードは こちら から おわりに AWSへの大規模なシステムの移行をサポートするITXパッケージ最新版のご利用に向けて、入り口は2つあります。 1） Webフォーム からお問い合わせ頂く。あるいは 2）担当営業までご連絡ください。 AWSクラウドへの移行やモダナイゼーションにご関心をお持ちのお客様は、 AWSで移行とモダナイズ のページをご確認ください。AWSへの移行やモダナイゼーションに必要な情報が網羅されています。 ITXパッケージ最新版にご興味をお持ちのお客様は、是非上記2つのいずれかよりAWSへお問合せください。 サービス＆テクノロジー統括本部　マイグレーション＆モダナイゼーションビジネス本部 シニアマイグレーションスペシャリスト 富松卓郎

AppsFlyer は、モバイルアトリビューションとマーケティング分析のグローバルリーダーです。AppsFlyer は、包括的な計測プラットフォームとプライバシークラウドを通じて、顧客のプライバシーを守りながらエコシステムの協調を促進することで、企業がすべてのチャネルとデバイスにわたるマーケティング活動の影響を理解することを支援します。 AppsFlyer 内では、データがコアであり、詳細な分析を公開し、顧客がキャンペーン活動のどこに焦点を置くか 正しい決定を下せるようになります。データのバックボーンは Apache Kafka の助けを借りて管理されており、1000 を超えるマイクロサービスのタイムフローを処理し、最大 50 を超えるクラスターに分散し、最大 800TB のデータを保持しています。 従来の Kafka インフラストラクチャでは、伝統的なセットアップを採用しており、各 Kafka ブローカーが専用の Amazon Elastic Compute Cloud (Amazon EC2) ノードにデプロイされていました。このシステムは、Chef、Terraform、サードパーティのサービスなど、さまざまなツールによって管理されており、それらは複数のGitプロジェクトに分かれていました。 この状況は、インフラストラクチャの変更のたびに複雑な依存関係の考慮が伴うため、、管理が複雑になりました。各コンポーネントは、Kafka のアップグレードなどの些細なタスクでさえ、慎重な検討、テスト、承認が必要でした。この複雑さにより、チームの作業負荷と複雑さが大幅に増え、その結果、AppsFlyer の内部研究開発 (R&amp;D) に投資できるリソースが減少しました。 そのため、AppsFlyer Platform グループが、従来の Kafka インフラストラクチャを Kubernetes に再設計する課題を受けた際、我々はさまざまな側面で Kafka システムを成長・改善する機会と捉えました。主な目標は、クラスターをより高度で自動化された高性能かつ管理が容易なインフラストラクチャに移行することでした。これにより、クライアントとチームの日々の運用の両方に恩恵がもたらされます。 この投稿では、Kafka アプリケーションを Kubernetes に移行したことで私たちの組織が実現した主な利点と、直面した課題、そしてその課題を克服するために採用した AWS のソリューションについて共有します。 Amazon Elastic Kubernetes Service による効率化 レガシーインフラストラクチャを再設計する際には、過去のインフラストラクチャと一致するソリューションを実装し、パフォーマンスを向上させ、簡単な管理と保守可能な自動化システムを提供する機会があります。加えて、コスト削減の余地も見込まれます。 幸いにも、Kubernetes に移行する際、AWS Cloud には複数のソリューションが用意されていました。 Kubernetes はコンテナ化されたワークロードを管理するための多目的なツールで、サービス検出、オーケストレーション、ストレージ、シークレット管理、自己修復機能など、さまざまな機能を提供します。 Amazon Elastic Kubernetes Service (Amazon EKS) は、AWS 上で Kubernetes クラスターを構築・維持を簡素化する完全マネージド型の Kubernetes サービスです。AWS の主要サービスと統合されているため、ステートフルアプリケーションに関する様々な AWS クラウドコンポーネントとの接続や対話が容易になります。 私たちのデプロイでは、 Strimzi Kafka Operator を使用しています。これは、Kubernetes クラスター内で Apache Kafka を実行するプロセスを簡素化するプロジェクトです。これを選択したのは、Kubernetes 上で Kafka を効果的に管理するために専用に構築されたコンテナイメージとオペレーターを備えているためです。 AWS が提供する実装とツール (例えば External DNS 、 AWS Load Balancer Controller ) とオープンソースのツールを利用することで、私たちのニーズにあったデプロイメントを構築できました。大規模な Kafka の実行とクラスターの簡単なリバランス機構を提供する Cruise Control などのオープンソースツールを使用しました。さらに、リアルタイムでトピックのメッセージを観察できるユーザーインターフェース (UI) ツールである Redpanda-Console も使用しました。これらのツール群により、ストレージ、ネットワーク、アプリケーションなど、多層のインフラストラクチャを単一の Kubernetes サービスの下で管理できるようになりました。 異なる Git プロジェクトで個別のコンポーネントを管理する必要があった従来のインフラストラクチャとは異なり、1 つの中央集権化された Git プロジェクトの下で、すべてを 1 か所で管理しました。これにより、コラボレーションを改善し、関連リソースの可視性とトラッキングを向上させることができました。 Graviton による最適なパフォーマンス コンテナオーケストレーターを決めた後、Kafka pod を実行する AWS インスタンスの種類を選択する必要がありました。 当初、コストパフォーマンスと強化されたローカル SSD ストレージを考慮して、従来の i3 インスタンスから改良された i3en インスタンスへの移行を計画していました。しかし、ベンチマークの際に、AWS から私たちにメリットをもたらす可能性のある別のインスタンスタイプが紹介されました。 AWS Graviton です。 Graviton インスタンスは、さまざまなシステム利用シーンに合わせた多様なインスタンスタイプを備え、パフォーマンスと機能が向上しています。Graviton インスタンスは、ARM ベースのプロセッサを搭載していますが、我々のユースケースにとって最も重要なのは、IOPS とスループットが向上したローカル NVMe ストレージです。 従来のインフラストラクチャでは、Kafka ブローカーにインスタンスローカルストレージを使用することにしました。これは、入出力操作/秒 (IOPS) やフェッチ時間などのパフォーマンス要因を最大化するためです。外部ストレージでは、100 万以上の IOPS とミリ秒単位のレイテンシーという要件を満たすことができませんでした。 Kubernetes でローカルストレージを使用するのは比較的新しい概念です。このようなシステムでは、ノードを失うと、そのノード上のデータも失われるため、失われたデータを複製するための復旧時間が長くなります。 そのため、従来のインフラストラクチャと新しい Kubernetes インフラストラクチャの両方で、オンデマンドインスタンスを使用しています。これにより、ノードの終了と中断のインシデントを減らすことができ、Kafka が他のブローカーからデータを復元する必要がある回数を効果的に減らすことができます。これにより、複数のノードが終了することによる完全なデータ損失のリスクを回避できます。 しかし、高速なデータ復旧に関して、Graviton インスタンスはローカル NVMe SSD ストレージを提供しており、リアルタイムのバスデータベースやステートフルアプリケーションにとって大きな恩恵があります。 従来の i3.2xlarge インスタンス上で実行されている Kafka クラスターと、新しい im4gn.2xlarge Graviton インスタンス上で実行されている Kafka クラスターを比較すると、スループットが 75% 向上 、CPU 消費が 10% 低下 、そして特に注目すべきは、書き込み I/O のパフォーマンスが 58% 向上 、読み取り I/O のパフォーマンスが 92% 向上 するという驚くべき結果が得られました。 今に至るまでの経緯を振り返ると、im4gn Graviton インスタンス上の新しい Kubernetes アーキテクチャで Kafka を実行しているわけですが、CPU コア数を半減させ、 コストを 50% 削減 できたと自信を持って言えます。さらに、カーボンフットプリントも低減できるという利点もあります。 Kubernetes、Kafka、ローカルストレージの力 Graviton インスタンスを選択した後、Graviton の Local SSD ストレージの利点を活用したいと考えました。ベンチマークでは、書き込み I/O パフォーマンスが 58% 向上し、読み取り I/O パフォーマンスが 92% も大幅に向上したことが確認できました。これは無視できない事実でした。 ローカルストレージには、ノードの障害ごとに新しいブローカーが起動してデータを復元する必要があるため、復旧時間が遅くなるという課題がありますが、私たちはその課題に取り組むことにしました。単一の Kafka pod が存在するノードと同じ場所にストレージを配置することで (外部ストレージを使用するのとは対照的に)、プロデューサーとコンシューマーにパフォーマンス向上の恩恵をもたらすことができます。 まず、Kafka の &nbsp; Persistent Volume Claims (PVC) を対応する &nbsp;Persistent Volume (PV) に割り当てる管理を行うプロビジョナーを選択する必要がありました。そして、これらの PV は Graviton インスタンスによって提供されるローカル SSD ストレージにマッピングされます。 最終的に、Rancher の Local Path Provisioner オープンソースプロジェクトを使用することにしました。このプロビジョナーは、ローカルタイプのストレージの PVC を監視し、ノード上に PV を自動的に作成するとともに、PVC と PV のバインディングもします。 次に、ノードの障害シナリオについて考える必要がありました。つまり、基盤となるノードが障害を起こすと、そのノードがホストしていたローカルストレージが削除されます。これにより、新しい Kafka pod は、ストレージが再度利用可能になるのを待つため、ステータスが Pending になります。。 この状況に対処するため、私たちは Local PVC Releaser という独自の社内オープンソースコントローラーを開発しました。このコントローラーは、計画的または計画外のノード終了に関する Kubernetes イベントを監視します。ノードの終了を検出すると、コントローラーは自動的に終了したノードにバインドされていた PVC (ローカルストレージタイプ) を削除します。これにより、Strimzi Operator が PVC を再作成し、pod を新しいノードに安全に割り当てられます。そして、データの複製を開始されます。 Persistent Volumes の図 各 Kafka pod を単一ノードで実行するように設定し、ノードの障害が単一のブローカーにのみ影響するようにすることで、ノイジーネイバー問題を回避し、Kafka クラスターの可用性を高めることができます。 ステートフルアプリケーション向け Karpenter による Amazon EKS 自動化の最適化 最終的な構成を決定した後、次のステップはオートスケーラーを導入して、このソリューションのポテンシャルを最大限引き出す自動化をすることでした。当初、私たちは Kubernetes Autoscaler ソリューションを試し、EKS クラスターでのオートスケーリングイベントを処理しようとしました。 しかし、Kafka pod でインスタンスローカルデータストレージを使用したり、大規模な障害から保護するためにKafka pod を異なる アベイラビリティーゾーン (AZ) に分散させることで、複雑さが増したため、プロダクションではスケーリングイベントや障害イベントインシデントに即座に対応する必要がありました。 そのとき、AWS は 我々に Karpenter を紹介してくれました。 Karpenter は AWS が立ち上げ、支援するオープンソースプロジェクトで、Kubernetes ノードのオートスケーリングソリューションとして機能します。Kubernetes pod の要件と制約を考慮して、コストとリソース効率を最適化するように動作します。Karpenter は、より柔軟性のあるスケーリングを目指しています。 Karpenter は主に 3 つの点で私たちを助けてくれました。 1. スピード Kafka と Kubernetes には多くの自己修復機能がありますが、新しい AWS インスタンスを起動して EKS クラスターに追加できる速度は、私たちとユーザーにとって非常に重要です。 Karpenter は、スピーディな応答時間で、pod が新しいリソースを要求したことを自動的に認識します。Karpenter は、設定 (私のチームがプログラミングしたもの) で要求されたとおりにインスタンスをデプロイしますが、この時 Karpenter は pod の要件も考慮します。この様なロジックを通して、我々はインスタンスのデプロイ時間と復旧時間を Kubernetes autoscaler では 9 分程度を想定していましたが、Karpenter を使用することで 1 分未満 に短縮できました。 2. ローカルストレージの認識 この大幅な削減は、Karpenter のローカルストレージ認識機能によるものです。Karpenter には、ストレージスケジューリング要件を自動検出し、トポロジースプレッドとハードウェア仕様と組み合わせてノードの起動判断に統合する機能があります。 ローカルストレージの認識は、Kubernetes autoscaler が提供していない機能でした。Kubernetes autoscaler は、pod のローカルストレージをどこに配置すべきかを直接認識していないためです。一方で、Karpenter は自動的にローカルストレージを認識し、正しい AZ にインスタンスをデプロイします。 3. 大幅なコスト削減 Karpenter の最適化により、大幅なコスト削減が実現されます。Karpenter は、EKS クラスター上で実行されているデプロイアプリケーションをサポートするために必要なインスタンス数だけでなく、コスト効率を最適化するための特定のインスタンスファミリーとサイズを計算できるためです。 この機能は、Kafka クラスターと並行して動作するサードパーティツールの pod に役立ちます。これらの pod はステートレスなので、Karpenter が便利です。Karpenter は、インスタンスタイプとサイズでサポートできる pod の数を自由に決定できます。これは、使用頻度が低い別のインスタンスをデプロイする必要がないよう、同じインスタンス上に戦略的に pod を配置することで実現されます。 これらすべての結果から、ステートフルアプリケーションを Amazon EKS 上で実行する際のニーズを満たしたため、Karpenter を主要な自動スケーリングソリューションとして完全に利用することを決定しました。 Kafka の Kubernetes への移行 この投稿で説明した AWS ツールと、この投稿では説明しきれないその他多くのツールを使って、新しいアーキテクチャを確立した上で、AppsFlyer チームは 従来の Kafka クラスターを新しく改善された Kubernetes 上の Kafka インフラストラクチャに 2 か月足らずで移行することに成功しました。 この移行により、「Produce」リクエストと「Consume」リクエストの時間の大幅な性能向上、ディスク I/O 書き込み性能の強化、ノード障害発生時の高速かつ柔軟な復旧が実現し、ユーザーにメリットをもたらしました。さらに、これらの要素は Terraform でラップされているため、簡単に管理でき、AppsFlyer チームはクラスターを最新で健全な状態に保つことができます。 これにより、今日では、この基盤を使って 50 を超える本番 Kafka クラスターを管理しています。 以前の設定と比べて CPU コア数が半分になり、驚くべき 30% のコスト削減 が実現しました。 新しく得た知識と既に確立されたビルディングブロックを武器に、私たちは今や Kubernetes 上でより多くの種類のステートフルなアプリケーションを、はるかに短い時間で構築できるようになりました。 EKS 上の Kafka とローカル NVME の図 翻訳はソリューションアーキテクト祖父江が担当しました。原文は こちら です。