2023年も終わりを迎え、クリスマスまであと 50 日、AWS re:Invent まであと 21 日! ラスベガスにいるなら、私に挨拶しに来てください。私はほとんどの時間、Serverlesspresso のブースにいます。 10月30日週のリリース 10月30日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 Amazon EC2 – Amazon EC2 は ML 向けキャパシティブロックを発表しました。これは、短時間の ML ワークロード用に GPU コンピュートキャパシティを予約できるようになったことを意味します。このリリースについての詳細は、 特集ページ と 発表ブログ記事 をご覧ください。 Finch – Finch の一般公開を開始しました。Finch は、macOS (Intel または Apple Silicon を使用) でローカルコンテナ開発を行うためのオープンソースツールです。macOS 上で Linux コンテナを構築、実行、公開するためのコマンドライン開発者ツールを提供します。Finch についての詳細は、 Phil Estes が書いたこのブログ記事 、または Finch のウェブサイトをご覧ください。 AWS X-Ray – AWS X-Ray が分散トレース用の W3C 形式のトレース ID をサポートしました 。AWS X-Ray は、OpenTelemetry または W3C Trace Context 仕様に準拠するその他のフレームワークを通して生成されたトレース ID をサポートします。 Amazon Translate – Amazon Translate は、翻訳出力の長さを短縮するための簡潔性のカスタマイズを導入しています 。これは、キャプションサイズの制限を満たすために短い翻訳が必要なリアルタイム翻訳で有効にできる新機能です。この翻訳は文字通りのものではありませんが、根本的なメッセージは保たれます。 AWS IAM – IAM は 最後にアクセスしたアクション を 60 のサービスに増やしました 。この機能は、ロールのパーミッションを微調整し、未使用のパーミッションを特定し、ロールが必要とする最小限のパーミッションを付与する場合に非常に便利です。 AWS IAM Access Analyzer – IAM Access Analyzer ポリシージェネレータは、AWS CloudTrail のアクセスアクティビティに基づいてきめ細かいポリシーを作成するために、 200 以上の AWS サービスを識別するためのサポートを拡張しました。 AWS のお知らせの完全なリストについては、 「AWS の最新情報」ページをご覧ください。 その他の AWS ニュース 見逃したかもしれない他のニュースやブログ記事: AWS Compute Blog – Daniel Wirjo と Justin Plock が、 様々な AWS サーバーレスサービスを使用して AWS 上で Webhook を送受信する方法について非常に興味深い記事を書いています。アプリケーションでウェブフックを使っているなら、これは良い読み物です。これは、これらのソリューションを構築する方法を示すだけでなく、構築する際にどのような配慮が必要かも示しています。 AWS Storage Blog – Bimal Gajjar と Andrew Peace が、 Amazon S3 Event Notifications でイベントの順序と重複イベントを処理する方法について、とても役に立つブログ記事を書いてくれました。これは多くの顧客に共通する課題です。 Amazon Science Blog – David Fan は、 映像表現のためのより良い基礎モデルを構築する方法についての記事を書きました。この記事は、Prime Video がこのトピックに関する会議で発表した論文に基づいています。 AWS の公式ポッドキャスト  – 最新の AWS ニュースや興味深いユースケースの詳細情報を毎週お届けします。AWS の公式ポッドキャストは、数か国語で配信されています。 フランス語 、 ドイツ語 、 イタリア語 、および スペイン語 のポッドキャストもぜひご利用ください。 AWS オープンソースに関するニュースと最新情報  – 私の同僚である Ricardo  が厳選した情報をお届けする ニュースレター では、最新のオープンソースプロジェクト、記事、イベントなどが取り上げられています。 近日開催される AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしてください。 AWS Community Days  – お住まいの地域で AWS ユーザーグループのリーダーが主催するコミュニティ主導のカンファレンスにぜひご参加ください: エクアドル (11 月 7 日)、 メキシコ (11 月 11 日)、 モンテビデオ (11 月 14 日)、 中央アジア (カザフスタン、ウズベキスタン、キルギス、モンゴル: 11 月 17～18 日)、 グアテマラ (11 月 18 日)。 AWS re:Invent (11 月 27 日～12 月 1 日) – AWS の最新情報を聞き、エキスパートから学び、グローバルクラウドコミュニティとつながるために ぜひご参加ください 。 セッションカタログ と 参加者ガイド を確認し、 生成系人工知能 (AI) のハイライト をご覧ください。 11月6日週はここまでです。11月13日週の Weekly Roundup もお楽しみに! –  Marcia この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

2024 年半以降、新しくリリースされた Amazon EC2 インスタンスタイプは EC2 インスタンスメタデータサービス (IMDSv2) のバージョン 2 のみを使用します。また、IMDSv2 を AWS マネジメントコンソールのクイックスタートやその他の起動経路のデフォルト選択肢にするために一連のステップが実施されています。 背景 このサービスには、EC2 インスタンス内から固定 IP アドレス (IPv4 の 169.254.169.254 または Nitro インスタンス上の IPv6 の fd00:ec2::254 ) でアクセスできます。これにより、ユーザー (またはインスタンス上で実行しているコード) は、インスタンスの起動に使用された AMI の ID、ブロックデバイスマッピング、インスタンスにアタッチされたロールの一時的な IAM 認証情報、ネットワークインターフェイス情報、ユーザーデータを始めとする豊富な静的および動的データにアクセスできます。詳細については、「 インスタンスメタデータのカテゴリ 」を参照してください。 このブログ で詳細に説明されているように、v1 サービスはリクエスト/レスポンスのアクセス方式を使用し、v2 サービスはセッション指向の方法を使用します。どちらのサービスも完全に安全ですが、v2 では IMDS へのアクセスを試みる際に悪用される可能性のある 4 種類の脆弱性に対する追加の保護レイヤーが提供されます。 多くのアプリケーションやインスタンスが既に IMDSv2 を使用して、多くののメリットを活用していますが、完全なメリットは、AWS アカウントレベルで IMDSv1 が無効化されている場合にのみ利用できます。 移行計画 IMDSv2 を新しい AWS インフラストラクチャのデフォルトの選択肢にするために実施された重要なステップと今後予定されているステップを以下に示します (2023 年と 2024 年の日付に若干のずれがあります)。 2019 年 11 月 – IMDSv2 がローンチ され、これを使用して徹底的な防御を追加する方法が紹介されました。 2020 年 2 月 – AWS Marketplace の出品者と AWS パートナーから新たに公開されたすべての製品が IMDSv2 をサポートしていることの検証が開始されました。 2023 年 3 月 – すべてのローンチにおいてデフォルトで IMDSv2 を使用する Amazon Linux 2023 がローンチされました。 2023 年 9 月 – IMDSv2 のメリットを最大限に活用し、AWS インフラストラクチャ全体で IMDSv1 を無効にする方法 を紹介するブログ記事が公開されました。 2023 年 11 月 – 本日より、すべてのコンソールのクイックスタートローンチで IMDSv2 のみが使用されるようになります (Amazon とパートナークイックスタート AMI はすべてこれをサポートします)。次の図は、これをインスタンスの起動時に EC2 コンソールの 高度な詳細 で指定する方法を示しています。 2024 年 2 月 – アカウントレベルで IMDSv1 の使用をデフォルトとして制御できる新しい API 機能が導入される予定です。現在、IMDSv1 の使用は、IAM ポリシーでの制御 (既存のアクセス許可の取り消しと制限) に加えて、アカウント、組織単位 (OU)、または組織全体にグローバルに適用される SCP として制御することが可能です。IAM ポリシーの例については、「 インスタンスメタデータの使用 」を参照してください。 2024 年半ば – 新しくリリースされた Amazon EC2 インスタンスタイプは、デフォルトで IMDSv2 のみを使用します。移行をサポートするために、これまで同様に、インスタンス上での起動時または起動後に再起動や停止/開始を必要とせずに IMDSv1 を有効化できます。 対処 完全なメリットを取得 する方法を解説したブログ記事を参照して IMDSv1 から IMDSv2 への移行を開始できます。 IMDSv2 への移行に役立つツール 、および同じページで紹介されている推奨パスについても理解しておいてください。このページでは、ツールの推奨に加えて、IMDSv1 の使用を無効にする IAM ポリシーの設定方法、および MetadataNoToken CloudWatchメトリクスを使用して残りの使用量を検出する方法も示されています。 もう 1 つの便利なリソースが AWS re:Post にあります (「 Systems Manager オートメーションを使用して、Amazon EC2 インスタンスからインスタンスメタデータにアクセスするために IMDSv2 のみを使用するように強制するにはどうすればよいですか? 」)。 この移行がお客様とお客様の顧客にとって可能な限りスムーズなものとなることを望んでいます。追加のサポートが必要な場合は、 AWS サポート にお問い合わせください。 – Jeff ; 原文は こちら です。

機械学習 (ML) における最近の進歩は、あらゆる規模と業界にまたがる組織が新しい製品を考案し、ビジネスを変革する機会を生み出しました。しかし、これらの ML モデルのトレーニング、微調整、実験、および推論を行うための GPU 容量に対する需要の拡大に業界全体の供給が追いつかなくなっているため、GPU は希少なリソースになっています。取り組んでいる研究開発フェーズに応じて容量のニーズが変動するお客様にとって、GPU 容量へのアクセスは障害になります。 10月31日、AWS は Amazon Elastic Compute Cloud (Amazon EC2) の ML 向けキャパシティブロック を発表しました。これは、ML および 生成系 AI モデルをトレーニングしてデプロイするための GPU インスタンスに簡単にアクセスできるようにすることで、ML の民主化をさらに進める Amazon EC2 の新しい使用モデルです。EC2 キャパシティブロックを使用することで、高パフォーマンス ML ワークロード向けに設計された EC2 UltraClusters に配置されている何百もの GPU を予約することができます。これには、ペタバイト規模のノンブロッキングネットワーク内にある Elastic Fabric Adapter (EFA) ネットワーキングが使用され、Amazon EC2 で利用できる最高のネットワークパフォーマンスを提供します。 これは GPU インスタンスをスケジュールするための新しい革新的な方法で、後日に必要となる数のインスタンスを、必要な時間分だけ予約することができます。現在、EC2 キャパシティブロックは AWS 米国東部 (オハイオ) リージョン内にある NVIDIA H100 Tensor Core GPU 搭載の Amazon EC2 P5 インスタンス でご利用いただけます。EC2 キャパシティブロックでは、数回クリックするだけで GPU インスタンスを予約し、自信を持って ML 開発を計画できます。EC2 キャパシティブロックは、ML トレーニングに対して EC2 で最高のパフォーマンスを提供する EC2 P5 インスタンスへの予定どおりのアクセスを、誰もが簡単に実現できるようにします。 EC2 キャパシティブロックの予約は、ホテルの部屋を予約するしくみに似ています。ホテルの予約では、部屋を予約したい日付と期間、および希望するベッドのサイズ (クイーンサイズのベッドやキングサイズのベッドなど) を指定します。これと同様に、EC2 キャパシティブロック予約でも、 GPU インスタンスが必要になる日付と期間、および予約のサイズ (インスタンスの数) を選択します。予約の開始日になると、予約した EC2 キャパシティブロックにアクセスして P5 インスタンスを起動できるようになります。EC2 キャパシティブロックの期間終了時に実行中のインスタンスは、すべて終了されます。 EC2 キャパシティブロックは、ML モデルをトレーニングもしくは微調整する、実験を行う、または ML アプリケーションに対する需要の将来的な急増に備えるために、容量を保証しておく必要がある場合に使用できます。一方で、ビジネスクリティカルなアプリケーション、規制要件、またはディザスタリカバリなど、コンピューティング能力の保証が必要となるその他すべてのワークロードタイプには、引き続き オンデマンドキャパシティ予約 を使用することができます。 ML 向けの Amazon EC2 キャパシティブロックの使用を開始する キャパシティブロックを予約するには、米国東部 (オハイオ) リージョンの Amazon EC2 コンソール で、[ キャパシティーの予約 ] を選択します。2 つのキャパシティ予約オプションが表示されます。[ キャパシティブロックを購入 ] を選択してから、[ ご利用開始にあたって ] を選択して、EC2 キャパシティブロックの検索を開始します。 合計キャパシティを選択し、EC2 キャパシティブロックが必要になる期間を指定します。EC2 キャパシティブロックは、1、2、4、8、16、32、または 64 個の p5.48xlarge インスタンスのサイズで予約できます。EC2 キャパシティブロックを予約できる合計日数は 1～14 日で、1 日単位になっています。EC2 キャパシティブロックは最大 8 週間前に購入できます。 EC2 キャパシティブロックの料金は動的で、EC2 キャパシティブロックの購入時における利用可能な総供給量と需要に応じて変動します。仕様内のサイズ、期間、または日付範囲を調整することで、他の EC2 キャパシティブロックオプションを検索できます。[ キャパシティブロックを検索 ] を選択すると、AWS が、ユーザー指定の日付範囲内で仕様を満たす、利用可能な最低料金のオプションを返します。この時点で、EC2 キャパシティブロックの料金が表示されます。 EC2 キャパシティブロックの詳細、タグ、および合計料金情報を確認したら、[ 購入 ] を選択します。EC2 キャパシティブロックの合計料金は前払いで請求され、購入後に料金が変更されることはありません。支払いは、EC2 キャパシティブロックを購入してから 12 時間以内にお客様のアカウントに請求されます。 すべての EC2 キャパシティブロック予約は、協定世界時 (UTC) の午前 11 時 30 分に開始されます。購入後に EC2 キャパシティブロックを変更またはキャンセルすることはできません。 EC2 キャパシティブロックは、 AWS コマンドラインインターフェイス (AWS CLI) と AWS SDK を使用して購入することもできます。 describe-capacity-block-offerings API を使用してクラスター要件を指定し、購入可能な EC2 キャパシティブロックを見つけます。 $ aws ec2 describe-capacity-block-offerings \           --instance-type p5.48xlarge \           --instance-count 4 \           --start-date-range 2023-10-30T00:00:00Z \           --end-date-range 2023-11-01T00:00:00Z \           –-capacity-duration 48 上記コマンドからの CapacityBlockOfferingId とキャパシティ情報を使用して利用可能な EC2 キャパシティブロックを見つけたら、 purchase-capacity-block-reservation API を使用してキャパシティブロックを購入できます。 $ aws ec2 purchase-capacity-block-reservation \           --capacity-block-offering-id cbr-0123456789abcdefg \           –-instance-platform Linux/UNIX 新しい EC2 キャパシティブロック API の詳細については、 Amazon EC2 API ドキュメント を参照してください。 これで、EC2 キャパシティブロックが正常にスケジュールされました。スケジュールされた開始日になると、EC2 キャパシティブロックがアクティブになります。開始日にアクティブな EC2 キャパシティブロックを使用するには、その EC2 キャパシティブロックのキャパシティ予約 ID を選択します。[ キャパシティ予約の詳細 ] セクションにはリザーブドインスタンスキャパシティの内訳が表示されており、キャパシティが現在どのように使用されているかがわかります。 アクティブな EC2 キャパシティブロックにインスタンスを起動するには、[ インスタンスを起動 ] を選択し、EC2 インスタンスを起動して ML ワークロードを実行するための通常のプロセスに従います。 [ 高度な詳細 ] で、[ キャパシティブロック ] を購入オプションとして選択し、ターゲットにしようとしている EC2 キャパシティブロックのキャパシティ予約 ID を選択します。 EC2 キャパシティブロックの終了時間が近づくと、Amazon EC2 が Amazon EventBridge を通じてイベントを送信して予約が間もなく終了することを通知するので、ワークロードのチェックポイントを設定することができます。EC2 キャパシティブロックで実行中のインスタンスは、予約が終了する 30 分前にシャットダウン中状態になります。EC2 キャパシティブロックに対して請求された金額に、この 30 分間は含まれていません。EC2 キャパシティブロックの有効期間終了時に実行中のインスタンスは、すべて終了されます。 今すぐご利用いただけます Amazon EC2 キャパシティブロック は、AWS 米国東部 (オハイオ) リージョンの p5.48xlarge インスタンスで今すぐご利用いただけます。EC2 キャパシティブロックの料金は予約前に確認でき、EC2 キャパシティブロックの合計料金は購入時に前払いで請求されます。詳細については、 EC2 キャパシティブロックの料金 ページを参照してください。 EC2 キャパシティブロックの詳細については、 EC2 キャパシティブロックドキュメント を参照してください。フィードバックは、 AWS re:Post for EC2 、または通常の AWS サポート連絡先をとおして送信してください。 – Channy 原文は こちら です。

AWS re:Invent まであと 1 か月を切りましたが、その間も興味深いニュースが続々と発表されています。10月30日週は、私が皆様に最新情報をお知らせします! 先週のリリース 10月23日週、私の目に留まったリリースをいくつかご紹介します。 AWS re:Post – re:Post では、AWS を利用してさらなる成功を実現するのに役立つエキスパートのコミュニティにアクセスできます。 Selections では、コミュニティメンバーは集約ビューで知識を整理し、 学習パスや厳選されたコンテンツセットを作成できます。 Amazon SNS – FIFO (先入れ先出し) トピックが、別のアーカイブリソースのプロビジョニングを必要とせずに、 メッセージを保存および再生するオプションをサポートするようになりました 。これは、イベント駆動型アプリケーションの耐久性を向上させ、ダウンストリームの障害シナリオから回復するのに役立ちます。詳細については、AWS コンピューティングブログの記事「 Archiving and replaying messages with Amazon SNS FIFO 」をご覧ください。また、 カスタムデータ識別子 を使用して、一般的な機密データ (名前、住所、クレジットカード番号など) だけでなく、会社の従業員 ID などのドメイン固有の機密データも保護できるようになりました。この機能の詳細については、AWS セキュリティブログの記事「 Mask and redact sensitive data published to Amazon SNS using managed and custom data identifiers 」をご覧ください。 Amazon SQS – FIFO 高スループットモードのためのスループットクォータの引き上げ により、API アクションごとに 1 秒あたり最大 18,000 のトランザクションを処理できます。スループットクォータは AWS リージョンによって異なることにご留意ください。 Amazon OpenSearch Service – OpenSearch Serverless は、新しいインデックスライフサイクルポリシーにより、 時間ベースの自動データ削除 をサポートするようになりました。 正確で低レイテンシーのベクトル検索クエリを提供するための最適な戦略を決定 するために、OpenSearch は、 近似最近傍探索 (ANN) を使用した事前フィルタリングや、正確な k-最近傍 (k-NN) を使用したフィルタリングなど、 最適なフィルタリング戦略をインテリジェントに評価 できるようになりました。また、OpenSearch Service は、 インターネットプロトコルバージョン 6 (IPv6) をサポートするようになりました 。 Amazon EC2 – マルチ VPC ENI アタッチメント を使用すると、1 つの仮想プライベートクラウド (VPC) 内でプライマリ Elastic Network Interface (ENI) を使用してインスタンスを起動し、別の VPC からセカンダリ ENI をアタッチできます。これは、ネットワークレベルの分離を維持するのに役立ちますが、特定のワークロード (一元管理されたアプライアンスやデータベースなど) が相互に通信するのを引き続き許可します。 AWS CodePipeline – パラメータ化されたパイプライン を使用すると、入力パラメータをパイプライン実行に動的に渡すことができます。ソースリポジトリ内の コミットに特定の git タグが適用された際にパイプラインの実行を開始 できるようになりました。 Amazon MemoryDB – Graviton3 ベースの R7g ノードをサポート するようになりました。これは、R6g と比較して最大 28% 多いスループットを実現します。また、これらのノードは、より高いネットワーク帯域幅も提供します。 その他の AWS のニュース ここでは、私が注目している AWS およびクラウドに関する他のブログ記事をいくつかご紹介します。 ネットワーキングとコンテンツ配信のブログ – AWS ネットワークインフラストラクチャを構築する際に下す、技術管理とハードウェアに関する意思決定の一例:「 A Continuous Improvement Model for Interconnects within AWS Data Centers 」 DevOps ブログ – 企業のお客様が CodeWhisperer を利用しているデベロッパーの数、利用頻度、提案を受け入れる頻度を理解するのをサポートします:「 Introducing Amazon CodeWhisperer Dashboard and CloudWatch Metrics 」 フロントエンドウェブおよびモバイルブログ – GraphQL API へのアクセスをプライベートネットワーク内のコンシューマーに制限する方法:「 Architecture Patterns for AWS AppSync Private APIs 」 アーキテクチャブログ – この非常に興味深いシリーズの新しい記事:「 Let’s Architect! Designing systems for stream data processing 」 Community.AWS から:「 Load Testing WordPress Amazon Lightsail Instances 」および「 Future-proof Your .NET Apps With Foundation Model Choice and Amazon Bedrock 」。 私の同僚の Ricardo による AWS の最新のオープンソースに関するニュースレター もお見逃しなく。 今後の AWS イベント カレンダーを確認して、次の AWS イベントにぜひサインアップしてください。 AWS Community Days  – お住まいの地域で AWS ユーザーグループのリーダーが主催するコミュニティ主導のカンファレンスにぜひご参加ください: ジャイプル (11 月 4 日)、 ヴァドーダラー (11 月 4 日)、 ブラジル (11 月 4 日)、 中央アジア (カザフスタン、ウズベキスタン、キルギス、モンゴル: 11 月 17～18 日)、 グアテマラ (11 月 18 日)。 AWS re:Invent (11 月 27 日～12 月 1 日) – AWS の最新情報を聞き、エキスパートから学び、グローバルクラウドコミュニティとつながるために ぜひご参加ください 。 セッションカタログ と 参加者ガイド を確認し、 生成系 AI のハイライト をご覧ください。 こちらでは、今後のすべての AWS 主導の対面および仮想イベント と デベロッパー中心のイベント を確認できます。 10月30日週はここまでです。次回もお楽しみに! – Danilo この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

