Anthropic が Claude 3 をリリース してからまだ 3 か月ばかりです。Claude 3 は最先端の人工知能 (AI) モデルファミリーであり、ニーズに合ったインテリジェンス、速度、コストの適切な組み合わせを選択することを可能にします。 6月20日、Anthropic は、近日リリース予定の Claude 3.5 モデルファミリーの最初のリリースである Claude 3.5 Sonnet を発表しました。 Amazon Bedrock で Claude 3.5 Sonnet が利用可能になった ことをお知らせいたします。 Claude 3.5 Sonnet は、インテリジェンスに関する業界の水準を引き上げ、幅広い評価で他の生成 AI モデルを上回るパフォーマンスを発揮しています。これには、Anthropic のこれまで最もインテリジェントなモデルであった Claude 3 Opus が含まれます。Claude 3.5 Sonnet は、オリジナルの Claude 3 Sonnet モデルと同じ速度と コスト で利用できます。実際、Claude 3.5 Sonnet は Opus よりも 80% 低コストであるため、Claude 3 Opus よりも優れたインテリジェンスとスピードを 5 分の 1 の料金で利用できます。 Claude 3.5 Sonnet が示す最先端のインテリジェンスとコスト効率の高い料金により、このモデルは、コンテキストに応じたカスタマーサポート、複数ステップのワークフローのオーケストレーション、コード変換の合理化などの複雑なタスクに最適です。 Claude 3.5 Sonnet は、学部レベルの専門的な知識 (MMLU)、大学院レベルの専門的な推論 (GPQA)、コード (HumanEval) などの新しい業界ベンチマークを達成しています。次の表に示すように、Anthropic によると、Claude 3.5 Sonnet はほぼすべてのベンチマークで OpenAI の GPT-4o と Google の Gemini 1.5 Pro を上回るパフォーマンスを発揮します。 また、Claude 3.5 Sonnet は、Anthropic のこれまでで最も強力なビジョンモデルでもあり、ほとんどのビジョンベンチマークで Claude 3 Opus よりも平均 10% 優れたパフォーマンスを発揮します。さらに、Anthropic によると、Claude 3.5 Sonnet は、ほぼすべてのカテゴリで他の生成 AI モデルを上回るパフォーマンスを発揮します。 Anthropic の Claude 3.5 Sonnet の主な改善点 Claude 3.5 Sonnet のリリースにより、複数の領域で大幅な改善がもたらされ、ソフトウェアデベロッパーや企業は 生成 AI を活用した新しい機能を利用できます。この新しいモデルのいくつかの主な強みを次に示します。 視覚処理と理解 – Claude 3.5 Sonnet は、画像の処理、特にチャートとグラフの解釈において優れた機能を発揮します。不完全な画像からテキストを正確に書き起こします。これは、 小売 、物流、 金融サービス などの業界の中核的な機能であり、テキストのみの場合と比較して、グラフィックやイラストからより多くのインサイトを得られるようにします。Claude 3.5 Sonnet を使用すると、視覚データ処理タスクを自動化し、貴重な情報を抽出して、データ分析パイプラインを強化できます。 ライティングとコンテンツ生成 – Claude 3.5 Sonnet では、ニュアンスとユーモアを理解する能力が飛躍的に高まっています。このモデルは、より自然かつ人間味のあるトーンで、より本物らしく、親しみやすい、質の高い書面コンテンツを生成します。このモデルを使用すると、魅力的で説得力のあるコンテンツを生成し、ライティングワークフローを合理化して、ストーリーテリング機能を強化できます。 カスタマーサポートと自然言語処理 – コンテキストの理解度が高まり、ワークフローのマルチステップオーケストレーションが可能な Claude 3.5 Sonnet は、顧客からの複雑な問い合わせの処理に優れています。この機能により、24 時間体制のサポート、応答時間の短縮、より自然なやり取りが可能になり、最終的には顧客満足度を高めることができます。このモデルを使用すると、カスタマーサポートプロセスを自動化および強化し、エンドユーザーのためにシームレスなエクスペリエンスを提供できます。類似の実装の例については、Amazon Bedrock で Anthropic の Claude 3 モデルを使用して、 DoorDash が生成 AI によるセルフサービスコンタクトセンターソリューションを構築した方法 をご覧ください。 分析とインサイト – Claude 3.5 Sonnet は、非構造化データを簡単に操作し、複数のツールを使用してインサイトを生成することで、データサイエンスの領域における人間の専門知識を強化します。ビジネス戦略からリアルタイムの製品トレンドに至るまで、質の高い統計ビジュアライゼーションと実用的な予測を生成します。Claude 3.5 Sonnet を使用すると、データ分析ワークフローを簡素化し、有益なインサイトを明らかにして、データ駆動型の意思決定を推進できます。 コーディングとソフトウェア開発 – Claude 3.5 Sonnet は、関連ツールが提供されている場合、高度な推論機能とトラブルシューティング機能を使用して、コードを独自に記述、編集、実行できます。Claude 3.5 Sonnet を使用すると、デベロッパーのワークフローを合理化し、コーディングタスクを高速化するとともに、手作業を減らして、全体的な生産性を高めることができます。 Amazon Bedrock コンソールでの Anthropic の Claude 3.5 Sonnet の使用 これは新しいモデルなので、 Amazon Bedrock コンソール に移動し、ナビゲーションペインから [モデルアクセス] を選択して、Claude 3.5 Sonnet へのアクセスを有効にします。 モデルにアクセスできるようになったので、 Our World in Data ウェブサイトの 次の画像から情報を抽出するためにモデルを使用します。 ナビゲーションペインの [プレイグラウンド] セクションで [チャット] を選択し、モデルとして [Anthropic] と [Claude 3.5 Sonnet] を選択します。その後、 [画像] アップロードボタンを選択して前の画像をアップロードし、次のプロンプトを入力して、 [実行] を選択します。 Which countries consume more than 1000 TWh from hydropower? Think step by step and look at all regions.Output in JSON. 結果と、私が実行したことをまとめたアニメーション画像を次に示します。 To determine which countries consume more than 1,000 TWh from hydropower in 2022, I need to carefully examine the map and color-coding.The scale at the bottom shows that dark blue represents consumption between 1,000 TWh and 2,000 TWh. Let's look at each region systematically: 1.North America: Canada is dark blue, indicating it consumes between 1,000-2,000 TWh from hydropower. 2.South America: Brazil is dark blue, also consuming between 1,000-2,000 TWh. 3.Europe: No country is dark blue; all are light green or have no data. 4.Africa: No data available for any country. 5.Asia: China is dark blue, indicating consumption between 1,000-2,000 TWh. 6.Oceania: No country is dark blue; Australia is light green. In summary, there are three countries that consume more than 1,000 TWh from hydropower in 2022: 1.Canada (North America) 2.Brazil (South America) 3.China (Asia) Here's the response in JSON format: ```json { "countries_consuming_over_1000TWh_hydropower": [ { "name": "Canada", "region": "North America", "consumption_range": "1,000-2,000 TWh" }, { "name": "Brazil", "region": "South America", "consumption_range": "1,000-2,000 TWh" }, { "name": "China", "region": "Asia", "consumption_range": "1,000-2,000 TWh" } ] } ``` These three countries stand out as the highest consumers of hydropower energy, each using between 1,000 and 2,000 terawatt-hours in 2022. 画像などの非構造化データから情報を確実に抽出するこのモデルの機能は、新しい可能性の世界を切り開きます。 プレイグラウンドウィンドウの隅にある 3 つの小さなドットを選択し、 [API リクエストを表示] を選択して、 AWS コマンドラインインターフェイス (AWS CLI) および AWS SDK でモデルを使用したコード例を表示します。コード構文を詳しく見てみましょう。 AWS SDK での Claude 3.5 Sonnet の使用 新しい Amazon Bedrock Converse API または Anthropic Claude Messages API を使用して、任意の AWS SDK で Claude 3.5 Sonnet を使用できます。 既に Claude 3 モデルを使用しているコードを更新するために必要なのは、モデル ID を次のように置き換えることだけです。 anthropic.claude-3-5-sonnet-20240620-v1:0 Converse API で画像とテキストを使用する方法を示すために、以前と同じ画像を使用した AWS SDK for Python (Boto3) のサンプル実装を次に示します。 import boto3 from botocore.exceptions import ClientError MODEL_ID = "anthropic.claude-3-5-sonnet-20240620-v1:0" IMAGE_NAME = "primary-energy-hydro.png" bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1") with open(IMAGE_NAME, "rb") as f: image = f.read() user_message = "Which countries consume more than 1000 TWh from hydropower? Think step by step and look at all regions.Output in JSON." messages = [ { "role": "user", "content": [ {"image": {"format": "png", "source": {"bytes": image}}}, {"text": user_message}, ], } ] response = bedrock_runtime.converse( modelId=MODEL_ID, messages=messages, ) response_text = response["output"]["message"]["content"][0]["text"] print(response_text) 実行すると、コンソールにおけるのと類似の出力が表示されます。 Let's approach this step-by-step: 1.First, I'll examine the color scale at the bottom of the map.The darkest blue color represents consumption of 2,000 TWh or more. 2.Now, I'll scan the map region by region: North America: Canada is dark blue, indicating over 1,000 TWh. South America: Brazil is also dark blue, over 1,000 TWh. Europe: No country appears to be dark blue. Africa: No country appears to be dark blue. Asia: China stands out as dark blue, indicating over 1,000 TWh. Oceania: No country appears to be dark blue. 3.To be thorough, I'll double-check for any medium blue countries that might be close to or over 1,000 TWh, but I don't see any that appear to reach that threshold. 4.Based on this analysis, there are three countries that clearly consume more than 1,000 TWh from hydropower. Now, I'll format the answer in JSON: ```json { "countries_consuming_over_1000TWh_hydropower": [ "Canada", "Brazil", "China" ] } ``` This JSON output lists the three countries that visually appear to consume more than 1,000 TWh of primary energy from hydropower according to the 2022 data presented in the map. JSON 構文を指定しなかったため、2 つの回答は異なる形式を使用しています。アプリケーションでは、プロンプトで必要な JSON プロパティを記述するか、または出力で標準形式を取得するためのサンプルを提供できます。 その他の例については、 「Amazon Bedrock ユーザーガイド」のコードサンプル をご覧ください。より高度なユースケースについては、 生成 AI モデルをカスタムツールまたは API に接続する方法 を示す、完全に機能する ツール使用 デモをご覧ください。 AWS CLI での Claude 3.5 Sonnet の使用 コマンドラインが最も速い場合があります。新しいモデルで AWS CLI を使用する方法は次のとおりです。 aws bedrock-runtime converse \ --model-id anthropic.claude-3-5-sonnet-20240620-v1:0 \ --messages '{"role": "user", "content": [{"text": "Alice has N brothers and she also has M sisters.How many sisters does Alice’s brother have?"}]}' \ --region us-east-1 --query output.message.content 出力では、クエリオプションを使用して出力メッセージの内容のみを取得します。 [ { "text": "Let's approach this step-by-step:\n\n1.First, we need to understand the relationships:\n - Alice has N brothers\n - Alice has M sisters\n\n2.Now, let's consider Alice's brother:\n - He is one of Alice's N brothers\n - He has the same parents as Alice\n\n3.This means that Alice's brother has:\n - The same sisters as Alice\n - One sister more than Alice (because Alice herself is his sister)\n\n4.Therefore, the number of sisters Alice's brother has is:\n M + 1\n\n Where M is the number of sisters Alice has.\n\nSo, the answer is: Alice's brother has M + 1 sisters." } ] text を小さな Python プログラムにコピーして、複数行に出力されているのを確認します。 print("Let's approach this step-by-step:\n\n1.First, we need to understand the relationships:\n - Alice has N brothers\n - Alice has M sisters\n\n2.Now, let's consider Alice's brother:\n - He is one of Alice's N brothers\n - He has the same parents as Alice\n\n3.This means that Alice's brother has:\n - The same sisters as Alice\n - One sister more than Alice (because Alice herself is his sister)\n\n4.Therefore, the number of sisters Alice's brother has is:\n M + 1\n\n Where M is the number of sisters Alice has.\n\nSo, the answer is: Alice's brother has M + 1 sisters.") Let's approach this step-by-step: 1.First, we need to understand the relationships: - Alice has N brothers - Alice has M sisters 2.Now, let's consider Alice's brother: - He is one of Alice's N brothers - He has the same parents as Alice 3.This means that Alice's brother has: - The same sisters as Alice - One sister more than Alice (because Alice herself is his sister) 4.Therefore, the number of sisters Alice's brother has is: M + 1 Where M is the number of sisters Alice has. So, the answer is: Alice's brother has M + 1 sisters. これは非常に繊細な理解を要する質問でしたが、Claude 3.5 Sonnet はそれを正しく理解し、その推論をステップバイステップで説明しました。 知っておくべきこと Anthropic の Claude 3.5 Sonnet は、米国東部 (バージニア北部) AWS リージョン において、 Amazon Bedrock で本日からご利用いただけます。 リージョン別の Amazon Bedrock モデルのサポートの詳細については、ドキュメントをご覧ください 。  Amazon Bedrock の料金ページ では、特定のユースケースのコストをご確認いただけます。 Claude 3.5 Sonnet は、より高速かつ強力なモデルへのアクセスをより低コストで提供することで、次のような多くの業界で生成 AI をより簡単かつ効果的に使用できるようにします。 ヘルスケアとライフサイエンス – 医療分野では、Claude 3.5 Sonnet における画像分析の強化、患者のトリアージのための診断アシスタントとしての機能、最新の研究結果を簡単に理解できる形式で要約する機能に期待が寄せられています。 金融サービス – このモデルは、金融トレンドの特定や、クライアントの独自の状況に合わせてカスタマイズおよびパーソナライズされた債務返済計画の作成において、有益なサポートを提供できます。 法律 – 法律事務所は、このモデルを使用して、関連する裁判例や法令を迅速に表示することで、法律関連の調査を加速できます。さらに、このモデルは、契約分析を通じてパラリーガルの効率を高め、標準的な法律文書の草案作成をサポートできます。 メディアとエンターテインメント – このモデルは、ジャーナリストの調査を迅速化し、脚本執筆やキャラクターの確立といったクリエイティブなプロセスをサポートするとともに、有益なオーディエンス感情分析を提供できます。 テクノロジー – ソフトウェアデベロッパーにとって、Claude 3.5 Sonnet は、アプリケーションの迅速なプロトタイピング、レガシーコードの移行、革新的な機能の着想、ユーザーエクスペリエンスの最適化、およびフリクションポイントの特定における機会を提供します。 教育 – 教育機関は、このモデルを使用して助成金申請書の作成を効率化し、新しいトレンドを取り入れた包括的なカリキュラムを策定するとともに、データベースクエリとインサイトの生成を通じて研究支援を受けることができます。 今は生成 AI にとってエキサイティングな時期です。この新しいモデルの使用を開始するには、 「Amazon Bedrock ユーザーガイド」の Anthropic Claude モデルのセクション をご覧ください。また、 community.aws サイトにアクセスして、詳細な技術コンテンツを検索したり、ビルダーコミュニティが自らのソリューションで Amazon Bedrock をどのように利用しているかを学んだりすることもできます。これらの強化された機能で何を実行しているのか、ぜひお知らせください! – Danilo 原文は こちら です。

この記事はソリューションアーキテクトの遠藤宣嗣が翻訳しました。原文は こちら です。 AWS は 2008 年から .NET ワークロードをサポートしています。長年にわたり、.NET は柔軟性の低い Windows 専用のフレームワークから、モジュール型のクロスプラットフォームランタイムへと変化してきました。現在では、レガシーな .NET Framework アプリケーションを Windows 上で実行できるだけでなく、Linux 上でも最新の .NET アプリケーションを実行することができます。これらはすべて AWS で完全にサポートされています。従来の .NET Framework アプリケーションは AWS 上で実行できますが、.NET ワークロードを最新化することでコスト削減、コンテナとサーバーレスの活用、マイクロサービスとクラウドネイティブアーキテクチャへの移行が可能になります。 この記事では、.NET のモダナイゼーションのさまざまなアプローチを AWS の支援ツールやガイダンスとともに紹介します。この記事では、.NET Framework と明確に区別するために、クロスプラットフォームの .NET（以前は .NET Core と呼ばれていた）を「最新の .NET」と呼びます。 .NET アプリケーションをモダナイズする理由 まず「.NET モダナイゼーション」が何を意味するのか、そしてなぜ考慮すべきかについて説明しましょう。.NET モダナイゼーションには、1) アプリケーションコードを最新の .NET にアップグレードすること、2) クラウドとコンテナへの移行、3) ライセンス製品からオープンソースへの移行、4) 最新のアーキテクチャへの移行が含まれます。アプリケーションとともにデータも移行する必要があるため、データベースについても同様の考慮事項があります。 最初に、レガシーな.NET Framework から「最新の .NET」 へ移行することで、新しい機能を利用できるようになり、パフォーマンスが向上します。 .NET Framework 4.8 は Windows で引き続きサポートされていますが、このバージョンの活発な開発は行われていません。対照的に、 最新の .NET は定期的にアップデートされ、毎年、新機能とパフォーマンス改善が行われています。 2つ目に、スケールと従量課金の柔軟性があるクラウドに移行することができます。クラウドでは、デファクトスタンダードとなっているコンテナを使用することもできます。 コンテナを使用することで、アプリケーションの移植性が高まり、サーバーの使用効率が上がり、クラウドにおけるサービスの選択肢が広がります。AWS のコンテナ サービスの詳細は、 AWS でのコンテナ をご覧ください。 3つ目は、オープンソース製品に移行することでコストを削減できます。「最新の .NET」 コードは Linux 上で OS ライセンスの料金なしで実行できます。また、SQL Server やその他のプロプライエタリなリレーショナルデータベースからオープンソースのデータベースに移行することで、ライセンス料金を削減できます。AWS のリレーショナルデータベースや目的別のデータベースの詳細は、 AWS クラウドデータベース をご覧ください。 4つ目に、クラウドでアーキテクチャをモダナイズできます。 単一の大規模な「モノリシック」アプリケーションをマイクロサービスに変換することで、疎結合と複雑さの軽減による技術的・組織的なメリットが得られます。AWS でのマイクロサービスの詳細は、 マイクロサービス で学ぶことができます。さらに一歩進めて、完全にクラウドネイティブなアーキテクチャを採用し、クラウドのメリットを最大限に活用することもできます。マネージドサービス、サーバーレス、目的別のデータベース上に構築されたイベント駆動型のソリューションは、疎結合で俊敏性と効率性に優れ、監査可能なものです。これらの詳細は、 クラウドネイティブとは 、 イベント駆動型アーキテクチャとは 、 AWS でのサーバレス  で学ぶことができます。 このような選択肢がある中で、.NET アプリケーションのモダナイゼーションをどこから始めたらいいのか、どこを目指すのか迷うかもしれません。それぞれのアプローチのメリット、技術的な作業、必要な労力を理解することが役立ちます。 モダナイゼーションへのアプローチ AWS では、モダナイゼーションを旅路に例えることがありますが、それは誰にとっても同じものではありません。AWS で .NET アプリケーションをモダナイズするために複数のアプローチがあり、その中にはよりシンプルなものもあります。AWS の支援ツールを使ってマネージドサービスを利用する 4 つのアプローチを見ていきましょう。 アプローチ ツール メリット ポートフォリオを評価して、モダナイゼーション戦略を立案する Migration Hub Strategy Recommendations 複数のアプリケーションをモダナイズするための最適な戦略とアプローチを特定する Windows コンテナ上で .NET Framework をリプラットフォームする AWS App2Container コードを変更せずに最小限の労力で AWS に移行する。Windows ライセンス料を削減するためにサーバーを統合する Linux コンテナ上のモダンな .NET に .NET Framework をリファクタリングする AWS Toolkit for .NET Refactoring、または Porting Assistant for .NET OS のライセンス料なしで Linux 上で実行することによりコストを削減する モノリシックな .NET アプリケーションをマイクロサービスにリファクタリングする AWS Microservice Extractor for .NET スケーラビリティ、アジリティ、安定性の向上 アプリケーションポートフォリオの評価とモダナイゼーションの計画 どこから始めれば良いか分からない場合は、ここから始めてください。モダナイズするアプリケーションが複数ある場合は、個々のアプリケーションに焦点を当てる前に、アプリケーションポートフォリオの評価を行うことをおすすめします。そうすることで、モダナイゼーションの優先順位が明確になり、戦略の特定につながります。これは、旅行の前に計画を立てるのと同じように、モダナイゼーションを始めるのに理想的な出発点です。モダナイゼーションのスピードを上げることができる、繰り返し適用できるパターンが見つかるかもしれません。 AWS Migration Hub Strategy Recommendations (MHSR) は、オンプレミスまたは AWS で実行されているアプリケーションの移行とモダナイゼーションの戦略を構築するのに役立ちます。MHSR はサーバー、アプリケーションのソースコード、データベースを分析します。そして、大規模なモダナイゼーションを支援するのに役立つ最適な戦略とツールに関するガイダンスを提供します。 Windows コンテナ上の .NET Framework のリプラットフォーム .NET Framework の IIS Web アプリケーション を Windows　コンテナを使用して、通常はコードを変更せずに、最小限の労力で AWS に移行できます。アプリケーションをコンテナ化することで、サーバーを統合し、コンピューティングリソースをより効率的に使用できるため、Windows ライセンスコストを削減できます。コンテナ化されたアプリケーションは、最終的に Amazon Elastic Container Registry (ECR) の Windows コンテナイメージになります。Windows コンテナは、 Amazon Elastic Container Service (Amazon ECS) で で、あるいは、Kubernetes がお好みの場合は、 Amazon Elastic Kubernetes Service (Amazon EKS) でホストできます。Amazon ECS にデプロイする場合、 AWS Fargate を使用して、Windows コンテナをサーバーレスでホストするオプションもあります。 AWS App2Container (A2C) コマンドラインツールを使用すると、アプリケーションを分析し、Amazon ECS または Amazon EKS 向けの正しい依存関係、ネットワーク構成、デプロイ手順を含むコンテナイメージを自動生成できます。A2C は AWS へのデプロイも処理します。 A2C の仕組みは次の通りです。まず、A2C はサーバーをスキャンして Web アプリケーションのインベントリを作成します。次に、選択した .NET Framework IIS アプリケーション用の Windows コンテナ イメージが作成されます。3つ目に、デプロイメント アーティファクトを使用した CI/CD パイプラインが作成されます。最後に、Amazon ECS または Amazon EKS 上でサービスが作成されます。これで、.NET Framework アプリが AWS 上の Windows コンテナで実行されるようになります。このモダナイゼーションパスを完了するには、データベースを AWS に移行し、元の環境から他のアプリケーションの依存関係を移行する必要もあります。 .NET Framework から Linux コンテナ上の「最新の .NET」へのリファクタリング .NET Framework アプリケーションを「最新の .NET」 に移植し、Linux 上で実行することでライセンスコストを節約できます。移行が完了すると、 AWS App Runner 、 Amazon ECS 、または Amazon EKS で管理された Linuxコンテナ内でモダナイズされた dotnet アプリケーションを実行できます。AWS App Runner はよりシンプルな Web アプリケーションに最適であり、Amazon ECS と Amazon EKS は複数のコンテナサービスのオーケストレーションを処理できます。 AWS Toolkit for .NET Refactoring（英語） または Porting Assistant for .NET ツールを使用して、移行作業を迅速に開始しましょう。これらの支援ツールは、.NET Framework アプリケーションをスキャンして、「最新の .NET」 との互換性の問題を特定し、既知の置き換え候補を検索し、詳細な互換性評価を生成し、コードをLinux に対応するように変更します。おそらく手動での移行作業が必要になることもありますが、これらの支援ツールが大部分の作業を肩代わりしてくれます。互換性評価は、 レガシーな WCF アプリケーションを CoreWCF に移行する（英語） など、移植の問題を解決するための戦略とソリューションを提示してくれます。 どちらの移行ツールを使用すべきか検討する際、Porting Assistant for .NET はオープンソースであるのに対し、.NET Refactoring 用の Toolkit は AWS 環境でのテストなど追加機能を提供し、Visual Studio に統合されていることを考慮してください。 モノリスからマイクロサービスへのリファクタリング マイクロサービスは、ソフトウェア開発におけるアーキテクチャ上のアプローチであり、ソフトウェアを小さな独立したサービスで構成し、明確に定義された API を介して通信します。密結合のモノリシックなアプリケーションと比較して、マイクロサービスはアプリケーションのスケーラビリティを向上させ、開発速度を速めます。マイクロサービスは技術的な面だけでなく、組織的な面でも優れています。各サービスは最も適したチームが管理できるからです。AWS のマイクロサービスの詳細は、 マイクロサービス をご覧ください。 マイクロサービスへの移行は、 Strangler Fig（英語） パターンに従い、 AWS Microservice Extractor for .NET ツールを使用することで、徐々に進めることができます。このツールは、.NET Framework とモダン .NET アプリケーションの両方のリファクタリングを簡単にします。Microservice Extractor はアプリケーションを分析し、コンポーネントと依存関係を可視化します。機械学習に基づいてマイクロサービス化に適した候補を推奨したり、コンポーネントを手動でグループ化したりすることも可能です。ビジネスドメインを分離し依存関係を取り除くことでコードのリファクタリングを行い、ツールを使用してグループを個別のサービスプロジェクトに抽出します。Microservice Extractor は、Porting Assistant for .NET との統合を通じて、サービスを抽出しながら .NET Framework コードを最新の .NET に移植できます。AWS 上の .NET マイクロサービスへのリファクタリングの詳細は、テクニカルガイドの .NET アプリケーションのモノリスからマイクロサービスへの移行（英語） を参照してください。 まとめ この記事では、.NET のモダナイゼーションに向けたい幾つかのアプローチを紹介し、その過程で AWS が提供する支援ツールがどのようにガイドして作業負荷を軽減してくれるかについても触れました。.NET アプリケーションのモダナイゼーションを開始するには、 AWS で .NET ワークロードをモダナイズ をご覧ください。 そこでは、これらのアプローチに関するガイダンス、ツール、デモ、詳しい解説などの情報を参照できます。この投稿で説明したアプローチに加えて、 AWS で Windows ワークロードをモダナイズ 、 Microsoft ワークロードモダナイゼーションガイド（英語） 、 Microsoft ワークロード向け AWS モダナイゼーションツール リファレンスガイド（英語） で、追加のアプローチを確認できます。 投稿者について David Pallmann David Pallmann は AWS の EC2 チームのシニアプロダクトマネージャーです。彼のミッションは、AWS を .NET 開発者にとってワールドクラスのエクスペリエンスにすることです。David は以前、エンジニアリング、コンサルティング、プロダクト、テクニカルマネージャの役割を担っていました。彼は WCF に取り組み、後に最初の .NET ベースのエンタープライズサービスバスである Neuron ESB を開発しました。X では @davidpallmann でフォローしてください。 翻訳者について 遠藤 宣嗣 遠藤 宣嗣 は、AWS Japan のソリューションアーキテクト　(SA)として、日本市場において ISV ベンダーを中心にお客様の SaaS Journey とマイクロソフトワークロードのアプリケーション モダナイゼージョンを支援しています。

