IAM Access Analyzer をさらに強力にし、カスタムポリシーチェックを拡張し、IAM ポリシーの微調整に役立つガイダンスに簡単にアクセスできるようにしました。これらの新機能はどちらも、re:Invent 2023 で開始された カスタムポリシーチェックと未使用アクセス分析 に基づいています。こちらが弊社が立ち上げるものです。 新しいカスタムポリシーチェック – 自動推論の力を利用した新しいチェックは、特定の重要な AWS リソースへのアクセスを許可するポリシー、またはあらゆる種類のパブリックアクセスを許可するポリシーを検出するのに役立ちます。どちらのチェックも、デプロイ前に、おそらく CI/CD パイプラインの一部として使用するように設計されており、組織のセキュリティ慣行やポリシーに準拠していない更新を積極的に検出するのに役立ちます。 ガイド付き取り消し – IAM Access Analyzer では、実際には必要のないアクセス権を付与する許可を取り消せるようガイダンスを提供し、デベロッパーと共有できるようになりました。これには、未使用のロール、未使用の許可を持つロール、IAM ユーザーの未使用のアクセスキー、IAM ユーザーの未使用のパスワードが含まれます。ガイダンスには、余分な項目を削除するか、より制限の厳しい項目に置き換えるために必要な手順が含まれています。 新しいカスタムポリシーチェック 新しいポリシーチェックは、コマンドラインから、または API 関数を呼び出すことで呼び出すことができます。チェックは、リクエストの一部として提供されたポリシードキュメントを検証し、 PASS または FAIL の値を返します。いずれの場合も、 PASS はポリシー文書が特定のアクセスを適切に拒否していることを示し、 FAIL はポリシーが許可の一部またはすべてを許可している可能性があることを示します。新しいチェックは次のとおりです。 パブリックアクセスがないことのチェック – このチェックはリソースポリシーに対して実行され、ポリシーが指定されたリソースタイプへのパブリックアクセスを許可しているかどうかを確認します。例えば、 AWS::S3::Bucket リソースタイプを指定することで、ポリシーで S3 バケットへのパブリックアクセスが許可されているかどうかを確認できます。有効なリソースタイプには、DynamoDB テーブルとストリーム、EFS ファイルシステム、OpenSearch ドメイン、Kinesis ストリームとストリームコンシューマー、KMS キー、Lambda 関数、S3 バケットとアクセスポイント、S3 Express ディレクトリバケット、S3 Outposts バケットとアクセスポイント、Glacier、Secrets Manager シークレット、SNS トピックとキュー、ロールを引き受ける IAM ポリシードキュメントなどがあります。有効なリソースタイプのリストは、時間が経つにつれて拡大していく予定で、 CheckNoPublicAccess のドキュメントに記載されています。 Amazon Simple Queue Service (Amazon SQS) キューへのパブリックアクセスを誤って許可するポリシーがあるとします。確認方法は次のとおりです。 $ aws accessanalyzer check-no-public-access --policy-document file://resource.json \ --resource-type AWS::SQS::Queue --output json 結果は、次のとおりです。 { "result": "FAIL", "message": "The resource policy grants public access for the given resource type.", "reasons": [ { "description": "Public access granted in the following statement with sid: SqsResourcePolicy.", "statementIndex": 0, "statementId": "SqsResourcePolicy" } ] } ポリシーを編集して付与したアクセス権を削除して再試行すると、今度はチェックに合格しました。 { "result": "PASS", "message": "The resource policy does not grant public access for the given resource type." } アクセス権が付与されていないことのチェック – このチェックは、一度に 1 つのリソースポリシーまたは ID ポリシーに対して実行されます。また、アクションとリソースのリストも受け付けます。いずれも IAM ポリシーの一部として受け入れられる形式です。このチェックでは、ポリシーが、リスト内のリソースへの意図しないアクセスを、リスト内のアクションによって許可していないかどうかを確認します。例えば、このチェックを使用して、ポリシーで重要な CloudTrail 証跡の削除が許可されていないことを確認できます。 $ aws accessanalyzer check-access-not-granted --policy-document file://ct.json \ --access resources="arn:aws:cloudtrail:us-east-1:123456789012:trail/MySensitiveTrail" \ --policy-type IDENTITY_POLICY --output json IAM Access Analyzer は、次のように、チェックが失敗したことを示しています。 { "result": "FAIL", "message": "The policy document grants access to perform one or more of the listed actions or resources.", "reasons": [ { "description": "One or more of the listed actions or resources in the statement with index: 0.", "statementIndex": 0 } ] } ポリシーを修正して再試行すると、今度はチェックに合格します。このことから、ポリシーがリストされたリソースへのアクセスを許可していないことがわかります。 { "result": "PASS", "message": "The policy document does not grant access to perform the listed actions or resources." } ガイド付き取り消し 以前の記事では、IAM Access Analyzer が、実際には必要のないアクセス権を付与する IAM 項目を検出して一覧表示する方法を説明しました。本日のリリースにより、ユーザー (または開発チーム) がこのような検出結果を解決するのに役立つガイダンスを得られます。私の AWS アカウントの最新の検出結果は次のとおりです。 これらの中には、あるサービスへの早期アクセス権を与えられ、そのサービスを利用してブログを書いたときの残り物もあれば、私がクラウド管理者として一般的に無能だったことが原因のものもあります。 どちらにせよ、これらをクリーンアップしないといけません。2 つ目の「 未使用のアクセスキー 」から始めましょう。項目をクリックすると、下部に新しい [Recommendations] (レコメンデーション) セクションが表示されます。 手順に従ってアクセスキーを削除することも、 [Archive] (アーカイブ) をクリックして検出結果をアクティブな結果のリストから削除し、アーカイブされた検出結果のリストに加えることもできます。今後似たような検出結果に対して同じことをするアーカイブルールを作成することもできます。未使用の IAM ユーザー、IAM ロール、およびパスワードについても同様のレコメンデーションが提供されています。 それでは、 未使用の許可 の検出結果について見てみましょう。 レコメンデーションは既存のポリシーを新しいポリシーに置き換えることです。次のように、新しいポリシーを既存のポリシーと並べてプレビューできます。 最初の例のように、手順に従うことも、検出結果をアーカイブすることもできます。 検出結果とレコメンデーションは、コマンドラインからも確認できます。次のように、アナライザーとその検出結果を指定してレコメンデーションを生成します。 $ aws accessanalyzer generate-finding-recommendation \ --analyzer-arn arn:aws:access-analyzer-beta:us-west-2:123456789012:analyzer/MyAnalyzer \ --id 67110f3e-05a1-4562-b6c2-4b009e67c38e 次に、レコメンデーションを取得します。この例では、JSON 出力全体がかなり充実しているので、ステップのみを表示するように出力をフィルタリングしています。 $ aws accessanalyzer get-finding-recommendation \ --analyzer-arn arn:aws:access-analyzer-beta:us-west-2:123456789012:analyzer/MyAnalyzer \ --id 67110f3e-05a1-4562-b6c2-4b009e67c38e --output json | \ jq .recommendedSteps[].unusedPermissionsRecommendedStep.recommendedAction "CREATE_POLICY" "DETACH_POLICY" これらのコマンド (または同等の API コール) を使用して、レコメンデーションを独自のツールやシステムに統合できます。 今すぐご利用いただけます 新しいチェックと解決手順がご利用いただけるようになり、すべてのパブリック AWS リージョンで今すぐ利用を開始できます。 – Jeff ; 原文は こちら です。

セキュリティは Amazon Web Services (AWS) の最優先事項であり、6月11日、お客様の AWS アカウントのセキュリティ体制を強化するのに役立つ 2 つの機能をリリースします。 まず、ルートユーザーと AWS Identity and Access Management (IAM) ユーザー向けに、サポート対象の 多要素認証 (MFA) のリストに パスキー を追加します。 次に、ルートユーザーに MFA を適用 し始めました。最も機密性の高いユーザー、つまり AWS Organization の 管理アカウント のルートユーザーから始めました。2024年の残りの期間中に、この変更を他のアカウントにも引き続き適用します。 MFA は、アカウントのセキュリティを強化する最も簡単で効果的な方法の 1 つであり、保護層をさらに強化して権限のない個人がシステムやデータにアクセスするのを防ぎます。 ルートユーザーと IAM ユーザー用のパスキー付きの MFA パスキーは、 FIDO2 認証用に作成された認証情報に使用される一般的な用語です。 パスキーは、サービスまたはウェブサイトに登録したときにクライアントデバイス上で生成される一組の暗号化キーです。キーペアはウェブサービスドメインにバインドされ、それぞれ一意です。 キーのパブリック部分はサービスに送信され、サービス側に保存されます。キーのプライベート部分は、 セキュリティキー などの安全なデバイスに保存されるか、 iCloud キーチェーン 、 Google アカウント 、または 1Password などのパスワードマネージャーといったクラウドサービスを使用するときに、ユーザーアカウントに接続されたデバイス間で安全に共有されます 。 通常、キーのプライベート部分へのアクセスは、デバイスに応じて、PIN コードまたは生体認証 (Apple Face ID 、 Touch ID 、 Microsoft Hello などの生体認証) によって保護されます。 パスキーで保護されているサービスで認証しようとすると、サービスがブラウザに課題を送信します。その後、ブラウザは私のデバイスにプライベートキーを使って課題に署名するように要求します。これにより、PIN または生体認証がトリガーされ、プライベートキーが保存されている安全なストレージにアクセスします。ブラウザは署名をサービスに戻します。署名が有効であれば、サービスに保存されているパブリックキーと一致するプライベートキーを所有していることが確認され、認証が成功します。 このプロセスと現在使われているさまざまな標準 ( FIDO2 、 CTAP 、 WebAuthn ) の詳細については、 2020 年 11 月に AWS IAM アイデンティティセンターでパスキーのサポートを開始したときに私が書いた記事 を参照してください。 パスキーはパスワードの代わりに使用できます。ただし、今回の初回リリースでは、パスワードに加えてパスキーを第二要素認証として使用することにしました。パスワードは知っているもので、パスキーは持っているものです。 パスキーはパスワードよりもフィッシング攻撃に対する耐性が高くなります。まず、指紋、顔、または PIN コードで保護されたプライベートキーにアクセスするのがはるかに困難です。次に、パスキーは特定のウェブドメインにバインドされるため、意図せず開示された場合の範囲が狭まります。 エンドユーザーは、使い勝手が良く、簡単に復元できるというメリットがあります。携帯電話やノートパソコンに組み込まれている認証システムを使用して、暗号化で保護された認証情報をロック解除して AWS サインインを行うことができます。また、クラウドサービス (iCloud キーチェーン、Google アカウント、1Password など) を使用してパスキーを保存すると、パスキープロバイダーのアカウントに接続されているどのデバイスからでもパスキーにアクセスできます。これにより、不幸にもデバイスを紛失した場合に、パスキーを回復できます。 IAM ユーザーのパスキー MFA を有効にする方法 パスキー MFA を有効にするには、コンソールの AWS Identity and Access Management (IAM) セクションに移動します。ユーザーを選択し、ページを下にスクロールして [Multi-factor authentication (MFA)] (多要素認証 (MFA)) セクションに移動します。次に、 [Assign MFA device] (MFA デバイスの割り当て) を選択します。 耐障害性とアカウントの回復を強化するために、 1 人のユーザーに対して複数の MFA デバイスを有効にできます 。 次のページで [MFA device name] (MFA デバイス名) を入力し、 [Passkey or security key] (パスキーまたはセキュリティキー) を選択します。その後、[Next] (次へ) を選択します。 パスキーをサポートするパスワードマネージャーアプリケーションを使用すると、ポップアップが表示され、そのアプリケーションを使用してパスキーを生成して保存するかどうかを尋ねてきます。そうしない場合、ブラウザにいくつかのオプションが表示されます。画面の正確なレイアウトは、オペレーティングシステム (macOS または Windows) と使用するブラウザによって異なります。これは、Chromium ベースのブラウザを搭載した macOS で表示される画面です。 残りの操作は、選択内容によって異なります。 iCloud キーチェーン は、パスキーを生成して保存するための Touch ID の入力を促します。 このデモでは、電話などの別のデバイスでパスキーをブートストラップする方法を説明します。そこで、代わりに [Use a phone, tablet, or security key] (スマートフォン、タブレット、またはセキュリティキーを使用する) を選択します。ブラウザに QR コードが表示されます。次に、携帯電話を使用して QR コードをスキャンします。電話が Face ID で私を認証し、パスキーを生成して保存します。 この QR コードベースのフローでは、あるデバイスのパスキーを使用して別のデバイス (デモでは電話とノートパソコン) にサインインできます。これは FIDO 仕様で定義されており、 クロスデバイス認証 (CDA) として知られています。 すべてがうまくいけば、IAM ユーザーのパスキーが登録されます。 IAM ユーザーを使って AWS コンソールで人を認証することはお勧めしません。代わりに AWS IAM アイデンティティセンター でシングルサインオン (SSO) を設定することをお勧めします。 サインインエクスペリエンスはどのようなものですか? MFA を有効にしてパスキーを設定したら、アカウントにサインインしてみます。 ユーザーエクスペリエンスは、使用するオペレーティングシステム、ブラウザ、およびデバイスによって異なります。 例えば、iCloud キーチェーンが有効になっている macOS では、Touch ID キーをタッチするようにシステムから求められます。このデモでは、CDA を使用して携帯電話にパスキーを登録しました。そのため、携帯電話で QR コードをスキャンするようにシステムから求められます。スキャンが完了すると、電話の Face ID で認証してパスキーのロックを解除し、AWS コンソールによりサインイン手順が終了します。 ルートユーザーに MFA の使用を強制する 6月11日 2 つ目の発表は、一部の AWS アカウントのルートユーザーに MFA の使用を強制し始めたことです。この変更は昨年、 Amazon の最高セキュリティ責任者である Stephen Schmidt のブログ記事 で発表されました。 Schmidt の言葉を引用すると: AWS で最も権限のあるユーザーが MFA で保護されていることを確認することは、AWS のお客様のセキュリティ体制を継続的に強化するという当社の取り組みの新たな一手に過ぎません。 まず、最も機密性の高いアカウントである AWS Organizations の管理アカウントから始めました。ポリシーの導入は段階的に行われ、一度に数千のアカウントに対してしか行えません。今後数か月にわたって、大部分の AWS アカウントのルートユーザーに MFA 強制ポリシーを段階的に導入する予定です。 ルートユーザーアカウントで MFA を有効にしていない状態でアカウントが更新されると、サインイン時に MFA を有効にするように求める新しいメッセージがポップアップで表示されます。猶予期間があり、その後は MFA が必須になります。 中国を除くすべての AWS リージョンで、今日からパスキーを多要素認証に使用できるようになりました。 中国の 2 つのリージョン (北京、寧夏) と AWS GovCloud (米国) を除くすべての AWS リージョンで多要素認証の使用を強制します。これらのリージョンの AWS アカウントにはルートユーザーがいないためです。 次に、 アカウントのルートユーザーのためにパスキー MFA を有効にします 。 — seb 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 6月20日から21日にかけて AWS Summit Japan が開催されました！たくさんの方にご来場頂き、本当にありがとうございました。初日の基調講演では生成AIに関するニュースをお届けしました。お客様事例登壇も大変興味深いものでしたので、ご覧になっていない方は7/5までオンデマンドで配信中の動画をぜひご覧ください。ここではサービス関係のお知らせをまとめていきましょう。 7月中に、東京リージョンのAmazon BedrockでAnthropic Claude 3をご利用可能に 2024年中に、Amazon Q Businessの日本語正式サポートと東京リージョン対応を実施 生成AI実用化推進プログラムを発表。基盤モデル自体を開発・カスタマイズする方と、既存のモデルを活用してプロダクトやソリューションの機能や価値を高めたい方の両方を支援（詳細は近日発表） また、日本時間の6月20日から21日にかけて、 AnthropicからClaude 3.5 Sonnetが発表 されました。このモデルはバージニアリージョンのAmazon Bedrockを介してご利用頂けるようになっていますので、こちらもご注目ください。 それでは、6 月 17 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「Anthropic’s Claude 3.5 Sonnet model now available in Amazon Bedrock: Even more intelligence than Claude 3 Opus at one-fifth the cost」を公開 冒頭でも書きましたが、 AnthropicのClaude 3.5 Sonnetが発表 され、バージニアリージョンの Amazon Bedrock にてご利用頂けるようになっています。Claude 3.5 SonnetはClaude 3 Opusよりも高いベンチマークスコアを記録する高い能力を発揮すると同時に、Opusよりも80%安価にご利用頂けるとされています。用途に応じて適したモデルを選べるのがAmazon Bedrockの価値のひとつですので、Anthropicのモデルもそうですが他の多言語対応をうたっているモデル、例えばCohere Command R/R+などと比較し、最適なものを選択しましょう。 AWS生成AI国内事例ブログ: 株式会社ナウキャスト様、決算短信データ抽出業務にLLMを適用 株式会社ナウキャスト様は、POSデータやクレジットカードの決済データを解析し、生活者の消費行動や企業活動をより早く正確に捉えるデータソリューションの提供に取り組んでいます。そのためにはデータが必要不可欠ですが、膨大な適時開示資料から人力でデータ抽出を行っており、作業負担が課題になっていました。ナウキャスト様はLLM(大規模言語モデル)を自然言語の処理技術として捉え、適したタスクの見極めを行うことを考え、「セグメント別売り上げ情報抽出」が適したタスクのひとつだと判断、Amazon Bedrockを介したClaude 2で処理を行うこととしました。それによって抽出精度90%を達成、作業工数を50%削減という結果を達成しています。またローコード開発ツールStreamlitとAWSのマネージドサービスを活用し、担当者1名という限られたリソースで短時間の開発と検証を実施したそうです。今後は対象業務と銘柄の拡大を行い、データ単体のマネタイズやオペレーション自体の顧客への提供を考えているとのことです ブログ記事「非構造化金融データに隠された関連性を Amazon Bedrock と Amazon Neptune で発見する」を公開 先週公開されたブログですが、ピックアップ漏れがあったので今回紹介します。生成AIの適用が期待される領域に、データから新たな洞察（インサイト）を得るというものがあります。このブログ記事では、フルマネージドなグラフDBのサービスである Amazon Neptune と、 Amazon Bedrock の生成AIモデルを活用することにより、金融データに隠れたデータ間の関連性を見いだす方法を解説するものです。 サービスアップデート AnthropicのClaude 3.5 SonnetがAmazon Bedrockで利用可能に 既にお知らせしているように、AnthropicのClaude 3.5 SonnetがバージニアリージョンのAmazon Bedrockでご利用頂けるようになりました。 Amazon BedrockがCohere EmbedモデルによるCompressed Embeddingsをサポート Amazon BedrockでCohereのEmbedを利用したCompressed Embeddingsに対応しました。これは検索拡張生成(RAG)やセマンティック検索で利用されるケースが多い機能で、生成AIを組み込んだアプリケーションを効率化します。一般的にはEmbeddings形式のデータは、FP32(32ビット浮動小数点数)で表現されますが、Compressed EmbeddingsはINT8(8ビット整数)またはバイナリで表現します。これらのデータはFP32よりもサイズが小さく、ベクトルデータベースへの負荷や検索の時間的・費用的コストを抑えることが可能です。生成AIアプリケーションの大規模展開を考えるとベクトルデータベースへの負荷が課題になるケースがあり、そういった場合に検討できる対策のひとつといえます。 Amazon SageMakerでフルマネージドなMLflow機能を提供開始 MLflowは機械学習のライフサイクル管理で利用されるオープンソースツールのひとつです。今回、SageMakerでフルマネージドなMLflowのトラッキングサーバーを利用できるようになりました。MLflowへのアクセスはAWS IAMによって制御可能で、開発者の方は使い慣れたMLflowを利用した実験・分析を容易に実行できます。 Amazon SageMaker HyperPodがクラスタストレージのカスタマイズに対応 Amazon SageMaker Hyperpod はモデルの分散トレーニングのためのインフラストラクチャの構築と最適化を容易にする仕組みです。今回、SageMaker Hyperpodで構築されるクラスタのストレージがカスタマイズ可能になり、一般的なユースケースよりも大容量のストレージを必要とする場合にも対応できるようになりました。 Amazon SageMaker JumpStartで基盤モデルに対する詳細なアクセス制御が可能に Amazon SageMaker JumpStartは生成AIを支える基盤モデルをなど学習済みのモデルをすぐに起動できる枠組みで、機械学習に関するタスクを素早く始めることを可能にするハブとして機能します。今回、管理者が組織内のユーザに対して利用できる基盤モデルを細かく制御できるようになりました。SageMaker SDKを利用してSageMaker JumpStartにプライベートなハブを作成し、ユーザが利用してよいモデルだけを登録できるようになりました。これによって、例えばApahce 2.0ライセンスのもののみ触って良い、といったルールを適用することが容易になります。 Amazon CodeCatalystでブループリントの選択にAmazon Qを活用可能に Amazon CodeCatalyst はAWSで稼働するシステムの構築・開発を迅速化する統合ソフトウェア開発サービスです。CodeCatalystを利用して開発を開始する方法のひとつが、プロジェクトのひな形のようなブループリントを利用する方法です。これまではブループリントの説明文を読んで適しているものを判断する必要がありましたが、Amazon Qとの統合により自然言語でプロジェクトの概要を説明することで、適したブループリントを提案してくれるようになりました。 Amazon CodeCatalystがAmazon Qによる問題分析と推奨されるタスク分割の出力に対応 Amazon CodeCatalystがAmazon Qとの統合を強化し、問題の分析と推奨されるタスク分割を提案することが可能になりました。従来、プロジェクトにおけるタスクは主導で作成する必要がありましたが、今回のアップデートで問題の複雑さをAmazon Qに分析させ、作業を詳細タスクに分割するアイデアを提示してもらうことが可能になりました。 Amazon CodeCatalystがGitHub CloudとBitbucket CloudとAmazon Qの連携に対応 Amazon CodeCatalystで、GitHub CloudやBitbucket Cloudに保存されたソースコードレポジトリに対してAmazon Qによる開発支援が可能になりました。CodeCatalystで管理されるタスクをAmazon Qに割り当てることによって、これらのサービスで保存されるコードを分析し、対応計画を作成し、プルリクエストを生成できます。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

