製造業のお客様は、しばしば人材の不足が組織の生産性に影響を与えていると話しています。このように感じているのは、あなただけではありません。製造業の事業者の興味関心事項を集めている業界団体の全米製造業協会 (U.S. National Association of Manufacturers) は、CEO に対して四半期ごとに主要な事業課題についてアンケートを実施しています。最新のアンケート( 2023年第4四半期製造業の概況 )では、71%を超える製造業の企業が「優秀な人材を惹きつけ、維持できない」という問題が、他のいかなる問題よりも事業に影響を与えていると回答しています。この問題は長年にわたって懸念事項のトップであり、「製造業のスキルギャップ」という独自のブランディングさえされています。簡単に言えば、30年の経験を持つ製造業の従業員が退職し、次世代が参入せず、現世代にはさまざまな考え方や期待があるため、製造現場では純粋に20%の従業員が減少している状況です。パンデミックによってこの状況はさらに悪化しています。 製造業の企業は、離職率が高い今の時代に生産性を維持するため、恒常的に新しい従業員をすばやく訓練する必要があります。また、革新の速度や必要なスキルセットの変化に対応するために、既存の従業員の能力向上や再訓練を行う必要があります。さらに、専門家の退職や離職によって既存の知識が失われるリスクを回避するため、できるだけ早期に既存の知識を収集し制度化しなければなりません( “the silver tsunami” と呼ばれることがあります)。多国籍企業にとっては、組織内の知識が一つの言語で入力されているが、別の言語で利用する必要があるなど、さらなる課題があります。 組織における隠れた知識を収集、統合し、これらを解放して簡単にアクセス可能にすることは、自然言語処理技術の最前線にある課題です。このブログでは、生成 AI の技術、特に非構造化・分散した情報を文脈化して洞察を抽出する能力が、どのように製造業の企業のスキルギャップ解消に向けた進歩に役立っているかを明らかにします。 生成AIとは 生成 AI とは、膨大な量の幅広い非構造化データセットで学習された、数十億のパラメーターを持つ機械学習 (ML) モデルの領域を指します。これらの生成 AI モデル、一般に基盤モデル (FM) または大規模言語モデル (LLM) と呼ばれるモデルは、情報の取得と要約、質問への回答、オリジナルコンテンツの生成など、幅広い文脈に適用できる複雑な要求を解釈する能力を持っています。FM には、テキストを生成する (Text-to-Text モデル)、画像を生成する (Text-to-Image)、マルチモーダル (Text-to-Image, Image-to-Text) などさまざまな種類のモデルがあります。例としては、Anthropic Claude、Meta Llama、 Amazon Titan などの基盤モデルがあります。 基盤モデルは、一般的な知識タスクにおいて、そのままでも良好な性能を発揮しますが、ドメイン固有の知識は限られています。従業員のスキルギャップを埋めるために、多くの場合に企業の専有情報や機密と見なされるドメイン固有の能力こそが、製造業の顧客が必要としているものです。 データサイエンティストは、一から高度に特化したモデルを開発するよりも、むしろ既存の汎用 FM を出発点として活用し、ドメイン固有の情報にアクセスできるようにしてモデルの応答を微調整するソリューションを設計しています。よく知られた費用対効果の高いアーキテクチャパターンとして、Retrieval Augmented Generation(RAG) があります。RAG では、ドメイン固有の機密性の高い情報にスマートな検索を実行し、最も関連性の高い情報を探し出します。検索した結果は基盤モデルに渡され、その複雑な情報を解釈する能力を活用して、検索結果から意味を抽出し、ドメイン固有の知識に基づいて要約、質問回答、オリジナルコンテンツの生成を行います。この手法により、製造業のような事実を重要視する業界で最も重要なことですが、回答が正確になり、同時に機密情報を保護することができます。RAG を使えば、基盤モデル、知識ストア、スマート検索サービスを柔軟に選択することで、パフォーマンスとコストを最適化することもできます。 企業は、文書ナレッジベース、ERP(Enterprise Resource Planning)、MES(Manufacturing Execution Systems) などの企業が専有するデータソースと基盤モデルを組み合わせ、ドメイン固有で高度にパーソナライズされた技術情報を扱える学習チャットボットなどのソリューションを提供できます。 生成AIがスキルギャップの解消にどのように役立つか RAG アーキテクチャが作業員を支援する情報をどう活用するかを理解するために、たとえばチャットボットが設備の修理技術者を支援し、問題の診断に費やす時間を短縮するケースを想像してみましょう。設備が停止すると、重要な製造ラインの稼働が妨げられる可能性があります。ラインを稼働させ続けることは、すべての製造事業者の主要な業績評価指標の要素(総合装置効率, OEE の一部である Uptime) であり、企業の収益に直接影響することがあります。診断時間の短縮は修理時間の短縮へとつながり、機器の可用性を高めます。 このチャットボットは、裏側で Retrieval Augmented Generation(RAG) を使って基盤モデルと診断マニュアル、サービスニュース、過去の原因分析、保守システムの情報などの追加情報源を組み合わせます。これらの情報は紙の書類の場合があります。紙の文書では、関連する情報をデジタルデータの形で抽出する処理が必要になります。また、スマート検索と生成 AI はコンテンツがデジタル化されていることを前提としており、特定のファイル形式を使えば、単語、概念、語意のセマンティクスや類似性を解釈する能力が高まります。そのため、デジタル化されているソースの文書でも変換が必要になる場合があります。 AWS Step Functions 、 Amazon Textract 、 AWS Lambda などの AWS のマネージドサービスを活用した自動コンテンツ処理パイプラインを構築することで、新しい情報が追加されるたびに抽出・変換が可能です。多国籍企業や多言語の従業員がいる企業では、パイプラインの中で Amazon Translate を使って、ソース言語から一つ以上のターゲット言語に翻訳する手順が加わります。 このコーパスは、基盤モデルがドメインに特化したデータソースを参照して正確な回答を行うためのものです。基盤モデルは文脈を把握しながら情報を要約して人間が理解しやすくし、既存の検索手法を超えた対話型の質問と回答を可能にします。 企業には何千件もの知識文書のコーパスがある場合があります。修理技術者がそれらをすべて読んでいるとは限らず、さらに重要なことに、重大な問題を診断する際に適切な情報を見つけるのは非常に難しいでしょう。 Amazon Kendra や Amazon OpenSearch Service などの AWS サービスを使ってスマートな検索を実現すれば、技術者は数千件の知識文書を現在の問題に最も関連性の高いごく一部に絞り込むことができます。これにより数千件から数十件と技術者の認知負荷は軽くなりますが、それでも負担があります。その数十件の文書を Amazon Bedrock で実行されるマネージドな基盤モデルに渡せば、RAG プロセスを完成させ、数千件の知識文書全体を1つの段落や絞った手順に要約できます。 数千件から数十件へ、そして最終的には、修理を行う技術者が重大な生産の問題を診断し、解決するまでの時間短縮に役立つ1つの簡潔な回答へとたどり着きます。 上記のソリューションは、生成 AI 対応のアーキテクチャを製造業の課題解決に適用できる例の一つに過ぎません。このアーキテクチャには AWS のマネージドサービスが含まれています。技術的なアーキテクチャと全体的なソリューションを確認し、個別の要件を満たすために拡張、機能強化、最適化することをお勧めします。 ソリューションの概要 それでは、修理技術者の診断時間を短縮するために、診断マニュアルなどの静的で構造化されたデータと、センサーのテレメトリデータや異常検知アラートなどの動的なデータの両方にアクセスする方法を主眼としたアーキテクチャ例を見てみましょう。 既存の静的なコンテンツから知識を抽出 診断マニュアルなどの知識源はあまり変更されることがなく、修理用チャットボットで継続的に再利用するために処理して保存することは理にかなっています。これらの文書には、フォームやチャートなど、前処理が必要なコンテンツが含まれることがよくあります。Amazon Textract などのサービスを使用して、この情報を抽出することができます。複数の言語を扱う場合は、必要に応じて Amazon Translate を使用して、異なる言語間で翻訳することもできます。文書から抽出され翻訳された情報は処理されたのち、Amazon Kendra (他の選択肢も可能)などのセマンティック検索が可能なコンテンツ知識リポジトリに追加されます。RAG ベースのチャットボットは、この情報を使用して、基盤モデルに渡す関連情報を見つけ出します。 図面、診断マニュアル、SOP などの組織の知識源が、 Amazon S3 に保存されています。 AWS Lambda 関数がトリガーとなり、S3 の変更イベントに応じて AWS Step Functions のオーケストレーションが開始されます。 Step Functions のワークフローは、Amazon Textract を使用してこれらのデータソースから情報を抽出し、文書の性質に応じてAmazon Translateを使用して翻訳するように構成されています。 処理された文書が最終的なコーパスとして Amazon S3 に保存されます。 Amazon Kendra は、多言語の文書コーパスが保存されている Amazon S3 バケットを参照し、検索用にインデックス化します。 エンタープライズアプリケーションと設備監視システムからの知識の抽出 産業設備は、ライン上の機器に接続されたセンサーからテレメトリーデータを生成します。このデータを分析し、予測アルゴリズムを使用して異常を検出します。異常が検出されると、アラートが発報されたり、技術者による問題解決のためにワークオーダーが自動的に作成されます。アーキテクチャの例では、 Amazon Monitron と Amazon Lookout for Equipment が異常を検知するサービスとして示されています。Amazon Kendra は、多くの AWS サービスや保全システムを含む業界で標準的なデータソースとネイティブで接続でき、カスタムコネクタを介して他のデータソースにもアクセスできます。 産業機器および製造工程からのテレメトリーデータは、さまざまなセンサーを通して収集されます。産業ゲートウェイがこれらのセンサーからデータを収集し、クラウドに送信します。 製造業のお客様は、 Amazon SageMaker などの機械学習やアナリティクスサービスを使用して、このテレメトリーデータを処理・分析できます。 この分析の結果に基づいて、なんらかの異常やイベントが AWS Lambda 関数をトリガーします。 AWS Lambda 関数は、設備管理システムで保守作業依頼を作成します。Amazon Kendra は、情報源として設備管理システムを使用します。 コンテンツやアプリケーションリポジトリと生成AIを結合する Amazon Kendra により、診断マニュアルなどの既存の静的で頻繁に更新されない知識ストアを、設備監視システムや EAM などの企業アプリケーションからのトランザクションデータと組み合わせることができます。 Amazon Bedrock は、Amazon Kendra などのデータソースを利用して、ドメイン固有の情報を検索し、コンテキスト化、要約、インタラクティブな質問と回答のためにさまざまな基盤モデルに渡します。Amazon Bedrock は API 駆動型であり、チャットボットアプリケーションや内部システム (既存のメンテナンスシステムなど) に機能を埋め込むことができます。Amazon Bedrock では、修理技術者のチャットボットを企業全体で広範囲に展開する際に重要な要素となる、正確な回答を適切なコストで提供するモデルを選択できます。 Amazon Kendra は、この例では静的コンテンツとトランザクションアプリケーションの知識ソースの両方を参照します。 Amazon Bedrock は、ドメイン固有の検索に Amazon Kendra を使用し、コンテキスト化、要約、インタラクティブな質問への回答のために基盤モデルを実行します。 エンドユーザーが Amazon Bedrock と接続されたチャットボットを使用します。 終わりに 数千から数十へ、最終的には従業員が使用できる 1 つの簡潔な回答へと、生成 AI と検索拡張生成 (RAG) アーキテクチャには、製造業の従業員を大いに力づけ、閉じ込められた知識を解放する可能性があります。基盤モデルと独自のデータソースを組み合わせることで、学習チャットボットなどのソリューションは、従業員のドメイン固有の質問に対して、関連性が高く理解しやすい回答を迅速に提供できます。これにより、作業員が情報検索に費やす時間が大幅に短縮され、機器の診断や修理などのプロセスが加速されます。最終的には、これが現場での生産性と効率性の向上につながります。 本ブログで紹介したソリューションはあくまで一例ですが、生成 AI によって従業員が組織内の情報へのアクセス方法を変革する可能性を示しています。アーキテクチャをカスタマイズして組織独自のデータソースを活用することで、この技術はあらゆる企業のニーズに適用できます。生成 AI が進化し続ける中で、これを活用してスキルギャップを解消し労働者を支援する絶好の機会が製造業のお客様に訪れています。 本ブログはAWS Blog の “ Closing the manufacturing skills gap with generative AI ” をソリューションアーキテクトの山本が翻訳しました。 Danny Smith Danny Smith は、自動車・製造業界のプリンシパル ML ストラテジストであり、顧客の戦略アドバイザーを務めています。彼は、役員室から製造現場に至るまで、主要な意思決定者がデータ、テクノロジー、数学を活用してより良い意思決定を行えるよう支援することに注力してきました。最近は、デジタルトランスフォーメーションの推進、データ主導型への移行、人工知能と機械学習の民主化戦略に関する話題がほとんどでした。彼は産業サプライチェーンの分野でキャリアをスタートし、今もなおこの分野を好み、特に鉄道が好きです。Danny は、ジョージア工科大学で産業管理の学士号を、ジョージア州立大学で意思決定科学の修士号を取得しています。 Garry Galinsky Garry Galinsky は、アマゾンウェブサービスのソリューションアーキテクチャを担当しています。電気通信、ローカル検索、インターネット、金融業界で 20 年以上にわたって進歩的なハイテクの経験を積んできました。Garry はキャリアの中で、北米、ヨーロッパ、中東、アジアの中小企業、大企業の顧客向けに、インターネット、Web 2.0、ローカル＆ソーシャル検索、モバイルソリューションの設計、開発、提供、普及に成功してきました。 Ravi Soni Ravi Soni は、製造システム、デジタルトランスフォーメーション、AI/ML、IoT、インダストリー 4.0、AWS クラウドなどに関する豊富な技術スキルを持つ製造ソリューションスペシャリストです。ダッソー、Google X、NuvaSiveで勤務した経験を持つ Ravi は、産業機械、プロセス製造、CPG、医療機器、航空宇宙産業にまたがる幅広い専門知識を持っています。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 最近暖かくなってきたと思ったら、最近はウォーキングで少し汗ばむぐらいになってきましたね。お昼のウォーキングも快適で、個人的には1年中これぐらいの気温だと良いのですが。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年4月8日週の主要なアップデート 4/8(月) Amazon OpenSearch Service now lets you update node count without blue/green Amazon OpenSearch Service で、専用のクラスター管理ノード（クラスターマネージャーノード）を持たないクラスターにおいて、Blue/Greenデプロイメント無しでデータノードの数を更新する機能が拡張されました（専用のクラスター管理ノードがある環境では以前より可能でした）。これにより、Blue/Greenデプロイメント実行中の一時的なノード数の増加をが不要になり、迅速にノード数変更が可能になりました。 Amazon CloudWatch RUM is generally available in 11 additional AWS Regions Amazon CloudWatch RUM を利用可能なリージョンが追加され、新たに大阪を含む11のリージョンで使えるようになりました。CloudWatch RUMはクライアント側からのリアルユーザーモニタリング (RUM)を支援するサービスです。追加されたリージョンは以下の通りです。Africa (Cape Town), Asia Pacific (Jakarta), Asia Pacific (Mumbai), Asia Pacific (Osaka), Asia Pacific (Seoul), Canada (Central), Europe (Milan), Europe (Paris), Middle East (Bahrain), South America (Sao Paulo), US West (N. California) 4/9(火) Amazon Route 53 adds support for 18 additional Top-Level Domains Amazon Route 53 は権威DNSサーバーの機能だけでなく、ドメインのレジストレーションサービスも提供しています。今回新たに18のトップレベルドメイン(TLD)が追加され、合計351のTLDが利用可能になりました。追加されたTLDは以下の通りです。.beer, .bid, .bio, .christmas, .contact, .design, .fan, .fun, .law, .llc, .ltd, .pw, .shopping, .ski, .software, .stream, .vote, .work Amazon RDS for MySQL supports rds_superuser_role for easier implementation of role based privileges Amazon RDS for MySQL v8.0.36 以降で rds_superuser_role というロールが追加されました。v8.0.36 以降で管理者ユーザーが直接DB内の表への変更を行うことが非推奨になり、新しいロールベース権限モデルに移行したのですが、これを支援するためのロールです。このロールは、DB内の表を操作する多くの権限を持っており、デフォルトの管理者に付与される形でこれまでとの互換性を維持しています。詳細は こちらのドキュメント をご覧ください。 Knowledge Bases for Amazon Bedrock now supports Claude 3 Haiku Amazon Bedrock の Knowledge Bases は、基盤モデル（FM）を社内のデータソースに安全に接続して検索拡張生成（RAG）を行い、より適切で正確な回答を提供することを支援する仕組みです。今回の改善で Anthropic の Claude 3 Haiku 基盤モデルをサポートしました（Claude 3 Sonnet はすでにサポート済です）。 AWS AppSync forwards application request headers to AWS Lambda custom authorizer functions AWS AppSync はサーバーレスで高性能な GraphQL サービスです。今回の改善で GraphQL リクエストを承認する際に、アプリケーションリクエストヘッダーを AWS Lambda カスタムオーソライザー関数に渡すことができるようになりました。カスタムオーソライザーでは認証ヘッダーの値に基づいて認証を実行できるようになります。 4/10(水) AWS Clean Rooms Differential Privacy is now generally available AWS Clean Rooms Differential Privacy (差分プライバシー) が一般提供開始（GA）になりました。Differential Privacyは、共有されたデータを分析する際に、統計的な影響を生まない範囲でのノイズ（エラー）を追加することでより匿名性を高めたり、プライバシーバジェット（予算）という仕組みの導入で、クエリの量のコントロールを実現する機能です。詳細はこちらの プレビュー時のブログ をご覧ください。 4/11(木) Amazon CloudWatch Container Insights announces observability for Windows containers on Amazon EKS Amazon CloudWatch Container Insights で、Amazon Elastic Kubernetes Service (EKS) で稼働する Windows コンテナに対応しました。CloudWatch Container Insights はコンテナ化されたアプリケーションやマイクロサービスからメトリクスとログを収集、集計、要約するオブザーバビリティのサービスです。 Introducing workflow monitor for AWS Media Services AWS Elemental MediaConnect, Elemental MediaLive, Elemental Media Packageといった、AWSのメディアサービスのワークフローを管理するためのworkflowmonitor for live videoが利用可能になりました。Elemental MediaLive console から利用可能です。 詳細はこちらのブログをご覧くださ い。 Amazon Braket adds experimental capabilities for QuEra device via Braket Direct フルマネージド量子コンピューティングサービスである Amazon Braket の Braket Direct で、QuEra の Aquila がサポートされました。 Braket Direct はリソースの予約といった機能に加えて、実験的な機能も利用可能にするものです。詳細は こちらのドキュメント をご覧ください。 Amazon CloudFront now supports Origin Access Control (OAC) for Lambda function URL origins Amazon CloudFront が Lambda Function URL をオリジンとする際にOrigin Access Control (OAC)でのアクセスを可能にしました。これによりLambda Functionを公開する際に、LambdaへのアクセスはCloudFrontからのリクエストに限るという設定が容易に可能になります。 4/12(金) AWS Step Functions Announces Optimized Integration for AWS Elemental MediaConvert AWS Step Functions で AWS Elemental MediaConvert との連携がより容易に行えるようになりました。例えば、MediaConvert CreateJob API 用の Run a Job (.sync) という統合パターンを利用すると、非同期の MediaConvert トランスコーディングジョブが完了するのを待ってから次のステップに進むといったワークフローを記載することが可能になるなど、より複雑なメディア処理のパイプラインが構築可能になります。 AWS KMS announces more flexible automatic key rotation AWS Key Management Service (AWS KMS) で、自動キーローテーションについて複数のアナウンスがありました。ローテーション期間の頻度が 90 日から 最大 7年 (2560 日) まで延ばすことが可能になり、過去のすべてのローテーションの履歴を確認できるようになりました。また、 価格についても変更があり、キーローテーションの最初の2回は1ドル/月の費用がかかりますが、3回目以降にはローテーションの費用がかからなくなりました。この変更は2024年5月の支払いサイクルから適用されます。詳細は こちらのホームぺージ をご覧ください。 それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (X/twitter – @simosako )

このブログは 2024 年 4 月 11 日に Kenneth Hui (シニアソリューションアーキテクト) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 ランサムウェアの脅威により、データ保護はすべての企業にとって最優先事項となっています。 Sophos 社の「State of Ransomware Report 2023」 によると、2022 年には 66 % の組織が被害を受け、ランサムウェアによる支払い額の中央値は 40 万ドル (平均支払い額は 154 万ドル) でした。バックアップを使用した場合の復旧コストの中央値は身代金支払いの半分 (75 万ドルに対して 37 万ドル) であるため、信頼性の高いバックアップを用意することは贅沢ではなく、組織にとって不可欠です。 同時に、組織はクラウドデータ保護のコストなどのクラウドコストの最適化を検討しています。 Flexera 社の「2023 State of the Cloud Report」 によると、クラウドを利用しているすべての組織の 82% が、クラウド支出の管理を最優先事項としています。AWS ユーザーからは、包括的な多層防御戦略と費用対効果の高いデータ保護戦略とのバランスを取る必要があるというフィードバックが一貫して提供されています。 AWS Backup は、ハイブリッドリソースの大規模なデータ保護を簡素化する、費用対効果の高いフルマネージド型のポリシーベースのサービスをユーザーに提供するネイティブクラウドソリューションです。13 万人の AWS Backup のお客様 (2023 年 9 月現在) がデータ保護の支出を最適化できるように、何千人ものユーザーとの作業から集めた AWS Backup のコスト最適化のベストプラクティスを概説する一連の記事を公開しています。この記事では、コスト最適化の定義、コストを最適化するための AWS Backup の構築方法、およびバックアップコストを最適化する際に考慮すべき原則について概説します。 コスト最適化とは何ですか？ コスト最適化とは「賢く」支出することであり、必ずしも支出を減らすことではありません。ガートナー社は、 コスト最適化 を「ビジネス価値を最大化しながら、支出とコスト削減を促進するためのビジネスに焦点を当てた継続的な規律」と定義しています。同様に、AWS はコスト最適化を「システムを運用してビジネス価値を最も低いコストで提供する能力」と定義しています。AWS Backup などのマネージドクラウドサービスは、コストの削減、イノベーションとモダナイゼーションの促進、運用効率とビジネスの成長の促進、ビジネスリスクの軽減により、IT インフラストラクチャからより多くの価値を引き出すのに役立ちます。 AWS Backup がデータ保護コストを最適化する方法 AWS Backup は、データを保護しながら経済的および運用上のメリットを得るのに役立つ主な方法が 3 つあります。 AWS Backup は、バックアップと復旧のインフラストラクチャ全体の支出を削減するのに役立ちます。 バックアップサーバーやストレージをプロビジョニングして管理する必要はありません。リソースの増大に合わせて容量を手動でスケールアップする必要はありません。AWS Backup を使用しても、年間のソフトウェアライセンスコストはかかりません。資本的支出や運用上のオーバーヘッドなしで、AWS Backup にすぐにアクセスでき、使用した分だけ支払います。 AWS Backup はバックアップ操作を簡素化するので、バックアップ操作に費やす時間とサイクルを減らし、代わりにイノベーションとモダナイゼーションに焦点を当てることができます。 AWS Backup を使用すると、サポートされた AWS サービスを一元的に保護できます。ネイティブの AWS サービスのバックアップを管理するために、購入または構築した複数のソリューションを管理する必要はありません。AWS Backup はマネージドサービスであるため、リソースのプロビジョニングやソフトウェアのパッチ適用、キャパシティプランニングなど、区別できないタスクに時間とサイクルを費やす必要がなくなります。 AWS Backup は、組織全体のバックアップコストを監視および最適化するための管理ツールを提供しています。 コスト配分タグなどのツールを使用して、バックアップのコストを追跡できます。AWS Backup ポリシーエンジンを使用すると、バックアップデータの保持とサポートされたサービスのライフサイクルを制御して、必要な時に以降データが保持されないようにすることができます。 AWS Organizations と統合することで、これらのポリシーを複数の AWS アカウントに一元的に適用できます。 考慮すべきコスト最適化の原則 バックアップコストを最適化するための万能のソリューションはありません。代わりに、総合的なアプローチを取り、ビジネス目標を達成しながら効率的に支出する方法を検討する必要があります。以下のテーマについて詳しく説明します。 1. 現在のクラウドのバックアップコストを評価して理解する バックアップコストの計算には、ストレージの料金を知るだけでは不十分です。インフラストラクチャやソフトウェア、運用コストを含め、現在のソリューションにいくら支払っているか知っていれば、コストをより適切に比較して最適化できます。 総保有コスト (TCO) を理解します。 バックアップストレージのコストだけでなく、現在のバックアップソリューションの TCO も考慮することをお勧めします。TCO を評価するためには、ソフトウェアライセンス、コンピューティング、運用などの追加コストを考慮する必要があります。 支出を追跡します。 実際の支出を理解していなければ、コストを最適化することはできません。AWS Backup は、バックアップコストの追跡と最適化に役立つツールを提供しています。コスト配分タグを使用してバックアップのコストを追跡できます。 AWS Cost Explorer を使用してタグ付けされたリソースをフィルタリングすると、部門やプロジェクトなどのさまざまな基準でバックアップコストを表示できます。 2. コストの計算方法を理解する バックアップコストはサポートされたリソースによって異なり、 AWS Backup の料金ページ に記載されています。各リソースのコストモデルを理解し、それらのポリシーに基づいてバックアップポリシーを設定することで、コストを最適化できます。 永久増分バックアップのコストへの影響を理解します。 従来のバックアップソリューションでは、増分バックアップに加えて、定期的なフルバックアップも必要とする方式が使用されていました。AWS のバックアップは、フルスナップショットを 1 つだけ作成することを必要とする永久増分スナップショットに基づいています。例えば、100 GB の Amazon Elastic Block Store (Amazon EBS) ボリュームで、日次の変更率が 2 % の場合、30 日間の保持期間で 1 か月間の日次バックアップを行うと、最大 160 GB のスナップショットデータが蓄積されます。週次のフルバックアップを行う従来の方法では、同じボリュームに最大 600 GB のスナップショットデータが蓄積されます。 さまざまなリソースのバックアップ料金を理解します。 AWS Backup は、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Relational Database Service (Amazon RDS) 、 Amazon Simple Storage Service (Amazon S3) 、VMware vSphere、 SAP HANA on Amazon EC2 など 20 のリソース・AWS サービスのバックアップ管理をサポートしています。サービスによってコストモデルは異なる場合があり、それらのコストモデルを理解しすることは、コストを予測および制御するのに役立ちます。例えば、Amazon RDS では AWS Backup を通じて継続的なバックアップを提供しています。これらのバックアップは最大 35 日間保存でき、その保持期間中に作成されたバックアップは無料で提供されます。 3. バックアップストレージにライフサイクル管理を使用する バックアッププランのバックアップ頻度やライフサイクル、リソース選択の粒度を制御できます。何をどのくらいの期間保護するかを選択できます。これらの設定はいつでも変更できます。 バックアップ頻度を制御します。 バックアップのコストは、データをバックアップする頻度に直接関係します。ワークロードごとの目標復旧時間と目標復旧時点に基づいて、ワークロードを分類し、バックアップ頻度を設定することをお勧めします。 保持ポリシーを決定します。 同様に、保持要件に従ってワークロードを分類することをお勧めします。例えば、日次バックアップは 1 か月だけ保持し、月次バックアップは 1 年間保持する要件がある場合があります。コストを制御するために、バックアップデータを必要以上に長く保持したくない場合があります。 長期間の保持のためにコールドストレージにバックアップを階層化します。 AWS Backup によって保護されている一部のリソースは、コールドストレージへの階層化をサポートしています。保持要件に従ってワークロードを分類し、必要に応じてコールドストレージに階層化することをお勧めします。 まとめ データが貴重で攻撃を受けている今、AWS Backup などのソリューションを使用してデータを保護することは不可欠です。しかし、その要件とコストの最適化の必要性とのバランスが取られる必要があります。AWS Backup には、最も低い料金でビジネス価値をもたらすシステムを運用できるだけでなく、バックアップの管理に役立つツールとベストプラクティスが用意されています。2024 年中に AWS Backup のコスト最適化に関する記事が他にもありますので、ぜひご覧ください。一方、AWS Backup の詳細については、 製品ページ をご覧ください。また、この Amazon ストレージブログの記事 を読んで、AWS Backup でコスト配分タグを使用する方法を学んでください。 この記事を読んでいただきありがとうございました。 翻訳はクラウドサポートエンジニアの黒川が担当しました。 Kenneth Hui Kenneth Hui は AWS 州政府と地方自治体チームのシニアソリューションアーキテクトです。エンタープライズテクノロジー分野で 20 年以上の経験があり、複数の移行プロジェクトを主導したり、参加したりしてきました。ケンはニューヨーク市に住んでおり、さまざまなレストランで食事をしたり、さまざまな料理を試したりすることを楽しんでいます。

