このブログは、Gergely Cserdi と Akshay Parkhi が共同執筆しました。 はじめに SAP は 2027 年までに SAP HANA 以外のデータベースに対する 一般的なサポート を終了するため、近い将来、 SAP HANA は SAP システムの新規導入における唯一の選択可能なデータベースになります。特に多数の HANA インスタンスを運用しているお客様にとって、TCO を削減するためには、一貫性のある自動化された方法でデータベースのパッチを適用することが重要です。 多くの場合、HANA ノード間では HANA System Replication (HSR) が有効になっています。これを Pacemaker クラスタと組み合わせると、お客様のデータベースは HA アーキテクチャを実現できます。このような方法でデータベースをクラスタ化すると、HANA データベースにパッチを適用する nZDT (ほぼゼロのダウンタイム) 方式のメリットを受けることができます。このブログでは、クラスタ化された HANA ノードに nZDT パッチを適用する方法について説明し、Red Hat Enterprise Linux (RHEL) ベースのシステムでプロセス全体を自動化する Ansible プレイブックのサンプルも紹介します。 パッチ適用処理中のほとんどの時間においては、データベースは少なくとも 1 つのノードで使用が可能な状態です。クラスタを使用しない場合のパッチ適用については、SAP ヘルプサイトにかなり詳しく記載されていますが、HANA ノードがクラスタ構成の場合に nZDT パッチを実行する方法に関する情報は限られています。 図 1: ペースメーカーを使用した 2 ノードの HANA クラスタ構成 前提条件: 稼働中の HANA HSR クラスタペア ( AWS Launch Wizard を使えば、数時間で、完全に自動的に SAP HANAのクラスタ構成の構築ができます。詳細に関しては、 AWS Launch Wizard  ユーザガイド をご参照ください。) HANA パッチを適用する前に、必要な OS パッチ (ある場合) が適用されていること。詳細については、以下の情報をご確認ください。 OS に関して、BYOS の場合は“Red Hat Enterprise Linux for SAP Solutions”、またはAWS Marketplace の場合は“Red Hat Enterprise Linux for SAP with High Availability and Update Services” が必要です。サポートされている OS については、 OSS ノート 1631106 をご参照ください。また、Red Hat Enterprise Linux for SAP ソリューションサブスクリプションの ナレッジベース を参照することもできます。 root パスワードが必要で、まつ両方のノードで同じパスワードになっていることが必要です。この点に関するサポートが必要な場合は、チームの Linux 管理者に問い合わせてください。 SYSTEMDB と TENANT のために SYSTEM ユーザパスワードが必要です。この点に関しては、チームのデータベース管理者に問い合わせてください。 使用可能な Ansible インフラストラクチャーをお持ちで、HANA ノードでプレイブックを実行するように設定されていること。 必要な HANA のパッチパッケージが S3 バケットにあるか、ファイルシステムに保存されていること。 (オートメーション処理は両方からファイル取得可能) SAP HANA パッチソフトウェアは SAP Marketplace ソフトウェアダウンロードセンター からダウンロードします。(ダウンロードエリアにアクセスするには SAP Marketplace アカウントが必要) パッチファイルが Amazon S3 バケットに保存される場合、Amazon EC2 には、該当のバケットにアクセスできる IAM ロールが付与されていること。 手順 nZDT メソッドで HANA クラスタノードにパッチを適用する一般的なプロセスは以下になります。この例では、ノード 1 が現在プライマリノードで、ノード 2 がセカンダリノードであると仮定します。 * 注意 : 作業順番を守ることは重要です。 クラスタノード 2 をスタンバイモードに設定 スタンバイモードを有効にすると、指定したノードはリソースをホストできなくなります。制約が許せば、そのノードで現在アクティブなリソースがあれば、別のノードに移動されます。この場合、HANA インスタンスはセカンダリ役割であり、現在使用されているクラスタノード 1 はすでにプライマリインスタンスとなっているため、リソースはクラスタノード 1 に移動されません。 クラスタをメンテナンスモードに設定 クラスタ全体をメンテナンスモードにすると、クラスタがクラスタリソースを一切管理しなくなります。HANA のパッチ適用中に HANA サービスが断続的に停止し、そうしなけれ場クラスタが動作する可能性があるため、これは不可欠です。 ノード 2 の HANA パッチ適用 セカンダリノードで HANA にパッチを適用します。このステップは、データベースのソフトウェアバージョンを更新するための中心的な部分です。 図 2: セカンダリノードの HANA パッチ適用 パッチ適用プロセス中、セカンダリノードは一定期間使用できなくなります。ただし、プライマリノードは通常どおり稼働しており、SAP アプリケーションとユーザーにサービスを提供します。 ノード 2 をスタンバイモードから解除 このステップでは、クラスタノード 2 がクラスタで再び使用可能になり、リソースを受け入れられます。 クラスタのメンテナンスモードをオフ メンテナンスモードを無効にすると、クラスタはプライマリノードとセカンダリノードの間の HSR を自動的に再確立します。SAP はセカンダリノードをプライマリノードよりも高いパッチレベルに設定することをサポートしています。セカンダリノードはプライマリノードと同期される状態になります。 レプリケーションが再開され、正常に動作 この段階では、セカンダリノードがプライマリノードと完全に同期し、引き継ぐ準備が整うまで待つ必要があります (ステータス SOK)。 ノード 1 をスタンバイモードに設定 スタンバイモードでは、プライマリクラスタノードはリソースをホストできなくなり、プライマリ HANA の役割がノード 1 からノード 2 に引き継がれます。クラスタは現在のプライマリノードを降格させ、ノード 2 の HANA インスタンスを昇格させます。また、クラスタはオーバーレイ IP をノード 2 に移動し、ルートテーブルの更新を行います。これにより、SAP を引き継いだ後も、ユーザーは引き続き先の HANA データベースに接続できます。 図 3: テイクオーバー処理中にセカンダリノードが昇格 テイクオーバーが完了するまで待機 テイクオーバー処理には少し時間がかかります。ノード 1 にパッチを適用する前に、ノード 2 の HANA インスタンスが完全にプライマリ役割を引き継いでいることを確認する必要があります。 クラスタをメンテナンスモードに設定 クラスタがパッチ適用プロセスの妨げにならないようにするには、クラスタ全体をメンテナンスモードにする必要があります。 ノード 1 の HANA パッチ適用 この段階では、HANA DB はノード 2 でプライマリとして実行されており、SAP システムからの接続とユーザーからの接続を受け入れます。ノード 1 の HANA インスタンスにパッチを適用できるようになりました。 図 4 元のプライマリであったノード1へのパッチ適用し、現在はセカンダリノードがプライマリ役割 ノード 1 をスタンバイステータス解除 ノード 1 のパッチ適用が完了したら、スタンバイ状態から外すことで、クラスタノードとして再び有効にできます。 クラスタのメンテナンスモードをオフ クラスタがメンテナンスモードを終了すると、クラスタノード 1 で HANA インスタンスが起動していることを確認します。現在、クラスタノード 2 の HANA インスタンスにはプライマリ役割があるため、クラスタノード 1 の HANA インスタンスはセカンダリ役割として起動され、ノード 2 からノード 1 へのレプリケーションが開始されます。 図 5: パッチを適用した HANA ノード間で HSR を再確立 クラスタリソースを消去 メンテナンス作業中に、クラスタフレームワークでエラーやアラートが発生することがあります。クラスタを最初からやり直すには、これらをクリーンアップする必要があります。 まとめると、パッチ適用プロセス中は、テイクオーバー発生時に短時間停止する場合を除いて、常に少なくとも 1 つのノードでデータベースが使用可能である必要があります。注:プライマリとセカンダリは、最後に入れ替わります。これは正常であり、データベースの動作には影響しません。都合の良いときに元のトポロジーに 切り戻す ことができます。 プロセス全体を自動化する Ansible プレイブックのサンプルコードは、この 公開 github リポジトリ にあります。 Ansible プレイブックを実行するための準備 ターゲット HANA パッチ SAR ファイルを SAP Marketplace からダウンロードし、S3 バケットまたはサーバーのファイルシステムに配置します。S3 バケットまたはディレクトリに 1 つの SAR パッチファイル以外のファイルが含まれていないことを確認してください。以下は、パッチ HANA SP05 rev64 の SAR ファイルを格納している S3 バケットの例です。 図 6: HANA SAR ファイルを格納する Amazon S3 バケット リポジトリを Ansible コントローラーサーバーにコピー リポジトリをコピーする 1 つの方法は、git clone コマンドを使用することです。git コマンドに関しては参考情報のセクションをご確認ください。そのためには、まず git をインストールする必要があります。Linux への インストール方法 をご覧ください。 コピーしたリポジトリのディレクトリにアクセスし、インベントリファイルを作成し、「SAP_ <SID>_hana_ha」という名前のグループを作り、そのグループに 2 つの HANA ノード IP を追加します。たとえば、HANA SID が「HDB」、HANA ノード 1 の IP が 10.20.30.40、HANA ノード 2 の IP が 10.20.30.50 の場合、インベントリファイルの内容は次のようになります。 [SAP_HDB_hana_ha] 10.20.30.40 10.20.30.50 自動化ツールHANA パッチツール hdblcm を実行するには、複数の認証情報が必要になります。セキュリティ上のベストプラクティスとして、可変ファイルやその他の方法でパスワードを簡単に開示できないようにしてください。Ansible は、機密情報の暗号化に役立つ ansible-vault ツールを提供しています。HANA パッチを適用する Ansible プレイブックソリューションでは、以下の認証情報を含む「passvault.yml」というボールトファイルが必要です。 root ユーザパスワード 変数名: ROOTPWD <sid>adm ユーザパスワード 変数名: SIDADMPWD SYSTEM @ テナントパスワード 変数名: SYSTEMTNTPWD SYSTEM @ SYSTEMDB パスワード 変数名: SYSTEMDBPWD これらの認証情報を「passvault.yml」ファイルに追加すると、変数名や暗号化された値が格納されます。 たとえば、暗号化された root パスワードを passvault.yml ファイルに追加するには、次のコマンドを実行します。 ansible-vault encrypt_string ‘theactualpassword’ --name ‘ROOTPWD’ | tee -a passvault.yml 別の例として、SYSTEM DB の SYSTEM ユーザーの暗号化されたパスワードを passvault.yml ファイルに追加するには、次のコマンドを実行します。 ansible-vault encrypt_string ‘somepassword’ --name ‘SYSTEMDBPWD’ | tee -a passvault.yml パスワード変数を追加するときは、暗号化に同じボールトパスワードを使用してください。暗号化されたパスワードをすべて追加したら、ファイルの新しい行から始まるようにしてください。必要なパスワードをすべて追加すると、ファイルは次のようになるはずです。 [root@ip-***-***-***-*** sap-hana-update-cluster-nzdt]# cat passvault.yml SYSTEMDBPWD: !vault | $ANSIBLE_VAULT;1.1;AES256 35643964393039616161626666353862653038373434613533313566353134376364643337666539 6436623736323161613031663636356162633362353831620a393365646636653837636633623164 32623365313931303939323532393265613565643965393538393737353436366330636233646330 3265663163636366340a633734306136313839366431616562666162386633353035393764313833 3137 SYSTEMTNTPWD: !vault | $ANSIBLE_VAULT;1.1;AES256 39613736376436396361383939313637623435326232656163353863383138633230326166666334 3733653737646431373261313434353065646431343037370a333963643230313565653264643831 36393332386266333438326639346539316330303331393464663539653864353834656665346264 3134306666623765640a303733383031376131613438396436393334636166386233633966396432 3232 ROOTPWD: !vault | $ANSIBLE_VAULT;1.1;AES256 30323033336466663837623064343631376634316534316165316438306635636562633164653266 3331663837303932346237643165353062656165356562300a626363373134663635313962303363 37323531633737656239356438613838343665353530313939356530616631623561623733643236 6138653361316265650a386561366330303832346235383035346363633463663035383131623732 3438 SIDADMPWD: !vault | $ANSIBLE_VAULT;1.1;AES256 63633035656533316432353435376433393565623066643735326165313137396633323132363730 3562623132356439613533633536323563333738373931650a623964323966386634616466376631 37386564666337626630333338666264666365616263366531306162636539366461386135663263 3334373437643763380a316238373335653636323564363139376562616130396164613932633938 3361 [root@ip-***-***-***-*** sap-hana-update-cluster-nzdt]# ファイルの設定が完了したら、次の手順に進みます。 プレイブックを実行 ディレクトリをコピーしたリポジトリのルートに切り替え、以下のコマンドを実行します。 ansible-playbook -i <inventoryfile> --ask-vault-pass -e "SID=<SID>" -e "MEDIASRC=<s3/fs>" -e "MEDIALOC=<locationofSARfile" ./patch_sap_hana.yml たとえば、インベントリファイルが「myinventory」、HANA DB SID が「HDB」、メディアソースが S3 バケット「s3://hanapatch/」にある場合は、次の構文を使用します。 ansible-playbook -i myinventory --ask-vault-pass -e "SID=HDB" -e "MEDIASRC=s3" -e "MEDIALOC=s3://hanapatch/" ./patch_sap_hana.yml 別の例として、インベントリファイルが「myinventory」、HANA DB SID が「HDB」、メディアソースがファイルシステムから、SAR ファイルが /tmp/hanapatch/ にある場合は、次の構文を使用してください。 ansible-playbook -i myinventory --ask-vault-pass -e "SID=HDB" -e "MEDIASRC=fs" -e "MEDIALOC=/tmp/hanapatch/" ./patch_sap_hana.yml 自動化処理は、前述で説明した順序でノードにパッチを適用します。パッチ適用処理が終了すると、ノードの役割が入れ替われることに注意してください。ノードの元のロールは後でいつでも元に切り戻すことができます。パッチが適用されたことを確認するには、Ansible ログの末尾にある各 HANA ノードの新しいパッチバージョンを確認できます。 クリーンアップ Playbook が正常に実行されると、パスワードテンプレートファイルは自動的にクリーンアップされます。 プレイブックを実行した後も、再び必要になった場合に備えて、ソフトウェアは引き続き使用できます。不要になった場合は、アーカイブするか、単純に削除することをおすすめします。 コスト 2 つの HANA ノードのコスト以外に、自動化には Amazon EC2 インスタンス上で稼働する小さな Ansible 管理ノードが必要な場合があります。 HANA のパッチファイルを保存するために S3 バケットが必要です。一般的なパッチファイルは約 3 ～ 4 GB で、これは年間わずか数ドル (0.023$/GB /月) に相当します。 他の展開 SAP HANA HSR の概念 について詳しくは、SAP 公式ヘルプドキュメントをご覧ください。 HANA HSR に関するよくある質問に対するその他の回答については、 SAP Note 1999880 — FAQ: SAP HANA システムレプリケーションをご覧ください。 RHEL 上の HANA 用 SAP ペースメーカークラスタの詳細については、公式の SAP HANA on AWS ガイド をお読みください。 AWS 無料利用枠サービスを活用して、最小限のコストで SAP on AWS で Ansible を使用する方法を学ぶのに役立ちます。Amazon Linux 2 では AWS 無料利用枠 を使用して EC2 インスタンスを作成できます。このインスタンスは Ansible 管理ノード を実行するのに使用できます。 Ansible モジュールとコーディング技術について詳しくは、ansible の 公式ドキュメント をご覧ください。 結論 この例では、クラスタ化された HANA ノードの nZDT パッチ処理がどのようなものかを説明しました。また、プロセスを自動化する例の方法として、 Ansible プレイブックも提供しました。 図 7:  nZDT HANA のパッチ適用プロセス全体の概要ステップ AWS は HANA パッチ適用を自動化するための AWS Systems Manager ドキュメント (SSM ドキュメント) もサポートしていますが、クラスタノードはまだサポートされていないことに注意してください。 SLES ベースのシステムには、考え方は同じです。pcs コマンドをそれぞれ crm コマンドに置き換えるか、YAST モジュールを使用して処理することが可能です。 今後のアクション AWS Launch Wizard for SAP を使用して新しい HANA クラスタ構成を構築してみましょう。まず、 オンラインドキュメント をご確認ください。 無料利用枠の Amazon インスタンスに ansible をインストールし、公開リポジトリからサンプルコードのクローンを作成します。 HANA クラスタノードのロールを確認し、パッチを適用する前に HANA DB のバージョンを確認してください。 インベントリファイルと passvault.yaml ファイルを準備し、パッチ適用プレイブックを起動します。 HANA クラスタノードの役割をもう一度確認し、パッチ適用後に HANA DB のバージョンを確認します。現在、どのノードがプライマリになっているのかでしょうか？ 不要なコストを避けるため、テスト後は必ずリソースをクリーンアップしてください。 リファレンス 公式 SAP ページにある SAP HANA システムレプリケーションによる SAP HANA システムのアップデート Near Zero Downtime Upgrades のために、SAP HANA システムレプリケーションの使用 AWS Launch Wizard YAST モジュールを使用した HANA クラスタの SLES nZDT パッチ適用 Git クローンコマンドの リファレンス 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。

AWS Launch Wizard for SAP API による SAP 環境構築の自動化 AWS Launch Wizard は、オンプレミスで数週間から数カ月かかる HANA ベースの SAP アプリケーションの環境構築を、わずか数時間で、安全で高性能、復元力があり、効率的に、AWS に構築するための完全に自動化されたプロセスをお客様に提供します。AWS Launch Wizard for SAP サービスは、 AWS 、SAP、および使う OS のベストプラクティスに従って、SAP アプリケーションと SAP HANA データベースのインストールと設定に必要なすべての AWS リソースをプロビジョニングします。 Nvidia 、 UNOX 、 Storengy などのお客様は、AWS Launch Wizard を利用して SAP 環境の移行を加速させています。 2020 年 4 月のサービス一般提供開始以来、AWS for SAP チームはお客様やパートナー様からのフィードバックに耳を傾け、AWS Launch Wizard サービスを継続的に改善してきました。そのフィードバックに基づいて、SAP アプリケーションソフトウェアの自動構築、構築前/構築後のスクリプトによるカスタマイズされたデプロイ、AWS サービスカタログとの統合など、いくつかの重要な改善を行いました。さらに、Launch Wizard チームは、AWS、SAP、およびオペレーティングシステムの最新機能を活用した新機能を継続的に提供しています。これにより、SAP アプリケーションのあらゆる階層で最新のイノベーションを活用することができ、お客様の投資が将来にわたって保護されます。 お客様から最も要望の多かった機能の 1 つは、AWS Launch Wizard を既存の導入ツールやスクリプトと統合できることです。お客様がアプリケーション・プログラミング・インターフェース・コール（API）を使用して、AWS管理コンソールにログインすることなく、プログラマティックでSAPシステムをデプロイできるようになったことを11月初旬に 発表 しました。 このブログでは、SAP S/4HANA システムをプログラマティックでデプロイが可能にする新しい AWS Launch Wizard API について詳しく説明します。 AWS Launch Wizard API 概要 AWS Launch Wizard API を使用すると、以下のアクションが実行可能となります。 CreateDeployment: 指定された設定でワークロードをデプロイします。 ListDeployments: 作成されたデプロイメントを一覧表示します。 GetDeployment: 特定のデプロイメントに関する詳細情報を取得します。 DeleteDeployment:特定のデプロイメントを削除します。 ListDeploymentEvents:デプロイ中に実行されているすべてのアクションを一覧表示します。 ListWorkloads: AWS Launch Wizard がサポートしている利用可能なすべてのワークロードを一覧表示します。 ListWorkloadDeploymentPatterns: 特定のワークロードのすべてのデプロイパターンを一覧表示します。 GetWorkload: 特定のワークロードに関する詳細情報を取得します。 デプロイメントの仕様 デプロイ仕様は、ニーズに応じてアプリケーションをデプロイするための情報提供に使用します。デプロイ仕様で、Amazon Virtual Private Cloud、サブネット、セキュリティグループなどのインフラストラクチャ関連の仕様や、構築予定の SAP システムの SID、SAP ソフトウェアおよびバージョンなどのアプリケーション仕様を提供します。 こちらのURL に記載されているように、サポートされているデプロイパターン毎に、異なる仕様が必要となります。AWS Launch Wizard API は、SAP HANA データベースと NetWeaver ベースのアプリケーションの以下のデプロイパターンをサポートします。 SAP HANA SAP HANA データベース、は以下のデプロイパターンがサポートされています。 SAP HANA 高可用性構成 SAP HANA マルチノード SAP HANA シングルノード SAP アプリケーション SAP S/4HANA、SAP S/4 Foundations、SAP Solution Manager、SAP BW/4HANA、NetWeaver ABAP や Java などの SAP NetWeaver ベースのアプリケーションでは、以下のデプロイパターンがサポートされています。 高可用性構成 マルチノード/分散構成 シングルノード/セントラル構成 ユースケース AWS Launch Wizard API の発表により、Launch Wizard サービスが、単なるコンソールベースのサービスから強化されます。これらの API によって、SAP アプリケーションをデプロイするために、オペレータや管理者がコンソールを操作する必要がなくなります。最初のテスト/検証作業を行えば、その後人の操作を全く介在せずにデプロイを実現できます。Launch Wizard API を活用できるユースケースをいくつかご紹介します。 SAP のデプロイをさらにスピードアップ: SAPアプリケーションを迅速にプロビジョニングするために、SID、インスタンス番号、サイジングなどのパラメータを微調整できる自動化ルーチンを構築します。 障害復旧プロセスの最適化: 災害復旧のテスト/イベント中に、ベースラインシステムのプロビジョニングに使用できるテンプレートを構築することで、Launch Wizard API を災害復旧計画の一部として活用できます。これらのテンプレートは DR プロセスに一貫性と再現性をもたらし、コンソールを使用して手動でシステムを導入する際に発生する可能なミスを削減します。 一時的または N+1 ランドスケープ設定: AWS Launch Wizard for SAP API を活用して、一時的なプロジェクト環境または永続的な N+1 環境を立ち上げながら、SAP システムのデプロイプロセスを加速できます。 例：AWS Launch Wizard for SAP API を使用した SAP S/4HANA デプロイ この例では、 AWS Command Line Interface (AWS CLI) を使用して AWS Launch Wizard for SAP API を呼出し、ABAP SAP セントラルサービス (ASCS)、プライマリアプリケーションサーバー (PAS)、SAP HANA データベースを含む SAP S/4HANA システムを、単一の EC2 インスタンスに構築します。 前提条件: AWS アカウント AWS CLI をインストールして設定 (この ドキュメント を参照)。最低限必要なバージョンは AWS CLI バージョン2 です。 AWS Launch Wizard for SAP の一般的な条件と IAM 前提条件を設定完了 (この ドキュメント を参照) SAP アプリケーションとデータベースのインストールメディアをダウンロードして準備 (この ドキュメント を参照) ステップ 1: デプロイメント仕様ファイルの準備 AWS Launch Wizard for SAP API は、JSON 形式のファイルを使用して、通常は AWS コンソールから入力されるデプロイに関する設定値を定義します。デプロイパターンに基づいて、SAP アプリケーションを構成するために必要なパラメータリストについては、 SAP デプロイ仕様 を参照してください。 { "KeyPairName": "ExampleKeyPair", "VpcId": "vpc-a1b2c3d4", "AvailabilityZone1PrivateSubnet1Id": "subnet-11111111aaaaaaaaa", "Timezone" :"PST", "EnableEbsVolumeEncryption" :"Yes", "EbsKmsKeyArn" : "arn:aws:kms:us-east-1:111122223333:alias/aws/ebs", "CreateSecurityGroup" :"No", "DatabaseSecurityGroupId" :"sg-1234567890abcdef0", "ApplicationSecurityGroupId" :"sg-021345abcdef6789", "SidAdmUserId" :"7002", "SapSysGroupId" :"5001", "DatabaseSystemId" :"HYD", "SapSid" :"S4K", "ApplicationDataVolumeType" :"gp2", "DatabaseInstanceNumber" :"30", "InstallAwsBackintAgent" :"Yes", "BackintSpecifications": "{\"backintBucketName\":\"launchwizardsoftware\",\"backintBucketFolder\":\"HANABackintBucketFolder\",\"backintBucketRegion\":\"us-east-1\",\"backintKmsKeyArn\":\"arn:aws:kms:us-east-1:111122223333:alias/aws/s3\",\"backintAgentVersion\":\"2.0.2.732\",\"backintContinueOnFailure\":\"No\",\"backintCreateEbsVolume\":\"No\"}", "CentralSystemOperatingSystem" :"SuSE-Linux-15-SP2-For-SAP-HVM", "CentralSystemAmiId" :"ami-1234567890abcdef0", "CentralSystemInstanceType" :"r5.8xlarge", "CentralSystemHostname" :"apis4sin", "SapPassword" :"EXAMPLE-PASSWORD", "DatabaseLogVolumeType" :"io2", "SetupTransportDomainController" :"Yes", "InstallSap" :"Yes", "SapInstallationSpecifications": "{\"parameters\":{\"PRODUCT_ID\":\"saps4hana-2021\",\"HDB_SCHEMA_NAME\":\"SAPABAP1\",\"CI_INSTANCE_NR\":\"22\",\"ASCS_INSTANCE_NR\":\"20\",\"SAPINST_CD_SAPCAR\":\"s3:\/\/launchwizardsoftware\/sapmedia\/sapcar\",\"SAPINST_CD_SWPM\":\"s3:\/\/launchwizardsoftware\/sapmedia\/swpm\/20-sp10\",\"SAPINST_CD_KERNEL\":\"s3:\/\/launchwizardsoftware\/sapmedia\/kernel\/785\",\"SAPINST_CD_LOAD\":\"s3:\/\/launchwizardsoftware\/sapmedia\/exports\/s4h-2021\",\"SAPINST_CD_RDBMS\":\"s3:\/\/launchwizardsoftware\/sapmedia\/database\/hana-20-sp06-rev60\",\"SAPINST_CD_RDBMS_CLIENT\":\"s3:\/\/launchwizardsoftware\/sapmedia\/hana-client\/20-11\"}, \"onFailureBehaviour\": \"CONTINUE\"}", "SnsTopicArn" :"arn:aws:sns:us-east-1:111122223333:InstallStatus", "SaveDeploymentArtifacts" :"Yes", "DeploymentArtifactsS3Uri" :"s3://launchwizardsoftware", "DisableDeploymentRollback" :"Yes", "CentralSystemAutomaticRecovery": "Yes", "DatabaseDataVolumeType": "gp3" } ステップ 2: デプロイメント仕様の検証 デプロイを実行する前に、 create deployment アクションのオプションの dry-run フラグを使用して仕様を検証し、アクションに必要な権限があるかどうかを確認できます。 // Example command values aws launchwizard create-deployment \ --workload-name SAP \ --deployment-pattern-name SapNWOnHanaSingle --name S4HanaSingleTest \ --dry-run \ --region us-east-1 \ --specifications file://s4hana-single.json デプロイに問題がない場合は、次のメッセージが表示されるはずです。 // Example JSON response { "deploymentId": "Dry run is successful" } ステップ 3: デプロイを実行開始 dry-run フラグでデプロイ仕様を検証した後、—no-dry-run フラグを使用して実際のデプロイメントを開始します。 // Example command with sample values aws launchwizard create-deployment \ --workload-name SAP \ --deployment-pattern-name SapNWOnHanaSingle --name S4HanaSingleTest \ --no-dry-run \ --region us-east-1 \ --specifications file://s4hana-single.json 以下に示すようにデプロイメント ID を取得し、後でこの ID をを使用してデプロイメントの進行状況を確認することができます。 // Example JSON response { "deploymentId": "72c26320-6d17-4e55-992c-b3ad8d47331d" } ステップ 4 — デプロイメントのステータスを確認 list-deployment-events アクションを使用してイベントを一覧表示し、デプロイメントのステータスを確認できます。 // Example command values aws launchwizard list-deployment-events \ --deployment-id 72c26320-6d17-4e55-992c-b3ad8d47331d \ --region us-east-1 以下のスクリーンショットは、 list-deployments-events API コマンドの JSON レスポンスのサンプルです。 // Example JSON response { "deploymentEvents": [ { "name": "Validate Resource Limits (CFN, VPC, EIP, IGW)", "description": "Validate Resource Limits (CFN, VPC, EIP, IGW)", "status": "Completed", "statusReason": "Resource limit validation completed successfully", "timestamp": "2023-10-26T12:18:34.721000-04:00“ }, { "name": "Create resource group", "description": "Creates a resource group with all the application resources", "status": "COMPLETED", "statusReason": "", "timestamp": "2023-10-26T12:18:32.937000-04:00" }, { "name": "Create secret", "description": "Creates a new secret", "status": "COMPLETED", "statusReason": "", "timestamp": "2023-10-26T12:18:33.392000-04:00" }, { "name": "Creates the infrastructure for the application deployment", "description": "Creates the infrastructure for the application deployment", "status": "IN_PROGRESS", "statusReason": "", "timestamp": "2023-10-26T12:19:52.694000-04:00" } ] } デプロイメントが正常に完了すると、API コマンド list-deployments を使用してデプロイメントのステータスを取得できます。 // Example command values aws launchwizard list-deployments \ --region us-east-1 以下のスクリーンショットは、 list-deployments API コマンドの JSON レスポンスのサンプルです。 // Example JSON response { "deployments": [ { "name": "S4HanaSingleTest", "id": "a572f36c-5b06-4fb5-932c-61e684ca3159", "workloadName": "SAP", "patternName": "SapNWOnHanaSingle", "workloadVersionName": "2023-10-26-00-00-00", "status": "COMPLETED", "createdAt": "2023-10-26T22:02:39.413000-05:00" } ] } トラブルシューティング AWS Launch Wizard for SAP のトラブルシューティングについては、 AWS Launch Wizard トラブルシューティングガイド を参照してください。 まとめ このブログでは、AWS Launch Wizard for SAP API を使用して、プログラムで SAP システムを AWS にデプロイする方法について学びました。この新機能を使用することにより、AWS Launch Wizard for SAP コンソールにアクセスしたり、デプロイのステップを手動で画面設定したりする必要がなくなります。詳細については、 AWS Launch Wizard の詳細ページ と ドキュメント をご覧ください。 AWS re: Invent 2023 に参加される方は、 ENT312 — Deploy and optimize SAP on AWS with DevOps で、 AWS Launch Wizard APIを使用して、SAP S/4HANA システムの高可用性構成をいかに簡単に構築、スケーリングできるかをご覧ください。このセッションで、AWS for SAP のエキスパートがプロセスのステップを説明し、AWS での SAP システムの稼働に関する質問にお答えします。 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。

