本ブログは 2025 年 1 月 8 日に公開された「 New AWS Skill Builder course available: Securing Generative AI on AWS 」を翻訳したものとなります。 Amazon Web Services（AWS） 上での生成 AI ワークロードをセキュアにするためにお客様をサポートする、新しい AWS Skill Builder コース「 Securing Generative AI on AWS 」の提供開始をお知らせします。 この包括的なコースは、セキュリティの専門家、アーキテクト、人工知能および機械学習（AI/ML）エンジニアが AWS クラウド上の生成 AI アプリケーションおよびモデルのセキュリティのベストプラクティスを理解し、実装するための助けとなるを目的としています。 AWS Skill Builder は、AWS のお客様およびパートナーがデジタルトレーニング、セルフペースラボ、その他のコースタイプを通じてクラウドスキルを構築するための学習センターです。AWS Skill Builder には、お客様が AWS セキュリティの概念を理解し、実践的な経験を得るための様々な AWS セキュリティコンテンツがあります。 コースのハイライトは以下の通りです（訳者注：コンテンツは英語となります）。 生成 AI セキュリティスコープマトリックスの紹介 – この革新的なフレームワークを使用して、異なる AI 実装を分類し、保護する方法を学びます。 主要な AI セキュリティフレームワークのカバレッジ – OWASP Top 10 for Large Language Models (LLMs) と MITRE ATLAS フレームワークについての洞察を得ます。 実践的なセキュリティ戦略 – 様々な AI のスコープにおけるガバナンス、法律、リスク、コントロール、レジリエンスの分野にわたる包括的なセキュリティを実装するスキルを開発します。 実世界での応用 – コンシューマアプリケーション、エンタープライズソリューション、事前学習済みのモデル、ファインチューニングされたモデル、自身で学習したモデルをカバーするケーススタディにセキュリティのコンセプトを適用します。 コースを受講するには 無料の AWS Skill Builder アカウントにサインアップします。 コースカタログで「Securing Generative AI on AWS」を検索します。 コースに登録して学習を始めましょう！ 補足情報 生成 AI セキュリティに関するさらなる情報については、以下のブログシリーズをご確認いただくことをお勧めします。 生成 AI をセキュアにする: 生成 AI セキュリティスコーピングマトリックスの紹介（日本語） 生成 AI をセキュアにする: 関連するセキュリティコントロールの適用（日本語） 生成 AI をセキュアにする: データ、コンプライアンス、プライバシーに関する考慮点（日本語） 私たちは皆さまのフィードバックや貢献を大切にしています。コースを完了した後にご意見や洞察があれば、コースのフィードバックから、または AWS サポート にお問い合わせください。 Anna McAbee Anna は、AWS で金融サービス、生成AI、インシデント対応にフォーカスしたセキュリティスペシャリストソリューションアーキテクトです。仕事以外では、テイラー・スウィフトを楽しみ、フロリダ・ゲイターズ・フットボールチームを応援し、NFL を観戦し、世界中を旅することを楽しんでいます。 Pablo Roesch Pablo は、AWS のテクニカルシニアプロダクトマネージャーで、セキュリティおよびクラウド運用トレーニングポートフォリオを管理しています。彼は生成 AI を活用してコース開発と市場投入戦略を革新し、技術的専門知識とイノベーティブなアプローチを組み合わせています。Pablo は、パッケージ化された仮想マシンアプリケーションとの外部通信（US 11,7973,26 B2）の特許を保有しており、クラウドおよび仮想化技術における彼の専門知識を反映しています。 Meg Peddada Meg は 10 年以上の経験を持つシニアセキュリティソリューションアーキテクトで、セキュリティ、リスク、コンプライアンスを専門としています。彼女の専門知識はガバナンス、セキュリティ自動化、脅威管理、アーキテクチャに及びます。余暇には、バレーボール、アートとクラフト、新しいブランチ体験を見つけることを楽しんでいます。 翻訳はプロフェッショナルサービス本部の藤浦 雄大が担当しました。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 私は年初に趣味のパデルの大会に出て、リフレッシュしてきました。みなさんはどんな年末年始を過ごされましたか？ 今年も新たな機能が追加されていってますね。それでは、先週の主なアップデートについて振り返っていきましょう。 2025年1月6日週の主要なアップデート 1/7(火) Amazon DynamoDB now supports configurable point-in-time-recovery periods Amazon DynamoDB では、ポイントインタイムリカバリ (PITR) の期間を設定できるようになりました。PITR を使用したデータリカバリの期間をテーブル単位で 1～35 日の範囲で指定できます。PITR は、DynamoDB のデータを偶発的な書き込みや削除から保護し、リカバリ期間内の任意の秒数までデータをリストアすることができます。 これにより、バックアップのリカバリ期間を設定することで、データリカバリ期間を短縮する必要があるコンプライアンスや規制要件を満たすことができます。 Announcing 20 additional AWS Systems Manager Automation runbook recommendations in AWS Chatbot AWS は、AWS Chatbot のイベント通知のコンテキストアクションボタンとして、AWS Systems Manager Automation で20 個の推奨ランブックの一般提供を発表しました。 このリリースにより、お客様は Microsoft Teams や Slack チャネルから AWS Systems Manager オートメーションを実行し、AWS Security Hub や Amazon ECS 関連のイベントに対処できるようになります。詳細は、AWS Chatbot の ドキュメント または AWS Chatbot の製品ページ を参照してください。 1/8(水) Amazon Q Developer is now available in Amazon SageMaker Code Editor IDE Amazon SageMaker は、SageMaker Studio コードエディタにおける Amazon Q Developer の一般提供を発表しました。 SageMaker Studio の顧客は、コードエディター (Visual Studio Code – オープンソース) IDE 内で、Q Developer によるジェネレーティブ AI アシスタンスを利用できるようになりました。 Q Developer を使用することで、データサイエンティストと ML エンジニアは、SageMaker の機能、コード生成、トラブルシューティングに関する専門家のガイダンスにアクセスできます。 これにより、退屈なオンライン検索やドキュメントレビューの必要性がなくなり、差別化されたビジネス価値を提供する時間を確保できるため、生産性が向上します。 Amazon Connect Contact Lens now provides free trials for conversational analytics and performance evaluations Amazon Connect Contact Lens は、会話分析とパフォーマンス評価を初めて利用するユーザー向けに無料トライアルを提供するようになりました。 音声用会話アナリティクスを初めてご利用になるお客様には、最初の 2 ヶ月間、月間 10 万分の音声通話を無料でお試しいただけます。 さらに、初めて Contact Lens のパフォーマンス評価を使用する顧客には、最初のパフォーマンス評価を提出した日から 30 日間の無料トライアルが提供されます。 1/9(木) AWS Compute Optimizer now expands idle and rightsizing recommendations for Amazon EC2 Auto Scaling groups AWS Compute Optimizer は、スケーリングポリシーと複数のインスタンスタイプを持つAmazon EC2 Auto Scaling グループに、アイドル状態と適切なサイズ調整の推奨事項を追加しました。 新しい推奨事項により、スケーリングポリシーや複数のインスタンスタイプを使用している Auto Scaling グループのコストとパフォーマンスを最適化するためのアクションを、専門的な知識やエンジニアリングリソースを必要とせずに実行できるようになります。 1/10(金) AWS CodeBuild now supports batch builds with reserved capacity and Lambda compute AWS CodeBuild は、バッチビルド機能を拡張し、リザーブドキャパシティフリートおよび Lambda コンピューティングのサポートを追加しました。この機能拡張により、ビルドバッチに対してオンデマンドインスタンス、リザーブドキャパシティフリート、Lambda コンピューティングリソースを組み合わせて選択できるようになります。バッチビルドでは、1 つのプロジェクト内で複数のビルドを同時に実行し、それらを調整することが可能です。この機能は、マルチプラットフォームプロジェクトや相互依存するビルドプロセスを持つ開発者に特に有用です。ビルドシーケンスは、ビルドリスト、ビルドマトリックス、または依存関係グラフを使用して定義できます。CodeBuild はこれらのビルドのオーケストレーションを管理し、開発と統合プロセス全体を効率化します。 Amazon Connect Contact Lens launches agent performance evaluations for email contacts Amazon Connect Contact Lens は、メールコンタクトに対するエージェントのパフォーマンス評価機能をリリースしました。この新機能により、マネージャーは Amazon Connect 内でメールを含むすべてのコンタクトチャネル（音声、チャット、メール、タスク）におけるエージェントのパフォーマンスを、使いやすい単一のウェブインターフェースで評価できるようになりました。また、エージェントグループ全体のパフォーマンスを時系列で集約した洞察も得られます。 インフルエンザも流行っているので、みなさんも体調には気をつけてください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

本ブログは 2024 年 12 月 17 日に公開された「 How DeNA Co., Ltd. accelerated anonymized data quality tests up to 100 times faster using Amazon Redshift Serverless and dbt 」を翻訳したものです。 本ブログは 株式会社ディー・エヌ・エー（以下 DeNA ） と Amazon Web Services Japan が共同で執筆しました。 DeNA は「一人ひとりに想像を超える Delight を」というミッションのもと、ゲーム、ライブコミュニティ、ヘルスケア・メディカル、スポーツ・スマートシティ、モビリティなど多岐にわたる事業を展開しています。中でもヘルスケア・メディカル事業では、機密性の高いデータを扱っており、同社のデータポリシーに準拠するためにデータ処理に関して以下の要件を設定しています： データポリシーに準拠したデータ処理 – 必要に応じて機密性の高いデータをマスキングや削除を行い、匿名化データに変換します。加えて区分値に無効な値が含まれないようにするなど、的確且つ損失なくデータの処理を行います。 データポリシーに準拠した匿名化データの品質テスト – 加工後のデータ品質問題を迅速に特定し対処するため、データ品質テストを実施して高品質なデータを常に維持します。 本ブログでは、DeNA が Amazon Redshift Serverless と dbt ( dbt Core ) を組み合わせて、匿名化データの品質テストを高速化した事例をご紹介します。なお、本取り組みについては DeNA Engineer Blog にも記載があります。そちらも併せて参考いただけると幸いです。 解決したい課題 データ品質テストは、毎月 10 TB のデータに対して 1,300 件のテストを実施する必要があります。今までデータ品質テストは AWS 上の Amazon Elastic Compute Cloud (Amazon EC2) で Python で実装されたバッチジョブを実行して行ってきました。しかし、事業とデータ量の拡大に伴い、以下の課題に直面しました。 パフォーマンス – エンジニアがビッグデータ処理を想定してバッチを設計していなかったため、データ品質テストの完了に数日から数週間を要していました。 コスト – 特に大規模なデータセットに対して、バッチの設計によりコストが増加しました。実装上、データをメモリにロードして処理する必要があり、大規模なテーブルのデータを扱う際には、メモリ容量が大きな EC2 インスタンスを利用する必要がありました。 保守性 – バッチの実装がエンジニアごとに大きく異なり、保守に必要な知識が属人化していたため、保守のコストが増大していました。 Redshift Serverless と dbt への移行 これらの課題を解決するため、DeNA は以下の理由から Redshift Serverless と dbt (オープンソースのデータ変換ツール) を採用しました。主な理由は以下の通りです：  Redshift Serverless によりスケーラブルでコスト効率の高い処理が可能  dbt により利用技術を標準化して運用がしやすいデータ品質テストの実装が可能 この決定は様々なソリューションを比較検討した結果なされました。当初 DeNA は既存の Python バッチジョブを並列化することを検討しました。しかし、現時点で保守負荷が高く改修が難しい Python バッチに手を入れるのは工数が多くかかり、また属人化による高い保守負荷を解決することにはつながらないため、採用を見送りました。代わりに、ヘルスケア・メディカル事業で利用している dbt を採用し、大規模な分散処理が可能な AWS のサービスと組み合わせて利用することを決定しました。dbt は SQL 中心のテンプレートエンジンで、反復的で拡張可能なデータ変換を SQL と Python で記述することができます。dbt には data tests という、SQL を利用してデータモデルやテーブルが期待されるルールや条件に従っているかを検証するテスト機能があり、データの整合性や制約違反を検出してデータ品質を高めることができます。この機能を利用することで、事業における利用技術を統一化することができ、運用性や汎用性の高い SQL を利用してデータ品質テストを実装することができます。また dbt を大規模分散処理が得意なマネージドサービスに接続することで、コスト効率を向上させながら処理を高速化できると考えました。 AWS は dbt を接続してデータを処理できるサービスとして、 Amazon Redshift や  AWS Glue などを提供しています。今回 DeNA は Redshift Serverless を採用しました。主な採用理由は、サーバーレスによる低い運用負荷と高いコストパフォーマンスに加え、データウェアハウスサービス特有の構造化されたデータへの優れた処理パフォーマンスです。 ソリューションの概要 DeNA は以下のアーキテクチャを設計しました。コスト効率や運用性の観点で、すべてのコンポーネントをサーバーレスで構築しました。 設計のポイント データ品質テストの対象となるデータは Amazon Simple Storage Service (Amazon S3) に配置されるため、配置をトリガーに Amazon EventBridge 経由で AWS Step Functions の ステートマシン (ワークフロー) を起動しました。1種のデータで複数のファイルが提供されるため、すべてのファイルの配置が完了したことを確認できるように、提供元のシステムから完了を示すファイルを Amazon S3 に配置するようにしました。 dbt は AWS のサーバーレスコンテナサービスである AWS Fargate を利用して Amazon Elastic Container Service (Amazon ECS) 上で実行するようにしました。Amazon ECS を採用した理由は、サーバーレス且つ従量課金で dbt を実行でき、過去 DeNA で Amazon ECS を利用したアプリケーションの開発・運用経験があったためです。また dbt が実行されるコンテナ上から Redshift Serverless に安全にアクセスできるようにするため、DeNA は コンテナに機密データを渡す Amazon ECS の機能 を使用し、AWS Secrets Manager に保存された接続のためのクレデンシャルを ECS タスク実行 IAM ロール を使用してコンテナに渡しました。 アクセス制御のため Redshift Serverless を制御の境目で別々の ワークグループ に分離しました。ワークグループはコンピューティングリソースの集合で、アクセス制御などのセキュリティ設定も含まれます。データ品質テストでは、データ品質の問題を調査するなどの運用の観点から運用者が実際に Query Editor V2 を利用して Redshift Serverless 上のデータベースにアクセスすることがあります。しかし扱っているデータの機密性が高いため、限定された人のみアクセスできるようにする必要があります。Redshift Serverless は データベースセキュリティ機能 を利用することで、データベース製品と同じように GRANT コマンド を利用して細かくデータへのアクセス制御を行うことが可能です。しかし今回は AWS Identity and Access Management (IAM) の機能を利用して、ワークグループへの 接続を IAM レベルで制御しました 。これにより、特定の IAM ロールを持つ人は特定の Redshift Serverless ワークグループへのアクセスに制限することができるようになり、IAM で認可の管理が統一的にできるようになりました。またワークグループを分離したことによって、処理で必要とする計算リソースである RPU (Redshift Processing Unit) を個別に調整することができ、コスト最適化にも寄与しました。 Amazon ECS 上で実行される dbt のログは Amazon CloudWatch Logs に送信されます。DeNA は メトリクスフィルター を利用してログを CloudWatch メトリクス に変換し、これらのメトリクスに基づいてアラームを作成しました。トリガーされたアラームは、 Amazon Simple Notification Service (Amazon SNS) を使用して AWS Lambda の関数を呼び出します。この Lambda 関数は、dbt の実行とデータ品質テストの結果レポートを作成し、DeNA 内部のチャットアプリケーションに送信します。DeNA はデータ品質テストの結果を elementary CLI を利用して可視化しました。elementary CLI は dbt ネイティブなデータオブザーバビリティソリューションで、dbt と連携してデータの状態を可視化することが可能です。これにより、エンジニア以外のユーザーでもデータ品質テストの状況を効率的に確認できるようになりました。 導入効果 DeNA はソリューションを設計して新しいプラットフォームに移行することで、直面していたすべての課題を解決することができました： パフォーマンス – 数日または数週間掛かっていた処理時間を 1~2 時間に短縮し、最大 100 倍の高速化を実現しました。以前は 877 分かかっていた特定のデータ品質テストが、Redshift Serverless の大規模分散処理機能により、現在では 1 分で完了できるようになりました。 コスト – 90% のコスト削減を実現できました。サーバーレスサービスで構築したため、データ品質テスト実行中のみのコスト発生となり、コスト圧縮を実現することができました。 保守性 – dbt による利用技術の標準化により、実装の属人化を無くすことができました。dbt の data tests 機能により、データ品質テストの実装が簡素化されました。elementary CLI により、エンジニア以外のユーザーにもデータ品質テストのオブザーバビリティが向上しました。AWS のサーバーレスサービスにより、ワークロードのインフラを管理するための運用コストがほぼゼロになりました。 まとめ 本ブログでは、DeNA が Redshift Serverless と dbt を組み合わせることで、データ品質テストを安全かつ効率的に加速できた事例をご紹介しました。この組み合わせは、DeNA のユースケースだけでなく、さまざまな業界における多様なビジネスユースケースにも適用可能です。 Redshift Serverless と dbt の組み合わせについて詳しくは、以下のリンクを参照ください。 dbt CLI and Amazon Redshift Manage data transformations with dbt in Amazon Redshift Implement data warehousing solution using dbt on Amazon Redshift Best Practices for Leveraging Amazon Redshift and dbt 著者について Momota Sasaki は、DeNA の主要子会社である DeSC ヘルスケア株式会社のエンジニアリングマネージャーです。彼は 2021 年に DeNA に入社し、DeSC ヘルスケア株式会社に出向しました。それ以来、一貫してヘルスケア事業に携わり、データプラットフォームの開発と運用をリードし、推進しています。 Kaito Tawara は、DeNA の主要子会社である DeSC ヘルスケア株式会社のデータエンジニアで、ヘルスケア事業のデータプラットフォームの改善に注力しています。ウェブシステムのバックエンド開発とデータサイエンスの経験を積んだ後、データエンジニアリングに転向しました。2023 年に DeNA に入社し、 DeSC ヘルスケア株式会社に出向しました。現在は名古屋市からリモートで勤務し、ヘデータプラットフォームの強化に貢献しています。 Shota Sato は、AWS Japan のアナリティクススペシャリストソリューションアーキテクトです。デジタルネイティブビジネスを行う顧客向けに AWS を活用したデータ分析ソリューションの提案を行っています。 このブログの翻訳はソリューションアーキテクトの佐藤 祥多が担当しました。

1 月 7 日、3 つのアベイラビリティーゾーンと API 名 ap-southeast-7 で、AWS アジアパシフィック (タイ) リージョンの一般提供を開始したことをお知らせいたします。 AWS アジアパシフィック (タイ) リージョンは、タイ初のインフラストラクチャリージョンであり、香港、ハイデラバード、ジャカルタ、マレーシア、メルボルン、ムンバイ、大阪、ソウル、シンガポール、シドニー、および東京の既存のリージョン、ならびに中国の北京および寧夏リージョンに加わり、アジアパシフィックで 14 番目のリージョンとなります。 ルンピニ公園は、バンコク中心部にある 142 エーカーに及ぶ最大の緑地の 1 つです。 タイでは、進化するビジネスニーズと Thailand 4.0 などの政府のイニシアティブにより、クラウドコンピューティングの導入が急速に進んでいます。これらのイニシアティブは、新興テクノロジーを利用して、生産性を高め、競争力を強化し、持続可能な成長を推し進めることで、タイをイノベーションドリブンの経済に変革することを目指しています。 この新しい AWS リージョンは、スタートアップ、企業、政府機関、教育機関、非営利団体が、タイ国内にデータレジデンシーを維持しながら、アプリケーションを実行し、エンドユーザーにサービスを提供できるようサポートします。これは、タイのデジタルトランスフォーメーションの目標およびクラウドサービスの需要の高まりに資するものです。今後 15 年間で、Amazon Web Services (AWS) が計画しているタイにおける投資は、タイの国内総生産 (GDP) に 100 億 THB 貢献し、タイの現地企業で年間平均 11,000 人のフルタイム当量 (FTE) の雇用を支えると推定されています。 タイでの AWS の存在感の高まり タイでの当社の取り組みは、2013 年にバンコクに最初の AWS オフィスを開設したことから始まりました。それ以来、AWS はタイ国内でインフラストラクチャとサービスを継続的に拡大してきました。 Amazon CloudFront – 2020 年以降、AWS はタイ全土に 6 つの Amazon CloudFront エッジロケーションを設けました。これらのエッジロケーションは、非常に安全でプログラム可能な AWS コンテンツ配信ネットワーク (CDN) の一部であり、低レイテンシーと高速転送で、世界中のユーザーに対するデータ、動画、アプリケーション、API の配信を加速するように設計されています。 AWS Outposts – 同じ 2020 年に、AWS はタイ市場に AWS Outposts を導入しました。フルマネージドソリューションである AWS Outposts は、AWS インフラストラクチャとサービスをほぼすべてのオンプレミスまたはエッジロケーションで利用できるようにし、真に一貫したハイブリッドエクスペリエンスを実現します。このサービスは、低レイテンシー、ローカルデータ処理、またはローカルデータストレージを必要とするワークロードに特に役立ちます。 AWS Local Zones – 2022 年、AWS はバンコクでの AWS Local Zones の立ち上げを通じて、タイへの取り組みを強化しました。このインフラストラクチャデプロイにより、コンピューティング、ストレージ、データベース、および他の厳選されたサービスが、人口の多い場所、産業、IT センターのより近くで提供されるようになります。その結果、お客様は 1 桁ミリ秒のレイテンシーを必要とするアプリケーションをエンドユーザーに提供できます。 AWS Direct Connect – AWS は、接続オプションを強化するために 2023 年にバンコクに AWS Direct Connect ロケーションを設け、AWS アジアパシフィック (タイ) リージョンの立ち上げに合わせて新しい AWS Direct Connect ロケーションを追加しました。お客様は AWS Direct Connect を利用して、AWS リソースへの安全な専用ネットワーク接続を確立し、ネットワークパフォーマンスを改善するとともに、帯域幅コストを削減できます。 タイにおける AWS のお客様の成功事例 タイの組織は、イノベーションと変革を推進するために弊社のサービスを利用しています。例をいくつかご紹介します。 2C2P タイを拠点とする大手 FinTech スタートアップである 2C2P は、堅牢なセキュリティ機能を理由として AWS を選択しました。東南アジアのオムニチャネル決済サービスプロバイダーである同社は、暗号キー管理のために AWS CloudHSM、分散型サービス拒否 (DDoS) からの保護のために AWS Shield、機密性の高い認証情報を保護するために AWS Secrets Manager を利用して、世界中で何百万もの顧客決済を処理しています。 「AWS を通じて、安全かつ動的に、コンプライアンスに準拠してスケールし、決済取引量の急増に対応できるようになりました。AWS CloudHSM は、コンプライアンス要件を満たし、ビジネスの拡大を加速させる上で重要な役割を果たしています」と 2C2P の Chief Technology Officer である Myo Zaw 氏は述べています。 aCommerce 東南アジア最大級の e コマースイネーブラーである aCommerce は、AWS で生成 AI を活用した機能である AskIQ をリリースし、マーケットインテリジェンスに革命をもたらしました。この Software as a Service (SaaS) プラットフォームは、東南アジア最大級の e コマースサイト全体で、競合他社およびカテゴリについての包括的なパフォーマンス追跡機能を世界有数のブランドに提供します。 aCommerce Group の VP of Data Products である Leena Chanvirach 氏は、AWS とのコラボレーションの戦略的価値を強調しています。「AWS とのコラボレーションにより、クライアントはコアコンピテンシーとビジネス上の優先事項に注力できます。この両方の長所を兼ね備えたアプローチにより、ブランドは社内で高度なデータインフラストラクチャを構築および維持する負担なしに、競争上の優位性を獲得できます」。 Ascend Money 東南アジアの先駆的な FinTech 企業である Ascend Money は、特定のワークロードでアプリケーションパフォーマンスを最大 40% 改善しながら、コンピューティングコストを 70% 削減できました。Ascend Money は、Amazon EC2 インスタンスを使用して高度なコンピューティング戦略を実装し、運用を大幅に改善しました。 「AWS によって当社のパフォーマンスが大幅に改善され、より革新的なサービスをお客様に提供できるようになりました」と Ascend Money の Head of Technical Operations である Peerawit Phuangkaeo 氏は述べています。 ともにクラウドスキルを構築 AWS は、タイでクラウド教育とスキル開発のための包括的なプログラムを構築し、2017 年以降、50,000 人を超える個人にクラウドスキルのトレーニングを提供してきました。プログラムの一部は次のとおりです。 AWS Skill Builder AWS Skill Builder は、AWS のエキスパートから学び、クラウドスキルをオンラインで構築できるオンライン学習センターです。AWS は、600 を超えるコース (タイ語で提供されるコースは 106 あります) を提供することで、タイの学習者がクラウド教育をより利用しやすくしました。最近立ち上げられた Amazon AI Ready イニシアティブにより、特に成長している AI 分野での学習機会がさらに拡大しました。 AWS Educate 2016 年に提供が開始されてから、AWS Educate はタイの教育に変革をもたらしてきました。このプログラムは、タイ全土の教育カリキュラムにクラウドコンピューティングをうまく統合し、AWS リソースへの直接アクセスとハンズオンエクスペリエンスを学生に提供しています。その影響は大きく、20,000 人を超えるタイの学生がこのプログラムに登録しています。学生の教育を超えて、AWS Educate はタイの教育者のトレーニングに投資し、学生がデジタル経済の需要に対応できるようにするための、魅力的かつ実用的なクラウドコンピューティングコースを、これらの教育者が提供できるようにサポートしています。 AWS Academy 2017 年にタイで提供が開始されてから、AWS Academy は、学術的な学習と業界のニーズを結び付ける上で重要な役割を果たしてきました。国内の 30 を超える先駆的な大学やカレッジとの戦略的パートナーシップを通じて、AWS Academy は、クラウドスキルを備えたプロフェッショナルの強力なパイプラインを構築しました。このプログラムは、業界のニーズに合わせた包括的なクラウドコンピューティングカリキュラムを教育機関に提供し、すぐに仕事で用いることのできる実践的なスキルを学生が身につけて卒業できるようにします。 これらのさまざまなイニシアティブとプログラムを通じて、AWS は教育リソースを提供するだけでなく、クラウドテクノロジーを効果的に利用するために必要なスキルをワークフォースに身につけさせるのをサポートすることで、タイのデジタルの未来の基盤を構築しています。 タイにおける持続可能なイノベーションのサポート AWS の持続可能性への取り組みは、環境イニシアティブを推進しているタイの革新的な企業のサポートにも及びます。 BODA Technology & Consultancy AWS を活用した持続可能性のスタートアップである BODA は、エネルギー効率の最適化を実現するために、AWS IoT Core を利用して AI を活用したソリューションを開発しています。同社は、タイ全土の 100,000 を超える建物や工場の運用を成功裏に改善し、コストや環境への影響を抑えながら、これらの施設が効率を最大限に高められるようにしました。 GSPC Group タイの持続可能かつ先駆的な電力会社である GSPC Group を見れば、AWS がエネルギー部門のデジタルトランスフォーメーションをどのようにサポートしているのかを知ることができます。Global Power Synergy Public Company と Glow Energy の合併後、同グループは、太陽光発電所の運用を移行するために AWS クラウドを選びました。AWS および AWS パートナーである Dailitech と連携して、GSPC Group は、クラウドに移行してから、ハードウェア、ソフトウェア、ライセンスのコストを 20～25% 削減できました。 知っておくべきこと タイの AWS コミュニティ – タイには、2 人の AWS ヒーロー、7 人の AWS コミュニティビルダー、17,000 人を超える AWS User Group のメンバーがいます。AWS User Group Thailand への参加にご興味がある場合は、同グループの Facebook ページにアクセスしてください。 AWS のグローバル展開 – AWS は現在、世界中の 35 の地理的地域内の 111 のアベイラビリティーゾーンでサービスを提供しています。当社は、ドイツ、台湾、メキシコ、サウジアラビア王国、ニュージーランドにおいて、さらに 15 のアベイラビリティーゾーンと 5 つの AWS リージョンを追加する計画を発表しました。 新しいアジアパシフィック (タイ) リージョンは、お客様のビジネスをサポートする準備ができています。詳細については、「 AWS グローバルインフラストラクチャ 」のページにアクセスしてください。そして、 ap-southeast-7 で構築を開始しましょう。 構築がうまくいきますように。 –  Donnie 原文は こちら です。