訳者注記： 原文記事 は 2019 年の記事となりますが、定期的にメンテナンスされており、且つ DNS 管理において有用であるため翻訳対象として選定しています。 前回の投稿 では、マルチアカウント環境にCentral DNS を実装するソリューションを紹介しました。これにより、クロスアカウントや AWS からオンプレミスへのドメイン解決を実装するときに必要なサーバーとフォワーダーの数が減り、DNS 管理が簡素化されます。 Amazon Route 53 Resolver サービスのリリースにより、ハイブリッド DNS 解決をさらに簡素化するネイティブの条件付きフォワーダーにアクセスできるようになりました。 この記事では、Route 53 Resolver を使用してマルチアカウント環境で DNS 管理を一元化する最新のソリューションを紹介します。このソリューションにより、AWS でドメインコントローラーを実行しなくても、複数のアカウントにわたって、また AWS とオンプレミスで実行されているワークロード間でドメインを解決できます。 ソリューションの概要 このソリューションでは、ドメイン解決の 3 つの主要なユースケースを解決する方法を示します。 VPC で実行されているワークロードからオンプレミスドメインの名前解決 オンプレミスで実行されているワークロードから AWS 環境内のプライベートドメインの名前解決 異なる AWS アカウントで実行されているワークロード間のプライベートドメインの名前解決 次の図は、大まかなアーキテクチャを示しています。 図 1: アーキテクチャ図 アーキテクチャ図中の 1 ~ 6 について説明します。 Central DNS VPC 用のAmazon が提供するデフォルト DNS サーバーです。ここでは、これを DNS-VPC と呼びます。これは VPC CIDR 範囲内の 2 番目の IP アドレスです (図に示されているように、 172.27.0.2 を持ちます)。このデフォルトの DNS サーバーは、参加している AWS アカウントで実行されるすべてのワークロードのプライマリドメインリゾルバーになります。 Route 53 Resolver Endpoint を示しています。インバウンドエンドポイントは、オンプレミスの DNS サーバーと、参加している AWS アカウントで実行されているワークロードから転送されたクエリを受信します。アウトバウンドエンドポイントは、ドメインクエリを AWS からオンプレミス DNS に転送するために使用されます。 条件付き転送ルールを示しています。このアーキテクチャでは、2 つのルールが必要です。1 つは onprem.private ゾーンのドメインクエリをアウトバウンドエンドポイント経由でオンプレミス DNS サーバーに転送するルール、もう 1 つは awscloud.private のドメインクエリを DNS-VPC のリゾルバーインバウンドエンドポイントに転送するルールです。 これら 2 つの転送ルールが AWS Resource Access Manager を介して他のすべての AWS アカウントと共有され、これらのアカウントのすべての VPC に関連付けられていることを示しています。 awscloud.private という固有のサブドメインを使用して各アカウントに作成されたプライベートホストゾーンを示しています。 awscloud.private ゾーンへのクエリを Resolver インバウンドエンドポイントの IP アドレスに転送するように設定された条件付きフォワーダーを備えたオンプレミスの DNS サーバーを示しています。 注:このソリューションでは、送信元/宛先の VPC と DNS-VPC 間の VPC ピアリングや接続は必要ありません。 仕組み 次に、このアーキテクチャのドメイン解決フローが、3 つのユースケースに従ってどのように機能するかを示します。 ユースケース ① 図 2: AWS で実行されているワークロードからオンプレミスドメインを解決するユースケース 最初に、AWS で実行されているワークロードからオンプレミスドメインを解決する方法を見ていきます。プライベートドメイン host1.acc1.awscloud.private のサーバーが host1.onprem.private というアドレスを解決しようとすると、次のようになります。 DNS クエリは、host1.acc1.awscloud.private をホストしている VPC のデフォルト DNS サーバーにルーティングされます。 VPC は Central DNS アカウントから共有される転送ルールに関連付けられているため、これらのルールは VPC 内の Amazon が提供するデフォルトの DNS によって評価されます。 この例では、ルールの 1 つが onprem.private のクエリをオンプレミス DNS サーバーに転送するように指示しています。このルールに従って、クエリはオンプレミスの DNS サーバーに転送されます。 転送ルールは Resolver アウトバウンドエンドポイントに関連付けられているため、クエリはこのエンドポイントを介してオンプレミスの DNS サーバーに転送されます。 このフローでは、参加しているアカウントの1つで開始されたDNSクエリが Central DNS サーバーに転送され、次にオンプレミス DNS に転送されます。 ユースケース ② 次に、オンプレミスのワークロードで AWS 環境のプライベートドメインを解決する方法は次のとおりです。 図 3: オンプレミスのワークロードで AWS 環境のプライベートドメインを解決する方法のユースケース この場合、host1.acc1.awscloud.private のクエリはオンプレミスホストから開始されます。次に何が起こるかは次のとおりです。 ドメインクエリはオンプレミスの DNS サーバーに転送されます。 その後、クエリはオンプレミスDNSサーバー上の条件付き転送ルールを介して Resolver インバウンドエンドポイントに転送されます。 クエリは、DNS-VPC のデフォルト DNS サーバーに到達します。 DNS-VPC はプライベートホストゾーン acc1.awscloud.private に関連付けられているため、デフォルトの DNS サーバーがこのドメインを解決できます。 この場合、DNS クエリはオンプレミスで開始され、インバウンドエンドポイントを通じて AWS 側の Central DNS に転送されています。 ユースケース③ 最後に、複数の AWS アカウントにまたがるドメインの解決が必要になる場合があります。これを実現する方法は次のとおりです。 図 4: 複数の AWS アカウントにまたがるドメインを解決する方法のユースケース host1.acc1.awscloud.private のホスト 1 が host2.acc2.awscloud.private というドメインを解決しようとしたとすると、次のことが起こります。 ドメインクエリは、VPC ホスティングソースマシン (host1) のデフォルト DNS サーバーに送信されます。 VPC は共有転送ルールに関連付けられているため、これらのルールは評価されます。 awscloud.private ゾーンのクエリは、DNS-VPC のインバウンドエンドポイントに (アウトバウンドエンドポイント経由で) 転送する必要があるというルールがあります。 次に、アウトバウンドエンドポイントは DNS クエリをターゲット IP に転送します。この例では、ターゲット IP は受信エンドポイントの IP アドレスです。 DNS-VPC は acc2.awscloud.private ホストゾーンに関連付けられているため、デフォルトの DNS は自動定義ルールを使用してこのドメインを解決します。 このユースケースでは、DNS クエリが 1 つの参加アカウントで開始され、別の AWS アカウントのドメイン解決のために Central DNS に転送される、AWS 間ケースについて説明します。次に、このソリューションをお客様の環境で構築するために何が必要かを見ていきます。 ソリューションの導入方法 このソリューションを 4 つのステップで構成する方法を説明します。 一元化された DNS アカウントを設定します。 各参加アカウントを設定します。 プライベートホストゾーンと Route 53 の関連付けを作成します。 オンプレミスの DNS フォワーダーを設定します。 ステップ 1: Central DNS アカウントを設定する このステップでは、一元管理された DNS アカウントにリソースを設定します。主に、DNS-VPC、リゾルバーエンドポイント、転送ルールが含まれます。 ウェブコンソール または AWS クイックスタート を使用して、ビジネスシナリオに応じて DNS-VPC として動作する VPC を作成します。 Amazon VPC ユーザーガイド で一般的なシナリオを確認できます。非常に一般的なシナリオの 1 つは、 パブリックサブネットとプライベートサブネットを持つ VPC です。 リゾルバーエンドポイントを作成 します。DNS クエリをオンプレミス DNS に転送するアウトバウンドエンドポイントと、オンプレミスのワークロードや他の AWS アカウントから転送された DNS クエリを受信するインバウンドエンドポイントを作成する必要があります。 2 つの 転送ルール を作成します。最初のルールは、ゾーン onprem.private の DNS クエリをオンプレミスの DNS サーバーの IP アドレスに転送することです。2 番目のルールは、ゾーン awscloud.private の DNS クエリをリゾルバーのインバウンドエンドポイントの IP アドレスに転送することです。 ルールを作成したら、ゾーン onprem.private のルールをステップ #1 で作成した DNS-VPC に関連付け ます(他の転送ルールを DNS-VPC に関連付ける必要はありません)。これにより、Route 53 リゾルバーはドメインクエリの転送をそれに応じて開始できます。 最後に、 2 つの転送ルールをすべての参加アカウントと共有する 必要があります。そのためには、AWS Resource Access Manager を使用し、ルールを AWS 組織全体または特定のアカウントと共有できます。 注:ドメインクエリをオンプレミスの DNS サーバーに転送するには、データセンターと DNS-VPC 間の接続が必要です。接続は、 Site-to-Site VPN または AWS Direct Connect を使用して確立できます。 ステップ 2: 参加アカウントを設定する 参加しているアカウントごとに、共有転送ルールを使用するように VPC を設定し、アカウントごとにプライベートホストゾーンを作成する必要があります。 AWS Resource Access Manager からの 共有ルールに同意 します。ルールが AWS 組織と共有されている場合、このステップは不要です。次に、転送ルールを各アカウントのワークロードをホストする VPC に関連付け ます。関連付けが完了すると、リゾルバーはルールに従ってDNSクエリの転送を開始します。 この時点で、共有転送ルールに関連付けられている任意の VPC で実行されているワークロードからオンプレミスドメインを解決できるはずです。AWS でプライベートドメインを作成するには、プライベートホストゾーンを作成する必要があります。 ステップ 3: プライベートホストゾーンを作成する このステップでは、awscloud.private のサブドメインを使用して各アカウントにプライベートホストゾーンを作成する必要があります。環境内でのドメインの競合を避けるため、プライベートホストゾーンごとに一意の名前を使用してください (たとえば、acc1.awscloud.private または dev.awscloud.privateなどです)。 awscloud.private のサブドメインを持つ各参加アカウントに プライベートホストゾーンを作成 し、そのアカウントで実行されている VPC に関連付けます。 プライベートホストゾーンを DNS-VPC に関連付け ます。これにより、集中管理された DNS-VPC はプライベートホストゾーンのドメインを解決し、AWS アカウント間の DNS リゾルバーとして機能できます。 プライベートホストゾーンと DNS-VPC は異なるアカウントにあるため、プライベートホストゾーンを DNS-VPC に関連付ける必要があります。そのためには、プライベートホストゾーンを所有するアカウントから認証を作成し、DNS-VPC を所有するアカウントからこの承認を受け入れる必要があります。これは AWS CLI を使用して行うことができます。 参加している各アカウントで、プライベートホストゾーン ID、リージョン、関連付ける VPC ID (DNS-VPC) を使用して認証を作成します。 aws route53 create-vpc-association-authorization --hosted-zone-id <hosted-zone-id> --vpc VPCRegion= <region> ,VPCId= <vpc-id> Text Central DNS アカウントで、参加している各アカウントのホストゾーンに DNS-VPC を関連付けます。 aws route53 associate-vpc-with-hosted-zone --hosted-zone-id <hosted-zone-id> --vpc VPCRegion= <region> ,VPCId= <vpc-id> Text ステップ 4: オンプレミス DNS フォワーダーを設定する オンプレミスで実行されているワークロードから awscloud.private ドメイン内のサブドメインを解決できるようにするには、Central DNS アカウントに作成されたリゾルバーインバウンドエンドポイントの 2 つの IP アドレスにドメインクエリを転送する条件付き転送ルールを設定する必要があります。これには、データセンターと DNS-VPC 間の接続が必要であることに注意してください。接続には、 Site-to-Site VPN または AWS Direct Connect を使うことができます。 その他の考慮事項と制限事項 Route 53 Resolverの柔軟性と条件付き転送ルールにより、どのクエリを Central DNSに送信し、どのクエリを同じアカウントでローカルに解決するかを制御できます。これは、AWS PrivateLink や Amazon Elastic File System (EFS) など一部の AWS サービスを使用する予定がある場合に特に重要です。これらのサービスに関連するドメイン名は、それらを所有するアカウントのローカルで解決する必要があるためです。 可能であれば、アカウントのローカルドメインを解決することをお勧めします。たとえば、同じアカウントのプライベートホストゾーンにあるプライベートドメインの場合です。そのためには、アカウントのローカルに条件付き転送ルールを作成し、ルールタイプに「system」を使用して、これらのルールを VPC に関連付けることができます。 ※訳者注記：ルールタイプについてのドキュメントは こちら を参照ください。 Route 53 リゾルバーの制限に関する注意：Route 53 リゾルバーには、エンドポイントの IP アドレスあたり 1 秒あたり 10,000 クエリという制限があります。より高い制限を必要とするワークロードがある場合は、EC2 インスタンス上で実行されている適切に設定されたローカル DNS サーバーにこれらのクエリを転送することを検討してください。サービスの制限について詳しくは、 こちら をご覧ください。 このセクションでは、追加の考慮事項が必要な 2 つのユースケースを挙げます。 インターフェイス VPC エンドポイント (AWS PrivateLink) AWS PrivateLink インターフェイスエンドポイント を作成すると、AWS はサービスとの通信に使用できるエンドポイント固有の DNS ホスト名を生成します。AWS サービスと AWS Marketplace パートナーサービスでは、オプションでエンドポイントのプライベート DNS を有効にできます。このオプションは、プライベートホストゾーンを VPC に関連付けます。ホストゾーンには、サービスのデフォルト DNS 名のレコードセット (たとえば 、ec2.us-east-1.amazonaws.com) が含まれています。このレコードセットは、VPC 内のエンドポイントネットワークインターフェイスのプライベート IP アドレスになります。これにより、エンドポイント固有の DNS ホスト名ではなく、デフォルトの DNS ホスト名を使用してサービスにリクエストを行うことができます。エンドポイントにプライベート DNS を使用する場合は、アカウントのローカルエンドポイントへの DNS クエリを解決し、AWS が提供するデフォルトの DNS を使用する必要があります。そのため、この場合は 、amazonaws.com のドメインクエリをローカルで解決し、これらのクエリを Central DNS に転送しないことをお勧めします。 DNS 名を使用して EFS をマウントする DNS 名を使用して Amazon EFS ファイルシステム　Amazon　EC2　インスタンスにマウントできます。ファイルシステム　DNS　名は、接続している Amazon EC2 インスタンスのアベイラビリティーゾーンにあるマウントターゲットの IP アドレスに自動的に解決されます。そのためには、VPC は Amazon が提供するデフォルト DNS を使用して EFS DNS 名を解決する必要があります。ご使用の環境で EFS を使用する予定がある場合は、EFS DNS 名をローカルで解決し、これらのクエリを Central DNS に送信しないことをお勧めします。その場合、クライアントはアベイラビリティーゾーンに最適化された回答を受け取ることができず、オペレーションのレイテンシーが高くなり、耐久性が低下する可能性があります。 まとめ この記事では、マルチアカウントおよびハイブリッド環境で Central DNS 解決を実装するための簡単なソリューションを紹介しました。このソリューションでは、AWS Route 53 Resolver、AWS Resource Access Manager、および Route 53 のネイティブ機能が使用され、AWS　環境でカスタム　DNS　サーバーやフォワーダーが不要になるため、複雑さと運用の労力が軽減されます。 著者について Mahmoud Matouk Mahmoud は、世界各地の公共部門ソリューションアーキテクトの一員であり、高等教育機関のお客様がさまざまな AWS サービスを使用して、革新的で安全で可用性の高いソリューションを構築できるよう支援しています。 この記事の翻訳はソリューションアーキテクトの長屋が担当しました。原文は こちら です。

この記事は、 Commoditize connected mobility with WirelessCar on AWS を翻訳したものです。 WirelessCar は、スウェーデン、米国、中国に拠点を置き、12 社以上の自動車 OEM 、世界中の 100 を超える市場 に対して、 AWS の 99.99% の稼働率でコネクテッドモビリティサービスを提供しています。WirelessCar は、コネクテッドカーサービスの構築において 20 年以上の経験を持つ AWS パートナー です。WirelessCar は、API 製品、コストの最適化、フライホイールの構築、AWS によるスケールメリットにより、AWS 上のコネクテッドモビリティサービスをコモディティ化してきました。WirelessCar が AWS 上で展開するプラットフォームには、現在 1,000 万台以上の車両が接続しており、 1 億台の接続数であれば、年間の台あたりコストを 1 桁ドル台まで下げるに至っています。 このブログ記事では、WirelessCar が AWS を利用してモジュラー API 製品を構築し、コスト最適化を実現し、スケールメリットを構築してコネクテッドモビリティサービスをコモディティ化した方法に焦点を当てています。 背景 自動車 OEM がデジタルトランスフォーメーションを続けるにつれて、ソフトウェア開発組織になりつつあり、ソフトウェアサプライヤーからのサービスの利用方法も変化するでしょう。要件を指定してサプライヤーに機能を注文する組織から、社内で独自のソフトウェアを構築する開発チームへと変化しています。誰もが毎回すべてをゼロから構築することは持続可能ではないため、チームは差別化のない機能をサプライヤーから購入することに頼っています。このようなソースソフトウェアの消費者が OEM の社内開発チームに移るとき、彼らはパブリッククラウドサービスと同じようにソフトウェアを利用できることを期待しています。つまり、自分でインストールして運用する必要のあるソフトウェアパッケージを受け取ることは期待せず、 SaaS モデルでサプライヤーから提供された API ベースの製品を利用することになります。これにより、 OEM 開発チームはセルフサービスで製品のインスタンス化、統合のトラブルシューティング、使用状況と請求のフォローアップ、アクセスとデータの管理を行うことができます。その結果、ボトルネックが解消され、 OEM はイノベーションのスピードを上げることができます。 WirelessCar の API 製品 WirelessCar は、クラウドベースのフルマネージド型コネクテッドモビリティ API 製品を SaaS 方式で提供します。既製のマネージド API 製品を自社で構築して保守する代わりに利用することで、OEM は差別化機能の提供に注力し、総所有コストを削減し、スケールメリットを享受できます。カスタマイズやコンサルティングのニーズに合わせて、 WirelessCar はプロフェッショナルサービスとディスカバリーサービスを提供します。OEM は、顧客にコネクテッドモビリティサービスや、 API を使用して採用して既存のプラットフォームに統合したい製品を提供するために、WirelessCar 製品スイート全体を完全なソリューションとして採用することを選択します。そのため、既存のOEM プラットフォームと新しい OEM プラットフォームの両方が、 WirelessCar API 製品のすべてまたは一部を採用しています。 WirelessCar は、コネクテッドモビリティの6つの異なる分野で API 製品を提供しています。 接続性 : 車両とライフサイクル管理への接続を提供する製品。 ジャーニーインテリジェンス : この分野には、 位置と移動の統計情報 、 データレイク 、デジタルコンパニオン、ドライバーモニタリング、コーチングのユースケースを網羅した製品が含まれます。 安全とセキュリティ : これには、 コールセンターサービス 、盗難車追跡、車両セキュリティ警告サービスが含まれます。 電気自動車 ( EV ) : 自動車業界で信頼性の高い EV サービスの1つであるスマート EV ルーティング、スマート充電、デジタル EV コンパニオンサービス。 共有モビリティ : この分野では、WirelessCar が車両管理、車両データアクセス、デジタル管理サービスを提供します。 デジタルトランスフォーメーション : 物流追跡、社用車管理、遠隔診断、予知保全などがこの分野でカバーされる最新のサービスです。 WirelessCar と AWS は協力して、エッジ・ツー・クラウド、セキュリティ、データ、機械学習などの分野で新製品を開発しています。OEM は WirelessCar サービスを採用し、WirelessCar サービス API を使用してその上にサービスを構築しています。 WirelessCar 製品は、OEM が車両、工場、顧客関係管理システム、またはその他のエンドポイントからデータを安全に取り込むのに役立ちます。OEM は WirelessCar に連絡してこれらの API を購読します。WirelessCar には、API の使用方法に関する詳細なドキュメントが用意されています。OEM は、サービスの利用に何か月も何年もかかっていた API を数週間で使い始めています。 WirelessCar 製品は、AWS のマネージドサービスと Amazon API gateway 、 AWS Lambda 、 Amazon DynamoDB 、 AWS IoT Core などの Serverless サービスを使用して、インフラストラクチャをコスト効率よくスケーリングし、DevOps の労力を削減します。WirelessCar サービスをコードとしてのインフラストラクチャとして構築し、継続的インテグレーションと継続的デプロイ ( CI/CD ) パイプラインを構築することで、DevOps の労力が軽減されます。ロギング、モニタリング、アラートサービスは Amazon CloudWatch を使用して提供されます。セキュリティとアクセス管理を確保するために、AWS のセキュリティおよびアクセス管理サービスである Identity and Access Management (IAM) 、 AWS WAF 、 AWS Certificate Manager (ACM) 、 AWS security hub 、 AWS Shield 、およびその他のサービスが使用されています。このように、WirelessCar はコネクテッドモビリティサービスを利用するためのモジュール式 API 製品を OEM に提供しています。AWS と WirelessCar は、今後、これらのサービスを AWS マーケットプレイスで利用できるように取り組んでいます。これにより、誰でも既製の WirelessCar 製品を使い始めることができます。 コスト最適化 コスト最適化は一過性のものではなく、費用対効果の高いソリューションを開発するために企業文化の一部として DevOps チームに組み込まれます。モビリティワークロードにおけるコストは、車両の通信パターン、車両が使用するモビリティサービスの数、および車両が要求する応答によって異なります。これら 3 つのパラメータは OEM ごとに異なるため、各 OEM のコストは異なります。このためコスト最適化は、 OEM プログラム、 WirelessCar サービス、および AWS サービスごとのコストを特定することからスタートしました。 WirelessCar と AWS は、コストログと Amazon QuickSight を使用してコストを見える化し、1 台あたりの年間コスト、メッセージあたりのコストなどのマトリックスを作成しました。現在では WirelessCar は、コストをほぼリアルタイムで追跡し、結果を測定することが可能となりました。 WirelessCar では、コストの視覚化を可能にするために、すべての AWS リソースに対して一貫したタグ付け戦略を採用していることに注意してください。 WirelessCar は、2 つの方法でコスト削減を実現しました。 アーキテクチャ変更したり、多大な労力をかけたり、クラウド利用に関するガバナンスを設定したりすることのないような、容易な項目を特定しました。例えば、未使用のリソースやデータのクリーニング、コスト削減のための IO2 から IO3 への Amazon Elastic Block Store ( Amazon EBS ) ボリューム変更や、コンピューティングとデータベース用の AWS EC2 Graviton インスタンスの利用などです。 各 AWS サービスの使用方法を確認し、コスト最適化アクションとリファクタリングを特定しました。これらの取り組みは、 WirelessCar チームが各スプリントで計画し、機能の実装を優先しながら、時間をかけて実施してきました。 WirelessCar におけるコスト最適化キャンペーンにより、WirelessCar チームは自分たちの選択を意識するようになりました。現在、 WirelessCar チームは開発したサービスコストを QuickSight で追跡し、コストの最適化に取り組んでおり、また WirelessCar のお客様はこれらのコスト削減から直接メリットを得ることができます。このように、 WirelessCar はコスト効率の高い API 製品を OEM に提供しています。 スケールメリットの構築 20 年以上の経験、コストを最適化した優れた API 製品、 AWS とのパートナーシップ、市場開拓戦略により、 WirelessCar の製品を利用する OEM の数はますます増えています。 WirelessCar は、数か月や数年ではなく、数週間で顧客をプラットフォームに導入できるようになりました。既存のモビリティプラットフォームは、特に EV サービスの分野でギャップを埋めるために WirelessCar サービスを採用しています。 WirelessCar と AWS は協力して新しいサービスを市場に投入しています。 これにより、世界中で毎週何千台もの新しい車両が WirelessCar 製品に接続されています。これはフライホイールの構築とスケールメリットの向上に役立ち、ひいては車両1台あたりのコストを削減し、 WirelessCar のお客様にもメリットをもたらします。私たちは 1 億台の車両に搭載し、コネクテッドモビリティサービスを共同でコモディティ化することを目指しています。 最後に このブログ記事では、 WirelessCar と AWS がどのように協力して API 製品、コスト最適化、スケールメリットを利用してコネクテッドモビリティサービスをコモディティ化したかを学びました。詳細については、 WirelessCar まで お問い合わせ ください。AWS サービスの詳細については、 自動車向け AWS のページ をご覧ください。または、今すぐ AWS チームに お問い合わせ ください。 このブログは、ソリューションアーキテクトの丹羽と小野田が翻訳しました。 Sushant Dhamnekar Sushant Dhamnekar は AWS のシニアソリューションアーキテクトです。Sushant は、信頼できるアドバイザーとして、コネクテッドモビリティやソフトウェアデファインドビークルの分野で、拡張性、柔軟性、耐障害性に優れたクラウドアーキテクチャを構築する自動車業界のお客様を支援しています。仕事以外では、Sushantはハイキング、食事、旅行、HIT ワークアウトを楽しんでいます。 Tomas Carlfalk トーマスは、コネクテッドカーのパイオニアである WirelessCar の CTO であり、自動車メーカーと協力してデジタルトランスフォーメーション戦略を実現しています。スウェーデン西海岸のヨーテボリで生まれ育ったトーマスは、約20年前に WirelessCar のソフトウェア開発者として自動車業界でキャリアをスタートさせました。長年にわたり、さまざまな役職でコネクテッドカープログラムの立ち上げに携わってきたほか、 WirelessCar 全体のクラウド導入とサイバーセキュリティの取り組みを主導してきました。

最近は日本政府および多くの企業が「クラウド・ファースト」を宣言し、クラウドを最優先にシステム開発に取り組む事例が数多く出てきています。業界や規模を問わず多くの企業が、クラウド上でシステムを開発するプロジェクトに取り組んでいます。クラウドを活用する場合でも、プロジェクト管理のポイントは従来のプロジェクトと変わらず、PMBOK® Guide等のナレッジを最大限活用して進めることが重要です。一方で、クラウドの特性ゆえに陥りがちな問題もあり、回避策を知り正しく実践することでプロジェクトの成功率を高めることができます。 そこで、著者がカスタマーソリューションマネジャーとしてお客様を支援する中で得られた、クラウドを活用するプロジェクトを進める際の具体的な考慮点を、複数回に分けてお伝えいたします。初回となる本ブログでは、プロジェクトの立ち上げにフォーカスし、目標とするビジネス価値を明確にして関係者と合意することの重要性について記載します。クラウドを活用したプロジェクトの立ち上げをリードする方を主な読者と想定していますが、プロジェクトメンバとして実行に関わる方にも参考になる内容と考えています。 クラウドを活用するプロジェクトで起こりやすい問題 クラウドを活用するプロジェクトは「クラウドの活用」自体が目的となり、具体的なビジネス上の目標が不明確なまま開始されてしまうことがあります。それにより、以下のような問題が発生し、プロジェクトの減速・停滞につながってしまうケースが見られます。 想定外の問題が発生した時や、他の重要案件が発生した時にプロジェクトの優先度を正しく評価できず劣後・停滞してしまう システムのリリース後にコストの削減のみが注目され、「期待していた効果が出ていない」と評価される。またはそもそも効果の評価自体ができない状態となる このような状況を避けるためには、以下2点を注意してプロジェクトを立ち上げることが重要です。 考慮点①　クラウド活用で得られる価値を正しく理解し、具体的なビジネス上の目標を設定する クラウドを活用することで得られる価値は多岐にわたります。以下にAWSがこれまで多数・多様なお客様のクラウド移行をご支援する経験に基づいて整理した、クラウドの活用により期待できる価値のフレームワーク（ AWS Cloud Value Framework ）を記載しています。もちろん実際に期待できる価値は各システムの特性や状況にもよりますが、システムの信頼性向上や俊敏性向上がコスト削減以上にビジネスに大きな価値をもたらすことも多くあります。 そのため、プロジェクト立ち上げの際に、これらを踏まえた広い視点で具体的なビジネス上の目標を定義し、検証できるよう準備をすることが非常に重要となります。そうすることで、想定外の問題が発生した時や、他の重要案件が発生した時に客観的な評価をすることが可能となり、プロジェクトの減速・停滞を防止することができます。また、システムリリース後に効果の計測・評価を適切に行うことも可能となります。 考慮点②　ビジネス部門を含めたプロジェクトのステークホルダー全員で目標を合意する 具体的なビジネス上の目標を立てているものの、ステークホルダーの特定や重要度判断が不足することで、ビジネス部門との認識が合致していないケースが見られます。このような状態では、プロジェクトを進める中で、仕様変更の判断が正しくできない、テストや移行準備などで適切な協力が得られない、といった問題につながってしまいます。 そのため、設定した目標をプロジェクトのステークホルダー全体に共有し、合意しておくことが非常に重要です。プロジェクトマネージャーにはこの点を意識し、必要なコミュニケーションを丁寧に行うことが求められます。加えて、合意した内容は極力プロジェクト憲章等に文章化して残すことが推奨されます。それにより、認識相違の防止や、プロジェクトメンバへの共有の効果が高まります。 また、クラウド活用推進をミッションとした、ビジネス部門とIT部門が一体となった組織（CCoE：Cloud Center of Excellence）がプロジェクトの立ち上げを支援することも有効な方法となります。CCoEについてはその役割等を解説している ブログ を是非参考にしていただければと思います。 まとめ クラウド活用プロジェクトを成功に導くためには、プロジェクト立ち上げの時点で達成すべきビジネス価値を明確にし、関係者間で合意することが重要です。具体的には、以下の2点に注意しましょう。 クラウド活用の価値を広く理解し、具体的なプロジェクトの目標を設定する ビジネス部門を含めたステークホルダー全員で目標を合意する プロジェクト立ち上げ後の重要な考慮点については、次回以降のブログでお伝えいたしますので、そちらも是非ご覧ください。 参考リンク 第１回：プロジェクトの立ち上げ 第２回：柔軟なベースライン管理

