Amazon Managed Streaming for Apache Kafka (Amazon MSK) は、Apache Kafka を使用してストリーミングデータを処理するアプリケーションを構築・実行可能なフルマネージドサービスです。 本日、Amazon MSK は、新規の MSK プロビジョンドクラスター用に M7g インスタンスの提供を開始いたしました。これにより、Graviton3 のメリットを Kafka ワークロードにもたらせることをうれしく思います。 AWS Graviton プロセッサは、クラウドワークロードに最適なコストパフォーマンスを実現するために AWS が構築したカスタム ARM ベースのプロセッサです。たとえば、M7g.4xlarge インスタンスを使用して MSK プロビジョンドクラスターを実行すると、M5.4xlarge インスタンスと比較して CPU 使用量を最大 27% 削減し、書き込みと読み取りのスループットを最大 29% 向上させることができます。これらのパフォーマンス向上と、M7g の低いコストにより、M5 インスタンスに比べてコンピューティングコストを最大 24% 節約可能です。 2023 年 2 月に、AWS は Graviton3 ベースの新しい M7g インスタンスをローンチしました。M7g インスタンスには DDR5 メモリが搭載されており、前世代で使用されていた DDR4 メモリよりも最大で 50% 高いメモリ帯域幅を実現しています。また、M7g インスタンスは、同規模の M5 インスタンスと比べてストレージスループットが最大 25% 高く、ネットワークスループットが最大 88% 向上するため、Kafka ワークロードのコストパフォーマンス面でもメリットがあります。M7g の機能について詳しくは、 新しい Graviton3 ベースの汎用 (m7g) およびメモリ最適化 (r7g) Amazon EC2 インスタンス でご覧いただけます。 MSK における M7g インスタンスのスペックは以下のとおりです。 インスタンスタイプ vCPU メモリ ネットワーク帯域 ストレージ帯域 M7g.large 2 8 GiB 最大 12.5 Gbps 最大 10 Gbps M7g.xlarge 4 16 GiB 最大 12.5 Gbps 最大 10 Gbps M7g.2xlarge 8 32 GiB 最大 15 Gbps 最大 10 Gbps M7g.4xlarge 16 64 GiB 最大 15 Gbps 最大 10 Gbps M7g.8xlarge 32 128 GiB 15 Gbps 10 Gbps M7g.12xlarge 48 192 GiB 22.5 Gbps 15 Gbps M7g.16xlarge 64 256 GiB 30 Gbps 20 Gbps Amazon MSK における M7g インスタンス 組織は Amazon MSK を採用して、リアルタイムでのデータキャプチャと分析、機械学習 (ML) ワークフローの実行、イベント駆動型アーキテクチャの実装を行っています。Amazon MSK を使用すると、運用上のオーバーヘッドを削減し、より高い可用性と耐久性でアプリケーションを実行できます。また、 階層型ストレージ などの機能により、コストパフォーマンスが向上します。コンピューティングは Kafka におけるコストの大部分を占めるため、利用者はコンピューティングコストを更に最適化する手段を必要としており、Graviton インスタンスがその最短経路であることを理解していました。Amazon MSK チームは Kafka バージョン 2.8.2、3.3.2 以降で M7g の十分なテストを行い、重要なワークロードの実行が容易で、Graviton3 のコスト削減によるメリットを得られることを確認しました。 AWS マネジメントコンソール 、AWS SDK 経由での API 呼び出し、 AWS コマンドラインインターフェイス (AWS CLI) を使用して、ブローカータイプに Graviton3 ベースの M7g インスタンスを指定して、新しいクラスターをプロビジョニングすることができます。M7g インスタンスは Amazon MSK と Kafka のすべての機能をサポートしているため、既存の Kafka ワークロードを最小限の変更で簡単に実行できます。Amazon MSK は Graviton3 ベースの M7g インスタンスを large から 16xlarge サイズまでサポートし、すべての Kafka ワークロードを実行できます。 MSKプロビジョンドクラスター で M7g インスタンスを試して、Amazon MSK M5 インスタンスと比較してみましょう。 M7g インスタンス入門 利用者は Amazon MSK でさまざまなワークロードを実行しています。レイテンシーの影響を受けやすいものもあれば、スループットの制約を受けるものもあります。本投稿では、スループットの制約を受けるワークロードに対する M7g のパフォーマンスの影響に焦点を当てています。M7g はネットワークとストレージのスループットが向上しており、M5ベースのクラスターと比較してブローカーあたりのスループットが高くなっています。 その影響を理解するために、Kafka がデータの書き込みまたは読み取りに利用可能なスループットをどのように消費するかを見てみましょう。MSK クラスター内のすべてのブローカーには、制限付きのストレージとネットワークスループットが付与されています。Kafka の書き込みは主にストレージとネットワークスループットの両方を消費しますが、読み取りは主にネットワークスループットを消費します。通常、Kafka のコンシューマーはページキャッシュからリアルタイムデータを読み取り、時々古いデータを処理するためにディスクにアクセスするからです。したがって、全体的なスループットの向上度合は、ワークロードの書き込みと読み取りのスループット比率によって変化します。 例に基づき、スループットの向上度合を見てみましょう。今回のセットアップでは、M7g.4xlarge インスタンスを含む MSK クラスターと、3 つの異なるアベイラビリティーゾーンに 3 つのノードがある M5.4xlarge インスタンスを含むMSK クラスターが含まれています。また、M7g とM5 MSK クラスターの両方で、TLS 暗号化、 AWS Identity and Access Management (IAM) 認証を有効化し、レプリケーション係数を 3 にしました。また、ブローカー設定においては、 num.network.threads = 8 、 num.io.threads = 16 など、Amazon MSK のベストプラクティスを適用しました。書き込みクライアントでは、適切な linger.ms と batch.size 設定によりバッチサイズを最適化しました。ワークロードとしては、それぞれ 64 パーティションを持つ 6 つのトピック (ブローカーあたり384 パーティション) を想定しました。取り込みでは、平均メッセージサイズ 512 バイト、トピックごとに 1 つのコンシューマーグループで負荷を生成しました。クラスターにかけられた負荷の量は同一でした。 MSK クラスターに取り込むデータが増えるにつれて、次のグラフに示すように、M7g.4xlarge インスタンスはブローカーあたりのスループットが高くなります。1 時間の一貫した書き込みの後、M7g.4xlarge ブローカーは最大で54 MB/秒の書き込みスループットを維持しているのに対し、M5 ベースのブローカーでは 40 MB/秒です。これは 29％ の増加に相当します。 また、もう 1 つ重要な観測結果があります。M7g ベースのブローカーは、29％ 高いスループットを維持しているにもかかわらず、消費する CPU リソースは M5よりもずっと少ないのです。次の図に示すように、M7Gベースのブローカーの CPU 使用率は平均 40％ ですが、M5ベースのブローカーでは 47％ です。 先ほど説明したように、コンシューマーグループの数、バッチサイズ、インスタンスサイズによってパフォーマンスの向上度合が異なる場合があります。 MSK Sizing and Pricing を参照して、ユースケースに応じた M7g のパフォーマンスの向上度合を計算するか、M7g インスタンスベースのクラスターを作成し、ベンチマークを通してメリットを確認することをお勧めします。 コストを削減し、運用上の負担を軽減し、耐障害性を高める Amazon MSK はローンチ以来、全般的に耐障害性を向上させながら、Kafkaワークロードを費用対効果の高い方法で実行できるようにしてきました。ローンチ初日から、追加のネットワークコストを気にすることなく、複数のアベイラビリティーゾーンでブローカーを運用できるようになりました。私たちは、2022 年10 月に、 最大 50% のコストを削減しつつ実質的に無制限のストレージを提供する階層型ストレージをローンチしました。階層型ストレージを使用すると、全体的なストレージコストを節約できるだけでなく、クラスターの全般的な可用性と弾力性も向上します。 この道を歩み続けることで、私たちは現在もパフォーマンスを向上させながら、お客様のコンピューティングコストを削減しています。M7g インスタンスによって、Amazon MSK は同様のサイズの M5 インスタンスと比較してコンピューティングコストを 24％ 節約できます。Amazon MSK に移行することで、 Amazon MSK Connect 、 Amazon MSK Replicator 、Kafka の自動バージョンアップグレードなどの機能を使用して、運用上のオーバーヘッドを削減できるだけでなく、耐障害性を向上させ、インフラストラクチャコストを削減できます。 価格とリージョン Amazon MSK の M7g インスタンスは、現在、米国 (オハイオ、バージニア北部、北カリフォルニア、オレゴン) 、アジアパシフィック (ハイデラバード、ムンバイ、ソウル、シンガポール、シドニー、東京) 、カナダ (中部)、欧州 (アイルランド、ロンドン、スペイン、ストックホルム) リージョンでご利用いただけます。 Graivton3ベースのインスタンスとAmazon MSKの価格設定については、 Amazon MSK の料金表 を参照してください。 まとめ 本投稿では、Graviton ベースの M7g インスタンスを使用することで達成できたパフォーマンスの向上について説明しました。これらのインスタンスは、Amazon MSK ワークロードにおける同サイズの M5 インスタンスと比較して、読み取りと書き込みのスループットを大幅に向上させることができます。まずは、 AWS マネジメントコンソール を使用して、 M7g ブローカーで新しいクラスターを作成しましょう。詳細については、ドキュメントをご確認ください。 著者について Sai Maddali は AWS の製品管理担当シニアマネージャーで、Amazon MSK の製品チームを率いています。彼は顧客のニーズを理解し、テクノロジーを使って顧客が革新的なアプリケーションを構築できるようにするサービスを提供することに情熱を注いでいます。仕事以外にも、旅行、料理、ランニングを楽しんでいます。 Umesh は AWS のストリーミングソリューションアーキテクトです。彼は AWS の顧客と協力して、リアルタイムのデータ処理システムを設計および構築しています。彼は、データ分析システムの設計、設計、開発を含むソフトウェアエンジニアリングで13年の実務経験があります。 Lanre Afod は、AWS のグローバル金融サービスに焦点を当てたソリューションアーキテクトです。お客様が、安全に、スケーラブルで、可用性が高く、回復力のあるアーキテクチャを AWS クラウド内にデプロイできるよう支援することに情熱を注いでいます。 翻訳はソリューションアーキテクトの榎本が担当いたしました。原文は こちら です。

最も広く使用されているクラウドデータウェアハウスである Amazon Redshift は、最も要求の厳しいワークロードのパフォーマンス要件を満たすために大幅に進化しました。 この記事では、その新機能の 1 つである多次元データレイアウトソートキーについて説明します。 Amazon Redshift は、多次元データレイアウトソートキーをサポートすることでクエリのパフォーマンスを向上させました。多次元データレイアウトソートキーは、テーブルの物理的なカラムではなくフィルター述語でテーブルのデータをソートする新しいタイプのソートキーです。 多次元データレイアウトソートキーは、特にクエリワークロードに反復スキャンフィルターが含まれている場合に、テーブルスキャンのパフォーマンスを大幅に向上させます。 Amazon Redshift にはすでに 自動テーブル最適化 (ATO) 機能が用意されており、管理者の介入なしにソートキーと分散キーを適用してテーブルの設計を自動的に最適化します。 この投稿では、 ATO が提供する追加機能として、Amazon Redshift のソートキーアドバイザーアルゴリズムによって強化された多次元データレイアウトソートキーを紹介します。 多次元データレイアウトソートキー AUTO ソートキーを使用してテーブルを定義すると、Amazon Redshift ATO はクエリ履歴を分析し、ワークロードに適したオプションに基づいて、テーブルの単一カラムのソートキーまたは多次元データレイアウトソートキーを自動的に選択します。 多次元データレイアウトを選択すると、Amazon Redshift は、通常同じクエリでアクセスされる行を同じ場所に配置する多次元ソート関数を構築し、その後、クエリ実行中にソート機能を使用してデータブロックをスキップしたり、個々の述語カラムのスキャンをスキップしたりします。 次のユーザークエリを考えてみましょう。これは、ユーザーのワークロードの主なクエリパターンです。 SELECT season , sum ( metric2 ) AS "__measure__0" FROM titles WHERE lower ( subregion ) like '%United States%' GROUP BY 1 ORDER BY 1 ; SQL Amazon Redshift は、各カラムのデータを 1 MB のディスクブロックに格納し、テーブルのメタデータの一部として各ブロックの最小値と最大値を格納します。 クエリで 範囲が制限された述語 を使用する場合、Amazon Redshift は最小値と最大値を使用して、テーブルスキャン中に大量のブロックをすばやくスキップできます。 ただし、このクエリの subregion カラムのフィルターでは、最小値と最大値に基づいてスキップするブロックを決定することはできません。その結果、Amazon Redshift は titles テーブルのすべての行をスキャンします。 SELECT table_name , input_rows , step_attribute FROM sys_query_detail WHERE query_id = 123456789 ; SQL subregion を使用したシングルカラムのソートキーを使用し、 titles テーブルを指定してユーザーのクエリを実行した場合、前述のクエリの結果は次のようになります。 table_name | input_rows | step_attribute -------------+------------+--------------- titles | 2164081640 | ( 1 rows ) SQL これは、テーブルスキャンが 2,164,081,640 行を読み取ったことを示しています。 titles テーブルのスキャンを改善するために、Amazon Redshift は多次元データレイアウトソートキーの使用を自動的に決定する場合があります。 述語 lower(subregion) like '%United States%' を満たす行はテーブルの専用の領域に全て配置されるため、Amazon Redshift は述語を満たすデータブロックのみをスキャンします。 述語 lower(subregion) like '%United States%' を含む多次元データレイアウトソートキーを使用して titles テーブルを指定してユーザーのクエリを実行すると、 sys_query_detail クエリーの結果は次のようになります。 table_name | input_rows | step_attribute -------------+------------+--------------- titles | 152324046 | multi - dimensional ( 1 rows ) SQL これは、テーブルスキャンが元のデータの 7% に過ぎない 152,324,046 行を読み取り、多次元データレイアウトソートキーを使用したことを示しています。 この例では 1 つのクエリを使用して多次元データレイアウト機能を紹介していますが、Amazon Redshift はテーブルに対して実行されるすべてのクエリを考慮し、最も一般的に実行される述語を満たす複数の領域を作成できることに注意してください。 今度は、より複雑な述語と複数のクエリを使った別の例を見てみましょう。 次の例に示すように、4 つの行を持つテーブル items (cost int, available int, demand int) があるとします。 #id cost available demand 1 4 3 3 2 2 23 6 3 5 4 5 4 1 1 2 主なワークロードは、次の 2 つのクエリで構成されています。 70% のクエリパターン: select * from items where cost > 3 and available < demand SQL 20% のクエリパターン: select avg ( cost ) from items where available < demand SQL 従来のソート方法では、 cost カラムに対してテーブルを並べ替える方法を選び、 cost > 3 の評価式に対してこのソートのメリットが得られるようにすることができます。 そのため、単一の cost カラムを使用してソートした後のテーブルのアイテムは次のようになります。 #id cost available demand Region #1, with cost <= 3 Region #2, with cost > 3 #id cost available demand 4 1 1 2 2 2 23 6 1 4 3 3 3 5 4 5 この従来のソートを使用すると、ID が 4 と 2 の上位 2 行 (青色の行) は、 cost > 3 を満たさないため、すぐに除外できます。 一方、多次元データレイアウトソートキーでは、ユーザーのワークロードでよく発生する2つの述語（ cost > 3 、 available < demand ）の組み合わせに基づいてテーブルがソートされます。 その結果、テーブルの行は 4 つの領域へソートされます。 #id cost available demand Region #1, with cost <= 3 and available < demand Region #2, with cost <= 3 and available >= demand Region #3, with cost > 3 and available < demand Region #4, with cost > 3 and available >= demand #id cost available demand 4 1 1 2 2 2 23 6 3 5 4 5 1 4 3 3 この概念は、単一の行ではなくブロック全体に適用したり、従来のソート手法には適さない演算子( like など) を使用する複雑な述語に適用したり、3 つ以上の述語に適用したりすると、さらに強力になります。 システムテーブル 次の Amazon Redshift のシステムテーブルは、テーブルとクエリで多次元データレイアウトが使用されているかどうかをユーザーに示します。 特定のテーブルが多次元データレイアウトソートキーを使用しているかどうかを判断するには、 svv_table_info の sortkey1 が AUTO (SORTKEY (padb_internal_mddl_key_col)) と等しいかどうかを確認できます。 特定のクエリが多次元データレイアウトを使用してテーブルスキャンを高速化しているかどうかを判断するには、 sys_query_detail ビューの step_attribute をチェックします。 スキャン中にテーブルの多次元データレイアウトソートキーが使用された場合、値は multi-dimensional になります。 パフォーマンスベンチマーク 反復スキャンフィルターを使用して複数のワークロードについて内部でベンチマークテストを実施し、多次元データレイアウトソートキーを導入すると次の結果が得られることを確認しました。 ソートキーがない場合と比較して、実行時間が合計で 74% 短縮されました。 各テーブルに最適なシングルカラムのソートキーを使用する場合と比較して、実行時間が合計で 40% 短縮されました。 ソートキーがない場合と比較して、テーブルから読み取られる合計の行数が 80% 減少しました。 各テーブルに最適なシングルカラムのソートキーを使用した場合と比較して、テーブルから読み取られる合計の行数が 47% 減少しました。 機能比較 多次元データレイアウトソートキーが導入されたことで、ワークロードでよく発生するフィルター述語に基づいた式でテーブルをソートできるようになりました。 次の表は、Amazon Redshift の機能を 2 つの他社製品と比較したものです。 機能 Amazon Redshift 製品 A 製品 B カラムに基づくソート Yes Yes Yes 式に基づくソート Yes Yes No ソート用のカラムの自動選択 Yes No Yes ソート用の式の自動選択 Yes No No カラムに基づくソートか、式に基づくソートかの自動選択 Yes No No スキャン中の式に対するソートプロパティの自動使用 Yes No No 考慮事項 多次元データレイアウトを使用するときは、次の点に注意してください。 テーブルを SORTKEY AUTO に設定すると、多次元データレイアウトが有効になります。 Amazon Redshift Advisor は、過去のワークロードを分析することにより、テーブルのシングルカラムのソートキーまたは多次元データレイアウトを自動的に選択します。 Amazon Redshift ATO は、進行中のクエリのワークロードとの相互作用に基づいて、多次元データレイアウトソート結果を調整します。 Amazon Redshift ATO は、既存のソートキーと同じ方法で多次元データレイアウトソートキーを管理します。 ATOの詳細については、 自動テーブル最適化の使用 を参照してください。 多次元データレイアウトソートキーは、プロビジョニングされたクラスターとサーバーレスワークグループの両方で機能します。 テーブルで AUTO SORTKEY が有効になっていて、スキャンフィルターが繰り返し使用されることが検出されたら、多次元データレイアウトソートキーは既存のデータで使用されます。 多次元ソート機能の結果に基づいてテーブルが再構成されます。 テーブルの多次元データレイアウトソートキーを無効にするには、 ALTER TABLE table_name ALTER SORTKEY NONE を使用してください。 これにより、テーブルの AUTO ソートキー機能が無効になります。 プロビジョニングされたクラスターをサーバーレスクラスターに復元または移行するとき、またはその逆の場合でも、多次元データレイアウトソートキーは保持されます。 まとめ この投稿では、多次元データレイアウトソートキーを使用すると、主要なクエリに反復スキャンフィルターがあるワークロードのクエリ実行時のパフォーマンスが大幅に向上することを示しました。 Amazon Redshift コンソールからプレビュークラスターを作成するには、 クラスター ページに移動し、 Create preview cluster を選択します。 米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、ヨーロッパ (アイルランド)、ヨーロッパ (ストックホルム) の各リージョンにクラスターを作成し、ワークロードをテストできます。 この新機能に関するフィードバックをお待ちしています。 著者について Yanzhu Ji は Amazon Redshift チームのプロダクトマネージャーです。 彼女は、業界をリードするデータ製品およびプラットフォームにおける製品ビジョンと戦略の経験があります。 彼女は、ウェブ開発、システム設計、データベース、および分散プログラミング技術を使用して、価値あるソフトウェア製品を構築する優れたスキルを持っています。 私生活では、Yanzhu は絵を描いたり、写真を撮ったり、テニスをしたりするのが好きです。 Milind Oke はニューヨークを拠点とするデータウェアハウススペシャリストソリューションアーキテクトです。 彼は 15 年以上にわたってデータウェアハウスソリューションを構築しており、Amazon Redshift を専門としています。 Jialin Ding は Learning Systems Group の Applied Scientist で、機械学習と最適化の手法を適用して Amazon Redshift などのデータシステムのパフォーマンスを向上させることを専門としています。 翻訳はソリューションアーキテクトの小役丸が担当しました。原文は こちら です。

