イントロダクション AWS Copilot CLI は、 Amazon Elastic Container Service ( Amazon ECS ) , AWS Fargate 及び AWS App Runner 上で コンテナのビルドや管理運用する際にデベロッパーが用いるツールで、 2020 年にローンチ しました。 このブログでは、AWS Copilot CLI を使用して、Amazon ECS 及び AWS Fargate 上で publisher サービスと subscriber ワーカーサービスを簡単に実装する方法説明します。これらのサービスは、 pub/sub アーキテクチャ 内でそれぞれがイベントを publish 及び consume します。 この機能を説明するために、 このブログ に掲載されたモノと似たアーキテクチャを元に、publish/subscribe(pub/sub) アーキテクチャを作成します。しかし、 AWS Lambda に頼ることなく、AWS Fargate 上で動作する Amazon ECS サービスを用いると共に、AWS Copilot CLI を用いてリソースの作成と管理をします。 このブログでは、あなたは E コマースプラットフォームの所有者と仮定します。そして、プラットフォームに注文が送信される度にマイクロサービスがトピックにメッセージを送信し、このメッセージに関心があるいくつかのマイクロサービスは、非同期に受け取った注文に対して処理を始めます。注文を処理できるマイクロサービスは様々あると考えられ、たとえば、注文フルフィルメントマイクロサービス、インボイスのマイクロサービス、特定の閾値を超える注文に対してキャンペーンコードを生成するようなプロモーションマイクロサービスなどです。このブログでは、フルフィルメントマイクローサビス及びプロモーションマイクロサービスを実装します。 ソリューションのアーキテクチャは下記の図の通りです。 ソリューションの概要 pub/sub でのメッセージングは非同期メッセージングパターンで、送信者または受信者のidを知ることなくメッセージを交換できます。このパターンでは、サービス間の通信を疎結合にできるので、アプリケーションを分離できます。送信者 ( publisher とも呼ばれる ) は、トピックに対してメッセージをブロードキャストします。一方で受信者 ( subscriber とも呼ばれる ) は異なるトピックをサブスクライブし、当該トピックにメッセージが送信されるとフィルタリングポリシーを参照し、合致するメッセージを受信します。 受信者は、送信者からのメッセージを無限に受け取ることができますが、topic-queue chaining と呼ばれるパターンを用いることをオススメします。この名前が示すように、SNS トピックを SQS キューに紐付けます。もし、サービスが例外を実行した際やメンテナンスを必要としている際でも、メッセージはキューに保持されます。これには、キューがバッファとして機能し、最終的にロードバランサーとして機能するという利点もあります。 AWS Copilot CLIは、topic-queue chaining パターンのpub/sub アーキテクチャを以下のように簡単に実装できます。 サービスマニフェストを修正するだけで、 Amazon SNS トピック にメッセージを送信する publisher サービスを作成します。 トピックに送信された通知を処理するため 1 つ以上の Amazon SQS キュー を含む worker サービス、障害を処理する デッドレターキュー ( DLQ )、キューからメッセージを取得し、非同期にメッセージを処理するAWS Fargate 上で動作する Amazon ECS サービスを作成します。 このブログでは、AWS Copilot CLI が提供する Load Balanced Web Service と Worker Service を用いて以下のアーキテクチャを実装します。 ウォークスルー ここからは、皆さんと次の作業を実施していきます。 サンプルリポジトリのクローンとコードの確認 AWS Copilot CLI を用いて、マイクロサービスのための環境の構築 publisher と SNS トピックの作成 subscriber、SQS キュー、subscriber のポリシーの作成 実装した pub/sub アーキテクチャがどのように動作するか確認 前提条件 このウォークスルーでは、以下の前提条件を満たす必要があります。 AWS アカウント の用意 AWS Copilot CLI がインストール済み ( version v1.22 以上 ) AWS CLI または 環境変数 を用いて適切に設定された AWS クレデンシャル Docker がインストールされ、実行可能であること サンプルリポジトリのクローン 最初のステップでは、Github リポジトリをクローンするディレクトリに移動し、git clone を実行します。 git clone https://github.com/aws-samples/aws-copilot-pubsub クローンしたディレクトリに移動し、サブディレクトリを確認してください。サービスごとにフォルダーがあり、1 つは publisher 用、もう 1 つは fulfilment と promotion という名前の 2 つの subscriber 用です。下記にフォルダー構成を示します。 aws-copilot-pubsub/ ├─ subscribers/ │ ├─ fulfilment/ │ │ └─ ... │ ├─ promotion/ │ │ ├─ requirements.txt │ │ ├─ promotion.py │ │ └─ Dockerfile ├─ publisher/ │ └─ ... アプリケーションと環境の作成 まず最初に、Service、Environment、Pipeline を関連づける論理グループを作成します。AWS Copilot では、これを Application と呼びます。 copilot app init pubsub 上記のコマンドを実行すると、AWS Copilot はマニフェストと呼ばれる IaC の YAML 構成ファイルを保持するために ./copilot フォルダを利用します。それにより、AWS Copilot CLI を用いて AWS 上にコンテナ化されたアプリケーションを簡単にデプロイすることを可能にします。合わせてリソース作成に使われるインフラストラクチャロールもいくつか作成されます。 次のステップでは、デプロイするアプリケーションのための環境を構築します。AWS Copilot では、アプリケーションのデプロイメントを論理的に分離した環境を非常に簡単な方法で作成する事ができます。一般的なユースケースは、テスト環境 及び 独立した本番環境を用意し、テスト環境で検証された場合にのみ、アプリケーションを本番環境にデプロイすることです。このウォークスルーでは、以下のコマンドで作成した test という名前のテスト環境にサービスをデプロイします。 copilot env init \ 　　 --app pubsub \ 　　--name test \ 　　--region 'eu-west-1' \ 　　--default-config \ 　　 --profile default 上記のコマンドを実行すると、AWS Copilot は指定されたプロファイル認証情報 (default profile) を使用して、サービスをホストするために必要なインフラストラクチャを作成します。プロファイルを省略すると、 ~/.aws/credentials ファイル内のプロファイルのうち一つを選択するように促されます。AWS Copilot は、選択された認証情報を用い、ユーザに代わってリソースの作成を開始します。初期構成が出来上がった後は、ユーザは、 ./copilot/environments/test/manifest.yaml ファイルを修正することにより環境をアップデートできます。今回は、環境に変更を加えることはしません。下記のコマンドで環境をデプロイします。 copilot env deploy --name test 作成された環境ごとに、AWS Copilot は、分離されたネットワークスタック、コンピュートエンジンに AWS Fargate を用いた Amazon ECS クラスタを作成します。このプロセスが完了するまで、およそ 2 分かかります。少しストレッチして待ちましょう。もし、AWS Copilot が裏で何を作成しているか詳しく知りたいなら、AWS CloudFormation コンソールへアクセスしてスタックの進行状況を確認しましょう。スタックは、 <appName>-<envName> と名づけられるので、今回の場合は、 pubsub-test です。 publisher の作成 現在、皆さんの環境はデプロイ済みであり、当該環境にAmazon ECS クラスタが既に存在するので　皆さんは SNS トピックにメッセージを送信する “publisher” と命名されたマイクロサービスをデプロイすることができます。 まず最初に、 ./publisher ディレクトリを探しましょう。内部には、ロジックを実装する Python ファイルと、コードと依存関係を含むコンテナイメージの作成に用いる Dockerfile があることがわかります。 publisher/ │ ├─ templates │ │ ├─ index.html │ │ └─ order.html │ ├─ requirements.txt │ ├─ publisher.py │ └─ Dockerfile コードはとてもシンプルです。なぜなら、 Flask や Jinja のテンプレートを活用して、以下の画像に示すような小規模なフロントエンドを作成するからです。 フロントエンドは、2つのフィールドを持つフォームを提供しています。一つは顧客名、もう一つは注文金額です。これは、リクエストの処理をトリガーするためのシンプルな方法です。Send ボタンが押されると、マイクロサービスはフォームを処理し、注文のデータを DynamoDB テーブルへ記録し、SNS トピックへメッセージを送信します。それにより、subscriber マイクロサービス上で非同期に処理が開始できます そのようなマイクロサービスを実装するためには、複数のインフラストラクチャコンポーネントを作成する必要があり、そのプロセスに時間がかかる場合があります。インフラストラクチャの作り方を理解するのに時間を費やすよりも、マイクロサービス開発に時間を効率的に使うために、AWS Copilot は いくつかの CLI コマンドや 追加設定した AWS Copilot YAML マニフェストファイルを通して Elastic Load Balancing (Application Load Balancer または Network Load Balancer のいずれか)、Amazon ECR リポジトリ、タスク定義、Amazon ECS タスクに加え、 SNS トピックや DynamoDB テーブルといったリソースを作成する手助けをします。 ここでは、 Load Balanced Web Service と呼ばれる AWS Copilot のパターンを使用し、Amazon ECS サービス 及び パブリックアクセスが可能な Application Load Balancer (ALB) を作成します。そのため、以下のコマンドで実行します。 copilot svc init \ --app pubsub \ --svc-type "Load Balanced Web Service" \ --name "publisher" \ --port 5000 \ --dockerfile "publisher/Dockerfile" 上記のコマンドを実行すると、コンテナイメージを安全に保存でき、プライベートで利用可能なAmazon ECR リポジトリと、サービスの構成オプションが記載されたマニフェストファイルが copilot/publisher/manifest.yml に作成されます。 サービスをデプロイする前に生成された manifest.yml ファイルを確認します。マニフェストファイルがどのようにサービス構成を保持しているか確認し、割り当てられたCPU、メモリ、タスク数などの構成オプションを変更できます。 このウォークスルーでは、2 つの追加リソースを加える必要があります。publisher がメッセージを送信するための SNS トピックとリクエストを保持するデータベースです。 AWS Copilot CLI で SNS トピックを簡単に作成するために、下記のセクションをマニフェストファイルに追加します。 publish: topics: - name: ordersTopic 宣言したトピックごとに AWS Copilot は標準 SNS トピックを作成し、 COPILOT_SNS_TOPIC_ARNS という環境変数を通してリソースの Amazon Resource Name(ARN) を注入します。そして、トピックへメッセージを送信するために Amazon ECS タスクに適切な権限を渡します。当該環境変数は JSON 構造で、key にトピック名、各 key はトピック ARN を value に持ちます。それゆえ Python では、以下のようなコードでこれらの辞書のような構造体にアクセスします。 dest_topic_name = 'ordersTopic' sns_topics_arn = json.loads(os.getenv("COPILOT_SNS_TOPIC_ARNS")) topic_arn = sns_topics_arn[dest_topic_name] ここでは、標準 SNS トピックを作成していることに注意して下さい。FIFO (first-in, first-out) が必要なケースでは、マニフェストファイルにトピック設定に fifo property を追加してこの動作を有効にできます。もし FIFO を有効するならば、全ての subscriber は同様に FIFO SQS キューを利用しなければならないことを覚えておいてください。ここでは、物事をシンプルにするために、標準 SNS トピックを利用します。 データベーステーブルを追加するために、ターミナルで以下のコマンドを実行します。 copilot storage init \ --name ordersTable \ --storage-type DynamoDB \ --workload publisher \ --partition-key id:S \ --no-sort --no-lsi このコマンドは、 copilot/publisher ディレクトリの下に addons/ordersTable.yml を作成します。当該ファイルには、AWS Copilot CLI を用いてデプロイされた DynamoDB テーブルの設定が記載されています。 マニフェストファイルとアドオンファイルで必要なリソースを定義できたので、実際にリソースを作成していきます。ローカルで実行している Docker デーモンが、コンテナイメージをビルドし、その後、Amazon Elastic Container Registry (Amazon ECR) にアップロードされ、Amazon ECS タスクのイメージとして利用されます。 備考：下記のコマンドを実行する前 または コマンドの実行失敗の際には Docker デーモンが起動していることを確認してください。 copilot svc deploy --name publisher --env test ターミナルにリソースの作成状況が表示されます。サービスとアドオンが作成された後、Application Load Balancer の DNS 名を受け取ります。これでインターネットを介して、サービスにアクセスできるようになりました。 1 つ目の subscriber (fulfilment) の作成 前のステップで、注文を送信する publisher 用のインフラストラクチャと サービスを作成しました。しかし、注文を処理する subscriber 用のインフラストラクチャとサービスは作成していません。それでは、1 つ目の subscriber サービスを作成しましょう。まず初めに、下記のコマンドでサービスの定義を作成しましょう。 copilot svc init \ --app pubsub \ --svc-type "Worker Service" \ --name fulfilment \ --port 5000 \ --dockerfile "subscribers/fulfilment/Dockerfile" \ --subscribe-topics "publisher:ordersTopic" ここでは、AWS Copilot CLI が提供する Worker Service というサービスタイプを用います。Worker Service では、バッファとして動作し、メッセージを保持する SQS キュー と AWS Fargate 上で動作する Amazon ECS サービスが作成されます。 さらに、 <svcName>:<topicName> の表記でサブスクライブしたいトピックを選択していることに注目してください。あるいは、上記のフラグ引数をせず、省略することも可能です。その場合、コマンドを実行した際に 既に存在する SNS トピックをサブスクライブするように促されます。その際は、スペースバーを押してトピックを選択し、最後にエンターキーを押します。 Which topics do you want to subscribe to? [Use arrows to move, space to select, type to filter, ? for more help] > [x] ordersTopic (publisher) コマンドが発行されると、 copilot/fulfilment ディレクトリ下にサービス用の新しいマニフェストファイルが作成されていることがわかります。マニフェストファイル内に、トピックのサブスクリプションが追加されたセクションがあることを確認してください。 subscribe: topics: - name: ordersTopic service: publisher 上記の設定により、AWS Copilot CLI は COPILOT_QUEUE_URI 環境変数を注入するため、SQS キュー内のイベントへアクセスする事ができます。キューから何度読んでもアプリケーションが正常に処理できない特定のメッセージがある際、通常 当該メッセージは、手動で検査するために Dead-Letter Queue (DLQ) と呼ばれる別のキューへルーティングされます。AWS Copilot では、DLQ の作成 及び 再送設定 の指定がとても簡単です。皆さんがすることは、以下のセクションをマニフェストファイルに追加することだけです。 subscribe: topics: - name: ordersTopic service: publisher queue: dead_letter: tries: 3 マニフェストを修正したら、以下のコマンドを用いて Amazon ECS 及び AWS Fargate に subscriber サービスをデプロイできます。 copilot svc deploy --name fulfilment --env test 2 つ目の subscriber (promotion) の作成 前のステップでは、ordersTopic トピックに送られた各メッセージを処理する subscriber サービスを作成しました。しかし、いくつかのマイクロサービスでは、受け取った全てのメッセージを処理する必要はなく、特定の特徴を持った一部のメッセージのみ処理する必要があります。そのため、多くの顧客は新しいトピックを作成したり、またはメッセージを処理するかどうかを決定するコンシューマーで何かしらの前処理をします。しかし、それは良いプラクティスではありません。ベストプラクティスは、SNS のネイティブの機能を利用することです。SNS は、メッセージコンテキストに沿ってメッセージ属性を公開することができるため、subscriber は サブスクリプションフィルタリングポリシー を指定して、受信するメッセージを定義できます。これにより、追加のトピックの作成 または 前処理が不要になります。 このステップでデプロイするサービスは、promotion という名前で、$80 以上の注文を処理します。このシナリオでは、20% のクーポンコードが発行され、次回の購入時に利用できます。先にデプロイしたサービスと同様に、以下を実行してサービスを作成します。 copilot svc init \ --app pubsub \ --svc-type "Worker Service" \ --name promotion \ --port 5000 \ --dockerfile "subscribers/promotion/Dockerfile" \ --subscribe-topics "publisher:ordersTopic" SNS トピックサブスクリプションのフィルターポリシーを指定する新しいセクションを copilot/promotion/manifest.yml マニフェストファイルに追加します。 subscribe: topics: - name: ordersTopic service: publisher filter_policy: amount: - numeric: - ">=" - 80 queue: dead_letter: tries: 3 マニフェストを修正した後、以下のコマンドで Amazon ECS 及び AWS Fargate に subscriber サービスをデプロイすることができます。 copilot svc deploy --name promotion --env test 動作確認 全てのマイクロサービスを作成したので、想定通りに機能するかテストします。ブラウザを開き、publisher サービスを作成後に得られたロードバランサーの DNS 名を入力して下さい。もし、DNS 名を忘れてしまった場合、以下のコマンドを実行してください。 copilot svc show --name publisher --json | jq '.routes[0].url' または、以下を実行して下さい。 copilot svc show --name publisher そして、 COPILOT_LB_DNS という変数の値をコピーして下さい。 ページを更新するたびに、新しい名前と注文の合計が生成されますが、必要に応じてフィールドを変更することができます。 このとき、裏側で起きている事象を知るためには、ターミナルを開き、以下のコマンドを実行して下さい。 copilot svc logs \ --name publisher \ --env test \ --follow \ --since 1s 上記のコマンドで publisher サービスのログを表示することができるのため、ウィンドウを調整すれば、フロントエンドの画面とターミナルで同時に確認することができます。最初は何も表示されないかもしれませんが、送信ボタンを押すとすぐに以下のような出力が表示されるはずです。 2 つの subscriber サービスで起きていることを確認するために、以下のコマンドでログを確認します。 copilot svc logs \ --name fulfilment\ --env test \ --follow \ --since 1s copilot svc logs \ --name promotion \ --env test \ --follow \ --since 1s 同時に 3 つのターミナルを起動することをオススメします。それにより、各マイクロサービス内でどのような処理がなされているのか確認することができます。さまざまな金額を入力して、閾値を満たさない注文が promotion マイクロサービスでどのように処理されないかを確認してください。注文が永続化されていることを確認するため、送信された全注文を保持する DynamoDB 内のアイテムテーブルを調べることもできます。 クリーンアップ 将来的な料金の発生を避けるため、リソースを削除します。デモのリソースを正しく作成した場合、以下のコマンドを実行することで全てのサービスと関連するインフラストラクチャは削除されます。 copilot app delete pubsub おわりに AWS Copilot CLI によって pub/sub アーキテクチャを簡単に構築できました。サービスに必要なインフラストラクチャやポリシーの作成に時間を費やすのではなく、必要なリソースをデプロイするのに役立つサービステンプレート と コマンドを使用することで、本当に重要なことに集中できるようになりました。AWS Copilot CLI は、SNS トピックの構築、SQS キューの構築、サブスクリプションの設定、フィルターポリシーの設定、DLQ の構築、再配送設定、サービスへ URI の設定ができるため、publisher と subscriber を作成することが、これまで以上に簡単になりました。 AWS Copilot は、 オープンソースのツール で、 パブリックロードマップ から状況を確認することができます。また、 GitHub issues の作成や Gitter でのディスカッションに 参加頂ける と幸いです。 AWS Copilot Documentation AWS Copilot Public Sprint Board on GitHub AWS Copilot Gitter Chat Room それでは。 翻訳はソリューションアーキテクト祖父江が担当しました。原文は こちら です。

お客様は 2008 年以来、AWS 上で SAP ワークロードを実行しています。SAP と AWS は 14 年以上に渡るパートナーシップと、お客様のために共同でイノベーションを起こしてきました。SAP は、SAP Concur、SAP CX（SAP Qualtrics によるカスタマーエクスペリエンス）、SAP NS2 HANA Secure Cloud などの社内システムやお客様向けサービスの運用に、長年にわたり一貫して AWS サービスを活用してきました。SAP 最大の SAP Business Technology Platform（SAP BTP）のデプロイは AWS 上にあり、お客様が ERP コアを中心にイノベーションを起こせるよう 80 以上のサービスを提供しています。SAP BTP ポートフォリオは、SAP HANA Cloud、SAP Integration Suite、SAP Data Warehouse Cloud、SAP Analytics Cloud など、アプリケーション開発と自動化、プランニング、データ／アナリティクス、統合、人工知能に対応するさまざまなサービスで構成されています。SAP on AWS のお客様は一貫して、クラウドに移行する動機の 1 つは、AWS インフラのコスト削減とスケーラビリティに加えて、ストレージ、データ分析、IoT、機械学習、自動化機能などの AWS サービスと SAP を統合することだと語っています。このようなお客様ニーズから逆算して、AWS と SAP は最初のステップとしてジョイント・リファレンス・アーキテクチャ・ガイダンスを通じてお客様にイノベーションを提供し、その後の自動化を提供するために継続的に投資しています。このブログでは、AWS と SAP が、初期のハイレベルなビジネスユースケースのリファレンスアーキテクチャパターンを通じて、お客様に共同ガイダンスを発行するアプローチについて説明します。また、各アーキテクチャパターンの詳細な実装ガイダンスの追加リファレンスもあります。 RISE with SAP on AWS RISE with SAP は、オンプレミスで SAP やその他の ERP ワークロードを実行し、クラウド上の SAP S/4HANA への移行を検討しているお客様向けの、SAP によるフルマネージドソリューションです。AWSとSAPは、RISE with SAPを通じて、お客様がガイド付きのトランスフォーメーション・ジャーニーを通じて、このビジネス変革を加速できるよう協力してきました。AWS 上の RISE with SAP のお客様は、現在クラウドの旅のどの段階にいるかにかかわらず、迅速に移行、展開、革新することができます。SAP S/4HANA Cloud（RISE with SAP を通じて提供）は、お客様のビジネスプロセスを業界標準に合わせることを支援し、重要なビジネスプロセスの中央リポジトリとして機能を果たします。AWS と連携した SAP BTP は、ERP コアの統合された拡張機能としてアプリケーション開発、統合、アナリティクスのフレームワークを提供することで、 クリーンコア モデルを採用する簡素化されたアーキテクチャアプローチを提供し、移行の簡素化と迅速化、ビジネスプロセスの自動化と最適化、360° アナリティクスなどのメリットをもたらします。 ジョイント・リファレンス・アーキテクチャのアプローチ AWS と SAP は、ビジネスプロセスの統合、拡張、データ管理、アナリティクスシナリオなどの分野のリファレンスアーキテクチャパターンを考案するために提携しています。これらのパターンは、SAP BTP の基本サービスに沿ったプラットフォーム、データ・トゥ・バリュー、アプリケーションを含む 3 つの基本的な柱によって推進されます。これらの柱はそれぞれ、イノベーションに対応し、SAP BTP と AWS のサービスを補完して利用することで、お客様のビジネスオペレーションの効率化を促進します。この図（図1 – SAP BTP on AWS ジョイント・リファレンス・アーキテクチャの概要）は、AWS と SAP BTP のサービスの強みを組み合わせ、プラットフォーム、データ・トゥ・バリュー、アプリケーションの基本的な柱を確立するための包括的なアーキテクチャを表しています。この初期アーキテクチャの焦点は、 SAP Build Work Zone 、 SAP Cloud Integration 、 SAP Data Warehouse Cloud などの SAP BTP の基盤となるサービスと、 Amazon Route 53 、 Amazon Sagemaker 、 Amazon Redshift などの AWS サービスによる、高可用性、ビルトイン弾力性、自動化と技術的負債の削減に重点を置いたイノベーションです。 図 1 – SAP BTP on AWS ジョイント・リファレンス・アーキテクチャの概要 プラットフォーム基盤 ミッションクリティカルなビジネスアプリケーションの基本要件の 1 つは、ビジネスの継続性です。現代のビジネスアプリケーションは、ビジネスの継続性だけでなく、信頼性の向上とレイテンシの低減も要求しています。お客様は、厳格な監視フレームワークと信頼性の高いフェイルオーバー戦略を通じて、障害に強いアーキテクチャを持つことに依存しています。耐障害性の高い実装により、お客様は AWS グローバルインフラストラクチャ を使用して、重要なアプリケーションへの中断のないアクセスを維持します。プラットフォーム基盤の柱では、 Amazon Route 53 サービスと連携して AWS リージョンを活用することで、 SAP Build Work Zone や SAP Integration Suite といった SAP BTP の基盤サービスが高い耐障害性を持つようにすることに注力しています。このアーキテクチャガイダンスの詳細と実装については、 こちら をご覧ください。 データから付加価値を創出 データはあらゆるビジネスにおいて最も価値のある資産の 1 つであり、お客様はますますクラウド上のマルチソースデータストレージ戦略を採用するようになっています。 データフェデレーション 戦略は、データの重複やデータパイプラインを排除することで、マルチソースデータへのリアルタイムアクセスを提供するため、お客様の効率化に役立ちます。また、技術的負債を削減し、総所有コスト（TCO）を最適化することにもつながります。SAP Datasphere（旧名称 SAP Data Warehouse Cloud） を通じて、SAP、 Amazon Redshift 、 Amazon S3 、 Amazon Athena を含む様々なデータソースをセキュアに連携・融合することで、効率的なプランニング、キュレーション、機械学習、アナリティクスを可能にします。Amazon AthenaとSAP Datasphere を使用した双方向データ連携の可能性の 1 つについて、こちらの ブログ で説明しています。 データウェアハウスに蓄積されたデータから、お客様は機械学習技術を駆使して有意義な洞察を引き出し、ビジネスの将来の戦略的ニーズを予測しようとしています。ライブ SQL 接続を使用して、SAP FedML は SAP DWC から Amazon Sagemaker へのデータソースを支援し、AWS データストアと SAP にネイティブに存在する結合データセットに基づいてモデル化、トレーニング、予測を行います。この処理されたデータセットは、AWS 内でネイティブに消費されるか、FedML を通して SAP DWC に戻されます。詳細なアーキテクチャガイダンスについては、こちらの ブログ を参照してください。 統合とアプリケーション開発 現代のアプリケーションは、アプリケーションレイヤーだけでなく、基盤となるインフラやデータレイヤーにもビルトインされた弾力性のあるフレームワークを持つことが期待されており、それによって全体的に分散された弾力性が生まれます。 SAP Cloud Application Programming Model（CAP） は、言語、ライブラリ、ツールのフレームワークとして機能し、開発者を実証済みのベストプラクティスの道へと導き、繰り返し発生するタスクに対してすぐに使える豊富なソリューションを提供します。SAP BTP 内でネイティブに構築されたこれらのアプリケーションは、Amazon Route 53 や Amazon Aurora のような AWS サービスの組み合わせにより、高可用性を実現できます。 Amazon Aurora は、MySQL と PostgreSQL の完全な互換性を備えたクラウド用に構築されたリレーショナルデータベース管理システム（RDBMS）で、商用グレードのデータベースのパフォーマンスと可用性を低コストでお客様に提供します。このアーキテクチャ・ガイダンスの詳細と実装については、 こちら をご覧ください。 SAP BTP と AWS のその他の統合可能性には、 Amazon Simple notification Service （SNS）を活用して通知を送受信する SAP S/4HANA ビジネスプロセス拡張アプリケーションの構築が含まれます。この統合は、より迅速なサポート対応と解決のために、ビジネスプロセスや技術的なアプリケーション監査のためのリアルタイム通知を必要とする企業にとって特に有用です。また、IoT センサーと定期的に相互作用する CAP アプリケーションは、データ受信時に、確立された優先度レベルに基づいて Amazon SNS を使用して必要な通知をトリガーすることができます。こちらの ブログ では、お客様が SAP Business partners を作成する際の SAP S/4HANA 移行シナリオに関連する実際のユースケースを取り上げています。 まとめ このブログでは、SAP BTP と AWS サービスを使用して SAP エコシステムを近代化するためのアーキテクチャパターンを提供する SAP と AWS のハイレベルな戦略について説明しました。各パターンは、実際のユースケースを伴う簡単なソリューション概要とともに説明されています。これらのアーキテクチャパターンの詳細な実装については、SAP の各リファレンスブログで説明されています。このブログは、AWS と SAP が計画している一連の詳細な共同リファレンスアーキテクチャガイダンスの始まりとなります。 SAP on AWS ワークロードのための共同リファレンスアーキテクチャに関して、共同チームが 2022 年に発表した以下のセッションをチェックしてください。 AWS re:Invent 2022 – Accelerate value for your business w w/SAP & AWS reference architecture (PRT105) SAP TechED 2022 – Amplify the Value of SAP Investments on AWS with a Joint Reference Architecture [DT200] さらに参考になる文献をいくつかご紹介します。 SAP and AWS – Joint Reference Architectures to maximize utilization and investments AWS and SAP BTP – Driving more value from your SAP ERP journey to the cloud Query SAP HANA using Athena Federated Query and join with data in your Amazon S3 data lake SAP on AWS 、 Amazon Route53 、 Amazon Sagemaker 、 Amazon Redshift 、 Amazon Athena 、 Amazon Aurora の詳細については、 AWS 製品ドキュメント を参照してください。 さらに専門的なガイダンスが必要な場合は、AWS アカウントチームに連絡して、ローカルの SAP スペシャリストソリューションアーキテクトに依頼してください。 SAP on AWS ディスカッションへの参加 お客様のアカウントチームと AWS サポートチャネルに加えて、私たちは最近 re:Post – A Reimagined Q&A Experience for the AWS Community を立ち上げました。私たちの SAP on AWS ソリューションアーキテクチャチームは、定期的に SAP on AWS トピックを監視し、お客様やパートナー様を支援するためのディスカッションや質問にお答えしています。もしあなたの質問がサポートに関連したものでなければ、re:Post で議論に参加し、コミュニティのナレッジベースに追加することを検討してください。何千ものアクティブなお客様が AWS 上で SAP を実行していることについては、 SAP on AWS のページをご覧ください。 クレジット ジョイント・リファレンス・アーキテクチャに関する AWS と SAP のパートナーシップは、SAP と AWS の組織からの深い協力と貢献の結果です。専門知識、サポート、ご指導をいただいた以下のメンバーに感謝いたします。 チーム AWS：Sabari Radhakrishnan, Sunny Patwari, Rajesh Chigurupati, Yuva Athur, Ganesh Suryanarayanan, Krishnakumar Ramadoss, Spencer Martenson, Adam Hill, Scott Rigney, Soulat Khan and Erik Kamman. チーム SAP：Madankumar Pichamuthu, Sangeetha Krishnamoorthy, Karishm.a Kapur, Weikun Liu, Haridas Nair, Sivakumar N and Anirban Majumdar. 翻訳は Partner SA 松本が担当しました。原文は こちら です。

アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの濱野谷です。2023年7月28日にオンラインで開催された「 テキストから画像への生成系AIによる革新的技術の紹介 」では、生成系 AI によるテキストからの画像生成について３つのセッションをお届けしました。 オープニングで、AWS の AIML GTM スペシャリストの浅倉より、AWS の AI/ML 関連のサービスの一覧の中で、AI による画像生成に関係するサービスの位置づけをご紹介しました。その後、Stability AI Japan の Jerry Chi 様より、画像生成 AI モデルを提供する立場から画像生成 AI 技術の進化と活用事例についてご紹介いただきました。次に株式会社リコーの梅津様より、生成系 AI を活用したソリューションを提供し、顧客価値を創造する取り組みについてご紹介いただきました。最後に、AWS の機械学習ソリューションアーキテクトの呉より、Amazon SageMaker JumpStart を利用した生成系 AI の利用と Fine Tune について紹介いたしました。 「画像生成 AI 技術の進化と活用事例」 Stability AI Japan 株式会社 Head of Japan Jerry Chi 様 Jerry Chi 様からは、 Stability AI Japan 様が提供する画像生成モデルである Stable Diffusion についてご紹介いただきました。Stable Diffusion は2022年8月のリリース以降、日本でも多くのユーザに利用されている、画像生成の人気モデルです。2023年6月23日に最新バージョンの Stable Diffusion XL 1.0 がリリースされました。Stable Diffusion を使用する方法は、１． Stability Platform API を使用する、２． Amazon SageMaker JumpStart のソリューションテンプレートを使用してモデルをデプロイする、３． Amazon Bedrock を使用してAPI経由で使用する、の３つの選択肢から選択できます。 Stable Diffusionは様々な機能を有しています。画像の一部をAIで塗りつぶす inpainting 、写真を枠外に拡張して描画する Uncrop 、１枚の画像から被写体の向きや背景のバリエーションを作成する Reimagine 、ラフスケッチから画像を生成する Stable Doodle などの拡張機能や改造を、Stability AI 様が Web 上で公開している画像編集 AI ツールの Clipdrop で無料で体験することができます。 これらの機能の活用事例として、広告やプロモーションの画像や動画の作成、アニメ制作におけるキャラクター描画や背景の生成、プロダクトや建築・インテリアのデザイン、画像認識モデルの訓練のためのシンセティックデータ（合成データ）生成など幅広い分野での事例もご紹介いただきました。特に、シンセティックデータの生成では、異常検知などデータの収集にお金と時間をかけても集めにくいデータを、早く安く生成することが可能になります。事例では、違法漁業検知 AI の訓練データとして、本物の船の写真を68枚だけ用意し、Stable Diffusion でシンセティックデータを生成した例をお話しいただきました。 まとめとして、今後も生成系 AI の活用は拡大していき誰でもクリエイターになれる時代が来る、それを使いこなすためには、生成される多くの画像をキュレーションしたりプロデュースするスキルが必要になってくる、とのメッセージをいただきました。 「生成系 AI を活用した商品・サービス提供による顧客価値の創造　生成系 AI のソリューション活用に向けて　～リコーの取り組み～」 株式会社リコー デジタル戦略部 デジタル技術開発センター 所長 梅津 良昭 様 株式会社リコーの梅津様からは、生成 AI を活用した顧客価値の創造の事例として、「働く現場での AI 活用」と、「オフィス領域での高度な AI 活用」の２つの取り組みについてご紹介いただきました。 まず、「働く現場での生成 AI 」では、工場設備などのインフラ点検、屋内物流、加工現場などで、画像や映像生成の AI を活用しています。その一例として、工場の配管やメーターをチェックする自動走行式ロボットについてお話しいただきました。ロボットは敷地内のメーターや設備をカメラを使って確認し、異常が有った場合のみ通知を送ります。サビや煙が発生した異常な状態は画像を使ってトレーニングを行う必要が有りますが、実際に異常な状態になった画像を多く集めるのは困難です。そこで、画像生成 AI を使ってトレーニング用の異常系データのバリエーションを生成し、ロボットのトレーニングに活用しているとのことでした。また、ロボットの自動走行のトレーニングにも、走行経路の画像にトラックや荷物などの障害物を追加した画像を生成しているとのことでした。この他にも、VSLAM 技術や振動モニタリング技術などのリコーが得意とするセンシング技術と、AI 技術を組み合わせることで、向上・設備稼働の自動化や、自動点検、警備等のソリューションの提供を目指していくとのメッセージをいただきました。 続いて紹介いただいた「オフィス領域での高度な AI 活用」では、言語系 AI を中心として AI を活用してオフィス領域での業務に価値を提供しています。この領域については、2023 年 4 月の AWS Summit Tokyo でも 事例セッション に登壇いただいています。この領域では、Transformer を用いた LLMの OSS の言語モデルをベースとして、お客様データの追加学習や FineTuning を行う事で、企業に特化したモデルを作成し、業務に活用するソリューションを提供しています。業務活用の事例としては、生成 AI を使い始めるきっかけやユースケースの掘り起こしを目的とした RICHO Chatbot Service からはじまり、企業のドキュメントを使って高度な検索を実現するベクトル検索や、お客様ドキュメントを追加学習したカスタム GPT3 の開発、将来的にはより高度な業務への AI インテグレーションも対応可能とのことです。開発中の AI インテグレーションの例として、眼鏡型ヒアラブル端末を使って、AO 機器の保守エンジニアがトラブル対応時にリコー製 カスタム GPT3 から解決方法の情報を得る例と、対話型サイネージ等でユーザーと対話するデジタルヒューマンの例をお話しいただきました。 最後に、AI を使いたい企業向けにノーコード AI 開発や運用を行える環境の提供を開始したというアナウンスと、使ってみたい企業がいらっしゃれば是非一緒にやっていきたいとのメッセージをいただきました。 「Amazon SageMaker を活用した生成系 AI への第一歩と第二歩の Tuner へのガイド」 [ Slides ] アマゾン ウェブ サービス ジャパン合同会社 機械学習ソリューションアーキテクト 呉 和仁 最後のセッションでは、 Amazon SageMaker を使い、第一歩として基盤モデルのデプロイ、第二歩として FineTune を実施する方法を、デモを使って紹介しました。 <【デモ】生成系AIを使ってみる> 第一歩のデモの中では、最初のセッションでも紹介された Stable Diffusion を利用した画像生成と、 rinna 社の提供する日本語の生成系 AI である japanese-gpt-neo-x-3.6b を利用した言語生成をそれぞれ実施しています。 画像生成では、「印象派風のコテージ」「仕事をしている風景」といった一般的なテキストには、それらしい画像が生成されました。一方で、「呉和仁」という特定の人物を指すテキストには、なんとなく人間のような画像は生成されましたが、本人とは似ていないという課題が発生しました。 テキスト生成では、AIと連歌を嗜もうとしました。最初に、連歌の定義を質問したところ、誤った情報であるハルシネーションを回答するという課題が発生しました。続けて藤原道長の短歌の上の句（五・七・五）「この世をば　わが世とぞ思ふ　望月の」を入力し、下の句（七・七）を詠むように指示を出すと、本来の下の句である「かけたることも　なしと思へば」でも、七・七調でもない句が出力されてしまい、連化にならないという課題が発生しました。これらの課題を解決するのが、後半のデモで実施する Fine Tuneです。 また、デモの中では、 Amazon SageMaker Jump Start を使って提供されるモデルをデプロイしたり、 Amazon SageMaker Studio を使って、公開されている Jupiter Notebook 形式のファイルから簡単に生成系AIの利用を開始していました。このように、AWS のサービスを使うと、アルゴリズムの選定やモデルを動かすまでのトレーニングなどの機械学習の開始に必要な膨大な苦労を回避して、生成系 AI の利用を開始することができます。 <【デモ】生成系AIを Fine Tuneする> 第二歩のデモとして、公開されている学習済みモデルで要件を満たせない場合に、少量のデータで再学習しモデルを微調整する FineTune を実演しました。 画像生成では、第一歩のデモで生成できなかった「呉和仁」の６枚の画像と、プロンプトをS3にアップロードし、Amazon SageMaker JumpStart の Train Model を使って学習します。Fine Tune 後のモデルを使うと、オフィスにいるような画像を生成することが出来ました。 テキスト生成では、古今和歌集、新古今和歌集のデータをクロールしたデータや、現代文の短歌をアップロードし、短歌の特徴に合わせて Fine Tune します。Fine Tune 後のモデルでは、ほぼ七・七調で古文独特の言い回しを用いた下の句を生成することができました。また、このデモの関連記事が builders.flash に掲載されています。 デモを通してお伝えしたように、現在では、多くの企業がモデルを公開しており自由に使うことができます。一方で、同じようなモデルを使う他社と差別化するには、用途に合わせたデータを溜めて Fine Tune することが必要です。そのために、良いデータを溜め続け、顧客体験を改善していくことが差別化の重要要素となります。 最後に、API からサーバレスで基盤モデルを使用できる Amazon Bedrock についても言及が有りました。Amazon Bedrock でも Amazon SageMaker と同様 Fine Tune が可能です。そのため、どのようなサービスで生成系AIモデルを使う場合でも、集めたデータは無駄にならないので、データを集める仕組みを今から検討しましょう、というメッセージを伝えさせていただきました。 質問 セミナーを通して参加者から多くのご質問をいただきました。その中から、ピックアップして回答いたします。 Q. Stable Diffusionで同じ prompt で複数回画像を生成すると、異なる画像が生成されますが、どのような仕組みでしょうか？ Stable Diffusionでは、ランダムノイズを使用して元の画像を生成し、ノイズを除去していくことによって画像を生成します。元のランダムノイズが異なるので、異なる画像が表示されます。 一方で、seed と呼ばれる値で画像の生成を制御することが可能です。デフォルトではランダムな画像が生成されるように設定されていますが、seed に固定値を設定して同じ画像を生成することが可能です。 Q. AWS の SageMaker や Bedrock などのサービスで、入力したプロンプトや FineTune の学習データが公開モデルの学習に使われるということはあるでしょうか？ ありません。お客様の推論およびトレーニングデータは、AWS が提供する基盤モデルの更新やトレーニングに使用、共有されることは有りません。 Q. 初心者が最短で生成系 AI を試すには、どの方法が良いでしょうか？ Amazon SageMaker JumpStart がおすすめです。 事前トレーニング済みのモデルが複数公開されており 、用途に合ったものを選択して簡単にデプロイできます。 Q. デモの中で、6 画像の Fine Tune の所要時間が14分でしたが、Fine Tuneにかかる時間を短縮できるオプションはありますか？ Jobの起動オーバーヘッドが１０分くらい占めるので、実時間は４分程度です。また、Epoch 数やバッチサイズなどハイパーパラメータを調整することでも学習時間を変えられます。 Q. デモの読み上げ音声はどのように実装していたのでしょうか？ Amazon Polly を使って音声を生成しています。 Q. FIne Tune したモデルはどのような費用がかかりますか？使用中の他に、使わない場合も費用が発生しますか？ モデル使用中の料金は、選択するインスタンスのサイズによって料金は異なります。詳しくは、 Amazon SageMaker の料金 のJumpStartの料金をご参照ください。 モデルを Amazon S3 に保存するため、モデルを使用しない間もリージョンの S3 標準タイプの料金 が発生します。S3 の料金はリージョンにより異なりますが、一例として、バージニア北部の S3 標準の料金は、0.023 USD / GB / 月ですので、200MB程度の rinna の Fine Tune 済みモデルを保存すると、月に0.0005 USD 程度の料金が発生します。 まとめ 今回は、「テキストから画像への生成系 AI による革新的技術の紹介」というテーマで、生成系AI によるテキストから画像への生成の基本原理とそのメカニズム紹介いたしました。画像生成 AI モデルを提供する Sitability AI 様と、生成系AIをビジネスに活用するソリューションを提供するリコー様と、それぞれ異なる立場から活用例をご紹介いただき、非常に学びの多いイベントとなりました。また、AWS からは、AWS 上で生成系 AI モデルを動かす方法と、公開されているモデルを Fine Tune して差別化を行っていくためにデータ収集をする重要性をお話しさせていただきました。 これまでの AI/ML 関連イベントの開催報告と登壇スライドは、以下のリンクからご覧いただけます。 AWS AI/ML@Tokyo 開催報告まとめ TAGS: AI/ML@Tokyo , Artificial Intelligence , Generative AI , Amazon SageMaker , AI/ML

本投稿は、ゲストである Grafana Labs の Senior Software Engineer の Michael Mandrus と Amazon Timestream の Senior Technical Product Manager の Igor Shvartser の共著となります。 多くの組織にとって、パフォーマンスとコスト効率の良い監視と分析は、ミッションクリティカルなアプリケーションの要件となっています。この要件に伴い、特に DevOps 、 セキュリティ 、 IoT アプリケーションでよく見られるアクティビティの急増時に、運用ダッシュボードと視覚化を使用する事が増えています。これらのダッシュボードは、多くのアナリストにより同時に表示され、短い間で何度もリロードされますが、こういった頻繁な使用により、コストの急騰やクエリの遅延を招き、チームの生産性の低下につながる事があります。また、より時間に敏感な状況では、ダッシュボードの読み込みを待って時間を無駄にしてしまわない事が重要です。 Grafana は時系列データベースと統合してソフトウェアスタックを監視、視覚化出来る主要なオープン可観測性プラットフォームです。Grafana は頻繁にアクセスされるデータをキャッシュする機能を提供します。また、1 日に数兆件のイベントを処理可能なスケーラビリティを持ち、サーバレスで高速に動作する時系列データベースである Amazon Timestream と統合する事ができます。 幅広い業界のお客様が Grafana を Timstream と統合して利用しており、ダッシュボードからリアルタイムの洞察を導き出し、重要なアプリケーションを監視し、Web サイトやアプリケーションの数百万のリアルタイムイベントを分析しています。Grafana と Timestream を統合して利用する事で、運用ダッシュボードを構築し、ソースとなる Timestream テーブルでは無く、Grafana が保持するキャッシュから結果を読み込む事が出来ます。これによりダッシュボードの読み込み時間が短縮され、クエリコストが削減され、クエリがスロットリングする可能性は低減します。 この投稿では、Timestream のデータを使って Grafana のダッシュボードを作成する方法と、 Grafana Query Caching 機能を使ってクエリキャッシュを構成する方法を紹介します。 ソリューションの概要 Grafana を利用すると、ユーザは パネルのコレクション から構築されたダッシュボードを作成して、様々なソースデータの視覚化を実現できます。 Grafana Plugins Catalog からダウンロードして利用できるプラグインを通じて、様々なデータソースが利用できるようになります。プラグインをインストール後、特定のデータベースへ接続するように構成されたデータソースインスタンスを作成します。データソースの構成、利用方法については Timestream plugin を参照して下さい。また、本ソリューションを利用する際のコストについては注意して下さい。 データソースインスタンスを構成後、クエリを作成し、Grafana で利用可能な可視化の方法を選択して結果を表示させる事により、ダッシュボードパネルを作る事ができます。パネルをロードすると、ダッシュボードで指定された時間範囲を組み合わせたクエリが実行されます。 Grafana のクエリキャッシュ機能 (Grafana Cloud、Grafana Enterprise で利用可能) はデータソースインスタンス、クエリ、及び時間範囲を使用してキャッシュのキーを作成します。パネルがロードされると、Grafana はまずローカルキャッシュで要求されたデータを確認し、見つかった場合はキャッシュからデータを返します。見つからない場合は、Grafana はデータソースに対してクエリを実行し、結果をローカルキャッシュに保存します。つまり、ダッシュボードの初期ロードでは通常の時間がかかりますが、その後の同様の時間範囲を指定したロードはほぼ瞬時に行われる事になります。これは、時間範囲を最も近い間隔にまとめ、キャッシュヒットの可能性を高める事で実現されます。尚、クエリキャッシュとその有効期限 (TTL) はデータソースインスタンス毎に構成できます。 Timestream を始める Timestream の利用を開始するには、チュートリアルとサンプルのアプリケーションを含む こちら を確認して下さい。このチュートリアルでは、サンプルデータセットが入力されたデータベースを作成し、サンプルクエリを実行する方法を示します。また、サンプルアプリケーションは、データベース／テーブルを作成し、テーブルにサンプルデータを設定し、サンプルクエリを実行する方法を示します。AWS コンソールに直接アクセスしたり、AWS コマンドラインインターフェース (CLI) や AWS SDK を使用したりする事も出来ます。 尚、Timestream を初めて利用する場合には、使用量割当の条件を遵守する必要がありますが、1ヵ月間の 無料トライアル で試す事が出来ます。 Timestream プラグインの構成 本セクションでは、データベースキャッシュ機能を備えた Timestream プラグインの構成と使用方法について説明します。Timestream データベースを設定し、Grafana からクエリを実行する為の前提条件と手順については、 こちら を参照して下さい。 1. Timestream プラグインを インストール します。 2. 新しいデータソースを追加します。 3. 接続情報の詳細を入力します。 4. 追加の詳細を入力し、 Save & test を選択して、接続を検証します（スクリーンショットの構成情報は例であり、実際の詳細とは異なる場合がある点に注意して下さい） 5. Cache のタブで、 Enable を選択します。 6. Cache 設定 (オプション) を構成します。 7. クエリを作成し、ビジュアライゼーションを選択してパネルを作成します（スクリーンショットの構成と SQL クエリは例であり、実際の詳細とは異なる場合がある点に注意して下さい） 8. パネルをリロードし、応答がキャッシュされた事を確認します。 これで完了です！必要な可視化が得られるまでは、ダッシュボードの構築を続けましょう。以下は特に広い時間の範囲が選択された Timestream のダッシュボードの例です。クエリサイズ (1 か月分の Timestream データ) が大きい為、初回はダッシュボードを全てロードするのに時間がかかりましたが、リフレッシュ時はクエリキャッシュを利用する為、Timestream へのアクセスは発生せず、ダッシュボードを表示するのに 100 ms 以下 (99% 短縮) で完了しました。 考慮事項 Grafana のクエリキャッシュ機能を使う場合は、現在、以下 2 点の考慮事項があります。 キャッシュキーは特定のタイムスタンプによって決まります。つまり、クエリに利用する時間範囲が既にキャッシュに保存されている時間範囲に収まらない場合は、Grafana はデータベースに対して全く新しいクエリを発行する必要があります。例えば、 t0 から t1 に対してクエリを実行し、次に t0 から t2 に対してクエリを実行すると、Grafana は t1 から t2 では無く、 t0 から t2 に対してクエリを実行します。同じ事は結果のサブセットにも当てはまります。 もしも複数の利用者が同じダッシュボードを同時にロードした際、キャッシュにデータが無い場合は、各クエリは重複排除されずに並行してデータソースに送信され、キャッシュスタンピード (データソースにアクセスが殺到して高負荷となる事) が発生する可能性があります。キャッシュスタンピードを監視する方法としては、Grafana のメトリック grafana_http_requests_in_flight をモニターする事が挙げられます。これは、事象発生時には、同メトリックが増加する為です。また、キャッシュスタンピードを予防するには、 max_conns_per_host や、 max_open_conns_default 等のパラメータを Grafana に設定し、データソースへの接続数を調節する必要があります。 Grafana チームはこれらの制限に対応する拡張機能の可能性を積極的に調査しており、Grafana の将来のバージョンに含める事を検討しています。進捗情報と今後のリリースでの修正にご期待下さい。 結論 本投稿では、Timestream で Grafana クエリキャッシュを利用する方法について説明しました。クエリキャッシュは運用ダッシュボードのパフォーマンスを向上させ、クエリコストを削減する為の重要な機能です。Timestream での Grafana の使用、及びサンプルアプリケーションとダッシュボードの作成について説明する追加ドキュメントについては、 Grafana の Timestream 開発者ガイド を確認して下さい。 Grafana Cloud はメトリクス、ログ、トレース、ダッシュボードを使い始める最も簡単な方法です。また Grafana は最近、永久無料枠として、3 人までのユーザに対して、全てのエンタープライズプラグインへのアクセスを含む新機能を追加しました。さらにあらゆるユースケースに対応するプランも用意しています。今すぐ無料で サインアップ しましょう！ Timestream を確認して開始するには、 こちら をご確認下さい。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

Amazon FSx for Lustre は、オープンソースの Lustre ファイルシステムのスケーラビリティと高いパフォーマンスを備えたフルマネージド型共有ストレージを提供し、Linux ベースのワークロードをサポートします。FSx for Lustre は、ストレージ速度とスループットを重視するワークロードに向いています。これは、FSx for Lustre が、人工知能 (AI) や機械学習 (ML)、ハイパフォーマンスコンピューティング (HPC)、金融モデリング、メディア処理を含むワークロードにおいて、ストレージボトルネックを回避し、コンピューティングリソースの使用率を高め、価値を生み出すまでの時間を短縮できるためです。FSx for Lustre は Amazon Simple Storage Service (Amazon S3) とネイティブに統合され、自動インポートとエクスポートによって双方向の変更を同期するため、高性能な POSIX 準拠のファイルシステムを通じて Amazon S3 データレイクにオンデマンドでアクセスできます。 FSx for Lustre のファイルリリースを8月9日に発表いたしました。この機能により、Amazon S3 と同期されたファイルデータをリリースして、データライフサイクルを管理することができます。ファイルリリースによってストレージスペースが解放されるため、Amazon S3 から FSx for Lustre の遅延読み込みによってリリースされたファイルへのオンデマンドアクセスを保持しながらも、引き続きファイルシステムに新しいデータを書き込むことができます。リリースするディレクトリを指定し、オプションで最終アクセスからの最短時間を指定すると、指定したディレクトリのデータと、最終アクセスからの最短時間 (指定されている場合) のみがリリースされます。ファイルリリースは、使用頻度の低いファイルデータを S3 に移動させることで、S3 階層化を活用できるようにするので、データライフサイクル管理において有用です。 ファイルリリースタスクは、 AWS マネジメントコンソール を使用して開始するか、 AWS CLI 、AWS SDK、または一定間隔でリリース・タスクをスケジュールする Amazon EventBridge スケジューラ を使用して API コールを行うことで開始されます。必要に応じて、リリースタスクの終了時に完了レポートを受け取るように選択できます。 リリースタスクの開始 例として、コンソールを使用してリリースタスクを開始する方法を見てみましょう。リリースするファイルの条件 (ディレクトリや最終アクセスからの時間など) を指定するために、リリースデータリポジトリタスク (DRT) を定義します。DRT は、Amazon S3 と同期され、指定された条件を満たすすべてのファイルをリリースします。リリース DRT は順番に処理されるということに注意してください。つまり、別の DRT (インポートやエクスポートなど) の進行中にリリース DRT を送信すると、リリース DRT はキューに入れられますが、インポートまたはエクスポート DRT が完了するまでは処理されません。 注 : データリポジトリの関連付けを機能させるには、ファイルシステムの自動バックアップを無効にする必要があります (これを行うには、 [バックアップ] タブを使用してください)。次に、ファイルシステムと関連付けられた S3 バケットが同じ AWS リージョンにあることを確認します。 FSx for Lustre ファイルシステム my-fsx-test が既にあります。 ファイルシステム上のディレクトリと S3 バケットまたはプレフィックスとの間のリンクである、 データリポジトリの関連付けを作成 します。 ファイルシステムに関連付ける S3 バケット名または S3 プレフィックスを指定します。 データリポジトリの関連付けを作成したら、 [リリースタスクの作成] を選択します。 リリースタスクは、特定の条件に基づいてリリースしたいディレクトリまたはファイルをリリースします (このリリースが機能するためには、これらのファイルまたはディレクトリを S3 バケットと同期する必要があることに再度ご留意ください)。(ディレクトリに加えて) リリースのための最短最終アクセスを指定した場合、それ以降最近にアクセスされていないファイルがリリースされます。 この例では、完了レポートを [無効にする ] を選択しました。しかし、完了レポートを [有効にする] を選択した場合、リリースタスクはリリースタスクの終了時にレポートを生成します。 リリースされたファイルには、既存の FSx for Lustre 機能を使用して引き続きアクセスでき、Amazon S3 からオンデマンドでデータをファイルシステムに自動的に取得することができます。これはリリースされても、メタデータがファイルシステムに残るためです。 ファイルをリリースしても、ファイルシステムが容量一杯となることを自動的に防ぐわけではありません。次のリリースタスクを実行する前に、使用可能なストレージ容量を超えるデータを書き込まないようにすることが重要です。 今すぐご利用いただけます 本日より、FSx for Lustre のファイルリリースは、FSx for Lustre がサポートされているすべての AWS リージョン、Lustre バージョン 2.12 以降を実行しているすべての新規または既存の S3 リンクファイルシステムでご利用いただけます。FSx for Lustre のファイルリリースでは、追加コストは発生しません。ただし、後でファイルシステムから再びアクセスするファイルをリリースした場合、それらのファイルがファイルシステムに読み込まれる際に、通常の Amazon S3 リクエストとデータ取り出しのコストが発生します (該当する場合)。 詳細については、 Amazon FSx for Lustre ページ にアクセスしてください。また、 AWS re:Post for Amazon FSx for Lustre 、または通常の AWS サポートの担当者までフィードバックをぜひお寄せください。 – Veliswa 原文は こちら です。