第２回ではプロジェクトを成功させる３大要素である、スコープ、スケジュール、コストのベースラインに焦点を当てます。プロジェクトの成功に向けて成果物を明確に定義し、範囲を制御するスコープ管理、プロジェクトを所定の時期に完了するようマネジメントするスケジュール管理、プロジェクト予算内で運営するためのコスト管理は不可欠な管理領域です。これらの管理領域は密接に連携し、バランスを保ちながらプロジェクトを計画、実行し、監視する必要があります。また、開発アプローチについては、プロジェクトの要求事項や環境に応じて適切なアプローチ手法を選択する必要があります。本ブログでは、伝統的なウォーターフォール開発だけでなく、クラウドの特性を最大限に活用するために、アジャイル開発やハイブリッド開発などの柔軟な開発アプローチも考慮し、お客様へクラウド活用をご支援する中で得られた具体的な考慮点をご紹介します。 多様なサービスの活用や柔軟なスケーリングができるメリットを活かしたスコープ管理 スコープ管理はプロジェクトの範囲を明確に定義し、変更を管理する重要な要素です。クラウド導入プロジェクトにおけるスコープ管理では、以下の内容について考慮することが重要です。 柔軟なスコープ変更への対応 ：クラウドの利点である多種多様なサービスを低コスト、短時間で利用できる特徴に注目し、ビジネスニーズや市場変化に適応するための柔軟なスコープ変更を可能にする対応策が求められます。これには、適切なスコープ変更プロセスの確立が必要であり、新しいサービスの追加や既存のサービスの削減などを戦略的かつ迅速に実現できるようになります。柔軟なスコープ変更は、競争力維持・向上やビジネスの成功に寄与し、クラウド導入プロジェクトの成果を最大限に活用する手段となります。 マネージドサービスの活用 ： マネージドサービス を利用することで、スプリントごとにスコープ調整が行われる際などに、リソースの設定や運用、スケーリングにおいて柔軟性と効率性を提供することが可能になります。マネージドサービスは、セキュリティやパフォーマンスの向上を支援し、リソースの最適な利用を確保します。スコープの変更に伴う新たな要件に対応し、リソースを迅速かつ適切に調整する際に、貴重な時間とリソースを節約できます。これにより、システムやプロダクトの柔軟性を高め、効率性を向上させることが可能となります。 アジャイル開発およびPoCの早期実施を活用したスケジュール管理 スケジュール管理は、プロジェクトの進捗を計画し、タスクや活動を時間的に配置する重要な要素です。クラウド導入プロジェクトにおけるスケジュール管理では、以下の内容について考慮することが重要です。 アジャイル開発の活用 ：クラウドは短期間で機能を構築できる特性を持ちます。開発手法としてウォーターフォール開発だけで進めるのではなく、 アジャイル開発 やハイブリッド開発を採用することで、スケジュールを柔軟に調整でき、ビジネス要件や市場の変化に素早く対応できます。アジャイルのイテレーションと迅速な反応性により、プロジェクトの進行状況を継続的に改善し、新たな要求事項を迎え入れる柔軟性が生まれます。これにより、プロジェクトの成功確率が向上し、リソースの最適活用とスケジュールの合理的な達成が実現できます。アジャイル開発は、クラウド導入プロジェクトの効果的なスケジュール管理はもちろんのこと、柔軟なベースライン管理全般に貢献します。 PoC（Proof of Concept）の早期実施 ：クラウドの特性を活用し、実際の環境でのPoCは机上検証よりも有益です。早い段階で実環境を用いたPoCを行うことで、システムやアプリケーションの適合性やスケジュールの実現性をより早く、確実に確認できます。これにより、問題や課題を早期に発見し、修正できるため、プロジェクトの進行におけるリスクを最小化できます。PoCの早期実施は、クラウド導入プロジェクトの成功に向けたスケジュール管理戦略の重要な要素であり、計画の実現可能性を向上させます。 クラウドの特徴を活かす柔軟なコスト管理 コスト管理はプロジェクトにかかる費用が予算内に収まるよう効果的に管理する重要な要素です。クラウド導入プロジェクトにおけるコスト管理では、以下の内容について考慮することが重要です。 リソース配置の最適化と過剰なリソース割当の回避 ：クラウドは必要なリソースを必要なタイミングで提供できる特性を備えています。このため、過剰なリソース割当を防ぐために、必要な時にのみリソースを起動し、利用しない時はリソースを停止するなど、クラウドの柔軟性を最大限に活用したコスト管理が肝要です。これにより、不必要なコストを削減し、プロジェクトのコスト効率を向上させることができます。また、リソースのモニタリングと適切なスケジュールの設定により、コストを最小限に抑えながら、プロジェクトの成功を支えることができます。 コストの柔軟な管理と関係者の合意 ：クラウドを活用したプロジェクトでは、開発進捗、試行検証、仕様変更等によるコストの変動が予想されます。このため、厳密な予算遵守よりも柔軟なコスト管理が必要です。状況に応じて予算を調整し、 コスト最適化 に向けて、事前に関係者との合意を得ることが重要です。合意を得ることで、プロジェクトの進行への影響を回避するために、予算変更やリソースの調整がスムーズに実施できます。この柔軟なアプローチは、クラウド導入プロジェクトにおいて予測困難な状況に、迅速に対処するための重要な手段であり、関係者の協力と合意を得ることで、コスト管理の効果を高めます。 まとめ クラウド導入プロジェクトにおいて、クラウド活用の真価である価値創造により集中するために、柔軟なスコープ変更に対応可能なコスト管理、アジャイル開発やPoC等を積極的に活用したスケジュール管理、リソースの最適配置による柔軟なコスト管理を含んだ、柔軟なベースライン管理が重要です。これらの要素は、プロジェクトの効率化と成功に焦点を当て、価値を最大化します。本ブログで整理した考慮点を参考に、クラウド導入プロジェクトの成功につなげていただければ幸いです。 参考リンク 第１回：プロジェクトの立ち上げ 第２回：柔軟なベースライン管理

この記事は Serverless containers at AWS re:Invent 2023 (記事公開日: 2023 年 11 月 9 日) を翻訳したものです。 AWS re:Invent は、AWS によるクラウドコンピューティングに関する世界規模の「学習型」カンファレンスです。今年は、 Amazon Elastic Container Service (Amazon ECS) と AWS Fargate のサービスチームが、生産性の向上、コストの最適化、ビジネスの俊敏性の向上に役立つベストプラクティスやヒントを共有します。ぜひ 11 月 27 日から 12 月 1 日まで (PST: 米国太平洋標準時)、ラスベガスにてご参加ください。 Expo ホール の Amazon ECS キオスクまたは AWS モダンアプリケーションとオープンソースゾーン にいらしてください。AWS でのモダンアプリケーションの構築についてエキスパートに質問したり、デモンストレーションを見たり、またオープンソースチームと会うことができます。ぜひお立ち寄りいただき、挨拶を交わし、楽しんで、おやつを食べて、クレーンゲームマシンから賞品を獲得しましょう！ 参加型セッション 例年同様、カンファレンスではさまざまな形式でのセッションが提供されます。 ブレイクアウトセッション：AWS のエキスパート、開発者、お客様による講義形式のプレゼンテーションです。 ワークショップ：新しいテクノロジーを学ぶのに役立つハンズオン形式での学習セッションです。参加には自身のラップトップを持参してください。 チョークトーク：さまざまなトピックのエキスパートによる対話形式のセッションです。ぜひ自分の経験やフィードバックを共有してください。 開発者向けセッション：AWS のエキスパートが主導する小規模なセッションで、自身のラップトップでプロジェクトを構築します。 ブレイクアウトセッション CON205 | Amazon ECS でビジネスアプリケーションを強化しよう 11 月 28 日 (火) 9:00 am JST | (Nov 27, 4:00 pm PST, Caesars Forum, Level 1, Summit 214) Amazon ECS はフルマネージドのコンテナオーケストレーションサービスで、安全性、信頼性、拡張性に優れたコンテナをよりシンプルに実行できます。Amazon ECS の GM であるNick Coult が、重要なビジネスアプリケーションを Amazon ECS を使用することでどのように強化できるかについて説明します。Amazon ECS と AWS Fargate の最新の進歩について学び、モダナイゼーションの目標をより迅速に達成するのにお役立てください。また、ユナイテッド航空が Amazon ECS を使用してどのようにモノリシックなアプリケーションをマイクロサービスに移行し、アプリケーションをモダナイズして目覚ましい成果を上げたかをご覧ください。 CON320 | AWS のサーバーレスサービスで未来を構築する 11 月 30 日 (木) 6:00 am JST | (Nov 29, 1:00 pm PST, Wynn, Level 1, Lafite 4) AWS のサーバーレスサービスは、企業がアイデアを本番環境に出すまでの道のりを短縮し、最新のアプリケーションを大規模に構築して実行できるようにすると同時に、コストを削減して俊敏性を高めるのに役立ちます。企業がビジネスで優れた成果を達成するのを支援するために、AWS がサーバーレスコンピューティングとコンテナで行っているイノベーションについて AWS のサーバーレスコンピューティングのバイスプレジデントである Holly Mesrobian が話します。 AWS Lambda 、 Amazon EventBridge 、 AWS Step Functions 、Amazon ECS on AWS Fargate などにおける新たな進歩や最近のリリースについて学んでください。企業が AWS の運用上の優位性を活用して、近代化の目標をより迅速に達成できる方法を学びましょう CON209 | AWS App Runnerによるコストとパフォーマンスの最適化 12 月 1日 (金) 09:00 am JST | (Nov 30, 4:00 pm PST, Wynn, Level 1, Lafite 9) コンピューティングコストは、企業がワークロードをどこにどのようにデプロイするかを評価する一般的な検討項目です。このセッションでは、 AWS App Runner のフルマネージド機能を使用して、総所有コストを削減し、アプリケーションの俊敏性を向上させる方法を紹介します。このセッションでは、自動スケーリング、継続的デプロイ、マネージドランタイムバージョンについて説明します。AWS App Runner が行うコードからのデプロイや、インフラストラクチャの管理、オーバーヘッドの削減方法の具体例をご覧ください。さらに、AWS App Runner によるパフォーマンスチューニングに関するエキスパートのガイダンスを受けて、アプリケーションの効率的な実行を支援します。 CON303 | サーバーレスコンテナを使用した生成系 AI アプリを大規模かつ効率的にデプロイ 11 月28 日(火) 10:30 am JST | (Nov 27, 5:30 pm PST, Caesars Forum, Level 1, Forum 113) さまざまなビジネスユースケースの課題を解決するために、LLM モデルの導入を検討する企業が増えています。このセッションでは Amazon ECS on AWS Fargate での CPU 推論、Amazon ECS on Amazon Elastic Compute Cloud (Amazon EC2) での GPU と Inf1 による高速推論、および関連するストレージとネットワーキングのオプションなど、Amazon ECS を使用して LLM モデルをデプロイするのに役立つさまざまなインフラストラクチャオプションと統合について説明します。 CON307 | コンテナイメージの遅延読み込みによる AWS Fargate の起動時間の短縮 11 月 29 日(水) 4:00 am JST | (Nov 28, 11:00 am PST, Mandalay Bay, Level 3, South, Jasmine H) このセッションでは、Seekable OCI (SOCI) について Dive Deep します。AWS Fargate で SOCI インデックスを使用することで、Amazon ECS タスクの起動にかかる時間を大幅に短縮する方法をご覧ください。SOCI のベストプラクティスについて学び、適切なワークロードに SOCI を利用する方法を学び、既存の OCI コンテナイメージの SOCI インデックス作成を自動化するさまざまな方法を検討します。 CON313 | Amazon ECS と AWS Fargate へのマルチテナント SaaS アプリケーションのデプロイ 11 月 28 日 (火) 07:30 am JST | (Nov 27, 2:30 pm PST, Caesars Forum, Level 1, Forum 121) Amazon ECS で SaaS ソリューションを構築する傾向が高まっています。マルチテナントの SaaS アプリケーションを開発する際には、テナントの分離、テナントのオンボーディング、テナント固有のメータリング、監視、その他 SaaS に必要な側面など、複数の問題に対処する必要があります。このセッションでは、AWS Fargate にソリューションをデプロイする際にマルチテナントをどのように管理するかを探ります。 CON315 | Data-Aware アプリケーションを大規模に展開するためのストレージオプションの進歩 12 月 1 日 (金) 07:00 am JST | (Nov 30, 2:00 pm PST, MGM Grand, Level 1, Grand 120) 企業がコンピューティングにコンテナを幅広く採用しようとしている中、ビッグデータや ETL ジョブなどの一部のワークロードでは、既存のデータを取得して処理を実行し、処理されたデータをダウンストリームで使用できるように保存する必要があります。コンピューティング効率を最大化するために、これらのワークロードには大量のトランザクションとスループットをサポートするストレージが必要です。このセッションでは、基盤となるストレージの管理について心配することなく、データ処理とストレージを大量に消費するワークロードを大規模に実行する方法を詳しく見ていきます。 CON318 | 効率性の向上: AWS Fargate で 70% のコスト削減を実現する方法 11 月 29 日 (水) 07:30 am JST | (Nov 28, 2:30 pm PST, Mandalay Bay, Level 3, South, South Seas E) このセッションでは、大手エンタープライズ SaaS 企業が AWS Fargate と AWS Graviton を使用して、データ集約型のグリッドサービスをどのように変革したかをご覧ください。6 か月以内に 70% のコスト削減を実現し、ピーク時のトラフィックを 1,000 RPS から 50,000 RPS に増やしました。また AWS CodePipeline を使用して、デプロイ速度を週 1 回から毎日 2 回に増やした方法をご覧ください。拡張性と効率を向上させるためのセルベースのアーキテクチャ戦略をご覧ください。 CON322 | AWS Fargate への移行による TCO とダウンタイムの削減 11 月 30 日(木) 10:30 am JST | (Nov 29, 5:30 pm PST, Wynn, Level 1, Lafite 4) 大規模な金融サービス企業を含む多くの企業が、大規模なアプリケーションのモダナイゼーションを通じてクラウド対応のイノベーションの真っ只中にいます。これらの企業は、アプリケーションの拡張性、セキュリティ、運用効率を犠牲にすることなく、総所有コスト (TCO) を削減したいと考えていることがよくあります。このセッションでは、複雑な組織が段階的にサーバーレスコンテナに移行し、コスト負担を徐々に軽減するために利用したさまざまな方法 (AWS Fargate など) について説明します。規制の厳しい環境で全体的なコストを削減するために使用できるアーキテクチャ上の重要な決定事項とベストプラクティスについて説明します。 CON325｜Amazon ECS と AWS Fargateでコンテナ化されたワークロードを保護する 12 月 01 日 (金) 04:30 am JST | (Nov 30, 11:30 am PST, Wynn, Level 1, Lafleur 2) この本セッションでは、Amazon ECS と AWSクラウドの統合、AWS のセキュリティサービスの利用、AWS Fargate のシングルテナンシーアーキテクチャのメリットなど、コンテナ化されたワークロードを安全に実行するための概要を説明します。AWS Fargate のセキュリティに関する考慮事項に Dive Deep し、AWS Fargate の最新機能を使用して潜在的な脅威やイベントに対するセキュリティ体制を改善する方法を見つけてください。 CON401 | Amazon ECS のレジリエンスと可用性を深く掘り下げる 11 月 30 日 (木) 02:30 am JST | (Nov 29, 9:30 am PST, Mandalay Bay, Level 1, North, Islander G) すべてのアプリケーションのアーキテクチャは、基盤となるインフラストラクチャに依存しています。多くのアプリケーションアーキテクチャの基盤として Amazon ECS が選択されています。Amazon ECS がどのように構築されているか知っていますか? サービスを構築する際には、どのような設計上の考慮事項が必要ですか? Amazon ECS はシステム停止を最小限に抑えるのにどのように役立ちますか? このセッションでは、耐障害性と信頼性の高いアプリケーションをクラウドで実行するための要件に Amazon ECS がどのように対応できるかを学びます。Amazon ECS サービスのアーキテクチャ、設計、オペレーション方法が、アプリケーションの安全で回復力のある基盤をどのように提供しているかについて Dive Deep します。 ENT212 | Carrier Global が AWS 上の Windows コンテナで 40% の節約を実現した方法 12 月 1 日(金) 05:30 am JST | (Nov 30, 12:30 pm PST, MGM Grand, Level 3, Chairmans 370) このセッションでは、Carrier Global が AWS テクノロジーを使用して、レガシーな .NET コードをリファクタリングなしで最新のイベント駆動型アプリケーションに変換した方法について学びます。Amazon ECS 上の Windows コンテナを使用してアーキテクチャの最新化を実現し、機能提供の俊敏性を向上させた方法をご覧ください。また、Carrier Global がさまざまな AWS のサービスと機能を使用して Windows アプリケーションの実行コストを 40% 削減し、スケーリングのパフォーマンスを 70% 向上させた方法についても説明します。 チョークトーク (対話型セッション) CON314 | Amazon ECS によるモダンアプリケーション開発の高速化 11 月 29 日 (水) 07:30 am JST | 12 月 2日 (土) 03:30 am JST | (Nov 28, 2:30 pm PST, MGM Grand, Level 3, 301 | Dec 1, 10:30 am PST, Caesars Forum, Level 1, Forum 126) ベストプラクティスに基づいてアーキテクチャを構築することで、企業はパフォーマンスが高く、コスト効率が高く、安全なアプリケーションを構築できます。このチョークトークでは、 AWS Well-Architected Tool Framework に基づいた Amazon ECS のベストプラクティスについての洞察を提供します。Framework の各柱の重要なベストプラクティスを確認した後、ホワイトボードの例を通じて、これらのベストプラクティスが実際に Amazon ECS ワークロードにどのように適用されているかを確認してください。 CON316 | Amazon ECS オートスケーリング Deep Dive 11 月 28 日 (火) 07:30 am JST | 11 月 30 日 (木) 12:00 pm JST | (Nov 27, 2:30 pm PST, Caesars Forum, Level 1, Forum 104 | Nov 29, 7:00 pm PST, Caesars Forum, Level 1, Forum 123) オートスケーリングは、Amazon ECS サービス内の必要なタスク数を自動的に増減する機能を提供する Amazon ECS の強力な機能です。このチョークトークでは、キャパシティプロバイダーなどの Amazon ECS のオートスケーリングメカニズムと、Amazon EC2 と AWS Fargate を対象とした、ターゲット追跡ポリシーやステップスケーリングポリシーを含む Amazon ECS サービスのオートスケーリング について学びます。さまざまなワークロードに特化したさまざまなメトリクスを使用して、Amazon ECS のオートスケーリングオプションを指定する実際の使用例について説明します。 CON317 | Amazon ECS ネットワーキング Deep Dive 11 月 30 日 (木) 05:00 am JST | (Nov 29, 12:00 pm PST, MGM Grand, Level 3, Premier 320) このチョークトークでは、さまざまなネットワークモードや、Amazon ECS Service Connect と Amazon ECS サービスディスカバリーを使用した Amazon ECS サービス間のネットワーキングなど、Amazon ECS のネットワークメカニズムについて Dive Deep します。 Amazon ECS on Amazon EC2 と Amazon ECS on AWS Fargate を使用した ENI トランキングと、セカンダリ CIDR を使用した IP 枯渇のような実際のユースケースと一般的な問題、およびそれを解決するさまざまな方法を聞くことができます。この講演では、AWS PrivateLink を使用した接続の実装とその利点についても説明します。 CON319 | AWS Fargate と AWS Lambda による生成系 AI のデータパイプラインの構築 11 月 30 日 (木) 03:00 am JST | (Nov 29, 10:00 am PST, MGM Grand, Level 3, 304) 生成系 AI アプリケーションの人気が高まるにつれ、リアルタイムデータとスケーラブルな計算能力が基盤モデルの構築の中核となり、さまざまな業界のビジネスの急速な発展を後押ししています。このチョークトークでは、特にコンテナ、サーバーレス、統合されたサービスにおけるデータとコンピューティングに焦点を当てています。次世代アプリケーションを構築するためのユースケースとサーバーレスおよびコンテナサービスの効果的な活用方法を探ります。実際のユースケースについて聞き、イベント駆動型アーキテクチャやサーバーレスストリーム処理などのさまざまなパターンと、 Amazon EMR がどのようにアプリケーションの操作を大幅に簡素化および自動化できるかを確認してください。 CON321 | コンテナ化されたワークロードを AWS Fargate に移行する 11 月 29 日 (水) 06:00 am JST | (Nov 28, 1:00 pm PST, Caesars Forum, Level 1, Summit 221) AWS Fargate は、企業がコンテナワークロードのデプロイとモニタリングのオペレーション負担を軽減し、アプリケーションの構築とビジネスの運営に集中できるようにします。このチョークトークでは、Amazon EC2 から Amazon ECS 上で稼働する AWS Fargate サーバーレスコンピューティングにワークロードを移行する際の設計上の考慮事項について説明します。 CON323 | AWS Fargate サーバーレスアプリケーションのオブザーバビリティの実装 11 月 29 日 (水) 09:00 am JST | (Nov 28, 4:00 pm PST, MGM Grand, Level 3, Premier 320) AWS Fargate でコンテナ化されたワークロードが拡張するにつれて、効果的なオブザーバビリティを維持することはますます困難になっています。このチョークトークでは、AWS Fargate へのデプロイでオブザーバビリティをスケーリングするための戦略とベストプラクティスを検討します。メトリクスの収集、ログの集約、分析の最適化など、モニタリングとロギングを大規模に管理する方法をご紹介します。コンテナ中心のモニタリング手法、効率的なログ管理、および Amazon CloudWatch Logs、AWS Lambda、 AWS Glue などの AWS サービスの活用方法について詳しく説明します。 CON336 | AWS App Runner を使用して、ゼロから本番環境にアプリケーションを数分で作成する 12 月 1日 (金) 08:30 am JST | (Nov 30, 3:30 pm PST, Mandalay Bay, Level 1, North, South Pacific D) AWS App Runner を利用し、既存のアプリケーションを本番環境へ数分で変換する方法をご紹介します。このチョークトークでは、デプロイメント戦略、ネットワーク管理、秘密情報と設定の安全な取り扱いにおけるベストプラクティスを順守しながら、コンテナ化とデプロイのシームレスなプロセスをガイドします。AWS App Runner によって、アプリケーションを簡単に最新化し、AWS クラウドインフラストラクチャの潜在能力を最大限に活用して、市場投入までの時間と運用のオーバーヘッドを削減する方法をご覧ください。AWS App Runner を活用して、ゼロから本番環境に対応したアプリケーションへの移行を加速させましょう。 CON407 | Amazon ECS サービスのデプロイのベストプラクティス 11 月 29 日 (水) 06:00 am JST | (Nov 28, 1:00 pm PST, Caesars Forum, Level 1, Academy 411) Amazon ECS サービスを使用して、アプリケーションをコンテナ化されたマイクロサービスとして実行する組織が増えています。このチョークトークでは、Amazon ECS を使用して新しいアプリケーションバージョンを安全かつ迅速にロールアウトするためのベストプラクティスを共有することに重点を置いています。説明には、Amazon ECS のデプロイに使用できるさまざまなツール ( AWS CloudFormation 、AWS CDK、Terraform、AWS コマンドラインインターフェイス ( AWS CLI )、 AWS マネジメントコンソール など) と、アプリケーションのタイプ (負荷分散型またはイベント駆動型) とインフラストラクチャプロバイダー (Amazon EC2 または AWS Fargate) に応じて使用できる保護手段のベストプラクティスが含まれます。 CON408 | Amazon ECS と AWS Fargate を使用してワークロードのスピードとコストの最適化 11 月 29 日 (水) 10:30 am JST | 11 月 30 日 (木) 09:30 am JST | (Nov 28, 5:30 pm PST, Wynn, Level 1, Latour 5 | Nov 29, 4:30 pm PST, Wynn, Level 1, Montrachet 1) AWS Fargate は世界中のミッションクリティカルなワークロードの実行基盤として信頼され、サーバーレスコンテナワークロードの最適化とチューニングに役立つさまざまな機能を提供しています。このチョークトークに参加して、SOCI によるイメージの遅延読み込み、 AWS Compute Optimizer によるコンテナの適切なサイズ設定、代替圧縮メカニズム ZSTD の使用などの新機能の使用方法を聞いてください。 ワークショップ CON201 | Amazon ECS と AWS Fargate で生成系 AI の可能性を解き放とう 11 月 30 日 (木) 08:00 am JST | (Nov 29, 3:00 pm PST, MGM Grand, Level 3, Premier 311) 生成系 AI は、デジタルビジネスのさまざまな側面に影響を与える可能性があります。このワークショップでは、AWS の生成系 AI サービスとサーバーレスコンテナサービスの力を組み合わせて、サンプルアプリケーションをゼロから構築する方法を学びます。このワークショップで学習したアプローチは、例えばアプリケーションログ、ドキュメント、顧客メモなど、さまざまな非構造化データにインテリジェントな検索および検出機能を追加するために使用できます。参加には自身のラップトップを持参する必要があります。 CON202 | AWS Fargate と Amazon EC2: どちらの起動タイプを使用すべきですか? 11 月 28 日 (火) 10:00 am JST | 11 月 30 日 (木) 05:00 am JST | 12 月 1 日 (金) 4:30 am JST | (Nov 27, 5:00 pm PST, MGM – Grand 117 | Nov 29, 12:00 pm PST, Venetian, Level 3, Lido 3006 | Nov 30, 11:30 am, Mandalay Bay, Breakers I) 多くの企業が AWS Fargate を選ぶ理由は、Amazon EC2 インスタンスを管理するための運用上のオーバーヘッドを取り除くことができることや、そのシンプルさと使いやすさにあります。ただし、AWS Fargate への移行がワークロードにどのように影響するかを尋ねるユーザーもいます。このワークショップでは、Amazon EC2 の CPU、メモリリクエスト、制限の設定を AWS Fargate と比較して調べ、ワークロードに適した起動タイプを決定するのに役立ちます。ワークロードが要求されたリソースの外部で動作する場合の動作の違いについて説明します。合成負荷生成を通じて実際のアプリケーションの動作をシミュレートすることで、さらに深く掘り下げることができます。参加には自身のラップトップを持参する必要があります。 CON304 | Amazon ECS と AWS Fargate のサービスディスカバリーオプションについて 11 月 28 日 (火) 07:00 am JST | (Nov 27, 2:00 pm, Wynn, Upper Level, Cristal 1) サービスディスカバリは AWS Fargate 上で、回復力があるスケーラブルなマイクロサービスを構築する上で重要な役割を果たします。Amazon ECS on AWS Fargate には複数のサービスディスカバリのオプションがあり、それぞれに独自の機能とトレードオフがあります。このワークショップでは、利用可能なさまざまなサービスディスカバリのオプションについて詳しく説明します。これらのオプションを比較し、意思決定に必要な情報を提供します。Amazon ECS Service Connect、 AWS Cloud Map 、 Application Load Balancer について、それぞれの利点、制限、ユースケースを検討します。実践的な例とベストプラクティスを通じて、さまざまなサービスディスカバリのオプションが、ダイナミックでコンテナ化された環境の管理をどのように簡素化するかを学びます。参加には自身のラップトップを持参する必要があります。 CON403 | Amazon ECS でコンテナイメージの遅延読み込みを実現する Seekable OCI (SOCI) 11 月 29 日 (水) 07:00 am JST | (Nov 28, 2:00 pm PST, MGM Grand, Level 1, Grand 123) Seekable OCI (SOCI) は、AWS がオープンソースで提供しているテクノロジーです。コンテナイメージのロードを遅延させることでコンテナをより高速に起動できるようにします。このワークショップでは、SOCI を実際に体験します。既存のコンテナイメージの SOCI インデックスを作成する方法と、AWS 上ででインデックス生成を自動化する方法について説明します。次に Amazon ECS on AWS Fargate にワークロードをデプロイする方法を学びます。コンテナイメージを遅延ロードすることで、起動時間がどのように短縮されるかを体験してください。参加には自身のラップトップを持参する必要があります。 開発者向けセッション CON301 | Amazon ECS でコストを最適化したワークロードを構築 11 月 28 日 (火) 07:30 am JST | 11 月 30 日 (木) 03:30 am JST | 12 月 01 日 (金) 06:00 am JST | 12 月 01 日 (金) 08:30 am JST | (Nov 27, 2:30 pm PST, Caesars Forum, Level 1, Alliance 315 | Nov 29, 10:30 am PST , Caesars Forum, Level 1, Alliance 311 | Nov 30, 1:00 pm PST, MGM, 350 | Nov 30, 3:30 pm PST, MGM, 353) コストの最適化はワークロードの設計や改善を行う際の重要な考慮事項です。このセッションでは Amazon ECS での請求をきめ細かく可視化し、適切なサイズのワークロードの実現を目指します。オートスケーリング、AWS Graviton、スポットインスタンスを使用してコストをさらに最適化する方法を探ります。このセッションは Amazon ECS への移行を始めたばかりの企業だけでなく、すでに本番レベルで Amazon ECS ワークロードを利用している企業にも適用できます。これらの概念をワークロードに適用できるようにすることを目的としたハンズオンセッションです。参加には自身のラップトップを持参する必要があります。 CON324 | Amazon ECS ワークロードでのデータ保護とコンプライアンス設計 11 月 28 日 (火) 07:30 am JST | 11 月 29 日 (水) 08:30 am JST | 11 月 30 日 (木) 09:30 am JST | 12 月 2 日 (土) 02:00 am JST | (Nov 27, 2:30 pm PST , MGM Grand, Level 1, Terrace 151 | Nov 28, 3:30 pm PST, Mandalay Bay, Surf A | Nov 29, 4:30 pm PST, Wynn, Level 1, Latour 7 | Dec 1, 9:00 am, Caesars Forum, Level 1, Academy 416) コンテナ化されたワークロードを実行している多くの企業は、保護対象の医療情報 (PHI) データを保護するための HIPAA プライバシー、およびセキュリティルールに関連するものを含む厳格なデータ保護およびコンプライアンス要件を満たしていることを確認する必要があります。このセッションでは Amazon ECS やその他の AWS サービスを使用して、 PHI を含むコンテナアプリケーションを実行する方法に焦点を当てます。Amazon ECS、Amazon ECR、AWS Fargate、 Amazon GuardDuty に関するベストプラクティスを学びましょう。参加には自身のラップトップを持参する必要があります。 直接参加できない場合は、基調講演とリーダーシップセッションのライブストリームに参加できます。 イベントに登録 して、バーチャル参加専用パスを選択できます。ブレイクアウトセッションは、イベント終了後に YouTube チャンネルで視聴できます。 これらのセッションの詳細や、AWS のエキスパートとのディスカッションに興味がある場合は、AWS 担当者にお問い合わせください。 re:Invent 2023でお会いできるのを楽しみにしています！その他の学習リソースについては、 Amazon ECS にアクセスしてください。 翻訳はソリューションアーキテクトの加治が担当しました。原文は こちら です。

