この記事は、 Amazon OpenSearch Service now supports 99.99% availability using Multi-AZ with Standby を翻訳したものです。 お客様は、ミッションクリティカルなアプリケーションや監視に Amazon OpenSearch Service を使用しています。しかし、OpenSearch Service自体が利用できない場合はどうなるのでしょうか? たとえば、E コマースの検索がダウンした場合、収益が失われます。アプリケーションをOpenSearch Serviceで監視している場合、利用できなくなると、アプリケーションの問題を検出、診断、修復する能力が低下します。これらのケースでは、収益の損失、顧客の不満、生産性の低下、あるいは組織の評判へのダメージを被る可能性があります。 OpenSearch Service は、 ベストプラクティス に従うことで 99.9% の可用性のSLAを提供します。しかし、それらのプラクティスを実践するのは複雑で、OpenSearch のデータ配置と管理に関する知識と経験が必要となります。また、OpenSearch Service が AWS のアベイラビリティゾーンやネットワーク、分散システム、OpenSearch の自己回復能力、回復方法とどのように相互作用するかについての理解も必要です。さらに、ノードが応答しなくなるなどの問題が発生した場合、OpenSearch Service は欠落したシャード (データ) を再作成することで回復しますが、これによりドメイン内で大量のデータ移動が発生する可能性があります。 このデータ移動はクラスターのリソース使用量を増加させ、パフォーマンスに影響を及ぼす可能性があります。 クラスターのサイズが適切でない場合、可用性が低下し、3 つのアベイラビリティーゾーンにプロビジョニングする目的を達成できなくなります。 AWS は OpenSearch Service の新しいデプロイメントオプションである Multi-AZ with Standby を発表しました。これにより、高頻度の監視、迅速な障害検出、障害からの迅速な回復などの重労働を軽減し、インフラ障害が発生した場合でもドメインの可用性とパフォーマンスを維持できるようになります。Multi-AZ with Standby を使用すると、ドメインは 99.99% の可用性と一貫したパフォーマンスを実現できます。 この記事では、この新しいオプションのメリットと、Multi-AZ with Standby で OpenSearch クラスターを設定する方法について説明します。 ソリューション概要 OpenSearch Service チームは、お客様のために数万のドメインを運用する中で得た経験を、Multi-AZ with Standby 機能に組み込みました。Multi-AZ with Standby を採用すると、OpenSearch Service は 3 つのアベイラビリティゾーンにまたがるクラスターを作成し、各アベイラビリティゾーンにはクラスター内のデータの完全なコピーが含まれます含めます。次に、OpenSearch Service は1つのアベイラビリティゾーンをスタンバイモードにし、すべてのクエリを他の 2 つのアベイラビリティゾーンにルーティングします。ハードウェア関連の障害を検出すると、OpenSearch Service は 1 分以内にスタンバイプールのノードをアクティブに昇格させます。Multi-AZ with Standby を使用すると、OpenSearch Service は失われたノードからデータを再分配または再作成する必要がありません。その結果、クラスターのパフォーマンスは影響を受けず、可用性が低下するリスクを排除します。 前提条件 Multi-AZ with Standby には、以下の前提条件が必要です : ドメインは OpenSearch 1.3 以上で実行する必要があります ドメインは 3 つのアベイラビリティゾーンにまたがってデプロイされる必要があります ドメインには 3 つ (または 3 の倍数) のデータノードが必要です 3 つの専用クラスターマネージャー (マスター) ノードを使用する必要があります ドメインと専用マスターノードのサイジングのガイダンスについては、 Amazon OpenSearch Service ドメインのサイジング を参照してください。 Multi-AZ with Standby を使用した OpenSearch クラスターの設定 Multi-AZ with Standby は、新しいドメインを作成するときにも、既存のドメインに追加するときにも使用できます。 AWS Management Console を使用して新しいドメインを作成する場合、新しい Easy create オプションまたは従来の Standard create オプションを選択することで、Multi-AZ with Standby を使用して作成できます。既存のドメインは、ドメイン設定を編集することで Multi-AZ with Standby を使用するように更新できます。 Easy create オプションは、名前が示すように、ほとんどの設定をベストプラクティスの選択肢にデフォルトすることで、ドメインの作成を容易にします (大部分は後から変更可能です) 。ドメインは最初から高可用に設定され、Multi-AZ with Standby としてデプロイされます。 データノードを選択する際は、各アベイラビリティゾーンに均等に分散されるように、3 つ (または 3 の倍数) のデータノードを選択する必要があります。OpenSearch Service コンソールの Data nodes テーブルは、アベイラビリティゾーンの 1 つがスタンバイになることを視覚的に表しています。 同様に、専用マスターノードを選択する際には、計画しているデータノード、インデックス、シャードの数を考慮して、インスタンスサイズを決定することをお勧めします。 ドメインが作成されたら、OpenSearch Service コンソールの Cluster configuration で、デプロイメントタイプを確認できます。以下のスクリーンショットを参照してください。 インデックスを作成する際は、コピー数 (プライマリとレプリカ) が 3 の倍数になるようにしてください。レプリカ数を指定しない場合、サービスはデフォルトで 2 を設定します。これは、各アベイラビリティゾーンにデータのコピーが少なくとも 1 つ存在することを保証するために重要です。ログワークロードの場合は、 index template などを使用することをお勧めします。 OpenSearch Service は、ノードとデータコピーを 3 つのアベイラビリティゾーンに均等に分散させます。通常の運用では、スタンバイノードは検索リクエストを受信しません。2 つのアクティブなアベイラビリティゾーンがすべての検索リクエストに応答します。ただし、データはこれらのスタンバイノードにレプリケートされるため、常に各アベイラビリティゾーンにデータの完全なコピーが存在することが保証されます。 インフラ障害イベントへの対応 OpenSearch Service は、ノード障害、ディスク障害、アベイラビリティゾーン障害などのイベントについてドメインを継続的に監視します。アベイラビリティゾーン障害などのインフラ障害が発生した場合、OpenSearch Service は影響を受けたアベイラビリティゾーンが回復する間、スタンバイノードをアクティブに昇格させます。影響を受けたアベイラビリティゾーンからのトラフィックは1分以内に転送されるため、影響 (がある場合) は実行中のリクエストに限定されます。 ドメインのステータス、アクティブおよびスタンバイのデータノードメトリクス、アベイラビリティゾーンのローテーションメトリクスは、 Cluster health タブで確認できます。以下のスクリーンショットは、Cluster health とデータノードのメトリクス ( CPU 利用率、JVM memory pressure 、ストレージなど) を示しています。 以下のスクリーンショットは、 AZ Rotation Metrics セクション ( Cluster health タブの下にあります) で、アベイラビリティゾーンの read と write のステータスを示しています。OpenSearch Service は、イベントに対応できるように準備ができていることを確認するために、30 分ごとにスタンバイのアベイラビリティゾーンをローテーションさせます。トラフィックに応答しているアベイラビリティゾーンは値が 1 で、スタンバイのアベイラビリティゾーンは値が 0 です。 考慮事項 この機能には、より高い可用性を提供し、パフォーマンスを維持するいくつかの改善とガードレールが実装されています。ノードあたりのシャード数、ドメインのシャード数、シャードのサイズに関する特定の静的な制限が適用されています。OpenSearch Service はデフォルトで Auto-Tune も有効にします。Multi-AZ with Standby は、最もコスト効果的で高パフォーマンスなストレージオプションである GP3 または SSD-backed インスタンスにストレージを制限します。さらに、不正なクエリを検出する高度なトラフィックシェイピングメカニズムを導入しており、これによりドメインの信頼性がさらに向上します。 高可用性とパフォーマンスを実現するために、お客様のワークロードに基づいてドメインインフラストラクチャのニーズを評価することをお勧めします。 まとめ Multi-AZ with Standby は、US West (N. California)、 AWS GovCloud (US-Gov-East, US-Gov-West) を除いた OpenSearch Service が利用できるすべてのAWSリージョンで利用できるようになりました。お試しいただき、 AWS re:Post for Amazon OpenSearch Service または通常の AWS サポート窓口までフィードバックをお送りください。 翻訳は Solutions Architect 川岸が担当しました。

皆様の 2024 年のご多幸とご繁栄をお祈りします。 新年を迎えるにあたり、サプライチェーンマネジメントの私の 2024 年の予測を共有したいと思います。 サプライチェーンマネジメントの状況は前代未聞のペースで進化し続けています。 過去数年間、世界中のサプライチェーンの回復力と適応力を示されてきました。 かつてサプライチェーンマネジメントの要であった従来のアプローチは、今ではより統合され技術的に進歩したソリューションに道を譲っています。 このシフトは単なるトレンドではなく、気候変動、地政学的動向、マクロ経済問題、顧客行動の変化など、増え続ける課題に対処するために必要不可欠な進化です。 このブログでは、本年の主な予測を述べ、これらの変化がサプライチェーンマネジメントの未来をどう形作るかに焦点を置きます。 過去、サプライチェーンの問題は、PLM (製品ライフサイクル管理)、WMS (倉庫管理システム)、TMS (輸送管理システム)、OMS (注文管理システム) などの特化したスタンドアロンシステムを導入することで対処されてきました。 これらのシステムは、サプライチェーンの特定の問題を解決するのに効果的でしたが、エンドツーエンドの統合ソリューションを提供したり、大きな課題に効果的に適応したりする能力が不足していました。 2024 年の予測 このように考えると、過去五年間のサプライチェーンマネジメントでは 2 つの重要なトレンドがあったと思います。 第 1 に、組織は、機能横断的かつシステム的な問題に対処するデータファースト戦略をますます採用するようになっています。 このアプローチは、在庫の可視性を高め、在庫の不一致を減らし、消費者の信頼を育みながら、サプライチェーンの混乱に適応できるようにします。 第 2 に、サプライチェーンマネジメントのシンプル化へのトレンドが高まっており、組織は手動のデータ統合方法を機械学習 (ML) ベースのデータ連携に置き換えています。 これは、個別の問題解決から、統合され技術的に進歩したアプローチへの顕著なシフトを表しており、今日のグローバルサプライチェーンの課題の複雑さに対応しています。 これらのトレンドは、サプライチェーンマネジメントに影響を与え続けるでしょう。そして、次の重要な予測にもつながります。 生成系 AI が、意思決定を改善し加速するために、差別化につながらない重労働を解消する。 生成系 AI への関心が高まっていますが、 同時に効果的な展開、使用法、セキュリティ、倫理に多くの混乱が生じています。特にサプライチェーンマネジメントにおいては、多くの混乱があります。2024 年には、生成系 AI がサプライチェーンマネージャーにより良い洞察をもたらし、複雑なシナリオの結果や、サプライチェーン運用における複数の選択肢のトレードオフを発見するのをどのように支援するかについて、より詳細が明らかになっていくでしょう。 サプライチェーンマネジメントは、計算やトレンド分析を支援するために ML などのテクノロジーの採用はゆっくりでしたが、よりスマートで、効率的で、顧客中心のソリューションが必要なことが明確になるでしょう。意思決定を加速するためにデータの層を掘り下げて労働集約的なタスクを自動化することは、生成系 AI にとって理想的なユースケースです。 サプライチェーンリーダーは、複雑なシナリオ、トレードオフ、潜在的な結果に対処するために、会話形式で何、なぜ、もし~ならばと質問することができるようになるでしょう。 生成系 AI は、運用パフォーマンス、サステナビリティ指標、財務健全性の分析を自動化することによって、サプライヤーの監査、評価、選択、置き換えの業務を簡略化するでしょう。 ついにデータが関連付けられ、革新的なサプライチェーンマネジメント機能が利用可能になる。 貴重なサプライチェーンデータはまだデータサイロに分散しており、効果的に使用することが困難です。以前は、真のサプライチェーン可視化を実現するための技術は実装コストがかかりすぎていましたが、大規模言語モデルによるデータ取り込みと変換により、この参入障壁が下がっています。2024 年には、組織のモチベーションが高まり、複数のシステムに分散したデータをより簡単に統合モデルに変換できるようになるでしょう。組織はついに、サプライチェーンのデータを統合してサプライチェーンの意思決定を改善するための実用的、スケーラブル、費用対効果の高いアプローチを手に入れるでしょう。データが増えれば、組織はより良いインテリジェンスと可視性を得ることができます。データを 1 か所に置くことで、組織はついに効果的な生成系 AI 戦略を展開し、生成系 AI モデルから最適なパフォーマンスを引き出すことができます。 デジタルサプライチェーンは、不確実な世界に対する俊敏性を高めるだろう。 生成系 AI を活用したデジタルサプライチェーンは、サプライチェーンのさまざまな意思決定の影響を説明するシナリオのシミュレーションを可能にします。最近の環境、経済、地政学的な問題が示すように、不安定な状況はいつでも、どこでも起こり得ます。デジタルサプライチェーンを利用する組織は、こうした混乱がいつ発生したかに関わらず、回復力を高める可能性があります。 デジタルサプライチェーンは、組織が物理的なサプライチェーンの俊敏性と柔軟性を向上させるのに役立ちます。生成系 AI を使えば、さまざまな変数を用いて数十万ものシナリオを実行して結果を予測し、より正確なガイダンスを提供するでしょう。そうすれば、組織はサプライチェーン全体の効率性、有効性、即応性を最大化するように行動できます。このアプローチにより、組織はデジタルサプライチェーンを用いて正しい意思決定を行い、物理的なサプライチェーンを用いて、その知識に基づいて迅速かつ正確に行動できます。 結論 2024 年を通して、サプライチェーンマネジメントに先進的な技術、特に生成系 AI を統合していくことは、単なる競争上の優位性ではなく、必要不可欠なことになるでしょう。状況の変化にすばやく適応し、情報に基づいた意思決定を行い、運用の効率性を維持する能力が欠かせません。サプライチェーンマネジメントの未来は疑いなくデジタル化の道を進んでいきます。この変化を受け入れる者が、よりレジリエントで効率的、顧客中心のサプライチェーンを生み出す道を切り拓くリーダーとなるでしょう。待ち受ける課題とチャンスをつかむ準備をして、この未来に自信を持って踏み込んでいきましょう。明けましておめでとうございます! 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Diego Pantoja-Navajas は AWS Supply Chain の Vice President で、ビジネスアプリケーションのビジョンの策定と実現を担当しています。彼と彼のチームは、サプライチェーンの機能を根本的に考え直し、世界で初めての継続的に改善するサプライチェーン管理システムを市場に提供することに注力しています。彼は顧客の成功に情熱を注ぎ、SaaS、クラウド、AI/ML テクノロジーを活用して、サプライチェーン、e コマース、フルフィルメントに関連するビジネスの問題を解決するための高度に使いやすく知的な B2B エンタープライズソフトウェアソリューションを構築しています。Diego はジョージア工科大学の優等卒業生で、MIT の人工知能・機械学習のエグゼクティブエデュケーションコースを修了しています。また、IESE ビジネススクール、ミシガン大学ロス・ビジネススクールとのパートナーシップのもと、リーダーシップコースにも参加しています。彼は南フロリダに家族と暮らしており、顧客のビジネスの成功をさらに推進する革新的な製品やソリューションを学ぶことを常に喜んでいます。 <!-- '"` -->

