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

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

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

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

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

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

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

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

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

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

Amazon Pinpoint は、SMS やテキストメッセージング、E メール、モバイルプッシュ、音声、アプリ内メッセージングなどのコミュニケーションチャネルを利用して、アプリケーション開発者が顧客とエンゲージメントを取るのに役立つマルチチャネルコミュニケーションサービスです。 Amazon Pinpoint SMS は、Web、モバイル、ビジネスアプリケーションで SMS および音声メッセージングを提供するために必要なグローバル スケール、回復力、柔軟性を提供します。 SMS メッセージングは、ワンタイムパスコードの検証、タイムリーなアラート、双方向チャットなどのユースケースで、そのグローバルなリーチと普及性のために使用されます。 現在、Amazon Pinpoint SMS は 240 を超える国と地域にメッセージを送信しています。 ここでは、新しい Pinpoint SMS 管理コンソールを使用して、SMS リソースを正しく最初に設定する方法を確認します。 このブログでは、管理コンソールを使用した Pinpoint SMS のセットアップと構成の手順を説明します。 また、すべてのセットアップと構成は、 Pinpoint SMS API を使用して完了することもできます。 詳細については、Pinpoint SMS ドキュメント を参照するか、 Amazon Pinpoint SMS ワークショップ を完了してください。 Pinpoint SMS 管理コンソールは、 Pinpoint SMS API の既存の機能の制御を提供し、SMS および音声リソースを作成および管理することができます。 さらに、Pinpoint SMS コンソールには、セットアッププロセスをガイドし、SMS リソースをリクエストおよび管理するためのクイックスタート – SMS セットアップガイドまたは発信者リクエストフローがあります。 Amazon Pinpoint SMS を使用した SMS の動作についての背景が必要な場合は、 Amazon Pinpoint でのグローバル SMS 送信の管理方法 を参照してください。 以下は、このブログ投稿でポイントとなるいくつかの重要な SMS の概念です。 重要な SMS の概念とリソース 電話プール: 電話プールリソースは、すべて同じ設定を共有し、番号が利用できなくなった場合のフェイルオーバーを提供する電話番号と送信者 ID のコレクションです。 発信者: 発信者とは、電話番号または送信者 ID を指します。 電話番号: 発信者番号とも呼ばれ、電話番号は送信者を識別する数字の文字列です。これはロングコード、ショートコード、料金無料通話番号 (TFN)、10 桁のロングコード (10DLC) です。詳細については、 電話番号または送信者 ID の選択 を参照してください。 検証済みの宛先電話番号: アカウントがサンドボックスの場合、検証プロセスを経た電話番号にのみ SMS メッセージを送信できます。 その電話番号は検証コードが含まれる SMS メッセージを受信します。 受信したコードをコンソールに入力してプロセスを完了する必要があります。 シミュレーター電話番号: シミュレーター電話番号は、他の発信元および宛先電話番号と同じように動作しますが、SMS メッセージはモバイルキャリアには送信されません。 シミュレーター電話番号には登録が必要なく、テストシナリオに使用されます。 ※現状日本のシミュレーター番号はありません 送信者 ID: 発信者 ID とも呼ばれ、送信者 ID は送信者を識別するアルファベットと数字の文字列です。 詳細については、 電話番号または送信者 ID の選択 を参照してください。 登録済み電話番号: 一部の国では、電話番号や送信者 ID を購入する前に、会社のIDを登録する必要があります。 また、その国の受信者に送信するメッセージのレビューも必要です。 登録は外部の第三者によって処理されるため、電話番号のタイプと国によって登録処理にかかる時間が異なります。 必要なすべての登録が完了すると、電話番号のステータスがアクティブに変更され、使用できるようになります。 登録が必要な国の詳細については、 サポートされている国と地域 (SMS チャネル) を参照してください。 はじめに AWS 管理コンソールにサインインし、Amazon Pinpoint を検索します。 AWS アカウントをお持ちでない場合は、アカウントを作成するために次の 手順 に従ってください。 Amazon Pinpoint コンソールで、Amazon Pinpoint SMS と Amazon Pinpoint Campaign Orchestration のどちらを管理するかを選択できます。 Pinpoint SMS は、SMS 送信のために関連リソースを設定および構成するアプリケーション開発者がアクセスする場所です。Pinpoint Campaign Orchestration は、顧客セグメントを管理し、キャンペーンやマルチステップ ジャーニーを使用してメッセージを送信するビルダーを対象としています。 Pinpoint Campaign Orchestration は、Pinpoint SMS や Amazon SES (Simple Email Service) などのチャネルを利用してメッセージを配信します。 このブログでは、管理コンソールを使用した Pinpoint SMS の構成方法について説明します。 クイックスタート – SMS セットアップ ガイド Pinpoint SMS コンソールを選択すると、[概要] ページが表示されます。 このページには、SMS リソースの概要とクイックスタート – SMS セットアップ ガイドが表示されます。 このガイドでは、SMS メッセージの送信を開始するための適切な SMS リソースの作成を案内します。 クイックスタート ガイドに概説されている手順は推奨ですが、必須ではありません。 ステップ1: 電話プールの作成 電話プールは、同じ設定を共有し、番号が利用できなくなった場合のフェイルオーバーを提供する電話番号と送信者 ID のコレクションです。電話プールは、番号のレジリエンスを管理する利点があり、送信アプリケーションからの複雑さを取り除き、電話番号と送信者 ID を管理するための論理的なグルーピングを提供します。例えば、電話プールは、OTP (ワンタイムパスワード) メッセージのために使用するなど、ユースケースごとにグループ化できます。 ナビゲーションペインの [概要] で、[クイックスタート] セクションの [プールを作成] を選択します。[プールのセットアップ] セクションで、プール名にプールの名前を入力します。プールを作成するには、プールに関連付ける発信元 ID 、電話番号または送信者 ID を選択する必要があります。追加の発信元 ID は、プールが電話プールページで作成された後に追加できます。アカウントにアクティブな電話番号または送信者 ID がない場合は、テストに使用でき、登録は必要ないシミュレータ番号を選択することをお勧めします。発信元 ID を選択したら、[電話プールの作成]を選択してステップ1を完了できます。 ステップ2: 設定セットの作成 設定セットは、メッセージの送信時に適用されるルールのセットです。 例えば、設定セットは、メッセージに関連するイベントの宛先を指定できます。 SMS イベント(配信または失敗イベントなど)が発生すると、メッセージの送信時に指定した設定セットに関連付けられた宛先にルーティングされます。 メッセージの送信時に設定セットを使用する必要はありませんが、使用することをお勧めします。 SMS および音声イベントをAmazon CloudWatch、Amazon Kinesis Data Firehose、およびAmazon SNSに送信することをサポートしています。 ナビゲーションペインの [概要] で、[クイックスタート] セクションの [セットを作成] を選択します。 [設定セットの詳細] セクションで、設定セット名に名前を入力します。 [イベント送信先の設定] では、CloudWatch、Kinesis Data Firehose、および SNS を自動的に作成および構成してすべてのイベントを記録する CloudFormation スタックを作成する「クイックスタート」オプション、またはセットアップするイベント送信先を手動で選択する「詳細設定」オプションを選択します。 選択後、[作成]を選択してステップ2を完了します。 ステップ3: SMS 送信のテスト SMS シミュレータを使用してテストメッセージを送信します。 送信元を選択し、送信先の番号を選択します。 メッセージのステータスを追跡するには、SMS イベントを公開する設定セットを追加します。 ナビゲーションペインの [概要] で、[クイックスタート] セクションの [テストメッセージを送信] を選択します。 [発信者] セクションで、アカウントの電話プール、電話番号、または送信者 ID を選択します。 次に、[送信先番号] セクションで、テストメッセージを送信するシミュレーター番号またはアクティブな宛先番号を選択します。 アカウントがサンドボックスの場合、シミュレータ番号または検証済みの宛先番号にのみメッセージを送信できます。 アカウントが本番になると、シミュレータ番号または任意のアクティブな宛先番号にメッセージを送信できます。 SMS イベントを追跡するために、設定セットを選択できます。 次に、[メッセージ本文] セクションで、サンプルメッセージを入力してテストメッセージを送信します。 注意 – 米国のシミュレータ番号から送信している場合(または米国のシミュレータ番号のみが含まれる電話プールから送信している場合)、米国のシミュレータの宛先番号にのみメッセージを送信できます。 シミュレータの電話番号は、他の電話番号と同様に機能しますが、SMSメッセージはモバイルキャリアには送信されません。 ステップ4: 本番アクセスのリクエスト 最後に、アカウントが サンドボックスの場合、使用できる金額に制限があり、検証済みの宛先電話番号にのみ送信できます。 これらの制限を削除するには、サンドボックスから本番への移行をリクエストしてください。 本番に移行するには、 AWS Support Center  でケースを開きます。 まとめ 本番アクセスのリクエスト後、アカウント構成の設定を完了するために推奨されるステップを実行しました。 アカウントで次のリソースをテストおよび構成しました。 電話プール: 電話プールは、同じ設定を共有し、番号が利用できなくなった場合のフェイルオーバーを提供する電話番号と送信者 ID のコレクションです。電話プールは、番号のレジリエンスを管理する利点があり、送信アプリケーションからの複雑さを取り除き、電話番号と送信者 ID を管理するための論理的なグルーピングを提供します。 発信元: プールの設定の一環として、プールに少なくとも1つの発信元を関連付ける必要があります。発信元は、電話番号または送信者 ID を指します。シミュレータ番号を選択した場合は、新しい 電話番号  または送信者 ID をリクエストできます。 設定セット: 設定セットを使用すると、SMS イベントを整理、追跡、構成して、それらを公開する場所を指定できます。 次のステップ 管理コンソールの [リクエスト発信者] フローを使用して  発信元  の電話番号や送信者 ID などをリクエストできます。発信元がサポートされており、 登録  が必要な場合は、管理コンソールで電話番号または送信者 ID の登録を自動で行うことができます。 この記事は、 Simplify your SMS setup with the new Amazon Pinpoint SMS console を翻訳したものです。翻訳は Solution Architect の 中村 達也 が担当しました。