明けましておめでとうございます! 私たちは、テクノロジーがインスピレーションに富む方法で人間の創意工夫を強化するのを目の当たりにしています。今後数年間、好ましい影響をもたらすためにテクノロジーを利用することで、成功についての考え方が再定義されるでしょう。Amazon の CTO であるワーナー ヴォゲルス博士は、2025 年以降について、将来を見据えたテクノロジーに関する 5 つの予測を提示しています: 明日のワークフォースはミッションドリブンである エネルギー効率の新しい時代がイノベーションを推進する テクノロジーが真実の発見に大きな役割を果たす オープンデータが分散型災害対策を推進する 意図駆動型の消費者向けテクノロジーが定着する ワーナー ヴォゲルスの 「Tech Predictions for 2025 and Beyond」eBook をダウンロードするか、またはワーナーの All Things Distributed ブログ を読み、これらのテクノロジーのトレンドが世界をどのように形作り、より革新的かつ効率的で目的のある未来への道を切り拓いているかについて詳しく学んでください。 AWS re:Invent 2025 の動画と re:Caps re:Invent での発表を知りたい場合や、最新の AWS イノベーションについてさらに詳しく知りたい場合は、次のようないくつかのオプションをご利用いただけます: 基調講演、イノベーショントーク、ブレイクアウトセッション をオンデマンドで視聴する。 主要な AWS re:Invent の発表の概要をダウンロードする。 世界中の AWS ユーザーグループ のボランティアが主催する、 実地で開催される無料コミュニティである re:Cap のセッション に参加する。 過去数週間のリリース 2024 年 12 月 16 日の 前回の Weekly Roundup 以降の、年末そして先週からのリリースをいくつか取り上げたいと思います。 Amazon SageMaker JumpStart と Amazon Bedrock で Llama 3.3 70B が利用可能に – Meta の Llama 3.3 70B は、モデルの効率性とパフォーマンスの最適化における大きな進歩を体現しています。Llama 3.3 70B は、テキストのみのアプリケーションのために使用される場合、 Llama 3.1 70B および Llama 3.2 90B と比較してより優れたパフォーマンスを発揮する、テキストのみのインストラクションチューニングモデルです。 Amazon SageMaker JumpStart と Amazon Bedrock の両方でこのモデルを使用できるようになりました。 Amazon Bedrock で Stable Diffusion 3.5 Large が利用可能に – Stability AI が提供する Stable Diffusion 3.5 Large は、 Amazon SageMaker HyperPod でトレーニングされた 81 億のパラメータを備えた、Stable Diffusion ファミリーで最も強力なモデルです。 Amazon Bedrock で Stable Diffusion 3.5 Large を使用して、テキストの説明から質の高い画像を生成できるようになりました。 Apache Flink 用の新しい Amazon Kinesis ソースコネクタ – Apache Flink コミュニティは、AWS オープンソースコントリビューションである AWS サービスコネクタのバージョン 5.0.0 をリリースしました。このリリースでは、以前の Kinesis Consumer に代わる、 Amazon Kinesis Data Streams からデータを読み取るための新しいコネクタである Kinesis Streams Source が導入されています。 Amazon WorkSpaces Personal での AWS Global Accelerator のサポート – Amazon WorkSpaces Personal は、 AWS Global Network とエッジロケーション を通じてストリーミングトラフィックを最適化することで WorkSpaces 接続パフォーマンスを強化するために、 AWS Global Accelerator (AGA) と統合するようになりました。この機能は、WorkSpaces に遠距離で接続するエンドユーザーを抱えるお客様に特に役立ちます。AGA 機能は、WorkSpaces ディレクトリレベルで有効にすることも、 Amazon DCV プロトコル を実行する個々の WorkSpaces のために有効にすることもできます。 AWS Resource Explorer の新しいリソースインサイト – 強化された Resource Explorer エクスペリエンスにより、 サポートされているリソースタイプ のために、複数の AWS サービスからの関連データとインサイトが一元化されます。新しい機能を使用すると、タグの管理、アプリケーションへのリソースの追加、 Amazon Q を使用した、リソースに関する追加情報の取得など、Resource Explorer コンソールから直接リソースに対するアクションを実行できます。 AWS Billing and Cost Management でのカスタム請求ビューの一般提供の開始 – カスタム請求ビュー を使用すると、 AWS 管理アカウント へのアクセスを付与することなく、 AWS Cost Explorer の単一のビューを使用して、複数の AWS アカウントにわたる関連コスト管理データへのアクセスを、アプリケーションおよびビジネスユニットの所有者に提供できます。コスト配分タグまたは特定の AWS アカウントに基づいて、コスト管理データのフィルタリングされたビューを作成できます。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページを定期的にご確認ください。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS at CES 2025 (1 月 7～10 日) – AWS は、自動車、モビリティ、輸送、製造の各業界向けに特別に構築された最新のクラウドサービスおよびソリューションのいくつかをご紹介します。 Amazon Experience Area に参加して、生成 AI、ソフトウェア定義車両、プロダクトエンジニアリング、サステナビリティ、新たなデジタルカスタマーエクスペリエンス、コネクテッドモビリティ、自動運転などの分野における最新のクラウド機能について学びましょう。 AWS at NRF 2025 (1 月 12～14 日) – Retail’s Big Show で AWS に参加して、生成 AI と最先端のテクノロジーが実際に役立っている様子をご覧ください。革新的なビッグアイデアセッションや厳選された TechTalks を聴き、小売業界の最新のトレンドやテクノロジーなどをご体験ください。 Amazon QuickSight 学習シリーズ – データスキルを強化することで 2025 年をスタートしましょう。1 月のオンライン学習シリーズに参加して、 re:Invent 2024 で発表された Amazon QuickSight の最先端の機能 について学びましょう。 近日開催予定の実地イベントやバーチャルイベントをすべてご覧いただけます。 1 月 6 日週はここまでです。1 月 13 日週の Weekly Roundup もお楽しみに! – Prasad この記事は、 Weekly Roundup シリーズ の一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

12 月 3 日、最先端インテリジェンスと業界トップクラスの価格パフォーマンスを実現する新世代の最先端 基盤モデル (FM) である Amazon Nova を発表できたことを嬉しく思います。このモデルは Amazon Bedrock でのみご利用いただけます。 Amazon Nova を使用すると、ほとんどすべての 生成 AI タスクのコストとレイテンシーを削減できます。Amazon Nova をベースに構築することで、企業のワークロードに最適化されたさまざまなインテリジェンスクラスから、複雑なドキュメントやビデオの分析、チャートや図の理解、魅力的なビデオコンテンツの生成、高度な AI エージェントの構築を行うことができます。 画像やテキストを処理する必要があるドキュメント処理アプリケーションを開発する場合でも、大規模なマーケティングコンテンツを作成する場合でも、視覚情報を理解して処理できる AI アシスタントを構築する場合でも、Amazon Nova は、理解とクリエイティブコンテンツ生成という 2 つのカテゴリのモデルで必要なインテリジェンスと柔軟性を提供します。 Amazon Nova 理解モデルでは、テキスト、画像、またはビデオの入力を受け付けてテキスト出力を生成します。Amazon クリエイティブコンテンツ生成モデルでは、テキストと画像の入力を受け付けて画像またはビデオ出力を生成します。 理解モデル: テキストとビジュアルインテリジェンス Amazon Nova モデルには、さまざまなニーズを満たすように設計された 3 つの理解モデルが含まれています（4 つ目は近日公開予定）。 Amazon Nova Micro – Amazon Nova シリーズのモデルで最もレイテンシーの低いレスポンスを非常に低コストで提供するテキストのみのモデルです。Amazon Nova Micro は、コンテキストの長さが 128,000 トークンで、速度とコストを重視して最適化されているため、テキストの要約、翻訳、コンテンツの分類、インタラクティブなチャットとブレーンストーミング、単純な数学的推論とコーディングなどのタスクに優れています。Amazon Nova Micro では、精度を向上させるための微調整とモデル蒸留による独自データのカスタマイズもサポートしています。 Amazon Nova Lite – 画像、ビデオ、テキスト入力を高速に処理してテキスト出力を生成する、非常に低コストのマルチモーダルモデルです。Amazon Nova Lite は、お客様とのリアルタイムのやり取り、ドキュメント分析、および視覚的な質問応答タスクを高精度で処理できます。このモデルは、最大 30 万トークンの長さの入力を処理し、1 回のリクエストで複数の画像または最大 30 分のビデオを分析できます。Amazon Nova Lite は、テキストとマルチモーダルの微調整もサポートしており、モデル蒸留などの手法を使用して、ユースケースに最適な品質とコストを実現するように最適化できます。 Amazon Nova Pro – 精度、スピード、コストの最適な組み合わせで、幅広いタスクに対応する高性能マルチモーダルモデルです。Amazon Nova Pro は最大 30 万個の入力トークンを処理でき、複雑なワークフローを完了するために呼び出す API とツールを必要とするマルチモーダルインテリジェンスとエージェントワークフローに新しい標準を打ち立てます。視覚的な質問応答（ TextVQA ）やビデオ理解（ VATEX ）などの主要なベンチマークで最先端のパフォーマンスを実現しています。Amazon Nova Pro は、視覚情報とテキスト情報の両方を処理する強力な機能を発揮し、財務書類の分析にも優れています。30 万トークンの入力コンテキストで、15,000 行を超えるコードを含むコードベースを処理できます。Amazon Nova Pro は、Amazon Nova Micro と Lite のカスタムバリアントを抽出するための教師モデルとしても機能します。 Amazon Nova Premier – 複雑な推論タスクや、カスタムモデルの抽出に最適な教師として使用できる、当社の最も高性能なマルチモーダルモデルです。Amazon Nova Premier はまだトレーニング中です。2025 年初頭に発売を開始することを目標としています。 Amazon Nova 理解モデルは、 Retrieval-Augmented Generation (RAG) 、関数呼び出し、およびエージェントアプリケーションに優れています。これは、 Comprehensive RAG Benchmark (CRAG) 評価、 Berkeley Function Calling Leaderboard (BFCL) 、 VisualWebBench 、 Mind2Web の Amazon Nova モデルスコアに反映されています。 Amazon Nova を企業にとって特に強力なものにしているのは、そのカスタマイズ機能です。スーツを仕立てるようなものだと考えてください。高品質のファンデーションから始めて、ニーズに合わせて調整します。テキスト、画像、ビデオを使用してモデルをファインチューニングすることで、業界の用語を理解し、ブランドボイスを理解し、特定のユースケースに合わせて最適化できます。たとえば、法律事務所では、法律用語やドキュメント構造をよりよく理解するために Amazon Nova をカスタマイズする場合があります。 これらのモデルの最新のベンチマークスコアは、 Amazon Nova 製品ページ で確認できます。 クリエイティブなコンテンツ生成: コンセプトに命を吹き込む Amazon Nova モデルには、次の 2 つのクリエイティブコンテンツ生成モデルも含まれています。 Amazon Nova Canvas – インペイント、アウトペイント、背景削除などの豊富な編集機能を含む、スタイルとコンテンツを正確に制御しながらスタジオ品質の画像を生成する最先端の画像生成モデルです。Amazon Nova Canvas は、人間による評価だけでなく、 質問回答によるテキストと画像の忠実度評価 (TIFA) や ImageReward などの主要なベンチマークにも優れています。 Amazon Nova Reel – 最先端のビデオ生成モデルです。Amazon Nova Reel を使用すると、テキストプロンプトや画像を使用して短いビデオを制作したり、視覚スタイルやペースを制御したり、マーケティング、広告、エンターテイメント向けのプロ品質のビデオコンテンツを生成したりできます。Amazon Nova Reel は、ビデオの品質とビデオの一貫性に関する人間による評価において、既存のモデルよりも優れています。 Amazon Nova のすべてのモデルには安全制御が組み込まれており、クリエイティブコンテンツ生成モデルには責任ある AI の使用を促進するためのウォーターマーク機能が含まれています。 いくつかのユースケースで、これらのモデルが実際にどのように機能するかを見てみましょう。 ドキュメント分析に Amazon Nova Pro を使用する ドキュメント分析の機能を実証するために、AWS のドキュメントから PDF 形式の「 生成 AI サービスの選択 」決定ガイドをダウンロードしました。 まず、 Amazon Bedrock コンソール のナビゲーションペインで [ モデルアクセス ] を選択し、新しい Amazon Nova モデルへのアクセスをリクエストします。次に、ナビゲーションペインの [ プレイグラウンド ] セクションで [ チャット/テキスト ] を選択し、 mazon Nova Pro モデルを選択します。チャットでは、意思決定ガイドの PDF をアップロードして、次のことを尋ねます。 このドキュメントの要約を 100 字で書いてください。次に、デシジョンツリーを作成します。 出力は私の指示に従い、読む前にドキュメントを垣間見ることができる構造化されたデシジョンツリーを生成します。 ビデオ分析に Amazon Nova Pro を使用する ビデオ分析を示すために、2つの短いクリップを結合してビデオを作成しました（これについては次のセクションで詳しく説明します）。 今回は、 AWS SDK for Python (Boto3) を使用して Amazon Bedrock Converse API を使用して Amazon Nova Pro モデルを呼び出し、ビデオを分析します。 import boto3 AWS_REGION = "us-east-1" MODEL_ID = "amazon.nova-pro-v1:0" VIDEO_FILE = "the-sea.mp4" bedrock_runtime = boto3.client("bedrock-runtime", region_name=AWS_REGION) with open(VIDEO_FILE, "rb") as f: video = f.read() user_message = "このビデオについて説明します。" messages = [ { "role": "user", "content": [ {"video": {"format": "mp4", "source": {"bytes": video}}}, {"text": user_message} ] } ] response = bedrock_runtime.converse( modelId=MODEL_ID, messages=messages, inferenceConfig={"temperature": 0.0}  ) response_text = response["output"]["message"]["content"][0]["text"] print(response_text) Amazon Nova Pro は、API を使用してアップロードされたビデオ (前のコードと同様) や、 Amazon Simple Storage Service (Amazon S3) バケットに保存されたビデオを分析できます。 スクリプトでは、ビデオの説明をお願いしています。コマンドラインからスクリプトを実行します。結果は次のとおりです。 ビデオは海の岩だらけの海岸の眺めから始まり、次に砂浜で休んでいる大きな貝殻のクローズアップに移ります。 より詳細なプロンプトを使用して、オブジェクトやテキストなどの特定の情報をビデオから抽出できます。Amazon Nova は現在、ビデオのオーディオを処理していないことに注意してください。 ビデオ作成に Amazon Nova を使用する それでは、Amazon Nova Reel を使用してビデオを作成しましょう。テキストのみのプロンプトから始めて、参照画像を指定します。 ビデオの生成には数分かかるため、Amazon Bedrock API では次の 3 つの新しいオペレーションが導入されました。 StartAsyncInvoke – 非同期呼び出しを開始する GetAsyncInvoke – 特定の非同期呼び出しの現在のステータスを取得する ListAsyncInvokes – ステータスや日付などのオプションフィルタを使用して、すべての非同期呼び出しのステータスを一覧表示する Amazon Nova Reel は、カメラのズームや移動などのカメラコントロールアクションをサポートしています。この Python スクリプトは、次のテキストプロンプトからビデオを作成します。 砂の中の大きな貝殻のクローズアップ。シェルの周りには穏やかな波が流れています。サンセットライト。カメラのズームインが非常に近いです。 最初の呼び出し後、スクリプトはビデオの作成が完了するまで定期的にステータスをチェックします。ランダムシードを渡すと、コードが実行されるたびに異なる結果が得られます。 import random import time import boto3 AWS_REGION = "us-east-1" MODEL_ID = "amazon.nova-reel-v1:0" SLEEP_TIME = 30 S3_DESTINATION_BUCKET = "<BUCKET>" video_prompt = "砂の中の大きな貝殻のクローズアップ。シェルの周りには穏やかな波が流れています。サンセットライト。カメラのズームインが非常に近いです。" bedrock_runtime = boto3.client("bedrock-runtime", region_name=AWS_REGION) model_input = { "taskType": "TEXT_VIDEO", "textToVideoParams": {"text": video_prompt}, "videoGenerationConfig": { "durationSeconds": 6, "fps": 24, "dimension": "1280x720", "seed": random.randint(0, 2147483648) } } invocation = bedrock_runtime.start_async_invoke( modelId=MODEL_ID, modelInput=model_input, outputDataConfig={"s3OutputDataConfig": {"s3Uri": f"s3://{S3_DESTINATION_BUCKET}"}} ) invocation_arn = invocation["invocationArn"] s3_prefix = invocation_arn.split('/')[-1] s3_location = f"s3://{S3_DESTINATION_BUCKET}/{s3_prefix}" print(f"\nS3 URI: {s3_location}") while True: response = bedrock_runtime.get_async_invoke( invocationArn=invocation_arn ) status = response["status"] print(f"Status: {status}") if status != "InProgress": break time.sleep(SLEEP_TIME) if status == "Completed": print(f"\nVideo is ready at {s3_location}/output.mp4") else: print(f"\nVideo generation status: {status}") スクリプトを実行します。 ステータス: 進行中 . . . ステータス: 完了 s3://BUCKET/PREFIX/output.mp4 でビデオの準備ができました 数分後、スクリプトが完了し、 Amazon Simple Storage Service (Amazon S3) の出力場所が出力されます。 AWS コマンドラインインターフェイス (AWS CLI) を使用して出力ビデオをダウンロードします。 aws s3 cp s3://BUCKET/PREFIX/output.mp4 ./output-from-text.mp4 これが出来上がったビデオです。要求に応じて、カメラは被写体を拡大します。 Amazon Nova Reel を参考画像と共に使用する ビデオの作成をより適切に制御できるように、Amazon Nova Reel に次のような参照画像を提供できます。 このスクリプトは、参照画像とテキストプロンプトとカメラアクション（ 海岸の風景の上空を飛行するドローンビュー ）を使用してビデオを作成します。 import base64 import random import time import boto3 S3_DESTINATION_BUCKET = "<BUCKET>" AWS_REGION = "us-east-1" MODEL_ID = "amazon.nova-reel-v1:0" SLEEP_TIME = 30 input_image_path = "seascape.png" video_prompt = "海岸沿いの風景の上空を飛行するドローンビュー" bedrock_runtime = boto3.client("bedrock-runtime", region_name=AWS_REGION) # 入力画像を Base64 文字列としてロードします。 with open(input_image_path, "rb") as f: input_image_bytes = f.read() input_image_base64 = base64.b64encode(input_image_bytes).decode("utf-8") model_input = { "taskType": "TEXT_VIDEO", "textToVideoParams": { "text": video_prompt, "images": [{ "format": "png", "source": { "bytes": input_image_base64 } }] }, "videoGenerationConfig": { "durationSeconds": 6, "fps": 24, "dimension": "1280x720", "seed": random.randint(0, 2147483648) } } invocation = bedrock_runtime.start_async_invoke( modelId=MODEL_ID, modelInput=model_input, outputDataConfig={"s3OutputDataConfig": {"s3Uri": f"s3://{S3_DESTINATION_BUCKET}"}} ) invocation_arn = invocation["invocationArn"] s3_prefix = invocation_arn.split('/')[-1] s3_location = f"s3://{S3_DESTINATION_BUCKET}/{s3_prefix}" print(f"\nS3 URI: {s3_location}") while True: response = bedrock_runtime.get_async_invoke( invocationArn=invocation_arn ) status = response["status"] print(f"Status: {status}") if status != "InProgress": break time.sleep(SLEEP_TIME) if status == "Completed": print(f"\nVideo is ready at {s3_location}/output.mp4") else: print(f"\nVideo generation status: {status}") 繰り返しますが、AWS CLI を使用して出力をダウンロードします。 aws s3 cp s3://BUCKET/PREFIX/output.mp4 ./output-from-image.mp4 これが出来上がったビデオです。カメラは参照画像から開始し、前方に移動します。 責任ある AI の構築 Amazon Nova モデルは、モデル開発段階を通じてお客様の安全、セキュリティ、信頼に重点を置いて構築されています。これにより、お客様独自のユースケースを実現するための安心感と適切なレベルの制御が可能になります。 包括的な安全機能とコンテンツ管理機能が組み込まれているため、責任を持って AI を使用するために必要な制御が可能になります。生成されたすべての画像およびビデオには、デジタル透かしが含まれています。 Amazon Nova 基盤モデルは、その強化された機能に見合った保護機能を搭載して構築されています。Amazon Nova は、誤った情報、児童の性的虐待資料 (CSAM)、化学的、生物学的、放射線的、または原子力 (CBRN) のリスクの拡散に対抗するために安全対策を拡大しています。 知っておくべきこと Amazon Nova モデルは、米国東部 (バージニア北部) AWS リージョン の Amazon Bedrock でご利用いただけます。Amazon Nova Micro、Lite、Pro は、 クロスリージョン推論 により米国西部 (オレゴン) および米国東部 (オハイオ) リージョンでもご利用いただけます。 Amazon Bedrock では通常どおり、価格設定は従量課金制です。詳細については、 Amazon Bedrock の料金 をご覧ください。 新世代の Amazon Nova 理解モデルはあなたの言語を話します。これらのモデルは 200 以上の言語でコンテンツを理解して生成し、特に英語、ドイツ語、スペイン語、フランス語、イタリア語、日本語、韓国語、アラビア語、簡体字中国語、ロシア語、ヒンディー語、ポルトガル語、オランダ語、トルコ語、ヘブライ語で強力な機能を備えています。つまり、言語の壁を気にしたり、地域ごとに別々のモデルを維持したりすることなく、真にグローバルなアプリケーションを構築できるということです。クリエイティブコンテンツ生成用の Amazon Nova モデルは英語のプロンプトをサポートします。 Amazon Nova を試してみると、ますます複雑になるタスクを処理できることに気付くでしょう。これらのモデルを使用すると、最大 30 万トークンの長いドキュメントを処理したり、1 回のリクエストで複数の画像を分析したり、最大 30 分分のビデオコンテンツを理解したり、自然言語から大規模な画像やビデオを生成したりできます。そのため、これらのモデルは、迅速なカスタマーサービスインタラクションから、企業ドキュメントの詳細な分析や広告、e コマース、ソーシャルメディアアプリケーション用のアセット作成まで、さまざまなビジネスユースケースに適しています。 Amazon Bedrock との統合により、デプロイとスケーリングが簡単になります。 Amazon Bedrock ナレッジベース などの機能を活用して、独自の情報でモデルを強化したり、 Amazon Bedrock エージェント を使用して複雑なワークフローを自動化したり、 Amazon Bedrock Guardrails を実装して責任ある AI の使用を促進したりできます。このプラットフォームは、インタラクティブアプリケーションのリアルタイムストリーミング、大量のワークロードのバッチ処理、およびパフォーマンスの最適化に役立つ詳細な監視をサポートしています。 Amazon Nova で構築を開始する準備はできていますか? 今すぐ Amazon Bedrock コンソール で新しいモデルを試してみて、 Amazon Bedrock ドキュメント の Amazon Nova モデルセクションにアクセスして、 AWS re:Post for Amazon Bedrock にフィードバックを送ってください。 community.aws では、詳しい技術コンテンツを検索し、ビルダーコミュニティが Amazon Bedrock を使用する方法を見出すことができます。これらの新モデルで何を構築するのか教えてください! – Danilo 原文は こちら です。