Amazon DynamoDB テーブルでプロビジョンドキャパシティを使用する場合、突然のリクエストトラフィックの増加 (スパイク) に対して、スロットルされることなく対処するための最善の方法を検討するのは課題の一つです。スロットルは、リクエストレートが設定された制限を超えたことを DynamoDB が検知した場合に発生するサービス応答です。たとえば、テーブルの書き込み容量ユニット (WCU) を 10,000 にプロビジョニングしており、トラフィックが 20,000 を消費するレートでアクセスされた場合、やがてスロットルが発生し、スロットルされたリクエストを処理するためリトライをする必要があります。 突発的かつ長時間続くトラフィックスパイクほど、テーブルにスロットルが発生する可能性が高まります。ただし、突発的なトラフィックに対して、スロットルの発生を避けることができないわけではありません。ここでは、トラフィックのスパイクに対処するための 8 つの設計と、それぞれの利点と欠点を紹介します： Auto Scaling とバーストキャパシティを利用する Auto Scaling のターゲット使用率を調整する オンデマンドモードに切り替える バックグラウンド処理をセルフスロットルする バックグラウンド処理をスロースタートする スパイクのタイミングを予測できる場合、Auto Scaling スケジュールを使用する スパイクのタイミングを予測できない場合、積極的に Auto Scaling の調整を使用する 戦略的に一定レベルのスロットルを許容する DynamoDB のスロットルに関する背景 DynamoDB において、読み取りおよび書き込みリクエストがスロットルされる状況は主に 2 つあります。第一に、テーブルへのリクエストレートがテーブルのプロビジョンドキャパシティを超えた場合。第二に、特定のパーティションへのリクエストレートがすべてのパーティションに存在するハードリミットを超えた場合。この投稿では、テーブルレベルのスロットルに焦点を当てています。これらは急激なトラフィックスパイクに最も関連する制限です。 テーブルおよびパーティションの制限について詳しく知りたい場合は、「 DynamoDB のスケーリング: パーティション、ホットキー、Split for heat がパフォーマンスに与える影響 (第 1 部: ローディング) 」を参照してください。 DynamoDB のプロビジョニングされたテーブルでは、プロビジョニングされたスループット容量を割り当てることでテーブルの読み取りおよび書き込みの能力を明示的に制御します。読み取りスループット ( 読み取りキャパシティユニット、または RCU で表される) および書き込みスループット ( 書き込みキャパシティユニット、または WCU で表される) を割り当てます。割り当てるほど、スロットルが発生するまでにテーブルまたはインデックスで実行できる読み取りまたは書き込み作業が増え、時間ごとのコストも上がります。 グローバルセカンダリインデックス ( GSI ) は、ベーステーブルとは異なるプロビジョニングされたスループット容量を持っています。それらの制限はテーブルと同じように機能します。この投稿の残りの部分では、「テーブル」という用語はテーブルとインデックスの両方を指すことがあります。 1. Auto Scaling とバーストキャパシティを利用する 通常、トラフィックは一日中変動します。プロビジョンドキャパシティテーブルでこれを処理するクラシックな方法は、Auto Scaling 機能をオンにすることです。Auto Scaling はテーブル上の消費されたキャパシティを監視し、その応答としてプロビジョンドキャパシティの増減を調整します。最小値 (これ以下にはならないように) 、最大値 (これ以上にはならないように) 、およびターゲット使用率 (プロビジョニングされた合計量に対して、消費されている量をこの割合に保つように試みる) を構成します。Auto Scaling は通常のエンドユーザートラフィックの変動や一時的なスパイクに対処するために調整されます。 Auto Scaling はターゲット使用率を超える 2 分間の消費キャパシティを観測すると、プロビジョンドキャパシティを上方に調整します。利用率がターゲット使用率ラインよりも 20 ％ (相対ではなく、2,000 ベーシスポイントとして) 低い状態を 15 分間観測すると、プロビジョンドキャパシティを下方に調整します。スケールアップはいつでも発生できますが、スケールダウンはより厳格なルールがあります。これは「 Amazon DynamoDB のサービス、アカウント、およびテーブルのクォータ 」で説明されています。 「1 日あたりの DynamoDB テーブルで実行できるプロビジョンドキャパシティーの減少数には、デフォルトのクォータがあります。日付は、協定世界時 (UTC) に従って定義されます。特定の日に、その日に他の減少をまだ実行していない限り、1 時間以内に最大 4 回の減少を実行することから始めることができます。その後、前の 1 時間に減少がない限り、1 時間あたり 1 回追加で減少を実行できます。これにより、1 日で減らすことができる最大の回数は 27 回になります (1 日の中で最初の 1 時間は 4 回、その後は 1 時間ごとに 1 回)。」 「テーブルとグローバルセカンダリインデックスの減少制限は別々に設定されているため、特定のテーブルのグローバルセカンダリインデックスにはいずれも、独自の減少制限が設定されています。」 Auto Scaling は Amazon CloudWatch を使用して消費キャパシティを観測します。CloudWatch メトリクスは即座ではなく、2 分以上の遅延があります。これは Auto Scaling が DynamoDB テーブルを監視する際に、常に少し過去を見ていることを意味します。Auto Scaling はプロビジョニングされた量を変更するために必要なデータが揃うまでに最短 4 分かかります。 Auto Scaling のターゲット使用率は、この時間ウィンドウ内でのトラフィックスパイクに対応するための余裕を提供します。テーブルが 70,000 WCU を消費している場合、70 ％のターゲット使用率を持つ Auto Scaling は 100,000 WCU をプロビジョニングします。追加の 30,000 WCU は、Auto Scaling がより高い量をプロビジョニングできるようになるまでのトラフィックスパイクを処理する余裕 (パディング) です。これにより、最も極端なトラフィックスパイクを除いて、スロットルが発生することはありません。 パディングを超えるスパイクが発生する場合、DynamoDB はバーストキャパシティを提供し、テーブルが一時的にプロビジョニングされたレベルを超えることを許可します。詳細は「 DynamoDB のスケーリング: パーティション、ホットキー、Split for heat がパフォーマンスに与える影響 (第 2 部: クエリの実行) 」を参照してください。バーストキャパシティは常に有効です。 図 1 は典型的な Auto Scaling の動作を示しています。ゆらぎのあるオレンジの線は一日中にわたる 300,000 WCU から 650,000 WCU までの書き込みトラフィックの消費を示しています。水平の青い線は Auto Scaling によって制御されるプロビジョニングされた書き込み容量です。必要に応じて上下に動きます。 図 1 : Auto Scaling の動作 – ゆらぎのあるオレンジの線は書き込みの消費を示し、水平の青い線はプロビジョンドキャパシティです 真夜中直後 (グラフの 3/4 の位置) を注意深く見ると、スロットリングの影響が見られます。オレンジの消費線は 375,000 WCU から 640,000 WCU に急激にジャンプし、520,000 WCU に設定された青いプロビジョンドキャパシティラインをはるかに超えました。この一時的な超過は、バーストキャパシティによって許可されました。スパイクが続き、数分後にはバーストキャパシティが使い果たされたため、オレンジ色の消費ラインがプロビジョニングされたラインまで下がり、Auto Scaling によってプロビジョニングされた青色のラインが上方に引き上げられ、消費が回復するまでの約 1 分かかりました。 (黒い矢印はこの出来事を指しています) 。 図 2 は、4,000 WCU から 18,000 WCU にユーザーロードを急激に増加させ、スロットルを生成するように設計された、1 時間のシンセティックテストを示しています。このシンセティックテストには、本当のユーザー負荷のようなランダムなジッタが含まれていますが、すべて人工的に生成されたものです。そのため、さまざまな動作を微調整して結果をテストすることができます。 この最初のテストのテーブルは、70 ％ のターゲット使用率で Auto Scaling が有効になっています。上側の図には、結果として得られた消費キャパシティ (変動している青い線) とプロビジョンドキャパシティ (四角い赤い線) が表示されています。下側の図には、同じ時間枠内のテーブルのスロットル数が表示されています。スパイクは急で、スロットルを引き起こすのに十分な長さがあります。 注：赤い線は、Auto Scaling イベントログで説明されているとおり、分単位のスケーリング活動を正確に示すために手書きされています。CloudWatch はプロビジョンドキャパシティの情報を分単位では受け取りません。 図 2 : シンセティックテスト – テーブルが 70 ％のターゲット使用率で構成され、トラフィックが 4,000 WCU から18,000 WCU に急増する状況を示しています このテストは、最初に 4,000WCU から 5,000 WCU を消費する比較的平らなトラフィックから始まります。Auto Scaling により、プロビジョンドキャパシティは約 7,500 WCU に維持されます。トラフィックの単純な変動はパディングによって処理されます。そして、13:07 に書き込みトラフィックが急激に 18,000 WCU にジャンプします。最初はスロットリングは発生しません。バーストキャパシティが余剰の使用を許可します。しかし、13:11 にはバーストキャパシティが尽き、書き込みレートはプロビジョニングされた量に下がり、他のすべてのリクエストはスロットリングされます。スロットリングは 13:13 まで続き、その後、Auto Scaling によってプロビジョンドキャパシティは 26,000 WCU まで増加します。これは、スパイクに対処するのに十分な量であり、別のスパイクがあった場合に備えたパディングも行われます。最終的に、スパイクが収束してから約 15 分後に、Auto Scaling はプロビジョニングされた量を元に戻します。 この投稿の残りの部分では、デフォルトの Auto Scaling では処理できない、非常に急激で持続的な読み取りまたは書き込みトラフィックの増加のシナリオを含むアクセスパターンを持つテーブルがある場合の設計について検討します。 2. Auto Scaling のターゲット使用率を調整する 考慮すべき調整の一つは、Auto Scaling のターゲット使用率を低く設定することです。これは、予測できない時間にエンドユーザーのトラフィックが予想外に発生し、スロットルを回避して低いレイテンシを維持したい場合に効果的です。 Auto Scaling のターゲット使用率は、テーブルがスパイクを処理するために手元に保持するパディングの量を制御します。これは 20 ％から 90 ％までの範囲で設定できます。低い値はより多くのパディングを意味します。例えば、ターゲットが 40 ％の場合、現在のトラフィックレベルの 1.5 倍をパディングに割り当てます。つまり、10,000 WCU をアクティブに消費しているテーブルは、40 ％のターゲットを達成するために 25,000 WCU をプロビジョニングします。低いターゲット使用率には 3 つの利点があります。 スパイクを処理するためにより多くのパディングが提供される。 スパイクがプロビジョニングされたレベルを超える場合、バーストキャパシティの許容が増加する。なぜなら、バーストキャパシティの許容はプロビジョニングされた量に比例しているためです。 Auto Scaling をより迅速に立ち上げることができます。Auto Scaling は、消費されたキャパシティがどれだけターゲット使用率を超えて増加したかを見て、どれだけ増やすかを決定します。スロットルの数は考慮しません。より多くのパディングがあると、予期せぬスパイクのうちの大部分が検知され、それを使用して大きなジャンプを計算できます。パディングがほとんどない場合、スパイクはより抑制されて見え (容量を消費する代わりにスロットルが発生するため) 、Auto Scaling はより小さなステップで進みます。 デメリットはコストの増加です。プロビジョニングされた量に基づいて料金が発生するため、より多くのパディングはより多くのコストを意味します。また、Auto Scaling がトラフィックのスパイクに応じてプロビジョンドキャパシティを上方に調整するたびに、再び下方に調整するまでに一定時間がかかる可能性があります。その期間中には追加のコストがかかります。スロットルとコストのバランスを見て、適切なターゲット使用率を選択します。 Auto Scaling のターゲット使用率を調整する場合は、ベーステーブルだけでなく、GSI (グローバルセカンダリインデックス) も考慮することを忘れないでください。 図 3 は、以前と同じトラフィックパターンを再現していますが、今回はターゲット使用率を 60 ％に設定しています。スロットリングは発生しません。 図 3 : シンセティックテスト – テーブルが 60 ％のターゲット使用率で構成され、トラフィックが 4,000 WCU から 18,000 WCU に急増する状況を示しています。今回はスロットルが発生していません。 低いターゲット使用率はより多くのパディングを提供しました。テストの最初の 10 分間では、Auto Scaling は前回のテストとは異なり、7,500 WCU ではなく 9,000 WCU に近くプロビジョニングしました。18,000 WCU への急激なジャンプは 14:28 に発生し、14:35 には Auto Scaling がプロビジョニングされた量を上方に調整しました。図 2 と同じくらいの大きなスパイクが発生しても、低いターゲット使用率のテーブルでは一切スロットルが発生しませんでした。 ここで低いターゲット使用率が提供した 2 つの利点は次の通りです。まず第一に、余分なパディングがあったため、スパイク中に必要なバーストキャパシティが少なかったことです。第二に、スパイク前に高いプロビジョニング量を確保しておくことで、消費できるバーストキャパシティがより多くなっていました。この組み合わせにより、このシナリオでは一切スロットルが発生しませんでした。 3. オンデマンドモードに切り替える スロットルの回避が最優先の場合に考慮すべき有用なデザインの一つは、テーブルを オンデマンドモード に変更することです。 オンデマンドでは、価格は完全に消費量に基づいています。各リクエストにはわずかな料金が発生します。秒ごとに一定量の RCU および WCU を割り当てて時間単位で支払うのではなく、リクエストごとに読み取りリクエストユニット (RRU) または書き込みリクエストユニット (WRU) を消費します。オンデマンドではプロビジョニングはなく、自動スケールアップやスケールダウンも必要ありません。急増するワークロードや予測不可能なワークロードに最適です。 オンデマンドテーブルは、突然のトラフィックスパイクに対するスロットリングの発生確率を大幅に減少させます。オンデマンドテーブルは、2 つの理由でのみスロットリングします。まず第一に、パーティションの制限を超えた場合 (プロビジョニングモードと同じ) 。第二に、テーブルへのトラフィックがアカウントのテーブルレベルの読み取りまたは書き込みスループット制限を超える場合です。これらはデフォルトで 40,000 のガードレールに設定されていますが、これをより高く設定することは可能で、より高く設定しても追加料金は発生しません。 図 4 は、同じトラフィックパターンを再現していますが、今回はオンデマンドモードのテーブルです。プロビジョニングされた値はありません (赤い線はありません) し、テーブルレベルのスロットルもありません。 図 4 : オンデマンドモードはトラフィックの急激な増加に対して即座に反応するため、スロットリングが発生しません テーブルをオンディマンドに設定して、そのまま使うことができます。プロビジョニング、ターゲット使用率、スケールアップまたはスケールダウンについて考える必要はありません。テーブルはプロビジョニングモードとオンデマンドモードの間で自由に切り替えることができます。テーブルは 24 時間ごとにオンデマンドモードに切り替えることができます。また、テーブルはいつでもプロビジョニングモードに戻すことができます。テーブルをオンデマンドモードに変更して、1 日のうちスパイクが予想される時間に使用し、他の滑らかなトラフィック時間帯に対してはプロビジョニングモードに変更すると便利かもしれません。 オンデマンドテーブルはプロビジョニングテーブルよりも高価であるという一般的な誤解があります。時にはそうであり、時にはそうではありません。比較的平坦なトラフィックの場合、コストの面でプロビジョニングモードが優れています。ワークロードにトラフィックスパイク (急激な上昇と下降) が多いほど、オンデマンドモードの方がコスト優位になります。十分なスパイクがあれば、オンデマンドモードがより低コストの選択肢になる可能性があります。なぜなら、オンデマンドモードはすべてのパディングに関連する追加のコストを回避し、スパイク後のダウンサイジングの待ち時間がないからです。 数学的には、プロビジョニングされたテーブルの達成利用率が 15 ％未満の場合、オンデマンドモードはより低コストな選択肢になります。達成された使用率は、消費されたキャパシティの合計を、その月のプロビジョンドキャパシティの合計で割ったものとして計算されます。ダウンサイジングの遅れのため、ターゲット使用率よりも低くなります。 4. バックグラウンド処理をセルフスロットルする トラフィックの急増が、ある程度制御できるバックグラウンド処理によって引き起こされている場合は、バックグラウンド処理をセルフスロットルさせるという別のオプションを検討する必要があります。基本的には、バックグラウンド処理の消費レートを制限させることで、エンドユーザーのトラフィックと過度に競合しないようにし、必要な Auto Scaling の増加を抑制します。 大幅なスパイクは、背後で何らかのバックグラウンドアクティビティが行われることが原因となることがよくあります。新しいデータセットのロード、日次アイテムのリフレッシュ、履歴データの選択的な削除、または分析のためにテーブルをスキャンするなどの状況では、バックグラウンド処理がどのように振る舞うかを制御できるかもしれません。 バックグラウンド処理がセルフスロットルのレートで実行されるようにします。通常の Auto Scaling のパディングに簡単に収まるようなレートを選択します。このようにすると、開始時にはスロットリングを引き起こさず (ホットパーティションがないと仮定) 、Auto Scaling はテーブルに必要なパディングを復元するために上方に調整できます。もし外部のパーティーがスパイキートラフィックを駆動させている場合は、アプリケーションアクセスポイントで各外部パーティをレートリミットできるかどうかを検討してください。 バルク処理は、各リクエストで ReturnConsumedCapacity を要求し、1 秒あたりどれだけの容量を消費しているかを追跡することで、セルフスロットルできます。消費量が高すぎる場合は、処理を遅くすることができます。複数の別々のクライアントプロセスを使用している場合、クライアントごとに一定の最大容量消費率を許可することができます。 次の図は、セルフスロットルのバルク処理がスパイクのサイズを制限し、スロットリングを回避する様子を示しています。テーブルは再び図 2 と同じく 70 ％のターゲット使用率を持っていますが、今回はバルク処理タスクが少し遅く、少し長く実行されるようになっているため、リクエスト率はわずか 14,000 WCU にしか上昇していません。 図 5 : 18,000 WCU ではなく 14,000 WCU にジャンプすることで、スロットリングが回避されます 14,000 WCU への小さなスパイクは、スパイク中に消費されるバーストキャパシティが少なくなり、テーブルがスロットリングする前に Auto Scaling が上向きに調整するための時間を与えます。 このセルフスロットルのアプローチは、バックグラウンド処理が穏やかなペースで実行されることが許容される場合に機能します。その場合、これには Auto Scaling が上方に調整する量を制限するという追加の利点があります。バックグラウンド処理が 10 分間で一定の 4,000 WCU または 5 分間で 8,000 WCU を消費する場合を想像してみてください。オンデマンドテーブルではこれら 2 つのオプションは同じ価格です。ただし、Auto Scaling を使用するプロビジョニングテーブルでは、より穏やかなジョブはより小さな Auto Scaling の増加を引き起こします。Auto Scaling の減少を 1 時間待たなければならない場合、それははるかに低いプロビジョニングキャパシティでの 1 時間です。ここでのテスト結果では、ピークのプロビジョニングが 20,000 WCU であることがわかります。これは元のテストの 26,000 WCU からの減少です。 このアプローチはスパイクをプラトーに変え、Auto Scaling を使用したプラトーは通常より低いコストになります。 5. バックグラウンド処理をスロースタートさせる できるだけ早く完了させたいバックグラウンド処理があり、エンドユーザーのトラフィックに影響を与えるスロットルの発生リスクを避けたい場合は、バックグラウンド処理をスロースタートさせることができます。 スロースタートは、前述のようにワークがセルフスロットルすることを必要としますが、最初は緩やかに始め、数分ごとにリクエスト率を増加させます。この緩やかな開始の挙動により、Auto Scaling は需要の増加に対応するための時間を確保できます。スポーツと同様に、何かを壊さないように最初にウォームアップすることが望ましいのです。 この前のオプションと比較して、これは潜在的なコスト削減を提供しませんが、テーブルレベルのスロットリングとエンドユーザートラフィックとの競合のリスクを制限し、 (ウォームアップ後には) 任意に高速なリクエスト率 (構成された Auto Scalingの最大値およびアカウントレベルおよびテーブルレベルの制限のみによる制限) を可能にします。 以下の図は、スロースタートが Auto Scaling のパディング内に収まり、スロットリングを回避するだけでなく、容量を増やす必要性について Auto Scaling にシグナルを送ることができた様子を示しています。 図 6 : バックグラウンド処理のスロースタートにより、Auto Scaling が適応する時間が確保されます 22:49 から 23:00 の間に、トラフィックは 4,000 から 9,000、次に 14,000、最後に 18,000 へと段階的に増加しました。このスロースタートにより、Auto Scaling はバーストキャパシティが消耗される前に独自の増加を行うための十分な時間がありました。テストは元のテストと同じ 18,000 WCU のレートに達し、同じ 70 ％のターゲット使用率ですが、スロースタートを始めることですべてのスロットリングを回避しました。 6. スパイクのタイミングを予測できる場合は、Auto Scaling スケジュールを使用する スパイクがあり、それが予測可能な場合 (たとえば、毎日午前 5 時に大量のロードを実行するか、毎朝午前 9 時にエンドユーザーリクエストが存在しない状態から急激に増加する場合など) 、 スケジュールされたスケーリング を使用できます。 スケジュールされたスケーリングでは、テーブルの最小値と最大値を日時に応じて異なる値に設定できます。 スケジュールされたアクション を制御するために crontab の表現力を最大限に活用できます。 たとえば、スパイクが来ることがわかっており、それがどのくらいの量かも知っている場合、スパイクを処理できるように Auto Scaling の最小値を大きくすることで、テーブルのプロビジョンドキャパシティを増やすことができます。スパイクが始まると最小値を下げることができます。最小値を下げることはプロビジョンドキャパシティを下げるわけではありません。実際の消費が減少するのを確認した時に、Auto Scaling がそれを下げるだけです。 次の図はトラフィックのスパイクがそのレートにジャンプする 2 分前に、Auto Scaling の最小値を 18,000 WCU に調整するというスケジュールされたアクションを示しています。 図 7 : 予測可能なスパイクの前に積極的にスケールアップした場合 この積極的な Auto Scaling の最小値の調整により、いかなるスロットリングも回避されました。18,000 への最初の上昇はスケジュールされたアクションでした。33,000 への 2 回目の上昇は、実際のトラフィックに対応し、必要なパディングを追加するための Auto Scaling の反応でした。 7. スパイクのタイミングを予測できない場合は、積極的に Auto Scaling の調整を要求する 正確なスパイクのタイミングを予測することはできないが、それが始まりそうなタイミングを検知することができる場合は、積極的に Auto Scaling の調整をリクエストすることができます。 たとえば、朝に大量のバルク処理があることを知っているが、具体的な時刻はわからないという場合を考えます。この場合、バルク処理が始まるときに、特定のキャパシティの引き上げをプロアクティブに要求することができます。あるキャパシティ量を要求するために「準備しろ、今行くぞ」というコールをして、遅延を発生させずにテーブルを調整するイメージです。 実際には、テーブルのプロビジョンドキャパシティを上方に調整するのは非常に速いです。通常、1 分未満で行われます。唯一の注意点は、テーブルのプロビジョニングされた制限を、以前に設定された制限よりも高く上げる場合です。このように新しいハイウォーターマークを設定すると、テーブルはその容量を大きくする必要があり、この増強には時間がかかることがあります。この増強が迅速に達成できるようにするためのベストプラクティスは、テーブルとインデックスを一度、最大の読み取りおよび書き込みレベルでプロビジョニングし、その後再びダウンスケーリングする前に、本番で必要な最大のレベルに設定することです。これにより、後のキャパシティ引き上げを迅速に行うことができます。これをテーブル作成時に行うことができる場合は、それが最速の方法となります。 では、Auto Scaling テーブルのプロビジョンドキャパシティを積極的に増やす方法について説明します。テーブルを直接更新すると、Auto Scaling は変更を認知せず、独自の Auto Scaling アクションで変更を元に戻す可能性があります。より信頼性の高い手法は、Auto Scaling の最小値を新しいプロビジョンドキャパシティとして設定することです。これにより、Auto Scaling はプロビジョンドキャパシティを増やし、また、その発生を認識します。 キャパシティの各リクエスタはコーディネーターにアクセスし、テーブルまたは GSI に一定量の追加キャパシティを要求し、それが届くのを待ってから、遅延なく、かつテーブルレベルのスロットリングを引き起こすことなく開始するべきです。 コーディネーターは各リクエストを受け取り、現在のトラフィックを調査し、要求されたキャパシティを追加し、新しい Auto Scaling の最小値を割り当てます。数分後、バルクワーカーのアクティビティがバルク処理の終了までプロビジョニングレベルを高い要求値に保つことを信頼して、最小値を元の値に戻すことができます。ダウンスケールのタイミングを注意深く計る必要はありません。テーブルを素早くアップスケールするだけです。 最終的な結果は、図 7 と同じように見え、同じように振る舞いますが、事前にタイミングを知る必要がないという違いがあります。 8. 戦略的に一定のスロットリングを許可する 最後に考慮すべきデザインは、アプリケーションデザインでスロットリングを戦略的に許可することです。確実に低いレイテンシであることが厳密な要件でない場合はこれを検討してみてください。一部のスロットリングを受け入れることは、コスト効果が高い選択肢となり得ます。 スロットリングは致命的ではありません。また、データベースに損傷を与えることはありません。単にレイテンシを増加させるだけです。 例えば、エンドユーザートラフィックがないテーブルに対してバルク処理を実行している場合、バルク処理がテーブルの最大容量と同じかそれ以上で実行されることで、途中でいくつかのスロットリングが発生するのがちょうどいいかもしれません。スロットルをなくすために容量を上げた場合よりも負荷は少し長くかかりますが、コストは一定になり、すべてのキャパシティが使用されるため、パディングやその他の考慮は必要ありません。 ただし、テーブルにエンドユーザートラフィックが同時に存在する場合、このようなバルク処理を実行すると、エンドユーザーが彼らの書き込みでスロットリングに遭う可能性があり、これはエンドユーザーに認知されるレイテンシを増加させ、問題になるかもしれません。戦略的にスロットリングを許可する選択肢は、クライアントが低レイテンシを必要としない場合に最も適しています。 デフォルトでは、SDK による呼び出しはスロットリングの応答を検知した場合、リクエストを再試行します。これは SDK 自身が行うため、クライアントはスロットリングが発生していることに気付かないことがよくあります。リクエストは数回再試行され、成功すると、クライアントにとっては成功した (通常よりも高いレイテンシのある) リクエストのように見えます。SDK が実行可能なリトライカウントを超えるまで失敗した場合にのみ、プロビジョニングされたスループットが超過した例外が発生します。この例外が表示された場合は、例外をキャッチして (まだ作業が必要な場合は) リクエストを再試行する必要があります。最終的には、リクエストは成功します。テーブルが 10,000 RCU でプロビジョニングされている場合、ミリ秒ごとにリクエスト処理に利用可能な RCU は 10 増加します。 スロットリングイベントは CloudWatch に ReadThrottleEvents 、 WriteThrottleEvents 、 ThrottledRequests として表示されます。スロットルされたクライアントの数が少ない場合、クライアントが成功する前に一連の迅速な自動再試行を実行すると、大量のスロットリングイベントが生成される可能性があります。このため、正確なカウントよりもスロットリングイベントの大まかで相対的な大小に焦点を当てるべきです。また、スロットリングはテーブルレベルで発生する可能性がありますが、ホットパーティションがある場合はパーティションレベルでも発生する可能性があります。CloudWatch メトリクスはこの 2 つを区別しませんが、 CloudWatch Contributor Insights はこのデバッグに役立ちます。 まとめ Auto Scaling とバーストキャパシティは、大規模なトラフィックの急激で持続的な増加に対処できますが、急激で持続的な増加ほど、テーブルでスロットリングが発生する可能性が高くなります。 Auto Scaling のターゲット使用率を下げることで、トラフィックの増加に対する余裕を増やすことも、テーブルをオンデマンドモードに切り替えて、設定して忘れるという選択をすることもできます。 サージがバックグラウンド処理によって引き起こされる場合 (大規模で持続的なサージの場合がよくあります) 、バックグラウンド処理をセルフスロットルして消費量を低く抑えるか、または Auto Scaling が適応するのに十分な時間をかけて徐々に開始するようにすることができます。 サージのタイミングを事前に知っている場合は、Auto Scaling の変更をスケジュールして、スループットの最小値をサージを処理するのに十分な値に上げることができます。事前にサージのタイミングがわからない場合でも、開始の瞬間を特定できる場合は、Auto Scaling の増加を積極的にリクエストすることができます。 最後に、低レイテンシが必要ではない場合は、戦略的に一定のスロットリングを許可することを検討できます。 変更を行う際は、関連する GSI の設定も調整することを忘れないでください。 コメントや質問がある場合は、コメントセクションにコメントを残してください。 AWS Database Blog で Jason Hunter によって書かれた DynamoDB の投稿 やその他の投稿を見つけることができます。 (本記事は 2023/09/20 に投稿された Handle traffic spikes with Amazon DynamoDB provisioned capacity を翻訳した記事です。翻訳は Solutions Architect の嶋田朱里が担当しました。) 著者について Jason Hunter は Amazon DynamoDB に特化したカリフォルニア拠点の Principal Solutions Architect です。彼は 2003 年から NoSQL データベースに携わっています。また、Java、オープンソース、およびXML への貢献で知られています。 &nbsp; &nbsp; Puneet Rawal は AWS データベースに特化したシカゴ拠点の Sr Solutions Architect です。彼は 20 年以上の経験を持ち、大規模なデータベースシステムの設計と管理に従事しています。

1月16日、 AWS Supply Chain 用の 3 つの新しいモジュールがリリースされました。これらのモジュールは、サプライチェーンの各サイトで最適な在庫レベルを維持することを目的として、サプライチェーンのすべての階層にわたるサプライヤーとの連携を支援するために設計されています。概要を以下に示します。 Supply Planning – このモジュールは、原材料、部品、完成品の購入を正確に予測して計画するのに役立ちます。複数のアルゴリズムを使用して、発注書と在庫移動要件を含む供給計画を作成します。 N-Tier Visibility – このモジュールは、エンタープライズの内部システムを越えて、可視性とコラボレーションを取引パートナーの複数の外部階層にまで拡大します。 Sustainability – このモジュールは、二酸化炭素排出量に関するデータに加えて、商品の取得、製造、輸送、廃棄に使用された有害物質に関するレポートをリクエスト、収集、確認するためのより安全で効率的な方法を提供します。取引パートナーの複数の階層へのデータリクエストの送信、回答の追跡、欠席者へのリマインダーの送信、回答を保存および表示するための中央のリポジトリの提供が可能になりました。 各機能を見ていきましょう。 Supply Planning AWS Supply Chain には、独自の機械学習アルゴリズムを使用して需要を予測し、2 年以上前の過去の注文品目データに基づいて需要計画を生成する Demand Planning モジュールが既に含まれています。予測は、流通センターや小売店を始めとして、詳細で具体的です。 新しい Supply Planning モジュールは、需要計画を入力として使用します。既存の在庫を調べ、不確実性を考慮して、在庫戦略を含む追加のビジネス入力をサポートします。最終的に、コンポーネントと原材料のレビューと承認用の発注書が生成されます。Supply Planning モジュールのメインページを以下に示します。 このモジュールは、自動補充と製造計画もサポートしています。製造計画は、複数の直接および間接的な上流供給元から調達された個々のコンポーネントに分解 (展開) された部品表 (BoM) から逆算して進められます。 供給計画は、計画範囲と計画スケジュールに基づいて行われます。計画範囲と計画スケジュールは、どちらも組織プロファイルで定義されます。 このモジュールの設定では、発注書のレビューと承認をカスタマイズすることもできます。 N-Tier Visibility このモジュールは、直接のベンダー、ベンダーに供給するベンダーなどと連携して作業するのに役立ちます。ベンダーが自動的に検出され、 AWS Supply Chain へのオンボーディングがセットアップされます。このモジュールは、発注書に関する手動および EDI によるコラボレーションをサポートする一方で、不一致やリスクを特定し、必要に応じて代替ベンダーを見つけるのにも役立ちます。 モジュールのメインページには、取引パートナーの概要が表示されます。 ポータルのステータス 列には、既にオンボーディングされているパートナー、招待済みのパートナー (および招待の有効期限が切れているパートナー)、まだ招待されていないパートナーが表示されます。 [Invite partners] をクリックして招待を延長できます。パートナー (通常、Supply Chain データレイクのデータを使用して自動的に検出) を選択し、 [Continue] をクリックします。 次に、選択した各パートナーの連絡先情報を入力し、 [Send invites] をクリックします。 連絡先は E メールで招待状を受け取り、招待を承認できます。招待を承認したパートナーは、供給計画と発注書を (E メールまたは EDI 経由で) 電子的に受け取って対応できます。 Sustainability Sustainability モジュールは、パートナーからのコンプライアンスおよびサステナビリティデータを要求、受信、レビューするために役立ちます。これは、既に説明したパートナーネットワークに基づいて構築されており、データのリクエストを追跡します。 データをリクエストするには、必要なデータのタイプとデータが必要なパートナーを選択し、 [Continue] をクリックします。 次に、期日など、リクエストを定義する詳細を入力します。選択したパートナーにテキストメッセージでの応答やファイルでの応答を依頼できます。 各パートナーから提供された回答とファイルは Supply Chain データレイクに書き込まれ、 Amazon Simple Storage Service (Amazon S3) バケットにエクスポートすることもできます。 AWS Supply Chain のリソース AWS Supply Chain を初めて使用する際に詳細が必要な場合は、使用開始に役立つリソースが用意されています。 AWS Supply Chain – ホームページ。 AWS Supply Chain の一般提供が開始されました — 可視性の向上と実用的なインサイトによるリスクの軽減とコストの削減 – ブログ投稿。 AWS Supply Chain が上流における新機能を発表します – ブログ投稿。 AWS Supply Chain によるライフサイクルの異なる製品の需要計画の改善 – ブログ投稿。 AWS Supply Chain: Helping Woodside Energy optimize their supply chain – 動画。 – Jeff ; 原文は こちら です。

新年の始まりである 1 月に何か新しいことを学ぼうという抱負を持った方も多いと思います。何か新しいことを学び、無料の Amazon Web Services (AWS) 学習バッジ を取得することを考えている場合は、新しい Events and Workflows ラーニングパス をチェックしてみてください。 このラーニングパスでは、 AWS Step Functions 、 Amazon EventBridge 、イベント駆動型アーキテクチャ、サーバーレスについて理解すべきことをすべて学習できます。ラーニングパスの終了時には評価を受けることができます。評価に合格すると、 Credly から提供される AWS 学習バッジを履歴書やソーシャルメディアのプロフィールで共有できます。 1月8日週のリリース 1月8日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 Amazon Route 53 – Route 53 Resolver DNS Firewall を有効にして、DNS クエリ形式の質問セクションに含まれるクエリタイプに基づいて DNS トラフィックをフィルタリング できるようになりました。さらに、 Route 53 は、DNS レコードの追加のルーティングポリシーとして地理的近接性ルーティングをサポート するようになりました。リソースへのトラフィックのルーティングを行う地理的領域を拡大または縮小するには、レコードのバイアス値を変更します。これは、応答性の高いデジタルエクスペリエンスを提供する必要がある業界にとって非常に役立ちます。 Amazon CloudWatch Logs – CloudWatch Logs がアカウントレベルのサブスクリプションフィルターの作成をサポートするようになりました。 この機能を使用すると、アカウントのすべてのロググループを Amazon OpenSearch Service や Amazon Kinesis Data Firehose などのその他のサービスに転送することができます。 Amazon Elastic Container Service (Amazon ECS) – Amazon ECS が Amazon Elastic Block Store (Amazon EBS) と統合した結果、EBS ボリュームをプロビジョニングして、 AWS Fargate および Amazon Elastic Cloud Compute (Amazon EC2) の両方で実行する Amazon ECS タスクにアタッチできるようになりました。この機能が実際に使用されている様子を紹介する Channy のブログ記事 を参照してください。 Amazon EventBridge – EventBridge が EventBridge バスのターゲットとして AWS AppSync をサポートするようになりました。 .これにより、バックエンドアプリケーションからフロントエンドクライアントにリアルタイムの更新をストリーミングすることが可能になります。例えば、バックエンドで注文ステータスが変化したときに、行った注文からモバイルアプリケーションで通知を受け取ることができます。 Amazon SageMaker – SageMaker が機械学習 (ML) インターフェイス向けに M7i、C7i、および R7i インスタンスをサポートするようになりました 。これらのインスタンスは、カスタムの第 4 世代 Intel Xeon スケーラブルプロセッサを搭載し、前の世代のプロセッサよりも最大 15% 優れた価格パフォーマンスを実現しています。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 皆さんが見逃した可能性がある、その他の更新情報とニュースです。 1月15日週、 サーバーレス愛好家 の方向けに、 AWS Compute ブログ で、 2023 年の最終四半期のサーバーレス ICYMI の四半期ごとのまとめが公開されました (見逃した場合のため) 。この投稿は、10 月、11 月、12 月に行われた発表に加えて、その期間に AWS デベロッパーアドボケートが作成したすべての関連コンテンツをまとめたものです。このブログ投稿に加えて、AWS re:Invent 2023 で公開された新しいデモアプリケーション ServerlessVideo についても学ぶことができます。 1月15日週は、お客様が直面する一般的な課題を解決する方法を説明する非常に興味深いいくつかのブログ記事もありました。1 つ目は、 Amazon Cognito ユーザープールのアクセストークンをカスタマイズする方法 を説明する AWS Security ブログのブログ投稿です。2 つ目は、 Amazon DynamoDB を使用してデータを効果的にソートする方法 を説明する AWS Database ブログの記事です。 AWS の公式ポッドキャスト &nbsp;– 最新の AWS ニュースや興味深いユースケースの詳細情報を毎週お届けします。AWS の公式ポッドキャストは、数か国語で配信されています。 フランス語 、 ドイツ語 、 イタリア語 、および スペイン語 のポッドキャストもぜひご利用ください。 AWS オープンソースニュースレター &nbsp;– 私の同僚である Ricardo &nbsp;が厳選した情報をお届けする ニュースレター では、最新のオープンソースプロジェクト、記事、イベントなどが取り上げられています。 トルコのお客様 については、2024 年 1 月 1 日、AWS Turkey Pazarlama Teknoloji ve Danışmanlık Hizmetleri Limited Şirketi (AWS Turkey) が AWS EMEA SARL (AWS Europe) からトルコのお客様向けの 契約当事者 およびサービスプロバイダーの業務を引き継ぎました。これにより、トルコの AWS のお客様は、現地通貨 (トルコリラ) と現地の銀行との取引が可能になります。AWS Turkey の詳細については、 よくある質問ページ を参照してください。 AWS の今後のイベント 今年の初めは、今後 2 か月間に世界中で開催される AWS re:Invent の要約シーズンです。 要約ページ をチェックして、最寄りのイベントを見つけることができます。 開催予定の AWS 主導の対面イベントや仮想イベント 、および AWS DevDay などの 開発者向けイベント のすべてを閲覧できます。 1月15日週はここまでです。次週再びアクセスして、新たな Week in Review をぜひお読みください! –&nbsp; Marcia この記事は、 Weekly Roundup &nbsp;シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