　本稿は、 関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みの第2回の前半となります。執行役員である松浦 康雄様より寄稿いただきました。前半、後半の 2 回に分けてご紹介いただきます。本稿は、その後半となります。前半については、 こちらのリンク からご確認ください。 　なお、第1回の寄稿については、「 寄稿：関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介 (前半) 」をご参照ください。 ４．システムアーキテクチャ 　次に、私たちが検討を進めている次世代スマートメーターシステムのアーキテクチャの概要をご紹介します。 　上述の開発方針に沿って疎結合アーキテクチャを実装するにあたって、サブシステム間の連携では疎結合を基本としています。具体的には、HES から MDMS 、そして MDMS からデータを一元管理するメーターデータ活用基盤へのサブシステム間連携においては、Amazon SQS を活用してシステム間を非同期に連携させながら、高い弾力性とリアルタイム性の高いデータ転送を同時実現できるよう設計しました。SQS をベースとした仕組みを構築することで、定期的に大量に発生する検針値や、停電や復電時に大量に送信されてくるイベント情報などをバッファリングしながら受信して、後続処理に高速に連携していくことができ、大量のバーストトラフィックに対して弾力性を保ったニアリアルタイムの処理が可能なアーキテクチャを組んでいます。 　また、疎結合アーキテクチャを基本とするサブシステム内では、マイクロサービスの活用を進めます。業務ロジックを見直して機能を細分化し、使用量計算や計器イベントの処理などは AWS Lambda などを活用、パッケージ的なアプリケーション実行環境は Amazon ECS, AWS Fargate をベースとしたコンテナ環境で実現、その上で、Amazon S3 や Amazon DynamoDB などと API 連携することで疎結合アーキテクチャを組み上げます。現在は制度が決まっていない将来的な新機能実装については、機能細分化されたサーバレスやコンテナを活用しながら柔軟かつ俊敏な開発を実現します。 　データベースのセキュリティやバージョンアップの対応に係る運用保守性の向上などを念頭に置いて、AWS マネージドサービスを中心に据えてシステムを組み上げる方針としており、これに伴い、S3 だけではなく、Amazon Aurora 、 Amazon KeySpaces、DynamoDB や Amazon RDS for PostgreSQL といったデータベースや、データ連携のための Amazon API Gateway など各種マネージドサービスを活用しています。 　スマートメーターシステムで収集された検針値データや設備情報などの将来的な高度利活用やその活性化に向けて、まずはメーターデータ活用基盤のデータストアにそれら情報を一元的に集約管理するとともに、これを起点としたデータ活用の仕組みを Lambda や API Gateway などを利用しながら先行開発します。データ利活用の高度化に向けては、このデータストアに Amazon QuickSight などを連携して手軽なデータ分析が可能な環境を整備するとともに、AI/ML サービスも試行錯誤の段階から活用して業務適用できるようにしていく計画です。 　図 6 に、私たちが開発を進めているシステムの全体概要を示します。 図 6 当社の次世代スマートメーターシステムのアーキテクチャ概要 ５．共通基盤の導入とシステム統制 　私たちの 15 年間に亘るスマートメーターの取り組みの中で、様々な課題に直面してきました。それらは例えば、システム間での機能重複や、複雑な連携方式など、データ利活用に際して柔軟性に欠ける課題や、システムベンダの独自 OS や商用データベース、ミドルウェア採用に伴う経済性や将来持続性の課題、システムのブラックボックス化や業務処理ロジックの隠匿化などの課題、更には半導体枯渇によるサーバハードウェア調達納期の遅延など、将来の不確実性も含めた課題というものでした。これらの課題は、一元的なシステムコンセプトのもとでの開発ができなかったことが根源的な要因だと考えており、今回は自らの開発コンセプトを入れ込むことを重視しています。 　そのためには私たちが今回開発プラットフォームとする AWS クラウド上のシステム基盤を正しく理解する必要があります。つまり、アプリケーションレイヤから、それを支えるインフラレイヤまで、すべてをシステムベンダに任せてシステム開発するのではなく、今回は、クラウドのインフラレイヤと、その上のアプリケーション用の AWS アカウント管理からネットワーク機能、セキュリティ対策など、システム全体に係る共通的な機能を「共通基盤」として整理したうえで、私たちが管理することでアプリケーションレイヤの開発方向性を含めて全体統制することとしました。私たちがインフラレイヤを正しく理解し、深層まで把握することで、これを基盤とするアプリケーションの開発についても、システムベンダとしっかり連携して協調しながら進めることができると考えています。システムベンダにとっても、業務に紐付くアプリケーション開発により注力することができるようになるため、結果としてこれまで以上のシステム品質確保が可能になり、将来的なデータ利活用にも確かな道筋を手に入れることができるものと考えています。 　私たちがクラウドのインフラレイヤを正しく理解して所管し、将来的なデータ利活用まで手の内化していくための取り組みのポイントが三つあります。 　一つ目は、AWS のマルチアカウント戦略に基づいて、AWS アカウントを分割することです。これによって責任範囲を明確化するとともに、セキュリティ面の強化を図ります。具体的には、共通基盤は私たちが管理した上でシステムベンダごとに AWS アカウントを分割し、ベンダにはアカウント内でシステム構築や保守を実施いただきます。また、システム間の接続点は最小化し責任分界点を明確化します。必要なユーザ ID も、共通基盤側から提供します。これを、AWS のマルチアカウント戦略(*2)の考え方の元、整理したものが、図 7 となります。 (*2) Organizing Your AWS Environment Using Multiple Accounts 　このように、本番、試験、開発という環境を分離して整備するとともに、各環境内において共通基盤やサブシステムごとの責任分解を AWS アカウントにより明確に分割しています。これにより、システムベンダは付与されたアカウント内においてアプリケーションシステムの開発に注力し、システムの運用保守も担当いただきます。 図 7 AWS アカウントのシステム間分割による責任範囲の明確化とセキュリティ強化 二つ目は、AWS の責任共有モデルをベースに、AWS とシステムベンダ、および私たちの責任範囲を明確にすることです。これに伴い、OS など標準化が必要なものは共通基盤として私たちが管理してベンダに提供します。OS 種別やバージョンに係るシステムごとのバラツキをなくすことができ、TCO 削減にもつながります。具体イメージは、図 8 となります。 図 8 共通的なインフラ機能の一元管理 　三つ目は、 AWS Professional Services の協力を得ることです。クラウドのフル活用を実現するためには、共通基盤の導入が必要不可欠であり、その上でシステムベンダ各社との協力をより緊密にしていくことが重要だと考えています。これには、私たちが当事者としてシステムを正しく理解して、環境変化に伴うシステムの拡張や変更に着実に対応していくことが求められ、つまりは私たちが AWS を正しく理解することが必須であり、AWS Professional Services の協力を得て検討やスキル・知見の獲得を加速しています。AWS Professional Services のメンバーと随時協調を取りながら、多岐にわたる技術課題を適切に理解し柔軟かつ的確に課題解決を図りつつ、プロジェクト推進にかかる PMO のサポートや私たちのメンバーの教育支援など、包括的な支援をうけることで、システム開発を加速させて取り組みを進めています。 6．おわりに 　今回の寄稿では、AWS を活用する次世代スマートメーターシステムについて、技術的な観点も交えて取り組み状況をご紹介しました。次回は現行スマートメーターシステムのクラウドシフトについてご紹介したいと考えています。 執筆者 松浦　康雄 関西電力送配電株式会社 執行役員（配電部、情報技術部） 2000 年代初期より、次世代配電網に適用する通信メディアの技術開発に携わり、 2010 年よりスマートメーターシステムの開発・導入プロジェクトを担当。 この経験を踏まえ、 CIGRE （国際大電力会議）にてスマートメーターのデータ利活用に関するワーキンググループを立ち上げて報告書をまとめるなど、スマートメーターシステムの全体像からデータ利活用にかかる論点を国内外の場で調査・発表し、脱炭素社会の実現、レジリエンス向上や効率化の実現に欠かすことのできない重要なキーデバイスとして、日本におけるスマートメーターの認知度向上に貢献。 2020 年には、資源エネルギー庁の声掛けのもと再開された次世代スマートメーター制度検討会に委員として参画し、次世代スマートメーターに求められる構造、機能や性能などについて、現行スマートメーター導入の経験や諸外国調査の知見を活かして議論をけん引。 2022 年度には、同社の現行スマートメーター全数導入を成し遂げるとともに、データプラットフォームとなり得る次世代スマートメーターシステム構想を描き、同社における検討を推進。 現在に至る。

　本稿は、 関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みの第2回の前半となります。執行役員である松浦 康雄様より寄稿いただきました。前半、後半の 2 回に分けてご紹介いただきます。本稿は、その前半となります。 　なお、第1回の寄稿については、「 寄稿：関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介 (前半) 」をご参照ください。 １．はじめに 　本稿では、三部構成で当社の取り組みを紹介します。第１回では、当社スマートメーターシステムにおけるクラウド活用に向けた議論の全体像をご紹介しました。今回は、AWS を活用した次世代スマートメーターシステムの全体像について、技術的な観点も交えて私たちの現在の取り組み状況をご紹介します。 (図 1) 図 1 スマートメーターシステムと本稿における説明対象範囲 ２．次世代システムの要件 　当社では次世代スマートメーターシステムの開発にあたり、15 年間に亘る現行スマートメーターシステムの開発や維持運用の経験、次世代スマートメーター制度検討会の取りまとめ内容や社外ニーズ、および最新技術動向を踏まえ、開発コンセプトを社内で議論しました。 　現行システムを開発した 15 年前は基本がオンプレミス環境であり、アプリケーションは私たちの観点での開発を行うものの、機能配置やシステム間連携方法などのアーキテクチャは、システム毎に異なるベンダに依存することになり、ベンダ間調整によりシステム全体を構築しました。つまり、私たちのコンセプトに基づく一元的なシステム開発は不可能で、その結果、システム間での機能重複や複雑なシステム間連携があり、結果として柔軟なデータ活用に制約が生じていました。 　次世代スマートメーター制度検討会では、再生可能エネルギーのコスト低下やエネルギーマネジメントの高度化、レジリエンス強化に対する関心の高まり、更には 2050 年カーボンニュートラル宣言等を背景とした分散型エネルギーリソースの導入拡大の進展がこれまで以上に期待されるようになってきていることが指摘されました。それらの結果、分散化・多層化を志向する次世代配電プラットフォームにおいて、データを活用した電力ネットワークの運用の高度化、電力分野以外への電力データの利用拡大、需要側リソースの拡大に伴う取引ニーズの多様化などへの対応を目的として、新仕様スマートメーターシステムへのアップグレードの必要性が取りまとめられております。 　私たちは社内外の環境変化を踏まえ、2023 年 8 月に関西電力送配電グループビジョンを制定し、関西一円のネットワーク設備、人財と技術、お客さまや社会の皆さまとのつながりといった送配電グループが有するプラットフォームを深化・拡大させることで、電気の安定供給のみならず、お客さまや社会に新たな価値を提供するエネルギープラットフォーマーへ進化し続けたいという考えを公表しました。そのキーとなるツールが、スマートメーターやそのデータを活用するためのシステムであると考えています。 　これらの背景のもと、次世代スマートメーターシステムの基本コンセプトは、「データの一元管理」、「類似機能の統廃合」、「相互影響しにくい疎結合な機能配置」であると考え、スマートメーターシステムに接続する周辺システムの更新計画、現行スマートメーターシステムから次世代システムへの円滑な移行等も踏まえ、将来にわたって柔軟かつ効率的な運用が可能なシステムを、シンプルかつ低コストに実現することも併せてコンセプトとして謳い、RFP を実施しました。より端的に表現すると、システムには、徹底的な拡張性や機能開発への柔軟性、および可用性を求め、今後想定される現行システムの移行や、スマートメーターへの機能追加要望、現行と次世代のシステム混在期の円滑な業務運用の実現、更にはスマートメーターシステムと周辺システムとの連携を推進し、再生可能エネルギーの導入拡大やレジリエンスの強化、およびお客さまの多様なニーズへの着実な対応にもつなげていきたいと考えています。 　これまで 15 年間のスマートメーターシステムの開発と運用の経験を踏まえると、当社が目指す姿の実現のためには、システム開発の考え方を抜本的に見直す必要があると考えました。実績のある従来の技術を継続採用することでリスク軽減が図れることは理解しながらも、私たちは新しい技術を正しく評価し、リスクコントールをしながら活用する方向性があると認識し、今回構築する全てのシステムを、AWS のクラウド上に実装するとともに、できる限り AWS サービスを利用することが望ましいと考え、開発に着手しております。その具体的な考えを、次章以降で記載いたします。 ３．次世代スマートメーターシステム開発方針 　前章で紹介した通り、次世代スマートメーターシステムでは、メーターの収容数や処理負荷増大に対する拡張性、現時点では未確定の将来の制度への対応などを見据え、新機能開発に係る実装の柔軟性とその俊敏性、送配電事業のレジリエンスを支える本システムの可用性を、将来にわたって高度に実現していくことが求められています。 　従来のモノリシックシステムアーキテクチャの考え方を踏襲した場合、スケールアップや機能追加、改修において、サイジングや一体的な機能開発などに多くの時間を要し、対応の柔軟性や俊敏性に制約が生じる傾向にあります。今回私たちは、品質を確保しながら柔軟なシステム開発の実現を志向するモダンアプリケーション開発手法によるアプローチを選択しました。モダンアプリケーションという考え方における重要な構成要素である、マイクロサービスやコンテナを用いてアプリケーションをより小さな機能単位にモジュール化して分割することで、システムとしての拡張性や将来機能実装への高い柔軟性、俊敏性を実現します。また、疎結合アーキテクチャを適切に取り込むことで、作業や障害時における影響範囲を限定し、システム全体としての可用性を高める仕組みとします ( 図 2) 。 図 2 当社のスマートメーターシステムにおける疎結合化の実現イメージ 　サブシステム内においては、疎結合化と拡張性の担保に留意しています。具体的には例えば、データベースや S3 にデータを配置し、データ授受は API 連携を基本とするとともに、データイベントをトリガーとしたイベント駆動型の仕組みを採用して非同期な機能間連携を実現します。これによって、次世代スマートメーターシステムのような大規模で複雑なシステムにおいても、耐障害性、スケーラビリティ、柔軟性の同時実現が図れます( 図 3)。 図 3 イベント駆動型アーキテクチャの特長 　また、システム開発時において、システムベンダがアプリケーション開発に注力できるようサーバレスやコンテナを積極的に活用するとともに、データベースをはじめインフラ周りは、システムベンダが個別構築するのではなく AWS マネージドサービスの利用を基本原則としました。 AWS の各種マネージドサービスを活用することで、拡張性やセキュリティ対応を AWS サービスで担保させながら、データベース等に係るシステムの維持運用を AWS にオフロードすることで当社側の業務負荷の軽減も狙っており、クラウドメリットを最大限享受する方向性としています( 図 4)。 図 4 AWS マネージドサービス活用によるメリット 　さらに、AWS クラウドにデータを一元的に集約管理することで、そのデータレイクを中心としてデータアナリティクスサービスや拡大を続ける AI/ML サービスなど AWS の最先端技術を活用し、将来に亘る高度なデータ利活用に向けた道筋を具現化していきます。AWS の分析サービスを活用することで、要件定義や設計、構築などのステップを踏まずに、ニーズが発生した初期段階から、すぐ簡単に手軽に試行錯誤しながら有用性や方向性を見極めていくことができます。メーターデータ分析の活用事例については AWS でも紹介されており（ *1、図 5 ）、これらも参考に最先端技術を「必要な時に、いつでも、手軽に」使って、データ分析やデータ利活用に取り組めるように進めて参ります。 (*1) https://aws.amazon.com/jp/solutions/guidance/meter-data-analytics-on-aws/ 図 5 メーターデータ分析に係る AWS のソリューション事例 　このような検討背景を踏まえて、当社のシステム開発方針は以下のとおり策定しました。 疎結合アーキテクチャによる拡張性とシステム開発に対する柔軟性、高い可用性の実現 マネージドサービス活用によるスケーラビリティや俊敏性、運用最適化の実現 スマートメーターデータを分析し利活用するための AWS のデータ分析サービスの活用 　当社のシステム開発方針をシステムベンダ各社と共有しながら、AWS クラウド上での次世代スマートメーターシステムの開発を進めています。 　本稿では、当社のスマートメーターシステムのクラウド採用に向けた取り組みについて、「３．次世代スマートメーターシステム開発方針まで」をご紹介致しました。後半については、「 寄稿：関西電力送配電株式会社におけるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介(第2回) – 後半 」をご参照ください。 執筆者 松浦　康雄 関西電力送配電株式会社 執行役員（配電部、情報技術部） 2000 年代初期より、次世代配電網に適用する通信メディアの技術開発に携わり、 2010 年よりスマートメーターシステムの開発・導入プロジェクトを担当。 この経験を踏まえ、 CIGRE （国際大電力会議）にてスマートメーターのデータ利活用に関するワーキンググループを立ち上げて報告書をまとめるなど、スマートメーターシステムの全体像からデータ利活用にかかる論点を国内外の場で調査・発表し、脱炭素社会の実現、レジリエンス向上や効率化の実現に欠かすことのできない重要なキーデバイスとして、日本におけるスマートメーターの認知度向上に貢献。 2020 年には、資源エネルギー庁の声掛けのもと再開された次世代スマートメーター制度検討会に委員として参画し、次世代スマートメーターに求められる構造、機能や性能などについて、現行スマートメーター導入の経験や諸外国調査の知見を活かして議論をけん引。 2022 年度には、同社の現行スマートメーター全数導入を成し遂げるとともに、データプラットフォームとなり得る次世代スマートメーターシステム構想を描き、同社における検討を推進。 現在に至る。

