Amazon OpenSearch Service は、ワークロード固有の要件を満たすための複数のドメイン 設定 を提供しています。標準的なサービス運用の一環として、これらの設定を定期的に更新する必要がある場合があります。最近、Amazon OpenSearch Service は設定変更をより効果的に追跡できるようにする 視認性の改善 を行いました。詳細でより説明的な設定ステータスを導入することで、アラームの設定と自動化の利用を可能にし、手動での監視を最小限に抑えることが可能になりました。 こうした視認性の改善を、アプリケーションでご活用いただくことをお勧めします。 新機能は後方互換性があります。既存の自動化された処理が従来の processing パラメータに依存して構成変更のステータスを判断している場合は、影響なく動作し続けるはずです。 複数の未処理の構成変更リクエストを簡単に追跡できるように、Amazon OpenSearch Service は ドメイン処理ステータス がアクティブであるときにのみ構成リクエストを許可します。 詳細は「構成変更は一度に 1 つだけ」のセクションを参照してください。 ソリューションの概要 従来、設定変更のステータスは OpenSearch Service API (Application Programming Interface) の processing パラメータや、OpenSearch Service コンソールのドメインステータスフィールドを通じて確認できました。Amazon OpenSearch Service では設定更新のエクスペリエンスを改善するために、次の変更を導入しました。 API レスポンスに、 DomainProcessingStatus と ConfigChangeStatus の 2 つの新しいパラメータを導入しました。 同様に、コンソールに ドメイン処理ステータス と 設定変更ステータス フィールドを追加しました。 これらの変更により、直観的な複数のステータスから高い可視性が得られるようになりました。従来のステータスは、 Active と Processing の 2 つの値に限定されていました。 現在のアクティブな設定と、変更適用中の設定を簡単に比較できるようになりました。 以前は、複数のステップが必要でした。 今回、Amazon OpenSearch Service は、一度に 1 つの構成変更リクエストのみを許可するアプローチを採用しました。 単一のリクエストにまとめられるドメイン設定変更の項目数に制限はありません。 ただし、次の設定リクエストを送信できるのは、以前のリクエストが完了し、ドメインの処理ステータスがアクティブになった後です。 この改善により、設定の更新が合理化され、以前のような、実行中の複数の設定変更リクエストを追跡する課題が解消されました。 検証に失敗した場合、変更リクエストをキャンセルできるようになりました。 以前は、インスタンスが使用できない場合、ドメインは processing 状態のままでした。 現在は、 検証に失敗 すると、変更リクエストをキャンセルしてから時間を置いて再試行が可能です。 シャードの移動を含むすべてのバックグラウンドアクティビティが完了した後にのみ、ドメインの処理ステータスが Active になります。 これは、データ移動などのすべての内部プロセスが完了したかどうかを推測する必要がなく、自動化スクリプトで新しく導入されたステータスを自身をもって使用できることを意味します。 設定更新ステータスを追跡するための、詳細情報の取得方法 最近の改善の一環として、Amazon OpenSearch Service は API に DomainProcessingStatus と ConfigChangeStatus パラメータを、コンソールにそれぞれ対応する ドメイン処理ステータス フィールドと 設定変更ステータス フィールドを導入しました。これらのステータスを利用することで、設定変更において Blue/Green デプロイを伴う場合、または Blue/Green デプロイを伴わない場合、構成変更がオペレーターによってトリガーされる場合や、OpenSearch サービスによってトリガーされる場合など、さまざまな構成変更シナリオで正確で一貫した情報を取得できます。これらの強化された視認性のエクスペリエンスを見ていきましょう。 ドメイン処理ステータスの視認性: ドメインレベルの構成変更のステータスは、コンソールの ドメイン処理ステータス フィールドで追跡できます。同様に、API レスポンスには DomainProcessingStatus パラメータが含まれます。値と簡単な説明は次の詳細で提供されています: アクティブ: 構成変更は進行中ではありません。新しい構成変更リクエストを送信できます。 作成中: 新しいドメインの作成が進行中です。 変更中: このステータスは、新しいデータノードの追加、Amazon Elastic Block Store ( Amazon EBS ) GP3 ストレージのプロビジョニング、KMS キーの設定など、1つ以上の構成変更が進行中であることを示しています。したがって、 UpdateDomainConfig API を介して変更が行われた場合、ステータスは「変更中」にセットされます。「変更中」ステータスには、構成変更を完了するためにシャードの移動が必要なドメインも含まれます。注意: 後方互換性のために、API レスポンスでは processing パラメータの動作を変更していません。 processing パラメータは、シャード移動の完了を待たず、コアとなる設定変更が完了した時点で false にセットされます。 エンジンバージョンのアップグレード中: Elasticsearch バージョン 7.9 から OpenSearch バージョン 1.0 へのアップグレードなど、エンジンバージョンアップグレードが進行中です。 サービスソフトウェアの更新中: このステータスは、サービスソフトウェア更新に関連する構成変更を指します。 削除中: ドメインの削除が進行中です。 隔離: このステータスは、アカウント関連の課金問題や重要なセキュリティパッチ更新に準拠していないなどの、さまざまな理由で中断されているドメインを表しています。 設定変更ステータスの視認性: 設定変更は、ユーザーによって開始されることがあります(新しいデータノードの追加、インスタンスタイプの変更など)。または、サービスによって開始されることがあります(AutoTune や必須のサービスソフトウェア更新など)。最新のステータスの詳細は、コンソールの 構成変更ステータス フィールドと、API レスポンスの ConfigChangeStatus パラメータを通じて確認できます。以下は、値と簡単な説明です。 保留中: 構成変更リクエストが送信されたことを示しています。 初期化中: サービスが構成変更リクエストを初期化しています。 検証中: サービスがリクエストされた変更と必要なリソースを検証しています。 検証に失敗しました: リクエストされた変更が検証に失敗しました。この時点では、構成変更は適用されていません。起こりうる検証失敗の例としては、ドメイン内の red インデックスの存在、選択したインスタンスタイプが使用できない、ディスク容量の不足などがあります。 こちら に潜在的な検証失敗のリストがあります。検証失敗イベント中は、構成変更をキャンセル、再試行、編集できます。 ユーザー入力待ち: ユーザーが無効な KMS キーなどの検証エラーを修正できるシナリオです。このステータスでは、ユーザーは構成変更を編集できます。 変更の適用中: サービスがリクエストされた構成変更を適用しています。 キャンセル済み: 検証失敗ステータス中に、コンソールの キャンセル ボタンをクリックするか、 CancelDomainConfigChange API を呼び出すことができます。変更リクエストの一部であったすべての適用された変更がロールバックされます。 完了: リクエストされた構成変更が正常に完了しました。 コンソールの改善 Amazon OpenSearch Service コンソールでは、構成変更の進捗状況を追跡するための視認性が向上しました。以下のスクリーンショットで、改善点の概要を確認できます。 Amazon OpenSearch Service コンソールは、 ドメイン処理ステータス 、 設定変更ステータス 、 変更 ID フィールドを提供します。注意: 変更 ID に関連付けられた変更の詳細を知るには、 DescribeDomainChangeProgress API を使用できます。 設定変更の概要 。アクティブな設定と要求された変更の横並びの比較を見るには、ドメインの詳細ページでクラスター設定タブに移動し、設定変更の概要セクションまでスクロールダウンします。 保留中の変更 フィールドには、その時点での保留中のプロパティのステータスが表示され、適用された変更は含まれません。 DescribeDomain および DescribeDomainConfig API の ModifyingProperties パラメータを介して、同様の詳細も取得できます。 検証失敗時のキャンセル。 以下のスクリーンショットでは、構成変更リクエストの検証に失敗したときに変更リクエストをキャンセルする新しいオプションが確認できます。 たとえば、 SubnetNotFound エラーが発生した場合、 リクエストのキャンセル ボタンを使用して以前のアクティブな構成にロールバックし、問題を修正してから構成の更新を再試行できます。 構成変更は一度に 1 つだけ 以前は、複数の変更リクエストをしたときに、個々の変更リクエストの成功と失敗を追跡することは簡単ではありませんでした。 シンプルなエクスペリエンスを提供するために、現在の OpenSearch Service は、変更リクエストは一度に 1 つのみと制限を設けています。 1 つの構成変更リクエストに、複数の変更をまとめることができます。 コンソールもしくは UpdateDomainConfig API を介して次の構成変更をリクエストする前に、送信された構成変更リクエストが完了する必要があります。 この簡素化されたエクスペリエンスにより、リクエストされた変更とその最新のステータスを追跡することが容易になります。 自動化処理が設定変更 API を複数回呼び出すように記述されている場合は、単一の更新呼び出しに複数の構成変更をまとめるか、次の設定変更を送信する前に、個々の更新処理が完了するのを待つ必要があります。 ドメインの処理ステータスがアクティブになったときに、ドメイン設定の更新が可能です。 Blue/Green デプロイメントが必要な変更のリストについては、 こちら をご覧ください。 以下のスクリーンショットは、「クラスター設定の編集」ページの例で、ユーザーに対して、別の変更や更新が進行中であることを通知するアラートを示しています。OpenSearch Service では、新しい構成更新リクエストを送信できなくなり、進行中の変更が完了するまで「変更の適用」ボタンが無効になります。 API の変更 DescribeDomain 、 DescribeDomainChangeProgress 、 DescribeDomainConfig API を使用して、詳細な構成更新ステータスを取得できます。 さらに、検証失敗が発生した場合は、 CancelDomainConfigChange を使用して変更リクエストをキャンセルできます。 Amazon OpenSearch Service API ドキュメントは こちら からご参照ください。 まとめ 本投稿では、設定の更新リクエストに関する詳細な情報の取得方法について説明いたしました。 新規に導入された改善により、設定変更リクエストの進捗状況の可視性が向上し、適用された変更と保留中の変更を簡単に区別できるようになりました。 設定変更リクエストを送信する前に、 DomainProcessingStatus 処理ステータス値が Active であることを確認する必要があります。 検証の失敗が発生した場合に変更をキャンセルできる機能により、ドメインを処理状態から自助的に回復する制御が向上します。 詳細は、製品の ドキュメント をご覧ください。 著者について Siddhant Gupta は、インドのハイデラバードに拠点を置くAmazon Web Services のシニアテクニカルプロダクトマネージャーです。 Siddhant は Amazon で6年以上働いており、現在OpenSearch Service チームと協力して新しいリージョンのローンチ、価格戦略、EC2 と EBS のイノベーションを OpenSearch Service のお客様に提供しています。彼はアナリティクスと機械学習に情熱を注いでいます。余暇では、旅行、フィットネス、家族との時間、ノンフィクション本の読書を楽しんでいます。 Deniz Ercelebi は、Amazon OpenSearch Service の Sr. UX デザイナーです。 彼女の役割は、複雑な問題のデザインソリューションの作成、実装、および成功した提供に貢献することです。 個人的な動機は、ユーザーエクスペリエンスへの情熱、顧客中心のソリューションへの献身、そして協調的イノベーションへの確固たる信念によって推進されています。 Shashank Gupta は、Amazon OpenSearch Service の Sr. ソフトウェア開発者で、プラットフォームのマネージドサービスの側面の強化を専門としています。 主な焦点は、コンソールから API やリソースプロビジョニングに至るまで、マネージドエクスペリエンスを効率的な方法で最適化することです。 イノベーションへの献身的なコミットメントがあり、サービス内で革新的なソリューションを導入することによって、全体的な顧客体験を高めることを目指しています。 翻訳はソリューションアーキテクトの榎本が担当いたしました。原文の投稿は Track Amazon OpenSearch Service configuration changes more easily with new visibility improvements  よりご確認ください。

このブログでは、さまざまな 生成 AI を活用したビジネスユースケースをデモンストレーションしている Generative AI Use Cases JP をカスタマイズする方法についてご紹介します。Amazon Bedrock、Amazon Kendra などを利用して、Generative AI Use Cases JP はさまざまなビジネスユースケースを公開しています。 その Generative AI Use Cases JP の Web UI を利用することで簡単に新しいユースケースを追加することが可能です。 このデモンストレーションでは、SQL を記述する工数を削減したいデータアナリストをターゲットに、Amazon Bedrock の 基盤モデル を用いてSQL を生成するユースケースを作成してみます。 今回作成するユースケースで用いる 基盤モデル は Claude v2 を利用します。 ユースケースを作成し始める前に、基盤モデル で SQL を生成可能かチャットで確認する ユースケースを作成する前に、そもそも 基盤モデル を利用して SQL 生成が可能かどうかをチェックします。 具体的には、チャットで意図した SQL が生成できるかを検証してみます。 ここでは、人間が記述するのが面倒な、長い Case 文を自然言語で簡単に出力できるか確認してみます。 SQL 生成のために 基盤モデル に入力すべき情報 有用な SQL を出力するために入力すべき必要な情報を整理してみます。 テーブル定義 基盤モデルは社内データベースのスキーマ情報を知りません。 基盤モデルにテーブル定義を渡すと各カラムの type や range、コメント などを参照して正確な SQL の出力を期待できます。 出力したい SQL を説明する自然言語 普段使用している自然言語で出力させたい SQL を説明します。 チャットに入力 チャットに入力すべき情報 1, 2 を Claude v2 に入力していきます。 まずは基盤モデルに役割とタスクを与えるため、システムコンテキストに以下を入力します。システムコンテキストとは、Claude に質問したりタスクを与える前に特定の目標や役割を指定するなど、Claude にコンテキストと指示を提供する方法です。詳細については Anthoropic 社の システムプロンプトの使用方法 を参照してください。 システムコンテキスト Claude2 に役割とタスクを与える 役割: ユーザーの指示をよく理解する熟練のデータベーススペシャリスト タスク: を守って、可読性の高い SQL だけを出力してください Claude2として利用する Claude が理解しやすい XML タグを用いて記述する。XML タグは自由に定義してよい。 RDB のスキーマ情報: <schemas></schemas> Claude v2 の出力例: <examples></examples> 以下はユーザーと AI のやりとりです。 ユーザーは AI に <schemas></schemas> の xml タグで囲って RDB のスキーマ情報を渡します。 さらに、<input></input> の xml タグで囲って AI に記述して欲しい SQL の説明を渡します。 AI は、ユーザーの指示をよく理解する熟練のデータベーススペシャリストなので、以下の <rules></rules> を守って、可読性の高い SQL だけを出力してください。 <rules> * <schemas> と <input> の情報を頼りに、ユーザーが求める SQL を ANSI SQL に準拠して出力してください。 * join する場合はテーブル名に別名をつけた上で、列名は必ず `別名.列名` と表記してください。 * GROUP BY や ORDER BY 句には、必ず `列名` あるいは `別名.列名`を使用することを遵守してください。列番号の使用は修正が難しくなるので禁止です。 </rules> 出力は <output>```sql {SQL} ```</output> の形式を遵守してください。 SQL のコード以外を出力してはいけません。解説なども出力してはいけません。 出力例を <examples></examples> で与えます。 <examples> <output>```sql SELECT * FROM v_schedule; ```</output> <output>```sql SELECT e.id AS employee_id, e.name AS employee_name, c.id AS company_id, c.name AS company_name FROM employees e JOIN companies c ON c.id = e.company_id ; ```</output> <output>```sql SELECT id, COUNT(price), SUM(price), MIN(price), MAX(price) FROM transaction t GROUP BY t.id ; ```</output> </examples> 上記の通り、ユーザーは <schemas> と <input> を与えれば Claude v2が SQL を出力してくれるはずです。ここでは Amazon Athena を前提とした DDL と、作成したい SQL の内容をチャットに入力します。 <schemas> CREATE TABLE users ( id SERIAL PRIMARY KEY, name VARCHAR(50) NOT NULL, gender VARCHAR(10) NOT NULL, age SMALLINT NOT NULL, CONSTRAINT users_pk PRIMARY KEY (id) ); COMMENT ON COLUMN users.id IS 'ユーザーID'; COMMENT ON COLUMN users.name IS 'フルネーム'; COMMENT ON COLUMN users.gender IS 'Male, Female, Other のいずれかが格納'; COMMENT ON COLUMN users.age IS '年齢'; CREATE TABLE user_logs ( request_id BIGSERIAL PRIMARY KEY, request_time TIMESTAMP NOT NULL, url TEXT NOT NULL, id SERIAL NOT NULL REFERENCES users(id) ); COMMENT ON COLUMN user_logs.request_id IS 'ログレコードのユニークID'; COMMENT ON COLUMN user_logs.request_time IS 'リクエストした時刻'; COMMENT ON COLUMN user_logs.url IS 'リクエストしたURL'; COMMENT ON COLUMN user_logs.user_id IS 'ユーザーID'; </schemas> <input> 年齢と性別で層分けした属性情報で、年月毎のリクエスト回数の合計を集計してください。 年齢は20歳未満、20-29、30-39、…、70-79, 80以上で分けてください。 性別は、Male, Female, Other で分けてください。 </input> チャット UI 上ではこのように表示されます。 このプロンプトを利用してSQL 生成ユースケースを作成します。 SQL 生成ユースケースの開発 ブランチを作成する アプリ開発をする上でバージョン管理は大切です。 SQL 生成のユースケースを作成するためにブランチを作成します。 以下のコマンドを使用してください。 以下のコマンドは feat/generate-sql ブランチを作成し、このブログ執筆時の最新のコミットを指定しています(Commit ID: 37b29d2 )。 ※注意) ブログ執筆時は上記コードが動きましたがメンテナンスされませんのでご注意ください。この成果物は後述の通り main ブランチを追従しない、かつ main ブランチにもマージされません。お試しや開発のヒントとしてお使いください。 git checkout -b feat/generate-sql git reset --soft `37b29d2` ローカル開発環境を立ち上げる フロントエンドの開発をするにあたり、開発環境を整えます。 Generative AI Use Cases JP をデプロイしていない場合、こちらの リンク を参考にしてまずはデプロイしてください。 今回は開発体験も考慮して、ローカル開発用サーバーを立て、ローカル環境でSQL生成ユースケースを確認できるようにします。 Unix 系コマンドが使えるPC であれば (Linux や MacOS 等)、以下のコマンドでローカル環境が立ち上げられます。 npm run web:devw http://localhost:5173 にアクセスすればローカルで開発したフロントエンドをすぐに確認することができます。 コマンドの設定については /package.json を参照してください。 メニューに追加 まずは、専用のユースケースのリンクを作成します。 packages/web/src/App.tsx でユースケースリンク一覧を作成しているので、追記することで SQL 生成のリンクを追加することができます。 カスタマイズ方法として、本ブログの Diff と書かれた内容の中で、行頭に + があればその行を追加し、行頭に - があればその行を削除して下さい。 packages/web/src/App.tsx …(前略)… PiX, + PiTerminal, } from 'react-icons/pi'; …(中略)… { label: '画像生成', to: '/image', icon: <PiImages />, display: 'usecase' as const, }, + { + label: 'SQL 生成', + to: '/generate-sql', + icon: <PiTerminal />, + display: 'usecase' as const, + }, { label: '音声認識', to: '/transcribe', icon: <PiSpeakerHighBold />, display: 'tool' as const, }, …(後略)… リンク先を用意する 作成したリンクは当然存在しないので 404 が表示されます。 まずはリンク先を用意しましょう。 packages/web/src/main.tsx でリンク先を設定します。 packages/web/src/main.tsx …前略… import GenerateImagePage from './pages/GenerateImagePage'; + import GenerateSqlPage from './pages/GenerateSqlPage'; import TranscribePage from './pages/TranscribePage'; …中略… path: '/image', element: <GenerateImagePage />, }, + { + path: '/generate-sql', + element: <GenerateSqlPage />, + }, { path: '/transcribe', element: <TranscribePage />, …後略… 以上で、 「 /generate-sql をクリックしたときは GenerateSqlPage.tsx を参照する」という設定が出来上がりました。 ただし、 GenerateSqlPage.tsx が無いため、画面側で以下のようなエラーが発生しているはずです。 [plugin:vite:import-analysis] Failed to resolve import "./pages/GenerateSqlPage" from "src/main.tsx". Does the file exist? …後略… ページを作成する ここから SQL 生成ユースケースのページを作成していきます。 SQL 生成の場合は、「テーブルを定義する DDL」を入力するフォームと、「そのテーブルからクエリを生成するための指示」を入力するフォームの二つが必要となります。すでに文書生成ユースケースで同様の UI が作成されているため、こちらのページの UI をそのまま利用して作成していきます。 以下コマンドで、文書生成のページを複製します。 # プロジェクトのルートディレクトリで実行 cp packages/web/src/pages/GenerateTextPage.tsx packages/web/src/pages/GenerateSqlPage.tsx 複製した、 packages/web/src/pages/GenerateSqlPage.tsx を編集していきます。 packages/web/src/pages/GenerateSqlPage.tsx …前略… import { create } from 'zustand'; + import { generateSqlPrompt } from '../prompts'; + import { GenerateSqlPageLocationState } from '../@types/navigate'; - import { generateTextPrompt } from '../prompts'; - import { GenerateTextPageLocationState } from '../@types/navigate'; import { SelectField } from '@aws-amplify/ui-react'; …中略… clear; () => void; }; + const useGenerateSqlPageState = create<StateType>((set) => { - const useGenerateTextPageState = create<StateType>((set) => { const INIT_STATE = { …中略… }; }); + const GenerateSqlPage: React.FC = () => { - const GenerateTextPage: React.FC = () => { const { modelId, …中略… setText, clear, + } = useGenerateSqlPageState(); - } = useGenerateTextPageState(); const { state, pathname } = + useLocation() as Location<GenerateSqlPageLocationState>; - useLocation() as Location<GenerateTextPageLocationState>; const { loading, messages, postChat, clear: clearChat } = useChat(pathname); const { setTypingTextInput, typingTextOutput } = useTyping(loading); …中略… useEffect(() => { if (state !== null) { + setInformation(state.schemas); + setContext(state.instruction); - setInformation(state.information); - setContext(state.context); } }, [state, setInformation, setContext]); …中略… } }, [modelId, availableModels, setModelId]); + const getGeneratedSql = ( - const getGeneratedText = ( modelId: string, + schemas: string, + instruction: string - information: string, - context: string ) => { postChat( + generateSqlPrompt.generatePrompt({ + schemas, + instruction, - generateTextPrompt.generatePrompt({ - information, - context, }), true, textModels.find((m) => m.modelId === modelId) …中略… const onClickExec = useCallback(() => { if (loading) return; + getGeneratedSql(modelId, information, context); - getGeneratedText(modelId, information, context); }, [modelId, information, context, loading]); …中略… <div className="grid grid-cols-12"> <div className="invisible col-span-12 my-0 flex h-0 items-center justify-center text-xl font-semibold print:visible print:my-5 print:h-min lg:visible lg:my-5 lg:h-min"> + SQL 生成 - 文章生成 </div> <div className="col-span-12 col-start-1 mx-2 lg:col-span-10 lg:col-start-2 xl:col-span-10 xl:col-start-2"> …中略… <Textarea + placeholder="SQL 生成に必要なテーブル情報 (create table DDL) を入力してください" - placeholder="入力してください" value={information} …中略… <Textarea + placeholder="生成する SQL の説明を入力してください。" - placeholder="文章の形式を指示してください。(マークダウン、ブログ、ビジネスメールなど)" value={context} …中略… + export default GenerateSqlPage; - export default GenerateTextPage; ここでは以下 2 点の修正を主にしています。 画面で表示されている文書生成用の説明文字列を SQL 生成用に修正しています。 内部で利用している変数名を文書生成から SQL 生成用に修正しています。この変更は、実際に運用していくにあたり可読性や保守性を上げると言う観点で修正しています。 ただし、変数名を変更することによって、他に変数を定義・利用している部分で TypeScript のエラーが以下のように発生しています。 [{ "resource": "generative-ai-use-cases-jp/packages/web/src/pages/GenerateSqlPage.tsx", "owner": "typescript", "code": "2305", "severity": 8, "message": "モジュール '\"../prompts\"' にエクスポートされたメンバー 'generateSqlPrompt' がありません。", "source": "ts", "startLineNumber": 11, "startColumn": 10, "endLineNumber": 11, "endColumn": 27 },{ "resource": "generative-ai-use-cases-jp/packages/web/src/pages/GenerateSqlPage.tsx", "owner": "typescript", "code": "2724", "severity": 8, "message": "'GenerateSqlPageLocationState' という名前のエクスポートされたメンバーが '\"../@types/navigate\"' に含まれていません。候補: 'GenerateTextPageLocationState'", "source": "ts", "startLineNumber": 12, "startColumn": 10, "endLineNumber": 12, "endColumn": 38 }] 変数定義の修正 packages/web/src/pages/GenerateSqlPage.tsx で使用している、 schemas 変数と instruction 変数の定義を行います。 これは、より型安全にするために ReactRouter の useLocation に型定義を行っています。 packages/web/src/@types/navigate.d.ts context: string; }; + export type GenerateSqlPageLocationState = { + schemas: string; + instruction: string; + }; export type RagPageLocationState = { content: string; システムコンテキストとユーザープロンプトの埋め込み 最後に用意したプロンプトを SQL 生成ユースケースのページにも適用させます。 prompt は、 packages/web/src/prompts/index.ts で制御しています。 このファイルは各ページのコンテキストを定義しています。このファイルに先ほど作成したシステムコンテキストを定義し、ユーザの入力を受け取り、Claude v2 に入力するためのプロンプトを作成するための処理を追加します。 packages/web/src/prompts/index.ts …前略… '/generate': 'あなたは指示に従って文章を作成するライターです。', + '/generate-sql': `以下はユーザーと AI のやりとりです。 + ユーザーは AI に <schemas></schemas> の xml タグで囲って RDB のスキーマ情報を渡します。 + さらに、<input></input> の xml タグで囲って AI に記述して欲しい SQL の説明を渡します。 + AI は、ユーザーの指示をよく理解する熟練のデータベーススペシャリストなので、以下の <rules></rules> を守って、SQL だけを出力してください。 + <rules> + * <schemas> と <input> の情報を頼りに、ユーザーが求める SQL を ANSI SQL に準拠して出力してください。 + * join する場合はテーブル名に別名をつけた上で、列名は必ず \`別名.列名\` と表記してください。 + * GROUP BY や ORDER BY 句には、必ず \`列名\` あるいは \`別名.列名\`を使用することを遵守してください。列番号の使用は修正が難しくなるので禁止です。 + </rules> + 出力は + <output>```sql + {SQL} + ```</output> + の形式を遵守してください。 + SQL のコード以外を出力してはいけません。解説なども出力してはいけません。 + 出力例を <examples></examples> で与えます。 + + <examples> + <output>```sql + SELECT * FROM v_schedule; + ```</output> + <output>```sql + SELECT + e.id AS employee_id, + e.name AS employee_name, + c.id AS company_id, + c.name AS company_name + FROM + employees e + JOIN + companies c ON c.id = e.company_id + ; + ```</output> + <output>```sql + SELECT + id, + COUNT(price), + SUM(price), + MIN(price), + MAX(price) + FROM + transaction + GROUP BY + id + ; + ```</output> + </examples> + `, '/translate': 'あなたは文章の意図を汲み取り適切な翻訳を行う翻訳者です。', …中略… + export type GenerateSqlParams = { + schemas: string; + instruction: string; + }; + export const generateSqlPrompt = { + generatePrompt: (params: GenerateSqlParams) => { + return `<schemas> + ${params.schemas} + </schemas> + <input> + ${params.instruction} + </input>`; + }, + }; <EOF> このコードで行っていることは以下の 2 つです。 先程作成した prompt を変数に格納 入力されたテキストを受け取って、 <schemas> や <input> タグに埋め込む 動作確認 最後に、動作確認をします。 本ブログ上部で入力した DDL ( <schemas> タグの内側のテキスト )と、定義した テーブルで生成したい SQL ( <input> タグの内側のテキスト) を入力します。 実行ボタンをクリックすると、次のような SQL が生成されます。 このように既存の API を利用して簡単に ユースケース を追加することができました。 API をいじるようなケースはまた別途開発が必要ですが、既存の UI を流用して ユースケースを追加するだけであればこのように簡単に作成することができます。 まとめ 本記事では、Generative AI Use Cases JP の既存の UI 、API を利用して、ユースケースを追加する方法についてご紹介しました。文書生成ページを流用して、SQL 生成ページを作成しました。ページ追加の方法や、システムコンテキストの変更方法などを併せて紹介しました。SQL 生成ユースケースとして、実際にはテーブル定義を毎回書くのは大変です。そのため、例えば前回書いたテーブル定義をlocalStorage 等に保存できるようにし、次回利用時には自動で入力された状態の方が便利かもしれません。さらに発展し、DB やテーブル一覧を API で取得しテーブル定義を自動でインポートできるようになると、利便性が格段に向上します。このように、今回の SQL 生成ユースケース一つをとっても、まだまだ拡張の余地があります。 今回のカスタマイズの方法をもとにして、独自のユースケースを作成してみましょう。 この記事のコードサンプルについては、 GitHub リポジトリをご覧ください。 著者プロフィール 呉 和仁 (Go Kazuhito) は AWS Japan の機械学習ソリューションアーキテクト。 IoT の DWH 開発、データサイエンティスト兼業務コンサルタントを経て現職。プログラマの三大美徳である怠惰だけを極めてしまい、モデル構築を怠けられる AWS の AI サービスをこよなく愛す。     鈴木 大樹 (Daiki Suzuki) はAWS Japan のソリューションアーキテクト。データベース領域を得意としており、機械学習領域と絡めたソリューションの作成を行なっています。