6月19日、 Amazon SageMaker でのフルマネージド型 MLflow 機能 の一般提供についてお知らせいたします。 MLflow は広く使用されているオープンソースツールであり、機械学習 (ML) チームが ML ライフサイクル全体を管理する上で重要な役割を果たします。今回の新リリースにより、わずか数ステップで MLflow Tracking Server を簡単にセットアップおよび管理できるようになり、お客様はプロセスの合理化と生産性の向上を実現できます。 MLflow を活用すると、データサイエンティストと ML デベロッパーはモデルトレーニングの複数回の試行を実験内のランとして追跡し、それらのランを視覚化と比較して、モデルを評価し、最適なモデルをモデルレジストリに登録することができます。Amazon SageMaker では、MLflow のセットアップと管理に必要とされる、競合他社との差別化にはつながらない手間のかかる作業が不要になります。また、ML 管理者は AWS で安全かつスケーラブルな MLflow 環境をすばやく効率的に構築できるようになります。 SageMaker でのマネージド MLflow の主要なコンポーネント SageMaker のフルマネージド型 MLflow 機能は、次の 3 つの主要なコンポーネントを中心に構築されています。 MLflow Tracking Server – SageMaker Studio UI を使用すると、わずか数ステップで MLflow Tracking Server を作成できます。このスタンドアロン HTTP サーバーは、ランと実験を追跡するための複数の REST API エンドポイントを提供するため、ML 実験のモニタリングを効率的に開始できます。セキュリティをさらに細かくカスタマイズするには、 AWS コマンドラインインターフェイス (AWS CLI) を使用することもできます。 MLflow バックエンドメタデータストア — メタデータストアは MLflow Tracking Server の重要な部分であり、実験、ラン、アーティファクトに関連するすべてのメタデータが保持されます。これには、テスト名、ラン ID、パラメーター値、メトリクス、タグ、アーティファクトの場所が含まれ、ML テストを包括的に追跡および管理できます。 MLflow アーティファクトストア – このコンポーネントは、トレーニング済みモデル、データセット、ログ、プロットなど、ML 実験中に生成されたすべてのアーティファクトの保存場所を提供します。 Amazon Simple Storage Service (Amazon S3) バケットを利用して、これらのアーティファクトを安全かつ効率的に保存するためのカスタマー管理型 AWS アカウントを提供します。 Amazon SageMaker with MLflow の利点 Amazon SageMaker と MLflow を組み合わせて使用すると、機械学習ワークフローを合理化および強化できます。 包括的な実験トラッキング: ローカル統合開発環境 (IDE)、SageMaker Studio のマネージド IDE、SageMaker トレーニングジョブ、SageMaker 処理ジョブ、SageMaker パイプライン全体にわたって MLflow の実験を追跡します。 MLflow の全機能: MLflow トラッキング、MLflow 評価、MLflow モデルレジストリなどのすべての MLflow 実験機能を使用して、トレーニング反復の結果を簡単に比較および評価できます。 統合モデルガバナンス: MLflow に登録したモデルは自動的に SageMaker モデルレジストリに表示され、統合モデルガバナンスエクスペリエンスが提供されるため、カスタムコンテナを構築することなく MLflow モデルを SageMaker 推論にデプロイできます。 効率的なサーバー管理: SageMaker API または SageMaker Studio UI を使用して、必要に応じて MLflow Tracking Server のプロビジョニング、削除、アップグレードを行います。SageMaker は、お客様が基盤となるインフラストラクチャを管理しなくても、Tracking Server のスケーリング、パッチ適用、継続的なメンテナンスを管理します。 セキュリティの強化: AWS Identity and Access Management (IAM) を使用して MLflow Tracking Server へのアクセスを保護します。特定の MLFlow API へのアクセスを許可または拒否する IAM ポリシーを記述して、ML 環境の強固なセキュリティを確保します。 効果的なモニタリングとガバナンス: Amazon EventBridge と AWS CloudTrail を使用して MLflow Tracking Server のアクティビティをモニタリングし、Tracking Server の効果的なガバナンスをサポートします。 MLflow Tracking Server の前提条件 (環境設定) SageMaker Studio ドメインの作成 新しい SageMaker Studio エクスペリエンス を使用して SageMaker Studio ドメインを作成できます。 IAM 実行ロールの設定 MLflow Tracking Server には、Amazon S3 へのアーティファクトの読み取りおよび書き込みを行ったり、モデルを SageMaker に登録したりするための IAM 実行ロールが必要です。Studio ドメイン実行ロールを Tracking Server 実行ロールとして使用することも、Tracking Server 実行ロール用に別のロールを作成することもできます。このために新しいロールを作成する場合は、IAM ロールの詳細について「 SageMaker デベロッパーガイド 」をご覧ください。Studio ドメイン実行ロールを更新する場合、ロールに必要な IAM ポリシーの詳細については、「SageMaker デベロッパーガイド」を参照してください。 MLflow Tracking Server の作成 このチュートリアルでは、Tracking Server の バージョン (2.13.2)、 サイズ (小)、 実行ロール (Studio ドメイン実行ロール) などのデフォルト設定を使用して、MLflow Tracking Server を作成します。Tracking Server のサイズによって、サポートできる使用量は異なります。25 ユーザー以下のチームには、Small Tracking Server を使用することをお勧めします。Tracking Server 設定の詳細については、「 SageMaker デベロッパーガイド 」を参照してください。 まず、先ほど説明した環境設定で作成した SageMaker Studio ドメインの [アプリケーション] で [MLflow] を選択し、[ 作成 ] を選択します。 次に、Tracking Server の 名前 と アーティファクトの保存場所 (S3 URI) を指定します。 MLflow Tracking Server の作成には最大 25 分かかる場合があります。 トレーニングランの追跡と比較 MLflow のメトリクス、パラメータ、アーティファクトのログ記録を開始するには、作成ステップで割り当てた Jupyter Notebook と Tracking Server ARN が必要です。MLflow SDK を使用してトレーニングランを追跡し、MLFlow UI を利用してそれらを比較できます。 MLFlow モデルレジストリから SageMaker モデルレジストリにモデルを登録するには、 AWS Signature V4 を使用して MLFlow SDK によって行われたすべての MLFlow API リクエストを認証するための sagemaker-mlflow プラグインが必要です。 MLFlow SDK と sagemaker-mlflow プラグインをインストールする まず、Notebook に MLFlow SDK と sagemaker-mlflow Python プラグインをインストールします。 pip install mlflow==2.13.2 sagemaker-mlflow==0.1.0 実験でランを追跡する 実験のランを追跡するには、次のコードを Jupyter Notebook にコピーします。 import mlflow import mlflow.sklearn from sklearn.ensemble import RandomForestClassifier from sklearn.datasets import load_iris from sklearn.model_selection import train_test_split from sklearn.metrics import accuracy_score, precision_score, recall_score, f1_score # Replace this with the ARN of the Tracking Server you just created arn = 'YOUR-TRACKING-SERVER-ARN' mlflow.set_tracking_uri(arn) # Load the Iris dataset iris = load_iris() X, y = iris.data, iris.target # Split the data into training and testing sets X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42) # Train a Random Forest classifier rf_model = RandomForestClassifier(n_estimators=100, random_state=42) rf_model.fit(X_train, y_train) # Make predictions on the test set y_pred = rf_model.predict(X_test) # Calculate evaluation metrics accuracy = accuracy_score(y_test, y_pred) precision = precision_score(y_test, y_pred, average='weighted') recall = recall_score(y_test, y_pred, average='weighted') f1 = f1_score(y_test, y_pred, average='weighted') # Start an MLflow run with mlflow.start_run(): # Log the model mlflow.sklearn.log_model(rf_model, "random_forest_model") # Log the evaluation metrics mlflow.log_metric("accuracy", accuracy) mlflow.log_metric("precision", precision) mlflow.log_metric("recall", recall) mlflow.log_metric("f1_score", f1) MLflow UI でランを表示する ステップ 2 で示した Notebook を実行すると、MLflow UI に新しいランが表示されます。 ランを比較する random_state を変更してトレーニングランごとに異なるメトリクス値を生成すると、この Notebook を複数回実行できます。 候補モデルを登録する ステップ 4 で説明したとおり、複数回のランを比較したら、要件に最も一致するメトリクスを備えたモデルを MLflow モデルレジストリに登録できます。モデルを登録すると、本番環境への導入への潜在的な適合性が示され、この適合性を検証するためのさらなるテストが行われます。MLflow に登録されたモデルは SageMaker モデルレジストリに自動的に表示され、統一されたモデルガバナンスエクスペリエンスとなり、MLFlow モデルを SageMaker 推論にデプロイできるようになります。これにより、主に MLflow を実験に使用するデータサイエンティストは、SageMaker Model Registry を使用してモデルの本番環境へのデプロイを管理する ML エンジニアにモデルを引き渡すことができます。 MLflow モデルレジストリに登録されているモデルは次のとおりです。 SageMaker モデルレジストリに登録されているモデルは次のとおりです。 クリーンアップ 一度作成した MLflow Tracking Server では、削除または停止するまでコストが発生します。Tracking Server の請求は、サーバーの稼働時間、選択したサイズ、Tracking Server に記録されたデータ量に基づきます。Tracking Server を使用していないときは停止してコストを節約したり、API や SageMaker Studio UI を使用して削除したりできます。価格設定の詳細については、 Amazon SageMaker の料金 を参照してください。 今すぐご利用いただけます SageMaker with MLflow は、中国と米国の GovCloud リージョンを除く、SageMaker Studio が利用可能なすべての AWS リージョンで 一般提供されています。この新機能をぜひ試して、機械学習プロジェクトの効率性と制御性の向上を体験してください。詳細については、SageMaker with MLflow 製品詳細ページ をご覧ください。 詳細については、「 SageMaker デベロッパーガイド 」をご覧ください。また、 AWS re:Post for SageMaker または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Veliswa 原文は こちら です。

この記事はソリューションアーキテクトの遠藤宣嗣が翻訳しました。原文は こちら です。 2024 年 6 月 20 日更新： 当初、このアナウンスでは .NET Framework の最小バージョンは 4.6.2 に変更される予定でした。 しかし、この作業の開発中に、SDK の長期的な方向性を考えると、 4.7.2 がより適切な最小ターゲットフレームワーク であると判断しました。 4.7.2 を使用することで、SDK は将来必要となるより多くの暗号アルゴリズムを利用できるようになります。また、このバージョンには特殊文字使用時のエンコードや署名の不一致に影響する System.Uri クラスの修正も含まれています。 2024 年 8 月 15 日から、.NET 用 AWS SDK は .NET Framework 3.5 のサポートを終了し、最小の .NET Framework バージョンを 4.7.2 に変更します。 変更の背景 .NET Framework 3.5 は、AWS のサービスがまだ少数しかなかった 2007 年にリリースされました。それ以来、クラウドアプリケーションの複雑さと言語ランタイムの要件は成長してきました。.NET 自体も、.NET での非同期プログラミングの記述方法を含め、.NET Framework 3.5 以降劇的に変化しています。これらの理由から、AWS SDK for .NET は .NET Framework 3.5 のサポートを終了します。 加えて、AWS SDK for .NET は現在 .NET Framework 4.5 を対象としていますが、これは 2016 年 1 月 にサポート終了となりました。.NET Framework 4.X プラットフォームに対する AWS SDK for .NET のサポートは、最小で 4.7.2 に引き上げられます。.NET Framework 4.7.2 は Windows Server 2019 のデフォルトインストールであり、Windows Server 2008 R2 SP1 や Windows 7 など過去のバージョンでも使用できます。 AWS SDK で .NET Framework 4.7.2 を使用する変更を行うことで、チームは SDK のモダナイズを開始し、より高パフォーマンスな SDK を提供できるようになります。 この SDK は、AWS SDK for .NET のすべての .NET ターゲットにわたって、.NET Standard 2.0 ライブラリと API を使用できるようになります。 これにより、SDK は JSON パースに System.Text.Json を使用し、Span や ArrayPool のようなメモリ効率の高い API を使用できるようになります。これらの変更により、アロケーションとガベージコレクションが削減されるため、.NET SDK を使用するアプリケーションのパフォーマンスが向上し、メモリフットプリントが小さくなります。 SDK のモダナイズは継続的な作業であり、最小限の .NET Framework ターゲットを更新することから始まります。 まとめ アップグレードできないアプリケーションを実行している場合は、現在のバージョンの AWS SDK for .NET を引き続き使用できます。ただし、2024 年 8 月 15 日以降、AWS SDK for .NET の新しいバージョンは、これらの古いバージョンの .NET Framework をサポートしなくなります。SDK のソースコードは、 GitHub で公開されています。.NET Framework 3.5 のサポートが終了すると、.NET Framework 3.5 をサポートしていた SDK の最後のバージョンが、別の Git ブランチにアーカイブされます。 フィードバック AWS SDK for .NET の変更は、 GitHub リポジトリで行われます。Issue や Discussion を開くことで、リポジトリ上の変更に対するフィードバックを提供できます。 投稿者について Norm Johanson Norm Johanson は、20年以上ソフトウェア開発者としてあらゆる種類のアプリケーションを開発してきました。2010年以来、彼はAWS で .NET 開発者のエクスペリエンスにフォーカスして働いています。X @ socketnorm と GitHub @ normj で見つけることができます。 翻訳者について 遠藤 宣嗣 遠藤 宣嗣 は、AWS Japan のソリューションアーキテクト　(SA)として、日本市場において ISV ベンダーを中心にお客様の SaaS Journey とマイクロソフトワークロードのアプリケーション モダナイゼージョンを支援しています。

AWS では、信頼性とは許容できる範囲内で大規模な中断に耐え、許容できる期間内に回復できる能力であると考えています。サービスの信頼性は、その目標を達成するために、可用性やパフォーマンスのような従来の基準を超えるものです。システムまたはアプリケーションのコンポーネントは、時間の経過とともにやがて故障します。当社の CTO である Werner Vogels が言うように、「Everything fails, all the time（故障しないものは無い）」のです。問題は、エンドユーザーに影響を与えずにシステムまたはアプリケーションがどのように障害に耐えられるか、そしてシステムが障害に対してどの程度回復力があるかということです。私たちのお客様はインシデントによる被害範囲を縮小し、ビジネスが必要とする信頼性、パフォーマンス、スケーラビリティの期待に応えるための支援を常に求めています。 このブログでは、インシデント発生時の迅速な対応のために、パフォーマンスを客観的に測定し、信頼性を正確に報告することでチームの成功を後押しする信頼性に関するベストプラクティスについて説明します。また、 サービスレベル目標 (SLOs) を、Amazon CloudWatch Application Signals を使ってすべての Amazon CloudWatch メトリクスから設定、監視し、アラートする方法についても説明します。 サービスレベル管理 (SLM) サービスレベル管理 (SLM) は、お客様に提供する IT サービスとサービスレベルを定義、交渉、管理するためのフレームワークやプロセスを提供します。このフレームワークには、サービスの可用性、品質、データセキュリティ、スループットといった、いくつかの重要な要素が含まれます。これは、お客様の目的と、サービスプロバイダである自社の両方の目的を守ることを目指しています。初めに、お客様に対する保証を表す用語と、サービスの健全性を示す追跡可能な指標について理解しましょう。 SLI (Service Level Indicator) は、提供されるサービスレベルのある側面を慎重に定義した定量的な指標です。 SLO (Service Level Objective) は、SLI によって一定期間測定されたサービスレベルの目標値または値の範囲です。 SLA (Service Level Agreement) は、お客様に約束するサービスレベルを概説した、お客様との合意です。また、要件を満たせない場合の対応策 (追加サポートや価格割引など) も詳細に規定されています。 エラーバジェット は、SLO を満たせなかった割合です。これは 100 % の信頼性と SLO 目標値の差に相当します。つまり、エラーバジェットとは、他の SLO を満たすための SLO です。 次の図は、SLA、SLO、SLI がどのように相互作用するかを表しています。お客様 (サービス利用者) はサービスを所有するチームの外部にいます。サービスチーム内には、ビジネスオーナーやカスタマーサクセスエンジニアなどのセールス機能があり、プロダクトオーナー (ロードマップを所有) と、サービスの開発と運用を行うエンジニアリングチームがいます。エンジニアリングチームは、サービスを測定する SLI を所有し、SLO を推進します。通常、プロダクトとエンジニアリングは SLA に情報を与える SLO を共同で所有しています。お客様は SLA を確認でき、サービスの状況を把握できますが、通常、SLO と SLI はサービスチームの境界を超えて共有されません。 実効的な SLO SLO は性能基準が満たされることを保証し、主要業績評価指標 (KPI) を達成するための実績データとして機能します。そのため、SLO は SMART (具体的、測定可能、達成可能、関連性がある、期限付き) である必要があります。SLO は、達成すべき目標を明確に定義し、進捗状況を測定する方法を提供し、現在のリソースと能力を考慮して現実的に目標を達成できることを保証し、ビジネス目標と一致し、目標達成のための期限を設定する必要があります。効果的な SLO の主な利点は、効果的な意思決定を可能にする可視性の向上と、事業の中断を効果的に防止するサービス品質の向上の２つです。これらは、カスタマーエクスペリエンスの評価に役立つ効果的な SLO のほんの一例です。 一般的な課題 SLO は、エンドユーザーとビジネスにとって何が最も重要かを効果的に優先順位付けするのに役立つ強力なツールです。しかし、導入には課題もあります。以下は、お客様の間でよく見られる課題の一部です。 SLI に適切なメトリクスをキャプチャする : 効果的な SLO の出発点は適切なメトリクスです。ただし、使用する適切なメトリクスを特定し、ビジネスに影響を与えるメトリクスを正しく計測できるようにサービスが実装されているかを確認することは難しい場合があります。 違反にいつ、どのように対応すべきかを知る : 適切なサービス、メトリクス、目標を特定したら、次の課題はエラーバジェットの計算方法と、バーンレートに基づく適切なレベルのアラートを作成する方法を知ることです。 SLO を診断ツールに接続する : SLO 違反に対して運用アラームに対応する予定がある場合、SLO の監視ツールとアプリケーションパフォーマンスのデバッグに使用するツールが連携していないと、SLO を満たしていない理由を特定するのが難しくなります。エクスペリエンスの繋がりが深いほど、より多くの洞察が得られ、SLO のパフォーマンスを向上させるために何に焦点を当てるべきかをより早く特定できます。 ベストプラクティス 組織におけるサービスレベル目標の導入を成功させるには、チーム間のコラボレーションが最も重要です。SLA を満たすための SLO を作成する際は、次のベストプラクティスを検討することをお勧めします。 全てのステークホルダーの目標を一致させる ：効果的な SLO を設定する際、プロダクト、エンジニアリング、オペレーションの全てで目標を合わせることが重要です。この目標の統一により、信頼性を検査し改善する SLO の実践を強化できます。 100 % を達成するのは現実的ではない ：好ましくないかもしれませんが、故障しないものはありません。そのため、100% の信頼性という目標を設定することは失敗の元になります。代わりに、達成すべき現実的な目標は何か、エンドユーザーはサービスに何を期待するかを考えてください。また、サービスは失敗したリクエストを再試行するように設計する必要があることを覚えておいてください。 対応計画を立てる（自動診断） ： SLO 違反に対して、警告をいつ、どのように受け取るかを慎重に検討することが重要です。一部の運用イベントは、他のイベントよりも速くバーンレートを消費するため、より重大なアラートを必要とする場合があります。可能な限り、SLO に影響を及ぼすアプリケーションの問題を自動検知し、改善するための自動化を利用しましょう。 文書化し、共有し、オープンスタンダードを活用する ：組織全体で SLO の採用を進める際は、チームが一貫したパターンを使用できるように、SLO の文書化と共有のための共通のフレームワークを用意しておくとよいでしょう。日次または週次の運用会議に SLO のレビューをどのように組み込むかを検討してください。 繰り返す （フィードバックループ、目標の再評価）： 厳格なSLAとは異なり、SLO はより柔軟で、サービスの信頼性を向上させることを目的としています。SLO の目標を達成できているかを継続的に評価し、ビジネスとお客様にとって適切な信頼性のバランスを実現できるように繰り返すことが重要です。 Amazon CloudWatch でネイティブ の SLO を作成する方法 Amazon CloudWatch Application Signals の導入により、AWS ネイティブで SLO を作成および監視できるようになりました。これらの SLO と Application Signals を使って、手動でのインストルメンテーション、メトリクス計算、観測された問題と根本原因の相関付けなどの作業なしに、重要なビジネス目標に対するアプリケーションのパフォーマンスを追跡できるようになります。CloudWatch Application Signals は、SLO を APM エクスペリエンスに接続できる包括的なアプリケーションパフォーマンス監視ソリューションを提供します。現在 CloudWatch で利用可能なメトリクスを使って SLO を開始できるため、簡単に使い始めることができます。 たとえば、ユーザーがログインしてワークアウトを確認したり、主要なフィットネスアクティビティを確認できるアプリケーションを提供するフィットネス会社で働いているとしましょう。このアプリケーションは、 Application Load Balancer (ALB) の背後にある EC2 インスタンス フリートで実行されます。ある日、サポートチームから、アプリにログインしてもワークアウトが表示されないという苦情がユーザーから寄せられているという緊急の通知が届きました。この問題を解決した後、同じようにエンドユーザー体験が低下させるような大規模な問題が発生したときに的確に把握できるように、可用性を監視する SLO を設定する必要があります。 CloudWatch に既にある ALB メトリクス を使用して可用性をモニタリングするための SLO を作成する方法を見てみましょう。この例では、1 分間のメトリクス期間においてリクエストの 95% が 28 日間にわたって99% 正常に処理されるという目標を設定します。これにより、毎分 95% を超えるリクエストの成功という期待どおりの結果が得られない場合に迅速に通知を受けることができます。また、すぐに対処する必要はないが、最終的には SLO 違反につながるような小さな問題を特定することもできます。 まず、左側のナビゲーションの Application Signals > サービスレベル目標 (SLO) を選択し、CloudWatch コンソールの SLO ダッシュボードに移動します。 次に SLO を作成 をクリックし、 SLI と SLO を定義します。 SLO のフォームから、 サービスレベル目標 (SLO) 名を設定 フィールドに名前 「My Availability SLO」を入力し、SLI に CloudWatch メトリクス を選択します。 次に、評価するメトリクスを選択します。このケースでは、アプリケーションが利用可能かどうかを評価したいとします。 CloudWatch メトリクス の Metric Math を使用して、1 分以内に 5xx エラーにならなかったリクエストの割合を計算します。 CloudWatch メトリクスを選択 ボタンをクリックし、 メトリクスの選択 ウィジェットを表示します。最初に 名前空間 ApplicationELB を選択し、次に AppELB 別 メトリクス を選択して ALB のメトリクスを検索します。次に、 RequestCount と HTTPCode_ELB_5XX_Count の 2 つのメトリクスを選択します。これら 2 つのメトリクスを使用して、5xx エラーを返さなかったリクエストの割合を計算し、アプリケーションの可用性を測定します。  RequestCount メトリクスと HTTPCode_ELB_5XX_Count メトリクスを選択したら、グラフ化したメトリクス タブを選択し、5xx エラーを返さなかったリクエストの割合を計算する数式を作成します。まず、両方のメトリクスの 統計 を サンプル数 に変更し、 期間 を 1 分 に変更します。 RequestCount の ID を 「totalrequests」 に変更し、 HTTPCode_ELB_5XX_Countm の ID を 「failedrequests」 に変更します。次に、 数式を追加 を選択し、 空の式で始まる を選択します。 数式の編集 で次の式を追加して成功したリクエストの割合を計算します。 ((totalrequests-failedrequests)/totalrequests)*100 。最後に、CloudWatch メトリクスのウィンドウで選択される唯一のメトリクスが数式になるように元のメトリクスの選択を解除し、 メトリクスの選択 をクリックします。 SLI に使用するメトリクスを定義したら、サービスがその目標を達成しているかどうかを示す条件を設定します。今回は 95 以下 をしきい値として設定します。つまり、リクエストの成功率が 95% 以下だった時間は不適格な時間と判定されるということです。 次に、SLO の目標とその目標をどのくらいの期間で測定するかを設定する必要があります。CloudWatch Application Signals では、SLO の時間間隔を選択する際に、 ローリング日 (連続日)と カレンダーか月 の 2 つのオプションが用意されています。最長の期間は12 か月です。この例では、「28 ローリング」日を選択し、達成目標を 99% に設定します。また、 警告のしきい値 を設定を登録することで、SLO を警告状態として指定するタイミングを選択できます。 オプションで、SLI がしきい値を満たさないとき (SLI 状態アラーム) 、 SLO 目標に違反したとき（SLO 達成目標アラーム）、警告のしきい値を超えたとき（SLO 警告アラーム）に通知する 3 つのアラームを自動的に作成することができます。次に、 SLOを作成 を選択します。 SLO を作成すると、数分以内に SLO ページに、達成度やエラーバジェットなどの SLO メトリクスが表示されます。また、 Application Signals は、より高度なアラームやダッシュボードのユースケースに使用できる達成度(AttainmentRate)とSLI 違反回数(BreachedCount) のメトリクスを公開しています。 次のステップ Application Signalsを使用すると、ビジネスへの影響が大きいメトリクスに焦点を当てた サービスレベル目標 (SLO ) を作成できます。これにより、重大な問題に優先順位を付け、ビジネス KPI との相関性を高めるために SLO を継続的に微調整できます。根本原因の特定を迅速化するために、Application Signals は CloudWatch Synthetics と連携して重要な API とユーザー操作を監視し、 CloudWatch RUM と連携して実際のユーザーパフォーマンスを監視することで、アプリケーションのパフォーマンスを包括的に監視できます。 CloudWatch Application Signalsを使用すると、アプリケーションを手動でインストルメントしなくても、AWS上のアプリケーションのパフォーマンスを簡単に確認できます。利用方法については、この ブログ を参照してください。 re:Invent 2023 の動画では、JP モルガン・チェースが Amazon CloudWatch Application Signals を使用してビジネス目標に対するパフォーマンスをトラックした方法をご覧頂けます。 Amazon CloudWatch Application Signals を使用したアプリケーションモニタリングの詳細については、この YouTube 動画 を確認してください。 この新機能を実際に体験するには、 ハンズオンワークショップ をご利用ください。ここでは、Amazon EC2 上で実行している Amazon EKS ワークロードをモニタリングするためにApplication Signals を使う方法を学べます。 結論 このブログでは、パフォーマンスを客観的に測定し、信頼性を正確に報告し、アラートによる混乱の軽減とインシデント発生時の迅速な対応を可能にすることで、チームを成功へと導く効果的な SLO のベストプラクティスについて説明しました。SLO の継続的な改善と定期的な見直しは、SLO が現実的であり続け、システムの機能とビジネス目標の両方と一致していることを確認するために不可欠です。また、パフォーマンスに影響する可能性のあるシステムへの変更は、関連する SLO の見直しのきっかけとなるはずです。もし、サポートが必要な場合は、AWS サポートや AWS アカウントチームにお問い合わせください。 著者について Andreas Bloomquist Andreas Bloomquist は Amazon CloudWatch の Sr. Product Managerです。彼はアプリケーションのオブザーバビリティに重点を置き、お客様がアプリケーションの状態を監視および評価し、問題が発生したときにその根本原因に迅速にたどり着けるよう支援しています。 Michael Hausenblas Michael は AWS オープンソースオブザーバビリティサービスチームで Technical Product Manager を務め、 AWS Distro for OpenTelemetry (ADOT) を担当しています。 Arun Chandapillai Arun Chandapillai は、ダイバーシティ＆インクルージョンの推進者である Senior Infrastructure Architect です。彼は、ビジネスファーストのクラウド運用戦略を通じてお客様が IT の近代化を加速し、クラウドでアプリケーションとインフラストラクチャを上手に構築、デプロイ、管理できるよう支援することに情熱を注いでいます。アルンは自動車愛好家であり、熱心な講演者であり、慈善家であり、「you get (back) what you give（善因善果）」と信じています。LinkedIn: /arunchandapillai 本記事は、 Improve application reliability with effective SLOs を翻訳したものです。翻訳はテクニカルアカウントマネージャーの日平が担当しました。