このブログは Neil Salamack（Senior Product Marketing Manager）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 11 月 27 日から 12 月 1 日にかけて、 AWS re:Invent 2023 がネバダ州のラスベガスで開催されます。AWS re:Invent はクラウド愛好家や専門家、初学者に対して他にない体験を提供します。あなたは、企業を変革する生産的なソリューションを見つけるための 5 日間の機会と、新しいスキルを素早く習得するための 2000 を超えるセッションに参加できます。また、このイベントでは、あなたのキャリアやビジネスにとって次の大きなステップとなりうる繋がりを築くための 100 を超える方法が用意されています。 re:Invent ではインフラストラクチャを最適化するための AWS ファイルストレージサービスについて、学習する機会が多く含まれています。このブログでは、AWS ファイルストレージに関する全てのセッションをリスト化し、セッション選択と予約を手助けします。これらのセッションは満席になりつつありますので、必ず「座席の予約はこちら」と書かれたリンクをクリックし、席を確保してください。また、興味のあるセッションについてはお気に入りに登録することもできます。カタログページにて表示されるセッション情報には、星のアイコンが表示されます。こちらを選択することで、お気に入りとしてマークすることができます。お気に入りから外す場合は、もう一度星のアイコンを選択してください。それでは、re:Invent に参加しながら AWS ファイルストレージに関連する知識を最大化するための 3 つの簡単なステップを見ていきましょう。 STEP 1 – 基調講演や Innovation Talk に参加し、全体像を把握しましょう 毎年 re:Invent の基調講演では、最も重要な発表が行われます。基調講演に参加することで、あなたの構築するアプリケーションやビジネスの強化に役に立つ、クラウドの状況を変えるようなニュースや製品発表を聞くことができます。 re:Invent の Web サイト から基調講演や Innovation Talk のリストを確認し、スケジュールに追加してください。 まずは、AWS の著名なエンジニアである Andy Warfield のセッションです。このセッションでは、AWS のストレージに関する最新のイノベーションと、社内において洞察と革新を加速するためのアジャイルで弾力性を備えたデータ基盤を構築する方法やその視点を紹介します。AWS の高性能なストレージを使用してデータアクセスを高速化し、データレイクを簡素化、 AI/ML 機能を強化することで、組織がどのように競争上の優位性を向上させているかご覧ください。Andy は、データドリブンなビジネスの裏側で、セキュリティ、ガバナンス、分析、アプリケーション開発をサポートする AWS ストレージサービスがどのように機能しているのか、重要なポイントを紹介します。 Andy Warfield, AWS の Vice President で著名なエンジニア STG227-INT: AWS ストレージ : The backbone for your data-driven business – Innovation Talk （データドリブンビジネスの裏側） 11 月 28 日（火）2:00 PM – 3:00 PM PST（日本時刻：29 日 7:00 AM – 8:00 AM） 加えて、AWS ストレージチームは 11 月 30 日（木）12:30 PM – 1:30 PM PST（日本時刻：1 日 5:30 AM – 6:30 AM）に開催される Innovation Talk の「Putting your data to work with generative AI（あなたのデータを生成系 AI で活用する）」への参加を推奨しております。AWS の Vice President, Technology である Mai-Lan Tomsen Bukovec と一緒に、生成系 AI によってデータレイクをビジネスアドバンテージに繋げる方法を学びましょう。独自の生成系 AI ソリューションを構築する際に、独自データセットを活用するための戦略をご覧ください。具体的には、Amazon SageMaker、Amazon Bedrock、および PyTorch などの一般的なフレームワークと、AWS のコンピューティング、ストレージ、分析サービスを使用して、データセットを活用する方法を学びます。そして、非構造化データ（映像、画像、PDF）、半構造化データ（Parquet）、テーブルフォーマットデータ（Iceberg）を機械学習トレーニングやファインチューニング、チェックポインティング、プロンプトエンジニアリングに使用するためのベストプラクティスを紹介します。またビジネスデータを、カスタマイズされた生成系 AI ソリューションに取り込むための、顧客が現在使用しているアーキテクチャについてもお話しします。 Mai-Lan Tomsen Bukovec, AWS の Vice President, Technology AIM250-INT Putting your data to work with generative AI – Innovation Talk （あなたのデータを生成系 AI で活用する） 11 月 30 日（木）12:30 PM – 1:30 PM PST（日本時刻：1 日 5:30 AM – 6:30 AM） STEP 2 – AWS ファイルストレージセッションを予約しましょう AWS re:Invent では、基調講演形式の Breakout session、インタラクティブ形式の Chalk talk、ハンズオン形式の Workshop、Builders session 等様々なタイプのセッションに参加ができます。 Breakout Sessions AWS re:Invent の Breakout session は 1 時間の講義形式です。このようなセッションは会場全体で行われ、すべてのレベル（200 – 400）の全てのトピックを網羅します。またバーチャル参加者向けに、Breakout session はオンデマンド形式で配信される予定です。 STG311 | AWS storage for serverless application development （サーバレスアプリケーション開発向けの AWS ストレージ） サーバーレスなイベント駆動型コンピューティングサービスにより、サーバーをプロビジョニングしたり管理することなく、事実上あらゆる種類のアプリケーションやバックエンドサービスのコードを実行できます。このセッションでは、Amazon EFS や Amazon S3 などの AWS ストレージサービス全体を紹介し、一般的なワークフローを掘り下げて、どのストレージサービスが自身のワークロードに適しているかを判断できるようにします。AWS ストレージが、大規模にスケールし、分析ワークロードをアジャイルに実行し、総所有コストを削減するようなアプリケーションの構築に、どのように役立つかを考えてみましょう。 座席の予約はこちら STG212 | Accelerate generative AI and ML workloads with AWS storage（AWS ストレージで生成系 AI とML ワークロードを加速する） 最近の AI と機械学習技術の進歩に加え、様々な業界で AI を利活用する動きが市場主導により進んだ結果、多くの IT 組織で 新たなストレージが求められています。このセッションでは、さまざまな AI/ML サービスと統合可能で高性能かつスケーラブルな AWS のストレージが、機械学習ワークロードを構成し、イノベーションを加速させる方法を学びます。 座席の予約はこちら STG338 | Scale analytics and SaaS applications with serverless elastic storage（サーバレスで弾力性のあるストレージを使用し、分析・SaaS アプリケーションをスケーリング） クラウドネイティブなアプリケーションのデプロイやスケーリングを望む開発者やアナリスト、データサイエンティストは、クラウドリソースを通してデータを共有する必要があります。Amazon EFS はサーバレスでスケーラブルなストレージを提供し、高い IOPS パフォーマンス、低レイテンシー、スループットの自動増減を実現するように設計されています。このセッションでは、データを共有し共同作業をする方法、簡単にスケールできる SaaS アプリケーションを構築する方法、ストレージの俊敏性を高めて分析ワークロードを実行する方法、アクティブ、非アクティブなデータが混在する状況で全体的な保管コストを削減する方法を学びます。 座席の予約はこちら STG209 | Network-attached storage in the cloud with Amazon FSx（Amazon FSx によるクラウド内でのネットワーク接続型ストレージ） 規模が大きい状況で、パフォーマンスや可用性に悪影響を与えずファイルベースのワークロードをクラウドに移行することは、困難になるケースがあります。Amazon FSx ファミリーは、このようなネットワーク接続ストレージ （NAS）の課題に対応でき、フルマネージドサービスとしてアプリケーションやコードを変更することなく、共有ストレージ、耐障害性、管理互換性を実現します。このセッションでは、メディアエンターテイメント、教育、ヘルスケア、ライフサイエンス、通信分野の専門家によるユースケースを交えながら、俊敏性の向上、コスト削減、自動的なスケーリング方法について紹介します。このセッションに参加することで、自信を持って移行プランを作成できるようになります。 座席の予約はこちら STG340 | Accelerate ML and HPC with high performance file storage（高性能なファイルストレージで ML や HPC の活用を加速する） 負荷の高いワークロードを高速化することは、機械学習（ML）トレーニングの高速化や、より多くの HPC ジョブを短時間で完了できるようになるなどのメリットをもたらします。Amazon FSx for Lustre は、ML、EDA、金融モデリング、天気予報、ビデオレンダリングとトランスコーディングなど、要求の厳しい HPC ワークロードを高速化します。このセッションでは、ミリ秒以内のレイテンシー、最大数百 GB/s のスループット、数百万の IOPS を提供する共有ストレージ Amazon FSx for Lusture が、コンピューティングワークロードを高速化し、あらゆる規模の企業でどのように採用されているかをお話しします。大規模な稼働が可能で、数回クリックするだけで簡単に構成できるフルマネージド型の Lustre サービスの利点についても説明します。 座席の予約はこちら STG219 | What’s new with AWS file storage（AWS ファイルストレージの最新情報） AWS は様々な種類のフルマネージドなストレージサービスを提供しています。共有ファイルストレージである Amazon EFS や Amazon FSx はほぼすべてのアプリケーションをサポートしているため、特定のユースケース、求められるパフォーマンス、アプリケーションやワークフローとの互換性に基づいて、最適なサービスを選択できます。このセッションに参加して、ファイルストレージの最新情報を聞き、機能豊富でパフォーマンスの高いファイルストレージへの移行・実行・拡張に関する実践的なヒントを学んでください。 座席の予約はこちら STG341 | Meet performance demands for your business-critical applications（ビジネスクリティカルなアプリケーションのパフォーマンス要求を満たす） あらゆる業界の組織には、オンプレミスにありながらもクラウド移行の候補となっている、本番環境レベルのアプリケーションがあります。これまで、性能が高くフル機能を持ったファイルシステムを、クラウドにて見つけるのは困難でした。汎用的なクラウドにおける選択肢は魅力的に見えますが、複雑であり、エンタープライズクラスの機能を持たない傾向もあります。一方で、AWS のファイルストレージは、クラウド移行の促進、効率化によるコスト削減、ビジネスクリティカルなワークロードのモダナイズに役立ちます。このセッションに参加し、VMware などの環境、SAP HANA、Oracle Database/Oracle RAC、Microsoft SQL Server などのデータベース移行に関する専門家のアドバイスを受けましょう。また、メディアエンターテイメント、金融、ヘルスケア等の業界固有の基幹業務ユースケースについても聞くことができます。 座席の予約はこちら Chalk talks Chalk talk は少ない参加者で、非常にインタラクティブに行われるセッション形式です。AWS の専門家による簡単な講義で始まり、続いて参加者との Q&A が行われます。 STG343 | Powering compute-heavy workloads with burst-to-cloud storage（クラウドへのバーストストレージで計算量の大きいワークロードを強化） 高いパフォーマンスが要求される、スパイクのあるワークロードや予測不可能なワークロードがありますか？アプリケーションの高速化やリソース拡張をすぐに実行しなければならないのに、オンプレミスのコンピューティングリソースでは不十分ではありませんか？この Chalk talk に参加して、AWS ファイルストレージを用いたハイブリッドクラウド戦略を採用することにより、データの保存場所に依らないファイルデータをより迅速かつ簡単に処理する方法を話し合いましょう。スケーラブルなパフォーマンス、高速ファイルキャッシュなどの機能が、分散型機械学習トレーニング、メディアレンダリングとトランスコーディング、電子設計自動化（EDA）、ビッグデータ分析などのワークロードに柔軟性をもたらす方法をご覧ください。 座席の予約はこちら STG402 | Boost performance and run compute-intensive workloads at scale（パフォーマンスを向上させ、コンピュート負荷の高いワークロードを大規模に実行） Amazon FSx はクラウドで実行されるパフォーマンスに敏感なワークロードの一部を強化します。AWS ファイルストレージサービスを使用することで、継続的なパフォーマンスの向上と最適化を実施できます。この Chalk talk では、参加者のパフォーマンスに関する質問に答え、データ使用量を最適化するベストプラクティスを提供します。パフォーマンスモードについて詳しく学習し、IOPS の向上、スループットの最適化、レイテンシーの最小化する方法に関するガイダンスを受けることができます。 座席の予約はこちら STG221 | How to match your workload with the right file storage（ワークロードから適切なファイルストレージを選択する方法） ストレージはアプリケーション導入を成功させるための土台です。一方、適切なファイルシステムの選択は、そのシステムが既に使用しているものや使い慣れたものとどの程度一致するかという観点から検討が始まります。ワークロードに適したクラウドファイルサービスをどのように選択しますか？この Chalk talk では、ファイルシステムの機能とユースケースをより適切にマッチさせるための意思決定プロセスについて説明します。AWS の専門家と相談して、Amazon EFS と Amazon FSx ファミリー、どのファイルサービスを選択するかを決定しましょう。複雑さやコストを抑えた拡張・移行に役立つ情報を入手してください。 座席の予約はこちら STG344 | How to protect unstructured files to achieve data resiliency（非構造化ファイルを保護し、データの耐障害性を高める方法） データ量の増加の管理は容易ではありません。近年生成されるデータのほとんどは、非構造化ファイルで構成されています。大規模から小さなファイルまで存在し、それらは NAS システム、Unix サーバー、Windows サーバー、およびクラウドに保存されます。一方で、非構造化ファイルには、データ保護とコンプライアンス要件を満たす必要のある機密データが含まれていることが多く、独特な課題があります。データを保護し、安全に保つための方法を知っていますか？この Chalk talk に参加して、Amazon FSx ファミリーと Amazon EFS のファイルストレージを使用した、クラウドにおいてファイルベースのアプリケーションを安全に実行するためのヒントとツールについて話し合ってください。 座席の予約はこちら STG342 | Build and run analytics and SaaS applications at scale（分析や SaaS アプリケーションを大規模に構築して実行する） 分析ワークロードを強化し、スケーラブルなパフォーマンスを持った SaaS（Software as a Service）アプリケーションを構築するにはどうすれば良いでしょうか？Amazon EFS を使用することで、容量やパフォーマンスのプロビジョニングや管理が不要で弾力性のあるファイルストレージにより、データの分析や共有が可能になり、SaaS アプリケーションの開発とデータ分析のワークロードを加速できます。この Chalk talk に参加して、ファイルワークロードにおける予測不可能なパフォーマンスニーズをサポートする方法を学び、ワークロードに必要な一貫性を習得してください。 座席の予約はこちら STG223 | Lower your TCO of storing data for large file datasets（大きなファイルデータセットを保存する際の TCO 削減） パフォーマンスの最適化、容量のプロビジョニング、またデータ階層化の管理を行う適切なタイミングはいつですか？管理を複雑にせず、データの可用性、耐久性、保護を実現したいとお考えですか？この Chalk talk に参加して、必要な時にすぐ利用できる実質的に無制限なファイルストレージを使用して、データの価値を最大化する方法を探りましょう。Amazon EFS がパフォーマンスとストレージ容量、両方の観点でどのように柔軟にスケーリングされ、高いスケーラビリティを備えているかをご覧ください。データを大規模に活用して価値を最大化し、総所有コスト（TCO）を低く抑える方法をご紹介します。 座席の予約はこちら Workshops Workshop は、2 時間のハンズオンセッションで、チームに分かれて AWS のサービスを使用した問題解決を行います。Workshop では、参加者を小グループにまとめ、交流を促すシナリオを提示します。これにより、互いに学びを得る機会が得られます。 STG316 | Increase your database agility with Amazon FSx（Amazon FSx を使用して、データベースのアジリティを高める） SQL Server、PostgreSQL、Oracle、SAP HANA などのデータベースをクラウドに移行することは、お客様のクラウドジャーニーにおける大切な部分です。この Workshop では、Amazon FSx を使用して Amazon EC2 上にセルフマネージドデータベースを構築、実際に SQL Server、PostgreSQL、MySQL を使用してみます。Amazon FSx の高度なスナップショット、クローニング、バックアップ、およびレプリケーション機能により、RPO や RTO を数時間から数秒にまで短縮する方法をご覧ください。加えて運用だけでなく、追加の容量が不要なクローニングを使用して、開発者にデータベースのコピーを即座に提供することで、開発と更新のサイクルを短縮する方法のデモンストレーションをご覧いただきます。参加する場合はラップトップを持参してください。 座席の予約はこちら STG403 | Get insights faster: Accelerate your Amazon S3 data lake（Amazon S3 のデータレイクを加速しより早く洞察を得る） Amazon FSx for Lustre を使用することで、Amazon S3 に保存されたデータセットの取得が高速化され、より迅速に洞察を得ることができます。Amazon FSx for Lustre は Amazon S3 と統合されているため、高性能ファイルシステムから Amazon S3 のデータにアクセスして処理することができます。この Workshop では、ミリ秒未満のレイテンシーで大規模な S3 ワークロードを処理する方法を学びます。Amazon FSx for Lustre ファイルシステムを作成し、それを S3 バケットにリンク、Amazon EC2 クラスターを起動して、Amazon FSx for Lustre ファイルシステムをマウントします。Amazon FSx for Lustre が S3 オブジェクトをファイルとして Amazon EC2 インスタンスに表示し、大規模なファイルシステムでスケールアウト可能な高速スループットと高い IOPS を実現する方法をご覧ください。参加する場合はラップトップを持参してください。 座席の予約はこちら Builders sessions Builders session は 60 分間の小さなグループセッションです。1 テーブルにつき最大 6 人の参加者で、1 人の AWS エキスパートが質問に答えガイダンスを提供します。参加者はあなたと AWS エキスパート、そしてラップトップだけです。 STG405 | Rightsizing VMware Cloud compute and storage（VMware Cloudにおけるコンピュートとストレージのライトサイジング） VMware Cloud on AWS の運用が加速するにつれて、組織はストレージを大量に消費するワークロードに合わせて拡張する必要性を認識しています。この Builders session で、クラウドコンピューティングとは別にクラウドストレージを拡張することで、コストを削減および管理する方法を理解してください。TCO を削減し、Amazon FSx for NetApp ONTAP を VMware Cloud on AWS で実行されているワークロードへ補完的なデータストアとして統合する方法をご覧ください。参加する場合はラップトップを持参してください。 座席の予約はこちら STEP 3 – AWS Expo の AWS ストレージキオスクに訪問しましょう Expo には学習と交流の機会が多くあります。AWS Village に立ち寄って、製品、サービス、ソリューションについて掘り下げてみましょう。AWS ストレージキオスクでは、あらゆる分野（ファイル・ブロック・オブジェクト）の AWS ストレージ専門家が常駐しています。弊社のアーキテクトが、お客様の質問や課題に対して、ワークロードに最適なアプローチを提供できるようにお手伝いします。 今すぐ登録を！ 今年の re:Invent は、素晴らしく有益になること間違いなしです。まだ登録していない場合は、 こちら から今すぐ登録してください。ラスベガスでお会いしましょう！ 翻訳はソリューションアーキテクトの吉澤が担当しました。