国立研究開発法人 新エネルギー・産業技術総合開発機構 （以下、NEDO）とアマゾン ウェブ サービス ジャパン（以下、AWS）は 2023 年 10 月 26 日に、「Deeptech | AWS : NEDO 助成金と AWS の活用セッション」を AWS Startup Loft Tokyo にて共同開催しました。 NEDO は「エネルギー・地球環境問題の解決」と「産業技術力の強化」をミッションに、イノベーション・アクセラレーターとして産学官の強みを結集した体制構築や運営、評価、資金配分などによって技術開発を推進してきました。そして、その成果の社会実装を促進することで、社会課題の解決を目指しています。 本イベントでは NEDO のスタートアップ支援事業に採択された事業者の経験談や、ディープテック分野における NEDO のスタートアップ支援事業全般についてのご紹介をしました。ここではそのレポートをお届けします。 オープニング AWS パブリックセクター 事業開発マネージャー（Startup） 田村 圭 イベント冒頭では、AWS パブリックセクター 事業開発マネージャー（Startup）の田村 圭が、オープニングのあいさつをしました。 岸田内閣は 2022 年 11 月に「スタートアップ育成 5 か年計画」を発表しました。これは、スタートアップへの投資額を 2027 年度に 10 兆円規模とし、スタートアップを 10 万社、ユニコーンを 100 社創出するという目標です。融資制度や税制優遇、補助金など幅広い政策で援助する内容となっており、すでに 1 兆円規模の予算が計上されています。 「この施策により、本イベントのテーマであるディープテックを扱うスタートアップにも、多額の支援が行われます。そうしたスタートアップが活躍することで、この先の日本経済の成長にもつながると考えております」と田村は述べました。 ディープテックとは、革新的な技術を用いて社会的な課題を解決する取り組みのことを指します。そうした技術は、設備や研究への投資に多額の資金が必要であったり、製品化を実現するまでに長い歳月がかかったりするという課題があります。だからこそ、NEDO の助成事業を活用することには大きな意義があるのです。 「まだ NEDO の助成事業についてそれほど詳しくない方もいらっしゃると思いますので、今回のイベントで NEDO についてぜひ知っていただきたいです。また、研究開発型スタートアップが AWS をどのように活用すればいいのかも、把握していただきたいと考えております」と田村は結びました。 ディープテックスタートアップ・パネルディスカッション ＜スピーカー＞ FRAIM株式会社 取締役 CTO 宮坂 豪 氏（写真左） WOTA株式会社 インキュベーション責任者 山田 諒 氏（写真右） ＜モデレーター＞ アマゾン ウェブ サービス ジャパン スタートアップ事業本部 福井 健悟 ここからは、NEDO の助成事業を活用したスタートアップとして、FRAIM 社の宮坂 氏と WOTA 社の山田 氏がスピーカーとして登壇。AWS の福井をモデレーターとして、NEDO 活用の経験談を語りました。 FRAIM 社 は「文書作成を、再発明する。」をミッションとして、AI などの最新技術を用いて文書作成を「しくみ」ごと変えることを目指し、クラウド ドキュメント ワークスペース「LAWGUE」や関連技術ソリューションの研究・開発・提供を行っています。 FRAIM 社は NEDO が実施する「研究開発型スタートアップ支援事業／Product Commercialization Alliance（以下、PCA事業）」に、2022年度に採択されました。PCA 事業とは、提案時から 3 年ほどで継続的な売り上げを立てる具体的計画がある研究開発型スタートアップを対象とし、審査を行った上で最大 2.5 億円（助成率2/3）の助成を行うものです。 採択されたのは「LAWGUE」の基幹を支えるクラウド型エディタ技術をベースとした「規制改訂等に伴う影響文書の自動特定および修正支援技術の実用化」というテーマです。 また、 WOTA 社 は「水問題を構造からとらえ、解決に挑む。」を存在意義とし、独自の技術・ソリューションにより「水問題」という社会課題に正面から向き合っています。生活排水を再生し最大限有効活用する「小規模分散型水循環システム」およびそれを実現する「水処理自律制御技術」を開発しているのです。 WOTA 社も FRAIM 社と同様に、2022 年度に PCA事業で採択されました。採択されたのは、住宅規模の全排水再生循環利用に対応した小規模分散型水循環システムを、そのプロダクト化に向けて異なる場面や環境条件で実証し、性能・信頼性を検証する「小規模分散型水循環システム実証事業」です。加えて、WOTA 社は 2023 年度に、「ディープテック・スタートアップ支援基金／ディープテック・スタートアップ支援事業」のDMPフェーズにも採択されています。 セッションでは、両社が NEDO の支援を受けようと思った理由やディープテック・スタートアップが AWS を活用する利点、AWS に期待すること、NEDO の各種公募に応募する際の心構えや Tips などが語られました。 FRAIM 社は PCA 事業の公募で一度は不採択となり、2 回目の挑戦で採択されたといいます。その経緯について、宮坂 氏は「エンジニアを増員して開発速度を向上させたかったですし、インフラの費用も今後大きくなることが見えていました。だからこそ諦められませんでしたね。NEDO の助成金は金額が大きく、スタートアップにとって魅力的です」と話しました。 また、山田 氏は AWS の利用について「多種多様なサービスが用意されているため、ディープテック・スタートアップにとっても便利に活用できます。さらに、AWSの利用クレジットをご提供いただき、運用サポートも受けられるので、多くの利点がございました」と推奨しました。 これから NEDO の助成金を申請する企業に向けて、宮坂 氏は「採択前・採択後にどのような書類を作成する必要があるのかあらかじめ調べておくとよい」と説明。山田 氏は「申請時は、自社の事業の社会的な意義や研究開発した内容を事業化する方法などを申請書類に適切に記載してほしい」と述べました。 NEDO 公募説明会 ここからは、NEDO のイノベーション推進部に所属する方々が登壇。NEDO の概要やディープテック分野におけるスタートアップ支援の内容、申請方法などを解説しました。まずは NEDO イノベーション推進部 総括グループの村井 繁樹 氏が NEDO の支援内容について「ディープテック分野での人材発掘・起業家育成事業（以下、NEP事業）」を中心に説明しました。 NEDO イノベーション推進部 総括グループ 村井 繁樹 氏 NEP 事業は、NEDO が行う起業前後の方々を対象としたスタートアップ支援事業です。本事業は「開拓コース」と「躍進コース」の 2 つに分かれています。躍進コースにおいては、応募要件や支援内容に応じて「躍進 A」「躍進 B」「躍進 C」の 3 タイプを設けています。 開拓コースの対象となるのは、起業前の個人（チームでも可）。活動内容としては、自ら起業することも視野に入れながら、技術シーズを活用したアイデアの実現可能性に関する調査を行うこと。活動費としては月額 30 万円（税込）上限 300 万円までとなります。この費用は調査活動において自らが必要と判断した経費に使用でき、事業期間は NEDO が指定する日から 10 カ月程度です。 一方の躍進コースでは、「躍進 A」の助成対象は個人・チーム。「躍進 B」「躍進 C」は法人が助成対象（応募時が個人の場合、交付決定後に法人化する必要あり）です。活動内容としては、事業可能性の調査や、事業化促進に向けた研究開発や実証を行うこと。助成金額は「躍進 A」「躍進 B」が 500 万円未満であり「躍進 C」が 3,000 万円以内です。事業期間は 12 カ月以内となります。 ●詳細は、本年度のNEP事業公募ページを参考としてご確認下さい。 ※尚、来年度は変更になる可能性があることを予めご了承下さい。 NEP事業公募ページ（2023年度）： https://www.nedo.go.jp/koubo/CA2_100393.html　 セッション内では NEP 事業の各コースの概要説明や実施体制の全体フロー、審査の方法、公募情報の見つけ方、応募の手順や各種参考情報などが網羅的に語られました。 NEDO イノベーション推進部 総括グループ 奥田 洋子 氏 村井 氏の次に登壇したのは、NEDO イノベーション推進部 総括グループの奥田 洋子 氏。 NEDO の支援内容について「ディープテック・スタートアップ支援基金／ディープテック・スタートアップ支援事業（以下、DTSU事業）」を中心に説明しました。 前述の通り、日本政府は「スタートアップ育成 5 か年計画」を掲げています。その施策の柱として「スタートアップへの資金供給の強化と出口戦略の多様化」が存在しているのです。その流れを受けて、NEDO によるディープテック・スタートアップへの支援策の強化のために、DTSU 事業が 2023 年度に開始されました。 ディープテックは、事業化や社会実装を実現すれば世界規模の課題を解決できるというような、社会にインパクトを与える価値を持ちます。一方で、そうした技術は研究開発の成果獲得や事業化・社会実装までに長期間を要する上に多額の資金も不可欠です。さらに既存のビジネスモデルを適用しにくいという特徴があります。そのため、国による支援の必要性が高いのです。 DTSU 事業では、ディープテック・スタートアップが行う研究開発や試作品の開発、量産化のための実証等に加え、市場獲得に向けた事業化可能性調査等に対する支援を行います。STSフェーズ（実用化研究開発（前期））、PCAフェーズ（実用化研究開発（後期））、DMPフェーズ（量産化実証）の3つのフェーズを設けており、事業の進捗度に適合した支援を行います。また、ステージゲート審査を経ることで、複数フェーズでの中長期的な支援を行います。 これらの支援の実施にあたっては、スタートアップの資金調達スパンに応じた支援とするべく、VC等やCVC、事業会社、金融機関から、所定の期間内に、助成対象費用の一定割合以上の出資又は融資を受けることを必須の要件としています。 助成金額上限は、 STSフェーズ が 3億円又は5億円、PCA フェーズが 5 億円又は10 億円、DMP フェーズが 25 億円となり、複数フェーズを跨ぐ場合も 30 億円としています。また、事業期間は次の資金調達の時期を目安に設定することとし、同一フェーズ内で4年まで、複数フェーズを跨ぐ場合も6年までとしています。 ●詳細は、DTSU事業公募ページをご確認下さい。5年間の通年公募を行っていますが、年4回程度の提案受付機会を設けており、当該機会ごとに公募ページが異なり、公募内容も変わりうる点にご留意ください。 ※DTSU事業公募ページ（2023年度第3回の例）： https://www.nedo.go.jp/koubo/CA2_100429.html セッション内では各事業の支援対象者や対象分野、事業の流れ、経費計上に関する留意事項、提出資料の内容などが語られました。 （※NEDOの助成事業に関する情報は諸事情等により変更が生じる可能性がございます。） AWS パブリックセクターは今後も、ディープテック・スタートアップがイノベーションを加速させるための、さまざまなテクニカル・ビジネスセッションやコミュニティ活動を実施予定です。ご関心を持たれた方は、ぜひお気軽にこちらまでお問い合わせください。社会課題解決イノベーションに取り組まれる、スタートアップや研究者のみなさまのご参加をお待ちしております！ このブログは、アマゾンウェブサービスジャパン合同会社 パブリックセクター 事業開発マネージャー（ Startup ）である 田村 圭 が執筆しました。

あらゆる業界のお客様が、エンタープライズリソースプランニング (ERP)、注文管理システム (OMS)、エンタープライズデータウェアハウス (EDW) などの自律分散システムを長期に渡り活用し、サプライチェーンと運用データを保存しています。 これらのシステムは基本的な機能を十分に果たしていますが、サプライチェーンのデータはこれらの別々のデータ提供元となるシステムに閉じ込められたままです。 これらのシステムの基盤となるデータモデルと定義はさまざまであるため、ビジネスアプリケーションやレポートに利用するためにデータの標準化や変換を困難にしています。一方、これらのシステムに標準化されていないデータが存在すると、データ管理者やビジネスアナリストが、レポートや計画などのビジネスニーズに合わせてデータを変換または標準化するために費やす時間が長くなります。 このような状況は、組織が統一され標準化されたデータを用いて最適化された機械学習（ML）を活用した機能や運用を活用することを妨げています。 当社のお客様からは、複雑で抽出、変換、読み込み (ETL) 機能のために、サイロ化されたデータと手動の統合が、業務に支障をきたす事例が共有されています。 このブログ記事では、AWS サービスを使用して標準化されていないデータを変換し、ETL 操作を簡素化する簡単な方法を紹介します。 この記事では、 AWS Supply Chain にデータを送る自動パイプラインの設定プロセスについても説明します。 AWS Supply Chain は、既存の ERP およびサプライチェーン管理システムと連携するクラウドベースのサプライチェーン管理アプリケーションです。 AWS Supply Chain は、一連のインタラクティブなビジュアルインターフェイスを使用して、データをリアルタイムのビジュアルマップでコンテキスト化します。 現在の在庫選択と数量、および各拠点の在庫状況の健全性 (たとえば、在庫切れの恐れがある在庫) が強調表示されます。 また、AWS Supply Chain では、より正確なベンダーのリードタイムを生成し、リスクを軽減するための機械学習を活用した実用的な洞察を提供します。 ソシューション概要 データ変換ソリューションでは、 Amazon Simple Storage Service (Amazon S3) 、 AWS Glue クローラー、 AWS Glue DataBrew 、および AWS Supply Chain を使用しています。 次の参照図は、これらのサービスの統合を示しています。 オンプレミスデータソース – このブロックは、お客様のオンプレミスにある古いデータソースをすべてキャプチャします。 Amazon S3 raw data sink – これらの Amazon S3 バケットは、ソースシステムから未加工の (変更されていない) データを受信することを目的としています。 今回の設定では、カンマで区切られた値 (.csv) のファイルをアップロードします。 AWS Glue クローラー – AWS Glue クローラーは、Amazon S3 バケット内のファイルをクロールし、ファイルに存在する基礎となるスキーマを学習するように設計されています。 このスキーマにより、顧客は通常、手動のスキーママッピングに費やされる時間を削減できます。 また、AWS Glue クローラーには、クロールジョブの実行頻度を設定するオプションが組み込まれています。 このサービスの出力は、データソースのスキーマとテーブルの定義です。 AWS Glue DataBrew – このツールは、お客様に次のような機能を提供するビジュアル ETL ツールを提供します。 テーブルスキーマのビュー データリネージを把握して変化の流れを把握できる ソースフィールドの変更方法を管理するためのマッピングおよび変換機能 Amazon S3 で変換されたデータ – Amazon S3 のストレージロケーションには、更新データと標準化されたデータが格納されます。 これは、ビジネスアプリケーションまたは任意のレポートツールに直接接続できます。 AWS Supply Chain – このエンドユーザー向けビジネスアプリケーションは、回復力のあるサプライチェーンの運営に役立つ洞察を生成するためにML アルゴリズムを利用しています。 前提条件 このブログ記事では、前述のサービスの使用方法を理解し、次の条件を満たしていることを前提としています。 記載されているサービスが有効になっている AWS アカウント AWS Identity and Access Management (IAM) ロールを作成および変更できること。 これはポリシーと権限 (特に AWS Glue に関連するサービス) を作成するために必要です。 データの提供元とのなるシステムへのアクセスとこれらのシステムからCSVファイルを抽出できること。 ソリューションの範囲と前提条件 このブログ記事では、いくつかの前提条件を設けています。 データの提供元とのなるシステムから CSV ファイルを抽出し、Amazon S3 バケットにアップロードするプロセスは除外しています。 ソースファイルは Amazon S3 バケットに手動でアップロードされます。 ただし、どのプロセスを使用しても、Amazon S3 バケットにロードできます。 受信するファイルの形式は、値がカンマで区切られていると想定されます。 クロールワークフローはオンデマンドで実行されるように設定されています。 ただし、この記事では、異なる頻度でワークフローを構成する方法についても説明します。 スキーマに変更があった場合、現在のソリューションを拡張して、スキーマの変更やそれに関連するデータフローへの影響をユーザーに通知することができます。 この設計拡張の詳細については、AWS ブログ記事「 AWS Glue を使用してソーススキーマの変更点の特定 」を参照してください。 . ソリューションの各要素 管理者として AWS マネジメントコンソール にサインインします。 検索ボックスを使用して Amazon S3 を 検索 してください。 Amazon S3 バケット Amazon S3 バケットを作成するには、 バケットを作成 を選択し、画面上の手順に従います。 この設定では、デフォルトオプションを変更しないでください。 これにより、追加されるすべてのファイルについて、Amazon S3 バケット内のコンテンツの変更が確実にスキャンされます。 ソースシステムから抽出した未加工のファイルを Amazon S3 バケットにアップロードすることで、データを取り込むことができます。 AWS Glue crawler コンソールの上部にある検索ボックスを使用して AWS Glue に移動します。 左側のナビゲーションバーで Databases, を選択し、 Create database を選択します。 左側のナビゲーションバーで Clawlers を選択し、 Create crawler を選択します。 Name フィールドと Description フィールドに、追加するエンティティに基づいた値を入力します。 次のスクリーンショットでは、Product エンティティのクローラーが作成されています。 次に Next を選択します。 次の画面で、データソースを追加するように求められます。 ここで Amazon S3 のロケーションを参照します。 このクローラージョブをいつ開始するかのスケジュールを選択できます。 このウォークスルーではオンデマンドが選択されています。 要件に基づいて設定を変更できます。 次に Next を選択します。 次の画面で、完了した選択内容を確認して Create crawler ボタンをクリックできます。 作成したクローラーを選択して Run ボタンを押して実行してください。 左側のナビゲーションバーの Databases をクリックし、 Tables を選択すると、作成されたテーブルのリストが表示されます。 AWS Glue Databrew 検索ボックスで AWS Glue Databrew を検索します。 左側のナビゲーションペインで、 データセット を選択します。 このステップでは、AWS Glue クローラーを使用して作成したデータセットの新しい接続を作成します。 以前に定義したすべてのテーブルについて、下記の手順を繰り返します。 AWS Glue DataBrew 画面の プロジェクトを作成 ボタンをクリックして、新しいデータプロジェクトを開始します。 プロジェクトを作成 画面で、プロジェクト名を入力し、以前に作成されたデータセットを選択してこの手順を完了します。 例として、 Outbound OrderLine データセットは以下のプロジェクトの作成に使用されます。 GitHub Repository: 列名の変更など、スキーマ変換ステップはすべてレシピファイルを使用して実行できます。 この GitHub の ロケーション にある JSON レシピファイルを参照できます。 たとえば、 Outbound OrderLine テーブルでは、列名の変更のみが必要です。 これらのレシピをローカルマシンにダウンロードして、参照または使用することができます。 Databrew ウィンドウに戻り、 レシピ を選択します。 レシピ (GitHub ステップまたは独自のバージョンからダウンロードしたもの) を Databrew ウィンドウにアップロードするには、右隅にある レシピをアップロード を選択します。 AWS Glue Databrew – Visual Transformation [オプション] AWS Glue DataBrew では、受信データを視覚的に変更または変更することができます。 これには、フォーマット、列名、列操作の変更が含まれます。 新しいプロジェクトを作成するには、 プロジェクト に移動し、 新規プロジェクト を選択します。 この例では、 InventoryPositions を使用します。 右上隅にあるレシピオプションを使用して、変換手順を追加できます。 次の例は、既存のデータの列名の変更を示しています。 フィールド変換の一例として、標準日付を UTC 形式に変更することが挙げられます。 この変更を行うには、 ステップを追加 を選択します。 レシピがアップロードされたら、 ジョブ に移動して変換を自動化するジョブを作成します。 ジョブを作成 を選択します。 ジョブの詳細画面で、レシピジョブを選択します。 次に、データセットの下で、新しいジョブを定義したいデータセットを関連付けます。 AWS Glue Databrew サービスでは、データを抽出する形式を柔軟に選択できます (この例では、値をカンマで区切った形式を使用します)。 関連付けられたスケジュール [オプション] : 追加の手順として、ジョブのスケジューリングを設定できます。 権限を含む必須フィールドをすべて入力したら、 ジョブを作成 を選択します。 ジョブが作成されたら、スケジュールに従ってジョブを実行するのを待つか、手動で実行することができます。 ジョブが正常に実行されると、変換された CSV ファイルが Amazon S3 の場所で利用可能になるはずです。 まとめ ERP や WMS などのレガシーで断片化されたデータシステムに存在する非標準化データは、レポートや計画などのビジネスニーズに合わせてデータを標準化するのに必要な時間と労力を増大させます。 サプライチェーン管理システム間の統合は困難かつ複雑で、非常に時間がかかる場合があり、組織は単一ベンダーまたは非常に高価な統合サービスの使用を強いることがあります。 このウォークスルーでは、AWS サービスを使用して正規化されたデータロードプロセスを自動化するデータ変換アプローチについて説明しました。 このアプローチは、貴重なサプライチェーンデータを引き出すのに役立ち、より迅速な意思決定と効率性の向上を可能にします。 このブログでは、AWS Supply Chain についても簡単に触れていますが、これはサプライチェーンの可視性を高め、サプライチェーンの回復力を向上を可能にします。 詳細と始め方については AWS Supply Chain にアクセスしてください。技術概要については自分のペースで進められる AWS ワークショップ をご覧ください。 本ブログはソリューションアーキテクトの水野 貴博が翻訳し画面も日本語の最新のものを使用しました。原文は こちら 。 著者について Vikram Balasubramanianは、サプライチェーンのシニア・ソリューション・アーキテクトです。Vikramは、サプライチェーンの経営幹部と緊密に連携して、彼らの目標や問題点を理解し、解決策の観点からベストプラクティスと連携させています。Vikramは17年以上にわたり、サプライチェーン分野のさまざまな業種のフォーチュン500企業で働いてきました。Vikramは、パデュー大学でインダストリアルエンジニアリングの修士号を取得しています。ヴィクラムはノースダラス地域を拠点としています。 <!-- '"` -->

まえがき みなさん、こんにちは。カスタマーソリューションマネージャー (CSM) の上原です。クラウド導入を検討されているお客様のクラウドジャーニー全般を支援する活動をしています。本ブログは、現状オンプレミス上で多くの IT 資産が稼働しており、AWS への移行を検討しているお客様向けに作成しています。 前編 ではクラウド移行の 4 つのフェーズの中でAssess (評価) フェーズに着眼し、頻出課題の 1 つ目 「クラウド移行のビジネスメリットが分からない」に関して、課題の深堀りと解決策についてお話しました。 今回は後編として、同じく Assess (評価) フェーズにおけるもう 1 つの頻出課題「ベンダー依存で移行対象システムが未選定、準備状況も把握できない」について、AWSが提供するプログラムを交えながらお話していきます。 AWSのクラウド移行およびクラウド活用の道のりについては、「 クラウドジャーニーの歩み方 (前編) 」でも紹介していますので、併せてご参照ください。 まずはクラウド移行を阻害する 10 のハードルに関して振り返ってみましょう。 クラウド移行を阻害する 10 のハードル クラウド移行には、4 つのフェーズがあります。Assess (評価) から始まり、移行に向けた課題に取り組む Mobilize (移行準備) 、そして実際の Migration (移行) フェーズへと進みます。さらに、クラウド利用によるビジネス価値をより高める取り組みをModernization (最適化) で実行する流れとなります。それら各フェーズで AWS がご支援する中で、多くのお客様で共通するハードルがあることがわかっています。詳細は下図、「クラウド移行を阻害する 10 のハードル」 をご参照下さい。 本 ブログ は、最初の取り組みとなる Assess (評価) フェーズにおける課題と解決策についての後編 (前編は こちら ) として、ベンダー依存というキーワードに注目してお話していきます。 Assess (評価) フェーズでの課題 後編 「２．ベンダー依存で移行対象システムが未選定、移行準備状況も把握できていない」 １．移行対象システムが不明確 (優先度、手順、インパクト) 特に大きな企業では、膨大な IT 資産の維持・管理といった煩雑で工数がかかる作業をお任せできる、また融通が利きテクニカルな相談にも乗ってくれる IT ベンダーの存在は、多くのメリットがあります。実装や運用だけでなく、ビジネス自体を円滑に進めるためにも、その存在が不可欠となっている企業も多くあると思います。 ただし、あまりにも IT ベンダーに依存しすぎている状態では、費用や品質面だけでなく、企業として新たな取り組みを検討、実行する際に問題を生む可能性があります。企業全体でスピード感をもって推進することが求められるクラウド移行も、例外ではありません。 例えば、業務システムごとなど複数のベンダーを抱えているケースでは、全体のアセット情報を自社で一元管理することが難しく、そもそも移行を検討する対象システムが特定できない、コスト試算や移行の実現可能性が確認できない、といった結果に繋がりやすいといえます。情報システム部門が管理しているシステムに加え、各事業部保有のシステム、個別サーバーも存在するような状況の中で、その管理が標準化されておらず各ベンダーに依存した状況では、全社単位での移行検討が進まない、というのもうなづけます。 クラウドを利用する価値として、重複設備の削減や共通基盤利用によるコスト削減、アジリティや柔軟性の向上、運用効率化による工数削減、セキュリティ向上等があります。それらを実現する、若しくは評価するためにはアセットの棚卸、システム情報の可視化が必須であるといえます。全社的な移行戦略検討のはじめの一歩として、全体を俯瞰できる状態を整えておきましょう。 移行の対象とするシステムのインベントリ情報に関して、標準化されたアセット管理の仕組みが用意されていない場合、若しくは管理された情報が移行検討に十分でない場合、まずは必要な情報を定義し、それらを収集することから始める必要があります。ご参考までに収集が必要な項目例を以下にご紹介します。 [システム情報]： システム名称、ロケーション、利用者数、更新時期、システム重要度、依存関係、物理的制約、DR要件等 [サーバー情報]： サーバー名 、環境区分 (本番/テスト/etc..) 、アプライアンス、各種スペック、パフォーマンス情報、OS、ミドルウェア、HA 機能等 これら情報を効率的に取得できる対象の組織や責任者から、アンケートやヒヤリング形式で情報収集を行っていきます。個別のシステム担当者しか把握できていないケースもあり、収集が思うように進まない場合もあるかと思います。そういった際は、エグゼクティブスポンサー経由で各部門に対してその目的や内容に理解を求め、ある程度トップダウンで進められるよう働きかける、というのも1つのやり方かもしれません。 AWS では、移行の準備段階で必要なデータ収集、および分析・評価をご支援する各種 Discovery ツールの提供を行っています。例えばその 1 つ、 AWS Application Discovery Service ではインベントリやパフォーマンス状況、システム依存関係などをキャプチャして視覚化することで、クラウド移行の企画や情報整理、システムの利用傾向の把握に役立てることが可能です。また Migration Evaluator に関しては、移行評価サービスとして収集したインベントリデータからクラウド移行のビジネスケースを作成、コストやライセンス利用料含め 具体的なクラウド移行計画を検討する際に役立ちます。 以下、Discovery ツールを活用する有効性と特徴について参照下さい。 Discovery ツールの有効性： 分析用の価値の高いデータを収集可能 専門チームによる移行評価レポートを提供 データの視覚化が可能 各ツールの詳しい説明に関しては、以下のオンラインコンテンツでも紹介していますので、ぜひご覧ください。 クラウド移行における Discovery ツールの必要性 [ PDF | YouTube ] AWS Application Discovery Service の概要 (AWS 移行準備シリーズ) [ PDF | YouTube ] ２．移行準備で注力するべきポイントがわからない IT ベンダーへの依存度が高いことの弊害として、もう一つよく語られるのは、移行に向けた準備を進めたいが、具体的に何をしていいかがわからない、といった課題です。これはシステム管理全般をベンダーに任せているため、各システム毎の運営状況や抱える課題、現在地がわからず、実際に移行を推進するための具体的なタスクが見えてこない、といった原因で発生します。 効果的なクラウド導入を進めるためには、必要なプラットフォームやセキュリティに関する検討、またオペレーション関連の要件確認、調整といった技術観点での準備のみならず、全社で推進するために必要なビジネス、人・組織、ガバナンス等、非技術面の観点でも準備が必要となります。特にビジネス目線でクラウド移行がもたらす効果を明らかにし、共通理解として明文化しておくことは、後続フェーズでタスクを進める中で、それら期待効果や目的に立ち戻って検討・評価が必要となった際に非常に重要となります。この Assess (評価) フェーズにおいては、これら技術・非技術面に関する現時点での準備状況 (どの程度準備が整っているか) と、取組むべき課題を明らかにしておく必要があります。 業務を支えるシステム自体、若しくは取り巻く環境が抱える課題の把握がおろそかでは、真に必要なタスクをイメージすることは難しくなってしまいます。このようなケースでは現在のシステム全体像の把握と共に、自社クラウド移行の位置づけ、期待されるビジネス価値を整理し、目的達成に向けて取り組むべき課題、タスクを明らかにすることが重要です。また、お客様が既に認識している課題とまだ顕在化されていない課題、また将来課題となり得るリスクを含め、全網羅的に抽出することが重要です。 AWS では現状のシステム移行に向けた準備がどの程度整っているかを客観的に評価、分析するためのご支援として「Migration Readiness Assessment (MRA) 」 というプログラムを提供しています。このプログラムは、アセスメントシートに記載された各種質問に回答いただくことで、クラウド移行に向けた現在の準備状況をフレームワークに沿って網羅的に分析し、実際の移行推進に向けた課題の明確化を行っていきます。 具体的にはクラウド導入フレームワーク AWS Cloud Adoption Framework (CAF) の6つの観点における、課題とニーズを抽出して、原因分析と施策を検討します。ヒアリング結果を評価、色分けをして、レーダーチャートなどで可視化することにより、アーキテクチャーの議論には含まれない、会社としてのビジネス、人・組織と IT の関係性、親和性やガバナンスの在り方など、包括的な評価が可能となり、その後の移行計画のインプットとしてご利用頂くことが可能です。 MRA につきましては、 こちら のブログでも解説していますので、併せてご参照ください。 まとめ いかがでしたでしょうか。後編では、Assess (評価) フェーズで語られることが多い、IT ベンダー依存に関する課題と解決策についてお話をしてきました。IT ベンダーとの関係性を良好に保つことは、日頃の運用や業務効率化においても、重要であることは明白です。ただしあまりに依存度が高い場合にはベンダーロックインのような状態が発生し、長期的にはコストや品質、アジリティの観点などさまざまな弊害が発生する可能性があります。役割分担を明確にし、主要なナレッジや経験が社内にも蓄積されるよう、日頃からコントロールすることも重要ではないでしょうか。 次回は、後続の Mobilize (移行準備) フェーズにおける頻出課題と解決策についてお話をしていきます。お楽しみに！ カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー (CSM) 上原 研太、安部 俊作 参考リンク クラウドジャーニーの歩み方 (前編) クラウドジャーニーの歩み方 – Assess (評価) フェーズ – #1 AWS Application Discovery Service Migration Evaluator AWS Cloud Adoption Framework (CAF)