はじめに みなさんこんにちは。ソリューションアーキテクトの眞壽田（ますた）です。2024年6月20日、21日に幕張メッセにて AWS Summit Japan イベントが開催されました。今年の AWS Summit は、Online 含め述べ 52,323 人という多くの方に参加頂きました。自動車業界のお客様を支援する私達 AWS for Automotive チームは、 AWS Industry エリアに、4つのデモンストレーションブースを構えて皆様に AWS for Automotive のソリューションを紹介致しました。デモブースで皆様とお話させて頂き、詳細な資料が欲しいというご要望を頂きましたので、本ブログでは、その４つのデモンストレーションをダウンロード頂いた資料よりも詳しく紹介していきます。 1. AWSクラウドによる自動車ソフトウエア開発の高速化 自動車業界では、CASE への対応でソフトウエアの開発量が増大しています。一方で車載のソフトウエア開発は組み込み開発であるが故に、ソフトウエア開発には評価ボードやハードウエアが必要となります。今後の自動車業界は、増え続けるソフトウエア開発を如何に効率化していくかという点が課題の１つとなっています。AWS では、自動車業界のお客様に、ハードウエアに依存せずに可能な限りAWS クラウド上でソフトウエア開発を行うお手伝いをしています。 デモ１の構成 こちらのデモンストレーションでは、EV 向けバッテリー制御を行うECU ソフトウエアの動作シミュレーションをAWS クラウド上で行っています。 Amazon EC2 インスタンス上で、The MathWorks, Inc.の MATLAB/Simulink で制御ソフトをモデリングし、シミュレーションを行います。 1で作成した Simulink モデルから AUTOSAR Classic スタック上で動作するコードを生成し、CI/CD パイプラインでビルドします。 Amazon EC2 インスタンス上で、Synopsys Silver シミュレーターを動作させ、Elektrobit Automotive GmbH のミドルウエアで、AUTOSAR Classic 準拠の仮装ECU に、ビルドしたバイナリをデプロイします。 Amazon EC2 インスタンス上で、Elektrobit Automotive GmbH のミドルウエア上で、AUTOSAR Adaptive の ECU ソフトウエアを動作させます。 Amazon EC2 インスタンス上で動作する Android OS ベースの UI アプリケーションと ECU ソフトウエアが SOME/IP で通信を行います。 UI アプリケーション上でスポーツモードの切り替えを行うと、Synopsis Silver 上の電力出力量のグラフが変化します。 AWS では、可能な限り車載ハードウエアに近い環境を AWS クラウド上に構築し、仮想的に ECU ソフトウエアを動作させることで、ハードウエア群を準備しなくて済むソフトウエア開発環境を構築し、全体での試作回数を減らすと共に、時間がかかる開発PCの調達や保守、開発ツールのインストール作業から開発者を解放し、開発者が ECU ソフトウエアの開発に専念できるよう支援します。もちろん、CI/CD パイプラインを構築することで、ビルドや静的解析、ユニットテスト、デプロイなどの作業を自動化することも可能です。 デモ２の構成 こちらのデモンストレーションでは、コックピットの ECU ソフトウエアの UI 開発を AWS クラウド上で行っています。 Rightwareの Kanzi One（UI開発用IDEツール）を AWS Gravition EC2 インスタンス上で動作させ、Nice DCV プロトコルでデモブースの Laptop PC のブラウザに表示します。 パナソニック オートモーティブシステムズ株式会社の vSkipGen を使用し、 AWS Gravition EC2 上で、メータークラスターの仮想ECUを AGL（ Automotive Grade Linux ）上で動作させる。また、同時にインフォテインメントの仮想ECUを Android OS 上で動作させます。 Kanzi One のターゲットECU として、それらの仮想ECUを指定し、Kanzi One での UI 変更をニアリアルタイムに仮想ECUに反映させることで、開発者は画面で確認しながら視認性ならびにデザイン性の高い動く UI を開発します。 コックピットの仮想ECUが動作する VPC とは別のVPC上で AUTOSAR Adaptive の仮想ECUも動作しており、 SOME/IP 通信によりコックピットの仮想ECUと通信し、車両データ（例えば車速やエンジン回転数）をコックピット仮想ECUと連携します。異なるVPC上にある仮想ECU同士を SOME/IP で通信させるためには、それぞれの仮想ECUが同一サブネット上に存在する必要があるという条件に基づき、 AWS Transit Gateway を用いて、同一ネットワーク環境を構成しています。将来、仮想ECUを連携させる時の構成の一例として提案させていただいております。 2. クラウドからエッジへ 自動運転開発サイクルを高速化するオープンソース環境 AWS は、SOAFEE , eSync Alliance , Autoware foundation といったオープンソースコミュニティとも連携し、業界全体の開発生産性向上を目指しています。本デモでは、自動運転ソフトウエアスタックの開発、シミュレーション、OTA アップデート実行時に、実機と同じネイティブコードで動くクラウド上のバーチャル車両に対してテスト・検証をしています。 今回のデモで想定しているシナリオは、自動運転 Level4 相当の自動運転車両が、路肩に停車している他の車両を認識して安全に回避するようなシナリオになります。まず、現行のバージョンのソフトウェアではうまく回避できずに、安全確保のために衝突する前に停止し続けてしまう状態から、パスプランニング修正済みのソフトウェアを AWS 上で検証し、そのソフトウエアで OTA で車両にデプロイする、という内容です。このように様々な状況を実車検証の前に AWS 上で検証できることで、多くのリアルなユースケースにおける挙動の確認ができるのではないか、と言う提案にもなっています。 デモの構成と流れ Level 4 相当の自動運転仮想車両にオープンソースソフトウェア（OSS）の自動運転ソフトウェアスタックである Autoware で実装されており、開発ツールに株式会社ティアフォーの Web.Auto を利用します。 AWS 上で、Web.Auto を使って Autoware のシナリオを修正し、新たなソースコードをビルドし、シミュレーションにより、アップデートされているかを検証します。 検証して品質が保証されたソフトウエアを、eSync Alliance の OTA のコンソーシアムが提供しているツールを使い、OTA のキャンペーンを作成し、実車の ECU に検証済みのソフトウエアをデプロイします。 AWS では、本デモのように、ソフトウエアの開発における計画、実装、シミュレーションテスト、リリース、デプロイ（OTA）という実車検証のサイクルを、可能な限り AWS クラウド上でサイクリックに実現し、車載ソフトウエア開発の効率化を支援します。クリックに実現し、車載ソフトウエア開発の効率化を支援 3. 生成AIなどを活用したAWS上での自動運転機能開発の加速 このデモでは ADAS/自動運転の開発におけるワークフローを AWS クラウド上で大規模に実現しており、特にシミュレーションや機械学習といったタスクのためのデータを準備するために利用可能なコンポーネントについて、具体的に動作するところを皆様にご覧いただきました。 デモについて 生成 AI のモデルを利用して、ラベルがない画像データに対して、自然言語で検索をして、関連する画像を抽出することができます。 下の図では、検索ボックスに、「 pedestrian crossing an intersection 」と入力し、「Search」ボタンを押下します。 すると検索結果に下の図の様に、 交差点を通行する歩行者 の画像が表示されます。 従来は、事前にラベル付されていないような画像やシーン・シナリオについては手軽に検索できませんでしたが、生成 AI を用いた手法を活用することで、ラベル付されていないデータから自然言語による検索を行って、求めるシーン・シナリオに関するデータを抽出することができます。 4. コネクテッドビークル AI解析による運転体験の最適化 このデモでは、車が路面状況を理解して、車側でその状況に応じて最適なドライビングアシスタント機能を使えるようにする機能開発を目的として、 AWS IoT FleetWise を利用し、車載カメラと CAN 情報をクラウドに収集、道路コンディションを推定するAIモデルを作成し、継続的に推論結果を活用して車載ソフトウェア改善を行うプロセスをお見せしました。 デモの流れ 車両側 AWS IoT FleetWise の新機能 Vision System Data を利用し、車載カメラから画像を収集し、その画像を元に車載側のAI 推論で検出した道路状況と CAN データから収集した道路状況が一致しない場合、車載側のAI推論のモデルを再度トレーニングするための教師データとして、車載カメラの画像データを AWS クラウドで収集します。 AWS 側では、受信データを教師データとして利用し、車載側のAI推論を再トレーニングします。 下の図は、収集したデータを Amazon QuickSight で可視化し、AI 推論の結果とカメラの画像を確認できます。これによりAI 推論を誤ってしまったカメラ画像を改めて学習することで、AI 推論の認識率を上げていくことにAWSが貢献しています。 このデモで中心となるAWSサービスが AWS IoT FleetWise になります。 AWS IoT FleetWise は新しい機能として、 Vision System Data (カメラ、レーダー、LiDAR など)を収集する仕組みを2023年の re:Invent で発表しました。これにより、CAN に流れているシグナルのデータだけではなく、カメラなどで取得した画像などのデータを収集し、活用することができるようになりました。 おわりに 今回の AWS Summit Japan では、私たち AWS for Automotive のチームが、今の自動車業界のトレンドを軸にデモンストレーションを選定しました。今まで自動車業界のお客様には、 Connected Vehicle や自動運転のための物体検知の AI 推論などで AWS を活用頂いてきましたが、自動車業界が100年に一度の変革期を迎える中、昨年から車載のソフトウエア開発環境のクラウド化を支援させて頂くことが増えてきました。その背景から、今回の Automotiveブース では、車載ソフトウエア開発のデモンストレーションの割合を増やし、ハードウエアに依存しない車載ソフトウエア開発のソリューションを多くのお客様に紹介させて頂きました。このブログをご覧になってもう少し内容を詳しく聞きたいというお客様がいらっしゃいましたら、AWSアカウントチームまでご連絡頂ければと思います。 著者 眞壽田 英輝 (Masuta, Hideki) アマゾン ウェブ サービス ジャパン 合同会社 Mobility領域のお客様を支援するソリューションアーキテクト。好きなAWSサービスはAmazon Managed Streaming for Apache Kafka (MSK)です。

6月10日週、私が以前勤務していた Standard Bank Group (SBG) がソフトウェアエンジニアリングカンファレンスを主催し、基調講演者の 1 人として私を招待してくださいました。SBG はアフリカ全土に拠点を置いており、このハイブリッドカンファレンスにはアフリカ大陸全体からほぼ 2,000 人のエンジニアが参加しました。長年の友人やかつての同僚と再会し、新しい友達ができたこのカンファレンスは、実にすばらしい経験でした。 6月10日週のリリース 6月10日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 ルートユーザーと IAM ユーザーのためのパスキー多要素認証 (MFA) – 利便性を提供し、容易な復旧を実現するため、ルートユーザーと AWS Identity and Access Management (IAM) ユーザー向けのサポート対象 多要素認証 (MFA) のリストにパスキーを追加しました。パスキーは、サービスまたはウェブサイトへの登録時にクライアントデバイス上で生成される暗号化キーのペアです。パスキーはパスワードの代わりに使用できますが、今回の初回リリースでは、パスワードに追加される 2 番目の認証要素としてパスキーを使用することにしました。 Amazon GuardDuty Malware Protection for Amazon S3 – 今週開催された AWS re:Inforce 2024 で、Amazon GuardDuty Malware Protection for Amazon Simple Storage Service (Amazon S3) の一般提供開始が発表されました。これは、GuardDuty Malware Protection の拡張機能であり、選択した S3 バケットへの悪意のあるファイルのアップロードを検出するためのものです。これには、コンピューティングインフラストラクチャを管理することなくマルウェア検出を完全に管理する能力や、組織内にあるすべての保護対象バケットのカバレッジ概要など、さまざまなメリットがあります。詳細については、 Amazon GuardDuty Malware Protection for Amazon S3 を詳しく説明する先週掲載の記事 をお読みください。 IAM Access Analyzer アップデート – 先週の AWS re:Inforce 2024 からもうひとつのすばらしいお知らせです! IAM Access Analyzer アップデートが発表されました。これは、カスタムポリシーチェックの拡張を可能にするとともに、ガイド付き失効機能も含まれています。この機能は、開発者と共有できるガイダンスを提供して、開発者が不要な許可を失効できるようにします。 私の同僚の Jeff Barr が、こちらの記事でこの機能をさらに詳しく説明しています 。 AWS のその他のニュース AWS のオープンソースに関するニュースと最新情報 – 私の同僚である Ricardo が こちらの Open Source Newsletter を毎週執筆して、AWS コミュニティからの新しいオープンソースプロジェクト、ツール、およびデモを紹介しています。 .NET 開発者コミュニティは、AWS にとって大切なコミュニティであり続けています。私の同僚である Brandon Minnick と Francois Bouteruche は、私のインスピレーションでもあります。このコミュニティをサポートする彼らは、楽しい .NET 開発者エクスペリエンスを生み出すために AWS と Azure のエンジニアリングチームが連携するという結果をもたらしました 。世界各国で開催されている NDC Conferences の一環として最近行われた NDC Oslo では、VP of Azure Developer Experience である Scott Hunter 氏が、その基調講演でこのコラボレーションについて話しました。 NDC Conferences YouTube チャンネル で公開され次第、この基調講演をぜひご覧ください。 今後の AWS イベント AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントです。お住まいの地域が南北アメリカ、アジア太平洋、日本、EMEA であるかにかかわらず、地域内で開催される 今後の AWS Summit イベントに関する情報については、こちらをご覧ください 。 AWS Community Day – この記事の冒頭で紹介したものと同様の AWS Community Day イベント で、地域のエキスパート AWS ユーザーや業界リーダーが主導するテクニカルディスカッション、ワークショップ、ハンズオンラボに参加しましょう。 スリランカにお住まいの場合は、来週この地域で開催されるイベント があります。 こちらで、 近日中に開催されるすべての対面およびバーチャルイベントを閲覧 することができます。 6月17日週のニュースは以上です。6月24日週の Weekly Roundup もお楽しみに! – Veliswa この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします。 原文は こちら です。