このブログ記事は、Microsoft SQL Server のライセンスに関する推奨を生成する AWS Compute Optimizer の新しい機能について説明します。 AWS Compute Optimizer は、 Amazon Elastic Compute Cloud (Amazon EC2) 上で Microsoft SQL Server を実行しているお客様にライセンスコストの最適化を提案する機能があり、それによって大きなライセンスコストの削減効果を得ることが出来ます。 AWS Compute Optimizer は、 推定ワークロードタイプ を活用して SQL Server が Amazon EC2 インスタンス上で実行されているかどうかを検出します。そして、SQL Server Enterprise エディションの機能が使用されているかどうかを検出し、SQL Server Standard エディションへのダウングレードのオプションがあることを提示することで、ライセンスコストの削減を推奨します。 パフォーマンスと SQL Server ライセンスの最適化における課題への対応 データベース管理者（DBA）は、Amazon EC2 インスタンス上の SQL Server を最適化する簡単な方法を探しています。データベースのパフォーマンスへのニーズは頻繁に変化する為、ハードウェア要件、機能、設定に違いが発生してきます。それにより、お客様はデータベースのパフォーマンスを手動で分析・評価する専任の DBA を必要とすることになります。 AWS Compute Optimizer は、Amazon EC2 インスタンスと Amazon Elastic Block Store（Amazon EBS）ボリュームの適切なサイズをお客様に推奨し、インフラストラクチャのコスト削減を実現します。DBA は、AWS Compute Optimizer と推定ワークロードタイプを使用することで、SQL Server のワークロードを実行している Amazon EC2 インスタンスを迅速かつ容易に特定し、大規模なアプリケーションとデータベースのリリース後に提案される推奨事項をレビューすることができます。サイジングの適正化の分析と推奨は、主に Amazon EC2 インスタンスと Amazon EBS ボリュームのコストとパフォーマンスの最適化に重点を置いていますが、必要とするデータベース機能に関するインサイトはない為、エディションの推奨については限定的なものとなります。 SQL Server ワークロードのコスト最適化でよく見落とされるのがライセンスについてです。例えば、SQL Server Enterprise エディションの機能は、アプリケーションが最初に公開されたときには必要であったかもしれませんが、その後のリリースでは使用されなくなっているかもしれません。アプリケーション/データベースごとの個々のリリースの変更に関する深い知識がなければ、機能要件の変化を見逃してしまい、SQL Server エディションのダウングレードの機会に気付けない可能性があります。 エディションのダウングレードの機会を見つけるもう一つのユースケースは SQL Server のバージョンアップです。SQL Server Enterprise Edition と Standard Editionの機能はバージョンが変わると変更されることがあります。例えば、Transparent Data Encryption（TDE）は SQL Server Enterprise エディションでよく使われる機能です。SQL Server 2019 のリリースにより TDE はStandard エディションで利用できるようになり、Enterprise エディションの要件がなくなりました。AWS Compute Optimizer は、Amazon EC2 上で SQL Server のワークロードを実行しているお客様に対して、SQL Server のライセンスエディションのダウングレードを提案します。 AWS Compute Optimizer は、以下のような SQL Server の Enterprise Edition の様々な機能についてチェックします。  128 GB 以上のメモリのバッファプール、または 48 vCPU 以上 を必要とするインスタンス 可用性グループ、リソースガバナー、非同期リードレプリカなど、よく使用される機能 NUMA 対応やメモリ最適化 tempdb メタデータなど、使用頻度の低い機能  これらの機能や制限が無い場合、AWS Compute Optimizer は SQL Server エディションのダウングレードを推奨し、オンデマンド価格によるコスト削減の余地を提示します（図 1 参照）。SQL Server エディションの機能比較について詳しく知りたい場合は「 SQL Server 2022 の各エディションとサポートされている機能 」を参照してください。 図 1. AWS Compute Optimizer は Amazon EC2 と Amazon EBS に対して、プロビジョニング不足、最適化、またはオーバープロビジョニングのリソースを素早く特定することができる推奨を提示します。 これらの自動化されたインサイトと推奨は、お客様と DBA が SQL Server のエディションをダウングレードし、ワークロードのコストを最適化する機会を簡単に特定して検証するのに役立ちます。AWS Compute Optimizer が SQL Server のエディション機能を評価することで、DBA とお客様は、常に最もコスト最適化された SQL Server のエディションを使用していることに安心できます。 SQL Server Standard エディションは Enterprise エディションよりも73%も価格が安い ため、表 1 に示すように Enterprise エディションから Standard エディションにダウングレードすることで大幅なコスト削減が可能です。表示されている価格は、SQL Server 2022 および SQL Server 2019 の、このブログ記事の公開日時点、2023/9/26 時点での Microsoft の公開価格に基づいています。 表1. SQL Server Enterprise Edition と Standard Edition の価格比較 SQL Server のライセンス費用を削減するだけでなく、SQL Server を Enterprise エディションから Standard エディションにダウングレードすることで、BYOL のお客様はソフトウェアアシュアランスのコストも削減することができます。BYOL のお客様は、利用しない Enterprise エディション・ライセンスを再利用または温存することによって再調達のコストを削減することができ、ライセンス投資を最適化できます。 AWS Compute Optimizer のサイジングの適正化の推奨機能は、追加費用なしで利用できます。エディションのダウングレードの推奨には、有料のカスタムメトリックを使用する Amazon CloudWatch Application Insights を有効にする必要があります。詳しくは、 Amazon CloudWatch Application Insights とは 、をご覧ください。 AWS Compute Optimizer を使い始めるには 1. AWS Compute Optimizer の推奨を受け取るには、 AWS Compute Optimizer にオプトイン する必要があります。オプトインすると、Amazon EC2 インスタンスタイプ、Amazon EBS ボリュームの IOPS やスループットなど、リソースの適切なサイジングの推奨を受け取るようになります。推定ワークロードタイプ機能はデフォルトで有効になっているため、SQL Server が Amazon EC2 インスタンスで実行されているかどうかを検出するために追加の設定は必要ありません。また、Amazon EC2 インスタンス上の SQL Server ワークロードに対して エージェントによるメモリ使用 を有効化し、メモリ使用量に関するより深いインサイトを得ることを推奨します。 2. AWS Compute Optimizer の 商用ソフトウェアライセンス推奨機能 を利用するには、個々のAmazon EC2 インスタンスに対して Amazon CloudWatch Application Insights を有効にする必要があります。どの Amazon EC2 インスタンスが Amazon CloudWatch Application Insights を有効にしているか、または有効にする必要があるかを表示するには、図 3 に示すように、AWS Compute Optimizer コンソール内のナビゲーションペインで「Licenses」をクリックします。 図 3. AWS Compute Optimizer の Licenses セクションにて、SQL Serverワークロードが実行されていることを検出した Amazon EC2 インスタンスの詳細を表示できます。 3. ライセンスの推奨ダッシュボードでは、SQL Server ワークロードを実行している Amazon EC2 インスタンスが一覧表示され、検出結果によって並べ替えることができます。検出される可能性のある定義は3つあります。 a. 最適化 – これらの Amazon EC2 インスタンスでは、Amazon CloudWatch Application Insights が有効になっており、AWS Compute Optimizer は Enterprise 機能が使用されていると検知したため、すでに最適化されていると判断しています。 b. 最適化されていない – これらの Amazon EC2 インスタンスでは、Amazon CloudWatch Application Insights が有効になっており、AWS Compute Optimizer は、SQL Server Enterprise Edition の機能を使用していないことを検知したため、Standard Edition へのダウングレードを検討が必要と判断しています。 c. メトリクスが不十分 – これらのインスタンスでは、Amazon CloudWatch Application Insights が有効になっていないか、適切な権限がないため、推奨が提供できません。 4. メトリクスが不十分と表示された Amazon EC2 インスタンスについては、インスタンスIDをクリックして、アプリケーションインサイトの有効化手順を始めて下さい。 5. AWS Compute Optimizer と Amazon CloudWatch Application Insights がアクセスして SQL Server Enterprise エディションの機能使用状況を確認できるようにするには、シークレットを選択するか、作成する必要があります（図 4 参照）。シークレットは SQL Server 認証インスタンスログイン、ユーザー名、パスワードとなり、ターゲットの SQL Server インスタンスで設定する必要があります。SQL Server ログインには以下の権限があることを確認する必要があります。 GRANT VIEW SERVER STATE TO [LOGIN]; GRANT VIEW ANY DEFINITION TO [LOGIN]; ログインを作成し、対象の SQL Server インスタンスへの権限を付与したら、 AWS Secrets Manager を使用して、Amazon CloudWatch Application Insights が使用する為のログイン認証情報を保存することができます。ドロップダウンボックスからシークレットを選択してください。 図 4. ドロップダウンボックスから、Amazon Cloudwatch Application Insights にデータベースへのアクセスを許可するために作成したシークレットを選択できます。 6. また、Amazon EC2 インスタンスが上記で 選択したシークレットにアクセス できるように、 IAM ポリシーとインスタンスロール を設定する必要があります。このインスタンスロールは、ライセンスの推奨を有効にするために、SQL Server を実行している対象のAmazon EC2 インスタンスにアタッチする必要があります。”Confirm Instance Role and Policy is attached” をチェックしてください。 7. これで “ Enable license recommendations” を選択できるようになります（図 5 参照）。これを選択すると、上部に “CloudWatch Application Insights is successfully enabled” という緑色のチェックマークが表示されます。 図 5. シークレットを設定しインスタンスロールとポリシーがアタッチされると Enable License Recommendations をクリック出来るようになります。 Amazon CloudWatch Application Insights を有効にした後、AWS Compute Optimizer のダッシュボードにレコメンデーションが表示されるまで、通常は24時間かかります。有効化のプロセスでは、ターゲットの Amazon EC2 インスタンスに PrometheusSqlExporterSQL（図 6 参照）という Windows サービスをデプロイします。SQL Server Enterprise Edition の機能が使用されているかどうかを判断するためにはこのサービスが必要です。 図 6. インストールされた PrometheusSglExporterSQL サービスが実行されていることを示す Windows Services コンソール。 推奨の詳細を表示するには、ライセンスの推奨ダッシュボードの “Findings” 列で “over-provisioned” と識別されたインスタンス ID をクリックします (図 7 を参照)。インスタンスの詳細ページに移動し、上部に “License recommendations” という新しいタブが表示されます。このタブでは”最適化されていない”などの検知と”ライセンスがオーバープロビジョニングされている”などの理由を確認できます。 図 7. AWS Compute Optimizer 内の “License recommendations” セクションの表示。この例では、Enterprise Edition から Standard Edition へのダウングレードを推奨する SQL Server インスタンスが示されています。 インスタンス ID をクリックすると、”License recommendations” の更に詳細を見ることができます。インスタンス固有のページでは、現在のライセンスのコストと推奨との比較の詳細が表示されます。図 8 は、Enterprise が現在のエディションで Standard が推奨です。 図 8. AWS Compute Optimizer の “License recommendations” セクションでインスタンスIDを選択すると、そのインスタンスに対する固有の推奨事項の詳細ビューに移動します。 また、SQL Server のエディションをダウングレードした場合の、月々の削減見込み額や削減機会の割合などの詳細も表示されます。図 9 では、Amazon EC2 の削減コストと SQL Server の推奨での削減コストが円グラフで分割され、両方の推定削減コストが示されています。推奨には、ダウングレードした場合のオンデマンドのコストと、現在のエディションに留まった場合のコストも含まれているため、お客様はコスト削減の全体像を可視化することができます。 図 9. AWS Compute Optimizer のダッシュボードから、ライセンスの推奨による潜在的なコスト削減を素早く確認することが出来ます。 SQL Server Enterprise エディションから SQL Server Standard エディションへのダウングレード Amazon EC2 上で SQL Server の License Included の AMI を使用して SQL Server を実行しているお客様は、SQL Server のインプレースダウングレードではなく、新しい SQL Server Standard エディションの AMI を起動してデータベースを移行する必要があります。異なる SQL Server ネイティブの移行方法については、 SQL Server データベース移行方法のドキュメント を参照してください。 AWS Systems Manager の自動化のドキュメントは、SQL Server BYOL モデルで SQL Server を Amazon EC2 上で実行しているお客様が、SQL Server Enterprise エディションから Standard または Developer エディションにダウングレードする際にも役立ちます。自動化を使用してエディションをダウングレードする方法については、こちらのブログ記事を参照してください： Downgrade SQL Server Enterprise edition using AWS Systems Manager Document to reduce cost. まとめ 適切な SQL Server エディションを選択することで、お客様は必要な SQL Server 機能を確実に使用しながら、大幅なコスト削減を実現できます。AWS Compute Optimizer に SQL Server Enterprise Edition の機能評価が追加されたことで、組織は SQL Server のライセンスとインフラストラクチャのコストを削減することができます。この機能を使用することで、お客様はAmazon EC2 インスタンス上の SQL Server が、パフォーマンス、ライセンス、およびコストが最適化された状態で実行されていることを確認できます。 AWS は、他のどのクラウドプロバイダーよりもはるかに多くのサービスと、それらのサービス内の多くの機能を備えており、既存のアプリケーションをより迅速、簡単、かつコスト効率よくクラウドに移行し、想像できるほぼすべてのものを構築することが出来ます。Microsoft アプリケーションに必要なインフラストラクチャを提供し、お客様が望むビジネス成果を実現しましょう。マイクロソフトのワークロードに関するその他のガイダンスとオプションについては、 .NET on AWS と AWS Database のブログをご覧ください。移行とモダナイゼーションの旅を始めるには、今すぐ お問い合わせ ください。   投稿者について Blake Lyles Blake Lyles は、SQL Server を専門とする Microsoft Workloads Specialist Solutions Architect です。ブレイクはアマゾンに 6 年以上在籍し、そのほとんどの期間を EC2 上の SQL Server、RDS のサポート、Database Migration Service、Amazon DocumentDBなどのデータベースワークロードに費やしてきました。Blake は、顧客が AWS 上でデータベースワークロードを移行し、近代化するのを支援してきました。 Reghardt van Rooyen Reghardt van Rooyen は Amazon Web Services のシニア・スペシャリスト・ソリューション・アーキテクトです。14 年間の SQL Server データベース管理とリーダーシップの経験を活かし、企業のお客様向けの高スループット SQL Server HADR ソリューションのアーキテクチャリングを専門としています。常に探究心を持ち、お客様の実装がパフォーマンスとコストの最適化につながることを確実なものとなるように、AWS のインフラストラクチャと SQL Server データベースのパフォーマンス限界を探ります。南アフリカ出身で、ラグビー、バーベキュー、家族や友人と屋外で過ごすことが趣味です。 Blake Lyles Yogi はプリンシパル・ソリューション・アーキテクトであり、22年にわたりさまざまな Microsoft テクノロジーに携わってきた経験があります。AWS 上で Microsoft のワークロードを実行するためのAWSに関する深い専門知識を持っています。 翻訳はソリューションアーキテクト樋口が担当しました。原文は こちら です。

