みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 7月下旬の発表以来、たくさんのお客様にお申し込みを頂いた「 AWSジャパン生成AI実用化推進プログラム 」ですが、一部のお客様からもう少し準備に時間が欲しいというフィードバックを頂いています。それを受けて申込み締め切りを11月22日まで延長しました。生成AIによる課題解決に取り組みたいと考える方は、ぜひご検討ください。 業界特化のイベントも色々企画しています。今週木曜日、10/24には「 【流通小売/消費財/EC 企業向け】クラウドと生成AI によるオペレーション改革 」というオンラインイベントを開催します。ユーザ企業さんの成功事例を軸としたコンテンツ構成になっていますので、該当する業界の方は（それ以外の方も参考になるかも？）必見です。 それでは、10 月 14 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 株式会社メタバーズ様、Amazon BedrockでAIボットサービスを支える生成AIモデルの多様化を少ない工数で実現 株式会社メタバーズ 様は、 メタバース空間構築支援サービス を提供しています。メタバース空間でエンドユーザ対応をするためのチャットボット・アバターボットを作成するサービスも提供していますが、ユースケースにあわせてモデルのバリエーションを増やすための作業工数が課題になっていました。これを解決するためにAmazon Bedrockを採用し、モデル数の増加と更新作業の迅速化を実現しました。結果的に倍以上のモデルをラインナップするとともに、新モデル導入時の開発工数を約3日から数時間に短縮、類似検索の実現のために個別のモデルが不要になり開発コストを90%削減するという効果が出ています。 ブログ記事「生成 AI 時代におけるセキュリティ強化: re:Invent 2024 必見のセッション」を公開 12月2日から6日にかけて、AWS界隈で最大の学習型カンファレンスである AWS re:Invent が開催されます。AWS社員一同で様々なコンテンツを用意していますが、このブログ記事は生成AIとセキュリティというキーワードで考えたときの、オススメコンテンツのまとめ記事です。現地で参加される方は是非ライブでご覧いただくことをおすすめしますが、現地に参加できない方もおってセッションの録画が公開されるはずですので、そちらでチェックしてみてくださいね。 サービスアップデート Amazon Q in AWS Supply Chainを発表 AWS Supply Chainが持つサプライチェーンの諸情報を分析し、運用上・財務上のインサイトを提供するとともに、ユーザからの質問に回答する生成AIアシスタント、Amazon Q in AWS Supply Chainがご利用頂けるようになりました。「この製品の今後2ヶ月の需要予測は？」といった質問を(現時点では英語で)投げると、Amazon Qがデータを分析して予測数値とその根拠を提示する、といった形でデータ分析に習熟したエンジニアやアナリストの支援を待たずに、サプライチェーンの現状について掘り下げることを可能にします。本ブログポスト執筆時点では、バージニア、オレゴン、シドニー、フランクフルト、アイルランドのリージョンでご利用頂けます。 Amazon Q Businessを独自アプリケーションに組み込み可能に WebアプリケーションにAmazon Q Businessによる生成AIアシスタントを埋め込むことができるようになりました。アプリケーションデータや技術資料、ウェブサイトのコンテンツなどをインデックス化しておくことで、エンドユーザに対してAIアシスタントを利用して質問への回答を得たり、情報を要約したりといった機能を容易に提供できます。データはワークフロー全体で分離され、第三者へ公開を防ぐ仕組みとなっており、Amazon Q Businessのセキュリティ・プライバシー機能を継承しているため、エンドユーザ向けの権限制御を再実装する手間を省くことにもつながります。 Amazon Q Businessでメタデータを使用した検索精度向上が可能に Amazon Q Businessはデータソースコネクタを利用して様々なデータソースのデータを取り込んで検索対象とすることが可能です。今回、Amazon Q Businessがコネクタメタデータを利用してより高精度な情報検索を行えるようになりました。例えば、あるユーザが2024年9月に作成したドキュメントを抽出する、といった処理を実行する際は、データのメタデータとして作成者や作成日の情報を使う事が可能になり、より意図に沿った結果を出力できるようになります。 Amazon Bedrock AgentのConversational Builderを発表 Bedrock Agentの構築に利用できるチャットインタフェースを提供する新機能、Conversational Builderを発表しました。これを利用するとエージェントの開発をサポートするアシスタントとチャットで会話するという形式で、エージェントの開発を行うことができます。従来の手動構成よりも簡潔にプロトタイプが作成できますので、ぜひお試しあれ。 Amazon Bedrock Model Evaluationがインポートされたカスタムモデルの評価に対応 Amazon Bedrockでは対応するアーキテクチャのモデルをインポートして利用することができます。今回、モデルの性能評価を自動または手動でシステマチックに実行できるAmazon Bedrock Model Evaluationがインポートされたモデルの評価にも対応しました。異なるモデル同士での比較にとどまらず、ベースモデルとカスタムモデルの比較を実行しカスタマイズがどれくらい効果的だったのかを判断するためにも利用できるのがポイントです。 AWS CloudShellがAmazon Q CLIをサポート AWS CloudShellは、マネジメントコンソールに組み込まれたコマンドライン操作環境です。今回、AWS CloudShellでAmazon Q CLIが利用できるようになりました。これによってパーソナライズされたコマンドの提案や、自然言語からコードへの変換など、生成AIによるユーザ支援によりコマンドライン操作環境をより使いやすくサポートします。詳細は ドキュメント をどうぞ。 Amazon EKSがAL2023を利用したNVIDIA/Neuronによるアクセラレーションに対応 Amazon EKS(Elastic Kubernetes Service)に最適化されたAL2023(Amazon Linux 2023) AMIが一般利用開始になりました。NVIDIAのGPUやAWS Inferentia, AWS Trainiumによるアクセラレーションを必要とするワークロードで、強化されたセキュリティ機能や起動時間の最適化、AL2023の新しいバージョンのカーネルなどのメリットがあり、モデルトレーニングの実行環境の選択肢がさらに広がりました。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

この投稿は、SK テレコムの Seunghyun Jeong、Sunwoo Lee、Eric Davis と共同執筆した「 SK Telecom improves telco-specific Q&A by fine-tuning Anthropic’s Claude models in Amazon Bedrock 」を翻訳したものとなります。 SK Telecom （SKT）は、3,000 万人の顧客にサービスを提供する韓国の主要な通信会社で、AI イノベーションの最前線に立っています。SKT は、いつでもどこでも誰でも AI の可能性を引き出すことを目指す AI ピラミッド戦略に沿って、 AWS Generative AI Innovation Center （GenAIIC）カスタムモデルプログラムと協力し、通信業界特有のユースケースのために Amazon Bedrock を使用してドメインに特化した訓練モデルを探求しています。 このコラボレーションは、AI の専門知識と戦略的パートナーシップを活用して革新的な AI ベースの製品やサービスを開発するという SKT のビジョンに沿ったものです。そのような取り組みの1つとして、参考文書に基づいた根拠のある質疑応答（Q&A）のためのカスタムソリューションの開発に焦点を当てました。 検索拡張生成（RAG）は Q&A タスクに人気のある技術で、事実の正確性と知識の根拠付けを向上させます。しかし、RAG は通信業界のユースケースに適した好ましいトーン、スタイル、マナーに合致した応答を生成することや、関連性のない文書を取得してしまい、不正確な応答につながる可能性があるという課題に直面しています。これに対処するため、SKT と AWS GenAIIC は、 Amazon Bedrock での Anthropic Claude モデル を以下の3つの重要な分野で改善するためにモデルのカスタマイズを目指しました： 簡潔で有益な回答の提供 取得した文書からリンクを正しく参照すること SKT に一致し、正解の回答に似たトーンとスタイルで回答すること さらに、チームは知識蒸留と限られたラベル付き訓練データのシナリオのために、より大きな大規模言語モデル（LLM）によって生成された合成データを使用して、より小さなモデルのパフォーマンスを向上させることを探求しました。 Amazon Bedrock は、様々な LLM や基盤モデル（FM）を提供するフルマネージドサービスで、Amazon Bedrock Knowledge Bases、Amazon Bedrock Agents、Amazon Bedrock Guardrails などの機能を備えており、多くの生成 AI ユースケースを迅速に実現できます。Amazon Bedrock は、Claude モデルをファインチューニングする機能を提供する唯一のフルマネージドサービスです。Amazon Bedrock は、 Anthropic の Claude モデルなどを直感的かつ安全にファインチューニングする方法 を提供します。ファインチューニングされた Claude モデルは Amazon Bedrock を使用してデプロイでき、例えば通信業界特有の RAG のための Amazon Bedrock Knowledge Bases や、エージェント使用のための Amazon Bedrock Agents など、Amazon Bedrock の機能をシームレスに利用できます。 この記事では、SKT が Amazon Bedrock を使用して、SKT の電気通信関係の技術文書に関する通信業界特有の Q&A のために Anthropic Claude モデルをカスタマイズする方法を共有します。 ソリューション概要 チームは、プロンプト最適化、カスタマイズ（ファインチューニング）、合成データによるデータ拡張の組み合わせを探求しました。この多面的なアプローチは、根拠のある Q&A 生成タスクに対して各技術の利点を最大化することを目指しました。 以下のセクションでは、これらの方法をより詳しく探ります。 プロンプト最適化を伴う Anthropic の Claude カスタマイズ Amazon Bedrock を通じて Anthropic の Claude を含む様々な FM で利用可能なファインチューニングは、事前学習された言語モデルを特定のユースケースに対して適応させられます。これは特に、応答スタイルとフォーマットの遵守を調整するのに効果的です。 チームはまず、システムプロンプトを最適化し、 Anthropic モデルのプロンプト設定のベストプラクティス に基づいて、回答のフォーマットと文書の引用に関する標準化されたガイドラインを実装しました。主な焦点分野は以下の通りです： システムコマンドの明確な提示 コードブロックフォーマットの一貫した使用 コンテキストに基づいてカスタマイズされた応答 このプロンプトエンジニアリングとファインチューニングの組み合わせにより、精度が大幅に改善しました： ROUGE-3 スコアが 50% 以上増加 ROUGE-L スコアが 25% 以上改善 埋め込み類似度スコアが 4% 以上増加 正確な参考文献の引用に大幅な改善 反復的な改善プロセスは累積的な利点を示しました。プロンプトの更新だけで主要な指標で 35-40% の改善を示し、最終的にカスタマイズされたモデルでは一部の指標で 50-60% の改善が見られました。 この進歩は、RAG、プロンプトエンジニアリング、ファインチューニングを通じたモデルカスタマイズの累積的な利点を明確に示しています。ROUGE スコアと引用の精度の面で、ベースラインとプロンプトの更新バージョンの両方を大幅に上回るモデルになりました。 ROUGE スコア は、N-gram の単語のオーバーラップを計算することにより、正解と生成された結果の類似性を測定します。以下の表はこれらの改善をまとめたものです。 LLM プロンプトの更新 ファインチューニング ベースライン（baseline）からの改善割合 ROUGE-3 ROUGE-L 引用の精度 Anthropic’s Claude 3 Sonnet – – baseline baseline baseline Anthropic’s Claude 3 Sonnet – +38.30% +13.4% +52.94% Anthropic’s Claude 3 Sonnet +58.1% +26.8% +70.59% ファインチューニングのための合成データ 高品質なラベル付き訓練データが限られているという課題に対処するため、チームは合成データの生成技術を探求しました。このアプローチは、より大きな LLM からより小さな、より対象を絞ったモデルへの知識蒸留も促進し、レイテンシーとコストの低減などの利点をもたらします。 チームは以下を使用して制御された実験を行いました： 500 個の正解サンプルからなるベースラインセット 500 個のオリジナルサンプルと 1,500 個の合成データのサンプルを含む拡張セット 2,000 個のオリジナルサンプルからなる、より大きなセット 合成データは Anthropic の Claude Sonnet 3 を使用して生成され、正解例で使用されたのと同じ取得文書に対して新しい質問と回答のペアを作成しました。 結果は LLM ベースの比較と人間の選好評価の両方を使用して評価されました。人間の評価者は、どのモデルの出力かをみずにランク付けし、選好に基づいてスコアを割り当てました（最良：4、2 番目：3、3 番目：2、最悪：1）。以下の表は、人間の選好評価スコアの結果を示しています。 ランク モデル 累積スコア （ベストスコア：160） 1 2,000 個のオリジナルサンプルでファインチューニング 114 2 500 個のオリジナルサンプルと 1,500 個の合成データのサンプルでファインチューニング 112 3 500 個のオリジナルサンプルでファインチューニング 85 4 ファインチューニングなし（ベースライン） 84 次のような発見がありました： 小さな訓練セット（500 個のサンプル）はベースラインに対してわずかな改善しか示さなかった より大きな訓練セット（2,000 個のサンプル）は大幅に高いスコアを示した 合成的に拡張されたデータは、同等のサイズのオリジナルデータと同様のパフォーマンスを示した ドメイン特有の大量の訓練データを持つことが常に理想的ですが、多くの企業は利用可能なデータセットが限られています。そのようなシナリオでは、合成データがオリジナルデータの代わりに重要な役割を果たすことができます。これは、モデルのカスタマイズにおける合成データの可能性を示しています。 結論 SK Telecom と AWS GenAIIC の協力は、通信業界の課題に対する革新的な AI ソリューションを開発するという同社のコミットメントを示しています。Amazon Bedrock を使用して Anthropic の Claude モデルをカスタマイズすることで、SKT は一からモデルを構築する必要なく、通信業界特有の韓国語ユースケースに対して大幅なパフォーマンスの向上を達成しました。実証実験では以下の大幅な改善が示されました： ROUGE-3 スコアが約 58% 増加 ROUGE-L スコアが約 27% 増加 正しい参照文書のリンクを返すことに大幅な改善 この合成データ生成技術と組み合わせたアプローチは、SKT の AI ピラミッド戦略に沿っており、新しいアプローチのより迅速なテストと開発を可能にします。SKT が個人向け AI アシスタント、AI ヘルスケア、AI データセンターなどの主要分野に引き続き焦点を当てる中、AWS とのこの協力は、彼らの AI 進化とグローバル AI 環境における長期的な競争力において重要な一歩を表しています。 AWS と同様のプロジェクトに取り組むことに興味がある方は、 Generative AI イノベーションセンター をご覧ください。 翻訳はソリューションアーキテクト菊地が担当しました。 著者について Sungmin Hong は、AWS Generative AI イノベーションセンターのシニア応用科学者で、AWS の顧客の多様なユースケースの迅速化を支援しています。Amazon に入社する前は、ハーバード医科大学のポスドクの研究員でした。ニューヨーク大学でコンピューターサイエンスの博士号を取得しています。仕事以外では、ハイキング、読書、料理を楽しんでいます。 Sujeong Cha は、AWS Generative AI イノベーションセンターのディープラーニングアーキテクトで、モデルのカスタマイズと最適化を専門としています。生成 AI や従来の AI/ML ソリューションを活用して、顧客のビジネスユースケースを解決する豊富な実践経験を持っています。ニューヨーク大学でデータサイエンスの修士号を取得しています。 Arijit Ghosh Chowdhury は、AWS Generative AI イノベーションセンターの科学者で、モデルのカスタマイズと最適化に取り組んでいます。彼のロールでは、様々な業界向けに生成 AI を実現するためのファインチューニングとモデル評価の応用研究に取り組んでいます。イリノイ大学アーバナ・シャンペーン校でコンピューターサイエンスの修士号を取得しており、その研究は質問応答、検索、ドメイン適応に焦点を当てていました。 Yiyue Qian は、AWS Generative AI イノベーションセンターの応用科学者 II で、AWS の顧客に生成 AI ソリューションを提供するサポートを行っています。この役割では、専門家チームと協力して、様々な業界の AWS 顧客向けに革新的な AI 駆動モデルを開発しています。ノートルダム大学でコンピューターサイエンスの博士号を取得しており、その研究は高度な機械学習とディープラーニング技術に焦点を当てていました。 Wei-Chih Chen は、AWS Generative AI イノベーションセンターの機械学習エンジニアで、LLM のモデルカスタマイズと最適化に取り組んでいます。また、チームが LLM 開発ライフサイクルのさまざまな側面（ファインチューニング、ベンチマーキング、負荷テストを含む）に取り組むのを支援するツールを構築し、AWS 顧客の多様なユースケースの採用を加速しています。カリフォルニア大学デービス校でコンピューターサイエンスの修士号を取得しています。 Hannah Marlowe は、AWS Generative AI イノベーションセンターのモデルカスタマイズ部門のシニアマネージャーです。彼女のチームは、顧客が独自の専有データを使用して差別化された生成 AI ソリューションを開発し、重要なビジネス成果を達成するのを支援することを専門としています。アイオワ大学で物理学の博士号を取得し、天文学の X 線分析と機器開発に焦点を当てていました。仕事以外では、コロラド州の山々でハイキング、マウンテンバイク、スキーを楽しんでいます。 Seunghyun Jeong（Steve） は、SKT のプラットフォームアプリケーションチームのチームリーダーです。AI モデルとツールを提供する Global Intelligence Platform（GIP）の商業化を担当しています。キャリアの大半で、モバイルウォレット、ファッションストリーミング、統合ログインサービスなど、SK の様々なモバイルサービスを開発する PM を務めてきました。彼のチームは、内部チームが AI を適用しやすくするためにモデルと機能の提供を拡大し、SKT の AI トランスフォーメーションに貢献しています。AI 分野に入る前は、米国と韓国向けのモバイルウォレット、ファッションストリーミング、統合ログインサービスなど、様々なモバイルサービスを開発・運営するプロダクトマネージャーでした。 Sunwoo Lee（Lois） は、SK Telecom の Global AI Tech 部門内のデータ構築・評価チームのチームリーダーです。言語モデルのトレーニングデータの設計と構築、モデルパフォーマンス評価プロセス、およびそのサービスへの適用を監督しています。彼女のキャリアは IT 内の NLP に焦点を当てており、言語学と韓国語教育のバックグラウンドとよく合致しています。世界クラスのチームと共に、言語モデルトレーニングのデータ設計の最適化方法、言語モデルのパフォーマンスを検証するためのタスクと方法の実装、AI と人間の会話の最適な設計など、魅力的な問題の探求と解決を続けています。 Eric Davis は、SKT の AI Tech Collaboration Group の副社長です。Eric は世界中のテクノロジーパートナーとの技術コラボレーションを監督し、通信ドメイン向けに大規模言語モデル（LLM）をカスタマイズしています。彼のチームは、LLM を調整するためのデータセットの設計と構築、および一般的な LLM と通信ドメイン向けの LLM のベンチマーキングを担当しています。Eric はカーネギーメロン大学の言語技術研究所でコンピューターサイエンスの理学修士号を、カリフォルニア大学ロサンゼルス校で言語学と心理学の文学士号を取得しています。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 一つイベントを宣伝させてください。 11月1日 10:00-12:00に コンテナ/サーバーレスによるモダン・プロジェクト実践 というイベントが開催されます。プロジェクトで実践されているユーザーの体験・声を直に感じる機会ですのでぜひご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年10月14日週の主要なアップデート 10/14(月) Amazon EKS now supports using NVIDIA and AWS Neuron accelerated instance types with AL2023 Amazon Linux 2023のEKSに最適化されたアクセラレーテッドAMIが一般提供されました。これによりEKSでNVIDIA GPU、AWS Inferentia、AWS Trainiumインスタンスを使用するワークロードにおいて、新しいカーネルバージョンであるAL2023、強化されたセキュリティ機能、最適化された起動時間を利用できるようになりました。このAMIは、AWS GovCloud (米国) リージョンを含むすべてのAWSリージョンで、サポートされているすべての標準バージョンのEKSバージョンおよび延長サポート バージョン1.23以降で利用可能です。詳細については ドキュメント をご確認ください。 Assign billing of your shared Amazon EC2 On-Demand Capacity Reservations Amazon EC2 オンデマンドキャパシティ予約の未使用分の請求を、予約を共有している組織の任意のアカウントに割り当てることができるようになりました。キャパシティ予約を組織で共有する場合、各アカウントには使用量に応じて請求がされますが、これまでは未使用分は予約を所有するアカウントに請求されました。この機能により、未使用分の請求アカウントを柔軟に設定できるため、組織で一元的に管理しプールする場合の柔軟性が増します。この機能は、すべての商用AWSリージョンとAWS中国リージョンで追加料金なしで利用可能です。詳細については、 ドキュメント をご確認ください。 AWS Transfer Family SFTP connectors now provide real-time status of file transfer operations AWS Transfer FamilyでSFTPコネクタを利用する際に、ファイル転送が完了したか、進行中、キューに入っているか、失敗したかなど、転送操作のステータスをリアルタイムに照会できるようになりました。これにより、ファイル転送操作の現在の状態を簡単に監視し、転送後のアクションを設定するなど、AWSでのファイル転送ワークフローを自動化できます。たとえば、AWS Step Functions を使用する場合は、SFTP コネクタを使用してリクエストされたファイル転送操作のステータスを再帰的にポーリングし、ファイル転送が完了すると自動的に後処理ステップを作成するなどのユースケースで利用できます。詳細については ドキュメント をご確認ください。 10/15(火) AWS announces general availability of Amazon DynamoDB zero-ETL integration with Amazon Redshift Amazon DynamoDBとAmazon Redshiftのzero-ETL統合が一般提供されました。zero-ETL統合は抽出、変換、ロード(ETL)を実行するための複雑なパイプラインを構築・保守することなくシームレスにデータ連携ができる機能です。この機能によりDynamoDBで実行されているプロダクションワークロードに影響を与えることなくRedshiftでデータの分析を実行できるようになりました。この機能は全ての商用リージョンとAWS GovCloud(米国)リージョンで利用可能です。詳細については ローンチブログ と DynamoDB 、 Redshift 各々のドキュメントをご確認ください。 Amazon Aurora PostgreSQL zero-ETL integration with Amazon Redshift now generally available 先に紹介したDynamoDB同様、Amazon Aurora PostgreSQLとAmazon Redshiftのzero-ETL統合が一般提供されました。zero-ETL統合は複数のAuroraからのデータ連携にも対応しており、ペタバイト単位のトランザクションデータをほぼリアルタイムにRedshiftに連携し分析や機械学習などに活用することができます。この機能はAurora PostgreSQL バージョン 16.4 以降のAurora プロビジョンドクラスターとAmazon Aurora サーバーレス v2 クラスター、RedshiftはAmazon Redshift サーバーレスとRA3インスタンスタイプを使うプロビジョニングされたクラスターで利用可能です。また、提供のリージョンは東京を含む11のリージョンで利用可能です。詳細については ローンチブログ と Aurora , Redshift 各々のドキュメントをご確認ください。 Amazon SageMaker Studio notebooks now support G6e instance types SageMaker Studio ノートブックでAmazon EC2 G6eインスタンスが一般提供されました。EC2 G6eインスタンスはNVIDIA L40S Tensor Core GPUを搭載しており、G5インスタンスと比較して最大2.5倍のパフォーマンスを発揮し、P4dと比較して推論ワークロードを最大20%安価に実行できます。13B規模の大規模言語モデル(LLM)や画像、動画、音声を生成する拡散モデルのデプロイに適しています。SageMaker Studio ノートブックでのEC2 G6e インスタンス利用は、バージニア北部、オハイオおよびオレゴンのリージョンで選択可能です。 AWS CodeBuild now supports managed network access control lists AWS CodeBuildの予約済みキャパシティフリートでNetwork access control lists(NACL)によるトラフィックの制御が可能になりました。NACLを設定することで、ビルド環境に出入りするトラフィックを制御し、外部サイトとのトラフィックを許可または拒否するルールを設定できます。この機能は、予約済みキャパシティを利用できる東京を含む10のリージョンで利用可能です。詳細は ドキュメント をご確認ください。 AWS CodePipeline supports automatic retry on stage failure AWS CodePipeline V2がステージで失敗した際の自動再試行をサポートしました。これにより、パイプラインの実行時にエラーが起きた際にステージで一回再試行がされます。再試行に際してはステージの最初から、もしくは失敗したアクションからをオプションとして指定することができます。この機能はAWS CodePipeline がサポートされているすべてのリージョンで利用できます。詳細や設定方法は ドキュメント をご確認ください。 Amazon AppStream 2.0 now supports custom shared network storage Amazon AppStream 2.0で、Windowsユーザー向けの新しいオプションとしてカスタム共有ネットワークストレージがサポートされました。これによりファイルを手動で転送しなくても共有することが可能になります。共有ネットワークストレージはSMBネットワークドライブとして実装され、アクセス制御と権限を一元管理することで組織のデータセキュリティを強化できます。この機能は、Amazon AppStream 2.0が利用可能なすべてのAWSリージョンで追加料金なしで利用できます。この機能をユーザー向けに有効にするには、2024年9月18日以降にリリースされた AppStream 2.0 エージェントを使用する AppStream 2.0 イメージを使用するか、2024年9月20日以降にリリースされた Managed AppStream 2.0 イメージアップデートを使用する必要があります。詳細については ドキュメント をご確認ください。 10/16(水) AWS Marketplace now supports offers in four new currencies and non-US bank accounts for disbursement AWS Marketplaceで日本円(JPY)、EUR、GBP、AUDの新たに4つの通貨による契約価格の設定と、支払いに米国以外の銀行口座の選択が可能になりました。これにより販売者、購入者双方がソフトウェアやサービスの利用で請求金額の為替リスクを排除することができます。詳細については、現地通貨でのオファーと支払いに関する ドキュメント をご確認ください。 Announcing AWS DMS Serverless support for MongoDB and DocDB as a source データベース移行サービスのAWS Database Migration Service Serverless(AWS DMSS)が新たにMongoDBとAmazon DocumentDBをデータソースとしてサポートしました。これによりMongoDBとDocumentDBから様々なターゲットDBにデータ移行ができるようになります。詳細については ドキュメント をご確認ください。 Amazon Bedrock Agents now provides Conversational Builder Amazon Bedrock Agents向けのConversational Builderが一般提供開始されました。Conversational BuilderはAgentsを作る際に利用できるチャットインターフェイスで、自然言語で指示をすることでAgentsを作成することができます。従来の手動設定に加えて作成方法が増えたことで、より簡易にAgentsを作成することが可能になります。この機能はAmazon Bedrock Agents を利用できるバージニア北部、オレゴン、シドニー、パリ、フランクフルトのリージョンで利用可能です。 10/17(木) AWS Lambda console now supports real-time log analytics via Amazon CloudWatch Logs Live Tail AWS LambdaのコンソールでAmazon CloudWatch Logs Live Tailがサポートされました。これによりCloudWatchコンソールを開かずにログをリアルタイムに確認でき開発やトラブルシューティングが容易になります。この機能はコンソールの[Open CloudWatch Live Tail]ボタンから利用できます。詳細については ローンチブログ や ドキュメント をご確認ください。 Amazon Aurora PostgreSQL now supports local write forwarding Amazon Aurora Postgre SQL互換エディションでwrite forwardingをサポートしました(Aurora MySQLは以前からサポート)。この機能によりAuroraリードレプリカへの書き込みリクエストをライターインスタンスに転送されるため、アプリケーション側で読み取り/書き込みを分離する複雑なロジックを書かずともリードレプリカをスケーリングすることができます。書き込み転送は整合性のニーズに合わせて整合性レベルを選択可能です。この機能はAurora PostgreSQL バージョン 14.13、15.8、16.4 以降でサポートされています。詳細については ドキュメント をご確認ください。 Amazon RDS Multi-AZ deployment with two readable standbys now supports AWS IAM database authentication Amazon RDS マルチAZ配置で読み取り可能なスタンバイDBを2つ配置構成（この機能については こちら ）で、IAM認証によるデータベースアクセスがサポートされました。これにより各DBへのアクセスを個別に管理する必要なくIAMにより一元的なアクセスが可能になります。また、IAM認証を利用することでログイン情報を保存・管理する必要もなくなります。詳細については ドキュメント をご確認ください。 10/18(金) Amazon Bedrock Model Evaluation now supports evaluating custom model import models Amazon Bedrockのモデル評価では自動評価と人間による評価により精度や堅牢性などの指標を事前定義されたアルゴリズムで行うことができます。この機能がCustom model importにより取り込んだ独自モデルもサポートしました。これにより、カスタマイズしたモデルを再度カスタマイズするか、品質を満たしているか等の評価などにも利用することが可能になりました。この機能が利用可能なリージョンは こちら をご確認ください。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