まえがき みなさん、こんにちは。カスタマーソリューションマネージャー (CSM) の安部です。カスタマーソリューションマネージャーは、クラウド導入を進めようとしているお客様のクラウドジャーニー全般を支援する活動をしています。 本ブログは、現状オンプレミス上で多くの IT 資産が稼働しており、AWS への移行を考えたいお客様向けに作成しています。 この記事では、CSM の観点で、AWS への移行を検討しているお客様がクラウド移行を進めるにあたり、クラウド移行の4つのフェーズと各フェーズで阻害要因となる10のハードルを軸に、各フェーズにおいてどのような具体的な課題を持たれ、どのように解決していくかを事例を紹介しながら、紐解いていこうと思います。 AWSのクラウド移行およびクラウド活用の道のりについては、「 クラウドジャーニーの歩み方 (前編) 」と題したブログでも紹介していますので、併せてご参照ください。 クラウドジャーニーにおける10のハードル クラウド移行には、4つのフェーズがあります。Assess (評価) から始まり、Mobilize (移行準備) に入り、Migration (移行) へと進みます。さらに、クラウド利用によるビジネスの価値を高めるため、Modernization (最適化とモダナイゼーション) へ取り組む流れとなります。本ブログでは、最初の取り組みとなるAssess (評価) に焦点を当てて、前編・後編でまとめています。前編では、下記図に示す「クラウドジャーニーにおける10のハードル」の最初のハードルである、「１．クラウド移行のビジネスメリットがわからない」に関して、課題の深堀りと解決策についてお話いたします。 Assess (評価) フェーズでの課題 前編 本前編では、本Assess (評価) フェーズの位置づけからご説明します。 クラウドジャーニーの歩み方でも触れました通り、Assess (評価) フェーズでは、クラウド移行のためのビジネスの全体戦略の策定、全体戦略から紐づくビジネス価値の特定、現状分析とあるべき姿の定義とロードマップの検討を行うことが求められます。これらは、何を目的にクラウド移行を進めるのかを理解して、コスト削減だけにはとどまらず、イノベーションを起こす企業風土の構築に不可欠となり、はじめの一歩の重要なフェーズとなります。 本フェーズにおいてよくある課題を掘り下げてみます。 「 １．クラウド移行のビジネスメリットが分からない」 クラウド移行のビジネスメリットがわからない状態という課題は、クラウド戦略の策定がされていない、またはビジネス戦略の中に明確に体系的に表現されていない場合に起こりがちです。最適なビジネス成果を実現するためには、ビジネス戦略とクラウド戦略が統合されて、クラウド機能が各ビジネスユニットにどのような戦略的利点をもたらすかの組織内理解が進んでいる必要があります。現状、クラウド戦略がどの程度策定されているかを確認する方法として、各事業部において将来ビジネスに対応したIT課題の施策が具体的に検討されているか、また上位層の情報源としては、年次報告書、中期経営計画書、経営層からステークホルダーへの社長レターなどがあります。ビジネスリーダーが、クラウド対応の機会をビジネス戦略や計画に組み込んでいるかを読み込んで、実現したい目標が明確になっているか確認してみてください。 ここで、クラウド戦略が策定されていないもしくは漠然とした戦略である場合を想定してみましょう。なぜクラウドなのか？ビジネスの観点で見た場合のクラウドとは、自社でハードウェアや設備を購入、準備することなく、ネットワーク経由でコンピューティング、データベース、ストレージ、ソフトウェアといったさまざまな、ITリソースをオンデマンドで、利用することができるサービスとなります。オンプレミスに比べて、利用までにかかる時間の圧倒的短縮、需要の縮小や拡張にあわせたリソースの利用、利用した分だけの支払いという従量課金制、 IT 資産の固定費から変動費への転換といった特徴があります。 次に既存の自社システムが稼働しているシステム環境について、改めて振り返ってみます。オンプレミスやプライベートクラウドでは、自社で必要となるサーバーやネットワーク機器、電源機器、ソフトウェアなどを自社で保有して、運用されている利用形態となります。メリットは、⻑年の運⽤実績を踏まえたセキュリティー管理や、⾃社内ですべての設備環境を掌握し、情報漏洩防止を自主管理できること、⾃社ネットワークの低レイテンシー要件への対応ができること、などがあります。これはオンプレミスのデメリットにもつながり、初期導⼊コストやデータセンター維持等の固定費の発⽣、定期的な機能増強や⽼朽化対応、保守、災害対応などによる俊敏性の低下、負荷に対応したサイジングが困難で、余剰キャパシティーの発⽣やリソース不⾜による機会損失があります。 今一度、時間がかかっても、コストがかかっても、すべて自前でコントロールできるITインフラを企業内の全システムが持つべきかを考える必要があります。 オンプレミスのシステム運用にかかる人件費や設備費に対して、ビジネス的価値、利益をほとんど生み出していないのが、オンプレミスを保持し続ける一番の課題ではないでしょうか。 それぞれの事業組織やビジネス領域において、クラウドを活用して何を実現したいのかといったゴールやビジネス目標を明確にし、それを実現するためにはどのようにクラウド移行をするのかといった移行戦略を立案することが重要です。 これらの課題に対してAWSでは、全社的なシステム全体のクラウド移行戦略を支援するための、「Enterprise Transformation Workshop (ETW) 」という企画構想支援ワークショップがあります。全社で保有する現行システムをリスト化して、稼働状況、抱えている課題を洗い出して、どうあるべきかを明文化して、移行パスと移行戦略を検討して可視化することで、施策の優先順位とロードマップにまとめてていくものです。 「AWS IT トランスフォーメーションパッケージ 2023 ファミリー (ITX 2023) 」 と併せてご案内できますので、ご興味をお持ちのお客様は、アマゾン ウェブ サービスの営業担当者にお問い合わせください。 まとめ 前編では評価フェーズとして、システムたな卸しによる課題認識、ビジネスのあるべき姿明確化に向けたクラウド移行の戦略立案、そして移行準備の状況評価による強化ポイント洗出し、までを行いました。 後編 では、評価フェーズのもう一つのハードルとして、「ベンダー依存で何をするにも時間がかかり進まない」についての課題とその取り組みについて、ご紹介いたします。 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー (CSM) 安部 俊作、上原 研太 参考リンク NIST (アメリカ国立標準技術研究所) によるクラウドコンピューティングの定義 AWS IT トランスフォーメーションパッケージ 2023 ファミリー (ITX 2023) クラウドジャーニーの歩み方 (前編)&nbsp; クラウドジャーニーの歩み方 – Assess (評価) フェーズ – #2

ブロックチェーン領域のビルダーがアプリケーションを提供するために、ブロックチェーンノード運用、ブロックチェーンデータ抽出、標準API開発などの差別化されていないタスクに費やす時間を減らして、ユースケースに合わせた機能の開発により多くの時間を費やす必要があります。多数のパブリックブロックチェーンノードを構成、プロビジョニング、および保守することは、可用性、耐障害性、およびパフォーマンスの高い方法でこれらのノードを運用するために必要なインフラストラクチャコストと人的時間の両面で、リソースを大量に消費する可能性があります。 お客様にとってコスト最適化が最優先事項であるため、限られた開発者リソースは、ユースケース固有の機能に直接影響を与える差別化されたタスクに最適に割り当てる必要があります。 Amazon Managed Blockchain (AMB) Access Bitcoin は、このニーズに応えるためにAMBサービスで初めてリリースされた最初のサーバーレスJSONリモートプロシージャコール(JSON-RPC)APIです。これにより、AWSが管理するブロックチェーンノード群へのリクエストトラフィックを処理する、従量課金制で高性能なJSON-RPC APIを実現し、ブロックチェーンノードの運用に関連する固定費の高騰と差別化できない重労働を排除できます。 お客様の要望に応えて、 AMB Access は現在PolygonのProof-of-Stakeネットワークをパブリックプレビューでサポートしています。PolygonのメインネットとMumbaiのテストネットの両方が利用できます。AMB Access Polygonを通じて、開発者は常時稼働しているエンドポイントを介してPolygon JSON-RPC APIを利用でき、予測可能な従量課金でPolygonネットワークと対話するアプリケーションを構築できます。AMB Access Polygonは、Polygon JSON-RPC APIへの反復的で高可用なアクセスを必要とするユースケースや、断続的で予測不可能なアクセスを必要とするユースケースなど、さまざまなユースケースに対応しています。 この投稿では、新しいAMB Access Polygonのパブリックプレビューの概要、Polygon上で開発を行う開発者をどのようにサポートするか、および一部の顧客がPolygonで構築しているユースケースについて説明します。Polygonでの構築を開始する方法とリソースの詳細は、 Amazon Managed Blockchain Access Polygon developer guide で確認できます。 AMB Access polygon Public Previewの概要 AMB Accessは、パブリックブロックチェーンとプライベートブロックチェーンへのアクセスを提供する、フルマネージドサービスです。AMB Accessを利用することで、スケーラブルで、セキュアなレジリエントなWeb3アプリケーションを開発・展開することができます。 AMB AccessのPolygonのパブリックプレビューでは、AWSのスケーラブルかつセキュアなインフラストラクチャ上で、Polygonの持つトランザクションを高速かつ低いガス代(トランザクションの手数料)で処理できる能力を活用できるようになりました。AMB Access Polygonは、最小コストなしでPolygonブロックチェーンへのインスタントかつサーバーレスアクセスを提供します。AMB Access Polygonを使用すると、開発者は専用のブロックチェーンインフラストラクチャを必要とせずに、パブリックエンドポイントを介してPolygonメインネットとMumbaiテストネットの両方へRPCを行うことができます。 PolygonへのAMBアクセスが開発者をどのようにサポートするか AMB Access Polygonを使用すると、開発者はブロックチェーンインフラストラクチャの管理の負担なしに、 non-fungible token (NFT) マーケットプレイス、ロイヤルティ報酬プラットフォーム、実世界のアセットトークン化エンジンなどのアプリケーションを構築するために、Polygon メインネットとMumbaiテストネットをすぐに利用できます。完全マネージドのサーバーレスアクセスにより、アーカイブノードを含むPolygonノードのスケールアウトが可能です。 次の図は、バックエンドアプリケーションまたはクライアントマシンからPolygonネットワークと対話するためのアーキテクチャを示しています。 Polygonの上に構築する開発者は、次のような方法でAMBアクセスの恩恵を受けます 市場投入までの時間の短縮 — AMB Accessにより、開発者はプロビジョニングやセットアップに時間をかけずに、アプリケーションの差別化された側面を構築できるようになり、市場投入までの時間を短縮できます。 自動スケーリング — ワークロードの増大に応じてAMB Accessが処理する自動スケーリングにより、ブロックチェーンアプリケーションを簡単にスケーリングできます。 費用対効果の高い管理 — ブロックチェーンアプリケーションをコスト効率よく運用でき、従量課金の料金体系のため、自己管理型インフラストラクチャと比較してブロックチェーンのノード支出を最大 80% 節約できます。 商用品質のアプリケーション — 信頼性、セキュリティ、可用性 (99.9% のアップタイム) に対する AWS の高い基準に依存する商用品質のブロックチェーンアプリケーションを構築できます。 AMB Access Polygonで構築 Polygonノードのフリートが提供するさまざまな JSON-RPC APIs をサポートすることで、AMB Access Polygonは、デジタルアセットのユースケースからデジタルIDまで、ほぼあらゆる種類のブロックチェーンアプリケーションを構築できるように開発者を支援します。 たとえば、金融サービス機関は、AMB Access Polygonを使用して、ブロックチェーンからデータを読み取るためのJSON-RPC APIと、ユーザーに代わって署名されたトランザクションをブロードキャストするなど、カストディや取引などのデジタルアセットサービスを提供できます。 ゲームスタジオは、ゲーム内で使用およびプレーヤーによる交換のためのNFTを作成でき、消費者ブランドは、最も忠実なファンと顧客を褒め称え、報酬として代替可能なトークン(Fungible Token)を提供できます。 これらは、AWSのお客様がAMB Accessで検討しているユースケースのほんの一例にすぎません。 以下のリファレンスアーキテクチャは、AMB Access Polygonを使用する分散型アプリケーション(dApp)を示しています。 このハイブリッドなdAppアーキテクチャは、バックエンドシステムでデジタル資産を支出するために使用される暗号鍵を管理する信頼できる第三者であるカストディアルウォレットと、ユーザーがクライアントCLI、Webアプリ、モバイルアプリから直接トランザクションに署名してブロードキャストする暗号鍵を管理するノンカストディアルウォレットの両方をサポートします。このリファレンスアーキテクチャは、dAppで見つける可能性のある基本的なコンポーネントを表していますが、さまざまな機能要件を満たすために、他のAWSサービスを組み込んで拡張できます。このアーキテクチャは次のように機能します: Amazon CloudFront は、分散型ファイルストレージプロトコルであるInterPlanetary File System (IPFS) から配信される静的ウェブコンテンツ (React Native アプリケーションなど) へのグローバルアクセスを提供します。アプリケーション・ロード・バランサは、IPFSネットワークにルーティングしてコンテンツを提供するn個のIPFSゲートウェイ・ノード間でリクエストを分散します。 CloudFrontとIPFSを通じて提供されるこのウェブアプリケーションのユーザーにとって、ウォレット (暗号鍵) の管理責任を保管サービスの第三者に委任したいと思う人もいるかもしれません。これらのユーザーは、OAuth や多要素認証などの従来のログインメカニズムで認証し、REST API に API 呼び出しを行います。このアーキテクチャでは、認証は Amazon Cognito によって処理されます。Amazon Cognito は、 Amazon API Gateway でホストされている REST API に対して行われる API リクエストを保護するために使用されます。 たとえば、ユーザーが Polygon ネットワーク上のデジタル資産の取引をリクエストすると、API Gateway は AWS Lambda 関数をトリガーします。この関数は取引に署名してもらい、AMB Access Polygonを介してブロックチェーンにブロードキャストします。 Lambda 関数は、リクエストに対して提供された認証トークンにエンコードされたユーザー固有の識別子を使用して、 AWS Nitro Enclaves の分離されたコンピューティングインスタンスを利用する安全なトランザクション署名モジュールをトリガーし、ユーザーの機密性の高い秘密鍵を保管して Polygonのトランザクションに署名します。トランザクション署名のモジュールでは、 AWS Systems Manager が分離された Amazon Elastic Compute Cloud (Amazon EC2) インスタンスへのアクセスを管理し、 AWS Key Management Service (AWS KMS) がプライベートキーの導出に使用される対称暗号化キーを管理し、 AWS Secrets Manager が暗号化されたプライベートキー (暗号テキスト) を安全に管理します。 トランザクションがユーザーのプライベートキーで安全に署名されると、Lambda 関数は署名されたトランザクションを AMB Access によって公開される JSON-RPC API を介してパブリックな Polygon ネットワークにブロードキャストします。 eth_sendRawTransaction リクエストはトランザクションハッシュ (ID) を返し、これを使用して後続の JSON-RPC リクエストを使用してブロックチェーン上のトランザクションとそのステータスに関する情報を取得できます。 あるいは、自分のウォレット（暗号鍵）を所有しているノンカストディアルユーザーが、バックエンドシステムを使用せずに、ウェブアプリケーション（クライアント）からウォレットを使ってトランザクションに署名し、それをAMB Accessに直接ブロードキャストすることもできます。Amazon Cognito identity pool を使用して、 Amazon Managed Blockchain へのアクセスを許可する AWS Identity and Access Management (IAM) ロールの認証情報を委任できます。 AMB Access Polygonがさまざまなブロックチェーンアプリケーションのより広範なアーキテクチャにどのように適合するかを理解した上で、サービスがさまざまなユースケースを解決するためにどのように使用できるかを概説する具体的な例について詳しく見ていきましょう。 お客様はどのように AMB Access Polygonを使用しているか AMB Access Polygonを利用するお客様は、ゲームや金融サービスなど、複数の業種にわたるツールとユースケースの構築をしています。これらの顧客の例には次のものがあります Magicは、簡単にノンカストディアルウォレットを作成できることでWeb3へのユーザーのオンボーディングを支援するWallet as a Serviceのプロバイダーです。電子メールやソーシャルログインを使用して、シードフレーズやブラウザー拡張機能に代わるものです – 標準的なWeb2のエクスペリエンスと区別がつきません。Magicは、認証、フィアットオンボーディング、NFTのMint/Checkout、AWSのAMBサービスとのパートナーシップを通じたBlockchacein Node Serviceなど、end-to-endのWeb3オンボーディングのための機能を提供します。メインストリームの採用障壁を取り除くことで、 Magic.link は企業がストレスなくアプリ上の何百万人ものユーザーにリーチし、Web3に新しい顧客をオンボードさせることができます。2,500万を超えるウォレットを作成したMagicは、企業がWeb3のメリットをストレスなく実現できるようにします。 Mystic Mooseは、Mojo MeleeというPlanet Mojoという神秘的な世界に設定されたストラテジーオートチェスバトラーのインディーゲームスタジオおよびパブリッシャーです。このゲームは、プレイヤーに特殊な能力を持つ個性的なMojos、Champions、SpellStonesを組み合わせて、ダイナミックな1対1または8人のPvPバトルに参加するという、深い戦略的ゲームプレイと魅力的なビジュアルのユニークなブレンドを提供します。 Mojo Meleeは、カジュアルな愛好家からハードコアな戦略家まで、幅広いプレイヤーに訴求し、没入感と報酬のあるゲーム体験を提供します。 2023年8月、Mojo MeleeはAmazon Prime Gamingとのコラボレーションを発表し、Prime会員にゲームからの独占NFTを獲得する機会を提供しました。Oasis Proは、実物資産とデジタル証券のためのグローバルフィンテックインフラプロバイダーです。 Oasis Proは、デジタル通貨または法定通貨を使用した公開および非公開のトークン化証券のFINRA登録のマルチアセット取引プラットフォームソリューションを含め、従来の金融をWeb2からWeb3に橋渡しするend-to-endのソリューションを提供しています。 Oasis Proのスマートコントラクトは、ABSやプライベートエクイティなど、さまざまな金融商品のライフサイクルに合わせて調整されています。 AMB Accessを使用することで、Oasis Proはスマートコントラクトを安全にデプロイし、Polygonネットワーク上でOasis Proによって発行されたセキュリティトークンのすべてのイベントを監視できます。 これにより、Oasis ProはオフチェーンのCAPテーブルを維持し、トランザクションを報告し、ホワイトリストに登録された投資家のウォレットのセキュリティトークン残高を取得するためのアクションを実行できます。 Oasis Proは現在、将来的に他のブロックチェーンでAMBを使用することを検討しています。 株式会社レコチョクは、音楽配信を中心としたエンターテインメントコンテンツサービスの先駆的な企業です。レコチョクは「音楽でWeb3をもっと楽しく」というコンセプトのもと、NFTチケットサービスなどWeb3技術を活用したサービスを多数展開しています。従来の「入場証」としてのチケット機能にブロックチェーン技術の特徴を融合させた当サービスは、ライブやイベントへの参加証明としての役割を果たし、チケット保有者限定の体験など、チケットオーナーへの特別な権利を付与します。レコチョクは、このデジタルチケットを活用して、音楽&amp;エンタメ領域における新たなファンのビジネスを創出し、誰もが音楽をより楽しめるサービスの提供を目指します。 結論 この投稿では、Polygon上のweb3アプリケーションを構築するための信頼性の高い、スケーラブルでコスト効率の良い方法を開発者に提供する、新しいAMB Access Polygonパブリックプレビューの概要を提供しました。さらに、Polygon上で構築する開発者をサポートするAMB Access Polygonの主な機能、およびAMB Accessを使用している選択された顧客のユースケースについても共有しました。 Polygonとの対話のためのサポートされるRPCとサンプルコードを参照するには、 Getting Started guide.を参照してください。 本記事は「 Build on the Polygon network with Amazon Managed Blockchain Access 」を翻訳したものです。 翻訳はBlockchain Prototyping Engineerの深津 颯騎が担当しました。 著者について Forrest Colyer は、Amazon Managed Blockchain(AMB)サービスをサポートするWeb3/ブロックチェーン専門ソリューションアーキテクチャチームを管理しています。Forrestと彼のチームは、概念実証から本番までのあらゆる段階で顧客をサポートし、ブロックチェーンのワークロードを実現するための深い技術的専門知識と戦略的なガイダンスを提供しています。コンソーシアム主導のプライベートブロックチェーンソリューションやNFTやDeFiなどのパブリックブロックチェーンのユースケースの経験を通じて、Forrestは顧客が高インパクトなブロックチェーンソリューションを特定し実装するのを支援しています。 Soum Dasgupta は、Amazon Managed Blockchain AccessのProduct leaderです。Tech、Fintech、暗号企業にわたるプログラムと製品の構築に13年の経験があります。SoumはWeb3の見込みに熱心で、採用の障壁を取り除く製品の構築を愛しています。Soumは、カストディ、NFT、ゲーミング、DeFiスペースの顧客と緊密に連携し、使いやすくスケーラブルなソリューションの構築をしています。ブロックチェーン以前は、ソウムは9年間、顧客の財務とテクノロジーのリスクを管理するのを助けるコンサルティングで働いていました。

