このブログは 2023 年 11 月 17 日に Daniel Rabinovich（Software Development Engineer）、Vyassa Baratham（Software Development Engineer）、Mahesh Goud Paruchuri（Software Development Manager）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 企業では、複数のチームやプロジェクトで使用されるワークロードや関連リソースをグループ化するために、個別のアカウントを使用することがよくあります。これにより、組織は所有権、意思決定、コストを調整し、社内のチーム間で容易に管理できるようになります。しかし、アカウント内の各チームは、重要なリソースとそうでないリソースに関して、異なる要件やプロセスを持つ場合があります。このような要件やプロセスが混在していると、バックアップの失敗によってデータが失われ、大幅なダウンタイムが発生し、 目標復旧時点 が達成できない可能性があります。一方、アカウントの所有者や管理者は、各チームやプロジェクトのプロセスの詳細を知らないため、アカウントレベルでバックアップの要件を決定することは困難です。 現在お客様は、 Amazon Elastic Block Store（EBS） ボリュームを EBS スナップショット に、 Amazon Elastic Compute Cloud（Amazon EC2） を EBS-backed Amazon Machine Images（EBS-backed AMI）に自動的にバックアップするために使用できる幅広い製品、機能、カスタムスクリプトの選択肢を持っています。これらのツールは互いに独立して動作するため、異なるチームが同じリソースをバックアップするために異なるツールを使用すると、重複したバックアップが作成され、追加コストが発生する可能性があります。 アカウントの所有者とストレージの管理者は、 Amazon Data Lifecycle Manager のデフォルトポリシーを使用して、作成されるリソースの数を最小限に抑えながら、すべての重要なワークロードを保護できるようになりました。デフォルトポリシーは、インスタンスまたはボリュームに、デフォルトポリシーで設定された作成頻度を満たす最近のバックアップがない場合にのみ、新しいバックアップを作成します。それ以外のメカニズムでバックアップが正常に作成されている場合、デフォルトポリシーは対象のリソースに対して新しい AMI またはスナップショットを作成しません。 この記事では、お客様が Amazon Data Lifecycle Manager のデフォルトポリシーをどのように設定すれば、リソースの重複作成とコストを最小限に抑えながら、重要なワークロードを確実にバックアップできるかを説明します。Amazon EC2 インスタンスと Amazon EBS ボリュームに対するデフォルトポリシーのセットアップの概要を説明し、Amazon EC2 のコンソールでデフォルトポリシーが作成するリソースを検証します。デフォルトポリシーは、アカウント内のすべてのインスタンスとボリュームを自動バックアップする簡単な方法が必要なお客様にも最適なオプションです。デフォルトポリシーを使用することで、アカウントの所有者や管理者は、アカウントで動作するチームやプロジェクトが使用するさまざまなプロセスに関係なく、アカウント内のすべての重要なワークロードがバックアップされているという安心感を得ることができます。 シナリオ 以下は、バックアップが必要とされる 2 つの一般的なシナリオです: シナリオ 1: 一人のユーザーがすべてのリソースをバックアップする簡単な方法を求めている アリスはアカウントの所有者で、アカウント内のすべてのインスタンスとボリュームの自動バックアップを有効にする簡単な方法を求めています。Amazon EC2 のコンソールからこの機能を有効にし、「確実に動く」ことを確認したいです。 シナリオ 2: ストレージ管理者は、重要なワークロードがすべてバックアップされていることを確認したい ボブは組織のストレージ管理者で、主要アカウントの重要なワークロードが定期的にバックアップされていることを確認する責任を負っています。このアカウントは複数のチームとユーザーによって使用されており、それぞれが独自の要件を持っています。アカウントのユーザーがデータをリストアするためのバックアップを見つけることができない場合、ボブは彼らの最初の連絡先となります。次の図は、1 つのアカウントで動作するすべてのチームとワークロードの例です。 チーム A は、ボリューム 1–4（ Amazon EBS io2 Block Express ボリューム ）で重要なアプリケーションを実行し、1 時間ごとのバックアップが必要です。 チーム B は、ボリューム 5–7（Amazon EBS io2 Block Express ボリューム）で重要なアプリケーションを実行し、データボリュームのみ 1 時間ごとのバックアップが必要です。 チーム B は、ボリューム 8（ Amazon EBS gp3 ボリューム ）に一時データを保存し、バックアップは不要です。 チーム C は、ボリューム 9–10（Amazon EBS io1 ボリューム、io2 Block Express ボリューム）で重要なアプリケーションを実行し、データボリュームのみ 1 時間ごとのバックアップが必要です。 個別ユーザーはボリューム 11–14（Amazon EBS io2 Block Express ボリューム）を作成し、テスト目的で使用する場合を除き、組織の 1 時間ごとのバックアップ要件を遵守する必要があります。 また、各チームは独自のメカニズムでデータをバックアップしています: チーム A は、ボリュームのタグに基づいてバックアップするリソースを決定するサードパーティツールを使用しています。 チーム B は、Amazon Data Lifecycle Manager のカスタムポリシーを使用して、ボリュームのタグに基づいてバックアップするリソースを決定しています。 チーム C は、ボリュームのタグに基づいてバックアップするリソースを決定するカスタムスクリプトを使用しています。 個別ユーザーは自由にバックアップのメカニズムを選択しています。 アプリケーションをリストアするための最近のバックアップが見つからないという理由で、ボブは何度かユーザーから連絡を受けました。手動で調査した結果、ボブは以下の原因を特定しました: チーム A が誤ってボリューム 1 のタグを削除し、バックアップツールがボリューム 1 のバックアップを停止しました。 チーム B がボリューム 7 のタグを変更したため、Amazon Data Lifecycle Manager のカスタムポリシーがボリューム 7 のバックアップを停止しました。 チーム C のカスタムスクリプトにソフトウェアの欠陥があり、スナップショットが作成されなくなりました。 個別ユーザーは、タグ（production:environment）を持つすべてのボリュームを保護するようにチーム B のポリシーが設定されていると思い込み、ボリュームにタグ（production:environment）を付けていました。しかし、実際にはチーム B のポリシーは別のタグ（prod:environment）を持つボリュームを対象としていました。このため、個別ユーザーのボリュームはまったくバックアップされていませんでした。 ソリューションの概要 アリスもボブも、Amazon Data Lifecycle Manager のデフォルトポリシーを使うことで、それぞれのニーズを満たすことができます: シナリオ 1: 一人のユーザーがすべてのリソースをバックアップする簡単な方法を求めている アリスは、Amazon EC2 のダッシュボードから数回クリックするだけで、Amazon Data Lifecycle Manager のデフォルトポリシーを有効にすることができます（ウォークスルーの Step 1）。アリスはまた、アカウント内のすべての Amazon EBS ボリュームを監視して、過去 1 日以内に作成されたバックアップがあることを確認できます（Step 6）。 シナリオ 2: ストレージ管理者は、重要なワークロードがすべてバックアップされていることを確認したい ボブは Amazon Data Lifecycle Manager のデフォルトポリシーを簡単に有効にして、様々なチームが使用するすべての重要なアプリケーションが日次バックアップされるように設定することができます。アカウント内の一部のユーザーは、1 時間ごとにバックアップを作成するように独自のバックアップメカニズムを設定しますが、ボブは重要なボリュームが少なくとも日次バックアップされるように、デフォルトポリシーを使用することができます。デフォルトポリシーを設定する際（Step 4）、ボブは除外パラメータを設定し、重要なアプリケーションを実行するボリュームのみがデフォルトポリシーの対象となるようにします。 お客様は除外パラメータを使用して、デフォルトポリシーによる定期的なバックアップから除外したい Amazon EBS ボリュームと Amazon EC2 インスタンスの属性を定義できます。リソースが除外パラメータの少なくとも 1 つに一致する場合、デフォルトポリシーはそのリソースのバックアップを作成しません。 さまざまなチームやユーザーの要件に基づくと、ボブのデフォルトポリシーは、すべてのブートボリュームと Amazon EBS io2 以外のボリュームタイプ（gp3、gp2、io1、sc1、st1、standard/magnetic）を除外すべきです。また、タグ（temp:storage）が設定されたテスト目的のボリュームも除外する必要があります。デフォルトポリシーを作成すると、すべてのチームとユーザーにとって重要なワークロードを実行するすべてのボリュームが、デフォルトポリシーの対象となります（以下の図で示す範囲）。各チームのバックアップメカニズムが計画通りに動作してボリュームのバックアップを 1 時間ごとに作成している場合、デフォルトポリシーは追加のスナップショットを作成しません。ただし、何らかの問題が発生し、ボリュームに過去 1 日分のスナップショットが存在しない場合は、デフォルトポリシーがそのボリュームのスナップショットを作成します。 前提条件 このウォークスルーでは、定期的にバックアップする必要がある Amazon EC2 インスタンスと Amazon EBS ボリュームがアカウントに存在することを想定します。デフォルトポリシーを適用したリソースを作成する際に、これらのリソースにタグを設定する必要はありません。 ウォークスルー Amazon Data Lifecycle Manager のデフォルトポリシーを作成および管理するには、いくつかの方法があります。また、Amazon Data Lifecycle Manager のデフォルトポリシーとカスタムポリシーを Amazon EC2 コンソールに統合し、Amazon EC2 インスタンスの新規起動や Amazon EBS ボリュームの新規作成時にポリシーが有効になっているかどうかを確認できるようになりました。この記事では、デフォルトポリシーのすべてのタッチポイントについて説明します: Amazon EC2 ダッシュボードを使用したデフォルトポリシーの確認 デフォルトポリシーの作成と設定 デフォルトポリシーとカスタムポリシーの区別 Amazon EBS ボリュームの作成時におけるデフォルトポリシーの設定の確認 Amazon EC2 インスタンス起動時におけるデフォルトポリシーの設定の確認 Amazon EBS ボリュームと最近のスナップショットバックアップの監視 Step 1: Amazon EC2 ダッシュボードを使用したデフォルトポリシーの確認 1. Amazon EC2 のダッシュボードに移動し、アカウントの属性の Data protection and security に進みます。 2. Data protection and security タブでは、EBS スナップショットおよび/または EBS-backed AMI に対して Amazon Data Lifecycle Manager のデフォルトポリシー が有効になっているかどうかを確認できます。作成するリソースに対応する Create policy を選択します。 この AWS リージョン のアカウントにどちらか一方でも作成されている場合、ダッシュボードにはポリシーの作成頻度と保持期間も表示されます。 Step 2: デフォルトポリシーの作成と設定 Amazon EC2 ダッシュボードから Create policy を選択すると、Amazon Data Lifecycle Manager ポリシーの作成ページに移動します。 1. ポリシーの説明 を入力し、 AWS Identity and Access Management（IAM） ロールを選択することで、デフォルトポリシーの設定を開始できます。どのロールを使用すべきかわからない場合は、 デフォルトロール を選択することをお勧めします。正しい IAM 権限を持たない他のロールを選択した場合、ポリシーは エラー状態 になります。 2. 次に、 作成頻度 、 保持期間 、および 除外パラメータ を設定する必要があります。 作成頻度 は、ポリシーの対象となるすべての Amazon EBS ボリュームのスナップショットバックアップを作成する間隔を定義します。同じ頻度（またはそれ以上の頻度）でスナップショットを作成する他のバックアップメカニズムがある場合、デフォルトポリシーはそれらのボリュームに対してスナップショットを作成しません。ただし、他のメカニズムがスナップショットを作成する頻度が低い場合、または他のメカニズムが対象ボリュームのスナップショットの作成を停止するような問題が発生した場合は、デフォルトポリシーが介入し、作成頻度の基準を満たすようにスナップショットが作成されます。 保持期間 は、デフォルトポリシーで作成されたスナップショットが保持される期間を定義します。 除外パラメータ を定義して、デフォルトポリシーの対象から除くボリュームの属性を設定する必要があります。 ソリューションのセクションにあるボブのユースケースに基づくと、デフォルトポリシーは次のスナップショットを作成しません: ブートボリューム gp3、gp2、io1、sc1、st1、standard/magnetic のボリュームタイプ タグ（temp:storage）を設定したボリューム チームまたはユーザーが前述の除外する基準を満たさないボリュームを作成した場合、デフォルトポリシーはそのボリュームに日次バックアップがあることを確認します。 3. 次に、デフォルトポリシーの 詳細設定 を行います。ここでは、 削除を最新の AMI まで延長 を有効にしています。このパラメータを有効にしない場合、Amazon Data Lifecycle Manager のデフォルトポリシーは、ソースボリュームが削除されたときに最後のスナップショットを削除しません。また、デフォルトポリシーが無効化/削除されたとき、またはエラー状態に遷移したときでも、デフォルトポリシーによって作成されたスナップショットは削除されません。ソースボリュームが削除されたときや、デフォルトポリシーが削除/無効化やエラー状態に遷移したときに、（保持期間に基づいて）デフォルトポリシーが最終スナップショットを削除する場合は、 削除を最新の AMI まで延長 を有効にする必要があります。 4. 満足のいく設定ができたら、 デフォルトポリシーを作成 を選択し、設定を確認することで、デフォルトポリシーの作成は完了です! 同じ手順で、EBS-backed AMI 用のデフォルトポリシーも作成できます。このポリシーは、ポリシーの 除外パラメータ で定義したものを除いて、アカウント/リージョン内のすべての Amazon EC2 インスタンスを対象とします。 5. お客様は、 AWS Command Line Interface（AWS CLI） を一回使用するだけで、同じデフォルトポリシーを簡単に作成することもできます。 $ aws dlm create-lifecycle-policy \ --state ENABLED \ --description "EBS snapshot policy" \ --execution-role-arn “role_arn” \ --default-policy VOLUME \ --create-interval 1 \ --retain-interval 7 \ --extend-deletion \ --exclusions ExcludeBootVolumes=true, ExcludeTags=[{Key=temp,Value=storage}], ExcludeVolumeTypes="standard|gp2|gp3|io1| st1|sc1" Step 3: デフォルトポリシーとカスタムポリシーの区別 Amazon EC2 コンソールの Amazon Data Lifecycle Manager ページから、Amazon Data Lifecycle Manager のデフォルトポリシーを作成することもできます。 1. Amazon EC2 のコンソールで Lifecycle Manager を選択してください。 2. デフォルトポリシー のラジオボタンを選択します。または、タグに基づいて対象とするリソースを選択できる カスタムポリシー を作成することもできます。 3. EBS スナップショットポリシー または EBS-backed AMI ポリシー のいずれかを選択します。次に、Step 2 の指示に従ってポリシーを設定します。 4. 同じアカウントの同じ AWS リージョン同じタイプのデフォルトポリシーを既に作成している場合、別のデフォルトポリシーを作成することはできず、タイルはグレーアウトされます。必要に応じて、 デフォルトポリシーを表示 して既存のデフォルトポリシーの変更ができます。 5. Amazon Data Lifecycle Manager のメイン画面では、デフォルトポリシーの表示、監視、フィルタリング、ソートも可能です。 Step 4: Amazon EBS ボリュームの作成時におけるデフォルトポリシーの設定の確認 Amazon EC2 コンソールを使用してボリュームを作成する際に、Amazon Data Lifecycle Manager のデフォルトおよびカスタムポリシーが Amazon EBS ボリュームをバックアップするか確認できます。 1. Amazon EC2 のコンソールで Elastic Block Store の ボリューム を選択し、 ボリュームの作成 を選択します。 2. ページの一番下までスクロールし、 バックアップの概要 の更新アイコンを選択します。 3. 同じアカウントの同じ AWS リージョンに対して EBS スナップショットのデフォルトポリシーが設定されている場合、そのポリシーがそのボリュームをバックアップするかどうかを確認できます。また、Amazon Data Lifecycle Manager のカスタムポリシーがこのボリュームを（付与されたタグに基づいて）バックアップの対象にしているかどうかも確認できます。 4. ボリュームをデフォルトポリシーの対象にしない場合は、ボリュームの属性が 除外パラメータ の少なくとも 1 つに一致することを確認する必要があります。詳細を表示を拡張し、 除外パラメータを表示 を選択できます。この例では、タグ（temp:storage）を追加し、更新アイコンを再度選択すると、デフォルトポリシーがこのボリュームを対象としていないことがわかります。 Step 5: Amazon EC2 インスタンス起動時におけるデフォルトポリシーの設定の確認 Amazon EC2 コンソールでインスタンスを起動したときに、Amazon Data Lifecycle Manager のデフォルトポリシーとカスタムポリシーが Amazon EC2 インスタンスをバックアップするかどうかを確認できます。 1. Amazon EC2 コンソールで インスタンス を選択し、 インスタンスを起動 へと進みます。 2. EBS-backed AMI のデフォルトポリシーがタグに基づいてインスタンスを除外するように設定されていて、現在のボリュームを除外したい場合は、ここでタグを追加し、それが インスタンス に適用されることを確認する必要があります。 3. ページの ストレージを設定 までスクロールダウンし、更新アイコンを選択します。 4. 同じアカウントの同じ AWS リージョンに EBS-backed AMI のデフォルトポリシーが設定されている場合、インスタンスが作成されると、ポリシーがインスタンスをバックアップするかどうかを確認できます。また、Amazon Data Lifecycle Manager のカスタムポリシーが（付与されたタグに基づいて）このインスタンスをバックアップするかも確認できます。 Step 6: Amazon EBS ボリュームと最近のスナップショットバックアップの監視 Amazon Data Lifecycle Manager を使用しているかどうかに関係なく、Amazon EC2 コンソールの Amazon EBS ボリュームのページを使用して、過去 24 時間に作成されたスナップショットがあるボリュームの数を確認できます。 1. Amazon EC2 コンソールで ボリューム を選択します。 2. 検索バー を使用して、ボリュームの属性に基づいてフィルタリングすることもできます。複数のボリュームを選択すると、 セレクション概要 タブに移動して、選択したボリュームの数と最近スナップショットが取得されたボリュームの数を表示できます。 重要なワークロードを実行している 1 つまたは複数のボリュームに最近のスナップショットが表示されない場合、デフォルトポリシーを作成することで、このギャップを迅速に解決できます。 クリーンアップ 前の手順で作成したスナップショットを削除して、ストレージ料金が発生しないようにします。 スナップショット のページに移動し、ポリシーによって作成されたすべてのスナップショットを検索し、すべてのスナップショットを選択し、 アクション の後に スナップショットの削除 を選択します。 同様に、Amazon Data Lifecycle Manager のデフォルトポリシーを削除して、今後そのポリシーによってスナップショットが作成されないようにする必要があります。まず、デフォルトポリシーの削除を 最新の AMI まで延長 を有効にして、ポリシーが削除されても、ポリシーによって既に作成されたスナップショットが削除されるようにします。次に、Amazon Data Lifecycle Manager の画面に移動してポリシーを選択し、 アクション を選択して ライフサイクルポリシーを削除 を選択すると、ポリシーを削除できます。 まとめ この記事では、AWS リソースのアカウント所有者がアカウント内のすべてのボリュームが定期的にバックアップされていることを簡単に確認できるように、Amazon Data Lifecycle Manager のデフォルトポリシーを作成することについて説明しました。デフォルトポリシーを使用することで、ストレージ管理者は自分が管理するアカウントを使用するチームやユーザーの要件を満たすことができます。ストレージ管理者は、チームやユーザー独自のバックアップメカニズムが失敗した場合でも、アカウント内のすべての重要なワークロードが定期的にバックアップされているという保証を得ることができます。何よりも、デフォルトポリシーでは、最近のバックアップがすでに存在する場合、追加のバックアップを作成しないため、バックアップの重複による追加コストと管理オーバーヘッドを排除することができます。 最後の提案として、ご自身の環境でこの機能を試してみることをお勧めします。また、この機能の詳細については、AWS の ドキュメント をご覧ください。 この記事をご覧いただきありがとうございます。 <!-- '"` --> TAGS: Amazon Data Lifecycle Manager (Amazon DLM) , Amazon EBS Snapshots , Amazon Elastic Block Store (Amazon EBS) , Amazon Elastic Compute Cloud (Amazon EC2) , AWS Cloud Storage Daniel Rabinovich Daniel Rabinovich は Amazon Elastic Block Store（Amazon EBS）の Software Development Engineer です。Amazon Data Lifecycle Manager を含む EBS スナップショット製品の開発に 9 年以上の経験があります。 Vyassa Baratham Vyassa Baratham は Amazon Elastic Block Store（Amazon EBS）の Software Development Engineer です。複雑な問題に対する堅牢で持続可能なソリューションを構築することが好きです。趣味は料理、ランニング、スキー、愛猫ポピーと遊ぶことです。 Mahesh Goud Paruchuri Mahesh Goud Paruchuri は Amazon Elastic Block Store（Amazon EBS）の Software Development Manager です。大規模システムや機能の設計、実装、提供において 10 年以上の経験があります。趣味はワークアウトと読書です。