AWS Config は、AWS アカウント内のリソースの構成と関係性を評価、監査、検証します。このサービスをコスト最適化に使用したい理由は何でしょうか。たとえば、特定の Amazon Relational Database Service ( Amazon RDS ) インスタンスがアカウントにデプロイされた場合にアラートを受信できるシナリオを考えてみましょう。必要以上に大きいインスタンスタイプが使用されている場合、予期しないコストが発生する可能性があります。 このブログ記事では、AWS Config でカスタムルールを実装する方法を示します。カスタムルールによりデータベースのインスタンスを監視することで、コストの最適化を図ります。複数のアカウントを使用するシナリオでは、お客様は高コストなデータベースインスタンスの使用を制限し、違反が発生した場合に通知を受け取りたいと考えることがあります。たとえば、テストアカウントでは必ずしもアプリケーション構築にプロダクションサイズのインスタンスを利用する必要はありません。AWS Config カスタムルールは、実行中のデータベースインスタンスのタイプをチェックします。そして、意図しないデータベースインスタンスタイプの場合、AWS Config が非準拠として検出します。 ソリューションの概要 次の図は、ソリューションアーキテクチャを示しています 図 1: ソリューションの概要 図 1 の左上にある AWS Config のカスタムルールは、Amazon RDS データベースインスタンスのプロビジョニングが事前定義したコスト管理の基準に違反していないかを検出する AWS Lambda 関数を呼び出します。 この関数の呼び出しは、アカウント内で新しい Amazon RDS データベースインスタンスが検出されるたびに発生します。 AWS Lambda 関数は、インスタンスタイプが承認されたインスタンスタイプに準拠していることを確認します。 リソースが準拠と評価された場合は、何も起こりません。 リソースが非準拠と評価された場合、AWS Lambda 関数は Amazon Simple Notification Service ( Amazon SNS ) トピックを介して管理チームにアラートを送信し、アカウント管理者が修正措置を取ることができるようにします。 手順の説明 このチュートリアルでは、上記のソリューション図で提示されている全体的な手順をデモするために、次のステップで説明します。 注意 : ここで提供されるすべてのコードは、本番環境以外の環境で検証ならびに評価してください。 AWS CloudFormation テンプレートを使用して必要なリソースを作成する Amazon SNS トピックのサブスクリプションを確認する AWS Config カスタムルールが機能していることを確認するために Amazon RDS インスタンスを作成する このチュートリアルの前提条件は次のとおりです。 AWS アカウントに管理者権限でログインできること。 このチュートリアルで使用するリージョンで、AWS Config サービスの設定が完了していること。完了していない場合は、 AWS Config の ワンクリックセットアップ のドキュメントに従ってください。 図 2: AWS Config の設定 ステップ 1: AWS CloudFormation テンプレートを使用したリソースの作成 この AWS CloudFormation テンプレート をダウンロードして起動すると、AWS Lambda 関数、AWS Config カスタムルール、Amazon SNS トピックなどの関連リソースがデプロイされます。 注意 : デプロイされたリソースはコストが発生します。以下の「クリーンアップ」セクションの説明に従ってリソースをクリーンアップするように覚えておいてください。 AWS CloudFormation テンプレートを使用してリソースを作成するには、次のステップを完了します: AWS マネジメントコンソールにサインインします 「 AWS CloudFormation コンソール 」>「 スタックの作成 」>「 新しいリソースを使用 (標準) 」の順に移動します YAML テンプレートファイルをアップロードし、 次へ を選択します 「 スタック名 」を指定し、「 NotificationEmail 」パラメータにメールアドレスを入力した後、 次へ を選択します 「スタックオプションの設定」はデフォルト値のままにして、 次へ を選択します 「レビュー」で設定の詳細を確認し、「 機能 」の「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」のボックスにチェックを入れます 送信 を選択します   図 3: スタック作成の確認 注意 : スタックの作成が送信された後、 AWS CloudFormation > スタック > スタック名 > イベント タブの下でその進捗状況を確認できます。 スタックが正常に作成されると、AWS アカウントにいくつかのリソースがデプロイされていることがわかります。具体的には、 AWS Config ルール 、 AWS Lambda 関数 、 Amazon SNS トピック 、および対応する AWS Identity and Access Management (IAM) ロール です。 ステップ 2: Amazon SNS トピックのサブスクリプションの確認 ステップ 1 の完了後、ステップ 1 で設定したメールアドレスに、「AWS Notification – Subscription Confirmation」というタイトルのメールが「sns.amazonaws.com」から届きます。メールの内容は、下図のようになります。 図 4: サブスクリプション確認メール このメールアドレスで登録された Amazon SNS トピックのサブスクリプションを確認するには、メール内の「Confirm Subscription」リンクをクリックしてください。 注意 : サブスクリプションのステータスは、以下のように Amazon SNS > トピック > aws-config-demo-topic > サブスクリプション タブで確認できます。 図 5: サブスクリプションの確認 ステップ 3: Amazon RDS インスタンスの作成 このステップでは、MySQL の Amazon RDS インスタンスを作成します。これにより、AWS Config のルールがトリガーされ、アカウント管理者にアラートが必要かどうかを判断するために、インスタンスのサイズをチェックします。この例では、作成されるインスタンスのサイズは「 db.r6g.large 」です。 この Amazon RDS インスタンスを作成するには、次のステップを完了します: AWS マネジメントコンソールにサインインします 「 Amazon RDS コンソール 」>「 データベース 」>「 データベースの作成 」の順に移動します 「 簡単に作成 」オプションを選択し、エンジンのタイプとして「 MySQL 」を選択します 図 6: Amazon RDS エンジンのタイプ DB インスタンスのサイズとして「開発 / テスト」を選択し、「パスワードの自動生成」オプションにチェックを入れます。チュートリアル後、今回作成した Amazon RDS インスタンスは削除するので、パスワードを保持する必要はありません。 図 7: Amazon RDS インスタンスサイズ 他のオプションはデフォルト値のままにして、「データベースの作成」を選択します。デフォルトでは、このデータベースはデフォルトの VPC、またはデフォルトの VPC が存在しない場合は新しい VPC 内に作成されます。このセットアップがシナリオに適合しない場合は、「標準作成」を選択して設定を変更できます。 図 8: データベースの作成 この Amazon RDS インスタンスが作成された後、数分以内にメールボックスに通知メールが届くはずです。 AWS Config のカスタムルールによって呼び出される AWS Lambda 関数は、Amazon RDS インスタンスが「 db.t3.micro 」のサイズで作成されているかどうかをチェックしています。したがって、この Amazon RDS インスタンスは AWS Config で非準拠と評価され、アラートメールが送信されます。以下は、RDS インスタンスリソースを評価するために AWS Lambda 関数で使用されるコードスニペットです。 def is_compliant(configurationItem):    logger.info(f"Resource to be evaluated->{configurationItem}") if configurationItem['configuration']['dBInstanceClass'] == 'db.t3.micro':       return True     else:         return False AWS Lambda 関数の完全なコードは、 Lambda > 関数 > aws-config-demo-lambda > コード タブから参照できます。 クリーンアップ チュートリアルでデプロイしたリソースを以下のステップで削除してください。 Amazon RDS インスタンスの削除 AWS CloudFormation スタックの削除 まとめ このブログ記事では、AWS アカウントのコストを管理するために AWS Config カスタムルールを実装する方法について紹介しました。また、Amazon RDS インスタンスタイプを検証するための具体的なユースケースを踏まえて説明しました。 AWS Config のカスタムルールの詳細については、 OS CIS コンプライアンス をチェックするAWS Config カスタムルールの設定をご覧ください。 著者紹介 Neville Lewis Neville Lewis は AWS の Cloud Application Architect で、アプリケーションアーキテクチャデザインの経験が豊富です。 James Hu James Hu は AWS の Sr. Cloud Application Architect で、マイクロサービスアーキテクチャや AWS CloudFormation/CDK、高可用性の構成について造形が深いです。 Desta Pickering Desta Pickering は AWS の Cloud Application Architect で、彼女はお客様のユニークな課題を解決することが大好きです。 Drishti Arora Drishti Arora は AWS Professional Services の Cloud Application Architect で、お客様とパートナーのクラウドジャーニーを支援しています。 翻訳は SA 桂井が行いました。原文は こちら です。

この記事は、 Generative AI Infrastructure at AWS を翻訳したものです。 生成 AI モデルの構築やトレーニング、そして正確で洞察に満ちた出力の予測と提供には、大規模なインフラストラクチャを必要とします。 大規模言語モデル（LLM）や基礎モデル（FM）が生成する高品質の合成テキスト、画像、その他のメディアの出力には、大量のデータが必要です。 まず、モデルのトレーニングに使用されるデータセットには、一般的に 10 億個ほどの変数（パラメータ）が含まれています。 このペタバイト単位のような膨大なデータを処理するには、何百ものハードウェアアクセラレーター（ML 専用シリコンまたは GPU が組み込まれている）が必要になります。 効果的な LLM に必要なデータ量を考えると、これらのモデルのデータに GPU/ML シリコンが処理するのと同じ速さでアクセスできなければ、コストがかかり非効率になります。 生成 AI ワークロード用のインフラストラクチャを選択することは、コスト、パフォーマンス、持続可能性の目標、使いやすさに至るまで、あらゆることに影響します。 FM のトレーニングと推論を成功させるには、組織は以下の要素が必要です。 大規模な生成 AI ワークロードを支えるためのコストパフォーマンスに優れたアクセラレーテッド・コンピューティング（最新の GPU や専用 ML シリコン） アクセラレーターの利用率を高く維持できるように構築された高性能かつ低レイテンシーのクラウドストレージ 生成 AI ワークロードのインフラストラクチャをサポートする、高性能で最先端のテクノロジー、ネットワーキング、システム 生成 AI アプリケーション、ツール、インフラストラクチャ全体でシームレスな統合を提供可能なクラウドサービスを利用した構築能力 生成 AI のためのコンピューティング、ストレージ、ネットワーキングの概要 Amazon Elastic Compute Cloud (Amazon EC2) のアクセラレーテッド・コンピューティング・ポートフォリオ（ GPU や専用の ML シリコンで動作するインスタンス ）は、生成 AI ワークロードを強化するための幅広いアクセラレーターの選択肢を提供します。 アクセラレーターの高い利用率を維持するためには、処理のためのデータへの定常的なアクセスが必要です。AWS は Amazon FSx for Lustre と Amazon S3 により、ストレージからの高速なデータ転送（最大数百 GB/TB のデータスループット）を提供します。 AWS Nitro System 、最大 3,200 Gbps の Elastic Fabric Adapter (EFA) ネットワーキング、 Amazon EC2 UltraClusters によるエクサスケールコンピューティングのような AWS テクノロジーが組み込まれた高速コンピューティングインスタンスは、生成 AI ワークロードのための最もパフォーマンスの高いインフラストラクチャを提供するのに役立ちます。 これらのインスタンスは、 Amazon SageMaker HyperPod や Amazon Elastic Kubernetes Service (Amazon EKS) などのマネージドサービスと組み合わせることで、生成 AI アプリケーションの構築とデプロイのための業界最高峰のプラットフォームを開発者に提供します。 このブログ記事では、生成 AI を中心とした Amazon EC2 インスタンス、ストレージ、ネットワーキング関連のアナウンスに焦点を当てます。 生成 AI ワークロードのための AWS コンピュートの進化 大規模な FM のトレーニングには膨大なコンピュートリソースが必要です。また、あらゆる規模の組織がより速く反復的に、多くのモデルをトレーニングし、精度を高めるためには、プロジェクト毎に幅広いオプションセットを必要とします。2023 年には、AWS のコンピュート分野全体で、生成 AI のトレーニングと推論の両方のワークロードをサポートする多くのリリースがありました。 そのうちの 1 つ、 Amazon EC2 Trn1n インスタンス （AWS 自身が ML ワークロード、特に ML トレーニング向けに開発した第二世代の ML 専用チップ AWS Trainium を搭載したインスタンス）は、Trn1 インスタンスと比較して Elastic Fabric Adapter (EFA) のネットワーク帯域幅を 2 倍の 1,600 Gbps に拡張しました。この帯域幅の向上により、LLM や mixture of experts (MoE) などのネットワーク負荷の高い生成 AI モデルのトレーニングが Trn1 と比較して最大 20% 高速化されました。 「 株式会社わたしは 」様は革新的でインタラクティブな AI チャットボットサービス「大喜利 AI」を提供しており、LLM を使用してユーモアを取り入れ、顧客により適切で会話しやすい体験を与えています。株式会社わたしはの小橋洋平 CTO は「モデルの開発では、モデルの事前学習とファインチューンを頻繁に行う必要がありました。我々はテンソルとデータの並列性を活用して、GPT ベースの日本語モデルを EC2 の Trn1.32xlarge インスタンスで事前学習しました。トレーニングは 28 日以内に完了し、以前の GPU ベースのインフラストラクチャと比較して 33% のコスト削減を実現しました。当社のモデルは急速に複雑さを増し続けるので、より大規模なモデルのトレーニングを高速化するために、Trn1 の 2 倍のネットワーク帯域幅を備えた Trn1n インスタンスに期待しています。」と述べています。 AWS は生成 AI ワークロードのためのインフラストラクチャを進化させ続けており、最近 Trainium2 アクセラレーター も近々登場すると発表しました。これらのアクセラレーターは、第 1 世代の Trainium チップよりも最大 4 倍高速な学習を実現するように設計されており、最大 100,000 チップの EC2 UltraCluster にデプロイできるようになり、エネルギー効率を最大 2 倍改善しながら、FM や LLM を短い時間で学習できるようになります。 AWS は、これまでにも GPU インフラへ長年投資を続けてきました。現在までに、NVIDIA は Ampere GPU 世代と Grace Hopper GPU 世代にわたり、AWS 上に 200 万基の GPU を展開しています。これは 3 ゼタフロップス、つまり 3,000 台のエクサスケールのスーパーコンピュータに相当します。最近では、AWS は NVIDIA H100 Tensor Core GPU で動作する Amazon EC2 P5 インスタンス を発表しました。これは、NVIDIA CUDA または CuDNN を使用した時間重視の大規模トレーニングワークロード向けに設計されたものです。P5 インスタンスは、旧世代の GPU ベースの EC2 インスタンスと比較して、ソリューション解決の速度を最大 4 倍に高速化し、ML モデルのトレーニングコストを最大 40% 削減します。P5 インスタンスは、より速いペースでソリューションを反復処理し、迅速に市場に投入するのに役立ちます。 また AWS は、高需要な GPU コンピューティング容量への簡単かつ予測可能なアクセスを提供するために、 Amazon EC2 Capacity Blocks for ML をローンチしました。これは、主要なクラウドプロバイダーとしては初めての消費モデルで、GPU を将来の使用のために予約して短時間の ML ワークロードを実行できます（EC2 UltraClusters で最大 500 基までデプロイ可能）。 AWSはまた、 Amazon SageMaker HyperPod によってトレーニングを簡素化し、大規模かつ耐障害性の高い分散トレーニングに必要なプロセス（例えば、分散トレーニングライブラリの構成、数千のアクセラレーターにわたるトレーニングワークロードのスケーリング、異常なインスタンスの検出と修復など）の多くを自動化することで、トレーニングを最大 40% 高速化します。Perplexity AI のような顧客は、SageMaker HyperPod を使用することで、 数百の GPU を超えて柔軟にスケーリングし、ダウンタイムを最小限に抑えています 。 ディープラーニングの推論は、 AWS Inferentia2 によって提供される低コストで高性能な Amazon EC2 Inf2 インスタンス など、AWS がクラウドインフラストラクチャの革新を続けているもう一つの例です。これらのインスタンスは、高性能なディープラーニングの推論アプリケーションをグローバル規模で実行するために設計されています。これらは、生成 AI における最新のイノベーションを展開するためには、Amazon EC2 における最もコスト効率とエネルギー効率の高いオプションです。 別の例として、 Amazon SageMaker を使用すると、同じインスタンスに 複数のモデルをデプロイ することができるため、コンピュートリソースを共有し、推論コストを 50% 削減することができます。SageMaker はまた、推論リクエストを処理しているインスタンスをアクティブに監視し、利用可能なインスタンスに基づいてインテリジェントにリクエストをルーティングします。これにより、平均して 20% 低い推論レイテンシーを実現します。 AWS は、生成 AI ワークロードのためのツールにも多額の投資を行っています。AWS ML シリコンについては、AWS は Trainium と Inferentia から顧客が最大限のパフォーマンスを得るためのソフトウェア開発キット（SDK）である AWS Neuron に注力しています。Neuron は、Meta の Llama 2、Databricks の MPT、mistral.ai の Mistral、Stability AI の Stable Diffusion を含む、人気のある一般公開モデルをサポートし、モデルリポジトリである Hugging Face のトップ 100 モデルのうち 93 モデルをサポートしています。PyTorch や TensorFlow のような ML フレームワークにプラグインでき、JAX のサポートは 2024 年初頭に予定されています。AWS の顧客が、既存のモデルトレーニングや推論パイプラインを、わずか数行のコードで Trainium や Inferentia に簡単に切り替えられるように設計されています。 生成 AI のための AWS クラウドストレージの進化 AWS がトレーニングと推論のパイプラインを加速させているもう 1 つの方法は、ストレージパフォーマンスの改善です。これは、最も一般的な ML タスク（大規模な GPU やアクセラレーターのクラスターへのトレーニングデータのロードなど）を考えるときだけでなく、チェックポイントや推論リクエストの処理にとっても重要です。AWSは、ストレージリクエストの速度を加速し、コンピュートリソースのアイドル時間を短縮するためのいくつかの改善を発表しました。これにより、生成 AI ワークロードをより速く、効率的に実行できます。 より正確な予測を得るために、生成 AI ワークロードは大規模なデータセットを使用しており、膨大なデータ量を処理するために高性能なストレージが必要です。 Amazon S3 Express One Zone は、組織で最も頻繁にアクセスされるデータのために設計された高性能かつ低レイテンシーのオブジェクトストレージの新しいストレージクラスです。これは、ML のトレーニングや推論のようなリクエスト集中型の処理に最適です。Amazon S3 Express One Zone は、AWS リージョン内のどのアベイラビリティゾーンからでも、Amazon S3 標準クラスよりもデータアクセス速度が最大 10 倍速く、リクエストコストが最大 50 %低い、低レイテンシーのクラウドオブジェクトストレージです。 AWS は ML フレームワークのためのデータアクセス速度も継続的に最適化しています。最近、 Amazon S3 Connector for PyTorch がローンチされ、Amazon S3 への既存の PyTorch コネクタよりも最大 40% 速くトレーニングデータをロードできるようになりました。ほとんどの顧客は、 Mountpoint for Amazon S3 や Amazon S3 Connector for PyTorch を使用してトレーニングや推論の要件を満たすことができますが、一部の顧客は独自のカスタムデータローダーを構築して管理しています。Amazon S3 と Amazon EC2 Trn1、P4d、P5 インスタンス間で最速のデータ転送速度を実現するために、AWS は最近、 AWS Command Line Interface (AWS CLI) と Python SDK で Amazon S3 のデータ転送を自動的に高速化する機能 を発表しました。トレーニングジョブは Amazon S3 からトレーニングデータを最大 3 倍高速にダウンロードし、Scenario のような顧客は、コードを 1 行も書くことなくモデルのダウンロード時間を 5 倍スループット向上させるなど、すでに大きな成果を得ています。 生成 AI ワークロードのトレーニングで要求されるパフォーマンス要件の変化に対応するため、Amazon FSx for Lustre は スループットのオンデマンドスケーリング を発表しました。これは、俊敏かつ低コストで要件を満たすようにファイルシステムのスループット階層を調整できるため、モデルトレーニングに特に有用です。 生成 AI のための AWS ネットワークの進化 昨年、AWS は EC2 UltraCluster 2.0 を発表しました。これは、P5 インスタンスと将来の ML アクセラレーター専用に最適化された、フラットで広いネットワークファブリックです。これにより、レイテンシーを 16% 削減し、最大 20,000 基の GPU をサポートし、全体の帯域幅を最大 10 倍にすることができます。従来のクラスター構成では、一般的にクラスターが物理的に大きくなるとレイテンシーも大きくなる一方で、UltraCluster 2.0 では、AWS はクラスターのサイズを拡大しながらレイテンシーを短縮します。 AWS は、ネットワークの効率化も支援し続けています。例えば、最近発表された Amazon EC2 Instance Topology API はインスタンス間の近接度を内部的に確認できるので、ジョブを戦略的に配置できます。最適化されたジョブスケジューリングにより、分散ワークロードの処理を高速化します。最も頻繁にデータをやり取りするジョブをクラスタ内の同じ物理的な場所に移動させることで、データパス内の複数のホップを排除できます。モデルが限界を押し広げる中、このようなソフトウェアの革新は、ハードウェアを最大限に活用するための鍵となります。 AWSは Amazon Q （AWS の生成 AI 搭載アシスタント）に加え、 Amazon Q networking troubleshooting (preview) も開始しました。 現在の AWS アカウントで、ネットワークの設定ミスに起因するネットワーク接続の問題のトラブルシューティングを Amazon Q にサポートしてもらうことができます。この機能では、 Amazon QはAmazon VPC Reachability Analyzer と連携して接続をチェックし、潜在的な問題を特定するためにネットワーク構成を検査します。Amazon Q network troubleshooting では、ネットワークに関する質問を会話形式で行うことができます。例えば、「Why can’t I SSH to my server?」や「Why is my website not accessible?」（2023/02 時点、日本語未対応）と尋ねることができます。 まとめ AWS は、価格性能、持続可能性、使いやすさに重点を置いたオプションを含め、お客様のインフラストラクチャにさらに多くの選択肢を提供します。昨年このスタック全体にわたる AWS の機能は、お客様のニーズに応えること、および「生成 AI をあらゆる規模や技術力のお客様が利用できるようにすることで、実現できることの革新や変革をサポートする」という目標に向けた取り組みを強化しました。 その他のリソース AWS 生成 AI インフラストラクチャの詳細は、 AWS Machine Learning インフラストラクチャ のページをご覧ください。 AWS がどのようにアプリケーション、ツール、インフラストラクチャに渡って生成 AI をクラウドで構築しているかの詳細は、ブログ「 Welcome to a New Era of Building in the Cloud with Generative AI on AWS 」をご覧ください。

お客さまから、 Amazon Relational Database Service (Amazon RDS) と Amazon Aurora データベースでのワークロードパフォーマンスの可視性と監視性、および予定されたイベントと予定外のイベントの可視性と監視性を改善する方法についてよく聞かれます。この記事では、計測機能をプロアクティブに有効化して設定し、すべての詳細をキャプチャし分析できるようにする方法について説明しています。 私は 8 年間、AWS のお客さまが Amazon RDS と Aurora でデータベースを使用するという目標を達成できるよう支援してきました。その間、top や vmstat コマンドが自己管理型データベースで提供する、より詳細なオペレーティングシステムのメトリクスに関心を持つシステム管理者の皆さんや、Amazon RDS Multi-AZ インスタンスがスタンバイアベイラビリティーゾーンにフェイルオーバーした理由を知りたがっている DBA の皆さんと仕事をしてきました。この記事では、上記の情報などを提供するさまざまな監視ツールの概要を説明し、各ツールに関する追加のヒントを示し、各ツールの仕組みについてより深く説明したい場合に利用できるリソースを紹介します。 この話題に関する動画を見たい場合は、 Amazon RDS と Aurora によるパフォーマンスモニタリングに関するこの AWS re:Invent 2022 セッション が最適です。 Amazon RDS と Aurora のツール まず、Amazon RDS と Aurora に固有のツールから始めましょう。この記事の後半では、RDS と Aurora の使用状況に関する具体的なインサイトを提供する、他の AWS サービスについても説明します。 Performance Insights Amazon RDS Performance Insights は、軽量な方法を使用してデータベースセッションとクエリのパフォーマンスメタデータをキャプチャし、それをインスタンスの CloudWatch メトリクスと組み合わせて、事前設定されカスタマイズ可能なダッシュボードに統合されたビューを提供します。特に気に入っているのは、どのクエリが最も長く、最も頻繁に実行されているかを、1秒単位まで掘り下げて確認できることです。このパフォーマンスに関するメタデータは、Performance Insights がお客さまのワークロードに与える影響を最小限に抑えるため、データベースインスタンスの外部に保存されます。データベースパフォーマンスの履歴を把握し、特定のクエリが以前と比較して現在どのように実行されているかを確認できるように、すべての本番インスタンスで常に有効にし続けておくことをお勧めします。詳細については、「 Amazon RDS での Performance Insights を使用したDB 負荷のモニタリング 」を参照するか、 パフォーマンスインサイトを使用してクエリパフォーマンスをトラブルシューティングする簡単な例 をご覧ください。 Cool fact: Performance Insightsを有効にしたり、保存期間を変更したりしても、データベースのダウンタイムや中断は発生しません。さらに、デフォルトの7日間のデータ保持には追加費用はかかりません。 推奨: パフォーマンス問題のトラブルシューティングを行う場合は、Performance Insights のデータ保持期間を一時的に延長して、原因と解決策が見つかるまでパフォーマンスデータ (問題発生前と問題発生中のもの) を保存することをお勧めします。 Amazon Aurora MySQL 互換エディション 、 Amazon Aurora PostgreSQL 互換エディション 、および Amazon RDS for PostgreSQL インスタンス使用時のボーナス: これらのデータベースエンジンでは、 Amazon DevOps Guru for RDS を使用してパフォーマンスインサイトを拡張できます。これは、データベース関連のパフォーマンスの問題 (リソースの使いすぎや特定の SQL クエリの不適切な動作など) を検出し、すぐに通知し、診断情報を提供する、機械学習 (ML) 搭載の機能です。問題の解決に役立つ推奨事項が表示されます。 このビデオでは、Amazon DevOps Guru for RDS のデモを紹介しています 。 拡張モニタリング 2015 年 12 月に Amazon RDS 拡張モニタリング機能の開始が発表 されたとき、私がどれほど興奮していたかを今でも覚えています。それ以前は、Linux プロンプト上で top、vmstat、iostat を実行した場合のような、RDS インスタンスのパフォーマンスに関するより詳細な情報を求められることがよくありました。拡張モニタリング にはそれだけでなく、50 種類を超えるさまざまなメトリクスが収集されているエンジンもあります。私が特に気に入っている拡張モニタリングの機能は、次の 2 つです。: 抽出されたメタデータは Amazon CloudWatch Logs に書き込まれ、そこで生のメトリクス値にインタラクティブかつプログラム的にアクセスできるため、メタデータを分析する独創的な方法が可能になります。たとえば、サードパーティのモニタリングツールを使用してデータを取得し、アプリケーションのパフォーマンスと関連付けることができます。また、メトリクスは RDS や Aurora インスタンス自体には書き込まれないため、拡張モニタリングを有効にしてもデータベースへのオーバーヘッドは最小限に抑えられます。さらに、 拡張モニタリング自体には別途料金はかかりませんが、CloudWatch Logs では拡張モニタリングのデータ転送とストレージに対して通常の料金が請求される 点にも注意してください。大事なことを言い忘れましたが、拡張モニタリングのメタデータにおけるデフォルトの保持期間は 30 日ですが、CloudWatch Logs 自体で ロググループの保持設定 を変更できます。 拡張モニタリングが使用するデータ収集間隔は、1、5、10、15、30、または 60 秒に設定できます (60 がデフォルト、1 が最も詳細です)。2 つの理由から、特に 1 秒間隔が気に入っています。1 つは、1 秒間隔はPerformance Insights がデータベースメタデータの収集に使用する間隔と一致していること、もう 1 つは、クエリの待ち時間の増加につながる非常に短時間の過負荷 (通常は CPU、I/O、またはネットワーク) を示すために最適な間隔だからです。 cool fact: 拡張モニタリングを有効にしたり、収集間隔を変更したりしても、データベースのダウンタイムや中断は発生しません。 推奨: パフォーマンス問題のトラブルシューティングを行う場合は、データベースにアクセスするワークロードのパフォーマンスプロファイルが明らかになるまで、拡張モニタリングのデータ収集間隔を一時的に1秒に設定することをお勧めします。これは、各ユーザーのアクションがデータベース内のデータへのクエリや変更を直接トリガーできる、インターネットベースのアプリケーションを提供するデータベースにとって特に重要です。1分毎のメトリクスではCPU使用率が 100% に遠く及ばないように見えるのに、拡張モニタリングの間隔を1秒に設定すると、ユーザの波が押し寄せた為に数秒だけ過負荷が発生することがわかった、ということを数多く経験しています。 拡張モニタリングについてもっと知りたいですか？詳細については、ブログ記事「 拡張モニタリングを使用した柔軟な解像度の Amazon RDS OS メトリクスのリアルタイムモニタリング 」を参照してください。 DBエンジンの主要なログファイル データベース管理者の同僚によると、データベースのエンジンアクティビティの主要なログファイルは、次の 2 種類のイベントに関する、主要な情報源の 1 つです。 チェックポイント、REDO ロギング、データブロックのディスクへのフラッシュなど、データベース内部の処理過程が疑われる場合 (ログを「checkpoint」「redo」「flash」などのキーワードで検索できます) 。 クラッシュ、フェイルオーバー、シャットダウン、または起動が発生した場合 (一般的なキーワードは、「start」「shut」「crash」または「ready」です) 。 Amazon RDS と Aurora では、これらのログファイルをデフォルトでお客さまが利用できるようになっているため、インスタンスから ログファイルを表示またはダウンロード できます。各エンジン毎に独自の命名規則があり、MySQL、MariaDB、SQL Serverはそれらを error logs と呼び、オラクルはそれらを alert logs と呼び、PostgreSQLはそれらを postgresql logs と呼びます。 Tip: エンジンログに関しては「ニュースがないのは良いニュースだ」ということわざが確かに当てはまります。特定の時間間隔でログがない場合は、エンジンが問題を警告する必要がないと判断したことを意味します。その間、シャットダウン、起動、クラッシュ、またはフェイルオーバーは発生しませんでした。 Cool fact: Amazon RDS と Aurora は自動的にログローテーションとログの保持を管理します。 推奨: 各エンジンには、記録される情報量を増やすために設定できるパラメーターがあります。これらの詳細については、エンジンのドキュメントを参照することをお勧めします。 追加のデータベースアクティビティ監査 一部のデータベースインスタンスでは、ワークロードの重要度によって、データベースで発生したすべてのことを記録しておきたい場合があります。誰が、どの IP アドレスから、何時にログインしたのか？先週の土曜日にテーブルがドロップされた時の正確なタイムスタンプはいつで、特定の時点への復元を正確に開始できるか？アプリケーションの設定でテーブルを更新したのは誰で、いつ更新したのか？データベース監査は、これらの質問に答えます。しかし、オーバーヘッドがあり、すべての顧客がそれを必要としているわけではないため、監査はインスタンスに対して有効にする必要があります。さらに、監査機能はデータベースエンジンによって提供されるため、それぞれに異なる有効化手順があります。Amazon RDS と Aurora の各データベースエンジンの監査を有効にする方法の詳細については、以下のリソースを参照してください。 RDS for MySQL、RDS for MariaDB、および Amazon Aurora MySQL 互換エディションでのデータベースアクティビティをキャプチャするように監査ログを設定する PostgreSQL を実行している Amazon RDS DB インスタンスを pgaudit 拡張機能を使用して監査するにはどうすればよいですか? データベースアクティビティストリームと pgAudit を使用して Aurora PostgreSQL データベースを監査する Amazon RDS for Oracle でのセキュリティ監査 Amazon RDS for SQL Server の DB インスタンスの監査 推奨: 非常にアクティブなインスタンスは大量のログを生成します。ワークロードにこのような特徴がある場合は、次のトピックを確認してください。 CloudWatch Logs によるログのクエリと保存 エンジンによっては、各エンジンの主要なログファイルや監査ログファイル以外にも便利なロギング形式があります。たとえば、MySQL や MySQL 互換のエンジンでは、定義した秒数以上かかるクエリを スロークエリログ に記録できます。これらのさまざまな形式のロギングを行う間に、ログファイルの数とサイズが大きくなる可能性があります。その一方、データベースインスタンスは、これらのログファイルを保存したりアクセスしたりするのに最適な場所ではありません。このため、Amazon RDS と Aurora には、 データベースログを CloudWatch ログに発行できる機能 があります。データベースログを CloudWatch Logs にエクスポートすることが良い理由は次のとおりです。 ディスク容量を節約するために、Amazon RDS と Aurora は定期的にログをローテーションし、インスタンスから削除しています。一方、CloudWatch Logs の ログの保存期間はユーザーが定義でき、期限切れにならないように設定することもできます。 大きなファイルまたは大量のファイルをデータベースインスタンスから直接ダウンロードすると、インスタンスの I/O リソースを大幅に消費する可能性があります。しかし、ログをCloudWatch Logs から読み取っても、データベースインスタンスのパフォーマンスには、ほとんど、またはまったく影響しません。 CloudWatch Logs には非常に優れた 検索機能とフィルタリング機能 があり、必要なログをすばやく簡単に特定してアクセスできます。 CloudWatch Logs では、 ログに特定のキーワードが見つかったときに通知を設定できます 。 Aurora インスタンスは、インスタンスにアタッチされた一時ディスクにログを保存します。このため、インスタンスに障害が発生して交換された場合、ログが失われる可能性があります。しかし、ログをCloudWatch Logsに発行することで、最新のわずかな部分を除いてすべてが保存されます。 注意事項: ほとんどのログはお客さまにて有効化される必要があるため、もしもログが生成されていない場合は、CloudWatch Logs にログをエクスポートするようにインスタンスを設定するだけでは不十分です。 推奨: CloudWatch Logs と、AWS Lambda、Amazon SNS、その他の AWS ソリューションを組み合わせて使用することで、プロアクティブで自動化された RDS ログ分析およびアラート機能を構築できます。 RDS イベント RDS イベントは、Amazon RDS のあまり知られておらず、活用されていない機能の 1 つであると同時に、非常に便利な機能でもあります。エラーログファイルを監視してデータベース内で何が起こっているかを知ることが重要であるのと同じように、 RDS イベントを監視 して、データベースを支えている RDS 基盤で何が起こっているかを知ることも同様に重要です。 Cool fact 1: イベント「Recovery of the DB instance has started. Recovery time will vary with the amount of data to be recovered. (DB インスタンスの復旧がスタートされました。復旧時間は、復旧するデータの量に応じて変わります。) 」これは、インスタンスのハードウェアが復旧中であることを意味します。Amazon RDS の復旧は、新しい Amazon Elastic Compute Cloud (Amazon EC2) ホストに移行して、ハードウェアを交換することによって行われます。リカバリにかかる時間は場合によって異なりますが、以下の 2 つの理由によります。まず、新しいホストのプロビジョニングには時間がかかります。次に、新しいホストが作成され、データベースプロセスが起動すると、プロセスがクラッシュリカバリを開始します。クラッシュリカバリは、リカバリ前の状況に応じて、短時間で完了する場合もあれば、時間がかかる場合もあります。エンジンはそれぞれ異なっており、クラッシュリカバリに関するデータベースエンジンのマニュアルを確認することをお勧めします。 Cool fact 2: イベント「The RDS Multi-AZ primary instance is busy and unresponsive (RDS Multi-AZ プライマリインスタンスはビジーで応答しません) 」このイベントは、数少ない RDS Multi- AZ フェイルオーバーの原因のうちの 1 つであり、すぐに通知を受けることができます。このイベントが発生した場合は、この記事で紹介した他の監視ツールをさらに活用する必要があります。そうすることで、インスタンスがなぜ応答不能になるほどビジー状態となったのかを突き止めることができます。 Amazon RDS はとりわけ、インスタンスとクラスターのイベントを生成します。過去 24 時間は Amazon RDS コンソールでアクセスでき、過去 14 日間は、 AWS コマンドラインインターフェイス (AWS CLI) や SDK などを使用してプログラム的にアクセスできます。しかし、私が本当にお勧めするのは、 イベント通知サブスクリプション を有効にすることです。これにより、送信先とデータ保持を定義できます。 推奨: すべてのクラスターとインスタンスのすべてのイベントに、イベント通知サブスクリプションを設定し (個別に挙げる必要はなく、この設定であれば後から作成したリソースにも適用されます)、専用のメールアドレス、または、Amazon RDS での 14 日間の保存期間が経過した後でも検索や読み取りが可能なその他の長期保存ストレージに配信するように設定します。 Amazon RDS CloudWatch メトリクス RDS と Aurora の各インスタンスは、追加費用なし、設定なしですぐに使える、 1 分間隔の、 数十の CloudWatch メトリクス を収集し公開します。Amazon RDS コンソールには、インスタンスの現在のステータスを一目で確認できる便利なインターフェイスがありますが、メトリクスの分析と相関付けを行うため、CloudWatch のより強力なメトリクス管理専用インターフェイスの方が私は好きです。 Cool fact: RDS メトリクスは 15 か月間保存されますが、解像度の高いメトリクスは CloudWatch によって定期的に集計されます 。たとえば、15 日が経過すると、1 分毎のデータは表示されなくなりますが、5 分毎のデータは引き続き表示されます。また、各期間の 5 つのデータポイントは集計されたため、最小値、平均値、最大値を確認できます。 Tip: Amazon RDS は、インスタンスの名前を使用してメトリクスを CloudWatch に保存します。これには 2 つの影響があります。まず、インスタンスの名前が変更されると、メトリクスが消去されたように見える場合がありますが、実際にはメトリクスは古い名前に関連付けられており、CloudWatch コンソールからアクセスできます。次に、インスタンスが削除され、同じ名前で別のインスタンスが作成 (または復元) された場合、新しいインスタンスには以前のインスタンスのメトリクスも表示されるため、作成前のメトリクスがあるように見えます。 Aurora使用時のボーナス: Aurora は、インスタンスのメトリクスの公開に加えて、同じメトリクス値をクラスター名にも公開します。インスタンスがライターかリーダーかによって、WRITER ロールまたは READER ロールにも公開されます。次の点に注意してください。 クラスターメトリクスは、インスタンスのCPU使用率が 90% を超えた場合にアラームを設定するなど、インスタンスの削除や追加に関係なく機能するクラスター全体のアラームを設定する場合に非常に役立ちます。また、ある時点でクラスターにどれだけの正常なインスタンスがあったかを知るのにも役立ちます。また、SampleCount 統計値を使用して、1 分毎にメトリクスを報告したインスタンスの数を知ることができます。 クラスターの WRITER ロールに関するメトリクスは、フェイルオーバーによって異なる時点でクラスターのライターが 2 つ以上のインスタンスになった場合でも、クラスターの過去のライターパフォーマンスを一貫して確認できる優れた方法です。いちどにただ1つのインスタンスが、このロールに対してレポートします。 クラスターの READER ロールのメトリクスは、 Application Auto Scaling が必要に応じてクラスターにリーダーを追加または削除するような場合に使用するメトリクスです。ただし、これらのメトリクスは、クラスター上の少なくとも 1 つのインスタンスがリーダーである場合にのみ表示されます。このため、Auto Scaling が有効なクラスターには常にライターとリーダーが必要です。 さらに、これらのメトリクスで CloudWatch アラームを作成 することもできます。ただし、おそらく使用するエンジン毎に異なる、重要なものに対してのみ作成したいと思うでしょう。たとえば、PostgreSQLの場合、 トランザクション ID のラップアラウンドを防ぐための アラームを設定したいと思うかもしれません。 Pro tip: 特定のメトリクス (またはインスタンスのすべてのメトリクス) のデータが欠落していることは、メトリクスの高い値が意味していることと同じくらい重要です。データベースインスタンス内の RDS エージェントがメトリクスの値を CloudWatch にプッシュするため、インスタンスのすべてのメトリクスが欠落しているということは、インスタンスに過負荷または障害が発生している可能性があることを示しています。同様に、一部のメトリクスは表示されているが他のメトリクスは表示されない場合、それが何かを意味している可能性があります。 たとえば、CPU利用率 (およびその他のOSベースのメトリクス) の値は見えるが、レプリカの遅延 (またはその他のデータベースベースのメトリクス) は見えない場合、私はそれを不審に思い、他の点では正常なホストでデータベースプロセス自体に障害が発生していないかどうかを確認する他の手段を探すことになります。 AWSサービス このセクションでは、他の AWS サービスが、Amazon RDS や Aurora のインサイトを補完する具体的なインサイトをどのように提供するかについて説明します。 AWS CloudTrail データベースの監査によって、データベース接続を通じてデータベースに送信されたコマンドを記録して知ることができるのと同様に、 AWS CloudTrail では、Amazon RDS や Aurora などを含めたAWS サービスに対して、さまざまな手段 (CloudTrail コンソール、AWS CLI、CDK、サードパーティツール、エンドポイントへの直接の API 呼び出しなど) を通じて AWS アカウントに送信されたすべての API 呼び出しを、ログに記録 して知ることができます。 Cool fact: CloudTrail には、過去 90 日間の API 呼び出しを保存するイベント履歴がデフォルトで用意されています。このイベント履歴を保存するために何かを有効にしたり設定したりする必要はありません。 推奨: オプションの 証跡 を有効にすると、 Amazon Simple Storage Service (Amazon S3) バケットにイベントが配信されて保存され、必要に応じて保持期間を設定できます。 AWS Health AWS Health は、AWS サービスのパフォーマンスと可用性、およびこれらがアカウントに与える影響について、AWS がお客さまに知らせる方法です。これは、2 つの部分からなります。1 つは、公開情報でありアクセスに認証を必要としない サービスの状態 (Service Health) ページ で、もう 1 つはアカウントのリソースに固有の情報を提供する アカウントの状態 (Account Health) ページ です。 推奨 1: RDS と Aurora のインスタンスとクラスターの アカウントの状態 ページには、想定どおりに動作しない状況に関する情報に加えて、今後のメンテナンスや必要なアップグレードに関する通知も表示されます。 アカウントの状態ページ の [その他の通知] タブを確認することを忘れないでください。 推奨 2: AWS アカウントに関連付けられているメールアドレスには、Health イベントに関するメールも送信されます。これらは、検索できるフォルダに長期間保存することをお勧めします。 Amazon VPC Amazon Virtual Private Cloud (Amazon VPC) には、接続問題のトラブルシューティングに役立ついくつかの機能があります。 VPC フローログ VPC フローログ は、VPC 上のネットワークインターフェイスに出入りする IP トラフィック (および TCP 接続) に関する情報を提供します。 推奨: 接続がどこから、どのボリュームまたはレートで接続されているかを把握するために、必要に応じて使用してください。これは、新しい接続ストームやスパイクが疑われる場合に非常に役立ちます。 VPC トラフィックミラーリング お客さまからよく聞かれるもう 1 つの質問は、「RDS または Aurora インスタンスでパケットキャプチャを実行できますか?」というものです。その答えは「はい、思っているよりも簡単に出来ます」です。RDS や Aurora インスタンスに触れることなく、お客さま自身で実行できるからです。 VPC トラフィックミラーリング には、 (VPC 内の他の ENI と同じように) RDS または Aurora ENI からのトラフィックを、パケットキャプチャユーティリティ (pcap や Wireshark など) が実行されている EC2 インスタンスにミラーリングする機能があります。ネットワークや接続の問題が疑われる場合のトラブルシューティングとして、この方法をお勧めします。 Cool fact: 複数のクライアントからのトラフィックを一度にキャプチャするため、複数のクライアント上でそれを実施するよりもセットアップがはるかに簡単です。また、AWS サポートを利用しているかどうかに関係なくセットアップできるため、より迅速です。 推奨: ミラーリングされるすべてのパケットを受信できる能力を確保するために、ターゲットの EC2 インスタンスを、 RDS または Aurora インスタンスと少なくとも同じサイズに設定することを忘れないでください。 アプリケーションもしくはデータベースクライアント AWS、Amazon RDS、およびデータベースインスタンス自体から取得できる前述のすべての情報に加えて、クライアントマシン、つまりデータベースに接続しているマシンでのみ取得できる重要な情報があります。接続の問題など、セッション固有のエラーや警告は、データベース接続自体を通じてのみ報告されるため、接続をオープンするクライアントソフトウェアは、その情報をログに記録する必要があります。そうしないと、情報が失われます。 同様に、お客さまはしばしばデータベースのパフォーマンス上の問題を疑いますが、実際のパフォーマンス問題の原因が結局クライアントマシンだったと判明することがあります。 推奨 1: クライアントマシン上で、アプリケーションが接続固有のエラーを記録して保持するようにしてください。 推奨 2: データベース呼び出しやその他の操作を開始タイムスタンプと終了タイムスタンプと共に記録するような、デバッグモードを有効にするスイッチまたはオプションがアプリケーションにあるかどうかを確認します。 まとめ Amazon RDS、 Aurora のお客さまには、データベースのワークロードを監視するために使用できる、さまざまなツールがあります。 この記事では、どのような状況でどのツールを使用すべきかを説明し、各ツールが提供するものについて説明し、各ツールの詳細情報を参照するためのリンクを提供しました。 フィードバックや質問がある場合は、コメントセクションにコメントを残してください。 著者について Valter Rehn は AWS サポートの Principal Engineer です。彼はAmazon RDSとAmazon Auroraに焦点を当てており、2015年7月に Aurora バージョン1.0がリリースされて以来、Auroraの最適な使用方法についてお客さまにガイドしてきました。 翻訳はクラウドサポートエンジニアの立野が担当しました。原文は こちら です。