e コマースサイトは、機敏で正確、そして何よりもユーザーフレンドリーであるべきです。しかし、e コマースサイトの検索パフォーマンスの歴史は、顧客と小売業者のどちらも満足させていない現実を物語っています。 Baymard Institute によると、「全 e コマースサイトのうち 61％ が、 ユーザーの検索語句にそぐわない検索結果を表示している」ため、顧客は新しい検索語句を入力するか、古い検索語句を完全に放棄せざるを得ないのです。 Forrester によると、 「商品の検索体験全体に対するイライラによって、 約 68％ という許容できないほどの解約や離脱を引き起こされている」といいます。 Z 世代がより速く（そしてより正確な）検索結果を求める中、e コマース企業は検索をモダナイズしなければならないという重圧を感じていますが、行動に移している企業はほとんどありません。この失敗をそのままにしてしまうと、イノベーションだけでなく、売上においても競合他社に遅れをとるという深刻なリスクを負うことになります。 このブログでは、なぜ小売業者がキーワード検索の品質のために機会損失してしまうのかと、どのようにして Amazon Web Services（ AWS ）が自然言語処理（ NLP ）を用いて、 e コマース企業の収益向上を支援できるのかを述べます。 キーワード検索の課題 すべてのオンライン顧客が買い物中に検索バーを利用するわけではないですが、50％ 近くは利用しています。 Forrester は、2022 年のロードマップレポート ” Must-Have E-Commerce Features ” にて、「小売ウェブサイトユーザーの 43% は、初めてウェブサイトにアクセスした際に、まずは検索バーで検索することから始める」ということです。このことから、検索結果に重点を置くことは、顧客との関係を維持する上でさらに重要になります。しかしながら、検索結果に重点を置くことはそれほど簡単ではありません。なぜなら、ほとんどの検索エンジンは自然言語を理解しないからです。 例えば、あなたが赤いドレスシャツを探しているとしましょう。あなたはお気に入りのウェブサイトを立ち上げ、検索バーに「男性 赤い ドレスシャツ」と入力します。そうすると、検索エンジンはあなたが書き込んだ内容を理解しようとします。しかし、キーワード検索エンジンは、キーワードをそれぞれ個別の用語としてしか理解できないため、必要な情報以外の入力は、ズレた検索結果を導いてしまう可能性があります。赤いドレスシャツの検索結果の代わりに、検索エンジンは 「ドレスシャツ 」ではなく、ドレスやシャツの検索結果を返すかもしれません。これを変えるには、検索エンジンが検索語句を一つの用語として理解する必要があります。言い換えれば、ユーザーの意図を理解する必要があるのです。 キーワード検索によくある課題として、タイプミス、同義語と方言、特徴検索、フィルター検索、コンテキスト検索、テーマ検索があります。 タイプミス： 検索したい単語を誤ってスペルミスしてしまうことです。例えば、「 sweater 」と入力すべきところを 「 sweeter 」と入力することです。 同義語と方言： 地域によって異なる意味を持つ単語を検索することです。例えば、「 sunglasses 」ではなく、「 shades 」と検索してしまい、全く異なる検索結果を得ることがあります。 例：multi-billion-dollar retailer – 「 mens sunglasses 」の代わりに 「 mens shades 」で検索した結果 特徴検索： ユーザーが特定の特徴を持つ商品を検索することです。例えば、「 strap sandal 」と検索した際に、キーワード検索エンジンが理解できるのはキーワードだけで、ユーザーの意図は理解できないので、商品説明にはサンダルとストラップが使用されていても、検索エンジンは検索語句と同一と認識できず、検索結果は 0 件と返します。 フィルター検索： ユーザーが商品の属性で検索することです。例えば、$ 30 未満のイヤリング、青色の靴下、ポリエステルの椅子張りカバーなどと検索します。 例：multi-billion-dollar retailer – 「 Earrings Under 30 」 の検索結果として関連のないアイテムが表示されてしまう コンテキスト検索： ユーザーが特定の商品ではなく、コンテキストに基づいて何かを検索することです。例えば、「すきま風対策」や「寒さ対策」と検索して、どんな商品が結果に出てくるかを確認するような場合です。コンテキスト検索は、小売業者にとって最も困難なものになります。なぜなら、コンテキスト検索では、ユーザーが存在しないキーワードを検索していることが多く、その結果、検索結果が 0 件になったり、関連した検索結果が 0 件になるからです。 テーマ検索： ユーザーがテーマ別のカテゴリーで商品を検索することです。例えば、特定の種類のラグを探している人は、単に 「ラグ」と検索するのではなく、「廊下用ラグ」と検索するかもしれません。 例：multi-billion-dollar retailer – 「 rug 」 の代わりに 「 hallway rug 」 で検索した結果 Baymard Institute は、「ユーザーの観点では、これらの日常的な表現は業界用語と同じように正しいと思っており、大規模テストの参加者のほとんどは、検索結果が悪かったときに別の類義語を試そうとは思わなかった」と述べています。「その代わりに、検索結果が悪かったり、限定的だったりするのは、そのサイトがそのような商品を選んでいるからだと参加者は単に思い込んでいました。」 機会損失を回避しましょう 顧客と小売業者にとって、検索の問題はイライラさせられるものですし、ショッピング体験の全体的な質を低下させています。しかも、小売業者は、この問題から顧客の体験と企業の財務の両面で悪影響を受けます。もし、顧客が探している商品を見つけられなければ、小売業者は多くの収益を失うことになるからです。 数字を見てみましょう。 Econsultancy の調査によると、e コマースの平均コンバージョン率は 2.77% です。しかし、顧客が検索バーを使って探していた商品を見つけると、平均コンバージョン率は 4.63% に上昇します。これは e コマースの平均コンバージョン率のほぼ 2 倍です。 Amazon.com で検索された場合、この数字はさらに上昇します。毎回 Amazon.com で検索し、探していた商品を見つけると、 コンバージョン率は 6 倍に上昇 します。つまり、かつては 2％ だったコンバージョン率が 12％ になります。このパーセンテージを収益に換算すると、e コマース企業にとって財務的に大きな改善です。 e コマース検索の改善を AWS はどのように支援できるのでしょうか？ AWS は、Amazon Comprehend 、Amazon Kendra 、Amazon Textract 、Amazon OpenSearch Service といった人工知能と機械学習（ AI/ML ）サービスを提供しています。これらのサービスを利用することで、e コマース検索を改善することができます。 Amazon Comprehend は、機械学習を使用してテキストの意味、洞察、つながりを見つける自然言語処理サービスです。このサービスにより、あなたの検索エンジンはキーフレーズ、エンティティ、感情をインデックス化し、検索パフォーマンスを向上させることができます。Amazon Comprehend は時間をかけて学習し、ドキュメント、カスタマーサポートチケット、商品レビュー、メール、ソーシャルメディアへの投稿といったテキスト情報から貴重な洞察を発見します。Amazon Comprehend を使用することで、ユーザーは次のことができるようになります： ビジネスの分析とコールセンターの分析： 顧客アンケートから洞察を引き出し、商品を改善します。 商品レビューのインデックス化と検索： キーワードだけでなく、キーフレーズ、エンティティ、感情をインデックス化した検索エンジンを用いることで、コンテキストに焦点を当てます。 Amazon Kendra は、自然言語を理解する ML ベースのインテリジェント検索エンジンです。このインテリジェントなエンタープライズ検索サービスは、組み込みのコネクタを使用して、さまざまなコンテンツリポジトリを横断して検索することができ、機械学習の専門知識がなくても、ユーザーに高い精度の回答を提供します。 Amazon Textract は、スキャンした文書からテキスト、手書き文字、データを手作業なしで自動的かつ正確に抽出でき、すぐに使える ML サービスです。業種を問わず、データを整理し、元のコンテキストを保ち、出力結果のマニュアルレビューを省くために、Amazon Textract を利用できます。 Amazon OpenSearch Service はオープンソースの分散型検索・分析スイートで、インタラクティブなログ分析、ニアリアルタイムのアプリケーション監視、ウェブサイト検索を実行できます。OpenSearch Service を使用すると、ユーザーはアプリケーション、ウェブサイト、データレイクカタログ内で、高速かつパーソナライズされた検索により、関連するデータをすばやく見つけることができます。 結論 何十億ドルもの売上があるにもかかわらず、小売業者は検索パフォーマンスの低さによって収益を失っています。しかし、そのままにしておくのは勿体ありません。Amazon Comprehend 、Amazon Kendra 、Amazon Textract 、Amazon OpenSearch Service といった AWS サービスを利用することで、この問題を解消することができます。これらのサービスにより、小売業者は強力で改善された検索体験を生み出すことができるため、最終的には、収益の減少ではなく、収益の増加に集中することができます。 AWS の AI/ML サービス を利用して小売業の検索パフォーマンスを改善し、収益を増加させる方法をご覧ください。 消費財業界向けの AWS の取り組みについては こちら から詳細をご覧ください。または、 AWS 担当者 にお問い合わせください。 参考リンク Building Blocks for Modern Retail Ecommerce and Media Search with AWS Amazon OpenSearch Service と Amazon Comprehend を使用したテキスト分析 Building an NLU-powered search application with Amazon SageMaker and Amazon Opensearch Service KNN feature 著者について Aditya Pendyala Aditya はニューヨークを拠点とする AWS のシニアソリューションアーキテクトです。クラウドベースのアプリケーションのアーキテクトとして豊富な経験があります。現在、大企業と協業し、拡張性、柔軟性、耐障害性に優れたクラウドアーキテクチャの構築を支援するとともに、クラウドに関するあらゆることを案内しています。Shippensburg University でコンピューターサイエンスの理学修士号を取得し、 “When you cease to learn, you cease to grow “という言葉を信条としています。 Siddharth Pasumarthy Siddharth はニューヨークを拠点とする AWS のソリューションアーキテクトです。ファッションやアパレル業界の小売企業の顧客と協業し、クラウドへの移行や最先端技術の導入を支援しています。Indian Institute of Technology で建築学の学士号、Kelley School of Business で情報システムの修士号を取得しました。最新のテクノロジーに精通するだけでなく、芸術にも情熱を注いでおり、余暇にはアクリル画の静物画を制作しています。 翻訳は Solutions Architect 金成が担当しました。原文は こちら です。

こちらの Blog は、 Accelerate connected vehicle deployment with the Connected Mobility Solution on AWS  を翻訳したものです。 AWS は、オートモーティブクラウド開発者ポータル (ACDP) の追加を含む、 Connected Mobility Solution (CMS) の大幅な改善をお知らせできることを嬉しく思います。本改善には、高度な DevOps 機能、Cloud Formation や Cloud Developer Kit ( CDK ) などのデプロイツール、コネクテッド車両プラットフォーム (CVP) の開発と運用監視の改善に役立つ新しいプラグインとメトリックスが含まれます。重要なのは、 OTA やライフサイクル管理など、車両のリモート機能を、堅牢なコントロールプレーンを通じて、より適切に管理できるようになったことです。 CMS 内の ACDP (下図 1 参照: CMS on AWS — ACDP) は、CVP 開発者の包括的なハブとして機能します。これにより、CVP (下記の図 2: AWS 上の CMS — CVP アーキテクチャ) アセットのコラボレーション、デプロイ、運用を効率化できます。ACDP は、CVP に必要なツール、ドキュメント、指標を統合するように設計されているため、開発者は質の高いソリューションの提供に集中できます。これには、インフラストラクチャモジュール、再利用可能なコードコンポーネントのデプロイ、デプロイ可能なコードアセットの管理が含まれます。 ACDP を使用すると、お客様はコネクテッドカーのコンポーネントをよりシンプルで安全な方法で導入できます。たとえば、ACDP は、わかりやすい車両オンボーディング、データの標準化と保存のための統合データプレーン、データの異常や閾値違反に対する警告システムなどの機能を顧客に提供しています。さらに、ユーザーは車両管理ポータルと車両テレメトリーシミュレーターの恩恵を受けることができます。 図 1 : CMS on AWS — ACDP 図 2 : CMS on AWS — CVP アーキテクチャ モジュール式で直感的な CMS は、スケーラビリティと顧客による使いやすさを考慮して設計されています。これは、お客様がコネクテッドモビリティ機能を安全かつ効率的に導入および管理できるように設計されています。自動車メーカー、サプライヤー、モビリティテクノロジープロバイダーは CMS を使用して、コネクテッドビークルのデータに基づいて車両管理や車両のパーソナライズなどのサービスを提供できます。また、CMS は、開発者エクスペリエンスに重点を置いたプラットフォームエンジニアリングアプローチを通じて、コストの最適化、市場投入までの時間の短縮、開発者の作業負荷の軽減など、自動車業界のお客様が直面する主要な課題にも対処します。 業界レポート によると、このような優れた設計のプラットフォームは、最大 25% のコスト削減、40% の生産性向上、市場投入までの時間の 50% 短縮につながります。 注目すべき例としては、 同様のプラットフォーム を実装したトヨタが挙げられます。トヨタは、市場投入までの時間を大幅に短縮し、年間コストを 500 万ドル以上削減しました。 コストと開発時間を抑えながら、消費者の高まるデジタル期待に応えるため、AWS は新しい CMS を導入しました。AWS 自動車および製造部門のソリューションおよび GTM ディレクターである Bill Foyは、「このソリューションにより、お客様は自社またはパートナーのソリューションを革新し、より効率的にデプロイできるようになります」と強調しています。 CMS on AWS が一般公開されました。開始するには、 AWS Connected Mobility Solution をご覧ください。

お客様がコンタクトセンターを管理しているなら、組織が顧客の信頼とロイヤルティを構築する上でエージェントが重要な役割を果たしていることをご存知でしょう。コンタクトセンターに連絡したことがある人なら、エージェントが複雑な意思決定を導き、必要に応じて迅速かつ正確なソリューションを提供することがいかに重要であるかを知っています。これには時間がかかり、正しく行わないとフラストレーションがたまる可能性があります。 Amazon Connect の生成系 AI 機能 本日、 Amazon Connect の既存の人工知能 (AI) 機能に、 Amazon Bedrock を通じて利用できる大規模言語モデル (LLM) を活用した生成系 AI 機能が加わり、コンタクトセンターが顧客にサービスを提供する方法が劇的に変わったことをお知らせします。LLM は、一般に基盤モデル (FM) と呼ばれる膨大な量のデータについて事前にトレーニングされており、テキストを理解、学習、生成し、インタラクティブな会話を行い、質問に回答し、ダイアログやドキュメントを要約し、レコメンデーションを提供することができます。 Amazon Q in Connect: カスタマーサポートを迅速に行うための推奨される回答とアクション 組織は常に変化しています。こうした組織の変化に対応する高いレベルのパフォーマンスを維持するために、コンタクトセンターはエージェントのオンボーディング、トレーニング、コーチングを継続的に行っています。トレーニングやコーチングを受けたとしても、エージェントは顧客に優れたサービスを提供するために、製品ガイドや組織のポリシーなど、さまざまな情報源を検索しなければならないことがよくあります。これにより、顧客の待ち時間が長くなり、顧客満足度が低下し、コンタクトセンターのコストが増加する可能性があります。 Amazon Q in Connect は、生成系 AI を活用したエージェントアシスタントで、以前は Amazon Connect Wisdom として提供されていた機能を備えています。顧客の意図を理解し、関連する情報源を使用して正確な応答とアクションを行い、エージェントが顧客固有のニーズを伝え、解決するためのアクションをすべてリアルタイムで提供します。2024 年 3 月 1 日まで、Amazon Q in Connect を無料でお試しいただけます。この機能は簡単に有効にでき、Amazon Connect コンソールから始めることができます。 Amazon Connect Contact Lens: 生産性向上のためのコンタクト後の要約生成機能 顧客とのやり取りを改善し、詳細を後で参照できるようにするために、コンタクトセンターのマネージャーは、顧客とのやり取りのたびにエージェントが手動で作成するメモを活用しています。これらのメモには、顧客の問題への対処方法、会話の重要な場面、保留中のフォローアップ項目に関する詳細が含まれています。 Amazon Connect Contact Lens では、生成系 AI を活用したコンタクト後の要約作成が行えるようになり、コンタクトセンターのマネージャーがより効率的にモニタリングできるようになり、コンタクトの質とエージェントのパフォーマンスの向上を支援できるようになりました。例えば、要約を使用して顧客へのコミットメントを追跡し、フォローアップアクションが迅速に完了したことを確認できます。顧客とのやり取りの直後に、Contact Lens は会話を簡潔でまとまりのある要約にまとめることができるようになりました。 Amazon Connect の Amazon Lex: アシスト付きスロット解決 Amazon Lex を使用して、以前よりチャットボット、仮想エージェント、対話型音声応答 (IVR) を構築できました。これにより、顧客は人間のエージェントに話しかけることなく予定を立てることができます。例えば、「自分と 2 人の子供の旅行予約を変更する必要がある」というのは、従来のボットでは数値 (旅行予約に何人いるのか?) を把握して解決するのが難しい場合もあるでしょう。 新しいアシスト付きスロット解決機能により、Amazon Lex はユーザーの発話のスロット値を非常に正確に解決できるようになりました (例えば、3 という正しい数値を使って前の質問に回答するなど)。これは、精度を向上させ、より良い顧客体験を提供する LLM の高度な推論機能によって支えられています。より良いセルフサービス体験を構築するのに役立つ生成系 AI を利用した新しい機能など、 Amazon Lex のすべての機能をご覧ください。 Amazon Connect Customer Profiles: 統一された顧客プロファイルをより迅速に作成して、パーソナライズされた顧客体験を実現 顧客はパーソナライズされたカスタマーサービスエクスペリエンスを期待しています。これを実現するために、コンタクトセンターは顧客の好み、購入状況、やり取りを包括的に理解する必要があります。これを実現するために、コンタクトセンターの管理者は、複数のアプリケーションからの顧客データをマージして、統合された顧客プロファイルを作成しています。これらのアプリケーションにはそれぞれ、さまざまなタイプの顧客データがさまざまなデータストアにわたってさまざまな形式で保存されています。これらのさまざまなデータストアからのデータをつなぎ合わせるには、コンタクトセンターの管理者がデータを理解し、それを整理して統合された形式にまとめる方法を考え出す必要があります。これを実現するために、コンタクトセンターの管理者は何週間もかけて一つの顧客プロファイルにまとめています。 本日より、 Amazon Connect Customer Profiles は LLM を使用して、統合された顧客プロファイルの作成に必要な時間を短縮できます。コンタクトセンターの管理者が Amazon Simple Storage Service (Amazon S3) 、Adobe Analytics、Salesforce、ServiceNow、Zendesk などのデータソースを追加すると、Customer Profiles はデータを分析して、データ形式と内容が何を表し、データが顧客プロファイルとどのように関連しているかを理解します。次に、Customer Profiles は、さまざまなソースからのデータを整理して組み合わせて完全で正確なプロファイルにする方法を自動的に決定します。ほんの数ステップで、マネージャーは顧客プロファイルの確認、必要な編集、設定を完了できます。 Amazon Connect のアプリケーション内、ウェブ、動画機能 組織としては、使いやすく便利で優れたカスタマーサービスを提供したいと考えていることでしょう。この記事の前半で、セルフサービスチャットボットと、それがどのように役立つかについて説明しました。顧客は往々にして、チャットボットを超えて、エージェントとの音声会話を行いたいと思うことがあります。 Amazon Connect には、豊富でパーソナライズされたカスタマーエクスペリエンスを提供するのに役立つアプリ内機能、ウェブ機能、ビデオ機能が搭載されています (詳細については、 Amazon Lex の機能を参照 )。フルマネージド型の通信ウィジェットを使用すれば、数行のコードを記述するだけで、これらの機能をウェブアプリケーションやモバイルアプリケーションに実装できます。これにより、顧客はページを離れることなく、ウェブまたはモバイルアプリケーションからサポートを受けることができます。ビデオは、エージェントのみ、顧客のみ、またはエージェントと顧客の両方が有効化できます。 Amazon Connect SMS: 双方向 SMS 機能 ほとんどの人がモバイルデバイスを所有しており、外出先でもテキストベースのサポートを受けられる柔軟性が重宝されています。コンタクトセンターのリーダーはこのことを知っており、これまで、顧客に双方向の SMS を提供するために、接続されていないサードパーティーのソリューションに頼っていました。 Amazon Connect には現在、コンタクトセンターのリーダーがこの柔軟性を提供できるように、双方向の SMS 機能が搭載されています (詳細については、 Amazon Lex の機能 を参照してください)。これにより、コストのかかるサードパーティーソリューションとの統合なしに、顧客満足度を高め、エージェントの生産性を向上させることができます。SMS チャットは、通話やチャットと同じ設定、 Amazon Connect エージェントワークスペース 、分析を使用して有効にできます。 詳細はこちら Amazon Q in Connect 製品ページ Amazon Amazon Connect の開始方法 ユーザーガイド フィードバックを送信する AWS re:Post for Amazon Connect 、または通常の AWS サポート窓口を通じて – Veliswa 原文は こちら です。