このブログは Kumar Kumaraguruparan による “ Learn to build, train, and iterate machine learning models faster with new AWS course ” を翻訳+加筆修正したものです。 機械学習（Machine Learning: ML）が、潜在的な COVID ワクチン候補の数を数万から 26 に減らす上で重要な役割を果たしたことをご存知ですか ( PMC )？ ML によって生産性が向上することで、COVID ワクチンの開発においては多くの人々の命を救いました。 AWS クラウドでMLモデル構築のパフォーマンスを向上 パブリッククラウドにおける非構造化データ分析およびデータ管理市場は、2021年から2025年の間に41.9％の CAGR（年平均成長率）で成長すると予想されています ( IDC )。データは ML モデルを構築・チューニングするために必要です。ML モデル構築作業をクラウドに移行してデータの移動を減らすことで、モデル開発のスピードアップが期待できます。データや分析のワークロードがすでに AWS にある場合や、AWS クラウドサービスを検討している場合は、ML ワークロードを AWS クラウドに統合することでモデル構築のパフォーマンスを向上させることができます。 Amazon SageMaker Studio について Amazon SageMaker Studio は ML 専用の統合開発環境 (IDE) です。SageMaker Studio は、データの準備から、ML モデルのデプロイと監視まで、ML 開発のすべてのステップを実行でき、Web ベースのビジュアルインターフェイスで包括的なツールセットにアクセスできます。 2020 年の Anaconda 社によるデータサイエンスに関する調査 ( Anaconda Survey ) によると、回答者は仕事の時間の 66% がデータの読み込み、クレンジング、可視化に費やされていると答えています。データが指数関数的に増加し続ける中、データをより迅速に変換、分析、可視化するツールがさらに重要になっています。 SageMaker Studio と統合された SageMaker Data Wrangler では、300 種類以上の組み込み関数が利用でき、データ変換時間の短縮と、データに関するインサイトの生成を支援します。SageMaker Studio は、Amazon EMR クラスター上で実行されている Apache Spark と Studio ノートブックの統合による、大規模なデータ処理もサポートしています。また、AWS Glue Interactive Sessions が管理するサーバーレスの Apache Spark ランタイム環境を使用して、Studio ノートブックから、大規模データをインタラクティブに処理することもできます。 SageMaker Studio は、SageMaker Debugger によるモデルのデバッグとプロファイリングに役立つだけでなく、実験やトライアルに関連する詳細を自動的に追跡してグラフ化することで、データサイエンティストの生産性を向上させます。SageMaker Clarify を使用すると、データサイエンティストはデータやモデルのバイアスを特定し、特定の予測の理由（説明可能性）についてのインサイトを得ることができます。 これらの機能を活用するために必要なスキルを身に付けることは、オンプレミスの機械学習から AWS クラウドに移行する企業や、SageMaker を使用してクラウドネイティブソリューションを構築する企業にとって重要です。 3 日間の新クラスルームコースについて 「Amazon SageMaker Studio for Data Scientist」  は上級レベルの 3 日間のコースで、専門の AWS インストラクターと一緒にSageMaker Studio を使用して ML モデルをより迅速に構築、トレーニング、反復する方法を学習します。 トレーニングでは、ML タスクの時間を節約する 5 つの主要スキルを学ぶことができます。 SageMaker Data Wrangler の組み込み変換を使用して特徴量エンジニアリングを行い、SageMaker Feature Store を使用してそれらの特徴量を共有する方法 組み込みアルゴリズム、SageMaker AutoPilot、SageMaker Debugger、自動モデルチューニングを使用してモデルをより速く構築する方法 SageMaker Experiments を使用してモデルトレーニングに関連するさまざまなトライアルのパフォーマンスを比較し、SageMaker モデルレジストリでトラックする方法 SageMaker Clarify を使用してデータとモデル内のバイアスを特定する方法 SageMaker Pipelines を使用してモデル構築ワークフローを自動化する方法 このコースは、特徴量エンジニアリングからモデル構築、トレーニング、チューニング、そしてデプロイ、推論、モニタリングへと続く ML ライフサイクルをたどります。10 個のラボを通して、Amazon SageMaker Studio の 8 つの主要な機能について学びます。 さらに、AWS インストラクターのインタラクティブなセッションでは、SageMaker Studio ユーザーインターフェイス、SageMaker AutoPilot、および SageMaker Model Monitor などについても説明します。最後に、SageMaker Python SDK と SageMaker Studio についての理解度をテストするための 7 つのチャレンジを含んだハンズオンラボが用意されています。各課題の難易度を、ヒントなし、ヒントのみ、または詳細なガイド付きから選択できます。 このコースを最大限に活用するには、学習者に 1 年以上の ML の経験と Amazon SageMaker に関する基礎知識と、AWS の基礎知識があることをお勧めします。AWS Technical Essentials コースを修了することで、AWS の基礎知識の要件を満たすことができます。 ML の経験や Amazon SageMaker に関する基礎知識がない方は、事前に中級レベルの機械学習関連のコースを修了することもお勧めです。 中級レベルの機械学習関連コース The Machine Learning Pipeline on AWS このコースでは、機械学習 (ML) パイプラインを使用して、ビジネス上の問題を解決する方法を学びます。4日間のトレーニングは、機械学習の種類や、モデル・特徴量・アルゴリズムといった機械学習の基本の解説から始まり、問題の定式化、データの前処理、モデルトレーニングなどの機械学習パイプラインの各フェーズで発生するタスクと、タスクを実行するための Amazon SageMaker の機能を学ぶことができます。機械学習入門者や、Amazon SageMaker について詳しく学びたい方にお勧めのトレーニングです。本コースを受講することで、新コースの受講前提である ML の経験や Amazon SageMaker に関する基礎知識の習得が可能です。 Practical Data Science with Amazon SageMaker このコースは、顧客の解約を予測するというユースケースを題材に、Amazon SageMaker を使用したモデル構築、トレーニング、チューニング、およびデプロイの実践方法をハンズオン形式で学習します。コースの期間は1日で、既に機械学習の知識があり、Amazon SageMaker の機能を体験したい方や、機械学習モデルの開発を短時間で体験してみたい方にお勧めです。新コース受講の前提知識である SageMaker の基礎知識の習得にもお勧めです。 MLOps Engineering on AWS このコースは DevOps のプラクティスを機械学習に適用し、モデルの構築、トレーニング、およびデプロイを迅速化・効率化する方法を学習します。コースの期間は3日間です。新コースと比較すると、このコースの目標は MLOps に特化しており、MLOps が必要になる背景やメリットといった観点から、MLOps の組織・プラクティス・ツールに関するベストプラクティスをについて詳しく学ぶことができます。このコースには、オープンソースを含めた、複数の MLOps 自動化ソリューションについての比較も含まれています。 コース開催予定 本ブログの中で紹介している新コース「 Amazon SageMaker Studio for Data Scientists 」は、2024年2月から日本語クラスも提供開始予定です。Amazon SageMaker Studio を活用して、データサイエンスタスクの生産性を向上させる方法に興味がある方は、ぜひご受講を検討いただければと思います。AWS Training & Certification で開催日の検索とお申し込みが可能です ( 今後のコースの開催予定の検索 )。コースの期間は3日間、直近の開催は2024年2月、5 月で下記リンクからお申込みいただけます。お待ちしております。 2024/02/26 – 2024/02/28 2024/05/28 – 2024/05/30 この記事の執筆および翻訳は Technical Instructor の佐中晋が担当しました。

近年、世界中の機関や組織がランサムウェア攻撃の被害を受けています。医療機関も例外ではなく、ランサムウェアを用いた攻撃の標的となることがしばしばあります。 本ブログでは、医療機関でも被害が増えているランサムウェアとその被害からの復旧における重要な指標、バックアップを活用したデータ保護についてご紹介します。また、その中でバックアップや復旧において、ご活用いただける AWS のサービスや機能についてご紹介します。 ランサムウェアについて ランサムウェアとは、ビジネスに不可欠なデータへ不正にアクセスし、データの暗号化やアクセス遮断を行い、身代金を要求するようなマルウェアの一種です。 昨今では様々なタイプのランサムウェアが出てきており、ファイルを暗号化するだけでなくデバイス自体を暗号化するなど、ランサムウェアは継続的に変化する脅威として知られています。 デバイスやファイルを不正にロックされることにより、被害者はそれらのリソースへのアクセスが遮断されてしまいます。医療機関の場合、患者の診察履歴や投薬の記録といった、ミッションクリティカルなデータへのアクセスができなくなります。そのため、医療機関は、サイバー攻撃に備えた事業継続計画の策定が急務となっています。 また、攻撃者に対して身代金を支払う行為は、必ずしもデータが回復するとは限らず、攻撃者に対する支援につながるため、決して行ってはいけません。 ガイドラインに則ったソリューション構築におけるポイント整理 医療機関では電子カルテをはじめ、診療報酬請求のためのレセプトコンピューター、PACS (医用画像管理システム)、各種部門システム等多くの医療情報システムが稼働しています。日本におけるすべての医療行為は医療法等で医療機関等の管理者の責任で行うことが求められています。クラウドサービスを利用する場合も、医療情報システムの構築や運用に関連して、安全かつ適切な技術的及び運用管理方法を確立し、安全管理や e-文書法の要件等への対応を行っていく必要があります。具体的には 3 省 2 ガイドラインと称される、厚生労働省、総務省、経済産業省の 3 省が定めた医療情報システムに関する各ガイドラインに対して、関連事業者や責任者が要求事項を整理検討し、必要に応じて対策を施す必要があります。 医療機関及び医療情報システム事業者における 3 省 2 ガイドラインの位置付けについては、 医療情報ガイドラインの改定から読み解くクラウド化 | Amazon Web Services ブログ にて解説を行なっております。 医療情報の電子保存における要求事項の 3 基準 厚生労働省のガイドラインに記載されている医療情報の電子保存における要求事項の 3 基準には、「真正性」「見読性」「保存性」の 3 つがあります。各基準は以下のように定義されています。電子カルテのような医療情報を扱うシステムは、これらも考慮する必要があります。 真正性: 正当な権限で作成された記録に対し、虚偽入力、書き換え、消去及び混同が防止されており、かつ、第三者から見て作成の責任の所在が明確であること。 見読性 : 電子媒体に保存された対象を、「診療」「患者への説明」「監査」「訴訟」などの要求に応じて、それぞれの目的に対し支障のない応答時間やスループット、肉眼で見読可能な状態にできること。 保存性 : 記録された情報が法令などで定められた期間にわたって真正性を保ち、見読可能にできる状態で保存されること。 復旧における重要な指標 データの復旧には、目標復旧時点 (RPO) と目標復旧時間 (RTO) という 2 つの重要な指標が存在します。 RPO: データを過去のどの時点まで復旧させる必要があるかという指標です。例えば、ランサムウェアの被害においては、データの損失をどれだけ許容できるかに関連があります。 RTO: どれだけの時間で復旧を完了させるかを示す指標です。システムの停止時間やダウンタイムと関連があります。 バックアップ取得対象とするシステムの RPO や RTO を確認し、適切なバックアップ頻度で適切な復旧環境を検討できているかについて確認することが重要です。 ランサムウェア被害とRPO、RTOの関係性 バックアップと復旧戦略を考える上で、データ量とコストはトレードオフの関係であることに注意してください。優先すべき復旧対象データを特定し、RPO や RTO を明確にすることが、ビジネスの継続や復旧コストなどの観点から重要となってきます。 従来のバックアップ戦略 AWS サービスを紹介する前に、従来のバックアップ戦略について説明します。医療機関内で、各種のアプリケーションおよびデータベースサーバーが稼働しており、院内にある 1 次バックアップサーバーにバックアップが集約されることがよくあります。これらのバックアップを長期間テープストレージに書き出したり、遠隔地に 2 次バックアップサーバーを用意することで、物理的に隔離して保管されている場合もあります。しかし、このような仕組みは、増え続けるバックアップデータに対して、都度ストレージの追加が発生するなど、コスト効率の良いアプローチとは言えません。 これらの課題については、利用した分だけ料金が発生する従量課金という、クラウドならではの特徴を活かしたアプローチで解決することができます。 AWS ストレージサービスでの Immutable なデータ保護環境 ランサムウェア被害を受けた際のリカバリにおいては、保存されたデータは本当にランサムウェアの被害を受ける前の正しいデータかどうか疑われます。そのため、ランサムウェアに対応するためには、災害対策で考えられるような物理的な遠隔地に置かれるだけでなく、一度書いたら二度と上書きができないような、Immutable なストレージが必要です。Immutable とは、「変更不可能な」という意味で、一度作成したら、その状態を変えることができないということです。AWS のストレージサービスには Immutable を実現するための、Write Once Read Many (WORM) 機能を備えているものもあります。このように物理的に離して障壁（エアギャップ）を設けるだけでなく、Immutable な状態のように論理的な障壁 (ロジカルエアギャップ) を生じさせるような構成を、クラウドであれば容易に実装することが可能です。 ここからは、AWS のストレージサービスとその詳細を紹介します。 S3 Object Lock Amazon Simple Storage Service (Amazon S3) は、任意の量のデータの保存と取得をどこからでも行えるように設計されたオブジェクトストレージです。 S3 Object Lock は、WORM モデルを使用したオブジェクトの保存を可能にします。この機能を有効化することで、S3 上にアップロードされたオブジェクトに対する上書きや削除操作が行えなくなり、データの改ざん防止機能としてご利用いただくことができます。 医療機関の場合、例えば S3 上に保存している電子カルテのバックアップなどを、ランサムウェアによるデータ上書きや削除といった攻撃から保護することができます。 S3 バケットの作成時に詳細設定から S3 Object Lock を有効化するか、既存のバケットに対してはAWS サポートへの サポートケース の起票により有効化することができます。 Amazon S3 オブジェクトロックの設定画面 S3 Object Lock には、「ガバナンスモード」と「コンプライアンスモード」の2種類の保持モードが存在します。ガバナンスモードでは、特定の IAM アクセス許可を持つユーザー以外の上書きや削除操作から保護し、コンプライアンスモードでは、保持期間中はルートユーザーを含むすべてのユーザーの上書きや削除操作からオブジェクトを保護することができます。 ガバナンスモードとコンプライアンスモードの選択画面 また、デフォルトの保持期間を設定せずに、リーガルホールドの設定を行うことが可能です。リーガルホールドは、保持期間を設定していないので、上書きや削除操作から無期限に保護することができます。こちらを適用することで、IAM でリーガルホールドの権限が付与されたユーザーのみ、上書きや削除操作を許可するように設定することができます。 ガバナンスモードとコンプライアンスモードの場合、保持期間が終了した後は、リーガルホールドの設定を有効にしない限り、オブジェクトバージョンを上書きまたは削除することができます。 以上のように、S3 Object Lock を有効化することで、データを Immutable な状態で保存することができます。 より詳細な情報は、「 S3 オブジェクトロックの仕組み – Amazon Simple Storage Service 」や「 Amazon S3 オブジェクトロックによるデータの保護 | Amazon Web Services ブログ 」をご参照ください。 AWS Backup Vault Lock AWS Backup は、バックアップの一元管理と自動化を実現するフルマネージドサービスです。手動と自動スケジュールのバックアップを実施することができます。1 つのコンソールで、多岐にわたる AWS リソースのバックアップの設定と実行、復旧を実施することができ、一元管理することができます。暗号化した個別の Vault と呼ばれる単位でデータを格納することができるため、セキュリティを確保することもできます。Vault は、バックアップを保存および整理するためのコンテナです。 AWS Backup Vault Lock は AWS Backup のオプション機能で、対象の Valut を読み込み専用である WORM に設定することができます。この機能により、バックアップデータを変更できなくなるため、バックアップデータの暗号化といった、ランサムウェアによる悪意ある攻撃を防ぐことができます。また、不注意や誤操作によってバックアップが削除されることも防ぐことができるという利点もあります。 医療機関に限らず、ランサムウェア被害から復旧する際に利用するバックアップデータを、悪意ある上書きや削除から保護することができます。 AWS Buckup Vault の設定画面 AWS Backup Vault Lock 機能も、S3 Object Lock と同様に、特定の IAM 権限でのみ Vault に格納されたリカバリポイントを削除可能な「ガバナンスモード」と、ルートユーザーであったとしても Vault に格納されたリカバリポイントを削除できない「コンプライアンスモード」が用意されており、お客様の要件に合わせて選択することが可能です。また、リーガルホールドの機能も提供しており、保持期間が終了していても、明示的に解除されるまではバックアップの削除を防ぐことができます。 より詳細な情報は、「 AWS Backup Vault Lock – AWS Backup 」や「 AWS Backup | 一元管理型クラウドバックアップ | よくある質問 #Write-Once-Read-Many (WORM) 」をご参照ください。 EBS スナップショットゴミ箱機能のルールロック Amazon Elastic Block Store (Amazon EBS) は、EC2 インスタンスで使用するためのブロックレベルのストレージボリュームを提供します。 EBS スナップショット とは、Amazon EBSボリュームのデータを Amazon S3 にバックアップできます。そして、 EBS スナップショットゴミ箱 は、EBS スナップショット を誤って削除した場合でも、スナップショットを復旧できる機能です。ゴミ箱からの手作業での削除インターフェースは存在せず、ゴミ箱ルールに入れたものはゴミ箱ルールで指定された保持期間を迎えるまでは削除できません。 しかし、ランサムウェアや悪意を持った攻撃者は、ゴミ箱ルールを削除してからスナップショットを復元してデータを不正に取得し、それを削除するという方法でゴミ箱の回避を試みることもあり得ます。それを阻止することができる機能が、 EBS スナップショットのゴミ箱のルールロック です。これは、EBS スナップショットゴミ箱機能のルールを編集、削除することを防ぐ機能です。「ロック解除の遅延期間」を設定すると、その期間中は遅延期間を変更や削除ができない状態になります。 ルールがロックされると、保持ルールの編集もできなくなるため、保持しているゴミ箱内の EBS スナップショット の削除保護が実現できます。ルール自体の変更や削除ができないため、攻撃者は前述の手法でスナップショットを削除することができなくなります。 例えば、医療機関で本番運用している AWS アカウントの権限が侵害された場合、ロック解除の遅延期間を設けているため、その期間中は EBS スナップショットからデータを復旧できなくなることを心配せず、セキュリティ脅威を検出して対応するための時間を確保することができます。 ルールロックの設定画面 より詳細な情報は、「 保持ルールの操作 – Amazon Elastic Compute Cloud 」をご参照ください。 Amazon FSx for NetAPP ONTAP の SnapLock Amazon FSx for NetApp ONTAP は、ONTAP ファイルシステムの一般的な機能、パフォーマンス、API を AWS のフルマネージドサービスとして利用でき、AWS の俊敏性、スケーラビリティ、セキュリティ、および耐障害性を享受することができます。 SnapLock は、WORM を備えたボリュームを作成する ONTAP 機能で、指定された期間内のファイルの変更や削除を防止することができます。そのため、ランサムウェアや悪意を持った攻撃者によるデータの改ざんや削除から、データを保護することができます。 現在オンプレミスで利用中のファイルシステムがあり、AWS クラウド上に移行する場合、ランサムウェア被害に対策できるファイルストレージの移行先として検討することができます。 SnapLock の設定画面 SnapLock では、「コンプライアンスモード」と「エンタープライズモード」の 2 つのモードが用意されています。 コンプライアンスモードでは、保持期間が終了するまで、全てのユーザーはファイルの名前変更や削除操作を行うことができなくなります。 エンタープライズモードでは、コンプライアンスモードでボリュームを作成する前に、組織のデータ保持ポリシーや、保存設定をテストするために使用されます。このモードでは、承認されたユーザーのみに削除操作を許可することができます。また、有効な保存期間内の WORM ファイルが含まれていても、そのボリュームを削除することができます。 この機能は、既存のボリュームに対して有効化することができませんが、SnapLock が有効なボリュームを新規作成して、そのボリュームにデータをコピーすることはできます。 より詳細な情報は、「 新着情報 – 規制コンプライアンスとランサムウェア対策を目的として Amazon FSx for NetAPP ONTAP が WORM 保護のサポート提供を開始 | Amazon Web Services ブログ 」をご参照ください。 各サービスの機能の比較 今回ご紹介した、4 つのサービスの機能の比較表を以下に示します。 Amazon S3 AWS Backup ゴミ箱機能(EBS スナップショット) Amazon FSx for NetAPP ONTAP 名称 Object Lock Vault Lock Rule Lock SnapLock 保護対象リソース バージョニングされたオブジェクト リカバリポイント ゴミ箱内の EBS スナップショット ファイルとボリューム 設定対象リソース オブジェクトまたはバケット Vault ゴミ箱機能のリテンションルール SnapLockの設定はボリューム単位、リテンションの設定はファイル単位 リソース削除のタイミングとロックのリテンションの関係 ロックのリテンションとオブジェクトの削除は独立 ロックのリテンションとリカバリポイントが削除されるタイミングが同じ ロックのリテンションとゴミ箱からスナップショットが削除されるタイミングが同じ ロックのリテンションとファイルの削除は独立 実際に保護対象リソースが削除できるタイミング ロック解除後のライフサイクルなどで指定したタイミング Backup plan でのリテンション次第 ゴミ箱機能のリテンションルール次第 ロック解除後のファイルの標準的な削除タイミング ユースケース オブジェクトストレージである S3 上に保存している電子カルテのバックアップなどを、ランサムウェアによるデータ上書きや削除といった攻撃から保護 AWS上の各種リソースや、オンプレミスのVMware 仮想環境のバックアップで利用でき、ランサムウェア被害から復旧する際に利用するバックアップデータを、悪意ある上書きや削除から保護 既に EC2 で稼働している医療情報システムがあり、AWS アカウントの権限が侵害された場合、ロック解除の遅延期間中に EBS スナップショットからデータを復旧できなくなることを心配せず、セキュリティ脅威を検出して対応するための時間を確保 医用画像や文書ファイルを、ランサムウェア被害から保護することができるファイルストレージ ランサムウェア被害を対策する上では、ロックの保持期間やロック解除の遅延期間を適切に設定することが重要です。適切に設定するためには、セキュリティ侵害の特定と対応にかかる時間を見積り、それよりも長くする必要があり、過去のセキュリティインシデントやアカウント侵害の特定と修復に必要な時間を確認しなければなりません。一方で、お客様自身が意思をもって削除を試みたい場合、ロックの保持期間やロック解除の遅延期間が終了するのを待つ必要があり、その後にリソースの削除やルールの変更、もしくはルールの削除する必要があります。 まとめ 本ブログでは、ランサムウェアの脅威に備えるためのガイドラインの要点、復旧戦略を検討する上でのポイントとなる目標復旧時点と目標復旧時間についてお話ししました。また、バックアップのストレージとして AWS では S3 の Object Lock や AWS Backup の Vault Lock、EBS スナップショットゴミ箱機能のルールロック、Amazon FSx for NetAPP ONTAP の SnapLock がランサムウェア対策において有効であることを説明しました。 内閣サイバーセキュリティーセンターの NICS や 厚生労働省 、 情報処理機構 、 医療機関向けセキュリティ教育支援ポータルサイト など、各組織よりランサムウェア対策の特設ページが設けられています。最新の情報をご確認の上、対策を検討いただければ幸いです。 著者について 吉村 弘明 (Yoshimura, Hiroaki) は AWS Japan のソリューションアーキテクトです。週末は料理をしたり、美味しいご飯を求めて都内を歩いています。       片山 洋平 (Katayama, Yohei) は AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。