この記事は、software as a service (SaaS) のためのリレーショナルデータベースのスケーリングに関するシリーズの続編です。SaaS プロバイダーは、 Amazon Relational Database Service (Amazon RDS) や Amazon Aurora などのリレーショナルデータベースを一般的にソリューションで利用しています。 Part 1 では、リレーショナルデータベースアーキテクチャをスケーリングまたは最適化する一般的な方法をいくつか紹介しました。これらの方法は、 垂直スケーリング や リードレプリカによる水平スケーリング など、制限のある物理リソースのセットをスケーリングすることに焦点を当てていました。SaaS プロバイダーとしては、これらの限界を超えて成長する必要がある場合があり、そのような場合に データベースシャーディング がスケーリングメカニズムとして有効な選択肢となります。 データベースのシャーディングは複雑さを増し、一度実装すると後戻りできなくなることが多くあります。これは、シャーディングがデータモデルに明示的に組み込まれ、アプリケーションもそれに合わせて変更する必要があるためです。したがって、SaaS 運用に影響を与えるような判断をする前に、データベースをシャーディングすることの意味を理解しておく必要があります。さらに、データベースアーキテクチャが複雑になるにつれ、テナントのリクエストを正しいデータベースにルーティングする課題に直面する可能性があります。 この記事では、データベースのシャーディングと、アプリケーションがテナントのリクエストを正しいデータベースにルーティングする課題への対処方法について説明します。 更なるスケーリング 垂直スケーリングは読み取りと書き込みのパフォーマンスを向上させますが、データベースインスタンスを拡張または最適化できるサイズには上限があります。同様に、リードレプリカを使った水平スケーリングでは読み取り負荷に対してスケールアウトできますが、データベースソリューションでサポートされるリードレプリカの数に制限があります。これらの制限に近づいたり到達したりした場合、アプリケーションを拡大し続けるにはどうすればよいでしょうか。 プールやブリッジモデル では、一部のテナントがリソースを他のテナントよりも多く消費している場合、サイロストレージにテナントを移行するという選択肢があります。選択されるテナントは通常、パフォーマンス要件が最も高いテナントです。その後、既存のテナントを新しい環境に移行するメカニズムを導入する必要があります。 AWS Database Migration Service (AWS DMS) などのツールを使用すると、 この移行を自動化 できます。また、テナントとストレージを対応付ける必要があり、ソリューションとオペレーションにさらなる複雑さが加わります。 別の選択肢は、データベースのシャーディングを利用することです。これにより、パーティショニングモデルを維持しながら、顧客層の拡大に伴ってデータセットをスケールアップできます。 SaaS ソリューションにおけるデータベースのシャーディング データベースのシャーディングについては、 データベースのシャーディングとは? と Amazon Relational Database Service でのシャーディング で詳しく説明されています。この概念に詳しくない場合は、これらの参考資料を確認することをお勧めします。この記事では、SaaS 固有の側面に焦点を当てています。 データベースのシャーディングアーキテクチャを設計する際、シャードキーの選択は重要です。SaaS プロバイダーは、テナントのデータを単一のデータシャードに紐付けできるため、 tenant_id をシャードキーとして使用することが多くあります。次の図は、リレーショナルデータベースの Order テーブルを tenant_id をシャードキーとしてシャーディングする例です。 テナントのすべてのトランザクションを単一のデータシャードに紐付けると、テナントごとのパフォーマンスを改善できます。例えば、テナントのデータベースクエリでは、すべてのデータベースのすべての行を検索する必要がある場合があります。テナントを単一のデータベースに限定すると、検索される行数が減り、パフォーマンスが向上します。また、テナントに対して外部キーと JOIN を使用できるようになります。次の図は、 tenant_id をシャードキーとして使用し、複数のデータベーステーブルにわたってシャーディングされている様子を示しています。 データシャードは固有のデータベースであるため、単一のデータベース インスタンスまたはクラスターに複数のシャードを持つことができます。シャードのサイズとインスタンスあたりのシャード数は、使用事例によって異なります。たとえば、多数のシャードを管理する運用オーバーヘッドを減らすために、インスタンスごとに 1 つの大きなシャードを選択することができます。あるいは、データベースのサイズが原因で、レプリケーションやバックアップの遅延、 vacuuming などのデータベースのメンテナンスタスクの実行に問題が発生している場合は、インスタンスあたり複数の小さなシャードを選択することができます。 シャーディングのメリット シャーディングを使用すると、単一のデータベースのパフォーマンスを超えてアプリケーションをスケールアウトできます。既存のシャードのサイズ変更や、パフォーマンス問題への対応、または新規テナントのプロビジョニングに応じて、リアルタイムで新しいシャードを追加できるように、SaaS アプリケーションをアーキテクチャ設計できます。単一のテナントが単一のデータベースで提供できるパフォーマンスを超える必要がある場合、シャーディングは 1 つの解決策となります。 大規模なテナントを扱う場合、シャーディングを使ったプールモデルの方が、サイロモデルよりも運用効率が高くなります。データベースの管理数が少なくなり、新しいテナントを追加する際に新しいデータベースをプロビジョニングする必要がないため、テナントのオンボーディングが簡素化されます。 tenant_id をシャードキーとして使用することで、他の運用上の効率化も得られます。テナント分離アプローチと相性が良く、パフォーマンス問題に対処するためにテナントを新しいノードに簡単に再配置できます。これは、すべてのデータを単一のデータシャードに格納するためです。同様に、 テナント単位のバックアップと復元 では、複数のデータシャードにまたがる整合性を確保する必要がありません。 テナント ID をシャードキーとして使用する場合、シャーディングと他のデータベーススケーリングアプローチを組み合わせると、テナントのパフォーマンスがさらに向上しますが、複雑さが増します。たとえば、 テーブルパーティショニング を tenant_id に基づいて実装し、個々のテナントのパフォーマンスを対象にしたり、 データベースキャッシング を導入してシャードのパフォーマンスを改善したりできます。 シャーディングは、 cellular architecture パターンも提供します。これにより、インフラストラクチャの障害からの影響範囲が限定され、単一のテナントが他のパフォーマンスに与える影響が軽減されます。次の図は、各データベースインスタンスに最大 2 つのテナントを含む 3 つのシャードが含まれる (各シャードが個別のデータベース) アーキテクチャを示しています。この図には高可用性は示されていませんが、Aurora または Amazon RDS ではネイティブに実装されています。これらのオプションの詳細については、 高可用性と耐久性 および Amazon RDS Multi-AZ を参照してください。 シャッフルシャーディング を利用すれば、1 つの問題のあるテナントが他に与える影響をさらに軽減できます。ただし、シャードレプリケーションを管理するソリューションを導入する必要があるため、複雑さが増します。 シャーディングの課題 シャーディングは SaaS アプリケーションを非常に複雑にします。アプリケーションはすべてのシャードにわたるデータのマッピングとルーティングを処理する必要があります。ヘルパーサービスを導入することで、この複雑さを開発者から隠すことができます。この概念については、後ほど投稿内で説明します。 複数のシャードからデータを必要とするクエリでは、アプリケーションレベルでの追加エンジニアリングが必要になります。これは通常、単一のシャードを使用するクエリよりも高いレイテンシーを引き起こします。オンライン分析処理 (OLAP) のようなワークロードは、通常、全データセットに対してデータ分析を行うため、シャーディングには適していません。このような場合、両方の機能を持つために、データセットのコピーを OLAP データベースに作成することが一般的な方法です。 シャーディングを導入すると、いくつかの運用上の課題が生じます。データセットの領域が複雑になるため、サポートが難しくなる可能性があります。シャーディングされたデータセットは分散しているため監視が難しくなり、テナントを認識したコンテキスト、ログ記録、メータリングが必要になります。テナントの移行は簡単ではなく、データ保持に関する検討が必要になる可能性があります。 シャーディングされたデータセットは、時間の経過とともに偏りが生じ、データベースのホットスポットを引き起こす可能性があります。シャード間でのパフォーマンスの違いは、顧客のパフォーマンスにばらつきを生む原因となります。データを均等に分散せるためには、長期にわたってデータセット全体でテナントを継続的に再調整する必要があります。そのため、コアアーキテクチャの一部としてテナントを移行する機能が必要です。 シャード化されたアーキテクチャにオブザーバビリティを持たせる事は不可欠です。 Amazon RDS Performance Insights 、 Enhanced Monitoring 、 Amazon DevOps Guru for RDS などのツールを使用すると、データベースのパフォーマンスを可視化し、ソリューションに影響を与える可能性のある問題を特定できます。 最後に、シャード化されたアーキテクチャからシャード化されていないアーキテクチャに戻すことは難しく、相当な技術的専門知識、エンジニアリングリソース、プログラム管理が必要になります。シャード化の決定は一方通行だと考えるべきです。 これらの課題の多くは、 Amazon Aurora Limitless Database (現在 Limited Preview 中) によって解決されます。Aurora Limitless Database は、単一インスタンスの制限を超えてスケーリングできる Aurora のサーバーレスデプロイです。アプリケーションレベルのシャーディングを自分で実装する必要はありません。Aurora Limitless Database は単一のインターフェースを提示するため、アプリケーションはシングルデータベースを使用する場合とほぼ同じ方法で使用できます。Aurora Limitless Database では、アプリケーションがテナントのルーティングを処理したり、クラスターのトポロジを認識する必要はありません。Aurora Limitless Database はスキーマとキーレンジの配置を認識しており、クエリを正しいデータアクセスシャードにルーティングし、アプリケーションに返す前に結果を集約します。 シャーディングのタイミングとシャーディングへのアプローチ シャーディングの主な利点は、単一の物理データベースを超えてスケーリングできることです。現代のデータベースはリソースが増え続けているため、一般的にはその他のスケーリングアプローチが機能しなくなった場合にのみシャーディングを検討します。1 つのユースケースとして、データベースの物理的な限界に達したサイロモデルのテナントで、他の方法でスケーリングできない場合が考えられます。あるいは、データベースエンジンのパフォーマンスが限界に達しても、既存のパーティショニングモデルを維持したい場合もあるでしょう。SaaS アプリケーションのリレーショナルデータベースのパフォーマンスを改善する他の方法については、このシリーズの Part 1 をお読みください。 別のシャーディングのユースケースは、大規模環境での運用効率化です。多くのテナントが存在する場合、サイロモデルでこれらのテナントを管理することは、プールモデルほどのコスト効率性は得られませんが、シャーディングされたプールモデルと同じくらい運用が複雑になる可能性があります。たとえば、16 の データベースシャードにまたがる 400 のテナントを管理する方が、400 の個別のデータベースを管理するよりも簡単かもしれません。 レジリエンシーのためにシャーディングを検討することもできます。データベースアーキテクチャは多くのテナントをサポートできる可能性があります。しかし、データベース障害の影響が事業リスクとして大きすぎる場合があります。シャードの物理的な分離により、データベース障害の影響範囲が小さくなります。また、レプリケーションにより、障害発生時にセカンダリシャードからデータを利用できるようになります。 データセットをシャーディングすることを決めた場合は、どのようにシャーディングするか、何をシャーディングするかを評価する必要があります。データセットを複数のセットに分割し、シャーディングが必要な部分のみをシャーディングすることができるかもしれません。SaaS アプリケーションの機能とテナントの使用パターンを評価し、データセットのどの部分をシャーディングするのが適切かを判断してください。その上で、データセットの一部を分割し、シャーディングしてください。 複雑なデータセットにおけるデータベースリクエストのルーティング 独自のシャーディングソリューションを実装する場合、アプリケーションはデータベースへのリクエストをどこにルーティングするかを知る必要があります。データセットを複数のデータベースシャードやパーティショニングモデル (プレミアム層のサイロモデルと標準層のプールモデルなど) に分散させると、これが難しくなります。 アプリケーションには、テナントデータがどこにあるかを追跡するために、各テナントをデータベースインスタンスにマッピングするインデックスが必要です。新しいテナントをオンボーディングしたり、既存のテナントをシャードやパーティションモデル間で移行する際には、このインデックスを更新する必要があります。また、新しいテナントをどのシャードに配置するかを決定するメカニズムが必要になる可能性があります。 このインデックスの管理とクエリを行うヘルパーサービスとして、データアクセスマネージャーを実装できます。これにより、開発者からデータセットの複雑さを隠蔽し、アプリケーションを変更することなく将来的にデータセットのアーキテクチャを変更できます。リレーショナルデータベースの管理に限定されず、アプリケーション用のすべてのデータセットをインデックス化およびマッピングできます。 次の図は、データアクセスマネージャーのアーキテクチャ例を示しています。 この例では: JSON Web トークン ( JWT ) が SaaS アプリケーションを通して渡され、 テナントコンテキスト が含まれています。 JWT をデータアクセスマネージャーに渡し、JWT マネージャーを呼び出します。 JWT マネージャーは JWT を検査し、 tenant_id フィールドを返します。 データアクセスマネージャーは、 Amazon DynamoDB テーブルに格納されたマッピングを使用して、 tenant_id を正しいデータベースインスタンスにマッピングします。 データベースの詳細がアプリケーションに返却されます。 アプリケーションは、正しいデータベースインスタンスに接続します。 マッピングテーブルには DynamoDB を使用しています。これは、マッピングデータを格納するための経済的でスケーラブルなソリューションを提供するためです。このマッピングデータはアプリケーション内のすべてのサービスやマイクロサービスで使用される可能性があるため、パフォーマンスのボトルネックにならないことが重要です。DynamoDB は、クエリごとに単一のアイテムのみが返されるこのようなキーバリュー型のアクセスパターンに適しています。複数のサービスが、バックエンドにある異なるデータベースを使用しながらこのシャーディングモデルを利用する場合は、 service_id 属性を追加し、 複合プライマリキー を作成することで、この例のアーキテクチャを拡張できます。さらに、このデータはかなり静的であると予想されるため、 キャッシング層 を導入して DynamoDB への呼び出し回数を減らすこともできます。 Aurora Limitless Database を使用すると、このようなルーティングの複雑さは解消されます。Aurora Limitless Database には、選択したシャードキー (例: tenant_id ) に基づいて、クエリを正しいデータアクセスシャードにルーティングするルーターインスタンス群が含まれています。そのため、アプリケーションは、クエリの一部として tenant_id を指定し、単一のシャードグループエンドポイントにアクセスするだけで済みます。Aurora Limitless Database の詳細については、 Join the preview of Amazon Aurora Limitless Database をご覧ください。次の図は、Aurora Limitless Database のアーキテクチャを示しています。 結論 この投稿では、SaaS アプリケーション内のリレーショナルデータベースをスケーリングする選択肢としてのシャーディングと、データルーティングを処理するためのデータアクセスマネージャーの概念について説明しました。 リレーショナルデータベースをシャーディングすると、SaaS アプリケーションにアーキテクチャ上および運用上の複雑さが生じます。シャーディングされたアーキテクチャを実装することのトレードオフを検討し、それが自分のユースケースに最適なものであることを確認する必要があります。シャーディングが提供するパフォーマンス上の利点は、別のスケーリング戦略でも得られる可能性があります。 複数のスケーリング戦略を組み合わせ、シャーディングを選択することもできます。SaaS 導入における正しい判断は、チームの既存の知識を活かしてソリューションを運用し続けることかもしれません。既存のテクノロジースタックを維持することで、将来的によりスケーラブルなテクノロジーに移行する前に、他の成長分野に注力できます。 シャーディングを実装することにした場合は、アプリケーションのルーティングの複雑さを軽減し、スケーリングとメンテナンス作業を簡素化するために、Aurora Limitless Database などのマネージドなシャーディングソリューションを検討する必要があります。 スケーリング戦略を本番環境に導入する前に、十分にテストすることが重要です。スケーリングアプローチを設計する際は、スケーリングメカニズムのパフォーマンスを可視化し、期待したスケーリング目標に達しているかを検証するための運用メトリクスを実装する必要があります。 AWS SaaS ファクトリーについて AWS SaaS Factory は、SaaS ジャーニーのあらゆる段階にある組織を支援します。新製品の構築、既存アプリケーションの移行、または AWS 上での SaaS ソリューションの最適化を検討している場合でも、お手伝いできます。 AWS SaaS Factory Insights Hub にアクセスして、さらに多くの技術的およびビジネス的なコンテンツとベストプラクティスを見つけてください。 SaaS ビルダーは、アカウント担当者に連絡して、エンゲージメントモデルについて問い合わせ、AWS SaaS Factory チームと協力することを推奨します。 著者について aaaaaaaaa Dave Roberts は、シニアソリューションアーキテクトであり、AWS SaaS Factory チームのメンバーです。AWS 上で SaaS 製品を構築する AWS パートナーを支援しています。SaaS について話していないときは、ギターエフェクトペダルを作ったり、家族と森で時間を過ごすことを楽しんでいます。 Josh Hart は、Amazon Web Services のプリンシパルソリューションアーキテクトです。彼は英国の ISV 顧客と協力し、AWS 上で SaaS アプリケーションを構築およびモダナイズするのを支援しています。 翻訳はソリューションアーキテクトの「藤川 貞信」が担当しました。 原文 はこちらです。

ビジネスが成長するにつれて、SaaS (Software as a Service) プロバイダーが直面する課題の 1 つは、 テナント のエクスペリエンスをどのように維持するかです。これには、テナントベースが拡大するにつれて、許容できるパフォーマンスとレスポンスタイムを確保することが含まれます。 Amazon Relational Database Service (Amazon RDS) や Amazon Aurora などのリレーショナルデータベースは、一般的に SaaS プロバイダーによって使用されています。ビジネスが成長するにつれて、データベースのスケーリング方法も決定する必要があります。 SaaS ビルダーとしての課題は、 SaaS ジャーニー の段階に応じて、どのスケーリングメカニズムが適切かを決定することです。アプリケーションが成長するにつれて、既存のソリューションがニーズを満たさなくなった場合、データベースアーキテクチャを変更する必要が生じる可能性があります。新しいテクノロジーやアーキテクチャパターンを実装すると、成長の推進やコア事業への投資から注力が逸れてしまうことがあります。新しいテクノロジーやアーキテクチャに移行するよりも、チームの知識を維持するために既存のアーキテクチャを最適化する方が有益な場合もあります。 このシリーズでは、既存のリレーショナルデータベースを持つ SaaS プロバイダーに対し、効果的にスケーリングする方法のガイダンスを提供します。Part 1 では、SaaS の観点から一般的なリレーショナルデータベースのスケーリングパターンの利点を探り、SaaS ソリューションに適したスケーリングアプローチを選択し、さらなる検討の出発点とするための情報を提供します。 Part 2 では、シャーディングとテナントルーティングについて説明します。 データベーススケーリングと SaaS パーティショニングモデル データベースのスケーリングの説明に入る前に、SaaS の データ分割 モデルを理解することが重要です。利用できる 3 つの高レベルな SaaS 分割モデル は、 サイロ 、 ブリッジ 、 プール です。 サイロモデル – 各テナントが物理リソース (テナントごとのデータベースインスタンスなど) を個別に持っています ブリッジモデル – テナントは物理リソースを共有しますが、論理的に分離されています (テナントごとのテーブルやスキーマなど) プールモデル – テナントは物理リソースと論理リソースを共有します。たとえば、シングルな共有テーブルです SaaS ソリューションは多くのテナントとそのユーザーのデータをサポートし、ビジネスが成長するにつれてデータも拡張する必要があります。シングルデータベースは最終的にパフォーマンスのボトルネックになる可能性があるため、どのようなスケーリングオプションがあるかを理解しておく必要があります。 リレーショナルデータベースのスケーリングは、大まかに次の 3 つのカテゴリに分類できます。 物理リソース – まず、リードレプリカやシャーディング (このシリーズの Part 2 で解説) によってスケールアウトすることで、データセットの物理リソースを増やすことができます。 データベース操作 – 次に、より適切なインデックス作成やデータモデルの変更などの手法で、データベース操作を最適化できます。 データベースアーキテクチャ – 最後に、データセット全体または一部のデータベースアーキテクチャを変更することができます。これには、 purpose-built データベース の利用、 キャッシングメカニズム の追加、または非同期プロセスの作成や Command Query Responsibility Separation (CQRS) パターン の実装などの大規模なアーキテクチャ変更が含まれます。このアプローチについては、「 Modernize legacy databases using event sourcing and CQRS with AWS DMS 」でより詳しく説明されています。 スケーリングメカニズムを組み合わせることで、最良の結果が得られることが多く、特定のパーティション分割モデルや使用パターンに適したスケーリングパターンがあります。このシリーズを通して、これらの違いを検討していきます。 物理リソースの追加による既存アーキテクチャのスケーリング SaaS プロバイダーがリレーショナルデータベースをスケーリングする際の最初のアプローチは、通常、物理リソースを増やすことです。物理リソースをどこまで拡張できるかには上限がありますが、それまでは、インフラストラクチャのコストが高くなる一方で、コアビジネス目標からリソースを奪うようなアーキテクチャの変更を行わずに、データベースを拡張する効果的な方法です。 垂直スケーリング SaaS プロバイダーは、最初のスケーリングアプローチとして一般的に 垂直スケーリング を選択します。より多くの物理リソース (CPU、メモリ、ネットワーク) を提供することで、より多くの同時接続をサポートできるようになります。既存のパーティション分割モデルを維持したまま、接続設定を変更せずにデータベースをインプレースでスケーリングできます。Amazon RDS では、新しいインスタンスタイプを選択することで、利用可能なあらゆるインスタンスサイズにリソースを垂直にスケーリングできます。これによりインスタンスが再起動され、わずかなダウンタイムが発生しますが、 Amazon Aurora Serverless v2 では、サービス中断なしで スケールアップとスケールダウン ができるため、可変のデータベースワークロードを持つ SaaS プロバイダーに適しています。 サイロモデルでは、SaaS 以外のアプリケーションのスケーリングと比べて、SaaS 固有の違いはありません。ただし、ブリッジモデルとプールモデルでは、スケーリングの要因を評価し、潜在的なリスクを検討する必要があります。より多くのテナントを追加するためにスケーリングすると、 ノイジーネイバー やインフラストラクチャの障害など、パフォーマンスに影響を与えるイベントの影響範囲が広がります。同様に、シングルテナントが他のテナントの可用性に影響を与えるためにスケーリングが必要な場合は、テナントのパフォーマンスをスロットリングするか、そのようなテナントをサイロデータベースに移行することで、サービスと運用体験が向上するかどうかを検討してください。 リードレプリカによる水平スケーリング 読み取りの負荷問題を解決する必要がある場合、 リードレプリカ を使用することで、データ分割モデルを変更することなく、パフォーマンスを向上させることができます。これには他の利点もあります。例えば、RDS リードレプリカを スタンドアロンインスタンスに昇格 したり、 Aurora ストレージボリュームを新しいクラスターにクローン したりすることで、可用性を高めたり、データベースのシャーディングを容易にしたりできます。Aurora クラスターには、ボタンをクリックするだけで 最大 15 のリードレプリカ を設定できます。さらに、Aurora リードレプリカはストレージ層のレプリケーションを使用するため、従来のレプリケーションアプローチと比べて、プライマリへのパフォーマンス影響が少なくなります。 目的に応じて複数のリードレプリカを作成することができます。プライマリインスタンスを使用するサービスに影響を与えることなく、読み取り操作に基づく追加のサービス機能を SaaS 製品に導入できます。これらのアクティビティを様々なインスタンスタイプで実行することで、運用コストを削減できる可能性があります。 リードレプリカの追加や削除は、ダウンタイムを必要としません。Aurora で Aurora レプリカでの Auto Scaling を有効にすれば、リードレプリカのスケーリングを自動的に管理できるため、運用の複雑さを軽減できます。 既存アーキテクチャの最適化 データベースのパフォーマンスを拡張する別の方法は、パーティショニングモデルを変更せずに、既存アーキテクチャを最適化してデータベース効率を改善することです。これにより、スケーリングの必要性を遅らせたり、パフォーマンスの向上によりテナントのサービス体験を改善できます。各最適化アプローチは特定のユースケースに対応しているため、製品にどのアプローチが適用できるかを理解することが重要です。 マイクロバッチ処理 データベースリクエストには、それぞれパフォーマンスのオーバーヘッドが伴います。多くのユーザーが頻繁にリクエストを行う SaaS アプリケーションの場合、同時に多数のリクエストを処理するオーバーヘッドの累積によって、データベースのパフォーマンスが低下する可能性があります。類似のリクエストを マイクロバッチ と呼ばれるパターンでまとめることで、このインパクトを軽減できます。 この手法は、多くのユーザーが頻繁に小さなリクエストを行う場合、すべてのパーティション分割モデルで効果的です。特にプールモデルでは、データベースインスタンスあたりのテナントをさらに多く収容できるため、運用効率がさらに向上します。 運用の複雑さが高まるマイクロバッチ処理を扱うソリューションを作成する必要がある場合があります。次の例では、アプリケーションがデータベースに直接書き込むのではなく、 Amazon Simple Queue Service (Amazon SQS) キューに書き込みます。その後、 AWS Lambda 関数がこの SQS キューをポーリングし、メッセージバッチを消費して、結果整合性というコストを払って、データベースに原子的に書き込みます。 データベーステーブルのパーティショニング ほとんどのリレーショナルデータベースでは、論理的に大きなデータベーステーブルを小さな物理的なパーティションに分割するテーブルパーティショニングがサポートされています。パーティション内のデータにアクセスする際、探しているデータを見つけるために親テーブル全体を検索する必要はありません。これは、SaaS アプリケーションが大規模なマルチテナントデータセットを使用するプールモデルにおいて有益です。 テーブルパーティショニング は、日付やテナント ID などのパーティションキーを使ってテーブルを分割します。データベースエンジンによって、パーティションキーに対するレンジ、指定されたキーのリスト、ハッシュ値を使ってテーブルパーティショニングを行えます。ルートテーブルはそのままアクセス可能で、テーブルパーティショニングを活用するためにクエリを再設計する必要はありません。 tenant_id をプールモデルのパーティションキーとして使用することで、アプリケーションコードを再設計することなく、テナント固有のクエリのパフォーマンスを向上させることができます。実装例を次の図に示します。 テーブルのパーティショニングを tenant_id でシングルな物理リソースを超えてスケールさせるには、 データベースシャーディング の概念を拡張する必要があります。このシリーズの Part 2 でこの点を詳しく説明します。 データベーステーブルのパーティショニングでは、シングルパーティションがパフォーマンスのボトルネックになり、再調整が必要になるホットスポットが発生する可能性があります。また、パーティションを管理するための運用オーバーヘッドも発生します。 Amazon RDS for PostgreSQL または Amazon Aurora PostgreSQL-Compatible Edition を使用している場合は、PostgreSQL の pg_partman 拡張機能を使用して テーブルパーティションの作成と管理を自動化 できます。選択したデータベースエンジンのパーティション制限と、メンテナンス操作を実行する際のロック動作を考慮する必要があります。なぜなら、多くのテナントが同じデータベースを共有している場合に適さない可能性があるからです。環境に変更を加える場合と同様に、期待した結果が得られていることを監視し、変化に応じて適宜調整してください。 データの集約 SaaS プロバイダーは、多くの場合、テナントに分析的な洞察を提供するために、データセット上でユーザーごとまたはテナントごとの集計を行います。メトリクスやメータリングのため、またはデータセットのマルチテナントパフォーマンスを向上させるために、テナントごとまたはテナント間の集計を行うことができます。これにより、データベースが OLTP (オンライン トランザクション処理) と OLAP (オンライン分析処理) の両方のクエリに対応する必要が生じる可能性があります。 データセット全体で集計を行う読み取りクエリを実行すると、コストがかかり、テナントに影響を与える可能性があります。このアクティビティが予測できない場合、テナントのパフォーマンスを一定レベルに維持することが難しくなり、サービス体験が低下する可能性があります。この影響は、ブリッジモデルとプールモデルの方が大きく、複数のテナントが同じ物理データベースリソースを共有し、集計アクティビティの競合が発生する可能性があります。 サービス提供に、これらの集計アクティビティからのリアルタイムデータが不要な場合は、結果を事前に計算しておくことができます。たとえば、テナントデータの生成と分析を、オンデマンドで計算するのではなく 3 時間ごとに行うことができます。これにより、データベースのパフォーマンスが均一になり、結果が即座に利用できるようになるため、テナントのサービス体験が向上します。 RDS for PostgreSQL または Aurora PostgreSQL データベース上で pg_cron を使用 して、このアクティビティを自動化することもできます。これらの結果を配信するためにリードレプリカを使用すれば、さらにパフォーマンスが向上します。 さらに、 Amazon Redshift などのデータウェアハウスに分析クエリをオフロードすることができます。 Aurora と Amazon Redshift 間のZero-ETL integration により、トランザクションデータベースと分析データベース間でデータをニアリアルタイムに自動的に同期できるため、複雑なデータパイプラインを開発する必要がありません。 ユースケースを評価して、計算前のプロセスを維持することによるオーバーヘッドに見合う価値があるかどうかを検証する必要があります。データアクセスパターンがそのような集計を実行することがほとんどない場合、作業に見合う恩恵は得られない可能性が高いです。 データベース接続のスケーリング データベースには、利用可能な同時接続数に制限があり、テナントの数に応じて接続数が増加するため、ブリッジまたはプールのデプロイメントモデルを使用すると、この制限に達する可能性があります。これにより、タイムアウトやパフォーマンスの不安定化が発生する可能性があります。 Amazon RDS Proxy などのデータベースプロキシを実装すると、データベース接続をプールして共有できるため、データベースをさらにスケーリングできます。RDS Proxy のパフォーマンス特性の詳細については、 Build and load test a multi-tenant SaaS database proxy solution with Amazon RDS Proxy を参照してください。または、 RDS Data API のようなデータベースへの接続レスインターフェイスを検討してください。 Purpose-built データベース の導入 成長に合わせてデータベースのパフォーマンスを維持するには、特定のユースケースに最適化するためにデータベース アーキテクチャを変更する必要がある場合があります。この課題に対処する 1 つの方法は、同じデータベース内に個別の論理スキーマを使用し、それぞれを別のユースケースに最適化することです。 SaaS アプリケーションの機能が発展するにつれて、1 つのデータセットを複数に分割することが有益な場合があります。個々のアクセスパターンを分離し、purpose-built データベース に移行できます。複数の異なるアクセスパターンを最適化しようとして、最小公倍数に落ち着くのではなく、代わりにアクセスパターンをデータベース技術に合わせ、そのアクセスパターン専用に最適化することで、 適切な作業に適したツールを選択 するのです。 例えば、高スループットのトランザクションデータ用に対してや、テナント管理用のキーバリューストアとして Amazon DynamoDB のような NoSQL データベースを使用します。集計アクティビティで使用されるデータを分離するために Amazon Redshift のようなデータウェアハウスを使用し、より高いパフォーマンスレベルが必要なテナントに新しいサービス層を導入できます。既存のリレーショナルデータベースでは実装が難しい、 Amazon Neptune を使った 不正検知 などの新機能を導入し、既存の SaaS 製品に新しい市場を獲得することもできます。 Purpose-built データベースを導入すると、テナント分離の実装方法が変わり、パーティション分割モデルを再評価する必要が生じる可能性があります。パーティション分割モデルを維持できる場合でも、テナント分離の実装方法は異なる可能性があります。新しいデータベース技術を評価する際は、この点を考慮する必要があります。 詳細については、 AWS Well-Architected フレームワーク 、特にパフォーマンスの柱における データベースアーキテクチャの選択 、および データ分析レンズ の指針に従うことをお勧めします。 データベーススケーリングアプローチの検証 スケーリングアプローチがあなたの期待に沿っているかどうかを十分にテストおよび検証する必要があります。 メトリクス は、これらの判断のためのデータを提供する上で重要な役割を果たします。たとえば、 Amazon RDS Performance Insights を使用して、簡単で自動化された方法でデータベースのパフォーマンスメトリクスを監視したり、 Enhanced Monitoring を有効にして、Amazon RDS コンソールから RDS データベースインスタンスのすべてのシステムメトリクスを表示することができます。スケーリングが期待どおりに機能していないときや、新しいスケーリングメカニズムが必要なときを特定するために、運用管理タスクにパフォーマンスメトリクスを実装することを目指してください。 結論 SaaS アプリケーションの成長に伴い、データベースアーキテクチャも進化していきます。SaaS ジャーニーの中で、既存のアーキテクチャを拡張するか、要件の増大に合わせてアーキテクチャを変更するかを決める必要があります。判断の根拠にはメトリクスを用い、スケーリングアプローチが効果的であることを検証し、さらなるスケーリング手法が必要になったタイミングを把握できるようにしてください。 この投稿では、リレーショナルデータベースのスケーリングアプローチをいくつか取り上げ、SaaS アプリケーションとの関係を説明しました。これにより、リレーショナルデータベースのスケーリング方法を適切に判断できるようになります。 Part 2 では、データベースのシャーディングと、テナントをそれぞれのデータセットにルーティングする方法について調査します。 AWS SaaS ファクトリーについて AWS SaaS Factory は、SaaS ジャーニーのあらゆる段階にある組織を支援します。新製品の構築、既存アプリケーションの移行、または AWS 上での SaaS ソリューションの最適化を検討している場合でも、お手伝いできます。 AWS SaaS Factory Insights Hub にアクセスして、さらに多くの技術的およびビジネス的なコンテンツとベストプラクティスを見つけてください。 AWS SaaS Factory チームと協力し、エンゲージメントモデルについてお問い合わせいただくよう、アカウント担当者にご連絡いただくことをお勧めします。 著者について aaaaaaaaaaaaaa Dave Roberts は、シニアソリューションアーキテクトであり、AWS SaaS Factory チームのメンバーです。AWS 上で SaaS 製品を構築する AWS パートナーを支援しています。SaaS について話していないときは、ギターエフェクトペダルを作ったり、家族と森で時間を過ごすことを楽しんでいます。 Josh Hart は、Amazon Web Services のプリンシパルソリューションアーキテクトです。彼は英国の ISV 顧客と協力し、AWS 上で SaaS アプリケーションを構築およびモダナイズするのを支援しています。 翻訳はソリューションアーキテクトの「藤川 貞信」が担当しました。原文は こちら です。