本ブログは、株式会社ココペリと Amazon Web Services Japan が共同で執筆しました。 株式会社ココペリ は「中小企業にテクノロジーを届けよう」というビジョンのもとサービスを提供しています。より多くの価値提供を行うための活動が実施されており、提供サービスの一つである 中小企業 DX 支援プラットフォーム「Big Advance」 の体験向上を狙う施策も期待されていました。 Big Advance にはビジネスマッチング機能やホームページ作成など複数の機能が搭載されています。これらの機能が有効に活用されることで、利用者のビジネス課題が効率よく解決されることに寄与します。ココペリ社は、利用者がより効率よく機能を活用できるように AI/ML 技術を使った施策を検討し価値提供を試みていました。一方で、AI/ML の活用は技術的な側面のみならずビジネス視点での成長戦略が必要です。Big Advance 利用者への価値提供とともにココペリ社の成長が行えるような AI/ML の活用施策の考案が求められていました。 ML Enablement Workshop による生成 AI のユースケースの特定 このような背景から、ココペリ社は AWS とともに  ML Enablement Workshop (MLEW) を実施しました。MLEW は AWS が開発しメンテナンスしているワークショップです。このワークショップは、プロダクトを AI/ML によって成長させるロードマップの作成を支援します。MLEW では、技術者だけでなくプロダクトマネージャーに代表される企画・ビジネス側の役職も交えた議論が行われます。ココペリ社は、データサイエンティスト、エンジニアやプロダクトマネージャーに加えて、カスタマーサクセスも参加し議論を行いました。 ココペリ社は MLEW での顧客体験分析を通じて、Big Advance のビジネスマッチング機能に着目し、生成 AI のユースケースを特定しました。ビジネスマッチング機能は、自社のビジネス上の要望を「ニーズ」として登録し、Big Advance 上に公開することができるものです。公開すると、6万を超える全国の会員企業がそのニーズを閲覧し商談を申し込むことができるため、販路拡大や新規取引先の開拓が期待できます。 効率の良いビジネスマッチングを行うには各企業が自社の特徴を捉えたニーズを作成することが重要ですが、一からニーズの文章を書き上げるのはハードルが高いことが示唆されました。 このことからニーズ作成のハードルの高さを解消することを目標とし、生成 AI によるニーズ自動作成を重要度の高い施策として検証を開始しました。 役職を横断した連携が可能にした生成 AI の検証 生成 AI による課題解決の検証では、成果物の評価が重要になります。今回の検証の評価は、MLEW に参加したカスタマーサクセスとの強固な連携によって実施されました。 生成 AI によるニーズの自動作成では、出力されたニーズの文章が登録する企業の特徴を捉えたものであるかが評価軸になります。これらの評価には顧客の実務に基づいた評価が必要になります。ココペリ社においてはカスタマーサクセスが顧客の実務を深く理解しているため、カスタマーサクセスが成果物を評価することが有効な判断軸であると言えました。今回の MLEW においてはカスタマーサクセスが参加したことで、これらの連携が円滑に行えています。 ニーズ作成の精度向上を行うために、処理の追加や複数の大規模言語モデルの比較などを行いました。最終的に、生成 AI への入力データとして事前のスクレイピングなどを行い（下図参照）、また Amazon Bedrock で利用可能な Anthropic 社 が提供する大規模言語モデル (LLM) Claude 2.1 を利用することで、社内の評価で 97.9% の採択率となりました。 このワークフローによって出力された結果は以下のようになっており、企業の特徴を捉えた具体的な内容を出力することができているとの評価となりました。 [詳細] 【事業の詳細】 金融機関が連携し、都道府県や金融機関の垣根を超えたビジネスネットワークで、中小企業の経営課題の解決を支援いたします。ビジネスマッチング、ビジネスチャット、ホームページ作成等の機能を月額定額で提供しております。 【キャッチコピー】 ビジネスをもっとシンプルに、楽に #ITサービス #中小企業 #金融 [対象] 中小企業 [ひとことメッセージ] 【事業の強み】 全国の金融機関との連携 【事業への思い】 中小企業の成長支援に情熱を注いでおります 【価格目安】 月額3,300円(税込) 以上の試みは ビジネスマッチングでの Claude による文章生成 に、より詳しく記載されています。 上記のワークフローは複数の処理が実行されますが、 AWS Step Functions や AWS Lambda といった AWS のサービスと Amazon Bedrock の連携によって、ワークフローの自動化を実現しています。 今後の展望 検証結果を受けてニーズ生成機能の社内利用を開始しており、今後はワークフローを洗練した上でプロダクトへの機能実装を計画しています。この技術を活用、改善していくことで精度の高いニーズを容易に作成できるようになり、Big Advance のビジネスマッチングにおける顧客体験をより向上させることを目指していきます。 まとめ 以上のようにココペリ社は MLEW での分析を通じ、Big Advance の顧客に最もインパクトのある生成 AI のユースケースを特定し、その検証を行いました。同社からは「MLEW での顧客体験分析を通じ、Big Advance の顧客に最もインパクトのある生成 AI の用途を特定しタスクと効果測定 KPI を決めることができました」との言葉を頂いています。 検証では、MLEW を通して技術・ビジネスの双方の領域の参加者が強固に連携し、顧客体験に寄り添った精度評価を行うことができました。ココペリ社では、今後も役職を横断した連携と AI/ML 技術、 AWS のテクノロジーを活用し、中小企業のビジネス支援を推し進めていく考えです。

本記事は 2023年11月26日に AWS DevOps Blog で公開された ” Automate safe AWS CloudFormation deployments from GitHub ” を翻訳したものです。翻訳は Partner Sales Solutions Architect の 福井 敦 が担当しました。 AWS CloudFormation は、Infrastructure as Code (IaC) サービスで、AWS およびサードパーティのリソースをモデル化、プロビジョニング、管理できます。新しくトラッキングしている Git リポジトリが更新されるたびに、 Git 同期 によって自動的にデプロイメントがトリガーされるようになりました。 これにより、開発者は Git ワークフローに統合し、コンテキストの切り替えによる時間の浪費を減らすことで、CloudFormation の開発サイクルを大幅に高速化できます。この新しい Git 同期は、 GitHub 、 GitHub Enterprise 、 GitLab 、 Bitbucket に対応しています。 この投稿では、GitHub のネイティブツールと CloudFormation の Git 同期を使った最新の開発体験について説明します。 GitHub CodeSpaces を使用してクラウド開発環境を作成し、 GitHub Actions と CloudFormation Linter を使用して プルリクエスト に直接フィードバックし、安全なデプロイを自動化します。 要件 AWS アカウントを所有していること。 Amazon Virtual Private Cloud (Amazon VPC) リソースをデプロイします。AWS アカウントには通常リージョン毎に 5 つまでの VPC が作成できますが、制限を引き上げることが可能です。 GitHub アカウントと、 Codespaces 、 Actions を利用できること。これらは無料利用枠がありますが、制限を超えると課金される可能性があります。 デベロッパーツールで GitHub への接続を作成 しておくこと。 空のリポジトリの作成 今回は、新しい GitHub リポジトリから始めます。GitHub では無料で新しい Git リポジトリを作成できます。この例では、 git-sync という名前のリポジトリを作成します。 Codespace の設定 リポジトリを作成すると、Codespace を作成するオプションが表示されます。Codespace は GitHub が管理するリモートの開発環境で、設定済の仮想マシン環境でどこからでも開発できます。 Codespaces は、 Visual Studio Code を選択したコードエディターとして利用します。Visual Studio Code は拡張機能をインストールできるため、非常に柔軟で拡張性に優れたオープンソースのコードエディターです。 作成が完了したら、ローカルの開発環境と同様に環境を設定できます。テンプレート開発時に、エディタ内で即座にフィードバックを得られるよう CloudFormation Linter 拡張機能を追加します。 これにより、検証のためテンプレートを CloudFormation に送信する必要はなく、送信する前にテンプレートが有効であることを確認できます。コマンドラインと Visual Studio Code 拡張機能の両方でインストールを行います。ターミナルで次のコマンドを実行してください。 pip3 install cfn-lint インストールされたら、拡張機能パネルで CloudFormation Linter をインストールできます。 次に、ベースディレクトリに vpc.yaml という名前のテンプレートを作成します。 入力を始めると、 CloudFormation Linter が推奨事項とオートコンプリート機能を提供します。 次のテンプレートを新しく作成した vpc.yaml ファイルにコピーしてください: AWSTemplateFormatVersion: "2010-09-09" Resources: VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 このテンプレートは、CIDR ブロック 10.0.0.0/16 の VPC を作成します。 テンプレートにエラーがないことを確認するには、ターミナルで cfn-lint を実行し、エラーが返されないことを確認します。 cfn-lint -t vpc.yaml デプロイファイルの追加 Git 同期では多様なデプロイメントをサポートするため、Git リポジトリから CloudFormation スタックを管理するための柔軟性を提供する スタックデプロイファイル をサポートしています。 この設定ファイルは、テンプレートファイルの場所、使用したいパラメータやタグの管理を行います。 パラメータやタグの管理には、このスタックデプロイファイルを使うことを強くお勧めします。監査や決定論的なデプロイメントが容易になるためです。 リポジトリ内に deployment-file.yaml という新しいファイルを作成します。このスタックにはパラメータやタグがないため、シンプルです。 template-file-path: ./vpc.yaml 後からコンソールでこのファイルを追加することもできます。 Pull Request アクションの追加 これで開発環境の設定が完了しました。次はプルリクエストを送るだれもが、ローカルで受けているのと同じようなフィードバックを受け取れるようにしたいと思います。 GitHub Actions を使えば、これが可能になります。GitHub Actions は、プルリクエストフィードバックと CI ビルドを自動化する、カスタマイズ可能なワークフローツールです。 次のようなディレクトリとファイルを作成します。 .github/workflows/pull-request.yaml このファイルの内容は以下のとおりです。 name: Pull Request workflow on: - pull_request jobs: cloudformation-linter: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Linter install uses: scottbrenner/cfn-lint-action@v2 with: command: cfn-lint -t ./vpc.yaml この設定により、プルリクエストに対して linter の結果がフィードバックされるようになります。作業内容をリモートブランチにプッシュしてください。 git add -A git commit -m "add pull request linting workflow, add base vpc template" git push origin main これから VPC にサブネットを追加しますが、 VpcId ではなく VpcName という無効なプロパティを意図的に追加します。 AWSTemplateFormatVersion: "2010-09-09" Resources: VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 Subnet: Type: AWS::EC2::Subnet Properties: VpcName: ! Ref VPC CidrBlock: 10.0.0.1/16 ローカルの linter は、これが無効であることをすぐに指摘します: これらは今のところ無視してかまいません。プルリクエストを作成するには、新しいブランチを作成し、ローカルの変更をコミットする必要があります。以下のコマンドを実行してください。 git switch -c add-subnet git add -A git commit -m "add subnet" git push origin add-subnet これらのコミットをプッシュすると、GitHub から main ブランチに対するプルリクエストを作成できるようになります。 ただし、プルリクエストを作成すると、GitHub Actions の実行が終わったときにチェックが失敗したことがわかります。 「Files changed」タブを確認すると、どこが間違っているかがわかります。Linter アクションはプルリクエスト上で直接フィードバックを提供し、 ブランチ保護 を設定した場合はマージのアクションをブロックします。 このリポジトリでは、少なくとも 1 人のレビュアーと全てのチェックの成功が必要なので、これら両方の失敗を解決しなければなりません。 フィードバックと問題があった行番号を取得できたので、テンプレートに戻り、 VpcName を VpcId に修正しましょう。 AWSTemplateFormatVersion: "2010-09-09" Resources: VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 Subnet: Type: AWS::EC2::Subnet Properties: VpcId: ! Ref VPC CidrBlock: 10.0.0.1/16 ローカルの linter は問題ありません。コミットしなおすと、リモートの linter も同様に問題がないことを確認できます。レビュアーからの承認を得た後、コミットを main ブランチにマージできます。 Git 同期の有効化 開発環境が整い、プルリクエストの過程でテンプレートがマージ前に Lint されるようになりました。 main ブランチに到達した CloudFormation テンプレートはデプロイの準備ができています。 次に、新しく公開された CloudFormation の Git 同期を利用して、デプロイされたスタックを新しいテンプレートに自動的に同期させます。 まず、CloudFormation がスタックをデプロイするために必要な IAM ロール を作成します。このロールは、CloudFormation がデプロイするリソースを制御します。ロールの名前は後の手順で使用するので控えておきましょう。この例ではロール名を vpc-example-cloudformation-deployment-role とし、次の許可ポリシーを設定します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:CreateVpc", "ec2:CreateSubnet", "ec2:DescribeVpcs", "ec2:DescribeSubnets", "ec2:DeleteVpc", "ec2:DeleteSubnet", "ec2:ModifySubnetAttribute", "ec2:ModifyVpcAttribute" ], "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:CalledVia": ["cloudformation.amazonaws.com"] } } } ] } ロールを作成したら、次はスタックを新しく作成します。 こちらでは、新しいオプション Sync from Git を選びテンプレートのソースを設定します。既にスタックデプロイファイルを作成済みのため、 I am providing my own file in my repository. を選択します。 次に、Git 統合を設定してリポジトリを選択します。あらかじめ作成したデベロッパーツールの Github への接続を使用し、リポジトリを選択する必要があります。 GitHub 、 接続 、 リポジトリ 、 ブランチ 、 デプロイファイルのパス を選択してください。 最後に 新しい IAM ロール を選択して、サービスマネージドロールを作成します。このロールにより、Git 同期がリポジトリに接続できるようになります。この作業は 1 回限りで、今後はここで作成する既存のロールを使用できます。 次のページでは、このスタックをデプロイするために必要な作成済の IAM ロール vpc-example-cloudformation-deployment-role を選択します。このロールは、CloudFormation がデプロイするリソースを制御します。このように、Git 同期によってスタックを管理するには、事前にロールを作成しておく必要があります。 最後に、「Git と同期」タブで、設定内容、同期のステータス、プロビジョニングのステータス、そして必要に応じて同期の再試行や接続解除が可能であることを確認できます。 結論 この投稿では、CloudFormation テンプレートの作成および更新時にフィードバックを得るためのリモート開発環境を設定しました。プルリクエストを作成する際も同様に、フィードバックを得られます。テンプレートが main ブランチにマージされると、自動的にスタックにデプロイされます。このように、AWS リソースを Infrastructure as Code として管理するための、堅牢で拡張性のある CI/CD システムが構築されました。この Git 同期についてのフィードバックをお待ちしています！ 著者について Dan Blanco Dan is a senior AWS Developer Advocate based in Atlanta for the AWS IaC team. When he ’ s not advocating for IaC tools, you can either find him in the kitchen whipping up something delicious or flying in the Georgia sky. Find him on twitter (@ TheDanBlanco) or in the AWS CloudFormation Discord .

本記事は 2024 年 5 月 9 日に公開された ” How Can You Build a Culture of Experimentation? ” を翻訳したものです。 世界中の何百人もの企業幹部と話をしたところ、彼らは迅速に行動してイノベーションを起こすというアイデアは気に入っているものの、企業のレガシーシステムや制約の中でそれを実現するのは難しいと感じていることがわかりました。生成 AI の可能性を考えると、迅速なイノベーションは急務です。しかし、イノベーションを促進するには、実験が容認されるだけでなく、当たり前の文化を築く必要があります。 この記事では、低コスト、低リスク、低摩擦で、企業に大きな利益をもたらす実験を奨励する文化を徐々に築いていく効果的な方法を説明します。私が NASA のジェット推進研究所 (Jet Propulsion Laboratory: JPL) の IT 最高技術・イノベーション責任者を務めていたときに、この方法がうまくいっていました。JPL の実験文化のおかげで、チームは現在の宇宙ミッションにクラウドを利用するようになりました。これにより、より迅速な意思決定が可能になり、必要に応じて方向転換できるようになりました。迅速な実験は、拡張現実、3D プリント、データ視覚化、大規模な機械学習の民主化など、多くの新しいテクノロジーの導入にもつながりました。既存の従業員、インターン、新入社員がこれらのイノベーションを迅速かつ安価に導入できたことは、組織全体の助けとなり、実験者のキャリアに大きな利益をもたらしました。 実験の文化を築くために、最初に組織で実施する実験と実施しない実験を定義します。これにより、期待値を定め、十分な開発と管理を行わずに提案した実験が、本番環境に移行してしまう恐れを軽減できます。 次に、2 週間以内に解決できる可能性の高いビジネス上の問題を選びます。テクノロジーや特定のソリューションではなく、お客様のニーズから逆算して、実際のビジネス上の問題に集中します。ソリューションは時間とともに進化します。洞察につながる成功指標を決定するには、実験者に希望する結果を説明した 1 ページまたは 2 ページの資料を渡してもらい、各実験後の結果をもとに更新してもらいます。これらのビジネス上の問題を、将来の実験者がトレーニングやイテレーションのためにアクセスできるユースケースのライブラリに保存してください。これは、従業員が小さいながらも実際のビジネス上の問題を解決しながら新しいスキルを学ぶ素晴らしい方法です。 第三に、ビジネス組織と機能組織全体にわたる実験者を見つけましょう。多くの組織は、関心と知識が豊富な人材がいることに驚きます。新しいことに挑戦するには、承認と激励が必要です。たとえば、処方的分析の専門家は、AI、機械学習、生成AIを簡単に導入できます。 第四に、部門横断的なアプローチをとりましょう。少なくとも 1 人の IT 従業員、関心のある事業部門のエンドユーザー 1 人、またアドバイスや啓発を行うサイバーセキュリティ専門家で構成される 2 人から 4 人のチームを選任します。 第五に、実験の成功を測定します。投資利益率 (Return On Investment: ROI) の測定に固執しないでください。ROI 文書の作成には、実験の実施にかかる時間よりも多くの時間と費用がかかります (そして勢いを失います)。エンドユーザーコミュニティからの Return On Attention (ROA)、つまり影響を受けるエンドユーザーからの関心度を測定します。ROA を 1 ～ 10 の範囲で評価します。10 は 100% 積極的でポジティブな関心であることを示します。JPL では、少なくとも 2 つのエンドユーザーコミュニティから 8 ポイントを獲得すれば、投資資金が得られることが分かっていました。それから、ROI を測定し、完璧 (またはそれに近い) に向けて繰り返すことができるのです。私は他の企業と協力して同様のアプローチを開発することに成功しました。このようにすることが、問題に最も近い人、そしてしばしば解決策を持っている人がいるような組織の端から創造性を解き放つことに役立ちます。 第六に、実験の話をします。新しいテクノロジーでビジネス上の問題を解決したら、対面デモを行い、複数のデモを紹介するオープンハウスを開催することを検討してください。注釈付きのデモを録画して、セルフサービスの視聴機能を作成します。自分の取り組みが金メッキの科学実験だという批判を避けるために、自分がプロのビデオグラファーではないという期待値を設定することが重要です。特に他のエンドユーザーコミュニティが彼らの意見を受け入れる可能性が最も高いので、エンドユーザー (ビジネス) 参加者の功績を称えることを忘れないでください。そうすれば、将来の実験への参加に対する需要が高まります。ソーシャルメディアやアワードプログラムを利用して、参加者に利益をもたらしましょう。 このアプローチに従えば、始めるのに多額の予算は必要ありません。予算が多すぎると、ソリューションが複雑になりすぎます。時間をかけすぎると、新たに発生するビジネスクリティカルな問題が原因で主要な実装担当者を失うことになります。高い結束力と集中力を確立するために、2 週間 2 ～ 4 人だけで始めましょう。最も成功している企業では、許可を求めることなく利用できる少額の予算を CIO/CTO や事業部門が設定しています。大胆な人には、10 倍の ROI を約束してください。予算を得るのに役立ちます。JPL ではその目標を達成するのに何の問題もありませんでした！ また、エリート主義や反感を助長する可能性があるため、「唯一無二」のイノベーショングループを設立することも避けてください。エンドユーザーと一緒にイノベーションを起こし、自由に賞賛を贈ってください。自社で考えるべきことを外部に委託することは避け、特定の技術の専門家と手を組み、自分でビジョンを維持しましょう。コンプライアンスコントロールを含む自動化により、実験をより簡単かつ迅速に行うことができます。気づかれないように実験を行い、成功してから公開することを検討してください。そうすれば、実験への恐れが減ります。事業を変革できる可能性のある、潜在的に無限の利益をもたらす低リスク、低コストの実験を行っていることを関係者に思い出させましょう。 実験の文化で成功するには、ビジネスの成果がすべてです。 各実験はストーリーを伝え、簡単に元に戻せるものでなければなりません。これにより、リスクと反対意見が減ります。実験における唯一の本当の失敗は、あなたの組織が何も学ばないことであり、私たちはそれが起こるのを見たことがありません。上記の手順は、組織全体のすべてを一度に変更する必要がないため、既存の企業でかなり簡単に試すことができます。ビジネスプロセスを何度も 10% 改善できれば、会社に大きな変化をもたらすことができます。組織は楽しく働ける職場となり、社内のアイデア形成や人材の採用、再教育、定着に役立ちます。そして、それはたしかに価値のある目標です。 ご意見、結果、アイデアをお聞かせください。 Live long and experiment! この記事は、カスタマーソリューションマネージャーの仁科 みなみが翻訳を担当しました。原文は こちら です。