大企業や中小企業を問わず、多くの組織がアマゾン ウェブ サービス(AWS)上で分析ワークロードの移行と近代化に取り組んでいます。AWS への移行にはさまざまな理由がありますが、主な理由の 1 つは、インフラストラクチャのメンテナンス、パッチ適用、モニタリング、バックアップなどに時間を費やす代わりに、フルマネージドサービスを利用できることです。リーダーシップと開発チームは、現在のインフラストラクチャのメンテナンスではなく、現在のソリューションの最適化や新しいユースケースの実験などにより多くの時間を費やすことができます。 AWSを利用することでスピードを上げられる一方で、スケール拡大に伴い受信および処理データに対して責任を持つ必要性が生じます。これらの責任には、データプライバシー法および規制を順守すること、個人を特定できる情報 (PII) や上流のソースからの保護された健康情報 (PHI) などの機密データを非公開のまま保存することが含まれます。 この投稿では、データプライバシーの懸念に対処するために大量の開発時間を費やす必要なく、組織のデータプラットフォームをスケールし続けることができる方法を示す、ハイレベルなアーキテクチャと具体的なユースケースについて説明します。個人を特定できる情報 (PII) データを Amazon OpenSearch Service にロードする前に、 AWS Glue を使用して検出、マスキング、編集を行います。 ソリューションの概要 次の図は、高レベルのソリューションアーキテクチャを示しています。 設計のすべてのレイヤーとコンポーネントは、 AWS Well-Architected Framework Data Analytics Lens に沿って定義されています。アーキテクチャは、次のコンポーネントで構成されています。 ソースデータ データは、データベース、ファイル転送、ログ、SaaS(Software as a Service) アプリケーションなど、数十から数百のソースから送られてくる可能性があります。組織は、これらのチャネルを通じて流れ込んできたデータや、ダウンストリームのストレージやアプリケーションに入ったデータを常にコントロールできているとは限りません。 取り込み: データレイクのバッチ、マイクロバッチ、ストリーミング 多くの組織では、バッチ、マイクロバッチ、ストリーミングジョブなど、さまざまな方法でソースデータをデータレイクに取り込んでいます。 例えば、 Amazon EMR 、 AWS Glue 、 AWS Database Migration Service (AWS DMS) は、 Amazon Simple Storage Service (Amazon S3) 上のデータレイクにシンクするバッチおよび/またはストリーミング操作を実行するために使用できます。 Amazon AppFlow は、さまざまな SaaS アプリケーションからデータレイクにデータを転送するために使用できます。 AWS DataSync と AWS Transfer Family は、さまざまなプロトコルを介してデータレイクへのファイルの移動を支援できます。 Amazon Kinesis と Amazon MSK にも、Amazon S3 上のデータレイクに直接データをストリーミングする機能があります。 S3 データレイク データレイクに Amazon S3 を使用することは、モダンなデータ戦略に沿っています。Amazon S3 は、パフォーマンス、信頼性、可用性を犠牲にすることなく、低コストのストレージを提供します。 このアプローチでは、必要に応じてコンピューティングリソースをデータに紐づけ、実行に必要な容量分のみを支払うことができます。このアーキテクチャでは、機密データを含む可能性のある様々なソース(内部および外部)から生データが来ることがあります。 AWS Glue Crawler を使用することで、データを発見およびカタログ化できます。これによりテーブルスキーマが構築され、最終的には AWS Glue ETL と PII 変換を用いたデータレイク内の機密データ検出、マスクおよび編集が容易になります。 ビジネスコンテキストとデータセット アプローチの価値を示してみましょう。あなたは金融サービス機関のデータエンジニアリングチームのメンバーであるとします。要件は機密データを検出し、組織のクラウド環境に取り込まれる際にマスキングすることです。このデータはダウンストリームの分析プロセスで利用されます。将来的には、内部銀行システムから収集したデータストリームに基づいて、過去の支払い取引を安全に検索できるようになります。運用チーム、顧客、インターフェースアプリケーションからの検索結果は、機密フィールドについてはマスキングする必要があります。 次の表は、このソリューションで使用されるデータ構造を示しています。明確化のために、生の列名を整理された列名にマッピングしています。このスキーマ内の複数のフィールド(名、姓、社会保障番号(SSN)、住所、クレジットカード番号、電話番号、Eメール、IPv4アドレスなど)が機密データと見なされることに注意してください。 生データの列名 修正後の列名 型 c0 first_name 文字列 c1 last_name 文字列 c2 ssn 文字列 c3 address 文字列 c4 postcode 文字列 c5 country 文字列 c6 purchase_site 文字列 c7 credit_card_number 文字列 c8 credit_card_provider 文字列 c9 currency 文字列 c10 purchase_value 整数 c11 transaction_date 日付 c12 phone_number 文字列 c13 email 文字列 c14 ipv4 文字列 ユースケース: OpenSearch Service への読み込み前の個人情報バッチ検出 このアーキテクチャを実装しているお客様は、さまざまな分析を大規模に実行するために、Amazon S3 上にデータレイクを構築しています。このソリューションは、OpenSearch Service へのリアルタイム取り込みが不要で、スケジュールで実行される、またはイベントによってトリガーされるデータインテグレーションツールを使用することを計画しているお客様に適しています。 Amazon S3 にデータレコードが到着する前に、データレイクにすべてのデータストリームを信頼できる形で安全に取り込むための取り込みレイヤーを実装します。 Kinesis Data Streams は、構造化および半構造化データストリームの高速な取り込みのための取り込みレイヤーとして導入されます。これらの例としては、リレーショナルデータベースの変更、アプリケーション、システムログ、クリックストリームなどがあります。変更データキャプチャ (CDC) ユースケースの場合、Kinesis Data Streams を AWS DMS のターゲットとして使用できます。機密データを含むストリームを生成するアプリケーションやシステムは、Amazon Kinesis Agent、AWS SDK for Java、Kinesis Producer ライブラリのいずれかの 3 つのサポートされている方法を介して Kinesis Data Streams に送信されます。最後のステップとして、 Amazon Kinesis Data Firehose がリアルタイムに近いバッチデータを高い信頼性で S3 データレイクのデスティネーションにロードするのに役立ちます。 次のスクリーンショットは、 データビューア を介してKinesis Data Streams を通過するデータフローと、raw S3 プレフィックスに着地するサンプルデータの取得方法を示しています。このアーキテクチャでは、 データレイクの基礎 で推奨されている S3 プレフィックスのデータライフサイクルに従いました。 次のスクリーンショットの最初のレコードの詳細からわかるように、JSON ペイロードは前のセクションと同じスキーマに従っています。 Kinesis データストリームに流れ込む改変されていないデータが見えます。これは後の段階で改変されます。 データが Kinesis Data Streams に収集・取り込まれ、Kinesis Data Firehose を使用して S3 バケットに配信された後は、アーキテクチャの処理レイヤーが引き継ぎます。 パイプラインでの機密データの検出とマスキングを自動化するために、AWS Glue PII transform を使用します。 次のワークフロー図に示すように、AWS Glue Studio で変換ジョブを実装するために、コード不要の視覚的 ETL アプローチを採用しました。 まず、 pii_data_db データベースから raw のソース Data Catalog テーブルにアクセスします。このテーブルは、前のセクションで提示されたスキーマ構造を持っています。処理済みの raw データを追跡するために、 ジョブブックマーク を使用しました。 AWS Glue Studio のビジュアル ETL ジョブで AWS Glue DataBrew レシピ を使用して、2つの日付属性を OpenSearch で期待される フォーマット と互換性のある形式に変換します。これにより、完全なノーコード体験が実現できます。 Detect PIIアクションを使用して、機密性の高いカラムを特定します。AWS Glue には、選択したパターン、検出閾値、データセットの行のサンプル部分に基づいてこれを判断させます。この例では、アメリカ合衆国 (SSN など)に特に適用されるパターンを使用しましたが、他の国の機密データは検出されない場合があります。 使用例に適用できる利用可能なカテゴリと場所を確認するか、AWS Glue の正規表現 (regex) を使用して、他の国の機密データの検出エンティティを作成できます。 AWS Glue が提供する適切なサンプリング方法を選択することが重要です。この例では、ストリームから入ってくるデータにはすべての行に機密データが含まれていることがわかっているため、データセット内のすべての行を 100% サンプリングする必要はありません。下流のソースに機密データを一切許可したくない場合は、選択したパターンのデータを 100% サンプリングするか、データセット全体をスキャンして個々のセルに対処し、すべての機密データが検出されるようにすることを検討してください。サンプリングから得られるメリットは、スキャンする必要のあるデータ量が減るため、コストが削減されることです。 Detect PII アクションを使用すると、機密データをマスキングする際にデフォルトの文字列を選択できます。この例では、******** という文字列を使用しています。 apply mapping オペレーションを使用して、 ingestion_year 、 ingestion_month 、 ingestion_day などの不要なカラムの名前変更や削除を行います。 このステップでは、あるカラム ( purchase_value ) のデータ型を文字列から整数に変更することもできます。 この時点から、ジョブは OpenSearch Service とAmazon S3 の2つの出力先に分割されます。OpenSearch Service のプロビジョニングされたクラスターは、 Glue 用の組み込み OpenSearch コネクタ を介して接続されています。書き込み先の OpenSearch インデックスを指定し、コネクタが資格情報、ドメイン、ポート設定を処理します。下のスクリーンショットでは、指定されたインデックス index_os_pii に書き込んでいます。 マスクされたデータセットは、キュレーションされた S3 プレフィックスに格納します。 そこでは、特定のユースケースに対して正規化され、データサイエンティストによる安全な利用やアドホックなレポートのニーズに対応できるようにデータが用意されています。 統一的なガバナンス、アクセスコントロール、監査証跡をすべてのデータセットと Data Catalog テーブルに適用するには、 AWS Lake Formation を使用できます。これにより、AWS Glue Data Catalog テーブルと基礎となるデータへのアクセスを、必要なアクセス許可を付与されたユーザーとロールに限定できます。バッチジョブが正常に実行された後、OpenSearch Service を使用して検索クエリやレポートを実行できます。次のスクリーンショットに示すように、パイプラインはコード開発作業なしで自動的に機密フィールドをマスクしました。 バッチジョブが正常に実行された後、OpenSearch Serviceを使用して検索クエリやレポートを実行できます。次のスクリーンショットに示すように、パイプラインはコード開発作業なしで自動的に機密フィールドをマスクしました。 操作データから、前のスクリーンショットのように、クレジットカードプロバイダー別の1日当たりの取引数などのトレンドを特定できます。また、ユーザーが購入を行う場所とドメインも判断できます。 transaction_date 属性により、時間の経過とともにこれらのトレンドを確認できます。次のスクリーンショットは、取引情報が適切に編集されたレコードを示しています。 Amazon OpenSearch にデータをロードする他の方法については、 Amazon OpenSearch Service へのストリーミングデータをロードする を参照してください。さらに、機密データは他の AWS ソリューションを使用して発見およびマスキングすることもできます。 たとえば、 Amazon Macie を使用して S3 バケット内の機密データを検出し、次に Amazon Comprehend を使用して検出された機密データを編集することができます。詳細については、 AWSサービスを使用した PHI および PII データの検出の一般的な手法 を参照してください。 まとめ この投稿では、環境内の機密データを扱うことの重要性と、組織のスケールを速くする一方でコンプライアンスを維持するためのさまざまな方法とアーキテクチャについて説明しました。これで、データを検出、マスク、編集してAmazon OpenSearch Service にロードする方法がよく理解できるはずです。 著者について Michael Hamilton は、AWS 上でのエンタープライズ顧客の分析ワークロードの現代化と簡素化を支援する上級ソリューションアーキテクトです。仕事以外の時間では、マウンテンバイクに乗ったり、妻と3人の子どもたちと過ごすのが楽しみです。 Daniel Rozo は、オランダの顧客を支援する AWS のシニアソリューションアーキテクトです。 彼の情熱は、シンプルなデータとアナリティクスのソリューションのエンジニアリングと、顧客が現代のデータアーキテクチャに移行するのを助けることです。 仕事の外では、テニスをしたり自転車に乗ったりしています。 本投稿はソリューションアーキテクトの榎本が翻訳いたしました。原文は こちら です。

AWS Step Functions は、完全マネージドのビジュアルワークフローサービスで、 AWS Glue 、 Amazon EMR 、 Amazon Redshift などのさまざまな抽出・変換・読み込み (Extract, Transform, Load; ETL) テクノロジーを含む複雑なデータ処理パイプラインを構築できます。個々のデータパイプラインタスクを繋ぎ、ペイロード、リトライ、エラー処理を最小限のコードで構成することで、ワークフローを視覚的に構築できます。 Step Functions は、データパイプライン内のタスクが一時的なエラーで失敗した場合、自動リトライとエラー処理をサポートしていますが、アクセス許可の誤り、無効なデータ、パイプライン実行中のビジネスロジックの失敗など、回復不可能な失敗が発生する可能性があります。これにより、ステップで発生した問題を特定し、問題を修正してワークフローを再起動する必要があります。従来は、失敗したステップを再実行するには、ワークフロー全体を初めからやり直す必要がありました。これにより、特に複雑な長時間実行の ETL パイプラインの場合、ワークフローの完了が遅れていました。パイプラインに最初から実行するための状態遷移回数が増加するため、Map, Parallel ステートを使用する多数のステップがある場合、コストも増加します。 Step Functions では、失敗、中止、タイムアウトしたステートからワークフローを再実行できるようになりました 。これにより、ワークフローをより速く、低コストで完了させ、ビジネス価値の提供にさらに時間を費やすことができます。後続の問題が解決した後、失敗したステートに提供された同じ入力を使用して、失敗したワークフロー実行を再実行することで、取り扱われなかった失敗からより早く回復できるようになりました。 この投稿では、Step Functions の Distributed Map ステート を使用して、 Amazon Relational Database Service (Amazon RDS) のテーブルからデータをエクスポートする ETL パイプラインジョブをご紹介します。その後、障害をシミュレートし、新しい失敗したステートから再実行する機能を使用して、障害が発生したタスクを障害発生地点から再起動する方法をデモンストレーションします。 ソリューションの概要 データパイプラインに含まれる一般的な機能の 1 つに、複数のデータソースからデータを抽出し、データレイクにエクスポートしたり、別のデータベースにデータを同期したりすることがあります。 Step Functions の Distributed Map ステートを使用することで、このようなエクスポートや同期のジョブを最大 10,000 の並列度で実行できます。Distributed Map は、 Amazon Simple Storage Service (Amazon S3) から数何百万のオブジェクト、または単一の S3 オブジェクトから数百万レコードを読み込み、それらのレコードを後続のステップに配信することができます。 Step Functions は、Distributed Map 内のステップを、最大 10,000 の並列度で子ワークフローとして実行します。 10,000 の並列度は、AWS Glue のような他の多くの AWS サービスがサポートする並列度を大きく上回っています。AWS Glue は、ジョブごとに最大 1,000 のジョブ実行という制限 (ソフトリミット) があります。 このサンプルデータパイプラインは、 Amazon DynamoDB から商品カタログデータ、 Amazon RDS for PostgreSQL データベースから顧客注文データをソースとしています。データはその後前処理され、変換され、さらなる処理のために Amazon S3 にアップロードされます。データパイプラインは、RDS データベースの Data Catalog を作成するために、 AWS Glue クローラー で開始されます。AWS Glue クローラーの起動が非同期であるため、パイプラインにはクローラーの完了をチェックする待ちループがあります。AWS Glue クローラーの完了後、パイプラインは DynamoDB テーブルと RDS テーブルからデータを抽出します。これら 2 つのステップは独立しているため、並列ステップとして実行されます。1 つは、 AWS Lambda 関数を使用して、DynamoDB から S3 バケットにデータを出力、変換、ロードするものです。もう 1 つは、 AWS Glue ジョブ同期インテグレーション を使用した Distributed Map で、RDS テーブルから S3 バケットに同様の処理を行います。 AWS Identity and Access Management (IAM) アクセス許可が、Step Functions から AWS Glue ジョブを呼び出すために必要であることに注意してください。詳細は、 Step Functions から AWS Glue ジョブを呼び出すための IAM ポリシー を参照してください。 次の図は、Step Functions のワークフローを示しています。 RDS データベースには、顧客と注文データに関連する複数のテーブルがあります。Amazon S3 は、すべてのテーブルのメタデータを .csv ファイルとしてホストしています。このパイプラインは、Step Functions の Distributed Map を使用して、Amazon S3 からテーブルメタデータを読み取り、すべてのアイテムを反復処理し、後続の AWS Glue ジョブを並列で呼び出してデータをエクスポートします。次のコードを参照してください: "States": { "Map": { "Type": "Map", "ItemProcessor": { "ProcessorConfig": { "Mode": "DISTRIBUTED", "ExecutionType": "STANDARD" }, "StartAt": "Export data for a table", "States": { "Export data for a table": { "Type": "Task", "Resource": "arn:aws:states:::glue:startJobRun.sync", "Parameters": { "JobName": "ExportTableData", "Arguments": { "--dbtable.$": "$.tables" } }, "End": true } } }, "Label": "Map", "ItemReader": { "Resource": "arn:aws:states:::s3:getObject", "ReaderConfig": { "InputType": "CSV", "CSVHeaderLocation": "FIRST_ROW" }, "Parameters": { "Bucket": "123456789012-stepfunction-redrive", "Key": "tables.csv" } }, "ResultPath": null, "End": true } } 前提条件 ソリューションをデプロイするには、次の前提条件が必要です: AWS アカウント AWS CloudFormation スタックリソースをデプロイするための適切な IAM アクセス許可 CloudFormation テンプレートの起動 AWS CloudFormation を使用してソリューションリソースをデプロイするには、次のステップを完了してください: 以下を選択してCloudFormationスタックを起動してください。 スタック名を入力してください。 機能と変換 の下のすべてのチェックボックスを選択してください。 スタックの作成 を選択してください。 CloudFormation テンプレートは、次のものを含む多くのリソースを作成します: データパイプラインとなる Step Functions ワークフロー エクスポートされたデータと Amazon RDS のテーブルのメタデータを格納する S3 バケット DynamoDB の製品カタログテーブル 事前にテーブルがロードされた RDS for PostgreSQL データベースインスタンス RDS テーブルをクロールして AWS Glue Data Catalog を作成する AWS Glue クローラー RDS テーブルから S3 バケットにデータをエクスポートするパラメータ化された AWS Glue ジョブ DynamoDB から S3 バケットにデータをエクスポートする Lambda 関数 障害のシミュレート ソリューションをテストするには、次のステップを完了してください: Step Functions コンソールで、ナビゲーションペインの ステートマシン を選択します。 ETL_Process という名前のワークフローを選択します。 デフォルトの入力でワークフローを実行します。 数秒で、ワークフローは Distributed Map ステートで失敗します。 マップ実行のエラーは、マップ実行と子ワークフローの Step Functions ワークフロー実行イベントにアクセスすることで調査できます。この例では、例外が AWS Glue の Glue.ConcurrentRunsExceededException によるものであることがわかります。このエラーは、AWS Glue ジョブの同時実行要求数が、設定された数を超えていることを示しています。Distributed Map は Amazon S3 からテーブルメタデータを読み取り、.csv ファイルの行数と同じ数の AWS Glue ジョブを起動しますが、AWS Glue ジョブは作成時に同時実行数が 3 に設定されています。これが子ワークフローの失敗を引き起こし、失敗が Distributed Map ステート、次いで Parallel ステートに伝播した結果です。Parallel ステートのもう一方のステップで DynamoDB テーブルを取得する処理は正常に完了しました。Parallel ステートのいずれかのステップが失敗した場合、連鎖的な失敗が見られるように、ステート全体が失敗します。 Distributed Map による障害への対処 デフォルトでは、ステートがエラーを報告すると、Step Functions はワークフローの失敗を引き起こします。 Distributed Map ステートでこの失敗を処理する方法は複数あります: Step Functions を使用すると、 エラーをキャッチし、エラーをリトライし、別のステートにフォールバックして エラーを適切に処理することができます。次のコードを参照してください: Retry": [ { "ErrorEquals": [ "Glue.ConcurrentRunsExceededException " ], "BackoffRate": 20, "IntervalSeconds": 10, "MaxAttempts": 3, "Comment": "Exception", "JitterStrategy": "FULL" } ] JSON 場合によっては、ビジネスが障害を許容できることがあります。これは、数百万のアイテムを処理していて、データセットにデータ品質の問題があることを予測している場合に特に当てはまります。デフォルトでは、Map ステートのマップ処理が失敗すると、他のすべてのマップ処理が中止されます。Distributed Map を使用すると、障害のしきい値として、失敗したアイテムの最大数または割合を指定できます。障害が許容レベル内であれば、Distributed Map は失敗しません。 Distributed Map ステートを使用すると、子ワークフローの並列実行数を制御できます。並列実行数を AWS Glue ジョブの並列実行数にマッピングできます。この並列実行数は、ワークフロー実行レベルでのみ適用されることに注意してください。ワークフローの異なる実行を跨いでは適用されません。。 エラーの根本原因を修正した後、失敗したステートからステートを再実行できます。 失敗したステートの再試行 このサンプルソリューションの問題の根本的な原因は、AWS Glue ジョブの同時実行性にあります。 失敗したステートを再実行するために、次のステップを完了してください: AWS Glue コンソールで、 ExportsTableData という名前のジョブに移動します。 ジョブの詳細 タブの 詳細プロパティ で、 最大同時実行数 を 5 に更新します。 再実行機能のローンチに伴い、過去 14 日間で正常に完了しなかった 標準ワークフロー の実行を再起動できるようになりました。 これには、失敗、中止、タイムアウトした実行が含まれます。 失敗したワークフローは、最後に正常に完了しなかったステートと同じ入力を使用して、失敗したステップからのみ再起動できます。 最初のワークフロー実行とは異なるステートマシン定義を使用して、失敗したワークフローを再起動することはできません。 失敗したステートが正常に再起動されると、Step Functions はすべての後続のタスクを自動的に実行します。Distributed Map の再起動がどのように機能するかの詳細については、 マップ実行の再起動 を参照してください。 マップ内のステップが子ワークフローとして実行されるため、ワークフローの IAM 実行ロールには、Distributed Map のステートを再起動するためにマップ実行を再実行する権限が必要です。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "states:RedriveExecution" ], "Resource": "arn:aws:states:us-east-2:123456789012:execution:myStateMachine/myMapRunLabel:*" } ] } JSON プログラムで失敗したステップからワークフローを再実行するには、 AWS Command Line Interface (AWS CLI) や AWS SDK を使用するか、視覚的な操作体験を提供する Step Functions コンソールを使用できます。 Step Functions コンソールで、再実行したい失敗したワークフローに移動します。 詳細 タブで、 失敗から再実行 を選択します。 パイプラインは、AWS Glue ジョブを実行するのに十分な同時実行数があるため、正常に実行されます。 ワークフローをプログラムで失敗したポイントから再実行するには、 新しい Redrive Execution API アクションを呼び出します。同じワークフローが最後の失敗したステートから開始され、最後に成功しなかったステートと同じ入力が使用されます。ワークフロー定義と、再実行対象のステートとステートへの入力は、変更できません。 子ワークフローの異なるタイプについて、次の点に注意してください: Express 子ワークフローの再実行 – Distributed Map 内の Express ワークフローである失敗した子ワークフローの場合、再実行機能により、子ワークフローの先頭からシームレスに再起動できます。 これにより、マップ全体を再起動することなく、個々のマップに固有の問題を解決できます。 標準子ワークフローの再実行 – Distributed Map 内の標準ワークフローである失敗した子ワークフローの場合、再実行機能はスタンドアロンワークフローと同じように機能します。 各マップ内の失敗したステートを、すでに正常に実行された不要なステップをスキップして、失敗したポイントから再起動できます。 Step Functions のステータス変更通知 を Amazon EventBridge と組み合わせることで、失敗時にメールを送信するなどの失敗通知ができます。 クリーンアップ リソースをクリーンアップするには、AWS CloudFormation コンソールから CloudFormation スタックを削除してください。 まとめ この投稿では、Step Functions の再実行機能を使用して、失敗したステップを失敗したポイントから再起動することにより、Distributed Map 内の失敗したステップを再実行する方法を示しました。 Distributed Map ステートを使用すると、サーバーレスアプリケーション内で大規模なパラレルワークロードを調整するワークフローを記述できます。 Step Functions は、最大並列度 10,000 で Distributed Map 内のステップを子ワークフローとして実行します。これは、多くの AWS サービスでサポートされている同時実行数を大きく上回っています。 Step Functionsの Distributed Map の詳細については、 Step Functions – Distributed Map を参照してください。ワークフローの再実行の詳細については、 Redriving executions を参照してください。 本記事は、Sriharsh Adari、Joe Morotti、Uma Ramadoss による “ Build efficient ETL pipelines with AWS Step Functions distributed map and redrive feature ” を翻訳したものです。 翻訳はソリューションアーキテクトの高橋が担当しました。