このブログは、 Amazon DynamoDB zero-ETL integration with Amazon OpenSearch Service is now available を翻訳したものです。 本日、 Amazon OpenSearch Service と Amazon DynamoDB zero-ETL の統合 が一般公開されたことをお知らせします。これにより、カスタムコードやインフラストラクチャを必要とせずに、DynamoDB データを自動的に複製および変換して検索を実行できます。この zero-ETL 統合 により、データパイプラインアーキテクチャのコードの記述、データの同期、頻繁なアプリケーション変更によるコードの更新に伴うオペレーション上の負担とコストが軽減され、アプリケーションに集中できるようになります。 この zero-ETL 統合により、 Amazon DynamoDB を利用するお客様は、全文検索、あいまい検索、オートコンプリート、機械学習 (ML) 用のベクトル検索など、 Amazon OpenSearch Service の強力な検索機能を使用して、ユーザーエンゲージメントを高め、アプリケーションに対する満足度を向上させる新しいエクスペリエンスを提供できるようになりました。 この zero-ETL&nbsp;統合では、 Amazon OpenSearch Ingestion を使用して、Amazon DynamoDB&nbsp;と Amazon OpenSearch Serviceの間でデータを同期します。データを同期する必要がある DynamoDB テーブルを選択すると、Amazon OpenSearch Ingestation は、データが使用可能になってから数秒以内に Amazon OpenSearch マネージドクラスターまたはサーバーレスコレクションにデータを同期します。 また、インデックスマッピングテンプレートを指定して、Amazon DynamoDB フィールドが Amazon OpenSearch Service インデックスの正しいフィールドにマップされるようにすることもできます。また、複数の DynamoDB テーブルのデータを 1 つの Amazon OpenSearch Service マネージドクラスターまたはサーバーレスコレクションに同期して、複数のアプリケーションにわたる総合的なインサイトを得ることができます。 zero-ETL 統合を開始する 数回のクリックで、DynamoDB から OpenSearch Service にデータを同期できます。DynamoDB と OpenSearch Service 間の統合を作成するには、 DynamoDB コンソール の左ペインにある Integrations メニューと、データを同期したい DynamoDB テーブルを選択します。 ポイントインタイムリカバリ (PITR) と DynamoDB Streams 機能を有効にする必要があります。この機能により、テーブル内の項目レベルの変更をキャプチャし、その変更をストリームにプッシュできます。 Exports and streams タブで Turn on を選択してPITR と DynamoDB Streams を有効にします。 PITRとDynamoDB Streamsをオンにしたら、 Create&nbsp; を選択して、OpenSearch Service の管理ドメインにデータをレプリケートするOpenSearch Ingestion パイプラインをアカウントに設定します。 最初のステップでは、一意のパイプライン名を入力し、現在の取り込みワークロードに基づいてパイプラインを自動的にスケーリングするように、パイプラインの容量とコンピューティングリソースを設定します。 これで、定義済みのパイプラインの設定を YAML ファイル形式で設定できるようになります。リソースを参照して情報を検索し、パイプラインの設定を構築するための情報を貼り付けることができます。このパイプラインは、DynamoDB の設定をする source 部分と OpenSearch Service の設定をする sink 部分を組み合わせたものです。 DynamoDB テーブルからデータを読み取り、OpenSearch ドメインに書き込むために必要な権限を持つ複数の IAM ロール ( sts_role_arn ) を設定する必要があります。その後、OpenSearch Ingestion パイプラインがこのロールを引き受け、データをソースからターゲットに移動する際に常に適切なセキュリティが維持されるようにします。詳細については、AWS ドキュメントの Amazon OpenSearch Ingestion のロールとユーザーの設定 を参照してください。 必要な値をすべて入力したら、パイプライン構成を検証して構成が有効であることを確認できます。詳細については、AWS ドキュメントの Amazon OpenSearch Ingestion パイプラインの作成 を参照してください。 数分で OpenSearch Ingestion パイプラインがセットアップされると、DynamoDB テーブルへの統合が完了したことが確認できます。 これで、OpenSearch Dashboards で同期された項目を検索できるようになりました。 知っておくべき事項 この機能について知っておくべきことが数点あります。 カスタムスキーマ –&nbsp;Amazon DynamoDB から OpenSearch Service にデータを書き込む際に、OpenSearch Ingestion が使用するインデックスマッピングとともに、カスタムデータスキーマを指定できます。このエクスペリエンスは Amazon DynamoDB 内のコンソールに追加され、OpenSearch Service で作成されるインデックスのフォーマットを完全に制御できます。 料金 –&nbsp;既存の基盤となるコンポーネントのコストを除いて、この機能を使用する際の追加コストは発生しません。Amazon OpenSearch Ingestion では、Amazon DynamoDB と Amazon OpenSearch Service 間でデータを複製するために使用される OpenSearch Compute Unit (OCU) が課金されることに注意してください。さらに、この機能は変更データキャプチャ (CDC) に Amazon DynamoDB ストリームを使用するため、Amazon DynamoDB ストリームの標準コストが発生します。 モニタリング –&nbsp;パイプラインの状態は、DynamoDB コンソールで統合のステータスを確認するか、OpenSearch Ingestion ダッシュボードを使用してモニタリングできます。さらに、 Amazon CloudWatch を使用してリアルタイムのメトリクスとログを確認し、ユーザー定義のしきい値に違反した場合にアラートを発するように設定できます。 一般利用可能に Amazon DynamoDB と Amazon OpenSearch Service の zero-ETL&nbsp;統合は、現在 OpenSearch Ingestion が利用可能なすべての AWS リージョンで一般利用可能になりました。 詳細については、AWS ドキュメントの &nbsp;DynamoDB zero-ETL integration with Amazon OpenSearch Service&nbsp; と　 Using an OpenSearch Ingestion pipeline with Amazon DynamoDB &nbsp;を参照してください。 お試しいただき、 AWS re:Post for Amazon OpenSearch Service 、または通常の AWS サポート窓口までフィードバックをお送りください。 — Channy Channy Yun Channy Yun は AWS の Principal Developer Advocate であり、開発者が最新の AWS サービスで最新のアプリケーションを構築できるよう支援することに情熱を注いでいます。根っからの開発者でありブロガーでもある彼は、コミュニティ主導のテクノロジー学習と共有が大好きで、開発者はグローバルな AWS ユーザーグループに参加するようになりました。彼の主なトピックは、オープンソース、コンテナ、ストレージ、ネットワークとセキュリティ、IoTです。ツイッターで @channyun で彼をフォローしてください。 翻訳は Solutions Architect 深見が担当しました。

はじめに 私たちは、いつでも国や世界を飛び回れることが簡単で当たり前のことと思っています。しかし、航空会社は、想像以上に頻繁に、予期せぬ気象現象、山火事、地政学的事象、物流問題、その他、通常業務に影響を与える外部要因などの課題に直面しています。このような事態は運航の乱れにつながり、フライトの遅延や欠航を引き起こし、乗務員のスケジューリングに支障をきたし、結果として収益や旅行者の信頼を失うことになります。 厳格なビジネスプロセス、老朽化したインフラ技術、航空運航をサポートするソフトウエア機能不足によって、イレギュラーなオペレーションが悪化する可能性があります。これらの事象をすべて解決することは不可能ですが、航空会社は効果的に管理することができます。 このブログでは、航空会社が直面する運行中断の可能性を増大させる特有の課題のいくつかに焦点を当てます。復旧時間を改善するための Amazon Web Services (AWS) のソリューションガイダンスを提案し、航空会社が技術スタックの全体的な回復力を高める方法を取り上げます。 課題 技術基盤の老朽化： 今日の航空業界の業務の大部分を支える老朽化したインフラ技術には単一障害点が存在します。ルーターの故障、ネットワークケーブルの切断、ストレージサブシステムの故障のような物理層における単純な問題は、技術チームが故障したコンポーネントの修理に奔走する間、数時間に及ぶグランドストップを引き起こしています。 複数の アベイラビリティゾーン や複数のリージョンを活用した AWSのWell-Architected 設計と組み合わせることで、 AWS グローバルインフラストラクチャ はハードウェア障害に対する耐障害性を提供し、業界の最新のハードウェアイノベーションをすぐに利用できます。また、需要に合わせて使用量を増減できるため、ピーク負荷を予測してサイズを調整する必要がなくなります。オンプレミスのデータセンターからAWSにワークロードを移行するだけで、 IDC によると、お客様は計画外の停止を69%削減できると言われています 。 ソフトウエアシステムの不備： ソフトウェア機能不足は、ハードウェアの障害以上に航空会社のオペレーションに影響を与える可能性があります。航空会社が使用する、新しいフライトスケジュールの生成、航空機の割り当ての決定、乗客の再収容、客室乗務員の割り当てをおこなうニッチでレガシーなソフトウエアシステムの多くは、数十年前のものであり、航空会社が今日直面している大規模な障害に対応できるようには構築されていません。 航空会社はこのような課題を認識していますが、利益率の低い厳しい市場で競争力を維持するために新たな機会を追求しながら、すべての課題に対処するための十分な予算も人材も持ち合わせていません。この技術的負債に対処するための予算を確保する1つの方法は、ワークロードをクラウドに移行してモダナイズすることです。すでに述べた可用性の向上に加え、AWSに移行した顧客は、 5年間の運用コストを平均50％削減 し、 ITインフラチームの効率を平均47％向上 させています。これにより、新たな収益を生み出すプロジェクトと技術的負債の解消のため投資できます。 AWSでは、移行方法に柔軟性があります。既存のワークロードを単純に リホスト（リフト・アンド・シフト） して、すぐに回復力とパフォーマンスを向上させることもできます。また、クラウドネイティブサービスを活用して、一からリファクタリングと アプリケーションモダナイゼーション をして、さらなる拡張性とコスト削減を実現することもできます。 AWSには、AWS上に構築された業界固有のソフトウェアを提供するテクノロジー企業を含む、 AWS トラベル・サービスコンピテンシーパートナー の豊富なネットワークがあります。ポートフォリオ分析を実施し、固有のワークロードに最適な移行アプローチの決定するのを支援するコンサルタント会社もあります。 手作業によるプロセスは障害からの回復を遅らせる： 障害からの復旧に関わる多くのプロセスは、ほとんど手作業であったり、顧客と航空会社の担当者の間で双方向のコミュニケーションが必要になったりします。そのため、急な人員増強が必要となり、問題解決プロセスが遅れ、顧客体験の低下につながります。 AWSのサービスとパートナー製品は、高度な自動化を実現するのに役立ちます。航空会社は、 AWS Step Functions や Amazon Textract といったサーバーレスやローコードのサービスを活用し、手動のワークフローやプロセスを自動化できます。新型コロナウィルスの期間中、ユナイテッド航空のデジタルチームは、旅行書類を検証する ソリューションを AWS 上 に構築しました。このソリューションは、400万の乗客のためにアップロードされた新型コロナウィルス検査フォームの3分の2以上を自動的に検証し、この要件を満たすために必要な手作業の労力とコストを削減しました。 スタッフや顧客とのコミュニケーション： フライトの遅延や欠航が発生した場合、顧客が最初に取る行動は、航空会社に電話し代替便を予約します。多くの顧客が影響を受ける大規模なイベントの際、従来のコールセンター・テクノロジーでは、短期間で増加する問い合わせに十分に対応できるようにスケールできません。これでは完全なコミュニケーション不全となり、顧客体験を著しく低下させてしまいます。社内では、客室乗務員が空席状況を報告し、割り当てを取得するために電話をかけようとすると、顧客に対応する代わりに何時間も待たされることになり、さらなる障害につながってしまいます。 業務が中断しても、顧客とのやり取りを適切に処理することで、顧客満足度（CSAT）やネットプロモータースコア（NPS）を向上させることができます。 Amazon Connect を使えば、数分でコンタクトセンターを立ち上げることができ、数万人のエージェントで数百万人の顧客をサポートできる規模にスケールできます。航空会社は、需要に合わせてスケールできない融通のきかないレガシーコンタクトセンター技術の代替として Amazon Connect を使用しています。Amazon Connect を使用すると、対話型 IVRでコールをルーティングし、 Amazon Lex を搭載したチャットボットで複雑度の低いケースを処理し、顧客からの電話に対応するエージェントにステップバイステップのガイドを提供し、ほぼリアルタイムの会話分析を実行して、顧客のアイデンティティと感情を判断することができます。 デルタ航空 がどのように Amazon Connect を採用し、卓越したカスタマーエクスペリエンスを提供し、エージェントとのやり取りを変革し、競争力を維持したかをご覧ください。 データへのアクセスの欠如： 航空会社は、障害に効果的に対処するために、統合された一連のデータ・ドメインに素早くアクセスする必要があります。しかし、復旧に役立つ重要な情報は、組織の境界や技術的な制約により、サイロ化されることがよくあります。その結果、障害を予測したり、障害の影響やコストを定量化したり、障害発生時に迅速に行動できなくなります。障害発生時には、以下のシステムからのデータを統合し、シームレスな影響の把握と復旧を行う必要があります。 予約システム 出発管制システム（DCS）と空港業務 IROPS（Irregular Operations）ツール 空港オペレーション DB（AODB） スケジュール バゲージ・ハンドリング・システム（BHS）とトラッキング・システム 払い戻しおよび補償管理システム CRM およびロイヤルティシステム 航空会社は、すべてのデータを一元的に把握する必要性を認識し、その多くが AWS を利用したデータレイクとクラウドデータウェアハウス機能を構築しています。AWSは、業界で最も広範かつ深い 分析 と 人工知能/機械学習（AI/ML） 機能を提供し、お客様がデータをコントロールし、 最新のデータ戦略 を用いて記述的および予測的分析の両方で深いインサイトを得られるようにします。当社の業界専門家は、Amazon S3 を使用して、最新の無限にスケーラブルなデータレイクや高速で柔軟なレポートを作成するための Amazon Redshift や Amazon QuickSight などのサービスを使用して、航空会社に特化した分析ソリューションを構築しました。これらのサービスを組み合わせることで、実用的な洞察が得られ、航空会社を見直しできるデータ主導の意思決定が可能になります。 まとめ／結論 冬の嵐や山火事など、航空会社の運航に影響を与える出来事の多くは防ぐことができませんが、AWSは復旧までの時間を短縮し、悪条件に対する全体的な回復力を高めることができる 業界固有のソリューション を数多く提供しています。運用の回復力と分析のニーズについて AWS のトラベル＆ホスピタリティの専門家に お問い合わ せください。 さらに読む How machine learning is transforming airline operations Korean Airlines on AWS Transforming Travel and Hospitality Customer Service Using Amazon Connect Mike Gomez Mike Gomezは、AWSエンタープライズサポートのエンタープライズサポートマネージャーです。信頼性エンジニアリングとITオペレーションに情熱を注いでいます。トラベル＆ホスピタリティ、メディア＆エンターテイメント、銀行での経験を生かし、業界横断的なイノベーションを通じてお客様のビジネス目標達成を支援することに注力しています。 Paul Ramsey Paul Ramsey は、テキサス州ダラスを拠点とするエンタープライズアカウントのシニアAWSソリューションアーキテクトです。彼の興味と経歴は、AI/ML、アナリティクス、サーバーレステクノロジー、コンテナなど。仕事以外では、ギターやピアノを弾いたり、Amazon Primeで新しい番組を夢中で見たり、チェスをしたりしています。 Robin Kanthareuben Robin Kanthareuben は、旅行、交通、ホスピタリティ分野で20年以上の経験を持つベテランのテクノロジー・リーダーです。大手航空会社、空港、航空連合、ホテルチェーン、旅行テクノロジープロバイダーとテクノロジー戦略やアーキテクチャのコンサルティングに携わっています。現在はドバイを拠点とする Amazon Web Services に在籍。現在の職務では、旅行業界のビジネス＆テクノロジーエグゼクティブのパートナーとして、クラウドやデジタル技術を活用してビジネス目標を達成し、組織を変革してその分野のリーダーとなり、最高の顧客体験を提供できるよう支援しています。