この投稿は、 2023 年 11 月 16 日の シニアソリューションアーキテクトの Nati Goldberg 氏と AWS Lambda シニアプロダクトマネージャーの Shridhar Pandey 氏によるブログ記事を日本語化したものです。元の投稿は こちら をご覧ください。 AWS は本日、 AWS Lambda の高度なログ制御機能をリリースしました。これにより、開発者や運用者は関数のログのキャプチャ・処理・消費をより細かく制御できるようになりました。 今回3つの新機能がリリースされ、Lambda の標準的なログ体験が簡略化・強化されました。 まず、独自のロギングライブラリを用意せずとも、JSON 形式のログフォーマットで Lambda 関数のログをキャプチャできるようになりました。JSON 形式のログを利用すると、大量のログの検索・フィルタリング・分析がより簡単にできるようになります。 次に、Lambda 関数のログレベルの制御がコードの変更なしでもできるようになりました。これにより、デバッグやトラブルシューティングがより効率化されます。 最後に、Lambda 関数のログ転送先の Amazon CloudWatch ロググループをユーザ側で設定できるようになりました。これにより、大規模なログの集約と管理がより簡素化されます。 概要 重要な問題をトラブルシューティングし修正するためには、関連するログメッセージの特定やフィリタリングが必要不可欠です。開発者や運用者が障害を監視しトラブルシューティングできるように、Lambda サービスは自動的にログをキャプチャし、CloudWatch Logs に転送します。 これまで、Lambda 関数はプレーンテキスト形式、つまり非構造化ログ形式でログを出力していました。これにより、ログのクエリやフィルタリングが難しくなってしまう場合もありました。その一例としては、ユーザは START・END・REPORT といったよくある文字列識別子、または関数呼び出し時のリクエスト ID を使って手動でログの検索と関連付けを行う必要があったことが挙げられます。また、ネイティブでアプリケーションログをエンリッチする方法がなかったため、自動分析を行ったり分析ダッシュボードを構築したりするにはユーザ側でログからのデータ抽出に対応する必要がありました。 これまで、運用者は関数のログレベルを制御することができず、INFO・DEBUG・ERROR などの必要なログレベルに設定するには、アプリケーション開発チームにコードを変更してもらう必要がありました。 Lambda ベースのアプリケーションは多くの場合複数のマイクロサービスで構成され、それぞれのマイクロサービスが複数の単一目的の Lambda 関数で構成されます。このリリースより以前は、Lambda 関数のログは関数作成時に作成されるデフォルトの CloudWatch ロググループに送信され、ロググループの指定はできませんでした。今では、複数の関数のログを一箇所に集約できるようになったため、セキュリティやガバナンスおよび保持ポリシーを一括で適用できるようになりました。 JSON 形式のログフォーマットで Lambda のログをキャプチャする この度のリリースで、Lambda は一連のキーバリューペアの形で構造化ログを JSON 形式でキャプチャすることをネイティブサポートするようになりました。これにより、ログの検索とフィルタリングがより簡単にできるようになりました。 JSON 形式の構造化ログを利用する場合、ログに独自のタグやコンテキスト情報を追加することもできるため、大量のログを自動的に分析できるようになり、これは関数のパフォーマンスを理解するのに役立ちます。Lambda の JSON 形式のログフォーマットは人気のオープンソースロギング標準である OpenTelemetry（OTel）の Logs Data Model に準拠するため、関数の監視にオープンソースのツールをご利用いただけます。 コンソールからログフォーマットを変更するには、 設定 タブを選択した上左側のパネルから モニタリング及び運用ツール を選択し、そしてログフォーマットのプロパティを変更をします。 Lambda はアプリケーションログ（関数コードが生成するログ）とシステムログ（Lambda サービスが生成するログ）を JSON 形式のログフォーマットでキャプチャすることをネイティブサポートするようになりました。 これは、Python、Node.js、Java の非推奨バージョンを除く各バージョンの Lambda ランタイム を利用した関数で、Lambda 推奨のロギング方法（例えば、Python では logging ライブラリ、Node.js では コンソールオブジェクト 、Java の場合では LambdaLogger または Log4j が推奨されています）を使って出力したログに適用されます。 その他のランタイムの場合、現時点ではシステムログのみ JSON 形式のログフォーマットでのログキャプチャがネイティブサポートされています。とはいえ、手動でロギングライブラリを設定すれば、アプリケーションログをJSON 形式のログフォーマットでキャプチャすることが可能です。より詳しくは、Lambda の開発者向けガイドの Configuring advanced logging controls for your Lambda function のセクション（英語のみ）をご参照ください。また、 Powertools for AWS Lambda を使用した JSON 形式のログフォーマットでのログのキャプチャも可能です。 テレメトリーパイプラインでログをパースしている場合、ログフォーマットをテキストから JSON に変更することはシステムに深刻な影響を与えてしまう可能性があります。AWS では、ログフォーマットの変更後全てのテレメトリーパイプラインをテストすることを推奨しています。 Node.js の Lambda 関数で JSON 形式のログフォーマットを利用する JSON 形式のログフォーマットとともに CloudWatch 埋め込みメトリクスフォーマット （CloudWatch Embedded Metric Format, EMF）を使用すれば、JSON 形式の構造化ログにカスタムメトリックスを埋め込むことができます。CloudWatch は自動的に埋め込まれたカスタムメトリックスを取得し、これをアラームの設定や可視化に活用できます。ただし、Node.js の Lambda 関数で JSON 形式のログフォーマットとともに EMF ライブラリーを使用するには、最新バージョンの Node.js 用 EMF クライアントライブラリ 、 または最新バージョンの Powertools for AWS Lambda（TypeScript）ライブラリ を使用する必要があります。 Lambda 関数のログレベルを設定する コードの変更なしに ERROR・DEBUG・INFO などのログレベルによって Lambda のログをフィルタリングできるようになりました。簡素化されたログレベルフィルタリングにより、エラーをデバッグするために大量のログをふるい落とす必要がなくなり、必要なログの粒度が選択できるようになりました。 アプリケーションログ（関数コードが生成するログ）とシステムログ（START や REPORT ログメッセージのような Lambda サービスが生成するログ）でそれぞれのログレベルフィルタを設定することが可能です。ただし、ログフォーマットが JSON に設定されている場合のみ、ログレベルの設定が可能になります。 各ログイベントのログレベルは関数コード内で定義できます。次のコードでは関数のインプットである event を DEBUG ログとして出力しています。 console.debug(event); 関数のログレベルを設定すると、設定されたログレベルより低レベルのログイベントはその関数の CloudWatch ログストリームに送信されなくなります。例えばログレベルが INFO に設定された場合、DEBUG ログは転送されません。 この機能を活用することで関数が出力するログの量を適切に制御できるようになります。例えば、本番環境ではノイズ率をさげるためにログレベルを高めに設定しておき、テストやトラブルシューティング時はより細かいログイベントを収集できるようにログレベルを低く設定したりすることができます。 Lambda 関数の CloudWatch ロググループを設定する これまでは、ユーザ側で関数の CloudWatch ロググループの設定ができなかったため、複数の関数からのログを一つの共通のロググループにストリーミングできませんでした。また、複数のロググループに任意の保持ポリシーを適用するには、各ロググループを /aws/lambda/&lt;function&gt; のような規定された名前で個別に作成する必要がありました。 今では、任意の CloudWatch ロググループを指定し、アプリケーションを構成する複数の関数からのログを自動的に一箇所に集約できるようになりました。関数レベルではなく、アプリケーションレベルでセキュリティ・ガバナンス・保持ポリシーを適用できるようになっています。 ログストリーム名には Lambda 関数の名前とバージョンが入っているため、これが共通のロググループに入っていても、ログの発行元の関数を見分けることができるようになっています。 複数の関数で共通のロググループを使用することによりログを集約することができます。Lambda が指定されたロググループにログを送信できるようにするためには、関数の IAM ポリシーに logs:CreateLogStream と logs:PutLogEvents の権限を付与することが必要です。コンソールで関数のロググループを設定する場合は、Lambda サービスが自動的に必要な権限を付与します。 コンソールでロググループ名を入力すれば、関数のログの送信先を任意のロググループに設定できます。入力したロググループが存在しない場合、Lambda が自動でロググループを作成します。 Lambda の高度なログ制御機能は Lambda API 、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス（CLI） 、または AWS サーバレスアプリケーションモデル（AWS SAM） や AWS CloudFormation などの infrastructure as code（IaC）ツールからご利用いただけます。 Lambda の高度なログ制御機能を使用したサンプルアプリケーション このセクションでは、AWS SAM から新しくリリースされた Lambda の高度なログ制御機能を利用し、AWS 上でリソースをビルドおよびデプロイする方法を示します。 概要 次のアーキテクチャ図では、 Amazon S3 のバケットに新しいオブジェクトが作成された後、二つの Lambda 関数がそれぞれオブジェクトを処理し、ログを共通の CloudWatch ロググループに送信することを表しています。 具体的な処理の流れは以下となります： S3 バケットに新しいオブジェクトが作成されます。 S3 が S3 イベント通知機能 によって Amazon EventBridge にイベントを発行します。 EventBridge が非同期的に二つの Lambda 関数を発火させます。 関数がそれぞれ Amazon Rekognition と Amazon Textract を利用し、オブジェクトからラベル検出とテキスト抽出を行います。 各関数が共通の CloudWatch ロググループにそれぞれのログを送信します。 ここでは AWS SAM を使用して Lambda 関数を定義し、必要なログ制御を設定しています。IAM ポリシーでは、関数が指定のロググループにおいてログストリームの作成とログの送信ができるよう権限設定されています。 DetectLabelsFunction: Type: AWS::Serverless::Function Properties: CodeUri: detect-labels/ Handler: app.lambdaHandler Runtime: nodejs18.x Policies: ... - Version: 2012-10-17 Statement: - Sid: CloudWatchLogGroup Action: - logs:CreateLogStream - logs:PutLogEvents Resource: !GetAtt CloudWatchLogGroup.Arn Effect: Allow LoggingConfig: LogFormat: JSON ApplicationLogLevel: DEBUG SystemLogLevel: INFO LogGroup: !Ref CloudWatchLogGroup サンプルをデプロイする サンプルをデプロイする手順は下記となります： GitHub リポジトリ をクローンし、アプリケーションを確認します。 git clone https://github.com/aws-samples/advanced-logging-controls-lambda/ cd advanced-logging-controls-lambda &nbsp;AWS SAM を使ってリソースをビルドし、AWS 上にデプロイします。下記のコマンドでは、npm によってアプリケーションがビルドされ、リソースをデプロイするのに必要なテンプレートが作成されます。 sam build AWS SAM CLI によるインタラクティブなデプロイガイドを利用しソリューションをデプロイします。 sam deploy --guided 下記の値を入力してください。 Stack Name： advanced-logging-controls-lambda Region：デプロイ先のリージョン（例えば us-east-1 など）を入力してください。 Parameter UploadsBucketName：一意的なバケット名を入力してください。 ほかは全てデフォルトのままにしてください。 アプリケーションをテストするため、下記の AWS CLI コマンドを使って先ほど作成した S3 バケットにサンプル画像をコピーしましょう。 aws s3 cp samples/skateboard.jpg s3://&lt;先ほど作成したバケットの名前&gt; CloudWatch に作成された AggregatedLabelsLogGroup という名前のロググループに出力されたログを確認します。 ログストリームには、DetectLables という Lambda 関数が JSONフォーマットで出力した DEBUG ログイベントがある一方、ExtractText 関数からの同レベルのログイベントは省略されています。これは、それぞれの関数ではアプリケーションログのログレベルの設定の違い（DetectLables では DEBUG、ExtractText では INFO）に由来します。 下記のサンプルクエリのように、 CloudWatch Logs Insights を使用した JSON フォーマットのログの検索・フィルタリング・分析も可能です。 以下のようなクエリ結果が得られます。 まとめ Lambda の高度なログ制御機能によって、ログをより細かく設定できるようになりました。Lambda 関数のログレベルやログフォーマットが設定できるようになったため、ユーザはより簡単にログを検索・クエリ・フィルタリングできるようになり、効果的にトラブルシューティングを行うことができるようになりました。 Lambda のログの送信先の CloudWatch ロググループもユーザ側で指定できるようになりました。これにより、複数の関数のログを一つのロググループに集約し、保持・セキュリティ・ガバナンスポリシーを共通化することで、大規模なログ管理を効率化できるようになりました。 新規・既存の Lambda 関数のロギング設定を必要に応じて設定することで、これらの新機能が利用できます。 Lambda の高度なログ制御機能は、Lambda が利用可能な全ての AWS リージョンで追加費用なしでご利用いただけます。より詳しくは、こちらの ドキュメント（英文のみ） をご参照ください。 Serverless Land では、他にもサーバレスの学習リソースをご用意しております。 日本語のサーバレス学習リソースについては、 サーバーレスパターン や サーバーレス自己学習ガイド もご覧ください。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 AWS re:Invent が今日から 12 月 1 日 までラスベガスで開催されています。現地に行けない方でも、キーノートとイノベーショントークのライブ配信を視聴頂けます。 こちら からご登録ください。また、ご登録頂くとオンデマンドでいくつかの動画が視聴できるようになります。リアルタイムの視聴が難しい場合もぜひご利用ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2023年11月20日週の主要なアップデート 11/20(月) Amazon QuickSight now Supports Connectivity to Google BigQuery Amazon QuickSight から Google BigQuery に直接接続できるコネクターの一般提供を開始しました。QuickSight のデータセット画面から BigQuery コネクターが選択する際に、BigQuery のテーブルを直接指定することが出来ます。また、カスタム SQL オプションを利用して、異常検出、予測、自然言語クエリなどの ML 機能を使用して QuickSight で高度な分析を実行できるようになります。詳細は こちら のブログをご覧ください。 Introducing Amazon CodeWhisperer for command line (preview) コマンドライン用の Amazon CodeWhisperer のプレビューを発表しました。「CLI 補完」と「自然言語から bash へ変換」の 2 つのコア機能を提供しています。「CLI 補完」は、コマンドラインに文字を入力すると、文字に合わせたコマンドの補完をします。git、npm、docker、aws のサブコマンドを表示してくれ、候補の中から実行したいものを選択できます。「自然言語から bash へ変換」は、例えば「S3 バケットからデスクトップにデータをダウンロードする」といった自然言語命令を記載すると、Amazon CodeWhisperer が実行可能なシェルコードに変換します。 こちら の X ポストに動作している様子の GIF アニメーションがあり、ご覧頂くと動作を理解しやすいです。 Amazon S3 now supports enabling S3 Object Lock on existing buckets Amazon S3 の既存のバケットに対して、S3 Object Lock を後から有効化ができるようになりました。S3 Object Lock を利用することで、指定した期間、オブジェクトの上書きや削除を禁止でき、データ保護に活用できます。既存のバケットに対して S3 Object Lock を有効化すると、新たに作成するオブジェクトに保持期間を適用できます。既存のオブジェクトを保護するには追加の作業が必要です。各オブジェクト対して保持に関する設定を有効化が出来ますが、ひとつづつ設定するのは大変なので S3 Batch Operations を利用して複数のオブジェクトを一括で有効化できます。 Amazon EMR on Amazon EKS is now available in 3 additional regions Amazon EMR on Amazon EKS が大阪リージョンで新たに利用可能になりました。EKS を既に利用されているお客様は、EMR を既存の EKS クラスタで実行できます。これにより、EKS 環境のリソースの利用率を向上させ、インフラ管理を簡素化でき、効率よく EMR のアプリケーションを動かすことが出来ます。 EC2 Security group connection tracking adds support for configurable idle timeouts Amazon EC2 のコネクショントラッキングに、アイドルタイムアウトを設定する機能が新たに追加されました。EC2 に割り当てるセキュリティグループには、確立された各コネクションをトラッキングして、戻りパケットを期待通りに受信する動作をします。インスタンスごとにトラッキングできるコネクション数の上限があり、アイドルのままのコネクションはトラッキングの枯渇に繋がります。TCP 接続の場合は、デフォルトで 5 日間アイドルコネクションを保持します。今回のアップデートで、アイドルのままのコネクションを、タイムアウトする時間を短く設定することができるようになり、コネクションの枯渇を緩和しやすくなりました。詳細は こちら のドキュメントをご覧ください。 Amazon QuickSight now supports runtime filtering for embedded dashboards and visuals Amazon QuickSight で埋め込みダッシュボードを表示する際に、QuickSight Embedding SDK を通じて「見た目のテーマの動的変更」と「データを表示する際のフィルターの動的変更」が利用できるようになりました。例えば、QuickSight のダッシュボードを SaaS アプリケーションに組み込む際に、表示するユーザーによってカスタマイズを行いたいときがあります。「見た目のテーマの動的変更」は、ダークモードやライトモードといった表示色や、フォントをログインユーザーに合わせて変更が出来ます。「データを表示する際のフィルターの動的変更」は、ログインするユーザーに合わせてフィルターの変更を動的変更でき、表示するデータを出し分けることができます。例えば、管理者は全てのデータが見えるが、一般ユーザーは一部の許可されたデータしか表示しない、といったコントロールがやりやすくなりました。詳細は こちら の Blog をご覧ください。 11/21(火) Amazon CloudFront announces CloudFront KeyValueStore, a globally managed key value datastore Amazon CloudFront で CloudFront KeyValueStore を一般提供開始しました。これは、CloudFront Functions 内からの読み取りアクセスを提供する、グローバルで利用可能な低レイテンシーのキーバリューストアです。メリットを一つあげると、CloudFront Functions 内の設定データを外部の KeyValueStore に外出しできます。例えば、CloudFront Functions を利用して URL のリダイレクトを行う際に、「リダイレクトの条件」や「リダイレクト先の URL」を変更したいときがあります。いままでは CloudFront Functions のソースコード内に設定データを埋め込んだ実装が必要でした。そのため、動作を変更をしたい場合に CloudFront Functions 全体をデプロイすることになり、意図しない変更を加えてしまうリスクがありました。KeyValueStore を利用することで設定データを外出しでき、ソースコードの全体をデプロイすることなく、簡単に設定データだけを更新できるようになりました。詳細は こちら の Blog をご覧ください。 AWS Amplify launches next generation of backend building capabilities AWS Amplify はコード中心の開発者体験を提供する機能のパブリックプレビューを開始しました。従来の機能では、Amplify CLI や Amplify Studio を使用してバックエンドを作成する、ツール中心の利用方法でした。Gen 2 と表現される新しい機能では、コード中心のアプローチに移行し、開発者がアプリの要件 (データモデル、ビジネスロジック、認可ルール) を TypeScript で表現できるようになりました。必要なクラウドインフラストラクチャは、明示的な定義なしに、アプリケーションコードに沿って自動的にデプロイされます。詳細は こちら の Blog をご覧ください。 Amazon S3 server access logging now supports automatic date-based partitioning Amazon S3 のサーバーアクセスログは、日付ベースの自動パーティショニングをサポートしました。サーバーアクセスログは、オブジェクトサイズ、合計時間、所要時間、HTTP リファラーなどを含む、S3 バケットに対して行われたリクエストの詳細なログを保存します。日付ベースのパーティショニングにより、Amazon S3 はログをバケットに保存するときにイベント時間または配信時間のプレフィックスを自動的に生成します。これによって、Amazon Athena、Amazon EMR、Amazon Redshift Spectrum などのサービスがクエリー実行するときに日付パーティションを活用しやすくなり、パフォーマンス向上やコスト削減のメリットがあります。 11/22(水) Amazon EMR Studio is now available in 4 new AWS Regions Amazon EMR Studio が大阪リージョンを含めた 4 つのリージョンで、追加で利用可能になりました。EMR Studio は、データサイエンティストやデータエンジニアが、PySpark、Python、Scala、R で記述された分析アプリケーションを簡単に開発、視覚化、デバッグできるようにする統合開発環境 (IDE) です。デバッグをやりやすくするために、Spark UI や YARN Timeline Service などのツールも提供されています。詳細は Amazon EMR Studio の ドキュメント や、YouTube の デモ動画 をご覧ください。 Amazon QuickSight launches a new redesigned analysis experience Amazon QuickSight はダッシュボードをより直感的かつ効率的に作成できる、新しい分析体験の機能を提供開始しました。いくつか機能を挙げると、レイアウトが 3 ペインに変わりました。明確に整理された画面構成となり、データの選択、可視化のためのビジュアルの構築、オブジェクトのプロパティ画面などがより直感的にわかりやすくなりました。他にも、分析ツールバーが新しくなり、UNDO/REDOボタンの追加、ビジュアルの追加ボタンなど、重要な機能群に素早くアクセスできるようになりました。詳細は こちら のブログをご覧ください。新しい画面レイアウトの画像と共に新機能が紹介されています。 Logs support now available in AWS Distro for OpenTelemetry AWS Distro for OpenTelemetry (ADOT) でログ収集の機能が一般提供開始になりました。ADOT は AWS がサポートする OpenTelemetry プロジェクトのディストリビューションです。今回のアップデートにより、お客様は ADOT コレクターとサポートされている OpenTelemetry SDK (Java、JavaScript、.NET、Python) を使用して、ログを収集し、Amazon CloudWatch や Amazon OpenSearch などの OpenTelemetry Protocol (OTLP) をサポートするバックエンドに送信できるようになりした。また、Amazon EKS および Amazon ECS で実行されているアプリケーションで、標準化された方法でログを含めたすべてのテレメトリデータを収集できるようになりました。Filelog レシーバーと AWS CloudWatch Logs エクスポーターのサポートを ADOT コレクターに追加することで、アプリケーションログを収集し、CloudWatch Logs にログを収集できます。 Amazon OpenSearch Service now supports Neural Sparse Retrieval Amazon OpenSearch Service 2.11 で Neural Sparse Retrieval がサポートされました。この機能は「セマンティック検索」を実現する際に利用できる機能です。「セマンティック検索」は、単にキーワードをマッチングするのではなく、ユーザーのクエリの意図と文脈を理解しようとする検索技術です。従来、OpenSearch Sercvice で「セマンティック検索」を実現するために、ベクトル埋め込みによる k-NN 検索を利用してきました。k-NN 検索は、ベクトル数や次元数によっては多くのメモリと CPU を要求します。今回新しく追加された Neural Sparse Retrieval &nbsp;ではベクトルの代わりに、入力トークンと関連性の高いキーワードを重みとともにドキュメントに埋め込むことで、転置インデックスによるセマンティック検索を実現します。これは k-NN と比較してリソース消費量を抑えられる可能性があります。 11/23(木) アップデートはありませんでした 11/24(金) アップデートはありませんでした 次回の 週刊AWS は、AWS re:Invent で紹介された内容のうち、いくつをピックアップして紹介する特別号をお送りする予定です。私自身、新たに発表される内容を楽しみにしています :) それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