アマゾン ウェブ サービス ジャパン（以下、AWS）は 2023 年 11 月 15 日に、「【Edtech Meetup】Edtech スタートアップがグローバルに活躍するには？」と題したイベントを AWS Startup Loft Tokyo にて開催しました。 このイベントでは、グローバルに活躍する Edtech スタートアップの方々をお招きし、Go to Market 戦略やグローバル展開における苦労とその乗り越え方などについてパネルディスカッションを行いました。 Edtech スタートアップや教育業界の方々が集まり、業界のプロフェッショナルの方々との交流を深め、新たなアイデアやビジネスチャンスを見つける機会を創出いたしました。今回はそのレポートをお届けします。 オープニング イベント冒頭では、AWS パブリックセクター 教育事業本部 初等中等教育/EdTech 営業部長の平塚 建一郎が、オープニングのあいさつをしました。 AWS パブリックセクター 教育事業本部 初等中等教育/EdTech営業部長 平塚　建一郎 日本では、少子高齢化が大きな社会問題になっています。2022 年の日本人出生数は約 77 万人であり、統計を始めた 1899 年以降で最少。初めて 80 万人台を割り込みました。「これは教育関連の事業を手がけている方々にとって、切実な問題ではないかと思います」と平塚は触れます。 日本の人口は徐々に減少していくため、教育関連の事業をグロースさせるうえでは“世界”に目を向けることが重要です。現在、日本の 15 歳未満の人口は約 1,435 万人ですが、世界の 15 歳未満の人口は約 18 億人。単純計算すると、世界には日本の 100 倍以上の市場が存在します。 しかし、日本企業が海外進出するには大きなハードルがあります。商習慣や文化の違い、法規制、販路拡大、知的財産の扱い、人員の確保、資金調達といった問題を乗り越える必要があるのです。そうした課題に対する解決策のヒントを提供するため、AWS は本イベントを開催しました。すでにグローバル展開を行っている各社から、各種の課題をいかにして乗り越えてきたのかを解説していただきます。 「最後になりますが、私たち AWS もグローバル企業のうちの一社です。世界各国で Edtech 企業のご支援をさせていただいております。何かしらの形でみなさまのお役に立てればと考えておりますので、お気軽にご相談ください。何卒よろしくお願いいたします」と、平塚はあいさつを終えました。 パネルディスカッション開始 ＜モデレーター＞ ワンダーファイ株式会社　代表取締役 CCO /ファウンダー　川島 慶 氏 ＜スピーカー＞ ELSA, Corp. 日本法人代表 玉置 俊也 氏 Riiid Inc.　日本代表　Moon YongJoo 氏 Instructure, Inc.　Channel Account Manager APAC Japan　玉木 和将 氏 ここからは、グローバル展開を行っている各社が登壇。ワンダーファイ社は、世界中の子どもから「知的なわくわく」を引き出すための教材やコンテンツを開発・運営する会社です。STEAM 教育領域の通信教育サービス「ワンダーボックス」 や、150 カ国 200 万人の子どもが楽しむ思考力が育つアプリ「シンクシンク」を運営しています。 ELSA 社は英語をより正しく、自信を持って話せるようになるための AI パーソナルコーチアプリ「ELSA」を提供する企業。「ELSA」は世界の AI 企業 100 にも選ばれた独自の音声認識技術を用いていて、学習者は自分自身のスピーキングの弱みを把握して短期間で改善できます。現在、100 カ国以上 5,000 万人のユーザーに利用されています。 Riiid 社は多くの AI エンジニア/リサーチャーが在籍する韓国発のディープテックベンチャー。機械学習領域で研究や論文発表を行い、特に教育や学習分野の研究に力を入れてきました。事業としては AI パーソナライズ TOEIC 学習アプリ「Santa」などを提供。「Santa」は韓国と日本で合計 600 万人以上のユーザーが利用しています。 Instructure 社は、アメリカに本拠地を置く Edtech スタートアップ企業です。Web ベースの学習管理システム「Canvas」や評価管理システム「MasteryConnect」の開発・提供を行っています。Instructure 社の顧客数は 6,000 機関以上あり、アメリカのアイビーリーグの全教育機関が「Canvas」を使用しています。 各企業の概要紹介や登壇者による活動内容の紹介の後、パネルディスカッション形式での議論を行いました。 ワンダーファイ株式会社　代表取締役 CCO /ファウンダー　川島 慶 氏 グローバル展開において、さまざまな障壁を乗り越える方法 ここからは、グローバル展開において経験した苦労や障壁、それを乗り越える方法などについて各社が事例を話しました。 玉置 氏は ELSA 社とRiiid 社、Instructure 社の本社が海外にあることを述べたうえで、「本社と日本との商慣習の違いで苦労することが多い」と述べます。たとえばアメリカの企業では多くの場合、可能な限りスピーディーにビジネスの成果を出すことを従業員に求めます。事業の海外展開においても、それは同様です。 しかし、特定の国への進出をゼロからスタートする場合、そんなに簡単には売上を立てられる状態にはなりません。ましてや、日本は「企業同士の関係値や信頼関係を構築してからサービスを契約する」という慣習が根強く、アメリカのように「お互いの利害関係が一致すればすぐにサービスを契約する」という文化ではないのです。その点を、本社へと適切に伝えることが大事だといいます。玉置 氏の所属する ELSA 社においても、日本で最初の顧客を獲得するまでに長い時間がかかりました。 また、Moon 氏は「同じプロダクトであっても、韓国と日本とではユーザーのニーズやユースケースが全く違っていた」と話します。Riiid 社の提供する「Santa」は、TOEIC のための英語学習を行うユーザーを対象としています。韓国では主なユーザーが大学生であり、ほとんどの人が就職活動のために TOEIC を受けます。アプリを利用する期間が数カ月ほどの短期間なのです。 一方、日本では転職活動や昇進などをきっかけに TOEIC の学習をする人が多く、より長期間アプリを使用する傾向にあります。「こうした情報は、実際に現地で働いてみなければなかなか見えてきません」と Moon 氏は述べました。 また、イベント中盤では「各国の拠点の裁量やプレゼンスを大きくしていく方法」についても語られました。川島 氏の所属するワンダーファイ社は、2017 年より国際協力機構（JICA）中小企業海外展開支援事業として、カンボジアにおいて思考力教育の導入事業を手がけています。この事業では、カンボジアの拠点のメンバーがプレゼンスを発揮し、現地の政治家との連携などを行っているのです。 Instructure, Inc.　Channel Account Manager APAC Japan　玉木 和将 氏 このテーマについて玉木 氏は「特定の国に新しい拠点を築く場合、ビジネスの土台を作るにはかなりのエネルギーが必要」と述べます。ここで言う“土台”は、パートナー企業の開拓のように“社外”との活動や関係性構築だけではなく、“社内”とのやりとりも含まれます。たとえば、本社に対して日本の商慣習や文化、教育業界の状況などを伝え、ビジネスプランにそれらを活かさなければならないのです。 玉木 氏は過去に経験した印象深い出来事として、日本以外の国で働く Instructure社のメンバーにチャットツール上であいさつをした際のエピソードを挙げます。その社員からは「日本拠点があることを知らなかった」という旨の返答があり、「社内外に向けて積極的に情報発信しなければならない」と痛感したのだといいます。 海外展開を成功させるためのヒント イベント終盤では、企業が海外展開を成功させる知見について語られました。玉木 氏は、日本における採用とアメリカにおける採用の違いと、それに関連して事業をスケールさせるための考え方を話しました。 アメリカにおける採用では「その人材が特定の職能におけるスペシャリストであり、社内でその役割のみを果たすこと」を期待して人を採ります。社員は一人一役であり、専門性を持ったメンバーがチームとして動くことで企業が成り立っているのです。 一方で、日本における採用では「その人材が部署内のさまざまな業務を担当し、ジェネラリストとして立ち回ること」を期待されることが多いです。異動により、その社員が専門知識を持たない業務を担当することもあります。この仕組みにより、企業全体の生産性がなかなか向上しないという課題が生じます。玉木 氏は「事業をスケールさせるためには、日本企業も“チームとして動くこと”を前提とした組織・制度構築が必要」と語りました。 また、サービスを各国に展開してビジネスを成功させるうえでは、特定の国における成功体験を他の国に持ち込んではならないと玉木 氏は言及。その国の慣習や文化、ユーザーに合わせた形でサービスの機能やプランなどをローカライズしていく必要があるのです。 Riiid Inc.　日本代表　Moon YongJoo 氏（写真右） Moon 氏も「グローバル展開を考えるならば、必ず一人はその国で働くメンバーが必要。他国に拠点を置かずに簡単にスタートしたいのはわかるが、デスクで他の国を完璧に想像するのはできない。マーケティングクリエイティブすら毎日変わってる中で、他の業務をしながら他国の市場状況を理解するのは不可能に近い。正しい市場反応を得られるためには、正しい検証方法が必須なので、現地を理解して正しい検証ができるメンバーが最低一人は必要になる。また、海外進出は必ず何度も失敗を繰り返すことになるので、何度も失敗してもそこから学んで成功に持っていける体制がもっとも大事です。 現地専任の人ではない限りは、小さな失敗でもすぐ諦める可能性がものすごく高い。現地のことを理解、失敗を繰り返せる体制、この二つなしではどれほど素晴らしいサービスでも必ず失敗してしまう。」と述べました。 玉置 氏は ELSA 社の事例を踏まえて「日本からグローバルに進出する場合、そして他の国から日本に進出する場合に役立ちそうな Tips を最後に共有させてください」と述べました。 ELSA 社がユーザーを増やすために大切にしていることとして、玉置 氏はグロースループを挙げます。これは、特定のユーザーが他のユーザーを呼び込むという制度設計のことです。たとえばインフルエンサーマーケティングにおいても、“共感”をベースに施策を推進することを大切にしているといいます。 ELSA 社では英語の AI パーソナルコーチアプリ「ELSA」の認知拡大のために、お笑い芸人のたむらけんじ 氏をプロモーションに起用しています。たむら 氏は 50 歳の誕生日を機に、活動拠点をアメリカに移しました。その様子を SNS で見ていた ELSA 社の社員が「たむら 氏を手助けしたい」という思いから、彼にアプローチしたのだといいます。その後、たむら 氏は ELSA 社のビジョンや「ELSA」のプロダクトコンセプトに共感し、自発的にさまざまなプロモーションを行ってくれるようになりました。 ELSA, Corp. 日本法人代表 玉置 俊也 氏 この例のように「ユーザーがプロダクトを好きになってくれること」「ユーザーが他の方々と一緒に楽しく学べるようなプロダクトにすること」などを ELSA 社は重視して、施策・機能の設計をしています。 それに加えて、ELSA 社は世代を超えて楽しめる学習体験を作ることも意識しています。例を挙げると、子どもが「ELSA」を使って自宅で英語学習をする際に、家族も一緒に楽しめるような仕掛けを用意しています。それがきっかけで、両親が「ELSA」の良さに気付き、自分の働く企業にプロダクトを導入する可能性が生まれるのです。「こうした共感ベースのアプローチを、ぜひ参考にしていただければ幸いです」と玉置 氏は結びました。 AWS パブリックセクター　パートナーアライアンス本部 パートナー事業開発マネジャー 松下 紘之 イベント終盤には AWS からのお知らせとして、AWS パートナーネットワーク（以下、APN）についての紹介をしました。AWS パートナーネットワーク (APN) は、オファリングの構築、マーケティング、およびお客様への販売のためのプログラムとリソースを活用するパートナーのグローバルコミュニティです。 APN への参加後、企業は自社のビジネスに関連するパートナーパスに登録します。パートナーパスには「ソフトウェアパス」「ハードウェアパス」「サービスパス」「トレーニングパス」「ディストリビューションパス」の 5 種類が存在しています。 パートナーパスの詳細はこちら APN の 加入企業は、AWS を基盤としたビジネスの構築に役立つ AWS パートナープログラムを効果的に活用することで、 事業成長に結びつけていただくことが可能です。 AWS パートナープログラムの詳細はこちら 今回のイベントは AWS パブリックセクターが主催していることもあり、これらのプログラムのうち、AWS 公共部門パートナープログラムについて詳細に解説。そして、このプログラムを積極活用し公共パートナービジネスの急速成長を目指していく企業に対しての、AWS のアクセラレーション支援の概要や事例についてもご紹介しました。 AWS パブリックセクターは今後も、Edtech スタートアップの方々に向けてさまざまなテクニカル・ビジネスセッションやコミュニティ活動を実施予定です。ご関心を持たれた方は、ぜひお気軽にこちらまでお問い合わせください。みなさまのご参加をお待ちしております！ このブログは、アマゾンウェブサービスジャパン合同会社 パブリックセクター 事業開発マネージャー（ Startup ）である田村 圭が執筆しました。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 JAWS DAYS 2024 が 3 月 2 日 (土) に開催されます。これは東京で 5 年ぶりに開催されるリアルイベントで、オフラインで実施されます。多様なテーマのイベントが計画されており、「新しいビジネスアイディアを持つ人が、JAWS DAYS 2024 に参加しているエンジニアと一緒に即席でアーキテクチャを検討する」というような興味深い内容が予定されています。申し込みはまだ開始されていませんが、3 月 2 日 (土) 10:00 から池袋サンシャインシティで開催されますので、興味のある方は事前に日程を確保すると良いと思います。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年1月8日週の主要なアップデート 1/8(月) Amazon ECS improves deployment monitoring responsiveness for Amazon ECS services Amazon ECS でデプロイメントサーキットブレーカーを利用した際に、デプロイを「失敗」と判断するまでの時間が短縮され、迅速にロールバックできるようになりました。デプロイメントサーキットブレーカーは、ECS サービスのデプロイ後にタスクが RUNNING に遷移しない状況や、ヘルスチェックに失敗し続けるような状況を検知して、ロールバックを実行できる機能です。本アップデートにより、20 個未満のタスクを動かすサービスについて、「失敗」と判断するための最小閾値を 10 個から 3 個に下げました。 AWS Mainframe Modernization AWS Blu Insights is now available in additional regions AWS Blu Age サービスの AWS Blu Insights 機能が、東京を含む 14 リージョンで新しく利用できるようになりました。AWS Blu Age は、メインフレームで動作するアプリケーションを Java ベースのアプリケーションに自動変換し、モダナイゼーションを支援するサービスです。AWS Blu Insights は、コードベースの分析及び変換機能を提供します。アップデート以前は海外のリージョンで利用する事が出来ましたが、組織のセキュリティポリシー上、国外のリージョンを利用するハードルがある場合もあります。今回のアップデートで、国内の東京リージョンで利用ができるようになりました。 Amazon OpenSearch Service expands Graviton2 support to six additional regions Amazon OpenSearch Service の Graviton2 サポートが、大阪を含む 6 リージョンで新たに利用可能になりました。Graviton は Amazon が設計した 64 ビットの Arm Neoverse コアとカスタムシリコンを利用して構成されています。x86 ベースのインスタンスと比べて、最大 30 % 優れたコストパフォーマンスを提供できます。 1/9(火) Amazon EC2 C7i instances are now available in 8 additional AWS Regions Amazon EC2 で新たに C7i インスタンスが利用可能になりました。カスタムされた第 4 世代の Intel Xeon プロセッサー (Sapphire Rapids) を搭載しています。C6i インスタンスと比較して、最大 15 % 優れたコストパフォーマンスを提供し、バッチ処理、データ分析、広告配信、動画エンコードなど、コンピューティングリソースを消費する使い方に向いています。 AWS CodeBuild now supports a X-Large Linux compute type AWS CodeBuild の LINUX_CONTAINER ビルド環境で、新たに BUILD_GENERAL1_XLARGE (36 vCPU、70 GB メモリ、256 GB ディスク) をサポートしました。アップデート以前は、2 vCPU、4 vCPU、8 vCPU、72 vCPU の 4 パターンから選択できました。今回新たに 36 vCPU が追加され、ビルド対象とコストを見ながら、最適な環境を選択しやすくなりました。 AWS CloudShell now supports Docker in 13 Regions AWS CloudShell で新たに Docker をサポートしました。CloudShell 環境に Docker が事前インストールされるようになり、コンテナの起動、作成などを通じてコンテナベースの開発を素早く行えるようになりました。東京リージョンを含めた 13 リージョンで利用可能です。 1/10(水) Amazon EC2 M7i-flex and M7i instances now available in additional AWS regions Amazon EC2 で M7i と M7i-Flex インスタンスが、東京を含めた 2 つのリージョンで新たに利用可能となりました。カスタムされた第4世代の Intel Xeon プロセッサー (Sapphire Rapids) が搭載されています。M7i は、M6i と比較して最大 15 % 優れたコストパフォーマンスを実現します。新たな概念 の M7i-Flex は、 M7i をより安価に利用出来る汎用的なインスタンスタイプです。CPU の性能の 40 % 分は常時利用出来るベースラインが提供されています。40 % を超えた場合、95 % の確率で CPU パフォーマンスの 100 % を利用できます。残りの 5 % は、数ミリ秒 ~ 数十ミリ秒待機することで CPU が提供されます。M7i-Flex は、このような仕組みに基づき安価に利用できるタイプとなっており、選択肢のひとつに入れていただけると良いと思います。 Amazon Location Service now supports additional places content in Maps Amazon Location Service で、新たにカスタムレイヤーの概念が追加されました。カスタムレイヤーを有効化することで、地図上に要素を追加できます。現在のところ、カスタムレイヤーとして Point of Interest (POI) が選択可能です。これは、地図上にショップ、レストラン、サービス施設、アトラクション、その他興味を持つ場所の情報を追加できます。人の目で地図を見たときに、場所情報も一緒に確認することで、視覚的によりわかりやすく利用できるようになりました。現在、カスタムレイヤーは Esri Navigation のマップスタイルのみ利用可能です。 1/11(木) Amazon CloudWatch Logs now supports account level subscription filter Amazon CloudWatch Logs でアカウント単位のサブスクリプションフィルター機能を追加しました。取り込まれたログをリアルタイムに、Kinesis Data Streams、Kinesis Data Firehose、AWS Lambda を経由して、データ処理や他のサービスへ転送などができます。今までは、ロググループ単位でサブスクリプションフィルターを設定するものだったため、複数のロググループにまたがった設定を行いたいときに、一つずつ設定が必要でした。今回のアップデートで、アカウント単位のサブスクリプションフィルターが利用できるようになり、アカウント全体に 1 つのサブスクリプションフィルターポリシーを設定することで、複数のロググループに取り込まれたログを出力できるようになりました。また、設定のシンプル化に加えて、ロググループあたりのサブスクリプションフィルターを設定する Service Quota の上限が 2 となっており、これを節約できるメリットもあります。 Amazon EC2 R7i instances are now available in more AWS regions Amazon EC2 で、R7i インスタンスが、東京を含む 9 つのリージョンで新たに利用可能となりました。R7i インスタンスは、R6i インスタンスと比較して最大 15% 優れたコストパフォーマンスを提供します。これらのインスタンスは SAP 認定を受けており、SAP、SQL、NoSQL データベース、分散型 Web スケールのインメモリキャッシュ、SAP HANA などのインメモリデータベース、Hadoop や Spark などのリアルタイムビッグデータ分析など、メモリを大量に消費するワークロードに最適です。 Amazon ECS and AWS Fargate now integrate with Amazon EBS Amazon ECS と AWS Fargate が Amazon EBS と統合され、EBS ボリュームを簡単にプロビジョニングし、ECS タスクにアタッチができるようになりました。この機能により、ECS Task で、ETL ジョブ、メディアトランスコーディング、ML 推論ワークロードなど、ストレージやデータ集約型のアプリケーションを簡単にデプロイるようになりました。元々、ECS on Fargate で統合されているストレージは、「一時ストレージ」と「EFS」がありました。「一時ストレージ」は、簡単に利用できる一時的なストレージ領域ですが、最大 200 GB の制限があります。「EFS」はより大容量のストレージを利用出来ますが、パフォーマンス管理などが必要となっていました。今回のアップデートで、Task に 専用の EBS ボリュームをアタッチできるようになり、低レイテンシーと高パフォーマンスを両立するブロックストレージを利用できるようになりました。新規に EBS ボリュームをプロビジョニングするパターンと、Snapshot を利用して事前にデータを格納しておくパターンが選択できます。詳細は こちらの Blog をご参照ください。 1/12(金) ROSA with hosted control planes (HCP) is generally available Red Hat OpenShift Service on AWS (ROSA) で、Hosted Control Plane (HCP) の一般提供が開始されました。これにより、ROSA の実行コストの削減、クラスターの作成時間の短縮、アップグレードの柔軟性が向上しました。従来の構成は、ROSA のコントロールプレーン (Master Node、Infrastructure Node) をお客様の AWS アカウント上にデプロイする必要がありました。その際、最小構成でも 7 台の EC2 インスタンスが必要で、コスト増加やインスタンス管理の手間が発生していました。しかし、今回のアップデートにより、コントロールプレーンを ROSA サービス側で提供する HCP 構成を選択できるようになり、最低 2 台の EC2 インスタンスから利用可能になりました。HCP を利用する場合、コントロールプレーンの料金として 1 時間あたり $0.25 が追加されますが、インスタンスの台数が減少することで全体のコスト削減が期待できます。 Private Access to the AWS Management Console is available in 7 additional AWS Regions AWS マネジメントコンソールにおける Private Access 機能が、東京を含む 7 つのリージョンで提供を開始しました。この機能の主なユースケースは、組織内の操作端末からAWS マネジメントコンソールにアクセスする際に、未管理の AWS アカウントへのアクセスを制限することが挙げられます。例えば、セキュリティ上の理由から、組織内の端末を使って個人所有の AWS アカウントへのアクセスを禁止する場面がこれに当たります。誤解されやすい点ですが、Private Access 機能を使用しても、Web Proxy の利用など、インターネット経由のアクセスは依然として必要です。画像や JavaScript、CSS はインターネット経由で取得されます。また、Private Access で利用できないサービスも存在します。詳細については、 こちらのドキュメント を参照してください。 それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