こんにちは。 AWS パブリックセクター技術統括本部の押川です。 本ブログは、「詳細解説」シリーズの一つとして、標準準拠システムの AWS 上でのデータ連携について解説いたします。ぜひご検討の際に参考にしていただければと思います。 本ブログは以下の内容で構成されています。 庁内データ連携機能とは 2つの連携方式とデータ連携の要件 認証認可について AWS 上での実現方法 認証認可サーバーが必要な場合 認証認可サーバーが必要でない場合 異なる CSP またはオンプレミスとのファイル連携をする場合の認可を行う各方法のまとめ まとめ ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目については、 ガバメントクラウド活用のヒント『見積もりで注意すべきポイント』 をはじめとする「ガバメントクラウド活用のヒント」シリーズをご覧ください。 また、さらに詳細を知りたいという方には、 詳細解説：ガバメントクラウド名前解決編 をはじめとする「詳細解説」シリーズをお勧めしております。 庁内データ連携機能とは 標準準拠システムが、他の標準準拠システムにデータを送信又は他の標準準拠システムからデータを受信すること、庁内データ連携機能と言います。例えば、住民記録システムから介護保険システムに対して、住民基本情報を連携する場合などが該当します。 2つの連携方式とデータ連携の要件 連携方式としては、「RESTによる公開用API連携」（以降、「API連携」という。）と「ファイル連携」の２つの方式を規定しています。 API連携 API連携は、RESTful APIを使用してシステム間でデータをやり取りする方式です。提供側業務システムは REST による API を利用側業務システムへ公開し、利用側業務システムはその API を呼び出します。 ファイル連携 詳しい仕様についてはデジタル庁が提供している「 ファイル連携に関する詳細技術仕様書 」などをご覧ください。 重要な点についてまとめると、以下のようになります。 ストレージを使用してシステム間でデータをやり取りする方式です。 オブジェクトストレージを利用し CSV ファイルよる連携を行います。基本的に、提供側業務システムは、オブジェクトストレージが提供するツール（API等）を利用して、オブジェクトストレージ上の所定の格納先に CSV ファイルを格納します。それが困難な場合はファイルサーバーを構築して、 SFTP や SCP などによる暗号化を行なった上で CSV ファイルを格納することができます。 共通機能を提供する事業者はオブジェクトストレージ上に業務の組み合わせごとのバケットを作成し、そのバケットを利用してシステム間でのデータのやり取りを行います。バケットが業務の組み合わせごとに分かれているため、提供側業務システムは、利用側業務システム単位に別々の連携ファイルを作成します。 例えば、北海道札幌市において(市区町村コード=011002)、住民基本台帳(システム区分＋業務ID=0001)と印鑑登録(システム区分＋業務ID=0002)の業務の組み合わせのバケットを作成する場合、バケット名は「011002-0001-0002」とします。 異なるCSP間又はCSPとオンプレミス環境間でファイル連携を行う場合、API 連携で利用する認証認可サーバをIDプロバイダーとし、 CSPの認証認可機能と連携 (フェデレーション) させ、IDプロバイダーでオブジェクトストレージの認証を行う必要があります。 AWS 上では、オブジェクトストレージには Amazon S3 を用います。上述したように、Amazon S3 のバケットを業務の組み合わせごとに作成し、その中でフォルダ分けします。 認証認可について 詳しい仕様についてはデジタル庁が公開している「 地方公共団体情報システム　共通機能標準仕様書 」や「 「地方公共団体情報システム共通機能標準仕様書」に関するリファレンス 」などをご覧ください。 重要な点についてまとめると、以下のようになります client_secret_jwt による JWT を用いた認証を行います。それが難しい時のみ、API Key の利用を当面認めますが、ガバメントクラウドでは原則認められていません。 API 認可サーバーは自治体内で原則 1 つ用意します。ただし、以下に当てはまる場合などは必要ありません。 ファイル連携において連携元/連携先の業務システムがどちらもAWS上で稼働する場合 ファイル連携で認可サーバーを利用しない方法を使う場合 利用側業務システムが複数の提供側業務システムにアクセスする場合にも、提供側業務システムごとにアクセストークンを発行し、複数の提供側業務システムへアクセス可能なアクセストークンの発行は行いません。 AWS 上での実現方法 認証認可サーバーが必要な場合 API 連携を行う場合 API 連携における RESTful API は、 Amazon API Gateway などを用いて実現します。また、API 連携において必要になる認証認可機能については、Amazon Elastic Container Service (Amazon ECS) や Amazon Aurora を利用してサーバーを構築します。 それぞれの事業者には、以下の業務が発生します。 データ提供側の業務システム構築業者 OAuth 2.0のリソースサーバー側の実装 アクセストークン情報の取得 アクセストークンの検証 など 認証認可サーバーの構築業者 認証認可サーバーの実装 データの要求元・データの要求先にそれぞれクライア ントID/クライアントシー クレットを発⾏ データ利用側の業務システム構築業者 OAuth 2.0のクライアント側の実装 認証認可サーバからのアクセ ストークンの取得 アクセストークンを利⽤した データ要求先へのリクエスト発⾏ など ファイル連携で認証認可サーバーを構築する場合 ここでは、ファイル連携で認証認可サーバーを構築する場合について図を用いて説明します。 それぞれの事業者には、以下の業務が発生します。 共通機能の構築業者 IAM Role の作成 OAuth 2.0のリソースサーバー側の実装 アクセストークン情報の取得 アクセストークンの検証 など 認証認可サーバーの構築業者（共通機能の構築業者が兼任することも多い） 認証認可サーバーの実装 データ利用側にクライア ントID/クライアントシー クレットを発⾏ データ利用側の業務システム構築業者 OAuth 2.0のクライアント側の実装 認証認可サーバからのアクセストークンの取得 アクセストークンを利⽤した データ要求先へのリクエスト発⾏ など 認証認可サーバーが必要でない場合 AWS と異なるCSP間又は AWS とオンプレミス環境間でファイル連携を行う場合、認証認可サーバーを構築しない方法として以下の 2 つの方法があります。 AWS Transfer Family を用いて SFTP で暗号化して通信する オンプレミスや他 CSP で AWS IAM の機能を利用できるようにする（SSM Agent, IAM Role Anywhere） AWS Transfer Family を用いて SFTP で暗号化して通信する場合 上述のように、API によるファイルのアップロードやダウンロードが困難な場合はファイルサーバーを構築して、 SFTP や SCP などによる暗号化を行なった上でファイルを格納することができます。AWS Transfer Family というサービスによって、SFTP を用いて Amazon S3 にオブジェクトを格納・取り出せます。 データ提供側の業務システム構築業者 対象の S3 バケットをバックエンドにした Transfer Family のセットアップ データ要求元が作成した SSH キーを利用したユーザーの作成 ユーザーに対応する S3 へアクセス可能な IAM ロールの作成 データ利用側の業務システム構築業者 認証に利用する SSH キーの作成 オンプレミスや他 CSP で AWS IAM の機能を利用できるようにする場合 AWS の機能を利用し、オンプレミスや他CSPのサーバーへ IAM の権限を付与することができます。 SSM Agent を使う方法や、 IAM Role Anywhere を用いる方法があります。 ここでは、 SSM Agent を用いて、オンプレミスにあるデータ利用側の業務システムが、AWS 上にあるデータ提供側の業務システムのデータを利用する方法について図を用いて説明します。 まず、 AWSマネジメントコンソールのAWS Systems Managerのページにて、SSM Agentをインストールする際の有効化に必要なコードとIDを発行します。そして、作成した SSM Agent 用ロールをデータ利用側システム（オンプレミス）のサーバーが引き受けます。次に、 IAM STS を利用して、Amazon S3 にアクセスできるタスク実行用ロールの一時認証情報を取得します。最後に、取得した一時認証情報で Amazon S3 にアクセスします。 それぞれの事業者には、以下の業務が発生します。 データ提供側の業務システム構築業者 データ利用側の事業者の IAM ロールが引き受けることのできる、S3 へアクセスできる IAM ロールを作成 データ利用側の業務システム構築業者 オンプレミスのサーバが利用する IAM ロールの作成 データ提供側の事業者へS3 へのアクセスに利用する IAM ロールを通知 オンプレミスのサーバでIAMロールが利用できるよう SSM Agent の設定 異なる CSP またはオンプレミスとのファイル連携をする場合の認可を行う各方法のまとめ ここまででにあげた 3 つの方法について、表にまとめました。方法を選択する際の参考になさってください。   SSM Agent Transfer Family 認証認可サーバー 特徴 導入手順がシンプル SFTP の利用が可能 ID/Password認証が可能 標準仕様に記載された方法 API認可や職員認証で利用する認証認可サーバーがある場合は新規構築が不要 別CSPでも同様の方法が可能 考慮点 SSM Agent の導入やアップデートの工数 1000 台以上利用の場合は追加料金が発生 一時的な認証情報の利用はできない 200USD/月程度のコスト 認証認可サーバーの運用保守コスト OAuth 2.0 に準拠した API の実装コスト ユースケース コストを安く済ませたい場合 データ利用側・提供側のサーバーで SFTP を用いたい場合 API 認可や職員認証で認証認可サーバーを構築する場合 まとめ 本ブログでは、ガバメントクラウド上での標準準拠システムデータ連携について詳細をご紹介しました。重要なポイントとしては、AWS と異なるCSP間又は AWS とオンプレミス環境間でファイル連携を行う場合、複数の認可方法があるため、どのような業務が発生するかを把握して選択することが挙げられます。 地方公共団体に所属している方、または関連するベンダーパートナーの方でこのブログに関して追記した方がいいことやご不明点などございましたら、お気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へお気軽にご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介した 標準準拠システムデータ連携に関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

こんにちは。 AWS パブリックセクター技術統括本部の押川です。 ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目については、 ガバメントクラウド活用のヒント『見積もりで注意すべきポイント』 をはじめとする「ガバメントクラウド活用のヒント」シリーズをご覧ください。 また、さらに詳細を知りたいという方には、 詳細解説：ガバメントクラウド名前解決編 をはじめとする「詳細解説」シリーズをお勧めしております。 本ブログは、「ガバメントクラウド活用のヒント」シリーズの一つとして、ガバメントクラウド上に構築したシステムに対する運用保守経路についてご説明いたします。ぜひご検討の際に参考にしていただければと思います。 本ブログは以下の内容で構成されています。 運用保守経路としての Transit Gateway の利用 運用保守経路としての PrivateLink の利用 運用保守経路としての Systems Manager Session Manager の利用 補足: 複数のアカウントの EC2 で一度に同じコマンドを実行する 補足: サーバーの更新に必要なインターネットアクセスを運用保守アカウント越しに実現する 運用保守経路としてのTransit Gateway の利用 ガバメントクラウドの道案内『ASP＆運用管理補助者編』 の(4) 運用保守経路を確保する にもありますが、ガバメントクラウド上で構築した業務システムへの運用保守経路を構築する必要があります。自治体の基幹業務ではインターネット経由でシステムの運用保守を行うことができないため、閉域経由での運用保守経路を構築する必要がありますが、ここではベンダーが独自に専用線を利用してクラウドへの運用保守経路を構築する場合について記載します。 以下のように、事業者運用拠点から閉域を経由してガバメントクラウド上の本番アカウントに接続できるようにして、EC2 への SSH 接続やデータベースへのクエリの実行などの運用管理を行うことを可能にします。 この接続形式では、本番アカウントと事業者運用拠点は IP リーチャブルであり、双方向に通信が可能です。 この方法のメリットは、構築が簡単で、後述する AWS PrivateLink などのコストがかからないという点があります。 この方法のデメリットは、本番アカウントと事業者運用拠点が IP リーチャブルであることから、両者の IP アドレス範囲が重複しないように設計する必要があったり、ルートテーブルを管理する必要があるなどの点です。 一般的に、事業者運用拠点から複数の自治体の本番アカウントを保守しなければならず、そのすべての IP アドレス範囲と重複しないように事業者運用拠点を設計することは難しいため、後述するように AWS PrivateLink などで接続する方式が取られています。 運用保守経路としての PrivateLink の利用 先ほど述べた、事業者運用拠点と本番アカウントの IP アドレスが重複してしまうなどの問題を解決するために、AWS PrivateLink で本番アカウントの EC2 や RDS に接続することがあります。 事業者運用拠点から AWS PrivateLink の VPC エンドポイントに直接接続できますが、運用管理アカウントに踏み台サーバー (Amazon EC2) を設置する場合もあります。 AWS PrivateLink を利用すると、VPC エンドポイントの費用がかかります。接続したい対象の数だけ用意する必要があります。 参考として、 「AWS PrivateLink ワークショップ」 もご活用ください。 決まった数個の VPC エンドポイントのみで Amazon EC2 に接続することができるようになるのが、次の方法です。 踏み台サーバーを Systems Manager に代替する AWS Systems Manager には、Session Manager という機能があり、SSH のポートを解放しなくても Amazon EC2 にログインして操作を行うことができます。 マネジメントコンソールからの利用が一般的ですが、ガバメントクラウドでは、マネジメントコンソールへアクセスするために払い出されるユーザーからは Session Manager を利用することができません。しかし、運用管理アカウント経由など、本番アカウントのマネジメントコンソールを介さなければ Session Manager を利用することができます。 閉域から Session Manager を利用するには、AWS CLI の以下のようなコマンドを実行します。 aws ssm start-session --target instance-id この場合、運用管理アカウントと本番アカウントに、 Session Manager を利用するために必要な数個のエンドポイントを設置するだけで本番 EC2 へのログインが可能になります。 Session Manager を利用するために必要な VPC エンドポイントについては、 こちらのドキュメント をご覧ください。 AWS Systems Manager Session Manager では EC2 にしかアクセスできないので、例えば RDS に SSH ログインをしてクエリを実行するなどの保守作業を行いたいといったようなケースでは、踏み台サーバーが必要になります。 補足:複数のアカウントの EC2 で一度に同じコマンドを実行する メンテナンスなどで、複数の EC2 で同時にコマンドを実行したい場合、 AWS Systems Manager Automation を使えます。 各本番アカウントで定義された実行権限のあるロールに運用管理アカウントから AssumeRole してアクションを実行します。この場合、どのようなコマンドを実行するかなどのアクションを管理する Runbook は運用管理アカウント内で一括管理できます。 補足: サーバーの更新に必要なインターネットアクセスを運用保守アカウント越しに実現する 運用保守作業とは少し違いますが、サーバーの更新などで本番サーバーからインターネットに接続する必要がある場合のインターネットへの経路の設定についても補足しておきます。 ガバメントクラウド上では、ネットワーク分離の考え方から インターネットゲートウェイを設置することが制限されています。そのため、サーバーの更新などで本番サーバーからインターネットに接続する必要がある場合は、運用保守アカウントに NAT ゲートウェイ・インターネットゲートウェイを設置し、そこへの経路を設置する必要があります。 この場合、本番アカウントからインターネットゲートウェイが IP リーチャブルではない方がセキュアですので、途中に AWS PrivateLink を挟みます。そして、その到達先として Amazon EC2 を設置し、そのサーバーを経由して NAT ゲートウェイ・インターネットゲートウェイにアクセスするようにします。 まとめ 本ブログでは、ガバメントクラウド上での運用保守経路について詳細をご紹介しました。複数のパターンのメリットとデメリットを把握し、適切な運用保守経路を構築することが必要です。 地方公共団体に所属している方、または関連するベンダーパートナーの方でこのブログに関して追記した方がいいことやご不明点などございましたら、お気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へお気軽にご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介した 標準準拠システムデータ連携に関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

本ブログは、三協立山株式会社と Amazon Web Services Japan が共同で執筆しました。 三協立山株式会社 は ビル・住宅・エクステリア建材の開発・生産・販売までを一貫して手がけるほか、アルミやマグネシウム合金の鋳造・押出・加工や販売を行っています。商業施設向けの陳列棚やショーケース、屋外看板などを提供し、メンテナンスも担っています。本ブログでは三協立山が開発した社内向けサービス 「AI ふたば」 の概要とその中でどのように Amazon Bedrock が活用されているかを紹介します。 　 課題と背景 三協立山では 2023 年 6 月に社長より生成 AI の積極的活用方針が示され、特に生産性向上を目指した取り組みを優先的に始めることになりました。 生成 AI の導入に向けて、社内ルールやガイドラインの整備、E-ラーニングの作成など、社員限定での利用環境の整備を進めていき初期バージョンの「AI ふたば」をリリースしました。この時点では Amazon Bedrock は 採用しておらず、他社の LLM を使って実装していました。しかし、実際の運用においていくつかの課題が浮き彫りとなってきました。 主な課題として以下が挙げられます： 文字数制限による議事録の自動作成への活用の難しさ 業務での具体的な活用シーンの不明確さ 自社情報の活用ニーズ（過去の資料検索の非効率性）への対応 また、プログラミングや文書作成業務に従事する一部のヘビーユーザーを除き、全社的な活用は進んでいない状況でした。社内情報を活用した RAG（Retrieval-Augmented Generation）の自社開発も試みましたが、実装の困難さに直面していました。これらの課題に対し、より実用的で効果的な生成 AI 活用の仕組みづくりが求められていました。 ソリューションの概要 そのような課題がある状況で AWS より Generative AI Use cases JP (以下、GenU) をご提案しました。CDK や React の経験が全くなく不安もあったそうですが、開発メンバーの川崎さんは「AWS はほぼ初心者で CDK も今回初めて存在を知ったくらいですが、Readme ファイルなども充実しており、想像以上に簡単に始めることが出来ました。」さらに「コーディングで分からないところは AI ふたば自身で確認をしながら進められ、ローカル環境で動かして画面を確認しながら修正ができるので敷居が低かった。議事録の文字起こし機能のバックエンド部分を非同期処理で実装することもできました。」と語っています。 また、GenU が元々持っていたプロンプトテンプレートを自社向けにカスタマイズし、業務での具体的な活用シーンに即して 50 パターンほど用意しています。 図 1 : AI ふたばの画面イメージ 自社データの活用については、GenU に含まれている Amazon Kendra を活用した RAG を採用しました。商品情報では「X.スタイル」と「クロス.スタイル」など言葉の揺らぎに対してはプロンプトやファイルの置き方を工夫したり、メタデータを活用して、検索精度を高めることに成功しました。また Amazon Bedrock にはない外部の LLM も利用できるようにカスタマイズを行っており、エンドユーザーに多くの選択肢を提供するように工夫しています。 以下の図 2 がAI ふたばのアーキテクチャーの概要になります。 図 2 : AI ふたばのシステム構成 導入効果と今後の展開 GenU をベースとしてカスタマイズをしたことで、AI ふたば Ver2 はたった１か月でリリースすることができました。Ver2 での議事録作成機能の追加やプロンプトテンプレートでユースケースを提示したことで社内の利用者は 1.5 ～ 2 倍程度拡大しました。また当初から要望の多かった議事録作成機能をリリース出来たことで年間で 1 万 5000 時間の業務時間削減効果が見込まれています。 川崎さんは「AWS は初心者で、しかも OSS として公開されている GenU をベースにして開発するという体験は、今までの既存アプリのバージョンアップ中心だった業務から、世の中の動きを知るきっかけになりました。IaC である CDK も初めて使いましたが、あまりの便利さにこれから他の開発でも CDK を使ってみようと思います。」と語っています。同じく開発メンバーの船場さんは「生成 AI も Amazon Bedrock を利用することで非常に簡単に実装できるということが 分かりました。」と語っています。 GenU はアプリケーションのソースコードはもちろん、AWS の各種サービスもビルディングブロックで組み合わされたものを CDK　の形で OSS として公開しています。そのままお使い頂くこともできますが、今回の事例のようにカスタマイズして使う事もできるようになっているのが特徴です。 情報システム統括室システム企画開発部の高畑部長は、「若手のメンバーが面白がって取り組んでくれた。GenU をベースにしながらも、Ver1 の見た目に寄せるようカスタマイズしたことでエンドユーザにとっても違和感なく展開することができました。」と語っています。 　 今後の展開としては以下のようなことを検討しています。 議事録機能の更なる改善 エージェント機能の追加 Amazon Kendra へのファイル連携機能の効率化 まとめ 本ブログでは 三協立山で導入した AI アシスタントサービスの紹介とその中で Amazon Bedrock や GenU がどのように活用されているかを紹介しました。 Amazon Bedrock を利用することによってみなさまの AWS 上のワークロードに生成 AI を活用した機能を容易に組み込めます。本ブログが生成 AI を活用されている皆様の参考になりましたら幸いです。 本ブログは、三協立山 株式会社と AWS のソリューションアーキテクトの水野が共同で執筆いたしました。 三協立山ショールームにて撮影 左から 情報システム統括室システム企画開発部 高畑 裕紀 部長 情報システム統括室システム企画開発部企画開発一課 船場 和馬 改革推進統括室デジタル改革推進部デジタル改革推進グループ 川上 貞昭 グループ長 情報システム統括室システム企画開発部企画開発一課 川崎 翔平 副主任 情報システム統括室システム企画開発部企画開発一課 阿閉 清紀 課長 著者について 水野 貴博 水野貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは AWS Supply Chain です。趣味は、ドラマや映画のエキストラに参加することです。