AWS は発足から 3 年目を迎えたデジタル庁と、ガバメントクラウドの加速を継続して支援します 急ピッチでデジタル化を進める日本の政府、自治体、企業、スタートアップ 私たちアマゾン ウェブ サービス（以下、AWS）は、クラウドを中核としたデジタル技術には、社会の課題や困難を突破する力が備わっていると考えています。なぜならば、クラウドによって誰もが高度なテクノロジーと、様々なデータを簡単に利用できる社会を構築することができるからです。私達はこれを、テクノロジーとデータの民主化と呼び、AWS はこれらの民主化を通じて、国民・市民　一人ひとりが、デジタルの恩恵を享受できる、社会の実現に貢献するために、地域社会をより豊かに、そして地球と人々の発展を支える信頼性の高いテクノロジーを提供することを目指しています。そして、日本全体のデジタルトランスフォーメーション（以下、DX）を支援するため、日々活動を行っています。この思いは、政府が進めるビジョンである、全国どこでも 誰もが便利で快適に暮らせる 社会を目指す「 デジタル田園都市国家構想 」に一致するものです。 世界における日本のデジタル競争力の強化、最終的に市民・国民のより良い、心豊かな暮らしの実現のために、日本政府は DX をさらに加速しています。2021 年のデジタル庁創設、行政、教育、医療などのデジタル化、デジタル格差の解消、さらにガバメントクラウドの実現など、急ピッチでデジタル化を進めています。デジタル田園都市構想もその一つで、デジタルの力を活用して地域の社会課題の解決を目指し、地域でイノベーションを起こし新たな仕事を生み出すスタートアップ支援を進め、人の流れを作り、結婚・出産・子育てがしやすい環境作りを行うことを目指しています。 ガバメントクラウドの意義はますます大きく デジタル田園都市国家などを実現するデジタル基盤として進められているイニシアティブの中に、ガバメントクラウドがあります。ガバメントクラウドは、クラウドサービスの利点を最大限活用し、迅速、柔軟、セキュア、コスト効率の高いシステムを構築・提供し、最終的には国民、市民へのより良いサービスにつなげるもので、デジタル庁がけん引して進めています。官公庁や自治体のデジタル化施策のベースとなるこのガバメントクラウドに、AWS は 2021 年度から継続して採択され、 2024 年度も引き続き採択されています。ガバメントクラウドに必要な要素を AWS が実現している証左であると大変光栄に思うと同時に、日本政府、官公庁、自治体のインフラとして、引き続きコスト効率の良さを維持しながら、セキュアで、最新技術を利用できるクラウドを提供すべく、引き続き真摯に取り組み続けます。 また AWS は、ガバメントクラウド活用の支援のために、官公庁や自治体職員、および自治体を支援するパートナー向けに、AWS に関する基礎知識を学ぶ トレーニング （ハンズオンを含む）を2022 年 6 月から提供しています。 2023 年 10 月までに、のべ 1,000 人以上の官公庁・自治体職員・パートナーが参加しました。 AWS は公共、教育機関、非営利団体を支援してきた、クラウドベースのソリューションと経験を持つ世界中の AWS パートナーを認定する AWS 公共部門パートナー(PSP) プログラム を提供しており、日本の公共部門のお客様がイノベーションの文化を醸成し、パートナーやスタートアップ、シビックテックのエコシステムを活かして、地域体験を革新するために協働しています。 地方創生・地域活性化、行政の業務改善のための生成系 AI 活用など、自治体との様々な側面での連携を加速 AWS は、全国の自治体や地域行政におけるイノベーションを支援し、より良い社会と市民生活の実現に貢献すべく、様々な自治体、関係団体との連携を図っています。2022 年 9 月に つくば市 と研究開発型スタートアップの成長加速に向けてまた、同年同月に 浜松市 とデジタル・スマートシティ浜松の実現に向けて連携協定を締結しました。2023 年 5 月には 新潟県 と地域産業の活性化に向けた包括的な取り組み、同年 8 月に 北九州市 と地域の特色や強みを活かしながら地域課題を解決するための DX の推進に向けた取り組みを進めています。 例えば、新潟県との連携から、地域の人材育成支援に関して、すでにポジティブな動きが生まれています。AWS の認定トレーニングパートナーである トレノケート株式会社 は AWS と共に、新潟県の地域のリーダーを育てる新しい取り組みである NINNO ACCADEMIA において、AWS のクラスルームトレーニング Developing on AWS を 提供しています 。新潟の地域・社会課題を解決していく人材を育てるために、様々なプログラムを提供し、地域の DX を加速しています。 また、 大阪市 と 2023 年 9 月、行政 DX に向け、生成系 AI の活用に関して連携することで協定を締結。大阪市の行政業務の効率化と、市民サービス向上に向け、生成系AIの利活用の可能性と、利用にあたっての課題解決などについて、共同検証を行っています。 市民生活に直結する公共部門においては、データの確固たる信頼性や透明性が必須となってきます。私たちは、過去 20 年以上にわたり、人工知能（ AI ）や機械学習（ ML ）を誰でもが使うことができるように民主化し、グローバル企業や大規模な公共部門の組織からスタートアップまで、あらゆる規模のお客様が安全に容易に、そして適切なコストで革新的な AI ソリューションを構築できるよう注力しています。 このように AWS は、生成系 AI サービス、ソリューションを含めた最先端、かつ安全に安心して使っていただくテクノロジーや、幅広いサービスを提供しつつ、地域の活性化、市民へのより良いサービスの提供をデジタルを最大限に活用して取り組んでいる自治体と協働し、 DX の加速をサポートしています。 AWS ならではの AI / ML の支援・テクノロジーの民主化　日本の大規模言語モデルの構築支援と選択肢の提供 前日の大阪市の生成系 AI の取り組みの通り、生成系 AI をビジネスや公共部門領域に利用する動きが活発化しています。AWS ではこれまでに  Amazon Bedrock 、 Amazon CodeWhisperer 、 Amazon Q  などの生成系 AI サービスや  AWS Generative AI Accelerator 、 AWS Generative AI Innovation Center  といった生成系 AI 開発者支援プログラムを提供してきました。これら、Amazon の 20 年以上にわたる機械学習の経験から生まれたサービス・プログラムを活用することで、お客様は  AWS 上で柔軟、セキュア、かつ費用対効果の高い生成系 AI アプリケーションを構築することができます。AWS では Amazon Bedrock や  Amazon SageMaker JumpStart  で多くの大規模言語モデル ( Large Language Model, LLM ) をお客様に提供しており、お客様の用途に合わせた幅広い選択肢と柔軟性を提供します。また、AWS はお客さまがこの新しいテクノロジーの価値をフルに活かせるように、生成系 AI の専門家からなるチームを設置しており、あらゆる組織が AI を活用できるように支援するという目標を掲げています。 その一環としてアマゾン ウェブ サービス ジャパンは 2023 年 7 月 3 日に、日本独自の施策として国内に法人または拠点を持つ企業・団体の大規模言語モデルの開発を支援する「 AWS LLM 開発支援プログラム 」を開始しました。本プログラムでは、LLM 開発を行うための計算機リソース確保に関するガイダンスや AWS 上での LLM 事前学習に関わる技術的なメンタリング、LLM 事前学習用クレジット、ビジネス支援などのサポートを提供します。詳しくは こちら をご覧ください。 クラウドと AI に対応したスタートアップを含む中堅中小企業（ MSME ）が日本経済を牽引 冒頭、クラウドには社会の課題や困難を突破する力がありますとお伝えしました。それを証明するべく、AWSは、グローバルのコンサルティング企業であるアクセンチュアと共同で、社会課題に取り組む中堅中小企業（MSME: Micro, Small & Medium Enterprises）のクラウドへの移行によってもたらされる日本経済、および社会へのインパクト潜在的効果について検証し、レポート「 日本においてクラウド主導経済が現実に：中堅中小企業（MSME）を通じてクラウドが経済と社会に与えるインパクトとは 」 を発表しました。 同レポートによると、日本経済はクラウドが主導するテクノロジーを採用した MSME によって、2030 年には医療、教育、農業の分野全体で年間総額 1 兆 9,000 億円相当の生産性向上効果、日本の全雇用の 7 ％にあたる 520 万人の雇用を生み出すと予測しています。 医療分野では、クラウド主導の MSME が登場することで、医療機関にアクセス困難で十分なサービスを受けられない地域の課題解消を実現する可能性があるとしています。2030 年には日本でクラウド主導の MSME が医療分野で大きく成長し、年間総額 1 兆 2,000 億円相当の生産性向上効果の創出を促し、6,000 万件のオンライン医療相談をサポートすることになると推計しています。 教育分野では、クラウド主導の MSME がデジタルプラットフォームを通じ、教育へのアクセス性向上とインクルージョン教育に関する課題への対応を支援できる可能性があります。2030 年に MSME が教育分野で年間総額 5,000 億円相当の生産性向上効果を創出し、日本の 400 万人の生徒に e ラーニングソリューションを提供するようになるほか、2030 年までに日本で約 2,000 万人の成人がクラウド主導の MSME を介しオンライン教育にアクセスするようになり、現在の利用者数の 185% 増となると見込んでいます。 農業分野でクラウド主導の MSME が AI やクラウドテクノロジーを通じ、データ主動型の農業生産を導入することで、食糧不足問題を解決する可能性があると期待されています。2030 年には、農業生産に関わる日本の MSME が年間 1,000 億円相当の生産性向上を創出し、3 軒に 1 軒の農業従事者が精密農業ソリューションを利用するようになるだろうと推計しています。これは現在の使用率の 130% 増にあたります。 AWS では、中堅中小企業、スタートアップがイノベーションを支える重要な存在となり、医療、教育のデジタルサービスへのアクセスを改善するなど、社会の課題に対処する上で重要な役割を果たす存在になるだろうと考えています。生成系 AI や高度なクラウドテクノロジーの導入を加速し、経済的・社会的メリットを速やかに可能にするために、AWS は政府、関連機関など各業界と協力し、日本のビジネスがすべての人々にとってより良い未来を築けるよう支援していきます。 社会課題の解決を積極的に取り組む自治体、企業、スタートアップを支援 ビジネス、地域のさらなる活性化実現のために、AWS では「 デジタル社会実現ツアー2023 」を開催しました。昨年初めてオンラインにて開催した「 デジタル社会実現ツアー 2022 」をさらに進化させ、2023 年は 8 月 22 日の高松会場を皮切りに、広島、北九州、大阪、新潟、横浜、名古屋、浜松、仙台、札幌、那覇、福岡、そして全国の自治体、スタートアップなどに集まっていただき、総集編のようなコンテンツとした 10 月 4 日の東京会場と、全国計 13 ヶ所でリアルに開催しました。 「デジタル社会実現ツアー 2023 」のテーマは、「地域創生を“さらに”一歩進めるには？」。政府が進めるデジタル田園都市国家構想によって実現を目指す地域創生や社会課題解決のために、地域交通のリ・デザイン、遠隔医療、こども政策、教育 DX、観光 DX、防災 DX、スマート農林水産業・食品産業など、各領域において、先行して取り組みを始めている先進的な企業やスタートアップおよびそれらと連携している自治体や関係各省庁の皆様を各会場にお招きしました。そこで、「プロジェクトの進め方（資金調達など）」「人材育成」「デジタル技術の活用」といった注目の各トピックについての成功談・失敗談についてお話いただきました。全国各地で開催することで、地域ならではの課題、チャレンジが話し合われました。様々なトピックやテーマについて、多くの様々な参加者の方から情報共有、ディスカッションが行われましたが、AWS を活用しつつ社会課題の解決に尽力している企業様をハイライトとして抜粋してご紹介します。 浜松会場では、「浜松市実証実験サポート事業」に採択されたプロジェクトとして、 株式会社フジヤマ が提案した、浜松市全域の盛土の変化を観測するWebシステムが紹介されました。低コストで利用できる衛星データを活用し、AI 学習を用いた盛土の変化検出手法の検証および Web システム構築を行うことで、市域全体の盛土監視システムの構築を目指すものです。 札幌会場では、 株式会社よびもり が知床（羅臼町と斜里町ウトロ）の海上にて、役場、観光船協議会および漁協とともに実施した、助け合い海難救助サービス「よびもり（ yobimori ）」の実証実験を紹介しました。「よびもり」は、海難事故が発生した場合、最新の位置情報を近くの漁船、観光船などにつないで、救助要請を可能とする仕組みです。 横浜会場では、神奈川県による「要配慮施設利用者の安全を守る避難確保計画の取組化」の実証実験として、 株式会社ネオジャパン の製品である desknet’s NEOとAppSuite にて構築した避難確保計画作成アプリケーションが紹介されました。横浜市の避難確保計画に関するサイトと情報をアプリ上に集約し、災害に対する意識啓発を促進している事例です。 「デジタル社会実現ツアー2023」は、全 13 会場の様子をオンデマンド視聴することができます。詳しくは こちら からご覧ください。 デジタル庁が進めるデジタルマーケットプレイスへの支援 現在、デジタル庁では官公庁や自治体などの行政機関がクラウドソフトウェア（SaaS）を調達する際に、オンライン上でほしいソフトウェアを検索、比較して、調達できるような手法「デジタルマーケットプレイス（DMP）」の開設準備を進めています。 DMP はデジタル庁が運営する調達プラットフォームで、多様なベンダーがサービスを登録し、その中から行政機関が必要なサービスを検索・選定し、簡易的に調達できるようになります。2024 年度下半期の本番サイトオープンにあわせ、国と自治体が調達の際に DMP を利用できるような国の制度整理を進め、会計制度上も利用できるものとする計画です。これに先立ち、2023 年度は α 版というカタログサイトが公開され、事業者が実際に製品を登録し、売り手側、買い手側のニーズや操作性等の確認・調査が行われる予定です。 公共調達の仕組みが大きく簡素化されることと、SaaS というクラウドによる提供形態の製品の紹介の場が作られることにより、これまで公共調達に参加しにくかった中堅中小企業やスタートアップなどにとっては大きなメリットとなります。また、買い手側も DMP というオンライン上で、いつでもどこでも、自分たちのニーズに合った製品を探し出すことができるようになります。 もともとはスタートアップであるアマゾンに出自をもつ AWS は、民間ビジネス領域のみならず、公共部門でのスタートアップの更なる活躍を継続して支援しており、これまでハードルが高かった公共調達に、より参入しやすくなるこの DMP に賛同し、成功を支援します。 例えば前述の、11 月 30 日に事業者向け機能がリリースされた カタログサイトα版 を構築したスタートアップである株式会社dotD（ドットディー）は、 AWSプロフェッショナルサービス によるコンサルティング支援を活用しました。また私たちは、AWS を活用頂いているパートナー向けに、カタログサイト α 版へ製品を登録するためのワークショップや意見交換のための交流会を実施しています。詳しくは こちら をご覧ください。 AWS では、日本の DMP 開設、本格稼働に最大限協力し、企業やスタートアップが公共調達のハードルを乗り越えて、公共部門で社会課題解決のために活躍し、さらに日本の行政サービスの質の向上およびコスト削減に向け貢献されることを全面的に協力し支援していきます。 AWS が考える継続支援への決意 AWS では、デジタル庁が掲げるデジタル田園国家構想を実現するための支援として、ガバメントクラウドに AWS を採用いただくにとどまらず、さらなる活動を継続して行っていくことが重要と考えています。今後、豊かな暮らしを実現していくためには、「経済・社会の発展」、それを実現する要素として「テクノロジーとデータの民主化」、さらに「社会課題の解決」、「付加価値の創造」という循環を作り出していくことが必要です。 しかも、付加価値の創造や社会課題の解決のためには従来の手法では難しい場面が出てくるかもしれません。そこで重要になるのが新しい考え方でテクノロジーを使うような新しい企業が誕生するための「スタートアップへの支援」です。こうして誕生したスタートアップは、「革新的なビジネスモデル」を生み出し、「経済・社会の発展」に寄与すると共に、付加価値の創造や社会課題の解決の一助となっていくでしょう。 日本のデジタル化、それによる市民のより良い暮らしの実現に向けて、AWS は引き続き全方位であらゆるステークホルダーと協力し、支援し、タッグを組み、安全で安心して信頼いただけるクラウドサービスの提供、活動を続けてまいります。 AWS の 2022 年の公共部門における取り組みについては、 こちら をご覧ください。 アマゾン ウェブ サービス ジャパン合同会社 執行役員 パブリックセクター 統括本部長 宇佐見 潮

はじめに デジタル環境が急速に変化する今日、企業は効率的な業務運営、コスト削減、クラウドコンピューティングの最適活用を常に模索しています。企業の成長に伴い、Azure や Google Cloud Platform(GCP) から Amazon Web Services(AWS) への移行など、異なるクラウドプロバイダー間での仮想マシン(VM)移行が必要となることが多々あります。 しかし、クラウドへの移行を始めることは、課題や複雑さが多く困難な作業になりかねません。 そこで、 AWS Application Migration Service (AWS MGN) が移行プロセスを簡素化・合理化する強力なツールとして役立ちます。 AWS MGN は、高度に自動化されたリフト&シフトソリューションを提供することで、クラウド移行の簡素化、促進、コスト削減を実現します。 1台のサーバーにつき最大 90 日間、サーバーの数に制限なく無料で移行できます。ほとんどのお客様は、この 90 日以内にサーバーの移行を完了し、AWS Application Migration Service を無料でご利用いただけます。 このブログでは、AWS MGN を使用して Azure 上の仮想マシンを AWS に移行する方法について解説します。 移行をスムーズに成功させるための手順、ベストプラクティス、留意点について説明し、AWS が提供する様々な機能を最適に活用できるよう助言します。 アーキテクチャの概要 AWS MGN は、物理サーバー、仮想マシン、クラウド上のサーバーを、簡単に別の場所に移行できるサービスです。 オンプレミスのデータセンターや別の AWS リージョン、他のクラウドプロバイダー上のサーバーから、AWS にサーバーを移行することができます。 以下のアーキテクチャ図は、AWS MGN を使ってオンプレミスのサーバーを AWS に移行する流れを示しています。 図 1. AWS MGN アーキテクチャ図 ソースサーバにインストールされた軽量なエージェントが、レプリケーションを実行します。この AWS レプリケーションエージェントは、TLS を利用してポート 443 を通じて安全に通信を行い、接続されているすべてのディスクをスキャンして、ターゲットリージョンへブロックレベルでレプリケーションを行います。最初のレプリケーションが完了すると、レプリケーションエージェントはソースサーバへの変更を監視し、その変更点をレプリケートしていきます。これにより、ターゲットリージョンに保存されたデータを最新の状態に保つことができます。 ソースとターゲットが完全に同期し、継続的レプリケーションモードになった後は、テストまたはカットオーバーを開始することができます。 テストまたはカットオーバーが開始されると、AWS MGN は Amazon Elastic Compute Cloud (Amazon EC2)   の API を使用してターゲットインスタンスを起動し、新しい Amazon Elastic Block Store (Amazon EBS)   ボリュームをアタッチします。 AWS MGNを利用することで、アプリケーションやワークロードの内容に関わらず、オンプレミスのデータセンターや他のクラウドプロバイダーから AWS へ仮想マシンを移行することができます。 ソリューション概要 AWS MGN を利用すると、仮想マシンを Amazon EC2 に移行できます。また、アプリケーションデータの同期も確認できます。 移行に関する手順は以下の通りです。 AWS MGN を利用してレプリケーション環境を構築します。 一時的な認証情報を作成します。 Azure の仮想マシンに AWS MGN エージェントをインストールします。 ソースサーバーの起動設定を行います。 テスト用インスタンスとカットオーバーインスタンスを起動します。 前提条件 Azure での WordPress サイトの作成 まず移行を行うには、 WordPress が構築されている Azure 仮想マシンが必要です。Azure 仮想マシンを作成する手順は以下の通りです。 Azure アカウント上で検索バーに「 WordPress 」と入力し、検索します。 検索に一致した Marketplace で [ WordPress ] オプションを選択します。App Service で WordPress を選択しないでください。選択すると、VM にアクセスできなくなります。 [ 作成 ] を選択します。 リソースグループ名 と 仮想マシン名 を入力します。 管理者アカウント に、 ユーザー名 と キーペア名 を入力します。これは後でインスタンスに接続するときに使用します。 [ 確認および作成 ] を選択します。 新しいキーペアを生成するように求められます。後で仮想マシンにアクセスできるように、プライベートキーをダウンロードするオプションを選択します。 ソースサーバーネットワーク AWS MGN レプリケーションエージェントを WordPress サーバーにインストールする際には、ネットワーク設定を適切に構成し、アクセスを許可する必要があります。手順は以下の通りです。 Azure アカウントで、仮想マシンを検索します。 WordPress ドキュメントの作成時に指定した名前の仮想マシンを選択します。 サイドバーの 設定 の [ネットワーク設定] タブを選択します。 図 2. WordPress を実行しているソースサーバーのネットワーク画面 [ 受信ポート ルール ] を選択します。宛先ポート範囲を 443 に設定し、プロトコルとして TCP を選択します。 DenyAllInbound の優先度よりもこのルールの優先度番号が小さいことを確認してください。 次に、[ ポート ルールの作成 ] – [ 送信ポート ルール ] を選択します。 このメニューで、宛先ポート範囲を 1500 に、プロトコルを TCP に設定します。残りはデフォルトのままにします。 セクション 1: AWS MGN 環境のセットアップ AWS MGN のランディングページで[ 使用を開始 ]をクリックします。このサービスに初めてログインした場合、サービスの初期設定を求められます。 図 3. AWS MGN サービス初期時のプロンプト コンソールの AWS MGN エリアにアクセスするのが初めてではない場合は、サイドバーの [ レプリケーションテンプレート ] に移動し、[ サービスのアクセス許可を再初期化 ] を選択することでアクセス許可を再設定できます。 サービスを初期化すると、 AWS Idenity and Access Management (IAM ) ロールとともにレプリケーションテンプレートが作成されます。テンプレートは、新しく追加されたソースサーバーごとにデータレプリケーションがどのように機能するかを規定します。また IAM ロールはレプリケーションエージェントをインストールするために必要な権限が付与されます。 構成されたレプリケーション設定は、個々のソースサーバーまたはソースサーバーのグループでいつでも変更できます。 レプリケーション設定の詳細 をご覧ください。 セクション 2: 一時的な認証情報の作成 ソースサーバーに AWS MGN エージェントをインストールするには、まず必要な認証情報を作成する必要があります。そのためには、インストール権限を持つ AWS IAM ロールを作成します。このロールを使用して、MGN で利用するための一時的な認証情報を生成します。 コンソールの AWS IAM に移動します。 サイドバーで、[ アクセス管理 ]の[ ロール ]タブを選択します。 右上の [ ロールを作成 ] ボタンを選択します。 図 4. 新しいロールを作成できる AWS IAM ロール画面 信頼されたエンティティタイプについては、[AWS アカウント] を選択し、[次へ] を選択します。 許可ポリシーの検索バーで、[AWSApplicationMigrationAgentInstallationPolicy] を検索し、その横にあるチェックボックスをオンにして選択します。次に、[次へ] を選択します。 ロール名には 「 mgn_install 」 を入力します。次に、下にスクロールして [ ロールを作成 ] を選択します。 ロール検索バーで、先ほど作成した mgn_install ロールを検索し、選択して概要にアクセスします。 概要に表示されている mgn_install の ARN をコピーします。 セッション時間が長く必要と想定される場合は、編集ボタンを選択し、必要に応じてロールの最大セッション時間を長くしてください。 図 5. mgn_install ロールの概要 セクション 3: Azure 仮想マシンに AWS MGN エージェントをインストールする コンソールの AWS MGN に移動します。ソースサーバーを選択し、[ サーバーを追加 ]を選択してエージェントインストーラーのリンクを取得します。 図 6. 新しいソースサーバーを追加できる AWS MGN ソースサーバー画面 [ サーバーを追加 ]を選択すると、AWS レプリケーションエージェントインストールに関する設定画面が表示されます。 図 7. AWS レプリケーションエージェント のインストール画面 ここでは、セクション2で作成した IAM ロールの認証情報(AccessKeyID、SecretAccessKey、および SessionToken)を提供する必要があります。そのため、 AWS Security Token Service (AWS STS) の AssumeRole API を利用して、一時的な認証情報を取得します。一時的な認証情報を取得するには以下の手順を実行します: コンソールページの左下にある CloudShell ボタンを選択して、コマンドラインインターフェイス (CLI) を開きます。 図 8. AWS CloudShell インターフェイス CLI に次のコマンドを挿入します。これにより、AccessKeyID、SecretAccessKey、および SessionToken が出力されます。これらのトークンは、AWS レプリケーションエージェントのインストールページの項目 に利用します。 (図 7 を参照)。 aws sts assume-role —role-arn [mgn_install の ARN] –-role-session-name “mgn-install” 図 9. aws sts assume-role コマンドを実行した後の CloudShell の出力 AccessKeyID、SecretAccessKey、および SessionToken を入力後、図7の項目5と6のコマンドをコピーして Azure 仮想マシン上で実行することで、Azure 仮想マシンにレプリケーションエージェントをインストールすることができます。 Azure 仮想マシンへの Secure Shell (SSH) または Remote Desktop Protocol (RDP) のガイダンスについては、次のドキュメントを参照してください。 https://learn.microsoft.com/en-us/azure/virtual-machines/linux-vm-connect?tabs=Linux 項目 5 のコマンドを正常に実行すると、次のようになります。 図 10. エージェントインストーラが正常にダウンロード完了した場合の出力 同様に、項目6のコマンドを実行すると、次のようになります。 図 11. レプリケーションエージェントを正常にインストール完了した場合の出力 AWS レプリケーションエージェント が正常にインストールされたことを示すプロンプトが表示された後、AWS MGN のソースサーバー一覧にソースサーバーが表示され、初期同期が開始されます。 図 12. MGN のアクティブなソースサーバーリストに表示されるサーバー エージェントのインストール後、ソースサーバに接続されているすべてのディスクが自動的にスキャンされ、検出されたディスク上のデータに対して複製が開始されます。 セクション 4: サーバー起動設定の構成 テストインスタンスとカットオーバーインスタンスを起動する前に、いくつかの設定を構成する必要があります。 設定を行うには、まずソースサーバーを選択します。ここから、図13に示すように、[ 起動設定 ]に移動できます。 [ 起動設定 ]では、[ 一般的な起動設定 ] と [ EC2 起動テンプレート ]の2つがあります。 図 13. ソースサーバーの起動設定 このユースケースでは、[ 一般的な起動設定 ] をデフォルトのままにします。 [ EC2 起動テンプレート ]については、[ ネットワーク設定 ] までスクロールし、[ 高度なネットワーク設定 ] を選択します。 図 14. EC2 起動テンプレート内のネットワーク設定 ここでは、WordPress サーバーが公開されている前提で、[ パブリック IP の自動割り当て ]を有効にする必要があります。次に、[ テンプレートのバージョンを作成 ] を選択して、これを新しいテンプレートバージョンとして保存します。 図 15. 高度なネットワーク設定 テンプレートを構成したら、テンプレートを開いて正しく構成されていることを確認する必要があります。そのためには、テンプレートバージョンを作成した後に表示される成功通知でテンプレート名を選択します。 図 16. 起動テンプレートが正常に作成された後に表示されるメッセージ AWS MGN はデフォルトのバージョンの EC2 起動テンプレートを使用します。新しく作成したテンプレートはデフォルトにはなっていないため、[ アクション ] に移動して [ デフォルトバージョンを設定 ] を選択する必要があります。ドロップダウンから最新のテンプレートバージョンを選択し、「 デフォルトバージョンとして設定 」を選択します。 図 17. デフォルトバージョンを設定するドロップダウンメニュー セクション 5.テストインスタンスとカットオーバーインスタンスの起動 最初にテストインスタンスを起動し、テストインスタンスで問題が無いことを確認した後カットオーバーに進みます。これは、カットオーバーのプロセスを完了する前に、インスタンスで問題が発生しないかどうかを事前に検証するためです。 ソースサーバーの [ 移行ライフサイクル ] 列に [ テストの準備完了 ] と表示され、データレプリケーションステータスが正常となっているを確認します。 次に、ソースサーバーを選択し、[ テストおよびカットオーバー ] から [ テストインスタンスを起動 ] を選択します。 図 18. [テストおよびカットオーバー] から[テストインスタンスを起動] を選択 テストインスタンスの起動に成功すると、[ アラート ]列に [ 起動済み ]と表示されます。サーバーを選択し、[ 移行ダッシュボード ]を表示して確認することもできます。起動ステータスが[ 成功 ]と表示されると、起動したテストインスタンスを EC2 で表示し、パブリック IPv4 アドレスを開くオプションが表示されます。これはカットオーバーインスタンスでも同様に表示されます。 (オプション) 検証に失敗した場合、[ アラート ]列にエラーメッセージが表示されます。再試行する前にサーバーのトラブルシューティングを行えるように、[ 移行ライフサイクル ]を[ テストの準備完了 ]に戻すオプションを選択できます。エラー一覧とトラブルシューティング方法については、 こちら をご覧ください。 テストが成功したら、[ テストおよびカットオーバー ]に移動し、[ カットオーバーの準備完了 ] としてマークできます。次に、[ カットオーバーインスタンスを起動 ] を選択します。テストと同様に、[ アラート ]列に [ 起動済み ] ステータスが表示されれば、カットオーバーが成功したことがわかります。ソースサーバー名を選択して、移行ダッシュボードを表示することもできます。 図 19. [テストおよびカットオーバー] から [カットオーバーインスタンスを起動]を選択 次に、ソースサーバーのリストからソースサーバーを選択し、[ 移行ダッシュボード ]から EC2 へのリンクを選択します。 図 20. 移行ダッシュボードで、起動した EC2 カットオーバーインスタンスに遷移 インスタンス概要から、新しいインスタンスのパブリック IPv4 アドレスを確認し、IPv4 アドレスを使用して WordPress ページにアクセスします。 図 21. カットオーバーインスタンスの EC2 概要とパブリック IPv4 アドレス IPv4 アドレスにアクセスし WordPress ページが機能していれば、カットオーバーは成功しています。移行を完了するには、コンソールで AWS MGN サービスに戻り、ソースサーバー に移動します。 ソースサーバーを選択し、[ テストおよびカットオーバー ]から[ カットオーバーを最終処理 ]を選択します。最終処理が完了すると、ソースサーバーの移行に使用されたリソースがすべてクリーンアップされ、破棄されます。 図 22. [テストおよびカットオーバー]から[カットオーバーを最終処理]を選択 セクション 6: クリーンアップ クリーンアップするには、ソースサーバーを選択し、[ アクション ]から「 アーカイブ済みとしてマーク 」を選択します。 アーカイブ済みとしてマークされたサーバーは AWS MGN コンソールに表示されなくなります。 (オプション)カットオーバーインスタンスを使用する目的でこれを実行した場合は、このステップに従わないでください。ただし、学習としてこのガイドに従った場合は、ターゲットの EC2 インスタンスを削除して、そのインスタンスとそれに関連する EBS ボリュームのコストが発生しないようにする必要があります。これを行うには、EC2 ダッシュボードにアクセスしてインスタンスを表示します。そこからインスタンスを選択し、[ インスタンスの状態 ] から [ インスタンスの終了 ] を選択します。 結論 このブログ記事では、AWS MGN を使用して Azure から AWS へ仮想マシンを移行する際の主な手順について説明しました。 移行をスムーズに行う方法として、AWS MGN の環境設定の方法、Azure の仮想マシンに MGN エージェントをインストールする手順を解説しました。さらに、AWS 側で起動テンプレートを設定する方法もステップバイステップで説明しました。 AWS MGN は、仮想マシンをクラウド間で移行するプロセスを簡略化することを目的としており、互換性の評価、データレプリケーション、カットオーバーなどのタスクを高度に自動化します。 この記事は特に Azure VM から AWS への移行に焦点を当てていますが、MGN はオンプレミス、Azure、GCP、AWS など、異なる環境間での異機種移行もサポートしています。 組織は、アプリケーションポートフォリオと要件を評価し、AWS MGN が自社のクラウド移行戦略とロードマップに適合し、どの部分で活用できるかを判断することができます。 翻訳はソリューションアーキテクト 駒野 達也 が担当しました。原文は こちら です。

