はじめに：なぜお客様は 高度な文書処理（IDP）を導入するのでしょうか？ 企業は日々、大量の構造化・非構造化データを扱っています。請求書処理、契約書管理、財務報告などは、企業が大量の文書を効率的に処理する必要があるほんの一例にすぎません。このような文書を手作業で処理するのは、単調でミスが起こりやすいものです。そのため、企業は文書処理のワークフローを自動化する方法を模索しています。より良い文書処理は、より正確な収集、キャプチャ・コストの削減、電子的な情報の保持と呼び出しにつながります。 当社のお客様の多くは、ビジネスクリティカルな SAP ワークロードを AWS 上で実行しており、SAP アプリケーションのカスタマイズを減らしながら、 IDP ワークフローを構築する方法を常に模索しています。SAP アプリケーションを AI/ML を搭載した AWS サービスと統合し、ビジネス・ワークフローを近代化・刷新してコストを大幅に削減し、俊敏性を高め、生産性を向上させる、よりシンプルな方法を模索しています。AWS サービスはオープンなアプリケーション・プログラミング・インターフェース（API）による統合をサポートしていますが、お客様はこれらの API を利用するために複雑な ABAP プログラムを開発することを望んでいません。顧客は、SAP モジュール内でこれらの API を利用するために、よりシンプルな抽象化とアクセスパターンを求めています。 お客様からのフィードバックに基づき、私たちは最近、 AWS SDK for SAP ABAP の一般提供を発表しました。これにより、顧客はわずか数行のコードで SAP アプリケーションを 200 を超える AWS サービスに接続できるようになります。これにより、顧客は複雑なカスタマイズやポイント・ツー・ポイントの統合、関連するメンテナンス・コストの必要性がなくなります。 このブログでは、AWS SDK for SAP ABAP を使用して、 Amazon Textract 、 Amazon Translate 、 Amazon Comprehend 、 Amazon SNS などの AI/ML を搭載した AWS サービスと SAP を組み合わせ、ベンダーから受け取った請求書を自動的に処理して SAP に転記する方法を説明します。このソリューションは、PDF、文書、画像などのフォーマットをサポートしています。 高度な文書処理（IDP）ワークフローの作成 AWS SDK for SAP ABAP を使用するのは簡単です。AWS SDK for SAP ABAP をインストールするには、 SDK をここからダウンロードし 、SAP 移送管理システムを使用して SAP アプリケーションスタックにインストールします。その他の詳細については、 Getting Started with the AWS SDK for SAP ABAP Blog をご参照ください。 AWS SDK for SAP ABAP は、認証、データフォーマット、パフォーマンス、暗号化などの複雑な機能を抽象化し、ABAP 開発者に使いやすい機能を提供します。 SDK の API リファレンスガイド では、AWS SDK for SAP ABAP を使用して各サービスにアクセスする方法を説明しています。 前提条件 実装の詳細に入る前に、まずこのソリューションの前提条件を見てみましょう： S3 バケット、SNS トピックを作成・管理し、Amazon Textract、Amazon Translate、Amazon Comprehend サービスにアクセスするための適切な IAM 権限を持つ AWS アカウント SAP NetWeaver バージョン 7.40 以上の SAP ERP / S/4HANA システム AWS SDK for SAP ABAP が SAP ERP または S/4HANA システムにインストールされている。AWS SDK for SAP ABAP を使用した SAP システムのインストールと設定方法については、 こちらのガイド を参照してください。 SAP ABAP プログラミングの知識 請求書処理ワークフロー概要 多くの企業はサプライヤーから大量の請求書を受け取りますが、手作業で処理するには時間がかかり、エラーが発生しやすいプロセスです。AWS SDK for SAP ABAP と Amazon Textract を使用することで、企業は請求書処理ワークフローを SAP S/4HANA や SAP ECC などの既存の SAP ERP ソリューションとシームレスに統合することができます。これにより、企業は買掛/売掛プロセスを合理化し、財務業務の全体的な効率を向上させることができます。 請求書文書処理ワークフローを実装するには、以下のアーキテクチャを活用します。 サプライヤーから PDF 形式で受け取った請求書類は、まず AWS SDK for SAP ABAP を活用して AWS サービスとネイティブにやり取りするカスタム ABAP アプリケーションを使用して、 Amazon S3 バケットにアップロードされます。その後、カスタム ABAP アプリケーションがドキュメントの処理をトリガーします。 カスタム ABAP アプリケーションは、AWS SDK for SAP ABAP を使用して Amazon Textract API を呼び出し、ドキュメントからデータを抽出します。 その後、抽出されたデータは Amazon Translate に送られ、ドキュメントの説明をターゲット言語に翻訳します。言語検出には、 Amazon Translate がターゲット言語に翻訳する前に、ソース言語を検出するために Amazon Comprehend が使用されています。 抽出された情報を使用して、カスタム ABAP アプリケーションは SAP ERP の標準関数を使用して請求書の検証を実行し、SAP に請求書ドキュメントをポストします。 プロセス中にエラーが見つかった場合、アプリケーションは Amazon SNS API を呼び出して自動通知メールをトリガーします。 また、オプションで AWS Step functions を使用して承認ワークフローを開始し、レビュープロセスや分散アプリケーションを含むオーケストレーションをトリガーできます。 以下は、IDP のための AWS SDK for SAP ABAP と Amazon Textract の使い方を説明するコードスニペットです。ソリューション全体のサンプルコードを取得するには、 こちらの git repo を参照してください。 まず、AWS SDK For SAP ABAP を使用して S3 にファイルをアップロードする方法を見てみましょう。 *Create session object Data(lo_session) = /aws1/cl_rt_session_aws=>create( Iv_profile_id = co_profile ). *Create S3 client Data(lo_s3) = /aws1/cl_s3_factory=>create( lo_session ). *Perform action – upload to bucket TRY. lo_s3->putobject( iv_bucket = p_bucket iv_key = p_key iv_body = lv_xstring ). CATCH /aws1/cx_s3_nosuchbucket. * Handle exceptions ENDTRY 次に、AWS SDK for SAP ABAP を使用して Amazon Textract API を呼び出す方法を見てみましょう。IDP ワークフローで Amazon Textract を使用する方法を説明する前に、サービスがどのように文書を処理するかを理解することが重要です。Textract は、高度な ML アルゴリズムを使用して、文書内のテキストブロック、テーブル、フォームを検出し、分析します。 *Create Textract client Data(lo_textract) = /aws1/cl_tex_factory=>create(lo_session ). *S3 object DATA(lo_s3object) = NEW /aws1/cl_texs3object( iv_bucket = p_bucket iv_name = p_key ). *Document location DATA(lo_documentlocation) = NEW /aws1/cl_texdocumentlocation( io_s3object = lo_s3object ). TRY. Data(lv_jobid) = lo_textract->startdocumentanalysis( EXPORTING io_documentlocation = lo_documentlocation it_featuretypes = lt_featuretypes ). CATCH /aws1/cx_rt_technical_generic. * Handle exceptions ENDTRY. Textract は文書をブロック単位で処理し、各ブロックはテキストを含む文書のセクションを表します。例えば、ブロックはテキストの段落、見出し、テーブルのセルを表します。各ブロックはテキスト、位置、サイズ、その他の属性について分析される。Textract はまた、各ブロックの信頼スコアを提供し、ブロックが有効なテキストを含む可能性を示します。 *Process Document blocks Data(lt_blocks) = lo_textract->getdocumentanalysis( iv_jobid = pv_jobid )->get_blocks( ). ドキュメントからデータを抽出したら、次のコードを使って Amazon Translate に翻訳を依頼します： *Create Translate client DATA(lo_xl8) = /aws1/cl_xl8_factory=>create( lo_session ). *Translate text CALL METHOD lo_xl8->translatetext EXPORTING iv_text = pv_desc iv_sourcelanguagecode = 'auto' " will use comprehend to do lang detection iv_targetlanguagecode = 'de' RECEIVING oo_output = DATA(lo_output). DATA(lv_trans_desc) = lo_output->get_translatedtext( ). 請求書投稿が成功したことを通知したり、途中で例外が発生したことを通知したりするために、SNS に公開することができます。 * Create SNS client DATA(lo_sns) = /aws1/cl_sns_factory=>create( lo_session ). * Publish messaage lo_sns->publish( iv_topicarn = lv_arn iv_message = lv_msg iv_subject = lv_sub ). 最後に、BAPI_ACC_DOCUMENT_POST などの標準的な SAP API を使用して、以下のように請求書ドキュメントから抽出した情報を処理し、SAP にベンダー請求書トランザクションをポストします。以下の例では、抽出された請求書番号が、会計文書のヘッダーセクションの参照文書番号にどのようにマッピングされるか、また請求書の他のすべての詳細が、翻訳されたテキストを含め、SAP のベンダー請求書トランザクションの関連フィールドにどのようにマッピングされるかがわかります。 AWS SDK for ABAP と Amazon Textract for IDP を使用する利点を見てみましょう： 統合： AWS ABAP SDKは、SAP システムと AWS サービスとのシームレスなネイティブ統合を提供し、既存の SAP ランドスケープに大きな変更を加えることなく、ビジネス変革に特化した AWS サービスを活用できます。 高速処理 ： Amazon Textract は、大量のドキュメントを迅速かつ正確に処理し、手作業と処理時間を削減します。大規模なドキュメントを非同期で処理できるため、スケーラビリティとパフォーマンスが向上します。 精度向上： Amazon Textract は、機械学習アルゴリズムを使用して文書からデータを抽出するため、精度が向上し、エラーが減少します。 効率性向上： 自動化された文書処理ワークフローはリソースを解放し、全体的なコストと運用効率を改善します。 セキュリティ： AWS クラウドは、機密データの保存と処理にセキュアな環境を提供し、データのプライバシーと業界規制へのコンプライアンスを保証します。 全体として、SAP のビジネス変革に AWS ABAP SDK を使用することで、コストを削減しながら効率性、正確性、セキュリティを向上させることができます。 概要 AWS SDK for SAP ABAP は、ABAP 開発者が SAP ABAP 言語を使用してネイティブに AWS サービスのパワーを活用することで、ビジネスプロセスを拡張し、変換することを容易にします。SDK は、SAPとAWS サービス間の複雑な統合を手作業で作成する必要性を排除することで、接続性、セキュリティ、相互運用性のためのデータフォーマット、ポイントツーポイント統合の必要性など、すべてのアーキテクチャ上の複雑性を簡素化します。この機能により、200 を超える AWS サービスと SAP を統合する道が開かれます。AWS SDK for SAP ABAP は、ABAP ビルダーコミュニティと AWS サービス間の長年のギャップを埋めるものです。 SDK を ABAP 環境にインストールする方法については、 Getting Started Blog をご覧ください。 翻訳は Partner SA 松本が担当しました。原文は こちら です。

9月7日、 Amazon EC2 R7iz インスタンス の一般提供を発表します。R7iz インスタンスは、3.9 GHz の持続オールコアターボ周波数を備えた、クラウド内で最も高速な第 4 世代インテル Xeon スケーラブルベース (Sapphire Rapids) インスタンスです。R7iz インスタンスは、追加データを処理するためのより多くのメモリ、スケールアップするためのより大きなサイズのインスタンス、完了時間を短縮するためのより高いコンピューティングおよびメモリのパフォーマンス、レイテンシーを改善するためのより高いネットワーキングおよび Amazon Elastic Block Store (Amazon EBS) のパフォーマンスが必要なワークロードに適しています。R7iz インスタンスの高いコンピューティングパフォーマンスを、大量のメモリと組み合わせることで、フロントエンドの Electronic Design Automation (EDA)、コアあたりのライセンス料金が高額なリレーショナルデータベースワークロード、財務、数理計算、データ分析シミュレーションのワークロードを含むアプリケーションの全体的なパフォーマンスが向上します。これは、ライセンスコストを削減しながら、製品開発の市場投入までの時間を短縮するのに役立ちます。 R7iz インスタンス R7iz インスタンスの仕様は次のとおりです。 vCPU メモリ (GiB) ネットワーク帯域幅 EBS 帯域幅 r7iz.large 2 16 最大 12.5 Gbps 最大 10 Gbps r7iz.xlarge 4 32 最大 12.5 Gbps 最大 10 Gbps r7iz.2xlarge 8 64 最大 12.5 Gbps 最大 10 Gbps r7iz.4xlarge 16 128 最大 12.5 Gbps 最大 10 Gbps r7iz.8xlarge 32 256 12.5 Gbps 10 Gbps r7iz.12xlarge 48 384 25 Gbps 19 Gbps r7iz.16xlarge 64 512 25 Gbps 20 Gbps r7iz.32xlarge 128 1024 50 Gbps 40 Gbps 各 R7iz インスタンスには最大 88 個の EBS ボリュームをアタッチできます。比較のためにお伝えすると、 z1d インスタンス でアタッチできる最大ボリューム数は 28 個です。 また、2 つのサイズのベアメタル R7iz インスタンスをリリースする準備も進めています。 vCPU メモリ (GiB) ネットワーク帯域幅 EBS 帯域幅 r7iz.metal-16xl 64 512 25 Gbps 20 Gbps r7iz.metal-32xl 128 1024 50 Gbps 40 Gbps 組み込みアクセラレーター R7iz インスタンスには、Advanced Matrix Extensions (AMX)、Intel Data Streaming Accelerator (DSA)、Intel In-Memory Analytics Accelerator (IAA)、および Intel QuickAssist Technology (QAT) という 4 つの組み込みアクセラレーターも含まれています。これらのアクセラレーターの中には、特定のカーネルバージョン、ドライバー、および/またはコンパイラの使用が必要なものもあります。Advanced Matrix Extensions はすべてのサイズの R7iz インスタンスで利用でき、Intel QAT、Intel IAA、Intel DSA アクセラレーターは r7iz.metal-16xl および r7iz.metal-32xl インスタンスで利用可能になる予定です (近日リリース予定)。 今すぐご利用いただけます 本日より、R7iz インスタンスは、米国東部 (バージニア北部) および米国西部 (オレゴン) の AWS リージョンで一般提供されます。Amazon EC2 でのいつものお支払いと同様に、使用した分の料金のみをお支払いいただきます。詳細については、「 Amazon EC2 の料金 」を参照してください。 詳細については、 Amazon EC2 R7iz インスタンスページ にアクセスしてください。また、 EC2 の AWS re:Post 、または通常の AWS サポートの担当者までフィードバックをぜひお寄せください。 – Veliswa 原文は こちら です。

AWS ヒーロー プログラムでは、さまざまなアプローチを通して AWS コミュニティを盛り上げてくれている技術愛好家たちを四半期ごとに表彰しています。こうしたインスピレーションあふれる人たちは知識を積極的に共有してくれる一方で、LED を活用してクリスマスシーズン向けの不思議なディスプレイを作るなど、時にはテクノロジーを使用する斬新で楽しい方法を見つけています。また、ユーザーグループ、ブートキャンプ、ワークショップの主導や、カンファレンスの講演でのソリューションの共有を行って地域社会に大きく貢献していることも少なくありません。 前置きはこれくらいにして、今回のヒーローたちを紹介したいと思います。ヒーローたちの詳細をご確認ください。 Alex Lau 氏– 香港 コミュニティヒーローである Alex Lau 氏は、Tecky Academy の Lead Instructor として、フルスタック、モバイルアプリ、そして AWS テクノロジーにフォーカスしています。教育と共有に熱心な Lau 氏は、2015 年から香港の開発者コミュニティのリーダーとして活躍しています。ハッカソンを毎年開催し、コーディングブートキャンプを設立して、コミュニティのメンバーを 1,000 人以上に増やしました。今年の初めには、AWS Summit 香港のステージで最先端の AWS テクノロジーを紹介し、香港 AWS の GenAI Solution Day のセッションも主導しました。 Brian H. Hough 氏 – ボストン (米国) DevTools ヒーローである Brian H. Hough 氏は、エンタープライズとスタートアップにサービスを提供するソフトウェアエンジニアリング企業および 1 万人以上のフォロアーを擁するメディアブランドである Tech Stack Playbook® の創設者です。Hough 氏の講演、プレゼンテーション、および作業は、AWS、freeCodeCamp、MongoDB、NASA によって取り上げられています。ビルダーの声を拾い上げ、理想となる未来の世界を構築するすべての人を支援することを楽む Hough 氏は、AWS の All Builders Welcome Grant プログラムやその他のテクノロジーコミュニティのメンターも務めています。さらに、AWS re:Invent、AWS Summit ニューヨーク、Geekle の Worldwide Software Architecture Summit、DataSaturday を始めとする多くのカンファレンスでフルスタック開発、マイクロサービス、MLOps、Infrastructure as Code について講演しています。 Dheeraj Choudhary 氏 – マハーラーシュトラ (インド) コミュニティヒーローの Dheeraj Choudhary 氏は、10 年以上の IT の経験を持ち、AWS クラウドと DevOps の分野にフォーカスしたリードエンジニアです。DevOps エンジニアリング、ビルドエンジニアリング、リリースエンジニアリング、およびソフトウェア構成管理を専門としています。Choudhary 氏は、プネーの AWS ユーザーグループのリーダーとして、対面式の交流会や AWS Community Day の共催に情熱を注いでいます。さらに、Choudhary 氏は各国の AWS コミュニティイベントで積極的に講演し、プネーのカレッジや大学で AWS クラウドコンピューティングに関するゲスト講義やワークショップを開催しています。 Evandro Pires – ブルメナウ (ブラジル) サーバーレスヒーローである Evandro Pires 氏は、12 歳のときにプログラミングを始めたという CTO です。テクノロジーと起業家精神のバックグラウンドを持つ Pires 氏は、インターネットとモバイルバンキング、SaaS ソリューション向けの AI とローコードの重要なプロジェクトを多く率いてきました。2020 年以来、Pires 氏は「Sem Servidor」と呼ばれるサーバーレスに特化したポッドキャストを設立し、そのホストを務めています。 また、ラテンアメリカ初の ServerlessDays の開催にも携わりました。 三浦一樹 氏 – 北海道 (日本) コミュニティヒーローである 三浦一樹 氏は、北海道テレビ放送(HTB) のシニアエンジニアです。三浦氏は、同社のビデオオンデマンドサービスと電子商取引サービスの開発と運営に携わっています。ウェブサービスの開発を通して得た知識を日本の AWS ユーザーグループ (JAWS-UG) と広く共有しています。 Linda Mohamed 氏 – ウィーン (オーストリア) コミュニティヒーローである Linda Mohamed 氏は、10 年以上にわたってテクノロジー業界で活躍してきました。Mohamed 氏は現在、EBCONT に所属し、主にクラウドテクノロジー、IT プロセスの最適化、アジャイル方法論に焦点を当ててた専門家として活動しています。同氏は AWS コミュニティ の DACH Support Association 会長という肩書きも持っていて、資金調達諮問委員会のメンバーとしても積極的に活動しています。企業のクラウドへの移行を指導していないときは、AI/ML サービスとテクノロジーの分野における AWS のコミュニティイベントやその他のテクノロジープラットフォームでインサイトを共有しています。 Monica Colangelo 氏 – ミラノ (イタリア) DevTools ヒーローである Monica Colangelo 氏は、IT 業界で 15 年以上のキャリアを持つプリンシパルクラウドアーキテクトです。その経験は、運用、インフラストラクチャ、そして特に DevOps をカバーしています。自動化とオペレーショナルエクセレンスは常に Colangelo 氏の仕事の中心であり、同氏のアプローチとソリューションの指針となっています。Colangelo 氏はテクノロジーカンファレンスでも定期的に講演を行い、専門知識やインサイトを共有しています。さらに、多様性を提唱する Colangelo 氏は、テクノロジーセクターにおける女性の割合を高める必要性を強調しています。 Nick Triantafillou 氏– ウロンゴン (オーストラリア) コミュニティヒーローである Nick Triantafillou 氏は、クラウドエンジニア、教育者、ユーザーグループの創設者、そしてクリスマスライト愛好者という多彩な顔を持っています。クラウド教育スタートアップ A Cloud Guru の最初のコースインストラクターの 1 人である Triantafillou 氏は、100 万人以上の受講者に AWS の基礎を教え、世界初の AWS Certified DevOps Engineer コースを設立しました。また、地元のウーロンゴン AWS ユーザーグループの創設者、そして Sydney Serverless Meetup の共同創設者でもあり、ServerlessConf と ServerlessDays ANZ カンファレンスの両方の計画と運営に携わってきました。現在は、TikTok と YouTube ですべての AWS サービスに関する動画の作成を試みる「NickExplainsAWS」を運営しています。毎年 12 月には自宅に 75,000 個以上の LED を設置して、サーバーレスと AWS を活用したスペクタクルなライトショーを開催し、道行く人たちの目を引き付けています。 詳細はこちら 新しいヒーローたちについて詳しく知りたい、またはお近くのヒーローとつながりたいという場合は、 AWS ヒーローのウェブサイト にアクセスするか、「 AWS Heroes Content Library 」(AWS ヒーローコンテンツライブラリ) をご覧ください。 – Taylor 原文は こちら です。

AWS Weekly Roundup を書く順番がもう一度回ってきたようです。 最初に書いた のは 2012 年の 4 月 16 日ですから、ほんの 4,165 日前です。 9月4日週のリリース 9月4日週のリリースのうち、私が注目したいくつかのリリースを以下に記載します。 R7iz インスタンス – 高い CPU パフォーマンス向けに最適化され、メモリを大量に消費するワークロード向けに設計されたこれらのインスタンスは、クラウドで最も高速な第 4 世代 Intel Xeon スケーラブル (Sapphire Rapids) ベースのインスタンスを搭載しています。8 種類のサイズがあり、vCPU 数は 2～128、メモリは 16～1024 GiB でネットワークと EBS 帯域幅も十分に割り当てられています。 vCPU メモリ (GiB) ネットワーク帯域幅 EBS 帯域幅 r7iz.large 2 16 最大 12.5 Gbps 最大 10 Gbps r7iz.xlarge 4 32 最大 12.5 Gbps 最大 10 Gbps r7iz.2xlarge 8 64 最大 12.5 Gbps 最大 10 Gbps r7iz.4xlarge 16 128 最大 12.5 Gbps 最大 10 Gbps r7iz.8xlarge 32 256 12.5 Gbps 10 Gbps r7iz.12xlarge 48 384 25 Gbps 19 Gbps r7iz.16xlarge 64 512 25 Gbps 20 Gbps r7iz.32xlarge 128 1024 50 Gbps 40 Gbps Veliswa が 記事 で紹介しているように、 R7iz インスタンスには 4 つの組み込みアクセラレーターも含まれていて、2 つの AWS リージョンで使用可能です。 ビューリソース用の Amazon Connect API – View API の新しいセットを使用すると、エージェントの UI に表示されるステップごとのガイドで使用されるビューリソース (UI テンプレート) の作成と管理をプログラムによって行うことができます。 Marketplace 出品者への日次支払い – 出品者は、支払いの優先設定を設定することや、未払い残高を毎日受け取るように設定することが可能になり、支払いを既存の会計処理と一致させるなど、柔軟性が向上しました。 AWS Step Functions のエラー処理の強化 – Step Functions Fail 状態 の詳細なエラーメッセージを構築できるようになりました。また、再試行間隔の最大制限を設定することもできます。 Amazon CloudWatch Logs 正規表現フィルタリング – Amazon CloudWatch Logs フィルターパターンで正規表現を使用できるようになりました。例えば、以前のように複数のフィルターを使用しなくても、複数の IP サブネットまたは HTTP ステータスコードに一致する単一のフィルターを定義できます。各フィルターパターンでは、最大 2 つの正規表現パターンを使用できます。 Amazon SageMaker – 新しい (そしてすばやい) Studio セットアップエクスペリエンス 、 PyTorch 向けのマルチモデルエンドポイント 、そしてノートブックを使用する際に SageMaker の地理空間機能を GPU ベースのインスタンス で使用する機能が利用できるようになりました。 X in Y – 既存のサービスとインスタンスタイプが新しいリージョンで利用できるようになりました。 欧州 (スペイン) リージョンの ROSA 。 ロサンゼルスのローカルゾーン us-west-2-lax-1a の AWS NAT Gateway 。 米国東部 (オハイオ)、アジアパシフィック (シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、ロンドン) リージョンの Amazon Simple Email Service (SES) の E メール受信サービス 。 AWS GovCloud (米国) リージョンでの 最後に使用およびアクセスされた IAM ロール 。 AWS GovCloud (米国) リージョンの AWS Security Hub 検出結果の統合 。 欧州 (ロンドン) リージョンの C6id インスタンス 。 AWS GovCloud (米国西部) リージョンの Amazon Location Service 。 イスラエル (テルアビブ) リージョンの Amazon Managed Streaming for Apache Kafka と Amazon FSx for NetApp ONTAP 。 欧州 (チューリッヒ) リージョンの M6i および R6i インスタンス 。 AWS GovCloud (米国西部) リージョンの C6gd および R6gd インスタンス 。 アジアパシフィック (ハイデラバード、メルボルン)、欧州 (スペイン、チューリッヒ)、中東 (UAE) リージョンの VPC DNS クエリのログ記録 。 アジアパシフィック (ソウル) リージョンの High Memory インスタンス 。 AWS のその他のニュース AWS のその他の更新情報とニュースをご紹介します。 AWS Fundamentals – 「 AWS for the Real World, Not for Certifications 」の第 2 版が発売されました。16 の重要な AWS サービスを網羅した 400 ページのボリュームに加え、各章には詳細で魅力的なインフォグラフィックが含まれています。サンプルを以下に示します。 AWS ブログからのその他の投稿 – 私がフォローしている他の AWS ブログやクラウドブログからの投稿です。 AWS DevOps ブログ –「 Using AWS CloudFormation and AWS Cloud Development Kit to provision multicloud resources 」 AWS Big Data ブログ –「 Managing Amazon EBS volume throughput limits in Amazon OpenSearch Service domains 」 AWS Contact Center ブログ –「 How contact center leaders can prepare for generative AI 」 AWS Desktop & Application Streaming ブログ –「 Selecting the right AWS End User Computing service for your needs 」 AWS Containers ブログ –「 Migrate existing Amazon ECS services from an internal Application Load Balancer to Amazon ECS Service Connect 」 AWS コミュニティビルダー – SST を使用した canary デプロイ で Lambda ゲームをレベルアップ しましょう。 Cloudonaut – AWS 上の自己ホステッド GitHub ランナー 。 Trek10 – Amazon EventBridge パイプを使用する方法と使用するとき 。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS End User Computing Innovation Day、9 月 13 日 – この 1 日の仮想イベントは、今日の困難な時期に、従業員が業務を遂行するために必要なツールを提供する IT チームを支援することを目的に設計されています。 詳細はこちら 。 AWS グローバルサミット、9 月 26 日 – AWS Summit – 最後の対面式 AWS Summit が 9 月 26 日にヨハネスブルグで開催されます。ベルリン、ボゴタ、パリ、ソウル、シドニー、テルアビブ、ワシントン DC などの最新の Summit イベントのオンデマンド動画を AWS YouTube チャンネルで視聴することもできます。 CDK Day、9 月 29 日 – CDK と関連プロジェクトに関するコミュニティ主導の完全バーチャルのイベントです (英語とスペイン語)。詳細については、ウェブサイトを参照してください。 AWS re:Invent、11 月 27 日～12 月 1 日 – re:Invent の計画はお済みですか。 今すぐ セッションカタログ を確認してください。ぜひご参加ください。AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。 複数の日程で開催される AWS Community Day – AWS ユーザーグループが主催し、お住まいの地域のコミュニティが主導するカンファレンスにご参加ください。 ミュンヘン (9 月 14 日)、 アルゼンチン (9 月 16 日)、 スペイン (9 月 23 日)、 ペルー (9 月 30 日)、 チリ (9 月 30 日) で開催されます。ランディングページにアクセスして、今後開催されるすべての AWS Community Day をチェックしてください。 今後予定されている AWS 主導の対面イベント、仮想イベント や AWS DevDay などの デベロッパー向けイベント をすべて閲覧できます。 – Jeff ; この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