私が空港の技術分野に携わっていることを話すと、多くの人から、最近の空港での遅延や障害は、テクノロジーで解決できるという反応が返ってきます。昨年は空港で問題が発生したにもかかわらず（主に手荷物取り扱いと保安検査のスタッフ不足が原因）、ほとんどの人は、高度なロボット工学や自律機械を必要とする例に飛びつきません。最も多い不満はデータに関する以下のようなものがあります。なぜ航空会社は私の荷物がどこにあるか知らないのか？飛行機が何時間も飛行しているときに、どうして空港は私のフライトの早期到着に備えられなかったのか？今日、追加の旅客がいるということをどうして知らなかったのか？航空会社は空港に伝えなかったのか？ 空港と航空会社はデータの有効活用を望んでいる それは旅行者だけではありません。空港や航空会社のビジネやテクノロジーリーダーも同じことを言っています。彼らは、運営上の問題を解決するためのデータ不足を嘆いており、空港を利用する旅客の好みをもっと知りたいと考えており、ビジネスパートナーと共に空港内のさまざまなシステムの部門と連携したいと考えています。また、外部プロバイダーから入手できる気象情報や交通情報などのデータを活用したいと考えています。 一般にはあまり知られていませんが、空港は、他の空港、航空会社、グランドハンドリングエージェント（チェックイン、手荷物の積み込み、航空機運航管理など、空港内で多くの航空会社にサービスを提供する会社）とデータを共有し、業務プロセスを改善することに大成功しています。例えば、 Airport collaborative decision-making (A-CDM) は、 空港の遅延を10％削減し、CO2排出量を7.7％削減 しました。 空港はこれをさらに進めたいと考えています。Amazon Web Services (AWS) を利用して予防保全や機内食の需要予測を行っている大韓航空やライアンエアーのような航空会社で、データがどのように業界を変革するか、良い例は、ライアンエアーの Panini Predictor です。正確な予測、パーソナライゼーション、すべての関係者間での簡単なデータ共有によって、空港業務と旅客体験が向上することを想像できます。国際空港評議会（ACI）が、最近、「 空港データの共有とコラボレーションは、旅客の満足度を向上させる鍵である 」と述べたことは驚くべきことではありません。 空港はデータプラットフォームを構築している フランスのニース・コート・ダジュールをはじめ、多くの空港が最近 AWS 上にデータプラットフォームを構築しています。一般的に複雑なビジネスルールを持つ高度に構造化されたデータベースである空港運用データベース（またはAODB）とは異なり、データプラットフォームは、空港のシステム、航空会社、サードパーティ全体からさまざまな種類の情報、理解、視覚化、予測、共有するためのより柔軟な方法です。 シンシナティ空港 は、Enterprise Awareness &amp; Situational Exceptions（EASE）と呼ばれる 予測分析と事前通知 のためにデータを使用しています。EASE は、 Amazon Relational Database Service (Amazon RDS) 、マネージドサービス群、 AWS Lambda 、イベント駆動型のコンピューティングサービスのような AWS のサービスを使用して、企業内各所から構造化データと非構造化データを収集しています。これにより、かなりバラバラなデータセットであっても、動的な意思決定を改善できます。また、空港は気象や現地の交通状況も監視しているため、運航計画を調整したり、旅客に注意を促すこともできます。 シンガポールの チャンギ空港 は、データを活用してコラボレーションとイノベーションを向上させた素晴らしい例です。 AWSのトラベル＆ホスピタリティ・パートナー である アクセンチュア と協力し、チャンギ空港は DIVA イノベーション・ラボの基盤としてデータ・プラットフォームを構築しました。その中には、旅客により良い情報を提供する新しいコンシェルジュ・アプリや、Where-To-Clean アプリは、空港内で利用者の多かった場所を優先的に清掃するようにスタッフに伝えます。 空港の手荷物処理システムの世界的リーダーである シーメンス・ロジスティクス も、あらゆる種類の空港運営データを取り込み、分析し、視覚化するために、AWS 上に航空データハブを構築しました。例えば、同社の Baggage360 システムは、複数の情報ソースを使用して手荷物データを分析し、手荷物の流れを予測します。シーメンス・ロジスティクスの航空データソリューション担当ディレクター Stephan Poser 氏は「手荷物の流れを監視し、手荷物処理時間を予測し、リスクのある乗り継ぎを特定し、手荷物が重要な工程に入るタイミングを予測できます。」「到着ベルトで旅客がいつバックを見つけられるか予測できます。」と語っています。 データプラットフォームをオンプレミスで運用している空港の中には、ニーズが高まるにつれ、拡張性や新サービスの追加に限界があることに気づいているところもあります。例えば、AWSパートナーの Wipro は、最近、トロント・ピアソン国際空港のデータプラットフォームをオンプレミスのシステムからAWSに移行し、拡張性と俊敏性を活用し、人工知能（AI）、機械学習（ML）、ほぼリアルタイムのデータ取り込みなどの新機能を追加しました。Wipro・カナダのゼネラルマネージャー Anudeep Kambhampati 氏は「AWS 上の新しい Databricks レイクハウスプラットフォームは、さまざまなソースからほぼリアルタイムのビジネスインサイトを導き出し、継続的なイノベーションを推進するのに役立ちます。」と語っています。 空港がなぜ最近になってデータプラットフォームの構築に乗り出したのか、私は興味がありました。このテクノロジーは以前から存在していたにもかかわらず、なぜ今なのだろうか？この疑問に答えるため、ヨーロッパで 30 以上の空港でデータによる業務改善を支援してきた Azinq 社のマネージング・ディレクター Chris Taylor 氏に話を聞きました。「我々の顧客は、AWSが提供するインフラとデータサービスを活用するために、急速にクラウドベースのデータプラットフォームに移行しています。空港は以前から、旅客やステークホルダーのエンゲージメントを理解し、改善するためのデータの価値を認識していましたが、これまではコストや技術的な障壁のために、空港がデータプラットフォームを構築することは困難でした。AWS 上の私たちの Airport Hive プラットフォームは、空港が運営に関するインサイトを得ることをはるかに容易にし、小さな変化が財政的にも旅客体験にも大きな影響を与えることを可視化します。AWS のスケーラビリティと弾力性により、お客様はオンプレミスの実装にかかるコストや手間を回避し、長期的な成長余力を得ることができます。」 データプラットフォームは、非常に特殊な問題の解決に役立ちます。例えば、米国のある主要空港では、タクシーが一時駐車場で待機しているという問題を抱えており、それは旅客の駐車スペースが減り、空港の収益が減ることを意味します。これを解決するために、空港は AWS パートナーである Slalom と契約し、過去のフライト、天候、タクシー乗客のデータを利用してデータ予測モデルを構築し、前もってタクシーの需要を予測し、必要なときだけタクシーを要請するようにしました。これにより駐車場のスペースが解放され、旅客体験が向上し、空港は運営改善により約 500 万ドルの収益を回収することができました。 データ共有の課題を解決する 空港にとっての課題のひとつは、必要なデータにアクセスすることです。空港は、空港を運営するすべての航空会社や企業から必要なデータを入手するのが難しいと言います。AWSと私たちのパートナーは、空港がこの問題を解決する支援をしています。 AWS re:Invent 2022 では、 AWS Clean Rooms を発表しました。AWS Clean Roomsは、基盤となるデータを共有したり公開したりすることなく、お客様とそのパートナーがより簡単かつセキュアにデータセットをマッチング、分析、コラボレーションできるようにします。各コラボレーターは、AWS Clean Rooms で独自のデータクリーンルームを作成し、どのデータセットで誰とコラボレートするかを選択し制限を設定します。コラボレーターは、AWS環境の外にデータのコピーを維持したり、別のプラットフォームにロードする必要はありません。顧客がクエリーを実行する際、AWS Clean Rooms はデータが存在する場所でデータを読み込み、分析ルールを適用するため、共同作業者が共有したいデータのみが共有されます。航空会社が独自のデータクリーンルームを作成し、空港は航空会社が共有したいデータ（搭乗者数など）のみにクエリを実行できます。 AWS は、空港と航空会社のコラボレーションとデータ共有を支援してきました。私たちは、旅客体験を共有することに集中することで、空港と航空会社のコラボレーションを構築する可能性があると考えています。例えば、空港に対して実践的なアプローチをとって、特定の旅客のペインポイントを理解し、その解決に必要なデータの特定を支援し、航空会社のパートナーと協力して、その旅客のペインポイントを解決するためにデータ共有をしています。 サードパーティ企業は、空港業務の改善に特化したデータフィードを提供しています。例えば、 Passur はAWS上に構築された　API を通じて、フライトポジション、フライト予測、フライトイベントデータを含むほぼリアルタイムのデータフィードを空港に提供しています。Passur の CEO である Brian Cook 氏は、「空港は、資産管理、キャパシティプランニング、航空会社とのコラボレーションを改善するために当社のデータを使用しています。」「当社のデータフィードは、空港に遅延の事前通知を提供し、空港の混乱を防ぐため、事前に運用を調整できます。」「さらに、 AWS Data Exchange は、サードパーティのデータが 1 つのデータカタログで簡単に見つけることができ、気象やフライトデータを含む何千ものデータセットがあります。」と語っています。 AWS は、イノベーションに対する独自の文化とアプローチで知られています。この方法論を取り入れ、お客様がデータによってイノベーションを起こし、ビジネス上の問題を解決できるように特別にアレンジしました。これを AWS Data-Driven Everything Program (D2E)と呼んでいます。D2E を使って何百ものお客様を支援してきました。 私たちは、 最近、豊富な人口統計学的属性と行動属性を持つ統一されたビューを構築することが困難であると感じていた旅行業界の顧客のために D2E セッションを実施しました。当社の旅行業界のお客様は、顧客をマイクロセグメント化して、サポートをパーソナライズし、ネットプロモータースコア（NPS）を 20 ％以上向上させたいと考えていました。D2E の成果は、顧客を中心とした 360 度のビューに対する野心的なビジョン、Minimum Viable Product（MVP）バージョンの構築計画、統合顧客プロファイル製品の改善を繰り返し提供するファストフォロワー機能でした。 次は何をするのか？ 空港はデータプラットフォームの構築と改善に着手できます。AWS コンサルティングパートナーとテクノロジーパートナーは、素早い構築を支援でき、実証済みのソリューションを実装できます。AWS は、安全なデータレイクプラットフォームを構築するための AWS Lake Formation 、ML を使用してビジネス成果を簡単かつ正確に予測する Amazon Forecast 、ML モデルの構築、トレーニング、デプロイを行う Amazon SageMaker など、さまざまなサービスを提供しています。AWS のすべてのお客様は、アカウントマネージャーに連絡できます。アカウントマネージャーは、導入を支援したり、ソリューションアーキテクトや対象分野の専門家を招いてガイダンスやサポートを提供できます。 また、お客様やパートナーが AWS を利用して望ましいビジネス成果を達成できるよう支援する AWS プロフェッショナルサービス チームもあります。 では、空港とデータの今後はどうなるのでしょうか？新型コロナウイルス感染症のパンデミック、最近の空港の収容能力の制約、最近のテクノロジーの進歩のため、空港がデータを共有し、ャパシティの問題を予測し、それに対処するための計画を立てたり、旅客にパーソナライズされたサービスを提供したり、ビジネスステークホルダーとのより良いコラボレーションを実現したり、データをより有意義な方法で使用することがはるかに容易になると期待しています。 私はこれから出会う人々との会話が、「なぜ空港は知らないのか」ではなく「どうして空港は知っているのか」と問われることを楽しみにしています。空港が知るだけでなく、旅客も知ることになるのは良いことでしょう。 Bob Kwik Bob Kwik は AWS のワールドワイド・エアポート・ヘッドです。 彼の役割は、お客様のクラウド導入の過程をサポートすることです。 彼は空港業界で20年以上の経験を持っています。 AWS に入社する前、Bob は大手航空テクノロジー企業で働き、販売、事業開発、技術設計、製品開発において地域および世界の指導的役割を果たしていました。 彼はヨーロッパとアメリカに住み、働いてきました。また、仕事や娯楽のために広範囲に渡って旅行してきました。 ダブリンのトリニティ・カレッジで工学の修士号を取得しています。

IBM と AWS が協力して、AWS インフラストラクチャ上で稼働するフルマネージド型の Db2 データベースエンジンである Amazon Relational Database Service (Amazon RDS) for Db2 を提供したことをお知らせします。 IBM Db2 は、IBM が開発したエンタープライズグレードのリレーショナルデータベース管理システム (RDBMS) です。強力なデータ処理機能、強固なセキュリティー・メカニズム、スケーラビリティ、多様なデータ型のサポートなど、包括的な機能セットを備えています。Db2 は、その信頼性とパフォーマンスにより、さまざまなアプリケーションのデータを効果的に管理し、データ集約型のワークロードを処理する上で、多くの企業で定評のある選択肢です。Db2 は、IBM が1970年代から行ってきたデータストレージと 構造化クエリ言語 （SQL）に関する先駆的な取り組みに端を発しています。1983 年から商用化されており、当初はメインフレーム専用でしたが、後に Linux、UNIX、および Windows プラットフォーム (LUW) に移植されました。現在、Db2 はあらゆる業種の何千ものビジネスクリティカルなアプリケーションを支えています。 Amazon RDS for Db2 では、 AWS マネジメントコンソール で数回クリックするか、 AWS コマンドラインインターフェイス (AWS CLI) で 1 つのコマンドを入力するか、 AWS SDK を使用して数行のコードを入力するだけで Db2 データベースを作成できるようになりました。インフラストラクチャの面倒な作業は AWS が行い、アプリケーションのスキーマやクエリの最適化など、より高レベルのタスクに時間を割くことができます。 Amazon RDS を初めて使用する方や、オンプレミスの Db2 のバックグラウンドをお持ちの方のために、Amazon RDS の利点を簡単にまとめてみましょう。 Amazon RDS は、現在オンプレミスで使用しているものと同じ Db2 データベースを提供しています。既存のアプリケーションはコードを変更せずに RDS for Db2 を利用することができます。 データベースはフルマネージド型のインフラストラクチャ上で稼働します。サーバーのプロビジョニング、パッケージのインストール、パッチのインストール、またはインフラストラクチャを運用可能な状態に維持する必要はありません。 データベースはフルマネージドです。インストール、マイナーバージョンアップグレード、毎日のバックアップ、スケーリング、高可用性は AWS が担当します。 インフラストラクチャは必要に応じてスケールアップおよびスケールダウンできます。データベースを停止して再起動するだけで、基盤となるハードウェアを変更して変化するパフォーマンス要件を満たすことも、最新のハードウェアを利用することもできます。 Amazon RDS では、高速で予測可能で一貫した I/O パフォーマンスを実現するように設計されたストレージタイプを選択できます。新しいワークロードや予測不可能なワークロードの場合は、 ストレージを自動的にスケーリング するようにシステムを設定できます。 Amazon RDS はバックアップを自動的に実行し、数回クリックするだけで新しいデータベースに復元できます。 Amazon RDS は、可用性の高いアーキテクチャのデプロイに役立ちます。Amazon RDS は、異なるアベイラビリティーゾーン (アベイラビリティーゾーンは個別のデータセンターの集まり) にあるスタンバイデータベースにデータを同期的に複製します。マルチ AZ 配置で障害が検出されると、Amazon RDS は自動的にスタンバイインスタンスにフェイルオーバーし、データベースエンドポイントの DNS 名を変更せずにリクエストをルーティングします。この切り替えは、ダウンタイムが最小限に抑えられ、データ損失も発生しません。 Amazon RDS は AWS の安全なインフラストラクチャ 上に構築されています。転送中のデータを TLS を使用して暗号化し、保存中のデータを AWS Key Management Service (AWS KMS) で管理されているキーを使用して暗号化します。これにより、 FedRAMP 、 GDPR 、 HIPAA 、 PCI 、 SOC など、会社または業界の規制に準拠したワークロードをデプロイできます。 第三者監査人は、複数の AWS コンプライアンスプログラムの一環として Amazon RDS のセキュリティとコンプライアンスを評価します。 Amazon RDS コンプライアンス検証の全リストを確認することができます。 restore や import などのネイティブの Db2 ツールや AWS Database Migration Service (AWS DMS) を使用して、既存のオンプレミスの Db2 データベースを Amazon RDS に移行できます。AWS DMS では、データベースを 1 回の操作で移行することも、継続的に移行することもできますが、その間は、お客様が移行を決めるまで、アプリケーションがソースデータベースのデータを更新し続けます。 Amazon RDS は、 Amazon RDS 拡張モニタリング や Amazon CloudWatch など、データベースインスタンスをモニタリングするための複数のツールをサポートしています。また、 IBM Data Management Console や IBM DSMtop を引き続き使用することもできます。 それでは、その仕組みを見ていきましょう 私はいつも、新しいサービスを実際に動かしてみて、その仕組みを学びたいと思っています。Db2 データベースを作成し、 IBM が提供する標準ツール を使用して接続してみましょう。この記事を読んでいる皆さんのほとんどは、IBM Db2 のバックグラウンドを持ち、Amazon RDS についてあまり知らないと思います。 まず、Db2 データベースを作成します。そのためには、 AWS マネジメントコンソール の Amazon RDS ページに移動し、 Create database を選択します。このデモでは、ほとんどのデフォルト値をそのまま使用します。ただし、ここではすべてのセクションを紹介し、検討しなければならない重要な構成ポイントについてもコメントします。 Amazon RDS が提供する複数のデータベースエンジンの中から Db2 を選択しています。 ページを下にスクロールして、 IBM Db2 Standard とエンジンバージョン 11.5.9 を選択します。Amazon RDS は、必要に応じてデータベースインスタンスに自動的にパッチを適用します。Amazon RDS データベースメンテナンスの詳細については、 こちら をご覧ください。 Production を選択します。Amazon RDS は、高可用性と高速で一貫したパフォーマンスを実現するように調整されたデフォルト設定をデプロイします。 Settings で、RDS インスタンスに名前を付け（これは Db2 カタログ名ではありません！）、 マスターユーザー名 と パスワード を選択します。 Instance configuration で、データベースを実行するノードのタイプを選択します。これにより、仮想サーバーのハードウェア特性 ( vCPU 数、メモリ量など) が定義されます。アプリケーションの要件に応じて、IBM Db2 Standard インスタンスに最大 32 個の vCPU と 128 GiB の RAM を備えたインスタンスを割り当てることができます。IBM Db2 Advanced インスタンスを選択すると、最大 128 個の vCPU と 1 TiB の RAM を備えたインスタンスを割り当てることができます。このパラメーターは費用に直接影響します。 Storage では、 Amazon Elastic Block Store (Amazon EBS) ボリュームの タイプ 、サイズ、IOPS とスループットを選択します。このデモでは、デフォルトで提示されている値を受け入れます。これも費用に直接影響する一連のパラメーターです。 Connectivity で、データベースをデプロイする VPC ( AWS の用語では VPC はプライベートネットワーク) を選択します。 Public access で No を選択して、データベースインスタンスに自分のプライベートネットワークからのみアクセスできるようにします。このオプションで Yes を選択すると、インターネットからRDSに直接アクセスできるようになるため注意が必要です。 VPC セキュリティグループ を選択する場所でもあります。セキュリティグループは、どの IP アドレスまたはネットワークがデータベースインスタンスにアクセスでき、どの TCP ポートにアクセスできるかを定義するネットワークフィルターです。アプリケーションが Db2 データベースに接続できるように、必ず TCP 50000 が開いているセキュリティグループを選択または作成してください。 他のオプションはすべてデフォルト値のままにします。ページの一番下にある Additional configuration セクションを開くことが重要です。ここで Initial database name を指定できます。ここで Db2 データベースの名前を指定しない場合、そのインスタンスにデータベースが作成されないため、既存の Db2 データベースバックアップを復元する必要があります。 このセクションには、Amazon RDS 自動バックアップのパラメータも含まれています。時間枠とバックアップの保持期間を選択できます。 デフォルトをすべてそのまま使用して、 Create database を選択します。 数分後、データベースが使用可能となります。 データベースインスタンスの Endpoint の DNS 名を選択し、同じネットワーク上で稼働している Linux マシンに接続します。 IBM Web サイトからダウンロードした Db2 クライアントパッケージ をインストールしたら、次のコマンドを入力してデータベースに接続します。ここでは、Amazon RDS 固有のものは何もありません。 db2 catalog TCPIP node blognode remote awsnewsblog-demo.abcdef.us-east-2.rds-preview.amazonaws.com server 50000 db2 catalog database NEWSBLOG as blogdb2 at node blognode authentication server_encrypt db2 connect to blogdb2 user admin using MySuperPassword Bash 接続したら、人気の Db2Tutorial Web サイト からサンプルデータセットとスクリプトをダウンロードします。作成したばかりのデータベースに対してスクリプトを実行します。 wget https://www.db2tutorial.com/wp-content/uploads/2019/06/books.zip unzip books.zip db2 -stvf ./create.sql db2 -stvf ./data.sql db2 "select count(*) author_count from authors" Bash ご覧のとおり、データベースの接続と使用に関しては、Amazon RDS に固有のものはありません。私は標準の Db2 ツールとスクリプトを使用しています。 注意点 Amazon RDS for Db2 では、お客様自身の Db2 ライセンスを持ち込む必要があります。Db2 インスタンスを起動する前に、IBM customer ID とサイト番号を入力する必要があります。 そのためには、 カスタム DB パラメータグループ を作成し、起動時にデータベースインスタンスにアタッチします。DB パラメータグループは、1 つ以上の DB インスタンスに適用されるエンジン設定値のコンテナとして機能します。Db2 パラメータグループには、IBM Db2 ライセンス固有のパラメータが 2 つあります。それは IBM Customer Number ( rds.ibm_customer_id ) と IBM サイト番号 ( rds.ibm_site_id ) です。 IBM サイト番号がわからない場合は、IBM営業に連絡して、最新の資格証明（PoE）、請求書、または販売注文のコピーを入手してください。これらの書類にはすべて、サイト番号が記載されているはずです。 価格と使用可能状況 Amazon RDS for Db2 は、中国と GovCloud を除くすべての AWS リージョンでご利用いただけます。 Amazon RDS の価格はオンデマンドで、初期費用やサブスクリプションはありません。お支払いいただくのは、データベースが稼働している時間単位で、さらに、1 か月あたりにプロビジョニングされたデータベースストレージ、使用したバックアップストレージ、およびプロビジョニングした IOPS の数を加えた金額です。 Amazon RDS for Db2 の料金ページ には、リージョンごとの料金の詳細が記載されています。先に述べたように、Amazon RDS for Db2 ではお客様自身の Db2 ライセンスを持参する必要があります。 Amazon RDS を既にご存知であれば、アプリケーション開発者が新しいデータベースエンジンを利用できるようになったことを喜ぶでしょう。オンプレミスの世界から来ているなら、Amazon RDS が提供するシンプルさと自動化を気に入るはずです。 Amazon RDS for Db2 のドキュメントページ には、さらに多くの詳細が記載されています。さあ、今すぐ Amazon RDS for Db2 で初めてのデータベースをデプロイ してください。 — seb Sébastien Stormacq セブは、80年代半ばに初めてコモドール64に触れて以来、コードを書いてきました。彼は、情熱、熱意、顧客支援、好奇心、創造性を密かに融合させて、AWS クラウドの価値を引き出すようビルダーを鼓舞しています。彼の関心はソフトウェアアーキテクチャ、開発者ツール、モバイルコンピューティングです。彼に何かを売りたいなら、その商品にAPIがあることを確認してください。Twitter @sebsto で彼をフォローしてください。 翻訳はソリューションアーキテクトの山根 英彦が担当しました。原文は こちら です。