世界中の研究機関では、 AWS を利用して大規模なシミュレーション、分析、モデリング、その他の分散型・計算集約型ワークロードを毎日実行しています。これらのジョブは、コンピューティングフリート全体でタスクを調整するオーケストレーションレイヤーに依存しています。 研究者やシステム管理者にとって、研究者向けのサービスを提供する際、ワークロードの種類によって選択肢が多岐にわたるため、どの AWS サービスやソリューションを使用するべきか判断することが難しい場合があります。 本記事では、代表的な研究ユースケースを取り上げ、それぞれのワークロードに最もフィットすると考えられる AWS ツールについて解説します。 ワークロードを理解する 各ツールの詳細に踏み込む前に、自身のワークロードの特性を把握することが大切です。 プロセスの密結合が求められるか、コンテナを利用するか、機械学習機能が必要か、クラウドデスクトップが不可欠かといった、様々な要因が意思決定プロセスにおいて重要な役割を果たします。 研究は一様ではないため、 AWS では工学シミュレーションや創薬、ゲノミクス、機械学習（ML）、金融リスク分析、社会科学など、 HPC（High Performance Computing, 高性能計算処理 )ベースの多岐にわたる研究をサポートしています。 また、選択するツールは排他的ではありません。お客様は同じアカウント内で、自身のニーズを満たすソリューションを組み合わせて利用できます。 AWSのコンピュートオーケストレーションツールの詳細 従来の HPC クラスターに適した AWS ParallelCluster AWS ParallelCluster は、AWS上でHPCクラスターを構築・管理するための柔軟なツールです。シミュレーションや分析など、従来型のHPCクラスターを必要とする密結合ワークロードに最適です。低レイテンシーと高スループットのインスタンス間通信のために、 Elastic Fabric Adapter （EFA）ネットワークをすぐに使えるようサポートしており、高性能ファイルシステム（Lustre – Amazon FSx for Lustre マネージドサービスを通じて利用可能）も備えています。 図1 – HPC ワークロードのための AWS ParallelCluster とその構成要素の概要を示しています。Slurm と Amazon EC2 との統合により、ジョブキューに基づいて計算ノード数が適切にサイジングされます。Amazon FSx for Lustre を使用すれば、高性能ファイルシステムにアクセスでき、同時に Amazon S3 オブジェクトストレージの利点も活用できます。これらすべてが Elastic Fabric Adapter (EFA) で接続されており、密結合ワークロードに対して極めて高い性能の接続とスケーリングを実現します。 コンテナベースのジョブに適した AWS Batch AWS Batch は、多くのコンテナ化されたジョブを同時に実行するような並列度の高い用途に適しており、これは密結合のワークロードも含みます。 Amazon Elastic Kubernetes Service (EKS)、 Amazon Elastic Container Service (ECS) などとシームレスに統合されたフルマネージドスケジューラで、研究者は既存のコンテナ化アプリケーションを活用できます。典型的なワークロードは、汎用的な計算の並列実行や、他の AWS サービスとの統合、MPI や NCCL を用いた密結合ジョブ等です。 図2 – コンテナベースのジョブ処理と AWS サービスとの統合を示す AWS Batch のワークフローです。Amazon EKS および ECS との互換性により、Compute Environment 層で柔軟性が確保されています。 機械学習プロジェクトに適した Amazon SageMaker Amazon SageMaker は、特に Jupyter Notebook で Machine Learning モデルを開発するワークロードに最適です。研究コンピューティングの基礎的な構成要素に特化しているわけではありませんが、代わりにデータ発見・探索からモデルトレーニング・デプロイまでの全工程をカバーする、マネージド型の ML ・データサイエンスツール群のエコシステムを提供しています。 SageMaker ノートブックは対話型の開発環境を提供し、研究者はモデルの開発・テストを容易に行えます。SageMaker には事前トレーニングされたモデルも含まれており、研究者は ML プロジェクトをジャンプスタートできます。また、マネージド型の推論エンドポイントも提供されており、モデルのデプロイと予測の提供が簡単になります。 図3 – データ準備からモデルデプロイまでのエンドツーエンドのプロセスを高レベルで示す Amazon SageMaker エコシステムです。ノートブックでのローカルファイルシステムとして Amazon EFS と統合されており、また、モデルトレーニングのために高度に最適化された AWS Deep Learning Containers とも統合されています。 基盤となる計算リソースについて 先程述べた3つのサービスは、Amazon EC2 の Spot インスタンス と AWS Fargate の両方を活用できます。Spot インスタンスは割引価格で提供される余剰の EC2 キャパシティですが、2 分前の通知の後に中断される場合があります SageMaker、Batch、ParallelCluster はいずれも、Spot インスタンスの経済的メリットを活用できます。Spot インスタンスを使う場合、ワークロードが回収によるキャパシティ中断に耐えられるか、またはサービスが代替リソースへ自動的に移行してプロセスの中断を回避できるかを確認する必要があります。 MemVerge などの AWS テクノロジーパートナーは、 OSレベルのメモリチェックポインティング を活用してこの問題を処理できます。 Fargate はサーバーレスコンピューティングエンジンで、Batch with ECS、ECS および EKS クラスターのネイティブワークロードで使用できます。サーバーやインフラパラメータ（インスタンスタイプなど）といった設定なしにコンテナを実行できます。ただし、ハードウェア仕様に関する注意事項がいくつかあり、 ドキュメント で確認する必要があります。一般的に、研究では Spot インスタンスや Fargate を AWS オーケストレーションツールと組み合わせて使うことをお勧めします。 個人用クラウドデスクトップのための Amazon Lightsail for Research Amazon Lightsail for Research は、価格の予想がしやすく、事前にセットアップ済みであるクラウドデスクトップを求める研究者向けのシンプル(かつ強力)なソリューションです。研究に最適化されたハードウェア仕様と、シームレスなユーザー体験を提供するよう、特に研究者向けにカスタマイズされています。Lightsail は、研究者のニーズに合わせてカスタマイズ可能な、さまざまな事前構成済みの仮想プライベートサーバーを提供し、Scilab、RStudio などの研究アプリケーションが付属しています。使いやすいインターフェイスと手頃な価格設定により、Lightsail for Research は研究者が AWS を使い始めるための、信頼性と効率性の高いソリューションとなっています。 図4 – 研究者が Amazon Lightsail for Research の簡素化された管理インターフェースとオプションを使って、Jupyter、RStudio、Scilab などの好みのアプリケーションをデプロイできることを示しています。 クラウドデスクトップを大規模に管理するための Research and Engineering Studio on AWS Research and Engineering Studio on AWS (RES)は、管理者が安全なクラウドベースの研究開発環境を作成・管理するためのオープンソースのWebベースポータルです。複数の研究環境の基盤をITチームが簡単に管理できるよう設計されており、研究機関に最適です。ワンクリックでの迅速なデプロイが可能ですが、組織の特定のニーズに合わせてカスタマイズも可能です。 図5 – 研究者と管理者の両方が RES を活用して、Amazon EC2 でバックアップされた Engineering Virtual Desktops (eVDI)を作成できることを示しています。ここに示されている RES Virtual Desktop の画面には、ユーザーが作成したすべての eVDI セッションとそれらを起動、シャットダウン、または稼働時間をスケジューリングするための制御機能が一覧表示されています。 バイオインフォマティクスのための AWS HealthOmics AWS HealthOmics は、バイオインフォマティクス研究のための包括的なソリューションです。生のゲノムデータの保存と処理を容易にし、研究者はゲノムデータを保存して解析できます。 WDL や Nextflow などの一般的なバイオインフォマティクスワークフロー定義言語をサポートしており、研究者は効率的にゲノムデータを処理・解析できます。 HealthOmics では、研究者が独自のワークフローを持ち込むか、事前に構築された Ready2Run ワークフローを使用するかを選択できます。 Ready2Run ワークフロー は、Sentieon 社や NVIDIA 社などの業界をリードする第三者ソフトウェア企業によって設計されており、タンパク質構造予測のための AlphaFold などの一般的なオープンソースパイプラインが含まれています。Ready2Run ワークフローを使えば、ソフトウェアツールやワークフロースクリプトを管理する必要がなく、研究者は大幅な時間を節約できます。 図6 – AWS HealthOmics プラットフォームの構造を示しており、ゲノムデータの処理と解析機能が強調されています。生の配列データと参照データは、Nextflow または WDL ワークフローを通して処理された後、 Amazon Athena などの AWS 分析サービスで解析できます。 次世代サーバーレス技術の活用 この10年間、AWS はサーバーレスコンピューティングの分野を先駆けてきました。サーバーレスコンピューティングとは、サーバーインフラストラクチャを管理することなく、アプリケーションを構築・デプロイできるモデルです。パッチや監視などのオーバーヘッドを伴う仮想マシンを起動する代わりに、実行するコードやプロセスに集中できます。 これは、イベントハンドリングや非同期タスクなどのユースケースに適していますが、研究者はサーバーレスコンピューティングを活用して、ML のハイパーパラメータ最適化、ゲノム検索、さらには MapReduce などの並列性の高いワークロードの高速化にも利用してきました。 AWS Lambda は、サーバーを管理することなくコードを実行するためのサーバーレスインターフェースです。疎結合ワークロードに適した設計になっており、データの変更(またはデータの到着)などのイベントに応じてコードを実行できます。Lambda は自動的にスケーリングするため、数千の並列実行が可能です。 さらに良いことに、Lambda は200以上の他の AWS サービスと統合されているため、複雑なワークフローを構築しやすくなっています。 AWS Step Functions との統合も提供されており、視覚的にワークフローを作成し、マルチステップの分散アプリケーションを構築できます。Lambda と Step Functions を組み合わせることで、異なる計算ステップ、データニーズを含むワークロード、さらには承認プロセスや人的な入力が必要なワークロードにも対応できるようになります。 図7 – サーバーレスコンピューティングアーキテクチャのサンプルを示しています。処理されるジョブのデータストリームが AWS Lambda によってピックアップされ、ダウンストリームの Amazon SQS キューに入れられます。AWS Step Functionsはこのキューから読み取り、Lambda ワーカー関数を使った分散コンピューティングのオーケストレーションの重い作業を処理します。Step Functions はまた、ワークロードの状態管理に Amazon DynamoDB 、イベントハンドリングに Amazon EventBridge 、処理後の結果の保存にAmazon S3を利用しています。 まとめ：適切な選択をするために 適切な AWS コンピュートオーケストレーションツールを選ぶには、万能のソリューションを見つけるのではなく、ツールの機能をワークロードの特定の要件に合わせて考えることが重要です。プロジェクトの細かい点、データの性質、計算ニーズに基づいて決定する必要があります。 プロジェクトとの互換性とスケーラビリティを測るために、小さなワークロードから始めましょう。 AWS は包括的なサービススイートを提供しており、お客様の研究の境界を押し広げるために必要なリソースと環境を確保し、研究ジャーニーのあらゆるステップをサポートする準備ができています。 また、 AWS パートナーもこれらのツールの実装をサポートします。 Ronin や Ansys などのパートナーは、 AWS 上での研究の時間を短縮するための貴重な専門知識を提供します。 プロジェクトに最適な意思決定を行うために、研究チームと AWS 営業担当との相談をお勧めします。研究が進化するにつれ、 AWS のスケーラブルで多様なコンピューティング環境は、計算ニーズを満たすために必要なツールとサポートを提供し続けます。この記事で触れたいくつかのツールの細かい点についてより深く掘り下げるために、 Choosing between AWS Batch or AWS ParallelCluster for HPC 、 why you should use Fargate with AWS Batch 、 save up to 90% using EC2 Spot についての過去の記事をチェックすることをお勧めします。 Patrick Guha Patrick Guhaは、テキサス州オースティンを拠点とするAWSのソリューションアーキテクトです。彼は、クラウド上でゲノミクス、ヘルスケア、高性能コンピューティングのワークロードに注力する非営利の研究顧客をサポートしています。Patrickは電気・コンピュータ工学の学士号を取得しており、現在はエンジニアリングマネジメントの修士号の取得に向けて取り組んでいます。 Matt Bollinger Matt Bollingerは、AWSのシニアソリューションアーキテクトであり、地球観測と地球科学に重点を置く非営利の研究組織と協力しています。彼は、顧客がクラウドネイティブの実践を活用して問題を効率的かつ持続可能な方法で解決できるよう指導しています。 翻訳はソリューションアーキテクト池田が担当しました。原文は こちら です。 HPC全般に関するお問い合わせ窓口： aws-jp-hpc@amazon.com

2023 年 6 月 30 日（金）および 2023 年 12 月 7 日（木）に、メディア業界のお客様向けに AWS 勉強会を開催いたしました。両日共に放送局のお客様にご登壇いただき、 AWS の活用事例についてご紹介いただきました。登壇者の所属部署および肩書きは登壇当時のものとなります。 AWS メディア業界向け勉強会 #3 （2023 年 6 月 30 日開催） AWS の基盤を活用したディープラーニング系ハンズオンの取り組み 朝日放送テレビ株式会社 技術局 技術戦略部 荒木 優 氏 朝日放送テレビでは、人材育成と機械学習の中でもディープラーニングに関する知見の蓄積を目的とした、若手および中堅エンジニアから構成される AI 研究会を立ち上げました。ハードウェアを購入しなくても必要な環境が用意できること、クラウドの知識も同時に習得できることから、 Amazon EC2 の GPU インスタンス（G4 インスタンス） 上で環境の構築を行い、今後の放送での利用も見据えて、ディープラーニングを使ったモデルによる物体認識や顔認識などの画像認識の実証実験を行なっています。また、 AWS Amplify 、 AWS Cloud9 、 AWS CodeCommit などを用いることで、これらの活動で得られた知見や手順、ソースコードの管理もクラウド上で実現しています。 資料のダウンロードは こちら 動画の視聴は こちら AWS でLIVE 配信をやってみた 株式会社静岡第一テレビ 技術プロデュース局 技術プロデュース部 システム室 泉地 裕史 氏 静岡第一テレビでは、COVID-19 下の無観客試合の中でも全国高等学校サッカー選手権大会（以下、高校サッカー）を多くの視聴者の方に楽しんでもらうために、2021年に自社サイト内でのインターネット配信を実施しました。高校サッカーは3ヶ月間に渡って開催されるため、より運用負荷の少ない体制や配信基盤を選定する必要があります。そこで、簡単にセットアップが可能で、低コスト、かつトラフィックに合わせてスケールが可能な Amazon Interactive Video Service（Amazon IVS） を選択し、わずか1週間でのセットアップを実現しました。Amazon IVS を使用することで大規模な自社配信設備の構築が不要となり、また広告を挿入することでインターネット配信のマネタイズも実現しています。 資料のダウンロードは こちら 動画の視聴は こちら AWS メディア業界向け勉強会 #4 （2023 年 12 月 7 日開催） 話題の衛星通信サービスでIVSに映像を上げてみた～AWS＋低軌道衛星 ＝ 災害時の最強タッグ～ 関⻄テレビ放送株式会社 技術推進本部 DX推進局 DX戦略部 専⾨部⻑ 栗⼭ 和久 氏 災害報道を行う際には、さまざまな手段を組み合わせていかに中継現場から本社までの映像伝送路を確保するか、という点が重要です。そこで関⻄テレビ放送では、衛星通信サービスやモバイル映像中継ソリューション、 Amazon Interactive Video Service（Amazon IVS） を組み合わせて映像を伝送する実験を行いました。その結果、設定するパラメータによって、伝送路の安定性や遅延量が大きく異なることが分かりました。安定した伝送路が確立されると、映像の伝送だけでなく避難所向けの情報配信や行政情報の共有などにも使える可能性があり、これらの知見の蓄積をすることは非常に重要です。例えば本実験では約4秒のレイテンシーが観測され、これは Amazon IVS が謳う5秒未満のレイテンシーの範囲内に収まっていることが分かります。Amazon が計画中の低軌道衛星を用いたブロードバンドサービス Project Kuiper についても期待の声をいただきました。 1日最大150球場超！大規模配信を支える バーチャル高校野球ライブ配信 技術 の舞台裏 朝⽇放送グループホールディングス株式会社 DX・メディアデザイン局 R＆Dチーム 村中 貴彦 氏 朝日放送テレビでは、朝日新聞社と共同で高校野球の総合情報サイト「バーチャル高校野球」を運営しています。年を追うごとに配信試合数が増加し、2023年には地方大会全3434試合、全国大会48試合を配信。配信担当者のスキルに依存しない仕組みを実現するために、AWS マネジメントコンソールから設定やステータスの確認が可能である AWS Elemental Link  を導入し、これによりエンコーダーの集中管理が可能となりました。また、年々増加する試合数に対応すべく、オンプレミスソリューションの AWS Elemental Live に加えて、わずか数分で新たなライブチャンネルをデプロイ可能な AWS Elemental MediaLive を導入しました。ワークロードの冗長性を担保するために、2 つのエンコーディングパイプラインを持つ標準チャンネルを採用しています。 また、担当者間で配信スケジュールの共有を行うために Amazon EC2 、 Amazon RDS 、 Amazon ElastiCache などを用いた試合ステータス情報の管理システム ACOMS（Asahi Communication System）を構築しました。このシステムを用いることで、試合スケジュールや運用ステータスの管理が可能となり、Web サイトの運営から配信対応まで、各担当者が連携して作業を行えるようになったことで、運用負荷（1 試合単位の運用対応人数が従来の 50％ と半減）とトラブルの軽減を実現しています。 導入事例「 朝日放送グループホールディングス、AWS を活用し『バーチャル高校野球』で 1 日最大 156 球場での試合を大規模配信 」に詳細の記載がございますので、ぜひこちらもご覧ください。 まとめ メディア業界向け勉強会の開催概要をご紹介させていただきました。内容について詳しく知りたい方は、記事上部より資料のダウンロード及び動画を視聴いただけますのでご確認ください。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきますので、どうぞよろしくお願い致します。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。

AWS Summit Sydney (4 月 10～11 日) 開催がいよいよ 2 日後となり、 AWS Summit Singapore (5 月 7 日) と AWS Summit Bangkok (5 月 30 日) を皮切りとする東南アジアの AWS Summit シーズンも開催まで残すところあと 1 か月になりました。この期間にシドニー、シンガポール、バンコクにおられる場合は、ぜひ AWS Summit にご参加ください。 4月1日週のリリース 4月1日週の Weekly Roundup をまだお読みになっていませんか? この Roundup では、 Channy がエイプリルフールのネタとして、 Jeff Barr からの新しいイニシアティブ、AWS Chips Taste Test について書きました。 4月1日週のリリースのうち、私の目に留まったものをいくつかご紹介します。 新しい Amazon EC2 G6 インスタンス – NVIDIA L4 Tensor Core GPU を搭載した Amazon EC2 G6 の一般提供が発表されました。G6 インスタンスは、ググラフィック集約型のユースケースや機械学習のユースケースに幅広く使用することができます。G6 インスタンスは、Amazon EC2 G4dn インスタンスと比較して、深層学習推論やグラフィックワークロードで 2 倍のパフォーマンスを発揮します。詳細については、 Amazon EC2 G6 インスタンスページ を参照してください。 Amazon Bedrock で Mistral Large が利用可能に  –  Veliswa が、Amazon Bedrock サービスの一環として Mistral Large 基盤モデルが利用可能になったことに関する記事を書いています。Mistral Large は、非常に優れた推論能力を必要とする複雑なタスクを処理するために使用できます。さらに、 Amazon Bedrock は、欧州パリ AWS リージョンでも利用可能になりました 。 Amazon Redshift との Amazon Aurora ゼロ ETL 統合がさらに多くのリージョンで利用可能に – ゼロ ETL 統合に関する発表は、昨年のローンチの中でも私のお気に入りでした。このゼロ ETL 統合は、2 つのサービス間でのデータ転送プロセスを簡素化するため、お客様は手動で抽出、変換、ロード (ETL) を実行する必要なく、 Amazon Aurora と Amazon Redshift の間でデータを移動させることができます。今回の発表に伴い、Amazon Aurora と Amazon Redshift 間でのゼロ ETL 統合が 11 の追加リージョンでサポートされるようになりました。 AWS Deadline Cloud の発表  – 映画、テレビ番組、コマーシャル、ゲーム、工業デザインの仕事に携わっていて、2D や 3D のビジュアルアセットを作成するチームのための複雑なレンダリング管理に対処しているならば、AWS Deadline Cloud にぜひご期待ください。この新しいマネージドサービスは、メディアおよびエンターテイメントワークロード向けのレンダーファームのデプロイと管理を簡素化します。 AWS Clean Rooms ML の一般提供開始 – 2023年、私は AWS Clean Rooms ML のプレビュー に関する記事を書きました。その記事では、お客様とパートナーが未処理データを互いにコピーしたり共有したりすることなく集合データに機械学習 (ML) モデルを適用できるようにする、 AWS Clean Rooms の新しい機能について詳しく説明しました。この AWS Clean Rooms ML を、皆さんに利用していただけるようになりました。 Amazon Bedrock のナレッジベースが OpenSearch Serverless のプライベートネットワークポリシーのサポートを開始 – Amazon Bedrock で構築する皆さんに嬉しいお知らせです。これからは、プライベートネットワークポリシーを備えた Amazon OpenSearch Serverless (OSS) コレクションを使用する Amazon Bedrock のナレッジベースで検索拡張生成 (RAG) を実装できるようになります。 Kubernetes バージョンに対する Amazon EKS 延長サポートの一般提供開始 – Kubernetes バージョン 1.21 以降を実行しているならば、この Kubernetes の延長サポートにより、 Amazon EKS で最新の Kubernetes 機能とセキュリティ改善を用いて最新状態を維持することができます。 AWS Lambda が Ruby 3.3 のサポートを追加  – Ruby でコーディングしていますか? AWS Lambda がそのランタイムとして Ruby 3.3 をサポートするようになりました。この更新により、Ruby 言語の最新の機能や改善を活用できるようになります。 Amazon EventBridge コンソールの機能強化  – Amazon EventBridge コンソールがの新しい機能と改善で更新され、より優れたユーザーエクスペリエンスによってイベント駆動型アプリケーションの管理がさらに簡単になりました。 商用リージョンでの AWS マネジメントコンソールへのプライベートアクセス  – 社内ネットワークからの個人 AWS アカウントへのアクセスを制限する必要がある場合は、AWS マネジメントコンソールプライベートアクセスを使用できます。このローンチにより、すべての商用 AWS リージョンで AWS マネジメントコンソールのプライベートアクセスを利用できるようになりました。 community.aws より   community.aws は、ビルダーである私たちが AWS での構築で学んだ事柄を共有する場です。以下は、私が選んだ先週のトップ 3 記事です。 14 LLMs fought 314 Street Fighter matches.Here’s who won ( Banjo Obayomi 著) Build an AI image catalogue! – Claude 3 Haiku ( Alan Blockley 著) Following the path of Architecture as Code ( Christian Bonzelet 著) AWS のその他のニュース   興味深いと思われる追加のニュース記事、オープンソースプロジェクト、Twitch 番組をいくつかご紹介します。 Build On Generative AI  – Tiffany そして Darko とともに、生成 AI をより詳しく学び、デモを見て、ゲストスピーカーと生成 AI のさまざまな側面について話し合いましょう。毎週月曜日、米国太平洋時間午前 9:00 に Twitch でストリーミング配信中です。 AWS オープンソースに関するニュースと最新情報  – AWS コミュニティからのさまざまなオープンソースプロジェクトやツールをお探しなら、私の同僚である Ricardo が担当する AWS オープンソースニュースレターをお読みください。 近日開催予定の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Summits – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。 アムステルダム (4 月 9 日)、 シドニー (4 月 10～11 日)、 ロンドン (4 月 24 日)、 シンガポール (5 月 7 日)、 ベルリン (5 月 15～16)、 ソウル (5 月 16～17西)、 香港 (5 月 22 日)、 ミラノ (5 月 23 日)、 ドバイ (5 月 29 日)、 タイ (5 月 30 日)、 ストックホルム (6 月 4 日)、および マドリッド (6 月 5 日) から、最寄りの都市でご登録ください。 AWS re:Inforce – 6 月 10～12 日に米国ペンシルバニア州で開催される、ビジネスイニシアティブの推進を支援するように設計された 2 日半の没入型クラウドセキュリティ学習のための AWS re:Inforce で、生成 AI 時代のクラウドセキュリティに関する知識を深めましょう。 AWS Community Days  – 世界中の エキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されるコミュニティ主導のカンファレンスに参加しましょう。カンファレンスは、 ポーランド (4 月 11 日)、 サンフランシスコ・ベイエリア (4 月 12 日)、 ケニア (4 月 20 日)、および トルコ (5 月 18 日) で開催されます。 近日開催されるすべての 対面イベント と 仮想イベント を閲覧することができます。 4月8日週のニュースは以上です。4月15日週の Weekly Roundup もお楽しみに! –  Donnie この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