マルチアカウント環境で効果的なガバナンスを実現し AWS のベストプラクティスや一般的なコンプライアンスフレームワークと連携させる作業は、複雑になることがあります。多くのお客様、特に規制の厳しい業界で事業を営むお客様は、リスクを特定し、サービス間の関係や依存関係に対処するための独自の統制を開発するために、時間とリソースを投資する必要があるという課題に直面しています。このプロセスによって、新しいサービスを実装する際のタイム・トゥ・バリュー (TTV) が長くなることがあります。 AWS Control Tower は、コンプライアンスドメイン全体にわたる 包括的なコントロール をお客様に提供し、強固なコンプライアンスフレームワークの確立を促進します。AWS のベストプラクティスと業界標準に準拠しているため、コンプライアンスを確保しながら新しいサービスを迅速に確立できます。これらの統制を活用することで、組織はガバナンスプロセスを合理化し、AWS 環境で新しいサービスを採用する際の TTV を短縮できます。 このブログでは、社内標準や規制要件を遵守するのに役立つ、AWS Control Tower のコントロールを使用する際のベストプラクティスについて説明します。 ベストプラクティス 適切なコントロールを適用するために、ワークロードと OU を把握して評価する アカウント内で運用されているワークロードと、確立されたビジネス目標を達成するための対応する要件、およびアカウントを組織単位（OU）に整理する根底にある理論的根拠を詳細に理解することが不可欠です。この理解は、必要な統制の範囲を決めるための指針となり、ワークロードとそのセキュリティ要件に沿った一貫した構造を確保します。 コンプライアンスフレームワークとの連携を検討する AWS Control Tower を利用することで、AWS のサービス、統制目標、コンプライアンスフレームワーク ( NIST 800-53 、 CIS AWS Benchmark 、 PCI-DSS など) ごとに統制をグループ化し、規制対象の業界のお客様は特定のコンプライアンス目標を達成するコントロールを簡単に有効化できるようになります。 IT コンプライアンスフレームワークとの連携は、規制対象外の業界の組織にも大きなメリットをもたらします。明確なコンプライアンス義務はないかもしれませんが、そのようなフレームワークを採用することで、リスク管理の一貫性と再現性のある基盤を確立することができます。さらにこれらのフレームワークは、お客様の AWS 環境に合わせたセキュリティ設定のベストプラクティスを提供することで、すべてのお客様にメリットをもたらします。 AWS Control Tower のコントロールを有効にする前に、その動作とメカニズムを理解する AWS Control Tower は、コントロールが どのように実装されているか を完全に可視化するアーティファクトなどの、各コントロールに関する包括的な情報を提供します。 予防コントロール は、セキュリティポリシーの違反につながる可能性のあるアクションを 許可しません 。これは サービスコントロールポリシー (SCP) によって実装されています。 検出コントロール は、ポリシー違反などのアカウント内の非準拠のリソースを検出し、ダッシュボードを通じてアラートを表示します。検出コントロールのステータスは「クリア」、「違反」、「無効」のいずれかで、AWS Control Tower で管理対象とするリージョンに適用されます。これらは AWS Config Rules によって実装されています。 プロアクティブコントロール は、 プロビジョニングの前に AWS CloudFormation を介してデプロイされたリソースをスキャンして、そのコントロールに準拠していることを確認します。準拠していないリソースはプロビジョニングされません。プロアクティブコントロールは、 AWS CloudFormation Hooks と AWS CloudFormation Guard ルールを使用して実装されています。各プロアクティブコントロールでは、ポジティブテストケースとネガティブテストケースのリファレンスとして使用できるサンプルCloudFormationテンプレートアーティファクトが提供されています。プロアクティブコントロールのステータスは「PASS」「FAIL」または「SKIP」です。 予防コントロールを検討する前に、検出コントロールを適用する 検出コントロールを適用することで、アーキテクチャの弱点やあるべき姿とのギャップを特定して、セキュリティ態勢を評価・継続的に改善することができます。検出されるアラートの傾向の分析に基づいてターゲットを絞ったプロアクティブコントロールを適用すると、将来のコンプライアンス問題を防ぐこともできます。たとえば、S3 ブロックパブリックアクセス設定が有効になっているかどうかをチェックする検出コントロール「 [S3.1] S3 ブロックパブリックアクセス設定を有効にする必要があります 」を有効にしてから、AWS CloudFormation 経由で非準拠の S3 バケットが作成されないようにするプロアクティブコントロール「 [CT.S3.PR.1] Amazon S3 バケットには、パブリックアクセスをブロックする設定が必要です 」を有効にします。 non-production OU でコントロールをテストする サンドボックス環境と開発環境では、通常、本番環境よりも頻繁に変更や更新が行われます。このような環境で最初にコントロールを適用することで、潜在的なリスクや構成ミスを早期に特定して軽減し、これらの問題が本番環境に伝播する可能性を減らすことができます。 有効化されているコントロールを継続的に監視・テストする積極的なアプローチを採用する AWS CloudTrail のイベントログを監視して、統制違反を示す可能性のある異常を特定します。 AWS Audit Manager を使用して自動評価を実施し、一般的なセキュリティおよびコンプライアンスフレームワークと照らし合わせてリソース構成を評価します。これにより、監査管理プロセス全体を簡素化し、統制上のギャップに対処することに集中できます。 AWS Identity and Access Management (IAM) Access Analyzer を使用してアクセスパターンを確認し、IAM 固有の統制に加えてどの予防コントロールを導入すべきかについて、情報に基づいた決定を下すことができます。「設定したら後は何もする必要がない」ではなく、継続的に確認することで、統制目標を効果的に実現できるという自信を得ることができます。 Policy as Code 戦略を採用し、組織全体でピアレビューを実施する AWS CloudFormation Hook と AWS CloudFormation Guard ルールを組み合わせた AWS Control Tower のプロアクティブコントロールを使用してください。Policy as Code は、ポリシー適用へのさらに効率的なアプローチを提供し、一貫性と自動化を促進します。また、中央の IT チームと開発チーム間のコラボレーションを促進することで障害を取り除き、開発者やエンジニアに透明性をもたらします。 3 種類すべてのコントロールを組み合わせて有効化する多層防御アプローチをとる AWS Control Tower は、各コントロールの依存関係や関連性についての情報を提供します。関連するコントロールを評価し、環境に適用できるコントロールを有効化することで、多層的で回復力のあるコンプライアンス態勢を確立できます。セキュリティベースラインを保護するための予防コントロール、AWS CloudFormation を介して非準拠のリソースがデプロイされるリスクを軽減するプロアクティブコントロール、リソースの変化を継続的に監視して対応するための検出コントロールを組み合わせて使用します。 AWS Control Tower は AWS Security Hub と統合されており、AWS Control Tower から AWS Security Hub が用意した検出コントロールを有効化できます。有効化すると AWS Security Hub に サービスマネージド標準 (AWS Control Tower) のセキュリティ標準が作成され、コントロールの準拠状況を管理できます。AWS Security Hub の検出コントロールと AWS Control Tower の予防コントロールやプロアクティブコントロールを組み合わせ、それらをまとめて管理することが AWS Control Tower では可能です。 コンプライアンス違反リソースの検出と修復を自動化する セキュリティイベントの検出と修復を自動化することで、人的労力を削減し、エラーの可能性を最小限に抑えることができます。AWS Control Tower の検出コントロールと AWS Systems Manager Automation を組み合わせて活用してください。 AWS Systems Manager による自動化により、さまざまなメンテナンス、デプロイ、修復タスクが簡素化され、運用が合理化され、効率が向上します。 独自のコントロールを作成して機能を拡張する AWS Control Tower の管理するコントロールとは別に、追加のコントロールが必要な場合は、 AWS Organizations 内のサービスコントロールポリシー (SCP) やカスタム AWS Config ルールなどのリソースを活用して追加のポリシーを定義できます。これらのポリシーは、AWS CloudFormation テンプレートを使用して AWS Organizations の組織にデプロイできます。さらに、 AWS Config コンフォーマンスパック は、AWS 環境内のガバナンスと規制コンプライアンスを強化する汎用的なコンプライアンスフレームワークを提供します。コンフォーマンスパックは、コンプライアンスルールとそれに対応する修復アクションを 1 つのエンティティとしてまとめることで、ルールを大規模に展開する作業を効率化します。これにより、組織への独自コントロール導入プロセスが簡素化されます。 まとめ 管理者には、ガバナンスとアジリティのバランスを取るための包括的なアプローチを取り、AWS 環境を保護する際に適切なセキュリティ判断を下す責任があります。そのためには、セキュリティドメイン内で利用可能なツールやリソースを活用して、全体的なセキュリティ態勢を強化し、特定の要件や存在する可能性のある脆弱性に対処する必要があります。 言い換えると、多面的なアプローチを採用することで、管理者は包括的な保護を確保し、潜在的なリスクを効果的に軽減する必要があります。 AWS Control Tower のコントロールを適用するためのベストプラクティスに従うことで、ガバナンスプロセスを合理化し、AWS 環境で新しいサービスを導入する際の TTV を短縮できます。さらに、ビジネス目標とコンプライアンス目標を達成するために必要な統制の定義、マッピング、管理にかかる時間を短縮できます。 コントロールの有効化を開始するには、 AWS マネジメントコンソール の AWS Control Tower サービスのコントロールライブラリにアクセスしてください。また、 AWS Control Tower API を使用して、 AWS CloudFormation 、 AWS Command Line Interface (AWS CLI) 、 AWS SDK 、および AWS Cloud Development Kit (AWS CDK) を介してコントロールをプログラムで管理することもできます。各コントロールの固有のリソース識別子については、 コントロールメタデータテーブル を参照してください。 AWS Control Tower のコントロールを Infrastructure as Code (IaC) としてデプロイする場合のその他のガイダンスについては、 AWS Perspective Guidance カタログの「 AWS CDK と AWS CloudFormation を使用して AWS Control Tower コントロールをデプロイおよび管理する 」と「 Terraform を使用して AWS Control Tower コントロールをデプロイおよび管理する 」を参照してください。（訳註：日本のSAが公開しているセキュアなベースライン環境を展開するためのテンプレートである BLEA も理解において有用ですので是非ご参照ください） 本ブログの翻訳はソリューションアーキテクトの三厨が担当いたしました。原文は こちら 。 著者について Chezsal Kamaray Chezsal Kamaray は、アマゾンウェブサービスのハイテク分野のシニアソリューションアーキテクトです。この職務の範囲内で、エンタープライズ顧客と戦略的に連携し、AWS クラウドでのスケーラブルで安全で回復力のあるアーキテクチャの開発を促進しています。彼女は、オンプレミスとクラウドベースの両方のドメインにわたるさまざまなインフラストラクチャプロジェクトのテクニカルレビューのリーダーシップを含め、多面的なクロスファンクショナルシステムの複雑な設計とシームレスな統合において15年以上の経験を持っています。Chezsal は、ニュージャージー工科大学で電子通信工学の工学士号（BenG）と電気通信の理学修士号（MSc）を取得しています。余暇には、Chezsal は料理への好奇心にふけり、音楽を聴きながら新しいレシピを試しています。 Matthew Barbieri Matt Barbieri は、ニューヨークを拠点とする AWS のソリューションアーキテクトです。コンプライアンス、セキュリティ、オペレーションエクセレンスに重点を置いて、企業顧客が AWS でソリューションを構築できるよう支援しています。AWS の元顧客として 10 年近くの経験を持つ彼は、クラウドへの移行に着手する企業が直面する課題と機会を深く理解しています。

AWS Loft TokyoでDeveloper x NoSQL nightというイベントを2023年9月21日に実施します。 開催概要 Serverless Days Tokyo にて Keynote を務める DynamoDB Book の著者であり AWS Serverless Hero である Alex DeBrie様を今回はゲストに迎え、NoSQL とDeveloper /開発者の目線というテーマで、Amazon DynamoDB をメインにベストプラクティスや実際の試行錯誤についてスピーカーによるセッションを行います。 対象 ・RDBMSは知っているけど、NoSQLはまだあまり利用をしていない方 ・RedisはしっているけどDDBはまだ利用したことが無い方 ・DynamoDB/Keyspaces(Cassandra)などのKVS系NoSQLを既に使っている方 これから利用するか悩んでいる、今使っていて効果的に利用出来ているか不安だ、という方は是非お越しください。 参加登録はこちら イベントでは軽食・飲み物をご用意する予定です。もし足りなかったら「大人の常識の範囲内で」1F or 3Fのセブンイレブンで購入の上持ち込みOKなのでお越しください。 スピーカー紹介 まず、登壇者の一人であるAWS Solutions Architectの福井厚について紹介します。福井厚はシニアソリューションアーキテクト : Developer Specialist – DevAxとしてお客様のクラウドネイティブなモダンアプリケーション開発を支援しています。過去にはAWS Summit、AWS Innovate、AWS DevDay、AWS Developer Live Showなど多数登壇し多くのAWSサービスや技術情報を伝えてきました。 開発者としての経験から現在もDevloper として多くのカスタマーを支援し モダンアプリケーションにおける代表的な設計パターン   と言った資料の著者でもあります。 筆者が福井にスピーカーをお願いしたかったのは、開発者としての長年の経験というのと、RDBMSの開発経験も豊富なため良い意味でNoSQLについて慎重な見方をしてくれる所だと思っています。サービスの機能やベストプラクティスについて「実装に落とすなら結局どうするのか？」「他の手段を使った時と比べてどれだけの利点があるのか？」「開発者はそれで本当に嬉しいのか？」という事をいつも指摘してくれました。もちろんそこは明確にお答えしたりケースバイケースな部分もあるんですが、「現実的にどこまで何が嬉しいのか？」という壁打ち的なコメントをしてくれてとても勉強になりました。 今回、福井が改めて開発者としての視点でAmazon DynamoDBをどう扱うのか？というセッションをしてくれるのは筆者として非常に嬉しく思っています。 Alex DeBrie様について そして次のSpeakerである Alex DeBrie様 です。 彼はこのイベントのすぐ後にあるServerless Days Tokyo 2023にてKeynoteを務めるくらいDynamoDBだけではなくServerlessコミュニティにおいても重要な人物です。Serverless Days Tokyo 2023では本当に多くの素晴らしいセッションが予定されており、AWSメンバーもセッション登壇予定です。興味深いセッションが多いのでまだ登録出来そうであれば是非参加してみてください。 https://tokyo.serverlessdays.io/ 我々Solutions Architectの多くのメンバーも彼のDynamoDB Bookを買って読んだという経験が多く彼と同じイベントでDynamoDBについて話す機会を貰えるのは本当に光栄です。少し前のセッションでは2019年のre:InevntなどではData modelingをテーマとして というセッションで登壇されており、その後もre:Inventや他のイベント、AWS Database Blogへの寄稿（最近ではSingle table vs Multi Table designという非常に興味深いエントリを投稿されています） https://aws.amazon.com/jp/blogs/database/single-table-vs-multi-table-design-in-amazon-dynamodb/ そしてAmazon DynamoDB 10周年記念イベントでも登壇しdata modelingについてセッションをされています。 また最近ではDynamoDBのTransactionについてDynamoDB チームのシニアプリンシパルエンジニアであるAkshat Vig & Somu Perianayagamとのディスカッションも公開されました 今回Alex様には筆者からは「例えば自分はこういうスタイルで開発、モデリング、改善、テストをしていると言った開発者としての目線などが伺えるととても嬉しい」と言ったリクエストをさせて頂きました。今回は”Understanding & Using Amazon DynamoDB”というタイトルでの発表となり今から筆者自身が最も発表を楽しみにしています。 このブログ著者である成田は直近のDynamoDBの機能紹介であったりスループットコントロールやそのメカニズムなどについてお話出来ればと考えています。 Amazon DynamoDBに興味を持っている方、開発者として実際に使ってもっと実践的な情報を知りたいという方は是非イベントに参加ください 本ブログ著者 : 成田 俊は、Principal DynamoDB Solutions Architectです。Amazon DynamoDB を使用する多くの AWS のお客様にアーキテクチャのレビューや技術支援を行っています。