ビジネス上の重要な処理に SAP システムを利用している企業は、高い可用性とパフォーマンスを求められるため、オブザーバビリティ戦略は運用の効率化に欠かせない重要な要素となります。 SAP HANA、SAP Business Suite on HANA、または SAP S/4HANA などのソリューションを実行する大規模な SAP 環境を持つ企業は、これらの環境に複数のモニタリングオプションがあります。SAP Solution Manager、Amazon CloudWatch Application Insights などのソリューションは、一般的にシステムの正常性とパフォーマンスを監視するために使用されます。しかし、エンタープライズのモニタリング戦略を見ると、SAP と非 SAP ソリューションを組み合わせ、さらにマルチクラウド構成にすることで、可視化やアラートを単一の画面上で表示するダッシュボードを実現し、長期的なアーキテクチャを最適化します。Prometheus や Grafana などのツールは、SAP と非 SAP 環境を組み合わせたシステム監視のセットアップを実現するため、SAP と Amazon のマネージドオファリング (Amazon Managed Prometheus (AMP) と Amazon Managed Grafana (AMG)) を使用する組織でも既に使用されており、クラウドネイティブ技術を提供します。 SAP のお客様も、RISE with SAP で AWS を選択することが増えています。RISE に移行していないお客様のために、この解決策により、SAP ワークロードの監視能力が向上します。このブログでは、 AWS Well-Architected Framework の SAP Lens のベストプラクティスに従って AMP と AMG を構成することで、SLES (SUSE Linux Enterprise Server) OS と SAP S/4HANA の監視ダッシュボードのセットアップ方法を学びます。 セットアップが完了すると、オペレーティングシステム、SAP アプリケーションサーバー、SAP 高可用性クラスターの各コンポーネントについて、複数のダッシュボードにまたがって SAP 環境全体の正常性を確認できます。 定義 このブログで使用する用語を定義しましょう。 オブザーバビリティ : オブザーバビリティ（可観測性）とは、システムの状態や性能を把握するための仕組みを指します。具体的には、システムの状態を示すメトリクス（指標）、ログ、トレースを用いて分析します。システムのパフォーマンスを理解することは、運用の優秀性を達成し、ビジネス目標を満たすための鍵となります。 「監視」という用語は時にオブザーバビリティとは異なると定義されますが、しかし監視はトレースやログ収集などの活動と並んで、システムを観測可能にする活動です。 Amazon Managed Prometheus (AMP) : AMP はメトリクスのためのサーバーレス、Prometheus 互換のモニタリングサービスで、大規模なコンテナ環境をセキュアに監視することを簡単にします。AMP を使えば、お客様は今日使っているオープンソースの Prometheus データモデルとクエリ言語を使って、ワークロードのパフォーマンスを監視できます。また、基盤となるインフラストラクチャを管理する必要がなく、スケーラビリティ、可用性、セキュリティの向上もあります。 Amazon Managed Grafana (AMG) : AMG は、完全にマネージドされ、セキュリティが確保されたデータ可視化サービスで、顧客はさまざまなデータソースから運用状況のデータを素早く照会、関連付け、視覚化できます。AMG は、拡張可能なデータサポートで広く利用されているデータ可視化ツール Grafana を簡単にデプロイ、運用、スケーリングできるようにしています。 前提条件 前提条件として、高可用性の有無にかかわらず、AWS アカウント内に SAP システムをセットアップする必要があります。設定を行うユーザーアカウントには、AWS IAM でロールを割り当てる権限が必要です。このブログでは、SAP S/4HANA システム (ASCS/ERS と SAP HANA DB クラスターおよび 2 つのアプリケーションサーバー) を、SLES for SAP 15 SP4 オペレーティングシステム上で動作させています。 アーキテクチャ まずはこのソリューションの基本的なアーキテクチャを理解しましょう。図 1 は AWS 上で SAP S/4HANA を高可用性 (HA) 構成にした典型的なアーキテクチャを、図 2 はオブザーバビリティのアーキテクチャを示しています。 すべての SAP システムは SAP 認定 Amazon EC2 インスタンス上にインストールされ、データの移動は全て VPC エンドポイントを経由します。 図 1: AWS 上の SAP S/4HANA 高可用性 (HA) アーキテクチャの表現 図 2: Amazon Managed Prometheus (AMP) と Amazon Managed Grafana (AMG) を使用した SAP の可観測性アーキテクチャ 設定と構成 図 3 の下に示すように、ソリューションを構成する手順は以下の通りです。 図 3: AMP を使用した SAP の監視構成と AMG での可視化のためのステップ AMP ワークスペースの作成と設定 データは AMP Workspace に「リモートライト」方式で取り込まれ、AMG のダッシュボードのデータソースとして使用されます。 ユーザー ID に Amazon Managed Service for Prometheus (AMP) コンソールから「Create workspace (ワークスペースの作成)」を選択する権限があることを確認し、図 4 に示すようにしてください。 図 4: AMP ワークスペースの作成 AMP でワークスペースが作成されると、サービスがリモート書き込み URL (図 5 に示されている) を提供します。後のセクションの構成手順でこの URL が必要になるので、 リモート書き込み URL を控えておいてください。 図 5: AMP ワークスペースエンドポイントの詳細例 EC2 IAM から AMP にメトリクスをストリーミングする AmazonPrometheusRemoteWriteAccess AWS 管理ポリシー を使用して、Amazon EC2 インスタンスの IAM ロールを作成します。このロールを EC2 インスタンスに割り当てるか、この新しく作成したロールで EC2 インスタンスを起動するか、または既存のロール ( AWS ドキュメント の図 6 のように) に AmazonPrometheusRemoteWriteAccess ポリシーを割り当てることができます。 図 6: AMP ポリシー名 VPC エンドポイント EC2 インスタンスから AWS バックボーンネットワークを経由して AMP にメトリクスをプライベートに送信するために、AMP 用の VPC エンドポイントを設定する必要があります。 VPC エンドポイントにより、VPC 内のリソース (この場合は EC2 インスタンス) から管理型サービスに安全にアクセスできるようになります。 次に、以下の手順で AMP の VPC インターフェイスエンドポイントを作成します: AWS コンソールから、VPC サービスの「Endpoints」を選択し、図 7 のように「Amazon WorkSpaces」サービスを選択します。 図 7: AMP 用の AWS VPC エンドポイントサービス名 VPC 内のリソースがこれらのインターフェイスエンドポイントに HTTPS で通信を行えるように、VPC 内のセキュリティグループを変更する必要がある場合もあります。インターフェイスエンドポイントの作成方法の詳しい手順は、 AWS ドキュメント で確認できます。 さらに、VPC から直接インターネットにアクセスできない場合は、図 8 に示すように、sigv4 がエンドポイントを介して機能できるよう、AWS Security Token Service 用のインターフェイス VPC エンドポイントも作成する必要があります。 図 8: AWS Security Token Service の VPC エンドポイントサービス名 Metrics Exporters と Prometheus の EC2 インスタンスへのインストールと設定 この手順では、EC2 インスタンス上に必要なエクスポーターと Prometheus エージェントをインストールする方法を学びます。 Prometheus のエクスポーターは、システムからメトリクスを収集し、Prometheus で読み取り可能にする役割を果たします。 Prometheus のエージェントは、メトリクスをエンドポイントに転送する役割を果たします。 各 SAP アーキテクチャコンポーネントのエクスポーターのリストは表 1 にまとめられています。 さらに、すべての EC2 インスタンスで Prometheus エージェントのインストールが必要で、そのことでデータを AMP に転送できるようになります。 SAP システムロール エクスポーター名 詳細情報の URL SAP ASCS/ERS クラスター ClusterLabs ha_cluster_exporter Prometheus node_exporter https://github.com/ClusterLabs/ha_cluster_exporter https://github.com/prometheus/node_exporter SAP アプリケーションサーバー SUSE sap_host_exporter Prometheus node_exporter https://github.com/SUSE/sap_host_exporter https://github.com/prometheus/node_exporter 表 1: SAP 各コンポーネントで EC2 にインストールするエクスポーターのリスト 2.1 Node Exporter Prometheus Node Exporter は、ハードウェアやカーネルに関する様々なメトリクスを公開し、それらのメトリクスを使って EC2 のヘルスステータスをダッシュボードで表示できます。 EC2 インスタンス上で node exporter をインストールして実行する手順は次のとおりです。( Prometheus のウェブサイト にも記載があります)。 Linux (SLES) オペレーティングシステムを実行している EC2 インスタンスで node exporter をインストール、展開、実行するには、以下のコマンドを実行してください。は node exporter のバージョン、-は OS のアーキテクチャに置き換えてください。 ダウンロードできる Node exporter パッケージは Prometheus のウェブサイト で確認できます。 wget https://github.com/prometheus/node_exporter/releases/download/v/node_exporter-.-.tar.gz tar xvfz node_exporter-*.*-amd64.tar.gz cd node_exporter-*.*-amd64 ./node_exporter Node Exporter はお好みのディレクトリ(例: /usr/local/bin)にインストールできます。実行すると、Node Exporter はローカルサーバーの 9100 番ポートの /metrics エンドポイントでメトリクスを公開します。 次の curl コマンドを実行して、9100 /metrics エンドポイントでメトリクスがエクスポートされていることを確認できます。 curl http://localhost:9100/metrics コマンドの出力は次のようになります: # HELP node_cpu_seconds_total Seconds the CPUs spent in each mode. # TYPE node_cpu_seconds_total counter node_cpu_seconds_total { cpu ="0",mode ="idle"} 6.8382833e + 06 node_cpu_seconds_total { cpu ="0",mode ="iowait"} 824.38 node_cpu_seconds_total { cpu ="0",mode ="irq"} 0 # その他の設定など この手順を完了すると、SAP の役割に関係なく、すべての SAP EC2 インスタンスに node exporter がインストールされます。 2.2 ASCS/ERS EC2 インスタンスでの HA クラスターエクスポーター Clusterlabs HA Cluster Exporter はステートレス HTTP エンドポイントです。 各 HTTP リクエストで、さまざまなクラスタコンポーネントのツールによって提供される既存の分散データを解析することで、クラスタの状況をローカルで検査します。 エクスポートされるデータには、次のような情報が含まれます。 ペースメーカークラスタの概要、ノードとリソースの統計情報 Corosync の通信リングのエラーとクォーラム投票 DRBD リソースなど 高可用性 SAP システムの設定では、corosync、pacemaker、フェイルオーバーの状態などのサービスの状況を把握することで、システムをよりよく理解し、障害の根本原因を特定するのに役立ちます。 ASCS と ERS の両方の EC2 インスタンスで、root ユーザーまたは sudo 権限を持つユーザーとしてエクスポーターパッケージをインストールして実行してください。 zypper install prometheus-ha_cluster_exporter ./ha_cluster_exporter HA Cluster Exporter を実行すると、デフォルトでポート 9664 の /metrics パスの下にメトリクスがエクスポートされます。 ホスト上で実行中の /usr/bin/ha_cluster_exporter プロセスを確認すれば、HA クラスタのプロセスの状態を確認できます。 2.3 アプリケーションサーバーインスタンス上の SAP ホストエクスポーター SAP Host Exporter はステートレスの HTTP エンドポイントです。 各 HTTP リクエストでは、SAPControl Web インターフェイスを介して SAP システムからランタイムデータを取得します。 エクスポートされたデータには、以下のような情報が含まれます: サービスプロセスを起動する サーバー統計を (統計情報を)キューに登録する SAP アプリケーションサーバー ディスパッチャーのワークプロセスキュー統計 sap_host_exporter をインストールするには、以下のコマンドを使用してください。 export DISTRO = SLE_15_SP4 # 自身の OS のバージョンに合わせて変更してください zypper addrepo https://download.opensuse.org/repositories/server:/monitoring/$ DISTRO/server:monitoring.repo zypper install prometheus-sap_host_exporter インストール後は、次のように exporter を実行し、図 9 に示されているように、Unix ドメインソケットを経由して SAPControl Web サービスに接続できます。 ./sap_host_exporter — sap-control-uds /tmp/.sapstream51213 図 9: SLES でプロセスとして実行されている sap_host_exporter サービス これにより、デフォルトでポート 9680 の /metrics パスでメトリクスを公開します。 SAP アプリケーションサーバーが実行中の SAP EC2 インスタンスで SAP ホストエクスポーターをインストールするには、これらの手順を実行してください。 2.4 Prometheus エージェント Prometheus は EC2 インスタンスからデータを収集し、AMP に保存します。したがって、このステップでは、リソースの使用量が少ない Prometheus のエージェントモードをインストールします。Prometheus に同梱されている UI 機能やアラート機能は必要ありません。また、AMP へのリモートライトを設定します。 Prometheus サーバーは任意のディレクトリにインストールできます。例えば /usr/bin です。この例では、以下のコマンドで示したように、SLES for SAP 15 SP4 オペレーティングシステムに Prometheus v2.49.1 をインストールします。 Prometheus がインストールされたディレクトリに移動します。 wget https://github.com/prometheus/prometheus/releases/download/v2.49.1/prometheus-2.49.1.linux-amd64.tar.gz tar xvfz prometheus-*.tar.gz cd prometheus-* Prometheus のインストールディレクトリ内に、YAML 形式で記述された設定ファイル prometheus.yml があります。ファイルの中身は次のようになっています。 # グローバル設定 global: scrape_interval: 15s # スクレイプ間隔を 15 秒に設定します。デフォルトは 1 分です。 evaluation_interval: 15s # 15 秒ごとにルールを評価します。デフォルトは 1 分です。 # scrape_timeout はグローバルのデフォルト (10 秒) が設定されています。 # Load rules once and periodically evaluate them according to the global 'evaluation_interval'. rule_files: # - "first_rules.yml" # - "second_rules.yml" # 1 つのエンドポイントのみをスクレイピングする構成: # ここでは Prometheus そのものです。 scrape_configs: # ジョブ名がラベル `job =` として、この構成からスクレイピングされた全てのタイムシリーズに追加されます。 - job_name: "EC1-CS" # metrics_path はデフォルトで '/metrics' に設定されます # scheme はデフォルトで 'http' に設定されます。 static_configs: - targets: ['localhost:9664','localhost:9100'] remote_write: - url: https://aps-workspaces.us-east-1.amazonaws.com/workspaces//api/v1/remote_write sigv4: region: queue_config: max_samples_per_send: 1000 max_shards: 200 capacity: 2500 私たちのユースケースに合わせるために、 prometheus.yml ファイルで次の変更を行う必要があります: job_name を、観測性ダッシュボード上でこのシステムを識別できるような名前に変更してください。例えば、SAP Application Server EC2 インスタンスについては「SAP S41 App Server」、SAP 中央サービス EC2 インスタンスについては「S41 ASCS/ERS」などです。 targets の : 設定を変更します。ホストは Exporter が実行されているホストを、ポートは Exporter がメトリクスを公開しているポートを指定します (例: localhost:9100)。上記のように、複数のターゲットを設定できます。例えば、SAP Application Server EC2 インスタンスの yml ファイルの設定では、SAP Host Exporter と Node Exporter からメトリクスをスクレイピングするために、’localhost:9680′ と ‘localhost:9100’ の 2 つのターゲットエントリがあります。 yml ファイルの最後に remote_write URL セクションを追加します。remote_write URL は、ステップ 1 で AMP 作成時に控えた URL に、AWS リージョン (例: us-east-1) を指定して変更してください。 prometheus.yml ファイルを更新したら、以下のコマンドを実行してエージェントモードで Prometheus を実行します。 ./prometheus --config.file =./prometheus.yml --enable-feature = agent & 各 SAP コンポーネントの正しいポートを特定し、すべての EC2 インスタンスでこれらの手順を実行してください。 このタイミングで、データが AMP に送信されており、Amazon Managed Grafana の構成が可能になりました。 Prometheus Agent Mode エージェントモードでは、リモートライトユースケースに最適化されています。クエリ、アラーティング、ローカルストレージが無効化され、カスタマイズされたタイムシリーズデータベースのライトアヘッドログに置き換えられます。その他の機能(スクレイピングロジック、サービスディスカバリ、関連設定) は同じままです。 エクスポーターを systemd サービスとして有効化する これらのエクスポーターやエージェントを起動時に自動起動するように設定することをお勧めします。これは systemctl を使って行うことができます。以下が HA クラスターの例です。 systemctl --now enable prometheus-ha_cluster_exporters 他のサービスについても同じように設定できます。 systemctl についての詳細は、 SUSE のドキュメント を参照してください。 AMG の設定と監視ダッシュボードのセットアップ AMG は、可視化ツールの人気製品である Grafana のフルマネージドサービスで、Amazon Managed Prometheus と連携することで、メトリクス、ログ、トレースに対するクエリ、可視化、アラートを行えるようになります。 この項では、Amazon Managed Grafana (AMG) の構成方法と SAP S/4HANA の監視ダッシュボードのセットアップ方法について説明します。 この項に記載されている手順は、Amazon Managed Service for Prometheus (AMP) サービスで収集された SAP のメトリクスに対する監視ダッシュボードをセットアップするために必要な AMG サービスの構成手順を示しています。 3.1 Amazon Grafana でワークスペースを作成する Amazon Managed Grafana において Amazon Managed Prometheus をデータソースとして、新しいワークスペースを作成しましょう。Amazon Managed Grafana におけるワークスペースは、Grafana サーバーの論理的なユニットです。 AWS コンソールから Amazon Grafana サービスを開き、図 10 のように希望のエイリアスでワークスペースを作成します AWS IAM Identity Center(ID センター) と SAML の間から、好みの認証アクセス方法を選んでください オプションですが、推奨されるのは、SAP VPC 内のデータソースに接続する場合、ワークスペースから SAP VPC への VPC 接続を選択すること (これにより、パブリックインターネット経由のリクエストを回避できます) Service Managed と Customer Managed の間から、権限管理方式を選んでください 最後に、図 11 に示されているように、Data Sources のリストから Amazon Managed Prometheus をデータソース名として選択します 図 10: AMG ワークスペースエイリアス 図 11: AMG のデータソース名 数分かかりますが、この段階で Grafana ワークスペースの準備が整いました。 3.2 Amazon Grafana ワークスペースを構成する AMG でワークスペースの作成が完了したら、次は Amazon Managed Service for Prometheus (AMP) との統合です。ステップには Grafana ワークスペースコンソールでの管理者権限によるユーザー作成、Grafana ワークスペースコンソールでの AMP データソースの構成、Grafana ワークスペースコンソールへの監視用ダッシュボードのインポートが含まれます。 AMG では、Grafana コンソールへのアクセスの認証基盤として、AWS IAM Identity Center と SAML を認証基盤として利用できます。AMG ワークスペースのアクセスと Grafana ワークスペースコンソールの設定には、管理者ユーザーを設定する必要があります。ユーザーは AWS IAM Identity Center または外部の ID プロバイダに設定できます。この記事では、AWS IAM Identity Center にユーザーを設定しました。AWS IAM Identity Center に設定されたユーザーには、 AWSGrafanaAccountAdministrator と AWSSSODirectoryAdministrator のポリシーが必要です ( こちら を参照)。オプションのロールを確認し、必要に応じて割り当ててください。ワークスペースへのアクセスの認証方式として SAML を選択した場合は、記載された手順に従ってください。 ユーザーの作成後、Amazon Managed Grafana (AMG) ワークスペースにユーザーを割り当て、Grafana コンソールを設定するユーザーに対して「管理者権限を付与する」アクションを実行します。実行するには、AWS コンソールから AMG を開き、「すべてのワークスペース」をクリックし、新しく作成したワークスペースをクリックします。認証タブ内で、AWS Identity Center でユーザーまたはグループを追加するか、SAML 設定を行います。ユーザーが追加されたら、そのユーザーを選択し、アクションロップダウンから「管理者権限を付与する」を選択します (図 12 参照)。この手順を完了すると、管理者権限を付与したユーザーは、このワークスペースの Grafana コンソールを管理者として利用できるようになります。 図 12: AMG 用の AWS IAM Identity Center ユーザー Grafana ビューアユーザー ダッシュボードの作成には Admin ユーザーのみを使用し、ダッシュボードの表示にはセキュリティおよびコスト最適化の観点から「ビューア」ユーザーの使用を推奨します。 Grafana ワークスペースコンソールの URL を取得します。これを行うには、AWS コンソール内の Amazon Grafana サービスを開き、 全てのワークスペース をクリックし、新しく作成したワークスペースに関連付けられているワークスペース URL を見つけてください。図 13 のように表示されます。 図 13: Grafana ワークスペース URL の例 前のステップで管理者として構成したユーザー認証情報を使って、ワークスペース URL にアクセスし、AMG ワークスペースコンソールにログインします Grafana ワークスペースコンソールにログインした後、「アプリ」->「AWS データソース」->「データソース」の順に選択し、Amazon Managed Service for Prometheus の中からステップ 1 で作成した Amazon Managed Prometheus ワークスペースをメトリクス収集用に選択します (図 14 の通り)。 図 14: Grafana ワークスペースのデータソース設定 Amazon Managed Prometheus ワークスペースをデータソースとして正常に追加できると、Administration -> Data sources タブに設定済みのデータソースとして表示されます (図 15 参照)。 図 15: AMG のデータソースとして AMP 3.3 SAP レポートをインポート Grafana のダッシュボードは JSON 形式のレポートを使って作成できます。独自のレポートを作成するか、Grafana で提供されているレポートをインポートすることができます。このブログでは、インポートオプションを使用しており、使用するレポートは以下の通りです。 Node Exporter を使用した OS レベルのデータ (ID 1860) ASCS/ERS 上で Pacemaker を実行している HA クラスター (ID 12229) SAP Application Server (ID 12761) AMG ワークスペースコンソールにログインし、ダッシュボードタブに移動します。図 16 のように、JSON レポートをアップロードするか、Grafana.com のレポート ID でインポートして、レポートをインポートしてください。 図 16: JSON アップロードまたは Grafana.com のダッシュボード ID を使用してダッシュボードをインポートする すべてのレポートを追加した後、次のような画面が表示されます: 図 17: OS レベルのメトリクスダッシュボード 図 18: SAP ASCS/ERS HA クラスターダッシュボード 図 19: ノードがダウンしたときのマルチクラスター概要ダッシュボード 図 20: SAP アプリケーションサーバーのステータスとプロセス概要ダッシュボード 図 21: SAP アプリケーションサーバーディスパッチャーキューダッシュボード 図 17: OS レベルのメトリクスダッシュボード 図 18: SAP ASCS/ERS HA クラスターのダッシュボード 図 19: ノードがダウンしている場合のマルチクラスター概要ダッシュボード 図 20: SAP アプリケーションサーバーのステータスとプロセス概要ダッシュボード 図 21: SAP Application Server ディスパッチャーキュー ダッシュボード AMG データソースとマルチクラウドダッシュボード 設定手順と図 22 に示されているように、Amazon CloudWatch、Amazon Athena などの他のデータソースを指定できます。これにより、SAP 以外のシステムだけでなく、ハイブリッドおよびマルチクラウド環境のダッシュボード化が可能になります。 図 22: AMG のデータソース 結論 Prometheus と Grafana は、SAP ランドスケープを監視・可視化するための強力なオープンソースツールです。 AWS での AMP と AMG の利用により、組織はよりよい自動化とセキュリティポスチャを得ることができます。 SAP の可観測性ダッシュボードを構築するための AMP と AMG を使用することで、Prometheus と Grafana のデプロイやインフラストラクチャの管理、定期的なソフトウェアアップデートの実施などの負担なく、一元的に可観測性ダッシュボードを確認できます。 この記事では、Amazon Managed Prometheus と Amazon Managed Grafana を使用して、SAP S/4HANA システムの SAP 監視ダッシュボードをセットアップする方法について説明しました。 また、Grafana の他のデータソースを使用して、非 SAP システムを組み込む方法についても説明しました。 AMG、ダッシュボードの種類、セキュリティ機能の詳細については、 AWS ドキュメンテーション を確認してください。 翻訳は Partner SA 松本が担当しました。原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 あけましておめでとうございます。本年も週刊生成AI with AWSと、週刊AWSをよろしくお願いいたします。今年も最新情報をギュッとまとめてお届けしますので、引き続きご期待くださいね。 それでは、12 月 23 日週と 30 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: アオラナウ株式会社、AWSのGenUを活用した社内RAGシステムで技術調査業務の効率化を実現 アオラナウ株式会社様はServiceNowの価値を最大化することに取り組んでいます。50名を超える従業員には、技術的な熟練度が高いメンバーと未経験のメンバーが混在しており、それぞれ情報検索や個人が抱える課題の解決に時間を要する、同僚への質問を躊躇してしまうという課題がありました。これを解決するために Generative AI Use Cases JP(GenU) を活用し、高度なRAGシステムを短期間・低コストで構築することに成功しました。これによってドキュメント検索時間が1/5に、未経験メンバーから熟練メンバーへの質問件数の減少、質問自体の質の向上という成果を上げています。 ブログ記事「個性的なモデルに出会える Amazon Bedrock Marketplace で基盤モデルの選択肢を増やそう」を公開 世の中には様々な生成AIモデルがあります。AWS re:Invent 2024ではAmazon Bedrock Marketplaceが発表され、100以上のモデルをAmazon SageMakerにデプロイし、BedrockのAPIでアクセスすることが可能になりました。これによってBedrockで選択できるモデルではカバーできない、特徴をもったモデルを利用したくなった場合にも、アプリケーションの変更を最小限に抑えて最適なモデルを活用しやすくなります。この記事では、Amazon Bedrock Marketplaceの使い方や、日本発のモデルについて紹介しています。 ブログ記事「Stable Diffusion 3.5 Large が Amazon Bedrock でご利用いただけるようになりました」を公開 Amazon BedrockでStable Diffusion 3.5 Largeが利用できるようになりましたので、その深掘り記事を公開しました。 ブログ記事「Amazon Bedrock アプリケーションで責任ある AI のコアディメンションに対応するための考慮事項」を公開 責任あるAI活用の考え方は、生成AIの活用において重要度が高いテーマです。この記事は英語版の翻訳ですが、「責任あるAI」に含まれる概念を整理し、Amazon Bedrockでどのようにそれを実現していくかを説明しています。安全なAI活用のために、なにから始めればいいのか悩んでいる方におすすめの記事です。（大作なので徐々に読み進めるのも良いアイデアです） サービスアップデート Amazon Bedrock Agents, Flows, Knowledge Basesがレイテンシ最適化モデルに対応 AWS re:Invent 2024で発表された推論時のレイテンシーを最適化する機能に、Amazon Bedrock Agents, Flows, Knowledge Basesが対応しました。この最適化機能はAnthropic Claude 3.5 Sonnetと、Meta Llama 3.1 70B/405Bに対応しており、これらのモデルを利用する際に精度を損なうことなく推論時の遅延時間を短縮することでユーザ体験の向上につながります。ちなみにオレゴンリージョンでクロスリージョン推論を介して利用することが可能です。 AWS NeuronがTrainium2とNxD Inferenceに対応 Neuron 2.21 が発表され、AWS Trainium 2 チップを搭載したAmazon EC2 Trn2インスタンスと、Trn2 UltraServersがサポートされました。同時に、PyTorch 2.5がサポートされ、 NxD Inference (ベータ)とNeuron Profiler 2.0(ベータ)が利用可能になっています。NxD InferenceはvLLMと統合されたPyTorchベースのライブラリで、大規模言語モデルやマルチモーダルモデルのデプロイを簡素化します。 Amazon SageMaker JumpStartでMeta Llama 3.3 70Bが利用可能に Amazon SageMaker JumpStartを利用してMeta Llama 3.3 70Bモデルを利用できるようになりました。SageMaker JumpStartは数クリックで事前構築済みの機械学習ソリューションを数回のクリックで起動できる機械学習ハブで、最新のモデルを簡単に利用できます。詳細については ブログ記事 が出ていますので、そちらもご覧ください。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