はじめに 過去数年にわたり、産業や製造の領域では、 インダストリアル IoT (IIoT) 、人工知能 (AI) 、 機械学習 (ML) の進歩による変革が加速しています。この変革の中心にあるのはデータであり、これを効果的に活用すれば、ビジネスのオペレーション効率、イノベーション、顧客満足度を新たな高みに押し上げることができます。強固な産業データ基盤の構築は、単なる戦略的な活動ではありません。デジタル時代における成功を目指すメーカーや産業界にとって不可欠です。 AWS IoT SiteWise は、産業機器から大規模なデータを簡単に収集、整理、分析できるマネージドサービスであり、顧客がより適切でデータ主導の意思決定を行えるよう支援します。 Volkswagen Group 、 Coca-Cola İçecek 、 Yara International などのお客様は、AWS IoT SiteWise を使用して、工場全体で生成されたオペレーショナルテクノロジー (OT) データをコンテキスト化して分析できる産業用データプラットフォームを構築し、事業とビジネスのグローバルビューを構築しています。さらに、 Embassy of Things (EOT) 、 Tata Consulting Services (TCS)、 Edge2Web 、 TensorIoT 、 Radix Engineering などの AWS パートナーは、予知保全やアセットパフォーマンスモニタリングなどのユースケースを可能にする専用アプリケーションの基盤となっています。お客様やパートナーとのこうした取り組みを通じて、デジタルトランスフォーメーションの取り組みを拡大する上での主な障害は、プロジェクトの複雑さ、インフラストラクチャのコスト、価値実現までの時間にあることがわかりました。 こうした障害に対処するため、AWS IoT SiteWise ではお客様やパートナーが AWS IoT SiteWise に保存されている産業機器データに分析と AI/ML を適用する方法を簡素化する新機能をリリースしました。これらの新機能により、データをクラウドに取り込むコストを最大 70% 削減し、プロジェクトのタイムラインを数か月から数週間に短縮、ビジネスインテリジェンス (BI) ダッシュボードや ML アプリケーションでデータに簡単にアクセスできるようになります。これらの機能強化により、お客様はアセットモデルと階層をより迅速に導入し、取り込みから数分以内に分析ワークフローを実行し、予測メンテナンスのユースケースをより迅速に展開して計画外のダウンタイムを回避できます。今回の新機能により、AWS は、大量の多様な産業データを実用的な洞察に変換し、オペレーション効率を高め意思決定を改善することをより簡単かつ費用対効果の高い方法で実現できるようになりました。 このブログ記事では、AWS IoT SiteWise で最近リリースされた機能の詳細と、AWS のお客様とパートナーがデータ基盤の近代化を促進するためにこれらの機能をどのように使用しているかについて詳しく説明します。 変革のペースを加速する 業務全体の可視性を標準化することは、産業変革の重要な要素です。これは、従来の分断された手動の監視方法からの転換を意味し、コンテキスト化されたデータの統一されたビューに基づいて構築された、統合されたデータ主導型のアプローチが必要です。AWS IoT SiteWise は、このようなデータの標準化とコンテキストをアセットモデルで提供します。モデルはデータを整理し、企業、サイト、エリア、およびマシンレベルでの分析に役立ちます。しかし、産業のオペレーションが複雑であることを考えると、物理資産を正確に表すモデルの構築と維持には時間がかかり、洞察を得るまでの時間が遅れる可能性があります。 新たに追加された API により、AWS IoT SiteWise では、データヒストリアン、他の AWS アカウント、または AWS の独立系ソフトウェアベンダー (ISV) パートナーの場合は独自の産業データモデリングツールなどのさまざまなシステムから、 産業アセットモデルのメタデータを大規模にインポート、エクスポート、更新 ができるようになりました。 図 1: ヒストリアンなどの外部システムから機器メタデータをインポート さらに、AWS IoT SiteWise は、お客様が新しいアセットモデルを作成するために再利用できる アセットモデルコンポーネント とサブコンポーネントの作成をサポートするようになりました。アセットモデルコンポーネントにより、お客様は複雑な機械を企業全体で再利用可能な部品に分割できます。お客様は全社的なコンポーネントライブラリを作成できるため、モデルの標準化が促進され、業務の拡大や複雑化に伴うより効率的なスケーリングが可能になります。下の図は、再利用可能なサーボモーターコンポーネントを使用して複雑な溶接ロボットをモデル化する方法を示しています。新機能により、新しい産業用ユースケースを導入するまでの時間が数か月から数週間に短縮され、さまざまな産業用データソースからのデータを統合ビューにすばやく取り込むことで、価値実現までの時間が短縮されます。 図 2: 再利用可能なコンポーネントモデルを作成してアセットを記述し、データを整理 リアルタイムおよび過去の機器データの統合ビューの作成 AWS IoT SiteWise は、リアルタイムの機器データと過去の機器データの両方を安全に一元管理できるストレージを提供します。エンドユーザーと産業用アプリケーションは、AWS IoT SiteWise に保存されているデータを利用して、貴重な洞察を得てビジネス成果を促進できます。 機器からリアルタイムのデータを収集するために、AWS IoT SiteWise では AWS IoT SiteWise Edge を提供しています。これは AWS によって作成され、オンプレミスにデプロイされ、エッジでの機器の収集、整理、処理、監視を簡単に行えるようにするソフトウェアです。SiteWise Edge を使用すると、お客様は OPC-UA などの産業用プロトコルや標準を使用して機器に安全に接続し、機器からデータを読み取ることができます。AWS パートナーである Domatica 社と協力し、MQTT、Modbus、SIMATIC S7 などの 10 種類の産業用プロトコルのサポートを追加 しました。これにより、機器、機械、レガシーシステムから AWS IoT SiteWise に取り込んで、エッジでの処理や産業用データレイクを強化できるデータの種類が多様化されました。1 秒未満のレイテンシーでデータをクラウドに取り込むことで、お客様は AWS IoT SiteWise を使用して、産業活動全体にわたる何十万ものアセットをほぼリアルタイムで監視できます。 図3: AWS パートナーである Domatica 社の EasyEdge ソフトウェアをを利用することにより新たにサポートされたプロトコルによる機器への接続が可能 ただし、クラウドにおいてすべての機器データがニアリアルタイムで必要なわけではありません。エネルギー、組立製造、プロセス業界のお客様とのプロジェクトを通して、クラウドに送信された機器データのうち、クラウド上のダッシュボードで使用されているニアリアルタイムのデータはわずか10～30％であることがわかりました。残りの 70% ～ 90% は、BI ダッシュボードや機械学習モデルトレーニングなど、クラウド内のデータを数秒ではなく数分以内に必要とする分析アプリケーションで使用されます。そのため、データの取り込みと保存の方法を最適化する必要がありました。 そこで、分析のユースケースに適したコストとパフォーマンスを提供するために、 バッファリングされたデータ取り込みを発表 しました。バッファリングされたデータ取り込みでは、クラウドに取り込まれる前にエッジでバッファリングするデータストリームを顧客が設定できます。これにより、お客様はクラウドへのデータ取り込みコストを最大 70% 削減できます。 コスト効率が高く分析クエリ用に最適化されたストレージ AWS IoT SiteWise には複数のストレージ階層があり、パフォーマンスとコスト効率のバランスを取りながら、さまざまなユースケースを柔軟にサポートできます。ホットストレージ階層は頻繁にアクセスされるデータに最適化されており、インタラクティブダッシュボードなどのリアルタイムアプリケーションでは書き込みから読み取りまでの待ち時間が短くなります。コールドストレージ層は、 Amazon S3 バケットを使用して、稀に使用されるデータを保存します。新機能としてデータをコスト効率よく保存できるように設計された 新しいウォームストレージ階層 を追加しました。ウォームストレージ階層は BI、レポートツール、ML モデルトレーニングなどのアプリケーションで、書き込みから読み取りまでの待ち時間が中程度の大量のデータを取得するのに最適化されています。このウォームストレージ階層により、お客様は大量のデータを、 Amazon S3 に近い 1 GB あたりの価格で保持できます。 ウォームストレージ階層を使用しているお客様は、 新しい Query API も使用できます。Query API を使用すると、お客様は SQL に似たクエリステートメントを使用して、1 回の API リクエストで、アセットモデル、アセット、測定値、メトリクス、変換、集計からメタデータと時系列データを取得できます。この機能は、Amazon QuickSight、PowerBI、Microsoft Excel などのツールと互換性があり、ニアリアルタイムや過去の企業業績のレポートを作成できます。 お客様は、新しい Query API で SQL クエリステートメントを使用してデータを探索し、洞察を抽出できます。次の例は、ユーザーが名前に「Engine」を含むすべてのマシンの RPM 情報をクエリする方法を示しています。 select a.event_timestamp,b.asset_name ,c.property_name , a.quality,a.integer_value from raw_time_series a,asset b , asset_property c where a.event_timestamp > 1698335614 and b.asset_name LIKE ‘Engine%’ and c.property_name = ‘RPM’ event_timestamp asset_name property_name quality integer_value 26-10-2023T15:53:34 Engine001 RPM GOOD 2857 26-10-2023T15:53:34 Engine002 RPM GOOD 2549 26-10-2023T15:63:34 Engine001 RPM GOOD 2753 26-10-2023T15:63:34 Engine002 RPM GOOD 2349 表 1: SQL ステートメントを使用したクエリによるデータ取得 機械学習を使用した予知保全プログラムの推進 複数のお客様が、AWS IoT SiteWise からの産業機器データを Amazon Lookout for Equipment と統合して、予測を行い、機器の異常な動作を検出できる機械学習モデルを作成しています。しかし、サービス間の連携のためにお客様が複数のステップを踏む必要があり、時間のかかるプロセスでした。 AWS IoT SiteWise と Amazon Lookout for Equipment の新しいネイティブ統合 により、連携のための複雑な仕組みの構築やコードを記述したりすることなく、これら 2 つのサービス間でデータを直接同期できるようになりました。これにより、Lookout for Equipment の機械学習モデルを AWS IoT SiteWise から簡単に構築でき、異常検出と予知保全が可能となります。 トヨタ自動車ノースアメリカ (TMNA) は、AWS IoT SiteWise データを使用して Amazon Lookout for Equipment で作成されたモデルを自社の CNC マシンにデプロイしました。サイトあたり200台以上の CNC マシンが年中無休で稼働していたため、TMNA メンテナンスチームにとって予知保全には時間とコストがかかりました。TMNA は、AWS IoT SiteWise を使用して、障害を数日前に予測し、計画外のダウンタイムを削減できる 予測メンテナンス ソリューションを開発しました。導入以来、お客様は数十件の事故や何時間ものダウンタイムを防ぐことができただけでなく、オペレーション可用性を過去 12 か月間の平均で 10% 向上させました。 「当社のフォーカスラインの稼働率は78～ 82% で、毎月約40時間のダウンタイムが発生していました。AWS の支援により、マシンに多くの問題が見つかりました。気付かないままにしておくと、重大な障害につながります。現在、当社の OA は 92% で、ダウンタイムは約20時間です。」— Braden Burford, Sr. Maintenance Engineer, Toyota 機器データのコンテキスト化による強力な洞察 産業の変革は、主に機器、機械、レガシーシステムから得られるデータの可能性を解き放つことに重点を置いています。従来のデータ管理システムでは、効率性、拡張性、革新性に向けた高い要求を満たすにはもはや十分ではありません。これらの機能強化により、AWS IoT SiteWise は、データを資産として活用するためのスケーラブルで統一された統合アプローチを可能にする最新の産業用データ基盤を実現します。コスト効率が高く、安全で再現性のあるフレームワークを提供することで、お客様が産業変革のための強固な基盤を構築し、業務を最適化するのに役立つ産業用データセットへのアクセスを可能にします。 AWS のお客様であるバイオ医薬品の世界的リーダーである Bristol Myers Squibb (BMS) は、AWS IoT SiteWise による産業データ基盤の近代化によって業務変革を実現されたお客様です。生物製剤、製薬、細胞療法の各部門にわたる事業戦略を強化するという目標を掲げており、BMS は従来のデータシステムの見直しの必要性を認識しました。彼らの主な目的は明確でした。1/ 企業全体の可視性を実現すること、2/ エンドツーエンドのトレーサビリティを確立すること。3/ プロセス監視、予測的資産保守、継続的プロセス検証 (CPV) のための検証済みの単一エンタープライズソリューションを実装すること。 BMS は、企業全体の可視性と分析を強化できるデータ管理への統合アプローチを求めて、AWS IoT SiteWise を採用しました。BMS は、Enterprise PI Historian からデータを引き出し、それを AWS 上の統合データレイクに送ることで、データ管理においてかつてないスケール、パフォーマンス、スピードを実現しました。 BMS の重要な進歩の 1 つは、エンタープライズリソースプランニング (ERP) やその他のシステムからの情報とデータを集約することで、データにコンテキストを追加できることでした。これにより、さまざまな場所で製造されている製品バッチのより詳細なサイト分析が可能になりました。 「生物製剤、製薬、細胞療法におけるビジネス戦略の改善を目指すにあたり、可視性とトレーサビリティの強化が不可欠であり、AWS IoT SiteWise は完璧なソリューションでした。AWS を使用してデータ基盤を最新化することで、さまざまなデータソースを統合データハブにシームレスに統合し、効率とスケーラビリティを最適化しました。この変革により、さまざまなシステムからのデータを組み合わせることができ、複数のサイトにわたる製品バッチの洞察に満ちた分析が可能になりました。これにより、アセットのメンテナンスを予測する能力が大幅に強化され、新しい潜在的なユースケースに光が当てられました。これはゲームチェンジャーです。」— Nitin Bhatti, GPS IT, Manufacturing Analytics at Bristol Myers Squibb BMS の変革は、将来のイノベーションの舞台となりました。インフラストラクチャが最新化されたことで、Predictive Asset Maintenance (PAM) や多変量分析など、新たなユースケースを検討できるようになりました。長期的なビジョンには、データの使用と分析を現場の担当者の範囲を超えて拡大し、企業全体の包括的な視野を提供することが含まれます。 AWS パートナーと協力してビジネス成果を実現 デジタルトランスフォーメーションを進めている産業界では、プロジェクトの拡大が難しいことに気付きました。PoC から大規模な企業への本格導入までイニシアチブをとることは、リソースを大量に消費し、専門的なスキルが必要です。AWS パートナーは、業界全体にわたる深い専門知識を持ち、基幹業務のユースケースを解決するソリューションを提供することで長期的な顧客価値を生み出すために必要な推進要因を理解しています。これらのパートナーは、お客様が AWS IoT SiteWise を使用して堅牢なデータ基盤を構築できるよう支援し、そのデータ基盤を使用してお客様の特殊なユースケースの解決を支援します。AWS IoT SiteWise パートナーのいくつかの例を以下に示します。 EOT は Twin Fusion を構築しました。これは、AWS IoT SiteWise を使用して、AWS クラウド内の高度な分析、ML、生成 AI を活用してレガシー IoT データの活用、管理、視覚化、アクションを実現する、Software-as-a-Service (SaaS) 製品です。Twin Fusion は、 産業データファブリック (IDF) に関する AWS ガイダンス の一部です。Twin Fusion は、マシンや時系列データからの IIoT データやセマンティックデータを AWS IoT SiteWise に取り込むためのエンドツーエンドのソリューションを提供します。Twin Fusionは、複数の産業用データソースからのメタデータを統合する企業全体のデジタルツイングラフアセットモデルを提供します。この製品は、エンドユーザーデータ分析、アセット階層検索、埋め込みMLモデル、およびAIによる産業資産の企業全体の最適化のためのオペレーションダッシュボードを提供します。 TCS は、時系列データを AWS サービスでモダナイズするパートナーであり、エッジと AWS クラウドに AWS IoT SiteWise をデプロイすることで、顧客の価値実現までの時間を短縮しています。TCS は、お客様が複数の時系列データを単一のエンタープライズクラウドヒストリアンに取り込み、データのサイロ化を解消して、機器のダウンタイムの最適化、サイクルタイムの改善、一貫した生産性、不良率の低下、環境コンプライアンスなどの産業上の課題を解決できるよう支援します。 Edge2Web は、ノーコードおよびローコードの産業用アプリケーションの オープンプラットフォーム の基盤として AWS IoT SiteWise を使用しています。Edge2Web アプリケーションは、お客様が資産をより適切に管理し、機械のダウンタイムを削減し、製品品質を向上させ、生産パフォーマンスを最適化するのに役立ちます。 TensorIoT は、AWS IoT SiteWise 上に構築された SmartInsights ソリューションを開発しました。SmartInsights は、「起こったこと」と「これから起こること」を1つの画面で確実に視覚化します。SmartInsights を使用すると、お客様は予知保全、リモートアセット監視、再生可能資産の性能予測と保守などのユースケースを解決できます。 Radix Engineering は、産業界のお客様がエッジに保存されている時系列データを活用し、AWS IoT SiteWise を使用して従来の産業オペレーション技術 (OT) アーキテクチャを最新化できるよう支援すると同時に、統合された機械学習 (ML) モデルと洞察により運用と信頼性の向上を促進することに重点を置いています。 これらのパートナーソリューションはそれぞれ、特定の産業上の課題に対処するだけでなく、長期的なビジネス価値と効率性を実現するためにデジタルトランスフォーメーションの取り組みを成功させる上で、専門知識と AWS IoT SiteWise などの高度なツールが果たす重要な役割を示しています。 変革の青写真 トヨタ自動車北米と Bristol Myers Squibb の成功事例は、他の企業の青写真として役立っています。これらのリーダーをはじめとする多くの企業が、スケーラブルで再現性のある産業データ基盤を提供するサービスとして AWS IoT SiteWise を採用し、それを日常業務に統合し、過去およびリアルタイムの機器データの力を活用してデジタルトランスフォーメーションの価値を実現しています。 AWS IoT SiteWise を開始するには、 ここをクリック してください。 re:Invent 2023 に参加する場合は、以下のセッションに参加して、これらの新機能を深く掘り下げてください。 IOT206 | Accelerating industrial transformation with IoT on AWS IOT215 | Accelerate shop floor digitization with edge-to-cloud data integration IOT212 | Modernizing your data historian with AWS IoT SiteWise IOT203 | Automated anomaly detection for smart manufacturing この記事は Sophie Pagalda、Sharon Allpress、Jan Borch、David Castro によって書かれた The Blueprint for Industrial Transformation: Building a Strong Data Foundation with AWS IoT SiteWise の日本語訳です。この記事は Solutions Architect の西亀真之が翻訳しました。

はじめに モノのインターネット ( IoT ) ワークロードを導入しようとする場合、企業はプラットフォームを複数の選択肢から選択することになります。この選択肢はさまざまで、独自デバイスのハードウェアを含めて完全にゼロから構築する方法や、事前に設定されたハードウェアを購入して、完全な SaaS (Software as a Service) IoT プラットフォームに接続するような方法があります。 このブログの目的は、IoT ソリューションの設計に必要なスキルや知識を理解し、どのコンポーネントを自前で開発して、どのコンポーネントを外部の技術ソリューションとして買ってくるのかを判断できるようにすることです。IoT ワークロードを AWS に移行しようと考えている場合は、 「  AWS IoT Core へのシームレスな移行を計画する  」 をご参照ください。 AWS を利用することによる、移行プロセスの簡略化、提供可能なサポート、得られるメリットなどを理解するための最初のステップとして役立ちます。 一般的な AWS IoT アーキテクチャのコンポーネント デバイスの製造 ハードウェアの設計と製造では、考慮すべき要素がいくつかあります。 要件に基づき、ソリューションの現在および将来のニーズを満たすためにハードウェアを選択する必要があります。 IoT の一般的な制約、つまり電力(供給と消費)、接続性、セキュリティ、オペレーティングシステムの管理に関する意思決定が必要です。 ハードウェアを社内で製造していない場合、オリジナルデバイスメーカー ( ODM ) を選択する必要があります。ODM には、大量のデバイスを生産するための製造ライン、ツール、プロセスが揃っています。 通常、プリント基板 ( PCB ) の回路図、部品表、ファームウェア、プロビジョニング要件など、提供する仕様に基づいて製造できます。 デバイスのハードウェア制約を考慮する項目 : 消費電力 : デバイスの使用方法と場所は、電源供給に大きな影響を与えます。ウェアラブルデバイスは小さなバッテリーで動作しますが、テレビは AC 電源を必要とします。バッテリーを必要とするデバイスの場合、バッテリーが再充電可能か交換可能か、ハードウェアの寿命まで利用可能かを判断する必要があります。 オペレーティングシステムとファームウェア : オペレーティングシステムやファームウェアの選択は、デバイスの種類と期待されるタスクによって異なります。小型で低消費電力のデバイスは FreeRTOS などの リアルタイムオペレーティングシステム が必要かもしれませんし、大型で専用の電源を必要とするデバイスは Linux などのフルスタックオペレーティングシステムが必要になる場合もあります。 接続性 : IoT ソリューションには、 イーサネット 、 Wi-Fi 、 セルラー 、 LoRaWAN 、 Bluetooth Low Energy ( BLE ) など、多くの接続性とプロトコルのオプションがあります。デバイスの設置場所、可用性、消費電力、セキュリティ、ユースケースによって、ソリューションに最適な接続オプションが決まります。 AWS ではこのコンポーネントを支援するために、 AWS デバイス認定プログラム  を完了した AWS パートナー製デバイスのリストである AWS Partner Device Catalog  を提供しています。 このリストにあるデバイスは、AWS IoTとAWSのベストプラクティスとの互換性を確保し、市場への投入を高速化するのに役立ちます。さらに、自社製造のデバイスをお持ちの場合は、 AWS IoT Core Device Advisor  を使用して、AWS IoT Core と確実かつ安全に接続できることを検証できます。 デバイスのプロビジョニング IoT ソリューションにおけるデバイスのプロビジョニング方法は、デバイスの機能とその製造プロセスによって異なります。ここでの主な焦点は、デバイスとその認証情報の作成方法にあります。 セキュリティは、あなた、エンドユーザ、デバイス製造業者にとって最優先事項であるべきです。X.509 証明書を使用する場合、製造プロセスで、デバイスが一意となる証明書と秘密鍵のペアを取得するタイミングと、IoT ソリューションにどのように登録するかを明確にする必要があります。 デバイスプロビジョニングと証明書管理を検討する際のポイント : メーカーの選択 : 信頼できる証明書チェーンは、ハードウェアを社内開発または OEM パートナーを選択することから始まります。後者の場合、サプライチェーン全体で証明書の整合性が維持されていることを確認するために、そのプロセスを検査する必要があります。  認証局 ( CA ) : デバイスの製造に柔軟性を持たせるために、AWS では独自の CA、サードパーティの CA、 Amazon ルート認証局 ( CA )  など、複数の選択肢を用意しています。  ハードウェアセキュリティモジュール  : IoT デバイスに組み込まれたセキュアエレメントは、デバイスセキュリティの基盤を形成します。これにより、証明書やシークレットの暗号化と改ざん防止の保存、ファームウェアとアプリケーションの検証が可能になります。これを支援するために、AWS には  AWS IoT ExpressLink を搭載したさまざまな接続モジュールがあります。これらのモジュールには AWS が要求するセキュリティ要件を実装したソフトウェアが含まれています。 外部リソース : カスタムプロビジョニングプロセスを可能にするために、IoTソリューション内でのリソース作成が必要になる場合があります。 これらのリソースは、デバイスの稼働台数が増加するにつれてスケールするように設計する必要があります。 AWS の場合、これは  Pre-provisioning hook  として機能する  AWS Lambda function になる可能性があります。 デバイスレベルのロジック : デバイスには、確実かつ安全にプロビジョニングされるため、オンデバイスのロジックが必要になる場合があります。 AWS では、 AWS IoT SDKs  はこのオンデバイスのロジックを可能にするために設計されています。 AWS IoT Core を使用したデバイスのセキュアなプロビジョニングと登録の詳細については、 AWS IoT Core Device Provisioning  や AWS ホワイトペーパーの  Device Manufacturing and Provisioning with X.509 Certificates in AWS IoT Core  をご参照ください。 デバイス管理 成熟したプロビジョニングのプロセスがあれば、デバイスは最初に接続したときからセキュアで最新の状態に保たれますが、ファームウェアや証明書のローテーションなどの更新が必要になる場合があります。完全にコンプライアンスを遵守し、最高のユーザーエクスペリエンスを提供するためにはこうした更新が必要です。これらの更新のためのソリューションは、配信の中断、接続性、ロールバックルーチン、自動スケーリングへの対応が必要となるでしょう。 デバイス管理戦略を検討する際の考慮事項 : デバイス整理 : デバイスをすばやく識別し操作できることで、コンプライアンスから外れた場合のトラブルシューティングと隔離が可能になります。多数のデバイスを運用する場合、デバイスの整理、インデックス作成、分類を行うソリューションが必要になります。AWS では、 Fleet Hub for AWS IoT Device Management  を使用できます。 デバイス監視 : デバイス群のステータスを監視できることは、誤動作やコンプライアンス違反のデバイスを特定するのに重要です。デバイスのメトリクス、ログ、設定などの観測データとセキュリティデータを収集する監視ソリューションを用意してください。 AWS IoT Device Defender は、稼働している多数のデバイスのセキュリティのための監査と継続的なインテリジェントな監視を提供します。 イベントへ対応 : ログ、メトリクス、アラームの最小セットを定義することで、運用チームは大きなビジネスの中断を防ぐことができます。監視ソリューションと統合できるスケーラブルなアラートソリューションが必要です。AWS では  Amazon CloudWatch  を使用できます。 Over-The-Air ( OTA ) アップデート対応  : デバイスは更新を受信して適用できるように設計する必要があります。IoT ソリューションは更新を送信し、デバイスの更新進捗を監視できる必要があります。AWS では、 AWS IoT Device Management Jobs  を使用できます。 このコンポーネントを支援するために、 AWS IoT Device Management 、 AWS IoT Device Defender 、 AWS IoT Core  は、稼働している IoT デバイス全体のデバイス整理、監視、アラート、OTA 更新のための完全な機能セットを提供します。 デバイスデータの取り込み すべての IoT ソリューションがデータ取り込みに焦点を当てるわけではありませんが、そうしたソリューションでは、このデータ取り込みがプライマリなコンポーネントとなり、ソリューションの全体的なアーキテクチャに影響します。このコンポーネントに対する要件は、ソリューションのスケール、コスト、セキュリティ、パフォーマンスに影響するため、現在と将来のデータ取り込みを考慮した IoT ソリューションのアーキテクチャを設計する必要があります。 データ取り込み戦略を検討する際の考慮事項 : データサイズ : デバイスがハードウェア的に制約されていない場合、効率を高めるためにメッセージサイズを一定に 保ち、小さいメッセージをバッチ処理することを検討してください。バッチ処理は、メッセージ送信時だけでなく、IoT Core に取り込んだ後に IoT ルールを使用して実行できる ことに留意してください。 データの頻度と構造 : デバイスがメッセージを送信する頻度を考慮し、ソリューションがそのスケールに対応できるように設計してください。頻度に加えて、データの構造がメッセージベースかストリーミングベースの IoT ワークロードかを決定します。 MQTT トピック設計 : このプロトコルを使用する場合は、最小限の権限コミュニケーションを実施しつつ、将来のデバイス導入をサポートできるスキーマのバランスをとる必要があります。適切なトピックスキーマは 、柔軟なメッセージフィルタリングとメッセージルーティングを可能にする共通の命名規則を実装します。 データストレージ : メッセージのフローと使用法を分析し、適切なストレージソリューションを特定してください。これらのストレージソリューションは、ユースケース、全体的なメッセージ構造、スケール ( 現在と将来の成長 ) 、コストなど、複数の考慮事項があります。  ルーティング : 取り込んだ後、メッセージをストレージや他のサービスにルーティングするための、ルールベースの簡単なソリューションが必要です。これらのルールは、さらなるメッセージのバッチ処理、処理、アラートなどに使用できます。  エッジゲートウェイ : 一般的なアーキテク チャパターンは、データを取り込み、処理、バッチ処理してから IoT ソリューションに送信するゲートウェイまたはブローカーを用意することです。これは、デバイスに近いローカルエンドポイント、または IoT ソリューションに近いクラウドベースのゲートウェイとして実装できます。 このコンポーネントの支援として、AWS IoT Core を使用すると、インフラを管理することなく、 数十億ものIoTデバイスを接続 し、 Amazon SQS  、 Amazon Kinesis 、 Amazon SNS などの他の AWS サービスに 何兆ものメッセージをルーティング できます。AWS には、エッジランタイムを提供するオープンソースの  AWS IoT Greengrass  もあります。AWS IoT Core を使用したデータ取り込みのパターンの詳細は、AWS IoT ブログの「 IoT データの取り込みと可視化のための7つのパターン – ユースケースに最適なものを決定する方法 」をご参照ください。 リアルタイムのビデオとデータストリーム 前のセクションで説明したものに加えて、IoT ワークロードがビデオやその他の高容量データストリームで構成されている場合は、さらにいくつかの点を考慮する必要があります。データストリームを扱う IoT ワークロードは、ビデオ処理や分析などのアプリケーション向けに、高頻度かつ非構造化の生データを扱うことが多くなります。 ストリーミングベースのワークロードを考慮するポイント :  プロデューサ側 : データストリームがどのように生成されるかは、IoT ソリューションの下流でどのようにインジェスト、処理、保存されるかに直接影響します。 デバイスのストリーミングプロトコル、ネットワークの可用性、アクセシビリティ 、コストの制約などの側面が、ストリームの生成方法に影響します。  コンシューマ側 : データストリームの消費と処理は、IoT ソリューションの必要なスケールと全体的なコストに影響を与える可能性があります。ビデオストリームなどの高頻度データは、高可用性で管理が容易で、スループット要件を処理できる堅牢なアーキテクチャーが必要になります。 これらのストリームの直接的なビジネス価値を総合的な IoT ソリューションで考慮して、最もコスト効果的かつスケーラブルな方法で消費および処理することを決定してください。  このようなアーキテクチャを支援するために、AWS には AWS IoT Greengrass 、Amazon Kinesis 、 Amazon Kinesis Video Streams があります。 AWS IoT Greengrass は、エッジでデータストリームを 容易に消費および処理し、 AWS 提供のコンポーネント を介して AWS に転送できるエッジランタイムを提供するオープンソースです。 Amazon Kinesis は、 デバイスから直接 、AWS IoT Greengrass Stream manager コンポーネント から、または AWS IoT ルール から生成されるストリーミングデータをコスト効果的に処理および分析できるマネージドサービスです。 Amazon Kinesis Video Streamsは、デバイスから直接、または AWS IoT Greengrass の Edge connector for Kinesis Video Streams  を介して生成されたビデオストリームを、ソースプロトコルに関係なく安全に表示、処理、分析できるマネージド AWS サービスです。 デバイスのコマンド・アンド・コントロール コマンド・アンド・コントロールは、デバイスにアクションの実行を要求するメッセージを送信し、成功または失敗の確認応答を受け取る操作です。これは、デバイスへのコマンドメッセージまたは IoT ソリューションからデバイスの状態を変更して伝達することで実現できます。データ取り込みとコマンド・アンド・コントロールのための IoT ソリューションのメッセージングニーズを評価および最適化することで、パフォーマンスとコストのバランスが最適になります。 デバイスのコマンド・アンド・コントロール戦略についての検討パターン : コマンドメッセージング : 選択したメッセージングプロトコルを使用して、コマンドを直接デバイスに送信します。デバイス側のロジックを実装して、コマンドの受信、実行、デバイスの実行ステータスの報告をする必要があります。このパターンでは、IoT ソリューションでコマンドメッセージを確実に配信する必要があり、デバイスがオフラインになったり接続が切断された場合には、対処可能な障害が発生することに留意してください。 デバイスの状態 : デバイスの状態は IoT ソリューションで処理し、コマンドの設定や実行ステータスの更新に使用できます。この状態は、IoT ソリューションからの変更があった際にデバイスへ送信され、デバイス自身が変更を加えた場合にもそれを送り返すことができる、単純なドキュメントとすることができます。このパターンでは、デバイスが接続されていなくても、IoT ソリューションと対話できます。 このコンポーネントを支援するために、AWS IoT Core は  AWS IoT Device Shadow service 　、 MQTT5 リクエスト/レスポンスパターン 、AWS IoT デバイス管理は AWS IoT Job 機能 を提供しています。デバイスのコマンド・アンド・コントロールの実装パターンの詳細は、「 AWS IoT Lens for the AWS Well-Architected Framework 」の デバイスコマンド の項を参照してください。 クラウドアーキテクチャ IoT ソリューションがクラウドに存在する場合、地域を限定した1つのサービスや小規模なデバイス群から始めることができます。これは概念実証やデモンストレーションには十分ですが、ソリューションを本番に移行する際には、クラウドベースのベストプラクティスを考慮して構築されていることを確認する必要があります。「 AWS Well-Architected framework  」は、ソリューションの設計、構築、レビューの際に、AWS を安全かつ高パフォーマンス、回復性が高く、効率的に使用していることを確認するのに役立ちます。AWS IoT におけるクラウドベースのベストプラクティスの詳細は、 IoT Lens – AWS Well-Architected Framework  を参照してください。 まとめ このブログでは、典型的な IoT ソリューションを構成する主要な技術要素に分解し、それぞれについて考慮すべき要件と注意点を明らかにしました。IoT ソリューションの構築は間違いなく複雑ですが、AWS IoT を活用することによって、その道のりを簡素化、合理化することができます。さらに、 AWS パートナー が構築した AWS IoT ソリューションを利用することで、市場投入までの時間を短縮することもご検討ください。 著者紹介 Kai-Matthias Dickman  は、Amazon Web Services ( AWS ) の IoT ソリューションアーキテクトです。大企業の開発者や意思決定者と協力して、AWS IoT サービスの導入を推進することを楽しんでいます。IoT とクラウドに関する深い知識を持っており、スタートアップから大企業に至る世界中のお客様と協力して、AWS エコシステムを使った IoT ソリューションの構築を可能にする役割を担っています。 Nicholas Switzer  は、Amazon Web Services の IoT ソリューションアーキテクトです。2022年に AWS に加入し、IoT 、エッジコンピューティング、コネクテッドプロダクト分野を専門としています。アメリカに拠点を置き、日常生活を改善するスマートプロダクトの構築を楽しんでいます。 この記事は Kai-Matthias Dickman  ,  Nicholas Switzer  によって書かれた Deploying and managing an IoT workload on AWS  の日本語訳です。この記事は ソリューションアーキテクト の伊藤 一成が翻訳しました。