本記事は 2024 年 4 月 11 日に公開された ” KPIs – Enterprise Journey from Technology to Business ” を翻訳したものです。 以前の ブログ記事 で説明したように、AWS は、KPI (Key Performance Indicators: 主要業績評価指標) が明確に定義され、追跡され、調整された組織が、クラウドトランスフォーメーションのジャーニーで成功していると理解しています。しかし、KPI を定義して追跡することは難しい課題です。組織が連携して成果を追跡し、そうすることに価値があるとしても、最初から KPI に注目することが難しい組織もあります。 このブログ記事では、架空の企業 (AnyCompany) が KPI を導入するまでのジャーニーを、複数の顧客とともに取り組んだ実際の経験に基づいて説明します。大規模な企業組織である AnyCompany は、営業利益と売上の向上を目指していました。まず、コストの最適化、総所有コストの削減、技術的負債の回収、将来の機能のための基盤構築を実現するために、オンプレミスのデータセンターを廃止し、アプリケーションをクラウドに移行することから始めました。彼らが採用した未来が、ビジネスの成長と変革を後押ししました。 ビジネス KPI を使ってクラウド導入の効果を追跡する AnyCompany のビジネス目標と現在の文化、プロセス、ガバナンスを理解した上で、ビジネス KPI の導入を促進するために Crawl (ハイハイ)、Walk (歩く)、Run (走る) のアプローチを推奨しました。最初の Crawl フェーズでは技術 KPI から始めて、次の Walk フェーズでビジネス KPI を導入して初期の摩擦を乗り越え、最後の Run フェーズでは徐々にすべてのビジネス KPI に移行します。Crawl フェーズの焦点は、ワークロードをクラウドに移行することで技術的負債を軽減することです。戦術的な KPI は、ワークロードのリプラットフォームとリアーキテクチャの効果的な追跡と進捗報告を確実にします。Walk フェーズでは、クラウド導入技術とコスト削減の成果をビジネス部門のビジネス成果に結び付けます。Run フェーズでは、組織が社内のマーケティングと社内のビジネスアプリケーション開発チームからの肯定的なフィードバックを通じて成功を収めた後、外部のクライアント対応チームは、クライアントにも同様の結果をもたらすという見通しを持ってモチベーションを高めます。これにより、人、プロセス、テクノロジー、ビジネスの観点から組織全体の変革を促進するプラスのフライホイール効果が生まれます。 Crawl フェーズ — 技術 KPI を追跡し、測定する このフェーズでの主な焦点はテクノロジー、つまり技術的負債を減らし、クラウドの導入を増やすことです。このフェーズの KPI は、次の表に示すように、コスト削減、トレーニングを受けたスタッフの数、移行されたアプリケーションの数、運用上の優秀性などのメリットの測定に重点を置いています (表 1)。組織はこの段階では社内の KPI に重点を置き、IT 以外の社員に進捗状況をすぐに伝えます。これにより、KPI の測定、追跡、共有というマッスルメモリー (条件反射的に意識せずに行動できること) が生まれます。KPI は、完了までの期間が複数の四半期または数年にわたる場合に有効です。サイロ化された構造のため、AnyCompany ではこのステップが必要でしたが、他の組織では次の段階にすばやく移行し、勢いをつけるために Crawl フェーズを必要としない場合があります。 表1　Crawl フェーズの KPI と影響 メリット 目的 測定 影響 コスト削減 データセンターの廃止 マネージドサービスプロバイダー (MSP) のデータセンターから廃止されたサーバー数 IT 支出を詳細に確認することによる的を絞った最適化の取り組みが可能 インフラストラクチャ支出のより正確な予測 オンプレミスとクラウドのコスト削減 (ビジネスケース) オンプレミスとクラウドのサーバー数 オンプレミスとクラウドのコスト コストの前年比 (YoY) ダウンタイムの削減 使用されていないアプリケーションを廃止することでアプリケーションフットプリント (リソース使用量やシステムに与える影響など) を簡素化 廃止されたアプリケーションの割合 技術的な問題が顧客に影響を与える前にプロアクティブに解決 ピークアプリケーション使用時のパフォーマンス低下なし (オートスケーリング) アプリケーション停止回数の減少 技術的負債の除去 サポートされた OS 上で稼働するアプリケーションの割合 サポートされたデータベース上で稼働するアプリケーションの割合 運用上のメトリクスの改善 オンプレミスとクラウドの平均検出時間 (MTTD) の基準 プラットフォームやリホストの性能改善 オンプレミスとクラウドのピーク負荷時におけるアプリケーション性能の基準 計画外のシステム停止回数の削減 オンプレミスとクラウドのシステム停止回数の基準 AnyCompany は、Crawl フェーズ中に前の表 1 の KPI を使用して、オンプレミスアプリケーションの約 25％、コストのかかるレガシーデータベースとサーバーの約 50％ を廃止しました。さらに、複数のデータセンターを閉鎖し、セキュリティとオブザーバビリティを向上させ、モダンアプリケーション開発プラットフォームを構築しました。 Walk フェーズ — ビジネス KPI を徐々に導入する この段階では、組織はビジネス成果をテクノロジードライバーに結び付けます。Crawl フェーズで確立された KPI を拡大するにつれて、徐々に変化していきます。目標は Crawl フェーズですべての KPI を完成させることではなく、チームがメトリクスを活用し、継続的な改善とステークホルダーとの透明性を維持できる状態に移行する能力に注目することが目標であることに注意してください。次の表 2 に示すように、初期の KPI セットを取りこんで、自動化された環境プロビジョニングを追加するなど、それらを拡張することになります。これにより、開発者はインフラストラクチャの管理から解放され、デプロイの失敗が減り、機能の強化やより価値のあるタスクに集中できるようになります。ここでは、副次的な目標としてビジネスインパクトの測定から始めたいと思います。初期の KPI には完了までの明確な道筋があり、チームにこれらの新しい KPI を意思決定プロセスで使用してもらうために、チームに KPI を導入する機会を探してください。 AnyCompany は現在、クラウドへの移行を順調に進めており、このフェーズの一環として移行の先を見据えています。彼らは、クラウド移行の過程ですでに測定されていた技術 KPI にビジネス成果を追加しました。企業全体とのコミュニケーションを継続することで、企業のステークホルダーは、移行によって自社のビジネスがどのようにプラスの影響を受けているかを理解できるようになりました。表 2 は、追跡対象の技術 KPI がビジネスに与える影響を示しています。 表2 Walk フェーズの KPI と影響 メリット 目的 測定 影響 ダウンタイムの削減 コードで運用されるアーキテクチャの増加 自動化された環境プロビジョニング数 開発者が機能強化に費やせる時間の増加 デプロイ失敗の減少、つまり、同じ作業を繰り返すことの減少 報告された問題に対するより早いレスポンスタイム デプロイの効率性 自動化されたアプリケーションのデプロイ数 デプロイ成功率 デプロイガバナンスの合理化 デプロイガバナンスプロセスの評価 テスト自動化の割合 オンプレミス、クラウド、クラウドネイティブプラットフォームのデプロイ時間 コスト削減 クラウドネイティブプラットフォームに移行することでリプラットフォームやリファクタリングの準備ができているアプリケーションのモダナイズ クラウドネイティブプラットフォームのアプリケーションの割合 本番環境で報告された不具合に対するレスポンスの増加 本番環境での不具合数の減少 顧客へのプロダクト強化提供数の増加 デプロイ中のダウンタイムの排除 アプリケーションセキュリティの改善 (自動化されたセキュリティスキャン) AWS のマネージドデータベースの割合 機能のサイクルタイム (機能リクエストを本番環境に実装するまでの時間) デプロイ数の前年比 (YoY) 本番環境で報告された不具合数 Run フェーズ — 時間とともにビジネス KPI を追跡、測定、発展させる この段階では、長期的なビジネス上のメリットが実現されつつあり、移行の最初の部分も終わりに近づいています。この時点で、組織はクラウドで成熟しています。初期の戦術的な測定 は、次の表 3 に示すように、組織のビジネスに直接影響する KPI に置き換えられています。これには、売上増加、業務オペレーションの競争上の優位性確保と効率化、営業利益の増加、市場シェアの増加、新しい収益セグメントが含まれます。組織は機能リリースなどのアウトプットとビジネスを推進する成果の関係を理解しています。また、成果を測定すると同時に、その実現のためにどのような機能を追加する必要があるかを調べます。 表 3 Run フェーズの KPI と影響 メリット 目的 測定 影響 効率化 開発者の請求対象外時間 (直接的には収益を生まない時間) の削減 デモや概念実証の労力を軽減し、プリセールス時間を追跡 従業員の生産性向上 AWS CloudFormation テンプレートのような再利用可能なアセットがチームを横断して共通的なワークロードに活用され、チームは付加価値のある作業と差別化されない作業に注目 タグ付けされたアセットやアクセスの追跡 アジリティ (俊敏性) より強いガードレールや舗装された道を提供して、プロジェクト内でジュニアレベルとシニアレベルのエンジニアが一緒に取り組むことができる。経験の浅いスタッフをより迅速に増員できる。 Amazon CodeWhisperer (2024 年 6 月現在では、Amazon Q Developer) のような新しいツールの導入とアウトプットの測定 新人のオンボーディングプロセスの迅速化 イノベーション クラウドネイティブソリューションに基づくクライアントオファリングへの新しい機能追加 (グローバル化、レジリエンシー、サステナビリティ) 顧客による新しい機能のフィードバックスコア 新しい収益源 この段階で、AnyCompany はテクノロジーの観点からクラウドトランスフォーメーションについてある程度の成熟度を達成し、現在は、完了しようとしている作業に関連するビジネス KPI との結び付けと測定に注力しています。ビジネスの変革を可能にする機能や特徴に焦点を当てながら、技術的負債が野放しにならないようにするためのメカニズムとガバナンスが整っています。このフェーズは継続的な道のりであり、ビジネス戦略と IT 戦略を結びつけることで、AnyCompany がマーケットリーダーとしての地位を確立し、コラボレーションを改善できるようになります。 結論 このブログ記事では、AnyCompany がトランスフォーメーションのジャーニーの初期から採用しているアプローチを紹介しています。現在の状況にかかわらず、これらの手順に従うことで、勢いを維持または回復し、一貫した進歩を遂げることができます。KPI を継続的に強化することを目標に、徐々にビジネス KPI に置き換えることができる技術 KPI を測定して共有するメカニズムを構築するための段階的アプローチについて説明しました。 この記事は、カスタマーソリューションマネージャーの仁科 みなみが翻訳を担当しました。原文は こちら です。

Amazon Relational Database Service (Amazon RDS) for SQL Server は、 Microsoft SQL Server データベースの運用と管理を簡素化する AWS マネージドデータベースサービスです。Amazon RDS for SQL Server は、SQL Server データベースのプロビジョニング、管理、モニタリングを行うことで価値をもたらします。このような運用上の俊敏性は価値がありますが、データベースを物理データセンターの外部に移行するリスクを考慮すると、データ保護とセキュリティはさらに重要になります。Amazon RDS では、SQL Server の 透過的データ暗号化 (TDE) 機能を採用できます。この機能は保存中のデータを保護し、アクセスを許可されたユーザーに制限しますが、転送中または使用中のデータは暗号化されません。 複数の AWS アカウントを使用することは、環境を論理的に分離するための一般的なベストプラクティスです。TDE 対応の SQL Server データベースを AWS アカウント間で管理する場合、データ保護を確実にするためのいくつかの重要な手順があります。この記事では、AWS アカウントをまたいで Amazon RDS for SQL Server インスタンス間で TDE 対応データベースを移行する手順について説明します。 前提条件 ここでは、お客様が Amazon RDS for SQL Server と SQL Server の TDE について事前に知識があることを前提としています。この記事では SQL Server 2019 エンタープライズエディションを使用しています。 この記事では、次の前提条件が必要です。 アカウント A とアカウント B の AWS アカウント で Amazon RDS for SQL Server の TDE オプショングループが有効になっていて、リソースを操作するための適切な権限があること AWS KMS キーを使用して作業するためのアクセス権 アカウント A とアカウント B の S3 バケット ソリューション概要 このソリューションでは、AWS アカウント A の Amazon RDS for SQL Server にある TDE 対応データベースをバックアップし、それをアカウント B の別のインスタンスに復元する必要があります。 AWS Key Management Service (AWS KMS) キーで暗号化された TDE 証明書も、ターゲットのインスタンスに復元する必要があります。ソースデータベースの TDE 証明書をバックアップするために使用される秘密鍵の暗号文は、アカウント A の KMS キーで復号化され、アカウント B の KMS キーで再度暗号化されます。 ソリューションを実装する大まかな手順は、アカウント A では以下の流れになります。 存在しない場合は、新しい対称暗号化 KMS キーを作成します。 AWS KMS キーを使用して TDE 証明書を Amazon Simple Storage Service (Amazon S3) バケットにバックアップします。 RDS for SQL Server データベースを S3 バケットにバックアップします。 プライベートキーファイルの S3 メタデータから ciphertext-blob を抽出します。 AWS KMS キーを共有します。 アカウント B で、次の手順を実行します。 アカウント A の暗号文を復号化し、平文のパスワードを抽出します。 アカウント B で新しい対称暗号化 KMS キーを作成し、そのキーでプレーンテキストのパスワードを暗号化します。 データベースをリストアする前に、アカウント B のターゲットインスタンスで TDE 証明書をリストアする必要があります。 アカウント B の Amazon RDS for SQL Server に対してデータベースをリストアし、AWS KMS キーを暗号化します。 次の図は、TDE 対応の SQL Server データベースをアカウント間で移行するためのソリューションアーキテクチャを示しています。 アカウント A の TDE 証明書と RDS for SQL Server データベースを S3 バケットにバックアップ AWS KMS キーを使用して RDS インスタンスの rds_backup_tde_certificate ストアドプロシージャを使用して、アカウント A の TDE 証明書をバックアップします。アカウント A の Amazon RDS for SQL Server では、次のサンプルコードを実行します。 以下は、アカウント A で実行されるステートメントの例です。 まず、sys.certificates システムビューにクエリを実行して TDE 証明書名を取得します。 USE [ master ] GO SELECT * FROM sys . certificates WHERE name LIKE 'RDSTDECertificate%' GO SQL 次に、KMS キーを使用して Amazon RDS TDE 証明書をバックアップします。 EXECUTE msdb . dbo . rds_b ackup_tde_certificate @certificate_name = 'RDSTDECertificate20230323T215533' , @certificate_file_s3_arn = 'arn:aws:s3:::<BUCKET-NAME-ACCOUNTA>/mssql-inst02.cer’, @private_key_file_s3_arn = ’arn:aws:s3:::<BUCKET-NAME-ACCOUNTA>/mssql-inst02.pvk' , @kms_password_key_arn = 'arn:aws:kms:us-east-1:<ACCOUNTA-ID>:key/mrk-<Key ID>' , @overwrite_s3_files = 1 ; SQL 最後に、暗号化されたデータベースを Amazon S3 にネイティブバックアップします。 exec msdb . dbo . rds_backup_database @source_db_name = 'tpcc' , @s3_arn_to_backup_to = 'arn:aws:s3:::<BUCKET-NAME-ACCOUNTA>/tpcc-native-backup.bak' , @overwrite_s3_backup_file = 1 , @type = 'FULL' , @number_of_files = 4 ; SQL 詳細については、「 SQL サーバーの透過的なデータの暗号化サポート 」を参照してください。 プライベートキーファイルの S3 メタデータから ciphertext-blobを抽出 以下のステップを完了します。 前のステップの S3 バケットに移動し、プライベートキーファイルのメタデータから ciphertext-blob をコピーします。これは x-amz-meta-rds-tde-pwd タグの下にあります。 暗号化操作を実行するアカウント B の root ユーザー、他のユーザーまたはロールと (TDE 証明書のバックアップに使用される) KMS キーを共有します 。 root ユーザーを使用する IAM ポリシーの例を以下に示します。 { "Sid" : "Allow an external account to use this KMS key" , "Effect" : "Allow" , "Principal" : { "AWS" : [ "arn:aws:iam::444455556666:root" ] } , "Action" : [ "kms:Encrypt" , "kms:Decrypt" , "kms:ReEncrypt*" , "kms:GenerateDataKey*" , "kms:DescribeKey" ] , "Resource" : “<ARN - FOR - KMS - KEY > ” } YAML 以下は、ロールを使用した IAM ポリシーの例です。 { "Sid" : "Allow an external account to use this KMS key" , "Effect" : "Allow" , "Principal" : { "AWS" : "arn:aws:iam::444455556666:role/ExampleRole" } , "Action" : [ "kms:Encrypt" , "kms:Decrypt" , "kms:ReEncrypt*" , "kms:GenerateDataKey*" , "kms:DescribeKey" ] , "Resource" : “<ARN - FOR - KMS - KEY > ” } YAML TDE 証明書 (.cer) とプライベートキー (.pvk) のバックアップファイルをアカウント A の S3 バケットからアカウント B の S3 バケットにコピーします。 アカウント A の暗号文を復号化して平文のパスワードを抽出 TDE 証明書のバックアップに使用した AWS KMS キー ID を使用して、アカウント A から受け取った暗号文を復号化します。以下は、暗号文を復号化してプレーンテキストのパスワードを取得する AWS Command Line Interface (AWS CLI) コマンドの例です。 AWS kms decrypt —key - id —ciphertext - blob —output text —query Plaintext —region YAML 復号化の詳細については、「 Decrypt 」を参照してください。 アカウント B で新しい AWS KMS キーを作成、そのキーをプレーンテキストのパスワードで暗号化 次のステップでは、アカウント B で新しい対称 AWS KMS キーを作成し、アカウント B の AWS KMS キーを使用して前のステップで復号化されたプレーンテキストのパスワードを暗号化します。AWS KMS キーに対するアクセス権限を持つ認証情報を使用します。次のコマンドは、前に復号化したこのプレーンテキストパスワードの暗号文を提供します。 aws kms encrypt —key - id <Provide KMS KeyID from Account - B > —plaintext "The output from the decrypt step" —output text —region <AWS Region > YAML 詳細については、「 対称暗号化 KMS キーの作成 」を参照してください。 次に、証明書とプライベートキーが保存されているアカウント B の S3 バケットに移動します。プライベートキーファイル (.pvk) を選択し、オブジェクトアクションに移動してメタデータを編集します。「ユーザー定義」タイプで x-amz-meta-rds-tde-pwd というタグを付けて暗号文の値を更新します。 データベースをリストア、アカウント B の Amazon RDS for SQL Server に対して AWS KMS キーを暗号化 データベースをリストアする前に、アカウント B の RDS for SQL Server インスタンスに TDE とネイティブバックアップとリストアが有効になっているオプショングループがあることを確認します。 以下のサンプルコードを使用して、新しく作成された AWS KMS キーを使用して更新された TDE 証明書をアカウント B の Amazon RDS for SQL Server にリストアします。 EXECUTE msdb . dbo . rds_restore_tde_certificate @certificate_name = 'UserTDECertificate_FromAcct1' , @certificate_file_s3_arn = 'arn:aws:s3:::<BUCKET-NAME-ACCOUNTB>/mssql-inst02.cer' , @private_key_file_s3_arn = 'arn:aws:s3::: <BUCKET-NAME-ACCOUNTB>/mssql-inst02.pvk' , @kms_password_key_arn = 'arn:aws:kms:us-east-1:<ACCOUNTB-ID>:key/mrk-<Key ID>' ; SQL ユーザー証明書に次のコードがロードされているかどうかを確認します。 SELECT * FROM msdb . dbo . rds_fn_list_user_tde_certificates ( ) ; SQL TDE 証明書が正常にリストアされ、Amazon RDS for SQL Server で検証されたら、データベースバックアップのリストアに進むことができます。以下は、アカウント B の S3 バケットから TDE 対応のバックアップをリストアする例です。 exec msdb . dbo . rds_ restore_database @ restore_db_name = 'tpcc' , @s3_arn_to_restore_from = 'arn:aws:s3:::<BUCKET-NAME-ACCOUNTB>/tpcc' , @with_norecovery = 0 , @type = 'FULL' ; SQL 後片付け 検証で作成した AWS リソースを削除するには、次の手順を実行します。 AWS マネジメントコンソール にサインインします。 RDS for SQL Server インスタンスが存在するリージョンを選択します。 Amazon RDS コンソールのナビゲーションペインで [データベース] を選択します。 作成された RDS インスタンスを選択します。 [アクション] メニューで [削除] を選択します。 Amazon S3 コンソールで、作成されたバケットを選択します。 [アクション] メニューで [削除] を選択します。 AWS KMS コンソールで、作成した KMS キーを選択します。 [スケジュールキー削除] を選択し、7 ～ 30 日間の期間を入力して、[スケジュール削除] を選択します。 結論 透過的データ暗号化は、データを保護するために SQL Server で一般的に使用されている組み込みの暗号化メカニズムです。この記事では、RDS for SQL Server インスタンスにある TDE 対応のデータベースを別のアカウントにある RDS for SQL Server インスタンスにリストアするためのソリューションを紹介しました。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Alvaro Costa-Neto は、AWS のデータベーススペシャリストソリューションアーキテクトで、お客様のクラウドでのデータベースソリューションの設計と実装を支援しています。彼はデータベーステクノロジーに長けており、19 年以上にわたり主に Microsoft SQL Server でデータベーステクノロジーに携わってきました。彼はフロリダ州クレルモンに妻と 2 人の子供と一緒に住んでおり、飛行機と旅行が好きです。仕事がないときは、家族や友人と BBQ を主催したり、新しい場所を探索したりしています。 Gopakumar Gopalakrishna Pillai は、アマゾンウェブサービスのデータベースエンジニアです。16 年間データベースに関わってきて複数のデータベーステクノロジーに取り組み、さまざまなお客様の問題に対するソリューションを提供してきました。RDS SQL Server のお客様に最適なデータベースソリューションを提供することに注力しており、その経験を活かしてお客様がサーバーレスアプリケーションを構築できるよう支援しています。自由時間には、新しい場所を探索するのが好きです。 Jeril Jose は、Microsoft SQL Server やその他のデータベーステクノロジーで 14 年以上の経験を持つデータベーススペシャリストコンサルタントです。お客様の AWS へのデータベースソリューションの設計、移行、最適化を支援しています。AWS に入社する前は、金融および小売部門にわたる生産およびミッションクリティカルなデータベースの実装をサポートしていました。