(左から、AWS ジャパン ソリューションアーキテクト 木村 公哉、AWS ジャパン スタートアップ事業開発 福井 健吾、東大 IPC 長坂 英樹、AWSジャパン 事業開発 田村 圭) 日本政府は成長と分配の好循環を目指す「新しい資本主義」の実現に向けて、社会課題の解決に取り組むスタートアップがそのドライバーであると捉えスタートアップへの支援を強化し、持続可能な社会を目指しています。さらに、スタートアップ育成5か年計画の中では、グローバル市場での優位性という観点から非言語技術の創出を目指しDeepTech（研究開発型スタートアップ）への支援に関する予算が多く割り当てられており、その成長に期待が寄せられています。 アマゾン ウェブ サービス ジャパン合同会社 （以下、AWSジャパン）は、クラウドを始めとした新たなデジタルテクノロジーを社会実装するうえで欠かせないのがスタートアップであると考え、過去10年以上にわたり数千におよぶ日本のスタートアップを支援してきました。その中でもDeepTech（研究開発型スタートアップ）支援に関連して、AWSジャパンは2022年9月につくば市と研究開発型スタートアップの成長加速に向けた連携、2023年9月に慶應義塾大学と大学発スタートアップ創出支援に向けた連携を発表し支援するなど、より良い社会と市民生活の実現に貢献すべく、様々な関係団体との連携を図っています。 東大IPC は、2016年、東京大学が100％資本を持つ投資事業会社として設立されました。投資事業、起業支援、DeepTech Diveの３つの活動を通して東京大学のイノベーションエコシステム拡大を担う機関です。 起業支援においては、東大のみならず東工大、一橋大、筑波大、東京医科歯科大、北海道大学、名古屋大学、神戸大学など国内14の大学と連携した国内最大級の大学横断型起業支援プログラム、「 1stRound 」を年2回実施しています。 このような背景からAWSジャパンは、本日、東大IPCと研究者・スタートアップの支援について連携して取り組んでいくことを発表しました。既に提供していたAWS利用枠（クレジット）に加えてよりDeepTechに特化したワークショップ、個別技術相談会、ネットワーキングイベントなどをご提供し、お客様のビジネス成長を支援します。AWSジャパンは、東大IPCとともに、国内の産業活性化の支援のみならず、グローバルの社会課題解決の支援に向けて取り組んでいきます。 この連携は、「1stRound」に採択された、あるいは申請した起業を目指す研究者に対する多角的な支援体制の構築を特徴としており、具体的には、主にAWSジャパンが提供する以下の3つの支援から成り立っています。 計算リソース提供： AWS Activate *プログラムを活用し、東大IPC関連スタートアップに対して、最大25,000アメリカドル分のAWS利用バウチャーや他のAWSサービスのディスカウントを提供 技術支援： DeepTechに特化したワークショップ、個別技術相談会を実施 GTM（Go To Market）支援：　ネットワーキングイベントなどを提供 東京大学協創プラットフォーム開発株式会社 代表取締役社長 植田 浩輔氏のコメント 東大IPCは、「1stRound」の活動をはじめ、大学、企業、VC、政府など幅広いステークホルダーと連携した世界と伍するスタートアップ創出・育成、エコシステム構築を通じて、世界における日本の産業競争力の強化に資するべく活動を展開しています。 グローバル、業界をリードするクラウドテクノロジーの提供及び知見を持つAWSジャパンとの連携によって、大学の優れたシーズの早期事業化の支援をさらに強力なものにします。そして、日本のディープテックの可能性を最大限に引き出し、グローバルでの課題解決を目指すスタートアップ創出、そしてイノベーション・エコシステム構築を目指して参ります。 アマゾン ウェブ サービス ジャパン合同会社 執行役員 パブリックセクター 統括本部長 宇佐見 潮のコメント 東大IPCとAWSジャパンの連携は、起業を志す研究者等や、創業間もないスタートアップ起業に対し支援を提供することで、東京大学を中心としたスタートアップ支援を強化するものです。DeepTechのポテンシャルを解放するべく、この連携により大学の成果研究が素早く社会実装されるモデルを構築し、国内の産業活性化のみならず、グローバルの社会課題解決に貢献したいと考えます。東大IPCとAWSジャパンが日本のイノベーション創出に貢献することを期待しています。 アマゾン ウェブ サービス ジャパン合同会社 スタートアップ事業本部　事業開発部長 Will Leeのコメント 日本のみならずアジア全域においてディープテックへの期待が高まる中、数々の研究シーズを社会実装された東大IPCと連携することでAWSジャパンがより幅広いスタートアップを支援できることを非常に楽しみにしております。日本のみならずグローバルな支援へと拡大できることを期待しております。 *AWS Activate は、スタートアップ企業のジャーニーでのあらゆるステップを簡素化するために設計された無料のツール、リソース、およびコンテンツを、ふさわしいスタートアップ企業に提供するものです。メンバーは登録後すぐに、AWS が厳選した、ビジネスおよび技術的なニーズに関するエキスパートのヒント、トレーニングとサポート、事前構築済みのインフラストラクチャテンプレートなどの特典を受け取ることができます。

左：アマゾン ウェブサービス ジャパン デジタルサービス技術本部 ISV/SaaS ソリューション部 本部長 上原 誠 右：株式会社 Works Human Intelligence Product Div. Advanced Technology Dept. Dept長/VPoT 加藤 文章 氏 AWS には Prototyping Program というお客様のプロジェクトの加速を支援するプログラムがあります。このプログラムでは AWS の Prototyping Engineer が、お客様の課題に合わせたシステムのプロトタイプを開発します。株式会社 Works Human Intelligence (以下、WHI) ではこれまで Prototyping Program を複数回活用しており、プロトタイピングという活動自体に有用性を感じていただき、社内で同様のプロトタイピングチームの立ち上げに取り組まれました。 今回は、WHI へのサポートを行うアマゾン ウェブサービス ジャパン デジタルサービス技術本部 ISV/SaaS ソリューション部 本部長 上原 誠が WHI Product Div. Advanced Technology Dept. Dept長/VPoT 加藤 文章 氏にプロトタイピングチーム立ち上げについてお話を伺いました。 本対談のサマリ 会社の主力製品の改善と保守に専念する開発チームとは別に、新しい技術の導入や新製品の開発を担当するプロトタイピングチームを立ち上げた。このチームでは、新しい技術の検証や新製品のプロトタイプを作成し、製品化の可否を早期に判断することができる。また、若手エンジニアの育成にも役立っている。プロトタイピングチームの活動を通して、技術的負債の解消や新しいビジネスチャンスの獲得が期待できる。今後は各製品チームにもプロトタイピングチームを設置し、全社的に新しい取り組みを推進していく計画である。 プロトタイピングチーム立ち上げのきっかけ 上原：プロトタイピングチーム立ち上げの背景を伺うにあたって、まずは WHI の会社概要などを簡単に教えてください。 加藤：WHI では COMPANY という製品を約 25 年前から作っています。この COMPANY という製品は大手企業向け HR 製品で、人事給与・ワークフロー・勤怠・タレントマネジメント（タレマネ）などのサービスがあります。元々はパッケージ製品で、現在は SaaS 化を進めている状況です。 上原：約 25 年間というとかなり長い年月ですね。アプリケーションもかなり大規模かと思います。アプリケーションの開発状況や今回のプロトタイピングに取り組んだ背景を教えてもらえるでしょうか？ 加藤：COMPANY は製品としての歴史が長く幅広い人事領域業務を網羅する大きな製品のため、ソースコードの量も多くなっています。そのため、 開発メンバーはその機能改善や保守を続けていくことに⼤きな⼯数を割いています。特に⼈事給与の領域は法改正対応が毎年入るためそれもかなりの⼯数を取られてる状況です。 一方で、人的資本経営が推進されている中で、HR 製品に対するお客様のニーズが多様化しており、これに応えるために機能追加や改善をしていく必要があります。そこで、生成 AI やブロックチェーンなどの新しい技術をいかに早く取り入れていくかが重要ですが、先ほどお話しした通り、どうしても既存機能の改善や保守には多くの工数がかかってしまうため、機能改善や保守をしつつ新しい技術の導入速度を高めるための取り組みを強化する必要がありました。これに対し、製品の保守をしているチームの外側から、プロトタイピングチームが新技術をどのように製品に取り入れるかの検証を早いサイクルで回していけるため、プロトタイピングチームはこの課題に有効な組織になると考えています。 上原：いわゆるスタートアップのような俊敏性を組織として持つようなイメージですね。 先ほどの背景や課題がプロトタイピングチームの立ち上げを検討するに至った経緯になるかと思いますが、実際に組織立ち上げに踏み切ったきっかけなどはありましたか？ 加藤：2023 年はじめに新たな経営戦略とビジョンが発表され、それに対して何か新しいことに取り組むことができないか悩んでいたところ、 WHI と AWS で新しい取り組みをできないか議論する会を AWS の営業さんから設定いただき、その後の懇親会で、上原さんとお話しして、悩みや思いなどに共感いただいたのをきっかけにこの取り組みに繋がりました。 上原：ちょうど 1 年ほど前に目黒の中華屋さんで意気投合して盛り上がって、プロトタイピングをやろうとなりましたね (笑) トップからのダイレクションがあって、何かしら具現化しないといけないという場面で、そこに AWS が関われたのは有り難かったです。具体的なアクションを共に議論して、組織立ち上げに貢献できたことは AWS としてもエキサイティングで嬉しいことでした。 上原：これまでの話に出てきた部分もありますが、あらためてWHI でのプロトタイピングチームはどのようなものを想定していて、どのようなメリットを期待されていましたか？ 加藤：プロトタイピングチーム立ち上げのメリットとして大きく 2 点を考えていました。 まず 1 点目は、多くの開発メンバーは COMPANY の保守開発がメイン業務であり、新しい技術を活用した機能改善にあまり取り組めていないので、そこに対するアプローチとして期待していました。 2 点目はエンジニアの教育に対するメリットです。現状、若手のエンジニアはコードを書く量が少なく、機能追加や不具合修正に対して、どう実装するかの設計やどういう機能を追加していくかなどで既存コードを確認する作業が多くなっています。そこで早いサイクルでコードを書く機会を作っていきたいと考えました。 上原：既存コードの改修も非常に重要なタスクですよね。そのため、相対的に新しい技術に触れたり教育したりする機会が少なくなってしまうのは難しい課題ですね。 立ち上げに向けての取り組み 上原：組織としてプロトタイピングチームを立ち上げることは簡単ではなかったと思います。実際にはどのように実現していったのですか？ WHI 社内での交渉など含めて、どのように立ち上げてスタートに至ったのか詳しくお伺いしたいです。 加藤：時期としては構想開始が 2023 年 2 月で、実際にチームが立ち上がったのは 2023 年 7 月なので、約 5 ヶ月間です。 2023 年 1 月から Tech Lead Dept. という部門の部門長を私が引き継いでいたのですが、部門 (Dept.) とその配下のグループ (Grp.) の名称と業務内容やミッションをより合致させていきたいという思いがありました。そこで、7 月に組織を大きく変えることを計画していました。その中で、どのように変えていきたいか、どのようなミッションを持たせたいかを各マネージャーや私の上長と会話していました。加えて、このプロトタイピングの活動もフィットしそうだったため、7 月の組織改変のタイミングで取り込めるように進めていました。 上原：プロトタイピングという新しい取り組みのため、それを理解してもらうことやマインドセットを変えるというのは難しかったと思います。どのようにこの取り組みの理解やマインドセットを整えていったのですか？ 加藤：すぐ失敗して取り組むという Fail Fast の考えを持っている適任のマネージャーがおり、ちょうど 5 月からリソースを割ける状況だったため、その方にプロトタイピングチームのマネージャーを依頼しました。そして、Training & Prototyping Grp. というグループ名で設立しました。また、マネージャーに加えてメンバーも 2 名に入ってもらいましたが、両名とも新しいものを取り入れるマインドを持っていて、そういうのが好きなエンジニアで適性があったというのも大きいですね。 上原：なるほど、素養がある方をアサインしたのですね。適正のあるメンバーがいなければ考え方からインプットする必要があるので、そこがクリアできていたのは大きいですね。 今後は、メンバーの拡充などは考えているのですか？ 加藤：実は既に 1 名追加しています。中途で新しく入ってきたエンジニアが、適性があり相性が良かったのでこのチームに入ってもらいました。チームを徐々にストレッチさせているところですね。 上原：入社後にまずはプロトタイピングを 1 件こなすというオンボーディングプロセスの一環にしてみるのも面白い考えかもしれませんね。 加藤：そうすると Training & Prototyping Grp. というグループ名にもある通り、育成という目標も相性良く達成できそうです。 実施したプロトタイピングとそこでの反応 上原：具体的に実施されたプロトタイピングの内容を教えてください。 加藤：チーム立ち上げ後の 2023 年 7 月から 2024 年始めまでに完了したプロトタイピングは 2 件で、AWS のソリューションアーキテクト 松岡さんにも支援いただきました。 1 件目はタレントマネジメントシリーズの研修管理製品の連携機能に取り組みました。タレマネチームには若手のエンジニアがいたので、プロトタイピングチームと一緒になって素早く完了させました。7 月末から始まって、9 月には完了しています。タレマネチームに引き継ぎも完了して、Training の役割も果たせていると言えます。 上原：当初の目標であった Training の役割も果たせているのは素晴らしいですね。2 件目はどういったものだったのでしょうか？ 加藤：2 件目は職歴・学歴などの経歴情報の信頼性を担保する機能の検証です。結果的に、フレームワークが未成熟だったり、仕様が固まっていなかったりして、すぐに製品化は難しいという意味で失敗にはなりましたが、Fail Fast の考えですぐに失敗できたおかげで、時期を見て再開するという判断材料になりました。 上原：まさにプロトタイピングの考えに基づくものですね。新しい技術を取り入れる際に失敗は必ずあり得ることだと思います。その失敗についてはどう捉えていますか？ 加藤：早めに失敗できてよかったです。その技術の採用を決定してから失敗するのは影響が最も大きいので、早めに判断ができてよかったです。 上原：事業部がやると決定してから戻すのは難しいと思うので、プロトタイピングで判断出来たのは大きいですね。 加藤：元々 4 週間ほどで判断する予定だったのですが、実際やってみると多くの調査が必要で長期化してしまいました。 なんとか実現しようとメンバーが尽力してくれた結果、仕様の深い部分の調査などが発生して、そこまで深くやり始めると時間がいくらあっても足りないという状況になりました。実現できるように深い部分の調査をするのは非常に重要ですが、早期に可否の判断を下すこともプロトタイピングの目的であるので、なんらかの区切りを設けてその範囲内でできる限りのことをやるといった工夫が必要だなと感じました。 そういった点で、AWS のプロトタイピングでやられているように、期間を区切るというのはとても重要だと思いました。今後は適切に期間を区切って実施した上で、判断材料にできれば良いなと思っています。 上原：なんらかの区切りは必要ですよね。リソースを無限にかける訳にもいかないですし、どこかで成否を判断しなければいけないので。複数回のプロトタイピングを実施したからこその学びですね。 では、実際にプロトタイピングを実施したメンバーは、どのような反応や感想だったのでしょうか？ 加藤：今までこのような取り組みがなく手探りでの挑戦だったのですがメンバーからはポジティブな意見が多かったです。プロトタイピングの依頼を受けて実装し、引き継ぐためにドキュメントをまとめる、といった作業を期間を区切って実施することはメンバーにとって新しい経験で面白かったようです。 また、案件が完了するとその後すぐに別件が入ってくるという点に対して、「自分の特性に合っていて楽しい」というメンバーからの声も上がっています。ビジネスを形にしていくという重要な領域を担っている点にもやりがいを感じているようです。 上原：エンジニアにとって良い刺激にもなっているのは嬉しいです。 今回のプロトタイピングチーム立ち上げに対しての AWS からのご支援はいかがでしたか？ 加藤：とても良かったです。 AWS もリーダーシップ・プリンシプルの中で「Customer Obsession」を掲げており、お客様目線を持たれていると思いますが、今回の支援はまさにこちらの課題を聞いてもらって、一緒に解決に向けて伴走してくれていると感じました。 上原さんをはじめ、実際にプロトタイピングを実施した松岡さんと一緒にやれて良い経験になりました。 プロトタイピング実施とチーム立ち上げの成果 上原：プロトタイピングで当初想定していたような成果がありましたか？実際のアウトプットやメンバーの成長など加藤さんにとっての成果を教えてください。 加藤：2 件のプロトタイピングで新機能や新製品の開発の加速に寄与できました。お客様に早く良いものを提供できるようにすることがプロトタイピングで真に実現したい事なので、そこに貢献できたのは成果と言えます。 上原：AWS の Prototyping では Culture of Experimentation というマインドセットがあります。正にこれに通ずる考えだと思いました。AWS には Prototyping Program を提供するプロトタイピングチームがあり、私のチームにも同様のプロトタイピングチームを立ち上げていて、両方のチームで一貫しているのはこの Culture of Experimentation というマインドセットを大事にしている点です。これは、細かい試行を積み重ねることで、結果としてより良いサービスをより早く作ることに繋げるという考えです。 加藤：正に WHI でも重要視している点と同じですね。 上原：別の観点で、新しい技術を取り入れることは技術的負債に対しても重要な要素の1つかと思うのですが、プロトタイピングでの新しい取り組みは技術的負債の解消に繋がっていくものでしょうか？ 加藤：現在、プロトタイピングチームには新しい製品を早く作るという役割で動いてもらっていますが、今後は既存の各製品に対してプロトタイピングチームが連携することで、負債の解消に寄与できると思います。コードは書いた瞬間から負債と言われるので完全に解消するとは言いづらいですが、古くなってしまったものを新しく変えていく際にプロトタイピングチームが貢献できると考えています。 上原：既存のコードを置き換えていくのは大変な作業だと思うのですが、理想的には開発プロセスの中で負債がたまらないようにしていくのがベストだと思っています。そのプロセスの中にプロトタイピングをうまくはめ込めると良さそうに感じましたが、プロトタイピングを開発プロセスの中に入れ込めそうですか？ 加藤：入れ込めはするのですが、プロトタイピングとは別で技術的負債を解消するプロジェクトが動いており、それらはプロセスに組み込もうとしています。そのプロジェクトで実現が難しい場合にピンポイントでプロトタイピングチームが入って連携するという形の方が有効かなと思います。 上原：プロトタイピングを組織的に取り組んできたことで、様々な気づきや学びがあったことが分かりました。 今回の活動を経て、プロトタイピングがどのようなフェーズの組織にフィットしそうかという感触があれば教えてください。 加藤：WHI のように主力製品を持っていて、その主力製品の改修にリソースを多く割いているが、何か変えなければいけないという課題を抱えている会社にフィットするかなと思います。また、それに対して何かを変えることにトップが積極的な会社だとより良いと思います。 上原：仰る通りですね。トップから「プロトタイピングチームを組成することがメインプロダクトの開発リソースが減る」と見られると難しいですよね。トップも含めて Culture of Experimentation の考えを持っているかが大事そうですね。 WHI は会社の規模が大きく、エンジニアも多いかと思いますが、どのような規模感の組織にフィットしそうでしょうか？ 加藤：ある程度成熟したプロダクトを持っている企業が良いのではないかと思います。スタートアップなどの組織は通常の開発業務自体がプロトタイピングのような動きに当たるのでプロトタイピングチームは不要だと思います。 また、余力があることも重要ですね。主力製品で収益が出せているからこそ、プロトタイピングなどにリソースを割くことができると思います。 今後の展望 上原：プロトタイピングチームの今後のプランや展望などはありますか？既に人員増加など進んでいると思うのですが、ビジョンがあれば教えて下さい。 加藤：プロトタイピングチームの考えなどは COMPANY のエンジニアにはまだ広まっていませんが、この考えを全エンジニアに広げて、将来的には各部署にプロトタイピングチームを作って、それを教育機関としていきたいと思っています。 上原：集約ではなく各部門に配置するんですね？ 加藤：そうですね。製品群がいくつかある中で、集約して横断的に見る役割を持ったプロトタイピングチームも必要ですが、各製品のアーキテクチャや技術にフォーカスして革新していく際には各組織に閉じてプロトタイピングチームがある方がスピード感を持って早いサイクルで実施できると考えています。 上原：部門ごとの技術スタックや環境に合わせるために、教育機関として各部門に置くのは納得感がありますね。 既存の開発チームとの棲み分けはどのように考えられていますか？ 加藤：各製品を開発しているエンジニアは改修や不具合修正に多くの時間を割いており、新しい機能追加や改善をしたい思いはある一方で、そのチームにいるとそこに時間を割く余裕がないというのが実情です。なので、プロトタイピングを行うグループとして、既存コードの改修以外の機能追加など新しいことに取り組める組織を作るのは有効だと考えています。 上原：人気のグループになりそうですね。 加藤：そこに入りたくて頑張るという雰囲気を作れたら嬉しいですね。そして、プロトタイピングのメンバーを固定せず、ローテーションでみんなにやってもらいたいと思っています。 上原：エンジニアのモチベーションに繋がり、教育の役割も果たせると素晴らしいですね。進展ありましたら是非聞かせてください。 本日はお話を伺わせていただきありがとうございました。引き続きご支援・ご連携させてください。 —- 本ブログの執筆はソリューションアーキテクト 松岡勝也、撮影はソリューションアーキテクト 伊藤威・山崎宏紀が担当しました。

