MYCOM OSI このブログは 2023 年 12 月 4 日に Dirk Michel（MYCOM OSI, SVP SaaS and Digital Technology）、Josh Hart（Senior Solutions Architect）、Chris Williams（Solutions Architect）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 “Kubernetes 上のデータ”は、パフォーマンス、回復力、信頼性、総所有コスト（TCO）を最適化する、クラウドネイティブなマイクロサービスベースのソフトウェアソリューションを構築するために不可欠な、急速に進化する革新的分野です。Kubernetes アプリケーションの多くは、ブロックストレージ、共有ファイルシステム、オブジェクトストレージなどの永続ストレージとデータサービスへのアクセスを必要とします。 このブログでは、 MYCOM OSI が Amazon FSx for NetApp ONTAP を採用することで、どのようにコストパフォーマンスを改善したかについて説明します。また、大規模で複雑な通信事業者の通信ネットワークについて品質やパフォーマンスを監視するための、アシュアランスデータセットの処理を最適化するソリューションを特定するために、ストレージオプションをどのように評価したかを探ります。 MYCOM OSI はデジタル時代の通信サービスプロバイダー（CSP）向けに保証、自動化、分析の Software-as-a-Service （SaaS）アプリケーションを提供する AWS Specialization Partner です。 MYCOM OSI の アシュアランス・クラウド・サービス （ACS）は、重要なネットワーク・パフォーマンス、障害、サービス品質の管理を提供します。このサービスは、SaaS モデルおよび自社クラウド（BYOC）モデルのあらゆる領域において、ハイブリッド、物理、および仮想化ネットワークに対して、AI および ML技術を活用した自動化された包括的なアシュアランスをサポートしています。 データマネジメントの課題 通信事業者のアシュアランスデータセットは大きく、時には 10～100 テラバイト（TB）単位になります。昨今の通信ネットワークを構成する機器やネットワーク機能は、様々なプロトコルやフォーマットで大量のテレメトリデータを送信します。アシュアランスアプリケーションはこのデータストリームを取り込みます。このデータストリームは通常、情報量の多い時系列数値データ、イベントデータ、ログフォーマットデータ、設定データで構成されています。 通信事業者は、受信するアシュアランスデータストリームのほぼリアルタイムの性質を利用して、監視センターとオペレーションセンター内で、時間的制約のあるトリアージとインシデント対応活動に情報を提供しています。また通信事業者では、受信データを長期にわたって保持・蓄積し、ネットワーク分析や ML ワークロードに不可欠な貴重な履歴データリポジトリを構築します。 重要なことは、多くの時間的制約のあるアシュアランスのユースケースは、中程度の範囲の履歴データへの低レイテンシーアクセスに依存していることです。また、より長い範囲の履歴データは、ネットワークのキャパシティプランニングやエンタープライズ・リソース・プランニング（ERP）など、他の領域における意思決定のためのバッチプロセスを駆動します。 ペタバイト（PB）スケールのデータセットは、高品質、高粒度である可能性がありますが、多大なコストがかかるため、扱うのが難しいです。主なコスト要因のひとつはストレージであり、特に大規模なアクセスネットワークと長期間のデータ保持を必要とする通信事業者にとっては尚更です。データセットのサイズが大きくなるにつれて、必要なストレージ容量を取得、維持し、低レイテンシのパフォーマンス要件を満たすためのコストは大幅に増大します。 直接的なストレージリソースのコストに加え、システムや AWS のアベイラビリティゾーン（AZ）間で大規模なデータセットを転送したりアクセスしたりするのにもコストがかかります。このような大量のデータをネットワーク経由で移動させる場合、高い帯域幅が要求されることが多く、データ転送コストが高くなる可能性があります。 MYCOM OSI のクラウドベースの SaaS ソリューションは、Kubernetes 上にマイクロサービスアプリケーションとしてデプロイされ、数値データストアにはネットワークファイルシステム（NFS）ストレージを多用しています。 Amazon Elastic Kubernetes Service （Amazon EKS）はコアコンピュートプラットフォームであり、AWS 上の Kubernetes クラスタとシームレスに動作するように特別に設計された複数のストレージオプションを提供しています。 EKS の NFS ストレージのオプションとして長年人気があるのは、 Amazon Elastic File System （Amazon EFS）です。Amazon EFS は、完全に管理され、弾力性があり、可用性が高く、スケーラブルな NFS ファイルシステムサービスです。その弾力性とサーバーレス実装により、Amazon EFS はファイルシステムを自動的に拡大・縮小するため、キャパシティプランニングを行う必要はありません。 EFS のインテリジェント階層化機能はもう一つの重要な側面であり、アクセスパターンに基づいて EFS Standard と EFS Infrequent Access のストレージクラス間で動的にファイルを移動させます。 Amazon EKS チームは、Kubernetes コンテナストレージインターフェースのアドオンである EFS CSI Driver を提供しており、EKS が Amazon EFS ファイルシステムと効率的かつ安全に統合し、ライフサイクルを管理できるようにしています。ワーカーノードや AZ に分散された Kubernetes Pod は、EFS によってバックアップされた RWM（Read-Write-Many）永続ボリューム（PV）を同時に使用することができます。 MYCOM OSI のクラウドベースの SaaS ソリューションは、下図に示すように EFS を広範囲に使用しています。 図1 – Kubernetes の永続ボリュームに Amazon EFS を使用したアーキテクチャ。 通信事業者の顧客は、より広範なアシュアランスとテレメトリデータリポジトリを構築し、履歴データをより長く保持しようとしているため、増大する NFS ストレージの使用量について対策する必要性が明らかになりました。その結果、データ効率化機能をアプリケーション側で実装することを避けるために、 Amazon FSx ポートフォリオを評価するイニシアティブが生まれました。 さらに、このイニシアチブは、さまざまな可用性構成を検討する機会にもなりました。そのため、チームは代替のマネージド NFS ストレージソリューションの検討を開始しました。 提案されたソリューション 初期の決断の一つは、マネージド NFS ファイルシステムを求めてAmazon FSx ファミリーにフォーカスすることでした。Amazon FSx は時間の経過とともに拡張され、FSx for ONTAP のような新しいマネージドファイルシステムのサポートが開始されました。MYCOM OSI クラウド開発チームは FSx for ONTAP を使用した経験があり、パフォーマンスと効率性に特に焦点を当て、様々な側面から実装を評価し始めました。 評価された主な機能は以下の通りです： 柔軟なパフォーマンス構成オプション ： スループットキャパシティと IOPS を個別にプロビジョニングすることで、MYCOM OSI はデータ取り込み速度を最大 260% 高速化。 データ圧縮と重複排除機能 ： これらの機能により、MYCOM OSI はストレージ要件を平均 80% 削減。 “プライマリストレージ“と”キャパシティプールストレージ“の二つのストレージ階層 ： データアクセスパターンに基づいてデータをより低コストのストレージメディアに移動させることで、コスト効率を向上。 スナップショットベースのバックアップやリストアなどのデータ保護機能 ： AWS Backup で NFS ファイルシステムからバックアップを取ったりリストアを開始したりするのは、コストと時間がかかる。この課題をスナップショットで回避することで、データ損失やアプリケーションの障害時に迅速かつ効率的なリカバリが可能。 次の図は、ハイレベルの構成図です： 図2 – Kubernetes の永続ボリュームに Amazon FSx を使用したアーキテクチャ チームは、複数のストレージオプションをサポートし、必要に応じて個々の顧客のニーズに基づいた実装の選択肢を提供したいと考えていました。 通信事業者の顧客には様々な形態や規模があり、万能なソリューションが存在することは稀です。SaaS ソリューションの一部として柔軟なストレージソリューションオプションをサポートすることで、MYCOM OSI は大規模な履歴データセットを持つ顧客に最高の価値を提供することができました。 結果 初期の検証フェーズの一環として、チームはファイルシステムボリュームのライフサイクルを管理する FSx for ONTAP 提供の Kubernetes CSI Driver をレビューしました。FSx for ONTAP は、Kubernetes クラスタ内で永続ボリューム（PV）と永続ボリュームクレーム（PVC）のシームレスな統合を可能にします。 発生した課題： FSx for ONTAP は、 AstraTrident CSI Driver for Kubernetes の使用を推奨しています。このドライバには NFS ライブラリが含まれておらず、実際、関連する NFS ライブラリが Kubernetes ワーカーノードで利用可能であることを前提としています。これは、 BottlerocketOS のような最新のコンテナに最適化された Linux オペレーティングシステムでは必ずしも利用できるとはいえません。これらは専用に構築され、軽量で、セキュリティが強化されており、NFS ライブラリも含まれていません。 MYCOM チームと AWS ソリューションアーキテクトは協力して代替の CSI ドライバを特定し、標準の nfs-csi-driver と FSx for ONTAP の互換性を検証しました。チームは BottlerocketOS と FSx for ONTAP のセキュリティ上の利点をストレージソリューションとして利用することを決めました。 パフォーマンス ファイルシステムのパフォーマンス検証作業は、MYCOM OSI ラボのテストハーネス上で実行され、ストレージ効率化機能を有効にした FSx for ONTAP ファイルシステムを採用した SaaS テナント環境を使用しました。 選択されたベンチマークは、二つの特定領域を検証：ファイルシステムに書き込み優位の負荷を与えるデータ取り込みパフォーマンスと、読み取りに集約されるデータ分析パフォーマンスです。結果は以下のように、両方のベンチマークで改善が見られました。 ベンチマークタイプ ベンチマーク種類 ベンチマーク結果 データ取り込み 1B のレコード変換と書き込み 110% – 260% 高速化 データ分析 1B のレコード読み取りと計算 10% – 23% 高速化 この結果は、FSx for ONTAP を導入したパターンでは、十分に低いレイテンシが実現されることを示します。 効率性 このソリューションの費用対効果を検証するためには、データ圧縮率を証明する必要がありました。通常、FSx for ONTAP のコンパクト化、圧縮、重複排除機能を使用した場合、AWS はストレージ容量を 65% 削減できることを確認しています。 複数のテストを実施した結果、システム側で圧縮を行わない NFS ファイルシステムと比較して、ストレージ容量が平均 80% 削減されました。非圧縮ファイルシステムサイズと圧縮ファイルシステムサイズの差は約 10TB/2TB で、圧縮率は 5:1 となりました。達成される圧縮率はさまざまで、データセットの構成や疎性（スパース性）などの複数の要因によって異なります。 ベンチマークタイプ ベンチマーク種類 ベンチマーク結果 データセットタイプ1 合成された通信事業データセット 85% 圧縮 データセットタイプ2 合成された通信事業データセット 75% 圧縮 可用性 FSx for ONTAP のもう一つの特徴は、AZ 間接続性です： アクティブストレージシステムは、どのアベイラビリティゾーンからでも分散アプリケーションによってアクセスできます。これは EFS One Zone の場合とは異なり、EFS One Zone のデプロイメントは、それが存在する同じ AZ 内からのみ EFS CSI ドライバによってマウント可能です。 マルチ AZ の EKS トポロジーを維持するには、EFS ファイルシステムを複数の AZ に分散する EFS Standard で展開する必要があります。これは、回復力と可用性を高めますが、コストの増加というトレードオフを伴います。 FSx for ONTAP では、single-AZ 展開タイプのファイルシステムは、どのアベイラビリティゾーンからでも NFS でマウント可能です。これは、EKS クラスタが可用性と標準の展開テンプレートを維持する一方で、NFS ストレージは可用性を下げて提供されることを意味します。これは、オンプレミスとクラウドを比較する場合など、クラウド移行プロジェクトにとって重要です。詳細については、ブログ記事 Amazon FSx for NetApp ONTAP のシングルアベイラビリティーゾーン デプロイメント利用による VMware Cloud on AWS のストレージコストの削減 を参照してください。 クラウドへの移行をめぐる話題は、コストから始まることがあります。そのため、同等の条件で比較することが重要になります。オンプレミスにマルチサイトレプリケーションがない場合、One Zone ファイルシステムがそれに相当します。もう一つの重要な考慮点は、特定のアプリケーションの要件です。ここでのトレードオフ対象は、可用性、コスト、持続可能性です。 One Zone の導入パターンでストレージの容量を削減すれば、基盤となるインフラが削減されるため、ソリューションのカーボンフットプリントも削減されます。 まとめ MYCOM OSI は、データ集約的な通信事業者のアシュアランスにおいてストレージソリューションを進化させ、顧客固有のニーズに最適なストレージソリューションを採用することができました。進化したストレージアーキテクチャは、特に大規模な履歴データセットを持つ通信事業者の顧客にとって、パフォーマンスの向上とコスト削減を同時に実現しました。Amazon EFS と Amazon FSx for ONTAP の両方をサポートすることで、適切な業務に適切なツールを選択する柔軟性を提供します。 MYCOM OSI は、一貫した SaaS アーキテクチャを維持するための標準的なパターンセットを提供しながらも、特定の要件を満たす柔軟なテナントオプションを提供する能力を高めました。MYCOM OSI は、通信事業者の顧客全体の過去のデータサイズと可用性要件を評価することで、その顧客ベースに対して可能な限り最高のコストパフォーマンスと投資収益率（ROI）を提供することができました。 通信事業者は、MYCOM OSI のアシュアランスクラウドサービス（ACS）プラットフォームのようなクラウドネイティブな SaaS ソリューションを採用することで、アシュアランスアプリケーションの総所有コスト（TCO）を改善することができます。 翻訳はネットアップ合同会社の榎本様、監修はエンタープライズサポートの岡田が担当しました。 . . MYCOM OSI – AWS Partner Spotlight MYCOM OSI は、デジタル時代の通信サービスプロバイダ向けにアシュアランス、オートメーション、アナリティクスの SaaS アプリケーションを提供する AWS パートナーです。 MYCOM OSIへのお問い合わせ | Partner 概要