このブログは 2021 年 11 月 2 日に Ahmed ElHaw (シニアソリューションアーキテクト) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 クラウドファースト戦略を採用する多くのお客様は、俊敏性の向上とコストの最適化のために、自動拡張、ビルトインされた高可用性、使用量に応じた課金モデルを提供するサーバーレス技術やクラウドファイルストレージを優先的に採用しています。お客様がサーバーレスアーキテクチャを採用する際、永続的なストレージ層におけるデータアクセスの共有が必要になる場合があります。AWS Lambda には、お客様のコード用に 512MB の一時ファイルシステムが含まれていますが、これは耐久性のあるストレージを意図したものではなく、一時的なリソースとなります。この記事で紹介する Lambda 関数の SMB 統合により、関数の呼び出しにまたがるデータの共有、大きな参照データファイルの読み込み、関数の出力の永続的な共有ストアへの書き込みが可能になります。 この記事では、 AWS Lambda と Amazon FSx for Windows File Server を統合することに焦点を当てます。また、 Amazon FSx for NetApp ONTAP を含む SMB 互換のファイルシステムならどれでも、ご紹介するソリューションを使用することができます。このソリューションでは、Amazon FSx for Windows File Server、Amazon FSx for NetApp ONTAP、オンプレミスの Windows ファイルサーバーで動作する SMB 互換のデータストア、または Amazon EC2 の Windows ファイルサーバーでホストされているファイル共有にて、ファイルやフォルダーの一覧、保存、取得、削除などのファイルおよびディレクトリ操作を実行することができます。 ユースケース コンテンツ管理やウェブサーバー、ホームディレクトリ、ビジネスクリティカルなワークロードなどの分散型アプリケーションは、共有ファイルストレージの恩恵を受けることができます。以下に、一般的なサーバーレスのユースケースを紹介します。 Windows のホームディレクトリや部門内での共有 のような環境において、 Lambda 関数を使用してユーザーのホームディレクトリや部門共有にレポートファイルを書き込むことができます。 Amazon FSx for Windows File Server またはAmazon FSx for NetApp ONTAP は、ホームディレクトリ、部門共有、コンテンツ管理、高可用性 Microsoft SQL Server のデプロイなど、さまざまな用途で使用することができます。 Amazon FSx でコンテンツをホスティングし、ファイル変更イベントに応じた自動化されたサーバーレスアクションを実行します。 Amazon FSx for Windows File Server の ファイルアクセス監査 を使用して、ファイル変更イベントが発生するたびに Amazon CloudWatch にイベントログを生成することができます。また、このような CloudWatch Logs のエントリーが生成された時点で Lambda 関数をトリガーし、変更されたファイルに対して操作を実行することができます。 (例えば、変更されたファイルを最新の内容を反映する必要がある別のデータソースにコピーすることができます) 公開用 SFTP サーバーを通じて組織内でファイルを共有します。 Amazon S3 に保存されたデータと&nbsp; AWS Transfer for SFTP &nbsp;を活用し、外部ファイルを SMB ファイル共有にダウンロードすることが可能です。このサーバーレス統合を通して、Lambda 関数は自動的に S3 からファイルをダウンロードし、共有ファイルシステムに保存することができます。 Amazon Athena &nbsp;を使用して、Amazon S3 に保存されているデータにクエリを実行します。 クエリ結果はカンマ区切り形式 (.csv) で保存され、SMB 互換のファイル共有に結果をコピーしたい場合に有効です。Lambda 関数を使用した Athena クエリのスケジューリングは一般的なユースケースであり、クエリ結果を Windows ファイル共有にコピーするよう拡張した Lambda 関数で、プロセスを自動化することができます。 ソリューションの概要 AWS Lambda は ランタイム を利用することで複数の言語をサポートしています。Python、.NET、Java、Node.js など、一般的なプログラミング言語で SMB を実装したライブラリがいくつかあります。ここでは、異なるランタイムを使用した二つの Lambda 関数を紹介します。一つ目の関数は Python ランタイムを使用し、SMBv2 および SMBv3 プロトコルを実装するオープンソースの Python ライブラリである smbprotocol をインポートします。二つ目の関数 (.NET に慣れている方向け) は、 SMBLibrary &nbsp;(オープンソースの C# SMB 1.0/CIFS, SMB 2.0, SMB 2.1, SMB 3.0 サーバとクライアントの実装) をインポートしています。 これからご紹介する Lambda 関数のコードでは、既存の Amazon FSx for Windows File Server 共有に対して二つの操作 (ファイルの保存と共有の一覧表示) を実装しています。それぞれのライブラリのドキュメントを参照することで、ニーズに合わせて操作を拡張することができます。また、 AWS Secrets Manager を使ったセキュリティ面やクレデンシャル管理についても詳しく説明しています。 手順 Amazon FSx for Windows File Server、Amazon EC2 上の Windows File Server、またはオンプレミス環境で動作する SMB ファイル共有と Lambda 関数の統合を説明します。 図 1: Amazon FSx、EC2、またはオンプレミス環境で動作する SMB ファイル共有と統合する Lambda 関数 ダミーのペイロード (“test”) を持つテストイベントを作成し、Lambda 関数を呼び出します。 AWS Lambda は、他の AWS サービスと統合 して関数を呼び出すことができます。 . 注：Amazon S3 は、Lambda 関数をトリガーできるサービスの例として示されており、Lambda 関数は AWS SDK を使用して Amazon S3 から読み取りと書き込みが可能です。 Lambda 関数が Secrets Manager からファイルサーバーの保存されたクレデンシャル (ユーザー名、パスワード、ホスト、共有名など) を取得します。 Lambda 関数がテストファイルを作成し、ファイル共有に保存します。 AWS Serverless Application Model (SAM) を用いた手順紹介 ソースコードを表示 サンプルのアプリケーションをデプロイするには、以下の前提条件が必要です。 前提条件 リソースを作成するために必要な権限を保持している AWS クレデンシャル。この例では、管理者権限を持つクレデンシャルを使用しています。 利用可能な Amazon FSx ファイル共有、または有効な資格情報と VPC へのルートを持つ SMB 互換のファイル共有。Amazon FSx for Windows File Server をセットアップするには、 Amazon FSx の開始方法 を参照してください。Amazon FSx for NetApp ONTAP の場合は こちらのガイド をご参照ください。 Lambda .NET core ランタイムを使用するテンプレートをデプロイする場合は、 .NET SDK がインストールされていること。 この記事の執筆時点での AWS SAM CLI のバージョン 1.29.0 です。 GitHub のリポジトリ をクローンします。 デプロイ方法 クローンしたリポジトリのディレクトリに移動するか、 sam init &nbsp;を実行して Custom Template Location を選択し、リポジトリの URL を貼り付けます。 &lt;templateName&gt; を Python または .NET テンプレートに置き換え、AWS SAM アプリケーションをビルドします。 sam build -t &lt;templateName&gt; 3. AWS SAM アプリケーションをデプロイします。 sam deploy --guided 図 2:ガイド付き AWS SAM デプロイメントの入力値の例 AWS SAM は以下のステップを実行します。 Secrets Manager にダミー値を格納し、シークレットを作成します。 選択した VPC に Secrets Manager の VPC エンドポイントを作成します。これは、VPC に接続された Lambda 関数に必要です。 CIDR (Classless Inter-Domain Routing) ブロックの管理と参照を容易にするために、 プレフィックスリスト を作成します。 選択したテンプレートに応じて、AWS SAM はいずれかのアクションを実行します。 Python ランタイムで Lambda 関数をビルドしてデプロイし、依存関係を持つライブラリの Lambda レイヤーをビルドして Lambda 関数に関連付けします。 または .NET Core とその依存関係で Lambda 関数をビルドします。 テスト 統合をテストするために、Python の Lambda 関数の内容を説明していきます。 1. Secrets Manager で作成したシークレットのダミー値を、ファイル共有の IP アドレスまたは解決可能なホスト名、サーバー名、ユーザー名、パスワードに置き換えます。 注： 変更を加えるには、まずリソースポリシーを削除する必要があります。AWS マネジメントコンソールから、ルートユーザーとして Secrets Manager にアクセスし、リソースポリシーをメモ帳にコピーしてください。秘密鍵ペアの値を置き換えたら、再びリソースポリシーを復活させます。 注： Amazon FSx for Windows File Server の場合、シークレットのホスト値は、コンソールで見つかった「優先ファイルサーバー IP アドレス」で構成します。Amazon FSx for NetApp ONTAP の場合、シークレットのホスト値は、コンソールで見つかった「管理エンドポイント -IP アドレス」で構成します。 2. Lambda コンソールで関数を選択し、リポジトリにある json ファイル (testevent.json) からペイロードを指定してテストイベントを作成します。 図 3: Lambda 関数のテストイベント成功 3. ファイル共有にファイルが作成されることを確認します。 図 4:ファイル共有にテストファイルが作成されていることを確認 モニタリングとトラブルシューティング ファイル共有アクセスやファイルアクセスを確認するには、Amazon FSx for Windows File Server を使用している場合、 ファイルアクセス監査 を有効にし、CloudWatch でログを確認することができます。Windows ファイルサーバーが EC2 やオンプレミスで稼働している場合は、Windows イベントログを確認します。 セキュリティと接続性 AWS Well-Architected Framework の セキュリティの柱 に従って、すべてのレイヤーでセキュリティを確保します。すべてのレイヤー (ネットワークのエッジ、VPC、ロードバランシング、すべてのインスタンスとコンピューティングサービス、オペレーティングシステム、アプリケーション、コード) に複数のセキュリティコントロールを用い、多層的な防御アプローチを適用します。 注：このソリューションは、サーバーレスワークロードの SMB アクセスを実現する方法についての概念実証です。お客様は自社のソリューションの開発時に、自社のセキュリティ要件を念頭に置く必要があります。 このソリューションでは、いくつかのセキュリティ設定が必要です。 VPC とサブネット このデモソリューションでは、レジリエンシーのため Lambda 関数を VPC と二つのプライベートサブネットで構成しています。この設定により、Lambda 関数から AWS のプライベートリソースへの到達性の確保が可能になります。実際の環境では、ニーズに応じて Lambda 関数のサブネットから適切なルーティングを構成してください。 オンプレミスのファイルサーバーの場合、SMB トラフィックを Amazon VPC に通過させるルーティングルールを持つ Amazon VPN または AWS Direct Connect が必要です。 セキュリティグループ このデモソリューションの Lambda 関数のセキュリティグループには、二つのアウトバウンドルールを設定し、インバウンドルールは設定しません。 シークレットの取得のために、Secrets Manager VPC エンドポイントのセキュリティグループ (宛先) への HTTPS (ポート443) アクセスを許可するアウトバウンドルールを設定します。 SMB トラフィックのために、ファイルサーバーの CIDR ブロック (宛先) への SMB (ポート 445) アクセスを許可するアウトバウンドルールを設定します。 注: 作成したマネージド プレフィックスリスト をオンプレミスネットワークの CIDR ブロックに設定します。 図 5: Lambda 関数のセキュリティグループのアウトバウンドルール Secrets Manager の VPC エンドポイントのセキュリティグループには、インバウンドルールが一つ設定されています。 シークレット取得のため、Lambda 関数のセキュリティグループ (送信元) からのHTTPS (443番ポート) 通信を許可するインバウンドルールを設定します。 図 6: Secrets Manager VPC のエンドポイントセキュリティグループのルールで Lambda 関数のセキュリティグループからのインバウンド HTTPS を許可する 最後に、ファイル共有サーバーのセキュリティグループ (またはオンプレミスのファイアウォールアプライアンス) が、Lambda 関数のセキュリティグループからのインバウンドアクセス (ポート445) を許可していることを確認します。 クレデンシャルの管理 Lambda 関数は、SMB ファイル共有で認証する必要があります。クレデンシャルをハードコーディングしたり、ファイルや環境変数に保存したりすることを避けることが重要です。そのため、今回紹介するソリューションでは Lambda 関数を Secrets Manager と統合して、ファイルサーバーのクレデンシャルとパラメータを保存および取得できるようにしています。Secrets Manager は、次のスクリーンショットのように、キー・バリューのペアの形式でシークレットを保存しています。シークレットに設定する Value をカスタマイズし、Admin のクレデンシャルではなく、必要最低限の権限を持った専用のクレデンシャルを使用することをお勧めします。 図 7: Secrets Manager で認証情報とパラメータが設定されたシークレット Secrets Manager は、アプリケーションでシークレットを取得する方法を説明するコードの例を提供しています。それらを表示するには、 AWS マネジメントコンソール &gt;AWS Secrets Manager&gt;シークレット&gt;シークレットの名前 にアクセスします。 転送中と格納中のデータの暗号化 Amazon FSx for Windows File Server は、ファイルシステムの暗号化において、格納中のデータの暗号化と転送中のデータの暗号化の二つの形式をサポートしています。Amazon FSx ファイルシステムを作成する際に、格納中のデータの暗号化は自動的に有効になります。転送中のデータの暗号化は、SMB プロトコル 3.0 以降をサポートするコンピューティングインスタンスにマッピングされたファイル共有でサポートされています。Amazon FSx は、お客様がアプリケーションを修正しなくとも、ファイルシステムにアクセスする際に、SMB 暗号化を使用して転送中のデータを自動的に暗号化します。 次のスクリーンショットでは、Amazon EC2 で動作する Windows ファイルサーバーと Lambda 関数のトラフィックをスニッフィングしています。Amazon FSx for Windows File Server でも同様の動作が期待できます。ファイルサーバーと Lambda 関数の間で、SMB 3.1.1 ダイアレクトにネゴシエートされたプロトコルを見ることができます。 図 8: Lambda 関数が Amazon EC2 上の Windows 2019 ファイルサーバーに送信する「Negotiate Protocol Request」 プロトコルネゴシエーションが完了すると、以下のスクリーンショットのような Lambda 関数とファイルサーバー間の暗号化されたトラフィックを確認することができます。 図 9: Lambda 関数と Amazon EC2 上の Windows 2019 ファイルサーバー間のトランジットにおける暗号化を示すパケットトレース Amazon FSx ファイルシステム管理のベストプラクティスドキュメント に記述されているように、Amazon FSx for Windows File Server で SMB 3.x をサポートしていないクライアントに対し、転送中の暗号化を強制することによって、暗号化されていないアクセスを制限することができます。 注：この設定では、SMB 3.x をサポートしていないファイルシステムに接続されたクライアント (Lambda関数以外) はすべて接続に失敗します。 図 10: SMB 2 クライアントからの暗号化されていないアクセスを拒否する Amazon FSx for Windows File Server IAMポリシー Lambda 関数と Secrets Manager の VPC エンドポイントからシークレットにアクセスするために、それらのインラインポリシーを次のように設定します。 GetSecretValue アクションは、リソースフィールドで定義されたファイルサーバーのシークレットのみに制限されます。 Version: "2012-10-17" Statement: - Effect: Allow Principal: '*' Action: - 'secretsmanager:GetSecretValue' Resource: !Sub ${MySecret} リソースポリシー さらに、Secrets Manager&nbsp;に格納されているシークレットに対してリソースポリシーを設定しています。Secrets Manager に対して、定義されたソース VPC エンドポイントからのリクエストでない限り、すべてのリクエストを明示的に拒否するようにします。 注：今回の AWS SAM テンプレートでは、次のようなポリシーが作成されます。 Version: "2012-10-17" Statement: - Sid: EnableSecretsManagerpermissions Effect: "Allow" Principal: AWS: !Sub "${AWS::AccountId}" Action: "secretsmanager:*" Resource: "*" - Sid: RestrictGetSecretValueoperation Effect: "Deny" Principal: '*' Action: "secretsmanager:GetSecretValue" Resource: "*" Condition: StringNotEquals: 'aws:sourceVpce': !Sub '${SecretsManagerVPCEndpoint}' リソースの削除 環境を削除するには CloudFormation スタックを削除するか、ターミナルから sam delete を実行します。 まとめ この記事では、Python と .NET 用のオープンソースライブラリを使用して、Lambda 関数と Amazon FSx for Windows File Server または Amazon FSx for NetApp ONTAP または SMB 互換ファイル共有を統合する方法を紹介しました。このデモソリューションはサーバーレスで、AWS SAM を使って簡単にデプロイすることができます。また、ソリューションのすべてのレイヤーのセキュリティについても説明しています。この統合により、Lambda 関数は SMB 互換の永続データストアでファイル操作を実行できるようになります。 AWS Lambda を Amazon FSx ファイル共有と統合することで、関数呼び出し間でデータを共有できるようになり、Windows ホームディレクトリへのファイルの自動保存したり、ファイル変更イベント時にプログラムによるアクションを実行したり、関数呼び出しのための大規模かつ永続的なデータストアが必要なユースケースなど、Lambda を新たなユースケースで利用できます。 また、他の Lambda ランタイムや、Java や Node.js などのオープンソースの SMB ライブラリも、ご希望に応じてお試しください。すべてのソリューションの成果物は GitHub リポジトリ で公開されており、必要に応じて拡張することができます。 当記事をお読みいただきありがとうございました。 翻訳はネットアップ合同会社の岩井氏、監修はソリューションアーキテクトの松本が担当しました。 <!-- '"` --> Ahmed ElHaw Ahmed ElHaw は、テレコム、ウェブ開発とデザイン、空間コンピューティング、AWS サーバーレスコンピューティングのバックグラウンドを持つ AWS のシニアソリューションアーキテクトです。彼は顧客に技術的なガイダンスを提供し、AWS を最大限に活用するソリューションの構築とその支援を楽しんでいます。仕事以外では、子供たちと過ごしたり、コーディングしたり、ビデオゲームをしたりするのが好きです。

昨今、生成系 AI をビジネスに利用する動きが活発化しています。AWS はお客さまがこの新しいテクノロジーの価値をフルに活かせるように、生成系 AI の専門家からなるチームを設置するとともに、柔軟性と費用対効果に優れた生成系 AI サービスを企業に提供しています。あらゆる組織が AI を活用できるように支援するという目標を掲げているのです。 その一環としてアマゾン ウェブ サービス ジャパンは 2023 年 7 月 3 日に、日本独自の施策として国内に法人または拠点を持つ企業・団体の大規模言語モデルの開発を支援する「 AWS LLM 開発支援プログラム 」を開始しました。本プログラムでは、LLM 開発を行うための計算機リソース確保に関するガイダンスや AWS 上での LLM 事前学習に関わる技術的なメンタリング、LLM 事前学習用クレジット、ビジネス支援などのサポートを提供します。 そしてこのたび、本プログラムで支援する企業・団体が正式に決定しました。本格的な LLM 開発支援が始まり、今後は 2023 年 12 月以降の成果発表会へと進むことになります。2023 年 9 月 4 日には「AWS LLM 開発支援プログラム」の採択企業が集い、Kick off party が開催されました。今回はこのイベントのレポートをお届けします。 代表執行役員社長 長崎 忠雄によるご挨拶 イベントの冒頭では、アマゾン ウェブ サービス ジャパン 代表執行役員社長の長崎 忠雄が、「AWS LLM 開発支援プログラム」推進にあたってのご挨拶をしました。アマゾン ウェブ サービス ジャパンは「日本の LLM 開発者や LLM 技術の発展に貢献したい」という思いから、このプログラムを開始。告知後は 60 社弱の企業から応募があったことに長崎は触れ、「ご応募いただいたみなさまに、この場を借りてお礼を申し上げます」と感謝の言葉を述べました。 アマゾン ウェブ サービス ジャパン 代表執行役員社長 長崎 忠雄 AWS は 2006 年に創業し、「テクノロジーを民主化する」という思いのもとクラウドコンピューティングを提供してきました。AI や機械学習などの領域においても、同様に民主化のための取り組みを続けています。 2023 年 6 月 22 日（米国時間）には、AWS は生成系 AI ソリューションの構築と展開を支援する新プログラム「AWS 生成系 AI イノベーションセンター」を稼働開始。「あらゆる技術領域の民主化を、私たちはお客さまとともに実現します」と長崎は解説しました。 こうした各種の取り組みは、Amazon がミッションステートメントとして掲げる Working Backwards（お客さまを起点に考える）という価値観に基づいています。「AWS LLM 開発支援プログラム」も、日本における LLM の開発・普及を加速させ、各社の事業の成長を目指しているのです。 「たくさんのご応募があったなかから、今回は 17 社を採択いたしました。みなさまとともに日本の技術発展に貢献し、各社のプロダクトが世界に羽ばたくような未来を見据えて、ご支援させてください」と結びました。 執行役員 技術統括本部長 巨勢 泰宏によるご挨拶 続いてはアマゾン ウェブ サービス ジャパン 執行役員 技術統括本部長の巨勢 泰宏からご挨拶をしました。「AWS LLM 開発支援プログラム」にご応募いただいたのは優れた技術や事業を持つ企業ばかりであったこと、選考においても多くの時間がかかったことなどを巨勢は語ります。 アマゾン ウェブ サービス ジャパン 執行役員 技術統括本部長 巨勢 泰宏 AWS は AI・機械学習の領域において、お客さまに長らくサービスの提供や技術的な支援をしてきました。その結果、数多くの成果が生まれています。生成系 AI の領域においても、2022 年 4 月に Amazon Bedrock を発表しただけではなく、たくさんのお客さまを対象として技術的な支援を行ってきました。「生成系 AI を活用してプロダクトを改善したい」「生成系 AI で新たなビジネスを創出したい」という企業・団体のニーズは高まり続けています。そうした声に応えるため、「AWS LLM 開発支援プログラム」をスタートしました。 「このプログラムを通じて、採択企業には新しい化学反応を起こす機会を作っていただきたい。そして、AWS はクラウドという基盤や各種のプログラム、メンタリングなどを提供し、みなさまをご支援していきます」と巨勢は思いを述べました。 「AWS LLM 開発支援プログラム」の詳細を解説 ここからは「AWS LLM 開発支援プログラム」の企画・運営に携わるアマゾン ウェブ サービス ジャパン 機械学習ソリューションアーキテクトの宇都宮 聖子が、本プログラムの概要や採択企業、AWS のサポート体制についてご紹介しました。 アマゾン ウェブ サービス ジャパン 機械学習ソリューションアーキテクト 宇都宮 聖子 本プログラムでは、LLM の開発に必要な 4 つの支援を AWS が提供しています。1 つ目は「計算機リソース選定と確保のガイダンス」です。利用するモデルや深層学習フレームワークなど、参加企業ごとの技術要件に応じた適切なインスタンスの種類の選定や、その計算機リソースを AWS 上で確保するためのガイダンスを実施しています。 2 つ目は「技術相談やハンズオン支援」です。AWS 上での分散学習やクラスタリング時のネットワーク性能最適化、マネージドサービスの活用、 AWS Trainium / AWS Inferentia の利用などについて、AWS の技術エキスパートによるサポートを行います。 3 つ目は「LLM 事前学習用の AWS クレジット」です。総額で 600 万 US ドル規模のクレジットを投資し、事前学習用のワークロードに必要な計算機リソースなどの費用を一部支援します。 4 つ目は「ビジネスプランおよびユースケースに関する支援」です。開発した LLM をビジネスに活用する方法や AWS Marketplace などを活用した LLM の公開・販路拡大支援、 Amazon SageMaker JumpStart の活用、ビジネスクライアント候補やベンチャーキャピタルとのコミュニケーションなどを実施します。 プログラムは以下のような流れで進行します。 参加対象は「LLM 開発を行う国内の企業・団体」「数十億〜一千億パラメータ以上の規模の LLM の事前学習をしている企業・団体」「今年の 11 月末までに開発成果（例: 本番環境でのローンチなど）を出すことを目指している」「クラウドを活用し、より効率的な方法で LLM を開発したい」などの条件を満たす企業・団体です。そして、技術的観点や研究開発的観点、ビジネス的観点といった総合的な要素を鑑みて選考を実施しました。 応募状況としては、前述の長崎の説明でもあったように 60 社弱の応募があり、そのなかから 17 社を採択しました。スタートアップ企業から大企業まで幅広く、多様な LLM モデルの開発を進める企業・団体が含まれています。以下が「AWS LLM 開発支援プログラム」採択企業の一覧です（公開可能な企業および団体）。 会社・団体名（社名五十音順・敬称略） ・カラクリ株式会社 ・株式会社サイバーエージェント ・ストックマーク株式会社 ・Sparticle株式会社 ・Turing株式会社 ・株式会社Preferred Networks ・株式会社Poetics ・株式会社松尾研究所 ・株式会社マネーフォワード ・株式会社ユビタス ・株式会社Lightblue ・株式会社リクルート ・株式会社リコー ・rinna株式会社 ・株式会社ロゼッタ ・株式会社わたしは AWS と上記の企業・団体はすでに以下の取り組みを実施しています。 ・プログラム期間中のスケジューリング ・計算機リソースの確保のガイダンス ・技術とビジネスの両面でのプランニング ・2023 年 8 月 30 日、2023 年 9 月 4 日に Prototyping Camp を実施 宇都宮は AWS のサポート体制についても解説しました。「AWS LLM 開発支援プログラム」では、AWS の国内外のスペシャリスト・スポンサーによって技術・ビジネスの両面から企業・団体のサポートを行います。 スピーチの終盤では、機械学習向け Amazon EC2 インスタンスそれぞれの特徴や、採択企業向けの Prototyping Camp にて各種インスタンスを参加者にお試しいただいたことなども、宇都宮は解説しました。 イベント参加の採択企業によるご挨拶 次に、イベントに参加していた採択企業より「AWS LLM 開発支援プログラム」参加にあたっての意気込みを語っていただきました。 サイバーエージェント社は「マルチモーダルな LLM や次世代アーキテクチャ構築などにチャレンジしたい」と宣言。 リコー社は「採択企業はライバルではなく、ともに LLM 技術の発展を目指す同志だと考えています」と、会場の方々に語りかけます。 ストックマーク社は「さまざまなビジネスのユースケースに活用できる LLM を作りたい」と大きなビジョンを述べ、 Sparticle 社も「LLM 技術の隆盛は歴史的なチャンスだと思っているため、各社とともに頑張りたい」と前向きな気持ちを語りました。 わたしは社は自社プロダクトの大喜利 AI について触れ「これまでも私たちは言語モデルの開発に取り組んできましたが、より一層この技術に力を入れたい」と言及。 完全自動運転 EV の開発を行う Turing 社も「開発した LLM 関連技術を自動運転の改善に活かしたい」と志を述べました。 リクルート社は自社が多種多様な事業を展開していることを述べたうえで、「それらの事業で蓄積したデータやドメイン知識などを活用し、良い LLM を生み出したい」と前向きに解説しました。 アマゾン ウェブ サービス ジャパン スタートアップ事業本部 技術統括部 本部長 塚田 朗弘（写真左） ここで採択企業によるご挨拶の前半パートが終了。「AWS LLM 開発支援プログラム」の企画・運営・立ち上げに携わっているアマゾン ウェブ サービス ジャパン スタートアップ事業本部 技術統括部 本部長の塚田 朗弘が、機械学習やコンピューティングのスペシャリストで支援体制を構築していることを述べ、会場にいる AWS のメンバーから一言ずつコメントをもらいます。そして「乾杯！」の言葉の後に会場の参加者が飲み物を口にし、採択企業によるご挨拶の後半パートに移ります。 ロゼッタ社は自社の歴史・沿革について述べたうえで「AWS 社や他の採択企業とも協力しながら、最良のものを世の中に出していきたい」と提言。 カラクリ社は提供している事業内容にちなみ、「カスタマーサポートの業務を LLM の技術によって改善していきたい」と目標を掲げます。 AI キャラクター「りんな」を提供する rinna 社は「採択企業のみなさまと一緒に AI の民主化を推進したい」と説明。 自然言語処理や画像解析の AI 開発に強みを持つ Lightblue 社は、ユーモアを交えつつ開発のビジョンを語りました。 「音声のコミュニケーションデータと LLM とを組み合わせて新たな可能性を探りたい」と話したのは、音声認識や音から人の感情を解析する AI、自然言語処理などを扱う Poetics 社。 ユビタス社は GPU 仮想化技術やクラウドストリーミング・プラットフォームに強みを持つ自社の事業について解説。 最後に、東京大学松尾研究室の技術の社会実装を目指す松尾研究所社が意気込みを述べ、採択企業によるご挨拶が終了しました。 閉会のご挨拶 イベント最終盤には「AWS LLM 開発支援プログラム」の企画・運営に携わるアマゾン ウェブ サービス ジャパン スタートアップ事業本部 アカウントマネジメント部 部長の岡田 大志が閉会のご挨拶をしました。 「日本を代表する AI・機械学習の専門家のみなさまとこのプログラムをご一緒できることを、非常にうれしく思っています。プログラムにご参加くださった各社には、公募への申し込みやヒアリング、プランニングセッション、Prototyping Camp など多大なるご協力をいただきました」と岡田は感謝の言葉を述べました。 アマゾン ウェブ サービス ジャパン スタートアップ事業本部 アカウントマネジメント部 部長 岡田 大志 ここから本格的な LLM 開発支援が始まり、2023 年 12 月以降の成果発表会を目指して採択企業各社 と AWS はプロジェクトを進めていきます。みなさまの LLM に関する取り組みの成功確率を上げられるように、そして最終的には各社のビジネスにも良い影響を与えられるように、AWS は最大限の支援を行います。 「LLM のトッププレイヤーが一堂に会する機会は、非常に貴重だと思います。今後も AWS はこうした交流会を開催してまいりますので、ぜひみなさま奮ってご参加いただき、情報交換やネットワーク構築にお役立てください」と岡田はイベントを総括しました。

本記事は、「 How to establish private connectivity for ECS Anywhere 」（2023 年 5 月 26 日公開）を翻訳したものです。 はじめに 2014 年、AWS は Amazon Elastic Container Service (Amazon ECS) を発表しました。これは、コンテナ化されたアプリケーションのオーケストレーション、デプロイ、スケーリングを支援するフルマネージド型サービスです。Amazon ECS は、さまざまな業界業種のお客様にご利用いただいていますが、アプリケーションをローカルで実行する必要がある場合もあります。特に規制の厳しい業界ではよくある要件になります。この課題を解決するためにAWSは Amazon ECS を拡張し、2020 年に Amazon ECS Anywhere (Amazon ECS-A)を発表しました。これは、お客様が Amazon ECS のシンプルさと機能性を利用して、コンテナベースのアプリケーションを AWS リージョン以外で、お客様のオンプレミス環境で実行できるオプションです。仮想マシン (VM)、ベアメタルサーバー、またはお客様が管理するその他のインフラストラクチャを使用することが可能となります。 ECS-A コントロールプレーンは AWS 上で動作し、Amazon ECS と同じ API ですが、コンテナベースのアプリケーションは任意のセルフマネージドのハードウェアでホストすることが可能です。このようにコントロールプレーンとデータプレーンを分離するためには、企業のデータセンターと Amazon ECS エンドポイント間の通信パスが必要であり、多くの場合、プライベート通信チャネルが必要になります。 この記事では、AWS リージョン外でホストされている Amazon ECS Anywhere 管理のコンテナベースのアプリケーションと、Amazon ECS コントロールプレーン API との間で、AWS サイト間 VPN (S2S VPN) または AWS Direct Connect (DX) を使用して、安全かつプライベートな方法でプライベート通信チャネルを確立する方法について説明します。 ECS-A ソリューションアーキテクチャ Amazon ECS Anywhere を使用すると、お客様は独自のインフラストラクチャと Amazon ECS を合わせて活用することが可能となり、コンテナワークロードを大規模にスケジュールし、実行することが可能となります。独自のインフラストラクチャを使用するためには、VM を Amazon ECS マネージドインスタンスとして登録する必要があり、お客様の施設と AWS リージョン間の接続が必要です。この接続は、インターネット経由で公開することも、AWS Direct Connect または仮想プライベートネットワーク (VPN) を使用してプライベートに確立することもできます。 コンフィグの一部として、オンプレミス環境には AWS Systems Manager (SSM) エージェントと Amazon ECS エージェントの両方が必要です。 SSM エージェントは AWS Systems Manager のコンポーネントで、AWS Systems Manager のオンホスト機能を実行します。インスタンスから AWS API を実行できるようにするために、インスタンス登録プロセスで、AWS Systems Manager がアクティベーションキーとインスタンスロール認証情報を生成して SSM エージェントに送信します。もう 1 つのコンポーネントは Amazon ECS エージェントで、これは AWS リージョンの Amazon ECS コントロールプレーンと通信し、サーバーまたは VM をマネージドインスタンスとして登録し、コンテナ設定やタスクスケジューリングなどの指示を受信して実行します。図 1 はこのアーキテクチャを示しています。 図1 ソリューション概要 ECS-A プライベート通信アーキテクチャ Amazon ECS Anywhere は接続切断や信頼性の低い接続に耐えられますが、AWS リージョンとお客様の施設間のプライベート接続により、より高いレベルのセキュリティ、信頼性、およびパフォーマンスが保証されます。図 2 は、Amazon ECS エージェントと SSM エージェントがコントロールプレーン API を使用してプライベートかつ安全に通信できるアーキテクチャを示しています。ECS Anywhere コントロールプレーン API 宛のプライベート VPC エンドポイントを作成し、DNS クエリを Route 53 インバウンドリゾルバーエンドポイントに転送し、プライベート IP アドレスで応答することで、エージェントはプライベート通信チャネル (DX やサイト間 VPN など) を介して AWS サービスと通信します。 図2 前提条件 このソリューションの前提条件は以下となります。 AWS アカウント Amazon ECS Anywhere クラスタ AWS Direct Connect や サイト間 VPN によるVPC とオンプレミス環境間のプライベート接続 プライベート通信チャネル この記事では、オンプレミス環境と AWS VPC の間にプライベート通信チャネルを設定する方法については詳しく説明しません。ただし、(1) AWS Direct Connect と (2) サイト間 VPN の 2 つのオプションがあります。 どちらを選択しても、この通信チャネルが設置されていれば、AWS とオンプレミス環境との間にプライベート IP アドレスを使用して双方向接続が可能になります。 ウォークスルー 以下のコンポーネントは任意の順序でデプロイできます。 Amazon VPC 内で Amazon ECS と AWS Systems Manager のインターフェース VPC エンドポイント( AWS PrivateLink ) Amazon VPC 内での Route 53 リゾルバーのインバウンドエンドポイント オンプレミス環境での DNS 条件付き転送ルール 最後に、オンプレミス環境の Amazon ECS-A エージェントが AWS とプライベートに通信するように設定します。 AWS PrivateLink AWS PrivateLink は、トラフィックをインターネットに公開することなく、VPC、AWS サービス、オンプレミスネットワーク間のプライベート接続を提供します。AWS PrivateLink を使用するには、 インターフェイス VPC エンドポイントを作成 します。VPC エンドポイントを作成すると、指定したサブネットにネットワークインターフェイスが作成され、サブネットのアドレス空間からのプライベート IP がそのインターフェイスに割り当てられます。このアーキテクチャでは、6 つのエンドポイントを作成する必要があります。 com.amazonaws.&lt;region&gt;.ecs-agent com.amazonaws.&lt;region&gt;.ecs-telemetry com.amazonaws.&lt;region&gt;.ecs com.amazonaws.&lt;region&gt;.ssm com.amazonaws.&lt;region&gt;.ssmmessages com.amazonaws.&lt;region&gt;.ec2messages 図3 オプションとしてAmazon Elastic Container Registry ( Amazon ECR ) を使用してコンテナイメージを保存する場合は、 以下のエンドポイント が追加で必要になります。 com.amazonaws.&lt;region&gt;.ecr.dkr com.amazonaws.&lt;region&gt;.ecr.api com.amazonaws.&lt;region&gt;.s3 また、 Amazon CloudWatch Logs でログを受信したい場合は、以下のエンドポイントも必要になります。 com.amazonaws.&lt;region&gt;.logs Route 53 インバウンドリゾルバー オンプレミスリソースが VPC エンドポイントの DNS 名をプライベート IP アドレスに解決する必要があります。このステップを省略した場合、ドメイン名がパブリック IP アドレスに解決されます。 1 つの選択肢は、VPC エンドポイントの A レコードをオンプレミスの DNS サーバーに設定することです。ただし、エンドポイントを再作成したり、サブネットを変更したりする場合は、これらの A レコードを手動で変更する必要があります。言い換えると、これらのレコードが最新の状態に保たれるようにする責任をユーザーが持つ必要があります。 それに対して、推奨される解決策は、Amazon Route 53 リゾルバー用のインバウンドエンドポイントを作成することです。インバウンドエンドポイントを使用すると、外部ネットワークからの VPC に対する DNS クエリを解決できます。そして、オンプレミス DNS サーバーが特定のドメインのクエリを Route 53 リゾルバーに転送するように、条件付き転送ルールを設定します。これにより、VPC 内のリソースの DNS レコードの管理について心配する必要がなくなります。 「 インバウンド転送の設定 」セクションの手順に従って設定してください。図 4 は、2 つの IP アドレスを持つ構成済みのインバウンドエンドポイントの例を示しています。 図4 オンプレミスの DNS 解決 最後のステップは、前述の 6 つのサービスのクエリを転送するようにオンプレミス DNS サーバーを構成することです。&lt;region&gt;.amazonaws.com ドメインを Route 53 リゾルバーのインバウンドエンドポイントの IP アドレスに送信します。これは DNS サーバーソフトウェアに大きく依存します。図 3 の 6 つのエンドポイントに対して、次の DNS 転送を構成する必要があります。 ecs-a*.us-east-2.amazonaws.com ecs-t*.us-east-2.amazonaws.com ecs.us-east-2.amazonaws.com ssm.us-east-2.amazonaws.com ssmmessages.us-east-2.amazonaws.com ec2messages.us-east-2.amazonaws.com これらの設定の後、オンプレミスエージェント (Amazon ECS と SSM) が AWS エンドポイントに到達しようとする際に、ターゲットドメイン名を解決すると、オンプレミス DNS サーバーは DNS クエリを Route 53 インバウンドリゾルバーに転送し、対応する VPC エンドポイントのプライベート IP が応答されます。エージェントは、事前に確立されたプライベート通信チャネル (DX や S2S VPN など) を使用して VPC エンドポイントのプライベート IP と通信します。 ハイブリッド DNS アーキテクチャの詳細については、 Hybrid Cloud DNS Options for Amazon VPC のホワイトペーパーをご覧ください。 DNS 設定およびオンプレミス環境から Route 53 Resolver エンドポイントの IP へのアクセスを確認するには、dig、nslookup、またはその他任意の DNS ルックアップコマンドを使用できます。 $ nslookup api.ecr.us-east-2.amazonaws.com Server: 10.0.0.32 Address: 10.0.0.32#53 Non-authoritative answer: api.ecr.us-east-2.amazonaws.com canonical name = ecr.us-east-2.amazonaws.com. Name: ecr.us-east-2.amazonaws.com Address: 10.0.0.45 結果には、インターフェイス VPC エンドポイントのプライベート IP（前の例では 10.0.0.45）が出力されるはずです。 設定の詳細とトラブルシューティングのヒントについて、「 How do I configure a Route 53 Resolver inbound endpoint to resolve DNS records in my private hosted zone from my remote network 」の記事には Route 53 Resolver インバウンドエンドポイントの詳細な設定手順が記載されています。 SSM エージェントと ECS-A エージェント ここまできて、Amazon ECS-A をセットアップすることができます。クラスターのアクティベーションキーを取得し、両方のエージェントをインストールして、インスタンスを登録します。 詳細な手順については、「 クラスターへの外部インスタンスの登録 」のドキュメントページを参照してください。 クリーンアップ 追加の検証コストの発生を防ぐために、作成したすべての VPC エンドポイントとインバウンドエンドポイントを削除してください。 VPC エンドポイントの削除 VPC コンソール を開きます。 [仮想プライベートクラウド] の [エンドポイント] に移動します。 作成したエンドポイントを選択し、[アクション] → [VPC エンドポイントの削除] をクリックします。 インバウンドエンドポイントの削除 Route 53 コンソール を開きます。 [リゾルバー] セクションの [インバウンドエンドポイント] に移動します。 インバウンドエンドポイントを選択します。 [削除] を選択します。 結論 この記事では、AWS サイト間 VPN または AWS Direct Connect のプライベート接続を使用して、Amazon ECS Anywhere の高いレベルのセキュリティと信頼性を実現する方法を紹介しました。 AWS 側で必要な設定手順 (インターフェイスエンドポイントとリゾルバーエンドポイント) と、オンプレミスの DNS 転送の設定手順の概要について説明しました。 自身の環境でこのソリューションを試して、プライベート通信チャネルを活用してください。Amazon Simple Storage Service ( Amazon S3 ) や Amazon CloudWatch など他のサービスにも同様のトラフィックフローを適用することができます。詳細については、「 Hybrid Networking using VPC Endpoints (AWS PrivateLink) and Amazon CloudWatch for Financial Services 」と「 Secure hybrid access to Amazon S3 using AWS PrivateLink 」の記事をご覧ください。 著者について Ivo Pinto Ivo は AWS のシニアソリューションアーキテクトです。Ivo は、ネットワークを専門とし、オンプレミスとクラウドの両方で世界規模のインフラストラクチャを構築した経歴があります。3 つの CCIE を持ち、Cisco Press の「Network Automation Made Easy」という本を執筆しています。 Diogo Minhava Lopes Diogo は AWS のシニアソリューションアーキテクトです。ソフトウェア開発の経歴があり、共同設立したスタートアップ企業を含め、異なる規模の企業にクラウドテクノロジーを活用する 8 年間の経験を持ちます。 Pedro Santos Pedro は、リスボンを拠点とする AWS のシニアソリューションアーキテクトです。データエンジニアリングとクラウドアーキテクチャを専攻し、過去 8 年間クラウドテクノロジーに携わってきました。 翻訳はソリューションアーキテクトの陳誠が担当しました。

この記事は Improving operational visibility with AWS Fargate task retirement notifications (記事公開日 : 2023 年 9 月 6 日) の翻訳です。 導入 AWS Fargate は、コンテナワークロードのためのサーバーレスコンピューティングエンジンであり、基盤となるインフラストラクチャの保護やパッチ適用といった、ビジネスに付加価値をもたらさない作業から解放してくれます。この記事では、AWS がインフラストラクチャを安全かつ最新の状態に保つための仕組みの 1 つである Fargate タスクのリタイア通知 について深掘りします。 AWS は、Fargate タスクのリタイアプロセスに関する最近のアップデートにおいて、お客様が受け取る リタイアに関する通知 を統合し、 リタイア通知を受け取ってから実際にタスクがリタイアするまでの時間 を制御する仕組みを導入しました。この記事では、これらの変更点を詳しく確認し、リタイア通知を使用して オペレーショナルエクセレンス を実現する例を紹介します。 背景 AWS Fargate 上に Amazon Elastic Container Service (Amazon ECS) タスクをデプロイする際、スタンドアロンタスクを実行する API コール または ECS サービス において、 プラットフォームバージョン を指定します。プラットフォームバージョンは、カーネルとコンテナランタイムの組み合わせで構成される、ホスト OS のランタイム環境を指します。また、プラットフォームバージョンには、内部的に複数のプラットフォームバージョンリビジョンが存在します。プラットフォームバージョンリビジョンはイミュータブルであり、例えばカーネルのバグ修正やセキュリティアップデートなど、環境の変化に追従してリリースされます。新しいタスクが AWS Fargate にスケジューリングされると、指定されたプラットフォームバージョンの最新リビジョンでタスクが起動します。 AWS は、時間の経過とともに「タスクを実行中の既存のプラットフォームバージョンリビジョンをリタイアさせる必要がある」と判断することがあります。リビジョンがリタイアすると、AWS Fargate はそのリビジョンで実行中のすべてのタスクを終了します。リビジョンをリタイアさせる理由には、セキュリティの脆弱性やパフォーマンスの改善などがあります。AWS Fargate では、これまで月に 1、2 個のプラットフォームバージョンリビジョンをリタイアさせてきましたが、プラットフォームバージョンリビジョンには特に決まったサポート期間は存在しません。プラットフォームバージョンリビジョンのライフサイクルを考慮すると、短命のワークロードを実行している場合には、数週間にわたって実行されるタスクを実行している場合に比べて、リビジョンのリタイアに伴いタスクが終了する可能性は小さくなります。 上図は、AWS Fargate プラットフォームバージョンリビジョンのライフサイクル全体を示します。新しいプラットフォームバージョンリビジョンが利用開始されると、すべての新しいタスクは新しいリビジョンに配置されるようになります。すでに配置され、実行中の既存のタスクは、タスクのライフサイクル全体において最初に配置されたリビジョンに留まり、新しいリビジョンに移行することはありません。 ECS サービスの更新 や Fargate タスクのリタイアなどの理由でタスクが置き換えられる場合、新しいタスクは、起動時に利用可能な最新のプラットフォームバージョンリビジョンに配置されます。 タスクのリタイア 下図に、Fargate タスクのリタイアプロセスの全体像を示します。 特定のプラットフォームバージョンリビジョンをリタイアさせる必要がある場合、すべての AWS リージョンにおいて、AWS はそのプラットフォームバージョンリビジョンで実行中のすべてのタスクを特定します。その後、リージョンごと、アカウントごとに 1 つの通知を送信し、影響を受けるタスクやサービス、実際にリタイアプロセスが開始する日時を案内します。通知は、AWS アカウントのプライマリメールアドレスおよび AWS Health Dashboard に送信されます。AWS Health Dashboard に送信された通知は、 Amazon EventBridge を通じて AWS サービスやサードパーティツール に転送できます。 リタイア通知が送信されてから AWS Fargate が自動的にタスクのリタイアプロセスを開始するまでの正確なタイミングを制御したい場合、タスクのリタイア待機時間と呼ばれる値を設定し、対応するための時間を指定できます。タスクが ECS サービスとして実行されている場合、AWS Fargate は ECS サービスの minimumHealthyPercent を考慮しつつタスクを置き換えます。 スタンドアロンタスク の場合、実行中のタスクの状態を監視し、タスクを置き換えるのはお客様の責任です。 Fargate タスクのリタイアの影響を最小化するために、 Amazon ECS ベストプラクティス に従ってワークロードをデプロイするべきです。例えば、ウェブサーバーや API サーバーなどのステートレスなアプリケーションを ECS サービスとしてデプロイする場合、タスクの複数のレプリカをデプロイし、 minimumHealthyPercent を 100% に設定します。これにより、AWS Fargate がタスクのリタイアを開始した際に、Amazon ECS はまず新しいタスクをスケジューリングし、 実行 されるのを待ってから、古いタスクを終了します。 タスクのリタイアプロセスの詳細については、 AWS Fargate ドキュメント を参照してください。 タスクのリタイア待機時間 タスクのリタイア待機時間の値は、 Amazon ECS アカウント設定 内の fargateTaskRetirementWaitPeriod で制御できるようになりました。例えば、特定のウィンドウでのみ停止可能なワークロードを実行している場合、タスクのリタイア待機時間を使用して、独自のスケジュールでタスクを終了するように設定できます。 タスクのリタイア待機時間には、以下の表のいずれかの値を設定できます。新しいプラットフォームバージョンリビジョンをより早く適用するために、できる限り待機時間を短く設定することをおすすめします。 日数 アクション 0 通知を送信してすぐに、影響を受けるタスクのリタイアを開始します。 7 通知を送信してから 7 日後に、影響を受けるタスクのリタイアを開始します。 14 通知を送信してから 14 日後に、影響を受けるタスクのリタイアを開始します。 稀に重大なセキュリティアップデートがある場合、AWS Fargate は設定したタスクのリタイア待機時間を上書きし、待機時間無しで対象のタスクをリタイアさせることがあります。この場合、 fargateTaskRetirementWaitPeriod を 0 に設定した場合と同じ挙動となります。 現在の fargateTaskRetirementWaitPeriod の値は、 aws ecs list-account-settings コマンドで確認できます。 $ aws ecs list-account-settings \ --name fargateTaskRetirementWaitPeriod \ --effective-settings { "settings": [ { "name": " fargateTaskRetirementWaitPeriod", "value": "14", "principalArn": "arn:aws:iam::123456789012:root" } ] } fargateTaskRetirementWaitPeriod を変更したい場合は、 aws ecs put-account-setting-default コマンドを使用します。 $ aws ecs put-account-setting-default \ --name fargateTaskRetirementWaitPeriod \ --value 14 タスクのリタイア待機時間の詳細については、 Amazon ECS ドキュメント と Amazon ECS 開発者ガイド を参照してください。 ソリューション概要 : タスクのリタイア通知を捕捉する タスクのリタイアが予定されている場合、AWS は AWS Health Dashboard と AWS アカウントのプライマリメールアドレスに タスクのリタイア通知 を送信します。AWS Health Dashboard は、 Amazon EventBridge を含む多くの AWS サービス と統合されています。Amazon EventBridge を利用することで、ChatOps ツールに通知を転送してリタイアの可視性を高めたり、タスクのリタイア通知への対応を自動化することもできます。 AWS Health Aware は、AWS Health Dashboard のパワーと通知を組織全体に配布する方法を紹介する素晴らしいリソースです。このプロジェクトを参考に、タスクのリタイア通知をチャットアプリケーションである Slack に転送する例を紹介します。このソリューションでは、タスクのリタイア通知は EventBridge ルールによって捕捉され、Event Detail Type が AWS Health Event かつ Event Detail Code が AWS_ECS_TASK_PATCHING_RETIREMENT であるイベントがフィルタリングされます。ルールが通知を捕捉すると、 AWS Lambda 関数をトリガーし、影響を受けるリソースのイベントを解析、 Slack Incoming Webhook に転送します。 下図に、このソリューションのアーキテクチャを示します。 前提条件 ソリューションのウォークスルーを実施するには、以下の前提条件を満たす必要があります。 Incoming Webhook Slack アプリケーション がインストール、有効化された既存の Slack ワークスペース Amazon EventBridge ルールと AWS Lambda 関数をデプロイするための権限を持つ AWS アカウント AWS SAM CLI がインストールされたローカル開発環境 ウォークスルー このウォークスルーのサンプルコードは GitHub リポジトリ で確認できます。まず最初のステップとして、リポジトリをローカル開発環境にクローンします。 $ git clone https://github.com/aws-samples/capturing-aws-fargate-task-retirement-notifications.git $ cd capturing-aws-fargate-task-retirement-notifications 次に、AWS SAM テンプレート ( cloudformation.yaml ) で定義した Lambda 関数と EventBridge ルールをビルド、デプロイします。デプロイウィザードでは、Slack ワークスペース URL や Slack チャンネルなどのパラメータを入力する必要があります。 $ sam build --template cloudformation.yaml $ sam deploy --guided Configuring SAM deploy ====================== Looking for config file [samconfig.toml] : Not found Setting default arguments for 'sam deploy' ========================================= Stack Name [sam-app]: FargateTaskRetirementNotifications AWS Region [eu-west-1]: eu-west-1 Parameter SlackWorkspaceURL []: https://hooks.slack.com/services/workspace/app/token Parameter SlackChannel []: platform-eng #Shows you resources changes to be deployed and require a 'Y' to initiate deploy Confirm changes before deploy [y/N]: y #SAM needs permission to be able to create roles to connect to the resources in your template Allow SAM CLI IAM role creation [Y/n]: #Preserves the state of previously provisioned resources when an operation fails Disable rollback [y/N]: Save arguments to configuration file [Y/n]: SAM configuration file [samconfig.toml]: SAM configuration environment [default]: それでは、テストしましょう！ ここでは、Amazon EventBridge に 2 つのサンプルイベントを送信し、期待通りに動作することを確認します。AWS Health の通知を再現することはできないので、代わりに EventBridge ルールにマッチする EventBridge イベントを作成して、ワークフローをトリガーします。サンプルリポジトリには、ECS サービスとしてデプロイされたタスク用と、スタンドアロンタスク用の 2 つのイベントが用意されています。 $ aws events put-events --entries file://sample_service_event.json $ aws events put-events --entries file://sample_task_event.json Slack ワークスペースにて、テストイベントごとに 1 つ、合わせて 2 つの Slack 通知を確認できるはずです。 後片付け ウォークスルーで作成したリソースを削除するには、 sam delete コマンドで CloudFormation スタックを削除します。 まとめ この記事では、Fargate タスクのリタイアプロセスについて深堀りし、リタイア通知からタスクのリタイアまでの時間を制御したい場合に、タスクのリタイア待機時間を変更する方法を紹介しました。その後、Amazon EventBridge と AWS Lambda を使用してタスクのリタイア通知を捕捉する方法を紹介しました。Fargate タスクのリタイアの詳細については、 AWS Fargate ドキュメント を参照してください。

本ブログ記事は、KDDI株式会社 ソリューション事業本部 DX推進本部 スマートシティ推進室 PFデザイングループリーダー 中嶋優氏と、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 新谷 が共同で執筆しました。本実証実験に関する詳細なレポートは こちら をご覧ください。 はじめに 住民に安心安全な暮らしを提供し、まちの持続的な価値向上に繋げるために、民間主導によるまちの賑わい創出、維持管理、防災などの実装を通じたエリアマネジメントが活発化しています。高度なまちづくり実現のために AWS クラウドを始めとしたテクノロジーを導入し、スマートシティの取り組みを加速する動きも国内外で行われています。一方で、エリアマネジメントに関わるステークホルダーは多く、安定的な財源確保も課題となりやすいことから、合意形成に時間を要することもあります。 KDDI株式会社（以下、KDDI）含む実施事業者（他：東日本旅客鉄道株式会社（以下、JR東日本）、東急不動産株式会社、株式会社日建設計）は、3D 都市モデルを活用した大規模誘導・避難シミュレーションによって防災計画の計画検証や合意形成をサポートする実証実験を行いました。その中で、KDDI は、国土交通省が主導する 3D 都市モデルの整備・活用・オープンデータ化プロジェクトである PLATEAU のデータを活用し、Amazon Elastic Compute Cloud (Amazon EC2) G4dn インスタンス上の Unreal Engine 4 で 1 万人を超える避難シミュレーションを実現しています。 また、Amazon QuickSight・Amazon AppStream 2.0 等のマネージドサービスを駆使して、関係者が簡単にシミュレーション結果を参照するための仕組みも構築しました。結果として、関係者との討議の中で、まちづくりや防災業務、議論の可視化に対して有用性を確認する事ができています。 本ブログでは、KDDI の寄稿により「防災エリアマネジメントDX」の取り組みを技術的な観点からご紹介します。 KDDI の防災エリアマネジメントDX の取り組み KDDI は、JR東日本が手掛ける「TAKANAWA GATEWAY CITY」の都市計画・まちづくりに参画し、「防災」を切り口にしたエリアマネジメント DX の実証実験を行いました。防災は潜在リスクが把握されにくいことから、重要性が認識される一方で、合意形成が困難かつ成果を実感しづらいという理由から取組が停滞しやすいといえます。そのため、 3D 都市モデルを活用した大規模誘導・避難シミュレーション環境を整備し、災害時の潜在リスクや避難誘導計画を 3 次元的に可視化することによって、防災計画の計画検証や合意形成をサポートすることを目標としました。 アーキテクチャ 本実証実験では 1 万人を超える大規模な人流シミュレーションを行う環境を構築しました。シミュレーション実行環境として、NVIDIA T4 GPU を搭載した Amazon EC2 の g4dn.4xlarge インスタンス上に Unreal Engine 4 を構築し、セキュアで高性能なリモートデスクトップ環境を NICE DCV で実現しています。AWS を活用することで、事前の厳密なサイジングをすることなくインスタンスタイプを変更しながら試行錯誤し、最適化できることが利点の一つでした。 また、多くの都市計画策定関係者と協議するために、シミュレーション結果を共有する仕組みが必要でした。本実証実験では、シミュレーション結果のログを QuickSight で可視化するとともに、AppStream 2.0 を活用してリプレイシステムを整備し、関係者が容易に結果を参照できる仕組みを構築しています。以下では、技術的なポイントをいくつかご紹介します。 大規模人流シミュレーションのための最適化 本実証実験では、3D 都市モデルを Unreal Engine に取り込み、シナリオ要件に合わせて属性毎に異なる歩行速度とサイズを設定したキャラクターを、1 万人規模でシミュレーションする必要がありました。しかし、当初はキャラクターの移動処理において、Unreal Engine のデフォルト実装では GameThread の処理がボトルネックとなりパフォーマンスが出ない状況にありました。そのため、Visual Studio を利用できる Microsoft Visual Studio AMI を採用し、Unreal Engine 自体の実装に一部手を入れています。 具体的には、移動処理を TaskGraphThread で実行しマルチスレッド化することで、タスク待ち状態で活用されていなかった CPU リソースを有効活用する追加実装を行いました。これによって、GameThread のボトルネックを解消し、フレームレートを改善することに成功しました。また、キャラクターもアニメーション処理を削減し軽量化することで更に負荷を軽減する対応も行っています。なお、Visual Studio は後述するリプレイ操作や、ログ・リプレイファイルの Amazon Simple Storage Service (Amazon S3) へのアップロードと AWS Glue ジョブ実行など Blueprint だけで実現できなかった部分の実装にも活用しました。 シミュレーション結果の分析と可視化 避難に要する時間を可視化し、また人の密集度から移動に時間がかかった要因を抽出できるように、シミュレーション結果の分析環境を整備しました。分析フローとして、まずキャラクターの毎秒の座標・移動開始時間・移動完了時間・属性情報などのログを Unreal Engine から Amazon S3 にアップロードします。そして、Amazon Athena で移動完了時間の集計を行うとともに、計測エリアの面積とキャラクター面積・到達人数に基づき、AWS Glue によって密集度を計算しています。これらの計算結果は、QuickSight によって、時系列に沿った密集度の推移グラフや、移動完了時間毎のゴールした人数グラフとして可視化しています。実証実験では、密集度と移動完了時間の閾値を超過した場合にリプレイ動画を確認し、移動時間が長くなった原因の考察や危険な場所の有無を確認するという検証を行っていましたが、このような分析環境も AWS のマネージドサービスを活用することで容易に構築し、開発工数を削減することができています。 移動経路上の密集度 ゴールエリアの密集度 移動完了時間の分布 Amazon AppStream 2.0 によるシミュレーションリプレイ環境の提供 各社の都市計画策定関係者が、シミュレーション結果を参照しながら協議できるようにする必要がありました。そのため、シミュレーション完了時に出力できる Unreal Engine のリプレイファイルを、Amazon S3 経由で AppStream 2.0 から再生して再現可能な環境を構築しています。グラフィックスを多用するシミュレーションのリプレイ環境も、AppStream 2.0 の グラフィック G4dn インスタンスによるクラウドレンダリングとストリーミングを駆使することで、容易に関係者が参照できるようになっています。Unreal Engine のクラウドレンダリングの仕組みである Pixel Streaming を活用するのに比べて、環境構成がシンプルになり構築の労力が小さいことと、ストリーミング配信用のインスタンス管理・運用面においても、AppStream 2.0 が容易だったため採用しました。 AppStream 2.0 上のリプレイ画面 今後に向けて 今回の実証実験を通じて、3D 都市モデルを活用した大規模人流シミュレーションが防災業務活用や議論の底上げに繋がるという一定の効果を観測することができました。KDDI は、今後も技術的改善を重ねてより大規模にシミュレーションを実現可能にしていきたいと考えており、 AWS SimSpace Weaver の活用も検討しています。また、防災以外にもユースケースを創出することでビジネス拡大に繋げていくことが今後の目標です。 まとめ 本ブログでは、KDDI株式会社による AWS を活用した大規模人流シミュレーション事例をご紹介しました。ご紹介した主要なサービスは以下のとおりです。 Amazon EC2 G4 インスタンス : 画像分類、オブジェクト検出、音声認識などの機械学習モデルをデプロイしたり、リモートグラフィックワークステーション、ゲームストリーミング、グラフィックレンダリングなど、グラフィックを多用するアプリケーション向けの、業界で最も費用対効果が高く用途の広い GPU インスタンスです。G4 インスタンスは、NVIDIA GPU (G4dn) または AMD GPU (G4ad) を選択して使用できます。 Amazon QuickSight : 非常に高速で使いやすいクラウド対応のビジネス分析サービスで、組織内のすべての従業員が可視化の構築、アドホック分析の実行、およびデータからいつでも、どのデバイス上でもビジネスインサイトを迅速に得ることを容易にします。 Amazon AppStream 2.0 : 安全性、信頼性、拡張性に優れたアプリケーションストリーミング、SaaS 変換、および仮想デスクトップのサービスです。Graphics Design、Graphics Pro、Graphics G4、Graphics G5 というインスタンスファミリーを活用することで、ユーザは GPU 負荷の高いアプリケーションに任意のコンピュータからいつでもアクセスすることができます。 著者 中嶋 優 KDDI株式会社 ソリューション事業本部 DX推進本部 スマートシティ推進室 PFデザイングループリーダー 新谷 歩生 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 エンタープライズ技術本部 通信・メディアグループ 通信ソリューション第三部 シニアソリューションアーキテクト

はじめに Amazon Elastic Container Service (Amazon ECS) &nbsp;でコンテナワークロードを簡単かつ素早くビルド可能にする、 ECS Blueprints &nbsp;for&nbsp; AWS Cloud Development Kit (AWS CDK) &nbsp;をご紹介いたします。ECS Blueprints は、Amazon ECS クラスター上でコンテナワークロードを設定しデプロイするのに役立つ、Infrastructure as Code (IaC) のオープンソースモジュールの集まりです。ECS Blueprints は、お客様が Amazon ECS への移行を開始する際だけでなく、既存のクラスターに Application Load Balancer&nbsp;(ALB) によるフロントエンドサービスなど特定のワークロードを構築する際にも使用できます。また、ECS Blueprints&nbsp;は各シナリオのベストプラクティスを示し、リファレンスアーキテクチャとソリューションパターンを提供します。ECS Blueprints&nbsp;は、特定シナリオのエンドツーエンドの要件に対応しているため、お客様は Amazon ECS ワークロードの構築をスピードアップすることができます。さらに、ECS Blueprints テンプレートをユースケースに合わせて簡単にカスタマイズすることも可能です。これについてはこの記事で詳しく説明します。 AWS CDK は、使い慣れたプログラミング言語を使用してクラウドインフラストラクチャをモデル化およびプロビジョニングするオープンソースのソフトウェア開発フレームワークです。そのため、開発者は TypeScript、Python、Java などの使い慣れた言語を使用して、インフラストラクチャのプロビジョニングとビジネスロジックの構築を同時に行うことができます。さらに、AWS CDK の組み込みコンポーネントは 1 つ以上の AWS リソースで構成される高レベルの抽象化であるため、お客様は AWS CDK コンストラクトによって定義されたパラメータのカスタム値を使用して、複数の環境を素早く設定しデプロイできます。 この記事では AWS CDK を使用した ECS Blueprints に焦点を当てていますが、Terraform を使用した ECS Blueprints も同じリポジトリにあり、Terraform でも同様の概念を実装しています。 モチベーション コンテナは、アプリケーションのパッケージングとデプロイのデファクトスタンダードです。コンテナにはアプリケーションの依存関係がすべて含まれており、開発者のラップトップから本番環境まで、あらゆるマシンで一貫して起動します。コンテナの移植性により、お客様はエンドツーエンドの自動化されたソフトウェアデリバリーパイプラインを構築でき、ソフトウェアを頻繁かつ迅速にリリースできます。しかし、多くの新規顧客にとって、これらのメリットを得るために必要な学習曲線とスキルは非常に厳しい場合があります。コンテナイメージの構築方法を学び、Amazon ECS などのコンテナオーケストレーションを理解し、デプロイアーティファクトを作成し、オブザーバビリティとセキュリティのための仕組みを作成し、継続的インテグレーション (CI) と継続的デプロイ (CD) パイプラインを設定する必要があります。Amazon ECS や AWS Fargate &nbsp;によって手間のかかる作業を大幅に省くことができますが、それでも新規ユーザーが高めるべきスキルは、かなり多岐にわたります。 ECS Blueprints によって、新規ユーザーがコンテナベースのモダナイゼーションによって得られるメリットを、数か月ではなく数時間で実現できるようにしたいと考えています。ブループリントは、新規ユーザーがすぐに始めることができ、実践を通じて学習できるようにすることを目的としています。ECS Blueprints では、ベストプラクティスと適切に設計されたアーキテクチャパターンを体系化し、CI/CD、オブザーバビリティ、セキュリティ、コスト効率に対応するエンドツーエンドのソリューションを提供することを目指しています。この投稿では、コンピューティングとしてサーバーレスコンテナエンジンである AWS Fargate を使用し、Infrastructure as Code として AWS CDK を使用する ECS Blueprints について詳しく説明します。 ECS Blueprints の構造理解 AWS CDK 開発のベストプラクティスの 1 つは、「コンストラクトによるモデリングとスタックによるデプロイ」です。つまり、複数の AWS リソースからアプリケーションの上位論理ユニットのコンストラクトを構築します。このベストプラクティスガイドラインに従い、 コンポーネントディレクトリ を複数のシナリオで再利用できるようにカスタムコンストラクトで構成しました。この記事の執筆時点では、 コンポーネントディレクトリ にはコアインフラストラクチャと CI/CD パイプラインの 2 つのコンストラクトがあります。 コアインフラストラクチャのコンストラクト は、Amazon VPC (Amazon Virtual Private Cloud)、Amazon ECS クラスター、プライベート DNS 名前空間などで構成されています。Amazon ECS への移行を開始するために必要な、基本的な AWS リソースの集まりです。 CI/CD&nbsp;のコンストラクト は、 AWS CodeBuild 、 Amazon Elastic Container Registry (Amazon ECR) 、 AWS CodePipeline 、および関連する AWS IAM ロールからなります。この 2 つのコンストラクトを各 ECS Blueprints&nbsp;テンプレートに埋め込む代わりに、カスタムコンストラクトにしました。この設計の利点は、お客様が繰り返し使用するソースコードを減らせることです。お客様はこのコンストラクトをプログラミング言語の関数として、複数の ECS Blueprints テンプレートに簡単に挿入できます。 図 1. AWS CDK のための ECS Blueprints の一部 コンポーネントディレクトリ と同じ階層の各ディレクトリには、Amazon ECS ワークロードの名前が付けられています。そして、そのディレクトリ配下の各テンプレートは、以下に示したものと同じ階層構造に従います。 └── &lt;workload name&gt; ├── lib │ ├── __init__.py │ ├── &lt;workload name&gt;_stack.py │ ├── &lt;workload name&gt;_stack_props.py ├── README.md ├── __init__.py ├── app.py ├── cdk.json ├── sample.env lib/&lt;workload name&gt;_stack.py – このブループリントアプリケーションのメインスタックのコンストラクトが定義されているファイル。 lib/&lt;workload name&gt;_stack_props.py – アプリケーションのメインスタックに必要な変数で構成されているファイル。 README.md –&nbsp;この ECS Blueprints&nbsp;の使用方法を説明するファイル。 __init__.py –&nbsp;ディレクトリを Python パッケージとして扱うために使用されるファイル。 app.py – この Amazon ECS アプリケーションを実行するためのエントリーポイント。 cdk.json –&nbsp;CDK コンストラクトツリーを生成するために、実行する必要がある実行可能な CDK を定義している AWS CDK の設定ファイル。 sample.env – この ECS&nbsp;Blueprints テンプレートの実行に必要な、変数のサンプルコレクション。 AWS CDK スタックはデプロイの単位であるため、スタックのスコープ内で定義されるすべての AWS リソースのライフサイクルは同じです。この特性に基づいて、各機能を異なるテンプレートに分割しました。 ウォークスルー このウォークスルーでは、ECS Blueprints テンプレートを使用して Amazon ECS クラスターに簡単なウェブアプリケーションをデプロイします。最も一般的なワークロードであるこのアプリケーションでは、エンドユーザーが アプリケーションロードバランサー のエンドポイント経由でサービスにアクセスできます。ALB を経由するトラフィックはフロントエンドサービスによって処理され、フロントエンドサービスはサービスディスカバリーを通じてバックエンドサービスと通信します。 図 2. AWS CDK を通じてデプロイされたフルスタックアプリケーションのアーキテクチャ 前提条件 ECS Blueprints&nbsp;で Amazon ECS ワークロードを簡単に設定できることを示すために、フルスタックアプリケーションのプロビジョニングに 2 つの ECS Blueprints テンプレートを使用します。このウォークスルーには、以下の準備が必要です。 AWS Command Line Interface (AWS CLI) version 2 AWS CDK Toolkit Python での AWS CDK の使用 Python ≥ 3.6+ Git ウォークスルーする場所で AWS 認証情報を設定します。始めに、 ECS Blueprints Github リポジトリ をクローンします。 git clone https://github.com/aws-ia/ecs-blueprints.git Step 1:&nbsp;コアインフラストラクチャとバックエンドサービスをデプロイ バックエンドサービスのブループリントは、次のステップでデプロイするフロントエンドアプリケーションのトラフィックを処理する Node.js バックエンド API をデプロイします。このバックエンドサービスには、 AWS Cloud Map &nbsp;に登録されたサービスディスカバリー名を持っています。この Amazon ECS クラスターで実行されている他のサービスは、バックエンドサービスのディスカバリー名を使用してバックエンドサービスにアクセスできます。 cd ecs-blueprints/cdk/examples/backend_service/ ご自身の環境に合わせて AWS アカウントと AWS リージョンの環境変数を設定します。この投稿では、例としてオレゴンリージョン (us-west-2) を使用します。次に、AWS CDK テンプレートで使用する .env ファイルを生成します。バックエンドサービスのデプロイ時に、.env&nbsp;ファイル内の変数が取得されます。 export AWS_ACCOUNT=$(aws sts get-caller-identity --query 'Account'&nbsp;--output text) export AWS_REGION=${AWS_REGION:=us-west-2} sed -e "s/&lt;ACCOUNT_NUMBER&gt;/$AWS_ACCOUNT/g"&nbsp;\ &nbsp;&nbsp;-e "s/&lt;REGION&gt;/$AWS_REGION/g"&nbsp;sample.env &gt; .env Python の仮想環境を作成して、Python のインストールと関連する pip パッケージをローカル環境から分離します。その後、必要なパッケージをインストールします。 # manually create a virtual environment: python3 -m venv .venv # activate your virtual environment: source .venv/bin/activate # install the required dependencies: python -m pip install -r ../../requirements.txt .env ファイル の各値を詳しく見てみましょう。 deploy_core_stack – VPC や Amazon ECS クラスターなどのコアインフラストラクチャを事前にプロビジョニングしていないため、コアインフラストラクチャとバックエンドサービスの両方をデプロイしました。そのため、この値を True に設定しています。 Essential Props – これには、AWS CDK スタックのデプロイ時に不可欠な要素である AWS アカウント ID&nbsp;と AWS リージョンが含まれます。 Core Stack Props – コアインフラストラクチャを構成するコンポーネントの名前を指定します。 Backend Service Props&nbsp;– コンテナイメージ URI、コンテナ名、コンテナポート、Amazon ECS タスクに割り当てられるリソース量など、バックエンドサービスの詳細情報を設定します。 ECS cluster Props と Service discovery Props&nbsp;– コアインフラストラクチャのプロビジョニング中にこれらの値は自動的に出力されるため、両方の prop 値をデフォルト設定のままにします。 初めて CDK を使用してインフラストラクチャを作成する場合は、CDK をブートストラップします。 cdk bootstrap aws://${AWS_ACCOUNT}/${AWS_REGION} バックエンドサービスのスタックをデプロイする前に、次の AWS CDK コマンドを使用してこのアプリケーションの AWS CDK スタックを調べてください。CoreInfraStack と BackendService という名前の 2 つのスタックが表示されます。 cdk ls 下記のコマンドを使用して AWS CDK スタックをデプロイします。 cdk deploy --all --require-approval never --outputs-file output.json Step 2:&nbsp;ロードバランサーとフロントエンドサービスをデプロイする フロントエンドサービスのテンプレートに移動します。このブループリントは、ウェブ向けの負荷分散された Amazon ECS サービスを作成します。 cd ../lb_service 再び、ご使用の環境に合わせて AWS アカウントと AWS リージョンの環境変数を設定します。AWS CDK テンプレートで使用する .env ファイル を生成します。フロントエンドサービスのデプロイ中に .env&nbsp;ファイル内の変数が取得されます。 export AWS_ACCOUNT=$(aws sts get-caller-identity --query 'Account'&nbsp;--output text) export AWS_REGION=us-west-2 sed -e "s/&lt;ACCOUNT_NUMBER&gt;/$AWS_ACCOUNT/g"&nbsp;\ &nbsp;&nbsp;-e "s/&lt;REGION&gt;/$AWS_REGION/g"&nbsp;sample.env &gt; .env ただし、バックエンドサービスをデプロイする場合とは異なり、一部の値は調整が必要です。まず、コアインフラストラクチャはすでにプロビジョニングされているため、その Amazon ECS クラスターをフロントエンドサービスに使用します。 deploy_core_stack の値を False に変更してください。次に、前のステップでプロビジョニングしたコアインフラストラクチャ情報を参照して、ECS タスク実行ロール ARN と名前空間の値を指定します。必要な情報は、バックエンドサービスのディレクトリ内の&nbsp; output.json &nbsp;ファイルから取得できます。 訳注：下記の {ECS_TASK_EXECUTION_ROLE_ARN} と {NAMESPACE_ARN} , {NAMESPACE_ID} &nbsp;を置き換えてください。 deploy_core_stack="False" # Essential Props account_number="${AWS_ACCOUNT}" aws_region="${AWS_REGION}" # Core Stack Props vpc_cidr="10.0.0.0/16" ecs_cluster_name="ecs-blueprint-infra" namespaces="default" enable_nat_gw="True" az_count="3" # Frontend Service Props backend_svc_endpoint="http://ecsdemo-backend.default.ecs-blueprint-infra.local:3000" container_image="public.ecr.aws/aws-containers/ecsdemo-frontend" container_name="ecsdemo-frontend" container_port="3000" task_cpu="256" task_memory="512" desired_count="3" service_name="ecsdemo-frontend" ## Enter the values below by referring to the backend_service/output.json # ECS cluster Props ecs_task_execution_role_arn="{ECS_TASK_EXECUTION_ROLE_ARN}" vpc_name="ecs-blueprint-infra-vpc" # Service discovery Props namespace_name="default.ecs-blueprint-infra.local" namespace_arn="{NAMESPACE_ARN}" namespace_id="{NAMESPACE_ID}" 下記のコマンドを使用して AWS CDK スタックをデプロイします。 cdk deploy FrontendService --require-approval never 2 つの ECS Blueprints&nbsp;テンプレートを使用して Amazon ECS クラスターを構築し、その上にフロントエンドサービスとバックエンドサービスをプロビジョニングしました。デプロイを確認するには、AWS CDK 出力情報の最後の部分に記載されているロードバランサーエンドポイントをウェブブラウザにコピーしてアクセスします。次のような画像が表示されます。 図 3. バックエンドとフロントエンドの CDK スタックをデプロイした結果 ECS Blueprints を好みに合わせてカスタマイズ 図 4. 1 つのワークロードディレクトリ内のファイル間の相関関係 ECS Blueprints が目的のワークロードに合わない可能性もあります。その場合は、ECS Blueprints&nbsp;をカスタマイズして、お客様のワークロードに合わせたテンプレートに簡単に変換できます。ブループリントテンプレートをカスタマイズするには、提供されている AWS CDK コードをより深く理解する必要があります。 前述のとおり、各 Amazon ECS ワークロードの設定ロジックは stack.py ファイルにあります。また、 stack_props.py ファイルに列挙されている変数は、 stack.py ファイル内の各リソースを設定する際のパラメータとして使用されます。つまり、このファイルはスタックのプロパティを定義するために使用されるインターフェースです。さらに、お客様はこれらのプロパティの値を .env ファイルで指定できます。そのため、お客様は必要なパラメータを変数に変換することで、1 つのテンプレートからパラメータの異なる複数のサービスを生成できます。たとえば、お客様が Amazon ECS サービスの自動スケーリングの設定にタスクの最大値と最小値を直接指定したい場合、それらを環境変数および状態変数として stack_props.py ファイルに抽出できます。最後のステップとして、これらの値を stack.py ファイルの環境変数に置き換えます。 加えて、各 Amazon ECS ワークロードシナリオはそれぞれ異なるディレクトリに配置され、独自のデプロイライフサイクルを有しています。お客様は、既存のディレクトリ構造を使用して、Amazon ECS ワークロードのロジックを含む ECS Blueprints テンプレートを簡単に作成できます。任意でお客様がテンプレートのロジックに少し変更を加えることで、同じ目標を達成できます。 クリーンアップ AWS CloudFormation コンソールか、フロントエンドサービスのテンプレートの場所で AWS CDK コマンドを使用することでスタックを削除できます。 cdk destroy フロントエンドサービスを削除したら、バックエンドサービスのテンプレートに移動し、AWS CDK コマンドをもう一度使用してください。これで、バックエンドサービスとコアインフラストラクチャが削除されます。 cd ../backend_service cdk destroy --all --force まとめ この投稿では、ECS Blueprints とは何か、そしてどのように使用するか、どのようにカスタマイズできるかを紹介しました。ECS Blueprints をお客様のワークロードに使用する方法を学んだばかりなので、今すぐ ECS Blueprints を始められます！ECS Blueprints の詳細については、 ECS Blueprints ワークショップ と 公式 GitHub リポジトリ をご覧ください。ECS Blueprints は無料で使用でき、お支払いいただくのはデプロイしたリソースの分だけです。 ECS Blueprints は、一般的な Amazon ECS ワークロードシナリオをカバーすることを目的としています。そのため、ECS Blueprints をどのように発展できるかについてのフィードバックをお待ちしています。フィードバックにご興味がおありでしたら、ECS Blueprints リポジトリへ&nbsp; GitHub Issue をオープン してください。 本記事は&nbsp; Accelerate Amazon ECS-based workloads with ECS Blueprints &nbsp;(2023 年 7 月 24 日公開) を翻訳したものです。翻訳は、ソリューションアーキテクトの吉田が担当しました。

この記事は 「 AWS Lambda for the containers developer 」（記事公開日： 2023 年 5 月 9 日）の翻訳記事です。 はじめに AWS 上でアプリケーションを構築する際、お客様が直面する一般的な決定事項の 1 つは、 AWS Lambda で構築するのか、あるいは Amazon Elastic Container Service ( Amazon ECS ) や Amazon Elastic Kubernetes Service ( Amazon EKS ) といったようなコンテナサービスで構築するのかということがあります。 この決定を下すには、コスト、スケーリング特性、開発者がハードウェアオプションをどの程度制御できるかなど、考慮すべき多くの要素があります。ファンクションモデルもサービスベースのモデルも、客観的にどちらが優れているということはありません。むしろ、アプリケーションや基盤となるプロダクトとの相性の問題です。しかし、この選択でわかりにくい側面の 1 つは、プログラミングモデルが AWS Lambda の関数中心のパラダイムと、Amazon ECS や Amazon EKS の従来のサービスベースのパラダイムとの違いです。 AWS Lambda と Amazon ECS または Amazon EKS のプログラミングモデルの違いについては、よく議論されます。しかし、プログラミングモデルとはどういう意味でしょうか？ プロダクトのプログラミングモデルには 2 つの側面があります。1 つ目は、呼び出し側がアプリケーションに対してリクエストを出す方法です。もう 1 つは、アプリケーション内のコードがサービスからリクエストを受け取り、対応するレスポンスを返す方法です。この記事では、前者について説明しますが、後者にも焦点を当てます。AWS Lambda アプリケーションの内部を確認し、AWS Lambda で実行されているアプリケーションが AWS Lambda サービスと相互作用してリクエストを受け取り、それにレスポンスする内部の仕組みを理解することを目指しています。 この記事の目的は 2 つあります。まず、AWS Lambda のプログラミングモデルを紐解き、「 Lambda マジック」が実際にはアプリケーションとサービスの間の単純なやりとりであることを示します。次に、従来のコンテナのバックグラウンドを持つユーザーにとって、AWS Lambda もそれほど変わらないことを示します。すべてのコンピュートプロダクトは、アプリケーションコードとサービスの間で何らかのやりとりをします。コンピュートプロダクト間でアプリケーションを移動させることは、実際には、プロダクトのプログラミングモデルに準拠するようにアプリケーションを（できれば小さく）変更することです。 ウォークスルー それでは、始めましょう！ ご存知のとおり、AWS Lambda はサーバー上で実行されます、また、ZIP パッケージまたは Open Container Initiative ( OCI ) パッケージのいずれかでアプリケーションコードを設定します。ZIP パッケージを使用して同じことを行うこともできますが (これについては最後に詳しく説明します)、この記事ではコンテナイメージを使用して AWS Lambda を設定します。ワークロードに関しては、最もシンプルなプログラミング言語の 1 つである bash スクリプトを使用してビルドします。コンテナで実行されているコードと AWS Lambda サービスのプログラミングモデルとの相互作用を実証するために、これらのサーバーにできるだけ近づきたいと考えています。 まず、次の簡単な Dockerfile を使用します。 FROM public.ecr.aws/amazonlinux/amazonlinux:2023 RUN yum install -y jq tar gzip git unzip RUN curl -Ls "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" \ &amp;&amp; unzip awscliv2.zip \ &amp;&amp; ./aws/install ADD startup.sh /startup.sh ADD businesscode.sh /businesscode.sh ENTRYPOINT /startup.sh AWS Lambda を難解なものだと思ったことがあるなら、もう一度考えてみてください。これは標準の Dockerfile で、Amazon Linux 2023 イメージを指定した FROM で開始し、そこに一連のツール （ AWS Command Line Interface [ AWS CLI ]、tar、git など）をインストールします。AWS Lambda は、ラップトップ（または AWS Fargate ）で実行できるのと同じように、このコンテナイメージと startup.sh スクリプトを実行します。 AWS Lambda 上でコンテナを特別なものにする 3 つの側面があります。 コンテナの制約 コンテナを起動するもの startup.sh スクリプト （および businesscode.sh スクリプト）で実行する内容 これらを個別にみていきましょう。 コンテナの制約 コンテナが動くマシンまたは仮想マシンによって制約が決まります。ラップトップでコンテナを起動しても、自由に使える Graphics Processing Unit（GPU）はないでしょう。AWS Fargate を使用してコンテナを起動すると、特権を持つコンテナを実行できません。すべての実行環境には制約があります。 AWS Lambda 実行環境にも独自の制約があります。 実行期間は（意図的に）制限されています サイズはメモリパラメータで設定され、CPU容量は比例して割り当てられます コンテナは読み取り専用のルートファイルシステムで実行されます（ /tmp は書き込み可能な唯一のパスです） 特権を持つコンテナは実行できません コンテナで GPU は使用できません これらの制約の多くは、従来のコンテナ管理サービスやローカル実行に共通しています。実行期間の制約と読み取り専用ファイルシステムの制約は、この記事で最も関連性が高くなっており、また後で説明します。 コンテナを起動するもの このセクションでは、サービスのプログラミングモデルの最初の側面、つまり呼び出し側がアプリケーションを呼び出す方法について説明します。すべての環境には、コンテナの起動をオーケストレーションする独自の方法があります。ラップトップでコンテナを起動したい場合は、おそらく docker run か finch run を使用するでしょう。AWS Fargate でコンテナを起動したい場合は、おそらく runTask や createService などの Amazon ECS API を使用するでしょう。AWS Lambda でコアとなるのはイベント駆動型システムであり、すべて（上記のコンテナの起動を含む）はイベントによって行われます。AWS Lambda は、さまざまな AWS サービスの何百もの異なるイベントをサポートしています。典型的なイベントは、非同期アプリケーションの一部である Amazon SQS キュー内のメッセージです。ただし、イベントは、インタラクティブなウェブアプリケーションの一部としての AWS API Gateway （または AWS Elastic Load Balancing ） HTTP 呼び出しでもかまいません。いずれにせよ、イベントは AWS Lambda で処理できるようになります (このメカニズムについては後で詳しく説明します）。1 つの AWS Lambda コンテナは、一度に最大で 1 つのイベントを処理します。ただし、コンテナの存続期間中は多数のイベントを順番に処理する場合があります。 AWS Lambda のコンテナのオーケストレーションは、受信イベントに応答して大まかに次のフローに従います。 コンテナの初期化がされており、イベント実行するためにアイドル状態のコンテナがある場合、AWS Lambda はそのコンテナにイベントを割り当て、そのコンテナ上で実行します。 コンテナの初期化がされておらず、イベント実行するためのアイドル状態のコンテナがない場合、AWS Lambda は新しいコンテナを起動します。 AWS Lambda は、将来のイベントで新しいコンテナを起動する必要がないように、このコンテナを 1 回の実行で停止せずに、長くキープすることを選択するかもしれません。 複数のイベントが同時に発生した場合、AWS Lambda は、設定された関数またはアカウントの同時実行数とバースト制限まで、それぞれコンテナを並行して起動します。 startup.sh スクリプトで実行する内容 これまで、AWS Lambda コンテナの実行環境 （制約） と、この実行環境のライフサイクル （オーケストレーション） について説明してきました。次に、コンテナ内で実行されているコードが実際に何をするか （プログラミングモデル）について考えてみましょう。 皆さんは Lambda runtime APIs について聞いたことがあるかもしれません。これらの API について考える最も簡単な方法は、イベントを取得してイベントにレスポンスする方法をアプリケーションに提供するというものです。コンテナは、処理するイベントがあるかどうかを繰り返しチェックし、存在する場合は何らかを実行して、その作業の結果を AWS Lambda に通知する、長時間実行されるプロセスと考えてください。 この高レベルのメンタルモデルを念頭に置いて、上記のフローを実装する startup.sh スクリプトを作成します。この例でのビジネスニーズは AWS Lambda が Hugo で作成したウェブサイトの GitHub リポジトリをクローンし、それを JavaScript アーティファクトのセットに組み込み、その結果を Amazon Simple Storage Service ( Amazon S3 ) バケットにコピーすることです。整理しやすいように、ビジネスロジックは businesscode.sh というスクリプトに取り込んでいます。startup.sh スクリプトは businesscode.sh を呼び出し、AWS Lambda プログラミングモデルとビジネスロジックの間の架け橋として機能します。ビジネスロジックは AWS Lambda について何も知る必要はありません。 重要: このユースケース自体は重要ではありません。実際のコマンドやその機能よりも、フローとコードの実行方法に注目してください。 startup.sh は次のとおりです。 #!/bin/sh set -euo pipefail ############################################################### # The container initializes before processing the invocations # ############################################################### echo Installing the latest version of Hugo... cd /tmp export LATESTHUGOBINARYURL=$(curl -s https://api.github.com/repos/gohugoio/hugo/releases/latest | jq -r '.assets[].browser_download_url' | grep Linux-64bit.tar.gz | grep extended) export LATESTHUGOBINARYARTIFACT=${LATESTHUGOBINARYURL##*/} curl -LO $LATESTHUGOBINARYURL tar -zxvf $LATESTHUGOBINARYARTIFACT ./hugo version ############################################### # Processing the invocations in the container # ############################################### while true do # Create a temporary file HEADERS="$(mktemp)" # Get an event. The HTTP request will block until one is received EVENT_DATA=$(curl -sS -LD "$HEADERS" -X GET "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next") # Extract request ID by scraping response headers received above REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2) ############################ # Run my arbitrary program # ############################ /businesscode.sh ############################ # Send the response curl -X POST "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d '{"statusCode": 200}' done businesscode.sh は次のとおりです。 #!/bin/sh set -euo pipefail rm -rf hugo-sample-site git clone https://github.com/${AWS_LAMBDA_FOR_THE_CONTAINERS_DEVELOPER_BLOG_GITHUB_USERNAME}/aws-lambda-for-the-containers-developer-blog cd aws-lambda-for-the-containers-developer-blog/hugo_web_site /tmp/hugo aws s3 cp ./public/ s3://${AWS_LAMBDA_FOR_THE_CONTAINERS_DEVELOPER_BLOG_BUCKET}/ --recursive startup.sh スクリプトは、コンテナの起動時にのみ実行されるセクションから始まります。スクリプトのこの部分 (init) が、AWS Lambda コンテナのコールドスタートを決定します。この例では、実行時に Hugo バイナリの最新バージョンをダウンロードします。このバイナリのセットアップを前述の Dockerfile に追加することもできますが、それではファイルの最新バージョンが必要になるたびにイメージを再構築する必要があります。ここでは、AWS Lambda がコンテナを起動するたびに初期化コードを実行するという利点を生かして、最新バージョンの Hugo を動的に導入しています。特定のユースケースによって、コードの一部を Dockerfile に配置するか、初期化フェーズ、またはビジネスロジックに含めるかが決まります。 /tmp フォルダーは Lambda コンテナ内の唯一の書き込み可能なフォルダーであるため、このフォルダー内で操作する必要があることに注意してください。このため、Dockerfile でいくつかのツールをインストールする方が簡単でした。 スクリプトの次のセクション（「Processing the invocations in the container」ラベル）では、コードが無限ループに入り、コンテナが存続している間、続きます。このコードは、処理するイベントがあるかどうかを常に（ローカルの AWS Lambda runtime API endpoint に対して curl を使用して）チェックします。そして、これこそが AWS Lambda のマジックです。各実行環境内でランタイム API エンドポイントを公開し、管理します。ポーリングされたエンドポイントの受信時にイベントを返し、待機中のイベントがない場合、AWS Lambda はイベントが到着するまで実行環境を一時停止します。各イベントを受信すると、コードはそのイベントを取得し、そのイベントでスクリプトの次の部分（「 Run my arbitrary program 」ラベル）を実行し続けます。これはスクリプトの AWS Lambda に依存しない部分であり、ここでビジネスロジック（businesscode.sh スクリプト）を実行します。この部分は AWS Lambda 実行タイムアウト（最大 15 分まで設定可能）の影響を受けます。つまり、「 Run my arbitrary program 」セクションの一部として実行されるコードは、設定されたタイムアウトを超えて実行することはできません。 ビジネスロジックが完了すると、スクリプトは HTTP POST を介して同じエンドポイントにメッセージを返し、イベント処理が完了したことを AWS Lambda サービスに通知します。コードが何かを返していれば、AWS Lambda は何を返しているかは気にしないことに注意してください。このスクリプトでは {“statusCode”: 200} を返します。これは、API ゲートウェイを使用してこの関数をトリガーしており、 API Gateway はそのコードが返されることを期待している ためです。代わりに 「hey I am done」 のようなテキストを返すこともできますし、AWS Lambda はそれで問題ありませんでした（ API Gateway ほどではありません）。 コンテナの存続期間を AWS Lambda タイムアウトと混同しないでください。前者は、コンテナが起動後もループを実行し続ける時間を定義します。この存続期間は AWS Lambda の「契約」には含まれていないため、開発者はコンテナがシャットダウンされるまでの存続するのか想定すべきではありません。AWS Lambda タイムアウトは確かに契約の一部であり、この記事の執筆時点（ 2023 年 5 月 9 日時点）では最大 15 分まで設定可能です。 ランタイム API からイベントを受信したときに、コンテナのコードがそのレスポンスをポストするまでに設定されたタイムアウトよりも長くかかった場合、リクエストはタイムアウトとして呼び出し元に返され、コンテナは再起動されます。 このスクリプトで注目すべきもう 1 つの点は、実際のイベント情報を格納するイベントのペイロードを無視していることです。つまり、関心があるのはイベントトリガーだけで、トリガーがもたらすものには関心がありません。 HEADERS を解析し、リクエスト ID を抽出し、ループの最後でそのリクエスト ID をイベントを処理した AWS Lambda サービスに通知します。より古典的なイベント駆動型アーキテクチャでは、ペイロードを解析し、それを使用してビジネスロジックがリクエストに対して何をするかを制御していたでしょう。 この図は、上記のコードのセクションを視覚的に表現したものです。 これまでの内容をまとめましょう 次は、この AWS Lambda をデプロイおよび実行したときに内部で何が起こるかを大まかに説明します。 上記の Dockerfile からコンテナイメージを構築し、そのイメージを使用して AWS Lambda 関数を作成します。次に、この AWS Lambda に API Gateway エンドポイントと Amazon SQS キューの 2 つのトリガーを設定します。この段階では、何も実行されておらず、コンテナも起動されていません。 では、ターミナルからのリクエスト (curl &lt;api gateway endpoint&gt;) で API Gateway エンドポイントにアクセスしましょう。API Gateway はその HTTP リクエストを AWS Lambda イベントに変換し、イベントに応答してコンテナを起動します。コンテナは初期化フェーズ（この例では Hugo バイナリを取得） を経ます。次に、イベントループに入り、AWS Lambda が保持しているイベントを取得し、コンテナが空くのを待ちます。コンテナは数秒かけてリポジトリをクローンし、サイトを構築し、そのコンテンツを Amazon S3 にコピーします。完了すると、コンテナは HTTP POST を介してコードの実行が終了したことを AWS Lambda ランタイムに通知します。AWS Lambda は API Gateway に同期的に通知し、ターミナルにはプロンプトが返されます（スクリプト内の HTTP POST のメッセージでは本文を返さないため、レスポンスはありません）。 このユースケースでは、Lambda を何かしらのビルドシステムとして使用しているため、このプロセスには約 30 秒かかることに注意してください。これは、従来の同期リクエスト / レスポンスのパターンでの AWS Lambda の使用方法とは異なる場合があります。もしそうなら、「ビジネスロジック」はおそらくもっと無駄になるでしょう。ミリ秒単位でレスポンスするウェブサービスを考えてみてください。繰り返しになりますが、このユースケースは、Lambda の仕組みの内部で何が起こるかを説明するためにのみ使用します。 この時点で、コンテナは次のイベントのためにランタイム API にコールバックし、ランタイムのレスポンスを待っています。これで、コンテナは別のイベントが発生するまで一時停止され、その間は料金を支払う必要はありません。ここでメッセージをキューに送信すると、AWS Lambda はアクティブでアイドル状態の実行環境があることを認識し、コンテナの一時停止を解除してイベントをそのコンテナにルーティングします。コンテナは、ランタイム API の呼び出しに対するレスポンスとしてイベントを受け取り、ビジネスロジックを実行して結果を返すという同じプロセスを経ます。 この場合、イベントのペイロードは API Gateway によって生成されたイベントとは異なりますが、このユースケースでは、コンテナに渡されたイベントを読み取ることすらしないため、気にしません。トリガーだけを気にし、イベントのコンテンツそのものは気にしません。 しばらくして、リクエストが受信されなくなると、AWS Lambda は上記のコンテナをシャットダウンし、関数の裏で実行されているコンテナはなくなります。この時点で、API Gateway エンドポイントに 100 件の同時リクエストを送信します。AWS Lambda は 100 個のリクエストを受信し、100 個のコンテナを同時起動し、それらのリクエストを処理します (つまり、すべて初期化を行います「コールドスタート」)。リクエストが処理され、サイトが 100 回構築およびコピーされると、100 個のコンテナは不特定の期間で実行され続け、実行中のループを介してより多くのイベントを取得できるようになります（ AWS Lambda が再び停止することを決定するまで）。 Lambda の外部でのコンテナイメージの実行 これを読んでいる方なら、この記事で使用してきた Dockerfile が実際に見られる従来の Dockerfile と何ら変わりないことにお気づきかもしれません。最大の特徴は、startup.sh スクリプトがコンテナを初期化する方法と、AWS Lambda API とのやり取りにあります （ループ内でのイベント取得と結果送信の両方）。この部分は、AWS Lambda プログラミングモデルの非常に特有なものです。とは言うものの、ビジネスロジック (businesscode.sh) がプログラミングモデル (startup.sh) から分離されるようにこれらのスクリプトを作成しました。このため、AWS Lambda の仕様をバイパスしてビジネスロジックを直接起動することで、同じコンテナイメージを使用して別の場所で実行するのが簡単になります。これを実現する簡単な方法は、次の Docker コマンドを使用してローカルで実行することです。 docker run -v /tmp:/tmp --rm --entrypoint /businesscode.sh &lt;container_image:tag&gt; エントリーポイントを微調整して businesscode.sh スクリプトを指定するだけで済みました。 勘のいい方であれば、ローカルフォルダをコンテナの /tmp フォルダにマッピングしていることに気づき、なぜなのか疑問に思っているかもしれません。初期化フェーズをバイパスしたため、コンテナイメージは起動時に Hugo バイナリをインストールしません。代わりに、ラップトップの /tmp にある既存のバイナリから動的に渡しています。実際のシナリオでは、Hugo バイナリをコンテナイメージにビルドするか、ダウンロードコードを startup.sh から分割して AWS Lambda コンテキスト外で実行できるようにすることができます。繰り返しますが、この例はデモンストレーションを目的としており、実際の世界への適用するかどうかはユースケースによって異なります。 ちょっと待ってください。これは私たちが知っていて愛用している AWS Lambda ではありません！ その通りです。約束どおり、今回は実行モデルとプログラミングモデルを組み合わせた AWS Lambda の低レベルの仕組みを紹介するツアーでした。AWS Lambda を知っている、またはすでに使用したことがある場合は、これらの詳細からは抽象化されているかと思います。興味深いのは、AWS Lambda がリリース時にこれらの抽象化の最高峰からスタートし、このブログ記事で説明したことを完全に可視化するための徐々にサポートを導入した経緯です。ここで説明した内容を、皆さんが知っていたり聞いたりする高レベルの抽象化とどのように一致させるのでしょうか。 この記事で説明した内容から、ご存知の AWS Lambda まで発展させていきましょう。 ほとんどの開発者は、ビジネスコードを書いている間、ループや HTTP の GET や POST を扱うことを望んでいません。ここで、Lambda でよく見かける抽象化や規則、つまり AWS Lambda Runtime Interface Client (RIC) の出番です。RIC はイベントをインターセプトするループを実装するユーティリティ（バイナリまたはライブラリ）で、特定のプログラミング言語向けに AWS が提供しています。これらのイベントをコードに渡す方法は、プログラム関数に渡されるオブジェクトを介して行われます。RIC は上記の HEADERS と BODY を取得します。イベントの内容と実行環境のコンテキストを解析し、それらをオブジェクトとして関数に渡します。つまり、コンテナは RIC をメインプログラムとして起動し、イベントごとに RIC はイベント情報を使って関数を呼び出します。この規則に従うと、開発者はエンドポイントを呼び出したり、HEADERS や BODY を解析したりしなくても、関数内で直接イベントを検索できます。 RIC が実装するロジックの一部である bash スクリプト（startup.sh）を効果的に組み込んでいます。この例では「関数」の規則を真似したくないことに注意してください。なぜなら、「これは bash で RIC を再実装する方法です」という側面よりも、「これは何らかの特徴を持つ通常のコンテナです」という側面を増やしたかったからです。これについては、 Lambda ドキュメントにあるチュートリアル （この記事のきっかけとなった） がまさにそのためのもので 、メインスクリプトにインポートする bash 関数を構築する方法を示しています！ AWS Lambda は Function as a Service (FaaS) ですが、AWS Lambda のコンテキストにおける関数の概念全体は、開発者がすっきりと使えるように抽象化したコンテナ内の ループと 2 つの curl 操作の上に構築した規約にすぎません。 RIC の話題に戻りますが、独自のコンテナイメージを構築したい場合は RIC スタンドアロン （選択された言語用）と、構築に使用できる AWS Lambda マネージドのベースイメージ （RIC などを含む）の両方を用意しています。何を選択するかにかかわらず、コンテナイメージを使用するときは、そのメンテナンスを行う必要があります。つまり、ファンクション用の最新のイメージをデプロイする必要があります。 別のメカニズムとして、より高いレベルの抽象化は、カスタムランタイムとビジネスロジックを ZIP ファイルとしてパッケージ化し、関数が実行されるオペレーティングシステムを AWS に管理させることです。 究極の抽象化とマネージドエクスペリエンスを実現するには、ビジネスロジックのみを ZIP ファイルとしてパッケージ化し、お客様に代わって AWS にランタイム全体の整理と管理を任せることができます。前に説明したように、これが AWS Lambda のスタート地点であり、スタックの柔軟性と制御性を高めるためには長いプロセスがありました。レイヤーのサポートを追加し始め、最終的にはコンテナイメージのサポートを追加しました。 長年にわたって、Lambda コミュニティは上記の Lambda プログラミングモデルをさらに抽象化してきました。そのような抽象化の 1 つが、顧客が従来のウェブアプリケーション Lambda を実行できるようにする Lambda Web Adapter です。この Web Adapter は、Lambda プログラミングモデルと、ポートでリッスンする従来のウェブアプリケーションフレームワークとの間のインターフェースとなるカスタムランタイムと捉えることができます。このモデルを使用することで、Lambda のイベント駆動型の性質が抽象化され、インフラストラクチャがプログラミングモデルから事実上切り離されます。 このプロトタイプをご自身でテストしてみてください 実際に試したいと思われる好奇心旺盛な人のために、このプロトタイプを再作成するのに必要なすべてのコードとセットアップ手順を含む GitHub リポジトリを作成しました。自分で試したい場合は、 このリンク にアクセスしてください。 まとめ この記事では、AWS Lambda をいつもとは異なる観点から説明しました。これまで使用した具体的な例とユースケースは従来のものではなく、実際の AWS Lambda シナリオに対応していない可能性もありますが、この記事が、お客様がサービスの内部動作について理解を深めるのに役立つことを願っています。また、AWS Lambda と従来のコンテナシステムの違いをさらに明確にしていただければ幸いです。違いを理解すると、最初に感じていたほど風変わりなものではありません。 翻訳はソリューションアーキテクトの多田が担当しました。原文は こちら です。

この投稿は、「 Application integration in utility smart metering using AWS 」を翻訳したものです。 はじめに 配電事業者は、情報および運用技術（IT/OT）アプリケーションを実装して、配電の商業活動と送配電網の運用・管理を行なっています。これらの IT/OT アプリケーションには、請求、カスタマーケア、スマートメータリング、高度配電管理システム（ADMS）、監視制御およびデータ収集（SCADA）、および停電管理システム（OMS）が含まれます。停電の特定と復旧、請求精算、顧客の加入・解約、メーターの交換、配電提供地域の需要予測などのビジネスプロセスを問題なく実行するには、電力会社はこれらのアプリケーション間でデータを統合する必要があります。その中でも、スマートメータリングシステムは、これらのプロセスに欠かせない主要なデータソースとなります。電力会社は、本格的なエンタープライズサービスバスを導入する代わりに、クラウドベースの統合サービスを活用できるようになりました。 このブログ記事では、スマートメーターシステムに関連するアプリケーション統合のユースケースとスマートメーターシステム（Advanced Metering Infrastructure、または単に AMI とも言います）とユーティリティ系のシステムを統合する場合に使用できる AWS サービスの概要を説明します。 このブログの想定読者は、従来のスマートメータリングソリューション (AMI 1.0) を導入していて、今後の選択肢のひとつとして AWS のクラウド基盤上で動作するスマートメータリングソリューションを検討、評価している配電事業者、または AWS にすでにシステムを実装しており、他のユーティリティシステムとの統合ポイントを拡張中の配電事業者を主として想定しています。さらにこの記事では、AWS のサーバーレスサービスと IoT サービスを活用する AMI 2.0 次世代スマートメータリングシステムに使用できるアーキテクチャについても説明します。 統合対象となるユーティリティのメータリング関連アプリケーション スマートメータリングの導入と管理を成功させるには、電力会社はメーターデバイス本体、メーターデータ収集ネットワーク、ヘッドエンドシステム（HES）を含むスマートメータリングの中核となる「エコシステム」を実装する必要があります。また、いくつかの既存のユーティリティアプリケーションと統合する必要があります。 Meter-to-Cash (検針から入金まで）プロセスの主な統合: メーターデータ管理システム（MDMS）— スマートメーターデータを処理できる既存のシステムでも、スマートメータリングエコシステムの一部としてインストールされた新しいシステムでもかまいません 託送収益管理（検針、請求、集金、接続管理）と顧客関係管理（CRM）を担う請求およびカスタマーケアシステム（託送CIS/CRM） その他のコア AMI システムとは異なるタイプの HES（実装されている場合） その他の統合対象: スマートメーターの大量導入と継続的なメンテナンスを管理するための作業指示（ワークオーダー）管理と現地作業従業員（モバイルフィールドフォース）管理アプリケーション 位置情報システム（ GIS ） ビジネスインテリジェンス（ BI ）ダッシュボード レガシー AMI 導入のメータリング関連の統合ユースケース スマートメータリングとユーティリティアプリケーションの統合に必要な AWS サービスを特定するには、以下のユースケースを参考にしてください。ユースケースは他にもあるかもしれませんが、最も一般的で適用可能な統合方法についての知見を得るには、まずはこれらで十分と考えます。 メーターデータ統合の主な利用例： 定期請求処理のための日次メーターデータ： MDMS との統合の主な使用例としては、スマートメーターの計量値を使用して消費者に請求するための「請求およびカスタマーケアシステム」との統合があげられます。MDMS は、消費者の請求日の設定に基づいて、該当日に請求が予定されているすべての消費者に対する API リクエストを送信します。MDMS は、リクエストを受けたすべての消費者に対する当該請求額決定の構成要素を請求およびカスタマーケアシステムに連携します。 請求およびカスタマーケアシステムは、Amazon API Gateway で設定された REST API の API リクエストを送信します。リクエストには、請求決定要素に紐づく消費者固有の識別番号またはメーター番号が含まれます（消費者は、毎月または隔月のサイクルに従って特定の日に請求されるものとします）。 Amazon API Gateway の API は、インテグレーションタイプが HTTP で MDMS API のエンドポイントとして設定されます。Amazon API Gateway には API のスロットリングレートを設定することもできます。これにより、請求およびカスタマーケアシステムから MDMS に送信される API リクエストの負荷をAmazon API Gateway で調整できます。 請求およびカスタマーケアからリクエストされた消費者リストから、MDMS は MDMS データベースから請求料金計算に必要な要素を抽出し、Amazon API Gateway に設定された API Gateway への API コールとして連携されます。Amazon API Gateway の API は、インテグレーションタイプが HTTP、エンドポイントが請求およびカスタマーケアシステム API として連携されます。MDMS は、Amazon API Gateway を介して請求料金計算に必要な要素を複数のバッチで請求およびカスタマーケアシステムに送信します。請求決定要素が複数のバッチで送信される理由は2つあります。(1) MDMSと請求およびカスタマーケアシステムへの負荷を最適化するために多数の消費者分を複数のバッチに分割すること、(2) MDMS データベースに最新の計量値がない場合、欠測している計量値は再試行によってMDMSによって取得され、この再試行により受信した計量値は請求およびカスタマーケアシステムに複数のバッチとして送信されます。 別の連携手法として、請求バッチ処理のユースケースの統合は、セキュアファイル転送プロトコル（SFTP）を介して交換されるファイルを介して行われることもあります。 SFTP を使用する AWS Transfer Family は、セキュリティポリシーに従って MDMS 用のユーザー認証情報を使用してサーバーを作成するように設定できます。MDMS は、SFTP を使用して AWS Transfer Family の指定されたディレクトリに、あらかじめ定義された命名規則に従って複数のファイル (各ファイルには複数のメーターの請求要素を含む) を送信できます。送信したファイルは Amazon Simple Storage Service (Amazon S3) または Amazon Elastic File System (Amazon EFS) に保存できます。請求システムは、指定された場所からファイルを読み取り、その読み取りを処理して請求を行うことができます。 図１：メーターデータの代表的な利用例。オンプレミスとAWSのハイブリッドシナリオが示されていますが、すべてのシステムをAWSベースにすることも可能 メーターデータからデータレイクへ： キロワット（KW）、キロボルトアンペアリアクティブ（KVAR：キロバール）、電圧などのさまざまなタイプの計量値と同様に、複数のパラメータ、イベント/アラームを含んだメーターデータを分析すると、電力会社が顧客と電力網の両方の運用に関して洞察を得るのに役立ちます。このメーターデータは、さまざまな種類の計量をさまざまな頻度で収集し、数か月または数年にわたって蓄積すると、ペタバイト単位のデータになります。このデータを効率的に分析するために、電力会社はこれらのデータをデータレイクに蓄積します。データレイクでは、機械学習のユースケースを含む高度な分析を迅速に実行できます。 詳細については、 Meter Data Analytics （MDA）に関するブログと、MDA ソリューションの迅速な構築と導入に役立つ MDA Reference Architecture と Quick Start を参照してください。 メーターデータ統合のその他の使用事例 オフサイクルトランザクションのオンデマンド計量： 新しい場所への転居などのオフサイクルトランザクションに対しては、請求およびカスタマーケアシステムはその処理をオンデマンド計量で対応します。消費者の入居済み申請が請求およびカスタマーケアシステムに記録されると、請求およびカスタマーケアシステムから MDMS に API リクエストが送信され、MDMS から HES へのAPIリクエストが開始され、スマートメーターからの計量が行われます。処理の応答は再び HES から MDMS へと戻り、さらに請求およびカスタマーケアシステムに戻ります。 請求およびカスタマーケアシステムは、 Amazon API Gateway で設定された REST API の API リクエストを送信します。Amazon API Gateway は、開発者があらゆる規模で API を簡単に作成、公開、保守、監視、保護できるようにする完全マネージド型サービスです。 Amazon API Gateway では、API はインテグレーションタイプが HTTP、エンドポイントが MDMS API として設定されています。Amazon API Gateway には API のスロットリングレートを設定することもできます。これにより、請求およびカスタマーケアシステムから MDMS に送信される API リクエストの負荷を Amazon API Gateway で調整できます。 MDMS はリクエストを HES に送信してオンデマンド計量を要求し、HES からの応答は MDMS に送り返され、次に請求およびカスタマーケアシステムに送られます。 図2: その他のメーターデータ統合の使用事例。オンプレミスと AWS のハイブリッドシナリオが示されていますが、すべてのシステムを AWS ベースにすることも可能 停電および復旧アラーム： スマートメーターからの停電および復旧アラームは、電力会社による停電箇所特定プロセスに役立ちます。停電および復旧アラームは、スマートメーターによって HES に送信され、次に HES から MDMS に送信されます。MDMS はこれらを OMS（停電管理システム：Outage Management System） に送信し、OMS はアラームをグリッドレベルで停電と結び付けて、停電している消費者を特定します。 スマートメーターがメーター番号とアラーム日時とともに停電アラームを HES に送信すると、HES はこれを MDMS に送信します。HES と MDMS のアラームの統合方法は、アプリケーションによって異なります。 MDMS はこの停止アラームを Amazon Simple Queue Service (Amazon SQS) に送信できます。Amazon SQS は、何百万ものメッセージを処理できるサーバーレスのキューイングサービスであり、負荷を処理するために独自にスケールアップおよびスケールダウンできます。 OMS は Amazon SQS キューからメッセージを取得し、電気が失われている消費者を特定するなどの発生イベントに合わせてメッセージを処理します。 上記ユースケースに記載されている統合方法は一例ですが、実際の統合方法は設計段階で最終決定します。HES が複数あったり、請求システムとカスタマーケアシステムが連携する可能性もあるため、システム同士のポイントツーポイント（一対一）統合の代わりに統合レイヤアプローチという手法により統合にかかる労力を最小限に抑えることが重要です。特に統合レイヤが AWS のフルマネージド・サービスを採用している場合、運用とメンテナンスに必要な労力も削減できます。導入時には、複数の送信元システムと送信先システムでサポートできる共通のデータフォーマット（必須パラメータとオプションパラメータを含む）を定義することも重要です。統合アーキテクチャを定義する際に考慮すべきベストプラクティスには、次のようなものがあります。 疎結合サービス ：疎結合は、コンポーネントの動作をそれに依存する他のコンポーネントから分離するのに役立ち、回復性（レジリエンシ）と俊敏性を高めます。キューイングシステム、ストリーミングシステム、ワークフロー、ロードバランサーなどの統合サービスは疎結合であり、要件に基づいて実装することができます。これらの統合サービスをすべて必要とするアーキテクチャもあれば、これらのサービスを 1 つか 2 つ必要とするアーキテクチャもあります。設計方針として、例えば、この例のように実装時には2 つの統合サービスのみに限定することで、実装にかかる全体的な労力と時間を削減することが可能です。 イベント駆動型アーキテクチャ（Event-driven architecture） ：イベント駆動型アーキテクチャは、イベントを使用して分離されたサービスを起動し、サービス間の通信を行います。これは、マイクロサービスで構築されたモダンアプリケーションでは一般的なアーキテクチャです。イベント駆動型アーキテクチャでは、イベントのポーリング、フィルタリング、ルーティングを行うコードを記述する必要はありません。代わりに、これらはイベントルーターによって処理され、イベントを自動的にフィルタリングしてプッシュします。 AWS Well-Architected Framework は、クラウドベースの実装のベストプラクティスを網羅しており、お客様と AWS パートナーがアーキテクチャを評価し、時間の経過とともに拡張可能な設計を実装するための一貫したアプローチを提供します。 AMI 2.0 向けの AWS ベースのサービス アドバンスト・メータリング・インフラストラクチャ（AMI）またはスマート・メータリングは、エッジデバイス、クラウド、通信、業務における領域で技術の進歩とともに、過去 20 年間で進化してきました。 AMI 2.0 と呼ばれる次世代のスマートメータリングシステムは、これらの進歩をベースにしています。新しいスマートメータリングを導入する際、アーキテクチャ上で検討、決定すべき重要な事項は、(1) ソリューションは回復性があり、数百万のエンドポイントまで自動的に拡張可能であること、(2) メータリングソリューションの保守と運用のオーバーヘッドが最小限に抑えられること、(3) メータリングおよびエネルギー関連の複数のアプリケーションをエッジ (メーター内またはメーターデバイスの後段) で管理および実行できるソリューションであることです。これにより、スマートメータリングソリューションを実行するために必要なインフラストラクチャの管理にかかる運用上のオーバーヘッドが削減され、メータリングの信頼性が向上し、エッジでの付加価値のあるメータリングサービスの実現が可能になります。これは、AWS のサーバーレスサービスと IoT サービスを使用することで実現できます。たとえば、AWS のサーバーレスサービスは自動的にスケールアップおよびスケールダウンされ、顧客によるインフラストラクチャのプロビジョニングは不要です。一方、AWS IoT サービスでは、自動診断、セキュリティパッチ、無線によるソフトウェア配布などの機能により、メータリング群の管理が大幅に簡単になります。 次の図は、AMI 2.0 アプリケーションとアプリケーション統合をサポートできる AWS サービスの概要を示しています。これをさらに強化して、顧客固有の要件に基づく他のユースケースにも対応できます。 図 3: AMI 2.0 向けの AWS サービス スマートメーターは、メーターデータ (メーターの定期計量、深夜のメーター計量、アラーム、イベント) を MQTT、HTTPS、WSS 経由の MQTT、LoRaWAN 経由で AWS IoT Core に送信できます。 AWS IoT Greengrass をスマートメーター (またはコンセントレータ) 上で利用して、異常検出やその他のアプリケーションなどを動作させて、エッジデバイスにインテリジェンスをもたらすことができます。 スマートメーターによって送信されたメーターデータは、AWS IoT Core によって受信されます。AWS IoT Core はサーバーレスサービスで、負荷に応じて自動的にスケールアップとスケールダウンが可能で、耐障害性があります。 AWS IoT Device Defender は、AWS IoT Core に接続されたデバイスを監査および監視するためのセキュリティレイヤをもたらします。IoT デバイス群のクラウド構成を評価し、ルールベースおよび ML ベースの検出機能によってデバイスのアクティビティを継続的に監視し、監査違反または異常な動作が特定されるとアラームを発動し、ビルトインされた緩和アクションで問題に迅速に対処できるようにします。 データが AWS IoT Core で受信されると、ルールとアクションを定義してデータをさらに処理できます。ルールとアクションは、上記のアーキテクチャに示されているように 1 つ以上でもかまいません。このアーキテクチャでカバーされているユースケースは次のとおりです。 AWS IoT Core で受信したメッセージはすべて Amazon S3 バケットに送信され、保存され、分析とレポート用のデータレイクが構築されます。 受信したメーターデータがアラーム (停電、低電圧など) の場合、ルールを適用してメッセージを Amazon SQS に送信できます。 AWS IoT Core で受信したすべてのメッセージは AWS Lambda に送信されます AWS IoT Core で受信したすべてのメッセージは AWS Lambda 関数に送信され、この関数は必要に応じてデータ加工処理を実行し (KWh 指示値に乗率を適用するなど)、加工されたデータを Amazon DynamoDB に保存します。最新のメーターデータは Amazon DynamoDB に短期間保存されるため、その他のユーティリティアプリケーションがこの最新データに迅速にアクセスすることができます。Amazon DynamoDB は、あらゆる規模で高性能アプリケーションを実行できるように設計された、フルマネージド型のサーバーレスのキーバリュー型 NoSQL データベースです。Amazon DynamoDB には、組み込みセキュリティ、継続的バックアップ、自動マルチリージョンレプリケーション、インメモリキャッシュ、データエクスポートツールが備わっています。 スマートメーターの警告アラームを含む準リアルタイムのメッセージを Amazon SQS に送信できます。連携するアプリケーションが異なる場合があるため、アラームの種類ごとに異なるキューを定義する可能性があります。あるいは、連携するアプリケーションに基づいてメッセージキューを１つに統合することもできます。たとえば、OMS が使用するすべてのアラーム（停止/ Last Gasp、復旧、L1 障害、L2 障害など）をすべて１つのキューに送信できます。 AWS IoT Core で受信したすべてのメッセージは、オブジェクトの形式で Amazon S3 バケットに送信されます。メーターデータは、データのタイプに基づいて別々のバケットに保存できます。たとえば、あるバケットにはすべての定期計量値が、別のバケットにはすべての深夜計量値が保存されます。Amazon S3 は、分析を生成するためのソースとなるデータレイクの基盤となります。 Amazon Athena を使用してデータレイク内のデータをクエリできます。データレイクは Amazon QuickSight のダッシュボードのデータソースになります。このデータレイクは、将来、AI/ML を使用した高度な分析を実行するためにさらに使用することができます。 スマートメーターから受信して永続レイヤに保存されたデータは、外部アプリケーションがさまざまな目的で必要とします。このデータを外部アプリケーションに提供する方法の 1 つは、REST API を使用することです。REST API は Amazon API Gateway で利用できるようになります。Amazon API Gateway には、インテグレーションタイプとして AWS Lambda 関数が指定できます。AWS Lambda 関数は Amazon DynamoDB（および必要に応じて Amazon S3）から適切なデータセットを取得し、その応答を Amazon API Gateway に返してさらに処理します。 まとめ スマートメータリングのクラウドベースの実装を検討している配電事業者は、スマートメータリングソリューションと他のユーティリティシステム間のデータ連携に AWS Application Integration サービスを選択できます。AWS Application Integration サービスには、公益事業者がプロビジョニングや管理を行う必要がなく、負荷に応じて自動的にスケールアップやスケールダウンを行うサーバーレスサービスが含まれます。サーバーレスサービスには耐障害性が組み込まれているため、特にスマートメータリングに関連する重要なユースケースでは、統合サービスの実行に必要な信頼性レベルが得られます。サーバーレスサービスは使用量に基づいて請求され、アイドル状態のリソースについては請求されないため、多くの場合、配電事業者はコストを節約できます。 AMI 2.0 の観点から見ると、配電事業者は、AWS IoT、Amazon S3、Amazon Athena、Amazon QuickSight などのサービスを使用してスマートメータリングソリューションを開発、強化、実装する時間を短縮できるというメリットがあります。エッジレイヤとアップストリームレイヤの両方で、AWS IoT サービスで利用できるビルトインの統合機能により、開発とテストに必要な時間を大幅に短縮できます。 ルールが呼び出されたときに何をすべきかを指定する AWS IoT rule actions には、Amazon DynamoDB、AWS Lambda、Amazon SQS などの他の AWS サービスのほか、抽出、変換、ロードサービスである Amazon Kinesis Data Firehose 、フルマネージドのメッセージングサービスである Amazon Simple Notification Service (Amazon SNS)、膨大な量の IoT データに対して高度な分析の実施、運用を簡単にできる完全マネージド型サービスである AWS IoT Analytics といったその他の AWS サービスとの事前構築済みの統合が含まれています。これらのサービスは、ユースケースに基づいて設定できます。さらに、AWS のサービスによって、スマートメータリングデータセットの上に負荷予測や高度な ML などの新しいユースケースを俊敏に実装できます。エッジ面では、AWS IoT Greengrass の使用はデバイスメーカー（スマートメーターまたはコンセントレーターメーカー） にとっても検討に値します。これは、AWS IoT Greengrass では、クラウドで作成、トレーニング、最適化されたモデルを使用して、デバイス上でローカルで ML 推論を簡単に実行できるためです。 スマートメータリング統合に関する AWS サポートの詳細については、この re: Invent セッション を視聴するか、 AWS Power &amp; Utilities のウェブサイト をご覧ください。 本ブログは、ソリューションアーキテクトの丹羽が翻訳しました。原文は こちら です。 AWS for Energyについて詳細は こちら をご覧ください。 タグ: AMI , AWS AMI , AWS IoT , MDMS Integration , OMS integration , smart meters , utilities &nbsp; Sainath Bandhakavi Sainath Bandhakavi は、アマゾンウェブサービスインディアの電力・公益事業および持続可能性担当主任ソリューションアーキテクトです。電力、公益事業、サステナビリティ分野の顧客、新興企業、AWS パートナーと協力して、クラウドの力を利用して AWS で業界ソリューションを構築し、最新化できるよう支援しています。Sainath は、ソリューションアーキテクト、戦略およびプロセスコンサルタントなど、さまざまな役割でこれらの分野のお客様と20年以上働いてきました。彼の最近の業務は、スマートメータリング、公共料金の請求とカスタマーケア、スマートシティソリューション、高度分析などでした。 Greg Thompson Greg Thompson は、電力・ユーティリティ業界の AWS IoT ワールドワイドビジネス開発リーダーです。電力・ユーティリティ業界セグメント向けのグローバル AWS IoT 戦略の策定と、グローバルセールスチームおよびパートナーとの共働を担当しています。Greg は、AWS やシュナイダーエレクトリック (Schneider Electric) などの企業で 20 年以上にわたり、公益事業、データセンター、スマートビルディング、自動車、その他の業界向けの SaaS、IoT、エンタープライズソリューションを開発およびリードしてきました。 Joseph Beer Joseph (Joe) Beer は、電力・ユーティリティ業界の AWS ワールドワイド・テクノロジー・リーダーであり、AWS における再利用可能な IT、OT、カスタマエンゲージメント、データ、資産管理ソリューションアーキテクチャの開発を指導しています。Joe は、AWS クラウドがお客様のデジタルトランスフォーメーション戦略を実現し、ビジネス目標の達成にどのように役立つかについて、お客様やパートナーにアドバイスしています。Joe は業界のベテランであり、国内外の複数の業界にわたるIT管理、ソリューションアーキテクチャと提供、コンサルティングの分野で30年以上のリーダーシップ経験があります。Joe は、Puget Sound Energy から AWS に入社しました。Puget Sound Energy では CTO 兼チーフアーキテクトを務め、従来の IT と 制御機器に対する OT の両方の戦略、アーキテクチャ、設計業務の指揮を担当していました。

9 月 13 日 (水) に開催される参加料無料のオンラインイベントである AWS End User Computing Innovation Day 2023 にぜひご参加ください。AWS は、 LinkedIn Live 、 Twitter 、 YouTube 、 Twitch を含む複数のプラットフォームでこのイベントを同時にストリーミングします。 オフィスへの復帰義務、自社運営のデータセンターから脱却して移行することを求める圧力、増大するセキュリティ上の懸念、社内の IT 専門知識の不足、経費管理に関する絶え間ない注意などによって形作られた複雑な状況に適応することは、従業員が仕事をするために必要なツールを提供する責任を負う IT チームに多くの課題をもたらします。 AWS End User Computing Innovation Day 2023 は、まさにこれらの課題を詳しく分析することを目的とした 1 日間の無料仮想イベントです。この変革の時代を乗り切るために、 AWS End User Computing (EUC) サービスをどのように活用できるかを詳しく掘り下げていきますので、ぜひご参加ください。リモートおよびハイブリッドのワークフォースの当面および将来の要件をサポートするための、驚くほどアジャイルかつ安全な基盤を構築する方法をご覧ください。 このイベントでは、AWS のシニアリーダーから直接話を聞くことができます。このイベントで予定されているハイライトをいくつかご紹介します。 基調講演 – AWS の End User Computing 部門 General Manager である Muneer Mirza による基調講演セッションから始まります。Muneer は、俊敏性を最大化し、変化へのシームレスな適応を促進するための一連の戦略的アプローチを検討します。 ブラウザベースのワークロードセキュリティ – Amazon WorkSpaces Web の General Manager である Brett Taylor が、セキュリティおよびコンプライアンス体制を強化できるように、Amazon WorkSpaces Web を利用してウェブベースのアプリケーションを保護する方法について説明します。 イベントページ で登録すると、カレンダーにイベントリマインダーを追加できます。 当日お会いできるのを楽しみにしています。 – Irshad 原文は こちら です。

2023 年 8 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon CloudFront の レポート / モニタリング / ロギング編 Amazon CloudFront の レポート / モニタリング / ロギング編です。 Content Delivery Network (CDN) サービスである Amazon CloudFront の運用時に役に立つ レポート / モニタリング / ロギング機能をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 基本的な AWS サービスについて理解されている⽅ Amazon CloudFront の概要を理解されている方 Amazon CloudFront を現在運用中の方 Amazon CloudFront の監視やロギングの仕組みについてご興味のある方 本 BlackBelt で学習できること 本セミナーを受講することで、Amazon CloudFront のレポート / モニタリング / ロギング機能を利用し、様々な種類のデータやメトリクス、ログを確認できることを学習できます。 スピーカー 長谷川純也 ソリューションアーキテクト Virtual Andon on AWS カスタマイズ可能でスケーラブルなウェブインターフェイス Andon システムを提供し、製造現場での異常イベントをモニタリングすることができる AWS ソリューション・ Virtual Andon on AWS について、AWS Black Belt Online Seminar で解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 製造現場での異常イベントのモニタリングに取り組まれている方 Virtual Andon on AWS をこれからご利用予定の方 Virtual Andon on AWS をすでにご利用の方で、より理解を深めたい技術者の方 本 BlackBelt で学習できること 製造現場での異常イベントをクラウド上でモニタリングする方法やシステム構成を学習することができます。 スピーカー 山田航司 ソリューションアーキテクト Amazon Connect と Amazon Pinpoint による効果的なマルチチャネルコミュニケーション Amazon Connect と Amazon Pinpoint を活用する事でアウトバウンド業務が抱える様々な課題を解決しつつ、顧客との効果的なマルチチャネルコミュニケーションを実現する事が可能です。 本セッションでは、このようなマルチチャネルコミュニケーションを実装するための技術的なポイントを具体的な設定方法、実装方法を交えながら詳しくご説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect の基本的な知識や操作経験をお持ちの技術者 Amazon Pinpoint の基本的な知識や操作経験をお持ちの技術者 電話やメールなど複数のチャネルを使い効果的な顧客アプローチを検討されている方 すでに電話やメールなどでアウトバウンド業務を行なっており、効率的な運用を検討したい方 本 BlackBelt で学習できること Amazon Connect と Amazon Pinpoint の連携方法 アウトバウンドの仕組みをサーバーレスに構築する方法 スピーカー 梅田裕義 Amazon Connect スペシャリスト ソリューションアーキテクト AWS Control Tower 基礎編 統制の効いたマルチアカウント環境を構築する際に AWS Control Tower は有力な選択肢です。AWS Black Belt Online Seminar AWS Control Tower 基礎編では、AWS Control Tower でどんなことが実現できるのか紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 マルチアカウント管理について興味のある方 AWS Control Tower に関心のある方 AWS Control Tower をご利用予定の方 本 BlackBelt で学習できること AWS Control Tower の概要 AWS Control Tower の主要機能 スピーカー 桂井俊朗 ソリューションアーキテクト AWS Control Tower 手順編 AWS Control Tower の有効化 AWS のベストプラクティスに沿ったマルチアカウント環境 (ランディングゾーン) を構築できる AWS Control Tower をセットアップする手順を解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 複数の AWS アカウントを管理されている方 AWS Control Tower を導入予定・検討中の方 AWS Control Tower におけるアカウントの登録手順を整理したい方 本 BlackBelt で学習できること AWS Control Tower ランディングゾーンがセットアップする内容 AWS Control Tower のスムーズな有効化手順 AWS Control Tower にメンバーアカウントを登録する手順 スピーカー 大西朔 クラウドサポートエンジニア AWS CDK の基本的なコンポーネントと機能 (Basic #2) AWS Cloud Development Kit (AWS CDK) の App や Construct, Context などの基本的なコンポーネントを紹介します。また CDK アプリの合成とデプロイの仕組みや、リソースの参照、AWS アカウント上のリソースのインポート、AWS CloudFormation テンプレートの活用についても解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 インフラ構築の手間や作業ミスにお悩みの方 インフラを含めたアプリ全体を素早くデプロイしたいエンジニア 言語を問わず、プログラミングの経験がある方 AWS CDK の仕組みを理解して、よりよいコードを書きたい方 本 BlackBelt で学習できること AWS CDK の仕組みや各コンポーネントの役割を理解して、よりよい CDK アプリのコードを記述することができるようになります。 スピーカー 高野賢司 ソリューションアーキテクト AWS CDK の開発を効率化する機能 (Basic #3) AWS Cloud Development Kit (AWS CDK) を使用してアプリを一緒にデプロイする方法や、複雑な設定を抽象化する方法、デプロイ中に任意の処理を実行する方法など、アプリ全体をコードで定義するのに必要なテクニックを紹介します。また、CDK におけるテストとバリデーション、CDK Pipelines、npm に関する tips も解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 インフラ構築の手間や作業ミスにお悩みの方 インフラを含めたアプリ全体を素早くデプロイしたいエンジニア 言語を問わず、プログラミングの経験がある方 AWS CDK の仕組みを理解して、よりよいコードを書きたい方 本 BlackBelt で学習できること AWS CDK でアプリ全体をコードで定義し、すばやくデプロイするために活用できるテクニックを理解できます。 スピーカー 高野賢司 ソリューションアーキテクト モダナイゼーションプロジェクト立ち上げに向けたポイント ここ数年でモダナイゼーションという言葉が浸透し、実際に取り組まれている事例が増えています。一方で、抽象的なために全容が把握しずらい、検討したが関係者の共通認識がはかれないまま進めた結果頓挫してしまった、どこから手をつければいいか分からない、といった声も聞くようになってきました。本セッションでは、モダナイゼーションプロジェクトの立ち上げに向けて、事前に検討・考慮すべきポイントについてお話します。 資料（ PDF ） | 動画（ YouTube ） 対象者 モダナイゼーションに取り組むうえで、企画フェーズでの検討内容に関心があるリーダー、責任者の方 システムのモダナイゼーションに取り組もうとしているが、その対象選定や方針策定のポイントを確認したい方 本 BlackBelt で学習できること 企画フェーズでの検討内容や、モダナイゼーションに取り組む上での対象選定や方針策定のポイント スピーカー 平岩梨果 ソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2023-09 AWS Batch HPC スペシャリストソリューションアーキテクト 小林広志 2023-09 Amazon Managed Grafana ソリューションアーキテクト 大井友三 2023-09 Amazon Kinesis Video Streams 基礎編 ソリューションアーキテクト 宇佐美雅紀 2023-09 Amazon Kinesis Video Streams 応用編 IoT スペシャリストソリューションアーキテクト 三平悠磨 2023-09 AWS SimSpace Weaver コンセプト編 ソリューションアーキテクト 阿南麻里子 2023-09 Virtual Andon on AWS ソリューションアーキテクト 山田航司 2023-09 AWS Key Management Service セキュリティソリューションアーキテクト 平賀敬博 2023-09 AWS Secrets Manager ソリューションアーキテクト 押川令 2023-09 Amazon GameLift FleetIQ ソリューションアーキテクト 安藤怜央 2023-09 AWS Control Tower 機能紹介編 ソリューションアーキテクト 桂井俊朗 2023-10 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 入門編 クラウドサポートエンジニア 高橋尚久 2023-10 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Container Service(Amazon ECS) 編 クラウドサポートエンジニア 古野俊広 2023-10 AWS FreeRTOS Kernel 編 ソリューションアーキテクト 山岡卓紀夫 2023-10 Amazon EC2 Auto Scaling スケーリングポリシー編 シニアソリューションアーキテクト EC2 フレキシブルコンピュートスペシャリスト 滝口開資 2023-10 アクセラレータ搭載インスタンスの選択肢 シニアソリューションアーキテクト 赤澤智信 2023-10 AWS ML アクセラレータ入門 Annapurna Labs 常世大史 2023-10 AWS Application Discovery Service の概要（AWS 移行準備シリーズ） マイグレーションパートナーソリューションアーキテクト 鈴木槙将 2023-10 Amazon CodeCatalyst Overview 編 ソリューションアーキテクト 三尾泰士 2023-10 AWS Budgets シニアテクニカルアカウントマネージャー 岡本迅人 2023-10 AWS Cost and Usage Reports シニアテクニカルアカウントマネージャー 石王　愛 &nbsp;

はじめに Amazon Simple Storage Service ( Amazon S3 )&nbsp; は、ライブ動画ストリーミングワークフローのベーシックなオリジンとして必要なスケーラビリティ、データの可用性、セキュリティ、パフォーマンス、整合性を提供するオプジェクトストレージサービスです。この記事では、 AWS Elemental Live と AWS Elemental MediaLive を使用して Amazon S3 で HLS 出力グループを生成する際の、設定および耐障害性に関するベストプラクティスを紹介します。Amazon S3 は、ライブ動画向けの低コストでベーシックなオリジンとして、 AWS Elemental MediaStore の代わりに利用できるようになりました。動画コンテンツを準備、保護、配信するうえで包括的な機能を必要とするライブストリーミングのワークフローについては、 AWS Elemental MediaPackage を参照してください。 ライブオリジンのアーキテクチャ 冗長なライブストリーミングアーキテクチャは、同一出力を持つ2つのメディア処理パイプラインを提供します。こちらの例では、 MediaLive Standard チャンネル が Redundant HLS manifests 機能を使用して、2 つの異なる Amazon S3 バケットのパスに HLS 出力を生成します。一方、MediaLive の Single Pipeline クラスでは、出力先が 1 つしかないため、中断が入ると視聴体験に影響が生じます。 どちらのアーキテクチャでも、マニフェストやセグメントの更新に失敗すると、ライブストリームが「古い」状態になり、プレーヤーはオリジンから 200 HTTP のコードレスポンスを受信しますが、通常は動画/音声の最後の数セグメントを再生し、その後停止します。この記事では、このような古いバリアントマニフェストを検出して無効にする方法について紹介します。- 404 HTTP エラーコードを下流の Amazon CloudFront コンテンツデリバリーネットワーク （CDN） とビデオプレーヤーに強制的に送信することで、HL S仕様に記述されている通り、冗長フェイルオーバーがトリガーされます。 Amazon S3 をオリジンストレージとして選択し、上の図が示すように下流の CDN とプレーヤーが冗長マニフェストを処理できるようにするためには、次の基準を考慮する必要があります。 パフォーマンス オーバーザトップ（OTT）ストリーミングに使用されるアダプティブビットレート （ABR） メディアは、通常、動画/音声メディアを含む連続的に命名された一連のファイルセグメントをベースとしています。 Amazon S3 のパフォーマンス最適化 に関するベストプラクティスでは、Amazon S3 が高いリクエストレートに自動的にスケールされ、パーティション化された プレフィックス ごとに少なくとも毎秒 3,500 回以上の PUT/COPY/POST/DELETE リクエストまたは 5,500 回以上の GET/HEAD リクエストを達成する方法を概説しています。 ABR ワークフローでは、各ライブチャンネル形式および関連する品質バリアントの区切り文字としてスラッシュ (/) を使用することで、このプレフィックスが付与されます。MediaLiveの出力パスの構文は、このプレフィックスを提供する ドキュメント に概説されています。 プレイリストやメディアセグメントサイズのオブジェクトに対する PUT/GET リクエストのレイテンシー測定結果の p99.9 で、Amazon S3 のパフォーマンスは AWS Elemental MediaStore のパフォーマンスと比べて機能的に全く同じです。 整合性 Amazon S3 は、すべての AWS リージョンの Amazon S3 バケットのオブジェクトの PUT/DELETE リクエストに対して、強力な書き込み後の読み取り整合性を提供します。この動作は、新しいオブジェクトの書き込みだけでなく、既存のオブジェクトを上書きする PUT リクエスト、そして DELETE リクエストにも適用されます。詳細については、 Amazon S3 data consistency model を参照してください。 新しいオブジェクトの書き込みまたは既存オブジェクトの上書きが成功すると、それ以降の読み取りリクエストには直ちに最新バージョンのオブジェクトが提供されます。また、Amazon S3 はリスト操作でも強力な整合性を提供するため、書き込み後すぐに、すべての変更が反映された状態でバケット内のオブジェクトの一覧を取得できます。マニフェストやセグメントをポストするエンコーダーの書き込みが失敗した場合、使用可能なセグメントが中断されないように再試行の実施を設定する必要があります。 耐障害性 冗長なライブエンコーディングパイプラインの出力は、異なるプレフィックスを使って 1 つの Amazon S3 バケットに、あるいは 2 つの個別の Amazon S3 バケットに送ることが可能です。冗長マニフェスト機能が有効になっている場合、各パイプラインのメインプレイリストは、自身の子マニフェストともう一方のパイプラインの子マニフェストの両方を参照します。パイプラインに問題があると、そのパイプラインの子マニフェストにも問題が生じます。その場合、下流のプレーヤーはメインマニフェストを再度参照して、もう一方のパイプラインの子マニフェストを見つけることができます。 セキュリティ Amazon S3 を使うとお客様は、暗号化機能とアクセス管理ツールを活用して、データを保存し、不正アクセスから保護することができます。Amazon S3 は、PCI-DSS、HIPAA/HITECH、FedRAMP、EU Data Protection Directive、FISMA などに対応するコンプライアンスプログラムを整備しており、お客様が規制要件を満たすお手伝いをします。AWS では更に、Amazon S3 リソースへのアクセス要求を監視するための多数の監査機能もサポートしています。 メディア配信コンテンツのセキュリティは、ライブエンコーダーでの暗号化、および エッジでの安全なメディア配信を AWS で実現するソリューション を使用したアクセスのトークン化により提供されます。ただし、完全な デジタル著作権管理 (DRM) を行うには、AWS Elemental MediaPackage などの他サービスを使用する必要があります。 古いマニフェストの無効化 エンコーダーがメディアプレイリストへの更新内容のアップロードに失敗したとき、プレイリストが古いと見なされた時点でこのオブジェクトに 404 エラーを返させることが望ましい場合がよくあります。古いプレイリストには、ライブエッジよりも過去のセグメントしか含まれていないため、別のバリアントプレイリストへの再生切り替えが必要になる場合があります。404 エラーが返されることでクライアントの再生デバイスは、古いプレイリストのまま行き詰まるのではなく、再生を続行すべく切り替えの判断を下すことができます。 このリファレンス SAM は、デプロイされると、指定された Amazon S3 バケットにアップロードされたプレイリストファイルをすべて監視し、古いプレイリストが検出された場合は削除します ( https://github.com/aws-samples/amazon-cloudfront-s3-hls-invalidator )。 チェックする必要があるのは、エンドリスト、つまり HLS の #EXT-X-ENDLIST タグがないバリアントプレイリストのみです。マスターのマルチバリアントプレイリストは通常、配信開始時にライブエンコーダーからポストされるだけで、その後は更新されないため、Amazon S3 バケットに残しておく必要があります。 ライブエンコーダーでは、チャンネルが再起動した場合にセグメントが互いをオーバーライドするのを防ぐのと、CloudFront に異なるキャッシュキーを割り当てるために、セグメント名にはタイムスタンプを追加することが推奨されます。MediaLive の使用については Identifiers for variable data （変数データの識別子）を使用した segmentModifier の設計 を参照してください。 料金 ほとんどの AWS サービスと同様に、 Amazon S3 や AWS Lambda には最低料金の設定はありません。実際に使用した分だけお支払いいただきます。ライブストリーミングのアプリケーションで考慮すべきコストの要素は、ストレージ、リクエスト、データ転送、Lambda 実行時間です。Amazon S3 の料金については こちら 、AWS Lambda については こちら より詳細を確認してください。 まとめ Amazon S3 を使用した AWS 上でのライブストリーミング をセットアップするために利用できるリファレンスアーキテクチャが利用可能です。そしてこの記事では、古いマニフェストを無効化することで、耐障害性を最適化するためのベストプラクティスをいくつか紹介しています。更なる背景情報については、 AWS re:Invent 2022 – Deep dive on Amazon S3 を参照してください。 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog　(日本語) AWS Media &amp; Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は BD 山口、SA 石井が担当しました。原文は こちら をご覧ください。

はじめに お客様は 2008 年以来、AWS 上で SAP ワークロードを実行しており、これら SAP のお客様の多くは、ABAP を使用して SAP ビジネスプロセスを開発し強化してきました。多くのお客様のビジネスプロセスはカスタム ABAP コードに依存しており、社内またはパートナーを通じて ABAP 開発者のチームを持っています。しかし、ABAPと並行して機械学習や言語翻訳のような機能をAWSサービスで革新することは、従来は面倒でした。この摩擦を減らすために、我々は 2022年 11 月に AWS SDK for SAP ABAP のプレビューを発表しました。これにより、ABAP 開発者は、データフォーマットのマッピング、多くのポイント・ツー・ポイント接続の作成と維持、SAP と AWS のセキュリティモデルの統合を行うことなく、快適な ABAP プログラミング言語を使用して AWS サービスに接続することで、SAP ベースのビジネスプロセスを容易に近代化し、変換することができます。 このブログでは、AWS SDK for SAP ABAP をインストールして設定し、 Amazon Simple Storage Service (Amazon S3) のバケットに存在するオブジェクトをリストアップする ABAP プログラムの例を紹介します。 AWS SDK for SAP ABAP の使用方法に関する詳細については、 AWS SDK for SAP ABAP のコード例を参照してください。 アーキテクチャ SAP NetWeaver ベースの ABAP システムにインポートすると、AWS SDK for SAP ABAP は、ネイティブの ABAP コンストラクトを使用して AWS サービス API を簡単に利用するための一連の SAP ABAP クラスを提供します。開発者は、既存の SAP 機能を強化したり、新しいアプリケーションを開発するために、レポートやプログラムでこれらの ABAP ベースのクラスを使用することができます。例としては、請求書作成を自動化するためのインテリジェントなドキュメント処理、 AWS Translate を使用した言語翻訳、SAP とサードパーティアプリケーション間でファイルを交換するための Amazon S3 の使用などがあります。 前提条件 このウォークスルーを実施するには以下の前提条件が必要です： SAP NetWeaver ABAP 7.40 以上 AWS アカウント Amazon S3 バケットに保存されたファイル IAM セキュリティのベストプラクティス に従った IAM ロール SAP ABAP のための AWS SDK のための SAP 権限 ウォークスルー このブログでは以下のステップを説明します： AWS SDK for SAP ABAP のセットアップ AWS SDK for SAP ABAP の設定 サンプル ABAP プログラムの作成 1. AWS SDK for SAP ABAP のセットアップ このセクションでは、前提条件の確認、AWS SDK for SAP ABAP のダウンロード、NetWeaver ABAP システムへの必要な移送のインポートを行います。 SAP BASIS リリースと SAP Kernel には最低限必要なバージョンがあります。移送のインポートに進む前に、 前提条件 が完全に満たされていることを確認してください。AWS SDK for SAP NetWeaver ABAP は こちらからダウンロード できます。 AWS SDK for SAP ABAP は、200 を超える AWS サービス用の個別の ABAP 移送を含む圧縮アーカイブとして提供され、個別の移送ファイル（データと共同ファイル）が個別のサブディレクトリに格納されています。サブディレクトリには 3 文字の略称（TLA）があり、 ここ で確認できます。AWS SDK の移送はクライアントに依存しません。 コア移送は必須であり、SDK ランタイムコード、 AWS Security Token Service (AWS STS) 用モジュール、Amazon S3 用モジュールを含みます。残りの SDK モジュールはそれぞれ別の移送で提供されます。お客様のシステムで SDK のサイズを小さく保つために、各 SDK モジュールはオプションであり、お客様のビジネスアプリケーションに必要であればインストールすることができます。 AWS SDK for ABAP のインストールは、必要な移送をインポートすることで行われます。いつでも最新の移送をインポートすることで、SDK のパッチやアップグレードを簡単に行うことができます。必要なモジュールが特定されたら、コアモジュールとサービスモジュールのデータファイルと共同ファイルを DIR_TRANS の data サブディレクトリと co-file サブディレクトリにコピーします。トランザクションコード STMS を使用して、移送依頼をインポートキューに追加します。 以下のスクリーンショットでは、コアと AWS Translate に関連する移送がインポートキューに追加されています。 全ての移送を同時にインポートすることも可能ですが、移送を個別にインポートする場合は、最初にコア移送をインポートする必要があることに注意してください。Ignore Invalid Component Version オプションが選択されていることを確認してください。 移送のインポートには、選択したモジュールの数によって時間がかかる場合があります。移送が正常にインポートされると、STMS は緑または黄色のインジケータを表示します。 インストールに関するより詳細な情報は、 Installing the AWS SDK for SAP ABAP Developer Guide に記載されています。 AWS SDK for SAP ABAP のアンインストールは、アンインストール移送をインポートすること でも可能です。インストールプロセスと同様に、アンインストー ル移送はモジュールによってインポートされる必要があります。コアモジュールがアンインストールされると、インプリメンテーションガイド (IMG) を介して行われた以前のすべてのコンフィギュレーションも削除されることに注意する必要があります。 2. AWS SDK for SAP ABAP の設定 ABAP プログラムで AWS SDK for SAP ABAP を使用する前に、トランザクションコード /AWS1/IMG を使用して設定する必要があります。構成は、品質および生産 SAP システムに転送可能なカスタマイズ要求に保存されます。/AWS1/IMG トランザクションの実行に必要な権限については、 SAP オーソライゼーション を参照してください。コンフィグレーションは、大きく 4 つの一般的なカテゴリーに分類されます： 技術的前提条件 グローバル設定 アプリケーション設定 ランタイム設定 SAPGUI コマンドバーに /n/AWS1/IMG と入力し、Enter キーを押すと、AWS SDK for SAP ABAP のインプリメンテーションガイド(IMG)が表示されます。 AWS SDK for SAP ABAP Settings ノードを展開します。 2.1. 技術的前提条件 Technical Prerequisites ノードを展開します。プロファイルパラメータ icm/HTTPS/client_sni_enabled が TRUE に設定され、 AWS ルート CA 証明書 が SSL Client Standard PSE にインポートされているかどうかを IMG アクティビティ で確認します。 SAP システムが AWS 以外の場所で実行されている場合、SAP の Secure store and forward (SSF) メカニズムを使用して AWS Identity and Access Management ユーザーの資格情報（アクセスキー ID とシークレットアクセスキー）を暗号化するには、以下の追加設定が必要です。 Additional Settings for On-Premises systems を展開します。新しい GUI ウィンドウでトランザクションコード SE16 を実行して、SSF アプリケーションを定義します。テーブル名 SSFAPPLIC を入力します。以下のスクリーンショットのように新しいエントリを作成します。 IMGアクティビティ Set SSF Parameters を実行して、SSFアプリケーションの暗号化パラメータを設定します。 New Entries を選択します。前のステップで作成したSSFアプリケーションを選択し、 Save を選択します。 Hash Algorithm を SHA256 に、 Encryption Algorithm を AES256-CBC に変更します。その他の値はデフォルトのままにしておきます。 Save を選択します。 IMGアクティビティ Create PSE for SSF Application を実行します。 STRUST トランザクションコードに移動します。 SSF SSF Encryption for the AWS SDK for SAP ABAP を右クリックし、 Create を選択します。デフォルト設定を受け入れます。 IMG アクティビティ Assign an SSF application to the AWS SDK for SAP ABAP を実行します。新規エントリを作成し、SSFAPPLIC テーブルに作成した SSF Application ID を入力します。 2.2. グローバル設定 グローバル設定は、AWS SDK for SAP ABAP 全体の動作に影響します。 IMG ノード Global Settings を展開し、IMG アクティビティ Configure Scenarios を実行します。通常運用では、DEFAULT というシナリオを作成します。 DEFAULT シナリオとは異なる設定を行う災害復旧などのシナリオを追加できます。ほとんどのユースケースでは、DEFAULTシナリオで十分です。 作成した DEFAULT シナリオは、アクティブなシナリオとして設定する必要があります。IMG ノード Runtime Settings を展開し、IMG アクティビティ Active Scenario を実行します。DEFAULT シナリオを選択し、 Commit Scenario Change を選択します。 IMG ノード Global Settings を展開し、IMG アクティビティ Technical Settings を実行して、AWS SDK のグローバル構成を構成します。以下のスクリーンショットのように新規エントリを作成します。 2.3. アプリケーション構成 アプリケーション構成は、 SDK Profile と Logical Resource Resolver の作成で構成されます。 SDK Profile は、請求書や販売注文関連の機能拡張など、典型的なユースケースに必要なすべての設定をグループ化したものです。SDK Profile では、SAP システムのシステム ID（SID）やクライアント、ステップ 2.2 で設定したシナリオ、使用する AWS リージョン、認証方法などの SAP 設定を定義します。使用する認証方法は、SAP システムが AWS クラウドにあるか AWS 外部にあるかによって異なります。IMG アクティビティ SDK Profile を実行します。意味のある名前で新しい SDK Profile を作成します。この例では、 ZFINANCE という名前のプロファイルを作成します。左側のパネルから Authentication and Settings を選択します。新しいエントリを作成し、SAPシステムの詳細とAWSリージョンを入力します。この例ではus-east-1 AWSリージョンを使用します。認証方法は、以下のオプションのいずれかを選択します。 SAPシステムが Amazon Elastic Compute Cloud (Amazon EC2) 上で動作している場合、以下のスクリーンショットに示すように、認証方法として Instance Role via Metadata を選択します。 SAP システムがオンプレミスで稼働している場合は、認証方法として Credentials from SSF Storage を選択し、 Save を選択します。 Set Credentials を選択します。IAM ユーザーのアクセスキーとシークレットアクセスキーを入力します。 左側のパネルから IAM Role mapping を選択します。Logical IAM Role の名前を入力し、AWS IAM Administrator から提供された IAM ロールの Amazon Resource Name (ARN) を入力します。この IAM ロールは、必要な AWS サービスを呼び出す権限を持ちます。この例では、IAM ロールは S3 バケットに存在するオブジェクトをリストアップする権限を持っています。 Logical Resource Resolver は、ABAP プログラムでの AWS リソース名（S3 バケットなど）のハードコー ディングを防ぎ、DR（Disaster Recovery）のように AWS リソース名が DR AWS リージョンで異なる場合に役立ちます。IMG アクティビティ Logical Resource Resolver を実行します。意味のある名前で新しい論理リソースを作成します。この例では、 ZFINANCE_S3_RESOURCE という名前を使用します。左側のパネルから Physical Resource Mapping を選択し、ステップ2.2で設定したSAPシステム設定とScenarioに続いてAWSリソース名を入力します。この例では、ファイルを保存したS3バケット名を入力します。 次のスクリーンショットは、この例で使用する abap-sdk-demo という名前のS3バケットです。オブジェクトをS3バケットにアップロードするには、Upload.Amazon S3 Bucket uploaded with objectsを選択します。 2.4. ランタイムの設定 トラブルシューティングのためにトレースを有効にする必要がある場合は、IMG アクティビティ Log and Trace を実行し、必要なトレースレベルを選択することで実行できます。 3. サンプルABAPプログラムの作成 トランザクションコードを SE38 実行し、 zdemo_s3_listbuckets という名前のプログラムを作成します。内容を以下のABAPコードに置き換えます。このコードは、AWS SDK for SAP ABAP を使用して S3 バケットに存在するオブジェクトをリストします。正常に実行するためには、前のステップで SDK の設定を完了する必要があります。 REPORT zdemo_s3_listbuckets. START-OF-SELECTION. PARAMETERS pv_lres TYPE /aws1/rt_resource_logical DEFAULT 'ZFINANCE_S3_RESOURCE' OBLIGATORY. DATA(go_session) = /aws1/cl_rt_session_aws=&gt;create( 'ZFINANCE' ). DATA(gv_bucket) = go_session-&gt;resolve_lresource( pv_lres ). DATA(go_s3) = /aws1/cl_s3_factory=&gt;create( go_session ). TRY. DATA(lo_output) = go_s3-&gt;listobjectsv2( iv_bucket = CONV string( gv_bucket ) iv_maxkeys = 100 ). LOOP AT lo_output-&gt;get_contents( ) INTO DATA(lo_object). DATA lv_mdate TYPE datum. CONVERT TIME STAMP lo_object-&gt;get_lastmodified( ) TIME ZONE 'UTC' INTO DATE lv_mdate. WRITE: / CONV text30( lo_object-&gt;get_key( ) ), lv_mdate, lo_object-&gt;get_size( ). ENDLOOP. CATCH /aws1/cx_rt_generic INTO DATA(lo_ex). DATA(lv_msg) = lo_ex-&gt;if_message~get_text( ). MESSAGE lv_msg TYPE 'I'. ENDTRY. プログラムを実行すると、次の画像の例のような出力が表示されるはずです。出力には、S3バケットに存在するオブジェクトが一覧表示されます。 まとめ このウォークスルーでは、AWS SDK for SAP ABAP のインストールと設定方法、そしてわずか数行の ABAP コードで S3 バケットに存在するオブジェクトをリストアップする方法を紹介しました。AWS SDK for SAP ABAP を使用すると、SAP ABAP 開発者は、SAP ABAP 言語を使用してネイティブに AWS サービスのパワーを活用することにより、SAP ベースのビジネスプロセスを拡張し、変換することが容易になります。 詳細については、 AWS SDK for SAP ABAP のページ をご覧ください。 AWS SDK for SAP ABAP はこちらからダウンロード できます。 数千ものお客様が AWS for SAP を選択する理由については、 AWS for SAP のページ をご覧ください。 翻訳は Partner SA 松本が担当しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 週刊AWSをご利用頂いているお客様より、次のような声をお伺いしました。チームで定期的に時間を取り、週刊AWSの記事を読む会を実施されているとのことです。とても嬉しく思うとともに、素敵なご利用方法だと思いました。 引き続きわかりやすい記事をお届け出来るように心がけていきます。ありがとうございます。 それでは、先週の主なアップデートについて振り返っていきましょう。 2023年9月4日週の主要なアップデート 9/4(月) 大きなアップデートはありませんでした。 9/5(火) Amazon Personalize simplifies implementation by extending column limits Amazon Personalize で、モデルをトレーニングする際のデータセットの列数上限を増やしました。Personalize では、独自のデータスキーマを利用してパーソナライゼーションモデルをトレーニングできます。独自のデータには、「 アイテムデータセット 」と「 ユーザーデータセット 」が含まれています。今回のアップデートで、アイテムデータセットの列数上限が、50 列から 100 列と 2 倍になりました。ユーザーデータセットでは、列数上限が 5 列から 25 列と 5 倍になりました。これにより、お客様はより多くのデータを Personalize に渡すことが出来、実験をより高速に実施しやすくなりました。 AWS SAM CLI announces local testing and debugging support on Terraform projects AWS SAM CLI を利用して、HashiCorp Terraform で定義された Lambda 関数と API Gateway を、ローカルでテスト、およびデバッグが出来るようになりました。これまでは、Terraform で実際に deploy して AWS 上で確認する方法がありました。今回のアップデートでローカルで作成したテンプレートファイル (.tf ファイル) を、ローカルのまま動作確認ができるようになり、より高速に確認と修正のサイクルを推進できるようになりました。Terraform のバージョン 1.1 以上でサポートされています。詳細は AWS Blog をご確認ください。 Amazon CloudWatch adds Amazon EKS control plane logs as Vended Logs Amazon EKS のコントロールプレーンログが、Amazon CloudWatch Logs における Vended Logs に分類されました。Vended Logs は、お客様に代わって AWS のサービスがネイティブに発行するログです。Vended Logs は利用料に応じて段階的に料金が割引になる仕組みがあります。例をあげると、CloudWatch Logs に格納する場合、初めの 10 TB は 1 GB あたり $0.76 です。10 TB を超えて、次の 20 TB を格納する場合、1 GB あたり $0.38 と安価になる仕組みがあります。詳細は 料金ページ をご確認ください。 9/6(水) Amazon CloudWatch Logs announces regular expression filter pattern syntax support Amazon CloudWatch Logs のフィルターパターン構文で正規表現がサポートされ、ログの検索やマッチングがより簡単になりました。ユースケースを一つ挙げると、ログ監視を行う際に、特定の文字列 (例 : statusCode=404) が出てきたとき、アラートとしてメールや Slack 通知などを行いたいことがあります。アップデート以前では、アラートの条件に正規表現が利用できなかったので、statusCode=404 や statusCode=405 といった複数の条件を指定しにくい場合がありました。今回のアップデートで正規表現を新たに利用できるようになったため { $.statusCode=%4[0-9]{2}% } といった柔軟な指定ができるようになりました。 Amazon SageMaker Inference now supports Multi Model Endpoints for PyTorch SageMaker Multi-Model Endpoint で、新たに PyTorch をサポートしました。SageMaker Multi-Model Endpoint は、1 つの SageMaker エンドポイントに複数モデルをデプロイすることで、コスト最適化のメリットがあるフルマネージド機能です。例えば、1000 個のPyTorch モデルを 1 つのエンドポイントにデプロイすることで、推論エンドポイントを共有でき、コストの最適化が図れます。 AWS Backup launches resource exclusion for AWS CloudFormation stack AWS Backup で AWS CloudFormation をバックアップする際に除外する機能が追加されました。AWS Backup に AWS CloudFormation で作成したスタックをバックアップ対象として指定できる機能があります。スタック単位でバックアップが出来るため、サポートしているコンポーネントを一括でバックアップする使い方が可能です。今回のアップデートで、スタックの中で特定のリソースをバックアップ対象から除外出来るようになりました。バックアップ対象をより柔軟に指定できるようになった形です。 9/7(木) Amazon Kendra releases Web Crawler for dynamic content support Amazon Kendra のウェブクローラーコネクタ v2.0 で動的なウェブサイトをサポートしました。ウェブクローラーコネクタでは、Web サイトの URL を指定しクローリングすることで、Kendra の検索対象に含めることができます。今回のアップデートにより、Angular、React、JavaScript などで動的にレンダリングされる Web サイトを、データ収集の対象としてサポートしました。 AWS Step Functions launches enhanced error handling AWS Step Functions でエラーハンドリングを行う際に、「動的なエラーメッセージの出力」や「リトライ間隔の調整」をしやすくなりました。「動的なエラーメッセージの出力」は、Step Functions で実行するなんらかの処理中にエラーが発生した際に、そのエラーメッセージを Fail アクションで動的に認識し、Step Functions 上のエラーメッセージとして出力できるようになりました。「リトライ間隔の調整」は 2 種類あります。1 種類目は、リトライを繰り返すエラーの際に最大遅延時間を指定できるようになりました。これにより、指数関数的なリトライを行う際に望ましい時間枠を指定できるようになりました。2 種類目は、リトライ間隔にジッタ―を追加できるようになりました。リトライを行う際にランダムな遅延を導入することで、同時リトライによる負荷の集中を回避しやすくなりました。 Amazon Detective adds Amazon EKS security investigations to AWS Workshop Studio 新機能のお知らせとは少々異なるのですが、過去リリースされた新機能を学習しやすくなったお知らせです。Amazon EKS で検出された脅威とセキュリティ調査結果に対して、Amazon Detective で効果的に調査する方法を Amazon Detective Workshop で学習しやすくなりました。Amazon Detective では EKS 監査ログを基に、操作履歴の可視化や、詳細な調査を支援する機能があります。例えば「セキュリティ侵害の兆候を示す Kubernetes ユーザーアカウントが呼び出した Kubernetes API メソッドは何か」といった内容を素早く確認できます。この機能の効果的な利用方法を学習するためのトピックが Workshop に追加されました。 9/8(金) Amazon SES email receiving service expands to 7 new regions Amazon SES でメールを受信する機能が、東京リージョンを含めた 7 つのリージョンで新たに利用できるようになりました。Amazon SES のメール受信機能は、Microsoft Outlook のような E メールクライアントを使って受信する方法とは異なります。ユースケース例をあげると、Amazon SES が受信したメールを自動的に保存したり、AWS Lambda や Amazon SNS を使ってなんらかの自動処理を行うことができます。例えば、お客様からの問い合わせのメールを Amazon SES で受信し、Lambda 関数を起動します。起動した Lambda 関数経由で問い合わせ内容を Slack 上に表示する、といったことが可能になります。 Amazon Route 53 now supports AWS-managed prefix lists for health checks Managed prefix lists で、新たに Route 53 のヘルスチェックをサポートしました。Managed prefix lists は、AWS で提供しているサービスに関連する IPv4 または IPv6 のアドレス範囲を定義したものです。ネットワークセキュリティを管理する上で便利な使い方が出来ます。使い方の例を挙げると、EC2 インスタンス上で Web サーバーを構成しているときに、Route 53 のヘルスチェックに限定してネットワーク通信を許可したい時があります。いままでは、セキュリティグループのインバウンドルールに、手動で Route 53 ヘルスチェックに関連する IP アドレスを設定することで実現できました。ただ、IP アドレス範囲が変更される可能性があり追従する手間がありました。今回のアップデートで Managed prefix lists で提供されているものを指定することで、Route 53 ヘルスチェックの最新の IP アドレス範囲を利用でき、通信許可を設定しやすくなりました。 AWS Backup announces support for Amazon Aurora continuous backup AWS Backup は、Amazon Aurora の 継続的バックアップ を新たにサポートしました。継続的バックアップを利用することで、1 秒以内の精度で選択した時間まで巻き戻してリストアができます。最大 35 日まで遡ることができます。継続的なバックアップは、最初にフルバックアップを作成し、トランザクションログを継続的にバックアップすることで実現しています。Amazon Aurora 側で、同様な機能の ポイントインタイムリカバリ がありましたが、AWS Backup 経由では管理ができませんでした。今回のアップデートで、AWS Backup を利用して Amazon Aurora の柔軟なバックアップリストアを管理しやすくなりました。 9 月 22 日 18:30 より、 AWS 秋の Observability 祭り が開催されます。Amazon CloudWatch を初めとした Observability 関連サービスの活用方法のご紹介や、NTTドコモ様、中外製薬株式会社様、株式会社デイトナ・インターナショナル様の事例発表があります。目黒オフィスで開催するリアルイベントとなっており、席に限りがある事前登録制です。この機会にぜひご登録ください。 それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

AWS Hybrid Cloud and Edge Computing サービスの導入は開発者に対してコンピューティングリソースおよびストレージへの低遅延なアクセスを提供し、AWSインフラストラクチャのグローバルな展開を急速に拡大しています。米国内だけでも、19個のAWS Wavelengthゾーンが一般提供されています。アプリケーションを展開する場所の選択肢が増えることにより、どの場所がアプリケーションリクエストにとって最適になるのかが新たな課題になっています。 エッジを意識したデプロイ: エッジディスカバリの原点は、効果的に地理分散したデプロイになります。カバレッジと低遅延アクセスを最適化したい開発者は、お客様の要件を満たすために複数のWavelengthゾーンにアプリケーションをデプロイする必要があります。自動的な決断メカニズムが大規模でエッジコンピューティング展開において極めて重要です。別の投稿では、この課題に対処するためのテクニック（例: Pod Topology Spread Constraints）について説明しました。 エッジディスカバリ: アプリケーションがデプロイされた後、特定のクライアントセッションに対する最適なアプリケーションエンドポイントを決定するための選択基準、方法論、またはアルゴリズムが必要です。これには通信遅延、利用可能なネットワーク帯域幅、ネットワークトポロジーなどが含まれて考慮する必要があります。 ドメインネームシステム（DNS）は、サーバーなどのリソースに到達するためのデファクトアプローチですが（例: myedgeapplication.com）、エッジコンピューティングに必要な精度と粒度が通信プロバイダ（CSP）ネットワーク内で常に提供されているわけではありません。たとえば、Amazon Route 53などのDNSサービスは、ロケーションベースのルーティングを提供しています。DNS名（例: myedgeapplication.com）は、ユーザーの地理的な位置に基づいてエンドポイントにルーティングすることができますが、基本的にはユーザーのDNSリゾルバのIPアドレスによって決定されます。 ただし、再帰的なDNSルックアップで使用されるIPアドレス（eDNSが有効でない限り）は、要求デバイスではなくそのDNSサーバーのIPアドレスになります。DNSサーバーの場所がクライアントがアタッチされているUPFの場所と一致しない場合、結果は不正確なマッピングになります。開発者には、リクエストを出すデバイスの場所をより詳細で正確な特定方法が必要です。 この課題を対処するために、この記事では、CSPが開発したエッジディスカバリサービス（EDS）APIを使用し、イベント駆動アーキテクチャと統合するリファレンスパターンを記載します。例として、この記事では、Verizon Edge Discovery Serviceを使用して、高度に分散したエッジコンピューティング環境でモバイルクライアント向けのダイナミックなワークフローを提供する方法を示します。 モバイルネットワークの基本 モバイルエッジ環境に接続する際、モバイルトラフィックはRadio Access Network（RAN）を介してルーティングされます。すなわち、LTE無線（eNB）または5G無線（gNB）およびパケットコアネットワークを介してルーティングされます。UEがモバイルネットワークにアタッチすると、LTEでは特定のPacket Gateway（PGW）、5GではUser-Plane Function（UPF）と呼ばれるノードとの接続が確立され、ユーザ端末（UE）のすべての入出力データトラフィックが処理されます。これにより、キャリアグレードのNAT（CG-NAT）が使用され、UEのトラフィックはプライベートモバイルネットワークからパブリックインターネットへと変換されます。 モバイルネットワークでは、UEはコアネットワーク内でアタッチされているLTE PGW（または5G UPF）との間で確立されたIPセッションを維持しながら、無線RANセル間でシームレスに移動し、ハンドオーバーすることができます。カバーエリアが失われた場合やUEが再起動した場合（デバイスをオンオフにした場合）、UEまたはネットワークは再アタッチをトリガーし、コアネットワークとのIPセッションを再確立します。したがって、モバイルハンドオーバーはWavelengthゾーンのネットワークトポロジー上の近さに影響を与えないケースがほとんどです。たとえクライアントが数百マイルを移動したとしても、地理的に最も近いWavelengthゾーンが変わったが、ネットワークトロポジー上最も近いWavelengthゾーンは変わりません。その結果、モバイルアプリケーションでは、現在接続しているエンドポイントが最適かどうかを定期的にチェックすることが推奨されています。 具体的な例を挙げましょう。ある朝、ニューヨーク市で電源を入れた4G/5Gデバイスがあると仮定します。このデバイスはニューヨーク市のPGWにアタッチされます。したがって、最も低遅延のWavelengthゾーンはニューヨーク市となります。このモバイルデバイスが2,000マイル西にあるデンバー市に移動したとしても、最も低遅延のWavelengthゾーンはニューヨーク市のままです。ネットワークに再アタッチしない限り、この状況は続きます。 デンバー市からは、クライアントはすべてのトラフィックをニューヨーク市のパケットコアを介して、キャリアのバックボーンを経由でデンバー市に戻ってきます。ジオロケーションベースのディスカバリはこの動きに影響を与えることはありません。これは、従来のCSPが設計した継続性と信頼性を重視する長寿命セッションの性質によるものです。ただし、5Gのネットワークでは、CSPはリアンカリングとセッションの継続性に対し、より大きな柔軟性が与えられています。したがって、この例で、今では最も近いWavelengthゾーンはデンバー市のになる可能性があります。 開発者を5Gネットワークの深い専門知識から解放するために、Edge Discovery API には使いやすいサービスメッシュが用意されています。これにより、5G ネットワークトポロジーに対応した方法を公開して、クライアントを最適なエッジコンピューティングゾーンにルーティングできます。Edge Discovery API は、ネットワークのパフォーマンス特性 (最大遅延、必要な帯域幅など) を考慮したユーザー定義のサービスプロファイルを使用して、トポロジー的に最適なモバイルエッジコンピュートノードを選択できます。この方法により、「最適な」エッジゾーンをどのように決定するかというロジックは、アプリケーション開発者から通信プロバイダにオフロードされます。 キャリア開発したEDSデザイン EDS は、データベース、キュー、マイクロサービス、その他のクラウドリソースなど、あらゆるアプリケーションリソースをカスタム名で登録できる API です。各カスタム名は ServiceEndpoints オブジェクトと呼ばれる一意の識別子で、通信事業者向けのアプリケーションサービスのエンドポイントメタデータで構成されます。各 ServiceEndpoint オブジェクトは、キャリアの IPv4 アドレス (AWS Wavelength では IPv6 は現在サポートされていません)、オプションとして FQDN 、ポート、およびその他のメタデータで構成されています。 モバイルクライアントが最適なエッジエンドポイントを特定しようとする場合、クライアントはまず、TURNサーバーやその他のツール（例: ifconfig.me）を使用してCG-NATパブリックIPを特定する必要があります。IPアドレスを特定した後、この値を必要なUEIdentity属性とともに指定されたserviceEndpoints識別子に渡すことで、最適なサービスエンドポイントを取得します。APIリファレンスについて詳しくは、「 5G Future Forum API specifications 」や「 5G EDS documentation 」を参照してください。 図1: EDSワークフロー EDSワークフロー 例として、VPC（10.0.0.0/24）に2つのサブネットがあり、各サブネットにはAmazon Elastic Compute Cloud（Amazon EC2）インスタンスが起動されています。各インスタンスにはキャリアIPアドレスがアタッチされています。 1) サンフランシスコWavelengthゾーン（us-west-2-wl1-sfo-wlz-1）CIDRレンジ10.0.0.0/26 キャリアIPアドレス: 155.146.21.144 2) ラスベガスWavelengthゾーン（us-west-2-wl1-las-wlz-1）CIDRレンジ10.0.0.64/26 キャリアIPアドレス: 155.146.118.11 図2: Amazon VPCアーキテクチャ EDSへのアクセス EDS を使用するには、まず API を認証してサービスプロファイルを作成する必要があります。このオブジェクトは、Edge アプリケーションに必要なリソースを記述し、EDS が応答する選定基準を定義します。注目すべきサービスプロファイルフィールドには、最小帯域幅、最大リクエストレート、最小可用性、最大遅延などがあります。 次に、ServiceEndpoints オブジェクトを一連のレコードとともにサービスプロファイルにアタッチします。ワークフロー全体の例として、サービスプロファイルとServiceEndpointsの関係を示した前の図を参考してください。 最後に、最適な Edge エンドポイントを特定したいモバイルクライアントの場合、API を認証して、選択した ServiceEndpointSid からエンドポイントを取得する必要があります。EDS から、サービスプロファイルで定義されている最適なエンドポイントのリストが回答されます。 EDSの拡張: 動的エンドポイントの更新 UEがEDS APIを呼び出す基本的な部分に加えて、開発者体験向上のための最適化ができます。例えば、EDS APIをAWSネイティブのワークフローと統合することで、エッジコンピュートサービスエンドポイントのマッピング管理を簡素化することができます。たとえば、図3は、3つ目のWavelengthゾーンが導入された場合に何が起こるかを示しています。手動で操作しなければ、Wavelengthゾーン3 に地理的に近い UE は適切にルーティングされません。これは、エンドポイントを登録するために EDS に対して新しいクエリを行わなければ、新しいロケーションがマッピングされないためです。 エンドポイントを動的に登録するソリューションを構築するために、次のAWSサービスを使用します。 Amazon EventBridge: AWSサービスからデータを取り込むサーバーレスのイベントバスを使用して、カスタムルールを設定して自動応答をトリガーできます。 AWS Lambda: AWS Wavelengthメタデータを抽出し、サードパーティのEDSを埋めるサーバーレス関数を作成できます。 AWS Systems Manager Parameter Store: EDSのAPI応答から、AWS Systems Manager Parameter Storeに必要な情報（例: serviceEndpointsIdおよび認証情報）をキャッシュすることができます。 Amazon EC2 Tag: 単一のアカウントから複数のエッジアプリケーションを管理できるようにするために、アプリケーションリソースに適切にタグを付け、Lambdaで選択される特定のタグを使用します。 図3: Amazon EC2を使用したエッジディスカバリアーキテクチャ 前述した動的なエッジディスカバリの手法は以下のワークフローに基づきます： デプロイ前に、アプリケーションリソースに使用する一連のAWSタグを事前に選択します。この例では、eds-data-plane-app-nameとcustomer-wavelength-appをそれぞれタグキーと値として選択しました。これらのタグは、EDS APIに自動的に登録されるリソースを一意に識別します。 次に、Amazon EC2ライフサイクルイベントに基づいた特定のルールを使用してEventBridgeを設定します。エッジ環境のすべての変更をキャプチャするために、最も確実な方法は、EC2インスタンスの実行・終了状態の変更を表すイベントを全てキャプチャすることです。イベントが検出されると、EventBridgeは関連するメタデータをキャプチャするためのLambda関数をトリガーします。 Lambda関数の第一部分では、現在実行中のEC2インスタンスで、タグ（ステップ1から）が一致するすべてのEC2インスタンスをAmazon EC2 APIから取得します。取得された各EC2インスタンスに対して、アタッチされたキャリアIPアドレスを抽出します。アタッチされたアドレスは、起動後にアタッチされる静的アドレス（Elastic IP）または起動時に割り当てられるエフェメラルIPアドレスとして表示される可能性があることに注意してください。 Lambda関数の第二部分では、EDS API に対して認証を行い、ServiceEndpoints オブジェクトに最新のエッジエンドポイントを設定します。これには、新しいレコードの作成や古いレコード (EC2 インスタンスの終了/停止など) の削除が含まれる場合があります。 EDSの現在の設計では、serviceEndpointsオブジェクトが更新されるたびに、新しいserviceEndpointsId識別子が返されます。AWS環境が最新のメタデータを持つことを確認するために、Lambda関数はAWS Systems Manager Parameter StoreにserviceEndpointsIdの最新値を書き込みます。 モバイルデバイスの観点からは、最も近いAWS Wavelengthゾーンのエンドポイントを特定するたびに、EDS APIを認証・クエリして、最適なエンドポイントを取得します。 EDSの応答に従い、モバイルクライアントはIPアドレスとポートまたはFQDNと直接接続できます。 EDSと自動スケーリング環境の統合 エッジアプリケーションのトラフィック量が多い場合、AWS Auto Scaling を使用してキャパシティを動的に調整し、スケーリングプロセスを管理できます。上記の例の環境が下記のように拡張されたと仮定します。 サンフランシスコWavelengthゾーン（us-west-2-wl1-sfo-wlz-1） インスタンス1：アタッチされたキャリアIPアドレス：155.146.21.144 インスタンス2：アタッチされたキャリアIPアドレス：155.146.21.135 インスタンス3：アタッチされたキャリアIPアドレス：155.146.21.128 ラスベガスWavelengthゾーン（us-west-2-wl1-las-wlz-1） インスタンス1：アタッチされたキャリアIPアドレス：155.146.118.41 インスタンス2：アタッチされたキャリアIPアドレス：155.146.118.32 インスタンス3：アタッチされたキャリアIPアドレス：155.146.118.2 図4：AWS Auto Scalingを使用したエッジディスカバリアーキテクチャ モバイルクライアントがEDS APIをクエリし、最適なエッジリソース名（ERN）がサンフランシスコWavelengthゾーン（us-west-2-wl1-sfo-wlz-1）である場合、APIレスポンスとしては3つのインスタンスIPアドレス（155.146.21.144、155.146.21.135、155.146.21.128）の間でロードバランシングしません。このシナリオでは、EDSは次の方法でDNSを併用すべきです： 高可用性を実現するために、各WavelengthゾーンにApplication Load Balancer（ALB）を作成し、各Wavelengthゾーンのインスタンスを対象グループとして設定します。例えば、サンフランシスコWavelengthゾーンにALBを構成し、上記の3つのEC2インスタンスを対象グループとして設定します。AWS Wavelengthでのロードバランスについて詳しくは、「 Enabling load-balancing of non-HTTP(S) traffic in AWS Wavelength. 」をご覧ください。 ドメイン（例：edgeapp.com）を取得した後、各Wavelengthゾーンのサブドメインを作成し、エイリアスレコードを使用してロードバランサーのFQDNを指定するようにします。例えば、sfo.edgeapp.comは、サンフランシスコWavelengthゾーンALBのFQDNに変換するようになります。 次に、EDS APIを設定します。servceProfileを作成した後、serviceEndpointsオブジェクトを作成し、エッジリソース名（ERN）ごとに単一のリソースレコードを設定します。この場合、2つのレコードがあります。サンフランシスコWavelengthゾーンERN（us-west-2-wl1-sfo-wlz-1）に対応するレコードと、ラスベガスWavelengthゾーンERN（us-west-2-wl1-las-wlz-1）に対応するレコードです。 前のシナリオでは、各リソースレコードに対してIPv4アドレスとポートが指定されますが、今回は、そのWavelengthゾーン内のALBの完全修飾ドメイン名が指定されます（上記ステップ4を参照）。UEからEDS APIをクエリする際、出力はALBのDNS名であり、IPアドレスではありません（ステップ7と8を参照）。 直接 vs. 間接的なエッジディスカバリ 現在、EDS API にはモバイルネットワーク内からだけではなく、パブリックインターネットからもアクセスできます。これにより、API の呼び出しが柔軟になり、特に EDS をモバイルクライアントから直接問い合わせるもしくは間接的に問い合わせるかを可能となります。 直接（クライアントサイド）： 特定のユースケースでは、開発者は簡素化を求め、各モバイルエンドポイントが直接EDSと対話するようにしたいのです。この例では、モバイルデバイスは上記のステップ6-7に従います。このアーキテクチャの「コスト」は 2 つあります。1 つは、数百 （もしくは数千）のデバイスが API キーのコピーを保持しなければならないセキュリティ上のリスクと、EDS への不必要に大量の呼び出しのことです。 間接（サーバーサイド）： 他の場合では、開発者はエッジディスカバリをAWSネイティブのエンティティに「オフロード」したい考えもあります。これはコンテナ化されたアプリケーションまたはLambda関数として存在し、モバイルデバイスはこのキャッシュ層との直接対話のみを行うようにします。このモデルの例については、MongoDB World 2022で紹介された「 real-time data architecture on Amazon EKS in AWS Wavelength .」をチェックしてください。この例では、ウェブアプリケーションにはJavaScriptを埋め込み、直接EDSと対話するサーバーレス関数を呼び出します。 結論 この記事では、エッジコンピューティング環境でEDSを使用して、地理的に分散した低遅延のアプリケーションに最適なエンドポイントを特定する方法を示しました。そして、AWSサーバーレスサービスがEDS APIを強化するアーキテクチャを紹介しました。さらに、EventBridgeとLambdaを介したサーバーレスワークフローが、Edge Discoveryアーキテクチャにエンドポイントを自動的に登録する方法も示しました。 エッジディスカバリは、エッジアプリケーションのウェルアーキテクチャーの重要なコンポーネントの1つです。詳しくは、 hands-on lab from re:Invent 2022 をチェックするか、re:Invent 2021の Verizon’s presentation on network intelligence セッションをご覧ください。 さあ、始めてみましょう。 Verizon EDS documentation または 5G Future Forum website をご覧いただき、Edge Specialist Sales Teamに質問してみてください。 著者について Robert Belson Robert は、AWS エッジコンピューティングを専門とする AWS ワールドワイドテレコムビジネスユニットのデベロッパーアドボケイトです。開発者コミュニティや大企業のお客様と協力して、自動化、ハイブリッドネットワーキング、エッジクラウドを使用してビジネス上の課題を解決することに重点を置いています。 本記事は、「 Deploying dynamic 5G Edge Discovery architectures with AWS Wavelength 」を翻訳したものです。 翻訳はソリューションアーキテクトの陳誠が担当しました。