このブログは 2023 年 6 月 16 日に Sumiran Tandon（Senior Product Manager）と、Rohit Aswani（Senior Specialist Solutions Architect）、Shubham Singh（Senior Network Specialist Solutions Architect）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 オンプレミスで利用しているアプリケーションがクラウドのストレージを使用する場合、コンプライアンス要件によりプライベート接続が義務付けられることがよくあります。これらの要件を満たすため、お客様は AWS Direct Connect や、 AWS Site-to-Site VPN 接続経由で AWS PrivateLink を使用して、 Amazon S3（S3） へのプライベート接続を構成します。その結果、AWS 間とデータが直接送信され、パブリックインターネットは経由しません。AWS PrivateLink を使用すると、 Amazon Virtual Private Cloud（VPC） にインターフェイスエンドポイントをプロビジョニングして、プライベート IP アドレスを S3 に割り当てます。AWS PrivateLink は、これらのプライベート IP に対してグローバルで一意のパブリック DNS 名を自動的にプロビジョニングします。アプリケーションはこのパブリック DNS 名を使用して S3 にアクセスできます。S3 のリージョナル名（s3.<Region>.amazonaws.com）を使用する際に、オンプレミスのクライアントがこれらのプライベート IP アドレスを指すように、オンプレミスでカスタム DNS エントリを作成できますが、オペレーションのオーバーヘッドが増え管理が困難になるため、この方法はお勧めできません。 プライベート接続の DNS 設定を簡素化するために、S3 インターフェイス VPC エンドポイント でプライベート DNS オプションを サポート しました。S3 のプライベート DNS を使用することで、オンプレミスのアプリケーションからは AWS PrivateLink を使用してインターフェイス VPC エンドポイント経由で S3 にアクセスができ、VPC 内のアプリケーションからのリクエストについては ゲートウェイ VPC エンドポイント を使用して S3 にアクセスできます。このようにリクエストをルーティングすることで、コードの作成やクライアントの設定を変更しなくても低コストでプライベートネットワーク接続を活用できます。 この記事では、AWS PrivateLink を使用してプライベート DNS で S3 にアクセスする方法を説明します。また、さまざまなシナリオの設定オプションについて検討し、クライアントがゲートウェイ VPC エンドポイントとインターフェイス VPC エンドポイントを経由して S3 に接続していることを確認する方法について説明します。 S3 VPC エンドポイント VPC から S3 への接続に使用できる VPC エンドポイント には、ゲートウェイエンドポイントとインターフェイスエンドポイントの 2 種類があります。 ゲートウェイ VPC エンドポイントは、インターネットゲートウェイや VPC の NAT デバイスを必要とせずに、S3 または Amazon DynamoDB への信頼性の高い接続を提供します。ゲートウェイ VPC エンドポイントは AWS マネジメントコンソールで数回クリックするだけで設定でき、VPC ルートテーブルを使用して VPC 内のクライアントからのリクエストを AWS ネットワーク経由で S3 または Amazon DynamoDB のパブリック IP にルーティングできます。ゲートウェイ VPC エンドポイントには追加料金がかからず、ゲートウェイエンドポイントが作成された各 VPC のローカルリソースからの接続のみがサポートされます。 インターフェイス VPC エンドポイントは、 AWS PrivateLink を使用して 140 を超える AWS サービスとサードパーティ SaaS アプリケーション にプライベート接続を提供します。インターフェイス VPC エンドポイントは、VPC サブネットにプライベート IP アドレスを持つ Elastic Network Interface（ENI）を作成します。インターフェイス VPC エンドポイントは、AWS Direct Connect または AWS Site-to-Site VPN を介したオンプレミスからの接続をサポートします。インターフェイス VPC エンドポイントを設定すると、VPC 内とオンプレミスの両方から名前解決が可能な AWS PrivateLink が提供するエンドポイントのパブリック DNS 名 が作成できます。インターフェイス VPC エンドポイントには 2 つの料金があります。1 つは各アベイラビリティーゾーンでプロビジョニングされる各 VPC エンドポイントの時間単位の料金で、もう 1 つは GB 単位のデータ処理料金です。料金の詳細については、 AWS PrivateLink の料金ページ をご覧ください。 S3 にアクセスする最もコスト効率の高い方法は、可能であれば ゲートウェイ VPC エンドポイントを使用（例：リージョンの Amazon EC2 インスタンスからの接続）し、オンプレミスなど他の場所からの接続の場合は インターフェイス VPC エンドポイントを使用することです。 プライベート DNS 名で S3 インターフェイスエンドポイントにアクセス 図 1 は、AWS Direct Connect または AWS Site-to-Site VPN を介してオンプレミスから接続するハイブリッドネットワーク設定を示しています。このセットアップでは、 Amazon Route 53 インバウンド Resolver エンドポイント を設定し、オンプレミスの DNS リゾルバーで条件付きフォワードを設定して DNS クエリをインバウンド Resolver エンドポイントのプライベート IP アドレスに転送します。次に、S3 のインターフェイス VPC エンドポイントを作成すると、プライベート DNS 名を有効にするオプションが表示されます。 図 1: AWS Direct Connectまたは AWS Site-to-Site VPN 経由でオンプレミスから接続する構成 S3 インターフェイス VPC エンドポイントの プライベート DNS を有効にすると、AWS はプライベートホストゾーンを作成し、VPC に関連付けます。このホストゾーンには、以下の S3 DNS 名のプライベート IP を持つインターフェイス VPC エンドポイントのリソースレコードが含まれます。 リージョナルバケット（例：s3.<Region>.amazonaws.com） コントロール（例：s3-control.<Region>.amazonaws.com） アクセスポイント（例：s3-accesspoint.<Region>.amazonaws.com） サービスのリージョナルや、コントロール、アクセスポイントのエンドポイントにリクエストをすることで、S3 への AWS の プライベートネットワーク接続が使用できます。詳細については「 Amazon S3 用の AWS PrivateLink 」のドキュメントを参照してください。 図 1 のウォークスルー オンプレミスのクライアントより、リージョナル S3 バケットをターゲットにした DNS クエリを実施します。 オンプレミスの DNS サーバーは、AWS Site-to-Site VPN または AWS Direct Connect 接続を介して、S3 インターフェイス VPC エンドポイントを持つ同じ VPC に関連付けられている各 Route 53 インバウンド Resolver エンドポイントにクエリを転送します。 Route 53 インバウンド Resolver エンドポイントは、クエリを AWS が管理する Route 53 ホストゾーンに転送し、DNS 応答で S3 インターフェイス VPC エンドポイントの IP アドレスを返します。 オンプレミスのクライアントは、S3 インターフェイス VPC エンドポイントへ接続します。 S3 インターフェイスエンドポイントは、クライアントのクエリを AWS PrivateLink 経由で指定された S3 バケットに転送します。 New： インバウンドエンドポイントのみプライベート DNS を有効にする 多くのお客様は、オンプレミスと AWS リージョンでアプリケーションを所有しており、どちらも同じ VPC の S3 にデータが格納されています。これらのお客様から、オンプレミスからのトラフィックをインターフェイスエンドポイント経由でルーティングし、AWS 内からのトラフィックをゲートウェイエンドポイント経由で簡単にルーティングする方法が欲しいと言われていました。この課題を解決するために、「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」オプションを導入しました。S3 インターフェイスエンドポイントの「 DNS 名を有効化 」を有効にすると、「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」オプションがデフォルトで有効になります。この場合、オンプレミスから S3 への DNS クエリについては S3 インターフェイスエンドポイントのプライベート IP アドレスに名前解決され、 同じ VPC 内のリソースから S3 への DNS クエリについては引き続きゲートウェイ VPC エンドポイントを使用して S3 のパブリック IP アドレスに名前解決されます。この設定が機能するためには、VPC にゲートウェイエンドポイントが構成されている必要があります。VPC にゲートウェイエンドポイントが構成されていない場合にこの設定を有効にしようとすると、AWS マネジメントコンソールに以下のエラーが表示されます（ 図 2 ）。 「To set PrivateDnsOnlyForInboundResolverEndpoint to true, the VPC <vpce_id> must have a Gateway endpoint for the service.」 これを解決するには、VPC にゲートウェイエンドポイントを作成してください。または「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」を無効にして、すべてのトラフィックをインターフェイスエンドポイント経由でルーティングすることもできます。 図 2: PrivateDNSonlyForInboundEndpoint が有効かつゲートウェインエンドポイント未構成時のエラー 前提条件 まず、以下の前提条件が満たされていることを確認してください。 VPC エンドポイント経由で接続したい S3 バケットと同じリージョンに VPC を作成します。 EnableDNShostNames  と  EnableDNSSupport  の 属性 が true に設定されていることを確認してください。 プライベート仮想インターフェイス（VIF）を使用した AWS Direct Connect 接続もしくは AWS Site-to-Site VPN 接続を作成して、データセンターとの接続を確立してください。 手順 1 で作成した VPC に S3 のゲートウェイ VPC エンドポイント を作成し、「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」を有効にしてください。 S3 インターフェイス VPC エンドポイント作成とプライベート DNS オプション有効化 S3 インターフェイス VPC エンドポイントを作成するために、VPC コンソールに移動し「 エンドポイント 」を選択し、「 エンドポイントを作成 」をクリックしてください。 「 サービスカテゴリ 」で「 AWS のサービス 」を選択します。次に、検索ボックスに「S3」を入力してサービス名をフィルタリングします。「 サービス名 」のサービスが「S3」となっており、「 タイプ 」が「Interface」と表示されていることを確認してください（ 図 3a ）。 図 3a: S3 インターフェイスエンドポイント作成 VPC とアベイラビリティーゾーン、サブネットをそれぞれ選択し、適切なセキュリティグループを選択します。セキュリティグループには、オンプレミスネットワークからのポート 443 のインンバウンドトラフィックを許可するよう構成してください。 「 追加設定 」 で、インターフェイスエンドポイントの「 DNS 名を有効化 」を選択します。デフォルトで「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」は選択されており、VPC 内部からのトラフィックはゲートウェイ VPC エンドポイントを経由し、オンプレミスからのトラフィックはインターフェイス VPC エンドポイントを経由します。 「 エンドポイントを作成 」 を選択します。以下のスクリーンショット（ 図 3b ）を参照してください。 図 3b: プライベート DNS オプションの有効化 エンドポイントはさまざまな ステータス を経て作成されるため少々時間がかかります。インターフェイスエンドポイントのステータスが「使用可能」になったら、「 詳細 」を選択して設定を表示できます（ 図 4a ）。「DNS 名」フィールドに、サービスへのアクセスに使用される DNS 名が表示されます。プライベート DNS を有効にすると、デフォルトの S3 リージョン DNS 名も表示されます。 図 4a: インターフェイス VPC エンドポイントの詳細 「 サブネット 」を選択すると、インターフェイスエンドポイントの場所や、各サブネットのエンドポイントネットワークインターフェイス ID が表示されます。以下のスクリーンショット（ 図 4b ）では、VPC のエンドポイントネットワークインターフェイスのプライベート IP アドレスは 10.0.4.122 と 10.0.23.155 となっています。 図 4b: インターフェイス VPC エンドポイントのサブネット情報 プライベート DNS オプションのシナリオ S3 ゲートウェイとインターフェイス VPC エンドポイントを使用して、VPC とオンプレミスでホストされているアプリケーションから S3 へのクライアント接続に影響を与える DNS オプションのさまざまな組み合わせについて理解しましょう。 シナリオ 1：プライベート DNS 無効 この構成では、ゲートウェイエンドポイントが作成された VPC 内のクライアントからのトラフィックは S3 リージョナルエンドポイントに接続できます。VPC 外のクライアント（オンプレミスまたは相互接続された別の VPC）からは、エンドポイント固有の DNS 名を使用するか、この ブログ で説明しているオプションを使用して S3 に接続できます。プライベート DNS が false に設定されている場合、「インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint）」は設定できません。 このオプションは、独自のプライベートホストゾーンでプライベート DNS 名を柔軟に管理したい場合に便利です。 ゲートウェイエンドポイントを使用する VPC 内のクライアント dig s3. <Region> .amazonaws.com +short 54.x.y.z (Public IP address(es) of S3 service endpoint) エンドポイント固有の DNS 名を使用する VPC またはオンプレミスのクライアント dig *.vpce-0cd6fd8a1a7d95f7e-4nyak8fx.s3. <Region> .vpce.amazonaws.com +short 10.0.23.155 10.0.4.122 上記の出力結果では、VPC 内のクライアントが S3 サービスエンドポイントのパブリック IP アドレスに名前解決されているのに対して、データセンターのクライアントは S3 の VPC エンドポイント ENI IP アドレスに名前解決されていることを示しています。 シナリオ 2：プライベート DNS 有効 この構成では、VPC 内トラフィックとオンプレミストラフィックの両方が S3 インターフェイス VPC エンドポイントを経由して流れます。このオプションは DNS の管理を簡素化するので、1 種類のエンドポイントのみを使用するようにアーキテクチャをシンプルにしたい場合に便利です。ただし、VPC のリソースから S3 へのトラフィックに対して、S3 インターフェイス VPC エンドポイントのデータ転送料金も発生するため、コスト効率の高いソリューションではありません。 図 5 に示すように、緑と青の色は VPC とオンプレミス環境内の EC2 インスタンスから S3 インターフェイス VPC エンドポイントを経由してトラフィックが流れていることを示しています。 図 5: 「プライベート DNS」を有効、「インバウンドエンドポイントのみプライベート DNS を有効にする」を無効 図 5 のウォークスルー 手順 1 ～ 5 はすべて 図 1 で説明した内容と同じです。ただし、 「プライベート DNS」が有効になっているため、VPC 内およびオンプレミスのクライアントのみが S3 インターフェイス VPC エンドポイント経由で S3 に接続します。 VPC 内のクライアント dig s3. <Region> .amazonaws.com +short 10.0.23.155 10.0.4.122 オンプレミスアプリケーションのクライアント dig s3. <Region> .amazonaws.com +short 10.0.23.155 10.0.4.122 上記の出力結果は、VPC 内のクライアントとオンプレミスのクライアントの両方が S3 VPC エンドポイント ENI IP アドレスに解決されていることを示しています。 シナリオ 3：インバウンド Resolver エンドポイントのみにプライベート DNS を使用する この構成では、VPC 内のアプリケーションからのトラフィックはゲートウェイ VPC エンドポイントを経由し、オンプレミスからのトラフィックは S3 インターフェイス VPC エンドポイントを経由します。このオプションでは、VPC およびオンプレミスアプリケーション内から S3 にアクセスする際に費用対効果の高いネットワーク設計を提供します。この構成を選択する際には、VPC 内のゲートウェイ VPC エンドポイントを維持する必要があります。これは、トラフィックが常に AWS プライベートネットワーク上に留まるようにするためです。ゲートウェイエンドポイントがない場合に、VPC 内のトラフィックが誤ってインターネットゲートウェイを経由したり、インターネットゲートウェイがない場合にドロップされる可能性を排除できます。このため、アプリケーションを実行している VPC にゲートウェイ VPC エンドポイントが存在しない場合は「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」オプションが選択できなくなります。既存のインターフェイスエンドポイントを「インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint）」に更新したい場合は、VPC に S3 ゲートウェイ VPC エンドポイントが構成されていることを確認する必要があります。ゲートウェイ VPC エンドポイントとプライベート DNS 名の管理の詳細については、AWS PrivateLink ガイドの「 ゲートウェイエンドポイント 」と「 VPC エンドポイントサービスの DNS 名を管理する 」をそれぞれ参照してください。 図 6  では、青いパスはゲートウェイ VPC エンドポイントを経由する VPC 内の Amazon EC2 インスタンスからのトラフィック示しており、緑のパスはインターフェイス VPC エンドポイントを使用するオンプレミスから S3 へのトラフィックフローを示しています。 図 6: 「プライベート DNS」を有効、「インバウンドエンドポイントのみプライベート DNS を有効にする」を有効 図 6 のウォークスルー 手順 1 ～ 5 はすべて 図 1 説明した内容と同じです。ただし、「 プライベート DNS 」と「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」の両方が有効になっているため、VPC 内のクライアントは S3 のゲートウェイ VPC エンドポイント経由で S3 に接続し、オンプレミスのクライアントは S3 のインターフェイス VPC エンドポイント経由で S3 に接続します。 ゲートウェイエンドポイントを使用する VPC 内のクライアント $ dig s3. <Region> .amazonaws.com +short 54.x.y.z (Public IP address(es) of S3 service endpoint) インターフェイスエンドポイントを使用するオンプレミスのクライアント $ dig s3. <Region> .amazonaws.com +short 10.0.23.155 10.0.4.122 「プライベート DNS」と「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」 の両方が有効になっている場合は、ゲートウェイ VPC エンドポイントを削除できません。削除しようとすると、以下のエラーが出力されます。 「Gateway endpoint cannot be deleted while Interface endpoint for the service has PrivateDnsOnlyForInboundResolverEndpoint set to true.」 上記が発生した場合にゲートウェイ VPC エンドポイントを削除するには、インターフェイス VPC エンドポイントを変更し「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」 オプションの選択を解除する必要があります。 まとめ この記事では、S3 インターフェイス VPC エンドポイントにプライベート DNS を使用して、オンプレミスアプリケーションを変更せずに S3 にアクセスする方法について説明しました。S3 へのネットワーク接続を最適化するために「 インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint） 」オプションを使用する方法について説明しました。これらのオプションを使用すると、コードの作成やクライアントに設定変更をしなくても、低コストのプライベートネットワーク接続が活用できます。S3 用の AWS PrivateLink の使用を開始するには、この ページ にアクセスしてください。 S3 用の AWS PrivateLink の詳細については、以下のブログを参照してください。 Secure hybrid access to Amazon S3 using AWS PrivateLink Choosing Your VPC Endpoint Strategy for Amazon S3 AWS Partners use AWS PrivateLink to connect privately to Amazon S3 翻訳はプロフェッショナルサービス本部の葉山が担当しました。 Sumiran Tandon Sumiran は、ワシントン州シアトルに拠点を置く Amazon S3 チームの AWS のシニアプロダクトマネージャーです。彼女は、顧客が複雑なビジネス上の課題を解決できるように、革新的でお客様中心の製品を構築することに重点を置いています。彼女はデューク大学でMBAの学位を取得しています。 Rohit Aswani Rohit は、AWS のネットワーキングを専門とするシニアスペシャリストソリューションアーキテクトであり、スケーラブルで可用性が高く、安全で、回復力があり、費用対効果の高いネットワークをお客様が構築および設計できるよう支援しています。ノースイースタン大学でコンピューターネットワークを専門とする電気通信システム管理の修士号を取得しています。余暇には、Rohit はハイキング、旅行、新しいコーヒーショップの探索を楽しんでいます。 Shubham Singh Shubham は AWS のシニアネットワークスペシャリストソリューションアーキテクトです。彼は、お客様が AWS サービスを使用して革新的で回復力があり、費用対効果の高いソリューションを設計できるよう支援しています。彼はテクノロジーに情熱を注いでおり、ネットワークとセキュリティのソリューションを構築することを楽しんでいます。ノースイースタン大学でコンピューターネットワークを専門とする電気通信システム管理の修士号を取得しています。

第 5 回の AWS Storage Day へようこそ! このバーチャルイベントは、8月9日、太平洋標準時の午前 9:00 (東部標準時正午) に開催され、 AWS On Air Twitch チャンネル で視聴できます。最初の AWS Storage Day は 2019 年に開催されました。このイベントはイノベーションデーへと発展し、毎年皆様をお迎えできることを楽しみにしています。 昨年の Storage Day の投稿 で、データを安全に保護しながら活用できるようにすることを目指した AWS Storage の絶え間ない革新について書きました。今年の Storage Day は、AI/ML 用のストレージ、データ保護と耐障害性、およびクラウドへの移行のメリットに焦点を当てています。 AWS Storage Day の主要テーマ AI/ML 用のストレージ に関しては、データ量はかつてない速度で増加しており、テラバイトからペタバイト、さらには エクサバイトにまで 急増しています。AWS の最新のデータアーキテクチャでは、 スケーラブルなデータレイク を迅速に構築し、目的別に構築された幅広いデータサービスを使用したり、パフォーマンスを犠牲にすることなくシステムを低コストで拡張したり、組織の境界を越えてデータを共有したり、コンプライアンス、セキュリティ、ガバナンスを管理したりできるため、規模を問わず迅速かつ機敏に意思決定を行うことができます。 機械学習モデルをトレーニングして 生成系 AI アプリケーションを構築 するには、適切なデータ戦略を策定する必要があります。ライブイベントで楽しみにしているセッションのリストの中で、 Optimize generative AI and ML with AWS Infrastructure (生成系 AI と ML を AWS インフラストラクチャで最適化する) セッションでは、データを有意義なインサイトに変換する方法について話し合います。 クラウドを使い始めたばかりか、 アプリケーションを AWS に移行することを計画しているか 、既に AWS でアプリケーションを構築しているかにかかわらず、 データを保護し、事業継続目標を達成する のに役立つリソースがあります。当社の データ保護 と 耐障害性 の機能およびソリューションは、目標復旧時点 (RPO) と目標復旧時間 (RTO) 全体にわたって、ビジネス継続性目標を達成し、データ損失が発生した際のディザスタリカバリを実現するのに役立ちます。今日、世界では前例のないほどのデータ増加が起こっているため、データの保存場所、保護方法、およびデータにアクセスできるユーザーの決定は、かつてないほど優先度が高まっています。 Protect data in AWS amid a rapidly evolving cyber landscape (急速に進化するサイバー情勢の中で AWS でデータを保護する) セッションにぜひ参加して、詳細をご覧ください。 データを クラウドに 移動 する場合、さまざまなユースケースに合わせてどこにデータを移動するか、移動するデータの種類、利用可能なネットワークリソースなどを把握する必要があります。クラウドに移行する理由はたくさんあります。最近、 Enterprise Strategy Group (ESG) は、組織がオンプレミスのワークロードを AWS クラウドインフラストラクチャに移行することで、コンピューティング、ネットワーク、およびストレージのコストを最大 66% 削減したことを検証しました。ESG は、オンプレミスのワークロードを AWS に移行することで、組織はコストの削減、パフォーマンスの向上、運用効率の向上、価値実現までの時間の短縮、ビジネスの俊敏性の向上を実現できることを確認しました。 お客様のユースケースに基づいて、クラウドへの移行方法について説明するセッションを多数用意しています。私が最も楽しみにしているのは、 Hybrid cloud storage and edge compute: AWS, where you need it (ハイブリッドクラウドストレージとエッジコンピューティング: 必要な場所で AWS) セッションです。このセッションでは、完全にクラウドに移行できないワークロードに関する考慮事項について説明します。 これらすべてのテーマなどに対応する AWS Storage サービスの幅広いポートフォリオ や機能に関連する新しい発表、リーダーシップに関するインサイト、教育コンテンツについて、専門家から話を聞きましょう。本日、 Amazon Simple Storage Service (Amazon S3) 、 Amazon FSx for Windows File Server 、 Amazon Elastic File System (Amazon EFS) 、 Amazon FSx for OpenZFS などに関する発表があります。 以下に詳細を示します。 Amazon EBS の 15 年 少し前に、 Jeff Barr の「AWS ブログを執筆して 15 年」というタイトルの記事 を読みました。 この記事では、Jeff が初期の AWS のサービスと機能について執筆した記事をいくつか紹介しています。 Amazon Elastic Block Store (Amazon EBS) は、 Amazon EC2 の使用を簡素化するサービス としてこのリストに含まれています。 Amazon EBS の発売が発表されてから 15 年が経ち、8月9日、このサービスの 15 周年を祝います。Amazon EBS を有効に活用し、当社が考案と簡素化、繰り返し、改善に役立つ非常に有益なフィードバックを提供してくれた最初のユーザーの一人なら、光陰矢の如しと感じていらっしゃることでしょう。現在、Amazon EBS は毎日 100 兆件を超える I/O オペレーションを処理しており、毎日 3 億 9,000 万を超える EBS ボリュームが作成されています。 Amazon EBS を初めてご利用になる場合は、AWS のセールス、マーケティング、グローバルサービス担当シニアバイスプレジデントである Matt Garman との炉辺談話にご参加ください。2008 年のサービス開始の背景にあった戦略とお客様が抱えていた課題についてお話します。また、EBS の長期顧客である Stripe から、12 年前に Stripe が設立されて以来 EBS とともに成長してきた話も聞くことができます。 Amazon EBS は、Amazon EC2 インスタンスの直接的なストレージアタッチメントとして、より多くのお客様のワークロードをサポートするために、スケーラビリティとパフォーマンスを継続的に改善してきました。8 月 2 日、カスタム第 4 世代 Intel Xeon Scalable プロセッサを搭載した Amazon EC2 M7i インスタンスがリリース されたことで、前世代 M6i インスタンスの 28 個から増加し、最大 128 個の Amazon EBS ボリュームをアタッチできます。ボリュームアタッチメントの数が多いほど、インスタンスあたりのストレージ密度を高め、リソース使用率を向上させ、総コンピューティングコストを削減できます。 大規模なデータベースアプリケーションでは、1 インスタンスあたり最大 127 のコンテナをホストでき、コスト効率の高い方法でスケーリングできます。これにより、追加のインスタンスをプロビジョニングする必要がなくなり、必要なリソースに対してのみ支払いが発生します。ボリュームアタッチメントの数が多いほど、データベースのストレージフットプリントが拡大しても、このような強力な M7i インスタンスで利用できるメモリと vCPU を最大限に活用できます。また、EBS では、作成できるマルチボリュームスナップショットの数を増やしており、最大 128 個の EBS ボリュームをインスタンスにアタッチできます。これにより、インスタンスにアタッチされたすべてのボリュームの Crash-consistent バックアップを作成できます。 15 years of innovations with Amazon EBS (Amazon EBS とともにイノベーションを起こして 15 年) セッションに参加して、Amazon EBS の最初のビジョンが、クラウドインフラストラクチャに対するお客様の高まる需要を満たすためにどのように進化してきたかについて話し合いましょう。 Mountpoint for Amazon S3 現在一般提供されている Mountpoint for Amazon S3 は、高スループットのアクセスを実現し、Amazon S3 上のデータレイクのコンピューティングコストを削減する新しいオープンソースのファイルクライアントです。Mountpoint for Amazon S3 は、ローカルファイルシステム API 呼び出しを S3 オブジェクト API 呼び出しに変換するファイルクライアントです。Mountpoint for Amazon S3 を使用すると、Amazon S3 バケットをローカルファイルシステムとしてコンピューティングインスタンスにマウントし、Amazon S3 の伸縮自在なストレージとスループットを備えたファイルインターフェイスを介してオブジェクトにアクセスできます。Mountpoint for Amazon S3 は、 既存のファイルに対する順次読み取り操作とランダム読み取り操作、および新しいファイルを作成するための順次書き込み操作 をサポートします。 Deep dive and demo of Mountpoint for Amazon S3 (Mountpoint for Amazon S3 の詳細説明とデモ) セッションでは、ファイルクライアントを使用してファイル API を使って Amazon S3 のオブジェクトにアクセスする方法を示します。これにより、データを大規模に保存しやすくなり、分析と機械学習のワークロードによってデータの価値を最大化できるようになります。 このブログ記事 を読んで、Mountpoint for Amazon S3 の詳細と開始方法 (デモを含む) をご覧ください。 Amazon S3 Glacier Flexible Retrieval でコールドストレージをより迅速に稼働させる Amazon S3 Glacier Flexible Retrieval は、追加費用なしでデータ復元時間を最大 85% 短縮します。 Amazon S3 バッチオペレーション を使用する際、より高速なデータ復元が自動的に標準取得層に適用されます。これらの復元は数分以内にオブジェクトを返し始めるため、復元されたデータをより迅速に処理できます。復元されたデータを継続的な復元と並行して処理することで、データワークフローを加速し、ビジネスニーズに迅速に対応できます。これで、メディアのトランスコーディング、運用バックアップの復元、機械学習モデルのトレーニング、履歴データの分析を行っていようと、アーカイブからのデータ復元を高速化できます。 2022 年に発表された、 S3 Glacier を改善して数百万のオブジェクトに対して最大 10 倍のスループットを復元できるようにしたこと と相まって、あらゆる規模の S3 Glacier データ復元で、開始時間の短縮と完了時間の短縮というメリットがもたらされました。 Maximize the value of cold data with Amazon S3 Glacier (Amazon S3 Glacier でコールドデータの価値を最大化する) セッションに参加して、あらゆる規模のあらゆる業界の組織がデータアーカイブを変革してビジネス価値を引き出し、俊敏性を高め、ストレージコストを節約する上で、Amazon S3 Glacier がどのように役立つかを学んでください。 このブログ記事 を読んで、Amazon S3 Glacier Flexible Retrieval のパフォーマンスの向上について詳しく学び、S3 Glacier Flexible Retrieval からより高速な標準取り出しを開始する方法についてのステップバイステップのガイダンスをご覧ください。 幅広いファイルワークロードをサポート ファイルシステムに依存する幅広いユースケースに対応するため、当社はそれぞれ異なるニーズに対応したファイルシステムサービスのポートフォリオを用意しています。 Amazon EFS は、コンピューティングリソース間でデータを共有するために柔軟なエクスペリエンスが得られるように構築されたサーバーレスファイルシステムです。Amazon FSx を使用すると、機能豊富で高性能なファイルシステムをクラウドで簡単かつ費用対効果の高い方法で起動、実行、拡張できます。これにより、コード、プロセス、またはデータの管理方法を変更せずにクラウドに移行できます。 Amazon EFS で ML 研究とビッグデータ分析を強化する Amazon EFS は、ストレージ容量とスループットパフォーマンスの両方で高いスケーラビリティを実現するように設計された、サーバーレスで完全にスケーラブルなファイルストレージを提供します。ちょうど7月31日週、より高速な読み取り/書き込み IOPS のサポートが強化され、より要求の厳しいワークロードの処理が容易になったことを発表しました。Amazon EFS のパフォーマンス性能が向上し、ファイルシステムあたり最大 55,000 件の読み取り IOPS と最大 25,000 件の書き込み IOPS がサポートされるようになりました。このようなパフォーマンスの強化により、KubeFlow による機械学習 (ML) 研究、IBM Symphony による金融シミュレーション、Domino Data Lab、Hadoop、Spark によるビッグデータ処理など、より要求の厳しいワークフローの実行を支援します。 Build and run analytics and SaaS applications at scale (分析と SaaS アプリケーションを大規模に構築して実行する) セッションに参加して、最近の Amazon EFS パフォーマンスの改善がどのようにさらに多くのワークロードの強化に役立つかを聞いてください。 Amazon FSx for OpenZFS のマルチ AZ ファイルシステム Amazon FSx for OpenZFS でファイルシステムを作成する際にマルチ AZ 配置オプションを使用できるようになりました。これにより、複数の AWS アベイラビリティーゾーンにまたがるファイルストレージを簡単にデプロイできるようになり、ビジネスクリティカルなワークロードにマルチ AZ レジリエンスを提供できます。今回のリリースでは、Amazon FSx for OpenZFS のパワー、俊敏性、シンプルさを活用して、幅広いワークロードに対応できます。これには、複数の AZ にまたがる可用性の高い共有ストレージを必要とするデータベース、基幹業務、ウェブサービスアプリケーションなどのビジネスクリティカルなワークロードが含まれます。 新しいマルチ AZ ファイルシステムは、さまざまなワークロードに対応する高レベルのパフォーマンスを実現するように設計されています。これには、金融サービス分析、メディアおよびエンターテイメントワークフロー、半導体チップ設計、ゲーム開発およびストリーミングなどのパフォーマンスを重視するワークロードが含まれ、頻繁にアクセスされるキャッシュデータでは最大 21 GB/秒のスループットで 100 万 IOPS、永続ディスクストレージからアクセスするデータでは最大 10 GB/秒で 350,000 IOPS を実現します。 Migrate NAS to AWS to reduce TCO and gain agility (NAS を AWS に移行して TCO を削減し、俊敏性を向上させる) セッションに参加して、Amazon FSx for OpenZFS によるマルチ AZ について詳しく学びましょう。 Amazon FSx for Windows File Server の新しい、より高いスループットキャパシティレベル Amazon FSx for Windows File Server のパフォーマンスの向上により、SQL Server データベース、メディア処理、クラウド動画編集、仮想デスクトップインフラストラクチャ (VDI) など、パフォーマンスを重視するワークロードの結果が出るまでの時間を短縮できます。 4 つの新しい高スループットキャパシティレベルを追加して、使用可能な最大 I/O を以前の I/O である 2 GB/秒から最大 12 GB/秒に増やします。このようなスループットの向上は、それに応じてディスク IOPS のレベルも高くなり、最大 350,000 IOPS まで向上するように設計されています。 さらに、FSx for Windows File Server を使用することで、SSD ファイルシステムのデフォルトの 3 IOPS/GiB よりも高い IOPS をプロビジョニングできます。これにより、SSD IOPS をストレージ容量とは無関係にスケールできるため、パフォーマンスが重視されるワークロードのコストを最適化できます。 Migrate NAS to AWS to reduce TCO and gain agility (NAS を AWS に移行して TCO を削減し、俊敏性を向上させる) セッションに参加して、Amazon FSx for Windows File Server のパフォーマンス向上について詳しく学びましょう。 AWS Backup 用の論理的にエアギャップのあるボールト AWS Backup は、フルマネージド型のポリシーベースのデータ保護ソリューションです。これにより、お客様は (コンピューティング、ストレージ、データベースにわたる) 19 の AWS サービスと、VMware Cloud on AWS やオンプレミスなどのサードパーティーアプリケーション、および SAP HANA on Amazon EC2 にわたってバックアップの復元を一元化および自動化できます。 8月9日、マルウェアイベントを軽減するための追加の保護レイヤーとして機能する新しいタイプの AWS Backup Vault として、 論理的にエアギャップのあるボールトのプレビューを発表しました 。論理的にエアギャップのあるボールトにより、お客様は別の信頼できるアカウントを通じてアプリケーションデータを回復できます。 Deep dive on data recovery for ransomware events (ランサムウェアイベントの際のデータ復旧に関する詳細情報) セッションに参加して、AWS Backup の論理的にエアギャップのあるボールトについて詳しく学びましょう。 AWS DataSync を使用して他のクラウドとの間でデータをコピーする AWS DataSync はオンラインのデータ移動および検出サービスです。これにより、データ移行が簡素化され、ファイルまたはオブジェクトデータを AWS ストレージサービスとの間で迅速、簡単、安全に転送できます。DataSync は、AWS ストレージサービスとの間でのデータ移行のサポートに加えて、Google Cloud Storage、Azure Files、Azure Blob Storage などの他のクラウドとの間のコピーもサポートしています。DataSync を使用すると、他のクラウド上の Amazon S3 互換ストレージと Amazon S3 などの AWS ストレージサービスとの間でオブジェクトデータを大規模に移動できます。現在、他のクラウドとの間でデータをコピーできるように DataSync のサポートを拡大しており 、DigitalOcean Spaces、Wasabi Cloud Storage、Backblaze B2 Cloud Storage、Cloudflare R2 Storage、Oracle Cloud Storage などもサポートされています。 Identify and accelerate data migrations at scale (大規模なデータ移行を識別し促進する) セッションに参加して、この DataSync のサポートの策だいについて詳しく学びましょう。 オンラインでご参加ください Twitch の AWS On Air チャンネルで AWS Storage Day のバーチャルイベントに今すぐご参加ください 。このイベントは、太平洋標準時の 8 月 9 日の午前 9 時 (東部標準時正午) からライブ配信が始まります。すべてのセッションは、Storage Day の約 2 日後にオンデマンドで提供される予定です。 お会いできるのを楽しみにしています! –  Veliswa  原文は こちら です。