2024 年 10 月 4 日に「 いまこそ始めよう！AWS でクラウド HPC！ 」と題したセミナーを開催いたしましたのでご報告いたします。 HPC とは High Performance Computing の略で、流体解析や気象シミュレーションといった大規模な計算ワークロードをスーパーコンピュータ等で実行する分野のことです。広義の HPC としては機械学習の大規模分散学習処理やビッグデータ処理も含まれます。近年では HPC ワークロードを実行するプラットフォームとして AWS を選ばれるお客様が増えてきています。 本セミナーでは、 AWS 上での クラウド HPC について AWS よりご紹介したのち、実際に AWS のクラウド HPC を活用されているお客様の事例として、株式会社Helical Fusion様と宇宙航空研究開発機構様にご登壇いただきました。ここからは当日のセッション内容について簡単にご紹介いたします。 セッション内容 10:05 – 10:20 「クラウド HPC 超入門」 スピーカー : AWS HPC事業開発マネージャー 草開 志帆 概要 : まずはこれまでの HPC 業界のおさらいに加えて、クラウド HPC の利点であるインフラ維持コストの削減、運用の効率化、レジリエンス、ビジネスアジリティについてご説明しました。また、世界の HPC ワークロードの 20 % がすでにクラウドで稼働していて増加傾向にあること、AWS がスーパーコンピュータの国際会議 SC23 にて Best HPC Cloud Platform 賞を 6 年連続で受賞していることをご紹介しました。 [ 資料 ] 10:20 – 10:40 「いまこそ始めよう！HPC on AWS！」 スピーカー : AWS ソリューションアーキテクト 小林 広志 概要 : AWS の クラウド HPC を支えるサービスとして、Amazon Elastic Compute Cloud (Amazon EC2) の 各種インスタンスタイプ 、ストレージサービスである Amazon FSx for Lustre や、 AWS ParallelCluster と AWS Batch によるクラスター管理の概要をご紹介しました。また、オンプレミスの HPC プラットフォームを AWS へ移行する際にポイントとなる、ワークロードの種類や、移行パス、ライセンス面についてご説明しました。 [ 資料 ] 10:40 – 11:00 「AWS でお手軽 HPC クラスターを作ろう！AWS Parallel Computing Service (AWS PCS) 入門」 スピーカー : AWS ソリューションアーキテクト 遠藤 亘 概要 : 2024 年 8 月 に発表された新サービスである AWS Parallel Computing Service (AWS PCS) では、AWS 上でマネージドな HPC クラスターを簡単に構築・運用できます。本セッションでは AWS PCS が解決する課題としてメンテナンスの自動化や既存 HPC ワークロードとの親和性についてご紹介したのち、AWS PCS を用いた HPC クラスターのアーキテクチャや導入方法、料金例についてご説明しました。また、デモとしてマネジメントコンソールの画面例をご紹介し、最後に AWS PCS を用いて流体解析ソフトウェアである OpenFOAM を実行する例もご紹介しました。 [ 資料 ] 11:05 – 11:25 「核融合スタートアップにおける AWS 活用」 スピーカー : 株式会社Helical Fusion チーフリサーチャー 中村 誠 様 株式会社Helical Fusion チーフリサーチャー 金田 健一 様 株式会社Helical Fusion 経営戦略室 シニアマネジャー 吉村 奈保 様 （近日中に公開予定です） 11:25 – 11:45 「JAXA流体シミュレーションにおける AWS HPC の評価」 スピーカー : 宇宙航空研究開発機構 宇宙科学研究所 学際科学研究系/准教授 高木 亮治 様 概要 : JAXA 様では航空宇宙分野における研究開発に必要な流体解析等のシミュレーションをオンプレミスのスーパーコンピューターシステムで実施されていますが、このシステムは利用率 90 %を超える状態で運用されており、突発的な事象で計算資源が必要になってもすぐに実行できないという課題がありました。そうした課題の解決のため クラウド HPC の活用をご検討いただいており、今回は AWS の クラウド HPC と既存のオンプレミス環境について同一の流体解析プログラムを実行した際の性能評価結果を詳細にご説明いただき、全体的な使用感についてもご共有いただきました。 [ 資料 ] おわりに 今回は AWS から クラウド HPC の概要と新サービスである AWS PCS をご紹介するとともに、AWS をご活用いただいているお客様から クラウド HPC の活用事例をご説明いただきました。AWSコンピュートサービスに関連する今後のセミナー予定は こちら に掲載していきます。今後も引き続き、様々な切り口からのセミナーを企画してまいりますので、みなさまのご登録をお待ちしております。 このブログはソリューションアーキテクトの遠藤 亘が担当いたしました。

SaaS プロバイダーにとって重要な課題は、テナントを特定し適切なリソースにリクエストをルーティングするための、セキュアで拡張性の高いテナントルーティング機構を設計することです。 効果的なテナントルーティングにより、分離性、拡張性、そしてセキュリティが確保されます。 この記事では、AWS 上のマルチテナント SaaS 環境における HTTP リクエストのルーティング戦略について、考慮事項、ベストプラクティス、そして例を交えて説明します。 トランスポート層でのルーティング戦略については、 SaaS 向け AWS PrivateLink を使用したトランスポート層テナントルーティングのアプローチ をご覧ください。 SaaS におけるテナントルーティングの概要 テナントルーティングは、 SaaS アーキテクチャモデル に依存します。 プールモデルでは、複数のテナント間でインフラストラクチャリソースを共有します。 この場合、すべてのテナントに対して単一のリソースが存在するため、ルーティングは必要ありません。 一方、サイロモデルでは、テナントごとにインフラストラクチャリソースが専用に構築されます。 この場合、受信リクエストをテナント固有のリソースにルーティングするための効率的なテナントルーティングが不可欠になります。 ブリッジモデルは、サイロモデルとプールモデルを組み合わせたものです。この混合モデルは、階層化戦略やアーキテクチャ内のマイクロサービスに基づいてテナント間で適用できます。その結果、複数のルーティングメカニズムを使用する可能性があります。 テナントルーティング戦略 テナントルーティング戦略には大きく分けて 2 つのカテゴリーがあります。 ドメイン駆動型ルーティング は、Domain Name System (DNS) を使ってルーティングを決定します。SaaS プロバイダは、各テナントにサブドメインやドメイン名のプレフィックスを割り当て、アプリケーションを提供できます。 データ駆動型ルーティング は、受信した HTTP リクエストに含まれる情報を使ってルーティングを決定します。SaaS プロバイダは、さまざまな HTTP ヘッダ、リクエストパラメータ、クッキーを利用してルーティングロジックを実装できます。 ドメイン駆動型ルーティング ドメイン駆動型ルーティングでは、各テナントに一意のホスト名を割り当てます。一般的なアプローチは、テナントごとにサブドメインを使用することです (例: tenant1.example.com )。ドメイン駆動型ルーティングの主な利点は、シンプルさです。DNS インフラストラクチャを活用することで、ホスト名だけからテナントコンテキストとルーティングを効率的に取得できます。しかし、アプリケーションが時間とともに進化するにつれ、複雑なシナリオでは柔軟性とカスタマイズ性に欠けるかもしれません。 考慮事項とベストプラクティス バニティドメイン – ブランディングの利点を提供するために、SaaS プロバイダーはテナントに対し、カスタマイズされたパーソナライズされたバニティサブドメインの選択を許可することが多くあります。テナントのオンボーディングを高速化するために、最初はランダムなユニークなバニティドメインを生成し、後から変更を許可することができます。 独自のドメイン (BYOD) の利用 – ブランディングを強化するため、SaaS プロバイダーはテナントに対して Apex ドメインを利用できるようにすることができます。ただし、複雑さが増すためあまり一般的ではありません。 サブドメインでは、SaaS プロバイダーがドメインの所有権と TLS 証明書を管理します。一方、Apex ドメインでは、テナント自身がドメインを管理する必要があります。 ブランディングの利点と、ドメイン委任、検証、TLS 証明書の取得にかかる追加プロセスとのトレードオフを検討してください。 たとえば、 AWS Certificate Manager (ACM) などのサービスを利用して TLS 証明書の更新を自動化できます。 これには、最初にドメインの所有権を証明するためのメールまたは DNS 検証が伴います。この検証は通常、テナントのオンボーディング時に要求されます。 ただし、自動化が常に可能というわけではありません。 たとえば、企業のお客様は、ドメインと TLS 証明書を厳密に管理するために、手動のプロセスを要求するかもしれません。 テナントディレクトリ – ドメイン駆動型のルーティングでは、ユーザーがテナントの URL を覚えておく必要があります。しかし、一部のユーザーは URL を忘れてしまう可能性があるか、SaaS ソリューションに直接アクセスする場合はさらなるガイダンスが必要になる場合があります。そのため、ユーザーのメールアドレスやユーザー識別子に基づいてテナントを特定できるようなエクスペリエンスを設計することをご検討ください。そのようなエクスペリエンスの例を以下に示します。 図 2: SaaS ソリューションの一環としてテナントに提供できるユーザー エクスペリエンスの例 Amazon Route 53 と Application Load Balancer を使用した例 ドメイン駆動のルーティングを実装するには、受信リクエストのルーティングに使用する AWS サービスに依存します。この例では Application Load Balancer を使用し、 リスナールール を使って受信リクエストのホストヘッダーに基づいた条件式ロジックを設定します。 各テナントをプロビジョニングする際、ルーティングを設定してユーザーを適切なテナントリソースに振り分けます。 図 3: Application Load Balancer のリスナールールを使ったドメイン駆動型ルーティングの例 Amazon Route 53 による DNS – HTTP リクエストでは DNS が最初の入り口となります。この例では、 Amazon Route 53 にエイリアス DNS レコードを設定 し、すべての *.example.com サブドメインに関連するトラフィックを Application Load Balancer にルーティングします。 アプリケーションロードバランサーを使用したホストベースのリスナールール – トラフィックがロードバランサーに流れる際には、 HTTP ホストヘッダー が含まれています。例えば、 tenant1.example.com などです。そして、そのリクエストをテナントに割り当てられたリソースに対応する ターゲット に転送します。 テナントのオンボーディング – テナントのオンボーディング の一部としてテナントルーティングを検討してください。 例えば、新しい SaaS 顧客が登録した際、その ティア に基づき、テナントのオンボーディングサービスで新しいインフラストラクチャがプロビジョニングされる必要があるかどうかを判断できます。 必要な場合は、インフラストラクチャのプロビジョニングに加えて、テナントルーティングを設定する必要があります。 この場合、新しいテナントインフラストラクチャに対応するホストベースのリスナールールを設定してください。 これはドメインベースのルーティング手法の一例にすぎないことに注意してください。Application Load Balancer を使用していますが、ここで説明されるコンセプトは他の技術に対しても適用できます。 データ駆動型ルーティング 次にデータ駆動のルーティングについて見ていきましょう。SaaS アプリケーションでは主要な 設計原則 として、ユーザー ID とテナント ID を関連付けることです。 これにより SaaS ID が生成され、システムの全レイヤーを通過して、テナントコンテキストにアクセスできるようになります。 データ駆動のルーティングでは、この ID を HTTP リクエストの部品に含めることができます。 これにはヘッダー、Cookie、URL パス (URI) 、リクエストボディなどがあります。 次に、この情報を抽出して、着信リクエストを適切なテナントのリソースに動的にルーティングします。 データ駆動型ルーティングの重要な利点は柔軟性です。ただし、ルーティングのための追加算出が必要なため、手法には複雑さと運用オーバーヘッドが加わります。そのため、特に大規模な SaaS 環境では、細心の設計が求められます。 考慮事項とベストプラクティス テナント ID 管理 – データ駆動型ルーティングでは、一般的なアプローチは、API キーや OAuth クライアント ID のようなテナントコンテキストをユーザー認証時に取得することです。ただし、このアプローチは SaaS アプリケーションに集中型 ID サービスがあることを前提としています。場合によっては、SaaS アプリケーションには各テナントごとに別々の ID サービスがある可能性があります。そのような状況では、適切な ID サービスを決定するために認証前にテナントコンテキストが必要になります。そのため、ドメイン駆動型ルーティングの方がより適切なアプローチかもしれません。 ワイルドカードサブドメイン – SaaS ソリューションでは自動化が重要であり、一般的なアプローチは各テナントにサブドメインを提供することです。ワイルドカードサブドメインでは、DNS を 1 回設定するだけで、新しいテナントをオンボードする度に追加の DNS 操作は必要ありません。たとえば、 Amazon CloudFront にワイルドカードの代替ドメイン *.example.com を設定します。サービスは、そのパターンに一致するトラフィックを、アプリケーションが存在するオリジンにルーティングします。そして、アプリケーションでテナントのコンテキストを抽出し、リクエストを適切なテナントにルーティングできます。ワイルドカードサブドメインは、 Amazon API Gateway 、 Application Load Balancer 、 AWS Amplify などのサービスでサポートされています。 キャッシュを利用したコスト最適化とパフォーマンス最適化 – ルーティングロジックの実行には、コストとパフォーマンスのオーバーヘッドが発生します。そのため、実行頻度を最小限に抑えることを検討してください。例えば、初期認証プロセス中にのみルーティングロジックを実行します。同じユーザーやテナントからの後続のリクエストではキャッシュされたルーティング結果を利用することができます。 高度なコンテキスト – 一部のユースケースでは、テナントの識別子以外の追加のテナントコンテキストが必要になる場合があります。これには、バックエンドリソースへの参照、アプリケーションバージョン、または CloudFront ヘッダー から抽出されたジオロケーションデータなどが含まれ、マルチリージョンアーキテクチャーで特に役立ちます。このような状況では、Amazon CloudFront KeyValueStore や Amazon DynamoDB などの低レイテンシーのキーバリューストアにこの詳細なテナント情報を保存することを検討してください。これにより、ルーティングにこれらの詳細を効率的に取得できます。 Amazon Route 53 と CloudFront による事例シナリオ ドメイン駆動のルーティングと同様に、データ駆動ルーティングの実装は、着信リクエストを処理するために選択するテナントルーティングサービスに依存します。 この例では、CloudFront をアプリケーションへの最初のエントリポイントとして使用します。 テナントコンテキスト (例: tenant-id ) を取得し、条件付きでリクエストを転送する発信元 (サービス) を選択することで、Lambda @ Edge でルーティングロジックを構成します。 図 4: CloudFront の Lambda @ Edge を使用したデータ駆動型ルーティングの例 Amazon Cognito を使ったユーザー認証 – テナントのコンテキストを取得するには、まず Amazon Cognito などのアイデンティティプロバイダを使ってユーザーを認証します。 認証すると、アイデンティティプロバイダから JSON Web トークン (JWT) が発行されます。 このトークンには、ユーザーが所属するテナントが含まれています。 次に、このトークンを認証 HTTP ヘッダに含めて、その後の HTTP リクエストを送信します。 Amazon Route 53 による DNS – データ駆動型ルーティングでは、たとえば www.example.com のように単一のドメインを使用して、すべてのテナントにアプリケーションへのアクセスを許可し、HTTP ヘッダにテナントのコンテキストを埋め込む場合があります。この例では、 Amazon Route 53 に別名 DNS レコードを設定 して、 www.example.com に関連するすべてのトラフィックを CloudFront ディストリビューションにルーティングします。 CloudFront の Lambda @ Edge での認証ベースのルーティング – CloudFront ディストリビューションにトラフィックがルーティングされると、それには以前にアイデンティティプロバイダから取得された暗号化 JWT を含む HTTP 認証ヘッダーが含まれています。この JWT には、ユーザーのテナントコンテキスト、たとえば tenant-id:tenant1 が含まれています。次に、Lambda @ Edge を設定して JWT を復号化し、テナントコンテキストを抽出します。JWT を検証するには、アイデンティティプロバイダから公開鍵を取得します。検証された後、リクエストをそのテナントに属するオリジンに転送します。このプロセスの詳細については、 authorization with Lambda @ Edge and JWT をご覧ください。 テナントのオンボーディング – テナントのオンボーディング の一部としてテナントルーティングを検討してください。 たとえば、新しいテナントのインフラストラクチャをプロビジョニングする際、Lambda @ Edge のルーティングロジックを更新して新しいテナントを考慮できます。 より拡張性の高いアプローチとしては、低レイテンシーのキーバリューストアにテナントから Origins へのマッピングを維持し、Lambda @ Edge のロジックからこれを参照することで、ルーティング決定をすることができます。 新しいテナントがオンボーディングされた際は、新しいルートを考慮するために新しいエントリを追加できます。 テナントルーティングの実装 テナントルーティングの実装方法は、SaaS アーキテクチャ、特に SaaS アプリケーションのエントリーポイントを処理するサービスに依存します。 サービスを選択する際は、ルーティング機能に加えて、パフォーマンス、セキュリティ、コストなどの一般的な要件を考慮する必要があります。 例えば、CloudFront と Lambda @ Edge を使って、データ駆動型のルーティングを行うだけでなく、レイテンシを削減し、 DDoS 攻撃からセキュアにすることもできます 。 別の例は HTTP リバースプロキシの利用です。その軽量な性質によりデータ駆動型のルーティングを効率的に実行できます。Kubernetes アーキテクチャでは、認証済みリクエストやテナントへのルーティングを管理するために、サービスメッシュを追加で利用することが一般的です。詳細は SaaS Identity and Routing with Amazon EKS を参照してください。 別の実装アプローチは、API Gateway を使用することです。API Gateway は、 ワイルドカードカスタムドメイン と Lambda オーソライザー を提供しており、ドメイン駆動型とデータ駆動型のルーティングアプローチをサポートします。 さらに、API Gateway は SaaS アプリケーションでも人気があり、 スロットリング による各テナントのリクエストをコントロールできるため、 ノイジーネイバー の影響を最小限に抑え、パフォーマンスを最適化できます。 スケーラビリティとシャーディングに関する考慮事項 テナントルーティングのアプローチに関係なく、拡張性は重大な検討事項です。テナントを増やしてオンボードしていくためです。 サービスクォータ によってルーティングロジックにおける最大ルート数に制限が設けられる可能性があることに注意してください。たとえば、Application Load Balancer のシナリオでは、テナントごとにリスナールールに依存します。CloudFront のシナリオでは、配布およびリクエストごとの関数に制限のある Lambda @ Edge に依存します。さらに CloudFront には、配布ごとのドメイン名と SSL 証明書に制限があります。これらの制約は、様々な アーキテクチャの決定 につながります。 これらのスケール制限を克服する高度なアプローチの 1 つは、 セルベースのアーキテクチャ を採用することです。これはテナントを シャードの分割単位に分けます。 ここでは、受信リクエストをまずシャードに、その後、シャード内のテナントにルーティングします。 図 5: プールされたテナントのリソースシャーディングを伴う SaaS アプリケーションでのテナントルーティング まとめ テナントルーティングは SaaS アプリケーションを構築する際に慎重に検討する必要があります。この記事では、ドメイン駆動のルーティングとデータ駆動のルーティングという 2 つの戦略を検討しました。簡単なテナントごとのサブドメインから、HTTP リクエストの内容に基づく高度なダイナミックルーティングまで、さまざまなアプローチについても説明しました。テナントルーティング戦略を設計する際は、スケーラビリティ、オペレーション、コストのトレードオフを検討する必要があります。さらに重要なのは、SaaS モデルに合致し、お客様にご期待の体験を提供できることです。さまざまなアプローチを評価し、目標ビジネスに合わせることで、お客様のニーズの変化に対応できる、安全でスケーラブルな SaaS アプリケーションを構築できるはずです。 SaaS アプリケーションの構築方法の詳細は、 AWS Well-Architected SaaS Lens をご覧ください。 本稿は、2024年6月25日に Networking & Content Delivery で公開された “ Tenant routing strategies for SaaS applications on AWS ” を翻訳したものです。翻訳は Solutions Architect の長屋が担当しました。

はじめに みなさん、こんにちは。2024 年 9 月 12 日に「 クラウド・生成 AI で実現するサステナビリティ 」を開催しました。 このブログでは、当日参加できなかった方や、参加したが内容を振り返りたい方に向けて、ご自身の取り組みの参考としていただくために当日のセッション内容のまとめを紹介します。 セッション内容の紹介 Amazon / AWS のサステナビリティの取り組みと、課題解決を支える AWS テクノロジー アマゾン ウェブ サービス ジャパン合同会社 事業開発統括本部 シニア事業開発マネージャー 杉山 彩奈 本セッションでは初めに Amazon サステナビリティレポート 2023 年度版 を中心に Amazon のサステナビリティの取り組みをご紹介いたしました。Amazon はパリ協定よりも 10 年早く、 2040 年までにネットゼロカーボン（温室効果ガス排出量実質ゼロ）を達成することを約束する誓約「 The Climate Pledge （クライメイト・プレッジ）」に署名する最初の企業となりました。また Amazon は 2023 年、当初の予定よりも ７ 年早く、Amazon 全体で使用する電力量と同等の電力を 100% 再生可能エネルギーで確保するという目標を達成しました。さらに 2024 年、サプライヤーに無料で情報提供を行う Amazon サステナビリティ・エクスチェンジ の立ち上げを行ったことをご紹介いたしました。 （より詳しく： Amazon サステナビリティ ） 続いて、AWS クラウドによって実現するサステナビリティには 3 つの要素があることをご紹介いたしました。 クラウドのサステナビリティ (Sustainability of the cloud) : クラウドへのマイグレーション（移行）による IT システムのサステナビリティを向上 クラウド内のサステナビリティ (Sustainability in the cloud) : AWS Well-Architected Framework のサステナビリティの柱や様々なサービスを利用した AWS のワークロードの最適化 クラウドを通じたサステナビリティ (Sustainability through the cloud) : AWS のテクノロジーとデータサービスを活用してサステナビリティの課題を解決 本セッションは 3 つ目のクラウドを通じたサステナビリティにフォーカスし、サステナビリティに関する主な課題として、データの収集・分析・報告の複雑さ、作業の非効率性、統一基準の欠如、データの品質・信頼性の問題、限られた洞察などを挙げています。これらの課題に対し、AWS は Guidance for Building a Sustainability Data Fabric on AWS (SDF) をはじめ、様々なユースケースに対応したソリューションを提供しています。 具体的な事例として、シアトルのスポーツアリーナ「 Climate Pledge Arena 」では、AWS を活用してカーボンフットプリントの計算や各種サステナビリティレポートの作成を実現しました。また、 三菱倉庫株式会社様 では、フォワーディングシステムの刷新により、より現実的な輸送ルートと温室効果ガス (GHG) プロトコル排出量算定し、最適なルート提案を可能にしました。 さらに、生成 AI の活用により、サステナビリティ関連の文書検索・要約、市場動向分析、リスク管理、コンプライアンス確保、データ収集・報告書作成の効率化などが可能になっています。 AWS のテクノロジーを活用することで、サステナビリティデータの収集・計算処理の自動化、開示基準の理解促進、データ収集の頻度向上、正確性・信頼性・監査可能性の向上などが実現できます。これにより、報告書作成作業に追われるのではなく、企業全体の脱炭素計画とモニタリング、各事業部との協力によるサステナビリティ取り組みの加速に注力できるようなることを紹介いたしました。 Amazon / AWS のサステナビリティの取り組みと、課題解決を支える AWS テクノロジー セッション資料 AWS を使ったサステナビリティソリューションの構築 アマゾン ウェブ サービス ジャパン合同会社 　ソリューションアーキテクト　戸塚 智哉 本セッションでは、企業のサステナビリティ対応の重要性と、排出量計測における課題が説明されました。 アクセンチュアの調査 によると、デジタル技術と持続可能性を両立させた「ツイントランスフォーマー」企業が 2.5 倍パフォーマンスが良いとされています。日本では 2050 年カーボンニュートラルを目指し温室効果ガス削減目標が掲げられていますが、多くの企業が計測に課題を抱えています。 その解決策として AWS の Guidance for Building a Sustainability Data Fabric on AWS が紹介されました。様々なデータソースからの収集・統合・分析が可能で、自社施設からのセンサーデータ収集や他社・公開データの活用などに対応できます。収集パターンに合わせた構築例も示されました。 さらに発展的なユースケースとして、サステナビリティデータの活用は、3 つのステップで進められます。まずは業務プロセスの最適化から始まり、データ種類が増えるにつれ経営判断の材料となり、最終的には対外的な公開や新規事業創出、収益多角化につながるとされています。 特に注目されているのがデジタルツインの活用です。製造企業ではエネルギー消費パターンを微調整することで、温室効果ガス (GHG) プロトコル スコープ 1 、2 、3 の排出量削減に貢献できます。また、サプライチェーン全体のカーボンフットプリントをリアルタイムで追跡し、製品の環境負荷を最大 40% 削減できるともいわれています。物流の最適化による排出量削減、収益と品質の向上も期待できます。 最後に、データ収集に課題を抱える企業は多いものの、AWS のサービスを活用することで効率的な開発が可能です。まずは小さな範囲から始め、徐々に機能を拡張していくことが推奨されました。サステナビリティ経営の重要性が高まる中、デジタルツインなどの先進的なソリューションの活用が企業の成長に大きく寄与することが期待されています。 AWS を使ったサステナビリティソリューションの構築 セッション資料 脱炭素 SaaS スタートアップである Terrascope のネットゼロへの取り組みと脱炭素化に向けた企業の動向 Terrascope Japan 株式会社 代表 廣田 達樹 様 Terrascope 様からまず、自社のネットゼロへの取り組みとして、2040 年にネットゼロを目指し、The Climate Pledge の署名企業でもあることをご紹介いただきました。自社の排出量の 98% が温室効果ガス (GHG) プロトコル スコープ 3 に集中しており、特に購入した商品・サービスが 62% を占めています。削減に向けて、ホットスポット分析やデータプロファイリングを実施し、4 つの重点領域(空調・再生可能エネルギー利用、従業員の出張、クラウドサービスの効率化、サプライヤーエンゲージメント)に取り組んでいます。 世界的な脱炭素化トレンドとして、以下の 5 つが挙げられました: 1. ネット・ゼロへの取り組みは、データの収集、脱炭素化アクション、グリーンイノベーションの 3 つの軸が重要 2. グローバルなトレンドの理解と、消費者の意識変化を踏まえた対応が企業に求められている 3. ESG プラットフォーム、カーボンプラットフォーム、環境プラットフォームの 3 つから、自社のステージに応じた選択が求められる 4. 排出データの収集方法には、支出ベース法、活動量ベース法、そしてそれらを組み合わせたハイブリッド方式がある 5. FLAG (Forest, Land and Agriculture、森林、土地利用、農業等) セクターには、より詳細なガイドラインが設定されている 企業は、自社の戦略やフェーズに応じて適切なサステナビリティプラットフォームを選択し、段階的にデータの質と精度を向上させていくことが重要であり、業界固有の基準やコンプライアンス要求にも注意を払う必要があることもご紹介いただきました。また最後には、完璧を求めるのではなく、データ収集から行動、改善のサイクルを繰り返し、少しずつ前進していくことが脱炭素化への道筋となると締めくくっていただきました。 Terrascope 様は 2022 年にシンガポールで創業した企業で、企業のカーボンフットプリント算定を支援するクラウド型ソフトウェアサービスを提供するスタートアップ企業です。親会社の Olam 社の 30 年近いサステナビリティの取り組みを活かし、大規模な排出原単位データベースと機械学習を用いて、複雑なサプライチェーンの排出量を効率的かつ精度高く算定できることが特徴です。 金融機関の脱炭素を強力に推進！ Persefoni が金融機関に与える価値とは。 PCAF に準拠した温室効果ガス排出量の算定と、ポートフォリオの脱炭素支援を実現。 Persefoni Japan Director, Sales and Partnerships – Japan 遠藤 トレイ 様 Persefoni 様は、この後ご紹介する PCAF (Partnership for Carbon Accounting Financials) を用いたファイナンスドエミッションの算定を含め、温室効果ガス排出量算定・可視化・分析プラットフォームを提供するグローバルで一元的な排出量算定を実現するプラットフォームを提供している企業です。 本セッションではまず、地球温暖化の現状と将来予測について説明がありました。観測史上最高の平均気温を記録し、温暖化がほぼ確実に人為的であることが科学的に立証されています。このまま温暖化が進むと、極端な高温や大雨、干ばつなどの自然災害が激化し、食料品価格の高騰や保険料の値上がりなど、家計にまで影響が及ぶことが示されました。 こうした背景から、炭素会計への取り組みが求められており、世界各国で温室効果ガス排出量の開示義務化が進んでいます。日本でも東証プライム上場企業に対して TCFD (気候関連財務情報開示タスクフォース) フレームワークに基づく情報開示が義務化され、今後有価証券報告書への記載も義務化される予定とご紹介がありました。企業は自社の排出量だけでなく、サプライチェーンの排出量の開示まで求められるようになっています。 金融機関においては、GHG プロトコル スコープ 3 カテゴリー 15 の投融資ポートフォリオからの排出量が特に重要で、これは自社の排出量の 700 倍にも上ると言われています。 金融機関の投融資における排出量算定のグローバルスタンダードとして、PCAF によるルールが確立されています。PCAF は様々なアセットクラスの算定を実現するルールを作成しており、金融機関の脱炭素化を進める上で重要な要素となっています。金融機関は投融資先の排出量を理解・管理して初めて、自社ポートフォリオの GHG 排出量削減に取り組むことができ、世界的な脱炭素目標の実現に貢献することができるのです。最後に気候変動対策が訴訟リスクにもつながる中、金融機関にとって正確な排出量算定と開示はますます重要になってきており、Persefoni 様においてこういったお客様を積極的にご支援していることをお伝えいただき、締めくくっていただきました。 Persefoni 様セッション資料 おわりに 本イベントでは、Amazon と AWS のサステナビリティへの取り組みと、AWS テクノロジーを活用したサステナビリティソリューションの構築について深く掘り下げました。また、Terrascope 様と Persefoni 様からは、実際のビジネス現場での脱炭素化の取り組みや、金融機関が直面する課題と解決策について貴重な洞察を共有いただきました。 サステナビリティは今や企業経営の中核を成す重要なテーマとなっています。本イベントを通じて、クラウドや生成 AI などの最新テクノロジーが、企業のサステナビリティ戦略を加速させ、より効果的なアクションにつながることをお伝えできたのではないでしょうか。 今回のセッション内容が、皆様のサステナビリティへの取り組みの一助となれば幸いです。AWS は今後も、お客様のサステナビリティ目標の達成を様々な面からサポートしてまいります。 著者について 杉山 彩奈 杉山 彩奈 (Ayana Sugiyama) は、クラウドを通じてお客様のサステナビリティ課題解決をご支援する、GTM (Go-To-Market) ソリューションマネージャーです。趣味は、家族と美味しい食べ物とコーヒー巡り、ゲームなどです。 戸塚 智哉 戸塚智哉 (Tomoya Tozuka) は、飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