想像力豊かなクリエイティブを大手広告代理店やグローバルブランド、エンターテイメント企業向けに制作するには、限りない想像力が必要です。そのためには、 Hornet が 25 年以上にわたって実写映像、ビジュアルエフェクト（VFX）、ストップモーション、モーションデザイン、3D、セルアニメーション、ブランド戦略の仕事で発揮してきたような創造性が求められます。 こちらのスタジオでは継続的な成長と進化のため、作品の需要に応えるためにインフラストラクチャをレベルアップする必要があり、必要に応じたスケーラビリティ確保のため、Hornet はクラウドを活用する計画を立てました。SI 企業の インテグレーテッド・メディア・テクノロジーズ（IMT） と協力して、スタジオは最終的に Amazon Web Services (AWS) とのインテグレーションを選択し、効率的なクラウドベースのレンダーファームをデプロイしました。 「私たちの業界では、プロジェクトの増減にともなうリソースキャパシティーが常に課題となっていました。クラウドはそのための完璧なソリューションです。制作量の急増や特殊なマシン要件に対応するために必要な機材をすべて購入またはレンタルすることは、楽しくも経済的でもありません。そのため、必要に応じてリソースを増減できることは、私たちにとって大きなメリットとなります。」と、Hornet のマネージングパートナー Greg Bedard 氏 は語ります。 また、Hornet のパイプラインテクニカルディレクター Kevin Poli 氏は次のように付け加えています。「さまざまなクラウドオプションを検討しましたが、AWS は他とは比較にならないほど優れていました。これは間違いなく最も成熟したテクノロジーです。」「AWS のトレーニングを受けるための素晴らしい教育リソースがたくさんあり、とても利用しやすかったです。」 画像提供: Hornet 将来を見据えた構築 長年にわたってレンダリング管理ソフトウェア AWS Thinkbox Deadline を使用していた Hornet によるクラウドプロバイダーの決定の背景には、AWS とのネイティブ統合の影響もありました。スタジオは当初、2021 年にオンプレミスと AWS でハイブリッドレンダリングソリューションを開発していましたが、新しいクラウドベースの AWS 実装をゼロから構築したいと考えていました。この戦略は、2023 年にニューヨーク市のソーホー地区にある新しい場所へのスタジオ移転において、オンプレミスのデータセンター構築に多額の投資をせずに規模を拡大するための基盤となりました。人口密度の高い地域に移転すると、物理的な拡張はほとんど不可能になるため、機械をレンタルまたは購入するという物流上の問題を回避したいと考えていたためです。 クラウドベースのレンダリングに最適化することがパズルの最初のピースでした。セキュリティの強化も優先事項でした。Hornet のパイプライン責任者である Gareth Porter 氏は、「ファイルアクセスをより適切に制御できるようにしたかったのです。」と述べています。「IMT チームは、セキュリティのナビゲートに特に役立ちました。さらに、リソースの効率化のためにワークフローを最適化しました。」 Hornet は IMT チームと AWS サポートと協力して、オンプレミスインフラストラクチャに接続された AWS クラウドスタジオ環境を構築しました。デプロイには Amazon Elastic Compute Cloud ( Amazon EC2 ) スポットインスタンス によるレンダリングが含まれ、現在は GPU ベースのバーチャルアーティストワークステーションを含むように拡張されています。これにより、スタジオのリモートアーティストは、デジタルコンテンツ制作（DCC）ソフトウェアをクラウド上でローカルワークステーションと同じ応答性で実行するために必要となる高いパフォーマンスを得ることができます。 「私たちは AWS を使うには十分な知識がありましたが、クラウド上で複雑なプロダクションワークフローを構築するには十分ではありませんでした。IMT のおかげで、機能的なシステムを管理しているインフラストラクチャの中核要素に置き換えることができました。」と Poli 氏は説明しました。 「私たちのワークフローは今ではずっと安定しています。このプロセスと経験を積むことで、クラウドを最も効率的に使用する方法と、より多く成功するために管理する方法を理解し始めています。」と Porter 氏は付け加えました。 画像提供: Hornet クラウドへの接続 Hornet のオンプレミスファームは、アイドル状態または利用可能なコンピューティングを備えたアーティストワークステーションと専用のレンダリングノードが混在しています。マシンのスペックはさまざまで、チームは可用性と要件に基づいてレンダリングジョブを割り当てます。 「もし締め切りが間近に迫っていて、1 時間分のレンダリングをこなす必要がある場合は、できるだけ多くのノードを立ち上げてそれを実行します。」と Porter 氏は説明します。「私たちは、このシナリオで最も費用対効果の高いマシンを選択することを目指しています。時間があれば、より少ないノードを選択するかもしれませんが、そうでない場合は、状況に応じて必要なリソースを手に入れます。」 スタジオは AWS Thinkbox Deadline 10 を使用してハイブリッドレンダリングファームを管理し、 スポットイベントプラグイン を活用して Amazon EC2 スポットフリート でレンダリングリソースをスケーリングしています。Hornet の主要な制作ツールには、Autodesk Maya、Foundary Nuke、Maxxon Cinema 4D、SideFX Houdini などがあります。また、Blender と Epic Games の Unreal Engine についても研究しています。 「Thinkbox Deadline のスポットイベントプラグインは素晴らしいです。このおかげで、逼迫した時間帯にレンダリング担当者にとって大変なストレスになりかねない多くのタスクが自動化されます」と Poli 氏は語ります。「使用量ベースのライセンス（UBL）も、私たちにとって非常に大きな意味があります。すべてのコンピューティング環境が揃っていますが、サードパーティのリソースにも依存しています。Thinkbox Deadline を使用すると、それらを簡単に導入できます。AWS は究極の追加機能です。」 「業界標準ツールのレンダリングライセンスを個別に購入すると、それぞれ数百ドルかかり、一度に 1 台のマシンでしか使用できませんが、使用量ベースのライセンスでは、同じレートで 1 時間に 100 台のマシンを起動したり、10 台のマシンを 10 時間利用したりできるので、柔軟なソリューションとして有効です。」と Porter 氏は説明しました。 Hornet チームは、ジョブのタグ付けを通じてより多くのクラウド使用状況データを収集するようになったおかげで、レンダリング予算をより正確に見積もり、プロジェクトごとの支出を予測できるようになり、より自信を持って利用できるようになりました。 画像提供: Hornet プロダクションでのAWS利用 クラウドの導入によって、Hornet はクライアントからのフィードバックをもとに、アーティスティックな戦略をたて、技術的な実現を最短の工程で実行できるようになりました。柔軟性の高いスケーラビリティにより、スタジオはより大規模で複雑な作業を引き受けられるようになりました。この能力は、仮想ワークステーションの利用が開始されるとさらに強化されます。アーティストの観点から見ると、クラウドで強化されたワークフローでは、ユーザー体験に影響を与えることなくレスポンスがすぐに返ってくるため、試行錯誤の時間を短縮し制作を加速することができます。 「私たちは主にコマーシャル分野に携わり、制作期間は通常 1 〜 2 か月なので、時間の余裕はありません。AWS は、すぐに立ち上げたり止めたりができるので、当社のようなスタジオにとってゲームチェンジャーとなります。」と Bedard 氏は言います。「ビジネスの観点から見ると、クラウドは非常に強力です。これまでクラウド制作を見てきましたが、他にこのような方法ははありません。」 「クラウドの外では、アーティストが数千フレームのシーケンスをレンダリングし、修正指示を受け取り、新しいバージョンを同じ日にサブミットすることは現実的ではありません。AWS といくつかの技術的な魔法でこれを実現できました。」と Poli 氏は言います。「予算とニーズに基づいてパラメータを調整できるので、レンダリング時間自体はあまり心配されません。アーティストは、限られたリソースの中で作業する代わりに、たくさんのテストをサブミットできます。また、ショットを仕上げるのに十分な計算能力があることを知っているので、より安心できます。」 Bedard 氏はこう締めくくりました。「当社の AWS ワークフローは、1 つの施設内でさまざまなクリエイティブ分野をサポートできるようにするための最善の道筋を示してくれます。特にレンダリングにおける使用量ベースのライセンス（UBL）は、私たちにとって大きなものでした。そして今、次のステップは仮想ワークステーションです。これらの基本的な要素は、パイプラインの成長と進化を続けるのに役立ち、IMT や AWS との関係により、はるかに早く開発面で達成したい場所にたどり着くことができました。」   クラウドベースのクリエイティブワークフローに AWS を使用する方法の 詳細を確認 するか、AWS for Media and Entertainment の担当者に お問い合わせ ください。 著者について Ellen Grogan Ellen Grogan は、AWS のメディアおよびエンターテイメント部門のシニアプロダクトマーケティングマネージャーです。 この記事は Hornet supercharges render capacity with AWS を翻訳したものです。翻訳はVisual Compute ソリューションアーキテクトの森が担当しました。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