前提：本ブログは既存システムの改修や更新に携わるエンジニアの方が既存プログラムの概要を把握する手段の選択肢の一つとして、LLMの可能性を提示したものです。実際に稼働しているシステムのプログラムは、本ブログで用いたプログラムよりも規模・複雑度ともに大きく、紹介した方法だけでは十分な結果が得られない可能性があります。後述する「改善ポイント」も参考に、カスタマイズしてご利用ください。 本ブログでは、既存システム更新に関わる課題解決のために、AWS の生成 AI サービスである Amazon Bedrock を使って COBOL ソースコードからプログラム概要資料を作成する活用例を解説します。実際に使用したプロンプトも紹介していきますので参考にしやすい構成になっています。また、COBOL 言語初心者の筆者が生成 AI を活用しながら COBOL 言語を学び、成果物品質を向上させていった方法についても解説します。今回紹介する方法が、既存システムの理解促進と将来の発展のための参考になれば幸いです！ はじめに 2018年、経済産業省から「 DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～ 」が公開されました。あらゆる産業において、デジタルトランスフォーメーションのスピーディーな実現が求められている一方で、企業が抱える多くの問題についても言及されました。その一つが既存システムの老朽化・複雑化・ブラックボックス化している現状でした。レポートには調査結果が引用されており、既存システムの抱える問題のインパクトの大きさが伺えます。 『JUASのアンケート調査によると、約8割の企業が「レガシーシステム」を抱えており、約7割が「レガシーシステム」が自社のデジタル化の足かせになっていると回答している。』 レポートではこの既存システムが DX の足かせとなっている理由についても言及されており、「ドキュメントが整備されていないため調査に時間を要する」というものが一番多くの企業で挙げられていました。 そのような既存システムで使われているプログラミング言語の一つが COBOL 言語です。COBOL 言語は1959年に事務処理用に開発されたプログラミング言語であり、現在も多くの企業、システムで稼働しています。一方で既存システムを開発したエンジニアが離職などにより減ってきている他、現在は新たに COBOL を学ぶエンジニアが減ってきており COBOL エンジニアの絶対数が不足している現状があります。 そんな中で近年最も注目を集めているのが生成 AI です。生成 AI はテキストの理解力や表現力が非常に高く、テキスト生成や、コード生成を得意としています。AWS は昨年の re:Invent にて生成 AI を活用し情報検索を簡単にする Amazon Q というサービスや、生成 AIを用いて対話的にETLジョブのコードを生成する機能などをリリースしています。 本ブログでは、AWS の生成 AI サービスである Amazon Bedrock （サービスについての詳細は こちら をご覧ください）を用いて、COBOL のドキュメント（今回はプログラム概要資料）を作成する活用例を解説します。 なお、エンタープライズ企業におけるメインフレームモダナイゼーションの全体像は大規模で、そのマイグレーションプロセスも複雑です。限られた時間とコストでビジネスゴールを達成するために、業界のベストプラクティスをご参照ください。詳細はこちら「 Mainframe Modernizationへのアプローチ（前編） 」。 生成 AI の出力を組み込んだプログラム概要資料 『論より証拠』、まずは実際に生成 AIの出力を組み込んだプログラム概要資料をご紹介します。 対象とした COBOL プログラムには、AWS が公開している CardDemo というカード会社のシステムを模したものを使いました。CardDemo は画面を備えたアプリで、いくつかのバッチプログラムもあり、実際に環境を整えれば実行することもできます。 CardDemo の画面イメージは以下のようになっています。 図1-1：CardDemo の画面の一例 バッチプログラムの一覧はこちらです。 図1-2：CardDemo のバッチプログラムの一覧 実際に生成 AI の出力を組み込んだプログラム概要資料は以下のとおりです。 図1-3：生成 AI の出力を組み込んだプログラム概要資料 以降では、プログラム本体のファイルと画面定義のファイルについて詳細を示します。 プログラム本体のファイル（ファイル拡張子.cbl） 図2-1：CardDemo のプログラム本体のファイル、右が作成したプログラム概要資料 プログラム概要資料にはプログラム名、プログラム説明のほか、使用する入力ファイル、出力ファイル、変数であるデータ項目、プロシジャーの処理概要、プロシジャーの一覧、プロシジャーから呼び出されプロシジャーの一部として実行される COPYBOOK というファイルの一覧を出力しています。 画面定義のファイル（ファイル拡張子.bms） 図2-2：CardDemo の画面定義のファイル、右が作成したプログラム概要資料 プログラム概要資料には画面名、画面説明のほか、画面イメージ、画面項目の一覧を出力しています。 いかがでしょうか？ プログラム本体や画面定義について、人が比較的に読みやすい形でドキュメント化できたことが分かりますね。 以降では、このドキュメントを Amazon Bedrock  を用いてどのように作成したのかを解説していきます。 Amazon Bedrock を用いたプログラム概要資料作成 概要資料作成プログラムの構成 今回作成した概要資料作成プログラム全体の構成は以下の通りです。 図3-1：プログラム概要資料作成プログラムの構成 全体は Python でプログラミングしています。Amazon Bedrock は COBOL ソースコードの解析部分に利用しています。 Amazon Bedrock から利用する LLM（Large Language Model） には Anthropic Claude v2.1 を使いました。選定理由は、1/日本語での出力が必要なことと、2/後述する通り XML や JSON などが取り扱え、高品質なアウトプットが期待できたためです。 概要資料作成プログラム詳細 概要資料作成プログラムの処理は以下の通りです。 ファイルの情報（ファイル名、ファイルパス、サイズ、ファイル拡張子、ファイル行数）を取得する 各ファイルについて Amazon Bedrock を使って仕様情報を取得する 上述の情報をプログラム概要資料（Word 形式）に書き出す １は概要資料にファイルの一覧を出力する目的のためファイルを列挙し、さらに生成 AI では難しいが Python で可能な処理（例：行数を数える）を行ないます。 ２ではファイル種別毎にプロンプトを切り替えて仕様情報を取得します。 ３では１、２で取得した情報をプログラム概要資料に書き出します。例えば1の結果をもとに画面一覧を出力したり、2の結果をもとに画面詳細仕様を出力したり、と言った感じです。 このブログでは Amazon Bedrock にフォーカスして説明するため Python 部分のコードについての説明は割愛しますが、サンプルプログラムの公開を検討中ですので後続のブログをお待ちいただけると幸いです。 以降、２の Amazon Bedrock の使い方について解説していきます。 Amazon Bedrock タスク ここからは成果物イメージでお見せした、COBOL プログラムのプログラム本体と画面定義について具体的なプロンプトをご紹介します。 COBOL プログラムのプログラム本体から概要資料生成に必要な情報を取得するために使用したプロンプトは以下のとおりです。 コードは <inputText> XML タグの中に Python で埋め込んで Amazon Bedrock の API を呼び出しました。 Human: あなたはCOBOLプログラムの設計、実装、試験のスペシャリストです。 <inputText></inputText>XMLタグ内のプログラムはCOBOLプログラムです。 このCOBOLプログラムを読んで、COBOLプログラム仕様書を作成してください。 COBOLプログラム仕様書のテンプレートを<template></template>XMLタグ内に記載しました。COBOLプログラム仕様書を作成する際には、テンプレートに沿う必要があります。 またCOBOLプログラム仕様書を作成する際には<condition></condition>XMLタグ内に記載した条件を満たして作成してください。 COBOLプログラム仕様書の説明文は日本語で記述する必要があります。ただし、ファイル名称は変数名、関数名などのCOBOLプログラムに記述されている単語はCOBOLプログラム中の記載を優先することが必要です。 <condition> 1.COBOLプログラム仕様書の説明文は日本語で記述してください。文体はですます調で統一してください。 2.出力は<template></template>XMLタグ内に示したJSON形式のテキスト部分だけを記述してください。 3.出力するJSON形式のテキストの前後にこのタスクに関する説明を付加しないでください。 4.<template>タグ、</template>タグそのものを出力しないでください。 5.JSON形式は厳密に守ってください。 </condition> <template> [{"programtitle":"ここにCOBOLプログラムのPROGRAM-IDの内容を記述してください", "processdescription":"ここにCOBOLプログラムの処理概要を400文字以内で記述してください。", "inputfile":[{"inputfilename":"ここに入力ファイル名を記述してください","inputfiledescription":"ここに入力ファイルの概要を40文字以内で記述してください”}], "outputfile":[{"outputfilename":"ここに出力ファイル名を記述してください","outputfiledescription":"ここに出力ファイルの概要を40文字以内で記述してください”}], "dataitem":[{"dataitemname":"ここにCOBOLプログラムのDATAディビジョンのWORKING-STORAGEセクションのデータ項目を記述してください","dataitemdescription":"ここにCOBOLプログラムのDATAディビジョンのWORKING-STORAGEセクションのデータ項目の概要を40文字以内で記述してください”}], "procedureitem":[{"procedurename":"ここにCOBOLプログラムのプロシジャー名を記述してください","proceduredescription":"ここにCOBOLプログラムのプロシジャーの概要を40文字以内で記述してください”}], "workflow":[{"workflowstep":"ここにCOBOLプログラムのPROCEDURE DIVISION. の中身のワークフローの処理ステップ数を1から順にインクリメントしながら記述してください。","workflowdescription":"ここにCOBOLプログラムのPROCEDURE DIVISION. の中身のワークフローの概要を40文字以内で記述してください”}], "copyfile":[{"copyfilename":"ここにCOBOLプログラムがCOPYしているファイルの名前を記述してください。COPYしているファイルというのはCOPY命令の後に示されるモジュールの名前です。","outputfiledescription":"ここにCOBOLプログラムがCOPYしているファイルの概要を40文字以内で記述してください”}] }] </template> <inputText> --filecontent-- </inputText> それでは、<inputText></inputText>XMLタグ内のCOBOLプログラムを読んで、<template></template>に記載したCOBOLプログラム仕様書のテンプレートに従って、COBOLプログラム仕様書を生成してください。 Assistant:[ Outputの一例（COCRDLIC.cblを入力とした場合） { "programtitle":"COCRDLIC", "processdescription":"COCRDLICプログラムは、クレジットカードの一覧表示を行うビジネスロジック層のプログラムです。管理者ユーザーの場合は、コンテキストが渡されなければ、すべてのカードを一覧表示します。管理者以外のユーザーの場合は、COMMAREAで渡されたACCTに関連付けられたカードのみを一覧表示します。", "inputfile":[ {"inputfilename":"COMMAREA","inputfiledescription":"前画面から渡されるコンテキスト情報が格納されている"} ], "outputfile":[ {"outputfilename":"画面","outputfiledescription":"クレジットカードの一覧を表示"} ], "dataitem":[ {"dataitemname":"WS-COMMAREA","dataitemdescription":"前画面から受け取ったコンテキスト情報"}, {"dataitemname":"WS-SCREEN-DATA","dataitemdescription":"画面に表示するカード情報"} ], "procedureitem":[ {"procedurename":"0000-MAIN","proceduredescription":"メイン処理"}, {"procedurename":"1000-SEND-MAP","proceduredescription":"画面送信"}, {"procedurename":"2000-RECEIVE-MAP","proceduredescription":"画面受信"} ], "copyfile":[ {"copyfilename":"DFHAID","outputfiledescription":"AID条件名"}, {"copyfilename":"DFHBMSCA","outputfiledescription":"BMSマップ定義"} ] }] COBOL プログラムの画面定義に対して使用したプロンプトは以下のとおりです。 コードは同じく <inputText> XML タグの中に記載して Amazon Bedrock の API を呼び出します。 Human: あなたはCOBOLプログラムの設計、実装、試験のスペシャリストです。 <inputText></inputText>XMLタグ内のプログラムはBMSマップです。 このBMSマップを読んで、BMSマップ仕様書を作成してください。 BMSマップ仕様書のテンプレートを<template></template>XMLタグ内に記載しました。BMSマップ仕様書を作成する際には、テンプレートに沿う必要があります。 またBMSマップ仕様書を作成する際には<condition></condition>XMLタグ内に記載した条件を満たして作成してください。 BMSマップ仕様書の説明文は日本語で記述する必要があります。ただし、ファイル名称は変数名、関数名などのBMSマップに記述されている単語はBMSマップ中の記載を優先することが必要です。 <condition> 1.BMSマップ仕様書の説明文は日本語で記述してください。文体はですます調で統一してください。 2.出力は<template></template>XMLタグ内に示したJSON形式のテキスト部分だけを記述してください。 3.出力するJSON形式のテキストの前後にこのタスクに関する説明を付加しないでください。 4.<template>タグ、</template>タグそのものを出力しないでください。 5.JSON形式は厳密に守ってください。 </condition> <template> [{"programtitle":"ここにBMSマップのTITLEを記述してください", "processdescription":"ここにBMSマップの概要を400文字以内で記述してください。", "displayimage":"ここにBMSマップの画面イメージをアスキーアートで記述してください。画面イメージはコンソールに出力されるイメージになるべく近づけてください。BMSマップ内のフィールド名称などは表示しないでください。", "fieldnames":[{"fieldname":"ここにBMSマップの画面フィールド名称を記載してください","fielddefaultvalue":"ここにBMSマップの画面フィールドの初期値をBMSマップの記載通りに日本語に変更せず記載してください "}]}] </template> <inputText> --filecontent-- </inputText> それでは、<inputText></inputText>XMLタグ内のBMSマップを読んで、<template></template>に記載したBMSマップ仕様書のテンプレートに従って、BMSマップ仕様書を生成してください。 Assistant:[ Outputの一例（COBIL00.bmsを入力とした場合） {"programtitle":"CardDemo - Main Menu Screen", "processdescription":"CardDemoはメインメニュー画面プログラムです。ユーザーはアカウントIDを入力し、現在の残高を確認した後、残高の支払いを実行するかどうかを選択することができます。", "displayimage":" Tran:____ Bill Payment Date:__/__/__ Prog:________ Time:__:__:__ ------------------------------------------------------------ Enter Acct ID:_________ ------------------------------------------------------------ Your current balance is: __________ Do you want to pay your balance now. Please con- firm: _ (Y/N) ", "fieldnames":[{"fieldname":"TRNNAME","fielddefaultvalue":"____"}, {"fieldname":"TITLE01","fielddefaultvalue":"Bill Payment"}, {"fieldname":"CURDATE","fielddefaultvalue":"__/__/__"}, {"fieldname":"PGMNAME","fielddefaultvalue":"________"}, {"fieldname":"TITLE02","fielddefaultvalue":""}, {"fieldname":"CURTIME","fielddefaultvalue":"__:__:__"}, {"fieldname":"ACTIDIN","fielddefaultvalue":"_________"}, {"fieldname":"CURBAL","fielddefaultvalue":"__________"}, {"fieldname":"CONFIRM","fielddefaultvalue":"_"}, {"fieldname":"ERRMSG","fielddefaultvalue":""}]}] プロンプトは1ファイルにつき1回の Amazon Bedrock API の呼び出しで複数の必要な情報を得られるように工夫しました。1)1回の呼び出しで複数の回答を同時に得られることでプログラム全体の実行時間の短縮とコストの削減が見込める、2)同一コードに対しての複数の項目を別々に取得する場合に比べて出力内容間の整合性がとれる可能性がある、と仮定しています。 今回のプロンプトで利用した Anthropic Claude のプロンプトテクニックについて、 Anthropic のプロンプトガイド を引用して列挙します。 テクニック１： Mark different parts of the prompt/プロンプトのさまざまな部分にマークを付ける Claude は XML タグを認識できるように微調整されています。XML タグを使用することで、プロンプトをサブセクションに区切ることができます。また JSON や YAML などの他の構造化形式も認識できます。今回のサンプルでは、指示を明確にするために XML タグを使いました。また、1回の API 呼び出しで複数の情報を得られるように JSON 形式で応答するように指示しました。 テクニック２： Put words in Claude’s mouth/クロードの口に言葉を入れる 生成 AI は回答の冒頭に、「○○○について、以下に説明します。」のような言葉を加えることがあります。これは概要資料に記載する項目としては不要です。上記プロンプトでは出力の形式を JSON にし、指示中の Condition に不要な説明を含めないように制限を示し、Assistant: の直後に JSON の“[”を指定することで、JSON のみの出力を得られるよう工夫しました。 ＊このプロンプトは概ねうまくいきますが、完全ではありませんでした。今回の事例では正しい出力を得るため再実行が必要なことがありました。 テクニック３： Documents before instructions/指示前にドキュメントを入れる Claude は大きなコンテキストウィンドウがあり、大規模な COBOL プログラムもプロンプトに含めて渡すことができます。プロンプトの構造として、最初に指示を書き、次に入力となる COBOL コードを示した上で、最後に再度指示を書きました。これにより指示が守られやすくなります。 Amazon Bedrock の使い方として、使用したプロンプトは以上です。このプロンプトを使って得られた JSON 形式の応答を Python で受け取り、プログラム概要資料に出力しました。 次にこの概要資料作成プログラムを作るにあたり、どのように進めたのか説明していきます。 COBOL 初心者の私が COBOL 概要資料作成の生成 AI デモを開発した道のり 私は COBOL 言語を使ったことがありませんでしたので、当然文法についての知識もありませんでした。そのため生成 AI を使って COBOL 言語や COBOL ソースコードを理解しながら、概要資料作成プログラムを徐々に良くしていくという方法を取りました。 だいたい次のような流れで進めました。 おおまかに質問して、全体感を把握する。 具体的にしたい部分に絞った質問をして、より詳細な情報を得る。 キーワードをたまに Web 検索して、生成 AI の出力結果が正しいのか事実確認をする。 以降、１から３を繰り返す Amazon Bedrock には生成 AI とインタラクティブに対話しながら  LLM  の出力をチェックし、質問応答を行うことができる チャットプレイグラウンド が用意されています。以下では、私がチャットプレイグラウンドを利用して COBOL 言語を学んでいった際のイメージを示します。 どのようなファイルがあるのかを質問したり、ファイルの仕様を質問したり、言語仕様の調査を行なっている様子です。 図5-1：COBOL 言語のファイル種別を質問した場合の回答 図5-2：COBOL 言語のプログラム本体のファイル構成を質問した場合の回答 図5-3：COBOL 言語の MOVE 命令について質問した場合の回答 図5-4：COBOL 言語の COPYBOOK について質問した場合の回答 ソースコードを調査した際のイメージを以下に示します。 プログラム全体の概要を説明させたり、ソースコードを少しずつ説明させたりしてソースコード調査を行なっている様子です。 図5-5：CardDemo のあるプログラム本体をすべて引用して質問したところ 図5-6：CardDemo のあるプログラム本体について引用して質問した場合の回答 図5-7：CardDemo のプログラム本体の数行について質問をしたところ 図5-8：CardDemo のプログラム本体の数行について質問した場合の回答 Python で概要資料作成した際のイメージを以下に示します。 Python から Word 形式のプログラム概要資料を作成するためのライブラリ調査を行なっている様子です。 図5-9：Python から Word を処理するために必要なライブラリを質問した場合の回答 図5-10：Python-docx というライブラリについて使用方法を質問した場合の回答 このように、生成 AI との対話を通して、COBOL 言語、CardDemo に関する知識を徐々に広げながら、プロンプトを工夫したり Python 実装を行なったりして進めていきました。 本概要資料作成プログラムの作成に要した期間ですが、著者の場合で約１週間でした。 本デモ開発を通じたラーニングのシェア 本取り組みを通して得られた学びをシェアします。 1. 未知の言語、未知のシステムであっても生成 AI を使うことで、簡単に短時間で学ぶことができた 始める前は、生成 AI が COBOL 言語の情報を持っているか分からなかったが、質問することで目的に十分な知識があることが確認できました。生成 AI を使うことで、一般的な言語仕様の説明を得られる上に、目の前のソースコードについても解説が得られるので、システムが何をしているのかより早く理解することができました。 ＊LLM が十分に学習していない言語だった場合でも、その言語の知識を持ち込むこと（プロンプトや、RAG 等）で対応可能な可能性があります。 2. 学びを概要資料作成に活かすことで、成果物の品質がどんどん向上した 学んだ言語仕様を前提としてプロンプトを改良することで、目的に合致する情報を確実に得られるようになりました。 生成 AI では得ることが難しい情報だと分かった場合は、Python で取得するように変更しました（例：プログラム行数の取得）。その際も生成 AI を使って Python コードを生成することで、短時間で目的を達成することができました。（このブログでは割愛しましたが、Python コードの作成には Amazon CodeWhisperer を使っています。） 3. 生成 AI が出力する“本当かどうか分からない”出力も、それっぽいのでうまく使うと便利 生成 AI はソースコード内の変数名やプロシジャー名からそれっぽい説明を生成します。（例：”TRNXFILE” というファイル名の説明を「トランザクションデータを含む入力ファイル」と出力しました。）正しいかどうかは調査を進めないと分かりませんが、事前情報なくそれっぽく説明してくれるので、一旦構成を理解するのに役立ちました。 ＊調査が進み、生成 AI の出力が正しくないと感じたら、プロンプトでファイル名の命名ルールを与えるなどすれば、より正確な出力が得られる可能性があります。 改善ポイント 今回限られた時間の中で、意味のありそうなプログラム概要資料を得られるところまで作り込むことができました。 ここではこの方法を実際のプロジェクトで活用しようと思った時に、考えられる改善のポイントをあげておきます。 プロンプトはまだまだ改善ができます。指示を改良する、例を示すなどすることで出力をわかりやすく、かつ安定させることができるはずです。 概要資料のプロシジャーの説明は、今回は表形式での説明としましたが、フローチャートなど図化を行なった方がより直観的にわかりやすくなります。Python ではグラフ構造をテキストで指示してフローチャートなどの図を出力できる Graphviz が使えます。生成 AI の出力としてこの Graphviz で使えるグラフ構造のテキストを生成させることができます。改善の一つとしてこのような改修を入れるのは有効です。 生成 AI の出力は時には最善とは言えないものとなる可能性があります。今回は生成 AI の出力を目視で確認し、リトライを行なっていましたが、生成 AI で出力した成果を生成 AI によって回答品質を判断し、品質が低い場合は自動でリトライさせる方法が考えられます。生成 AI の出力品質チェック用のツール（例：https://github.com/citadel-ai/langcheck）も出てきていますので、用途に合ったものを使うのも良いやり方です。 生成 AI で出力された情報をさらに統合的に解析し、生成 AI を通すことでより高度な情報を概要資料に含めることができます。例えば、各プログラムから使用している COPYBOOK 名を取得済みですが、逆に COPYBOOK の修正により影響を受けるファイルの一覧を出力することができます。また、各プログラムファイルから生成された説明を元に、生成 AI を使って再度プログラム全体の説明を作成することで、ボトムアップで正確な説明ができる可能性があります。 まとめ 本ブログでは、AWS の生成 AI サービスである Amazon Bedrock を使い、COBOL ソースコードのプログラム概要資料を作る方法の解説を行いました。Anthropic Claude のプロンプト例を具体的に提示し、効率的に正しい回答を得るためのプロンプトテクニックについて解説しました。 本内容はCOBOL以外のプログラム言語でも応用できる可能性があります。 プログラム概要資料作成のための概要資料作成プログラムを作ることで、解析対象のシステムをより手軽に早く理解することができるようになります。また概要資料を読んだ結果、新たな観点で調査を行いたいとなったときも、この概要資料作成プログラムに手を加えることで、短時間で調査を完了することができます。この概要資料作成プログラムは既存システム理解のための重要なツールとなると実感しました。 今回紹介した方法が、既存システムの理解促進と将来の発展のための参考になれば幸いです！ 著者について 勝本 秀之(Hideyuki Katsumoto) 勝本 秀之(Hideyuki Katsumoto) は AWS Japan のパートナーソリューションアーキテクトとして、パートナーの AWS ビジネスの推進や個別案件の技術支援を担当しています。好きなサービスは Amazon Bedrock です。2024年の活動ポリシーは「手を動かす！」なので、いろんなサンプルコードを作っていきたいと思います。ご質問、ご要望あればご連絡ください！ 本橋 和貴 (Kazuki Motohashi) 本橋 和貴 (Kazuki Motohashi) は、AWS Japan の機械学習パートナーソリューションアーキテクトです。AWS 上で機械学習関連のソフトウェアを開発しているパートナー企業の技術支援を担当をしています。好きなサービスは Amazon SageMaker です。週末は昔の RPG のリメイクゲームの攻略に勤しんでいます。博士 (理学)。

AWS Config の 高度なクエリ 機能は、AWS リソースの設定状態を示すメタデータを取得し、リソースのコンプライアンス状態を特定するための SQL ベースのクエリインターフェースを提供します。AWS Config の高度なクエリは、単一の AWS アカウントおよびリージョン、または AWS Config の アグリゲータ を使用して設定されたマルチアカウントとクロスリージョンにおいても使用できます。しかしながら、クエリの作成には SQL の知識および、リソースの設定プロパティとリソース間の関係性の理解が必要であり、お客様のAWS 環境の規模と複雑さが増すにつれ、SQL の作成はより複雑で時間のかかる作業になりがちでした。 そこでこの度、AWS Config では自然言語で書かれたシンプルな命令や質問を使用して AWS リソース、設定、コンプライアンス状態を問い合わせることができる生成 AI を活用した自然言語クエリ (プレビュー提供) 機能をリリースしました。クエリを自然言語の文章、命令、質問として記述できるため、SQL を学習したり、リソースの設定プロパティやリソース間の関係性を理解するための負荷が低減します。 本ブログでは、AWS Config の高度なクエリ機能で自然言語クエリを利用する方法を解説します。シンプルな文から始めて、求める回答を得るためにどのように改善していけば良いかも併せて解説します。 前提条件 本ブログでは、AWS Config の 高度なクエリ 機能と AWS Config アグリゲータ 機能に関する説明は省いています。それらについてはドキュメントをご確認ください。また、本ブログの手順を実施するには、事前にお客様の AWS アカウントにおいて最低 2 つのリージョンで AWS Config の有効化、1 つのリージョンでアグリゲータの設定が必要です。手順中に生成されるクエリをテストするには、AWS Config を有効化およびアグリゲータで集約対象としている各リージョンに、暗号化された Amazon Elastic Block Store (Amazon EBS) ボリュームと暗号化されていない Amazon EBS ボリュームが必要です。Amazon EBS ボリュームを作成するには こちら のドキュメントを参照してください。 手順 本手順のゴールは、「AWS アカウント内のすべての Amazon EBS ボリュームの暗号化の状態を確認すること」とします。まずは、対象となるすべての Amazon EBS ボリュームを確認し、次に、暗号化された Amazon EBS ボリュームを抽出するためのフィルタリングを行っていきます。 1. AWS マネジメントコンソールから AWS Config の画面に遷移し、左側のナビゲーションペインで、 [高度なクエリ] を選択します(図 1) （訳者注）自然言語クエリプロセッサ機能は、2024 年 3 月現在東京リージョンで提供されていないため、バージニア北部 (us-east-1) もしくはオレゴン (us-west-2) リージョンを選択してください。 図 1 AWS Config – 高度なクエリ 2. [新しいクエリ] を選択します。 [クエリスコープ] を [このアカウントとリージョンのみ] ではなく、アグリゲータ名に変更します。自然言語クエリプロセッサに「List volumes」と入力し、 [生成] を選択します。すると右側にクエリが自動的に生成されます。その後、 [エディタに移動] を選択します。(図 2) 図 2 自然言語クエリプロセッサ機能による Amazon EBS ボリュームの一覧を出力するクエリ生成 3. [新しいクエリ] に生成されたクエリがコピーされているので [実行] を選択します。クエリの結果には Amazon EBS ボリュームのリストが含まれていますが、resourceId と resourceType フィールドのみが含まれており、暗号化ステータスは含まれていないことが分かります(図 3)。次のステップでプロンプトを少し改善してみましょう。 図 3 Amazon EBS ボリュームの一覧を出力するクエリの実行結果 4. [自然言語クエリプロセッサ] に戻り、「List EBS volumes. show volume ID, AZ, resource type and encryption status」と入力し、 [生成] を再度選択します。(図 4) 図 4 Amazon EBS ボリュームの一覧（AZ と暗号化ステータスの情報を含む）を出力するクエリ生成 5. 生成されたクエリには、暗号化ステータスを表す configuration.encrypted フィールドが含まれていることを確認してください。 6. エディタに入力してクエリを実行するには、 [エディタに移動] を選択します。 7. クエリを実行すると Amazon EBS ボリュームと暗号化ステータスがリスト表示されます。(図 5) 図 5 Amazon EBS ボリュームの一覧（AZ と暗号化ステータスの情報を含む）を出力するクエリの実行結果 8. 他にも試してみましょう。 [自然言語クエリプロセッサ] に戻り、「List encrypted EBS volumes. show volume ID, AZ, resource type and encryption status」と入力し、 [生成] を選択してください。(図 6) 図 6 暗号化された Amazon EBS ボリュームの一覧を出力するクエリ生成 9. [エディタに入力] を選択し、生成されたクエリを実行して、次の結果を確認してください。(図 7) 図 7 暗号化された Amazon EBS ボリュームの一覧を出力するクエリの実行結果 他の生成 AI アプリケーションと同様に、想定の結果が得られる SQL を生成するためには、少し試行錯誤が必要な場合があります。そのため、ぜひニーズに合ったプロンプトを自由に試してみてください。 まとめ 本ブログ記事では、AWS Config で生成 AI ベースの自然言語クエリを活用する方法を紹介しました。この機能は、バージニア北部およびオレゴンリージョンでプレビュー版として利用できます。AWS マネジメントコンソールから AWS Config の高度なクエリよりご利用いただけます。 著者について Faraz Rehman Faraz Rehman は、サンフランシスコベイエリアを拠点とする AWS のシニアソリューションアーキテクトです。過去数年間、ISV のお客様が AWS 上でビジネスクリティカルな本番規模のワークロードを構築して運用できるよう支援することに注力してきました。彼の専門分野には、クラウド運用、管理、ガバナンスが含まれます。 Avi Harari Avi Harari は AWS のシニアテクニカルアカウントマネージャーで、エンタープライズ顧客の AWS サービスの導入と利用をサポートしています。AWS Cloud Operations コミュニティの一員であり、AWS での設定、コンプライアンス、監査を専門としています。仕事以外では、家族と過ごす時間やミクソロジーを楽しんでいます。 翻訳は Solutions Architect 北川が担当しました。原文は こちら です。

この記事は、2024 年 3 月 12 日に Andre Zoutte によって投稿された Is the AWS Certified Data Engineer – Associate certification right for you? を翻訳し、日本語リソースに関する情報を加筆したものです。 新認定である AWS Certified Data Engineer – Associate (DEA) の予約と受験が開始されました。この認定では、データ関連の AWS サービスに関するスキルと知識、データパイプラインを実装する能力、モニタリングとトラブルシューティングを行う能力、コストとパフォーマンスを最適化する能力を検証します。私は AWS トレーニングおよび認定チームの AWS ソリューションアーキテクトとして、AWS 認定試験の技術的な監督を行っています。私はこの試験の主任認定テクニカルアーキテクトでした。つまり、すべての内容をレビューし、試験の問題が技術的に正確で、当社の品質基準を満たしていることを確認しました。 このブログでは、この新しい試験の概要、利用できる受験準備リソース、および準備中のその他のリソースを紹介します。 AWS がデータエンジニア向けの認定資格を新設した理由 データエンジニアリングは急速な成長を遂げています。世界中のデータエンジニアの求人情報は 2021 年から 2023 年にかけて 45% 増加し、今後 10 年間でさらに 28% 増加すると予想されています (Draup)。この新しい AWS 認定は、受験者がデータエンジニアリングの需要が高い職種に就くための手段となります。 データエンジニアリングは、もう 1 つの主要なトレンドである人工知能 (AI) や機械学習 (ML) にとっても不可欠です。ほとんどの ML アルゴリズムでは、学習と評価にはクリーンなデータが必要とされます。データエンジニアは、データのソースと、それを活用するオペレーションを結びつけます。また、特徴量を設計してデータをサニタイズすることで、モデルの精度を改善します。 専門的に成長する機会を探している人にとって、データエンジニアリングは素晴らしいキャリアの選択肢の一つです。データエンジニアには、開発者としてのプログラミング能力と、データ関連の AWS サービスに関する理解が必要です。データエンジニアの中には、データエンジニアリングの役割に特化したトレーニングを受けている人もいれば、状況に応じてそのような役割を担うことになる人もいます。 AWS Certified Data Engineer – Associate の受験準備 この試験の受験準備に役立つように、オンラインラーニングセンターである AWS Skill Builder に 受験準備リソース を用意しています。試験当日に自信を持って取り組むことができるように、準備プロセスを 4 つのステップにまとめました。これらのリソースを活用して、試験の概要を理解し、試験のトピックについて学び、試験の準備をし、準備状況を評価してください。 （訳注：上記の受験準備リソースページは、執筆時点では英語でのみの提供ですが、各コースを選択後に、そのコンテンツを日本語に切り替えることができます） 他の AWS 認定との比較 皆さんのこれまでの経歴によっては、AWS Certified Data Engineer – Associate の方が、他の Associate 分野の AWS 認定よりも難しいと感じるかもしれません。それは、データエンジニアはエントリーレベルの職種ではなく、ソフトウェア開発者、データサイエンティスト、ソリューションアーキテクトなど、隣接するいくつかの職種に関するスキルが必要となるためです。そのため、 試験ガイド では、AWS Certified Data Engineer – Associate の対象者を、データエンジニアリングに関する 2~3 年の実務経験、AWS に関する 1~2 年の実務経験と定義しています。これは、他の Associate 分野のものよりも複雑です。 AWS 認定の今後の進化 私たちは、Foundational、Associate、Professional 分野の AWS 認定の強化に積極的に取り組んでいます。これらの分野に重点を置いている理由は、需要の高まりにあり、これらの試験には受験者と雇用者の両方から多くの関心が寄せられています。さらに、過去 10 年間でテクノロジー環境は大きく変化しており、認定試験にもこれらの変化を反映させたいと考えています。今後のさらなる情報にご期待ください。 他の学習者がどのように AWS 認定の受験準備をしたのかや、専門家からアドバイスを確認したい場合は、以下のブログをチェックしてください。 Steps to start your AWS Certification journey Learner journey: From zero cloud knowledge to achieving three AWS Certifications in one year AWS ソリューションアーキテクトによる AWS 認定試験の 5 つのヒント AWS 認定の受験準備に役立つ日本語ブログには以下もありますので、合わせてご参照ください。 AWS 認定試験を受けるときのコツ AWS Certified Cloud Practitioner と AWS Certified Solutions Architect – Associate を同時に受験準備するための 10 のヒント この記事の翻訳および追加情報の加筆は Sr. Technical Instructor の生出拓馬が担当しました。

システム維持運用コストを約80％削減しながら、技術的負債を解消し、データドリブン経営を加速 イントロダクション 経済産業省が2018年に「 DXレポート～IT システム「2025 年の崖」の克服と DX の本格的な展開～ 」を発表して6年が経過しました。しかし2024年に入った今もなお、大型コンピュータと呼ばれるメインフレームで基幹システムを運用するお客様から、技術面で老朽化した基幹システムの近代化（モダナイゼーション）に関するお問い合わせをいただくことが増えています。 こうしたなか、明治グループの食品事業を担う企業として、幅広い世代に笑顔と健康価値を提供する 株式会社 明治 （以下、明治）は、 AWS Mainframe Modernization を活用して、30 年以上の長きにわたり運用してきた基幹アプリケーション群のモダナイゼーションを進めました。2022年9月に AWS Mainframe Modernization のプレビュー版による検証を開始し、2024年2月に、第 1 弾として販売系基幹システムなどを含むメインフレームアプリケーション群 のモダナイゼーションを完了しました。このモダナイゼーション第1弾により、技術的負債を解消しながら、システム維持運用コストを約80％削減し、データドリブン経営を加速することが可能になりました。 メインフレームにおける課題 明治では、もともと、社内の多くの領域でクラウドを活用したITシステムが運用されており、2024年1月には経済産業省が定めるDX認定制度に基づく「DX認定事業者」の認定を取得しています。育児応援サイト「ほほえみクラブ」で提供するLINEによるオンラインビデオ通話での相談サービス「 明治 つながる栄養士 」など、AWSを基盤として運用することで、デジタルを活用した新たな顧客価値の提供と、顧客接点の多様化に向けた取組も進めていました。 一方、業務システムなどの基幹系システムは、30年以上にわたって、メインフレームで構築・運用されてきました。時代の流れとともに段階的にメインフレームからオープン系システムへの移行も進めてきましたが、2022年9月に抜本的なモダナイゼーションに着手するまでは業務アプリケーションの14%がメインフレーム上で稼働しており、その運用には年間数億円ものコストがかかっていました。 そのような中、同社が直面したメインフレームアプリケーション運用上の課題は大きく分けて3つあります。 30年以上に及ぶシステム構築の積み重ねによる複雑化やブラックボックス化 それに伴う保守・運用コストの増大傾向 COBOLなどレガシー言語を扱える人材の高齢化と確保難といった人員面でのリスク こうした課題に対処すると同時に、2025年4月に控えたメインフレームのアウトソーシング契約更新を前に、同社はシステム全体の刷新を含めた新たな方針を検討しました。 出典：明治 明治のAWSを活用したメインフレーム・モダナイゼーションの方針 業務アプリケーションを棚卸し、同社のメインフレームで稼働する基幹システムの全体像を確認した結果、大まかに以下の3つのカテゴリーに分類できました。 ビジネスのトレンドや変化に迅速に追随可能なように変革するアプリケーション群 基幹システムなど非競争領域にあり、再構築を行うアプリケーション群 現時点でビジネスモデルに大きな変更がなく現行維持するアプリケーション群 そこで、同社は本プロジェクトにおいて、3つ目のカテゴリーに該当する一部のアプリケーションを対象に、メインフレーム上のロジックをそのまま維持しつつ、基盤のみを汎用機からAWS環境に移行し、クラウドでのモダナイゼーションを進めることを決定しました。実現手法の1つとしてAWSが提供するAWS Mainframe Modernizationサービスに着目し、まず概念実証（Proof of Concept、PoC）でその有効性を検証することとしました。 出典：明治 AWS Mainframe Modernization AWS Mainframe Modernization はAWSが2021年の年次イベントで発表したサービスで、お客様のメインフレームアプリケーションのより迅速かつ容易なクラウド移行を支援するサービスです。老朽化した基幹システムのモダナイゼーションには、その複雑さゆえに、既存システムの業務フローを含めた評価・分析から、検証、移行、テスト、運用までの長期にわたるプロセスが求められ、同時にお客様のビジネス上、重要性が高い既存システムに関しては、経営環境の変化に柔軟かつスピーディーに対応するクラウドを活用した最新のアプリケーションを開発、実行、運用する必要があるというお客様の声をもとに開発されました。その後、 2022年12月にAWS アジアパシフィック（東京）リージョンでAWS Mainframe Modernizationの一般提供を開始 した後、 2023年12月にはAWS アジアパシフィック（大阪）リージョンでも一般提供を開始 しました。 明治では2022年9月から、本サービスのPoCを開始しました。 国内初のモダナイゼーションへのチャレンジ AWS Mainframe Modernizationの有効性を検証するPoCの結果は予想以上に良好でした。そのため、明治では約5か月という短期間でのPoC及び社内検討を経て、2023年1月にはAWS Mainframe Modernizationを利用した国内初の本格的なメインフレームモダナイゼーションプロジェクトを始動させました。 メインフレーム上で稼働する業務アプリケーションのうち、販売系基幹システムは新システムとして再構築します。一方、それ以外のアプリケーションについては、AWS Mainframe Modernizationサービスを用いて自動変換し、これまでのロジックを継続利用するものの、基盤はメインフレームからAWSに移行しました。 モダナイゼーション対象の各アプリケーションは、メインフレーム上で動作するCOBOL、PL/1といったレガシーな言語で開発されており複雑を極めました。しかし、AWS Professional Services、AWS Mainframe Modernizationで提供するリファクタリングソリューション AWS Blu Ageを提供するBlu Ageチームの支援のもと、明治独自のビジネスロジックを事前に組み込むことで、当初は数年が必要とみられていたJavaベースのプログラムコードへの自動変換を、7ヶ月という短期間で完了することが可能となりました。 明治では、メインフレームアプリケーションのモダナイゼーションにあわせて、関連する周辺システムの改修や、業務フローや帳票の電子化推進といった取り組みも並行して進めており、2024年6月をめどに新システムへの全面移行が完了する計画です。 メインフレーム・モダナイゼーションによる成果 明治では新システムへの全面移行完了後、これまでのメインフレームの維持運用コストを約80%削減できる見込みです。技術的負債を解消しながら、AWS を活用したモダナイゼーションを機にデータ連携が強化されることで、データドリブン経営を加速する効果も期待されています。 株式会社 明治　執行役員　デジタル推進本部　本部長　古賀 猛文氏は、今回の成果を踏まえ、次のようにコメントしています。「今回のメインフレーム・モダナイゼーションは、当本部のミッションである『デジタルで「やりたい」を「できる」に変える』を実践したものです。最新のIT・データ連携基盤が構築された現在、この基盤を活かしたデジタルトランスフォーメーション（DX）の本格的な推進が次なる挑戦です。明治は今後も、AWSの強力なサポートを活かし、新しいビジネスモデルを創出するための『攻めのDX』と、自社のバリューチェーンを支えるプロセスを効率化し、劇的に省力化する『守りのDX』をさらに推進していきます」 出典：明治 終わりに 老朽化したメインフレームシステムのAWSクラウドへの移行やモダナイゼーションにご興味をお持ちのお客様は、 Webフォーム からお問い合わせいただくか、担当営業までご連絡ください。また、 AWS で移行とモダナイズ のページをご確認いただくと、AWSへの移行やモダナイゼーションに必要な情報が網羅されています。 AWSへの移行やモダナイゼーションにご興味をお持ちのお客様は、是非AWSへのコンタクトをお待ちしております。 サービス＆テクノロジー統括本部　マイグレーション＆モダナイゼーションビジネス本部 マイグレーションスペシャリスト 富松 卓郎

本記事は、 Support multi-tenant applications for SaaS environments using Amazon QuickSight を翻訳したものです。翻訳は Solutions Architect の深見が担当しました。 可視化やレポートを利用するアプリケーションやサービスは、顧客の導入を促進し、収益を増やし、競争上の優位性を生み出します。 統合された分析やレポートがない場合、SaaS (Software as a Service) ソリューションの市場での競争力が低下してしまいます。 しかし、自社開発や商用の BI (business intelligence) ソリューションを利用する場合、構築と運用コストがかさみがちです。 Amazon QuickSight は AWS のサーバーレス BI サービスで、組み込みアプリケーションで数千の顧客が利用し、コストを抑えながらもシームレスな可視化や分析体験を提供しています。 この記事では QuickSight のマルチテナンシーに焦点を当てていますが、マルチテナンシー以外のパターンについての詳細は、 Build embedded analytics architectures using Amazon QuickSight を参照してください。 多くの組織がマルチテナンシーの利点を享受できますが、運用上のオーバーヘッドやコストをかけずにソフトウェアを利用できる SaaS ソリューションがマルチテナンシーの主なユーザーになります。 SaaS ソリューションの取り組みの１つとして、高品質の BI ソリューションを低コストかつ大規模に提供することがあります。 QuickSight では、セルフマネージドソリューションの運用オーバーヘッドを削減しながら、コスト効率よく機能を提供できます。 さらに、QuickSight のマルチテナンシーは、顧客向けのダッシュボードやレポート作成ソリューションを提供するコンサルティング企業にとっても有用です。 この投稿では、マルチテナント環境における QuickSight のデプロイの方法のガイダンスと、QuickSight アプリケーションでデータの分離とテナントへのリソースの展開に関する考慮事項について説明します。 アプリケーション内のマルチテナント機能は、ユーザーグループを相互に分離するメカニズムを提供します。 これらのグループは、異なる企業や地理的領域、または同一企業内の別の事業部門のユーザーかもしれません。 異なるテナントのユーザーは、お互いのユーザー、データ、アセットを見ることができませんが、各ユーザーグループごとに別々のインフラストラクチャを用意する複雑さを軽減できます。 この投稿では、次のトピックについて説明します。 ユースケースに最適な QuickSight でのデータ分離方式の選択 QuickSight 内のオブジェクトにアクセスを許可し、デプロイする最適な方法の選択 テナントユーザーのプロビジョニング 全テナントへのアセットデプロイを可能にする開発およびデプロイ手法 グループと名前空間 Amazon QuickSight では、リソースを分離してマルチテナンシーを実現する方法が 2 つあります。 グループ を利用する方法と、 名前空間 を利用する方法です。 どちらの方法でも、リソース (データソース、データセット、分析、ダッシュボード) を分離できますが、1 つ根本的な違いがあります。 エンドユーザーがダッシュボードの構築、デプロイ、または共有を行う必要がある場合は、名前空間を使用する必要があります。 エンドユーザーがレポート作成を行う必要があり、Author ライセンスを必要とする場合には名前空間が必須になります。 グループのメンバーシップでは、Author ライセンスを持つ著者がグループ外で新規リソースを共有するのを制限できません。これにより、意図しないデータ漏洩のリスクが高まります。 オブザーバビリティの観点から、名前空間は QuickSight におけるテナントレベルの利用状況の監視を簡素化することで、 利用状況の追跡と顧客への請求 を容易にします。 グループか 名前空間 のどちらを使うかを決める前に、それぞれのアプローチの制限事項に関するドキュメントを確認してください。 テナント毎のデータセットとデータソース vs 行レベルセキュリティを使用した単一データセット QuickSight のマルチテナントアーキテクチャでは、データセットに関する決定を下す必要があります。 この節では、2 つのオプションについて検討します。 どちらのオプションが最適かは、組織のリスク許容度や業界固有のコンプライアンス要件に依存します。 テナント毎のデータセットとデータソース このシナリオでは、テナントごとにデータセットが存在します。各データセットは、そのテナントに特化したデータを返すように、データフィルタまたはパラメータ付きのカスタムクエリの形式で構成されています。 テナントごとにデータソースを持つ必要はありません。たとえば、 Amazon Athena を使用して Amazon Simple Storage Service (Amazon S3) からデータを照会する場合、すべてのテナントで共有される接続詳細を持つデータソースを使用できます。 各テナントのデータセットは、異なるテナント ID で Athena にクエリを送ることができます。 データベースレベルのマルチテナンシーが、テナントごとにデータベース・スキーマやクラスターなどの分離されたハードウェアやスキーマを含む場合、テナントごとにデータソースを 1 つ用意する必要があります。 AWS Lambda 関数を使用することで、テナントごとのアセットの展開を自動化することもできます。 このプロセスでは新しいアセットを作成し、そのアセットが特定の名前空間 (テナント) 内のグループまたはユーザーからのみ参照できるように、必要なアクセス許可を適用します。 また Lambda を使用して、必要に応じてテナントのクリーンアップやユーザーおよびアセットの削除を行うこともできます。 次の図はこのアーキテクチャを示しています。 行レベルセキュリティを使用した単一データセット この例では、全てのテナントの生データを格納した 1 つのデータセットがあり、行レベルのセキュリティ (RLS) が有効になっています。単一のダッシュボードがこのデータセットを指しており、すべてのテナントと共有することができます。 RLS を利用するには、各テナントがアクセス可能なデータを保持する別のデータセットを作成する必要があります。詳細は、 Amazon QuickSight での Row-Level Security (RLS) の利用 をご覧ください。 次の図はこのアーキテクチャを示しています。 オプションの比較 以下の表は、それぞれのオプションのメリットとデメリットを要約したものです。 オプション 長所 短所 テナント毎に固有のアセット (データソース、データセット、ダッシュボード) データの分離を必要とする業界特有の要件に準拠できる アセットを管理するための自動化が必要になり、開発オーバーヘッドが比較的大きくなる SPICE の利用コストをテナント単位で追跡しやすい RLS を利用したテナント間での共有アセット 実装が単純で開発オーバーヘッドが低くなる SPICE の利用コストをテナント単位で追跡できない RLS のルールデータセットがセキュリティの要になる 保存されたデータの容量が SPICE 制限に達する可能性が高くなる プロビジョニング、認証、認可 この記事では、テナント (名前空間)、グループ、ユーザーをプロビジョニングします。他の実装では、 ID フェデレーション を使用して、グループを QuickSight の外部で管理できます。 アプリケーションにダッシュボードを埋め込むと、QuickSight でのユーザー管理を排除でき、シームレスなユーザーエクスペリエンスを提供できます。 埋め込みアプリケーションは、ユーザーに代わって QuickSight API を呼び出し、ダッシュボードをユーザーに表示する iFrame で利用できる 1 度だけ利用可能な URL を生成します。 埋め込み URL の作成時にユーザーコンテキストが渡されるため、QuickSight にサインインする必要はありません。 詳細については、 Embedding Workflow ワークショップを参照してください。 QuickSight 固有のセキュリティのベストプラクティスについては、 Amazon QuickSight のセキュリティベストプラクティス を参照してください。 以下のセクションでは、 AWS Identity and Access Management (IAM) のユーザー、グループ、名前空間、アセットを使用して、QuickSight でマルチテナント環境に必要なリソースを作成します。 わかりやすくするため、 AWS Command Line Interface (AWS CLI) での例を使用しています。 AWS CLI の代わりに、 AWS SDK for Python (Boto3) などの他の SDK を使うこともできます。 テナント (名前空間) このセクションでは、カスタムの名前空間という形式で最初のテナントを作成し、次にグループを作成します。 名前空間内のグループは、多数のユーザーに対して権限を適用するのに便利です。 次のコマンドを入力します (自分の AWS アカウント ID と名前空間の名前を指定してください): aws quicksight create-namespace --aws-account-id YOUR_AWS_ACCOUNT_ID --name YOUR_NAMESPACE --identity-store QUICKSIGHT このプロセスは非同期です。名前空間が作成されたかどうかを確認するには、次のコマンドを入力します。 aws quicksight describe-namespace --aws-account-id YOUR_AWS_ACCOUNT_ID --namespace YOUR_NAMESPACE ユーザー このセクションでは、IAM ユーザーを作成し、そのユーザーを名前空間の下で QuickSight に登録します。 まず、適切な権限を持つ IAM ユーザーを作成する必要があります。詳細は、 AWS アカウントに IAM ユーザーを作成する を参照してください。 次のコマンドを入力して、作成したユーザーを名前空間の下で QuickSight Author として登録します。 aws quicksight register-user --identity-type IAM --email YOUR_USER_EMAIL --user-role AUTHOR --iam-arn YOUR_IAM_USER_ARN --aws-account-id YOUR_AWS_ACCOUNT_ID --namespace YOUR_NAMESPACE テナント間でのアセット展開 このセクションでは、テナント間でデータセットを展開するプロセスを確認します。AWS CLI を使って JSON 形式でデータセットをエクスポートし、テンプレートを作成することで、さまざまなテナントにデータセットをデプロイできるようになります。 AWS CLI コマンドまたは Python 用の SDK を Lambda と組み合わせて、エクスポートとデプロイのパイプラインを作成し、本番ワークロードでこれらのパイプラインを自動化できます。 QuickSight には、アセットをコードとしてエクスポートする 2 つの方法があります: 標準の API (例: describe-dashboard) を使用する バンドル API を使用する バンドル API を使用すると、すべての依存関係を単一のエクスポートファイルにバンドルすることで、エクスポートプロセスが簡素化されます。 マルチテナントの環境でアセットを開発する場合、開発用の名前空間を割り当ててください。 デフォルトの名前空間または顧客の名前空間を使用できます。 次の図は、名前空間間でのアセットのエクスポート、テンプレート化、インポート処理を示しています。 バンドルエクスポートとしてアセットをデプロイするには、以下の手順を完了してください。 エクスポートしたいダッシュボードの ARN を取得するには、次のコマンドを入力します: aws quicksight list-dashboards --aws-account-id YOUR_AWS_ACCOUNT_ID 取得したリソース ARN を使って、エクスポートジョブを開始します。AWS CLI では、ダッシュボードが使用しているデータセットとデータソースがエクスポートされるように、依存関係を含める必要があります。この記事では、エクスポート形式は JSON を使用しますが、 AWS CloudFormation もサポートされています。次のコードを参照してください。 aws quicksight start-asset-bundle-export-job --aws-account-id YOUR_AWS_ACCOUNT_ID --asset-bundle-export-job-id YOUR_EXPORT_JOB_ID --resource-arns YOUR_RESOURCE_ARN --include-all-dependencies --export-format QUICKSIGHT_JSON –asset-bundle-export-job-id の値はエクスポートジョブの期間中、一意である必要があります。QuickSight では、アセットバンドルエクスポートジョブを最大 5 つ同時に実行できます。 エクスポートジョブは、ダッシュボード、データセット、データソース JSON 出力 (または CloudFormation 形式) を含む .qs ファイル拡張子の .zip ファイルを生成します。 この .zip ファイルは Amazon S3 に保存されます。 エクスポート ジョブが完了すると、.qs ファイルの場所を示す S3 の署名付き URL が生成されます。この URL は 5 分間だけ有効です。この URL が期限切れになった場合は、describe-asset-bundle-export-job コールを実行して再度有効化してください。 API が非同期であるため、バンドルのエクスポートの進捗状況を確認するには、次のコマンドを入力してください: aws quicksight describe-asset-bundle-export-job --aws-account-id YOUR_AWS_ACCOUNT_ID --asset-bundle-export-job-id YOUR_EXPORT_JOB_ID 次のコードは、出力がどのようになるかを示しています。 { "Status": 200, "JobStatus": "SUCCESSFUL", "DownloadUrl": "https://QuickSight-asset-bundle-export-job-us-east-1.s3.amazonaws.com/ YOUR_AWS_ACCOUNT_ID / YOUR_EXPORT_JOB_ID/ .../asset-bundle.qs ? X-Amz-Security-Token =...", "Arn": "arn:aws:QuickSight:us-east-1:AWS_ACCOUNT_ID:asset-bundle-export-job/job-1", "CreatedTime": "2023-12-19T04:06:37 + 00:00", "AssetBundleExportJobId": "job-1", "AwsAccountId": "AWS_ACCOUNT_ID", "ResourceArns": [ "arn:aws:QuickSight:us-east-1:AWS_ACCOUNT_ID:dashboard/4c9f55d7-9fdb-41ca-be97-a2d2f0c38c29" ], "IncludeAllDependencies": true, "ExportFormat": "QuickSight_JSON", "RequestId": "8491111e-9cba-4f23-a63d-5b1572540419" } DownloadUrl の値をコピーし、curl を使って Amazon S3 からファイルをダウンロードします。DownloadURL の値を二重引用符で囲むようにしてください: curl "DownloadUrl" --output asset_bundle.qs 以下のコマンドを使用して、コンテンツを解凍してください。 unzip asset_bundle.qs 次のスクリーンショットは、フォルダ構造がどのようになるかを示しています。 QuickSight には、インポート中にホスト名、パスワード、データ ソース名などのパラメーターを上書きする場合に、すぐに使えるいくつかのオプションが用意されています。これを行うには、 AssetBundleImportJobOverrideParameters API を使用してください。 パラメータ化しようとしている属性が API でサポートされていない場合は、それらのパラメータをテンプレート上で手動で追加する必要があります。スクリプトを使ってパラメータを検索し、必要な値に置き換えることができます。この記事では、検索と置換のプロセスについては扱いません。 エクスポートされたバンドルのファイルを見ると、各 JSON ファイルには ID として datasourceId、dataSetId、dashboardId があり、次のスクリーンショットのように、更新する必要のある name キーがあります。 テナントごとに dashboardId、datasetId、name を一意にすることは必須です。 次の例には、国用のデータセットフィルターがあり、テナントごとに異なる値に設定する必要があります。ダッシュボードには同じフィールドやフィルターがない場合があります。表示・設定したい列またはフィルターを選択します。 次のスクリーンショットでは、元のフィルタを示しています。 次のスクリーンショットは、新しいパラメータでフィルターしたものを示しています。 ここで、プロセスを自動化して、スクリプトに {{ COUNTRY_PARAMETER }} を関連する値に置き換えさせることができます。 この投稿では、手作業で {{ COUNTRY_PARAMETER }} に値を設定してファイルを保存します。 dashboard 、 dataset 、 datasource フォルダと同じディレクトリレベルに移動し、新しい .zip ファイルを作成してください。 zip -r new_bundle.qs dashboard dataset datasource 新しいバンドルファイルを Amazon S3 にアップロードします: aws s3 cp new_bundle.qs s3:// YOUR_S3_BUCKET /new_bundle.qs 以下の AWS CLI コマンドでインポートジョブを開始します: aws quicksight start-asset-bundle-import-job --aws-account-id YOUR_AWS_ACCOUNT_ID --asset-bundle-import-job-id YOUR_IMPORT_JOB_ID --region us-east-1 --asset-bundle-import-source "{ \"S3Uri\": \"s3:// YOUR_S3_BUCKET /new_bundle.qs\"}" 進行状況を確認するには、次のコマンドを入力してください。 aws quicksight describe-asset-bundle-import-job --aws-account-id YOUR_AWS_ACCOUNT_ID --asset-bundle-import-job-id YOUR_IMPORT_JOB_ID バンドルをインポートした後、作成されたアセットは、誰からも見えたり、アクセスできない状態になっています。これは、設計上、バンドルにはアクセス許可が含まれていないためです。 複数のテナントにアクセスできるようにするため、新しいダッシュボードにグループの権限を追加するには、次のコマンドを入力します (YOUR_PRINCIPAL_ARN の値は作成した IAM ユーザーを指定できます)。 aws quicksight update-dashboard-permissions --aws-account-id YOUR_AWS_ACCOUNT_ID --dashboard-id YOUR_DASHBOARD_ID --grant-permissions Principal = YOUR_PRINCIPAL_ARN ,Actions = QuickSight:DescribeDashboard,QuickSight:QueryDashboard,QuickSight:ListDashboardVersions テナントグループのダッシュボードの権限を更新したら、ジョブが完了し、ユーザーがそれにアクセスできるようになります。ユーザーがデータセットにアクセスする必要がある場合は、そのアセットの権限を更新する必要があります。 次のコマンドを入力してパーミッションを更新してください: aws quicksight update-data-set-permissions --aws-account-id YOUR_AWS_ACCOUNT_ID --data-set-id YOUR_DATASET_ID --grant-permissions Principal = YOUR_QUICKSIGHT_ARN ,Actions = QuickSight:DescribeDataSet,QuickSight:DescribeDataSetPermissions,QuickSight:PassDataSet,QuickSight:DescribeIngestion,QuickSight:ListIngestions アセットを別の名前空間にデプロイ 別の名前空間にアセットをデプロイするには、テンプレートにパラメータを追加することから始め、前述の手順を繰り返します。 結論 この記事では、マルチテナントの SaaS 環境で QuickSight レポートをデプロイする際の設計上の考慮事項について説明しました。 設計する上で最初に決定しなければならないことは、テナント間での権限分離についてです。 テナントがリソースを作成または編集できる場合は、名前空間が最適です。 その次の設計の判断基準は、行レベルセキュリティを持つか、テナントごとに単一のデータセットを持つかです。 SPICE データセット間の分離を持つには、テナントごとのデータセットが必要です。 この記事の最後のセクションでは、テナント間でアセットバンドルをデプロイする方法のガイダンスを提供しました。 QuickSight の組み込み分析とマルチテナンシーの詳細は、 Build embedded analytics architectures using Amazon QuickSight および Embed multi-tenant analytics in applications with Amazon QuickSight を参照してください。 著者について Evangelos Pertsinis   は、アマゾンウェブサービスのソリューションアーキテクトです。彼は、顧客が AWS テクノロジーを効率的に活用できるよう支援しています。エンドツーエンドのデータ ソリューションの設計と構築の経験を持つエヴァンゲロスは、顧客と協力してデータの価値を引き出すことに情熱を注いでいます。自由時間には、エヴァンゲロスはサッカー、ハイキング、釣りを楽しんでいます。 Mike Gillespie は、アマゾンウェブサービスのプリンシパルソリューションアーキテクトです。彼は、AWS でソリューションを実行するソフトウェア会社と協力し、AWS を使用して製品を改善するのを支援しています。 Mike は、機械学習、分析、サーバーレス、セキュリティなどのさまざまなドメインでソリューションを構築する、実践的なテクノロジを好むビルダーです。仕事以外では、マイクは屋外でランニングやパドリングをしたり、ポッドキャストを聴きながら犬の散歩をしたり、写真を撮ったりすることを楽しんでいます。 Ramon Lopez は、Amazon QuickSight のプリンシパルソリューションアーキテクトです。 BI ソリューションの構築に長年の経験と会計のバックグラウンドを持つ彼は、顧客と協力してソリューションを作成し、世界クラスのサービスを作成することが大好きです。仕事以外の時は、海や山など屋外で過ごすことを好みます。

AWS Cloud Development Kit (CDK) はクラウドリソースの作成に一般的なプログラミング言語を使えるようにすることで、クラウド上での開発を加速します。この速度の利点を生かすためには、アクセス許可やセキュリティ制御が開発速度を低下させないような環境が必要です。しかし厳格に管理された環境では、そうしたことが必ずしも保証されているわけではありません。一方で懸念されるのは、開発者が AWS Identity and Access Management (IAM) エンティティ (ユーザーやロールなど) を作成する権限を持つ場合です。この場合、権限の昇格が可能になってしまい、IAM エンティティの作成者である開発者よりも広範なアクセス許可を持つエンティティが作成できてしまうおそれがあります。このような課題は一般的に、 IAM エンティティのアクセス許可境界 を使うことで解決できます。本ブログではこのアクセス許可境界を CDK アプリケーション開発に適用する方法について説明し、セキュリティを確保しながらスピーディな開発を実現します。 カスタムアクセス許可境界を CDK アプリケーションのデプロイに適用する CDK アプリケーションをデプロイする際、ユーザーに代わって操作を実行するための AWS CloudFormation サービスロール が利用されます。この IAM ロールは、 ブートストラップフェーズ で AWS CDK コマンドラインインターフェース (CLI) によって作成されます。このロールは、開発者に代わって CloudFormation がデプロイを実行するために必要な操作を許可する必要がありますが、組織のコンプライアンスやセキュリティの目標を損なわないようにもする必要があります。開発者が IAM エンティティを作成し、そこにアクセス許可を割り当てる必要がある場合、この作業は複雑な結果を生むことがあります。開発者が割り当てたアクセス許可が、開発者が持つ既存のアクセス許可を超えることで権限昇格がなされる可能性があるためです。これらのエンティティの作成を許可しないことは、この問題を解決する 1 つの方法です。しかし、その場合は、開発者が管理者に新規のリソースを都度要求しなければならず、スピーディな開発に対して大きな障害となります。セキュリティを重視した環境では、スタック内の各 AWS Lambda 関数など、個別のユースケースごとに個別の IAM ロールを作成することが考えられるため、この問題はより困難になります。この方法ではなく、IAM アクセス許可境界を使えば、次の 2 つのメリットが得られます。1 つ目は、すべてのアクションがユーザーの持つアクセス許可とアクセス許可境界の重なり合う部分に収まることが保証されます。2 つ目は、作成される IAM エンティティにも同じアクセス許可境界が適用されることが保証されます。これにより、開発者による IAM エンティティの作成を制限することなく、権限昇格の経路をブロックできます。最新バージョンの AWS CLI では、ブートストラップコマンドの実行時に自動的にこれらのアクセス許可境界をサービスロールに適用できるだけでなく、CDK スタックで作成された IAM エンティティにもアクセス許可境界を設定できます。 CDK でアクセス許可境界を使用するには、まず IAM ポリシーを作成 し、それをアクセス許可境界として使用します。このポリシーでは、CDK アプリケーションがデプロイ時と運用時に開発者に代わって実行できるアクションセットの上限を定義する必要があります。この手順は通常、アカウントのセキュリティを担当する管理者が実行し、適切なアクセス許可境界とコントロールを設定します。作成後、このポリシーの名前を bootstrap コマンドに指定します。以下の例では、IAM ポリシー「developer-policy」を使用して、コマンドの利用方法を説明しています。 cdk bootstrap --custom-permissions-boundary developer-policy このコマンドを実行すると、新しい bootstrap スタックが作成され (または既存のスタックが更新されて)、実行ロールにこのアクセス許可境界が適用されます。次に、作成されるすべての IAM エンティティにも同じアクセス許可境界が適用されるようにできます。これは、CDK コンテキスト変数を使用するか、それらのリソースの permissionBoundary 属性を設定することで実現できます。この機能の詳細を説明するため、実際のユースケースを想定したシナリオとして、開発者の AWS Config サービスの利用を制限する方法を例として説明します。 AWS CDK CLI のインストールまたはアップグレード 最初に、AWS CDK CLI ツールの最新バージョンがインストールされていることを確認してください。 ドキュメントの指示 に従ってこれを完了してください。この新機能を利用するには、バージョン 2.54.0 以上が必要です。インストールされているバージョンを確認するには、次のコマンドを実行してください。 cdk --version ポリシーの作成 最初に、新しい IAM ポリシーを作成しましょう。以下は、このサンプルで使用するアクセス許可ポリシーを作成する CloudFormation テンプレートです。この場合は AWS CLI で直接デプロイできますが、 CloudFormation Stack Sets のようなメカニズムを使えば、自動化して大規模に実行することも可能です。このテンプレートには、次のポリシーステートメントが含まれています。 デフォルトですべてのアクションを許可します。これにより、選択したアクションを特定して拒否できます。ただし、独自のポリシーを作成する際は、アクション許可/拒否のアプローチを慎重に検討する必要があります。 「developer-policy」のアクセス許可境界が使用されていない場合、ユーザーまたはロールの作成を拒否します。また、既存のエンティティへのアクセス許可境界の割り当ても、「developer-policy」のみを許可するように制限します。これにより、ポリシーを超えた権限を持つエンティティの作成や変更を防ぐことができます。 そのポリシー自体の変更を拒否します。これにより、開発者がその境界内で操作できる範囲を変更できなくなります。 ユーザーやロールからアクセス許可境界を削除する機能を拒否します。 AWS Config サービスに対するすべてのアクションを拒否します。 項目 2、3、4 は、アクセス許可境界が正常に機能するための下準備です。アクセス許可境界が削除、改ざん、回避されることを防ぐ制御機構です。このポリシーの中心は、項目 1 と 5 であり、ここでは特定のアクションを拒否する (許可リストアプローチではなく、拒否リストを用いたアプローチ) 以外のすべてを許可しています。 Resources: PermissionsBoundary: Type: AWS::IAM::ManagedPolicy Properties: PolicyDocument: Statement: # ----- Begin base policy --------------- # If permission boundaries do not have an explicit allow # then the effect is deny - Sid: ExplicitAllowAll Action: "*" Effect: Allow Resource: "*" # Default permissions to prevent privilege escalation - Sid: DenyAccessIfRequiredPermBoundaryIsNotBeingApplied Action: - iam:CreateUser - iam:CreateRole - iam:PutRolePermissionsBoundary - iam:PutUserPermissionsBoundary Condition: StringNotEquals: iam:PermissionsBoundary: Fn::Sub: arn:${ AWS::Partition }:iam::${ AWS::AccountId }:policy/developer-policy Effect: Deny Resource: "*" - Sid: DenyPermBoundaryIAMPolicyAlteration Action: - iam:CreatePolicyVersion - iam:DeletePolicy - iam:DeletePolicyVersion - iam:SetDefaultPolicyVersion Effect: Deny Resource: Fn::Sub: arn:${ AWS::Partition }:iam::${ AWS::AccountId }:policy/developer-policy - Sid: DenyRemovalOfPermBoundaryFromAnyUserOrRole Action: - iam:DeleteUserPermissionsBoundary - iam:DeleteRolePermissionsBoundary Effect: Deny Resource: "*" # ----- End base policy --------------- # -- Begin Custom Organization Policy -- - Sid: DenyModifyingConfig Effect: Deny Action: config:* Resource: "*" # -- End Custom Organization Policy -- Version: "2012-10-17" Description: "Bootstrap Permission Boundary" ManagedPolicyName: developer-policy Path: / 上の内容を developer-policy.yaml としてローカルに保存し、AWS CLI の CloudFormation コマンドでデプロイできます。 aws cloudformation create-stack --stack-name DeveloperPolicy \ --template-body file://developer-policy.yaml \ --capabilities CAPABILITY_NAMED_IAM ポリシーをテストするためのスタックの作成 始めるにあたり、アクセス許可境界の動作をテストして観察するために使用する新しい CDK アプリケーションを作成します。次のコマンドを実行して、TypeScript CDK アプリケーションを含む新しいディレクトリを作成してください。 mkdir DevUsers && cd DevUsers cdk init --language typescript まず、 cdk bootstrap コマンドを使用して CDK ブートストラップスタックをデプロイする必要があります。最初はアクセス許可境界を適用しないでください。後で追加し、デプロイの動作がどのように変化するかを確認します。bootstrap コマンドは --cloudformation-execution-policies 引数を使用していないため、デフォルトで arn:aws:iam::aws:policy/AdministratorAccess が適用されます。つまり、アクセス許可境界が適用されるまで、CloudFormation がアカウントに対する完全なアクセス許可を持つことになります。 cdk bootstrap コマンドが実行されたら、アクセス許可境界が適用される前に問題なくこれが機能することを確認するために、アプリケーションに AWS Config Rule を作成してください。ファイル lib/dev_users-stack.ts を開き、その内容を以下のサンプルのように編集してください。 import * as cdk from 'aws-cdk-lib'; import { ManagedRule, ManagedRuleIdentifiers } from 'aws-cdk-lib/aws-config'; import { Construct } from "constructs"; export class DevUsersStack extends cdk.Stack { constructor(scope: Construct, id: string, props ?: cdk.StackProps) { super(scope, id, props); new ManagedRule(this, 'AccessKeysRotated', { configRuleName: 'access-keys-policy', identifier: ManagedRuleIdentifiers.ACCESS_KEYS_ROTATED, inputParameters: { maxAccessKeyAge: 60, // default is 90 days }, }); } } 次に、 cdk deploy コマンドを使って CDK CLI でデプロイできます。この操作は成功するはずです (重要な項目の概要を示すために、一部の出力は省略されています)。 ❯ cdk deploy Synthesis time: 3.05s DevUsersStack Deployment time: 23.17s Stack ARN: arn:aws:cloudformation:ap-southeast-2:123456789012:stack/DevUsersStack/704a7710-7c11-11ed-b606-06d79634f8d4 Total time: 26.21s アクセス許可境界をデプロイする前に、 cdk destroy コマンドを使ってこのスタックを削除してください。 ❯ cdk destroy Are you sure you want to delete: DevUsersStack (y/n)? y DevUsersStack: destroying... [1/1] DevUsersStack: destroyed CDK テストアプリケーションでアクセス許可境界を使用する 作成したアクセス許可境界を適用し、同じスタックのデプロイに与える影響を確認してみましょう。アクセス許可境界を設定するためにブートストラップスタックを更新するには、新しい custom-permissions-boundary パラメータを指定して cdk bootstrap コマンドを再実行します。 cdk bootstrap --custom-permissions-boundary developer-policy このコマンドが実行された後、CloudFormation の実行ロールは、 config:* の拒否ルールに基づいて同じアプリケーションのデプロイが失敗するように、そのポリシーをアクセス許可境界として使用するように更新されます。この内容を確認するためには、再度 cdk deploy を実行し、エラーメッセージを確認してください。 Deployment failed: Error: Stack Deployments Failed: Error: The stack named DevUsersStack failed creation, it may need to be manually deleted from the AWS console: ROLLBACK_COMPLETE: User: arn:aws:sts::123456789012:assumed-role/cdk-hnb659fds-cfn-exec-role-123456789012-ap-southeast-2/AWSCloudFormation is not authorized to perform: config:PutConfigRule on resource: access-keys-policy with an explicit deny in a permissions boundary これは、アクセス許可境界によってアクションが意図通りに拒否されたことを示しています。 IAM エンティティへのアクセス許可境界の自動適用 次に、CDK アプリケーションによって作成された IAM エンティティにアクセス許可境界を拡張する方法を見ていきましょう。ここで懸念されるのは、新しい IAM エンティティを作成する開発者が、自分自身が持っているよりも強力なアクセス許可をそのエンティティに割り当てる可能性があることです。アクセス許可境界が付与されたエンティティのみを作成できるよう制限することでこの事態を予防します。この動作はスタックを変更し、アクセス許可境界を含まない IAM ロールを使用する Lambda 関数をデプロイすることで検証できます。 lib/dev_users-stack.ts ファイルを再度開き、以下のサンプルを反映するように編集してください。 import * as cdk from 'aws-cdk-lib'; import { PolicyStatement } from "aws-cdk-lib/aws-iam"; import { AwsCustomResource, AwsCustomResourcePolicy, PhysicalResourceId, } from "aws-cdk-lib/custom-resources"; import { Construct } from "constructs"; export class DevUsersStack extends cdk.Stack { constructor(scope: Construct, id: string, props ?: cdk.StackProps) { super(scope, id, props); new AwsCustomResource(this, "Resource", { onUpdate: { service: "ConfigService", action: "putConfigRule", parameters: { ConfigRule: { ConfigRuleName: "SampleRule", Source: { Owner: "AWS", SourceIdentifier: "ACCESS_KEYS_ROTATED", }, InputParameters: '{"maxAccessKeyAge":"60"}', }, }, physicalResourceId: PhysicalResourceId.of("SampleConfigRule"), }, policy: AwsCustomResourcePolicy.fromStatements([ new PolicyStatement({ actions: ["config:*"], resources: ["*"], }), ]), }); } } ここで AwsCustomResource を使用して、新しい Config ルールを作成する Lambda 関数をプロビジョニングしています。これは先ほどのスタックと同じ結果ですが、この場合はルールの作成が CDK コンストラクトによって作成される新しい IAM ロールによって行われます。このままデプロイを試みると失敗します。この動作を確認するには、 cdk deploy を実行してください。 Deployment failed: Error: Stack Deployments Failed: Error: The stack named DevUsersStack failed creation, it may need to be manually deleted from the AWS console: ROLLBACK_COMPLETE: API: iam:CreateRole User: arn:aws:sts::123456789012:assumed- role/cdk-hnb659fds-cfn-exec-role-123456789012-ap-southeast-2/AWSCloudFormation is not authorized to perform: iam:CreateRole on resource: arn:aws:iam::123456789012:role/DevUsersStack- AWS679f53fac002430cb0da5b7982bd2287S-1EAD7M62914OZ with an explicit deny in a permissions boundary このエラーメッセージは、アクセス許可境界が適用されていないために、 iam:CreateRole の呼び出しに失敗したため、スタックをデプロイできなかったことを説明しています。CDK では cdk.json ファイル内の CDK コンテキスト変数 core:permissionsBoundary を介して、作成されたすべての IAM エンティティにデフォルトのアクセス許可境界を設定する簡単な方法が提供されています。 { "context": { "@aws-cdk/core:permissionsBoundary": { "name": "developer-policy" } } } この context を利用したアプローチによって、インポートした IAM エンティティを作成するコンストラクト ( Construct Hub で見つけたものや、デフォルトの IAM ロールを作成する既存のコンストラクトなど) に対してもアクセス許可境界が適用されるようになります。このアプローチが適さない場合、別の方法として特定のロールにアクセス許可境界を設定することもできます。 cdk.json ファイルを変更して、再度 CDK デプロイを実行します。今度はカスタムリソースが CloudFormation 実行ロールではなくアクセス許可境界が付与された IAM ロールを使用して Config ルールの作成を試みます。同様に、このアクセス許可境界により Lambda 関数が許可されていないアクションの実行から保護されます。これを確認するために、再度 cdk deploy を実行してください。CloudFormation のデプロイ更新では、今回はロール作成が成功し、新しいエラーメッセージが生成されていることがわかります。 Deployment failed: Error: Stack Deployments Failed: Error: The stack named DevUsersStack failed creation, it may need to be manually deleted from the AWS console: ROLLBACK_COMPLETE: Received response status [FAILED] from custom resource. Message returned: User: arn:aws:sts::123456789012:assumed-role/DevUsersStack- AWS679f53fac002430cb0da5b7982bd2287S-84VFVA7OGC9N/DevUsersStack- AWS679f53fac002430cb0da5b7982bd22872-MBnArBmaaLJp is not authorized to perform: config:PutConfigRule on resource: SampleRule with an explicit deny in a permissions boundary このエラーメッセージから、参照されているユーザーが DevUsersStack-AWS679f53fac002430cb0da5b7982bd2287S-84VFVA7OGC9N であり、CloudFormation の実行ロールではないことがわかります。カスタム Lambda 関数リソースで使用されているロールで Config ルールの作成を試みると、同様にアクセス許可境界により拒否されます。ここから、アクセス許可境界が CDK アプリ内で作成されるすべての IAM エンティティに一貫して適用される様子がわかります。これにより、開発者が行う作業すべてに対して、管理コントロールを最小限のオーバーヘッドで一貫して適用することが可能になります。 クリーンアップ クリーンアップでは CDK ブートストラップスタックを削除するか、スタックからアクセス許可境界を削除するかを選択できます。削除する場合は、次の AWS CLI コマンドで CloudFormation から CDKToolkit スタックを削除します。 aws cloudformation delete-stack --stack-name CDKToolkit ブートストラップスタックを保持したい場合は、次の手順に従ってアクセス許可境界を削除できます。 AWS コンソールの CloudFormation ページに移動し、CDKToolkit スタックを選択します。 「更新」ボタンを選択します。「現在のテンプレートの使用」を選択し、次に「次へ」をクリックします。 パラメータページで、値「developer-policy」が設定されている InputPermissionsBoundary を見つけ、このインプットのテキストを削除して空欄にします。「次へ」をクリックし、次のページでも「次へ」をクリックします。 最終ページで下までスクロールし、CloudFormation がカスタム名の IAM リソースを作成する可能性があることを認める確認ボックスにチェックを入れ、「送信」を選択します。 アクセス許可境界はもう使用されていないので、最後のステップとして、アクセス許可境界の作成に利用したスタックを削除できます。 aws cloudformation delete-stack --stack-name DeveloperPolicy おわりに IAM のアクセス許可境界をどのようにシンプルに CDK 開発に統合できるかがわかりました。開発者が必要なコントロールを与えつつ、管理者はセキュリティを組織の要件に沿った方法で管理できるようになります。 この点を踏まえた上で、アクセス許可境界の使用をさらに拡張するための次のステップがあります。GitHub の CDK Security and Safety Dev Guide では、これらのアプローチと、デプロイ時の権限アプローチの考え方を説明しています。開発者とセキュリティ管理者はこれを確認し、セキュリティ目標に合った適切な権限ポリシーのアプローチを開発することをお勧めします。 さらに、アクセス許可境界の概念を、各ステージに個別のアクセス許可境界名を適用するマルチアカウントモデルに適用できます。これにより、下位レベルの環境 (開発環境やベータ環境など) にはトラブルシューティングやその他の開発者固有のアクションに適した緩やかなアクセス許可境界を設定しつつ、上位レベルの環境 (ガンマまたは本番環境など) にはセキュリティリスクを適切に管理するために制限の厳しいアクセス許可境界を設定できるようになります。このメカニズムを実装する方法は、CDK Security and Safety Dev Guide でも紹介されています。 本記事は、 Secure CDK deployments with IAM permission boundaries を翻訳したものです。翻訳は Solutions Architect の 山崎 宏紀が担当しました。

3月4日週の金曜日は国際女性デー (IWD) でした。本題に入る前に、テクニカルリーダーとしての地位に昇りつめ、Amazon の CTO であるワーナー ヴォゲルスが言うところの「構築し始める」ためのインスピレーションを周りの人々に与えることによってガラスの天井を打破している、クラウドコンピューティング分野の素晴らしい女性たちに感謝の意を表したいと思います。 3月4日週のリリース 3月4日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 Amazon Bedrock – Anthropic の Claude 3 Sonnet 基盤モデルがサポートされるようになりました。Claude 3 Sonnet は、Anthropic で最も優れたパフォーマンスを提供するモデルである Claude 2 や Claude 2.1 と同レベルのインテリジェンスを備えながら、速度は 2 倍になっています。私が気に入っている Sonnet の特徴は、JSON 出力をよりよく生成できるため、開発者がアプリケーションをより簡単に構築できるという点です。また、ビジョン機能も提供しています。この基盤モデル (FM) の詳細については、先週初めに Channy が書いた記事 をお読みください。 AWS re:Post – 先週ローンチされました! AWS re:Post Live は毎週配信される Twitch ライブストリーム 番組で、コミュニティが専門家と交流し、質問して、スキルを磨く手段を提供します。この番組は、毎週月曜日の午前 11 時 (米国太平洋標準時) にライブストリーミングされます。 Amazon CloudWatch – CloudWatch メトリクスストリームで日次メトリクスをストリーミングするようになりました 。メトリクスストリームを使用することで、ユーザーが選択した送信先にほぼリアルタイムのメトリクスのストリームを送信できます。 Amazon Elastic Compute Cloud (Amazon EC2) – 新しいメタルインスタンスである C7gd、M7gd、および R7gd の一般提供が発表されました 。これらのインスタンスは、最大 3.8 TB のローカル NVMe ベースの SSD ブロックレベルストレージを使用し、AWS Nitro System 上に構築されています。 AWS WAF – レートベースのルールを用いたリクエスト集約のために、設定可能な評価時間枠がサポートされるようになりました 。これまで、ルールを集約および評価するときの AWS WAF の時間枠は 5 分に固定されていました。これからは、アプリケーションのユースケースに応じて、1 分、2 分、5 分、または 10 分の時間枠を選択できるようになります。 AWS パートナー – 先週、 AWS 生成 AI コンピテンシーパートナーが発表されました。 この新しい専門分野には、AWS を利用した生成人工知能 (AI) における技術的能力と、プロジェクトで成功を収めた実績を実証する AWS パートナーが集められています。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 その他の AWS ニュース 皆さんが見逃した可能性がある、その他の更新情報とニュースです。 最近私が興味を持った記事の 1 つに、 サーバーレスマイクロサービスを構築するためのさまざまな設計アプローチを比較 する記事があります。Luca Mezzalira と Matt Diamond が執筆したこの記事では、サーバーレスワークロードの最も一般的な 3 つの設計を比較して、それぞれを使用する場合の利点と課題を説明しています。 サーバーレス分野に関心があるならば、毎週火曜日の午前 10 時 (米国太平洋標準時) にライブ配信される Serverless Office Hours をぜひご覧ください。サーバーレス分野からの最新情報に関して毎週行われる AWS サーバーレスデベロッパーアドボケートとのチャットに参加しましょう。 AWS の公式ポッドキャスト  – 最新の AWS ニュースや興味深いユースケースの詳細情報を毎週お届けします。AWS の公式ポッドキャストは、数か国語で配信されています。 フランス語 、 ドイツ語 、 イタリア語 、および スペイン語 のポッドキャストもぜひご利用ください。 AWS オープンソースに関するニュースと最新情報  – 私の同僚である Ricardo  が厳選した情報をお届けする ニュースレター では、最新のオープンソースプロジェクト、記事、イベントなどが取り上げられています。 近日開催される AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Summit のシーズンがもうすぐ始まります。最初の AWS Summit は、 パリ (4 月 3 日)、 アムステルダム (4 月 9 日)、 ロンドン (4 月 24 日)で開催されます。AWS Summit は、会場で直接参加し、AWS テクノロジーの最新情報を学ぶことができる無料イベントです。 GOTO x AWS EDA Day London 2024 – 5 月 14 日、AWS パートナーと GOTO が EDA (イベント駆動型アーキテクチャ) Day カンファレンスを開催します。このカンファレンスでは、EDA 分野の専門家に会い、お客様、専門家、AWS からの非常に興味深い話を聞くことができます。 こちらで、 近日中に開催されるすべての対面およびバーチャルイベントを閲覧 することができます。 3月11日週のニュースは以上です。3月18日週に再びアクセスして、新たな Week in Review をぜひお読みください! –  Marcia この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

Amazon Aurora は、クラウド向けに構築された MySQL および PostgreSQL 互換のリレーショナルデータベースです。Aurora は、従来のエンタープライズデータベースのパフォーマンスと可用性と、オープンソースのデータベースのシンプルさとコスト効率を持ち合わせています。 Amazon Aurora MySQL は MySQL 5.7 と互換性に加え、 MySQL 8.0 とも互換性があります。MySQL 8.0 互換の Aurora MySQL 3 が一般提供されています。 Aurora MySQL 3 は、共通テーブル式 (CTE) のサポート、ロールベースの認証、レプリケーションの強化、ウィンドウ関数、インスタント DDL など、いくつかの新機能を導入しています。ローンチ時点で、Aurora MySQL 3 は MySQL 8.0.23 コミュニティエディションとの互換性があり、Aurora がサポートされているすべての AWS リージョン で利用できます。 この投稿では、Aurora MySQL 3 と MySQL Community Edition 8.0 のバージョン間での調整事項、このバージョンがもたらす主な新機能、重大な変更、この新しいバージョンをワークロードに採用するために知っておくべきことなど、この新しいリリースのさまざまな側面について説明します。 MySQL Community Edition マイナーバージョンとのより緊密な互換性 機能と機能性について掘り下げる前に、新しい MySQL Community Edition リリースでのバージョン互換性の維持について、私たちがどのような考え方をしているかについて触れておきましょう。マイナーバージョンの互換性の観点から、すべての Aurora MySQL 2 エンジンバージョンは、 MySQL 5.7.12 もしくは 5.7.40 Community Edition とワイヤー互換性があります。   Aurora MySQL との互換性を備えた新機能をリリースしたり、MySQL コミュニティエディションの機能やその他の修正を Aurora マイナーバージョンに提供したりするたびに、個別の Aurora バージョンを維持しています。 Aurora MySQL 3 から、このリリース戦略を MySQL コミュニティエディションのリリースにより密接に追従するように変更します。各 Aurora MySQL 3 リリースは、対応する MySQL 8.0 コミュニティエディションリリースにマッピングされます。たとえば、Aurora MySQL 3.01 は MySQL 8.0.23 にマッピングされ、その特定のコミュニティエディションマイナーバージョンとワイヤー互換性があります。これは、その特定のマイナーバージョンに追加されたすべての修正とコード変更が含まれることを意味します。 Aurora MySQL 3 のマイナーバージョンでは、Aurora 固有の修正と機能の追加だけでなく、MySQL 8.0 コミュニティエディションとの互換性を維持し、コミュニティのバグ修正と機能が継続的に取り入れられるようにします。 Aurora MySQL 2 から Aurora MySQL 3 へのサポートされるアップグレードパス Aurora MySQL DB クラスタをバージョン 3 にアップグレードする前にアップグレード評価を実行し、対応が必要なすべての項目に対処してください。 mysqlcheck--check-upgrade コマンドを使用して評価を実行できます。また、本番の Aurora データベース クラスタのアップグレードを考慮する前に、アップグレードされた Aurora MySQL 3 のバージョンでアプリケーションのテストを行う必要があります。詳細については、この投稿の「動作の変更」の章や、 Amazon Aurora ユーザーガイド を確認してください。 起動時に、スナップショットリストアを使用して Aurora MySQL 2 から Aurora MySQL 3 へアップグレードできます。このアップグレードパスを使用するには、現在の Aurora MySQL 2 クラスタのスナップショットを取得し、復元中に Aurora MySQL 3 バージョンを選択する必要があります。Aurora は Aurora MySQL 2 スナップショットを復元し、必要なアップグレード手順を自動的に実行します。新しく復元された DB クラスターは、Aurora MySQL 3 DB インスタンスを使用してデプロイされます。カスタムクラスターまたはインスタンスレベルのパラメータグループを使用している場合は、Aurora MySQL 3 用の新しいカスタムパラメータグループを作成し、Aurora コンソールの 「 DB クラスターを復元 」ページの「追加設定」 下の 「データベースオプション」 でそれらを選択する必要があります。あるいは、 AWS Command Line Interface (AWS CLI) または SDK を使用してリストアする場合は、適切な API 呼び出しに新しいカスタムパラメータグループを指定します。 本番ワークロードの場合、データベースを利用しているワークロードの「常にアクティブ」であるという性質上、アップグレードプロセス中のダウンタイムを最小限に抑えることが望ましい場合があります。ダウンタイムを最小限に抑えたアップグレードを実行するには、まずスナップショットを取得する前に、古い Aurora MySQL 2 DB クラスタでバイナリログレプリケーションを有効にします。その後スナップショットを復元して、Aurora MySQL 3 クラスタとして作成します。これにより、このクラスターにはAurora MySQL 2 クラスタからのすべてのデータが含まれるようになります。Aurora MySQL 2 をソース、 Aurora MySQL 3 をターゲットとしてバイナリログレプリケーションを設定します。 Amazon RDS ブルー/グリーンデプロイ を利用することで、レプリケーション設定や切り替え手順の簡素化ができます。レプリケーションがすべての変更をキャッチアップした後(レプリケーションが実行されており、レプリカのラグがゼロであることを確認)、レプリケーションを停止し、Aurora MySQL 3 クラスタをプライマリデータベースとして使用を開始できます。 Aurora MySQL 3 で導入された主な新機能 Aurora MySQL 3 は、多くの新しい MySQL 8.0 機能を利用できるようになりました。ユーザーガイドにすべての機能についてのリストがあります。このセクションでは、多くの Aurora のお客様から要望のあった機能を紹介します。 バイナリログの改善 Aurora MySQL はローンチ時からバイナリログレプリケーションをサポートしており、Aurora MySQL 3 でも継続してサポートされています。Aurora MySQL 3 は以前のバージョンと比較して、次のようないくつかの改善点があります: マルチスレッドレプリケーション – Aurora MySQL 3 はマルチスレッド レプリケーション(MTR)をサポートしています。これは、レプリカ DB クラスターで replica_parallel_workers に 0 より大きい値を設定することで有効にできます。MTR は、プライマリ DB インスタンスで高頻度の書き込みを生成するようなワークロードなど、特定のシナリオでバイナリログレプリケーションのパフォーマンスを改善できます。プライマリ DB インスタンスで行われたすべての変更は、レプリカ上で再生する必要があり、同期を取るためです。シングルスレッドのレプリケーションと比較して、マルチスレッド レプリケーションはレプリカ上の変更を並列して適用できるため、レプリケーションラグを短縮できる可能性があります。  レプリケーションフィルタリング – Aurora MySQL 3 はバイナリログのレプリケーション フィルタリングのサポートも取り入れられています。レプリケーションフィルタを使用すると、どのデータベースとテーブルをレプリケートするかを指定できます。レプリケーションフィルタでは、レプリケーションにデータベースやテーブルを含めたり、除外したりできます。 replicate-do-* と replicate-ignore-* のフィルタリングパラメータを使用して、レプリケーションを実装できます。  バイナリログトランザクション圧縮 – Aurora MySQL 3 でバイナリログトランザクション圧縮を有効にして利用できます。有効にすると、zstd アルゴリズムを使用してトランザクションペイロードが圧縮されます。圧縮されたトランザクションはバイナリログに書き込まれ、圧縮されたまま転送やバイナリログレプリカに保存されます。これにより、プライマリとレプリカの Aurora MySQL クラスタの両方でディスク領域を節約できます。また、ネットワーク帯域幅の消費を抑え、転送時のパフォーマンスが向上します。  インスタント DDL Aurora MySQL 3 はインスタント DDL をサポートしています。ALTER TABLE ステートメントの ALGORITHM = INSTANT 句を使用することで、インスタント DDL 機能を利用できます。この機能により、列の追加、列のデフォルト値の設定や削除、テーブルの名前変更など、 サポートされているスキーマ変更 が大幅に高速化されます。これらのサポートされている DDL 操作は、オンライン (ALGORITHM = INPLACE) やオフライン (ALGORITHM = COPY) の代替 DDL メソッドを使用する場合と比較して大幅に高速に実行されるだけでなく、変更中のテーブルを排他的にロックすることもありません。インスタント DDL 操作では、 データディクショナリ内のメタデータのみが変更されます。操作の実行フェーズ中に、テーブルの排他的メタデータロックが一時的に取られることがありますが、テーブルデータは影響を受けないため、 操作はほぼ瞬時に完了します。 共通テーブル式 共通テーブル式（CTE） を使用すると、ステートメントのスコープ内で呼び出せる名前の一時的な結果セットを使用できます。CTE を使用することで、 複数のサブクエリを作成する場合や再帰クエリを作成する場合に比べて、より簡潔で読みやすい SQL クエリを作成できます。 また、サブクエリを複数回記述したり、複数回評価したりすることを避けることで、パフォーマンスの向上にもつながります。CTE は WITH 句 を使用して実装されます。 ウィンドウ関数 ウィンドウ関数を使用することで、分析クエリを改善できます。ウィンドウ関数は集計的な操作ですが、結果を 1 行にまとめるわけではありません。連続するウィンドウに対して集計を行い、行ごとに結果を出力します。Aurora MySQL 3 では、 RANK() 、 DENSE_RANK() 、 NTILE() 、 ROW_NUMBER() などのウィンドウ関数をサポートしています。詳細は こちら をご覧ください。 パラレルクエリのサポートの改善 パラレルクエリは、Aurora MySQL 固有の機能で、 クエリ処理を Aurora の専用分散ストレージ層に分散して並列化することで、特定の種類のクエリのパフォーマンスを向上させることができます。 パラレルクエリの恩恵を受けられるクエリの例として、次のコードに示すように WHERE 句を使用する単純なカウント操作があります。 mysql> explain select count(*) from part where p_partkey > 10 ; +----+...+----------+------------------------------------------+ | id |...| rows     | Extra                                                                      | +----+...+----------+------------------------------------------+ |  1 |...| 20427936 | Using where ; Using parallel query (1 columns, 1 filters, 0 exprs ; 0 extra) | +----+...+----------+------------------------------------------+ Aurora MySQL 3 では、 パーティショニングテーブル 、集計、HAVING 句、BLOB に対する Aurora パラレルクエリのサポートが追加されました。このサポートにより、集計、パーティション分割テーブル、TEXT、JSON、CHAR、769 バイトを超える VARCHAR などの BLOB データ型を使用するテーブルを利用するクエリで、パラレルクエリのパフォーマンスを最適化できます。 新しいインデックスタイプ Aurora MySQL 3 では、降順インデックスと非表示インデックスがサポートされるようになりました。 降順インデックス は、 インデックスを降順にソートして取得する必要があるクエリのパフォーマンスが向上します 。 非表示インデックス を使用すると、 実際にインデックスを削除しなくても、インデックスを削除することによるパフォーマンスへの影響をテストできます。 この機能を使用して、未使用のインデックスを特定し、スキーマを最適化することができます。 ロール 権限の名前付きコレクションとして機能するロールを作成できるようになりました 。ロールを作成および削除したり、ロールに対して権限を付与および取り消すことができます。ユーザーアカウントからロールを付与および取り消すこともできます。 Aurora MySQL の以前のバージョンでは、権限を直接付与できるのは個々のユーザーアカウントのみでした。これにより、ユーザーグループへの権限の付与と取り消しが効率化され、ユーザー管理全体が簡素化されます。詳細については、 Using Roles を参照してください。 Amazon RDS for MySQL 5.7/8.0 から Aurora MySQL 3 へのサポートされる移行パス Amazon Relational Database Service (Amazon RDS) for MySQL から Aurora MySQL 3 への移行を検討している場合、次の移行パスが利用できます: スナップショットの復元 – MySQL 8.0 (MySQL バージョン 8.0.23 以下) のスナップショットから Aurora MySQL 3 への復元ができます。プロセスは Aurora のアップグレードセクションで説明したものと同じです。  リードレプリカの移行 – Amazon RDS for MySQL 8.0 プライマリ DB インスタンス (MySQL バージョン 8.0.23 以下) から、Aurora MySQL 3 リードレプリカ DB クラスタを作成できます。このプロセスでは自動的に、MySQL DB インスタンスからすべてのデータを含む Aurora MySQL 3 DB クラスタが作成され、Amazon RDS for MySQL ソースから Aurora MySQL ターゲットへのバイナリログレプリケーションが設定されます。リードレプリカ DB クラスタが作成され、すべての変更をキャッチアップした後 (レプリケーションが実行されており、レプリカのラグがゼロであることを確認)、スタンドアロンのプライマリ DB クラスタに昇格させて、 読み取りと書き込みを 受け入れることができます。  これらの方法は、Amazon RDS for MySQL 8.0 からの移行にのみ適用できます。Amazon RDS for MySQL 5.7 から Aurora MySQL 3 への移行にはこの方法を使用できません。 Amazon RDS for MySQL 5.7 から Aurora MySQL 3 への移行は、 2 段階のプロセスになります 。まず、Amazon RDS for MySQL 5.7 DB インスタンスを Amazon RDS for MySQL 8.0 にアップグレードする必要があります。その後、上記で説明した 2 つの移行方法のいずれかを使用します。 他のセルフマネージド MySQL 互換データベースからのサポートされている移行パス 現時点では 、 論理データのエクスポートを実行して新しい Aurora MySQL 3 DB クラスターにインポートすることで、 、セルフマネージド MySQL 互換データベースからの移行ができます。 バイナリログレプリケーションを使用すると、他のアップグレードソースまたは移行ソースの前のセクションで説明したように、ダウンタイムを最小限に抑える移行を実行できます 。 バイナリログレプリケーションの設定は、 Amazon Aurora ユーザーガイド で詳しく説明されています。 この移行は、コミュニティやサードパーティが提供するネイティブな MySQL ツール(mysqldump、mydumper/myloader など)を使用するか、 AWS データベース移行サービス(AWS DMS) を使用することで実行できます。 Aurora MySQL 3 への Aurora MySQL 1 および 2 からの動作変更 Aurora MySQL 3 では、新しい機能に加えて、クエリに対するデータベースの動作や、内部構造の運用や管理方法が変わる可能性のある変更もいくつか導入されています。データベースのアップグレードを検討する前に、アップグレード前の評価を実施して、アップグレード前に対応が必要な 項目 に確実に対処することを強くお勧めします。動作には次のような重要な変更点があります。変更の完全なリストについては、 MySQL 8.0 の変更点 を参照してください。 TempTable ストレージエンジン MySQL 8.0 では、複雑なクエリを処理する際にデータベースエンジンが内部的に一時テーブルを作成するのに使用される新しい TempTable ストレージエンジンがデフォルトとして導入されました。Aurora MySQL 3 でも、TempTable ストレージエンジンをデフォルトとして導入しています。 TempTable は、内部テンポラリテーブルを格納するために一定量のメモリを割り当てるだけでなく、メモリに収まらない大きなデータセットを、メモリマップファイル、InnoDB ストレージエンジンのいずれかに流出させたり、カスケードしてメモリマップファイルや InnoDB ストレージエンジンに流出させたり、両方にカスケードしたりすることがあります。Aurora MySQL の場合は共有ストレージアーキテクチャを使用するため、InnoDB テーブルはクラスタのリーダー DB インスタンスで読み取り専用モードでのみアクセスできます。その結果、リーダー DB インスタンスは内部一時テーブルにメモリマップドファイルのみを使用でき、DB インスタンスクラスに対応する割り当てられた一時ストレージスペースの量に限定されます。Aurora MySQL 3 DB クラスターのライター DB インスタンスは、メモリマップファイルと InnoDB ストレージのいずれかまたは両方を使用するように設定できます。 TempTable エンジンは、VARCHAR、VARBINARY、およびその他の BLOB データ型をより効率的に格納できます。固定長の行形式を使用していた MEMORY ストレージエンジンと比較して、TempTable ストレージエンジンは VARCHAR、VARBINARY、その他の BLOB 列を、可変長のセル配列を使用して格納します データディクショナリの変更 Aurora MySQL 3 は、データディクショナリ(メタデータ)の保持方法が変更されました。以前のバージョンでは、データディクショナリは非リレーショナルなメタデータファイル(FRM、TRN、TRG、OPT ファイルなど)を使用して保持されていましたが、現在はデータディクショナリはトランザクションスキーマに格納 されるようになりました。 この新しい実装には、クラッシュセーフなデータディレクトリスキーマ、 一元化されたメタデータによる簡潔さ 、ディクショナリオブジェクトの 統一 キャッシング、 アトミック DDL など、いくつかのメリットがあります。新しい実装のメリットの完全なリストについては、 MySQL データディクショナリ を参照してください。 エラーコードの削除 いくつかのエラーコードが削除されました。アプリケーションでエラー処理に MySQL の特定のエラーコードを使用している場合は、アプリケーションに適切な変更を加える必要があります。詳細は、 MySQL 8.0 で削除された機能 をご覧ください。 GROUP BY の ASC/DESC 句 GROUP BY 句で ASC または DESC 修飾子を使用しているクエリの場合、これらは Aurora MySQL のこのバージョンで削除されているため、機能しなくなります。 GROUP BY で ASC または DESC 修飾子を使用したクエリの結果を並べ替える必要がある場合は、代わりに ORDER BY 句で ASC または DESC 修飾子を使用するようにクエリを変更する必要があります。 Aurora MySQL のメジャーバージョンの選択方法 Aurora MySQL のメジャーバージョンの選択は、 主に特定の アプリケーションの互換性要件、新しいメジャーバージョンのテストのためのリソース、必要な機能へのアクセス可否に大きく依存します。 ワークロードを将来にわたって利用できるようにし、最新機能にアクセスすることを優先する場合は、Aurora MySQL 3 (MySQL 8.0 互換) を検討する必要があります。 同様に、バージョン 3 で実行することで、Aurora DB インスタンスクラスの形式で最新のハードウェアにアクセス できるようになります。また、新しいワークロードを作成していて、レガシーコードがない場合は、最新バージョンの Aurora MySQL の使用を検討する必要があります。 Aurora MySQL チームは、まずバージョン 3 プラットフォームでの新機能の開発とリリースに注力します。 Aurora MySQL 3 の長期サポート (LTS) バージョンもリリースされています。このバージョンでは、ソフトウェアの更新がセキュリティとバグ修正に限定され、新機能によるワークロードの動作の変化のリスクがないことが保証されます。 これは、 バージョンポリシー (各メジャーバージョンの Aurora MySQL に 1 つの LTS バージョン)に沿ったものです。 まとめ この投稿では、MySQL 8.0 エンジン互換性を備えた新しい Aurora MySQL 3 の一般提供可能性について説明しました。新しくエキサイティングな機能のサポート、動作の変更、アップグレードと移行オプション、マイナーバージョン互換性の観点での考え方の変化について説明しました。 新プラットフォームのすべての機能とメリットを活用していただけることを楽しみにしています。 すぐに MySQL 8.0 との互換性がある新しい Aurora MySQL 3 データベースクラスターを起動 をお試しください。 著者について Aditya Samant   は、AWS のデータベースを専門とするソリューションアーキテクトです。AWS のお客様が最先端のクラウドテクノロジーを活用した、スケーラブルで安全で堅牢なアーキテクチャを 設計できるよう支援しています。プライベートではレトロな PC テクノロジーを楽しんだり、コンピューターゲームをしたり、家族や友人と時間を過ごしたりしています。 Vlad Vlasceanu は、AWS のスペシャリストソリューションアーキテクトです。彼はお客様と協力してデータベースプロジェクトに関するガイダンスや技術支援を行い、お客様が AWS を使用する際のソリューションの価値向上を支援しています。

先月、 2024 年のサプライチェーンについての予測ブログ を共有しました。 このブログでは、複数のシステムに分散したデータを統合データモデルにまとめる必要性について詳しく説明します。 サプライチェーンのリーダー達は、広大なグローバルネットワークと顧客の期待の高まりにより、ますます複雑化に直面しています。 顧客がより多くの品揃え、持続可能性の向上、商品やサービスのオンデマンドデリバリーを求めた結果、サプライチェーン管理は戦略的な差別化要因に変わってきています。 デジタルサプライチェーン は、可視性やレジリエンス、スピードや俊敏性の向上といった、運用上のメリットをもたらします。 ただし、その可能性を最大限に引き出すには、分断されたシステムに分散した断片化されたデータから価値を抽出する必要があります。 データはイノベーションを促進する新しい経験と洞察を促進しますが、組織全体で価値を引き出すデータ戦略を構築することは簡単ではありません。 また、サプライチェーンチームは、手作業によるレポート作成、スプレッドシート、複雑なデータ操作といった負担をなくし、セルフサービスでデータにアクセスしたいと考えています。 さまざまなデータセットが企業全体や、さらにそれを超えて取引先のシステムまで分散しているため、データシステムは広範囲に拡がり、サイロ化し、複雑化しています。 そのため、サプライチェーンチームはデータをつなぎ合わせるのに長い時間を費やし、データモデルが変更された場合はこのプロセスをやりなおさなければならず、永久に続く手作業のサイクルを作り出しています。 エンドツーエンドの可視性を実現し、有意義な洞察を得るには、さまざまなソースにわたるデータを統合して調和させる必要があります。イノベーションを加速し、将来の混乱に備え、顧客のニーズを満たすために、 組織はサプライチェーン全体でのデータの活用方法を全面的に見直す必要があります。 最高サプライチェーン責任者（CSO）、サプライチェーンの責任者、その他のサプライチェーンのリーダーは、強力なデジタル基盤、AI、高度なアナリティクスを可能にする統一データモデルの必要性を認識しています。 データを手動で集計して正規化するプロセスは複雑で時間がかかり、エラーも起こりがちです。 また、多くの組織では、カスタムデータ統合作業に必要な社内スキルやリソースが不足しています。 このブログでは、組織全体のサプライチェーンデータを一元的に把握することで、エンドツーエンドのプロセスの可視性を向上させ、俊敏性を高め、レジリエンスを向上させ、運用コストを削減し、全体的な持続可能性リスクを軽減する、唯一の信頼できる情報源をどのように提供するかを概説します。 また、組織が計画を最適化し効率を向上させ、顧客の要求を上回れるようにするための統合データ基盤を AWS Supply Chain がどのように提供するかについても説明します。 AWS Supply Chain データレイク AWS Supply Chain は、サプライチェーンデータレイク (SCDL) による統合データ管理を提供します。これにより、エンドツーエンドの可視性、より正確な需要予測、サプライチェーンの耐障害性を実現します。 SCDL は、断片化されたシステムをまたがってデータを取得し、標準化し、統合するための機能を標準で提供する、柔軟でスケーラブルなデータインフラストラクチャです。 サプライチェーンデータを集約して高品質で統一されたデータ資産に関連付けることで、組織は企業の集合知を活用できるようになります。 これにより、組織は新しいテクノロジーを探求しながら、既存のプロセスを最適化することができます。 また、SCDL は予測精度の向上、過剰在庫の削減、サイクルタイムの短縮を可能にします。 データに基づく洞察により、レガシーシステムの機能が強化され、長期的なモダナイゼーションを容易にします。 専用のコネクタにより、エンタープライズリソースプランニング（ERP）、倉庫管理システム（WMS）、注文管理システム（OMS）、輸送管理システム（TMS）、調達システム、フラットファイル、データベースなど、一般的なサプライチェーンのデータソースとデータフォーマットを迅速に取り込むことができます。 SCDL はまた、機械学習（ML）と自然言語処理を活用して非構造化データを解析し、サプライチェーンのコンテキストを理解します。この ML アルゴリズムは、一般的なサプライチェーンのデータ構造と関係について事前にトレーニングされています。 これにより、一般的なデータレイクツールと比較して、より正確なエンティティ認識とマッピングが可能になります。 SCDL は、 Amazon QuickSight , Amazon SageMaker , AWS Glue , AWS Glue DataBrew などの分析およびデータサイエンスツールと統合されています。 標準化されていないデータを変換するための AWS サービスの利用方法については、以前の ブログ をご覧ください。 データ変換の高速化により、データチームは影響の大きいモデルをより迅速に提供し、ETL (抽出、変換、読み込み) 操作を簡素化できます。 IoT や機械学習等の技術の進歩により、SDCL は分析基盤としても機能し、サプライチェーンデータ基盤を将来も使い続けられるようにします。 AWS は、 zero-ETL の未来に向けた投資を行い、お客様が新しい洞察を発見し、より早くイノベーションを行い、より良いデータ主導の意思決定を行えるようサポートしています。 複雑な ETL やデータモデリングに費やす時間をなくすことで、統合データが脆弱性やボトルネックを解決するような、価値の高いユースケースを迅速に採用できます。 SCDL は、エンドツーエンドの可視性を高め、データ主導の洞察を引き出すための信頼できる唯一の情報源を提供します。 SCDL は AWS Supply Chain のモジュールの基盤となり、在庫の可視性を高め、在庫やリードタイムのリスクを軽減するための ML に基づく推奨事項により包括的なビューを提供します。 Demand Planning では、Amazon のサプライチェーンの専門知識と ML を組み合わせて、過去と現在の販売データを分析し、予測情報を作成し、精度を高めるためにモデルを継続的に改良します。傾向と異常を分析し、混乱を予測し、問題が発生したときに優先順位を付けるために ML を使用することで、組織はレジリエンスを高めることができます。アナリストは、データの処理に費やす時間が少なくなり、ビジネス判断にインサイトを適用する時間が増えます。AWS Supply Chain を使用すると、状況認識力を高め、計画を最適化し、需要に対応した供給を行い、変化するビジネスニーズに対するデータの整合性を向上できます。 今年後半には、Amazon Q in AWS Supply Chain をリリースする予定です。これは、 Amazon Bedrock を搭載した生成 AI アシスタントで、サプライチェーン管理の生産性を向上させます。 Amazon Q in AWS Supply Chain は、需要変動、在庫状況、ベンダーのリードタイムの不確実性に関する重要な質問に回答する自然言語インターフェイスを提供します。 SCDL に格納されたデータを問い合わせ、「何が」「なぜ」といった質問に対するデータ主導の回答を得ることができます。 Amazon Q in AWS Supply Chain は業務用に特化して設計されており、使用する組織の SCDL に合わせてカスタマイズされます。 まとめ イノベーションのペースと顧客需要は世界的に加速しています。 組織は、競争力を維持するために必要な可視性、スピード、およびレジリエンスを実現するために、集合的なデータインテリジェンスを活用する必要があります。データは、AI/ML の潜在能力を引き出すデジタルトランスフォーメーションの基盤であり原動力です。 SCDL は、分断されたサプライチェーンデータを広く活用できる高品質な資産に迅速に統合するための専用機能を提供します。 これにより、予測からサプライチェーンのデジタル化まで、データ主導のイノベーションが促進されます。 AWS Supply Chain は、既存のサプライチェーンのデータ投資から価値を引き出すための迅速かつ簡単な方法を提供します。主な利点は次のとおりです。 事前構築済みのデータコネクタにより、価値創出までの時間を短縮。 手動による複雑なデータ統合を最小限に抑えることでコストを削減。 集計分析により、在庫状態の可視性を向上。 データに基づく洞察によるサプライチェーンのレジリエンスの向上。 予測精度の向上と在庫コストの削減。 サプライチェーン専用の機能により、イノベーションサイクルを短縮。 AWS Supply Chain の Web サイトを閲覧いただき、サプライチェーンデータを迅速かつ大規模に活用する方法の詳細について確認ください。 セルフペースで学べる技術概要については、 AWS Workshops をご覧ください。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 <!-- '"` --> 著者について Diego Pantoja-Navajas は AWS Supply Chain の Vice President で、ビジネスアプリケーションのビジョンの策定と実現を担当しています。彼と彼のチームは、サプライチェーンの機能を根本的に考え直し、世界で初めての継続的に改善するサプライチェーン管理システムを市場に提供することに注力しています。彼は顧客の成功に情熱を注ぎ、SaaS、クラウド、AI/ML テクノロジーを活用して、サプライチェーン、e コマース、フルフィルメントに関連するビジネスの問題を解決するための高度に使いやすく知的な B2B エンタープライズソフトウェアソリューションを構築しています。Diego はジョージア工科大学の優等卒業生で、MIT の人工知能・機械学習のエグゼクティブエデュケーションコースを修了しています。また、IESE ビジネススクール、ミシガン大学ロス・ビジネススクールとのパートナーシップのもと、リーダーシップコースにも参加しています。彼は南フロリダに家族と暮らしており、顧客のビジネスの成功をさらに推進する革新的な製品やソリューションを学ぶことを常に喜んでいます。

大規模言語モデル (LLM) をデプロイする場合、機械学習 (ML) の担当者は通常、モデルサービングのパフォーマンスの 2 つの測定値に注目します。1 つ目は 1 トークンの生成にかかる時間で定義されるレイテンシー、二つ目は 1 秒あたりに生成されるトークンの数によって定義されるスループットです。デプロイされたエンドポイントへの単一のリクエストは、モデルレイテンシーの逆数とほぼ同じスループットを示しますが、複数の同時リクエストがエンドポイントに同時に送信される場合は必ずしもそうではありません。クライアント側で同時リクエストを連続的なバッチとして処理するなどのモデルサービング手法により、レイテンシーとスループットの複雑な関係は、モデルアーキテクチャ、サービス構成、インスタンスタイプによるハードウェア、同時リクエスト数、入力トークンや出力トークンの数などの入力ペイロードのバリエーションによって大きく異なります。 この投稿では、Amazon SageMaker JumpStart で利用可能な LLM (Llama 2、Falcon、Mistral の各バリアントを含む) の包括的なベンチマークを通じて、これらの関係を探ります。SageMaker JumpStart を使用すると、ML の担当者は広く公開されているさまざまな基盤モデルから選択して、ネットワークから隔離された環境内の専用の Amazon SageMaker インスタンスにデプロイできます。それらを活用して、アクセラレータ仕様が LLM ベンチマークにどのように影響するかについての理論的な原則について述べます。また、1 つのエンドポイントの背後に複数のインスタンスをデプロイすることによる影響についても説明します。最後に、レイテンシー、スループット、コスト、および利用可能なインスタンスタイプの制約に関する要件に合わせて SageMaker JumpStart のデプロイプロセスを調整するための実践的な推奨事項を示します。ベンチマークの結果と推奨事項はすべて、ユースケースに合わせて調整できる汎用性の高い ノートブック に基づいています。 デプロイされたエンドポイントのベンチマーク 次の図は、さまざまなモデルタイプとインスタンスタイプにわたるデプロイ設定の最小レイテンシー（左）と最高スループット（右）を示しています。このベンチマークでは、デプロイ時にSageMaker JumpStartの提供するデフォルト設定を活用しています。これにより、モデルのデプロイに際して、各モデルにとって最適なモデルIDとインスタンスタイプが自動的に設定されます。 これらのレイテンシーとスループットの値は、256 個の入力トークンと 256 個の出力トークンのペイロードに対応します。レイテンシーが最も低い構成では、処理できるモデルは同時リクエストが 1 つに制限され、スループットが最も高い構成では、同時リクエストの数が最大化されます。（訳注：つまりこの二つのグラフは同一のリクエスト設定のもとで測定されたものではないことに注意してください）ベンチマークでわかるように、同時リクエストを増やすとスループットが単調に向上しますが、大量の同時リクエストの改善は弱まります。さらに、サポート対象のインスタンスではモデルが完全にシャーディングされます。たとえば、ml.g5.48xlarge インスタンスには 8 つの GPU があるため、このインスタンスを使用するすべての SageMaker JumpStart モデルは、使用可能な 8 つのアクセラレータすべてでテンソル並列処理を使用してシャーディングされます。 この図からいくつかのポイントがわかります。まず、すべてのモデルがすべてのインスタンスでサポートされているわけではありません。Falcon 7B などの一部の小規模モデルはモデルシャーディングをサポートしていませんが、大規模モデルではコンピューティングリソース要件が高くなります。2 つ目は、シャーディングが増えるほどパフォーマンスは一般的に向上しますが、小規模なモデルでは必ずしも向上するとは限りません。これは、7B や 13B のような小さなモデルでは、あまりにも多くのアクセラレータでシャードすると、通信オーバーヘッドが大きくなるためです。これについては後で詳しく説明します。最後に、A10G GPU よりも A100 GPUの方がメモリ帯域が改善されているため、ml.p4d.24xlarge インスタンスのほうがスループットが大幅に向上する傾向があります。後で説明するように、特定のインスタンスタイプを使用するかどうかは、レイテンシー、スループット、コスト制約などのデプロイ要件によって異なります。 これらの最小のレイテンシーと最高のスループットの設定値を得るにはどうすればよいでしょうか?まず、次の曲線に示すように、256 個の入力トークンと 256 個の出力トークンを含むペイロードの ml.g5.12xlarge インスタンス上の Llama 2 7B エンドポイントのレイテンシーとスループットをプロットすることから始めましょう。デプロイされた他のすべての LLM エンドポイントでも同様のプロットが可能です。 同時実行が増えると、スループットとレイテンシーも単調に増加します。したがって、同時リクエスト値が 1 のときにレイテンシーが最も低く抑えることができ、逆に同時リクエストを増やすことでシステムスループットをコスト効率よく向上させることができます。この曲線には明確な変化点 (“knee”)があり、この変化点の左側では、レイテンシーの増加を影響を受けずに同時実行数の増加によるスループットの向上が期待できます。（訳者注：この変化点を超えると曲線の立ち上がりが顕著になるため、同時実行数の増加がレイテンシーの増加に大きく影響します）。この変化点の場所をどこと捉えるかはユースケースに依存します。事前に指定されたレイテンシー要件（たとえば、100 ミリ秒/トークン）を超えた時点で変化点を定義するケースもあれば、half-latency ruleなどの負荷テストのベンチマークやキューイング理論の手法を適用するケースもあり、さらには理論上のアクセラレータ仕様を使用するケースもあります。 また、同時リクエストの最大数には制限があることにも注意してください。上の図では、プロットは 192 件の同時リクエストで終了しています。この制限の原因は、SageMaker エンドポイントが60 秒後に呼び出し応答をタイムアウトすることです。この設定はアカウント固有で、個々のエンドポイントでは設定できません。LLM では、大量の出力トークンを生成するのに数秒から数分かかることがあります。そのため、入力または出力のペイロードが大きいと、呼び出しリクエストが失敗する可能性があります。さらに、同時リクエストの数が非常に多いと、多くのリクエストでキュー時間が長くなり、この 60 秒のタイムアウト制限が発生します。この調査では、タイムアウト制限下で可能なリクエストにおいて最大スループットを定義しました。重要なのは、SageMaker エンドポイントが呼び出し応答のタイムアウトを観察せずに多数の同時リクエストを処理する場合もあるかもしれないが、レイテンシー-スループット曲線の変化点を基準にして最大同時リクエスト数を定義したい場合があるということです。この時点で、水平スケーリングを検討し始める可能性があります。水平スケーリングとは、単一のエンドポイントが複数のインスタンスにモデルレプリカをプロビジョニングし、受信リクエストをレプリカ間で負荷分散して、より多くの同時リクエストをサポートすることです。 さらに一歩進んで、次の表には、入出力トークンの数、インスタンスタイプ、同時リクエスト数など、Llama 2 7Bモデルのさまざまな構成のベンチマーク結果が含まれています。上の図では、この表の 1 行だけがプロットされていることに注意してください。 Throughput (tokens/sec) Latency (ms/token) Concurrent Requests 1 2 4 8 16 32 64 128 256 512 1 2 4 8 16 32 64 128 256 512 Number of total tokens: 512,&nbsp; &nbsp; Number of output tokens: 256 ml.g5.2xlarge 30 54 115 208 343 475 486 — — — 33 33 35 39 48 97 159 — — — ml.g5.12xlarge 59 117 223 406 616 866 1098 1214 — — 17 17 18 20 27 38 60 112 — — ml.g5.48xlarge 56 108 202 366 522 660 707 804 — — 18 18 19 22 32 50 101 171 — — ml.p4d.24xlarge 49 85 178 353 654 1079 1544 2312 2905 2944 21 23 22 23 26 31 44 58 92 165 Number of total tokens: 4096,&nbsp; &nbsp; Number of output tokens: 256 ml.g5.2xlarge 20 36 48 49 — — — — — — 48 57 104 170 — — — — — — ml.g5.12xlarge 33 58 90 123 142 — — — — — 31 34 48 73 132 — — — — — ml.g5.48xlarge 31 48 66 82 — — — — — — 31 43 68 120 — — — — — — ml.p4d.24xlarge 39 73 124 202 278 290 — — — — 26 27 33 43 66 107 — — — — このデータには、他にもいくつかのパターンが見られます。コンテキストのサイズが大きくなると、レイテンシーが増加し、スループットが低下します。たとえば、同時実行数が 1 の ml.g5.2xlarge では、合計トークン数が 512 の場合、スループットは 30 トークン/秒ですが、トークンの総数が 4,096 の場合は 20 トークン/秒です。これは、入力が大きいほど処理に時間がかかるためです。また、GPU の能力とシャーディングを増やすと、最大スループットとサポートされる同時リクエストの最大数に影響することもわかります。この表から、Llama 2 7B はインスタンスタイプごとに最大スループット値が著しく異なり、これらの最大スループット値は同時リクエストの値が異なる場合に発生することがわかります。このような特徴から、ML 実践者は、あるインスタンスのコストを別のインスタンスよりも正当化したいと思うでしょう。たとえば、低レイテンシー要件の場合、実践者は ml.g5.2xlarge インスタンス（1 つの A10G GPU）よりも ml.g5.12xlarge インスタンス（4 つの A10G GPU）を選択するかもしれません。高いスループット要件がある場合、フルシャーディング機能を備えた ml.p4d.24xlarge インスタンス (8 個の A100 GPU) の使用は、同時実行性が高い場合にのみ正当化されます。ただし、7B モデルの複数の推論コンポーネントを 1 つの ml.p4d.24xlarge インスタンスにロードすることが、しばしば有益であることに注意してください。このようなマルチモデルのサポートについては、この記事の後半で説明します。 前述の観察は、Llama2 7Bモデルについて行われました。ただし、他のモデルにも同様のパターンが当てはまります。主なポイントは、レイテンシーとスループットのパフォーマンスの数値はペイロード、インスタンスタイプ、同時リクエストの数に依存するため、特定のアプリケーションに最適な構成を見つける必要があるということです。ユースケースに合わせて前述の数値を生成するには、リンクされた ノートブック を実行して、モデル、インスタンスタイプ、およびペイロードに合わせてこの負荷テスト分析を設定できます。 アクセラレータの仕様を理解する LLM 推論に適したハードウェアの選択は、特定のユースケース、ユーザーエクスペリエンスの目標、選択した LLM に大きく依存します。この節では、アクセラレータ仕様に基づく大まかな原則を基準として、レイテンシーとスループット曲線の変化点を理解することを目指しています。これらの原則だけで意思決定をおこなうには不十分であり、実際のベンチマークが必要です。ここでは、デバイスという用語はすべての ML ハードウェアアクセラレータを示しています。我々は、レイテンシースループット曲線は、次の 2 つの要因のうちの 1 つによって決まると断言します。 アクセラレータが KV (訳註: TransformerアーキテクチャのKeyとValue) マトリックスをキャッシュするためにメモリを使い果たしたため、以降のリクエストはキューに入れられます。（この場合はメモリが計算のボトルネックになりmemory バウンドと呼ばれます） アクセラレータには KV キャッシュ用の空きメモリがまだありますが、十分なバッチサイズを使用しているため、処理時間はメモリ帯域幅ではなく計算処理のレイテンシーによって決まります。（訳注：この場合はcompute バウンドと呼ばれます） 2番目の要素はアクセラレータのリソースが飽和状態になっているため、一般的には 2 番目の要素による制限が好まれます。基本的に、支払ったリソースを最大限に活用していることになるからです。さらに詳しく見ていきましょう。 KV キャッシュとデバイスメモリ 標準的な transformer の attention メカニズムは、新しいトークンごとに以前のすべてのトークンに対して attention を計算します。最新の ML サーバー（訳者注: LLM の推論機能を提供しているフレームワーク）のほとんどは、attention の key と value をデバイスメモリ (DRAM) にキャッシュして、各ステップで再計算されないようにします。これは KV キャッシュと呼ばれ、バッチサイズやシーケンスの長さとともに大きくなります。これにより、並行して処理できるユーザリクエストの数が定義されます。使用可能な DRAM が利用可能であることから前述の 2 番目のシナリオの compute バウンドレジームがまだ満たされていない場合には、レイテンシー・スループット曲線のどの程度が優先されるかが決まります。次の式は、KV キャッシュの最大サイズの大まかな概算です。 この式では、B はバッチサイズ、N はアクセラレータの数です。たとえば、A10G GPU (24 GB DRAM) 上で動作する FP16 の Llama 2 7B モデル (2 バイト/パラメーター) は、約 14 GB を消費しますが、残りの 10 GB は KV キャッシュ用です。モデルの全コンテキスト長 (N = 4096) と残りのパラメーター (n_layers=32、n_kv_attention_heads=32、d_attention_head=128) を差し込むと、この式は DRAM の制約により、同時に処理できるバッチサイズが 4 ユーザーに制限されていることがわかります。前の表の対応するベンチマークを観察すると、このレイテンシ・スループット曲線で観測された変化点の近似値が適切であることがわかります。 グループ化されたクエリアテンション (GQA) などの方法では KV キャッシュサイズを減らすことができます。GQA の場合は、KV ヘッドの数を減らすのと同じ係数で KV キャッシュサイズを減らすことができます。 算術強度とデバイスメモリ帯域幅 ML アクセラレータの計算能力の増大は、メモリ帯域幅を上回っています。そのため、データの 1 バイトにアクセスするのにかかる時間に対して、はるかに多くの計算をおこなうことができます。 演算の算術強度、つまり計算処理とメモリアクセスの比率によって、選択したハードウェアのメモリ帯域幅または計算能力のどちらによって制限されるかが決まります。たとえば、FP16 で 70 TFLOPS、メモリ帯域幅が 600 GB/秒の A10G GPU (g5 インスタンスタイプファミリー) では、約 116 オペレーション/バイトを計算できます。A100 GPU (p4d インスタンスタイプファミリー) は、約 208 オペレーション/バイトを計算できます。transformer モデルの算術強度がその値を下回る場合はメモリに制限され、それを上回ると計算量に制限されます。Llama 2 7B のアテンションメカニズムは、バッチサイズ 1 でバイトあたり 62 オペレーションを必要とします (説明については、 LLM 推論とパフォーマンスのガイド を参照してください)。つまり、メモリに制約があるということです。アテンションメカニズムがメモリーに制約されている場合、高価な FLOPS は未使用のままになります。 アクセラレータをより有効に活用して算術強度を上げるには、操作に必要なメモリアクセスを減らす方法（ FlashAttenttion が注目している点）とバッチサイズを増やす方法の2つがあります。ただし、DRAM が小さすぎて対応する KV キャッシュを保持できない場合、バッチサイズを十分に増やすことができないため、compute バウンド領域に達することができない場合があります。標準的な GPT デコーダーによる推論のcompute バウンド領域とmemory バウンド領域を区別するクリティカルバッチサイズ B* の大まかな概算は、次の式で表されます。ここで、A_mb はアクセラレータのメモリ帯域幅、A_f はアクセラレータ FLOPS、N はアクセラレータの数です。この重要なバッチサイズは、メモリアクセス時間が計算時間と等しい場所を見つけることで導き出すことができます。この ブログ記事 を参照して、式 2 とその前提条件をより詳しく理解してください。 これは、以前にA10Gで計算したのと同じオペレーション/バイト比なので、この GPU のクリティカルバッチサイズは 116 です。この理論上重要なバッチサイズにアプローチする方法の 1 つは、モデルのシャーディングを増やし、キャッシュを N 個のアクセラレータに分割することです。これにより、KV キャッシュ容量だけでなく、メモリー制限のあるバッチサイズも効果的に増加します。 モデルシャーディングのもう 1 つの利点は、モデルパラメーターとデータの読み込み作業を N 個のアクセラレーターに分割できることです。このタイプのシャーディングは、テンソル並列処理とも呼ばれるモデル並列処理の一種です。単純に、メモリ帯域幅と計算能力は合計で N 倍になります。どのような種類のオーバーヘッド (通信、ソフトウェアなど) もないと仮定すると、メモリに制約がある場合はトークンあたりのデコード待ち時間が 1/N に減ります。これは、この領域におけるトークンのデコード待ち時間は、モデルの重みとキャッシュを読み込むのにかかる時間によって制限されるためです。しかし実際には、シャーディングの度合いを上げると、デバイス間の通信が増加し、すべてのモデルレイヤーで中間アクティベーションを共有するようになります。この通信速度は、デバイス相互接続の帯域幅によって制限されます。その影響を正確に推定することは困難ですが (詳細は モデルの並列処理 を参照)、最終的にはメリットが得られなくなったり、パフォーマンスが低下したりする可能性があります。これは、データ転送が小さいほど転送速度が遅くなるため、特に小規模なモデルに当てはまります。 ML アクセラレータを仕様に基づいて比較するには、以下をお勧めします。まず、式 2 に従って各アクセラレータタイプのおおよそのクリティカルバッチサイズを計算し、式 1 に従ってクリティカルバッチサイズの KV キャッシュサイズを計算します。その後、アクセラレータで使用可能な DRAM を使用して、KV キャッシュとモデルパラメータに適合するのに必要なアクセラレータの最小数を計算できます。複数のアクセラレータを選択する場合は、メモリ帯域幅 1 GB/秒あたりのコストが最も低い順にアクセラレータを優先します。最後に、これらの構成をベンチマークし、希望するレイテンシーの上限に対して最適なコスト/トークンを検証します。 エンドポイントのデプロイ設定を選択する SageMaker JumpStart によって配布されている多くの LLM は、モデルのサービングに text-generation-inference (TGI) の SageMaker コンテナ を使用しています。次の表は、レイテンシー・スループット曲線に影響するモデル・サービングに対応するように、またはエンドポイントに過負荷をかけるリクエストからエンドポイントを保護するために、さまざまなモデル・サービング・パラメーターを調整する方法を示しています。これらは、ユースケースに合わせてエンドポイントのデプロイメントを設定するために使用できる主なパラメーターです。特に指定がない限り、デフォルトの text generation payload パラメータと TGI 環境変数 を使用します。 Environment Variable Description SageMaker JumpStart Default Value Model serving configurations MAX_BATCH_PREFILL_TOKENS 事前入力 (prefill) 操作のトークンの数を制限します。この操作は、新しい入力プロンプトシーケンスの KV キャッシュを生成します。これはメモリを大量に消費し、計算量も限られるため、この値によって 1 回の事前入力操作で許可されるトークンの数が制限されます。プレフィルの実行中は、他のクエリのデコードステップが一時停止します。 4096 (TGI デフォルト) またはモデル固有のサポートされるコンテキストの最大長 (SageMaker JumpStart 提供) のいずれか大きい方。 MAX_BATCH_TOTAL_TOKENS デコード中にバッチに含めるトークンの最大数、またはモデルを推論する回数を制御します。理想的には、使用可能なすべてのハードウェアの使用率を最大化するように設定してください。 指定なし (TGI デフォルト)。TGI は、モデルのウォームアップ中に CUDA メモリの残量を基準にしてこの値を設定します。 SM_NUM_GPUS 使用するシャードの数。つまり、テンソル並列処理を使用してモデルを実行するために使用される GPU の数です。 インスタンスによって異なります (SageMaker JumpStart 提供)。特定のモデルでサポートされている各インスタンスについて、SageMaker JumpStart はテンソル並列処理に最適な設定を提供します。 Configurations to guard your endpoint (set these for your use case) MAX_TOTAL_TOKENS これにより、入力シーケンスのトークン数と出力シーケンスのトークンの数 ( max_new_tokens ペイロードパラメーター) の合計が制限され、1 つのクライアントリクエストのメモリバジェットが制限されます。 モデル固有のサポートされるコンテキストの最大長。たとえば、Llama 2の場合は4096です。 MAX_INPUT_LENGTH 1 つのクライアントリクエストの入力シーケンスで許可されるトークンの最大数を識別します。この値を増やす際に考慮すべき点としては、入力シーケンスが長くなるとメモリが必要になり、連続バッチ処理に影響します。また、多くのモデルがサポートしているコンテキストの長さを超えないようにしてください。 モデル固有のサポートされるコンテキストの最大長。たとえば、Llama 2 の場合は 4095 です。 MAX_CONCURRENT_REQUESTS The maximum number of concurrent requests allowed by the deployed endpoint. New requests beyond this limit will immediately raise a model overloaded error to prevent poor latency for the current processing requests. 128 (TGI デフォルト)。この設定により、さまざまなユースケースで高いスループットを得ることができますが、SageMaker 呼び出しのタイムアウトエラーを軽減するために適切なピン設定を行う必要があります。 TGI サーバーは連続バッチ処理を使用します。連続バッチ処理では、同時に発生するリクエストを動的にバッチ処理して 1 つのモデル推論フォワードパスを共有します。フォワードパスには、prefillとdecodeの 2 種類があります。新しいリクエストごとに、prefillフォワードパスを 1 回実行して、入力シーケンストークンの KV キャッシュに入力する必要があります。KV キャッシュにデータが入力されると、decode フォワードパスはバッチ処理されたすべてのリクエストに対して次のトークンの予測を 1 回実行し、これを繰り返し実行して出力シーケンスを生成します。新しいリクエストがサーバーに送信されると、新しいリクエストに対してprefill ステップが実行されるまで、次のdecode ステップを待つ必要があります。この処理は、新しいリクエストが連続的にバッチ処理される後続のdecode ステップに含まれる前に行われなければなりません。ハードウェアの制約により、decode に使用される連続バッチ処理にはすべてのリクエストが含まれない場合があります。この時点で、リクエストは処理キューに入り、スループットの向上はわずかですが、推論レイテンシーは大幅に増加し始めます。 LLM のレイテンシーベンチマーク分析を、prefill レイテンシー、decode レイテンシー、queue レイテンシーに分けることができます。これらの各コンポーネントで消費される時間は本質的に異なります。prefill は 1 回限りの計算で、decode は出力シーケンスのトークンごとに 1 回行われ、queue にはサーバーのバッチ処理が含まれます。複数の同時リクエストが処理されている場合、特定のクライアントリクエストで発生するレイテンシーには、新しい同時リクエストを prefill する必要があることによる queue レイテンシーと、リクエストを batch デコードプロセスに含めることによる queue レイテンシーが含まれるため、これらの各コンポーネントのレイテンシーをそれぞれ算出することが困難になります。そのため、この記事ではエンドツーエンドの処理レイテンシーに焦点を当てています。レイテンシー – スループット曲線で問題となるのは、キューの待ち時間が大幅に増加し始める飽和点です。この現象はどのモデル推論サーバーでも発生し、アクセラレータの仕様によるものです。 デプロイ時の一般的な要件には、最低限必要なスループット、最大許容レイテンシー、1 時間あたりの最大コスト、および 100 万トークンを生成するための最大コストなどが含まれます。これらの要件は、エンドユーザーのリクエストを表すペイロードに条件を付ける必要があります。これらの要件を満たす設計では、特定のモデルアーキテクチャ、モデルのサイズ、インスタンスタイプ、インスタンス数 (水平スケーリング) など、多くの要素を考慮する必要があります。以下のセクションでは、レイテンシーを最小限に抑え、スループットを最大化し、コストを最小限に抑えるためのエンドポイントのデプロイに焦点を当てます。この分析では、合計 512 個のトークンと 256 個の出力トークンを仮定しています。 レイテンシーの最小化 レイテンシーは、多くのリアルタイムユースケースにおいて重要な要件です。次の表では、各モデルと各インスタンスタイプの最小レイテンシーを示しています。 MAX_CONCURRENT_REQUESTS = 1 に設定すると、レイテンシーを最小限に抑えることができます。 Minimum Latency (ms/token) Model ID ml.g5.2xlarge ml.g5.12xlarge ml.g5.48xlarge ml.p4d.24xlarge ml.p4de.24xlarge Llama 2 7B 33 17 18 20 — Llama 2 7B Chat 33 17 18 20 — Llama 2 13B — 22 23 23 — Llama 2 13B Chat — 23 23 23 — Llama 2 70B — — 57 43 — Llama 2 70B Chat — — 57 45 — Mistral 7B 35 — — — — Mistral 7B Instruct 35 — — — — Mixtral 8x7B — — 33 27 — Falcon 7B 33 — — — — Falcon 7B Instruct 33 — — — — Falcon 40B — 53 33 27 — Falcon 40B Instruct — 53 33 28 — Falcon 180B — — — — 42 Falcon 180B Chat — — — — 42 モデルのレイテンシーを最小限に抑えるには、目的のモデル ID とインスタンスタイプを指定して次のコードを使用できす。 from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "1", "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", }, ) predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True レイテンシーの数値は、入力トークンと出力トークンの数によって変化することに注意してください。ただし、環境変数 MAX_INPUT_TOKENS と MAX_TOTAL_TOKENS 以外のデプロイプロセスは同じままです。ここでは、入力シーケンスが大きくなるとレイテンシー要件に違反する可能性があるため、これらの環境変数はエンドポイントのレイテンシー要件を保証するために設定されています。SageMaker JumpStart では、インスタンスタイプを選択する際に他の最適な環境変数がすでに用意されていることに注意してください。たとえば、ml.g5.12xlarge を使用すると、モデル環境で SM_NUM_GPUS が 4 に設定されます。 スループットの最大化 このセクションでは、1 秒あたりに生成されるトークンの数を最大化します。これは通常、モデルとインスタンスタイプに対する有効な同時リクエストの最大数に達したときに達成されます。次の表では、任意のリクエストで SageMaker 呼び出しのタイムアウトが発生する前に達成された最大同時リクエスト値で達成されたスループットを報告しています。 Maximum Throughput (tokens/sec), Concurrent Requests Model ID ml.g5.2xlarge ml.g5.12xlarge ml.g5.48xlarge ml.p4d.24xlarge ml.p4de.24xlarge Llama 2 7B 486 (64) 1214 (128) 804 (128) 2945 (512) — Llama 2 7B Chat 493 (64) 1207 (128) 932 (128) 3012 (512) — Llama 2 13B — 87 (128) 496 (64) 3245 (512) — Llama 2 13B Chat — 782 (128) 505 (64) 3310 (512) — Llama 2 70B — — 124 (16) 1585 (256) — Llama 2 70B Chat — — 114 (16) 1546 (256) — Mistral 7B 947 (64) — — — — Mistral 7B Instruct 986 (128) — — — — Mixtral 8x7B — — 701 (128) 3196 (512) — Falcon 7B 1340 (128) — — — — Falcon 7B Instruct 1313 (128) — — — — Falcon 40B — 244 (32) 382 (64) 2699 (512) — Falcon 40B Instruct — 245 (32) 415 (64) 2675 (512) — Falcon 180B — — — — 1100 (128) Falcon 180B Chat — — — — 1081 (128) モデルのスループットを最大化するには、次のコードを使用できます。 from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "128", # For your application, identify it from the benchmarking table with the maximum feasible concurrent requests. "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", }, ) predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True 同時リクエストの最大数は、モデルタイプ、インスタンスタイプ、入力トークンの最大数、および出力トークンの最大数によって異なることに注意してください。そのため、 MAX_CONCURRENT_REQUESTS を設定する前にこれらのパラメーターを設定する必要があります。 また、レイテンシの最小化に関心のあるユーザーは、スループットの最大化に関心のあるユーザーと対立することが多いことにも注意してください。前者はリアルタイム応答に関心があり、後者はエンドポイントのキューが常に飽和状態になって処理のダウンタイムを最小限に抑えるようなバッチ処理に関心があります。レイテンシー要件を条件としてスループットを最大化したいユーザーは、レイテンシー – スループット曲線の変化点に立って処理することに関心がある場合がよくあります。 コストの最小化 コストを最小限に抑える最初の選択肢は、1 時間あたりのコストを最小限に抑えることです。これにより、選択したモデルを 1 時間あたりのコストが最も低い SageMaker インスタンスにデプロイできます。SageMaker インスタンスのリアルタイム価格については、 Amazon SageMaker 料金表 を参照してください。一般的に、SageMaker JumpStart LLM のデフォルトのインスタンスタイプは最も低コストのデプロイオプションです。 コストを最小限に抑えるための2つ目の選択肢は、100万トークンを生成するためのコストを最小限に抑えることです。これは、先に説明した表を単純に変換してスループットを最大化する方法です。まず、100 万トークンの生成にかかる時間 (1e6/スループット/3600) を時間単位で計算します。その後、この時間を指定した SageMaker インスタンスの 1 時間あたりの価格にかけて、 100 万トークンを生成のにかかるコストを算出できます。 1 時間あたりのコストが最も低いインスタンスは、100 万トークンを生成するためのコストが最も低いインスタンスと同じではないことに注意してください。たとえば、呼び出しリクエストが散発的である場合は、1 時間あたりのコストが最も低いインスタンスが最適である一方、スロットリングシナリオでは、100 万トークンを生成するコストが最も低いインスタンスの方が適切な場合があります。 テンソル並列 vs 複数モデルのトレードオフ これまでのすべての分析では、デプロイインスタンスタイプの GPU の数に等しいテンソル並列度を持つ単一のモデルレプリカをデプロイすることを検討しました。これが SageMaker JumpStart のデフォルト動作です。ただし、前述のように、モデルをシャーディングすることは、ある特定の限界までモデルのレイテンシーとスループットを改善することができますが、その限界を超えると、デバイス間通信の要求が計算時間を支配するようになります。これは、高いテンソル並列度を持つ単一モデルをデプロイするよりも、低いテンソル並列度を持つ複数のモデルを単一インスタンスにデプロイする方が、しばしば有益であることを意味しています。 ここでは、テンソル並列 (TP) 次数が 1、2、4、8 の ml.p4d.24xlarge インスタンスに Llama 2 の 7B および 13B エンドポイントをデプロイします。モデルの動作をわかりやすくするために、これらのエンドポイントはそれぞれ 1 つのモデルのみをロードします。 以前の分析では、ml.p4d.24xlarge インスタンスではスループットが大幅に向上していることがすでに示されています。これは、同時リクエストの負荷が高い条件下で g5 インスタンスファミリーよりも 100 万トークンを生成するコスト面でのパフォーマンスの向上につながることを示しています。この分析は、単一インスタンス内でのモデルシャーディングとモデル複製のトレードオフを考慮する必要があることを明確に示しています。つまり、完全にシャーディングされたモデルは、通常、7B および 13B モデルファミリーの ml.p4d.24xlarge コンピューティングリソースの最適な使用法ではありません。実際、7B モデルファミリーでは、テンソルの並列次数が 8 ではなく 4 の単一モデルレプリカが最高のスループットが得られています。 ここから、7B モデルの最高スループット構成は 8 つのモデルレプリカによるテンソル並列次数 1 で、13B モデルの最高スループット構成は 4 つのモデルレプリカによるテンソル並列次数 2 である可能性が高いと推定できます。これを実現する方法の詳細については、「推論コンポーネントベースのエンドポイントを使用した Amazon SageMaker の最新機能を使用してモデルのデプロイコストを平均 50% 削減する 」を参照してください。負荷分散の技術、サーバールーティング、および CPU リソースの共有により、レプリカ数とレプリカあたりのスループットを掛けた値とまったく同じスループットの向上を完全には達成できない場合があります。 水平スケーリング 前に説明したように、各エンドポイントのデプロイでは、入力トークンと出力トークンの数、およびインスタンスタイプに応じて、同時リクエストの数に制限があります。これがスループットまたは同時リクエストの要件を満たさない場合は、デプロイされたエンドポイントの背後で複数のインスタンスを利用するようにスケールアップできます。SageMaker はインスタンス間のクエリの負荷分散を自動的に実行します。例えば、次のコードは 3 つのインスタンスがサポートするエンドポイントをデプロイします。 model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.2xlarge", ) predictor = model.deploy( accept_eula=False, # Change EULA acceptance to True initial_instance_count = 3, ) 次の表は、Llama 2 7B モデルのインスタンス数の係数としてのスループットゲインを示しています。 特に、インスタンス数が多いほど、マルチインスタンスエンドポイント内で処理できる同時リクエストの数が増えるため、レイテンシースループット曲線の変化点が右にシフトしています。この表では、同時リクエストの値はエンドポイント全体のもので、個々のインスタンスが受け取る同時リクエストの数ではありません。 また、自動スケーリング機能を使用してワークロードを監視し、容量を動的に調整して、可能な限り低いコストで安定した予測可能なパフォーマンスを維持することもできます。これはこの記事の範囲外です。自動スケーリングの詳細については、「A ma zon SageMaker での自動スケーリング推論エンドポイントの設定 」を参照してください。 同時リクエストでのエンドポイントの呼び出し たとえば、スループットの高い条件下においてデプロイされたモデルからレスポンスを生成するために使用するクエリのバッチが大量にあるとします。たとえば、次のコードブロックでは、1,000 個のペイロードのリストを作成し、各ペイロードで 100 個のトークンの生成を要求しています。合計で 100,000 個のトークンの生成をリクエストしています。 payload = { "inputs": "I believe the meaning of life is to ", "parameters": {"max_new_tokens": 100, "details": True}, } total_requests = 1000 payloads = [payload,] * total_requests SageMaker ランタイム API に大量のリクエストを送信すると、スロットリングエラーが発生することがあります。これを軽減するために、再試行回数を増やすカスタム SageMaker ランタイムクライアントを作成できます。既にデプロイされているエンドポイントに新しいpredictor をアタッチしたい場合には、作成された SageMaker セッションオブジェクトを JumpStartModel コンストラクターまたは s agemaker.predictor.retrieve_default に渡すことができます。次のコードでは、Llama 2 モデルをデフォルトの SageMaker JumpStart 構成でデプロイするときにこのセッションオブジェクトを使用します。 import boto3 from botocore.config import Config from sagemaker.session import Session from sagemaker.jumpstart.model import JumpStartModel sagemaker_session = Session( sagemaker_runtime_client=boto3.client( "sagemaker-runtime", config=Config(connect_timeout=10, retries={"mode": "standard", "total_max_attempts": 20}), ) ) model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", sagemaker_session=sagemaker_session ) predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True このデプロイされたエンドポイントは、デフォルトで MAX_CONCURRENT_REQUESTS = 128 になっています。次のブロックでは、concurrent futures ライブラリを使用して、128 個のワーカースレッドを含むすべてのペイロードのエンドポイントを繰り返し呼び出します。エンドポイントは最大で 128 件の同時リクエストを処理し、リクエストが応答を返すたびに、エグゼキューターはすぐに新しいリクエストをエンドポイントに送信します。 import time from concurrent import futures concurrent_requests = 128 time_start = time.time() with futures.ThreadPoolExecutor(max_workers=concurrent_requests) as executor: responses = list(executor.map(predictor.predict, payloads)) total_tokens = sum([response[0]["details"]["generated_tokens"] for response in responses]) token_throughput = total_tokens / (time.time() - time_start) この結果、1 つの ml.g5.2xlarge インスタンスで合計 100,000 個のトークンが生成され、スループットは 1255 トークン/秒になります。この処理には約 80 秒かかります。 このスループット値は、この記事の前の表にある ml.g5.2xlarge の Llama 2 7B の最大スループット (64 件の同時リクエストで 486 トークン/秒) とは著しく異なることに注意してください。これは、入力ペイロードが 256 の代わりに 8 個のトークンを使用し、出力トークン数が 256 個ではなく 100 個になり、トークン数が少ないほど 128 個の同時リクエストが可能になるためです。最後に、レイテンシーとスループットの数値はすべてペイロードに依存していることを思い出させてくれます。ペイロードトークンの数を変更すると、モデル提供中のバッチ処理に影響が及び、ひいてはアプリケーションの事前入力、デコード、キューにかかる時間にも影響します。 結論 この投稿では、Llama 2、Mistral、Falconなどを含む SageMaker JumpStart LLM のベンチマークについて説明しました。また、エンドポイントのデプロイ構成のレイテンシー、スループット、コストを最適化するためのガイドも紹介しました。まずは、 関連するノートブック を実行してユースケースのベンチマークを行ってください。 &nbsp; このブログのオリジナルは、 Benchmark and optimize endpoint deployment in Amazon SageMaker JumpStart で、機械学習ソリューションアーキテクトの卜部が翻訳しました。