はじめに 日本の工作機械メーカー株式会社牧野フライス製作所（マキノ）は、5Gネットワークを介した自律走行搬送ロボット(Autonomous Mobile Robot, AMR)制御システムの立ち上げに5か月足らずで成功しました。マキノは、5GネットワークとAWS Wavelengthを使用して、移動するAMR と制御サーバー間の無線通信の安定性を向上させました。同社はパブリック 5G と AWS Wavelength を選択することで、プライベート 5G 環境を自社で構築する場合と比較して大幅なコスト削減を実現しました。 AWS Japan 主催の イベント にて、株式会社牧野フライス製作所 CIO 中野 義友 氏、情報システム部 志津里 淳 氏、開発本部 児玉 匠 氏 は、この先進的な取り組みのほぼ全てをマキノ社員による内製開発によって、わずか５ヶ月足らずの期間に実現したことを発表しました。このブログでは、マキノが取り組んだ課題と実装したソリューションについて説明します。 工場を走り働くロボット 一般的にマシニングセンタとして知られている装置では、さまざまな金属加工を実行するために、フライスやビットなどの重い工具を交換する必要があります。現在、これらの工具は人間の作業者によって手作業で置き換えられており、肉体的に厳しい労働を伴います。マキノは、工場内での工具の搬送や交換を自動化する AMR を自社で製造・販売しています。マキノのAMRにはLiDARセンサーが搭載されており、周囲の障害物を検知して自律的に移動することができます。作業現場の作業員や他のAMRと協力して作業できるように設計されています。 図1: マキノのAMR 図2：マキノのAMRはLiDARで周囲を認識できる 図 3: マキノの AMR ダッシュボードには LiDAR を使った自動マッピングが表示される 課題 マキノのAMRは制御サーバーから要求を受け取り、自律的に移動してその要求を処理します。これまで、マキノは AMR とサーバー間の通信に Wi-Fi を使用していました。サーバーは、HTTPSやWebRTCなどの複数のプロトコルを使用して要求メッセージをAMRに送信します。これには、安定した中断のない通信が必要でした。しかし、移動中の AMR とサーバー間の通信が不安定になることがありました。AMR が Wi-Fi アクセスポイントの圏外に移動して接続が切断されると、別のアクセスポイントへのハンドオーバーに時間がかかります。マキノは、Wi-Fiハンドオーバープロセスの遅延がこの不安定性の原因であると特定しました。これを解決するには、アクセスポイント間の安定したハンドオーバーが必要です。 図4: Wi-Fi アクセスポイント間ハンドオーバーの課題 5GはAMR制御アプリの安定した無線通信を実現する そこでマキノはWi-Fiの代わりに5Gネットワークを採用しました。5G通信は、移動中でもシームレスな接続を実現するように設計されているため、ロボットが動いているときでも基地局間の受け渡しがスムーズになります。 工場の屋内で5G通信を実現する方法はいくつかあります。たとえば、工場のオーナーは「ローカル5G」と呼ばれる独自のプライベート5Gネットワークを構築できます。マキノは、さまざまな無線通信方式の評価を行いました。具体的には、プライベート5Gとパブリック5Gの比較を行いました。 評価の末、マキノはパブリック5Gを選択した結果、コスト削減とリアルタイムでの安定した操作性の両方を実現しました。マキノは、5Gネットワークの導入に加えて、これまで工場にあったサーバーをパブリック5Gを用いたハイブリッドクラウドサービスであるAWS Wavelengthに移行しました。AWS のソリューションアーキテクトが マキノ の技術的課題の解決を支援しました。 図 5:  5G 通信を用いたソリューションの概要 マキノがパブリック 5G と AWS Wavelength を選んだ理由 AWS Wavelength は、モバイルキャリアが所有する 5G 基地局ネットワーク上の AWS リソースを使用して処理を行うサービスです。5G基地局のすぐ近くで処理を実行して応答できるため、AWS Wavelength は 5G 通信の低レイテンシー処理に最適です。日本の大手モバイルキャリアであるKDDIは、AWS Wavelengthをサポートしています。 図 6: AWS Wavelength マキノは以下の理由により、パブリック5GとAWS Wavelengthの組み合わせがWi-Fiやプライベート5Gよりも今回のユースケースに適した選択肢であると結論付けました。 ネットワークの安定性とパフォーマンス まず、マキノはモバイル接続における5G通信の優れたパフォーマンスに着目しました。同社は工場に5G基地局を設置し、ネットワークの安定性とパフォーマンスを評価し、移動するロボットが複数の5G基地局エリアで通信しても通信断が発生しないことを確認しました。その後、同社は通信パフォーマンスを測定しました。Wavelength Zone のインスタンスから AMR までのネットワークレイテンシーは 10 ～ 15 ミリ秒でした。また、VPN トンネル上で HTTPS を使用するアプリケーションで測定した場合でも、制御アプリケーションから AMR までの全体のレイテンシーは約 40 ミリ秒でした。これはマキノ の AMR を制御するメッセージを送信するに十分なレイテンシーの低さです。このAWS Wavelengthへの移行においてマキノはアプリケーションの最適化の効果よりも稼働開始までの期間を優先し、「リフト」アプローチ（大きな設計変更をしない移行戦略）を採用していますが、将来、アプリケーションを AWS Wavelength 用に最適化できれば、さらに通信レイテンシーを改善できる可能性があります。ネットワークスループットは、ダウンストリームの平均1.1 Gbps、アップストリームの平均140 Mbpsで測定され、マキノにとって満足のいく結果でした。 初期費用の削減 マキノは意思決定において特にコストを重視しました。パブリック5Gネットワークには、プライベート5Gネットワークの運用とは異なり、5G機器の構築と保守に費用をかける必要がない（通信事業者に任せられる）という利点があります。 保守性 パブリック5Gの場合、5G通信ネットワークを運用するためのライセンスを取得したり、専門家を雇ったりする必要はありません。パブリック5Gは一般的なスマートフォンでも使用できます。5G通信事業者は基地局を継続的にアップグレードしますが、プライベート5Gネットワークの所有者は自社の機器のアップグレードと修理に責任があります。 ロボットの遠隔監視と調査 これまで、AMRは工場内で監視および管理されていました。制御サーバーは工場内にあり、工場のLANに接続されていたため工場外からのAMR管理は不可能でした。しかし、パブリック5Gの活用により、マキノは遠隔管理が可能になり、AMRの運用をリモートで調査できるようになりました。AMRに問題が発生した場合、オペレーターはリモートで調査し、適切な措置を講じることができます。さらに、より詳細なログをリモートでリアルタイムに表示できるようになりました。 工場にサーバーを設置する必要がなくなる マキノは、AWS Wavelengthを使用することで、制御サーバーをAMRを納める工場に設置する必要をなくすことに成功しました。これにより、マキノからロボットを購入するお客様は、自社の工場内にサーバーインフラを設置する必要がなくなりました。これにより、マキノのお客様が高度なロボットを購入するプロセスが簡単になります。 AWS Wavelength によるネットワーク構成 図 7: ソリューションの AWS アーキテクチャ図 AMRの制御サーバーは Wavelength Zoneにあります。AMR とサーバーは、パブリック 5G ネットワークを介して通信します。制御用のタブレットとサーバーはインターネットを介して通信します。 マキノは AWS Wavelength を使用する際にいくつかの要素を考慮しました。 IPアドレス範囲 ：通常、工場の機器はプライベートIPアドレスを使用します。マキノのAMRには、特定のプライベートなIPアドレス範囲が必要でした。一方、AWS Wavelengthによって付与されるIPアドレスの範囲は、キャリア固有のグローバルIPアドレスで構成されます。 デバイス認証：  AWS Wavelength は、AWS IoT Core などの AMR デバイス認証用のマネージドサービスをサポートしていません。 図8: マキノのAMRをAWS Wavelengthとパブリック5Gネットワークで使用する際の考慮点 同社は慎重に検討した結果、これらの問題の解決策を見つけました。同社は Wavelength Zoneに VPN ルーターインスタンスを作成しました。VPN ルーターは各 AMR への VPN トンネルを確立し、AMR のプライベート IP アドレス範囲からの通信を可能にします。デバイス認証は、VPN トンネルの接続時にVPNのクライアント証明書を使用して行うことができます。 図 9: マキノの AMR を AWS Wavelengthとパブリック 5G ネットワークで利用するためのソリューション その結果、マキノは AWS Wavelength を使用して AMR やサーバーと安全に通信できるようになりました。 おわりに マキノはAMR 制御システムをパブリック 5G ネットワークと AWS Wavelength 上にわずか 5 か月足らずで構築し、次のようなメリットを得ました。 ネットワークの安定性とネットワークパフォーマンス 初期費用の削減 保守性 ロボットの遠隔監視と調査 工場内のサーバーレスAMRシステム マキノは、この新たなシステムを顧客に販売する予定です。そのために同社は、AWS上のアーキテクチャを最適化し、保守性と運用性をより迅速かつ容易にすることで、さらなる運用改善とネットワークパフォーマンスの向上できると考えています。 詳細はこちら AWS Japan イベントでのマキノのセッション マキノは、2022年4月7日に開催されたAWSイベントで、5GネットワークとAWS Wavelengthを使用したAMRとユースケースについて説明しています。 このブログ にはスライドとビデオ（日本語）が含まれています。 AWS Wavelength など、 AWS が提供するさまざまなハイブリッドサービスについて学ぶことで、ユーザーに適したソリューションを選択できます。これらのAWS ハイブリッドサービスによるスマートプロダクトソリューションを検討する際は、最適なソリューションを見つけるお手伝いをする AWS のソリューションアーキテクトにご依頼ください。 牧野フライス製作所 株式会社について 牧野フライス製作所は日本を拠点とするフライス盤・マシニングセンタメーカーです。同社は世界中に工場と営業所を持ちます。また、ロボットや先端技術を積極的に活用しています。 吉川晃平(Kohei Yoshikawa) 吉川は AWS Japan のシニアソリューションアーキテクトです。北海道大学の修士課程を卒業後、ソフトウェア開発者およびシステムインテグレーターとして20年以上従事しました。2020 年 12 月に AWS に入社し、日本の多くの製造業のお客様を支援してきました。週末はサイクリング、冬はスキーを楽しんでいます。 このブログは吉川による” Makino improves performance of Autonomous Mobile Robots with AWS Wavelength and 5G network “を和訳したものです。

私たちは AWS Supply Chain のイノベーションにより、サプライチェーンの未来に備えています。 私たちは、お客様の声に耳を傾け、お客様の課題を理解し、フィードバックを収集することで、お客様の立場に立って取り組むことでイノベーションを起こします。 このアプローチにより、当社のイノベーションがお客様のあらたなニーズに確実に対応できるようになります。 AWS Supply Chain は、サプライチェーンのリーダーがサプライチェーンの回復力を高めるため、リスクを軽減し、コストを削減してするのに役立つクラウドベースのアプリケーションです。 AWS Supply Chain は、サプライチェーンデータを統合し、機械学習 (ML) を活用したコネクタとアクションに繋がるインサイトを提供し、コンテキストに応じたコラボレーションを組み込みます。 在庫切れを減らすことで顧客サービスのレベルを高め、過剰在庫によるコストを削減できるように設計されています。 このブログ記事は、最近の AWS Supply Chain のリリースをまとめたものです。 ブログで紹介する機能は、お客様のフィードバックに基づいています。 需要計画における製品系統を使用した予測 AWS Supply Chain Demand Planning では、製品を 製品系統 と呼ばれる以前のバージョンまたは代替バージョンとリンクして、予測の精度を高めることができるようになりました。 製品とその以前のバージョンまたは代替製品との間にリンクを確立することで、プランナーは以前のモデルまたは類似製品の過去の売上データを利用して予測に役立てることができます。 この「代理履歴」は、より正確な需要予測の基礎を形成し、製品系統を通じて生成される予測が本質的に正確であることを保証し、それによって手動調整の必要性を最小限に抑えます。 需要計画の強化 需要予測は効率的なサプライチェーンの中心であるため、このプロセスを強化するために複数の機能を導入しました。 需要予測に 複数のオーバーライド を適用できるため、複数の製品にまたがった調整を同時に実施できます。 AWS Supply Chain Demand Planning の直感的な ユーザーインターフェイス が刷新され、予測設定が簡単になり、ワークフローが効率化されました。 予測における手動のオーバーライドを自動的に 保持 し、計画サイクル全体にわたって保持する一貫性があり効率的な予測が可能になります。 ユーザーエクスペリエンスとコンプライアンスの向上 私たちはシームレスなユーザー体験を提供することに全力を注いでいます。 AWS CloudTrail を AWS Supply Chain Demand Planning と 統合 しました。これにより、ガバナンスを常に監視を行い正常稼動を確実にし、透明性とコンプライアンスを向上させることができます。 新しい地域への可用性の拡張 各地でAWS Supply Chain に対する関心は高まり続けているため、提供地域を拡大しています。 現在、AWS Supply Chain はオーストラリア ( シドニー )、ヨーロッパ ( アイルランド )、米国東部 (バージニア北部)、米国西部 (オレゴン)、ヨーロッパ (フランクフルト) でご利用いただけます。 結論 今後数か月以内に、さらにエキサイティングなアップデートを発表する予定です。 これらの強化は、イノベーションへの注力と、お客様に価値を提供するという当社の取り組みによって推進されています。 AWS Supply Chain にアクセスして、詳細を確認して利用を開始しましょう。 また、 AWS Workshop Studio にアクセスして、インスタンスの作成、データの取り込み、ユーザーインターフェイスの操作、インサイトの作成、需要計画の生成に関する技術的な概要を自分のペースで確認することもできます。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Harold Abell は AWS Supply Chain のシニアプロダクトマネージャーです。 Harold は AWS Supply Chain の創立者プロダクトマネージャーの 1 人で、アプリケーションのコンセプトと設計に携わっています。 Harold は、ゼネラル・エレクトリック (GE) とアマゾンウェブサービス (AWS) の両方で、サプライチェーンとソフトウェア開発において 10 年以上の業界経験があります。 Harold はブリガム・ヤング大学を卒業し、製造工学の学士号と修士号、デューク大学のフクア・スクール・オブ・ビジネスで経営学修士号を取得しています。 余暇には、Harold は妻と3人の女の子とのスノースキーやボートなど、アウトドアのあらゆるものが大好きです。 Harini Kidambi は AWS Supply Chain Demand Planning のプロダクトマネージャーです。 BlueYonderとアマゾンウェブサービス (AWS) の両方でサプライチェーンと分析の分野で5年以上の経験があります。 彼女は AWS Supply Chain のお客様と協力して、お客様のビジネスニーズを理解し、技術ソリューションとユーザーエクスペリエンスを調整し、最大のビジネス価値を実現できるよう支援しています。 Vita Grebeniuk は AWS Supply Chain のシニアテクニカルプログラムマネージャーです。 Vita は、ソフトウェア開発とプログラム管理の分野で 10 年以上の経験があります。 現在の役職では、AWS Supply Chain のさまざまなワークストリームと連携して、製品の拡張や、お客様のビジネスの成長と複雑なサプライチェーンの課題の解決に役立つ重要な機能の立ち上げに取り組んでいます。 Vita はサイクリングやスキー、アメリカやカナダの旅行、ロードトリップも好きです。基本的には外で過ごす時間を増やし、家族をアクティブに保つためなら何でも好きです。 <!-- '"` -->

背景 生成系 AI の応用の幅が広がる技術としてマルチモーダルなモデルがあります。マルチモーダルではモデルの入出力に複数の異なるデータ形式を用いることができます。例えば Amazon Bedrock の Stable Diffusion ではテキストを入力に画像を生成することができます。画像とテキストという異なるデータ形式の入出力をするためマルチモーダルなモデルといえます。他にも入力した画像の説明文章をテキストとして出力できる BLIP-2 (Bootstrapping Language-Image Pre-training) と呼ばれるモデルもあり、AWS では Amazon SageMaker の推論 Endpoint にデプロイすることで利用することができます。詳しくは こちらのブログ をご覧ください。さらに、BLIP-2 は画像に対しキャプションをつけるタイプのモデルでしたが、対話形式で画像に対する問い合わせをすることができる MiniGPT-4 が生まれました。MiniGPT-4 は BLIP-2 の ViT (Vision Transformer) 、 Q-Former (Querying Transformer) と LLM (Large Language Models) を線形結合層で繋ぐことで実現されます。LLM を切り替える場合はこの線形結合層のみを再学習するため BLIP-2 や LLM 自体の再学習をしない分少ないパラメータを対象に再学習できるメリットがあります。 これらのように画像を入力にテキストを生成するモデルを Image to Text と呼びます。Image to Text のモデルを使えば、画像に対して説明を求めたり、QA することができるようになります。これを応用して、画像にタグを付与したり、テキストを入力に画像を検索したりできるようになります。従来の物体検出のような Computer Vision 技術で取得できた画像情報とは異なる情報を柔軟に取得できる可能性があります。どれくらいの情報が取得できるのか是非試したいですよね。 画像へ対話形式の問合せを日本語で試したい！と思っても、MiniGPT-4 は英語のモデルのため日本語には難があるかもしれません。そこに、MiniGPT-4 の線形結合層を日本語データで再学習した OSS の 日本語 LLM が発表されました。それが rinna株式会社の bilingual-gpt-neox-4b-minigpt4 です。今回は無料の Jupyter ノートブックサービスである SageMaker Studio Lab から bilingual-gpt-neox-4b-minigpt4 を利用して画像に対する QA に日本語で挑戦してみたいと思います。 制限事項 執筆時点で SageMaker Studio Lab には CPU と GPU いずれも 1 日あたり利用時間上限が決められています。また、閉域接続ではなくインターネットでご利用いただくサービスになります。好評いただいているサービスのため、特に GPU の利用時に一度では Start runtime できず複数回トライいただく場合があります。これらの特徴と上手にお付き合いいただきご利用いただければ嬉しいです。 前準備 SageMaker Studio Lab は AWS アカウント不要の無料のノートブックサービスです。AWS アカウントがなくても利用でき、メールアドレスがあれば登録することができます。 こちらのブログ をご覧いただき登録を完了いただけると以降の手順がスムーズです。 SageMaker Studio Lab は 機械学習帳とも連携 しており、SageMaker Studio Lab を使ってすぐに機械学習のスキル獲得を始めていただく事ができます。 sagemaker-distribution を利用して永続化領域を節約 本ブログでは 公式の environment.yml ではなく、 sagemaker-distribution カーネルを利用する方法をお伝えします。これにより、SageMaker Studio Lab の永続化領域を有効利用することができ、SageMaker Studio への移行も簡単にすることができます。sagemaker-distribution は PyTorch、TensorFlow、Keras などの人気のあるライブラリがプリインストールされている環境を提供します。SageMaker Studio と SageMaker Stdio Lab の両方に互換性のある Pythonライブラリが 18 種類以上付属しています。この環境は永続的であり、SageMaker Studio Lab 利用者に割り当てられた 15 GB の空き容量を使用しません。詳しくは こちら をご覧ください。sagemaker-distribution カーネルは 2023 年 8 月に SageMaker Studio Lab で利用できるようになりました。 bilingual-gpt-neox-4b-minigpt4 のダウンロードと必要なライブラリのインストール こちらの作業は CPU モードで実行することで GPU 利用時間を節約しましょう。CPU と GPU の切り替えはログインページのラジオボタンからの切り替えになります。ノートブックの実行画面にはないため注意してください。 公式のダウンロード手順 に従い必要なファイルをダウンロードします。SageMaker Studio Lab から Terminal を起動し、以下を実行します。Terminal は画面左上のプラスボタンから Launch タブを開き、Terminal を選択することで起動できます。Blog 執筆時点では以下のコマンドとなっていました。最新のコマンドは こちらの URL からご確認ください。 git clone https://github.com/Vision-CAIR/MiniGPT-4.git cd ./MiniGPT-4 git checkout 22d8888 # latest version as of July 31, 2023. wget https://huggingface.co/rinna/bilingual-gpt-neox-4b-minigpt4/resolve/main/customized_mini_gpt4.py wget https://huggingface.co/rinna/bilingual-gpt-neox-4b-minigpt4/resolve/main/checkpoint.pth ダウンロードが終わったことを確認したら、元のモデルファイルを /tmp/model_data に保存するように customized_mini_gpt4.py に変更を加えます。元のままの場合、ユーザの永続化領域にモデルファイルが保存され容量を圧迫してしまうためです。111 行目以降の from_pretreined の引数に cache_dir = ‘/tmp/model_cache/’ を追加し、以下のように変更します。永続化領域を節約する効果は こちら をご覧ください。画面左側のファイル一覧からダブルクリックで customized_mini_gpt4.py の編集画面を開くことができます。 if self.low_resource: self.gpt_neox_model = CustomizedGPTNeoXForCausalLM.from_pretrained( gpt_neox_model, torch_dtype=torch.float16, load_in_8bit=True, device_map={'': device_8bit}, cache_dir = '/tmp/model_cache/' ) else: self.gpt_neox_model = CustomizedGPTNeoXForCausalLM.from_pretrained( gpt_neox_model, torch_dtype=torch.float16, cache_dir = '/tmp/model_cache/' ) それでは こちらのページ を参考にノートブックを作成していきましょう。作成された MiniGPT-4 ディレクトリに sample.ipynb を作成します。以降の作業は全て sample.ipynb に実装します。 画面左上のプラスボタンから sagemaker-distribution: Python を選択いただくとノートブックファイルを作成できます。ファイル名を sample.ipynb に変更してください。 作業中、sagemaker-distribution カーネルが選択されているかを確認する場合は、右上のカーネル選択にてsagemaker-distribution が選択されているかをご覧ください。 次に以下のコマンドをセルで実行してください。 !conda install -y -c conda-forge opencv !pip install omegaconf !pip install iopath !pip install timm !pip install webdataset !pip install transformers !pip install decord !pip install sentencepiece これで環境は整いました。 ノートブックで Image QA にトライ ここからは GPU モードで実行しましょう。移行の実装は公式の I/O Format と How to use the model のソースコードをセルに分割して書き下したものになります。 まずは、必要なモジュールを import します。以下のコードをセルに貼り付けて実行してください。 import torch import requests from PIL import Image from minigpt4.processors.blip_processors import Blip2ImageEvalProcessor from customized_mini_gpt4 import CustomizedMiniGPT4 GPU が利用可能かを以下のコマンドで確認しておきましょう。以下のコードをセルに貼り付けて実行してください。 torch.cuda.is_available() GPU モードで SageMaker Studio Lab を起動していても、torch の version と CUDA Driver が合わない場合、上記の結果は False が返ります。この場合、以降のコードは CPU で実行され期待動作しない場合がありますため注意が必要です。sagemaker-distribution カーネルを使えばこの問題は起きません。SageMaker-Distibution カーネルには SageMaker Studio Lab の GPU が使用できるバージョンの torch が予めプリインストールされているためです。もし False が返ってきた場合指定したカーネルが誤っている可能性がありますのでご確認ください。 次に、モデルを準備します。以下のコードをセルに貼り付けて実行してください。CustomizedMiniGPT4 はダウンロード手順で取得した customized_mini_gpt4.py の中に実装があります。興味がある方は是非確認してみてください。 checkpoint.pth は再学習した線型結合層のモデルファイルです。こちらも先ほどの手順でダウンロード済です。 model = CustomizedMiniGPT4(gpt_neox_model="rinna/bilingual-gpt-neox-4b") tokenizer = model.gpt_neox_tokenizer if torch.cuda.is_available(): model = model.to("cuda") ckpt_path = "./checkpoint.pth" if ckpt_path is not None: print("Load BLIP2-LLM Checkpoint: {}".format(ckpt_path)) ckpt = torch.load(ckpt_path, map_location="cpu") model.load_state_dict(ckpt['model'], strict=False) それでは、問合せ対象の画像を準備しましょう。以下のコードをセルに貼り付けて実行してください。ここでは huggingface にあるサンプル画像を利用します。猫が横たわっている画像が表示されれば成功です。 image_url = "https://huggingface.co/rinna/bilingual-gpt-neox-4b-minigpt4/resolve/main/sample.jpg" raw_image = Image.open(requests.get(image_url, stream=True).raw).convert('RGB') raw_image BLIP-2 を利用して画像をエンコードします。画像を数字列に変換する Embedding と呼ばれる手法です。この値とテキストを入力することで画像への問合せが可能となります。以下のコードをセルに貼り付けて実行してください。 vis_processor = Blip2ImageEvalProcessor() image = vis_processor(raw_image).unsqueeze(0).to(model.device) image_emb = model.encode_img(image) 以下は公式のサンプルプロンプトです。 に先ほどの Embedding した値が入ります。ユーザー/システムで話者を識別しています。以下のコードをセルに貼り付けて実行してください。 prompt の中身が表示されれば成功です。 prompt = [ { "speaker": "ユーザー", "text": "&lt;Img&gt;&lt;ImageHere&gt;&lt;/Img&gt; 何が写っていますか？" }, { "speaker": "システム", "text": "a cat on a table with a laptop" }, { "speaker": "ユーザー", "text": "猫はどんな体勢をしていますか？" }, ] prompt = [ f"{uttr['speaker']}: {uttr['text']}" for uttr in prompt ] prompt = "\n".join(prompt) prompt = ( prompt + "\n" + "システム: " ) print(prompt) 画像の Embedding に加えて、テキストも Embedding して、それらを組み合わせる処理をします。詳しくは、 customized_mini_gpt4.py の get_context_emb をご覧ください。以下のコードをセルに貼り付けて実行してください。 embs = model.get_context_emb(prompt, [image_emb]) さあ、最後に回答となるテキストを生成するコードです。 output に回答テキストが入ります。以下のコードをセルに貼り付けて実行してください。結果はどうなるでしょうか？ output_ids = model.gpt_neox_model.generate( inputs_embeds=embs, max_new_tokens=512, do_sample=True, temperature=1.0, top_p=0.85, pad_token_id=tokenizer.pad_token_id, bos_token_id=tokenizer.bos_token_id, eos_token_id=tokenizer.eos_token_id ) output = tokenizer.decode(output_ids.tolist()[0], skip_special_tokens=True) print(output) 出力例: うつ伏せ 以下に、著者が試してみた画像に対する対話型での QA を記載します。是非、皆さんのアイデアで試してみてください。 ユーザー: &lt;Img&gt;&lt;ImageHere&gt;&lt;/Img&gt; 何が写っていますか？ システム: 猫がテーブルの上のパソコンを眺めている ユーザー: 猫は何色？ システム: 白 ユーザー: 茶色に見えますが、白ですか? システム: 茶色 ユーザー: 猫可愛いですね。この猫の隣にあるのは何ですか? システム: パソコン ユーザー: このシーンの次には何が起きると思いますか? システム: パソコンが壊れる 最後に いかがでしたか？本ブログでは、日本語対応の OSS のモデルを利用して、画像に対して対話型で QA することに挑戦してみました。画像を変えてみたり、プロンプトを変えてみたりして結果を確認してみてください。また、 bilingual-gpt-neox-4b-minigpt4 の登場によって、日本語 LLM と学習用データを準備すれば線形結合層の再学習のみで日本語対応できる MiniGPT-4 が作れることが示されました。今後、登場する日本語 LLM の OSS を利用して皆さん独自のデータで再学習したい場合にも適用できる方式になります。是非、そちらにも挑戦いただければ嬉しいです。著者もどこかで実験し Blog にできればと考えています。 著者 中島 佑樹 西日本のお客様をメインで担当するソリューションアーキテクト。社会人博士を修了したことをきっかけに AIML を得意分野としている。 システム一般のテーマや Amazon Bedrock を用いた生成系 AI のシステム開発、Amazon SageMaker Studio Lab を用いた AIML への入門まで幅広く活動。