AWS Application Migration Service (AWS MGN) は、AWS への移行において AWS が推奨するサービスです。AWS MGN を利用することで、物理、仮想、またはクラウドのソースサーバーから AWS でネイティブに稼働するよう移行することが、簡単かつ迅速に行えます。 この 1 年間に、AWS MGN サービスの 主要なアップデート をいくつかご紹介しました。例えば、ソースサーバー環境のインベントリリストを AWS MGNに対して一括で入力するために利用できる「インポートとエクスポート」などの機能です。これらのアップデートは、より多くの移動方法を提供し、クラウドジャーニーのハードルを下げることを目的としています。そして当ブログでは、インポートとエクスポートの機能を補完する位置付けとして MGN コネクタをご紹介します。 MGN コネクタは、ソースサーバーへの AWS MGN レプリケーションエージェントの展開に伴う手動プロセスを自動化するための機能です。エージェントをソースサーバーに迅速にデプロイし、一括移行の準備が行えるため、多くの作業時間を節約することができます。 図 1 は、MGN コネクタを使用した AWS MGN レプリケーションエージェントのデプロイのアーキテクチャの概要を示しています。 図 1. AWS MGN レプリケーションエージェントのデプロイのアーキテクチャの概要 通常、ソースサーバーに AWS MGN レプリケーションエージェントを展開すると、エージェントが MGN エンドポイントに登録され、結果としてソースサーバーが AWS MGN のインベントリに追加されます。MGN コネクタを使用して AWS MGN レプリケーションエージェントを展開する場合、まず図 2 に示すインポートとエクスポート機能を使用して、AWS MGNにソースサーバーのリストを入力します。そのためには、AWS MGN サービスのコンソールからインベントリインポート用のテンプレートをダウンロードし、ソースサーバーデータを入力、そしてコンソールを使用してインポートし直します。インポートとエクスポートとその使用方法の詳細については こちら をご覧ください。 図 2. インポートとエクスポートのAWSコンソール画面 MGN コネクタを使用するために、AWS アカウントに対して、 こちら に記載された権限を付与した IAM ロールと IAM ポリシーを用意します。 次に、適切な IAM 認証情報と、 AWS Systems Manager (SSM) ハイブリッドアクティベーション のコードと ID を取得します。 2023 年 5 月のアップデート である、 AWS Organizations と統合して、複数の AWS アカウントにまたがる移行を管理 するための機能である、 AWS MGN の グローバルビュー を使用している場合、 こちら の手順に従い、MGN コネクタを用いて複数のアカウントにレプリケーションエージェントをデプロイすることができます。 MGN コネクタは、 サポートされている Linux バージョン を実行しているソース環境のサーバーにインストールする必要があります。このサーバーは MGN コネクタの実行にのみ使用してください。 MGN コネクタは、次のプロトコルを使用してソースサーバーと通信し、レプリケーションエージェントを展開します。 Windows サーバー向け: WinRM (Remote PowerShell、TCP ポート 5985-5986) Linux サーバー向け: SSH (TCP ポート 22) ソースサーバーのインベントリが入力され、権限が設定され、ファイアウォールルールが設定されたら、図 3 に示すように MGN コネクタを追加します。AWS MGN サービスコンソールに移動し、 MGN コネクタを追加 を選択します。 図 3. MGN コネクタの追加 次に、図 4 に示すように、コネクタの名前、SSM ハイブリッドアクティベーション、取得した IAM 認証情報など、MGN コネクタの登録に必要な事項を入力します。これらの入力情報を使用したシェルコマンドが生成されるため、それをコピーして Linux サーバーのシェルに貼り付け、MGN コネクタのダウンロードとインストールを行います。 図 4. MGN コネクタを登録するための情報入力 新しく作成された MGN コネクタは、自動的に MGN サービスとの通信を開始し、図 5 に示すように、AWS MGN サービスコンソールに表示されます。 図 5. MGN コネクタが登録されるとコンソールに表示される MGN コネクタをインストールしたら、次はソースサーバーを MGN コネクタに登録します。 コンソールから新しくデプロイした MGN コネクタを選択し、図 6 に示すように サーバーの登録 を選択します。 図 6. MGN コネクタにソースサーバーを登録する 図 7 に示すように、MGN のインベントリからソースサーバーを選択し、 MGN コネクタによるサーバーの登録 を選択します。 図 7. MGN コネクタに登録するソースサーバーを選択する MGN コネクタは、ソースサーバーにレプリケーションエージェントをデプロイするための認証情報を必要とします。認証情報は、 AWS Secrets Manager にシークレットとして作成、保存されます。 認証情報を構成するには、図 8 に示すように、リストから対象のサーバーを選択し、 アクション ドロップダウンメニューから サーバー認証情報の登録 を選択します。 図 8. サーバーの認証情報の登録 図 9 に示すように、ソースサーバーの管理者認証情報に関する新しいシークレットを作成します。複数のソースサーバーが同じ認証情報を共有している場合、シークレットの ARN を提供することで既存のシークレットを使用することもできます。 図 9. AWS secret manager にソースサーバーの認証情報を追加する MGN コネクタへのソースサーバーの登録プロセスが完了し、移行の実施に一歩近づきました。 次に、図 10 に示すように、ソースサーバーを選択し、 アクション ドロップダウンメニューから レプリケーションエージェントのインストール を選択して、MGN レプリケーションエージェントをソースサーバーに展開します。MGN コネクタは、デプロイメントを正常に完了するのに十分な CPU、RAM、およびディスク容量リソースがあることを確認します。 図 10. ソースサーバーへのレプリケーションエージェントのインストール これで、MGN コネクタがソースサーバーにレプリケーションエージェントをデプロイする構成になったため、移行プロセスにおけるその他の観点に集中することができるようになります。 レプリケーションエージェントのデプロイプロセスが完了したら、MGN コンソールからソースサーバーの ライフサイクルの状態 をトラックし、移行プロセスの次のステップを計画できます。 まとめ このブログでは、MGN コネクタを使い、ソースサーバーへの AWS MGN レプリケーションエージェントの展開に伴う手動プロセスを自動化する方法について記載しました。これにより、エージェントをソースサーバーに迅速にデプロイし、一括移行の準備が行えるため、多くの作業時間を節約することができます。ぜひ、AWS Application Migration Serviceの ユーザーガイド を確認し、MGN コネクタやその他の新しいサービス機能をお試しください。 翻訳はソリューションアーキテクト 小宮山 裕樹 が担当しました。原文は こちら です。

Apache Iceberg は、 Amazon Simple Storage Service （ Amazon S3 ）における大規模データセット用のオープンなテーブルフォーマットであり、大規模テーブルに対する高速なクエリパフォーマンス、アトミックコミット、同時書き込み、SQL 互換のテーブル進化を提供します。Iceberg はデータレイクにおける ACID トランザクションをサポートし、スキーマやパーティションのエボリューション、タイムトラベル、ロールバックなどの機能で非常に人気があります。Iceberg はデータセットの状態に関するメタデータ情報を取得し、データセットの進化や時間経過に伴う変化を記録します。 AWS Glue クローラー が Iceberg テーブルをサポートするようになり、AWS Glue Data Catalog の利用や他の Iceberg カタログからの移行が容易になりました。AWS Glue クローラーはスキーマ情報を抽出し、Iceberg メタデータの場所やスキーマの変更を Glue Data Catalog に更新します。その後、すべてのアナリティクスエンジンでデータカタログの Iceberg テーブルにクエリし、 AWS Lake Formation のきめ細かい権限を適用することができます。 Iceberg カタログは、Iceberg テーブルのコレクションを管理し、テーブルの現在のメタデータを追跡するのに役立ちます。Iceberg カタログには、AWS Glue Data Catalog、Hive メタストア、JDBC カタログなど、いくつかの実装オプションがあります。AWS Glue Data Catalog は、 Amazon Athena 、AWS Glue、 Amazon EMR 、Lake Formation などの AWS 分析サービスと統合されているため、ユーザーにおいて AWS Glue Data Catalog の使用や移行が好まれています。 本日（2023年8月16日）の発表で、データカタログにある既存の Iceberg テーブルに対して AWS Glue クローラーを作成し、スケジュールすることができるようになりました。そして、Iceberg テーブルが配置されている 1 つまたは複数の S3 パスを指定することができます。クローラーがクロールできる S3 パスの最大深度を指定するオプションがあります。各クローラーの実行ごとに、クローラーは各 S3 パスを検査し、データカタログ内のスキーマに対する新しいテーブル、削除、更新などのスキーマ情報をカタログ化します。クローラーはすべてのスナップショットでスキーマのマージをサポートし、AWS の分析エンジンが直接使用できるデータカタログの最新のメタデータファイルの場所を更新します。 さらに、AWS Glue は、AWS Glue コンソールまたは AWS Glue CreateTable API を使用して、データカタログに新しい（空の）Iceberg テーブルを作成するためのサポートを開始します。今回のリリース以前は、Iceberg テーブルフォーマットを採用したいユーザーは、 CreateTable に加えて、別途 PutObject を使用して Amazon S3 上に Iceberg の metadata.json ファイルを生成する必要がありました。多くの場合、ユーザーは Athena や AWS Glue などの分析エンジンで create table ステートメントを使用していました。新しい CreateTable API は、metadata.json ファイルを別途作成する必要性をなくし、与えられた API 入力に基づいて metadata.json を自動生成します。また、 AWS CloudFormation テンプレートを使用してデプロイメントを管理するユーザーは、 CreateTable API を使用して Iceberg テーブルを作成できるようになりました。詳細については、 Apache Iceberg テーブルの作成 を参照してください。 Athena を使用してデータにアクセスする場合、Amazon S3 のデータロケーションを Lake Formation に登録する際に、Lake Formation によるきめ細かいアクセス制御権限を設定して Iceberg テーブルを保護することもできます。Amazon S3 のソースデータと Lake Formation に登録されていないメタデータについては、Amazon S3 と AWS Glue アクションの AWS Identity and Access Management (IAM) 権限ポリシーによってアクセスが決定されます。 ソリューション概要 このユースケースの例では、あるユーザーがデータ処理に Amazon EMR を使用し、トランザクションデータには Iceberg フォーマットを使用しています。商品データを Amazon S3 に Iceberg フォーマットで保存し、データセットのメタデータを EMR のプライマリノード上の Hive メタストア にホストしています。ユーザーは、Athena を使用したインタラクティブな分析のために、アナリストロールの人が商品データにアクセスできるようにしたいと考えています。多くのAWS分析サービスは Hive メタストア とネイティブに統合されていないため、AWS Glue Data Catalog にメタデータを入力するために AWS Glue クローラーを使用します。Athena は Iceberg テーブルの Lake Formation アクセス権の許可をサポートしていますので、データアクセスにはきめ細かいアクセス権を適用可能です。 Iceberg スキーマをデータカタログにオンボードし、Lake Formation アクセスコントロールを使用してクローリングを行うようにクローラーを構成します。データベースとクロールされたテーブルに対して Lake Formation によるアクセス権の許可を付与し、アナリストユーザーが Athena を使ってデータをクエリし、検証できるようにします。 既存の Iceberg データセットのスキーマを Data Catalog に入力した後、新しい Iceberg テーブルを Data Catalog に登録し、Athena を使用して新しく作成したデータにデータをロードします。データベースと新しく作成したテーブルに Lake Formation によるアクセス権の許可を付与し、アナリスト・ユーザーが Athena を使用してデータをクエリし、検証できるようにします。 次の図は、ソリューションのアーキテクチャーを示しています。 AWS CloudFormationでリソースをセットアップする AWS CloudFormationを使用してソリューションリソースを設定するには、以下の手順を実行します。 IAM 管理者として AWS Management Console にログインします。 スタックの作成 を選択してCloudFormation テンプレートをデプロイします。 次へ を選択します。 次のページで、 次へ を選択します。 最後のページで詳細を確認し、「 AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。 」を選択します。 送信 （注意：画面上は左記の表記ですが 作成 の意味です。）を選択します。 CloudFormationテンプレートは以下のリソースを生成します。 EMR クラスタ用の VPC、サブネット、セキュリティグループ Iceberg テーブルデータとメタデータを格納するデータレイクバケット クローラーと Lake Formation 登録用の IAM ロール EMR クラスタと、Hive メタストアを使用して Iceberg テーブルを作成する手順 データアクセス用のアナリストロール 結果用の Athena バケットパス スタックが完成したら、AWS CloudFormation コンソールで、スタックの リソース タブに移動します。 EmrClusterId 、 DataLakeBucketName 、 LFRegisterLocationServiceRole 、 AWSGlueServiceRole 、 AthenaBucketName 、および LFBusinessAnalystRole の値をメモします。 Amazon EMR コンソールに移動し、作成された EMR クラスタを選択します。 ステップ タブに移動し、ステップが実行されたことを確認します。 このスクリプトは、Hive と Iceberg テーブルの product を使用してデータベース icebergcrawlerblodb を作成します。メタストアとして Amazon EMR 上の Hive メタストアサーバーを使用し、Amazon S3 にデータを保存します。 作成した S3 バケットに移動し、Iceberg テーブルのデータとメタデータが作成されていることを確認します。 このスタックがデプロイするリソースの中には、使用時にコストが発生するものもあります。 データが Amazon S3 上にあるので、バケットを Lake Formation に登録してアクセスコントロールを実装し、データガバナンスを一元化することができます。 Lake Formation の権限を設定する Lake Formation で AWS Glue Data Catalog を使用するには、以下の手順で Data Catalog の設定を更新し、IAM ベースのアクセス制御の代わりに Lake Formation によるアクセス権の許可を設定して Data Catalog リソースを制御します。 Lake Formation コンソールに admin としてサインインします。 Lake Formation コンソールに初めてアクセスする場合は、自分をデータレイク管理者として追加します。 ナビゲーションペインの Administration で Data Catalog Settings を選択します。 Use only IAM access control for new databases の選択を解除します。 Use only IAM access control for new tables in new databases の選択を解除します。 Cross account version settings で Version 3 を選択します。 Save を選択します。 これで Lake Formation によるアクセス権の許可を設定できるようになりました。 データレイクのS3バケットをLake Formationに登録する データレイクの S3 バケットを登録するには、以下の手順を実行します。 Lake Formation コンソールのナビゲーションペインで、 Data lake locations を選択します。 Register location を選択します。 Amazon S3 path には、データレイクバケットのパスを入力します。 IAM ロール は、CloudFormation テンプレートから LFRegisterLocationServiceRole に指定されたロールを選択します。 Permission mode は Lake Formation を選択します。 Register location を選択します。 クローラーにデータロケーションへのアクセス権を与える クローラーへのアクセスを許可するには、以下の手順を実行します。 Lake Formation コンソールのナビゲーションペインで、 Data locations を選択します。 Grant を選択します。 IAM users and roles で、クローラーのロールを選択します。 Storage locations には、データレイクのバケットパスを入力します。 Grant を選択します。 データベースを作成し、クローラーロールにアクセス権を付与する 以下の手順でデータベースを作成し、クローラーロールにアクセス権を付与します。 Lake Formation コンソールのナビゲーションペインで、 Databases を選択します。 Create database を選択します。 データベースの名前を icebergcrawlerblogdb とします。 Use only IAM access control for new tables in this database オプションが選択されていないことを確認します。 Create database を選択します。 Action メニューで Grant を選択します。 IAM users and roles で、クローラーのロールを選択します。 データベースは icebergcrawlerblogdb のままにしておきます。 Database permissions で Create table 、 Describe 、および Alter を選択します。 Grant を選択します。 Iceberg 用クローラーの設定 Iceberg 用のクローラーを設定するには、以下の手順を実行します。 AWS Glue コンソールのナビゲーションペインで、 Crawlers を選択します。 Create crawler を選択します。 クローラーの名前を入力します。この記事では、 icebergcrawler を使用します。 Next を選択します。 Data source configuration で、 Add data source を選択します。 Data source で Iceberg を選択します。 S3 path には、 s3://&lt;datalakebucket&gt;/icebergcrawlerblogdb.db/ を入力します。 Add a Iceberg data source を選択します。 Iceberg テーブルのサポートは、 CreateCrawler と UpdateCrawler の API と、以下のプロパティを持つ IcebergTarget をターゲットとして追加することで利用できます。 connectionId – Iceberg テーブルが VPC 認証が必要なバケットに格納されている場合、ここに接続プロパティを設定します。 icebergTables – これは icebergPaths 文字列の配列で、それぞれ Iceberg テーブルのメタデータファイルが存在するフォルダを示します。 以下のコードを参照してください。 { "IcebergTarget": { "connectionId": "iceberg-connection-123", "icebergMetaDataPaths": [ "s3://bucketA/", "s3://bucketB/", "s3://bucket3/financedb/financetable/" ] "exclusions": [ "departments/**", "employees/folder/**" ] "maximumDepth": 5 } } Next を選択します。 Existing IAM role には、スタックで作成したクローラーロールを選択します。 Lake Formation configuration で、 Use Lake Formation credentials for crawling S3 data source を選択します。 Next を選択します。 Set output and scheduling で、ターゲットデータベースを icebergcrawlerblogdb に指定します。 Next を選択します。 Create crawler を選択します。 クローラーを実行します。 各クロール中、提供された icebergTable パスごとに、クローラーは Amazon S3 List API を呼び出して、その Iceberg テーブルメタデータフォルダ下の最新のメタデータファイルを見つけ、 metadata_location パラメータを最新のマニフェストファイルに更新します。 次のスクリーンショットは、正常に実行された後の詳細を示しています。 クローラーは S3 データソースをクロールし、データカタログに Iceberg データのスキーマを入力することに成功しました。 これでデータカタログをプライマリメタストアとして使い始め、データカタログで直接、または createtable API を使って新しい Iceberg テーブルを作成することができます。 新しいIcebergテーブルを作成する コンソールを使用してデータカタログに Iceberg テーブルを作成するには、このセクションの手順を実施します。または、CloudFormation テンプレートを使用して、以下のコードを使用して Iceberg テーブルを作成することもできます。 Type: AWS::Glue::Table Properties: CatalogId:"&lt;account_id&gt;" DatabaseName:"icebergcrawlerblogdb" TableInput: Name: "product_details" StorageDescriptor: Columns: - Name: "product_id" Type: "string" - Name: "manufacture_name" Type: "string" - Name: "product_rating" Type: "int" Location: "s3://&lt;datalakebucket&gt;/icebergcrawlerblogdb.db/" TableType: "EXTERNAL_TABLE" OpenTableFormatInput: IcebergInput: MetadataOperation: "CREATE" Version: "2" IAMロールにデータロケーションへのアクセス権を付与する まず、IAM ロールにデータロケーションへのアクセス権を付与します。 Lake Formation コンソールのナビゲーションペインで Data locations を選択します。 Grant を選択します。 IAM users and roles の Admin IAM role を選択します。 Storage location に、データレイクのバケットパスを入力します。 Grant を選択します。 Iceberg テーブルの作成 以下の手順を実行して、Iceberg テーブルを作成します。 Lake Formation コンソールのナビゲーション ペインで、 Tables を選択します。 Create table を選択します。 Name に product_details と入力します。 Database に icebergcrawlerblogdb を選択します。 Table format は Apache Iceberg table を選択します。 Table location に &lt;datalakebucket&gt;/icebergcrawlerblogdb.db/ のパスを指定します。 Upload schema を選択後、以下のスキーマを指定し、 Upload を選択します。 [ { "Name": "product_id", "Type": "string" }, { "Name": "manufacture_name", "Type": "string" }, { "Name": "product_rating", "Type": "int" } ] Submit を選択してテーブルを作成します。 新しいIcebergテーブルにレコードを追加する Iceberg テーブルにレコードを追加するには、次の手順を実行します。 Athena コンソールで、クエリエディタに移動します。 設定 のタブを選択後、 管理 を選択し、CloudFormation の出力から AthenaBucketName に指定された値を使用して Athena クエリ結果の場所を構成します。 保存 を選択します。 以下のクエリを実行して、テーブルにレコードを追加します。 insert into icebergcrawlerblogdb.product_details values('00001','ABC Company',10) データカタログの Iceberg テーブルに Lake Formation によるアクセス権の許可を設定する Athena は Iceberg テーブルの Lake Formation によるアクセス権の許可をサポートしているので、この記事ではテーブルへのきめ細かいアクセス権を設定し、Athena を使用してクエリを実行する方法を紹介します。 これにより、データレイク管理者は Lake Formation コンソールを介して LFBusinessAnalystRole-IcebergBlogIAM ロールにデータベースとテーブルへのアクセス権の許可を委譲することができます。 ロールにデータベースと Describe へのアクセス権を許可する LFBusinessAnalystRole-IcebergBlogIAM ロールにDescribe 権限とともにデータベースへのアクセス権を許可するには、次の手順を実行します。 Lake Formationコンソールで、ナビゲーションペインの Permissions の下にある Data lake permissions を選択します。 Grant を選択します。 Principals で、 IAM users and roles を選択します。 IAM ロール LFBusinessAnalystRole-IcebergBlog を選択します。 LF-Tags or catalog resources で、 Named Data Catalog resources を選択し、 Databases に icebergcrawlerblogdb を選択します。 Database permissions で Describe を選択します。 許可を適用するには、 Grant を選択します。 ロールにカラムアクセスを許可する 次に、 LFBusinessAnalystRole-IcebergBlogIAM ロールに列アクセス権を付与します。 Lake Formation コンソールのナビゲーションペインの Permissions で、 Data lake permissions を選択します。 Grant を選択します。 Principals で、 IAM users and roles を選択します。 IAM ロール LFBusinessAnalystRole-IcebergBlog を選択します。 LF-Tags or catalog resources で、 Named Data Catalog resources を選択し、 Databases に icebergcrawlerblogdb を、 Tables に product を選択します。 Table permissions で Select を選択します。 Data permissions で Column-based access を選択します。 Include columns を選択し、 product_name と price を選択します。 権限を適用するには、 Grant を選択します。 ロールにテーブルへのアクセス権を付与する 最後に、 LFBusinessAnalystRole-IcebergBlogIAM ロールにテーブルアクセスを付与します。 Lake Formation コンソールのナビゲーションペインの Permissions で Data lake permissions を選択します。 Grant を選択します。 Principals で、 IAM users and roles を選択します。 IAM ロール LFBusinessAnalystRole-IcebergBlog を選択します。 LF-Tags or catalog resources で、 Named Data Catalog resources を選択し、 Databases に icebergcrawlerblogdb を、 Tables に product_details を選択します。 Table permissions で Select と Describe を選択します。 許可を適用するには、 Grant を選択します。 Athena を使用したテーブルの検証 Athena を使用してテーブルを検証するには、 LFBusinessAnalystRole-IcebergBlogrole に切り替え、以下の手順を実行します。 Athena コンソールで、クエリエディターに移動します。 設定 のタブを選択後、 管理 を選択し、CloudFormation 出力から AthenaBucketName の値を使用して Athena クエリ結果の場所を構成します。 保存 を選択します。 product と product_details のクエリを実行して、アクセスを検証する。 次のスクリーンショットは、 product のカラムパーミッションを示しています。 次のスクリーンショットは、 product_details のテーブル・パーミッションを示しています。 Hive メタストアから作成した Iceberg データセットを Amazon S3 上のデータでクロールし、スキーマが設定された AWS Glue Data Catalog テーブルを作成することに成功しました。データレイクのバケットを Lake Formation に登録し、Lake Formation によるアクセス権の許可設定を使用してデータレイクへのクローラーのアクセスを有効にしました。データベースとテーブルに対する Lake Formation によるアクセス権の許可をアナリストユーザーに付与し、Athena を使用してデータへのアクセスを検証しました。 クリーンアップ AWSアカウントへの不要な課金を避けるために、AWSリソースを削除します。 CloudFormation スタックの作成に使用した IAM 管理者として CloudFormation コンソールにサインインします。 作成したCloudFormationスタックを削除します。 まとめ Iceberg のクローラーがサポートされたことで、Iceberg テーブルのプライマリカタログとしてAWS Glue データカタログへすぐに移行することができます。AWS の Glue クローラーを実行することで、自動的にIceberg テーブルをデータカタログに登録することができ、DDL や手動でのスキーマ定義が不要になります。AWS Glue クローラーを使用して AWS 上のサーバーレスでトランザクション可能なデータレイクの構築の開始、データカタログを使用して新しいテーブルの作成、Athena による Iceberg テーブルフォーマットのクエリのために Lake Formation のきめ細かいアクセス制御を利用することができます。 様々な AWS 分析サービスにおける Iceberg テーブルの Lake Formation サポートについては、 他のAWSサービスでの使用 を参照してください。 原文は こちら です。