本記事は、2024 年 11 月 22 日に公開された “ Simplifying developer experience with variables and JSONata in AWS Ste… ”を翻訳したものです。 この投稿は、Uma Ramadoss (サーバーレス担当 Principal Specialist SA) と Dhiraj Mahapatro ( Amazon Bedrock 担当 Principal Specialist SA) によって執筆されたものです。 AWS Step Functions において、変数と JSONata データ変換が導入されました。変数により、開発者は 1 つのステートでデータを割り当て、その後のステップで参照できるようになり、複数の中間ステートを経由してデータを受け渡す必要がなくなったため、ステートのペイロード管理が簡素になります。オープンソースのクエリおよび変換言語である JSONata により、日付と時刻の書式設定や数学的演算などの高度なデータ操作と変換できるようになりました。 この記事では、これらの新機能の強力な機能について詳しく説明します。具体的には、変数を使用したステート間のデータ共有を簡素にする方法と、高度な JSONata 式によるデータ操作の複雑さを軽減する方法について深く掘り下げていきます。 概要 お客様は、 AWS Lambda 、 AWS Fargate 、 Amazon Bedrock 、HTTP API 統合など、複数のサービスを含む複雑なワークフローを構築するために Step Functions を利用します。 これらのワークフローの中で、さまざまなサービスとやり取りするためのステートを構築し、入力データを渡し、出力としてレスポンスを受け取ります。 Step Functions 自体の機能を超えた、日付、時刻、数値の操作には Lambda 関数を使用できますが、この方法では複雑になるにつれて、ペイロードの制限、データ変換の手間、さらなるステート変更などの課題が生じます。 これは、ソリューション全体のコストに影響を与えます。 この問題に対処するために、変数と JSONata を使用します。 これらの新機能を説明するために、 JSONPath ブログ で取り上げた保険業界の顧客オンボーディングプロセスのユースケースを考えてみましょう。 潜在顧客は、サインアップ時に名前、住所、保険への関心事項などの基本情報を提供します。 この Know-Your-Customer (KYC) プロセスでは、これらの詳細な情報を含むペイロードとともに Step Functions ワークフローが開始されます。 ワークフローでは、顧客の承認または拒否を判断し、通知します。 { "data": { "firstname": "Jane", "lastname": "Doe", "identity": { "email": "jdoe@example.com", "ssn": "123-45-6789" }, "address": { "street": "123 Main St", "city": "Columbus", "state": "OH", "zip": "43219" }, "interests": [ {"category": "home", "type": "own", "yearBuilt": 2004, "estimatedValue": 800000}, {"category": "auto", "type": "car", "yearBuilt": 2012, "estimatedValue": 8000}, {"category": "boat", "type": "snowmobile", "yearBuilt": 2020, "estimatedValue": 15000}, {"category": "auto", "type": "motorcycle", "yearBuilt": 2018, "estimatedValue": 25000}, {"category": "auto", "type": "RV", "yearBuilt": 2015, "estimatedValue": 102000}, {"category": "home", "type": "business", "yearBuilt": 2009, "estimatedValue": 500000} ] } } 従来のワークフロー図は新機能を適用する前のワークフローを示しており、新しいワークフロー図は変数と JSONata を適用して構築されたワークフローを示しています。 このワークフローは、 GitHub リポジトリ の main ブランチ (従来のワークフロー) と jsonata-variables ブランチ (新しいワークフロー) からアクセスできます。 図 1 : 従来のワークフロー 図 2: 新しいワークフロー セットアップ README の手順に従ってこのステートマシンを作成し、テストが完了したら後片付けを行ってください。 変数によるデータ共有の簡素化 変数を使用することで、後続のステートで参照される変数に、ステートの結果を宣言または代入することができます。1 つのステートで、静的データ、ステートの結果、JSONPath や JSONata 式、組み込み関数など、さまざまな値を持つ複数の変数を割り当てることができます。次の図は、ステートマシン内で変数がどのように割り当てられ、使用されるかを示しています。 図 3: 変数の割り当てとスコープ 変数のスコープ Step Functions における変数は、プログラミング言語と同様のスコープを持ちます。内部スコープと外部スコープがあり、それぞれのレベルで変数を定義します。内部スコープの変数は map、parallel、ネストされたワークフロー内で定義され、その特定のスコープ内でのみアクセス可能です。一方、外部スコープの変数はトップレベルで設定されます。一度変数が割り当てられると、実行順序に関係なく、後続のどのステートからでもこれらの変数にアクセスできます。しかし、このブログのリリース時点では、Distributed Map は外部スコープの変数を参照できません。 変数のスコープに関するユーザーガイド では、このようなエッジケースについて詳しく説明されています。 変数の割り当てと使用 変数の値を設定するには、特別なフィールドである Assign を使用します。このブログの後半にある JSONata の部分で、 {%%} の目的について説明しています。 "Assign": { "inputPayload": "{% $states.context.Execution.Input %}", "isCustomerValid": "{% $states.result.isIdentityValid and $states.result.isAddressValid %}" } 変数を使用するには、変数名の前にドル記号 ($) を付けて記述します。 { "TableName": "AccountTable", "Item": { "email": { "S": "{% $inputPayload.data.email %}" }, "firstname": { "S": "{% $inputPayload.data.firstname %}" },.... } JSONata によるデータ操作の簡素化 JSONata は、Json データ用の軽量なクエリおよび変換言語です。JSONata は、Step Functions 内の JSONPath と比較してより多くの機能を提供します。 QueryLanguage を "JSONata" に設定し、JSONata 式に {%%} タグを使用することで、ステートマシン内で JSONata を利用できます。 この設定 はステートマシンのトップレベルまたは各タスクレベルで適用できます。タスクレベルの JSONata を利用することで、JSONata と JSONPath の選択を細かく制御できます。この方法は、一部のステートを JSONata で簡素化し、残りのステートでは JSONPath を使い続けたい複雑なワークフローに有用です。JSONata は、JSONPath や Step Functions の組み込み関数よりも多くの関数と演算子を提供します。 ステートマシンレベルで QueryLanguage 属性を JSONata に設定 すると、JSONPath が無効になり、 InputPath 、 Parameters 、 ResultPath 、 ResultSelector 、 OutputPath の使用が制限されます。代わりに JSONata では Arguments と Output を使用します。 シンプルなステートの最適化 新しいステートマシンで最初に気づく点の 1 つは、以下の比較で示されるように、 Verification プロセスが Lambda 関数を使用していないことです。 図 4: Pass ステートに置き換えられた Lambda 関数 従来のアプローチでは、正規表現を使用してメールアドレスとソーシャルセキュリティナンバー (SSN) を検証する Lambda 関数が使用されていました。 const ssnRegex = /^\d{3}-?\d{2}-?\d{4}$/; const emailRegex = /^[a-zA-Z0-9._-] +@[a-zA-Z0-9.-] + \.[a-zA-Z]{2,4}$/; exports.lambdaHandler = async event => { const { ssn, email } = event ; const approved = ssnRegex.test(ssn) && emailRegex.test(email); return { statusCode: 200, body: JSON.stringify({ approved, message: `identity validation ${approved ? 'passed' : 'failed'}` }) } }; JSONata を使用すると、ステートマシンの Amazon States Language (ASL) を利用して正規表現を直接定義できます。 Pass ステートと JSONata の $match() を使用して、メールアドレスと SSN を検証します。 { "StartAt": "Check Identity", "States": { "Check Identity": { "Type": "Pass", "QueryLanguage": "JSONata", "End": true, "Output": { "isIdentityValid": "{% $match($states.input.data.identity.email, /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/) and $match($states.input.data.identity.ssn, /^(\d{3}-?\d{2}-?\d{4}|XXX-XX-XXXX)$/) %}" } } } } 同様に、JSONata の高度な文字列関数 $length 、 $trim 、 $each 、 $not を使って、 Pass ステートの中で住所を検証できます。 { "StartAt": "Check Address", "States": { "Check Address": { "Type": "Pass", "QueryLanguage": "JSONata", "End": true, "Output": { "isAddressValid": "{% $not(null in $each($states.input.data.address, function($v) { $length($trim($v)) > 0 ? $v : null })) %}" } } } } JSONata を使用する場合、 $states は 予約変数 になります。 結果の集計 以前は JSONPath では、 Choice ステート以外で式は使用できませんでした。しかし JSONata ではそのような制限はありません。この例では、 parallel ステートで各サブステップからの本人確認と住所確認の結果を収集しています。それらの結果を boolean 変数 isCustomerValid に集約しています。 "Verification": { "Type": "Parallel", "QueryLanguage": "JSONata", ... "Assign": { "inputPayload": "{% $states.context.Execution.Input %}", "isCustomerValid": "{% $states.result.isIdentityValid and $states.result.isAddressValid %}" }, "Next": "Approve or Deny?" } ここで重要な点は、 $states.result を介した結果へのアクセスと、{%%} 内での AND ブール演算子 の使用です。これにより、この変数を使用する後の Choice ステートがシンプルになります。 JSONata の Operators を使用することで、可能な限りこのような式を柔軟に記述でき、単純なデータ変換するをためのコンピュート層を削減できます。 さらに、 {%%} 内の式が true または false の値を返す限り、柔軟な JSONata 演算子および式を利用することで、 Choice ステートが簡単に使えるようになります。 JSONata 関数としての組み込み関数 Step Functions は、 Step Functions の組み込み関数 と同等の機能を提供するために、JSONata の組み込み関数が提供されています。 DynamoDB の putItem ステップでは、 States.UUID() 組み込み関数と同じ機能を持つ $uuid() の使用方法を示しています。 また、日付と時刻に関する JSONata 固有の関数も利用できます。 以下のステートは、DynamoDB テーブルにアイテムを挿入する前に、 $now() を使用して現在のタイムスタンプを ISO-8601 形式の文字列として取得する例を示しています。 "Add Account": { "Type": "Task", "QueryLanguage": "JSONata", "Resource": "arn:aws:states:::dynamodb:putItem", "Arguments": { "TableName": "AccountTable", "Item": { "PK": { "S": "{% $uuid() %}" }, "email": { "S": "{% $inputPayload.data.identity.email %}" }, "name": { "S": "{% $inputPayload.data.firstname & ' ' & $inputPayload.data.lastname %}" }, "address": { "S": "{% $join($each($inputPayload.data.address, function($v) { $v }), ', ') %}" }, "timestamp": { "S": "{% $now() %}" } } }, "Next": "Interests" } JSONata 式が ASL を利用してステートマシンを定義する際の開発者の負担を軽減するため、 S.$ 内で .$ 表記が不要になったことに注目してください。Step Functions 内で利用可能な 追加の JSONata 関数 についても調べてみてください。 高度な JSONata JSONata の柔軟性は、組み込み関数、 高階関数 のサポート、 関数型プログラミング構文 に由来します。JSONPath では、高度な式 "InputPath": "$..interests[?(@.category ==home) ]" を使用して、配列 interests から住宅保険関連の興味関心をフィルタリングしていました。JSONata は フィルタリング 以上の機能を提供します。たとえば、住宅保険の関心事を探し、カテゴリタイプが home の totalAssetValue を参照し、name や email などの既存のフィールドを JSONata 変数として参照できます。 ( $e := data.identity.email ; $n := data.firstname & ' ' & data.lastname ; data.interests[category='home']{ 'customer': $n, 'email': $e, 'totalAssetValue': $sum(estimatedValue), category: {type: yearBuilt} } ) 結果の JSON は次のようになります。 `{ "customer": "Jane Doe", "email": "jdoe@example.com", "totalAssetValue": 1400000, "home": { "own": 2004, "business": 2009 } }` これらのステップに従うことで、すべての保険に関する関心事とその集約結果を収集し、1 つ上のレベルに進みます。カテゴリフィルターがもう存在しないことに注目してください。 ( $e := data.identity.email ; $n := data.firstname & ' ' & data.lastname ; data.interests{ 'customer': $n, 'email': $e, 'totalAssetValue': $sum(estimatedValue), category: {type: yearBuilt} } ) 結果は次のようになります。 { "customer": "Jane Doe", "email": "jdoe@example.com", "totalAssetValue": 1549000, "home": { "own": 2004, "business": 2009 }, "auto": { "car": 2012, "motorcycle": 2018, "RV": 2015 }, "boat": { "snowmobile": 2020 } } 複雑な式の探索 サンプルデータと JSONata プレイグラウンドを利用 して、要件に合った詳細で複雑な式を見つけてください。以下は JSONata プレイグラウンドの使用例です。 図 5: JSONata プレイグラウンド 考慮事項 変数のサイズ 1 つの変数の最大のサイズは 256KiB です。 この制限は、ステート出力を別々の変数に格納することで、Step Functions のペイロードサイズ制限を回避するのに役立ちます。 個々の変数のサイズは最大 256KiB ですが、単一の Assign フィールド内のすべての変数の合計サイズは 256KiB を超えることはできません。 この制限を回避するには Pass ステートを使用できますが、格納されたすべての変数の合計サイズは、1 回の実行につき 10MiB を超えることはできません。 変数の可視性 変数は、ステート間でデータを共有するのを簡単にする強力な仕組みです。使いやすく柔軟であるため、 ResultPath 、 OutputPath 、JSONata の Output フィールドよりも変数を優先してください。ただし、 Output を使う可能性のある場面が 2 つあります。1 つ目は、外側のスコープから内側のスコープの変数にアクセスできない場合です。この場合、 Output フィールドを使うと、ワークフローの異なるレベル間でデータを共有できます。2 つ目は、ワークフローの最終ステートからレスポンスを送信する際に、 Output フィールドを使う必要がある場合です。以下の JSONPath から JSONata への移行図に、その詳細を示しています。 図 6: JSONPath から JSONata への移行 さらに、特定のステートに割り当てられた変数は、同じステートからはアクセスできません。 "Assign Variables": { "Type": "Pass", "Next": "Reassign Variables", "Assign": { "x": 1, "y": 2 } }, "Reassign Variables": { "Type": "Pass", "Assign": { "x": 5, "y": 10, ## The assignment will fail unless you define x and y in a prior state. ## otherwise, the value of z will be 3 instead of 15. "z": "{% $x+$y %}" }, "Next": "Pass" } ベストプラクティス Step Functions の 検証 API は、ワークフローのセマンティックチェックを提供し、早期の問題発見を可能にします。 ワークフローの安全な更新を確実するために、検証 API と バージョニングとエイリアス を組み合わせて、段階的にデプロイすることをお勧めします。 JSONata の複数行の式は有効な JSON ではありません。したがって、セミコロン “;” で区切られた文字列として 1 行 を使用し、最後の行で式を返すようにしてください。 相互排他 QueryLanguage タイプの使用は相互に排他的です。変数の割り当て時に JSONPath/組み込み関数と JSONata を混在させないでください。たとえば、以下のタスクは失敗します。変数 b は JSONata を使用していますが、 c は組み込み関数を使用しているためです。 "Store Inputs": { "Type": "Pass", "QueryLanguage": "JSONata" "Assign": { "inputs": { "a": 123, "b": "{% $states.input.randomInput %}", "c.$": "States.MathRandom($.start, $.end)" } }, "Next": "Average" } JSONPath で変数を使用するには 、 QueryLanguage を JSONPath に設定するか、タスク定義からこの属性を削除してください。 結論 変数と JSONata により、AWS Step Functions は開発者が Amazon States Language (ASL) で通常のプログラミングパラダイムに合わせた簡潔なコードでエレガントなワークフローを記述できるようになり、開発者体験が向上しました。 開発者は、余分なデータ変換のステップを省略することで、より高速に、クリーンなコードを記述できるようになりました。 これらの機能は、新規および既存のワークフローの両方で使用できるため、JSONPath から JSONata と変数への移行を柔軟に行うことができます。 変数と JSONata は、AWS Step Functions が利用可能なすべての AWS リージョンで追加料金なしでお客様にご利用いただけます。 JSONata と 変数 のユーザーガイド、および jsonata-variables ブランチの サンプルアプリケーション を参照してください。 サーバーレスに関する知識を深めるには、 Serverless Land をご覧ください。

みなさん、明けましておめでとうございます。ソリューションアーキテクトの杉山です。年末年始で 1 週 Skip させていただいたため、2 週まとめて 週刊AWS をお届けします。 年末年始に SNS でバズっていた (?) レシピを使って、自宅で豚骨ラーメンを作りました。まるで外出先のお店でいただけるような味にできて、ちょっとした充実があり、リフレッシュできました。 それでは、主なアップデートについて振り返っていきましょう。 2024年12月23日 – 30日 週の主要なアップデート 12/23(月) Amazon SES Mail Manager でログ機能に対応 Amazon SES の Mail Manager でログ機能を提供開始しました。Mail Manager は組織内でメールを送受信する際に、コンプライアンスを一元的に管理できる機能セットです。例えば、DKIM が Pass になったメールのみ受信する、Trend Micro Virus Scanning と連携しウイルススキャン後にメールを受信する、といったルール管理が可能です。この Mail Manager に CloudWatch Logs、S3、Firehose へログを出力する機能が追加され、詳細なトラブルシュートなどがやりやすくなりました。詳細は こちらの Document を参照ください。 Amazon Lightsail API エンドポイントが IPv6 での接続をサポート Amazon Lightsail API エンドポイントが IPv6 プロトコルをサポートし、IPv6 での接続が可能になりました。従来のエンドポイントは IPv4 専用でしたが、新たに IPv6 接続が可能な dual-stack エンドポイント（例 : lightsail.ap-northeast-1.api.aws）が追加されました。詳細は こちらの Document を参照ください。 AWS CloudTrail が Internet Protocol Version 6 (IPv6) をサポート AWS CloudTrail は CloudTrail API エンドポイントでデュアルスタックを導入し、IPv6 での接続が可能になりました。また、AWS PrivateLink を使用して VPC から CloudTrail API エンドポイントにプライベートにアクセスする場合でも、デュアルスタックが利用可能です。 12/26(火) Amazon EKS が Kubernetes バージョンのサポートステータスなどを取得する API を追加 Amazon EKS で Kubernetes バージョンのサポートステータスなどを取得する API を追加しました。 DescribeClusterVersions API を AWS CLI や SDK などから利用でき、各 Cluster Version のリリース日、Standard Support の期限、Extended Support の期限などを確認できます。また、各バージョンについて、現状 Standard Support なのか、Extended Support なのか、サポート期限切れかどうかを確認できます。従来 AWS Document から確認 できましたが、これをプログラムから取得できるようになった形です。 12/27(水) Amazon EC2 I7ie インスタンスが AWS US East (Ohio)、US West (Oregon) リージョンで利用可能 Amazon EC2 で、I7ie インスタンスがオハイオ、オレゴンリージョンで利用可能になりました。I7ie は高密度ストレージ最適化インスタンスで、大規模なデータセットにアクセスする際に、非常に低いレイテンシーで、高いランダム読み取り/書き込み性能が必要なワークロードに最適です。最大 120 TB のローカル NVMe ストレージを提供し、前世代インスタンスと比較して最大 2 倍の vCPU とメモリを提供します。 1/2(木) AWS Application Discovery Service で IPv6 エンドポイントをサポート AWS Application Discovery Service (ADS) で、IPv6 エンドポイントをサポートしました。Application Discovery Service は、クラウド移行の一環で、移行元のサーバーやアプリケーションを自動的に発見し、それらのシステム構成、使用状況、パフォーマンスデータ、などの詳細な情報を収集します。リソースのサイジング、アプリケーション間の依存関係の把握などに利用できます。IPv6 をサポートするようになり、より幅広いネットワーク環境でご利用しやすくなりました。 1/3(金) AWS WAF コンソールに新しいトップインサイトのダッシュボード機能を追加 AWS WAF のコンソールダッシュボードに、トラフィックに関するインサイトを提供する、より充実したダッシュボード機能を追加しました。CloudWatch Logs に蓄積しているデータを活用し、URI Path、HTTP Method、接続元 IP、User agent などの属性ごとにトラフィックデータを確認できるダッシュボードを提供するものです。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

はじめに 生成 AI の活用が企業の競争力を左右する時代となっています。しかし、 PwC 社の 生成AIに関する実態調査2024 春 米国との比較 によると、「必要なスキルを持った人材がいない」や「ノウハウがなく、どのように進めれば良いか、進め方がわからない」、「意義やメリット、費用対効果を感じない」といった課題があるなど、多くの企業では、生成 AI の導入にあたって、技術的なハードルや、コスト面での課題を抱えています。 アオラナウ株式会社 （以下、アオラナウ）は、AWS が提供する Generative AI Use Cases JP （通称: GenU）を活用することで、わずか 2 週間という短期間で社内 RAG システムを構築し、ドキュメント検索時間が従来の 1/5 程度に短縮するなど、大幅な業務効率化を実現しました。本ブログは、アオラナウがどのように GenU を活用したか、アオラナウの AI プロダクト開発部の金山 陽希氏から寄稿いただいたものです。 課題：ベンチャー企業における業務効率化の必要性 アオラナウは、従業員数 50 名を超えるベンチャー企業です。技術的な熟練度が高いメンバー（高度技術者）と、未経験メンバーが入り混じっており、プロジェクト運営の際に以下のような課題が生じていました。 高度技術者は、膨大な技術ドキュメントの効率的な探索に時間がかかる 未経験メンバーは、高度技術者への問い合わせに時間を使っており、双方の時間を使われる 未経験メンバーは、忙しい高度技術者への質問を躊躇してしまう これらの課題を解決するために、最新の生成 AI 技術である RAG を利用したいと思いましたが、AI 導入においては、限られた予算内で実施できるよう工夫する必要がありました。 ソリューション：GenU を活用した社内 RAG システムの構築 AWS の AI/ML ソリューションアーキテクトである呉 和仁氏（ @kazuneet ）に相談したところ、AWS が提供する Generative AI Use Cases JP （通称: GenU、以降 GenU と略す）をご紹介いただき、私たちは GenU を基盤とした社内 RAG システムの構築を決定しました。 ＜GenU を採用したポイント＞ すぐにデプロイできる AWS の技術者が構築した質の高いコードがすぐデプロイできる状態で用意されており、自社での開発工数を大幅に削減できることが魅力でした。導入手順も丁寧に解説されており、AWS 未経験者でも容易に導入することが出来そうでしたし、結果として容易でした。 カスタマイズの柔軟性 最新の LLM モデルを設定ファイルの変更のみで導入できたりと、カスタマイズが柔軟にできるように設計されておりました。また、GenU の利用状況のモニタリングや、ユーザーからのハルシネーション報告などをもとにデータを修正するシステムを簡単に連結することが出来ました。 コスト最適化 サーバーレスアーキテクチャが最大限活用されており、ほぼ利用分のみの安価な運用コストも大変魅力的でした。ベクトル DBに Pinecone などのサードパーティー製品を利用するためのガイドもあり、さらなるコスト最適化の検討が容易なように設計されていました。 アーキテクチャ システムは以下のように、GenU をベースとして、弊社独自に GenU を管理するためのシステムを構築しています。 ServiceNow の技術ドキュメント（日本語/英語）60,000 ページと、600,000 件の QA データを元にした社内 RAG システムを、2 週間で構築することができました。 アオラナウでの GenU 構成 ユーザーは、GenU の画面から、RAG チャットを利用して技術的な質問をすることが出来ます。 アオラナウでの GenU 利用イメージ GenU管理システムでは、ユーザーの利用状況のモニタリングや、ユーザーからのハルシネーション報告を元にデータの修正作業を行えるようにしています。 アオラナウでの GenU ダッシュボード GenU の導入効果 GenU を導入することで、以下のような効果を月々数万円程度のコストで実現することが出来ました。 高度技術者は、ドキュメント検索時間が従来の 1/5 程度に短縮 未経験者の高度技術者への問い合わせ件数が削減 未経験者はまず GenU で調査した後、高度技術者に深い内容を聞くという質問の質の向上 結果として、プロジェクトを効率的に進めることができるようになったと体感しています。 今後、プロジェクトの成果物まで生成 AI が作成サポート出来るか、検証していく予定です。 まとめ GenU の活用により、私たちは短期間かつ低コストで高度な RAG システムを構築することができました。特筆すべきは、AWS の MLSA である呉氏による手厚いサポートです。技術的な課題に直面した際も、迅速な解決策の提案をいただき、スムーズな導入を実現できました。 ベンチャー企業にとって、効率的なリソース活用は重要な課題です。GenU は、その解決策として非常に有効なツールとなりました。今後も、AWS の提供するサービスを活用しながら、さらなる業務改善を進めていきたいと考えています。 執筆者について アオラナウ株式会社の AI プロダクト開発チームです。 金山 陽希 フルスタックエンジニア。ソリューションの設計、実装を担当しています。 新しいAI技術と前職でのWebアプリケーション開発の経験を活かし、なにかを実現することを楽しんでいます。 近頃足回りを囲むパネルヒーターを手に入れたので、今冬はこれだけで乗り切ろうかと画策中。 宍戸 凌雅 オペレーションエンジニア。本プロジェクトで運用設計を主に担当しています。 前職で培った経験を活かし、効率的で効果的な運用フローの構築に努めています。 生成AIを仕事やプライベートで積極的に活用しており、その可能性を追求することで世の中に貢献したいと考えています。 趣味は散歩や筋トレで、体力づくりを楽しみながらリフレッシュしています。 鄭 巽 AIエンジニア兼開発リードとして、チーム管理作業と実装作業を担当しています。 前職で培った統計知識と開発経験を活かし、適切な解決策を考えて事業価値を創出しています。 画像認識や生成モデルの分野に興味を持ち、実務の中で実践できることを楽しんでいます。 人と技術の橋渡し役として、チームのモチベーションを高めつつ、成果を引き出せるよう努めています。 保田 駿介 ServiceNowコンサルタント。お客様とのPoC実施、プリセールス活動を実施。生成AIを含むAI/ML技術の支援を担当しています。 様々な業界のServiceNowやSalesforceの導入を支援していた経験を生かし、ビジネス上の課題や業務課題解決するためのAI/MLソリューションの提案や導入支援に努めています。 BizDevの役割ではありますが、技術面もキャッチアップを怠らず進めていこうと思ってます。 李 溶基 ServiceNowアーキテクト。AWSとServiceNowの連携部分の開発を担当。REST API開発経験を生かし、ビジネス上の課題を解決するためのAI/MLソリューションの提案や導入支援に努めています。 プライベートではランニングやジム通いを通じてストレスを発散しています 伊藤 芳幸 エンジニア。前職の経験を活かし、AI/ML技術とServiceNowを融合させ、企業の生産性向上の新しい可能性を模索しています。 新しい技術に触れることは楽しみの一つで、積極的に手を動かしています。プライベートでは育児に忙しい日々を送っていますが、フットサルやジム通いを通じてストレスを発散しています。 参考情報 Generative AI Use Cases JP Amazon Bedrock ユーザーガイド AWS Lambda 開発者ガイド Meta knowledge for retrieval augmented large language models (amazon science)

今日の データ主導の世界 では、企業は データレイク や ウェアハウス にまたがる 膨大な量の情報 を処理および分析する効率的な方法を常に模索しています。 Amazon SageMaker Lakehouse を使用すると、 Amazon Simple Storage Service ( Amazon S3 ) 上のデータレイクと Amazon Redshift データウェアハウスにまたがるすべてのデータを統合することができ、強力なアナリティクスと AI / ML アプリケーションを一元化されたデータで構築できます。SageMaker Lakehouse は、データを動かさずに Apache Iceberg と互換性のあるすべてのツールとエンジンでクエリを実行できる柔軟性を提供します。これは、SageMaker Lakehouse の機能を使用したい オープンソースの Apache Spark ユーザーにとって、エキサイティングな可能性を開きます。さらに、 SageMaker Lakehouse では、すべてのアナリティクスおよび ML ツールやエンジンに適用されるきめ細かい権限を定義することで、データを保護することができます。 この投稿では、オープンソースの Apache Spark のパワーを利用し、 AWS Glue Iceberg REST Catalog で動作するようサードパーティのエンジンを設定する方法を探ります。 この投稿には、 AWS Lake Formation が一時的なクレデンシャルを提供する機能を使用してメタデータと実データへのアクセスを管理し、 Amazon S3 テーブルに対してデータを読み取り/書き込みする操作を実行する方法の詳細が含まれます。 ソリューション概要 この投稿では、お客様が Data Catalog を使用して組織内の構造化および半構造化データセットのテクニカルメタデータを一元管理し、データチームが Apache Spark を使用してデータ処理を行えるようにしたいと考えています。 お客様は、 AWS Glue データベースを作成します。そして、Lake Formation の権限コントロールを使用してAmazon S3 上の Iceberg データを読み書きするために、Iceberg Rest API を使用して Glue Data Catalog と対話できるよう Apache Spark を設定します。 まず、 Apache Spark を使用して ETL ( 抽出・変換・ロード ) スクリプトを実行することから始めます。 Amazon S3 上に Iceberg テーブルを作成し、 Glue Iceberg REST Catalog を使用してそのテーブルにアクセスします。 ETL スクリプトは Iceberg テーブルにデータを追加し、 その後 Spark SQL を使用してデータを読み取ります。 この投稿では、他のデータチームが Amazon Athena を使用して、このデータをクエリする方法についても紹介します。 前提条件 Data Catalog を持つアカウントの、 Lake Formation データレイク管理者である AWS Identity and Access Management (IAM) ロール にアクセスできる必要があります。 手順については、 データレイク管理者を作成する を参照してください。 Python バージョン 3.7 以降がインストールされていることを確認します。 pip3 のバージョンが 22.2.2 以上であることを確認してください。 最新の AWS Command Line Interface ( AWS CLI ) をインストールまたは更新します。 手順については、 最新バージョンの AWS CLI のインストールまたはアップデート を参照してください。 AWS CLI を使用して aws configure を実行し、 AWS アカウントを指定します。 お客様の Iceberg テーブルを格納する S3 バケットを作成 します。 今回は、 us-east-2 の AWS リージョンを使用し、バケット名を ossblog-customer-datalake とします。 AWS Glue Iceberg REST Catalog エンドポイントを使用したデータアクセスに使用する、 OSS Spark 用の IAM ロールを作成します。作成した IAM ロールが Data engineer permissions で定義されている AWS Glue と Lake Formation のポリシーを持っていることを確認してください。 この投稿では、 spark_role という名前の IAM ロールを使用します。 Lake Formation のサードパーティからのアクセス権限を有効にする このセクションでは、 Lake Formation に S3 バケットを登録 します。 このステップにより、Lake Formation は Amazon S3 に保存されたメタデータとデータの一元的な権限管理システムとして機能し、データレイク環境においてより効率的でセキュアなデータガバナンスを可能にします。 ロケーションの登録に使用するロールの要件 に従って、ユーザー定義の IAM ロールを作成します。 この投稿では、IAMロール : LFRegisterRole を使用します。 以下のコマンドを実行し、 IAM ロール LFRegisterRole を使用して、S3バケット ossblog-customer-datalake を登録します。 aws lakeformation register-resource \ --resource-arn ' < S3 bucket ARN for amzn-s3-demo-bucket> ' \ --role-arn ' < IAM Role ARN for LFRegisterRole > ' \ --region <aws_region> または、Lake Formation の AWS マネジメントコンソールを使用することもできます。 Lake Formation コンソールに移動し、ナビゲーションペインから Administration を選択し、次に Data lake locations を選択して、以下の値を入力します。 Amazon S3 path では、 s3://ossblog-customer-datalake を選択します。 IAM role では、 LFRegisterRole を選択します。 Permission mode では、 Lake Formation を選択します。 Register location を選択します。 Lake Formationで、外部エンジンがデータにアクセスできるように full table access を有効にします。 管理者ユーザーとしてサインインし、ナビゲーション ペインで Administration を選択します。 Application integration settings を選択し、 Allow external engines to access data in Amazon S3 locations with full table access を選択します。 Save を選択します。 OSS Spark ロールのリソースアクセスを設定 Lake Formation コンソールに移動し、ナビゲーションペインで Databases を選択して、デフォルトカタログに ossblogdb という AWS Glue データベース を作成します。 データベースを選択し、 Edit を選択して Use only IAM access control for new tables in this database のチェックボックスをオフにします。 OSS Spark ロールにリソース権限を付与 OSS Spark が ossblogdb データベースの上でデータセットを作成し、データを投入できるようにするには、前提条件のステップ 4 で作成した Apache Spark インスタンスの IAM ロール（ spark_role ） を使用します。 Apache Spark はこのロールを使用して、Iceberg テーブルを作成し、レコードを追加し、読み込みます。 この機能を有効にするには、 spark_role にフルテーブルアクセスを付与し、テーブルデータを保存できる S3 バケットにデータロケーション権限を付与します。 spark_role にテーブル作成権限を付与 データレイク管理者としてサインインし、AWS CLIで以下のコマンドを実行します。 aws lakeformation grant-permissions \ --principal '{"DataLakePrincipalIdentifier":"arn:aws:iam:: <aws_account_id> :role/ <iam_role_name> "}' \ --permissions '["CREATE_TABLE","DESCRIBE"]'\ --resource '{"Database":{"CatalogId":" <aws_account_id> ","Name":"ossblogdb"}}' \ --region <aws_region> またはコンソール上で以下を実施します Lake Formation コンソールのナビゲーションペインで、 Data permissions を選択し、 Grant を選択します。 Principals セクション の IAM users and roles で、 spark_role を選択します。 LF-Tags or catalog resources セクションで、 Named Data Catalog resources を選択します。 Catalogs では <accountid> を選択します。 Databases では ossblogdb を選択します。 Database permissions で、 DESCRIBE と CREATE TABLE を選択します。 Grant を選択します。 spark_role にデータロケーション許可を付与 データレイク管理者としてサインインし、AWS CLI を使用して以下のコマンドを実行します。 aws lakeformation grant-permissions --principal '{"DataLakePrincipalIdentifier":" <Principal> "}' --permissions DATA_LOCATION_ACCESS --resource '{"DataLocation":{"CatalogId":" <Catalog ID> ","ResourceArn":" <S3 bucket ARN> "}}' --region <aws_region> またはコンソール上で以下を実施します。 Lake Formation コンソールのナビゲーションペインで、 Data Locations を選択し、 Grant を選択します。 IAM users and roles では、 spark_role を選択します。 Storage locations では、 バケット名 を選択します。 Grant を選択します。 AWS Glue Iceberg REST catalog エンドポイントを使用する Spark スクリプトのセットアップ 以下の内容で、 oss_spark_customer_etl.py という名前のファイルをあなたの環境に作成します。 import sys import os import time from pyspark.sql import SparkSession #Replace <aws_region> with AWS region name. #Replace <aws_account_id> with AWS account ID. spark = SparkSession.builder.appName('osspark') \ .config('spark.jars.packages', 'org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.4.1,software.amazon.awssdk:bundle:2.20.160,software.amazon.awssdk:url-connection-client:2.20.160') \ .config('spark.sql.extensions', 'org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions') \ .config('spark.sql.defaultCatalog', 'spark_catalog') \ .config('spark.sql.catalog.spark_catalog', 'org.apache.iceberg.spark.SparkCatalog') \ .config('spark.sql.catalog.spark_catalog.type', 'rest') \ .config('spark.sql.catalog.spark_catalog.uri','https://glue. <aws_region> .amazonaws.com/iceberg') \ .config('spark.sql.catalog.spark_catalog.warehouse',' <aws_account_id> ') \ .config('spark.sql.catalog.spark_catalog.rest.sigv4-enabled','true') \ .config('spark.sql.catalog.spark_catalog.rest.signing-name','glue') \ .config('spark.sql.catalog.spark_catalog.rest.signing-region', <aws_region> ) \ .config('spark.sql.catalog.spark_catalog.io-impl','org.apache.iceberg.aws.s3.S3FileIO') \ .config('spark.hadoop.fs.s3a.aws.credentials.provider','org.apache.hadoop.fs.s3a.SimpleAWSCredentialProvider') \ .config('spark.sql.catalog.spark_catalog.rest-metrics-reporting-enabled','false') \ .getOrCreate() spark.sql("use ossblogdb").show() spark.sql("""CREATE TABLE ossblogdb.customer (name string) USING iceberg location 's3://<3_bucket_name>/customer'""") time.sleep(120) spark.sql("insert into ossblogdb.customer values('Alice') ").show() spark.sql("select * from ossblogdb.customer").show() Pyspark をローカルで起動し、 Amazon S3 上の Iceberg テーブルへの読み書き を検証する pip install pyspark を実行します。 スクリプトをローカルに保存し、環境変数（ AWS_ACCESS_KEY_ID , AWS_SECRET_ACCESS_KEY , AWS_SESSION_TOKEN ）に spark_role の一時的な認証情報を設定します。 python /path/to/oss_spark_customer_etl.py を実行します。 Athena を使用して Iceberg テーブルのデータを表示することもできます。 他のデータチームがコンテンツを閲覧できるようにするには、Lake Formation コンソールを使用してデータチームの IAM ロールに読み取りアクセス権を付与します。 Lake Formation コンソールのナビゲーションペインで、 Data permissions を選択し、 Grant を選択します。 Principals セクションの IAM users and roles で、 <iam_role> を選択します。 LF-Tags or catalog resources セクションで、 Named Data Catalog resources を選択します。 Catalogs では <accountid> を選択します。 Databases では ossblogdb を選択します。 Tables では customer を選択します。 DESCRIBE と SELECT を テーブル権限 に選択します。 Grant を選択します。 IAM ロールでサインインし、以下のコマンドを実行します。 SELECT * FROM "ossblogdb"."customer" limit 10; クリーンアップ リソースをクリーンアップするには、以下の手順を実行します。 Data Catalog で作成したリソース（データベース/テーブル）を削除します。 S3バケットを 空にして 、 削除します 。 結論 この投稿では、Amazon S3 の Iceberg テーブルにアクセスするための Apache Spark と AWS Glue Iceberg Rest Catalog のシームレスな統合について説明し、Iceberg REST API を使用して読み取りと書き込みの操作を効果的に実行する方法を示しました。 このソリューションの素晴らしいところは、その柔軟性にあります。データセンターのベアメタルサーバーで Spark を実行している場合でも、 Kubernetes クラスタで実行している場合でも、その他の環境であっても、このアーキテクチャはニーズに合わせて適応させることができます。 著者について Raj Ramasubbu は、Amazon Web Servicesのビッグデータおよびアナリティクス、AI / MLに特化したシニアアナリティクススペシャリストソリューションアーキテクトです。 AWS 上で拡張性、パフォーマンス、安全性の高いクラウドベースのソリューションを設計、構築するお客様を支援しています。 AWS 入社以前 20 年以上にわたり、データエンジニアリング、ビッグデータ分析、ビジネスインテリジェンス、データサイエンスソリューションの構築における技術的専門知識とリーダーシップを発揮してきました。 彼は、ヘルスケア、医療機器、ライフサイエンス、小売、資産管理、自動車保険、住宅用不動産投資信託、農業、タイトル保険、サプライチェーン、文書管理、不動産など、さまざまな業種のお客様を支援しました。 Srividya Parthasarathy は、 AWS Lake Formation チームのシニアビッグデータアーキテクトです。 プロダクトチームやお客様と協力して、分析データプラットフォーム向けの堅牢な機能とソリューションを構築しています。彼女は、データメッシュソリューションを構築し、コミュニティと共有することを楽しんでいます。 Pratik Das は、 AWS Lake Formation のシニアプロダクトマネージャーです。 データに関するあらゆることに情熱を持っており、お客様の要件を理解し、楽しいエクスペリエンスを構築するためにお客様と協力しています。 彼は、データドリブンソリューションと機械学習システムの構築経験があります。 翻訳は Solutions Architect 圓山が担当しました。原文は こちら です。

この記事は Amazon EKS now supports Amazon Application Recovery Controller (記事公開日: 2024 年 11 月 8 日) を翻訳したものです。 はじめに Amazon Elastic Kubernetes Service ( Amazon EKS ) が Amazon Application Recovery Controller ( ARC ) のサポートを開始しました。ARC は AWS リージョン またはアベイラビリティゾーン (AZ) の障害に対する準備と復旧を可能にする AWS サービスです。 ARC には、ゾーンシフトとゾーンオートシフトを含む マルチ AZ リカバリ と、ルーティングコントロールと準備状況チェックを含む マルチリージョンリカバリ の 2 つの機能があります。今回のリリースにより、以前は Application Load Balancer (ALB) と Network Load Balancer (NLB) でのみ利用可能だったゾーンシフトとゾーンオートシフトが Amazon EKS をサポートしました。 ARC のゾーンシフトとゾーンオートシフトは、障害のある AZ から他の正常な AZ に ingress トラフィックをシフトすることで、サポートされている AWS リソースのマルチ AZ リカバリを実現します。シフトが終了すると、ARC は ingress トラフィックを再び受信できるように以前に影響を受けた AZ を戻します。 Amazon EKS コンソール、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS CloudFormation 、または eksctl を使用して、EKS クラスターのゾーンシフトを有効にできます。有効にすると、ARC コンソール、AWS CLI、またはゾーンシフトとゾーンオートシフト API を使用して、EKS クラスターのゾーンシフトを開始したり、ゾーンオートシフトを有効にしたりできます。 EKS クラスターでゾーンシフトをトリガーするには、まず AZ を選択し、次に EKS クラスター (バージョン 1.28 以降) を選択し、ゾーンシフトを有効にする有効期限を指定します。すると、ARC はゾーンシフトを開始し、選択した AZ からトラフィックを切り離します。ARC は、有効期限が切れるか、ユーザーがキャンセルした場合にゾーンシフトを終了します。ゾーンシフトが終了すると、トラフィックは EKS クラスターに接続されているすべての正常な AZ に戻ります。 EKS クラスターのゾーンオートシフトを有効にすると、AZ が異常であることを ARC が検出したときに、AWS がユーザーに代わってトラフィックを切り離すことを許可することになります。ARC は内部テレメトリを使用して、AWS ネットワーク、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Elastic Load Balancing (ELB) サービスなど、さまざまなソースからの重要なヘルスメトリクスを監視しています。ARC は、影響を受けた AZ が再び正常状態になったことがテレメトリで示されると、ゾーンオートシフトを終了します。これにより、EKS クラスターに接続されているすべての正常な AZ にトラフィックが返されます。 ARC ゾーンシフトとゾーンオートシフトを利用する理由 AWS グローバルクラウドインフラストラクチャ は、各 AWS リージョンが完全に分離された複数の AZ で構成されているため、耐障害性とレジリエンスを提供します。このマルチ AZ アーキテクチャを活用することは、リージョンに高可用性アプリケーションを実装するために不可欠です。Amazon EKS では、複数の AZ にデプロイすることで可用性の高いアプリケーションを迅速に開発できますが、スケーラブルでパフォーマンスが高く、信頼性の高い方法で AZ の障害に対処するには、構築と保守に多大な労力を要するカスタムソリューションを実装する必要があります。 もう 1 つの課題は、シミュレーションが難しいことが多い AZ 障害シナリオのテストです。テストが不十分だと、環境内の AZ で異常が生じたとき、予期せぬワークロードの動作に陥る可能性があります。 ARC ゾーンシフトまたはゾーンオートシフトを用いると、障害のある AZ で実行されているクラスターワーカーノードと Pod を一時的に隔離し、クラスター内のネットワークトラフィックをそれらから自動的に切り離して、ワークロードの耐障害性と可用性を向上させることができます。 さらに、ゾーンシフトとゾーンオートシフト機能を使用することで、AZ 障害の計画と対応に伴うチームのオペレーションオーバーヘッドを削減できます。 仕組み EKS クラスターを ARC リソースとして登録すると、ARC を使用してクラスターのゾーンシフトをトリガーしたり、もしくはクラスターのゾーンオートシフトを有効にしたりできます。ARC がゾーンシフトを実行すると、クラスターは次のような変更を受けます。 Kubernetes スケジューラ が異常な AZ のノードに新しい Pod をスケジュールできないように、影響を受けた AZ のノードは cordon (スケジュール対象外としてマーク) されます。 マネージドノードグループ (MNG) を使用している場合、 アベイラビリティゾーンの再調整 は一時停止され、 Auto Scaling グループ (ASG) が更新されて、新しい Amazon EKS のデータプレーンノードが正常な AZ でのみ起動されるようになります。Karpenter と Kubernetes の Cluster Autoscaler は、ARC ゾーンシフトとゾーンオートシフトをネイティブでサポートしていません。正常に動作している AZ のみに新しいノードをプロビジョニングするよう自動スケーリングツールを再構成する必要があります。新しいノードの起動に特定の AZ のみを使用するように Karpenter と Cluster Autoscaler を設定する方法については、 Amazon EKS ベストプラクティスガイド を参照してください。 異常な AZ のノードは終了されません。したがって、影響を受けた AZ の Pod は削除されません。これは、ゾーンシフトの期限が切れたりキャンセルされたときに、トラフィックがフルキャパシティーの状態の AZ に安全に戻るようにするためです。 EndpointSlice controller は、障害のある AZ 内のPod の Endpoint を検出し、それらを関連するEndpointSlice リソースから削除します。これにより、ネットワークトラフィックが正常な AZ の Pod の Endpoint のみを対象とすることが保証されます。Endpoint slice controller は、ゾーンシフトがキャンセルまたは期限切れになると、復元された AZ の Endpoint を含むように Endpoint slice を更新します。 次の図は、Amazon EKS 環境における AZ の異常が生じた場合の east-to-west (クラスター内部) のトラフィックフローを示しています。このようなシナリオでは、ネットワークパケットのドロップやネットワーク遅延が発生する可能性があります。 次の図は、障害のある AZ からトラフィックを切り離した場合の Amazon EKS 環境を示しています。 ゾーンシフトとゾーンオートシフトのための EKS クラスターとワークロードの準備 Amazon EKS でゾーンシフトとゾーンオートシフトが正常に動作するようにするには、事前に AZ 障害に強いクラスター環境を準備する必要があります。以下は、 EKS クラスターに実装する必要がある重要なステップのリストです。これらのステップについては、 Amazon EKS のドキュメント で詳しく説明されています。 クラスター内のワーカーノードを複数の AZ に分散します。 単一の AZ の削除に耐えられるだけの十分なコンピューティングキャパシティをプロビジョニングしてください。AZ 障害に耐えられるアプリケーションの構築方法の詳細については、 静的安定性 に関する AWS のドキュメントを参照してください。 すべての AZ で、Pod を事前にスケーリングしてください。これらの Pod には、アプリケーション Pod と、CoreDNS、Cluster Autoscaler、 AWS Load Balancer Controller などのコントローラー Pod が含まれます。これを実現する方法の詳細については、 Amazon EKS のドキュメント を参照してください。 Pod レプリカを複数の AZ をまたいで分散させて、単一の AZ を切り離しても十分な容量が残るようにします。これを実現するには、Topology spread constraints が役立ちます。 クラスターで実行されているコントローラーやその他のアプリケーションの高可用性 (HA) をサポートするためにリーダーの選出が必要な場合は、ポッドの数が奇数であるか、ポッドが 2 つ以上であるなどの基準が、AZ 障害イベント中および発生後に一貫して満たされていることを確認してください。 ロードバランサーを使用して外部トラフィックを Kubernetes の Service にルーティングする場合は、ALB と NLB のみを使用することをお勧めします。 AWS Load Balancer Controller を使用してロードバランサーを管理することもお勧めします。AWS Load Balancer Controller はインスタンスと IP トラフィックモードをサポートしていますが、そのうちの IP モードが推奨されます。インスタンスと IP モードの詳細については、 AWS Load Balancer Controller のドキュメント を参照してください。 Amazon EKS のゾーンシフトによってアプリケーションとクラスター環境が正常に回復するには、前述のステップが不可欠です。さらに、AZ 障害を効果的に管理するには、以下のベストプラクティスをお勧めします。 Topology Aware Routing などの Kubernetes 機能を使用するか、 サービスメッシュ と統合することで、Pod 間の通信を同じ AZ 内に限定します。 同じ AZ 内に、相互に依存するアプリケーションとサービスを配置します。これは Pod Affinity rule で実現できます。 マルチ AZ オブザーバビリティ を実装します。 アプリケーションでは、データベース、サービスなどの外部依存関係に対するタイムアウト値を適切に設定し、再試行を実装してください。障害を正常に処理するには、エクスポネンシャルバックオフパターンを備えたサーキットブレーカーを実装してください。 ゾーンシフトとゾーンオートシフトをサポートするようにクラスターとワークロードを準備する方法、およびゾーンシフトとゾーンオートシフトに関するその他のベストプラクティスの詳細については、 Amazon EKS ドキュメント を参照してください。 さらに、ワークロードが AZ 障害を処理できることを定期的にテストして検証することを強くお勧めします。ゾーンシフトを手動でトリガーするか、ゾーンオートシフトを有効にして、クラスター環境の AZ を 1 つ減らしてワークロードが期待どおりに機能することを確認することで、AZ 障害をテストできます。 始めてみよう ARC ゾーンシフト機能の説明に使用するサンプルアプリケーションを準備しました。このウォークスルーでは、既存の EKS クラスターを使用するか、 新しいクラスターを作成 できます。クラスターとそのクラスターに設定されているノードグループは、3 つの AZ にまたがり、各 AZ に少なくとも 1 つのノードが必要です。 1. サンプルアプリケーションをデプロイする a. まず、EKS クラスターにサンプルアプリケーションをデプロイします。Kubernetes Secret を作成するときは、必ず有効なユーザー名とパスワードを指定してください。この Secret は、MySQL データベースとそれに接続するアプリケーションの両方で使用されます。 kubectl create secret generic catalog-db --from-literal=username=<<有効なユーザー名で置換>> --from-literal=password=<<有効なパスワードで置換>> cat << EOF > catalog_deploy.yaml --- apiVersion: v1 kind: ConfigMap metadata: name: catalog data: DB_ENDPOINT: catalog-mysql-0.catalog-mysql:3306 DB_READ_ENDPOINT: catalog-mysql-0.catalog-mysql:3306 DB_NAME: catalog --- apiVersion: v1 kind: Service metadata: name: catalog-mysql labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql spec: clusterIP: None ports: - port: 3306 targetPort: mysql protocol: TCP name: mysql selector: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql --- apiVersion: v1 kind: ServiceAccount metadata: name: catalog labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample app.kubernetes.io/managed-by: Helm --- apiVersion: v1 kind: Service metadata: name: catalog labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample app.kubernetes.io/managed-by: Helm spec: type: ClusterIP ports: - port: 80 targetPort: http protocol: TCP name: http selector: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample --- apiVersion: apps/v1 kind: Deployment metadata: name: catalog labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample app.kubernetes.io/managed-by: Helm spec: replicas: 3 strategy: rollingUpdate: maxUnavailable: 1 type: RollingUpdate selector: matchLabels: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample template: metadata: annotations: prometheus.io/path: /metrics prometheus.io/port: "8080" prometheus.io/scrape: "true" labels: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app.kubernetes.io/name: catalog serviceAccountName: catalog securityContext: fsGroup: 1000 containers: - name: catalog env: - name: DB_USER valueFrom: secretKeyRef: name: catalog-db key: username - name: DB_PASSWORD valueFrom: secretKeyRef: name: catalog-db key: password envFrom: - configMapRef: name: catalog securityContext: capabilities: drop: - ALL readOnlyRootFilesystem: true runAsNonRoot: true runAsUser: 1000 image: public.ecr.aws/aws-containers/retail-store-sample-catalog:0.8.1 imagePullPolicy: IfNotPresent ports: - name: http containerPort: 8080 protocol: TCP livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 periodSeconds: 3 resources: limits: memory: 256Mi requests: cpu: 128m memory: 256Mi volumeMounts: - mountPath: /tmp name: tmp-volume volumes: - name: tmp-volume emptyDir: medium: Memory --- apiVersion: apps/v1 kind: StatefulSet metadata: name: catalog-mysql labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql app.kubernetes.io/managed-by: Helm spec: replicas: 3 serviceName: catalog-mysql selector: matchLabels: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql template: metadata: labels: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app.kubernetes.io/name: catalog app.kubernetes.io/component: mysql containers: - name: mysql image: public.ecr.aws/docker/library/mysql:8.0 imagePullPolicy: IfNotPresent env: - name: MYSQL_ROOT_PASSWORD valueFrom: secretKeyRef: name: catalog-db key: password - name: MYSQL_DATABASE value: catalog - name: MYSQL_USER valueFrom: secretKeyRef: name: catalog-db key: username - name: MYSQL_PASSWORD valueFrom: secretKeyRef: name: catalog-db key: password volumeMounts: - name: data mountPath: /var/lib/mysql ports: - name: mysql containerPort: 3306 protocol: TCP volumes: - name: data emptyDir: {} --- EOF kubectl apply -f catalog_deploy.yaml b. Kubernetes マニフェストファイルをクラスターに適用すると、それぞれ catalog と catalog-mysql という名前の 2 つのアプリケーションが作成され、 catalog-mysql は MySQL データベースになります。次のステップに進む前に、Pod が実行状態であることを確認します (これには数分かかる場合があります)。 2. クラスターのゾーンシフトを有効にする a. Amazon EKS コンソールを開いてクラスターを選択し、次の図に示すように、 概要 (Overview) の ゾーンシフト (Zonal Shift) セクションに移動します。 b. 管理 (Manage) を選択し、 有効化 (Enabled) を選択し、変更を保存します。 3. アプリケーションを検証する a) default Namespace で利用可能な Service を一覧表示します。 kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE catalog LoadBalancer XX.XXX.XXX.XXX <pending> 80:31932/TCP 41m catalog-mysql ClusterIP None <none> 3306/TCP 41m b) catalog Service への kubectl port-forward をバックグラウンドモードで実行します。プロセスのプロセス ID を書き留めておきます。 kubectl port-forward svc/catalog 8090:80 > /dev/null & [1] 42306 c) curl を使用して catalog Service を呼び出すと、以下に示すように、いくつかのアイテム ID を返すことを確認します。 curl -s localhost:8090/catalogue | jq -r '.[0,1].id' 510a0d7e-8e83-4193-b483-e27e09ddc34d 6d62d909-f957-430e-8689-b5129c0bb75e # port-forward プロセスを終了 (42306) kill -9 <<kubectl port-forward プロセスのプロセスID>> 4. クラスター・トポロジーを理解する アプリケーションが正常に動作していることを確認できたので、ゾーンシフトを実行する準備が整いました。ただし、ゾーンシフトをトリガーする前に、クラスターのトポロジーを理解する必要があります。これには、Pod が稼働している AZ を特定することが含まれます。 a. リージョンの AZ ID を一覧表示します。この例では、リージョンは us-west-2 なので、us-west-2 の AZ ID を確認できます。 aws ec2 describe-availability-zones --query 'AvailabilityZones[*].[ZoneName, ZoneId]' --output text us-west-2a usw2-az2 us-west-2b usw2-az1 us-west-2c usw2-az3 us-west-2d usw2-az4 b. 次のコマンドを使用して、クラスター内の各ノードとそれが動作している AZ を特定する必要があります。次のコマンドを入力すると、ノード名とノードが実行されている AZ のリストが出力されるはずです。この例では、3 つのノードが 3 つの AZ (us-west-2b、us-west-2b、us-west-2c) に分散しています。 kubectl get nodes -o=jsonpath='{range .items[*]}"{.metadata.name}"{"\t"}"{.metadata.labels.topology\.kubernetes\.io/zone}"{"\n"}{end}' | sort -k 1 > nodes-info.txt cat nodes-info.txt "ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal" "us-west-2a" "ip-YYY-YYY-YYY-YYY.us-west-2.compute.internal" "us-west-2b" "ip-ZZZ-ZZZ-ZZZ-ZZZ.us-west-2.compute.internal" "us-west-2c" c. 次のコマンドを使用して、各 Pod が現在実行されているノードと AZ を特定する必要があります。コマンドを入力すると、Pod 名、AZ、および Pod が実行されているノードを示す出力が生成されます。この場合、3 つの AZ の 3 つのノードに分散されたカタログアプリケーションポッドがあります。 kubectl get pods -l "app.kubernetes.io/component"=service -o=jsonpath='{range .items[*]}"{.metadata.name}"{"\t"}"{.spec.nodeName}"{"\n"}{end}' | sort -k 2 > pods-info.txt join -1 1 -2 2 nodes-info.txt pods-info.txt "ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal" "us-west-2b" "catalog-74957c74ff-xxxxx" "ip-YYY-YYY-YYY-YYY.us-west-2.compute.internal" "us-west-2c" "catalog-74957c74ff-yyyyy" "ip-ZZZ-ZZZ-ZZZ-ZZZ.us-west-2.compute.internal" "us-west-2a" "catalog-74957c74ff-zzzzz" 5. ゾーンシフトをトリガーする これで、クラスター・トポロジーを十分に理解できたはずです。次に、ゾーンシフトをトリガーしてトラフィックを AZ から切り離し、ゾーンシフト機能をテストします。 a. 次の図に示すように、ARC コンソールを開き、 ゾーンレベルの移行 (Zonal Shift) を選択します。 b. 次の図に示すように、ゾーンシフトを開始するために、トラフィックを切り離す AZ (us-west-2b)、ゾーンシフトを実行する EKS クラスタ、有効期限 (10 分) を選択して、そして 開始 (Start) を選択します。 ゾーンシフトは、トリガーしてから完了するまでに数分かかります。そのため、数分待ってからテストすることをお勧めします。 c. アプリケーションの Endpoint へのトラフィックを生成してアプリケーションを検証し、トラフィックを切り離した AZ で実行されている Pod に対して呼び出しが行われていないことを確認します。そのためには、まず Kubernetes Job を実行してアプリケーションへのトラフィックを生成し、次にトラフィックを処理する Pod とそれらが属する AZ をログから特定します。次のコマンドを入力すると、catalog Service へのトラフィックが 2 つの Pod に分散されていることがわかります。 kubectl create job curl-job --image=curlimages/curl -- /bin/sh -c "while true; do curl -s catalog.default/catalogue; sleep 1; done" start_time=$(date -u +"%Y-%m-%dT%H:%M:%SZ") # 20-30秒間待つ kubectl logs -l "app.kubernetes.io/component"=service --prefix --since-time=$start_time --tail=50 | grep -i "/catalogue" | cut -d '/' -f 2 | sort | uniq -c > pod-logs.txt cat pod-logs.txt 5 catalog-78679df9c4-xxxx 6 catalog-78679df9c4-zzzz d. Pod の位置を確認すると、どの Pod も AZ us-west-2b (ゾーンシフトによってトラフィックが迂回された AZ) で稼働していないことがわかります。 join -1 1 -2 2 nodes-info.txt pods-info.txt | tr -d \" | sort -k 3 > pods-nodes-az.txt join -1 3 -2 2 pods-nodes-az.txt pod-logs.txt catalog-74957c74ff-xxxx ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal us-west-2a 5 catalog-74957c74ff-zzzz ip-ZZZ-ZZZ-ZZZ-ZZZ.us-west-2.compute.internal us-west-2c 6 e. 先に進む前に、トラフィックを生成するために作成した Kubernetes Job を削除します。 kubectl delete job curl-job 6. ゾーンシフトをキャンセルする a. 次の図に示すように、以前に作成したゾーンシフトを選択し、 ゾーンシフトをキャンセル (Cancel zonal shift) を選択して、ゾーンシフトのキャンセルをテストします。 ゾーンシフトのキャンセルは、トリガーしてから完了するまでに数分かかります。そのため、数分待ってからテストすることをお勧めします。 b. アプリケーションへのトラフィックを生成し、AZ で動作している Pod がトラフィックを受信していることを確認できます。 kubectl create job curl-job --image=curlimages/curl -- /bin/sh -c "while true; do curl -s catalog.default/catalogue; sleep 1; done" start_time=$(date -u +"%Y-%m-%dT%H:%M:%SZ") # 20-30秒間待つ kubectl logs -l "app.kubernetes.io/component"=service --prefix --since-time=$start_time --tail=50 | grep -i "/catalogue" | cut -d '/' -f 2 | sort | uniq -c > pod-logs.txt cat pod-logs.txt 9 catalog-78679df9c4-xxxx 7 catalog-78679df9c4-yyyy 5 catalog-78679df9c4-zzzz join -1 1 -2 2 nodes-info.txt pods-info.txt | tr -d \" | sort -k 3 > pods-nodes-az.txt join -1 3 -2 2 pods-nodes-az.txt pod-logs.txt catalog-74957c74ff-xxxx ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal us-west-2a 9 catalog-74957c74ff-yyyy ip-YYY-YYY-YYY-YYY.us-west-2.compute.internal us-west-2b 7 catalog-74957c74ff-zzzz ip-ZZZ-ZZZ-ZZZ-ZZZ.us-west-2.compute.internal us-west-2c 5 # kubernetes job を削除する kubectl delete job curl-job 7. クラスターのゾーンオートシフトを設定します a. ゾーンオートシフトを設定する前に、ARC が練習実行が成功のうちに完了したかどうかを検査するために用いる Amazon CloudWatch アラームを設定する必要があります。ARC ゾーンオートシフトの練習実行の詳細については、この ドキュメント を参照してください。 b. 次の図に示すように、ARC コンソールを開き、 ゾーンオートシフトを設定 (Configure zonal autoshift) を選択します。 c. ゾーンオートシフトの設定するリソース (Resource to configure) として EKS クラスターを選択し、ゾーンオートシフトのステータス (Zonal autoshift status) で 有効化 (Enable) を選択し、CloudWatch アラーム ARN を入力して 作成 (Create) を選択します。次の図に示すように、コンソールのオプションセクションはそのままにしておきます。 d. ARCは、練習実行の一環として、週に1回、ゾーンオートシフトを実施します。Amazon EventBridge との統合を用いて、ゾーンオートシフトと練習実行の通知を受け取ることができます。練習実行中に、ゾーンシフトの検証に使用したのと同じ検証手順をゾーンオートシフトに適用できます。 ゾーンシフトとオートシフトにより、AZ 障害からの迅速な回復と Amazon EKS ワークロードの信頼性の向上が可能になります。AZ 障害に対して真に回復力を発揮するには、ワークロードがゾーンシフトやゾーンオートシフト機能を使用するだけでなく、「クラスターとワークロードの準備」セクションで概説されているプラクティスを遵守して AZ 障害からの回復も行う必要があります。 後片付け 今後のコストを避けるため、この演習用に作成された EKS クラスターなどのリソースをすべて削除してください。次のコマンドは、ゾーンシフトをテストするために以前にインストールしたアプリケーションを削除します。 kubectl delete -f catalog_deploy.yaml kubectl detelet secret catalog-db rm nodes-info.txt pods-info.txt pod-logs.txt pods-nodes-az.txt 価格と提供リージョン Amazon EKS の ARC ゾーンシフトおよびゾーンオートシフト機能の対応は、中国と GovCloud リージョンを除くすべての AWS リージョンで利用できます。EKS クラスターでゾーンシフトを有効にしてゾーンシフトをトリガーしても、追加のコストは発生しません。ただし、Pod やクラスターノードの事前スケーリングなど、ワークロードが AZ 障害を確実に処理できるようにするために、追加のコストがかかる場合があります。 まとめ この投稿では、ARC ゾーンシフトおよびゾーンオートシフト機能を使用して、単一の AZ 障害から回復する方法を説明しました。入念な計画と実装を行うことで、ゾーンシフトとゾーンオートシフトの可能性を最大限に活用して、単一の AZ 障害から Amazon EKS クラスターで実行されているアプリケーションとデータソースを保護できます。 Amazon EKS のゾーンシフトとゾーンオートシフトの詳細については、 Amazon EKS のドキュメント を参照してください。 GitHub でホストされている AWS Containers Roadmap にコメントを残したり、Issue を投稿したりすることで、EKS クラスターの ARC ゾーンシフト機能に関するフィードバックを提供できます。今後も機能を進化させ、ユーザーがクラスターの耐障害性と可用性を向上させるのに役立つさまざまな方法を模索していきますので、ご期待ください。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。