※本記事に記載の内容は 2024 年 03 月 10 日の内容に基づいたものです。今後、サービスの更新や変更に伴い、本記事の内容と異なる部分が出てくる可能性がある点、予めご了承ください。 こんにちは！テクニカルインストラクターの吉田です。2024 年も 3 月になりました。桜の季節が近づいていますね。さて皆様、AWS クラウドの学習を、ゲームベースで行うことができる学習コンテンツの AWS Cloud Quest をご存じでしょうか？ゲーム内で、ストーリーに沿って出題されるソリューション構築に関する課題を、実際の AWS のアカウントを使用しながら解いていく、RPG テイストのコンテンツです。本記事では、昨年 10 月に日本語化された「 AWS Cloud Quest: Cloud Practitioner (Japanese) 日本語版 」に続いて日本語化された「 AWS Cloud Quest: Solutions Architect (Japanese) 日本語版 」についてご案内します。 ＊まだ AWS Cloud Quest をプレイしたことがない、という方は、まずは「 ゲームベースで学習できる「AWS Cloud Quest: Cloud Practitioner」が日本語で学習可能になりました 」をご覧ください。 AWS Cloud Quest: Solutions Architect が日本語化しました。 AWS Cloud Quest には、「クラウドプラクティショナー」「ソリューションアーキテクト」「サーバーレスデベロッパー」「機械学習」「セキュリティ」「データ分析」「ネットワーク」の 7 つのロール（学習カテゴリ）があります。 既に、クラウドプラクティショナーロールをプレイしたことがある方には、次のステップとしてソリューションアーキテクトロールのプレイをお勧めします。 AWS Skill Builder のサブスクリプションをご登録いただくとクラウドプラクティショナーロールに加えてソリューションアーキテクトロールを含む 6 つのロールがプレイ可能になります。なお、執筆時点では &nbsp;7 日間の無料トライアル がございますので、ご興味ある方は「 AWS Skill Builder 個人サブスクリプションで AWS を学んでみる ! 」をご覧いただき、是非お試しください。 ＊ AWS Skill Builder では AWS Cloud Quest 以外にも、 動画学習コンテンツ・ハンズオンコンテンツ (セルフペースラボ)・認定試験模擬問題 (Practice Exam) などもご利用いただけます。 ソリューションアーキテクトロールでは 27 の課題、28 個のサービスが学習可能です。 ソリューションアーキテクトロールでは、クラウドプラクティショナーロールで提供されている、12 の課題を含む 27 の課題に取り組むことができます。 27 の課題に取り組む中で 28 個のサービス（AWS Lambda, Amazon API Gateway, Amazon EC2, Amazon EC2 Auto Scaling, Amazon S3, Elastic Load Balancing, Amazon DynamoDB, AWS Pricing Calculator, Amazon Route 53, AWS Config, AWS Key Management Service, Amazon Elastic File System, Amazon Relational Database Service, AWS CloudFormation, AWS Backup, AWS Identity and Access Management, Amazon CloudWatch, Amazon CloudFront, Amazon SNS, Amazon SQS, Amazon Elastic Container Registry, Amazon Elastic Container Service, Amazon Data Firehose, Amazon Athena, AWS Glue, AWS Cloud Development Kit, AWS Cloud9, Amazon CodeWhisperer）を、実際の環境を触りながら身につけていくことができます！クラウドプラクティショナーロールで触れるサービスは上述したサービスの内の 9 つなので、ソリューションアーキテクトロールでは、その 3 倍の数のサービスを学習できます。 島の住人の課題を解決する手段として、28 個ものサービスを使ったソリューションを学習できるのがソリューションアーキテクトロールの魅力です。具体例として、「クラウド、はじめの一歩」という課題を見てみましょう。島の住人は、物理サーバーにマウントされたハードディスクの障害に悩まされています。皆様は、ソリューションアーキテクトとしてこの課題を解決するために、Amazon EC2 及び Amazon EBS を用いたアーキテクチャを提案及び実装します。 AWS Cloud Quest を通して、技術課題の解決の経験を積むことができます。それぞれの AWS サービスがどんな技術的な課題を解決できうるのか、という観点で学習できるのが AWS Cloud Quest で学習していく魅力です。(加えて、楽しく学習できます！) 生成 AI に関する課題がプレイできます。 近年のホットトピックである、生成 AI に関する「生成 AI でのクラウドインフラストラクチャ」という課題がプレイ可能です。上司から AWS リソースのデプロイの自動化ミッションを与えられ困惑している島の住人に対し、 皆様はソリューションアーキテクトとして生成 AI によるコードの自動生成を利用した 迅速な IaC (Infrastructure as Code) の実現を提案します。 そして課題内でプロトタイプを作成し、島の住人の課題を解決します。この課題では、リアルタイムでコードを提案する Amazon CodeWhisperer について学習いただけます。 執筆時点では、ソリューションアーキテクトロール内では、生成 AI の課題は 1 つのみですが、サーバーレスデベロッパーロール・機械学習ロール・セキュリティロール内に生成 AI に関する課題が合わせて 4 つあります。「話題の生成 AI に興味がある」、「AWS の 生成 AI サービスを学習したい」という方にもお勧めです。 さて、今回は昨年 10 月に日本語化された「 AWS Cloud Quest: Cloud Practitioner (Japanese) 日本語版 」に続いて日本語化された「 AWS Cloud Quest: Solutions Architect (Japanese) 日本語版 」についてご案内しました。 AWS Cloud Quest については、こちらに 5 分程度の紹介用動画 もありますので、内容を手早く知りたい方は是非ご確認ください（こちらの動画は 2023 年 8 月に公開した内容のため、「英語版のみでのご提供」という表現がありますが、クラウドプラクティショナーロール及びソリューションアーキテクトロールは上記の通り日本語化されております）。日本語化されたことでより多くの方に楽しんでいただけるのではないかと期待しています。 今後とも AWS のトレーニングをよろしくお願いいたします。