2023 年 10 月 5 日に「AWS で実践！ Analytics Modernization ～事例祭り編～」を開催しました。今回の事例祭りでは新しく GA された Zero-ETL を活用したデモや Amazon OpenSearch Service を用いたベクトル検索、また AWS Clean Rooms と AWS の分析・予測サービスをつなげた一連のデモをご紹介しました。また AWS サービスを用いてビジネス価値を創出しているお客様事例としてパイオニア株式会社 様にご登壇いただきました。本ブログでは当日の各発表内容を紹介いたします。 Zero-ETL Integration を活用した業務データベースのニアリアルタイム分析 アマゾンウェブサービスジャパン合同会社 アナリティクススペシャリストソリューションアーキテクト 濱岡 洋太 資料ダウンロード AWS の濱岡からは 2022 年の re:Invent で発表された新機能である Zero-ETL Integration を使い、 Amazon Aurora に保管されているデータを Amazon Redshift へニアリアルタイムに連携・分析する方法についてご紹介しました。 業務系データベースには時事刻々と変化する最新のデータが保管されており、そのデータを分析することで新たなインサイトを生むことが期待されます。一方、分析のために業務データベースから分析データベースへデータを連携しようとするとデータ鮮度の低下や ETL 処理の構築・運用コストが課題として挙がります。業務データベースを分析する上ではデータ連携をいかに素早く、簡単に実現するかが重要となりますが、従来この 2 つを両立することは困難でした。 Zero-ETL 統合は ETL パイプラインなしで Aurora MySQL から Amazon Redshift へニアリアルタイムにデータを連携する機能です。Zero-ETL 統合を使用することで、これまで自前で組んでいた ETL 処理等のデータ連携の仕組みを代替し、かつデータ鮮度を簡単に向上することが可能です。Aurora 側での変更は 50 パーセンタイルが 15 秒以内に Redshift へ連携され、また更新はストレージレイヤーで行われるため Aurora 及び Redshift のコンピュートリソースへの影響は最小限に抑えられます。 デモでは、Webアプリケーションのバックエンドとして使用されている Amazon Aurora のデータを Zero-ETL 統合を使用して Amazon Redshift へ連携し、Amazon Managed Grafana を使用して可視化を行いました。 画面左側では Webアプリケーションを模した Amazon EC2 インスタンスから、 Amazon Aurora へ 1 秒ごとにデータを INSERT しています。INSERT されたデータは Zero-ETL 統合によって自動的に Amazon Redshift へ同期されます。画面右側の Amazon Managed Grafana から Amazon Redshift へクエリを行い、データがニアリアルタイムに連携されていることが確認できました。 Zero-ETL 統合を使って業務データベースを素早くかつ簡単に連携する方法についてご紹介しました。Zero-ETL 統合は本イベント実施時点ではプレビュー中でしたが、2023年11月7日より一般利用可能となっていますので是非ご活用ください。 車両走行データを活用した渋滞情報生成基盤のご紹介 パイオニア株式会社 Cross Technology Center サービス技術企画部 先行開発グループ 宮本 祥平 氏 資料ダウンロード 1937 年に国産初ダイナミックスピーカーの開発を行い翌年創業しました。音をメインにしていたところから時代の変化とともに変革していき、近年ではカーエレクトロニクス事業を基幹事業としており、「より多くの人と、感動を」を理念に事業をしてます。市販事業の中で、音声だけで操作ができる対話するドライビングパートナーである NP1 の販売が開始されました。またドライバーの運転スタイルを学習し、パーソナライズされたデバイスへと進化をします。それ以外に、近年はデータソリューション事業にも力を入れています。モビリティデータやインテリジェントカメラの映像データ、位置情報などと連携しクラウドソリューションを提供しています。 パイオニアが保有するデータとして全国道路総延長 70 万 km のデータや、走行時の定点画像データ 2 億枚、それ以外にこちらに記載のデータを保有しており、今後データを活用したサービス提供していきたいと考えています。 渋滞情報生成基盤として、2006 年からスマートループ渋滞情報のサービスを提供しています。その後さまざまなデータがアップロードされ、データ量が増えてきた一方、各サービスがサイロ化されデータが連携できていなかったため、AWS 上にデータレイクを構築し、データの集約を行いました。そして今回、新規渋滞情報生成基盤の商用化に向け開発を行いました。 ポイントは 3 つあり、リアルタイムのストリーミング処理による走行データの渋滞情報への反映速度改善、複数データソース毎の仕様差分の吸収、データ流量に応じたスケールイン/アウトです。 いくつかの車載器から点列データが AWS Lambda を介しアップロードされます。Amazon EKS のコンテナにデータを渡し、点列データからマッチングデータへ変換を行います。その際道路情報は Amazon EBS に格納をしています。別経路からは道路情報が付与されているマッチングデータがアップロードされます。これはコンテナ 2 に直接アップロードできるようにしています。その後、Amazon Aurora と Amazon Kinesis Data Firehose にデータを渡しています。Firehose からは Amazon Glue を介し、Amazon S3 上に渋滞統計データを保存しています。 いくつか改善事例をご紹介します。まずは Amazon Kinesis と AWS Lambda の部分です。走行データの渋滞情報への反映速度の改善と各走行データソースのアップロードがバラバラであったという課題に対し、Amazon Kinesis Data Streams と AWS Lambda をそれぞれのサービスにデプロイしました。それにより、随時データ処理ができたこと、後段の共通処理をそれぞれの AWS Lambda で調整ができるようになったこと、また新規データの追加が共通パターンを利用できるようになったことが改善として挙げられます。 また Amazon EKS についてですが、開発当初は EKS にするか Lambda にするか検討していましたが、マップマッチング処理が必要であった点、またその処理が高負荷かつ処理時間が長い点、EKS の方が料金割引がある点で EKS を採用しました。 次はアーカイブデータ分析についてです。こちらではリアルタイムに処理されてきた個別所要時間データを保有しています。そのデータを分析するために、Amazon Athena を用いて分析を行っています。また AWS Glue job を用いて大量データ統計処理を行い、Amazon S3 に保存しています。データの品質チェックには自作のデータチェック用の AWS Glue job を用いています。また Amazon Sagemaker を利用してデータの分析や可視化を行い、品質改善を行っています。ただし課題として、データ分析自体は自動化できていなく、確認したいデータを都度 Amazon Sagemaker で確認しなければいけない点があります。 3点目はストレージの検討です。当初左の図の様な Amazon EFS の構成を検討していましたが、Amazon EBS に地図データを配置することとしました。その際 gp3 を採用することで無料枠を超えてもファイルアクセスをすることができ、Amazon EFS と比較しコスト削減ができました。 最後は Amazon Aurora のタイプについてです。今回のシステムでは Aurora standard で実装しましたが、I/O 数が多くなり、Amazon Aurora のインスタンス料金よりも I/O 料金の方が高くなってしまいました。そこで新しい Aurora I/O-Optimized に変更することで、30-50% のコスト削減に成功しました。 今後の展望は、Amazon SageMaker Notebook 上で可視化しているものをダッシュボード化したいと考えています。その際は Amazon QuickSight の利用を考えています。また手動でデータチェックをしている部分を AWS Glue Data Quality の利用を検討しています。 まとめです。大量データのリアルタイム処理には、処理速度や I/O 数に合わせ、運用費を意識してアーキテクチャを構築すること。データの品質を保ちつつ、生成したデータの分析がしやすいアーキテクチャを構築すること。やりたいことに対し、新しい AWS サービスが対応しているかはすぐに調べること。迷ったり悩んだりした場合は AWS に相談することで方針が決まったことが挙げられます。 OpenSearch を使用したベクトル検索 アマゾンウェブサービスジャパン合同会社 プロトタイプエンジニアリング本部 プロトタイピングエンジニア 後藤 駿介 資料ダウンロード AWS の後藤からは、近年注目を集めている技術の一つであるベクトル検索を OpenSearch で行う方法についてご紹介しました。セッションの中では、ベクトル検索の基本やベクトル検索のユースケースを説明した後、Amazon OpenSearch Service や Amazon OpenSearch Serverless が持つベクトル検索機能を紹介し、最後に OpenSearch Serverless でベクトル検索をするデモを実施しました。 ベクトル検索とは、音声・画像・テキストなどのメディアの情報を機械学習の技術などを用いて数列値 (ベクトル) に埋め込むことで検索を行う技術のことを指します。埋め込みに使用される機械学習モデルでは、メディア同士近い性質を持つものは互いに近い距離のベクトルとして埋め込まれるように学習されます。そのため、テキストの検索では、伝統的に使用されてきたキーワード検索よりも、単語や文章の意味を考慮した検索が可能になります。またテキストに限らず、画像や音声などのデータに対しても、それらのメディアの類似度による検索を行うことができます。 ベクトル検索の代表的なユースケースとして、レコメンド、画像検索、RAG などがあります。レコメンドでは、商品情報やユーザー情報をベクトル化して、ユーザーにおすすめのコンテンツを推薦します。画像検索では、画像を CNN などの機械学習モデルを使用してベクトル化して、類似画像を取得します。RAG では、クエリに関連したドキュメントを取得するためにベクトル検索が使用されることがあります。 k-NN 検索とは、入力のベクトルと類似したベクトルを k 個返す検索のことです。k-NN 検索を正確に実行しようとすると、データ量に対して比例して計算量が増大しています。数万くらいのデータ量であればそれでもパフォーマンスに問題は出ませんが、更に大きな量のデータに対して k-NN 検索を実行しようとするとパフォーマンスに大きな問題が生じる可能性があります。近似 k-NN 検索では、近似的に類似したベクトルを取得することで、データ量が増大しても高速に処理できるようになります。上述したようなユースケースのアプリケーションで大規模なデータを扱う場合は近似 k-NN の使用が欠かせません。OpenSearch では近似 k-NN にも対応しており、大規模なデータに対して高速に検索することが可能です。 OpenSearch が持つ k-NN 機能は、AWS のマネージドサービスである Amazon OpenSearch Service や Amazon OpenSearch Serverless からも利用可能です。OpenSearch Service では、非近似 k-NN だけでなく、近似 k-NN アルゴリズムとして、HNSW と IVF アルゴリズムが使用可能です。また、メモリの消費を抑える手法である PQ を使用することも可能となっています。こうした選択肢があることで、お客様の要件に合わせたベクトル検索が可能になります。 また、プレビューではありますが、OpenSearch Serverless でもベクトル検索が可能となっています。OpenSearch Serverless は OpenSearch Service とは異なり、クラスターのサイジングやシャーディング戦略を考える必要なく OpenSearch を利用することが可能になります。OpenSearch Serverless でのベクトル検索は、OpenSearch Service と同様の操作で行うことができます。動画の中では、OpenSearch Serverless を起動して、データを投入して検索する流れをデモンストレーションしておりますので、ぜひそちらをご確認ください。 AWS Clean Rooms と AWS の分析・予測サービスとの親和性 アマゾンウェブサービスジャパン合同会社 アナリティクススペシャリストソリューションアーキテクト 佐藤 祥多 資料ダウンロード AWS の佐藤からは2022年の re;Invent で発表された AWS Clean Rooms についてご紹介し、AWS Clean Rooms とノーコード予測分析サービスである Amazon SageMaker Canvas とデータ可視化ツールである Amazon QuickSight を組み合わせたデモを実施しました。 AWS Clean Rooms は AWS 上でデータを安全に共有するためのデータクリーンルームを作ることができるサービスです。データクリーンルームとは、プライバシーやセキュリティが保護された状態でデータを共有することができる場を指します。昨今、企業内や組織間だけのデータ共有ではなく、企業や組織の枠組みを超えてデータ共有を行い、新しいビジネスインサイトを得るための取り組みが活発化しています。そういったビジネスニーズを満たすため、AWS Clean Rooms は AWS を利用しているすべてのお客様に手軽にデータクリーンルームを作れる機能を提供します。 AWS Clean Rooms は Amazon Athena のような SQL による操作で、共有されたデータに対して単体で分析を行うことや自身が保有するデータと組み合わせて分析を行うことができます。AWS Clean Rooms は安全にデータ共有を行うためのいくつかの機能を有しています。 コラボレーション：AWS Clean Rooms はデータ共有を行う場としてコラボレーションを作成できます。データを共有する AWS Account, データの分析を実行する AWS Account, データの分析結果を取得する AWS Account をコラボレーションに最大5つまで参加させることが可能です。データ分析の実行と結果取得は同じ AWS Account にすることも可能です。コラボレーションのオーナーはコラボレーションに参加させる AWS Account をコントロールすることで、誰が/誰に/何ができるのかを制御することができます。 生データを共有せずにデータ共有可能：AWS Clean Rooms では生データを共有せずに AWS Clean Rooms を利用するパートナーとデータ共有することが可能です。Amazon Simple Storage Service (S3) に保存され、AWS Glue Data Catalog に登録されたデータに AWS Clean Rooms は AWS Account を跨いでアクセスし、分析された結果だけをデータ共有先の Amazon S3 バケットに転送します。 分析ルールによる出力制限の設定：コラボレーションに参加しているデータ共有をする AWS Account は共有されたデータに対して特定のクエリしか許可しない分析ルールを設定することが可能です。この分析ルールを設定することで、SUM や AVG といった統計情報しか出力しない制御を実現することや、共有先が保持している ID に合致したものだけを共有先にデータ提供するといった制御を実現することが可能です。 AWS Clean Rooms で共有されたデータは S3 に保存されるため、AWS の分析サービスや機械学習サービスを利用してさらなる分析や予測を行うことが可能です。Amazon QuickSight はデータを可視化するためのマネージドな Business Intellijence (BI) ツールです。マネージドであるため BI ツールのインフラを管理しなくても良いという特徴や、様々なアプリケーションに埋め込みが可能な埋め込み機能などがあります。 Amazon SageMaker Canvas はノーコードで機械学習モデルを作成してモデルを適応できる AutoML のサービスです。こちらも AWS Clean Rooms による分析結果を活用できるサービスになっています。 このセッションでは、新規広告を打った場合の効果を予測するというデモシナリオを AWS Clean Rooms, Amazon SageMaker Canvas, Amazon QuickSight を組み合わせて実施しました。デモの詳細な中身については動画を閲覧いただけると幸いです。 まとめ これまでの事例祭りに続き、Analytics 領域の先進的な事例が盛り沢山のセミナーとなりました。 日本のお客様向けに AWS アナリティクスサービスの最新動向 を発信しています。AWS サービスにご興味ある場合は無料で個別相談会を開催しておりますので、皆様からのお申込みをお待ちしております。 お申込みリンク 。 井形 健太郎・濱岡 洋太  