6月11日、2025 年初頭までに新しい AWS リージョンが台湾に導入されることを発表しました。新しい AWS アジア太平洋（台北）リージョンは、ローンチ時に3つのアベイラビリティゾーンで構成され、台湾の AWS のお客様に、台湾に残す必要があるワークロードの実行とデータの保存を可能にします。 各アベイラビリティーゾーンは、リージョン内の他のゾーンから物理的に独立しています。低レイテンシーを必要とするアプリケーションをサポートするのに十分な距離でありながら、アベイラビリティゾーンレベルのイベントが事業継続に影響を与えるリスクを大幅に低減するのに十分な距離です。 このリージョンのアベイラビリティーゾーンは、完全冗長の専用ファイバーを介した高帯域幅、低レイテンシーのネットワーク接続を介して接続されます。この接続は、可用性または冗長性のためにアベイラビリティーゾーン間の同期レプリケーションを必要とするアプリケーションをサポートします。リージョンと AZ の設計と構築方法の詳細については、 AWS グローバルインフラストラクチャ のページをご覧ください。 現在、 マレーシア 、 メキシコ 、 ニュージーランド 、 サウジアラビア王国 、 タイ 、 AWS European Sovereign Cloud のリージョンに取り組んでいます。AWS クラウドは世界中の 33 の AWS リージョンで 105 のアベイラビリティーゾーンを運用しており、さらに 21 のアベイラビリティーゾーンと、台湾を含むさらに 7 つのリージョンの計画が発表されています。 台湾の AWS AWS は 10 年以上にわたり、台湾のお客様やパートナーに投資し、サポートしてきました。台湾のお客様をサポートするために、 台北オフィス には事業開発チーム、ソリューションアーキテクト、パートナーマネージャー、専門サービスコンサルタント、サポートスタッフなど、さまざまな役職があります。 その他の AWS インフラストラクチャには、 Amazon CloudFront のエッジロケーション が 2 つあり、複数の冗長化海底ケーブルを通じて AWS グローバルバックボーンにアクセスできます。Chief Telecom と Chunghwa Telecom が運営する台北の AWS Direct Connect ロケーション から、他の AWS リージョン (北京と寧夏を除く) にアクセスできます。AWS Direct Connect では、以前はインターネット経由で転送されていたデータが、お客様の施設と AWS の間のプライベートネットワーク接続を介して配信されます。 台湾でも AWS Outposts を利用できます。これは、ほぼすべてのオンプレミスまたはエッジロケーションに AWS インフラストラクチャとサービスを提供するフルマネージドソリューションのファミリーで、真に一貫したハイブリッドエクスペリエンスを実現します。台北の AWS Local Zones では、1 桁ミリ秒のレイテンシーを必要とするアプリケーションをエンドユーザーに配信できます。 AWS は、 AWS Academy 、 AWS Educate 、 AWS Skill Builder などのサービスを通じて、台湾の学生、現地の開発者や技術専門家、非技術専門家、次世代 IT リーダーのスキルアップに引き続き投資しています。2017 年以来、AWS はアジア太平洋地域と日本地域全体で 800 万人以上の人々にクラウドスキルのトレーニングを行ってきました。その中には、台湾の 10 万人以上が参加しています。 詳細は、7 月に開催される AWS Summit 2024 Taiwan 、クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する対面イベントに参加しましょう。 台湾の AWS のお客様 台湾の AWS のお客様は、アプリケーションを AWS に移行し、テクノロジーインフラストラクチャを世界中の他の AWS リージョンで運用することが増えています。この新しい AWS リージョンの追加により、お客様はエンドユーザーにさらに低いレイテンシーを提供し、生成人工知能 (生成 AI)、モノのインターネット (IoT)、モバイルサービスなどの高度なテクノロジーを使用してイノベーションを推進できるようになります。このリージョンにより、AWS のお客様は台湾でワークロードを実行してコンテンツを保存できるようになります。 AWS を使用してイノベーションを推進しているお客様の例をいくつかご紹介します。 Chunghwa Telecom は台湾最大の総合通信事業者です。AI データのセキュリティとガバナンスを向上させるために、ソフトウェア開発ライフサイクルの仕様書の自動生成やカスタムマーケティングキャンペーンの作成など、さまざまな生成 AI アプリケーションに Amazon Bedrock を使用しています。Amazon Bedrock を使用することで、Chunghwa Telecom は開発者の時間を節約し、没入型のインタラクティブなバーチャル英語教師を初めて開発しました。 Gamania Group は、台湾におけるオンラインゲームの開発と公開におけるリーダーです。AWS 上で実行することの価値を最大化するために、彼らは AWS Training and Certification と協力して、 AWS Classroom トレーニング、 AWS Well-Architected フレームワーク、 AWS GameDay イベントなど、全部門にわたって AWS スキルを強化しました。その結果、重要な運用上の意思決定に必要な時間を 50% 短縮し、市場投入までの時間を最大 70% 短縮し、新しいゲームのローンチを加速しました。 KKCompany Technologies は、台湾で音楽ストリーミングプラットフォーム、AIを活用したストリーミングソリューション、クラウドインテリジェンスサービスを構築しているマルチメディアテクノロジーグループです。同社は、台湾と日本の企業向けの生成 AI、マルチメディアテクノロジー、デジタルトランスフォーメーションコンサルティングサービスを専門としています。クラウドベースのストリーミングソリューションである BlendVision は AWS Marketplace にあります。 台湾のお客様事例の詳細については、 英語版の AWS Customer Success Stories または 繁体字中国語のページ をご覧ください。 引き続きご期待ください このリージョンとその他のリージョンについては、今後のブログ記事でお知らせしますので、ご期待ください！ 詳細については、 繁体字中国語 の「 台湾の AWS リージョン 」ページをご覧ください。 – Channy 原文は こちら です。

時々、技術リーダーから、生成 AI アプリケーションの可視性とガバナンスを改善したいという話を聞きます。セキュリティ、耐障害性、プライバシー、正確性に関する問題に対処したり、責任ある AI のベストプラクティスに照らして検証したりするために、データの使用と生成をどのように監視および管理していますか? 実装段階でこれらを考慮に入れるだけでなく、長期的なオブザーバビリティを維持し、ソフトウェアのライフサイクル全体にわたってコンプライアンスチェックを実施するにはどうすればよいでしょうか? 6月11日、 AWS Audit Manager で AWS Audit Manager の生成 AI ベストプラクティスフレームワークのアップデートを開始します。このフレームワークにより、エビデンスの収集が簡素化され、ベストプラクティス要件を実装するように事前設定された 110 の標準コントロールを通じて、生成 AI ワークロードのコンプライアンス体制を継続的に監査および監視できます。例としては、トレーニングモデルのために使用される前に匿名化されていなかった可能性のある個人を特定できる情報 (PII) データを可視化したり、使用されているデータセットにアクセスするために多要素認証 (MFA) が強制されていることを確認したり、カスタマイズされたモデルのバックアップバージョンを定期的にテストしてシステム停止前に信頼性が高いことを確認したりすることが挙げられます。これらのコントロールは、 AWS Config と AWS Security Hub からコンプライアンスチェックを行い、 AWS CloudTrail からユーザーアクティビティログを収集し、関連する AWS サービスへのアプリケーションプログラミングインターフェイス (API) 呼び出しを行って設定データを取得することでタスクを実行します。そのレベルの柔軟性が必要な場合は、独自のカスタムコントロールを作成することもできます。 以前は、v1 に含まれていた標準コントロールは、 Amazon Bedrock で動作するように事前設定されていましたが、この新しいバージョンでは、 Amazon SageMaker もデータソースとして含まれているため、Amazon Bedrock と Amazon SageMaker の両方での生成 AI ワークロードをより少ない労力でより厳密に制御および可視化できます。 生成 AI ワークロードに対してベストプラクティスを実施する 「AWS 生成 AI ベストプラクティスフレームワーク v2」に含まれる標準コントロールは、正確性、公平性、プライバシー、耐障害性、責任、安全、セキュリティ、そして持続可能性といったドメインにまとめられています。 コントロールは、自動チェックまたは手動チェック、あるいはその両方を実行することができます。例えば、モデルの精度を長期にわたって定期的に確認することを対象とするコントロールがあります。 Amazon Bedrock と SageMaker の API を呼び出して、関連するモデルのリストを自動的に取得しますが、その場合は、それぞれのモデルについてレビューが行われたことを示すエビデンスを特定の時期に手動でアップロードする必要があります。 コントロールを含めたり除外したり、定義済みのコントロールをカスタマイズしたりして、フレームワークをカスタマイズすることもできます。これは、さまざまな国の規制に合わせてフレームワークを調整したり、経時的に変化する規制に応じて更新したりする必要がある場合に非常に役立ちます。独自のコントロールをゼロから作成することもできますが、時間を節約できるので、最初に Audit Manager コントロールライブラリを検索して、開始点として使用するのに適した、またはそれに近いものを探すことをお勧めします。 共通コントロール、標準コントロール、カスタムコントロールを参照および検索できるコントロールライブラリ。 開始するには、まず評価を作成する必要があります。このプロセスを順に見ていきましょう。 ステップ 1 – 評価の詳細 まず、AWS マネジメントコンソールの Audit Manager に移動し、[Assessments] (評価) を選択します。[Create assessment] (評価を作成) を選択すると、設定プロセスに移動します。 評価に名前を付けてください。必要に応じて説明を追加することもできます。 この評価の名前を選択し、必要に応じて説明を追加します。 次に、Audit Manager が生成した評価レポートを保存する Amazon Simple Storage Service (S3) バケットを選択します。ただし、評価と同じ AWS リージョンのバケットを選択する必要はありませんが、選択することをおすすめします。選択した場合、評価では最大 22,000 件のエビデンス項目を収集できますが、クロスリージョンバケットを使用する場合、そのクォータは 3,500 項目に大幅に減少します。 AWS Audit Manager がレポートを保存できる S3 バケットを選択します。 次に、使用するフレームワークを選択する必要があります。フレームワークは、そのすべてのコントロールを評価に使用できるようにするテンプレートとして効果的に機能します。 今回は、「AWS 生成 AI ベストプラクティスフレームワーク v2」フレームワークを使用したいと考えています。検索ボックスを使用し、ポップアップ表示された一致する結果をクリックしてフィルターを有効にします。 検索ボックスを使用して「AWS 生成 AI ベストプラクティスフレームワーク V2」を検索する 次に、フレームワークのカードが表示されます。必要に応じてフレームワークのタイトルを選択し、フレームワークの詳細を確認したり、含まれているすべてのコントロールを参照したりできます。 カード内のラジオボタンをクリックして選択します。 ラジオボタンをチェックしてフレームワークを選択します。 これで、評価にタグを付けることができるようになりました。他のリソースと同様に、わかりやすいメタデータをタグ付けすることをお勧めします。そのためので、ガイダンスが必要な場合は、「 AWS リソースのタグ付けのベストプラクティス 」を確認してください。 ステップ 2 – 対象範囲内の AWS アカウントを指定する これは非常にわかりやすい画面です。評価のコントロールで継続的に評価することを希望する AWS アカウントを選択するだけです。デフォルトでは、現在使用している AWS アカウントが表示されます。Audit Manager は、複数のアカウントに対して評価を実行し、レポートを 1 つの AWS アカウントに統合することをサポートしていますが、この機能を使用する場合は、まず AWS Organizations との統合を明示的に有効にする 必要があります。 評価に含める AWS アカウントを選択します。 リストに表示されている自分のアカウントを選択し、[Next] (次へ) をクリックします ステップ 3 – 監査所有者を指定する あとは、この評価を使用および管理するための完全な許可を持つ必要のある IAM ユーザーを選択するだけです。これは文字通り簡単な作業です。 Identity and Access Management (IAM) のリストからユーザーまたは利用可能なロールを選択するか、ボックスを使って検索します。AWSAuditManagerAdministratorAccess ポリシーを使用することをお勧めします。 たとえそれが自分自身であっても、少なくともユーザーを 1 人選択する必要があります。このチュートリアルでもそのようにしています。 この評価に対して完全な許可を持ち、所有者として行動する IAM ユーザーまたはロールを選択します。 ステップ 4 – 確認して作成する あとは、選択内容を確認し、[Create assessment] (評価を作成) をクリックしてプロセスを完了するだけです。 評価が作成されると、Audit Manager は選択した AWS アカウントでエビデンスの収集を開始し、ユーザーはレポートの作成を開始し、準拠していないリソースは概要画面に表示されます。最初の評価が表示されるまでに最大 24 時間かかる場合があることに注意してください。 評価の詳細画面にいつでもアクセスして、どのコントロールのステータスも確認できます。 まとめ 「AWS 生成 AI ベストプラクティスフレームワーク v2」は、Amazon Bedrock と Amazon SageMaker が利用できるすべての AWS リージョンの AWS Audit Manager フレームワークライブラリ で本日よりご利用いただけます。 Audit Manager が希望するリージョンで利用可能かどうかは、 リージョン別の AWS サービス で確認できます。 さらに深く掘り下げたい場合は、 開始方法のステップバイステップガイド をご覧ください。 原文は こちら です。

多くの AWS 顧客は、開発プロセスを高速化し、アーキテクチャの一部としてそれぞれのサービスをスケールアウトする機能を向上させるために、モジュール化されたアプリケーションの近代化を行っています。これには顧客が開発したアプリケーションと、パートナーが開発した SaaS アプリケーションが含まれます。アプリケーション間の通信には、 Amazon Web Services (AWS) 環境全体でのネットワーク接続が必要です。これらのアプリケーションについて、顧客とパートナーは、パートナーが各種 AWS サービスを使ってアプリケーションへのアクセスを許可する、さまざまなネットワーク接続モデルを使用します。アプリケーション間の通信を接続、監視、保護するネットワーク構造の 1 つが Amazon VPC Lattice です。顧客は、サービスへのアクセスをコントロールするきめ細かなアクセス制御ポリシーを使って、簡素化された安全なネットワーク接続モデルを提供する VPC Lattice を利用します。例えば、顧客はサービスネットワークに関連付けられている Amazon Virtual Private Cloud (VPC) の各クライアントアプリケーションから SaaS サービスとの通信方法をポリシーで定義します。 この記事では、Amazon VPC Lattice 内の SaaS サービスをどのように接続するかについて説明します。 SaaS サービスの接続を可能にする VPC Lattice 内のコンポーネントを確認し、パートナーアカウントと VPC にデプロイされた SaaS サービスを接続するためのベストプラクティスを概説します。 また、パートナーの視点と顧客の視点の両方から認証ポリシーの例を確認し、サービスネットワーク内のサービスへのアクセスを許可または拒否する方法を示します。 前提条件 以降のセクションでは、 AWS Identity and Access Management (IAM) ポリシーの作成と、VPC Lattice の基本的な概念 (サービス、サービスネットワーク、認証ポリシーなど) を把握していることを前提とします。 また、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 AWS Lambda を使ってサービスやアプリケーションをデプロイする方法に習熟していることを前提とします。 ソリューション概要 パートナーと VPC Lattice 内でサービスを共有するには、この接続モデルを提供する 2 つの機能、リソース共有とセキュリティコントロールがあります。 例として 3 つのサービスで構成するシンプルなアーキテクチャを使用します。 アプリケーションのフロントエンドとバックエンドの 2 つのサービスがお客様のアカウント内に存在します。 さらに、パートナーの SaaS ソリューションをサービスネットワークに追加し、異なるサービス間の通信を可能にします。 図 1 にこのネットワークの一部としてデプロイされたアプリケーションを示しています。 図 1: 顧客アカウントと SaaS アカウント間のアプリケーションアーキテクチャ リソース共有 SaaS プロバイダと AWS アカウント または AWS Organizations アカウント内のサービスネットワークとの間でサービスを共有するには、 AWS Resource Access Manager (AWS RAM) を利用します。 AWS RAM は、VPC Lattice リソースを他の AWS アカウントまたは組織と共有できるサービスです。 AWS RAM を使うと、パートナーは独自の SaaS サービスを共有し、あなたのサービスネットワークにアクセスし、VPC Lattice の一部としてデプロイされたサービスと VPC との間での通信を許可できます。 パートナーが所有する VPC Lattice リソースを他の AWS アカウントと共有する場合、それらのアカウントは、サービスやサービスネットワークなど、パートナーのリソースをお客様のアカウントのリソースに関連付けることができます。 AWS RAM では、パートナーが共有するテナンシモデルに応じて、1 つまたは複数のアカウントとサービスを共有できます。詳細は後の項で説明します。 共有リソースに対してアソシエーションを作成すると、リソースを所有しているアカウントに Amazon Resource Name (ARN)が生成され、アソシエーションを作成したアカウントにも ARN が生成されます。 AWS RAM の強力なコンセプトの 1 つに、リソース共有がリソース所有者と、リソース所有者が直接共有する AWS アカウントもしくは組織との間でのみ行われるという点があります。そうした AWS アカウントや組織は、他のアカウントと直接リソースを共有することはできません (推移的な共有はできません)。例として、図 2 では SaaS アカウントが SaaS サービスを Account A と共有し、Account A はそのリソースをサービスネットワークに追加します。そのサービスネットワークの他のサービスも、VPC Lattice サービスとサービスネットワーク認証ポリシーがアクセスを許可している限り、SaaS サービスにアクセスできます。しかし、AWS RAM 内のリソースは推移的に共有することはできません。たとえば、Account A は Account B にサービスを共有してその サービスネットワークに SaaS サービスを追加することはできません。Account B がサービスネットワークに SaaS サービスを追加したい場合、SaaS アカウントから直接共有する必要があります。 図 2: AWS RAM では推移的なサービス共有は許可されない AWS RAM の動作がわかったところで、図 1 に示した SaaS サービスの共有方法を説明します。まず、SaaS アカウントが単一の SaaS サービスを作成しました。 AWS RAM 経由で、SaaS サービスはパートナーが提供するサービスを提供し、これがお客様のサービスネットワークに接続されます。 図 3: SaaS プロバイダー アカウントで作成された SaaS サービス SaaS サービスをアカウントと共有するためには、パートナーがターゲットの AWS アカウントまたは組織向けに AWS RAM で リソース共有を作成 します。 リソース共有で、パートナーは次の項目を選択します。 共有するリソース : これには、パートナーがお客様の AWS アカウントまたは組織と共有する 1 つ以上の VPC Lattice サービスが含まれます。 リソース共有に関連した権限 : デフォルトでは、VPC Lattice サービスの権限には VPC Lattice サービスの情報を取得する権限と VPC Lattice サービスをネットワークに関連付ける権限が含まれます。リソース共有で他の権限を許可するかどうかは、パートナーがカスタマイズできます。 アクセスを許可される対象 : これは、パートナーがリソースを共有するアクセス権限を持つ対象の AWS アカウントまたは組織を指定します。 図 4 に示すように、パートナーがアカウントで SaaS サービスを共有すると、 AWS RAM と VPC サービス の両方で共有されたサービスが表示されます。 図 4: SaaS サービスと顧客アカウントの共有 この例では、図 5 に示すように、サービスがあなたのアカウントに表示されます。 図 5: アカウント内の VPC Lattice サービス 既に AWS アカウントでデプロイされているサービスネットワークに SaaS サービスを追加します。これにより、自身のサービス (フロントエンドとバックエンド) と SaaS サービスの間でサービス間通信が可能になります。 ただし、その前にサービスネットワーク内におけるサービス間のセキュリティと認証ポリシーについて説明します。 VPC Lattice 内のセキュリティコントロール セキュリティコントロールの観点から、 VPC Lattice 認証ポリシー を使用すると、サービスネットワークまたはサービスネットワーク内のサービスグループに IAM ポリシーを割り当てることができます。 これにより、VPC Lattice 内の各サービスとサービスネットワークへのアクセスを制御できるメカニズムを提供します。 各認証ポリシーは AWS IAM リソースポリシーであり、サービスアクセスリクエストへのリクエストレベルの認証とコンテキストに応じた承認を提供します。 認証ポリシーは、IAM リソースレベルでアクセスを許可または拒否するための強力な機能を提供し、 セキュリティグループ や ネットワークアクセスコントロールリスト (ACL) といったネットワークレベルの構成に加えて利用できます。 パートナー側の視点とお客様側の視点という 2 つの立場からシナリオを見ていきましょう。 パートナー側は、サービスを共有し、お客様側は VPC Lattice のサービスネットワークに SaaS サービスを追加します。 アーキテクチャは図 1 に示したものと同じで、フロントエンド、バックエンド、SaaS サービスで構成されます。 認証と認可の観点では、パートナー側はどの AWS アカウントや組織がサービスにアクセスできるかを決めるポリシーをデプロイします。 一方、お客様側は、サービス同士がどのように通信するかを決めるポリシーをデプロイします。 パートナー視点 VPC Lattice でサービスを提供するパートナーの場合、SaaS ソリューションのテナント分離戦略は、パートナーがリソースを共有する方法と、VPC Lattice サービスに追加する必要があるアクセス制御のポリシーに影響します。 SaaS アプリケーションの種類(フロントエンド、バックエンド、データアプリケーションなど)によって、パートナーが SaaS ソリューションをデプロイする方法が異なります。 シングルテナントモデル シングルテナントモデルでは、パートナーは VPC Lattice サービスを単一のお客様と共有します。ただし、1 つの AWS アカウント、複数の AWS アカウント、または AWS Organizations アカウントの中の 1 つの組織で共有する場合があります。 パートナーサービス内のすべてのリソースは、単一のお客様に紐づけられ、他の SaaS 顧客からは分離されています。パートナーは、すべてのリソースを別々のアカウントや VPC に配置する必要はありません。ただし、各 VPC Lattice サービスを個々の顧客向けにプロビジョニングされたリソースに紐付ける必要があります。このモデルでは、パートナーの認証ポリシーにより、指定の AWS アカウントまたは組織に所属する認証済みプリンシパルからのリクエストへのアクセスが許可されます。 図 6: シングルテナントとサービスを共有する SaaS プロバイダー 例を見てみましょう。パートナーが組織と共有している SaaS サービスがあると想定します。認証と認可の観点から、SaaS プロバイダーは、指定された組織に属する主体者から発信された認証済みのリクエストに対してのみ権限を付与したいと考えています。このためパートナーは、次のポリシーを作成し、SaaS サービスにこのポリシーを適用します。 { "Version":"2012-10-17", "Statement":[ { "Effect": "Allow", "Principal": "*", "Action": "vpc-lattice-svcs:Invoke", "Resource": [ " arn:aws:vpc-lattice:us-east-1:444455556666:service/svc-0b847e0ccdc496cb3/*" ], "Condition": { "StringEquals": { "aws:PrincipalOrgID": [ "o-123456customer1" ] } } } ] } このポリシーにより、組織 ID (o-123456customer1) から SaaS サービス (svc-0b847e0ccdc496cb3) へのリクエストが許可されます。 マルチテナントモデル マルチテナントモデルでは、パートナーが複数の顧客と VPC Lattice サービスを共有します。 SaaS サービス全体で顧客間でリソースを共有し、パートナーのサービスへのアクセスにはテナントごとの識別認証、パスベースの認証ポリシー、またはアプリケーションベースの別のメカニズムを使用して、リソースやカスタマーデータへのアクセスを定義します。 このモデルでは、パートナーの認証ポリシーが、顧客間の認証済み要求をすべて許可するか、または特定の顧客に対してのみ特定のパスへのアクセスを許可します。これは図 7 に示されています。 図 7: マルチテナントとサービスを共有する Saas プロバイダー 前の例を拡張して、パートナーは複数の顧客が利用する単一の SaaS サービスを展開し、サービスパスで認可を分離します。 これを実現するために、パートナーは前の例のポリシーを次のような例に変更し、SaaS サービスにポリシーを適用します。 { "Version":"2012-10-17", "Statement":[ { "Effect": "Allow", "Principal": "*", "Action": "vpc-lattice-svcs:Invoke", "Resource": [ " arn:aws:vpc-lattice:us-east-1:444455556666:service/svc-0b847e0ccdc496cb3/customer1" ], "Condition": { "StringEquals": { "aws:PrincipalOrgID": [ "o-123456customer1" ] } } }, { "Effect": "Allow", "Principal": "*", "Action": "vpc-lattice-svcs:Invoke", "Resource": [ " arn:aws:vpc-lattice:us-east-1:444455556666:service/svc-0b847e0ccdc496cb3/customer2" ], "Condition": { "StringEquals": { "aws:PrincipalOrgID": [ "o-123456customer2" ] } } } ] } 次に、パートナーが顧客 1 に /customer1 パスを使用して SaaS サービスへのアクセスを許可します (組織 o-123456customer1 から)。パートナーは顧客 2 に /customer2 パスを使用して SaaS サービスへのアクセスを許可します (組織 o-123456customer2 から)。 同じサービスを複数の顧客で共有しますが、認証ポリシーによって、トラフィックの発信元に応じて異なるパスへのアクセスを許可または拒否できます。 顧客視点 お客様の観点では、どのサービスがパートナーの SaaS サービスにアクセスするのか、また SaaS サービスからサービスネットワーク内の他のサービスへの接続を開始するかどうかを検討する必要があります。 認証ポリシー内の複数の条件に基づいてアクセスを許可または拒否する、細かく制御可能な認証ポリシーを作成できます。 自身のサービス間通信に作成するポリシーと同様に、管理者はサービスネットワークに追加される各 SaaS ソリューションに対してどのようなアクセスを与えるかを決定する必要があります。次に図 8 を見てみましょう。 図 8: フロントエンド VPC は、バックエンド サービスと SaaS サービスへのリクエストを開始します。他のリクエストはすべて拒否されます。 この例では、バックエンドサービスと SaaS サービスの 2 つのサービスをサービスネットワークに関連付けています。 さらに、フロントエンド VPC からサービスネットワークへの接続を開始できるように、フロントエンド VPC との VPC 関連付けを作成しています。 フロントエンド VPC からバックエンドサービスと SaaS サービスへの接続のみを許可し、他の VPC からの接続は許可しない設定にします。 この設定を行うには、以下のポリシーを記述し、サービスネットワークに適用します。 { "Version":"2012-10-17", "Statement":[ { "Effect": "Allow", "Principal": "*", "Action": "vpc-lattice-svcs:Invoke", "Resource": [ " arn:aws:vpc-lattice:us-east-1:444455556666:service/svc-0b847e0ccdc496cb3/*", " arn:aws:vpc-lattice:us-east-1:111122223333:service/svc-0be0b12dd1d277c58/*", ], "Condition": { "StringEquals": { "vpc-lattice-svcs:SourceVPC": " vpc-1a2b3c4d" } } } ] } このポリシーにより、フロントエンドサービス (vpc-1a2b3c4d) がバックエンドサービス (svc-0be0b12dd1d277c58) と SaaS サービス (svc-0b847e0ccdc496cb3) の両方に要求を送信できるようになります。 これで、お客様のサービスと組織で利用されているパートナーの SaaS サービスの間でサービス間通信を行うためのサービスネットワークが構築できました。 注意点 VPC Lattice でサポートされているリスナープロトコルとポートは、 VPC Lattice ユーザーガイド に記載されています。 VPC Lattice サービスの所有者のみがそのサービスにアクセス権限ポリシーを追加できます。所有者があなたにサービスを共有した場合は、サービスネットワークまたはサービスネットワーク内のサービスに対してアクセス権限ポリシーを作成できます。 結論 この記事では、 Amazon VPC Lattice を使用してサービスネットワーク全体のサービスと SaaS サービス間の安全な接続を提供する方法について説明しました。 パートナーがあなたの AWS アカウントまたは組織とサービスを共有する方法を確認しました。 次に、パートナーとあなた両方がサービスネットワーク内のサービス間通信を許可または拒否するために認証ポリシーを作成する例を示しました。 この記事に関する質問がある場合は、AWS re:Post に質問を投稿してください。 Amazon VPC Lattice の詳細については、 Amazon VPC Lattice ドキュメント および VPC Lattice について説明する追加の Networking & Content Delivery ブログ投稿 を参照してください。 本記事は、 Connecting Saas services within a VPC Lattice service network を翻訳したものです。翻訳は Solutions Architect の 長屋 が担当しました。