Mountpoint for Amazon S3 は、ファイル対応の Linux アプリケーションが Amazon Simple Storage Service (Amazon S3) バケットに簡単に直接接続できるようにするオープンソースのファイルクライアントです。2023年初めにアルファリリースとして 発表されましたが 、現在一般公開されており、データレイク、機械学習トレーニング、画像レンダリング、自動運転車シミュレーション、ETL など、読み取り負荷の多い大規模なアプリケーションで本番環境で使用できるようになりました。シーケンシャル読み取りとランダム読み取り、シーケンシャル (追加のみ) 書き込みを実行するファイルベースのワークロードをサポートし、POSIX の完全なセマンティクスを必要としません。 なぜファイルなのか? 多くの AWS のお客様は、 S3 API と AWS SDK を使用して、S3 バケットの内容を一覧表示、アクセス、処理できるアプリケーションを構築しています。ただし、多くのお客様は、UNIX スタイルでファイルにアクセスする方法（ディレクトリの読み取り、既存のファイルのオープンと読み取り、新しいファイルの作成と書き込み）を知っている既存のアプリケーション、コマンド、ツール、およびワークフローを持っています。これらのお客様から、大規模な S3 への高性能なアクセスをサポートする、エンタープライズ対応の公式クライアントを求められています。これらのお客様と話し、多くの質問を投げかけた結果、パフォーマンスと安定性が主な関心事であり、POSIX 準拠は必須ではないことがわかりました。 2006 年に Amazon S3 について 初めて書いたとき 、Amazon S3 はファイルシステムとしてではなく、オブジェクトストアとして使用することを目的としていることは明らかでした。Mountpoint/S3 コンボを使用して Git リポジトリなどを保存するのは望ましくありませんが、S3 のスケールと耐久性を活用しながらファイルを読み書きできるツールと組み合わせて使用することは、多くの状況で理にかなっています。 マウントポイントのすべて のマウントポイント は、概念的には非常にシンプルです。マウントポイントを作成し、そのマウントポイントに Amazon S3 バケット (またはバケット内のパス) をマウントし、シェルコマンド ( ls 、 cat 、 dd 、 find など)、ライブラリ関数 ( open 、 close 、 read 、 write 、 creat 、 opendir など)、またはすでに使用しているツールや言語でサポートされている同等のコマンドと関数を使用してバケットにアクセスします。 内部では、 Linux 仮想ファイルシステム (VFS) がこれらのオペレーションをマウントポイントへの呼び出しに変換し、さらにマウントポイントが S3 への呼び出し ( LIST 、 GET 、 PUT など) に変換されます。 マウントポイント は、ネットワーク帯域幅を有効に活用してスループットを向上させ、より多くの作業をより短時間で行うことでコンピューティングコストを削減できるように努めています。 マウントポイント は、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスから、または Amazon Elastic Container Service (Amazon ECS) または Amazon Elastic Kubernetes Service (EKS) コンテナ内で使用できます。また、既存のオンプレミスシステムにインストールすることもでき、直接、または AWS PrivateLink for Amazon S3 を介した AWS Direct Connect 接続経由で S3 にアクセスすることもできます。 Mountpoint for Amazon S3 のインストールと使用 マウントポイント は RPM 形式で提供されており、Amazon Linux を実行している EC2 インスタンスに簡単にインストールできます。RPM を取得して yum を使ってインストールするだけです。 $ wget https://s3.amazonaws.com/mountpoint-s3-release/latest/x86_64/mount-s3.rpm $ sudo yum install ./mount-s3.rpm ここ数年、私は定期的に ワシントン州フェリー のウェブカメラのいくつかから画像を取得して、自分の wsdot-ferry バケットに保存してきました。 私は、これらの画像を収集して、フェリーの出入りを追跡し、ある時点でそれらを分析して、最適な乗車時間を見つけることを目的としています。今日の私の目標は、丸一日分の画像を素敵なタイムラプスにまとめた映画を作ることです。まず、マウントポイントを作成してバケットをマウントします。 $ mkdir wsdot-ferry $ mount-s3 wsdot-ferry wsdot-ferry マウントポイントをトラバースしてバケットを調べることができます。 $ cd wsdot-ferry $ ls -l | head -10 total 0 drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 2020_12_30 drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 2020_12_31 drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 2021_01_01 drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 2021_01_02 drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 2021_01_03 drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 2021_01_04 drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 2021_01_05 drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 2021_01_06 drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 2021_01_07 $ $ cd 2020_12_30 $ ls -l total 0 drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 fauntleroy_holding drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 fauntleroy_way drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 lincoln drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 trenton drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 vashon_112_north drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 vashon_112_south drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 vashon_bunker_north drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 vashon_bunker_south drwxr-xr-x 2 jeff jeff 0 Aug 7 23:07 vashon_holding $ $ cd fauntleroy_holding $ ls -l | head -10 total 2680 -rw-r--r-- 1 jeff jeff 19337 Feb 10 2021 17-12-01.jpg -rw-r--r-- 1 jeff jeff 19380 Feb 10 2021 17-15-01.jpg -rw-r--r-- 1 jeff jeff 19080 Feb 10 2021 17-18-01.jpg -rw-r--r-- 1 jeff jeff 17700 Feb 10 2021 17-21-01.jpg -rw-r--r-- 1 jeff jeff 17016 Feb 10 2021 17-24-01.jpg -rw-r--r-- 1 jeff jeff 16638 Feb 10 2021 17-27-01.jpg -rw-r--r-- 1 jeff jeff 16713 Feb 10 2021 17-30-01.jpg -rw-r--r-- 1 jeff jeff 16647 Feb 10 2021 17-33-02.jpg -rw-r--r-- 1 jeff jeff 16750 Feb 10 2021 17-36-01.jpg $ 1つのコマンドでアニメーションを作成できます。 $ ffmpeg -framerate 10 -pattern_type glob -i "*.jpg" ferry.gif そして、これが私が得るものです。 ご覧のように、 マウントポイント を使用して既存のイメージファイルにアクセスし、新しく作成したアニメーションを S3 に書き戻しました。これはかなり単純なデモですが、既存のツールとスキルを使用して S3 バケット内のオブジェクトを処理する方法を示しています。何年にもわたって数百万の画像を収集してきたことを考えると、それらをローカルファイルシステムに明示的に同期せずに処理できることは大きなメリットです。 Mountpoint for Amazon S3 に関する情報 マウントポイント を使用する際に留意すべき点がいくつかあります。 価格 – マウントポイント を使用しても新しい料金は発生しません。お支払いいただくのは、基礎となる S3 オペレーションに対してのみです。また、 マウントポイント を使用して、リクエスタ支払いバケットにアクセスすることもできます。 パフォーマンス – マウントポイント は、各 EC2 インスタンスと S3 間の 最大100 GB/秒のデータ転送 など、S3が提供する柔軟なスループットを活用できます。 認証情報 – マウントポイント は、バケットをマウントしたときに有効な AWS 認証情報を使用して S3 バケットにアクセスします。認証情報、バケット設定、リクエスタ支払いの使用、S3 Object Lambda の使用に関するヒントなどの詳細については、 CONFIGURATION ドキュメントを参照してください。 オペレーション とセマンティクス – マウントポイント は基本的なファイル操作をサポートしており、最大5 TB のサイズのファイルを読み取ることができます。既存のファイルを一覧表示して読み取ることができ、新しいファイルを作成することもできます。既存のファイルを変更したり、ディレクトリを削除したりすることはできません。また、シンボリックリンクやファイルロックもサポートしていません (POSIX のセマンティクスが必要な場合は、 Amazon FSx for Lustre をご覧ください)。サポートされているオペレーションとその解釈の詳細については、 SEMANTICS ドキュメントを参照してください。 ストレージクラス – マウントポイント を使用して、S3 Glacier Flexible Retrieval、S3 Glacier Deep Archive、S3 Intelligent-Tiering アーカイブアクセス層、S3 Intelligent-Tiering ディープアーカイブアクセス層を除くすべてのストレージクラスの S3 オブジェクトにアクセスできます。 オープンソース – マウントポイント はオープンソースであり、公開ロードマップがあります。お客様の貢献は大歓迎です。必ず最初に私たちの 貢献ガイドライン と 行動規範 をお読みください。 ホップオン ご覧のように、 マウントポイント は非常に優れており、アプリケーションで使用するための素晴らしい方法がいくつか見つかると思います。annチェックして、感想を教えてください! – Jeff ; 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 AWS Dev Day 2023 のオンデマンド配信 は、2023 年 8 月 31 日までの期間限定で配信されています。クラウド開発に関する最新のテクノロジーや手法について、技術解説セッション、ユーザー事例、デモ、ライブコーディングなどの、合計 59 のセッションを通じて幅広く学ぶことができます。すぐに視聴を開始いただけますので、ぜひこの機会にご登録ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2023 年 8 月 7 日週の主要なアップデート 8/7(月) Amazon Interactive Video Service announces Real-Time Streaming Amazon IVS でレイテンシーが 300 ミリ秒以下のリアルタイムライブ配信を、 最大 1 万人の視聴者に配信できるようになりました。これまでは、低遅延ストリーミング機能により、レイテンシーが3 秒未満のライブ配信をサポートしていました。リアルタイムストリーミング機能を利用することで、より低レイテンシーでライブ配信が出来るようになり、ソーシャルメディアアプリケーションやオークションのような低レイテンシーが重要なユースケース向けにサービスを提供しやすくなりました。詳細は こちらのブログ をご確認ください。 AWS Security Hub launches 12 new security controls AWS Security Hub で新たに 12 個のセキュリティコントロールをリリースしました。Security Hub の機能の一つに、AWS アカウント上のリソース設定状況を基に、セキュリティのベストプラクティスから逸脱されているものを自動的に検出してくれるものがあります。今回のアップデートで、検出を行うためのコントロールが追加され、Amazon Athena、 Amazon DocumentDB、Amazon Neptune が検出対象に追加されました。 8/8(火) AWS Glue Studio now supports Amazon CodeWhisperer in additional regions AWS Glue が利用できる全てのリージョンで、Glue Studio ノートブックと Amazon CodeWhisperer を連携してコードを生成する機能が利用できるようになりました。利用できるリージョンに東京・大阪の両方が含まれています。例えば、Glue Studio ノートブックに「JSON ファイルから Spark DataFrame を作成する」といったコメントを英語で記述すると、このコメントに合わせて自動的にコードを生成します。これにより素早い開発が可能になります。詳細は こちらのブログ をご確認ください。 AWS Global Accelerator extends IPv6 support to EC2 endpoints AWS Global Accelerator で、IPv4 と IPv6 を利用できる dual-stack accelerator に、EC2 エンドポイントを追加できるようになりました。dual-stack accelerator を使うことで、Global Accelerator が IPv4 と IPv6 の両方の IP アドレスを持ちます。これにより、IPv4 と IPv6 のトラフィックに対して AWS Global Accelerator のメリットである可用性、セキュリティ、パフォーマンスなどの向上が期待できます。これまで dual-stack accelerator は ALB のみの対応でしたが、このアップデートで IPv6 の ENI を持っている EC2 インスタンスを追加できるようになりました。 8/9(水) You can now scale IOPS separately from storage on Amazon FSx for Windows File Server Amazon FSx for Windows File Server で SSD ストレージタイプを構成する際に、ファイルシステムのストレージ容量とは別に、IOPS (1 秒あたりの IO) を追加できるようになりました。これまでは、1 GiB あたりのストレージ容量に対して 3 IOPS が固定で付与されていました。今回のアップデートで 1 GiB あたり最大 500 IOPS を追加できるようになりました。高い IOPS 性能を求める際に、不要なストレージ容量を追加する必要がなくなり、コストをより最適化できるようになりました。 Amazon S3 Glacier Flexible Retrieval improves data restore time by up to 85% Amazon S3 Glacier Flexible Retrieval で、データの取り出しに掛かる時間を最大 85 % 改善しました。この改善に伴う追加の料金はありません。Amazon S3 Glacier Flexible Retrieval は S3 ストレージクラスの 1 つで、より安価なストレージ料金を提供します。1 年に 1 ~ 2 回ほどアクセスし、リアルタイム取り出しが不要なアーカイブやバックアップデータの格納に最適なストレージクラスです。いままではデータ取り出しに掛かる時間が 3 ~ 5 時間ほどでしたが、今回のアップデートで数分以内にデータの取り出しが開始できるようになりました。データの取り出しは、プロセスの進捗に応じて段階的に取得されます。 Mountpoint for Amazon S3 is now generally available Mountpoint for Amazon S3 の一般提供が開始しました。Mountpoint for Amazon S3 は、 GitHub で公開されている オープンソースの S3 アクセスクライアントです。大規模なデータセット (テラバイトからペタバイトのサイズ) を読み取り、拡張性や高スループットを必要とするワークロードに最適です。例えば、機械学習トレーニングなどのユースケースがあげられます。このソフトウェアはよく質問を受けるので、いくつかの注意点を記載します。一見、EBS 等にアクセスするかのように S3 にアクセスができますが、S3 上のオブジェクトを操作している以上、一般的なストレージとは違うものだと考える必要があります。例えば性能特性は大きく異なりますし、現時点ではロック機能はサポートされていません。つまり普通のファイルシステムだと考えず、このソフトウェアを利用することのメリット・デメリットを検討の上でご利用ください。Mountpoint for Amazon S3 のファイルシステムの動作に関する詳細は こちら をご参照ください。今後のロードマップについては こちら で公開されています。 AWS Fargate now supports process ID namespace sharing and kernel parameter configuration Amazon ECS on AWS Fargate で、稼働するコンテナの PID namespace の共有と、一部のカーネルパラメータ設定 (sysctl) をサポートしました。PID namespace を共有すると、ECS の 1 タスクで複数のコンテナを起動した際に、複数のコンテナ間でプロセスを参照できるようになります。ユースケースを一つあげると、コンテナセキュリティを監視するための製品の中には、PID namespace の共有が必要な場合があり、これに対応できるようになりました。カーネルパラメータ設定は、アプリケーションの特性に応じて、カーネルの動作を最適化できるようになりました。一つ例をあげると、net.ipv4.tcp_keepalive_time を変更して、Fargate で実行されているアプリケーションの接続をより長く維持できるようになりました。 Amazon Interactive Video Service announces live video output price changes Amazon Interactive Video Service の低遅延ストリーミングのライブビデオ出力価格が最大 50% 値下げになりました。ビデオ出力の時間あたりの料金は、韓国で最大 50%、インドで 46%、台湾で 43%、オーストラリアで 41%、南米で 30%、日本、香港、東南アジアで 29% 削減されます。さらに、低遅延ストリーミングのライブビデオ出力の価格は、利用量に応じて段階的に下がる仕組みが備わっています。例えば、日本で HD 解像度 (720p) で配信を行う場合、最初の 10,000 時間までは 1 時間あたり $0.0460 の価格です。次の 40,000 時間までは、1 時間あたり $0.0420 の価格に下がります。500,000 時間まで 5 段階の価格で提供される仕組みがあります。詳細は こちら をご確認ください。 8/10(木) Network Load Balancer now supports security groups Network Load Balancer (NLB) がセキュリティグループをサポートしました。これまでは、NLB にセキュリティグループを指定できなかったため、例えば NLB と EC2 間に限定した通信制御の設定が難しい場合がありました。このアップデートで NLB に直接セキュリティグループを適用できるようになったため、NLB と EC2 間のネットワーク通信などをより厳密に、より簡単に構成できるようになりました。 Amazon EventBridge Schema Registry and Schema Discovery now in additional regions Amazon EventBridge Schema Registry と Schema Discovery の機能が、大阪リージョンを含めた、いくつかのリージョンで利用できるようになりました。複数のチームがそれぞれシステムを開発する際に、互いのシステムが受け取るイベントのスキーマを理解したうえで、リクエストを投げる必要があります。EventBridge Schema Registry を使用すると、チームが公開しているイベントの構造を共有できるため、他のチームがイベントを組み込んだ実装を見つけて作成できるようになります。使いどころの詳細は、 こちらの資料 もご活用ください。 8/11(金) Amazon EventBridge API Destinations is now available in additional regions Amazon EventBridge API Destinations の機能が、大阪リージョンを含めた、いくつかのリージョンで利用できるようになりました。API Destinations を利用すると、任意の HTTP API を定義して送信できるようになり、EventBridge 上のイベントと連携がやりやすくなります。HTTP API を接続する際の認証方式として、ベーシック認証・OAuth のクライアントクレデンシャル・ API key に対応しています。例えば、これらの認証方式に対応している SaaS アプリケーションとの連携がやりやすくなります。 Amazon QuickSight launches hierarchy layout for pivot tables Amazon QuickSight 上でピボットテーブルを利用する際に、新しいレイアウトとして要素を階層化したレイアウトが利用できるようになりました。視覚的にわかりやすい階層表示が出来るオプションが追加され、ユースケースに合わせた最適なレイアウトを選択しやすくなりました。新しい階層化したレイアウトは、スペースを節約しながら大量のデータを表示し、カテゴリごとのデータを明確で読みやすく表示したい場合に最適です。新しい 階層化したレイアウトに関する Blog があり、画像を使って新しいレイアウトが紹介されています。どういったことができるのかを視覚的に理解できるため、こちらもご活用ください。 それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