マルチアカウント戦略 に関する AWS のベストプラクティスに従い、お客様は製品、グループ、部門などに応じて、複数のアカウントとリージョンで Amazon Connect インスタンスを起動して維持しています。これにより、個々のビジネスオーナー、開発者、エンジニアなどは、各自の独立した Amazon Connect 環境に変更を加えることができます。このようなシナリオでは、 Amazon Connect 環境全体にわたるユーザーやリソースのアクティビティに関する調査を簡素化し、管理するための一元的な仕組みが必要です。 お客様がマルチアカウント環境で Amazon Connect パブリック API を追跡、記録、分析できるように、Amazon Connect は、すべてのパブリック Amazon Connect API 呼び出しを記録するサービスである AWS CloudTrail と統合されています。AWS CloudTrail を使用すると、お客様は AWS Organization 全体でログを収集し、一元化された Amazon Simple Storage Service (S3) バケットに送信できます。また、サーバーレスのインタラクティブ分析サービスである Amazon Athena には、一元化された Amazon Connect ログのクエリと分析を行う機能が備わっています。 このブログ記事では、複数の AWS アカウントとリージョンにわたる Amazon Connect インスタンスのアクティビティを記録、表示、クエリ、分析するために必要な手順について説明します。この情報により、Amazon Connect のセキュリティ状況を把握し、想定から逸脱したアクティビティを調査できます。 前提条件 このチュートリアルでは、次の前提条件を満たしている必要があります。 Amazon Conenct パブリック API の基本的な理解 AWS Organization の 管理アカウント へのアクセス 組織の証跡 を作成できること チュートリアル このチュートリアルでは、アカウントとリージョンを横断し、削除された Amazon Connect インスタンスを調査します。まず、組織全体で削除された Amazon Connect インスタンスの数を確認することから始めます。次に、削除を行ったユーザーを特定し、他のアクティビティを調べます。 まず、 組織の証跡 を作成します。組織の証跡を作成すると、組織全体の Amazon Connect パブリック API の履歴を記録し、CloudTrail ログを一元化された S3 バケットに送信します。次に、Amazon Athena を使用してこの一元化された S3 バケットにクエリを実行し、アカウントとリージョンを横断して Amazon Connect のアクティビティを分析します。図 1 は、このワークフローを図示したものです。 図 1: 一元化された CloudTrail ログへのクエリ ステップ 1: 組織の証跡の設定 既存の組織の証跡がある場合、この演習でも既存の証跡を使用できます。既存の組織の証跡にアクセスできない場合は、以下の手順に従ってください。管理イベントを Amazon S3 に配信する場合、 1 つの配信は 無料 です。 CloudTrail コンソール に移動します。左側のペインから証跡を選択し、右側のペインから証跡の作成を選択します。 証跡属性の選択ページ で、 cloudtrail-connect-example などの証跡名を指定します。 組織内のすべてのアカウントで有効化 のボックスにチェックを入れます。 わかりやすくするために、 ログファイルの SSE-KMS 暗号化 は有効にしません。他のオプションはデフォルトのままにします。 次へ を選択します。 ログイベントの選択 ページですべてデフォルトのままにして、 次へ をクリックします。 確認と作成 ページで、 証跡の作成 を選択します。 これで証跡が作成されました。 S3 バケットの列 のバケット名をメモしておきます。 ステップ 2: Athena テーブルの設定 Athena コンソール に移動し、 クエリエディタ を選択します。Athena を使用して初めてログを記録する場合、以下のメッセージが表示されます。 設定を編集 を開き、クエリ結果の場所の S3 バケットを設定します。 組織 ID を確認するため、AWS Organizations のコンソールにアクセスします。左側のパネルの 組織 ID をコピーします。 Athena コンソール に戻り、クエリエディタを開きます。右側のペインのクエリエディタにクエリを入力し、実行することができます。 以下のクエリを使用して、結果をクエリするためのテーブルを作成します。 S3 バケット名 (ステップ 1 でメモしたもの) と 組織 ID (o-xxxxxxxxxx) は置き換えてください。 CREATE EXTERNAL TABLE cloudtrail_logs ( eventversion STRING, useridentity STRUCT&lt; type:STRING, principalid:STRING, arn:STRING, accountid:STRING, invokedby:STRING, accesskeyid:STRING, userName:STRING, sessioncontext:STRUCT&lt; attributes:STRUCT&lt; mfaauthenticated:STRING, creationdate:STRING&gt;, sessionissuer:STRUCT&lt; type:STRING, principalId:STRING, arn:STRING, accountId:STRING, userName:STRING&gt;, ec2RoleDelivery:string, webIdFederationData:map&lt;string,string&gt; &gt; &gt;, eventtime STRING, eventsource STRING, eventname STRING, awsregion STRING, sourceipaddress STRING, useragent STRING, errorcode STRING, errormessage STRING, requestparameters STRING, responseelements STRING, additionaleventdata STRING, requestid STRING, eventid STRING, resources ARRAY&lt;STRUCT&lt; arn:STRING, accountid:STRING, type:STRING&gt;&gt;, eventtype STRING, apiversion STRING, readonly STRING, recipientaccountid STRING, serviceeventdetails STRING, sharedeventid STRING, vpcendpointid STRING, tlsDetails struct&lt; tlsVersion:string, cipherSuite:string, clientProvidedHostHeader:string&gt; ) ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe' STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat' LOCATION 's3:// ENTERNAMEOFS3BUCKET /AWSLogs/ ENTERORGID /'; 左側のテーブルとビューのパネルに cloudtrail_logs というテーブルが作成されました。 次に、テーブルに追加する必要があります。そのため、クエリエディターでプラス (+) 記号を選択して、次のクエリ用に新しいタブを作成します。 ALTER TABLE cloudtrail_logs SET LOCATION 's3:// ENTERNAMEOFS3BUCKET /AWSLogs/ ENTERORGID /' ステップ 3: 複数のアカウントとリージョンにわたる Amazon Connect アクティビティの調査 Amazon Connect のアクティビティをシミュレートするため、複数のアカウントとリージョンで Amazon Connect インスタンスを作成 し、後で それらのインスタンスを削除 します。CloudTrail レコードが表示されるまで数分待ってから、次のクエリを新しいタブに入力してください。 アカウントとリージョン全体で 削除された インスタンスの数を確認するには、 Athena コンソール に移動して以下のクエリを実行します。 SELECT eventName, count(eventName) AS NumberOfDeletedInstances, recipientaccountid, awsRegion FROM cloudtrail_logs Where eventname = 'DeleteInstance' AND eventsource = 'connect.amazonaws.com' GROUP BY eventName, recipientaccountid, awsRegion これらのインスタンスを削除したユーザーを特定するには、以下のクエリを実行します。 useridentity.arn をコピーしておきます。 SELECT useridentity.arn, recipientaccountid, sourceipaddress, eventtime, awsRegion, eventName, requestParameters FROM cloudtrail_logs Where eventname = 'DeleteInstance' AND eventsource = 'connect.amazonaws.com' これらの削除を行ったユーザーのアクティビティを確認するには、以下のクエリを実行します。 SELECT eventName, recipientaccountid, sourceipaddress, eventtime, awsRegion FROM cloudtrail_logs Where useridentity.arn = 'ENTERTHEUSERARN' AND eventsource = 'connect.amazonaws.com' 上記の例の手順で、アカウント・リージョン全体の Amazon Connect に関する CloudTrail ログをクエリできました。Amazon Connect のログファイルのエントリの詳細については、AWS CloudTrail ドキュメントの「 AWS CloudTrail を使用して Amazon Connect API 呼び出しをログ記録する 」をご覧ください。 クリーンアップ 検証の為だけにブログの手順に従っていた場合は、請求が継続しないようにアカウントをクリーンアップしてください。そうでない場合は、クリーンアップを実行しないでください。クリーンアップするには、以下の手順に従ってください。 この演習の一環として CloudTrail の組織の証跡を作成した場合は、 CloudTrail コンソール に移動し、作成した証跡を選択して 削除 を選択します。 S3 コンソール に移動します。すべてのアカウントの CloudTrail ログを保存するために作成した S3 バケットを 削除 します。 結論 このブログ記事では、組織の証跡を使用して複数のアカウントとリージョンにわたる Amazon Connect に関するアクティビティをクエリする方法を紹介しました。Amazon Connect の詳細については、 Amazon Connect のドキュメント をご覧ください。 著者について Pranjal Gururani Pranjal Gururani は、シアトルを拠点とする AWS のソリューションアーキテクトです。Pranjal はさまざまなお客様とビジネス上の課題に対処するクラウドソリューションを構築しています。ハイキング、カヤック、スカイダイビングを楽しみ、余暇には家族と過ごす時間を楽しんでいます。 Guy Bachar Guy Bachar は、ニューヨークを拠点とする AWS のソリューションアーキテクトです。彼はグリーンフィールドのお客様の AWS を使用したクラウドへの移行を支援しています。ID、セキュリティ、ユニファイドコミュニケーションに情熱を注いでいます。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