e コマース市場は年々拡大を続けており、小売業界のさらなる変革を後押ししています。小売業者は、より多くの顧客を EC サイトへ呼び込むことに尽力しており、特にブラックフライデーやサイバーマンデーなどのピーク時の売上において、EC サイトが占める割合が高まっています。 Statista によると 、2022 年第 3 四半期、米国の小売業全体の売上において、 e コマースの占める割合は 14.8 ％ で、これは前四半期を上回っており、金額にして約 2660 億ドルになります。 小売業のリーダーが、e コマース事業から更なる価値を得る方法を模索しているのは、驚くことではありません。そのため、多くの企業がウェブサイトのトラフィックを監視し、売上に影響を与え得るオンラインアクティビティの変化の兆候を見つけ出そうとしています。例えば、トラフィックが減少することは、製品の価格設定が最適でなかったことや、システム障害などの要因により、需要が減少したことを示す可能性があります。いずれにせよ、売上は打撃を受けることになります。 一方、e コマースのトラフィックが急増することは、小売業者にとって良いことのように思えますが、必ずしもそうとは限りません。例えば、価格設定にミスがあり、オンラインショップの顧客がとんでもない安値で商品を買い占めていった場合です。最近、ある大手小売業者が、ウェブサイト上の小数点の位置を間違えて、100 ドルの人気商品をわずか 10 ドルで表示したことがありました。オンラインショップの顧客は大喜びで商品を大量に注文し、小売業者はこの不手際を修正し、さらなる損失を食い止めるために奔走することになりました。 どちらのシナリオでも、重要なのは、e コマースのトラフィックを常に把握し、発生した問題を解決するためにチームを迅速に動員することです。そこで、アマゾン ウェブ サービス（ AWS ）の人工知能と機械学習ソリューションが役に立ちます。小売業者は、ビデオやデータストリームをリアルタイムで収集、処理、分析できる Amazon Kinesis や、メトリクス内の異常を自動的に検出し、その根本原因を特定する Amazon Lookout for Metrics などのサービスから多大なる恩恵を受けることができます。 トラフィックの変動に対処する 小売業者は、e コマースのトラフィックが季節、月、日付、時間帯によって大きく変化することをご存じでしょう。例えば、多くの e コマースサイトでは、朝方の時間帯よりも夕方の時間帯でトラフィックが多くなります。また、平日ではなく、週末にトラフィックが急増するケースもあります。一方、休日やその他のピーク時のトラフィックは、これらのトレンドのいずれにも当てはまらないかもしれません。このように動的で様々なパターンがあるため、ユーザートラフィックの少数派な異常をニアリアルタイムで検出することは非常に困難です。 大規模な e コマースを展開する企業の多くは、ユーザートラフィックの主要な異常を検出するための手順をすでに整えています。しかし、これらのプロセスは、静的なアラートや手動による監視技術に依存していることが多く、少数派な異常をニアリアルタイムで検出することは困難であり、問題が起こった際にチームが迅速に介入し、対応することが難しくなっています。 小売業者は、過去のデータパターンに基づいて、ユーザートラフィックのわずかな変化を検出することができるスマートなソリューションを必要としています。しかし、静的なルールに基づいてこれらの傾向をプログラミングすることは、非常に時間がかかり、導入後の効果もあまり期待できないことがあります。 予想されるトラフィックの変動を考慮しつつも、小売業者が自動的に少数派な（そして主要な）異常を検知したい際に、AWSの異常検知ソリューションがどのように役立つかを詳しく見ていきましょう。 図1. e コマーストラフィックのための異常検知ソリューションのアーキテクチャ AWS の異常検知ソリューションとの連携 このソリューションは、データ収集と異常検知を自動化し、データを操作して、重大性に基づいて異常をフィルタリングするためのグラフィカルユーザーインターフェースを提供します。ここからは、このソリューションがどのように機能するかを説明します。 顧客は、オンラインショッピングのために e コマースアプリケーションを利用します。   プロセスは、顧客がモバイルまたはデスクトップアプリケーションを使用して、e コマースのウェブサイトで商品を検索し、表示することから始まります。買い物かごに商品を入れた後、決済ページで購入を完了します。これらのページのトラフィックは、時間間隔に基づくデータの塊に分解されます。これらは、トラフィックのパターンを理解するために使用できるデータポイントとして機能します。 データは、取り込まれ、変換され、保存されます。   e コマースアプリケーションは、複数のフォーマットと異なる量のデータを生成します。それを理解するためには、データを継続的に取り込むストリーミングプラットフォームにデータを供給する必要があります。このソリューションでは、 Amazon Kinesis Data Streams （あらゆる規模のデータストリームの取得、処理、保存を支援）を使用して、ユーザーのトラフィックを取得し、e コマースアプリケーションとのやりとりを記録します。通常、収集したデータを修正または「変換」して、迅速な分析や機械学習に適した形式で保存する必要があります。 Amazon Kinesis Data Firehose （ストリーミングデータを取り込み、変換し、データレイク・データストア・分析サービスに配信することができるサービス）や AWS Lambda （サーバーやクラスタを意識せずにコードを実行できるサーバーレス、イベント駆動型のコンピューティングサービス）などの AWS サービスは、データを変換して分析用に準備するために役立ちます。データは、どこからでもどんな量のデータでも取り出せるように構築されたオブジェクトストレージサービス、 Amazon Simple Storage Service (Amazon S3) を使って、効率的にクラウドに保存されます。 トラフィックの異常を検出し、チームに通知します。   データをニアリアルタイムで分析し、異常を特定する準備が整ったので、ここからが Amazon Lookout for Metrics の出番です。まずは、Amazon Lookout for Metrics で 検出器 を作成し、Amazon S3 データリポジトリからデータを自動的に取り込むことから始めます。検出器が起動すると、Amazon Lookout for Metrics はデータの監視を開始し、異常があればニアリアルタイムでフラグを立てます。誤検知を減らすために、検知システムの感度を 0 から 100 の間で調整することができます。機械学習技術を使用して、Amazon Lookout for Metrics は、トラフィックパターンからフィードバックを得て、時間の経過とともに検出結果の継続的な改善をします。当然ながら、異常があればチームメンバーに通知したくなるでしょう。通知により、ウェブサイトで何が起きているのかを理解でき、必要に応じて迅速に是正措置を講じることができるようになります。このソリューションは、 Amazon Simple Notification Service (Amazon SNS) とシームレスに統合されており、SMS テキストメッセージ、モバイルプッシュ、電子メールを通じてアラートや通知を自動的に送信することができます。 まとめ AWS の異常検知ソリューションにより、小売業者は e コマースのトラフィックを監視し、売上に影響を与え得るトラフィックパターンの異常を迅速に検知するための強力なツールを手に入れました。これは、従来の静的アラートや手動による監視技術を大きく前進させるものです。オンライン販売の拡大と不必要な損失の回避を目指す小売業者にとって、このAWSのソリューションは、コストと時間のかかる自社開発ソリューションに投資することなく、目標を達成するための効果的な方法となり得るでしょう。 各サービスの詳細は Amazon Lookout for Metrics Developer Guide Amazon Kinesis Data Streams Developer Guide Amazon Kinesis Data Firehose Developer Guide 著者について Aditya Pendyala Aditya は、NYC を拠点とする AWS のシニアソリューションアーキテクトです。クラウドベースのアプリケーションのアーキテクトとして豊富な経験があります。現在、大企業向けに、拡張性、柔軟性、耐障害性に優れたクラウドアーキテクチャの構築を支援し、クラウドに関するあらゆることの案内をしています。Shippensburg 大学でコンピュータサイエンスの理学修士号を取得しました。また、彼は、” When you cease to learn, you cease to grow “という言葉を信条としています。 翻訳は Solutions Architect 金成が担当しました。原文は こちら です。

テレコム 5G および IMS コンテナベースのワークロードは、 Multus CNI を利用してトラフィックとルーティングの分離とパケットアクセラレーションを実現します。Multus コンテナネットワークインターフェイスプラグインを使用すると、Kubernetes ポッドを複数のインターフェイスとネットワークに接続できるようになります。Multus CNIは「メタプラグイン」であり、 VPC CNI ( Amazon Elastic Kubernetes Service (Amazon EKS) のデフォルト CNI)、 IPVLAN CNI などの他のCNIを呼び出すことでこれを実現します。VPC CNI は Kubernetes ポッドのプライマリインターフェイスを管理しますが、IPVLAN CNI では、ワーカーノードの Elastic Network Interface (ENI) 上の同じ MAC アドレスを使用することで、ポッドがワーカーノードのセカンダリインターフェイスを使用できるようになります。Multus CNI は、 host-local 、 static 、および whereabouts などの IPAM CNI も呼び出します。 「 Amazon EKS now supports Multus CNI 」の記事は、Amazon EKS で Multus ワークロードをデプロイし始めるのに役立ちます。Amazon EKS に Multus ベースのワークロードをプロダクション向けにデプロイするには、次の 2 つのトピックの管理を計画する必要があります。 Multus ワーカーノードグループ: ワーカーノードサブネット、およびワーカーノードの IP アドレス管理。各ワーカーノード ENI にはサブネットの IP アドレスが必要 Multus ポッドネットワーク: ワーカーノードサブネットからの Multus ポッドの IP 管理、および Amazon Virtual Private Cloud (Amazon VPC) でのポッド通信。 この記事では、標準の Multus ノードグループのデプロイ方法と、Amazon VPC 内の Multus ワークロードで ipvlan CNI を使用する際の上記のトピックを管理するための課題とアプローチについて説明します。 標準的な Multus ノードグループ導入アプローチ 上の図は、IPVLAN CNIを使用した Multus ワークロードのデプロイ例を示しており、この記事で説明していきます。この例では、Amazon EKS クラスターと 2 つのワーカーノードを持つノードグループがあります。両方のワーカーノードは、次のように 2 つのサブネットに接続されます。 eth0 ネットワーク:10.10.12.0/24 (VPC CNI、即ちポッドのプライマリインターフェイスに使用) eth1 ネットワーク:10.10.1.0/24 (Multus ipvlan cni、即ちポッドのセカンダリインターフェイスに使用) 上のサンプルデプロイ方法では、デプロイは Amazon EKS クラスターデプロイから始まり、その後に Amazon EKS ノードグループのデプロイが続きます。ノードグループがデプロイされたら、Multus CNI と関連するプラグインをデプロイしてワークロードをサポートできます。プラグインがデプロイされたら、ワークロードをデプロイできます。 次のセクションでは、Multus ワーカーノードグループと IP 管理のデプロイ戦略について説明します。 Multus ワーカーノードグループのデプロイと IP 管理 Multus ワーカーノードデプロイ 自己管理型の Multus ノードグループは、オートスケーリンググループを使用して復元力（最小限のワーカー数を維持）とスケーラビリティを提供します。オートスケーリンググループは、 起動テンプレート を使用して Amazon Elastic Compute Cloud (Amazon EC2) ワーカーノードを構成します。オートスケーリンググループは、起動テンプレートと組み合わせて、同じサブネットに属する単一または複数のインターフェースを持つワーカーノードを作成できます。カスタムデプロイメント戦略では、カスタム AWS Lambda を使用して、異なるサブネットからの複数のネットワークインターフェイスアタッチを実現します。これにより、Amazon EC2 オートスケーリングライフサイクルフックに Multus インターフェイスが追加されます。 次の図に示すように、デプロイメントはオートスケーリンググループが起動テンプレートを使用して単一インターフェイス (eth0) のワーカーノードを作成するところから始まります。ワーカーが起動すると、カスタム Lambda が単一のインターフェイスノードを終了します。このスケールインにより、「autoscaling: EC2_INSTANCE_TERMINATING」イベントが発生し、カスタム Lambda がトリガーされてからノードをドレインします、もしくは何も行われません。 このイベントが完了すると、オートスケーリンググループは必要な容量を満たすためにスケールアウトし、「autoscaling: EC2_INSTANCE_LAUNCHING」イベントが発生します。このイベントはカスタム Lambda 関数をトリガーし、タグ (key: node.k8s.amazonaws.com/no_manage 値: true) を使用して Multus サブネットからセカンダリインターフェイスを追加します。 EKS Multus ノードグループの作成フロー ワーカーノードの IP 管理に関する課題 オートスケーリンググループは、Amazon EKS ワーカーノードグループに弾力性と復元力を提供し、すべてのインターフェイスに DHCP IP 割り当てを使用して同じようにサポートします。一方、Multus ポッドの場合、非 VPC IPAM CNI（ host-local 、 whereabouts 等）は、静的アドレス範囲/プールを使用してセカンダリインターフェイスでの IP 割り当てを管理します。ポッドの出力/入力は対応するワーカー ENI を介して行われるため、ポッド IP とワーカー ENI IP アドレスはサブネットから取得する必要があります。アプリケーション計画者は、Multus network-attachment-definition の構成とアノテーションによって、Multus ポッドの静的 IP 範囲を割り当てます。 同じサブネット上の 2 つの異なる別々の IP 割り当て方法 (DHCP と静的) は、ワークロードのデプロイにおいて興味深い課題となります。DHCP によるワーカーノードの IP 割り当てはランダムであり、他の静的割り当てを認識しないため、ポッドに対して計画された静的 IP 範囲から任意の IP アドレスを取得できます。Multus IPAM CNI ( host-local 、 whereabouts 等) は、この割り当てを認識しません。この IP アドレスがワーカーインターフェイスによって取得されると、アプリケーションポッドで IP 競合が発生し、IP 割り当てが失敗し、予期しないアプリケーションのデプロイが発生してしまいます。 ソリューション 以下のセクションでは、ワーカーノードと Multus ワークロードの IP アドレスを競合しない方法でより適切に管理するための 2 つの方法を紹介します。 アプローチ 1: カスタム Lambda を使用してワーカー IP を静的に割り当てる このソリューションアプローチは、ワーカーとポッド間の論理サブネット共有モデルで機能します。このアプローチでは、ワーカーノードはサブネットの最初から未割り当ての IP を取得し、Multusポッドはサブネットの終わりから未割り当ての IP を取得します。この割り当て戦略では、IP アドレスはワーカーノードインターフェイスにランダムに割り当てられるのではなく、IP 割り当てはサブネットで最初に空いている空き IP から静的に行われます。 詳細な説明、サンプル AWS CloudFormation テンプレート、サポートされている Lambda 関数については、GitHub リポジトリ「 Allocate Worker IPs statically via a custom lambda-based solution 」を参照してください。 アプローチ 2: ポッドの IP アドレスに VPC サブネット CIDR 予約 (静的) を使用する このアプローチでは、 VPC サブネット CIDR 予約 戦略を使用して、ワーカーノードと Multus ポッドの IP アドレス割り当てを分離します。このアプローチでは、Multus ポッドの IP CIDR 範囲を静的として明示的に予約でき、Amazon EC2 ワーカーノードの DHCP がこのブロックからワーカーノードに IP アドレスを割り当てないようにすることができます。 これを実現する為に、明示的 (静的) 割り当てのみを目的として、ポッド IP アドレスの塊に対して 1 つ以上のサブネット CIDR 予約を作成できます。サブネット CIDR の予約されていない塊は、オートスケーリンググループの背後にあるワーカーノードへの DHCP（デフォルト）割り当てに使用できます。 詳細な説明、サンプルの CloudFormation テンプレート、およびサポートされている Lambda 関数については、GitHub リポジトリ「 Use VPC subnet cidr reservation (static) for pods IP addresses 」を参照してください。 自動 Multus ポッドネットワーキング Amazon EKS クラスターと Multus ノードグループが前述のアプローチのいずれかでデプロイされたので、Multus を使用して Amazon EKS にワークロードをデプロイできます。次のステップとして、 git リポジトリ に記載されているように Multus CNI をデプロイし、 whereabouts IPAM CNI をインストールします。この記事では、 whereabouts IPAM CNI を使用してクラスターの一意の Multus IP アドレスを管理しています。 ここで、VPC での IP 通信の仕組み、ルーティングを有効にする方法、および自動化された方法で Multus ポッドに IP を割り当てる方法を理解しましょう。 Multus ポッドのIP 管理とルーティングの課題 次の例では、Multus ポッドをデプロイすると、セキュリティグループルール/NACL がトラフィックをブロックしていない場合でも、異なるワーカー上のポッド間通信が機能しないことに留意してください。ただし、同じワーカーノード上のポッド間の相互通信は正常に機能します。 ここでは、この動作について詳しく説明します。Amazon VPC クラウドは、ワークロードにレイヤー 3 ネットワーキングを提供します。ENI は、1 つ以上の IP アドレスと対応する MAC アドレスを含む論理ネットワークエンティティです。Amazon VPC は、ENI に割り当てられた IP アドレスに基づいて、トラフィックを正しい宛先にルーティングします。Amazon EC2 ワーカーノードに接続されている各 ENI には、適格な IP アドレスが割り当てられている必要があります。 ポッドのプライマリインターフェイスでは、Amazon VPC CNI は DHCP を使用してプライマリポッド IP アドレス (上の図では 10.10.12.x) をポッド eth0 (VPC CNI マネージドインターフェイス) に割り当て、これらの IP をワーカーノード ENI のセカンダリ IP として割り当てます。非 VPC IPAM CNI (whereabouts、host-local、static 等) は、IP アドレスを Multus ポッドに割り当てます。したがって、Amazon VPC はこの IP アドレスの割り当てを認識しません。さらに、これらの IP アドレスは、それぞれのワーカーノード ENI (上の図では eth1) のセカンダリ IP として割り当てられません。 Amazon EC2 コンソールでワーカーノードの ENI を調べることで同じことを確認できます: Amazon EC2 コンソール → インスタンス → インスタンスの選択 (ワーカー) → アクション → ネットワーキング → IP アドレスの管理。 この問題は、ポッドが想定する IP アドレスがそれぞれのワーカー ENI に割り当てられると解決されます。これらの IP がそれぞれの ENI (例: eth1) に割り当てられると、Amazon VPC は割り当てられた IP の マッピングを ENI へ更新し、指定された Multus IP アドレスにトラフィックをルーティングします。 次の例では、Multus ポッド IP アドレス 10.10.1.80 および 10.10.1.82 が、最初のワーカーノードの eth1 ENI 上のセカンダリ IP アドレスとして割り当てられます。同様に、10.10.1.81 セカンダリ IP が 2 番目のワーカーノード eth1 ENI に割り当てられます。 自動化ソリューション Amazon EC2 の IP アドレスの割り当て/IP アドレスの割り当て解除 API 呼び出しにより、ワーカーノード ENI での IP 割り当てを自動化できます。 git リポジトリ にあるサンプル Python コードとスクリプトでも同じ結果が得られます。 以下で説明する自動化アプローチでは、アプリケーションイメージやソースコードを変更する必要はありません。これらのポッドでカスタムの「IP 管理」コンテナを利用して、アプリケーションコンテナやそのアーキテクチャに影響を与えることなく、それぞれのワーカーノード ENI で IP 割り当ての自動化を実行できます。この追加のコンテナを使用して、ワークロードの pod/deployment/statefulset の仕様を強化できます。 この機能を提供し、次のいずれかのソリューションオプションで使用できる Docker コンテナイメージをビルドするには、「 How to build 」を参照してください。 アプローチ1: InitContainer ベースのIP 管理ソリューション このソリューションは、フローティング IP (次のアプローチで説明) などの特別な処理やカスタム処理を行わなくても、ほとんどの ipvlan CNI ポッドで機能します 。このアプローチでは、ワーカーに追加の CPU/メモリ要件の制約が追加されません。 この「IP 管理」コンテナは、ポッドが init 状態のときに最初のコンテナとして実行されます。このコンテナは、ポッドが初期 (init) 状態にあるときに、ポッドの IP アドレスを確認し、その IP アドレスを ENI に割り当てます。Multus IP アドレスがワーカーノード ENI に正常に割り当てられると、この initContainer は終了し、ポッドは初期状態から抜け出します。 このソリューションを使用するには、 InitContainer IP management ドキュメントとデプロイ手順を参照してください。 Amazon EC2 コンソールでワーカーノードの ENI を調べることで、同じことを確認できます。Amazon EC2 コンソール → インスタンス → インスタンスの選択 (ワーカー) → アクション → ネットワーキング → IP アドレスの管理。 アプローチ 2: サイドカー IP 管理ソリューション このアプローチでは、「IP管理」コンテナはサイドカーコンテナとして動作します。さらに、initContainer とは異なり、Multus インターフェイス上のポッド IP アドレスを常に監視して、新規または変更された IP アドレスがないかどうかを確認します。これは、アクティブ/スタンバイポッドに対するカスタムの「フローティング IP」処理を持つポッドにとって役立ち、内部ロジックに基づいて、トラフィックを中断することなく「フローティング IP」がスタンバイポッドにフェイルオーバーします。この場合、サイドカーは IP アドレスの変更についてポッドを常に監視するため、Multus ベースのポッドごとにこのコンテナ用の CPU/メモリ (最小限) が追加で使用されます。 このソリューションを使用するには、 Sidecar IP management Solution のドキュメントと手順を参照してください。 Amazon EC2 コンソールで確認できます: Amazon EC2 コンソール → インスタンス → インスタンスの選択 (ワーカー) → アクション → ネットワーキング → IP アドレスの管理。 クリーンアップ この記事でデプロイされたサンプル Multus ワークロードをクリーンアップするには、GitHub リポジトリの「 Cleanup 」を参照してください。さらに、今後の料金の発生を避けるために、CloudFormation コンソールから Multus Worker ノードグループを削除してください。Amazon EKS クラスターは Amazon EKS コンソールから削除できます。 まとめ この記事では、Amazon VPC クラウド内のワーカーノードと Multus ポッドの IP アドレスの IP 割り当て、管理、分離の際にお客様が直面する課題について説明しました。さらに、Multus ポッドがどのように Amazon EKS および Amazon VPC スコープで動作し、VPC内 でトラフィックをルーティングするかについても説明しました。 加えてこの記事では、ソフトウェア/イメージを変更することなく、Amazon EKS ノードグループと Multus ポッドの IP 管理自動化の、自動化サンプルメソッドも提供しております。 分かり易くするために、この記事の上の例では IPv4 の処理のみを説明しました。但し、 git リポジトリ のサンプル コードは IPv6 もサポートしています。様々なアプリケーションアーキテクチャやユースケースに応じて、git リポジトリ内のサンプル ソースコードをさらに調整して頂けます。 この記事はアマゾン ウェブ サービス ジャパンの黒田由民が翻訳を担当しました。 (原文は こちら ) Raghvendra Singh Raghvendra Singh は AWS 5G および AWS のネットワークトランスフォーメーションプラクティスのスペシャリストです。彼は AWS の 5G ソリューション設計全体、E2E 統合、ネットワークアーキテクチャ、自動化、セキュリティ全般を担当しています。彼は 4G/5G NFV 分野を専門とし、お客様が AWS 上でクラウドネイティブのコンテナネットワーク機能を導入および統合できるよう支援しています。