AWS 上で Infrastructure as Code (IaC) を利用することで、インフラストラクチャがスケールするように管理、モデリング、プロビジョニングできます。 AWS CloudFormation を使えば YAML や JSON でコードとしてインフラストラクチャを宣言できます。一般的なプログラミング言語を使って AWS Cloud Development Kit (CDK) を利用することもできます。 Application Composer で視覚的に管理することもできます。IaC 化されたリソースは、選択したバージョン管理システムで監査およびバージョン管理ができます。また、AWS CloudFormation を使ってデプロイすることで、 変更セット を使ったデプロイプレビュー、自動ロールバック、 Hooks を使ったリソースコンプライアンスのプロアクティブな適用などが可能になります。非常に多くのお客様が、AWS 上で IaC による安全性と信頼性の恩恵を受けています。 すべてのリソースが IaC で作成されるわけではありません。お客様はさまざまな理由で IaC 管理外のリソースを作成しています。IaC を知らなかったり、CLI や マネジメントコンソール で作業することを好む場合もあります。2019 年に、既存のリソースを CloudFormation に インポート する機能を発表しました。この機能は個々のリソースを IaC に取り込むうえでもはや必要不可欠ですが、デプロイ済みのリソースに合わせて手動でテンプレートを作成するプロセスは理想的ではありませんでした。お客様はリソースのドキュメントを調べ、パラメーターを手動でコピーする必要がありました。また、お客様はこれまで関連するリソースのグループとしてアプリケーションを扱っており、個々のリソースを扱うことはその経験と合致しないとのフィードバックもいただいています。そこで、リソースと関連するリソースをより包括的に管理する仕組みの作成に取り組むことにしました。 先日、リソースと関連するリソースに対して IaC のテンプレートを作成し、一貫した体験を実現する IaC ジェネレーター と CDK Migrate を発表しました。 これは、AWS アカウントをスキャンし、 CloudFormation リソースタイプスキーマ を使用してリソース間の関連情報を見つけることで機能します。 テンプレートが作成されると、既存のスタックにそれらのリソースをインポートするか、ゼロから完全に新しいスタックを作成するかのどちらかを選択できます。 リソースを再作成する必要はなく、アプリケーション全体を CloudFormation スタックで管理できるようになりました！ このブログでは、IaC ジェネレーター が解決する一般的なユースケースを紹介します。IaC ツールの外で作成された既存のネットワークアーキテクチャを CloudFormation で管理します。 IaC ジェネレーターの活用 次のシナリオを考えてみましょう: クラウド活用のプロセスを始めたばかりの組織に新入社員として入社し、チームの共有 Amazon Virtual Private Cloud (VPC) リソースの開発を継続するタスクが課せられました。 これらのリソースは現在、開発チームによってアクティブに使用されています。 調べてみると、これらのリソースは IaC を利用せずに作成されたことがわかりました。 ドキュメントはなく、セットアップした人はもうチームにいません。 問題をより複雑にしているのは、 サブネット 、 ルートテーブル 、 インターネットゲートウェイ などの関連リソースを含む複数の VPC があることです。 あなたは IaC のメリットである再現性、信頼性、監査可能性、安全性を理解しています。 これらのリソースを CloudFormation の管理下に置くことで、既存のリソースにもこれらのメリットが適用されます。 以前にもリソースを CloudFormation にインポートしたことがあるので、テンプレートを作成するために、関連するすべてのリソースを手動で見つける作業に取りかかります。しかし、すぐにこれは簡単な作業ではないことがわかりました。 VPC には他のリソースとの関連情報は保存されていません。その代わりに、関係性は逆になっています。リソースは自身が紐付く VPC を知っていますが、VPC は自身に紐付いているリソースを知りません。 VPC に関連するすべてのリソースを見つけるには、VPC 関連のすべてのリソースを手動で確認し、それらが属している vpc-id をスキャンする必要があります。 存在を認識していなかったり、異なるサービスのリソースであったりするためにリソースを見落としやすいので、注意深く確認する必要があります。 たとえば、 Elastic Network Interface (ENI) を使用して VPC にアタッチするリソースもあります。 Amazon Relational Database Service インスタンスなどがそうです。 しかし、あなたは最近 IaC ジェネレーターのことを知りました。 このジェネレーターは、アカウントのスキャンを実行してリソースの最新のインベントリを作成することで機能します。 CloudFormation は、リソースタイプスキーマを利用して、リソース間の関係性を見つけます。 たとえば、サブネットは vpc-id プロパティ経由で VPC との関係があると判断できます。 これらの関係性が決定されると、テンプレートを生成したいトップレベルのリソースを選択できます。 最後に、ウィザードを利用して、この既存のテンプレートからスタックを作成できます。 マネジメントコンソールの IaC ジェネレーターページに移動し、アカウントでスキャンを開始できます。スキャンは 30 日間有効で、1 つのアカウントで 1 日に 3 回スキャンを実行できます。 スキャンが完了すると、 テンプレートを作成 ボタンを選択してテンプレートを作成します。 新しいテンプレートから開始 を選択した後、 テンプレート名 やスタックポリシーなど、スタックに関する詳細を入力します。ここでは、 Retain (保持) のままにします。 次のページでは、スキャンされたすべてのリソースが表示されます。タグなどのフィルタをリソースに追加して、スキャンされたリソースのサブセットを表示できます。この例では、 Resource type prefix フィルタのみを使用します。フィルタの詳細については、 こちら をご覧ください。VPC を見つけたら、リストから選択できます。 次のページでは、CloudFormation がこの VPC とリンクしていると判断したリソースのリストが表示されます。 これには、さまざまなネットワーク関連リソースが含まれていることがわかります。 これらすべてのリソースを選択した状態でテンプレートを作成します。 この時点で、 テンプレートを作成 を選択すると、CloudFormation が既存のリソースからテンプレートを生成します。 これらのリソースをインポートする既存のスタックがないため、新しいスタックを作成する必要があります。 ここでこのテンプレートを選択し、 スタックにインポート ボタンを選択します。 スタック名 を入力した後、テンプレートが必要とする パラメータ を入力できます。 CloudFormation は、新しいスタックの変更セットを作成します。変更セットを使用すると、CloudFormation がスタックに適用する変更を確認できます。この例では、すべてのリソースが Import ステータスになります。CloudFormation が見つけたリソースが表示され、スタックを作成できます。 この時点で、スタックの作成操作は通常通り進み、各リソースをインポートしてスタックに取り込んでいきます。ネットワークスタック全体を正常にインポートできたことをチームに報告できます！次のステップとして、このテンプレートをバージョン管理システムでソース管理する必要があります。 私たちは先日、 CloudFormation テンプレートを一般的なバージョン管理システムと同期 できる新機能を発表しました。 最後に、 ドリフト を避けるために、CloudFormation を通じて変更を行うことを確認してください。 この例は主に CloudFormation ベースでしたが、CDK を利用されている方は CDK Migrate を使用して、この構成を CDK アプリケーションにインポートできます。 すぐにご利用いただけます！ IaC ジェネレーターは、CloudFormation がサポートされているすべてのリージョンで現在利用可能です。コンソール、CLI、SDK を使用して IaC ジェネレーターにアクセスできます。 おわりに このブログでは、CloudFormation の新しい IaC ジェネレーター機能を紹介しました。以前に存在していたリソースを管理する必要があるシナリオを辿り、IaC ジェネレーターの提供する手順に従って CloudFormation テンプレートを生成しました。次に、そのテンプレートを使用してスタックを作成し、これらのリソースを管理しました。 これらのリソースは、IaC が提供する安全性と反復可能性の恩恵を受けることができるようになりました。これはひとつの例に過ぎませんが、コンソールファーストの開発体験を可能にするなど、この機能の他のユースケースを想定しています。この機能についてのご意見をお聞かせいただけることを楽しみにしています。 ぜひ感想をお聞かせください！ 本記事は、Dan Blanco による Import entire applications into AWS CloudFormation を翻訳したものです。翻訳はソリューションアーキテクトの山崎宏紀が担当しました。

はじめに Amazon Elastic Container Service (ECS)  は、コンテナ化されたタスクを AWS インフラストラクチャにデプロイし、管理します。Amazon ECS を使用して、サーバーレスである AWS Fargate キャパシティにタスクをデプロイすることで、お客様はコンピューティングインスタンスを保守する必要がなくなります。しかし、Amazon Elastic Compute Cloud (Amazon EC2) をキャパシティとして Amazon ECS を使用することを好むお客様もいます。EC2 インスタンスをコンテナ実行のキャパシティとして使用すると、基盤となるコンピューティングインフラストラクチャをより細かく制御できますが、これにはメンテナンスのオーバーヘッドが増えるという欠点があります。従来、クラスターオペレーターは EC2 インスタンスで実行されているコンテナワークロードが予期せず中断されないように、EC2 インスタンスのメンテナンス用のカスタムツールを構築する必要がありました。Amazon ECS には、EC2 インスタンスで実行中のタスクをドレインし、それらのタスクを別のインスタンスに移動する機能が組み込まれています。これにより、元のインスタンスを置き換えたり終了したりすることができます。ただし、このドレイン機能を利用するには、 コンテナインスタンスをドレイン状態に設定し、すべてのタスクがドレインされるまでの間コンテナインスタンスをドレイン状態にする、Auto Scaling ライフサイクルフックを利用したカスタムソリューションを、お客様自身で実装する必要がありました。 Amazon ECS では、Amazon ECS キャパシティプロバイダーの組み込み機能としてマネージドインスタンスドレインが提供されるようになりました。この新機能により、Amazon ECS は Amazon ECS キャパシティプロバイダーに関連付けられた Amazon EC2 Auto Scaling グループの一部である EC2 インスタンスから、タスクを安全かつ自動的にドレインできるようになりました。この簡素化により多くの Amazon ECS のお客様は、これまで EC2 インスタンスのドレインに使用していたカスタムライフサイクルフックが不要になります。お客様は、Auto Scaling グループインスタンスの更新をシームレスに利用することで、ワークロードを中断させずに ECS エージェントの新しいバージョンのロールアウトのようなインフラストラクチャの更新を実行できるようになりました。 インスタンスの更新とドレインについて EC2 Auto Scaling グループは、EC2 インスタンス群をスケールアウトするための主要なメカニズムです。Auto Scaling グループに属する EC2 インスタンスは、インスタンスタイプと EC2 インスタンスのベースとなる Amazon マシンイメージ (AMI) を定義する起動テンプレートを使用して設定します。Amazon ECS の場合は、 ECS に最適化された AMI をベースにした EC2 インスタンスを起動できます。この特別な AMI には、インスタンスを Amazon ECS クラスターに接続し、ホストでコンテナワークロードを起動するために必要なものがすべて付属しています。Amazon ECS の新機能や、基盤となるホスト OS のバグやセキュリティ脆弱性に対するパッチを提供するために、ECS に最適化された AMI の新しいバージョンが定期的にリリースされています。 Auto Scaling グループインスタンスの更新 は、クラスター内の EC2 インスタンスを稼働させている AMI を更新するための 1 つのソリューションです。Amazon ECS に最適化された AMI の最新バージョンを参照する新しい起動テンプレートは、Auto Scaling グループの EC2 インスタンスの再起動に役立ちます。 EC2 Auto Scaling グループの AMI アップデートをトリガーするには様々な方法があります。EventBridge Scheduler と Lambda 関数を使用して定期的にインスタンスの更新をトリガーすることで、インスタンスの更新を自動化したい場合があります。AWS CloudFormation または AWS Cloud Development Kit (AWS CDK) を使用したい場合は、 UpdatePolicy 設定 を使用して、EC2 インスタンスのコード駆動型ローリング更新としてインフラストラクチャを設定することもできます。 EC2 インスタンスをどのように更新しても、Auto Scaling グループの一部である EC2 インスタンスは置き換えられます。タスクの実行中に EC2 インスタンスを停止して交換すると、それらのタスクも停止します。Amazon ECS は、Amazon ECS サービスの一部のタスクが失われたことを検出します。サービスの希望するタスク数を維持するために、Amazon ECS はクラスター内の別の EC2 インスタンスで代替タスクを起動します。しかし、これは事後対応型のフェイルセーフであり、コンテナがすでに停止していて、サービスの実行中タスク数がすでに希望タスク数を下回った後にのみ発生します。 マネージドインスタンスドレインは、事後対応型ではなく事前対応型です。EC2 インスタンスが Auto Scaling グループによって終了するように設定されるたびに、Amazon ECS はインスタンスの終了を一時的に遅らせ、インスタンスを自動的にドレインモードにします。このドレインモードでは、インスタンスでこれ以上タスクが起動されなくなり、インスタンスで実行中のサービス起動タスクはすべて積極的に新しいホストに置き換えられます。タスク置換では、ドレイン中の EC2 インスタンスで現在実行中の既存のタスクを停止する前に、新しい置換タスクを起動しようとします。ドレイン動作の詳細については、Amazon ECS の公式ドキュメント コンテナインスタンスドレイン をご覧ください。 新しいマネージドインスタンスドレインは、ワークロードの実行と可用性を維持するために設計された次の Amazon ECS 機能と相互作用します。 マネージド終了保護 Auto Scaling グループにアタッチされた Amazon ECS キャパシティプロバイダーを設定する場合、Amazon ECS で利用できるオプションの 1 つにマネージド終了保護があります。これにより、Amazon ECS タスクを実行している EC2 インスタンスをスケールインから保護できます。有効にすると、Auto Scaling グループのスケールイン中は、1 つ以上のタスクを実行している EC2 インスタンスを停止できなくなります。マネージド終了保護は、あらゆる形態の EC2 インスタンスの終了を防ぐわけではありませんが、EC2 インスタンスをドレインする必要がある状況の多くを防ぐことができます。しかし、それでもなお、マネージド終了保護とマネージドインスタンスドレインの両方を有効にすることは良いことです。両方の機能を有効にすると、本番環境のワークロードの中断から最大限の保護を受けることができます。マネージド終了保護により、さまざまなタイプの破壊的な EC2 インスタンス停止を防ぐことができます。また、マネージドインスタンスドレインにより、EC2 インスタンスを終了する必要が生じた場合でも、実行中のワークロードが適切に処理されます。 停止タイムアウト Amazon ECS タスクを定義するときに、タスクの停止タイムアウトを指定できます。指定しない場合、この停止タイムアウトはデフォルトで 30 秒になります。Amazon ECS は EC2 インスタンスをドレインしているときに停止が必要な各タスクコンテナに SIGTERM 停止信号を送り、停止タイムアウトの時間を待ってコンテナが正常に終了するかどうかを確認します。停止タイムアウトが経過してもコンテナが正常に終了しない場合、Amazon ECS はコンテナのプロセスを強制停止するために  SIGKILL  信号を送ります。すぐには完了できないような重い作業がタスクで行われている場合は、タスクの停止タイムアウトを長く設定できます。マネージドインスタンスドレインでは、タスクが自動的に正常終了するか、停止タイムアウト期間を超えて Amazon ECS がタスクを強制停止するまで、EC2 インスタンスをドレイン状態のままにします。ただし、Amazon ECS のタスクの停止タイムアウトは、希望すれば何年も待機するように設定できますが、EC2 のドレイン期間は 48 時間を超えることはできません。したがって、タスク停止タイムアウトを 48 時間以上に設定することはお勧めできません。 タスク保護 Amazon ECS では、実行中のタスク自体を保護対象としてマークすることができます。この機能は、タスクが重要な作業を行っている最中であり、そのタスクを停止してはいけないことを Amazon ECS に伝えます。マネージド終了保護を使用している場合、保護されたタスクを実行しているインスタンスは、Auto Scaling グループのスケールインの一環として停止されないようにすでに部分的に保護されています。ただし、マネージド終了保護が無効になっている場合、Amazon EC2 Auto Scaling グループは EC2 インスタンスに保護されたタスクがあるかどうかを確認しません。さらに、Amazon ECS のマネージド終了保護によってスケールインから保護されている場合でも、EC2 インスタンスの更新によるインスタンスの置き換えができるように設定できます。Auto Scaling グループは引き続き、保護されたタスクをホストしている EC2 インスタンスを終了することを選択できます。これにより EC2 インスタンスはドレイン状態になり、インスタンスで実行中のタスクはタスク保護の状態に関係なく、すぐに SIGTERM   停止信号を送ります。タスクで停止タイムアウトを使用してタスクフォースの終了を遅らせ、EC2 インスタンスを最大 48 時間ドレイン状態に保つことができます。 一般的に、タスク保護機能を使用する予定のタスクには停止タイムアウトを設定するのがベストプラクティスと考えられています。さらに、EC2 でホストされるミッションクリティカルなタスクであれば、 Amazon ECS メタデータエンドポイント を使用してタスクをホストしているインスタンスの ID を検出し、 Amazon EC2 ModifyInstanceAttribute API を使用して、タスクをホストする EC2 インスタンスに disableApiStop 属性または disableAPItermination 属性を設定すると良い場合があります。これにより、EC2 インスタンスの自動停止アクションに対する保護が強化されます。 RunTask API で起動されたスタンドアロンタスク サービスが起動したタスクはレプリカセットの一部であり、サービスはいつでも他の EC2 インスタンスで追加のタスクを起動できるため、EC2 インスタンスから安全に削除できます。ただし Amazon ECS では、RunTask API で起動されたスタンドアロンタスクをドレインしません 。むしろ、Amazon ECS はこれらのタスクが自動的に終了するのを待ちます。これらのタスクが実行されている限り、Amazon EC2 インスタンスはドレイン状態のままになります。Amazon EC2 インスタンスは、最大 48 時間までドレイン状態のままでいることができます。それ以降は、 RunTask  によって起動されたか CreateService  によって起動されたかにかかわらず、インスタンス上のすべてのタスクが強制停止されます。 まとめ 新しい Amazon ECS マネージドインスタンスドレイン機能は、公開コンテナロードマップの機能リクエストから生まれました。 オープンソースの RFC には、Github で 300 件以上のリアクションが寄せられました。Amazon ECS の将来への継続的な関心と関与に感謝するとともに、AWS にコンテナを大規模にデプロイしやすくする強力な機能を引き続き提供できることを嬉しく思います。独自の機能リクエストがある場合は、公開ロードマップに問題を提起するか、既存の機能リクエストに賛成票を投じて関心を示してください。 マネージドインスタンスドレインを開始するには、Amazon ECS ドキュメントを参照して、キャパシティプロバイダーと Auto Scaling グループに マネージドインスタンスドレインを有効にする方法の詳細 を確認してください。 本記事は Amazon ECS enables easier EC2 capacity management, with managed instance draining  (2024 年 1 月 19 日公開) を翻訳したものです。翻訳は、ソリューションアーキテクトの吉田が担当しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 2月になりました。私は東京在住なのですが、人によってはそろそろ花粉の兆しを感じる、といっている方も出始めてきましたね。私もスギ花粉症があるので、そろそろ薬を飲み始めようかなと思っています。私は3年前に舌下免疫療法という、スギ花粉を定期的に摂取してアレルギー反応を弱める治療を始めたのですが、幾分か症状が軽くなったような気がします。でも、スギ花粉の量にもよるでしょうし、なんとも判断しづらい感じですね……。 さて、2月22日には AWS Innovate が開催されます。今回はAI/ML and Data editionというテーマでお送りします。昨年からのホットなトピックである生成AIが主軸ですが、お客様と会話をしていると「どうやれば実務を良くするために利用できるか」というポイントに興味の軸足が移ってきているように感じます。今回のAWS Innovateでは既存のモデルを利用したい方、モデル開発にチャレンジしたい方、ビジネスへの応用を考えている方、それぞれに興味を持っていただけるコンテンツを用意しましたので、ぜひご参加ください。 それでは、1 月 29 日週のアップデートを振り返ってみましょう。 2024 年 1 月 29 日週の主要なアップデート 1/29(月) Amazon EC2の属性ベースのインスタンス選択利用時に評価される価格保護ルールを追加 Amazon EC2 AutoScalingやEC2 FleetではvCPUやメモリなどインスタンスの属性に基づいて、スケーリングを実行することが可能です。今回のアップデートで、スポットインスタンス利用時の価格に基づいた制御を行うことが可能になり、コスト効果を最大化するためのルールを定義しやすくなりました。 Amazon RDS for Db2で照合順序としてEBCDICに対応 Amazon RDS for Db2がEBCDICによる照合順序をサポートしました。EBCDICによる照合順序を利用することが多いz/OS上のDb2からAmazon RDS for Db2に移行する場合に便利な機能です。従来の照合順序を維持することができるので、アプリケーション改修量の削減が期待できます。 1/30(火) AWS GlueのAmazon Q data intergration機能をプレビュー開始 自然言語を利用してデータ統合ジョブを構築できるようにすることでジョブ構築を容易にする新機能、Amazon Q data integrationのプレビューを開始しました。この機能は生成AIの技術に基づいており、自然言語でワークロードを説明すると、Glueのスクリプトが生成されます。詳細については ブログ もぜひ。 1/31(水) Amazon Aurora PostgreSQLがPostgreSQL 16.1をサポート PostgreSQL互換のAmazon Auroraで、PostgreSQLの バージョン16.1 がサポートされました。Auroraの リリースノート もご確認ください。 2/1(木) Amazon EC2の無料利用枠に750時間/月のIPv4アドレス利用を追加 2023年7月に発表したパブリックIPv4アドレスに対する新しい料金体系 が、2月1日より適用になりました。これと関係して、Amazon EC2のAWS無料利用枠に月間750時間のIPv4アドレス利用料が含まれるようになりました。 Amazon Monitronを静的IPアドレスベースで利用可能に Amazon Monitronは、センサーからのデータをゲートウェイデバイスを経由してAWSクラウドに安全に転送します。従来、ゲートウェイデバイスから”amazonaws.com”のサブドメイン全体に対して接続性が必要で、ファイアウォールの設定が難しいというフィードバックをいただいていました。今回、接続先が リージョン毎に異なる固定IPアドレス になり、ファイアウォールの設定が容易になりました。 Amazon Rekognitionでコンテンツモデレーションの新モデルを利用開始 Amazon Rekognitionでは不適切なコンテンツを検出する、コンテンツモデレーション機能を提供しています。今回、新しい機械学習モデルが導入され、精度向上とともにモデレーション結果として付与されるラベルが詳細化されました。また、アニメーションやイラストのモデレーションにも対応しました。 Amazon CognitoでフェデレーションにSAMLを利用するケースに向けた3つの新機能 シングルサインオンの実装にSAML標準によるフェデレーションを利用している場合に便利な3つの機能を発表しました。新たに、Amazon Cognito User Poolを利用して署名付きSAML認証リクエストを送信すること、SAMLのIDプロバイダに対して暗号化された応答を要求すること、IdP Initiated SSOへの対応、が可能になりました。 FinchがWindowsプラットフォームをサポート Finch はオープンソースのコマンドラインツールで、Linuxコンテナを構築・実行・公開するためものです。今回、macOSに加えてWindowsプラットフォームがサポートされました。開発者が複雑な環境を管理する手間をかけずに、コンテナをローカル環境で構築・管理できるようになります。 Amazon EC2 Capacity Block for MLがP4dインスタンスに対応 機械学習ワークロードを実行するためにEC2のキャパシティを予約できるAmazon EC2 Capacity Block for MLが、オハイオとオレゴンのリージョンにおけるP4dインスタンスの予約に対応しました。EC2 Capacity Block for MLでは、バージニア北部リージョンのP5インスタンスの予約にもご利用いただけます。 2/2(金) 大きなアップデートはありませんでした。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )

Amazon SageMaker Canvas は、様々な機能を備えたコーディング不要の機械学習 (ML) と生成 AI ワークスペースです。見やすい画面とコーディング不要のインターフェースにより、世界中のお客様が ML テクノロジーをより簡単に採用し、いろいろな課題を解決できるようになりました。 これは、SageMaker Canvas が ML のワークフロー全体をカバーできていることに起因します。データの前処理やAutoMLの強力な機能、管理されたエンドポイントのデプロイ、簡略化された MLOps 機能、AWS AIサービスと生成 AI を活用したすぐに使えるモデルを利用者が探しているかどうかに関わらず、 SageMaker Canvas は目標達成を支援できます。 あらゆる規模の企業が SageMaker Canvas を採用するにつれ、お客様はコストの最適化の方法を求めてきました。 AWS Well-Architected Framework で定義されているように、コスト最適化されたワークロードは、すべてのリソースをフルに使用し、お客様の機能要件を満たし、可能な限り低い価格で成果を達成します。 この投稿では SageMaker Canvas アプリケーションのコストをより最適化する新しい方法を紹介します。 SageMaker Canvas は現在、アプリの使用状況とアイドル時間に関するインサイトを提供する Amazon CloudWatch Metrics を収集しています。 お客様はこの情報を使用して、意図しないコストの発生を避けるために自動的にアイドル状態の SageMaker Canvas アプリケーションをシャットダウンできます。 この投稿では、シンプルなサーバーレスアーキテクチャを使用して、アイドル状態のSageMaker Canvasアプリをシャットダウンしてコストを制御する方法を示します。 この投稿で使用されるテンプレートは こちらの GitHub で入手できます。 SageMaker Canvas のコストについて理解する オンプレミスまたはクラウドのどちらのワークロードでも、コストを理解し制御するためには、コストについて学ぶことから始まります。まずは SageMaker Canvas の課金モデル を確認することから始めましょう。 簡単に言うと、SageMaker Canvasには次の２つの側面に基づいた従量課金モデルがあります。 Workspace instance : 以前はセッション時間と呼ばれていたもので、SageMaker Canvas アプリの実行に関連するコスト。  AWSサービス料金 : モデルのトレーニング、エンドポイントのデプロイ、推論の生成といった SageMaker Canvas を起動するためのリソースに関連するコスト。 お客様は、SageMaker Canvasによって起動されるリソースを常に完全に制御することができ、AWS Billing and Cost Management Service を使用して、SageMaker Canvasアプリに関連するコストを追跡できます。 詳細については、「 SageMaker Canvasの課金とコストの管理 」を参照してください。 Workspace instance に関連するコストを制限するためのベストプラクティスとして、ブラウザタブは閉じずにログアウトをする方法があります。ログアウトするには、SageMaker Canvas アプリの左パネルにある ログアウトボタン を選択します。 自動で SageMaker Canvas アプリケーションをシャットダウンする SageMaker Canvasアプリケーションを自動的にシャットダウンしてコストを抑えたいIT管理者は、次の2つのアプローチをとることができます。 スケジュールに従ったアプリケーションのシャットダウン（毎日 19:00 または毎週金曜日 19:00） アイドル状態のアプリケーションの自動シャットダウン（アプリケーションが 2 時間使用されていない場合） スケジュールに従ったアプリケーションのシャットダウン スケジュールに従った SageMaker Canvas アプリケーションのシャットダウンは、Amazon SageMaker API である DeleteApp を呼び出すコンピューティングコンポーネント (AWS Lambda 関数) である cron 式 (Amazon EventBridge Cron ルールを使用) を使用することで、ほとんど手間をかけずに実行できます。このアプローチについては、「 AWS CDKとAWS Service Catalogを使用したAmazon SageMaker Canvasの機械学習環境のプロビジョニングと管理 」の記事で説明されており、こちらの  GitHub リポジトリ で実装が公開されています。 上記のアーキテクチャの利点の 1 つは、SageMaker Canvas アプリケーションの定期的な作成をとても簡単に複製できることにあります。定期的な作成と削除を組み合わせることで、ユーザーが業務を開始する時間帯（例 : 営業日の AM9:00）にSageMaker Canvas アプリケーションを立ち上げ、ユーザーが業務を終了する時間帯（例 : 営業日の PM7:00、週末は常にシャットダウン）に自動で SageMaker Canvas アプリケーションを削除することを確実にしておくことができます。必要なことは、 DeleteApp API を呼び出すコード行を CreateApp に変更することと、アプリ作成時間を反映するように cron 式を更新することだけです。 このアプローチは実装とテストが非常に簡単ですが、欠点としてアプリケーションが使用されているかどうかを考慮せず、アクティビティステータスに関係なくアプリケーションをシャットダウンしてしまうことです。セッションが突然終了するかもしれないため、アクティブユーザーと軋轢が生じてしまう可能性があります。 このアーキテクチャに関連するテンプレートは、 次の GitHub リポジトリ から取得できます。   アイドル状態のアプリケーションの自動シャットダウン 2023/11/24 から新たに、Amazon SageMaker Canvas はアプリケーションの使用状況とアイドル状態に関するインサイトを提供する CloudWatch Metrics を出力するようになりました。これにより、管理者はアイドル状態メトリクスを読み取り、しきい値と比較して自動シャットダウンの特定のロジックを定義するソリューションを定義できます。SageMaker Canvas によって出力されるアイドル状態メトリクスのより詳細な概要を次の段落に示します。 アイドル状態メトリクスに基づく SageMaker Canvas アプリケーションの自動シャットダウンを実現するために、AWS CloudFormation テンプレートを提供しています。このテンプレートは、次の 3 つの主要コンポーネントで構成されています。   Amazon CloudWatch Alarm はクエリを実行して TimesInceLastActive メトリクスの最大値をチェックします。この値が CloudFormation テンプレートの入力で指定されたしきい値より大きい場合、以下の残りの工程が自動で実行されます。このクエリは、単一のユーザープロファイル、単一のドメイン、またはすべてのドメインのどれでも実行できます。希望する制御レベルに応じて、以下を使用できます。 all-domains-all-users テンプレート。テンプレートがデプロイされているリージョン内のすべてのユーザーとすべてのドメインをチェックします。 one-domain-all-users テンプレート。テンプレートがデプロイされているリージョン内の 1 つのドメインのすべてのユーザーを対象にチェックします。 one-domain-one-user テンプレート。テンプレートがデプロイされているリージョンの 1 つのドメイン内の 1 つのユーザープロファイルについてチェックします。 アラーム状態が変更されると、Amazon EventBridge のデフォルトイベントバスにイベントが作成されます。このイベントバスには、AWS Lambda 関数をトリガーするように設定された Amazon EventBridge ルールがあります。 AWS Lambda 関数は、指定されたしきい値を超えてアイドル状態で稼働している SageMaker Canvas アプリケーションを特定し、 DeleteApp API を使用してそのアプリケーションを削除します。 このアーキテクチャに関連付けられた AWS CloudFormation テンプレートは、 次の GitHub リポジトリ から取得できます。 SageMaker Canvas のアイドル状態メトリックの仕組み SageMaker Canvas は /aws/SageMaker/Canvas/AppActivity 名前空間で TimeSinceLastActive メトリクスを出力します。このメトリックは、ユーザーが何の操作もしていないアプリケーションがアイドル状態であった秒数を示します。この新しいメトリックを使用して、SageMaker Canvas アプリケーションが一定期間アイドル状態になると、SageMaker Canvas アプリの自動シャットダウンをトリガーできます。SageMaker Canvas は、次のスキーマを使用して TimeSinceLastActive を公開します。 { "Namespace": "/aws/sagemaker/Canvas/AppActivity", "Dimensions": [ [ "DomainId", "UserProfileName" ] ], "Metrics": [ { "Name": "TimeSinceLastActive", "Unit": "Seconds", "Value": 12345 } ] } このメトリックの主要なコンポーネントは次の通りです。 Dimensions , 特に DomainId と UserProfileName  は全てのドメインとユーザーでアイドル状態になっているアプリケーションを特定することができる Value は SageMaker Canvas アプリケーションの中で最後のアクティビティからの秒数を示す。SgaeMaker Canvas は以下の操作をアクティビティがあったとみなす SageMaker Canvas アプリケーション内で行った全ての動作（例：ボタンを押下する、データセットを変換する、アプリ内で推論を行う、モデルをデプロイするなど） ready-to-use model を使用する、もしくはチャット画面を使って生成 AI モデルとやり取りをする 特定の時間にバッチ推論を実行するようにスケジューリングする（詳細については を参照） このメトリックは、 get_metric_data などの Amazon CloudWatch API を介して読み取ることができます。たとえば、Python 用 AWS SDK ( boto3 ) を使用する場合は以下となります。 import boto3, datetime cw = boto3.client('cloudwatch') metric_data_results = cw.get_metric_data( MetricDataQueries=[ { "Id": "q1", "Expression": 'SELECT MAX(TimeSinceLastActive) FROM "/aws/sagemaker/Canvas/AppActivity" GROUP BY DomainId, UserProfileName', "Period": 900 } ], StartTime=datetime.datetime(2023, 1, 1), EndTime=datetime.datetime.now(), ScanBy='TimestampAscending' )   Python クエリは DomainID と UserProfileName でグループ化した後、SageMaker Canvas に関連付けられた名前空間から TimeSinceLastActive  の MAX 値を抽出します。   自動シャットダウンソリューションをデプロイして試してみる 自動シャットダウンスタックをデプロイするには、以下を実行します。 上記の GitHub リポジトリから、実装したいソリューションを実装している AWS CloudFormation テンプレート をダウンロードしてください。ソリューションをすべての SageMaker Domainか、単一の SageMaker Domainか、単一ユーザー向けに適用するかを選択します。 以下のテンプレートパラメータの更新してください。 アイドルタイムアウト(idle timeout) — SageMaker Canvas アプリがシャットダウンされる前にアイドル状態でいられる時間 (秒単位)。デフォルト値は 2 時間です。 アラーム期間(alarm period) — CloudWatch Alarm がアイドルタイムアウトを計算するために使用する集計時間 (秒単位)。デフォルト値は 20 分です。 (Option) SageMaker Domain ID と ユーザープロファイル名 クラウドフォーメーションスタックをデプロイしてリソースを作成します。 クラウドフォーメーションスタックをデプロイしてリソースを作成します。 デプロイが完了すると (2 分もかかりません)、AWS Lambda 関数と Amazon CloudWatch アラームは、アイドル状態のときに Canvas アプリケーションを自動的にシャットダウンするように設定されます。自動シャットダウンスクリプトをテストするには、次の操作を行います。 SageMaker Canvas アプリが適切なドメイン内で適切なユーザープロファイル (設定されている場合) で実行されていることを確認してください。 SageMaker Canvas アプリの使用を停止し、アイドルタイムアウト期間 (デフォルトは 2 時間) を待ちます。 CloudWatch アラームがトリガーされ、自動化をトリガーした後に通常の状態に戻ったことを確認して、しきい値時間アイドル状態になった後にアプリが停止したことを確認します。 このテストでは、アイドルタイムアウト期間を 2 時間 (7200 秒) に設定しました。Amazon CloudWatch Metrics によってプロットされた次のグラフでは、アラームがトリガーされたしきい値 (1) に達するまで、SageMaker Canvas アプリが TimeSinceLastActive メトリクスを出力していたことがわかります。アラームがトリガーされると、AWS Lambda 関数が実行され、アプリケーションが削除され、メトリクスがしきい値 (2) を下回りました。     結論 この投稿では、AWS Lambda と CloudWatch Alarm と SageMaker Canvas から新たに出力されるようになったアイドル状態のメトリックスを使用して、アイドル状態の SageMaker Canvas アプリケーションの自動シャットダウンソリューションを実装しました。このソリューションにより、顧客は機械学習ワークロードのコストを最適化できるだけでなく、SageMaker Domainで実行されていたことを忘れてしまったアプリケーションへの意図しない請求を回避できます。 このソリューションによってお客様が安心して解決できる新しいユースケースやワークロードを楽しみにしています。SageMaker Canvasがビジネス目標の達成にどのように役立つかについてのその他の例については、以下の記事を参照してください。 Predict customer churn with no-code machine learning using Amazon SageMaker Canvas Amazon SageMaker Canvas の ML 予測を使用して Amazon QuickSight に予測ダッシュボードをパブリッシュ ノーコード機械学習のAmazon SageMaker Canvas を使用して、画像から製造品質欠陥の検出を誰でも簡単に行う方法 Use no-code machine learning to derive insights from product reviews using Amazon SageMaker Canvas sentiment analysis and text analysis models Empower your business users to extract insights from company documents using Amazon SageMaker Canvas Generative AI Amazon SageMaker Canvas を使用してプロダクションレベルのワークロードを実行する方法については、以下の投稿を参照してください。 ビルド、共有、デプロイ : ビジネスアナリストとデータサイエンティストが、ノーコード機械学習と Amazon SageMaker Canvas を使用して市場投入までの時間を短縮する方法 Retrain ML models and automate batch predictions in Amazon SageMaker Canvas using updated datasets Operationalize ML models built in Amazon SageMaker Canvas to production using the Amazon SageMaker Model Registry AWS CDKとAWS Service Catalogを使用したAmazon SageMaker Canvasの機械学習環境のプロビジョニングと管理 （訳者注：上記のブログ記事は、日本語に翻訳済のものは日本語の翻訳記事のリンクを掲載しています。原文を読みたい場合は、日本語の記事からのリンクを参照下さい。）   著者について Davide Gallitelliは、AI/MLのシニアスペシャリストソリューションアーキテクトです。彼はブリュッセルに拠点を置き、ローコード/ノーコードの機械学習テクノロジーとジェネレーティブAIの採用を検討している世界中の顧客と緊密に連携しています。彼は幼い頃から開発者として活躍し、7歳でコーディングを始めました。彼は大学でAI/MLを学び始め、それ以来ずっとAI/MLに夢中になっています。     Huong Nguyen は AWS のシニアプロダクトマネージャーです。彼女はSageMakerのデータエコシステム統合を主導しており、企業と消費者の両方の分野で顧客中心およびデータ主導型の製品を構築してきた14年の経験があります。     Gunjan Garg は AWS の Amazon SageMaker チームのプリンシパルエンジニアで、この製品の技術的リーダーシップを発揮しています。彼女は過去 5 年間、AI/ML 組織でいくつかの役職を歴任し、現在は Amazon SageMaker Canvas に焦点を当てています。     Ziyao Huang は Amazon SageMaker Data Wrangler のソフトウェア開発エンジニアです。彼は、お客様が ML を簡単に利用できるようにする優れた製品の開発に情熱を注いでいます。仕事以外では読書をしたり、友達と遊んだりするのが好きです。     本ブログはソリューションアーキテクトの辻浩季が翻訳しました。原文は こちら です。      