このブログは AWS のクラウドサポートエンジニア Charles Adebayo と Suhail Fouzan によって執筆された内容を⽇本語化したものです。原⽂は こちら を参照して下さい。 オンプレミスまたは Amazon Elastic Compute Cloud (Amazon EC2) 上の重要なサーバーで実行されている AWS Systems Manager エージェント (SSM エージェント) が、何らかの理由で AWS Systems Manager (SSM) との正常な接続を失った際に、プロアクティブな通知を受けたいと思ったことはありませんか？ SSM エージェントのステータスの可視性を高め、ダッシュボードで監視したいと思ったことはありませんか？このブログ記事では、これらの目的を達成するための自動化された仕組みについて説明します。 この投稿では、 AWS Organizations 内の重要なマネージドノードで実行されている SSM エージェントのステータスを中央管理用の Amazon CloudWatch ダッシュボードでモニタリングする方法と、SSM エージェントが AWS Systems Manager との正常な接続を失ったときに、指定した Amazon Notification Service (SNS) トピックにメッセージを送信するように Amazon CloudWatch アラームを設定する方法を示します。E メールまたは携帯電話番号を SNS トピックに登録すると、Amazon CloudWatch アラームがアクティブになるたびにアラートを受け取ることができます。 監視対象の重要なマネージドノード (Amazon EC2 インスタンスでもオンプレミスノードでもかまいません) は、これらのリソースに適用した特定のタグ ( env: prod や ssmMonitoring: True など ) を使用して、他のノードと区別することができます。 ソリューション概要 このソリューションは以下のサービスによって実現されます: AWS CloudFormation AWS Lambda function AWS Identity and Access Management (IAM) AWS Systems Manager (SSM) Amazon CloudWatch Amazon Simple Notification Service (SNS) AWS Organizations Amazon EventBridge 図 1: ソリューション図 このソリューションでは、 AWS Lambda 関数 が特定のタグとリージョンによって識別された AWS Organizations 内の重要なマネージドノード上の SSM エージェントの接続状態をチェックし、その結果を PingStatus メトリクスとして中央管理用の Amazon CloudWatch ダッシュボードへレポートします。マネージドノードが Systems Manager に正常に接続されている場合、 DescribeInstanceInformation API の PingStatus は Online となります。Lambda 関数は Amazon CloudWatch に PingStatus メトリクスを作成します。これにより、 PingStatus が Online のときはメトリクス値が 0 になり、それ以外の場合は 1 になります。 また、Lambda 関数は重要なマネージドノードに対応する Amazon CloudWatch アラームを作成し、アラームがアクティブになった際に所定の SNS トピックへメッセージを送信するように設定します。この Lambda 関数は Amazon EventBridge カスタムルールによって定期的に呼び出されます。Lambda 関数を呼び出す頻度は Amazon EventBridge ルールで定義できます。 作成するアーキテクチャのワークフローは以下のとおりです: ターゲットアカウントの Lambda 関数 IAM ロールを引き受けます。 AWS EventBridge ルールは、スケジュールに従って ( 例えば 15 分ごとに ) Lambda 関数を呼び出します。 AWS Lambda 関数は、指定した特定のタグを持つマネージドノードの SSM エージェントの正常性ステータスをチェックし、Amazon CloudWatch のカスタムメトリクス PingStatus にデータポイントを Publish します。この Lambda 関数は、マネージドノードが追加された際には 他の CloudWatch API も呼び出して PingStatus メトリクスに対応する CloudWatch アラームを設定し、必要に応じてターゲットとなる Amazon SNS トピックを設定し、さらに Amazon CloudWatch ダッシュボードを作成または更新します。 タグ付けされた実行中のインスタンスが Systems Manager に表示されないか PingStatus が Online 以外の場合、CloudWatch の PingStatus メトリクス値を 1 に設定します。 Systems Manager 上の PingStatus が Online の場合、CloudWatch のメトリクス値を 0 に設定します。 いずれかのマネージドノードの PingStatus メトリクスが 1 に変わるとアラームがアクティブになり、Amazon SNS トピックのサブスクライバーに通知が送信されます。 ソリューションによって監視されていたインスタンスが終了するかモニタリングタグが削除された場合、次回 Lambda 関数が呼び出されて CloudWatch ダッシュボードが更新されるときに、対応するアラームが削除されます。 前提条件 このチュートリアルでは、次の要素が揃っている必要があります: AWS アカウントまたは AWS アカウントのリストまたは AWS Organizations オンプレミスまたは Amazon EC2 の AWS SSM マネージドノード マネージドノードに適用される タグ ( 例： SSMMonitoring: True ) 中央管理ダッシュボードと同じリージョンの Amazon SNS トピック。 SNS トピックのサブスクライバー は E メール、SMS などでもかまいません。 ウォークスルー このソリューション用にデプロイする CloudFormation テンプレートは 2 つあります: AWS Organizations のすべてのアカウントまたは特定の AWS アカウントに IAM ロールを作成します。 これらの IAM ロールは、次のステップで作成される SSMPingStatus Lambda 関数に引き継がれます。 提供されている CloudFormation テンプレートを使用して、任意の中央管理ダッシュボードリージョンとアカウントで CloudFormation スタックを起動し、SSMPingStatus モニタリングソリューションをデプロイします。 この CloudFormation テンプレートは、必要なコンポーネント (AWS Lambda 関数、CloudWatch アラーム (オプション)、Amazon EventBridge ルール、AWS CloudWatch ダッシュボード) を作成します。 ステップ 1: CloudFormation テンプレートと CloudFormation StackSets を使用して IAM ロールをデプロイします。 CloudFormation テンプレート をダウンロードします。 Organizations の管理アカウントまたは CloudFormation 委任管理者 の AWS CloudFormation コンソール に移動します。 ナビゲーションペインから StackSets を選択します。 StackSets ページの右上にある StackSet を作成 を選択します。 前提条件 – テンプレートの準備 で テンプレートの準備完了 を選択します。 テンプレートの指定 で テンプレートファイルのアップロード を選択し、 ファイルの選択 からステップ 1 でダウンロードしたファイルを選択して、 次へ を選択します。 StackSet の詳細を指定 ページで、次の手順を実行します: StackSet 名 と StackSet の説明 欄に SSMPingStatus-IAMRole を入力します。 パラメータ の CentralAccount に、ソリューションをホストするモニタリングアカウントのアカウント ID を入力します。 AWSSSMPingStatusCrossAccountRoleName にはデフォルト値の AWS-Lambda-SSMPingStatus-Cross-Account-Role のままにするか、Lambda が中央管理アカウントから引き継ぐ IAM ロールのカスタム名を入力します。 次へ をクリックします。 図 2: CloudFormation StackSet のパラメーター StackSet オプションの設定 ページで必要に応じてタグを指定し、 AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します をチェックして 次へ を選択します。 デプロイオプションの設定 ページの リージョンを指定 で、目的のリージョン（ us-east-1 など ）を選択します。今回作成するのはグローバルリソースである IAM リソースだけなので、1 つのリージョンのみを選択して 次へ をクリックします。 すべての情報を確認して 送信 をクリックします。 ページを更新すると StackSet のステータスが RUNNING になっているはずです。 ステータスが SUCCEEDED に変わったら、次のセクションに進んでください。 図 3 に示すように、CloudFormation StackSet コンソールの スタックインスタンス タブで個々のスタックインスタンスの結果を確認できます。 注: ドキュメント によると、CloudFormation StackSets は、管理アカウントが組織内または組織内の OU にあっても、スタックインスタンスを組織の管理アカウントにデプロイしません。 したがって、管理アカウントまたは委任管理者アカウントをこの監視ソリューションの対象として含める場合は、管理アカウントまたは委任管理者アカウントのスタックとして IAM ロール SSMAgent_IAM_role.yml を作成する必要があります。 図 3: CloudFormation StackSets のターゲットアカウントのステータス ステップ 2: CloudFormation テンプレートを使用して SSMPingStatus ソリューションをデプロイする CloudFormation テンプレート をダウンロードします。 SSM エージェントのステータスをモニタリングする AWS アカウントの CloudFormation コンソール に移動します。 スタックの作成 で 新しいリソースを使用 (標準) を選択します。 テンプレートソース で テンプレートファイルのアップロード を選択します。 ファイルの選択 から、ステップ 1 でダウンロードしたテンプレートを指定します。 次へ をクリックします。 スタック名として SSMPingStatus と入力します。 パラメータ で、以下の通り AWS CloudFormation スタックのパラメータを指定します: Target では、AWS Organizations 内のすべてのアカウントをターゲットにする場合は AWS Organization を、特定のアカウントをターゲットにする場合は Accounts を選択します。 注: Target パラメータが AWS Organization の場合、このスタックは管理アカウントまたは AWS サービスの委任管理者のいずれかにデプロイする必要があります。 ただし、 Target パラメータが Accounts の場合は、AWS Organizasions のどのアカウントでもこのソリューションを起動できます。 (オプション) TargetAccounts では、上記 7.1 のステップで Accounts を選択した場合は監視対象のマネージドノードをホストしているアカウントのリストをカンマで区切って入力します ( 例:1111111111,222222222,333333333 )。 それ以外の場合は空白のままにしてください。 TargetRegionIds では、監視対象のマネージドノードをホストするリージョンのリストをカンマで区切って入力します ( 例:us-east-1,us-east-2,eu-west-2 )。 Tag では、 CloudWatch でモニタリングする特定のマネージドノードのタグの key:value のペアを入力します ( 例: SSMMonitoring:true )。 EventBridgeSchedule では、モニタリングソリューションの実行頻度を cron 形式 で入力します。 例えば、 cron(0/15 * * * ? *) は 15 分間隔のスケジュールです。この設定により、マネージドノードのステータスをトラックするために Lambda 関数が呼び出される頻度が決まります。使用されるタイムゾーンは UTC です。詳細については、 Amazon EventBridge schedule を参照してください。 CrossAccountExecutionRoleName では、ステップ 1 でターゲットとなる全 AWS アカウントで作成した Lambda が使用するロールの名前を入力します ( 例:AWS-Lambda-SSMPingStatus-Cross-Account-Role )。 CloudwatchCentralDashboardRegion では、アカウントやリージョンをまたいでマネージドノードをトラックするために Amazon CloudWatch ダッシュボードを作成するリージョンの名前を入力します ( 例:us-east-1 )。 CreateCloudWatchAlarm では、監視対象のマネージドノードごとにアラームを作成する場合は true を、それ以外の場合は false を入力します。 (オプション) SNSTopicArn では、 CreateCloudWatchAlarm パラメータが true の場合に CloudWatch アラームのターゲットとして使用される SNS トピックの Amazon リソースネーム (ARN) を入力します。 RetainCloudWatchResourcesOnDelete では、スタック削除操作時に CloudWatch アラームとダッシュボードを保持したい場合は true を入力し、それ以外の場合は false のままにします。 図 4: CloudFormation テンプレートのパラメーター スタックオプションの設定 ページで必要に応じてタグを指定し、 AWS CloudFormation によって IAM リソースが作成される場合があることを承認します をチェックして 次へ を選択します。 確認して作成 ページですべての情報を確認して 送信 をクリックします。 テンプレートがデプロイされたら、 出力 タブを選択し、 図 5 に示すように次の値を書き留めます: AWSLambdaSSMPingStatusRoleName EventBridgeRule SSMPingStatusLambdaFunctionName 図 5: CloudFormation の出力タブ モニタリングダッシュボードの表示 Amazon CloudWatch コンソール に移動します。 左上のメニューで ダッシュボード を選択します。 カスタムダッシュボード で AWSOrganization-SSMAgentPingStatus を選択します。 図 6: 特定のタグが付与されたマネージドノード用の Amazon CloudWatch ダッシュボード 注: 上のスクリーンショットの 4 つのウィジェットはそれぞれ、CloudFormation スタックのデプロイ時に指定されたタグによって監視対象と識別されたマネージドノードを表しています。 マネージドノードが見つからない場合、グラフ化されたウィジェットは表示されません。 インスタンスウィジェットの 1 つをクリックして拡大することもできます: 図 7: 特定のマネージドノードの PingStatus の値が 1 であることを示す CloudWatch ダッシュボード 作成された CloudWatch アラームの表示 マネージドノードの PingStatus メトリクスが 1.0 になると CloudWatch アラームがアクティブになり、SNS トピックのサブスクライバーに通知が送信されます (CloudFormation テンプレートのパラメータでアラーム設定が有効になっている場合)。 これをシミュレートするには、インスタンスにログオンして SSM エージェントサービスを停止するか、マネージドインスタンスをシャットダウンして EventBridge ルールによる Lambda 関数の次の呼び出しを待ちます。アラームは以下の手順で表示します: Amazon CloudWatch コンソールに移動します。 左上のメニューで アラーム を選択します。 アラーム状態 を選択すると、 図 8 に示すように、現在アラーム状態になっているすべてのインスタンスが表示されます。 図 8: アラームがアクティブ化された特定のマネージドノードを示す CloudWatch Alarm ダッシュボード 図 9 に示すように、ソリューションで提供されている SNS トピックに E メール通知が送信されます。 図 9: アラームがアクティブになったときの電子メール通知 マネージドノードとして報告されない、または ConnectionLost のステータスが報告されるサーバーを修正するには このガイド を参照してください。 ソリューションの導入コストは、マネージドインスタンスが 50 個の場合、概算で 1 か月あたり 20 ドル ～ 25 ドルです。 クリーンアップ 今後料金が発生しないようにするには、 CloudFormation スタックとスタックセットを削除してリソースを削除してください。 CloudFormation によって作成されたリソースをクリーンアップするには以下の手順を実施します: 子アカウントの SSMPingStatus-IAMRole を作成するために使用した Organizations の管理アカウントまたは CloudFormation 委任管理者 の AWS CloudFormation コンソール に移動します。 StackSets を選択し、 SSMPingStatus-IAMRole という名前の CloudFormation スタックセットを選択します。 このガイド を使用して、関連するスタックをスタックセットから削除します。 このガイド を使用して StackSets を削除します。 モニタリングアカウントに移動し、モニタリングアカウントのソリューション作成のために使用した SSMPingStatus という名前の CloudFormation スタックを削除します。 AWS CloudFormation コンソール を開き、ナビゲーションペインで スタック を選択します。 SSMPingStatus という名前の CloudFormation スタックを選択し、 削除 を選択し、 スタックの削除 を選択します。 まとめ このソリューションをデプロイし、Amazon CloudWatch ダッシュボードと CloudWatch アラームを利用して SSM エージェントの状態を監視することで、AWS Organizations 内のマネージドノード全体で SSM エージェントのオブザーバビリティが向上しました。 これにより、応答時間が短縮され、フリート内の重要なサーバー全体で SSM エージェントの問題が解決され、SSM エージェントの障害による全体的なダウンタイムが短縮されます。 このソリューションをさらに拡張して、マネージドノード用に作成された CloudWatch アラームがアクティブになるたびに AWS Systems Manager Incident Manager のインシデントを作成する こともできます。 さらに、Amazon EventBridge ルールを使用して CloudWatch アラームを監視し、カスタム修復/プレイブックをルールのターゲットとして定義することもできます。 著者について: Charles Adebayo Charles Adebayo は AWS ケープタウンオフィスのクラウドサポートエンジニアです。 Charles は世界中のお客様と協力して、一元化された運用のマイグレーション、モダナイゼーション、合理化を支援しています。 Charles はAWS Systems Manager、EC2 Windows、マイグレーションサービスを専門としています。 テクノロジー以外では、Charles は上級ピアニストでオーケストラでの演奏を楽しんでいます。 Suhail Fouzan Suhail Fouzan は、Systems Manager (SSM)、EC2、マイグレーションサービスを専門とする AWS プレミアムサポートのクラウドサポートエンジニアです。 彼は SSM 領域の専門性を活かして、お客様のシステム管理を合理化し集中管理することを支援しています。仕事以外ではクリケットをプレーしたり家族と時間を過ごすのが好きです。 翻訳は Solutions Architect の小野が担当しました。原文は こちら です。

本記事は AWS Principal Product Manager の Julian Payne による投稿の日本語訳です。原文は こちら よりご確認いただけます。 Amazon Kinesis Data Analytics for SQL は、ストリーミングソースに対して独自の SQL コードを実行し、時系列分析の実行、リアルタイムダッシュボードへのデータ供給、リアルタイムメトリクスの作成を支援するデータストリーム処理エンジンです。AWS は、 2026 年 1 月 27 日をもって Kinesis Data Analytics for SQL の提供を終了することを決定しました。この記事では、Kinesis Data Analytics for SQL サポート終了の背景、代替となる AWS サービス、および SQL クエリとワークロードの移行方法について解説します。 Kinesis Data Analytics for SQL の概要 以下の図は、Kinesis Data Analytics for SQL の使用ワークフローを示しています。 2021 年より、Kinesis Data Analytics for SQL は、 AWS 公式サイト 、 AWS Management Console 、および デベロッパーガイド においてレガシー製品であることが示されていました。この間、新機能の追加や新しい AWS リージョンへの展開は行われていませんでした。しかし、サービスの既存機能のメンテナンスやパッチ適用、お客様のサポートはアクティブに行われてきました。これらは今後も継続的に行われます。 Kinesis Data Analytics for SQL からの移行計画を支援するため、提供の終了は段階的に行います。 2025 年 10 月 15 日以降、新規の Kinesis Data Analytics for SQL アプリケーションは作成できなくなります。既存のアプリケーションは通常通り実行可能です。 2026 年 1 月 27 日に、残存する全てのアプリケーションが削除されます。この日以降、Kinesis Data Analytics for SQL アプリケーションの起動や操作はできなくなり、サポートも行われなくなります。 Managed Service for Apache Flink および Apache Flink Studio の概要 2016 年に提供が開始された Kinesis Data Analytics for SQL は、 Amazon Managed Service for Apache Flink や Amazon Managed Service for Apache Flink Studio など、現在ではポピュラーな AWS データストリーム処理サービス以前に登場したものです。私たちは、お客様が Kinesis Data Analytics for SQL ではなく、こうした新しいサービスの利用を検討するようになったことに気づきました。 Amazon Managed Service for Apache Flink は、低レイテンシー・高可用性・高度なスケーラビリティを有するサーバーレスなリアルタイムストリーム処理サービスです。Apache Flink は、データストリーム処理に向いているオープンソースの分散エンジンです。マネージドな Flink ベースのサービスは、Kinesis Data Analytics for SQL では利用できない機能を提供し、エンドツーエンドのストリーミングパイプラインの構築、データの正確性と即時性の維持に役立ちます。例えば、Amazon Managed Service for Apache Flink は、ビルトインのスケーリング機能、exactly-once のセマンティクス、SQL を含む複数の開発言語サポート、40 以上のソース・シンクコネクタ、アプリケーション状態の永続化などをサポートしています。 私たちは、お客様がマネージド Flink サービスが提供する高度な機能を活用するために、Kinesis Data Analytics for SQL のワークロードを移行しているのを目にしています。SQL クエリを実行しているお客様は、Amazon Managed Service for Apache Flink Studio を選択しています。Amazon Managed Service for Apache Flink Studio は、ノートブック (Web ベースの開発環境) を提供します。ノートブックを使用することで、Flink が提供する高度な機能による、シンプルかつインタラクティブな開発体験が得られます。Amazon Managed Service for Apache Flink Studio は、ノートブックとして Apache Zeppelin を使用し、ストリーム処理エンジンとして Flink を使用します。Amazon Managed Service for Apache Flink Studio ノートブックは、これらのテクノロジーをシームレスに組み合わせ、あらゆるスキルレベルの開発者がデータストリームに対する高度な分析を行えるようにします。ノートブックは素早くプロビジョニングされるため、ストリーミングデータの表示・分析をすぐに行うことができます。Zeppelin は、Amazon Managed Service for Apache Flink Studio ノートブックに以下の機能を含む完全な分析ツールスイートを提供します。 データの可視化 データのファイルへのエクスポート 簡単な分析のための出力フォーマットの制御 ノートブックをスケーラブルな本番アプリケーションに変換 以下の図は、Managed Service for Apache Flink の一般的なワークフローを示しています。 Kinesis Data Analytics for SQL とは異なり、Managed Service for Apache Flink は以下の SQL  機能を追加でサポートしています。 複数の Amazon Kinesis Data Streams 間、または Kinesis のデータストリーム と Amazon Managed Streaming for Apache Kafka (Amazon MSK) トピック間でのストリームデータを結合する データストリーム内のデータを、処理・変換し、リアルタイムに可視化する 同一アプリケーション内で、 Python スクリプトまたは Scala プログラムを使用する ストリーミングレイヤーのオフセットを変更する Amazon Managed Service for Apache Flink のもう一つの利点は、デプロイ後のソリューションのスケーラビリティが向上することです。Managed Service for Apache Flink では、負荷に応じてインフラストラクチャのリソースが動的にスケールします。Kinesis Data Analytics for SQL アプリケーションをスケールさせるためには、ポンプを追加し、アプリケーションにリソース追加を促す必要がありました。 Managed Service for Apache Flink への移行 Kinesis Data Analytics for SQL から Amazon Managed Service for Apache Flink Studio への移行に関する詳細については、 Amazon Kinesis Data Analytics for SQL アプリケーションから Amazon Managed Service for Apache Flink Studio への移行 をご覧ください。さらに、Kinesis Data Analytics for SQL の 17 の一般的なクエリを Amazon Managed Service for Apache Flink Studio で再現する方法のサンプルコードを含むガイダンスを、 公式ドキュメント として提供しています。ドキュメントは今後も拡充していく予定です。 Amazon Data Firehose をソースとして使用しているお客様や、Amazon Managed Service for Apache Flink でユーザー定義関数を使用したいお客様向けに、ステップバイステップの移行ガイダンスも作成しました。また、Kinesis Data Analytics for SQL から Amazon Managed Service for Apache Flink への機械学習ワークロードの移行を支援するドキュメントも提供しています。 まとめ この記事では、Kinesis Data Analytics for SQL の提供終了の計画とその背景について解説しました。Kinesis Data Analytics for SQL のワークロードを Amazon Managed Service for Apache Flink および Apache Flink Studio に移行することを推奨します。移行を開始するためのリソースを提供しています。さらなるサポートが必要な場合は、 re:Post で質問することができます。その際、質問には Kinesis Data Analytics for SQL のタグの付与をお願いいたします。 著者について Julian Payne は、AWS のプリンシパルプロダクトマネージャーです。クラウド上でリアルタイムデータ処理アプリケーションを使用して顧客がイノベーションを起こせるよう、製品や機能の構築に情熱を注いでいます。プライベートでは、グラフィックノベルの執筆とイラスト制作を行っています。