競争の激しい今日の世界でビジネスを成功させるには、優れたカスタマーサービスを提供することが不可欠です。コンタクトセンターは、多くの場合、主要な顧客接点の一つであり、通話録音は、企業が可能な限り最高の顧客体験を提供するのに役立つ貴重なツールです。インサイトに富んだ情報源を提供することで、次のような複数の目的を果たすことができます。 品質保証: 通話録音は、エージェントのカスタマーサービスの効果を信頼できる方法で評価します。エージェントのパフォーマンス、社内基準との整合性、顧客満足度などの要素を評価するために利用できます。 トレーニング: 通話録音は、新しいエージェントが様々なシナリオに慣れるための貴重なトレーニングリソースとなるだけでなく、既存のエージェントが自分のパフォーマンスを自己評価したり、マネージャーが対象を絞ったトレーニングプログラムを構築したりするための貴重なトレーニングリソースにもなります。 インサイト: 通話録音は、顧客の行動や感情に関する貴重なインサイトを提供するため、企業は顧客のフィードバックやレビューを収集したり、繰り返し発生するテーマを特定したり、マーケティングイニシアチブの影響を評価したりすることができます。 コンプライアンス: 通話録音は、顧客とのやりとりを記録し、会社の方針や手順への順守を保証することで、コンタクトセンターが規制要件を満たすのに役立ちます。 通話録音には数多くの利点がありますが、様々な管理上の課題を引き起こすこともあります。コンタクトセンターが生成する通話録音が増え続ける中、大量の蓄積データを費用対効果の高い方法で管理することが難しくなる場合があります。さらに、いくつかの業界では、通話録音の保存と維持に関して厳しい規制が課せられています。これは、特に通話録音を長期間保存することを義務付けられている企業にとって、大きな課題となる可能性があります。さらに、企業にとっては、通話録音や保有する機密情報のセキュリティと保護を確保することも不可欠です。 Amazon Connect にはフルマネージド型のネイティブ通話録音機能があり、お客様は最小限の設定とオペレーション労力で、エージェントと顧客との会話を録音して安全に保存できます。この投稿では、コスト最適化、セキュリティ、データ戦略を含む、前述のよくある課題に対処するために、Amazon Connect の通話録音に適用できる追加のベストプラクティスについて説明します。取り上げるトピックには以下が含まれます。 通話録音の偶発的または悪意のある削除からの保護 通話録音ライフサイクルの理解と管理、およびコスト最適化アプローチ 通話録音アクセスの監査 1. 通話録音の偶発的あるいは悪意のある削除からの保護 通話録音は Amazon S3 にネイティブに保存され、99.999999999%（11 個の「9」）の データ耐久性 を備えています。提供されている高い耐久性に加えて、各企業にとっては明確なアプローチを取り、これらの通話録音を悪意のあるまたは偶発的な削除や上書きから保護するための安全対策を講じることがベストプラクティスです。次のような様々なアプローチを使用できます。 IAM とバケットポリシー。 通話録音バケットに適用される バケットポリシーやユーザーポリシー はすべて、最小権限の許可モデルに準拠していることを確認してください。既存のポリシーを定期的に見直し、不要になったポリシーはすべて削除してください。お客様は IAM の 最終アクセス情報 を利用して、レビューの際に役立てることができます。 Amazon Connect のユーザーアクセス許可。 Amazon Connect インスタンス内の設定済みユーザーに、それぞれの 役割と責任に適したアクセス権限 が付与されていることを確認します。アクセス権限の範囲を必要なものだけに絞り込むのがベストプラクティスです。 バックアップ。 従来的に通話録音のバックアップを取り、保存要件に従って保存します。 AWS Backup for Amazon S3 は、AWS サービスのデータ保護を簡単に一元化および自動化できるフルマネージドサービスで、このプラクティスを簡素化するために活用できます。 通話録音に対する S3 オブジェクトロック。 多忙なコンタクトセンターでは、通話録音がすぐに蓄積されてしまいます。データのコピーを余分に作成して保存する従来型のバックアップ方法ではストレージコストが増加し、大規模になると非常に高額になる可能性があります。通話録音用バケットに Amazon S3 オブジェクトロックを組み合わせることは、一定期間の間に通話録音を偶発的または悪意ある削除から守るための費用対効果の良い代替方法となり、さらに Write-Once Read-Many (WORM) ストレージを利用することで無期限に守ることもできます。さらに、オブジェクトロックは使用しても追加コストが発生しません。詳細については、 Amazon S3 ユーザーガイド と Amazon Connect 管理者ガイド を参照してください。 2. 通話録音ライフサイクルの理解と管理 一般的に、コールセンター環境において、通話録音はライフサイクルの初期段階、つまり品質保証、エージェント評価、トレーニングと開発の一環として録音された直後に、最も頻繁にアクセスされます。通話録音が古くなるにつれてアクセス頻度は低下し、一部の録音だけが特定の長期にわたる顧客からの問い合わせや内部調査のサポートや、コンプライアンスと監査の目的のためにアクセスされます。 通話録音が典型的にどうアクセスされるかと、そのアクセスが通話録音の存続期間を通じてどのように変化するかを理解することで、大幅にコスト最適化できる可能性があります。デフォルトでは、通話録音は頻繁にアクセスされるデータ用に設計された、可用性と耐久性に優れたストレージクラスに保存されます。古くてアクセス頻度の低い通話録音を低コストのアーカイブストレージクラスに移行すると、同等に高レベルなデータ耐久性と可用性とアクセス時間を維持しながら、ストレージコストを大幅に削減できます。 Amazon S3 ライフサイクルポリシー では、個々の通話録音の経過期間に基づいて通話録音を別のストレージクラスに移動する自動化されたメカニズムが提供されています。例えばお客様は、あらかじめ決められた期間を過ぎた通話録音を、即時アクセスできる低コストのアーカイブストレージクラスである Amazon S3 Glacier Instant Retrieval に移動できます。 取り出しリクエストに対する Glacier Instant Retrieval の料金 には注意が必要ですが、典型的には大幅なストレージコストの削減幅がこれを上回ります。アクセスパターンが異なるお客様も、使用する ストレージクラス を要件に合わせて調整することで同様のアプローチをとることができます。 3. 通話録音アクセスのロギングと監査 最高レベルのセキュリティと監視を確保するには、通話録音へのアクセスに対して包括的なロギングと監査のアプローチを実装することが重要です。これにより不正アクセスを検出して防止できるだけでなく、録音にアクセスしたユーザーやアクセス日時、アクセス元の場所を明確かつ検証可能な形で記録できます。この情報は、コンプライアンス監査に使用できるだけでなく、セキュリティ調査の際にも役立ちます。 以下のいずれかのアプローチを使用することで、お客様は通話録音バケット内のすべてのアクセスを簡単に記録、監査、把握できます。 AWS CloudTrail を使用して Amazon S3 API 呼び出しを記録する。 AWS CloudTrail はユーザーやロール、AWS サービスから実行されたアクションの記録を提供するサービスです。 CloudTrail ログには、ユーザーが再生のために通話録音をいつ取得したかなど、実行された API 呼び出しに関する詳細が含まれます。サーバーレスのインタラクティブクエリサービスである Amazon Athena を使用すると、お客様は標準 SQL を使用してこれらのログを素早く分析し、貴重なインサイトを得ることができます。 Athena ユーザーガイドはすぐに使い始めるための ステップバイステップの手順 を提供しています。 サーバーアクセスログを使用してリクエストを記録する。 Amazon S3 サーバーアクセスログは、通話録音バケットに対するリクエストの詳細な記録を提供できます。こちらも Amazon Athena により標準 SQL を使用してログを分析できます。 こちらのナレッジ記事 では、すぐに使い始めるためのサンプルクエリを含むステップバイステップガイドを提供しています。 こちらのリソース では、上記のロギングオプションに関する情報を提供し、それぞれの違いを取り上げて最適な方法を判断しやすくしています。要件によっては両方を組み合わせることも可能です。 結論 このブログでは、Amazon Connect での通話録音の管理に関する一連のベストプラクティスを紹介しました。まず、偶発的および悪意のある削除から通話録音を保護するための様々なアプローチとして、アクセス許可、バックアップ、オブジェクトロックなどを確認しました。続いて、通話録音のライフサイクルと、適切なストレージクラスを活用してコストを最適化する方法を検討しました。最後に、通話録音へのアクセスを記録および監査するための 2 つの簡単な方法として、AWS CloudTrail や S3 サーバーアクセスロギングの使用方法と、Amazon Athena を使用してこれらを迅速に分析して貴重なインサイトを得る方法について詳しく説明しました。 次のステップ 通話録音のさらなる最適化についてより詳しく知りたい場合は、次のブログ記事 「Amazon Connect 通話録音のアーカイブコストを最適化するためのサーバーレスアーキテクチャ」 と 関連するコードリポジトリ をご覧になることをお勧めします。 ここで取り上げているトピックについて質問がある場合やガイダンスが必要な場合は、いつでもお手伝いします。 AWS サポートセンター からお問い合わせいただけます。エンタープライズサポートをご利用されている AWS のお客様は、サポート関連の事柄や緊急の問題のエスカレーションについて、TAM にお問い合わせください。 無料の仮想イベント、AWS Contact Center Day にご参加ください。カスタマーサービスの未来や、機械学習が顧客とエージェントのエクスペリエンスを最適化する方法などについて学ぶことができます。 今すぐ登録 » ※訳注 オンラインイベントは2023年4月26日に開催されました。現在はイベントをオンデマンド配信でご覧いただけます。 翻訳はソリューションアーキテクト遠藤が担当しました。原文は こちら です。