この記事は How to build a scalable, multi-tenant IoT SaaS platform on AWS using a multi-account strategy の日本語訳です。IoT Specialist Solutions Architect の新澤雅治 が翻訳しました。 IoT デバイスとサービスの相互作用を決定する IoT SaaS プラットフォームの構築を自分ではなく顧客が行う場合、単一のクラウドアーキテクチャをすべてのシナリオに最適化できないということがすぐにわかります。このブログ記事では、実際の顧客体験に基づいてマルチテナントの IoT SaaS プラットフォームを構築するための実装戦略と、オペレーションプロファイルの異なるデバイス群を 1 つの AWS アカウントに混在させることで生じる問題について紹介します。IoT SaaS プラットフォームのすべての顧客に共通のエクスペリエンスを提供しながら、AWS インフラストラクチャの境界と自動化機能を使用して顧客とそのデバイス群のセグメント化を可能にする手段を説明します。 はじめに モノのインターネット (IoT) の普及に伴い、多くのソリューション提供者は、既存のサービスとして Software-as-a-Service　(SaaS) と統合する IoT アプリケーションの構築と管理を望んでいます。 IoT デバイス群を含む SaaS サービスを検討する場合、そのアーキテクチャはテナント管理だけでなく、フリートの関連付けと隔離も考慮に入れる必要があります。このブログでは、 AWS Control Tower をマルチアカウント戦略とともに使用して、マルチテナントの IoT SaaS プラットフォームを実装するリファレンスアーキテクチャについて説明します。 アーキテクチャの設計には、さまざまなデプロイメントモデルを用いる方法がいくつかあります単一の Amazon Web Services (AWS) アカウントにデプロイすることも、 AWS アカウントの制限、テナントの隔離、リージョン固有のデプロイメント制限、またはその他のアーキテクチャ上の考慮事項のために、複数の AWS アカウントにまたがってデプロイすることもできます。 AWS でマルチアカウント戦略 を確立することは、新しいアプリケーションバージョンの迅速なテストとデプロイを可能とし、環境を安全に管理するのに役立ちます。マルチアカウントデプロイメントモデルは、特にクラウドワークロードがデバイスフリートの動作と一致する必要がある IoT ワークロードの技術的課題を解決します。これについては、次のセクションで詳しく説明します。 マルチテナント型 IoT SaaS プラットフォームの課題への対応 顧客がデバイスを作成して展開するマルチテナントの IoT SaaS プラットフォームサービスを構築する際には、実装を成功させるために解決しなければならない次のような課題があります。 データ分離n – マルチテナント構造では、 SaaS プロバイダーは、規制や顧客の要件に基づいてデータ分離境界をどのように設定するかを考慮する必要があります。IoT ワークロードの場合、多くのデバイスとゲートウェイがさまざまなデータタイプをさまざまなスキーマで接続して送信します。 AWS アカウントごとに境界を定義しておくと、さまざまなアカウントレベルのポリシーを設定できるため、クォータや個々の顧客フリートのニーズを管理しやすくなります。 データプライバシー – IoT は世界中で多くの業界で使用されています。さらに、データプライバシー規制は業界や地域によって異なります。テナントごとに要件に基づいて個別の IoT エンドポイントを用意することで、グローバル SaaS プラットフォームとして柔軟に運用できます。 デバイスプロビジョニングとオンボーディング – 現場で複数のセンサを束ねるルートデバイスの ID を変更することなく、デバイスを複数のテナント・エンドポイントにオンボーディングする戦略が必要です。 IoT セキュリティのベストプラクティス では、各 IoT エンドポイントで認証される固有の暗号化 ID を使用してデバイスをプロビジョニングすることを推奨しています。デバイスのルート ID のプログラミングと確立は、通常、製造時などのコントロールされた顧客環境で行われます。デバイスがグローバルサプライチェーンを経て現場に設置されるまでに数か月から数年かかる場合があります。製造時にデバイスの ID をテナントアカウントの IoT エンドポイントに緊密に結合してしまうと、柔軟性に欠けるサプライチェーンとなってしまいます。また、メーカーにとって SKU の断片化の原因にもなります。IoT エンドポイントへのデバイス ID のオンボーディングは、デバイスのライフサイクルの後半で行われる可能性があることを考慮する必要があります。 このブログのリファレンスアーキテクチャは、上記の課題に対処し、導入と運用を簡素化し、データガバナンスを強化します。 以下では、アーキテクチャの重要なポイントについて説明します (図 1)。 プラットフォーム作成の自動化 – 新しいテナントをオンボーディングすると、このアーキテクチャでは新しい AWS アカウントを作成し、テナント専用およびリージョン固有の AWS IoT Core エンドポイントを確立します。その後、新しいアカウントごとに、他の関連する AWS サービスとアプリケーションをデプロイします。この自動化されたプロセスは、データの分離、プライバシー、クォータ管理の課題の一部を解決するのに役立ちます。 デバイスのプロビジョニングとオンボーディング – 一元化されたオンボーディングサービスを使用して、IoT デバイスを要求し、指定されたテナント IoT エンドポイントにルーティングします。これにより、製造時のテナント固有のデバイスプロビジョニングの課題やテナントバインディングの遅延を解決できます。 図 1 — AWS アカウントレベル別の IoT マルチアカウントアーキテクチャの概要 AWS Control TowerとAWS Service Catalog を使ったテナント環境構築の自動化 自動化とスピードは、より良いカスタマーエクスペリエンスの鍵となります。特に、テナントのオンボーディングの際には、 AWS Control Tower と AWS Service Catalog を使用して、 AWS アカウント作成を含むテナントオンボーディングプロセスを自動化しましょう。これらのサービスは、顧客のプロセスを改善し、製品の市場投入までの時間を短縮します。 AWS Control Tower を有効にすると、Control Tower – Master という ランディングゾーン がリージョンにデプロイされます。AWS Control Tower は、監査アカウントとログアーカイブアカウントも作成します（図2）。AWS Control Tower は、セキュリティとコンプライアンスのリスクをスキャンするための設定、またはシステムコントロールを提供します。これらのコントロールは policy-as-a-code として管理し、新しく作成された AWS アカウントに適用することができます。 図2 – AWS Control Tower サービスコンソールの組織ビュー AWS Control Tower が有効になると、AWS Control Tower Account Factory を使用して新しい AWS アカウントを作成し、 IoT アプリケーション（エンドポイント）をデプロイできるようになります。 Account Factory は、新しい AWS アカウントの作成プロセスを自動化し、セキュリティとコンプライアンスのベストプラクティスのコントロールを適用します。また、アカウント作成プロセス中に AWS IoT Core を使用するテナントアプリケーションインフラをデプロイします。 AWS Control Tower コンソールを見ながら、主要な設定ポイントを理解していきましょう。 AWS Control Tower コンソールで、ナビゲーションペインの Account Factory を選択します。 Create Account ボタンを選択すると、Create account ページが表示されます。 このページで、アカウントマスターのメールアドレス、 AWS IAM Identity Center の識別情報、組織情報などのアカウントの詳細を指定します(図 3)。 図 3 – AWS Control Tower Account Factory でのアカウント作成 ページを下にスクロールして、 Account factory customization (AFC) セクションを見つけます。(図 4) このセクションでは、AWS アカウント作成後にデプロイする製品またはアプリケーションを指定します。 注：ドロップダウンリストに表示するには、すべての製品を Service Catalog 製品として登録する必要があります。Service Catalog 製品は自分でテンプレートを開発するか、構成済みのライブラリを使用して作成できます。詳細については「 Getting Started Library 」を参照してください。図のシナリオでは、製品は「テナント用 IoT アプリケーション」と名付けられ、製品として事前登録されているため、AFC はアカウント作成プロセス中にデプロイをトリガーできます。詳細については、「 Account Factory Customization （AFC）によるアカウントのカスタマイズ 」を参照してください。. 最後に、製品を配置する場所を選択します。Account Factoryは、ホームリージョン (AWS Control Tower を有効にしたリージョン） 、または ” All Governed Regions “にデプロイします。このシナリオでは、 ホームリージョン であるバージニア北部にデプロイします。 図 4 – AWS Control Tower の Account Factory Customization での設定 アカウント作成後、AWS Control Tower に登録・管理されているアカウントが表示されます。 図 5 — AWS Control Tower によってデプロイおよび管理される AWS アカウントのリスト、組織構造、およびアカウント作成に使用されたブループリント (テンプレート) テナントアカウントへの IoT デバイスのプロビジョニングとオンボーディング IoT アプリケーションがデプロイされた AWS アカウントが用意できたので、次にデバイスのプロビジョニングとオンボーディングに移りましょう。製造中のデバイスプロビジョニングを個々のテナントアカウントから切り離すために、AWS Control Tower を使用して、専用の AWS アカウント内に集中化されたデバイスオンボーディングサービスを作成します。このシナリオでは、QR コードを使用して IoT デバイスを AWS IoT Core にオンボードする方法を提供する 「Device Lobby」 リファレンスアーキテクチャを使用します。 図 6 – AWS Device Lobby アーキテクチャ ビルやキャンパスの物理的なロビーが訪問者のための公開エントランスポイントを提供するのと同様に、 IoT Device Lobby は、バインドされていない IoT デバイスのための AWS へのエントリーポイントを確立します。このアプローチにより、テナントデバイスの柔軟なオンボーディングが可能になり、クレーム処理を通じてユニークなデバイス識別子をテナントの IoT コアエンドポイントに関連付けます。サービスがデバイスをクレームすると、 Device Lobby サービスアカウントは、定義された MQTT トピックを介してテナントの AWS IoT Core エンドポイントにデバイスを送信するルーティング層として機能します (図 7) 。 このアーキテクチャは、デバイスのライフサイクル中のいつでも、テナントによって製造されたデバイスがそのエンドポイントにルーティングされることをサポートします。また、IoT Device Lobby アーキテクチャーは、デバイスを再プロビジョニングすることなく、あるリージョンやアカウントから別のリージョンまたはアカウントに移行することもサポートします。この状況では、サービスは Device Lobby サービスをホストする中央エンドポイントと、製造時にプラットフォームまたはテナントの公開鍵基盤（PKI）に基づく固有の認証情報でデバイスをプロビジョニングします。 詳細については、 IoT Device Lobby Architecture を参照してください。 図7 – Device Lobby アーキテクチャによる IoT デバイスのルーティングとテナントアカウントへの登録 Device Lobby アーキテクチャをデプロイするには、サービスをホストする専用の AWS アカウントを作成します。Device Lobby サービスのインスタンスは1つしか必要ないので、デプロイガイドに従って直接専用アカウントにデプロイできます。必要に応じ、AWS Service Catalog から製品を作成することにより、開発、テスト、ステージングアカウント全ての環境で同じ構成を実行できます。詳細については、 Device Lobby Configuration を参照してください。 図8 – サービスカタログに追加された Device Lobby サービス製品 IoT SaaS プラットフォームの Device Lobby サービスアカウントを確立したら、テナント IoT アプリケーションのアカウント設計図には、クロスアカウント信頼ポリシーを含める必要があります。このポリシーにより Device Lobby サービスがデバイスを登録し、テナントアカウントの IoT エンドポイントに接続できるようになります。 Device Lobby を使用することで、IoT SaaS プラットフォームは任意のテナントアカウントやリージョンにデバイスをオンボードする際の柔軟性が大幅に向上し、デバイスを特定の単一テナントアカウント用にプロビジョニングする必要がなくなります。デバイスの構築と現場への配備には時間がかかるため、このアプローチでは既存のデバイス SKU を再利用できるため、顧客の IoT 導入を大幅に加速できます。また、このソリューションは、デバイスのサプライチェーンにおける規模の経済性を高めることにもつながります。 まとめ この投稿では、IoT SaaS プラットフォームが、複数の顧客の IoT デバイス群をホスティングする際に、データの分離、プライバシー、サービスクォータ管理の課題にどのように対処できるかについて説明しました。AWS Control Tower は、 SaaS プラットフォームを構成する可能性のある複数のアカウントを管理するための手作業や潜在的にエラーを起こしやすいプロセスを取り除くのに役立ちます。テナントの IoT ワークロードをホストする複数の AWS アカウントへのデバイスオンボーディングを、Device Lobby アーキテクチャのような一元化されたサービスで管理できます。さらに、マルチアカウント戦略を採用することで、IoT SaaS サービスを構成する各テナントの AWS アカウントで、個別のさまざまな顧客デバイスフリートをホスティングすることができます。これにより、テナント・フリート間の分離が向上し、テナントごとに異なるサービスのクォータとポリシーの管理が容易になり、 AWS 上でより堅牢でスケーラブルな IoT SaaS プラットフォームを実現します。 AWS Control Tower の詳細については 、AWS Control Tower Workshop をご覧ください。 AWS IoT サービスを始めるには、 AWS IoT Immersion Day Workshop をご覧ください。 著者について Tomo Sakatoku シアトルの Amazon Web Services のプリンシパル・エンタープライズ・アーキテクトです。顧客と協力して困難な問題を解決することに情熱を注いでいます。また、趣味はテニスと家族旅行です。 Ben Cooke テキサス州オースティンの Amazon Web Services のシニア IoT ソリューションアーキテクトです。IoT システムアーキテクチャに注力しています。趣味は、家族とのアドベンチャーやガレージでの物づくりです。 <!-- '"` --> この記事は Ben Cooke と Tomo Sakatoku によって書かれた How to build a scalable, multi-tenant IoT SaaS platform on AWS using a multi-account strategy の日本語訳です。この記事は ソリューションアーキテクト の新澤雅治が翻訳しました。

クラウドのマイグレーションとモダナイゼーションは、時間がかかり複雑で、常に進化し続けるプロセスです。それにもかかわらず、マッキンゼーの調査では、お客様はクラウドにかける予算と移行を計画しているアプリケーションの数を増やしていることが示されています。マイグレーションおよびモダナイゼーション プロジェクトが複雑になる理由は3つあり、第１に、不揃いかつその場限りのソリューションに依存するため、関係者とのコラボレーションが煩雑になる可能性があることです。第 2 に、お客様には絶えず変化する最新技術に追従することに慣れていない場合があります。最後に、お客様は移行プロセス全体の管理を怠って、個別のタスクに気を取られてしまう場合があり、移行プロセス全体のタスクパイプラインの管理を無視することがあります。これらの課題の影響は、以下の図1に示すように、440人を超える経営幹部を対象にマッキンゼーが行った調査のデータから明らかになっています。 このブログ記事では、 AWS Migration Hub Journeys を紹介し、コラボレーション、計画、実行など、複雑なマイグレーションとモダナイゼーションに関連する課題にどのように対処するかを紹介します。 図 1: マッキンゼーの調査チャート AWS Migration Hub Journeys の紹介 今日、お客様はマイグレーションとモダナイゼーションに向けたタスクを実行するため、最新かつ信頼できるガイダンスを探すのに多大な時間を費やしており、移行タスク管理が非効率性と不確実性につながっています。 AWS Migration Hub Journeys は、AWS への移行を成功させるための手順とガイダンスを提供することで、移行タスクの実行と追跡を容易にします。Migration Hub Journeys は、移行フェーズごとにすべてのタスクを階層化し、簡単に実行できるようにそれらをサブタスクに分割しています。また、サブタスクごとに段階的な実行手順書が提供されるため、プロジェクト計画に必要な時間が短縮され、クラウド エキスパートへの依存が軽減されます。ユーザーは必要に応じてタスクを柔軟に編集または追加できます。AWS Migration Hub Journeysは、特に移行に関する自動化作業と手動作業に関するコラボレーションを容易にします。 ユーザーは、個々のタスクの結果として作成された成果物を、一元的に保存して、後で参照することができます。大規模な移行を追跡する際、AWS Migration Hub Journeys は、追跡および警告システムを通じて問題が発生した場合に適切な AWS エキスパートに警告を発し、支援を求めます。AWS Migration Hub のMigration Hub Journeysを利用することで、AWS への移行にかかるコストと時間を全体的に削減できます。 以下の図 2 は、AWS Migration Hub Journeys が移行を開始するにあたりどのように役立つかの概要を示しています。 図 2 : AWS Migration Hub Journeys マイグレーション・ジャーニー AWS Migration Hub Journeys では、マイグレーション・ジャーニーの概念を導入しています。これらのジャーニーは、エキスパート、プロセス、ツールを集めて移行作業を効率化するためのプラットフォームです。これにより、構造化と体系化されたタスクパイプラインによって、移行の見通しを一変させます。下の図 3 は、AWS Migration Hub コンソール内のジャーニーの簡単な概要を示しています。これについては、本ブログで詳しく説明します。 図 3 : マイグレーション・ジャーニーの概念 Migration Hub には、マイグレーション・ジャーニーの作成に使用できるテンプレートが用意されています。これらのテンプレートは一般的な移行シナリオを表しており、ベストプラクティスに従っています。テンプレートからジャーニーを作成すると、フェーズ、モジュール、タスク、サブタスクがあらかじめ定義されているジャーニーを作成できます。 マイグレーション テンプレート マイグレーション テンプレートは、「典型的な」マイグレーション・ジャーニーのタイプ（例：DB2データを移行するジャーニーや、Windows OSアプリケーションを移行するジャーニー）を説明する構造化された文書です。これらには、移行プロセスを完了するために必要な一連のタスクがすべて含まれています。お客様は、自分のニーズに最も近いテンプレートを選択し、テンプレートの内容を新しいジャーニーにコピーしてから、自分の要件に合わせてジャーニーを更新することで、独自の移行プロセスを計画します。AWS Migration Hub には、リリース時に AWS のエキスパートとパートナーによって開発された多数のテンプレートが含まれています。また、お客様は独自のカスタムテンプレートを作成して、特定のニーズに合わせて繰り返し実行できる移行プロセスを確立することもできます。AWS Migration Hub Journeys から現在入手可能なテンプレートについては、下の図4を参照してください。 使い方 — Migration Hub Journey コンソールで、左側のメニューから[ Migration journey templates ]を選択します。 図4: マイグレーション・ジャーニー テンプレート 各テンプレートには、 AWS 移行方法 に沿ったフェーズが設定されており、各フェーズ内には、図 5 に示すように、移行手順をガイドするモジュール、タスク、サブタスクがあります。 使い方 — Migration Hub Journey コンソールで、左側のメニューから [ Migration journey templates ] を選択します。リストから任意のテンプレートを選択すると、その特定のテンプレートに対応する詳細情報が表示されます。 図 5: 一般的なマイグレーション テンプレート — 概要 マイグレーション・ジャーニー – フェーズ テンプレートからジャーニーを作成すると、各フェーズが利用可能になり、それらのフェーズの管理をジャーニー内で開始できます。図 6 は、選択したジャーニーを構成するフェーズを示しています。 使い方 — Migration Hub Journey コンソールから、Journey を選択します。ジャーニー内から、「 phases 」タブを選択します。 図 6: マイグレーション・ジャーニー — フェーズ マイグレーション・ジャーニー – タスク 以下の図 7 のタスクには、必要な手順とガイダンスが記載されています。場合によっては、タスクを完了するのに役立つ、またはタスクを完了するために必要となるツールに関する指示も記載されています。タスクを特定のタスク所有者に割り当てたり、完了タイムラインを指定したり、推定作業レベルと実際の作業レベルを把握したりできます。 使い方 — Migration Hub Journey コンソールから、Journey を選択します。ジャーニー内から、[ tasks ]タブを選択します。任意のタスクを選択すると、タスク内の詳細と編集可能な設定が表示されます。 図 7: マイグレーション・ジャーニー — タスクの詳細 マイグレーション・ジャーニー – サブタスク タスクを正常に完了するために、タスクの下位にサブタスクが集約されます (下の図 8) 。タスク(と複数のサブタスク）でコメントやファイルを共有することができるため、別のチームメンバーに割り当てて共同作業を行うことができます。依存関係は、タスクの完了を妨げるブロッカーとともにタスク内にリストされます。 使い方 — Migration Hub Journey コンソールから、Journey を選択します。ジャーニー内から「 tasks 」タブを選択し、編集するタスクを選択します。タスク内から、[ Subtasks ]を選択します。 図 8: マイグレーション・ジャーニー — タスク — サブタスク チームメンバーは、タスクおよびサブタスクにファイルを添付できます (図 9)。たとえば、タスクの完了に役立つ分析レポートを添付します。タスクの結果を含むファイルを添付することもできます。 使い方 — Migration Hub Journey コンソールから 、Journey を選択します。ジャーニー内から、[ Tasks ] タブを選択し、編集するタスクを選択します。タスク内から、[ Attached files ] を選択します。 図 9: マイグレーション・ジャーニー — タスク — 添付ファイル マイグレーション・ジャーニー – モジュール タスクはモジュールに割り当てられて編成されます (図 10)。モジュールは、特定の結果を達成するようフェーズ内のタスクを整理するために使用する論理的なコンテナです。 使い方 — Migration Hub Journey コンソールから、Journey を選択します。ジャーニー内から [ Modules ] タブを選択します。 図 10: マイグレーション・ジャーニー — モジュール マイグレーション・ジャーニー — 個人とチーム マイグレーション・ジャーニーには、移行プロセスのコントリビュータまたは管理者である個人とチーム（図11）を定義する機能も含まれています。ジャーニーの作成者は、自動的にそのジャーニーの管理者になります。 個人またはチームをコントリビュータまたは管理者としてスペースまたはジャーニーに追加するには、招待状を送信します。追加されるには、招待を受け入れる必要があります。また、招待を断ることもできます。 使い方 — Migration Hub Journey コンソールから、Journey を選択します。ジャーニー内から、[ Individuals and teams ]タブを選択します。 図 11: マイグレーション・ジャーニー — 個人とチーム AWS Migration Hub Journeys へのアクセス AWS を初めて使用し、クラウド移行の計画段階の初期段階にある場合は、AWSアカウント無しで AWS Migration Hub Journeys に直接アクセスするオプションがあります。AWS Migration Hub Journeys に直接アクセスするプロセスは、 AWS ビルダー ID を利用することで簡略化されます。 クリーンアップ マイグレーション・ジャーニーをクリーンアップする手順は、AWS Migration Hub Journeys コンソールからマイグレーション・ジャーニーが削除できます。下の図 12 に示すように、AWS Migration Hub Journeys の [ Migration journeys ] セクションから、ジャーニーの横にあるラジオボタンを選択し、右上の [ Actions ] ドロップダウンをクリックして [ Delete journey ] を選択します。お客様が確認し、追加の書面による同意を提供すると、そのジャーニーは完全に削除されます。 図 12: マイグレーション・ジャーニーの削除 まとめ AWS Migration Hub Journeys は、リアルタイムのガイダンスと効率的なコラボレーションによってマイグレーションとモダナイゼーションの両方のプロセスを合理化し、複雑な移行を総合的な移行プロセスにおける管理可能なタスクに変換します。お客様は、AWS Migration Hub Journeys の機能と利点を調べて、お客様やパートナーのプロジェクトに実装することを検討することをお勧めします。今すぐ AWS Migration Hub Journeys の能力を活用して、マイグレーションとモダナイゼーションのジャーニーを最適化し、よりスムーズで効率的なAWS移行を実現してください。AWS Migration Hub Journeys を採用することで、組織はマイグレーションとモダナイゼーションの複雑さを自信を持って乗り切ることができ、AWS での体験をより効率的かつ成功させることができます。 著者について Kalyan Vennelakanty Kalyan Vennelakanty は AWS のテクニカルプログラムマネージャーで、クラウドアプリケーションのデリバリーに豊富な経験があります。彼は新しいクラウドテクノロジーに取り組み、お客様の移行ニーズを満たすのを支援することに情熱を注いでいます。 Steven Koufoudakis Steven Koufoudakis は AWS のパートナーソリューションアーキテクトです。彼は新しいテクノロジーを扱うことに喜びを感じています。また、適切なテクノロジーを組み合わせてお客様のビジネスニーズを満たすお手伝いをしています。パートナーやお客様の AWS でのワークロードのマイグレーション、モダナイゼーション、最適化を支援することに情熱を注いでいます。 Steven Koufoudakis Mohan CV は、バージニア州北部に拠点を置く AWS の主任ソリューションアーキテクトです。大企業のマイグレーションとモダナイゼーションの分野で豊富な経験を持ち、データ＆アナリティクスを専門としています。Mohanは新しいテクノロジーの活用に情熱を注いでおり、お客様が独自のビジネスニーズに合わせてこれらのイノベーションをカスタマイズできるよう支援することに喜びを感じています。 この記事の翻訳はソリューションアーキテクトの須山健吾が担当しました。原文は こちら です。

1月22日週も当社のサービスチームはお客様のためにイノベーションを続けており、 Amazon Web Services (AWS) の世界では多くのことが起こりました。また、世界中で開催されているすべての AWS コミュニティ イベントやイニシアティブについても共有します。 早速見ていきましょう! 1月22日週のリリース 私が注目したいくつかのリリースをご紹介します。 AWS Step Functions が Amazon Q を含む 33 のサービスの統合を追加 – AWS Step Functions は、220 を超える AWS サービスから 11,000 以上の API アクションをオーケストレーションできるビジュアルワークフローサービスで、お客様が分散型アプリケーションを大規模に構築するのをサポートします。1月29日週、 AWS Step Functions は AWS SDK の統合を拡張し、Amazon Q、AWS B2B Data Interchange、Amazon CloudFront KeyValueStore など 33 の AWS サービス向けのサポートの提供を追加で開始します 。 Amazon Elastic Container Service (Amazon ECS) Service Connect が TLS 証明書を使用した自動トラフィック暗号化のサポートを導入 – Amazon ECS は、ECS Service Connect と呼ばれるネットワーク機能のために、Transport Layer Security (TLS) 証明書を使用した自動トラフィック暗号化のサポートの提供を開始します。このサポートにより、アプリケーションは ECS Service Connect を使用して、ネットワークトラフィックを暗号化することで安全な接続を確立できます。 Amazon Elastic Kubernetes Service (Amazon EKS) および Amazon EKS Distro が Kubernetes バージョン1.29 をサポート – Kubernetes バージョン1.29 では、いくつかの新機能とバグ修正が導入されました。Amazon EKS コンソールもしくは eksctl コマンドラインインターフェイスを使用して、または Infrastructure as Code (IaC) ツールを通じて、v1.29 で新しい EKS クラスターを作成したり、既存のクラスターを v1.29 にアップグレードしたりできます。 Amazon Lightsail の IPv6 インスタンスバンドル – これらの新しいインスタンスバンドル を使用すると、パブリック IPv4 アドレスを必要とすることなく、Amazon Lightsail の使いやすさとシンプルさの恩恵を受けながら、IPv6 のみで迅速に起動して実行できます。パブリック IPv4 アドレスを持つ既存の Lightsail インスタンスがある場合は、いくつかの簡単なステップでインスタンスを IPv6 のみに移行できます。 Amazon Virtual Private Cloud (Amazon VPC) がルートテーブルとネットワーク ACL 作成のために冪等性をサポート – ルートテーブルとネットワーク ACL の冪等性の作成 は、ワークフローの一部としてルートテーブルとネットワーク ACL を作成するネットワークオーケストレーションシステムまたはオートメーションスクリプトを使用するお客様を対象としています。これにより、さらに悪影響を生じさせることなく、安全に作成を再試行できます。 Amazon Interactive Video Service (Amazon IVS) が低レイテンシーストリーミングの音声のみの料金を発表 – Amazon IVS は、世界中の視聴者が視聴できる低レイテンシーまたはリアルタイム動画を実現するように設計されたマネージドライブストリーミングソリューションです。 低レイテンシーストリーミング機能の音声のみの料金 を、既存の HD 動画レートの 1/10 で提供するようになりました。 AWS Marketplace でサードパーティーのプロフェッショナルサービスの販売者による再販が可能に – 独立系ソフトウェアベンダー (ISV)、コンサルティングパートナー、チャネルパートナーを含む AWS Marketplace の販売者は、 AWS Marketplace でサードパーティーのプロフェッショナルサービスを再販できるようになりました 。サービスには、実装、評価、マネージドサービス、トレーニング、またはプレミアムサポートが含まれる場合があります。 AWS 中堅中小企業 (SMB) コンピテンシーのご紹介 – これは、中堅中小企業のお客様にサービスを提供するパートナー向けに設計された、初の市場投入に関する AWS Specialization です。 SMB コンピテンシーは、AWS パートナーが SMB のお客様のビジネスに投資および注力するための強化されたメリットを提供します 。このメリットには、新しいパイロットや販売イニシアティブに参加する際の頼れるパートナーとなることや、需要生成エンジンをスケールするための独自のアクセスを利用できることが含まれます。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 X in Y – 追加のリージョンで既存のサービスとインスタンスタイプの提供を開始しました。 Amazon Q in QuickSight が欧州 (フランクフルト) で利用可能になりました 。Amazon Q in QuickSight を利用すると、ビジネスユーザーはデータのナラティブを提供する魅力的なデータストーリーを生成したり、ダッシュボードの概要を作成してデータから重要なインサイトを数秒で共有したりできるほか、ダッシュボードやレポートの情報だけでは回答できない質問に自信をもって答えることができます。 Amazon Launch Wizard がアジアパシフィック (メルボルン) および欧州 (スペイン、チューリッヒ) で利用可能になりました 。AWS Launch Wizard は、アプリケーションプログラミングインターフェイス (API) またはコンソールベースのエクスペリエンスを使用して、SAP HANA および Adaptive Server Enterprise (ASE) 上に構築された SAP HANA および SAP NetWeaver システムのために、AWS リソースのサイズ設定、構成、デプロイに役立つステップバイステップのガイドを提供します。 Amazon RDS Custom for Oracle が欧州 (パリ) で利用可能になりました 。Amazon RDS Custom for Oracle を利用すると、自動バックアップやポイントインタイムリカバリなどの機能を備えたマネージドデータベースサービスの俊敏性の恩恵を受けることができるほか、データベースアプリケーションのカスタマイズ要件を満たすこともできます。 Amazon EC2 の M7a および R7a インスタンス がアジアパシフィック (東京) で利用可能になりました 。M7a および R7a インスタンスは、3.7 GHz の最大周波数を備えた第 4 世代 AMD EPYC プロセッサ (コード名: Genoa) を搭載しており、それぞれ M6a および R6a インスタンスと比較して最大 50% 高いパフォーマンスを実現します。 Amazon EC2 の C7i インスタンス が欧州 (フランクフルト) および南米 (サンパウロ) で利用可能になりました 。C7i インスタンスは、AWS でのみ利用可能なカスタム第 4 世代インテル Xeon スケーラブルプロセッサを搭載しています。他のクラウドプロバイダーが利用する同等の x86 ベースのインテルプロセッサよりも最大 15% 優れたパフォーマンスを提供します。 Amazon EC2 の High Memory インスタンス が欧州 (ストックホルム) で利用可能になりました 。Amazon EC2 の High Memory インスタンスは、本番環境で Business Suite on HANA、SAP S/4HANA、Data Mart Solutions on HANA、Business Warehouse on HANA、および SAP BW/4HANA を実行できることが SAP によって認定されています。 Amazon Connect SMS がアジアパシフィック (ソウル、シドニー) で利用可能になりました 。Amazon Connect SMS を利用すると、テキストメッセージを通じて顧客の問題を簡単に解決できます。 AWS のその他のニュース 興味深いと思われるその他のプロジェクト、プログラム、ニュースをいくつかご紹介いたします。 Amazon Inspector を利用してソフトウェア部品表をエクスポート – SBOM を生成すると、重要なセキュリティ情報を得ることができます。この情報を参照することで、最も頻繁に使用するパッケージや、会社全体に影響を及ぼす可能性のある関連する脆弱性など、ソフトウェアサプライチェーンに関する詳細を確認できます。南アフリカの私の同僚である Varun Sharma は、 Amazon Inspector によって組織全体でモニタリングされているリソースの統合 SBOM を、 CycloneDx や SPDX などの業界標準形式でエクスポートする方法をご紹介します。また、 Amazon Athena を利用して SBOM アーティファクトを分析するためのインサイトとアプローチも共有します。 AWS のオープンソースに関するニュースと最新情報 – 私の同僚である Ricardo は、AWS コミュニティの新しいオープンソースプロジェクト、ツール、デモに焦点を当てたこの オープンソースに関する週刊ニュースレター を執筆しています。 近日開催される AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Innovate: AI/ML and Data Edition – 2024 年 2 月 22 日に開催される アジアパシフィックおよび日本の AWS Innovate オンラインカンファレンス に登録して、人工知能 (AI) と機械学習 (ML) でイノベーションを生み出す方法を参照、検索、学習してください。3 か国語で提供される 50 超のセッションから選択し、生成 AI ビルダーを対象としたテクニカルデモを実際にご体験ください。 AWS Summit Paris&nbsp; – AWS Summit Paris は、フランスのパリで開催される毎年恒例のイベントです。これは、世界中のクラウドコンピューティングのプロフェッショナルにとって、最新の AWS テクノロジーについて学び、他のエキスパートとネットワークを築き、プロジェクトで共同作業するためのすばらしい機会です。Summit には無料で参加でき、基調講演、ブレイクアウトセッション、実践的ラボが提供されます。 現在、登録を受け付けています! AWS コミュニティ re:Invent re:Caps –&nbsp;世界中の AWS ユーザーグループと AWS クラウドクラブのボランティアが主催する コミュニティ re:Cap イベント に参加して、AWS re:Invent の最新の発表をご確認ください。 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます。 1月29日週はここまでです。2月5日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! — seb この記事は、 Weekly Roundup &nbsp;シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

この記事は Looking beyond code coverage with Amazon CodeWhisperer (記事公開日: 2024 年 1 月 8 日) の翻訳記事です。 コードカバレッジ は、ユニットテストによりコード品質を計測するメトリクスです。すべてのパラメータの組み合わせに対するテストケースを考えるのには時間がかかりますが、開発者の時間は貴重なものになっています。開発者の焦点は、カバレッジのしきい値を満たすことのみに(誤って)向けられます。その結果、コードの品質が損なわれ、予期しない結果をもたらすコードが残る可能性があります。 この記事では AI コーディングコンパニオンの AI コーディングコンパニオンの Amazon CodeWhisperer を活用して、Java アプリケーションをウォークスルーします。時間とリソースの制約によりしばしば見過ごされがちな境界条件を含むテストケースの組み合わせを生成するコードカバレッジの先を見る方法をデモします。このアプローチを取ることで、コードの品質と生産性の両方を向上させることができます。 前提条件 AWS アカウント を作成してください。AWS アカウントをまだお持ちでない場合は、 AWS Management Console にアクセスするためにアカウントの作成が必要です。このため、 新しいユーザーを作成 することをおすすめします。 CodeWhisperer を開発環境にセットアップするには、 AWS Toolkit のセットアップ手順 に従ってください。 Java をダウンロードおよびセットアップ: Java SE Development Kit をインストール してください。 Maven をインストール してください。 VS Code 、 IntelliJ など、使用したい IDE を選択できます。このブログでは IntelliJ コミュニティエディションを使用しています。ダウンロードは こちら から。Ultimate 版のライセンスをお持ちの場合はそちらを使用できます。 リポジトリをクローン: Looking beyond code coverage with CodeWhisperer IntelliJ にインポートしたプロジェクトについては、 プロジェクトのインポート ガイドに従ってください。 上記のステップに従うと、プロジェクトをローカルにセットアップできます。以下の図 1 は、IDE に Maven プロジェクトとしてインポートした後の初期プロジェクトの見た目を示しています: 図1. Java プロジェクトの初期状態 次の画面録画 1 は、「//method for adding two numbers」 というコメントを使用して「add」メソッドのコードを生成するために、CodeWhisperer を使用する方法を示しています。 画面録画 1. 最初のアプリケーションコードの生成 それでは、画面録画 2 で示したように CodeWhisperer を使用して、1 つのシンプルなテストケースを生成してみましょう。最初のテストケースの生成: 画面録画 2. 最初のテストケース生成 テストケースを実行して、コードカバレッジを確認しましょう。図 2 の「最初のコードカバレッジを用いた最初のテスト」では、Calculator クラスで 100% のカバレッジを達成したことがわかります。カバレッジのみを見ると、コードが準備完了であると言えます。 図 2. コードカバレッジを用いた最初のテスト 1 つのユニットテストだけでは、品質が高く副作用のないコードを保証することはできません。 次に、CodeWhisperer が追加のテストケースの生成を支援する方法を見ていきます。 「// Test」 といったコメントの入力を開始するとすぐに、「// test with one negative number」、 「// test with two negative numbers」、 「test with one zero number」 など、新しいテストケースの提案が表示されます。 以下の「追加のテストケースの生成」と題された画面録画 3 で示されているように、さまざまなテストケースを生成する作業が容易になり、開発者はより短時間で多くのテストを作成できるようになります。 画面録画 3. 追加のテストケースの生成 ここまで、異なる引数でテストケースを生成し、コードカバレッジ 100% を達成してきました。 次はコードの安全性に焦点を当て、予期しない結果につながる可能性のあるさまざまな引数について考えていきましょう。 各引数は、-2,147,483,648 (int 型の最小値) から 2,147,483,647 (int 型の最大値) の範囲内である必要があります。 以下の画面録画で示すように、CodeWhisperer を使用してコードの安全性を検証するための追加のテストケースを生成しましょう: 画面録画 4. 境界条件のテストの生成 ここでまず、CodeWhisperer は整数の最大値に 1 を加えるテストケースを生成しました。そして 実行時に 「add」 メソッドが返す実際の値を確認できるように、結果をコンソールに出力するステートメントも追加しました。: ここで注目すべきは、生成されたテストケースが int 型の最小値が出力されることを期待している点です。 テストを実行すると、テストケースの結果が予期しないものであることがわかります。 符号付き整数 の演算の仕組みのため、最大の int に 1 を加えると最小値になります。 より実践的な観点から考えてみましょう。銀行システムで 「add」 メソッドを使用し、顧客が銀行口座に預金するたびに、最近の預金額を加算して口座の最終金額を計算する場合を想像してください。今度は、21.4 億ドルを預金した後に口座残高がマイナスになり、高額を支払わなければならないことを顧客が発見したときの反応を想像してみてください。 この例は、100%のカバレッジを持つコードでも予期しない副作用があることを示しています。焦点を当てるべきは、予期しない結果をもたらすパラメータの組み合わせを特定することです。そうすることで、コードを製品にこのような動作が現れる前に修正できます。 次に、CodeWhisperer を使用して、予期しない結果を生み出す可能性のある別のテストケースを生成してみましょう: 「’int’ の最小値に -1 を加える」。 再び、int の最小値に -1 を加えると、最大値が結果として得られます。 上記の例と同様に、お客様は 21.4 億ドルを引き出した後でも、銀行口座にまだお金があることに気づいて大喜びするでしょう。 再度述べますが、ポイントは開発者はカバレッジ目標を追求するよりも、コードが意図しない予期しない結果をもたらさないことを確認することに注力するべきだということです。 add メソッドが特定の条件下で整数オーバーフローを起こすことがわかったので、 「check a and b for integer overflow」 というコメントを使用して、CodeWhisperer を使ってコードを改善しましょう。 画面録画 5. コード改善-オーバーフローチェック 安全チェックを追加した後、テストケースは予期しない結果をもたらさず、上記のスクリーン録画で示されているように ArithmaticException を発生させています。 しかし、テストケースは失敗しており、失敗したテストケースは CI/CD パイプラインを中断させる可能性があります。 したがって、以下の画面録画で示されているように、この実行時例外を期待するようにこれらのテストケースをリファクタリングし、テストケースをパスさせる必要があります。 画面録画 6. テストケースの改善-オーバーフローチェック テストケースをカバレッジとともに再実行した結果、テストケースがパスしているだけでなく、100% のコードカバレッジが得られていることがわかります。 このブログのコードと対応するテストケースの大部分は、AI コーディングコンパニオンの CodeWhisperer によって生成されました。このツールを使用することで、ライブラリを簡単に検索してコードを強化できます。この例では、 「Math.addExact」 メソッドを利用することにつながりました。これは、タスクに関連する境界条件のチェックを提供します。以下の図 3 の最終コードで示すように、このメソッドを利用するようコードをリファクタリングしましょう。 図 3. 最終コード テストスイートをカバレッジとともに再実行すると、すべてのテストケースをパスしており、カバレッジも 100% が維持されていることがわかります。 図 4. カバレッジを含む最終テスト 結論: この記事を通じて、高いコードカバレッジだけでは高品質なコードが保証されないことを示しました。 Amazon CodeWhisperer のようなツールは、境界条件を含むコードと対応するテストスイートを生成することで、開発者の生産性を向上させることができます。これにより、開発者はビジネスロジックに集中し、新しいフレームワークとライブラリを学ぶことができ、結果として、コードの品質と安全性が全体的に向上します。 Java に焦点を当てた例でしたが、このコンセプトは他のプログラミング言語にも適用できます。 CodeWhisperer がサポートしているプログラミング言語と IDE の完全なリストは、 FAQ をご覧ください。 CodeWhisperer の Individual Tier を無料でお試しいただき、 CodeWhisperer スタートガイド を使用して、より効率的に高品質なコードを書くのにどのように役立つか確認してみてください。 コーディングを楽しんでください！ 翻訳はソリューションアーキテクトの江口昌宏が担当しました。 &nbsp;&nbsp;&nbsp; Saurabh Kumar Saurabh Kumar は、ノースカロライナ州 Raleigh を拠点とする AWS のソリューションアーキテクトです。移行からモダナイゼーション、最適化に至るまで、お客様がビジネス上の課題や技術的な問題を解決できるよう支援することに情熱を注いでいます。仕事以外では、ガーデニングや家族との時間を過ごすのが好きです。 Bineesh Ravindran Bineesh はアマゾンウェブサービス (AWS) のソリューションアーキテクトで、テクノロジーに情熱を持ち、お客様の問題解決を支援することが大好きです。Bineesh はエンタープライズアプリケーションの設計と実装に 20 年以上携わってきました。AWS のパートナーやお客様と協力して、スケーラブルなアーキテクチャを構築し、AWS サービスの採用を促進するための戦略を実行するためのアーキテクチャガイダンスを提供しています。仕事をしていないときは、サイクリング、アクアスケープ、バドミントンを楽しんでいます。

1月30日は、データ統合ジョブのオーサリングとトラブルシューティングに自然言語を使用することができる AWS Glue の新しいチャットエクスペリエンスをプレビューします。 AWS Glue の Amazon Q データ統合は、AWS Glue のデータ統合エンジンを使用したデータ統合ジョブの学習、構築、および実行に必要な時間と労力を削減します。ジョブのオーサリングや問題のトラブルシューティングを実行したり、AWS Glue とデータ統合に関するあらゆる質問への回答を瞬時に得たりすることができます。チャットエクスペリエンスには Amazon Bedrock が使用されます。 データ統合ワークロードを説明すると、Amazon Q が完全な ETL スクリプトを生成します。エラーを説明し、解決策を提案するよう Amazon Q に要求することで、ジョブをトラブルシューティングできます。Amazon Q は、データ統合ワークフローの全体を通じて詳しいガイダンスを提供します。Amazon Q は、AWS Glue を使用したデータ統合ジョブの学習と構築を助け、 Amazon Simple Storage Service (Amazon S3)、 Amazon Redshift 、および Amazon DynamoDB などの一般的な AWS リソースへの接続を助けることもできます。 では、AWS Glue の Amazon Q データ統合の機能をいくつかご紹介しましょう。 1.会話形式の Q&amp;A 機能 この機能の使用を開始するには、AWS マネジメントコンソールの右側にある Amazon Q アイコンを選択します。 例えば、「AWS Glue って何?」とたずねると、Amazon Q が簡潔な説明とともに、質問のフォローアップやガイダンスの検証に使用できる参照ドキュメントを提供してくれます。 Amazon Q では、ユースケースをより詳しく説明することでコンテキストを提供できます。例えば、Amazon Q に「AWS Glue ジョブを作成する方法を教えて」とたずねることができます。 次に、「AWS Glue ジョブのメモリ管理を最適化する方法を教えて」と Amazon Q にたずねます。 2.AWS Glue ジョブの作成 この機能を使用するには、Amazon Q に「Redshift から読み込み、null フィールドをドロップし、Parquet ファイルとして S3 に書き込む Glue ETL ジョブを作成して」と指示することができます。 コピーボタンをクリックするだけで、コードをスクリプトエディタやノートブックにコピーできます。また、Amazon Q に「DynamoDB テーブルを読み込み、フィールドをマップして、結果を Parquet 形式で Amazon S3 に書き込む Glue ジョブの作成を手伝って」と指示することも可能です。 Amazon Q の使用を今すぐ開始する Amazon Q では、質問に答え、コードをすばやく記述し、問題のトラブルシューティングやワークロードの最適化を行うだけでなく、新しい機能のコーディングさえも助けてくれる人工知能 (AI) エキスパートがそばについていてくれます。これらの機能は、AWS でのアプリケーション構築のすべての段階を簡素化します。AWS Glue の Amazon Q データ統合は、Amazon Q がサポートされているすべてのリージョンで利用できます。詳細については、「 Amazon Q pricing 」ページを参照してください。 詳細はこちら Amazon Q のメイン製品ページ Amazon Q データ統合 IT 専門家と開発者向けの Amazon Q 詳細情報 Amazon Q の開始方法 – Irshad 原文は こちら です。

はじめに 国内外の製薬企業において特に創薬研究領域でのクラウド利用が大きく進んでいます。国内有数の創薬研究領域の学会であるCBI学会の中で、研究者の皆様に創薬研究領域でのクラウド利用に関する関連事例や最新サービスを学んで頂くことを目的に、AWSは2つのスポンサードセッションとブース展示を行いました。スポンサードセッションでは、2023年大会のテーマでもあった「ゲノム情報・診療情報が創り出す新しい創薬と医療」に即して、基礎生物学研究所教授 重信秀治先生をお迎えし、ゲノム科学におけるクラウド活用の実際をお話しいただきました。加えて、AWSからは、 AWS HealthOmics などのゲノム領域に特化したサービスや、High Performance Computing (HPC) 関連の最新サービス、そして近年注目を集める生成系AIに関する事例やAWSの取り組みについてご紹介しました。本ブログでは、各セッションの講演資料を掲載すると共に、その発表内容の要約をご紹介します。 ゲノム科学領域における最新のAWS活用〜基礎生物学研究所のゲノム解析プラットフォーム〜 パート１「ゲノム科学領域でご利用が進む最新のAWSサービス及び活用事例のご紹介」[ Slide ] AWS エンタープライズ技術本部 ヘルスケア＆ライフサイエンス部　鳥羽 祐輔　登壇 近年シーケンシングの技術が劇的に向上したことでゲノムデータ活用に向けた取り組みは盛んになってきており、今回の CBI 学会大会の副題にも含められています。一方で、数多くのオミクスデータを分析しようとするとデータが数ペタバイトにもなり得るため、オンプレミスのストレージや解析環境では対応しきれないことや、データ活用のスピードが落ちてしまうことがあります。お客様が集中したいのは、データをどのように活用して価値に繋げるかであり、そのための IT リソースの検討や調達、またバリアントデータ等を分析するための専用ツールを使いこなすために時間をかけることではありません。 この領域で AWS を活用いただくことで、スケーラビリティのあるストレージや計算環境を手に入れることができ、ゲノムデータ活用を加速させることができます。実際に AWS は 10 年を超える期間にわたって、 医療機関や製薬企業等のお客様 がこのデータを実用的なインサイトに変換するまでの時間を短縮できるようサポートしてきました。 Ancestry 、 アストラゼネカ 、 Illumina 、 DNAnexus 、 Genomics England 、 GRAIL 等の業界の代表的なお客様は、AWS を活用して発見までの時間を短縮しつつ、コスト削減とセキュリティ強化を同時に実現しています。 本セッションの前半では、データの転送・保存・解析の 3 つのパートから構成されるゲノムデータ活用の基本アーキテクチャをベースに、各パートで活用いただける AWS サービスをご紹介しました。中でも解析パートは行いたい解析の種類や方法によって幅広いサービスからお選びいただけるようになっており、後ほどの重信先生のセッションでも紹介いただく AWS ParallelCluster や AWS Batch 、パートナー様から提供されるソリューションに加えて、AWS ではゲノミクス領域特化型のサービスやツールも提供されています。 その内の 1 つが、2022 年の re:Invent で発表された新サービス AWS HealthOmics です。AWS HealthOmics は10 年以上のゲノミクス関連システムのご支援の経験から、よりお客様が健康の改善と科学的発見の促進につながるインサイトを生み出すことに専念いただけるよう設計されたマネージドサービスです。AWS HealthOmics を利用することで、ゲノムデータ、トランスクリプトームデータ、その他のオミクスデータを保存、検索、分析することができます。 セッションの後半では実際の活用事例についてもご紹介しました。その一部としてAWS HealthOmicsの最新事例である フィラデルフィア小児病院 様のお取り組みをご紹介します。マルチオミクスデータを研究者が活用するためのフレームワークを構築するプロジェクトで AWS HealthOmics を活用いただきました。背景課題としてオープンソースの解析ツールを利用するためには多くの時間と労力がかかっており、何万人もの患者のゲノム情報を収集し続けるために拡張性のあるソリューションが求められる状況でした。その中でAWS HealthOmics を活用することで、インフラ管理とオミクスに特化したデータ変換を AWS にオフロードしながら、大規模なマルチモーダルデータ解析に研究者がアクセスできるようになりました。結果として、研究者は、科学的発見のための活動により多くの時間を費やすことができるようになりました。 パート２「ゲノム科学におけるクラウド活用：独占型スパコン構築からデータ共有まで」[ Slide ] 基礎生物学研究所 教授　重信 秀治 先生　登壇（AWS 代筆） このパートでは、基礎生物学研究所教授　重信秀治先生にご登壇いただき、1.ゲノム研究分野におけるクラウド化の動向、2. 計算資源の確保、3. データ共有による共同研究促進、をテーマに、アカデミアの領域の中でオミクスデータを扱う際の課題やクラウド利用の実際についてご講演いただきました。 まず、近年、次世代シーケンシング（NGS）などの革新的な進歩により、研究者の方々は、膨大に増えるオミクスデータを日常的に扱う必要に迫られており、その対策として、クラウドコンピューティングが世界的にも注目されているとご紹介いただいています。その例として、例えば米国では、National Center for Biotechnology Information (NCBI)はSRA（NGSデータアーカイブ）をAWS のクラウド経由で提供するようになり、National Human Genome Research Institute Home (NHGRI)はAnVILと呼ばれるゲノム解析の統合的クラウドプラットフォームの開発を推進していると、グローバルでのクラウド活用例を挙げていただきました。また、日本のアカデミアでは、2018年に政府が「クラウドサービスの利用推進」を宣言して以降、2023年5月には、競争的研究費の直接経費からクラウド利用料の支出が可能になることが明確化され、先端的なクラウド利用例が報告されつつある現状を共有いただきました。 次に、ゲノム生物学領域において、NGSデータの大規模化、基礎研究におけるトライ＆エラーの必要性、解析用のソフトウェアごとに必要なコンピューターリソースの特殊性に触れられ、柔軟で可用性のあるコンピューターリソースの確保が喫緊の課題であるとした上で、High Performance Computing (HPC) でのクラウド利用の実際についてご説明いただきました。従来の典型的なHPC環境の構成要素として、クラスターコンピュータやスパコンを利用する場合、ジョブ待ちや、OSやライブラリーのバージョンアップの固定化、サーバ調達やメンテナンスに伴う高額なコストなど、共用HPCの問題点を挙げられました。この問題に対して、基礎研究に適したHPC環境をクラウド上に作るためのサービスとして、HPC アプリケーションに必要なリソースのモデル化とプロビジョニングを自動的かつセキュアに実行可能な AWS ParallelCluster をご紹介いただきました。これにより、ジョブ待ちの無いHPC環境を実現し、研究者ごとに必要に応じた計算リソースを確保できるため解析時間が短縮され、スポットインスタンスを活用した大幅なコスト削減も実現した、とクラウド移行のメリットを語っていただきました。また、研究所とAWSはSINETで接続されており、セキュアで十分なネットワーク帯域を確保されています。 最後に、ゲノム解析結果の共有方法として、ゲノム情報を視覚的に閲覧・検索するためのツールであるゲノムブラウザに関して、目指すべき姿は「Google Mapのゲノム版」とされ、ゲノムブラウザの検索性、アクセス性、網羅性を向上させることで共同研究が加速することへの期待を寄せられています。このゲノムブラウザを構築するためのツールの代表例として、JBrowse2を挙げられ、重信先生がJBrowse2を用いて新規ゲノムブラウザのサーバレス環境をAWS上に構築されています。 Amazon S3 と Amazon CloudFront のサーバレスアーキテクチャで実装された結果、サーバ管理の手間削減やコスト削減、高付加耐性、世界中への高速配信等が実現し、かつ内部ネットワークに公開サーバを設置できないアカデミアの機関がほとんどのため、セキュアなクラウド環境を利用できることがメリットだとご紹介いただきました。ゲノムブラウザの中でも特にニーズが高いツールとして、配列検索ツール「Basic Local Alignment Search Tool (BLAST)」に触れられ、AWS環境を利用したLight-weight Serverless BLASTの開発に重信先生が現在取り組まれているとお話しされました。これは、NCBIから提供されるバイナリのBLASTをDockerコンテナ化し、 AWS Lambda を活用することで、BLAST環境のサーバレス化を実現されたもので、「開発後のメンテナンス面を考慮すると、サーバレスアーキテクチャを目指すべきである」と語られています。 創薬の未来へのカギ：クラウドで活用されるHPCと生成系AI パート３「AWSのHPCへの取り組みと創薬分野における事例」[ Slide ] AWS パブリックセクター技術統括本部 ソリューションアーキテクト　佐々木 啓　登壇 創薬の研究開発に用いられる計算インフラの課題として、計算需要の変動性、手法の多様性による異なる環境要件、外部とのセキュアなデータ共有、および調達や保守管理の負担が挙げられます。クラウドを活用することで、これらの課題を解決し研究プロセスを加速することができます。 クラウドは必要な時に必要な計算リソースを効率良く活用できるため、オンプレミスの限られた資源で時間がかかっていた処理を、一度に多くのリソースを立ち上げて短期間で完了させることや、ユーザやタスクごとに専用のクラスタを立ち上げて、最適な計算環境で処理することが可能です。 Harvard Medical Schoolでの創薬研究 では長大な計算時間が必要とされる数十億規模の化合物ドッキングシミュレーションをAWS上で228万vCPUを活用することで数時間で完了しました。 AWSのHPC関連サービスは仮想サーバ(Amazon EC2)、高速ネットワーク（Elastic Fabric Adapter）やファイルストレージ(Amazon S3、Amazon FSx for Lustre)、オーケストレーションツール（AWS ParallelCluster）があり、これらを組み合わせてオンプレミスHPCの使い慣れたツールやソリューションを実行することもできます。第一三共株式会社様は、創薬化学研究プラットフォームで、OpenEyeやSchrödingerなどの既存ツールをAWSの動的リソースに構築するとともに、新たにAI/MLサービスとの連携を行い研究業務を進歩させました。 AWSはArmベースのGravitonプロセッサを独自開発しており、2023年にHPC分野に最適化したGraviton3Eインスタンスとして Hpc7g をリリースしました。 また AWS ParallelCluster はバッチジョブスケジューラとスケーラブルに伸縮するクラスタ環境を構築する公式オープンソースソフトウェアです。設定ファイルでInfrastructure as Code(IaC)を実現できるため、測定したHPC環境を別のユーザが用いることで同じ環境を再現することが可能です。 クライオ電子顕微鏡のデータ解析ソフトウェアRelionはAWS ParallelClusterを介してジョブを実行する機能が整備されています。大塚製薬様の創薬プラットフォームではRelionのデータ解析や、AlphaFoldを使ったAI基盤を整備しています。 高エネルギー加速器研究機構 様のGotoCloudプロジェクトでは、クライオ電子顕微鏡の出力データをAWS上にハブ化し、最適化された解析基盤をIaCで提供することで外部企業や研究機関の活動を支援しています。 理化学研究所様のバーチャル富岳プロジェクトでは、スーパーコンピューター富岳で開発されたアプリケーションを幅広く活用することを目指し、Amazon EC2 Hpc7gインスタンスへのマイグレーションを行いました。超並列分子動力学ソフトウェアGENESISは、ParallelClusterで構築したHPC環境上でソフトウェアスタックの整備、アプリケーションチューニングを行い、AWS上で有用性を検証しました。この取り組みの成果として、GENESIS on AWSとして株式会社理研数理様が商用サービスとしてGENESISを実行可能なAWS環境と利用サポートを提供しています。(2023年12月よりサービス開始)。 以上のように、AWSのサービスは、創薬研究開発の計算インフラにおける多くの課題を解決するための強力なツールとなり得ます。これにより、研究者は研究の本質に集中し、プロセスを加速させることが可能となります。 パート４「創薬における機械学習の最新動向 – 生成系 AI がもたらすイノベーション」[ Slide ] AWS エンタープライズ技術本部 ハイテク・製造・自動車産業グループ ソリューションアーキテクト　森下 裕介　登壇 創薬において AWS がお客様に提供できる価値の 1 つとして、「スケーラビリティと俊敏性の両立による創薬の加速」が挙げられます。AWS は 10 年以上にわたり日本や海外の製薬会社を支援しており、創薬研究における機械学習というトピックにおいては、ゲノミクスや画像解析、量子コンピューティングなどの幅広いユースケースで AWS をご活用いただいています。創薬研究での機械学習におけるAWS 活用事例として、中外製薬様の抗体創薬への取り組み、アストラゼネカ様の腎臓病理画像解析の事例、日本たばこ産業様のグラフニューラルネットワークの活用事例をご紹介しました。 一方で、「生成系 AI」 というアプローチが昨今急速に進化を遂げています。生成系 AI とは、テキストや画像などの新たなコンテンツやアイデアを高精度に生成可能な AI の一種です。事前学習された大規模な基盤モデルの活用により、個別の学習不要で複雑で広範なタスクに対応できる柔軟性を持つようになりました。 創薬研究領域における生成系 AI の活用ユースケースは 2 つに大別できます。1 つが「汎用的な生成系AIによる研究活動の効率化」と、もう 1 つが「創薬ドメインに特化した生成系AIによる解析・デザインの高度化」です。本セッションでは前者について説明しました。後者に関しては次の石尾のセクションをご覧ください。 汎用的な生成系 AI を活用することで、論文要約や翻訳、解析コードの生成など研究にまつわる様々なタスクを効率化できます。セッションの中では、サンプルの対話型 AI アプリケーションを通して AlphaFold2 の論文 を日本語で要約するデモを実施しました。 このような生成系 AI アプリケーションを簡単に構築できるサービスが Amazon Bedrock となります。Amazon Bedrockは、Amazon や最先端の AI 企業が提供する、テキストや画像生成などの様々な基盤モデルを API 経由で利用できるマネージドサービスです。基盤モデルやインフラの管理は AWS が行い、またお客様のデータが基盤モデルの学習に一切利用されることはなくプライベートかつセキュアな利用が可能となります。 こうした Amazon Bedrock などで提供される基盤モデルを、お客様固有のデータをうまく活用することが他社との差別化につながります。本セッションでは、基盤モデルとお客様固有のデータを組み合わせるアプローチの一つとして、RAG（Retrieval-Augmented Generation; 検索拡張生成）をご紹介しました。こちらは膨大な社内ドキュメントやデータから該当する情報を検索する社内文書検索の結果を基盤モデルと組み合わせるというアプローチです。基盤モデルの学習データ外の情報である社内データに基づいた正確な回答をファインチューニング不要で実現することができます。 実際にこの RAG アプローチに取り組まれている製薬業界のお客様として アストラゼネカ様の事例 を取り上げました。アストラゼネカ様では MR が医療従事者に最新かつ適切な製品情報を提供できるように、社内文書をリアルタイム検索できる仕組みを Amazon Kendra を用いて実現しました。また、これと Amazon Bedrock との組み合わせによって、より自然な対話での直感的な情報検索が可能になり、MRは医療従事者との対話をよりスムーズにできるようになると期待されています。 Amazon Bedrock は AWS マネージメントコンソールの Playgrounds からお試しできるほか、様々なユースケースを実際にご体験いただける デモソリューション もオープンソースで提供しています。これらの試用を通じて皆様の業務の中で生成系 AI が価値を発揮するユースケースを見極めていただくことで、皆様のビジネス課題の解決につながります。 パート５「クラウドと生成系AIを活用した創薬研究：タンパク質構造予測を例に」[ Slide ] AWS エンタープライズ技術本部 ヘルスケア＆ライフサイエンス部 ソリューションアーキテクト　石尾 千晶　登壇 最後のセッションでは、創薬研究におけるクラウド上での生成系AIの活用についてご紹介しました。生成系AI の活用の方向性として、大別して「汎用的な生成系AIによる研究活動の効率化」と、「創薬ドメインに特化した生成系AIによる解析・デザインの高度化」があります。一つ前のセッションでは前者について紹介したので、こちらのセッションでは後者に焦点を当ててお話ししました。 医薬品開発の現場では、薬価の引き下げやパテントクリフへの対応が求められるなど、タイムリーな開発が必要になる中で、個別化医療に向けた期待も高まっており、新薬の開発は難しくなっています。こうした状況で、機械学習を活用した創薬技術が求められています。 創薬研究の質向上にはさまざまな側面があります。今回は、医薬品開発において重要な役割を持つ、タンパク質構造解析を例に取り上げました。タンパク質の数は約2億個以上ありますが、そのうち実験で構造が解明されているのは、わずか0.1%（20万個）程度です。このような状況の中で、 AlphaFold をはじめとした機械学習を用いた構造予測のアルゴリズムが発表され、その後も、さまざまな企業や研究機関から次々とアルゴリズムが発表されています。 このような状況の中で、研究者が直面する課題として、新しいアルゴリズムを素早く試せること、使い慣れたインターフェースへの統合、秘匿性の高いデータをセキュアに解析することなどが挙げられます。また、開発環境のスケーラビリティや計算環境の強化、コスト最適化も重要な要素です。 クラウドを活用することで、スケーラビリティのある開発環境で、柔軟かつ効率的な解析ができるようになり、研究者は研究の本質により一層集中できるようになります。AWSでは、 AWS ParallelCluster 、 AWS Batch 、 AWS HealthOmics など、様々な実行環境が提供されています。このような実行環境と合わせて、各研究者が使い慣れたインタフェースを使うことで、素早く解析を開始することができます。インターフェースと実行環境の組み合わせは、各研究者の好みによってどのように組み合わせても構いませんが、例として、以下の図中の ② の組み合わせについて掘り下げて説明しました。 ② の構成は、以下の図に示す通りで、大きく3つのパートに分かれており、それぞれ Jupyter Notebook のインターフェース（左側）、スケーラブルな計算環境（下側）、大規模データを高速に処理するためのストレージ（右上）となっています。計算環境としては AWS Batch が使われており、AlphaFold2 をはじめとした10種類以上のアルゴリズム用のコンテナを、必要な時に必要な分だけ起動して計算できます。この構成全体をみなさまの環境ですぐにお使いいただけるよう、 実装ガイド や、 CloudFormation テンプレートを含むソースコード も提供しております。また、この実装をさらに発展させたものとして、 AWS Drug Discovery Workbench というウェブアプリのフロントエンド付きの実装例もご紹介しました。 最後に、創薬研究における生成系AI の活用をさらに進めていくための支援プログラムとして、 Generative AI Innovation Center についても触れました。お客様とAWSのAI/機械学習エキスパートをつなぎ、生成系AIを活用したシステムやモデルの構築と展開をサポートするプログラムとなっていますので、ぜひ合わせてご活用ください。 おわりに AWSはインダストリーに特化したお客様の事業課題に対してご支援をしております。過去のお客様のお取り組み/事例を ヘルスケア・ライフサイエンスWebページ に掲載しておりますので、ぜひお立ちよりください。また今回のブログに関してご質問やご要望がある場合には、担当営業もしくは お問い合わせページ よりご連絡をお願いいたします。 著者について 鳥羽 祐輔 (Yusuke Toba) エンタープライズ技術本部 ヘルスケア＆ライフサイエンス部 ソリューションアーキテクト 現在は製薬企業のお客様向けにクラウド活用に関する技術的なご支援をおこなっています。 佐々木 啓 (Kei Sasaki) パブリックセクター技術統括本部 ソリューションアーキテクト 大学・研究機関のお客様を中心に、研究・教育・事務のクラウド化の技術支援を担当しております。 森下 裕介 (Yusuke Morishita) エンタープライズ技術本部 ハイテク・製造・自動車産業グループ ソリューションアーキテクト 製造業のお客様を中心に技術支援を担当しております。 石尾 千晶 (Chiaki Ishio) エンタープライズ技術本部 ヘルスケア＆ライフサイエンス部 ソリューションアーキテクト エンタープライズの製薬業界のお客様向けに、クラウド活用のための技術支援をおこなっています。 片岡 勇人 (Yuto Kataoka) ヘルスケア・ライフサイエンス事業開発部 シニア事業開発マネージャー クラウドに対する日本のお客様固有の要件にお応えするために、AWS グローバルチームとも連携し、ヘルスケア・ライフサイエンス領域のお客様の取組みをご支援しております。

生成 AI コーディングツールは、開発者の日々の開発作業の仕方を変えています。関数の生成からユニットテストの作成まで、これらのツールはお客様のソフトウェア開発の加速に役立っています。 Amazon CodeWhisperer は、開発者の自然言語のコメントと周囲のコードに基づいてコードのレコメンデーションを提供することで、開発者の生産性を向上させる IDE とコマンドラインの AI による生産性向上ツールです。 CodeWhisperer を使用すると、開発者は「 S3 にファイルをアップロードする Lambda 関数を作成する」など、特定のタスクを簡単な英語で概説するコメントを単純に記述することができます。 CodeWhisperer に対してこれらの自然言語のコメントのような入力プロンプトを記述する際、プロンプトエンジニアリングは重要な概念の1つです。 プロンプトエンジニアリングは大規模言語モデル (LLM) との対話を改善して、モデルの出力をより良いものにするプロセスです。 私たちは CodeWhisperer に提供するプロンプトを改善して、より良いコード出力を生成したいと考えています。 この投稿では、Python における効果的なプロンプトエンジニアリングを通じて、 CodeWhisperer の機能を最大限に活用する方法を探っていきます。巧みに作られたプロンプトにより、ツールの全能力を引き出し、生産性を向上させ、使用目的に合った正しいコードを生成するのに役立ちます。明確で具体的なプロンプトの記述や、有益なコンテキストと例の提供など、プロンプトエンジニアリングのベストプラクティスについて説明します。また反復的にプロンプトを改良して、より良い結果を生み出す方法についても議論します。 CodeWhisperer を使ったプロンプトエンジニアリング CodeWhisperer を使ったプロンプトエンジニアリングにおいて、以下のベストプラクティスをデモンストレーションします。 プロンプトは具体的かつ簡潔に保つ プロンプトでの追加のコンテキスト 複数のコメントの利用 コメントとコードからのコンテキストの取得 クロスファイルコンテキストでのユニットテストの生成 クロスファイルコンテキストを持つプロンプト 前提条件 ローカルで検証するために必要な前提条件は以下のとおりです。 AWS アカウント Visual Studio Code またはサポートされている JetBrains IDEs IDE 内で CodeWhisperer をローカルで有効化する Python CodeWhisperer ユーザーアクション IDE に応じた CodeWhisperer ユーザーアクション の以下のドキュメントを参照してください。このドキュメントでは、レコメンデーションを受け入れる方法、推奨オプションを順に切り替える方法、推奨を拒否する方法、CodeWhisperer を手動でトリガーする方法が説明されています。 プロンプトを具体的かつ簡潔に保つ このセクションでは、プロンプトを具体的かつ簡潔に保つ方法を説明します。CodeWhisperer のプロンプトを作成する際、プロンプトの目的を維持しつつ簡潔であることは重要な要素です。 過度に複雑なプロンプトは結果を悪くします。 良いプロンプトには、要求を明確かつ簡潔に伝えるのに必要な情報が含まれています。 例えば、 CodeWhisperer に 「create a function that eliminates duplicates lines in a text file」 とプロンプトするとします。 これは具体的かつ簡潔なプロンプトの例です。 一方、 「create a function to look for lines of code that are seen multiple times throughout the file and delete them」 などのプロンプトは不明確で冗長すぎる可能性があります。 まとめると、焦点を絞った直接的なプロンプトは CodeWhisperer があなたが何を望んでいるかを正確に理解し、より良いレコメンデーションを提供するのに役立ちます。 この例では、 Python で CSV ファイルを開き、ファイルの内容を辞書に格納する関数を書きたいと思います。 以下のシンプルかつ簡潔なプロンプトを使用して、 CodeWhisperer にレコメンデーションを生成させます。 レコメンデーションを受け入れる前に、左/右の矢印キーを使用して、さまざまな推奨事項を順に表示してください。 例 1: コメントの例: #load the csv file content in a dictionary ソリューションの例: #load the csv file content in a dictionary import csv def csv_to_dict(csv_file): with open(csv_file, 'r') as f: reader = csv.DictReader(f) return list(reader) 簡潔で明確なプロンプトは、プロンプトエンジニアリングにおいて重要です。なぜなら、それらは CodeWhisperer が余計な詳細に惑わされることなく、重要な情報を理解するのに役立つからです。シンプルで簡潔なプロンプトは、反復のスピードを上げ、文字数制限内で最大限の効果を発揮できるようにします。 プロンプトの追加のコンテキスト このセクションでは、追加のコンテキストがプロンプトエンジニアリングをどのように支援できるかを説明します。詳細で具体的かつ簡潔なプロンプトが重要ですが、追加のコンテキストは CodeWhisperer の理解を助けることができます。具体例は簡潔なプロンプトからのユーザーの要求を CodeWhisperer が推測するのが困難な場合にも、ガイドラインを提供します。 この例では、 CSV ファイルのコンテンツを辞書に格納した例1に追加のコンテキストを加えたいと思います。今回は、アルファベット順に CSV ファイルのコンテンツを格納し、辞書からキーリストを返す追加の要件があります。以下のサンプルプロンプトをご覧ください。適切なコンテキストは、 CodeWhisperer が高品質でカスタマイズされたレコメンデーションを生成するのに役立ちます。 例 2: コメントの例: #load the csv file content in a dictionary in alphabetical order and return the list of keys ソリューションの例: #load the csv file content in a dictionary in alphabetical order and return the list of keys import csv def csv_to_dict(file_name): def read_csv_file(file_name): with open(file_name, 'r') as csv_file: csv_reader = csv.DictReader(csv_file) csv_dict = {} for row in csv_reader: csv_dict[row['name']] = row return csv_dict プロンプトを CodeWhisperer に提示する際、背景の詳細や例を通じて追加のコンテキストを提供することは有益です。ただし、その追加情報が本質的な要求を曖昧にするのではなく、有用な明確さを加える場合に限ります。簡潔さと的を射たコンテキストのシグナルの適切なバランスは、 CodeWhisperer がより適合性の高い高品質なレコメンデーションを生成するのに役立ちます。 複数のコメントを利用する このセクションでは、プロンプトエンジニアリングにおいて、複数のコメントがどのように有用なテクニックとなりうるかを説明します。戦略的に CodeWhisperer を使用することで、複数のコメントにより、簡潔さを犠牲にすることやプロンプトを乱雑にさせることなく、より多くのコンテキストを提供できます。 例えば、 CSV ファイルを開き、その中の行をアルファベット順に並べ替え、重複行を削除し、各行の末尾にピリオドを追加して返す、ということをしたいとします。以下の CodeWhisperer のプロンプトを見てください。複数の要件を別々のコメントに分割していることに注目してください。 例 3: コメントの例: #open a csv file and return a list of lines in alphabetical order #Remove duplicate lines #Insert a period at the end of each line ソリューションの例: #open a csv file and return a list of lines in alphabetical order #Remove duplicate lines #Insert a period at the end of each line def open_csv(filename): with open(filename) as f: lines = f.readlines() lines = list(set(lines)) lines = sorted(lines) for i in range(len(lines)): lines[i] = lines[i].rstrip() + '.' return lines 複数のコメントを許可することで、プロンプトを簡潔に保ちながら、拡張されたコンテキストとガイダンスを CodeWhisperer に追加できるようになります。 コメントとコードから得られたコンテキスト このセクションでは、 CodeWhisperer のコンテキストがコメントだけでなく、周辺のコード(他の関数、インポートなど)も参照していることを説明します。この拡大されたコンテキストにより、 CodeWhisperer はコメントで意図したユースケースを実装するのに役立ちます。 ここでは、プロジェクト内の追加のコードがレコメンデーションにどのように影響するかを見ていきます。今回は Pandas ライブラリをインポートして、前のセクションと比較してレコメンデーションがどのように変化するかを確認します。 例 4: コメントの例: import pandas as pd #open a csv file and return a list of lines in alphabetical order #Insert a period at the end of each line #Replace duplicate lines with a single line ソリューションの例: import pandas as pd #open a csv file and return a list of lines in alphabetical order #Insert a period at the end of each line #Replace duplicate lines with a single line def open_csv(filename): df = pd.read_csv(filename) df = df.sort_values(by='line') df = df.drop_duplicates(subset='line') df['line'] = df['line'] + '.' return df['line'].tolist() Pandas をインポートすることで、 CodeWhisperer はソリューションでそれを活用する意図があると理解しています。これにより、 read_csv() 、 sort_values() 、 drop_duplicates() などの Pandas 関数を使用した、より関連性の高いレコメンデーションを提供できます。 コードの周囲のコンテキストは、おおまかな指示における実装の意図について、 CodeWhisperer に追加の手がかりを提供します。 クロスファイルコンテキストを用いたプロンプト 前のセクションでは、 CodeWhisperer がコンテキストとして取り込む周囲のコードを利用することで、ユースケースに合わせた関数を生成できることを確認しました。このセクションでは、 CodeWhisperer のクロスファイルコンテキスト機能を用いて、構築した関数のためのユニットテストを生成します。このセクションでは、テスト駆動開発のようなユースケースでクロスファイルコンテキストを用いたプロンプトの使い方をデモンストレーションします。 この例では、 CodeWhisperer に open_csv 関数を参照するコメントを書かせることで、ユニットテストを記述します。この場合、プロジェクトディレクトリにユニットテスト専用の新しい Python ファイルがあるとします。これまで作業してきたファイルが 「example4.py」 で、新しいファイルが 「unittest.py」 だとします。 「unittest.py」 に以下のコメントを含めます。 例 5: unittest.py のコメントの例: #create unit tests for the open_csv function from example4.py file unittest.py のソリューションの例: #create unit tests for the open_csv function from example4.py file class TestOpenCsv(unittest.TestCase): def test_open_csv(self): self.assertEqual(open_csv('example4.csv'), ['a.', 'b.', 'c.']) self.assertEqual(open_csv('example4.csv'), ['a.', 'b.', 'c.', 'd.']) CodeWhisperer が 1 つのファイルのコンテキストを使って、別のファイルでコードのレコメンデーションを生成していることに注目してください。 「unittest.py」 のコメント内で open_csv 関数を指定することで、 CodeWhisperer はその関数の目的とインターフェースを分析し、理解することができ、それを検証するための基本的な単体テストのセットを生成することができました。プロンプトを使うことで、クロスファイルのコンテキストを利用して単体テストを生成することができました。 Chain of thought (思考の連鎖) プロンプティング Chain of thought (思考の連鎖) プロンプティングは、複数のプロンプトをつなげることで、大規模言語モデル (LLM) がより自然なコンテキストを考慮した出力を生成できるようにするプロンプトエンジニアリングの手法です。 CodeWhisperer を利用する際、この手法を用いて非常に複雑なコーディングタスクを小さなステップに分解することによって、 CodeWhisperer がユースケースに対してより正確なレコメンデーションを行うことができます。 この例では、 CodeWhisperer によって生成されたコードスニペットで、複数のコメントが含まれているものを検証します。目的は、ユーザーにファイル名の入力を促し、それが csv かつアルファベット数字であることを確認した上で、 logging.info メソッドで処理することです。 Chain of thought (思考の連鎖) によるアプローチと単一のコメントの 2 通りで出力を分析します。 例 6: Chain of thought (思考の連鎖) プロンプトアプローチ: コメント 1 – “Take a user’s input using the input() function and store it in a variable called filename” import logging # Take a users input using the input() function and store it in a variable called filename filename = input("Enter the name of the file you want to read: ") コメント 2 – “create a function that will take a filename as an input” import logging # Take a users input using the input() function and store it in a variable called filename filename = input("Enter the name of the file you want to read: ") #create a function that will take a filename as an input def open_file(filename): コメント 3 – “validate the input using the isalnum() method and ensure the file ends in .csv then process the file using logging.info()” import logging # Take a users input using the input() function and store it in a variable called filename filename = input("Enter the name of the file you want to read: ") #create a function that will take a filename as an input def open_file(filename): #validate the input using the isalnum() method and ensure the file ends in .csv then process the file using logging.info() if filename.isalnum() and filename.endswith('.csv'): lines = open_csv(filename) logging.info(lines) return lines else: print('Invalid file name') return None 単一プロンプトによるアプローチ: import logging ''' Using the input() function and store it in a variable called filename and create a function that will validate the input using the isalnum() method and ensure the file ends in .csv then process the file accordingly. ''' def validate_file(filename): if filename.isalnum() and filename.endswith('.csv'): return True else: return False これらを並べて分析すると、 Chain of thought (思考の連鎖) プロンプトアプローチを用いた場合、ユーザー入力、入力検証、 .csv の検証、ログ記録など、 CodeWhisperer にすべての要件を実装させるために、複数のコメントを使用したことがわかります。一方、複数の要件を 1 つのコメントで実装したケースでは、この少し複雑な問題のすべての要件を考慮していなかったことがわかります。 結論として、 Chain of thought (思考の連鎖) プロンプトは CodeWhisperer のような大規模な言語モデルが、複雑な問題を論理的なステップに分解することで、使用例に関してより正確なコードを生成できるようにします。コメントとプロンプトでモデルを導くことで、タスクの各部分に順を追って集中できるのです。その結果、広範囲な 1 つのプロンプトと比較して、目的の機能により適合した正確なコードが生成されます。 まとめ 効果的なプロンプトエンジニアリングは、 Amazon CodeWhisperer のような強力な AI コーディングアシスタントを最大限に活用するための鍵です。具体的な説明、コンテキストの提供、プロンプトの反復的な改良などのプロンプトのベストプラクティスに従うことで、 CodeWhisperer はニーズに合わせた高品質なコードを生成するのに役立ちます。 CodeWhisperer が提供するすべてのコードオプションを分析することで、最適なアプローチを選択する柔軟性が得られます。 翻訳はソリューションアーキテクトの紙谷が担当しました。原文は こちら です。 著者について Brendan Jenkins Brendan Jenkins は、Amazon Web Services (AWS) のソリューションアーキテクトで、エンタープライズの AWS カスタマーに技術的なガイダンスを提供し、ビジネス目標の達成を支援しています。彼は DevOps と機械学習技術を得意としています。 Riya Dani Riya Dani は、Amazon Web Services (AWS) のソリューションアーキテクトで、エンタープライズのお客様がクラウドへの移行を進める際の支援を担当しています。学びに対する情熱を持ち、バージニア工科大学でディープラーニングに焦点を当てたコンピューターサイエンスの学士号と修士号を取得しています。自由時間には、アクティブに過ごしたり読書を楽しんでいます。

みなさん、こんにちは。 アマゾン ウェブ サービス ジャパンの機械学習ソリューションアーキテクト 鮫島です。 特定のテーマにフォーカスし最新テクノロジーを学べるオンラインイベント AWS Innovate を2024年2月22日 (木) に開催します。今年最初の開催となる今回は、AI/ML and Data (人工知能、機械学習、データ) がテーマです。特に今回の AWS Innovate は生成 AI に焦点を当て、これから生成 AI に取り組む方も、すでに 生成 AI の取り組みを始めている方も楽しんでいただけるようにしました。具体的には、AWS の生成 AI サービス、AI/ML プラットフォーム、生成 AI の活用シーンを学ぶためのユースケースの紹介を主なトピックとして取り上げます。セッション以外にもハンズオンのコンテンツを用意しているので、手を動かしながら生成 AI を学ぶこともできます。ぜひこの機会に、生成 AI の具体的な活用方法や構築方法を確認いただき、実践にお役立てください。 AWS Innovate の目的: 生成 AI を実業務に適用する 2023 年、生成 AI の技術は瞬く間に人々の生活に広がりました。多くの人が、生成 AI の文章や画像を生成する能力を目の当たりにし、日常のさまざまな業務へ適用することを検討しています。一方でお客様から「生成 AI をどのように使えば良いのかわからない」、「生成 AI を利用してみたいが技術的に難しい」、「生成 AI 単独でしか使っておらず、自社データとの連携ができていない」といった声が上がっており、実業務への適用には乗り越えるべき課題が存在しています。 こうした課題を乗り越えて生成 AI を実業務に適用するために、以下のようなジャーニーを歩むことになるかもしれません。 生成 AI のユースケースを学び、実業務にどのように生成 AI を活かすことができるかを理解する。 ユースケースが定まったら、ユースケースを実現するために必要な生成 AI の技術・サービスについて学ぶ。 生成 AI の技術・サービスを理解し、ユースケースを実現するための生成 AI アプリケーションを構築する。 AWS Innovate は、生成 AI のユースケース、AWS サービス、AI/ML プラットフォームを紹介するセッションを提供し、上記の生成 AI を実業務に適用するまでのジャーニーを支援することを目的とします。AWS Innovate に参加するメリットは以下の通りです。 AWS の生成 AI サービスとユースケースを学び、自社ビジネスへの生成 AI への適用検討を開始できる。 フルマネージドな環境で生成 AI を活用する方法を学び、生成 AI アプリケーションを効率よく開発できる。 生成 AI をはじめとする AI/ML に特化したプラットフォームについて学び、生成 AI の価値を最大化する方法で実装できる。 セッションと見どころ AWS Innovate は (T1) オープニングセッションで始まり、(T2) 生成 AI、(T3) AI/ML プラットフォーム、(T4) ビジネスユースケースの 3 つのトラックを並列して開催します。全てのセッションは、同日に 2 回提供配信されますので、同じ時間帯のセッションであっても、時間をずらすことによって聴講することが可能です。例えば、これから生成 AI に取り組む方は、まずは (T4) ビジネスユースケースのトラックを聴講してユースケースを理解し、それを実現するために (T2) 生成 AI のトラックを次に聴講するということが可能です。各トラックの見どころについて簡単に紹介します。 タイムテーブルを PDF で見る (T1) オープニングセッション オープニングセッションでは、生成 AI への取り組みを継続してイノベーションを起こすためにはどうすれば良いか、お客様の取り組みに AWS がどのように貢献できるかを説明します。生成 AI への取り組みを継続することは困難を伴う場合があり、持続可能な仕組みを用意することが重要です。Amazon は AI/ML への投資を 20 年以上続けており、それによってイノベーションを実現してきました。オープニングセッションでは、Amazon のイノベーションの考え方を踏まえ、特に Data is the differentiator (データを差別化要因として扱う) をキーワードに、生成 AI とデータをどのように組み合わせるかを説明します。 (T2) 生成 AI 生成 AI トラックはお客様が生成 AI を利用するための AWS サービスを紹介します。2023 年の AWS re:Invent で紹介された生成 AI スタックに従い、上段のアプリケーションとしてすぐに利用できるコード生成サービス Amazon CodeWhisperer に関するセッション (T2-4)、中段の生成 AI アプリケーションを構築するためのサービスである Amazon Bedrock (T2-1)、アプリケーション開発方法 (T2-3)、下段の Amazon SageMaker を利用したモデルのファインチューニング (T2-2) や、生成 AI を支えるインフラ技術 (T2-5) のセッションを提供します。 (T3) AI/ML プラットフォーム 生成 AI は非常に広範な AI/ML の技術の一つであり、それらの開発、運用、利用に対しては、これまでの成熟した AI/ML プラットフォームを利用することができます。AWS は機械学習のプラットフォームとして、Amazon SageMaker を 2017 年に発表し 6 年にわたって開発を続けてきました。Amazon SageMaker の機能を活用して生成 AI/ML を含む AI/ML に取り組みたい方へ、最新の情報を提供します。Amazon SageMaker の基礎 (T3-1) から始まり、ノーコードで機械学習を試せるAmazon Canvas (T3-2)、コードを書いてより柔軟に機械学習を試す方向けの Amazon SageMaker Studio (T3-3) のセッションを提供します。すでに機械学習を活用している方が運用を効率化するための MLOps (T3-4) や AI を利用してノーコードでデータを可視化する生成 BI (T3-5) についても紹介します。 (T4) ビジネスユースケース ビジネスユースケーストラックでは、AWS を活用してすでに生成 AI の取り組みを開始されている丸紅株式会社様、株式会社日立製作所様、株式会社ナウキャスト様をスピーカーとして迎え、生成 AI を実業務にどのように適用しているかをご紹介いただきます。実業務への適用におけるリアルな課題や解決策について知ることができる貴重な機会です。AWS エキスパートからも、生成 AI に取り組もうとしているお客様が「利益につながる」ユースケースを発見するための ML Enablement Workshop の紹介や、典型的なユースケースに対してすぐに適用できる生成 AI サービス Amazon Q の紹介を行います。 ハンズオンセッション 今回の AWS Innovate では、生成 AI をはじめとする3 つのハンズオンセッションをご用意しました。 生成 AI を用いたアプリケーションを簡単に構築可能なサービス Amazon Bedrock の使い方をステップバイステップで紹介する「Amazon Bedrock 入門ハンズオン」をはじめ、「ノーコード ML ツール Amazon SageMaker Canvas の始め方」、「Amazon CodeWhisperer を活用する Amazon SageMaker Studio 入門ハンズオン」をご用意してお待ちしています。ハンズオンセッションは、イベントプラットフォームの「ハンズオン &amp; 関連資料」チャンネルにて、 ご自身の AWS アカウントでいつでもお試しいただけます。 いますぐ AWS Innovate に申し込みましょう 2 月 22 日 (木) のみなさまのご参加をお待ちしています。当日はチャット形式のライブ Q＆A も実施しますので、AI/ML やデータ活用についての疑問点、お悩みなどもお気軽にお寄せください。みなさまと会話できることを楽しみにしております。 詳細・お申し込みは こちらから ！

このブログは、 Improve ML developer productivity with Weights &amp; Biases: A computer vision example on Amazon SageMaker を翻訳したのものです。 2023年7月：この投稿は正確性のためにレビューされました。 この投稿は、Weights &amp; BiasesのThomas Capelle と共同執筆です。コンピュータビジョンや自然言語処理などのディープラーニング技術をより多くの組織が使用するにつれて、機械学習（ML）開発者のペルソナは、実験追跡、リネージ、およびコラボレーションを取り巻く拡張可能なツールが必要になります。実験追跡には、オペレーティングシステム、使用されるインフラストラクチャ、ライブラリ、入出力データセットなどのメタデータが含まれ、しばしば手動でスプレッドシートに追跡されます。リネージには、ML モデルを作成するために使用されたデータセット、変換、アルゴリズムの追跡が含まれます。コラボレーションには、ML 開発者が単一のプロジェクトで作業するだけでなく、チーム間やビジネスステークホルダーに結果を共有することも含まれます。このプロセスは一般的に、メール、スクリーンショット、PowerPoint プレゼンテーションを介して行われます。この投稿では、Weights &amp; Biases（W&amp;B）と Amazon SageMaker を使用して、自動運転開発のユースケースに対して物体を識別するモデルを訓練します。共同ソリューションが ML 開発者の手動作業を削減し、モデル開発プロセスの透明性を高め、プロジェクトに取り組むチームのコラボレーションを可能にする方法を紹介します。 この例は、皆さんが自分で試せるように Amazon SageMaker Studio で実行します。 Weights &amp; Biases の概要 Weights &amp; Biases は ML チームがより早くより良いモデルを構築するのに役立ちます。SageMaker ノートブックに数行のコードを追加するだけで、モデルのデバッグ、比較、再現を即座に行うことができます。これには、アーキテクチャ、ハイパーパラメータ、git コミット、モデルの重み、GPU 使用状況、データセット、予測などが含まれます。これにより、チームメイトとのコラボレーションも促進されます。 W&amp;B は、世界中の最も革新的な企業や研究機関から 200,000 人以上の ML 実践者に信頼されています。無料で試すには、 Weights &amp; Biases にサインアップするか、 W&amp;B の AWS マーケットプレイスのリスト を訪れてください。 SageMaker Studio の利用開始 SageMaker Studio は、機械学習 (ML) 用の最初の完全統合開発環境 (IDE) です。Studio は、ML 実践者やデータサイエンティストが、一箇所でモデルを構築、トレーニング、デプロイするための単一の Web ベース インターフェースを提供します。これは、数回のクリックで行うことができます。 Studio を始めるには、AWS アカウントと、Studio ドメインを作成する権限を持つ AWS Identity and Access Management (IAM) ユーザーまたはロールが必要です。 Amazon SageMaker ドメインへのオンボードでドメイン を作成し、Studio のビジュアル インターフェースとノートブックの使用方法に関する概要については、 Studio のドキュメント を参照してください。 環境を設定する この投稿では、独自のコードを実行する必要がありますので、GitHub からいくつかのノートブックをインポートしましょう。以下の GitHub リポジトリ を例として使用するので、 このノートブック をロードしましょう。 リポジトリをクローンするには、ターミナルまたは Studio UI を通じて行うことができます。ターミナルを通じてリポジトリをクローンするには、システムターミナルを開きます（ ファイルメニュー で「 新規 」を選択し、「 ターミナル 」を選択）し、以下のコマンドを入力します： git clone https://github.com/wandb/SageMakerStudio Studio UI からリポジトリをクローンするには、「 SageMaker Studio で Git リポジトリをクローンする 」を参照してください。 始めるには、 01_data_processing.ipynb ノートブックを選択します。カーネルスイッチャープロンプトが表示されます。この例では PyTorch を使用しているので、事前に構築された PyTorch 1.10 Python 3.8 GPU 最適化イメージを選択してノートブックを開始します。アプリが起動しているのがわかり、カーネルが準備できたら、ノートブックの右上にインスタンスタイプとカーネルが表示されます。 ノートブックには追加の依存関係が必要です。このリポジトリは、追加の依存関係が記載された requirements.txt を提供しています。必要な依存関係をインストールするには、最初のセルを実行します： %pip install -r requirements.txt PyTorch アプリを起動するたびに自動的にパッケージをインストールするためのライフサイクル設定も作成することができます。詳しい手順やサンプル実装については、「 Customize Amazon SageMaker Studio using Lifecycle Configurations（ライフサイクル設定を使用した Amazon SageMaker Studio のカスタマイズ） 」を参照してください。 SageMaker Studio で Weights &amp; Biases を使用する Weights &amp; Biases (wandb) は標準の Python ライブラリです。インストールされると、トレーニングスクリプトに数行のコードを追加するだけで、実験の記録が準備できます。私たちは既に requirements.txt ファイルを通じてインストールしています。以下のコードで手動でインストールすることもできます： ! pip install wandb ケーススタディ: 自動運転車両のセマンティックセグメンテーション データセット この例では、 ケンブリッジ-ドライビングラベル付きビデオデータベース （CamVid）を使用します。これには、オブジェクトクラスのセマンティックラベルが付いたビデオコレクションが含まれており、メタデータが完備されています。このデータベースは、各ピクセルを32のセマンティッククラスのいずれかに関連付ける Ground truth のラベルを提供します。私たちは、データセットを wandb.Artifact としてバージョン管理することができ、後でそれを参照することができます。以下のコードを参照してください： with wandb.init(project="sagemaker_camvid_demo", job_type="upload"): artifact = wandb.Artifact( name='camvid-dataset', type='dataset', metadata={ "url": 'https://s3.amazonaws.com/fast-ai-imagelocal/camvid.tgz', "class_labels": class_labels }, description="The Cambridge-driving Labeled Video Database (CamVid) is the first collection of videos with object class semantic labels, complete with metadata. The database provides ground truth labels that associate each pixel with one of 32 semantic classes." ) artifact.add_dir(path) wandb.log_artifact(artifact) 01_data_processing.ipynb ノートブックに沿って進めることができます。 また、データセットの テーブル もログに記録します。テーブルはリッチでパワフルな DataFrame のようなエンティティで、タブラー形式のデータをクエリしたり分析したりすることができます。データセットを理解し、モデルの予測を視覚化し、セントラルダッシュボードで洞察を共有することができます。 Weights &amp; Biases テーブルは、画像、オーディオ、波形などの多くのリッチメディアフォーマットをサポートしています。メディアフォーマットの完全なリストについては、 データタイプ を参照してください。 次のスクリーンショットは、グラウンドトゥルースセグメンテーションを持つ生の画像のテーブルを示しています。また、この テーブルのインタラクティブバージョン も表示することができます。 モデルのトレーニング 現在、私たちはモデルを作成し、データセットでトレーニングすることができます。 PyTorch と fastai を使用してベースラインを迅速にプロトタイピングし、その後 wandb.Sweeps を使用してハイパーパラメータを最適化します。 02_semantic_segmentation.ipynb ノートブックに沿って進めてください。ノートブックを開く際にカーネルを求められたら、最初のノートブックと同じカーネル、 PyTorch 1.10 Python 3.8 GPU 最適化 を選択してください。同じアプリを使用しているため、パッケージは既にインストールされています。 このモデルは、自律エージェントの視点から撮影されたシーンのピクセルごとのアノテーションを学ぶことを目的としています。モデルは、道路、歩行者、歩道、車など、指定されたシーンの各ピクセルを32の関連カテゴリに分類またはセグメント化する必要があります。テーブル上のセグメント化された画像のいずれかを選択し、セグメンテーション結果とカテゴリにアクセスするためのインタラクティブなインターフェースを利用できます。 fastai ライブラリは wandb との統合がありますので、Learner に WandbCallback を簡単に渡すことができます: from fastai.callback.wandb import WandbCallback loss_func=FocalLossFlat(axis=1) model = SegmentationModel(backbone, hidden_dim, num_classes=num_classes) wandb_callback = WandbCallback(log_preds=True) learner = Learner( data_loader, model, loss_func=loss_func, metrics=metrics, cbs=[wandb_callback], ) learn.fit_one_cycle(TRAIN_EPOCHS, LEARNING_RATE) 基本実験のために、私たちは UNet ペーパーに触発されたシンプルなアーキテクチャを timm の異なるバックボーンを用いて使用することにしました。私たちは Focal Loss を基準としてモデルを訓練しました。Weights &amp; Biases を使用すると、実験の概要を簡単に作成し、以下のスクリーンショットに示されるように訓練結果を迅速に分析することができます。この ダッシュボードはインタラクティブにも閲覧可能 です。 スイープによるハイパーパラメータ探索 ベースのモデルのパフォーマンスを向上させるためには、最適なモデルとハイパーパラメータのセットを選択してトレーニングする必要があります。W&amp;B を使用すると、このプロセスが容易になります。W&amp;B は スウィープ を使って、これを簡単に行うことができます。 バリデーションデータセット上でモデルのフォアグラウンド精度を最大化することを目的とした ベイズ型ハイパーパラメータ検索 を実行します。スウィープを実行するために、設定ファイル sweep.yaml を定義します。このファイル内で、使用する希望の方法を指定します: bayes と、検索するパラメータとそれらの対応する値。私たちの場合は、異なるバックボーン、バッチサイズ、損失関数を試します。また、学習率や重み減衰のような最適化パラメータも探索します。これらは連続値なので、分布からサンプリングします。 スウィープには複数の設定オプション が用意されています。 program: train.py project: sagemaker_camvid_demo method: bayes metric: name: foreground_acc goal: maximize early_terminate: type: hyperband min_iter: 5 parameters: backbone: values: ["mobilenetv2_100","mobilenetv3_small_050","mobilenetv3_large_100","resnet18","resnet34","resnet50","vgg19"] batch_size: values: [8, 16] image_resize_factor: value: 4 loss_function: values: ["categorical_cross_entropy", "focal", "dice"] learning_rate: distribution: uniform min: 1e-5 max: 1e-2 weight_decay: distribution: uniform min: 0.0 max: 0.05 その後、ターミナルで、 wandb コマンドライン を使用してスイープを起動します： $ wandb sweep sweep.yaml —-project="sagemaker_camvid_demo" そして、以下のコードでこのマシン上でスイープエージェントを起動します： $ wandb agent &lt;sweep_id&gt; スイープが終了したら、パラレルコーディネートプロットを使用して、さまざまなバックボーンを持つモデルのパフォーマンスや異なるハイパーパラメータセットを探索できます。それに基づいて、どのモデルが最も良いパフォーマンスを示すかを確認できます。 次のスクリーンショットは、スイープの結果を示しており、パラレルコーディネートチャートやパラメータ相関チャートが含まれています。また、 このスイープダッシュボードを対話的 に表示することもできます。 このスイープから次のキーインサイトを導き出すことができます： 低い学習率と低い Weight Decay は、より良いフォアグラウンド精度とダイススコアを生み出す結果となります。 バッチサイズは、メトリックと強い正の相関を持っています。 VGG ベースのバックボーン は、 消失勾配を 引き起こしやすいため、最終モデルのトレーニングには適していないかもしれません。（損失が発散したため除外されました。） ResNet バックボーンは、メトリックに関して最も優れた全体的なパフォーマンスを示します。 最終的なモデルには、メトリックの面で強力なパフォーマンスを示す ResNet34 または ResNet50 バックボーンを選択するべきです。 データとモデルリネージ W&amp;B アーティファクトは、データセットとモデルをバージョン管理することを容易にするために設計されました。ファイルを W&amp;B で保存するか、既にバケットを持っていて W&amp;B に追跡させたいかに関わらず、これらの機能は有用です。データセットやモデルファイルを追跡した後、W&amp;B は自動的に各変更をログに記録し、ファイルの完全で監査可能な変更履歴を提供します。 この場合、データセット、モデル、トレーニング中に生成される異なるテーブルがワークスペースにログされます。 Artifacts ページにアクセスすることで、この系譜を迅速に閲覧し、視覚化することができます。 モデル予測の解釈 Weight &amp; Biases は、 wandb.Tables の力を使ってモデルのパフォーマンスを評価する際に特に有用です。これにより、モデルが不十分に機能している箇所を視覚化できます。この場合、自転車や歩行者のような脆弱なユーザーを正確に検出することができます。 予測されたマスクとクラスごとのダイススコア係数をテーブルに記録しました。その後、目的のクラスを含む行でフィルタリングし、ダイススコアの昇順で並べ替えました。 以下のテーブルでは、まずダイススコアが正（歩行者が画像に存在）である場所を選択してフィルタリングします。次に昇順に並べ替えて、最も検出が悪い歩行者を特定します。ダイススコアが1に等しい場合は、歩行者クラスが正しくセグメント化されていることを意味します。この テーブルを対話型で見る こともできます。 私たちは、自転車や信号機など他の脆弱なクラスに対しても、この分析を繰り返すことができます。 この機能は、正しくラベル付けされていない画像を識別し、再注釈をつけるためにタグ付けする非常に良い方法です。 結論 もっと詳しく知りたい方は、ライブ W&amp;B レポート にアクセスしてください。Weights &amp; Biases を無料で試すには、Weights &amp; Biases にサインアップするか、W&amp;B の AWS マーケットプレイス リスティングを訪問してください。 この投稿では、Weights &amp; Biases（W&amp;B）MLOps プラットフォームの紹介、SageMaker Studio での W&amp;B のセットアップ方法、および共同ソリューションでの初心者向けノートブックの実行方法を紹介しました。次に、自動運転車のセマンティックセグメンテーションのユースケースを実行し、W&amp;B の実験でトレーニングの実行結果を追跡し、W&amp;B スイープを使用したハイパーパラメータ最適化、および W&amp;B テーブルでの結果の解釈を示しました。 もっと学びたい方は、ライブの W&amp;Bレポート にアクセスできます。Weights &amp; Biases を無料で試すには、 Weights &amp; Biases にサインアップするか、 W&amp;B の AWS マーケットプレイスリスティング を訪問してください。 このブログはシニアソリューションアーキテクトの渡邊翼が翻訳を担当しました。 About the Authors Thomas Capelle は Weights and Biases で働くマシンラーニングエンジニアです。彼は www.github.com/wandb/examples リポジトリを最新の状態に保つことを担当しています。また、MLOPS、W&amp;B の産業への応用、一般的な面白いディープラーニングに関するコンテンツを構築しています。以前は、太陽エネルギーの短期予測問題をディープラーニングで解決していました。彼は都市計画、組み合わせ最適化、交通経済学、応用数学のバックグラウンドを持っています。 Durga Sury &nbsp;は、Amazon SageMaker サービス SA チームの ML ソリューションアーキテクトです。彼女はマシンラーニングを誰もが使えるようにすることに情熱を持っています。AWS での3年間で、彼女はエンタープライズ顧客のために AI/ML プラットフォームのセットアップを支援してきました。仕事以外の時は、オートバイでのライド、ミステリー小説、そして4歳のハスキーとのハイキングを楽しんでいます。 Karthik Bharathy は Amazon SageMaker のプロダクトリーダーで、10年以上のプロダクトマネジメント、プロダクト戦略、実行、およびローンチの経験を持っています。

AWS を活用したデータレイクは、きわめて高い可用性を誇る Amazon Simple Storage Service(Amazon S3) を土台としており、多様なデータとアナリティクスのアプローチを組み合わせるのに必要なスケール、敏捷性、柔軟性を提供することができます。データレイクがサイズと利用法の両面で成熟してくるにつれ、データをビジネスイベントに合わせて一貫性を保つのにかなりの労力が費やされることがあります。ファイルがトランザクションと一貫性を保って更新されることを確実にするために、 Apache Iceberg 、 Apache Hudi 、 Linux Foundation Delta Lake などのオープンソースのトランザクション処理可能なテーブルフォーマット (Open Table Format – OTF) を利用する顧客が増えています。これらのフォーマットは高い圧縮率でデータを保存し、アプリケーションやフレームワークと連携し、Amazon S3 上に構築されたデータレイクでの差分（増分）データ処理を簡素化します。これらのフォーマットにより、 ACID (原子性、一貫性、分離性、持続性)トランザクション、アップサート、削除、タイムトラベルやスナップショットなどの高度な機能が可能になります。これらの機能は以前はデータウェアハウスでのみ利用できたものです。各テーブルフォーマットはこの機能を少しずつ異なる方法で実装しています。比較のためには、 AWS 上のトランザクショナルデータレイクのためのオープンテーブルフォーマットの選択 （英文）を参照してください。 2023年に、AWS は Amazon Athena for Apache Spark において、Apache Iceberg、Apache Hudi、Linux Foundation Delta Lake サポートの一般提供開始を 発表 しました。これにより、個別のコネクタや関連する依存関係をインストールしてパッケージ管理する必要がなくなり、これらのフレームワークを使用するために必要な設定手順が簡素化されます。 この投稿では、 Amazon Athena ノートブックで Spark SQL を使用する方法と、Iceberg、Hudi、Delta Lake テーブルフォーマットを操作する方法を示します。 Athena の Spark SQL を使用した、データベースとテーブルの作成、テーブルへのデータの挿入、データのクエリ、Amazon S3 のテーブルスナップショットの確認など、一般的な操作をデモンストレーションします。 前提条件 次の前提条件を完了してください: 「 Amazon Athena Spark で Spark SQL を実行する 」（英文）に記載されているすべての前提条件を満たしていることを確認してください。 「 Amazon Athena Spark で Spark SQL を実行する 」で詳述されているように、AWS Glue Data Catalog に sparkblogdb というデータベースと noaa_pq というテーブルを作成してください。 Athena ワークグループで使用される AWS Identity and Access Management (IAM) ロールに、S3 バケットとプレフィックスへの読み書きアクセス許可を付与してください。 詳細については、 Amazon S3: Allows read and write access to objects in an S3 Bucket を参照してください。 クリーンアップを実行するために、Athena ワークグループで使用される IAM ロールに、S3 バケットとプレフィックスへの s3:DeleteObject アクセス許可を付与してください。 詳細については、 Amazon S3 アクション の オブジェクト削除のアクセス許可 セクションを参照してください。 Amazon S3 からのサンプルノートブックのダウンロードとインポート この投稿で説明するノートブックは、次の場所からダウンロードできます。 Iceberg チュートリアルノートブック: s3://athena-examples-us-east-1/athenasparksqlblog/notebooks/SparkSQL_iceberg.ipynb Hudi チュートリアルノートブック: s3://athena-examples-us-east-1/athenasparksqlblog/notebooks/SparkSQL_hudi.ipynb Delta チュートリアルノートブック: s3://athena-examples-us-east-1/athenasparksqlblog/notebooks/SparkSQL_delta.ipynb ノートブックをダウンロードしたら、 ノートブックファイルの管理 （※注：本稿翻訳時点ではリンク先のドキュメントが未翻訳であり、英語での提供です。以下同様。）の ノートブックのインポート方法 のセクションに従って、Athena Spark 環境にインポートしてください。 Open Table Format にあわせたセクションを参照してください Iceberg テーブル形式に興味がある場合は、 Apache Iceberg テーブルの利用 セクションを参照してください。 Hudi テーブル形式に興味がある場合は、 Apache Hudi テーブルの利用 のセクションを参照してください。 Delta Lake テーブル形式に興味がある場合は、 Linux Foundation Delta Lake テーブルの利用 のセクションを参照してください。 Apache Iceberg テーブルの利用 Athena の Spark ノートブックを使用する際、PySpark のコードを使用することなく直接 SQL クエリを実行できます。 これは、セルの動作を変更するノートブックセルの特別なヘッダであるセルマジックを使用することで実現します。 SQL の場合、 %%sql マジックを追加できます。これにより、セルの内容全体が Athena 上で実行される SQL ステートメントとして解釈されます。 このセクションでは、Athena の Apache Spark SQL を使用して、Apache Iceberg テーブルを作成、分析、管理する方法を示します。 ノートブックセッションの設定 Athena で Apache Iceberg を使用するには、セッションの作成や編集中に、 Apache Spark プロパティ セクションを展開し、 Apache Iceberg オプションを選択します。 以下のスクリーンショットに示すように、プロパティが事前に設定されます。 ステップの詳細は、 セッションの詳細を編集する または 独自のノートブックを作成する をご覧ください。 このセクションで使用されているコードは、 SparkSQL_iceberg.ipynb ファイルで参照できます。 データベースとIcebergテーブルの作成 まず、AWS Glue データカタログにデータベースを作成します。 次の SQL を使用すると、 icebergdb というデータベースを作成できます。 %%sql CREATE DATABASE icebergdb 次に、データベース icebergdb で、データのロード先になる Amazon S3 の場所を指す noaa_iceberg という Iceberg テーブルを作成します。次のステートメントを実行し、ロケーション s3://&lt;your-S3-bucket&gt;/&lt;prefix&gt;/ をご自身の S3 バケットとプレフィックスに置き換えてください: %%sql CREATE TABLE icebergdb.noaa_iceberg( station string, date string, latitude string, longitude string, elevation string, name string, temp string, temp_attributes string, dewp string, dewp_attributes string, slp string, slp_attributes string, stp string, stp_attributes string, visib string, visib_attributes string, wdsp string, wdsp_attributes string, mxspd string, gust string, max string, max_attributes string, min string, min_attributes string, prcp string, prcp_attributes string, sndp string, frshtt string) USING iceberg PARTITIONED BY (year string) LOCATION 's3://&lt;your-S3-bucket&gt;/&lt;prefix&gt;/noaaiceberg/' テーブルへのデータの挿入 noaa_iceberg Iceberg テーブルにデータを入力するために、前提条件として作成された Parquet テーブル sparkblogdb.noaa_pq からデータを挿入します。 Spark の INSERT INTO ステートメントを使用してこれを行うことができます。 %%sql INSERT INTO icebergdb.noaa_iceberg select * from sparkblogdb.noaa_pq あるいは、 CREATE TABLE AS SELECT に USING iceberg 句を使用することで、 Iceberg テーブルを作成し、ソーステーブルからデータを挿入する一連のステップを一度に実行できます。 %%sql CREATE TABLE icebergdb.noaa_iceberg USING iceberg PARTITIONED BY (year) AS SELECT * FROM sparkblogdb.noaa_pq Iceberg テーブルのクエリ データが Iceberg テーブルに挿入されたので、分析を開始できます。 'SEATTLE TACOMA AIRPORT, WA US' の場所について、年ごとの最低記録気温を見つけるために、Spark SQL を実行してみましょう。 %%sql select name, year, min(MIN) as minimum_temperature from icebergdb.noaa_iceberg where name = 'SEATTLE TACOMA AIRPORT, WA US' group by 1,2 次のような出力が得られます。 Iceberg テーブル内のデータの更新 テーブル内のデータを更新する方法を見ていきましょう。 ステーション名 'SEATTLE TACOMA AIRPORT, WA US' を 'Sea-Tac' に更新したいとします。 Spark SQL を使用すると、Iceberg テーブルに対して UPDATE ステートメントを実行できます。 %%sql UPDATE icebergdb.noaa_iceberg SET name = 'Sea-Tac' WHERE name = 'SEATTLE TACOMA AIRPORT, WA US' また、前のSELECTクエリを実行して、 'Sea-Tac' ロケーションの最低記録温度を見つけることができます。 %%sql select name,&nbsp;year, min(MIN) as minimum_temperature from icebergdb.noaa_iceberg where name = 'Sea-Tac' group by 1,2 次のような出力が得られます。 データファイルの圧縮 Icebergのような Open Table Format における更新処理では、ファイルストレージ内の更新差分を作成し、マニフェストファイルを通じて行のバージョンをトラッキングすることでその機能を実現しています。 ファイル数が多くなるとマニフェストファイルに格納されるメタデータの量が多くなりますし、小さいデータが大量にあると不必要にメタデータを多くしがちで、これによりクエリ効率の低下と Amazon S3 アクセスコストの上昇を招きます。 Athena (for Spark) で Iceberg の rewrite_data_files プロシージャを実行すると、データファイルが圧縮され、多数の小さな差分ファイルが、読み取りに最適化された少数の Parquet ファイルにまとめられます。 ファイルの圧縮により読み取り操作が高速化されます。 テーブルの圧縮を実行するには、次の Spark SQL を実行します。 %%sql CALL spark_catalog.system.rewrite_data_files (table =&gt; 'icebergdb.noaa_iceberg', strategy=&gt;'sort', sort_order =&gt; 'zorder(name)') rewrite_data_files には ソート戦略を指定するオプションがあり、これによりデータの再編成と圧縮を適切に指定することができます。 テーブルスナップショットのリスト表示 Iceberg テーブル上の各書き込み、更新、削除、アップサート、圧縮操作は、スナップショット分離とタイムトラベルを実現するため、古いデータとメタデータを保持しつつ、テーブルの新しいスナップショットを作成します。Iceberg テーブルのスナップショット一覧を得るには、次の Spark SQL ステートメントを実行します。 %%sql SELECT&nbsp;* FROM spark_catalog.icebergdb.noaa_iceberg.snapshots 古いスナップショットの期限切れ 不要になったデータファイルを削除し、テーブルメタデータのサイズを小さく保つために、期限を指定したスナップショットの定期的な削除が推奨されます。期限切れではないスナップショットでまだ必要とされているファイルは削除されません。Athena for Spark では、次の SQL を実行して、特定のタイムスタンプよりも古い icebergdb.noaa_iceberg テーブルのスナップショットの期限切れを設定できます。 %%sql CALL spark_catalog.system.expire_snapshots ('icebergdb.noaa_iceberg', TIMESTAMP '2023-11-30 00:00:00.000') timestamp の値は yyyy-MM-dd HH:mm:ss.fff の形式の文字列で指定されていることに注意してください。 出力は削除されたデータファイルとメタデータファイルの数をカウントしたものになります。 テーブルとデータベースの削除 この演習で使用したIcebergテーブルとAmazon S3の関連データをクリーンアップするには、次のSpark SQLを実行できます。 %%sql DROP TABLE icebergdb.noaa_iceberg PURGE 次の Spark SQL を実行して、icebergdb データベースを削除します。 %%sql DROP DATABASE icebergdb Athena で Spark を使用して Iceberg テーブルで実行できるすべての操作の詳細については、Iceberg ドキュメントの Spark クエリ と Spark プロシージャ を参照してください。 Apache Hudi テーブルの利用 次に、Athena の Spark SQL を使用して、Apache Hudi テーブルを作成、分析、管理する方法を示します。 ノートブックセッションの設定 Athena で Apache Hudi を使用するには、セッションの作成または編集中に、 Apache Spark プロパティ セクションを展開し、 Apache Hudi オプションを選択します。 ステップの詳細は、 セッションの詳細を編集する または 独自のノートブックを作成する をご覧ください。 このセクションで使用されているコードは、 SparkSQL_hudi.ipynb ファイルで利用できます。以下のステップを確認するためにご利用ください。 データベースとHudiテーブルの作成 まず、AWS Glue データカタログに格納される hudidb というデータベースを作成します。この次に Hudi テーブルを作成します。 %%sql CREATE DATABASE hudidb Amazon S3 のデータをロードする場所を指す Hudi テーブルを作成します。 このテーブルは、 コピーオンライト 型であることに注意してください。 これはテーブル DDL の type='cow' によって定義されています。 stationとdate を複合プライマリキー、preCombinedFieldをyearとして定義しました。 また、テーブルは year でパーティション化されています。 次のステートメントを実行し、ロケーション s3://&lt;your-S3-bucket&gt;/&lt;prefix&gt;/ をご自身の S3 バケットとプレフィックスに置き換えてください: %%sql CREATE TABLE hudidb.noaa_hudi( station string, date string, latitude string, longitude string, elevation string, name string, temp string, temp_attributes string, dewp string, dewp_attributes string, slp string, slp_attributes string, stp string, stp_attributes string, visib string, visib_attributes string, wdsp string, wdsp_attributes string, mxspd string, gust string, max string, max_attributes string, min string, min_attributes string, prcp string, prcp_attributes string, sndp string, frshtt string, year string) USING HUDI PARTITIONED BY (year) TBLPROPERTIES( primaryKey = 'station, date', preCombineField = 'year', type = 'cow' ) LOCATION ''s3://&lt;your-S3-bucket&gt;/&lt;prefix&gt;/noaahudi/' テーブルへのデータの挿入 Iceberg と同様に、前のステップで作成した sparkblogdb.noaa_pq テーブルからデータを読み取ることによってテーブルにデータを入力するために、 INSERT INTO ステートメントを使用します。 %%sql INSERT INTO hudidb.noaa_hudi select * from sparkblogdb.noaa_pq Hudi テーブルのクエリ テーブルが作成されたので、 'SEATTLE TACOMA AIRPORT, WA US' ロケーションにおける最高気温を検索するクエリを実行してみましょう。 %%sql select name, year,&nbsp;max(MAX) as maximum_temperature from&nbsp;hudidb.noaa_hudi where name = 'SEATTLE TACOMA AIRPORT, WA US' group by 1,2 Hudi テーブル内のデータの更新 ステーション名(name)を 'SEATTLE TACOMA AIRPORT, WA US' から 'Sea–Tac' に変更しましょう。 Athena for Spark で アップデート ステートメントを実行することで、 noaa_hudi テーブルのレコードを更新できます。 %%sql UPDATE hudidb.noaa_hudi SET name = 'Sea-Tac' WHERE name = 'SEATTLE TACOMA AIRPORT, WA US' 「Sea-Tac」ロケーションで記録された最高気温を検索するために、前のSELECTの条件句を’Sea-Tac’に変えて実行します。 %%sql select name,&nbsp;year,&nbsp;max(MAX) as&nbsp;maximum_temperature from&nbsp;hudidb.noaa_hudi where name = 'Sea-Tac' group by 1,2 タイムトラベルクエリ SQL でタイムトラベルクエリを使用することで、過去のデータスナップショットを分析できます。例: %%sql select name, year, max(MAX) as maximum_temperature from hudidb.noaa_hudi timestamp as of '2023-12-01 23:53:43.100' where name = 'SEATTLE TACOMA AIRPORT, WA US' group by 1,2 このクエリは、過去の特定の時点でのシアトル空港の気温データをチェックします。 timestamp 句を使うことで、現在のデータを変更することなく過去に戻ることができます。 timestamp の値は yyyy-MM-dd HH:mm:ss.fff のフォーマットの文字列で指定されていることに注意してください。 クラスタリングによるクエリ速度の最適化 Athena でのクエリパフォーマンスを改善するために、Spark SQL を使用して Hudi テーブルで クラスタリング を実行できます。 %%sql CALL run_clustering(table =&gt; 'hudidb.noaa_hudi', order =&gt; 'name') テーブルのコンパクション(compaction) コンパクションはHudiに特有の Merge On Read (MOR) テーブルで採用されているテーブルサービスで、行ベースのログファイルからの更新を定期的に対応する列ベースのベースファイルにマージすることで、ベースファイルの新しいバージョンを生成します。コンパクションは Copy On Write (COW) テーブルには適用されず、 MOR テーブルにのみ適用されます。 Athena for Spark を使用して MOR テーブルのコンパクションを実行するには、次のクエリを実行できます。 %%sql CALL run_compaction(op =&gt; 'run', table =&gt; 'hudi_table_mor'); テーブルとデータベースの削除 以下の Spark SQL を実行して、作成した Hudi テーブルと、Amazon S3 の場所に関連付けられたデータを削除してください: %%sql DROP TABLE hudidb.noaa_hudi PURGE 次の Spark SQL を実行して、データベース hudidb を削除します。 %%sql DROP DATABASE hudidb Athena で Spark を使用して Hudi テーブルで実行できるすべての操作については、Hudi ドキュメントの SQL DDL と Procedures を参照してください。 Linux Foundation Delta Lake テーブルの利用 次に、Athena の Spark SQL を使用して Delta Lake テーブルを作成、分析、管理する方法を示します。 ノートブックセッションの設定 Athena で Spark を使用して Delta Lake を利用するには、セッションの作成または編集中に、 Apache Spark プロパティ セクションを展開し、 Linux Foundation Delta Lake を選択します。 ステップの詳細は、 セッションの詳細を編集する または 独自のノートブックを作成する をご覧ください。 このセクションで使用されているコードは、 SparkSQL_delta.ipynb ファイルで利用できます。ためにご利用ください。 データベースとDelta Lakeテーブルの作成 このセクションでは、AWS Glue データカタログにデータベースを作成します。 次の SQL を使用すると、 deltalakedb というデータベースを作成できます。 %%sql CREATE DATABASE&nbsp;deltalakedb 次に、データベース deltalakedb で、データをロードする Amazon S3 の場所を指す noaa_delta という Delta Lake テーブルを作成します。次のステートメントを実行し、ロケーション s3://&lt;your-S3-bucket&gt;/&lt;prefix&gt;/ をご自身の S3 バケットとプレフィックスに置き換えてください: %%sql CREATE TABLE deltalakedb.noaa_delta( station string, date string, latitude string, longitude string, elevation string, name string, temp string, temp_attributes string, dewp string, dewp_attributes string, slp string, slp_attributes string, stp string, stp_attributes string, visib string, visib_attributes string, wdsp string, wdsp_attributes string, mxspd string, gust string, max string, max_attributes string, min string, min_attributes string, prcp string, prcp_attributes string, sndp string, frshtt string) USING delta PARTITIONED BY (year string) LOCATION 's3://&lt;your-S3-bucket&gt;/&lt;prefix&gt;/noaadelta/' テーブルへのデータの挿入 前の投稿で作成した sparkblogdb.noaa_pq テーブルからデータを読み取ることにより、テーブルに入力するために INSERT INTO ステートメントを使用します。 %%sql INSERT INTO deltalakedb.noaa_delta&nbsp;select * from sparkblogdb.noaa_pq CREATE TABLE AS SELECT を使用して、1 つのクエリで Delta Lake テーブルを作成し、ソーステーブルからデータを挿入することもできます。 Delta Lake テーブルのクエリ Delta Lake テーブルにデータが挿入されたので、分析を開始することができます。 'SEATTLE TACOMA AIRPORT, WA US' ロケーションの最低記録温度を見つけるために、Spark SQL を実行しましょう。 %%sql select name, year, max(MAX) as minimum_temperature from deltalakedb.noaa_delta where name = 'SEATTLE TACOMA AIRPORT, WA US' group by 1,2 Deltaレイクテーブル内のデータの更新 ステーション名を 'SEATTLE TACOMA AIRPORT, WA US' から 'Sea–Tac' に変更しましょう。 Athena の Spark 上で noaa_delta テーブルのレコードを更新する UPDATE ステートメントを実行できます。 %%sql UPDATE deltalakedb.noaa_delta SET name = 'Sea-Tac' WHERE name = 'SEATTLE TACOMA AIRPORT, WA US' 前のSELECTクエリを実行して、 'Sea-Tac' ロケーションの最低記録温度を検索できます。結果は以前と同じはずです。 %%sql select name, year, max(MAX) as minimum_temperature from deltalakedb.noaa_delta where name = 'Sea-Tac' group by 1,2 データファイルの圧縮 (optimize) Athena for Spark では、Delta Lake テーブルに対して OPTIMIZE を実行できます。これにより、複数の小さいファイルが大きなファイルに圧縮されるため、小さいファイルがたくさんあることによるクエリへの負担を減らすことができます。圧縮を実行するには、次のクエリを実行します。 %%sql OPTIMIZE deltalakedb.noaa_delta Delta Lake のドキュメントの 最適化 を参照して、OPTIMIZE の実行中に使用できるさまざまなオプションを確認してください。 Delta Lake テーブルで参照されなくなったファイルの削除 Athena の Spark を使用して Delta Lake テーブル上で VACUUM コマンドを実行することで、そのテーブルから参照されなくなった Amazon S3 に保存されたファイルで、保持期間を超えたものを削除できます。 %%sql VACUUM&nbsp;deltalakedb.noaa_delta Delta Lake のドキュメントの Delta テーブルで参照されなくなったファイルの削除 を参照して、VACUUM で利用できるオプションを確認してください。 テーブルとデータベースの削除 次の Spark SQL を実行して、作成した Delta Lake テーブルを削除します。 %%sql DROP TABLE&nbsp;deltalakedb.noaa_delta 次の Spark SQL を実行して、データベース deltalakedb を削除します。 %%sql DROP DATABASE&nbsp;deltalakedb Delta Lake テーブルとデータベースで DROP TABLE DDL を実行すると、これらのオブジェクトのメタデータが削除されますが、Amazon S3 のデータファイルは自動的には削除されません。 ノートブックのセルで次の Python コードを実行することで、S3 バケットからデータを削除できます。 import boto3 s3 = boto3.resource('s3') bucket = s3.Bucket('') bucket.objects.filter(Prefix="/noaadelta/").delete() Athena の Spark を使用して Delta Lake テーブルで実行できる SQL ステートメントの詳細については、Delta Lake ドキュメントの クイックスタート を参照してください。 まとめ この投稿では、Athena ノートブックで Spark SQL を使用してデータベースとテーブルを作成し、データを挿入およびクエリを実行し、Hudi、Delta Lake、Iceberg テーブルでの更新、圧縮、タイムトラベルなどの一般的な操作を実行する方法を示しました。 Open Table Format (OTF) は、 ACID トランザクション、アップサート、削除といった操作をデータレイク上で可能にし、オブジェクトストレージ上でのより高度な操作を提供します。 Athena for Spark では、別途コネクタをインストールする必要がないので、Amazon S3 上に信頼できるデータレイクを構築す際のこれらの一般的な準備や管理のオーバーヘッドを削減することができます。 データレイク上の処理における Open Table Format の選択の詳細については、 AWS でのトランザクションデータレイクのためのオープンテーブルフォーマットの選択 を参照してください。 著者について Pathik Shah は、Amazon Athena のシニアアナリティクスアーキテクトです。2015年にAWSに加入して以来、ビッグデータアナリティクスの分野に注力し、AWSのアナリティクスサービスを使用してスケーラブルで堅牢なソリューションの構築を支援しています。 Raj Devnath は、Amazon Athena のプロダクトマネージャーです。お客様に愛される製品の構築と、お客様のデータから価値を引き出すことに情熱を注いでいます。金融、小売、スマートビル、家庭オートメーション、データ通信システムなど、複数のエンドマーケット向けのソリューションの提供経験があります。 翻訳：ソリューションアーキテクト 下佐粉 昭 ( twitter – @simosako) 原文： Use Amazon Athena with Spark SQL for your open-source transactional table formats

Amzon Bedrock や ChatGPT のように API 経由で呼び出せる基盤モデルの精度とコストは実用的なレベルに到達しています。一方で、皆さんが開発している製品やサービス、プロダクトには様々なデータが蓄積されていると思います。そのデータで機械学習モデルを学習できれば、より顧客のニーズに合った体験を提供できます。体験が改善されればより多く顧客が集まり、そこから得られるデータはさらなるモデルの改善につながります。 API で利用できるモデルは追加学習なしに高い精度で推論できるものの、最初から顧客が満足するレベルの精度が出せるとは限りません。例えばカスタマーサポートの応対で使う場合、顧客の言葉の意味を取り違えたり、応対マニュアルと異なる対応や回答を伝えてしまう可能性があります。蓄積されたデータから不適切な回答を抜き出し、分析結果をもとに基盤モデルへの指示方法 ( プロンプト ) やモデル自体を調整できれば、より顧客のニーズに沿った体験を提供できます。 本文書では、 蓄積したデータによる精度改善を視野に入れた場合、 API と OSS のどちらがコスト効率が良くなるのか を検証します。 OSS とは、 Hugging Face などで公開されている基盤モデルをカスタマイズし、ホスティングする利用形態を想定しています。学習なしの推論で OSS のモデルが API 経由で利用できるモデルに並ぶのは現時点で難しいですが、学習データがあるなら話は変わってきます。 API の場合はプロンプトの修正 (Prompt Engineering) が精度改善の主な手段ですが、 OSS ではモデルの追加学習 (Fine Tuning: 本記事では Instruction Tuning を指します ) も選択肢になります。最近では対話形式に沿うよう学習 (Instruction Tuning) されたモデルが次々と公開されているため、 素の基盤モデルを用いた前回の検証 よりも少ないデータ量で API に並ぶ精度が得られると期待されます。 実験では、API として Amazon Bedrock で利用できる Claude と Claude Instant の 2 つ、OSS として open-calm-1b 、 japanese-gpt-neox-3.6b-instruction-ppo 、 bilingual-gpt-neox-4b-instruction-ppo 、 ELYZA-japanese-Llama-2-7b-instruct 、 Swallow-13b-instruct-hf の 5 つを使用しました。 1b 、 3b 、 7b 、10b クラスのモデルを取りそろえた形です。 モデル名 公開元 種別 概要 Claude v2.1 Anthropic API Anthropic の提供する高性能な基盤モデル。 Hugging Face の Leaderboard では GPT-4 などに次ぐ精度。日本語性能でも、 Rakuda Ranking などでトップレベルの性能を示す。 20 万トークンという長大なテキストを扱える。 Claude Instant Anthropic API 高速な応答に重点を置いたモデル。 10 万トークンという長大なテキストを扱える。 open-calm-1b CyberAgent OSS 株式会社サイバーエージェントから公開された GPT-NeoX ベースの日本語大規模言語モデル。 japanese-gpt-neox-3.6b-instruction-ppo rinna OSS rinna 株式会社から公開された日本語で学習された GPT-NeoX ベースの大規模言語モデル。対話形式のデータで教師あり学習、強化学習が行われた日本語大規模言語モデル。 bilingual-gpt-neox-4b-instruction-ppo rinna OSS rinna 株式会社から公開された日英両言語で学習された GPT-NeoX ベースの大規模言語モデル。対話形式のデータで教師あり学習、強化学習を行っている。 ELYZA-japanese-Llama-2-7b-instruct ELYZA OSS 株式会社 ELYZA から公開された、 Meta の Llama2 をもとに日本語コーパスで継続学習した大規模言語モデル。独自データでの教師あり学習を行っている。 Swallow-13b-instruct-hf 東工大 / 産総研 OSS 東工大と産総研の研究チームから公開された、Meta の Llama2 をもとに日本語コーパスで継続学習した大規模言語モデル。 Claude 2.1 は GPT-4 、 Claude Instant は ChatGPT 3.5 に近しい精度なので値は読み替えていただけると思います。評価用のデータセットは幅広な選択肢がありますが、今回は JGLUE の中でも質問回答のデータセットである JSQuAD を使用しました。 JSQuAD には、 Wikipedia の文書とそれに関する質問、質問に対する回答箇所が収録されています。近年、検索と生成を組み合わせた RAG (Retrieval Augmented Generation) と呼ばれる手法が注目されていますが、検索結果から要求に応じた情報を抽出するタスクは JSQuAD の形式に近く、 RAG で使用するモデルを選ぶ際の参考指標となり得ると考えたためです。 本記事では、気になる実験結果を先に提示し、のちのセクションで実験の内容について詳細に解説します。 API と OSS のコスト効率の比較結果 コスト効率とは、精度とコストの比率を指します。精度、コストの比較結果を示し最後にコスト効率について示します。 精度は次の図の結果となりました。縦軸は F1 という実際の回答と出力された回答がどれだけオーバーラップしているかを表す指標 ( 後述します ) 、横軸は使用した JSQuAD の学習データの件数です。API である Claude についてはプロンプトに含めた例示 ( データ ) の数、 OSS については追加学習に使用したデータの件数を示します。 API か OSS かで「データ件数」の意味が異なる点、また件数が対数軸になっている点にはご注意ください。追加学習には LoRA の手法を用い、ハイパーパラメーターやエポック数などの設定は各データ件数でそろえていますが、規定時間以内に終わらなかった学習は途中で打ち切っています。 この結果からは、次の 5 つの示唆が得られます (Claude をハイエンドのモデル、 Claude Instant を軽量なモデルと表現しています )。なお、得られる示唆は質問回答タスクに限定される点に注意してください。 1) 10B クラスの日本語 OSS モデルは、ハイエンドの API モデルを利用する場合の精度に匹敵する。 2) 7B クラスの日本語 OSS モデルでも、 30 件以上のデータがあれば追加学習で軽量な API モデルの精度に匹敵する。 3) 7B クラスの日本語 OSS モデルでも、 500 件以上のデータがあれば追加学習でハイエンドの API モデルの精度に匹敵する。 4) 4B 以下のモデルは追加学習しても API 経由のモデルの精度に至らず、また過学習により精度が下がる可能性がある。 5) プロンプトの例示は 2 件あれば十分効果が得られる。 続いて、コストを示します。縦軸は金額 ($) 、横軸はデータ件数です。金額は OSS の場合学習にかかった費用と検証データセットの推論にかかった費用の合計、 API の場合推論にかかった費用のみになります。 API では、ハイエンドのモデルは性能が高い分、やはり費用がかかることがわかります。 OSS では、おおむね 4000 件を超えたあたりから学習コストに対し得られる性能が割に合わなくなることが読み取れます ( 4B の rinna のモデルで少し跳ねがありますが、全体の傾向に影響ないと見ています ) 。先ほどの例から、十分な精度が得られるのは 500 件程度のため、あまり大量の学習データを用意するのは経済的ではないと言えそうです。 最後に、コスト効率の目安として F1 の値を学習コストで割った値をプロットした図を示します。 $1 の学習コストを払うことでどれくらい精度である F1 が向上するか、つまりコスト効率を示す指標になります。 7B のモデルである ELYZA が 32 件の時に突出しており、以後基本的には下がることがわかります。 1B の OpenCALM や 4B の rinna は初期コスト効率が低いものの 500 件近辺で持ち直し、以後は他のモデル含め下降傾向を示しています。そのため、まず 30 件以上、 500 件までは十分な費用対効果が期待できると言えると思います。この知見は、モデルにとって適切なプロンプトを探索したい場合どの程度データ件数をそれぞれ用意すればよいのかの疑問にも示唆を与える結果です。 質問回答タスクに基づく検証から、 API と OSS の使い分けは以下のようにするとよいのではないかという示唆が得られます。なお、文中では冗長性を省くため断定的に書いていますが、あくまで質問回答データセットを用いた本実験から得られる示唆と認識ください 。 API 経由で利用し精度に課題がある場合、 2 つ程度プロンプトに例示入れることで確かな精度の向上を確認できる。 Claude Instant 、あるいは ChatGPT 3.5 相当の精度は 7B クラスのモデルを 30 件以上のデータで追加学習することで到達できる。精度が十分であり、安定性や速度の課題がホスティング費用に勝るなら切り替える価値がある。 Claude 2.1 、あるいは GPT-4 相当の精度が必要な場合、 1) 10B クラスの OSS モデルを使用するか、 2) 7B クラスの OSS モデルを 500 件程度のデータで追加学習し目的の精度が得られるか検証する。精度が十分得られ、安定性や速度の課題がホスティング費用に勝るなら切り替える価値がある。 以下のセクションでは、結論に至るまでの実験設定について記載します。今後、他モデルの数、また要約や分類といった他のタスクについても検証を検討しています。 API と OSS の基盤モデル 現在、基盤モデルを利用する選択肢は大きく分けて API と OSS の 2 つがあります。 API は ChatGPT や Amazon Bedrock のように Web API 経由で基盤モデルを利用する形式です。基盤モデルをホスティングするインフラを意識することなく使うことができ、多くの場合処理したトークン数に応じて費用を支払います。 Anthropic の Claude や OpenAI の ChatGPT など、非常に性能が高いモデルを安価に利用できることが特徴です。トークン数に応じて課金されるため、詳細なプロンプトや例示を書くほどコストがかかることになります。 OSS は Hugging Face などで公開されているオープンソースのモデルを GPU インスタンス等にホスティングして利用します。推論用のコードやインフラを準備する手間があるものの、一度立ち上げてしまえば API リクエスト数や処理トークン数を意識することなく使用できます。 また、 API 提供者の設定するリクエスト制限、サービス停止などの影響を受けることもありません。 Amazon SageMaker JumpStart を使えば、モデルのホスティングもボタン操作のみで行えます。現在、 rinna と Stability AI の日本語モデルが掲載されており、今後も増える予定です。 OSS であるため、手元のデータで追加学習しカスタマイズすることもできます ( 追加学習、また追加学習後のモデルの利用と公開についてはライセンスを注意深く確認してください ) 。カスタマイズは API でもできるようになってきていますが、 Amazon Bedrock では 時間単位課金のモデルユニットが必要 であり、 ChatGPT でも カスタマイズしたモデルを使うときの料金は 3 倍近くになります (2024/1/31 時点) 。追加学習後の推論のコスト効率を考える場合、 OSS のモデルは良い選択肢になるでしょう。 評価手法 : データセット 今回は評価に JSQuAD という質問回答のデータセットを使用します。中のデータは次のような形式をしています。 SQuAD (The Stanford Question Answering Dataset) というデータセットを参考に作成されており、 Wikipedia の記事 ( context ) に対する質問 ( question ) と回答 ( answers ) が収録されています ( answers は 1 件のみです)。 SQuAD2.0 では context に答えがない場合 is_impossible : true のケースが存在しますが、 JSQuAD は SQuAD 1.1 をベースにしており答えられない質問は含まれていません。 { "title": "東海道新幹線 (Tokaido Shinkansen)", "paragraphs": [ { "qas": [ { "question": "2020年（令和2年）3月現在、東京駅 - 新大阪駅間の最高速度はどのくらいか。 (What is the maximum speed between Tokyo Station and Shin-Osaka Station as of March 2020?)", "id": "a1531320p0q0", "answers": [ { "text": "285 km/h", "answer_start": 182 } ], "is_impossible": false }, { .. } ], "context": "東海道新幹線 [SEP] 1987年（昭和62年）4月1日の国鉄分割民営化により、JR東海が運営を継承した。西日本旅客鉄道（JR西日本）が継承した山陽新幹線とは相互乗り入れが行われており、東海道新幹線区間のみで運転される列車にもJR西日本所有の車両が使用されることがある。2020年（令和2年）3月現在、東京駅 - 新大阪駅間の所要時間は最速2時間21分、最高速度285 km/hで運行されている。" } ] } 1 つの context には複数の質問があります。同じ context のデータは類似性が高いため、学習データを作る際は context が重複しないようにしています ( データ数が 15,000 件までは重複させないことができました ) 。 JSQuAD の学習データからランダムにサンプリングしデータ件数ごとの学習データを作成します。データを全く与えない場合を 0、そこから 2 、 4 、 8 、 16 ・・・と 2 の倍数刻みで 8192 件まで context の重複がないようランダムに選択したデータセットを用意しました。さらに、 15652 件 ( context 重複なしで作れる最大のデータ数 )、31005 件( context 重複を最大 2 回許可)、45576 件( context 重複を最大 3 回許可)、57086 件( context 重複を最大 4 回許可)、62859 件( context 重複が最大 5 件、 JSQuAD 内の全質問)のデータセットを用意しました。件数ごとのデータセットについて、 API はプロンプト内の例示に、 OSS ではモデルの追加学習に使用します。データが少なすぎると追加学習が困難なので、 追加学習は 8 件からスタートをしています。逆に、 API のプロンプトに入力できる事例数は 8 件を上限にしています。今回、評価データセット全件を評価するために Amazon Bedrock で Preview 中の Batch inference の機能 を使用したのですが、その容量の制限上この値に留めています。 128 件入れた研究もあり ( Cold-Start Data Selection for Few-shot Language Model Fine-tuning: A Prompt-Based Uncertainty Propagation Approach ) 、 Claude は 20 万トークンものサイズを扱えるので GA した際には推論可能な量も増えることを期待しています。 評価手法 : 精度の算出 JSQuAD の問題を基盤モデルで解き精度を計測するにはどうすればよいでしょうか ? 例えば、 Claude の場合は次のようにプロンプトを与えています。 input には context 、instruction には question が入ります。基盤モデルの回答と answers が一致するかで精度を評価します。 Human: 与えられたinputからinstructionに対する回答を抽出する関数を実行してください。 入出力のexampleを示します。 &lt;example&gt; &lt;input&gt;・・・&lt;/input&gt; &lt;instruction&gt;・・・&lt;/instruction&gt; Answer:xxxxx &lt;/example&gt; &lt;example&gt; &lt;input&gt;・・・&lt;/input&gt; &lt;instruction&gt;・・・&lt;/instruction&gt; Answer:xxxxx &lt;/example&gt; 次のinputからinstructionに対する回答を抽出してください。結果はAnswer:の後に記載し名詞以外何も含まないことを厳守してください。 &lt;input&gt;・・・&lt;/input&gt; &lt;instruction&gt;・・・&lt;/instruction&gt; Assistant:Answer: 精度は回答と完全に一致した Exact Match の数、予測の中にどれだけ回答と一致する文字が含まれるかを計測する F1 で行います。 JSQuAD の評価において、 F1 は文字単位で計算します。英語では単語単位なのですが、日本語の場合形態素解析の仕方で評価が揺らいでしまうためです 。 「 285 km/h 」が正解の場合、 “285 km/h” と完全に回答できれば Exact Match ですが “285” だと Exact Match にはなりません。 F1 の場合 “2” “8” “5” は一致していると評価されるのでより寛容な評価になります。ただ、今回評価に使用した lm-evaluation-harness では JSQuAD の評価を単語単位で計算している ので、本記事の F1 の値は本来の値とは少し異なります。上記は Claude の例を示しましたが、プロンプトの形式は各 API / OSS の形式に準じます。例えば、 Claude であれば \n\nHuman: と \n\nAssistant: の対話形式に、 OSS では例えば rinna のモデルであれば "ユーザー: " or "システム: " の形式に合わせます。 lm-evaluation-harness ではタスクの指定でプロンプトのテンプレートを切り替えることができます。例えば、 rinna 用のテンプレートは jsquad-1.1-0.4 になります。 評価手法 : コストの算出 コストはどう評価すればよいでしょうか ? 学習と推論の 2 つのコストがあります。 OSS の場合は学習と推論にかかったコスト、 API の場合は推論のみにかかったコストが計上対象となります。 OSS のモデルの学習は、 OpenCALM の検証 の時と同じ実装を使用しました。 aws-ml-jp 上のサンプルを使用することで、 Notebook を実行するのみで簡単に Hugging Face 上のモデルを LoRA 形式で追加学習できます 。テンプレートはモデルごと合ったものを使用し、 3 エポック学習を回しています。学習に使用したインスタンスは NVIDIA A10G の GPU が搭載された g5.2xlarge なので、インスタンスの時間当たりの単価と学習にかかった時間をかけ合わせればコストが計算できます。次の図は ELYZA の学習時間を示した図です。 価格を計算する際は、オンデマンド価格を参照しました ( 執筆時点で $1.212 / 時間 ) 。精度が十分な値になる 512 件では学習に 15 分程度、金額にして 44 円ぐらいになります。 小学校の遠足のおやつ代は平均 426 円 とのことなので、約 1/10 の金額でモデルが遠足に行って成長して帰ってくると考えると割安と感じます。スポットインスタンスなどを利用すればより安価になります。推論も同様にかかった時間に単価をかけて計算しましたが、 Swallow のみ g5.2xlarge に乗せるため 8bit の量子化をしています。 API のコストは、入出力のトークン数から計算します。ただし、評価用データ (validation dataset) が 4000 件近くあり、普通に 1 件 1 件推論しているとあっという間に 1 分当たりのリクエスト上限 に達してしまいます。そのため、 &nbsp;Preview 中の Batch inference の機能 を使用しました。次に Batch inference のサンプルコードを示します。 Amazon Simple Storage Service にデータをアップロードし、 create_model_invocation_job &nbsp;を実行します。 roleArn は Permission を参照し作成したロールの arn を設定します。 import time import boto3 bedrock = boto3.client(service_name="bedrock") inputDataConfig = ({ "s3InputDataConfig": { "s3Uri": "s3://input-bucket/input/abc.jsonl" } }) outputDataConfig = ({ "s3OutputDataConfig": { "s3Uri": "s3://output-bucket/output/" } }) response = bedrock.create_model_invocation_job( roleArn="arn:aws:iam::123456789012:role/MyBatchInferenceRole", modelId="amazon.titan-text-express-v1", jobName="my-batch-job", inputDataConfig=inputDataConfig, outputDataConfig=outputDataConfig ) job_id = response.get('jobArn') status = 'Begin' while status not in ('Completed', 'Failed', 'Stopped'): time.sleep(5) status = bedrock.get_model_invocation_job(jobIdentifier=job_id)[ "status" ] 定期的に get_model_invocation_job を実行しステータスを確認します。私が実行したところ、ジョブが実行開始になるまで ( Submitted から InProgress になるまで ) 数時間待たされることもあり、 Preview 以後改善されることを期待しています。 Batch inference は推論結果だけでなく、そのバッチで入出力されたトークン数が出力されます。以下は、 2 shot でプロンプトを書いたときの結果です。入出力のトークン数にそれぞれの単価をかけることでコストを算出できます。 { "processedRecordCount":4442, "successRecordCount":4442, "errorRecordCount":0, "inputTokenCount":3418270, "outputTokenCount":50038 } 実験コードは以下で公開しています。 Batch inference の実装サンプルはまだ少ないと思いますので、参考にしていただければ幸いです！ https://github.com/aws-samples/aws-ml-jp/pull/66 実験結果と今後の展望 実験結果は冒頭ご紹介した通りです。どれぐらいのデータがあれば OSS で公開されているモデルを追加学習し期待の精度が得られるのか、参考となる指標を示すことができたと思います。インスタンスをホスティングする場合常時稼働する点がネックになりますが、文書解析などリアルタイムで行う必要がないもの、ゲームなどで多様なキャラクターのバリエーションが必要でアクセス頻度も高い場合など、カスタマイズ性とホスティングによるレスポンスの速度や安定性が光るシーンは多々あると考えています。また、モデルを量子化しさらに C++ で最適化することで AWS Lambda 上で推論するなどできれば、実質サーバーレスの API と同等の体験が実現できるでしょう。 今後は、他タスクでの検証、また 7B のモデルを軸にサーバーレス形式での推論が行えないかなどを深堀できればと考えています。 著者プロフィール 久保 隆宏 (Takahiro Kubo) は AWS Japan の機械学習領域のデベロッパーリレーションを担当しており、「機械学習をするなら AWS 」と感じて頂くべくコンテンツの作成とフィードバックの収集による AWS サービスの改善を行っています。 前川 泰毅 (Taiki Maekawa) は AWS Japan のソリューションアーキテクトでメディア領域のお客様中心にアーキテクチャ設計や構築を支援しています。機械学習領域を得意としておりソリューションやサンプルコードの作成を行っています。 呉 和仁 (Go Kazuhito) は AWS Japan の機械学習ソリューションアーキテクト。 IoT の DWH 開発、データサイエンティスト兼業務コンサルタントを経て現職。プログラマの三大美徳である怠惰だけを極めてしまい、モデル構築を怠けられる AWS の AI サービスをこよなく愛す。