こんにちは、AWS ソリューションアーキテクトの梅田です。 2024年 05 月 29 日に 「生成 AI で教育を加速 ! 最新トレンドと実践ガイド」 というタイトルでウェビナーを開催しました。 開催報告として、ウェビナーの内容と当日の収録映像を紹介します。 開催の背景 生成AIが普及し始めて1年以上が経過し、さまざまな業界で活用事例が出てきました。教育分野においては、「どのように活用したらよいかわからない」「導入を検討しているがハードルが高い」という声を聞くことも増えました。 本ウェビナーでは、以下の2点を中心にご紹介しました。 AWSが提供する生成AI の最新アップデート情報 クラスメソッド社のクラウドソリューション導入・運用サポートサービス EdTech企業様や教育機関様がお抱えの課題に対し、生成AIの活用方法や、クラウド基盤の構築・運用をデモを交えながらワンストップでお応えする内容となっていました。 セミナー内容紹介 / 収録録画 タイトル : 生成 AI で教育を加速 ! 最新トレンドと実践ガイド 開催日 : 2024 年 05 月 29 日 (水) 動画視聴は こちら 資料は こちら Amazon Bedrock で Claude 3 を使いこなそう！(アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 技術統括本部 シニアソリューションアーキテクト　松井佑馬) Amazon Bedrock で Claude 3 を使いこなそう！ このセッションでは、高速で高性能な注目の最新基盤モデルである Anthropic 社の Claude 3 を、AWS の生成 AI サービスである Amazon Bedrock で使いこなす方法として、 Amazon Bedrock および Claude の特徴やユースケース、セキュリティ、プロンプトエンジニアリングなどを紹介しました。 まずセッションの初めに、教育分野におけるAIの活用について説明しました。まず、教育のDXを加速するため、個別最適な学びと協働的な学びの実現、および先生の働き方改革を実現することを課題としました。そこで、生成AIを活用することで、これらの課題解決を加速できると考えています。 続いて、 Amazon Bedrock では、様々な基盤モデルを単一のAPIで利用できること、セキュリティとプライバシーにも配慮されていることを説明しました。 そして Amazon Bedrock の基盤モデルの中でも Anthropic 社の Claude 3 について紹介しました。 Claude 3 には 3 つのモデル (Opus、Sonnet、Haiku) があり、精度・速度・コストに応じて選択できること、また特徴としてHaikuの高速性やマルチモーダル対応を挙げました。最後により望ましい結果を得るためのプロンプトの工夫 (プロンプトエンジニアリング) について説明しました。 これらの情報が生成AIの教育でのユースケースを検討したり、実際に Amazon Bedrock で生成AIを使い始めたりする際の参考になれば幸いです。 (参考情報) 公共機関における生成 AI の活用案 Generative AI Use Cases JP – すぐに業務活用できるビジネスユースケース集付きの安全な生成AIアプリ実装 生成AIをお客様のアプリに組み込む(アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター 技術統括本部 ソリューションアーキテクト　梅田昌太) 生成AIをお客様のアプリに組み込む このセッションでは、以下のトピックが取り上げられました 生成AIをお客様アプリへ組み込むヒント RAG(Retrieved Augmented Generation) というアプローチ Knowledge bases for Amazon Bedrock の紹介 RAG というアプローチを通して生成AIをどのようにお客様のアプリケーションに組み込むかについて説明しています。 RAG(Retrieved Augmented Generation)とは RAGは、Retrieve(検索)とGeneration(生成)の2つのステージを組み合わせるアプローチです。外部データを元に作成されたナレッジベースから質問に関連する情報を検索し、その情報と入力クエリを組み合わせて高品質な回答を生成します。 このアプローチにより、生成AIの「幻覚(hallucination)」問題を抑制し、回答の精度と一貫性を向上させることができます。AWSでは Knowledge bases for Amazon Bedrock を用いることで、 簡単にRAGが実装できることを紹介しています。 また、実際にお客様のアプリケーションへ生成AIを組み込むためには、生成AI機能だけでなく、アプリケーションを実行する基盤やデータの蓄積、収集の重要性についても触れられています。 AWSはすでにご利用いただいてるお客様にも、これからご利用いただくお客様にも、簡単にRAGを試せる環境があります。是非RAGを試して回答の品質を高められるか検証してみてください。 生成AIの信頼性を上げてビジネスを加速させるためのデータ活用術（クラスメソッド株式会社 新規事業部 ソリューションセールス 熊谷 敏宏 氏） 生成AIの信頼性を上げてビジネスを加速させるためのデータ活用 本セミナーでは、企業における生成AIの活用方法を、データ活用という視点から解説しています。 まず、企業が持つデータの90%が非構造化データであると指摘し、これらの活用が競争優位性につながる可能性に言及していて、非構造化データの活用が、生成AIの登場により加速度的に進み、業務効率化・意思決定の質向上・顧客理解の深化といったメリットをもたらすことを紹介しています。 生成AI活用の具体的な手法として、RAG（Retrieval-Augmented Generation）が紹介されています。 RAGは、大規模言語モデル（LLM）に追加情報を与えて回答を生成する方法で、自社データを活用した独自のAIシステムを構築できます。 しかし、RAGの実装には幾つかの課題があることも指摘されています。 例えば、CSVファイルの途中が抽出されてしまう問題や、似たようなドキュメントの内容が混同される問題などです。 これらの課題に対して、ファイルの分割やタグ付け・フィルタリングなどの具体的な解決策が提案されています。 最後に、クラスメソッド社が提供する「らくらくRAG導入パック」というサービスが紹介されています。 このサービスは、企業が短期間で自社データを活用したAIチャットボットを導入できるソリューションです。 セミナー資料全体を通して、生成AIの活用が企業の非構造化データ活用の敷居を下げ、ビジネス課題解決に大きな可能性をもたらすことが強調されています。 同時に、効果的な活用のためにはデータの前処理や加工が重要であることも指摘されており、企業が生成AIを導入する際の具体的なポイントが示されています。 おわりに 本セミナーの内容が、生成AI導入の一助になれば幸いです。 AWSの活用やご提案に関するご相談、ご要望がありましたら、担当営業、もしくは公式サイトの お問い合わせ までお問い合わせください。 このブログは、2024 年 06 月 18 日時点の情報に基づいてソリューションアーキテクト 梅田が執筆いたしました。

本ブログは株式会社サルソニード様と Amazon Web Services Japan が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの小林大樹です。 昨今、生成 AI を活用して業務効率化を図るお客様が増えています。特に、大量のテキストデータを扱うマーケティング業務では、記事作成や校正、リライトなどのタスクを生成 AI に任せることで、人的リソースを削減し、本来のマーケティング活動に注力できるようになってきました。 今回は、Web マーケティングのワンストップソリューションを提供されている 株式会社サルソニード様 が、 Amazon Bedrock と Amazon Kendra を活用して法律関連オウンドメディアの記事作成を効率化し、記事のリライト業務にかける時間を 70 % 削減された事例をご紹介します。 お客様の状況と検証に至る経緯 サルソニード様のマーケーターはマーケティング業務だけでなく、記事執筆業務や WEB サイト制作業務も一貫して担当しています。業務拡大にマーケティングチームの増員が追いつかず、マーケティングチームのリソース不足が続いていました。 そこで、生成 AI を活用した業務効率化基盤の構築を検討していましたが、1名のエンジニアのみで社内システムや複数の自社サービスの開発・運用を担当していたため、生成AIの環境構築に充分なリソースを割くことが困難な状況でした。その一方で、機微情報を扱っていることから、社員の方々が外部の生成 AI ツールを各々契約して勝手に利用する、いわゆるシャドー IT を防ぐためにも喫緊の対応が必要となっていました。 こうした課題を解決するため、Amazon Bedrock と Amazon Kendra を活用した RAG（検索拡張生成; Retrieval Augmented Generation) チャット環境を社内マーケター向けに提供し、記事のリライト業務を生成AIによってサポートする取り組みを始めました。 ソリューション／構成内容 環境構築にあまりリソースを割けない状況の中、セキュリティを担保した生成 AI 環境を構築するために、AWS が OSS (オープンソースソフトウェア) として提供している「 GenU (Generative AI Use Cases JP) 」を活用しました。GenU は以下のようなアーキテクチャで構成されており、生成 AI を用いたチャットボットや、要約や文章構成、画像生成など様々なユースケースを体験することができるアプリケーションとなっております。また、上記のユースケースに加え、RAG による社内情報に基づいた AI チャットボットなども利用することができます。 RAG について少し補足します。RAG では、ユーザーが知りたい内容に対してまず Amazon Kendara に対して検索を行い、得られた検索結果を参考情報として生成 AI が回答を生成します。RAG を利用することで、生成 AI モデルが知らない社内のマニュアルや規定といった情報についても回答を生成することができます。Amazon Kendra は Amazon S3 やウェブサイトなど、複数のデータソースからデータを簡単に取り込み、検索に適したインデックスを作成してくれます。今回の実装では、社内の過去の記事データやマニュアル類を Amazon Kendra に同期するために ECS Scheduled Task を利用し、以下のような処理を定期実行するジョブを作成しています。 ECS Scheduled Task でジョブを実行 1-1. 自社プロダクトのDB (Amazon Aurora PostgreSQL) から対象データを抽出 1-2. データをプレーンテキストに整形 1-3. AWS SDK で S3 にアップロード 1-4. Amazon Kendra の S3 Connector を利用してインデックスを同期 上記の実装を行うことで、自社 DB やその他のデータソースから検索対象データを柔軟に抽出し、RAG のデータソースとして利用することが可能となっています。加えて、GenU では生成 AI ツールを社内展開する際に便利な以下の機能を備えています。 Amazon Cognito を利用したユーザー認証機能 AWS WAF を利用した IP 制限等のアクセス制御機能 サルソニード様では、社内に生成 AI ツールを展開するにあたって、セキュリティを確保するために上記機能を有効化していただき、ユーザー認証やアクセス制限機能を備えたセキュアな環境を短期間で構築することができました。このように、GenU を利用することで、簡単かつ迅速に環境構築を行うことができたため、1 名のエンジニアがわずか 2 日で環境構築から社内リリースを行うことができました。 導入効果 前述の通り、サルソニード様は GenU を活用した生成 AI ツールを社内ユーザー向けにリリースされました。具体的には、Web メディア記事の制作や校正に Amazon Bedrock から利用可能なモデルを使った通常の生成 AI チャットを利用し、社内情報や専門知識が必要なマーケターの質問への回答には Amazon Bedrock と Amazon Kendra を組み合わせた RAG チャットを利用しています。この生成 AI ツールの導入により、サルソニード様では以下のような効果が得られました。 記事のリライト業務にかける時間を70%削減でき、マーケターはマーケティング業務に集中できるようになった 会社公認の生成 AI ツールを使える環境を GenU で提供することで、生成 AI のシャドー IT 利用の防止につながり、AWS 内で稼働する環境のため、情報漏洩のリスクもコントロールできるようになった 今回は「マーケターの記事執筆業務の効率化」という切り口で導入いただきましたが、「従業員が利用できるセキュアな生成 AI ツールを会社として提供したい」といったお客様や、「社内の知見と生成 AI を組み合わせて利用したい」というお客様にもおすすめできるソリューションとなっています。 まとめ 今回は、Amazon Bedrock と Amazon Kendra を活用した生成 AI ツールを活用し、記事執筆業務を効率化する、というサルソニード様の挑戦についてご紹介いたしました。 生成 AI は単体でも便利なツールですが、今回のように社内の過去の知見やマニュアル、規定類といった情報と、生成AIを組み合わせることで、業務効率化を実現しているお客様も多くいらっしゃいます。 セキュアかつプライバシー保護されたソリューションを簡単に構築・運用できる GenU を利用して、生成AIの社内活用を推進してみるのはいかがでしょうか。 AWS を利用した生成 AI の活用にご興味をお持ちのお客様は、お気軽にご相談いただければと思います。 ソリューションアーキテクト 小林 大樹 (X – @kobayasd )

本記事は、以下 4 名による共著です。 株式会社オルツ 経営管理部 技術本部付アシスタント 高橋 亜美 株式会社オルツ AI Solutions 事業部 PoC エンジニア 竹内 慎修 株式会社オルツ 経営企画部 マネージャー 西澤 美紗子 アマゾン ウェブ サービス ジャパン合同会社 機械学習パートナーソリューションアーキテクト 本橋 和貴 大規模パラメータを持つ大規模言語モデル (LLM) によるビジネスの変革が期待される一方で、その利用には膨大な計算リソースとエネルギーを必要とするため、環境に対する負荷の増大が懸念されています。そのため、軽量でありながら大規模モデルと同等の精度を実現するための小規模パラメータモデルの研究が活発化しています。その流れで、 P.A.I.®️ (パーソナル人工知能) をはじめ、AI クローン技術でつくり出すパーソナル AI の開発および実用化を行う 株式会社オルツ は、軽量型大規模言語モデル LHTM-OPT (ラートム・オプト) を 2023 年 10 月にリリースしました。また、LHTM-OPT は、2024 年 3 月に、 AWS Marketplace 上における世界初の日本語 LLM として公開されました。AWS Marketplace からモデルを購入することで、利用者は大規模言語モデルや機械学習の専門知識がなくても、簡単に LHTM-OPT を活用したアプリケーションやサービスを構築できます。 以下では、AWS Marketplace に出品されている LHTM-OPT を Amazon SageMaker にデプロイして推論を実行する方法を紹介します。 LHTM-OPT とは LHTM-OPT (ラートム・オプト) とは、オルツが開発した、日本語専用のプライベートな軽量型大規模言語モデルです。LHTM-OPT はオープンデータの学習だけでなく、オルツの独自の指示データや対話データのデータセットも利用し、高い回答精度を達成しています。2023 年 10 月のリリース以降、日本国内の様々なアプリケーションで利用されています。パラメータ数が最適化された LLM であるため、小規模 GPU マシンでも高速の推論、回答生成が可能です。 2023 年 10 月にリリースした時点では、 alt Developer API 利用とオンプレミスの場合のみデプロイが可能でした。今回、 AWS Marketplace に公開 することにより、AWS の機械学習開発運用プラットフォームである Amazon SageMaker に簡単にデプロイできるようになりました。 本記事では 7B パラメータの LHTM-OPT バージョン 1.0 について解説します。このモデルは、2023 年 10 月リリース時点では、日本語 LLM を評価する Rakuda ベンチマークにおいて、日本語商用プライベート LLM として最高性能を記録しました。また、日本語言語理解ベンチマーク「 JGLUE (Japanese General Language Understanding Evaluation) 」の 8 タスク平均においても、商用モデルとして国内最高スコア 56.12 を記録しました (LHTM-OPT の JGLUE 主要 4 タスク平均のスコアは 75.08 です)。これは同じサイズの競合モデルに比べて高い数値となっています。 AWS Marketplace とは AWS Marketplace は、アマゾン ウェブ サービス (AWS) 上で動作する多種多様なサードパーティ製ソフトウェア、データ、サービスを見つけ、購入し、デプロイ、管理するためのデジタルカタログです。セキュリティ、ネットワーキング、ストレージ、機械学習、IoT、ビジネスインテリジェンス、データベース、DevOps など、幅広いカテゴリーの製品が掲載されています。ユーザーは AMI (Amazon Machine Image) や SaaS など様々な形式で提供される製品を選択し、数回のクリックでこれらのソリューションを簡単に起動できます。無料トライアル、時間単位、月単位、年単位、複数年、ライセンス持ち込み (BYOL) モデルなど、柔軟な料金オプションもあり、すべて AWS のひとつの請求書で一括して支払いができます。AWS Marketplace を利用することで、ビジネスソリューションの構築や運用に必要なソフトウェアの調達にかかる時間と手間を大幅に削減できます。 AWS Marketplace には機械学習製品も豊富に取り揃えられています。すぐ利用できる事前学習済みモデルパッケージや、独自のデータセットを用いてファインチューニング可能なアルゴリズムといった機械学習ソリューションが提供されており、機械学習の専門知識がなくても、簡単に機械学習を活用したアプリケーションやサービスを構築できます。画像認識、自然言語処理、予測分析、異常検知などの機能を持つ製品が用意されており、ユーザーは自社のビジネスニーズに合わせてそれらを選択し、Amazon SageMaker 上でモデルを学習、デプロイすることができます。近年では LLM の出品も増えており、AWS Marketplace の機械学習製品を活用することで、機械学習の導入にかかる時間とコストを大幅に削減でき、迅速にインテリジェントなアプリケーションを構築できるようになります。 AWS Marketplace で LHTM-OPT をサブスクライブする AWS Marketplace に掲載されている LHTM-OPT を利用するには、初めに製品をサブスクライブします。 LHTM-OPT の製品ページ から製品の特徴などを確認した上で、サブスクライブしていきましょう。例えば、料金情報欄は以下の通りです。 図 1 : AWS Marketplace における LHTM-OPT の料金情報 AWS Marketplace の機械学習モデルパッケージ製品の料金欄にはソフトウェア料金 (Software Pricing) とインフラ料金 (Infrasstructure Pricing) が記載されています。LHTM-OPT は時間課金の料金設定になっており、ソフトウェア自体の料金としては 1 時間あたり 1.20 USD でご利用いただけます。それだけでなく、推論を実行する基盤としての SageMaker の利用料金もかかる点にはご注意ください。 料金などが確認できたら製品をサブスクライブしていきましょう。 LHTM-OPT を利用する AWS アカウントにログインする。 LHTM-OPT の製品ページ を開き、右上の「Continue to Sucscribe」ボタンをクリックする。 図 2 : LHTM-OPT の製品ページからサブスクライブに進む 料金や EULA (End User License Agreement) を確認し、「Accept offer」ボタンをクリックする。 図 3 : 料金や EULA の確認 サブスクライブが完了したら “Thank you for subscribing. You can now use your product” と表示されます。これで製品を利用する準備ができました。次に、「Continue to configuration」ボタンをクリックし、お客様の AWS 環境内に LHTM-OPT をデプロイしていきます。 LHTM-OPT のサブスクライブが完了した様子 サブスクライブした LHTM-OPT のデプロイ 「Continue to configuration」ボタンをクリックすると Configure and launch ページが開きます。ここでは、「Avalidable launch methods」に「SageMaker console」を指定します。「Region」では、デプロイ対象のリージョンを選択します。ここでは「Asia Pacific (Tokyo)」を選択しています。「Amazon SageMaker options」ではリアルタイム推論エンドポイントを作成するか、バッチ変換ジョブを実行するか選択できます。ここでは「Create a real-time inference endpoint」を選択しています。また、以降のコード内で使用するので、「Product Arn」をコピーし、メモしておいてください。 図 5 : Amazon SageMaker におけるデプロイオプションの指定 このまま GUI ベースでデプロイを進めることもできますが、以降では Python コードでモデルをデプロイする手順を紹介します。 まず、上記の製品の ARN (Amazon Resource Name) を変数に格納します。合わせて、必要なモジュールや SageMaker ランタイムのクライアントなどをセットアップします。 import json import boto3 import sagemaker from sagemaker import ModelPackage, get_execution_role role = get_execution_role() region = “ap-northeast-1” sagemaker_session = sagemaker.Session() sagemaker_runtime = boto3.client("runtime.sagemaker", region_name=region) model_package_arn = ( "<コピーした ARN に置き換えてください>" ) 次に、モデルのデプロイと推論エンドポイントの作成をします。デプロイするモデル名と SageMaker インスタンスタイプは必要に応じて変更することができます。ただし、インスタンスタイプは こちらの製品ページ で推奨しているインスタンスタイプ一覧から選ぶ必要があります。 推論エンドポイントを作成するために 10 分ほど待ちます。 model_name = "lhtmopt" real_time_inference_instance_type = "ml.p3.2xlarge" # Create a deployable model from the model package. model = ModelPackage( role=role, model_package_arn=model_package_arn, sagemaker_session=sagemaker_session, ) # Deploy the model predictor = model.deploy( initial_instance_count=1, instance_type=real_time_inference_instance_type, endpoint_name=model_name, ) モデルのデプロイが終わるとリアルタイム推論エンドポイントの利用準備が完了し、推論を実行できるようになります。 LHTM-OPT で推論を実行する LHTM-OPT で推論を実行する際、インプットは以下の 3 つの形式で渡すことができます。 方法 1 : デフォルトパラメータと質問 これは最もシンプルな形式です。ペイロードには質問を含むプロンプトのみを渡します。推論パラメータはデフォルトで設定されているものが利用されます。 payload = { "prompt": "質問：世界で最も高い山はなんですか？\n答え：", } 方法 2 : 推論パラメータと質問 推論パラメータは任意の値を設定することもできます。ペイロードに推論パラメータのキーと値を含めることでパラメータをセットし、アウトプットをコントロールすることができます。 payload = { "prompt": "質問：世界で最も高い山はなんですか？\n答え：", "max_new_tokens": 50, "temperature": 0.7, "top_k": 40, "top_p": 0.9, "do_sample": True, "repetition_penalty": 1.2, "skip_prompt": True, } 方法 3 : Llama 2 テンプレートでインプット プロンプトは Llama 2 テンプレートの形式に構造化することも可能です。これにより、システムプロンプトを明示的に指定することができます。 payload = { "prompt": """[INST] <<SYS>> あなたは優秀な日本人のアシスタントです。 <</SYS>> 世界で最も高い山はなんですか？ [/INST]""", "temperature": 0.7, “top_k": 40, } 推論を実行 上記のペイロードを用いて推論を実行するためには、次のような Python 関数を使用してください。 # real-time inference def invoke_endpoint(endpoint_name, payload): response = sagemaker_runtime.invoke_endpoint( EndpointName=endpoint_name, ContentType=”application/json”, Body=json.dumps(payload), ) return json.loads(response["Body"].read().decode("utf-8")) 次のコードで推論を実施し、結果を出力します。 result = invoke_endpoint(model_name, payload) print(f"Result: {result}") 応答結果は次のようになります。 Result: {'message': 'OK', 'text': '世界で最も高い山は、ヒマラヤ山脈にあるエベレストです。標高8,848メートル（29,029フィート）です。チベット自治区とネパールの国境付近に位置します。1953年5月29日に英国隊が初登頂に成功したそうです。'} LHTM-OPT の応用的なユースケース LHTM-OPT は様々なユースケースに対応することができます。 例えば、LHTM-OPT は LangChain、LlamaIndex などのフレームワークと組み合わせることによって RAG、文章要約、文章生成などに応用することができます。LHTM-OPT のファインチューニングを実行するための API は公開していませんが、今後、提供する予定です。 オルツは現在、プライベート LLM の開発に関するコンサルティングや、企業独自のニーズに合わせたカスタマイズ、特定の業務に特化した LLM の開発支援も行っております。引き続き、日本社会における真の DX の実現に向けて、大規模言語モデルや生成 AI を活用したサービスの開発・提供に邁進し、社会に新たな価値を提供してまいります。 生成 AI の受託開発および LLM を活用した DX プロジェクト については、株式会社オルツ AI Solutions 事業部 (gptsolutions@alt.ai) にお問い合わせください。 あと片付け 無駄な費用が発生しないよう、推論エンドポイントを利用しなくなった場合、次のコードで削除してください。 sagemaker_client = boto3.client(“sagemaker”, region_name=region) sagemaker_client.delete_endpoint(model_name) sagemaker_client.delete_endpoint_config(model_name) まとめ 本記事では、AWS Marketplace から利用可能な軽量型大規模言語モデル LHTM-OPT 1.0 について紹介しました。LHTM-OPT の SageMaker におけるデプロイ方法と推論の実行方法についても解説しました。LHTM-OPT は小規模 GPU マシンでも実用的に動作する、パラメータ数が最適化された大規模言語モデルであり、様々なアプリケーションに適用可能です。ぜひ、 LHTM-OPT 1.0 を AWS Marketplace からお試しください 。 オルツは、今後も継続して様々なベンチマークで評価を行い、モデルをブラッシュアップし、LHTM-OPT 2.0 や LHTM-3 などをリリースする予定です。また、本モデルを基盤として自動質問応答、議事録自動要約、情報抽出、会話理解、予測分析のデータ整理・作成などの高度な処理が必要な問題に対応可能な多くのアプリケーションを実装していきます。 著者について 本橋 和貴 (Kazuki Motohashi / @kmotohas ) は、AWS Japan の機械学習パートナーソリューションアーキテクトです。AWS 上で機械学習関連のソフトウェアを開発しているパートナー企業の技術支援を担当をしています。好きなサービスは Amazon SageMaker です。週末は昔の RPG のリメイクゲームの攻略に勤しんでいます。博士 (理学)。