この記事は Getting started with Amazon EKS Auto Mode (記事公開日: 2024 年 12 月 3 日) を翻訳したものです。 この記事は、Alex Kestner (Amazon EKS シニアプロダクトマネージャー) 、Ashley Ansari (シニアプロダクトマーケティングマネージャー) 、Robert Northard (コンテナプリンシパル GTM SSA) 、Sheetal Joshi (コンテナプリンシパルソリューションアーキテクト) の共著です。 はじめに Kubernetes クラスターにおけるコンピューティング、ストレージ、ネットワーキングを効率的に管理する新機能、 Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode の一般提供を発表しました。この機能により、クラスターを迅速に構築し、パフォーマンスを向上させ、管理の手間を減らすことができます。クラスター管理を AWS に任せることで、アプリケーションの構築に集中してイノベーションの推進に注力いただけます。 Amazon EKS Auto Mode は、インフラストラクチャの自動プロビジョニング、最適なコンピューティングインスタンスの選択、リソースの動的スケーリング、コスト最適化のために継続的なコンピューティングの最適化、オペレーティングシステム (OS) のパッチ適用、AWS セキュリティサービスとの統合により、Kubernetes クラスター管理を効率化します。有効にすると、EKS Auto Mode は AWS のベストプラクティスに基づいてクラスター機能を設定し、アプリケーションのデプロイに最適な状態でクラスターを準備します。 この記事では、EKS Auto Mode の高レベルアーキテクチャを紹介し、EKS Auto Mode を使用して高可用性かつ自動スケーリング機能を備えたサンプルアプリケーションをデプロイする手順を紹介します。 新機能の紹介 Amazon EKS は長らく、Kubernetes を実行するための安全な方法として信頼されてきました。EKS Auto Mode 以前は、マネージドのコントロールプレーンがあるにもかかわらず、本番環境相当の Kubernetes アプリケーションを実行するために必要なインフラストラクチャを管理するには、専門的な知識と継続的な労力が求められていました。具体的には、ユーザーはリソース効率とコストを最適化するための適切な Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの選択とプロビジョニングから、プラグインのインストールとメンテナンスまで、継続的なメンテナンス活動を行わなければなりませんでした。以下の図に示すように、インフラのセキュリティと最新性を維持するため、クラスターのアップグレードや OS のパッチ適用も並行して管理しなければなりませんでした。 Before Auto Mode EKS Auto Mode によるクラスター運用の完全自動化は、本番環境レベルの Kubernetes インフラ管理に必要な専門知識の依存度を大幅に低減し、ユーザーの時間と労力を大きく節約します。EC2 インスタンスの選定やプロビジョニング、リソースとコストの最適化、プラグインのメンテナンスといった作業にユーザーが時間とリソースを費やす必要がなくなりました。 EKS Auto Mode を有効にして新規に EKS クラスターを作成するか、既存のクラスターを更新すると、Amazon EKS は自動的に必要な処理を行います。具体的には、コンピューティング、ネットワーキング、ストレージ機能に必要なコントローラーを、Amazon EKS 専用の AWS アカウントと VPC 内にデプロイします。これはマネージドな Kubernetes コントロールプレーンと併せて実施されます。 アプリケーションのデプロイ時には、EKS Auto Mode が自動的に Bottlerocket OS ベースの EC2 インスタンスと Elastic Load Balancing (ELB) を起動し、ユーザーの AWSアカウントと指定された VPC 内に Amazon EBS ボリュームをプロビジョニングします。さらに、これらの EC2 インスタンスのライフサイクル管理、実行時のアプリケーション要件に応じたデータプレーンのスケーリングと最適化、不健全なノードの自動置換を行います。下図が示すように、EKS Auto Mode は、Amazon EC2 の豊富な機能や柔軟性を損なうことなく、管理されたインフラストラクチャを提供します。 After Auto Mode EKS Auto Mode の導入により、これまで Kubernetes DaemonSet として動作していたノード管理機能が、AWS が管理するシステムプロセスとして実行できるようになりました。具体的には、サービスディスカバリー、ロードバランシング、Pod ネットワーキング、ブロックストレージ、認証情報の提供などの機能が含まれます。AWS がこれらのコンポーネントのライフサイクル管理を担当し、セキュリティ更新を行い、最新のコンポーネントを組み込んだ EKS Auto Mode 用の Amazon Machine Image (AMI) を定期的にリリースします。 また、EKS Auto Mode はクラスターのアップグレードと OS の更新を自動的に行います。この際、ユーザーが定義した Kubernetes のスケジューリング制約を考慮しながら、ノードを段階的に置き換えることで、インフラのセキュリティと最新性を維持します。これにより運用の負担が大幅に軽減され、開発チームはインフラ管理ではなく、アプリケーション開発に注力できるようになります。 はじめ方 EKS Auto Mode は、Kubernetes バージョン 1.29 以降を実行している新規および既存の EKS クラスターで利用可能になりました。EKS Auto Mode を始めるには、新しいコンソール機能 [Quick Configuration (クイック設定) ]が便利です。この機能を使えば、最適なデフォルト設定が予め構成されたクラスターをワンクリックで迅速に立ち上げることができます。あるいは、Amazon EKS API、 AWS マネジメントコンソールのカスタム設定 、 eksctl、お好みの Infrastructure as code (IaC) ツールを使用することも可能です。 このセクションでは、EKS Auto Mode が Amazon EKS 上でのアプリケーションデプロイをいかに簡素化するかを実際に示します。まず、EKS Auto Mode を有効にして EKS クラスターを作成し、その後サンプルの小売店アプリケーションをデプロイします。EKS Auto Mode が新しいノードを自動的に起動し、AWS Load Balancer をセットアップし、永続的なストレージ要件を管理し、アプリケーションの自動スケーリングニーズを処理する様子をご覧いただけます。 事前準備 本記事で紹介する手順を実行するには、以下の準備が必要です： AWSアカウント：管理者権限を持つAWSアカウントをお持ちであることを前提としています。 以下のツールをインストールしてください： Helm 3.9+ 、 kubectl 、 eksctl 、 AWS Command Line Interface (AWS CLI) クラスターの作成 本記事では、EKS クラスターを簡単に作成できるコマンドラインツールである eksctl を使用します。以下に示す設定例では、eksctl を使ってクラスターインフラストラクチャとアプリケーションデプロイ用のサブネットを自動生成します。もしこのサンプル設定を使用しない場合は、 Amazon EKS ユーザーガイド に記載されている前提条件を全て確認してください。特に、クラスター IAM ロールとノード IAM ロールの変更が必要となります。これらの変更により、EKS Auto Mode がユーザーのアカウント内で EC2 インスタンスを管理するための新しい権限が付与されます。 今回のセットアップでは、あらかじめ用意されている general-purpose (汎用) ワークロードとsystem (システム) ワークロード用のマネージドな NodePool を使用して EKS Auto Mode を有効化します。general-purpose NodePool は汎用的なワークロードの起動をサポートし、system NodePool はアドオンを処理します。両方とも、C、M、R ファミリーの amd64 アーキテクチャを持つオンデマンド EC2 インスタンス (第5世代以降) を使用します。マネージドな NodePool の詳細については、 EKS Auto Mode ユーザーガイド を参照してください。 cat << EOF > cluster.yaml apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: eks-auto-mode-demo region: us-west-2 version: "1.31" addonsConfig: disableDefaultAddons: true autoModeConfig: enabled: true nodePools: ["general-purpose", "system"] EOF eksctl create cluster -f cluster.yaml クラスターの状態が Active  になるまでお待ちください。 aws eks describe-cluster --name eks-auto-mode-demo --output json --query 'cluster.status' これでクラスターの準備が整い、アプリケーションをデプロイできる状態になりました。次のセクションでは、EKS Auto Mode を使用することで、アプリケーションのデプロイがいかに簡素化されるかを実際に見ていきましょう。 アプリケーションのデプロイ 今回使用する サンプルアプリケーション は、オンラインショッピングの機能を模しています。ユーザーは商品カタログを閲覧し、商品をカートに追加し、チェックアウトプロセスを経て注文を完了することができます。このアプリケーションは、UI、カタログサービス、注文サービス、カートサービス、チェックアウトサービスなど、複数のコンポーネントで構成されています。また、永続的なストレージを必要とするバックエンドデータベースも含まれています。これらのコンポーネントは、Kubernetes の Deployment と StatefulSet を用いて実装されています。アプリケーションへのアクセスには、Kubernetes Ingress を使用してクラスター外からのアクセスを可能にします。また、カタログアプリケーションにはAmazon EBS 永続ストレージを使用するよう設定します。 EKS Auto Mode のパフォーマンス向上、スケーラビリティ、可用性の強化を実証するため、UI アプリケーションには特別な設定を行います。具体的には、 Horizonal pod Autoscaling (HPA) 、 Pod Topology Spread Constraints 、 Pod Disruption Budgets (PDB) をサポートするよう構成します。これらの設定により、EKS Auto Mode がもたらす利点を具体的に示すことができます。 アプリケーションのデプロイに進む前に、まずはクラスターの状態を確認しておきましょう。 kubectl get nodes kubectl get pods 現時点では、ノードと Pod のリストが空であることが確認できました。 アプリケーションのデプロイに進む前に、StorageClass とIngressClass を作成します。これらの設定は、後ほどデプロイするアプリケーションが必要とするストレージと Ingress の要件を満たすための基盤となります。一般的に、この作業はクラスター作成直後にプラットフォームチームが一度だけ実施するものです。この設定を行うことで、アプリケーションのデプロイがスムーズに進み、必要なリソースがすぐに利用可能になります。 cat >ingress.yaml <<EOF --- apiVersion: eks.amazonaws.com/v1 kind: IngressClassParams metadata: name: eks-auto-alb spec: scheme: internet-facing --- apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: eks-auto-alb spec: controller: eks.amazonaws.com/alb parameters: apiGroup: eks.amazonaws.com kind: IngressClassParams name: eks-auto-alb EOF kubectl apply -f ingress.yaml cat >ebs-sc.yaml <<EOF --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: eks-auto-ebs-csi-sc annotations: storageclass.kubernetes.io/is-default-class: "true" provisioner: ebs.csi.eks.amazonaws.com volumeBindingMode: WaitForFirstConsumer parameters: type: gp3 EOF kubectl apply -f ebs-sc.yaml アプリケーションのデプロイには Helm を使用します。まず、先ほど説明したアプリケーションの要件を指定するための values.yaml ファイルを作成しましょう。 cat >values.yaml <<EOF catalog: mysql: secret: create: true name: catalog-db username: catalog persistentVolume: enabled: true accessMode: - ReadWriteOnce size: 30Gi storageClass: eks-auto-ebs-csi-sc ui: endpoints: catalog: http://retail-store-app-catalog:80 carts: http://retail-store-app-carts:80 checkout: http://retail-store-app-checkout:80 orders: http://retail-store-app-orders:80 assets: http://retail-store-app-assets:80 autoscaling: enabled: true minReplicas: 5 maxReplicas: 10 targetCPUUtilizationPercentage: 80 topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app: ui - maxSkew: 1 topologyKey: kubernetes.io/hostname whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app: ui ingress: enabled: true className: eks-auto-alb EOF それでは、小売店アプリケーションのデプロイを行いましょう。デプロイを進める際は、values.yaml ファイルの設定内容に注意を払ってください。特に重要なのは、UI のエンドポイントの設定です。もし、デフォルトの retail-store-app とは異なるチャート名を使用している場合は、必ずエンドポイントの設定を適切に更新してください。 helm install -f values.yaml retail-store-app oci://public.ecr.aws/aws-containers/retail-store-sample-chart --version 0.8.3 EKS Auto Mode は、デプロイされた Pod のリソース要求を分析し、アプリケーションの実行に最適なコンピューティングリソースを判断します。この過程で、ユーザーが設定したスケジューリング制約 (トポロジー分散制約を含む) が考慮されます。EKS Auto Mode は general-purpose のマネージド NodePool を利用してノードを起動します。ノードが Ready になるまで待ちます。 kubectl wait --for=condition=Ready nodes --all 別のターミナルで、アプリケーションが使用可能な状態になるのを監視します。 kubectl wait --for=condition=available deployments --all 小売店アプリケーションのコンポーネントは実行中の状態になっているはずです。 catalog-mysql-ebs StatefulSetを調べると、EKS Auto Mode が 30 GiB の PersistentVolumeClaim を作成し、 storageClassName が eks-auto-ebs-csi-sc であることがわかります。 kubectl get statefulset retail-store-app-catalog-mysql \ -o jsonpath='{.spec.volumeClaimTemplates}' | jq . Output: [ { "apiVersion": "v1", "kind": "PersistentVolumeClaim", "metadata": { "creationTimestamp": null, "name": "data" }, "spec": { "accessModes": [ "ReadWriteOnce" ], "resources": { "requests": { "storage": "30Gi" } }, "storageClassName": "eks-auto-ebs-csi-sc", "volumeMode": "Filesystem" } } ] EKS Auto Mode は UI アプリケーション用に Application Load Balancer (ALB) を自動的に作成しました。以下のコマンドで ALB 名を確認できます。ALB の準備ができたら、ウェブブラウザでそのリンクにアクセスできます。小売店のホームページが表示されるはずです。 kubectl get ingress retail-store-app-ui -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}" Output: k8s-ui-uinlb-1111111111.elb.us-west-2.amazonaws.com アプリケーションのスケーリング アプリケーションのデプロイが完了したので、次は EKS Auto Mode によるスケーリング機能を見ていきましょう。EKS Auto Mode は HorizontalPodAutoscaler(HPA) と metrics-server を活用して、アプリケーションの需要に応じてクラスターのリソースを自動的に調整します。Kubernetes では、HPA は観測されたメトリクスに基づいて Deployment のレプリカ数を自動的に調整します。Metrics server は kubelet から CPU とメモリ使用量を収集し、Kubernetes API サーバーを通じて HPA に公開します。HPA はこれらのメトリクスを継続的に監視し、指定されたターゲットに一致するようにレプリカ数を調整します。 まず、Kubernetes metrics-server をデプロイします。 kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml この例では、UI サービスを使用し、CPU 使用率 (80 %) に基づいてスケーリングし、maxReplicas を 10 に設定します。なお、HPA の設定はアプリケーションのインストール時にすでに適用されています。具体的な設定内容は、 values.yaml ファイルの AutoScaling セクションで確認できます。現在の AutoScaling ポリシーは、以下のコマンドで確認することができます。 kubectl get hpa retail-store-app-ui 次に、設定した AutoScaling ポリシーがどのように機能するかを確認するため、負荷をかけてみましょう。これにより、EKS Auto Mode がクラスターのインフラストラクチャをどのようにスケールアウトするかを実際に観察できます。 kubectl run load-generator \ --image=public.ecr.aws/amazonlinux/amazonlinux:2023 \ --restart=Never — /bin/sh -c "while sleep 0.01; do curl http://retail-store-app-ui/home; done" アプリケーションに対してリクエストが発生しているので、この負荷に応じて EKS Auto Mode がどのように対応するか観察しましょう。新しいノードが起動し、UI Pod の数が増加する様子を確認できるはずです。 kubectl get nodes --watch Output: NAME STATUS ROLES AGE VERSION i-00018eaec7a3d5370 Ready <none> 155m v1.31.0-eks-672e808 i-043c71a371a8514a1 Ready <none> 155m v1.31.0-eks-672e808 HPA リソースを監視して、その進行状況を追跡できます。 kubectl get hpa retail-store-app-ui --watch Output: NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE retail-store-app-ui Deployment/retail-store-app-ui cpu: 158%/80% 3 10 5 16m retail-store-app-ui Deployment/retail-store-app-ui cpu: 161%/80% 3 10 6 16m retail-store-app-ui Deployment/retail-store-app-ui cpu: 148%/80% 3 10 9 16m ご覧の通り、EKS Auto Mode はアプリケーションの需要に基づいてクラスターインフラストラクチャを完全に管理し、動的にスケーリングします。Pod を終了させることで、負荷テストを停止できます。負荷生成の Pod が終了すると、HPAは設定に基づいてレプリカ数を徐々に最小数まで減らしていきます。 kubectl delete pod load-generator 主要な考慮事項 Amazon EKS Auto Mode でワークロードを展開する際に考慮すべき主なポイントは以下の通りです： Pod Disruption Budgets を設定し、自発的な中断からワークロードを保護する ：EKS Auto Mode が使用率の低いノードを停止させるような自発的な中断時に、Pod Disruption Budgets は Deployment のレプリカが中断される割合を制御し、一定のワークロード容量を維持してサービスの継続性を確保します。 高可用性を実現するため、レプリカをノードとアベイラビリティーゾーン間に分散させる ：Pod トポロジー分散制約を使用してワークロードをノード間に分散させ、同じノード上で Deployment の複数のレプリカが実行される可能性を最小限に抑えます。 適切なリソース要求と制限を設定する ：EKS Auto Mode はワークロードの vCPU とメモリ要求に基づいて EC2 インスタンスを起動します。リソースの過剰プロビジョニングを避けるため、リソース要求は慎重に設定する必要があります。EKS Auto Mode は リソース制限 や実際の使用量を考慮しないことに注意してください。 アプリケーションは正常なシャットダウン処理を実装する ：自発的な中断の間に作業の損失やユーザー体験の中断を防ぐため、アプリケーションは SIGTERM シグナルを適切に処理して正常にシャットダウンできる必要があります。Kubernetesが Pod の退避を決定すると、退避対象 Pod の各コンテナのメインプロセスに SIGTERM シグナルが送信されます。その後、SIGKILL が送信されるまでの猶予期間 (デフォルトは 30 秒) が設けられます。この猶予期間は Pod 仕様の terminationGracePeriodSeconds で変更可能です。 コンピューティングリソースの選択に過度な制約を設けない ：general-purpose の NodePool は、c、m、r 系の EC2 インスタンスを様々なサイズで利用し、ワークロードに最適なインスタンスを選択する柔軟性を確保しています。特定のコンピューティング要件がある場合は、 Kubernetes の well-known Label を使用して、特定のインスタンスタイプやアーキテクチャなどの属性を指定できます。 アプリケーションのベストプラクティスについて詳しく知りたい場合は、Amazon EKS ベストプラクティスガイドの 信頼性セクション を参照してください。 リソースの削除 不要な料金が発生しないよう、この記事で作成したリソースを以下の手順で削除してください： kubectl delete deploy -n kube-system metrics-server helm uninstall retail-store-app kubectl delete pvc/data-retail-store-app-catalog-mysql-0 eksctl delete cluster —name eks-auto-mode-demo 結論 Amazon EKS Auto Mode は、コンピューティング、ストレージ、ネットワーキングの機能をすぐに利用できる形で提供し、アプリケーションデプロイの複雑さを大幅に軽減します。新規クラスターの作成時でも既存クラスターの更新時でも、EKS Auto Mode は効率的な体験を提供します。クラスターインフラの管理だけでなく、Kubernetes の標準に準拠しながら、核となるクラスター機能も提供します。 EKS Auto Mode は、既存の Amazon EKS サービスを補完し、多様なワークロードに対応する柔軟性を提供します。特定の要件がある場合、ユーザーは従来の Amazon EKS コンピューティングオプションを引き続き利用できます。これにより、Kubernetes クラスターのカスタム設定、クラスターインフラの手動プロビジョニングと管理、Kubernetes 環境の詳細な制御が可能です。Auto Mode と従来のオプションの両方をサポートすることで、Amazon EKS は幅広いニーズに対応します。簡素化と運用負荷の軽減を求めるユースケースから、Kubernetes 環境のカスタマイズや詳細な制御が必要なケースまで、様々な要求に応えることができます。 EKS Auto Mode の機能について詳しくは、 Amazon EKS のドキュメント をご覧ください。EKS Auto Mode の実際の動作を確認し、AWS の専門家に質問する機会を得るには、今後のウェビナーシリーズ「 Simplifying Kubernetes operations with Amazon EKS Auto Mode 」にご登録ください。 翻訳はクラウドサポートエンジニアの桐生が担当しました。原文は こちら です。