Amazon QuickSight は、クラウドネイティブなサーバーレスビジネスインテリジェンス (BI) サービスです。ビジュアライゼーションの構築、アドホックな分析の実行、異常検知、予測、自然言語クエリなどの機械学習 (ML) 機能によってインサイトを得ることが可能です。また QuickSight は高性能なインメモリエンジンである SPICE (Super-fast, Parallel, In-memory Calculation Engine)を利用して迅速に高度な計算を実行し、ビジュアルを提供します。 BigQuery は Google Cloud のフルマネージドかつペタバイト規模のコスト効率の高い分析データウェアハウスであり、膨大な量のデータに対してニアリアルタイムでの分析を実行できます。BigQuery を使用するとインフラストラクチャの構築や管理が不要であるため、ユーザーは有益なインサイトの発見や、オンデマンドおよびキャパシティベースの柔軟な選択肢の活用に集中することができます。 本ブログでは、OAuth を通じてBigQuery のデータを QuickSight に取り込みシンプルなダッシュボードを作成するために必要な BigQuery の権限と接続の設定の詳細についてご説明します。 前提条件 以下が準備されていることを確認してください AWS アカウント Enterprise Edition の QuickSight アカウント Google Cloud アカウント BigQuery 権限の設定 このセクションは Google アカウントの管理者向けです。ユーザーが QuickSight でデータを表示するために必要となる権限を設定する必要があります。以下の手順を実行してください Google Cloud コンソールを開き、ナビゲーションペインで [IAM と管理] を選択します。 権限の設定ページが開き、プリンシパル(メールアドレス) 別、またはロール別にすべての権限が一覧で表示されます。 [アクセス権を付与] を選択します。 QuickSight にて BigQuery へのアクセスを許可する際のプリンシパルとなるメールアドレスを入力します。ユーザはこのログイン認証情報を使用して QuickSight にアクセスします。以下の例では、ユーザーは quicksight.user@gmail.com を設定しています。 [ロールを割り当てる] で、以下のロールを割り当てます BigQuery メタデータ閲覧者 (BigQuery Metadata Viewer) … プロジェクトレベルで設定します。これは、QuickSight ですべてのデータセットとテーブルを検出、表示するために必要です。 BigQuery ジョブユーザー (BigQuery Job User) … プロジェクトレベルで設定します。 ナビゲーションペインで [BigQuery] を選択します。 データセット (画像では QuickSight_Demo ) のオプションメニューを選択し、 [共有] を選択します。 [プリンシパルを追加] を選択します。 以上の手順により、ユーザーは QuickSight でデータを表示できるようになります。設定した権限に応じて、これは以前のロールのようにプロジェクトで実行することも、 データセット やテーブルのレベルで実行することも可能です。 本ブログでは、 QuickSight_Demo というデータセットを、quicksight.user@gmail.com のユーザーに、 BigQuery データ閲覧者(BigQuery Data Viewer) というロールを選択して共有します。 BigQuery からの接続詳細の取得 QuickSight との接続を開始する際に、BigQuery から以下の情報を取得することが必要です： Google Cloud アカウントのメールアドレスとパスワード プロジェクト ID データセットの地域 以下の手順で情報を収集できます Google アカウントのメールアドレスとパスワードをお持ちでない場合は、Google アカウント管理者にお問い合わせください。 プロジェクト ID を収集するには、 Google Cloud コンソール を開き、プロジェクト名を選択します。 ポップアップウィンドウで、プロジェクトの ID をコピーします。 または、BigQuery の管理者に連絡してプロジェクト ID を取得することも可能です。 Google Cloud のナビゲーションペインで、 [BigQuery] を選択します。 エクスプローラ で、QuickSight に取り込みたいデータセットを選択します。 データセット情報の データのロケーション(Data location) からデータセットの地域を取得します。画像の例では、 QuickSight_Demo をデータセットとして選択し、データのロケーションはデータセットの地域である US となっています。 または、BigQuery 管理者に連絡して、データセットの地域を確認することも可能です。 QuickSight で BigQuery のデータを分析する QuickSight で BigQuery のデータを分析するためには、 BigQuery のデータソースを作成する必要があります。以下の手順を実行します QuickSight コンソールで、ナビゲーションペインの [データセット] を選択します。 [新しいデータセット] を選択します。 Google BigQuery をデータソースとして選択します。 データソース名 に分かりやすい名前を入力します。(本ブログでは BigQuery Demo としています) 先ほど収集したプロジェクト ID と地域の詳細を入力します。 [サインイン] を選択します。 プロンプトが表示されたら、Google アカウントのメールアドレスとパスワードを入力します。 アクセスの詳細を確認し、 [続行] を選択します。 これまでの手順により、指定したプロジェクト ID とデータセットリージョンを QuickSight で管理し、BigQuery データを表示する権限が QuickSight に付与されます。 以上で Amazon QuickSight での BigQuery データソースの作成は完了です。続けて以下のステップでデータセットを作成します。 [データセット] にて、使用するデータセット ( QuickSight_Demo ) を選択します。 使用するテーブルを選択します。 (本ブログでは Sample_All_Flights を選択しています) [データの編集/プレビュー] を選択、または独自の SQL 文を使用したい場合は [カスタムSQLを使用] を選択します。 データ準備のページで、 [保存して公開] を選択し、 [発行して視覚化] を選択します。(こちらのデータは SPICE 上に取り込まれます) ビジュアルタイプを選択します。（本ブログでは、垂直積み上げ 100 パーセント棒グラフを使用します） 列を設定します。(本ブログでは、 X軸 、 値 、 グループ/色 として、それぞれ fl_date 、 origin_city_name 、 late_aircraft_delay を使用しします) 棒グラフにカーソルを合わせると、サンプルデータに基づいて Dallas/Fort Worth が May 15, 2015 に 50 %の航空機遅延を経験していることが確認できます。 ダッシュボードを公開するには、 [共有] を選択します。 本ブログで使用したデータは、今回のデモのために作成されたサンプルであり、実際の空港やフライトのデータを表現しているわけではないことに注意してください。 まとめ 本ブログでは、QuickSight にデータをインポートし、シンプルなダッシュボードを構築するためにBigQuery で必要な権限と接続情報についてご説明しました。 もしまだお持ちでなければ、次のステップとして Enterprise Edition の QuickSight アカウントを作成することをおすすめします。本ブログでは、QuickSight の基本的な機能のみをご紹介しました。QuickSight の高度なトピックに関するディスカッションや回答については、 QuickSight Community をご覧ください。 もしまだ BigQuery をご利用でない場合は、 Google Cloud Console からサインアップしてください。 翻訳はソリューションアーキテクトの守田が担当しました。原文は こちら です。 著者について Vignessh Baskaran は Amazon QuickSight のデータコネクティビティ領域を担当するプロダクトマネージャー。大規模データおよび分析ソリューションの開発において 7 年以上の経験を持つ。以前は、AWS の Sr. Sales Analytics Lead として、QuickSight を用いた包括的な BI ソリューションを構築し、AWS Worldwide Specialist Sales チームにグローバルで採用された。 Jobin George は Google の Staff Solutions Architect で、大規模データおよび分析ソリューションの設計と実装の 10 年以上の経験を持つ。Google の主要顧客や Data & Analytics パートナーに対して、技術的なガイダンスや設計に関するアドバイス、ソートリーダーシップを提供している。