本記事は、AWS の Worldwide Public Sector におけるパートナーソリューションアーキテクトである Nicholas Tunney によって作成されたものの日本語版です。原文は こちら よりご確認いただけます。 2024 年 10 月 17 日: Amazon Kinesis Data Analytics for SQL の提供終了が発表されました。詳細は AWS News Blog をご覧ください。 2024 年 2 月 9 日: Amazon Kinesis Data Firehose は Amazon Data Firehose に名称変更されました。詳細は AWS What’s New post をご覧ください。 2023 年 8 月 30 日: Amazon Kinesis Data Analytics は Amazon Managed Service for Apache Flink に名称変更されました。詳細は AWS News Blog をご覧ください。 この記事では、 Apache Flink の高度なストリーミング機能を活用するために、 Kinesis Data Analytics for SQL アプリケーションから Amazon Managed Service for Apache Flink への移行を AWS が推奨する理由について説明します。また、 Amazon Managed Service for Apache Flink Studio を使用して、移行したアプリケーションをデプロイする前に分析アプリケーションをテスト・チューニングする方法も紹介します。Kinesis Data Analytics for SQL アプリケーションを利用されていないお客様に対しても、この記事はデータ分析の過程で遭遇する多くのユースケースと、Amazon Managed Service for Apache Flink がどのように目標達成を支援できるかについて、背景となる情報を提供します。 Amazon Managed Service for Apache Flink は、フルマネージド型の Apache Flink サービスです。アプリケーション JAR または実行可能ファイルをアップロードするだけで、AWS がインフラストラクチャと Flink ジョブのオーケストレーションを管理します。また、Apache Flink を使用するノートブック環境である Amazon Managed Service for Apache Flink Studio を活用することで、データストリームのクエリや SQL クエリの開発、または概念実証ワークロードの開発を行うことを容易とし、アプリケーションの本番環境への展開を数分で行うこともできます。 Kinesis Data Analytics for SQL よりも Amazon Managed Service for Apache Flink または Amazon Managed Service for Apache Flink Studio の使用をお勧めします。Amazon Managed Service for Apache Flink と Amazon Managed Service for Apache Flink Studio が、exactly-once 処理セマンティクス、イベント時間ウィンドウ、ユーザー定義関数 (UDF) とカスタム統合を使用した拡張性、命令型言語のサポート、永続的なアプリケーション状態、水平スケーリング、複数のデータソースのサポートなど、高度なデータストリーム処理機能を提供するためです。Kinesis Data Analytics for SQL にはないこれらの機能は、データストリーム処理の正確性、完全性、一貫性、信頼性を保証する上で重要なものです。 ソリューション概要 今回のユースケースは、いくつかの AWS サービスを使用して、サンプルの自動車センサーデータをストリーミング、取り込み、変換し、Amazon Managed Service for Apache Flink Studio を使用してリアルタイムで分析するというものです。Amazon Managed Service for Apache Flink Studio を使用すると、Web ベースの開発環境であるノートブックを作成できます。ノートブックを使用すると、Apache Flink が提供する高度な機能と組み合わせた、シンプルでインタラクティブな開発エクスペリエンスを得ることができます。Amazon Managed Service for Apache Flink Studio は Apache Zeppelin をノートブックとして使用し、Apache Flink をストリーム処理エンジンとして使用します。Amazon Managed Service for Apache Flink Studio のノートブックは、これらのテクノロジーをシームレスに組み合わせて、あらゆるスキルレベルの開発者がデータストリームの高度な分析にアクセスできるようにします。ノートブックはすぐにプロビジョニングされ、ストリーミングデータを即座に表示および分析する手段を提供します。Apache Zeppelin は、Studio ノートブックに以下を含む完全な分析ツールスイートを提供します。 データの可視化 ファイルへのデータのエクスポート より簡単な分析のための出力フォーマットの制御 ノートブックをスケーラブルな本番アプリケーションに変換する機能 Kinesis Data Analytics for SQL アプリケーションとは異なり、Amazon Managed Service for Apache Flink は以下の SQL を追加でサポートします。 複数の Kinesis データストリーム間、または Kinesis データストリームと Amazon Managed Streaming for Apache Kafka (Amazon MSK) トピック間でのストリームデータの結合 データストリーム内の変換されたデータのリアルタイム可視化 同じアプリケーション内での Python スクリプトまたは Scala プログラムの使用 ストリーミングレイヤーのオフセットの変更 Amazon Managed Service for Apache Flink のもう一つの利点は、デプロイ後にソリューションのスケーラビリティが向上することです。需要に応じて基盤となるリソースをスケールできるためです。Kinesis Data Analytics for SQL アプリケーションをスケーリングするためには、ポンプを追加してアプリケーションにより多くのリソースを使用するよう促す必要があります。 このソリューションでは、自動車センサーデータにアクセスし、データのエンリッチを行い、結果を Amazon Data Firehose ストリーム経由で、 Amazon Simple Storage Service (Amazon S3) データレイクに配信する Amazon Managed Service for Apache Flink Studio ノートブックを作成します。このパイプラインは、さらなる処理や可視化のために Amazon OpenSearch Service やその他のターゲットにデータを送信する際にも使用できます。 Kinesis Data Analytics for SQL アプリケーション vs. Amazon Managed Service for Apache Flink この例では、ストリーミングデータに対して以下のアクションを実行します。 Amazon Kinesis Data Streams データストリームに接続する。 ストリームデータを表示する。 データを変換および充実させる。 Python でデータを操作する。 データを Firehose ストリームに再ストリーミングする。 Kinesis Data Analytics for SQL アプリケーションと Amazon Managed Service for Apache Flink を比較するために、まず Kinesis Data Analytics for SQL アプリケーションがどのように機能するかを説明しましょう。 Kinesis Data Analytics for SQL アプリケーションの根幹には、アプリケーション内ストリームの概念があります。アプリケーション内ストリームは、ストリーミングデータを保持し、データに対してアクションを実行できるテーブルと考えることができます。アプリケーション内ストリームは、Kinesis Data Streams などのストリーミングソースにマッピングされます。アプリケーション内ストリームにデータを取り込むには、まず Kinesis Data Analytics for SQL アプリケーションの管理コンソールでソースをセットアップします。次に、ソースストリームからデータを読み取り、テーブルに配置するポンプを作成します。ポンプクエリは継続的に実行され、ソースデータをアプリケーション内ストリームに供給します。複数のソースから複数のポンプを作成して、アプリケーション内ストリームにデータを供給できます。その後、アプリケーション内ストリームに対してクエリが実行され、結果を解釈したり、さらに処理や保存のために他の宛先に送信したりできます。 以下の SQL は、アプリケーション内ストリームとポンプのセットアップを示しています。 CREATE OR REPLACE STREAM "TEMPSTREAM" ( "column1" BIGINT NOT NULL, "column2" INTEGER, "column3" VARCHAR(64)); CREATE OR REPLACE PUMP "SAMPLEPUMP" AS INSERT INTO "TEMPSTREAM" ("column1", "column2", "column3") SELECT STREAM inputcolumn1, inputcolumn2, inputcolumn3 FROM "INPUTSTREAM"; アプリケーション内ストリームからデータを読み取るには、SQL SELECT クエリを使用します。 SELECT * FROM "TEMPSTREAM" Amazon Managed Service for Apache Flink Studio で同様のセットアップを行う場合、基盤となる Apache Flink 環境を使用してストリーミングソースに接続し、コネクタを使用して 1 つのクエリでデータストリームを作成します。以下の例は、以前と同じソースに接続していますが、Apache Flink を使用しています。 CREATE TABLE `MY_TABLE` ( "column1" BIGINT NOT NULL, "column2" INTEGER, "column3" VARCHAR(64) ) WITH ( 'connector' = 'kinesis', 'stream' = sample-kinesis-stream', 'aws.region' = 'aws-kinesis-region', 'scan.stream.initpos' = 'LATEST', 'format' = 'json' ); MY_TABLE は、サンプルの Kinesis Data Streams からデータを継続的に受信するデータストリームです。SQL SELECT クエリを使用して問い合わせが可能です。 SELECT column1, column2, column3 FROM MY_TABLE; Kinesis Data Analytics for SQL アプリケーションはストリーミングデータ上での操作を可能にする拡張機能を持つ SQL:2008 標準のサブセット を使用していますが、 Apache Flink の SQL サポート は SQL 標準を実装する Apache Calcite  を基にしています。 また、Amazon Managed Service for Apache Flink Studio が同じノートブック内で、 SQL の他に PyFlink と Scala の実行をサポートしていることも重要なポイントです。これにより、SQL だけでは不可能な、プログラミングによる複雑なストリーミングデータ処理を行うことができます。 前提条件 この演習では、さまざまな AWS リソースをセットアップし、分析クエリを実行します。移行の作業を進めるには、管理者アクセス権を持つ AWS アカウントが必要です。まだ管理者アクセス権を持つ AWS アカウントをお持ちでない場合は、 作成 してから以降の作業を進めてください。この記事で説明するサービスは、AWS アカウントに課金される可能性があります。不要な課金を停止するために、この記事の最後にあるクリーンアップ手順に従ってください。 ストリーミングデータの構成 ストリーミングの領域における典型的なタスクは、IoT センサーからのデータの取得、変換、エンリッチです。本演習では、リアルタイムのセンサーデータを生成するために、 AWS IoT Device Simulator を使用します。シミュレータは AWS アカウント内で実行され、Web インターフェイスを提供します。ユーザーは、ユーザー定義のテンプレートから仮想的に接続されたデバイスのフリートを起動し、それらをシミュレートして定期的に AWS IoT Core にデータを配信できます。本演習用のサンプルデータを生成するための仮想デバイスフリートを構築できるということです。 以下の Amazon CloudFormation   テンプレート を使用して IoT Device Simulator をデプロイします。これにより、必要なすべてのリソースがアカウント内に作成されます。 「スタックの詳細を指定」ページで、ソリューションスタックに名前を割り当てます。 「パラメータ」で、このソリューションテンプレートのパラメータを確認し、必要に応じて変更します。 「User email」に、IoT Device Simulator UI にログインするためのリンクとパスワードを受け取るための有効なメールアドレスを入力します。 「次へ」を選択します。 「スタックオプションの設定」ページで、「次へ」を選択します。 「確認」ページで、設定を確認して確認します。テンプレートが AWS Identity and Access Management (IAM) リソースを作成することを認識するチェックボックスを選択します。 「スタックの作成」を選択します。 スタックのインストールには約 10 分かかります。 招待メールを受け取ったら、CloudFront リンクを選択し、メールに記載されている認証情報を使用して IoT Device Simulator にログインします。 このソリューションには、AWS ですぐにセンサーデータの配信を開始できるようにするための、事前構築された自動車デモが含まれています。 「Device Type」ページで、「Create Device Type」を選択します。 「Automotive Demo」を選択します。 ペイロードは自動的に入力されます。デバイスの名前を入力し、トピックとして “automotive-topic” を入力します。 「Save」を選択します。 次に、シミュレーションを作成します。 「Simulations」ページで、「Create Simulation」を選択します。 「Simulation type」で、「Automotive Demo」を選択します。 「Select a device type」で、作成したデモデバイスを選択します。 「Data transmission interval」と「Data transmission duration」に希望の値を入力します。 好みの値を入力できますが、少なくとも 10 秒ごとに送信する 10 台のデバイスを使用してください。データ送信期間は数分に設定してください。そうしないと、ラボ中に何度もシミュレーションを再起動する必要があります。 「Save」を選択します。 これでシミュレーションを実行できます。 「Simulations」ページで、目的のシミュレーションを選択し、「Start simulations」を選択します。 または、実行したいシミュレーションの横にある「View」を選択し、「Start」を選択してシミュレーションを実行します。 シミュレーションを表示するには、表示したいシミュレーションの横にある「View」を選択します。 シミュレーションが実行中の場合、デバイスの位置を示すマップと、IoT トピックに送信された最新の 100 件までのメッセージを表示できます。 次に、シミュレータが AWS IoT Core にセンサーデータを送信していることを確認できます。 AWS IoT Core コンソールに移動します。 IoT Device Simulator をデプロイしたのと同じリージョンにいることを確認してください。 ナビゲーションペインで、「MQTT Test Client」を選択します。 トピックフィルターとして “automotive-topic” を入力し、「Subscribe」を選択します。 シミュレーションを実行している限り、IoT トピックに送信されているメッセージが表示されます。 最後に、IoT メッセージを Kinesis Data Streams にルーティングするルールを設定できます。このストリームは、Amazon Managed Service for Apache Flink Studio ノートブックのソースデータを提供します。 AWS IoT Core コンソールで、「Message Routing」と「Rules」を選択します。 ルールの名前を入力します（例: “automotive_route_kinesis”）、そして「Next」を選択します。 以下の SQL クエリを実行します。この SQL は、IoT Device Simulator が公開している “automotive-topic” からすべてのメッセージ列を選択します。 SELECT timestamp, trip_id, VIN, brake, steeringWheelAngle, torqueAtTransmission, engineSpeed, vehicleSpeed, acceleration, parkingBrakeStatus, brakePedalStatus, transmissionGearPosition, gearLeverPosition, odometer, ignitionStatus, fuelLevel, fuelConsumedSinceRestart, oilTemp, location FROM 'automotive-topic' WHERE 1=1 「Next」を選択します。 「Rule Actions」で、ソースとして「Kinesis Stream」を選択します。 「Create New Kinesis Stream」を選択します。 これにより新しいウィンドウが開きます。 「Data stream name」に “automotive-data” と入力します。 この演習では CloudFormation により事前に作成されたストリームを使用します。 「Create Data Stream」を選択します。 このウィンドウを閉じて AWS IoT Core コンソールに戻ることができます。 「Stream name」の横にある更新ボタンを選択し、”automotive-data” ストリームを選択します。 「Create new role」を選択し、ロールに “automotive-role” という名前を付けます。 「Next」を選択します。 ルールのプロパティを確認し、「Create」を選択します。 ルールはすぐにデータのルーティングを開始します。 Amazon Managed Service for Apache Flink Studio のセットアップ データが AWS IoT Core を通じてストリーミングされ、Kinesis Data Streams に入力されるようになったので、Amazon Managed Service for Apache Flink Studio ノートブックを作成できます。 Amazon Kinesis コンソールで、ナビゲーションペインの「Analytics applications」を選択します。 「Studio」タブで、「Create Studio notebook」を選択します。 「Quick create with sample code」を選択したままにします。 ノートブックに “automotive-data-notebook” という名前を付けます。 新しいウィンドウで「Create」を選択して、 AWS Glue の Data Catalog 内に新規にデータベースを作成します。 「Add database」を選択します。 データベースに “automotive-notebook-glue” という名前を付けます。 「Create」を選択します。 「Create Studio notebook」セクションに戻ります。 更新を選択し、新しい AWS Glue データベースを選択します。 「Create Studio notebook」を選択します。. Studio ノートブックを開始するには、「Run」を選択して確認します。 ノートブックが実行されたら、ノートブックを選択し、「Open in Apache Zeppelin」を選択します。 「Import note」を選択します。 「Add from URL」を選択します。 以下の URL を入力します: https://aws-blogs-artifacts-public.s3.amazonaws.com/artifacts/BDB-2461/auto-notebook.ipynb 「Import Note」を選択します。 新しいノートを開きます。 ストリーム分析の実行 Kinesis Data Analytics for SQL アプリケーションでは、管理コンソールを通じてストリーミングソースを追加し、アプリケーション内ストリームとポンプを定義して、Kinesis Data Streams からデータをストリーミングします。アプリケーション内ストリームは、データを保持し、クエリに利用できるようにするテーブルとして機能します。ポンプは、ソースからデータを取り込み、アプリケーション内ストリームにストリーミングします。その後、任意の SQL テーブルをクエリするのと同じように、SQL を使用してアプリケーション内ストリームに対してクエリを実行できます。以下のコードをご覧ください: CREATE OR REPLACE STREAM "AUTOSTREAM" ( `trip_id` CHAR(36), `VIN` CHAR(17), `brake` FLOAT, `steeringWheelAngle` FLOAT, `torqueAtTransmission` FLOAT, `engineSpeed` FLOAT, `vehicleSpeed` FLOAT, `acceleration` FLOAT, `parkingBrakeStatus` BOOLEAN, `brakePedalStatus` BOOLEAN, `transmissionGearPosition` VARCHAR(10), `gearLeverPosition` VARCHAR(10), `odometer` FLOAT, `ignitionStatus` VARCHAR(4), `fuelLevel` FLOAT, `fuelConsumedSinceRestart` FLOAT, `oilTemp` FLOAT, `location` VARCHAR(100), `timestamp` TIMESTAMP(3)); CREATE OR REPLACE PUMP "MYPUMP" AS INSERT INTO "AUTOSTREAM" ("trip_id", "VIN", "brake", "steeringWheelAngle", "torqueAtTransmission", "engineSpeed", "vehicleSpeed", "acceleration", "parkingBrakeStatus", "brakePedalStatus", "transmissionGearPosition", "gearLeverPosition", "odometer", "ignitionStatus", "fuelLevel", "fuelConsumedSinceRestart", "oilTemp", "location", "timestamp") SELECT VIN, brake, steeringWheelAngle, torqueAtTransmission, engineSpeed, vehicleSpeed, acceleration, parkingBrakeStatus, brakePedalStatus, transmissionGearPosition, gearLeverPosition, odometer, ignitionStatus, fuelLevel, fuelConsumedSinceRestart, oilTemp, location, timestamp FROM "INPUT_STREAM" Kinesis Data Analytics for SQL アプリケーションからのアプリケーション内ストリームとポンプを Amazon Managed Service for Apache Flink Studio に移行するには、ポンプ定義を削除し、kinesis コネクタを定義することで、これを単一の CREATE クエリに変換します。Zeppelin ノートブックの最初の段落では、テーブルとして提示されるコネクタをセットアップします。受信メッセージのすべての項目、またはそのサブセットに対して列を定義できます。 クエリを実行すると、ノートブックに成功結果が出力されます。これで SQL を使用してこのテーブルにクエリを実行したり、PyFlink や Scala を使用してこのデータにプログラムによる操作を実行したりできます。 ストリーミングデータにリアルタイム分析を実行する前に、データが現在どのようにフォーマットされているかを見てみましょう。これを行うには、作成したテーブルに対して簡単な Flink SQL クエリを実行します。ストリーミングアプリケーションで使用される SQL は、SQL アプリケーションで使用されるものと同じです。 数秒後にレコードが表示されない場合は、IoT Device Simulator がまだ実行中であることを確認してください。 Kinesis Data Analytics for SQL コードも実行している場合、結果セットが若干異なる場合があります。これは Amazon Managed Service for Apache Flink のもう一つの重要な違いです。後者には exactly once 配信の概念があるためです。このアプリケーションが本番環境にデプロイされ、再起動されたり、スケーリングアクションが発生したりした場合、Amazon Managed Service for Apache Flink は各メッセージを一度だけ受信することを保証します。一方、Kinesis Data Analytics for SQL アプリケーションでは、結果に影響を与える可能性のある重複メッセージを無視するために、受信ストリームをさらに処理する必要があります。 一時停止アイコンを選択して、現在の段落を停止できます。クエリを停止すると、ノートブックにエラーが表示される場合がありますが、無視して構いません。プロセスがキャンセルされたことを知らせているだけです。 Flink SQL は SQL 標準を実装しており、データベーステーブルをクエリする場合と同じように、ストリームデータに対して簡単に計算を実行する方法を提供します。データのエンリッチにおける一般的なタスクとしては、計算または変換 (華氏から摂氏への変換など)結果を保存するための新規フィールドの作成、下流のクエリの簡素化、可視化を改善するための新規データ作成等が挙げられます。次の段落を実行して、センサーの読み取り時に自動車が加速中であったかどうかを簡単に知ることができる、accelerating という名前の新しい Boolean 値を追加する方法を見てみましょう。このプロセスは、Kinesis Data Analytics for SQL と Amazon Managed Service for Apache Flink の間で違いはありません。 新しい列を検査し、新しい Boolean 値を FLOAT acceleration 列と比較したら、段落の実行を停止できます。 センサーから送信されるデータは通常、レイテンシーとパフォーマンスを向上させるためにコンパクトです。外部データでデータストリームをエンリッチすること、例えば追加の車両情報や現在の気象データなどでストリームをエンリッチすることは非常に有用です。この例では、現在 Amazon S3 に保存されている CSV からデータを取り込み、現在のエンジン速度帯を反映する color という名前の列を追加したいと仮定しましょう。 Apache Flink SQL は、AWS サービスやその他のソース用のいくつかのソース コネクタ を提供しています。最初の段落で行ったように新しいテーブルを作成し、代わりに filesystem コネクタを使用することで、Flink が Amazon S3 に直接接続してソースデータを読み取ることができます。以前の Kinesis Data Analytics for SQL アプリケーションでは、新しい参照をインラインで追加することはできませんでした。代わりに、 S3 参照データを定義 し、アプリケーション設定に追加して、SQL JOIN で参照として使用できました。 注意: us-east-1 リージョンを使用していない場合は、 csv をダウンロード して独自の S3 バケットにオブジェクトを配置できます。csv ファイルを s3a:/// として参照してください。 最後のクエリを基に、次の段落では現在のデータと新しく作成したルックアップソーステーブルに対して SQL JOIN を実行します。 エンリッチされたデータを再度ストリーミングします。実際のシナリオでは、データの扱い方に多くの選択肢があります。例えば、S3 データレイクにデータを送信したり、さらなる分析のために別の Kinesis データストリームに送信したり、可視化のために OpenSearch Service にデータを保存したりすることができます。簡単にするために、データを Amazon Data Firehose に送信し、データレイクとして機能する S3 バケットにデータをストリーミングします。 Amazon Data Firehose は、わずか数クリックで Amazon S3、OpenSearch Service、 Amazon Redshift データウェアハウス、および Splunk にデータをストリーミングできます。 Amazon Data Firehose ストリームの作成 Firehose ストリームを作成するには、以下の手順を実行します： Amazon Data Firehose コンソールで、「Create delivery stream」を選択します。 ストリームソースとして「Direct PUT」を選択し、ターゲットとして「Amazon S3」を選択します。 配信ストリームに “automotive-firehose” という名前を付けます。 「Destination settings」で、新しいバケットを作成するか、既存のバケットを使用します。 S3 バケットの URL をメモしておきます。 「Create delivery stream」を選択します。 ストリームの作成には数秒かかります。 Amazon Managed Service for Apache Flink コンソールに戻り、「Streaming applications」を選択します。 「Studio」タブで、Studio ノートブックを選択します。 「IAM role」の下にあるリンクを選択します。 IAM ウィンドウで、「Add permissions」を選択し、「Attach policies」を選択します。 「AmazonKinesisFullAccess」と「CloudWatchFullAccess」を検索して選択し、「Attach policy」を選択します。 Zeppelin ノートブックに戻ることができます。 Amazon Data Firehose へのデータのストリーミング Apache Flink v1.15 以降、Firehose ストリームへのコネクタの作成は、任意の Kinesis Data Streams へのコネクタの作成と同様に機能します。2つの違いがあることに注意してください。コネクタは firehose で、stream 属性は delivery-stream になります。 コネクタ作成後は、SQL テーブルのようにデータを書き込むことができます。 Firehose ストリームを通じてデータが取得されていることを確認するには、Amazon S3 コンソールを開き、ファイルが作成されていることを確認します。ファイルを開いて新しいデータを検査します。 Kinesis Data Analytics for SQL アプリケーションでは、SQL アプリケーションダッシュボードで新しい宛先を作成していました。既存の宛先を移行するには、新しい宛先を定義する SQL クエリをノートブックに追加します。新しいテーブル名を参照しながら、INSERT を使用して新しい宛先に書き込み続けることができます。 時系列データ Amazon Managed Service for Apache Flink Studio ノートブックで実行できるもう一つの一般的な操作は、タイムウィンドウ(一定の期間)にわたる集計です。このようなデータは、異常を特定したり、アラートを送信したり、さらに処理するために保存したりするために、別の Kinesis Data Streams に送信できます。次の段落には、タンブリングウィンドウを使用し、30 秒間隔で自動車フリートの総燃料消費量を集計する SQL クエリが含まれています。最後の例と同様に、別のデータストリームに接続してこのデータを挿入し、さらに分析することができます。 Scala と PyFlink データストリームに対して実行する関数は、単純さとメンテナンス性の両方の観点から、SQL よりもプログラミング言語で書く方が簡単な場合があります。例として、SQL 関数がネイティブにサポートしていない複雑な計算、特定の文字列操作、データの複数のストリームへの分割、他の AWS サービス(テキスト翻訳や感情分析など)との連携などが挙げられます。Amazon Managed Service for Apache Flink は、Zeppelin ノートブック内で複数の Flink インタープリター を使用する機能を持っています。これは Kinesis Data Analytics for SQL アプリケーションにはない機能です。 データに注意深く目を通していれば、location フィールドが JSON 文字列であることに気付いたでしょう。Kinesis Data Analytics for SQL では、文字列関数を使用して SQL 関数 を定義し、JSON 文字列を分解することができました。これは、メッセージデータの安定性に依存する脆弱なアプローチですが、いくつかの SQL 関数を使用して改善することができます。Kinesis Data Analytics for SQL で関数を作成する構文は以下のパターンに従います。 CREATE FUNCTION ''<function_name>'' ( ''<parameter_list>'' ) RETURNS ''<data type>'' LANGUAGE SQL [ SPECIFIC ''<specific_function_name>'' | [NOT] DETERMINISTIC ] CONTAINS SQL [ READS SQL DATA ] [ MODIFIES SQL DATA ] [ RETURNS NULL ON NULL INPUT | CALLED ON NULL INPUT ] RETURN ''<SQL-defined function body>'' Amazon Managed Service for Apache Flink でも最近利用可能となった Apache Flink v1.15 では、Apache Flink SQL のテーブル SQL に JSON Path 構文に似た JSON 関数 を追加しました。これにより、SQL 内で直接 JSON 文字列にクエリを実行できます。以下のコードをご覧ください。 %flink.ssql(type=update) SELECT JSON_STRING(location, '$.latitude) AS latitude, JSON_STRING(location, '$.longitude) AS longitude FROM my_table あるいは、Apache Flink v1.15 以前の方法である、ノートブック内で Scala または PyFlink を使用してフィールドを変換し、データを再ストリーミングすることもできます。両言語とも、堅牢な JSON 文字列処理を提供します。 以下の PyFlink コードは、メッセージの location フィールドから緯度と経度を抽出する 2 つの ユーザー定義関数 を定義します。これらの UDF は、その後 Flink SQL から呼び出すことができます。環境変数 st_env を参照しています。PyFlink は Zeppelin ノートブック内で 6 つの変数 を作成します。Zeppelin は、変数 z として コンテキスト も公開しています。 メッセージに予期しないデータが含まれている場合、エラーが発生する可能性もあります。Kinesis Data Analytics for SQL アプリケーションは、アプリケーション内エラーストリームを提供します。これらのエラーは別途処理され、再ストリーミングされるか削除されます。Kinesis Data Analytics ストリーミングアプリケーションの PyFlink では、複雑なエラー処理戦略を書き、即座に回復してデータの処理を続けることができます。JSON 文字列が UDF に渡される際、それは不正な形式であったり、不完全であったり、空であったりする可能性があります。UDF 内でエラーをキャッチすることで、エラーが発生した場合でも Python は処理を継続し、値を返すことができます。 以下のサンプルコードは、2 つのフィールドに対して除算計算を実行する別の PyFlink スニペットを示しています。ゼロ除算エラーが発生した場合、デフォルト値を提供してストリームがメッセージの処理を続行できるようにします。 %flink.pyflink @udf(input_types=[DataTypes.BIGINT()], result_type=DataTypes.BIGINT()) def DivideByZero(price): try: price / 0 except: return -1 st_env.register_function("DivideByZero", DivideByZero) 次のステップ この記事で行ったようなパイプラインの構築は、AWS の追加サービスをテストするための基礎を提供します。ストリームを削除する前に、ストリーミング分析の学習を続けることをお勧めします。以下を検討してください。 Amazon Managed Service for Apache Flink Studio ノートブックを 永続的な状態を持つアプリケーション として公開する。 Kinesis Data Firehose 配信ストリームを使用して OpenSearch Service に直接書き込む。 OpenSearch Dashboards を使用してストリーミングデータを可視化する。 一般的な SQL ベースの Kinesis Data Analytics アプリケーションから Amazon Managed Service for Apache Flink Studio へのクエリ書き換えの例について、 Migrating to Amazon Managed Service for Apache Flink: Examples ドキュメントを確認する。 クリーンアップ この演習で作成したサービスをクリーンアップするには、以下の手順を実行します。 CloudFormation コンソールに移動し、IoT Device Simulator スタックを削除します。 AWS IoT Core コンソールで、「Message Routing」と「Rules」を選択し、ルール “automotive_route_kinesis” を削除します。 Kinesis Data Stream コンソールで Kinesis データストリーム “automotive-data” を削除します。 IAM コンソールで IAM ロール “automotive-role” を削除します。 AWS Glue コンソールで、”automotive-notebook-glue” データベースを削除します。 Amazon Managed Service for Apache Flink Studio ノートブック “automotive-data-notebook” を削除します。 Firehose 配信ストリーム “automotive-firehose” を削除します。 まとめ Amazon Managed Service for Apache Flink Studio に関するこのチュートリアルをご覧いただきありがとうございます。現在、レガシーの Amazon Managed Service for Apache Flink Studio SQL アプリケーションを使用している場合は、AWS テクニカルアカウントマネージャーまたはソリューションアーキテクトに連絡し、Amazon Managed Service for Apache Flink Studio への移行について相談することをお勧めします。 Amazon Kinesis Data Streams Developer Guide で学習を続け、 GitHub でコードサンプルにアクセスできます。 著者について Nicholas Tunney は、AWS のワールドワイドパブリックセクターパートナーソリューションアーキテクトです。彼はグローバル SI パートナーと協力して、政府、非営利の医療、公益事業、教育部門のクライアント向けに AWS におけるアーキテクチャの開発を行っています。

10 月 15 日、 Amazon Aurora PostgreSQL 互換エディション および Amazon DynamoDB の Amazon Redshift とのゼロ ETL 統合の一般提供の開始を発表できたことを喜ばしく思います。ゼロ ETL 統合により、トランザクションデータまたは運用データが Amazon Redshift でシームレスに利用できるようになるため、抽出、変換、ロード (ETL) オペレーションを実行する複雑なデータパイプラインを構築して管理する必要がなくなります。ソースデータの Amazon Redshift へのレプリケーションが自動化され、同時にソースデータが更新されるため、Amazon Redshift の分析や機械学習 (ML) 機能で利用して、タイムリーなインサイトを導き出し、時間が重要な要素となる重大なイベントに効果的に対応できます。 これらの新しいゼロ ETL 統合を使用すると、さまざまなデータパイプラインを構築して管理することなく、さまざまなアプリケーションのデータに対して統合分析を実行し、複数のリレーショナルおよび非リレーショナルデータソースから単一のデータウェアハウスにデータを書き込むことができます。この記事では、Amazon Aurora PostgreSQL と Amazon DynamoDB の Amazon Redshift とのゼロ ETL 統合の両方を開始する方法について、2 つのステップバイステップのウォークスルーを提供します。 ゼロ ETL 統合を作成するには、ソースを指定し、Amazon Redshift をターゲットとして指定します。統合により、ソースからターゲットデータウェアハウスにデータがレプリケートされ、Amazon Redshift でシームレスに利用できるようになり、パイプラインの状態がモニタリングされます。 これらの新しい統合がどのように機能するかを見てみましょう。この記事では、ゼロ ETL 統合を作成して、異なるソースデータベース (Aurora PostgreSQL と DynamoDB) から同じ Amazon Redshift クラスターにデータをレプリケートする方法を学びます。また、Aurora PostgreSQL ソースデータベースから複数のテーブルまたはデータベースを選択して、同じ Amazon Redshift クラスターにデータをレプリケートする方法も学びます。ゼロ ETL 統合が、複数の ETL パイプラインを構築および管理する運用上の負担なしでどのように柔軟性を提供するのかを見ていきます。 Aurora PostgreSQL の Amazon Redshift とのゼロ ETL 統合の開始方法 データベースを作成する前に、カスタムクラスターパラメータグループを作成します。これは、Aurora PostgreSQL の Amazon Redshift とのゼロ ETL 統合では、 Aurora DB クラスターパラメータ に特定の値が必要になるためです。 Amazon RDS コンソール のナビゲーションペインから、 [パラメータグループ] に移動します。 [パラメータグループを作成] を選択します。 [パラメータグループ名] と [説明] で、 custom-pg-aurora-postgres-zero-etl と入力します。 [エンジンタイプ] で [Aurora PostgreSQL] を選択し、 [パラメータグループファミリー] で [aurora-postgresql16] を選択します (ゼロ ETL 統合は PostgreSQL 16.4 以降のバージョンで機能します)。最後に、 [タイプ] で [DB クラスターパラメータグループ] を選択し、 [作成] を選択します。 次に、 [パラメータグループ] ページで新しく作成したクラスターパラメータグループを選択して編集します。 [アクション] を選択し、 [編集] を選択します。次のクラスターパラメータ設定を行います。 rds.logical_replication=1 aurora.enhanced_logical_replication=1 aurora.logical_replication_backup=0 aurora.logical_replication_globaldb=0 [変更を保存] を選択します。 次に、 [Aurora PostgreSQL データベース] を作成します。データベースを作成する際に、必要に応じて構成を設定できます。 [使用可能なバージョン] から [Aurora PostgreSQL (PostgreSQL 16.4 以降と互換性あり)] を選択し、 [追加設定] セクションの [DB クラスターパラメータグループ] で、カスタムクラスターパラメータグループ (今回は [custom-pg-aurora-postgres-zero-etl] ) を選択します。 データベースが使用可能になったら、Aurora PostgreSQL クラスターに接続して、 books という名前のデータベースを作成し、このデータベースのデフォルトスキーマに book_catalog という名前のテーブルを作成して、ゼロ ETL 統合で使用するサンプルデータを挿入します。 ゼロ ETL 統合の使用を開始するために、私は既存の Amazon Redshift データウェアハウスを使用します。Amazon Redshift リソースを作成および管理するには、「 Amazon Redshift 開始方法ガイド 」にアクセスしてください。 Amazon RDS コンソールのナビゲーションペインから [ゼロ ETL 統合] タブに移動し、 [ゼロ ETL 統合を作成] を選択します。 [統合識別子] で postgres-redshift-zero-etl と入力し、 [統合の説明] で Amazon Aurora zero-ETL integration with Amazon Redshift と入力します。 [次へ] を選択します。 次のページで、 [RDS データベースを参照] を選択してソースデータベースを選択します。 [データフィルタリングオプション] で、 database.schema.table パターンを使用します。Aurora PostgreSQL books データベースに、 book_catalog というテーブルを含めます。フィルターに * を含めると、 books データベース内のすべてのスキーマのすべての book_catalog テーブルがレプリケートされます。フィルタータイプとして [含める] を選択し、 [フィルター式] フィールドに books.*.book_catalog と入力します。 [次へ] を選択します。 次のページで、 [Redshift データウェアハウスを参照] を選択し、既存の Amazon Redshift データウェアハウスをターゲットとして選択します。Amazon Aurora がデータウェアハウスにレプリケートできるようにし、大文字と小文字の区別を有効にするには、ターゲットで認可されたプリンシパルと統合ソースを指定する必要があります。Amazon RDS はセットアップ中にこれらのステップを完了できますが、Amazon Redshift で手動で設定することもできます。このデモでは、 [修正する] を選択し、 [次へ] を選択します。 大文字と小文字の区別のパラメータとデータウェアハウスのリソースポリシーを修正したら、次の [タグと暗号化を追加] ページで [次へ] を選択します。設定を確認したら、 [ゼロ ETL 統合を作成] を選択します。 統合が成功したら、統合名を選択して詳細を確認します。 ここで、統合からデータベースを作成してセットアップを完了する必要があります。 Amazon Redshift コンソール に移動し、ナビゲーションペインで [ゼロ ETL 統合] を選択して、作成した Aurora PostgreSQL 統合を選択します。 [統合からデータベースを作成] を選択します。 [ソース名データベース] として books を選択し、 [宛先データベース名] として zeroetl_aurorapg と入力します。 [データベースを作成] を選択します。 データベースが作成されたら、[Aurora PostgreSQL 統合] ページに戻ります。このページで、 [データをクエリ] を選択して Amazon Redshift データウェアハウスに接続し、データがレプリケートされているかどうかを確認します。 zeroetl_aurorapg データベースで選択クエリを実行すると、 book_catalog テーブルのデータが正常に Amazon Redshift にレプリケートされていることがわかります。 冒頭で述べたように、Aurora PostgreSQL ソースデータベースから複数のテーブルまたはデータベースを選択して、同じ Amazon Redshift クラスターにデータをレプリケートできます。同じゼロ ETL 統合に別のデータベースを追加するために必要なのは、 [データフィルタリングオプション] に database.schema.table の形式で別のフィルターを追加し、データベース部分を、レプリケートするデータベース名に置き換えることだけです。このデモでは、同じデータウェアハウスにレプリケートする複数のテーブルを選択します。Aurora PostgreSQL クラスターに publisher という名前の別のテーブルを作成し、サンプルデータを挿入します。 レプリケーションのためにパブリッシャーテーブルを含めるように [データフィルタリングオプション] を編集します。これを実行するために、 postgres-redshift-zero-etl の詳細ページに移動し、 [変更] を選択します。 [フィルター式] フィールドに、カンマを使用して books.*.publisher を付加します。 [続行] を選択します。変更内容を確認し、 [変更を保存] を選択します。統合の詳細ページの [フィルタリングされたデータテーブル] セクションに、レプリケーションのために 2 つのテーブルが含まれていることがわかります。 Amazon Redshift クエリエディタに切り替えてテーブルを更新すると、新しい publisher テーブルとそのレコードがデータウェアハウスにレプリケートされていることがわかります。 Aurora PostgreSQL の Amazon Redshift とのゼロ ETL 統合が完了したので、DynamoDB の同じデータウェアハウスとのゼロ ETL 統合を作成しましょう。 DynamoDB の Amazon Redshift とのゼロ ETL 統合の開始方法 この部分では、 Book_Catalog という名前の既存の Amazon DynamoDB テーブルを使用して、Amazon DynamoDB ゼロ ETL 統合を作成します。テーブルには 2 つの項目があります。 Amazon Redshift コンソール に移動し、ナビゲーションペインで [ゼロ ETL 統合] を選択します。その後、 [ゼロ ETL 統合を作成] の横にある矢印を選択し、 [DynamoDB 統合を作成] を選択します。 [統合名] で dynamodb-redshift-zero-etl と入力し、 [説明] で Amazon DynamoDB zero-ETL integration with Amazon Redshift と入力します。 [次へ] を選択します。 次のページで、 [DynamoDB テーブルを参照] を選択し、 Book_Catalog テーブルを選択します。統合を作成する前に、認可されたプリンシパルと統合ソースを含むリソースポリシーを指定し、ソーステーブルでポイントインタイムリカバリ (PITR) を有効にする必要があります。Amazon DynamoDB で自動的に実行することも、手動で設定を変更することもできます。統合に必要なリソースポリシーを自動的に適用し、DynamoDB テーブルで PITR を有効にするには、 [修正する] を選択します。 [次へ] を選択します。 その後、既存の Amazon Redshift Serverless データウェアハウスをターゲットとして選択し、 [次へ] を選択します。 [タグと暗号化を追加] ページで、もう一度 [次へ] を選択し、 [確認および作成] ページ で [DynamoDB 統合を作成] を選択します。 ここで、Aurora PostgreSQL ゼロ ETL 統合の場合に実行したのと同じように、統合からデータベースを作成してセットアップを完了する必要があります。Amazon Redshift コンソールで、DynamoDB 統合を選択し、 [統合からデータベースを作成] を選択します。ポップアップ画面で、 [宛先データベース名] として zeroetl_dynamodb と入力し、 [データベースを作成] を選択します。 データベースが作成されたら、Amazon Redshift の [ゼロ ETL 統合] ページに移動し、作成した DynamoDB 統合を選択します。このページで、 [データをクエリ] を選択して Amazon Redshift データウェアハウスに接続し、DynamoDB Book_Catalog テーブルからのデータがレプリケートされているかどうかを確認します。 zeroetl_dynamodb データベースで選択クエリを実行すると、データが Amazon Redshift に正常にレプリケートされていることがわかります。DynamoDB からのデータは [SUPER データ型] 列にレプリケートされており、 PartiQL sql を使用してアクセスできることに留意してください。 DynamoDB Book_Catalog テーブルに別のエントリを挿入します。 Amazon Redshift クエリエディタに切り替えて選択クエリを更新すると、新しいレコードがデータウェアハウスにレプリケートされていることがわかります。 Aurora PostgreSQL および DynamoDB と Amazon Redshift 間のゼロ ETL 統合は、複数のデータベースクラスターからのデータを統合し、データウェアハウスでインサイトを得るのに役立ちます。Amazon Redshift では、複数のテーブルに基づくクロスデータベースクエリとマテリアライズドビューを使用できるため、分析アセットを統合して簡素化し、運用効率を高め、コストを最適化する機会を得ることができます。複雑な ETL パイプラインの設定と管理について心配する必要がなくなりました。 今すぐご利用いただけます Aurora PostgreSQL の Amazon Redshift とのゼロ ETL 統合は、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム) の AWS リージョンでご利用いただけるようになりました。 Amazon DynamoDB の Amazon Redshift とのゼロ ETL 統合は、すべての商用、中国、GovCloud の AWS リージョンでご利用いただけるようになりました。 料金に関する情報については、 Amazon Aurora および Amazon DynamoDB の料金ページにアクセスしてください。 この機能の使用を開始するには、「 Amazon Redshift との Aurora ゼロ ETL 統合での作業 」および「 Amazon Redshift ゼロ ETL 統合 」のドキュメントをご覧ください。 – Esra 原文は こちら です。