従来から、通信サービスプロバイダ (CSP) は Virtual Routing and Forwarding (VRF) 技術を使用して、データセンター (DC) ネットワークをネットワークドメインごとに分離しています。例えば、運用管理 (OAM)、シグナリング、ローミング、ユーザートラフィックネットワークなどのドメインなどです。また、データセンターの各 VRF ドメインを他のデータセンターと同等の VRF に接続して、ネットワークを地域的および全国的にカバーする必要があります。さらに、CSP がエンドカスタマーに提供するサービスでは、CSP がマルチ VRF ベースのネットワークをネットワーク分離したまま、外部のプライベートネットワークに拡張する必要があることもよくあります。従って、DC 間接続と通信ネットワーク拡張の両方で、ネットワーク分離（VRF）を維持し、複数の自律システム（AS）サポートを相互接続するための特定の要件が生じます。一般的な解決策として、 RFC4364 ではこの要件に対応する 2 つのオプションが導入されています。オプションA は、RFC 4364 の VRF to VRF 接続により、ネットワーク間相互接続（NNI）の両側のルーティングコンテキストが 1:1 で調整されることを意味します。また、オプションB は、NNI のラベルスイッチングパラダイムに基づくマルチプロトコルラベルスイッチング（MPLS）AS 間接続を、グローバル QoS ポリシー、強化スキーム、および単一のMP-eBGPセッションを備えた単一の MPLS 対応論理インターフェイスで使用します。AWS で実行されているアプリケーションを、既存のマルチ VRF で分離されたネットワーク上のワークロードに相互接続する場合、この要件とソリューションを実装する必要があります。最初で最も簡単な方法として、RFC4364 オプションAの方法で、アプリケーションを個別の Amazon Virtual Private Cloud（Amazon VPC）に分離し、各 VRF にマッピングすることを考えることができます。これは次の図1に示すように、オンプレミスの VRF と AWS 上にマップされた VPC の間に個別の AWS Site to Site (S2S) VPN または AWS Direct Connect (DX) で接続することにより実現します。 図1 VRF から VPC への相互接続 (RFC4364 オプション A) これはうまく機能し分かり易いですが、ネットワークアプリケーションをそれぞれの VPC に分離できる場合にのみ機能します。ただし、仮想ネットワーク機能（VNF）やコンテナネットワーク機能（CNF）などの通信ネットワークアプリケーション/アプライアンスのほとんどの場合、特定のアプライアンス（EPC（evolved packet core）や 5GC（5G Core）等）では、複数のネットワークドメインを1つの VPC 内に限定する必要があります（OAM VRF、シグナリングネットワーク VRF、ユーザープレーン VRF、ローミングインターフェイス VRF 等）。これにより通常、ネットワーク分離の要件を維持したまま通信サービスプロバイダのネットワークと AWS 間のネットワーク拡張を実装しようとすると、複雑さとコストが増えます。そのため、特に AWS 上の通信アプリケーションに 1 つの VPC アーキテクチャを使用する場合は、ベストプラクティスを検討することが合理的です。 図 2 VRF から単一 VPC への相互接続 この記事では、AWS と複数の VRF で分離された CSP ネットワーク間にハイブリッドネットワークを構築するための 5 つの実行可能なデザインパターンを紹介します。1) Customer Gateweay (CGW) のルートフィルター オプション設定によるパターン、2) AWS Transit Gateway (Transit Gateway) ルートテーブルの分離によるパターン、3) Transit Gateway ルートテーブルの分離と Transit Gateway Connect によるパターン、4) VPC 内の仮想ルータアプライアンスによるパターン、及び 5) Multi-VPC ENI Attachments 機能を使用したパターン、の5つです。パターン 1 ～ 3 及び 5 では、オンプレミス側プロバイダエッジ (PE) ルーターまたは Transit Gateway の各側で微調整された構成を持つネイティブ AWS ネットワーキング構造を使用します。一方パターン 4 では、RFC4363 オプション B 構成を実装するために、VPC 内に仮想ルータアプライアンスが必要になります。これら 5 つのパターン以外にも他のオプションが存在する可能性がありますが、これらを一般的なアプローチとして、また AWS の VPC アーキテクチャと既存の VRF 分離ネットワークの両方への影響を最小限に抑えるベストプラクティスとして紹介します。 パターン 1 – CGW（プロバイダエッジ（PE）ルータ）でルートマップ IN フィルタを使用して VRF を単一の VPC に接続する 最初のデザインパターンは、最もシンプルな AWS ネットワーク構成方法で、VRF ごとに個別 Site to Site (S2S) 仮想プライベートネットワーク (VPN) または Direct Connect (DX) 仮想インターフェイス (VIF) を利用し、PE ルータ側に特定の構成を行います。前の章で説明したように、1つの VPC が AWS ネットワークの 1つのルーティングドメインになります。したがって、S2S VPN または DX を介して VRF 分離が存在するオンプレミスネットワークに Amazon VPC を接続すると、すべての VPC CIDR 範囲が接続されているすべてのピア VRF に広報されます。この際、各 VRF ルータ（VPC への各 S2S 接続の CGW としても見られます）のルートポリシーマップは、各 VRF 向け他 Amazon VPC サブネットからの干渉を受けないように実装されることができます。このインバウンドルートポリシーは、Amazon VPC 内の Amazon Virtual Private Gateway (VGW) との BGP 関連付けを介した現在の VRF とは関係のない、広報されたサブネットをフィルタで除外するために、適用される必要があります。つまり、このパターンでは、オンプレミス VRF ルータ側での事前設定が必要ですが、各 VRF 対応にマッピングする事前定義された Amazon VPC サブネットに関する情報も必要になります。このプライベートネットワーク側の構成に加えて、インスタンスとサブネットインターフェイスでセキュリティグループとアクセス コントロールリスト (ACL) を使用して、セキュリティ及び分離の適切な境界を設定する必要もあります。これにより、VPC 内でのネットワーク分離を実装可能とします。 図3 デザインパターン1; PE ルータでルートフィルタを使用する 図 3 の VRF1 ルータの場合、VPC が VPC CIDR 10.0.0.0/16 範囲全体を広報している一方で、VRF-1 サブネットが VPC で 10.0.10.0/24 として事前に設定されている場合に、ルートマップフィルタ設定例を次のように記載できます。S2S VPN または DX 接続を介して広報された複数の VPC CIDR 範囲を受信してフィルタリングするには、広報するプレフィックスごとに新しいセカンダリ VPC CIDR を設定し、その CIDR から VPC サブネットを作成する必要があることに留意ください。DXと S2S VPN は、プライマリ VPC CIDR だけでなく、セカンダリ VPC CIDR ごとに1つの VPC CIDR プレフィックスを広報します。これにより、オンプレミスの CIDR に基づいてフィルタリングできます。 router bgp 65001 network 169.254.205.58 neighbor 169.254.205.57 remote-as 64512 neighbor 169.254.205.57 route-map SET-LOCAL-PREF in ! route-map SET-LOCAL-PREF permit 10 match ip address 2 set local-preference 120 ! route-map SET-LOCAL-PREF permit 20 ! access-list 2 permit 10.0.10.0 0.0.0.255 access-list 2 deny any パターン2 – Transit Gateway ルートテーブル分離を使用する マルチ VRF 用の個別の S2S VPN または DX VIF がある（つまり、各 S2S VPN または VIF が各 VRF に個別にある）場合は、それらを使用して各 VRF を単一の VPC に接続できます。この環境では、AWS Transit Gateway (TGW)と Transit Gateway ルートテーブル を使用して、VPC CIDR のルート伝播を各 VRF に分けることができます。このアプローチ（および次のパターン3）で覚えておくべく留意点の1つは、Transit Gateway はデータトラフィックの料金がかかるため、大量のトラフィックを処理する必要がある通信サービスプロバイダの 4G/5G コアネットワークのユースケースにてユーザートラフィックの伝送には、最適なオプションとはならない可能性がある点です。次の図4に示すように、このデザインパターンの重要な考え方は、VRF 側への Amazon VPC の伝播を無効にし、代わりに各 VRF 専用ルートテーブルで静的ルートを定義して、VPC CIDR 範囲内の対応するサブネットのみを含むようにすることです。次の図例では、結果として、PE ルータの VRF1 側は Transit Gateway 側の BGP 広報から Private-VRF1 サブネット範囲のみを受信し、VRF2 側では Private-VRF2 サブネット範囲のみを参照します。前のデザインパターンと同様に、VPC 内のネットワーク分離は、各サブネットレベルとインスタンスレベルで NACL とセキュリティグループを介して実装する必要があります。 図4 デザインパターン2; TGW ルートテーブル分離を使用する パターン3 – 単一の DX Transit VIF を介して Transit Gateway Connect を使用する 前のパターンと似ていますが、DX 接続が1つだけ存在する場合は、 Transit Gateway Connect 機能がより効果的です。Transit Gateway Connect は、単一の DX Transit VIF を介して複数の AS 及び複数の VRF ネットワークを AWS に相互接続する方法を提供します。これにより、Generic Routing Encapsulation (GRE) と Border Gateway Protocol (BGP) を使用したオンプレミスデータセンタと AWS ドメイン間の物理ネットワーク接続を簡素化できます。 図5 デザインパターン3; TGW Connect と TGW ルート テーブルの分離を使用する 上の図は、複数の VRF を使用した複数の Transit Gateway attachment タイプ Connect の実装を示しています。Direct Connect Gateway（DX-GW）はTransit VIF で構成され、Transit Gateway の CIDR 範囲を広報します。DX-GW は Transit Gateway に接続されるため、DX-GW アタッチメントが作成されます。DX-GW アタッチメントは、Transit Gateway attachment タイプ Connect のトランスポートになります。Transit Gateway attachment タイプ Connect を作成したら、Connect ピア (GREトンネル) を作成してオンプレミス VRF で GRE + BGP を設定します。Transit Gateway の GRE 外部 IP アドレス (ピア IP アドレス) は、Transit Gateway CIDR からの任意の IP になり、VRFアプライアンス側の GRE 外部 IP アドレスは、オンプレミスの PE ルータから広報されたアドレスのいずれかになります。CIDR ブロック内の BGP は、169.254.0.0/16 範囲の /29 CIDR である必要があります。/29 IPv4 範囲の最初のアドレスは、 VRF アプライアンスの BGP ピア IP アドレスになり、他の 2 つのアドレスが Transit Gateway BGP ピア用に選択されます。すべての GRE 接続に対して 2 つの BGP ピアを設定でき、これにより各 GRE トンネル内に組み込みの冗長性が提供されます。各 Transit Gateway タイプ Connect には、トラフィックを分離するための独自の Transit Gateway ルーティングテーブルがあります。VPC アタッチメントがルーティングテーブルの伝播に追加されると、VPC CIDR は VRF に動的に伝播されます。オンプレミス VRF は、対応する Transit Gateway attachment タイプ Connect がルーティング テーブルの伝播に追加されると、それぞれのルーティングテーブル上でそのネットワークを広報します。前のパターンと同様に、この場合も NACL とセキュリティグループを使用して VPC 内のネットワーク分離を確認する必要があります。 パターン 4 – 仮想ルーターアプライアンスを使用した VRF 分離 (RFC4364-オプション B) VPC 内の仮想ルータアプライアンスによって構築されたオーバーレイネットワークの使用を考慮できます。次の図が示すように、オンプレミスネットワークの PE ルータとこの仮想ルータアプライアンスの間に、MPLS over GRE 接続を介して確立されたオプション B のネットワーク間インターフェイス (NNI) を作成できます。 図6 デザインパターン4; 仮想ルータアプライアンスによるオーバーレイネットワークの使用 簡単な検証のため、このアーキテクチャは、AWS Marketplace の Juniper Networks Virtual SRX (vSRX) を使用して、次の図の例示的な構成でテストできます。VPC1 のルータアプライアンスの左側はオンプレミスの PE ルータを模倣し、別の VPC2 のルータアプライアンスの右側は、オーバーレイネットワークを提供する VPC 内の仮想ルータアプライアンスを表します。これにより、両方の VPC がインターネット上の S2S VPN 経由で接続されるようになります。 図7 デザインパターン4の検証環境例 このデモ環境では、異なる MPLS L3 VPN から/へのトラフィックは、AWS Transit VPC の仮想ルーターアプライアンス上で終端される単一のオプション B オーバーレイ接続を介して多重化されます。この仮想ルータアプライアンスは、対応するルートターゲットをインポートおよびエクスポートすることで、ローカルに設定された複数の VRF にフローを明確化し、AWS Transit VPC 内の 1 つまたは複数のサブネットにバインドできます。以下は自律システム境界ルータ (ASBR) として機能する vSRX の構成例です。 [edit configuration] routing-instances { vSRXForWorkload-LAN1 { interface ge-0/0/1.0; instance-type vrf; route-distinguisher 65002:1; vrf-import import-vSRXOnPrem1; vrf-export export-vSRXForWorkload1; vrf-table-label; } vSRXForWorkload-LAN2 { interface ge-0/0/2.0; instance-type vrf; route-distinguisher 65002:2; vrf-import import-vSRXOnPrem1; vrf-export export-vSRXForWorkload2; vrf-table-label; } } 共通または異なるルートターゲットに基づくインポート及びエクスポートポリシーの適格な組み合わせも実装できます。AWS 側では、これらの各サブネットを同じ VPC に属する共通または専用のルートテーブルに関連付けることができます。サブネットルートテーブルごとに、VPC 内で異なるルーティングルックアップを実装できます。さらに、ルーティングコンテキスト間の分離を実現でき、前のパターンと同様に NACL とセキュリティグループを使用することもできます。 パターン 5 – Multi-VPC ENI Attachments を使用した VRF 分離 Multi-VPC ENI Attachments は、VPC レベルの分離を通じてアプライアンスが複数の個別のネットワークインターフェイスを持つことをサポートする機能です。この機能により、図 8 及び 図 9 に示すように、VPC の分離を維持しながら、アプライアンスなどのネットワーク機能が複数の ENI を持つことが可能になります。 図8 – デザインパターン5 の検証環境例 (TGW 使用) 図9 – デザインパターン5の検証環境例（VGW 使用） 図 1 で前述したように、このアーキテクチャは RFC4364 オプション A に準拠しており、各オンプレミス VRF を専用 VRF VPC に接続します。Multi-VPC ENI Attachments 機能により、ネットワーク機能アプライアンスを複数の VRF に接続できます。このアーキテクチャを使用する場合、パターン 2 と同様に、VRF-VPC ごとに個別の TGW ルートテーブルを使用する (図 8) か、ネットワーク要件に基づいて各 VPC で VGW を使用する (図 9) かを選択できます。 まとめ 一般的なクラウドの概念では、Amazon VPC は 1 つのルーティングドメインを提供する単一のフラットネットワークであるため、一致する VRF ごとに個別の VPC を持つことが最もシンプルな方法になります。ただし、4G/5G コア ネットワーク (UPF や PGW など) のようなアプリケーションでは、ルータをプライベートネットワークの複数の VRF に接続する必要がありますが、これらアプリケーションは通常、複数の VPC に分割することが出来ません。従って、VRF で分離されたプライベートネットワークへの単一 VPC の統合というこの課題は、AWS 上でのモバイルネットワーク実装のコンテキストで表面化することがよくあります。この記事では、Amazon VPC を VRF で分離されたオンプレミスのプライベートネットワークに接続するための 5 つの異なるアプローチについて説明しました。これは、AWS 上に 5G コアネットワークやプライベート 4G/5G ネットワークを構築するなど、通信業界のユースケースで必要になることがよくあります。各アプローチには、実装の複雑さ、運用コスト、スケーラビリティと性能要件の制約に関して長所と短所があります。よって、リストされたアプローチを使用した詳細な実装は、ユースケースの環境に応じて決定されることを推奨します。   長所 短所 パターン 1: PE ルータ（CGW）のルートマップフィルタ Amazon VPC 向けの最もシンプルな構成（S2S VPN, DX, VGW, Transit Gateway, サブネットルートテーブル） 複数の VIF および S2S VPN が必要（それぞれ VRF ごとに） PE ルータにはフィルタリング設定が必要 パターン2: 複数の S2S VPN または VIF を使用した Transit Gateway ルートテーブルの分離 各 VRF は、PE ルータを変更しなくても、対応するサブネットの広報を受信できる 複数の VIF および S2S VPN が必要（それぞれ VRF ごとに） 静的ルートの Transit Gateway ルートテーブルの設定が必要 Transit Gateway の使用が必要 パターン3: Transit Gateway ルートテーブルの分離、及び単一の Transit VIF を使用した Transit Gateway Connect 各 VRF は、PE ルータを変更しなくても、対応するサブネットの広報を受信できる 単一の VIF を活用 PE ルータには GRE のサポートが必要であり、GRE の制限（フローごとの制限等）に留意する必要がある 静的ルートの Transit Gateway ルートテーブルの設定が必要 Transit Gateway の使用が必要 パターン4: 仮想ルータベース ネットワークエンジニアにとって最も分かりやすい（従来の通信ネットワーク向け） オーバーレイおよびアンダーレイネットワークを構築するための追加コスト/複雑さ（高可用性、スケーラビリティ、性能に関する懸念を含む） パターン5: Multi-VPC ENI Attachments の使用 Amazon VPC 向けの最もシンプルな構成（S2S VPN, DX, VGW, Transit Gateway, サブネットルートテーブル） 各 VRF は、PE ルータを変更しなくても、対応するサブネットの広報を受信できる 複数の VIF および S2S VPN が必要（それぞれ VRF ごとに） この記事はアマゾン ウェブ サービス ジャパンの黒田由民が翻訳を担当しました。 (原文は こちら ) 著者 Rolando Jr Hilvano Rolando Jr Hilvano は、Amazon Web Services (AWS) のワールドワイドテレコムビジネスユニットのプリンシパルテレコムソリューションアーキテクトです。彼は 5G 分野を専門としており、通信領域のパートナーや顧客と協力しながら、AWS 上で通信ワークロードの構築やデプロイをしています。 Gonzalo Gomez Herrero Gonzalo Gomez Herrero は、AWS テレコムビジネスユニット EMEA チームのプリンシパルソリューションアーキテクトです。彼は20年以上にわたり、ネットワーク設計、エンジニアリング、計画、導入、および運用において世界中の通信サービスプロバイダをサポートしており、さまざまな役割にわたってコンサルティング、プロフェッショナルサービス、ソリューションアーキテクチャを提供してきました。Gonzalo は、サラゴサ大学で電気通信工学の修士号を取得し、ミュンヘン工科大学でコンピューターサイエンスの大学院研究を行いました。 Ammar Latif Ammar Latif は AWS のプリンシパルテレコムソリューションアーキテクトです。彼は、クラウドテクノロジーを使用してビジネス上の課題に取り組むお客様を支援しています。これまでのキャリアを通じて、Ammar は世界中の多くのテレコムおよびメディアのお客様と協力してきました。Ammar はニュージャージー工科大学で博士号を取得しています。 Matt Lehwess Matt Lewess は AWS のシニアプリンシパルソリューションアーキテクトです。マットは、ネットワークサービスプロバイダ分野でネットワークエンジニアとして長年働いており、アジア太平洋地域と北米で大規模なWANネットワークを構築し、データセンタテクノロジーとそれに関連するネットワークインフラストラクチャを展開してきました。その結果、彼は Amazon VPC、AWS Direct Connect、およびその他の Amazon のインフラストラクチャに焦点を当てた製品やサービスを最もよく使って作業しています。Matt は AWS のパブリックスピーカーでもあり、AWS クラウドプラットフォームを使用してお客様が大規模な問題を解決できるよう支援しています。仕事以外では、Matt は屋内と屋外の両方で熱心なロッククライマーであり、熱心なサーファーです。 Young Jung Young Jung 博士は、AWS ワールドワイドテレコムビジネスユニットのプリンシパルソリューションアーキテクトです。彼の主な焦点とミッションは、テレコムの Core /RAN パートナーとお客様が AWS 環境でクラウドネイティブ NFV ソリューションを設計及び構築出来るように支援することです。また、AWS のサービスとテクノロジーを活用したテレコムエッジサービス実装のため、通信業界向けの AWS Outposts のユースケースも専門としています。

通信サービスプロバイダ (CSP) が AWS 上に Long Term Evolution (LTE) または 5G ネットワーク機能をデプロイする場合、SGi (LTE の場合) または N6 (5G の場合) インターフェイスを介したユーザープレーンデータネットワークのブレークアウトに関するさまざまなオプションが存在します。3GPP は、SGi インターフェイスをパケットデータネットワーク（PDN）ゲートウェイ（S-GW およびP -GW）とデータネットワーク間の基準点として定義しています。さらに、N6 はユーザープレーン機能（UPF）とデータネットワークの間の基準点として定義されています。PDN は、公共の外部（インターネットなど）データネットワーク、プライベートパケットデータネットワーク（VPNなど）、またはオペレータ内パケットデータネットワークとすることができます。 この記事では、非ローミングシナリオでの AWS 上での LTE または 5G UPF のデータネットワークブレークアウトオプションについて説明します。UPF という用語は、3GPP TS 29.244 に記載されているように、SGW-U、PGW-U、TDF-U、UPF などのノードを指します。この記事では、PGW-U を P-GW と呼びます。 図 1: LTE の P-GW およびデータネットワーク (インターネット) 間の SGi インターフェイス 図2: 5G の UPF とデータネットワーク (インターネット) 間の N6 インターフェイス ソリューション設計 AWS 上の LTE または 5G ネットワークは、CSP によってパブリックネットワークまたはプライベートネットワークとして運営されています。各ネットワークタイプは、通常パブリックネットワークの消費者市場に関連する Enhanced Mobile Broad Band（eMBB: 高速大容量通信）、自動運転車に関連するユースケースのような遅延に厳しい要件がある Ultra Reliable Low Latency Communications（URLLC: 超信頼・低遅延通信）、データを送信する多数のデバイスをサポートするMassive Machine Type Communications（mMTC: 多数同時接続）など、様々なタイプのユースケースに対応します。ユースケースが何であれ、ユーザープレーンのトラフィックは P-GW または UPF を出てアプリケーションへ到達します。AWS 上でネットワーク機能を実行する場合、データネットワークにアクセスするにはさまざまな方法があります。5G UPF 機能をリファレンスとして使用する様々なブレークアウトアーキテクチャについて説明します。 設計1: AWS Internet Gateway 経由のパブリックデータネットワーク (インターネットなど) へのユーザープレーンのブレークアウト このアーキテクチャでは、N3 トラフィックはオンプレミスから AWS 上の UPF に到達します。UPF は、N6 インターフェイスに送信する前に、NAT を実行してユーザー機器 IP（UEIP）を UPF ENI IPに変換します。N6 ユーザープレーンのトラフィックブレイクアウトは、AWS Internet Gateway (IGW) 経由でパブリックデータネットワークであるインターネットに送られます。IGW は、VPC とインターネット間の通信を可能にする、水平方向に拡張された冗長で可用性の高い仮想プライベートクラウド (VPC) コンポーネントで、IPv4 とIPv6 のトラフィックをサポートしています。このアーキテクチャの UPF には、N6 トラフィックがインターネット宛先に到達するための1つ以上のパブリック IP アドレス（Elastic IP アドレスなど）が割り当てられています。N6 Elastic Network Interface (ENI) サブネットの VPC ルーティングテーブルには、インターネットトラフィック宛先のネクストホップとして IGW があります。 設計2: CSP のオンプレミスネットワークを介したパブリックデータネットワーク（インターネットなど）へのユーザープレーンのブレークアウト このアーキテクチャは、N6 トラフィックがルーティングでオンプレミスネットワークに戻ることをを示しています。このアプローチでは、AWS 上に配置されている UPF との間のユーザープレーントラフィックがヘアピンされます。このタイプのアーキテクチャを使用する CSP は、インターネットへの既存の ISP 接続またはエンタープライズ顧客へのプライベート接続を引き続き活用できます。N6 ENI サブネット向けの VPC ルーティングテーブルには、インターネットトラフィック宛先向けのネクストホップとして   AWS Transit Gateway   があります。Transit Gateway では、N6 データネットワークトラフィックは N6 Virtual Routing and Forwarding（VRF）セグメントに戻され、オンプレミスに到達します。 設計3: AWS Site-to-Site VPN によるプライベートデータネットワークへのユーザープレーンのブレークアウト このアーキテクチャは、UPF からの N6 トラフィックが、  AWS Site-to-Site VPN または VPN アプライアンスを使用する安全な VPN 接続を介してサードパーティのロケーションに向けて終端するプライベートネットワークの一般的なユースケースとなります。AWS Site to Site VPN サービスは、仮想プライベートゲートウェイまたは AWS 側の Transit Gateway を使用して確立できます。Site to Site VPN の設定の詳細については、 こちら をご覧ください。AWS Site to Site VPN の単一の VPN 接続の帯域幅容量 (1.25Gbps) を考慮に入れる必要があります。ただし、複数 VPN トンネルの等価コストマルチパス（ECMP）では、トラフィックが必要とする全体帯域幅を増加させることも可能です。 設計4: VPC ピアリングによる AWS 上のプライベートデータネットワークへのユーザープレーンのブレークアウト このアーキテクチャは、5G ネットワーク機能とユースケースアプリケーションの両方が AWS 上のそれぞれの VPC 上で動作するプライベートネットワークの一般的なユースケースとなります。2 つの VPC は VPC ピアリングを使用して相互接続されます。VPC ピアリング接続は、プライベート IPv4 アドレスまたは IPv6 アドレスを使用してトラフィックをルーティングする 2 つの VPC 間のネットワーク接続です。いずれかの VPC 内のインスタンスまたはワーカーノードは、あたかも同じネットワーク内にあるかのように相互に通信できます。N3 トラフィックがオンプレミスから AWS 上の UPF に到着すると、UPF は NAT を実行して UEIP を UPF ENI IP に変換してから N6 インターフェイスに送信します。UPF からの N6 データネットワークトラフィックは、VPC ピアリングをネクストホップとして使用してアプリケーション VPC にルーティングされます。完全修飾ドメイン名 (FQDN) アプリケーションアドレスは、ネットワーク機能 VPC をアプリケーション VPC の Amazon Route 53 プライベートホストゾーンに関連付けることで解決されます。 設計5: Transit Gateway 経由の AWS 上のプライベートデータネットワークへのユーザープレーンのブレークアウト このアーキテクチャは、プライベートネットワークの他の一般的なユースケースの 1 つです。5G ネットワーク機能とユースケースアプリケーションの両方が AWS 上のそれぞれの VPC 上で 動作します。2つのVPCは、VPCアタッチメントを介して Transit Gateway を使用して相互接続されます。VPC アタッチメントの詳細については、 こちら をご覧ください。UPF からの N6 データネットワークトラフィックは、ネクストホップとして Transit Gateway 経由でアプリケーションにルーティングされます。FQDN アプリケーションアドレスは、ネットワーク機能 VPC をアプリケーション VPC の Route53 プライベートホストゾーンに関連付けることで解決されます。VPC ピアリングとは異なり、Transit Gateway では推移的なルーティングが可能です。 設計6: AWS Resource Access Manager 経由のサブネット共有による AWS上 のプライベートデータネットワークへのユーザープレーンのブレークアウト このアーキテクチャは、ある AWS アカウントで動作する UPF からの N6 データネットワークトラフィックが、別の AWS アカウントで動作しているアプリケーションに送信されるプライベートネットワークのユースケースです。UPF の N6 インターフェイスとアプリケーションインターフェイスの両方が同じサブネット上にあります。サブネット共有は AWS Resource Access Manager (AWS RAM) を使用してリソース共有を作成することで可能になります。VPC 所有者であるネットワーク機能 VPC は、アプリケーションアカウントとサブネットを共有します。 共有されると、アプリケーションアカウントはサブネットにアクセスし、VPC リソースを起動できるようになります。サブネット共有の詳細については、 こちら をご覧ください。 まとめ  LTE や 5G のユーザープレーントラフィックをインターネットや非ローミングシナリオのアプリケーションにブレイクアウトする方法については、複数の設計があります。AWS はパブリックネットワークとプライベートネットワークの両方のユースケースで、CSP がアプリケーションに SGi または N6 トラフィックを送信できるようにする様々なサービスを提供しています。アーキテクチャ設計を選択する際には、遅延、アプリケーションのエントリポイントまたはアクセスポイント、そしてユースケースなどの要素を考慮する必要があります。詳細については、 AWS for Telecom をご覧ください。 この記事はアマゾン ウェブ サービス ジャパンの黒田由民が翻訳を担当しました。 (原文は こちら ) Rolando Jr Hilvano Rolando Jr Hilvano は、Amazon Web Services (AWS) のワールドワイドテレコムビジネスユニットのプリンシパルテレコムソリューションアーキテクトです。彼は 5G 分野を専門としており、通信領域のパートナーや顧客と協力しながら、AWS 上で通信ワークロードの構築やデプロイをしています。