2022年、 Amazon S3 Glacier は 10 周年を迎えました。Amazon S3 Glacier はクラウドコールドストレージのリーダーであり、私は、 過去 10 年間のそのイノベーションについて書きました 。 Amazon S3 Glacier ストレージクラスには、データを最小のコストで最適にアーカイブできる、長期的で安全で耐久性のあるストレージオプションが用意されています。Amazon S3 Glacier ストレージクラス ( Amazon S3 Glacier Instant Retrieval 、 Amazon S3 Glacier Flexible Retrieval 、 Amazon S3 Glacier Deep Archive ) は、コールドデータ専用に構築されており、ミリ秒単位から数日単位で柔軟に取得することができるほか、1 テラバイトあたり 1 か月 1 USD という低価格でアーカイブデータを保存できます。 多くのお客様から、将来的な価値が見込めることを認識しているため、データを長期間保存している、アーカイブデータのサブセットをすでに収益化している、または将来的に大量のアーカイブデータを使用する予定である、という声が寄せられています。 最新のデータアーカイブ は、 コールドデータのストレージコストを最適化するだけではありません 。データをビジネスに役立てる必要があるときに、ビジネス要件に応じて迅速にアクセスできるようにするメカニズムを設定することも重要です。 2022 年に、AWS のお客様は Amazon S3 Glacier から 320 億を超えるオブジェクトを復元しました。お客様は、 メディアのトランスコーディング 、 運用バックアップの復元 、 機械学習 (ML) モデルのトレーニング 、 または履歴データの分析を行う際に 、アーカイブされたオブジェクトを迅速に取得する必要があります。S3 Glacier Instant Retrieval をご利用のお客様は、わずか数ミリ秒でデータにアクセスできますが、S3 Glacier Flexival Retrieval は低コストで、1～5 分以内の迅速な取得、3～5 時間以内の標準的な取得、5～12時間以内の無料の一括取得という 3 つの取得オプションが用意されています。S3 Glacier Deep Archive は、当社で最も低コストのストレージクラスであり、標準取得オプションでは 12 時間以内、一括取得オプションでは 48 時間以内にデータを取得できます。 2022 年 11 月、 Amazon S3 Glacier は S3 Glacier Flexible Retrieval と S3 Glacier Deep Archive で大量のアーカイブデータを取得する場合に、追加コストなしで復元スループットを最大 10 倍向上させました。 Amazon S3 バッチオペレーション では、より速い速度で自動的にリクエストを開始できるため、ペタバイトのデータを含む数十億ものオブジェクトを復元できます。 10 年にわたるコールドストレージの技術革新の流れを継続するため、 S3 Glacier Flexival からの標準取り出しを、追加費用なしで最大 85% 高速化することを8月9日に発表しました 。S3 バッチオペレーションを使用すると、より高速なデータ復元が標準取得層に自動的に適用されます。 S3 バッチオペレーションを使用すると、取得するオブジェクトのマニフェストを提供し、取得層を指定することで、アーカイブされたデータを大規模に復元できます。S3 バッチオペレーションでは、標準取得層での復元では、通常 3～5 時間かかっていたオブジェクトが数分以内に返されるようになり、アーカイブからのデータ復元を簡単にスピードアップできます。 さらに、S3 バッチオペレーションは、ジョブに新しいパフォーマンスの最適化を適用することで、全体的な復元スループットを向上させます。その結果、データをより迅速に復元し、復元されたオブジェクトをより迅速に処理できます。復元されたデータを継続的な復元と並行して処理することで、データワークフローを加速し、ビジネスニーズに迅速に対応できます。 S3 Glacier Faster Standard Retrievals からのより高速な標準取得の開始 このようにパフォーマンスが向上した状態でアーカイブされたデータを復元するには、S3 バッチオペレーションを使用して S3 オブジェクトに対して大規模および小規模の両方のバッチオペレーションを実行できます。S3 バッチオペレーションでは、指定した S3 オブジェクトのリストに対して 1 つのオペレーションを実行できます。S3 バッチオペレーションは、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI)、SDK、または REST API から使用できます。 バッチジョブを作成するには、 Amazon S3 コンソールの左側のナビゲーションペイン で Batch Operations (バッチオペレーション) を選択し、 Create job (ジョブの作成) を選択します。マニフェスト形式の 1 つ、つまり取得したいオブジェクトキーを含む S3 オブジェクトのリストを選択できます。マニフェスト形式が CSV ファイルの場合、ファイルの各行にはバケット名、オブジェクトキー、およびオプションでオブジェクトバージョンを含める必要があります。 次のステップでは、マニフェストにリストされているすべてのオブジェクトに対して実行するオペレーションを選択します。 復元 オペレーションでは、指定した S3 オブジェクトのリストにあるアーカイブオブジェクトの復元リクエストが開始されます。復元オペレーションを使用すると、マニフェストで指定されているすべてのオブジェクトに対して復元が要求されます。 S3 Glacier Flexible Retrieval ストレージクラスの 標準取得層 を使用して復元すると、自動的により高速な取得が可能になります。 AWS CLI を使用して S3InitiateRestoreObject ジョブで復元ジョブを作成することもできます。 $aws s3control create-job \ --region us-east-1 \ --account-id 123456789012 \ --operation '{"S3InitiateRestoreObject": { "ExpirationInDays": 1, "GlacierJobTier":"STANDARD"} }' \ --report '{"Bucket":"arn:aws:s3:::reports-bucket ","Prefix":"batch-op-restore-job", "Format":" S3BatchOperations_CSV_20180820","Enabled":true,"ReportScope":"FailedTasksOnly"}' \ --manifest '{"Spec":{"Format":"S3BatchOperations_CSV_20180820", "Fields":["Bucket","Key"]},"Location":{"ObjectArn":"arn:aws:s3:::inventory-bucket/inventory_for_restore.csv", "ETag":"<ETag>"}}' \ --role-arn arn:aws:iam::123456789012:role/s3batch-role その後、次の CLI コマンドを実行して、リクエストのジョブ送信のステータスを確認できます。 $ aws s3control describe-job \ --region us-east-1 \ --account-id 123456789012 \ --job-id <JobID> \ --query 'Job'.'ProgressSummary' ジョブステータスの表示と更新、通知とログの追加、ジョブの失敗の追跡、完了レポートの生成を行うことができます。S3 バッチオペレーションジョブのアクティビティは、 AWS CloudTrail にイベントとして記録されます。ジョブイベントを追跡するには、 Amazon EventBridge でカスタムルールを作成し、これらのイベントを Amazon Simple Notification Service (Amazon SNS) などの任意のターゲット通知リソースに送信できます。 S3 バッチオペレーションジョブを作成する場合、すべてのタスクまたは失敗したタスクのみの完了レポートをリクエストすることもできます。完了レポートには、オブジェクトキーの名前とバージョン、ステータス、エラーコード、エラーの説明など、各タスクに関する追加情報が含まれています。 詳細については、Amazon S3 ユーザーガイドの ジョブステータスと完了レポートの追跡 を参照してください。 以下は、それぞれサイズが 100 MB の 250 個のオブジェクトを含むサンプル取得ジョブの結果です。 以前の復元パフォーマンス の線 (右側の青い線) からわかるように、これらの復元は通常、標準取得を使用すると 3～5 時間で終了します。現在、S3 バッチオペレーションで標準取得を使用すると、 向上したパフォーマンス の線 (左のオレンジ色の線) に示されているように、ジョブは通常数分以内に開始され、データの復元時間が最大 85% 短縮されます。 詳細については、AWS Storage Blog の Amazon S3 Glacier ストレージクラスからアーカイブされたオブジェクトの大規模な復元 と Amazon S3 ユーザーガイドの アーカイブされたオブジェクトの復元 を参照してください。 今すぐご利用いただけます Amazon S3 Glacier Flexible Retrieval のより高速な標準取得が、AWS GovCloud (米国) リージョンと中国リージョンを含むすべての AWS リージョンで利用できるようになりました。このパフォーマンスの向上は、追加費用なしでご利用いただけます。 S3 バッチオペレーションとデータ取得には料金がかかります。詳細については、 S3 料金のページ を参照してください。 最後に、 Amazon S3 Glacier でコールドストレージの価値を最大化 というタイトルの新しい eBook を公開しました。この eBook を読んで、Amazon S3 Glacier が、規模や業界を問わず、データアーカイブを変革してビジネス価値を引き出し、俊敏性を高め、ストレージコストを削減する方法を学んでください。 詳細については、 S3 Glacier ストレージクラスのページと 入門ガイド にアクセスし、 AWS re:Post for S3 Glacier にフィードバックを送信するか、通常の AWS サポート窓口を通じてフィードバックを送信してください。 この新機能を使い始めることを本当に楽しみにしています。また、アーカイブデータを使用してビジネスを改革するさらに多くの方法についてお聞きできることを楽しみにしています。 — Channy 原文は こちら です。

動的に変化するリソース群全体を、簡単に監視しアラームを設定するのに苦労していませんか？ 利用料がかかっている不要な大量のアラームが存在し、把握できなくなっていませんか？増減するリソースに合わせて、自動的に調整されるアラームを簡単に作成する方法を探してますか？ このブログでは、使用されなくなった AWS リソースにアラームが発生するリスクや新しい AWS リソースが監視されないままになるリスクが軽減するために、Amazon CloudWatch を使用した推奨されるコスト効率の高い方法について説明します。 この方法により、古くなったり、廃止されたメトリクスやリソースに関するアラーム、有効性は低いが料金を支払わなければならないアラームが存在してしまうリスクが軽減され、さらに、CloudWatch ダッシュボードの視認性が悪くなるといったリスクが軽減されます。Metrics Insights クエリを使用して作成されたアラームは、そのシンプルさと単一の定義により、集計アラームに対する運用のオーバーヘッドやコストが低くなります。また、AWSリソースの出入りに応じて自動的に調整されるため、アラームが滞留するリスクが低減されます。 以前のブログ では、価値の低いアラームを特定して削除する方法に関する自動化ソリューションを紹介しました。このブログでは、動きの速い環境を一貫して監視し、異常が検出されたときに警告する動的アラームを設定する方法について説明します。 Amazon CloudWatch Metrics Insights アラームを使用すると、標準的な SQL クエリを使用して、動的に変化するリソース群全体のアラームを 1 つのアラーム設定で可能にします。CloudWatch Metrics Insights は、高速で柔軟な SQL ベースのクエリを提供します。CloudWatch アラームと Metrics Insights クエリを組み合わせることで、動きの速い環境を一貫して監視し、異常が検出されたときにアラートを出す動的アラームを設定できるようになります。 一般的なユースケース ここでは、リソースの変化にすばやく対応するためにアラームが必要な場合と、アラームを手動で管理するのが困難な場合の 2 つの一般的なユースケースについて説明します。どちらのユースケースでも、Metrics Insights クエリでアラームすることがどのように役立つのかをご紹介します。 １つ目のユースケースでは、アカウント内の任意の Amazon DynamoDB テーブルへのリクエストが、そのテーブルにプロビジョニングされた読み込みキャパシティーユニットを超え、スロットリングイベントが発生したときにアラームがトリガーされます。2つ目のユースケースでは、アカウント内のいずれかの Amazon ECS クラスターが HTTP 5XX レスポンスコードを生成したときにアラームがトリガーされます。 ユースケース １. DynamoDB スロットリングの検出 アカウントのすべての DynamoDB テーブルの読み取りスロットルイベントを監視する一般的なユースケースを考えてみましょう。これは、DynamoDB がプロビジョニングした量よりも大量の読み取りリクエストを受け取った場合に発生します。これにより、アプリケーションが応答しなくなったり、新しいユーザーやトランザクションがブロックされたりする可能性があります。 この監視を実装する一般的な方法の1つは、Metric Math を使用して個々の「ReadThrottleEvents」メトリクスを集約し、その Metric Math の結果をアラームすることです。 この方法の注意点は、たとえば、新しい DynamoDB テーブルが追加された場合、 Metric Math は自動的に更新されないため、新しい DynamoDB テーブルを見逃したり、新しく追加されたリソースのエラーを見逃したりするリスクがあることです。ここで、ユーザーは手動で Metric Math を更新し、新しい DynamoDB テーブルのメトリクススを追加する必要があります。同様に、DynamoDB テーブルが削除された場合は、Metric Math を手動で更新する必要があります。さらに、1 つの Metric Math で許可される量よりも多くのメトリクスを集約する必要がある場合は、Metric Math に基づくアラームを 1 つではなく 2 つ作成する必要があります。 Metrics Insights アラームでは、複数のリソースを監視するMetrics Insights クエリを使用してアラームを設定できます。新しいリソースが追加されたり、既存のリソースが削除されたりしても心配する必要はありません。上記の例では、新しい DynamoDB テーブルが追加されると、Metrics Insights アラームは、ユーザーが手動で操作することなく、変更に動的に適応することができます。 ユースケース ２. ECS クラスターの 5XX エラーへの対応 アカウント内のいずれかの ECS クラスターが HTTP 5XX レスポンスコードを生成したときにアラートを受け取りたい、別のユースケースを考えてみましょう。 そのための一般的な方法では、まず ECS クラスターごとに報告された個々の「HttpCode_Target_5xx_Count」メトリクスを集計する Metric Math を作成し、この Metric Math の結果に対して、アラームを設定する必要があります。 この方法の注意点は、たとえば、新しい ECS クラスターが追加された場合、Metric Math が自動的に更新されないため、新しく追加されたリソースのエラーを見逃してしまう危険性があることです。ここで、ユーザーは手動で Metric Math を更新し、新しい ECS クラスターによって報告されたメトリクスを追加する必要があります。同様に、ECS クラスターが削除されると、Metric Math を手動で更新する必要があります。 Metrics Insights アラームでは、複数のリソースを監視する Metrics Insights クエリを使用してアラームを設定できます。新しいリソースが起動したり、既存のリソースが削除されたりしても心配する必要はありません。上記の例では、新しい ECS クラスターが追加されると、Metrics Insights アラームは変更に対して動的に適応するため、ユーザーによる手動操作は必要とせずに、アラームがしきい値を超えた場合にアラートを送信できます。 図 1. Metrics Insights – Query Builder ソリューション概要 このソリューションでは、前述のユースケースに対応する Metrics Insights アラームが作成されます。Metrics Insights アラーム「DDBReadThrottleAlarm」を「ReadThrottleEvents」メトリクスを監視してアラームするようにプロビジョニングします。また、「ECSTarget5XXAlarm」を「HTTPCode_Target_5XX_Count」メトリクスを監視してアラームするようにプロビジョニングします。以下の AWS CloudFormation テンプレートの起動時にアラームが発生するにしきい値を設定できます。このソリューションでは、アラームが発生した場合に通知する SNS トピックも用意されており、起動プロセスの一部としてメールアドレスを設定できます。このソリューションは、お客様のユースケースに関連する他の AWS サービスやメトリクスにも拡張できます。 ソリューションのデプロイ このソリューションと関連リソースは、AWS CloudFormation テンプレートとしてお客様の AWS アカウントにデプロイできます。 前提条件 このチュートリアルでは、次の前提条件を満たす必要があります。 AWS アカウントを保有していること。 Amazon DynamoDB テーブルと Amazon ECS クラスターが存在していること。 CloudFormation テンプレートは何をデプロイしますか？ CloudFormation テンプレートは、以下のリソースを AWS アカウントにデプロイします。 Amazon CloudWatch Metrics Insights アラーム DDBReadThrottleAlarm – 「ReadThrottleEvents 」メトリクスを監視し、アカウント内の任意の DynamoDB テーブルで読み取りスロットリングイベントが生成されたときにアラートを出します。 ECSTarget5XXAlarm – HTTPCode_Target_5XX_Count メトリクスを監視し、アカウント内のいずれかの ECS クラスターが HTTP 5XX レスポンスコードを生成したときにアラートを出します。 この CloudFormation テンプレートは、任意のメトリクスを使用するように変更できます。 Amazon SNS トピック AlarmNotificationTopic – アラームがトリガーされたときにメール通知を送信します。 CloudFormation テンプレートをデプロイする方法 yaml ファイルをダウンロードします 。 AWS アカウントの CloudFormation コンソールに移動します。 「スタックの作成」を選択します。 「テンプレートの準備完了」 を選択し、「テンプレートファイルのアップロード」を選択します。「ファイルの選択」で先ほどダウンロードした yaml ファイルを選択します。 「次へ」を選択します。 スタックに名前を付けます (最大長 30 文字)。 パラメータ「EmailToNotifyForAlarms」にはアラームを通知するメールアドレスを入力します。パラメータ「DDBReadThrottleThreshold」と「ECSTarget5XXThreshold」にはユースケースに基づいてそれぞれのアラームのしきい値を入力します。 「送信」を選択します。 スタックの作成が完了するまでお待ちください。 コスト このソリューションの利用に関連するコストは、アカウントとリージョンの DynamoDB テーブルの数と ECS クラスターの数によって異なります。Metrics Insights のクエリアラームには、クエリによって分析されるメトリクススごとに料金が発生します。料金の詳細については、 Amazon CloudWatch 料金表ページ を参照してください。また、通知料金の詳細については、 Amazon SNS の料金ページ を参照してください。 クリーンアップ CloudWatch Metrics Insights のアラームと関連リソースを保持する必要がなくなった場合は、AWS コンソールの CloudFormation に移動し、スタックを選択し (デプロイ時につけた名前)、「削除」 を選択します。そのスタックによって作成されたリソースはすべて削除されます。 これらの CloudWatch Metrics Insights アラームを再び追加したい場合は、いつでも CloudFormation yaml からスタックを再作成できます。 結論 このソリューションを使用すると、1つのアラームで、一瞬のうちに発生するリソース増減に対するアラーム設定を動的に調整し、数千ものリソースを監視できる価値の高いアラームを作成できます。CloudWatch Metrics Insights アラームはシンプルかつ単一の定義であるため、お客様はアラームの運用メンテナンスを行って、古くなったり廃止されたメトリクススやアラームをクリーンアップする必要がなくなります。 著者について Sharmadha Muthuram Sharmadha Muthuram は AWS Professional Services の Sr. Cloud Infrastructure Architect です。お客様の AWS 利用を成功に導くために、技術的なガイダンス、設計、実装プロジェクトのリードを行っています。お客様のクラウドジャーニーをシームレスにすることに情熱を注いでいます。イリノイ大学でコンピューターエンジニアリングの修士号を取得しています。仕事以外では、旅行やさまざまな料理の探索を楽しんでいます。 Karthik Chemudupati Karthik Chemudupati は AWS の Principal Technical Account Manager (TAM) であり、お客様がコスト最適化と優れた運用を実現できるよう支援することに重点を置いています。ソフトウェアエンジニアリング、クラウドオペレーション、自動化の分野で 19 年以上の IT 経験があります。Karthik は 2016 年に TAM として AWS に入社し、米国西部の十数社のエンタープライズのお客様と仕事をしました。仕事以外では、家族と過ごす時間を楽しんでいます。 Jean Schwerer Jean Schwerer は CloudWatch の Senior Product Manager です。テクノロジーの愛好家で、元エンジニアでもある彼は、テクノロジー製品の製品管理において 10 年以上の経験を積んでおり、お客様のユースケースやニーズに Dive Deep することを楽しんでいます。 翻訳はテクニカルアカウントマネージャーの日平が担当しました。原文は こちら です。

本ブログでは、 Amazon Timestream のスケジュールドクエリを使用してクエリのパフォーマンスを向上させ、コストを削減する方法を紹介します。スケジュールドクエリにより、リアルタイム分析がよりパフォーマンスとコスト効率に優れたものになるため、データからさらなる洞察を引き出し、より良いビジネス上の意思決定を継続的に行うことができます。 Timestream はサーバーレスの時系列データベースであり、幅広い業種のお客様がリアルタイムの洞察を引き出し、重要なビジネスアプリケーションを監視し、ウェブサイトやアプリケーションで何百万ものリアルタイムイベントを分析するために採用しています。これらの多様なワークロードを、クエリアクセスパターンやクエリ同時実行数の要件と合わせて分析することで、Timestream にいくつかの最適化を行い、その結果、異なるワークロード間でクエリレイテンシを最大3倍高速化することができました。 AWS re:Invent 2021 で Timestream は多くのユースケースをより簡単かつ安価に実装するための 新しい機能のアップデート を発表しました： マルチメジャーレコード – Timestream に 複数のメジャー値を書き込める ようになりました。データの書き込みが簡単になり、より多くのユースケースで扱うレコードの数が減る事になります。例えば、同じソースから同じ時間に放出された複数のメトリックを追跡する際にマルチメジャーレコードを使用出来ます。また、リレーショナルデータベースから Timestream へのデータ移行を考える際に、マルチメジャーレコードであればスキーマの変更が多くの場合不要となる為、Timestream へのデータ移行が簡単になるというメリットもあります。 マグネティックストレージへの書き込み – Timestream はデータのライフサイクルを直近データのメモリストアと履歴データのマグネティックストアという 2 つのストレージ階層で管理しています。メモリストアからマグネティックストアへのデータの移動は設定したポリシーに応じて自動的に実施されます。以前はデータはメモリストアにしかロード出来ず、遅れて到着するデータを格納する為には、メモリストアの保持時間を拡張して対応する必要がありました。今回、 直接マグネティックストアに書き込む 事が出来るようになり、ストレージコストを削減する事が出来ます。 スケジュールドクエリ – ダッシュボードやレポートを作成する際、ソースとなるテーブルに直接クエリを実行する代わりに、 スケジュールされたクエリ を実行して別テーブルに結果を格納する事が出来るようになりました。例えば、大規模なデータから頻繁に集約や合計の為のクエリを実行している場合、これらの結果を別テーブルに格納して、待ち時間とコストの削減が可能となります。 以下のセクションでは、Timestream でスケジュールされたクエリを作成し、直接クエリとパフォーマンスを比較する方法を示していきます。 ソリューションの概要 頻繁に処理されるデータセットに対してクエリを繰り返すと、集計処理と結果の生成に計算リソースが使われるため、コストがかかります。このメカニズムにはいくつかのステップがあります。 スケジュールドクエリでは、入力データに対して集計、ロールアップ、その他のリアルタイム分析を行うクエリを定義するだけです。Timestream はこれらのクエリを定期的かつ自動的に実行し、その結果を設定可能な指定されたテーブルに確実に書き込みます。そして、ダッシュボード、レポート、アプリケーション、モニタリングシステムに対して、時系列データが入ってくる非常に大きなソーステーブルにクエリするのではなく、スケジュールドクエリで設定されたテーブル(宛先テーブル)をクエリするように指示することができます。これにより、パフォーマンスを向上させながら、コストを1桁削減することができます。宛先テーブルは、ソーステーブルよりもはるかに少ないデータしか含まないため、データへのアクセスや保存がより高速かつ低コストで行えます。 宛先テーブルのデータ量はソーステーブルよりもはるかに少ないため、ソーステーブルのストレージコストの数分の一で、宛先テーブルに長期間データを保存できます。また、ソーステーブルのデータ保持期間を短くすることで、支払いコストをさらに最適化することもできます。従って、スケジュールドクエリは、時系列分析をより高速に、よりコスト効率よく、より多くの顧客がアクセスできるようにし、より良いデータ駆動型のビジネス上の意思決定を継続的に行えるようにします。 このブログを実例で示すために、気象データを収集するサンプルデータセットを作成し、スケジュールされたクエリを使用して集計クエリを作成します。 スキーマとデータセット 次のスクリーンショットは、IoTセンサーデータテーブルのスキーマを示しています。 15秒ごとに湿度と温度を収集するサンプルのIoTセンサーデータセットをロードしました。テーブルには 3,754,312 レコードが書き込まれています。次の表はデータの例です。 country city state gpio time temperature humidity US Jersey City NJ 17 2023-03-07 00:30:00.000000000 77.67058823529413 37.372549019607845 US Jersey City NJ 22 2023-03-07 00:30:00.000000000 77.0 35.254901960784316 US Jersey City NJ 17 2023-03-07 00:15:00.000000000 78.421052631579 38.50877192982456 US Jersey City NJ 22 2023-03-07 00:15:00.000000000 77.0 35.59649122807018 US Jersey City NJ 22 2023-03-07 00:00:00.000000000 77.0 36.206896551724135 US Jersey City NJ 17 2023-03-07 00:00:00.000000000 78.80000000000008 39.0 US Jersey City NJ 17 2023-03-06 23:45:00.000000000 78.80000000000008 39.29824561403509 US Jersey City NJ 22 2023-03-06 23:45:00.000000000 77.0 36.91228070175438 US Jersey City NJ 22 2023-03-06 23:30:00.000000000 77.0 37.91228070175438 US Jersey City NJ 17 2023-03-06 23:30:00.000000000 78.80000000000008 39.85964912280702 前提条件 以下の前提条件が必要です。 スケジュールされたクエリの出力を格納する 空のテーブルを作成します 。スケジュールされたクエリを作成する際にこのテーブルを参照します。 Amazon Simple Storage Service ( Amazon S3 )バケットに、クエリ実行エラーログを保存します。 Amazon Simple Notification Service ( Amazon SNS )トピックで、クエリ実行状況に関する通知アップデートを送信します。 ソーステーブルと宛先テーブル、および通知を送信する SNS トピックへの権限を持つ AWS Identity and Access Management ( IAM )ロールを用意します。 データ全体を暗号化するために AWS Key Management Service ( AWS KMS )キーを使用します。 *追加で発生するコストは、クエリ実行コストと追加ストレージコスト(集計結果データ)です。 集計クエリの作成 スケジュールされたクエリの使い方を示すために、まず、都市別、月別、年別の平均気温と湿度を計算する単純な集約クエリを作成します： SELECT city , AVG (temperature) AS avg_temp , AVG (humidity) AS avg_humidity , cast(month(time) as VARCHAR) AS month , cast(year(time) as VARCHAR) AS year , from_iso8601_timestamp('2022-01-01T00:00:00') AS time FROM "IoTHome"."sensordata" WHERE measure_name ='weather' GROUP BY city, month(time), year(time) ORDER BY city, year, month 次のスクリーンショットは出力を示しています。 次のセクションでは、Timestream でスケジュールされたクエリを作成し、実行する手順を示します。 スケジュールされたクエリの作成 スケジュールされたクエリを作成するには、以下の手順を実行します： Timestream コンソールのナビゲーションペイン( Management Tools の下)の Scheduled queries を選択します。 Create scheduled query を選択します。 Destination Table のところで、ドロップダウンから Database name と Table name (前提条件として作成したクエリ出力テーブル)を選択します。 Query Name のところにクエリの名前を入力します。 Next を選択します。 Query statement のところで集計クエリを入力し、 Validate を選択します。 クエリが正常に検証されると、宛先テーブルのスキーマが設定されます。お客様は、提案されたスキーマで進めるか、ユースケースに基づいて変更を加えるか選択できます。 Next を選択します。 Run schedule では、クエリを実行するスケジュール間隔を指定します。このブログでは、クエリを6時間ごとに実行したいと思います。 Security settings では、 IAM ロールと KMS キーを指定します。 SNS notifications では、SNS トピックを指定します。 Error report logging には、S3 バケットを入力します。 Next を選択します。 設定を確認し、 Create を選択します。 これで、 Scheduled queries ページにクエリがリスト表示されるようになります。クエリがスケジュール通りに実行されると、 Last run time 列の情報が更新されます。 以下のスクリーンショットは、スキャンされたバイト数、実行時間、返された合計行数などのクエリのメトリクスの詳細を示しています。 クエリパフォーマンスメトリクス 以下の表は、 Timestream でスケジュールドクエリを使用することで得られるパフォーマンスの利点を示しています。スケジュールされたクエリは、同じクエリを直接実行した場合と比較して、スキャンされた総バイト数だけでなく、期間においてもパフォーマンスの向上を示しています。 Query Type Total Bytes Scanned Duration (Cold Start) Duration Direct Query 177.57 MB 3.622 seconds 2.264 seconds Scheduled Query 627.00 B 0.2510 seconds 0.1520 seconds スケジュールされたクエリのパフォーマンスは14倍向上しました。これは小さな例ですが、データ規模が大きくなると、スキャンするデータが大幅に減るため、大幅なコスト削減を実現できます。実際の金額は、データ規模やクエリーによって異なります。 また、同じデータセットに対してクエリを実行するユーザーやレポートの数も考慮する必要があります。これにより、パフォーマンスが大幅に向上し、コスト削減も可能になります。 まとめ 本ブログでは、Timestream のスケジュールドクエリがクエリのパフォーマンス向上とコスト削減にどのように役立つかを紹介しました。Timestream スケジュールドクエリの詳細やその他の例については、 ドキュメント を参照してください。 翻訳はソリューションアーキテクトの宮﨑が担当しました。原文は こちら です。

2023 年 6 月 13 日 , 14 日に、AWS のセキュリティとコンプライアンスについてベストプラクティスや最新情報を学習できるグローバルカンファレンスである AWS re:Inforce 2023 が、アナハイムで開催されました。日本のお客様向けに日本語での振り返りセミナーを実施いたしましたので、その資料を公開いたします。 AWS セキュリティリーダーセッション　（桐山 隼人） 発表資料リンク： https://pages.awscloud.com/rs/112-TZM-766/images/1_SecurityLeaderSession.pdf 前半のセッションでは、AWS re:Inforce 2023 のキーノートで言及された点を中心にご紹介しました。組織においてセキュリティを統括されているCISO/CIO/CTO/事業部長の方や、セキュリティ計画実行の意思決定をされるセキュリティアーキテクト/ITアーキテクト/エンジニアリードの方を想定した内容です。 AWSの最優先事項であるセキュリティについて、セキュリティを担保するための重要な考え方、AWSが開発してきたサービスの開発背景やその特徴、さらにはインターネット自体をより安全な場所とするためのAWSの取り組みをご紹介しました。 AWSサービスアップデート（平賀 敬博） 発表資料リンク： https://pages.awscloud.com/rs/112-TZM-766/images/2_SecurityServicesUpdates.pdf youtube： https://youtu.be/qWsgF3z3yU4 後半のセッションでは、AWS re:Inforce 2023 の期間中に発表された新サービスや新機能をご紹介しました。業務においてAWSのセキュリティに携わる方々にとって効率的に最新情報を学び取っていただける内容です。新機能や新サービスの活用にあたっては、各サービスのドキュメントも参照ください。 1時間半のセミナーについて、300名以上の方にご視聴いただきました。来年も AWS セキュリティ最大規模のカンファレンスである AWS re:Inforce に是非ご注目ください！オンラインだけでなく、ぜひ現地でお会いしましょう！ 過去の同種イベントの開催報告 AWS re:Inforce 2022 re:Cap https://aws.amazon.com/jp/blogs/news/aws-reinforce-2022-recap-seminar/ AWS re:Inforce 2021 re:Cap https://aws.amazon.com/jp/blogs/news/aws-reinforce-2021-recap-seminar/ AWS re:Inforce 2019 re:Cap https://aws.amazon.com/jp/blogs/news/aws-reinforce-2019-recap-seminar/ 本Blogについて 本Blogは以下のメンバーにて執筆いたしました。 セキュリティ事業本部 セキュリティセールスリード 桐山 隼人 セキュリティ事業本部 セキュリティソリューションアーキテクト 平賀 敬博