はじめに 本記事では、個人用の Java 版 Minecraft サーバーを AWS 上にデプロイする方法をご紹介します。サーバーを AWS にホストすることで、自宅サーバーを使用した際に伴う、一般的なネットワーク上の課題やセキュリティ上の懸念を解消することができます。また、仮想マシンを制御できるため、任意の MOD やプラグインを構成することができます。今回は、 Amazon Elastic Compute Cloud (EC2) を使用して、友人と一緒に使用できる Minecraft サーバーを稼働させます。本記事で、コストの最適化についての説明は省きますが、サーバーのコストを削減する方法はたくさんあります。 ソリューション概要 本ソリューションは、Amazon EC2 を使用して、Minecraft サーバー用の仮想マシンを起動します。EC2 ではネットワーク構成を制御でき、さまざまな CPU および RAM オプションを備えた数百種類の EC2 インスタンスタイプから選択できます。この柔軟性により、小規模なプレイヤーベースと大規模なプレイヤーベースの両方をサポートするサーバーをホストできます。 仮想マシンは、AWS クラウド上の仮想プライベートネットワークである Amazon Virtual Private Cloud (VPC) で起動されます。さらに、EC2 インスタンスをセキュリティグループで保護します。セキュリティグループは、EC2 インスタンスへのアクセスを制御できる仮想ファイアウォールです。サーバーの設定を簡単にするために、必要なソフトウェアをインストールしてサーバーを実行するのに役立つ bash スクリプトを用意しています。 ウォークスルー 前提条件 AWS アカウント Minecraft Java Edition Account ステップ EC2 インスタンスのセットアップ カスタムスクリプトを使用して Minecraft サーバーのセットアップを自動化 Minecraft サーバー専用の IP アドレスを割り当て サーバーオペレータの設定、ワールドファイルの変更など クリーンアップ EC2 インスタンスのセットアップ Java 版 Minecraft サーバーを実行するには、Amazon EC2 を使用して仮想マシンを作成する必要があります。 AWS コンソール にログインします。 コンソールの右上で、プレイヤーのロケーションに適した AWS リージョンを選択します (たとえば、プレイヤーベースが米国西海岸にある場合は、us-west リージョンのいずれかを選択します)。 EC2 と検索し、EC2 ダッシュボードに移動します。 インスタンスを起動 を押します。 EC2 インスタンスの設定をここで行います。インスタンスに Minecraft Server などの名前を付けます。1 番目の Amazon Linux AMI を選択し、アーキテクチャを 64 ビット (Arm) に変更します。今回は、 Amazon Linux 2023 AMI を使用しました。 インスタンスタイプで、 t4g.small を選択します。サーバーが処理しきれないほどの多くのユーザが接続する場合は、いつでも サーバーをより大きな EC2 インスタンスにアップグレード できます。 キーペア名で 新しいキーペアを作成 を押します。キーペア名を入力し、 キーペアを作成 を押します。秘密鍵は自動的にダウンロードされます。 ネットワーク設定のセクションまでスクロールします。右上の 編集 ボタンをクリックします。ここで、EC2 インスタンスを保護し、安全でない接続を防ぐためのセキュリティグループを作成します。 デフォルト VPC を選択し、サブネットは指定しないままにして、パブリック IP の自動割り当てを有効にします。デフォルト VPC には、各 アベイラビリティーゾーン に 1 つのパブリックサブネットがあるため、変更せずに選択できます。 ファイアウォールで、 セキュリティグループの作成 を選択します。セキュリティグループ名を Minecraft Security Group に変更します。オプションで、 Security group with ports open for Minecraft Server &amp; SSH などの説明を追加します。 次に、接続を許可するインバウンドルールを 2 つ追加します。 EC2 Instance Connect は、AWS コンソールから EC2 インスタンスに安全に接続する方法です。EC2 インスタンスに接続するには、EC2 Instance Connect IPアドレスからの SSH トラフィックを許可する必要があります。EC2 Instance Connect IP アドレスの範囲は、EC2 インスタンスが置かれている AWS リージョンによって異なります。EC2 インスタンス接続の一般的な US の IP 範囲は次のとおりです。 IP CIDR Ranges us-east-1: 18.206.107.24/29 us-east-2:&nbsp;3.16.146.0/29 us-west-1:&nbsp;13.52.6.112/29 us-west-2: 18.237.140.160/29 EC2 インスタンスを起動するリージョンが上記のリストにない場合は、 AWS IP アドレスのドキュメント で IP 範囲を確認できます。JSON ファイルをダウンロードし、ブラウザで開きます。それを生データとして表示し、 Ctrl+F または Command+F を使用して文書内のテキストを検索します。検索バーに EC2_INSTANCE_CONNECT と入力し、利用するリージョンのインスタンス接続 IP を見つけます。 インバウンドセキュリティグループのルール に進んでください。デフォルトの SSH トラフィックルールで、ソースタイプを カスタム に変更します。使用している地域の IP アドレス範囲をソースフィールドに入力します。us-east-1 IP の使用例については、以下のスクリーンショットを参照してください。 セキュリティグループに別のインバウンドルールを追加して、ポート 25565 でどこからでも (0.0.0.0/0) TCP トラフィックを許可します。これにより、Minecraft プレーヤーがサーバーに参加できるようになります。 ネットワーク設定は次のようになります (この例では us-east-1 リージョンを使用しました)。 ストレージ設定のセクションに進んでください。ルートボリューム EBS には 8GB を選択します。これは、EC2 インスタンスが関連付けているストレージの量です。必要に応じてストレージを追加することもできますが、始めるには 8GB で十分です。 無料利用枠 の対象となるお客様は、EBS で最大 30GB の SSD を無料で入手できます。 Minecraft を自動的にダウンロードしてセットアップするようにユーザーデータを設定する 次に、EC2 インスタンスを起動するたびに Minecraft サーバーを自動的にダウンロード、設定、実行する bash スクリプトを追加します。 重要: スクリプトは、お客様に代わって Minecraft との エンドユーザー使用許諾契約 (EULA) に自動的に署名します。これは Minecraft サーバーの jar ファイルを実行するために必要で、通常はユーザーが行います。このスクリプトを使用することにより、Minecraft サーバーを実行するための EULA に同意したものとみなされます。 ページの一番下までスクロールし、 高度な詳細 セクションを見つけて展開します。もう一度ページの一番下までスクロールして、 ユーザーデータ フィールドを見つけます。 ユーザーデータ フィールドに、以下の Minecraft セットアップスクリプトの自動化 セクションのスクリプト全体をコピーして、 ユーザーデータ セクションに貼り付けます。 Minecraft セットアップスクリプトの自動化 #!/bin/bash # *** INSERT SERVER DOWNLOAD URL BELOW *** # Do not add any spaces between your link and the "=", otherwise it won't work. EG: MINECRAFTSERVERURL=https://urlexample MINECRAFTSERVERURL= # Download Java sudo yum install -y java-17-amazon-corretto-headless # Install MC Java server in a directory we create adduser minecraft mkdir /opt/minecraft/ mkdir /opt/minecraft/server/ cd /opt/minecraft/server # Download server jar file from Minecraft official website wget $MINECRAFTSERVERURL # Generate Minecraft server files and create script chown -R minecraft:minecraft /opt/minecraft/ java -Xmx1300M -Xms1300M -jar server.jar nogui sleep 40 sed -i 's/false/true/p' eula.txt touch start printf '#!/bin/bash\njava -Xmx1300M -Xms1300M -jar server.jar nogui\n' &gt;&gt; start chmod +x start sleep 1 touch stop printf '#!/bin/bash\nkill -9 $(ps -ef | pgrep -f "java")' &gt;&gt; stop chmod +x stop sleep 1 # Create SystemD Script to run Minecraft server jar on reboot cd /etc/systemd/system/ touch minecraft.service printf '[Unit]\nDescription=Minecraft Server on start up\nWants=network-online.target\n[Service]\nUser=minecraft\nWorkingDirectory=/opt/minecraft/server\nExecStart=/opt/minecraft/server/start\nStandardInput=null\n[Install]\nWantedBy=multi-user.target' &gt;&gt; minecraft.service sudo systemctl daemon-reload sudo systemctl enable minecraft.service sudo systemctl start minecraft.service # End script 次に、Minecraft サーバーファイルをダウンロードするために、スクリプトにリンクを追加する必要があります。Minecraft サーバーの最新バージョンを実行するには、公式の Minecraft サーバーダウンロードページ にアクセスしてください。 Download minecraft_server.1.20.4.jar and run it with the following command: と表示されている場所を見つけてください。ハイパーリンク Minecraft_server.jar を右クリックして、リンクをコピーします。 下の画像は、Minecraftの公式サイトからサーバー jar ファイルのダウンロードリンクを取得する方法を示しています。 前のステップでコピーしたリンクを使用して、EC2 インスタンス起動ページの ユーザーデータ に戻ります。スクリプトの上部にある MINECRAFTSERVERURL= フィールドを探してください。マインクラフトサーバーのリンクを MINECRAFTSERVERURL 変数フィールドに貼り付けます。 = と貼り付けようとしている Minecraft jar ファイルの URL の間にスペースを入れないでください。スクリプトの他の部分は編集しないでください。以下の画像は、ユーザーデータフィールドでの正しい設定の例を示しています。 例: Minecraft 1.20.1 では、ユーザーデータ内のコマンドは以下になります。 “MINECRAFTSERVERURL= https://piston-data.mojang.com/v1/objects/84194a2f286ef7c14ed7ce0090dba59902951553/server.jar” 上記の手順をすべて完了したら、 インスタンスを起動 を押します。EC2 インスタンスは、初回起動時にサーバーの設定と起動に最大 5 ～ 10 分かかる場合があります。Minecraft サーバーをテストするには、インスタンス設定でパブリック IPv4 アドレスを探し、起動後数分経ってから Minecraft でその IP に接続します。 Minecraft サーバーへの接続に問題がある場合は、以下のオプションを試してください。 ユーザーデータスクリプトは、初回起動時に実行に最大 10 分かかることがあるため、十分に待ってください。 EC2 インスタンスを停止して起動してみてください。 セキュリティグループのネットワーク設定を確認してください。 マインクラフトサーバー専用の IP アドレスを設定する EC2 インスタンスがオフになるたびに、そのパブリック IP アドレスが変更されます。サーバーの電源を入れたり切ったりするたびに新しい IP を検索しなければならないのは非効率的です。この問題を解決するために、Elastic IP を EC2 インスタンスに関連付けます。Elastic IP アドレスは、変更されず、さまざまなリソースにアタッチできる専用 IP アドレスです。 Elastic IP などのパブリック IPv4 アドレスには、AWS 上で 料金が発生 します。コストを節約するためには、サーバーがしばらくアイドル状態になる場合は、 Elastic IP アドレスを解放してから、EC2 インスタンスを停止します。Elastic IP を解放して再度関連付けると、サーバーの IP アドレスが変更されることが多いことに注意してください。 Elastic IP のセットアップ EC2 ダッシュボードで、左側のツールバーを展開します。 ネットワーク&amp;セキュリティ で、 Elastic IP をクリックします。 右上の Elastic IP アドレスの割り当てる ボタンをクリックします。 Amazon の IPv4 アドレスプール からパブリック IPv4 を選択します。 割り当て を押します。 Elastic IP を選択し、 アクション → Elastic IP アドレスの関連付け をクリックします。リソースタイプを インスタンス としてクリックし、ドロップダウンメニューから Minecraft Server インスタンスを選択します。次に、 関連付ける をクリックします。 Minecraft Server EC2 インスタンスに戻り、パブリック IPv4 フィールドの下を見るとご自身の Elastic IP アドレスを確認できます。 Minecraft サーバーに接続するには、ゲームのマルチプレイヤー画面に移動し、サーバーを追加するか、直接接続を使用してください。 サーバーアドレス フィールドに、EC2 インスタンスのパブリック IPv4 アドレスを入力します。Elastic IP をインスタンスに関連付けた場合、Elastic IP はサーバーアドレスになります。 サーバーオペレータの設定、ワールドファイルの変更など Minecraft サーバーのセットアップが完了したので、ゲーム内でコマンドを実行するサーバーオペレーターを追加する必要があります。新しいワールドファイルのアップロード、プラグインの追加などもできます。これは、EC2 インスタンスのセットアップ時に設定した EC2 Instance Connect を介して行うことができます。 まず、EC2 ダッシュボードに移動し、Minecraft サーバーの EC2 インスタンスを見つけ、その横にあるチェックボックスをクリックして、コンソールの上部にある 接続 ボタンを押します。 インスタンスに接続 画面で、下にスクロールして 接続 をクリックします。ユーザーはすでに ec2-user になっているはずです。そうでない場合は、 ec2-user 　に変更してください。接続に失敗した場合は、EC2 インスタンスを再起動し、数分待ってから再試行できます。接続するオプションがない場合は、EC2 インスタンスを正しく設定していない可能性があります。EC2 インスタンスのセットアップセクションに戻って再確認する必要があります。 ここでは、一般的なトラブルシューティングのヒントをいくつか紹介しています。 ログインに成功すると、端末画面が表示されます。次に、一連のコマンドを入力して Minecraft サーバーディレクトリに移動し、必要な設定ファイルを編集します。 まず、 cd /opt/minecraft/server/ と入力して Enter キーを押します。これは サーバーファイルが格納されている EC2 インスタンスのディレクトリです。将来サーバー設定を編集する場合に備えて、このディレクトリを覚えておいてください。 ls と入力して Enter キーを押して、サーバーファイルがすべて存在することを確認します。下の画像の ls コマンドにリストされているものと同じ出力が表示されるはずです (例: world、logs、server.jar)。 start と stop が緑色に強調表示されていることに注意してください。 start ファイルは、EC2 インスタンスを起動したり再起動したりするたびに自動的に実行される実行ファイルです。この機能が Minecraft サーバーを起動するので、手動で起動する必要はありません。これらは編集しないでください。 Minecraft サーバーコンソールは表示されませんが、まだ実行中です。最初にサーバーをオフにしないと、ファイルまたはフォルダーを編集できません。そのためには、 sudo ./stop と入力して stop スクリプトを実行します。これにより、 stop スクリプトが管理者として実行されます。これで、新しいワールドやプラグインなどを追加できます。 下の画像は、EC2 インスタンスの接続画面と、赤色のボックスで囲われた入力が必要な一連のコマンドを示しています。 また、 SCP コマンド または Amazon S3 を使用してアップロードすることで、ローカルコンピューターから EC2 インスタンスに新しいワールドやその他のファイルをアップロードすることもできます。また、 server.properties ファイルを vim や nano などの UNIX テキストエディターで編集することもできます。 オペレータを追加したり、コンソール自体からコマンドを実行したりするには、 sudo ./start と入力してサーバを再実行する必要があります。これにより、起動スクリプトが管理者として実行され、Minecraft サーバーがロードされます。下の画像のようにサーバーコンソールが起動します。サーバーが起動するまでに数分かかることがあります。 コンソールに Done と表示されたら、サーバーは稼働しています。これで、ターミナルで / なしで通常の Minecraft コマンドを入力して実行できます。たとえば、プレイヤーをオペレーターとして追加するには、 op *PLAYERNAMEHERE* と入力します。 以下は、ロードが完了したときにサーバーコンソールが出力する内容の参照画像です。サンプルプレイヤー名を使用して、サーバーのオペレーターとして追加しました。 お疲れ様でした！サーバーディレクトリに正常にアクセスし、好みに合わせて変更しました。アップロードするサーバーファイルを完全に制御できます。MOD、プラグインなどを追加していきましょう！ クリーンアップ この投稿でプロビジョニングされたリソースから課金されないように、リソースをクリーンアップします。 EC2 ダッシュボードで、選択ボックスを使用して EC2 インスタンスを選択します。右上の インスタンスの状態 を選択し、 終了 を選択 します。 同じ EC2 の画面で、サイドバーを開いて Elastic IP を選択します。EC2 インスタンスに使用されている Elastic IP の横にある選択ボックスを押し、右上の アクション を押して、 Elastic IP アドレスの解放 を押します。 リソースのクリーンアップが完了しました。 結論 おめでとうございます！これで、専用 IP アドレスを持つ EC2 インスタンスに Minecraft サーバーができました。Minecraft サーバーでプレイしていないときは、EC2 インスタンスを小まめに停止することを強くお勧めします。これにより、コストを節約でき、 Minecraft サーバーが立ち上がっているときのみ料金が発生します。次のステップとして、Minecraft Server が使用されていないときに EC2 インスタンスを自動的に停止するソリューションの開発を検討することをお勧めします。 本ブログはソリューションアーキテクトの濵野が翻訳しました。原文は こちら です。

はじめに ソフトウェア開発および運用業界は近代化を進めており、プロセスの標準アプローチとして DevOps を採用するケースが増えています。しかし、SAP のインストールと運用は依然として手作業で行われる傾向にあります。これを自動化されたアプローチに進化させるために、 1 つ目のブログ記事 で、Terraform と AWS Launch Wizard などのネイティブ AWS ツールを使用して SAP アプリケーションのインフラストラクチャをプロビジョニングする方法を示しました。続いて 2 番目のブログ記事 では、AWS Systems Manager を使用した SAP ソフトウェアのインストールの自動化について説明しました。最後に、 3 番目のブログ記事 では、自動化について詳しく説明し、高可用性 (HA) で動作する SAP ランドスケープのフルインストールをエンドツーエンドで実行しました。 このブログ記事では、SAP ランドスケープの運用に重点を置いています。アプリケーションの耐障害性を理解し、デプロイされたアプリケーションが目標復旧時間を満たしていることを確認するには、高可用性テストが必要です 。多くの組織では、監査プロセスへの準拠を維持するために、高可用性構成を時々テストする必要もあります。 このブログで詳しく説明されているソリューションは、AWS SAP プロフェッショナルサービスチームが多くのお客様と共同で行った SAP HANA ワークロードの高可用性クラスタのデプロイとテストを自動化した結果です。SAP HANA ワークロードの高可用性クラスタは、お客様が必要に応じて使用および適応できるオープンソース (以下のリンク) として提供されています。 このブログ記事では、 カオスエンジニアリング と呼ばれる業界全体のプラクティスを SAP の世界に紹介しています。これにより、SAP ランドスケープの動作について確信が持てるようになり、予測可能性が高まります。また、システム停止や重大なエラーの発生後に自己修復するように構成する方法についても同様です。 カオスエンジニアリングを適用すると、問題が発生する前に潜在的な問題を特定できるため、SAP ランドスケープの回復力を向上させることができますが、当社の経験から言うと、必要な一連のテストシナリオを手動で実行するには最大で 2 か月かかることがあり、ほとんどの組織では高度なスキルを持つ専門家が必要です。 このブログ記事では、これらのテストシナリオを自動化し、チームの時間を大幅に節約し、監査プロセスのコンプライアンスを維持するための出発点として使用できるサンプルコードを共有します。 一般的な手動アプローチと比較して、このソリューションが HA 構成のテストにもたらすメリットは次のとおりです。 スピード: 約 2 か月から数時間。 信頼性: 12 の HA テストシナリオ (後述) を反復可能なプロセスでカバーします。 ヒューマンエラーの削減: HA テストは繰り返し可能なプロセスになるため、ヒューマンエラーによるテストの潜在的な失敗率が減少します。 監査資産: このソリューションによって生成される最終的な HTML レポートには、監査資産に必要な共通情報がすべて含まれています。 改善資産: エラーが発生した場合、最終的な HTML レポートではテスト中に具体的に何が問題になったかが強調され、エラーの前後のシステムの全体像も示されます。その後、この問題は SAP BASIS の専門家に解析され、高可用性構成に関する修正が適用されます。 ここで紹介するソリューションには、いくつかの異なる実行方法があります。しかし、最終的には、「レポート」セクションで示した例のように、すべてが HTML レポートを生成します。 このソリューションを出発点として、必要なコードがすべて揃った パブリック GitHub リポジトリ があります。実行方法を理解するには、「How to Run」のセクションを参照してください。 このガイド を使えば、簡単なラボ環境を構築できます。このサンプルコードは、企業での HA テストの自動化に必要な労力を軽減するための出発点として使用してください。このサンプルコードは、RedHat OS (オペレーティングシステム) 上の SAP HANA 1909 で実行できるようにビルドされ、テストされています。 前提条件 このガイドを開始してこのコードを実行する前に、以下の前提条件を満たす必要があります。 Ansible をコントローラインスタンスにインストールします。コントローラインスタンスには以下のものがあります。 独自のインスタンス、ラップトップ、ワークステーション このソリューションの実行を自動化する CI/CD ツール アンシブルタワー コントローラインスタンスと HA テストを実行する SAP ランドスケープインスタンスとの間に SSH アクセスと接続が確立されました。 1 つの SAP ランドスケープの構成は次のとおりです。 HA が以前に構成された 2 つの HANA インスタンス。詳細については、Red Hat Enterprise Linux クラスターの設定に関する AWS ドキュメント 「 configuring Red Hat Enterprise Linux clusters for SAP on AWS 」 を参照してください。 ASCS インスタンス 1 つ PAS インスタンス 1 つ AWS CLI (コマンドラインインターフェイス) で以下の権限が設定された 1 つの AWS IAM ロール。このロールはコントローラインスタンスの AWS CLI で設定する必要があります。Ansible はテスト中にこれを使用して SAP ランドスケープとやり取りします。詳細については、AWS CLI に追加のプロファイルを設定する方法をご覧ください。 ec2:StartInstance で全てのインスタンスを起動する ec2:RebootInstances で全てのインスタンスを再起動する ec2:StopInstances の全てのインスタンスを停止する AMI を作成し、このシナリオに関係するインスタンスから各 EBS ボリュームのスナップショットをバックアップとしてキャプチャします。 想定するする高可用性テストシナリオ 各テストシナリオの目標は、すべてのテストを一度に実行したくない場合に備えて、スタンドアロンのテストとして役立つようにすることです。そのために、テストシナリオの前後に特定のタスクを実行して、環境の設定が有効で、テストが正常に完了したことを確認しています。これらの一般的な手順は、実行順序に示されているとおりです。 実行に必要なすべての入力パラメータが通知されましたか? ノードとコントローラーノードは接続されていますか? どのノードがプライマリで、どのノードがセカンダリか? 最低限の高可用性構成は整っているか? HANA に設定されているレプリケーションモードは、フェイルオーバー前とフェイルオーバー後に同じですか? テスト開始前の ASCS エンキュー番号はいくつですか?フェイルオーバー後の番号と一致していますか? PAS は正しいデータベースインスタンスに接続されていますか?フェイルオーバー前とフェイルオーバー後? GitHub リポジトリにあるテストシナリオは以下の通りです。 プライマリデータベースの「HDB Stop」。 新しいプライマリデータベースで「HDB Stop」(フェイルオーバー後)。 セカンダリデータベースの「HDB Stop」。 プライマリデータベースの「PCS node standby」。 新しいプライマリデータベースの「PCS node standby」(フェイルオーバー後)。 プライマリデータベースの「kill -9 pid」。 プライマリデータベースに「echo ‘b’ &gt; /proc/sysrq-trigger」があると、インスタンスがクラッシュします。 新しいプライマリデータベースで「echo ‘b’ &gt; /proc/sysrq-trigger」が発生してインスタンスがクラッシュする (フェイルオーバー後)。 プライマリデータベースで「HDB kill -9」が発生しました。 新しいプライマリデータベースで「HDB kill -9」(フェイルオーバー後)。 プライマリデータベースを再起動。 新しいプライマリデータベースを再起動 (フェールオーバー後)。 レポート 図 1 — 最後のステップで障害が発生して生成された HTML レポートの例 図 1 に示されている HTML は、 実行された 2 つのシナリオ を示しています（さらに、実際のテストを実行する前にシステム構成を全体的にチェックする #1 と、 #6 のシステムクラッシュに必要な事後処理である #7）。そのうちの1つは成功（HDB 停止、ケース #3、#4、#5）、システムクラッシュ（#6）は、ポストアクションステップ（#7）で見つかったように）失敗しました。 コードの実行方法 シングルボタンによる代替方法: 3番目のブログ記事で説明したソリューションを使用している場合は、プロジェクトをリロードし (1 — vagrant destroy、2 — git pull、3 — vagrant up)、[Credentials] ですべてのパラメータを再入力し、[SAP Hana+ASCS+PAS 3 Instances] フォルダの下にある [Run HANA HA test] としてリストされている新しいジョブを見つけて、[build now] をクリックします。図 2 は、テストが完了した後の結果を示しています。 画像 2 — Jenkins パイプラインを使用して HA テストを実行したときの最終出力 これが完了すると、次の場所に移動する HTML レポートが表示されます。 ビルド番号 (この場合は 24) をクリックし、 「Workspaces」に移動します。 リストされている最初の項目を選択します。 フォルダー Report を選択し、 「report-&lt;current date and time&gt;.html」を右クリックし、ローカルデスクトップに保存します。必ずローカルに保存してください。保存しないと、レポートの形式が正しくありません。 図 3 — 最終的な HTML レポートをローカルに保存する 主な手順 Linux または Mac コンピューター上のターミナルにアクセスできる環境を用意します。 AWS CLI をローカルに設定してください。 GitHub リポジトリのクローンを作成してください。 各サーバー (HANA プライマリ、HANA セカンダリ、ASCS、PAS) について、hosts.yaml ファイルの情報を更新します。 ansible_host ansible_user ansible_ssh_private_key_file var_file.yaml を開いて、必要な情報を入力します。 # Field Default value Comments Information for HANA 1 INPUT_HANA_SID AD0 Your HANA SID 2 INPUT_HANA_INSTANCE_NUMBER 0 Your HANA instance number 3 INPUT_SYSTEM_USER SYSTEM Username for the SYSTEM default user. This will be used to check if a backup is available before starting the tests 4 INPUT_SYSTEM_PASSWORD P@ssw0rd Password for the SYSTEM user. This will be used to check if a backup is available before starting the tests 5 INPUT_HANA_SYNC_MODE SYNC HANA replication mode Information for ASCS 6 INPUT_ASCS_SID AD0 Your ASCS SID 7 INPUT_ASCS_INSTANCE_NUMBER 0 Your ASCS instance number Information for PAS 8 INPUT_PAS_SID AD0 Your PAS SID 9 INPUT_PAS_INSTANCE_NUMBER 0 Your PAS instance number 10 INPUT_CHECK_R3_TRANS TRUE Whether to check the R3trans command on PAS after database failovers or not Information for AWS CLI 11 INPUT_AWS_REGION us-east-1 The region where your instances are 12 INPUT_AWS_CLI_PROFILE default The profile you configured for your AWS CLI on Pre requisites, item 2 13 INPUT_PRIVATE_SSH_KEY /my/path/to/pemFile.pem Path to the SSH key for Ansible to SSH into your instances ファイル「how_to_run.sh」を実行してください。 これがソリューションを実行する一番の近道です。BASH に慣れている場合は、「how_to_run.sh」ファイルを見てその動作を理解し、自分のシナリオで自動化できる可能性を見つけることをお勧めします。 HANA のサイズと構成によって、この作業には多少時間がかかります。ベンチマークとして、空の SAP ランドスケープインストールで 12 のシナリオをすべて実行すると、約 45 分から 1 時間かかります。 SAP 環境が大きい場合は、「More configurations allowed」のセクションをよく読んでソリューションの実行方法をカスタマイズし、シナリオを複数の実行に分割することをお勧めします。これにより、大量のテストを実行する前に、より短い時間枠で出力を確認し、インストールで発生する可能性のあるエラーを理解できます。 最終レポートを分析 テストが完了すると、各テストの結果を含む HTML レポートが生成されます。障害が発生した場合、このレポートには修復計画を設計するための基本リソースとして必要な情報がすべて記載されています。これにより、(1) どのテストがうまくいかなかったかを理解するための情報が得られます。(2) 失敗したコマンドは具体的にどれですか ? そして (3) そのコマンドがエラーになる直前にサーバーはどのように構成されていましたか? レポートには (上記の項目 3 を理解しやすくするため)、調査に役立つ最も一般的な SAP HANA トラブルシューティングコマンドのスナップショットがいくつか記載されています。レポートに記載されているコマンド情報の例: crm_mon -A1 HDB proc hdbnsutil -sr_state hdbuserstore list python systemReplicationStatus.py sapcontrol (…) -function GetProcessList 図 1 に示すレポート例に従い、手順 7 で「失敗」をクリックすると、画面は手順7の「Run POST ACTIONS for Scenario CRASH_NODE_PROC_PRE:」の詳細に移動します。 図 4 — エラーが発生したステップの詳細 赤色のステップの前の青色のステップは、エラーが発生する前にシステムで実行されたアクションを示しています。これを使うと、エラーが発生する前のシステム状態を理解できます。 エラー自体は赤色で表示され、何が起きたかを示す追加情報も表示されます。図 5 は、フェイルオーバーイベントの後も PAS が古いノードに接続されたままで、新しいプライマリノードに切り替えなかったことが検出された例を示しています。 図 5 — エラーが強調表示 テストシナリオの量と順序のカスタマイズ このソリューションは 12 のシナリオすべてを実行するように事前に構成されていますが、Ansible に慣れて実行方法を変更したい場合は、目的に合わせてシナリオの数を減らすことができます。そのためには、aws-sap-hana-ha-test/main.yaml ファイルを見つけて、実行したくないブロックにコメントを付けてください。1 番目と 2 番目のブロック (「Check Inputs」と「Check current HA installation (prep / bridge tasks)」) は必須で、常に実行する必要があります。 例えば、単純な「HDB Stop」シナリオだけを実行して解決策を知りたいとしましょう。そうすれば、66 行から最後までのすべての行にコメントできます。 ほとんどのシナリオはスタンドアロンで、さまざまな順序で実行できるため、すべてをカスタマイズできます。唯一の例外は「Crush Instance」シナリオで、その後に「Post Action」シナリオを含める必要があります。そのため、93 行目または 111 行目のクラッシュシナリオを実行している場合は、そのすぐ下のシナリオ (それぞれ 102 行目と 120 行目) にしてください。 次のステップ 始める準備はできましたか?インストール自動化リポジトリに直接アクセスして、ご使用の環境でのテストを開始してください。 テストが完了したら、特定のニーズに合わせてリポジトリをカスタマイズできます。リポジトリのフォルダには README があり、各フォルダがどのように機能してすべてをまとめ、最終的に SAP を実行させるかについての詳細な説明が記載されています。 SAP システムを DevOps モデルに移行する際に専門家によるガイダンスやプロジェクトサポートを求めている場合は、AWS プロフェッショナルサービスグローバル SAP 専門プラクティスが役に立ちます。ハウスサービスや Phillips 66 などの SAP on AWS のお客様が、SAP 変革を加速させるために当社のチームとの連携に投資するケースが増えています。私たちがどのように支援できるかについて詳しく知りたい場合は、 AWS プロフェッショナルサービスチーム にお問い合わせください。 何千ものお客様が AWS for SAP を選択する理由については、 AWSの SAP ページ をご覧ください。 SAP on AWS ディスカッションにご参加ください。 カスタマーアカウントチームと AWS サポートチャネルに加えて、re: POST — AWS コミュニティ向けの最適化された Q&amp;A エクスペリエンスを通じて 私たちとつながることができます。SAP on AWS ソリューションアーキテクチャチームは定期的に SAP on AWS のトピックを監視し、お客様やパートナーを支援するためのディスカッションや質問に回答しています。質問がサポートに関連していない場合は、 re: Post でのディスカッションに参加して、コミュニティのナレッジベースに追加することを検討してください。 翻訳は Partner SA 松本が担当しました。原文は こちら です。