日進月歩の世界において、世界 20 カ国以上で事業を展開する多国籍消費財（ CPG ）企業は、どのようにしてイノベーションの最先端を走り続けているのでしょうか。 それが、世界最大級の飲料会社であるペルーの CPG 多国籍企業 AJE Group （ AJE ） が、本格的なデジタル変革に乗り出すことを決めたときに直面した課題でした。 2019 年まで、同社はタスクごとに分断されたオンプレミスのインフラ環境を使用しており、世界の多くの地域に分散していました。 AJE は、目標を達成するためには、プロセスを合理化し、リソースをより効率的に管理するために、一元化されたクラウドベースの企業データプラットフォームを構築する必要があると判断しました。 1 万人以上の従業員を抱え、グローバルに事業を展開する同社は、組織全体でデータドリブンな意思決定を強化するため、データソリューションのモダナイズも必要としていました。 「デジタルトランスフォーメーション戦略の一環として、より多くのイノベーションにつながるデータドリブンな文化を社内にもたらしたいと考えていました」と、AJE グループのグローバルデータ＆アナリティクス責任者である Wilmer Rodriguez Ruiz 氏は言います。 AJE は、Amazon Web Services （ AWS ）がこの 2 つの分野で最も適した候補であると判断しました。 「 AWS のソリューションを使うことで、ビジネスの成長戦略を促進し、組織内のパラダイムを変えることができます」と Rodriguez Ruiz 氏は言います。 Amazon Redshift を利用した企業データプラットフォームの構築 AJE は、組織全体のデータを保存、処理、分析するためのデータ分析ソリューションを AWS 上に構築しました。 同社は、 AWS Database Migration Service （ AWS DMS ）を使用して、複数の SQL データベースを AWS に移行しました。 DMS はデータ移行とレプリケーションのためのマネージドサービスで、これを使うことでデータベースと分析ワークロードを素早く安全に、かつ最小限のダウンタイムで、そして実質データロスなしに AWS に移行することができます。 同社はデータウェアハウスとして、 Amazon Redshift を使用しており、 SQL を使用してデータウェアハウス、オペレーショナルデータベース、データレイク全体の構造化データおよび半構造化データを分析しています。 Amazon Redshift は現在、同社のデータの単一かつ真のデータソースとなっています。 さらに、 Amazon Redshift はマネージドサービスであるため、AJE は SQL サーバーのために行わなければならなかった差別化につながらない重労働を減らすことができました。 「私たちのチームは、一般的なデータセンターを管理する必要がなくなり、生産性が向上しました。 当社のソリューションは、キャパシティニーズを満たすために、機能を拡張したり、新しいインスタンスを作成したりするだけです。」 AJE Group は、データ抽出のために AWS Glue を使用しています。これは、複数のソースからデータの発見、準備、移動、統合を簡単にするサーバーレスデータ統合サービスです。 AWS Glue は、業界をリードするスケーラビリティ、データの可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスである Amazon Simple Storage Service ( Amazon S3 ) からデータを取得し、Amazon Redshift での分析のためにデータを変換します。 AWS 上に新しい企業データプラットフォームを実装して以来、同社は抽出、変換、ロード（ ETL ）にかかる時間を 35% 短縮しました。 イノベーションのためのデータ可視性の拡大 AJE グループは現在、データレイクを構築するために AWS を利用しており、データソリューションとアナリティクスの両方の拡張を支えています。 グローバル市場に広がる多くの膨大な従業員を抱える組織にとって、中央データソースは職場文化におけるデータ中心の考え方を促進するために不可欠です。「私たちは、データドリブンの戦略を社内に定着させたいと考えています。 データレイクは、すべての意思決定がデータに基づいて行われるように、すべての組織のすべてのレベルに到達するのに役立ちます。」 と Rodriguez Ruiz 氏は言います。 使えるデータがあったとしても、そのデータから洞察や分析を引き出せる従業員がいて初めて生産性に繋がります。 AJE は、AWS を使ってデータプラットフォームを構築すると同時に、従業員にデータリテラシーを身につけさせ、定量的なツールをビジネス戦略に適用できるようにすることにも注力してきました。 「現在、データの分析と取扱に精通した 600 人以上の従業員の育成に成功しています。今後 1 年半のうちに、この数を 3 倍に増やし、組織内のあらゆる階層に行き渡らせたいと考えています」と Rodriguez Ruiz 氏は言います。 AJE のデジタルトランスフォーメーションは、日常業務、特に全部門にわたるデータの可視化において、すでに成果を上げています。 以前は、社内チームが必要なデータにアクセスするのに 4 ～ 5 時間待たなければなりませんでした。 今では、そのデータがほぼリアルタイムで届くため、社内チームはデータに基づいた迅速な意思決定を行えるようになりました。 また、AJE のビジネスアナリストは、コンサルテーションや費用対効果分析をより迅速に完了できるようになりました。 「私たちは、組織全体が自立するために必要なデータの可用性を実現しました。すべての部門が、会社のビジョンを達成するために最適な意思決定をするための情報を持っています。」と Rodriguez Ruiz 氏は言います。 AWS を使うことで、AJE は新しい市場に進出するためのスケーラビリティも向上しました。「クラウドを利用することで、プロセスの拡張が格段に速くなりました。これにより、ビジネスニーズに応じて他の国でも成長できるチャンスが広がりました。」と Rodriguez Ruiz 氏は言います。 データドリブンな未来への投資 デジタルトランスフォーメーションが進む中、AJE グループはビジネスを拡大するための革新的な方法を模索し続けています。 同社は現在も、従業員にデータ中心の文化を浸透させ、新たな機会を探るための分析ツールの使用を推進しています。 AI / ML の普及に伴い、AJE グループは独自のアナリティクスサービスソリューションの構築を計画しています。 「AWS を利用することで、データ分析における従業員の能力を向上させることができました。セルフサービスで予測分析や情報を提供できるようになるチャンスがあります。」と Rodriguez Ruiz 氏は言います。 詳しくは、 AJE グループのお客様事例 をご覧ください。 Kate Wiley Kate Wiley は、AWS の小売業界マーケティング責任者。 AWS 入社以前は、Dick’s Sporting Goods 、 Reebok 、 Drybar 、 Jenny Craig などの小売企業でマーケティングを担当。 Kate は、小売業界のマーケティング責任者として、クラウドを活用してブランドと消費者の緊密な関係を築き、オペレーションを最適化し、AWS を活用してデジタルトランスフォーメーションを加速させる方法について、小売業者のサポートと教育を担当しています。 翻訳は Solutions Architect 圓山が担当しました。原文は こちら です。

AWS re:Invent 2024 は、世界中から集まった参加者にとってイベント盛りだくさんの1週間となりました。カンファレンスの期間中、様々な業界のお客様が中心となり、自社の変革の道のりを共有しました。これらのストーリーは、組織がどのようにクラウドとAIを活用してカスタマーエクスペリエンス戦略を変革し、大きなビジネス成果を達成しているかを浮き彫りにしています。 Amazon Connect はまた、AI のパワーを活用し、オムニチャネル機能を強化する新機能の数々を発表しました。 注目のビジネスインパクト State Farm, Toyota, Air Canada, Coinbase, Amazon Customer Service, Frontdoor, Fujitsu, Pearson, NatWest などのお客様がステージに上がり、ストーリーを共有しました。これらのストーリーは、世界をリードする組織のいくつかが Amazon Connect を活用してビジネスを加速している様子を示しています。プレゼンテーションの動画を視聴するには、以下の各企業のリンクをクリックしてください。 イノベーショントーク: カスタマーサービスのための生成 AI State Farm は、イノベーションの文化に基づいたアプローチでコンタクトセンターを近代化する取り組みに乗り出しました。それぞれの段階から学び最適化した結果、セルフサービスの解決率が 0.5% から 30% 以上に向上し、転送率が大幅に低下した一方で、一次解決率 (FCR) と顧客満足度スコアが向上しました。State Farm は、常にお客様が最善の事態に備え、最悪の事態から立ち直れるよう支援するという使命のもと、生成 AI と予測機能を模索しながら革新を続けています。 オムニチャネル体験とセルフサービスの提供 Air Canada は、旅客や貨物を含む事業分野全体で セルフサービス体験 をどのように革新しているかを紹介しました。 Coinbase は、Amazon Connect を使用してコンタクトセンター業務を迅速に変革し、それまで別々だった電話ベンダーとチャットベンダーを単一の統合 オムニチャネル ソリューションに統合したことを概説しました。 エージェントの生産性向上 Frontdoor はAmazon Connect に迅速に移行し、顧客待ち時間を半分に短縮し、さらにエージェントがよりパーソナライズされたサービスを提供するため生成 AI によって 生産性を向上させている 事について説明しました。 NatWest は、Amazon Q in Connect を使用することで顧客の意図の検出が改善され、エージェントがあらゆるやり取りにおいてよりパーソナライズされたカスタマーサービスを提供できるようになったことを強調しました。 分析、インサイト、最適化の活用 トヨタ は、Amazon Connect Contact Lens の 分析および最適化機能 を活用して、新たなテーマを検出し企業のリーダーが活用するインサイトを引き出す方法を紹介しました。 Fujitsu は、AI を活用した最適化機能を活用して、労働力と品質管理の効率化とコスト削減をどのように行っているかを明らかにしました。 Amazon から学ぶ Amazon Customer Service では、便利でパーソナライズされたカスタマーエクスペリエンスを提供するために、Amazon Connect を使用して年間数十億件もの顧客とのやり取りをサポートする方法について説明しました。また、生成 AI への投資によって世界中のカスタマーサービスがどのように強化されているかも紹介しました。 AWS パートナーとのイノベーション Pearson Clinical Assessments は、Amazon Connect と Salesforce Service Cloud Voice を使用して、音声、チャット、その他のデジタルチャネルにわたる対話を統合する統合ワークスペースをエージェントに提供している事を明らかにしました。 Amazon Connect の新しいイノベーション 効率化された設定と生成 AI でセルフサービス体験を強化 セルフサービスオプション は現代のカスタマーサービス戦略の重要な要素であり、顧客が自分で解決策を見つけられるようにすると同時に、サポートコストを削減し、全体的な満足度を高めます。Amazon Connect は、コンタクトセンターにおける セルフサービス体験 の簡素化と強化を目的とした一連の新機能を発表しました。生成 AI、合理化されたセルフサービス設定、改善された分析を活用して、より効率的で効果的な顧客インタラクションを実現します。 Amazon Connect が Amazon Q in Connect で生成 AI を活用したセルフサービスを開始 Amazon Connect がシンプルな会話型 AI ボットの作成を提供 Amazon Connect Contact Lens が会話型 AI ボットのパフォーマンスを分析するための組み込みダッシュボードをリリース Amazon Connect で IVR およびその他の自動対話中の音声が録音可能に プロアクティブなアプローチをパーソナライズし、チャネルサポートを拡大 現代の顧客は、好みのチャネルでのシームレスなやり取りを期待しています。先進的な企業は顧客のニーズを予測し、パーソナライズされたアプローチを通じて関係性を築く方法を模索しています。同時に、これらのソリューションは複数のコミュニケーションチャネルを統一されたワークスペースに統合し、エージェントがさまざまなアプリケーション間を行き来する必要性をなくし、合理的かつ効率的なワークフローを提供することでエージェントエクスペリエンスを変革しています。 Amazon Connect が顧客セグメントとトリガーベースのキャンペーン向けの AI アシスタントをリリース Amazon Connect が WhatsApp Business メッセージングのサポートを開始 Amazon Connect では、チャット内で重要な顧客データを簡単に収集できるようになりました AWS が Amazon Connect での Salesforce Contact Center を発表 (プレビュー) AI を活用した分析と予測でコンタクトセンターのパフォーマンスを最適化 コンタクトセンターは 分析 を活用して、カスタマーエクスペリエンスとオペレーション効率に革命をもたらしています。今や、顧客の行動を理解し、エージェントのパフォーマンスを最適化し、業務をリアルタイムで合理化するには、高度な分析が不可欠です。AI を使用することで、企業は顧客とのやり取りから深いインサイトを引き出し、将来の傾向を予測し、進化する顧客ニーズに合わせてプロアクティブに対策することができます。Amazon Connect は、現代のコンタクトセンターにおける分析の重要な役割を認識し、カスタマーサービス組織がデータからより多くのインサイトを引き出し、予測の精度を向上させ、カスタマーサービス業務のあらゆる面で継続的な改善を推進しやすくなる機能を導入しました。 Amazon Connect Contact Lens がエージェントのパフォーマンス評価を生成 AI を使用して自動化 Amazon Connect Contact Lens が生成 AI を使用してコンタクトを自動的に分類 Amazon Connect が新しい日中予測ダッシュボードを発表 将来を見据えた取り組み 企業はクラウド、AI、分析を活用してカスタマーサービスを向上させる絶好の機会を迎えています。私たちは、これらの最新機能によって、企業がカスタマーサービス体験とコンタクトセンター運営をどのように再構築し、改革していくかを目の当たりにできることを嬉しく思います。Amazon Connect の詳細については、 ウェブページ をご覧ください。 Amazon Connect でカスタマーサービス体験を変革する準備はできましたか？ お問い合わせください。 翻訳はシニア Amazon Connect ソリューションアーキテクト清水が担当しました。原文は こちら です。