はじめに Amazon Monitron は機械学習を用いて産業機器の異常な状態を検出し、予知保全を可能にするエンドツーエンドのシステムです。簡単に設置できるハードウェアと機械学習の力で、コストのかかる修理を省き、工場やプラントの機器のダウンタイムを防ぎます。Amazon Monitron の特徴は 製品紹介 をご覧ください。 Amazon Monitron は提供範囲を広げるとともに、お客様からの声を受け止めてたくさんのアップデートを行いました。 このブログでは2023年から2024年初頭までの間に提供された Amazon Monitron のアップデートをまとめて紹介します。 Amazon Monitron デバイスが日本とオーストラリアで販売開始 2023年8月に日本とオーストラリアで Amazon Monitron デバイス (センサー、イーサネットゲートウェイ、Wi-Fi ゲートウェイ) の使用が認定されました。これらのデバイスは、 オーストラリア では Amazon リテール (豪州) 経由で、 日本 では Amazon.co.jp (日本) および Amazon Business (日本) 経由で購入できるようになりました。現在、Amazon Monitron は、米国、カナダ、英国、ドイツ、スペイン、イタリア、オーストラリア、日本で購入いただけます。最新の購入可能地域は Amazon Monitron のよくある質問 をご覧ください。 なお、2024年3月現在、日本の東京リージョン・大阪リージョンでは Amazon Monitron サービスはサポートされていません。 日本国内で Amazon Monitron を利用するには Amazon Monitron をサポートしているリージョン を用いてください。 Amazon Monitron がアジアパシフィック (シドニー) リージョンで利用可能に 2023年8月にAmazon Monitron サービスがアジアパシフィック (シドニー) リージョンでも利用可能になりました。今回のリージョン拡大に伴い、Amazon Monitron は、米国東部 (バージニア北部)、欧州 (アイルランド)、アジアパシフィック (シドニー) の各 AWS リージョンで利用できるようになりました。アジアパシフィックリージョンのお客様は、地理的により近いリージョンで Amazon Monitron サービスを使用できるようになります。このアップデートについての詳細は リリースノート をご覧ください。最新のAmazon Monitron を可能なリージョンは Amazon Monitron のよくある質問 をご覧ください。 ソラコム社 が Amazon Monitron と IoT用LTEルーター、通信プランをセットにした「SORACOM セルラーパック for Amazon Monitron」 を販売開始 「SORACOM セルラーパック for Amazon Monitron」(2024年3月現在の名称) は、Amazon MonitronとSORACOM IoT SIM、その他 Amazon Monitron の導入にあたって必要となる部材一式をセットにしており、設置現場の既設ネットワークに干渉せずに、 Amazon Monitron のスムーズな導入を可能にします。このセットには plan-K2 K2-300MB SIM （サイズ：マルチ・データ通信のみ）と、SORACOM サービス利用料 1,000 円分のクーポン（6ヶ月有効）が付属します。このセットの詳細は ソラコム社へお問合せ ください。 Amazon Monitron が異なるリージョンの IAM Identity Center との連携に対応 2023年11月に Amazon Monitron は異なるリージョンのIAM Identity Center (IIC) との連携に対応しました。Amazon MonitronはMonitronアプリケーションのユーザー管理を行うために IIC を用いる必要があります。 従来、Amazon Monitron はAmazon Monitron を利用するリージョンと同じリージョンで稼働するIICとの連携のみをサポートしていましたが、このアップデートにより、Amazon Monitron が稼働するリージョンと異なるリージョンで稼働する IICと連携することができます。 このアップデートにより、例えば日本のような Amazon Monitron サービスがまだサポートしていないリージョンで既に IIC を利用しているお客様が Amazon Monitron を利用することが容易になりました。 詳細は Amazon Monitron ユーザーガイド をご覧ください。 振動に関するISO 20816規格に基づいた Class 1~4 のデフォルトクラスに加えて、「カスタムクラス」としてしきい値を独自に設定可能に 2023年12月にアセットクラスに「カスタムクラス」が追加されました。従来、振動に関する閾値ベースの判定は ISO 20816規格に基づいた Class 1 – 4 の4段階のアセットクラスから選択いただくことができました。各アセットクラスに応じてしきい値が固定に設定されており、しきい値に応じて Warning やアラームを発生させます。今回カスタムクラスが追加されたことにより、アセットタイプが Amazon Monitron が提供するデフォルトのアセットクラスと一致しない場合には、カスタムクラスを作成することができます。これにより、Warning やアラームを発生させる条件となるしきい値をカスタマイズすることが可能となりました。 詳細は A mazon Monitron のドキュメント をご覧ください。なお、ISO 20816 規格の詳細は、builders.flashの記事「 機械振動の測定と評価規格「ISO 20816」とは ? 」をご覧ください。 Amazon Monitron が他のAWSサービスと連携するためのデータストリーミング仕様が Ver.2 に更新 2023年4月にAmazon Monitron の Kinesis 2.0 データストリームがリリースされました。これはスキーマを更新したものであり、Monitron センサーとゲートウェイを使用する新しいインサイトを含みます。また、ユーザーによってトリガーされるアセット状態の移行イベントも含みます。この新しいスキーマは、今後追加されるデータタイプを受け取れます。Amazon Monitron が自動的に データを Kinesis ストリームに追加する ように設定すると、そのデータを Amazon S3 や Lambda など、さまざまな宛先に送信できます。 今回のローンチにより、センサーとゲートウェイデバイス、接続ステータス、ユーザークロージャコードを、ライブストリームから収集できるようになりました。Monitron サービスがいずれかのセンサーまたはゲートウェイがオフラインになったことを検出すると、接続ステータスによってお客様は Kinesis の更新情報を受け取れます。ユーザークロージャコードを使用すると、お客様は Monitron の通知に対するユーザーの応答を追跡できます。これにより、障害モードや実行したアクション全体にわたる共通事項のレポートが可能になります。この機能により、自社のエンタープライズ設備管理 (EAM) システムで保守チームの作業指示書を作成することもできます。 この機能の詳細については、 こちらのドキュメント を参照してください。 Amazon Monitron、防爆構造の Ex 規格センサーを発売 2023年11月に Ex 規格の Amazon Monitron センサーの発売を発表いたしました。これらの Ex 規格のセンサーは、米国、カナダ、英国、EU での使用が認定されており、 Amazon.com (米国) および Amazon Business (米国) で購入できます。 お客様は、これらの Ex 定格のセンサーを設置することで、Monitron を使用して危険な場所 (ガス、クラス 1 / ゾーン 2) にある資産を監視できるようになりました。2024年3月現在、上記以外の国ではEx 規格センサーを購入・利用はできません。詳細は リリースノート と データシート をご覧ください。 Amazon Monitron で、プロジェクトレベルとサイトレベルでのコスト可視化のサポートを開始 2023年12月に Amazon Monitron のお客様が、使い慣れた AWS Cost Explorer コンソールを使用して、プロジェクトレベルおよびサイトレベルでソフトウェアの請求を視覚化する機能をリリースしました。こののリリースにより、センサーの使用コストを、プロジェクトやサイトなど、Monitron の管理する階層内のリソースに正確に割り当てることができます。お客様は、プロジェクトレベルの請求を活用して、組織ごとにコストを配分できるようになりました。また、サイトレベルできめ細かな使用状況をよりよく把握できます。全体として、これらの機能により、組織ごとに Monitron ソフトウェアのコストをさまざまな業務にわたってより適切に最適化し、配分することができます。このアップデートの詳細は リリースノート をご覧ください。 Amazon Monitron でゲートウェイのネットワーク設定に静的 IP が使用可能に 2024年2月に、新たに設定するゲートウェイで静的 IP を使用できるようになりました。これにより、お客様はファイアウォールにきめ細かなルールを設定して、ドメイン名ではなく特定の IP アドレスをフィルタリングできます。これらのアドレス ( このドキュメントページ を参照) は静的で、Amazon Monitron を使用するリージョンのみに従属するため、ファイアウォールルールで IP アドレスを最大 3 つまで簡単に許可リストに追加できます。 従来、ファイアウォールによる保護を利用しているお客様は、工場に設置されたセンサーと AWS クラウドとの間でこの通信ができるようにするために、 amazonaws.com のサブドメイン全体を許可リストに登録する必要がありました。セキュリティ上の理由から、全ドメイン/サブドメインを許可リストに登録したくないお客様やファイアウォールの設定機能に制限があるために難しいと感じるお客様はAmazon Monitronの導入が容易になりました。詳しくは リリースノート をご覧ください。 Amazon Monitron を使い始めるには これから Amazon Monitron を使い始める日本のお客様のために、日本のソリューションアーキテクトが解説する短いオンラインセミナーを用意しました。このオンラインセミナーを視聴して、お客様の設備での検証を初めてください。 Amazon Monitron Part 1（基本編）【AWS Black Belt】 Amazon Monitron Part 2（設定編）【AWS Black Belt】 Amazon Monitron Part 3（サービス連携編）【AWS Black Belt】 おわりに Amazon Monitron は機械学習を用いて産業機器の異常な状態を検出し、予知保全を可能にするエンドツーエンドのシステムです。Amazon Monitron は2023年から2024年初頭までの間にお客様からの声を受け止めてたくさんのアップデートを行いました。 このブログでは提供された Amazon Monitron のアップデートをまとめて紹介しました。 このブログは Amazon Web Services Japan のソリューションアーキテクト 吉川晃平 が執筆しました。