みなさんこんにちは！ アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクトの Yuan です。 2023 年 10 月 26 日に「第三十五回 アップデート紹介とちょっぴり DiveDeep する AWS の時間」をオンラインで開催しました。本イベントは、AWS の数あるアップデートの中から「すぐ使える、運用に役立つ、あったらいいなと思ってた、おもしろい、重要」なものをピックアップし、ちょっぴり DiveDeep してカジュアルな雰囲気でお伝えするイベントです。 今回は「Serverless 編」ということで、 実際に AWS の Serverless 関連サービスをご利用いただいているお客様から事例やサービスの機能についてご紹介頂きました。 今回も非常に多くの方にご参加いただきました。ご参加いただいた皆様、誠にありがとうございました。 実施内容 今回はいつもの 5 分間アップデート以外に、ゲストスピーカーの株式会社ゼンリンデータコムの 新谷 亮人様、株式会社 Serverless Operations の 金 仙優 様、Ragate 株式会社 久保 翔太 から AWS の Serverless サービスを用いたサービス構築・運用の事例についてご紹介頂きました。合計 1 時間半の中で盛りだくさんの内容でお送りしました。 本記事の中に資料や動画のリンクを記載しておりますので、ぜひご活用ください！ 当日参加したメンバー アジェンダ 今月のお勧め 5 分間アップデート (5 分) スピーカー : アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 高橋 佑里子 今月の AWS のサービスアップデートを 5 分でご紹介しました。多くのアップデートの中から以下の 3 つをピックアップしました。 Amazon Bedrock が一般利用可能に ハンズオン (日本語) Generative AI Use Cases JP (日本語) AWS Lambda のバースト同時実行数のクォータが soft limit に Amazon OpenSearch Service が OpenSearch バージョン 2.9 をサポート開始 AWS の新着情報については 公式ページ のほか、毎週のアップデート情報をまとめて発信している 週刊 AWS を合わせてご覧頂くことがオススメです！ 100 台のサーバー運用からの脱却を目指して：初めての AWS サーバレス環境構築の裏側 (15 分) スピーカー : 株式会社ゼンリンデータコム 新谷 亮人 様 ゼンリンデータコムが長年にわたり提供する月間数億 PV の「店舗案内パッケージ」サービスが、AWS サーバーレスアーキテクチャとマイクロサービス化によりマルチテナント型の SaaS として進化しました。本セッションでは、15 年間で肥大化したモノリシックな環境からマイクロサービス・サーバレス環境への移行について、AWS のサービス選定、疎結合構成のメリット、AWS Lambda リリースや構成管理の課題などを失敗談も含めてご紹介します。サーバレス環境に興味はあるけれど踏み出せない、サーバレス導入を検討している方向けのセッションです。 人気番組の新作配信を安定起動させた、サーバーレスな AWS 分散負荷試験ソリューション「Distributed Load Testing」を使った負荷試験の仕組み (15 分) スピーカー : 株式会社 Serverless Operations COO 金 仙優 様 サーバーレス構成における「負荷試験」は、アクセススパイク時のパフォーマンス面のみならず、安定性、コストなど様々な面において最適化を行うための手段になります。このセッションでは、某人気番組が配信される度に激しいアクセススパイクに見舞われ、毎回サーバーが落ちていた VOD サービスを完全リニューアル、その番組の新作エピソードを問題なく配信できるまでの対応についてご説明します。特に、負荷試験で利用した AWS の分散負荷試験ソリューション「Distributed Load Testing」に焦点を当てて解説いたします。アクセススパイク以外でも、サーバーレスにおいて負荷試験を行う目的とメリットは多々ありますので、その点も合わせてお伝えしていきます。 【RDB 開発者向け】Amazon DynamoDB 設計ベストプラクティス事例紹介 (15 分) スピーカー : Ragate 株式会社 開発部プロジェクトマネージャー 久保 翔太 様 Amazon RDS とAmazon DynamoDB はどちらを選択するのが最適なのか。また、Amazon DynamoDB の設計のベストプラクティスに悩んでいる方向けに、自社の事例を交えて解説致します。 AWS マルチアカウント戦略を採用したサーバーレスアプリケーションの管理と運用 (15 分) スピーカー : 木村情報技術株式会社 システム開発本部 第三開発部 徳山 鐘三 様 AWS Lambda にて Docker ランタイムが利用できるようになったことにより、アプリケーション開発の自由度がより高まりました。またマルチアカウント戦略を取り入れることにより柔軟で管理しやすいアーキテクチャを実現する事ができます。 本セッションではマルチアカウント戦略を取り入れた上での Docker on Lambda を利用したサーバーレスアプリケーションのアーキテクチャや運用方法について、具体的な事例を交えて紹介します。 当日の様子 当日の内容を抜粋してご紹介します。 100 台のサーバー運用からの脱却を目指して：初めての AWS サーバレス環境構築の裏側 [ 資料 、 動画 ] こちらのセッションは株式会社ゼンリンデータコムプロダクト第一開発部シニアエンジニア新谷 亮人様より、15年以上歴史を持つ「店舗案内パッケージ」をサーバーレス構成にリニューアルする道と課題を紹介いただきました。「店舗案内パッケージ」はお客様が持つ店舗情報をホームページ上で案内したり、社内業務に利用したりする可能なサービスで、ビジネスの成長につれて、サーバー台数が100台を超え、パッチ適応などの運用負荷が高くなっていました。そこで、フロントエンドを Angular で SPA 化して、Amazon S3 にホスティングさせ、バックエンドは Amazon API Gateway、AWS Lambda、Amazon DynamoDB 及び Amazon CloudSearch を利用してサーバレス構成にリニューアルしました。そこで得られたメリット及び新たの課題も紹介されました。サーバレス構成を始めたい方には是非おすすめする内容です。 人気番組の新作配信を安定起動させた、サーバーレスな AWS 分散負荷試験ソリューション「Distributed Load Testing」を使った負荷試験の仕組み [ 資料 、 動画 ] 2 つ目のセッションでは、株式会社 Serverless Operations COO 金 仙優様より、サーバーレスな AWS 分散負荷試験ソリューション「Distributed Load Testing」を使った負荷試験の仕組みを紹介いただきました。負荷試験の基本的な考え方、サーバーレスで負荷試験を行うメリットを解説した上、AWS 公式展開している Distributed Load Testing on AWS ソリューション を活用して、動画配信サービスのサービス品質を安定させた事例を紹介しました。Distributed Load Testing on AWS で負荷試験を実施したことで、スパイクなトラフィックが発生した際の DynamoDB のホットパーティションニング問題を特定して解決しました。サーバーレスで負荷試験を実施したい方はぜひご確認ください。 【RDB 開発者向け】Amazon DynamoDB 設計ベストプラクティス事例紹介 [ 資料 、 動画 ] 3 つ目のセッションでは、Ragate 株式会社開発部プロジェクトマネージャー久保 翔太様より、Amazon DynamoDB 設計ベストプラクティスを紹介いただきました。Amazon DynamoDB はサーバーレスの大規模で高速なキーバリューデータベースですが、テーブル設計の考えは従来のリレーショナルデータベースと異なります。こちらのセッションでは RDB 開発者視点から Amazon DynamoDB を扱う際のテクニックと事例を紹介しました。Amazon DynamoDB のインデックスを設計する際の注意事項、実際のサービスにはどうモデリングしたのかの説明など有用な情報も含まれているので、これから Amazon DynamoDB を始めたい方には非常におすすめです。ご興味のある方はぜひご確認ください。 AWS マルチアカウント戦略を採用したサーバーレスアプリケーションの管理と運用&nbsp; [ 資料 、 動画 ] 最後のセッションでは、木村情報技術株式会社 システム開発本部第三開発部徳山 鐘三様より、AWS マルチアカウント戦略を採用したサーバーレスアプリケーションの管理と運用を紹介いただきました。こちらのセッションでは、木村情報技術株式会社様の Biznar の事例を中心に、実際に Ruby on Rails のアプリケーションを Docker on Lambda でサーバレス化した際の管理・運用、マルチアカウント戦略をとっていた際の経験を紹介しました。事例では、安価に Rails アプリケーションと同じ感覚でサーバーレスアプリケーションを構築できました。また、各テナントに独自の AWS アカウントを用意して、高い隔離性やアカウント別の請求を実現することができ、AWS Control Tower、AWS Config、AWS Security Hub でアカウント統制を行いました。Ruby on Rails のアプリケーションのサーバーレス化、マルチアカウントの運用を検討している方におすすめの内容です。ご興味のある方はぜひご覧いただきたいです。 いただいたご質問とその回答 「5 分間アップデート」について Q. 東京リージョンの Bedrock で ELYZA (llama2ベースの日本語学習 モデル) は使用できますか？ A. 東京リージョンの Bedrock で ELYZA は現在ご利用いただけません。ロードマップについて詳細はお伝えできませんが、llama 2 は近日公開予定となっております。 次回予告 次回は「Disaster Recovery 編」です。 ゲストスピーカーとして、株式会社マーズフラッグの 佐々木 崇之 様、エムオーテックス株式会社 の 立古 佳大 様、株式会社 Works Human Intelligence の 兒玉 拓也 様、株式会社ブイキューブの 岩上 蘭 様及び 中尾 真夕 様をお招きしまして、AWS での Disaster Recovery (DR) を中心に 4 セッションをご提供します。 次回も多くの方々のご参加を心よりお待ちしております！ 『アップデート紹介とちょっぴり DiveDeep する AWS の時間』の視聴申し込みでは複数月分をまとめてご選択頂くことが可能です！また、イベント開催直前にリマインドメールをお送りいたします。下記リンクから参加ご希望月の申し込みをお願いいたします。 第三十六回「アップデート紹介とちょっぴり DiveDeep する AWS の時間」- Disaster Recovery 編- 開催日時：2023 年 11 月 16 日（木）16:00 – 17:30 オンライン開催 アジェンダ 16:00 – 16:10 オープニングセッション 16:10 – 16:25 BCP の改善へ向けた可用性向上 ～Amazon RDS 周りを中心に～ スピーカー： 株式会社マーズフラッグ サービスプラットフォーム部、シニアエンジニア 佐々木 崇之 氏 16:25 – 16:40 ある日「DR やって？」と言われたら – 開発・運用現場が始める DR の第一歩 スピーカー： エムオーテックス株式会社 開発本部 サービス開発1部 サービス開発1課 SREグループ 立古 佳大 氏 16:40 – 16:45 Q&amp;A 16:45 – 17:00 コールドスタンバイによる DR 対策とフェールオーバーやフェールバックの定義について スピーカー： 株式会社 Works Human Intelligence Engineer 兒玉 拓也 氏 17:00 – 17:15 AWS マルチアカウント戦略を採用したサーバーレスアプリケーションの管理と運用 スピーカー： 株式会社ブイキューブ 技術本部 新規開発グループ インフラチーム 岩上 蘭 氏 スピーカー： 株式会社ブイキューブ 技術本部 新規開発グループ 開発チーム 中尾 真夕 氏 17:15 – 17:20 Q&amp;A 17:20 – 17:30 クロージングセッション このブログの著者 袁 嘉希 ( Yuan Jiaxi ) ソリューションアーキテクトとして ISV/SaaS 系のお客様の技術支援を行っております。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 最近急に寒くなってきましたね。近年はこの季節になると技術系のアドベントカレンダーが作られることが多くなっていますが、AWSに関連するアドベントカレンダーも色々とありますので、いくつか紹介します。 – Amazon Bedrock Advent Calendar 2023 – Anthropic Claude Advent Calendar 2023 – AWS Analytics Advent Calendar 2023 – AWS CDK Advent Calendar 2023 – AWS Lambda と Serverless Advent Calendar 2023 興味のあるジャンルにぜひ気軽に参加してみてください。 それでは、先週の主なアップデートについて振り返っていきましょう。今週は発表が多めでしたので、本稿で取り上げる数も少し多くなっています。そのため、説明はできるだけ簡素にしています。 2023年11月6日週の主要なアップデート 11/6(月) AWS Lambda supports faster polling scale-up rate for Amazon SQS as an event source Amazon SQSをイベントソースにした場合の AWS Lambda の同時実行数が最大で300まで増加可能になりました（旧来は60でした）。これにより、より大きいイベントのスパイクに対応できるようになりました。 Amazon MWAA now supports Apache Airflow version 2.7 and deferrable operators Amazon Managed Workflows for Apache Airflow (MWAA) で Apache Airflow version 2.7 環境が利用可能になりました。合わせて(Airflow 2.2から導入されていた) deferrable operatorもMWAAで利用可能になりました。deferrable operatorは、何か外部タスク等の完了を待つ必要がある際に、完了するまでの間ワーカースロットを開放して他のジョブにあてるための仕組です。 詳細はこちらのブログをご覧ください 。 AWS Fargate now enables Amazon ECS tasks to selectively leverage SOCI Amazon ECS ＋ AWS Fargate の環境においてSOCIの利用がより柔軟になりました。これまでは（重い）コンテナイメージをLazy loadしたい場合はECSのタスク定義内のコンテナイメージすべてにSOCI(インデックス)を作成しておく必要がありましたが、この改善によりLazy LoadしたいコンテナイメージのみにSOCIを準備するだけで良くなりました。 11/7(火) Amazon ElastiCache now supports network-optimized C7gn Graviton3-based nodes Amazon ElastiCache で Graviton3 ベースの C7gn ノードを利用可能になりました。ElastiCache C7gn ノードは第5世代 AWS Nitro Card を活用してより高いネットワークバンド幅を提供します。 AWS announces general availability of Amazon Aurora MySQL zero-ETL integration with Amazon Redshift Amazon Aurora MySQL zero-ETL integration with Amazon Redshift&nbsp;がGA(一般提供開始)になりました。東京リージョンでも利用可能になっています。この機能は、Aurora MySQL の表の更新をニアリアルタイムでRedshiftにレプリケーションする仕組みで、ETLインフラの構築不要で利用できます。また、Zero-ETL機能自体の費用は無料です。 本機能が対応している Aurora は Amazon Aurora Serverless v2 (MySQL) もしくはプロビジョン型のAurora MySQLで、Redshift側は、Amazon Redshift Serverlessもしくはプロビジョン型のAmazon Redshift RA3インスタンスです。 詳細はこちらのブログをご覧ください 。 11/8(水) Amazon Kinesis Video Streams WebRTC Ingestion is now generally available Amazon Kinesis Video Streams のWebRTCインテグレーションがGA(一般提供開始)になりました。本機能を使うことで、WebRTCに準拠したIoT機器、ブラウザ等からのデータを容易にKinesis Video Streamsに渡すことが可能になります。 AWS announces Amazon Aurora PostgreSQL Optimized Reads Amazon Aurora PostgreSQLで、Optimized Reads機能が利用可能になりました。これは内蔵のNMVe SSDをキャッシュとして活用することで読み取り性能を改善するものです。db.r6gd、db.r6idインスタンスで利用可能です。 QuickSight launches FLOAT data type support for SPICE datasets BIサービスの Amazon QuickSight にFLOAT型が追加されました。これまでもDECIMAL(固定小数点)が提供されていましたが、これは小数点以下の桁が4桁まででした。FLOAT(浮動小数点)はより小さい桁を扱う場合に適した型です。 11/9(木) Amazon SNS increases default FIFO topic throughput by 10x to 3,000 messages per second Amazon SNS の FIFO (First-In-First-Out)トピックの最大スループットが、従来の300メッセージ/秒から、10倍の3,000メッセージ/秒まで引き上げられました。 Amazon RDS for Oracle now supports Oracle Multitenant Amazon RDS for Oracle で Oracle Multitenant 構成が利用可能になりました。 Oracle Database 19c, 21c で利用可能です。Oracle Multitenant 構成を利用することで、ベースとなる multitenant container database (CDB) の中に複数のpluggable database (PDB)がホストできるようになります。 Amazon RDS for MySQL delivers up to 3X higher write throughput at no additional charge Amazon RDS for MySQL で MySQL 8.0.35 が利用可能になりました。8.0.35では前バージョンの8.0.34と比較して最大で3倍の書き込みスループットを実現しています。 Amazon OpenSearch Service introduces Neural Search Amazon OpenSearch Service で、Neural Searchが利用可能になりました。OpenSearch 2.9 以降で利用可能です。Neural Search はこれまでの OpenSearch を活用したベクトル検索を更に進化させた機能で、これまで外部で実行する必要のあったモデルによる処理を OpenSearch 内部で実行することで、ベクトル検索をワンストップで実行可能にします。 Amazon FSx for OpenZFS is now available in ten additional AWS Regions Amazon FSx for OpenZFS を利用可能なリージョンが追加され、大阪リージョンを含む10のリージョンで新たに利用可能になりました。これにより、大阪リージョンでAmazon FSx for NetApp Ontap, for OpenZFS, for Windows File Server, for Lustre の4種類全てが利用可能になりました。 Amazon SQS announces support for JSON protocol Amazon SQS の通信プロトコルとしてJSON protocolが利用可能になりました。これにより旧来のAWS Query protocolと比較してより短いレイテンシでの通信が可能になります。AWS SDKを最新バージョンに更新することで、JSON protocolがデフォルトで利用されるようになりますので、アプリケーションコードの変更は不要です。 Amazon Aurora Global Database for PostgreSQL now supports write forwarding Amazon Aurora Global Database for PostgreSQL でwrite forwardingが利用可能になりました(for MySQLでは以前より利用可能です)。write forwardingは、secondaryリージョンにて書き込みSQLが実行された際に、primaryリージョンに転送して実行するというものです。 AWS Lambda adds support for Amazon Linux 2023 AWS Lambda のマネージドランタイム、およびコンテナベースイメージとして、 Amazon Linux 2023 が利用可能になりました。 11/10(金) Amazon CloudFront announces unified security dashboard Amazon CloudFront のコンソールに、統合セキュリティダッシュボードが追加されました。例えば、AWS WAF への攻撃の状況等を一元的に確認することが可能です。 詳細はこちらのブログをご覧ください 。 最後に１つハンズオン資料の紹介を。お問い合わせいただく事が多い Generative AI (生成系 AI) に関するAWSサービスを体験するハンズオンが公開されています。社内データを活用したチャットボットや要約、文章校正、画像生成などの構築を体験することができます。興味がある方はぜひトライしてみてください。 – 生成系 AI 体験ワークショップ それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (twitter – @simosako )