IoT (Internet of Things: モノのインターネット) デバイスの数が指数関数的に増加するにつれ、企業では、さまざまな地理的地域にわたる IoT フリートを管理するために、位置情報を活用できる高度なツールが必要になります。デバイスの位置を知ることは、資産管理や盗難検出のためだけでなく、デバイスが動作していない場合にタイムリーな改善措置を講じるためにも重要です。さらに、位置情報とデバイス状態のメタデータを組み合わせることで、位置固有の接続問題を検出したり、位置別の利用の傾向を理解するなど、IoT フリートについてより深い洞察を得ることができます。例えば、自動販売機や広告キオスクを運営している場合は、ユーザーの利用が多い地理的位置に基づいて、フリートの拡大、アップグレード、広告を優先的に行うことができます。 AWS IoT Device Management の位置インデックス化とジオクエリ機能により、デバイスの最後に報告された位置に基づいてデバイスを検索できます。また、位置情報を活用して、IoT フリートの管理と監視活動を強化することもできます。この位置インデックス化とジオクエリ機能により、特定の地理的領域内に位置するデバイスをリストアップしたり、基準位置に対する近接検索を行ったり、ターゲットを絞った Over-The-Air (OTA) でのアップデートを実装したり、位置に応じたデバイスのパフォーマンス分析を行ったり、望ましい地理的境界外にあるデバイスを特定したりできます。 このブログでは、位置情報データのインデックス作成とジオクエリの使い方を学び、日々の IoT フリート管理業務をサポートする方法を解説します。 フリートインデックスとジオクエリの概要 AWS IoT Device Management は、大規模な IoT デバイスをリモートで監視・管理するためのフルマネージドクラウドサービスです。フリートインデックス機能を使って、 AWS IoT レジストリ 、 AWS IoT Device Shadow 、 AWS IoT の接続性 、 AWS IoT Device Management ソフトウェアパッケージカタログ 、 AWS IoT Device Defender での違反 などの IoT データソースにまたがるメタデータに基づいてデバイスをインデックス化、検索、集約、グループ化できます。位置情報インデックスとジオクエリを使えば、特定の洞察や監視のために位置情報で絞り込めます。 図 1: AWS IoT Device Managementを使用して位置情報を収集、インデックス化、活用するためのリファレンスアーキテクチャ 図 1 は、AWS IoT サービスを使用して位置情報を取り込み、インデックスを作成し、活用するためのリファレンスアーキテクチャを示しています。検索で位置データを使用するには、デバイスの位置情報 (緯度と経度) を 従来のシャドウまたは名前付きシャドウ に保存し、AWS IoT Core Settings で 位置データのインデックス作成 を有効にする必要があります。位置情報は、4 つのサポートされている位置データフォーマットのいずれかに格納できます (詳細については、 サポートされているデータフォーマット を参照してください)。グローバル ポジショニング システム (GPS) が組み込まれていないデバイスの場合は、 AWS IoT Core の Device Location 機能を使用してデバイスの位置を解決できます。次に、 AWS IoT Rules Engine を使用して、デバイスの位置を従来のシャドウまたは名前付きシャドウに格納できます。位置データが IoT デバイス管理サービスによってインデックスされると、Amazon CloudWatch でデバイスフリートの全体的な状態を監視したり、Amazon API Gateway を使用して近くのデバイスを照会したり、デバイスフリートの位置情報に基づく分析と洞察を生成するなどの複数のダウンストリームアプリケーションで使用できるようになります。 ジオクエリでは、フリートインデックスの既存の検索と集約のための API が使用され、さらに入力パラメータ geodistance が追加されています。この geodistance のパラメータは、指定された緯度と経度の座標からの検索半径の境界を指定します。ジオクエリは フリートメトリクス と Amazon CloudWatch と組み合わせることで、時間の経過に伴うトレンドを分析し、事前に定義された閾値に基づいてフリートの状態を監視するためのアラームを作成できます。他の例としては、需要の高い場所で特定の時間に利用可能な電動バイクの数を見つけること、EV 充電器の可用性 KPI を監視すること、デバイスが設置場所から移動したときに警告を受け取ること、規制機関に決済端末の場所を報告すること、太陽電池のパフォーマンスに関する位置に敏感な洞察を生成すること、温度や湿度などの地理的要素によるデバイスの故障を診断することなどが挙げられます。 ジオクエリの概要 次のセクションでは、地理空間クエリ機能の一部を紹介します。この手順では、EV 公共充電インフラのグローバルプロバイダー向けのシステムを開発します。この例では、異なる種類のコネクター、定格電力、充電速度を持つ EV 充電器を提供します。地理空間クエリを使用すると、次のビジネス要件に対応できます。 付近のロケーションにある充電器をニアリアルタイムで発見できる機能。 特定の SLA を維持できるよう、利用可能な充電器の数を監視する。 日々の取引量が一定の基準を超えるチャージャータイプ (レベル 1、レベル 2、レベル 3 – 異なる充電速度を表す) の分布を特定する。 前提条件 以下の手順を完了する前に、次の準備をしておく必要があります。 AWS IoT Core と AWS IoT デバイス管理でアクションを実行するアクセス権と許可を持つ AWS アカウント。 AWS IoT Core でロールを作成および割り当てる IAM (AWS Identity and Access Management) の権限。 AWS CloudShell へのアクセス、および Linux と AWS コマンドラインインターフェイス (AWS CLI) の基本的な知識。 ウォークスルー 初期設定と構成 この節では、EV 充電器を表すための一連のモノを AWS IoT Core に作成します。スクリプトとコードは us-east-1 リージョンを使用します。スクリプトは、モノを作成し、充電器仕様に関連するメタデータを生成します。また、充電器の位置と使用状況に関するデータを含む chargerusage という名前つきシャドウを生成します。最初のセットアップと地理クエリを実行するには、 us-east-1 の CloudShell を使用してください。 AWS Management コンソールにログインし、 CloudShell を開いてください。 次のコマンドを実行して、スクリプトをダウンロードするため Git リポジトリをクローンします。 $ git clone https://github.com/aws-samples/aws-iot-device-management-geoquery.git createResources.sh スクリプトを実行して、EV 充電器のフリートを作成します。 以下のコマンドで指定されているパラメータを使用すると、AWS IoT Core に geoquery-test- という名前の 10 個のリソースができます。 このスクリプトは、後続のスクリプトで使用される一時ファイルもローカルディレクトリに生成します。 $ cd aws-iot-device-management-geoquery $ bash createResources.sh geoquery-test 10 注: 出力でエラーが表示された場合は無視してください。 An error occurred (ResourceAlreadyExistsException) when calling the CreatePolicy operation: Policy cannot be created - name already exists (name=blog_fi_geoquery_policy) updateShadows.sh スクリプトを実行して、モノのシャドウドキュメントを更新します。 $ bash updateShadows.sh フリートインデックスを設定する AWS マネジメントコンソールに移動し、AWS IoT Core を検索してください。 AWS IoT Core ( us-east-1 リージョン) で、左ペインの 設定 を選択します。 フリートのインデックス作成 セクションに移動し、 インデックス作成の管理 を選択します。 モノのインデックス作成 と モノの接続の追加 のチェックボックスを選択します。 画面の一番下に移動し、 更新 を選択します。 次のコマンドを実行して、インデックスの状況を確認します。 $ aws iot describe-index --index-name "AWS_Things" --region us-east-1 indexStatus が ACTIVE になるまで待ちます。 再度 インデックス作成の管理 を選択します。 名前付きシャドウの追加 のチェックボックスを選択します。 名前付きシャドウの選択 の下に chargerusage が表示されない場合は、 モノでシャドウ名を参照 を選択します。 前のセクションで作成された、いずれかのモノを選択します。 リストから chargerusage を選択し、 シャドウ名の追加 を選択します。 インデックスの位置データ に移動し、 新しいフィールドの追加 を選択します。 データパス に shadow.name.chargerusage.reported.config.location を追加します。 シーケンス ドロップダウンリストから Lat, long を選択します。 集計用のカスタムフィールド に移動し、 新しいフィールドの追加 を選択します。 フィールド名 に attributes.type を追加し、 フィールドタイプ ドロップダウンリストから String を選択します。 画面の一番下に移動し、 更新 を選択します。 図 2: フリートインデックスを有効化する AWS IoT Core の設定 ユースケース 1: 近接検索 この節では、 SearchIndex API を使用して、車両所有者が自身の EV に適した近くの充電スポットを見つける方法を実演します。この例では、次のことを前提としています。 このクルマはレベル 1 とレベル 2 の EV 充電器に対応しています。 このクルマは搭載の GPS モジュールにより、現在の緯度経度 (37.723028, -122.375811) を認識しています。 クルマの所有者は、クルマの現在位置から半径 15 マイル以内の適切な充電器を探したいと考えています。 前のステップで使用した CloudShell に移動します。 コマンドプロンプトで次のコマンドを実行します。 aws iot search-index \ --index-name "AWS_Things" \ --region us-east-1 \ --query-string "( \ attributes.type:Level_1 OR attributes.type:Level_2) AND shadow.name.chargerusage.reported.usage.isOnline:true AND shadow.name.chargerusage.reported.config.location:geo_distance,37.723028,-122.375811,15miles" JSON 形式の出力には、クエリ条件を満たす全ての充電器のリストが表示されます。参考のために、出力を一部省略して示します。出力の値は変わる可能性があります。 図 3: search-index クエリの出力 ユースケース 2: 位置情報に基づくフリート監視 このステップでは、フリートインデックス機能のフリートメトリクスを使用して、関心のある地理的領域内の稼働中の EV 充電器の数を監視します。 前のステップで使用した CloudShell に移動します。 以下のコマンドをコマンドプロンプトで実行して、フリートメトリクスをセットアップします。一度作成されると、このフリートメトリクスは 60 秒ごとにデータポイントを生成し、サンフランシスコ (37.723028,-122.375811) から半径 50 マイル以内で電源が切断されている充電器の数をカウントします。 aws iot create-fleet-metric \ --metric-name "OfflineChargers" \ --region us-east-1 \ --query-string " shadow.name.chargerusage.reported.usage.isOnline:false AND \ shadow.name.chargerusage.reported.config.location:geo_distance,37.723028,-122.375811,50miles" \ --aggregation-type "name = Statistics,values = count" \ --aggregation-field "registry.version" \ --period 60 フリートメトリクスをセットアップすると、 OfflineChargers メトリクス が毎分 CloudWatch に送信されるため、それを確認できます。 また、このメトリクスに対して CloudWatch アラームを設定できます。アラームの作成手順は CloudWatch でフリートメトリクスを表示する をご覧ください。 CloudWatch で設定したアラーム閾値を超えると、保守チームへの警告のために複数の通知とチケット作成アクションがトリガーされます。同じプロセスで、異なるクエリ基準を使用して追加のフリートメトリクスを作成できます。 ユースケース 3 : 位置情報に基づく集約情報/洞察 このセクションでは、 GetBucketsAggregation API を使用して、一日あたりのトランザクション閾値を超える充電器の分布を、充電器タイプ (Level_1、Level_2、Level_3) に基づいて確認します。 前のステップで使用した CloudShell に移動してください。 コマンドプロンプトで次のコマンドを実行します。このクエリは、サンフランシスコ (37.723028,-122.375811) の 50 マイル以内にあり、1 日に 25 件を超えるトランザクションがあった充電器を集計します。 aws iot get-buckets-aggregation \ --index-name AWS_Things \ --region us-east-1 \ --buckets-aggregation-type "termsAggregation={maxBuckets=5}" \ --query-string "shadow.name.chargerusage.reported.usage.dailySessions> 25 AND shadow.name.chargerusage.reported.config.location:geo_distance,37.723028,-122.375811,50miles" \ --aggregation-field "attributes.type" 出力は以下の図 4 のようになります。この図は、基準を満たす Level_1、Level_2、Level_3 の充電器の数を示しています。「数」は、デプロイ時によって異なる可能性があります。 図 4: GetBucketAggregation クエリの出力 クリーンアップ これらの演習を完了したら、追加コストの発生を避けるために以下を行ってください。 フリートインデックスを今後使用しない場合、機能をオフにします。 AWS IoT Core ( us-east-1 リージョン) で、左側のメニューから 設定 を選択します。 フリートインデックス作成 セクションに移動し、 インデックス作成の管理 を選択します。 モノのインデックス作成 のチェックボックスの選択を外します。 画面下部に移動し、 更新 を選択します。 cleanupResources.sh スクリプトを実行して、作成した AWS IoT モノを削除します。 $ bash cleanupResources.sh さいごに このポストでは、AWS IoT Device Management を使用してデバイスフリートの位置情報データを検索および監視する方法を学びました。フリートのインデックス作成を構成してデバイスの位置データをインデックス化する方法、インデックス化された位置情報データから洞察を導き出す方法、フリートメトリクスを利用してデバイスフリートを監視し、そのトレンドを表示する方法を学びました。このサンプルを拡張して、クローンした GitHub プロジェクトの aws-iot-device-management-geoquery ディレクトリにある ShadowClient.py を変更することで、充電器のシャドウ (位置、使用状況、可用性データ) を動的に更新したり、フリートデータに位置ベースの分析を実行して位置ベースの接続切断パターンを特定したり、指定された地理的範囲内のデバイスに対して OTA アップデートの対象とすることができます。さらに、AWS IoT Core Device Location の位置解決機能を活用して、GNSS/Wi-Fi/セルラーメタデータから位置情報を解決し、その後位置情報データをインデックス化してジオクエリを利用できます。詳細については、 AWS IoT Developer Guide の 位置情報データのインデックス化 を参照するか、 コンソールにログイン して利用を開始してください。 著者略歴 Reetesh Varshney Reetesh is an IoT Specialist at Amazon Web Services. He works with customers across industry verticals and supports their IoT-enabled business opportunities and the technology that drives their IoT solutions. He has helped customers to develop AWS IoT solutions for Smart Connected Products, Connected Vehicles, and Smart Factories Satej Sawant Satej Sawant is a Software Engineer at Amazon Web Services. He works on AWS IoT Device Management that helps customers remotely search, monitor, and manage their IoT devices at scale. Surabhi Talwar Surabhi Talwar is a Sr. Product Manager at Amazon Web Services. She focuses on AWS IoT Device Management that helps customers remotely search, monitor, and manage their IoT devices at scale. Prior to AWS, Surabhi worked in systems engineering and product strategy at Dish Network, Ericsson, and Meta, and in the telecommunications and media space. この記事は Use location data with AWS IoT Device Management to monitor and manage your IoT fleet の日本語訳です。エンタープライズ事業本部 ソリューションアーキテクトの中西 貴大が翻訳しました。

近年、医療分野でもクラウドサービスの活用が進んでいます。しかしながら、医療情報の取り扱いには細心の注意が必要です。そこで策定されたのが、厚生労働省より策定された「 医療情報システムの安全管理に関するガイドライン 」（以下厚労省ガイドライン）と経済産業省・総務省より策定された「 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 」（以下２省ガイドライン）です。これら 2 つを合わせた 2 つのガイドラインのことを通称３省２ガイドライン、もしくは医療情報ガイドラインと呼びます。 本ブログシリーズでは、ガイドラインの改定のポイントをまとめると共に AWS における医療情報システム構築における技術的なポイントについても取り上げていきます。第 3 弾となる本ブログでは、この医療情報ガイドラインをクラウド上での実践例を解説します。特に、システム事業者の立場から見たガイドライン対応のポイントを概要編と詳説編に分けて整理していきます。 概要編では対応方針の全体像を解説し、詳説編で各ステップごとの具体的な進め方について解説します。なお、本ブログのコンテンツは医療情報ガイドライン準拠を保証するものでは無く、ガイドライン準拠におけるヒントを提示することを主目的としています。 本ブログシリーズの各種リンクはこちら。 医療情報ガイドラインの改定から読み解くクラウド化 医療情報ガイドラインをクラウド上で実践する – ネットワーク編 Part 1 医療情報ガイドラインをクラウド上で実践する -概要編- 医療情報ガイドラインをクラウド上で実践する -詳説編- ガイドライン対応する上での課題 医療情報ガイドラインは、医療情報と呼ばれる患者情報を扱う情報システムの適切な管理・運用方法を定めたものです。具体的には、診療録や検査画像、看護記録など、患者に関する様々な医療情報を対象としています。医療情報ガイドラインについての概要については本ブログシリーズの第 1 弾 「医療情報ガイドラインの改定から読み解くクラウド化」 を参照ください。 この中でも特に、システム・サービス提供事業者向けに策定されているガイドラインが経済産業省・総務省より策定された「 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 」（以下 2 省ガイドライン）です。2 省ガイドラインでは、下記のように策定方針が定められており、過去のガイドラインと同等の安全管理水準は保ちつつも一律に要求事項を定めることはしないといった言及がされています。その達成する方針としてリスクマネジメントプロセスの定義がされています。 他の規格・ガイドラインとの整合性の確保に留意しながら、過去のガイドラインの要求事項と同等の安全管理水準が確保されるようにする 医療情報システム等の特性に応じた必要十分な対策を設計するために、一律に要求事項を定めることはせず、リスクベースアプローチに基づいたリスクマネジメントプロセスを定義する セキュリティ対策の妥当性と限界について、正しい共通理解と明示的な合意のもと医療情報システム等を運用するために、リスクコミュニケーションを実施できるようにする 医療情報システム等に関連する法令の求めに対して、セキュリティ対策の抜け漏れを防止するために、医療情報の取扱いにおいて留意すべき点や制度上の要求事項を明らかにする 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 1.1 版 （p.4) より抜粋 このように、一律の要求事項を定めないリスクベースアプローチによりクラウドやオンプレミスといった医療情報システムなどの特性に応じた柔軟なシステム設計が可能になりました。一方で、画一された要求事項が定まっていないことにより「どこまでやれば対応したと言えるのかが分からない」「リスクベースアプローチと言うが、具体的にどうやって対応を始めればいいのか分からない」と感じるサービス提供事業者もいらっしゃいます。我々ソリューションアーキテクトに対しても日々このような問い合わせをいただきます。 このあとの章では、医療情報ガイドラインの対応例について触れながら事業者としてのの対応方針に触れていきます。医療機関側から見た対応例については別ブログで取り上げる予定です。 サービス提供事業者が果たす責任 2 省ガイドラインによるとサービス提供事業者は、法律的観点から下記の義務を負います。 個人情報保護法に基づき、医療情報の善管注意義務・守秘義務・安全管理措置を講じる義務がある。 委託契約に基づき、医療機関等が患者に対する安全管理義務を履行するために必要な情報を適時適切に提供する義務がある。 情報セキュリティ事故発生時には、個人情報保護法に基づき危機対応義務と報告・通知する義務がある。 また、医療情報システム等の一連のプロセス（ガイドライン本文ではライフサイクルと表記）における義務と責任として、「対象事業者は説明義務を果たすために、医療機関等との間で「共通理解」と「明示的な合意」の形成を行う」必要があります（ 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 1.1 版 p.14-p.19）。 上記の義務を遂行する中で、医療機関等への情報提供と合意形成を行うことは必須です。この適切な合意形成をするにあたって、作成する資料の例として「サービス仕様適合開示書」や「サービスレベル合意書 (SLA)」等があります。これらの文書では、サービスの概要や性能、セキュリティ対策、障害時の対応等について詳細に記載する必要があり、合意形成を行う上で重要な書類となります。ガイドラインではこれらの文書に加えて共通理解を形成することの重要性を説いています。 さらに、厚労省ガイドラインにおいて事業者確認用の「 医療機関におけるサイバーセキュリティ対策チェックリスト 」や「 （事業者確認用）薬局におけるサイバーセキュリティ対策チェックリスト 」において医療情報セキュリティ開示書（MDS/SDS）の提出に関するチェック項目が盛り込まれています。 上記で言及された書類を作成していくフローの具体例に触れます。あくまで一例ですので、 冒頭の繰り返しになりますが絶対的な正解ではなく読者のみなさまがガイドライン対応を進める方針を策定する際の参考にしていただくことを目的 としています。 リスクマネジメントプロセスフローの概要 2 省ガイドライン本編では対象事業者が行うべきリスクマネジメントプロセスのステップとして「リスク特定」「リスク分析」「リスク評価」「リスク対応の選択肢の選定」「リスク対応策の設計・評価」「説明・合意形成」に言及してます。これらを大まかに分類して整理すると下図で示したフローになります。 医療情報システム向け AWS 利用リファレンス 概要資料と２省ガイドラインの中身をベースに作成 各種ステップをまとめて大きく「リスクアセスメント」「リスク対応「リスクコミュニケーション」と３つのフェーズに分けています。リスクアセスメントフェーズでは、医療情報システム等を提供する中でのリスクの特定・分析・評価を通じて対応すべきリスクについての洗い出しを行います。次のリスク対応フェーズでは、洗い出されたリスクに対しての具体的な対応方針を決め、それぞれのリスクに対する対応と残存リスク等に関しての文書化を目指します。最後のリスクコミュニケーションではリスクアセスメント・リスク対応で作成した文書化などを通じて、医療機関等との間での役割分担・受容したリスク内容等について必要な情報を説明した上で合意形成を行います。 まとめ 概要編となる本ブログでは医療情報ガイドラインの概要とサービス提供事業者の立場からの対応方針の概要について概説しました。次の 詳説編 では、リスクマネジメントプロセスの各段階の具体的な進め方ついて、リスクアセスメント、リスク対応、リスクコミュニケーションの各プロセスの実践的な進め方を解説します。 著者について 尾原 颯 (Ohara, Soh) は AWS Japan にて主にヘルスケア系スタートアップに対して技術支援をしています。好きなサービスは Amazon SageMaker と Amazon HealthLake です。 片山 洋平 (Yohei, Katayama) は AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。

本ブログシリーズでは、厚生労働省より策定された「 医療情報システムの安全管理に関するガイドライン 」（以下厚労省ガイドライン）と経済産業省・総務省より策定された「 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 」（以下２省ガイドライン）を合わせた通称３省２ガイドライン（医療情報ガイドライン）の AWS における医療情報システム構築における技術的なポイントについても取り上げていきます。 第 3 弾となる本ブログでは、この医療情報ガイドラインをクラウド上でどのように実践していくかを解説します。 概要編 ではサービス提供事業者の対応方針について全体像を見ました。詳細編では 1 つ 1 つのステップについて細かく見ていきます。 本ブログシリーズの各種リンクはこちら。 医療情報ガイドラインの改定から読み解くクラウド化 医療情報ガイドラインをクラウド上で実践する – ネットワーク編 Part 1 医療情報ガイドラインをクラウド上で実践する -概要編- 医療情報ガイドラインをクラウド上で実践する -詳説編- リスクマネジメントプロセスのおさらい 概要編では対象事業者が行うべきリスクマネジメントプロセスのフェーズとして「リスクアセスメント」「リスク対応」「リスクコミュニケーション」に大きく大別できることを紹介しました。次の章からは各フェーズとその中のステップの中身についてより細かく見ていきます。 医療情報システム向け AWS 利用リファレンス 概要資料と２省ガイドラインの中身をベースに作成 さらに各ステップにおいて参考にできる資料とのマッピングを下図に示します。いくつか参考資料が出てくるため、このマッピングを念頭に置きながら読み進めていただくと整理しやすいでしょう。 各フェーズにおける対応方針 ここからはリスク対応フローの各フェーズにおける対応方針例を取り上げていきます。しかしながら、いきなり全てのステップを 1 から遂行しようとすると全体像が見えなくなることも多いです。どのような観点で対策を進めていくのかの全体像を把握するためにも、各フェーズに進む前に厚生労働省より公開されている「 医療機関におけるサイバーセキュリティ対策チェックリスト 」や「 （事業者確認用）薬局におけるサイバーセキュリティ対策チェックリスト 」に一通り目を通すことをお勧めします。例えばですが、「医療機関におけるサイバーセキュリティ対策チェックリスト」では、「事業者内に、医療情報システム等の提供に係る管理責任者を設置している。」「退職者や使用していないアカウント等、不要なアカウントを削除している。」といった項目が存在しています。 リスクアセスメント・リスク対応フェーズ 参考資料 リスクアセスメント・リスク対応フェーズでは、主に特定したリスクに対してどのように対応するかの方針を決めた上で、対応したリスク一覧を文書化するところまで行います。このフェーズにおいて対応工数を減らすために有用な資料を 2 つご紹介します。 1 つ目が 2 省ガイドラインで公開されている「 別紙2 統合前ガイドラインにおける対策項目一覧と医療情報安全管理ガイドライン6.0版の対応表 」（ EXCEL形式 ）（以下別紙 2）です。別紙 2 について 2 省ガイドライン本編では「従前の情報処理事業者ガイドライン及びクラウド事業者ガイドラインの要求事項を医療情報安全管理ガイドラインとの対応関係を踏まえ対策項目として整理・統合した別紙 2 を用い、その全ての対策項目について対応していることを確認をすることは、対象事業者による対策の設計や妥当性の判断、説明義務への対応において必須である。」と言及されており、従前のガイドラインの要求事項を厚労省ガイドラインとの対応関係を踏まえて整理・統合したとあります。さらに整理・統合された「対策項目により対策可能なリスクシナリオ例」についても言及されています。この表を参照することで、リスクシナリオごとの医療機関側の対応とサービス提供事業者側の対応とのマッピングを容易に実施できます。具体的には上図のように大きく３つのパートから成り立っています。 対策項目：対策項目例に関連する従前の情報処理事業者ガイドライン及びクラウド事業者ガイドラインの要求事項を、「人的・組織的」・「物理的」・「技術的」の３つの対策の観点毎に整理・統合した内容。主な実施主体として、対象事業者を想定する。 対策項目により対策可能なリスクシナリオ例：対策項目により対策可能となる、代表的なリスクシナリオを例示 関連する医療情報安全管理ガイドラインの要求事項：関連する厚労省ガイドラインの要求事項。主な実施主体として、医療機関等を想定する。 別紙 2 の概要  別紙2 統合前ガイドラインにおける対策項目一覧と医療情報安全管理ガイドライン6.0版の対応表 より抜粋     2 つ目が AWS パートナー各社様により作成されている「 医療情報システム向け AWS 利用リファレンス （以下 AWS 利用リファレンス）」です。特にその中でも今回は総務省・経済産業省版が参考になります。別紙 2 では AWS に特化した内容についての言及はされていないため、AWS 利用リファレンスを参考にすることで AWS の利用を加味した対応方針の策定に役立ちます。AWS 利用リファレンスは複数のシートから構成されています。 リスクアセスメント 1.1 リスクアセスメントシート: リスクアセスメントに使用するワークシート 1.2 リスク対応リファレンス: 特定したリスクに対する対策例 1.3 リスクシナリオ例: ガイドライン別紙2記載の最低限確認すべきシナリオ例 制度上の要求事項: ガイドライン6章「制度上の要求事項」の要求事項への対策例 AWS サービス関連情報: スク対策に活用できるAWSサービスを列挙・概要を解説 特に「リスク対応リファレンス」シートを利用することで、各リスクシナリオごとの対応策の具体的な方針のヒントが得られます。例えばですが「正当な利用者以外により、医療情報システム等上の情報が閲覧・操作される。」といったリスクシナリオに対して対策の概要として「アクセス記録の見直し・検査などによる不正アクセス有無の確認」が挙げられています。これに関連するサービスとして AWS CloudTrail や Amazon GuardDuty に触れている他、「情報システム・サービスの提供事業者の対応事項」や「医療機関等へ対応を求める事項」とに分かれて AWS に閉じない形での解説もあります。 医療情報システム向け AWS 利用リファレンス 1.2. リスク対応リファレンス より抜粋   参考資料を用いたリスクアセスメント・リスク対応 上記２つの資料を活用したリスクアセスメント・リスク対応フェーズの進め方の例として、AWS 利用リファレンスの 1.1 リスクアセスメントシートを軸に作成いただく方法が考えられます。 まずは、D、E 列の「特定したリスク」のところに別紙 2 で挙げられているリスクシナリオをベースにリスクの洗い出しを行います。ただし別紙 2 で言及されているリスクシナリオは 2 省ガイドライン本文で「ただし、当該リスクシナリオ例はあくまで参考例であり、関連するリスクと対策が他にも存在しないかを対策の設計を行う際に確認すること」と記載されているため、提供しているサービスの形態に応じて適宜加筆修正の必要があることには注意が必要です。そして洗い出されたリスクに対してリスク分析を実施します。リスク分析では影響度・顕在化率をベースにリスクレベルを算出します。リスクレベルについては、 2 省ガイドライン p.27 にある分類例の表などを参考にしながら算出します。算出したリスクレベルに応じて対応要否を判断します。 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン1.1版 より 表 5-2 を抜粋 例えばですが、下記のような形での記載例が考えられます。 これらの特定したリスクに対して、リスク分析が完了したら、対応が必要なリスクに対しては別紙２の「対策項目」や AWS 利用リファレンスの「1.1 リスク対応リファレンス」を参考にします。この時、ブログシリーズの第２弾「 医療情報ガイドラインをクラウド上で実践する – ネットワーク編 Part 1 」でも言及されている 責任共有モデル を参考に各関係者ごとの責任分界を意識して、事業者・医療機関・AWS の実施する対策内容をそれぞれ項目を分けて記載していきます。各ステークホルダーごとに何をすべきなのかを明記することで、特に「1.1 リスク対応リファレンス」では「AWS が実施している対策」「情報システム・サービス提供事業者の対応事項」「医療機関等へ対応を求める事項」についての記載があるため、これらの項目を参考にしながらアセスメントシートの項目を埋めていきます。下図は参考資料がリスクアセスメントシートでどのように対応づけができるかを簡易的に示した図となります。 上記対応を進めることで、リスク対応を一覧化した文書を作ることができます。対応ができていないところについては対応を進めていきます。 リスクコミュニケーションフェーズ リスクコミュニケーションフェーズでは、リスクアセスメント・リスク対応フェーズで行ったことをベースに、医療機関等に対する説明義務を果たします。この際、医療機関側の関係者には必ずしもシステムの専門家ではない方々も含まれることの考慮が必要です。システムの運用業者と開発業者が異なる場合は、それぞれの立場の関係者全員を巻き込み、利用者の目線も取り入れながら説明を行うことが重要です。特に、意思決定者の関与は欠かせません。関係者全員が会議を通じて意識共有をすることを目指しましょう。また、リスク状況が変化することも伝え、継続的なリスクコミュニケーションが求められます。 提出すべき書類の作成・提供や説明する会議体などに決まりは存在しませんが、いくつか参考になる文書例があります。2 省ガイドラインでは情報提供を行う文書例として「 別紙1 ガイドラインに基づくサービス仕様適合開示書及びサービス・レベル合意書（SLA）参考例 」（ WORD形式 ）を示しています。また、一般社団法人日本画像医療システム工業会 （JIRA）および一般社団法人保健医療福祉情報システム工業会（JAHIS）による「 製造業者/サービス事業者による医療情報セキュリティ開示書チェックリスト 」 （以下、MDS/SDS）があり、「当該チェックリストが対象とする医療情報システム等を提供する対象事業者においては、当該チェックリストを参考とすることが有効である。 」としています。このチェックリストでは、チェックリスト本体だけでなく各項目に関する補足事項を記載する備考記載欄があり、解説が充実しています。 作成した資料を使って説明する際は、説明を行った証跡を残すことも意識します。万が一のインシデントの際の「言った、言わない」問題についても対処できます。 まとめ 本ブログでは、医療情報ガイドラインの概要とリスクベースのアプローチの背景を確認しました。その上で、サービス提供事業者としてガイドライン対応を進める際の方針やリスクアセスメントからリスクコミュニケーションまでの一連のフローを解説しました。ガイドライン対応においては、リスクの特定から対応策の検討、最終的な合意形成まで一貫したプロセスで臨むことが重要です。本ブログが、読者の皆様のガイドライン対応の一助となれば幸いです。 尾原 颯 (Ohara, Soh) は AWS Japan にて主にヘルスケア系スタートアップに対して技術支援をしています。好きなサービスは Amazon SageMaker と Amazon HealthLake です。 片山 洋平 (Yohei, Katayama) は AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。