AWS Amplify Hosting における、Amplify アプリでカスタムドメインを使用する際のワイルドカードサブドメインの一般提供を発表することができ嬉しく思います。これは、Software as a Service (SaaS) やマルチテナントプラットフォームで、ユーザーにカスタマイズされた体験を提供する開発者にとって重要です。 この新機能は、静的アプリ、シングルページアプリケーション (SPA)、Next.js を使用したフルスタックサーバーサイドレンダリングアプリなど、カスタムドメインを使用して Amplify Hosting にデプロイされた任意のアプリで利用可能です。この機能により、動的なお客様固有のサブドメインを作成するプロセスが簡素化されるだけでなく、アプリのカスタマイズの可能性が広がります。ワイルドカードサブドメインでは、“*” ワイルドカードを使用して、トラフィックを Amplify アプリのブランチにルーティングする “catch-all” サブドメインを作成できます。これは、独自のユニークなサブドメイン識別子を必要とする SaaS アプリで一般的なパターンであり、お客様やアカウントのオンボーディング（およびオフボーディング）時にアプリが柔軟に対応できるようにします。 ソリューションの概要 この記事では、ワイルドカードサブドメインを活用した Next.js サーバーサイドレンダリング (SSR) アプリを Amplify Hosting で構築する方法を紹介します。Next.js ミドルウェアでサブドメイン識別子を取得するプロセスと、この機能をアプリのアーキテクチャに統合する方法を見ていきます。 具体的な例として、最小限の機能を持つ “Link in Bio” タイプのアプリを構築します。このアプリは Amplify の認証と GraphQL API を使って、個別のサブドメインルートとして即座にアクセス可能なユーザーアカウントを作成します。このアーキテクチャパターンは、ブログ、e コマース、カスタムウェブサイトプラットフォームなど、単一のコードベースで異なるサブドメインにわたって複数の顧客にサービスを提供する様々なマルチテナントアプリに拡張することができます。 ワイルドカードサブドメインを使った Next.js アプリのデプロイ 前提条件 ワイルドカードサブドメインを利用するために必要なものは以下の通りです。 アプリに使用するカスタムドメイン このドメインの DNS 設定へのアクセス まず、ワイルドカードサブドメインを利用した Next.js SSR アプリを AWS Amplify Hosting にデプロイします。このセットアップにより、アプリは動的に *.example.com のリクエストを処理できるようになります。アスタリスク (“*”) は、リクエストに含まれる有効な値のどれにもマッチします。 デプロイには GitHub を使うので、コードの変更を GitHub リポジトリにプッシュし、Amplify Hosting CI/CD を使ってアプリを作成し、リポジトリに接続してアプリをビルドします。 新しい Next.js アプリの作成 まず、 create-next-app を使用してデフォルトの Next.js SSR アプリを作成します。このアプリは App Router を使用します。 npx create-next-app@latest with-wildcard-subdomains --app 参考までに、以下は package.json です。プロジェクトの構成は SSR 用にする必要があります。 scripts セクションは以下のようにします。 { "name": "with-wildcard-subdomains", "version": "0.1.0", "private": true, "scripts": { "dev": "next dev", "build": "next build", "start": "next start", "lint": "next lint" }, "dependencies": { "next": "^14.0.1", "react": "^18", "react-dom": "^18" }, "devDependencies": { "@types/node": "^20", "@types/react": "^18", "@types/react-dom": "^18", "autoprefixer": "^10", "eslint": "^8", "eslint-config-next": "13.5.6", "postcss": "^8", "tailwindcss": "^3", "typescript": "^5" } } GitHub に新しいリポジトリを作成し、新しく作成されたプロジェクトをそれにプッシュします。 Amplify Hosting で新しいアプリをデプロイする Amplify Hosting の Host a web app フローを使用します。アプリを作成する際にいくつか設定します。 まず、GitHub アカウント内のアプリのリポジトリに接続します。接続すると、Amplify Hosting があなたのアカウントのリポジトリをフォークし、デプロイを確認するよう求めます。 アプリが サーバーサイドレンダリングデプロイメント として認識されていることを確認します。ビルドコマンドは npm run build 、 baseDirectory の値は .next になっている必要があります。 サーバーサイドレンダリングのログ用の IAM ロールを選択または作成します。これにより、Amazon CloudWatch にサーバーサイドのログを収集することができます。したがって、React Server Components や API ルート内の任意の console.log はあなたのアカウントにログ出力されます。 Build image settings セクションで、これが初めてのデプロイであればカスタムビルドイメージの値として amplify:al2023 を使用します。アプリがすでにデプロイされている場合は、ドロップダウンから Amazon Linux 2023 イメージを選択します。 Next をクリックしてアプリをデプロイします。アプリはフルスタックの SSR アプリをビルドしてデプロイします。サーバーサイドのコンピュートランタイムのランタイム環境は、ビルド時に使用されたランタイムと一致します。 CI/CD パイプラインが完了した後、アプリは amplifyapp.com ドメインでホストされます。次に、カスタムドメインを追加します。 ワイルドカードサブドメインの設定 カスタムドメインの設定 ナビゲーションペインで、 App Settings &gt; Domain management を選択します。カスタムドメインを追加し、設定します。 注: 例として、 example.com をドメインとして使用しています。ここではあなたが所有している、あるいはDNS レコードの更新が可能であるドメインを使用してください。 ワイルドカードサブドメインを追加するには、Add をクリックし、値としてアスタリスク * を入力します。このシナリオでは、 www.example.com へのリクエストはメインブランチにマッピングされます。さらに、他の任意のサブドメイン値もアスタリスクによってマッチされ、メインブランチへのトラフィックをマッピングします。 所有権を確認するために DNS を更新します。数分後、Amplify Hosting はドメインの SSL を作成し、設定します。 これが完了したら、設定したサブドメイン用にさらに 2 つの CNAME レコードを追加する必要があります。DNS で設定して完了すると、カスタムドメインのステータスは Available に切り替わります。 ワイルドカードサブドメインが稼働しました！アプリはどのサブドメイン値でもアクセス可能です。ユーザーがアプリにアクセスすると、アプリのミドルウェアはアプリのインデックスページにルーティングします。デプロイ後、 www 以外の任意のサブドメイン値にアクセスしてみてください。メインルートのインデックスページにリダイレクトされます。 上記の手順を踏むことで、Next.js アプリは動的なサブドメインを扱えるようになり、SaaS タイプのアプリに最適な形となります。 次のステップ – Link-in-Bio アプリの構築 ブランチをデプロイし、カスタムドメインとワイルドカードサブドメインを設定したので、最小限の機能を備えた “Link in Bio” アプリを作成する準備ができました。このアプリは、ユーザーが独自のユーザー名でサインアップし、サブドメイン（例: &lt;username&gt;.&lt;domain&gt;.com ）経由で個人の Bio ページにアクセスし、動的にプロフィールにリダイレクトできるようにするものです。 サブドメインのパースとリクエストのリダイレクトを処理するために、Next.js のミドルウェアを使用します。この機能により、Next.js アプリ内でリクエストをインターセプトして変更することができます。さらに、Amplify JS とプリビルドの Amplify UI Authenticator コンポーネントを使用したユーザー認証を統合します。 これを実行するために、以下の手順に従います。 Amplify CLI を使用して Amplify バックエンドを作成し、Next.js プロジェクトにプルする Amplify Auth を追加する データの永続化のための GraphQL API を追加する ユーザーがアプリにサインアップし、ダイレクトナビゲーション用のユーザー名を選択できるようにする サブドメインをキャプチャし、正しいページにリクエストを書き換えるためのミドルウェアを追加する アプリの Get Started &gt; Backend environments タブをクリックして、アプリの Amplify バックエンドを有効にします。 Local setup instructions を使って、Amplify バックエンドをローカル環境にプルします。 amplify pull --appId &lt;app-id&gt; --envName staging プロンプトが表示されたら、手順に従って Amplify Studio にログインし、ローカルのフロントエンドアプリを新しい Amplify バックエンドにリンクします。コマンドラインに戻った後、プロンプトの選択を行い、最後に次のように入力します。 Do you plan on modifying this backend? Yes これで、アプリの構築を続けることができます。 アプリの構造 必要な機能を追加するために、App Router を使用する Next.js 14 アプリの構造を変更します。更新内容は以下の通りです。 Amplify Authenticator を /login ルートに統合し、ユーザー登録、ログイン、プロフィール更新を可能にする ユーザーが Bio プロフィール情報を更新できる BioForm コンポーネント /users/[username] ルートはリクエストを受けるルートになります。ユーザーのサブドメインが [username] に一致した場合、リクエストはここに向けられます。 middleware.ts はリクエストのインターセプトと正しいパスへのマッピングを処理します . +├── amplify/ ├── app/ +│ ├─ (auth)/ +│ │ └─ login/ +│ │ ├─ BioForm.tsx +│ │ └─ page.tsx +│ │ +│ ├─ users/ +│ │ └─ [username]/ +│ │ └─ page.tsx │ ├─ layout.tsx │ ├─ page.tsx │ └─ ... +├── middleware.ts ├── node_modules/ ├── public/ ├── next.config.js ... └─ README.md Amplify Auth の追加 Amplify Auth を追加します。サインインメカニズムとして username を選択します。 amplify add auth GraphQL API の追加 ユーザーの概念ができたので、ユーザーが自分の Bio ページに表示するデータを永続化するための API を追加します。Bio の説明と Bio リンクを保持するための最小限のデータモデルを持つ GraphQL API を追加します。 amplify add api schema.graphql に User スキーマを追加します。これにより、ユーザーは自分のプロフィールレコードを作成、読み取り、更新することができると同時に、プロフィールへの公開アクセスも可能になります。 type User @model @auth(rules: [{ allow: public, operations: [read] }, { allow: owner }]) { id: ID! username: String! @index(name: "byUsername", queryField: "byUsername") description: String link: String } 変更をプッシュします。これにより、以前の Auth の変更もプッシュされます。 amplify push UI の作成 次に、Amplify JS と Amplify UI ライブラリを統合します。これにより、アプリは先ほどプロビジョニングされたクラウドリソースを使用できるようになります。ユーザー登録には &lt;Authenticator&gt; コンポーネントを使用します。さらに、Amplify JS ライブラリはミューテーションとクエリを通じて GraphQL API と連携します。 UI の構築を始めるために、以下の依存関係をインストールします。 npm install aws-amplify@6 npm install @aws-amplify/ui-react 認証の追加 デフォルトの Authenticator は、 追加のフィールドレベル検証 とともに使用されます。ユーザー名はサブドメイン参照にもなるため、 subdomainRegex を使って検証されます。 "use client"; // ...imports... export default function App() { return ( &lt;div&gt; &lt;Authenticator initialState="signUp" components={{ SignUp: { FormFields() { return ( &lt;&gt; &lt;Authenticator.SignUp.FormFields /&gt; &lt;/&gt; ); }, }, }} services={{ async validateCustomSignUp(formData) { // this is important if (!formData.username) { return { acknowledgement: "Username is invalid.", }; } // match subdomain pattern const subdomainRegex = /^[a-z0-9]+(?:-[a-z0-9]+)*$/; // check if subdomain is valid if (!subdomainRegex.test(formData?.username)) { return { acknowledgement: "Username is invalid.", }; } }, }} &gt; {({ signOut, user }) =&gt; ( &lt;div&gt; &lt;main&gt; &lt;h1&gt;Hello, {user?.username}.&lt;/h1&gt; &lt;div&gt; &lt;button onClick={signOut}&gt;Sign out&lt;/button&gt; &lt;/div&gt; &lt;/main&gt; &lt;/div&gt; )} &lt;/Authenticator&gt; &lt;/div&gt; ); } 新しいルートで Authenticator が設定されると、アカウントを作成する前やアプリでサインインする前に、以下のようなビューが app.&lt;domain&gt;/login ルートに表示されます。 そして、ユーザー名でサインインした後は以下のようになります。（例: stephen ） プロフィール Bio フォームの追加 ユーザーのBio ページで公開するために、ユーザーの説明とリンクフィールドを取得する簡単なフォームを追加します。 最初はユーザーのユーザー名のみ持っているため、このフィールドは GraphQL API で簡単に検索できるようにフォームにあらかじめ入力されています。GraphQL API はユーザー名にインデックスを持つことでこれを実現します。 新しいコンポーネント BioForm.tsx を作成し、既存のログインページに含めます。最小限のバージョンは以下のようになります。 // /app/(auth)/login/BioForm.tsx "use client"; import { useEffect, useState } from "react"; import type { FormEvent } from "react"; import { Amplify } from "aws-amplify"; import { createUser, updateUser } from "@/src/graphql/mutations"; import * as queries from "@/src/graphql/queries"; import { getCurrentUser } from "@aws-amplify/auth"; import { generateClient } from "aws-amplify/api"; import awsExports from "@/src/aws-exports"; Amplify.configure(awsExports); const client = generateClient(); export default function BioForm() { const [loggedInUser, setLoggedInUser] = useState&lt;any&gt;(null); const [userProfile, setUserProfile] = useState&lt;any&gt;(null); const [userProfileExists, setUserProfileExists] = useState&lt;boolean&gt;(false); async function onSubmit(event: FormEvent&lt;HTMLFormElement&gt;) { event.preventDefault(); const form = new FormData(event.currentTarget); const description = form.get("description") || userProfile?.description; const link = form.get("link") || userProfile?.link; if (userProfileExists) { await onUpdate({ id: userProfile?.id, username: loggedInUser?.username, description, link, }); } else { await onCreate({ username: loggedInUser?.username, description, link, }); } } // include mutation handlers to update user profile const onCreate = async (formData: { username: string; description: string; link: string; }) =&gt; { const { username, description, link } = formData; const input = { username, description, link }; await client.graphql({ query: createUser, variables: { input }, authMode: "userPool", }); }; const onUpdate = async (formData: { id: string; username: string; description: string; link: string; }) =&gt; { const { id, username, description, link } = formData; const input = { id, username, description, link }; await client.graphql({ query: updateUser, variables: { input }, authMode: "userPool", }); }; const getUserProfile = async (username: string) =&gt; { return await client.graphql({ query: queries.byUsername, variables: { username }, authMode: "userPool", }); }; useEffect(() =&gt; { const getUser = async () =&gt; { const user = await getCurrentUser(); if (user) { setLoggedInUser(user as any); const { data } = await getUserProfile(user?.username); const profile = data?.byUsername?.items[0]; if (profile) { setUserProfileExists(true); setUserProfile(profile as any); } } }; getUser(); }, []); return ( &lt;form onSubmit={onSubmit}&gt; &lt;div&gt; &lt;input type="text" name="username" id="username" value={loggedInUser?.username} disabled={true} /&gt; &lt;/div&gt; &lt;div&gt; &lt;textarea name="description" id="description" /&gt; &lt;/div&gt; &lt;div&gt; &lt;label htmlFor="link"&gt;Link&lt;/label&gt; &lt;input type="url" name="link" id="link" /&gt; &lt;/div&gt; &lt;div&gt; &lt;button type="submit"&gt; {userProfileExists ? "Update" : "Create"} &lt;/button&gt; &lt;/div&gt; &lt;/form&gt; ); } 現在のログインページを更新して、新しいコンポーネントを含めます。これで、ユーザーがログインすると、プロフィールフォームが表示されます。 Link-in-Bio ページの作成 エンドユーザーがユーザー名サブドメインのルートにアクセスすると、リクエストは /users ルートに書き換えられます。ユーザー名は、ユーザーのプロフィールを取得して表示するための動的パラメーターとして機能します。この機能を実装するために、 app/users/[username]/page.tsx でユーザーの Bio プロフィール情報を表示する公開ページを作成します。Next.js のルートパラメーターを使用して、Amplify JS でユーザーのプロフィールをクエリできます。以下は例です。 const { data } = await client.graphql({ query: queries.byUsername, variables: { username }, }) ミドルウェアによるマルチテナントルーティング これは、サブドメインでマッチングし、リクエストを正しいアプリページに書き換えるための middleware.ts ハンドラの例です。リクエストは、サブドメイン値を含む場合には適切なユーザープロフィールページにルーティングされ、ログインページは app. サブドメインで提供されます。 import { NextRequest, NextResponse } from "next/server"; export const config = { matcher: [ /* * Match all paths except for: * 1. /api routes * 2. /_next (Next.js internals) * 3. /_static (inside /public) * 4. all root files inside /public */ "/((?!api/|_next/|_static/|[\\w-]+\\.\\w+).*)", ], }; export default async function middleware(req: NextRequest) { const url = req.nextUrl; const hostname = req.headers.get("host")!; const path = url.pathname; let subdomain = hostname.split(".")[0]; subdomain = subdomain.replace("localhost:3000", ""); // handle no subdomain or www with base path if ((subdomain === "www" || subdomain === "") &amp;&amp; path === "/") { return NextResponse.rewrite(new URL("/", req.url)); } // profile login if (subdomain === "app" &amp;&amp; path === "/login") { return NextResponse.rewrite(new URL("/login", req.url)); } // subdomains if (subdomain !== "app") { return NextResponse.rewrite( new URL(`/users/${subdomain}${path === "/" ? "" : path}`, req.url) ); } return NextResponse.next(); } これで、アプリがリクエストを受け取ると、ミドルウェアは以下を行います。 パスに “app” のサブドメインと /login のパスがあるかどうかを確認する “app” に一致しないサブドメインをチェックする または、元のリクエストをそのまま渡すようにフォールバックする これで、ユーザーが作成された後、ユーザープロフィールページが稼働します！例えば、 stephen.localhost:3000 にアクセスすると、ユーザーが存在する場合にはプロフィールページが表示されます。 Hosting へのプッシュとデプロイ 更新されたアプリをデプロイするために、フロントエンドとバックエンドの両方の変更を含めて、まず Git リポジトリに変更をプッシュします。アプリに設定された IAM サービスロールを更新して、Amplify バックエンドのビルドを許可する必要があります。これは App settings &gt; General の設定で更新できます。 それが完了したら、フロントエンドをバックエンドにリンクして、継続的デプロイメントを有効にします。 App settings &gt; Build image settings で、Amplify CLI のバージョンに適した Live Package Updates を選択します。 これで、コミットをプッシュすると、フロントエンドとバックエンドがデプロイされます。 クリーンアップ 最後に、不要になったアプリを削除します。これを行うには、このアプリの Amplify Hosting Console の App settings &gt; General に移動し、 Delete app をクリックします。また、別のアプリに再利用する場合は、ドメインから DNS レコードを削除してください。 まとめ ワイルドカードサブドメインを使用することは、Amplify Hosting 上でマルチテナントアーキテクチャを拡張する効果的な方法です。動的なアプリや SSR アプリにワイルドカードサブドメインの設定を統合することで、SaaS アプリの拡大に合わせて、最小限の設定でカスタマイズされた体験を提供することができます。 詳細については、Amplify Hosting のドキュメントの Wildcard subdomains をご覧ください。 本記事は、 Wildcard Subdomains for Multi-tenant Apps on AWS Amplify Hosting を翻訳したものです。翻訳はソリューションアーキテクトの 都築 が担当しました。

Amazon CloudFront は、静的コンテンツと動的コンテンツを、低レイテンシーかつ高速な転送速度でセキュアに配信することを可能にします。CloudFront Functions では、1 秒あたり何百万ものリクエストにレイテンシーの影響を受けやすいカスタマイゼーションを実行できます。例えば、CloudFront Functions は、ヘッダーの変更、キャッシュキーの正規化、URL の書き換え、またはリクエストの承認を実行するために使用できます。 11月21日は、 CloudFront KeyValueStore を皆さんにご紹介します。CloudFront KeyValueStore は、CloudFront Functions 内からの読み取りアクセスを可能にするセキュアでグローバルな低レイテンシーキーバリューデータストアで、高度なカスタマイズ対応のロジックを CloudFront エッジロケーションで実行できるようにします。 これまで、設定データは関数コード内に埋め込む必要がありました。例えば、URL をリダイレクトするべきかどうか、およびビューワーをどの URL にリダイレクトするかを判断するためのデータです。設定データを関数コードに埋め込むと、設定を少し変更するだけでも、そのたびにコード変更を行って、関数コードを再デプロイする必要があります。新しいルックアップが追加されるたびにコードを更新してデプロイすることにより、コードを誤って変更するリスクが生じます。また、 最大関数サイズは 10 KB であるため、多くのユースケースにおいて、すべてのデータをコード内に収めることが困難になります。 CloudFront KeyValueStore を使用することで、関数に関連付けられたデータと関数コードを、それぞれ単独に更新できるようになります。この機能は、関数コードを簡素化するとともに、コード変更をデプロイすることなくデータを簡単に更新できるようにします。 では、これが実際にどのように機能するのかを見てみましょう。 CloudFront キーバリューストアの作成 CloudFront コンソール のナビゲーションペインから [関数] を選択します。 [KeyValueStores] タブで、 [KeyValueStore を作成] を選択します。 ここには、 Amazon Simple Storage Service (Amazon S3) バケット内の JSON ファイルからキーバリューペアをインポートするオプションがあります。キーがない状態で始めたいので、今はインポートしません。名前と説明を入力して、キーバリューストアの作成を完了します。 キーバリューストアが作成されたら、 [キーバリューペア] セクションで [編集] を選択してから、 [ペアを追加] を選択します。キーに hello 、値に Hello World と入力して、変更を保存します。キーと値をさらに追加することもできますが、今は 1 つのキーで十分です。 キーバリューストアを更新すると、キーバリューストアに関連付けられている関数がそれを低レイテンシーで使用できるように、変更がすべての CloudFront エッジロケーションに数秒で伝播されます。その仕組みを見てみましょう。 CloudFront Functions からの CloudFront KeyValueStore の使用 CloudFront コンソール のナビゲーションペインから [関数] を選択し、次に [関数を作成] を選択します。関数の名前を入力してから、 cloudfront-js-2.0 ランタイムを選択して、関数の作成を完了します。次に、キーバリューストアをこの関数に関連付けるための新しいオプションを使用します。 コンソールからキーバリューストア ID をコピーして、以下の関数コードで使用します。 import cf from 'cloudfront'; const kvsId = '&lt;KEY_VALUE_STORE_ID&gt;'; // This fails if the key value store is not associated with the function const kvsHandle = cf.kvs(kvsId); async function handler(event) { // Use the first part of the pathname as key, for example http(s)://domain/&lt;key&gt;/something/else const key = event.request.uri.split('/')[1] let value = "Not found" // Default value try { value = await kvsHandle.get(key); } catch (err) { console.log(`Kvs key lookup failed for ${key}: ${err}`); } var response = { statusCode: 200, statusDescription: 'OK', body: { encoding: 'text', data: `Key: ${key} Value: ${value}\n` } }; return response; } この関数は、リクエストのパスの最初の部分をキーとして使用し、キーの名前とその値を使って応答します。 変更を保存して関数を発行します。関数の [発行] タブで、先ほど作成した CloudFront ディストリビューションに関数を関連付けます。 [ビューワーリクエスト] イベントタイプと、 [デフォルト (*)] キャッシュ動作を使用して、ディストリビューションに対するすべてのリクエストをインターセプトします。 コンソールにある関数のリストに戻り、関数がデプロイされるのを待ちます。次に、コマンドラインから curl を使用して、ディストリビューションからコンテンツをダウンロードし、関数の結果をテストします。 まず、関数を呼び出して、先ほど作成したキー ( hello ) をルックアップするパスをいくつか試してみます。 curl https://distribution-domain.cloudfront.net/hello Key: hello Value: Hello World curl https://distribution-domain.cloudfront.net/hello/world Key: hello Value: Hello World 機能していますね! 次に、別のパスを試して、キーが見つからなかった場合に、コードで使用しているデフォルト値が返されることを確認します。 curl https://distribution-domain.cloudfront.net/hi Key: hi Value: Not found この最初の例が機能するのを確認したところで、次はもっと高度で便利な関数を試してみましょう。 CloudFront KeyValueStore 内の設定データを使用した URL の書き換え CloudFront が実際のリクエストの実行で使用する必要があるカスタムパスをキーバリューストアでルックアップするために、HTTP リクエスト内の URL のコンテンツを使用する関数を作成してみましょう。この関数は、ウェブサイトの一部である複数のサービスを管理するために役立ちます。 例えば、私のウェブサイトに使用しているブログプラットフォームを更新したいとします。古いブログにはオリジンパス /blog-v1 があり、新しいブログにはオリジンパス /blog-v2 があります。 最初は、まだ古いブログを使っています。CloudFormation コンソールで、 blog-v1 という値を持つキーバリューストアに blog キーを追加します。 次に、以下の関数を作成してから、ディストリビューションに対するすべてのリクエストをインターセプトするために [ビューワーリクエスト] イベントと [デフォルト (*)] キャッシュ動作を使用するディストリビューションにその関数を関連付けます。 import cf from 'cloudfront'; const kvsId = "&lt;KEY_VALUE_STORE_ID&gt;"; // This fails if the key value store is not associated with the function const kvsHandle = cf.kvs(kvsId); async function handler(event) { const request = event.request; // Use the first segment of the pathname as key // For example http(s)://domain/&lt;key&gt;/something/else const pathSegments = request.uri.split('/') const key = pathSegments[1] try { // Replace the first path of the pathname with the value of the key // For example http(s)://domain/&lt;value&gt;/something/else pathSegments[1] = await kvsHandle.get(key); const newUri = pathSegments.join('/'); console.log(`${request.uri} -&gt; ${newUri}`) request.uri = newUri; } catch (err) { // No change to the pathname if the key is not found console.log(`${request.uri} | ${err}`); } return request; } ここで、URL パスの先頭に blog と入力すると、リクエストが実際に blog-v1 パスに送られます。 blog-v1 は古いブログで使用されるオリジンパスであるため、CloudFront は古いブログに対して HTTP リクエストを行います。 例えば、ブラウザに https://distribution-domain.cloudfront.net/blog/index.html と入力すると、古いブログ (V1) が表示されます。 コンソールで、 blog-v2 という値で blog キーを更新します。数秒後に同じ URL にアクセスすると、今度は新しいブログ (V2) が表示されます。 ご覧のとおり、パブリック URL は同じですが、コンテンツが変更されています。より全般的に言うと、この関数は 2 つのブログバージョン間で URL が変更されないことを前提としています。 これで、私のウェブサイトの一部であるさまざまなサービスのキー (blog、support、help、commerce など) をさらに追加して、正しい URL パスを使用するための値を各キーに設定できるようになりました。そのうちの 1 つに新しいバージョンを追加するとき (新しいコマースプラットフォームに移行するなど) は、新しいオリジンを設定し、対応するキーを新しいオリジンパスを使用するように更新できます。 これは、コードから設定データを分離するときに得られる柔軟性の一例に過ぎません。すでに CloudFront Functions を使用している場合は、CloudFront KeyValueStore を使用してコードを簡素化できます。 知っておくべきこと CloudFront KeyValueStore は、11月21日から世界中のすべてのエッジロケーションでご利用いただけます。CloudFront KeyValueStore では、パブリック API からの読み取り/書き込み操作と、CloudFront Functions 内からの読み取り操作に基づく使用量に対する料金のみを支払います。詳細については、「 CloudFront の料金 」を参照してください。 キーバリューストアは、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、および AWS SDK を使用して管理できます。 AWS CloudFormation のサポートも近日提供される予定です。キーバリューストアの最大サイズは 5 MB で、各関数には単一のキーバリューストアを関連付けることができます。キーの最大サイズは 512 バイトです。値のサイズは最大 1 KB にすることができます。キーバリューストアを作成するときは、以下の JSON 構造を持つ Amazon S3 上のソースファイルを使用して、作成中にキーと値のデータをインポートできます。 { "data":[ { "key":"key1", "value":"val1" }, { "key":"key2", "value":"val2" } ] } 作成時にキーと値のデータをインポートしておくと、新しい環境 (テストや開発など) のセットアップを自動化し、1 つの環境から別の環境 (本番前環境から本番環境など) に設定を簡単にレプリケートするために役立ちます。 CloudFront KeyValueStore を使用して、エッジにカスタムロジックを追加する方法を簡素化しましょう。 – Danilo 原文は こちら です。