このブログは‘“ Revolutionizing Generative Biology with AWS and EvolutionaryScale ”を翻訳したものです。 本日、AWS は EvolutionaryScale と提携し、同社の新しいバイオロジー向け最先端言語モデルを、創薬からカーボンキャプチャまで、さまざまなアプリケーションを推進する科学者や研究者に提供することを発表する運びとなり、大変興奮しています。 この発表により、EvolutionaryScale の最先端で最高水準の言語モデルファミリー ESM3 を AWS で利用可能になります。この提携により、生成的で多様な ESM3 モデルファミリーを含む EvolutionaryScale の最先端モデルを、業界をリードする AWS のインフラストラクチャ、エンタープライズグレードのセキュリティ、プライバシー対策、ヘルスケア・ライフサイエンス業界および生成 AI 向けの特化したサービス、生成 AI の機能(ファインチューニング、ガードレール等)と組み合わせることができます。これらは現在、製薬企業やバイオテックにより研究が行われている分野です。これには、生成 AI および機械学習に AWS を既に利用している、数十万人の AI /機械学習を利用する顧客と、上位 10 社のグローバル製薬企業 9 社が含まれ、この分野のさらなる民主化が促進されます。 ESM3 のような基盤モデルを使えば、研究者は複雑なマルチドメインタンパク質を一から生成したり、タンパク質設計のワークフローを作成したり、機能的な理解を組み込むことができます。ESM3 の強力な機能により、自然界には存在しない全く新しいタンパク質の創造が可能になり、科学者や研究者は革新的な「プログラム可能なバイオロジー」のアプローチを取ることができます。これにより、新薬の市場投入までの時間とコストを数年間と数十億ドルコストダウンできる可能性があります。 お客様は Amazon SageMaker を通じて ESM3 を簡単に利用開始でき、後にリリースされる Amazon Bedrock のサポートにより、 AWS HealthOmics を使ってエンドツーエンドの創薬ワークフローを完全自動化することができます。 Amazon Bedrock は、基盤モデルを使った生成 AI アプリケーションを構築・スケーリングする最も簡単な方法です。 ライフサイエンス業界での生成 AI の大きな機運: AWS は、さまざまな業界で生成 AI のイノベーションを加速する最前線にあり、大規模言語モデル (LLM) や基盤モデル (FM) の力を活用できるよう組織を支援しています。 Amazon Bedrock を利用して高性能の生成 AI モデルに簡単にアクセスできる数万社のお客様、 Amazon SageMaker で数百のプリトレーニングモデルを提供している AWS は、生成 AI アプリケーションの構築とスケーリングを簡素化しています。ライフサイエンス業界では生成 AI への熱気と機運が非常に高く、プロセスの自動化から研究や発見の仕方を根本的に変革するまで、お客様がビジネスを変革しています。例えば、 アストラゼネカ はゲノミクスを活用して創薬と精密医療の変革を加速し、研究者が洞察を迅速に科学的知見に変えられるようにしています。ギリアドは、企業全体のさまざまなソースからの非構造化情報の大量を迅速に分析できるよう、主要データセットから洞察を生成しています。 ファイザー は Bedrock や SageMaker などのサービスを使い、医学/科学コンテンツや特許出願を作成する AI ソリューションを展開し、画期的な成果を早期に患者に届けられるようにしながら、年間最大10億ドルのコスト削減も可能にしています。 そこで本日、EvolutionaryScale との、ライフサイエンス業界の研究開発を変革することを目指す共同イニシアティブと、 Go-To-Market での提携を発表する運びとなり、大変喜ばしく思います。 EvolutionaryScale は、バイオロジー向けの最先端言語モデルのトレーニングと適用を主導するリーディングチームで、バイオロジーデータへの大規模言語モデリングの最初の適用例の1つである Evolutionary Scale Modeling (ESM) モデルファミリーの開拓者です。彼らはバイオロジーへの生成 AI の適用で、バイオロジー特化の最初のトランスフォーマー言語モデル、スケーリング則、生物学的配列の構造予測手法の開発など、主要なマイルストーンを達成しています。本日、EvolutionaryScale は、この重要な分野で全く新しい地平を切り開く、初の生成的で多様な言語モデルファミリー ESM3 の発表を行いました。 生成 AI がバイオロジーを変える可能性: 生物学的配列を「生命の言語」と捉えることで、タンパク質工学やデザインの分野に生成 AI の手法を適用する可能性が広がります。大規模言語モデルが膨大なテキストデータセットで学習することで言語理解を示す有用なアシスタントになるのと同様に、ジェネレーティブ・バイオロジーモデルは大量のタンパク質配列データから「タンパク質の言語」を学習できます。これらのモデルはこれらの配列内のパターンや関係性を理解することで、創薬設計、酵素工学、合成生物学などの用途に合わせて機能的な新規タンパク質配列を生成できるのです。タンパク質はテキストとは 3 次元構造が異なりますが、これは生命の基本単位に関わる分野で生成 AI の力を活用して発見やイノベーションを加速する可能性を示唆しています。この技術は、進化、分子生物学、人工知能、医療、人々の健康をつなぐ変革の中心にあります。 ESM3: ジェネレーティブ・バイオロジーの画期的成果 EvolutionaryScale の ESM3 は、配列、構造、機能を同時に推論できるバイオロジー向けの画期的で最先端の生成モデルで、従来のタンパク質言語モデルには無い機能です。38 億年の進化を経た数十億のタンパク質配列で複数のモダリティを学習した ESM3 は、さまざまなソースからの複雑なバイオロジーデータを理解し、自然界には存在しない全く新しいタンパク質を生成できます。ESM3 モデルファミリーには、3 つの独自モデル(パラメータ数 98B、7B、1.4B)と 1 つのオープンソースモデル(パラメータ数 14 億)が含まれ、オープンソースバージョンは本日から Amazon SageMaker と AWS HealthOmics で、2024 年後半に Amazon Bedrock でも利用可能になる見込みです。 ESM3 モデルを使えば、お客様は以下のことが可能になります。 配列、構造、機能の「言語」を理解した ESM3 を使い、複雑なマルチドメインタンパク質を一から生成できる。 異なるモダリティに基づいて個々のドメインを設計し、それらを組み合わせて新規タンパク質を作れるタンパク質設計ワークフローを作成できる。 抗体の理解を組み込める: ESM3 は抗体配列と構造を非常に良く理解しているため、in silico で多様化、最適化、進化工学などの操作が可能。 ESM3 で作られた蛍光タンパク質 esmGFP バイオロジー基盤モデル (biological Foundation Models: bFM) を安全に民主化: 汎用の LLM や FM と同様に、AWS の包括的なヘルスケア・ライフサイエンス業界および生成 AI 向け特化サービスポートフォリオ (Amazon SageMaker 、 AWS HealthOmics、 AWS HealthScribe、 Amazon Bedrock など)を通じて、研究者は ESM3 のような bFM に簡単にアクセスできるようになります。Amazon SageMaker と AWS HealthOmics から始まり、お客様はEvolutionaryScale の最新オープンソースモデルバージョンを活用できるようになり、独自の ESM3 モデルファミリーもすぐにこれらのサービスと Amazon Bedrock で利用可能になります。フルマネージドなAWSサービスにより、研究者は ESM3 のようなパワフルな bFM を創薬ワークフローにカスタマイズしてシームレスに統合する最も簡単な方法をご利用いただけます。 この発表により、お客様は独自データセットで ESM3 をファインチューニングでき、独自データをプライベートに保ちながら、医薬品開発での画期的な発見を可能にし、イノベーションを加速できます。また、お客様はAWSの業界をリードする生成 AI インフラ (高性能 GPU インスタンスや AWS Trainium のトレーニング向け機械学習専用アクセラレータ、AWS Inferentia の推論向け機械学習専用アクセラレータなど) を活用してこれらのイノベーションをスケーリングできます。AWS の並外れた計算能力により、お客様は ESM3 のトレーニング、構築、実行を効率的に行えます。ESM3 のようなジェネレーティブ bFM を AWS サービスと統合することで、デプロイが簡素化され、データの暗号化処理、プライベートネットワーキング、HIPAA および GDPR コンプライアンスによる強固なセキュリティが確保されます。責任あるモデルの挙動をガイドするため、ガードレールが多層で組み込まれています。EvolutionaryScale の ESM3 は、有害なタンパク質の生成などの安全性リスクを軽減するよう設計されています。Amazon Bedrock のガードレールにより、お客様は倫理的 AI ポリシーに沿った入出力へのカスタムフィルタを実装できます。この公平性、安全性、透明性へのコミットメントにより、bFM の驚くべき可能性が責任を持って実現されます。 バイオロジーにおける生成 AI の未来 このマイルストーンは、バイオロジーアプリケーション向けにカスタマイズされた生成 AI 搭載モデルの新時代の幕開けを告げるものです。飛躍的な前進であるESM3は、AWSの生成 AI 機能とEvolutionaryScale の革新的 AI モデルが、計算パワーとデータスケールの最前線で相乗効果を発揮することで、創薬のタイムラインを大幅に短縮する可能性を秘めています。この提携により、プログラム可能なバイオロジーを可能にし、ライフサイエンス企業は責任ある生成 AI の力を活用して創薬の境界を押し広げ、プロセスを合理化し、最終的には新しい治療薬をより早く患者に届けられるようになります。ターゲット特定の合理化、イノベーションの促進、開発時間とコストの削減、創薬の成功確率向上につながります。 著者について Matt Wood: Matt は AWS の AI 関連プロダクトの Vice President です。この役割において、彼は顧客、パートナー、内部の AWS チームと緊密に連携し、あらゆる業界における AI の効果的な活用を推進しています。 Matt はアマゾンに 14 年間在籍しており、クラウドビジネス全般 (Lambda、Kinesis、SageMaker、DeepRacer、Athena、EMRの立ち上げ支援を含む) に携わってきました。特に、データ、分析、機械学習、人工知能に重点を置いてきました。彼の情熱は、NFL、Cerner、Intuit、Pinterest、GE、FINRA、Celgene、NASA などの AWS 顧客と協力し、彼らのアイデアを実現することにあります。アマゾン入社前は、英国で医学を学び、機械学習の博士号を取得し、コーネル大学で博士研究員を務めていました。 このブログはヘルスケア・ライフサイエンス事業開発部 シニア事業開発マネージャー 片岡 が翻訳しました。

本記事は、2024年5月15日に公開された Data migration strategies to Amazon RDS for Db2 を翻訳したものです。 AWS は re:Invent 2023 で Amazon Relational Database (Amazon RDS) for Db2 を発表しました。RDS for Db2 は、 Amazon RDS に新しく追加されたデータベースエンジンです。 最適なパフォーマンスを実現するスケーラブルなハードウェアで、数分で Db2 データベースを展開できます。 また、Multi-AZ デプロイメントを使えば、別の Availability Zone にあるスタンバイデータベースインスタンスにデータを同期レプリケーションする、高可用性データベースを構築できます。 このブログでは、Amazon RDS for Db2 の組み込み機能と AWS Database Migration Service (AWS DMS) または Db2 Migration Tooling (Db2MT) を使用して、セルフマネージド型の Db2 データベースを RDS for Db2 に移行する手順を説明します。 まず、採用できる様々な移行戦略の概要を示し、次に移行方法について説明し、最後に移行の計画のためのベストプラクティスを紹介します。 マイグレーション戦略 マイグレーション戦略は、セルフホスティングの Db2 データベースのオペレーティングシステムによって異なります。 ソースデータベースとターゲットデータベースのオペレーティングシステムが同じ場合 (例えば Linux から Linux へ) 、そのマイグレーションは リホスト と呼ばれます。 ソースデータベースのオペレーティングシステムが宛先データベースとは異なる場合 (例えば z/OS から Linux へ) 、そのマイグレーションは リプラットフォーム と呼ばれます。 次の表は、ソースデータベースの基盤となるオペレーティングシステムに基づく リホスト と リプラットフォーム の詳細をまとめたものです。 マイグレーション戦略 リホスト リプラットフォーム 備考 オペレーティングシステム Linux Linux 以外 (z/OS、AIX、Windows など) ネイティブの IBM Db2 マイグレーションツール、DMS、サードパーティ製品を使用できます。 マイグレーションのスピード 高速 低速 リホストの方が変換が不要なので高速です。 リプラットフォームは変換が必要で時間がかかります。 Db2 オフライン リストア はい いいえ Db2 のバックアップとリストアを使用します。リストアが完了するまでダウンタイムが発生します。 Db2 オンライン リストア はい いいえ Db2 のバックアップとロールフォワードリストアを使用します。短時間のダウンタイムですが、完了までに時間がかかる場合があります。 Db2 エクスポートまたはインポート はい はい 論理マイグレーションには Db2 のエクスポートとインポートを使用します。リプラットフォームの場合は変換のために時間がかかります。 クライアントからのロード はい はい Db2 を使用します。 Amazon S3 からのロード はい はい リプラットフォームの場合は高速です。 AWS DMS はい はい レプリケーション IBM CDC レプリケーション はい はい レプリケーション IBM Q レプリケーション はい はい レプリケーション メタデータの忠実性(+) 高い 中程度 リプラットフォームの場合は忠実性に特に注意が必要です。 データの品質 高い 中程度 リプラットフォームの場合は品質に特に注意が必要です。 使いやすさ 簡単 複雑 リホストの方が簡単です。 導入のワークロード 低い 高い リプラットフォームには大きなワークロードが必要です。 (+)ソースからターゲットに移行される際、データベーススキーマの再構築方法によっては、メタデータが正確に再現されないことがあります。例えば、自動インクリメントの開始点、シーケンス、隠し列、チェック制約、外部キー制約の適用などが正しく適用されない事があります。 Amazon RDS へのリホスト (同一オペレーティングシステムへの移行) セルフ運用している Db2 データベースが、リトルエンディアンの 64 bit Linux プラットフォーム上で実行されている場合、Amazon RDS for Db2 へリホストできます。 たとえば、Linux on Intel、AMD、Linux POWER LE (リトルエンディアン) 上のセルフ運用している Db2 データベースはリホストできますが、AIX、zLinux、Windows 上のものはリホストできません。 Amazon RDS へのリプラットフォーム (異なるオペレーティングシステムへの移行) セルフ運用している Db2 のオペレーティングシステムが Linux (リトルエンディアン) 以外の場合、ソースの Db2 データベースを Amazon RDS for Db2 にリプラットフォームする必要があります。 セルフ運用の Db2 データベースが AIX、Windows、zLinux などのオペレーティングシステム上で実行されている場合、Amazon RDS for Db2 でリプラットフォームできます。 再プラットフォームは、より広範な移行プロセスの第一段階と見なされ、組織はデータベースを迅速にAmazon RDS for Db2に移行し、その後、徐々に最適化や再アーキテクチャを検討することができます。 Amazon RDS for Db2 を使用して DB をリホストおよびリプラットフォームする移行方法 移行方法の選択は、ソースDb2のオペレーティングシステムの種類と許容できるダウンタイムによります。移行速度を確認するために、適切なサイズのデータベースを使ったテスト移行を行い、エンドツーエンドの移行時間を把握することをお勧めします。許容できるダウンタイムに応じて、一回限りの移行またはログレプリケーションを用いた移行のいずれかを選択できます。ビジネスニーズに基づいて適切なレプリケーション方法を選択するために、次の意思決定ツリーを参照してください。 Amazon RDS によるリホスト セルフ運用の Db2 データベースが、Linux 上で実行されている場合は、Amazon RDS for Db2 にリホストできます。Linux からの移行はデータ変換を必要としないため、再プラットフォームよりも簡単かつ短時間で完了します。移行には Db2 のネイティブツールを使用し、複雑なデータ構造の変更や最適化を避けます。 ワンタイムマイグレーション データベースのバックアップ、リストア、および切り替えを行う全体的な時間が許容できるダウンタイム内であれば、ワンタイム移行を利用できます。 セルフ運用の Db2 Linux データベースのバックアップを直接 Amazon Simple Storage Service (Amazon S3) にコピーし、Amazon RDS for Db2 でリストアするために、 Db2 Migration Tooling (Db2MT) を使用します。 Db2MT は、移行を完了するために必要なスクリプトを作成し、バックアップとリストアの両方を並列化して移行を高速化します。 次の図はそのソリューションアーキテクチャーを示しています。 手動でデータ移行を行う場合は、Amazon S3 からオフラインバックアップを復元するため、RDS for Db2 のストアードプロシージャ restore_database を呼び出すことができます。 ログレプリケーションを使用した移行 初期テスト移行によって測定された移行時間が許容できるダウンタイムよりも長い場合、A/Bデプロイメントアプローチを使用して、Linux上のセルフ運用のDb2からAmazon RDS for Db2へのログレプリケーションを使用した移行を実行できます。このアプローチでは、新しいRDS for Db2データベース（A）を旧データベース（B）と並行して使用し、準備が整った時点で切り替えを行います。 Db2MT は、前のセクションで説明したように、ユーザーが管理する Linux の Db2 のオンラインデータベースバックアップを直接 Amazon S3 に取得し、次に Amazon RDS for Db2 で復元するための手順を提供しています。Db2MT はまた、定期的にログを直接 Amazon S3 にアーカイブし、データベースをロールフォワードペンディングモードに維持して、ログを RDS for Db2 に適用する手順も提供します。 ロールフォワード 操作を完了することで、最終的に切り替えを行うことができます。 次の図は、このソリューションのアーキテクチャを示しています。 Amazon RDS for Db2 のストアードプロシージャ restore_database  を使用して、 backup_type  を  ONLINE に設定することで、オンラインバックアップイメージを復元できます。 Amazon RDS for Db2 のストアードプロシージャ rollforward_database  を使用して、アーカイブログを適用できます。 切り替え準備ができたら、ストアードプロシージャ  complete_rollforward を実行して、データベースの復旧を完了し、Amazon RDS for Db2 データベースを接続可能な状態にできます。 Amazon RDS へのリプラットフォーム もう 1 つの主要な課題は、AIX、Windows、メインフレー上の Db2 on Linux (ビッグエンディアン) から、スピーディかつダウンタイムをほぼゼロに抑えてデータを移行することです。 Amazon RDS へのリプラットフォームは、リホストに比べてより時間がかかります。 これは、AIX、Windows、メインフレーム上の Db2 on Linux から Db2 バックアップイメージを復元できないためです。 これは、リトルエンディアンとビッグエンディアンの違いが原因です。 ソースの Db2 データベースからメタデータを抽出し、Amazon RDS for Db2 に適用する必要があります。 最良の方法は、他のサードパーティツールが使用するリバースエンジニアリング方法と比較して、メタデータの再現度が最も高いネイティブツールである  db2look  を使用することです。 Db2 のネイティブツールである  export  を使用して、データをアンロードし、ネイティブツールである  import  または  load  を使用して、ソースから RDS for Db2 データベースに移行できます。 移行の相対的な速度については、次の図を参照してください。 AWS DMS は、セルフ運用されている Db2 データベースから Amazon RDS for Db2 に移行する処理を簡素化するマネージドサービスです。AWS DMS は Db2 を ターゲットエンドポイント としてサポートし、Amazon RDS for Db2へのフル ロードとChange Data Capture (CDC) の両方の移行方法に対応しています。 別の方法として、Db2MT を使えば、メタデータを抽出し、データをアンロードすることができます。抽出したメタデータを使用してデータベースオブジェクトを作成し、その後 Db2MT を利用して Amazon S3 から直接 Amazon RDS for Db2 にデータをロードできます。 これらのタスクは自動化されており、簡単なDb2MTコマンドを使用して各タスクを開始できるため、抽出および並列化の複雑なプロセスに取り組む必要はありません。 データベースの移行速度は、適度な量のデータを使ったサンプル移行を行って判断することをお勧めします。これにより、一括の移行か、ログレプリケーションによる移行のどちらを使うべきかが判断できます。 ワンタイム移行 カットオーバー時間を含めた合計時間がダウンタイムの許容範囲内であれば、ワンタイム移行を選択できます。AIX または Windows から移行し、データを Amazon RDS for Db2 にロードする場合は、Db2MT の利用をおすすめします。次の図に、このソリューションのアーキテクチャを示します。 Amazon RDS for Db2 は、Amazon S3 から直接データを読み込む機能をネイティブでサポートしています。Db2MTは  DB2REMOTE ID  を使用し、Amazon S3への ストレージアクセス を利用して、Amazon RDS for Db2に接続されたDb2クライアントを通じてAmazon S3から直接データをロードします。 ログレプリケーションによる移行 初期テスト移行を通じて測定された移行時間が停止時間の範囲を超える場合、AIX または Windows 上のセルフ運用の Db2 から Amazon RDS for Db2 への移行にログ レプリケーションを使用することができます。 前述の Db2MT を使用して ワンタイム移行を完了するステップに従います。次のいずれかの方法を使用してダウンタイムがほぼゼロの移行を実現できます。 AWS DMS  – AWS では、Db2 をソースとターゲットとしてサポートしています。AWS DMS の レプリケーションインスタンス を使用することで、ソースの Db2 データベースから Amazon RDS for Db2 に変更を同期できます。 IBM Q Replication  –  IBM Q Replication を使用して、AIX、Windows、メインフレーム上のLinux (ビッグエンディアン) で実行されている Db2 からのダウンタイムをほとんどなくす移行を実現できます。 次の図は、このソリューションのアーキテクチャを示しています。 移行プロジェクトの計画 データ移行プロセスでは、メタデータの忠実性の確保、データの整合性と品質の確保、AWS DMS などの既存の Amazon RDS サービスを使用したパフォーマンス上の懸念、コスト管理、統合への対処、レガシーアプリケーションのサポート、ネットワーク帯域幅、事業継続、災害対策、安全なアクセスのための入念な計画が必要であり、次のフェーズを含みます。 準備と計画: データベースサイズと複雑性の分析  – データベースのサイズとデータの複雑さを理解する。これは移行に必要な時間とリソースを見積もるのに役立ちます。 ピークとオフピーク時間の特定  – ユーザへの影響を最小限に抑えるため、オフピーク時にデータ移行を行うようにスケジューリングします。 テスト: 移行プロセスのテスト  – ステージング環境で徹底的なテストを実施し、潜在的な問題を特定し、移行プロセスを洗練します。 パフォーマンステスト  -実際のデータ転送を効率的に処理できるかを確認するために、負荷をかけて移行プロセスをテストします。 段階的な移行: 段階的なデータ移行  – 一度にすべてのデータを移行するのではなく、小さなチャンクに分割して移行することを検討します。このアプローチはリスクを低減し、移行スピードの改善に役立ちます。 レプリケーション  – 最終的な切り替えまで、新しいデータベースが古いデータベースと同期する状態を維持するために、データベースレプリケーションを使用します。 監視とバックアップ: 継続的な監視  – 問題やパフォーマンスのボトルネックがないか、移行プロセスを注意深く監視します。 バックアップ  – 万が一の場合に備えて、元のデータベースのバックアップを必ず取っておきます。 最終的な切り替えと検証: 切り替え  – すべてのデータが正確に転送され、新しいシステムの準備が整ったことを確認した後、最終的な切り替えを行います。 移行後の検証  – 新しいシステムのデータの整合性とパフォーマンスを確実に確認するため、徹底的なチェックを実施します。 データベースの移行はそれぞれ固有のものであり、前述の戦略は、個々の状況と要件に合わせてカスタマイズする必要があります。さらに、経験豊富なデータベース管理者や技術者のチームを巻き込むことで、スムーズかつ効率的な移行プロセスを実現できます。 まとめ このブログでは、Db2 から Amazon RDS for Db2 へ移行するためのリホストとリプラットフォームの戦略を示しました。リホストは、Db2MT を使用して既存システムへの変更を最小限に抑えながら Amazon RDS for Db2 に移行することを目指す組織にとって、簡単で効率の良いアプローチとなります。リプラットフォームは、フルロードと CDC を利用可能なAWS DMS または IBM Q Replication を利用可能な Db2MT を使用します。 どちらのアプローチも、アーキテクチャやアプリケーションの機能を変更する複雑さを伴わずに、Amazon RDS for Db2の強化されたスケーラビリティや潜在的なコスト削減などの即時の利点を提供します。また、Amazon RDS によるリホストまたはリプラットフォームは、AWS への移行の足がかりとなり、将来のモダナイゼーションおよび最適化の取り組みの基盤を築きます。 このブログにコメントをお寄せいただき、Db2 用 Amazon RDS に関する今後の投稿についてご要望をお聞かせください。 サービスの詳細は、 Amazon RDS for Db2 ユーザーガイド をご覧ください。 著者について Vikram S Khatri は Amazon RDS for Db2のシニアプロダクトマネージャーです。VikramはDb2に関して20年以上の経験を持っています。彼はゼロから新しい製品を開発することを楽しんでいます。余暇には瞑想やポッドキャストを聞くことを楽しんでいます。 翻訳は、Solution Architect の 野間が担当しました。 原文 はこちらです。