組織が未来に対応できるようにすることは、企業のシニア・リーダーの仕事です。しかし、残念ながら未来は不透明で、急速な変化、不確実性、複雑性の時代においてはなおさらです。天気と同じように、私たちは近い将来をある程度確実に予測することができますが、先を見通すにつれて、その保証は薄れてきます。そして今日、濃い霧が立ち込め、1、2メートル先も見えないような状況になっています。では、どうすれば企業はその未来に備えることができるのでしょうか？ 喩えを徹底的に打ちのめすことを終わりにして、うまくいかないことを認めざるをえません。それは、霧の中を大胆に闊歩して、突然穴ぼこにつまずいたり崖から落ちたりするまで、あたかも見えているかのようにすることです。それは、馬鹿げているかと思えるかもしれませんが、多くの伝統的な企業がやっていることです。あたかも遠くまで見通せるかのような硬直した計画を立て、今年のニーズでさえ変化する可能性が高いのに、来年必要になると思われるリソースを獲得し、変化や革新を困難にするガードレールを設けることをしています。 本ブログは、未来に対応できるようになるための記事ですが、正直なところ、筆者は未来がどうなるのかほとんどわかっていません。労働力としてロボットを管理し、AI に事務用品を人質に取られたときに交渉する方法をお伝えしたいところだが、私が目にするのは、時折可能性のある道筋が垣間見える霧のようなものがほとんどなのです。 とはいえ、リーダーは組織が未来に備えるようにしなければなりません。そのための方法がこちらです。 回復力と俊敏性を高める 回復力と俊敏(訳者注：Resilience and agility、レジリエンスとアジリティ) とは、予期しない、あるいは予期できない状況に対応する能力を指す言葉です。それ故に、ビジネスにとって価値があります。貴社は、回復力と俊敏性への投資のリターンをどのように評価しているのでしょうか？　通常、企業は、収益の増加やコストの減少といった目に見えるリターンの予測に基づいて、潜在的な投資の価値を評価します。しかし、回復性への投資は、リスクの削減や選択肢の創出といった、より具体的な準備への投資です。具体的なリターンが予測される投資と比較して、優先順位をつけるのは困難です。特に、組織が、未来に霧がかかっていないかのように装ってリターンを予測している場合はなおさらです。 しかし、回復性と俊敏性は、将来への備えとして極めて重要です。そのためには、将来への継続性という広い視野が必要です。将来には、突然、新たな分かれ道が現れ、道路工事や料金所、あるいは空から降ってくる象によって、道が不意にふさがれてしまうかもしれません。組織には、新たなテクノロジーに対応し、容易に変更し、拡大・縮小できる技術インフラが必要です。また、状況の変化に適応できる労働力と企業文化も必要である。組織がロボット労働者の権利を認める必要があると判断したとき、あるいは生成 AI が顧客一人ひとりに関する小唄を作成し始めたとき、企業のガバナンス・プロセスはそれを受け入れることができるでしょうか？　さらに深刻なのは、状況の変化に応じて資金やその他のリソースを振り向けることができるかどうかです。パンデミックや戦争でマネジャーがいなくなった場合、他の誰かが代わりに行動できるでしょうか?　マネージャーのかわりの人は適切な権限を持ち、適切なデータにアクセスし、必要に応じて支出を委ねることができるだろうか？ 技術面では、未来に対応する組織は柔軟なテクノロジーと技術プロセスを採用する必要があります。今日、DevOps とクラウドは、回復性と俊敏性を獲得するための最良の方法です。クラウドは、インフラストラクチャの迅速な変更と、イノベーションをサポートするサービスの迅速なプロビジョニングを可能にします。DevOpsは、変更を本番環境に迅速に導入します。技術アーキテクチャは柔軟に設計でき、機械学習は、極めて複雑な機能を迅速に構築するための強力な手法になります。機械学習は、未来に対応できる企業の持つ道具セットに入っているべきなのです。 組織に回復性と俊敏性を構築することについては、まだまだ語りたいことがたくさんありますが、他のブログ記事でも頻繁に取り上げているので、この辺で話を進めることにしましょう。 未来志向のパートナーやプロバイダーとの連携 ベンダーやパートナーも同様の課題に直面しています。彼らもまた、不確実な将来に備えなければなりません。この意味で、クラウド・プロバイダーの選択は非常に重要です。 AWS が理想的なパートナーである理由を説明したいと思います。 AWS はクラウドのパイオニアであり、クラウドサービスにおけるイノベーションの最前線にいます。新しいテクノロジーが登場すれば、それらは間違いなくクラウドに登場します。どのような技術かは聞かないでほしいのですが （前述の通り、私はあなたと同じ霧の天気予報しか持っていません）、おそらく、あなたのデータセンターで利用できるようになるずっと前に、クラウドで利用できるようになるでしょう。 AWS は、新しいテクノロジーを試すコストとリスクを軽減することに取り組んでおり、私たちの基本理念の1つは、新しいテクノロジーを民主化し、簡単にアクセスできるようにすることです。言い換えれば、たとえ私たちが未来がどうなるのかよくわからなくても、 AWS が未来を利用できるように努力することは保証されます。 AWS は Amazon.com を動かしているテクノロジーであることを覚えておいてください。 AWS の顧客は、 Amazon.com が未来に進むために頼りにしているのと同じクラウド機能を利用できるのです。 AWS はアマゾンのニーズを満たすために進化し続けます。この表現の通り、まずは自分たちで試しているわけです。アマゾンのレコメンデーション・エンジン、フルフィルメント・センターでのロボットによるピッキング・ルート、配送ドローンや Amazon Go 店舗のビジョン機能、サプライチェーンやロジスティクスの予測システムなどの基盤となっています。 未来に対応できるようになるには、ベンダーの現在の能力だけでなく、ベンダーの未来への可能性を検証することが必要です。 目的と使命を明確にする たとえあなたの組織が変化に対応することに長けていたとしても、潜在的な問題はあるはずです。強い使命感、ビジョン、目的、指針が必要です。それは、ミッション・ステートメントを言葉で作ったり、壁に貼るポスターを作ったりする問題ではなく、何をもって自社の努力を団結させ、従業員のモチベーションを高め、競合他社や他のステークホルダーとの相対的な世界における自社のポジションを定義するかという問題なのです。 目的は、切迫感、思いやり、新しいアイデアに挑戦する意欲、結果のオーナーシップを駆り立てます。それは従業員に力を与え、誰もが組織の方向性を理解することで意思決定の分散化を可能にするのです。また、会社が何を目指しているのかを顧客に伝えることができ、競争力のあるポジショニングの一部となっていきます。 未来対応型であることとは、混乱期においても企業の努力を統合し、リーダーや従業員が変化の時代に迅速な意思決定を行えるような、強い方向感覚を持つことです。 労働力と柔軟なキャパシティ これは我慢しがたいことかもしれませんが、未来に対応する組織には余剰キャパシティが必要です。経済的には非効率に聞こえるかもしれませんが、リーン思考は、稼働率が高すぎ、そのキャパシティに対する需要が予測不可能な場合、 キングマンの方程式 で予測されるように、リードタイムが大きく損なわれる可能性があることを示しています。需要が予測可能な場合、生産能力計画は効果的なのです。需要が予測不可能な場合、ベルトの締め付けが強すぎると、単に他のコストが発生するだけです。 それには、従業員がジェネラリストであり、必要に応じて1つの機能と別の機能を行き来できることが助けになります。未来は霧に包まれているため、私たちは何をしなければならないのか、あまりよくわかっていません。それよりも、組織の目的を達成するために必要なことは何でもやるという文化を育て、さまざまなスキルを持った社員を抱える方がいいのです。 結論 未来に対応できるというのは、未来に何が起こるかを正確に知っていて、そのために今どう準備すべきかを知っているという意味ではありません。未来が進む方向を察知し、それに適応する能力に長けているということです。そしてそれは、組織が習得できるスキルであり、リーダーが率いるべき方法なのです。 Mark Schwartz マーク・シュワルツは、アマゾンウェブサービスのエンタープライズストラテジストであり、『 The Art of Business Value and A Seat at the Table：IT Leadership in the Age of Agility 』の著者です。 AWS に入社する前は、米国市民権・移民業務局 (国土安全保障省の一部) の CIO、Intrax の CIO、および Auctiva の CEO を務めていました。 彼はウォートン大学で MBA を取得し、イェール大学でコンピューターサイエンスの理学士号を取得し、イェール大学で哲学の修士号を取得しています。 この記事はアマゾン ウェブ サービス ジャパン ソリューションアーキテクトの佐藤伸広が翻訳を担当しました。原文は こちら です。

この記事は、 Automate Ethereum node validator deployment on Amazon EC2 using AWS CDK を翻訳したものです。 イーサリアム は、スマートコントラクト機能を持つ分散型のオープンソースブロックチェーンです。 Beacon chain （ETH2）は、イーサリアムのアップグレード版で、イーサリアムのエコシステムにプルーフ・オブ・ステークの概念を導入したものです。ETH2でのステークは、Ethereumネットワークのセキュリティとスケーラビリティを向上させるために、認証や新しいブロック作成の提案などのアクションを実行するバリデーターによって行われます。バリデーターは、ステーキングを行うことで報酬を得ることができます。 AWSは現在、 Amazon Managed Blockchain （AMB）を提供しています。これは、一般的なオープンソースフレームワークを使用して、スケーラブルなブロックチェーンネットワークを簡単に作成・管理できるフルマネージドサービスです。現在、私たちは Hyperledger Fabric としてプライベート許可型ネットワークを、またパブリックのmainnetと2つの人気テストネットであるRinkebyとRopsten(*)に接続する イーサリアム フルノードをサポートしています。Amazon Managed Blockchainは、現時点ではEthereum Beaconチェーンをサポートしていません。 Rocket Pool は、Beaconチェーンをサポートする分散型ステーキングプールの1つです。ステーキングで報酬を得たいバリデーターは、Rocket Poolを使用して自分の検証ノードを作成することができます。これらの検証ノードは、 Graviton2 プロセッサを搭載した Amazon Elastic Compute Cloud (Amazon EC2) 上で実行することができます。この記事では、 Amazon Elastic Compute Cloud 上での Rocket Pool のデプロイを簡素化する AWS Cloud Development Kit (AWS CDK) アプリについて紹介します。 (*) 2022/11/1時点でGoerilのテストネットもサポートされています。 ソリューションの概要 CDKは、オープンソースのソフトウェア開発フレームワークで、使い慣れたプログラミング言語を使ってクラウドアプリケーションリソースを定義することができます。 私たちのCDKアプリは、8つのvCPUと16GBのメモリを含むc6g.2xlargeインスタンスを使用して、Rocket Pool検証ノードを作成します。c6gインスタンスはGraviton2プロセッサを搭載しており、Ethereum検証のようなブロックチェーンワークロードに理想的です。また、高性能なブロックストレージとして2TBの Amazon Elastic Block Store （EBS）デバイスを、安全なアクセスとして AWS Systems Manager Session Manager を構成しています。 次の図は、AWS CDKを使用してアプリを初期化、合成、デプロイするプロセスを示しています。 このデプロイメントでは、ETH1とETH2の両方のブロックチェーンネットワークの検証を実行します。デフォルトでは、このノードはETH1検証用にGethクライアント、ETH2検証用にLighthouseクライアントを使用するように設定されています。デプロイ後にRocket Pool CLIを使用してこれらのクライアント設定を変更することができます。 ローカルのデスクトップでAWS CDKを使用することができます。 手順のドキュメント を参照してAWS CDKを使い始めることができます。 依存関係とRocket Pool AWS CDKアプリケーションをダウンロードしインストール 以下のコードを使用して、AWS CDKと前提アプリをダウンロードおよびインストールします。 # Install TypeScript globally for CDK npm i -g typescript # If you are running these commands in Cloud9 or already have CDK installed, then # skip this command npm i -g aws-cdk # Clone the demo CDK application code git clone https://github.com/aws-samples/cdk-rocketpool-validator-node # Change directory cd cdk-rocketpool-validator-node # Install the CDK application npm install Rocket Poolは16GBまたは32GBのメモリを搭載したノードをデプロイすることを推奨しています。この記事では、16GBのインスタンスでデプロイしています。ただし、メモリを増やしたい場合は 　lib/cdk-rocketpool-validator-stack.ts ファイルを修正します。例えば、以下のデプロイコードで、ec2.InstanceSize.XLARGE2 を ec2.InstanceSize.XLARGE3 または XLARGE4 に変更します。 // Create the instance const ec2Instance = new ec2.Instance(this, 'Instance', { vpc, instanceType: ec2.InstanceType.of(ec2.InstanceClass.C6G, ec2.InstanceSize.XLARGE2), machineImage: ami, securityGroup: securityGroup, role: role, blockDevices: [rootVolume] }); # Bootstrap the CDK application for first time cdk bootstrap # Deploy the CDK application cdk deploy ➜ rocketpool-blog git:(main) cdk deploy This deployment will make potentially sensitive changes according to your current security approval level (—require-approval broadening). Please confirm you intend to make the following modifications: IAM Statement Changes ┌───┬──────────────────────────────────┬────────┬──────────────────────────────────┬──────────────────────────────────┬───────────┐ │ │ Resource │ Effect │ Action │ Principal │ Condition │ ├───┼──────────────────────────────────┼────────┼──────────────────────────────────┼──────────────────────────────────┼───────────┤ │ + │ ${ec2Role.Arn} │ Allow │ sts:AssumeRole │ Service:ec2.${AWS::URLSuffix} │ │ ├───┼──────────────────────────────────┼────────┼──────────────────────────────────┼──────────────────────────────────┼───────────┤ │ + │ arn:${AWS::Partition}:s3:::{"Fn: │ Allow │ s3:GetBucket* │ AWS:${ec2Role} │ │ │ │ :Sub":"cdk-hnb659fds-assets-${AW │ │ s3:GetObject* │ │ │ │ │ S::AccountId}-${AWS::Region}"} │ │ s3:List* │ │ │ │ │ arn:${AWS::Partition}:s3:::{"Fn: │ │ │ │ │ │ │ :Sub":"cdk-hnb659fds-assets-${AW │ │ │ │ │ │ │ S::AccountId}-${AWS::Region}"}/* │ │ │ │ │ └───┴──────────────────────────────────┴────────┴──────────────────────────────────┴──────────────────────────────────┴───────────┘ IAM Policy Changes ┌───┬────────────┬────────────────────────────────────────────────────────────────────┐ │ │ Resource │ Managed Policy ARN │ ├───┼────────────┼────────────────────────────────────────────────────────────────────┤ │ + │ ${ec2Role} │ arn:${AWS::Partition}:iam::aws:policy/AmazonSSMManagedInstanceCore │ └───┴────────────┴────────────────────────────────────────────────────────────────────┘ Security Group Changes ┌───┬──────────────────────────┬─────┬────────────┬─────────────────┐ │ │ Group │ Dir │ Protocol │ Peer │ ├───┼──────────────────────────┼─────┼────────────┼─────────────────┤ │ + │ ${SecurityGroup.GroupId} │ In │ TCP 22 │ Everyone (IPv4) │ │ + │ ${SecurityGroup.GroupId} │ Out │ Everything │ Everyone (IPv4) │ └───┴──────────────────────────┴─────┴────────────┴─────────────────┘ (NOTE: There may be security-related changes not in this list. See https://github.com/aws/aws-cdk/issues/1299) Do you wish to deploy these changes (y/n)? y CdkRocketpoolValidatorStack: deploying... [0%] start: Publishing 1e05055f04e0f731f0605c1138bcef8f9b37398dac16b3c617b743b9e9ff1b36:current_account-current_region [50%] success: Published 1e05055f04e0f731f0605c1138bcef8f9b37398dac16b3c617b743b9e9ff1b36:current_account-current_region [50%] start: Publishing 83d98b3d48439ff5155c3381d7bb65e8e94aff567b80132f374e41e033c588c9:current_account-current_region [100%] success: Published 83d98b3d48439ff5155c3381d7bb65e8e94aff567b80132f374e41e033c588c9:current_account-current_region CdkRocketpoolValidatorStack: creating CloudFormation changeset... [··························································] (0/18) 10:17:23 PM | CREATE_IN_PROGRESS | AWS::CloudFormation::Stack | CdkRocketpoolValidatorStack デプロイメントが完了すると、次のような出力が得られます。 ✅ CdkRocketpoolValidatorStack Outputs: CdkRocketpoolValidatorStack.IPAddress = 3.92.48.208 CdkRocketpoolValidatorStack.sshcommand = aws ssm start-session --target i-03deeff4f403fa189 —document-name SSM-RocketPoolConfiguration Stack ARN:arn:aws:cloudformation:us-east-1:1218594674:stack/CdkRocketpoolValidatorStack/4d31dd40-7979-11ec-a7cb-12 この時点で、AWS CDK Outputsからsshコマンドを実行し、インスタンスにログインしてください。 aws ssm start-session --target i-03deeff403fa189 —document-name SSM-RocketPoolConfiguration 以下は出力例です。 Starting session with SessionId: &lt;&gt; cd ~ &amp;&amp; bash sh-4.2$ cd ~ &amp;&amp; bash [ec2-user@ip-10-0-0-16 ~]$ インストールの完了 接続が完了したら、以下のコマンドを実行して残りのインストールを完了させることができます。 rocketpool service start (オプション) ETH1/ ETH2 のクライアントを変更したい場合は、以下のコマンドを実行します。ETH1のデフォルトクライアントはGeth、ETH2のデフォルトクライアントはLighthouseです。 rocketpool service config 詳細については、 Configuring the Smartnode Stack を参照してください。前述のスタックはPraterテストネットワークで実装されています。メインネットに切り替えたい場合は、 Pool Staking on Mainnet を参照してください。 Rocket pool には Grafana のサポートが付属しており、ETH2 クライアントごとにあらかじめダッシュボードが構築されています。ブラウザで http://&lt;your node IP&gt;:&lt;grafana port&gt; に移動して、 Grafana にログインすることができます。Grafana ポートは、デフォルトで 3100 に設定されています。デフォルトのログイン認証情報やダッシュボードのインポート方法などの追加情報は、Rocket Pool のドキュメントの Setting up Grafana セクションに記載されている場合があります。以下は、Prysm ETH2 クライアントのメトリクスを表示するダッシュボードのサンプル画像です。 クリーンアップ この記事で作成したリソースを次のコードでクリーンアップします。 cdk destroy CdkRocketpoolValidatorStack まとめ Rocket Poolは、Ethereumノードバリデーターがプルーフ・オブ・ステーキングによって報酬を得ることを可能にします。この投稿では、AWS CDKを使用して最小限のセットアップ時間でAWSクラウドのRocket PoolにETH2バリデーターをデプロイする方法を示しました。また、Session Managerを使用してノードに安全にアクセスする方法も紹介しました。ETHバリデータをメインネットにデプロイする前に、テストネットで試してみることをお勧めします。 フィードバックや追加の質問がある場合は、コメントを残すことをお勧めします。 本稿はソリューションアーキテクト畑が翻訳を担当しました。