1月11日は、 Amazon Elastic Container Service (Amazon ECS) が Amazon Elastic Block Store (Amazon EBS) との統合のサポートを開始し、より広範なデータ処理ワークロードをより簡単に実行できるようになったことを皆さんにお知らせしたいと思います。 AWS Fargate および Amazon Elastic Compute Cloud (Amazon EC2) で実行されている ECS タスクに Amazon EBS ストレージをプロビジョニングでき、ストレージやコンピューティングの管理は必要ありません。 コンテナ化されたパッケージとしてアプリケーションをデプロイすることを多くの組織が選択していますが、Amazon ECS の Amazon EBS との統合の導入により、組織はこれまで以上に多くのワークロードタイプを実行できるようになります。 既存のデータをフェッチし、処理を実行して、処理されたデータをダウンストリームでの使用のために保存する必要がある、ビッグデータの抽出、変換、ロード (ETL) ジョブなど、大量のトランザクションと高スループットをサポートするストレージが必要なデータワークロードを実行できます。ストレージライフサイクルは Amazon ECS が完全に管理するため、インフラストラクチャの更新を管理するために追加のスキャフォールディングを構築する必要がありません。その結果、データ処理ワークロードのレジリエンシーが向上すると同時に、管理に必要な労力も軽減されます。 これからは、Amazon ECS で実行されるコンテナ化されたアプリケーションのためのストレージを、さまざまなオプションから選択できるようになります。 Fargate タスクには、デフォルトで 20 GiB の エフェメラルストレージ が提供されます。大規模なコンテナイメージのダウンロードや、スクラッチ作業のために追加のストレージ容量が必要になるアプリケーションには、Fargate タスク用に最大 200 GiB のエフェメラルストレージを設定できます。 共有データセットに同時にアクセスする必要がある多数のタスクにまたがったアプリケーションの場合は、EC2 と Fargate の両方で実行されている ECS タスクに Amazon Elastic File System (Amazon EFS) ファイルシステムをマウントするように Amazon ECS を設定できます。このようなワークロードの一般的な例には、コンテンツ管理システムなどのウェブアプリケーション、社内 DevOps ツール、および機械学習 (ML) フレームワークが含まれます。Amazon EFS はリージョン全体で利用できるように設計されており、多数のタスクに同時にアタッチできます。 タスク全体で共有する必要がない、高パフォーマンスで低コストのストレージを必要とするアプリケーションの場合は、Amazon EBS ストレージをプロビジョニングして、Amazon EC2 と Fargate の両方で実行されているタスクにアタッチするように Amazon ECS を設定できます。Amazon EBS は、アベイラビリティーゾーン内で低レイテンシーかつ高パフォーマンスのブロックストレージを提供するように設計されています。 詳細については、AWS ドキュメントの「 Amazon ECS タスクでのデータボリュームの使用 」と「 Persistent storage best practices 」を参照してください。 EBS ボリュームの ECS タスクへの統合の開始方法 タスク定義でコンテナのボリュームマウントポイントを設定し、ランタイムで Amazon ECS タスク用の Amazon EBS ストレージ要件を渡すことができます。ほとんどのユースケースでは、タスクに必要なボリュームのサイズを指定するだけで開始できます。オプションで、すべての EBS ボリューム属性と、ボリュームのフォーマットに使用したいファイルシステムを設定できます。 1.タスク定義を作成する Amazon ECS コンソール にアクセスし、 [タスク定義] に移動してから、 [新しいタスク定義の作成] を選択します。 [ストレージ] セクションで [デプロイ時に設定] を選択し、新しい設定タイプとして EBS ボリュームを設定します。Linux ファイルシステムでは、タスクごとに 1 つのボリュームをプロビジョニングしてアタッチできます。 [タスク定義の作成時に設定] を選択する場合は、バインドマウント、Docker ボリューム、EFS ボリューム、 Amazon FSx for Windows File Server ボリューム、または Fargate エフェメラルストレージなどの既存のストレージオプションを設定できます。 これで、タスク定義でコンテナとソース EBS ボリュームを選択し、タスク内でボリュームがマウントされるマウントパスを指定できるようになりました。 $aws ecs register-task-definition --cli-input-json file://example.json コマンドラインを使用して、EBS ボリュームを追加するためのタスク定義を登録することもできます。以下のスニペットはサンプルで、タスク定義が JSON 形式で保存されています。 { "family": "nginx" ... "containerDefinitions": [ { ... "mountPoints": [ "containerPath": "/foo", "sourceVoumne": "new-ebs-volume" ], "name": "nginx", "image": "nginx" } ], "volumes": [ { "name": "/foo", "configuredAtRuntime": true } ] } 2.EBS ボリュームでタスクをデプロイして実行する これで、タスクを ECS クラスターで選択することによって、タスクを実行できるようになりました。ECS クラスターに移動して、 [新しいタスクの実行] を選択します。コンピューティングオプション、起動タイプ、およびタスク定義を選択できることに留意してください。 注意: この例では、アタッチされた EBS ボリュームを使用したスタンドアロンタスクのデプロイを説明していますが、必要に応じて設定された EBS ボリュームを使用するように、新規または既存の ECS サービスを設定することも可能です。 追加のストレージを設定できる新しい [ボリューム] セクションが表示されます。ボリューム名、タイプ、およびマウントポイントは、タスク定義で定義したものです。 EBS ボリュームタイプ 、サイズ (GiB)、IOP、および目的のスループットを選択します。 既存の EBS ボリュームを ECS タスクにアタッチすることはできません。ただし、既存のスナップショットからボリュームを作成する場合は、スナップショット ID を選択するオプションがあります。新しいボリュームを作成する場合は、このフィールドは空白のままにしておくことができます。ファイルシステムのタイプは、Linux の ext3 または ext4 ファイルシステムを選択できます。 タスクが終了すると、Amazon ECS がデフォルトでアタッチされたボリュームを削除します。タスクの終了後に EBS ボリューム内のデータを保持する必要がある場合は、 [終了時に削除] のチェックを外します。また、Amazon ECS がユーザーに代わって API コールを実行できるようにするための関連許可が含まれた、ボリューム管理用の AWS Identity and Access Management (IAM) ロールを作成する必要もあります。このポリシーの詳細については、AWS ドキュメントで インフラストラクチャロール を参照してください。 Amazon マネージドキーとカスタマーマネージドキーのどちらかを使用して、EBS ボリュームで暗号化を設定することも可能です。これらのオプションの詳細については、AWS ドキュメントの「 Amazon EBS 暗号化 」を参照してください。 すべてのタスク設定を完了したら、 [作成] を選択してタスクを開始します。 3.EBS ボリュームでタスクをデプロイして実行する タスクが開始されると、タスク定義の詳細ページでボリューム情報を確認できます。タスクを選択し、 [ボリューム] タブを選択することで、作成した EBS ボリュームの詳細情報を表示します。 チームは、EBS ボリュームの開発と運用をより効率的に整理することができます。例えば、アプリケーション開発者は、利用可能なストレージがあることをアプリケーションが想定するパスをタスク定義で設定でき、DevOps エンジニアは、アプリケーションデプロイ時のランタイムで実際の EBS ボリューム属性を設定できます。 これは、DevOps エンジニアが、開発環境の gp3 ボリュームや本番環境の io2 ボリュームなど、異なる EBS ボリューム設定を使用する異なる環境に同じタスク定義をデプロイすることを可能にします。 今すぐご利用いただけます Amazon ECS の Amazon EBS との統合は、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、および欧州 (ストックホルム) の 9 つの AWS リージョンでご利用いただけます。お支払いいただく料金は、使用分の料金のみです (EBS ボリュームとスナップショットを含む)。詳細については、「 Amazon EBS の料金 」ページと、AWS ECS ドキュメントの「 Amazon EBS volumes 」を参照してください。 この機能をぜひお試しいただき、AWS の Public Roadmap 、 AWS re:Post for Amazon ECS 、または通常の AWS サポートの連絡先を通じてフィードバックをお寄せください。 – Channy P.S.このブログ投稿の執筆に貢献してくれた AWS のシニアエンタープライズデベロッパーアドボケイトである Maish Saidel-Keesing に心から感謝します。 原文は こちら です。

明けましておめでとうございます! クラウドテクノロジー、機械学習、そして生成系 AI の利用はますます簡単になっており、私たちの生活のほぼすべての側面に影響を及ぼしています。Amazon の CTO であるワーナー ヴォゲルス博士は、2024 年以降のテクノロジーについて 4 つの予測を立てています。 生成系 AI が文化を認識するようになる フェムテックがついに実力を発揮する AI アシスタントが開発者の生産性を再定義する 教育がテクノロジーのスピードに合わせて進化する テクノロジーに関するこれらの動向がどのように凝縮され、社会で最も困難な問題の解決に役立つかについては、「 Werner Vogels’ Tech Predictions for 2024 and Beyond 」ebook をダウンロードするか、ヴォゲルス博士の All Things Distributed ブログ をお読みください。 AWS および業界のソートリーダーたちからのインサイトを聞き、スキルを向上させて、インスピレーションを得るには、オンデマンドの AWS re:Invent 2023 動画 で、基調講演、イノベーショントーク、ブレークアウトセッション、および AWS ヒーローガイドのプレイリストを視聴しましょう。 過去数週間のリリース 2023 年 12 月 18 日の 前回の Weekly Roundup 以降の、年末そして先週からのリリースをいくつか取り上げたいと思います。 新しい AWS カナダ西部 (カルガリー) リージョン – カナダで 2 番目の新リージョン、AWS カナダ西部 (カルガリー) が開設されます。2023 年末の時点で、AWS には世界各国に 33 の AWS リージョンと 105 のアベイラビリティーゾーン (AZ) がありました。以前に、マレーシア、ニュージーランド、タイ、および AWS European Sovereign Cloud で開設予定の 4 つのリージョンに追加される 12 のアベイラビリティーゾーンについてお知らせしましたが、2024 年はこれらのリージョンについてより詳しい情報をお伝えしていくので、ぜひご期待ください。 Amazon Route 53 Resolver での DNS over HTTPS – インバウンドとアウトバウンド両方の Route 53 Resolver エンドポイントに DNS over HTTPS (DoH) プロトコルを使用できます。その名の通り、DoH は、HTTP over TLS または HTTP/2 over TLS をサポートして、ドメインネームシステム (DNS) 解決のために交換されるデータを暗号化します。 Amazon RDS 延長サポートへの自動登録 – 2024 年 2 月 29 日から、 Amazon Aurora および Amazon RDS で実行されている MySQL 5.7 データベースインスタンスと PostgreSQL 11 データベースインスタンスが Amazon RDS 延長サポートに自動登録されます。これにより、コミュニティサポートの終了 (EoL) 後にデータベースのメジャーバージョンへのアップグレードを実行するタイミングをよりよく制御できます。 新しい Amazon CloudWatch Network Monitor – Amazon CloudWatch の新機能で、AWS とオンプレミス環境間におけるネットワークの可用性とパフォーマンスのモニタリングに役立ちます。Network Monitor は手動インストルメンテーションが不要で、AWS のネットワークとユーザー独自のハイブリッド環境内の問題をプロアクティブかつ迅速に特定するためのリアルタイムのネットワーク可視性を提供します。詳細については、「 Monitor hybrid connectivity with Amazon CloudWatch Network Monitor 」をお読みください。 Amazon Aurora PostgreSQL の Amazon Bedrock との統合 – 生成系 AI アプリケーションを強化するための Aurora PostgreSQL データベースの Amazon Bedrock との統合には、2 つの方法を使用できます。 Amazon Bedrock との Aurora ML の統合 、および 検索拡張生成 (RAG) のための Knowledge Bases for Amazon Bedrock を用いた Aurora ベクトルストア で SQL クエリを使用できます。 Amazon Lightsail での新しい WordPress セットアップ – ウェブサイト設定の複雑性と設定に費やす時間を排除する新しいワークフローを使用して、 Amazon Lightsail で WordPress ウェブサイトをセットアップします。このワークフローでは、HTTPS でウェブサイトをセキュア化するための SSL 証明書の設定を含めた、必要なステップのすべてを完了することができます。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 新年を迎えるにあたり、皆さんにとって興味深いと思われるその他のニュースをいくつかご紹介します。 AWS のエグゼクティブカスタマーにお勧めの本 – 新年の計画を立てて、他の人が何を実行し、何を考えているのかを理解しておきましょう。AWS エンタープライズ戦略チームが、AWS のエグゼクティブカスタマーに読んでいただきたい最も重要な本を推薦します。 プラットフォームエンジニアリングで AWS CDK 導入をスケールするためのベストプラクティス – DevOps における最近の進化は、ワークロードチームをサポートするサービス、ツールチェーン、およびドキュメントを構築するためのプラットフォームエンジニアリングチームの導入です。このブログ記事では、組織内での CDK の導入を促進するための戦略とベストプラクティスを紹介します。プラットフォームエンジニアリングを通じて、パイロットプロジェクトから学んだ教訓を組織全体にスケールする方法を学ぶことができます。 AWS Graviton インスタンスでの HPC アプリケーションの実行による高パフォーマンス – 数値流体力学 (CFD) 問題を解決するために Amazon EC2 Hpc7g インスタンス で Parallel Lattice Boltzmann Solver (Palabos) を実行すると、前世代の Graviton インスタンスと比較して、パフォーマンスが最大 70% 向上し、価格パフォーマンスも最大 3 倍向上しました。 新しい AWS open source newsletter、#181 – すべての最新オープンソースコンテンツをチェックしましょう。今週は、 AWS Amplify 、 Amazon Corretto 、dbt、Apache Flink、Karpenter、LangChain、および Pinecone などが取り上げられています。 AWS の今後のイベント カレンダーを確認して、新年に開催予定の次の AWS イベントにサインアップしましょう。 AWS at CES 2024 (1 月 9～12 日) – AWS が、自動車、モビリティ、輸送、および製造の各業界に特化した最新のクラウドサービスとソリューションを紹介します。 Amazon Experience Area に参加して、生成系 AI、ソフトウェア定義自動車、プロダクトエンジニアリング、サステナビリティ、新たなデジタルカスタマーエクスペリエンス、コネクテッドモビリティ、および自動運転などのさまざまな分野にまたがる最新のクラウド機能について学びましょう。 APJ Builders Online Series (1 月 18 日) – このオンラインカンファレンスは、AWS の中核的なコンセプトと、ステップバイステップのアーキテクチャのベストプラクティスを学ぶために設計されており、AWS の利用を開始し、成功を加速化させるために役立つデモンストレーションも行われます。 開催予定の AWS 主導の対面イベントや仮想イベント 、および AWS DevDay などの 開発者向けイベント のすべてを閲覧できます。 1月8日週はここまでです。1月15日週に再びアクセスして、新たな Week in Review をぜひお読みください! – Channy この投稿は、Week in Review シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