10 月 7 日週、AWS は ロンドン と パリ で半日の無料会議を開催しました。同僚と私は、デベロッパーが生成 AI ツールを使用して設計、分析、コード作成、デバッグ、デプロイのワークフローをスピードアップする方法を実演しました。イベントは GenAI Lofts で開催されました。これらのロフトは、10 月 25 日 (ロンドン) と 11 月 5 日 (パリ) まで営業しています。イベント、会議、ワークショップ、会合などが盛りだくさんです。参加される場合は、必ずアジェンダ ( ロンドン 、 パリ ) をご確認ください。 有名な AWS ニュースブログの共著者である Veliswa が素晴らしいデモを行いました。彼女は Amazon Q Developer からの提案やレビューのみを使用して、 Duolingo のようなアプリケーション をゼロからライブコーディングしました。 それでは、先週の AWS に関するその他のエキサイティングなニュースを見てみましょう。 10 月 7 日週のリリース 私が注目したいくつかのリリースをご紹介します。 WhatsApp で会話しよう – AWS は、WhatsApp のサポートに AWS End User Messaging を追加しました。これにより、デベロッパーはマルチメディアやインタラクティブなメッセージングオプションを使用して WhatsApp のユーザーにリーチできます。この機能は、既に利用できる SMS やプッシュ通知と統合されています。デベロッパーは AWS マネジメントコンソール を使用してすぐに使い始めることができます。 データレイクテーブルによる Amazon Redshift データ共有 – これにより、さまざまな Amazon Redshift ウェアハウス間で安全で便利な方法でライブデータレイクテーブルを共有できます。 AWS Glue データカタログ のデータレイクテーブルのデータ共有により、データへのライブアクセスが可能になるため、データレイクで更新されるたびに、常に最新かつ一貫性のある情報を確認できます。 ゾーン間 Network Load Balancer 向けのゾーンシフトとゾーンオートシフト – Network Load Balancer (NLB) は、ゾーン間で有効化されるロードバランサーで Amazon Application Recovery Controller のゾーンシフトとゾーンオートシフト機能をサポートするようになりました。ゾーンシフトを使用すると、障害のあるアベイラビリティーゾーンからトラフィックをすばやく移動し、アプリケーションのデプロイ不良やグレー障害などのイベントから回復できます。ゾーンオートシフトは、AWS がアベイラビリティーゾーンへの潜在的な影響を特定したときに、トラフィックを安全かつ自動的にアベイラビリティーゾーンから遠ざけます。 Infrastructure as a Service (IaaS) コードを生成する Console to Code – 今週のローンチで断然お気に入りです。Console to Code を使うと、 AWS マネジメントコンソール でのプロトタイピングから本番デプロイ用のコード構築への移行を簡単、迅速、費用対効果の高い方法で行うことができます。1 回のクリックで、それぞれのコンソールアクションのコードを好みの形式で生成できます。生成されたコードは、タスク用のオートメーションパイプラインの使用を開始し、ブートストラップするのに役立ちます。Console to Code は Amazon Q Developer を利用しています。 AWS CodePipeline の新しい使用開始エクスペリエンス – AWS Data Pipeline では、シンプルで新しい使用開始エクスペリエンスが導入され、新しいパイプラインをすばやく作成できます。CodePipeline コンソールを使用して新しいパイプラインを作成する際、ビルド、オートメーション、デプロイのユースケースにわたるパイプラインテンプレートのリストから選択できるようになりました。パイプラインテンプレートを選択すると、パイプライン定義のアクション設定フィールドに値を入力するように求められます。プロセスが完了すると、完全に設定されたパイプラインがレンダリングされ、実行する準備が整います。 AWS Lambda は Lambda と Amazon S3 間の再帰ループを検出して停止 – Lambda 再帰ループ検出では、 AWS Lambda と Amazon Simple Storage Service (Amazon S3) の間の再帰ループを自動的に検出して停止できるようになりました。デフォルトで有効になっている Lambda 再帰ループ検出は、Lambda と他のサポートされているサービス間の再帰呼び出しを自動的に検出して停止し、暴走するワークロードによる意図しない使用や請求を防ぐ予防ガードレールです。 Amazon MemoryDB for Valkey – Amazon MemoryDB for Redis は、フルマネージド型の Valkey および Redis OSS 互換のデータベースサービスで、マルチ AZ の耐久性、マイクロ秒単位の読み取りと 1 桁のミリ秒単位の書き込みレイテンシー、および高スループットを提供しています。キャッシング、リーダーボード、セッションストアなどのユースケースに最適です。MemoryDB for Valkey により、AWS が提供するセキュリティ、運用上の優位性、信頼性を活用しながら、オープンソーステクノロジーに基づいて構築されたフルマネージド型のエクスペリエンスの恩恵を受けることができます。また、MemoryDB for Valkey は、AWS で人気のあるベクトルデータベースの中で、最も高いリコール率で最速のベクトル検索パフォーマンスを実現します。 Amazon Polly、生成エンジンに 4 つの新しい英語の音声を追加し、3 つのリージョンに拡張 – Polly は、テキストを本物そっくりの音声に変換するマネージドサービスです。これにより、ビジネスニーズに応じて会話をするアプリケーションを作成したり、音声対応製品を構築したりできます。生成エンジンは、最も高度な Amazon Polly テキスト読み上げ (TTS) モデルです。今回のローンチにより、Amazon Polly ポートフォリオにさまざまな新しい合成生成英語ボイスを追加しました。オーストラリア英語の音声 Olivia 一人と、米国英語の音声 Joanna、Danielle、Stephen の 3 人です。これらの音声はより自然な発音と韻律を持っています。このハイティア製品は、教育、出版、マーケティングなど、さまざまな業界やさまざまな目的に使用できます。 AWS のお知らせの詳細なリストについては、AWS の 最新情報 ページをご覧ください。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Cloud Day プラハ – 10 月 23 日にプラハで開催される無料のテクニカルカンファレンスにご参加ください。私も参加して、「基盤モデルをドメインエキスパートに変える技術」についてお話します。今すぐご登録ください。 Innovate の移行、モダナイズ、構築 – クラウドを初めて使用する方も、経験豊富なユーザーも、AWS Innovate で何か新しいことを学習できます。これは無料のオンライン会議です。 北米 (10 月 15 日) または欧州、中東、アフリカ (10 月 24 日) のうち、都合の良い時間とリージョンでご登録ください。 AWS Community Day – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されるコミュニティ主導のカンファレンスに参加しましょう。10 月 19 日に ヴァドーダラー 、 スペイン 、 グアテマラ で開催される AWS Community Day をお見逃しなく。 AWS re:Invent 2024 – 12 月 2〜6 日にラスベガスで開催される、毎年恒例のテックイベントへの登録が開始されました。 ポッドキャストのエピソード を録音する以外に、次の 3 つのセッションのプレゼンテーションを行います。 CMP410 | Accelerate testing cycles of CI/CD pipelines with EC2 Mac instances ( Vishal と共同) DEV301 | The art of transforming foundation models into domain experts ( Gregory と共同) DEV334 | Swift, server-side, serverless これら 3 つのセッションの席は残りわずかとなっています。今すぐご予約ください。 今後開催される AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 10 月 14 日週はここまでです。10 月 21 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! — seb この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