本日 (2023 年 10 月 4 日) 、Amplify の GraphQL API 機能のための AWS Cloud Development Kit (CDK) コンストラクト を発表できることを嬉しく思います。Amplify の GraphQL API CDK コンストラクトを使用すると、単一の GraphQL スキーマ定義を使用して、 Amazon DynamoDB テーブルや AWS Lambda 関数などのデータソースをバックエンドとするリアルタイム GraphQL API を作成できます。( Construct Hub で見る) フロントエンド用の API を立ち上げるためには、開発者は API エンドポイント、カスタムビジネスロジック、データソースを構築して繋げ合わせるために、何千行もの反復的で差別化されないコードを書く必要があります。 AWS Amplify は、開発者が単一の定義ファイルでデータモデルを定義し、データソースの create, update, list, read, subscribe, delete のような一般的な API 操作をサポートするために必要な AWS リソースを自動的に生成できるようにすることで、この重労働を取り除きます。これまでは Amplify CLI でのみ利用可能でしたが、今回のアップデートでこの機能を AWS CDK に拡張します。 CDK Day 2023 の Amplify のセッションで、新しい Amplify GraphQL API コンストラクトのプレビューを皆さんにお見せしました。 新しい GraphQL API コンストラクトの詳細なツアーに参加しましょう！本記事では、フロントエンドのためのバックエンドを必要とし、AWS CDK を使っているお客様が利用できる 6 つの新機能にフォーカスします。 既存 CDK アプリやリソースとのシームレスな統合 リアルタイム API とデータスタックのための信頼できる唯一の情報源 簡単に始められ、拡張できる認可ルール 拡張可能なカスタム Query, Mutation, Subscription API 生成されたリソースを完全に制御する L2 および L1 コンストラクトへのエスケープハッチ リアルタイム機能のためのファーストクラスのクライアントライブラリサポート 1. 既存 CDK アプリやリソースとのシームレスな統合 新しい Amplify GraphQL API CDK コンストラクトは、既存 CDK アプリ内のドロップインコンポーネントとして使用できます。Lambda 関数のような既存のリソースとシームレスに統合できます。CDK のコンポーザブルアーキテクチャをベースに、手作りのリソースやインポートしたリソースを GraphQL API のデータソースとして使用しながら、Amplify の自動化された CRUD 操作、認可ルール、AWS AppSync によるリアルタイムのサブスクリプションの恩恵を受けることができます。新しい Amplify GraphQL API コンストラクトでは、CDK で開始し、CDK で反復し、CDK でデプロイします。 開始するには、既存 CDK アプリを使用するか、新しいアプリを作成します。 mkdir amplify-cdk-demo cd amplify-cdk-demo mkdir backend cd backend cdk init app --language=typescript 次に、以下のコマンドで新しい Amplify GraphQL API CDK コンストラクトと依存関係をインストールします。 npm install @aws-amplify/graphql-api-construct CDK アプリの lib/backend-stack.ts ファイルで、新しい Amplify GraphQL API コンストラクトをインポートして初期化します。 import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; import { AmplifyGraphqlApi, AmplifyGraphqlDefinition } from '@aws-amplify/graphql-api-construct'; import * as path from 'path' export class BackendStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); const amplifyApi = new AmplifyGraphqlApi(this, "MyNewApi", { definition: AmplifyGraphqlDefinition.fromFiles(path.join(__dirname, "schema.graphql")), authorizationModes: { defaultAuthorizationMode: 'API_KEY', apiKeyConfig: { expires: cdk.Duration.days(30) } } }) } } 上記のコードは、 schema.graphql に格納されたスキーマ定義に基づいて新しい API をインスタンス化し、API キーを API のデフォルト認証モードとして使用します。API キーの有効期限はデプロイ時から 30 日間です。 次に、 schema.graphql を新規作成し、データモデルと API の単一のソースとして使用します。 2. リアルタイム API とデータスタックのための信頼できる唯一の情報源 新しい Amplify GraphQL API コンストラクトでは、開発者はデータモデルを GraphQL スキーマ定義言語で定義し、DynamoDB テーブル ( @model ) 、Lambda 関数 ( @function ) 、OpenSearch クラスタ ( @searchable ) などの付随するデータソースを生成するためのディレクティブを使って拡張します。CDK コンストラクトは、Amplify CLI の既存の GraphQL Transformer 機能と完全に同等の機能を備えています。開発者は @auth ディレクティブを使用して API とデータをセキュアにすることができます。 @auth ディレクティブは、グローバル、モデルレベル、フィールドレベルの認可ルールを構成する機能だけでなく、デフォルトで拒否する認可を提供します。新しい CDK コンストラクトは、CDK コード内から Amplify によって生成されたすべてのリソースにアクセスし、カスタマイズする機能を備えており、拡張可能です。 以下のスキーマは Blog アプリケーションを記述しています。以下の GraphQL スキーマをアプリケーションにコピー &amp; ペーストしてください。 type Blog @model @auth(rules: [{ allow: public }]) { title: String content: String authors: [String] } 次に、CDK を使ってアプリケーションをデプロイし、プロンプトが表示されたら “y” と答えます。 cdk deploy デプロイが完了したら、AWS AppSync コンソールにアクセスして API を選択し、いくつかのテストクエリを実行します。作成クエリとリストクエリを実行して結果を確認してみましょう。 3. 簡単に始められ、拡張できる認可ルール 新しい Amplify GraphQL API CDK コンストラクトは、デフォルトの拒否ルールをすぐに提供することで、認可を簡単に始めることができます。API レベル、データモデルごと、あるいは個々のフィールドごとにきめ細かい認証ルールを追加することで、アクセス制御をさらにカスタマイズすることができます。Amplify は、ユーザー単位、複数ユーザー、グループ単位、複数グループによる特定のレコードへのアクセスなど、一般的な認証ルールを提供します。これらのルールは、Amazon Cognito または任意の OpenID Connect (OIDC) プロバイダで動作します。カスタムの認可パターンを実現するために、Lambda 関数を活用することもできます。この宣言的な認証モデルを使えば、アプリケーションの成長に合わせて拡張できる、堅牢なアクセス制御を得ることができます。 API をロックダウンして、一般ユーザーは全てのブログを読むことができるが、サインインしたユーザーはブログの作成、閲覧、更新、削除ができるようにしてみよう。まず、GraphQL スキーマを更新して、”public ” アクセスルールをスコープダウンし、新しい “owner” 認可ルールを追加しましょう。”owner” 認可ルールでは、ユーザーごとの認可を指定することができる。サインインしたユーザーが新しいレコードを作成すると、そのレコードは自動的にサインインしたユーザーをオーナーとして指定します。 type Blog @model @auth(rules: [ { allow: public, operations: [ read ] }, { allow: owner } ]) { title: String content: String authors: [String] } 認可ルールは以下のように定義されています。 Public (API キーを使用するユーザー ) はどのブログでも読むことができます。 Owner (Cognito 経由でサインインしたユーザー) は自分のブログを作成、閲覧、更新、削除できます。 注意 ：グループベースの認可やフィールドレベルの認可など、さらに高度な認可を追加できます。これによって、「Admins グループのメンバーにのみブログの削除を許可する」、「サインインした作者にのみ表示される新しい privateNotes フィールドを追加する」などのユースケースに拡張することが出来ます。認可機能の全範囲については、 ドキュメント を参照してください。 lib/backend-stack.ts の CDK コンストラクトプロパティを更新し、ユーザーのサインインとサインアップ管理に新しいユーザープールまたは既存のユーザープールを使用するようにしました。 import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; import { AmplifyGraphqlApi, AmplifyGraphqlDefinition } from '@aws-amplify/graphql-api-construct'; import * as path from 'path' import { UserPool, UserPoolClient } from 'aws-cdk-lib/aws-cognito'; export class BackendStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); const userPool = new UserPool(this, "MyNewUserPool") new UserPoolClient(this, "MyNewUserPoolClient", { userPool: userPool }) const amplifyApi = new AmplifyGraphqlApi(this, "MyNewApi", { definition: AmplifyGraphqlDefinition.fromFiles(path.join(__dirname, "schema.graphql")), authorizationModes: { defaultAuthorizationMode: 'API_KEY', apiKeyConfig: { expires: cdk.Duration.days(30) }, userPoolConfig: { userPool: userPool } } }) } } 以下のコマンドで最新のものを再度デプロイします。 cdk deploy デプロイ後、 Amazon Cognito ユーザプールコンソール でテストユーザーを作成します。 AppSync コンソール では API キーを使う、もしくはサインインしたユーザーとして、GraphQL クエリを実行してテストすることができます。 4. 拡張可能なカスタム Query, Mutation, Subscription API 基本的な CRUD 操作以外のカスタムビジネスロジックを実装する必要がありますか？Amplify GraphQL API CDK コンストラクトを使用することで、独自の Lambda 関数をトリガーするカスタム GraphQL リゾルバを簡単に定義できます。カスタム Query, Mutation, Subscription を追加して、検索、分析、メッセージングなどの特殊な API を実装します。カスタムデータタイプを定義して、レスポンスフォーマットを構造化します。RDS や 3rd Party のAPI など、あらゆるソースからデータにアクセスします。Amplify が GraphQL スキーマの生成、クライアントSDK の構築、およびそれらの繋込みを行うことで、お客様はカスタムロジックの作成に専念することが出来ます。GraphQL と AWS Lambda の柔軟性で API 機能を拡張しましょう。 例えば、ブログアプリケーションにシンプルな PubSub API 機能を構築するとします。読者はブログサイトに表示され、お互いにメッセージをライブ配信することができます。 まず、GraphQL スキーマを編集して、サインインしたユーザがメッセージを送信し、Subscription がメッセージを受信できるような Mutation を追加する必要があります。 type Blog @model @auth(rules: [ { allow: public, operations: [ read ] }, { allow: owner } ]) { title: String content: String authors: [String] } type Mutation { broadcastLiveMessage(message: String): String } type Subscription { subscribeToLiveMessages: String @aws_subscribe(mutations: ["broadcastLiveMessage"]) } @aws_subscribe ディレクティブは、 mutations 引数で指定されたすべての Mutations に対してリアルタイムの Subscription をセットアップします。 次に、 lib/backend-stack.ts の CDK コードに戻って、 broadcastLiveMessage Mutation からのメッセージを subscribeToLiveMessages Subscription に渡す JavaScript リゾルバを追加します。Amplify GraphQL API をインスタンス化した後、以下のコードを追加します。 const broadcastDataSource = amplifyApi.addNoneDataSource("BroadcastNone") amplifyApi.addResolver("BroadcastResolver", { dataSource: broadcastDataSource, typeName: 'Mutation', fieldName: 'broadcastLiveMessage', code: Code.fromAsset(path.join(__dirname, 'resolvers', 'broadcastLiveMessage.js')), runtime: FunctionRuntime.JS_1_0_0 }) 上記のコードでは、まず NONE データソースを作成し、API に新しいリゾルバを追加して broadcastLiveMessage Mutation を処理します。このタイプのデータソースは、アクションを他の AWSリソースと連携することなく、AppSync 内でローカルに解決したい場合に使用します。 broadcastLiveMessage Mutations を処理するために、新しい resolvers フォルダに broadcastLiveMessage.js を作成します。 resolvers/broadcastLiveMessage.js は、Mutation からのメッセージ引数を使用し、Subscription に結果としてそれを渡します。 export function request(ctx) { return { payload: { message: ctx.arguments.message } } } export function response(ctx) { return ctx.result.message } もう一度変更をデプロイしてみます。 cdk deploy それでは、2 つの AppSync コンソールウィンドウを開いて、変更を検証してみましょう。1 つは一般向けの Subscription で、もう 1 つは Mutations を送信するために使用します。 5. 生成されたリソースを完全に制御する L2 および L1 コンストラクトへのエスケープハッチ Amplify は、DynamoDB テーブルや Lambda 関数のような基本リソースのプロビジョニングをしますが、アプリケーションが成熟するにつれて、開発者はより深いアクセスが必要になってきます。CDK コンストラクトは、L2 および L1 CDK コンストラクトを通じて基礎となるリソースに直接アクセスするためのエスケープハッチを提供します。DynamoDB の課金モードを微調整したり、Lambda に VPC インタフェースを追加したり、OpenSearch インデックスを CDK でカスタマイズできます。 AppSync API や DynamoDB テーブルなど、生成されたすべてのリソースは、L2 コンストラクトとして .resources パラメータの下で利用可能です。 .resources.cfnResources 経由でアクセスすることで、生成されたリソースの L1 コンストラクトにさらにドロップダウンできます。例えば、基礎となる AppSync API で X-Ray トレースを有効にするには、L1 レベルにドロップダウンして必要な X-Ray トレースを設定します。 &gt;amplifyApi.resources.cfnResources.cfnGraphqlApi.xrayEnabled = true 一度設定すれば、変更を再度デプロイすることができます。 cdk deploy 6. リアルタイム機能のためのファーストクラスのクライアントライブラリサポート バックエンドの実装を合理化すると同時に、Amplify はお客様の GraphQL API に強く型付けされたクライアント SDK の自動生成を提供します。クライアントアプリでリアルタイムデータのサポートと強力な GraphQL クエリをすぐに利用できます。Web アプリの場合は、React ベースの JavaScript クライアントを生成します。クロスプラットフォームまたはモバイルアプリについては、Android、iOS、および React Native をサポートしています。これらのプラットフォームに対応するクライアントコードを生成する方法については、 ドキュメント を参照してください。Amplify クライアントライブラリを使えば、複雑なロジックを 1 からコーディングすることなく、魅力的なユーザー体験を構築することができます。 この例では、React アプリケーションを使ってこのライブブログを紹介します。まず、ターミナルから以下のコマンドを実行して、新しい React アプリケーションを作成します。 cd .. npx create-react-app frontendcd frontend 全体的なフォルダー構造は以下のようになります。 &gt;amplify-cdk-demo |-backend |-frontend 次に、アプリケーションをバックエンド API に接続するための Amplify Libraries をインストールします。 npm install aws-amplify 次に、バックエンド API を認識するように Amplify Libraries を設定する必要があります。アプリのエントリーポイント (すなわち index.js ) に行き、 cdk deploy を実行したときにターミナルに出力された API エンドポイントの情報を使って、Amplify Libraries を設定します。先程の cdk deploy で以下のように出力されているはずです。 ✨ Deployment time: 62.86s Outputs: BackendStack.amplifyApiModelSchemaS3Uri = s3://backendstack-mynewapiamplifycodegenassetsamplifyc-1u3xykyhe309m/model-schema.graphql BackendStack.awsAppsyncApiEndpoint = https://wy5mtp7jzfctxc5w5pzkcoktbi.appsync-api.us-east-1.amazonaws.com/graphql BackendStack.awsAppsyncApiId = eci46vifpvbvhno55uo2ovtoqm BackendStack.awsAppsyncApiKey = da2-XXXX BackendStack.awsAppsyncAuthenticationType = API_KEY BackendStack.awsAppsyncRegion = us-east-1 フロントエンドの index.js に、Amplify Libraries をインポートし、対応する情報を設定します。 import { Amplify } from 'aws-amplify' Amplify.configure({ aws_appsync_graphqlEndpoint: 'https://wy5mtp7jzfctxc5w5pzkcoktbi.appsync-api.us-east-1.amazonaws.com/graphql', aws_appsync_region: 'us-east-1', aws_appsync_authenticationType: 'API_KEY', aws_appsync_apiKey: 'da2-XXXX' }) Amplify Libraries の API カテゴリを使って生の GraphQL リクエストを書くこともできるます、以下の npx スクリプトを使うことで、一般的なリクエストの大部分を Amplify に生成させることもできます。 npx @aws-amplify/cli codegen add --apiId eci46vifpvbvhno55uo2ovtoqm --region us-east-1 npx @aws-amplify/cli codegen 注意 ：バックエンドにスキーマ変更をデプロイする度に、対応するクライアントヘルパーコードを再生成するために、 npx @aws-amplify/cli codegen を再実行する必要があります。 src/graphql/ フォルダに新しいファイル群があるはずです。これらは GraphQL Query、Mutation、Subscription のクライアントコードヘルパーです。 src/graphql/ ├── mutations.js ├── queries.js └── subscriptions.js ブログとメッセージ機能を表示するためにフロントエンドの UI を変更します。 App.js にアクセスし、以下の内容に置き換えます。 import "./App.css"; import { useEffect, useState } from "react"; import { API } from "aws-amplify"; import { listBlogs } from "./graphql/queries"; import { subscribeToLiveMessages } from "./graphql/subscriptions"; import { broadcastLiveMessage } from "./graphql/mutations"; function App() { const [blogs, setBlogs] = useState([]); const [messages, setMessages] = useState([]); useEffect(() =&gt; { // fetches all blog posts async function fetchBlogs() { const response = await API.graphql({ query: listBlogs, }); setBlogs(response.data.listBlogs.items); } fetchBlogs(); // setup subscriptions for live chat messages const subscription = API.graphql({ query: subscribeToLiveMessages }).subscribe(next =&gt; { setMessages(messages =&gt; [...messages, next.value.data.subscribeToLiveMessages]) }) return () =&gt; subscription.unsubscribe() }, []); // sends the live chat message to users function handleMessageSend(event) { if (event.key === 'Enter') { API.graphql({ query: broadcastLiveMessage, variables: { message: event.target.value } }) } } return ( &lt;div style={{ display: "flex", gap: 20 }}&gt; &lt;div&gt; &lt;h1&gt;Articles&lt;/h1&gt; {blogs.map((blog) =&gt; ( &lt;div style={{ border: '1px solid black', padding: 10, borderRadius: 10}}&gt; &lt;h2&gt;{blog.title}&lt;/h2&gt; &lt;p&gt;{blog.content}&lt;/p&gt; &lt;/div&gt; ))} &lt;/div&gt; &lt;div&gt; &lt;h1&gt;Live chat&lt;/h1&gt; &lt;input type="text" placeholder="Hit enter to send message" onKeyDown={handleMessageSend} /&gt; &lt;hr&gt;&lt;/hr&gt; &lt;ul&gt; {messages.map(message =&gt; &lt;li&gt;{message}&lt;/li&gt;)} &lt;/ul&gt; &lt;/div&gt; &lt;/div&gt; ); } export default App; 70 行以下のコードで、ライブチャット機能を持つブログ記事フロントエンドを構築しました。アプリをローカルで実行するには、ターミナルで以下のコマンドを実行してます。 npm run start あなたのアプリはこのように見えるはずです。ライブチャット機能をテストするために、別のウィンドウで開いてみてください。 成功の秘訣 CDK を使用してデプロイされたリアルタイム API とデータスタックが React アプリに統合されました！これは、Amplify GraphQL CDK コンストラクトのほんの一部の機能です。より深く掘り下げるために、以下のリソースもぜひご覧ください。 Construct Hub の Amplify GraphQL API コンストラクト Amplify GraphQL API 機能の認可ルール カスタムビジネスロジック (Lambda 関数、HTTP、JS/VTL リゾルバ ) JavaScript、Android、Swift、Flutter 用の GraphQL クライアントヘルパーコードの生成 他に質問がある場合は、 Discord に参加するか、問題や機能要求を提出したい場合は、 GitHub にアクセスしてください。 本記事は、「 Connect a React app to GraphQL and DynamoDB with AWS CDK and Amplify 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

AWS Amplify UI チームは、エンドユーザーのための機能豊富なアプリを構築するのに役立つ、8 つの新しい React ユーザーインターフェイスコンポーネントと 2 つの改良されたコンポーネントを紹介します。本記事では、新しいコンポーネントと、それらをプロジェクトにどのように使用できるかを紹介します。Amplify UI は、クラウドに接続されたクロスプラットフォームと、パフォーマンス、テーマ性、応答性、アクセシビリティに優れた React コンポーネントの両方を備えたコンポーネントライブラリです。 1. Fieldset &lt;Fieldset legend="Favorite fruits" variation="outlined" direction="column"&gt; &lt;CheckboxField label="Apple" name="apple" /&gt; &lt;CheckboxField label="Pear" name="pear" /&gt; &lt;/Fieldset&gt; Fieldset は、アクセス可能な &lt;legend&gt; を伴う &lt;fieldset&gt; 要素をレンダリングする新しいコンポーネントです。Fieldset は、フォーム内の関連する要素をグループ化するために使用される HTML 要素です。例えば、チェックボックスのグループや、より大きなフォーム内に関連するフィールドを作成するために使用されます。以前は、独自のフィールドセットを作成し、スタイルを設定する必要がありましたが、Fieldset コンポーネントの導入により、このプロセスはより簡単になりました。 Fieldset はコンテキストプロバイダなので、Fieldset の無効状態は、Amplify UI のフォームコントロールとネストされた Fieldset に正しく受け継がれます。 isDisabled プロパティを true に設定すると、Fieldset の子要素であるすべてのフォームフィールドが無効になります。 2. Input &lt;Input placeholder="placeholder" /&gt; Input は &lt;input&gt; 要素が受け入れる標準的な HTML 属性のどれでも受け入れます。標準的な &lt;input&gt; 属性は MDN Documentation で確認することができます。Input プリミティブはテキスト入力専用にスタイルされています (テキスト、日付、数字など)。 3. Label &lt;Flex direction="column" gap="small"&gt; &lt;Label htmlFor="first_name"&gt;First Name:&lt;/Label&gt; &lt;Input id="first_name" name="first_name" /&gt; &lt;/Flex&gt; Label は UI 要素のキャプションを表します。Label コンポーネントは Input コンポーネントと一緒に使うことで、独自のフォームフィールドを構成することができます。Label は、 &lt;label&gt; 要素が受け入れる標準的な HTML 属性を受け入れます。標準的な &lt;label&gt; 属性は MDN Documentation で確認することができます。 4. SelectField (更新) &lt;SelectField label="Fruit" descriptiveText="What's your favorite fruit?" isMultiple={true} &gt; &lt;option value="apple"&gt;Apple&lt;/option&gt; &lt;option value="banana"&gt;Banana&lt;/option&gt; &lt;option value="orange" disabled&gt;Orange&lt;/option&gt; &lt;option value="pineapple"&gt;Pineapple&lt;/option&gt; &lt;option value="kiwi"&gt;Kiwi&lt;/option&gt; &lt;option value="tangerine"&gt;Tangerine&lt;/option&gt; &lt;/SelectField&gt; SelectField に isMultiple と selectSize プロパティが追加され、ユーザの選択を処理するための設定オプションが増えました。 5. Button (更新) &lt;Button variation="primary" colorTheme="success" &gt; Click me! &lt;/Button&gt; 更新された Button コンポーネントでは、 colorTheme プロパティがサポートされ、より多くのカラーバリエーションを柔軟に組み込むことができるようになりました。 variation 、 size 、 colorTheme プロパティにより、54 種類のスタイルのボタンが用意されました！ 6. Message &lt;Message variation="plain" colorTheme="neutral" heading="A message heading"&gt; Basic message content &lt;/Message&gt; Message コンポーネントは Alert コンポーネントの後継です。Message はよりカスタマイズ可能で柔軟性があるため、アプリケーションのより多くの状況で使用することができます。Message にはデフォルトで ARIA ロールが設定されていません。使用するケースに応じて、 role 属性を渡したり、必要に応じて独自の ARIA 属性を追加したりすることができます。Message コンポーネントには、メッセージのカラーバリエーションを増やす colorTheme プロパティがあります。colorTheme プロパティは、同名の buttonプロパティに似ています。 7. Breadcrumbs (パンくずリスト) import { Breadcrumbs } from '@aws-amplify/ui-react'; export default function DefaultBreadcrumbsExample() { return ( &lt;Breadcrumbs items={[ { href: '/', label: 'Home', }, { href: '/react/components', label: 'Components', }, { label: 'Breadcrumbs', }, ]} /&gt; ); } Breadcrumbs コンポーネントは柔軟性があるので、レンダリングされるものを完全にコントロールすることができ、より高度なユースケースをアンロックすることができます。 &lt;Breadcrumbs.Container&gt; &lt;Breadcrumbs.Item&gt; &lt;Breadcrumbs.Link&gt; &lt;Breadcrumbs.Separator&gt; Breacrumbs コンポーネントを NextJS の Link コンポーネントと useRouter コンポーネントと一緒に使うことで、現在のパスに基づいて Breadcrumbs を自動的に生成することができます。 import Link from 'next/link'; import { Breadcrumbs } from '@aws-amplify/ui-react'; import { useRouter } from 'next/router'; export default function NextBreadcrumbsExample() { const { asPath } = useRouter(); const nestedRoutes = asPath .split('#')[0] .split('?')[0] .split('/') .filter((subpath) =&gt; subpath.length &gt; 0); const breadcrumbs = [ { href: '/', text: 'Home' }, ...nestedRoutes.map((subpath, i) =&gt; { const href = '/' + nestedRoutes.slice(0, i + 1).join('/'); const text = subpath; return { href, text }; }), ]; return ( &lt;Breadcrumbs.Container&gt; {breadcrumbs.map(({ href, text }, i) =&gt; { const isCurrent = i === breadcrumbs.length - 1; return ( &lt;Breadcrumbs.Item key={href}&gt; &lt;Link href={href} passHref&gt; &lt;Breadcrumbs.Link isCurrent={isCurrent}&gt;{text}&lt;/Breadcrumbs.Link&gt; &lt;/Link&gt; {isCurrent ? null : &lt;Breadcrumbs.Separator /&gt;} &lt;/Breadcrumbs.Item&gt; ); })} &lt;/Breadcrumbs.Container&gt; ); } 8. Dropzone export default function DefaultDropZoneExample() { const [files, setFiles] = React.useState([]); return ( &lt;&gt; &lt;DropZone onDropComplete={({ files }) =&gt; { setFiles(files); }} &gt; Drag images here &lt;/DropZone&gt; {files.map((file) =&gt; ( &lt;Text key={file.name}&gt;{file.name}&lt;/Text&gt; ))} &lt;/&gt; ); } DropZone コンポーネントは、要素に必要なイベントハンドラを追加し、ファイルタイプによってドロップされたファイルをフィルタリングします。ドロップされた後のファイルを取得するには、 files と rejectedFiles 配列を持つ関数である onDropComplete プロパティを使用できます。 9. IconsProvider Amplify UI コンポーネントで使用するアイコンをカスタマイズするには、アプリケーションを IconProvider コンポーネントでラップし、変更したいアイコンを渡します。 icons プロパティは、アイコンの名前を React コンポーネントにマッピングするオブジェクトでなければなりません。例えば、以下のように実装することが出来ます。 import { IconsProvider, Rating } from '@aws-amplify/ui-react'; import { FiStar } from 'react-icons/fi'; export default function IconProviderExample() { return ( &lt;IconsProvider icons={{ rating: { filled: &lt;FiStar /&gt;, empty: &lt;FiStar /&gt;, }, }} &gt; &lt;Rating value={3.5} /&gt; &lt;/IconsProvider&gt; ); } IconProvider コンポーネントは、React コンテキストを使用して、子コンポーネントがカスタムアイコンセットを利用できるようにします。IconProvider 内部のどのコンポーネントも、内部フックを介してカスタムアイコンにアクセスできます。アプリケーションの特定の部分でアイコンを変更したい場合は、他の React コンテキストと同じように、アプリケーションのさまざまな部分で IconsProvider をネストできます。 10. StorageImage &lt;StorageImage alt="cat" imgKey="cat.jpg" accessLevel="public" /&gt; StorageImage コンポーネントは @aws-amplify/ui-react-storage パッケージの新しい Storage 接続コンポーネントで、Storage に保存された画像を簡単に表示するために使用できます。 まとめ これら 10 個の新しいコンポーネントと更新されたコンポーネントにより、Amplify UI は React アプリケーションの構築と拡張においてより柔軟性と効率性を提供します。私たちは、アクセスしやすく、カスタマイズ可能で、ユーザーフレンドリーなアプリケーションを簡単に作成するために必要なツールを提供するために努力を続けています。他にもご希望のコンポーネントがありましたら、 GitHub でお知らせください 。 これらのコンポーネントやその他の Amplify UI の詳細については、 ドキュメントをご覧ください 。 本記事は、「 AWS Amplify UI: 10 new and updated components 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