Amazon DynamoDB はフルマネージド型のNoSQLデータベースであり、高速で予測可能なパフォーマンスとシームレスなスケーラビリティを提供します。さまざまな業界のお客様が最適なデータベースとしてDynamoDBを利用しています。 多くのEdTech企業が、試験の点数や講座の進捗状況を追跡するための永続的なデータストアとしてDynamoDBを利用しています。学生が進級していくにつれて、特定の教科の教材との関わり方や試験の得点が変化します。授業や課程を修了すると、学生が過去の教育リソースにアクセスする頻度は大幅に減りますが、コンプライアンスまたは契約上の義務により、EdTech企業は長期間（多くの場合5年以上）にわたって学生が利用できるようにしておく必要があります。このような、データアクセスパターンは教育分野にとどまらず、さまざまな業界のお客様に共通する課題です。そのため、DynamoDBのデータアクセシビリティを維持しつつコスト効率の良いストレージソリューションへの需要が高まっています。 DynamoDBはデータをテーブルに整理し、標準とStandard-Infrequent Access (標準 – IA)という 2 つの異なるストレージクラスを提供します。標準テーブルクラスはデフォルト設定で、一般的にほとんどのワークロードに適しています。一方で、標準-IA テーブルクラスは、アクセス頻度の低いデータを格納するテーブル専用に設計されています。標準-IAテーブルクラスでは、保存されているデータのギガバイト (GB) あたりのコスト効率が高まります。データが古くなり、アクセス頻度が低くなるにつれて、標準テーブルクラスから標準-IA テーブルクラスへの移行はコスト効率の高い戦略になります。組織は、標準テーブルクラスと同じパフォーマンスと統合機能を確保しながら、ストレージコストを節約できます。このアプローチにより、企業は DynamoDBのストレージ機能を効率的に利用しながら、コスト最適化とデータ可用性のバランスを取ることができます。ストレージがコストの約50%以上を占める DynamoDBテーブルを所有しているお客様は、データを標準-IAテーブルクラスに移行することを検討する必要があります。 DynamoDB標準テーブルクラスと標準-IAテーブルクラスの詳細な料金例については、料金ページの さまざまなテーブルクラスを使用した例 をご覧ください。 このブログでは、 Amazon DynamoDB Streams 、 DynamoDB 有効期限 (TTL)、および AWS Lambda を使用して標準テーブルクラスから標準-IAテーブルクラスにデータをアーカイブするためのカスタマイズされたソリューションを作成するためのプロセスについて説明します。 ソリューション概要 DynamoDB StreamsとLambdaの機能を組み合わせることで、標準テーブルクラスに加えられた変更をキャプチャし、それらの変更に基づいた特定のアクションをトリガーすることができます。TTLを使用すれば、データが一定の経過時間に達したときに標準テーブルクラスで自動的に期限切れとしてマークし、期限切れのデータを含むレコードをDynamoDB Streamsに生成することができます。その後、Lambdaのイベントフィルタリングにより、DynamoDB Streamsからの期限切れデータイベントのみを選択し処理することができます。このプロセスにより、不要な処理やコストを回避しながら、期限切れデータを効率的に処理することで、標準-IAテーブルクラスに移行することができます。 次の図はこのソリューションのアーキテクチャを示しています。 ワークフローには次のステップが含まれます: DynamoDB TTLは、アイテム属性に基づいて期限切れのアイテムを標準テーブルクラスから削除します。 DynamoDB Streamsは、期限切れのアイテムを含むストリームレコードを生成します。 Lambdaは DynamoDB Streamsからの削除イベントを処理します。Lambdaイベントフィルタリングでは、Lambdaは DynamoDB TTLからの削除イベントによってのみ呼び出されます。 データは標準-IA テーブルクラスに書き込まれます。 DynamoDB TTL を使用したデータの削除 DynamoDB TTLは、DynamoDB内でデータのライフサイクルを管理する便利な方法を提供します。TTLを使用すると、テーブル内の各アイテムにタイムスタンプを割り当てて、そのアイテムがいつ期限切れになったか、不要になったかを示すことができます。指定したタイムスタンプが経過すると、DynamoDBはアイテムをテーブルから自動的に削除するため、手動で削除する必要がなくなります。TTLの主な利点は、運用上のオーバーヘッドなしに期限切れのアイテムや不要なアイテムを削除することで、保存されているデータ量を減らすことができることです。これは、時間経過とともに古くなる大量のデータがある場合など、前述のようなシナリオで特に役立ちます。期限切れのアイテムを自動的に削除することで、テーブルを整理し、ワークロードにとって最も関連性が高く最新のデータのみを保持するようにできます。 重要なことは、DynamoDB は書き込みスループットを消費せずに期限切れのアイテムを削除するため、古いデータを削除する際に追加コストが発生したり、パフォーマンスに影響を与えることはありません。TTL付きのDynamoDBグローバルテーブルを利用する場合では、DynamoDBは全てのレプリカに対してTTLによる削除を複製します。この際、各レプリカリージョンで複製されたTTLによる削除に対して、テーブルに設定されているキャパシティモードとテーブルクラスに応じた書き込みコストが発生します。 DynamoDB Streamsの概要 DynamoDB Streamsは、DynamoDB テーブルのアイテムへの変更を含む時系列ログを提供します。アプリケーションがテーブル内のアイテムを作成、更新、削除すると、変更の記録がテーブルの対応するストリームに書き込まれます。 デフォルトでは、DynamoDB Streamsは DynamoDBのアイテムに対して実行された以下のアクションを収集します。 INSERT – 新しいアイテムがテーブルに追加 MODIFY – 既存のアイテムの１つまたは複数の属性が変更 REMOVE – アイテムがテーブルから削除 ユーザーは、次のオプションからキャプチャするデータを選択できます。 Key attributes only – 変更されたアイテムのキー属性のみ New image – 変更後に表示されるアイテム全体 Old image – 変更前に表示されていたアイテム全体 New and old images – アイテムの新しいイメージ (New image) と古いイメージ (Old image) の両方 DynamoDB Streamsを使用すると、TTLによって期限切れになったアイテムの情報をネイティブに収集し、さらなる処理に使用できます。 DynamoDB TTLでアイテムが期限切れになると、DynamoDB Streamsに次のフィールドを含むレコードが作成されます: Records[<index>].userIdentity.type "Service" Records[<index>].userIdentity.principalId "dynamodb.amazonaws.com" 次に、以下のように、これらのプロパティを Lambdaのイベントフィルターとして追加できます。 "Records": [ ... { "userIdentity": { "type": "Service", "principalId": "dynamodb.amazonaws.com" } } ... ] JSON このイベントフィルタを利用することで、お客様は Lambda関数が DynamoDB TTL削除からのみ呼び出されるようにできます。これにより、関数の呼び出し回数が減り、コスト削減につながります。 Lambdaを利用した、DynamoDB Standard-IA テーブルクラスへの書き込み Lambdaはコードを実行するためのコンピューティングサービスで、サーバーのプロビジョニングや管理は必要ありません。Lambdaはイベントに応じて可用性の高いコンピューティングインフラストラクチャ上でコードを実行し、消費したリソースに対してのみ課金されます。Lambdaは、DynamoDB Streamsを含むさまざまな AWS サービスとすぐに統合できます。 DynamoDB Streamsを Lambda関数のトリガーとして追加 することで、標準-IAテーブルクラスにデータを格納することができます。アイテムの挿入、更新、削除は DynamoDB Streamsに記録され、それに応じてLambda関数がトリガーされます。不要な処理を避けるため、Lambdaイベントフィルタリングを利用して、必要なイベントにのみ応答できます。DynamoDB StreamsはLambdaを含むさまざまな AWS サービスと統合できます。さらに、DynamoDB Streamsからデータを処理する際、Lambdaから呼びだされるGetRecords APIに料金はかかりません。ただし、 AWS Lambda料金表 に従って、Lambda関数の実行時間に応じた標準の料金が適用されます。 まとめ この記事では、DynamoDB TTL、DynamoDB Streams、およびイベントフィルタリング付きの Lambda を使用して、DynamoDB標準テーブルクラスからDynamoDB標準-IA テーブルクラスにデータをアーカイブする方法について説明しました。AWS サービスとネイティブな統合を活用することで、DynamoDB 標準-IAテーブルクラス内にデータをアーカイブするためのフルマネージドで費用対効果の高いソリューションを構築できます。DynamoDB APIを使用してデータへのアクセスを維持しつつ、コールドデータの保存コストを節約したいお客様は、上記のソリューションを実装することが出来ます。 会話に参加しましょう！あなたのフィードバックと経験は私たちとコミュニティにとってかけがえのないものです。以下のコメント欄で洞察を共有したり、質問をしたり、別の視点を提供してください。協力して理解を深めていきましょう！DynamoDB の使用についてさらに詳しく知りたい場合は、 開発者ガイド をご覧ください。 (本記事は 2023/10/13に投稿された Archive to cold storage with Amazon DynamoDB を翻訳した記事です。) 著者について Andrew Chen は、データ分析、機械学習、インフラストラクチャの仮想化に関心を持つEdtech Solutions Architectです。Andrewは以前、経営コンサルティングの経験があり、さまざまなクラウド移行プロジェクトのテクニカルリーダーとして働いていました。Andrewは自由時間には、釣り、ハイキング、カヤックを楽しんだり、金融市場の動向も追っています。 Lee Hannigan は、アイルランドのドニゴールを拠点とするSr. DynamoDB Specialist Solutions Architectです。ビッグデータと分析技術の強固な基盤に裏打ちされた分散システムに関する豊富な専門知識を持っています。DynamoDB Specialist Solutions Architectとして、DynamoDBの機能を活用したワークロードの設計、評価、最適化においてお客様を支援することに長けています。

この記事は “ Key takeaways from Gilead’s Innovation Talk at re:Invent 2023 ” を翻訳したものです。 寄稿:ギリアド・サイエンシズのシニアバイスプレジデント兼 Chief Information Officer (CIO) マーク・バーソン、AWS ヘルスケア・ライフサイエンス担当ゼネラルマネージャー ダン・シーラン。 re: Invent 2023 では、 ギリアド・サイエンシズ の CIO であるマーク・バーソン氏が、「 インダストリー向け生成AI 」をテーマにしたイノベーショントークに、AWS インダストリテクノロジー担当ディレクターであるショーン・ナンディ氏と共に参加しました。 講演では、生成 AI を使用して治療法の飛躍的進歩を加速させるというギリアドのアプローチが強調され、企業レベルでテクノロジーを実現するために、レジリエントなクラウドインフラストラクチャと強固なデータ基盤を確立するというギリアド社の取り組みが紹介されました。 講演のキーポイントは次のとおりです。 生成AI による治療の進歩の促進 製薬会社は、サイエンスイノベーションの最前線で、生死に関わる病気と闘う患者に画期的な治療薬を迅速に提供しなければならないという大きなプレッシャーに常に対峙しています。 しかし、新薬の開発プロセスには通常 10 年以上の時間と、数十億ドルもの費用がかかり、さらに上市までに 90% という恐ろしい失敗確率に直面しています。 生成AIは、新規化合物の同定と設計を加速し、治療法の開発プロセスを最適化することで、創薬を大きく変革することができます。 この新技術は、規制当局への申請、市場アクセス、製品化に関連する手作業属人的な作業や冗長なプロセスを自動化することで、サイクルタイムをさらに短縮できます。 ギリアドは、生成AIがビジネストランスフォーメーションに与える可能性を活用して科学の進歩を加速させ、クラウド、データ、AI の融合を活用したイノベーションを実現する最前線にいます。　同じく、意思決定の強化、効率の向上、クラウドスケールのデータからのインサイト抽出の促進など、ROI の高いさまざまなユースケースに対応する生成 AI ソリューションを模索しています。 「業界の複雑な課題を乗り越えるには、企業が俊敏、かつイノベーティブであり、進化する状況に適応する必要があります。私たちは、手に入れられるあらゆる利点を追求する必要があります。 私たちは生成AIをエンタープライズ企業の視点から模索しており、投資対象となる価値の高い生成 AI のユースケースを特定するためのエンタープライズアプローチを実装しています。」 — ギリアド・サイエンシズ社 CIO、マーク・バーソン氏 創薬の変革：生成AIによるターゲット評価の再構築 ギリアド社は研究開発能力を強化するためにさまざまな生成 AI のユースケースに投資していますが、その中でも最も注目しているユースケースの 1 つがターゲット評価です。 ターゲット評価は、創薬の初期段階における重要なステップです。新薬候補のターゲットとなる生体分子（タンパク質または核酸）の評価と特性評価が行われます。徹底した評価を行い、研究者が成功確率が高い新薬候補について、どのターゲットを研究対象として追求する価値があるかを優先順位付けします。 ただし、このプロセスには、ペタバイト規模のデータをマイニングし、関連するあらゆる研究を特定し、その研究を分析し、研究から得た知見を迅速に適用する必要があります。 ギリアド社は生成 AI を活用して、創薬ターゲット評価プロセスの効率と効果を飛躍的に向上させています。専門の LLM  (Large Language Models) を使用して、膨大な量の医科学文献やデータベースを迅速にクエリして分析しています。 これにより、科学者は自然言語検索を行って研究文献を要約したり、簡単なクエリで分子相互作用をシミュレートしたり、参考文献を含む合成研究レポートを動的に作成して更新したりできるため、最終的にはより安全で効果的な医薬品の開発を加速できます。 #1: LLMツールを使用して、膨大な量の科学文献とデータベースを迅速に分析します #2: 潜在的な創薬ターゲットに関連する研究を特定します #3: ターゲットの特定と検証の初期段階を大幅にスピードアップします 「生成 AI は単にテクノロジーだけの問題ではなく、私たちの働き方そのものを変革しうる存在なのです。」 ギリアド社は、生成AIによって高品質な創薬ターゲット評価レポートを効率的に生成することで、従来までの評価プロセスに必要としていた時間を数か月にまで大幅に短縮できると予測しています。 同社では、これらの LLM、アーキテクチャのパターン、LLMOP (大規模言語モデルオペレーション) を社内の他のユースケースで再利用することも検討しています。 「基本的には、同じだけのリソース配分でより多くのことを行うという考え方です」と Berson 氏は言います。 <左>：出来ること 機械と自然言語を使った対話が可能 標準化された研究レポートの作成 スピードを持った品質評価結果の生成　<右>：利点 要約されたコンテンツ作成が加速される 使いまわしが可能なアキテクチャ−パターンとLLMOpes 他の部門、部署で再利用できる可能性 生成 AI を実現するための強固なクラウドとデータ基盤の確立 まだ生成 AI のモデルをめぐる話題があったにもかかわらず、ギリアド社は早い段階で、強力、かつ競争力のある生成 AI  アプリケーション構築の鍵は、包括的なエンドツーエンドのデータ戦略を実装することにあることを認識していました。 AWS 上に構築された堅牢なクラウドインフラストラクチャにより、ギリアドは事業を効率的に拡大し、迅速かつ機敏にイノベーションを起こすことができます。 同社は コンピューティングとストレージのワークロードの 80% を AWS に移行し 、現在ではミッションクリティカルなワークロードをクラウドで実行しています。 「私たちは、クラウドがもたらすレジリエンス、スピード、スケーラビリティを高く評価しています」と Berson 氏は言います。 「これはギリアド社にとって戦略的なビジネス上の優先事項であり、創薬から製品化までのバリューチェーン全体を変革するためには不可欠です。」 「ギリアド社では、AWS 上に構築されたクラウド、データ、強固な分析基盤の上に 機械学習 (ML) と生成 AI を構築しています。 さらに、MLOps を自動化して ML ライフサイクル全体の効率化を実現しています。」 ギリアド社の エンタープライズデータプラットフォーム では、 ML と生成 AI の機能 を一から作り直すことなく活用できます。 データメッシュアーキテクチャ で運用されるこのプラットフォームは、組織のデータを一元化し、管理を拡大し、組織全体のコラボレーションを促進します。 また、分散型データオーナーシップモデルでは、データに最も近く、現場の状況を理解しているビジネスチームがデータを管理できるようになります。 ギリアド社のデータメッシュのもう 1 つの特徴は、「 データ・アズ・ア・プロダクト（DaaP） 」アプローチです。 組織全体のデータプロデューサーは、エンタープライズデータプラットフォームで 300 を超えるデータプロダクトを公開しています。 これらはデータ利用者がすぐに使用できるようになっており、データが検索可能、アドレス指定可能で、理解しやすく、信頼できる、有用、アクセス可能、安全、相互運用可能であるよう最大限の注意が払われています。 さらに、これらのデータ製品のライフサイクル全体を管理するさまざまなセルフサービスデータソリューションが、分散型データオーナーシップの全体的なコストを削減することで、この戦略全体をサポートしています。 「AWS では、進化するビジネスニーズにより迅速に対応するために、従来のモノリシックなアプローチから脱却して、最新のデータ編成とエンジニアリング手法を導入しています。」 ギリアド社は、機密性の高い患者データを扱うグローバルなライフサイエンス組織として、フェデレーションによる意思決定構造（Federated Decision-Making Accountability Structure）に基づいた強力なデータガバナンス運用モデルにより、データセキュリティとコンプライアンスを強化しています。 「私たちには中央集権的な企業基準とガバナンスがありますが、ドメインのオーナーシップは独自に保たれています」とバーソン氏は言います。 「これにより、変化に機敏に対応し、成長に直面しても ROI と持続可能性を高めることができます。」 ・データ メッシュ アプローチは、かつては大規模なデータを管理するために使用されていました。 ・各ビジネス部門による分析データのドメインオーナーシップ。 ・企業全体でデータを製品として共有する この強固な基盤が整ったギリアドは、AI、機械学習、ディープラーニング、分析の活用を全社的な機能として拡大し、複雑なデータを貴重なインサイトに変換し、分子、創薬ターゲット、疾患間の隠れた関係を明らかにしています。 また、AWS と協力して、データサイエンティストに最新のテクノロジーを提供し、すべての人にとってより健康的な世界を作るという大胆なビジョンに向けて、画期的な治療イノベーションを実現しています。 「私たちが AWS を選んだのは、その技術だけでなく、業界を変革し、共に再定義することに情熱を注いでいるからです。 私たちはまさに、その活動に可能性を実現する力を見出しています。」 将来を見据えた取り組み:生成AI のユースケースをプロトタイプから本番環境に移行 業界がより複雑で創薬ターゲットを絞った治療法に移行する中、今後 3～5 年は創薬における生成 AI の価値を実証する上で極めて重要です。 パイロットからプロトタイピング、本番環境に至るユースケースが増える中、ギリアドは生成 AI の実用的な使用に対する基本指針を確立し、将来を見据えた責任ある AI の使用を確保することに重点を置いています。 Berson 氏はセッションを締めくくりに、生成 AI の流行に乗り出している企業に向けた、示唆に富むアドバイスをいくつか述べました。独自の指針を確立し、当初から経営幹部の関与と賛同を得ましょう。 「生成 AI が 単に IT プロジェクトの一つになるのではなく、ビジネスと緊密に連携して構築され、ビジネス成果でその成功を測るような取り組みになるようにしましょう」と彼は警鐘を鳴らしました。 このre:Invent 2023 イノベーション トークの リプレイはこちら の YouTube でご覧ください。 re:Invent 2023での HCLS のその他の発表と ハイライト ToP10 については、このブログをご覧ください。 著者について Dan Sheeran Dan は AWS のヘルスケア・ライフサイエンスインダストリービジネスユニット (HCLS IBU) を率いており、ライフサイエンス、医療機器、保険者、データサービス、ヘルスケア ISV および OEM のすべての AWS のお客様をサポートしています。HCLS IBU は、お客様が AWS クラウドと機械学習サービス、および AWS パートナーのソリューションを活用して、新しい治療法、診断、およびデバイスを研究・開発し、患者の転帰を改善してより効率的に医療を提供できるよう支援します。2019 年に AWS に入社する前は、慢性疾患の予防と管理のための遠隔医療と機械学習に焦点を当てた 2 つのデジタルヘルススタートアップを設立し、率いていました。Danはシアトル地域に住んでいます。ノースウェスタン大学で経営学修士号、ジョージタウン大学で理学士号を取得しています。 翻訳は Senior Business Development Manager の亀田が担当しました。

Amazon Payment Services (APS) は、中東・北アフリカにおける決済サービスプロバイダーです。セキュアかつシームレスな支払い体験により、企業がオンラインプレゼンスを構築できるようサポートします。 Amazon Payment Services は、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Elastic Container Service (Amazon ECS)、Amazon CloudWatch、Amazon Simple Storage Service (Amazon S3) など、複数の AWS サービスに依存する広範囲かつ複雑なマイクロサービスベースのアーキテクチャを基盤としています。 APS の機能拡大に伴い、サービスの依存関係グラフも拡大し続けています。APS チームは、特定のフローでどのマイクロサービスが利用されているかを分析する、また、マイクロサービスのパフォーマンスと正常性を分析する際に問題に直面しました。このブログ記事では、マイクロサービスアーキテクチャにおいてユーザーリクエストフロー内でパフォーマンス問題を特定するプロセスについて説明します。 APS システムアーキテクチャ APS チームは、リダイレクトページ、カスタマイズされた決済ページ、モバイル SDK など 7 つの加盟店統合フローを扱っています。また、世界中の決済業者や第三者決済サービスプロバイダとの統合も管理しています。APS チームは、顧客のパフォーマンスやレイテンシーの報告される問題への対応を担当しています。全体的なシステムのパフォーマンス改善、ビジネスの成長、スケーラビリティも保証する責任があります。 APS のマイクロサービスアーキテクチャは、支払いシステムのコンポーネントを支払い機能に基づいた小規模で疎結合なシステムに分割するのに役立ちます。これにより、APS チームはお客様のニーズに迅速に対応でき、お客様の問題に対処できるため、システムを柔軟に運用できるようになります。さらに、APS チームは必要に応じて柔軟にスケールアップまたはダウンでき、高い可用性と信頼性を確保しながら APS のお客様に最適なパフォーマンスとメンテナンス性の高いソリューションを提供できるようになります。 マイクロサービスアーキテクチャによる APS の課題 顧客からのリクエストを実行すると、複数のマイクロサービスが呼び出される可能性があり、呼び出されるマイクロサービスの数はフローが意図する機能によって決まります。 APS では対応する複雑なユースケースが多いため、多数のフローに対して膨大な数のサービスに依存関係が生じていました。 これらの問題により、顧客のパフォーマンス問題の根本原因の特定が遅れ、新機能の提供に影響を与えていました。この遅れは、顧客満足度にも悪影響を及ぼしていました。さらに、これがシステムの全体的な安定性に影響を与え、システムの停止にもつながる可能性がありました。 彼らが直面した課題は以下のようなものでした: APS チームは呼び出されたマイクロサービス間の API 呼び出しのレイテンシーメトリクスを継続的に測定して、パフォーマンスやレイテンシーの問題を検出するのが大変でした。 マイクロサービスレベルでのレイテンシーのトラブルシューティングと評価に体系的なアプローチがありませんでした。結果として、パフォーマンスの問題に対処するときは手動でメトリクスの出力や追加のログを加える必要があり、オーバーヘッドと運用コストの増加につながりました。 各マイクロサービス内のコードブロックのパフォーマンスを分析するツールが利用できませんでした。 マイクロサービスをまたいでリクエストのエンドツーエンドの流れを追跡する包括的なツールがないため、APS チームはアプリケーションとインフラストラクチャのパフォーマンスを可視化できず、運用面と事業面の両方で影響がありました。 ソリューションの概要 ソリューションを検討する際、APS チームは先行コストを最小限に抑え、管理のオーバーヘッドを減らすソリューションを求めました。アプリケーションアーキテクチャの性質上、APS チームは信頼性が高く、効率的で、手頃な価格で、長い導入期間やセットアップのプロセスを必要とせずに結果が得られるマネージド サービスを希望していました。APS チームの業務をサポートし、課題を解決するための理想的なソリューションとしてAWS X-Ray が選択されました。AWS X-Ray は、API、SDK、ダッシュボード、および他の AWS 監視ツールとの統合で構成される、分散アプリケーショントレーシングサービスです。 複数のプログラミング言語に対応しており、アプリケーションのコンポーネント構成マップを表示できます。 通常、オペレーションチームは Amazon CloudWatch ServiceLens および Amazon CloudWatch Synthetics と併せて使い、AWS ホストのアプリケーションの遅延や障害原因を特定します。AWS X-Ray を使うことで、オペレーションチームはマイクロサービスアーキテクチャにわたる遅延、スロットル、エラー率、障害について秒単位でメトリクスを収集できました。これにより、内部のマイクロサービスか外部サービスプロバイダのいずれであっても、パフォーマンスの問題や動作不良コンポーネントの根本原因を特定しやすくなりました。 その 3 日後には、AWS X-Ray が導入されただけでなく、APS チームは実際のメリットを認識し、その機能を活用し始めました。セットアップは簡単で、APS チームは AWS X-Ray の AWS ドキュメントに従い、以下の手順を実行しました。 セットアップ ：AWS X-Ray Daemon セットアップ ：AWS X-Ray Amazon CloudWatch メトリクス 設定 ：AWS X-Ray Java SDK を使用して、Spring Aspect-Oriented Programming (AOP) を構成 次のイメージは、AWS X-Ray の全体のセットアップアーキテクチャ図です。 AWS X-Ray による課題解決とエンドユーザー体験の改善 AWS X-Ray を使用した結果、APS チームは基盤システムについて深い洞察を得ることができ、10 の改善領域、3 つのライフサイクル中の不要なネットワーク呼び出し、4 つの誤動作フローを特定しました。 その結果、レイテンシーが 25 % 低減し、全体的な顧客体験が改善され、顧客の信頼を得ることができました。以下、その方法を説明します。 HTTP Request Service map : AWS X-Ray のサービスマップは、顧客からのリクエストについて詳細なエンドツーエンドの視覚的な表現を提供します。バックエンド、フロントエンド、下流のサービス間の接続関係を示します。その結果、パフォーマンスのボトルネック、API レスポンスタイム、各ノードのネットワーク呼び出し回数を特定することができます。 リクエストサービスマップは、AWS X-Ray コンソールのトレースタブでリクエストトレース ID をクリックすると取得できます。以下は、ノード間の接続関係を示すトレーストレースリストとリクエストサービスマップの例です。レスポンスタイム、リクエスト数、サービスノード名などのテレメトリデータが含まれています。 コードベースのエンドツーエンドトレーシングとセグメント化されたタイムライン: AWS X-Ray は、意図したコードクラスに @XRayEnabled アノテーションを付けることで、リクエストライフサイクル中に実行されるインラインコードブロックメソッドについてリアルタイムのトレースを提供できます。AWS X-Ray SDK は Aspect Oriented Programming(AOP) を利用して、レスポンスタイムやHTTPステータスなど、コードメソッドレベルでテレメトリメトリクスを出力します。 AWS X-Ray トレースを通じて、APS チームはレスポンスタイムの長いコードメソッドを特定し、1 リクエスト中に呼び出されるメソッド数をカウントすることができました。これらのメトリクスを定量化することで、APS チームはデータに基づいてレイテンシーとパフォーマンスの改善施策を推進できました。 AWS X-Ray のトレースは、高レスポンスタイムを消費するコードメソッドを特定し、リクエスト中に消費されるメソッド数をカウントするのに役立ちました。これらのメトリクスを定量化できる機能により、APS チームはデータに基づいたアプローチでレイテンシーとパフォーマンスの改善施策を推進することができました。 API パフォーマンスメトリクスを含む Amazon CloudWatch ダッシュボード: AWS X-Ray を使えば、レスポンスタイム、APIリクエスト数、エラー/フォールト率、スロットル率など、複数の APIに跨ったパフォーマンスの評価軸で、インサイトとメトリクスを得ることができます。これらのメトリクスは Amazon CloudWatch からアクセスできるため、APS チームはその強力な可視化機能を活用することにしました。 データ可視化のために、APS チームは統計、期間、データバケッティングなどの機能を使用しました。棒グラフ、折れ線グラフなどの Amazon CloudWatch の可視化機能を使えば、P50、P90、P99のレイテンシーメトリクスを観察することで、レイテンシーやパフォーマンスの問題がある領域に素早く焦点を当てることできます。 これにより、潜在的なボトルネックを特定し、ユーザーエクスペリエンスを最適化し、強力な Amazon CloudWatch メトリクスアラームを活用してレイテンシーの問題を自動検出できます。 おわりに 要約すると、APS チームはレスポンスタイムが長いリクエストの根本原因を特定できました。APS チームはマイクロサービス API での API レイテンシーに対する SLA (サービス レベル アグリーメント) を設定しました。 ダウンストリームサービスからの生のセグメントデータの収集と、AWS X-Ray を通じて公開されるメトリクスを使用してアラームの構成を行った後、ダウンストリームサービスのレイテンシーダッシュボードを作成しました。 改善の余地のある領域を特定・対応したことで、顧客リクエストのレスポンスタイムを 25 % 削減できました。 この記事はソリューションアーキテクト小森谷一生が翻訳を担当しました。（オリジナルは こちら ）

みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 4/1 にチーフエバンジェリストの Jeff Barr さんによる エイプリルフールの投稿 がありました。AWS “Chips” Taste Test と呼ばれるポテトチップスの味を食べ比べするミニ動画です。Graviton チップス、Inferentia チップス、Trainium チップス、Nitro チップスと名付けられた 4 種類のポテトチップスを試食しています。これらの名前は、AWS で提供される CPU やアクセラレーター、専用 HW の名称で、エイプリルフール的に紹介しています。Graviton チップスはチーズ味でした。興味があれば視聴してみてください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2024年4月1日週の主要なアップデート 4/1(月) Announcing per-second billing for EC2 Red Hat Enterprise Linux (RHEL)-based instances Amazon EC2 で Red Hat Enterprise Linux (RHEL) を稼働する際に、1 時間単位の課金から、1 秒単位にアップデートしました。この変更により、利用時間に応じてよりきめ細かく料金が算出されるようになり、短時間の利用でも無駄な支払いを抑えられるようになります。例えば、10 分間のみ利用した場合でも、従来は 1 時間分の料金が発生していましたが、今回の変更により実際の利用時間に応じて計算され、安価に利用しやすくなりました。留意点として、最小課金下限として 1 分が定義されています。RHEL を起動して 1 分を越えた場合に、1 秒単位の粒度で料金が計算されます。また、RHEL の料金体系そのものも変更がアナウンスされています。12 vCPU 以下のインスタンスは安価になる一方、16 vCPU 以上のインスタンスは上昇する傾向にあります。詳細は 公式の価格ページ をご確認ください。 Amazon EKS extended support for Kubernetes versions now generally available Amazon EKS の延長サポートが一般提供を開始し、EKS クラスターのサポート期間が最大 26 か月間に延長されました。従来の EKS では、新しい Kubernetes バージョンが利用可能になってから 14 か月間が標準のサポート期間でした。延長サポートを利用することで、標準サポート期間の終了後、最大 12 か月間の追加サポートを受けられるようになります。延長サポート期間では、Kubernetes コントロールプレーン、Amazon VPC CNI、kube-proxy、CoreDNS アドオン、EKS 最適化 AMI、EKS Fargate ノードのセキュリティパッチと重要なパッチが提供されます。Kubernetes バージョン 1.21 以降で延長サポートが利用可能です。延長サポートの料金について、1 個の EKS クラスターに対して、1 時間あたり 0.60 USD の料金が発生します。料金については、 こちら をご覧ください。バージョンとサポート期間の詳細は、 こちら をご覧ください。 Private Access to the AWS Management Console is now available in all commercial AWS Regions AWS マネジメントコンソールのプライベートアクセスが、すべてのリージョンで利用ができるようになりました。この機能の主なユースケースは、組織内の端末から AWS マネジメントコンソールにアクセスする際に、個人利用の AWS アカウントのアクセスを制限することがあげられます。誤解されやすい点ですが、Private Access 機能は閉域網などのプライベートネットワークで、完全に閉じた環境で利用できるのではありません。Web Proxy の利用など、インターネットのアクセスは必要です。画像や JavaScript、CSS はインターネット経由で取得が必要です。また、Private Access で利用できないサービスも存在します。詳細については、 こちらのドキュメント を参照してください。 Amazon RDS for SQL Server supports Single-AZ Read Replica Amazon RDS for SQL Server で、シングル AZ リードレプリカをサポートしました。以前はデータベースインスタンスをマルチ AZ 構成にする必要がありましたが、今回の変更によりシングル AZ データベースインスタンスでもリードレプリカを使用できるようになります。リードレプリカは、ソースデータベースインスタンスとレプリカ間でデータベースを非同期的に複製します。このアップデートで、マルチ AZ が不要な場合でもパフォーマンスを損なうことなく可用性と耐久性が向上します。 4/2(火) Amazon Aurora zero-ETL integration with Amazon Redshift now in additional regions Amazon Aurora MySQL と Amazon Redshift 間のゼロ ETL 統合が、東京と大阪リージョンを含めた、11 のリージョンで追加サポートしました。ゼロ ETL 統合を使用すると、Aurora MySQL のデータを Amazon Redshift に自動レプリケートできます。データ連携の仕組みを構築する負担を軽減して、データ分析基盤や機械学習に活用いただけます。レプリケーションのデータフィルタリング機能を利用でき、柔軟なゼロ ETL 統合をご利用いただけます。 Announcing AWS Deadline Cloud AWS Deadline Cloud をサービスを新たに提供開始しました。 AWS Thinkbox Deadline のフルマネージドサービスとなっており、映画、テレビ、CM、ゲーム、産業デザインのビジュアルアセットのレンダリング管理を支援するサービスです。Autodesk Arnold、Autodesk Maya、Foundry Nuke、Luxion KeyShot、SideFX Houdini などの組み込み統合機能と、幅広いカスタマイズツールが用意されています。東京リージョンを含めた 8 リージョンでサービスが提供されています。 4/3(水) Mistral Large foundation model now available on Amazon Bedrock Amazon Bedrock で Mistral AI 社が開発した Mistral Large モデルを一般提供開始しました。トップクラスの推論能力、特定の指示に従う能力、そして多言語翻訳能力で広く知られています。コーディングと数学的タスクに優れ、英語、フランス語、スペイン語、ドイツ語、イタリア語に堪能です。バージニア北部、オレゴン、パリの 3 リージョンで提供されています。 AWS Clean Rooms ML is now generally available AWS Clean Rooms ML の一般提供を開始しました。企業がそのままの生データを他の企業に共有することなく、データを活用した共同活用をしながら、機械学習を利用して予測的な洞察を生成できます。この機能は、企業が類似セグメントの作成を支援するMLモデルとともに提供されます。例えば、ヘルスケア分野のお客様は、望ましい特性を持つ参加者の一覧を使って、臨床試験や医学研究の参加者の募集に活用できます。東京を含めた 11 リージョンで利用可能です。 4/4(木) Announcing general availability of Amazon EC2 G6 instances Amazon EC2 で、新たに G6 インスタンスの一般提供を開始しました。G6 インスタンスは、NVIDIA の L4 Tensor Core GPU を搭載しており、グラフィックス処理や機械学習の利用に適しています。G4dn インスタンスと比較して、ディープラーニングの推論およびグラフィックスワークロードのパフォーマンスを最大 2 倍に向上させています。G6 インスタンスは現在、バージニア北部、オハイオ、オレゴンの 3 つのリージョンで利用可能です。 AWS Lambda adds support for Ruby 3.3 AWS Lambda で Ruby 3.3 のランタイムをサポートしました。この新しい Ruby 3.3 ランタイムは、Amazon Linux 2023 の minimal コンテナイメージを基に作られています。以前の Amazon Linux 2 ベースと比べると、より小さなリソースで効率的なデプロイが可能になりました。この Ruby 3.3 ランタイムは、AWS Lambda が利用可能なすべてのリージョンで提供されています。 4/5(金) Amazon CodeCatalyst now supports adding tasks to issues Amazon CodeCatalyst のアップデートで、課題管理の Issue ボードに新しい機能が追加されました。これまでは 1 つの Issue に対してサブタスクを設定することができませんでしたが、今回のアップデートで 1 個の Issue に最大 100 個のサブタスクを紐づけられるようになりました。プロジェクトを進めていく上で、大きな課題を細かなサブタスクに分割して管理することは重要です。この新しいサブタスク機能を活用すれば、Issue 単位で進捗を把握しやすくなります。例えば、「新しい機能を実装する」という大きな Issue に対して、「設計を行う」「コーディングを行う」「テストを行う」などのサブタスクを設定することができます。 Amazon IVS Low-Latency Streaming now supports SRT ingest Amazon IVS で SRT (Secure Reliable Transport) プロトコルを使って、映像や音声を配信できるようになりました。これまでの RTMPS に加えて、SRT が利用できるようになった形です。SRT は、信頼性の低いネットワークでのストリーミングを改善し、ジッター、パケットロス、ネットワーク帯域幅の変動から保護するように設計されたプロトコルです。視聴者にとっては、バッファリングが少なく、より高品質の視聴体験が得られやすくなりました。 Amazon VPC CNI now supports automatic subnet discovery Amazon EKS で IPv4 アドレスの枯渇の対応しやすくするため、Enhanced Subnet Discovery の機能を提供開始しました。デフォルトでは、VPC CNI プラグインは、EKS ワーカーノードが稼働する Subnet 上の IPv4 アドレスを Pod に割り当てます。表現を変えると、ワーカーノードが接続されていない Subnet の IPv4 を Pod に割り当てることはできませんでした。Enhanced Subnet Discovery の機能により、VPC 内でタグ付けされたすべてのサブネットを利用して Pod の IP アドレスを設定できるようになりました。VPC 上で IP アドレスが枯渇した場合にも、VPC として CIDR を拡張する機能があり、これも併せることで柔軟な拡張が可能です。Enhanced Subnet Discovery を利用するには、バージョン EKS 1.25 以上、VPC CNI 1.18.0 以上といった前提条件があります。詳細は、こちらの ブログ をご確認ください。 それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

３月、2 つの高性能 Mistral AI モデルである Mistral 7B と Mixtral 8x7B が Amazon Bedrock で 使用可能になったことをお知らせしました。Mistral 7B は、Mistral の最初の基盤モデルとして、自然なコーディング機能で英語のテキスト生成タスクをサポートします。Mixtral 8x7B は、テキストの要約、質疑応答、テキストの分類、テキスト補完、コード生成に最適な、人気のある高品質の Sparse Mixture-of-Experts (MoE) モデルです。 4月2日、Amazon Bedrock で Mistral Large が利用可能になったことをお知らせします。Mistral Large は、実質的な推論機能を必要とする複雑なタスクや、合成テキスト生成およびコード生成などの高度に専門化されたタスクに最適です。 Mistral Large について知っておくべきこと: 英語、フランス語、スペイン語、ドイツ語、イタリア語でネイティブレベルの流暢さを備えており、文法や文化的背景のニュアンスをよく理解しています。 32K トークンのコンテキストウィンドウがあり、サイズが大きいドキュメントからでも正確な情報を取得できます。 その正確な Instruction Following により、モデレーションポリシーを設計できます。Mistral AI の人々は、ベータアシスタントデモンストレーターである le Chat のシステムレベルのモデレーションを設定するためにこれを使用しました。大規模言語モデル (LLM) との最初のインタラクションは、プロンプトを中心に展開します。効果的なプロンプトを作成する技術は、LLM から望ましい応答を生成するために不可欠です。また、 Mistral AI はサンプルプロンプトを含むガイド を提供しており、さまざまなプロンプト機能が示されています。 Mistral Large の開始方法 Bedrock で Mistral Large の使用を開始するには、まずモデルにアクセスする必要があります。Amazon Bedrock コンソールで、 [モデルアクセス] を選択してから、 [モデルアクセスを管理] を選択します。次に、[Mistral Large] を選択し、 [変更を保存] を選択します。 Mistral Large にアクセスできるようになると、Bedrock でモデルを使用できるようになります。更新されたステータスを表示するには、ベースモデルのテーブルを更新します。 Mistral Large の 複雑な推論 の側面が機能している様子を見るために、 [プレイグラウンド] セクションで次のプロンプトを試してみました。 プロンプト Calculate the difference in payment dates between the two customers whose payment amounts are closest to each other in the given dataset: '{ "transaction_id":{"0":"T1001","1":"T1002","2":"T1003","3":"T1004","4":"T1005"}, "customer_id":{"0":"C001","1":"C002","2":"C003","3":"C002","4":"C001"}, "payment_amount":{"0":125.5,"1":89.99,"2":120.0,"3":54.3,"4":210.2}, "payment_date":{"0":"2021-10-05","1":"2021-10-06","2":"2021-10-07","3":"2021-10-05","4":"2021-10-08"}, "payment_status":{"0":"Paid","1":"Unpaid","2":"Paid","3":"Paid","4":"Pending"} }' 出力 To find the difference in payment dates between the two customers whose payment amounts are closest to each other, we first need to identify the two closest payment amounts and then find their respective payment dates. The payment amounts are: 125.5, 89.99, 120.0, 54.3, 210.2 The two closest payment amounts are 125.5 and 120.0.The payment date for the payment amount 125.5 is '2021-10-05' and for the payment amount 120.0 is '2021-10-07'. The difference in payment dates can be calculated as follows: Date difference = |'2021-10-07' - '2021-10-05'| = 2 days So, the difference in payment dates between the two customers whose payment amounts are closest to each other is 2 days. 私はこの記事の前半で、Mistral Large が複数の言語でネイティブレベルの流暢さを備えており、文法や文化的背景のニュアンスをよく理解していると述べました。そこで、モデルのフランス語の理解度をテストしてみました。 プロンプト Lequel est le plus lourd une livre de fer ou un kilogramme de plume 出力 Un kilogramme de plumes est plus lourd qu'une livre de fer. Pour comprendre cela, il est important de se rappeler que : 1.Une livre (lb) est une unité de mesure de masse principalement utilisée aux États-Unis et dans d'autres systèmes de mesure impériaux, tandis qu'un kilogramme (kg) est l'unité de base de masse dans le système international d'unités (SI). 2. 1 kilogramme est approximativement égal à 2,2 livres. Donc, un kilogramme de plumes est plus lourd qu'une livre de fer, car il correspond à environ 2,2 livres de plumes. Mistral Large をプログラムで操作する また、 AWS コマンドラインインターフェイス (CLI) と AWS Software Development Kit (SDK) で Amazon Bedrock API を使用してさまざまな呼び出しを実行することもできます。AWS SDK を使用して Amazon Bedrock Runtime API を操作する Python のサンプルコードを次に示します。「You will only respond with a JSON object with the key X, Y, and Z.」(キー X、Y、Z を持つ JSON オブジェクトのみで応答してください) とプロンプトで指定すると、簡単なダウンストリームタスクで JSON 形式の出力を使用できます。 import boto3 import json bedrock = boto3.client(service_name="bedrock-runtime", region_name='us-east-1') prompt = """ <s>[INST]You are a summarization system that can provide summaries with associated confidence scores.In clear and concise language, provide three short summaries of the following essay, along with their confidence scores.You will only respond with a JSON object with the key Summary and Confidence.Do not provide explanations.[/INST] # Essay: The generative artificial intelligence (AI) revolution is in full swing, and customers of all sizes and across industries are taking advantage of this transformative technology to reshape their businesses.From reimagining workflows to make them more intuitive and easier to enhancing decision-making processes through rapid information synthesis, generative AI promises to redefine how we interact with machines.It’s been amazing to see the number of companies launching innovative generative AI applications on AWS using Amazon Bedrock.Siemens is integrating Amazon Bedrock into its low-code development platform Mendix to allow thousands of companies across multiple industries to create and upgrade applications with the power of generative AI.Accenture and Anthropic are collaborating with AWS to help organizations—especially those in highly-regulated industries like healthcare, public sector, banking, and insurance—responsibly adopt and scale generative AI technology with Amazon Bedrock.This collaboration will help organizations like the District of Columbia Department of Health speed innovation, improve customer service, and improve productivity, while keeping data private and secure.Amazon Pharmacy is using generative AI to fill prescriptions with speed and accuracy, making customer service faster and more helpful, and making sure that the right quantities of medications are stocked for customers. To power so many diverse applications, we recognized the need for model diversity and choice for generative AI early on.We know that different models excel in different areas, each with unique strengths tailored to specific use cases, leading us to provide customers with access to multiple state-of-the-art large language models (LLMs) and foundation models (FMs) through a unified service: Amazon Bedrock.By facilitating access to top models from Amazon, Anthropic, AI21 Labs, Cohere, Meta, Mistral AI, and Stability AI, we empower customers to experiment, evaluate, and ultimately select the model that delivers optimal performance for their needs. Announcing Mistral Large on Amazon Bedrock Today, we are excited to announce the next step on this journey with an expanded collaboration with Mistral AI.A French startup, Mistral AI has quickly established itself as a pioneering force in the generative AI landscape, known for its focus on portability, transparency, and its cost-effective design requiring fewer computational resources to run.We recently announced the availability of Mistral 7B and Mixtral 8x7B models on Amazon Bedrock, with weights that customers can inspect and modify.Today, Mistral AI is bringing its latest and most capable model, Mistral Large, to Amazon Bedrock, and is committed to making future models accessible to AWS customers.Mistral AI will also use AWS AI-optimized AWS Trainium and AWS Inferentia to build and deploy its future foundation models on Amazon Bedrock, benefitting from the price, performance, scale, and security of AWS.Along with this announcement, starting today, customers can use Amazon Bedrock in the AWS Europe (Paris) Region.At launch, customers will have access to some of the latest models from Amazon, Anthropic, Cohere, and Mistral AI, expanding their options to support various use cases from text understanding to complex reasoning. Mistral Large boasts exceptional language understanding and generation capabilities, which is ideal for complex tasks that require reasoning capabilities or ones that are highly specialized, such as synthetic text generation, code generation, Retrieval Augmented Generation (RAG), or agents.For example, customers can build AI agents capable of engaging in articulate conversations, generating nuanced content, and tackling complex reasoning tasks.The model’s strengths also extend to coding, with proficiency in code generation, review, and comments across mainstream coding languages.And Mistral Large’s exceptional multilingual performance, spanning French, German, Spanish, and Italian, in addition to English, presents a compelling opportunity for customers.By offering a model with robust multilingual support, AWS can better serve customers with diverse language needs, fostering global accessibility and inclusivity for generative AI solutions. By integrating Mistral Large into Amazon Bedrock, we can offer customers an even broader range of top-performing LLMs to choose from.No single model is optimized for every use case, and to unlock the value of generative AI, customers need access to a variety of models to discover what works best based for their business needs.We are committed to continuously introducing the best models, providing customers with access to the latest and most innovative generative AI capabilities. “We are excited to announce our collaboration with AWS to accelerate the adoption of our frontier AI technology with organizations around the world.Our mission is to make frontier AI ubiquitous, and to achieve this mission, we want to collaborate with the world’s leading cloud provider to distribute our top-tier models.We have a long and deep relationship with AWS and through strengthening this relationship today, we will be able to provide tailor-made AI to builders around the world.” – Arthur Mensch, CEO at Mistral AI. Customers appreciate choice Since we first announced Amazon Bedrock, we have been innovating at a rapid clip—adding more powerful features like agents and guardrails.And we’ve said all along that more exciting innovations, including new models will keep coming.With more model choice, customers tell us they can achieve remarkable results: “The ease of accessing different models from one API is one of the strengths of Bedrock.The model choices available have been exciting.As new models become available, our AI team is able to quickly and easily evaluate models to know if they fit our needs.The security and privacy that Bedrock provides makes it a great choice to use for our AI needs.” – Jamie Caramanica, SVP, Engineering at CS Disco. “Our top priority today is to help organizations use generative AI to support employees and enhance bots through a range of applications, such as stronger topic, sentiment, and tone detection from customer conversations, language translation, content creation and variation, knowledge optimization, answer highlighting, and auto summarization.To make it easier for them to tap into the potential of generative AI, we’re enabling our users with access to a variety of large language models, such as Genesys-developed models and multiple third-party foundational models through Amazon Bedrock, including Anthropic’s Claude, AI21 Labs’s Jurrassic-2, and Amazon Titan.Together with AWS, we’re offering customers exponential power to create differentiated experiences built around the needs of their business, while helping them prepare for the future.” – Glenn Nethercutt, CTO at Genesys. As the generative AI revolution continues to unfold, AWS is poised to shape its future, empowering customers across industries to drive innovation, streamline processes, and redefine how we interact with machines.Together with outstanding partners like Mistral AI, and with Amazon Bedrock as the foundation, our customers can build more innovative generative AI applications. Democratizing access to LLMs and FMs Amazon Bedrock is democratizing access to cutting-edge LLMs and FMs and AWS is the only cloud provider to offer the most popular and advanced FMs to customers.The collaboration with Mistral AI represents a significant milestone in this journey, further expanding Amazon Bedrock’s diverse model offerings and reinforcing our commitment to empowering customers with unparalleled choice through Amazon Bedrock.By recognizing that no single model can optimally serve every use case, AWS has paved the way for customers to unlock the full potential of generative AI.Through Amazon Bedrock, organizations can experiment with and take advantage of the unique strengths of multiple top-performing models, tailoring their solutions to specific needs, industry domains, and workloads.This unprecedented choice, combined with the robust security, privacy, and scalability of AWS, enables customers to harness the power of generative AI responsibly and with confidence, no matter their industry or regulatory constraints. """ body = json.dumps({ "prompt": prompt, "max_tokens": 512, "top_p": 0.8, "temperature": 0.5, }) modelId = "mistral.mistral-large-2402-v1:0" accept = "application/json" contentType = "application/json" response = bedrock.invoke_model( body=body, modelId=modelId, accept=accept, contentType=contentType ) print(json.loads(response.get('body').read())) 次のような JSON 形式の出力を取得できます。 { "Summaries": [ { "Summary": "The author discusses their early experiences with programming and writing, starting with writing short stories and programming on an IBM 1401 in 9th grade. They then moved on to working with microcomputers, building their own from a Heathkit, and eventually convincing their father to buy a TRS-80 in 1980.They wrote simple games, a program to predict rocket flight trajectories, and a word processor.", "Confidence": 0.9 }, { "Summary": "The author began college as a philosophy major, but found it to be unfulfilling and switched to AI.They were inspired by a novel and a PBS documentary, as well as the potential for AI to create intelligent machines like those in the novel.Despite this excitement, they eventually realized that the traditional approach to AI was flawed and shifted their focus to Lisp.", "Confidence": 0.85 }, { "Summary": "The author briefly worked at Interleaf, where they found that their Lisp skills were highly valued.They eventually left Interleaf to return to RISD, but continued to work as a freelance Lisp hacker.While at RISD, they started painting still lives in their bedroom at night, which led to them applying to art schools and eventually attending the Accademia di Belli Arti in Florence.", "Confidence": 0.9 } ] } Mistral AI モデルのプロンプト機能の詳細については、 Mistral AI のドキュメント にアクセスしてください。 今すぐご利用いただけます Mistral Large は、他の Mistral AI モデル (Mistral 7B および Mixtral 8x7B) とともに、米国東部 (バージニア北部)、米国西部 (オレゴン)、および欧州 (パリ) リージョンにおいて、 Amazon Bedrock で現在ご利用いただけます 。今後の更新については、 詳細なリージョンのリスト をご覧ください。 community.aws で生成 AI コミュニティと共有し、学びましょう。 Amazon Bedrock コンソール で Mistral Large を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock まで、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 当社と Mistral AI のコラボレーションと、それが当社のお客様にとって何を意味するかについてお読みください 。 – Veliswa 原文は こちら です。