みなさん、こんにちは。シニアマイグレーションスペシャリストの富松です。 AWSジャパンでは、AWSへの大規模なシステムの移行を実現し、ひいてはお客様のデジタルトランスフォーメーションをサポートする 「 AWS ITトランスフォーメーションパッケージ（ITX） 」を2021年に、2022年には内容を強化・拡大した「 AWS ITトランスフォーメーションパッケージ2.0（ITX2.0） 」をリリースしました。2023年にはITXパッケージ2.0をより包括的に進化させた「 AWS ITトランスフォーメーションパッケージ 2023 ファミリー（ITX 2023） 」をリリースし、2021年以来220社(2024年6月現在)を超える多くのお客様にご活用頂き、企業のITトランスフォーメーションを支援してきました。 今回のブログでは、ITX 2023を更に包括的に進化させ、2024年6月にリリースした、最新版の「AWS ITトランスフォーメーションパッケージ ファミリー（ITX）」をご紹介します。（ 最新版のITX資料ダウンロードはこちらから ） 生成AIの活用が企業の喫緊の課題に 近年、生成AIが画期的な技術革新をもたらしています。自然言語処理の生成AIから、画像生成AI、さらにはコード生成AIまで、様々な分野でイノベーションが生み出されています。企業においても、業務効率化や新規ビジネス創出に向けて、生成AIの活用が進んでいます。 PwCコンサルティングの「 生成AIに関する実態調査2023 秋 」によると、調査対象企業の87%が「既に生成AIの社内利用あるいは社外活用(その検討)を進めている」と回答。さらに43%が2024年3月までの生成AI本格導入を予定し、約58%は今後1年以内に導入を検討しているなど、導入に向けた動きが加速する見込みです。 しかし一方で、生成AIを実際のビジネスに活用する際には、大きく2つの課題が存在しています。 1つ目の課題は、データ基盤の整備です。AWSのVice President of Data and AIであるDr. Swami Sivasubramanianが「データは生成AIアプリケーション活用における差別化要因である」とre:Invent 2023において述べているように、生成AIモデルの入力データの質が重要になります。しかし、企業の多くではデータのサイロ化が進み、必要なデータが統合されていないのが実情です。 2つ目の課題は、生成AIの活用に必要なスキルやノウハウの不足です。同レポート「 生成AIに関する実態調査2023 秋 」では、生成AI活用において直面した課題の上位2つが「必要なスキルを持った人材がいない」「ノウハウがなく、進め方が分からない」となっています。従来の機械学習とは発想を転換する必要があり、社内人材のリスキリングや専門人材の確保が欠かせません。 企業のDXを支えるパートナー連携の重要性 デジタル変革を推進するうえで、クラウドへの移行はほとんどの企業が直面する大きなチャレンジです。DXに取り組む企業の約6割が上流工程などの内製化を志向していますが、ユーザー企業におけるIT人材不足が阻害要因となっています。依存度の高いシステムインテグレーターや専門コンサルティング会社との協業は必須不可欠です。 しかし単に顧客がパートナー企業に移行を任せるだけでは不十分です。つまり、パートナー企業がITをどのように活用すればお客様のDX推進につながるか、パートナー企業が深く理解する必要があります。「ITを使って何ができるのか」「どのようなアーキテクチャが適切なのか」といった視点から、クラウド上のシステム開発・運用を支援することが求められます。 また、システム開発やシステム運用を支援するパートナー企業は、既存プロジェクトの技術支援だけではなく、AWS環境全体の運用やアカウント管理 (リセール事業)、新規のシステム移行支援などでも顧客に貢献したいと考えています。 AWS ITトランスフォーメーションパッケージ （ITX）の最新版で、包括的な支援を実現 こうした企業の課題と要望を受け、AWSジャパンでは「ITトランスフォーメーションパッケージ(ITX)」の最新版を2024年6月20日にリリースしました。最新版のITXでは、クラウド移行、データ活用、生成AI導入の3つの側面から、デジタル変革の実現をワンストップで支援します。AWSの専門性とソリューション、AWSパートナーネットワークを最大限活用することで、包括的な支援を行います。 また、ITXパッケージはこれまで民間企業のお客様のクラウド移行を支援してきましたが、公共分野特有の要素を固有には取り込んでいませんでした。今回AWSの活用やガバメントクラウドへの移行を考える中央省庁や地方自治体といった公共のお客様と、そうしたお客様を支援する事業者様向けに従来のITXの内容を拡張し、5つめの支援パッケージとして、公共版ITXを近日中にリリース予定です。 最新版のITXでは、生成AI活用に向けた新サービスとして、ITX for Cloud Nativeにおいて、以下の2つを提供します。また、ITX for MCP Partnerにおける、パートナー連携を強化します。 データプラットフォーム検討支援「Data Platform Modernization Assessment(DPMODA)」 データプラットフォーム検討支援「Data Platform Modernization Assessment(DPMODA)」では、データドリブン経営や、自社データを生成AIで最大限活用することを目指すお客様に対して、AWSの専門チームがお客様の現行データ基盤を分析し、モダナイゼーションのポイントや、To-Beアーキテクチャ案を提示します。 データプラットフォーム検討支援を通じて、現行データ基盤の成熟度を把握することで、今後の戦略策定に活用できます。また、To-Beアーキテクチャ検討を通して、現行基盤の単純移行にとどまらず、クラウドでの機能強化のヒントが得られます。 生成AI活用ワークショップ「Innovation EBA(Experience-Based Acceleration)」 生成AI活用ワークショップ(Innovation EBA)は、アジャイル型のインタラクティブなアクティビティです。お客様は、組み込みのAWSサービスと規範的なガイダンスを利用して、ビジネス価値向上を達成するためにAI/MLモデルの構築や、生成AIのユースケース実践をすばやく実現できます。 具体的には、約6週間でAI/MLモデルや生成AIユースケースを開発・実行できるようサポートしたり、未活用のデータや技術から新たなビジネス価値を引き出すことができます。技術ではなく主要なビジネス課題の解決に焦点を当て、実践を通してAI/ML、生成AIのスキルを身に付けられます。さらに、お客様ビジネスに合わせたユースケース開発の加速も図ることができます。AI/MLや生成AIを事業戦略の中核に据え、経営陣の強力な後押しと変革への意欲があれば、より効果的です。ビジネスインパクトが大きく本番環境への展開が見込めるユースケース、生産性や顧客体験、成長分野でのAI/ML活用ニーズがあれば適しています。 ITX for MCP Partnerにおけるパートナー連携強化 AWS移行コンピテンシーパートナー（Migration Competency Partner＝MCP）とは、“移行コンピテンシー”を保有されているAWSパートナーの事を指し、基幹システムや業務アプリケーションのAWSへの移行において、調査から計画、移行、運用までのすべてのフェーズにおける専門知識、豊富な実績やソリューションを持つAWSパートナーを認定させていただくものです。そのようなMCPパートナー各社が提供しているプログラムと、ITトランスフォーメーションパッケージが従来より提供していたプログラムを組み合わせたものが、「AWS ITトランスフォーメーションパッケージ for MCPパートナー（ITX for MCP Partner）」になります。 ITX for MCP Partnerをご利用いただく事により、AWSが持つクラウド移行の様々なオファリングに加えて、MCPパートナーが持つビジネスに関する専門知識、移行およびモダナイゼーションのツールやオファリング、教育などのサポートを併用して受けていただくことができます。 MCPごとに提供内容は異なりますが、例えば移行の計画立案から実行、データ分析基盤の構築、AIシステムの開発、運用支援まで、DXの実現に向けた幅広い支援が受けられます。 2024年6月現在、SCSK、Classmethod、富士ソフト、NHNテコラス、TIS、TOKAIコミュニケーションズ、 CTC、サーバーワークス 各社のITX for MCP Partnerがリリース済みで、今後は他のMCP各社のITX for MCP Partnerも追加予定です。多様なパートナーと連携することで、企業のニーズにより適合したソリューションを提供できます。 ITXパッケージ最新版の始め方 ITXパッケージ最新版のご利用に向けて、入り口は2つあります。 1） Webフォーム からお問い合わせ頂く。あるいは 2）担当営業までご連絡ください。 AWSクラウドへの移行やモダナイゼーションにご関心をお持ちのお客様は、 AWSで移行とモダナイズ のページをご確認ください。AWSへの移行やモダナイゼーションに必要な情報が網羅されています。 ITXパッケージ最新版にご興味をお持ちのお客様は、是非上記2つのいずれかよりAWSへお問合せください。 サービス＆テクノロジー統括本部　マイグレーション＆モダナイゼーションビジネス本部 シニアマイグレーションスペシャリスト 富松卓郎

今回は、 AWS Fault Injection Service (FIS) を使ったアプリケーションのレジリエンス向上をテーマにした新しいワークショップ、Resiliency Quest をご紹介します。このワークショップでは、ゲーミフィケーションの要素を取り入れ、実際に手を動かしながら、AWS FIS の使い方とレジリエンスのベストプラクティスを楽しく学ぶことができます。レジリエンスに関する技術的な経験をお持ちの無い方でも参加できますので、ぜひお試しください。 Resiliency Quest とは？ Resiliency Quest は、ゲーム形式の体験型ワークショップです。参加者はアプリケーションを運用する架空の企業の一員として、AWS FIS を使ってアプリケーションに実際に障害を引き起こし、その対応策を学びます。これにより、インフラストラクチャのレジリエンスを高める方法を体感し、実践的なスキルを習得できるイベントとなっています。 AWS Fault Injection Service (FIS) とは？ AWS FIS は、カオスエンジニアリングを実践するための強力なツールです。カオスエンジニアリングとは、意図的に障害を発生させてシステムの応答を観察し改善を行う手法で、システムの盲点や実装上の問題を明らかにし、運用スキルの向上を通じてリカバリ時間の短縮にも貢献します。 AWS FIS は以下のような特徴があります。 管理された障害実験： 実際の運用環境で発生する可能性のある障害をシミュレートすることで、事前に対策を講じることができます。 多様なリソース対応： AWS FIS は Amazon EC2 (EC2) 、 Amazon Elastic Container Service (ECS) 、 Amazon Elastic Kubernetes Service (EKS) 、 Amazon Relational Database Service (RDS) のほか、多くのAWSサービスをサポートしており、今後も追加のリソースやアクションがサポートされる予定です。 実験の安全性確保： CloudWatch アラームを使用して、特定の条件下で実験を自動的に停止させることができ、重要なビジネスメトリクスへの予期しない影響を防ぎます。 Resiliency Quest で学べること Resiliency Quest では、AWS FIS を通じてどのように障害をシミュレーションし、いかに障害に対する対応を実施するか学ぶことができます。また、アプリケーションの信頼性を高めるためのレジリエンスのベストプラクティスを理解し、レジリエンスの向上を図るための実践的なスキルが身につきます。 Resiliency Quest の内容のご紹介 次は、本ワークショップのより具体的な流れとシナリオをご紹介します。 あなたは MyDigitalWallet という架空のアプリケーションを運用しています。そんなある日、社長からあなた宛に「アプリケーションがダウンしている」との緊急連絡を受けます。顧客や社内からのプレッシャーが高まり、何とかしてアプリケーションを安定させなければなりません。 1 つのシナリオでは、アプリケーションがダウンした理由は MyDigitalWallet のユーザーが増加し、突然トラフィックが増加したといったケースです。この場合、AWS FIS を使ってトラフィック増加シナリオをシミュレーションし、どのように対策を講じるかを学びます。さらに、システムのパフォーマンスを監視し、問題の根本原因を特定するプロセスも体験します。 具体的なワークショップの流れは次のとおりです。 ワークショップの流れ シナリオ紹介： はじめの第一歩！前提となるシステムのアーキテクチャを理解します。 障害シミュレーション： AWS Fault Injection Service を使って実際に障害を引き起こします。 対応策の実装： アーキテクチャを修正し、同じ障害が再発してもシステムを止めない方法を考えます。 スコア表示： システムの稼働状況によってスコアリングされ、ダッシュボードに参加者の点数が表示されます。 ヒントと詳細実装方法： 行き詰まっても大丈夫！ヒントや実装方法を参考に問題をクリアしていきます。 具体的なシナリオのご紹介 ここからは実際にワークショプで体感していただくコンテナタスク障害のシナリオを Dive Deep してご紹介します。 まずは、提供されるワークショップのアーキテクチャを理解します。 ワークショップを開始すると、実験を行うための画面が表示されます。この画面に従って実験を進めていきます。 現在、画面表示は英語をサポートしていますが、近日中での日本語化を目下進めております。 MyDigitalWallet アプリケーションはサポートする ECS タスクに障害が発生しても、システムはアプリケーションがダウンタイムなしで機能し続け、すべての支払いトランザクションが正常に処理されるか、損失を最小限に抑えるように設計されている必要があります。ここでは、このアプリケーションがそのように設計されているという仮説を置きます。 この仮説を検証するために、FIS 実験テンプレートを活用します。FIS 実験テンプレートでは、’aws:ecs:stop-task’ アクションを使用して、1 つの ECS タスクを停止して中断することをシミュレートします。アプリケーションへの影響は 100 秒間監視されます。 Start ボタンをクリックすると、実際に FIS 実験テンプレートが起動され障害を引き起こします。その結果、ダウンタイムが発生しリクエストが失われることがわかりました。スコアは残念ながら 0 点です。 この状況に対応するために、ここからは実際の AWS 環境を操作しアーキテクチャを修正することで、同じ障害が再発しても継続的に稼働する環境を目指します。まずはヒントをみて解決策に関する大まかな推奨事項を把握します。進め方がわからない場合は、ポイントを消費してより詳細なガイダンスを見ることもできます。 ヒントに従って、AWS のマネジメントコンソールで設定を行っていきます。ECS の障害ということで、実際の設定の確認を進めます。ここから先は、ぜひ実際のワークショップでご確認ください。 設定を行った後に再度障害を引き起こしたところ、当初の仮説の通り、ダウンタイムなしで機能し続けることができました。スコアも満点になっています。 ダッシュボードを見ると自身の点数だけではなく参加者の点数も表示されます。競いながら楽しくハイスコアを目指してください！ シナリオのご紹介は以上となります。雰囲気が少しでも伝われば幸いです。 こんな方におすすめ 本ワークショップは、以下の方々に参加をおすすめしております。 AWS ユーザー： すでに AWS のサービスに触れているが、AWS FIS については未経験の方。 開発者： アプリケーションのレジリエンスを高めたいと考えているが、コーディングの経験が少ない方。 運用エンジニア： インフラストラクチャの信頼性を向上させるための実践的なスキルを身につけたい方。 チームリーダーやマネージャー： チーム全体でレジリエンスの重要性を学び、実践的なトレーニングを通じてスキルを高めたいと考えている方。 ワークショップの実施前提 参加に向けて AWS FIS の経験は不要です。また EC2、ECS、RDS の知識があるとより良いスコアを狙うことができますが、必須ではありませんので安心してご参加ください。 また現在本ワークショップは、AWS がホストする形式で開催しております。ワークショップの開催をご希望の際は AWS の担当営業もしくはソリューションアーキテクトにお問い合わせください。 Resiliency Quest まとめ Resiliency Quest は、レジリエンスを高める方法を学ぶための絶好の機会です。ハンズオン形式で学べるこのワークショップに参加して、実践的なスキルを身につけてください。興味を持たれた方は、ぜひ AWS のメンバーにお問い合わせください。一緒にアプリケーションの信頼性を高め、レジリエンスを強化しましょう！ この記事は、ソリューションアーキテクト 渡部 拓実 が執筆いたしました。

アイピー・パワーシステムズは、マンション等に設置されている非常用電源装置のメンテナンスサービス、電力一括受電サービス、受変電設備工事を中心に事業を展開しているJCOMのグループ会社です。アイピー・パワーシステムズでは、オンプレミスの仮想環境上で稼働していた電力管理システム等を 2024 年 1 月に AWS に移行。データベースもオンプレミスの Oracle Database から Amazon RDS for Oracle に移行しました。本ブログでは、アイピー・パワーシステムズが移行した電力管理システムについて、AWS への移行検討から移行までの流れと移行後の効果や課題について、お客様の声をご紹介します。 移行対象のシステム お客様は、オンプレミス上にある仮想環境に複数のシステムを構築しており、その中のメインのシステムである電力管理システムは、1,500 棟以上のマンションに設置されたスマートメーターから定期的に転送されてくる検針データを収集し、集計、料金計算、請求処理などを行うシステムです。このシステムのデータベースは、Oracle Database を採用していて、データ量が多く数億レコードを超えるテーブルが数テーブルあり、その中の一つは約 100 億近いレコードを格納しているような状況でした。このシステムは、1,500 以上のマンションから逐一データが転送されるため、システムが停止してしまうとデータ転送ができず、料金計算などの業務に影響が出てしまうような状況でした。 当該システムにおける課題 当該システムをオンプレミスで運用している中で、いくつかの課題がありました。 ・老朽化による運用負荷 当該システムが含まれる仮想環境とハードウェアは老朽化により、障害対応やメンテナンス作業が頻繁に発生しているような状況で、土日や深夜などの業務時間外対応も発生していたため、運用担当者にとって運用負荷が高い状況でした。また、外部に公開しているサービスでは、データ量が多いテーブルに対する参照処理が集中してしまうとパフォーマンス問題が発生することもあり、その問題の原因調査などの対処にも多くの時間が発生していました。 ・拡張性への懸念 上記パフォーマンス問題への対処や、今後のデータ量や処理量が増えた場合スケールアップする必要がありますが、現状の環境ではデータベースのライセンスをすぐに追加することが難しく、データベースサーバーの拡張でも設定変更などの準備作業が必要であり、このような拡張性への懸念を抱えたまま運用している状況でした。 ・BCP 対策への懸念 BCP対策も重要な課題でした。オンプレミス環境ではバックアップデータの遠隔地への保管は実施していましたが、実際に障害が発生した時にリカバリによる業務停止時間が大きくなる可能性がありました。また、運用に伴う設定変更などでバックアップしていたデータが正常にリカバリできるのか、システムとして正常に稼働できるのか、といった障害発生時の復旧についても懸念を抱えた状態での運用が続いていました。 クラウドへの移行を検討 このような状況から、ハードウェアを保持せず、スケールアップやメンテナンスなどのデータベース運用負荷が削減できるクラウドを前提に移行検討を開始しました。移行先の候補として複数のクラウドを対象にしました。移行に向けた検討項目としては、先の課題を解決可能なアーキテクチャであることはもちろん、コストや移行性などの項目で比較検討しました。一方で、定性的な観点として、事例数、クラウドベンダーやサードパーティが公開しているブログやセッション情報などの技術情報量、サポートの質、障害やメンテナンスによる運用担当者への負担など、現場の運用担当者にとって使いやすいクラウドであることも採用時の重要なポイントになっていました。そして、これらの検討項目を総合的に判断した結果、AWS に移行することに決定しました。データベースは、拡張性やバックアップ、Amazon RDS Performance Insights による運用の効率化、ワンストップでのサポートなどを考慮して RDS for Oracle SE2(License Included) を採用し、データベースの移行はダウンタイムを削減しつつ移行可能な AWS Database Migration Service（DMS） を採用することになりました。 アーキテクチャ AWS 移行後のアーキテクチャは以下の通りです。 AWS 移行準備と移行 AWS への移行は３つのフェーズに分けて実施しました。 ・フェーズ１ 全体の移行設計と、仮想環境上にある小規模システムの AWS への移行を実施。同時に、AWS Direct Connect によるオンプレミスと AWS 間のネットワークを構築。 ・フェーズ２ 電力管理システムの移行を実施。データベースについては並行して電力管理システムの大規模改修プロジェクトが走っており、そのプロジェクト完了後の移行としていたため、データベース以外のアプリケーションを AWS に移行。 ・フェーズ３ オンプレミスの Oracle を RDS for Oracle に移行。Oracle のバージョンアップに伴うアプリケーション側への対応や、RDS for Oracle 採用に伴い SYS ユーザーで実行していたプログラムの修正、DMS によるデータ移行のテストなど、RDS for Oracle 移行に向けた準備作業を実施。2024 年 1 月、RDS for Oracle への移行が完了し、すべてのシステムの AWS への移行を完了。データ移行については、DMS を使うことで、データ移行自体はほぼリアルタイムでの移行。移行時のプログラム切替作業や、アプリケーションテストなどで数時間のダウンタイムは発生しましたが、想定より短いダウンタイムでの移行を実現。 移行後の効果と課題 今回の AWS への移行により、以下のような効果を確認することができました。 ・運用工数を約 25% 削減 ハードウェアの障害対応やメンテナンスなどの対応がなくなり、土日や夜間の緊急対応もほぼゼロになりました。テスト環境の構築も容易になり、オンプレミスの時と比較して運用担当者の工数を約 25% 削減することができました。 ・パフォーマンスの改善 老朽化したハードウェアから RDS for Oracle に移行することで、パフォーマンスが改善しました。顧客計算の処理が 10 秒から 2 秒、データのロード処理も 15 分から 5 分に改善し、その他の処理でも改善が見られました。これにより、オンプレミスで発生していた参照処理の集中によるパフォーマンス問題も発生しなくなりました。さらに、Performance Insights でデータベースのパフォーマンス情報が可視化されたことで、定期的に Performance Insights を確認して効率が悪い SQL をチューニングするなど、より積極的な運用も可能になりました。 ・マネージドによる安定稼働 RDS for Oracle に移行したことで、バックアップや拡張性など、データベース運用にまつわる様々な懸念が解消されました。また、RDSのリージョン間自動バックアップを採用して大阪リージョンにバックアップを転送することで課題だったBCP対策も容易に実現することができています。さらに、データベースで問題が発生した際はサポートにワンストップで問い合わせすることができるなど、運用にまつわる運用担当者の工数だけでなく、データベース運用に関する心理的な負荷を大幅に削減することができたことも、目に見えない AWS 移行の大きな効果となっています。 一方で、AWS への移行時の問題もいくつか発生しました。 ・移行後のパフォーマンス遅延 データを移行してシステム切り替え後にパフォーマンスが大幅に遅延したため、切り戻しが発生しました。これは、移行先の RDS for Oracle のテーブルからインデックスが存在していなかったことで、不要な読み込みが大量に発生するという事象でした。切り戻し後、入念な移行テストを実施し再度移行した際は問題なく移行を完了させることができています。 ・一部パッケージシステムが AWS 未対応 一部のパッケージシステムが EC2 に未対応なものがあり、AWS に移行できず現状もオンプレミスのまま稼働しているシステムがあります。これはパッケージシステム自体の仕様ですが、仮想環境による複数システムでの移行ではこのような可能性があるため、移行評価時に適切に確認する必要があります。 まとめ アイピー・パワーシステムズでは、今回の AWS 移行により運用時の負荷やパフォーマンスを改善することができました。今回の AWS 移行について、アイピー・パワーシステムズ株式会社 カスタマーオペレーション部情報システムチーム長の榎木 卓郎 氏（写真左）は以下のように振り返っています。 「移行にあたり AWS のソリューションアーキテクトを始めとしたアカウントチームからの手厚いサポートで大変助かりました。移行後はパフォーマンスが改善したことでユーザーからのクレームもなくなりました。AWS サポートの質の高さも感じており、AWS に移行して本当に良かったと思っています。」 – アイピー・パワーシステムズ株式会社 カスタマーオペレーション部情報システムチーム長　榎木 卓郎 氏（写真左） – アイピー・パワーシステムズ株式会社 カスタマーオペレーション部情報システムチーム　廣瀬 壱行 氏（写真右） 今後は、AWS 移行で削減できた時間を使って、CI/CD の推進やデータベースエンジンの移行、Lambda やReserved Instance を使ったコスト最適化など、AWS のサービスを有効に使ってシステムの安定化やコスト最適化などをすすめていく予定です。