このブログは、AWSの以下のメンバーによって共同執筆されました： Pavol Masarovic, EMEA Principal SAP Innovation Architect Allison Quinn, Senior Analytics Solutions Architect Australia and New Zealand Peter Perbellini, Head of APJ Solutions Architecture, ERP on AWS はじめに AWSでは、お客様からSAPシステムをクラウドに移行するだけでなく、データに対して分析機能を活用し、組織の変革を実現したいという声をよく聞きます。去年リリースされたジョイントレファレンスアーキテクチャ (JRA) に沿って、RISE with SAP on AWS を採用している客様に更なる価値をもたらすために、AWS ネイティブサービスを統合しています。AWS と SAP BTP の ジョイントレファレンスアーキテクチャ は、異なるビジネスソリューションシナリオでどのように SAP BTP や AWS サービスを使用するかについて、お客様やパートナー様からの質問に対応するために開発されました。 SAP のお客様は既に AWS 上のデータレイクを活用し、SAP と SAP 以外のデータを組み合わせ、AWSの業界をリードするストレージとアナリティクス機能を活用しています。その中には、 Bizzy 、 Invista 、 Zalando 、 Burberry 、 Visy 、 Delivery Hero 、 Engie のようなお客様を含め、何年前からこのような取り組みを行っているお客様は複数います。お客様は、SAP と SAP 以外のデータ (例えば、CRM システムからのリード情報、顧客満足度点数、住宅統計、気象データ) を組み合わせたエンタープライズ・ダッシュボード、ML モデル、「what-if」シナリオを構築する方法を探しています。 AWS Analytics Fabric for SAP ソリューションを利用することで、SAP on AWS のお客様は、構築に必要な AWS サービスを考える負担がなくなり、構築作業を最大 90% 削減しながら、データドリブンアプローチにより数時間以内にSAPデータから実用的な洞察を得られます。 AWS Analytics Fabric for SAP を使用することで、ユーザーは製品、顧客、販売注文、納品、請求書などの機能領域を選択することができ、ソリューションのテンプレートには必要なテーブルとそれらの関連性を特定します。 AWS Analytics Fabric for SAP は以下の内容を含めます。 生成される データモデル は、ビジネスコンテキストを持ち、ビジネスフレンドリーな名前を提供 差分データ抽出 (CDC)、データ変換ルール、カスタムフィールドの自動的に含める包括的な機能を備えた、シンプルで適応性の高いニアリアルタイムの データパイプライン を実現 Amazon S3 で高度にスケーラブル可能な AWS データレイクを構築し、 Amazon S3 Intelligent Tiering を使用して費用対効果の高い階層に データを保存 ユーザが SAP データおよび  SAP 以外のデータに対して高度な分析やレポート作成をするために、高品質のデータモデルを提供 AWS Analytics Fabric for SAP を使用する主なメリット AWS Analytics Fabrics for SAP は、RISE のお客様の変革を加速し、AWS のデータ分析や AI/ML サービスからさらなる価値を引き出すために構築されました。モダンデータアーキテクチャのフレームワークに基づいているため、SAP on AWS のすべてのお客様がデータを活用し、ビジネスユースケースの要件に応じて拡張することも可能です。これらのアクセラレータは、開発のベースラインとして使用したり、お客様の要件に合わせて簡単に変更・カスタマイズすることができます。 データの取り込みは、標準で提供される SAP Business Content Extractor に基づいています。これらは要件に応じて、 SAP HANA CDS ビューまたはソーステーブルから抽出するように変更できます。データ取り込み処理は、分単位の間隔でスケジュールし、差分データのみ抽出します。この方法では、データソースで行われた変更を含めすべてのデータが取り込まれます。 その後、データは Amazon Redshift にロードされますが、ロードの処理は AWS Step Functions で制御され、参照整合性のために適切な順序を保ちます。Amazon Redshift 側には、様々な SAP ソースを結合したデータモデルのサンプルも提供されており、 Amazon QuickSight でこれらのデータを迅速に利用し、洞察を得ることができます。お客様は、これらの事前定義されたデータモデルを簡単に改修したり、SAP のソースデータを Redshift やデータレイク環境で利用可能な他のデータと簡単にモデリングできます。 このアーキテクチャ図は、OData プロトコルを介して SAP からデータを抽出し、AWS 上で SAP データを使用してクラウドデータウェアハウス構成と構築ステップを表しています。 以下は各ステップの説明です。前提条件に関しては次のセクションで詳しく説明します。 前提条件 – 標準の SAP Business Content Extractors をインストールし、有効化します。SAP システムの SAP Gateway で、ODP ベースの OData を設定します。 前提条件 – Amazon AppFlow から SAP ソースシステムへの OData 接続先を作成します。SAP on AWS 又は VPN /ダイレクトコネクト経由で AWS との接続がある場合はPrivateLinkを使用可能であり、またはインターネット経由での接続も可能です。 前提条件 – データを保存する Amazon S3 バケットを作成します。 Amazon AppFlow で、ステップ 2 で作成した SAP ソースとの接続先を使用してフローを作成します。フローを実行して SAP からデータを抽出し、Amazon S3 バケットに保存します。 Amazon S3 バケットに抽出された SAP データのメタデータを認識するために、データカタログエントリを作成します。 ‘ COPY ‘ コマンドで Amazon Redshift にデータをロードします。データを適切にモデル化し、データの過去の動きを可視化する機能を有効にします Amazon Redshift をデータソースとして Amazon QuickSight でデータセットを作成します。要件に応じてビジネスデータのダッシュボードを作成します。 AWS Step Functions でエンド・ツー・エンドのプロセスを自動化します。 SAP ソースシステムから抽出されたデータにより、お客様は直ちに、受注件数、受注総額、未決済受注件数および未決済受注総額、返品件数、平均受注額（AOV）、納期遵守率（DIFOT）、請求済み受注、受注処理率等のOrder-to-Cashに関連する主要業績評価指標（KPI）を導き出すことができます。これに加えて、データの差分抽出（CDC）を活用することで、お客様は、注文数量変更や納品時間枠変更など、データ更新を含む各注文のジャーニーを時系列で分析することができます。 前提条件 AWS Analytics Fabric for SAPのデプロイには3つの前提条件があります。 Git レポジトリ に記載されているエクストラクタをSAPシステムでインストールします。既に SAP BW システムがある場合は、すでにインストールされているかもしれません。これらのエクストラクタは、トランザクションコード SEGW で ODataサービスのソース ODP として定義する必要があります。 Amazon AppFlow で SAP システムへの 接続先 を作成します。これは接続先の情報と認証情報だけの簡単な入力も可能であり、AWS と SAP システム間の AWS PrivateLink を使う場合 PrivateLinkの情報も必要になります。これは 1 回だけ行う必要があるステップです。 SAP データを格納する Amazon S3 バケット を作成します。 これらの前提条件が完了すれば、残りの構築ステップはスムーズになります。 デプロイメント デプロイは、 AWS CloudFormation テンプレートとスクリプトを使用して自動化されており、必要に応じて迅速に実装、変更、拡張することができます。テンプレートはパラメータ化されており、迅速なデプロイが可能です。AWS Analytics Fabric for SAP の初回リリースは、”Order to Cash ” プロセスにフォーカスしており、他のプロセスも今後リリースされる予定です。 Git リポジトリのガイダンスに従って、定義された順序で各コンポーネントを実装してください。 Git レポジトリ には、テンプレート以外に、ほかの参考情報も記載してあります。 デプロイのステップは以下になります。 SAP システムからデータを抽出するために Amazon AppFlow のフローをデプロイします。これにより、自動的にフローがアクティブになり、指定したタイミングに基づいてデータの取り込み処理が実行されます。 データエントリーの技術メタデータカタログである AWS Glue データカタログ をデプロイします。これにより、Amazon Athena などのサービスでデータを参照して利用できるようになります。 Redshift クラスタを作成するために、Git レポジトリに Redshift 用のスクリプトがあります。最初に DDL（データ定義言語）スクリプトを実行し、データをロードするためのテーブル定義を作成します。その後、ほかのスクリプトを実行し、データパイプラインコンポーネントとCDC（Change Data Capture）パイプライン管理を作成します。すべてのテンプレートスクリプトは定義済みですが、SAP ソースシステムでカスタマイズがある場合など、カスタマイズや変更、拡張が可能です。 プロセス全体のオーケストレーションとデータパイプラインアラートのために Step Functions をデプロイします。 Amazon QuickSight アカウント を作成し（まだアクティブなアカウントがない場合）、 Amazon Redshift クラスタ に接続し、Amazon Redshift で使用可能なモデリングされたデータに基づいてデータソースを定義します。 上記は、提供された CloudFormation テンプレートのデータセットを使って Amazon QuickSight での可視化の例です。SAP 注文の異常検知や予測を追加するために、機械学習を活用した洞察機能で Order-to-cash の様々な KPI を可視化することができます。 まとめ AWS Analytics Fabric for SAP は、ビジネスユーザーが SAP データから迅速に実用的な洞察を得られるために、簡単で効率的な方法を提供しています。AWS 上で SAP 環境を稼働しているお客様は、AWS マネジメントコンソールでこのサービスを使い始めることができます。また、オンプレミスで SAP システムを稼動しているお客様は、SAP データを Amazon S3 に格納することで、AWS 上で強力なデータレイクを作成し、SAP への投資効果拡大や企業データから新たな価値を得ることができます。 アクセラレータを利用するための初期費用は不要で、利用する AWS サービスに対する課金となります。例としては、Amazon AppFlow のフロー実行コストは、実行ごとにわずか $0.001 です。販売伝票ヘッダーの取込みを 5 分ごとに 24 時間実行する場合、1 日あたり 288 回の実行があり、1ヶ月あたりのコストは $8.76 となります ( 1 日288 回 * ( 月の平均 730 時間 / 1 日 24 時間) =　月に 8760 フロー実行 * $0.001 = $8.76 ) 。また、処理したデータ量に応じて、1GB までは 1GB あたり $0.02、1GB 以上は 1GB あたり $0.10 の課金になります。差分抽出を実行することで、データ処理コストを最小限に抑えられます。Glue データカタログは、最初の 100 万オブジェクトの保存料と、最初の月間 100 万リクエストは無料です。Redshift サーバーレスの価格は、RPU 時間（Redshift 処理ユニット）あたり $0.36 からです。AWS価格の詳細については、 AWS Pricing Calculator をご覧ください。(**この例の参考価格はすべて us-east-1 リージョンに基づいていることをご注意ください。) 始めるには、まず AWS Analytics Fabric for SAP のリポジトリ をご覧ください。AWS が何千のアクティブな SAP お客様にイノベーションプラットフォームとして選択された理由は、 AWS for SAP のページをご覧ください。 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。

11月28日、 Amazon Q を発表しました。これは、仕事用に設計された新しい生成系人工知能 (AI) 搭載アシスタントで、お客様のビジネスに合わせてカスタマイズできます。Amazon Q を使用して、会社の情報リポジトリ、コード、データ、企業システムに接続することで、会話し、問題を解決し、コンテンツを生成し、インサイトを獲得し、行動を起こすことができます。Amazon Q は、タスクを合理化し、意思決定と問題解決を加速し、職場での創造性とイノベーションを促進するために、関連性の高い情報とアドバイスを従業員に即座に提供します。 Amazon Q はユーザーベースのプランを提供しているため、製品の使用方法に合わせた機能、料金、オプションを利用できます。Amazon Q は、ビジネスの既存のアイデンティティ、ロール、許可に基づいて、個々のユーザーに合わせてインタラクションが行えます。AWS は、基盤となるモデルのトレーニングに Amazon Q のお客様のコンテンツを使用することはありません。 つまり、会社の情報は安全かつプライベートに保たれます。 この記事では、 Amazon Q を一般的なビジネス用途 に使用する方法について簡単に説明します。 デベロッパーと IT プロフェッショナルが Amazon Q を使用する方法については、「 Amazon Q は IT 専門家とデベロッパーに生成系 AI を活用した支援を提供 プレビュー 」を参照してください。 ビジネスアナリストが QuickSight で Amazon Q を使用する方法については、「 QuickSight の新しい Amazon Q では、生成系 AI アシスタンスを使用して、データインサイトをより迅速かつ簡単に取得 (プレビュー) 」を参照してください。 コンタクトセンターのエージェントによる Amazon Q in Connect の活用法については、「 Amazon Q を含む Amazon Connect の新しい生成系 AI 機能により、コンタクトセンターサービスをさらに向上 」を参照してください。 Amazon Q はお客様のビジネスのエキスパートです ビジネスユーザーが簡単な自然言語プロンプトを使用してタスクを完了するのに Amazon Q がどのように役立つかについて、いくつかの例を見てみましょう。マーケティングマネージャーは、Amazon Q に依頼して、プレスリリースをブログ記事に変換させたり、プレスリリースの概要を作成させたり、提供されたリリースに基づいて E メールをドラフトさせたりすることができます。Amazon Q は、例えば社内のスタイルガイドなどの会社のコンテンツを検索して、会社のブランド基準に適した回答を提供することができます。次に、Amazon Q に依頼して、各ソーシャルメディアチャネルを通じてストーリーを宣伝するためのカスタマイズされたソーシャルメディアプロンプトを生成してもらうことができます。その後、Amazon Q に依頼して、キャンペーンの結果を分析し、経営陣がレビューできるように要約してもらうことができます。 次の例では、 2023 年の AWS ニュースブログの記事 へのアクセス権を持つ Amazon Q をデプロイし、アシスタントを「AWS ブログエキスパート」と呼びます。 前の例に戻って、私がマーケティングマネージャーで、最近の会社のブログ記事のためにソーシャルメディアの投稿を作成するのを Amazon Q に手伝ってもらいたいとします。 次のようなプロンプトを入力します。「Antje が最近の AWS Weekly Rounup の記事から得た重要なインサイトを要約し、最も重要な点を強調するだけでなく、エンゲージメントを促進する、説得力のあるソーシャルメディアの投稿を作成してください。ターゲットオーディエンスを考慮し、ブランドアイデンティティに沿ったトーンになることを目指してください。ソーシャルメディアの投稿は、読者がクリックして記事全体を読むように促すために、簡潔で有益で魅力的なものでなければなりません。コンテンツは共有可能で、視認性を最大限高めるために関連するハッシュタグを含めるようにしてください。」 舞台裏では、Amazon Q は接続されたデータソース内のドキュメントを検索し、私のブログ記事に基づいてソーシャルメディアの投稿のための詳細な提案を作成します。Amazon Q は、どのドキュメントが回答の生成に使用されたかも教えてくれます。この場合、問題のブログ記事の PDF ファイルです。 管理者は、応答のコンテキストを定義し、無関係なトピックを制限し、信頼できる企業情報のみを使用して応答するか、基盤となるモデルからの知識で応答を補完するかを設定できます。信頼できる企業情報のみに基づく応答に制限することで、ハルシネーションを軽減できます。ハルシネーションは、基礎となるモデルが、もっともらしく聞こえるが、誤解されたデータや存在しないデータに基いた応答を生成するという、一般的な現象です。 Amazon Q はきめ細かなアクセスコントロールを行うことができ、応答を従業員のアクセスレベルに基づいたデータの使用や行動に制限したり、事実確認とトレーサビリティのために元の情報源への引用や参照を提供したりします。 Amazon S3 、Google Drive、Microsoft SharePoint、Salesforce、ServiceNow、Slack など、一般的なデータソースやエンタープライズシステムに対応する 40 種類以上の組み込みコネクタの中から選択できます。 Amazon Q をビジネスに合わせてカスタマイズする方法 Amazon Q をビジネスに合わせてカスタマイズするには、 コンソールで Amazon Q に移動し、左側のメニューで [Applications] (アプリケーション) を選択し、 [Create application] (アプリケーションを作成) を選択します。 これにより、次のワークフローが開始されます。 ステップ 1 . アプリケーションを作成します 。アプリケーション名を指定し、Amazon Q が引き受けることができる AWS Identity and Access Management (IAM) サービスロールを新規作成するか、既存のサービスロールを選択します。このデモのアプリケーションを AWS-Blog-Expert と呼びます。次に、 [Create] (作成) を選択します。 ステップ 2 . レトリーバーを選択します 。レトリーバーは、会話中にインデックスからリアルタイムでデータを取得します。Amazon Q ネイティブリトリーバーを使用するか、既存の Amazon Kendra レトリーバーを使用するかの 2 つのオプションから選択できます。ネイティブリトリーバーは、Amazon Q がサポートするデータソースに接続できます。既に Amazon Kendra を使用している場合は、既存の Amazon Kendra レトリーバーを選択して、関連するデータソースを Amazon Q アプリケーションに接続できます。ネイティブリトリーバーオプションを選択します。次に、 [Next] (次へ) をクリックします。 ステップ 3 . データソースを接続します 。Amazon Q には、一般的なデータソースやエンタープライズシステム用のコネクタが組み込まれています。このデモでは、 Amazon S3 を選択し、ブログ記事の PDF が保存されている S3 バケットを参照してデータソースを設定します。 データソースの同期が正常に完了し、レトリーバーが正確なドキュメント数を表示したら、ウェブエクスペリエンスをプレビューして会話を開始できます。データソースの同期には、インデックスを作成するデータの量とサイズに応じて、数分から数時間かかる場合があります。 ServiceNow、Jira、Salesforce、Zendesk など、企業システムへのアクセスを管理するプラグインを接続することもできます。プラグインにより、Amazon Q はサポートチケットの作成や売上予測の分析など、ユーザーが要求したタスクを実行できます。 ウェブエクスペリエンスをプレビューしてデプロイする アプリケーションの概要で、 [Preview web experience] (ウェブエクスペリエンスをプレビュー) を選択します。これにより、カスタマイズされた Amazon Q の AWS ブログエキスパートとチャットするための会話型インターフェイスを利用したウェブエクスペリエンスを享受できます。最後のステップでは、Amazon Q ウェブエクスペリエンスをデプロイします。IAM を使用して SAML 2.0 準拠の外部 ID プロバイダー (IdP) を統合できます。Amazon Q は、SAML 2.0 に準拠しているすべての IdP と連携できます。Amazon Q は、サービス起動型シングルサインオン (SSO) を使用してユーザーを認証します。 プレビューをお試しください Amazon Q は現在、米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンでプレビュー版をご利用いただけます。 Amazon Q がビジネスのエキスパートになれる 方法については、製品ページをご覧ください。 また、 Amazon Q Slack Gateway の GitHub リポジトリもご確認ください。このリポジトリには、Amazon Q を Slack Bot アプリケーションとしてユーザーが利用できるようにする方法が記載されています。 詳細はこちら Amazon Q のメインの製品ページ 一般的なビジネス用途向けの Amazon Q –  Antje 原文は こちら です。

アプリケーションが古くなるにつれて、アプリケーションを安全に保ち、スムーズに実行するためだけにますます多くの労力が必要になります。アップグレードを管理するデベロッパーは、過去のアップグレードで既に他のデベロッパーが発見した、重大な変更やパフォーマンスの最適化に潜む複雑さと微妙な違いを再学習する必要に迫られます。その結果、新機能と重要なメンテナンス作業のバランスを取ることが難しくなります。 11月28日、 Amazon Q Code Transformation のプレビュー版をご利用いただけるようになりました。この新機能により、 生成系人工知能 (AI) を活用した新しいタイプのアシスタントである Amazon Q を使用して、既存のアプリケーションコードを簡単にアップグレードおよび最新化できます。Amazon Q は仕事に特化して設計されており、お客様のビジネスに合わせてカスタマイズできます。 Amazon Q Code Transformation では、バージョン 8 および 11 から Java Long-Term Support (LTS) リリースであるバージョン 17 への Java アプリケーションのアップグレードが行えます。また、まもなく Windows ベースの .NET Framework アプリケーションをクロスプラットフォームの .NET に変換できるようになります。 以前は、デベロッパーは各アプリケーションのアップグレードに 2～3 日を費やす必要がありました。社内テストでは、手動アップグレードでは通常数日または数週間かかるのに対し、トランスフォーメーション機能によってアプリケーションを数分でアップグレードできることが示されています。これにより、新しいビジネス要件に集中する時間ができます。例えば、5 人で構成される Amazon のある社内チームは、2 日間で 1,000 個の本番アプリケーションを Java 8 から 17 にアップグレードすることに成功しました。アプリケーションのアップグレードには平均で 10 分かかり、最長のアップグレードにかかった時間は 1 時間未満でした。 Amazon Q Code Transformation は、既存のコードを自動的に分析し、変換プランを生成し、プランによって提案された変換タスクを完了します。その際、パッケージの依存関係を特定して更新し、非推奨で非効率なコードコンポーネントをリファクタリングし、新しい言語フレームワークに切り替え、セキュリティのベストプラクティスを組み込みました。完了したら、変更を受け入れる前に、変換されたコードを確認して、ビルドとテストの結果を完成させることができます。 これにより、わずか数ステップでアプリケーションを最新の状態に保ち、サポートを維持し、パフォーマンス上のメリットを享受し、サポートされていないバージョンを使用することによる脆弱性を取り除くことができるため、新しいビジネス要件に集中する時間を確保できます。では、これが実際にどのように機能するのかを見てみましょう。 Java アプリケーションをバージョン 8 から 17 へアップグレードする このチュートリアルでは IntelliJ IDEA を使用しています (Visual Studio Code でも同じことができます)。IDE で Amazon Q Code Transformation を使用するには、 AWS Toolkit for IntelliJ IDEA の最新バージョンをインストールし、組織から提供された AWS IAM アイデンティティセンター の認証情報を使用してサインインします。Amazon Q Code Transformation にアクセスするには、組織が使用するプロファイルで、 CodeWhisperer 管理者が Amazon Q 機能へのアクセス許可を明示的に付与する必要があることにご注意ください 。 新しいバージョンの Java に更新する時間がなかった古いプロジェクトを開きます。プロジェクトは Apache Maven を使用してビルドを管理しています。プロジェクトの XML 表現であるプロジェクトオブジェクトモデル (POM) ファイル ( pom.xml ) は、ルートディレクトリにあります。 まず、プロジェクト設定で、プロジェクトが正しい SDK バージョン (この場合は 1.8) を使用するように設定されていることを確認します。左側のペインで [AWS Toolkit] (AWS ツールキット) を選択し、次に [Amazon Q+ CodeWhisperer] タブを選択します。 [Amazon Q (Preview)] (Amazon Q (プレビュー)) セクションで、 [Transform] (変換) を選択します。 これによりダイアログが開き、変換を続行する前に、アップグレード用に正しい Maven モジュールが選択されていることを確認できます。 [Transformation Hub] (変換ハブ) ウィンドウで進捗状況を確認します。私の小さなアプリケーションではアップグレードは数分で完了しますが、大きなアプリケーションでは完了するまでに 1 時間以上かかる場合があります。 エンドツーエンドのアプリケーションアップグレードは、次の 3 つのステップで構成されます。 アプリケーションを識別し分析する – コードはクラウド内の管理環境にコピーされ、リポジトリ内の指示に基づいてビルドプロセスがセットアップされます。この段階で、アップグレードするコンポーネントが特定されます。 変換プランを作成する – コードを分析して、Amazon Q Code Transformation がコードをアップグレードするために実行するステップを列挙した変換プランを作成します。このステップには、依存関係の更新、アップグレードされたコードの構築、アップグレード中に発生したビルドエラーの反復修正などがあります。 コードを生成し、ビルドをテストし、ファイナライズする – 変換プランを繰り返し実行して、既存のコードと設定ファイルを更新し、必要に応じて新しいファイルを生成し、コードとともに提供されたテストを用いてビルド検証を実行し、失敗したビルドで特定した問題を修正します。 数分後、変換は正常に終了します。ここから、プランと変換の概要を開くことができます。提案されている変更を確認するには、 [View diff] (差分を表示) を選択します。 [Apply Patch] (パッチを適用) ダイアログに、追加、変更、または削除されたファイルの要約が表示されます。 まず、 pom.xml ファイルを選択し、次に [Show Difference] (差分を表示) (左/右矢印の付いたアイコン) を選択すると、プロジェクト内の現在のコードと提案されている変更が並べて表示されます。例えば、依存関係の 1 つ ( Project Lombok ) が、ターゲットの Java バージョンとの互換性のためにバージョンアップしていることがわかります。 Java ファイルでは、アップグレードされた依存関係で使用される注釈が更新されました。新しいバージョンでは、 @With が昇格し、(実験的な) @Wither は非推奨になりました。これらの変更は インポート ステートメントに反映されます。 また、アップグレードを完了するために加えられた変更をすばやく確認できるように、コードリポジトリにサマリーファイルを保存しています。 ファイルを確認するのに少し時間を費やします。次に、 [OK] を選択してすべての変更を確定します。 これでパッチは正常に適用され、提案された変更がコードとマージされました。リポジトリに変更をコミットし、移行が完了するのを待っていたビジネスクリティカルな変更に焦点を当てます。 知っておくべきこと Amazon Q Code Transformation のプレビューは、 AWS Toolkit for IntelliJ IDEA と AWS Toolkit for Visual Studio Code の Amazon CodeWhisperer Professional Tier のお客様に本日ご利用いただけます。Amazon Q Code Transformation を使用するには、組織が使用するプロファイルへのアクセス権を CodeWhisperer 管理者が付与する必要 があります。 プレビュー中に Amazon Q Code Transformation を使用しても追加費用はかかりません。 Apache Maven を使用して構築された Java 8 および 11 アプリケーションを Java バージョン 17 にアップグレードできます。プロジェクトのルートディレクトリには POM ファイル ( pom.xml ) が必要です。間もなく、Windows ベースの .NET Framework アプリケーションをクロスプラットフォーム .NET に変換するオプションを追加し、Linux への移行を迅速に行えるようにする予定です。 変換ジョブが完了したら、差分ビューを使用して提案された変更を確認して承認できます。最終的な変換の概要には、Amazon Q Code Transformation によって更新された依存関係と変更されたコードファイルの詳細が表示されます。また、アップグレードされたコードの最終ビルドで発生したビルドエラーの詳細も記載されており、問題の修正やアップグレードの完了に使用できます。 Amazon Q Code Transformation は、自動推論と静的コード分析への Amazon の長期投資と 生成系 AI の力を組み合わせることで、基盤モデルを組み込んでいます。これは、後方互換性のない変更で Java ライブラリのロングテールを更新する必要があることが多いコンテキスト固有のコード変換に不可欠であることがわかりました。 AWS が構築した生成系 AI を活用したコード変換に加えて、Amazon Q Code Transformation では OpenRewrite の一部を使用して、お客様の Java アップグレードをさらに加速しています。AWS では、サービスの多くがオープンソースコンポーネントで構築されており、これらのコミュニティの長期的な持続可能性を促進することは、AWS とお客様にとって非常に重要です。だからこそ、OpenRewrite のようなコミュニティに貢献し、業界全体がそのイノベーションの恩恵を受け続けることができるようにすることが当社にとって重要なのです。AWS は、Amazon Q Code Transformation のオープンソースへの移行の一環として開発された OpenRewrite レシピと改善に貢献する予定です。 「ソフトウェアがはるかに速いペースで適応できることは、どの企業にとっても最も基本的な利点の 1 つです。だからこそ、AWS がオープンソースの自動コードリファクタリング技術である OpenRewrite をサービスの構成要素として使用していることは喜ばしいことです」と、 Moderne (OpenRewrite のスポンサー) の CEO 兼共同創設者である Jonathan Schneider 氏は述べています。「AWS が OpenRewrite コミュニティに参加してくれたことを嬉しく思います。フレームワークの移行、脆弱性へのパッチ適用、API の更新をさらに簡単にするために AWS が貢献してくれることを楽しみにしています」。 Java アプリケーションを今すぐアップグレード Amazon Q Code Transformation 製品ページ – Danilo 原文は こちら です。

こんにちは！アマゾンウェブサービスジャパン合同会社ソリューションアーキテクトの松本です。2023 年 11 月 17 日に製造業のお客様を対象にした「Sustainability Event」を開催いたしました。イベントの開催報告として、このブログではイベントの背景や実施内容などをお届けいたします。 はじめに 製造業に限らず、多くのお客様はサステナビリティへの取り組み目標や戦略をサステナビリティレポートや中期経営計画に掲げており、特に環境におけるカーボンニュートラル、低炭素の具体数値目標の達成に向けて高い関心をお持ちです。私たちソリューションアーキテクトはお客様のビジネス変革や IT 変革をリードすることがミッションであり、サステナビリティの観点でもお客様をご支援する方法を常に模索しています。今回のイベントはそのアイデアの一つとして開催する運びとなりました。 イベントの狙い サステナビリティへの取り組みは、その目標を設定した経営層だけではなく、多くの場合で社員全員が当事者意識を持ち、目標達成に貢献することが求められます。普段私たちが接している技術ロールの皆様も例外ではありませんが、通常業務とサステナビリティへの貢献を関連付けることは、なかなか難しいですよね。もしくは、どのような点で IT やクラウドの活用が貢献できるのか、その手段や特徴を知る機会も限られているかもしれません。一方で、AWS には AWS Well-Architected Framework (W-A Framework) の 持続可能性の柱 や AWS Gravtion プロセッサ など、サステナビリティにおける課題を解決できるソリューションを提供しています。既にこれらのソリューションを活用しているお客様も多くいらっしゃいますが、ご存知ない方がいらっしゃることもまた事実です。 そこで私たちは、お客様にサステナビリティ目標達成に向けた最初の一歩を踏み出していただくため、AWS のソリューションとその特徴を知っていただくこと、そして実際に利用する経験の場を提供することが必要と考え、今回の企画を始動しました。 イベント概要 AWS のソリューションを効果的に学んでいただくためには、実践的な体験をすることが重要だと考えています。ただし、体験する内容に理解が無いまま取り組むこともまた効果的とは言えません。そこで今回のイベントでは、まず AWS を利用することがどういった観点でサステナビリティへ貢献できるのかを理解していただくため、 W-A Framework Boot Camp の 持続可能性の柱版 を実施しました。この Boot Camp とは、仮想シナリオとアーキテクチャをもとに、W-A Framework を使ったレビューを体験していただくワークショップです。参加者は 4 ~ 5 名のグループに分かれ、チームごとに割り当てられた項目について As-Is と To-Be を議論・整理・発表していただきます。実際に W-A Framework を使った議論とレビュー、グループ間の情報交換や質疑を重ねることによって、W-A Framework の項目に対する理解を深めることができます。 このワークショップを実施した上で、 Sustainability GameDay にチャレンジしていただきました。GameDay とは、AWS ソリューションを利用して現実世界の技術的問題を解決することを目指すゲーム化された学習イベントです。参加チームにはイベント開始と同時にセットアップ済みの AWS アカウントが与えられ、そこで発生する様々なトラブルやクエストをクリアしていきます。（詳しくは こちら をご参照ください。）GameDay には様々なポートフォリオ（シナリオ）があり、今回は「 Reuse, Recycle, Reduce, Rearchitect 」にチャレンジしていただきました。 当日の様子 当日は AWS の目黒オフィスと Amazon Chime を利用したリモートのハイブリッド形式で開催し、総勢 40 名 14 チームの方にご参加いただきました。 はじめに、エンタープライズ技術本部製造グループ本部長の岡本から開会のご挨拶をさせていただきました。サステナビリティの高いアーキテクチャは、同時にコスト最適化など異なる観点にも寄与することから、実務にも大いに活かせることを解説させていただきました。 次に、イベント全体を通じて登場する AWS Gravtion プロセッサについて、ソリューションアーキテクトの寺部からご紹介させていただきました。詳しい内容にご興味がある方は、ぜひ AWS Black Belt オンラインセミナーをご覧ください。 ( 動画 、 資料 ) 続いて、ソリューションアーキテクトの杉本からは W-A Framework の持続可能性の柱について、ご説明させていただきました。皆様も持続可能性の柱が追加になったことはご存知だと思いますが、その設計原則や質問まではご覧になっていないかもしれません。この機会にぜひ一度 チェックしてみてください。 そして午前のメインイベント、W-A Framework Boot Camp です。今回は持続可能性の柱から、4 つの質問をピックアップし、チームごとに割り当てさせていただきました。当日のシナリオは残念ながらこの場でお見せすることはできませんが、以下のようなワークシートをもとに As-Is と To-Be を議論していただきました。 約 40 分のディスカッションタイムを終え、各参加チームは自チームの検討結果を発表しながら、他チームの発表にも耳を傾けていました。 お昼休憩のあとは、いよいよ GameDay の開催です。 イントロダクションは今回の舞台となるスタートアップ企業「ユニコーンレンタル」の CEO の挨拶から始まりました。どうやらこの会社はとても自由な社風のようですね。この GameDay には「ひどいジョークに対しても大笑いする義務がある」というレギュレーションがあるのですが、ありがたいことに違反者は一人も出ませんでした。 GameDay についても、あいにく詳細を明かすことはできませんが、参加者の皆様は困難な状況に立たされてしまったユニコーンレンタルを救うべく、様々な問題に果敢に挑戦していただきました。約 2.5 時間の熾烈な戦いの末、ついに優勝チームが決定し、AWS のささやかな商品贈呈と表彰式とともにイベントの幕を閉じました。 開催を振り返って 盛況のうちに終了した丸一日のイベントでしたが、ご参加いただいた皆様からはどのようなフィードバックをいただけたのでしょうか。ここでいくつかご紹介させていただくと、「 こういうサービスがあるということはわかっていましたが、実際に作業をすることはほとんどないので勉強になりました。 」「 普段触らないサービスをに触れる機会ができ勉強になりました。 」とまさに実践の必要性をご体感いただけていたようです。また、「 サステナビリティの達成に活用できるサービスはいっぱいあると思うので、掘り下げて紹介してほしい 」のように、今回のテーマであるサステナビリティへの関心を高めて下さった方もいらっしゃり、大変嬉しく感じています。中には「 内容はよかったが私の準備が足りておらず太刀打ちできなかった 」と悔しさを滲ませるコメントもありましたが、ぜひ今後の学習やイベント参加の糧にしていただきたいと思います。 まとめ 私たちは今回のイベントをお客様がサステナビリティ目標達成に向けて初めの一歩を踏み出す場と位置付けていました。まだお客様がご存知ない、あるいは体験したことが無い AWS のソリューションを経験していただき、サステナビリティに貢献できることに多少なりとも気づいていただけたと実感しています。しかし、まだまだ至らない点があることにも気づかされました。私たちはこの一度の開催に留まらず、さらに貢献できる方法を模索し続けたいと考えています。 もし、このブログを通じて「こういったイベントに参加したい」もしくは「自社で参加者を募って開催したい」などのご要望があれば、ぜひご担当のソリューションアーキテクトか、 こちら までご連絡ください。すぐにユニコーンレンタルの CEO とともに駆けつけたいと思います。 ここまで読んでいただき、ありがとうございました。 松本 修一 アマゾンウェブサービスジャパン合同会社のソリューションアーキテクトです。普段は製造業のお客様のご支援を中心に活動しています。趣味はオンラインゲームで、日々インターネットの向こうにいる仲間たちと冒険に出かけています。