この記事は、Origin社のColeman MaherとAWSのKevin Goodspeedによる投稿記事 How to Create and Sell Non-Fungible Tokens (NFTs) を翻訳したものです。 Non-Fungible Token (NFTs)は、新しいタイプのデジタル資産で、いろいろなところで話題になっています。NFTは、懐疑的な人からはナンセンスだと言われ、多くの人からはデジタルビーニーベイビーや野球カードだと言われ、真の信者からはデジタルコンテンツからアーティストとファンの交流方法まで全てを変えてしまう革命的な新しいアイデアだと言われています。私はOrigin ProtocolでNFTを担当し、すでに多くの業界でNFTがいかにゲームチェンジャーであるかを目の当たりにしています。このブログでは、NFTの世界を簡単に紹介し、また、自分でNFTを発行し、様々なプラットフォームやマーケットプレイスで取引する方法をお教えしたいと思います。 NFTの紹介 Non-Fungible Token（NFT）は、ユニークまたはレアなデジタル資産です。一般的に受け入れられている同等品と簡単に交換できるアイテムは、「代替可能」と言えます。例えば、1ドル札は別の1ドル札、4セント硬貨、100セント硬貨と交換することができます。NFTは、1つしか存在しないユニークなアイテムである場合があります。また、限られた数しか存在しない、希少なものである場合もあります。NFTが表現できるものに制限はありません。NBAはNBA Top Shotsでバスケットボールの試合のハイライトのビデオクリップを表現するためにNFTを使用しています。 NFTはまた、限定品のハンドバッグのような物理的な物の所有権証明にも利用できます。また、芸術の世界では「provenance」として所有権の証跡を提供することもできます。NFTが物理的なモノと結びつけられるなら、NFTは実体験とも結びつけられ、例えばコンサートやプライベートな公演へのアクセスチケットとして機能することも可能です。NFTの非常に強力な側面の1つは、二次販売取引による将来の収益を、NFTのオリジナル作成者または「発行者」にプログラム的に流用できることです。つまり、最初の販売後にNFTが何度も買い替えられたとしても、元の作成者は収益やロイヤリティを得ることができます。 NFTを発行する方法 独立系クリエイターによるNFTの活動の大部分は、イーサリアムのブロックチェーン上で行われています。イーサリアムとやり取りするには、モバイルアプリケーションとブラウザ拡張機能を持つMetaMaskのようなWeb3対応のウォレットが必要です。イーサリアムで取引を行うには、ブロックチェーンネットワークや「ガス」の手数料を支払うためのイーサリアムのネイティブ暗号通貨であるETHがウォレットに必要です。ETHはCoinbaseのような取引所で取得することができます。 イーサリアムのNFTはオープンソースの標準に基づいており、自分のウォレットに保有、つまり「保管」することになります。つまり、NFTを発行する際、特定のプラットフォームに縛られることなく、自分の好きなツールやプラットフォームを使ってNFTを作成することができます。例えば、MintbaseでNFTを発行し、OpenSeaでそれを公開・販売しても、NFTは自分のウォレットから出ることはありません。 OpenSeaは最近、クリエイターがガス代（手数料）を支払うことなくNFTを発行できる機能を発表しました。その方法について、 ステップバイステップのガイド が公開されています。まず、NFTを追加するコレクションを作成する必要があります。コレクションを作成し、名前を付けたら、画像ファイル、ビデオファイル、3Dモデル、音楽ファイルなど、基本的にあらゆる種類のデジタルコンテンツ・ファイルを使ってNFTを作成し、追加することができます。NFTの名前、説明、レア度も設定することができます。 Mintbaseは、クリエイターがNFTを簡単に発行できるもう一つのプラットフォームです。MintbaseはOpenSeaと同様、NFTを発行するためにまずストアを作成する必要があります。必要な手順については、 非暗号化ユーザー向けのガイド を参照してください。Mintbaseは現時点では画像のみをサポートしているため、ビジュアルアーティストに最適です。ストアを作成したら、名前、説明、数量を指定して NFT を発行し、ストアに追加します。すべてのNFTはデフォルトで販売用になっていますが、ボックスをチェックして販売用に表示されないようにすることができます。 Foundationは、NFTクリエイターのための招待制を採用しているプラットフォームです。Foundationは、誰でもプロフィールを作成できますが、選ばれたクリエイターだけがNFTを発行することができます。Foundationは、プラットフォーム上で NFTを発行する方法に関する完全なガイド を公開しています。Foundationは、画像、ビデオファイル、オーディオファイル、3DモデルによるNFTの発行をサポートしています。NFTの名前、説明、数量を選択することができます。 NFTSを売却する方法 ほとんどのNFTプラットフォームでは、NFTをリストして販売することもできます。OpenSeaでNFTを売却するには、そのNFTのアセットページに移動し、「売却」をクリックします。設定価格、オークション、バンドル販売から販売の種類を選択し、その他の条件を設定することができるようになります。 OpenSea のガイド では、すべての手順を説明しています。Mintbaseでは、デフォルトですべてのNFTが販売用にリストされています。NFTを販売用にリストしないことを選択した場合は、そのNFTに移動して「販売中」をチェックし、価格を設定することができます。Foundationは、NFTオークションに重点を置いています。NFTをオークションに出品するには、オークションに移動してリザーブプライスを設定し、「List Your NFT」をクリックしてオークションを開始します。オークションは24時間行われ、最後の15分間で入札があると、オークションはさらに15分間延長されます。 Foundationのガイド に詳細が記載されています。 もし、NFTのために自分だけにキュレーションされたストアを立ち上げたいと考えているなら、Originの共同設立者でAmazonブロックチェーンリードのKevin Goodspeedが書いた AWS上で自分だけのDshopを立ち上げる方法についてのガイド で確認することができます。多くのクリエイターは、自分のNFTが他のアーティストによる無関係なNFTと同じマーケットプレイスや仮想ギャラリーに表示されることを望まないため、キュレーションを非常に重要視しています。また、無関係なNFTを一緒に表示することは、NFTの価格に悪影響を及ぼす可能性があります。DshopはすでにNFTの出品に対応しているので、Dshopを立ち上げ、自分のプライベートストアとドメインでNFTを出品するだけでよいのです。 まとめ NFTとは何か、そしてこのエキサイティングな新世界に足を踏み入れるための知識について、ご理解いただけたと思います。分散型技術には確かに学習曲線があります。ですから、落胆することなく、非常に新しく実験的な技術を扱っていることを認識してください。皆さんがどのようなNFTを作り上げ、世界と共有するのか、楽しみでなりません。 本稿はソリューションアーキテクト畑が翻訳を担当しました。

Amazon Redshift は、クラウドにおけるフルマネージドでペタバイト規模のデータウェアハウスサービスです。Amazon Redshift を使えば、すべてのデータを分析して、ビジネスと顧客に関する総合的な洞察を導き出すことができます。ストアドプロシージャをサポートしており、準備された SQL コードが保存され、コードを何度も再利用することができます。 ストアドプロシージャは、データ変換、データ検証、ビジネス固有のロジックをカプセル化するために一般的に使用されます。複数の SQL ステップをストアドプロシージャにまとめることで、再利用可能なコードブロックを作成し、単一のトランザクションまたは複数の個別のトランザクションとしてまとめて実行することができます。Amazon Redshift 上のデータ処理を自動化するために、ストアドプロシージャをスケジュールすることもできます。詳細については、 Amazon Redshift にストアドプロシージャを導入する を参照してください。 Redshift ストアドプロシージャのデフォルトのアトミックトランザクションモードでは、Redshift ストアドプロシージャの呼び出しは、呼び出されたときに独自のトランザクションを作成するか、ストアドプロシージャが呼び出される前に明示的なトランザクションが開始されている場合は、既存のトランザクションの一部となります。プロシージャ内のすべてのステートメントは、ストアドプロシージャの呼び出しが終了したときに終了する単一のトランザクションブロック内にあるかのように動作します。他のプロシージャへの入れ子になった呼び出しは、他の SQL 文と同様に扱われ、呼び出し元と同じトランザクションのコンテキスト内で動作します。TRUNCATE、COMMIT、ROLLBACK ステートメントと、任意の SQL 文による例外処理ブロックは、現在のトランザクションを終了し、暗黙的に新しいトランザクションを開始します。この動作は、Teradata のような他のシステムから Amazon Redshift への移行において問題を引き起こす可能性があります。 この投稿では、非アトミックトランザクションモードのための Amazon Redshift ストアドプロシージャの拡張について説明します。このモードは、ストアドプロシージャ内のステートメントを自動的にコミットすることを可能にする、強化されたトランザクション制御を提供します。 非アトミックトランザクションモード 新しい非アトミックトランザクションモード機能は、Amazon Redshift のストアドプロシージャに 3 つの強化された機能を提供します。 DML または DDL ステートメントが明示的にオープンされたトランザクションの一部でない限り、ストアドプロシージャ内の各ステートメントは、それらステートメント自身が暗黙的に開始するトランザクションで実行され、次のステートメントではまた新しいトランザクションが開始されます。明示的にトランザクションが開始された場合、後続のステートメントはすべて実行され、明示的なトランザクション制御コマンド（ COMMIT または ROLLBACK ）がトランザクションを終了するために実行されるまで、コミットされないままになります。 Amazon Redshift は例外処理ステートメントが完了した後、例外を再送出しません。そのため、例外処理ブロックによってキャッチされた例外を再送出するために、INFO や EXCEPTION を持たない新しい RAISE ステートメントが提供されています。INFO や EXCEPTION を持たない、この RAISE ステートメントは、例外処理ブロックでのみ許可されています。 また、新しい START TRANSACTION ステートメントは、非アトミックトランザクションモードのストアドプロシージャ内で明示的なトランザクションを開始します。明示的に開始されたトランザクションを終了するには、既存のトランザクション制御コマンド ( COMMIT または ROLLBACK ) を使用します。 Amazon Redshift はサブトランザクションをサポートしないため、既に開始されたトランザクションが存在する場合、このステートメントを再度呼び出しても何も行われず、エラーは発生しません。 非アトミックトランザクションモードのストアドプロシージャ呼び出しが終了したときに、明示的トランザクションがまだ実行中の場合、セッション内でトランザクション制御コマンドが実行されるまで、明示的トランザクションは実行中のままになります。 トランザクション制御コマンドを実行する前にセッションが切断されると、トランザクション全体が自動的にロールバックされます。 その他の制限 Redshift ストアドプロシージャにはいくつかの制限があります。 ストアドプロシージャの入れ子呼び出しについては、アトミックトランザクションモード（デフォルトのモード）であろうと、新しい非アトミックトランザクションモードであろうと、すべてのプロシージャは同じトランザクションモードで作成されなければなりません。 2 つのトランザクションモード（アトミックと非アトミック）にまたがってストアドプロシージャを入れ子にすることはできません。 非アトミックトランザクションモードのストアドプロシージャに SECURITY DEFINER オプションや SET configuration_parameter オプションを設定することはできません。 カーソルへの影響 非アトミックトランザクションモードのストアドプロシージャのカーソルは、デフォルトのアトミックトランザクションモードと比較して異なる動作をします。 カーソルステートメントは、カーソルループの各イテレーションが自動コミットされないように、カーソルを開始する前に明示的なトランザクションブロックが必要になります。 非アトミックトランザクションモードのストアドプロシージャからカーソルを返すには、カーソルを開始する前に明示的なトランザクションブロックが必要です。そうでなければ、ループ内の SQL ステートメントが自動的にコミットされる時に、カーソルはクローズされます。 利点 ユーザーの視点から見たこの機能の主な利点は、以下の通りです。 Teradata のセッションモードで実行できる Teradata のストアドプロシージャをリフト＆シフトする機能を提供します。これは、Teradata や SQL Server のようなデータウェアハウスからのシームレスな移行に役立ちます。 Amazon Redshift がエラーや例外に遭遇した際に、ストアドプロシージャ内部でより柔軟な操作を提供できるようになります。Amazon Redshift は、例外に到達する前に以前のアクションの状態を保持できるようになりました。 構文 次のコードに示すように、新しいオプションのキーワード NONATOMIC がストアド プロシージャ定義の構文に追加されました。 &lt;code class="lang-sql"&gt;CREATE [ OR REPLACE ] PROCEDURE sp_procedure_name ( [ [ argname ] [ argmode ] argtype [, ...] ] ) [ NONATOMIC ] AS $$ procedure_body $$ LANGUAGE plpgsql&lt;/code&gt; このオプションのキーワードは、ストアドプロシージャを非アトミックトランザクションモー ドで作成します。このキーワードを指定しない場合は、ストアドプロシージャの作成時にデフォルトのアトミックモードがトランザクションモードとなります。 NONATOMIC は、プロシージャ内の各 DML と DDL ステートメントが暗黙的にコミットされることを意味します。 非アトミックモードでない場合、プロシージャは呼び出し開始時に独自のトランザクションを作成するか、呼び出し前に明示的なトランザクションが開始されていれば既存のトランザクションの一部となります。ストアドプロシージャ内の全てのステートメントは、この 1 つのトランザクションに属することになります。 NONATOMIC モードの例 顧客の主連絡先と副連絡先の電話番号を格納する顧客連絡先テーブル custcontacts を考えてみましょう。 CREATE table custcontacts( custid int4 not null, primaryphone char(10), secondaryphone char(10)); 連絡先番号のない 3 つのサンプル顧客レコードを挿入します。 INSERT INTO custcontacts VALUES (101, 'xxxxxxxxxx', 'xxxxxxxxxx'); INSERT INTO custcontacts VALUES (102, 'xxxxxxxxxx', 'xxxxxxxxxx'); INSERT INTO custcontacts VALUES (103, 'xxxxxxxxxx', 'xxxxxxxxxx'); 主と副の電話番号を更新するストアドプロシージャを作成する必要があります。要件は、副連絡先番号への更新が何らかの理由で失敗した場合に、主連絡先番号への更新をロールバックしないことです。 これは、NONATOMIC キーワードを使用してストアドプロシージャを作成することで実現できます。NONATOMIC キーワードは、ストアドプロシージャ内の各ステートメントが独自の暗黙的なトランザクションブロックで実行されるようにします。したがって、副電話番号に対する UPDATE ステートメントが失敗しても、主電話番号に対するデータ更新がロールバックされることはありません。以下のコードを参照してください。 CREATE PROCEDURE sp_update_custcontacts(cid int4,pphone char(15),sphone char(15)) NONATOMIC AS $$ BEGIN UPDATE custcontacts SET primaryphone=pphone WHERE custid=cid; UPDATE custcontacts SET secondaryphone=sphone WHERE custid=cid; END; $$ LANGUAGE plpgsql; それでは、10 桁以上の secondaryphone を渡すストアドプロシージャを呼び出してみましょう。副電話番号の長さが正しくないため UPDATE ステートメントは失敗します。 call sp_update_custcontacts(101,'1234567890','345443345324'); 前述のプロシージャ呼び出しは、主電話番号の更新には成功しますが、副電話番号の更新には失敗します。ただし、 primaryphone の更新は、ストアドプロシージャ定義の NONATOMIC 節により、独自の暗黙のトランザクション ブロックで実行されたため、ロールバックされません。 select * from custcontacts; custcontacts | primaryphone | secondaryphone -------------+---------------+--------------- 101 | 1234567890 | XXXXXXXXXX 102 | XXXXXXXXXX | XXXXXXXXXX 103 | XXXXXXXXXX | XXXXXXXXXX NONATOMICモードでの例外処理 ストアドプロシージャにおける例外の取り扱いは、アトミックモードか非アトミックモードかで異なります。 アトミック (デフォルト) – 例外は常に再送出されます。 非アトミック – 例外は処理され、再送出するかどうかを選択できます。 先ほどの例に続き、非アトミックモードでの例外処理を確認していきましょう。 ストアドプロシージャによって発生した例外を記録するために、以下のテーブルを作成します。 CREATE TABLE procedure_log (log_timestamp timestamp, procedure_name varchar(100), error_message varchar(255)); 次に、例外を処理するために sp_update_custcontacts() プロシージャを更新します。プロシージャ定義に EXCEPTION ブロックを追加していることに注意してください。これは、例外が発生した場合に procedure_log テーブルにレコードを挿入します。 CREATE OR REPLACE PROCEDURE sp_update_custcontacts(cid int4,pphone char(15),sphone char(15)) NONATOMIC AS $$ BEGIN UPDATE custcontacts SET primaryphone=pphone WHERE custid=cid; UPDATE custcontacts SET secondaryphone=sphone WHERE custid=cid; EXCEPTION WHEN OTHERS THEN INSERT INTO procedure_log VALUES (getdate(), 'sp_update_custcontacts', sqlerrm); END; $$ LANGUAGE plpgsql; もう 1 つストアドプロシージャを作成します。このプロシージャは前述のプロシージャを呼び出します。このプロシージャも EXCEPTION ブロックを持ち、例外が発生した場合に procedure_log テーブルにレコードを挿入します。 CREATE PROCEDURE sp_update_customer() NONATOMIC AS $$ BEGIN -- Let us assume you have additional staments here to update other fields. For this example, ommitted them for simplifiction. -- Nested call to update contacts call sp_update_custcontacts(101,'1234567890','345443345324'); EXCEPTION WHEN OTHERS THEN INSERT INTO procedure_log VALUES (getdate(), 'sp_update_customer', sqlerrm); END; $$ LANGUAGE plpgsql; 作成した親プロシージャを呼び出してみましょう。 call sp_update_customer(); これにより、 sp_update_custcontacts() プロシージャが呼び出されます。副電話番号を無効な値で更新しているため、内部で呼び出されているプロシージャ sp_update_custcontacts() は失敗します。コントロールは sp_update_custcontacts() プロシージャの EXCEPTION ブロックに入り、 procedure_log テーブルに挿入します。 しかし、非アトミックモードでは例外を再送出しません。したがって、親プロシージャ sp_update_customer() は、 sp_update_custcontacts() プロシージャから渡された例外を取得しません。コントロールは sp_update_customer() プロシージャの EXCEPTION ブロックに入りません。 procedure_log テーブルをクエリすると、 sp_update_custcontacts() プロシージャで処理されたエラーのエントリのみが表示されます。 select * from procedure_log; 次に、RAISE ステートメントを使用して sp_update_custcontacts() プロシージャを再定義します。 CREATE PROCEDURE sp_update_custcontacts(cid int4,pphone char(15),sphone char(15)) NONATOMIC AS $$ BEGIN UPDATE custcontacts SET primaryphone=pphone WHERE custid=cid; UPDATE custcontacts SET secondaryphone=sphone WHERE custid=cid; EXCEPTION WHEN OTHERS THEN INSERT INTO procedure_log VALUES (getdate(), 'sp_update_custcontacts', sqlerrm); RAISE; END; $$ LANGUAGE plpgsql; 親ストアドプロシージャ sp_update_customer() をもう一度呼び出してみましょう。 call sp_update_customer(); ここで、内部で呼び出されているプロシージャ sp_update_custcontacts() は、自身の EXCEPTION ブロックで例外を処理した後、親プロシージャ sp_update_customer() に例外を再送出します。その後、コントロールは親プロシージャの EXCEPTION ブロックに到達し、 procedure_log テーブルに別のレコードを挿入します。 procedre_log テーブルにクエリを実行すると、2 つのエントリーが表示されます。1 つは内部で呼び出されているプロシージャ sp_update_custcontacts() によるもので、もう 1 つは親プロシージャ sp_update_customer() によるものです。これは、内部で呼び出されているプロシージャの RAISE ステートメントが例外を再送出したことを示しています。 select * from procedure_log; 非アトミック・モードでの明示的なSTART TRANSACTION文 START TRANSACTION ステートメントを発行して、ストアドプロシージャ内でトランザクションブロックを開始することができます。これは、ストアドプロシージャ内で新しいトランザクションを開始します。参考例については、 非アトミックモードのストアドプロシージャのトランザクション管理 を参照してください。 まとめ この投稿では、Redshift ストアドプロシージャの非アトミックトランザクションモードの機能強化について説明しました。これは、ストアドプロシージャ内のステートメントを自動的にコミットできるようにトランザクション制御を拡張したものです。このモードは、Teradata のような他のシステムから Amazon Redshift への移行も容易にします。 原文は こちら です。