Epic Games が開発した Unreal Engine は、フォトリアリスティックなビジュアルや没入感のある体験を作成およびレンダリングするための最も高度なツールの 1 つです。これは最新のゲームとメタバースを強化するために必要です。従来、このような体験には、ディスクリートGPUを搭載した重厚なクライアント、たとえばデスクトップコンピューターが必要でした。Unreal Engine の Pixel Streaming を使用すると、クラウド内のサーバーで Unreal Engine アプリケーションを実行し、レンダリングされたフレームとオーディオを WebRTC を使用してブラウザやモバイルデバイスにストリーミングできます。 AWS と Unreal Engine の Pixel Streaming を使用することで、開発者は Unreal Engine でコンテンツを作成し、それを Windows または Linux 上の Amazon Elastic Compute (EC2) にデプロイできます。この記事では、Unreal Engine アプリケーションを大規模にデプロイする方法に焦点を当てます。つまり、ユーザーのストリーミングリクエストに基づいて EC2 インスタンスを起動および停止できるということです。この記事では、これらの EC2 インスタンスでのユーザーストリーミングセッションの管理についても説明します。 Pixel Streaming コンポーネントの概要 ホスティングとデプロイの観点から、Pixel Streaming ソリューションには 4 つの主要コンポーネントがあります。 ゲームロジックを実行する Unreal Engine アプリケーションパッケージ WebRTCプロトコルを介してクライアントにトラフィックを処理するための シグナリングおよびWebサーバー 、および CoTURN （TURNサーバー用） 複数のゲームインスタンスに負荷を分散し、クライアントとゲームアプリケーション間の接続を処理する マッチメーカーサーバー クライアント (ブラウザ) でパッケージセッションを実行する フロントエンドコンポーネント シグナリングサーバー、CoTurn サーバー、およびUnreal Engine アプリケーションは同じ Amazon EC2 インスタンスでホストできます。インスタンスには、 G4dn などのインスタンスファミリーが提供する GPU 機能が必要です。インスタンスには、CoTURN がクライアントとの WebRTC セッションを維持するためのパブリック IP アドレスも必要で、 パブリックサブネット にデプロイできます。この記事の残りの部分では、この Amazon EC2 インスタンスをシグナリングサーバーと呼びます。 マッチメーカーサーバーは、 プライベートサブネット にデプロイされた別の 汎用 Amazon EC2 インスタンスでホストできます。この記事の残りの部分では、この Amazon EC2 インスタンスをマッチメーカーサーバーと呼びます。 フロントエンドコンポーネントは、プライベートサブネットにデプロイされた別の汎用 Amazon EC2 インスタンスでホストできます。この Amazon EC2 インスタンスをフロントエンドサーバーと呼びます。 これらのコンポーネントがデプロイされると、ユーザーのデバイス (Web ブラウザーなど) からのストリーミングセッションのリクエストにより、次の一連の手順が開始されます。 フロントエンドサーバーはユーザーのリクエストを受け取り、ユーザーのブラウザーに Web ページをレンダリングします。 ユーザーは Web ページ上のボタンを選択してセッションをリクエストし、そのボタンがマッチメーカーサーバーを呼び出します。 マッチメーカーサーバーはユーザーリクエストを受信し、リクエストを処理できるシグナリングサーバーがあるかどうかを確認します。 シグナリングサーバーが使用可能な場合、マッチメーカーサーバーはシグナリングサーバーの詳細をユーザーのブラウザーで実行されている Web ページに送信します。 Web ページは、シグナリングサーバーへの WebSocket 接続を確立します。 シグナリングサーバーは、ストリーマーポートで Unreal Engine アプリケーションパッケージに接続し、ユーザー情報を渡します。 Unreal Engine アプリケーションパッケージは CoTURN を使用してすべてのストリームトラフィックをユーザーのウェブページに転送します。 注:フロントエンドサーバーのデフォルト実装は、シグナリングサーバーと直接通信します (ステップ 5)。マッチメーカーを利用する場合はフロントエンドサーバーを修正してください。 上記の一連の手順では、ストリーミングセッションが単一のユーザーリクエストでどのように機能するかを説明していますが、複数の同時ユーザーセッションリクエストを処理するにはどうすればよいでしょうか。 また、セッションが完了したら、シグナリングサーバーはどうしますか？ 最後に、シグナリングサーバーがユーザーストリーミングリクエストにすぐに対応できない場合はどうなるでしょうか。そのようなシナリオでのユーザーインタラクションの処理方法をはどうすべきでしょうか。 さらに重要なのは、このストリーミングフレームワークを設定する際に、コストとセキュリティをどのように管理するかということです。 ソリューションの概要 このセクションでは、これらの要件を満たすソリューションアーキテクチャを定義することで、これらの質問のいくつかに答えます。まず、ユーザーセッションのリクエストに基づいてシグナリングサーバーを作成できるカスタムの水平スケーリングフレームワークを構築します。スケーリングフレームワークは 2 つの主要コンポーネントで構成されています。 シグナリングサーバーをいつ作成する必要があるかを判断するトリガー シグナリングサーバーを作成するプロセス トリガーは、受信したユーザーセッションリクエストを識別し、そのリクエストを処理できるシグナリングサーバーをマッチメーカーサーバーに確認する必要があります。マッチメーカーサーバーが使用可能なシグナリングサーバーを返すことができない場合、トリガーロジックは新しいシグナリングサーバーの作成を開始します。このオーケストレーションは、ユーザーセッションリクエストで このロジック を実行する AWS Lambda 関数によって行われます。 シグナリングサーバーを作成するプロセスは、 新しい Amazon EC2 インスタンスを起動 し、シグナリングサーバーのコンポーネントをデプロイする AWS Lambda 関数に実装されます。さらに、シグナリングサーバーを アプリケーションロードバランサー (ALB) のターゲットグループに登録して、ロードバランサーの URL を使用してシグナリングサーバーにアクセスできるようにすることができます。 Amazon EventBridge ルールを作成できます。このルールは、シグナリングサーバーの 状態 が「実行中」に変更されたときにトリガーされます。次に、 AWS Lambda 関数を呼び出して、シグナリングサーバーをターゲットグループに登録します。以下の図は同じフローを示しています。 シグナリングサーバーが実行されると、その状態は マッチメーカーサーバーに通知 されます。その後、マッチメーカーサーバーはこのシグナリングサーバーを利用して新しいユーザーセッションリクエストを処理できます。Pixel Streaming の概要で説明したように、マッチメーカーサーバーには、ユーザーセッションリクエストを処理するために利用可能なシグナリングサーバーインスタンスを見つける ロジック があります。さらに、使用中のシグナリングサーバが新しいユーザセッション要求を処理するように選択されないようにします。 シグナリングサーバーはユーザーセッションリクエストに基づいて作成されるため、シグナリングサーバーがリクエストを処理できるようになるまで、リクエストを追跡する必要があります。この要件には、 Amazon Simple Queue Service(SQS) FIFO が適しています。これにより、ユーザーのリクエストを処理する準備ができるまで保存し、先入れ先出し（FIFO）などの何らかの順序付けを適用して、どのリクエストが最初に処理されるかを決定することもできます。トリガーはキューをポーリングして、受信するユーザーセッションリクエストを監視できます。 さらに、シグナリングサーバーがリクエストを処理できるようになったら、その情報をユーザーに中継する必要があります。これで、ユーザーはサーバーを利用してセッションを開始できます。WebSocket 接続はこの要件に適合します。これにより、ユーザーに定期的にポーリングしてシグナリングサーバーの可用性を問い合わせる必要がなくなり、シグナリングサーバーの情報をユーザーに中継できます。 Amazon API Gateway は WebSocket 接続 をサポートしており、AWS Lambda 関数を使用して、WebSocket 接続を介して シグナリングサーバーの詳細をユーザーに送信します、取得されたIPなどの情報からユーザーはシグナリングサーバーに接続 することができます。 次の図は、ユーザー要求を管理するためのキューと WebSocket 接続の使用方法を示しています。 前のセクションでは、AWS Lambda 関数と EventBridge を組み合わせてシグナリングサーバーを ALB ターゲットグループに登録する方法について説明しました。ただし、ALB URLが、ユーザーセッションのマッチメーカーサーバーによって識別された指定されたシグナリングサーバーにトラフィックを転送するようにする必要があります。これを実現するもう 1 つの方法は、ターゲットグループに関連付けられた A LB リスナー内のルール を使用して、固有のクエリ文字列で特定のシグナリングサーバーにアクセスできるようにすることです。このクエリ文字列は、新しく作成されたシグナリングサーバーをALBターゲットグループに登録するときに定義されます。次に、 AWS Lambda 関数がこのクエリ文字列を（WebSocket接続を介して）ユーザーに中継し、ユーザーがセッションの指定されたシグナリングサーバーに誘導されるようにします。 最後に、ユーザーセッションが完了したらシグナリングサーバーをスケールインするメカニズムが必要になります。これを実現するには複数の方法がありますが、1 つの選択肢は、シェル/バッチスクリプトを使用して一定期間後にインスタンスを停止することです。この期間は、ユーザーセッションリクエストが通常どのくらいの期間続くかによって決まります。 たとえば Linux インスタンスの場合、 ユーザーデータ に sudo shutdown -halt +20 を追加すると、20 分後にインスタンスが自動的に停止します。 Amazon EventBridge ルールは、インスタンスの状態が停止状態になったときにトリガーされ、 AWS Lambda 関数を呼び出して インスタンスを終了するように記述 できます。 セキュリティコントロール 送信中の暗号化をサポートするために、マッチメーカーサーバー、フロントエンドサーバー、およびシグナリングサーバーの ALB で HTTPS リスナー を設定できます。これにより、お客様のデバイスとのすべての通信がSSL経由になります。 認証用: フロントエンドサーバーでホストされているアプリケーションを ID プロバイダー (Amazon Cognito など) と統合してユーザーを認証し、 bearer token を Amazon API Gateway に送信できます。 Amazon API Gateway には、WebSocket 接続上のトークンを検証する AWS Lambda 関数 ( AuthorizeClient ) を含めることができます ( ソリューションダイアグラム の項目 #2、3、4)。 マッチメーカーサーバーは、クライアント ID とシークレットを使用して API 呼び出しを認証するように設定できます。 最適化のその他の範囲 マッチメーカーサーバーには、使用可能なすべてのシグナリングサーバーを追跡するためのパーシスタンスレイヤーがありません。これを管理するには、 Redis 用 Amazon ElastiCache のようなものを使用することを検討してください。詳細については、「 Redis 用 Amazon ElastiCache 入門 」の記事を参照してください。 シグナリングサーバーは、認証にトークンを要求するように変更できます。トークンは、フロントエンドからの WebSocket 接続の最初のメッセージとして渡すことができます。これは、 WebSocket 接続の認証パターン を調べることで実現できます。 コスト最適化に関する考慮事項 このソリューションでは、オンデマンドをシグナリングサーバーインスタンスの 購入オプション と見なしています。コストを最適化するために、ストリーミングセッションの完了時にインスタンスを終了するようにスケーリングフレームワークを設定できます。また、任意の時点で実行中のインスタンスの最大数の上限を設定することもできます。そのサンプル実装が リポジトリ に含まれています。 年間を通じて消費量がほぼ一定であれば、シグナリングサーバーのコスト削減の手段として、 Reserved Instances または Savings plans を検討する価値があります。 マッチメーカーとフロントエンドサーバーの場合、それらをコンテナ化して AWS Fargate でホストできるため、需要に応じたスケーリングが可能になります。ただし、これには、使用可能なシグナリングサーバーを追跡するための persistence layer をマッチメーカーサーバーに追加する必要があります。 まとめ この記事では、Unreal Engine Pixel Streaming を Amazon EC2 インスタンスに大規模にデプロイし、AWS のサービスを活用して複数のユーザーにオンデマンドでセッションを提供できるソリューションを構築する方法を示しました。この記事で提案されているソリューションのリファレンス実装は、この リポジトリ でホストされています。これをフレームワークとして使用してソリューションをさらに構築および最適化し、AWS で Pixel Streaming をすぐに使い始めることができます。 Unreal Engine のウェブサイト で Pixel Streaming について詳しく調べてください AWS サービスの詳細は こちら AWS のメタバースソリューション について学ぶ 翻訳はソリューションアーキテクトの嶋田が担当しました。原文は こちら です。

自治体のお客様において、現在ガバメントクラウドの利用検討が進んでいます。ガバメントクラウドを利用するうえでは、さまざまな事業者が分担して作業することが多いです。 例えば、「ネットワーク構築運用補助者」がネットワーク経路を整備し、「運用管理補助者」が運用管理を行う個別領域の上に、「ASP」がシステムを構築します。それぞれの事業者の詳細な役割分担については、 こちらのブログ をご参照ください。 単独利用方式の ASP が複数ある場合に、統合的に環境の統制をする体制を取るケースがあります。そのような場合、個別領域の運用管理補助者とは別に統合運用管理補助者を立てて、統合運用管理補助者がすべての AWS アカウントの統合管理を行います。 このブログでは、統合運用管理補助者が運用管理を行っていく上で気にするべき点や、参照できる資料をまとめました。作業内容の確認などに使っていただけるとうれしいです。 以下のような方を対象として記述しています。 統合運用管理補助者を担う事業者の方 統合運用管理補助者を立てることをご検討されており、詳細を知りたい自治体の方 以下の章で構成されています。 統合運用管理補助者が必要になる場合と担当する事業者について 統合運用管理補助者の役割範囲 マルチアカウントの場合の情報の集約方法 アラートが上がったときの対応について まとめ 免責事項 ガバメントクラウドに関するお問い合わせ 統合運用管理補助者が必要になる場合と担当する事業者について 統合運用管理補助者は、基本的には単独利用方式のアプリケーションが存在し、その上で自治体様に統合運用管理をしたいという意志がある場合に設置されます。全業務のアプリケーションが共同利用方式のみで完結する場合は不要になることが多いと思われます。 また、ネットワーク構築運用補助者がガバメントクラウド全体の運用管理補助業務を担える場合、ネットワーク構築運用補助者が統合運用管理補助業務を兼任することが想定されています。これは、ネットワーク構築運用補助者はもともとガバメントクラウド全体のネットワークを管理することが求められているため、セキュリティについての管理も兼任しやすいからです。 そうでない場合は、いずれかの単独利用運用管理補助者が統合運用管理補助者としてガバメントクラウド全体の運用管理補助業務を担当します。 統合運用管理補助者の役割範囲 統合運用管理補助者の役割範囲は主にインフラストラクチャレイヤーのセキュリティ面での運用管理を行うことです。あくまで参考ですが、例として以下のような業務が存在します。 ガバメントクラウド必須適用テンプレートなどの適用 AWS Config の構成情報を集約して監視、構成管理を行う AWS CloudTrail のログを集約して監視 Amazon Inspector , AWS Security Hub , Amazon GuardDuty などのセキュリティサービスの情報を集約して監視 以上のサービスで不審な動きが確認されたりアラートが発報された場合の対応 必要に応じて、情報が集約されたダッシュボードの作成 必要に応じて、 運用管理補助者兼 ASP 事業者へのガバメントクラウドの使い方の研修や、自治体との情報連携など Amazon CloudWatch などで確認できるアプリケーションレイヤーでのログやアラートの監視は、個々の運用管理補助者が行うことを想定しています。 マルチアカウントの場合の情報の集約方法 複数の AWS アカウントのセキュリティサービスなどの情報を集約するには、 AWS Organizations の機能を使うことが一般的です。しかし、ガバメントクラウドの個別領域はデジタル庁所有の AWS Organizations のメンバーアカウントなので、複数の個別領域の情報を集約するために AWS Organizations の機能を個別に適用できません。複数のアカウントの状況を把握するために、いちいち個別のアカウントから確認するのは大変です。 そのため、AWS Organizations の機能に頼らず情報を集約することが必要です。主に 2 とおりの方法が考えられます。 それぞれのサービスで設定し、個別のサービスにおいて結果を集約する さまざまなサービスの結果を Amazon Simple Storage Service (Amazon S3) にエクスポートし、 SIEM on Amazon OpenSearch Service (SIEM on AWS) を利用する (1) それぞれのサービスにおいて設定する場合 統合管理したいアカウント数が比較的少ない場合、または Amazon OpenSearch Service の費用など SIEM on AWS の利用に必要な費用や実装・運用コストを払いたくない場合は、それぞれのサービスにおいて個別に設定することで AWS の機能を用いて情報を集約できます。 AWS Config では、Config Aggregator を用いることで AWS Organizations に制約を受けず情報を集約可能です。詳しくは、 ドキュメント をご参照ください。 AWS CloudTrail では、Amazon CloudWatch に証跡を送信でき、Amazon CloudWatch Cross Account Observabillity を有効にすることで集約元のすべての CloudWatch ログを集約先アカウントから見られるようになります。詳しくは、 ドキュメント をご参照ください。 Amazon Inspector においては、上記のような自動集約機能がないため、Amazon S3 エクスポート機能を定期的にトリガーするなどして情報を集約する必要があります。詳しくは、 ドキュメント をご参照ください。 AWS Security Hub においては、 こちら の CloudFormation テンプレートなどを用いて結果を Amazon S3 に保存し、それをアカウント間でコピーして情報を集約する必要があります。 Amazon GuardDuty においては、個別に招待することで複数アカウントの検出結果を集約できます。詳しくは、 ドキュメント をご参照ください。 Amazon Detective では、メンバーアカウントを追加することで Organizations に制約を受けず情報を集約可能です。詳しくは、 ドキュメント をご参照ください。 詳しくは、2023 年 12 月 13 日に開催された ウェビナー でもご紹介いたしました。その際の資料や動画は こちら にございますので、ぜひご確認ください。 (2) SIEM on AWS を利用する場合 統合管理したいアカウント数が比較的多く、Amazon OpenSearch Service の費用などを払うことができ、 AWS Cloud Development Kit (AWS CDK) でのデプロイに親しみがある場合、 SIEM on Amazon OpenSearch Service (SIEM on AWS) を活用することが考えられます。 SIEM on AWS は、セキュリティインシデントを調査するためのソリューションです。Amazon OpenSearch Service を活用して、AWS のマルチアカウント環境下で、複数種類のログを収集し、ログの相関分析や可視化できます。デプロイは、 AWS CloudFormation または AWS CDK で行い、30 分程度でデプロイは終わります。AWS サービスのログを Amazon S3 のバケットに PUT すると、自動的に ETL 処理を行い、SIEM に取り込まれます。ログを取り込んだ後は、ダッシュボードによる可視化や、複数ログの相関分析ができるようになります。 各アカウントのセキュリティサービスから Amazon S3 のバケットに PUT する方法も SIEM on AWS のドキュメント に記載してありますので、ご参照ください。 アラートが上がったときの対応について 統合運用管理補助者が確認すべきアラートとして、以下のようなものがあります。 セキュリティインシデントのアラート (AWS Security Hub, Amazon GuardDuty など) AWS サービス障害情報のアラート ( AWS Personal Health Dashboard など) 一方で、ASP/運用管理補助者が確認すべきアラートとして、以下のようなものがあります。 AWS サービスの CloudWatch メトリクスに関するアラート (CPU 使用率等) アプリケーションのログにひもづくアラート (CloudWatch Logs で確認できるもの) アラートが上がった場合に行う作業の例として、以下のようなものがあります。 原因調査などを実施する 各個別領域の運用管理補助者や ASP と協力し、解決する 必要に応じて自治体に情報連携する 原因調査には、AWS のサービスを利用できます。 Amazon GuardDuty と AWS Security Hub については、「Amazon GuardDuty と AWS Security Hub 利用時のオペレーションガイド」を こちら からダウンロードできます (3 つの資料が連結されており、一番下の資料です) 。 Amazon CloudWatch については、 こちら から初心者向けのハンズオンを体験できます。併せてご覧ください。 障害の発生時に行う作業の例として、以下のようなものがあります。 すみやかに自治体に障害発生状況や復旧の状況などを通知する 原因調査などを実施する 各個別領域の運用管理補助者や ASP と協力し、解決する 必要に応じて、 CSP に連絡する まとめ このブログでは統合運用管理補助者となる事業者様向けに統合運用管理補助者の役割範囲や作業内容についてご説明いたしました。ガバメントクラウドではガバメントクラウド固有の事情や制約などが発生し、初めて触れる事業者様には難しいものとなっているかと思います。そんな中、統合運用管理補助者の作業内容を理解し、複数のガバメントクラウド個別領域全体を安全に運用管理していくためにこのブログをお役立ていただけると大変うれしく思います。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害などの責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 上記ご了承のうえ、ご利用ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介したタスクリストに関するお問い合わせの他、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

この記事は、 Provision and manage ML environments with Amazon SageMaker Canvas using AWS CDK and AWS Service Catalog を翻訳したものです。 機械学習 (ML) は、あらゆる業界でさまざまなユースケースで普及しつつあります。一方で、MLの需要と普及のペースが早いため、技術的ソリューションを導入する実務者の確保が追いつかず、ビジネス上の成果を実現することが難しくなっています。 今日の企業では、機械学習自体の実務者ではないがデータに対する知見が深い人材が多く、そのような人材が機械学習を有効に活用することが求められています。コーディング不要の機械学習プラットフォームを使うことで、企業全体の機械学習の価値を実現することができます。これらのプラットフォームにより、たとえばビジネスアナリストなど、さまざまなペルソナが 1 行もコードを書かなくても ML を使用し、ビジネス上の問題の解決策を迅速、簡単、直感的な方法で提供することができます。 Amazon SageMaker Canvas は、ビジネスアナリストが ML を使用してビジネス上の問題を解決できるようにする視覚的なポイントアンドクリックサービスです。ML の経験がなくても使えますし、コードを 1 行も記述する必要もありません。Canvasは、企業がソリューションを迅速に実装するのに役立つ、使いやすく直感的なインターフェイスにより、企業における機械学習の利用を拡大しました。 Canvasは機械学習の民主化を可能にしました。一方、Canvasで機械学習の環境を安全にプロビジョニング（訳者注：環境を設定し、立ち上げて準備すること）して利用者に展開するという課題は依然として残っています。この課題に関わる業務は、ほとんどの大企業では基幹部門のITチームの管轄です。この投稿では、課題を解決するためにIT チームが Amazon SageMaker Canvas 、 AWS Cloud Development Kit (AWS CDK)、および AWS Service Catalog を使用して安全な ML 環境をプロビジョニング、管理する方法について説明します。また、IT 管理者がこれを迅速かつ大規模に実現するためのステップバイステップガイドを紹介します。 AWS CDKとAWS Service Catalogの概要 AWS CDK は、クラウドアプリケーションリソースを定義するオープンソースのソフトウェア開発フレームワークです。プログラミング言語の親しみやすさと表現力を利用してアプリケーションをモデル化し、リソースを安全かつ反復可能な方法でプロビジョニングします。 AWS Service Catalog では、デプロイされた IT サービス、アプリケーション、リソース、メタデータを一元管理できます。AWS Service Catalog を使用すると、Infrastructure as Code 、(IaC) テンプレートを使用してクラウドリソースを作成、共有、整理、管理でき、迅速かつ簡単なプロビジョニングが可能になります。 ソリューションの概要 次の3つのステップに沿ってCanvasを使ったML環境をプロビジョニングします。 AWS Service Catalogを使用して、ユーザーにCanvasの使用を承認し払い出すために、必要なリソースや作業をポートフォリオの形で管理する方法について説明します。 次に、1で説明したAWS Service Catalogのポートフォリオを管理者が使用可能にするために、AWS CDKを用いてデプロイについて説明します。 最後に、実際にCanvasの環境をユーザの要望に応じて数分以内にプロビジョニングし、ユーザに払い出す方法を示します。 事前準備 Canvas、AWS CDK、および AWS Service Catalogを使用して ML 環境をプロビジョニングするために、あらかじめ以下を実行しておいてください。 Service Catalogポートフォリオがデプロイされる AWS アカウントにアクセスできること。AWS CDK スタックをアカウントにデプロイするための認証情報と権限があることを確認してください。 AWS CDK ワークショップ は、サポートが必要な場合に参照できる便利なリソースです。 以下のリソースで詳しく説明されているベストプラクティスに従うことをお勧めします。 Building secure machine learning environments with Amazon SageMaker Setting up secure, well-governed machine learning environments on AWS この GitHub リポジトリ を実行環境にクローンします。 AWS Service Catalogを使用して Amazon SageMaker Canvas 用に承認された ML 環境をプロビジョニングする 規制の厳しい業界やほとんどの大企業では、機械学習環境のプロビジョニングと管理について、ITチームが要求する要件を順守する必要があります。例えば、安全なプライベートネットワーク、データ暗号化、 AWS Identity and Access Management (IAM) などの権限のある認証されたユーザーのみに Canvas などのソリューションへのアクセスを許可するコントロール、監査目的の厳密なロギングとモニタリングが含まれます。 IT 管理者は、AWS Service Catalog を使用して、SageMaker Canvas のための安全で再現可能な ML 環境を作成し、製品ポートフォリオとしてまとめることができます。これは、前述の要件を満たすように組み込まれた IaC (Infrastructure as Code) コントロールを使用して管理され、必要な時に数分以内にプロビジョニングできます。また、このポートフォリオにアクセスできるユーザーを管理することもできます。 次の図は、このソリューションのアーキテクチャを示しています。 サンプルの流れ このセクションでは、SageMaker Canvas の使用のためのAWS Service Catalogポートフォリオの例を紹介します。このポートフォリオは、Canvas 環境を構成し安全に使用するためのさまざまな側面（概念や機能）で構成されています。 Studio ドメイン — Canvas は SageMaker Studio ドメイン内で実行されるアプリケーションです。ドメインは、 Amazon Elastic File System (Amazon EFS) ボリューム、認証されたユーザープロファイルリスト、およびさまざまなセキュリティ、アプリケーション、ポリシー、および Amazon Virtual Private Cloud (VPC) 設定で構成されます。AWS アカウントは、リージョンごとに 1 つのドメインにリンクされます。 Amazon S3 バケット — Studio ドメインが作成されると、 Amazon Simple Storage Service (Amazon S3) バケットが Canvas 用にプロビジョニングされ、ローカルファイルからのデータセットのインポート (ローカルファイルアップロードとも呼ばれます) が可能になります。このバケットはお客様のアカウントにあり、初回に一度だけプロビジョニングされます。 Canvas ユーザー — SageMaker Canvas では、Studio ドメイン内にCanvas ユーザーごとにユーザープロファイルを追加できます。Canvas ユーザーは、データセットのインポート、コードを書かずに ML モデルの構築とトレーニング、モデルに対する予測の実行を行うことができます。 スケジュールされたCanvasセッションのシャットダウン — Canvasユーザーは、タスクが完了したらCanvasインターフェースからログアウトできます。または、管理者は Canvas セッションの管理の一環として AWS マネジメントコンソール から各ユーザーの&nbsp; Canvas セッションをシャットダウンする こともできます。AWS Service Catalog ポートフォリオのこの部分では、スケジュールされた間隔で Canvas セッションを自動的にシャットダウンするように AWS Lambda 関数 が作成およびプロビジョニングされます。これにより、開いているセッションを管理し、使用していないときはシャットダウンできます。 このサンプルフローは GitHub リポジトリ にあり、簡単に参照できます。 AWS CDK を使用してフローをデプロイする このセクションでは、AWS CDK を使用して前述のフローをデプロイします。デプロイ後は、バージョントラッキングやポートフォリオの管理も行えます。 ポートフォリオスタックはリポジトリ内の app.py にあり、製品スタックは products/ フォルダーにあります。 studio_constructs/ フォルダ内の IAM ロール、 AWS Key Management Service (AWS KMS) キー、VPC セットアップを繰り返し実行することができます。スタックをアカウントにデプロイする前に、 app.py の以下の行を編集して、ポートフォリオにアクセスするためのIAM ロールを指定しておきます。 管理者はポートフォリオにアクセスできる IAM ユーザー、グループ、ロールを管理できます。詳細については、 ユーザーへのアクセス権の付与 を参照してください。 ポートフォリオをアカウントにデプロイ リポジトリ内で次のコマンドを実行して AWS CDK をインストールし、ポートフォリオをデプロイするための適切な依存関係ライブラリを事前にインストールします。 npm install -g aws-cdk@2.27.0 python3 -m venv .venv source .venv/bin/activate pip3 install -r requirements.txt アカウントにポートフォリオをデプロイするために以下のコマンドを実行します ACCOUNT_ID=$(aws sts get-caller-identity --query Account | tr -d '"') AWS_REGION=$(aws configure get region) cdk bootstrap aws://${ACCOUNT_ID}/${AWS_REGION} cdk deploy --require-approval never 最初の 2 つのコマンドは、コンピュータの AWS Command Line Interface (AWS CLI) を使用してアカウント ID と現在のリージョンを取得します。これに続いて、cdk bootstrap と cdk deploy はアセットをローカルにビルドしてから、数分でスタックをデプロイします。 AWS CloudFormationのコンソール画面からスタックを確認すると、このソリューションのスタックが作成されています。 また、次のスクリーンショットに示すように、ポートフォリオは AWS Service Catalog コンソール上の製品 (Products)メニューで見つかるようになります。 オンデマンドプロビジョニング ポートフォリオ内の製品は、AWS Service Catalog コンソールの プロビジョン メニューからオンデマンドですばやく簡単に起動できます。今回の場合、”Studio Domain”と “Canvas Auto Shutdown”を最初に起動します。これらはすべてのユーザーに対して有効であり、初回限りのアクションだからです。その後、”Canvas User”を起動して各ユーザーに対応するStudioユーザープロファイルをドメインに追加します。ユーザープロファイルの作成時にはドメイン ID と IAM ロール ARN の情報が必要ですが、これらの情報は スタック作成時にAWS Systems Manager に保存されており、次のスクリーンショットに示すようにユーザーパラメータが自動的に入力されるようになっています。 また、各ユーザーにコスト配分タグ（”UserCostCenter”）を使用することができます。 UserNameはSageMaker Studioドメインに追加されるユーザプロファイル名です。実際のユーザーが識別しやすい名前をつけると良いでしょう。 Canvas を使用して ML 環境を管理する際の主な考慮事項 ここまでの説明で、ユーザーにCanvasの環境を払い出すためのAWS Service Catalog ポートフォリオのプロビジョニングとデプロイが完了しました。ここからは、さらなる検討事項としてドメインとユーザープロファイルについて深掘りします。 Canvas ベースの ML 環境を管理するうえで他に考慮すべき点をいくつかリストアップします。 Studio ドメインに関する考慮事項は次のとおりです。 CanvasのネットワークはStudioドメインレベルで管理され、ドメインはセキュアな接続のためにプライベートVPCサブネットにデプロイされます。より詳細な設定を行いたい場合については、「 プライベート VPC を使用した Amazon SageMaker Studio 接続の保護 」を参照してください。 ユーザープロファイルのデフォルトの IAM 実行ロールはドメインレベルで定義されます。このデフォルトロールは、ドメイン内のすべてのCanvasユーザーに割り当てられます。（訳者注：Studioドメイン用のIAMロールとユーザプロファイル用のIAMロールの2種類がありますが、このサンプルでは二つに同じIAMロールを割り当てています） 暗号化は AWS KMS を使用してドメイン内の EFS ボリュームを暗号化することによって行われます。その他のコントロールとして、カスタマーマネージドキー (CMK) と呼ばれる独自のマネージドキーを指定することもできます。詳細については、「 暗号化による保存中のデータの保護 」を参照してください。 ローカルディスクからファイルをアップロードするには、Canvas が使用する S3 バケットにクロスオリジンリソース共有 (CORS) ポリシーをアタッチします。詳細については、「 ローカルファイルをアップロードする権限をユーザーに与える 」を参照してください。（訳者注：Canvasのアップデートにより、ドメイン作成時にデフォルトでCORS設定が有効化され、設定の手間がなくなりました。設定を無効化したい場合や、何らかの理由で無効化されている設定を有効化したい場合に上記リンクを参照してください） ユーザープロファイルに関する考慮事項は次のとおりです。 Studioでの認証は、シングルサインオン (SSO) とIAMの両方で行うことができます。また、コンソールにアクセスするユーザーをフェデレーションする既存のIDプロバイダーがある場合は、IAMを使用して各フェデレーションIDにStudioユーザープロファイルを割り当てることができます。これら3つの方式の詳細については、「チームやグループでAmazon SageMaker Studioを使用するための完全なリソース分離の設定方法」の Studio ユーザーへのポリシーの割り当て セクションを参照してください。 （訳者注：このサンプルでは同じIAMロールを使用していますが）各ユーザープロファイルに別々のIAMロールを割り当てることができます。Studioを使用している間、ユーザーは、ユーザープロファイルに割り当てられたロールを引き受けて (すなわちassume roleを用いて) 使用します。ユーザープロファイルごとに適切なIAMロールを設定することで、チーム内やユーザー間のきめ細かなアクセス制御を行うことができます。 属性ベースのアクセス制御 (ABAC) を使用してリソースを分離し、ユーザーがチームのリソースにのみアクセスできるようにすることができます。詳細については、「チームやグループでAmazon SageMaker Studioを使用するための完全なリソース分離の設定方法」を参照してください。 コスト配分タグ ( UserCostCenter )をユーザープロファイルに適用することで、きめ細かなコスト追跡を実行できます。 クリーンアップ 上記の AWS CDK スタックによって作成されたリソースをクリーンアップするには、AWS CloudFormation スタックのページに移動して 作成したCanvas スタックを削除します。もしくは、 git clone したリポジトリフォルダ内から cdk destroy を実行して同じ操作を行うこともできます。 結論 この投稿では、AWS Service Catalogと AWS CDK を使用して、Canvas で ML 環境をすばやく簡単にプロビジョニングする方法について説明しました。AWS Service Catalog でポートフォリオを作成し、ポートフォリオをプロビジョニングしてアカウントにデプロイする一連の流れをサンプルで体験しました。IT管理者はこの方法を使用して、Canvasをプロビジョニングしながらユーザー、セッション、および関連コストをデプロイおよび管理できます。 Canvas の詳細については、 製品ページ と 開発者ガイド をご覧ください。さらに読むには、 ビジネスアナリストがコンソールなしで AWS SSO を使用して SageMaker Canvas にアクセスできるようにする方法 (enable business analysts to access SageMaker Canvas using AWS SSO without the console) をご覧ください。また、 ビジネスアナリストとデータサイエンティストがCanvasとStudioを使用してより迅速にコラボレーションする方法 (business analysts and data scientists can collaborate faster using Canvas and Studio) についても学ぶことができます。

AWS は、2023 年 11 月 15 日 ( 水 ) 〜 2023 年 11 月 17 日 ( 金 ) にわたって幕張メッセで開催された Inter BEE 2023 に出展しました。 AWS ブース内プレゼンテーションステージでは、5 つのステージスペシャルセッションでのお客様事例、8 つのスポンサーと AWS から展示のハイライトをお届けしました。本ブログでは、 5 つのステージスペシャルセッションをご紹介させていただきます。 スペシャルセッションの内容&nbsp; (セッション提供順)： 株式会社スタジオブロス : バーチャルプロダクションにおけるAWS活用 – 事例と可能性 アマゾンウェブサービスジャパン合同会社 : Create. Deliver. Monetize. Trends &amp; Customer stories in the M&amp;E Industry 株式会社 TBS テレビ / 株式会社TBSアクト/&nbsp; ソニーマーケティング株式会社&nbsp;: 目指せ！収録⇒編集⇒アーカイブまで素材一元管理 TBSテレビコンテンツ制作局のこれまでの取り組み 株式会社 AbemaTV : ABEMA ライブイベント配信におけるパーソナライズ広告挿入について メモリーテック株式会社 / 株式会社クープ / Dolby Japan 株式会社 :&nbsp; NeSTREAM LIVE AWS を活用した DOLBY ATMOS での高臨場感ライブ配信事例の紹介 ※なお、本セミナーの収録には、ライブエンコーダー AWS Elemental Link UHD と株式会社トラフィック・シム社のクラウド同録ソリューション、 RecShare CLOUD を利用しました。 バーチャルプロダクションにおけるAWS活用 – 事例と可能性 株式会社スタジオブロス IT 開発部 部長 上津原 一利 様 バーチャルプロダクションの制作、確認、撮影など、様々なシーンでクラウド活用することによって各作業を効率的に進めることができます。スタジオブロス様で実際に行ったクラウド活用の事例や、活用によって広がる可能性などお伝えいただきました。 資料のダウンロードは こちら Create. Deliver. Monetize. Trends &amp; Customer stories in the M&amp;E Industry アマゾン ウェブ サービス ジャパン合同会社 Principal M&amp;E Partner Lead, APJ Shad Hashmi アマゾン ウェブ サービス ジャパン合同会社 AWS インダストリー事業開発マネージャー 山口 賢人 Create. Deliver. Monetize.の視点から、海外のメディア&amp;エンターテインメント業界のトレンドとお客様事例を紹介しました。 資料のダウンロードは こちら 目指せ！収録⇒編集⇒アーカイブまで素材一元管理 TBSテレビコンテンツ制作局のこれまでの取り組み 株式会社 TBS テレビ コンテンツ制作局 担当局次長 吉橋 隆雄 様 株式会社 TBS テレビ コンテンツ制作局 バラエティ制作三部 部長代理 樋江井 彰敏 様 株式会社TBSアクト　メディアサポート部　副部長 加藤 孝祐 様 ソニーマーケティング株式会社 前田 勇馬 様 ソニーマーケティング株式会社 小林 要介 様 大量の過去の収録テープ素材を前にした放送局の制作部門スタッフが「円滑に過去素材を再利用できる環境の構築」と「働き方改革にともなう諸業務の効率化」を目的に、社内各部署を巻き込んで説得し、映像のデータ化⇒クラウド化⇒クラウドオフライン編集に挑戦するまでの道のりと今後の課題と展望について、関係者一同と共にお話いただきました。 資料のダウンロードは こちら ABEMA ライブイベント配信におけるパーソナライズ広告挿入について 株式会社AbemaTV ビジネスディベロップメント本部 エンジニア 古川 俊太 様 ABEMA ではスポーツなどの試合に対応できるように新しく「ライブイベント」という放送形態を導入されました。ライブイベントという放送形態を新規で導入したことにより、広告の配信システムも新規で開発する必要がありました。今回、AWS MediaTailor をパーソナライズ基盤として選定いただきましたが、その経緯と現状、展望についてお話しいただきました。 資料のダウンロードは こちら NeSTREAM LIVE AWS を活用した DOLBY ATMOS での高臨場感ライブ配信事例の紹介 メモリーテック株式会社 デジタルソリューション事業本部 本部長 棟元 裕介 様 株式会社クープ テクニカル営業グループ シニア・スーパーバイザー 近藤 貴春 様 Dolby Japan 株式会社 技術部 シニア・テクニカル・マネージャー 萩谷 太郎 様 近年、音楽ライブにおいて、ドルビーアトモスでの劇場上映や、パッケージ販売・配信する事例が増えています。これまでの制作事例を踏まえ、今後増えていくことが予想されるドルビーアトモスでライブ配信の仕組みなどについてご紹介いただきました。 資料のダウンロードは こちら 終わりに 今回は、Inter BEE 2023 の AWS セミナーの概要を紹介しました。 AWS 展示の概要については こちら AWS スポンサー展示の概要については こちら AWS 出展者セミナーの概要については こちら を参照ください。 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog　(日本語) AWS Media &amp; Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 本ブログは BD 山口が担当しました。

2023 年 11 月と 12 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon CloudWatch Evidently Amazon CloudWatch Evidently は CloudWatch における Application Monitoring サービスの一つです。 Amazon CloudWatch Evidently を利用することで、より安全にローンチを行え、また、簡単に A/B テストを実施できます。 この AWS Black Belt Online Seminar では Amazon CloudWatch Evidently のメリットや機能について詳しく説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 機能フラグを使い、一部のユーザーのみ新機能を利用できるようにすることで、安全にローンチしたい方 A/B テストを実施し、より効果的な機能を定量的に判断したい方 本 BlackBelt で学習できること 本 BlackBelt では Amazon CloudWatch Evidently のメリットについて学べます。 また、Amazon CloudWatch Evidently を利用したダークローンチ や A/B テストの実施方法ついて学べます。 スピーカー 日平大樹 テクニカルアカウントマネージャー AWS SAW – セルフサービスな診断と運用の効率化 入門編 AWS SAW(AWS Support Automation Workflows) は AWS サポートエンジニアリングチームが作成した安全で高速なセルフサービス自動化を使用して、AWS 環境の一般的な問題を解決やログの収集、分析などを行います。 AWS SAW の仕組み、どのようなことができるか、どのようなシチュエーションで役立つかといった点について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 自分の AWS 環境のトラブルシューティング経験のある方 運用、トラブルシューティングをより効率化したい方 本 BlackBelt で学習できること AWS SAW がどのようなものであるか、その使用方法や探し方を学習できます。 スピーカー 高橋尚久 シニアクラウドサポートエンジニア AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Container Service(Amazon ECS) 編 AWS SAW(AWS Support Automation Workflows) は AWS サポートエンジニアリングチームが作成した安全で高速なセルフサービス自動化を使用して、AWS 環境の一般的な問題を解決やログの収集、分析などを行います。本セッションでは Amazon Elastic Container Service(Amazon ECS) で利用可能な 3 つの SAW について概要や利用ユースケースなどの詳細を解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon ECS を利用した運用を実施されている方 Amazon ECS のトラブルシューティングの効率化に興味のある方 本 BlackBelt で学習できること Amazon ECS 向けに利用可能な 3 つの AWS Support Automation Workflows(SAW) について利用ユースケース及び概要を解説します スピーカー 古野俊広 クラウドサポートエンジニア AWS SAW – セルフサービス自動化ランブックを使用したトラフィック監視の視覚化 Amazon Virtual Private Cloud (Amazon VPC) 編 AWS SAW (AWS Support Automation Workflows) は、AWS サポートエンジニアリングチームが作成した、AWS Systems Manager セルフサービス自動化ランブックのコレクションです。本セミナーでは、Amazon VPC からのトラフィックにおける、情報の取得に有効な 3つのランブックについて、概要やユースケースなどの詳細を解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 VPC から通信先サーバーまでの疎通監視をご検討されている方 VPC でトラフィックに関するログの取得をご検討されている方 本 BlackBelt で学習できること 「AWSSupport-SetupIPMonitoringFromVPC」ランブックの設定方法と活用方法 「AWSSupport-EnableVPCFlowLogs」ランブックの設定方法 「AWSSupport-ConfigureTrafficMirroring」ランブックの設定方法 スピーカー 中村佑希 クラウドサポートエンジニア AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Kubernetes Service(Amazon EKS) 編 AWS SAW(AWS Support Automation Workflows) は AWS サポートエンジニアリングチームが作成した安全で高速なセルフサービス自動化を使用して、AWS 環境の一般的な問題を解決やログの収集、分析などを行います。本セッションでは Amazon Elastic Kubernetes Service(Amazon EKS) で利用可能な 3 つの SAW について概要や利用ユースケースなどの詳細を解説します。 資料（ PDF ）&nbsp; | 動画（ YouTube ） 対象者 Amazon EKS を利用した運用を実施されている方 Amazon EKS のトラブルシューティングの効率化に興味のある方 本 BlackBelt で学習できること Amazon EKS 向けに利用可能な 3 つの SAW(AWS Support Automation Workflows) について利用ユースケースおよび概要を理解することができます。 スピーカー 坂元 龍太 クラウドサポートエンジニア AWS Cost and Usage Reports AWS Cost and Usage Reports (AWS CUR) はコスト可視化が可能なサービスの一つで、お客様の AWS の利用状況とご利用料金情報を提供する最も細かく最も包括的なレポートです。本セッションでは、AWS CUR の概要や分析・可視化方法 についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS Cost and Usage Reports (AWS CUR) をもっと使いこなしたい方、これから使ってみたい方 本 BlackBelt で学習できること AWS Cost and Usage Reports (AWS CUR) の概要や各項目内容、および分析・可視化方法を理解することができます。 スピーカー 石王　愛 テクニカルアカウントマネージャー AWS Certificate Manager AWS Certificate Manager について解説をさせていただきます。 どのように使うとメリットを享受していただけるのかを昨今のセキュリティの状況と共に解説させていただきます。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから AWS Certificate Manager (ACM) をご利用されたい、もしくは理解を深めたい SSL/TLS サーバ証明書管理、その運用にに興味・関心がある Web サーバの SSL/TLS による暗号化の仕組みについて理解されている 本 BlackBelt で学習できること 本 BlackBelt では AWS Certificate Manager についてご紹介します。 AWS Certificate Manager と使うメリットを、どのように使うとメリットを享受していただけるのかと共にご説明いたします。 スピーカー 長谷 有沙 ソリューションアーキテクト Amazon Pinpoint 再入門 マルチチャネルコミュニケーションサービス Amazon Pinpoint は、メッセージの配信・管理・最適化のためのマルチチャネルコミュニケーションサービスです。 本セッションは組織における顧客とのコミュニケーションの課題にフォーカスし、技術的なアプローチによる解決方法として Amazon Pinpoint で実現可能なことやユースケースをご紹介した上で、設定の構成要素について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Pinpoint で出来ることを具体的に知りたい方 顧客への情報配信ソリューションの情報収集をされている方 本 BlackBelt で学習できること Amazon Pinpoint のサービス全体像と設定の概要を把握できます Amazon Pinpoint を使った顧客へのアプローチ方法のイメージを掴んでいただけます スピーカー 清水幸典 Amazon Connect スペシャリスト ソリューションアーキテクト Amazon DataZone Overview Amazon DataZone は、AWS、オンプレミス、およびサードパーティのソース全体に保存されているデータを迅速かつ簡単にカタログ化、発見、共有、管理できるようにするデータ管理サービスです。本セッションでは、Amazon DataZone について詳しく解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon DataZone をご利用予定の方、ご利用されている方。 Amazon DataZone について学びたい方。 データ活用を促進していくことに関心がある方。 本 BlackBelt で学習できること Amazon DataZone の各コンポーネントの役割と、ガバナンスとアクセスコントールや認証認可の仕組み、実際の操作デモについて学ぶことができます。 スピーカー 平井 健治 ソリューションアーキテクト Karpenter Basic Kubernetes 環境で利用可能なオープンソースのノードプロビジョニングツールである Karpenter の概要や使い方をご紹介します。Karpenter が解決する課題や機能概要を知ることができるため、ご自身が管理するワークロードに対して Karpenter が有用なものとなるか参考にしていただけます。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS 上で Kubernetes を利用している方、もしくは利用を検討している方 Kubernetes 上の ノードグループの管理が複雑と感じている方 Karpenter について基本を学びたい方 本 BlackBelt で学習できること Karpenter が解決する課題 Karpenter の概要 Karpenter の使い方 スピーカー 多田 慎也 ソリューションアーキテクト 移行戦略 (7R) の概要 本セッションでは、AWS の移行戦略 (7R) について説明します。 システムをどのように移行させるかといった方針のことを移行戦略といい、AWS では 頭文字がRで始まる7つのパターンを提唱しています。 移行戦略 (7R) について種類と特徴を解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 オンプレミスから AWS への移行プロジェクトを担当される方 移行支援を外部の会社に依頼する場合の発注者側担当者 本 BlackBelt で学習できること 移行プロジェクトの全体像 移行戦略 (7R) の種類やメリット/デメリット スピーカー 杉山 大夢 テクニカルインストラクター Amazon CodeCatalyst Spaces 編 Amazon CodeCatalyst は、アプリケーションの開発、ビルド、デプロイ、およびテストを簡単かつ迅速に行うための「統合ソフトウェア開発サービス」です。Spaces 編では、CodeCatalyst において部署やグループなどの組織を表現する Space について解説します。 資料（ PDF ）&nbsp; 対象者 チーム開発をするすべてのアプリケーション開発者 Space の全体像を把握されたい方 AWS アカウントの管理者 本 BlackBelt で学習できること Space の概要と作成方法 Space におけるメンバー管理 AWS アカウントや IAM ロールの管理 スピーカー 柳久保 友貴 ソリューションアーキテクト Amazon CodeCatalyst Projects, Blueprints 編 Amazon CodeCatalyst は、アプリケーションの開発、ビルド、デプロイ、およびテストを簡単かつ迅速に行うための「統合ソフトウェア開発サービス」です。Projects, Blueprints 編では、CodeCatalyst における Project とそのテンプレートである Blueprint について解説します。 資料（ PDF ）&nbsp; 対象者 チーム開発をするすべてのアプリケーション開発者 Project の全体像を把握されたい⽅ Blueprint を⽤いて効率よく Project を作成/管理したい⽅ 本 BlackBelt で学習できること Project, Blueprint の概要と作成方法 Project のメンバー管理 Custom Blueprint の作成と更新方法 スピーカー 堀 ⻯慈 ソリューションアーキテクト Amazon CodeCatalyst Source repositories 編 Amazon CodeCatalyst は、アプリケーションの開発、ビルド、デプロイ、およびテストを簡単かつ迅速に行うための「統合ソフトウェア開発サービス」です。Source repositories 編では、CodeCatalyst 内で提供されるマネージドな Git 互換ソース管理機能について解説します。 資料（ PDF ）&nbsp; 対象者 チーム開発をするすべてのアプリケーション開発者 本 BlackBelt で学習できること Source repositories の概要 接続方法・操作方法 Pull Request の作成・レビュー・マージ Branch ルール 通知 スピーカー 国兼 周平 ソリューションアーキテクト Amazon CodeCatalyst Workflow 編 Amazon CodeCatalyst は、アプリケーションの開発、ビルド、デプロイ、およびテストを簡単かつ迅速に行うための「統合ソフトウェア開発サービス」です。Workflow 編では、ビルド・テスト・デプロイのパイプラインを定義・実⾏する機能である Workflow について解説します。 資料（ PDF ） 対象者 チーム開発をするすべてのアプリケーション開発者 CI/CD パイプラインの作成・管理⽅法を知りたい⽅ 本 BlackBelt で学習できること Workflow の全体像・構成要素 Workflow の作成・実行・管理方法 Workflow における Actions のベストプラクティス スピーカー 田中 創一郎 パートナーソリューションアーキテクト Amazon CodeCatalyst Issues 編 Amazon CodeCatalyst は、アプリケーションの開発、ビルド、デプロイ、およびテストを簡単かつ迅速に行うための「統合ソフトウェア開発サービス」です。Issues 編では、開発者のタスクを管理する機能である Issue について解説します。 資料（ PDF ）&nbsp; 対象者 チーム開発をするすべてのアプリケーション開発者 本 BlackBelt で学習できること Issue の概要・作成方法 Issue を起点とした開発フロー Issue の見積もり管理機能 Issue の外部連携機能 スピーカー 江口 昌宏 ソリューションアーキテクト Amazon CodeCatalyst Identity, permissions, and access 編 Amazon CodeCatalyst は、アプリケーションの開発、ビルド、デプロイ、およびテストを簡単かつ迅速に行うための「統合ソフトウェア開発サービス」です。Identity, permissions, and access 編では、CodeCatalyst におけるセキュリティやユーザーおよび権限の管理について解説します。 資料（ PDF ）&nbsp; 対象者 チーム開発をするすべてのアプリケーション開発者 本 BlackBelt で学習できること CodeCatalyst のセキュリティ Space と AWS アカウントの関係・接続 CodeCatalyst のユーザーおよび権限 スピーカー 国兼 周平 ソリューションアーキテクト Amazon CodeCatalyst Extensions 編 Amazon CodeCatalyst は、アプリケーションの開発、ビルド、デプロイ、およびテストを簡単かつ迅速に行うための「統合ソフトウェア開発サービス」です。Extensions 編では、CodeCatalyst の拡張機能について解説します。 資料（ PDF ） 対象者 チーム開発をするすべてのアプリケーション開発者 本 BlackBelt で学習できること Extensions の概要 CodeCatalyst と GitHub の連携 CodeCatalyst と Jira の連携 スピーカー 江口 昌宏 ソリューションアーキテクト Amazon CodeCatalyst Dev Environments 編 Amazon CodeCatalyst は、アプリケーションの開発、ビルド、デプロイ、およびテストを簡単かつ迅速に行うための「統合ソフトウェア開発サービス」です。Dev Environments 編では、クラウドベースの Linux 開発環境である Dev Environments について解説します。 資料（ PDF ）&nbsp; 対象者 チーム開発をするすべてのアプリケーション開発者 チーム開発で、開発環境の依存関係を揃えたい⽅ ブランチごとに独⽴した開発環境を作りたい開発者 クラウドで開発環境を持ちたい開発者 本 BlackBelt で学習できること Dev Environments の概要 Dev Environments の設定とライフサイクル Devfile の定義 Dev Environments と IDE との連携 スピーカー 髙柴 元 ソリューションアーキテクト AWS Systems Manager Quick Setup 編 AWS Systems Manager (SSM) は統合的な AWS 環境を運用するためのツールとして進化しており、多くの機能を持っています。本セッションでは、AWS Systems Manager の数ある機能のうち、 Quick Setup についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS の運用をされている方、これから運用される予定の方 本 BlackBelt で学習できること AWS Systems Manager Quick Setup の概要と設定方法をご理解いただく事ができます。 スピーカー 渡邊 良臣 ソリューションアーキテクト AWS CloudFormation 開発・テスト・デプロイ編 近年、AWS CloudFormation の開発を効率的に進めていただくためのツールが急速に進展しています。従来のベストプラクティスに加え、生成 AI を利用した新しい開発手法も出てきております。本セミナーでは、新機能の紹介も含めた最新の情報を紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS CloudFormation の開発をしようとされている方、すでに実施されている方が対象となります。 AWS の概要を理解していること、AWS CloudFormation の概要を理解していることが前提知識として必要です。 本 BlackBelt で学習できること 本セミナーでは、AWS CloudFormation の開発を進めていただく上での知識、理解を深めていただくことが可能です。 AWS CloudFormation スタックとコード設計の勘所 • 開発環境の整備 • テスト • デプロイについて説明しています。 スピーカー 山川 達也 ソリューションアーキテクト AWS CloudFormation#2 基礎編 AWS CloudFormation は、インフラストラクチャをコードとして扱うことで、AWS およびサードパーティーのリソースをモデル化、プロビジョニング、管理することができます。 本セミナーは、AWS CloudFormation について解説するシリーズの基礎編です。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS CloudFormation をこれから利用される方 AWS CloudFormation の概要をお知りになりたい方 本 BlackBelt で学習できること AWS CloudFormation を利用する上で必要な知識（依存関係、動的参照など）について解説しています。 AWS CloudFormation の基本的な利用方法（ネストされたスタック、スタックセットなど）についてイメージを掴んでいただけます。 スピーカー 上原 優樹 クラウドサポートエンジニア AWS CDK における開発とテスト (Advanced #1) AWS Cloud Development Kit (AWS CDK) のテストの種類や使いわけについて紹介します。 また、その他の開発にまつわる Tips も紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS CDK の実践的な活用方法に興味がある方 AWS CDK を使っている、あるいはこれから学ぶ方 本 BlackBelt で学習できること AWS CDK のテストの種類、使い分け AWS CDK の開発にまつわる Tips スピーカー 工藤 朋哉 Prototyping Engineer 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2024-01 AWS への大規模移行のための戦略とベストプラクティス カスタマーソリューションマネージャー 大熊正浩 2024-01 モダナイゼーションプロジェクト立ち上げのポイント ソリューションアーキテクト 平岩梨果 2024-01 AWS 言語系 AI/ML サービス ソリューションアーキテクト 安藤慎太郎

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 新年明けましておめでとうございます。今年もAWSのアップデートをコンパクトにお知らせすることに注力していきますので、時々チェックしていただけると嬉しいです。どうぞよろしくお願いします。 さて、早速ですがひとつ宣伝です。新年一発目の AWS Builders Online Series が1/18(木)に開催されます。AWSの基礎に加え、生成系AIやモダンアプリケーション開発など注目のトピックを取りそろえています。初心者向けのAWSに関するラーニングイベントという位置づけですが、すでにご利用頂いている方にも新たな発見があると思いますので、是非ご参加ください。 それでは、12 月 25 日と 1 月 1日週のアップデートを振り返ってみましょう。 2023 年 12 月 25 日週と 2024年 1 月 1 日週の主要なアップデート 12/26(火) Amazon Kinesis Data Firehoseがゼロ・バッファリングをサポート Amazon Kinesis Data Firehoseがゼロ・バッファリングに対応し、Amazon S3, Amazon OpenSearch Service, Amazon RedshiftおよびサードパーティのHTTPエンドポイントに対する数秒以内でのデータ転送が可能になりました。リアルタイムに近いデータ転送が必要なケースに対応しやすくなります。 12/27(水) Amazon SageMakerでデバックを目的としたモデルトレーニングコンテナへのアクセスを提供開始 可観測性を高め、素早いデバッグを可能にすることを目的に、Amazon SageMakerのトレーニング環境に対する安全で簡単なリモートアクセスの方法が提供されるようになりました。トレーニングジョブの問題調査や修正がこれまでよりも簡単に実行できるのがポイントです。 Amazon EKSでクラスターに関する健全性の問題を可視化可能に Amazon EKS(Elastic Kubernetes Service)において、クラスターに関する健全性の問題をEKSコンソールまたはAPIを利用して把握できるようになりました。クラスターの健全性に問題がある場合、その理由や解決方法が出力されるようになり、問題解決の助けとして利用できます。 12/28(木) Amazon EKSでIPv6アドレスを利用している場合にもEC2セキュリティグループを適用可能に Amazon EKS(Elastic Kubernetes Service)において、IPv6を利用している場合にもEC2セキュリティグループを提供できるようになりました。IPv6を用いて通信する場合についても、セキュリティグループによる保護を適用することによって、これまでよりも柔軟なアクセス制御を適用できるようになります。 12/29(金) AWS Mainframe Modernization Serviceが大阪リージョンに対応 AWS Mainframe Modernization serviceが大阪リージョンを含む4つのリージョンでご利用いただけるようになりました。 Amazon EMR Release 7.0がリリースされAmazon Linux 2023に対応 Amazon EMR Release 7.0がリリースされ、Amazon Linux 2023とAmazon Corretto Release 17で稼働するApach Spark 3.5がデフォルトで利用されるようになりました。詳細については リリースノート をご確認ください。 1/2(火) Amazon WorkSpacesでWorkSpaces Web Access利用時にも証明書ベースの認証に対応 Amazon WorkSpacesが、WorkSpaces Web Accessを利用してWSPバンドルのWindows環境にアクセスする際に証明書ベースの認証を利用できるようになりました。WorkSpacesのクライアントアプリケーションをインストールすることなく、SAML 2.0 IDプロバイダーのシングルサインオンを介してブラウザで直接WorkSpaces環境にアクセス可能です。 1/4(木) Amazon OpenSearch ServiceがTLS1.3とPFSをサポート Amazon OpenSearch Serviceで、ドメインエンドポイントに対する接続にTLS1.3を利用できるようになりました。またPFS(Perfect Foward Secrecy)がサポートされ、追加の保護を適用することも可能になっています。 AWS Systems ManagerでSSM Agentの自動アップデートが可能に SSM Agentはそれが導入されたEC2インスタンス、オンプレミスのサーバー、IoTデバイスをAWS Systems Managerと接続するためのブリッジとして機能するソフトウェアです。今回AWS Systems ManagerのApplication Managerが、アプリケーションのコンテキストに基づいたSSM Agent(AWS Systems Manager Agent)の自動バージョンアップに対応し、管理対象ノードについてAgentを最新に保つことが容易になりました。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )

みなさんこんにちは！アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクトの高橋です。 2023 年 12 月 21 日に「第三十七回 アップデート紹介とちょっぴり DiveDeep する AWS の時間」をオンラインで開催しました。本イベントは、AWS の数あるアップデートの中から「すぐ使える、運用に役立つ、あったらいいなと思ってた、おもしろい、重要」なものをピックアップし、ちょっぴり DiveDeep してカジュアルな雰囲気でお伝えするイベントです。過去の開催報告は こちら からご確認いただけます。 今回は「 AWS re:Invent 振り返り編 」ということで、AWS re:Invent 2023 で発表された新機能についてデモを交えながらご紹介させていただきました。100 名を超える多くの方々にご参加いただきました。ご参加いただいた皆様、誠にありがとうございました！ 実施内容 AWS のソリューションアーキテクトから、re:Invent 2023 で発表された新サービス・機能に関する 5 つのセッションを 1 時間半でお届けしました。本記事の中に資料や動画のリンクを記載しておりますので、ぜひご活用ください！ 当日参加したメンバー アジェンダ アジェンダ Amazon Q in QuickSight で生成系 AI を用いてダッシュボードをより効果的に活用する方法をご紹介！ (15 分) スピーカー: アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 守田 凜々佳 re:Invent 2023 にて Amazon Q in QuickSight が発表されました。Amazon QuickSight で 7 月に発表されたダッシュボード作成者による Generative BI 機能に加えて、ビジネスユーザーを対象とした新たな３つの機能をプレビューにて提供開始しました。本セッションでは、その３つの新機能 (Executive Summary, Data Q&amp;A, Story) についてデモを交えてご紹介します！ その ETL パイプラインもういらないかも？zero-ETL 総まとめ！ (15 分) スピーカー: アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 深見 修平 今使っているデータストアだけで要件を満たすのが難しくなってきたからデータを他のデータストアに連携したい、でもデータのパイプラインの構築・運用は大変・・・。そんな悩みございませんか？ re:Invent 2023 では、Aurora と Redshift や DynamoDB と OpenSearch といったように、 シームレスなデータ連携を簡単に実現する zero-ETL の機能が多くのサービス間において発表されました。本セッションでは、発表された zero-ETL の総まとめとしてそれぞれの詳細をデモを交えてご紹介します。 Amazon EKS 2023 年 冬のアップデートを振り返ろう 〜 EKS Pod Identity ＆ Mountpoint for Amazon S3 CSI driver 〜 (15 分) スピーカー: アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 後藤 健汰 re:Invent 2023 期間中、Amazon EKS に関わる大きなアップデートがありました。IAM ロールを ServiceAccount に割り当てる仕組みである「EKS Pod Identity」、Kubernetes の永続ボリュームとして S3 のマウントを可能にする「Mountpoint for Amazon S3 CSI driver」です。本セッションでは、これらのアップデートの詳細についてデモを交えてご紹介します。 AWS Fault Injection Service で AZ 障害を体験しよう – データベースの可用性向上対策の検証 (15 分) スピーカー: アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 塚本 真理 AWS Fault Injection Service は障害シナリオを実行できるサービスです。re:Invent 2023 では新たに AZ 障害とリージョン間接続の切断を想定した障害の追加が発表されました。アプリケーションを運用する際に可用性向上のため、マルチ AZ 構成や DR 構成を利用する場合もあるかと思います。用意した構成が障害発生時に正しく動作するのかを AWS Fault Injection Service を使って検証し、デモをお届けします。 生成系 AI × コンプライアンス！エージェントにおすすめの AWS Config マネージドルールを有効化してもらおう (15 分) スピーカー: アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 北川 友稀 RAG を行う機能である Knowledge Bases for Amazon Bedrock とエージェント構築機能である Agents for Amazon Bedrock が re:Invent 2023 で GA となりました。これらの機能を利用して、350 以上ある AWS Config のマネージドルールからおすすめルールの提案と有効化まで Amazon Bedrock に行ってもらいましょう。本セッションでは Amazon Bedrock の概要と GA となった新機能を利用したデモをお届けします。 当日の様子 当日の内容を抜粋してご紹介します！ Amazon Q in QuickSight で生成系 AI を用いてダッシュボードをより効果的に活用する方法をご紹介！ [ 資料 、 動画 ] 最初のセッションでは、ソリューションアーキテクトの守田から Amazon QuickSight の Generative BI 機能についてご紹介しました。QuickSight の Generative BI 機能は、ダッシュボード作成者を対象とした機能とビジネスユーザーを対象とした機能があります。前者では自然言語による指示でダッシュボードや計算フィールドを作成することができ、後者ではダッシュボードのデータから得られる考察を自然言語で要約することができます。デモでは、これらの機能を利用してダッシュボードを作成したりサマリを出力したりする様子をお見せしました。自然言語による指示が曖昧だった場合は指示を具体的にするよう提案する様子もご覧いただけます。 Generative BI 機能は現在プレビュー中かつ英語のみのサポートですが、ダッシュボードの作成にかかる時間を減らしてくれたり、データから考察を得るのを助けてくれる便利なアップデートですので、是非試してみてください！ その ETL パイプラインもういらないかも？zero-ETL 総まとめ！ [ 資料 、 動画 ] 続いてのセッションでは、ソリューションアーキテクトの深見から re:Invent 2023 で発表された zero-ETL 統合に関するアップデートの中から、 Amazon Redshift に関するものをご紹介しました。re:invent 2023 では新たに Amazon Aurora PostgreSQL の Amazon Redshift への zero-ETL 統合など、合計 5 つの zero-ETL 統合のアップデートが発表されました。発表の中では、Aurora MySQL と Aurora PostgreSQL からのデータ連携方法の違いや、Aurora と Amazon RDS からのデータ連携方法の違い等について詳しくご説明しています。デモでは 10,000 件以上の Aurora のデータが数秒で Redshift に同期される様子や、複数のデータソースから Redshift にデータを集約し集計する様子をお見せしました。今後データウェアハウスを使用したデータ分析を検討している皆様や、既存の ETL パイプラインに課題を持っている皆様に是非ご覧いただきたい内容になっています！また、資料の中では Amazon OpenSearch Service に関する zero-ETL 統合のアップデートについてもご紹介していますので、合わせてご確認ください。 Amazon EKS 2023 年 冬のアップデートを振り返ろう 〜 EKS Pod Identity ＆ Mountpoint for Amazon S3 CSI driver 〜 [ 資料 、 動画 ] 3 つ目のセッションでは、ソリューションアーキテクトの後藤から、 Amazon EKS に関するアップデートを 2 つご紹介しました。 EKS Pod Identity は、各 Pod の権限設定を AWS の API のみで完結させることができる機能です。これまでも IAM Roles for Service Accounts (IRSA) で同様の設定ができましたが、Kubernetes と AWS リソースの両方を修正する必要がありました。EKS Pod Identity によって、AWS の API のみで Kubernetes Service Account への IAM ロールの紐付けが完結するので、よりシンプルに Pod の権限を設定できます。また、2 つ目にご紹介した Mountpoint for Amazon S3 CSI driver によって、Kubernetes の Pod が Amazon S3 のオブジェクトに対してファイルシステムのインターフェースを使用してアクセスできます。デモでは、EKS Pod Identity を使用して IAM Role を Kubernetes Service Account に紐づける様子、Mountpoint for Amazon S3 CSI driver を使用して Kubernetes の Pod から S3 のオブジェクトにアクセスできる様子をお見せしました。EKS をご利用のお客様にご覧いただきたい内容となっています！ AWS Fault Injection Service で AZ 障害を体験しよう – データベースの可用性向上対策の検証 [ 資料 、 動画 ] 4 つ目のセッションでは、ソリューションアーキテクトの塚本から、 AWS Fault Injection Service (FIS) を使用したカオスエンジニアリングに関するセッションをお届けしました。FIS は AWS Resillience Hub の中にある機能の 1 つで、レジリエンス実現のための実験を管理するサービスです。re:Invent 2023 では、FIS に 1 つの AZ で完全に電源を喪失した場合を想定したシナリオ「The AZ Availability: Power Interruption」と、リージョン間の接続が切断され他のリージョンにアクセスできない場合を想定したシナリオ「Cross-Region: Connectivity」の 2 つのシナリオが追加された、という発表がありました。デモではマルチ AZ 構成のアプリケーションに対して FIS で AZ の電源障害のシナリオを発生させる設定から発生後の結果まで一気通貫でお見せしました。具体的な設定方法や、シナリオを実行した結果、EC2 インスタンスの停止や DB インスタンスのフェイルオーバーなどの障害が発生している様子をご覧いただけます。障害発生時のシミュレーションがなかなかできていない、オペレーションを実際に試したいと考えている皆様におすすめの内容となっております！ 生成系 AI × コンプライアンス！エージェントにおすすめの AWS Config マネージドルールを有効化してもらおう [ 資料 、 動画 ] この日最後のセッションでは、ソリューションアーキテクトの北川から、re:Invent 2023 で発表された Amazon Bedrock の新機能についてご紹介しました。Knowledge Base for Amazon Bedrock は基盤モデルとデータソースを組み合わせた拡張検索生成(RAG) をフルマネージドに実現するサービス、Agents for Amazon Bedrock は基盤モデルだけで完結しないタスクを実行することを容易にするフルマネージドサービスです。…と言われても、実際どのように活用できるのかイメージが湧かない方が多いのではないでしょうか？本発表のデモでは、これらの新機能を利用しておすすめの AWS Config マネージドルールをエージェントとの会話の中で有効化してもらう、ということを実現しています！Config のマネージドルールは種類が多いため適切なルールを選ぶのが難しいという課題がありますが、この課題をルールの一覧データをデータソースとした RAG によって解決しています。さらにそこから得た情報と指示の内容を Agent が解釈し、事前に定義したアクション ( AWS Lambda 関数) の中から適切なアクションを実行してルールを有効化しています。是非動画を見て Agents for Amazon Bedrock のご利用を検討いただけますと幸いです！ おわりに 今回のちょっぴり DD では、re:Invent 2023 で発表されたアップデートをデモを交えてご紹介させていただきました！ re:Invent 2023 のアップデート情報をキャッチアップしたい皆様には、以下のイベントもおすすめです。 2024 年 1 月 30 日 (火) 〜 2 月 1 日 (木)　 AWS re:Invent Recap – インダストリー編 2024 年 2 月 6 日 (火) 〜 9 日 (金)　 AWS re:Invent Recap – ソリューション編 また、本イベントは今回で一旦休止となります。今後の開催については、決まり次第お知らせします。これまでご視聴いただいた皆様、大変ありがとうございました！