11月28日、 Amazon CodeCatalyst の新しい生成系人工知能 (AI) 機能のプレビュー版をご紹介できることを嬉しく思います。これにより、 Amazon Q を使用してソフトウェアの配信を高速化できます。 機能開発を加速する – Amazon Q の機能開発機能は、コメントや README の追加、問題の説明の改良、小さなクラスや単体テストの生成、CodeCatalyst ワークフローの更新など、デベロッパーにとって時間がかかり面倒で差別化されていないソフトウェア開発タスクの実装を加速するのに役立ちます。デベロッパーは、わずか数回クリックするだけで、自然言語の入力のみで問題内のアイデアから、完全にテストされ、マージの準備が整った実行可能なコードへと移ることができます。AI は、人間のプロンプトを実行可能なプランに変換し、ソースコードリポジトリを要約し、コード、単体テスト、ワークフローを生成し、デベロッパーに割り当てられるプルリクエストの変更を要約するという面倒な作業を行います。発行されたプルリクエストについて直接 Amazon Q にフィードバックを行い、新しいリビジョンを生成するよう依頼することもできます。コード変更が期待通りにならなかった場合は、プルリクエストから直接開発環境を作成し、必要な調整を手動で行い、新しいリビジョンを発行し、承認されたらマージを進めることができます。 例: 既存のアプリケーションで API を変更する ナビゲーションペインで [Issues] (課題) を選択し、次に [Create issue] (課題を作成) を選択します。課題に、 get_all_mysfits() API を変更して、Age 属性でソートされた mysfits を返す というタイトルを付けます。次に、この課題を Amazon Q に割り当て、 [Create issue] (課題を作成) を選択します。 Amazon Q は、課題のタイトルと説明を分析して潜在的な解決策を策定する間、課題を自動的に [In progress] (進行中) 状態に移します。課題について既に話し合いが行われている場合は、Q が何をすべきかを理解できるように、説明に簡潔に記述する必要があります。処理が進むにつれ、Amazon Q は各段階で課題に関するコメントを残して進捗状況を報告します。リポジトリに既に存在するコードの理解と、策定したアプローチに基づいて、ソリューションを作成しようとします。Amazon Q が潜在的なソリューションを上手く生成できれば、ブランチを作成し、そのブランチにコードをコミットします。次に、プルリクエストを作成し、承認されると変更をデフォルトブランチにマージします。プルリクエストが発行されると、Amazon Q は問題のステータスを [In Review] (レビュー中) に変更します。これにより、ユーザーとチームはコードをレビューする準備ができたことがわかります。 変更を要約する – プルリクエストの作成者は、発行している変更をレビュー用に要約するよう Amazon Q に依頼することで、時間を節約できます。これまで、プルリクエストの作成者は説明を手動で記述しなければならず、まったく記述しないことにする場合もあります。作成者が説明を行わないと、どのような変更が行われたのか、またその理由をレビュー担当者が理解しにくくなり、レビュープロセスが遅れ、ソフトウェアの配信に遅れが出てしまいます。 プルリクエストの作成者とレビュー担当者は、Amazon Q にプルリクエストに残されたコメントを要約するよう依頼することで時間を節約することもできます。概要は、共通のフィードバックテーマを簡単に確認できるため、作成者にとって便利です。レビュー担当者にとっては、自分自身や他のチームメンバーからの会話やフィードバックにすばやく追いつくことができるので便利です。全体的なメリットには、コラボレーションの効率化、レビュープロセスの迅速化、ソフトウェア配信の迅速化があります。 プレビューをお試しください Amazon Q は本日より、米国西部 (オレゴン) の AWS リージョンのスペースで Amazon CodeCatalyst でご利用いただけるようになります。 詳細はこちら Amazon CodeCatalyst の製品ページ Amazon CodeCatalyst ユーザーガイド – Irshad 原文は こちら です。

また一つ re:Invent が閉幕し、参加されたお客様は、期間中、技術セッションで学習し、インタラクティブなデモを巡り、仲間とネットワーキングし、re:Play セレブレーションでの楽しんだりと、忙しい1週間を過ごされたと思います。 新しいサービス、機能、ソリューションに関する素晴らしいアナウンスがあり、これらは製造業の企業がクラウドでのデジタルトランスフォーメーションの旅を加速し、パイロット状態の先にあるスケーラブルなビジネス変革のイニシアチブへの移行に役立ちます。 今回のイベントには製造業の経営層や一般参加者も多く参加され、このイベントが「ただの」開発者に向けたものという概念がなくなったことを示しています。 注目のセッションを視聴する ライブストリームされた基調講演セッションを見逃された場合は、 CEO の Adam Selipsky の基調講演 をチェックすることをおすすめします。彼はクラウドトランスフォーメーションについての視点を共有し、データ、インフラストラクチャ、人工知能と機械学習の分野のイノベーションを強調しました。 これらの進歩により、AWS のお客様は目標をより速く達成し、未開拓分野の可能性を掘り下げ、より良い未来を創造することができます。 Adam の基調講演に続いて、製造・自動車担当 Vice President の Wendy Bauer が イノベーショントーク を発表しました。 彼女は、自動車、航空宇宙、民生エレクトロニクスなどの業界の企業が、クラウドテクノロジーを使用してビジネスの運用を最適化し、上市までの時間を短縮し、新しいビジネスアプローチによって新しい収益源を生み出す方法について説明しました。 Siemens Digital Industries Software の社長兼 CEO である Tony Hemmelgarn が AWS 上で動作する Xcelerator 産業ソフトウェアポートフォリオを使用してイノベーションを起こす方法について語りました。本田技研工業のコネクテッドソリューション開発本部長の野川忠文氏、アメリカ HONDA のサステナビリティ・ビジネス開発担当 Vice President の Jay Joseph と Wendy が、AWS でのソフトウェア定義 (Software Defined) のモビリティと電動化における本田との取り組みについて語り合いました。 エマージングテックのイノベーショントーク では、AWS のエンジニアリング担当 Vice President の Bill Vass と Siemens Factory Automation の CEO Rainer Brehm が OT における課題、特にデータのアクセシビリティと IT との統合について説明しました。 また、 Siemens Industrial Edge Marketplace で利用可能な AWS IoT SiteWise Edge を発表し、生産現場からクラウドへの OT データフローを容易にすることを発表しました。これに 関連するブレークアウトセッション で、AWS IoT Industrial Edge のヘッド Nicolas Pouyez と Siemens Factory Automation のエッジエコシステム担当 Vice President の Torben Poertner が、AWS と Siemens の新しい提携について説明しました。産業機器データの AWS クラウドへの送信を簡単にし、取り組みの加速とコスト削減に役立つ AWS と Siemens の提携の詳細については、 Accelerate shop floor digitization with edge-to-cloud data integration (IOT215) のセッション録画や ブログアナウンス をご確認ください。 月曜日には、 Peter DeSantis が AWS サービスを支えるエンジニアリングに深く掘り下げました。 AWS のユニークなアプローチとイノベーション文化が、シリコンからサービスに至る全領域にわたって、パフォーマンスやコストを犠牲にすることなく、最先端のソリューションを作成する方法を詳しく紹介しています。 水曜日には、データと AI 担当の Vice President である Dr. Swami Sivasubramanian が、目の前で繰り広げられている、人間・データ・AI のパワフルな関係について探求しました。 生成系 AI は生産性と創造性を新しい方法で高めていますが、その背後は大量のエンタープライズデータと人間の知性が推進しています。 Swami は、企業が独自の生成系 AI アプリケーションを構築し、組織全体の従業員の生産性を加速するためにどうデータを使用するかについて説明しました。 登壇されたお客様は、生成系 AI ユースケースをサポートし、顧客に新しいエクスペリエンスを提供するためのデータ活用の実例について詳しく説明されました。 木曜日に最高技術責任者の Dr. Werner Vogels は、回復力がありコストを意識したアーキテクチャ設計のベストプラクティスを強調し、人工知能は、システムを開発する際にすべてのビルダーが考慮すべきものであること、そしてそれが世界に及ぼす影響についても説明しました。 すべての基調講演とイノベーションセッションの録画を ここで チェックしてください。 製造業のお客様は多くのセッションに参加されていますが、以下のリストは、現在製造業のお客様に最も人気のあるトピックをまとめたものです。 From Machine to Digital Services: Equipment as a Service (MFG 104) Improving Manufacturing at Panasonic Energy (MFG 101) Accelerating Innovation with High-Performance Computing on AWS (MFG 105) Product Innovation and Customer Engagement with Ferrari and Autodesk (MFG 106) Northvolt’s Software-defined Factories (MFG 202) Highly Automated Driving with BMW and Qualcomm (AUT 202) Cloud Migration with Zero Downtime: Toyota Drivelink Safety Connect (AUT 205) Predictive maintenance at scale: Koch Ag & Energy Solutions (AIM 216) サービス、機能、ソリューションのリリース re:Invent の直前からイベント期間中、AWS のイノベーションはまるで鳴り続けるドラムロールのようでした。まず、製造業や産業企業に適用できる、いくつかのサービスと拡張機能をリリースしました。なぜそれらが重要なのか、読み解いていきましょう。 以前のブログ で、生成系 AI には新しい製品デザインを作り出す可能性、これまでにないレベルで製造生産性を高める可能性、サプライチェーン アプリケーションを最適化する可能性があると説明しました。期間中、いくつかの生成系 AI 関連のサービスと機能をリリースしましたが、最も注目すべきは Amazon Q (プレビュー)です。Amazon Q は、企業の情報リポジトリ、コード、エンタープライズ システムにあるデータと専門知識を使用して、急ぎの質問に対して迅速で関連性の高い回答を得て、問題を解決し、コンテンツを生成や、業務上のアクションを実行するのに役立ちます。Amazon Q とチャットすると、業務の効率化、意思決定のスピードアップ、職場での創造性とイノベーションの促進に役立つ、タイムリーな関連情報とアドバイスを提供します。開発者と IT 専門家にとって、Amazon Q は AWS 上でアプリケーションやワークロードを構築、展開、運用する方法を変革します。Amazon Q は AWS Well-Architected フレームワークのパターン、ベストプラクティス、ドキュメント、ソリューションの実装についてのエキスパートであり、製造業の企業が新しいサービスと機能を知り、すぐに使い始め、新しいテクノロジーを学習し、ソリューションを設計し、トラブルシューティングを行い、アプリケーションをアップグレードするのが容易になります。また、機械学習のトレーニング時間とコストを低減し、エネルギー消費量を削減する AWS Graviton4 と AWS Trainium2 もリリースしました。さらに、 Amazon SageMaker HyperPod もリリースしました。これは、大規模なトレーニング コンピュートクラスターを管理し最適化する際の大掛かりな作業を減らし、基盤モデル (FM) のトレーニングを加速させるためのものです。SageMaker HyperPod を使えば、週や月にわたる FM のトレーニングでも中断することなく実行できます。 産業用 IoT と機械学習の新たな発表 AWS IoT SiteWise は、産業機器からのデータを大規模に収集、保存、整理、監視することを簡単にするマネージド サービスであり、より良いデータ駆動型の意思決定を支援します。新たに AWS パートナーの Domatica との統合を通じて、10 種類の産業プロトコル (Modbus (TCP & RTU)、Ethernet/IP、Siemens S7、KNX、LoRaWAN、MQTT、Profinet、Profibus、BACnet、Rest インターフェイス) に対するサポート追加の一般利用可能 (GA) を発表しました。これは、ネイティブでサポートしている OPC UA に追加されるものです。そして、機器データの取り込みと保存のコスト削減を目的とした、 アセットモデルコンポーネント 、 アセットの一括インポート 、 Lookout for Equipment との統合 、 バッファされた取り込み 、 ユーザー定義の一意の識別子 、 クエリ API/SQL 、新しい ウォームストレージ階層 などの、新たな拡張機能も発表しました。また、工場のエッジに導入されるオンプレミスソフトウェアの AWS IoT SiteWise Edge を、 Siemens Industrial Edge マーケットプレイス から直接展開できるようになったと発表しました。これにより、産業機器のデータを AWS クラウドに送信することを簡単にし、時間を短縮し、コストを削減できます。 このブログ は、AWS IoT SiteWise でリリースされた全機能のまとめを提供しており、お客様が価値を見出すまでの時間短縮に役立ちます。 また、 AWS IoT TwinMaker の拡張機能 を発表しました。これにより、顧客はデジタルツインをさらに迅速かつ効率的にモデル化し、展開し、大規模に拡大することできます。メタデータの一括操作(インポート、エクスポート、更新など)、より大きなエンティティ数とコンポーネント数をサポートする AWS IoT TwinMaker サービスクォータ の引き上げ、複雑なコンポーネントタイプを構築するための柔軟性と効率性を提供する新しい複合コンポーネントタイプが含まれます。Amazon Monitron も新しい Amazon Monitron Ex 定格センサー で進化を遂げています。これは、危険な環境向けの本質安全 (Intrinsically Safe) な製品です。 サプライチェーンのリリース 昨年の re:Invent では、製造業のお客様にとって重要なサプライチェーン領域を支援するために、AWS Supply Chain をリリースしました。今年、AWS Supply Chain は4つの新機能を発表しました: サプライプランニング、N 階層の可視化、サステナビリティ、AWS Supply Chain における Amazon Q (プレビュー)です。これらの 新機能 は、サプライヤや取引先からの原材料や部品の調達と移動を含む、サプライチェーンの上流部分を最適化します。加えて、EDI ベースのビジネスクリティカルな取引をスケールして自動化する AWS B2B Data Interchange をリリースしました。B2B Data Interchange は、取引先との EDI の構築と管理にかかる時間や、複雑さ、コストを削減し、取引データから洞察を得ることに集中できるようにします。 もう一つの産業機器メーカーに有意義なサービス発表は、 AWS Clean Rooms ML (プレビュー)です。これは、産業機器メーカーとそのエンドユーザ製造業者が、生データを共有することなく、プライバシー保護を行いながら ML を適用して予測に基づくインサイトを生成できるようにすることができます。この機能でサポートされる最初のモデルは、企業が類似セグメントのデータ作成を支援するために開発されています。 AWS Clean Rooms ML の類似モデリングを使用すれば、自社のデータを使用してカスタムモデルをトレーニングし、パートナーに少量のレコードサンプルをコラボレーションに持ち込んでもらい、基礎となるデータを保護しながら、類似レコードのセットを拡大生成することができます。 ストレージとハイパフォーマンスコンピューティングのリリース データへのアクセス速度を S3 Standard クラスに比べ10倍改善し、リクエストコストを50%削減できる Amazon S3 Express One Zone ストレージクラス をリリースしました。これは、一貫して1桁ミリ秒のリクエストレイテンシを必要とするパフォーマンス重視のアプリケーション向けに設計された最速のクラウドオブジェクトストレージです。 Amazon WorkSpaces Thin Client が一般提供開始となりました。これは、幅広いエンドユーザーにコスト効率の良い安全な仮想デスクトップへのアクセスを提供し、エンドユーザーと IT スタッフの生産性を向上させます。エンドユーザーはデバイス上のガイド付きデプロイメントエクスペリエンスを使用してエンドポイントデバイスの設定と仮想デスクトップへの接続を数分で完了でき、IT からの追加の支援を必要としません。 re:Invent の直前には、 Research and Engineering Studio on AWS (RES) もリリースしました。これは管理者がセキュアなクラウドベースの研究・エンジニアリング環境を作成し管理するための、オープンソースの使いやすい Web ベースのポータルです。RES を使用すると、科学者やエンジニアはクラウドの専門知識を必要とせずに、データの可視化やインタラクティブアプリケーションの実行が可能です。 最後に、AWS は3つ種類の 新しい Amazon EC2 インスタンス を導入しました: NVIDIA H200 Tensor Core GPU で動作する P5e インスタンスは、大規模かつ最新の生成 AI および HPC ワークロード向けです。NVIDIA L4 GPU とNVIDIA L40S GPU でそれぞれ動作する G6 および G6e インスタンスは、AI ファインチューニング、推論、グラフィックス、映像ワークロードなど、幅広いアプリケーション向けです。 終わりに 今年の re:Invent では、AWS のイノベーションが製造業のデジタルトランスフォーメーションを加速し、ビジネスを最適化するのにどう役立つかが示されました。また、開発者中心のカンファレンスから、製造バリューチェーン全体を対象としたイベントへの移行も印象的でした。本年のイベントに参加できなかったお客様は、次回の re:Invent がネバダ州ラスベガスで 2024年 12 月 2 日から 6 日の日程で開催されることを楽しみにしてください! TAGS: AWS for Industrial , aws manufacturing , Manufacturing , re:invent Scot Wlodarczak Scot は 2018 年 7 月に AWS に入社し、現在は製造業のマーケティング活動を管理しています。Scot はこれまで、シスコとロックウェル・オートメーションに勤務し、インダストリアル・マーケティング・マネージャーおよびリージョナル・マーケティング・リーダーを務めました。 Scot は、デジタル変革の過程にある産業界の顧客へのマーケティングと、IT と OT のギャップを埋めることに重点を置いてきました。 彼は幅広い業界でオートメーションの経験があります。 Scot は、ニューヨーク州立大学バッファロー校で機械工学の学位を、コロラド大学で経営学の修士号を取得しています。 コロラド在住。 本記事は AWS ブログ re:Invent wrap up for manufacturing – not only for developers anymore! を翻訳したものです。翻訳はソリューションアーキテクトの山本が担当しました。

Amazon EKS Pod Identity を利用すると Amazon EKS の Pod 単位で簡単に IAM ロール権限を与えることができます。このブログでは Amazon EKS Pod Identity を利用して Amazon Bedrock アクセスするアプリケーションを実行する例をご紹介します。 Amazon EKS Pod Identity の開始方法や詳細につきましては以下のブログをご確認ください。 ブログ： Amazon EKS Pod Identity は、Amazon EKS クラスター上のアプリケーションの IAM 許可を簡素化します 前提条件 このブログでは、既存の Amazon EKS クラスター を使用します。 Amazon Bedrock は 東京リージョン ( ap-northeast-1 ) で anthropic.claude-instant-v1 のモデルが有効化している状態とします。 Amazon EKS Pod Identity の Add-on が既存の Amazon EKS クラスター にインストールしている状態とします。 本手順で公開するアプリケーションは 0.0.0.0:80 でパブリックに公開されますので、必要に応じてセキュリティグループを利用してアクセス制限を行ってください。 特に本番環境で利用する上では Amazon EKS のセキュリティベストプラクティス をご確認の上デプロイを行ってください。 Amazon Bedrock アクセスするアプリケーションの実行 まずは IAM ロール権限がない状態で以下のソースコードで実行されるアプリケーションを build して Amazon EKS 上で実行し、Amazon Bedrock アクセスできないことを確認します。 コンテナイメージの作成 Amazon Bedrock アクセスするアプリケーションのコードの例 ( app.py ) import streamlit as st import boto3 import json st.title("Bedrock Chat") # Bedrock Runtimeサービス用のクライアント bedrock = boto3.client( service_name='bedrock-runtime', region_name='ap-northeast-1') def format_chat_history(messages): formatted_history = "" for message in messages: # ユーザーかアシスタントかに応じてロールを設定 role = "Human:" if message["role"] == "user" else "Assistant:" # メッセージを整形して追加 formatted_history += f"{role} {message['content']}\n" return formatted_history # チャット履歴の初期化 if "messages" not in st.session_state: st.session_state.messages = [] # アプリ再実行時にチャットメッセージを表示 for message in st.session_state.messages: with st.chat_message(message["role"]): st.markdown(message["content"]) # ユーザー入力の受け取り if prompt := st.chat_input("What is up?"): # ユーザーメッセージをチャットメッセージコンテナに表示 with st.chat_message("user"): st.markdown(prompt) # ユーザーメッセージをチャット履歴に追加 st.session_state.messages.append({"role": "user", "content": prompt}) # 対話履歴を整形してモデルの入力用に準備 chat_history = format_chat_history(st.session_state.messages) # アシスタントの応答をチャットメッセージコンテナに表示 with st.chat_message("assistant"): message_placeholder = st.empty() full_response = "" # 整形された対話履歴と新しいユーザー入力をモデルに送信 body = json.dumps({ 'prompt': chat_history + 'Human: ' + prompt + '\n\nAssistant:', 'max_tokens_to_sample': 1000, "stop_sequences": ["\n\nHuman:"], "anthropic_version": "bedrock-2023-05-31" }) accept = 'application/json' contentType = 'application/json' model_id = 'anthropic.claude-instant-v1' response = bedrock.invoke_model_with_response_stream( body=body, modelId=model_id, accept=accept, contentType=contentType) stream = response.get('body') for event in stream: chunk = event.get('chunk') if chunk: # 取得したチャンクを追加し、Streamlitに表示 full_response += json.loads(chunk.get('bytes').decode() )["completion"] message_placeholder.markdown(full_response + "▌") message_placeholder.markdown(full_response) # アシスタントの応答をチャット履歴に追加 st.session_state.messages.append( {"role": "assistant", "content": full_response}) Dockerfileの例 FROM python:3.11-slim WORKDIR /app RUN apt-get update && apt-get install -y \ curl \ && rm -rf /var/lib/apt/lists/* COPY ./requirements.txt /app/requirements.txt RUN pip install --no-cache-dir --upgrade -r /app/requirements.txt COPY ./app.py /app RUN adduser --disabled-password --gecos '' streamlit USER streamlit EXPOSE 8501 HEALTHCHECK CMD curl --fail http://localhost:8501/_stcore/health ENTRYPOINT ["streamlit", "run", "app.py", "--server.port=8501", "--server.address=0.0.0.0"] requirements.txtの例 boto3==1.29.4 botocore==1.32.4 streamlit==1.28.2 Amazon EKS Pod Identity 使用する場合、 AWS SDK は 一定以上のバージョン が必要になります。 以下のようにディレクトリにソースコードを配置してコンテナ image を build し Amazon EKS から利用できる コンテナレジストリー に push を行います。 $ tree . ├── app.py ├── Dockerfile ├── requirements.txt このブログでは Amazon ECR を利用した手順をご紹介します。 以下の手順では事前に Amazon ECR 上に llm-app というプライベートレジストリが作成が必要です。 # ご自身のAWSアカウントIDを設定 export AWS_ACCOUNT_ID=XXXXXXXXXXXX # 認証トークンを取得し、レジストリに対して Docker クライアントを認証 aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin ${AWS_ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com # Docker イメージを構築 docker build -t llm-app:sample . # リポジトリにイメージをプッシュできるように、イメージにタグ付けを行う docker tag llm-app:sample ${AWS_ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com/llm-app:sample # イメージをプッシュ docker push ${AWS_ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com/llm-app:sample Amazon EKS 上での実行 以下の manifest ファイルのようにしてアプリケーションを実行します。 この手順では sample-app という Namespace を作成し、 Service は type: LoadBalancer を利用してアプリケーションを公開します。 ※Amazon EKS でロードバランサーを取り扱う場合は AWS Load Balancer Controller の利用を推奨します Namespace の manifest ファイルの例 apiVersion: v1 kind: Namespace metadata: name: sample-app Deployment の manifest ファイルの例 ※ Deployment のコンテナイメージはご自身のコンテナレジストリのイメージに変更してください。 apiVersion: apps/v1 kind: Deployment metadata: labels: app: llm-app name: llm-app namespace: sample-app spec: replicas: 1 selector: matchLabels: app: llm-app template: metadata: labels: app: llm-app spec: containers: # ご自身のコンテナレジストリのイメージに変更してください - image: XXXXXXXXXXXX.dkr.ecr.ap-northeast-1.amazonaws.com/llm-app:sample name: sampleapp Service の manifest ファイルの例 apiVersion: v1 kind: Service metadata: name: llm-app-lb namespace: sample-app spec: type: LoadBalancer selector: app: llm-app ports: - protocol: TCP port: 80 targetPort: 8501 アプリケーションを実行すると以下のようなアプリケーションが実行されます。 しかしながら、 Amazon Bedrock への IAM ロール権限が無いため画面のように AccessDeniedException となるはずです。 アプリケーション へ Amazon Bedrock へのアクセス権限を追加する Amazon Bedrock へのアクセス権限を持つ IAM ロールを作成し、 Amazon EKS 上で実行されている Pod に IAM ロールの追加を行います。 Amazon Bedrock へのアクセス権限を持つ IAM ロールの作成 IAM ロールの作成からユースケースで EKS – Pod Identity を選択し、 AmazonBedrockFullAccess の許可ポリシーを追加したロールを作成します。 Amazon EKS Pod Identity を利用して IAM ロールと ServiceAccount のアソシエーションを行う 以下の manifest ファイルのようにして ServiceAccount を作成し、Amazon EKS Pod Identity を利用して IAM ロールと ServiceAccount のアソシエーションを行います。アソシエーションは AWS Management Console 、もしくは CLI を利用して行うことができます。 ServiceAccount の manifest ファイルの例 apiVersion: v1 kind: ServiceAccount metadata: name: bedrock-sa namespace: sample-app CLI を利用したアソシエーションの例 ※ —role-arn ではご自身で作成した IAM ロールの arn を指定してください。 # IAM ロールと ServiceAccount の association aws eks create-pod-identity-association \ --cluster-name <CLUSTER_NAME> \ --role-arn arn:aws:iam::XXXXXXXXXXXX:role/eks-pod-identity-bedrock \ --namespace sample-app \ --service-account bedrock-sa # association の確認 eksctl get podidentityassociation --cluster <CLUSTER_NAME> ASSOCIATION ARN NAMESPACE SERVICE ACCOUNT NAME IAM ROLE ARN arn:aws:eks:ap-northeast-1:XXXXXXXXXXXX:podidentityassociation/develop/a-zxckaesu4um17oi7e sample-app bedrock-sa arn:aws:iam::XXXXXXXXXXXX:role/eks-pod-identity-bedrock アプリケーションへ ServiceAccount を追加する IAM ロールと ServiceAccount のアソシエーションが完了したら、あとはアプリケーションが定義されている Pod へ ServiceAccount の追加を行うだけです。 Deployment に serviceAccountName を追加し、 先程の手順でIAM ロール とアソシエーションした ServiceAccount を指定します。 Deployment の manifest ファイルの例 apiVersion: apps/v1 kind: Deployment metadata: labels: app: llm-app name: llm-app namespace: sample-app spec: replicas: 1 selector: matchLabels: app: llm-app template: metadata: labels: app: llm-app spec: # serviceAccountName を追加 serviceAccountName: bedrock-sa containers: # ご自身のコンテナレジストリのイメージに変更してください - image: XXXXXXXXXXXX.dkr.ecr.ap-northeast-1.amazonaws.com/llm-app:sample name: sampleapp アプリケーションを更新すると以下の様に、Amazon Bedrock へのアクセス権限が追加されていることがわかります。 Amazon EKS Pod Identity の良さを感じて頂いたのではないでしょうか。 まとめ このブログでは、 Amazon EKS 上で動作するアプリケーションに対して、Amazon EKS Pod Identity を利用して Amazon Bedrock への IAM ロール 権限を追加する方法をご紹介しました Amazon EKS Pod Identity を利用して ServiceAccount との IAM ロールのアソシエーションを行うと、 ServiceAccount を Pod に指定するだけで、 IAM ロールベースのアクセス権限を簡単に付与することができます。 サービスアカウントの IAM ロール (IRSA) と比較すると、 IAM ロールに Amazon EKS クラスター毎に信頼ポリシーを更新する必要がなく、複数のクラスターから IAM ロールを簡単に再利用できます。また ServiceAccount にアノテーションを付与する必要がないためよりシンプルな構成にすることができます。 このブログが皆様の Amazon EKS を利用したビジネスにお役立ちできれば幸いです。 作者情報 ソリューションアーキテクト 瀧田 直斗 (Takita Naoto) 中堅中小企業様を中心に技術的な側面からお客様のビジネスを支援させて頂いております。