みなさんこんにちは！ アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクトの後藤です。 2023 年 7 月 27 日に「第三十二回 アップデート紹介とちょっぴり DiveDeep する AWS の時間」をオンラインで開催しました。本イベントは、AWS の数あるアップデートの中から「すぐ使える、運用に役立つ、あったらいいなと思ってた、おもしろい、重要」なものをピックアップし、ちょっぴり DiveDeep してカジュアルな雰囲気でお伝えするイベントです。 今回のテーマは「Data Analytics」ということで、株式会社 E-Grant の堀江 氏、クラスメソッド株式会社の石川 氏、株式会社ジェーエムシステムズの植木 氏にご登壇いただきました。 今回も非常に多くの方にご参加いただきました。ご参加いただいた皆様、誠にありがとうございました。 実施内容 AWS のメンバーからは AWS SDK for pandas に関するセッションをお届けし、株式会社 E-Grant の堀江 氏、クラスメソッド株式会社の石川 氏、株式会社ジェーエムシステムズの植木 氏からは、AWS を活用した Data Analytics の事例についてご紹介いただきました。合計 1 時間半の中で盛りだくさんの内容でお送りしました。 記事の中に資料や動画のリンクがありますので、見逃してしまった方はそちらから御覧ください。 アジェンダ 今月のお勧め 5 分間アップデート (5 分) スピーカー：アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 後藤 健汰 今月の AWS のサービスアップデートを 5 分でご紹介。たくさんのアップデートの中から 4 つをピックアップしました。 AWS が Amazon Aurora MySQL と Amazon Redshift のゼロ ETL 統合 (パ ブリックプレビュー) を発表 AWS Lambda now detects and stops recursive loops in Lambda functions AWS Fargate enables faster container startup using Seekable OCI Llama 2 foundation models from Meta now available in Amazon SageMaker JumpStart AWS の新着情報については  公式ページ  のほか、 週間 AWS  を合わせてご覧いただくのがオススメです！ プロダクト成長のためのデータの可視化（15 分） スピーカー：株式会社 E-Grant CTO 堀江 勉 氏 株式会社 E-Grant では「うちでのこづち」という CRM システムを提供しております。プロダクトは作ってからがスタート。どんな情報に価値があるのか、必要になるかはそれぞれ。そのためにデータを集約することと、ログの解析や可視化に取り組んでおります。本セミナーでは、どのような情報を可視化し、どのようにプロダクトの成長に活かしているか、Amazon Athena や Amazon QuickSight などの具体的な事例を交えてお話しいたします。 AWS SDK for pandas で手軽に実現する！pandas と AWS のデータ分析サービス統合（15 分） スピーカー：アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 福本 健亮 AWS SDK for pandas をご存知でしょうか？元々は AWS Data Wrangler という名前で提供されていましたが、現在は名前が変わりつつも引き続き同じ機能が提供されています。pandas を普段お使いの方であれば、慣れた操作感で Amazon Athena や AWS Glue をはじめとした多くの AWS データ分析サービスと接続し、ETL などの処理が行えます。本セッションでは、普段の業務でお役立ていただける AWS SDK for pandas の基本に加えてデモも用意していますので、是非ご覧ください！ Amazon Athena (Iceberg) x dbt ではじめるデータ分析！（15 分） スピーカー：クラスメソッド株式会社 プロトタイプソリューションアーキテクト 石川 覚 氏 昨年の re:Invent2022 で発表された Amazon Athena Verion 3 のフォーマットタイプ「Iceberg」は、パフォーマンス改善、Merge（UPSERT）のサポート、ビューのサポート、VACUUM のフラグメントデータファイルの削除の改善など正常進化を遂げ、dbt (data build tools) が必要とする機能が網羅されました。一方、コミュニティベースで開発が進められている dbt-athena パッケージの Version1.5 では、table materialization や incremental models のサポートが開始され、dbt の強みを生かしたデータ変換が可能になりました。この強力な組み合わせによるエレガントなデータトランスフォームをご紹介致します。 AWS Glue + Amazon QuickSight でクイックに成果を出す需要予測（15 分） スピーカー：株式会社ジェーエムエーシステムズ アドバンストテクノロジー部 植木 将也 氏 「需要予測」は DX / データ分析でも根強い人気のテーマです。一方で精度、複雑さ、属人性、データ不足などがシステム化の障壁となるケースも多々見受けられます。本セッションでは AWS Glue や Amazon QuickSight などを組み合わせたデータ分析事例を通じ、実際に直面した課題に対する具体的な解決方法をご紹介するとともに、クイック ＆ ライトな仕組みから段階的に成果を刈り取る勘所をお伝えします。 当日の様子 当日の内容を抜粋してご紹介します。 プロダクト成長のためのデータの可視化 [ 資料 、 動画 ] 最初のセッションは株式会社 E-Grant の 堀江 氏より、Amazon Athena や Amazon QuickSight を使ったデータの収集と可視化の事例について共有いただきました。CRM システムとして「うちでのこずち」を提供する株式会社 E-Grant 様は、サービスの成功をお客様の成長に繋げるという付加価値の向上という観点からも、データの収集と分析に取り組まれています。具体的な実例として、Apache や Nginx のログ、サービス独自のアクセスログ、DB から抽出したデータの可視化についてご紹介いただきました。また実際のデータ活用の事例として、どういったデータを活用し、どういったアクションに繋げているか、という観点で、いくつかのケースを紹介いただきました。 プロダクトの成長のためのデータの可視化に取り組むうえでの具体的な事例について紹介されており、データをもとにプロダクトの成長を加速させたいと考えている方には、ぜひ御覧いただきたい内容です。 AWS SDK for pandas で手軽に実現する！pandas と AWS のデータ分析サービス統合 [ 資料 、 動画 ] 2 つ目のセッションでは、ソリューションアーキテクトの福本より、AWS SDK for pandas について概要のご紹介とデモンストレーションをおこないました。AWS SDK for pandas は、AWS のデータ分析サービスと Pandas DataFrame 間のやり取りが簡単に行える Python のライブラリです。今回の発表では、ローカルとクラウドでデータフレームをやり取りしたり、Amazon Athena にクエリを投げてローカルで結果を受け取る、といったユースケースでのデモンストレーションを実施いたしました。 pandas を普段お使いでクラウドでのスケーラブルな環境を手に入れたいと考えている方にはオススメのセッションですので、ぜひ動画をご覧ください。 Amazon Athena (Iceberg) x dbt ではじめるデータ分析！ [ 資料 、 動画 ] 3 つ目のセッションでは、クラスメソッド株式会社 石川 氏より dbt-template ソリューションの Amazon Athena 対応で得られた技術調査の結果と、テーブルフォーマットである Apache Iceberg と dbt 対応について共有いただきました。従来のデータレイクの技術課題と Apache Iceberg による解決策の詳細や、dbt の特徴、Amazon Athena (Iceberg) と dbt を組み合わせて利用した際の課題や代替案についても共有いただきました。 実際に検証いただき得られた課題と代替案についても詳しく説明して頂いております。Apache Iceberg や dbt に興味がある方はぜひ動画をご覧ください！ AWS Glue + Amazon QuickSight でクイックに成果を出す需要予測 [ 資料 、 動画 ] 最後のセッションは、株式会社ジェーエムエーシステムズ 植木 氏より、データ分析でも根強い人気のテーマの一つである「需要予測」にフォーカスを当てて発表いただきました。需要予測の目的や現状の課題に加えて、業務上の課題やその対策について共有いただきました。AWS Glue や Amazon QuickSight を活用し、短期間で IT 部門以外の社員でも分析が可能な環境を構築した事例について紹介いただきました。 実際に直面した課題に対して、AWS を活用した具体的な解決手法について紹介いただいております。DX やデータ分析といったテーマで課題を感じている方はぜひ動画をご覧ください！ 次回予告 次回は「Security」編です。 ゲストスピーカーとして、弥生株式会社の峯岸 氏、HENNGE 株式会社の土居 氏、穂坂 氏をお招きしまして、マルチアカウント環境におけるセキュリティ強化の事例や AWS Control Tower Account Factory for Terraform の事例について発表いただきます。 次回も多くの方々のご参加を心よりお待ちしております！ 2023 年 4 月以降に開催予定の『アップデート紹介とちょっぴり DiveDeep する AWS の時間』の視聴申し込みを一括でできるようになりました！毎月申し込みする必要はなくなります。また、イベント開催直前にリマインドメールをお送りいたします。下記リンクから参加ご希望月の申し込みをお願いいたします。 三十三回「アップデート紹介とちょっぴり DiveDeep する AWS の時間」- Security 編- 開催日時 2023 年 8 月 31 日（木）16:00 – 17:30 オンライン開催 アジェンダ 16:00 – 16:10 オープニングセッション 16:10 – 16:25 AWS 初心者が取り組んだセキュリティ強化の 2 年間とこれから スピーカー： 弥生株式会社 開発本部 情報システム部 インフラ/CCoE 峯岸 純也 氏 16:25 – 16:40 AWS Gateway Load Balancerを用いた仮想アプライアンスの活用 スピーカー： アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 長屋 和真 16:40 – 16:45 Q&A 16:45 – 17:00 Amazon GuardDuty 2023 夏 スピーカー： アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 吉田 裕貴 17:00 – 17:15 AFT で AWS アカウントをばら撒いてみた スピーカー：HENNGE株式会社 Cloud Product Development Division 土居 俊也 氏 17:15 – 17:20 Q&A 17:20 – 17:30 クロージングセッション 次回も多くの方々のご参加を心よりお待ちしております！ 特別回開催予告 また通常開催とは別の特別回として「AWS re:Inforce デモ祭り」を開催します。 2023 年 6 月に開催されたクラウドセキュリティ、コンプライアンスに特化したカンファレンスである AWS re:Inforce で発表された新サービス、新機能の内容についてデモ中心で Dive Deep します。 下記リンクから参加の申し込みをお願いいたします。 アップデート紹介とちょっぴり DiveDeep する AWS の時間 – AWS re:Inforce デモ祭り 開催日時 2023 年 9 月 6 日（水）16:00 – 17:30 オンライン開催 アジェンダ 16:00 – 16:10 オープニングセッション 16:10 – 16:25 ついにGA！ Amazon Verified Permissions でアプリケーションの認可をシンプルに！ スピーカー：アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 柴田 龍平 16:25 – 16:40 Amazon CodeGuru Security の紹介 スピーカー：アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 江口 昌宏 16:40 – 16:45 Q&A 16:45 – 17:00 踏み台サーバーなしでプライベートサブネットのインスタンスに SSH？EC2 Instance Connect Endpoint を試してみる！ スピーカー：アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 山崎 宏紀 17:00 – 17:15 Amazon Inspector SBOM Export ではじめるソフトウェアサプライチェーンセキュリティ スピーカー：アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 後藤 健汰 17:15 – 17:20 Q&A 17:20 – 17:30 クロージングセッション こちらについても、多くの方々のご参加を心よりお待ちしております！ このブログの著者 後藤 健汰 (Goto Kenta) ソリューションアーキテクトとして ISV/SaaS 領域のお客様の技術支援を行っております。好きなサービスは Amazon EKS です。夢は本場フィンランドのサウナでバルト海にちょっぴり Dive Deep することです。

このブログは 2023 年 8 月 1 日に Dilip Kumar によって投稿された Empowering your workforce with Amazon WorkSpaces services and Microsoft 365 を翻訳したものです。 何万ものお客様が、エンドユーザーコンピューティングサービスとして、ユーザーが仕事をするために必要なすべてのツールを備えた、安全でスケーラブルかつコスト効率の高い仮想デスクトップサービスである Amazon WorkSpaces サービスを利用しています。お客様は WorkSpaces 上で、倉庫作業員を誘導する単一目的の Web アプリケーションから、メディアやエンターテイメントなどの GPU ベースの複雑なレンダリングワークロードまで、あらゆる種類のアプリケーションを使用しています。多くのお客様は、Microsoft 365 のような Office アプリケーションをハイブリッドユーザーやリモートユーザーに提供するためのシンプルかつ費用対効果の高いメカニズムを含むソリューションを必要としており、同時に企業データや知的財産のセキュリティ体制を改善する必要があると述べています。 2023年8月1日から、 AWS エンドユーザーコンピューティング のお客様は、 Amazon WorkSpaces サービス上で BYOL (Bring Your Own License) モデルを通じて Microsoft 365 ライセンスを使用できるようになります。ナレッジワーカーに最適な WorkSpaces の仮想デスクトップは、Microsoft Windows、Amazon Linux 2、および Ubuntu Desktop オペレーティングシステムをサポートし、さまざまなインスタンス構成で利用できます。これらのサービスは、高い安全性と信頼性を誇る AWS クラウド上で実行され、自動スケーリングと従量課金制により、利用した分だけ料金を支払うことができます。また、ユーザーは、いつでも、どこからでも、サポートされているデバイスから、仮想デスクトップとアプリケーションに安全にアクセスできます。Microsoft 365 は、Microsoft Word、Microsoft Excel、Microsoft PowerPoint、Microsoft Outlook などの一般的な Office アプリケーションにより、ソリューションのパワーをさらに高めます。含まれるアプリケーションは、 Microsoft 365 のライセンスプラン によって異なります。Microsoft は、Microsoft E3、E5、A3、A5、Business Premiumライセンスを WorkSpaces サービス上で使用することを許可しています。また、新しいライセンス条件では、Microsoft Project とMicrosoft Visio のライセンスを WorkSpaces サービスに持ち込むこともできます。 Microsoft 365 の Office アプリケーションを WorkSpaces サービス上で実行するために Microsoft 365 のライセンスを使用したいお客様には、追加料金やコストは発生せず、特別なセットアップやイメージ管理も必要ありません。お客様は既存のツールを使用して、Microsoft 365 を WorkSpaces サービスに導入することができます。また、サービスプロバイダー向けライセンスプログラム (SPLA) に基づき、WorkSpaces サービス上で実行する Microsoft Office Professional を AWS から引き続き購入することも可能です。 AWS エンドユーザーコンピューティングは、仮想デスクトップ体験の提供において 10 年以上にわたって高い評価を得ており、お客様は、Microsoft 365 アプリケーションを含め、組織に最適なソフトウェアを柔軟に選択することができます。 翻訳はソリューションアーキテクトの平田が担当しました。原文は こちら です。

(編集者注: 最近のトップニュースや発表、見逃せない今後のイベントといった多様な情報をよりよく反映するために、8月8日、この定期的な週次投稿のタイトルを AWS Week in Review から AWS Weekly Roundup に変更します。) デベロッパーアドボケイトにとってスタジオでの動画撮影は新しい経験で、慣れるまでに少し時間がかかりました。 7月31日週、AWS ロンドンスタジオのチームメイト数名と一緒に一連の動画を撮影しました。このビデオは、Build On AWS YouTube チャンネルで公開される予定です。Build On AWS は、アジリティを高め、イノベーションのスピードをアップしたいと考えている実践的で技術的な AWS クラウドビルダーを対象としています。このチャンネルでは、デベロッパーがデベロッパー向けに設計した動的で高品質のコンテンツが提供されています。 このチャンネルの詳細については、次の動画を参照してください。新しいコンテンツが公開されるときを見逃さないよう、チェックしてサブスクリプションを検討してください。 では、AWS の最新情報です。先週は AWS に関する多くのニュースがあったので、皆さんにお伝えすべきお知らせと今後予定されているイベントをまとめました。それでは、始めましょう。 7月31日週のリリース 見逃された可能性のある7月31日週のリリースをいくつかご紹介します。 Microsoft 365 Apps for enterprise が Amazon WorkSpaces サービスで利用できるようになりました – Amazon WorkSpaces は、AWS クラウド内のフルマネージド型のセキュアで信頼性の高い仮想デスクトップです。Amazon WorkSpaces では、使用したインフラストラクチャに対してのみの支払いで IT のアジリティを高めてユーザーエクスペリエンスを最大化できます。Amazon WorkSpaces で Microsoft 365 Apps for enterprise が利用可能になったことが発表されました。お客様ご自身の Microsoft 365 ライセンスを使用して、追加費用なしでアプリケーションをアクティベートし、Amazon WorkSpaces サービス上で Microsoft 365 Apps for enterprise を実行できます (Microsoft のライセンス要件を満たしている場合)。 AWS イスラエル (テルアビブ) リージョンの提供開始 – イスラエルにデータを安全に保存しながら、近隣のユーザーにさらに低いレイテンシーでサービスを提供できるようになりました。先週、イスラエルに位置するデータセンターのアプリケーションの実行とユーザーへのサービス提供を目的とした追加オプションをお客様に提供するためにテルアビブ リージョンがローンチされました。 Amazon Connect のローンチ – AWS のお客様とお客様の顧客のエンゲージメントを大きく変えている Amazon Connect は、 私が最もお伝えしたい AWS のサービス の 1 つです。いくつか例を挙げると、先週、Amazon Connect は、 シフト期間に基づくアクティビティの自動スケジュール 、 カスタムフローブロックタイトル 、 UI からのフローのアーカイブと削除 を発表しました。 AWS のその他のニュース 以下では、他の注目すべきニュースやブログ記事をいくつかご紹介します。 Amazon CloudWatch Internet Monitor でサポートされるヘルスイベント向けのカスタマイズ可能なしきい値 – この発表の前までは、ヘルスイベントを呼び出すための全体的な可用性とパフォーマンススコアのデフォルトのしきい値は 95% でした。今回の発表により、エンドユーザーと AWS でホストされているアプリケーションとの間のインターネット向けトラフィックについて、ヘルスイベントを呼び出すタイミングのしきい値をカスタマイズできるようになりました。 Amazon S3 バケットの AWS Backup パフォーマンスが向上 – 3 億以上のオブジェクトを含むバケットのバックアップ速度が最大 10 倍向上したため、Amazon S3 の初期バックアップワークフローをスピードアップするとともに、30 億以上のオブジェクトを含むバケットをバックアップできるようになりました。このパフォーマンス向上は、Amazon S3 の AWS Backup サポートが利用可能なすべてのリージョンで自動的に有効になります。追加コストは必要ありません。 AWS のオープンソースに関するニュースや最新情報については、オープンソースプロジェクト、記事、イベントなどに関する最新情報をお届けするために同僚の Ricardo Sueiras が厳選した情報が記載されている 最新のニュースレター をご覧ください。 AWS のお知らせの完全なリストについては、「 AWS の最新情報 」ページをご覧ください。 今後の AWS イベント 以下のイベントが近日開催予定です。 AWS Storage Day (8 月 9 日) – このイベントでは、ストレージに関する現在の意思決定で AI/ML の準備をする方法、オンプレミスとクラウドデータのストレージコストを最適化して限られた予算で大きな成果を出す方法に加えて、ランサムウェアからの保護に役立つ復旧計画など、総合的なデータ保護を組織に提供する方法を学習できる 1 日のイベントです。 詳細情報と登録はこちらです 。 AWS Summit メキシコシティ (8 月 30 日) – サミットにサインアップ すると、AWS について学びながら、志を同じくする他の人々とつながってコラボレーションできます。 AWS Community Day (8 月 12 日、19 日) – 各地のコミュニティリーダーがイベントロジスティクスとコンテンツの計画、準備、提供を行うコミュニティ主催のカンファレンスに参加してください: コロンビア (8 月 12 日)、 西アフリカ (8 月 19 日). P.S.私たちは、より良いカスタマーエクスペリエンスを提供するためにコンテンツの改善に注力しており、そのためにはお客様からのフィードバックが必要です。 この短いアンケート にご回答いただき、AWS ブログに関するご感想をお聞かせください。なお、このアンケートは外部企業によって実施されているため、リンク先は当社のウェブサイトではありません。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。 – Veliswa 原文は こちら です。

このブログは 2023 年 8 月 9 日に Darryl Diosomito（Senior Solution Architect）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 AWS では、お客様がクラウドの IT 運用を実行することを選択した場合に、最高の経験と、パフォーマンス、コストが得られると考えています。しかしながら、様々な理由によってマルチクラウド環境で IT 運用を実行されているお客様もいます。たとえば、お客様が別のクラウドプロバイダーで運営されている会社を買収した場合や、データが AWS に保管されている必要がある特定の AWS データ処理サービスを利用する場合などです。これらのお客様は、アプリケーションとクラウドインフラストラクチャ運用が更に複雑になる可能性があります。ITリソースのプロビジョニングや、管理、統制、アプリケーションの状態監視、複数の場所に保存されているデータの収集と分析に、複数プロバイダーのソリューションを使用することを考慮する必要があります。これらの課題を抱えるお客様を支援するために、AWS はクラウドサービスを拡張して、お客様がハイブリッドおよびマルチクラウドのインフラストラクチャとアプリケーションを合理化し、管理、統制ができるようにしています。そのサービスの 1 つが AWS DataSync（DataSync） です。 DataSync は、様々なクラウドプロバイダー間で データが移動できるようになりました 。DataSync を使用すると、他のクラウドの Amazon S3 互換ストレージ と Amazon S3 などの AWS Storage サービス間でオブジェクトデータを大規模に移動できます。Google Cloud Storage や、Azure Files、Azure Blob Storage のサポートに加えて、DataSync は DigitalOcean Spaces や、Wasabi Cloud Storage、Backblaze B2 Cloud Storage、Cloudflare R2 Storage、Oracle Cloud Storage 間とのデータコピーをサポートするようになりました。 この記事では、マルチクラウドでデータ転送を開始するための DataSync の設定に関する一般的な概要を説明します。DataSync が特定のエンドポイントを介して様々なクラウドに接続する方法について説明し、サポートされている各クラウドの違いの概要を説明します。DataSync を使用すると、ビジネスワークフローの一環として、他のクラウドから AWS へのデータ移行や、AWS でのデータアーカイブ、他のクラウド間とのデータ移動を迅速かつ簡素化することができます。AWS にデータを保管することで、最も重要なアプリケーションに対して AWS の比類ない経験と、成熟度、信頼性、セキュリティ、パフォーマンスを活用することができます。 仕組み DataSync は、 DataSync エージェント を使用して他のクラウドとの間でデータを転送します。DataSync エージェントは、DigitalOcean Spaces と、Wasabi Cloud Storage、Backblaze B2 Cloud Storage、Cloudflare R2 Storage、Oracle Cloud Storage に加えて Google Cloud Storage、Azure Blob Storage に接続する Amazon EC2 インスタンスにデプロイできます。エージェントを Google Cloud または Azure にデプロイすると、ネットワークで圧縮の利点が得られるため送信コストが削減できます。 はじめに まず、 DataSync エージェントをデプロイして有効化 します。アクティベーションプロセスにより、エージェントが AWS アカウントおよびリージョンに関連付けられます。Amazon EC2 ベースのエージェントの場合、 プライベート VPC エンドポイント を使用してエージェントを有効化することをお勧めします。 DataSync エージェントをデプロイして有効化した後は、他クラウドのストレージタイプ用の DataSync ロケーションを作成します。他クラウドにある別の Amazon S3 互換オブジェクトストレージから AWS に転送する場合は、DataSync タスクのソースとして使用する DataSync オブジェクトストレージロケーション を作成する必要があります。サポートされているクラウドは、特定のリージョンまたはアカウントを持つパブリックエンドポイントと認証情報キーを提供し、DataSync が指定されたオブジェクトストレージにアクセスできるようにします。次の表は、サポートされているクラウドの Amazon S3 互換オブジェクトストレージと、指定されたクラウドから AWS にデータを転送するために DataSync が使用するエンドポイントおよび読み取り権限を示しています。特定のアクセス権限の詳細については、クラウドプロバイダーのドキュメントを参照してください。 ロケーションの例として Wasabi Cloud Storage を使用して、Wasabi バケットのリージョナルサーバーエンドポイントを指定し、アクセスキーの認証情報を入力します。ロケーションが作成されたら、そのロケーションを使用して DataSync タスク の一部として AWS にデータを転送できます。 Azure Blob Storage には、Amazon S3 互換のエンドポイントは提供されていません。Azure BLOB Storage からの転送は、 DataSync の Microsoft Azure Blob Storage ロケーションタイプ を使用して設定します。 クラウド間でデータを転送する際の考慮事項 DataSync はマルチクラウドのデータ転送を簡素化しますが、他のクラウドの特性を考慮する必要があります。Azure Blob Storage と Backblaze B2 Cloud Storage はオブジェクトタグをサポートしていますが、サポートされている他のクラウドプロバイダーは Amazon S3 インターフェイスからのオブジェクトタグやクエリタグをサポートしていません。DataSync には、 オブジェクトタグをコピー するタスクレベルのオプションが用意されていますが、タグの取得をサポートしていないクラウドにオブジェクトをコピーしたり、クラウドからオブジェクトをコピーしたりする場合は、このオプションを無効にする必要があります。 また、オブジェクトの読み取り元のソースストレージクラスも考慮する必要があります。他のクラウドプロバイダーには、データ転送の送信料金とリクエスト料金に影響するストレージクラスのオプションが混在しています。 DataSync は他のクラウドにリクエストを発行 して、オブジェクトの比較と読み取りを行い、変更とデータ転送を判断します。Amazon S3 と同様に、Azure Blob Storageと Oracle Cloud Storage のオブジェクトストレージにはアーカイブストレージクラスがあり、DataSync がアーカイブストレージクラス内のオブジェクトを読み取る前にオブジェクトを復元する必要があります。 まとめ この記事では、合併や買収によってクラウド間でデータを移動する場合や、お客様の要件で特定クラウドサービスを使ってデータを処理する場合などによって、お客様がマルチクラウド環境を管理する必要があるシナリオについて説明しました。DataSync が、他のクラウドが提供する様々なオブジェクトストレージやファイルサービス間でのデータ転送をサポートしたことを紹介しました。次に、クラウドプロバイダーのストレージエンドポイントの取得や、オブジェクトタグのサポート、データがどのストレージクラスにあるかを把握することの重要性、リクエストと送信料金など、クラウド間のデータ転送を計画する際の考慮事項をいくつか確認しました。 DataSync を使用すると、データ移動のワークフローを簡素化および自動化でき、複数のクラウドプロバイダーと通信できるソリューションを構築する際の障壁を最小限に抑えることができるため、AWS 間のデータ移動がこれまで以上に簡単に実現できます。 AWS の詳細なドキュメントとブログで今すぐ始めましょう。 Google Cloud Storage の AWS DataSync 転送設定 Microsoft Azure Blob Storage の AWS DataSync 転送設定 AWS DataSync を使用して Google Cloud Storage から Amazon S3 にデータを移行する方法 AWS DataSync を使用して Azure Blob Storage から Amazon S3 へ移行する AWS DataSync を使用して Azure Files の SMB 共有から AWS にデータを移行する方法 翻訳はプロフェッショナルサービス本部の葉山が担当しました。 Darryl Diosomito Darryl は AWS の Senior Solution Architect です。彼は、お客様がクラウドに移行する一環として、データを AWS に移行する支援に重点を置いています。Darryl はニューイングランド地域に住んでおり、季節ごとのアウトドアのアクティビティを見つけることを楽しんでいます。