Azure SQL Managed Instance から Amazon Web Services (AWS) の SQL Server へ、Azure SQL Managed Instance のコピーのみのバックアップを使用して Microsoft SQL Server データベースを移行できることをご存知ですか？この方法を使用すると、データベース内のすべてのオブジェクトをコピー/移動するため、手順は簡単で、すべてのエディションをサポートします。ただし、この方法はフルバックアップとリストアのみをサポートし、差分バックアップやトランザクションログのバックアップはサポートしていないことに注意してください。移行中の変更差分をキャプチャするために使用できる方法は他にもあります。 このブログ記事では、Azure SQL Managed Instance の最新機能である SQL Server 2022 への バックアップの移植性 も含め、SQL Server データベースを Azure SQL Managed Instance から AWS の SQL Server に移行するさまざまな方法について説明します。 Azure SQL Managed Instance から AWS への移行の理由 Azure SQL Managed Instance は最新の SQL Server 2022 データベースエンジンと互換性のあるフルマネージドプラットフォームですが、SQL Server 2022 のコピーのみのバックアップを使用して AWS に移行する利点があります。まず、インフラストラクチャのより高い柔軟性と管理を提供します。ニーズに最適なインスタンスタイプ、ストレージオプション、ネットワーク構成を選択できます。追加のソフトウェアをインストールしたり、特定のパフォーマンス最適化を適用したり、環境全体をより細かく制御できます。もう一つの重要な側面はコスト削減です。 Amazon Elastic Compute Cloud (Amazon EC2) 上の SQL Server に移行することで、ライセンスコストを節約し、Amazon EC2 の高可用性オプションを活用できる可能性があります。 Azure SQL Server Managed Instance から AWS への移行には、以下の 3 つの異なる方法があります。 SQL Server のバックアップと復元 (COPY_ONLY) AWS Database Migration Service &nbsp;(AWS DMS) SQL Server インポートおよびエクスポートウィザード ソリューション概要 図 1 のソリューションアーキテクチャ図は、SQL Server データベースを AWS に移行する 3 つの方法を示しています。 図 1 : Azure SQL Managed Instance から AWS 上の SQL Server への移行オプション Azure SQL Managed Instance から AWS への移行には、複数のオプションがあります。Amazon EC2 上の SQL Server または Amazon Relational Database Service (Amazon RDS) for SQL Server に移行できます。表 1 は、このブログ記事で説明している 3 つの移行オプションの機能を比較したものです。課題と利点を理解することで、ニーズに適した方法を判断し、全体的な移行目標と整合させることができます。 表 1 : Azure SQL Managed Instanceと AWS オプションの比較 * 詳細は AWS DMS のドキュメントを参照してください。 前提条件 Azure ストレージアカウント Azure SQL Managed Instanceでホストされている SQL Server ソースデータベース Amazon EC2 上の SQL Server 2022 があるアクティブな AWS アカウント AWS と Azure 間のネットワーク接続 (VPN、プライベートネットワーク、インターネット) SQL Server Management Studio (バージョン 19.0.1 以降) 方法 1. SQL Server のコピーのみのバックアップを使用した移行 Azure SQL Managed Instance から Amazon EC2 上の SQL Server へのデータベースの移行は、Azure SQL Managed Instance の コピーのみのバックアップ を使用して実行できます。この方法を利用すると、Azure のマネージドインスタンス から SQL Server 2022 インスタンス (Enterprise、Developer、Standard エディション) へ、データベースオブジェクトを含むすべてのデータベースを簡単にコピーまたは移動できます。この移行方法では、フルバックアップとリストアのみをサポートしており、差分バックアップやトランザクションログバックアップはサポートしていません。ソース SQL Server から AWS 上のターゲット SQL Server へ、SQL Server の ログイン を転送する必要があります。 注 : Azure SQL Managed Instance のコピーのみのバックアップ方法は Transparent Data Encryption (TDE) をサポートしていません 。移行前に、ソースの SQL Server データベースと証明書をバックアップし、TDE を無効にします。TDE を無効にすると、リソースを大量に消費する操作になる可能性があります。このアクティビティはピーク時以外に計画してください。移行後に Amazon EC2 上の SQL Server データベースで TDE を有効にすることができます。 ソースとターゲットの SQL Server データベースが接続されていることを確認してください。Amazon EC2 からソースの Azure SQL Server Managed Instance に接続してバックアップを実行できます。 移行を実行する手順は次のとおりです。 1.1. Azure portal にログインし、Azure ストレージアカウントに移動します。 1.2. 図 2 に示すように、Azure ストレージアカウントに Azure BLOB ストレージコンテナーを作成します。 図 2 : Azure BLOB ストレージでのコンテナーの作成 1.3. 図 3 に示すように、Azure ストレージコンテナー用の Shared Access Signature (SAS) トークン を作成する必要があります。 図 3 : ストレージコンテナの共有アクセストークンの作成 1.4. 次に、SQL Server Management Studio (SSMS) を使用して、 Azure SQL Server Managed Instance に接続します。手順 1.3 の SAS トークンを使用して、図 4 のスクリプトを使用して Azure BLOB Storage へのアクセスを許可する認証情報を作成します。 CREATE CREDENTIAL [https://sqlbackup02142023.blob.core.windows.net/sqlbackup] WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET ='sp=sssssssssxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’ 図 4 : 認証情報の作成 1.5. 認証情報を作成したら、図 5 のスクリプトを使用して、COPY_ONLY バックアップコマンドを実行し、 Azure BLOB Storage にデータベースの完全バックアップを実行する必要があります。Azure SQL Managed Instanceでは、バックアップコマンドの COPY_ONLY オプションのみが提供されています。 BACKUP DATABASE [AzureSQLMIBackuptest] TO URL = 'https://sqlbackup02142023.blob.core.windows.net/sqlbackup/AzureSQLMIBackupfulll.bak' WITH COPY_ONLY 図 5 : COPY_ONLY を使用したデータベースのバックアップ 1.6. SSMS を使用して Amazon EC2 上の移行先 SQL Server 2022 に接続し、Azure SQL Blob ストレージ用の図 6 のスクリプト (手順 1.3 で作成した共有アクセストークンを使用する) を使用して認証情報を作成できます。 CREATE CREDENTIAL [https://sqlbackup02142023.blob.core.windows.net/sqlbackup] WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET ='sp=sssssssssxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’ 図 6 : Amazon EC2 上のターゲット SQL Serverで認証情報を作成 1.7. 認証情報が作成されたら、Amazon EC2 上の SQL Server の宛先で、図 7 のスクリプトを使用して restore database コマンドを実行する必要があります。 RESTORE DATABASE AzureSQLMIBackuptest FROM URL = 'https://sqlbackup02142023.blob.core.windows.net/sqlbackup/AzureSQLMIBackupfull.bak' WITH MOVE 'data_0' TO 'C:\MSSQL\DATA\AzureSQLMIBackuptest_data_0.mdf', MOVE 'log' TO 'C:\MSSQL\DATA\AzureSQLMIBackuptestlog.ldf', MOVE 'XTP' TO 'C:\MSSQL\DATA\AzureSQLMIBackuptest_xtp.xtp' 図 7 : Amazon EC2 上のターゲット SQL Server へのデータベースのリストア 1.8. 次に、図8に示すように、Amazon EC2上のターゲット SQL Server で SSMS を使用して、リストアされたデータベースが利用可能であることを検証します。 図 8 : EC2 上の SQL Server にリストアされた Azure SQL Managed Instance SQL Server のバックアップとリストアの方法はフルバックアップのみを提供するため、この方法ではデータベースのサイズに応じてダウンタイムが必要になります。 方法2. AWS DMS を使用した移行 Azure SQL Server Managed Instance データベース上でミッションクリティカルなワークロードを実行していて、ダウンタイムを最小限に抑えて AWS に移行する必要がある場合は、 AWS Database Migration Service (AWS DMS) を使用できます。AWS DMS は、 SQL Server のバックアップとリストア 方法と組み合わせて、Azure SQL Managed Instance から Amazon EC2 上の SQL Server へ SQL Server データベースを移行できます。 AWS DMS を使用することで、Azure SQL Managed Instance から Amazon RDS for SQL Server へのダウンタイムを最小限に抑えたフルロードや変更データキャプチャ (Change Data Capture、CDC) によるマイグレーションができます。 AWS DMS は変更の追跡に MS-Replication または MS-CDC を使用します。 詳細は AWS DMS の ドキュメント を確認してください。 AWS DMS を使用した移行の手順は以下のとおりです。 2.1. まず、図 9に示すように、ソースの Azure SQL Server Managed Instance データベースとテーブルで CDC を有効にします。 図 9 : Azure SQL Server Managed Instance ソースデータベースの CDC の有効化 2.2. 次に、図 10に示すように、 AWS DMS レプリケーションインスタンス を作成します。 図 10 : AWS DMS でレプリケーションインスタンスの作成 2.3. ソースエンドポイントとして Azure SQL Managed Instance を作成する必要があります。「エンドポイント設定」コンソール画面で「接続のテスト」を選択することで、ソースエンドポイントからレプリケーションインスタンスへの 接続性をテスト できます。接続性が正しく設定されていることを確認してください。詳細は AWS DMS のドキュメントを参照してください。 図 11 : Azure SQL Managed Instance をソースとした AWS DMS エンドポイント設定 2.4. ソースエンドポイントが作成された後、ターゲットの SQL Server エンドポイントを作成します。 次に、図12に示すように、「エンドポイント設定」コンソール画面の「接続テスト」を選択することで、ターゲットエンドポイントからレプリケーションインスタンスへの 接続性をテスト します。 接続性が正しく設定されていることを確認してください。 図 12 : EC2 上の SQL Server をターゲットとした AWS DMS エンドポイント設定 2.5. AWS DMS タスクを作成するには、手順 2.3 と 2.4 で設定したソースからターゲットへのエンドポイントを選択します。図 13 に示すように、継続的なレプリケーションのために「既存のデータを移行して、継続的な変更をレプリケートする」移行タイプを選択します。 図 13 : AWS DMS マイグレーションタスクの設定 2.6. 次のステップはレプリケーションタスクをモニタリングすることです。図 14 は AWS DMS タスクの進捗を示しています。両方のデータベースが同期されたら、Amazon EC2 上のターゲット SQL Server への切り替え作業を実施し、ダウンタイムを最小限に抑えて移行を完了することができます。 図 14 : DMS レプリケーション概要ページからの AWS DMS 移行タスクのステータス進捗レポート この移行方法の詳細については、このブログ記事 AWS DMS を使用した SQL Server データベースの移行 をお読みください。 方法3. SQL Server インポートおよびエクスポートウィザードを使用した移行方法 Azure SQL Managed Instance から Amazon EC2 上の SQL Server への移行に、SQL Server のインポートおよびエクスポートウィザードを使用できます。これは、小規模なデータベースを使用している場合や、部分的なデータ移行を実行したい場合、移行中にデータ変換を必要とする場合に適しています。 ソースとターゲットの SQL Server データベース間の接続性を確保する必要があります。 Amazon EC2 からソースの Azure SQL Server Managed Instance に接続して、手順を実行できます。 SQL Server インポートおよびエクスポート ウィザードを使用して移行する手順は次のとおりです。 3.1. SQL Server Management Studio(SSMS)を使用して、Azure SQL Managed Instanceに接続します。 3.2. ソースデータベースを右クリックし、[タスク] – [データのエクスポート] を選択します。 図 15 に示すように、Microsoft OLE DB Driver for SQL Server を使用して、Azure SQL Managed Instance の接続詳細を指定します。 図 15: SQL Server インポートおよびエクスポート ウィザードのソースの選択 3.3. 次に、図16 に示すように、ターゲットサーバーとして Amazon EC2 上の SQL Server 2022 の接続情報を指定します。 図 16 : SQL Server インポートおよびエクスポート ウィザードのターゲットの選択 3.4. ソース接続とターゲット接続の両方をテストし、接続が機能していることを確認してください。 3.5. 移行するソーステーブルとビューを選択し、マッピングが期待どおりであることを確認して、データを移行するためにOKをクリックしてください。 図 17 : SQL Server インポートおよびエクスポート ウィザードの進捗レポート 3.6. SSMSを介してターゲットのSQL Serverに接続することで、インポート後のデータを検証してください。アプリケーションをテストおよび検証し、期待どおりに機能していることを確認してください。 この移行方法の詳細については、 他の方法による SQL Server データのインポートとエクスポート の一括コピーのセクションをご確認ください。 まとめ このブログ記事では、Azure SQL Server Managed Instance から Amazon EC2 上の SQL Server への移行について、3つの異なるオプションを紹介しました。 SQL Server 2022 のネイティブなバックアップとリストア機能を利用して、AWS 上の SQL Server 2022 へ移行することができます。 ダウンタイムを最小限に抑えたニアリアルタイムの移行を実現したい場合は、AWS DMS の利用を検討してください。 小規模なデータベースや、テーブル、ビューなどの特定のオブジェクトの部分的な移行を実行したい場合は、SQL Server インポートおよびエクスポートウィザードの利用を検討してください。 Azure SQL Managed Instance から AWS への SQL Server データベースの移行でダウンタイムを最小限に抑えるには、 AWS Marketplace の CloudBasic を利用 することもできます。 その他の方法を使用した SQL Server の移行に関する詳細は、 オンプレミスのMicrosoft SQL Server データベースを Amazon RDS for SQL Server に移行する(英文) をご覧ください。 SQL Server ワークロードの移行およびモダナイゼーションのオプションを現在評価している場合、SQL Server 2022 を含め、お問い合わせください。SQL Server の計画と活動を支援させていただきます。 AWS は、お客様がクラウドを最大限に活用する方法を評価するご支援をします。AWS は数百万のお客様からご信頼いただき、最も重要なアプリケーションをクラウドに移行しモダナイズするためにご利用いただいています。Windows Server または SQL Server のモダナイゼーションの詳細については、 Windows on AWS をご覧ください。今すぐ移行を開始するには、 こちら からお問い合わせください。 TAGS: SQL Server , SQL Server 2022 Yogi Barot Yogi はプリンシパルソリューションアーキテクトであり、さまざまなマイクロソフトテクノロジーを扱った 22 年の経験があります。彼女の専門は SQL Server とさまざまなデータベーステクノロジーです。Yogi には AWS でのマイクロソフトワークロードの実行に関する深い知識と専門知識があります。 Rita Ladda Rita Ladda は、アマゾン ウェブ サービスのマイクロソフト スペシャリスト シニアソリューション アーキテクトであり、多くのマイクロソフトテクノロジーで 20 年以上の経験があります。 彼女は、SQL Server およびその他のデータベースのデータベース ソリューションの設計を専門としています。 彼女は、Microsoft ワークロードの AWS への移行とモダナイゼーションにおけるアーキテクチャに関するガイダンスを顧客に提供しています。 この記事の翻訳はソリューションアーキテクトの平良允俊が担当しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 2024 年 3 月 21 日に、 AWSome Day Online Conference が開催されます。時間は、 10:00~13:00、14:00~17:00 の 2 パターンから参加しやすい方を選択いただけます。クラウドジャーニーのはじめの一歩として、AWS クラウドに関する基礎知識を 3 時間で学ぶ無償の初心者向けオンラインイベントです。クラウドに関する事前知識は必要ありません。クラウドそのものの解説からはじまり、EC2、Lambda、RDS、IoT など多くの AWS サービスを幅広く学習いただけます。是非ご登録ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024 年 3 月 4 日週の主要なアップデート 3/4(月) Anthropic’s Claude 3 Sonnet model now available on Amazon Bedrock Amazon Bedrock で新たなモデルの Claude 3 を提供する旨がアナウンスされました。Claude 3 には 3 つのモデルがあり、3 つの中で最速の出力を行い軽量な利用向けの Claude 3 Haiku、スキルとスピードのバランスのとれた Claude 3 Sonnet、トップレベル向けの最もインテリジェントな Claude 3 Opus です。既に Sonnet は、オレゴンと北部バージニアリージョンで利用可能で、残り 2 つは Coming Soon です。パフォーマンス・精度・信頼性の向上、ハルシネーションの軽減、ビジョン機能の追加などの特徴があります。ビジョン機能は画像を与えることで、画像の内容を読み取り出力を得られます。個人的に面白いと感じたのが、AWS のアーキテクチャ画像を与えて、レビューを依頼する使い方です。「可用性、拡張性、コスト最適化、セキュリティの 4 つの柱をより強く意識してアーキテクチャレビューをしてください」といったプロンプトを与えると、100 点満点ではないですが、比較的妥当な結果が得られました。一部、誤った結果が出る可能性は 0 ではないので、その点も留意して試してみてください。Claude 3 についての詳細は こちらのブログ をご確認ください。 AWS WAF enhances rate-based rules to support configurable time windows AWS WAF のレートベース機能でリクエストを集計する期間を変更できるようになりました。レートベースでは、受信リクエストをカウントし、レートが高い場合にはリクエストを制限します。例えば、特定の IP アドレスからのアクセスが、一定期間に 10,000 回以上のものを対象にブロックできます。これまでは集計期間が 5 分固定でしたが、1 分、2 分、10 分を指定できるようになりました。 Amazon FSx for NetApp ONTAP doubles maximum throughput capacity to 72 GBps Amazon FSx for NetApp ONTAP でファイルシステムあたりの最大スループット容量が 2 倍に増加しました。以前は、最大 36 GB/秒の読み取りスループットと 6 GB/秒の書き込みスループットを実現する最大 6 つの HA ペアを使用してファイルシステムを作成できました。現在では、最大 12 HA ペアでファイルシステムを作成でき、最大 72 GB/秒の読み取りスループットと 12 GB/秒の書き込みスループットを実現できるようになり、より高性能な ONTAP ワークロードを AWS に移行できるようになりました。 3/5(火) Free data transfer out to internet when moving out of AWS AWS のサービスをご利用のお客様にご満足いただけるよう努めています。しかし、何らかの事情により他のプラットフォームへ移行しなければいけない場合もあります。このような状況に対応するため、他のプラットフォームへ移行時にアウトバウンドデータ転送を無料にするようリクエストできる仕組みを提供しました。この仕組みを利用するには、担当の営業にご連絡いただくか、担当がいない場合は AWS サポートまでお問い合わせください。詳細は こちらの FAQ をご覧ください。 Amazon ECS adds gMSA authentication for Linux containers for AWS Fargate Amazon ECS on Fargate で動かしている Linux コンテナで、グループマネージドサービスアカウント (gMSA) がサポートされ、Windows 認証を使用しているアプリケーションを動かしやすくなりました。gMSA は Windows 認証周りを支援する機能です。一例を挙げると、アプリケーションから SQL Server や Windows ファイルサーバーへアクセスする際に、Active Directory と連携して、アクセスがしやすくなります。アップデート以前は Linux コンテナで gMSA を利用するために、ECS on EC2 を利用する必要がありましたが、今回のアップデートで ECS on Fargate で利用ができます。 3/6(水) Amazon RDS now supports io2 Block Express for consistent sub-millisecond latency and 99.999% durability Amazon RDS で高性能ストレージ io2 Block Express ボリュームの提供を開始しました。ミッションクリティカルなワークロードに対して一貫したサブミリ秒単位のレイテンシーを提供します。io2 Block Express は 99.999% の耐久性、最大 64 TiB ボリューム、4,000 MB/秒のスループットをサポートします。また、ModifyDBInstance APIを使用して、ダウンタイムなしで io1 ボリュームから io2 Block Express ボリュームにアップグレードできます。 Amazon EC2 C7gd, M7gd, and R7gd metal instances are now available Amazon EC2 で、最大 3.8 TB のローカル NVMe SSD ストレージを搭載した C7gd、M7gd、R7gd ベアメタルインスタンスの一般提供を発表しました。これらのインスタンスは、同等の Graviton2 ベースのインスタンスと比較して、NVMe ストレージ性能が最大 45 % 向上しています。AWS Nitro System 上に構築されており、一時ファイル、キャッシュなどのデータの一時的な保存を必要とするアプリケーションを含め、高速で低レイテンシーのローカルストレージへのアクセスを必要とするアプリケーションに最適です。東京含め 13 リージョンで提供されています。 Introducing the AWS Generative AI Competency Partners AWS パートナー関連のアップデートです。AWS Generative AI コンピテンシーの開始を発表しました。これは、AWS で生成 AI を実装する際の技術的な習熟度を示しており、お客様との継続的な成功を収めてきた実績がある AWS パートナーが対象として選ばれています。これらのパートナーは、Amazon Bedrock、Amazon SageMaker Jumpstart、Amazon CodeWhisperer、AWS Trainium、AWS Inferentia などの生成 AI 関連テクノロジーを活用する実績があります。 詳細はこちら からご覧ください。 3/7(木) Amazon Managed Grafana launches Enterprise plugins upgrade Amazon Managed Grafana で Grafana Enterprise へ直接アップグレードを行う機能が提供されました。これにより、Grafana Enterprise で提供されているプラグイン (ServiceNow、Splunk、New Relic など) にアクセスできるだけではなく、Grafana Labs からのサポートとトレーニングも可能になります。アップデート以前は、AWS Marketplace から Grafana Enterprise をサブスクライブすることで Enterprise Plugin にアクセスできましたが、今回のアップデートで、AWS マネジメントコンソールから直接サブスクライブできるようになりました。前払い料金や最低契約は不要で、アップグレードされたワークスペースあたりのアクティブユーザー数に基づいて使用した分のみ料金が発生します。 プラグインの一覧はこちら をご確認ください。 Announcing new Amazon VPC DHCPv6 setting to adjust IPv6 preferred lease time Amazon VPCの DHCP オプションセットに「IPv6 preferred lease time」と呼ばれる機能が追加され、IPv6 アドレスを DHCP で配布 (リース) する際に、リースの更新期間を調整できるようになりました。Amazon EC2 インスタンスは DHCP リース更新を定期的に行い、IPv6 アドレス割り当てを行います。デフォルトで、「IPv6 preferred lease time」は 140 秒となっており、DHCP リース更新処理は、140 秒の半分である 70 秒ごとに実行されます。この期間を長く調整することで、IPv6 リースの更新回数を最小限に抑え、万が一の更新に失敗する可能性を低減できます。 3/8(金) AWS announces Aurora MySQL integration with Amazon Bedrock for Generative AI Aurora MySQL 3.06 バージョンの Amazon Aurora ML 機能で、SQL で直接 Amazon Bedrock にアクセスできるようになりました。Amazon Aurora MLはモデルを SQL 関数として公開し、標準 SQL を使用してモデルにデータを渡したり、クエリ結果としてモデルの出力を返すことができます。データベース内で Bedrock へのアクセスがシンプルに実現でき、独自のインテグレーションなどのカスタマイズの負担を軽減できます。例えば、 SELECT invoke_titan(request) FROM prompts; といった SQL クエリーを投げることで、Bedrock から出力されたテキストを SELECT で取得できます。詳細は こちらの Document をご覧ください。 AWS WAF now supports larger request body inspections for regional resources AWS WAF でリージョナルリソース (API Gateway、Cognito User Pool、App Runner、Verified Access) に紐づけて検査する際、受信リクエストのサイズ上限が 64 KB に緩和されました。 元々 AWS WAF は、最大検査サイズの上限が 8 KB でした。CloudFront は 2023 年に 64 KB まで上限が緩和されていますが、それにリージョナルリソースが追いついた形です。一方、留意点として、ALB と AppSync はこのアップデートの対象外となっています。また 16 KB を越えて上限を緩和する設定を実施した際に、追加の料金が発生するようになります。 料金の詳細 はこちらをご覧ください。 Application Load Balancer now supports Resource Map in AWS Management Console Application Load Balancer (ALB) でリソースマップをサポートし、AWS マネジメントコンソール上で、ALB とそれに紐づくターゲットグループや EC2 インスタンスなどの関連リソースを視覚的に確認ができるようになりました。ALB の詳細画面に「Resource map 」タブが新規に追加され、簡単に確認ができます。 最後に、週刊AWS のサムネイルの写真を更新しました。今までは小林さん、下佐粉さんの写真でしたが、2023 年の夏頃に新たに参加した根本さんと杉山も含め、4 人の写真にアップデートしました (少し恥ずかしいですが・・・)。これからもよろしくお願いします。 それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

はじめに 昨今、多くのお客様はインフラストラクチャのデプロイとメンテナンスに関する手動運用を減らしたいと考えています。 AWS でインフラストラクチャをデプロイしたり運用したりするためには、 AWS CloudFormation 、 AWS Cloud Development Kit (AWS CDK) 、 Terraform のようなツールを利用した Infrastructure-As-Code (IaC) モデルを採用することが推奨されます。 Terraform を利用する上では、インフラストラクチャの設定やリソースを追跡するための State ファイルの管理がとても重要な要素となります。 AWS 上の CI/CD パイプライン で Terraform を実行する場合、State ファイルはパイプラインからアクセスできる共通の安全なパスに保存する必要があります。 チームの複数の開発者が同時にアクセスしようとすることを想定して、State ファイルをロックするメカニズムも必要です。 このブログ記事では、AWS で Terraform の State ファイルを管理する方法とその設定のベストプラクティス、および AWS CodeCommit や AWS CodeBuild などの AWS デベロッパーツールを利用した継続的インテグレーションパイプラインにおける効率的な管理の例について説明します。このブログ記事は、Terraform、AWS デベロッパーツール、AWS 上での CI/CD パイプラインに関する基本的な知識のある読者を想定しています。では始めましょう! State ファイルの取り扱いにおける課題 デフォルトでは、State ファイルは Terraform を実行するローカル環境に保存されます。これは、デプロイメントの作業をする開発者が 1 人だけの場合は大きな問題とはならないでしょう。しかしそうでない場合は、次のような問題が発生する可能性があるため、State ファイルをローカルに保存することは推奨されません。 チームで協力して作業する場合、複数の人が State ファイルにアクセスする必要がある State ファイル内のデータはプレーンテキストで保存されるが、そこには機密情報やセンシティブな情報が含まれる可能性がある ローカルファイルは紛失したり、破損または削除される可能性がある State ファイルの取り扱いにおけるベストプラクティス Terraform の組み込み機能としてサポートされているリモートバックエンド機能を利用して State ファイルをリモート管理することが推奨されます。 Amazon Simple Storage Service(Amazon S3) 上のリモートバックエンド: 耐久性とスケーラビリティに優れたストレージである Amazon S3 バケットに State ファイルを保存するように Terraform を設定できます。Amazon S3 に保存することで、State ファイルを他のユーザーと共有してコラボレーションすることも可能になります。 Amazon S3 上のリモートバックエンドと Amazon DynamoDB の利用 : Amazon S3 バケットを利用してファイルを管理することに加え、 Amazon DynamoDB テーブルを利用してState ファイルのロックを管理することもできます。特定の State ファイルを変更できる人を常に 1 人だけに限定してコンフリクトを回避し、State ファイルへの同時アクセスを安全に制御できます。 他にも Terraform Cloud 上のリモートバックエンドやサードパーティのバックエンドなどの選択肢があります。 AWS 上で Terraform State ファイルを管理するためにどんな方法が最適かは、固有の要件によって異なるといえるでしょう。 AWS 上で Terraform を利用してデプロイする際に、State を管理するために Amazon S3 と Amazon DynamoDB を使用する方法はお勧めの選択肢です。 State ファイルの管理のための AWS 設定 Terraform を利用して Amazon S3 バケットを作成します。 AWS Identity and Access Management (AWS IAM) ポリシー や Amazon S3 バケットポリシー を設定して Amazon S3 バケットのセキュリティ対策を実装します。アクセスを制限したり、データの保護やリカバリーのためにオブジェクトのバージョニングを設定したり、SSE-KMS を利用した AES256 暗号化を有効にしたりできます。 次に、Terraform を利用して、パーティションキーを LockID に設定した Amazon DynamoDB テーブルを作成します。読み取りキャパシティユニット/書き込みキャパシティユニットなどの追加の構成オプションも設定できます。テーブルが作成されたら、設定ファイルの中の terraform ブロックでテーブル名を指定して、State ロックでそのテーブル使用するように Terraform バックエンドを構成します。 単一の AWS アカウントの中に複数の環境やプロジェクトが存在している場合、単一の Amazon S3 バケットでそれらの State の管理ができます。 複数の AWS アカウントにまたがって環境やアプリケーションが存在するような場合は、アカウントごとに Amazon S3 バケットを作成して State の管理ができます。 この Amazon S3 バケット内で環境ごとに適切なフォルダを作成し、個別にプレフィックスを付加して State ファイルを格納できます。 AWS で Terraform の State ファイルを扱う方法がわかったので、次は AWS 上の 継続的インテグレーション パイプラインでこれらを設定する例を見ていきましょう。 アーキテクチャ 図1: AWS 上の CI パイプラインで Terraform を使用するサンプルアーキテクチャ この図は、このブログで実装されるワークフローの概要を示しています。 AWS CodeCommit リポジトリでコードを管理する (ここには Lambda などのアプリケーションのコードも含まれる) AWS CodeBuild ジョブは どの buildspec ファイルを使うかの設定を保持しており、AWS CodeCommit のソースコードを参照して動作する terraform apply の実行によって作成された AWS Lambda 関数には、同じリポジトリで管理されたアプリケーションコードが実装される Amazon S3 には terraform apply の実行で作成された State ファイルが保存される Amazon DynamoDB は Amazon S3 にある State ファイルのロックを管理する 実装 前提条件 始める前に、次の前提条件を満たしている必要があります。 AWS Command Line Interface(AWS CLI) の最新バージョンが インストール されている Terraform の最新バージョンが インストール されている Git の最新バージョンが インストール されており git-remote-codecommit がセットアップ されている 使用するAWS アカウントの準備ができている (既存の AWS アカウント、もしくは 新規作成 ) ローカルターミナルから AWS アカウントにアクセスできるように AWS IAM や AWS CLI の設定 がされている 環境の設定 AWS CLI を設定するには、AWS アクセスキー ID とシークレットアクセスキーが必要です。AWS CLI の設定の詳細については、 こちらの説明 を参照してください。 次のコマンドで、サンプルコード全体を含むリポジトリをクローンしてください。 git clone https://github.com/aws-samples/manage-terraform-statefiles-in-aws-pipeline クローンすると、次のようなフォルダ構成が確認できます。 図2: AWS CodeCommit リポジトリ構成 Terraform のコードを 2 つのパートに分けてみましょう。1 つはインフラストラクチャの準備用、もう 1 つはアプリケーションの準備用です。 インフラストラクチャの準備 main.tf ファイルは以下を行うコアコンポーネントです。 State ファイルを保存するための Amazon S3 バケットを作成します。バケットの ACL、バージョニング、暗号化を設定することで、 State ファイルをセキュアに管理することができます。 State ファイルをロックするために使用する Amazon DynamoDB テーブルを作成します。 2 つの AWS CodeBuild プロジェクトを作成します。1 つは terraform plan を実行するもので、もう1 つは terraform apply を実行するものです。 注記: 後で使用する AWS Lambda を作成するコードブロック(デフォルトではコメントアウトされている)も含まれています。 AWS CodeBuild プロジェクトは、Amazon S3、Amazon DynamoDB、AWS CodeCommit、AWS Lambda にアクセスできる必要があります。 これらのリソースにアクセスするために必要な権限を持つ AWS IAM ロールを iam.tf ファイルで作成します。 terraform コマンド terraform plan と terraform apply をそれぞれ実行する buildspec-plan.yaml と buildspec-apply.yaml という 2 つの buildspec ファイルがあります。 provider.tf ファイル内の AWS リージョンの設定を変更します。 (翻訳者補足: 作業中のAWS 環境に合わせて、必要であれば変更してください。) variable.tf ファイルで、Amazon S3 バケット名、Amazon DynamoDB テーブル名、AWS CodeBuild コンピュートタイプ、AWS Lambda ロールとポリシー名を必要な値に更新します。このファイルを使って、さまざまな環境に合わせてパラメーターを簡単にカスタマイズすることができます。 これでインフラストラクチャの設定は完了です。 (翻訳者補足: この時点では、 backend.tf には local バックエンド が設定されている必要があります。念のため、設定をご確認ください。) ローカルターミナルを使用して以下のコマンドを順番に実行すると、上記のリソースを AWS アカウントにデプロイできます。 terraform init terraform validate terraform plan terraform apply terraform apply が成功してAWS アカウントに上記のすべてのリソースが正常にデプロイできたら、アプリケーションのデプロイに進みましょう。 アプリケーションの準備 クローンしたリポジトリで、 backend.tf ファイルを使用して、 State ファイルを保存するための独自の Amazon S3 バックエンドを作成します。デフォルトでは以下の値が設定されます。必要に応じてこれらの値を更新します。 (翻訳者補足: ここでは「インフラストラクチャの準備」のセクションで作成した s3 バケットを指定してください。リージョンも同セクションにて provider.tf ファイルで変更している場合は同じ設定にしてください。) bucket = "tfbackend-bucket" key &nbsp; &nbsp; = "terraform.tfstate" region = "eu-central-1" このリポジトリにある main.py ファイルには、呼び出されたときにシンプルなメッセージを返す Python コードのサンプルがあります。 main.tf ファイルには、 main.py ファイルのコードを使用して Lambda 関数を作成およびデプロイするための、以下のコードブロックがあります (これらのコードブロックのコメントを解除してください)。 data "archive_file" "lambda_archive_file" { …… } resource "aws_lambda_function" "lambda" { …… } これで、AWS CodeBuild を利用してアプリケーションをデプロイできるようになりました。もう terraform コマンドをローカルで実行する必要はありません。これが AWS CodeBuild を利用することの最大の利点です。 terraform plan と terraform apply を再度実行するために、それぞれの AWS CodeBuild プロジェクトを起動します。 (翻訳者補足: AWS CodeBuild プロジェクトを起動する前に terraform init -migrate-state コマンドをローカルで実行することで、ローカルに保存されている State を Amazon S3 バックエンド に引き継ぐことができます。コマンドの仕様については ドキュメント を参照してください。) (翻訳者補足: AWS CodeBuild プロジェクトを起動する前に、「インフラストラクチャの準備」で作成した AWS CodeCommit リポジトリにソースコードを Push しておく必要があります。CodeBuild プロジェクトはこのソースコードを参照して動作します。) デプロイが成功したら、作成した AWS Lambda 関数でコードをテストしてみましょう。Lambda 関数をテストする手順は以下のとおりです。(コンソールでの作業になります) AWS Lambda コンソールを開き、関数「tf-codebuild」を選択します。 ナビゲーションペインの Code セクションで、 Test をクリックしてテストイベントを作成します。 イベント名 (例えば「test-lambda」) を指定します。 他はデフォルト値のまま Save をクリックします。 Test を再度クリックして、テストイベント「test-lambda」を起動します。 Lambda 関数は、main.py ファイルに記述してあるサンプルメッセージを返すはずです。 デフォルトでは以下に示すように「Hello from AWS Lambda !」のメッセージが表示されます。 図3: サンプル Lambda 関数のレスポンス State ファイルを確認するには、Amazon S3 コンソールに移動し、作成されたバックエンドバケット ( tfbackend-bucket ) を選択してください。 State ファイルが含まれているはずです。 (翻訳者補足: ここでは「インフラストラクチャの準備」のセクションで作成した s3 バケットを選択してください。) 図4: Terraform の State ファイルが保存された Amazon S3 バケット Amazon DynamoDB コンソールを開き、テーブル tfstate-lock を確認してみてください。LockID を持つエントリがあるはずです。 図5: LockID を持つエントリが登録された Amazon DynamoDB テーブル このように、継続的インテグレーションパイプラインから Terraform のリモートバックエンドを利用して、 Terraform State ファイルを安全に保存しロックすることができました。 クリーンアップ リポジトリから作成されたすべてのリソースを削除するには、ターミナルから以下のコマンドを実行してください。 terraform destroy まとめ このブログ記事では、Terraform の State ファイルの基本を掘り下げ、AWS 環境内での安全な保存のためのベストプラクティスと、ファイルをロックして不適切な同時アクセスを防ぐメカニズムについて説明しました。そして最後に、AWS 上の継続的インテグレーションパイプラインで、それらをいかに効率的に管理できるかの例を示しました。 AWS 上の 継続的デリバリー パイプラインでも、State ファイルを管理するために同じ方法が適用できます。 より詳細を知りたい場合は、 AWS での CI/CD パイプライン 、 Terraform バックエンドの種類 、 Terraform State の目的 をご覧ください。 著者について Arun Kumar Selvaraj Arun Kumar Selvaraj は AWS Professional Services の Cloud Infrastructure Architect です。彼は thought leadership、運用基準、プラットフォームを提供する世界クラスの能力を開発し、お客様に迅速な移行と成長パスを提供することに情熱を注いでいます。Migration, CCoE, IaC, Python, DevOps, Containers and Networking などの分野に興味があります。 Manasi Bhutada Manasi Bhutada はオランダを拠点とする ISV Solutions Architect です。お客様のビジネス上の課題に対処するために、AWS での Well-Architected なソリューションの設計と実装を支援しています。Data Analytics と Networking の分野に情熱を注いでいます。仕事以外では、さまざまな食べ物を試してみたり、ピックルボールやボードゲームをプレイすることを楽しんでいます。 本記事は 2024/02/19 に投稿された Best practices for managing Terraform State files in AWS CI/CD Pipeline を翻訳したものです。翻訳は Solutions Architect : 国兼 周平 (Shuhei Kunikane) が担当しました。

はじめに 組織がクラウド上でワークロードのモダナイゼーションを進めるにあたり、その ジャーニー を成功に導くためには重要となる「能力」の習得を必要とします。その能力には、組織構造、モダナイゼーション戦略、自動化、チームの成熟度合い、利害関係者のスポンサーシップなどが含まれます。このなかで、自動化は、特にアジリティ、スケーラビリティ、運用効率といったモダナイゼーションのメリットを実現する上での非常に大きな役割を果たします。 しかし、「自動化」は人によってさまざまな解釈があるでしょう。この記事における自動化とは、特定の成果を達成するために手作業に代わってコードと構成を用いて作業を行うツールとプロセスを指すということを、はじめにあわせておきましょう。 この記事では、特定の問題に対する早急な解決策ではなく、戦略的な実現手段としてクラウドの自動化を認識し、活用する効率的なデリバリー・モデルを構築するためのガイダンスをIT リーダーに提供していきます。 導入フェーズにおける自動化の目標 一般的に、モダナイゼーションプログラムの導入フェーズでは、ビジネス目標、スコープ、予算、組織構造、テスト戦略の定義に重点が置かれます。自動化戦略は、戦略的な計画の要素というよりは戦術的な活動とみなされるため、導入フェーズでは見落とされがちであり、含まれないことが頻繁にあります。その結果、モダナイゼーション戦略の大きな文脈において、自動化を推進するのに必要な注意が払われず、それにより、自動化が、計画や実装の段階で後回しにされることになります。自動化戦略は、モダナイゼーションプログラムの導入フェーズにおける重要なアウトプットであるべきであり、明確な自動化の目標が定義され、モダナイゼーションプログラムの目標に対して合致しているべきです。計画フェーズでは、自動化戦略からもっと拡げ、自動化のアプローチ、予算、および実装計画（設計、開発、テスト、デプロイメント、および運用を含む）を含めます。自動化計画は、重要なマイルストーンに対する主要な相互依存関係を組み込んだ上で、モダナイゼーションプログラム（図1 参照）と並行して進めるべきです。 図1：計画フェーズのアウトプット 運用モデル アプリケーション開発チームのミッションは、ビジネス機能を迅速に提供することに集中することであり、自動化は必ずしも優先事項ではありません。開発ライフサイクルを加速させるため、自動化機能を構築することを最優先する、別のチームの創設を検討しましょう。自動化チームと開発チームは、共通のビジネス目標を達成するために、プログラム全体のタイムラインと整合する相互依存の機能として運営されます。 組織のアジャイルと DevOps の実践は、図2 に示すように、開発ライフサイクル全体を通じて、モダナイゼーションの成果に対して共有オーナーシップを持つ開発チームと自動化アジャイルチーム間の機能横断的なコラボレーションを促進する必要があります。このアプローチは、より迅速なフィードバック・ループと継続的なインテグレーションを促し、チーム・メンバー間で共有の責務として、モダナイゼーションの成果を重視することになります。 図2：チーム構造 開発チームと自動化チームの間で職務を分離することで、利害の衝突を防ぎ、チームが定義された自動化プロセス以外のタスクを実行する可能性を減らすことができます。明確なポリシーを確立し、期待事項を伝え、定期的にアクセス制御を見直し、更新することが極めて重要になります。一般的なガイドラインとして、すべての環境構築、デプロイメント、コンフィギュレーション、データロードは、自動化プロセスによって実行されるべきでしょう。 自動化チームを編成するには、2 つの方法があります。1 /共通チーム： このアプローチでは、一元化された自動化チームが、組織全体の自動化ニーズに対応します。このアプローチは、組織が集中型DevOps 戦略をとっている場合に採用されます。これには、統一された自動化ツールとプロセスによる集中化したデプロイメントパイプラインが含まれます。2 /専任チーム： このアプローチでは、特定のモダナイゼーションのイニシアチブまたはプログラムの自動化を構築するために、専任の自動化チームが編成されます。このチームは、イニシアチブないしプログラムのための自動化の実装が完了後、最終的に集中型DevOps チームに統合されます。 自動化戦略 – エンド・ツー・エンドの自動化 組織は、開発ライフサイクル全体にわたるエンド・ツー・エンドの視点から自動化戦略を定義する必要があります。自動化ツールチェーン（ツールとプロセスを含む）をソフトウェアライフサイクル全体で構築します。ツールチェーンには、環境構築、開発、バージョン管理、継続的インテグレーション、コード品質、継続的デプロイメント、コンテナ化、モニタリング、コラボレーション、テストを含めます。 クラウド・セキュリティの自動化は、クラウド環境の動的な性質がもたらす課題に対処するために非常に重要です。自動化は、セキュリティ・ギャップのプロアクティブな特定と解決、パッチ管理、脅威の検出、インシデント対応によって、セキュリティとコンプライアンスを迅速かつ大規模に維持するのに役立ちます。 高度なアクセスを必要とせずに、アプリケーションとインフラストラクチャのパフォーマンス、信頼性、セキュリティを監視し、最適化するための自動化された可観測性ソリューションを構築します。これにより、チームは各環境を可視化し、プロアクティブな監視によって問題を軽減し、運用効率を向上させることができます。 効率的かつ効果的なワークフローを構築するには、適切なツールの組み合わせを選択することが重要です。ツールチェーンに選択するツールは、相互運用性に優れ、ライフサイクルを通じて統合されたユニットとして機能する必要があります。図3 は、統合されたエンド・ツー・エンドのツールを提供するAWS サービスを利用したツールチェーンのサンプルを示しています。 図3：AWSサービスを活用したサンプルのツールチェーン 自動化の効果測定 自動化の目的は多様であり、主要な指標を測定することが可能であるため、自動化の効果を測定することは複雑な作業になります。しかし、自動化の成果を測定することは不可欠といえます。適切な測定基準を追跡し、データに基づいた意思決定を行うことで、組織は自動化の効果を改善し、望ましい結果を得ることができます。以下は、自動化の効果を測定するために使用される一般的な測定基準です： コスト削減： 手動オペレーションの削減、生産性の向上、リソース利用の最適化によるコスト削減を測定します。人件費、インフラストラクチャー費用、運用経費などの要素を含めます。 時間の削減： 環境のプロビジョニング、コード開発、テスト、デプロイメントなど、特定のタスクやプロセスを完了するために、短縮できた時間を測定します。 欠陥率： 人的介入の最小化による精度の向上を指します。 手作業によるプロセスで発生していた不具合の削減を測定します。 生産性： 自動化により改善した生産性の向上を測定します。特定の時間内に完了したタスク、トランザクション、オペレーション数を評価します。 品質： 自動化によって達成されたアウトプットの品質向上を評価します。標準への準拠、コンプライアンス、顧客満足度などの要素を測定します。 プロセス・サイクル・タイム：自動化によるプロセス・サイクル・タイムの短縮を測定します。特定のプロセスやワークフローの開始から終了までにかかる時間を計算します。 投資利益率（ROI）： 発生したコストと得られた利益を比較することにより、自動化の取り組みにおけるROI を計算します。コスト削減、生産性の向上、効率性の向上、市場投入までの時間などの要素を考慮します。 さらに、 DevOps メトリクス を使用して自動化の有効性を測定することができます。 成熟度モデル 多くの組織では、成熟度モデルを用いて自動化の現状を評価するのが一般的です。成熟度モデルは、自動化のゴールを設定し、自動化に向けたロードマップを策定し、自動化における投資の優先順位を決めるための良いガイドとなります。一般的に、組織は、それぞれのニーズに合わせて成熟度モデルをカスタマイズするのが良いでしょう。 以下は、クラウドにおける自動化の成熟度を評価するために使用できるモデル（図4 ）になります。 図4：成熟度モデル 自動化メトリクスと成熟度モデルは、互いに連携して使用されます。成熟度レベルごとに、定量的なしきい値の範囲とともに、使用する具体的なメトリクスを定義します。自動化の成熟度レベルを検証するために、定期的な監査を実施します。これにより、チームは自動化の全体的な有効性を測定することができ、その結果、改善点を特定し、自動化のゴールの優先順位を決定することができます。 自動化におけるAI AI とML ツールが成熟し、生成AI が登場したことで、自動化に関するあらゆる可能性が広がりました。AI 機能は、インテリジェントな洞察、予知保全、自動インシデント対応、自己修復を提供する自動化システムの提供を可能にします。 生成AI により、意思決定にインテリジェンスと柔軟性を加えることで、自動化を次のレベルに引き上げ、以前は自動化には複雑すぎると考えられていたプロセスを変革することができます。生成AI が自動化に適用される例としては、文書化、スクリプトとコードの生成、コンプライアンス・レポート、セキュリティ・ギャップの特定と修正、自動化されたインシデント対応などがあります。 自動化におけるAI は進化する能力であり、新しいユースケースやチャンスが定期的に発見されます。AI を使用することで、組織は成熟度モデルを加速度的に通過し、ビジネス価値をより迅速に推進することができるようになるでしょう。 リスクと課題 自動化には多大なメリットがある一方で、リスクや課題もあります。自動化に過度に依存すると、人による監視が低下し、障害や意図しない結果を引き起こす可能性があります。複雑な自動化の実装は、保守が困難でIT 予算を浪費する扱いにくいソリューションの原因ともなります。 これらのリスクを軽減するために、組織は、計画的かつ十分に考え抜かれたアプローチに基づいて、自動化戦略を定義する必要があります。モニタリングやテストなど、自動化プロセスの定期的な監査を実施します。状況の変化に基づき、自動化プロセスを常に最新に保ちます。最後に、自動化に失敗した場合は、手動プロセスを導入します。自動化から必要な利益を得るためには、自動化とそれに伴うリスクのバランスを保つことが重要となります。 最後に 自動化は、開発ライフサイクルの生産性、効率性、信頼性を大幅に向上させ、それにより、チームはイノベーションと価値提供に集中することができます。自動化は、重要なマイルストーンを定義し、成熟度モデルに照らして測定することで、戦略的なアウトプットとして考えることができます。自動化は、プロジェクトの導入フェーズから実装まで注意を払う必要があるジャーニーです。自動化はそれ自体がアウトプットであり、重要なイネーブラー（成功要因）であることを念頭におき、モダナイゼーションに取り組みましょう。 参考文献 AWS CaseStudy – Botprise Reduces Time to Remediation by 86% on Average Using Automation and AWS Security Hub https://aws.amazon.com/solutions/case-studies/botprise-case-study/?did=cr_card&amp;trk=cr_card Customer CaseStudy – On-Demand Infrastructure on AWS Helps Capital One DevOps Teams Move Faster Than Ever https://aws.amazon.com/solutions/case-studies/capital-one-devops/ AWS. DevOps practices and tool and use cases. https://aws.amazon.com/devops/ AWS. (10 Jul 2023 ) Automated Code Review on Pull Requests using AWS CodeCommit and AWS CodeBuild &nbsp; https://aws.amazon.com/blogs/devops/automated-code-review-on-pull-requests-using-aws-codecommit-and-aws-codebuild/ AWS. (30 May 2023) Optimize software development with Amazon CodeWhisperer https://aws.amazon.com/blogs/devops/optimize-software-development-with-amazon-codewhisperer/ AWS. (04 May 2023) The history and future roadmap of the AWS CloudFormation Registry https://aws.amazon.com/blogs/devops/cloudformation-coverage/ AWS. (22 Dec 2022) Multi-branch pipeline management and infrastructure deployment using AWS CDK Pipelines https://aws.amazon.com/blogs/devops/multi-branch-pipeline-management-and-infrastructure-deployment-using-aws-cdk-pipelines/ AWS. (13 Dec 2022) Using Workflows to Build, Test, and Deploy with Amazon CodeCatalyst https://aws.amazon.com/blogs/devops/using-workflows-to-build-test-and-deploy-with-amazon-codecatalyst/ 著者について Swaroop Prabhakaran クラウド導入とデジタルトランスフォーメーションにフォーカスした結果重視型のリーダーです。ビジネスリーダーやIT リーダーと協力してイノベーションを加速させ、ビジネス成果を上げることに情熱を注ぎます。ビジネスおよびIT 組織全体で高いパフォーマンスを発揮するチームを率いながら、収益拡大を推進するためのプログラムマネジメントに豊富な経験を持ちます。 Nishant Singh 流通、消費財メーカー、デジタルバンキングを専門とするAWS のシニアカスタマーソリューションマネージャー（CSM）です。AWS を活用し、顧客のビジネス成果につながる新たな価値主導型ソリューションの構築を支援することに情熱を注ぎます。 この記事は、ソリューションアーキテクトの平岩梨果が翻訳を担当しました。原文は こちら です。

はじめに クラウドへのマイグレーションは、IT 環境をモダナイゼーションするための第一歩です。マイグレーションを完了することで、企業はよりモダンで、俊敏かつセキュアなIT 環境の基盤を築くことができます。しかし、多くの企業では、マイグレーション中に築かれた最初の勢いが減速し、行き詰まることが多々あります。クラウド導入の真の価値は、その後のアプリケーションと開発手法のモダナイゼーションにあり、魅力的なメリットを引き出すことにあります。組織は、モダナイゼーションの顧客への提供価値を明確にし、それを明確なビジネス成果に結びつけるのに苦労することが多いと言えます。 この記事では、当初のマイグレーションの勢いを維持しながら、クラウド導入のメリットを最大化するため、モダナイゼーションフェーズに進化するためのベストプラクティスを紹介します。 モダナイゼーションのメリット モダナイゼーションは、最新のテクノロジー、 クラウドネイティブ なアーキテクチャ、ソフトウェアデリバリーの実践、および運用プロセスを組み合わせることで、ビジネス目標をより迅速かつ一貫性を持って実現します。モダナイゼーションは、リフト＆ シフトのマイグレーションにとどまらない、さらに多くのメリットを引き出します。 スケーラビリティ ：モダナイズされたアプリケーションは、変化する需要に合わせて動的に拡張できるため、従来のモノリシックなアプリケーションに比べてパフォーマンスと可用性が向上します。さらに重要な点として、アプリケーションをホストするプラットフォーム全体ではなく、追加容量を必要とする特定のコンポーネントのみを拡張する能力を備えます。 コスト効率性 ：クラウドネイティブなテクノロジーとマネージドインスタンスを活用することで、インフラストラクチャとライセンスに関連するコストを削減できます。きめ細やかなレベルでリソースを効率的に活用できるため、全体的な費用の削減が可能です。 信頼性 ：モダナイズされたアプリケーションは、本質的にクラウド ネイティブ なテクノロジーを使用して設計されています。そのため、回復力があり、地理的に分散され、自己修復するように設計されており、ダウンタイムが削減され、全体的な信頼性が向上します。 イノベーションのスピード ：新機能の市場投入スピードが早くなり、新しいアイデアのテストや新機能の迅速な導入が容易になります。これにより、市場の変化に迅速に対応し、顧客からのフィードバックループを減らし、競争優位性を維持することができます。 インテグテーション ：クラウドネイティブなアプリケーションは、他のクラウドサービスと容易に統合できるため、より複雑で高度なシステムをシームレスに構築できます。 運用の効率化： クラウドネイティブなアプリケーションは、サーバーレスまたはマネージドインスタンスで管理・監視できるように設計されているため、バージョンアップ、パッチ適用、セキュリティ管理のために必要な複雑な作業と労力が軽減されます。生産性が向上し、組織は顧客への価値提供に集中できます。 モダナイゼーションを成功させるためのベストプラクティス 組織がモダナイゼーションジャーニーに取り組む際、モダナイゼーションプロジェクトを成功させるために推奨されるベストプラクティスがいくつかあります。これらの対策は、モダナイゼーションに向けた一貫性のある協調的な取り組みを確実に実施し、全体的な戦略とビジネス上の利益が途中で失われないようにするために重要です。 ステークホルダーの関与 ：すべてのモダナイゼーションの取り組みにおいて、ビジネス部門のステークホルダーだけでなくIT 部門のステークホルダーを持つことが重要です。ステークホルダーは、顧客の期待値の管理、ビジネス目標との整合、チェンジマネジメント、およびビジネスプロセスの変更への影響において重要な役割を果たします。ステークホルダーの関与は、モダナイゼーションの目標を達成するために不可欠です。 「大きく考え、小さく始める」 ：これは、組織がより多くのことを達成するために、限界を超えて挑戦的な目標を設定することを可能にする強力なマインドセットです。目標をより小さく、管理しやすいマイルストーンに分割することで目標を達成し、プロセス、リソーススキル、およびモダナイゼーションのアプローチ全体の強みを効果的に評価することができます。 組織の構造 ：マイグレーションフェーズで定義されたクラウド運用モデルは、IT 組織をクラウドに移行させるという非常に具体的な目的を果たすものでした。組織がモダナイゼーションフェーズに移行する際には、運用モデルを評価し、全体的なビジネス目標とモダナイゼーションの目的に基づいて調整することが重要です。クラウド運用モデルの有効性を定期的に測定し、組織の特定のニーズを満たすことを目的として、必要に応じて調整する必要があります。 自動化 ：自動化は、組織がモダナイゼーションのメリットをフルに享受するのに役立ちます。自動化により、新しいサービスの市場投入までのスピードが向上し、手動による介入を最小限に抑えた迅速な展開が可能になります。自動化によって手作業によるミスが減り、運用に関わる作業から解放されます。 自動化は、Infrastructure as Code（IaC）によるプロビジョニング、アプリケーション開発、テスト、デプロイメント活動など、開発ライフサイクルのあらゆる側面を包含する必要があります。 センター・オブ・エクセレンス ：クラウド・センター・オブ・エクセレンス（CCoE）は、顧客がクラウドモダナイゼーションのためのプロセスを標準化し、パターンを構築するために重要な役割を果たします。CCoE は、クラウドプラットフォームチームだけでなく、ビジネス部門を横断し、アプリケーション開発チームにも拡大する必要があります。CCoE チームは、再利用可能なリファレンス・アーキテクチャを構築し、適用先と使用方法に関するドキュメントを提供します。また、誤使用を防止するために自動化されたガードレールを組み込み、ガバナンスを利かせます。 スキルトレーニング ：社員がモダナイゼーションの準備をすることは、クラウドのトランスフォーメーションジャーニーにおいて重要な側面となります。社員が適切なクラウドネイティブツールに関する必要なスキルセットを習得していない場合、アプリケーションのモダナイゼーションに時間がかかり、品質が低下することにつながります。スキルはピアツーピアモデル（個々人が直接コミュニケーションできること）で習得できることが最善であり、組織内のコミュニティ構築が、成功のための重要な要素となります。 モダナイゼーション戦略 適切なモダナイゼーション戦略を定義することは、ビジネス成果を達成し、クラウドのメリットを最大化し、技術的負債を回避するために不可欠です。アプリケーションのワークロードを評価し、依存関係、インテグレーションパターン、パフォーマンス要件、およびビジネス価値などを考慮しながら、モダナイゼーションの候補を特定します。モダナイゼーション戦略は、図1 に示すモダナイゼーションのへ移行パスの1 つないし複数を選択することで実現できます。これらの移行パスは、単発のモダナイゼーションプロジェクトとして、またはクラウド移行の一部として実装することができます。 図1：モダナイゼーションへの移行パス 組織にとって適切なモダナイゼーションの移行パスは、アプリケーションの古さや複雑さ、予算、ビジネス目標など、さまざまな要因によって異なってきます。モダナイゼーションの目標を達成するには、以下のパターンの1 つ以上を選択することができます。 マイクロサービス ：アプリケーションがモノリシックで大規模かつ複雑な場合は、マイクロサービスの候補になります。マイクロサービスは、モノリシックなアプリケーションを独立したコンポーネントに分解するアーキテクチャです。マイクロサービスは、各コンポーネントを独立して拡張・管理できる柔軟性を提供します。 サーバーレスコンピューティング ：イベントドリブンであったり、変化しやすいワークロードを含んでいたり、短期間のプロセスがあるアプリケーションは、サーバーレスコンピューティングの良い候補となります。これにより、チームはサーバーのプロビジョニングや管理を行うことなくアプリケーションを構築できます。また、運用コストを削減しながら俊敏性を高めることができます。 マネージドサービス ： 目的別データベース などのマネージドサービスは、クラウドプロバイダーが最適化、スケーリング、信頼性などのインフラストラクチャを管理します。このアプローチにより、チームは基盤となるクラウドインフラストラクチャを管理することなく、効率性の向上、運用コストの削減、セキュリティの向上を実現できます。 コンテナ化 ：このアプローチでは、アプリケーションとその依存関係が、それぞれ独立したコンテナにパッケージ化され、ポータビリティ性と拡張性が向上します。コンテナ化の主なユースケースは、既存製品として販売されているアプリケーション、IoT デバイス、マイクロサービスコンポーネントです。 IT 環境内のアプリケーションが上記のパターンのいずれか、または組み合わせに当てはまらない場合は、レガシーな状態のままにしておきます。モダナイゼーションは、コスト削減、俊敏性、回復力の向上により、ビジネス価値を高める手段です。アプリケーションをモダナイゼーションすることに真のビジネス価値がない場合は、レガシーのままにしておいても問題ありません。 ビジネスケースの構築 ビジネスケースを、モダナイゼーション全般のビジョンと企業のビジネス目標に合致させておくことが重要です。モダナイゼーション戦略は組織レベルで定義され、実装はアプリケーションレベルで実現されますが、モダナイゼーションの完了には一般的に時間がかかるため、ビジネスケースは各ビジネス部門またはアプリケーショングループに合わせて調整する必要があります。 ビジネスケースを作成する際の主な考慮事項を以下に示します： アジリティとイノベーションの実現 ：モダナイゼーションによってビジネスの俊敏性がどのように向上し、イノベーションがどのように可能になるかを明確にします。開発・デプロイメント時間、拡張性、弾力性、市場投入までの時間、信頼性の向上に基づいてアジリティを評価します。 リスクの評価 ：モダナイゼーションプロジェクトに関連する潜在的なリスクおよび課題を特定するリスク評価を含めます。リスクは、技術の成熟度、ビジネスへの対応、ステークホルダーのコミットメント（ビジネスと IT）、チェンジマネジメントといった側面から評価します。 成功の測定 ：モダナイゼーションの取り組みに期待される成果を要約し、成功を測定するための明確なKPI を設定します。KPI は、レガシーシステムとの比較に使用できる明確な測定基準を持つ定量的なものとします。 所有コストの削減 ：コスト削減は、顧客がモダナイゼーションに向かうための重要な要素です。アプリケーションの各側面の ユニットメトリックコスト と、モダナイズされたソリューションの推定ユニットコストを比較します。ユニットメトリックコストの比較には、コンピュート、ストレージ、ネットワーク帯域幅、API とトランザクション、ライセンス料金、回復力、バージョンアップとバグ修正、および市場投入までの時間を含める必要があります。 最後に モダナイゼーションは終わりのないジャーニーであり、マイグレーションでとどまるべきではありません。クラウドは、データセンターの代替として扱うのではなく、企業が競争優位性を獲得するために活用すべき機能です。モダナイゼーションは、人・組織、プロセス、テクノロジーを横断する熟考戦略であるべきです。モダナイゼーションの最終的な目標は、イノベーションを起こしながらビジネスの成長を推進し、機敏でかつコスト効率に優れた組織へと変革することにあります。 参考文献 AWS. (2021, November 22).&nbsp;An Overview of the AWS Cloud Adoption Framework.&nbsp; https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/overview-aws-cloud-adoption-framework.pdf AWS. (2022, Jul 14). Tracking the Effectiveness of Cloud Adoption https://aws.amazon.com/blogs/enterprise-strategy/tracking-effectiveness-of-cloud-adoption/ AWS. (2023, Jun 19). Navigating the Cloud Migration Bubble: Turning Your Bubble into a Blip https://aws.amazon.com/blogs/enterprise-strategy/navigating-the-cloud-migration-bubble-turning-your-bubble-into-a-blip/ AWS. (2023, May 09). What is a cloud center of excellence and why should your organization create one? https://aws.amazon.com/blogs/publicsector/what-is-cloud-center-excellence-why-should-your-organization-create-one/ AWS. (2023, Apr 21). Business Value is IT’s Primary Measure of Progress https://aws.amazon.com/blogs/enterprise-strategy/business-value-is-its-primary-measure-of-progress/ AWS. (2021, Feb 23). What is a unit metric? https://aws.amazon.com/blogs/aws-cloud-financial-management/what-is-a-unit-metric/ 著者について Swaroop Prabhakaran クラウド導入とデジタルトランスフォーメーションにフォーカスした結果重視型のリーダーです。ビジネスリーダーやIT リーダーと協力してイノベーションを加速させ、ビジネス成果を上げることに情熱を注ぎます。ビジネスおよびIT 組織全体で高いパフォーマンスを発揮するチームを率いながら、収益拡大を推進するためのプログラムマネジメントに豊富な経験を持ちます。 Nishant Singh 流通、消費財メーカー、デジタルバンキングを専門とするAWS のシニアカスタマーソリューションマネージャー（CSM）です。AWS を活用し、顧客のビジネス成果につながる新たな価値主導型ソリューションの構築を支援することに情熱を注ぎます。 この記事は、ソリューションアーキテクトの平岩梨果が翻訳を担当しました。原文は こちら です。

By Kazuki Motohashi, Ph.D., Partner Solutions Architect, AI/ML – AWS Japan&nbsp; By Yuji Arakawa, Sr. Enterprise Architect, Partner Core Tech&nbsp;– AWS Japan 本稿では、スケーラブルでありながらもコスト効率に優れる Pinecone serverless ベクトルデータベースを Amzon Bedrock のナレッジベースとして利用することでビジネスが生成 AI による新しい体験を迅速にユーザーへ届けることができることを紹介します。RAG (Retrieval Augmented Generation; 検索拡張生成) やベクトルデータベースを活用するアイデアを持ちながらもコストへの懸念やシステム構築の手間から次の一歩をためらっている企業・政府機関などの組織にとって生成 AI ジャーニーへの船出の一助となることを願っています。 はじめに 生成 AI は、人々の生活を豊かにする新しい体験を提供したり、ビジネスの生産性向上と新たな事業機会を生み出すテクノロジーとして期待されています。既存のアプリケーションやサービスに組み込んでユーザー体験を改善したり、全く新しいアプリケーションやサービスの実装など様々な取り組みが進んでいます。生成 AI を活用する際には、最新で正確な情報に基づいたユーザー体験を提供することが求められます。企業や政府機関などの組織においてはセキュリティや知的財産権と並んで重要なテーマとなっています。 RAG・検索拡張生成とは RAG を使用すると、エンタープライズ検索、データベース、API などの外部知識ソースからデータを取得して、それを元に大規模言語モデル (LLM) により質問への回答生成のようなテキスト生成を行うことができます。質問応答のために生成 AI を使用する場合、RAG の仕組みにより、質問のクエリと最も関連性の高い最新の情報で回答を行います。さらに、その回答が正しいかユーザーが検証できるよう、データソースを引用として表示することもできます。 RAG では、外部の知識ソースとして企業・組織の内外のリレーショナル・データベースや API などを活用することに加えて、蓄積された文書などの膨大な非構造データから知識を検索したり洞察を得るために自然言語を使ったセマンティックサーチができるベクトルデータベースが注目されています。 ベクトルデータベースを使った RAG ソリューションでは、一般に次のようなプロセスが取られます。まず事前の準備として知識ソースのデータを元にベクトルデータベース上にナレッジベースを構築します。最初のステップでは、元のデータを検索に適した小さなセグメントに分割します。このセグメントはチャンクと呼ばれ、このステップはチャンキングと呼ばれます。次に、チャンクをセマンティックサーチが可能なベクトルデータへ変換します。この変換は埋め込み (embedding) モデルを使って行われます。埋め込みモデルは、単語や文章などのテキストデータを、高次元のベクトル空間内の点として表現します。この空間内では、意味的に類似したテキストデータは近くに位置するように学習されます。つまり、似た意味を持つ文章は、ベクトル空間内で近くに位置することになります。このようにして得られたベクトル表現を使うことで、2 つの文章の類似度を計算することができます。次に、このベクトル表現をベクトルデータベースの索引 (index) に登録することでナレッジベースが構築されます。 ナレッジベースから知識を検索したり洞察を得るためにユーザーが質問をすると、その質問文も同じ埋め込みモデルでベクトル化されます。そして、索引の中のベクトル化された文書群から、この質問のベクトルと最も近い文書 (単一、もしくは、複数) が検索されます。次に、検索された関連文書とユーザーの質問を組み合わせたプロンプト (指示文) を用いて LLM に最終的な回答を生成させます。つまり、この RAG システムには埋め込みモデルと LLM の 2 つのモデルが組み合わさっており、埋め込みモデルが関連文書の検索のために利用され、LLM が回答文を生成するという役割分担がなされています。 本稿では、 Knowledge base for Amazon Bedrock と、 AWS Marketplace からサブスクライブして利用できるベクトルデータベースの Pinecone を利用してナレッジベースを構築する手順について紹介します。 Knowledge base for Amazon Bedrock Knowledge base for Amazon Bedrock は、Amazon Bedrock で提供される大規模言語モデルと組み合わせてシンプルな手順で迅速にマネージドな RAG システムを構築することができる Amazon Bedrock の機能です。 Amazon Simple Storage Service (Amazon S3) にアップロードされたデータソースから情報を取得し、その情報をベクトル化してベクトルデータベース上にナレッジベースを構築します。データを検索に適した小さなセグメントへ分割する操作であるチャンキングや、埋め込みモデルを使ったベクトル化はマネージドサービスとして提供されます。お客様はこれらの仕組みを実装・運用する煩わしさから解放されます。 また、ナレッジベースは、 Agents for Amazon Bedrock と容易に統合することができます。これにより、企業や組織内に蓄積されたデータを元に精度の高い情報を回答できる RAG システムや、企業・組織の内外の API とも連携した生成 AI エージェントアプリケーションを迅速に構築することができます。 本稿執筆時点では、Knowledge base for Amazon Bedrock は、 US East (N. Virginia) と US West (Oregon) の 2 つのリージョンで提供されています。また、ベクトルデータベースとして Amazon OpenSearch Serverless 用ベクトルエンジン、 Amazon Aurora 、Pinecone、 Redis Enterprise Cloud をサポートしています。 Pinecone Pinecone は、高次元のベクトルデータを扱うための、クラウドネイティブでスケーラブルなベクトルデータベースです。 ベクトルデータベースの索引の中のからクエリに最も近い文書を検索する際、総当たりのアルゴリズムを用いることもできますが、非常に多くのコンピューティング資源を消費してしまい、大規模なベクトルデータベースではスケーラビリティに問題があります。Pinecone の基本的なアプローチは、ANN (Approximate Nearest Neighbor; 近似最近傍) 検索に基づいており、大規模なデータセット内でより高速にマッチする文書を効率的に見つけ、ランク付けすることができます。 Pinecone は AWS の ソフトウェアパートナー でもあります。 AWS re:Invent 2023 のパートナーキーノートにおいて、アメリカの大手投資ファンド会社である Blackstone と Pinecone の協業に関して取り上げられました。 Pinecone のプライシングプラン 本稿執筆時点では、Pinecone には、フリートライアルの Starter プランと、pod と呼ばれるクラウドリソース (vCPU、RAM、disk) をあらかじめ用意する pod ベースの Standard プラン、Enterprise プラン、そして、あらかじめクラウドリソースを用意せず使用量に基づいて課金される Serverless プラン (プレビュー) があります。Starter、Standard、Enterprise プランについては こちら のドキュメントをご参照ください。Serverless プランについては、 こちら をご参照ください。 Serverless プランでは、あらかじめコンピュート資源やストレージ資源を確保しておく必要がなく、課金は実際に消費した Read units (RUs) 、Write units (WUs)、Storage (GB 単位) に基づいて計算されます。そのため、トラフィックが少ないユースケースにおいても固定費を抑えてコスト効率の良いナレッジベースを構築することができます。例えば、Pinecone 社のホームページに掲載されている RAG ユースケースでは、初期アップロードされたベクトルデータのレコード数が 100 万レコード、月間のクエリ回数、書き込み回数がいずれも 1 万回でメタデータのサイズが 500 バイトである場合の月間コストは、 3.82 ドルと試算されています。詳しくは こちら の Estimate your costs をご参照ください。 本稿では、Pinecone serverless を利用する手順を解説します。 AWS Marketplace で Pinecone serverless をサブスクライブする AWS Marketplace は、AWS 上で動作するサードパーティ製のソフトウェア、データ、サービスを調達し、一元的に管理できるプラットフォームです。AWS Marketplace のカタログには何千ものソフトウェアが掲載されています。イメージとしては、 Amazon.com で Kindle の本を買うような手軽さでソフトウェアの調達を行うことができます。しかも、ソフトウェアの料金は AWS の請求と一元化されます。 多くの企業・組織では、ソフトウェアやサービスを購入する際には、調査、見積もり、稟議、承認、予算確保、サプライヤー選定、口座確認、契約、予算執行 (購入)、納期管理、ライセンス管理などの煩雑な作業が発生します。AWS Marketplace では Marketplace で素早く適切なソフトウェア、サービスを見つけることができる上、既に AWS を利用されていて予算が確保されている場合には、新たな予算確保等のプロセスが不要となり迅速な調達が可能となる場合もあります。また、請求の一元化やソフトウェア資産の管理機能等もあり、調達後にもメリットのあるものとなっています。 はじめに AWS マネジメントコンソール を開いて、上部の検索バーに “marketplace” などと入力し、”AWS Marketplace Subscriptions” を開きます。 図1: AWS マネージメントコンソールから AWS Marketplace Subscriptions へ 左ペインの “製品を検出” を開くと、下図のようなカタログの UI が表示されます。右上の検索バーに “Pinecone serverless” などと入力して、”AWS Marketplace: Pinecone Vector Database – Pay As You Go Pricing” をクリックすると Pinecone の製品ページが開きます 図2: AWS Marketplace で Pinecone serverless を探す 右上の “View purchase options” ボタンを押します。 図3: Pinecone serverless の製品概要 表示される確認画面の “Subscribe” ボタンをクリックします。 図4: Pinecone Vector Database – Pay As You Go Pricing へのサブスクライブ 画面右上に “Set up your account” というボタンが表示されます。このボタンを押すと、ブラウザの新しいタブに Pinecone のユーザー登録画面が表示されます。 図5: AWS Marketplace から Pinecone アカウントセットアップへのリンク 図6: Pinecone サインナップ画面 ユーザー登録が完了すると Pinecone のダッシュボードが表示されます。本稿の執筆時点 (2024年3月5日) では、Pinecone serverless の試用に関して 100 ドルのクレジットが提供されており、その旨を知らせるウィンドウが表示されます。 “Get Started” をクリックします。 図7: Pinecone serverless 試用の 100ドル分の無料クレジットの案内 Project serverless の作成に成功した旨が一瞬表示された後、画面下部に Pinecone の API Key が表示されているのが見えます。“Up to 50x” と表示されているウィンドウの右上の “X” をクリックして閉じます。 AWS Marketplace が表示されているタブに戻ります。“Offer” の下段に “You are currently subscribed to this offer.” と表示されます。表示されていない場合は、ブラウザのリロードを行います。 図8: AWS Marketplace で Pinecone へのサブスクライブが完了し、AWS Marketplace との連携が完了したことを確認 Pinecone の Index を作成する Knowledge base for Amazon Bedrock のセットアップの前に Pinecone の Index を作成します。これは Pinecone のコンソールで行います。Pinecone のダッシュボードが表示されたタブへ戻り “Create Index” をクリックします。 図9: Pinecone の Index 作成 “Create a new Index” 画面で “Name” と “Dimension” を入力します。Dimension は、使用する埋め込みモデル毎に異なります。本稿では、埋め込みモデルとして “Titan G1 Embeddings – Text” を使用するため、Dimension には “1536” を入力します。Knowledge base for Amazon Bedrock の Vector Store の前提条件については、 ドキュメント をご参照ください。 画面中央の “Capacity Mode” が“Serverless (Public Preview)” であることを確認します。また、画面下部には Pinecone Index を作成する AWS リージョンが表示されているので、意図するリージョンであることを確認します (Pinecone serverless はプレビュー中であり、現在は us-west-2 オレゴンリージョンのみに対応しています)。そして、右下の “Create Index” をクリックします。 図10: Pinecone の Index のパラメータ設定 Pinecone Index の作成が完了すると下図のような画面が表示されます。通常、数秒から数十秒程度で完了します。 図11: Pinecone の Index 作成完了の確認とHOST (エンドポイント URL) の確認 Pinecone Index の作成はこれで完了です。Pinecone コンソールに表示されている “HOST” をメモします。Knowledge base for Amazon Bedrock のナレッジベースが参照するベクトルデータベースを指定する際に必要となります。 Pinecone API Key を AWS Secrets Manager へ登録する Pinecone のコンソールの左側ナビゲーションペインで “API Keys” をクリックします。右側の “Actions” にあるコピーアイコンをクリックして、API Key をクリップボードにコピーします。 図12: Pinecone の API Key の確認 AWS マネジメントコンソール を開いているタブに戻り、上部の検索バーに “Secrets Manager” などと入力して AWS Secrets Manager のコンソールを開き、“新しいシークレットを保存する” をクリックします。 図13: AWS Secrets Manager コンソール “シークレットのタイプ” として “その他のシークレットのタイプ” を選択し、“キー“ には apiKey を、”値“ には先程クリップボードにコピーした ”Value“ をペーストします。下図のスクリーンショットではアスタリスクとなっていますが、実際のコンソール上では API Key の値がそのまま表示されます。なお、”キー“ の apiKey は、大文字小文字が区別されるので注意してください。画面右下の ”次“ をクリックします。 図14: AWS Secrets Manager で新しいシークレットを保存する (シークレットのタイプとキー／値のペア) “シークレットの名前” ( pinecone-kb-test など) と“オプションの説明” を入力して、右下の “次” をクリックします。次に表示される “ローテーションを設定 – オプション” は必要に応じて適切に設定し、右下の “次” をクリックします。“レビュー” 画面の内容を確認し “保存” をクリックします。 図15: AWS Secrets Manager で新しいシークレットの設定 下図のような画面が表示されれば、シークレットが正常に登録されています。 図16: AWS Secrets Manager で新しいシークレットの作成完了の確認 作成したシークレットをクリックして、“シークレットの詳細” を表示し、 “シークレットの ARN” をメモします。ナレッジベースが参照するベクトルデータベースを指定する際に必要となります。 図17: AWS Secrets Manager で新しいシークレットの ARN の確認 データソースを準備する Knowledge base for Amazon Bedrock では、Amazon S3 をデータソースとして、S3 バケットにアップロードされたファイルをベクトルデータベースへ取り込みます。ナレッジベースを作成する前にデータソースとなる S3 バケットを作成し、ファイルをアップロードします。 AWS マネジメントコンソール の上部の検索バーに “S3” などと入力して S3 のコンソールを開きます。右側の “バケットを作成” をクリックします。“バケットを作成”の画面が表示されたら “AWS リージョン” を選択 (本稿では、us-west-2 オレゴン) し、“バケット名” を入力して、右下の “バケットを作成” をクリックします。 図18: Amazon S3 にバケットを作成 バケットの作成が完了したら作成したバケット名をクリックすると下図のような画面が表示されます。右側の “アップロード” をクリックします。 図19: Amazon S3 バケットへのファイルアップロード (1) “ファイルを追加” をクリックして、ナレッジベースに登録するファイルを指定します。本稿では、 Amazon Bedrock のユーザーガイドの PDF ファイル をアップロードします。 図20: Amazon S3 バケットへのファイルアップロード (2) – ファイルの追加 右下の “アップロード” をクリックします。アップロードに成功すると、下図のような画面が表示されます。概要欄に表示されている “送信先” (s3://...) をメモしておきます。右上の “閉じる” をクリックします。 図21: Amazon S3 バケットへのファイルアップロード (3) – アップロード完了の確認 ナレッジベースを作成する AWS マネジメントコンソール の上部の検索バーに “Bedrock” などと入力して、Amazon Bedrock のコンソールを開きます。左上のハンバーガーメニューをクリックしてナビゲーションペインを開き、“▼オーケストレーション” の下の “ナレッジベース” をクリックします。 図22: Amazon Bedrock コンソール 右側の “ナレッジベースを作成” をクリックします。 図23: Amazon Bedrock でナレッジベースの作成 (1) ステップ 1 の “ナレッジベースの詳細を入力” 画面で “ナレッジベース名” ( knowledge-base-pinecone-test など) を入力して、右下の “次へ” をクリックします。 図24: Amazon Bedrock でナレッジベースの作成 (2) – 詳細入力 ステップ 2 の “データソースを設定” 画面で “データソース名” ( knowledge-base-pincone-test-data-source など) と “S3 URI” を入力します。“S3 URI” には先ほどの “データソースを準備する” のセクションでメモした S3 URI を指定します (もしくは、 “S3 を参照” をクリックして選択します)。“次へ” をクリックします。 図25: Amazon Bedrock でナレッジベースの作成 (3) – データソースを設定 ステップ 3 では “埋め込みモデル” を選択します。本稿では、“Titan Embeddings G1 – Text” を使用します。他の埋め込みモデルを使用する際には、埋め込みモデルの “ベクトルの次元” と Pinecone Index の “Dimension” が一致している必要があることに注意してください。 なお、使用する埋め込みモデルは、Amazon Bedrock サービスでアクセス権が付与されている必要があります。Bedrock コンソールのハンバーガーメニューからナビゲーションメニューを開き、“モデルアクセス” 画面を開きます。ここで、“アクセスが付与されました” となっていない場合 (“リクエスト可能” となっている場合) は、右上の “モデルアクセスを管理“ をクリックして、モデルアクセスをリクエストします。 図26: Amazon Bedrock でナレッジベースの作成 (4) – 埋め込みモデルを選択 スクロールダウンして、“ベクトルデータベース” を選択します。Pinecone を使用する場合は、 “作成したベクトルストアを選択” を選択し、“既存のデータベースを選択” 欄で “Pinecone” を選択します。また、“Pinecone を選択することにより、….” の条項に同意いただく必要があります。同意される場合は、チェックボックスにチェックマークを入れます。 図27: Amazon Bedrock でナレッジベースの作成 (5) – ベクトルデータベースを選択 さらにスクロールダウンし、“エンドポイント URL” に “Pinecone の Index を作成する” のセクションの最後にメモした “HOST” の URL を入力します。また、“認証情報シークレット ARN” には、“Pinecone API Key を AWS Secrets Manager へ登録する” でメモした “シークレットの ARN” を入力します。“テキストフィールド” には、チャンクに分割されたテキストデータを保存する Pinecone のフィールド名 ( text など) を入力します。“Bedrock マネージドメタデータフィールド” には、Bedrock がメタデータを保存する Pinecone のフィールド名 ( metadata など) を入力します。“次へ” をクリックします。“確認して作成” 画面で入力内容を確認して、右下の “ナレッジベースを作成” をクリックします。 図28: Amazon Bedrock でナレッジベースの作成 (6) – ベクトルデータベースの詳細を設定 通常、1分程度でナレッジベースが作成されます。この時点ではナレッジベースの枠だけが作成されています。 ナレッジベースをデータストアと同期する ナレッジベースを作成した直後の場合は下図のような画面が表示されています。“同期” もしくは “データソースを同期“ をクリックして、データソースをナレッジベースへ取り込みます。同期に必要な時間はデータストアのデータ量に依存します。”データソースの同期が完了しました“ と表示されればデータソースのナレッジベースへの取り込みが完了しています。今回の、Amazon Bedrock ユーザーガイドの PDF ファイルひとつの場合には 1 分程度で完了しました。 なお、この画面から移動してしまった場合は、Amazon Bedrock コンソールの左側ハンバーガーメニュー → ナビゲーションメニュー → オーケストレーション → ナレッジベースの順に辿り、テストしたいナレッジベースの名前を選択すると、同様の画面に遷移します。データストアに変更 (データの追加、更新、削除) があった場合には改めて ”同期“ を行う必要があります。API を使って同期する方法については ドキュメント をご参照ください。 図29: Amazon Bedrock でナレッジベースのデータストアとの同期 ナレッジベースをテストする ナレッジベースを作成して同期が完了すると、下図のような画面が表示されます。画面右側の “モデルを選択” をクリックして、クエリへの回答を生成する基盤モデルを選択します。 図30: Amazon Bedrock でナレッジベースのテスト (1) “モデルを選択“ 画面で、回答生成に使用したい基盤モデルを選択します。本稿では、Anthropic 社の ”Claude 2.1 v.2.1“ を選択します。Amazon Bedrock では Claude 3 が既に利用可能となっていますが、本稿執筆時点では Knowledge base for Amazon Bedrock で利用可能な基盤モデルは下図の 3 モデルとなっています。”適用“ をクリックします。 図31: Amazon Bedrock でナレッジベースのテスト (2) – 回答を生成する大規模言語モデル (LLM) の選択 “ナレッジベースをテスト” の下部にある “ここにメッセージを入力” 欄に質問を入力します。“実行” をクリックします。 図32: Amazon Bedrock でナレッジベースのテスト (3) – テストクエリの入力と実行 ナレッジベースの検索結果を元に、基盤モデルによる回答が生成されました。 図33: Amazon Bedrock でナレッジベースのテスト (4) – テスト結果 回答の元となった情報の出典も確認することができます。 図34: Amazon Bedrock でナレッジベースのテスト (5) – 回答の根拠となる出典を確認 ナレッジベースに API でアクセスする ナレッジベースに API 経由で質問を送信し回答を得るには、Agents for Amazon Bedrock Runtime の RetrieveAndGenerate API を使用することができます。詳細は ドキュメント をご参照ください。 API でアクセスするには、ナレッジベースの ID (図 29 などの “ナレッジベース ID”)と、回答を生成する基盤モデルのモデル ID が必要となります。基盤モデルのモデル ID は、Bedrock コンソール → 左上のハンバーガーメニュー → ナビゲーションメニュー → 基盤モデル → ベースモデルと辿って表示される “ベースモデル” 画面で、基盤モデル名 (このブログの例では Claude v2.1) をクリックして表示される画面の API リクエスト欄で確認することができます ( ListFoundationModels API で確認することもできます)。 下記のコードサンプルの modelId と knowledgebaseId を、確認した値に修正し、必要に応じて query を修正します。 import boto3 region = "us-west-2" modelId = "anthropic.claude-v2:1" knowledgebaseId = "XXXXXXXXXX" query = "Bedrockのセキュリティ上のメリットは何ですか？" modelArn = f'arn:aws:bedrock:{region}::foundation-model/{modelId}' session = boto3.Session(region_name=region) client = session.client(service_name='bedrock-agent-runtime') response = client.retrieve_and_generate( input={ 'text': query }, retrieveAndGenerateConfiguration={ 'type': 'KNOWLEDGE_BASE', 'knowledgeBaseConfiguration': { 'knowledgeBaseId': knowledgebaseId, 'modelArn': modelArn, }, }, ) print(response['output']['text']) 下図は実行例となります。 図35: ナレッジベースへの API アクセスの実行結果 ハイブリッドサーチに関する補足 本稿では Knowledge base for Amazon Bedrock と Pinecone serverless を用いてセマンティックサーチを行う方法について取り上げました。ユースケースによっては、セマンティックサーチだけでなく、テキストサーチも組み合わせたハイブリッドサーチが適している場合もあります。Pinecone 自体はハイブリッドサーチをサポートしていますが、本稿執筆時点では、Knowledge base for Amazon Bedrock と Pinecone との組み合わせでは、ハイブリッドサーチはサポートされていません。ハイブリッドサーチを使いたい場合には、Amazon OpenSearch Serverless との組み合わせをご検討ください。また、Pinecone のハイブリッドサーチを使いたい場合には、Knowledge base for Amazon Bedrock を使わずに、Amazon Bedrock の基盤モデルと Pinecone serverless を LangChain などのフレームワークで統合することができます。 まとめ Knowledge base for Amazon Bedrock と Pinecone serverless を組み合わせることでシステムの担当者は、RAG システムや生成 AI エージェントアプリケーションの構築の手間を大幅に軽減することが可能です。また、ビジネスの担当者はアイデアを迅速に検証し、素早く市場にリーチすることができます。そして、新しいサービスは利用者数や利用頻度を予測することが難しく固定費が大きなアーキテクチャーではプロダクションへの移行の決断が困難となりますが、Pinecone serverless のコンサンプションベースの料金体系により、リスクを最小限に抑えながら新サービスの事業化が可能となります。さらに、事業活動が大きく成長した際にも Pinecone serverless のスケーラビリティが役に立つでしょう。 著者について 本橋 和貴 (Kazuki Motohashi) は、AWS Japan の機械学習パートナーソリューションアーキテクトです。AWS 上で機械学習関連のソフトウェアを開発しているパートナー企業の技術支援を担当をしています。好きなサービスは Amazon SageMaker です。週末は昔の RPG のリメイクゲームの攻略に勤しんでいます。博士 (理学)。 荒川裕二 (Yuji Arakawa) は、APJ (Asia Pacific Japan) Partner Core Tech のシニアエンタープライズアーキテクトです。主に日本のパートナー企業の技術支援を担当しながら Machine Learning TFC (Technical Field Community) の AoD (Area of Depth) としても活動しています。好きなサービスは Amazon Bedrock と Amazon SageMaker Jumpstart です。自由時間のすべてをアニメーション産業の発展のために捧げています。

本記事は、AWSブログ Experience the Future of Smart Manufacturing at Hannover Messe 2024 を日本語に翻訳し、日本のお客様向けに 補足情報 を追加したものです。 ハノーバーメッセ2024は、今年最大の世界的な産業技術イベントになるでしょう。4月22日から26日までドイツのハノーバーで開催され、製造業や産業界をリードする企業、パートナー、さらに13万人以上の参加者が集い、製造業の未来を形作る新しいソリューションが披露されます。 Amazon Web Services(AWS) も出展し、工場における生成 AI を含む最新の産業ソリューションを紹介します。 こちらの動画で 概要をご覧いただけます。インダストリー4.0、生成 AI/人工知能、カーボンニュートラルな生産といったテーマのもと、製造業の企業が最新のイノベーションを活用して、スマートで効率的かつ持続可能な事業運営を実現する方法を体験できるでしょう。 ハノーバーメッセ 2024 へ来場する理由 世界有数の産業技術見本市であるハノーバーメッセは、見逃せないイベントです。来場すべき主な理由は以下のとおりです。 産業界における重要な課題を克服するための興味深いシアターセッションに参加し、新たな技術を活用して競争優位を得ようとする製造業の業界リーダーの洞察に触れることができます。 自動車、輸送、電力、石油・ガス、鉱業、化学などの関連業界の製造業の企業や参加者とのネットワーキングの機会があります。 生成AIや機械学習など、世界の産業を急速に変革しつつある最新の産業イノベーションや最新のソリューションにいち早くアクセスできる特別な機会があります。 2024 年ハノーバーメッセにおけるAWSの展示 Hall 15、Booth D76の AWS ブースにお越しいただき、AWS の専門家と交流したり、エンジニアリング/設計、スマート生産、スマート製品、サステナビリティ、サプライチェーンなどの最新のユースケースを支える AWS のテクノロジーや AWS パートナーソリューションのインタラクティブな展示をご覧ください。データがなぜあらゆるデジタルトランスフォーメーションの基礎であるのか、また、組織全体の様々なユースケースに対処するためには、産業データ戦略を持つことがビジネスチームのデータ活用のために極めて重要であることがご理解いただけるでしょう。 AWS は、データの資産活用のためのスケーラブルで統合されたメカニズムを実現するデータ管理アーキテクチャの作成をご支援します。 AWS のチームと会話し、製造業のお客様がコネクテッドなソフトウェア定義 (Software Defined) 製品とサービスを立ち上げる方法を学ぶことができます。 どのように製品に新しい機能を統合して顧客体験を向上させ、製品を改善し差別化するかを学ぶことができます。 AWS サービスを使用してアプリケーションを構築することにより、製造業のお客様は、スマートなコネクテッド製品・装置を革新することができます。新たな収益成長機会を創出するために、 製品・装置のデータを収集・処理・保存・分析・活用できる IoT、ML、AI、データ基盤を AWS サービスが提供します。 生成 AI 、データ分析、コンピュータビジョン、モノのインターネット (IoT)、デジタルツインなどを活用したライブ製品デモをご覧いただけます。電動バイクのスマートな生産ラインを題材にした新しいデモにより、AWS クラウドソリューションがどのように運用効率や品質を改善し、製品の設計からスマートコネクテッド製品の使用までの製造業のプロセス全体でビジネスイノベーションを推進するかをお見逃しなく。 ブースシアターでは、AWS のリーダー、AWS パートナー、そしてお客様による生成 AI 、機械学習、産業用IoTといった新しいテクノロジーの産業での活用についての講演をお聞きください。月曜日から木曜日まで 50 を超えるセッションを予定しており、生成 AI からデジタルツイン、サステナビリティまで、シアターはさまざまな話題でいっぱいです。 ブースでは、プラチナスポンサーの Siemens、MHP、Snowflake を含む30社以上の製造業に注力しているパートナーが展示を行っています。これらのAWSパートナーは製造業で強固な足場を築いており、クラウドトランスフォーメーションジャーニーを簡単にするためのソリューションを AWSと協力して構築しています。 業界を変革する最新の AWS 機能に重点を置いたガイド付きのブースツアーで、AWS の製造業の専門家とネットワークを築くことができます。また、月曜日から木曜日の午後5時30分から7時まで、AWS ブースで毎夕開催されるネットワーキングレセプションにもお立ち寄りください。 AWS ブースの生成 AI 生成 AI は、製造業の企業が業務を最適化したり、価値実現までの時間(Time to Value)を加速する方法を急速に変えつつあります。ブースに立ち寄りいただき、製造業のお客様のイノベーションと意思決定を加速するために、AWS がどのように生成 AI ベースのアプリケーション構築や大規模展開を容易になものにしているかをご覧ください。Amazon Bedrock、Amazon CodeWhisperer、Amazon Q などの AWS の生成 AI サービスは、製品の設計を革新し、生産を強化し、製造サプライチェーンを最適化するのに役立ちます。 生成 AI は、産業イノベーションの次の大きな波を表しています。ハノーバーメッセでは、未来を垣間見ることができるでしょう。 AWS のクラウドテクノロジーにより製造業の企業が業務全体で生成 AI を活用できるようになることをご自分の目で確認ください。 生成 AI が技能者、技術者に専門的なガイダンスをすぐに提供することで、スキルギャップをどのように解消するかを学んでいただけます。 生成 AI が製造品質管理、トラブルシューティング、メンテナンス、作業指示などをどのように最適化するかをデモでご覧いただけます。 コスト効率よく合成データセットを作成するため、どのように生成 AI を使用してコンピュータビジョンモデルをトレーニングするかをご確認ください。 デジタルツインと統合された生成 AI が装置のトラブルシューティングをどう効率化するかを体験してください。 産業における生産効率の進化と、生成 AI によって実現されるイノベーションを探るセッションにご参加ください。 生成 AI アプリケーションを自分で作成したり、使ったりすることを、ハンズオンで体験してください。 ご来場をお待ちしています ハノーバーメッセ 2024 へのご来場を通じて、今後の製造業を形作る最新のイノベーションを体験いただき、未来を、より速く、一緒に切り拓いていきましょう。 今すぐ登録して 、競争力、サステナビリティの実現、そして成長の原動力となる先進的なソリューションの数々を、ぜひ直接ご体験ください。 日本のお客様に向けた情報 日本からのお客様向けには、ハノーバー現地において、AWS の日本メンバーによる日本語でのブースのご案内や、個別ミーティング等を実施しています。上記リンクまたは担当の営業経由でお申し込みください。また、現地でも日本人スタッフにお気軽にお声がけください。 Tiffany Pfremmer Tiffany は、Amazon Web Services の製造・産業分野に注力する上級マーケティングマネージャーです。 ロックウェル・オートメーションに15年以上在籍し、マーケティング、品質、サービスなど、様々な役割を果たした経験を生かし、製造業のサプライチェーン全体を支えるソリューションのマーケティングと提供に注力しています。 &nbsp;