組み込みシステムは、家電製品や医療機器、空調機、自動車といった特定の機能を提供するために設計されたハードウェア及びソフトウェアを指します。このブログでは、AWS Summit Japan 2024 の製造業ブース内で展示される「仮想化で組み込みソフト開発・改善の高速化」のデモについて説明します。組み込みソフトウェア開発における課題と、AWS クラウドの導入による課題の解決方法とデモを紹介をします。 組み込みソフトウェア開発におけるトレンドと課題 近年、組み込みシステムは、IoT や AI / ML といった最新技術の普及に伴い、複雑化やスマート化が進んでいます。また、組み込みシステムである製品と AWS をはじめとしたクラウド上で構築されたサービスを接続し、お客様に新たな価値を提供する SaaS Plus a Box といったビジネスモデルを採用するケースが増えてきています。このような技術・ビジネスモデルの変化に伴い、製品を売った後も継続的な改善やセキュリティの強化が求められています。そのため、いち早くお客様への価値や安全を提供するために、ソフトウェアリリースサイクルを高速化する必要が出てきます。 クラウド上で構築されるサービスの開発においては、DevOps により高速に改善するアプローチがあります。今後は、組み込みソフトウェア開発でもこのスピード感が求められてきます。しかし、組み込みソフトウェア開発は、DevOps のアプローチが取れず、製品・サービス全体で開発・改善を高速化することが難しくなります。 その主な原因は、ハードウェアが完成することを待たないと開発が進められない点にあります。組み込みソフトウェアは特定のハードウェア上で動作することを前提としているため、開発には特殊な CPU アーキテクチャやペリフェラルを搭載したハードウェアが必要です。 このため、一般的な開発環境とは異なるツールチェーンやドライバーを使用する必要があり、デバッグやテストの際には物理的にデバイスに接続する必要があります。このような環境はサービス開発チームにも影響を及ぼします。製品とサービスをリリースするために欠かせない結合テストを行うためには、ハードウェアの手配や複雑なセットアップを必要とし、組み込みソフトウェア開発チームとのコミュニケーションコストもかかります。 ハードウェアが無いとデバッグやテストも行えないため、開発プロセスが自然とウォーターフォール開発に依存することになります。ウォーターフォール開発では、要件定義、設計、実装といった各段階が明確に区分けされており、前工程でリスクを最小限に抑え、手戻りを少なくするメリットがあります。しかし、ウォーターフォール開発の特性上、動くソフトウェアが後工程でようやくリリースされるため、ユーザーフィードバックが遅れがちになり、ニーズの把握が不十分になることがあります。また、パフォーマンスやサービスとの整合性といった要件に対するリスクの顕在化も遅れる可能性があります。 ソリューション このような課題を解消するためのアプローチとして、組み込みシステムを AWS 上で仮想化し、サービス開発と同じプラットフォームの上で開発を進めることが考えられます。組み込みソフトウェアを仮想化することで以下のメリットが出てきます。 俊敏性: ハードウェアが無くても瞬時に開発環境を提供することができるため、開発チームがすぐに開発業務を始めることができます。 弾力性: 開発者の増減に合わせて、自由にリソースの規模をスケールさせることができます。 コスト最適化: 弾力性の高い仕組みにより、開発・テスト用のハードウェア数を最小限に抑えることができるため、コストの最適化にも繋がります。 イノベーションの加速: サービス開発・組み込みソフトウェア開発の両チームが同じクラウド環境で協業することで、コミュニケーションコストを減らし、付加価値の高い業務に集中することができます。 サービス開発と組み込みソフトウェア開発の環境を AWS 上で構成すると以下のようなリファレンスアーキテクチャとなります。大きく4つの環境に分かれており、各環境に対して AWS IAM Identity Center により共通の認証・認可の仕組みを提供します。 開発環境: CI / CD パイプラインとアーティファクトリポジトリを管理します。サービス開発者は、アーティファクトリポジトリから最新の組み込みソフトウェアをダウンロードし、サービスとの結合テストに活用することができます。 検証環境: 製品とサービスを組み合わせた結合テストを実行します。組み込みソフトウェアは仮想化されているため、クラウド上で動作することも可能となり、ハードウェアのセットアップは不要となります。 本番環境: 製品のユーザーが実際に使用されている物理的な製品をサービスに接続します。この環境に対するアクセスは、製品を使用しているお客様データが含まれているため、データ保護・セキュリティの観点からアクセス許可範囲は限定的にする必要があります。 分析環境: 製品ユーザーの製品・サービス利用動向や CRM ( Customer Relationship Management ) に保存されたカスタマーサポート内容などから、改善点や問題を発見するための洞察を得ることができます。 開発環境を 1 つのプラットフォームで構成することにより、組み込みソフトウェア開発・サービス開発の垣根を無くし、高速にお客様に価値を届けることができます。また、両チームがお客様データに基づいて意思決定を行いやすくなるため、顧客ニーズに迅速に対応し、より良い製品サービスを提供することができます。 デモアプリケーションの紹介 AWS Summit Japan 2024 で展示されたデモをご紹介します。 ストーリー このデモでは、空調機の操作のための空調コントローラーという IoT プロダクトを想定します。空調機は人感センサー省エネ制御という、空調機が人の存在を感知する人感センサーを使用し、誰も部屋にいない時は空調機の動作を停止または低速運転に切り替える省エネ機能を有しています。ビル管理会社がこの機能をあまり有効化していないという課題が、空調機メーカーの BI (Business Inteligence) ダッシュボードによって判明しました。空調機メーカーは、空調コントローラーの UI を改善することで課題を解決できると考え、素早く新バージョンをリリースすることで、ビル管理会社の KPI であるエネルギー消費量の削減に応え顧客満足度の向上を目指します。 アーキテクチャ デモのアーキテクチャは以下のようになっています。 空調コントローラーには、Raspberry Pi を使用しています。ソフトウェアは、 Yocto Project をベースとしたカスタム Linux イメージを作成しています。 1. ユーザ分析 ユーザ分析では、IoT データやサポートケースの情報を BI ダッシュボードを作成して可視化します。BI ダッシュボードは、 Amazon QuickSight を使用して作成しており、人感センサー省エネ制御の利用状況や、サポートケースの情報を可視化しています。現在のユーザーの動線を見ると、多くのユーザは人感センサー省エネ制御の設定から自動制御モード (人感センサー省エネ制御の動作モードの設定画面) への遷移をしています。つまり、多くのユーザーは人感センサー省エネ制御の有効化に興味を示しているということです。しかし、当月の人感センサー省エネ制御の利用率は 23 % と低調になっているため、興味があるにも関わらず実際には設定を有効化していないということになります。一方で、問い合わせ履歴を確認すると、人感センサー省エネ制御に関する UI 操作の問い合わせが多いことが確認できます。データから、UI の操作性が機能の利用率を下げている一因であると推測できます。 2. ソース Push ダッシュボードから得た洞察を基に仮説を立て、組み込みソフトウェア開発チームはユーザーフレンドリーな新 UI を開発しました。旧 UI では、人感センサー省エネ制御の設定ボタンまで到達するためにスクロールが必要であったり、人感センサー省エネ制御を有効化するために制御の動作モードを少なくとも1つ有効化する必要があったりすることで、機能の有効化までに辿りつきづらい UI となっていました。新 UI では、スクロール不要とするようにボタンの間隔を縮小し、動作モードはデフォルト値を自動セットすることでお勧めの設定を促すようになっており、よりユーザーフレンドリーな UI となりました。 新 UI をリリースするため、ソースコードを AWS CodeCommit に Push し、 AWS CodePipeline , AWS CodeBuild による CI / CD パイプラインで新たなソフトウェアをビルド・テストしていきます。 3. リリース 組み込みソフトウェアのアーティファクトをリリースします。このデモでは Raspberry Pi で動作する空調コントローラーアプリケーションと、アプリケーションを動作させる組み込み Linux をビルドします。動作対象は、Raspberry Pi に加えて、オープンソースのエミュレータである QEMU と Amazon Machine Image ( AMI ) となり、イメージをそれぞれ作成します。AMI を作成するために、AWS のソフトウェアをインストールするレシピがまとめられているレイヤーである meta-aws を使用しています。 Yocto Project を使用することにより、稼働させるハードウェア又は仮想マシン特有のレシピを設定で切り替えることができます。 Yocto Project をベースとしたビルドパイプラインは GitHub リポジトリ aws4embeddedlinux-ci で公開されている CDK ライブラリを呼び出して構築しています。 4. テスト デバイスイメージだけでなく、QEMU や AMI をベースとしたアーティファクトを作成することで、デバイスレスでのテストが可能となります。これにより、クラウドで組み込みソフトウェアが動作するため、サービス開発者によってもシームレスに結合テストを実施し、製品・サービス間の連携を確認することが容易となります。下図では、 Amazon WorkSpaces を用いてVDI 上でのタッチパネルのテストを実施しています。 また、製品テストには実機を用いた結合テストも欠かせないので、 AWS Code Pipeline の手動承認アクションを追加し、パイプラインを停止し、承認者が実機テスト結果を確認して承認できるようにします。 5. デプロイ 全てのテストが完了したら、 AWS IoT Greengrass のコンポーネントをダウンロードします。 6. OTA AWS IoT Greengrass が OTA ( Over The Air ) アップデートにより製品に対して新しいコンポーネントをインストールします。 7. データ収集 製品は、 AWS IoT Greengrass のコンポーネントによりお客様から許可を得た上でユーザ行動ログや設定状態を MQTT 通信でクラウドに送信します。今回のデモでは、タッチパネルの画面遷移ログと空調コントローラーの設定を収集しています。また、CRM といった顧客データからも、顧客の行動やフィードバックが収集できます。今回のデモでは、サポートケース情報を収集し、分析対象に含めています。 8. 改善確認 以下のダッシュボードは、ソフトウェアアップデート後の状態です。人感センサー省エネ制御の設定から自動制御モードへの画面遷移数の変化は小さいものの、人感センサー省エネ制御の利用率が 40 % まで伸びました。UI の変更により顧客体験が向上し、より多くのユーザーが本機能を利用していることを、ダッシュボードから確認することができます。このように、異なる立場の開発者が同じ情報から意思決定を行うことで、効果的な機能改善が可能になります。 まとめ 組み込みソフトウェア開発は、要件の複雑化やスマート化に伴い、製品・サービスを使用するお客様へ高い価値を提供し続けるため、素早い市場投入・市場投入後の継続的な改善とセキュリティレベルの維持が求められています。この記事では、組み込みソフトウェアを仮想化し、製品・サービス両方の開発環境を AWS 上に構築しソフトウェアリリースサイクルを高速化するソリューションについて説明しました。また、AWS Summit Japan 2024 で展示された製造向け展示の一つであるスマートプロダクトエリアの「仮想化で組み込みソフト開発・改善の高速化」ブースで展示し、このソリューションの具体化されたストーリーを紹介しました。 村松 謙 (Ken Muramatsu @kenmuu) Amazon Web Services でソリューションアーキテクトとして製造業のお客様を中心にクラウド活用の技術支援を担当しています。AWS 以前は、組み込みソフトウェアエンジニアとして産業システムの開発に従事していました。 宇佐美 雅紀 (Masanori Usami @usamiii) ソリューション・アーキテクトとして、製造業のお客様を中心にご支援しています。AWS 以前は、組み込みソフトウェアのエンジニア、アーキテクトとしてさまざまなシステムの開発に従事していました。ソフトウェア工学の勉強が好きです。 梶山　政伸　(Masanobu Kajiyama @kajikun) 趣味は旅行で19ヶ国に行きました。現在はソリューションアーキテクトとして、製造業のお客様と共にクラウドジャーニーをしています。 中西 貴大 (Takahiro Nakanishi @taknakt) Amazon Web Services でソリューションアーキテクトとしてコングロマリットのお客様にクラウド活用の技術支援を担当しています。趣味はドライブや旅行です。 大久保 裕太 (Yuta Okubo @okyuta) Amazon Web Services でソリューションアーキテクトとして建設・不動産業のお客様を中心にクラウド活用の技術支援を担当しています。趣味はバスケと睡眠です。

「重要なものすべてが測定できるわけではなく、測定できるものすべてが重要であるわけでもない」この言葉は、成功を測定するための適切な指標とレポートを選択する難しさを表しています。これは、特にコンタクトセンターに当てはまります。コンタクトセンターを成功させるには、平均処理時間 (AHT) や離脱率などの標準指標を分析し、顧客生涯価値 (CLV) などの専門的な目標に合わせて指標をカスタマイズする必要があります。コンタクトセンターソリューションでは、独自のビジネス目標に沿って、従来の測定値と今後の測定両方を追跡する必要があります。 Amazon Connect は、スーパーバイザー、コンタクトセンターマネージャー、オペレーションマネージャーなどの役割を対象に、積極的かつ柔軟なアプローチでコンタクトセンターレポートを作成します。Amazon Connect は、ペルソナごとにリアルタイムデータと履歴データを組み合わせて提供し、さまざまなレベルの洞察を引き出すのに役立ちます。 Amazon Connect 分析データレイク など、Amazon Connect の最新のイノベーションの中には、標準レポートでは不十分なカスタムインサイトを引き出すのにも役立ち、最も重要なものを測定できるようにするものもあります。 コンタクトセンターチームのさまざまなメンバーが使用できるレポートをいくつか紹介します。 スーパーバイザー スーパーバイザーは、エージェントのグループのパフォーマンスの監視と管理、SLA の遵守の確認、コーチングとガイダンスの提供を担当するチームリーダーです。スーパーバイザーはチームを効果的に管理するため、レポートを必要としています。Amazon Connect では、サービスレベル、キューの待ち時間の長さ、エージェントのステータスなどを表示するダッシュボードをスーパーバイザーに提供しており、潜在的な問題をすばやく特定して解決できます。さらに、スーパーバイザーはエージェントパフォーマンス、キュー、およびコンタクト品質のレポートにアクセスして、エージェントと顧客のやりとりを監視および分析できます。これらの洞察により、コーチング、コンプライアンスチェック、継続的な改善が可能になります。 スーパーバイザーは、管理者ガイドでリアルタイムレポートと履歴レポートを確認できます。例としては、次のようなものがあります。 キューパフォーマンスダッシュボード エージェントアクティビティ監査レポート キューパフォーマンスダッシュボード コンタクトセンターマネージャー コンタクトセンターマネージャーは、人員配置、リソース配分、プロセスの最適化、カスタマーエクスペリエンス改善活動の推進など、コンタクトセンター全体を監督する戦略的リーダーです。Amazon Connect では、コンタクトセンターマネージャー向けに、履歴レポートとカスタマイズ可能なダッシュボードを包括的に提供しています。これらには、さまざまなチャネル (音声、チャット、タスクなど) にわたるサービスレベル、処理時間、放棄率、その他の主要な指標に関するデータが含まれます。マネージャーは、問い合わせの目的、言語、場所などのさまざまな属性に基づいてデータを細かく分類できます。このレベルのきめ細かな分析は、あらゆる規模の組織のデータ主導の意思決定と長期的な戦略計画に役立ちます。 コンタクトセンターマネージャーも、Amazon Connect 内の 効果的なスケジューリングと予測 に大きく依存しています。Amazon Connect に組み込まれたワークフォース管理機能には高度な予測機能があり、過去のコンタクトデータ、季節パターン、その他の要因を分析して将来の需要を正確に予測するのに役立ちます。これにより、 人員配置レベルを予測される問い合わせ量に合わせて、エージェントのスケジューリングを最適化することができます。さらに、Amazon Connect ではリアルタイムのスケジュール遵守性のモニタリングが可能で、スケジュールされたアクティビティに対するエージェントの現在の順守状況や、休憩やトレーニングなどの補助的な状態も表示されます。マネージャーとスーパーバイザーは、このリアルタイムの遵守性データをモニタリングツールとともに活用して、必要に応じて人員配置を調整し、チームメンバーがスケジュールに従って業務効率を維持できるようにすることができます。 コンタクトセンターマネージャーは、管理者ガイドでパフォーマンスレポートとダッシュボードを見ることができます。例には以下が含まれます。 履歴メトリクスレポート リアルタイムメトリクスレポート 予測の検査 スケジュール遵守性 Contact Lens 会話型分析ダッシュボード Amazon Connect Contact Lens 会話分析ダッシュボード コンタクトセンターの運営担当 コンタクトセンターの運営担当者は、コンタクトセンターの技術インフラストラクチャ、システム、およびプロセスが円滑に機能し、シームレスな顧客対応とエージェントの生産性を実現する舞台裏の担当者です。運用レベルでは、Amazon Connect は顧客ルーティングの有効性を測定するためのフローパフォーマンスなどの高度な分析機能を提供します。 2024 年 5 月、Amazon Connect は問い合わせレコード、エージェントパフォーマンス、 Contact Lens のインサイトなどのコンタクトセンターデータの単一ソースである 分析データレイク の一般提供を発表しました。コンタクトセンターの運営者は、Amazon Connect データを使用して独自のカスタムレポートを作成したり、ゼロ ETL を使用してサードパーティのソースからのクエリデータを組み合わせたりできます。Amazon Connect データレイクでは、過去のコンタクトセンターデータをすぐにクエリできるため、複雑なデータパイプラインを構築して維持する必要がなくなります。 Amazon Connect やサードパーティのデータにアクセスすることで、顧客生涯価値 (CLV) などの特殊な指標を作成できます。また、組織はデータレイクのデータを機械学習 (ML) モデルや人工知能 (AI) モデルと組み合わせて使用することで、コンタクトセンターの新たな最適化に役立つ情報を得ることができます。たとえば、エージェントとのやり取りが短くなる傾向は、セルフサービスの機会を表している可能性があります。Amazon Connect データレイクは、 Amazon QuickSight などのビジネスインテリジェンス (BI) ツールやその他のサードパーティのアプリケーションをサポートしており、レポートやダッシュボードをパーソナライズできます。これにより、運用のマネージャーは、選択したデータ視覚化ツールを使用して、重要なカスタマーエクスペリエンスの指標をモニタリングできます。 Amazon Athena などのクエリエンジンを通じて、Amazon Connect データレイク内の統合コンタクトセンターデータにアクセスできます。 Amazon Connect 管理者ガイド を参照して開始することができます。 Amazon QuickSight による Amazon Connect 分析データレイクのレポート例 まとめると、Amazon Connect のレポートと分析サービスは、コンタクトセンターに関わるさまざまなペルソナの多様なニーズに応えます。スーパーバイザーからマネージャー、運用チームまで、Amazon Connect はパフォーマンスの向上、運用の最適化、優れたカスタマーエクスペリエンスの提供に必要な洞察とツールを提供します。 6月3日から6日にラスベガスで開催された「Customer Contact Week」 のセッションもご覧ください。 Amazon Connect でカスタマーサービス体験を変革する準備はできていますか? お問い合わせください。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