この記事は Amazon EKS and Kubernetes sessions at AWS re:Invent 2023 (記事公開日: 2023 年 11 月 15 日) を翻訳したものです。 Introduction AWS re: Invent 2023 が間近に迫っており、Kubernetes とクラウドネイティブ関連のトピックに焦点を当てた全セッションが公開されました。適切なセッションを見つけて選択しやすくするために、セッションを主要な重点分野別にグループ化し、re: Invent セッションカタログへのリンクとともにリストアップしました。リンクをクリックしてから詳細ページが表示されるまで少し時間がかかることに注意してください。 見逃せないセッションの 1 つは「 CON203: Amazon EKS の未来 」です。こちらのセッションには AWS の Kubernetes 関連サービスの責任者である Nate Taber、Anthropic のクラウド責任者である Nova Dasarma、Slack のエンジニアリング担当ディレクターである Alex Demetri が出演します。Nova は Anthropic が Amazon Elastic Kubernetes Service ( Amazon EKS ) を使用して大規模言語モデル (LLM) をトレーニングした方法を紹介します。Alex は Slack が社内開発プラットフォームを Amazon EKS で標準化した方法を紹介します。Nate は最近の Amazon EKS のイノベーション、現在の重点分野、将来のロードマップの早期展望について説明します。 Expo ホール の Amazon EKS ブースまたは AWS モダンアプリケーションとオープンソースゾーン に立ち寄って、Kubernetes と Amazon EKS について AWS のエキスパートと話してみましょう。いくつかのデモンストレーションをチェックして、新しいオープンソース仲間と出会い、カスタムビルドのアーケードゲームで運試しをしてください！ プラットフォーム構築のための Kubernetes 私たちは Amazon EKS 上で、コンテナと Kubernetes を使用して革新的な開発者プラットフォームとアプリケーションを構築するお客様から常に刺激を受けています。今年の re: Invent のラインナップには、開発者が Kubernetes への移行を加速させるのに役立つ複数のセッションが用意されています。コンテナ化の取り組みを始めたばかりでも、既存のワークロードの最適化を検討している場合でも、これらのセッションでは必要な Kubernetes の知識が得られます。AWS のエキスパートに会い、同じような課題に直面している仲間とつながりましょう。 Amazon EKS がどのように Kubernetes をどんな規模のチームでも管理しやすくしているのか、一緒に明らかにしていきましょう。 CON206 | Amazon EKS で Kubernetes ジャーニーを加速させましょう (ブレイクアウトセッション) CON207 | Red Hat OpenShift Service on AWS (ROSA) を使用して AWS 上で OpenShift を実行する (ブレイクアウトセッション) CON305 | 組織全体で Kubernetes をスケーリングするための基礎 (ワークショップ) CON310 | AWS 上でのクラウドネイティブ Java (開発者向けセッション) CON311 | Amazon EKS によるプラットフォームエンジニアリング (ブレイクアウトセッション) CON327 | Amazon EKS の内部構造 (ブレイクアウトセッション) CON406 | Amazon EKS: Infrastructure as Code、GitOps or CI/CD? (チョークトーク) CON402 | Amazon EKS でのアプリケーションデプロイ: パターン、プラクティス、設計 (ワークショップ) Data on EKS (DoEKS) 大規模データ処理のパターン、生成系 AI モデルのデプロイ、 Data on EKS を使った Amazon EKS アーキテクチャのベストプラクティスを深く掘り下げます。Amazon EKS で機械学習ライフサイクルを管理するためのアプローチについて説明します。そして、Amazon EKS 上のデータを活用して生成系 AI アプリケーションを構築するワークショップを実際に体験してください。 CON309 | Amazon EKS での大規模データ処理 (ブレイクアウトセッション) CON312 | AI の未来を切り開く: Amazon EKS への 生成系 AI モデルのデプロイ (ブレイクアウトセッション) CON328 | Amazon EKS での MLOps アーキテクチャパターン (チョークトーク) CON404 | Amazon EKS でのデータを活用した生成系 AI (ワークショップ) CMP327 | Amazon EKS でのデータおよび分析ワークロードの最適化 (チョークトーク) CMP401 | Amazon EKS でコスト効率の高い Apache Spark データパイプラインを構築する (ワークショップ) コスト最適化とコストパフォーマンス クラスターの効率を最大化し、無駄を省く Amazon EKS のベストプラクティスを紹介します。Karpenter がリアルタイムのリソースニーズに合わせてノードグループを自動的にスケーリングし、コンピューティングコストを削減する方法をご覧ください。Kubernetes の支出とビジネス価値を一致させるための FinOps アプローチをご覧ください。コストを最適化することで、予算を新しい取り組みに充てることができるため、イノベーションが促進されます。環境の管理と最適化のための革新的な方法の提供を支援する AWS のエキスパートやパートナーに会いましょう。 CON306 | Karpenter: Amazon EKS ベストプラクティスとクラウドコスト最適化 (ワークショップ) CON331 | Karpenterのパワーを活用し Kubernetes のスケール、最適化、アップグレードを実現する (ブレイクアウトセッション) CON332 | Kubernetes を採用した FinOps: ビジネスイノベーションのためのコスト最適化 (チョークトーク) セキュリティ AWS では、Kubernetes ワークロードを実行するお客様にとってセキュリティが最優先事項であることを認識しています。Amazon EKS を安全にデプロイするためのツールとベストプラクティスを紹介します。クラスターを保護するために、ワークロードの分離、ネットワークポリシー、ランタイムセキュリティについて詳しく説明します。Amazon EKS を使用して初期段階から安全なソフトウェアファクトリを確立する方法を説明します。また、マルチテナントの Amazon EKS 環境におけるガバナンスとコンプライアンスのためのセキュリティ制御についても紹介します。 CON335 | Amazon EKS での Kubernetes ワークロードのセキュリティ保護 (ブレイクアウトセッション) CON334 | コンテナ環境を保護するための戦略とベストプラクティス (チョークトーク) CON302 | Amazon EKS を使用して AWS 上に安全なソフトウェアファクトリを構築する (ワークショップ) スケーラビリティ、耐障害性、接続性 お客様が Amazon EKS を使ってパフォーマンス、可用性、イノベーションの新たなスケールを実現できるよう支援することに私たちは全力を注いでいます。Amazon EKS のネットワーキング、スケーリング、エッジデプロイオプションについて学んでください。コンテナイメージの公開や、保護のための Amazon Elastic Container Registry ( Amazon ECR ) について詳しく説明します。また、Kubernetes API を拡張して AWS サービスを簡単にプロビジョニングする方法についても説明します。 CON308 | Amazon ECR によるパブリックイメージのオーナーシップの取得 (チョークトーク) CON329 | アーキテクチャに適したエッジコンテナサービスの選択 (チョークトーク) CON330 | Amazon EKS のネットワーキングの謎を解き明かす (チョークトーク) CON333 | AWS サービスをプロビジョニングするための Kubernetes API の拡張 (チョークトーク) CON405 | Amazon ECR に Dive Deep する (ブレイクアウトセッション) 直接参加できない方は、基調講演とリーダーシップセッションのライブストリームにご参加ください。 イベントに登録 すると、バーチャル専用パスを選択できます。ブレイクアウトセッションは、re: Invent の後に AWS のイベント YouTube でご覧いただけるようになります。 これらのセッションの詳細や、AWS の専門知識がお客様にどのように役立つかを知りたい場合は、AWS のアカウントチームにお問い合わせください。 ご来場またはオンラインでお会いできるのを楽しみにしています！Kubernetes を企業で使用する方法の詳細については、 Amazon EKS のウェブページをご覧ください。 翻訳はソリューションアーキテクトの加治が担当しました。原文は こちら です。

本記事は Amazon Mexico FP＆A の Gonzalo Lezma によるゲスト投稿です。 メキシコの財務計画と分析（FP＆A）チームは、 Amazon Mexico に関連する計画、分析、報告について、Amazon の CFO と経営陣に戦略的サポートを提供しています。私たちは、すべてのビジネスグループの内部損益（P＆L）レポートなど、主要な財務成果物を作成および管理します。また、月次予測見積もり、年間運用計画、3年予測などの計画プロセスにも関与しています。 私たちのチームは5つの主要な課題に取り組む必要がありました。手動による定期的なレポート作成、さまざまなソースからのデータの管理、大きくて遅いスプレッドシートからの移行、ビジネスユーザーによるアドホックなデータインサイト抽出の実現、および差異分析です。これらの問題に取り組むために、私たちはビジネスインテリジェンス（BI）のニーズに合わせて Amazon QuickSight を選択しました。 この投稿では、QuickSight によって私たちが財務分析とビジネス分析に集中できるようになり、ビジネス戦略の推進に役立てるようになったかについて説明します。 定期的なレポート作成の完全自動化 データの時間当たりのボリュームが多く、ビジネスグループやサブプロダクトが複数あるために、レポートを手動で作成・管理には時間がかかります。対象となるレポートでは処理すべきデータが大量にあり、さらに多くの利害関係者を満足させる必要があります。したがって、定期報告では、レポートの作成、スプレッドシートの数式チェック、報告数値の検証といった作業に多くの人と時間を割り当てる必要があります。 QuickSight のダッシュボードでは損益（P＆L）が表示され、データベースが更新されるとすぐに数値が更新されるため、定期的なレポート作成が大幅に簡素化されます。これにより人間の介入が必要なくなり、レポート作成で誤りが発生するリスクが排除されます。現在のところ、レポート作成プロセス自動化の結果として、従来1週間かかっていたレポートのメンテナンスと仕上げ作業にかかる時間をゼロにすることができています。また、 QuickSight アラート機能（次のスクリーンショットを参照）を使用して、特定の指標が事前定義されたしきい値を超えたときに通知を行っており、損益の大幅な変化をきめ細かく把握することも可能になりました。 さまざまなソースからのデータ メキシコでは新しい市場やチャネルが絶えず出現しているため、それらすべてが財務計画システムに統合されているわけではありません。そのため、シャドー P＆L やレポートは一般的で避けられない状況にあります。そのため、チームは財務数値の正確性や一貫性を損なうことなくそれらを追跡する方法を見つける必要があり、このことはさらに大きな課題となります。さらに、複数のチャネルとチームがそれらの数値を報告しているために、すべてのチームのデータソースを手動で更新するには時間がかかります。 QuickSight では、比較的新しい財務計画システムに未反映のチャネルや製品に関するデータを読み込むことができます。チームには Amazon Redshift 、CSV ファイル、Excel スプレッドシートなど、データをロードするためのさまざまなオプションがあり、レポート対象とするデータの粒度と範囲には事実上制限がありません。 大きくて遅いスプレッドシート スプレッドシートは財務分析の一般的なツールですが、大規模で複雑なデータセットを取り扱うには限界があります。これは分析のパフォーマンス、信頼性、検証に影響します。スプレッドシートは遅く、かさばり、エラーが発生しやすくなるため、大規模なデータセットを効率的に管理することが困難になります。 QuickSight が使用する SPICE (Super-fast, Parallel, In-memory Calculation Engine) のインメモリエンジンは、チームが過去に試したTableau や Excel などの他のソリューションと比べても比類のないもので、大規模なスプレッドシートを操作する必要性を劇的に減らすことができています。チームはレポートの内容を分析し詳しい説明を行う必要がありますが、それに加え、ただレポートを読んだり視覚化したりするのにも苦労をしている状況でした。 以下に示す MX 財務計画および分析ダッシュボードは、当社の事業の商品総売上高への主要な貢献要因を示しています。グラフに示されているように、売上全体の伸びの 20.92％ に対し、9.09％ が NAFN チャネルによるものであることがわかります。以下のグラフは、どの製品が売上の増加を牽引したかを示しています。 アドホックなデータインサイトの抽出 財務分野では、特定の商品・期間における直近のトレンドに関するアドホックな財務データが必要になることが頻繁にあります。チームが取り組んでいるチャネル、製品、シナリオの数を考えると、これは取り組むべき大きな問題になります。これらのデータからインサイトを抽出するにはかなりの処理能力が必要となり、チームが集中すべき他の重要なタスクを実行する時間を奪う可能性があります。 Amazon QuickSight Q はデータに関する様々なシンプルな質問に直観的かつ迅速に回答してくれるため、チームは自然言語での問い合わせによりデータからアドホックなインサイトを得ることができます。次のスクリーンショットは、 Q を使用して送料のレポートを行う際によく取得されるグラフを示しています。 差異分析 正確でインサイトに富んだ差異分析を提供することは、財務分析に携わる人にとって大きな課題です（たとえば、ミックス効果とレート効果を分離して価格や単位あたりの利益を説明する場合など）。財務分野でこの問題に取り組む方であれば、巨大で理解しづらいスプレッドシートを目にする機会も多いかもしれません。 QuickSight URLアクション （次のgifとスクリーンショットを参照）を使用すると、分析したい差異を右クリックすることで特定の差異の詳細を説明するシートにリンクさせることができます。これにより、チームが持っていた巨大で扱いにくい Excel の差異分析ツールを代替することが可能になります。 まとめ QuickSight の導入とダッシュボードの動的かつインタラクティブな性質により、社内のユーザーはマウスをクリックするだけでデータをより深く調査・分析できまるようになりました。また、ビジュアルの作成は直感的で、インサイトに富み、そして迅速に行えます。実際、今回紹介したソリューションとツールの全体は、専任の BI チームを必要とせずに構築されました。これに加えて、私たちは顧客の QuickSight の使用状況を確認するための社内向け QuickSight ダッシュボードを作成しました。これにより、どの領域・ユーザーがよりアクティブで、どの機能がパートナーによってより多く使用されているかを完全に把握することができます。 私たちは QuickSight ソリューションにより、自動化、セルフサービス BI、リクエストへの迅速な対応、および柔軟性を実現しています。 QuickSight のダッシュボード、レポートがビジネスにどのように役立つかについて、詳しくは Amazon QuickSight をご覧ください。 記事の翻訳は Solutions Architect 宮﨑 太郎が担当しました。原文は こちら です。