コマンドラインは、ソフトウェアの記述、ビルド、実行、デバッグ、デプロイのために、3000 万人以上のエンジニアが使用しています。しかし、ソフトウェア開発プロセスにとって重要であるにもかかわらず、コマンドラインは使いにくいことで有名だ。その出力は簡潔で、そのインターフェースは 1970 年代のもので「正しい使い方」についてのヒントは何もない。何万ものコマンドライン・アプリケーション（コマンドライン・インターフェースまたは CLI と呼ばれる）がある中で、正しい入力構文を覚えるのはほとんど不可能だ。コマンドラインには入力の検証機能がないため、タイプミスが不要なエラーやセキュリティリスク、さらには生産停止を引き起こす可能性もある。ほとんどのソフトウェア・エンジニアが、コマンドラインはエラーを起こしやすく、しばしばフラストレーションがたまる経験だと感じているのも不思議ではありません。 コマンドライン用 Amazon CodeWhisperer を発表 Amazon CodeWhisperer for command line は、AI を搭載した生産性向上ツール Amazon CodeWhisperer の新機能と統合セットで、ソフトウェア開発者のコマンドラインでの生産性を向上させます。CodeWhisperer for command line は、パーソナライズされたコード補完、インライン・ドキュメント、AI による自然言語からコードへの翻訳などの機能により、コマンドラインを近代化します。iTerm2 やVSCode 組み込みターミナルなどの既存のツールに直接統合できます。 まずは、 こちらから CodeWhisperer for command line をダウンロードしてください 。（macOS のみ） 500 以上の CLI の IDE スタイルの補完 CodeWhisperer for command line は、Git、npm、Docker、MongoDB Atlas、AWS CLI など、何百もの一般的な CLI に IDE スタイルの補完機能を追加します。これらの入力先読み補完機能により、反復的なコマンドや定型的なコマンドの入力時間を短縮し、生産性を向上させます。インラインドキュメントは、ブラウザにコンテキストを切り替えてワークフローを中断することなく、CLI の機能を理解するのに役立ちます。 以前は、 git のような CLI コマンドを入力してタブを押しても、補完が表示されなかったり、説明のない不便なインターフェイスで補完の不完全なリストが表示されたりしていました。現在では、 git と入力すると、すべての git サブコマンド、オプション、引数を説明付きで、使用頻度の高い順に表示することができます。また、 cd と入力するとすべてのディレクトリのリストが表示され、 npm install と入力するとインストール可能なすべての node パッケージのリストが表示され、 aws と入力すると AWS CLI のサブコマンドのリストが表示されます。 自然言語から bash への変換 CLI の補完はすでにやり方がわかっていて、とにかく早く進めたいタスクには最適です。しかし、ある問題を解決しようとしていて、その方法が100％わからない場合はどうすればいいのでしょうか？ cw ai の登場です！ cw ai コマンドを使えば、自然言語で命令を書くことができ、CodeWhisperer がそれを即座に実行可能なシェルコードスニペットに変換してくれます。例えば、ローカルマシンから Amazon Simple Storage Service (Amazon S3) にファイルをコピーしたいとします。“カレントディレクトリのすべてのファイルを s3 にコピーする” と書くと、CodeWhisperer は aws s3 cp . s3://$BUCKET_NAME —recursive と出力します。自然言語から bash への変換は、 git コミットの取り消し、 grep によるファイル内の文字列の検索、 tar によるファイルの圧縮など、たまにやらなければならないがいつも正しい bash 構文を忘れてしまうようなワークフローに最適です。また、CLI の補完と同様に、 cw ai translator は AWS CLI でも動作します。 はじめるには コマンドライン用の CodeWhisperer は macOS 上で、すべての主要なシェル （bash、zsh、fish）と、ターミナル、iTerm2, Hyper, Visual Studio Code と JetBrains の内蔵ターミナルなどの主要なターミナルエミュレータなどで利用可能です。 はじめるには、コマンドライン用の CodeWhisperer を ここから ダウンロードしてください。詳しくは、 CodeWhisperer のドキュメントをご覧ください。 本記事は Introducing Amazon CodeWhisperer for command line を翻訳したものです。翻訳はソリューションアーキテクトの江口昌宏が担当致しました。

こんにちは、カスタマーソリューションマネージャーの桑原です。この記事では普段お客様から「オンプレからクラウドに移行したいがどのように進めればよいかが分からない」、「既にクラウドを利用しているが、これまで以上にクラウドを活用していきたい」というお声をいただきます。そのような方に向けて AWS のクラウド移行およびクラウド活用の道のり、つまりクラウドジャーニーを進める上でのよくある課題や取り組むべき活動についてご紹介していきます。 昨今のクラウド移行の状況 昨今の取り巻く情勢としてシステム開発および移行する上でクラウド上に構築することはもはや外せない選択肢になっています。 総務省：クラウドサービスの利用状況 では、「クラウドサービスを全社的に利用している」が42.7%、「一部の事業所又は部門で利用している」が27.7%となっております。つまり会社の約70％がクラウドサービスをどこかで利用しており、広く日本全体に普及してきています。また一方で ガートナージャパン：2023年に向けて日本企業が注目すべきクラウド・コンピューティングのトレンドを発表 によると、メインフレームのワークロードをクラウド化など、ミッションクリティカルなシステムをクラウド化にすることが最近のトレンドになっており、クラウドの影響範囲がこれまで以上に拡大しています。これは日々、様々なお客様と接する中で、ビジネスインパクトが大きい基幹・業務システムのクラウド移行を検討・実行されるお客様が増えていることを体感しており、本トレンドの傾向は強いと言えます。参考として、基幹システムの移行に関する AWS 事例は、 基幹・業務システム用途での AWS 国内導入事例 にて確認することができます。 クラウドジャーニーを歩む上で重要な考え方 前述したトレンドの中でより効率的に確実にクラウド移行をするためにはどのようにすればよいのでしょうか？ それはクラウドが普及している状況の下、クラウドジャーニーを歩む上でよくある課題や取り組むべき活動について事前に把握し、先を見据えたクラウド移行の戦略を立案することが賢い進め方です。 クラウド移行戦略を立案するために重要な考え方は、お客様の中期事業計画や組織、チームの方針等からお客様自身のビジネス目標を明確にし、そのビジネス目標に連動する形でクラウド活用による達成したい目標はなにかといったゴールを定めることです。例えば、開発効率化、運用負荷軽減、ビジネスアジリティ向上、高可用性、コスト削減など、ビジネス上の課題や目標からクラウド活用によって達成したい目標を明確にします。つまりビジネス戦略に対してクラウド移行戦略を紐づけることが肝要です。まずは 1 つのプロジェクトで解決したい課題や達成したい目標を設定しましょう。設定した目標はクラウドジャーニーを歩む上で旅路に必要なコンパスの役割となります。クラウドジャーニーのどのフェーズにおいても常に目標を意識し、目標を見失わないように注意してください。 また、立案したクラウド移行戦略に対して積極的に社内のエグゼクティブを巻き込むことも重要です。オンプレからクラウドを移行すると、これまでの慣れ親しんだプロセスの変更や新たなルールを作成することになるため、一部からは反発されることがあるかもしれません。そのような懸念を未然に防ぎ、クラウド推進者の心理的安全性を確保するためにも、クラウド推進する上でのエグゼクティブスポンサーを擁立することがポイントです。 まとめると、ビジネス目標とアラインしたクラウド移行戦略を立てて、エグゼクティブによるスポンサーを確立することでクラウドジャーニーを歩むための地盤は整います。具体的な活動と課題については以降の 4 つのフェーズにてご説明いたします。 クラウドジャーニーの 4 つのフェーズ AWS のクラウド移行およびクラウド活用の道のりであるクラウドジャーニーには４つのフェーズがあります。それぞれのフェーズについてご紹介するとともに各フェーズでの課題と取り組むべき活動について触れていきます。取り組むべき活動については AWS によるご支援が可能ですので、AWS へお問い合わせください。 Assess (評価) フェーズ クラウド移行前に移行によるビジネス価値の整理や移行の準備状況を確認するフェーズになります。このフェーズでは、クラウド移行におけるビジネスメリットやどのシステムから移行を始めたらよいかが分からず具体的なクラウド移行戦略が立てられない、またクラウド移行の準備が現時点でどの程度整っているか分からないといった状況によって、移行作業に手を付け始めることができないという課題に多くのお客様が直面しています。 ビジネスメリットが分からないという課題に対しては、 AWS では AWS Cloud Value Framework (コスト削減、スタッフの生産性、オペレーショナルレジエンス、ビジネスの俊敏性、サステナビリティ) を用いて総所有コスト (TCO : Total Cost of Ownership) の削減以外の視点も含めたビジネス価値を特定することが重要です。これにより、オンプレミスとクラウドとの価値を比較することによって、今後のクラウド推進のための理由付けになります。なお、前述した「クラウドジャーニーを歩む上で重要な考え方」で述べたクラウド活用による目標の設定に資する情報になりますので、参考にしてください。 クラウド移行戦略が立てられないといった課題に対しては、クラウド移行候補のサーバーやシステムに関わる各種情報を収集することで、クラウド未対応のレガシー OS やミドルウェア、アプリの有無などといった技術課題の特定やシステム停止に伴うビジネスの影響度に応じた移行優先度並びに移行対象を確認することができます。そして、これらの情報を踏まえ、どのようにオンプレミスからクラウドへ移行すればよいのかといった 移行パス (7R) を選択することができるようになるため、より具体的なクラウド移行戦略を立案することができます。AWS では収集した情報から移行の優先度や移行パスを提案するご支援も可能ですので効率的に情報の整理を進めていただくことができます。 クラウド移行の準備がどの程度整っているか分からないといった課題に対しては、 AWS Cloud Adoption Framework (AWS CAF) を活用してお客様が認識できていない課題を含めた現状を確認していただくことが重要と考えています。現状の確認から不足部分を明確にして対策をすることで移行準備を前に進めることができます。 このように移行による効果や準備状況を多面的に確認して対策をすることで、足踏みしている状態から一歩踏み出して移行のフェーズを進めていくことができます。 Mobilize (移行準備) フェーズ Assess（評価）フェーズで収集した情報を基にクラウド移行計画を立案し、移行準備を行うフェーズになります。クラウド移行準備を網羅的に確認するためにはフレームワークを適用することが重要です。先ほどご紹介した AWS CAF には効果的にクラウド導入を進めるために検討するべき６つのパースペクティブ (観点) があり、それらを構成する AWS CAF の 基本的な機能 があります。各機能を全て具備することがクラウド導入における網羅的な準備であるとも言えますが、これらをすべて実装しないと移行ができないということではありません。各機能を参考にしながらお客様の状況に合わせて優先順位を付けつつ、バランスを取りながら並行的に進めていくことが必要です。 本ブログでは、移行準備をする上で特に重要と考える課題と取り組むべき活動についてご紹介します。 お客様には予算とリソースをどのくらい確保するかなどを策定するクラウド移行計画が立てられないという課題をお持ちのお客様もいらっしゃいます。主な要因として挙げられるのはナレッジ不足や経験不足です。この課題に対して各種学習やハンズオンなどを実施して補うことは良いアプローチですが、最も重要なのがまずは小さく始めてみることです。具体的には PoC や比較的影響が少ないプロジェクトを選定してパイロット移行を複数回行うことによって実体験から移行スキルや経験を積むことをお勧めします。プロジェクトメンバーの役割を問わず、実際に手を動かして初めて分かることが多いため、移行を経験することでクラウド移行計画を段階的に立案することができるようになりますし、その後の移行が加速する効果が見られます。 また、蓄積したクラウドスキルやノウハウを一箇所に集めて、効率的なナレッジ共有をするためには、クラウド専門家組織としての CCoE を設立 することによって、より効果的なクラウド推進をすることができます。 一方で社内ステイクホルダーへの周知ができているか、作成したクラウド基盤の設計が正しいのかといった準備を計画的にすることも重要です。社内ステイクホルダーへの周知は、移行対象システムの関係者や全ての責任者を明確にした上で早い段階からクラウド移行による価値や移行計画について会話しプロジェクトに巻き込んでいただくことが円滑に進める上でのポイントとなります。クラウド基盤の設計の妥当性ついては、 AWS Well-Architected をプロジェクト立ち上げの早い段階で読んでいただき、クラウドを効果的に活用するためのベストプラクティスに沿っているのかを確認いただくことをお勧めします。AWS にご相談いただけれればサポートさせていただくことも可能ですし、お客様自身で AWS Well-Architected Tool を利用して AWS のベストプラクティスかどうかを確認することも可能です。 まとめ 前編では昨今のクラウド移行の状況、クラウドジャーニーを進める上での考え方、クラウドジャーニーの Assess (評価) フェーズと Mobilize (移行準備) フェーズにおける課題と取り組むべき活動を説明してきました。後編ではクラウドジャーニーの Migration (移行) フェーズと Modernization (モダナイゼーション) フェーズにおける課題と取り組むべき活動についてご紹介します。お楽しみに！ 著者プロフィール アマゾン ウェブ サービス ジャパン 合同会社 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー 桑原 直哉 アマゾン ウェブ サービス ジャパン 合同会社 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー 服部 昌克 参考リンク 総務省：クラウドサービスの利用状況 ガートナージャパン：2023年に向けて日本企業が注目すべきクラウド・コンピューティングのトレンドを発表 基幹・業務システム用途での AWS 国内導入事例 AWS Cloud Value Framework マイグレーションを実現するために – 第 2 回 : 移行戦略と移行パスとは ? AWS Cloud Adoption Framework (AWS CAF)&nbsp; AWS Cloud Adoption Framework (AWS CAF) – 基本的な機能 – 今から始める CCoE、3 つの環境条件と 3 つの心構えとは AWS Well-Architected AWS Well-Architected Tool

AWS Amplify は、フロントエンド開発者が既存の TypeScript や JavaScript のスキルでフルスタックアプリを素早く構築しデプロイできるようにする、新しいコードファーストの開発者エクスペリエンスのパブリックプレビューを発表しました。このツールの第一世代は、CLI/コンソールベースのインタラクティブなワークフローを使用してバックエンドを作成する、ツールファーストのエクスペリエンスを提供していました。第 2 世代ではコードファーストの開発者体験に移行し、開発者はデータモデル、ビジネスロジック、認証ルールなどのアプリ要件を TypeScript で簡潔に表現できるようになります。必要なクラウドインフラは、宣言されたアプリコードに基づいて自動的にデプロイされるため、開発者は AWS サービスを明示的に設定する必要がありません。 このコードファーストのアプローチへのシフトは、開発者コミュニティからのフィードバックを収集した結果です。本記事では、このフィードバックを共有し、より柔軟な盛業、より速いイテレーション、より良いチームワークフローを提供する、アプリのバックエンドを構築するためのコードファーストな開発者体験 (Gen 2) を提供するために、どのようにインスパイアされたかを掘り下げます。 もしあなたが実践的に学びたい場合は、 クイックスタートガイド で始めてから、本記事に戻ってきてください。 AWS Amplify の進化 第 2 世代を紹介する前に、私たちがどのようにしてここまで来たかを説明します。 2017 年 11 月（豆知識：Amplify は 6 歳になりました！）、私たちは AWS Amplify を立ち上げました。当初はオープンソースの JavaScript ライブラリで、クラウドに接続されたモバイルアプリやウェブアプリを簡単に開発できるようにしました。 2018 年 8 月には、開発者がアプリのバックエンドを構築し、ウェブアプリやモバイルアプリに統合するためのコマンドラインツールである Amplify CLI を発表しました。 2020 年 12 月には、開発者がバックエンドを構築するためのビジュアルインターフェースを提供する Amplify Studio (旧称 Admin UI) を発表しました。そして、2021 年 12 月には、Figma-to-React 機能とフォーム生成機能によって、Amplify Studio の体験に UI 構築を追加しました。 スタートアップから大企業に至るまで、何十万ものお客様が、Web およびモバイルアプリの構築、デプロイ、ホスティングに Amplify を利用してきました。これらの企業は、Web およびモバイルアプリケーションの構築、デプロイ、ホスティングにおけるフルスタック開発の取り組みを大幅に加速させています。 お客様からのフィードバック 私たちは X (旧: Twitter), GitHub, Discord チャンネルを通じて、1:1 またはオンラインで多くのお客様からフィードバックをいただきました。 お客様からは、Amplify CLI と Studio の抽象化された機能が、ズルをしているような感覚で、とても速く実行できるところが気に入っていると言っていただいています。これは通常、根底にある「マジック」をより深く掘り下げることへの強い関心と結びついています。お客様は、 amplify add auth やビジュアルデータモデリングのような直感的な CLI コマンドから、コードリポジトリ内の AWS CloudFormation JSON や設定ファイルの生成への移行について、より深い理解を求めています。これは、バックエンドを変更して、Amplify が現在サポートしていない機能を実装しようとするときに、特に重要になります。 ローカルで開発している間、お客様は変更を検証するためのより速いフィードバックループを求めています。お客様はまた、チームメンバーの環境に干渉するリスクなしに、アプリケーションスタックを反復できることを望んでいます。 お客様は、Amplify CLI のビルトイン環境機能と、Amplify CI/CD ワークフローとの密接な統合が、Amplify を選んだ理由だと言っています。お客様は、本番環境へのロールアウトを簡素化し、トランクベースのワークフローを採用するためのワークフローの改善を望んでいます。 お客様の多くは AWS 初学者であり、一貫してフルスタックアプリケーション開発のために Amplify が提供している機能をどれほど評価しているかを共有しています。お客様はアプリケーション開発を始めるときに、様々な Amplify ツール (例えば、Amplify Console, Hosting, Studio、CLI) が、フルスタックアプリケーションの構築とデプロイのニーズを達成するためにどのように組み合わされているかを理解するのに時間がかかると言っています。 ソリューション このフィードバックをまとめると、ローカルでの開発体験からチームコラボレーションまで、エンドツーエンドの開発者体験を再構築する必要があることがわかりました。私たちの目標は、開発者がゼロからデプロイされたアプリケーションを素早く開発できるようにすること、MVP から本番環境に移行する際に複雑な機能セットをサポートすること、幅広いチームワークフローをサポートすることなど、既存の Amplify ツールの強みを維持することでした。さらに、お客様は次のようなことを望んでいます。 バックエンドの生成方法の透明性を高め、ローカル開発時に実装のカスタマイズや問題のデバッグを行いたい。 ローカル開発中にチームメンバーの環境に干渉することなく変更を検証するための、より迅速な反復サイクル。 下位環境から上位環境へコード変更をマージする際、本番ロールアウトを確実に行いたい。また、チームの運用方法を反映したデプロイメント・ワークフローにより、チームの好みに基づいてコードを柔軟に整理したい。 Amplify と AWS にオンボーディングする新規開発者が、すでに使い慣れたツール (TypeScript と Git) を使って作業を進められるよう、コンセプト数を削減したい。デプロイされたクラウドリソースのビルトイン管理。 これらのリクエストに応えるため、ローカル開発とチームコラボレーションを改善する多くの新機能を導入します。 1. CDK L3 コンストラクタで構築された TypeScript ファーストの Data と Auth 用の @aws-amplify/backend ライブラリ AWS Cloud Development Kit (AWS CDK) を使って構築された新しいライブラリを発表します。TypeScript によって、開発者はバックエンドを記述する際に、コード補完、インテリセンス、インラインドキュメントを見ることができます。特にデータに関しては、Gen 1 の schema.graphql データモデリングエクスペリエンスの完全に型付けされたバージョンを導入しました。強力な型付けにより、開発者はデータモデルを構築する際に検証エラーをキャッチすることができます。バックエンドのコードに変更があった場合、即座に同じ場所にあるフロントエンドのコードに型エラーが反映されます。 2. ファイルベースの規約 TypeScript ライブラリとファイルベースの規約を組み合わせることで、開発者はプロジェクト構造に最小限のフットプリントでフルスタックアプリの構築を開始できます。ファイルベースの規約は、開発者がバックエンドを記述する際の透明性と予測可能性を提供します。ユースケースごとにリソースを個別のファイルにグループ化することで、開発者は共通のリソース定義がどこにあるかを正確に把握することができます。 3. 開発者ごとのクラウドサンドボックス環境 チーム内のすべての開発者は、作業するアプリごとに自分の開発者サンドボックス環境を得ることができます。サンドボックスはマシン上でローカルに実行され (localhost サーバーに似ています)、Amplify プロジェクトの変更を監視することが出来ます。保存されたコード変更はすべて自動的に同期され、ローカル環境からクラウドにデプロイされる。サンドボックスのデプロイは、より速い反復のために最適化されています。私たちは、一般的な変更（データベーススキーマ、リゾルバコード、関数コードなど）のデプロイ時間を数分から数秒に短縮しました。 4. 統合管理コンソール Amplify Gen2 コンソールは、Amplify Studio と Amplify Hosting の開発者体験を統合し、お客様がビルド、ホスティング設定 (カスタムドメインなど)、デプロイ済みリソース（データブラウザやユーザー管理など）、環境変数やシークレットを管理するための単一の場所を提供します。 5. フルスタックの Git ブランチ Amplify はフルスタックのブランチデプロイメントを提供し、フィーチャーブランチからのインフラストラクチャやアプリケーションコードの変更を自動的にデプロイできるようになりました。すべてのチーム環境が Git ブランチと 1 対 1 でマッピングされるため、Amplify でブランチをデプロイする際に開発者が学ぶ必要のある概念数が減ります。 6. AWS CDK によるバックエンドの拡張 私たちのバックエンド構築の経験全体が AWS Cloud Development Kit (AWS CDK) L3コンストラクトにレイヤー化されているため、AWS サービスを利用したいお客様は、プロジェクト内で AWS CDK L1 または L2 コードをインラインで記述するだけで利用することができます。例えば、Amazon Location Service をバックエンドに追加したいお客様は、 custom/geo/resource.ts ファイルを追加し、CDK コードをインラインで使用することができます。 7. データに対するフォームの生成 開発者は、ターミナルで 1 つのコマンド ( amplify generate forms ) を実行するだけで、データモデルに対してReact フォームを生成することが出来ます。フォームは完全にカスタマイズ可能で、ライフサイクル管理ができ、コード内のカスタム検証ロジックをサポートします。 8. モノレポとマルチレポのサポート Amplify の CI/CD は、Nx やYarn Workspaces のようなツールを含め、モノレポでコードを管理するチームとうまく機能します。また、バックエンドのみの CI/CD もサポートしており、フロントエンドとバックエンドのチームが別々にリポジトリを管理することができます。 9. カスタムパイプライン Gen 2 はカスタムデプロイメントパイプラインを統合する機能を提供し、GitHub Actions, AWS CodePipeline、または Amazon CodeCatalyst を使用して、リージョンまたは AWS アカウント間でフルスタックアプリをデプロイできます。これにより、トランクベースのデプロイメントをステージやマルチアカウントで設定できるようになります。カスタムパイプラインの詳細については、 ドキュメント を参照してください。 10. シークレットの一元管理 Gen 2 は、すべてのフルスタックブランチに対して、シークレットと環境変数の集中管理を提供します。シークレットを使うことで、ソーシャルサインインキー、関数環境変数、関数シークレット、その他アプリケーションに必要な機密データのような環境固有の値を、環境間で安全に設定することができます。Amplify コンソールでシークレットを設定し、次の例のようにコードで使用することができます。 Next Step 第 1 世代から第 2 世代への移行をお考えのお客様には、第 1 世代から第 2 世代へ手動で移行する方法を説明した移行ガイドをパブリックプレビュー中に提供する予定です。一般提供が開始され次第、移行を加速させるツールを提供する予定です。 Amplify Gen 2 のビジョンは、開発者からのフィードバックに直接インスパイアされたものです。バックエンドのコードの透明性と制御性を高めたいという要望がありましたので、TypeScript ファーストのアプローチでそれを実現しました。より迅速なフィードバックループをご希望でしたので、保存のたびにコード変更を同期するクラウドサンドボックスデプロイメントを構築しました。チームのために柔軟なデプロイメントワークフローが必要だったので、Amplify はフルスタックの Git ブランチとカスタムパイプラインサポートを提供しました。そして、すべてを一元管理する場所をご希望でしたが、新しい統合コンソールがそれを提供します。 一般提供に向けて、皆様からのフィードバックをお待ちしています。今後注力する分野としては、ストレージや機能などの追加ユースケースをカバーするためのバックエンド機能の拡張、ローカルサンドボックスエクスペリエンスの改善、Gen 1 のお客様向けの移行ツールの構築などがあります。 Amplify Gen 2 を使い始めるには、 クイックスタートチュートリアル をお試しください。 本記事は「 Introducing the Next Generation of AWS Amplify’s Fullstack Development Experience 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

こんにちわ、ソリューションアーキテクトのザビオ( @zabbiozabbio )です！ 10/4日に 開催しましたWeb3@Startup Loft #5 &nbsp;の開催報告になります。 Web3@Loftとは Web3@Loft は AWS 上でブロックチェーンを始めようとしている、または、開発/運用しているデベロッパー、事業開発者のための、有志によるコミュニティイベントで、定期的に AWS Loft Tokyo で開催しております。 今回は「Wallet＆On Chain分析」にフォーカスし、実際に開発/運用されている各企業様にご登壇いただきました。 Amazon Web Services Japan G.K. Sr. Blockchain Specialist SA 中武 Amazon Managed Blockchain Web3 Update 最近機能追加になりました、AMB Access &amp; AMB Queryについて紹介しました。 これまで Dedicatedのインスタンスをマネージドという形で提供していましたが、Serverless のOptionが追加されたので、より拾いワークロードでご利用いただけるようになったアップデートをお話させていただきました。 AMB Access &amp; AMB Queryに関しては こちら をご参照ください。 シビラ株式会社 Co-Founder &amp; CTO 流郷様 シビラのプロダクトについて Walletを利用する上で、ユーザビリティも課題にあがりますが、それらを解消するためのWalletソリューションを紹介いただきました。個人的に印象に残っているのは、NFTを利用することで既存Webサービスのマーケティングとして有効に働いた事例が非常に印象的でした。 株式会社BRIDGED パク様 Web3におけるサイバーセキュリティについて 暗号通貨のハッキング被害や、攻撃手法、またハッキングされた場合にどういう対応をとればいいのかを説明いただきました。実際に漏洩した暗号通貨を取り戻した事例は衝撃的でした。ハッキングは他人事ではないので、改めてサイバーセキュリティに対する意識を高め、対策を講じることが不可欠と感じました。 仮想NISHI 様 (本人希望で写真掲載がNG) 仮想NISHI様にWalletサービスについてご説明いただきました。 (フードスポンサー枠) 株式会社SARAH様 SARAHのWeb3取り組みについて 今回、初の試みで、フードスポンサーとしてSARAH様からおいしいカレーを提供いただきました。カレーのバリエーションも様々でどれも美味しそうでした。 SARAH様は「おいしい！を増やす」をプロダクトビジョンに掲げ、グルメアプリを展開されています。そこからWeb3に参入したきっかけを紹介いただきました。 まとめ Walletからセキュリティまで幅広くユースケースや、アーキテクチャを紹介いただきました！ 次回の Web3@StartupLoft は、来年に年明けすぐになるかと思います！みなさま良いお年を〜！ このブログの著者 中武 優樹（Yuki Nakatake） Blockchain、Database、Zabbix が好きなソリューションアーキテクトです。