本記事は、 Modernize your data observability with Amazon OpenSearch Service zero-ETL integration with Amazon S3 を翻訳したものです。翻訳は Solutions Architect の深見が担当しました。 私たちは、バージョン 2.13 以降のドメインでの Amazon OpenSearch Service の　 Amazon Simple Storage Service (Amazon S3) とのゼロ ETL 統合の 一般提供の開始を発表できることを喜ばしく思います。 この統合により、お客様は Amazon S3 と S3 ベースのデータレイクに格納されているオペレーショナルログを、ツールを切り替えることなくダイレクトクエリできるようになりました。 OpenSearch Service と S3 データセットにまたがってクエリを実行することで、運用とセキュリティイベントの包括的な分析を行うことができます。 OpenSearch Service との新しい統合により、AWS のゼロ ETL ビジョンが実現され、データの複製や複数の分析ツールの管理による運用の複雑さが軽減されます。 これにより、オペレーショナルデータへのダイレクトクエリを実行でき、コストと時間を削減できます。 OpenSearch は、Elasticsearch 7.10 から派生したオープンソース分散検索・分析スイートです。現在、OpenSearch Service には数万人のアクティブユーザーがおり、数十万のクラスターを管理し、毎月数兆件のリクエストを処理しています。 Amazon S3 は、業界をリードする拡張性、データ可用性、セキュリティ、パフォーマンスを提供するオブジェクトストレージサービスです。 あらゆる規模の企業やあらゆる業界が、データレイク、クラウド中心のアプリケーション、モバイルアプリなど、実質的にあらゆるユースケースに対して、無制限にデータを保存して保護できます。 コスト効率の高いストレージクラスとユーザーフレンドリーな管理機能により、コストを最適化し、データを整理し、ビジネス、組織、コンプライアンス要件に合わせて細かくアクセス制御を設定できます。 OpenSearch Service のこの興味深い新機能について詳しく見ていきましょう。 OpenSearch Service と Amazon S3 のゼロ ETL 統合を利用するメリット OpenSearch Service の Amazon S3 との ゼロ ETL 統合により、OpenSearch Service 外の Amazon S3 に格納されているクエリの頻度が低いデータに対して、OpenSearch Service SQL と PPL の高度な分析機能を直接利用できます。また、他の OpenSearch との統合とも連携しているため、事前にパッケージ化されたクエリと可視化を導入して、データを分析できます。すぐに利用を開始できるよう簡単に設定できます。 次の図は、OpenSearch Service が一般的な AWS ログタイプの、あまり頻繁にクエリされないログがもつ価値を引き出す方法を示しています。 OpenSearch Service の ダイレクトクエリ を使用すると、Amazon S3 のデータに対してクエリを実行できます。 OpenSearch Service は、Amazon S3 のオペレーショナルログやデータレイクを分析するための Amazon S3 とのダイレクトクエリ統合機能を提供しています。 これにより、サービス間の切り替えを行うことなく、クラウドオブジェクトストアのデータを分析し、同時に OpenSearch Service のオペレーショナル分析と可視化機能を利用できます。 多くのお客様は現在、お客様自身が提供するソリューションに関するイベントデータを Amazon S3 に保存しています。オペレーショナル分析の文脈では、Amazon S3 は通常、 VPC フローログ 、 Amazon S3 アクセスログ 、 AWS ロードバランサーログ 、および他の AWS サービスからのイベントソースの宛先として使用されています。お客様はまた、コンプライアンスと監査のニーズから、アプリケーションイベントのデータを直接 Amazon S3 に保存しています。Amazon S3 の 耐久性 と拡張性により、低コストで利用できる長期保存やアーカイブオプションを必要とする多くのお客様にとって、データの保存先として明快な選択肢になります。 これらのソースからのデータを、ホットストレージとウォームストレージ層に格納された OpenSearch Service に取り込むことは、生成されるイベントのサイズとボリュームのために、現実的ではないケースがあります。OpenSearch Service のインデックスに格納されるイベントソースの一部については、データに対して実行されるクエリの量がクラスターにデータを保持し続けるコストに見合わないものもあります。以前は、クラスターにプロビジョニングされたストレージに基づいて、OpenSearch Service に取り込むイベントソースを選択する必要がありました。他のデータにアクセスするには、 Amazon Athena などの別のツールを使用して、Amazon S3 上のデータを表示する必要がありました。 実際にこの新しい統合がどのように恩恵をもたらしたかを、Arcesiumの事例で見てみましょう。 “ Arcesiumは、金融サービス業界向けに高度なクラウドネイティブのデータ、オペレーション、分析機能を提供しています。当社のソフトウェア・プラットフォームは、1日に何百万件ものトランザクションを処理し、その過程で大量のログと監査記録を出力します。私たちが処理し、保存し、分析する必要のあるログデータの量は、私たちの保持とコンプライアンスのニーズを考慮すると、指数関数的に増加していました。Amazon OpenSearch Service の Amazon S3との新しいゼロ ETL 統合は、大規模でコストのかかる OpenSearch クラスタを維持したり、アドホックな取り込みパイプラインを構築したりする運用コストをかける代わりに、Amazon S3 にすでに保存されているクエリ頻度の低いログを分析できることで、私たちのビジネスのスケールに貢献しています。” – Kyle George, SVP & Global Head of Infrastructure at Arcesium. Amazon S3 へのダイレクトクエリにより、複雑な抽出、変換、ロード (ETL) パイプラインを構築する必要がなくなり、OpenSearch Service と Amazon S3 ストレージの両方にデータを複製するコストがかからなくなりました。 基本概念 ダイレクトクエリ接続を構成した後、OpenSearch Service Query Workbench を使用して AWS Glue Data Catalog 内にテーブルを作成する必要があります。ダイレクトクエリ接続は、Glue Data Catalog テーブル内のメタデータに依存する形で、Amazon S3 に格納されているデータを参照します。AWS Glue クローラーまたは Athena によって作成されたテーブルは、現在サポートされていないことに注意してください。 Data Catalog テーブルの構造、SQL インデックス技術、OpenSearch Service インデックスを組み合わせることで、クエリのパフォーマンスを加速し、高度な分析機能を解放し、クエリのコストを抑えることができます。 データを加速する方法の例をいくつか示します。 スキップインデックス – Amazon S3 に格納されているデータのメタデータのみを取り込み、インデックス化します。スキップインデックスを持つテーブルに対してクエリを実行すると、クエリプランナーがインデックスを参照し、すべてのパーティションとファイルをスキャンするのではなく、クエリを書き換えて効率的にデータの場所を特定します。これにより、スキップインデックスは分析に関連する格納データの特定の場所を素早く絞り込むことができます。 マテリアライズドビュー – マテリアライズドビューを使用すると、集計などの複雑なクエリを使ってダッシュボードの可視化を強化できます。マテリアライズドビューは、データの一部を OpenSearch Service のストレージに取り込みます。 カバリングインデックス – カバリングインデックスを使用すると、テーブル内の指定されたカラムからデータを取り込むことができます。これは 3 つのインデックスタイプの中で最も高性能です。OpenSearch Service が目的のカラムからすべてのデータを取り込むため、パフォーマンスが向上し、高度な分析を実行できます。OpenSearch Service は、カバリングインデックスデータから新しいインデックスを作成します。この新しいインデックスを使って、ダッシュボードの可視化や、異常検知や地理空間機能などの他の OpenSearch Service 機能を利用できます。 S3 バケットに新しいデータが入ると、マテリアライズドビューとカバリングインデックスのリフレッシュ間隔を設定して、Amazon S3 上の最新のデータにローカルでアクセスできるようにすることができます。 ソリューションの概要 VPC フローログをソースとして試してみましょう! 前述のように、多くの AWS サービスはログを Amazon S3 に出力します。VPC フローログは、 Amazon Virtual Private Cloud (Amazon VPC) の機能で、VPC 内のネットワークインターフェースの送受信 IP トラフィックに関する情報をキャプチャできます。 このウォークスルーでは、次の手順を実行します。 S3 バケットが未作成の場合は作成してください。 トラフィックが生じており、ログを Amazon S3 上に Parquet 形式で保存できる既存の VPC を使用して、VPC フローログを有効にしてください。 S3 バケットにログが存在することを確認してください。 データが格納されている S3 バケットと Data Catalog に対して、ダイレクトクエリ接続を設定してください。 VPC フローログ用の統合をインストールしてください。 S3 バケットの作成 既存の S3 バケットがある場合は、バケット内に新しいフォルダを作成することでそのバケットを再利用できます。バケットを新規作成する必要がある場合は、Amazon S3 コンソールに移動し、組織のポリシーに適したバケット名で Amazon S3 バケットを作成してください。 VPC フローログの有効化 VPC フローログを有効にするには、次の手順を実行してください。 Amazon VPC コンソールで、アプリケーショントラフィックからログを生成できる VPC を選択します。 フローログ タブで、 フローログを作成 を選択します。 フィルター では、 すべて を選択します。 最大集約間隔 を 1 分に設定します。 送信先 では、 Amazon S3 バケットに送信 を選択し、前に作成したバケットの S3 バケット ARN を入力します。 ログレコード形式 では、 カスタム形式 を選択し、 Standard attributes を選んでください。 この記事では、執筆時点で Amazon Elastic Container Service (Amazon ECS) の属性は OpenSearch との統合がまだ実装されていないため、選択しません。 ログファイル形式 では、 Parquet を選択してください。 Hive 互換 S3 プレフィックス では、 有効化 を選択してください。 時間にログをパーティション分割 を 1 時間ごと (60 分) に設定してください。 S3 バケットにログが受信されていることの確認 先ほど作成した S3 バケットに移動すると、データがそのバケットにストリーミングされていることがわかります。 ディレクトリ構造を掘り下げていくと、ログが 1 時間ごとのフォルダに配信され、1 分ごとに出力されていることがわかります。 VPC フローログを S3 バケットに流し込めるようになったので、次は Amazon S3 上のデータと OpenSearch Service ドメインの間に接続を設定する必要があります。 ダイレクトクエリデータソースの設定 このステップでは、Glue Data Catalog のテーブルと Amazon S3 のデータを使用するダイレクトクエリデータソースを作成します。このアクションにより、Hive メタストア (Glue Data Catalog のデータベースとテーブル、およびデータソースがアクセスするバケットとフォルダーの組み合わせに格納されている Amazon S3 のデータ) にアクセスするために必要なすべてのインフラストラクチャが作成されます。 また、セキュリティプラグインの きめ細かなアクセス制御 に適切な権限が組み込まれるため、開始時の権限を気にする必要はありません。 次の手順に従って、ダイレクトクエリデータソースを設定してください: OpenSearch Service ドメインで、ナビゲーションペインの ドメイン を選択します。 ドメインを選択します。 Connections タブで、 Create new connection を選択します。 Name には、 zero_etl_walkthrough のようにダッシュを含まない名前を入力します。 Description には、説明を入力します。 Data source type では、 Amazon S3 with AWS Glue Data Catalog を選択します。 IAM role では、初めての場合は、 Create a new role を選択して、ダイレクトクエリの設定で権限を処理させます。後で組織のコンプライアンスとセキュリティニーズに基づいて編集できます。この記事では、ロール名を zero_etl_walkthrough としています。 S3 buckets では、さきほど作成したバケットを使用します。 Grant access to all existing and new buckets という項目のチェックボックスは選択しないでください。 Checkpoint S3 bucket では、作成したバケットと同じものを使用します。チェックポイントフォルダは自動的に作成されます。 AWS Glue tables では、Data Catalog で作成したものがないため、 Grant access to all existing and new tables を有効にします。 VPC フローログの OpenSearch 統合では、Data Catalog 内にリソースが作成されるため、それらのリソースにアクセスする権限が必要になります。 作成 を選択します。 初期設定が完了したので、VPC フローログの OpenSearch 統合をインストールできます。 VPC フローログの OpenSearch 統合のインストール OpenSearch のインテグレーションプラグインには、さまざまなソースから生成されたデータを可視化し、操作するのを簡単にするための、事前構築済みのダッシュボード、ビジュアライゼーション、マッピングテンプレート、その他のリソースが多数含まれています。 Amazon VPC 向けのインテグレーションでは、Amazon S3 に保存された VPC フローログデータを表示するためのさまざまなリソースがインストールされます。 このセクションでは、最新の統合パッケージをインストールするための手順を説明します。次に、OpenSearch 統合のインストール方法を示します。マイナーバージョンまたはメジャーバージョンのリリース時点では、VPC フローログ、NGINX、HA Proxy、Amazon S3 (アクセスログ) などの最新の統合が含まれている場合がほとんどです。ただし、OpenSearch はオープンソースのコミュニティ主導のプロジェクトであり、現在の展開に含まれていない新しいバージョンや新しい統合が登場することが予想されます。 OpenSearch と Amazon VPC の統合の最新バージョンの検証 OpenSearch Service の以前のバージョンから 2.13 にアップグレードする必要があります。このポストの内容と、あなたのデプロイ状況が一致していることを確認しましょう。 OpenSearch Dashboards で Integrations タブに移動し、 Amazon VPC を選択します。インテグレーションのリリースバージョンが表示されます。 バージョン 1.1.0 以降がインストールされていることを確認してください。デプロイ環境にインストールされていない場合は、OpenSearch カタログから最新バージョンのインテグレーションをインストールできます。以下の手順を実行してください。 OpenSearch カタログ に移動します。 Amazon VPC Flow Logs を選択します。 amazon_vpc_flow_1.1.0 というラベルのリポジトリフォルダから、 1.1.0 Amazon VPC integration ファイルをダウンロードします。 OpenSearch ダッシュボードの Dashboards Management プラグインで、 Saved Objects を選択します。 Import を選択し、ローカルフォルダを参照します。 ダウンロードしたファイルをインポートします。 このファイルには、インテグレーションを作成するために必要なすべてのオブジェクトが含まれています。インストール後、Amazon VPC OpenSearch インテグレーションのセットアップ手順に進むことができます。 OpenSearch と Amazon VPC の統合設定 さっそく統合をインストールしましょう: OpenSearch Dashboards で、 Integrations タブに移動します。 Available タブに遷移し、 Amazon VPC の統合を選択します。 バージョンが 1.1.0 以降であることを確認し、 Set Up を選択します。 Display Name はデフォルトのままにします。 Connection Type では、 S3 Connection を選択します。 Data Source では、前の手順で作成したダイレクトクエリ接続の名前を選択します。この投稿では zero_etl_walkthrough を使用します。 Spark Table Name では、事前入力された amazon_vpc_flow のままにします。 S3 Data Location では、前の手順で設定した VPC Flow Logs によって作成されたログフォルダの S3 URI を入力します。この投稿では s3://zero-etl-walkthrough/AWSLogs/ を使用します。 S3 バケット名はグローバルに一意である必要があり、会社のコンプライアンスガイダンスに準拠したバケット名を使用することを検討する必要があります。 一意性を保証するには、UUID に説明的な名前を付けるのが良い選択肢です。 S3 Checkpoint Location では、定義したチェックポイントフォルダの S3 URI を入力してください。チェックポイントは、ダイレクトクエリ機能のメタデータを格納します。選択したバケットの空のパスまたは未使用のパスを選んでください。この記事では、前に作成したバケットの s3://zero-etl-walkthrough/CP/ を使用します。 Queries (recommended) と Dashboards and Visualizations for Flint Integrations using live queries を選択します。 「Setting Up the Integration – this can take several minutes. （インテグレーションのセットアップ – これには数分かかる場合があります）」というメッセージが表示されます。この特定のインテグレーションでは、Amazon S3 内のデータ上にスキップインデックスとマテリアライズドビューが設定されます。 マテリアライズドビューは、データをバッキングインデックスに集約し、すべてのデータを取り込んでその上に可視化を構築するよりも、クラスター内のデータ容量を大幅に小さくすることができます。 Amazon VPC 統合のインストールが完了すると、さまざまなアセットを利用できるようになります。インストール済みの統合を確認すると、Amazon S3 上のデータを使ってデータ探索を始められるクエリ、ビジュアライゼーション、その他のアセットが見つかります。この統合でインストールされるダッシュボードを見てみましょう。 コストはいくらですか？ OpenSearch Service のダイレクトクエリでは、ワークロードで消費されたリソースのみの料金が発生します。OpenSearch Service では、外部データを照会するために必要な計算リソースと、オプションで OpenSearch Service 内のインデックスを維持するための計算リソースのみが課金されます。計算容量は OpenSearch Compute Unit (OCU) で測定されます。クエリやインデックス作成が行われていない場合は、OCU は消費されません。次の表は、us-east-1 で HTTP ログを検索した場合の計算料金の例を示しています。 クエリごとにスキャンされるデータ (GB) クエリごとの OCU 価格 (USD) 1-10 $0.026 100 $0.24 1000 $1.35 料金は問い合わせごとに使用される OCU に基づいているため、このソリューションは頻繁に問い合わせされないデータ向けにカスタマイズされています。ユーザーがデータを頻繁に問い合わせする場合は、 OR1 インスタンス や UltraWarm などのストレージ最適化手法を活用し、OpenSearch Service への完全な取り込みを実施することが適切になります。 ゼロ ETL 統合で消費された OCU は、 AWS Cost Explorer にアカウントレベルで表示されます。 アカウントレベルで OCU 使用量を把握し、しきい値を設定して、しきい値を超えた際にアラートを出すことができます。 Cost Explorer でフィルタリングする使用量の種類の形式は、RegionCode-DirectQueryOCU (OCU 時間) です。 AWS Budgets を使用して予算を作成し、DirectQueryOCU (OCU 時間) の使用量が設定したしきい値に達したときにアラートを設定できます。 また、 Amazon Simple Notification Service (Amazon SNS) トピックと、ターゲットとして AWS Lambda 関数を使用してしきい値の条件を満たしたときにデータソースをオフにすることもできます。 サマリ ダイレクトクエリ接続機能、OpenSearch 統合、および OpenSearch Service の Amazon S3 との ゼロ ETL 統合がどのように機能するかの概要を理解いただけたら、この機能をご自身の組織のツールセットの一部として利用することを検討してください。 OpenSearch Service の Amazon S3 との ゼロ ETL 統合により、イベント分析の新しいツールが利用できるようになりました。 ホットデータを OpenSearch Service に取り込めば、リアルタイムに近い分析とアラートが可能になります。 主にイベント後の分析と相関分析に使用される頻繁にクエリされることのない大量のデータは、Amazon S3 上でクエリできるため、データを OpenSearch Service に移動する必要がありません。 データは、コスト効率の高い Amazon S3 に保存されたままで、分析のために OpenSearch Service にデータを移動するための追加インフラストラクチャを構築することなく、必要に応じてデータにアクセスできます。 詳細については、 Amazon S3 での Amazon OpenSearch Service のダイレクトクエリの操作 を参照してください。 著者について Joshua Bright は、Amazon Web Services のシニアプロダクトマネージャーです。Joshua は OpenSearch Service チームでデータレイク統合イニシアチブを主導しています。仕事以外では、Joshua は自然の中を散歩しながら鳥のさえずりを聞くのが好きです。 Kevin Fallis は、Amazon Web Services のプリンシパル スペシャリスト ソリューションアーキテクトです。お客様が適切な AWS サービスの組み合わせを活用して、ビジネス目標を達成できるよう支援することに情熱を注いでいます。仕事後の活動には、家族、DIY プロジェクト、大工仕事、ドラムを演奏すること、そして音楽全般が含まれます。 Sam Selvan は、Amazon OpenSearch Service の Principal Specialist Solution Architect です。