本ブログは 2024 年 5 月 30 日に公開されたBlog ” How to issue use-case bound certificates with AWS Private CA ” を翻訳したものです。 このブログでは、 AWS Private Certificate Authority (AWS Private CA) を使用して、特定の用途やユースケースに合わせた幅広い X.509 証明書を発行する方法を紹介します。これらの特定用途向け証明書は、 Key Usage や Extended Key Usage 拡張などの証明書コンポーネント内で、その想定される用途が定義されています。 IssueCertificate API オペレーションを使用して、必要な Key Usage (鍵用途) および Extended Key Usage (拡張鍵用途) の値を指定して、用途を定義する方法を説明します。 背景 AWS Private CA サービスを使用すると、AWS クラウド内に独自の公開鍵インフラストラクチャ (PKI) を構築し、組織内で使用する証明書を発行できます。AWS Private CA が発行する証明書は、 Key Usage 拡張と Extended Key Usage 拡張の両方をサポートしています。これらの拡張機能を特定の値で使用することで、作成時に特定のユースケースに証明書の使用を制限できます。SSL/TLS サーバー認証やコード署名など、証明書を意図されたユースケースに制限することで、アカウンタビリティや最小権限といった具体的なセキュリティ上の利点が得られます。 特定の Key Usage と Extended Key Usage の値で証明書の使用法を定義すると、組織が特定の証明書の目的とそのユースケースを理解するのに役立ちます。監査時に、組織は証明書の Key Usage と Extended Key Usage の値を調べて、証明書の目的と範囲を判断できます。これにより、証明書の使用に関するアカウンタビリティだけでなく、監査人や関係者に対する透明性も確保されます。さらに、これらの拡張機能を特定の値で使用することで、最小特権の原則に従うことができます。使用事例に必要な Key Usage と Extended Key Usage の値のみを定義することで、最小特権を付与できます。例えば、ある証明書が電子メール保護 (S/MIME) にのみ使用される場合、その証明書にはその Extended Key Usage の値のみを割り当てるべきです。 証明書テンプレートとユースケース AWS Private CA では、Key Usage 拡張機能と Extended Key Usage 拡張機能、およびそれらの値は、 IssueCertificate API オペレーションで渡される設定テンプレートを使用して指定されます。AWS が提供する ベーステンプレート は、SSL/TLS サーバー認証やコード署名など、最も一般的な証明書のユースケースに対応しています。しかし、ベーステンプレートで定義されていない証明書のその他のユースケースも存在します。これらのユースケースに対応する証明書を発行するには、 IssueCertificate リクエストでブランク証明書テンプレートを渡し、必要な Key Usage および Extended Key Usage の値を併せて指定することができます。 このようなユースケースには、以下のようなものがあります (ただし、これらに限りません)： SSL/TLS 用の証明書 Extended Key Usage の値が Server Authentication 、 Client Authentication 、またはその両方の証明書を発行します。 電子メール保護 (S/MIME) 用の証明書 Extended Key Usage の値が E-mail Protection の証明書を発行します。 スマートカード認証 (Microsoft スマートカードログイン) 用の証明書 Extended Key Usage の値が Smart Card Logon の証明書を発行します。 文書署名用の証明書 Extended Key Usage の値が Document Signing の証明書を発行します。 コード署名用の証明書 Extended Key Usage の値が Code Signing の証明書を発行します。 Matter 接続規格 に準拠した証明書 Matter 準拠のデバイス認証証明書 Matter 準拠の中間 CA 証明書 Matter 準拠のノード操作証明書 その他の Matter 準拠の証明書 証明書に、 AWS ドキュメント で定義されていないあまり一般的ではない Extended Key Usage の値が必要な場合、オブジェクト識別子 (OID) を渡して Extended Key Usage の値を定義することもできます。OID はドット区切りの文字列識別子で、オブジェクトや属性にマッピングされます。OID は、API での直接渡しを使用して カスタム拡張機能 で定義および渡すことができます。また、CSR (証明書署名要求) の透過的な受け渡しテンプレートを使用して、 CSR で OID を定義する こともできます。具体的なユースケースとしては以下が挙げられます： IPSec または仮想プライベートネットワーク (VPN) 関連の拡張機能を必要とする証明書 以下の Extended Key Usage の値を持つ証明書を発行します： OID: 1.3.6.1.5.5.7.3.5 (IPSEC_END_SYSTEM) OID: 1.3.6.1.5.5.7.3.6 (IPSEC_TUNNEL) OID: 1.3.6.1.5.5.7.3.7 (IPSEC_USER) モバイル運転免許証 (mDL) の ISO/IEC 標準に準拠した証明書 カスタム拡張機能を使用して、mDL DS 用に予約された ISO/IEC 18013-5 OID ： 1.0.18013.5.1.2 を含めます。 ブランク証明書テンプレートがエンドエンティティー証明書だけに限定されないことに注意することが重要です。例えば、 BlankSubordinateCACertificate_PathLen0_APICSRPassthrough テンプレートは、 Basic constraints パラメータを CA:TRUE に設定し、独自の Key Usage および Extended Key Usage 値を持つ下位認証局証明書を発行できるようにします。 ブランク証明書テンプレートの使用 AWS Private CA の 証明書テンプレート を閲覧すると、ベーステンプレートでは独自の Key Usage や Extended Key Usage の拡張機能と値を定義できないことがわかるかもしれません。これらは、最も一般的な証明書タイプの発行を簡素化するために、そのタイプの証明書で使用される拡張機能と値に事前設定されています。例えば、 EndEntityCertificate/V1 を使用する場合、常に Key Usage の値として Critical, digital signature, key encipherment 、Extended Key Usage の値として TLS web server authentication, TLS web client authentication が得られます。以下の表は、このベーステンプレートのすべての値を示しています。 EndEntityCertificate/V1 X509v3 パラメータ 値 Subject alternative name (サブジェクトの別名) [証明書署名要求 (CSR) からのパススルー ] Subject (サブジェクト) [CSR からのパススルー ] Basic constraints (基本制約) CA: FALSE Authority key identifier (認証局鍵識別子) [CA 証明書のサブジェクト鍵識別子 ] Subject key identifier (サブジェクト鍵識別子) [CSR から導出 ] Key Usage (鍵用途) Critical, digital signature, key encipherment Extended Key Usage (拡張鍵用途) TLS web server authentication, TLS web client authentication CRL distribution points (CRL 配布ポイント) [CA 設定からのパススルー ] ブランク証明書テンプレートを見ると、より高い柔軟性があることがわかります。ブランク証明書テンプレートの一例として、 BlankEndEntityCertificate_APICSRPassthrough/V1 を見ると、 EndEntityCertificate/V1 と比較して、事前定義された値が少ないことがわかります。 Extended Key Usage と Key Usage にカスタム値を設定することができます。 BlankEndEntityCertificate_APICSRPassthrough/V1 X509v3 パラメータ 値 Subject alternative name (サブジェクトの別名) [API または CSR からのパススルー ] Subject (サブジェクト) [API または CSR からのパススルー ] Basic constraints (基本制約) CA:FALSE Authority key identifier (認証局キー識別子) [CA 証明書のサブジェクトキー識別子 ] Subject key identifier (サブジェクトキー識別子) [CSR から導出 ] CRL distribution points (CRL 配布ポイント) 注意： CRL 配布ポイントは、CA が CRL 生成が有効に設定されている場合にのみテンプレートに含まれます。 [CA 設定または CSR からのパススルー ] 希望する拡張と値を指定するには、 IssueCertificate API 呼び出しで指定する必要があります。これには 2 つの方法があります： API パススルーテンプレートと CSR パススルーテンプレート です。 API パススルー (通過) – IssueCertificate パラメータの APIPassthrough で定義された拡張とその値が、発行された証明書にそのままコピーされます。 CSR パススルー (通過) – CSR で定義された拡張とその値が、発行された証明書にそのままコピーされます。 これらの値を渡す異なる方法に対応するため、3 種類のブランク証明書テンプレートがあります。CSR ファイルで指定された拡張機能のみを発行する証明書に引き継ぎたい場合は、 BlankEndEntityCertificate_CSRPassthrough/V1 テンプレートを使用できます。同様に、 APIPassthrough パラメータで指定された拡張機能のみを引き継ぎたい場合は、 BlankEndEntityCertificate_APIPassthrough/V1 テンプレートを使用できます。最後に、CSR と APIPassthrough の両方で指定された拡張機能の組み合わせを使用したい場合は、 BlankEndEntityCertificate_APICSRPassthrough/V1 テンプレートを使用できます。テンプレートを選択する際は、以下の点に注意することが重要です： テンプレートの定義は、使用するテンプレートの種類に関係なく、常に CSR で指定された値よりも高い優先順位になります。例えば、テンプレートに digital signature という Key Usage が含まれており、CSR ファイルに key encipherment が含まれている場合、証明書はテンプレート定義の digital signature になります。 API パススルー値は、API パススルーまたは APICSR パススルーテンプレートを使用する場合にのみ適用されます。CSR からの情報は、CSR パススルーまたは APICSR パススルーテンプレートを使用する場合にのみ適用されます。これらの情報源が競合する場合 (CSR と API パススルーで同じ拡張機能や値が指定されている場合)、通常、次のルールが適用されます：各拡張機能の値について、テンプレート定義が最も高い優先順位を持ち、次に API パススルー値、そして CSR パススルー拡張機能の順になります。テンプレートの処理順序について詳しくは、 AWS のドキュメント をご覧ください。 AWS CLI で特定用途向けの証明書を発行する方法 証明書の発行を行うには、適切な AWS Identity and Access Management (IAM) 権限 と、 「アクティブ」ステータスの AWS Private CA が必要です。プライベート CA がアクティブであることを確認するには、AWS Command Line Interface (CLI) から aws acm-pca list-certificate-authorities コマンドを実行します。以下のような出力が表示されます： "Status": "ACTIVE" ステータスを確認した後、プライベート CA の Amazon リソースネーム (ARN) をメモしておきます。 特定のユースケースに限定された証明書を発行するには、AWS Private CA の IssueCertificate API オペレーション を使用する必要があります。 AWS CLI では、 issue-certificate コマンドを使用してこの API を呼び出すことができます。このコマンドには、以下のようないくつかのパラメータを指定する必要があります： ( --certificate-authority-arn ) – プライベート CA の ARN。 ( --csr ) – PEM 形式の CSR。 blob として渡す必要があります (例： fileb:// )。 ( --validity ) – 証明書の「有効期限」(失効日時) ( --signing-algorithm ) – 証明書の署名に使用する署名アルゴリズム。選択する値は、プライベート CA のアルゴリズムファミリー (RSA または ECDSA) と一致する必要があります。例えば、プライベート CA が RSA_2048 を使用している場合、署名アルゴリズムは SHA256WITHRSA のような RSA方式のアルゴリズムである必要があります。 プライベート CA のアルゴリズムファミリーは、そのキーアルゴリズムを参照することで確認できます。 aws acm-pca describe-certificate-authority コマンドで、対応する KeyAlgorithm の値が表示されます。 ( --template-arn ) – ここでブランク証明書テンプレートが定義されます。テンプレートは AWS Private CA テンプレート ARN である必要があります。AWS Private CA テンプレート ARN の完全なリストは、 AWS ドキュメント に記載されています。 ここでは、ブランクのエンドエンティティ証明書テンプレートを使用して、特定のユースケースに対応したエンドエンティティ証明書を発行する方法を実演します。2 種類の異なる証明書を発行します。1 つは電子メール保護用、もう 1 つはスマートカード認証用です。電子メール保護とスマートカード認証の証明書には、ベーステンプレートでは定義されていない特定の Extended Key Usage の値があります。スマートカード認証証明書の発行には CSR パススルーを使用し、電子メール保護証明書の発行には API パススルーを使用します。 使用する証明書テンプレートは次のとおりです： CSR パススルーの場合： BlankEndEntityCertificate_CSRPassthrough/V1 API パススルーの場合： BlankEndEntityCertificate_APIPassthrough/V1 このデモに関する重要な注意点： これらのコマンドはデモ目的のみです。特定のユースケースによっては、メール保護証明書やスマートカード認証証明書は、このデモで示されているものとは異なる拡張が必要になる場合があります。 RSA 2048 秘密鍵を生成します。秘密鍵は適切かつ安全に保護し、保管する必要があります。秘密鍵の暗号化やハードウェアセキュリティモジュール (HSM) での保管などが、保護方法として挙げられます。 ここでは OpenSSL コマンドラインツールを使用します。このツールは Amazon Linux 2023 など多くのオペレーティングシステムにデフォルトでインストールされています。このツールがインストールされていない場合は、必要に応じて組織やオペレーティングシステムのソフトウェア配布システムを使用して入手できます。 API パススルーの使用 ここでは、電子メール保護に特化した証明書を発行する方法を実際に示します。Key Usage と Extended Key Usage の値を指定し、API パススルーを通じて subject alternative name (サブジェクトの別名) も指定します。これらの拡張機能と値が電子メール保護証明書に含まれるようにします。 拡張機能： X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: E-mail Protection X509v3 Subject Alternative Name: email:john_doe@example.com メール保護用の証明書の発行 以下のコマンドを使用して、OpenSSL でキーペアと CSR を作成します。OpenSSL プロンプトで識別名 (Distinguished Name) を入力してください。 openssl req \ -out csr-demo-1.csr \ -new -newkey rsa:2048 \ -nodes -keyout private-key-demo-1.pem EMAIL_PROTECTION Extended Key Usage の値、デジタル署名と鍵暗号化の Key Usage の値、および subject alternative name (サブジェクトの別名) john_doe@example.com を指定してエンドユーザー証明書を発行するには、以下のコマンドを使用します。値がメールアドレスであるため、 Rfc822Name subject alternative name タイプを使用します。 arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111 のデータを、お使いのプライベート AWS Private CA の ARN に置き換え、署名アルゴリズムをAWS Private CA で使用しているアルゴリズムに合わせて変更してください。ここでは AWS Private CA が RSA タイプであると仮定し、SHA256WITHRSA を使用しています。 aws acm-pca issue-certificate \ --certificate-authority-arn arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111 \ --csr fileb://csr-demo-1.csr \ --template-arn arn:aws:acm-pca:::template/BlankEndEntityCertificate_APIPassthrough/V1 \ --signing-algorithm "SHA256WITHRSA" \ --validity Value=365,Type="DAYS" \ --api-passthrough "Extensions={ExtendedKeyUsage=[{ExtendedKeyUsageType="EMAIL_PROTECTION"}],KeyUsage={"DigitalSignature"=true,"KeyEncipherment"=true},SubjectAlternativeNames=[{Rfc822Name="john_doe@example.com"}]}" コマンドが成功すると、発行された証明書の ARN が結果として表示されます： { "CertificateArn": "arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111/certificate/123465789123456789" } このブログの 証明書の取得 セクションに進み、 CertificateArn から証明書と証明書チェーン PEM を取得してください。 CSR パススルーの使用 ここでは、スマートカード認証用の証明書を発行する方法を説明します。 証明書署名要求 (CSR) パススルーを通じて、Key Usage 、Extended Key Usage 、subject alternative name (サブジェクトの別名)の拡張機能と値を指定します。 目標は、これらの値をスマートカード認証証明書に含めることです。 拡張機能: X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Client Authentication, Microsoft Smartcard Login X509v3 Subject Alternative Name: othername: UPN::john_doe@example.com OpenSSL を使用して、これらの特定の拡張フィールドと値をリクエストすることで CSR を生成します。 IssueCertificate を呼び出すと、CSR の内容をそのまま反映するテンプレートがリクエストされた拡張情報を認識し、発行する証明書に反映します。 スマートカード認証用の証明書の発行 以下のコマンドを使用して秘密鍵を作成します。 openssl genpkey \ -algorithm RSA \ -pkeyopt rsa_keygen_bits:2048 \ -out private-key-demo-2.pem openssl_csr.conf というファイルを作成し、識別名 (Distinguished Name) と要求された CSR 拡張を定義します。 以下は OpenSSL 設定ファイルの例です。この設定を openssl_csr.conf ファイルにコピーし、必要に応じて値を調整できます。設定に関する詳細な参考情報は、 OpenSSL ドキュメント で確認できます。 [ req ] default_bits = 2048 prompt = no default_md = sha256 req_extensions = my_req_ext distinguished_name = dn #Specify the Distinguished Name [ dn ] countryName = US stateOrProvinceName = VA localityName = Test City organizationName = Test Organization Inc organizationalUnitName = Test Organization Unit commonName = john_doe #Specify the Extensions [ my_req_ext ] keyUsage = critical, digitalSignature extendedKeyUsage = clientAuth, msSmartcardLogin #UPN OtherName OID: "1.3.6.1.4.1.311.20.2.3". Value is ASN1-encoded UTF8 string subjectAltName = otherName:msUPN;UTF8:john_doe@example.com この例では、設定の [ my_req_ext ] セクションで Key Usage と Extended Key Usage の値を指定できます。 extendedKeyUsage 行では、1.3.6.1.4.1.311.20.2.2 のような Extended Key Usage OID も定義できます。可能な値は OpenSSL ドキュメント で定義されています。 設定ファイルを指定して CSR を作成します。 openssl req -new \ -key private-key-demo-2.pem \ -out csr-demo-2.csr \ -config openssl_csr.conf (オプション) 以下のコマンドを使用して CSR をデコードし、必要な情報が含まれていることを確認できます。 openssl req -in csr-demo-2.csr -noout -text 出力には、以下のように要求された拡張とその値が表示されるはずです。 X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Client Authentication, Microsoft Smartcard Login X509v3 Subject Alternative Name: othername: UPN:: <your_user_here> issue-certificate コマンドを使用して証明書を発行します。CSR パススルー テンプレートを使用して、CSR ファイル内の要求された拡張と値が発行された証明書にコピーされるようにします。 arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111 のデータを、お使いのAWS Private CA の ARN に置き換え、署名アルゴリズムと有効期間をユースケースに合わせて調整してください。ここでは AWS Private CA が RSA タイプであると仮定して、SHA256WITHRSA を使用しています。 aws acm-pca issue-certificate \ --certificate-authority-arn arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111 \ --csr fileb://csr-demo-2.csr \ --template-arn arn:aws:acm-pca:::template/BlankEndEntityCertificate_CSRPassthrough/V1 \ --signing-algorithm "SHA256WITHRSA" \ --validity Value=365,Type="DAYS" コマンドが成功すると、発行された証明書の ARN が結果として以下のように表示されます： { "CertificateArn": "arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111/certificate/123465789123456789" } 証明書の取得 API パススルーまたは CSR パススルーで issue-certificate を使用した後、PEM 形式で証明書の内容を取得できます。 get-certificate コマンドを使用し、証明書を発行したプライベート CA の ARN と、発行された証明書の ARN をそれぞれ指定します。 aws acm-pca get-certificate \ --certificate-arn arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111/certificate/123465789123456789 \ --certificate-authority-arn arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111 \ --output text AWS CLI で --query コマンドを使用して、証明書と証明書チェーンを別々のファイルで取得できます。 証明書 aws acm-pca get-certificate \ --certificate-authority-arn arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111 \ --certificate-arn arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111/certificate/123465789123456789 \ --output text \ --query Certificate > certfile.pem 証明書チェーン aws acm-pca get-certificate \ --certificate-authority-arn arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111 \ --certificate-arn arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111/certificate/123465789123456789 \ --output text \ --query CertificateChain > certchain.pem 証明書を取得した後、openssl x509 コマンドを使用してデコードできます。これにより、定義した拡張や値を含む証明書の詳細を確認することができます。 openssl x509 -in certfile.pem -noout -text まとめ AWS Private CA では、証明書の使用方法を定義することで、アカウンタビリティと最小権限の原則というセキュリティ上の利点を実装できます。 Key Usage と Extended Key Usage の値が、証明書の使用方法を定義します。多くの証明書のユースケースでは、基本的な証明書テンプレートでは定義できない Key Usage と Extended Key Usage の組み合わせが必要です。例として、文書署名、スマートカード認証、モバイル運転免許証 (mDL) 証明書などがあります。これらの特定のユースケースに対応する証明書を発行するには、 IssueCertificate API 呼び出しと共にブランク証明書テンプレートを使用できます。ブランク証明書テンプレートに加えて、CSR パススルー機能、API パススルー機能、またはその両方を通じて、 Key Usage と Extended Key Usage の特定の組み合わせを定義する必要があります。 このブログに関する質問がある場合は、 AWS サポートにお問い合わせ ください。 AWS セキュリティに関するニュースをもっと知りたいですか？ X でフォローしてください。 Chris Morris Chris は AWS のクラウドサポートエンジニアです。暗号化やデータ保護を含む、さまざまなセキュリティトピックを専門としています。クラウドにおけるセキュリティ態勢を強化するために、AWS のお客様が AWS セキュリティサービスを効果的に使用できるよう支援することに注力しています。公開鍵基盤と鍵管理は、彼のお気に入りのセキュリティトピックの一部です。 Vishal Jakharia Vishal はアメリカのニュージャージー州を拠点とするクラウドサポートエンジニアです。セキュリティサービスに関する専門知識を持ち、複雑な問題のトラブルシューティングにお客様と協力して取り組むことを好みます。AWS クラウド上での安全でスケーラブルなアーキテクチャの移行と構築をお客様に支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

AWS は “Born from Retail, Built for Retailers” というメッセージを掲げ、Amazon で培われたノウハウをもとに流通小売消費財業界向けソリューションを提供しています。そのなかで、この業界におけるイノベーションのカギとして、「カスタマーエンゲージメント」「デジタルコマース」「インテリジェント・サプライチェーン」「マーチャンダイジング & プランニング」「スマートストア」の 5 つのテーマに取り組んでいます。 AWS を活用してサービスを提供いただいているお客様、そして世界最大級のパートナーネットワークの一員を構成する AWS パートナー各社、計 24 社が集まり、デジタルトランスフォーメーションのストーリーを共有し、「次世代小売」を形作る新しいソリューションを一挙に紹介する展示型イベント、 AWS Retail CPG Expo 2024: カスタマーエンゲージメントからスマートストアまで – 5つの戦略的イノベーションが牽引する次世代小売 を 11 月 12 日に初開催いたします。 開催によせてメッセージ： “皆様の業界課題やチャレンジを踏まえ、更なるデジタル活用での商材の企画、開発、調達から、デジタルマーケティングによる商材の訴求、オンライン／オフラインを統合した購買と高度なサプライチェーンにより、End to End での顧客体験の向上を目ざして、それぞれの領域での AWS パートナー様、ソリューションプロバイダー様のソリューションを一同にご紹介する機会を用意させて頂きました。本 Expo では各ソリューションの概要とユースケース、価値訴求ポイントを理解いただき、デモや QA 対応も兼ねた懇親の場も用意しております。皆様の奮ってのご参加をお待ち申し上げております。” – アマゾン ウェブ サービス ジャパン合同会社 エンタープライズ事業統括本部 流通・小売・消費財営業本部 本部長 黒崎 智昭 イベント概要 AWS はお客様がビルダーとしてそれぞれの課題をテクノロジーで解決するお手伝いをしています。ビルダーとは、必ずしも自らすべてを作る（ビルドする）ことを意味するものではありません。AWS は世界中に広がるパートナーネットワークを擁しており、パートナー各社がお客様の個別の課題にフォーカスする解決策＝ソリューションを展開しています。加えて AWS テクノロジーを活用してサービスを展開するユーザー企業の皆様のソリューションもあります。自社課題の解決に適したソリューションがあれば、それを活用しない手はありません。 一方で、ソリューションはあまりにたくさんあり、自分のほしいソリューションを見つけることは簡単ではありません。 そこで、流通小売消費財業界のエンタープライズビジネスのお客様に向けて、継続的に革新を続けるソリューションプロバイダーによる最先端のソリューションをご紹介する特別な機会を提供するイベントを企画することにいたしました。 ソリューションプロバイダー各社がインタラクティブなセッションで、 カスタマーエンゲージメント デジタルコマース インテリジェント・サプライチェーン マーチャンダイジング & プランニング スマートストア の 5 つの領域で、流通小売消費財業界に固有の課題と機会に応えるサービスや、ベストプラクティスをプレゼンテーションします。 ご来場のお客様が各社と直接交流いただくための懇親会も用意し、会場では各社ブースでデモを展示します。各社のソリューションをより深く理解いただく、そして各社がご来場のお客様の特定のビジネスニーズについて個別にお伺いできる機会を提供します。 2024 年 11 月 12 日 （水）13:30 – 18:30 (13:00 受付開始) 場所： AWS 目黒オフィス 目黒セントラルスクエア 21 階 ※ 事前のお申し込み が必要です。オンラインでの開催はございません。 イベントコンテンツ それではここからは 5 つのテーマごとの登壇企業様をご紹介してまいります。当日は 2 つのトラックで並行してプレゼンテーションを行います。気になるコンテンツとタイムテーブルを事前にチェックの上、ご参加いただくことをお薦めします。 カスタマーエンゲージメント カスタマー 360° によって顧客セグメントの関係性や特徴、顧客生涯価値（LTV）を理解し、CRM、顧客データプラットフォーム（CDP）、有意義な顧客対話を行うためのコンタクトセンターなど、データ主導のインサイトによるカスタマーエンゲージメントの促進に役立つソリューションをご紹介します。 登壇予定ソリューションプロバイダー（アルファベット順）： Amplitude, Inc. ソリューション： Amplitude Analytics Braze 株式会社 ソリューション： Braze 富士通株式会社 ソリューション： Personalized Marketing Services 株式会社ギークフィード ソリューション： Sylphina 株式会社ジーニー ソリューション： ジーニーマーケティングクラウド CX 株式会社 primeNumber ソリューション： TROCCO 、 COMETA クアルトリクス合同会社 ソリューション：XM for Customer Experience ティーリアムジャパン株式会社 ソリューション： Tealium Customer Data Hub トレジャーデータ株式会社 ソリューション： CDP Growth Package 株式会社ヴィンクス ソリューション：CRM システム ゼンデスク ソリューション：Zendesk Suite Advanced AI add-on デジタルコマース 生成 AI などを利用した魅力的なサイトや、俊敏なコマース基盤、顧客の望む決済手段の提供といった、デジタルコマースソリューションへの投資は不可欠です。ウェブストアから、ライブコマースや没入体験まで、デジタルコマースのイノベーションを加速し、あらゆるチャネルでカスタマーエクスペリエンスを高めるためのソリューションをご紹介します。 登壇予定ソリューションプロバイダー（アルファベット順）： 株式会社コマースニジュウイチ ソリューション： commerce21 Fireworks Japan 株式会社 ソリューション： ライブコマースパッケージ フォーター ソリューション： Forter トラストプラットフォーム ナビプラス株式会社 ソリューション： NaviPlus シリーズ 日本電気株式会社 ソリューション： NeoSarf/DM ECモデル プリズマティクス株式会社 ソリューション： prismatix ストライプジャパン株式会社 ソリューション： Stripe Payments インテリジェント・サプライチェーン サプライチェーンコントロールタワー、倉庫管理システム（WMS）などインテリジェント・サプライチェーンによって、企業内のデータサイロを解消し、高度な AI/ML アルゴリズムを実行して、サプライチェーンを革新および合理化するとともに、変化するあらゆる部分をつなげ、最適化するソリューションをご紹介します。 登壇予定ソリューションプロバイダー（アルファベット順）： 株式会社日立製作所 ソリューション： HITLUSTER o9 ソリューションズ・ジャパン株式会社 ソリューション： o9 デジタルブレイン SCSK 株式会社 ソリューション： デジタルサプライチェーンソリューション マーチャンダイジング & プランニング 需要予測の精度を向上させ、在庫水準を予測して適正に保つ、マージンを維持しつつプロモーションの効果を最大化するなど、強化された顧客洞察、需要予測、カテゴリ管理、および店舗実装を通じて、マーチャンダイジングの決定と実行を改善するためのソリューションをご紹介します。 登壇予定ソリューションプロバイダー（アルファベット順）： フューチャーアーキテクト株式会社 ソリューション： FutureApparel スマートストア 新たな顧客接点デバイスの可能性を持つ POS、小売業に新たな収益の柱をもたらすことが期待される店舗内デジタルサイネージやリテールメディアの活用といったソリューションをご紹介します。 登壇予定ソリューションプロバイダー（アルファベット順）： Hexa ソリューション：3Dモデル作成・管理ソリューション 日本電気株式会社 ソリューション： NeoSarf/POS ヨメテル株式会社 ソリューション：RFID アンテナ タイムテーブル 2024 年 11 月 12 日 （水）13:30 – 18:30  (13:00 受付開始) 場所：　AWS 目黒オフィス 目黒セントラルスクエア 21 階 13:00 開場 13:30-17:30 各社ソリューションのプレゼンテーション 17:30-18:30 懇親会 & 会場にて各社デモ展示 お申し込みは こちら から。 ※プレゼンテーションの登壇順序はイベントページに掲載しております。 セッションでは、ソリューションプロバイダー全 24 社が次々に登壇し、各 15 分で各社の最もおすすめするソリューションをご紹介していきます。 懇親会ではお食事をお楽しみいただきつつ、各社のデモブースにてご興味のあるソリューションをじっくりとデモでご覧いただき、個別にお話をしていただく時間がございます。また会場では、お客様とソリューションプロバイダーの皆様、あるいはお客様同士でも、様々なネットワーキングをお楽しみいただけるような企画もご用意しています。 この特別な機会をお見逃しなく。皆様のご参加を楽しみにお待ちしております！

こんにちは、カスタマーソリューションマネージャーの服部です。「 クラウドジャーニーの歩み方（前編） 」でクラウドジャーニーの Assess （評価）フェーズ、 Mobilize （移行準備）フェーズについてお話させていただきましたので、今回のブログでは Migration （移行）フェーズと Modernization （モダナイゼーション）フェーズにおける課題や取り組むべき活動についてご紹介していきます。 Migration（移行）フェーズ オンプレまたは他クラウドから 7R を基に移行方法を選択してAWSクラウドに移行を行うフェーズになります。 7R とはシステムを移行する際の具体的な手法のことで、 AWS では「 Relocate 」「 Rehost 」「 Replatform 」「 Repurchase 」「 Refactor 」「 Retire 」「 Retain 」の頭文字を取った「 7R 」を移行戦略として提唱しています。このフェーズで本番稼働しているアプリケーションをクラウド環境へ移行することになりますが、このフェーズでの課題と解決策については Tech 領域、 NonTech 領域それぞれこちら（ Tech課題 ／ NonTech課題 ）に詳しく記載していますのでご覧下さい。 このフェーズで行う実際の移行作業は大きく以下の３つの手順を踏んで進めていきます。 移行計画策定（具体的な移行手順） リハーサル実施 部分移行、全面移行 それぞれの手順ついて詳しく見ていきましょう。 移行計画策定 Assess フェーズ、 Mobilize フェーズで移行の前準備は整っているため、実際に移行を行うプロジェクトを立ち上げます。プロジェクトを遂行していくために「移行の体制」、「移行スケジュール」、「移行対象システム」、「移行方法( 7R )」、「コンティンジェンシープラン」、「意思決定フロー」を策定します。特に移行時に障害が発生した際にどこまでロールバックを行うのか、誰が対応を判断するかなどコンテンジェンシープランを立てておくことが重要です。計画が策定できたら移行作業を行うメンバーを招集して、移行が完了するまで定例会議を開催してメンバー間でコミュニケーションを密に取ることをお勧めします。 リハーサル実施 実際に本番移行を手順の確認をするために事前リハーサルを行います。本番移行で失敗しないために本番と同じ体制で同じ手順で実施することが重要です。ここで手順の確認だけでなく移行作業に掛かる時間を確認することで具体的な移行スケジュールを精緻に立てることができ、実際の移行でシステムを停止させる時間も確認できます。 AWS では、このリハーサルを支援することもできますので、移行の手順など本番移行に際してお悩みのお客さまは是非ご相談ください。 部分移行、全面移行 まずは影響の少ないシステムから部分移行を行うことで、ビジネスインパクトを最小限に抑えた形で移行を始められます。部分移行で手順とシステムへの影響度を確認後、対象システムを広げてリハーサルと部分移行を繰り返していき、移行計画で策定した対象システムの全面移行を完遂させていきます。 これらの手順を遂行するためには移行経験のあるメンバーのサポートが必要になりますが、 CCoE がすでに組成されている場合は CCoE メンバーの支援、組成されていない場合は AWS移行パートナー の協力を得ることで移行をスムーズに進めることができます。 Modernization（モダナイゼーション）フェーズ モダナイゼーションには 1step モダナイゼーションと 2step モダナイゼーションの主な２つのパスがあります。前者は、マイグレーションのタイミングでモダナイズも合わせて行う移行方法で、オンプレから一気にクラウドのメリットを十分に享受できる環境に移行する形です。新規にモダンな環境をクラウド上に構築する場合もこの1step モダナイゼーションの移行方法になります。クラウドスキルや移行経験がある状態でクラウドの価値を最大限活用されたいお客様はこちらを選択することをお勧めします。この移行方法の場合でも前述のマイグレーションフェーズでの実施内容は省略せずに行います。一方、後者は一度リホストを行った後にモダナイズを行う移行方法になりますので、短期間にオンプレサーバを移行されたいお客様はこちらを選択することでリスクを軽減した状態で迅速に移行ができます。クラウドスキルや移行経験がない場合でも、経営判断によって計画的に移行する場合は前者を選択することも可能です。 モダナイゼーションという言葉は、認識違いから本来の目的を見失っている状態で使われている場面が多く見受けられます。モダナイゼーションとは個別技術要素のことではなく、企業や組織が社会の変化にあわせて素早く価値を提供し続けるために組織やシステムを常に新しくしていくことを表しており、人・組織、プロセス、テクノロジーの3つの軸を組み合わせて推進する必要があります。３つの軸を組み合わせて推進するとは、開発を効率的に回すことを目的として組織体制を改善してチームに裁量を渡して自律を促すこと（人・組織）、 IT アーキテクチャだけを変更するのではなく一連の開発作業におけるボトルネックを改善する（プロセス）、最新技術を闇雲に適用しようとせずに課題を解決するための合理的な変更をすること（テクノロジー）、これらを組み合わせて現状の課題を解決していくことを示しています。 どれか1つを刷新するのではなく、組み合わせてモダナイゼーションを推進していくことをイメージしていただくことで本来の目的を見失うリスクを防ぐことができます。他には認識の違いからあれもこれもすべて刷新しようとする状況も発生しがちです。モダナイゼーションを推進するためには、どの様なビジネス効果を実現するかに応じて最適な手段を選択していくことも気を付けるポイントです。 このフェーズはワークロードのコスト最適化やコンテナ、サーバレス、 CI/CD などを適用してモダナイゼーションを行い、クラウド活用によるビジネス効果を最大化させるフェーズです。既存システムが大規模のためモダナイゼーション対象システムの選定をどのように進めていけば良いのか分からない今あるシステムを変えていくとしたらどのような技術が適切なのか分からないなど、初めてクラウド移行を行う際と同様にスキル、経験不足に起因した課題が多く発生します。 対象システムの選定の課題に対しては、 AWS ではお客さまの業務システムを様々な観点から評価・分析し、モダナイゼーションのポイントや To-Be アーキテクチャ案を提示させていただくことができます。 To-Be アーキテクチャを確認することで、対象システムのモダナイゼーション計画が立てやすくなります。 また、スキル、経験不足の課題に対しては、各種学習やハンズオンなどを実施して補うことは良いアプローチですが、最も重要なのはまずは小さく始めてみることです。 PoC や比較的影響が少ないプロジェクトを選定してパイロット移行を複数回行うことによって実体験からモダナイズのスキルや経験を積むことをお勧めします。プロジェクトメンバーの役割を問わず、実際に手を動かして初めて分かることが多いため、実際にモダナイズ経験をすることで移行計画を段階的に立案することができるようになりますし、その後の移行を加速させる効果が得られます。 まとめ ここまでで各フェーズの課題と取り組むべき活動を説明してきましたが、 AWS ではお客様に共通した課題に対して支援するプログラムを各種用意しています。この後の記事ではお客様課題と AWS が提供しているプログラムを結び付けた形で詳しくお話させていただきます。お楽しみに！ 著者プロフィール アマゾン ウェブ サービス ジャパン 合同会社 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー 服部 昌克 アマゾン ウェブ サービス ジャパン 合同会社 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー 桑原 直哉 参考リンク クラウドジャーニーの歩み方 (前編) 移行戦略（７R）の概要 MRA (移行準備状況評価) から見えるクラウド移行におけるよくある課題とその対策 (前編) MRA (移行準備状況評価) から見えるクラウド移行におけるよくある課題とその対策 (後編) AWS 移行コンピテンシーとモナダイゼーションコンピテンシーのパートナー

10 月 1 日から NICE DCV の名前が新しくなります。さようなら NICE DCV、ようこそ Amazon DCV。2024.0 リリース、および機能強化とバグ修正に伴い、NICE DCV は 10 月 1 日 Amazon DCV としてリブランドされました。 この新しい名前は、 Amazon AppStream 2.0 や Amazon WorkSpaces などの AWS マネージドサービスで活用される DCV プロトコルの一貫的な参照にも使用されることになります。 Amazon DCV とは Amazon DCV は高性能リモートディスプレイプロトコルであり、リモートデスクトップやアプリケーションストリーミングを、さまざまなネットワーク条件下で任意のクラウドまたはデータセンターから任意のデバイスにセキュアな方法で配信することができます。 Amazon Elastic Compute Cloud (Amazon EC2) で Amazon DCV を使用することにより、グラフィック集約型のアプリケーションを EC2 インスタンスでリモート実行できます。その後、結果をよりシンプルなクライアントマシンにストリーミングできるため、高価な専用ワークステーションが不要になります。 サーバー側では、Amazon DCV が Linux オペレーティングシステムの主要フレーバーと Windows オペレーティングシステムの両方をサポートすることで、組織のニーズに合わせて選択する柔軟性を提供します。デスクトップとアプリケーションストリーミングを受信するクライアント側は、Windows、Linux、macOS、またはウェブブラウザ用のネイティブ DCV クライアントにすることができます。DCV リモートサーバーと DCV クライアントは、データではなく暗号化されたピクセルのみを転送するため、DCV サーバーから機密データがダウンロードされることはありません。EC2 インスタンスを用いた Amazon Web Services (AWS) での Amazon DCV の使用を選択すると、 33 の地理的リージョンにまたがる 108 の AWS アベイラビリティーゾーンと 31 のローカルゾーン を活用できるので、リモートストリーミングサービスを世界的にスケールすることが可能になります。 8 年前に Amazon が NICE を買収 して以来、私たちはさまざまなお客様が DCV を導入するのを目の当たりにしてきました。DCV の用途は、ビジネスアプリケーションを視覚化する汎用ユーザーから業界固有の専門家まで、多岐にわたることが実証されています。例えば、アーティストは DCV を使用して、デジタルコンテンツの作成やレンダリングタスクのために強力なクラウドワークステーションにアクセスしています。ヘルスケア部門では、医療画像専門家が患者データのリモートでの視覚化と分析のために DCV を使用しています。地球科学者は DCV を使用して油層シミュレーションの結果を分析し、製造業界のエンジニアは DCV を使用して数値流体力学実験を視覚化しています。教育業界や IT サポート業界は、複数のユーザーが単一のデスクトップを共有できる DCV でのコラボレーションセッションからメリットを得ています。 注目に値するお客様には、 Quantic Dream が含まれます。受賞ゲーム開発スタジオである Quantic Dream は、そのアーティストや開発者のための低レイテンシーで高解像度のストリーミングサービスの構築に DCV を役立てています。エンタープライズリソースプランニング (ERP) サービスプロバイダーである Tally Solutions は、何千ものお客様に ERP ソフトウェアをセキュアな方法でストリーミングするために DCV を導入しました。 Volkswagen は、DCV を使用して 1,000 人を超える自動車エンジニアが CAE (Computer Aided Engineering) にリモートでアクセスできるようにしています。サービスが十分に行き届いていないコミュニティにブロードバンド接続を提供するイニシアチブである Amazon Kuiper は、複雑なチップを設計するために DCV を使用しました。 AWS 内では、お客様にマネージドソリューションを提供するために、複数のサービスが DCV を取り入れています。例えば、 AppStream 2.0 では、セキュアかつスケーラブルで信頼性に優れたアプリケーションストリーミングを提供するために DCV が使用されています。また、2020 年からは、DCV 上に構築され、高パフォーマンスのために最適化された Amazon WorkSpaces Streaming Protocol (WSP) が、Amazon WorkSpaces のお客様に提供されています。今日は、WSP という名前も廃止され、DCV に置き換えられます。今後は、Amazon WorkSpaces におけるプロトコルの主要選択肢として DCV が提供されます。 バージョン 2024.0 の新機能 Amazon DCV 2024.0 には、パフォーマンス、セキュリティ、使いやすさを向上させるためのいくつかの修正と機能強化が導入されています。2024.0 リリースでは最新の Ubuntu 24.04 LTS がサポートされるようになり、最新のセキュリティ更新と、システムメンテナンスを簡素化するための長期的な延長サポートを提供します。Ubuntu 24.04 上の DCV クライアントは Wayland をサポートするように構築されているため、グラフィカルレンダリングの効率性が向上し、アプリケーション分離が強化されます。さらに、DCV 2024.0 では QUIC UDP プロトコルがデフォルトで有効化されるようになったため、クライアントは最適化されたストリーミング体験からメリットを得ることができます。このリリースには、リモートユーザーが接続しているときに Linux のホスト画面をブランクにして、ローカルアクセスやリモートセッションとのやり取りを防ぐ機能も導入されています。 使用開始方法 DCV を試してみる最も簡単な方法は、 WorkSpaces コンソール から WorkSpaces インスタンスをスピンアップして、DCV を活用するバンドルのいずれかを選択、または AppStream セッションを作成することです。今回のデモでは、EC2 インスタンスに DCV サーバーをインストールする方法を紹介したいと思います。 Amazon EC2 上で実行されている 2 つのサーバーに DCV サーバーをインストールしました。これらのサーバーの一方は Windows Server 2022 、もう一方は Ubuntu 24.04 を実行しています。また、macOS ノートパソコンにもクライアントをインストールしました。 クライアントパッケージとサーバーパッケージは、Amazon のウェブサイトでダウンロードできます 。どちらのサーバーでも、 セキュリティグループ が UDP または TCP ポート 8443 ( DCV が使用するデフォルトポート ) でのインバウンド接続を許可していることを確認してください。 Windows でのインストールは簡単で、 msi ファイルを起動し、各ステップで Next を選択するだけです。インストールは、この文を書き終えるよりも短い時間で完了しました。 Linux でのインストールにはもう少し注意が必要です。EC2 サーバーの  Amazon マシンイメージ (AMI) には、デスクトップコンポーネントやグラフィックコンポーネントが含まれていません。前提条件として、 X Window System と ウィンドウマネージャ をインストールするとともに、ユーザーがサーバーに接続してグラフィカルユーザーインターフェイスセッションを開始できるように X を設定する必要がありました。幸い、 これらのステップはすべて詳しく説明されています 。以下は、私が使用したコマンドの要約です。 # install desktop packages $ sudo apt install ubuntu-desktop # install a desktop manager $ sudo apt install gdm3 # reboot $ sudo reboot 再起動後、DCV サーバーパッケージをインストールしました。 # Install the server $ sudo apt install ./nice-dcv-server_2024.0.17794-1_amd64.ubuntu2404.deb $ sudo apt install ./nice-xdcv_2024.0.625-1_amd64.ubuntu2404.deb # (optional) install the DCV web viewer to allow clients to connect from a web browser $ sudo apt install ./nice-dcv-web-viewer_2024.0.17794-1_amd64.ubuntu2404.deb サーバーには GPU がなかったため、 これらのステップに従って X11 Dummy ドライバーをイントールし、このドライバーを使用するように X11 を設定しました 。 次に、サービスを起動しました。 $ sudo systemctl enable dcvserver.service $ sudo systemctl start dcvserver.service $ sudo systemctl status dcvserver.service オペレーティングシステムレベルでユーザーを作成 して、パスワードとホームディレクトリを割り当てました。その後、サーバーからの接続を試みる前に、サーバー上のセットアップを確認しました。 $ sudo dcv list-sessions There are no sessions available. $ sudo dcv create-session console --type virtual --owner seb $ sudo dcv list-sessions Session: 'console' (owner:seb type:virtual) サーバー設定の準備が完了した時点で、ノートパソコンの DCV クライアントを起動しました。セッションは、サーバーの IP アドレス、およびユーザーのユーザー名とパスワードを入力するだけで開始できました。 ノートパソコンで新しい DCV クライアントウィンドウを開き、もう一方の EC2 サーバーに接続しました。数秒後、クラウドで実行されている Windows と Ubuntu マシンをリモートで操作できるようになりました。 この例では単一の EC2 インスタンスでの Amazon DCV のインストールに着目しましたが、独自のサービスインフラストラクチャを構築するときは、 Amazon DCV Session Manager 、 Amazon DCV Access Console 、および Amazon DCV Connection Gateway など、DCV サービスの一部である他のコンポーネントを検討することをお勧めします。 料金と利用可能なリージョン Amazon DCV を AWS で使用するときに料金は発生しません。EC2 インスタンス、Amazon Workspace デスクトップ、Amazon AppStream 2.0 といった AWS のリソースやサービスの使用に対する料金のみをお支払いいただきます。オンプレミスサーバーで DCV を使用する予定の場合は、 こちらのウェブサイトにあるライセンス再販業者のリスト をご覧ください。 今すぐ DCV で独自のサーバーの構築を始めましょう 。 — seb 原文は こちら です。

10 月 10 日、AWS コンソールアクションを再利用可能なコードに簡単に変換できる AWS Console-to-Code の一般提供開始 (GA) についてお知らせします。AWS Console-to-Code を使用すると、コンソールでの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの起動などのアクションとワークフローを記録することや、コンソールアクションの AWS コマンドラインインターフェイス (AWS CLI) コマンドをレビューすることができます。必要なのは数回のクリック操作だけです。 Amazon Q が AWS CloudFormation テンプレート (YAML または JSON) や AWS Cloud Development Kit (AWS CDK) (TypeScript、Python、または Java) を始めとする任意の Infrastructure-as-Code (IaC) 形式を使用してコードが生成します。これをインフラストラクチャ自動化の開始ポイントとして使用し、パイプラインなどに含まれる本番ワークロード向けにさらにカスタマイズすることができます。 昨年のプレビューの発表 以来、AWS Console-to-Code はお客様から好評を博しています。お客様からのフィードバックを基に逆算して作業を続けた結果、この GA バージョンでは機能がさらに改善されました。 GA の新機能 より多くのサービスのサポート – プレビュー中、サポートされていたサービスは Amazon EC2 だけでした。GA では、AWS Console-to-Code のサポートが拡張され、 Amazon Relational Database Service (RDS) と Amazon Virtual Private Cloud (Amazon VPC) が含まれるようになりました。 簡素化されたエクスペリエンス – 新しいユーザーエクスペリエンスでプロトタイピング、記録、コード生成のワークフローを簡単に管理できます。 コードのプレビュー – EC2 インスタンスと Auto Scaling グループの起動ウィザードが更新され、お客様は実際に作成しなくてもこれらのリソースのコードを生成できるようになりました。 高度なコード生成 – AWS CDK と CloudFormation のコード生成が Amazon Q の機械学習モデルによって強化されています。 AWS Console-to-Code の開始方法 Amazon EC2 インスタンスを起動するシンプルなシナリオから始めましょう。 Amazon EC2 コンソール にアクセスします。右側にある AWS Console-to-Code ウィジェットを見つけ、 [記録を開始] を選択して記録を開始します。 次に、Amazon EC2 コンソールのインスタンス起動ウィザードを使用して Amazon EC2 インスタンスを起動 します。インスタンスが起動したら、 [停止] を選択して記録を完了します。 [記録されたアクション] テーブルで、記録されたアクションをレビューします。 [タイプ] ドロップダウンリストを使用して、書き込みアクション ( [書き込み] ) でフィルターします。 RunInstances アクションを選択します。 [CLI をコピー] を選択して、対応する AWS CLI コマンドをコピーします。 AWS Console-to-Code から取得した CLI コマンドを以下に示します。 aws ec2 run-instances \ --image-id "ami-066784287e358dad1" \ --instance-type "t2.micro" \ --network-interfaces '{"AssociatePublicIpAddress":true,"DeviceIndex":0,"Groups":["sg-1z1c11zzz1c11zzz1"]}' \ --credit-specification '{"CpuCredits":"standard"}' \ --tag-specifications '{"ResourceType":"instance","Tags":[{"Key":"Name","Value":"c2c-demo"}]}' \ --metadata-options '{"HttpEndpoint":"enabled","HttpPutResponseHopLimit":2,"HttpTokens":"required"}' \ --private-dns-name-options '{"HostnameType":"ip-name","EnableResourceNameDnsARecord":true,"EnableResourceNameDnsAAAARecord":false}' \ --count "1" このコマンドは簡単に変更できます。この例では、タイプ t3.micro ( --instance-type ) の 2 つのインスタンス ( --count 2 ) を起動するよう更新しました。これは簡素化された例ですが、同じ手法を他のワークフローに適用できます。 AWS CloudShell を使用してコマンドを実行すると、予期したとおりに動作し、2 つの t3.micro EC2 インスタンスが起動しました。 シングルクリックの CLI コード生成エクスペリエンスは、アクションが実行されたとき (EC2 インスタンスの起動中) に使用された API コマンドに基づきます。コンソールでアクションを完了すると、コンパニオン画面に記録されたアクションが表示されます。また、開始および停止の機能を備えたインタラクティブな UI では、プロトタイピングのアクションのスコープを明確にすることが容易になります。 AWS CDK を使用した IaC 生成 AWS CDK は、クラウドインフラストラクチャをコードで定義し、AWS CloudFormation を通してプロビジョニングするためのオープンソースフレームワークです。AWS Console-to-Code を使用すると、インフラストラクチャワークフロー用の AWS CDK コード (現在は Java、Python、TypeScript) を生成できます。 EC2 起動インスタンスのユースケースを続けましょう。まだ行っていない場合は、 Amazon EC2 コンソール の右側にある AWS Console-to-Code ウィジェットを見つけ、 [記録を開始] を選択して EC2 インスタンスを起動 します。インスタンスが起動したら、 [停止] を選択して記録を完了し、 [記録されたアクション] テーブルから RunInstances アクションを選択します。 AWS CDK Python コードを生成するには、ドロップダウンリストから [CDK Python を生成] ボタンを選択します。 このコードを開始ポイントとして使用して特定のユースケース用にカスタマイズし、本番環境で使用することができます。 ここでは、既に AWS CDK がインストールされていたので、新しい Python CDK プロジェクトを作成しました。 mkdir c2c_cdk_demo cd c2c_cdk_demo cdk init app --language python 次に、生成されたコードを Python CDK プロジェクトにプラグインしました。この例では、コードが正しいことを確認するために、コードを AWS CDK Stack にリファクタリングし、EC2 インスタンスタイプを変更して、その他の小さな変更を行いました。 cdk deploy を使用して正常にデプロイすることができました。 EC2 インスタンスを起動するコンソールアクションから AWS CDK まで、同じ結果を再現することができました。 from aws_cdk import ( Stack, aws_ec2 as ec2, ) from constructs import Construct class MyProjectStack(Stack): def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None: super().__init__(scope, construct_id, **kwargs) existing_vpc = ec2.Vpc.from_lookup(self, "ExistingVPC", is_default=True ) instance = ec2.Instance(self, "Instance", instance_type=ec2.InstanceType("t3.micro"), machine_image=ec2.AmazonLinuxImage(), vpc=existing_vpc, vpc_subnets=ec2.SubnetSelection( subnet_type=ec2.SubnetType.PUBLIC ) ) CloudFormation テンプレートを YAML 形式または JSON 形式で生成することもできます。 プレビューコード AWS Console-to-Code には、Amazon EC2 の [プレビューコード] と Amazon EC2 Auto Scaling グループの起動エクスペリエンスから直接アクセスすることもできます。これは、インフラストラクチャコードを取得するために実際にリソースを作成する必要がないことを意味します。 これを試すには、 起動テンプレートを使用して Auto Scaling グループを作成 する手順に従います。ただし、 Auto Scaling グループを作成 する代わりに、 [プレビューコード] をクリックします。インフラストラクチャコードを生成するオプションまたは AWS CLI コマンドをコピーするオプションが表示されます。 知っておくべきこと AWS Console-to-Code を使用する際に考慮すべき点がいくつかあります。 AWS Console-to-Code を使用すれば、誰でもインフラストラクチャワークフロー用の AWS CLI コマンドを生成できます。AWS CDK および CloudFormation 形式のコード生成機能には、1 か月あたり 25 生成の無料クォータがあります。それ以上を使用するには、 Amazon Q Developer サブスクリプション が必要になります。 デプロイする前に、生成された IaC コードコードをテストして検証することをお勧めします。 GA では、AWS Console-to-Code は Amazon EC2、Amazon VPC、Amazon RDS コンソールのアクションのみを記録します。 AWS Console-to-Code の [記録されたアクション] テーブルには、特定のブラウザタブ内の現在のセッション中に実行されたアクションのみが表示されます。以前のセッションや他のタブのアクションは保持されません。ブラウザタブを更新すると、記録されたすべてのアクションが失われることに注意してください。 今すぐご利用いただけます AWS Console-to-Code はすべての商用リージョンでご利用いただけます。詳細については、 Amazon EC2 のドキュメンテーション を参照してください。 Amazon EC2 コンソール でお試しいただいた後、 AWS re:Post for Amazon EC2 または通常の AWS サポート窓口までフィードバックをお寄せください。 原文は こちら です。

本ブログは 株式会社メタバーズ様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの文珠です。 VR や AR といった技術がエンジニア以外の人々にも広く浸透してきた昨今ですが、みなさんは既にメタバース空間を体験されましたか？この分野では日々技術の進化を積極的に取り入れており、様々な企業がその技術を製品の宣伝やアクティビティに活用し、新たな価値を提供しております。 この分野で最近注目されているのは ”生成 AI の技術を VR / AR とどのように組み合わせるか” という観点で、チャットボットやコンテンツ生成など多方面で検討が行われています。その一方で日進月歩で進化している生成 AI の技術に対して、最新の機能に追従していくことは大変だというお客様も多いです。 本記事では株式会社メタバーズ様が VR / AR のサービスに生成 AI の技術を活用された事例を紹介します。メタバーズ様は「メタバース空間構築支援サービス」を提供しております。今回 AWS の生成 AI サービスである Amazon Bedrock をメタバース空間上の AI ボットサービスに組み込むことで、「 対応可能な生成 AI のモデル数の増加 」と「 最新モデルへの追随 」を開発工数をかけずに行えるようになりました。 メタバーズ様の状況と経緯 株式会社メタバーズ 様は、メタバース空間構築支援サービス「 メタバース® CYZY SPACE 」を提供しており、本サービスではスマートフォンや PC のウェブブラウザで利用可能なメタバース空間の構築が可能です。 本サービスで作成されたメタバース空間では、数十人から 1,000 人まで同じ空間に集まることができます。こちらの空間は、学校空間、公共施設、常設ショールーム、バーチャル展示場といった様々な用途に展開ができ、幅広い業種のお客様にご利用いただいております。 (メタバース® CYZY SPACE) 本サービスを運用するためには、各メタバース空間の中でエンドユーザーの対応をする人手が必要でしたが、メタバース空間ごとに 24 時間 365 日で実際の人間を割り当てることは費用的に難しいことでした。この課題は本サービスだけのものではなく、メタバース空間を提供するサービスの共通課題とされています。そこで、メタバーズ様は本課題を解決するために、生成 AI サービスとの連携を検証し、新規サービスを開発されました。それが AI チャットボット・アバターボット作成サービス「 メタバース® Botbird for Business 」です。 こちらのサービスを「 メタバース® CYZY SPACE 」のメタバース空間と連携させることで、AI ボットによるメタバース空間の顧客対応を実現し、人材不足解決を支援しています。 (メタバース® Botbird for Business) 本サービスを利用するお客様が増えていく中で、様々なユースケースにあわせて生成 AI モデルのバリエーションを増やすことが、お客様の満足度向上に繋がることがわかりました。しかし、 様々な種類の生成 AI モデルに対応する には、開発チームの多くの工数が必要でした。そこで、生成 AI 技術の実装箇所に Amazon Bedrock を導入することで、対応可能な生成 AI のモデル数を増加させつつ、その更新の作業もスムーズに対応できるようにしました。 ソリューション／構成内容 3D 空間サービス「 メタバース® CYZY SPACE 」の各ルームには、必要に応じて AI コンシェルジュを投入することができます。各 AI コンシェルジュはバックエンドでチャットサービスの「 メタバース® Botbird for Business 」と通信し、生成 AI によるテキストの返信を行います。 Amazon Bedrock は主に、「テキストチャット用の言語モデル」、「検索拡張生成 (RAG) 用のテキスト埋め込みモデル」の 2 つの機能で利用されています。( RAG 、埋め込みモデル、ベクトルデータベース等について、さらに学びたい方は こちらの記事 をご覧ください。 ) Amazon Bedrock を利用する際には Converse API を用いて、複数の言語モデルをシームレスに切り替えられる実装をしています。また、チャットサービス内部に組み込まれた RAG 機能では、利用者・用途ごとにベクトルデータベースを作成する必要があり、その並列化のために AWS Lambda を活用しています。実は、テキスト埋め込みモデルを利用したベクトル検索が簡単に使えるようになる以前は、類似検索のための機械学習モデルを独自に作成していました。しかし、これには高いマシンスペックのコンピュートリソースが必要であったため、AWS Fargate のスポットインスタンスをいくつも呼び出す必要がありました。今回、Amazon Bedrock 経由でテキスト埋め込みモデル ( Titan Text Embedding や Cohere Embed など ) が利用できるようになったことにより、 AWS Fargate の代わりにAWS Lambda を用いた軽量な処理に置き換えることができました。 全体として心がけているのは、マネージドサービスおよびサーバーレスサービスをできるだけ活用し、運用コストを下げるということです。少人数チームで運用しているため、自動復旧性能と可用性の高さに助けられている部分は大きいと感じています。 (出展: 株式会社メタバーズ) 導入効果 Amazon Bedrock を導入することで、下記の3つの効果を得ることができました。 利用可能な モデルラインナップが倍以上に増え 、お客様は利用用途に合わせて柔軟にモデルを切り替えることが可能に 生成 AI モデルの切り替えを少ない工数で行えるようになり、新規モデル導入時の 開発工数を約 3 日から数時間に削減 類似検索のための機械学習モデルを独自に作成する必要がなくなり、その部分の 開発コストを 90% 削減 上記の結果、メタバース空間上の AI ボットで用いる生成 AI モデルを、幅広い選択肢の中からお客様のユースケースに合わせて選択することが可能になり、お客様の満足度の向上に繋がっています。今後も新しい生成 AI モデルが登場した際には、すぐにラインナップを増やせるというのも嬉しい点ですね。 まとめ 今回はメタバース空間上の AI ボットサービスで、 AWS の生成 AI サービスである Amazon Bedrock を活用する事例を紹介させていただきました。Amazon Bedrock を用いることで「 対応可能な生成 AI のモデル数の増加 」と「 最新モデルへの追随 」を開発工数をかけずに行えるようになりました。これが幅広い業種のお客様の満足度を向上させる結果に繋がっているとのことです。本番環境で利用している生成 AI の最新化や豊富な生成 AI モデルへの対応にご関心のあるお客様は、ぜひ AWS までお問い合わせください。 株式会社メタバーズ : 代表取締役 CEO 兼社長 島谷 直芳 様 （右上）、桂 卓生 様 （右下） Amazon Web Services Japan : アカウントマネージャー 尾形 龍太郎 (左上)、ソリューションアーキテクト 文珠 啓介 (左下) ソリューションアーキテクト 文珠 啓介

2024年6月20日、21日の二日間に開催された AWS Summit Japan では、 AWS Village と称する AWS のサービスやインダストリーソリューションを扱う 90 以上の AWS 展示と、50 以上のお客様事例展示が一堂に会した展示エリアが設けられました。 今年は鉄道関連の事例とソリューション展示が行われ、お客様事例として東海旅客鉄道株式会社（以下、 JR 東海）様と東海交通機械株式会社（以下 CKK ）様から鉄道機械設備の保全における活用事例と、 AWS から AWS IoT SiteWise および Amazon Bedrock を使った鉄道機械設備のモニタリングソリューションの紹介を行いました。 本投稿では前編後編の2部構成としており、このブログでは後編として、 AWS ブースで展示した内容を紹介します。前編の JR 東海様、 CKK 様から展示いただいた模様については こちら をご参照ください。 AWS ブース AWS のブースでは「クラウドで進化する鉄道機械保守」のテーマで、鉄道機械設備のリモートメンテナンスのソリューション展示を行いました。本ソリューションは以下の2つのポイントをに分けてご紹介していきます。 ポイント1： AWS IoT SiteWise を使用した鉄道設備の大規模データ管理 ポイント2： Amazon Bedrock を使って過去の対応記録から推奨エラー対応方法を生成 本ソリューションが機械設備保守業務の効率化や高度化に取り組まれている皆様のご参考になれば幸いです。 ポイント1： AWS IoT SiteWise を使用した鉄道設備の大規模データ管理 鉄道保全の現場では、転轍機や融雪装置などの従来の鉄道機械に加えて、ホームドアやエレベーターなど様々な機械設備があります。それらの設備は路線全体に点在しており、地理的にも広大な範囲に及びます。また、日本においては生産年齢人口が減少傾向にあり、保全業務の担い手確保が難しくなってくることが予想されます。これらを背景として、鉄道保全業務の効率化・高度化の必然性は高まってきております。効率化・高度化の一つの方向性として膨大な鉄道設備データを収集しリモートで集中管理することが有効です。 AWS IoT SiteWise を利用して路線全体に広域に配置されている鉄道設備群の大規模なデータを効率的に管理・モニタリングする方法についてご紹介いたします。 AWSの構成 今回の展示では全線で9駅を対象とした設備監視システムを構築しました。58の駅構造物に分解されて、それぞれに延べ223の機会設備が配置されていることを想定しております。 AWS IoT SiteWise で各機械設備のデータを取得し、取得したデータを Grafana で可視化しております。223もの機械設備の様々なセンサーデータをどのように管理すると効率的で高度な監視を実現出来るでしょうか。データモデルに着目して述べていきたいと思います。 駅設備データ構造のモデル化 駅の構造に着目すると、駅構内にホームやコンコースがあり、ホームやコンコースには空調機やエレベータなどの設備が配置されており、各設備に温度や回転数を計測するセンサーが付随しています。設備のモニタリングを行うためには、これらのセンサーデータを収集する必要があります。この時考慮すべき事項として、同種の設備が無数にあるため、各駅を起点とした階層構造と対応付けて設備データを管理する必要があります。このように各駅を起点とした階層構造をデータモデルとして管理する仕組みが必要なのです。 AWS IoT SiteWise の アセットモデル作成機能 を利用して大量の設備を効率的に管理することができます。 アセットモデルの作成 AWS IoT Sitewise を利用して次のような流れでアセットモデルを作成しました。詳細な手順は「 産業アセットのモデル化 」を参照ください。 アセットモデルを作成 駅、駅構造物、各機械設備の3階層で計10個のアセットモデルを作成しました。 データプロパティを定義 それぞれのモデル毎のデータプロパティを定義します。今回、空調機の例のように静的なデータ（属性）や設備から取得するデータ（測定）に加えて、変換・メトリクスのプロパティタイプを利用して、監視のために必要な測定値の評価や計算を行ってます。これらのプロパティを利用することでより高度な設備監視が可能となります。 アセットの作成 アセットモデルから各機械設備等のアセットを作成します。この時にアセット間の親子関係を関連付けることができます。親アセットは間r年するアセットのデータにアクセスし集計することができます。今回、各駅をルートとして駅構造物、各機械設備を子アセットとして関連付けております。例えば、美濃大垣駅-改札外コンコース-空調機01,02といったアセットが親子関係になっております。 このように実際の駅の構成を抽象化し、アセットモデルとして定義することで、効率的に設備データを管理することができます。また、監視の要件に合わせて、取得したデータを評価・計算することにより難しい作り込みを必要とせずに簡単に高度な監視も実現することができます。 ポイント2： Amazon Bedrock を使って過去の対応記録から推奨エラー対応方法を生成 AWS IoT SiteWise を使うことの利点の一つとしてリアルタイムアラート機能があります。機器から送られてくるデータに対してあらかじめモデルで定義された閾値を越えた場合に、アラートが発砲するという機能で、この AWS IoT SiteWise アラーム機能は AWS IoT Events と連動することによって提供されています。この機能の活用によりほぼリアルタイムで機器の異常を検知し異常状態に気づくことができます。しかし実際に現場で異常が発生した際は、実は検知したあとの作業の方が労力がかかるケースがほとんどです。そこで今回の展示では、異常を検知したあとの作業に対し少しでもお手伝いできることはないかというところからアイディアを想起させて実装してみました。 実装内容（やったこと） 機器に異常が発生した場合、行う作業の一つとして過去の対応履歴や対策/対応マニュアルなどを探して確認することがあると思います。そういった業務に対し少しでも省力化につながる仕組みとして、過去の蓄積文書を元にした推奨対応策の作成を生成 AI の活用により自動生成し、異常検知の通知メールの中に AI 推奨対応策として入れ込んでメール送信を行うという仕組みを実装してみました。生成 AI のユースケースの一つである RAG ( Retrieval-Augmented Generation ) と呼ばれる検索拡張生成の仕組みをチャットから使うのではなく、エラー情報をインプットとして活用するという試みをしました。 AWSの構成と動作の詳細 構成は図のようになっており、異常が発生した場合の処理の流れは次のようになります。 センサーデータがリアルタイムで AWS IoT SiteWise に格納されます。 格納されたデータに対し設定された閾値で評価され違反しているかを判定します。今回の展示では場合は、エラーコードを検出する文字列判定、設定温度と外気温 (15分平均の温度) の温度差が5度以上かどうかの数値判定、といったものを例として仕込みました。 上記の閾値に違反し異常を検出すると AWS IoT Events によって AWS Lambda に転送されます。 AWS Lambda によってエラーコードから大枠の事象を特定しプロンプト文を作成します。 そして Amazon SQS を経由し RAG が実装された AWS Lambda に転送します。 Amazon SQS から渡されたエラー情報を元に AWS Lambda で RAG を実行します。RAG とは関連情報の検索を行い抜粋された文章を元に生成 AI が文章を作成する仕組みです。ここでは例えば、エラーコードから空調機の冷媒液の漏洩が発生という情報が Amazon SQS から渡され、「空調機の冷媒液漏洩発生時の対処方法」という文言で関連文章内を検索します。そして検索に引っかかった文章を元に LLM (Large Language Model) に「空調機の冷媒液漏洩発生時の対処方法を教えてください」と問いかけることで AI 推奨の対処方法を生成します。ちなみに今回の展示の RAG で使った LLM は Amazon Bedrock の Claude 3 Haiku で、ドキュメント検索のインデックス DB には Amazon Kendra を使いデータソースは Amazon S3 になります。 Amazon S3 に格納されているドキュメントは国土交通省、 JR 総研、日本学術振興会などが公開している PDF 文章です。 Claude 3 Haiku を選んだ背景としては、リアルタイムの異常時対応という想定のため、日本語の精度が高い Claude 3 の中でも一番レスポンスが早いということで選択しました。 最後にメールを作成します。 Amazon Bedrock の Claude 3 Haiku で出力された文章に加えて、 Amazon Kendra から出力された Amazon S3 に格納されたドキュメントを参照できるように一定時間だけ有効な署名付きURLを発行し、参考ドキュメントとしてメールに記載しています。このメールを Amazon SNS で配信します。 展示でのデモ 当日の展示では、意図的に故障データを流せる RaspberryPI (「彦原-新幹線コンコース-空調機 01 」を模擬) を用意し、そこでスクリプトを実行すると異常データが飛ぶという仕掛けを用意しました。実際に実行すると、 Grafana ダッシュボードはほぼリアルタイムで反映され異常となります。 ダッシュボード上が異常となると同時に裏側では AWS IoT Events が動き RAG が実行されております。数十秒で RAG とメール送信の処理が完了し、アラート通知と過去の対応記録から類推された AI 推奨のエラー対応方法が記載されたメールを受信します。下図は実際にその時に受信したメール画面になります。 もし発生した異常への対応方法が記載された適切なドキュメントが見当たらなければ、情報がないことを明示したメールが届きます。下図は実際に受信したメール画面になります。 このように生成 AI の課題の一つであるハルシネーション (生成 AI がユーザーの質問に対して、事実とは異なる情報を利用して回答を生成すること) を抑えることが RAG によって可能になります。 今回私たちの方には適切なドキュメント等を持っていなかったため、公開されている情報から引っ張ってきましたが、適切な自社のマニュアルや対応履歴のドキュメントがあるとより正確で役立つ情報が配信できるソリューションになると考えられます。 以上、 AWS Village の鉄道関連展示における AWS ブースで展示した内容について紹介させていただきました。 本投稿では2024年6月20日、21日の二日間に開催された AWS Summit Japan にて展示された、 東海旅客鉄道株式会社（以下、 JR 東海）様と東海交通機械株式会社（以下 CKK ）様から鉄道機械設備の保全における活用(前編) と、 AWS から AWS IoT SiteWise および Amazon Bedrock を使った鉄道機械設備のモニタリングソリューション(後編)の2つの展示内容について2部構成で紹介させていただきました。本投稿が機械設備保守業務の効率化や高度化に取り組まれている皆様のご参考になれば幸いです。 著者 技術統括本部 ソリューションアーキテクト 岩永 昌寛 カスタマーソリューションマネジメント統括本部 カスタマーソリューションマネージャー 西部 信博 技術統括本部 ソリューションアーキテクト 宮﨑 知洋

2024年6月20日、21日の二日間に開催された AWS Summit Japan では、 AWS Village と称する AWS のサービスやインダストリーソリューションを扱う 90 以上のAWS 展示と、50 以上のお客様事例展示が一堂に会した展示エリアが設けられました。 今年は鉄道関連の事例とソリューション展示が行われ、お客様事例として東海旅客鉄道株式会社（以下、 JR 東海）様と東海交通機械株式会社（以下 CKK ）様から鉄道機械設備の保全における活用事例と、 AWS から AWS IoT SiteWise および Amazon Bedrock を使った鉄道機械設備のモニタリングソリューションの紹介を行いました。 本投稿では前編後編の2部構成としており、このブログでは前編として、 JR 東海様、 CKK 様から展示いただいた模様を報告します。後編の AWS ブースで展示した内容については こちら をご参照ください。 東海旅客鉄道株式会社様/東海交通機械株式会社様 「鉄道機械」と聞いて皆様はどのような事を想像するでしょうか？ JR 東海様、CKK 様では、皆様が通勤で目にする駅の改札機やホームドアなどはもちろん、雪が舞い上がらないようにするためのスプリンクラーや、車両基地で車両を洗浄する装置など、普段目にすることが少ない機械も含めると、約21,000台の機械設備をメンテナンスされています。 また、それら鉄道機械が約2,000kmにおよぶ鉄道路線に配置されています。 労働力人口が減少していく中、広範囲に配置された多種・多量な機械を効率的にメンテナンスしていくため、 JR 東海様、 CKK 様ではデータを活用した状態監視保全と予防保全に取り組まれており、 AWS Village では「データ収集」と「データ分析」の観点で4つの活用事例が紹介されていました。また、各事例とも情報システム部などのシステム部門ではなく、日々機械メンテナンスに携わっている機械エンジニアの方がこれらのソリューションを実現されたことに、当日 AWS Village を訪れた多くの方が驚かれていたのも印象的でした。 1. 故障調査ロガー 古い設備でも IoT デバイスを活用した遠隔監視を可能にするために CKK 様が開発されたのが「故障調査ロガー」のソリューションです。 故障調査ロガーの開発コンセプトは「1. 既存設備の改良工事が不要」「2. 可搬式で様々なシチュエーションで利用可能」「3. 必要に応じてセンサーの増設が可能」「4. 遠隔地のデータを事務所で確認可能」の4点があり、これらの利点により企業は古い設備の IoT 化を実現できるようになり、対象設備の状態をリアルタイムで監視し、潜在的な問題を早期に発見することができます。これは保守作業の効率化とダウンタイムの削減につながり、結果として運用コストの削減と生産性の向上が期待できます。 故障調査ロガーは CKK 様で普段実際に鉄道機械設備メンテナンスを実施している機械エンジニアの方が、業務の合間を使って AWS IoT Core 、 AWS IoT Greengrass 、 Amazon QuickSight などのサービスを組み合わせて約3ヶ月弱で構築されました。 各種センサー（電流、温度、湿度など）から収集されたデータは、クラウド上で処理され、 Amazon QuickSight を通じて分かりやすく可視化され、機械保守員の判断を支援することができるようになっています。 2. 改札故障予測 AI データに基づく故障時期の予測によって点検回数を削減するため取り組まれたのが CKK 様の故障予測 AI システムです。 CKK 様では、稼働保守データや作業実績データなどの大量の情報を効果的に管理・活用できる環境を整え、このデータを基に機械学習プラットフォーム Amazon SageMaker を用いて、自社開発の状態監視( CBM )モデルを構築されました。この CBM モデルは教師あり学習にて開発されており、 AUC = 0.79 という高精度の予測モデルとなっています。 これらの取り組みの結果、保守コストの15.6%削減、故障対応回数を40%削減という結果が得られています。 さらに、故障の予兆を事前に検知することで、深刻な故障を未然に防ぐことも期待されています。 3. データ分析運用 ( MLOps ) 2.改札故障予測 AI で紹介したような AI モデルを他の鉄道機械に広く適用していく際、多種・多量な機器に対するモデルの開発・運用をどのように効率的に実施していけるかが課題となりました。 JR 東海様はこの課題に対し、 Amazon SageMaker 、 AWS CodeCommit 、 AWS CodePipeline 、 Amazon EventBridge などの AWS のサービスを活用した高度な MLOps 環境を構築されることで解決を図られています。この MLOps 環境によりモデルの学習から推論、管理までの一連のプロセスを自動化しました。 この MLOps の具体的適用例として、東海道新幹線の東京駅ホームドアの異常検知モデルが紹介されていました。 ホームドアを動かすモーターのトルク値を用いた教師なし機械学習モデルにおいて、時間経過や環境変化によるデータドリフトの課題に対応するため、出力データを監視し、自動で再学習を行うアルゴリズムをパイプライン上に実装しています。再学習アルゴリズムにより、正常時の異常度（移動平均）を一定に保つことが可能となりました。具体的には、再学習なしの場合と比較して、3.5年間の正常期間における誤検知回数が約1/7に減少しました。これにより、モデルの検知精度を継続的に維持し、安定した異常検知を実現されています。 4. MELS (機械保全管理システム) Cloud 保全計画管理、保全実績入力など機械設備保守の実業務を支えているのが、 MELS と名付けられた CKK 様の機械保全管理システムです。 このシステムは元々オンプレミスで稼働していましたが、システムの運用保守・セキュリティ対策の負荷が課題となっていました。これらの課題を解決するためと、既に実現していた改札故障 AI との連携を用意するため、 MELS の AWS クラウド移行を行われました。 AWS への移行後もシステムを自らで維持、発展させていくことをできるようにするため、システム移行チームは普段 MELS を使用して業務を行っている機械設備エンジニアの方で構成されました。 AWS への移行決定時はクラウド知識が全くない状態でしたが、 AWS トレーニングと AWS プロフェッショナルサービスの活用により、約1年で AWS クラウドへの移行を実現され、現在も機械設備エンジニアの方によってシステムの保守が行われているほか、機械学習モデルの取り組み、適用業務範囲の拡大も実施されているとのことです。 以上、 AWS Village の鉄道関連展示における JR 東海様と CKK 様の取り組みを紹介しました。 後編のブログでは AWS より展示した、 AWS IoT SiteWise と Amazon Bedrock を利用した鉄道機械設備モニタリングソリューション展示 について紹介します。合わせてご覧ください。 著者 技術統括本部 ソリューションアーキテクト 岩永 昌寛 カスタマーソリューションマネジメント統括本部 カスタマーソリューションマネージャー 西部 信博 技術統括本部 ソリューションアーキテクト 宮﨑 知洋

Amazon Timestream for LiveAnalytics は、高速でスケーラブルなサーバーレスの時系列データベースであり、1 日に数兆件のイベントを簡単かつコスト効率よく保存および分析できます。 様々な業界のお客様 が Amazon Timestream を採用して、重要なビジネスアプリケーションを監視し、モノのインターネット (IoT) を含むアプリケーション、ウェブサイト、デバイスにわたる数百万のリアルタイムイベントを分析し、リアルタイムの洞察を導き出しています。 Timestream は、基盤となるインフラストラクチャの管理が不要で、ワークロードの要求に合わせて自動的に拡張するため、お客様はアプリケーション開発に集中する事が出来ます。 Amazon Timestream for LiveAnalytics は、お客様からのフィードバックに応える形で、時系列データをクエリ時にコスト効率が高く、金額が予測可能となるように設計された新しい価格モデルを導入しました。以前のクエリの価格モデルは、スキャンされるデータ量に基づいて課金され、クエリ毎に最低 10 MB でしたが、クエリが数 KB 程度の比較的小さい時系列データをスキャンすることが多いユースケースでは、高額となる場合がありました。さらに、クエリへの課金に上限を設定することも困難でした。これらの懸念に対処するために、クエリによってスキャンされたデータ量ではなく、使用されたコンピューティングリソースに基づいて料金を請求する 新しい料金モデル を導入しました。 Timestream Computing Unit (TCUs) に基づくこの新しい価格モデルにより、実際に使用されるリソースに応じてコストが調整され、クエリに使用するコンピューティングリソースの最大数を設定できるため、予算の順守が容易になります。 本投稿では、TCU の概要、TCU を使用したコスト管理、および最適なコストパフォーマンスを実現するためのワークロードに必要な TCU を見積もる方法について説明します。 Timestream Compute Units (TCU) TCU は、Timestream for LiveAnalytics のクエリに割り当てられるコンピューティングの容量です。各 TCU は 4 つの vCPU と 16 GB のメモリで構成されます。時系列データをクエリすると、Timestream サービスは主にクエリ (リアルタイムクエリと分析クエリ) の複雑さと、処理されるデータ量に基づき、必要な TCU の数を決定します。各コンピューティングユニットは同時に複数のクエリを実行するため、使用中の TCU で全クエリを処理できるかどうか、または追加のコンピューティングユニットが必要かどうかを評価し、必要に応じて、コンピューティングユニットを拡張します。TCU の数とその使用期間によって関連コストが決まり、クエリワークロードの管理が透過的かつコスト効率よく行われます。 コスト管理 TCU の利点の 1 つは、クエリコストを制御し、より効率的に管理できることです。 MaxQueryTCU は、AWS リージョン毎、アカウント毎に 設定 できますが、この設定をすることで、Timestream はクエリワークロードに対してMaxQueryTCU までスケールされるように制限することができます。 TCU の最大制限を設定することで、ワークロードのコスト上限を設定できるため、予算内に収める事が容易になります。 コンピューティングユニットの最大数は 4 の倍数に設定できます。料金は、使用したコンピューティングリソースに対してのみ発生します。つまり、最大 TCU を 128 に設定しても、一貫して 8 TCU のみを使用する場合は、 8 つの TCU を使用した課金のみが発生します。従量課金制の料金設定と使用制限の構成により、高度なコストの透明性と予測可能性が提供され、クエリのコストをより適切に計画および管理できるようになります。Timestream を初めて利用する場合、各 AWS アカウントのデフォルトの MaxQueryTCU 制限は 200 になります。 MaxQueryTCU の設定は UpdateAccountSettings API を使用するか、 AWS マネジメントコンソール から行います。また、TCU を事前に見積もる方法については、本投稿の後半で詳しく説明します。 Timestream コンソールの 管理者ダッシュボード で、 管理者設定を設定 を選択します。 最大クエリ TCU に希望の値を設定し、 設定を保存 します。 現在、使用中のアカウントがクエリによってスキャンされたデータ量に対して請求が行われており、TCU にオプトインするか選択できる場合は、追加のポップアップが表示されます。 尚、最大クエリ TCU を削減する際、使用状況によっては有効になるまでに最大 24 時間かかる場合があります。また、クエリが実際に消費した TCU に対してのみ料金が請求される為、最大クエリ TCU 制限を高くしても、それらの TCU がワークロードで使用されない限り、コストには影響しません。 TCU による請求 TCU を使用すると、最低 30 秒間、使用したコンピューティングリソースに対して 1 秒毎に料金が請求されます。これらのコンピューティングユニットの使用単位は TCU 時間です。アプリケーションが Timestream にクエリを送信すると、Timestream サービスは使用中のコンピューティングユニットでリクエストを処理できるかどうかを確認します。処理出来ない場合、サービスはスケールアップして、クエリを処理するために追加のコンピューティングユニットを割り当てます。クエリの実行後、サービスは追加のクエリを最大 10 秒間待機します。この期間内に追加のクエリがない場合は、使用中のコンピューティングユニットの数をスケールダウンして、リソースを最適化し、コストを最小限に抑えます。 実際の例を使って説明しましょう。まず、アプリケーションに 1 分のうち 40 秒の間、レイテンシが 1 秒未満のクエリを含むクエリパターンがあると仮定します。アプリケーションは、1 分の開始時刻 t1 秒から t40 秒にクエリを Timestream に送信します。 コンピューティングユニットには、最低 30 秒ごとに料金が請求されます。Timestream サービスは、最小時間(30 秒)が経過し、最大 10 秒間クエリがない場合に、コンピューティング ユニットをスケールダウンします。サービスが t1 でクエリ用に 4 つの TCU を割り当て、後続のすべてのクエリが同じ 4 つの TCU で処理されると想定します。 4 つの TCU 使用量のうち 50 秒 (=0.0138889 TCU 時間)、即ち、4 * 0.01388 TCU 時間 = 0.05552 TCU 時間に対して請求されます。このパターンが 1 日 8 時間、毎分 (t1 ～ t60) 繰り返されると仮定すると、消費される合計 TCU 時間は、1 日あたり 0.05552 TCU 時間 * 60 分 * 8 時間 = 26.6496 TCU 時間となります。 TCU 時間を取得したら、目的のリージョンごとのクエリ料金を確認する事で料金を計算できます。 請求をより深く理解するために、さらにいくつかの例を見てみましょう。 ワークロードが 3 時間で 20 個の TCU を使用する場合、 60 TCU 時間 (20 TCU x 3 時間) に対して請求されます。 ワークロードが 30 分間に 12 TCU を使用し、次の 30 分間に 20 TCU を使用します。この場合、16 TCU 時間に対して請求されます (12 TCU x 0.5 時間 + 20 TCU x 0.5 時間)。 TCU の推定 Timestream for LiveAnalytics は、容量とパフォーマンスを調整するために自動的にスケーリングされるため、基盤となるインフラストラクチャの管理や容量のプロビジョニングは必要ありません。データの取り込み、ストレージ、クエリを独立して拡張できる 完全に分離されたアーキテクチャ を特徴としており、アプリケーションのニーズに合わせて事実上無限の拡張性を提供できます。 必要なコンピューティングユニットの数は、クエリの同時実行性、データモデル、クエリによってスキャンされるデータ量などのワークロードの特性によって決まります。処理可能なクエリの数を見積もるために、Timestream for LiveAnalytics でデータが収集および分析され、Grafana を通じて視覚化されるインフラストラクチャ監視のユースケースをシミュレートしました。現実世界のシナリオと同様に、複数のユーザーがメトリクスを監視する 2 つの一般的な可観測性クエリパターンをシミュレートし、ユーザーを 1 から 21 に増やしました。次に、MaxQueryTCU 設定 (4 および 8) を変更して、ユーザーの増加に応じて処理されるクエリの量とそれに対応する待ち時間を監視しました。 ホストの最新のメモリ使用率 ( lastpoint-query.ipynb ) を取得するパターン、及び、過去 10 分間の CPU 使用率をビニングする ( single-groupby-orderby.ipynb ) クエリパターンについて、4 および 8 TCU でクエリボリュームとレイテンシーメトリクスを測定しました。 これらのワークロードでは、サービスにクエリを発行する 1 人のユーザーから開始し、同時ユーザーの数を 21 人までスケールします。テストは、ユーザー構成毎に 1 分間実行され、対応するレイテンシー (p50、p90、p99)、 1 分あたりのクエリ数、およびスロットリング数 (もしあれば) が観察されます。詳細については、 README.md を参照してください。 最初のシミュレーションでは、MaxQueryTCU を 4 に設定し、 次のクエリ を実行します。これにより、特定のホストの最新のメモリ使用率が取得されます。 select memory from "devops"."sample_devops" where time > ago(10m) and hostname='host1' order by time desc limit 1 次のグラフは、レイテンシーのパーセンタイル (秒)、1 分あたりのクエリ数、およびスロットリング数とユーザー数の関係を示しています。 最初は 1 人のユーザーから始めて、時系列データにアクセスするユーザーの数を増やし続けます。わずか 4 つの TCU で、Timestream サービスは 1 分あたり 4,560 件のクエリ、つまり 1 秒あたり約 76 クエリ (QPS) を処理し、p99 レイテンシーは 160 ミリ秒未満でした。 Grafana ユーザーの数が増えると、レイテンシーが増加し、それによって 1 分あたりのクエリ数が減少しますが、スロットリングは最小限に抑えられました。これは、 デフォルトの SDK の最大再試行数が 3 (ベストプラクティス) に設定されており、SDK はスロットリングが発生する前にクエリをリトライするためです。クエリのレイテンシには再試行時間が含まれるため、同時ユーザー数が 7 名 (76 QPS) を超えると、主に複数のリトライが原因で p99 レイテンシーが増加していることがわかります。ユースケースで 1 秒未満のクエリ遅延が許容できる場合は、4 つの TCU で最大 9 人の同時ユーザーと 1 分あたり 4,853 件のクエリをサポート出来る事が分かりました。 次に、MaxQueryTCU を 8 に増やしてテストを再実行します。Timestream サービスはオンデマンドでコンピューティング ユニットを割り当てるため、サービスは 4 TCU から開始され、ワークロードが増加するにつれて追加の 4 TCU を割り当てます。次のグラフは、8 TCU のメトリクスを示しています。 8 TCU の場合、200 ミリ秒未満の p99 レイテンシーで 9,556 件のクエリ (約 159 QPS) を処理可能でした。Grafana ユーザーの数が増えると、レイテンシーが増加し (330 ミリ秒未満)、そのため 1 分あたりのクエリ数がわずかに減少しますが、スロットリングは発生しませんでした。つまり、500 ミリ秒未満のクエリ遅延がユースケースで許容できる場合は、 8 つの TCU で最大 15 人の同時ユーザーと 1 分あたり 9,556 のクエリをサポート出来る事が分かりました。 MaxQueryTCU は最大 1,000 まで増やすことができるため、ユーザーベースの拡大に合わせて拡張できます。許容できるコストに応じて、MaxQueryTCU を増やし続けることも、遅延がユースケースとして許容できる場合には、既存の TCU を使用して追加のユーザーにもサービスを提供することもできます。 次に、以下の クエリ 2 でシミュレーションを繰り返します。これは、ビン分割、グループ化、並べ替えを実行しますが、クエリ 1 と比べるとリソースを大量に消費するクエリです。 select bin(time, 1m) AS binned_time, max(cpu_utilization) as max_cpu_utilization from "devops"."sample_devops" where time > ago(10m) and hostname='host2' group by bin(time, 1m) order by binned_time asc 次のグラフは、クエリ 2 に対応するメトリクスを示しています。 前のテストと同様に、1 人のユーザーから始めて、データにアクセスするユーザーの数を増やしていきます。4 つの TCU で、180 ミリ秒の p99 レイテンシーで 6 人の同時ユーザーに対して 3,310 件のクエリ(約 55 QPS)を処理出来ました。 Grafana ユーザーの数が増加すると、主に再試行によるオーバーヘッドが原因で 1 分あたりのクエリが減少し、レイテンシーも増加します。 次のグラフは、8 つの TCU の際のメトリクスを示しています。 8 つの TCU を使用すると、500 ミリ秒未満の p99 レイテンシーで 15 人の同時ユーザーに対して 6,051 (約 100 QPS) 件のクエリをサポートできます。 必要なパフォーマンスに必要な TCU を使用できますが、少ない TCU から始めて、希望のパフォーマンス基準を満たすか、価格とパフォーマンスの適切なバランスが見つかるまで、アカウント内の MaxQueryTCU を増やすアプローチがあります。 尚、Timestream のスケジュールクエリ機能は、集計およびロールアップ操作をサポートするように設計されており、パフォーマンスを向上させるために派生テーブル (データがすでに集計されており、データ量が削減されている) からダッシュボードや視覚化用のデータを生成するのに最適です。詳細については、「 Improve query performance and reduce cost using scheduled queries in Amazon Timestream 」を参照してください。 シミュレーションで実証されたように、4 つの TCU は 76 QPS (月間 1 億 9,900 万クエリに相当) および 55 QPS (月間 1 億 4,300 万クエリに相当) のクエリ量をサポート可能でしたが、クエリの複雑さに依存する為、シミュレーションで示されているよりも多くなる可能性があります。また、TCU はクエリ数ではなくコンピューティング使用時間に基づいて課金されるため、76 QPS と 55 QPS の費用は変わりません。クエリの同時実行の利点を最大限に高めるには、 データモデル、クエリ、ワークロードを最適化 してコンピューティングリソースを効果的に利用することが不可欠です。これにより、コストが削減され、クエリのスループットが向上し、リソースの使用率が向上します。 AWS Pricing Calculator を使用したコストの見積もり AWS Pricing Calculator を使用して、Timestream for LiveAnalytics の月額コストを見積もることができます。このセクションでは、リアルタイムクエリと分析クエリとみなされるものについての一般的なガイダンスを提供します。 リアルタイムクエリ – 小さなウィンドウ (5 分や 15 分などの数分) 内で メジャー を分析するクエリ、または通常は数百のレコードをスキャンするクエリ。 分析クエリ – 大きな時間範囲 (12 時間、日、月等) にわたってメジャーを分析するクエリ。複雑な結合やサブクエリが含まれる場合があり、通常は数千のレコードをスキャンします。これらのクエリでは、パフォーマンスを向上させるためにデータの集約とセグメント化に高いコンピューティング (CPU/メモリ) が必要です。 これは一般的なガイダンスです。小さなウィンドウ内で補間、導出、またはその他の複雑な関数を要求するような、リアルタイムクエリとして認められない可能性のあるコストのかかるクエリが存在する可能性があります。 わかりやすくするために、料金計算では、1 秒あたり 7 つの同時クエリが 4 つの TCU で 1 秒のレイテンシーで処理されると想定しています。我々の実験では、160 ミリ秒未満の p99 レイテンシーで 72 QPS を達成しました。料金計算ツールは、指定された時間単位 (秒、分、時間、日、月あたり) にわたって均等に分散されるクエリの数を分割します。場合によっては、クエリが 30 秒を超えて実行されない場合 (アイドル期間を含む)、その 1 分全体に対して料金が請求されるわけではありませんが、この Calculator では考慮されないため、実際の合計額はさらに小さくなる可能性があります。クエリのワークロードをよりよく理解している場合は、本投稿の前半で共有した例に基づいて、さらに正確なコストを計算できます。 TCU の監視 TCU の使用状況を効果的に監視するために、Timestream for Live Analytics は Amazon CloudWatch メトリクス QueryTCU を提供します。このメトリクスは、1 分間に使用されるコンピューティングユニットの数を測定し、1 分ごとに更新されます。このメトリクスを使用すると、1 分間に使用された最大および最小の TCU を追跡でき、コンピューティングの使用状況を把握できます。さらに、このメトリクスにアラームを設定して、コンピューティング使用量が特定の閾値を超えたときにリアルタイム通知を受け取ることができ、使用量を最適化し、クエリコストを削減できます。 次のグラフは、過去 3 時間に使用された QueryTCU の最大値を示しています。 最大 TCU は価格の計算には直接役立ちませんが、最大/最小 TCU がどの程度になるかに関して洞察を与える事が出来ます。正確な TCU 時間は、AWS Cost Management コンソールを開いて Cost Explorer を開始 し、Timestream for LiveAnalytics でフィルターする事で確認できます。 2024 年 4 月 29 日以降に初めて Timestream for LiveAnalytics を使用する全ての AWS アカウントは、クエリ料金設定にデフォルトで TCU を使用するようになります。 2024 年 4 月 29 日より前にサービスを利用していた場合は、「コスト管理」セクションで説明されているように、 API を通じて TCU へのオプトインを行うか、AWS Timestream コンソールで変更出来ます。 TCU ベースの価格設定に移行すると、コスト管理が改善され、クエリごとに計測される最小バイト数が無くなります。 TCU ベースの価格設定モデルへのオプトインはオプションであり、元に戻すことのできない変更です。つまり、クエリ価格設定に TCU を使用するように AWS アカウントを移行した場合、クエリ価格設定にスキャンされたバイト数を使用するように戻す事はできません。 結論 この投稿では、TCU、請求、コスト見積もりについて説明し、4 および 8 TCU 構成でのクエリワークロードのシミュレーションを実証しました。リソースを効果的に利用すれば、コストを増加させることなくワークロードを拡張できます。従量制の料金体系と TCU 使用量の最大値の設定により、高度なコストの透明性と予測可能性が提供され、クエリのコストをより適切に計画および管理できるようになります。詳細については、次のリソースを参照してください。 Timestream Compute Unit (TCU) Data Modeling Best Practices to Unlock the Value of your Time-series Data Amazon Timestream pricing 今すぐ Timestream for LiveAnalytics の利用頂き、多くのメリットを享受することをお勧めします。さらに詳しく知りたい場合は、通常の AWS サポート連絡先に問い合わせるか、 Amazon Timestream の AWS re:Post に質問を投稿してください。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。