こんにちは、AWS トレーニングデリバリーマネージャー の西村航です。 本記事は 2022 年 4 月に投稿した AWS 初学者向けの勉強方法 6 ステップ！2022 年版！ という記事を 2 年ぶりにアップデートした内容になります。投稿してから経過した 2 年間で公開された勉強方法を追記して、一部の勉強方法に関してはリンクの最新化を行いました。 皆さん、もしくは皆さんの周りでこんな方はいませんか。「AWS を勉強したいんだけど何から勉強すればよいだろう。どこかに勉強方法がまとまってないかな？」という悩みを抱えている方、または「同僚や部下に AWS の勉強を促しているけど、ちょうど良い教材とか無いかな？」という悩みを抱えている方。本記事はそういった AWS を勉強する際の悩みを抱えた AWS 初学者の方や AWS 初学者を育成する立場にある方を対象にした記事になります。 どのようなステップで知識を深めていけばよいのか、この勉強方法がなぜオススメなのか、疑問点やハマりどころに直面した際にどこのサイトをチェックすればいいのか、などハラオチしながら勉強を進められるように具体的に記載しています。 それでは、私がこれまでにお客様からいただいた質問をベースに、AWS 初学者向けの勉強方法を 6 ステップで順番にお話しします。 ステップ1. まず最初に何をするべき？ まず最初は、AWS が選ばれる理由や、ビジネスでの活用方法やビジネスにもたらす効果を事例ベースで学びましょう。AWS でどういうことができるのか、クラウドのメリットとは何なのか、を理解することで、「なぜ自分は AWS を勉強するのか」という勉強の理由をハラオチさせることができます。 また、皆さんがよく使う動画視聴サービスや EC サイトなど普段利用しているアプリケーションの裏側の仕組みも知ることができるため非常に面白いです。それでは、オススメのリンクを 3 つ紹介します。 1. AWS のクラウドが選ばれる 10 の理由 ★西村イチオシ AWS がお客様に選ばれる理由に関して説明されています。図や表を用いて読みやすく記載されています。「必要な時に、必要な分だけ、低価格で IT リソースを調達可能」「サービスを開始してから〇〇回以上の値下げを実施」など AWS のポイントがシンプルな言葉で説明されていて、分量もちょうど良いです。 2. お客様のクラウド導入事例 多種多様な業種や企業規模のお客様がどのようにクラウドを活用いただいているのかが網羅的にまとまっています。フィルター条件を適用することで、 エンタープライズなどのセグメント別、金融サービスなどの業種別、データレイクなどのユースケース別で見ることもできます。お客様の AWS の活用方法や、お客様のビジネスへの効果などが記載されているため、ビジネスの現場での AWS の活用シーンをイメージしやすくなります。 なお、耳慣れない単語に関しては辞書を引くような感覚で AWS 用語集 を利用いただくと理解が深まります。 3. AWS Summit Japan セッション資料・動画一覧 ( 2013 / 2014 / 2015 / 2016 / 2017 / 2018 / 2019 / 2020 / 2021 / 2022 / 2023 ) 当日のセッションが資料または動画で視聴できます。特にお客様事例セッションは、お客様のシステムにかける”熱意”が伝わってきますし、ビジネス上の課題を AWS でどのように解決していくのかのストーリーが分かりやすく、「AWS を勉強してみよう！」という気分になります。 ステップ2. AWS サービスの全体像を掴むには？ 先ほどのステップでは、AWS が選ばれる理由やビジネスでの活用例に関して説明しましたが、資料に目を通して AWS が提供するサービス数の多さに驚かれた方もいらっしゃると思います。 AWS のクラウドが選ばれる 10 の理由 でも記載されている通り、AWS はお客様の満足度を何よりも大事にしています。そのため、AWS では 200 を超えるサービスを提供しておりますが、その 90 %以上のサービス、機能は全世界のお客様からのリクエストをもとに実装されています。 とは言いつつも、サービスの多さゆえにサービスの全体像を理解するのが少し難しい、というのが初学者の方が最初に直面する壁です。その壁を乗りこえるためには、AWS のサービス群の全体を俯瞰しながら理解していき、点と点を線でつないでいきましょう。オススメの勉強方法は以下の 3 つです。 1. AWS Cloud Practitioner Essentials 日本語実写版 ★西村イチオシ 何度でも視聴できるオンデマンドの AWS デジタルトレーニングが AWS Skill Builder では無料で提供されており、 250 を超えるコースが日本語化されています。その中でも本コースは AWS を全体的に理解したい方を対象としている基礎レベルの内容になっておりますので、技術職の方に限らず営業職の方などにオススメです。日本の AWS 認定インストラクターが日本のスタジオで収録した日本語のコースとなっています。コーヒーショップをベースにした分かりやすいシナリオで、楽しんで視聴できるユニークな構成になっております。 2. Cloud for Beginners 日本語実写版 このコースでは キャパシティプランニングや CIDR といった IT に関する専門用語について適宜解説しながら進行しますので、AWS に関心がある非 IT 領域の方や学生の方にオススメです。ウェブサービスや AWS クラウドがどういうものなのかといった、AWS の学習をはじめる際に前提となる知識を効率よく学ぶことができます。また、コースの後半ではいくつかの代表的な AWS サービスについてとりあげ、その概要について紹介します。 3. AWSome Day Online Conference AWS クラウドジャーニーのはじめの一歩として、AWS に関する基礎知識を約 3 時間で学ぶ無償のオンライントイベントです。定期的に配信していますので、ぜひご参加ください。コンピューティング、ストレージ、データベース、ネットワークといった AWS の主要なサービスを段階的に学ぶことができます。ウェビナー開催中は 1:1 のチャットで AWS エキスパートに質問できますので、疑問点もその場で解決できます。 ステップ3. AWS の各サービスに詳しくなるには？ これまでのステップでは、AWS 全体に関する説明をしてきました。おそらく、各サービスの概要を知るにつれ、知りたいことや疑問点などが出てくると思います。例えば、「サービス A とサービス B は似ているように見えるが違いは何なのか」「サービス C の料金体系はどうなっているのか」「サービス D の設計時の制限値などは無いのか」などなど。 そのため、このステップではさらに一歩ふみこんで、疑問点を解消しつつ AWS の各サービスを深堀りしていくためのオススメのリンクを 4 つ紹介します。 1. AWS サービス別資料 ★西村イチオシ 真っ先にオススメするのが、「AWS サービス別資料」になります。サービスの要点をギュッ!と凝縮しつつ、サービス設計時の勘所を押さえた資料になっています。難しい専門用語も比喩表現を交えて分かりやすく解説されているため、気になるサービスに関しては最初に「AWS サービス別資料」に目を通しましょう。トップページの左側の技術カテゴリから選択することもできますし、サービス名で検索することもできます。PDF / YouTube のフォーマットで見ることができます。 2. AWS ドキュメント 「サービス別資料」でサービスの概要を理解した後に、より詳細にサービスの仕様などを理解したい場合は「AWS ドキュメント」を参照しましょう。HTML 形式で見やすい目次が画面左に表示されるので、知りたい情報に簡単にアクセスできます。ユーザーガイドだけでなく、開発者ガイドや API リファレンス、そしてチュートリアルも記載されています。 3. よくある質問 各サービスを勉強していて疑問がわいた時に、最初にアクセスするべきサイトが「よくある質問」になります。各サービスに関する製品および技術上の FAQ 集となっており、どういうサービスで何ができるのかといった基本的なことから、使用できるオプションなどの詳細まで網羅的に記載されています。 4. AWS re:Post AWS re:Post は AWS コミュニティの方々向けの Q&A サービスです。AWS に関する技術的な Q&A を検索したり、専門領域ごとのコミュニティグループに参加することができます。中でもオススメは AWS 情報センター です。AWS 情報センターでは「〇〇というエラーを解決する方法を教えて下さい」「〇〇を設定する方法を教えて下さい」などの実装に関する Q&A が豊富に記載されていますので、サービスを実装してハマりどころに直面した時に参照しましょう。 ステップ4. さらに知識を深めるには？ 「習うより慣れろ」という言葉がありますが、手を動かすことは学習定着率を高める上で非常に有効な方法です。勉強したサービスをハンズオンなどを通じて実際に触ってみることで、知識と実践を結びつけて理解することができます。 しかし、「どのサービスが入門に適しているのか分からない」「構築する際の手順書が欲しい」「できれば簡単なものから始めたい」と言った方もいらっしゃると思いますので、オススメのハンズオンを 3 つ紹介します。 1. AWS Cloud Quest ★西村イチオシ AWS Cloud Quest は実際に AWS を触りつつ初心者でもゲーム感覚で楽しく学べる 3D ロールプレイングゲームです。AWS Cloud Quest はロール毎や課題毎に様々なサービスを利用しながらソリューションを構築していくため、AWS のどのサービスから学習を始めればよいか悩んでいる初学者の方にもオススメのコンテンツとなっております。 また、ゲーム内の課題毎に、課題専用の AWS アカウントが払い出されますので、自身で AWS アカウントを用意する必要がありません。初級である AWS Cloud Quest: Cloud Practitioner は日本語版が無料で利用可能となっておりますので、詳細な説明は ゲームベースで学習できる AWS Cloud Quest: Cloud Practitioner が日本語で学習可能になりました の記事をご確認ください。 2. AWS ハンズオン資料 動画で勉強しつつ、用意されたシナリオと手順書に沿って進める入門者向けのハンズオンになります。特徴として「短い動画を見てからハンズオンで実際に触る」ステップを繰り返す構成になっていますので、歩幅を小さくじっくり理解しながら進めることができます。オンデマンド形式での配信となるので、移動時間などのスキマ時間で学習もできますし、分かりにくい部分を巻き戻して何度でもご覧いただくことができます。 3. JP Contents Hub JP Contents Hub は AWS に関する日本語のハンズオン・ワークショップ情報を一覧化して掲載されているウェブサイトです。このウェブサイトでは “日本語の” ハンズオンを限定して掲載していますので、日本語の手順で AWS のハンズオンを実施したいという方にオススメです。トップページの左側からカテゴリ別にハンズオンを選ぶこともできますし、特定のサービス名やキーワードで検索することもできます。そしてハンズオン一覧は継続的にアップデートされます。JP Contents Hub に関する詳細な説明は AWS 日本語ハンズオンまとめ JP Contents Hub のご紹介 の記事をご確認ください。 ステップ5. 最新情報をキャッチアップするには？ AWS のサービスは改善のサイクルが非常に早いため、サービスを使用する側も常に知識の鮮度を高める必要があります。また、最新技術を知ることで設計の幅を広げることもできます。 そのため、このステップでは各サービスの最新情報を効率よくキャッチアップできるオススメのリンクを 5 つ紹介します。 1. Amazon Web Services ブログ ★西村イチオシ 本記事を掲載している Amazon Web Services ブログ です。RSS 登録が可能です。AWS のサービスに関するアップデートを詳しく説明した記事など AWS 関連の様々な情報を掲載していますが、特に 週刊 AWS は要チェックです！前の週に公開された主要なアップデートや、日本のお客様に興味を持っていただけそうなものをピックアップして紹介しているので、「ちょっと先週は忙しくて AWS の最新情報を追いきれてない…」という方の助け舟になりますし、ダイジェスト版として重宝いただけると思います。 また、関連するブログとして AWS Startup ブログ と AWS JAPAN APN ブログ もオススメですので合わせてチェックしましょう。 2. AWS の最新情報 AWS の各サービスに関して、「〇〇サービスが東京リージョンで利用可能になりました」などの最新のアップデートが掲載されています。新しい機能拡張など設計にひびくアップデートもありますので、チェックしましょう。なお、本サイトは RSS 登録が可能ですので、RSS リーダーのスマートフォンアプリを利用することで、更新情報を自動的に取得することもできます。 3. builders.flash ディベロッパー向けのウェブマガジンで、様々なレベルの方に向けてバラエティに富んだ記事構成になっています。 AWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ?   などの AWS の設計や開発に関する記事だけでなく、 ハンズオンの「腹落ち問題」を改善する 5 Tips といった役立つ Tips をまとめた記事もあります。また手前味噌ですが、有識者に勉強方法をインタビューする ネットワークの勉強方法を聞いてみた といった初学者向けの記事などもあります。メンバー登録することでハンズオン記事をためす際に使える無料クーポンが配布されるなど様々な特典が用意されていますので、ぜひメンバー登録をしましょう。 4. SNS ( X / Facebook / YouTube ) オンラインイベントの配信開始などリアルタイム性のある内容に関しては X や Facebook をフォローすると情報を追いやすくなりますし、ブログ更新やセミナーの資料公開などの通知系の内容も投稿されています。また、様々な基調講演の内容なども YouTube で随時アップされますので、こちらもチャンネル登録しておきましょう。 5. AWS イベントスケジュール 開催を予定しているライブ配信イベントを一覧で確認することができます。また早期登録キャンペーンなど得する情報もチェックすることができますし、定期期にイベント情報をメールで取得することも可能です。なお、ライブ配信だけでなくオンデマンド配信のコンテンツも検索できますし、カテゴリーでお好みのイベントをフィルタリングすることもできます。 ステップ6. 中級レベルの情報を身に付けるには？ これまでに紹介した勉強方法を実践して基礎が固まってきた方、高度な情報にアクセスしたくなった方、より現場寄りなハンズオンを実装したい方に向けた勉強方法を 5 つ紹介します。 1. AWS アーキテクチャセンター ★西村イチオシ エキスパートがまとめた AWS の技術リソース郡を一覧できます。ドキュメントに関しては AWS ホワイトペーパーとガイド ではベストプラクティス等が記載された技術文書が集まっていますが、特に AWS Well-Architected Framework は設計原則と質問から構成される必読の AWS クラウドのベストプラクティス集になります。 また、  The Amazon Builders’ Library では Amazon のエンジニアが実際に開発・設計・リリース・運用する方法を説明していて、設計に関する考慮事項などの生の声が記載されていてオススメです。 2. AWS ソリューションンライブラリ AWS によって検証済みの実装例が参照できます。構成例に関しては 目的別クラウド構成と料金試算例 で代表的な構成とその試算例を幅広く紹介されていますので初回導入検討時の情報として活用いただけますが、より多くの構成例を確認したい場合は AWS リファレンスアーキテクチャ図 をご確認ください。200 を超えるアーキテクチャ図が掲載されていてポイントごとに解説もありますし、カテゴリ別・業種別にフィルタリングもできます。なお、お客様とパートナー様が実装したアーキテクチャを解説する動画を視聴できる This is My Architecture もオススメです。 3. クラウドコンピューティングコンセプトのハブ クラウドコンピューティングコンセプトのハブでは、クラウドコンピューティング関連の用語に関して深く分かりやすく説明された記事を閲覧して検索できる場所です。例えば ゼロ ETL とは何ですか？ の記事では、ゼロ ETL の概要説明だけでなく、解決する課題やメリット、そしてユースケースまで網羅的に説明されています。他にも、機械学習とは？DevOpsとは？など、改めて正しく深く理解したい用語が出てきた際にチェックしてみましょう。 4. ハンズオン 初級者向けのハンズオンをステップ 4 でご紹介しましたが、他にも複数のハンズオンがあります。 ハンズオンチュートリアル  や AWS Workshops  や  Modernization Workshops で探すことができます。前提条件や手順など含めて詳細に記載されています。オススメできるポイントとしては、レベルだけでなく、カテゴリ（セキュリテイ、IoT など）やタグ（Amazon VPC などのサービス名）が各ハンズオンで記載されていますので、習熟度や目的に応じてハンズオンをピックアップすることができます。 ちなみに、 AWS Samples や Amazon Web Services – Labs では GitHub 上に様々なワークショップのソースコード等を公開していますので、合わせてチェックしてみてください。 5. イベント 多くの新サービスや新機能が発表される AWS 最大のラーニングカンファレンスである AWS re:Invent など各イベントのコンテンツを一覧で確認できるのが AWS Events Content になります。ページ左側のフィルターでイベントだけでなく、レベルやカテゴリもピックアップできます。新サービスや新機能だけでは無く、サービスのベストプラクティスやデータ移行のワークロードなど面白いセッション資料も多数用意されていますので、是非目を通してみましょう。 お知らせ（AWS Skill Builder / AWS クラスルームトレーニング） 何度でも視聴できるオンデマンドの AWS デジタルトレーニングが AWS Skill Builder で公開されています。勉強の成果を確認するために AWS 認定資格を取得したいというお客様は、無料の公式練習問題集で認定試験の形式を確認できますし、トレーニングカテゴリで Exam Preparation を選択いただくと各認定試験の試験準備コースを視聴できます。さらに有償サブスクリプションにお申し込みいただくと、AWS 認定の公式模擬試験、ハンズオン、AWS Jam Journey など追加でコンテンツをお楽しみいただけます。詳細は AWS Skill Builder サブスクリプションのご案内  の記事をご確認ください。 なお、短期間で体系的に学びたいお客様のために、AWS 認定インストラクターが実施する有償集合研修の AWS クラスルームトレーニング も用意されております。オンサイトとオンラインの両方の形式で実施しております。AWS 認定インストラクターによる座学だけでなくハンズオンなども含めた充実した内容となっていますので、是非受講をご検討ください。どのコースを受講するかお悩みの方は AWS 認定インストラクターによる有償トレーニングコースの選び方  の記事を、そして有償トレーニングならではの価値を確認するために AWS 有償トレーニングのメリットってなんだろう  の記事も合わせてチェックしていただければと思います。 まとめ 本記事では、AWS 初学者向けの勉強方法を紹介しました。今日から早速始めてみましょう。 最後まで読んでいただき、本当にありがとうございました！ 著者について 西村 航 (Wataru Nishimura) @kuwablo AWS トレーニングサービス本部 トレーニングデリバリーマネージャー ツーリングが好きです。

コンタクトセンタープラットフォームを変革するという企業の決断には、技術的な改善の観点だけでなく、人的な観点も必要です。 Amazon Connect は、コンタクトセンター業務を変革したいと考えているあらゆる企業向けの、業界をリードするソリューションです。アメリカの技術調査およびコンサルティング企業である Gartner は、 2023 Gartner Magic Quadrant for Contact Center as a Service (CCaaS) を発表しました。AWS は、AI を活用した柔軟性の高いクラウドコンタクトセンターである Amazon Connect を 2017 年に発表して以来、初めてリーダーに選ばれました。お客様が Amazon Connect を選択する理由は、迅速な製品・機能の開発、コンタクトセンターの変革とテクノロジーの専門家の数、サードパーティのサービスパートナーや統合パートナーとの関係性が挙げられます。これらにより Amazon Connect はコンタクトセンターの移行とサービス統合に最適なソリューションとなっています。 Amazon Connect 製品はコンタクトセンターの技術基盤とデータ基盤を変革できますが、その活用には人的レベルの変革も必要です。 私は AWS プロフェッショナルサービス のエンゲージメントリーダーとして、小規模のお客様からフォーチュン 150 のお客様まで、様々なお客様を対象に Amazon Connect の導入を主導してきました。私の経験では、企業は導入後の運用サポートについて十分な優先順位を付けていません。プロフェッショナルサービスや AWS パートナーネットワーク の認定企業が、お客様のビジネス価値の期待に応える、または期待を上回るソリューションを設計、開発、テスト、そして本番環境に導入したら、次は何をすべきでしょうか。彼らの組織が引き続き、オンプレミスのコールセンターシステムを使用した運営方法に則っている場合、その企業はどのように今後規模を拡大し、最適化するのでしょうか。これこそが、エンゲージメントリーダーとお客様のリーダーが早い段階で足並みを揃え、頻繁に再検討しなければならない、導入の次のフェーズの考え方です。 AWS プロフェッショナルサービスの Amazon Connect プリンシパルコンサルタントである Naomi Hall は、2022 年 11 月の re:Invent で、 コンタクトセンターの変更管理 の重要性について講演しました。Naomi はステージに上がり、意図しない変更によってもたらされる、顧客体験のレジリエンシーに影響を与えるリスクの軽減のために、変更管理がいかに重要であるかについて話しました。 Naomi は、Amazon Connect に移行するビジネスリーダーが以下の分野を最優先に考えることを推奨しました。 開発プロセスの定義と文書化 AWS Lambda 関数と Amazon Lex ボットのエイリアスの利用 実稼働前の開発環境でのテストとデバッグ 独立した実稼働前環境での ユーザー受入テスト (UAT) 実施 自動化による不注意での変更リスクの低減 特に運用環境における最小権限アクセスの遵守 ソリューションの運用と拡張、エスカレーション手順に必要な役割と責任を持ち、運用の知識を集約する Center of Excellence (CoE) の確立 AWS ホワイトペーパー「 人工知能、機械学習、および生成 AI のための AWS クラウド導入フレームワーク 」では、コンタクトセンターのチーム変革の概念についてさらに詳しく説明しています。このホワイトペーパーの中では AI/ML ファーストの考え方ではなく「人」という視点の必要性を説明しています。Amazon Connect の使用が単なる技術的変革ではないことを理解することが、ユーザーに採用され、開発者や保守担当者がオーナーシップを発揮するための鍵となります。 Contact Center of Excellence (CCoE) として、以下の項目を検討することをお勧めします。順不同です。 変革をリードするチャンピオンの配置 Amazon Connect の導入には、多くのチームや業務が関わっています。チームには開発者、品質管理エンジニア、プロダクトオーナー、ビジネスアナリストが含まれ、業務の変革ではなく、まず導入に集中します。そして本番運用後の変革に焦点を当てる責任者を 1 人置くことが重要です。多くの場合、お客様はテクニカルデリバリーマネージャーまたはプロダクトオーナーを任命し、変革を彼らに委ねます。大規模なチームの取り組みをまとめた経験のある人を探すことを考えてみてください。開発とデプロイの期間、すべてのチームと連携し、障害を取り除き、意思決定者がいない場合は意思決定を行うことができる人が必要です。つまり、問題は起こりうり、リスクは存在するが、それでも変革が必要であることを理解している人でなければなりません。 ビジョンとすり合わせる チームには意思決定の根拠となる何かが必要です。例えば「完了」「技術面の準備ができた」とは何を指すのか。「成功」の定義は何か。 総合的な人材の発見とレビューの実施 この取り組みを最初から最後までサポートできる適切な人材はいますか。その人材は開発だけでなく、サポートに必要なスキルを持っていますか。 組織の管理変更に必要な指示 オンプレミス運用から Amazon Connect、あるいはハイブリッドモデルへの移行は、さまざまなレベルで、程度の差こそあれ、変化をもたらすでしょう。以前は必要なかった役割で、今必要なのはどのようなものですか。ビジネスを合理化するために、どこにリソースを割り当てるか、あるいは職務をなくせばよいでしょうか。変化が起こる前に対処すべき法務上および労働管理上の考慮事項はありますか。組織に、計画を実行するための指導やテンプレートを提供してくれる、認定された管理変更の専門家がいるかどうかを確認してください。 リーダーシップの役割と責任 各チームにプロダクトオーナーとテクニカルデリバリーリーダーを配置することをお勧めします。プロダクトオーナーは、ビジネスの視点を代表し、どのような価値を提供すべきかを理解しているビジネスサイドのメンバーです。テクニカルデリバリーリーダーは、開発がどのようなものであるべきかを理解しているメンバーです。 製品ロードマップの決定 製品ロードマップはありますか ? 製品ロードマップのイテレーションが UAT の完了時で終了していた場合、ロードマップは十分ではありません。また、テクノロジーだけにとどまってはいけません。Amazon Connect を使い始めてから 3 日、3 か月、3 年経った時、組織の人材、プロセス、手順はどのようになっているか定義します。 結論 コンタクトセンターの変革を決定では、ほとんどの企業が、どのプラットフォームを使用するかを決定するために時間と費用を費やしています。Amazon では、変革を行う最初のステップとして、コンタクトセンターに関するリソース、お客様の事例、AWS プロフェッショナルサービスを豊富に提供しています。Amazon Connect は業界をリードするコンタクトセンタープラットフォームです。そして、Amazon Connect を特別なものにしているのは、実装、運用、使用に関わる人々です。彼らは皆さんのクラウドジャーニーを支えてくれるでしょう。 著者について Corey Miller は、AWS プロフェッショナルサービスのシニアエンゲージメントマネージャーです。彼の職務は、お客様向けの導入プランを策定し、AWS、AWS パートナー、お客様チーム間の相乗効果を生み出すことです。Corey は 2 年ほど前に AWS に入社し、それ以前は米空軍に 28 年間勤務していました。Corey は旅行、ゴルフ、そして妻と 2 人の娘と過ごす時間を楽しんでいます。     翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