6月11日、 AWS CloudTrail Lake での生成人工知能 (生成 AI) を活用した自然言語クエリ生成のプレビュー版を発表できることを嬉しく思います。AWS CloudTrail Lake は、 AWS CloudTrail アクティビティログを取得、保存、アクセス、分析し、コンプライアンス、セキュリティ、運用上のニーズを満たすためのマネージドデータレイクです。CloudTrail Lake に保存されているこれらのアクティビティログ (管理イベントとデータイベント) について、自然言語を使用して質問できます。SQL クエリを作成する技術的な専門知識がなくても、またアクティビティイベントの正確な構造を解読するために時間を消費しなくてもかまいません。例えば、「スナップショットなしで削除されたデータベースインスタンスの数を教えてください」と尋ねると、機能によりその質問が CloudTrail Lake クエリに変換されます。このクエリは、そのまま実行することも、変更してリクエストしたイベント情報を取得することもできます。自然言語によるクエリ生成により、AWS アクティビティログの探索プロセスが簡単になります。 それでは、自然言語クエリ生成を使い始める方法を説明しましょう。 自然言語クエリ生成の開始方法 自然言語クエリジェネレーターは、生成 AI を使用してプロンプトからすぐに使用できる SQL クエリを生成します。このクエリは、CloudTrail Lake のクエリエディタで実行することを選択できます。 AWS CloudTrail コンソール では、 [Lake] (レイク) の下にある [Query] (クエリ) を選択します。クエリジェネレーターは、CloudTrail 管理イベントとデータイベントを収集するイベントデータストアのクエリのみを生成できます。CloudTrail Lake クエリのイベントデータストアを、 [Event data store] (イベントデータストア) のドロップダウンリストから選択します。 クエリジェネレーター では、自然言語を使用して [プロンプト] フィールドに次のプロンプトを入力します。 過去 1 か月間に記録されたエラーの数はどれくらいですか? 次に、 [Generate query] (クエリを生成) を選択します。次の SQL クエリが自動的に生成されます。 SELECT COUNT(*) AS error_count FROM 8a6*** WHERE eventtime >= '2024-04-21 00:00:00' AND eventtime <= '2024-05-21 23:59:59' AND ( errorcode IS NOT NULL OR errormessage IS NOT NULL ) [Run] (実行) を選択して結果を確認します。 これは面白く、もっと詳しく知りたいです。どのサービスで最もエラーが多かったか、なぜこれらのアクションがエラーになったのかを知りたいです。そこで、次のプロンプトを入力して追加の詳細をリクエストします。 過去 1 か月間に各サービスで記録されたエラーの数と、各エラーの原因は何でしたか? [Generate query] (クエリを生成) を選択すると、次の SQL クエリが生成されます。 SELECT eventsource, errorcode, errormessage, COUNT(*) AS errorCount FROM 8a6*** WHERE eventtime >= '2024-04-21 00:00:00' AND eventtime <= '2024-05-21 23:59:59' AND ( errorcode IS NOT NULL OR errormessage IS NOT NULL ) GROUP BY 1, 2, 3 ORDER BY 4 DESC; [Run] (実行) を選択して結果を確認します。 結果から、私のアカウントでは Amazon S3 に関連するエラーが最も多く、最も多いエラーは CORS とオブジェクトレベルの設定に関連していることがわかりました。さらに質問をすることで、さらに深く掘り下げて詳細を確認できます。しかし、今度は自然言語クエリジェネレーターに別の命令を与えましょう。 [Prompt] (プロンプト) フィールドに次のプロンプトを入力します。 過去 1 か月に使用した AWS サービスのトップ 10 はどれですか? イベント名も含めてください。 [Generate query] (クエリを生成) を選択すると、次の SQL クエリが生成されます。この SQL ステートメントは、フィールド名 ( eventSource 、 eventName 、 COUNT(*) AS event_count ) を取得し、 WHERE 句で過去 1 か月の日付間隔の行を制限し、行を eventSource と eventName でグループ化し、使用回数でソートし、自然言語で要求したように、結果を 10 行に制限します。 SELECT eventSource, eventName, COUNT(*) AS event_count FROM 8a6*** WHERE eventTime >= timestamp '2024-04-21 00:00:00' AND eventTime <= timestamp '2024-05-21 23:59:59' GROUP BY 1, 2 ORDER BY 3 DESC LIMIT 10; [Run] (実行) を選択して結果を確認します。 これで、過去 1 か月間に記録されたエラーの数、エラーの対象となったサービス、およびエラーの原因についての理解が深まりました。わかりやすい言葉で質問してみて、生成されたクエリをログに対して実行して、この機能がデータでどのように機能するかを確認できます。 プレビューをお試しください 自然言語クエリ生成は、 CloudTrail Lake の一部として米国東部 (バージニア北部) リージョンでプレビュー版として提供されています。 自然言語クエリ生成は、追加費用なしでプレビューで使用できます。CloudTrail Lake のクエリ料金は、クエリを実行して結果を生成する場合に適用されます。詳細については、 AWS CloudTrail の料金 をご覧ください。 自然言語クエリ生成の詳細と開始方法については、 AWS CloudTrail Lake ユーザーガイド をご覧ください。 — Esra 原文は こちら です。

6月11日、 Amazon Simple Storage Service (Amazon S3) 向け Amazon GuardDuty Malware Protection の一般提供についてお知らせします。これは、特定の S3 バケットへの悪意のあるファイルのアップロードを検出するための GuardDuty Malware Protection の拡張機能です。これまで、GuardDuty Malware Protection にはエージェントレススキャン機能があり、 Amazon Elastic Compute Cloud (Amazon EC2) とコンテナワークロードにアタッチされている Amazon Elastic Block Store (Amazon EBS) ボリューム上の悪質なファイルを特定していました。 これで、S3 バケットにアップロードされた新しいオブジェクトにマルウェアがないか継続的に評価し、見つかったマルウェアを隔離または排除するためのアクションを実行できます。Amazon GuardDuty Malware Protection は、 Amazon Web Services (AWS) が開発した、業界をリードする複数のサードパーティーマルウェアスキャンエンジンを使用して、Amazon S3 のスケール、レイテンシー、耐障害性を低下させることなくマルウェアを検出します。 GuardDuty Malware Protection for Amazon S3 では、指定した S3 バケットに組み込みのマルウェアとウイルス対策を使用できるため、悪意のあるファイルの評価を大規模に自動化することに伴う運用の複雑さとコストオーバーヘッドを排除できます。マルウェア分析に使用される既存の多くのツールとは異なり、GuardDuty のこのマネージドソリューションでは、マルウェア分析を実行したい各 AWS アカウントと AWS リージョンで、分離された独自のデータパイプラインやコンピューティングインフラストラクチャを管理する必要はありません。 開発チームとセキュリティチームが協力して、信頼できないエンティティから新たにアップロードされたデータをマルウェアスキャンする必要がある特定のバケットに対して、組織全体でマルウェア対策を設定して監視することができます。GuardDuty でオブジェクトのタグ付けなどのスキャン後のアクションを設定してダウンストリーム処理に役立てたり、 Amazon EventBridge から提供されたスキャンステータス情報を利用してアップロードされた悪意のあるオブジェクトを隔離したりできます。 S3 バケット向けの GuardDuty Malware Protection の開始方法 はじめに、 GuardDuty コンソール で [Malware Protection for S3] を選択し、 [Enable] (有効化) を選択します。 S3 バケット名を入力するか、 [Browse S3] (S3 を参照) をクリックして、現在選択されているリージョンに属するバケットのリストから S3 バケット名を選択します。選択したバケットに新しくアップロードされたすべてのオブジェクトを GuardDuty にスキャンさせたい場合は、 [All the objects in the S3 bucket] (S3 バケット内のすべてのオブジェクト) を選択できます。または、特定のプレフィックスに属する新しくアップロードされたオブジェクトをスキャンする場合は、 [Objects beginning with a specific prefix] (特定のプレフィックスで始まるオブジェクト) を選択することもできます。 新しくアップロードされた S3 オブジェクトをスキャンした後、GuardDuty は GuardDutyMalwareScanStatus というキーと以下のスキャンステータスの値を含む定義済みのタグを追加できます。 NO_THREATS_FOUND – スキャンされたオブジェクトに脅威は見つかりませんでした。 THREATS_FOUND – スキャン中に潜在的な脅威が検出されました。 UNSUPPORTED – このオブジェクトのサイズが原因で GuardDuty はスキャンできません。 ACCESS_DENIED – GuardDuty はオブジェクトにアクセスできません。許可を確認してください。 FAILED – GuardDuty はオブジェクトをスキャンできませんでした。 GuardDuty でスキャンした S3 オブジェクトにタグを追加したい場合は、 [Tag objects] (オブジェクトにタグ付け) を選択します。タグを使用すると、不正プログラム検索が完了する前にオブジェクトにアクセスされないようにするポリシーを作成し、アプリケーションが悪意のあるオブジェクトにアクセスするのを防ぐことができます。 次に、以下の必要な許可を含む AWS Identity and Access Management (IAM) ロールを先ず作成してアタッチする必要があります。 EventBridge アクションは、Malware Protection for S3 が S3 Event Notifications をリッスンできるように、EventBridge マネージドルールを作成および管理します。 Amazon S3 と EventBridge アクションは、このバケット内のすべてのイベントについて S3 Event Notifications を EventBridge に送信します。 Amazon S3 アクションは、アップロードされた S3 オブジェクトにアクセスし、スキャンされた S3 オブジェクトに定義済みのタグを追加します。 AWS Key Management Service (AWS KMS) キーアクションは、サポートされている DSSE-KMS と SSE-KMS を使用してテストオブジェクトをバケットにスキャンして配置する前に、オブジェクトにアクセスします。 これらの許可を追加するには、 [View permissions] (許可を表示) を選択し、ポリシーテンプレートと信頼関係テンプレートをコピーします。これらのテンプレートにはプレースホルダー値が含まれており、バケットと AWS アカウントに関連する適切な値に置き換える必要があります。AWS KMS キー ID のプレースホルダー値を置き換える必要もあります。 次に、 [Attach permissions] (許可をアタッチ) を選択すると、IAM コンソールが新しいタブに表示されます。新しい IAM ロールを作成するか、コピーしたテンプレートの許可で既存の IAM ロールを更新するかを選択できます。IAM ロールを事前に作成または更新したい場合は、AWS ドキュメントの「 前提条件 – IAM PassRole ポリシーの追加 」をご覧ください。 最後に、IAM コンソールが開いている GuardDuty ブラウザタブに戻り、作成または更新した IAM ロールを選択して、 [Enable] (有効化) を選択します。 これで、この保護されたバケットの保護 [Status] (ステータス) 列に「 Active 」と表示されます。 [View all S3 malware findings] (すべての S3 マルウェア検出結果を表示) を選択すると、スキャンされた S3 バケットに関連して生成された GuardDuty の検出結果が表示されます。「S3Object:S3/MaliciousFile」という検出結果タイプが返された場合、GuardDuty はリストに表示されている S3 オブジェクトを悪意のあるオブジェクトとして検出しました。 [Findings] (検出結果) の詳細パネルで [Threats detected] (検出された脅威) セクションを選択し、推奨される修復手順に従います。詳細については、AWS ドキュメントの「 Malware Protection for S3 の検出結果の修復 」をご覧ください。 知っておくべきこと AWS アカウントで GuardDuty が有効になっていなくても、S3 バケットに GuardDuty Malware Protection を設定できます。ただし、アカウントで GuardDuty を有効にすると、マルウェア保護機能を利用できるだけでなく、 AWS CloudTrail 管理イベント、 Amazon Virtual Private Cloud (Amazon VPC) フローログ、DNS クエリログなどの 基本的なソース を完全に監視できます。セキュリティの検出結果を AWS Security Hub と Amazon Detective に送信して、さらに調査することもできます。 GuardDuty は、S3 Standard、S3 Intelligent-Tiering、S3 Standard-IA、S3 One Zone-IA、および Amazon S3 Glacier Instant Retrieval という同期 Amazon S3 ストレージクラス に属するファイルをスキャンできます。マルウェアの拡散や封じ込めに使用されていることが知られているファイル形式をスキャンします。リリース時点では、この機能は最大 5 GB のファイルサイズをサポートします。これには、最大 5 レベルのアーカイブファイルと、解凍後 1 レベルあたり 1,000 ファイルが含まれます。 既に述べたように、GuardDuty は保護されている S3 バケットごとに EventBridge にスキャンメトリクスを送信します。アラームを設定し、オブジェクトにタグを付けたり、悪意のあるオブジェクトを検疫バケットに移動したりするなどのスキャン後のアクションを定義できます。 Amazon CloudWatch メトリクスや S3 オブジェクトのタグ付けなど、その他のモニタリングオプションの詳細については、AWS ドキュメントの「 マルウェアスキャンステータスのモニタリング 」をご覧ください。 今すぐご利用いただけます Amazon GuardDuty Malware Protection for Amazon S3 は、中国リージョンと GovCloud (米国) リージョンを除き、GuardDuty が利用可能な すべての AWS リージョン で現在一般的にご利用いただけます。 料金は、スキャンされたオブジェクトの GB ボリュームと 1 か月あたりに評価されたオブジェクトの数に基づいています。この機能では、新しい AWS アカウントの場合はアカウント作成の最初の 12 か月間、既存の AWS アカウントの場合は 2025 年 6 月 11 日までの条件に従って、毎月 1,000 件のリクエストと 1 GB の制限付きの AWS 無料利用枠をご利用いただけます。詳細については、「 Amazon GuardDuty の料金 」ページにアクセスしてください。 GuardDuty コンソール で GuardDuty Malware Protection for Amazon S3 をお試しください。詳細については、「 Amazon GuardDuty ユーザーガイド 」をご覧ください。また、 AWS re:Post for Amazon GuardDuty 宛てに、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 先週は幕張メッセで AWS Summit Japan を開催しました。ご参加頂けた方は楽しめたでしょうか？ 私は GenU (Generative AI Use Cases JP) の展示ブースに立ちながら、多くのお客様と直接お話しする機会がありました。その中で、お客様の AWS や生成 AI への関心の高さ、そして技術への情熱を肌で感じることができ、私自身も大いに刺激を受けました。 AWS Summit Japan の各セッションについて、 オンデマンド配信 がすでに開始されています。7/5 まで動画閲覧や資料ダウンロードができますので、ぜひご覧ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年6月17日週の主要なアップデート 6/17(月) Amazon EC2 C7i-flex instances are now available in US East (Ohio) Region Amazon EC2 で C7i-Flex インスタンスがオハイオリージョンで利用可能になりました。C6i インスタンスと比べて、最大 19 % のコストパフォーマンス向上を実現するタイプです。Flex インスタンス (M7i-Flex, C7i-Flex) は、従来のインスタンス (M7i, C7i) の低価格タイプとなっています。EC2 インスタンスを利用する際に、CPU 利用率は、低い時期と高い時期があるのが一般的だと考えられます。Flex インスタンスは、そういった常時 100 % の力を発揮しなくても良いような利用方法に適しているインスタンスタイプです。CPU 性能の 40 % はベースラインとして、常時提供します。ベースラインの 40 % を超える場合、95 % の確率で 100 % までスケールアップする仕組みを提供します。Web アプリケーションサーバー、データベース、仮想デスクトップ、バッチ処理、マイクロサービス、キャッシュといったユースケースでご検討いただけます。Flex インスタンスの特徴の詳細は、こちらの FAQ の「Flex instances」章もご覧ください。 AWS CodeBuild now supports organization and global GitHub webhooks AWS CodeBuild で、GitHub と GitHub Enterprise Server のグローバル Webhook がサポートされるようになりました。これにより個別のリポジトリごとに Webhook を設定することなく、単一の Code Build Webhook を設定するだけで組織内のすべてのリポジトリからイベントを受信できるようになりました。これらのイベントには、GitHub Actions のワークフロー実行、コミットのプッシュ、リリース、プルリクエストが含まれます。 AWS Systems Manager now supports additional Rocky, Oracle, and Alma Linux versions AWS Systems Manager で Rocky Linux、Alma Linux、Oracle Linux のバージョン 8.8 および 8.9 を実行しているインスタンスをサポートするようになりました。これにより、より多様な環境で Systems Manager を利用できるようになりました。Systems Manager は運用を支援するサービスであり、例えばインベントリ管理や、パッチ管理、遠隔アクセスの Session Manager などの機能が利用できます。 6/18(火) Amazon Connect Cases is now available in additional Asia Pacific regions Amazon Connect Cases が東京とソウルリージョンで利用できるようになりました。Amazon Connect Cases は電話を受けた担当者が、問い合わせケースを作成、共同作業のアサインなど、問い合わせを素早く解決するための管理機能を提供します。例えば、お客様から Amazon Connect に電話がかかってきた際に、担当者がお客様と会話しながら「問い合わせ概要」、「状況」、「問い合わせの詳細」を入力する機能を提供します。また、作成した問い合わせケースは、お客様名や電話番号で検索ができ、過去の対応履歴を検索、閲覧することも可能です。 CodeCatalyst allows customers to use Amazon Q Developer to choose a blueprint Amazon Q Developer in Amazon CodeCatalyst の一般提供を開始しました。CodeCatalyst にはブループリントと呼ばれる、Project テンプレートを管理、作成、利用する機能があります。ソースコードや CI/CD ワークフローを組織の形に合わせてテンプレート化しておくことで、新しい開発作業を始める際にテンプレートを流用できるメリットがあります。このアップデートで、自然言語を使って「お客様の実現したい内容」を記載すると、それに基づいたブループリントをガイドしてくれるようになりました。 Introducing Maven, Python, and NuGet support in Amazon CodeCatalyst package repositories Amazon CodeCatalyst のパッケージリポジトリで、Maven、Python、NuGet パッケージをサポートしました。パッケージリポジトリは、社内独自のライブラリなどをパッケージ化することで、社内に限定した公開や管理ができるようになります。 Amazon Redshift announces support for VARBYTE 16MB data type Amazon Redshift の VARBYTE 型のデータサイズ上限が、1 MB から 16 MB に増えました。VARBYTE は可変長バイナリ文字列を格納および表現するための可変サイズのデータ型です。例えば、画像データを直接バイナリデータとして Redshift に格納することで、アプリケーションから見ると実装がシンプルになるメリットが考えられます。 6/19(水) Amazon CodeCatalyst now supports GitHub Cloud and Bitbucket Cloud with Amazon Q Amazon CodeCatalyst は、Amazon Q と連携することで、課題 (Issue) を解決する Pull Request を自動生成する機能があります。今回のアップデートで、CodeCatalyst でリンク設定した GitHub Cloud および Bitbucket Cloud 上のリポジトリに対して、Amazon Q の連携機能が提供されました。CodeCatalyst 上で GitHub や Bitbucket のリポジトリと連携する機能が、Amazon Q によって強化された形になります。 AWS Glue adds additional 13 new transforms including flag duplicates AWS Glue で新たに 13 個の組み込み変換機能が追加されました。重複している列や行をフラグ付け、電話番号の書式設定、大文字小文字の書式設定、最頻値で埋める、重複を削除、月名、偶数かどうか、暗号化ハッシュ、復号化、暗号化、数値を IP アドレスに変換、などがあります。データを加工したい方が変換フローを作り上げるときに、より多くのアクションを利用できるようになり、素早く構築しやすくなりました。 Amazon SageMaker now offers a fully managed MLflow Capability Amazon SageMaker で MLflow をフルマネージドな形で提供開始しました。Mlflow は機械学習の実験管理を支援するポピュラーなオープンソースツールです。データサイエンティストは、馴染みのある MLflow を利用して、ML実験を整理、追跡、分析できます。また、SageMaker 上で利用することで、高いスケーラビリティ、可用性、セキュリティ向上、といったメリットがあります。詳細は こちらの Blog をご覧ください。MLflow 機能は追加料金が設定されております。 Price ページ の「MLflow」タブもご覧ください。 6/20(木) Anthropic’s Claude 3.5 Sonnet model now available in Amazon Bedrock Amazon Bedrock で Anthropic 社の最新モデル Claude 3.5 Sonnet を一般提供開始しました。Anthropic で一番知能の高いモデルとなっており、Claude 3 Opus を上回る性能を発揮しながら、Opus の 1/5 のコストでご利用いただけます。Claude 3.5 Sonnet の主な特徴は、画像を利用したときの処理や理解能力の向上、より自然で人間らしい雰囲気の高品質な文章生成、文脈を理解しながらマルチステップの処理能力の向上などがあります。バージニア北部リージョンでご利用いただけます。詳細はこちらの リリースブログ をご覧ください。 Amazon Bedrock now supports compressed embeddings from Cohere Embed Amazon Bedrock で Cohere Embed モデルを利用してベクトルを生成する際に、圧縮された埋め込み (int8, binary) をサポートしました。この圧縮された埋め込みを使用することで、ベクトル検索エンジンに埋め込みを保存して利用する際に、パフォーマンスの向上、ストレージコストの削減といったメリットがあります。一般的に利用される FP32 精度形式に比べて大幅に小さいサイズですが、精度の低下は最小限に抑えられています。ユースケースの一つとして、マルチテナント SaaS の裏側で大規模なベクトルデータを構成する際に、より高速なパフォーマンスを提供しやすくなる使い方が考えられます。 6/21(金) Amazon SageMaker JumpStart now provides granular access control for foundation models Amazon SageMaker JumpStart で数百の基盤モデルを素早くデプロイするための機能が提供されています。この基盤モデルに対して、きめ細かいアクセス制御を簡単に設定できるようになりました。ユースケースを挙げると、Apache 2.0 のライセンスモデルのみ組織内で利用可能にしたいときなどがあります。現在は、オハイオリージョンでご利用いただけます。詳細はこちらの Blog をご覧ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です