生成 AI アプリケーションの構築には、適切な日本語大規模言語モデル (LLM) の選定と活用が不可欠です。AWS では Amazon Bedrock , Amazon SageMaker JumpStart , AWS Marketplace でさまざまな基盤モデル (Foundation Model; FM) および大規模言語モデル (Large Language Model; LLM) を提供しています。最近、日本のスタートアップ企業である ELYZA の日本語 LLM が SageMaker JumpStart に掲載され、AWS 環境へワンクリックで簡単にデプロイできるようになりました。 今回、 ELYZA Japanese Llama 2 7B の 2つのモデルが SageMaker JumpStart で公開されました。JumpStart に掲載された ELYZA-japanese-Llama-2-7b-chat , ELYZA-japanese-Llama-2-7b-fast-chat いずれも Meta Llama 2 をベースとし、OSCAR や Wikipedia といった日本語コーパスを用いて継続事前学習を行っています。さらに、ELYZA の高品質データを用いた事後学習 (ファインチューニング) が施されています。後者の ELYZA-japanese-Llama-2-7b-fast-chat モデルでは日本語の語彙を取り込むことで辞書を拡張しており、日本語テキスト内のトークン数を 55% 削減、生成速度が 1.82 倍に向上しています。これらのモデルは独自データ ELYZA Tasks 100 によっても評価され、当初モデルがアナウンスされた2023年8月時点では日本語モデルの中でも高い性能を示していました。なお、モデルの性能評価など詳細については モデル公開時のブログ をご参照ください。 ELYZA はその後も、Llama 2 ベースで 13B モデルの公開 [ Announcement , Hugging Face ] と、70B モデルの発表・デモ公開 [ Announcement , Demo ] を行いました。Llama 2 ベースのモデルは Amazon EC2 Inf2 インスタンスを活用してコスト・パフォーマンス良く推論することが可能で [ Blog ]、特に ELYZA Llama 2 70B で Speculative Decoding という高速化手法を用いた Inf2 上での推論が技術ブログで解説されています [ Blog ]。現在 AWS 上では、SageMaker を用いたデプロイの他に、Meta Llama 2 などのアーキテクチャをベースとした公開済みのモデルを Amazon Bedrock に取り込む Custom Model Import (preview) [ Docs ] という機能も提供されています。このように、様々な方法で ELYZA のモデルを活用することができます。 SageMaker JumpStart でのデプロイ方法は、すでに JumpStart に掲載されいてる rinna , CyberAgent や Stability AI による日本語 LLM の手順を参照してください。 著者について 針原 佳貴 (Yoshitaka Haribara) は AWS Japan のスタートアップソリューションアーキテクトです。最近は生成 AI 基盤モデル・大規模言語モデル開発などのワークロードを中心に担当しています。趣味はドラムです。 久保 隆宏 (Takahiro Kubo) は AWS Japan の機械学習領域のデベロッパーリレーションを担当しており、「機械学習をするなら AWS 」と感じて頂くべくコンテンツの作成とフィードバックの収集による AWS サービスの改善を行っています。

この投稿はネットアップ合同会社 Zhao Mandy 氏に、Amazon FSx for NetApp ONTAP によるイミュータブルバックアップの取得について寄稿いただいたものです。 こちらは、サイバーレジリエンスブログシリーズの第 2 回です。本ブログシリーズでは、サイバーレジリエンスについて組織の重要な資産である「データ」の観点で 3 回に亘って基礎からご紹介していきます。 第 1 回ブログでは、「サイバーレジリエンス」に関する基礎的な内容を解説 しましたが、今回はデータ保護の観点から脅威となっているランサムウェアへの対策を中心にイミュータブルバックアップについてご紹介していきます。 データ紛失と改ざんは企業にとって深刻な影響をもたらす可能性があります。従来のバックアップ手段はデータ損失を防止しますが、バックアップ自体が攻撃され、障害になる可能性もあります。そのため、バックアッププロセスにもデータセキュリティの補強が必要です。 イミュータブル (変更不可) バックアップとは、あらかじめ設定された期間中に削除・改ざんできないバックアップファイルやデータコピーのことです。イミュータブルバックアップは、従来のバックアップと同じくプライマリーサーバー障害時にデータ損失を防止する役割だけでなく、ランサムウェアからのデータ保護にも役立ちます。 ランサムウェアは、データを標的にして暗号化し、身代金を支払うまで所有者がアクセスできないようにするサイバー攻撃の手法です。従来のバックアップ手段は効果的ですが、万全な対策ではありません。最近のランサムウェアはバックアップそのものを暗号化するように設計されており、ランサムウェアによるバックアップサイトにも被害が発生した場合、データを復旧することはさらに難しくなります。 ランサムウェア対策の観点でイミュータブルバックアップの存在意義は、いつでもファイルを復元できるということであり、復元しようとしたときにファイルが壊れていたり暗号化されていたりして、バックアップ・ソフトウェアが実際に正しく動作するかどうかを心配する必要がないということです。 ただし、イミュータブルバックアップの不変性には他のリスクを伴う可能性があります。イミュータブルバックアップの保存期間を長く設定すると、ストレージ容量を大量に消費するため、データ保存のコストが増加する可能性があります。また、ポリシー設計や運用管理によるストレージ管理者の負荷が高くなります。逆に、保存期間が短すぎると、組織が重要なデータを復旧できなくなる危険性があります。イミュータブルバックアップを運用する時、あらかじめバックアップの設計に工夫が必要です。 Amazon FSx for NetApp ONTAP イミュータブルバックアップソリューションの紹介 スナップショットは、データの可用性、信頼性、セキュリティを確保するための強力なデータ保護技術です。 Amazon FSx for NetApp ONTAP (FSx for ONTAP) は、フルマネージドの Snapshot と管理機能を提供します。FSx for ONTAP ファイルシステムを作成すると、Snapshot 機能はデフォルトで有効になっています。 FSx for ONTAP の Snapshot 機能により、Point in Time 方式でボリュームのデータコピーを作成します。Point in Time 方式は、データに変更が行われた時にデータブロックをそのままコピーするのではなく、ブロックへのポインタだけを変更するため、変更が発生してもほぼ瞬時にスナップショットが作成されます。余計な読み書きが発生しないため、スナップショット取得時のパフォーマンスオーバーヘッドが少ないです。ファイルデータとスナップショットは同じ場所で保存されますが、変更された部分に対してのみストレージ容量を消費するため、従来の Copy on Write 方式より容量効率が優れています。Snapshot 機能を活用してローカルまたはバックアップサイトでデータコピーを作成することで、ランサムウェア攻撃からデータの保護と迅速な復旧が実現できます。 最近のランサムウェア攻撃は元データをターゲットするだけではなく、スナップショットコピーも攻撃のターゲットとして暗号化されたり、削除されたり、バックアップ先が攻撃されるケースも増えています。バックアップデータが読み取り専用に設定しても、ランサムウェアの被害に気づくのが遅れると、ランサムウェアによる暗号化されたバックアップデータが暗号化前の正常なバックアップデータを食いつぶしてしまう可能性があります。 このような攻撃に対する保護対策として、FSx for ONTAP では「Tamperproof Snapshot」という機能が提供されています。Tamperproof Snapshot 機能を使用すると Snapshot コピーが指定した期間でロックされ、有効期限まで改ざん・削除できなくなります。この機能により、ランサムウェアの攻撃を防止することができます。また、管理者権限の漏洩や内部の不正な管理者による Snapshot の削除も防ぐことが可能です。ボリュームがランサムウェアによる被害を受けた場合、ロックされた Tamperproof Snapshot を使用してデータを復元できます。 FSx for ONTAP で Snapshot の作成と管理 ここからは ONTAP CLI を使って Snapshot を作成・管理する方法をご紹介します。 管理エンドポイントに ssh でログインしてファイルシステムの状態を確認します。FSx for NetApp ONTAP の管理エンドポイントは指定した IP アドレス範囲に自動作成されるもので、AWSコンソールから確認することができます。 >ssh fsxadmin@management_endpoint_ip 図 1: アクセス時のコンソール画面 ファイルシステムに ssh で接続すると、SVM の状態が確認できます。volume show コマンドで Volume の一覧情報を確認できます。 >volume show 下記のコマンドで Snapshot Policy の確認ができます。デフォルトの Snapshot 取得ポリシーでは、合計 10 個の Snapshot が定時的に保存されます。 >snapshot policy show -policy policyName 図 2: Snapshot Policy の確認 hourly、daily、weekly という 3 種類のスケジュールが有効になっており、それぞれ毎時 6 世代、日次 2 世代、週次 2 世代というスケジュールで Snapshot を取得しています。デフォルトのポリシーを利用しない場合、ユーザー自身で Snapshot Policy をカスタマイズすることも可能です。 取得時間の詳細を確認することもできます。下記のように、 job schedule cron show コマンドで 1 時間ごとの Snapshot は何分で取得するか、1 日ごとの Snapshot は何時何分で取得するか、1 週間ごとの Snapshot は何曜日の何時何分で取得するか、詳しく確認することができます。 図 3: Snapshot 取得スケジュールの確認 スケジュールされたタイミングを待たずに手動で Snapshot を取得することもできます。 下記のコマンドでボリューム volad の Snapshot を手動で作成します。 >volume snapshot create 図 4: 手動での Snapshot 作成 Snapshot 作成後、下記のコマンドとオプションで Volume のスペース配分を確認します。 >volume show volName -fields percent-snapshot-space, snapshot-space-used, snapshot-reserve-available Volume の容量のうち 5 %が Snapshot 用に snapshot-reserve として予約されています。 図 5: 作成した Snapshot の確認 このようにスケジュール通りで作成される Snapshot は SnapMirror というストレージレベルでのレプリケーション機能を活用してデータをプライマリサイトからリモートサイトに転送すると、よりセキュアなバックアップ環境を構築することが可能です。また、ファイルがランサムウェアによって暗号化されても、Snapshot コピーから一瞬でデータをリストアしてデータ損失のリスクを最小限に抑えられます。 FSx for ONTAP の Tamperproof Snapshot 機能 ここからは ONTAP CLI を使って Tamperproof Snapshot を作成・管理します。 新規ボリューム/既存ボリュームに対して Tamperproof Snapshot を設定できます。ONTAP CLI を使用して、 volume create および volume modify に -snapshot-locking-enabled オプションを指定します。 > volume modify -vserver vserverName -volume volumeName -snapshot-locking-enabled 図 6: 既存ボリュームへの Tamperproof Snapshot の設定 下記のコマンドを使って、手動で Tamperproof Snapshot の保持期限を設定/確認します。 >volume snapshot modify-snaplock-expiry-time -vserver vserverName -volume volumeName -snapshot snapshotName -expiry-time “mm/dd/yyyy HH:MM:SS” 図 :7 Tamperproof Snapshot 保持期限の設定と確認 snapshot delete コマンドを使って、Tamperproof Snapshot が削除できないことを確認します。 図 8: Tamperproof Snapshot 削除試行 留意点として、Tamperproof Snapshot は通常の Snapshot と異なり、保持世帯数より保持期間が優先されます。保持期間が終わっていない場合、指定した保持数を超えても Snapshot が残ります。例えば、1 日毎に Snapshot を作成するといったような Snapshot Policy を設定しました。Snapshot の保持数を 5、保持期間を 1 か月に設定した場合、1 か月経った時点で Snapshot の保持数は 5 を超えて 30 または 31 になります。 まとめ バックアップやスナップショットのリカバリポイントを標的にするランサムウェアによる攻撃が増えていますが、FSx for ONTAP の Tamperproof Snapshot 機能を使用して改ざん防止スナップショットを作成すれば、プライマリシステムもバックアップシステムもランサムウェア攻撃を防ぐことができます。ペタバイト級のデータを数秒で復旧できるため、組織のダウンタイムを最小限に抑えることができます。さらに、Tamperproof Snapshot コピーは、ランサムウェアの攻撃者や不正な管理者が削除したり変更したりできないため、攻撃が発生しても大切なデータを保護できます。このようなイミュータブルバックアップにより、クリーンなコピーでデータを保護することで、お客様のランサムウェア対策強化に役立ちます。

本稿は株式会社ナウキャスト データ & AI ソリューション事業部 事業責任者 片山 燎平様と Amazon Web Services Japan ソリューションアーキテクト 宮﨑の共同執筆です。LLM の業務活用に取り組まれる方の参考となれば幸いです。また、今回内容を含む 講演動画 も公開されておりますので、ご興味をお持ち頂けましたらあわせてご覧ください。 == 株式会社ナウキャスト では POS データやクレジットカードの決済データといった「オルタナティブデータ」を解析し、リアルタイムな経済統計の開発、生活者の消費行動や企業活動をより早く正確にとらえるデータソリューションの提供に取り組んでいます。POS データやクレジットカードなどの決済データ、ニュースや SNS 投稿のテキストデータといったオルタナティブデータを解析し、経済統計のリアルタイム化や企業の経営戦略の見える化を行い、国内外 250 社以上の金融機関、シンクタンク、政府、政府系金融機関、海外ヘッジファンド等の資産運用、経済調査業務を支援しています。 現在ナウキャストでは、国内外の資産運用会社と生成 AI / 大規模言語モデル (LLM) を活用した業務効率化システムの開発を推進しています。当該業務では資産運用における判断・意志決定のために膨大な適時開示資料から人力でデータ抽出を行っており、データの正確性は担保しつつ、データ抽出処理を効率化する仕組みの構築が求められていました。 本稿では、弊社における LLM によるデータ抽出効率化の取り組みの一例として、適時開示資料である決算短信からセグメント別売上情報を抽出する処理の実装とその成果についてご紹介します。 セグメント別売上情報抽出業務：現行課題 （図1. セグメント別売上情報抽出 – 手動） セグメント別売上情報抽出の業務では、適時開示資料をもとに、Excel などにデータを転記していく作業を行います。こちらの作業は (1) 対象銘柄の決算短信を探し、(2) セグメント別売上情報の記載個所を探し、(3) 該当箇所からセグメント名と各数値をコピー＆ペーストで埋めていく、といった流れになっており、一社当たり平均 2～3 分を要します。この業務は日々多くの会社の情報を取り扱う会社において、転記そのものの時間に加えチェックの負荷もあり、業務上大きな負担となっていました。 課題解決に向けた検討 皆様も既にご存じの通り、現状の LLM は課題に対する万能の解決方法ではありません。例えば、不適切な入出力を防止するためのガードレールの構築と維持、企業独自の知識を LLM で利用するためのデータソースの管理、適切なアクセス権限の制御など、プロトタイピングを超えて本番運用を見据えた場合、LLM の運用にあたっては多くのハードルがあります。 そのためナウキャストでは、課題解決の検討に LLM の利用を含める場合、LLM での解決が適しているかの見極めを実施しています。特に、LLM を万能の AI アシスタントとしてとらえるのではなく、自然言語の処理技術としてシステムに組み込むことが可能か、という視点で捉えなおし、以下の観点を一例として LLM に適したタスクかどうかの判断を行っています。 LLM アプリケーション開発に向いたタスク：観点例 (1) 正解が簡単に判断できる、もしくは正解がないタスク 人間が実施する場合でも難しい複雑なタスクは LLM にも難しいため、答えの決まりやすいタスクを対象とする (2) 深いドメイン知識が必要ない、もしくはそのドメインに関する知識が世に広く出回っているタスク RAG にも限界があるため、できるだけドメイン知識に依存しないか、一般的なドメイン知識の業務を対象とする (3) 終了に必要なコンテキストが少なく、かつコンテキストの言語化が容易なタスク 複数のコンテキストが絡み合う内容は LLM では精度を出すことが難しいため、シンプルなものを対象とする (4) ユーザーがプロンプトを入力しないタスク 業務ユーザーがプロンプトを扱うにはユーザー側・システム側双方の負荷が高いため、ユーザー入力をプロンプトに反映する必要のない業務を対象とする 今回のセグメント別売上情報抽出業務は上記 (1) ～ (4) の観点を満たすタスクとなっており、また、処理の実装により人間の作業コストを大きくカットできると見込まれることから LLM での適用に適したタスクと判断し、検証を実施することにしました。 解決策 （図2.セグメント情報抽出のフロー） 今回のフローでは、決算短信データ (PDF) から財務データ抽出を行う業務特性に照らし、大量の書類を扱う事に長けた Anthropic Claude 2 (100K) (*1) が利用可能な Amazon Bedrock を採用しました。また、LLM による情報抽出の精度が 100% になることはないため、オペレーターの目検チェックを運用に組み込んだ Human in the loop (*2) のシステムとする事で、ハルシネーションのリスクを最小化するようフローを設計しています。 (*1) 検証時点の最新モデル (*2) 人がループ（システム処理フロー）の中に参加する事で、プロセスの効率性と透明性を高める取り組み LLM データ抽出システム：実装イメージ ここまでの課題・解決策をもとに実装した LLM データ抽出システムのアーキテクチャーおよびポイントは以下の通りです。 アーキテクチャー （図3. LLM 抽出システム：アーキテクチャー） ポイント 基盤モデル Amazon Bedrock では複数の基盤モデルが提供されています。今回はデータ抽出の対象とする決算短信を分割せずに入力可能であることを重視し、Anthropic Claude 2 (100K) モデルを採用しました。 プラットフォーム LLM の業務導入では、LLM 単体の開発ではなく、業務システムとの統合を前提とした開発を行うことが重要になります。アプリケーションや業務システム統合を念頭に置いた場合、LLM に留まらず多くのサービスを提供する AWS を選択することで柔軟に業務システムを開発することが可能になると判断しています。 アプリケーション Amazon Bedrock と 他の AWS サービスを組み合わせてアプリケーションを実装しています。 Amazon ECS 上に Streamlit (*3) を用いたデータ整形のアプリケーションを実装 認証は Amazon Cognito を採用し、セキュリティと利便性を実現 決算短信の PDF データは ECS で定期的に取得し、データを S3 に保存 (*3) Python で簡易的な WEB アプリケーションを実装できるライブラリ セグメント別売上情報抽出業務：解決後業務イメージ （図4. セグメント別売上情報抽出 – LLM データ抽出システム） LLM データ抽出システム実装により、担当者の業務が改善されました。担当者が銘柄コードを入力するだけで、該当銘柄の適時開示資料におけるセグメント別売上情報のページ、およびそこから自動的に抽出されたセグメント別売上情報のテーブルがされるようになっています。担当者は表示された内容のチェックを行うだけでよく、情報を探索する手間や、転記ミスのリスクも低減されました。 ビジネス効果 LLM データ抽出システムの実装により、以下の成果を得ることができました。 (1) LLM による抽出精度 90% を達成 日本の上場株式約 100 銘柄を対象に検証した結果として、90% 以上の精度で正しく財務データの抽出に成功しました。また、今回失敗したケースについてもプロンプトのカスタマイズ等の対応によりさらなる改善が見込める状況です。 (2) 情報抽出のオペレーション工数を 50% 削減 従来資産運用会社のアナリストが Excel 等を用いてマニュアルで実施していた財務情報の検索と抽出が自動化された事により、情報抽出のオペレーションコストを 50% 削減しました。さらに副次的効果として、転記の際のコピー＆ペーストが削減され、ヒューマンエラーの削減にもつながっています。 (3) Streamlit で短期間のアプリケーション開発を実現 今回のシステムにおいては、AWS のマネージドサービスを活用するとともに、アプリケーション側の実装においてはローコード開発ツールである Streamlit を活用しました。それにより LLM アプリケーション開発担当 1 名のリソースにもかかわらず、短期間でのアプリケーション開発と効果検証を実現することができました。 今後の展望 今回の検証を踏まえ、今後さらに以下の展開を図っていくことを予定しています。 (1) 決算資料など対象業務の拡大 今回構築した仕組みをもとに、決算短信に加え、決算説明資料・有価証券報告書・大量保有報告書など様々な企業の開示資料に対象を拡大していきます。 (2) 全上場銘柄を対象にオペレーションを拡大 現状対象としている 100 社だけでなく、全銘柄を対象にすることでデータ単体でのマネタイズを目指します。また、オペレーション拡大に伴うデータ品質確保も図っていきます。 (3) オペレーションを他業種のデータにも拡大 適時開示資料をベースとしたシステム構築のノウハウを他業種にも展開し、データを拡充します。また、今回の調査オペレーション自体をカスタマイズし、クライアントへの提供を目指します。 まとめ 今回の検証により、Amazon Bedrock と AWS サービスを活用することで LLM アプリケーションを短期間で構築できることが実証できました。それにより、ビジネス適用時の業務検証 PDCA サイクルが高速化され、今後さらに幅広い領域へのビジネス展開ビジネスへの適用・拡張容易性向上が可能であるといった知見が得られました。 ナウキャストでは、データエンジニアリングと生成 AI 活用に強みを持っています。生成 AI に限らず、データ基盤構築やデータ利活用推進もあわせてご相談頂くことが可能です。データ活用や生成 AI 活用でお困りごとがございましたら、「株式会社ナウキャスト」で検索頂き、「デモリクエスト」よりお問い合わせを頂けますと幸いです。 == カスタマープロフィール：株式会社ナウキャスト ( Nowcast Inc. ) 株式会社ナウキャストは.、東京大学経済学研究科渡辺努研究室における「東大日次物価指数（現：日経CPINow）」プロジェクトを前身として設立された、オルタナティブデータのリーディングカンパニーです。