この記事は Amazon Redshift: Lower price, higher performance の翻訳記事です。 ほぼすべてのお客様と同様に、あなたも可能な限り最高のパフォーマンスを実現しながら、コストを最小限に抑えたいと考えることでしょう。つまり、コストパフォーマンスに注意を払う必要があるということです。 Amazon Redshift を使用すると、コストを最小限に抑えながら最高のパフォーマンスを実現することができます。 Amazon Redshift は、数百人の同時ユーザーをサポートするための同時実行スケーリングや、クエリパフォーマンスを高速化するための強化された文字列エンコーディング、Amazon Redshift Serverless のパフォーマンス強化といった先進的な技術を使用することで、実際のワークロードにおいて他のクラウドデータウェアハウスと比較して、ユーザーあたりのコストを最大 4.9 倍削減し、最大 7.9 倍優れたコストパフォーマンスを実現します。コストパフォーマンスが重要な理由と、Amazon Redshift では、特定のレベルのワークロードパフォーマンスを得るためにどの程度のコストが必要になるかという尺度、つまりパフォーマンス ROI (投資収益率) を理解するためにぜひ読んでください。 コストとパフォーマンスの両方がコストパフォーマンスの計算に含まれるため、コストパフォーマンスについては 2 つの考え方があります。 1 つ目の考え方は、コストを一定に保つことです。1 ドルを使えるとしたら、データウェアハウスからどの程度のパフォーマンスが得られるでしょうか？ コストパフォーマンスの優れたデータベースは、支出した 1 ドルごとに優れたパフォーマンスを提供します。したがって、同じ一定のコストの 2 つのデータウェアハウスを比較する場合、コストパフォーマンスの高いデータベースの方がクエリの実行が速いです。 2 つ目の考え方は、パフォーマンスを一定に保つことです。ワークロードを 10 分以内で完了する必要がある場合、それにかかるコストはいくらでしょうか？ コストパフォーマンスに優れたデータベースでは、ワークロードを10 分以内でより低コストで実行できます。したがって、パフォーマンスを一定に保ち、同じパフォーマンスを実現するサイズの 2 つのデータウェアハウスを比較する場合、コストパフォーマンスの高いデータベースの方がコストが低くなり、コストを節約することができます。 最後に、コストパフォーマンスのもう 1 つの重要な観点は、予測可能性です。データウェアハウスのユーザー数が増加するにつれて、データウェアハウスのコストがどれくらいかかるかを把握することは、計画を立てる上で非常に重要です。今日最高のコストパフォーマンスを提供するだけでなく、ユーザーやワークロードが追加されたときに予測どおりに拡張し、最高のコストパフォーマンスを提供する必要があります。理想的なデータウェアハウスは線形にスケールする必要があります。つまり、クエリスループットを 2 倍にするためにデータウェアハウスをスケーリングすることは、理想的にはコストが 2 倍 (またはそれ以下) になるということです。 この投稿では、Amazon Redshift がその他の主要なクラウドデータウェアハウスと比較して、コストパフォーマンスが非常に優れているということを説明するために、パフォーマンスの計測結果を共有します。これは、他のデータウェアハウスに費やすのと同じ金額を Amazon Redshift に費やした場合、Amazon Redshift を使用した方がパフォーマンスが向上することを示しています。あるいは、同じパフォーマンスを実現するように Redshift クラスターのサイズを調整すると、他のデータウェアハウスと比較してコストが低くなるということです。 実ワークロードにおけるコストパフォーマンス Amazon Redshift を使用すると非常に多様なワークロードを強化できます。複雑な抽出、変換、ロード (ETL) ベースのレポートのバッチ処理やリアルタイムのストリーミング分析から、数百、さらには数千の同時ユーザーに1 秒未満の応答時間でサービスを提供する必要がある低レイテンシーのビジネスインテリジェンス (BI) ダッシュボードまでのありとあらゆるワークロードです。AWS は、お客様のコストパフォーマンスを継続的に向上させる方法の 1 つとして、Amazon Redshift のパフォーマンスをさらに向上できる機会とお客様のユースケースを見つけるために、Redshift フリートからのソフトウェアおよびハードウェアのパフォーマンステレメトリーを常にレビューしています。 フリート テレメトリによるパフォーマンス最適化の最近の例としては、次のようなものがあります。 文字列型に対するクエリの最適化 – Amazon Redshift が Redshift フリート内のさまざまなデータ型をどのように処理するかを分析した結果、文字列を多く含むクエリを最適化すると、お客様のワークロードに大きなメリットがあることがわかりました。 (これについては、この投稿の後半で詳しく説明します。) 自動化されたマテリアライズド ビュー – Amazon Redshift のお客様は、サブクエリパターンを持つ多くのクエリを実行することが多いことがわかりました。たとえば、いくつかの異なるクエリが同じ結合条件を使用して同じ 3 つのテーブルを結合する場合があります。 Amazon Redshift は、マテリアライズドビューを自動的に作成および維持し、機械学習による 自動マテリアライズドビュー の自律的な機能を使用して、マテリアライズドビューを使用するようにクエリを透過的に書き換えられるようになりました。自動マテリアライズドビューを有効にすると、ユーザーの介入なしに、反復的なクエリのパフォーマンスを透過的に向上させることができます。 (ただし、自動マテリアライズドビューは、この投稿で説明したどのベンチマーク結果にも使用されていません) 同時実行性の高いワークロード – Amazon Redshift を使用してダッシュボードのようなワークロードを提供するユースケースが増加しています。これらのワークロードの特徴は、要求されるクエリ応答時間が 1 桁秒以下であり、使用パターンが突発的でしばしば予測不可能で、数十から数百のユーザーが同時にクエリを実行します。この典型的な例は、Amazon Redshift を利用した BI ダッシュボードで、多くのユーザーが週初めの月曜の朝にトラフィックが急増します。 特に同時実行性の高いワークロードは非常に幅広い適用範囲を持っています。ほとんどのデータウェアハウスのワークロードでは同時実行で動作し、Amazon Redshift では、数百、さらには数千のユーザーが同時にクエリを実行することも珍しくありません。 Amazon Redshift は、クエリの応答時間を予測可能かつ高速に保つように設計されています。 Redshift Serverless は、必要に応じて自動的に処理能力を追加および削除することで、クエリの応答時間を高速かつ予測可能に保ちます。つまり、1 人または 2 人のユーザーがアクセスしているときに迅速に読み込まれる Redshift Serverless のダッシュボードは、多くのユーザーが同時にアクセスしている場合でも引き続き迅速に読み込まれることを意味します。 このタイプのワークロードをシミュレートするために、100 GB データセットを使用した TPC-DS から派生したベンチマークを使用しました。 TPC-DS は、さまざまな典型的なデータウェアハウスクエリを含む業界標準のベンチマークです。 100 GB という比較的小規模なスケールでは、このベンチマークのクエリは Redshift Serverless 上で平均数秒で実行されます。これは、インタラクティブな BI ダッシュボードを読み込むユーザーが期待する典型的な速度であることを表しています。このベンチマークでは 1 ～ 200 の同時テストを実行し、同時にダッシュボードを読み込もうとする 1 ～ 200 人のユーザーをシミュレートしました。また、自動スケールアウトをサポートするいくつかの一般的なクラウドデータウェアハウスに対してテストを繰り返しました (自動スケールアップをサポートしていないため、私たちはブログ「 Amazon Redshift の継続的なコストパフォーマンス最適化 」の競合他社 A を含めませんでした)。私たちは、平均クエリ応答時間を測定しました。これは、ユーザーがクエリの完了 (またはダッシュボードの読み込み) を待つ時間を意味します。結果を次のグラフに示します。 競合他社 B は、同時クエリ数が約 64 個になるまではうまく拡張できていますが、その時点で追加のコンピューティングを提供できなくなり、クエリがキューに入り始め、クエリの応答時間の増加につながっています。競合他社 C も自動的にスケーリングできていますが、Amazon Redshift や競合他社 B よりもクエリのスループットが低くなり、クエリのランタイムを低く保つことができません。さらに、コンピューティングが不足した場合のクエリのキューイングはサポートしていないため、同時ユーザー数が約 128 人を超えて拡張することができません。これを超えて追加のクエリを送信すると、システムによって拒否されます。 ここで、Redshift Serverless は、数百のユーザーが同時にクエリを実行している場合でも、クエリ応答時間を約 5 秒と比較的一定に保つことができます。競合他社 B と競合他社 C の平均クエリ応答時間は、データウェアハウスの負荷が増加するにつれて着実に増加しています。その結果、データウェアハウスがビジー状態になると、ユーザーはクエリが返るまでより長く (最大 16 秒) 待たなければならなくなります。これは、ユーザーがダッシュボードを更新しようとしている場合 (リロード時に複数の同時クエリを送信することもあります)、Amazon Redshift は、たとえダッシュボードが他の数十、数百ものユーザーによって同時に読み込まれている場合でも、ダッシュボードの読み込み時間を一貫した状態に保つことができることを意味します。 Amazon Redshift は実行時間の短いクエリに対して非常に高いクエリスループットを提供できるため (「 Amazon Redshift の継続的なコストパフォーマンス最適化 」で説明したように)、スケールアウト時にこれらの高い同時実行性をより効率的に処理できるため、大幅に低いコストで処理することもできます。 これを定量化するために、次のグラフに示すように、前のテストで各データウェアハウスの公開されている オンデマンド価格 を使用してコストパフォーマンスを調べます。なお、 リザーブドインスタンス (RI) 、特に全額前払いオプションで購入した 3 年間の RI を使用すると、プロビジョニングされたクラスター上で Amazon Redshift を実行するコストが最も低くなり、オンデマンドまたは他の RI オプションと比較して、最高の相対的な価格パフォーマンスが得られることには注目すべきでしょう。 したがって、Amazon Redshift は、より高い同時実行でより優れたパフォーマンスを提供できるだけでなく、大幅に低いコストでそれを実現できます。コストパフォーマンスの図の各データポイントは、指定された同時実行数でベンチマークを実行するコストに相当します。コストパフォーマンスは線形であるため、任意の同時実行数でベンチマークを実行したコストを同時実行数 (このグラフの同時ユーザー数) で割ることで、この特定のベンチマークで新しいユーザーを追加するたびにどれくらいのコストがかかるかを知ることができます。 ここまでの結果は簡単に再現できます。ベンチマークで使用されるすべてのクエリは GitHub リポジトリ で利用でき、パフォーマンスはデータウェアハウスを起動し、Amazon Redshift で同時実行スケーリング (または他のウェアハウスで対応する自動スケーリング機能) を有効にし、データをロードすることによってカスタマイズなしの状態で測定します (手動でのチューニングやデータベース固有のセットアップはありません）。そして、各データウェアハウスで 同時実行数を1-200の間で32刻みで変化させ、同時実行テストを行いました。上述の GitHub リポジトリは、公式 TPC-DS データ生成キットを使用して事前生成された (かつ変更されていない)、 Amazon Simple Storage Service (Amazon S3) 内にある様々なスケールのTPC-DSデータを参照しています。。 文字列を多く含むクエリの最適化 前述したように、Amazon Redshift チームは、お客様にさらに優れたコストパフォーマンスを提供するための新しい機会を継続的に探しています。パフォーマンスを大幅に向上させるために最近開始した改善の 1 つは、文字列データに対するクエリのパフォーマンスを高速化する最適化です。たとえば、 SELECT sum(price) FROM sales WHERE city = ‘New York’ のようなクエリを使用して、ニューヨーク市にある小売店から得られた総収益を確認するとします。このクエリは文字列データ ( city = ‘New York’ ) を述語に適用しています。ご想像のとおり、文字列データ処理はデータウェアハウスアプリケーションで広く使用されています。 お客様のワークロードが文字列にアクセスする頻度を定量化するために、Amazon Redshift が管理する数万のお客様のクラスターのフリートテレメトリを使用して、文字列データ型の使用状況の詳細な分析を実施しました。分析の結果、クラスターの 90% では文字列カラムが全カラムの少なくとも 30% を構成し、クラスターの 50% では文字列カラムが全カラムの少なくとも 50% を構成していることがわかりました。さらに、Amazon Redshift クラウドデータウェアハウスプラットフォームで実行されるクエリの大部分は、少なくとも 1 つの文字列カラムにアクセスしています。もう 1 つの重要な要素は、文字列データはカーディナリティが低いことが非常に多く、列に含まれる一意の値のセットが比較的少ないことを意味します。たとえば、販売データを表す orders テーブルには数十億の行が含まれている場合がありますが、そのテーブル内の order_status 列には、 pending 、 in process 、 completed などの数十億の行にわたって一意の値がわずかしか含まれていない可能性があります。 この記事の執筆時点では、Amazon Redshift のほとんどの文字列カラムは LZO または ZSTD アルゴリズムで圧縮されています。これらは優れた汎用圧縮アルゴリズムですが、カーディナリティの低い文字列データを活用するように設計されていません。特に、データを操作する前に解凍する必要があり、ハードウェアメモリ帯域幅の使用効率が低くなります。カーディナリティの低いデータの場合、より最適な別のタイプのエンコーディングである BYTEDICT があります。このエンコードでは、ディクショナリエンコードスキームが使用されており、データベースエンジンは圧縮データを最初に解凍する必要がなく、圧縮データに対して直接操作できます。 文字列の多いワークロードのコストパフォーマンスをさらに向上させるために、Amazon Redshift は現在、BYTEDICT としてエンコードされたカーディナリティの低い文字列カラムのスキャンと述語評価を、LZO や ZSTD などの圧縮エンコーディングと比較して 5 ～ 63 倍高速化する追加のパフォーマンス強化を導入しています (次のセクションの結果を参照)。 Amazon Redshift は、CPU 効率が高い軽量なBYTEDICT でエンコードされたカーディナリティの低い文字列カラムをベクトル化スキャンすることで、このパフォーマンスの向上を実現します。これらの文字列処理の最適化により、最新のハードウェアが提供するメモリ帯域幅が効果的に利用され、文字列データのリアルタイム分析が可能になります。これらの新しく導入されたパフォーマンス機能は、カーディナリティの低い文字列カラム (最大数百の一意の文字列値) に最適です。 Amazon Redshift データウェアハウスで 自動テーブル最適化 を有効にすることで、この新しい高パフォーマンス文字列の機能強化の恩恵を自動的に受けられます。テーブルで自動テーブル最適化が有効になっていない場合は、Amazon Redshift コンソールの Amazon Redshift Advisor から、文字列絡むの BYTEDICT エンコードへの適合性に関する推奨事項を受け取ることができます。 BYTEDICT エンコードを使用したカーディナリティの低い文字列列を持つ新しいテーブルを定義することもできます。 Amazon Redshift の文字列の拡張機能は、 Amazon Redshift が利用可能 なすべての AWS リージョンで利用できるようになりました。 パフォーマンス測定結果 文字列処理の強化によるパフォーマンスへの影響を測定するために、カーディナリティの低い文字列データで構成される 10 TB (テラバイト) データセットを生成しました。 Amazon Redshift フリートテレメトリからの文字列の長さの 25、50、および 75 パーセンタイルに対応する、短、中、長の文字列を使用して 3 つのバージョンのデータを生成しました。このデータを Amazon Redshift に 2 回ロードし、1 つは LZO 圧縮を使用し、もう 1 つは BYTEDICT 圧縮を使用してエンコードしました。最後に、多くの行 (テーブルの 90%)、中程度の行 (テーブルの 50%)、および少数の行 (テーブルの 1%) を返すスキャンを多用するクエリのパフォーマンスを、これらのカーディナリティの低いデータセットに対して測定しました。パフォーマンス結果を次のグラフにまとめます。 この内部ベンチマークでは、多くの行に一致する述語を含むクエリでは、LZO と比較して新しいベクトル化 BYTEDICT エンコーディングで 5 ～ 30 倍の改善が見られました。一方で、少ない行に一致する述語によるクエリでは 10 ～ 63 倍の改善が見られました。 Redshift Serverless コストパフォーマンス この投稿で示した高い同時実行パフォーマンスの結果に加えて、より大きな 3 TB データセットでTPC-DS 派生のクラウドデータウェアハウスのベンチマークも使用して、Redshift Serverless のコストパフォーマンスを、他のデータウェアハウスと比較しました。私たちは同様の価格のデータウェアハウスを選択しました。今回のケースでは、公開されているオンデマンド価格を使用すると、1 時間あたり 32 ドルの 10% 以内に収まっています。結果は、Amazon Redshift RA3 インスタンスと同様に、Redshift Serverless が他の主要なクラウドデータウェアハウスと比較して優れたコストパフォーマンスを実現していることを示しています。いつものように、これらの結果は、 GitHub リポジトリ の SQL スクリプトを使用して再現できます。 Amazon Redshift がデータ分析のニーズをどのように満たすかを確認する最良の方法として、自身の PoC ワークロードを使用して Amazon Redshift を試してみることをお勧めします。 あなたのワークロードにおける最高のコストパフォーマンスを見つける この投稿で使用されているベンチマークは、業界標準の TPC-DS ベンチマークから派生したもので、次の特徴があります。 スキーマとデータは TPC-DS から変更せずに使用しています。 クエリは、TPC-DS キットのデフォルトのランダムシードを使用して生成されたクエリパラメーターを持つ公式 TPC-DS キットを使用して生成しています。データウェアハウスがデフォルトの TPC-DS クエリの SQL 言語をサポートしていない場合は、TPC で承認された変更を加えたクエリを使用しています。 テストには 99 個の TPC-DS の SELECT クエリを含みます。これには、メンテナンスとスループットの手順は含んでいません。 単発の 3TB 同時実行テストでは、3 回の POWER RUN が実行され、データウェアハウスごとに最良の実行結果を採用しました。 TPC-DS クエリのコストパフォーマンスは、時間あたりのコスト (USD) にベンチマークの実行時間 (時間単位) を掛けたものとして計算しています。これは、ベンチマークの実行コストに相当します。前述したようにリザーブド インスタンスの価格ではなく、すべてのデータウェアハウスで最新の公開されたオンデマンド価格を使用しています。 これをクラウドデータウェアハウスベンチマークと呼びます。 GitHub リポジトリ で利用可能なスクリプト、クエリ、データを使用して、前述のベンチマーク結果を簡単に再現できます。この投稿で説明されているように、これは TPC-DS ベンチマークから派生したものであり、テストの結果は公式仕様に準拠していないため、公開されている TPC-DS の結果と比較することはできません。 結論 Amazon Redshift は、さまざまなワークロードに対して業界最高のコストパフォーマンスを提供することに尽力しています。 Redshift Serverless は、最良の (最も低い) コストパフォーマンスでリニアにスケールし、一貫したクエリ応答時間を維持しながら数百人の同時ユーザーをサポートします。この投稿で説明したテスト結果に基づくと、Amazon Redshift は、最も近い競合他社 (競合 B) と比較して、同じレベルの同時実行数で最大 2.6 倍優れたコストパフォーマンスを示しました。前述したように、3 年間全額前払いオプションでリザーブドインスタンスを使用すると、Amazon Redshift の実行コストが最も低くなり、この投稿で使用したオンデマンドインスタンスの価格と比較して、相対的なコストパフォーマンスがさらに向上します。継続的なパフォーマンス向上に対する当社のアプローチには、顧客のユースケースとそれに関連するスケーラビリティのボトルネックを理解するというお客様を中心とした考え方と、パフォーマンスを大幅に最適化する機会を特定するための継続的なフリートデータ分析を組み合わせた独自の組み合わせが含まれます。 各ワークロードには独自の特性があるため、まだ始めたばかりの場合は、Amazon Redshift がどのようにコストを削減しながらパフォーマンスを向上させるかを理解するための最良の方法は PoC です。独自の PoC を実行する場合は、クエリスループット (1 時間あたりのクエリ数)、応答時間、コストパフォーマンスなどの適切な指標に焦点を当てることが重要です。 PoC を自分で実行するか、AWS または システムインテグレーターおよびコンサルティングパートナー の 支援 を受けて、データ主導の意思決定を行うことができます。 Amazon Redshift の最新の開発状況を常に把握するには、 Amazon Redshift の最新情報 フィードをフォローしてください。 翻訳はソリューションアーキテクトの池田 敬之が担当しました。

この投稿は、プリンシパルソリューションアーキテクトの Anton Aleksandrov とシニアプロダクトマネージャーの Tarun Rai Madan の投稿を翻訳したものです。 本日、 AWS Lambda は、 Amazon Simple Queue Service（Amazon SQS） をイベントソースとして構成したスパイクのある Lambda ワークロードのポーリングスケールアップ率を最大 5 倍高速化したことを発表しました。 この機能により、Lambda と SQS を使用してイベント駆動型アプリケーションを構築し、SQS キュー内のメッセージのバースト時に応答性の高いスケーリングを実現します。また、より高速なメッセージ処理を実現するために Lambda 関数または SQS キューを複製する必要性を減らします。 概要 AWS Lambda で最新のイベント駆動型およびメッセージングアプリケーションを構築するお客様は、分離されたアーキテクチャを作成するための基本的なビルディングブロックとして Amazon SQS を使用します。 Amazon SQS は、マイクロサービス、分散システム、サーバーレスアプリケーション向けのフルマネージドなメッセージキューイングサービスです。Lambda 関数がイベントソースとして SQS キューをサブスクライブすると、Lambda はキューをポーリングし、メッセージを取得し、取得したメッセージをバッチで関数ハンドラに送信して処理します。メッセージを効率的に消費するために、Lambda はキューの深さの増加を検出し、キューに入れられたメッセージを処理するためのポーラープロセスの数を増やします。 今日まで、Lambda は SQS キューを購読した Lambda 関数に対して 1 分間に最大 60 回の同時実行を追加し、約 20 分で最大 1,250 の同時実行にスケールアップしていました。しかし、お客様の声では、Lambda と SQS を使用して構築する最新のイベント駆動型アプリケーションのいくつかは、メッセージの突然の急増に敏感であり、エンドユーザーのメッセージの処理に顕著な遅延を引き起こす可能性があるとのことでした。SQS キューでメッセージのバーストがあるアプリケーションに Lambda のパワーを活用するために、これらのお客様はより速くスケールアップするための Lambda メッセージポーリングが必要でした。 今日の発表により、SQS キューを購読する Lambda の機能は、メッセージバックログが急増するキューに対して最大 5 倍速くスケールし、1 分間に最大 300 の同時実行を追加し、最大 1,250 の同時実行数にスケールアップできます。このスケーリングの改善は、Lambda と SQS の統合のシンプルさを使用して、特にリアルタイムシステム向けに、受信メッセージの急増時により高速に拡張できるイベント駆動型アプリケーションを構築するのに役立ちます。また、SQS キューでのメッセージの急増時に処理を高速化する利点を提供する一方で、SQS イベントソースごとに最大同時 Lambda 呼び出しを制限する柔軟性を提供し続けます。 SQS による最大同時 Lambda 呼び出しの制御 新しく改善されたスケーリングレートは、イベントソースとして Lambda と SQS を使用するすべての AWS アカウントに自動的に適用されます。取らなければならない明示的なアクションはなく、追加費用もありません。このスケーリングの改善は、お客様がより高速な SQS ポーリングスケールアップを必要とする、より高性能な Lambda アプリケーションを構築するのに役立ちます。関連するダウンストリームが高負荷になる可能性を低減するために、Lambda は関数レベルで予約済み同時実行数（Reserved concurrency）、イベントソースレベルで最大同時実行数（Maximum concurrency）を設定できます。 次の図は、SQS イベントソースの流量を制御するために使用できる設定を示しています。予約済み同時実行数（Reserved concurrency）を使用して関数レベルのスケーリングを制御し、最大同時実行数（Maximum concurrency）を使用してイベントソースのスケーリングを制御します。 予約済み同時実行数（Reserved concurrency） は、関数に割り当てる最大同時実行数です。関数に割り当てられた予約済み同時実行数がある場合、他の関数はその同時実行数を使用できません。 関数にスケールアップするのに十分な同時実行数を確保したい場合は、予約済み同時実行数を使用することを推奨します。SQS イベントソースが Lambda の同時実行をスケールアップしようとしているが、関数がすでに予約済み同時実行数によって定義されたしきい値に達している場合、Lambda サービスはさらなる関数呼び出しを制限します。 これにより、SQS イベントソースがスケールダウンを試み、同時に処理されるメッセージの数が減少する可能性があります。キューの設定に応じて、制限されたメッセージは再試行のためにキューに返されるか、保持ポリシーに基づいて期限切れになるか、 デッドレターキュー (DLQ) または 失敗の宛先 (on-failure destination) に送信されます。 最大同時実行数（Maximum concurrency） 設定を使用すると、イベントソースレベルで同時実行数を制御できます。これにより、イベントソースが Lambda 関数に送信しようとする同時呼び出しの最大数を定義できます。1つの関数に複数の SQS イベントソースが構成されているシナリオでは、各イベントソースの最大同時実行数を個別に定義することで、よりきめ細やかな制御が可能です。SQS イベントソースにレート制御を追加しようとする場合は、より高い柔軟性を提供するために、まず初めに最大同時実行数の設定を評価することを推奨します。 予約同時実行と最大同時実行は補完的な機能であり、併用することができます。最大同時実行数は、ダウンストリームシステムが高負荷になるのを防ぐために呼び出しをスロットルするのに役立ちます。予約同時実行数は、関数が利用可能な同時実行数を確保するのに役立ちます。 シナリオ例 あなたのビジネスはストレージから大量の文書を処理する必要があると考えてください。数時間ごとに、ビジネスパートナーは大量のドキュメントをアカウントの S3 バケットにアップロードします。 回復力（レジリエンシー）のために、アップロードされた各ドキュメントの SQS キューにメッセージを送信するようにアプリケーションを設計したので、誤ってスキップすることなく効率的に処理できます。ドキュメントは、単一のドキュメントを処理するのに約 2 秒かかる Lambda 関数を使用して処理されます。 これらのドキュメントの処理は CPU 使用率の高い操作であるため、1 つの呼び出しごとに 1 つのドキュメントを処理することにしました。Lambda のパワーを使用して、できるだけ多くの同時実行環境に並列処理をファンアウトしたいと考えています。Lambda 関数は、これらのドキュメントを可能な限り迅速にスケールアップし、コストを節約するためにすべてのドキュメントが処理されたらゼロにスケールダウンします。 ビジネスパートナーが 20万件の文書をアップロードすると、20万件のメッセージが SQS キューに送信されます。Lambda 関数は SQS イベントソースで構成され、キューからのメッセージを消費し始めます。 この図は、SQS イベントソースのスケーリング改善の前にテストシナリオを実行した結果を示しています。予想通り、同時実行数は 1 分間に 60 増加することがわかります。900 の同時実行数に徐々にスケールアップし、キュー内のすべてのメッセージを処理するには、約 16 分かかります。 次の図は、SQS イベントソースのスケーリングの改善後に同じテストシナリオを実行した結果を示しています。両方のチャートに使用される時間枠は同じですが、2 番目のチャートのパフォーマンスは優れています。同時実行数は毎分 300 増加します。1,250 の同時実行数にスケールアップするのに 4 分しかかからず、キュー内のすべてのメッセージは約 8 分で処理されます。 この例をデプロイする サンプルプロジェクト を使用して、自分の AWS アカウントでこのパフォーマンステストを複製します。 AWS Cloud Development Kit (CDK) を使用して AWS アカウントのサンプルプロジェクトをプロビジョニングするには、README.md の指示に従ってください。 このサンプルプロジェクトは、20万件のメッセージを処理する大規模なワークロードを実証するように構成されています。アカウントでこのサンプルプロジェクトを実行すると、料金が発生する場合があります。 AWS Lambda の料金 と Amazon SQS の料金 を参照してください。 デプロイしたら、“sqs-cannon” ディレクトリの下にあるアプリケーションを使用して、20万件のメッセージを SQS キューに送信します(もしくは他の数値を設定します)。SQS キューにメッセージを入力するのには数分かかります。すべてのメッセージが送信されたら、README.md で説明されているように SQS イベントソースを有効にし、プロビジョニングされた CloudWatch ダッシュボードのチャートをモニタリングします。 新しい AWS アカウントのデフォルトの同時実行数クォータは 1000 です。このクォータの増加をリクエストしていない場合、同時実行数はこの数に制限されます。 サービスクォータ を使用するか、アカウントチームに連絡して同時実行数の増加をリクエストしてください。 セキュリティのベストプラクティス Lambda 関数に SQS キューへのアクセスを許可するときは、常に最も特権の低い権限を使用してください。これは、特定の機能のみが特定のキューに対して特定のアクションを実行する権限を持つようにすることで、潜在的な攻撃面を減らします。たとえば、関数がキューからのみポーリングする場合は、メッセージを読む権限を付与しますが、新しいメッセージを送信する権限は付与しません。 関数実行ロール は、関数が他のリソースで実行できるアクションを定義します。 キューアクセスポリシー は、このキューにアクセスできるプリンシパルと、許可されるアクションを定義します。 サーバーサイド暗号化(SSE) を使用して、暗号化された SQS キューに機密データを保存します。SSE では、メッセージは常に暗号化された形式で保存され、SQS は許可された消費者に送信するためにのみ復号化します。SSE は、SQS が管理する暗号化キー (SSE-SQS) または AWS Key Management Service で管理されるキー (SSE-KMS) を使用して、キュー内のメッセージの内容を保護します。 まとめ 改善された Lambda の SQS イベントソースポーリングスケールアップ機能は、SQS キューを使用したスパイクのあるイベント駆動型ワークロードのスケールアップパフォーマンスを追加料金なしで最大 5 倍高速化できます。この改善は、SQS キューのメッセージの急増時に処理を高速化するメリットを顧客に提供しますが、イベントソースとして SQS による最大同時実行数を制限する柔軟性を提供し続けます。 より多くのサーバーレス学習リソースについては、 Serverless Land をご覧ください。 翻訳はソリューションアーキテクトの淡路が担当しました。原文は こちら です。