みなさんこんにちは！ アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクトの守田です。 2023 年 11 月 16 日に「第三十六回 アップデート紹介とちょっぴり DiveDeep する AWS の時間」をオンラインで開催しました。本イベントは、AWS の数あるアップデートの中から「すぐ使える、運用に役立つ、あったらいいなと思ってた、おもしろい、重要」なものをピックアップし、ちょっぴり DiveDeep してカジュアルな雰囲気でお伝えするイベントです。 今回は「Disaster Recovery (DR) 編」ということで、実際に AWS での DR を設計・運用されているお客様から事例やサービスの機能についてご紹介頂きました。今回も非常に多くの方にご参加頂きました。ご参加いただいた皆様、誠にありがとうございました。 実施内容 今回は 5 分間のアップデート紹介の後、ゲストスピーカーとして株式会社マーズフラッグの佐々木様、エムオーテックス株式会社の立古様、株式会社 Works Human Intelligence の兒玉様、株式会社ブイキューブの岩上様、中尾様から、実際に DR を導入されることになったきっかけや、まず最初に取り組まれたこと、現在どのように運用されているのかといった事例について発表して頂きました。合計 1 時間半の中で盛りだくさんの内容でお送りしました。 本記事の中に資料や動画のリンクを記載しておりますので、ぜひご活用ください！ 当日参加したメンバー アジェンダ 今月のお勧め 5 分間アップデート (5 分) スピーカー：アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 後藤 健汰 今月の AWS のサービスアップデートを 5 分でご紹介しました。多くのアップデートの中から 4 つをピックアップしました。 AWS Fargate の Amazon ECS タスクで SOCI の選択的な利用が可能に AWS CodeBuild で AWS Lambda によるコンピューティングのサポートを開始 Llama 2 Chat 13B foundation model from Meta is now available in Amazon Bedrock AWS が Amazon Aurora MySQL と Amazon Redshift のゼロ ETL 統合の一般提供開始を発表 AWS の新着情報については 公式ページ のほか、毎週のアップデート情報をまとめて発信している 週刊 AWS を合わせてご覧頂くことがオススメです！ BCP の改善へ向けた可用性向上 ～Amazon RDS 周りを中心に～ ( 15 分) スピーカー : 株式会社マーズフラッグ サービスプラットフォーム部 佐々木 崇之様 マーズフラッグが長年にわたり提供するサイト内検索サービス「MARS FINDER」を、顧客ニーズに応じ柔軟に機能の組み合わせが可能となるようプラグイン化を推進し「MARS PLATFORM」としてフルリニューアルを行っています。併せて当社プラットフォーム全体を再設計し可用性の向上と BCP の改善に取り組んでいます。このうち Amazon RDS の可用性向上を中心とした事例を交えて紹介します。 ある日「DR やって？」と言われたら – 開発・運用現場が始める DR の第一歩 ( 15 分) スピーカー : エムオーテックス株式会社 開発本部 サービス開発 1 部 サービス開発 1 課 SRE グループ 立古 佳大 様 昨今、事業継続計画 (BCP) の重要性が叫ばれるにつれ、クラウド環境に対しても DR 対応の要求が強まっています。一方で、DR の対応事項はサービス設計やビジネスの形態に依存する部分が多く、その具体的な要件定義は困難を極めます。本セッションでは、DR への取り組みに関わることとなった開発・運用担当者の視点で、DR の要件を明確化し、対応を習慣付けるための第一歩としてどのようなアプローチが可能か、クラウドサービスを長年に渡り多数のユーザーへ提供し続けてきた当社の経験も踏まえご紹介いたします。 DR 対策としてのマルチリージョン対応について ( 15 分) スピーカー : 株式会社 Works Human Intelligence Engineer 兒玉 拓也 様 東京リージョンが使用できない事態を想定した Pilot Light をベースにした DR 対策をご紹介します。Pilot Light ベースを選択した理由や、障害発生時のフェイルオーバーやフェイルバックの定義決めから BCP テストの実施計画などの運用的な話から、対応内容の Amazon DynamoDB や AWS Key Management Service といった利用する AWS サービスにおいて DR のために実施した技術的な対応内容についてお伝えします。 『バーチャル株主総会』における DR 環境の導入及び運用事例 ( 15 分) スピーカー : 株式会社ブイキューブ 技術本部 新規開発グループ インフラチーム 岩上 蘭 様、開発チーム 中尾 真夕 様 オンライン株主総会システム『バーチャル株主総会』サービスは、開催の時間帯においてピンポイントで、万が一が許されない、より高い品質が求められています。従来の Availability Zone 型の冗長性をさらに高めるべく、Region 型の冗長性の追加を DR 対策として行いました。今回はその実現方法と、そこでの苦労した点や AWS を利用していてよかったなと思う点、導入から一定期間経過してからの運用実例について、お話させていただきます。 当日の様子 当日の内容を抜粋してご紹介します。 ※ 録画は後日アップロードし、リンクを記載します。 BCP の改善へ向けた可用性向上 ～Amazon RDS 周りを中心に～ [ 資料 動画 ] 最初のセッションは株式会社マーズフラッグ 佐々木 崇之様より、BCP の改善に向けての可用性の向上に関する取り組みについて、 Amazon RDS を中心にご紹介頂きました。株式会社マーズフラッグ様は、オンプレミスで運用されていたプラットフォームを AWS 上の Amazon EC2 を中心とした構成に移行、その後 AWS 上のマネージドサービスを利用する構成にリニューアルされた、という変遷をご経験されています。本セッションでは、「オンプレ期」「AWS への移行期」「フルリニューアル期」の 3 つのフェーズに分け、それぞれのフェーズでの RDB の可用性向上の取り組みに関してご紹介頂きました。「AWS への移行期」では、「オンプレ期」で悩まれていたハードウェアの故障からは解放されたものの、AZ 障害への耐性がない、リカバリ手順が手動である、故障時のダウンタイムが 30 分程度発生すること等を課題とされていました。「フルリニューアル期」ではデータベースを Amazon RDS の マルチ AZ 構成に移行され、自動でのリカバリが可能となり、故障時のダウンタイムも 60 秒程度と大幅に削減されました。Amazon RDS のマルチ AZ 配置導入の効果について、可用性の向上のみならず、より生産性のあるタスクに費やすことのできるリソースの増加、障害に関する精神的なストレスからの解放、といった利点についてお話し頂きました。特にリレーショナルデータベースに関して可用性を向上したい方や、Amazon RDS のマルチ AZ 配置を利用した障害対策の実際の効果を知りたい方々にぜひご覧頂きたい内容です。 ある日「DR やって？」と言われたら – 開発・運用現場が始める DR の第一歩 [ 資料 動画 ] 2 つ目のセッションでは、エムオーテックス株式会社 立古 佳大様より、開発・運用部門の方々が DR を始める際の第一歩としての DR 対策の具体化、施策の実施、DR の制定後の動きについてご紹介頂きました。 DR 対策の具体化に関しては、プロダクトの特性を踏まえて SLO、RTO、RPO 等の値をゴールとして定めることで、ステークホルダーから具体的な要求を引き出すことが可能です。ゴールの具体化や運用への落とし込みで煮詰まった際には、外部のベンチマークとして Amazon Trusted Advisor の DR に関する推奨事項や、外部のセキュリティ認証規格 (AWS では AWS Foudational Technical Review で確認可能 ) を活用する方法をご紹介頂きました。次に具体的な施策の実施に関して、各サービスのユーザーの責任範囲に応じた DR の対応策が必要であること、手動での対応が必要であるケースを洗い出して手順を定めることについて具体例を交えてお話し頂きました。障害対策だけを意識してサービスを選定しているわけではないため、DR 側の要求事項を開発以前から開発メンバーに伝えておくことも、サービス選定においては重要な点となります。最後に策定後の定期的な訓練や見直し実施についてご紹介頂きました。DR を始めようと思っているが何から始めるべきか分からないというお悩みを抱えているお客様や、今後 DR を始める可能性がある開発・運用部門の方にぜひご覧頂きたい内容です。 DR 対策としてのマルチリージョン対応について [ 資料 動画 ] 3 つ目のセッションでは、株式会社 Works Human Intelligence Engineer 兒玉 拓也様より、マルチリージョン構成の DR 対策における事前検討から運用までの流れを、実際に設計されたアーキテクチャと共にご紹介頂きました。事前検討に関しては、株式会社 Works Human Intelligence 様のサービスである My Number Keeping System (MKS) で DR 対策を検討される際に策定された、災害発生時の対応体制や SLO などの復旧目標、監視体制をご共有頂きました。MKS のアーキテクチャは Pilot Light 構成をベースに構築されており、本セッションではアプリケーション層と永続層それぞれについてご説明されています。アプリケーション層はリージョン間の差分を意識することなく運用を行うため、災害発生時に 0 からデプロイ機構を構築する構成を取られており、こちらはマルチリージョン対応以前から 8 割程度の IaC 化を進められていたために実現が可能でした。永続層は Amazon DynamoDB と Amazon S3 を用いて DR リージョンへのデータの同期やレプリケーションを行い、 AWS Key Management Service にてデータキーを管理されています。運用設計に関しては、フェイルオーバーやフェイルバックの条件について実際に定められた条件をご説明いただきました。DR 対策が必要かどうか考えられている方、これから始められる方は是非ご覧ください。 『バーチャル株主総会』における DR 環境の導入及び運用事例 [ 資料 動画 ] 最後のセッションは、株式会社ブイキューブ 岩上 蘭様、中尾 真夕様より、DR 環境の導入と運用事例について実際のアーキテクチャを交えてご紹介頂きました。株式会社ブイキューブ様のバーチャル株主総会システムは、定期総会が集中する特定の期間において、万が一の停止が許されずより高い品質が求められるサービスです。2021 年に大阪リージョンがローカルリージョンから正式リージョンに昇格したことをきっかけに DR に取り組まれ、構成は切り替え時間やランニングコストを考慮の上で Pilot Light を選択されています。本セッションでは、東京リージョンで障害が発生した際にどのように大阪リージョンへの切り替えが行われるかの手順をアーキテクチャと共にご紹介頂きました。大量のアクセス負荷に対応し、重要なデータを適切に取り扱うため、全体の構成は Amazon ECS 、 Amazon Aurora 、 Amazon SQS 、 Amazon S3 、 Amazon ElastiCache をご利用頂いています。DR を導入して良かった点としてご紹介された、運用に関わる方々だけでなく、サービスに関わる全ての方の安心感を得ることができたという点は、DR を導入するすべてのお客様にとって欠かせない利点であると思います。マルチリージョンで DR を導入する際のステップや具体的なアーキテクチャ、導入の利点にご興味があるお客様には必見の内容です。 いただいたご質問とその回答 『ある日「DR やって？」と言われたら – 開発・運用現場が始める DR の第一歩』について Q. プロダクトの SLO、RTO、RPO を定める際に複数のステー クホルダーの方から異なる意見が出てくると思うが、その中でどのような要素が決め手となって最終的に目標値を決定したのでしょうか？ A. さまざまな立場の方がいらっしゃるが、コストとのバランスもあるため、プロダクトのマネージャーなど、コスト面をフェアに選べる方が最後の決定を行うことがあります。基本的にはステークホルダーの方々の対話を粘り強く進めていくことが必要です。 Q. DR の訓練はかなり大変な印象がありますが、どのような頻度・規模で実施されているのでしょうか？ A. 頻度は 1 年に 1 度です。必ずしも全ての方々に理想的な値かは分かりませんが、オフィスビルの避難訓練と同じようなもので、1 年に 1 度が一般的という肌感覚です。規模は、作った手順書やリソース全てについて実施するのは大変なので、例えば複数の RDS でバックアップの手順を使いまわせるように、使いまわせるものはどれか 1 つを実施したり、重要度によっては内容の確認だけ行なったりしています。それでも毎年工数が多すぎる場合は、サーバーレスへ移行した方が工数が小さいのではないか、といった点も議論できると、少しずつ負荷を下げられるのではないかと思います。 『DR 対策としてのマルチリージョン対応について』について Q. DR テストはメンテナンスと称してサービスを停止して行うのでしょうか？それとも Dummy 環境などを準備して実施するのでしょうか？ A. DR テストに関してはステージング環境を本番環境と見立ててテストを実施しました。ステージング環境は本番環境デプロイ前の最終テスト環境のため、本番環境と同等 (データを除く) の状態になっており、本番環境に見立てる事が可能という判断になります。ステージング環境と本番環境どちらで BCP テストを実施するかの判断は難しいとは思いますが、判断軸としてテストの影響範囲の大きさや、万が一の際に稼働影響が出るか出ないかを軸として実施環境を選択しております。DR テストは影響が大きい為、本番環境でのテストを避け、ステージング環境でのテスト実施としました。 次回予告 次回は「AWS re:Invent 振り返り」編です。 re:Invent 2023 で発表された新機能をドドンとデモを含めてご紹介していきます。どのようなコンテンツにするかは鋭意検討中ですので、発表までお待ちください！ 次回も多くの方々のご参加を心よりお待ちしております！ 第三十七回「アップデート紹介とちょっぴり DiveDeep する AWS の時間」- AWS re:Invent 振り返り編- 開催日時：2023 年 12 月 21 日（木）16:00 – 17:30 オンライン開催 アジェンダは決定次第追記させて頂きます！

この投稿は2023年10月26日に投稿された The Game Developer’s Guide to re:Invent 2023 を日本語化したものです。 AWS re:Invent 2023 の開催が迫りつつあります。re:Invent は開発者向けの年次カンファレンスで、今年は、11月27日から12月1日までの日程でラスベガスにて開催されます。 AWS for Games は、世界中からの参加者を迎えるための準備を進めています。今年は、 re:Invent の基調講演 で発表される情報のほか、参加者は AWS for Games チームが厳選したパネルディスカッション、プレゼンテーション、ハンズオン形式の学習体験などの多種多様でエキサイティングなコンテンツを楽しむことができます。 今回のイベントのプログラムは、ゲーム開発者やその後ろにある業界が直面している最も大きな課題やトレンドについての議論を引き出すように設計されています。プログラムには、アマゾン ウェブ サービス（AWS）のお客様である Riot Games、Epic Games、ニンテンドーシステムズによるセッションも含まれています。参加者はカスタマーブレークアウトレクチャーを聴講したり、AWSのエキスパートと1時間の少人数チョークトークでリアルワールドアーキテクチャの課題について議論することもできるほか、2時間のハンズオンワークショップに参加し少人数のグループワークで AWS サービスを使って問題を解いたり、主要な業界テーマをカバーした20分のライトニングトークを聞いたりなど、様々なコンテンツを楽しむことができます。 さらに、AWS for Games は11月28日火曜日の午後6時から8時半まで Villa Azure にて VIP ネットワーキングイベント を主催します。イベント参加者はネットワーキングのほか、AI フォトブースを含む楽しいインタラクティブなゲーム体験に参加することもできます。会場では食べ物や飲み物をご用意しております。 こちら からお早めに参加登録することをおすすめします。 the Venetian 内に位置する AWS re:Invent expo フロアの AWS for Industry Pavilion ブース#580にもぜひお立ち寄りください。ブースでは AWS for Games のインタラクティブデモをご用意しています。デモでは AWS のお客様が作ったマルチプレイゲームをプレイしながら、ゲームの開発とデプロイで使われた AWS サービスについて学ぶことができます。 おすすめセッションお探しであれば、AWS for Games チームがまとめた AWS for Games re:Invent 参加者ガイド と下記の AWS for Games re:Invent 2023 スケジュールハイライトとを合わせてご参照ください。 また、AWS Events というモバイルアプリ（ iOS 、 Android 対応）をダウンロードし、 re:Invent のプランニングと参加時のガイドにご活用ください。今からでも参加登録は可能です。 こちら から参加できるセッションとイベントの確認および参加者枠の予約をしてください。 AWS for Games re:Invent 2023 スケジュールハイライト： 11月27日（月） 8:30 AM-10:30 AM: GAM302: ワークショップ: AWS 上でスケーラブルでクロスプラットフォームのゲームバックエンドを構築する インタラクティブなワークショップに参加し、クロスプラットフォームの ID と認証、サーバレスおよびコンテナ形式のバックエンドマイクロサービスのテンプレート、そしてゲームエンジンとの統合を備えた、エンドツーエンドのセキュアでスケーラブルなゲームバックエンドソリューションを AWS 上でデプロイしてみましょう。 10:30 AM-11:30 AM: GAM305: ブレークアウトセッション: Warhammer 40,000: Darktide を1時間で0から100,000プレイヤーまでスケールさせる Fatshark からサーバレスバックエンドアーキテクチャ、 Amazon GameLift 、 AWS Global Accelerator の組み合わせを駆使してゲームを大規模にスケールさせる方法について学びましょう。 11:30 AM-12:30 PM: GAM301: チョークトーク: AWS Graviton を用いてコスト効率の高いゲームを構築する Amazon Elastic Kubernetes Service（Amazon EKS） にデプロイされた Unreal Engine で作られた x86 向けマルチプレイヤーゲームをご覧になってください。そしてコンピュートリソースに Graviton インスタンスを導入する手立てについて学びましょう。 12:00 PM-1:00 PM: ANT309: チョークトーク: 機械学習とリアルタイムパーソナライゼーションによるゲーム体験の最適化 データの取り込みと機械学習モデルの更新ができるニアリアルタイムの機械学習パイプラインの構築方法について学びましょう。このパイプラインにより、リアルタイムのパーソナライゼーションが可能となり、プレイヤーにカスタマイズされたコンテンツを提供することでプレイヤー行動に影響を与えることができます。 3:00 PM-4:00 PM: ANT320: ブレークアウトセッション: Electronic Arts が Amazon EMR を使ってデータプラットフォームをモダナイズした方法 Electronic Arts は Amazon EMR への移行（HDFS から Amazon S3 への移行、500以上の ETL ジョブの Apache Spark から Amazon EMR への移行を含む）により、データプラットフォームのモダナイズを実現しました。その移行について学びましょう。 11月28日（火） 5:00 PM-6:00 PM: SVS308: ブレークアウトセッション: 低遅延のイベントドリブンアーキテクチャの構築 Marvel Snap を作り出した Second Dinner が、サーバレスなバックエンドデザイン、 AWS Lambda を用いた HTTP リクエストハンドリングやデータ処理、そしてAWS Lambda とその他の AWS サービスとの統合についてお話しします。 Amazon EventBridge を使ったイベントドリブンなワークフローについて学びましょう。 11月29日（水） 9:00 AM-11:00 AM: GAM401: ワークショップ: LLMOps を用いた生成系 AI アプリケーションの運用 生成系 AI とゲーム開発についてのインタラクティブなワークショップに参加し、AWS 上でテキストや画像生成アプリケーションを運用する方法について学びましょう。LLMOps に基づき、生成系AIアプリケーションに CI（continuous integration、継続的統合）/CD（continuous deployment、継続的デプロイ）/CT（continuous tuning、継続的チューニング）を適用します。 10:00 AM-11:00 AM: GAM306: ブレークアウトセッション: ニンテンドーeショップのモダナイゼーション: マイクロサービスとプラットフォームエンジニアリング 任天堂が Nintendo Switch やその他の任天堂のプラットフォームから利用できるニンテンドーeショップをモノリスからマイクロサービスアーキテクチャへ移行した方法について学びましょう。 1:30 PM-2:30 PM: GAM304: ブレークアウトセッション: 脱データセンター: リーグ・オブ・レジェンドとVALORANTの物語 Riot Games は、最大規模な2つのゲームを中断なくオンプレミスからクラウドに移行することに成功しました。彼らから移行のプロセスとノウハウについて聞きましょう。 1:30 PM-2:30 PM: GAM303: チョークトーク: コンピュート、コンテナ、Amazon GameLiftでマルチプレイゲームを展開する サーバレスなアーキテクチャでゲームのバックエンドを構築する方法を学び、マネージドなソリューションである Amazon GameLift、Amazon EKS や Amazon Elastic Container Service（Amazon ECS） を利用したコンテナベースのソリューション、 Amazon EC2 上のバーチャルマシンといったゲームサーバホスティングソリューションから、どのように最適な技術選定ができるかについて学びましょう。 3:00 PM-4:00 PM: GAM307: ブレークアウトセッション: Mortal Kombat 1 のマルチプレイヤーゲームを百万人規模にスケールさせる方法 ワーナーゲームによるセッションにご参加ください。Mortal Kombat 1 の新バージョンは世界中から百万人規模のプレイヤーに対応できるスケーリング性能を有しています。それを支えるバックエンドアーキテクチャについて学びましょう。 5:30 PM-6:30 PM: DAT334: ブレークアウトセッション: Amazon Timestream を活用した Epic Games のUX向上策 Epic Games は Unreal Engine（様々な業界で利用されている 3D 制作エンジン）でゲームに変革をもたらしました。Epic Games がどのように Amazon Timestream を活用し、同社の様々なゲームにわたる膨大な数のユーザのゲームプレイをモニタリングし、さらにそこから洞察を得ることを可能にしたスケーラブルなソリューションを構築したかについて学びましょう。 11月30日（木） 11:00 AM-12:00 PM: STG203: ブレークアウトセッション: AWS Backup の最新情報 AWS と Supercell による AWS Backup の新機能紹介セッションに参加しましょう。このセッションでは、データ保護ボリシーのセキュリティ、管理、および監査に関する実践的なティップスを学び、開発者から AWS のマネージドなデータ保護サービス群が、どのように転送中および保存されたデータを強力に保護することができるかについて聞くことができます。 以上、セッションとイベントの紹介でしたが、これらは今年の11月に開催される re:Invent で体験できるもののごく一部にすぎません。 AWS for Games ブログ や LinkedIn をチェックして re:Invent のリアルタイムな情報をゲットしましょう。ラスベガスでお会いすることを楽しみにしています！ 翻訳はソリューションアーキテクトの Lin が担当しました。原文は こちら です。

AWS re:Invent 2023 が間近に迫っており、 Amazon Connect チームでは、11 月 27 日から 12 月 1 日までラスベガスにて世界中からの参加者の方々を歓迎する準備をしています。今年の参加者は、Amazon Connect チームによって厳選された興味深いプレゼンテーションやハンズオンでの学習体験などの数々をご覧いただけます。 顧客サービス向けの生成系 AI が話題になっている中、この興味深い技術から価値を引き出し、顧客体験を向上させる方法を学ぶため、ブレイクアウトセッション、チョークトーク、ビルダーセッション、ワークショップを見逃さないでください。ここでは皆様が re:Invent のスケジュールを立てて、ラスベガスでの一週間を最大限に活用するための ガイド をご紹介します。 re:Invent 基調講演 での発表に加えて、皆様にご参加いただきたいセッションがいくつかあります。 BIZ225-INT | C-Suite leaders talk generative AI and applications （経営幹部が生成系 AI とそのアプリケーションについて語る） 11 月 28 日 (火) 午後 5 時 ～ 午後 6 時 (PDT) （日本時間: 11 月 29 日 (水) 午前 9 時 〜 午前 10 時） AWS アプリケーションズ VP の Dilip Kumar と、Asana、U.S. Bank、Woodside Energy の経営幹部とのパネルセッションでは、生成系 AI がビジネスの成果、顧客サービス、従業員幸福度についての考え方をどう変革しているかを取り上げます。このイノベーションのトークでは、生成系 AI によって組織内で変革されるプロセスとシステム、そして自社のリーダーが自社の技術スタックに統合する際に予期すべき課題についてご説明します。生成系 AI の新機能やサービスを含む、AWS アプリケーションズグループの新しい取り組みについてご紹介します。 スピーカー: Dilip Kumar（AWS アプリケーションズ VP）、Alex Hood（Asana 最高製品責任者）、Kent Lemon（U.S. Bank コンタクトセンター カスタマーエンゲージメント SVP）、Meg O’Neill（Woodside Energy Group CEO） BIZ216 | What’s next in contact centers with Amazon Connect and generative AI（Amazon Connect と生成系 AI を用いたコンタクトセンターの今後の展望） 11 月 29 日 (水) 午前 10 時 ～ 午前 11 時 (PDT) （日本時間: 11 月 30 日 (木) 午前 2 時 〜 午前 3 時） クラウドにより、各社がコンタクトセンターをモダナイズし、イノベーションを加速し、よりよい顧客サービスを大規模に提供できるようになっています。今日、ビジネスリーダーやコンタクトセンターのリーダーは、顧客によりよいサービスを提供し、エージェントを支援・強化し、データから顧客とビジネスについてインサイトを引き出すためのイノベーションを加速するために、生成系 AI のような AI 技術に注目しています。このセッションでは、Amazon Connect の新機能や、顧客とビジネスによりよい成果をもたらすために各社が運用と日々のエージェント業務を最適化している方法をご紹介します。 スピーカー: Pasquale DeMaio（Amazon Connect VP）、Chris Short（Capital One プロダクトマネジメント シニアディレクター）、Ram Mepperla（Capital One ソフトウェアエンジニアリング ディレクター） さらに、11 月 29 日 (水) に Venetian の Villa Azur で開催される 顧客体験レセプションへの出席にお申し込み いただくと、Amazon Connect のエキスパートやユーザーと交流する機会を得ることができます。当日の re:Invent セッション後の夜に立ち寄って、おいしい軽食、遊び心あふれるカクテル、会話を楽しみながら、コンタクトセンターと顧客体験をレベルアップする方法を探りましょう。 ご登録・ご予約はまだ間に合います！皆様と re:Invent 2023 でお会いできるのを楽しみにしています。 re:Invent の顧客体験のガイドはこちらからダウンロードしてください。 翻訳はソリューションアーキテクト遠藤が担当しました。原文は こちら です。