みなさんお久しぶりです！ 猫が大好きな Solutions Architect の服部です。昨年の AWS Summit Tokyo でご好評いただいた Chaos Kitty がパワーアップして AWS Summit Japan に帰ってきました！ この記事では、2024 年の AWS Summit Japan の Developer Zone 内で展示される、「 Chaos Kitty で楽しくインシデント対応ゲームをしよう！ 」についてご紹介します。本展示は、システムを構築する上でも重要なレジリエンスやセキュリティをゲームを通じて楽しく学ぶことができる体験型コンテンツです。システムのレジリエンスやセキュリティを強化したい全ての方に本記事を読んでいただき、実際に AWS Summit Japan の会場まで足を運んで体験いただけると幸いです。開催期間は 2024 年 6 月 20 日 (木) と 21 日 (金) の 2 日間で、会場は幕張メッセになります。まだ登録してない方は こちらのページ からご登録ください。Chaos Kitty は、AWS Village の Developer Zone の中にあります。詳細は こちら 。 Chaos Kitty とは？ Chaos Kitty は、AWS のアーキテクチャを物理的に表現し、障害対応の体験学習ができるソリューションです。以下の 3 つの主要機能を備えています。詳細は、 昨年の記事 も合わせてご確認ください！ 1. IoT 電球によるリアルタイムの状態可視化 物理的なブロックと電球で表現された Web 3 層 アプリケーションのアーキテクチャにおいて、各コンポーネント (EC2, RDS, S3 など ) の状態が IoT 電球の色で示されます。電球は、正常な場合には緑、何か異常がある場合には赤で点灯する設定になっており、設定に異常が検出された場合には、電球が緑から赤に変わる仕組みとなっています。これにより AWS 上のアプリケーションの状況をリアルタイムで監視でき、異常をすぐに検知することができます。 2. 障害挿入機能による対応訓練 付属のボタンを押すと AWS での設定に意図的に設定ミスを注入し、IoT 電球の色が赤に変わります。ユーザーは AWS コンソールを使ってこの設定ミスを特定・修復し、電球を緑に戻すゲームを行います。修復が完了すれば、修復にかかった時間が表示され、手動での対応の難しさを体感できます。 3. 自動修復機能による対応の効率化 注入された設定変更に対して、自動修復するスクリプトを実行する物理的なボタンが用意されています。マネジメントコンソールを使用した手動修復と比べた自動化の優位性と、クリティカルなワークロードでの損失抑制の重要性を実感できます。 図 1 : Chaos Kitty 外観 図 2 : Web 3 層アプリケーション画面 パワーアップした Chaos Kitty とは？ 2023年までの Chaos Kitty のシナリオはセキュリティが中心でしたが、今年の Chaos Kitty はレジリエンスのシナリオを新たに追加し、実際にアプリケーションの障害と復旧をゲーム内で体感いただける内容となっております。レジリエンスを実現するためには、一部のコンポーネントに障害が発生しても稼働し続け、かつ自動で復旧するアーキテクチャを取ることが重要です。また、障害が発生した際に、素早く検知して復旧させるための調査の仕組みも必要となります。 Chaos Kitty ではゲームとしてわかりやすくするために、アプリケーションの問題箇所を電球で可視化していますが、実際のシステムではそう簡単にはいきません。実システムでは、ユーザ影響がある障害が発生しているかどうか、すぐに確認・分析できるようにするためのダッシュボードによる可視化が有効です。今回の Chaos Kitty では、レジリエンスのシナリオを通してシステムの状態を把握する必要性を実感いただくために、リソース稼働状況を一目で確認できるよう Amazon CloudWatch を活用したダッシュボードを用意しています。Amazon CloudWatch Synthetics を使ってリクエストの状態やレスポンスタイムを測定し、アプリケーションの稼働状況を監視したり、システム内のどこに障害が発生しているか把握するために AWS X-Ray を利用してトレース情報を取得し、ダッシュボードに表示するようにしています。本ゲームを通じて、レジリエンスのあるシステムの開発にご興味を持っていただけると幸いです。 図 3 : ダッシュボード画面 終わりに Chaos Kitty は実際の障害を模擬する形でサービスの稼働状況を電球やブロックを使ってわかりやすく表現しております。日頃クラウドサービスに慣れ親しむ機会が少ない方でも、運用における障害対応を気軽に体験いただけます。AWS Summit Japan 2024 で、皆様にお会いできることを楽しみにお待ちしております！ 服部 一成 自動車および製造業界向けビジネスユニットのソリューションアーキテクト。IoTの技術コミュニティに所属。 第二種電気工事士。最近の趣味は車の配線いじりとアウトドアグッズのウィンドショッピング。 Choas Kitty は AWS Japan ソリューションアーキテクトの高野 翔史、堀 貴裕、津郷 光明、宋 子豪、河角 修、服部 一成が中心となって運営しております。

本記事は 2024年6月12日に公開された “ Use Amazon DynamoDB incremental exports to drive continuous data retention ” を翻訳したものです。 Amazon DynamoDB は、 Amazon Simple Storage Service (Amazon S3) への 増分エクスポート に対応しており、さまざまなユースケースでの、ダウンストリームのデータ保持や利用を実現しています。 このブログでは、初期にフルエクスポートを行った後に、継続的な増分エクスポートを実行していくことで、エクスポートされたテーブルデータを継続的に更新していく方法を説明します。このソリューションはDynamoDB Continuous Incremental Exports (DCIE 、 GitHub でオープンソースにて提供) と呼ばれ、データが最新の状態に保たれた DynamoDB データのエクスポートを実現します。 DCIE のユースケースの一つは、DynamoDB テーブルに対するオフライン分析です。テーブルサイズが大きくなると、繰り返しフルエクスポートを行うよりも、一度フルエクスポートした後に増分エクスポートを行う方がコスト効率が良くなります。この方法を使えば、例えば Apache Iceberg テーブルを最新の状態に保つ ことができます。 DCIE の別のユースケースは、1 つの DynamoDB テーブルから別の DynamoDB テーブルへの変更を反映することです。 まず、新しいテーブルをフルエクスポートに基づいてブートストラップします。その後、新しいテーブルが最新になるまで、一連の増分エクスポートを進めていきます。新しいテーブルは、同じ AWS アカウント内の別のテーブル、別の AWS アカウント内のテーブル、さらには別の AWS リージョン内にあるテーブルでも構いません。 DCIE は一連のエクスポートを作成するのみであり、このブログではこれらのエクスポートを Iceberg テーブルに取り込んだり、別の DynamoDB テーブルに読み込むことには触れません。 継続的なエクスポート この節では、ワークフローの動作方法について説明します。まず、Amazon S3 へのフルエクスポートを実行します。これにより、特定の時点でのテーブル内容をキャプチャすることができます。次の図は、最近の時点 ( t = 0 と呼ばれる) で行われたフルエクスポートを示しています。 その後、デフォルトでは 15 分ごとに定期的な増分エクスポートを実行します。増分エクスポートごとに、2 つの時間の間(つまり、全エクスポートの終了から 15 分後まで)に発生した変更をキャプチャします。増分エクスポートは、コーディング時に差分表示される diff に似ています。その後、新しいエクスポートは、定期的に実行されます。 時間範囲が正確に一致していないと、期間にギャップが生じてしまいます。フルエクスポートの終了時刻は最初の増分エクスポートの開始時刻と一致している必要があります。また、最初の増分エクスポートの終了時刻は次の増分エクスポートの開始時刻でなければなりません。このようにすることで、テーブル全体の内容が一連のエクスポート結果に確実に反映されます。 次の図に示すように、 t = 1 で開始した増分エクスポートは完了までにしばらく時間がかかり、 t = 2 の後に完了する可能性があります。これは問題ありません。2 つの エクスポートは同時に実行できます。DynamoDB のエクスポートにはメタデータが含まれているため、エクスポートが正常に完了したかどうかを判断できます。また、エクスポートメタデータにより、ダウンストリームのコンシューマーは正常なエクスポートのみを正しい時系列順に処理できます。 ソリューションの概要 DCIE は Amazon EventBridge Scheduler を使用してワークフローを定期実行するスケジューリングを行い、ワークフロー内の調整を AWS Step Functions で管理しています。Step Functions を使用することで、このような分散アプリケーションを簡単にデザイン、カスタマイズ、実行、可視化、管理、再試行、そして視覚的にデバッグできます。 ワークフローのデプロイには、5 つのパラメータが必要です。複数のDynamoDB テーブルに複数回デプロイを行えるようにするためのスタック名、ソースとなる DynamoDB テーブル名、テーブルとインフラストラクチャの簡単なマッピングを可能にするデプロイエイリアス、エクスポート成功時の通知を受け取るメールアドレス、エクスポート失敗時の通知を受け取るメールアドレスです。Step Functions ステートマシンは、 Parameter Store を使用して状態を維持します。これは AWS Systems Manager の機能の 1 つです。 DCIE を AWS Cloud Development Kit (AWS CDK) を使ってデプロイすることができ、カスタマイズに上記のパラメータを設定するだけで済みます。また、カスタム S3 バケット、S3 プレフィックス、増分エクスポートの時間間隔をデフォルトの 15 分よりも長くする、エクスポートが完了したかを確認する間隔をデフォルトの 10 秒より長くまたは短くするなどのオプション設定も行えます。 Step Functions のワークフローは、まず事前チェックを行い、指定されたテーブルが存在し、 ポイントインタイムリカバリー (PITR) が有効になっているかを確認します。PITR は、S3 エクスポートに必須となります。 このワークフローには 2 つの主要なツリーがあります。最初にフルエクスポートを実行するツリーと、後続の増分エクスポートを実行するツリーです。それぞれのツリーは作業を開始し、定期的に完了やエラーを確認します。エラー時には状態の更新やメール送信を行います。特定のニーズがある場合は、ワークフローを自分で変更できます。次の図は、ワークフローの簡略化された論理的な表現です。 DCIE のデプロイの詳細については、GitHub リポジトリの README をご覧ください。 コストの管理 DCIE をデプロイするコストには以下が含まれます: PITR を有効にするための継続的な料金 (テーブルのサイズに基づきます) 初回 フルエクスポート の費用 (テーブルのサイズに基づきます) 各 増分エクスポート の費用 (処理するデータ量に応じ、また時間ウィンドウ内の変更数に比例します) Amazon S3 を使うために発生するコスト (オブジェクト書き込み、データストレージのコストは時間と共に増加します) AWS Lambda 、 Amazon Simple Notification Service (Amazon SNS)、 Amazon CloudWatch Logs の利用コスト まとめ DynamoDB の新しい Amazon S3 への増分エクスポート機能により、DynamoDB テーブル内のデータをダウンストリームのデータ コンシューマへ簡単にエクスポートできます。 このブログでは、最初にフルエクスポートを行い、その後、継続的な増分エクスポートのシリーズを生成することで、S3 バケットを継続的に更新するためのオープンソースソリューションを紹介しました。 これを利用することで、ダウンストリームの Iceberg テーブルにデータを供給したり、別の DynamoDB テーブルにデータを供給したり、または、リモートの S3 バケットにコピーして、リモートリージョンでテーブルを再作成するためのディザスターリカバリープランの一部として使用したりできます。 DynamoDB から S3 へのエクスポートの詳細については、 ドキュメントガイド を参照してください。 本ブログはソリューションアーキテクトの堤が翻訳しました。原文は こちら 。

この記事は Diving into Red Hat OpenShift Service on AWS (ROSA) with Hosted Control Planes (HCP) (記事公開日: 2024 年 1 月 22 日) を翻訳したものです。 はじめに 2015年に AWS で初めてリリースされて以来、Red Hat OpenShift は似たようなアーキテクチャを持ってきました。OpenShift 3 、 OpenShift 4 、自己管理の OpenShift Container Platform (OCP) か、マネージドサービスの ROSA  かを問わず、お客様はこれまで自身の AWS アカウント内に存在するコントロールプレーンについて、関連するコストを相殺して投資対効果 (ROI) を最大化する方法を検討してきました。これに応えるべく Red Hat は OpenShift 向けに Hosted Control Plane (HCP) をリリースしました。 この記事では、OpenShift における Hosted Control Plane の利点に詳しく掘り下げます。最近の変更点に注目し、従来のアーキテクチャと比較します。そして、これらの変更がユーザーに与える利点を明らかにします。 翻訳の時点(2024年6月13日)で、アジアパシフィック (東京) とアジアパシフィック (大阪)を含む多くのリージョンで Hosted Control Plane を備えた ROSA をご利用いただけます。 ROSA classic のアーキテクチャ OpenShift on AWS は、AWS とRed Hat OpenShift の高可用性モデルを組み合わせてきました。OpenShift コントロールプレーンと OpenShift API を提供する 3 つのコントロールプレーンノード、つまり Amazon Elastic Cloud Compute (Amazon EC2) インスタンスと、OpenShift ルーティングレイヤーとその他のクラスター関連機能を提供する 3 つのインフラストラクチャノードと、コンピューティングレイヤーであるワーカーノードがあります。これら全てがお客様のアカウントに存在し、複数の アベイラビリティーゾーン (AZ)  に配置されます。ROSA はマネージドサービスであるため、Red Hat Site Reliability Engineering (SRE) チームがお客様のアカウントに存在する OpenShift 環境を AWS PrivateLink 経由でアクセスしてお客様の代わりに管理・メンテナンスします。 従来の OpenShift on AWS アーキテクチャ ROSA を検討するお客様から尋ねられることの多い質問に、「他の AWS サービスの場合はコンピューティングノードのみですが、なぜ ROSA の場合はコントロールプレーンが私のアカウントにあるのですか?」「コントロールプレーンのリソースコストを削減するためのインセンティブプログラムとコスト管理オプションのベストプラクティスは何ですか?」「AZ 間のデータ転送コストの原因は何ですか?」があります。 ROSA の Hosted Control Plane (HCP) Red Hat が発表した OpenShift の hosted control plane により、お客様は多くの利点を得ることができます。 Hosted Control Plane ではコントロールプレーンノードが他の AWS サービスと同じようにお客様のアカウントから Red Hat のサービスチームアカウントへと移動されます。これにより、 Amazon EC2 や Amazon Elastic Block Store (Amazon EBS)  といった、お客様のアカウントにおける AWS サービスのコストが削減されます。また、OpenShift の Kubernetes レイヤーにおける etcd データベースがコントロールプレーンノードに存在することから、高可用性のための etcd レプリケーションに関する AZ 間のデータ転送コストもお客様のアカウントから取り除かれます。 Red Hat Site Reliability Engineering (SRE) チームがサービスチームアカウントから OpenShift クラスターを直接管理・メンテナンスします。お客様のアカウントにある AWS PrivateLink エンドポイントは、ワーカーノードがサービスチームアカウントのコントロールプレーンに接続するために用いられます。 3つの OpenShift インフラストラクチャノードもまた、お客様のアカウントから除去され、そのサービスはコントロールプレーンノードかワーカーノードに移行されます。ただし、OpenShift ルーティングレイヤーはワーカーノードに移動されることに留意してください。 このアプローチにより、コントロールプレーンノードとインフラストラクチャノード、および etcd 関連の AZ 間データ転送に関する Amazon EC2 と Amazon EBS の AWS サービスコストが削減されます。Hosted Control Plane には、コントロールプレーンノードとワーカーノードが並列的にプロビジョニングされるため、プロビジョニング時間が短縮される利点もあります。 HCP を備えた ROSA クラスターのデプロイ 既存の ROSA クラスターを Hosted Control Plane アーキテクチャへアップグレードまたは変換することはできません。HCP を備えた ROSA を活用するには新しいクラスターを作成する必要があります。 前提条件 デフォルト設定を使い、 AWS Identity and Access Management (AWS IAM)  リソースを自動作成すれば、HCP を備えた ROSA クラスターのデプロイは容易になります。ROSA CLI の rosa を使ってクラスターのデプロイを開始できます。HCP を備えた ROSA クラスターを rosa で作成する前に、アカウント全体のロールとポリシー、operator ロールを事前に準備しておく必要があります。 HCP を備えた ROSA クラスターを作成するために必要な重要なコンポーネントについて説明します。HCP を備えた ROSA クラスターを作成するには、次の項目が必要です。 設定済の Virtual Private Cloud (VPC) アカウント全体のロール OpenID Connect (OIDC) の設定 Operator ロール Virtual Private Cloud (VPC) Hosted Control Plane は既存の Virtual Private Cloud (VPC) にデプロイする必要があります。ほとんどのお客様は、既存の VPC を何らかの Infrastructure as Code (IaC) の形式で管理しています。VPC は手動で作成したり、 Terraform テンプレートを使って作成したりできます。Terraform はテンプレートを使ってさまざまなリソースを作成するためのツールです。VPC を Terraform テンプレートを使って構築する詳細なドキュメントは こちら です。 アカウント全体の STS ロールとポリシー セキュリティに関して、ROSA の異なるコンポーネントにアタッチされる AWS IAM ポリシーに変更があります。最小特権の原則に沿って、より限定的な AWS IAM ポリシーの使用が進められています。アカウント全体のロールの作成を再実行する必要があり、各 OpenShift operator ごとにより細かいロールが新たに必要になるといった変更があります。 HCP を備えた ROSA クラスターでは、そのデプロイメント向けに特別に設計された重要な AWS IAM ロールを事前に準備する必要があります。クラスターの operator はこれら operator ロールを使ってクラスター操作を行うための一時的な権限を取得します。 HCP を備えた ROSA クラスターは AWS Security Token Service (AWS STS)  による認証のみをサポートします。AWS STS は、ユーザーに対する一時的で権限の限られた認証情報を要求できるサービスです。 AWS PrivateLink ROSA classic アーキテクチャでは、 AWS PrivateLink  によって Red Hat SRE チームがお客様に代わってOpenShift クラスターに接続して環境を管理できるようになっていました。HCP アーキテクチャでは Red Hat SRE チームがサービスアカウントからお客様の環境を管理し、AWS PrivateLink はワーカーノードがコントロールプレーンに接続するために使われます。 プロビジョニング 以下に示すコマンドを使ってアカウントロール、operator ロール、OpenID Connect の設定を作成し、クラスターをデプロイします。詳細については、ドキュメントの「 デフォルトのオプションを使用した ROSA with HCP クラスターの作成 」もしくは「 Getting started with ROSA with HCP using the ROSA CLI in auto mode 」を参照してください。 アカウント全体のロール: 次のコマンドを使って必要な AWS IAM アカウントロールとポリシーを作成します。 $ rosa create account-roles --force-policy-creation OpenID Connect の設定: 次のコマンドを使って OIDC の設定と AWS リソースを作成します。 $ rosa create oidc-config --mode=auto --yes operator ロール: 次のコマンドを使って operator ロールを作成します。 $ rosa create operator-roles --hosted-cp --prefix <prefix-name> --oidc-config-id <oidc-config-id> クラスターのデプロイ: 次のコマンドのいずれかを使って HCP を備えた ROSA クラスターをデプロイします。 $ rosa create cluster --private --cluster-name=<cluster_name> --sts --mode=auto --hosted-cp --subnet-ids=<private-subnet-id> $ export REGION=<region_name> $ export ROSA_VERSION=<rosa_version> $ rosa create cluster --cluster-name <cluster_name> --multi-az --hosted-cp --mode=auto --sts --region $REGION --version $ROSA_VERSION --enable-autoscaling --min-replicas <minimum_replicas> --max-replicas <maximum_replicas> --compute-machine-type <instance_type> --host-prefix <host_prefix> --private --subnet-ids <subnet_id_1>,<subnet_id_2>,<subnet_id_3> --operator-roles-prefix <prefix-name> --oidc-config-id <oidc-config-id> 例: $ export REGION=us-west-2 $ export ROSA_VERSION=4.14.27 $ rosa create cluster --cluster-name my-cluster --multi-az --hosted-cp --mode=auto --sts --region $REGION --version $ROSA_VERSION --enable-autoscaling --min-replicas 3 --max-replicas 3 --compute-machine-type m5.2xlarge --host-prefix 23 --private --subnet-ids subnet-0aed73cfa77880167,subnet-07b78438a58648748,subnet-051e2679837a4cc42 --operator-roles-prefix rosa-hcp --oidc-config-id 2bp1mhs3fcbhq1vi40u0mh9vh17f3fm8 クリーンアップ ROSA クラスターと AWS STS リソースを削除する手順については、ドキュメントの「 ROSA with HCP クラスターの削除 」もしくは「 Delete a cluster and AWS STS resources 」を参照してください。 ROSA classic をご利用のお客様のための移行パス 現時点では、ROSA HCP クラスターをプロビジョニングし、その後アプリケーションワークロードを移行する必要があります。 ROSA classic から ROSA HCP へのインプレースアップグレードはできません。移行を考えているお客様は、 Red Hat Migration Toolkit for Containers の活用を検討してください。これはアップストリームの Konveyor  プロジェクトに基づいています。 まとめ この記事では、OpenShift における Hosted Control Plane の利点について解説しました。変更点に注目し、従来のアーキテクチャと比較しました。Hosted Control Plane (HCP) は OpenShift on AWS のデプロイと管理に新しい時代を切り開きます。この革新的な変更はコスト削減、運用の高可用性とセキュリティ強化、クラスターのプロビジョニングに要する時間の改善をもたらします。お客様のビジネスにおいて、HCP を備えた ROSA クラスターの新しい可能性と利点を検討することをお勧めします。 翻訳の時点(2024年6月13日)で、アジアパシフィック (東京) とアジアパシフィック (大阪)を含む 多くのリージョン で HCP を備えた ROSA をご利用いただけます。 追加情報 HCP を備えた ROSA クラスターのインストールについては、「 ROSA with HCP クラスターのインストール 」を参照してください。 ROSA のクイックスタートガイドについては「 Red Hat OpenShift Service on AWS クイックスタートガイド 」を参照してください。 アーキテクチャとネットワークの詳細については、「 ROSA: Architecture and Networking 」を参照してください。 Migration toolkit for containers の詳細については、「 Ask an OpenShift Admin (E68) | Migration toolkit for containers 」を参照してください。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。