本記事は 2024 年 2 月 7 日に Neil Baillie (Principal Consultant) 、Sean O’Sullivan (Cloud Infrastructure Architect) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 ハイブリッドクラウド環境間で大量のデータを移行するのは、オンプレミスとクラウドの両方のネットワーク、ストレージ、コンピューティング、オペレーティングシステムレイヤーの技術的な制限の中で様々な要件が生じるため、大変な作業に見えるかもしれません。ユーザーは、コンプライアンス要件を満たすためにタスクスケジュールと転送時間を最適化しながら、復旧時間目標 (RTO) と復旧ポイント目標 (RPO) のバランスを取る必要があり、さらに難しい課題に直面します。これらの課題は、ハイブリッド環境間のレイテンシーやネットワーク帯域幅の制限などの技術的制約、移行が必要なデータセットの大きさや量など、様々な形で現れます。 2024 年 2 月 7 日、 AWS DataSync は、 マニフェスト をサポートすることを発表しました。これは、DataSync タスクで転送するソースファイルまたはオブジェクトの明確なリストを指定できる新機能です。マニフェストを使用すると、タスクで処理する必要がある一部のファイルまたはオブジェクトのみを指定することで、タスクの実行時間を短縮できます。 本記事では、DataSync が Amazon Simple Storage Service (Amazon S3) にある 1 億を超えるソースオブジェクトをどのように扱うのか、どのようにこれらのオブジェクトを自己管理型ストレージにコピー、同期するのかについて説明します。データ転送時の長い待ち時間のようなスケーリングを阻害する問題を防ぎ、より効率的にデータを移動するためのお勧めの方法を紹介します。 DataSync の概要 DataSync は、AWS への移行をシンプル化し、AWS へのデータ転送を加速します。オンプレミスのストレージ、エッジロケーション、他のクラウド、AWS Storage 間のデータ転送を迅速かつセキュアに行えるよう支援します。 大量のデータ (例えば 1 億件以上の S3 オブジェクト) の転送に DataSync を利用するユーザーは、DataSync に備わっている固有の上限値の範囲内を意識しながら、データ転送タスクを最適化する方法について戦略的に検討する必要があります。 マニフェストファイルの概要 マニフェストは、DataSync で転送したいファイルまたはオブジェクトのリストです。例えば、S3 バケット内のすべてのオブジェクトをコピーする代わりに、DataSync はマニフェストに含まれるオブジェクトのみをコピーできます。この機能により、ユーザーは DataSync で転送するものをより正確に制御できます。大規模に特定のファイルセットをターゲットにする場合、 インクルードフィルター の使用よりもマニフェストファイルの利用が好ましいでしょう。 関連するクォータの確認 AWS DataSync のクォータ では次のように記載されています。 タスクごとのファイルまたはオブジェクトの最大数は 5,000 万個です。目標が 1 億個を超えるオブジェクトを対象とする場合は、まずこの最初の制限を克服する必要があります。 上記のタスクフィルターに含めることができる最大文字数とタスク実行履歴が保持される日数のクォータも、ソリューションの作成を進めるにあたって関連します。 ソリューションの概要 このソリューションには次が含まれます。 データの再編成 : ソースデータを分割し、DataSync のタスク実行あたりの最大オブジェクト数の制限内に収めます。 マニフェストファイルを使ったイベント駆動 : 新規または変更されたデータのみを処理するタスクを構成します。 インクルードフィルターを使った大量一括処理 : 自動でソースデータを DataSync タスクが実行できるように大きなバッチに分割します。 前提条件 このソリューションでは、下記が必要です。 AWS アカウント DataSync の エージェント 中級程度の Python プログラミングスキル ソリューションの説明 次のセクションでは、さまざまなアプローチについて説明します。 データの再編成 DataSync タスクを設定する際は、タスクのクォータである 5000 万件未満にオブジェクト数を抑えるようタスクを定義するため、ソースデータの構造を整理してください。この再構成を行う際のオプションを、次の例で示します。 タイムスタンプに基づいて、オブジェクトをパスごとに別のバケットに分割。 オブジェクトの数が閾値に達したら、新しいパスまたはバケットを使用。 ただし、ソースデータに関連する特定のワークロードや他の外部要因によっては、これらが現実的でない場合があります。 マニフェストファイルによるイベント駆動 イベント駆動型のアプローチを利用すると、DataSync で転送されるべきファイルのみが特定のタスク実行に含まれるようになります。 manifest-config を指定した start-task-execution を呼び出すことで、DataSync タスク実行に対象のファイル/オブジェクトのリストを含むことができます。アプリケーションプログラミングインタフェース (API) のコードの詳細は、 DataSync ドキュメント で確認できます。 マニフェストファイルによって、スキャンと処理の対象がマニフェストファイルに指定されたファイル/オブジェクトだけに制限されます。これによって DataSync の全体の実行時間が短縮され、Amazon S3 のスキャン費用も最小限に抑えられます。 Amazon S3 に新しいオブジェクトが作成されると、 s3:ObjectCreated イベントが Amazon EventBridge に配信されます。Amazon S3 にアップロードされる新しいオブジェクトごとに、EventBridge はそのオブジェクトを記載する JSON ペイロードを、 Amazon Simple Queue Service (Amazon SQS) キューに送信します。 Amazon SQS をイベントの宛先とすることで、これらのイベントが処理のために持続的に取得されます。 AWS Lambda は、Amazon SQS との統合によりダイレクトで同期したイベントペイロードを処理するために必要な計算リソースを提供します。この統合により、 バッチウィンドウ を利用することで、最大 5 分間レコードをバッファリングすることが可能になります。 ソースバケットへのオブジェクトのアップロード頻度によっては、5 分より長い時間バッファリングできます。より多くのオブジェクトを渡すことで、DataSync タスクの呼び出し回数が減る利点があります。ただし、転送に遅延が生じます。より大きなデータセットを転送する影響と、RPO への影響のどちらを重視するかを評価する必要があります。 5 分より長いバッファ時間を実装するには、 スケジュールに従って実行する Amazon EventBridge ルールの作成 を使用することができます。 Amazon SQS からのメッセージの取得 Amazon SQS キューからメッセージを読み取るために、Lambda 関数は boto3 Amazon SQS クライアントライブラリの get_queue_attributes と receive_messages API コールを使用します。 Lambda 関数は利用可能なメッセージ数を理解するために、キューの長さを取得します。この値は実行中のキューの残っているアイテム数と比較することができます。これにより、すべてのメッセージが取得されることが保証されます。あるいは、単一のタスク実行でオブジェクトの数を制限したい場合もあります。これは、キューにメッセージを残すことで実現できます (RPO に影響を与える可能性があります) 。または、複数のタスクを生成することで実現できます (DataSync でキューされた後に、全体のジョブの一部として単一のタスクを停止または再開する必要がある場合、運用上使いやすいかもしれません) 。 import boto3 import os sqs_client = boto3.client('sqs') queue_url = os.environ['QUEUE_URL'] # Get the SQS queue length resp = sqs_client.get_queue_attributes( QueueUrl=queue_url, AttributeNames=[ 'ApproximateNumberOfMessages', 'ApproximateNumberOfMessagesNotVisible' ] ) approximate_queue_length = resp['Attributes']['ApproximateNumberOfMessages'] Amazon SQS のキューにあるメッセージ数を把握した後、最適なパフォーマンスを得るために各 DataSync タスクに送信するメッセージの総数を検討します。単一の DataSync タスクにメッセージを過剰にロードすると、遅延が発生する可能性があります。これは、DataSync がタスクを順次実行し、アクティブな DataSync タスクが完了するまでタスクがキューイングされるため、Amazon SQS キューに到着する新しいメッセージの全体的な処理時間に影響します。 この問題を緩和するために、DataSync タスクのオーバーヘッドを減らすように Amazon SQS メッセージをバッチ処理します。 例えば、5 分間で 1,000 メッセージをバッチ処理すると、1 つの DataSync タスクで毎秒 3.3 個の新規オブジェクトを処理できます。一度にバッチ処理するメッセージ数を選択するだけでなく、必要な RPO を確実に満たすために、5 分ごとなど、設定した間隔で Amazon SQS キューを空にする必要があります。 Amazon SQS のメッセージを取得するタイミングでは、 receive_message API を使うと、1 回の API コールで Amazon SQS キューから最大 10 件のメッセージを受信できます。次のコード例では、メッセージ数が 1000 件 または指定した件数になるまで、while ループを使ってキューからメッセージを取得しています。 ボリュームの大きさを考えると、この関数ではパフォーマンスを最適化するために yield 文を使用します。これにより、キューから取得した値のリストはメモリに格納されません。 QUEUE_URL = os.environ[“queue_url”] MAX_RECEIVE = 20000 def process_chunks(queue_length: int): processed_msg_count = 0 max_receive = MAX_RECEIVE receive_count = 0 # receive from SQS queue & build list of messages while receive_count < (max_receive / 10) and processed_msg_count < queue_length: receive_count += 1 try: resp = sqs_client.receive_message( QueueUrl=QUEUE_URL, AttributeNames=["All"], MaxNumberOfMessages=10 ) except Exception as e: logging.error("SQS Retrieve Error") logging.error(traceback.format_exc()) try: msgs = [] for message in resp["Messages"]: msgs.append(message) processed_msg_count += 1 yield msgs # Messages to be sent to DataSync except KeyError: return マニフェストの構築 Amazon SQS キューからメッセージを取得した後、DataSync にメッセージを渡す前にメッセージに対していくつかのアクションを実行する必要があります。 マニフェストファイルを構築するための手順： 各 Amazon SQS メッセージから、S3 オブジェクトの「Key」の値を抽出。 Amazon S3 にマニフェストファイルを書き込み。 重複がないことを確認。 フォルダやプレフィックスは含まれないことを確認。(マニフェストにはオブジェクトのみを含めることができる点に注意) Amazon S3 にマニフェストファイルを書き込む際は、次のルールに従う必要があります： オブジェクトのフルパスを指定する必要があります。フォルダ/パス/ディレクトリだけを指定することはできません。オブジェクトの特定のバージョン (カンマ区切り) を転送するように指定できます。 各オブジェクトは改行文字で区切ってください。 マニフェストファイルは csv ファイル (ファイル名.csv) として保存してください。 必要な IAM 権限： Lambda: Lambda 関数の実行ロールには、マニフェストファイルを含むパス (バケット/フォルダ) への s3:PutObject 権限が含まれている必要があります。 DataSync: DataSync タスクの AWS Identity and Access Management (IAM) ロールには、マニフェストファイルが保存されているパス (バケット/フォルダ) への s3:GetObject 権限と、オブジェクトバージョンを指定する場合は s3:GetObjectVersion 権限が含まれている必要があります。 他の検討事項としては、マニフェストファイル名があります。同じタスクを再実行したい場合、タスクの実行中や実行後にマニフェストファイルを削除または変更してはいけません。1 つの戦略として、Lambda 呼び出しから実行 ID を取得してファイル名に使うことが考えられます。これにより、名前の重複を防ぎ、実行 API にファイル名を渡すことができます。この手法では、Lambda が継続してファイルを生成するため、時々マニフェストバケットをクリーンアップする必要があります。 Amazon SQS メッセージごとに、S3 オブジェクトの「Key」値を抽出： Amazon SQS キューからのメッセージリストを、別の関数に読み込んで、各メッセージから S3 オブジェクトの Key 値を抽出できるようになりました。この関数は、このリストの一部であるディレクトリも処理し、マニフェストファイルから除外します。 def process_chunk_data(messages: list): manifest_data = [] processed_msgs = [] for msg in messages: msg_body = msg["Body"] payload = json.loads(msg_body) msg_key = payload["detail"]["object"]["key"] if msg_key[-1] != "/": # Prevents Dirs from manifest manifest_data.append(msg_key) else: logger.info(f"Directory found. Skipping from manifest: {msg_key}") processed_msgs.extend( [{"Id": msg["MessageId"], "ReceiptHandle": msg["ReceiptHandle"]}] ) return (manifest_data, processed_msgs) 重複する要素がなく、マニフェストファイルに保存される一意な要素のリストを確実に持つために、オブジェクトキーのリストを含むリスト変数 ( manifest_data など) に対して Python の set メソッドを使用します。 マニフェストファイルを Amazon S3 に書き込む： 転送対象のオブジェクトをマニフェストファイルに読み込んだ後、そのファイルをマニフェストバケットにアップロードする必要があります。 ファイル名を一意にするため、この例では、前述のとおり Lambda の呼び出しから context.aws_request_id を使用しています。 def publish_manifest(manifest_data: set, aws_request_id: str, idx: int): filename = f"{S3_MANIFEST_FOLDER}{aws_request_id}_{idx}.csv" result = s3_resource.Object(S3_BUCKET_NAME, filename).put( Body=','.join(manifest_data)[1:] ) if result.get("ResponseMetadata").get("HTTPStatusCode") == 200: logger.info(f"Manifest Upload: Successful: Size: {len(manifest_data)} File: {S3_BUCKET_NAME} {filename}") else: sys.exit(1) return filename DataSync 呼び出し マニフェストファイルが作成され Amazon S3 にアップロードされると、DataSync タスクが実行されます。Lambda 関数は、マニフェストファイルのパスを参照して StartTaskExecution API を呼び出します。 ds_client = boto3.client('datasync') DS_TASK_ARN = os.environ['ds_task_arn'] ds_client.start_task_execution( TaskArn=DS_TASK_ARN, OverrideOptions={ "VerifyMode": "ONLY_FILES_TRANSFERRED", "TransferMode": "ALL", }, ManifestConfig={ "Action": "TRANSFER", "Format": "CSV", "Source": { "S3": { "ManifestObjectPath": manifest_file, "S3BucketArn": S3_BUCKET_MANIFEST_ARN, "BucketAccessRoleArn": DS_S3_ROLE_ARN } } } ) Amazon SQS キューから正常に転送されたメッセージの削除 DataSync タスクが正常に実行された後、Amazon SQS キューのメッセージを安全に削除できます。前の process_chunk_data 関数では、タスクが正常に実行された場合に削除するメッセージを processed_msgs 変数に格納しています。この値は、次の delete_messages 関数に渡されます。 QUEUE_URL = os.environ["queue_url"] def delete_messages(processed_msgs: list): total_msgs = len(processed_msgs) processed_msg_buffer = processed_msgs deleted_msg_count = 0 while len(processed_msg_buffer) > 0: delete_msg_list = processed_msg_buffer[0:10] processed_msg_buffer = processed_msg_buffer[10:] try: resp = sqs_client.delete_message_batch( QueueUrl=QUEUE_URL, Entries=delete_msg_list ) deleted_msg_count += len(resp["Successful"]) except Exception as e: logging.error(traceback.format_exc()) if deleted_msg_count != total_msgs: raise RuntimeError( f"Failed to delete messages: total messages={total_msgs!r} resp={resp!r}" ) else: logger.info(f"Deleted {deleted_msg_count} from the queue") return total_msgs インクルードフィルターを利用した大容量バッチ 最初に大量のデータをシードする必要がある場合、大容量バッチを移動するには DataSync の使用が適しています。オフライン転送の代替手段として、そのタスクを実行頻度や期限によっては AWS Snowball を使用する方法があります。また、イベント駆動型のアプローチと組み合わせて、データセット全体の検証を不定期に実行する場合も DataSync が適しています。 DataSync では、 StartTaskExecution を VerifyMode オプションを POINT_IN_TIME_CONSISTENT に設定して呼び出すことで、データセット全体をチェックおよび検証できます。この場合、目的はデータセット全体を転送して検証することであるため、マニフェストを使用する必要はありません。VerifyMode を他のユースケースのマニフェストとともに使用する場合、オペレーションごとに特定し、転送するファイルのみをターゲットにするために ONLY_FILES_TRANSFERRED を指定する必要があります。 オブジェクトのクォータ バッチアプローチを使用する場合、上限のクォータがどこにあるかを理解するために、さらにいくつかの理論上の上限について説明する必要があります。 タスク実行ごとの最大ファイル数またはオブジェクト数は、5000 万件です。 単一のタスクにキューイングできるタスク実行の最大数は、50 件です。 最大数のタスクがキューイングされた場合のタスクごとの最大オブジェクト数は、25 億件です。 まずタスクがニーズに十分な規模かどうかを評価します。十分でない場合は、複数のターゲットをセットした複数のタスクを定義することを検討してください。 フィルターのクォータ タスクにオブジェクトを含めるには、インクルードフィルターを使用します。フィルターの最大長は 102,400 文字です。このクォータに達するタイミングと方法は、オブジェクトキーで使用されるパス構造によって異なります。パスプレフィックスが長いほど、フィルターの連結が最大長に達するまでの時間が短くなります。 フィルター文字列の作成 フィルターを作成する際は、タスク呼び出しを効率的に使用するために、タスクの最大値を超えないようにオブジェクトを含めてください。 フィルターオブジェクトは次のようになります： includes = [{ "FilterType": "SIMPLE_PATTERN", "Value": str(datasync_filter) }] UUID ベースのバッチ処理 フィルターの長さは、キープレフィックスが UUID (Universally Unique Identifier) を使用している場合、予測可能です。UUID は、各プレフィックスが一意になるように 16 進数 (Hex) で構築されます。詳細は次の表をご覧ください。 フィルターに含まれる桁数が増えると、フィルターに含まれるオブジェクトの数は減少します。桁数が多すぎると、必要なフィルターのプレフィックスの数が増え、全体のフィルター長が長すぎることがあります。含まれる桁数が少なすぎると、オブジェクトが多すぎることがあります。プレフィックスフィルターに含める最適な桁数を見つけるには、調査が必要となります。 例えば、オブジェクトキーでパスプレフィックスが 21 文字あり、1 桁のフィルターが 1 つある場合、21 + 1 = 22 文字になります。 1 桁の場合、16 個のプレフィックスグループが作成されます。区切り文字に | を使用するため、この場合のフィルター文字列の長さは (22 * 16)+ 15 = 367 文字になります。 3 桁の場合、フィルターは 21 + 3 = 24 文字で、プレフィックスグループは 4096 個になります。フィルター文字列の長さは (24 * 4096)+ 4095 = 102,399 文字となり、これは最大長以内です。桁数を増やすと文字列が長くなりすぎて最大長を超えてしまいます。 これらの例はすべて、UUID のサンプルセットが十分に大きく、エントロピーも十分にあり、オブジェクトが 1 桁のマッチプレフィックスに対して均等に分散していることを前提としています。 大容量バッチ UUID のコード例 次のサンプルコードは、前述の最適な処理を実装する方法を示しています。 Python を使用して UUID プレフィックスのフルセットを生成します： datasync_filter = '' number_of_digits = 3 prefix = 'path/to/objects/' hex_range = range(0, 16**number_of_digits) uuid_prefixes = [f"{i:x}".zfill(number_of_digits) for i in hex_range] # These can then be joined with the path prefix to create filter. for uuid_prefix in uuid_prefixes: # Append the Prefix to the Filter, adding delimiter for all but the first if datasync_filter: datasync_filter += '|' datasync_filter += f'{prefix}{uuid_prefix}*' datasync_filter は インクルード フィルターで使用できます。 クリーンアップ 使用されていないリソースは削除し、課金されないようにしてください。削除対象には Lambda 関数、Amazon SQS キュー、Amazon S3 内の使用していないサンプルデータが含まれます。 まとめ 本記事では、AWS DataSync を使って最大 1 億を超えるオブジェクトからなる大規模なデータセットをバッチ処理、処理、転送、検証する方法について説明しました。マニフェストを紹介し、この DataSync の新機能をイベント駆動型アーキテクチャの一部として使用して、タスクで処理が必要なファイルまたはオブジェクトのみを指定することで、タスク実行時間を短縮できることを確認しました。加えて、初期の大量データ転送が必要な顧客向けに、DataSync の インクルードフィルターを使う方法を実演しました。また、AWS DataSync サービスのクォータの一部を概説し、これらのしきい値を回避するためのデータ転送効率化方法を提案しました。 AWS DataSync とマニフェストの詳細については、以下のリンクを参照してください： AWS DataSync マニフェストの特徴 AWS DataSync ドキュメント AWS DataSync コンソール Neil Baillie Neil Baillie は AWS ProServe の Principal Consultant であり、英国中央政府チームの一員です。Neil は 20 年以上の業界経験があり、クラウドアーキテクチャとエンジニアリングのバックグラウンドを持っています。 彼は、お客様によるプロジェクトの実施と AWS の可能性の実現を支援することに重点を置いています。 Sean O’Sullivan Sean O’Sullivan は AWS ProServe のクラウドインフラストラクチャアーキテクトであり、EMEA プロフェッショナルサービスチームの一員です。業界で 7 年以上にわたり、お客様と協力してデジタルトランスフォーメーションプロジェクトを推進し、AWS クラウドを最大限に活用するためのソリューションの設計、自動化、再設計を支援してきました。

この記事は、2024 年 4 月 1 日に Karan Lakhwani によって執筆された「 Use Amazon CodeWhisperer to advance your cloud knowledge 」を翻訳したものです。 Amazon CodeWhisperer は人工知能 (AI) を活用した革新的な生産性ツールで、開発者の生産性を向上させ、クラウドの学習を加速できます。Amazon CodeWhisperer は 機械学習 (ML) を利用して、統合開発環境 (IDE) でインテリジェントなコード提案を行います。 Amazon CodeWhisperer は、何十億行もの Amazon のコードや公開されているコードを学習しています。組み込みのセキュリティスキャンを備えており、特定された問題を改善するためのコード提案を提供し、 AWS のベストプラクティスを満たした AWS サービスのデプロイを容易にします。Amazon CodeWhisperer を使って、コードサンプル、API リファレンス、Infrastructure as Code (IaC) テンプレートを生成することができるため、経験の浅いクラウドアーキテクトから経験豊富な開発者まで、クラウドの習熟度を高めることができます。 このブログでは、開発者やクラウドアーキテクトが Amazon CodeWhisperer を教育のツールとして活用する 3 つの実践的な方法を紹介します。 1. Infrastructure as Code テンプレートを作成する AWS を初めて使う人の多くは、 AWS マネジメントコンソール を使ってリソースを手動でデプロイします。しかし、クラウドの習熟度が高まるにつれ、 AWS CloudFormation や Terraform などのサービスを使った Infrastructure as Code (IaC) の採用が推奨されています。 IaC を使えば宣言的なコードテンプレートを介して AWS インフラストラクチャ全体をデプロイできるため、エラーを低減し、制御された方法で、繰り返し可能かつ拡張性のあるデプロイが可能になります。これらのテンプレートはブループリントの役割を果たし、 AWS リソースのデプロイ方法を学ぶのに最適です。 → Amazon CodeWhisperer を活用 Amazon CodeWhisperer があなたの指示と周辺のコードに基づいて IaC テンプレートを生成することで、 IaC の学習を加速させることができます。以下の例では、AWS CloudFormation テンプレートを作成するための指示をコメントとして記述しました。Amazon CodeWhisperer は、 CloudFormation テンプレートを作成する最初のステップである AWSTemplateFormatVersion セクションを生成しています。 次に、 Virtual Private Cloud (VPC) , サブネット , Elastic Compute Cloud (EC2) インスタンスを作成するための追加の手順を Amazon CodeWhisperer に指示しています。Amazon CodeWhisperer は、 AWSTemplateFormatVersion の行から、これが CloudFormation テンプレートであることを認識し、手順を実行するために必要なコード (グレー色で表示) を生成します。コードを受け入れるには、単純に Tab キーを押すだけです。 Amazon CodeWhisperer でコード生成を行うことで、構文、ドキュメント、リソース仕様を手動で調べる必要がないため、開発プロセスを高速化できます。 クラウド初学者は Amazon CodeWhisperer を使用して、 AWS CloudFormation テンプレートの形式や、 AWS サービスをプログラムでデプロイする方法を素早く理解することができます。このような方法は、新しい IaC の言語を学ぶ時や、クラウド環境を素早く学ぶ必要がある時に出発点として役立ちます。あなたが提供する仕様と指示に基づいて、Amazon CodeWhisperer は開発を進めることができます。 2. 組織のコードベースを学習する 新しいチームに参加したり、新しいプロジェクトに着手したりする際、組織のコーディングやクラウドアーキテクチャのベストプラクティスの複雑さを理解するのは難しいことがあります。Amazon CodeWhisperer は、組織の内部ライブラリやアーキテクチャパターンに基づいて提案を生成するようにカスタマイズできます。これにより、 Amazon CodeWhisperer はより関連性の高いコードを提案し、開発者はより早くオンボーディングでき、AWS クラウドサービスを習得するのに役立ちます。 → Amazon CodeWhisperer を活用 Amazon CodeWhisperer は、組織の GitHub, AWS CodeCommit, その他の Git リポジトリに接続できます。その後、 Amazon CodeWhisperer は組織にカスタマイズされたコード候補を生成し、ドキュメントや様々な開発プロジェクトを確認する必要なく、組織のコーディングスタイルとアーキテクチャパターンを迅速に学習できるようサポートします。 さらに、 Amazon CodeWhisperer は経験豊富な開発者やアーキテクトにとって継続的な学習ツールとなります。組織は新しい基準、ライブラリ、フレームワークをコードベースに追加でき、 Amazon CodeWhisperer はそれらを提案に組み込みます。これにより、熟練の開発者はアナウンスやドキュメントの変更を読む必要がなくなり、組織の変更や技術に関する最新情報を入手できます。 3. Amazon CodeWhisperer を Amazon Q と統合して学習を深める 時々、 Amazon CodeWhisperer が提案したコードよりも、さらに詳細な説明やガイダンスが必要な場合があります。このとき Amazon CodeWhisperer は IDE で利用可能なインタラクティブ生成 AI アシスタントの Amazon Q と統合できます。IDE の中で Amazon Q にコードの説明、リファクタリング、修正、最適化を求めることができ、より深い洞察が得られるので、推奨されたコードについてより多くを学ぶことができます。 最初の例において、生成されたコードを範囲選択して右クリックし、 Amazon Q にそのコードを説明するよう求めることができます (下の画像の右側) 。これにより、 Amazon Q チャットボットが開き (画像の左側) 、選択されたコードを説明してくれます。 Amazon CodeWhisperer と Amazon Q の統合により、コード生成と知識習得のループが生まれ、開発者はクラウド上で継続的にスキルアップしながらコーディングの生産性を高めることができます。 Amazon CodeWhisperer をさらに学習しましょう Amazon CodeWhisperer の詳細を学習するには、オンライン学習センターである AWS Skill Builder の無料 30 分コース「 Amazon CodeWhisperer – Getting Started (Japanese) 」をご確認ください。このコースでは、 Amazon CodeWhisperer の主要機能と、お使いの IDE に Amazon CodeWhisperer をインストールとセットアップし、使用開始する方法を学ぶことができます。Amazon CodeWhisperer は、Visual Studio Code, JetBrains IDE, AWS Cloud9, AWS Lambda, JupterLab などで利用可能です。 次に、AWS Jam の「 Build using Amazon CodeWhisperer 」で実践的な経験を積むことができます。これらの課題を通して、時間のかかるコーディングタスクを効果的に行い、生産性を最大化する方法を学びます。この AWS Jam には 7 つの魅力的なチャレンジが含まれており、自分のペースで完了できます。 AWS Skill Builder サブスクリプションの 7 日間無料トライアル を利用して、この Jam を無料で受講できます。 まとめ Amazon CodeWhisperer は、開発者やクラウドアーキテクトが AWS やその組織のアプリケーション開発プロセスについて学ぶ方法を強化する強力な AI ツールです。Amazon CodeWhisperer のコード生成機能、組織のコードベースに関する知識、Amazon Q との統合を活用することで、クラウドネイティブアプリケーションを構築しながら AWS について学ぶことができます。ぜひ深く掘り下げて、Amazon CodeWhisperer にクラウド教育を導いてもらいましょう! このブログは生成 AI モデルの Claude の支援を受けて執筆しました。このブログの構文とコンテンツを補強・改善するために Anthropic AI アシスタントを使用しています。 https://www.anthropic.com この記事の翻訳は Technical Instructor の西村 諄が担当しました。