このブログは Lorenzo Ripani (Big Data Solutions Architect) と Stefano Sandona (Analytics Specialist Solutions Architect) によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 高可用性（HA）とは、指定された期間、故障することなく継続的に稼働するシステムまたはサービスの特性です。システム全体に HA 特性を実装することで、通常、サービスの中断につながる単一障害点を排除し、ビジネスの損失やサービスが使用不可能となることを回避します。 耐障害性と高可用性の核となる考え方は、定義の点では非常にシンプルです。通常、特定のサービスに対して冗長性を持たせるために複数のマシンを使用します。これにより、ホストがダウンしても他のマシンがトラフィックを引き継ぐことができるようになります。簡単に聞こえるかもしれませんが、特に分散テクノロジーを扱う場合、このような特性を得るのは容易ではありません。 Hadoop テクノロジーに焦点を当てると、使用しているフレームワークによって、複数のレイヤーで可用性について考える必要があります。耐障害性を持ったシステムを実現するには、次のレイヤーを考慮する必要があります。 データレイヤー 処理レイヤー 認証レイヤー 最初の 2 つの層は、通常、Hadoop フレームワークのネイティブ機能（ HDFS High Availability や ResourceManager High Availability など ) や、使用する特定のフレームワークで利用できる機能（例えば、読み取り処理の可用性を高めるための HBase テーブルレプリケーション を使用して処理されます。 認証レイヤーは、通常、Kerberos プロトコルの利用によって管理されます。Kerberos には複数の実装が存在しますが、 Amazon EMR はマサチューセッツ工科大学（MIT）が直接提供する Kerberos プロトコルのフリーな実装を使用しており、MIT Kerberos とも呼ばれます。 キー配布センター (KDC) のネイティブ設定 を見ると、ツールには典型的なプライマリ/セカンダリ構成が付属しており、プライマリ KDC に 1 つまたは複数のレプリカを追加して、可用性の高いシステムの構成が可能です。 しかし、この構成ではシステムが中断した場合に新しいプライマリ KDC を選出する自動フェイルオーバー機構は提供されていません。そのため、手動でフェイルオーバーを行うか、自動化されたプロセスを実装する必要がありますが、自動化のセットアップ作業は容易ではありません。 AWS のネイティブサービスを利用することで、MIT KDCの機能に対して、システムの障害に対する耐性をさらに高めることができます。 高可用な MIT KDC Amazon EMR は、Kerberos 認証を有効にするための異なるアーキテクチャオプションを提供し、各々が特定のニーズやユースケースを解決できます。Kerberos 認証は、 Amazon EMR セキュリティ設定 を定義することによって有効にできます。セキュリティ設定は Amazon EMR 自身に保存される情報です。そのため、複数のクラスター間でこの構成を再利用することができます。 Amazon EMR のセキュリティ設定を作成する際、 クラスター専用の KDC か外部 KDC のどちらかを選択する必要があるため、それぞれのソリューションの利点と制限を理解することが重要です。 クラスター専用 KDC を有効にすると、Amazon EMR は起動するクラスターの EMR プライマリノード上に MIT KDC を構成してインストールします。一方、外部 KDC を使用する場合、起動したクラスターは外部の KDC に依存します。この場合、 KDC は外部 KDC として別の EMR クラスターのクラスター専用 KDC 、または Amazon Elastic Compute Cloud (Amazon EC2) インスタンスやコンテナにインストールされた KDC を使用できます。 クラスター専用 KDC は、 KDC サービスのインストールと設定をクラスター自体に委ねる、簡単な構成のオプションです。このオプションは、Kerberos システムに関する深い知識を必要としないため、テスト環境に適しています。また、クラスター内に専用の KDC を設置することで、Kerberos レルムを分離できるため、組織内の特定のチームまたは部門の認証にのみ使用できる専用の認証システムを提供できます。 ただし、KDC は EMR のプライマリノードに配置されているため、クラスターを削除すると KDC も削除されることを考慮する必要があります。また、KDC を他の EMR クラスター（セキュリティ設定で外部 KDC と定義したもの）と共有する場合を考慮すると、それらの認証レイヤーが侵害され、結果としてすべての Kerberos が有効なフレームワークが機能しなくなります。これはテスト環境では許容されるかもしれませんが、本番環境では推奨されません。 KDC の寿命は特定の EMR クラスターに縛られるとは限らないため、EC2 インスタンスや Docker コンテナに設置した外部 KDC を使用するのが一般的です。このパターンには、次のような利点があります。 Active Directory を使用するかわりに、Kerberos KDC にてエンドユーザーの認証情報を保持することができます（ただし、クロスレルム認証を有効にすることもできます）。 複数の EMR クラスター間で通信を可能にし、すべてのクラスタープリンシパルが同じ Kerberos レルムに参加することで、すべてのクラスターで共通の認証システムを使用できます。 EMR プライマリノードを削除することで他のシステムの認証に影響が出ないように、EMR プライマリノードの依存関係を削除できます。 マルチマスターの EMR クラスターが必要な場合は、外部 KDC が必要です。 しかし、単一のインスタンスに MIT KDC をインストールしても、本番環境で重要な HA 要件には対応できません。次のセクションでは、認証システムの耐障害性を向上させるために、AWS のサービスを使用して可用性の高い MIT KDC を実装する方法について説明します。 アーキテクチャ概要 次の図に示すアーキテクチャは、AWS サービスを使用して、 複数のアベイラビリティゾーンに跨った高可用な MIT Kerberos KDC の構成です。ここでは 2 つのバージョンを提案します。 Amazon Elastic File System (Amazon EFS) ファイルシステムをベースにしたものと、 Amazon FSx for NetApp ONTAP (FSx for ONTAP) ファイルシステムをベースにしたものです。 どちらのサービスも EC2 インスタンスにマウントし、ローカルパスとして使用することが可能です。Amazon EFS はFSx for ONTAP と比較して安価ですが、後者はミリ秒以下の操作レイテンシーを提供するため、パフォーマンス が向上します。 異なるファイルシステムを含むソリューションのベンチマークとして、複数のテストを実施しました。次のグラフは、Amazon EMR 5.36 の結果です。フレームワークとして Hadoop と Spark を選択し、クラスターが完全に立ち上がるまでの時間を秒単位で測定しました。 テスト結果を見ると、NFS プロトコルのロック操作のレイテンシによってもたらされるパフォーマンス低下は、クラスタートポロジーのノード数を増やすとクラスター起動の遅延が大きくなるため、Amazon EFS ファイルシステムは小規模クラスター（100 ノード未満）の処理に適していることがわかります。例えば、200 ノードのクラスターでは、Amazon EFS ファイルシステムによって生じる遅延により、一部のインスタンスは時間内にクラスターに参加できなくなります。その結果、クラスターに参加できないインスタンスは削除され、その後置き換えられるため、クラスター全体のプロビジョニングが遅くなります。これが、上のグラフでクラスターノードの数が 200 の場合の Amazon EFS のメトリックを公開していない理由です。 一方、FSx for ONTAP は、クラスターのプロビジョニング中に作成されるプリンシパルの数が増えても、Amazon EFS と比較してパフォーマンスの低下を抑えながら、より適切に処理できます。 FSx for ONTAP を用いたソリューションであっても、インスタンス数が多いクラスターでは、 Amazon EFS で前述したような挙動が発生する可能性があります。したがって、大きなクラスター構成の場合は、このソリューションを慎重にテストして評価する必要があります。 Amazon EFS を使用したソリューション 次の図は、Amazon EFS を使用したソリューションのアーキテクチャです。 インフラストラクチャは、KDC の耐障害性を向上させるために、さまざまなコンポーネントに依存しています。このアーキテクチャでは、次のサービスを使用しています。 Kerberos サービスポート（認証用の port 88 と、プリンシパルの作成や削除などの管理タスク用の port 749）に対応するように構成された Network Load Balancer を使用しています。このコンポーネントの目的は、別々のアベイラビリティゾーンにある複数の KDC インスタンス間でリクエストのバランスをとることです。また、障害が発生した KDC インスタンスに接続する際のリダイレクトメカニズムを提供します。 KDC の可用性を維持し、定義した条件に従って EC2 インスタンスを自動的に追加または削除できるようにする EC2 Auto Scaling group を使用しています。このシナリオでは、 KDC インスタンスの最小数を 2 台と定義します。 Amazon EFS ファイルシステムは、 KDC データベースのための永続的で信頼性の高いストレージレイヤーを提供します。このサービスには HA プロパティが組み込まれているため、ネイティブ機能として永続的で信頼性の高いファイルシステムを利用できます。 Kerberos の設定、具体的には Kadmin サービスに使用するパスワード、 KDC が管理する Kerberos ドメインとレルムを保存および取得するために AWS Secrets Manager を使用します。Secrets Manager を使用することで、 KDC インスタンスの起動時にスクリプトのパラメータやパスワードなどの機密情報を入力する必要がなくなります。 この構成では、単一インスタンスのインストールによるデメリットがなくなります。 失敗した接続は正常な KDC ホストにリダイレクトされるため、KDC が単一障害点であることはありません。 認証のための EMR プライマリノードに対する Kerberos トラフィックがなくなると、プライマリノードの状態が改善されます。これは、大規模な Hadoop (数百ノードの場合) のインストールでは重要になる場合があります。 障害が発生中も、存続しているインスタンスで管理業務と認証業務を処理しながら復旧することができます。 FSx for ONTAP を使用したソリューション 次の図は、 FSx for ONTAP を使用したソリューションのアーキテクチャです。 このインフラストラクチャは Amazon EFS の構成とほとんど同じ構成であり、同じメリットがあります。唯一の違いは、複数のアベイラビリティゾーンの FSx for ONTAP ファイルシステムを KDC データベースの永続的で信頼性の高いストレージレイヤーとして使用していることです。この場合でも、サービスには HA プロパティが組み込まれているため、そのネイティブ機能を活用して、永続的で信頼性の高いファイルシステムを実現できます。 ソリューションで使用するリソース 本記事では、一般的なガイドとして AWS CloudFormation のテンプレートを提供しています。必要に応じて見直し、カスタマイズする必要があります。また、このスタックによってデプロイされたリソースの中には、使用し続けるとコストが発生するものがあることに注意してください。 CloudFormation テンプレートには、複数のネストしたテンプレートが含まれています。次のものを作成します。 KDC インスタンスをデプロイするための、2 つのパブリックと 2 つのプライベートサブネットを持つ Amazon VPC パブリックサブネットに接続するインターネットゲートウェイとプライベートサブネットに接続する NAT ゲートウェイ 各サブネットの Amazon Simple Storage Service （Amazon S3）ゲートウェイエンドポイントと Secrets Manager インターフェイスエンドポイント VPC を含むリソースがデプロイされた後、KDC のネストされたテンプレートが起動され、次のコンポーネントをプロビジョニングします。 監視する特定の KDC ポート（ Kerberos 認証用の port 88 と Kerberos 管理用の port 749 ）用のリスナーにそれぞれ接続された 2 つのターゲットグループ。 異なるアベイラビリティゾーンに作成された KDC インスタンス間でリクエストのバランスをとるための Network Load Balancer 1 台。 選択したファイルシステムに応じて、複数のアベイラビリティゾーンに跨った Amazon EFS または FSx for ONTAP ファイルシステム。 KDC インスタンスをプロビジョニングするための構成とオートスケーリング。具体的には、KDC インスタンスは、KDC のプリンシパルデータベースを格納するために使用されるローカルフォルダに選択したファイルシステムをマウントするように構成されます。 2 つ目のテンプレートが終了すると、外部 KDC が設定された、選択した場合にはマルチマスター構成で EMR クラスターが起動します。 CloudFormation スタックの起動 スタックを起動し、リソースをプロビジョニングするには、次の手順を実行します。 Launch Stack を選択: 「Launch Stack」をクリックすると、お使いの AWS アカウント（サインイン済でない場合はサインインするように移行します）で AWS CloudFormation テンプレートが自動的に起動します。必要に応じて AWS CloudFormation コンソールでテンプレートを表示することができます。スタックが意図するリージョンで作成されることを確認してください。 CloudFormation スタックには、次のスクリーンショットに示すように、いくつかのパラメータが必要です。 次の表は、スタックの各セクションで設定が必要なパラメータを記載しています。 Core セクションでは, 次のパラメータを指定します。 パラメータ 値 (デフォルト) 説明 Project aws-external-kdc 環境がデプロイされるプロジェクトの名前です。スタックで作成された各リソースに関連付けられた AWS タグを作成する際に使用されます。 Artifacts Repository aws-blogs-artifacts-public/artifacts/BDB-1689 このスタックを起動するために必要なテンプレートとスクリプトをホストしている Amazon S3 のロケーションです。 Networking セクションでは、次のパラメータを指定します。 パラメータ 値 (デフォルト) 説明 VPC Network 10.0.0.0/16 VPC のネットワーク範囲 (例：10.0.0.0/16) Public Subnet One 10.0.10.0/24 1 つ目のパブリックサブネットのネットワーク範囲 (例： 10.0.10.0/24) Public Subnet Two 10.0.11.0/24 2 つ目のパブリックサブネットのネットワーク範囲 (例： 10.0.11.0/24) Private Subnet One 10.0.1.0/24 1 つ目のプライベートサブネットのネットワーク範囲 (例： 10.0.1.0/24). Private Subnet Two 10.0.2.0/24 2 つ目のプライベートサブネットのネットワーク範囲 (例：10.0.2.0/24). Availability Zone One (ユーザー選択) 1 つ目のプライベートおよびパブリックサブネットを配置するためのアベイラビリティゾーン. Availability Zone Two パラメータの値とは異なる値となります。. Availability Zone Two (ユーザー選択) 2 つ目のプライベートおよびパブリックサブネットを配置するためのアベイラビリティゾーン. Availability Zone One パラメータの値とは異なる値となります。 KDC セクションでは、次のパラメータを指定します。 パラメータ 値 (デフォルト) 説明 Storage Service Amazon EFS KDC で使用する共有ファイルシステムを指定します。Amazon EFS または FSx for ONTAP を指定します。 Amazon Linux 2 AMI /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 最新の Amazon Linux 2 AMI を取得するための AWS Systems Manager パラメータエイリアスを指定します。 Instance Count 2 起動する KDC のインスタンスの数 Instance Type c5.large KDC のインスタンスタイプ KDC Realm HADOOP.LAN 外部 KDC サーバーによって管理される Kerberos レルム KAdmin Password Password123 KDC で管理者操作を実行するためのパスワード Kerberos Secret Name aws-external-kdc/kerberos.config Kerberos の設定を保存するために使用される Secrets Manager のシークレット名 EMR では、次のパラメータを指定します。 パラメータ 値 (デフォルト) 説明 Multi Master Disabled 有効にすると、 Hadoop HA で構成された3つのプライマリでクラスターが起動します。 Release Version emr-5.36.0 Amazon EMR のリリースバージョン (Workers) Instance Type m5.xlarge クラスターのプロビジョニングに使用された EC2 インスタンスタイプ (Workers) Node Count 1 クラスターの起動中にプロビジョニングされた Amazon EMR CORE ノードの数 SSH Key Name (ユーザー選択) SSH リモートアクセスを提供するためにクラスターと KDC インスタンスに添付される有効な SSH PEM 鍵 次へ を選択します。 必要に応じて AWS tags を追加します。 (このソリューションでは、すでにいくつかの定義済み AWS タグを使用しています) 次へ を選択します。 最終要件を確認します。 送信 を選択します。 テンプレートのネットワークセクションで、必ず異なるアベイラビリティゾーンを選択してください（Availability Zone One と Availability Zone Two）。これにより、アベイラビリティゾーン全体に障害が発生した場合の障害を防ぐことができます。 インフラストラクチャのテスト インフラストラクチャ全体のプロビジョニングが完了後、HA 構成のテストと検証を行います。 本テストでは、KDC インスタンスの障害発生をシミュレートします。障害が起きた際に、残っている健全な KDC を使い続け、障害が発生した KDC の代わりに KDC インスタンスを追加することで、インフラストラクチャがどのように自己回復するのかを確認します。 CloudFormation スタックを起動し、2つの KDC インスタンスを指定し、KDC データベースのストレージレイヤーとして Amazon EFS を使用してテストを実施しました。EMR クラスターは、11 台の CORE ノードで立ち上げています。 インフラストラクチャ全体をデプロイした後、SSH 接続を使用して EMR プライマリノードに接続 し、テストを実行することができます。 プライマリノード・インスタンスに接続後、テストのセットアップを進めます。 まず、KDC データベース内に 10 個のプリンシパルを作成します。そのために、create_users.sh という bash スクリプトを下記の内容で作成します。 #!/bin/bash realm="HADOOP.LAN" password="Password123" num_users=10 for (( i=1; i<=$num_users; i++ )); do echo "Creating principal test_user$i@$realm" echo -e "$password\n$password\n$password" | kadmin -p kadmin/admin@$realm addprinc "test_user$i@$realm" > /dev/null 2>&1 done 次のコマンドでスクリプトを実行します。 sh create_users.sh 10 個のプリンシパルが KDC データベース内に正しく作成されたことを確認します。これを行うには、list_users.sh という別のスクリプトを作成し、前のスクリプトと同じように実行します。 #!/bin/bash realm="HADOOP.LAN" password="Password123" echo -e "$password\n$password\n$password" | kadmin -p kadmin/admin@$realm listprincs スクリプトの出力には、クラスターノードがプロビジョニングされたときに作成されたプリンシパルと、作成したばかりのテストユーザーが表示されます。 ここで、複数の kinit リクエストを並行して実行し、その間に、利用可能な 2 つの KDC インスタンスのうち 1 つで krb5kdc プロセスを停止します。 このテストは、 kinit リクエストの高い並列性を実現するために、Spark を使用して実行されます。 次に user_kinit.sh というスクリプトを作成します。 #!/bin/sh realm="HADOOP.LAN" password="Password123" num_users="10" for (( i=1; i<=$num_users; i++ )); do echo -e "$password" | kinit test_user$i@$realm > /dev/null 2>&1 echo $? done spark-shell を開き、 —files パラメータを使用して、前述の bash スクリプトをすべての Spark エグゼキューターに配布します。また、Spark の動的割り当てを無効にし、各々が 4 つの vCore を使用する 10 個のエクゼキューターでアプリケーションを起動します。 spark-shell —files user_kinit.sh —num-executors 10 —conf spark.dynamicAllocation.enabled=false —conf spark.executor.cores=4 次の Scala 文を実行して、分散テストを開始します。 val tasks = spark.sparkContext.parallelize(1 to 1600, 1600) val scriptPath = "./user_kinit.sh" val pipeRDD = tasks.pipe(scriptPath) pipeRDD.map(_.toInt).sum この Spark アプリケーションは 1,600 個のタスクを作成し、各タスクは 10 個の kinit リクエストを実行します。 これらのタスクは、一度に 40 個の Spark タスクのバッチで並列に実行されます。このコマンドの最終出力は、失敗した kinit リクエストの数を返します。 ここでは、2 つの利用可能な KDC インスタンス に接続できます。このテンプレートでは、KDC インスタンスに SSH キーを提供していないため、 AWS Systems Manager Session Manager を使用して、SSH キーなしで接続します。Amazon EC2 コンソールから AWS Systems Manager を使用して KDC インスタンスに接続するには、 セッションの開始（ Amazon EC2 コンソール） を参照してください。 1 つ目の KDC にて、次のコマンドを実行して、受信した kinit 認証リクエストを表示します。 sudo -s tail -f /var/log/kerberos/krb5kdc.log 出力例は次のスクリーンショットの通りです。 2 つ目の KDC にて、次のコマンドを実行し、障害をシミュレートします。 sudo -s killall krb5kdc Amazon EC2 のコンソールに接続し、KDC に関連するターゲットグループを開くと、インスタンスの状態が Unhealthy になり（ 3 回連続でヘルスチェックが失敗した後）、その後削除されて新しいインスタンスに置き換えられたことが確認できます。 ターゲットグループは、サービスに障害が発生した際に以下の手順を実行します。 KDC インスタンスが Unhealthy の状態となる。 Unhealthy となった KDC インスタンスをターゲットグループから登録解除する。（ドレイン処理） 新しい KDC インスタンスを起動する。 新しい KDC インスタンスをターゲットグループに登録し、ロードバランサーからのトラフィックを受信できるようにする。 KDC インスタンスに障害が発生している間、次のスクリーンショットのような出力が表示されることが予想されます。 置き換えられた KDC インスタンスに接続すると、 krbr5kdc ログにトラフィックが表示され始めるのが確認できます。 テストの最後には、失敗した Kerberos 認証の総数が表示されます。 出力結果より、このテストでは認証の失敗がありませんでした。しかし、このテストを何度も繰り返すと、いくつかのリクエストの認証中に krbr5kdc のプロセスが停止してしまい、エラー（平均 1 ～ 2 個）が発生する可能性があります。. kinit ツール自体にリトライの仕組みがないことに注意してください。クラスター上で実行される Hadoop サービスと、 EMR インスタンスのプロビジョニング中に行われる Kerberos プリンシパルの作成は、いずれも KDC 呼び出しに失敗した場合にリトライするように設定されています。 これらのテストを自動化したい場合、 AWS Fault Injection Simulator の利用をご検討ください。これは AWS 上でフォールトインジェクション実験を行うためのフルマネージドサービスで、アプリケーションのパフォーマンス、オブザービリティ、レジリエンシーを容易に向上させることができます。 クリーンアップ すべてのリソースをクリーンアップするために、次の手順を行ってください。 AWS CloudFormation のルートスタックの削除。 削除の開始からしばらくすると、失敗が表示されます。 VPC のネストしたCloudFormationスタックをクリックし、 Resources を選択します。VPC リソースに対して、 DELETE_FAILED エントリが表示されています。これは、EMR が自動的に Default Security Groups を作成し、それらが CloudFormation による VPC の削除を妨げていることが原因です。 AWS コンソールの VPC セクションに移動し、その VPC を手動で削除します。 CloudFormation に戻り、ルートスタックを再度選択し、Delete を選択します。今度は削除が完了します。 ファイルシステムのバックアップ Amazon EFS と FSx for ONTAP は AWS Backup にネイティブに統合されています。 AWS Backup は、バックアップの自動化と一元管理を支援します。ポリシー駆動型のプランを作成した後、進行中のバックアップのステータスの監視、コンプライアンスの検証、バックアップの検索と復元をすべてマネジメントコンソールから行うことができます。 詳細については、 「AWS Backup を使用して、Amazon EFS ファイルシステムのバックアップおよび復元するには」 および、 「Amazon FSx で AWS Backup を使用する」 を参照してください。 その他考慮事項 本セクションでは、このソリューションを使用する際の考慮事項を説明します。 共有ファイルシステムのレイテンシーが与える影響 共有ファイルシステムの利用は、多くの場合パフォーマンスの低下に繋がります。特に、同時に作成しなければならない Kerberos プリンシパルが多ければ多いほど、プリンシパル作成プロセスとクラスター起動時間にレイテンシーが発生することがわかります。 この性能低下は、同時に行われる並列 KDC リクエストの数に比例します。たとえば、同じ KDC に接続された 20 ノードを持つ 10 個のクラスターを起動しなければならないシナリオを考えてみます。10 個のクラスターを同時に立ち上げると、フレームワークに関連する Kerberos プリンシパルを作成するための最初のインスタンスプロビジョニング中に、KDC へ 10 × 20 ＝ 200 の並列接続が発生する可能性があります。さらに、サービス用の Kerberos チケットの持続時間はデフォルトで 10 時間であり、すべてのクラスターサービスがほぼ同時に起動されるため、サービスチケットの更新にも同じレベルの並列性が発生する可能性があります。一方、この 10 個のクラスターを時間差で起動すると、並列接続が20個で収まる可能性があります。その結果、共有ファイルシステムによって生じるレイテンシーはそれほどパフォーマンスに影響しません。 本記事にて先述したように、複数クラスターでは関連する KDC 間でクロスレルム認証を設定することなく、互いに通信する必要がある場合に同じ KDC を共有することができます。複数のクラスターを同じ KDC にアタッチする前に、その必要性が本当にあるかどうかを評価する必要があります。なぜなら、より良いパフォーマンスを実現し、問題が発生した場合の影響範囲を小さくするために、Kerberos レルムを異なる KDC インスタンスに分離することも検討できるからです。 まとめ ダウンタイムが許されない EMR クラスターにとって、高可用性と耐障害性は重要な要件です。これらのクラスター内で実行される分析ワークロードは、機密データを扱う可能性があるため、安全な環境での運用が不可欠です。そのため、安全で可用性が高く、耐障害性の高いセットアップが必要です。 本記事では、Amazon EMR のビッグデータワークロードの認証レイヤーの高可用性と耐障害性を持たせるひとつの実現方法を紹介しました。AWS のネイティブサービスを使用することで、複数の Kerberos KDC を並行して動作させ、障害が発生した場合に自動的にインスタンスを交換する方法を示しました。これとフレームワーク固有の高可用性および耐障害性を組み合わせることで、安全で高可用性かつ耐障害性を持った環境で運用することができます。 翻訳はネットアップ合同会社の岩井様、監修はテクニカルアカウントマネージャーの有田が担当しました。 著者について Lorenzo Ripani は、AWS の Big Data Solution Architect です。分散システム、オープンソース技術、セキュリティに特化しています。世界中の顧客に対して、Amazon EMR を使ったスケーラブルで安全なデータパイプラインの設計、評価、最適化を提供しています。 Stefano Sandona は、AWS の Analytics Specialist Solution Architect です。データ、分散システム、セキュリティに特化しているエンジニアです。世界中の顧客のデータプラットフォームのアーキテクトを支援しています。Amazon EMR とその周辺のセキュリティに強い関心を持っています。