開発者とフロントエンドフレームワークの作成者が AWS Amplify Hosting 上でフルマネージドの Server Side Rendering (SSR) アプリケーションをデプロイできるようにする、新しいデプロイ仕様の一般提供を開始しました。このデプロイ仕様によって、Amplify Hosting の SSR 機能がすべてのフレームワークで利用可能になります。これらの文書化された規約に従うことで、開発者やフレームワークの作者は、Nuxt, SvelteKit, Astro、さらには Express サーバーのような一般的な SSR フレームワークで構築されたアプリケーションをデプロイすることができます。この仕様では、Compute, Image optimization, Routing rules, Static assets のための規約ベースの基本要素を定義しています。 主な機能は以下の通りです。 Static assets – フレームワークに静的ファイルをホストする機能を提供します。 Compute – フレームワークに Node.js HTTP サーバーを 3000 番ポートで実行する機能を提供します。 Image Optimization – フレームワークに実行時に画像を最適化する機能を提供します。 Routing Rules – フレームワークに入ってくるリクエストパスを特定のターゲットにマッピングする機能を提供します。 この新しい SSR のデプロイ仕様は、 Nuxt が Nitro サーバプリセットで行ったように開発者とフレームワークの作成者が SSR の基本要素を利用するためのアダプタを構築するために設計されています。さらに、開発者が基本要素をフル活用するために、Express.js のような他のフレームワークや技術で同様の実装することも可能にします。 この仕様と、Compute, Image optimization, Routing rules, Static assets に関する規約ベースの基本要素は、 Amplify Hosting SSR デプロイ仕様ドキュメント に記載されています。 Nuxt のサポート Nitro サーバー内でこのビルトインアダプターパターンを使用した Nuxt のサポートを開始されました。これによって Nuxt SSR アプリの Amplify Hosting へのデプロイを、プロジェクトに依存関係を追加することなく開始できるようになりました。新しいデプロイ仕様を使用して、Nuxt チームは、設定無しで Nuxt アプリを Amplify Hosting にデプロイできるアダプタを作成しました。以下にその方法を紹介します。 ソリューションの概要 この新機能を活用するため、Nuxt チームと協力して、Amplify Hosting への Nuxt SSR デプロイをサポートしました。この仕様は、Nuxt を駆動する Nitro サーバー内の組み込みデプロイプリセット に実装されており、Nitro 上に構築されたあらゆるフレームワークをサポートしています。 この記事では、Nuxt SSR アプリケーションを Amplify Hosting にデプロイすることに焦点を当てます。Nuxt アプリケーションは、Nitro サーバから利用可能な設定不要の組み込みアダプタを使用します。わずか数ステップで、Nuxt SSR アプリを作成して Amplify Hosting にデプロイできます。 Nuxt SSR アプリのデプロイ Nuxt アプリは Amplify Hosting に簡単にデプロイすることが出来ます。Nuxt の依存関係さえあれば、デプロイすることができまです。Nuxt は Nitro サーバー経由で組み込みアダプタを実装しているため、最小限のセットアップで Amplify Hosting にデプロイできます。 アプリをローカルで実行し、テストしたら、CI/CD で Amplify Hosting にデプロイできます。Amplify CI/CDでのビルドプロセス中に、Nitro サーバーは Amplify CI/CD パイプラインにあることを認識し、設定不要の Nitro プリセットを aws_amplify として自動的に選択します。このステップでは、アプリのビルド出力を Amplify Hosting のデプロイ仕様に合わせて調整します。このプロセス全体は、Nuxt 組み込みアダプタによって行われます。 新しい Nuxt アプリを始める はじめに、 nuxi を使用して 新しい Nuxt アプリ を作成します。 npx nuxi@latest init この例では、パッケージマネージャとして npm を使っています。インストール完了のメッセージが表示され、Git リポジトリを初期化するプロンプトが表示されます。 ✔ Which package manager would you like to use? npm ◐ Installing dependencies... &gt; postinstall &gt; nuxt prepare ✔ Types generated in .nuxt ✔ Installation completed. ✔ Initialize git repository? Yes ℹ Initializing git repository... Initialized empty Git repository in ... ✨ Nuxt project has been created with the v3 template. Next steps: › cd nuxt-app › Start development server with npm run dev プロジェクト内の package.json ファイルは以下の例のようになり、Nuxt と Vue の典型的な依存関係が含まれます。 { "name": "nuxt-app", "private": true, "type": "module", "scripts": { "build": "nuxt build", "dev": "nuxt dev", "generate": "nuxt generate", "preview": "nuxt preview", "postinstall": "nuxt prepare" }, "devDependencies": { "@nuxt/devtools": "latest", "nuxt": "^3.8.1", "vue": "^3.3.8", "vue-router": "^4.2.5" } } GitHub に新しいリポジトリを作成し、ローカルのリポジトリをそこにプッシュします。 Amplify Hosting でアプリを作成できるようになりました。Amplify Hosting で、 Host web app をクリックし、新しいアプリを作成します。 次に、GitHub リポジトリとブランチに接続します。 Amplify のアプリ名を入力します。Nuxt の場合、ビルドとテストの設定は自動検出によって自動的に入力されます。以下の例と一致することを確認し、必要に応じてパッケージマネージャのインストールコマンドを調整します。この設定では、ビルド環境を設定し、デプロイするアーティファクトの baseDirectory を .amplify-hosting に指定します。 version: 1 frontend: phases: preBuild: commands: - nvm use 18 - corepack enable - npx --yes nypm i build: commands: - npm run build artifacts: baseDirectory: .amplify-hosting files: - '**/*' Nitro サーバーアダプタは、デプロイ仕様に従ってファイルを整理し、 .amplify-hosting ディレクトリに自動で移動します。 ビルド設定で SSR アプリのログを有効にする アプリの サーバーサイドロギング を有効にすることができます。アプリがデプロイされると、 Amazon CloudWatch アカウントへのサーバーサイドロギングが有効になります。つまり、アプリケーションサーバーまたは Nuxt server route からのログはすべてそこにキャプチャされます。 有効にするには、 Build and test settings の Enable SSR app logs チェックボックスをオンにします。チェックボックスを選択すると、 IAM Role の選択または作成オプションが表示されます。サーバーサイドレンダリングロギングのIAM ロールを選択または作成します。Amplify Hosting に IAM ロールの作成を許可することを選択した場合、その IAM ロールはすでに CloudWatch Logs を作成する権限を持っています。 次の画面で、 Save and deploy を選択します。 アプリが正常にデプロイされたら、Amplify アプリの URL に移動します。これで Nuxt アプリが公開されました！ Nuxt image &lt;NuxtImg&gt; および &lt;NuxtPicture&gt; コンポーネントを完全に利用するには、 @nuxt/image モジュールをインストールしてアプリを設定します。モジュールでアプリを設定したら、変更をデプロイします。Amplify Hosting は自動的に画像の最適化を有効にし、コンポーネントを使用する際に画像のリサイズや変換が可能になります。 Nuxt サーバーサイドログの表示 オプションとして、いくつかのステップで CloudWatch へのサーバーサイドロギング出力をテストできます。まず、アプリの server/api/hello.ts に Nuxt server route を追加します。これは “Hello, World” の例で、ルートがリクエストを受信したときに追加の console.log() も追加します。 export default defineEventHandler((event) =&gt; { console.log('server route requested') return { hello: "world", }; }); アプリを保存し、新しい変更を GitHub のリポジトリにプッシュします。これによってアプリをビルドしてデプロイするための新しい CI/CD プロセスが開始されます。 デプロイされたら、新しいサーバーのエンドポイント ( main.&lt;app-id&gt; .amplifyapp.com/api/hello ) にアクセスしてください。サーバーは JSON レスポンスを返しますが、私たちの場合はシンプルな { hello: "world" } です。 サーバーサイドのログを見るには、 Monitoring &gt; Hosting compute logs で Amplify アプリのCloudWatch ログストリームに移動します。最新の CloudWatch ログストリームをクリックします。 CloudWatch コンソールを開きます。最新の Log stream をクリックします。 これらのログでは、サーバールートで追加されたステートメントログが出力されます。 新しい Amplify Hosting SSR デプロイ仕様を利用する設定不要のアダプタのおかげで、Amplify Hosting での Nuxt アプリのデプロイは合理化されています。互換性のあるアダプタを持つフレームワークを使用している場合、Amplify Hosting は自動的に SSR の基本要素を使用してアプリケーションを認識し、デプロイします。 クリーンアップ 最後に、不要になったアプリケーションを削除します。これを行うには、このアプリの Amplify Hosting コンソールの App settings &gt; General に移動し、 Delete app をクリックします。また、アプリのデプロイ設定中に SSR ロギング用の IAM ロールを作成した場合は、そのロールを削除する必要があります。ロールの名前は、 AmplifySSRLoggingRole-&lt;app-id&gt; のパターンに従います。 まとめ Nitro サーバの aws_amplify 用の設定不要なプロバイダを使用して、わずか数ステップで Nuxt アプリをビルドして Amplify Hosting にデプロイできるようになりました。この方法では、デプロイプロセスが簡素化され、Amplify Hosting 上の Nuxt アプリのビルド設定を検証するだけで済みます。Nuxt 3 アプリを Amplify Hosting 上で稼働させるための簡単で迅速な方法です。 この新しいデプロイ仕様により、開発者やフレームワークの作成者は、この仕様で概説されている SSR の基本要素を利用するための独自のアダプタを構築できるようになります。つまり、あらゆる SSR フレームワークでも、カスタムビルドのアダプタを使えば、Amplify Hosting 上で同じ合理的で効率的なデプロイプロセスを利用することができるのです。 Amplify Hosting の拡張された SSR 機能とアダプタの構築に関するドキュメントをより深く知るには、 Amplify Hostingによる SSR アプリのデプロイのドキュメント をご覧ください。 その他のリソース Amplify Hosting の SSR フレームワークサポート デプロイマニフェストを使用して Express サーバーを Amplify Hosting にデプロイ Nitro サーバー AWS Amplify プロバイダー の詳細設定 本記事は「 Introducing Support for Hosting Any SSR app on AWS Amplify Hosting 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

AWS は、お客様のルートアカウントの所有者もしくは運用、セキュリティ、請求の連絡先へ、サービス通知や計画されているアクティビティに関する定期的な更新を電子メールで提供します。AWS はまた、 AWS Health を通じて粒度の高い通知もお客様に提供し、お客様に直接関係のある問題についてのアラートを微調整できるようにしています。ヘルスダッシュボードのモニタリング機能に加え、お客様はその基盤となっている API 、つまり AWS Health API の恩恵を受けることも可能です。AWS Health API を使うことにより、お客様はリソースに影響のあるすべての通知を収集し、それらの通知をお客様固有のビジネスニーズに合うようにカスタマイズすることができます。実際に使用されている AWS Health API の例としては AWS Health Aware フレームワークがあります。それにより、お客様は通知を収集し、それを電子メール、Slack、 Amazon EventBridge などの複数のコミュニケーションチャネルに送信することができます。 AWS のお客様は多くの場合、Organization (AWS Organizations の組織) 全体で複数のアカウントをお持ちです。これらのアカウントはそれぞれ AWS Health イベント に基づいてアラートを生成する場合があり、お客様が Organization を数百アカウントに拡大するにつれて、それらのアラートを適切なチームに大規模にリダイレクトすることが重要になってきます。 このブログでは、AWS Health を使用して AWS インフラストラクチャのヘルスイベントに関するアラートを生成するフレームワークに関するガイダンスを提供します。そして、 適切なタグ付け戦略 を使用して既存のワークフローに合うように通知を微調整することで、リソースを特定しアラートを適切な担当部署に送信することができるようにします。同様のフレームワークは現在 Zoom Video Communications 社でも稼働中で、Yasin Mohammed 氏 (クラウド運用担当マネージャー) は「AWS リソースにタグベースのフィルタリングを使って AWS Health 通知を自動的に通知するメカニズムを設定することにより、複数のアカウントやリージョンにわたって Zoom のヘルスモニタリングとアラートのメカニズムを合理化することができました」と話しています。 前提条件 お客様が AWS Health API を最大限に活用するには、まず ビジネスサポートもしくはエンタープライズサポート に登録されていることを確認する必要があります。それらが有効になると、お客様は AWS Health API をクエリするコードを記述して AWS Health アラートをカスタマイズできるようになります。organization 全体にこのソリューションをデプロイして AWS Health アラートを収集したいお客様は、AWS Health Aware フレームワークを使用することができます。これは、それらのアラートを EventBridge や SNS、電子メールなどと統合できる無料かつオープンソースのフレームワークです。 Amazon Elastic Compute Cloud (EC2) 、 Amazon EventBridge 、 AWS Lambda の IAM 権限に関する中級レベルの理解 Amazon EC2 および Amazon EventBridge の API に関する中級レベルの理解 ソリューションアーキテクチャ 多くのエンタープライズのお客様に当てはまるシナリオは、さまざまなビジネスユニットに多くのアカウントがあり、それらがさまざまな運用チームや開発チームによって管理されているような場合です。これらのチームは、データベースやセキュリティなど、特定の専門分野や責任範囲があるため、複数のアカウントにわたり特定のリソースに準じて編成されることもあります。たとえば、一部のリソースに予定されている変更をアカウントレベルで運用チームに通知する必要がある場合や、特定のデータベースに関する通知がある際にデータベース管理者にアラートを送る必要がある場合もあります。 そのようなシナリオにおいては、 AWS リソースをタグ付けするためのベストプラクティス にあるように AWS リソースにタグを付けることが重要です。いったんリソースにタグを付ければ、タグ情報に基づいて AWS Health アラートを送ることができます。AWS Health イベントは生成されると EventBridge に送られます 。Amazon EventBridge では、関連する AWS リソースからタグ情報を取得することでアラートを微調整できる Lambda 関数を、トリガするように EventBridge ルール を設定することができます。リソース環境やチーム名などを追加するといった AWS Health イベントの強化も Lambda 関数を使用することにより可能です。専用の カスタムイベントバス を作成して別々のグループ/チームに通知することもできます。Lambda 関数は強化された AWS Health イベントをカスタムイベントバスに送り、そのカスタムイベントバスではメッセージを Amazon SNS に配信して適切なユーザー/アプリケーションに通知します。ここで、AWS Health はベストエフォートベースでイベントを配信することに注意してください。イベントは EventBridge に配信されることが常に保証されているわけではありません。このフレームワークは AWS Health Aware もサポートしているため、このアラートフレームワークを organization 全体にデプロイし、適切なチームが自分たちの担当するリソースについてのアラートを各自が希望する通知方法でタイムリーに受けるようにすることができます。 図 1: ソリューションアーキテクチャ ユースケース例 この例では、DEV 環境の EC2 インスタンスにアラートを設定します。EC2 インスタンスの環境情報は environment タグを使って取得します。また、 customEventBus タグを使用して専用のイベントバスを指定します。この専用のカスタムイベントバスは SNS トピックを使用して DEV 環境管理者に通知を行います。 図 2: EC2 インスタンスのタグ EC2 インスタンスへのタグ付けに加えて、 AWS アカウント 、 Amazon RDS リソースなどのほぼすべての AWS リソースにタグを付けることができます。 AWS Organizations を使用している場合には、AWS リソースに タグポリシー を強制してチームが運用上のベストプラクティスに従うようにすることができます。 EC2 インスタンスにタグが付けられると、EventBridge を使ってそのインスタンスに対する AWS Health イベントを受信します。EventBridge ルールによりトリガされる Lambda 関数をデプロイして、AWS Health イベントの JSON ペイロードを検査し、EC2 環境情報を使って AWS Health イベントペイロードを強化し、カスタムイベントバスにアラートをリダイレクトします。専用のカスタムイベントバスは SNS を使ってアラートを適切なチャネルに配信します。 ユースケースのウォークスルー ステップ 1: インフラストラクチャチームにアラートを送信する SNS トピックを作成する Amazon SNS コンソール に移動します。 左側のパネルから [トピック] を選択し、右側のパネルから [トピックの作成] を選択します。 [トピックの作成] ページの [タイプ] で [スタンダード] を選択し、[名前] に “health-alerts” のような名前を入力します。 残りの設定はそのままにして、[トピックの作成] を選択します。 電子メールで サブスクリプションの作成 を行い、メールボックスの電子メール確認でそれを確認します。 ステップ 2: インフラストラクチャチーム専用のカスタムイベントバスを作成する Amazon EventBridge コンソール に移動します。 左側のパネルから [イベントバス] を選択し、右側のパネルから [イベントバスを作成] を選択します。 [名前] に “health-events” のような名前を入力し、[作成] を選択します。 ステップ 3: 必要なサービスへの読み書きを行うための Lambda 関数用の実行ロールを作成する IAM コンソール に移動し、左側のパネルから [ポリシー] を選択します。 右側のパネルから、[ポリシーの作成] を選択します。 ユースケースに基づいて Lambda がお客様の代わりにサービスを呼び出すために必要となる権限を追加します。この例では、基本的な Lambda 実行ポリシー ( AWSLambdaBasicExecutionRole ) に加えて、対象となる EventBridge にイベントを送信し EC2 のタグを読み取る必要があります。各サービスの IAM ドキュメントを参照して、このポリシーをニーズに合わせてカスタマイズしてください。 権限の追加が完了したら [次へ] を選択します。 ポリシーに “EnrichHealthEventsPolicy” のような名前を付けて、オプションで [説明] に説明を入力します。 [ポリシーの作成] を選択します。 IAM ポリシーを設定したら、ポリシーから Lambda 実行ロールを作成します。 IAM コンソールに移動し、左側のパネルから [ロール] を選択します。 右側のパネルから [ロールを作成] を選択します。 [AWS のサービス] を選択します。ユースケースでは [Lambda] を選択し、[次へ] を選択します。 先ほど作成した “EnrichHealthEventsPolicy” を選択し、[次へ] を選択します。 ロールに “EnrichHealthEventsLambdaRole” のような名前を付けて、[ロールを作成] を選択します。 ステップ 4: Lambda 関数を追加して EC2 タグを取得し、AWS Health イベントを強化する Lambda コンソール に移動します。 右側のパネルから [関数の作成] を選択し、[一から作成] を選択します。 関数に “EnrichHealthEvents” のような名前を与えます。 ランタイムを選択します (この例では、Python を使用します)。 [デフォルトの実行ロールの変更] を選択し、ステップ 3 で作成した実行ロールを選択します。 [関数の作成] を選択します (これで簡単な “hello world” 関数が作成され、次のステップに進むために保存しておくことができます)。 [Deploy] を選択します。 後から、必要に応じて Lambda 関数を強化、反復、カスタマイズ、テストすることができます。 EC2 インスタンスの AWS_EC2_MAINTENANCE_SCHEDULED に対するテストの AWS Health Event の構造は以下の通りです: 図 3: AWS Health Event スキーマ Python で Lambda 関数をコーディングする際の Tips： 図 3 を参照すると、以下のコードスニペット (python) を使用して affectedEntities を参照することで EC2 インスタンスのインスタンス ID を取得できます: ec2InstanceId= event['detail']['affectedEntities'][0]['entityValue'] 影響を受けた EC2 インスタンスに関連付けられている environment と customEventBus のタグを取得します。これを行うために、EC2 インスタンス ID で インスタンスをフィルタリングし 、タグキーをループ処理してタグ値を取得します。 イベントは environment フィールドを追加するだけで強化されます: event['environment'] = environment 最後に、 put_events API コールを使用してステップ 2 で作成したカスタムイベントバスに強化したイベントを送信します: cloudwatch_events = boto3.client('events') response = cloudwatch_events.put_events( Entries=[ { 'Source': 'modifiedHealthEvent', 'EventBusName': eventBusName, 'DetailType': 'enrichedEvent', 'Detail': json.dumps(event) } ] ) ステップ 5: EventBridge ルールを作成してイベントをカスタムイベントバスから SNS へ送信する EventBridge コンソール に移動します。 右側のパネルから、[使用を開始する] で [イベントブリッジルール] を選択し、[ルールを作成] を選択します。 [ルールの詳細] ページで、[名前] にルールの名前 (例: “send-enriched-events”) を入力し、[イベントバス] でステップ 2 で作成したイベントバス (例：“health-events”) を選択して [次へ] を選択します。 [イベントパターンを構築] ページで [イベントソース] の [イベントソース] で [すべてのイベント] を選択します。他のオプションはすべてそのままにして、[次へ] を選択します。 [ターゲットを選択] ページにおいて、[AWS のサービス] を選択します。[ターゲットを選択] ではステップ 1 で作成した SNS トピック (例：“health-alerts”) を選択します。[次へ] を選択します。 [タグを設定] ページはデフォルトのままにし、[次へ] を選択します。 [レビューと作成] ページで [ルールの作成] を選択します。 ステップ 6: AWS Health イベントを Lambda 関数に送信する EventBridge ルールを作成する EventBridge コンソール に移動します。右側のパネルから、[使用を開始する] で [イベントブリッジルール] を選択し、[ルールを作成] を選択します。 [ルールの詳細] ページで、[名前] にルールの名前 (例: “health-events-rule”) を入力し、[イベントバス] で default を選択します。[次へ] を選択します。 [イベントパターンを構築] ページで [作成のメソッド] まで移動し、[パターンフォームを使用する] を選択します。 [イベントパターン] の [イベントソース] で [AWS のサービス] を選択し、[AWS のサービス] では [Health] を選択します。イベントタイプについては [特定のヘルスイベント] を選択します。[特定のサービス] で [EC2] を選択します。[次へ] を選択します。 図 4: EC2 ヘルスイベントをフィルタリングするためのイベントパターン [ターゲットを選択] ページにおいて、[AWS のサービス] を選択します。[ターゲットを選択] では [Lambda 関数] を選択します。[関数] でステップ 4 で作成した Lambda 関数 (例：“EnrichHealthEvents”) を指定します。[次へ] を選択します。 [タグを設定] ページはデフォルトのままにし、[次へ] を選択します。 [レビューと作成] ページで [ルールの作成] を選択します。 ソリューションのテスト ソリューションをテストするには、Lambda のテスト機能の使用を検討してください。 Lambda コンソール に移動し、ステップ 4 で作成した Lambda 関数を選択します。 [テスト] タブに移動し、図 3 のイベント構造を変更して [ 新しいイベントを作成 ] を行います。 [コード] に移動し、[Test] ドロップダウンで作成したテストイベントを選択します。[Test] を選択します。 これによりテストヘルスイベントがトリガーされ、ステップ 1 で設定したメールアドレスに通知が届くはずです。 これでこの例で提供されているウォークスルーをお客様のビジネスニーズに合わせて変更できるようになりました。リソースとタグに応じて、ご利用の環境でソリューションをテストしてみてください。 まとめ このブログ記事では、AWS リソースに関連するタグを割り当ててアラート通知を自動化し、通知ノイズを減らしながら AWS Health イベントへの応答を改善するフレームワークについて紹介しました。AWS Health イベントを解析し、関連するチーム向けにそれを強化する方法を紹介しました。AWS Health の詳細については AWS Health ドキュメント をご参照ください。 著者について Pranjal Gururani Pranjal Gururani はシアトルを拠点とする AWS のソリューションアーキテクトです。Pranjal はさまざまなお客様と一緒にビジネス上の課題に対処するクラウドソリューションを構築しています。彼はハイキング、カヤック、スカイダイビングを楽しみ、余暇には家族と過ごす時間を楽しんでいます。 John Bickle John Bickle はカナダのモントリオールを拠点とするシニアテクニカルアカウントマネージャー兼エンタープライズサポートリーダーです。John はお客様と緊密に連携してオペレーショナルエクセレンスを実現し、複雑さを軽減し、ダウンタイムをなくすことに喜びを感じています。余暇には音楽、セーリング、写真撮影を楽しんでいます。 Ballu Singh Ballu Singh は AWS のプリンシパルソリューションアーキテクトです。彼はサンフランシスコのベイエリアに住んでおり、お客様が AWS 上でアプリケーションを設計し最適化できるように支援しています。余暇には読書や家族との時間を楽しんでいます。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。