オブザーバビリティ（可観測性）とは、システムで何が起こっているかをどれだけ把握できるかを表します。多くの場合、メトリクス、ログ、トレースを収集するために計装することで実現します。運用体験の向上や、業務目標の達成を実現するには、システムがどのように動作しているかを理解する必要があります。これを実現するために、多くのお客様がリアルタイムのモニタリング、アラートとアラーム、カスタマイズ可能なダッシュボードの利用や、ビジネスの意思決定を支援を目的としたメトリクスの可視化を行うために、 Amazon CloudWatch を利用しています。組織では、カスタムパラメータを使用して任意の AWS Lambda 関数を呼び出すことができる CloudWatch ダッシュボードウィジェットを利用することが可能です。これにより、ダッシュボード上でデータを分析、および表示できる可能性が大きく広がります。しかし、組織内にこれらの関数を作成する専門知識がない場合はどうすれば良いでしょうか。ここで、 Amazon CodeWhisperer がこれらの関数の作成を支援するコード提案を行うことで、オブザーバビリティの向上に役立ちます。 Amazon CloudWatch ダッシュボード を使用すると、 AWS 環境全体のさまざまなメトリクスとリソースを一元的にモニタリングすることができるようになります。これにより、システムや組織全体でのアプリケーションの健全性とパフォーマンスを把握することができます。カスタムウィジェットにより、これらのダッシュボードの柔軟性が大幅に向上し、高度なレベルの監視と可視化が可能になります。 Amazon CodeWhisperer は、統合開発環境 (IDE) でリアルタイムに 1 行または関数コード全体の提案を生成することができる AI サービスです。これにより、ソフトウェアの構築を迅速に行うことができます。 この投稿では、 CodeWhisperer を利用して、 カスタムウィジェット 、 CloudWatch ダッシュボードの開発およびデプロイに使用されるコードの作成を支援する方法を示します。 またこの投稿では AWS Cloud Development Kit (CDK) を使用します。CDK は、近代的なプログラミング言語を使用してインフラストラクチャをコードとして定義し、 AWS CloudFormation を通じてデプロイするためのオープンソースのソフトウェア開発フレームワークです。 ソリューション全体像 このソリューションでは、 Amazon CodeWhisperer を使用して、 CDK コードの記述に関するコード提案を行います。 AWS CDK を使用して、さまざまなタイプの 3 つのウィジェットを持つダッシュボードをコーディングおよびデプロイします。 例では、テキストウィジェットと 2 つのカスタムウィジェットの作成方法を示します。 以下の図は、 CDK を介して作成されるリソースの概要を示しています。 図1. CDK によって作成される Amazon CloudWatch ダッシュボードアーキテクチャ この投稿のすべての手順に沿って操作を行うと、CloudWatch ダッシュボードは次のようになります。2 つのカスタムウィジェットと 1 つのテキストウィジェットが含まれます。 図2. CloudWatch テキストウィジェット この投稿全体を通して行うことは以下のとおりです。 Amazon CodeWhisperer の設定 ビルダー ID を使用するように IDE を設定 AWS CLI 、 AWS CDK 、 AWS IAM の設定 Amazon CodeWhisperer を使用して CDK コードと Lambda 関数の作成 デプロイのためのアセットを保持する Amazon Simple Storage Service(S3) バケットの作成 ダッシュボードとカスタムウィジェットのデプロイ 前提条件 この投稿に沿って作業を進める場合、ローカルマシン上の統合開発環境 (IDE) で作業を行なっていきます。 CodeWhisperer は、 Visual Studio Code (VS Code) 、 PyCharm などの JetBrains 製品など、複数の IDE で動作します。この記事では VS Code を使用します。他の IDE の使用手順は、 Amazon CodeWhisperer のドキュメント で確認できます。 また、以下についても必要になります。 AWS アカウント Visual Studio Code Python と pip AWS CLI AWS CDK ビルダー ID を使用するように IDE を設定 AWS Builder ID を使用して、 VS Code で CodeWhisperer を設定しましょう。AWS Builder ID は、 AWS 上で開発するすべてのユーザーのための新しい個人プロファイルです。 まず最初に、AWS Toolkit がインストールされていることを確認する必要があります。 VS Code IDE の左側のパネルで [Extensions] に移動します。検索バーに「AWS Toolkit」と入力し、以下のように拡張機能をインストールしてください。 図3. VS CodeでのAWS拡張機能の設定 これで、左側のパネルに AWS Toolkit アイコンが表示されるはずです。 Visual Studio Code の AWS Toolkit で、[Developer tools] の [CodeWhisperer] を選択し、 [Start] をクリックします。すると、 VS Code の上部にドロップダウンメニューが表示されます。 図4. CodeWhispererの開始 ドロップダウンメニューから、 [Use a personal email to sign up and sign in with AWS Builder ID] を選択します。 図5. 個人メールアドレスの設定 [Copy Code for AWS Builder ID] のプロンプトが表示されたら、 [Copy Code] と [Proceed] を選択します。 [Do you want Code to open the external website?] のプロンプトが表示されたら、 [Open] を選択します。 ブラウザタブが開き、 [Authorize request] ウィンドウが表示されます。コードはすでにクリップボードにコピーされているはずです。それを貼り付けて、 [Next] を選択します。 [Create AWS Builder ID] ページがブラウザタブで開きます。メールアドレスを入力し、 [Next] を選択します。 [Your name] のフィールドが表示されるので、名前を入力し、 [Next] を選択します。 入力したメールアドレスに確認コードが届きます。確認画面で届いたコードを入力し、 [Verify] を選択します。 [Choose your password] 画面で、パスワードを入力し、確認入力してから、 [Create AWS Builder ID] を選択します。 ブラウザタブが開き、 Visual Studio Code の AWS Toolkit にデータにアクセスすることを許可するよう求めるメッセージが表示されます。 [Allow] を選択します。 VS Code に戻ります。すでに IAM を使用して他の AWS ツールに認証している場合は、すべての AWS サービスで Builder ID を使用するかどうかを尋ねられます。状況に適したオプションを選択します。 AWS CLI 、 AWS CDK 、 AWS IAM の設定 このセクションでは、AWS CLI、CDK、CDKのフォルダ構造を設定します。 AWS CLIを設定するには、「 AWS CLI を設定する 」の手順に従ってください。 新しいフォルダを作成し、 sample1 と名前を付けます。このフォルダで CDK プロジェクトを作成します。 sample1 フォルダにディレクトリを変更します。 cd sample1 cdk をブートストラップします。 cdk bootstrap aws://&lt; アカウント番号 &gt;/&lt; リージョン名 &gt; cdk python 環境を作成します。 cdk init --language python これにより、sample1 フォルダに必要な python cdk ファイルが作成されます。 venv をアクティベートします。 source .venv/bin/activate 必要なパッケージをインストールします。 pip install -r requirements.txt Amazon CodeWhisperer を使用したコードの作成 このセクションでは、 CodeWhisperer を使用して CDK コードを記述する方法を説明します。 CDK を使用して、次の 6 つのリソースを作成する方法を説明していきます。 2 つの Lambda 関数 1 つの Lambda 関数は、ユーザー入力を受け取り、対応する出力を生成します。 もう 1 つのLambda関数は、 S3 バケットから HTML を取得します。 3 つの CloudWatch ウィジェット 1 つ目の Lambda 関数と統合するカスタムウィジェット。ユーザー入力を受け付け、 Lambda 関数からデータを読み取って出力を提供します。 2 つ目の Lambda 関数と統合するカスタムウィジェット。 S3 バケットから HTML ファイルを読み取ります。 「Hello World」と表示するテキストウィジェット 1 つの CloudWatch ダッシュボード Visual Studio Codeの利用 左上の [File] メニューから、 [Open Folder] を選択します。（ステップ 2 で作成した sample1 フォルダを選択します。） assets という名前の新しいフォルダを作成し、 HelloWorld.html という名前の html ファイルを作成します。 &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;body&gt; &lt;h1&gt;Hello!! This is an HTML file from S3 bucket&lt;/h1&gt; &lt;/body&gt; &lt;/html&gt; このファイルは S3 バケットにアップロードされ、 Lambda 関数によって読み込まれます。 再び sample1 フォルダに移動し、 sample1 という名前のサブフォルダを探します。 そのサブフォルダにあるスタックファイルを編集します。 ・import 文を追加します（入力時に CodeWhisperer が自動補完を支援します） from aws_cdk import ( aws_lambda, Stack, App, Duration, aws_iam, aws_cloudwatch, aws_s3, RemovalPolicy, aws_s3_deployment ) 必要なモジュールをインポートしたら、次の行を探します。 # The code that defines your stack goes here この行を削除し、スタックコードを記述します。 CodeWhisperer にコメントを入力して、 AWS CDK を使用した最初の Lambda 関数の作成を提案させます。 # define lambda function that has inline code 入力を開始すると、 CodeWhisperer が提案を開始します。 Lambda 関数の作成に関するヘルプが表示されたら、 Lambda 関数の CDK コードを次のように記述します。 # define lambda function that has inline code lambda_function = aws_lambda.Function(self, 'HelloWorldFunction', code=aws_lambda.Code.from_inline(""" def lambda_handler(event, context): showme = event['widgetContext']['forms']['all'].get('petType') # create a 2D array for pets and count data = [['puppy','10'],['bunny','5'],['kitten','6']] rowdata = "" for row in data: if (showme and showme==row[0]): # assume only 2 elements in the data rowdata += f''' &lt;tr&gt; &lt;td&gt;{row[0]}&lt;/td&gt; &lt;td&gt;{row[1]}&lt;/td&gt; &lt;/tr&gt;''' response = f''' &lt;p&gt;Which pet do you want to see? valid inputs: puppy/bunny/kitten &lt;form&gt;&lt;input name="petType" value="{showme}" size="10"&gt;&lt;/form&gt; &lt;/p&gt; &lt;table&gt; &lt;tr&gt; &lt;th&gt;Pets&lt;/th&gt; &lt;th&gt;Count&lt;/th&gt; &lt;/tr&gt; {rowdata} &lt;/table&gt; &lt;a class="btn btn-primary"&gt;Run query&lt;/a&gt; &lt;cwdb-action action="call" endpoint="{context.invoked_function_arn}"&gt;&lt;/cwdb-action&gt; ''' return response """ ), description="CloudWatch Custom Widget sample: simple hello world", function_name=self.stack_name, handler='index.lambda_handler', memory_size=128, runtime=aws_lambda.Runtime.PYTHON_3_9, timeout=Duration.seconds(60)' ) コードをカスタマイズするために入力を追加すると、 CodeWhisperer が提案を行うことに気づくでしょう。この例では、ペットの数の 2 次元配列を作成し、ユーザーに取得するデータを入力するよう求めています。ユースケースに基づいてデータを変更できます。 最初の CloudWatch カスタムウィジェットを作成するためのコメントの入力を開始します。このウィジェットでは、入力を要求し、出力として子犬の数を提供するコードを使用します。 # define custom widget to display lambda function CodeWhisperer の提案を使用して、カスタムウィジェットを作成する CDK コードを記述します。 # define custom widget to display lambda function my_custom_widget = aws_cloudwatch.CustomWidget( function_arn=lambda_function.function_arn, title="Hello, World!") CloudWatch のテキストウィジェットを作成するためのコメントの入力を開始します。 # define a text widget that displays "Hello World" CodeWhisperer の提案を利用しながら、テキストウィジェットのコードを完成させます。 # define a text widget that displays "Hello World" my_text_widget = aws_cloudwatch.TextWidget(markdown='# Hello World', width=6, height=2 ) assets フォルダのファイルをロードする S3 バケットを作成しましょう。 # define parameter for s3 bucket name s3_bucket_name = f'helloworld-{self.account}' s3_file_name = 'HelloWorld.html' # define s3 bucket with account id as suffix for hello world with no public access s3_bucket = aws_s3.Bucket(self, "S3Bucket", versioned=False, block_public_access=aws_s3.BlockPublicAccess.BLOCK_ALL, encryption=aws_s3.BucketEncryption.KMS_MANAGED, auto_delete_objects=True, removal_policy=RemovalPolicy.DESTROY, bucket_name=s3_bucket_name ) # define s3 bucket deployment to deploy files under assets folder aws_s3_deployment.BucketDeployment(self, "S3BucketDeployment", sources=[aws_s3_deployment.Source.asset("assets")], destination_bucket=s3_bucket ) S3 バケットからファイルを読み取る第 2 の Lambda 関数を作成しましょう。関連する IAM ロールも作成します。 # define IAM role for lambda that allows to read s3_file_name from s3 bucket with name s3_bucket_name s3GetObjectLambda_IAM_role = aws_iam.Role(self, "S3GetObjectLambda_IAM_role", assumed_by=aws_iam.ServicePrincipal("lambda.amazonaws.com"), inline_policies={ "S3GetObjectLambda_IAM_role_policy": aws_iam.PolicyDocument( statements=[ aws_iam.PolicyStatement( actions=["s3:GetObject"], effect=aws_iam.Effect.ALLOW, resources=[ f'arn:aws:s3:::{s3_bucket_name}/{s3_file_name}' ] ) ] ) } ) 2 つ目のカスタムウィジェットを作成しましょう。 # define s3GetObject custom widget to display s3GetObjectlambda_function s3GetObject_custom_widget = aws_cloudwatch.CustomWidget( function_arn=s3GetObjectlambda_function.function_arn, width=6, height=4) 次に、作成した 3 つのウィジェットをホストする CloudWatch ダッシュボードを作成します。コメントで CodeWhisperer に提案させることで、ダッシュボードのコードを作成します。 # define cloudwatch dashboard CodeWhisperer のコード提案が表示されたら、以前に作成したウィジェットを使用するダッシュボードのコードを完成させます。 # define CloudWatch dashboard dashboard = aws_cloudwatch.Dashboard( self, 'HelloWorldDashboard', dashboard_name='HelloWorldDashboard' ) 最後に、作成した 2 つのカスタムウィジェットと 1 つのテキストウィジェットをダッシュボードに追加します。 # add the 3 widgets to the dashboard dashboard.add_widgets(my_custom_widget) dashboard.add_widgets(my_text_widget) dashboard.add_widgets(s3GetObject_custom_widget) コードは次の例のようになるはずです。 from aws_cdk import ( Stack, Duration, aws_lambda, aws_cloudwatch, aws_s3, RemovalPolicy, aws_iam, aws_s3_deployment ) from constructs import Construct import os class Sample1Stack(Stack): def __init__(self, scope: Construct, construct_id: str, **kwargs) -&gt; None: super().__init__(scope, construct_id, **kwargs) cwd = os.getcwd() # define lambda function that has inline code lambda_function = aws_lambda.Function(self, 'HelloWorldFunction', code=aws_lambda.Code.from_inline( """ def lambda_handler(event, context): showme = event['widgetContext']['forms']['all'].get('petType') # create a 2D array for pets and count data = [['puppy','10'],['bunny','5'],['kitten','6']] rowdata = "" for row in data: if (showme and showme==row[0]): # assume only 2 elements in the data rowdata += f''' &lt;tr&gt; &lt;td&gt;{row[0]}&lt;/td&gt; &lt;td&gt;{row[1]}&lt;/td&gt; &lt;/tr&gt;''' response = f''' &lt;p&gt;Which pet do you want to see? valid inputs: puppy/bunny/kitten &lt;form&gt;&lt;input name="petType" value="{showme}" size="10"&gt;&lt;/form&gt; &lt;/p&gt; &lt;table&gt; &lt;tr&gt; &lt;th&gt;Pets&lt;/th&gt; &lt;th&gt;Count&lt;/th&gt; &lt;/tr&gt; {rowdata} &lt;/table&gt; &lt;a class="btn btn-primary"&gt;Run query&lt;/a&gt; &lt;cwdb-action action="call" endpoint="{context.invoked_function_arn}"&gt;&lt;/cwdb-action&gt; ''' return response """ ), # code=aws_lambda.Code.from_asset(os.path.join(cwd, "lambdafolder/package.zip")) description="CloudWatch Custom Widget sample: simple hello world", function_name=self.stack_name, handler='index.lambda_handler', memory_size=128, runtime=aws_lambda.Runtime.PYTHON_3_9, timeout=Duration.seconds(60) ) # define a CustomWidget that uses the Lambda function my_custom_widget = aws_cloudwatch.CustomWidget( function_arn=lambda_function.function_arn, title="Hello, World!") # define a text widget that displays "Hello World" my_text_widget = aws_cloudwatch.TextWidget(markdown='Hello World', width=6, height=2 ) # define parameter for s3 bucket name s3_bucket_name = f'helloworld-{self.account}' s3_file_name = 'HelloWorld.html' # define s3 bucket with account id as suffix for hello world with no public access s3_bucket = aws_s3.Bucket(self, "S3Bucket", versioned=False, block_public_access=aws_s3.BlockPublicAccess.BLOCK_ALL, encryption=aws_s3.BucketEncryption.KMS_MANAGED, auto_delete_objects=True, removal_policy=RemovalPolicy.DESTROY, bucket_name=s3_bucket_name ) # define s3 bucket deployment to deploy files under assets folder aws_s3_deployment.BucketDeployment(self, "S3BucketDeployment", sources=[aws_s3_deployment.Source.asset("assets")], destination_bucket=s3_bucket ) # define IAM role for lambda that allows to read s3_file_name from s3 bucket with name s3_bucket_name s3GetObjectLambda_IAM_role = aws_iam.Role(self, "S3GetObjectLambda_IAM_role", assumed_by=aws_iam.ServicePrincipal("lambda.amazonaws.com"), inline_policies={ "S3GetObjectLambda_IAM_role_policy": aws_iam.PolicyDocument( statements=[ aws_iam.PolicyStatement( actions=["s3:GetObject"], effect=aws_iam.Effect.ALLOW, resources=[ f'arn:aws:s3:::{s3_bucket_name}/{s3_file_name}' ] ) ] ) } ) # define lambda function S3GetObject s3GetObjectlambda_function = aws_lambda.Function(self, "S3GetObjectLambdaFunction", #inline code to read file from s3 bucket code=aws_lambda.Code.from_inline(""" import boto3 import json import os s3 = boto3.client('s3') def lambda_handler(event, context): #read environment variable S3_BUCKET_NAME bucket = os.environ['S3_BUCKET_NAME'] key = os.environ['S3_FILE_NAME'] response = s3.get_object(Bucket=bucket, Key=key) file_content = response['Body'].read().decode('utf-8') return file_content """ ), runtime=aws_lambda.Runtime.PYTHON_3_9, handler="index.lambda_handler", timeout=Duration.seconds(60), memory_size=128, description="Lambda function that reads file from S3 bucket and returns file content", # define IAM role for S3GetObject role=s3GetObjectLambda_IAM_role, #environment variables environment={ 'S3_BUCKET_NAME': s3_bucket_name, 'S3_FILE_NAME': s3_file_name }, # define function name as s3GetObject function_name=f's3GetObject-{self.stack_name}' ) # define s3GetObject custom widget to display s3GetObjectlambda_function s3GetObject_custom_widget = aws_cloudwatch.CustomWidget( function_arn=s3GetObjectlambda_function.function_arn, width=6, height=4, title="S3 Get Object" ) # define a CloudWatch dashboard dashboard = aws_cloudwatch.Dashboard( self, 'HelloWorldDashboard', dashboard_name='HelloWorldDashboard' ) # add the 3 widgets to the dashboard dashboard.add_widgets(my_custom_widget) dashboard.add_widgets(my_text_widget) dashboard.add_widgets(s3GetObject_custom_widget) コードを検証します。 Visual Studio Code のターミナルウィンドウで次のコマンドを実行します。 cdk ls コードをデプロイします。 Visual Studio Code のターミナルウィンドウで次のコマンドを実行します。 cdk deploy これで次のリソースがデプロイされているはずです。 2 つの Lambda 関数 3 つのウィジェットを持つ CloudWatch ダッシュボード 1 つのテキストウィジェット Lambda に接続された 2 つの CustomWidget S3 の HTML ファイルから読み取れる 1 つのカスタムウィジェット ユーザー入力を要求し、 Lambda から関連値を取得する 1 つのカスタムウィジェット 他のウィジェットの作成方法は こちら を参考にしてください。 環境の削除 今後課金されないようにするには、Visual Studio Code のターミナルウィンドウで次のコマンドを実行してリソースを削除します。 cdk destroy まとめ この投稿では、 Amazon CodeWhisperer を使用して CloudWatch ダッシュボードを作成する CDK コードを記述する方法を学びました。ご覧のとおり、 CodeWhisperer は開発者の生産性を向上させるだけでなく、より速く成果を出し、ソフトウェア開発を加速し、開発労力を削減する提案を行い、アイデア創出や複雑な問題解決のための時間を確保できるなど、多くのメリットがあります。詳細は CodeWhisperer のドキュメント をご覧ください。 本記事は、「 Leverage generative AI to create custom dashboard widgets in Amazon CloudWatch using Amazon CodeWhisperer 」を翻訳したものです。翻訳は ソリューションアーキテクト津郷が担当しました。

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

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

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

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

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

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

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