このブログは 2023 年 8 月 8 日に Dave Jaskie によって投稿された Migrating Amazon WorkSpaces services from Microsoft Office included bundles to Microsoft 365 を翻訳したものです。このブログでは、WorkSpaces サービスで実行されている Office バンドルから Microsoft 365 に移行する方法について説明します。 AWS では、 Amazon WorkSpaces サービスで Microsoft Office アプリケーションを実行するための 2 つの選択肢を提供しています。 Microsoft Office は、WorkSpaces アプリケーションバンドルの一部として購入できます。 また、2023 年 8 月 1 日より、 Microsoft 365 Apps for enterprise ライセンスを Amazon WorkSpaces サービスで使用できる ようになりました。 Microsoft 365 は、Microsoft Word、Microsoft Excel、Microsoft PowerPoint、Microsoft Outlook、 その他 の一般的なオフィスアプリケーションを使用して WorkSpaces サービスの機能を強化します。 含まれるアプリケーションは Microsoft 365 ライセンス プランによって異なります。 Microsoft では、Microsoft 365 E3、E5、A3、A5、Business Premium ライセンスを WorkSpaces サービスで実行することを許可しています。 このブログでは、WorkSpaces サービスで実行されている Office バンドルから Microsoft 365 に移行する方法について説明します。 WorkSpaces インスタンスで Microsoft 365 の使用を開始するために必要な手順は、次のシナリオで説明する多くの要因によって異なります。 一般的なシナリオ シナリオ1: カスタムパブリックバンドルを使用して、WorkSpaces を展開しました。このバンドルは、デスクトップエクスペリエンスを搭載した Microsoft Windows Server をベースにしており、AWS が提供する Office ライセンスを使用しています。 まず、AWS が提供する WorkSpaces の Office ライセンスを削除します。 WorkSpaces から Office ライセンスを削除するには、Office の AWS ライセンスが含まれていない新しいイメージから新しい WorkSpaces バンドルを作成します。 既存の WorkSpaces インスタンスから Office をアンインストールするだけでは、Office の AWS ライセンス料金は削除されないことに注意してください。 次の手順に従います。 パブリックバンドルから新しい WorkSpaces を起動します。リストされたイメージに Office が含まれていないことを確認するために、Software の選択で “Base”  をフィルタリングします。 新しく作成した WorkSpaces にログインします。Windows を更新し、Microsoft 365 とその他の必要なアプリケーションをインストールして、WorkSpaces のイメージを作成します。 新しいイメージの作成が完了したら、そのイメージからカスタムバンドルを作成します。 新しいカスタムバンドルができたので、個々の WorkSpaces をそのバンドルに移行できます。 追加の情報については、 カスタムの WorkSpaces イメージとバンドルの作成 、および、 WorkSpace の移行 、に関するドキュメントを参照してください。 シナリオ2: カスタムバンドルを使用し、AWS 提供の Office ライセンスを使用して、Windows デスクトップでのライセンス持ち込み (BYOL) に基づき Amazon WorkSpaces を展開しています。 まず、AWS が提供する WorkSpaces の Office ライセンスを削除します。 WorkSpaces から Office ライセンスを削除するには、Office の AWS ライセンスが含まれていない新しいイメージから新しい WorkSpaces バンドルを作成します。 既存の WorkSpaces インスタンスから Office をアンインストールするだけでは、Office の AWS ライセンス料金は削除されないことに注意してください。 移行プロセスは、シナリオ1 で説明したプロセスと似ています。違いは、代替となるベースイメージが、パブリック WorkSpaces イメージからではなく、BYOL イメージとして Amazon Compute Cloud (EC2) へインポートした Amazon Machine Image (AMI) から取得される点です。 参考として、 自分の Windows デスクトップライセンスを使用する を参照してください。 ステップ 6 の WorkSpaces コンソールを使用して BYOL イメージを作成する から開始できます。 WorkSpaces コンソールのイメージ にて、 “BYOL イメージの作成” を選択します。 AMI ID には、以前のイメージを作成したのと同じ EC2 AMI を使用します。アプリケーションを選択のドロップダウンリストでは、Microsoft Office 2016 または Microsoft Office 2019 を選択しないでください。 新しい BYOL イメージの作成が完了したら、カスタムバンドルを作成します。 新しいカスタムバンドルができたら、コンソールまたは API で、個々の WorkSpaces を移行できます。 詳細については、 カスタムの WorkSpaces イメージとバンドルの作成 、 WorkSpace の移行 に関するドキュメントを参照してください。 シナリオ3: 既存のWorkSpacesインスタンスにOfficeがインストールされていないか、Microsoft 365 以外のバージョンの Office がインストールされています。 このシナリオでは、WorkSpaces インスタンスは AWS が提供する Office バンドルを実行していません。 WorkSpaces インスタンスに他のバージョンの Office がある場合は、まずそれらをアンインストールしてから、Microsoft 365 のインストールを実行します。 WorkSpaces インスタンスに他のバージョンの Office がない場合は、Microsoft 365 のインストールに進むことができます。 Office の展開に関する Microsoft の推奨事項 を確認してください。 シナリオ4: 新しい WorkSpaces インスタンスの展開。 新しい WorkSpaces インスタンスでは、AWS から Office バンドルを購入して使用しないでください。Microsoft 365 アプリケーションを展開するには、Microsoftの推奨事項に従ってください。Officeは カスタムイメージとしてバンドルに追加 するか、WorkSpaces インスタンスの起動後に展開できます。 シナリオ5 : Microsoft からの例外がある。 ユーザーが Microsoft 365 で展開された WorkSpaces インスタンスの利用を許諾され、すでにその環境を利用している場合は、正しいライセンスが配置されていることを Microsoft ライセンスプロバイダに確認してください。 API を使用した移行の自動化 複数の WorkSpaces のバンドルを一度に移行するには、 MigrateWorkSpaces API を使用します。 コマンドが発行されると切断されるため、ユーザーが WorkSpaces を使用していないことを確認してください。 このプロセスを自動化するには、 AWS CLI 、 AWS Tools for PowerShell 、または、 AWS SDK を使用してカスタムスクリプトを作成します。 特定のバンドルを持つ WorkSpaces のリストを取得する まずは非本番環境でテストし、その後 WorkSpaces インスタンスを少量ずつ移行することをお勧めします。大規模な移行を計画している場合は、AWS アカウントチームに支援を依頼してください。 PowerShell を開き、次のように入力します。 Get-WKSWorkSpaces -Region [ your-region-id ] -BundleId [ your-bundled ] WorkSpaces のマイグレーション PowerShell を開き、移行する WorkSpaceId、Region、および、BundleId を指定し、以下のコマンドを実行します。 Start-WKSWorkspaceMigration -SourceWorkspaceId [ your-workspaceid ] -Region [ your-region-id ] -BundleId [ your-bundleid ] または、オープンソースの EUC Toolkit プロジェクトを使用して、自動化を開始するための対話型 GUI を作成することもできます。 WorkSpace インスタンスの新しいバンドルへの移行 WorkSpaces が特定されたら、次のコマンドを使用して移行できます。 Start-WKSWorkspaceMigration 結論 このブログでは、Microsoft 365 Apps for enterprises のライセンスを Amazon WorkSpaces で使用するためのオプションを紹介しました。 さらに、Office バンドルとともに展開された WorkSpaces バンドルを識別するためのいくつかのオプションも取り上げました。 これらの情報を使用して、Microsoft 365 への移行の計画と自動化を開始することができます。 このブログに記載されている手順を、お客様の特定のユースケースに最適化する方法についてご相談されたい場合は、アカウントチームまでご連絡ください。 翻訳はソリューションアーキテクトの平田が担当しました。原文は こちら です。

この記事は Exposing Kubernetes Applications, Part 3: NGINX Ingress Controller (記事公開日: 2022 年 11 月 22 日) を翻訳したものです。 はじめに 連載「Kubernetes アプリケーションの公開」では、Kubernetes クラスターで実行されているアプリケーションを、外部からのアクセスのために公開する方法に焦点を当てます。 Part 1 では、Kubernetes クラスターでインバウンドトラフィックの制御を定義する 2 つの方法である Service と Ingress リソースタイプについて探りました。Service と Ingress コントローラーによるこれらのリソースタイプの処理について説明し、その後、いくつかのコントローラーの実装バリエーションの利点と欠点について概要を説明しました。 Part 2 では、Ingress コントローラーの AWS のオープンソース実装である AWS Load Balancer Controller について、セットアップ、設定、想定されるユースケース、制限事項をウォークスルーしました。 今回、Part 3 では、Ingress コントローラーのまた別のオープンソース実装である NGINX Ingress Controller に注目します。その機能の一部や、AWS Load Balancer Controller との違いについてウォークスルーします。 NGINX Ingress Controller のアーキテクチャ Part 1 では、下図に示すようなクラスター内レイヤー 7 リバースプロキシーを使用する Ingress コントローラーのタイプについて説明しました。 NGINX Ingress Controller の実装は、上記のアーキテクチャに沿っています。 コントローラーは、人気のあるオープンソースの HTTP およびリバースプロキシサーバーである nginx のインスタンスを含む Pod をデプロイ、設定、および管理します。これらの Pod は 、コントローラーの Service リソースを介して公開され、Ingress およびバックエンドの Service リソースで表される関連アプリケーションを対象としたすべてのトラフィックを受信します。コントローラーは、Ingress と Service の設定を、静的に提供される追加パラメータと組み合わせて、標準的な nginx の設定に変換します。そして、この設定を nginx の Pod に注入し、トラフィックをアプリケーションの Pod にルーティングします。 NGINX Ingress Controller の Service は、ロードバランサーを介して外部トラフィック向けに公開されています。この Service は、通常の <service-name>.<namespace-name>.svc.cluster.local クラスター DNS 名を介してクラスター内部からも利用できます。 ウォークスルー NGINX Ingress Controller がどのように動作するかを理解したので、実際に動作させてみましょう。 前提条件 1. AWS アカウントへのアクセスの取得 AWS アカウントと、AWS コマンドラインインターフェイス ( AWS CLI ) や類似のツールを使用して、ターミナルから AWS と通信できる必要があります。 以下のコード例では、AWS アカウント ID やリージョンなど、置き換えることを前提とした文字列がいくつかが含まれています。これらは、あなたの環境に合った値で置き換えてください。 2. クラスターの作成 eksctl を使用して Amazon EKS クラスターをプロビジョニングします。eksctl はクラスター自体の作成に加えて、VPC、サブネット、セキュリティグループといった必要なネットワークリソースもプロビジョニングおよび設定します。 以下の eksctl 設定ファイルは、 Amazon EKS クラスターとその設定を定義します。 apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: nginx-ingress-controller-walkthrough region: ${AWS_REGION} version: '1.27' iam: withOIDC: true managedNodeGroups: - name: main-ng instanceType: m5.large desiredCapacity: 1 privateNetworking: true 上記のコードを config.yml ファイルに記述してください。 AWS_REGION および AWS_ACCOUNT 環境変数を定義してください。その後、クラスターを作成します。 envsubst < config.yml | eksctl create cluster -f - このウォークスルーでは、Kubernetes バージョン 1.23 の Amazon EKS プラットフォームバージョン eks.3 を使用しています。(訳注: 翻訳時には、Kubernetes バージョン 1.27 の Amazon EKS プラットフォームバージョン eks.4 を使用して動作を確認しています。) シンプルにするため、上記の構成では、セキュリティやモニタリングなど、Kubernetes クラスターのプロビジョニングと管理の多くの側面は考慮していません。より詳細な情報とベストプラクティスについては、 Amazon EKS と eksctl のドキュメントを参照してください。 クラスターが稼働していることを確認します。 kubectl get nodes kubectl get pods -A 上記のコマンドは、1 つの Amazon EKS ノードと 4 つの実行中の Pod を返すはずです。 3. Helm のインストール コントローラーのインストールと設定には、Kubernetes において一般的なパッケージマネージャーである Helm を使用します。 こちら の手順に従って Helm をインストールしてください。 NGINX Ingress Controller のインストール 1. Helm を使用したコントローラーのインストール helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm upgrade -i ingress-nginx ingress-nginx/ingress-nginx \ --version 4.2.3 \ --namespace kube-system \ --set controller.service.type=ClusterIP kubectl -n kube-system rollout status deployment ingress-nginx-controller kubectl get deployment -n kube-system ingress-nginx-controller コントローラーの Service を ClusterIP に設定しています。これは、ウォークスルー中にコントローラーの様々な設定パラメータを変更した際に、ロードバランサーが再作成されるのを回避するためです。ロードバランサーの作成については、記事の後半で説明します。 テスト用 Service のデプロイ 1. Namespace の作成 kubectl create namespace apps 2. Service のマニフェストファイルの作成 以下のコードを service.yml ファイルに記述します。 apiVersion: apps/v1 kind: Deployment metadata: name: ${SERVICE_NAME} namespace: ${NS} labels: app.kubernetes.io/name: ${SERVICE_NAME} spec: selector: matchLabels: app.kubernetes.io/name: ${SERVICE_NAME} replicas: 1 template: metadata: labels: app.kubernetes.io/name: ${SERVICE_NAME} spec: terminationGracePeriodSeconds: 0 containers: - name: ${SERVICE_NAME} image: hashicorp/http-echo imagePullPolicy: IfNotPresent args: - -listen=:3000 - -text=${SERVICE_NAME} ports: - name: app-port containerPort: 3000 resources: requests: cpu: 0.125 memory: 50Mi --- apiVersion: v1 kind: Service metadata: name: ${SERVICE_NAME} namespace: ${NS} labels: app.kubernetes.io/name: ${SERVICE_NAME} spec: type: ClusterIP selector: app.kubernetes.io/name: ${SERVICE_NAME} ports: - name: svc-port port: 80 targetPort: app-port protocol: TCP http-echo イメージを使用する上記の Service は、 ${SERVICE_NAME} 変数で定義した Service 名でリクエストに応答します。シンプルにするため、レプリカは 1 つとしています。 3. サービスのデプロイと検証 以下のコマンドを実行します (この記事を通して、これらの Service を使用します) 。 SERVICE_NAME=first NS=apps envsubst < service.yml | kubectl apply -f - SERVICE_NAME=second NS=apps envsubst < service.yml | kubectl apply -f - SERVICE_NAME=third NS=apps envsubst < service.yml | kubectl apply -f - SERVICE_NAME=fourth NS=apps envsubst < service.yml | kubectl apply -f - SERVICE_NAME=error NS=apps envsubst < service.yml | kubectl apply -f - SERVICE_NAME=another-error NS=apps envsubst < service.yml | kubectl apply -f - すべてのリソースがデプロイされていることを確認しましょう。 kubectl get pod,svc -n apps シンプルな Ingress のデプロイ 1. Ingress のマニフェストファイルの作成と Ingress のデプロイ 以下のコードを ingress.yml ファイルにコピーしてください。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ${NS}-ingress namespace: ${NS} spec: ingressClassName: nginx rules: - http: paths: - path: /first pathType: Prefix backend: service: name: first port: name: svc-port - path: /second pathType: Prefix backend: service: name: second port: name: svc-port AWS Load Balancer Controller の場合に見たのと同じように、 ingressClassName プロパティを nginx に設定することで、 NGINX Ingress Controller をターゲットにします。 nginx はコントローラーとともにインストールされるデフォルトの IngressClass の名前です。 以下のコマンドを実行して Ingress をデプロイします。 NS=apps envsubst < ingress.yml | kubectl apply -f - しばらくすると、Ingress リソースの状態を確認できるようになります (IP アドレスのバインドには少し時間がかかる場合があります) 。 kubectl get ingress -n apps 以下のような出力が得られます。 上記の ADDRESS と PORT 列は、コントローラーの Service のものが設定されています。 ClusterIP タイプで Service を作成するようにコントローラーを設定したため、Service と通信する方法として、Service に対するポートフォワーディングを設定する必要があります。 kubectl port-forward -n kube-system svc/ingress-nginx-controller 8080:80 2. Ingress のテスト これで、コントローラーの Service にリクエストを送信できるようになりました。 curl -sS localhost:8080/first curl -sS localhost:8080/second curl -sS localhost:8080/third 次の結果が得られれば、Ingress リソースがは正しくデプロイされ、設定されています。 IngressClass に関する考察 前述したように、 nginx という名前のデフォルトの IngressClass がコントローラーと一緒にインストールされています。以下のようなリソースです。 apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: nginx labels: app.kubernetes.io/name: ingress-nginx ... spec: controller: k8s.io/ingress-nginx AWS Load Balancer Controller とは異なり、 NGINX Ingress Controller は IngressClass パラメータ をサポートしていません。 IngressClass をデフォルトにするためには、 ingressclass.kubernetes.io/is-default-class: "true" アノテーションを追加するか、コントローラーのインストール時にデフォルトにするように設定します。 helm upgrade -i ingress-nginx ingress-nginx/ingress-nginx \ --namespace kube-system \ --set controller.ingressClassResource.default=true \ ... Default Backend とエラーハンドリング Ingress リソースのいずれかによって処理されないパスにリクエストを送信すると、nginx が 404 で応答することを確認しました。このレスポンスは、コントローラーにインストールされている Default Backend から返されます。これをカスタマイズする 1 つの方法は、たとえば Helm の values.yml ファイル を介して、 controller.defaultBackend プロパティを設定することです。これについては、この記事で後ほど説明します。もう 1 つの方法は、Ingress リソースに nginx.ingress.kubernetes.io/default-backend アノテーションを設定することです。 最後の方法として、次に示すような Ingress の仕様で設定することができます。 1. Ingress の更新とデプロイ ingress.yml ファイルを以下のように更新します。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ${NS}-ingress namespace: ${NS} spec: ingressClassName: nginx defaultBackend: service: name: error port: name: svc-port rules: - http: paths: - path: /first pathType: Prefix backend: service: name: first port: name: svc-port - path: /second pathType: Prefix backend: service: name: second port: name: svc-port デプロイします。 NS=apps envsubst < ingress.yml | kubectl apply -f - 2. Ingress のテスト これで、再びリクエストを送信してみましょう。 curl -sS localhost:8080/first curl -sS localhost:8080/second curl -sS localhost:8080/third これは、Default Backend を使用して、期待どおりに機能します。 複数の Ingress リソース 複数の Ingress リソースがあり、それらが異なるチームに属していたり、より大きなアプリケーションの一部であったりすることがよくあります。これらは別々に開発されデプロイされる必要がありますが、別々の構成は必要なく、1 つのコントローラーのインストールで処理できます。 NGINX Ingress Controller は Ingress リソースの マージをサポート していますが、 AWS Load Balancer Controller のようにリソースの順序やグルーピングを明示的に定義することはできません。 ホストベースのルーティング これまでのすべての例では、すべてのリクエストは同じドメインにルーティングされ、Ingress リソースが同じ *.* ホストにマージされることを前提としていました。どの Service がどのドメインで提供されるかを明示的に定義し、Ingress のホスト設定でそれらをセグメント化したりマージしたりすることもできます。 1. Ingress の更新とデプロイ ingress.yml を更新します。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ${NS}-ingress namespace: ${NS} spec: ingressClassName: nginx defaultBackend: service: name: error port: name: svc-port rules: - host: a.example.com http: paths: - path: /first pathType: Prefix backend: service: name: first port: name: svc-port - host: b.example.com http: paths: - path: /second pathType: Prefix backend: service: name: second port: name: svc-port 以下のコマンドを実行します。 NS=apps envsubst < ingress.yml | kubectl apply -f - 2. Ingress のテスト curl を使用して、さまざまなドメインへのリクエストをシミュレートできます。 curl localhost:8080/first -H 'Host: a.example.com' curl localhost:8080/second -H 'Host: b.example.com' curl localhost:8080/first -H 'Host: b.example.com' curl localhost:8080/first -H 'Host: b.example.net' 出力は次のようになります。 最後の 2 つのリクエストは、Default Backend にルーティングされることが期待されます。1 つはそのホストで定義されていないパスに送信されているため、もう 1 つは存在しないホストであるためです。 a.myapp.com と b.myapp.com の DNS レコードを NGINX Ingress Controller の Service に向けることで、両方のホストを処理することができます。このタスクを完了するために、Service を外部トラフィック向けに公開します (外部ロードバランサー経由など) 。これについては、この記事の後半で詳しく説明します。 Ingress の pathType および正規表現とリライト これまで、Ingress ルールの pathType を Prefix と定義してきました。 pathType を Exact に設定し、パスで 正規表現を使用 したり、リライトルールを定義することもできます。 1. Ingress の更新とデプロイ ingress.yml ファイルの Ingress 定義を変更し、再デプロイしましょう。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ${NS}-ingress namespace: ${NS} annotations: nginx.ingress.kubernetes.io/rewrite-target: /$1 spec: ingressClassName: nginx defaultBackend: service: name: error port: name: svc-port rules: - http: paths: - path: /first/(.*)/foo pathType: Prefix backend: service: name: first port: name: svc-port nginx.ingress.kubernetes.io/rewrite-target アノテーションは、ルールのパスで定義されたキャプチャグループのうち、どれを Service に送信するかを定義しています。すなわち、 /$1 の場合は、1 番目のキャプチャグループの内容をリクエストのパスとして Service に送信します。 Ingress をデプロイしましょう。 NS=apps envsubst < ingress.yml | kubectl apply -f - 2. Ingress のテスト テストを実行します。 curl -sS localhost:8080/first curl -sS localhost:8080/first/foo curl -sS localhost:8080/first/bar curl -sS localhost:8080/first/bar/foo これは、次のような結果になります。 ロードバランサー経由で NGINX Ingress Controller を公開する in-tree Service コントローラーを使用する NGINX Ingress Controller を外部トラフィック向けに公開する最もシンプルな方法は、 Part 1 で説明した in-tree コントローラー に Service を処理させることです。そのためには、Service のタイプを LoadBalancer に設定します。これによって、 AWS Classic Load Balancer (CLB) がプロビジョニングされます。 helm upgrade -i ingress-nginx ingress-nginx/ingress-nginx \ --namespace kube-system \ --set controller.service.type=LoadBalancer \ ... AWS Classic Load Balancer の代わりに、より新しく、推奨される AWS Network Load Balancer を指定することもできます。 helm upgrade -i ingress-nginx ingress-nginx/ingress-nginx \ --namespace kube-system \ --set controller.service.type=LoadBalancer \ --set controller.service.annotations."service\.beta\.kubernetes\.io/aws-load-balancer-type"="nlb" \ ... また、Helm の values.yml ファイルを使用して、これらの設定パラメータをより快適な方法で提供することもでき、同じ効果を得られます。次のセクションでそのような使用例を見ていきます。 AWS Load Balancer Controller を使用する方法 Service のために作成しプロビジョニングされる Network Load Balancer をより詳細に制御したい場合は、Service コントローラーをインストールします。 AWS Load Balancer Controller が推奨される選択肢です。 AWS Load Balancer Controller も Ingress リソースを処理しますが、処理対象の IngressClass が alb であり NGINX Ingress Controller とは異なるため、衝突は発生しません。 NGINX Ingress Controller 用に AWS NLB をプロビジョニングする AWS Load Balancer Controller のインストールについては、すでに連載の Part 2 で説明しましたので、これについてはおなじみのはずです。 1. AWS Load Balancer Controller 用の AWS IAM ポリシーの作成 この手順のステップ 2 と3 のみ を実行して、 AWSLoadBalancerControllerIAMPolicy を作成します。IRSA ( IAM Roles for Service Accounts ) を使用して、AWS Load Balancer Controller に IAM アクセス許可を提供します。 なお、 OIDC IAM プロバイダー の登録は、上述のクラスター定義によって eksctl が自動的に行うため、明示的に行う必要はありません。 2. AWS Load Balancer Controller 用の Service Account の作成 連載の Part 2 では、 eksctl によるクラスターの作成時に、 AWS Load Balancer Controller の Service Account を作成しましたが、今回は個別に作成します。 eksctl create iamserviceaccount \ --cluster=nginx-ingress-controller-walkthrough \ --name=aws-load-balancer-controller \ --namespace=kube-system \ --attach-policy-arn=arn:aws:iam::${AWS_ACCOUNT}:policy/AWSLoadBalancerControllerIAMPolicy \ --approve 3. CRD のインストール 以下のコマンドは、AWS Load Balancer Controller が機能するために必要な CustomResourceDefinition をインストールします。 kubectl apply -k \ "github.com/aws/eks-charts/stable/aws-load-balancer-controller//crds?ref=master" 4. Helm を使用した AWS Load Balancer Controller のインストール helm repo add eks https://aws.github.io/eks-charts helm upgrade -i aws-load-balancer-controller eks/aws-load-balancer-controller \ -n kube-system \ --set clusterName=nginx-ingress-controller-walkthrough \ --set serviceAccount.create=false \ --set serviceAccount.name=aws-load-balancer-controller kubectl -n kube-system rollout status deployment aws-load-balancer-controller kubectl get deployment -n kube-system aws-load-balancer-controller 5. NGINX Ingress Controller の再デプロイ NGINX Ingress Controller の Helm チャートに設定パラメータを渡す方法を変更します。 values.yml ファイルを作成します。 controller: service: type: LoadBalancer annotations: service.beta.kubernetes.io/aws-load-balancer-name: apps-ingress service.beta.kubernetes.io/aws-load-balancer-type: external service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: http service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: /healthz service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: 10254 ここでは、Service のタイプを変更し、ロードバランサー (Network Load Balancer) の名前を定義し、アクセスできるように internet-facing としています。さらに、ターゲットタイプを ip とし、NGINX サーバーのヘルスチェックを設定しています。 AWS Load Balancer Controller の Service のアノテーションの詳細については、 ここ を参照してください。 NGINX Ingress Controller を再デプロイします。 helm upgrade -i ingress-nginx ingress-nginx/ingress-nginx \ --version 4.2.3 \ --namespace kube-system \ --values values.yml kubectl -n kube-system rollout status deployment ingress-nginx-controller kubectl get deployment -n kube-system ingress-nginx-controller 6. Ingress のテスト pathType やコントローラーのリライト機能を説明するために使用したのと同じ Ingress 定義を使っていることに注意してください。 Network Load Balancer の URL を環境変数に保存します。 export NLB_URL=$(kubectl get -n kube-system service/ingress-nginx-controller \ -o jsonpath='{.status.loadBalancer.ingress[0].hostname}') 数分後、ロードバランサーのプロビジョニングが完了すると、リクエストを送信できるようになります。 curl ${NLB_URL}/first curl ${NLB_URL}/first/foo curl ${NLB_URL}/first/bar curl ${NLB_URL}/first/bar/foo これによって、予想どおり、以前と同じ結果が得られます。 既存のロードバランサーに NGINX Ingress Controller をアタッチする 前述の Service コントローラーを使用する方法に加えて、AWS CLI や Infrastructure as Code ツール ( AWS CloudFormation 、 AWS CDK 、 Terraform など) を介して Application Load Balancer や Network Load Balancer をプロビジョニングすることも可能です。 そのような場合、上記でインストールしたカスタムリソース定義の一部である TargetGroupBinding を使用することができます。 このリソース は、Service の Pod の IP アドレスをターゲットグループのターゲットとして登録することにより、Service (名前と Namespace で選択) をロードバランサーのターゲットグループ ( ARN で選択) にバインドします。 これは、ロードバランサーが他のコンピュートリソースで使用されている場合に有用な場合があります。まれに、クラスター内レイヤー 7 プロキシの上に、Application Load Balancer の独自機能の 1 つを利用するように設定する必要がある場合にも有用です。 複数の Ingress コントローラー 場合によっては、クラスター内に NGINX Ingress Controller の複数のインスタンスを構成して、別々の Ingress リソースを処理させることができます。これは、コントローラーに異なる設定を提供することで実現します。 AWS Load Balancer Controller とは異なり、 NGINX Ingress Controller はこのような構成をサポートしています。 次の例は 2 番目のコントローラーの例です。ユニークな名前、IngressClass 名、コントローラー値の設定が IngressClass に反映されます。 helm upgrade -i ingress-nginx-one ingress-nginx/ingress-nginx \ --namespace kube-system \ --set controller.ingressClassResource.controllerValue=k8s.io/ingress-nginx-one \ --set controller.ingressClassResource.name=nginx-one \ ... これで、Ingress リソースは、 ingressClassName を nginx-one に設定することで、このコントローラをターゲットにできるようになります。 クリーンアップ これでウォークスルーは終了です。ウォークスルー中に作成したリソースを削除するには、次のコマンドを実行します。 helm uninstall -n kube-system ingress-nginx helm uninstall -n kube-system aws-load-balancer-controller envsubst < config.yml | eksctl delete cluster -f - aws iam delete-policy --policy-arn arn:aws:iam::${AWS_ACCOUNT}:policy/AWSLoadBalancerControllerIAMPolicy まとめ このシリーズでは、いくつかの Ingress コントローラーを紹介し、それぞれがどのように異なる動作をするのかを強調しながら説明しました。 NGINX Ingress Controller は、nginx のパワーを利用します。これはより柔軟なコントローラーですが、リクエストのデータパス上に必要なコンポーネントのメンテナンス、パッチ適用、スケーリングが必要になるという欠点があります。 これに対し、 AWS Load Balancer Controller は、その負担を、可用性が高くスケーラブルで実績のあるマネージドサービスである Elastic Load Balancing にアウトソーシングし、その機能セットに依存して必要な設定オプションを提供します。 極めて高い柔軟性と運用の簡便性のどちらを選択するかは、導入されるアプリケーションの要件に基づいて決まります。この連載では取り上げていない他の Service コントローラーや Ingress コントローラーとともに、アプリケーションを外部トラフィックに公開するための豊富な選択肢を提供するはずです。 翻訳はプロフェッショナルサービスの杉田が担当しました。原文は こちら です。