今日の データ主導の世界 では、企業は データレイク や ウェアハウス にまたがる 膨大な量の情報 を処理および分析する効率的な方法を常に模索しています。 Amazon SageMaker Lakehouse を使用すると、 Amazon Simple Storage Service ( Amazon S3 ) 上のデータレイクと Amazon Redshift データウェアハウスにまたがるすべてのデータを統合することができ、強力なアナリティクスと AI / ML アプリケーションを一元化されたデータで構築できます。SageMaker Lakehouse は、データを動かさずに Apache Iceberg と互換性のあるすべてのツールとエンジンでクエリを実行できる柔軟性を提供します。これは、SageMaker Lakehouse の機能を使用したい オープンソースの Apache Spark ユーザーにとって、エキサイティングな可能性を開きます。さらに、 SageMaker Lakehouse では、すべてのアナリティクスおよび ML ツールやエンジンに適用されるきめ細かい権限を定義することで、データを保護することができます。 この投稿では、オープンソースの Apache Spark のパワーを利用し、 AWS Glue Iceberg REST Catalog で動作するようサードパーティのエンジンを設定する方法を探ります。 この投稿には、 AWS Lake Formation が一時的なクレデンシャルを提供する機能を使用してメタデータと実データへのアクセスを管理し、 Amazon S3 テーブルに対してデータを読み取り/書き込みする操作を実行する方法の詳細が含まれます。 ソリューション概要 この投稿では、お客様が Data Catalog を使用して組織内の構造化および半構造化データセットのテクニカルメタデータを一元管理し、データチームが Apache Spark を使用してデータ処理を行えるようにしたいと考えています。 お客様は、 AWS Glue データベースを作成します。そして、Lake Formation の権限コントロールを使用してAmazon S3 上の Iceberg データを読み書きするために、Iceberg Rest API を使用して Glue Data Catalog と対話できるよう Apache Spark を設定します。 まず、 Apache Spark を使用して ETL ( 抽出・変換・ロード ) スクリプトを実行することから始めます。 Amazon S3 上に Iceberg テーブルを作成し、 Glue Iceberg REST Catalog を使用してそのテーブルにアクセスします。 ETL スクリプトは Iceberg テーブルにデータを追加し、 その後 Spark SQL を使用してデータを読み取ります。 この投稿では、他のデータチームが Amazon Athena を使用して、このデータをクエリする方法についても紹介します。 前提条件 Data Catalog を持つアカウントの、 Lake Formation データレイク管理者である AWS Identity and Access Management (IAM) ロール にアクセスできる必要があります。 手順については、 データレイク管理者を作成する を参照してください。 Python バージョン 3.7 以降がインストールされていることを確認します。 pip3 のバージョンが 22.2.2 以上であることを確認してください。 最新の AWS Command Line Interface ( AWS CLI ) をインストールまたは更新します。 手順については、 最新バージョンの AWS CLI のインストールまたはアップデート を参照してください。 AWS CLI を使用して aws configure を実行し、 AWS アカウントを指定します。 お客様の Iceberg テーブルを格納する S3 バケットを作成 します。 今回は、 us-east-2 の AWS リージョンを使用し、バケット名を ossblog-customer-datalake とします。 AWS Glue Iceberg REST Catalog エンドポイントを使用したデータアクセスに使用する、 OSS Spark 用の IAM ロールを作成します。作成した IAM ロールが Data engineer permissions で定義されている AWS Glue と Lake Formation のポリシーを持っていることを確認してください。 この投稿では、 spark_role という名前の IAM ロールを使用します。 Lake Formation のサードパーティからのアクセス権限を有効にする このセクションでは、 Lake Formation に S3 バケットを登録 します。 このステップにより、Lake Formation は Amazon S3 に保存されたメタデータとデータの一元的な権限管理システムとして機能し、データレイク環境においてより効率的でセキュアなデータガバナンスを可能にします。 ロケーションの登録に使用するロールの要件 に従って、ユーザー定義の IAM ロールを作成します。 この投稿では、IAMロール : LFRegisterRole を使用します。 以下のコマンドを実行し、 IAM ロール LFRegisterRole を使用して、S3バケット ossblog-customer-datalake を登録します。 aws lakeformation register-resource \ --resource-arn ' < S3 bucket ARN for amzn-s3-demo-bucket> ' \ --role-arn ' < IAM Role ARN for LFRegisterRole > ' \ --region <aws_region> または、Lake Formation の AWS マネジメントコンソールを使用することもできます。 Lake Formation コンソールに移動し、ナビゲーションペインから Administration を選択し、次に Data lake locations を選択して、以下の値を入力します。 Amazon S3 path では、 s3://ossblog-customer-datalake を選択します。 IAM role では、 LFRegisterRole を選択します。 Permission mode では、 Lake Formation を選択します。 Register location を選択します。 Lake Formationで、外部エンジンがデータにアクセスできるように full table access を有効にします。 管理者ユーザーとしてサインインし、ナビゲーション ペインで Administration を選択します。 Application integration settings を選択し、 Allow external engines to access data in Amazon S3 locations with full table access を選択します。 Save を選択します。 OSS Spark ロールのリソースアクセスを設定 Lake Formation コンソールに移動し、ナビゲーションペインで Databases を選択して、デフォルトカタログに ossblogdb という AWS Glue データベース を作成します。 データベースを選択し、 Edit を選択して Use only IAM access control for new tables in this database のチェックボックスをオフにします。 OSS Spark ロールにリソース権限を付与 OSS Spark が ossblogdb データベースの上でデータセットを作成し、データを投入できるようにするには、前提条件のステップ 4 で作成した Apache Spark インスタンスの IAM ロール（ spark_role ） を使用します。 Apache Spark はこのロールを使用して、Iceberg テーブルを作成し、レコードを追加し、読み込みます。 この機能を有効にするには、 spark_role にフルテーブルアクセスを付与し、テーブルデータを保存できる S3 バケットにデータロケーション権限を付与します。 spark_role にテーブル作成権限を付与 データレイク管理者としてサインインし、AWS CLIで以下のコマンドを実行します。 aws lakeformation grant-permissions \ --principal '{"DataLakePrincipalIdentifier":"arn:aws:iam:: <aws_account_id> :role/ <iam_role_name> "}' \ --permissions '["CREATE_TABLE","DESCRIBE"]'\ --resource '{"Database":{"CatalogId":" <aws_account_id> ","Name":"ossblogdb"}}' \ --region <aws_region> またはコンソール上で以下を実施します Lake Formation コンソールのナビゲーションペインで、 Data permissions を選択し、 Grant を選択します。 Principals セクション の IAM users and roles で、 spark_role を選択します。 LF-Tags or catalog resources セクションで、 Named Data Catalog resources を選択します。 Catalogs では <accountid> を選択します。 Databases では ossblogdb を選択します。 Database permissions で、 DESCRIBE と CREATE TABLE を選択します。 Grant を選択します。 spark_role にデータロケーション許可を付与 データレイク管理者としてサインインし、AWS CLI を使用して以下のコマンドを実行します。 aws lakeformation grant-permissions --principal '{"DataLakePrincipalIdentifier":" <Principal> "}' --permissions DATA_LOCATION_ACCESS --resource '{"DataLocation":{"CatalogId":" <Catalog ID> ","ResourceArn":" <S3 bucket ARN> "}}' --region <aws_region> またはコンソール上で以下を実施します。 Lake Formation コンソールのナビゲーションペインで、 Data Locations を選択し、 Grant を選択します。 IAM users and roles では、 spark_role を選択します。 Storage locations では、 バケット名 を選択します。 Grant を選択します。 AWS Glue Iceberg REST catalog エンドポイントを使用する Spark スクリプトのセットアップ 以下の内容で、 oss_spark_customer_etl.py という名前のファイルをあなたの環境に作成します。 import sys import os import time from pyspark.sql import SparkSession #Replace <aws_region> with AWS region name. #Replace <aws_account_id> with AWS account ID. spark = SparkSession.builder.appName('osspark') \ .config('spark.jars.packages', 'org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.4.1,software.amazon.awssdk:bundle:2.20.160,software.amazon.awssdk:url-connection-client:2.20.160') \ .config('spark.sql.extensions', 'org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions') \ .config('spark.sql.defaultCatalog', 'spark_catalog') \ .config('spark.sql.catalog.spark_catalog', 'org.apache.iceberg.spark.SparkCatalog') \ .config('spark.sql.catalog.spark_catalog.type', 'rest') \ .config('spark.sql.catalog.spark_catalog.uri','https://glue. <aws_region> .amazonaws.com/iceberg') \ .config('spark.sql.catalog.spark_catalog.warehouse',' <aws_account_id> ') \ .config('spark.sql.catalog.spark_catalog.rest.sigv4-enabled','true') \ .config('spark.sql.catalog.spark_catalog.rest.signing-name','glue') \ .config('spark.sql.catalog.spark_catalog.rest.signing-region', <aws_region> ) \ .config('spark.sql.catalog.spark_catalog.io-impl','org.apache.iceberg.aws.s3.S3FileIO') \ .config('spark.hadoop.fs.s3a.aws.credentials.provider','org.apache.hadoop.fs.s3a.SimpleAWSCredentialProvider') \ .config('spark.sql.catalog.spark_catalog.rest-metrics-reporting-enabled','false') \ .getOrCreate() spark.sql("use ossblogdb").show() spark.sql("""CREATE TABLE ossblogdb.customer (name string) USING iceberg location 's3://<3_bucket_name>/customer'""") time.sleep(120) spark.sql("insert into ossblogdb.customer values('Alice') ").show() spark.sql("select * from ossblogdb.customer").show() Pyspark をローカルで起動し、 Amazon S3 上の Iceberg テーブルへの読み書き を検証する pip install pyspark を実行します。 スクリプトをローカルに保存し、環境変数（ AWS_ACCESS_KEY_ID , AWS_SECRET_ACCESS_KEY , AWS_SESSION_TOKEN ）に spark_role の一時的な認証情報を設定します。 python /path/to/oss_spark_customer_etl.py を実行します。 Athena を使用して Iceberg テーブルのデータを表示することもできます。 他のデータチームがコンテンツを閲覧できるようにするには、Lake Formation コンソールを使用してデータチームの IAM ロールに読み取りアクセス権を付与します。 Lake Formation コンソールのナビゲーションペインで、 Data permissions を選択し、 Grant を選択します。 Principals セクションの IAM users and roles で、 <iam_role> を選択します。 LF-Tags or catalog resources セクションで、 Named Data Catalog resources を選択します。 Catalogs では <accountid> を選択します。 Databases では ossblogdb を選択します。 Tables では customer を選択します。 DESCRIBE と SELECT を テーブル権限 に選択します。 Grant を選択します。 IAM ロールでサインインし、以下のコマンドを実行します。 SELECT * FROM "ossblogdb"."customer" limit 10; クリーンアップ リソースをクリーンアップするには、以下の手順を実行します。 Data Catalog で作成したリソース（データベース/テーブル）を削除します。 S3バケットを 空にして 、 削除します 。 結論 この投稿では、Amazon S3 の Iceberg テーブルにアクセスするための Apache Spark と AWS Glue Iceberg Rest Catalog のシームレスな統合について説明し、Iceberg REST API を使用して読み取りと書き込みの操作を効果的に実行する方法を示しました。 このソリューションの素晴らしいところは、その柔軟性にあります。データセンターのベアメタルサーバーで Spark を実行している場合でも、 Kubernetes クラスタで実行している場合でも、その他の環境であっても、このアーキテクチャはニーズに合わせて適応させることができます。 著者について Raj Ramasubbu は、Amazon Web Servicesのビッグデータおよびアナリティクス、AI / MLに特化したシニアアナリティクススペシャリストソリューションアーキテクトです。 AWS 上で拡張性、パフォーマンス、安全性の高いクラウドベースのソリューションを設計、構築するお客様を支援しています。 AWS 入社以前 20 年以上にわたり、データエンジニアリング、ビッグデータ分析、ビジネスインテリジェンス、データサイエンスソリューションの構築における技術的専門知識とリーダーシップを発揮してきました。 彼は、ヘルスケア、医療機器、ライフサイエンス、小売、資産管理、自動車保険、住宅用不動産投資信託、農業、タイトル保険、サプライチェーン、文書管理、不動産など、さまざまな業種のお客様を支援しました。 Srividya Parthasarathy は、 AWS Lake Formation チームのシニアビッグデータアーキテクトです。 プロダクトチームやお客様と協力して、分析データプラットフォーム向けの堅牢な機能とソリューションを構築しています。彼女は、データメッシュソリューションを構築し、コミュニティと共有することを楽しんでいます。 Pratik Das は、 AWS Lake Formation のシニアプロダクトマネージャーです。 データに関するあらゆることに情熱を持っており、お客様の要件を理解し、楽しいエクスペリエンスを構築するためにお客様と協力しています。 彼は、データドリブンソリューションと機械学習システムの構築経験があります。 翻訳は Solutions Architect 圓山が担当しました。原文は こちら です。

この記事は Amazon EKS now supports Amazon Application Recovery Controller (記事公開日: 2024 年 11 月 8 日) を翻訳したものです。 はじめに Amazon Elastic Kubernetes Service ( Amazon EKS ) が Amazon Application Recovery Controller ( ARC ) のサポートを開始しました。ARC は AWS リージョン またはアベイラビリティゾーン (AZ) の障害に対する準備と復旧を可能にする AWS サービスです。 ARC には、ゾーンシフトとゾーンオートシフトを含む マルチ AZ リカバリ と、ルーティングコントロールと準備状況チェックを含む マルチリージョンリカバリ の 2 つの機能があります。今回のリリースにより、以前は Application Load Balancer (ALB) と Network Load Balancer (NLB) でのみ利用可能だったゾーンシフトとゾーンオートシフトが Amazon EKS をサポートしました。 ARC のゾーンシフトとゾーンオートシフトは、障害のある AZ から他の正常な AZ に ingress トラフィックをシフトすることで、サポートされている AWS リソースのマルチ AZ リカバリを実現します。シフトが終了すると、ARC は ingress トラフィックを再び受信できるように以前に影響を受けた AZ を戻します。 Amazon EKS コンソール、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS CloudFormation 、または eksctl を使用して、EKS クラスターのゾーンシフトを有効にできます。有効にすると、ARC コンソール、AWS CLI、またはゾーンシフトとゾーンオートシフト API を使用して、EKS クラスターのゾーンシフトを開始したり、ゾーンオートシフトを有効にしたりできます。 EKS クラスターでゾーンシフトをトリガーするには、まず AZ を選択し、次に EKS クラスター (バージョン 1.28 以降) を選択し、ゾーンシフトを有効にする有効期限を指定します。すると、ARC はゾーンシフトを開始し、選択した AZ からトラフィックを切り離します。ARC は、有効期限が切れるか、ユーザーがキャンセルした場合にゾーンシフトを終了します。ゾーンシフトが終了すると、トラフィックは EKS クラスターに接続されているすべての正常な AZ に戻ります。 EKS クラスターのゾーンオートシフトを有効にすると、AZ が異常であることを ARC が検出したときに、AWS がユーザーに代わってトラフィックを切り離すことを許可することになります。ARC は内部テレメトリを使用して、AWS ネットワーク、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Elastic Load Balancing (ELB) サービスなど、さまざまなソースからの重要なヘルスメトリクスを監視しています。ARC は、影響を受けた AZ が再び正常状態になったことがテレメトリで示されると、ゾーンオートシフトを終了します。これにより、EKS クラスターに接続されているすべての正常な AZ にトラフィックが返されます。 ARC ゾーンシフトとゾーンオートシフトを利用する理由 AWS グローバルクラウドインフラストラクチャ は、各 AWS リージョンが完全に分離された複数の AZ で構成されているため、耐障害性とレジリエンスを提供します。このマルチ AZ アーキテクチャを活用することは、リージョンに高可用性アプリケーションを実装するために不可欠です。Amazon EKS では、複数の AZ にデプロイすることで可用性の高いアプリケーションを迅速に開発できますが、スケーラブルでパフォーマンスが高く、信頼性の高い方法で AZ の障害に対処するには、構築と保守に多大な労力を要するカスタムソリューションを実装する必要があります。 もう 1 つの課題は、シミュレーションが難しいことが多い AZ 障害シナリオのテストです。テストが不十分だと、環境内の AZ で異常が生じたとき、予期せぬワークロードの動作に陥る可能性があります。 ARC ゾーンシフトまたはゾーンオートシフトを用いると、障害のある AZ で実行されているクラスターワーカーノードと Pod を一時的に隔離し、クラスター内のネットワークトラフィックをそれらから自動的に切り離して、ワークロードの耐障害性と可用性を向上させることができます。 さらに、ゾーンシフトとゾーンオートシフト機能を使用することで、AZ 障害の計画と対応に伴うチームのオペレーションオーバーヘッドを削減できます。 仕組み EKS クラスターを ARC リソースとして登録すると、ARC を使用してクラスターのゾーンシフトをトリガーしたり、もしくはクラスターのゾーンオートシフトを有効にしたりできます。ARC がゾーンシフトを実行すると、クラスターは次のような変更を受けます。 Kubernetes スケジューラ が異常な AZ のノードに新しい Pod をスケジュールできないように、影響を受けた AZ のノードは cordon (スケジュール対象外としてマーク) されます。 マネージドノードグループ (MNG) を使用している場合、 アベイラビリティゾーンの再調整 は一時停止され、 Auto Scaling グループ (ASG) が更新されて、新しい Amazon EKS のデータプレーンノードが正常な AZ でのみ起動されるようになります。Karpenter と Kubernetes の Cluster Autoscaler は、ARC ゾーンシフトとゾーンオートシフトをネイティブでサポートしていません。正常に動作している AZ のみに新しいノードをプロビジョニングするよう自動スケーリングツールを再構成する必要があります。新しいノードの起動に特定の AZ のみを使用するように Karpenter と Cluster Autoscaler を設定する方法については、 Amazon EKS ベストプラクティスガイド を参照してください。 異常な AZ のノードは終了されません。したがって、影響を受けた AZ の Pod は削除されません。これは、ゾーンシフトの期限が切れたりキャンセルされたときに、トラフィックがフルキャパシティーの状態の AZ に安全に戻るようにするためです。 EndpointSlice controller は、障害のある AZ 内のPod の Endpoint を検出し、それらを関連するEndpointSlice リソースから削除します。これにより、ネットワークトラフィックが正常な AZ の Pod の Endpoint のみを対象とすることが保証されます。Endpoint slice controller は、ゾーンシフトがキャンセルまたは期限切れになると、復元された AZ の Endpoint を含むように Endpoint slice を更新します。 次の図は、Amazon EKS 環境における AZ の異常が生じた場合の east-to-west (クラスター内部) のトラフィックフローを示しています。このようなシナリオでは、ネットワークパケットのドロップやネットワーク遅延が発生する可能性があります。 次の図は、障害のある AZ からトラフィックを切り離した場合の Amazon EKS 環境を示しています。 ゾーンシフトとゾーンオートシフトのための EKS クラスターとワークロードの準備 Amazon EKS でゾーンシフトとゾーンオートシフトが正常に動作するようにするには、事前に AZ 障害に強いクラスター環境を準備する必要があります。以下は、 EKS クラスターに実装する必要がある重要なステップのリストです。これらのステップについては、 Amazon EKS のドキュメント で詳しく説明されています。 クラスター内のワーカーノードを複数の AZ に分散します。 単一の AZ の削除に耐えられるだけの十分なコンピューティングキャパシティをプロビジョニングしてください。AZ 障害に耐えられるアプリケーションの構築方法の詳細については、 静的安定性 に関する AWS のドキュメントを参照してください。 すべての AZ で、Pod を事前にスケーリングしてください。これらの Pod には、アプリケーション Pod と、CoreDNS、Cluster Autoscaler、 AWS Load Balancer Controller などのコントローラー Pod が含まれます。これを実現する方法の詳細については、 Amazon EKS のドキュメント を参照してください。 Pod レプリカを複数の AZ をまたいで分散させて、単一の AZ を切り離しても十分な容量が残るようにします。これを実現するには、Topology spread constraints が役立ちます。 クラスターで実行されているコントローラーやその他のアプリケーションの高可用性 (HA) をサポートするためにリーダーの選出が必要な場合は、ポッドの数が奇数であるか、ポッドが 2 つ以上であるなどの基準が、AZ 障害イベント中および発生後に一貫して満たされていることを確認してください。 ロードバランサーを使用して外部トラフィックを Kubernetes の Service にルーティングする場合は、ALB と NLB のみを使用することをお勧めします。 AWS Load Balancer Controller を使用してロードバランサーを管理することもお勧めします。AWS Load Balancer Controller はインスタンスと IP トラフィックモードをサポートしていますが、そのうちの IP モードが推奨されます。インスタンスと IP モードの詳細については、 AWS Load Balancer Controller のドキュメント を参照してください。 Amazon EKS のゾーンシフトによってアプリケーションとクラスター環境が正常に回復するには、前述のステップが不可欠です。さらに、AZ 障害を効果的に管理するには、以下のベストプラクティスをお勧めします。 Topology Aware Routing などの Kubernetes 機能を使用するか、 サービスメッシュ と統合することで、Pod 間の通信を同じ AZ 内に限定します。 同じ AZ 内に、相互に依存するアプリケーションとサービスを配置します。これは Pod Affinity rule で実現できます。 マルチ AZ オブザーバビリティ を実装します。 アプリケーションでは、データベース、サービスなどの外部依存関係に対するタイムアウト値を適切に設定し、再試行を実装してください。障害を正常に処理するには、エクスポネンシャルバックオフパターンを備えたサーキットブレーカーを実装してください。 ゾーンシフトとゾーンオートシフトをサポートするようにクラスターとワークロードを準備する方法、およびゾーンシフトとゾーンオートシフトに関するその他のベストプラクティスの詳細については、 Amazon EKS ドキュメント を参照してください。 さらに、ワークロードが AZ 障害を処理できることを定期的にテストして検証することを強くお勧めします。ゾーンシフトを手動でトリガーするか、ゾーンオートシフトを有効にして、クラスター環境の AZ を 1 つ減らしてワークロードが期待どおりに機能することを確認することで、AZ 障害をテストできます。 始めてみよう ARC ゾーンシフト機能の説明に使用するサンプルアプリケーションを準備しました。このウォークスルーでは、既存の EKS クラスターを使用するか、 新しいクラスターを作成 できます。クラスターとそのクラスターに設定されているノードグループは、3 つの AZ にまたがり、各 AZ に少なくとも 1 つのノードが必要です。 1. サンプルアプリケーションをデプロイする a. まず、EKS クラスターにサンプルアプリケーションをデプロイします。Kubernetes Secret を作成するときは、必ず有効なユーザー名とパスワードを指定してください。この Secret は、MySQL データベースとそれに接続するアプリケーションの両方で使用されます。 kubectl create secret generic catalog-db --from-literal=username=<<有効なユーザー名で置換>> --from-literal=password=<<有効なパスワードで置換>> cat << EOF > catalog_deploy.yaml --- apiVersion: v1 kind: ConfigMap metadata: name: catalog data: DB_ENDPOINT: catalog-mysql-0.catalog-mysql:3306 DB_READ_ENDPOINT: catalog-mysql-0.catalog-mysql:3306 DB_NAME: catalog --- apiVersion: v1 kind: Service metadata: name: catalog-mysql labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql spec: clusterIP: None ports: - port: 3306 targetPort: mysql protocol: TCP name: mysql selector: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql --- apiVersion: v1 kind: ServiceAccount metadata: name: catalog labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample app.kubernetes.io/managed-by: Helm --- apiVersion: v1 kind: Service metadata: name: catalog labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample app.kubernetes.io/managed-by: Helm spec: type: ClusterIP ports: - port: 80 targetPort: http protocol: TCP name: http selector: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample --- apiVersion: apps/v1 kind: Deployment metadata: name: catalog labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample app.kubernetes.io/managed-by: Helm spec: replicas: 3 strategy: rollingUpdate: maxUnavailable: 1 type: RollingUpdate selector: matchLabels: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample template: metadata: annotations: prometheus.io/path: /metrics prometheus.io/port: "8080" prometheus.io/scrape: "true" labels: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: service app.kuberneres.io/owner: retail-store-sample spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app.kubernetes.io/name: catalog serviceAccountName: catalog securityContext: fsGroup: 1000 containers: - name: catalog env: - name: DB_USER valueFrom: secretKeyRef: name: catalog-db key: username - name: DB_PASSWORD valueFrom: secretKeyRef: name: catalog-db key: password envFrom: - configMapRef: name: catalog securityContext: capabilities: drop: - ALL readOnlyRootFilesystem: true runAsNonRoot: true runAsUser: 1000 image: public.ecr.aws/aws-containers/retail-store-sample-catalog:0.8.1 imagePullPolicy: IfNotPresent ports: - name: http containerPort: 8080 protocol: TCP livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 periodSeconds: 3 resources: limits: memory: 256Mi requests: cpu: 128m memory: 256Mi volumeMounts: - mountPath: /tmp name: tmp-volume volumes: - name: tmp-volume emptyDir: medium: Memory --- apiVersion: apps/v1 kind: StatefulSet metadata: name: catalog-mysql labels: helm.sh/chart: catalog-0.0.1 app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql app.kubernetes.io/managed-by: Helm spec: replicas: 3 serviceName: catalog-mysql selector: matchLabels: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql template: metadata: labels: app.kubernetes.io/name: catalog app.kubernetes.io/instance: catalog app.kubernetes.io/component: mysql spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app.kubernetes.io/name: catalog app.kubernetes.io/component: mysql containers: - name: mysql image: public.ecr.aws/docker/library/mysql:8.0 imagePullPolicy: IfNotPresent env: - name: MYSQL_ROOT_PASSWORD valueFrom: secretKeyRef: name: catalog-db key: password - name: MYSQL_DATABASE value: catalog - name: MYSQL_USER valueFrom: secretKeyRef: name: catalog-db key: username - name: MYSQL_PASSWORD valueFrom: secretKeyRef: name: catalog-db key: password volumeMounts: - name: data mountPath: /var/lib/mysql ports: - name: mysql containerPort: 3306 protocol: TCP volumes: - name: data emptyDir: {} --- EOF kubectl apply -f catalog_deploy.yaml b. Kubernetes マニフェストファイルをクラスターに適用すると、それぞれ catalog と catalog-mysql という名前の 2 つのアプリケーションが作成され、 catalog-mysql は MySQL データベースになります。次のステップに進む前に、Pod が実行状態であることを確認します (これには数分かかる場合があります)。 2. クラスターのゾーンシフトを有効にする a. Amazon EKS コンソールを開いてクラスターを選択し、次の図に示すように、 概要 (Overview) の ゾーンシフト (Zonal Shift) セクションに移動します。 b. 管理 (Manage) を選択し、 有効化 (Enabled) を選択し、変更を保存します。 3. アプリケーションを検証する a) default Namespace で利用可能な Service を一覧表示します。 kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE catalog LoadBalancer XX.XXX.XXX.XXX <pending> 80:31932/TCP 41m catalog-mysql ClusterIP None <none> 3306/TCP 41m b) catalog Service への kubectl port-forward をバックグラウンドモードで実行します。プロセスのプロセス ID を書き留めておきます。 kubectl port-forward svc/catalog 8090:80 > /dev/null & [1] 42306 c) curl を使用して catalog Service を呼び出すと、以下に示すように、いくつかのアイテム ID を返すことを確認します。 curl -s localhost:8090/catalogue | jq -r '.[0,1].id' 510a0d7e-8e83-4193-b483-e27e09ddc34d 6d62d909-f957-430e-8689-b5129c0bb75e # port-forward プロセスを終了 (42306) kill -9 <<kubectl port-forward プロセスのプロセスID>> 4. クラスター・トポロジーを理解する アプリケーションが正常に動作していることを確認できたので、ゾーンシフトを実行する準備が整いました。ただし、ゾーンシフトをトリガーする前に、クラスターのトポロジーを理解する必要があります。これには、Pod が稼働している AZ を特定することが含まれます。 a. リージョンの AZ ID を一覧表示します。この例では、リージョンは us-west-2 なので、us-west-2 の AZ ID を確認できます。 aws ec2 describe-availability-zones --query 'AvailabilityZones[*].[ZoneName, ZoneId]' --output text us-west-2a usw2-az2 us-west-2b usw2-az1 us-west-2c usw2-az3 us-west-2d usw2-az4 b. 次のコマンドを使用して、クラスター内の各ノードとそれが動作している AZ を特定する必要があります。次のコマンドを入力すると、ノード名とノードが実行されている AZ のリストが出力されるはずです。この例では、3 つのノードが 3 つの AZ (us-west-2b、us-west-2b、us-west-2c) に分散しています。 kubectl get nodes -o=jsonpath='{range .items[*]}"{.metadata.name}"{"\t"}"{.metadata.labels.topology\.kubernetes\.io/zone}"{"\n"}{end}' | sort -k 1 > nodes-info.txt cat nodes-info.txt "ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal" "us-west-2a" "ip-YYY-YYY-YYY-YYY.us-west-2.compute.internal" "us-west-2b" "ip-ZZZ-ZZZ-ZZZ-ZZZ.us-west-2.compute.internal" "us-west-2c" c. 次のコマンドを使用して、各 Pod が現在実行されているノードと AZ を特定する必要があります。コマンドを入力すると、Pod 名、AZ、および Pod が実行されているノードを示す出力が生成されます。この場合、3 つの AZ の 3 つのノードに分散されたカタログアプリケーションポッドがあります。 kubectl get pods -l "app.kubernetes.io/component"=service -o=jsonpath='{range .items[*]}"{.metadata.name}"{"\t"}"{.spec.nodeName}"{"\n"}{end}' | sort -k 2 > pods-info.txt join -1 1 -2 2 nodes-info.txt pods-info.txt "ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal" "us-west-2b" "catalog-74957c74ff-xxxxx" "ip-YYY-YYY-YYY-YYY.us-west-2.compute.internal" "us-west-2c" "catalog-74957c74ff-yyyyy" "ip-ZZZ-ZZZ-ZZZ-ZZZ.us-west-2.compute.internal" "us-west-2a" "catalog-74957c74ff-zzzzz" 5. ゾーンシフトをトリガーする これで、クラスター・トポロジーを十分に理解できたはずです。次に、ゾーンシフトをトリガーしてトラフィックを AZ から切り離し、ゾーンシフト機能をテストします。 a. 次の図に示すように、ARC コンソールを開き、 ゾーンレベルの移行 (Zonal Shift) を選択します。 b. 次の図に示すように、ゾーンシフトを開始するために、トラフィックを切り離す AZ (us-west-2b)、ゾーンシフトを実行する EKS クラスタ、有効期限 (10 分) を選択して、そして 開始 (Start) を選択します。 ゾーンシフトは、トリガーしてから完了するまでに数分かかります。そのため、数分待ってからテストすることをお勧めします。 c. アプリケーションの Endpoint へのトラフィックを生成してアプリケーションを検証し、トラフィックを切り離した AZ で実行されている Pod に対して呼び出しが行われていないことを確認します。そのためには、まず Kubernetes Job を実行してアプリケーションへのトラフィックを生成し、次にトラフィックを処理する Pod とそれらが属する AZ をログから特定します。次のコマンドを入力すると、catalog Service へのトラフィックが 2 つの Pod に分散されていることがわかります。 kubectl create job curl-job --image=curlimages/curl -- /bin/sh -c "while true; do curl -s catalog.default/catalogue; sleep 1; done" start_time=$(date -u +"%Y-%m-%dT%H:%M:%SZ") # 20-30秒間待つ kubectl logs -l "app.kubernetes.io/component"=service --prefix --since-time=$start_time --tail=50 | grep -i "/catalogue" | cut -d '/' -f 2 | sort | uniq -c > pod-logs.txt cat pod-logs.txt 5 catalog-78679df9c4-xxxx 6 catalog-78679df9c4-zzzz d. Pod の位置を確認すると、どの Pod も AZ us-west-2b (ゾーンシフトによってトラフィックが迂回された AZ) で稼働していないことがわかります。 join -1 1 -2 2 nodes-info.txt pods-info.txt | tr -d \" | sort -k 3 > pods-nodes-az.txt join -1 3 -2 2 pods-nodes-az.txt pod-logs.txt catalog-74957c74ff-xxxx ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal us-west-2a 5 catalog-74957c74ff-zzzz ip-ZZZ-ZZZ-ZZZ-ZZZ.us-west-2.compute.internal us-west-2c 6 e. 先に進む前に、トラフィックを生成するために作成した Kubernetes Job を削除します。 kubectl delete job curl-job 6. ゾーンシフトをキャンセルする a. 次の図に示すように、以前に作成したゾーンシフトを選択し、 ゾーンシフトをキャンセル (Cancel zonal shift) を選択して、ゾーンシフトのキャンセルをテストします。 ゾーンシフトのキャンセルは、トリガーしてから完了するまでに数分かかります。そのため、数分待ってからテストすることをお勧めします。 b. アプリケーションへのトラフィックを生成し、AZ で動作している Pod がトラフィックを受信していることを確認できます。 kubectl create job curl-job --image=curlimages/curl -- /bin/sh -c "while true; do curl -s catalog.default/catalogue; sleep 1; done" start_time=$(date -u +"%Y-%m-%dT%H:%M:%SZ") # 20-30秒間待つ kubectl logs -l "app.kubernetes.io/component"=service --prefix --since-time=$start_time --tail=50 | grep -i "/catalogue" | cut -d '/' -f 2 | sort | uniq -c > pod-logs.txt cat pod-logs.txt 9 catalog-78679df9c4-xxxx 7 catalog-78679df9c4-yyyy 5 catalog-78679df9c4-zzzz join -1 1 -2 2 nodes-info.txt pods-info.txt | tr -d \" | sort -k 3 > pods-nodes-az.txt join -1 3 -2 2 pods-nodes-az.txt pod-logs.txt catalog-74957c74ff-xxxx ip-XXX-XXX-XXX-XXX.us-west-2.compute.internal us-west-2a 9 catalog-74957c74ff-yyyy ip-YYY-YYY-YYY-YYY.us-west-2.compute.internal us-west-2b 7 catalog-74957c74ff-zzzz ip-ZZZ-ZZZ-ZZZ-ZZZ.us-west-2.compute.internal us-west-2c 5 # kubernetes job を削除する kubectl delete job curl-job 7. クラスターのゾーンオートシフトを設定します a. ゾーンオートシフトを設定する前に、ARC が練習実行が成功のうちに完了したかどうかを検査するために用いる Amazon CloudWatch アラームを設定する必要があります。ARC ゾーンオートシフトの練習実行の詳細については、この ドキュメント を参照してください。 b. 次の図に示すように、ARC コンソールを開き、 ゾーンオートシフトを設定 (Configure zonal autoshift) を選択します。 c. ゾーンオートシフトの設定するリソース (Resource to configure) として EKS クラスターを選択し、ゾーンオートシフトのステータス (Zonal autoshift status) で 有効化 (Enable) を選択し、CloudWatch アラーム ARN を入力して 作成 (Create) を選択します。次の図に示すように、コンソールのオプションセクションはそのままにしておきます。 d. ARCは、練習実行の一環として、週に1回、ゾーンオートシフトを実施します。Amazon EventBridge との統合を用いて、ゾーンオートシフトと練習実行の通知を受け取ることができます。練習実行中に、ゾーンシフトの検証に使用したのと同じ検証手順をゾーンオートシフトに適用できます。 ゾーンシフトとオートシフトにより、AZ 障害からの迅速な回復と Amazon EKS ワークロードの信頼性の向上が可能になります。AZ 障害に対して真に回復力を発揮するには、ワークロードがゾーンシフトやゾーンオートシフト機能を使用するだけでなく、「クラスターとワークロードの準備」セクションで概説されているプラクティスを遵守して AZ 障害からの回復も行う必要があります。 後片付け 今後のコストを避けるため、この演習用に作成された EKS クラスターなどのリソースをすべて削除してください。次のコマンドは、ゾーンシフトをテストするために以前にインストールしたアプリケーションを削除します。 kubectl delete -f catalog_deploy.yaml kubectl detelet secret catalog-db rm nodes-info.txt pods-info.txt pod-logs.txt pods-nodes-az.txt 価格と提供リージョン Amazon EKS の ARC ゾーンシフトおよびゾーンオートシフト機能の対応は、中国と GovCloud リージョンを除くすべての AWS リージョンで利用できます。EKS クラスターでゾーンシフトを有効にしてゾーンシフトをトリガーしても、追加のコストは発生しません。ただし、Pod やクラスターノードの事前スケーリングなど、ワークロードが AZ 障害を確実に処理できるようにするために、追加のコストがかかる場合があります。 まとめ この投稿では、ARC ゾーンシフトおよびゾーンオートシフト機能を使用して、単一の AZ 障害から回復する方法を説明しました。入念な計画と実装を行うことで、ゾーンシフトとゾーンオートシフトの可能性を最大限に活用して、単一の AZ 障害から Amazon EKS クラスターで実行されているアプリケーションとデータソースを保護できます。 Amazon EKS のゾーンシフトとゾーンオートシフトの詳細については、 Amazon EKS のドキュメント を参照してください。 GitHub でホストされている AWS Containers Roadmap にコメントを残したり、Issue を投稿したりすることで、EKS クラスターの ARC ゾーンシフト機能に関するフィードバックを提供できます。今後も機能を進化させ、ユーザーがクラスターの耐障害性と可用性を向上させるのに役立つさまざまな方法を模索していきますので、ご期待ください。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。

この記事は Getting started with Amazon EKS Auto Mode (記事公開日: 2024 年 12 月 3 日) を翻訳したものです。 この記事は、Alex Kestner (Amazon EKS シニアプロダクトマネージャー) 、Ashley Ansari (シニアプロダクトマーケティングマネージャー) 、Robert Northard (コンテナプリンシパル GTM SSA) 、Sheetal Joshi (コンテナプリンシパルソリューションアーキテクト) の共著です。 はじめに Kubernetes クラスターにおけるコンピューティング、ストレージ、ネットワーキングを効率的に管理する新機能、 Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode の一般提供を発表しました。この機能により、クラスターを迅速に構築し、パフォーマンスを向上させ、管理の手間を減らすことができます。クラスター管理を AWS に任せることで、アプリケーションの構築に集中してイノベーションの推進に注力いただけます。 Amazon EKS Auto Mode は、インフラストラクチャの自動プロビジョニング、最適なコンピューティングインスタンスの選択、リソースの動的スケーリング、コスト最適化のために継続的なコンピューティングの最適化、オペレーティングシステム (OS) のパッチ適用、AWS セキュリティサービスとの統合により、Kubernetes クラスター管理を効率化します。有効にすると、EKS Auto Mode は AWS のベストプラクティスに基づいてクラスター機能を設定し、アプリケーションのデプロイに最適な状態でクラスターを準備します。 この記事では、EKS Auto Mode の高レベルアーキテクチャを紹介し、EKS Auto Mode を使用して高可用性かつ自動スケーリング機能を備えたサンプルアプリケーションをデプロイする手順を紹介します。 新機能の紹介 Amazon EKS は長らく、Kubernetes を実行するための安全な方法として信頼されてきました。EKS Auto Mode 以前は、マネージドのコントロールプレーンがあるにもかかわらず、本番環境相当の Kubernetes アプリケーションを実行するために必要なインフラストラクチャを管理するには、専門的な知識と継続的な労力が求められていました。具体的には、ユーザーはリソース効率とコストを最適化するための適切な Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの選択とプロビジョニングから、プラグインのインストールとメンテナンスまで、継続的なメンテナンス活動を行わなければなりませんでした。以下の図に示すように、インフラのセキュリティと最新性を維持するため、クラスターのアップグレードや OS のパッチ適用も並行して管理しなければなりませんでした。 Before Auto Mode EKS Auto Mode によるクラスター運用の完全自動化は、本番環境レベルの Kubernetes インフラ管理に必要な専門知識の依存度を大幅に低減し、ユーザーの時間と労力を大きく節約します。EC2 インスタンスの選定やプロビジョニング、リソースとコストの最適化、プラグインのメンテナンスといった作業にユーザーが時間とリソースを費やす必要がなくなりました。 EKS Auto Mode を有効にして新規に EKS クラスターを作成するか、既存のクラスターを更新すると、Amazon EKS は自動的に必要な処理を行います。具体的には、コンピューティング、ネットワーキング、ストレージ機能に必要なコントローラーを、Amazon EKS 専用の AWS アカウントと VPC 内にデプロイします。これはマネージドな Kubernetes コントロールプレーンと併せて実施されます。 アプリケーションのデプロイ時には、EKS Auto Mode が自動的に Bottlerocket OS ベースの EC2 インスタンスと Elastic Load Balancing (ELB) を起動し、ユーザーの AWSアカウントと指定された VPC 内に Amazon EBS ボリュームをプロビジョニングします。さらに、これらの EC2 インスタンスのライフサイクル管理、実行時のアプリケーション要件に応じたデータプレーンのスケーリングと最適化、不健全なノードの自動置換を行います。下図が示すように、EKS Auto Mode は、Amazon EC2 の豊富な機能や柔軟性を損なうことなく、管理されたインフラストラクチャを提供します。 After Auto Mode EKS Auto Mode の導入により、これまで Kubernetes DaemonSet として動作していたノード管理機能が、AWS が管理するシステムプロセスとして実行できるようになりました。具体的には、サービスディスカバリー、ロードバランシング、Pod ネットワーキング、ブロックストレージ、認証情報の提供などの機能が含まれます。AWS がこれらのコンポーネントのライフサイクル管理を担当し、セキュリティ更新を行い、最新のコンポーネントを組み込んだ EKS Auto Mode 用の Amazon Machine Image (AMI) を定期的にリリースします。 また、EKS Auto Mode はクラスターのアップグレードと OS の更新を自動的に行います。この際、ユーザーが定義した Kubernetes のスケジューリング制約を考慮しながら、ノードを段階的に置き換えることで、インフラのセキュリティと最新性を維持します。これにより運用の負担が大幅に軽減され、開発チームはインフラ管理ではなく、アプリケーション開発に注力できるようになります。 はじめ方 EKS Auto Mode は、Kubernetes バージョン 1.29 以降を実行している新規および既存の EKS クラスターで利用可能になりました。EKS Auto Mode を始めるには、新しいコンソール機能 [Quick Configuration (クイック設定) ]が便利です。この機能を使えば、最適なデフォルト設定が予め構成されたクラスターをワンクリックで迅速に立ち上げることができます。あるいは、Amazon EKS API、 AWS マネジメントコンソールのカスタム設定 、 eksctl、お好みの Infrastructure as code (IaC) ツールを使用することも可能です。 このセクションでは、EKS Auto Mode が Amazon EKS 上でのアプリケーションデプロイをいかに簡素化するかを実際に示します。まず、EKS Auto Mode を有効にして EKS クラスターを作成し、その後サンプルの小売店アプリケーションをデプロイします。EKS Auto Mode が新しいノードを自動的に起動し、AWS Load Balancer をセットアップし、永続的なストレージ要件を管理し、アプリケーションの自動スケーリングニーズを処理する様子をご覧いただけます。 事前準備 本記事で紹介する手順を実行するには、以下の準備が必要です： AWSアカウント：管理者権限を持つAWSアカウントをお持ちであることを前提としています。 以下のツールをインストールしてください： Helm 3.9+ 、 kubectl 、 eksctl 、 AWS Command Line Interface (AWS CLI) クラスターの作成 本記事では、EKS クラスターを簡単に作成できるコマンドラインツールである eksctl を使用します。以下に示す設定例では、eksctl を使ってクラスターインフラストラクチャとアプリケーションデプロイ用のサブネットを自動生成します。もしこのサンプル設定を使用しない場合は、 Amazon EKS ユーザーガイド に記載されている前提条件を全て確認してください。特に、クラスター IAM ロールとノード IAM ロールの変更が必要となります。これらの変更により、EKS Auto Mode がユーザーのアカウント内で EC2 インスタンスを管理するための新しい権限が付与されます。 今回のセットアップでは、あらかじめ用意されている general-purpose (汎用) ワークロードとsystem (システム) ワークロード用のマネージドな NodePool を使用して EKS Auto Mode を有効化します。general-purpose NodePool は汎用的なワークロードの起動をサポートし、system NodePool はアドオンを処理します。両方とも、C、M、R ファミリーの amd64 アーキテクチャを持つオンデマンド EC2 インスタンス (第5世代以降) を使用します。マネージドな NodePool の詳細については、 EKS Auto Mode ユーザーガイド を参照してください。 cat << EOF > cluster.yaml apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: eks-auto-mode-demo region: us-west-2 version: "1.31" addonsConfig: disableDefaultAddons: true autoModeConfig: enabled: true nodePools: ["general-purpose", "system"] EOF eksctl create cluster -f cluster.yaml クラスターの状態が Active  になるまでお待ちください。 aws eks describe-cluster --name eks-auto-mode-demo --output json --query 'cluster.status' これでクラスターの準備が整い、アプリケーションをデプロイできる状態になりました。次のセクションでは、EKS Auto Mode を使用することで、アプリケーションのデプロイがいかに簡素化されるかを実際に見ていきましょう。 アプリケーションのデプロイ 今回使用する サンプルアプリケーション は、オンラインショッピングの機能を模しています。ユーザーは商品カタログを閲覧し、商品をカートに追加し、チェックアウトプロセスを経て注文を完了することができます。このアプリケーションは、UI、カタログサービス、注文サービス、カートサービス、チェックアウトサービスなど、複数のコンポーネントで構成されています。また、永続的なストレージを必要とするバックエンドデータベースも含まれています。これらのコンポーネントは、Kubernetes の Deployment と StatefulSet を用いて実装されています。アプリケーションへのアクセスには、Kubernetes Ingress を使用してクラスター外からのアクセスを可能にします。また、カタログアプリケーションにはAmazon EBS 永続ストレージを使用するよう設定します。 EKS Auto Mode のパフォーマンス向上、スケーラビリティ、可用性の強化を実証するため、UI アプリケーションには特別な設定を行います。具体的には、 Horizonal pod Autoscaling (HPA) 、 Pod Topology Spread Constraints 、 Pod Disruption Budgets (PDB) をサポートするよう構成します。これらの設定により、EKS Auto Mode がもたらす利点を具体的に示すことができます。 アプリケーションのデプロイに進む前に、まずはクラスターの状態を確認しておきましょう。 kubectl get nodes kubectl get pods 現時点では、ノードと Pod のリストが空であることが確認できました。 アプリケーションのデプロイに進む前に、StorageClass とIngressClass を作成します。これらの設定は、後ほどデプロイするアプリケーションが必要とするストレージと Ingress の要件を満たすための基盤となります。一般的に、この作業はクラスター作成直後にプラットフォームチームが一度だけ実施するものです。この設定を行うことで、アプリケーションのデプロイがスムーズに進み、必要なリソースがすぐに利用可能になります。 cat >ingress.yaml <<EOF --- apiVersion: eks.amazonaws.com/v1 kind: IngressClassParams metadata: name: eks-auto-alb spec: scheme: internet-facing --- apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: eks-auto-alb spec: controller: eks.amazonaws.com/alb parameters: apiGroup: eks.amazonaws.com kind: IngressClassParams name: eks-auto-alb EOF kubectl apply -f ingress.yaml cat >ebs-sc.yaml <<EOF --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: eks-auto-ebs-csi-sc annotations: storageclass.kubernetes.io/is-default-class: "true" provisioner: ebs.csi.eks.amazonaws.com volumeBindingMode: WaitForFirstConsumer parameters: type: gp3 EOF kubectl apply -f ebs-sc.yaml アプリケーションのデプロイには Helm を使用します。まず、先ほど説明したアプリケーションの要件を指定するための values.yaml ファイルを作成しましょう。 cat >values.yaml <<EOF catalog: mysql: secret: create: true name: catalog-db username: catalog persistentVolume: enabled: true accessMode: - ReadWriteOnce size: 30Gi storageClass: eks-auto-ebs-csi-sc ui: endpoints: catalog: http://retail-store-app-catalog:80 carts: http://retail-store-app-carts:80 checkout: http://retail-store-app-checkout:80 orders: http://retail-store-app-orders:80 assets: http://retail-store-app-assets:80 autoscaling: enabled: true minReplicas: 5 maxReplicas: 10 targetCPUUtilizationPercentage: 80 topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app: ui - maxSkew: 1 topologyKey: kubernetes.io/hostname whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app: ui ingress: enabled: true className: eks-auto-alb EOF それでは、小売店アプリケーションのデプロイを行いましょう。デプロイを進める際は、values.yaml ファイルの設定内容に注意を払ってください。特に重要なのは、UI のエンドポイントの設定です。もし、デフォルトの retail-store-app とは異なるチャート名を使用している場合は、必ずエンドポイントの設定を適切に更新してください。 helm install -f values.yaml retail-store-app oci://public.ecr.aws/aws-containers/retail-store-sample-chart --version 0.8.3 EKS Auto Mode は、デプロイされた Pod のリソース要求を分析し、アプリケーションの実行に最適なコンピューティングリソースを判断します。この過程で、ユーザーが設定したスケジューリング制約 (トポロジー分散制約を含む) が考慮されます。EKS Auto Mode は general-purpose のマネージド NodePool を利用してノードを起動します。ノードが Ready になるまで待ちます。 kubectl wait --for=condition=Ready nodes --all 別のターミナルで、アプリケーションが使用可能な状態になるのを監視します。 kubectl wait --for=condition=available deployments --all 小売店アプリケーションのコンポーネントは実行中の状態になっているはずです。 catalog-mysql-ebs StatefulSetを調べると、EKS Auto Mode が 30 GiB の PersistentVolumeClaim を作成し、 storageClassName が eks-auto-ebs-csi-sc であることがわかります。 kubectl get statefulset retail-store-app-catalog-mysql \ -o jsonpath='{.spec.volumeClaimTemplates}' | jq . Output: [ { "apiVersion": "v1", "kind": "PersistentVolumeClaim", "metadata": { "creationTimestamp": null, "name": "data" }, "spec": { "accessModes": [ "ReadWriteOnce" ], "resources": { "requests": { "storage": "30Gi" } }, "storageClassName": "eks-auto-ebs-csi-sc", "volumeMode": "Filesystem" } } ] EKS Auto Mode は UI アプリケーション用に Application Load Balancer (ALB) を自動的に作成しました。以下のコマンドで ALB 名を確認できます。ALB の準備ができたら、ウェブブラウザでそのリンクにアクセスできます。小売店のホームページが表示されるはずです。 kubectl get ingress retail-store-app-ui -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}" Output: k8s-ui-uinlb-1111111111.elb.us-west-2.amazonaws.com アプリケーションのスケーリング アプリケーションのデプロイが完了したので、次は EKS Auto Mode によるスケーリング機能を見ていきましょう。EKS Auto Mode は HorizontalPodAutoscaler(HPA) と metrics-server を活用して、アプリケーションの需要に応じてクラスターのリソースを自動的に調整します。Kubernetes では、HPA は観測されたメトリクスに基づいて Deployment のレプリカ数を自動的に調整します。Metrics server は kubelet から CPU とメモリ使用量を収集し、Kubernetes API サーバーを通じて HPA に公開します。HPA はこれらのメトリクスを継続的に監視し、指定されたターゲットに一致するようにレプリカ数を調整します。 まず、Kubernetes metrics-server をデプロイします。 kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml この例では、UI サービスを使用し、CPU 使用率 (80 %) に基づいてスケーリングし、maxReplicas を 10 に設定します。なお、HPA の設定はアプリケーションのインストール時にすでに適用されています。具体的な設定内容は、 values.yaml ファイルの AutoScaling セクションで確認できます。現在の AutoScaling ポリシーは、以下のコマンドで確認することができます。 kubectl get hpa retail-store-app-ui 次に、設定した AutoScaling ポリシーがどのように機能するかを確認するため、負荷をかけてみましょう。これにより、EKS Auto Mode がクラスターのインフラストラクチャをどのようにスケールアウトするかを実際に観察できます。 kubectl run load-generator \ --image=public.ecr.aws/amazonlinux/amazonlinux:2023 \ --restart=Never — /bin/sh -c "while sleep 0.01; do curl http://retail-store-app-ui/home; done" アプリケーションに対してリクエストが発生しているので、この負荷に応じて EKS Auto Mode がどのように対応するか観察しましょう。新しいノードが起動し、UI Pod の数が増加する様子を確認できるはずです。 kubectl get nodes --watch Output: NAME STATUS ROLES AGE VERSION i-00018eaec7a3d5370 Ready <none> 155m v1.31.0-eks-672e808 i-043c71a371a8514a1 Ready <none> 155m v1.31.0-eks-672e808 HPA リソースを監視して、その進行状況を追跡できます。 kubectl get hpa retail-store-app-ui --watch Output: NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE retail-store-app-ui Deployment/retail-store-app-ui cpu: 158%/80% 3 10 5 16m retail-store-app-ui Deployment/retail-store-app-ui cpu: 161%/80% 3 10 6 16m retail-store-app-ui Deployment/retail-store-app-ui cpu: 148%/80% 3 10 9 16m ご覧の通り、EKS Auto Mode はアプリケーションの需要に基づいてクラスターインフラストラクチャを完全に管理し、動的にスケーリングします。Pod を終了させることで、負荷テストを停止できます。負荷生成の Pod が終了すると、HPAは設定に基づいてレプリカ数を徐々に最小数まで減らしていきます。 kubectl delete pod load-generator 主要な考慮事項 Amazon EKS Auto Mode でワークロードを展開する際に考慮すべき主なポイントは以下の通りです： Pod Disruption Budgets を設定し、自発的な中断からワークロードを保護する ：EKS Auto Mode が使用率の低いノードを停止させるような自発的な中断時に、Pod Disruption Budgets は Deployment のレプリカが中断される割合を制御し、一定のワークロード容量を維持してサービスの継続性を確保します。 高可用性を実現するため、レプリカをノードとアベイラビリティーゾーン間に分散させる ：Pod トポロジー分散制約を使用してワークロードをノード間に分散させ、同じノード上で Deployment の複数のレプリカが実行される可能性を最小限に抑えます。 適切なリソース要求と制限を設定する ：EKS Auto Mode はワークロードの vCPU とメモリ要求に基づいて EC2 インスタンスを起動します。リソースの過剰プロビジョニングを避けるため、リソース要求は慎重に設定する必要があります。EKS Auto Mode は リソース制限 や実際の使用量を考慮しないことに注意してください。 アプリケーションは正常なシャットダウン処理を実装する ：自発的な中断の間に作業の損失やユーザー体験の中断を防ぐため、アプリケーションは SIGTERM シグナルを適切に処理して正常にシャットダウンできる必要があります。Kubernetesが Pod の退避を決定すると、退避対象 Pod の各コンテナのメインプロセスに SIGTERM シグナルが送信されます。その後、SIGKILL が送信されるまでの猶予期間 (デフォルトは 30 秒) が設けられます。この猶予期間は Pod 仕様の terminationGracePeriodSeconds で変更可能です。 コンピューティングリソースの選択に過度な制約を設けない ：general-purpose の NodePool は、c、m、r 系の EC2 インスタンスを様々なサイズで利用し、ワークロードに最適なインスタンスを選択する柔軟性を確保しています。特定のコンピューティング要件がある場合は、 Kubernetes の well-known Label を使用して、特定のインスタンスタイプやアーキテクチャなどの属性を指定できます。 アプリケーションのベストプラクティスについて詳しく知りたい場合は、Amazon EKS ベストプラクティスガイドの 信頼性セクション を参照してください。 リソースの削除 不要な料金が発生しないよう、この記事で作成したリソースを以下の手順で削除してください： kubectl delete deploy -n kube-system metrics-server helm uninstall retail-store-app kubectl delete pvc/data-retail-store-app-catalog-mysql-0 eksctl delete cluster —name eks-auto-mode-demo 結論 Amazon EKS Auto Mode は、コンピューティング、ストレージ、ネットワーキングの機能をすぐに利用できる形で提供し、アプリケーションデプロイの複雑さを大幅に軽減します。新規クラスターの作成時でも既存クラスターの更新時でも、EKS Auto Mode は効率的な体験を提供します。クラスターインフラの管理だけでなく、Kubernetes の標準に準拠しながら、核となるクラスター機能も提供します。 EKS Auto Mode は、既存の Amazon EKS サービスを補完し、多様なワークロードに対応する柔軟性を提供します。特定の要件がある場合、ユーザーは従来の Amazon EKS コンピューティングオプションを引き続き利用できます。これにより、Kubernetes クラスターのカスタム設定、クラスターインフラの手動プロビジョニングと管理、Kubernetes 環境の詳細な制御が可能です。Auto Mode と従来のオプションの両方をサポートすることで、Amazon EKS は幅広いニーズに対応します。簡素化と運用負荷の軽減を求めるユースケースから、Kubernetes 環境のカスタマイズや詳細な制御が必要なケースまで、様々な要求に応えることができます。 EKS Auto Mode の機能について詳しくは、 Amazon EKS のドキュメント をご覧ください。EKS Auto Mode の実際の動作を確認し、AWS の専門家に質問する機会を得るには、今後のウェビナーシリーズ「 Simplifying Kubernetes operations with Amazon EKS Auto Mode 」にご登録ください。 翻訳はクラウドサポートエンジニアの桐生が担当しました。原文は こちら です。

日進月歩の世界において、世界 20 カ国以上で事業を展開する多国籍消費財（ CPG ）企業は、どのようにしてイノベーションの最先端を走り続けているのでしょうか。 それが、世界最大級の飲料会社であるペルーの CPG 多国籍企業 AJE Group （ AJE ） が、本格的なデジタル変革に乗り出すことを決めたときに直面した課題でした。 2019 年まで、同社はタスクごとに分断されたオンプレミスのインフラ環境を使用しており、世界の多くの地域に分散していました。 AJE は、目標を達成するためには、プロセスを合理化し、リソースをより効率的に管理するために、一元化されたクラウドベースの企業データプラットフォームを構築する必要があると判断しました。 1 万人以上の従業員を抱え、グローバルに事業を展開する同社は、組織全体でデータドリブンな意思決定を強化するため、データソリューションのモダナイズも必要としていました。 「デジタルトランスフォーメーション戦略の一環として、より多くのイノベーションにつながるデータドリブンな文化を社内にもたらしたいと考えていました」と、AJE グループのグローバルデータ＆アナリティクス責任者である Wilmer Rodriguez Ruiz 氏は言います。 AJE は、Amazon Web Services （ AWS ）がこの 2 つの分野で最も適した候補であると判断しました。 「 AWS のソリューションを使うことで、ビジネスの成長戦略を促進し、組織内のパラダイムを変えることができます」と Rodriguez Ruiz 氏は言います。 Amazon Redshift を利用した企業データプラットフォームの構築 AJE は、組織全体のデータを保存、処理、分析するためのデータ分析ソリューションを AWS 上に構築しました。 同社は、 AWS Database Migration Service （ AWS DMS ）を使用して、複数の SQL データベースを AWS に移行しました。 DMS はデータ移行とレプリケーションのためのマネージドサービスで、これを使うことでデータベースと分析ワークロードを素早く安全に、かつ最小限のダウンタイムで、そして実質データロスなしに AWS に移行することができます。 同社はデータウェアハウスとして、 Amazon Redshift を使用しており、 SQL を使用してデータウェアハウス、オペレーショナルデータベース、データレイク全体の構造化データおよび半構造化データを分析しています。 Amazon Redshift は現在、同社のデータの単一かつ真のデータソースとなっています。 さらに、 Amazon Redshift はマネージドサービスであるため、AJE は SQL サーバーのために行わなければならなかった差別化につながらない重労働を減らすことができました。 「私たちのチームは、一般的なデータセンターを管理する必要がなくなり、生産性が向上しました。 当社のソリューションは、キャパシティニーズを満たすために、機能を拡張したり、新しいインスタンスを作成したりするだけです。」 AJE Group は、データ抽出のために AWS Glue を使用しています。これは、複数のソースからデータの発見、準備、移動、統合を簡単にするサーバーレスデータ統合サービスです。 AWS Glue は、業界をリードするスケーラビリティ、データの可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスである Amazon Simple Storage Service ( Amazon S3 ) からデータを取得し、Amazon Redshift での分析のためにデータを変換します。 AWS 上に新しい企業データプラットフォームを実装して以来、同社は抽出、変換、ロード（ ETL ）にかかる時間を 35% 短縮しました。 イノベーションのためのデータ可視性の拡大 AJE グループは現在、データレイクを構築するために AWS を利用しており、データソリューションとアナリティクスの両方の拡張を支えています。 グローバル市場に広がる多くの膨大な従業員を抱える組織にとって、中央データソースは職場文化におけるデータ中心の考え方を促進するために不可欠です。「私たちは、データドリブンの戦略を社内に定着させたいと考えています。 データレイクは、すべての意思決定がデータに基づいて行われるように、すべての組織のすべてのレベルに到達するのに役立ちます。」 と Rodriguez Ruiz 氏は言います。 使えるデータがあったとしても、そのデータから洞察や分析を引き出せる従業員がいて初めて生産性に繋がります。 AJE は、AWS を使ってデータプラットフォームを構築すると同時に、従業員にデータリテラシーを身につけさせ、定量的なツールをビジネス戦略に適用できるようにすることにも注力してきました。 「現在、データの分析と取扱に精通した 600 人以上の従業員の育成に成功しています。今後 1 年半のうちに、この数を 3 倍に増やし、組織内のあらゆる階層に行き渡らせたいと考えています」と Rodriguez Ruiz 氏は言います。 AJE のデジタルトランスフォーメーションは、日常業務、特に全部門にわたるデータの可視化において、すでに成果を上げています。 以前は、社内チームが必要なデータにアクセスするのに 4 ～ 5 時間待たなければなりませんでした。 今では、そのデータがほぼリアルタイムで届くため、社内チームはデータに基づいた迅速な意思決定を行えるようになりました。 また、AJE のビジネスアナリストは、コンサルテーションや費用対効果分析をより迅速に完了できるようになりました。 「私たちは、組織全体が自立するために必要なデータの可用性を実現しました。すべての部門が、会社のビジョンを達成するために最適な意思決定をするための情報を持っています。」と Rodriguez Ruiz 氏は言います。 AWS を使うことで、AJE は新しい市場に進出するためのスケーラビリティも向上しました。「クラウドを利用することで、プロセスの拡張が格段に速くなりました。これにより、ビジネスニーズに応じて他の国でも成長できるチャンスが広がりました。」と Rodriguez Ruiz 氏は言います。 データドリブンな未来への投資 デジタルトランスフォーメーションが進む中、AJE グループはビジネスを拡大するための革新的な方法を模索し続けています。 同社は現在も、従業員にデータ中心の文化を浸透させ、新たな機会を探るための分析ツールの使用を推進しています。 AI / ML の普及に伴い、AJE グループは独自のアナリティクスサービスソリューションの構築を計画しています。 「AWS を利用することで、データ分析における従業員の能力を向上させることができました。セルフサービスで予測分析や情報を提供できるようになるチャンスがあります。」と Rodriguez Ruiz 氏は言います。 詳しくは、 AJE グループのお客様事例 をご覧ください。 Kate Wiley Kate Wiley は、AWS の小売業界マーケティング責任者。 AWS 入社以前は、Dick’s Sporting Goods 、 Reebok 、 Drybar 、 Jenny Craig などの小売企業でマーケティングを担当。 Kate は、小売業界のマーケティング責任者として、クラウドを活用してブランドと消費者の緊密な関係を築き、オペレーションを最適化し、AWS を活用してデジタルトランスフォーメーションを加速させる方法について、小売業者のサポートと教育を担当しています。 翻訳は Solutions Architect 圓山が担当しました。原文は こちら です。

AWS re:Invent 2024 は、世界中から集まった参加者にとってイベント盛りだくさんの1週間となりました。カンファレンスの期間中、様々な業界のお客様が中心となり、自社の変革の道のりを共有しました。これらのストーリーは、組織がどのようにクラウドとAIを活用してカスタマーエクスペリエンス戦略を変革し、大きなビジネス成果を達成しているかを浮き彫りにしています。 Amazon Connect はまた、AI のパワーを活用し、オムニチャネル機能を強化する新機能の数々を発表しました。 注目のビジネスインパクト State Farm, Toyota, Air Canada, Coinbase, Amazon Customer Service, Frontdoor, Fujitsu, Pearson, NatWest などのお客様がステージに上がり、ストーリーを共有しました。これらのストーリーは、世界をリードする組織のいくつかが Amazon Connect を活用してビジネスを加速している様子を示しています。プレゼンテーションの動画を視聴するには、以下の各企業のリンクをクリックしてください。 イノベーショントーク: カスタマーサービスのための生成 AI State Farm は、イノベーションの文化に基づいたアプローチでコンタクトセンターを近代化する取り組みに乗り出しました。それぞれの段階から学び最適化した結果、セルフサービスの解決率が 0.5% から 30% 以上に向上し、転送率が大幅に低下した一方で、一次解決率 (FCR) と顧客満足度スコアが向上しました。State Farm は、常にお客様が最善の事態に備え、最悪の事態から立ち直れるよう支援するという使命のもと、生成 AI と予測機能を模索しながら革新を続けています。 オムニチャネル体験とセルフサービスの提供 Air Canada は、旅客や貨物を含む事業分野全体で セルフサービス体験 をどのように革新しているかを紹介しました。 Coinbase は、Amazon Connect を使用してコンタクトセンター業務を迅速に変革し、それまで別々だった電話ベンダーとチャットベンダーを単一の統合 オムニチャネル ソリューションに統合したことを概説しました。 エージェントの生産性向上 Frontdoor はAmazon Connect に迅速に移行し、顧客待ち時間を半分に短縮し、さらにエージェントがよりパーソナライズされたサービスを提供するため生成 AI によって 生産性を向上させている 事について説明しました。 NatWest は、Amazon Q in Connect を使用することで顧客の意図の検出が改善され、エージェントがあらゆるやり取りにおいてよりパーソナライズされたカスタマーサービスを提供できるようになったことを強調しました。 分析、インサイト、最適化の活用 トヨタ は、Amazon Connect Contact Lens の 分析および最適化機能 を活用して、新たなテーマを検出し企業のリーダーが活用するインサイトを引き出す方法を紹介しました。 Fujitsu は、AI を活用した最適化機能を活用して、労働力と品質管理の効率化とコスト削減をどのように行っているかを明らかにしました。 Amazon から学ぶ Amazon Customer Service では、便利でパーソナライズされたカスタマーエクスペリエンスを提供するために、Amazon Connect を使用して年間数十億件もの顧客とのやり取りをサポートする方法について説明しました。また、生成 AI への投資によって世界中のカスタマーサービスがどのように強化されているかも紹介しました。 AWS パートナーとのイノベーション Pearson Clinical Assessments は、Amazon Connect と Salesforce Service Cloud Voice を使用して、音声、チャット、その他のデジタルチャネルにわたる対話を統合する統合ワークスペースをエージェントに提供している事を明らかにしました。 Amazon Connect の新しいイノベーション 効率化された設定と生成 AI でセルフサービス体験を強化 セルフサービスオプション は現代のカスタマーサービス戦略の重要な要素であり、顧客が自分で解決策を見つけられるようにすると同時に、サポートコストを削減し、全体的な満足度を高めます。Amazon Connect は、コンタクトセンターにおける セルフサービス体験 の簡素化と強化を目的とした一連の新機能を発表しました。生成 AI、合理化されたセルフサービス設定、改善された分析を活用して、より効率的で効果的な顧客インタラクションを実現します。 Amazon Connect が Amazon Q in Connect で生成 AI を活用したセルフサービスを開始 Amazon Connect がシンプルな会話型 AI ボットの作成を提供 Amazon Connect Contact Lens が会話型 AI ボットのパフォーマンスを分析するための組み込みダッシュボードをリリース Amazon Connect で IVR およびその他の自動対話中の音声が録音可能に プロアクティブなアプローチをパーソナライズし、チャネルサポートを拡大 現代の顧客は、好みのチャネルでのシームレスなやり取りを期待しています。先進的な企業は顧客のニーズを予測し、パーソナライズされたアプローチを通じて関係性を築く方法を模索しています。同時に、これらのソリューションは複数のコミュニケーションチャネルを統一されたワークスペースに統合し、エージェントがさまざまなアプリケーション間を行き来する必要性をなくし、合理的かつ効率的なワークフローを提供することでエージェントエクスペリエンスを変革しています。 Amazon Connect が顧客セグメントとトリガーベースのキャンペーン向けの AI アシスタントをリリース Amazon Connect が WhatsApp Business メッセージングのサポートを開始 Amazon Connect では、チャット内で重要な顧客データを簡単に収集できるようになりました AWS が Amazon Connect での Salesforce Contact Center を発表 (プレビュー) AI を活用した分析と予測でコンタクトセンターのパフォーマンスを最適化 コンタクトセンターは 分析 を活用して、カスタマーエクスペリエンスとオペレーション効率に革命をもたらしています。今や、顧客の行動を理解し、エージェントのパフォーマンスを最適化し、業務をリアルタイムで合理化するには、高度な分析が不可欠です。AI を使用することで、企業は顧客とのやり取りから深いインサイトを引き出し、将来の傾向を予測し、進化する顧客ニーズに合わせてプロアクティブに対策することができます。Amazon Connect は、現代のコンタクトセンターにおける分析の重要な役割を認識し、カスタマーサービス組織がデータからより多くのインサイトを引き出し、予測の精度を向上させ、カスタマーサービス業務のあらゆる面で継続的な改善を推進しやすくなる機能を導入しました。 Amazon Connect Contact Lens がエージェントのパフォーマンス評価を生成 AI を使用して自動化 Amazon Connect Contact Lens が生成 AI を使用してコンタクトを自動的に分類 Amazon Connect が新しい日中予測ダッシュボードを発表 将来を見据えた取り組み 企業はクラウド、AI、分析を活用してカスタマーサービスを向上させる絶好の機会を迎えています。私たちは、これらの最新機能によって、企業がカスタマーサービス体験とコンタクトセンター運営をどのように再構築し、改革していくかを目の当たりにできることを嬉しく思います。Amazon Connect の詳細については、 ウェブページ をご覧ください。 Amazon Connect でカスタマーサービス体験を変革する準備はできましたか？ お問い合わせください。 翻訳はシニア Amazon Connect ソリューションアーキテクト清水が担当しました。原文は こちら です。

今日のデジタルファースト社会において、企業は効率的かつコスト効果の高い顧客サービスを提供するため、チャットによるコミュニケーションへの依存度を高めています。一般的なカスタマーサービスのシナリオの多くでは、支払い処理や配送先住所の更新、本人確認、アカウント詳細へのアクセスなど、機密情報の収集が必要となります。しかし、 PCI DSS 、GDPR、 CCPA などの規制に準拠しながら、このようなデータを安全に収集することは、特にチャットチャネルにおいて課題となってきました。なぜなら、機密情報が会話記録、コンタクト記録、またはログに露出する可能性があるためです。 例えば、顧客がオンライン小売店の自動応答アシスタントと、近日中の配送に関する住所変更について会話するケースを考えてみましょう。自動応答アシスタントは、顧客に対して別のウェブページにログインして変更を行うよう指示する必要があり、これは会話の流れを中断し、断片的な体験を生み出してしまいます。あるいは、顧客がチャットでの対応中に月々の請求書の支払いを希望するケースを想像してください。チャット上でクレジットカード情報を安全に収集する方法がない場合、音声通話や支払いポータルへの転送が必要となり、対応時間の長期化や顧客の不満につながる可能性があります。 Amazon Connect は、チャットのやり取りにおける機密データ収集機能により、これらの課題に対するソリューションを提供します。ノーコード UI ビルダーを使用して、企業はチャット内で直接顧客の機密情報を収集するフォームを作成できます。このソリューションは、機密データがチャットトランスクリプトや問い合わせ記録に記録されないようにしながら、支払いの処理、顧客プロフィールの更新、その他の重要な取引のためにバックエンドシステムへの安全な送信を可能にします。 このシームレスなアプローチにより、顧客体験を損なうことなく、セキュリティを維持し、PCI に準拠したアーキテクチャを構築することが可能になります。フォームは会話中に文脈に応じて起動でき、機密データは通常のチャットログや保存から除外されながら、目的のシステムに直接送信されます。以下のような一般的なユースケースへの統合を考えてみましょう： 購入や請求書支払いのための支払い情報収集 アカウント更新のための配送先/請求先住所収集 検索のためのアカウント番号や識別子の取得 機密性の高い個人情報収集による本人確認 このブログでは、 Amazon Connect Chat での機密データ収集の実装方法を探り、機密情報のコンプライアンスに準拠した取り扱いを可能にするアーキテクチャを検証し、一般的なユースケースの実装例を順を追って説明します。ノーコードの UI ビルダーを使用してフォームを作成し、それらをチャットフローに統合して、シームレスかつ安全な顧客体験を実現する方法を学んでいただけます。 アーキテクチャの概要 Amazon Connect Chat のセキュアなデータ収集機能は、セキュリティとユーザー体験の両方を重視したアーキテクチャを採用しています。このソリューションの核心部分では、機密データ処理に特化したセキュリティ制御を強化した Amazon Connect のステップバイステップガイドを使用しています。 チャット内でセキュアなデータ収集を有効にするには、以下の2つのフェーズがあります： 1. フォームの作成と設定 フォームは Amazon Connect のノーコード UI ビルダーを使用して作成 フォームは「ビューを表示」ブロックを使用してコンタクトフロー内で設定 「このビューには機密データがあります」オプションを有効にして、安全な処理を開始 2. ランタイムフロー セルフサービスチャットがビューを使用する際、フォームやその他の設定済みガイドコンポーネントが顧客のチャットインターフェースに表示 顧客が入力したデータは転送中に暗号化 機密情報は通常のチャット処理をバイパス AWS Lambda 関数がバックエンド統合のためにデータを安全に処理 セキュリティ責任に関する注意事項 Amazon Connect は機密データを保護するための安全なインフラストラクチャとツールを提供していますが、お客様はセキュリティ要件に従ってこれらの機能を適切に設定し実装する責任を引き続き負っています。これは AWS の 責任共有モデル に従っています – AWS はクラウドインフラストラクチャのセキュリティを確保しますが、安全なフォームの適切な設定、ログ管理、データ処理手順を含む、クラウド「内」のセキュリティはお客様の責任となります。機密データを扱うソリューションを実装する際は、常にセキュリティチームとコンプライアンスチームに相談してください。 Amazon Connect のステップバイステップガイドとフローを活用することで、以下のことが可能になります： ノーコード UI ビルダーで安全なフォームを構築： 簡単にフォームを作成できるドラッグ＆ドロップインターフェース 様々なデータタイプ（クレジットカード番号、社会保障番号、住所など）に対応したカスタマイズ可能なフィールド データの正確性を確保する組み込みの検証ルール カスタムブランディングとスタイリングの追加が可能 機密データの安全な取り扱い： 機密データの保存やログ記録を行わない データはアクティブセッション中のメモリ内でのみ利用可能 必要に応じて AWS Lambda と連携して安全な処理を実行 各チャットセッション終了時に自動的にデータを消去 コンプライアンスの維持： データの分離により不正アクセスを防止 データの暗号化と安全な送信 データ収集に関する詳細な制御 データ処理とセキュリティ この機能は、機密データを保護するために複数のセキュリティレイヤーを実装しています： ゼロ永続化 ：デフォルトでは、機密データはログ、トランスクリプト、またはコンタクト記録に一切書き込まれません 安全な転送 ：すべてのデータは TLS 1.2 以上を使用して転送中に暗号化されます アクセス制御 ：認可された Lambda 関数のみが機密データにアクセスできます 自動クリーンアップ ：データは処理後またはセッション終了時に自動的に削除されます この機能はコンプライアンスに必要な技術的な管理を提供しますが、組織は常にコンプライアンスチームと法務チームに相談し、特定の実装が適用されるすべての要件を満たしていることを確認することが望ましいです。 このセキュアなデータ収集アーキテクチャにより、企業はセキュリティとコンプライアンスを維持しながら、自信を持って機密情報を収集することができます。次のセクションでは、一般的なシナリオにおける具体的なユースケースと実装例を探っていきます。 セキュアなデータ収集の主要なユースケース 一般的なカスタマーサービスのシナリオにおけるセキュアなデータ収集の実装方法を探ってみましょう。各ユースケースには、セキュリティとコンプライアンスを維持しながら、素早く開始できるようにするためのサンプル設定とベストプラクティスが含まれています。 セキュアな支払い処理 最も一般的なニーズの1つは、チャットでのやり取り中にクレジットカード情報を安全に収集することです。これにより、顧客はチャネルを切り替えることなく、支払いの実行、返金の処理、または支払い方法の更新を行うことができます。 プロファイル情報の更新 チャットでのやり取り中に顧客が個人情報を安全に更新できるようにすることで、プライバシーを維持しながらデータの正確性を向上させることができます。この情報は、 Amazon Connect Customer Profiles の更新や、他のバックエンドシステムに保存されている情報の更新に使用できます。 アカウント検索と本人確認 アカウント番号を安全に収集することで、機密性の高い識別子を保護しながら、効率的な顧客確認とアカウント管理が可能になります。本人確認のための機密性の高い個人情報の収集には、使いやすさを維持しながら追加のセキュリティ対策が必要です。 ユースケースに応じて、必要なセキュリティとコンプライアンスを維持しながら、類似または異なるビューを作成することができます。フォームは顧客の意図に基づいて文脈に応じてトリガーされ、チャットでのやり取りの中でシームレスな体験を提供します。 これらの実装は、スムーズな顧客体験を維持しながら、セキュアなデータ収集の基盤を提供します。次のセクションでは、これらのソリューションを Amazon Connect インスタンスにデプロイするためのプロセスを説明します。 ノーコード U I ビルダーを使用したセキュアなフォームの作成 Amazon Connect のノーコード UI ビルダーを使用すると、セキュアなデータ収集フォームを簡単に作成できます。以下が機密情報を保護するフォームの作成方法です： 1. UI ビルダーへのアクセス ルーティング → フロー → ビューに移動 既存のビューを開くか、 ビューを作成 を選択してステップバイステップガイドのノーコード UI ビルダーにアクセス 2. フォームフィールドの設定 Payment テンプレートを選択すると、クレジットカードや住所情報の収集方法の例をすぐに確認できます または、コンポーネントライブラリから必要なデータ（クレジットカードフィールド、住所フィールドなど）の入力フィールドを追加できます ビューの設定が完了したら、フロー内で使用できるように 公開 を選択します 3. フローモジュールの作成 すでに顧客向けのチャットガイドフローが設定されている場合は、それを活用して新しく作成したビューを連携することができます それ以外の場合は、ルーティング → フロー → モジュールに移動し、 フローモジュールを作成 を選択します モジュールの開始時に 「ログ記録動作の設定」 ブロックを追加し、ログ記録を 無効化 します 「ビューを表示」 ブロックを追加し、先ほど作成したビューを選択します 4. 機密データ処理の有効化 「ビューを表示」ブロックの設定で、 このビューには機密データがあります を有効化します エラー処理とタイムアウトの動作を設定します 5. Lambda 統合のセットアップ Amazon Connect 外でデータを処理する必要がある場合は、新しい AWS Lambda 関数を作成します Lambda 関数をインスタンスに関連付け、使用中のコンタクトフローに追加します 「ビューを表示」ブロックの出力を、収集したデータを処理する Lambda 関数に接続します 6. フロー設定の完了 Lambda 関数の処理が完了したら、 「ログ記録の動作の設定」 ブロックでログ記録を再度有効化します モジュールの最後に 「戻る」ブロックを追加して、元々のフロー体験を続けます モジュールに関する注意事項 安全なデータ処理のために再利用可能なフローモジュールを作成してください。モジュールに安全なデータ収集パターンをカプセル化することで、一貫したセキュリティ対策を維持し、複数のコンタクトフロー間で開発時間を節約することができます。 実際の動作を見る Amazon Connect Chat でのセキュアなデータ収集の仕組みをデモンストレーションでご覧ください。このビデオでは、顧客がチャットでのやり取り中に支払い情報を更新する必要がある実際のシナリオをご紹介します。安全なフォームがチャット体験にシームレスに統合され、顧客が安全にクレジットカード情報を入力できる様子をご覧いただけます。 このデモンストレーションは、企業がスムーズで中断のない顧客体験を提供しながら、セキュリティとコンプライアンスを維持できる方法を強調しています。機密データがチャット記録やエージェントのビューに表示されることはありませんが、チャットチャネル内で効率的に取引を完了できることに注目してください。 結論 企業が機密データを保護しながらシームレスな顧客体験の提供を目指す中、Amazon Connect Chat のセキュアなデータ収集機能は、セキュリティ、コンプライアンス、およびユーザー体験のバランスを取る強力なソリューションを提供します。チャットでのやり取り中に直接安全なフォーム収集を可能にすることで、組織は以前は断片的だったプロセスを、顧客の信頼を構築し運用効率を向上させる、スムーズで安全な会話に変えることができます。 シームレスなデジタル体験に対する顧客の期待が高まり続ける中、チャットでのやり取りの中で機密データをセキュアに扱う能力がますます重要になっています。Amazon Connect のセキュアなデータ収集機能は、現代のビジネスに必要なセキュリティとコンプライアンスの管理を維持しながら、信頼できる顧客体験を構築するための基盤を提供します。 これらの機能を実装することで、組織は以下のことが可能になります： デジタルカスタマーサービス業務を自信を持って拡大 セキュリティ要件の変化に迅速に適応 セキュリティを損なうことなく顧客体験を革新 サービス品質を向上させながらコストを削減 カスタマーサービスの未来には、セキュリティとシームレスさの両方が求められます – Amazon Connect のセキュアなデータ収集機能により、その未来は今日、手の届くところにあります。 入門リソース ステップバイステップガイドについてもっと学びたいですか？ ステップバイステップガイドの YouTube プレイリスト の動画をご覧いただき、始め方をご確認ください。 Amazon Connect で最初のステップバイステップガイドの構築を始めたいですか？ この ステップバイステップガイドワークショップ に従って、パーソナライズされた、動的で文脈に応じた体験を提供するためにAmazon Connect 属性と連携するサンプルガイドの構築、デプロイ、テスト方法について詳しく学んでください。 ステップバイステップガイドについて深く掘り下げたいですか？ Amazon Connect 管理者ガイドで詳細をご確認ください。 翻訳はソリューションアーキテクト 新谷 が担当しました。原文は こちら です。

イントロダクション マイクロサービスアーキテクチャをクラウドで実行することは、すぐに複雑な運用になる可能性があります。個々のワークロードにおける複数のインスタンスのような増え続ける変動要素を、インフラストラクチャの依存関係と合わせて考慮する必要があります。その上、これらの要素は、複数の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスや、 アベイラビリティーゾーン (AZ) 、AWS リージョンなど、さまざまなトポロジードメインに分散されている場合があります。Kubernetes は、前述のトポロジーに基づいてコンテナのワークロードとインフラストラクチャを自動的にデプロイすることで、これらの環境の構築と管理に伴う運用上の負担をいくらか軽減します。ただし、これらの環境は規模、複雑さ、ネットワークへの依存性があるため、ある時点でアーキテクチャ全体の一部分が機能低下した状態または障害状態になることは避けられません。そのため、チームは実行時の Kubernetes アプリケーションとインフラストラクチャーの状態を把握することで Design for Failure を実践し、ワークロードの可用性を危険にさらす予期しないイベントに迅速に適応して回復できるように構築する必要があります。 アプリケーションとインフラストラクチャの両方におけるベストプラクティスであり共通的なアプローチは、冗長性を確保し、単一障害点を防ぐことです。単一障害点をなくすために、複数のアベイラビリティーゾーンにまたがる Amazon Elastic Kubernetes Service (Amazon EKS) に高可用性アプリケーションをデプロイするお客様が増えています。ただし、アプリケーションとインフラストラクチャの冗長性は、最良の結果を得るために 適用すべき複数ある戦略 の ひとつにすぎません。特定の耐障害性あるいは障害の設計メカニズムを適用するかどうか、またそれらをどのように適用するかは、アプリケーションの目標復旧時間目標 (RTO) と目標復旧時点 (RPO) によって異なります。アプリケーションによっては、ダウンタイム要件が最小限またはゼロのクリティカルな性質のものもあれば、この型にはまらないものもあります。 障害または劣化の範囲は、さまざまなレベルで発生する可能性があります。Amazon EKS 環境では、1 つのワーカーノード、一部のワーカーノード、または AZ 全体に問題が発生することがあります。AZ の障害が発生した場合は、回復力と復旧戦略の一環として Amazon Application Recovery Controller (ARC) のゾーンシフト を使用できます。ARC ゾーンシフトを使用すると、クラスター内のネットワークトラフィックを、影響を受けた AZ から一時的にリダイレクトできます。ただし、ゾーンシフトのプロセスを適切に管理するには、AZ 障害を検出するための十分なモニタリングを実施する必要があります。 あるいは、 ゾーンオートシフト を使用してこれを管理することを AWS に許可することもできます。ゾーンオートシフトでは、AWS がお客様の AZ の全体的な状態を監視し、潜在的な障害が発生した場合は、お客様に代わってクラスター環境内の障害が発生した AZ からトラフィックを自動的に移動させることで対応します。また、その AZ が正常な状態に戻ったときに、その AZ へのクラスター内トラフィックの復元も AWS が管理します。 現在、多くのお客様が Istio などのサービスメッシュ実装を使用して、アプリケーション環境におけるネットワークインフラストラクチャを管理しています。Istio はシステムのネットワークオブザーバビリティの向上に役立ちます。そのデータプレーンプロキシは、特定の AZ の問題など、さまざまな問題を示すネットワークリクエストやマイクロサービスインタラクションに関連する主要なメトリクスを公開するためです。この投稿では、ゾーンシフトを管理するためのシグナルとして Istio のメトリクスを利用し、AZ における異常または劣化が発生した際に、アプリケーションの迅速な復旧を監視および自動化する方法に焦点を当てています。この記事で紹介するソリューションは、すでに Istio を Amazon EKS 環境に導入しているチームにとって最適です。別の方法として、チームはカスタムメトリクスをログデータに埋め込むことができる Amazon CloudWatch とその 埋め込みメトリクス形式 (EMF) の使用を検討することもできます。 ソリューション概要 このチュートリアルでは、EKS で複数の AZ にサンプルアプリケーションをデプロイします。このアプリケーションは サイドカーモード で動作する Istio サービスメッシュの一部です。つまり、各 Pod にはコンテナアプリケーションと Istio サイドカープロキシ (Envoy) の両方が含まれます。サイドカープロキシは、アプリケーションへのインバウンド通信とアウトバウンド通信を仲介します。すべての AZ の状態を判断するには、これらのアプリケーションサイドカープロキシによってキャプチャされたリクエストに対するネットワーク応答 (2xx や 5xx など) を AZ レベルで継続的に評価します。そのために、Prometheus を使用してこれらのサイドカープロキシの Envoy クラスターを監視します。ここで使用するメトリクスは envoy_cluster_zone_availability_zone__upstream_rq です。わかりやすく言うと、Envoy クラスター (EKS クラスターと混同しないでください) とは、特定のアプリケーションのトラフィックを受け入れる類似したアップストリームホストのグループを指します。さらに、Grafana は各 AZ のデータを可視化し、問題が発生した場合には Slack チャンネルにアラートを送信するためにも使用されます。最後に、Amazon EKS で ARC ゾーンシフトを作動させて、アプリケーションの復旧をテストします。この例では 、AZ ヘルスモニタリング用の 1 つのシグナルに焦点を当てていますが、本番環境で マルチ AZ 環境を監視する 場合、環境全体と AZ の健全性と状態をよりよく把握するために、レイテンシー、(トラフィックを受信していない) サイレント障害、 グレー障害 、定期的な障害など、さまざまなタイプの問題や障害も考慮する必要があります。 Envoy が公開しているクラスター統計のリスト を参照できます。 以下の図は、この記事で説明するアプリケーション環境を示しています。 前述したように、このソリューションでは、AZ 内の Pod からの全体的なネットワーク応答を一定の間隔で使用して、AZ が正常かどうかを示します。次の図は、AZ が正常と見なされるクラスターを示しています。 次の図は、一定期間において、AZ ごとの Pod ネットワークにおけるリクエストで発生したサーバー側のエラーの数に基づいて、異常と見なされる AZ (af-south-1c) を示しています。 次の図は、ARC ゾーンシフトを開始して迅速に回復し、Amazon EKS 環境の変化に適応することで、影響を受けた AZ を一時的に隔離し、east-to-west または north-to-southトラフィックを受信しないようにする方法を示しています。Amazon EKS で ARC ゾーンシフトを開始すると、 EndpointSlice コントローラー は正常でない AZ の Pod エンドポイントを EndpointSlice から削除します。しかし、これを Istio のサービスディスカバリーにどう結び付けるのでしょうか。 Istioのサイドカープロキシは、 xDS API と呼ばれるサービスディスカバリーAPIのセットを使用します。xDS API の 1 つが エンドポイント検出サービス (EDS) API です。これにより、上流の Envoy クラスターのメンバー (エンドポイント) を自動的に検出できます。ゾーンシフト中、検出可能なエンドポイント (上流の Envoy クラスターのメンバー) のリストは、クラスターの正常な AZ で実行されているものだけです。ゾーンシフト中も、 宛先ルール を使用して Istio ネットワークポリシーを適用できます。 準備 このサンプルを実行するには、以下の前提条件を満たす必要があります。 AWS アカウント 複数の AZ にプロビジョニングされた EKS クラスター (v 1.28 以上) EKS クラスターでの ARC ゾーンシフト有効化 Istio (サイドカーモード) のインストール オブザーバビリティのため kube-prometheus を用いた Prometheus と Grafana のインストール（または、 このガイド を使用して Amazon Managed Prometheus と Amazon Managed Grafana をセットアップすることもできます） Slack での 受信ウェブフックの設定 （このステップでは、無料の Slack アカウントを使用できます） デモンストレーション 以下の手順で、このソリューションについて説明していきます。 サンプルアプリケーション用の Istio ネットワークの設定 まず、関連する Istio リソースを設定してデプロイし、サンプルアプリケーションが外部からのネットワークリクエストを受信できるようにします。そのためには、まず Istio Ingress ゲートウェイを設定する必要があります。Ingress ゲートウェイはサービスメッシュへのエントリポイントであり、メッシュ内のワークロードを保護し、メッシュに流入するトラフィックを制御する役割を果たします。Istio Ingress ゲートウェイは、開くポートとそれに関連する仮想ホストを指定するゲートウェイリソースを作成することで設定できます。 ゲートウェイ apiVersion: networking.istio.io/v1 kind: Gateway metadata: name: ecommerce-gateway namespace: ecommerce spec: selector: istio: ingressgateway # use istio default controller servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"   ネットワークトラフィックが Ingress ゲートウェイを経由してサービスメッシュに入ったら、正しい宛先にルーティングする必要があります。このルーティングプロセスの管理は VirtualService リソースが行います。 Virtual Service apiVersion: networking.istio.io/v1 kind: VirtualService metadata: name: payments-virtualservice namespace: ecommerce spec: hosts: - "*" gateways: - ecommerce-gateway http: - match: - uri: prefix: /v1/payments route: - destination: host: payments-service port: number: 3005 retries: attempts: 3 perTryTimeout: 2s 次のステップでは、サンプルアプリケーションをデプロイします。 複数の Pod レプリカを実行して AZ 間に分散させる アプリケーションの複数のインスタンスを実行し、それを複数の AZ に分散させると、耐障害性と可用性の両方が向上します。 トポロジー分散の制約 を使用すると、アプリケーションが事前に静的安定性を持つように設定できます。これにより、AZ に障害が発生した場合でも、トラフィックの急増や急増が発生しても直ちに対処できる十分な数のレプリカが正常な AZ に保持されます。 最初のステップとして、アプリケーションインスタンスを配置する ecommerce 名前空間を作成します。その後、名前空間に適切なラベルを付けて、その名前空間内で実行されるすべてのアプリケーションにサイドカープロキシを挿入することを Istio が認識できるようにする必要があります。 kubectl create ns ecommerce kubectl label namespace ecommerce istio-injection=enabled これらのステップを完了すると、次のコードを使用してサンプルの支払いアプリケーションをデプロイできます。最適に分散 (またはレプリカを分布) させるには、他のレプリカがすでに起動して実行されてからアプリケーションを段階的にスケーリングする必要があります。これにより、スケジューラは特定の AZ のワーカーノードで実行されているレプリカを確認して、ユーザーが定義したスケジューリング制約に従うようにすることができます。 apiVersion: v1 kind: ServiceAccount metadata: name: payments-service-account namespace: ecommerce --- apiVersion: v1 kind: Service metadata: name: payments-service namespace: ecommerce spec: selector: app: payments type: ClusterIP ports: - protocol: TCP port: 3005 targetPort: 3005 --- apiVersion: apps/v1 kind: Deployment metadata: name: payments namespace: ecommerce labels: app.kubernetes.io/version: "0.0.1" spec: replicas: 6 selector: matchLabels: app: payments workload: ecommerce template: metadata: labels: app: payments workload: ecommerce version: "0.0.1" spec: serviceAccountName: payments-service-account topologySpreadConstraints: - maxSkew: 1 topologyKey: "topology.kubernetes.io/zone" whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: payments containers: - name: payments-container image: "lukondefmwila/ecommerce-payments:0.0.1" readinessProbe: httpGet: path: /v1/payments port: 3005 initialDelaySeconds: 5 periodSeconds: 10 ports: - containerPort: 3005 resources: requests: cpu: "1" memory: "64Mi" 前述のリソースを適用すると、Pod がクラスターで期待どおりに実行されていることを確認できます。次のスクリーンショットは、 K9s を使用したビューを示しています。 アプリケーションをデプロイしたら、次のコマンドを入力して Istio Ingress ゲートウェイが認識している payments アップストリームクラスターを一覧表示することで、さまざまな AZ 間でのアプリケーションの分布を確認できます。結果には、Pod エンドポイントと、それらが存在する各 AZ が表示されます。 kubectl exec -it deploy/istio-ingressgateway -n istio-system -c istio-proxy \ -- curl localhost:15000/clusters | grep payments | grep zone 次に、アプリケーションが期待どおりに動作していることをテストします。 まず、Istio Ingress ゲートウェイのホスト名を取得し、そのホスト名に /v1/payments というパスを追加し、ターミナル、ブラウザ、または API クライアントツールで GET リクエストを実行します。 ISTIO_IGW_HOST=$(kubectl get svc --namespace istio-system istio-ingressgateway -o json | jq -r ".status.loadBalancer.ingress | .[].hostname") curl "http://$ISTIO_IGW_HOST/v1/payments" 次のスクリーンショットのような結果が表示されます。 Istio サイドカープロキシを監視するための Prometheus のセットアップ ソリューション概要で詳しく説明されているように、各ゾーンのアプリケーションサイドカープロキシによって処理されるアップストリームリクエストへの応答を評価することで、AZ の状態を判断します。そのためには、まず Istio サイドカープロキシを持つ Pod からメトリクスを取得するように Prometheus を設定する必要があります。 apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: envoy-stats-monitor namespace: prometheus labels: monitoring: istio-proxies release: prom spec: selector: matchExpressions: - {key: istio-prometheus-ignore, operator: DoesNotExist} namespaceSelector: any: true jobLabel: envoy-stats podMetricsEndpoints: - path: /stats/prometheus interval: 15s relabelings: - action: keep sourceLabels: [__meta_kubernetes_pod_container_name] regex: "istio-proxy" - action: keep sourceLabels: [ __meta_kubernetes_pod_annotationpresent_prometheus_io_scrape] - sourceLabels: [ __address__, __meta_kubernetes_pod_annotation_prometheus_io_port] action: replace regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2 targetLabel: __address__ - action: labeldrop regex: "__meta_kubernetes_pod_label_(.+)" - sourceLabels: [__meta_kubernetes_namespace] action: replace targetLabel: namespace - sourceLabels: [__meta_kubernetes_pod_name] action: replace targetLabel: pod_name --- apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: istio-component-monitor namespace: prometheus labels: monitoring: istio-components release: prom spec: jobLabel: istio targetLabels: [app] selector: matchExpressions: - {key: istio, operator: In, values: [pilot]} namespaceSelector: any: true endpoints: - port: http-monitoring interval: 15s 前述のリソースを適用したら、次のコマンドを実行して Prometheus ダッシュボードにアクセスできます。 kubectl -n prometheus port-forward statefulset/prometheus-prom-kube-prometheus-stack-prometheus 9090 次に、Prometheus でメトリクスを確認できるように、サンプルアプリケーションのトラフィックを生成する必要があります。そのためには、ターミナルで以下のコマンドを実行します。これにより、支払いアプリケーションに 150 回の GET リクエストが入力されます。クエリの総数は必要に応じて調整できます。 for i in {1..150}; do curl <insert-your-instio-ingressgateway-hostname>/v1/payments; sleep .5s; done その後、Prometheusダッシュボードを再度開き、次のスクリーンショットに示すように、特定のAZのEnvoyクラスターのメトリクス結果を検索できます。 af-south-1a –  envoy_cluster_zone_af_south_1a__upstream_rq af-south-1b –  envoy_cluster_zone_af_south_1b__upstream_rq af-south-1c –  envoy_cluster_zone_af_south_1c__upstream_rq Grafana ダッシュボードの作成 次に、Grafana でダッシュボードを作成し、関連データをより整理された形式で視覚化します。作成される Grafana パネルのデータソースとして Prometheus を使用します。 ブラウザで Grafana にアクセスするには、次のコマンドを実行します。 kubectl -n prometheus port-forward svc/prom-grafana 3000:80 kube-prometheus でオブザーバビリティスタックをインストールしてから初めて Grafana を起動する場合は、admin ユーザーを使用し、次のコマンドを使用してパスワードを取得できます。 kubectl get secret prom-grafana -n prometheus -o jsonpath="{.data.admin-password}" | base64 --decode ; echo 認証情報を取得したら、Grafana にログインします。デフォルトでは、kube-prometheus には Grafana インストールのデータソースとして Prometheus と Alertmanager があらかじめ設定されています。ただし、Prometheus をデータソースとして設定する必要がある場合は、以下の手順に従うことができます。 左側のメニューで [接続] を選択 [接続] で [新しい接続を追加] を選択 検索バーに「プロメテウス」と入力 表示されたものを選択 右上の [新しいデータソースを追加] を選択 データソースを設定するには、次のスクリーンショットに示すように、接続の名前を入力し、Prometheus サーバーの URL を入力する必要があります。 kube-prometheus の Prometheus サーバー URL は ” http://prom-kube-prometheus-stack-prometheus.prometheus:9090/ ” です。 Prometheus データソースへ正常に接続できたら、Grafana でダッシュボードを作成できます。ダッシュボードに追加する各パネルは、前のセクションと同じメトリクス (envoy_cluster_zone_af_south_1a__upstream_rq など) を使用する EKS クラスターの AZ を表しています。次のスクリーンショットのように、クラスター内の AZ ごとにこのステップを繰り返します。 このプロセスを完了すると、パネル構成によっては、次のスクリーンショットのようなものが表示されるはずです。 EKS クラスター内の AZ 用に Grafana アラートを設定する このセクションでは、Grafana アラートの設定に焦点を当てます。ここまでの手順により、ある AZ における Pod からのネットワーク応答に基づいて対象の AZ の状態を監視できるように EKS クラスター環境が設定されました。ただし、アラートのルールを定義する際には、次の点を考慮する必要があります。 何をもって AZ で問題が発生していると見なすか？ 問題が発生した場合、誰に通知すべきか？ 通知はどのように行われるか？ この例では、特定の AZ 内でサーバー側のエラーが急増している場合、その AZ に何か問題が起きているという兆候であるとします。レイテンシーや、リクエストのタイムアウト、接続障害など、他の指標を使用することもできます。ダッシュボードパネルで行ったように、AZ ごとにアラートルールを作成する必要があります。 まず、 Alert Rules の欄で、次のスクリーンショットのように、直近の 30 分（30分前から現在まで）のデータを使用するようにアラートルールを設定します。次に、各 AZ のサーバー側のエラー (5xx) を追跡できるルールを設定できます。 envoy_cluster_zone_af_south_1a__upstream_rq{response_code_class=”5xx”} その後、設定した条件を Grafana に評価させる頻度を設定し、通知ポリシーのアラートにラベルを割り当てます。 次に、 Contact Point の欄でアラート通知を受け取るSlackチャンネルの連絡先を設定し、次のスクリーンショットのように期待どおりに機能することをテストします。 最後に、 Notification Policy の欄で、次のスクリーンショットに示すように、各ルールに追加したラベルに基づいてGrafanaがアラートを適切な連絡先と照合できるようにポリシーを作成します。 アラート通知システムが期待どおりに機能していることをテストするには、いずれかの AZ (この例では af-south-1c) のアラート条件を変更して、リクエストが正常に送信されたとき (response_code_class= ”2xx” ) に Grafana が代わりに通知できるようにします。さらに、結果を確認するために長時間待たなくても済むように、評価間隔を短くすることもできます。 そのためには、アラートルールのメトリックスとラベルフィルターを更新して、アラートをテストしたい AZ の条件を以下のように設定します。 envoy_cluster_zone_af_south_1c__upstream_rq{response_code_class=”2xx”} その後、テスト目的でカウントのしきい値を減らし、アラートルールの評価間隔を更新できます。Grafana でプレビューを選択すると、どの値がアラートを発するか確認できます。次のスクリーンショットは、アラートルールのプレビュー例を示しています。 アラートルール設定を保存したら、次のスクリーンショットに示すように、アプリケーションに多数のクエリを入力してアラートルールのしきい値を超えるようにすることで、通知システムをテストできます。 Amazon EKS でのゾーンシフトを実行する EKS クラスター内の AZ に異常または障害があるというアラートを受け取った場合は、ARC ゾーンシフトを使用して影響を受ける AZ からネットワークトラフィックを遠ざけることで対応できます。Amazon EKS でゾーンシフトをトリガーすると、次のステップが自動的に適用されます。 影響を受けた AZ のノードは封鎖されます。これにより、Kubernetes スケジューラが異常な AZ のノードに新しい Podをスケジューリングすることを防ぎます。 マネージドノードグループ を使用している場合、 AZ のリバランシング は中断され、Auto Scaling グループ (ASG) が更新されて、新しい EKS データプレーンノードが正常な AZ でのみ起動されるようになります。 異常な AZ のノードは終了されず、Pod もこれらのノードから削除されません。これは、ゾーンシフトの期限が切れたりキャンセルされたりしたときに、まだ十分なキャパシティのある AZ にトラフィックを安全に戻せるようにするためです。 EndpointSlice コントローラーは、障害のある AZ 内の Pod エンドポイントを見つけ、関連する EndpointSlice から削除します。これにより、正常な AZ 内の Pod エンドポイントのみがネットワークトラフィックの受信対象になるようになります。ゾーンシフトがキャンセルされるか期限が切れると、EndpointSlice コントローラーは EndpointSlice を更新して、復元された AZ のエンドポイントを追加します。 次のコマンドを使用して、クラスターのゾーンシフトを開始できます。 export AWS_REGION="af-south-1" export CLUSTER_NAME="beta" export ACCOUNT_ID="your-account-id" export AVAILABILITY_ZONES=("afs1-az1" "afs1-az2" "afs1-az3") aws arc-zonal-shift start-zonal-shift \ --resource-identifier arn:aws:eks:$AWS_REGION:$ACCOUNT_ID:cluster/$CLUSTER_NAME \ --endpoint https://arc-zonal-shift.$AWS_REGION.amazonaws.com/ \ --region $AWS_REGION \ --away-from ${AVAILABILITY_ZONES[2]} --comment "af-south-1c is unhealthy" --expires-in 1h 次のスクリーンショットに示すように、リソースがデプロイされているリージョンに存在する AZ の情報で前述のスクリプトを更新することを忘れないでください。 影響を受けたエンドポイントがトラフィックを受信できなくなったことを確認するには、次のコマンドを実行して、支払いアプリケーションに関連付けられた Envoy クラスターを取得します。 kubectl exec -it deploy/istio-ingressgateway -n istio-system -c istio-proxy \ -- curl localhost:15000/clusters | grep payments | grep zone 前のスクリーンショットでわかるように、支払いアプリケーションに使用できるアップストリームクラスターは af-south-1a と af-south-1b のクラスターだけです。 次に、支払いアプリケーションにクエリを実行して、他の AZ (af-south-1a と af-south-1b) で実行されている Pod からのネットワーク応答に基づいて、そのアプリケーションが引き続き利用可能で期待どおりに機能していることを確認できます。 クリーンアップ これ以上のコストが発生しないように、この記事で詳しく説明した例に関連してプロビジョニングしたインフラストラクチャを必ず削除してください。チュートリアルで Kubernetes マニフェストファイルの保存に使用したファイル名を忘れずに使用してください。 アプリケーションのリソース削除 kubectl delete -f sample-application-manifest.yaml Envoy サイドカー監視用の Prometheus カスタムリソースの削除 kubectl delete -f pod-monitoring-manifest.yaml,service-monitoring-manifest.yaml Prometheus のアンインストール helm uninstall <release-name> -n <namespace> -f values.yaml Istio のアンインストール istioctl uninstall --purge おわりに この投稿では、Istio、Prometheus、Grafana、ARC ゾーンシフトを使用して Amazon EKS クラスター内の AZ 障害を監視し、回復を自動化するための実践的なアプローチについて説明しました。Amazon EKS の ARC ゾーンシフトとゾーンオートシフトの詳細については、 ドキュメント をご覧ください。 翻訳はソリューションアーキテクトの松本が担当しました。原文は こちら です。

AWS の年次イベント re:Invent 2024 にて、 Amazon Bedrock Marketplace の機能が公開されました！Anthropic Claude や Meta Llama といったサーバーレスモデルに加えて、100 以上の企業または Hugging Face 等でオープンに公開されているモデルを Amazon SageMaker 側にデプロイし Bedrock の API を通じて利用することが出来ます。そして、本サービスがローンチする段階ですでに日本企業が開発したモデルも利用できます。ブログ執筆時点はビジネス知識に特化した Stockmark LLM 、パラメーターにより出力のカスタマイズが容易な Karakuri LM 、日本語のベンチマーク Jaster 等で GPT4 を超える性能を記録した Preferred Networks (PFN) の PLaMo 、22B と軽量ながら日本語ベンチマークで Llama-3-70B-Instruct と同等性能である CyberAgent の CyberAgentLM3 が利用できます。 本ブログでは Apache2 ライセンスによりインフラ費用のみで使用ができる CyberAgentLM3 を中心に、Amazon Bedrock Marketplace で購入できる Stockmark 、Karakuri 、PFN のモデルの特色もご紹介します。 Amazon Bedrock Marketplace でモデルを探し、デプロイする では、さっそく Amazon Bedrock Marketplace でモデルを検索しましょう。AWS Console から Amazon Bedrock のページにアクセスし、“Foundation models” 配下にある “Model catalog” を選択します。医療に特化した John Snow Labs や、音声合成の Cambi.ai のモデルなどもあり目移りしますがはじめに CyberAgentLM3 のモデルを使ってみます。 モデルカードをクリックすると、モデルの詳細画面に遷移します。商用モデルの場合は価格などが記載されています。価格は、モデルを動かすインスタンスの料金に加えモデルの料金が時間単位でかかります。 公開モデルについてはモデルの料金がかかりません。 事前にライセンス、商用モデルの場合は “View subscription options” で表示される Legal のセクションをよく読んでからモデルの Deploy をクリックします。 Deploy すると SageMaker Endpoint にモデルがデプロイされ、利用時は Bedrock の API から呼び出す形になります。SageMaker Endpoint にモデルがデプロイされる仕組み上、サーバーレスではないので料金にはご注意ください。 なお、立ち上げる GPU インスタンスの Quota が足りない場合、 Service Quotas の引き上げをリクエストします 。Quota の設定はリージョンごとに異なるので、モデルを使うリージョンに合わせて申請ください。引き上げる Quota は、Amazon SageMaker の endpoint usage です。endpoint 以外にも training や cluster など種類がたくさんあるので、Quota が endpoint のものかどうか確認をしてください、今回は ml.g5.48xlarge for endpoint usage の Quota が足りなかったので引き上げました。 Deploy を実行すると “Marketplace deployments” からデプロイの状況を確認できます。 “Endpoint ARN” を Amazon Bedrock の model-id として指定すると API から接続することが出来ます。 デプロイが完成すると Endpoint status が “In Service” になります。 CyberAgentLM3 のモデルは Chat のプレイグラウンドから選択することが出来ます。 CyberAgentLM3 は Nejumi LLM リーダーボード のスコアを見ると MT Bench の roleplay, humanities, writing で評価される “GLP_表現“ が前世代の GPT4 / Claude 3.5 Sonnet 並みあり、創作性に強そうだったので作文をお願いしてみます。「犬が海に行き、飼い主を思って吠えるシーンの短い脚本を書いてください」とお願いしました。CyberAgentLM3 と Claude 3.5 Sonnet v2 を比較しており、パラメーターは Temperature 1 でそろえています。 Claude 3.5 Sonnet v2 の結果 タイトル: 『海辺の想い』 場所: 夕暮れの海岸 時間: 夕方 （波の音が静かに響く） 柴犬のポチ、ゆっくりと波打ち際を歩く。 時折立ち止まっては、遠くを見つめる。 ポチ （小さく鳴く） クゥーン… （海風が優しく吹く） ポチ、砂浜に座り込む。 空には夕陽が沈みかけている。 飼い主との思い出の場所を見つめる。 ポチ （徐々に大きな声で） ワン！ワン！ （空を見上げて） ワンワンワーン！ （波の音が少し大きくなる） ポチ、もう一度遠くを見つめ、 ゆっくりと立ち上がる。 ポチ （静かに） クゥーン… （夕陽が海に沈んでいく） ポチ、ゆっくりと来た道を戻り始める。 後ろ髪を引かれるように、 もう一度海を振り返る。 （フェードアウト） 終 続いて CyberAgentLM3 の結果 タイトル: 海辺の約束 シーン: 海辺、穏やかな午後。海風が吹き、波が静かに寄せては引いている。 カメラ: 犬（マックス）が砂浜で遊ぶ姿。遠くには波打ち際にいる飼い主（エミリー）が見える。 ナレーション（マックスの声）: （鼻で鳴きながら）「エミリー、君と一緒にいるといつも楽しかった。」 エミリーが砂浜を歩いている。彼女は波音に耳を傾け、時折遠くを見る。 エミリー: （独り言）「本当に、もうここにはいないんだね。」 マックスが海の方を向き、吠える。その声は大きく、哀愁を帯びている。 エミリー: （驚いて）「マックス、どうしたの？」 マックスはエミリーの方に駆け寄る。 ナレーション（マックスの声）: 「僕が何かを感じてるんじゃない、君がここにいないことを感じるんだ。」 エミリーがマックスの頭を撫でる。 エミリー: 「ごめんね、マックス。君を置いて行かざるをえなかったの。」 マックス: （鼻で鳴く）「でも、約束したじゃないか。また一緒にここに来ようって。」 エミリーの目から涙がこぼれる。 エミリー: 「その約束、まだ覚えてるんだね。必ず戻ってくるから、それまで待っててね。」 マックスがもう一度大きく吠え、それから寄り添うようにエミリーの足元で丸くなる。 ナレーション（マックスの声）: 「約束だよ、エミリー。君が戻ってくるまで、僕はここで君を待ち続ける。」 エミリーがマックスを抱きしめる。海風が二人の周りを優しく包み込む。 カメラがゆっくりと引いていき、海の広がりが広がる。 エンドロール この脚本は犬と飼い主の絆を描きながら、約束の大切さとそれを守ることの意味を表現しています。シンプルな設定の中で、感情の深さを強調しています。 マックス (犬) がいるのかいないのか少し謎ですが、会話劇、心情描写ともにうまくストーリーテリングしてくれている印象です。オープンなモデルの特性として、シチュエーションやアクションシーンの関係で荒くなってしまう行動・言動についてもある程度出力させることが出来ます。CyberAgentLM3 の出力は読むとゲームの状況設定が浮かんできます。 今回は CyberAgentLM3 をそのまま使用していますが、必要に応じ Fine Tuning したのちに Custom model import を使用しモデルを Bedrock のインフラに載せることが出来ます。 Custom model import はモデルのストレージコストがかかりますが 5 分間アクティブでなければ自動的に落ちてくれるため経済的です。詳細は Amazon Bedrock の Pricing のページ をご参照ください。 検証が済んだら忘れずにモデルを削除しておきましょう。 “Marketplace deployments” からモデルが削除できます。現時点では、Endpoint はすぐに削除されますが SageMaker 側の Endpoint Configuration と Model は残るので気になる場合削除してください。 個性的なモデルを試す GPT-4 に匹敵する精度の PFN のモデル PFN の PLaMo は日本語ベンチマークのデータセット Jaster 、また MT-Bench のベンチマークで GPT-4 (0125 Preview)に匹敵する精度を誇ります 。公開されている論文によると MT-Bench では releplay / humanities に優位性があるようで、Appendix でも例が表示されていたことから CyberAgentLM3 と同様小説家になり切り文章を書いてみてもらいます。 PLaMo は執筆時点ではまだプレイグラウンドに対応していないので、API 経由で実行します。 aws bedrock-runtime invoke-model \ --cli-binary-format raw-in-base64-out \ --model-id "(model endpoint arn)" \ --body '{"messages":[{"role": "system", "content": "あなたは優秀な小説家です。"},{"role": "user", "content": "犬が海に行き、飼い主を思って吠えるシーンの短い脚本を書いてください"}], "model": "plamo-prime"}' \ --content-type application/json \ --region us-east-1 \ result.txt 出力は JSON で帰ってくるので jq で取り出します。 cat result.txt | jq .body.choices.[0].message.content PLaMo の出力は次の通りです。 タイトル: 海辺の再会 シーン: 犬のマックスと飼い主のサムが海辺の砂浜を散歩しています。マックスはリードから解放され、興奮しながら海の中に走っていきます。 マックス (吠え声): ワンワンワン! サム: マックス、どうしたの? 海の向こうに行っちゃだめよ。 マックスは海に向かっ て吠え続けます。遠くに船が通り過ぎていきます。 マックス (吠え声): ワワワン! ワワワン! サム (心配そうに): マックス、誰かを呼んでいるの? もしかして、寂しくなっちゃったのかな? 突然、一隻のボートが岸に戻ってきて、マックスはそのボートに向かって走り出します。 マックス (吠 え声): ワンワンワン! ワンワンワン! ボートから降りてきたのは、サムの友人のアレックスでした。アレックスはマックスを見ると、喜びのあまり抱きしめます。 アレックス: マックス! 会いたかったよ。今までどこに行ってたの? マックス (吠え声): ワンワンワン! サム: マックスはあなたを呼んでいたのよ。寂しかったのね。 マックスとアレックスは抱き合って再会を喜び合います。サムは微笑みながら、マックスを見守ります。 サム: マックス、私がいつもそばにいるからね。 マックスはサムに向かって吠え、サムはマックスを抱きかかえ、二人は海辺を後にします。 マックス ( 吠え声): ワンワンワン! (うれしそうに) サム (微笑んで): マックス、大好きだよ。 フェードアウト。 マックス (犬) が離れていた友人と出会い喜ぶシーンがきっちり書かれています。私は何も操作をしていないのですが、犬の名前が CyberAgentLM3 と同じマックスになるのは驚きました。 Claude の出力と同様、犬のセリフはすべてワンワンで表現されています。 PLaMo では英語の MT-Bench で評価された結果も掲載されており、humanities/roleplay/writing のスコアは日本語学習後もスコアをほぼ落としていなかったことから、翻訳がうまくできると思いやってみてもらいました。 翻訳の性能をテストするために、Claude で翻訳が難しい日本語を作ってもらいました。なんとなく、もの悲しい、しみじみといったあいまいな表現を含む情緒的な文書です。 夕暮れ時、なんとなく寂しげな様子で庭先に佇む捨て犬を見かけた少年は、思わずその場に立ち止まってしまった。もの悲しい目をした犬は、少年の方をじっと見つめ返してきた。その瞬間、少年はしみじみと胸に染み渡るような温かい気持ちに包まれた。 英訳してもらった結果がこちらです。 As the sun began to set, a young boy happened upon a forlorn-looking stray dog in the backyard. The sight of the sad-eyed canine, standing alone, caused the boy to pause and approach, his heart swelling with an unexpected surge of compassion. The dog, in turn, seemed to gaze back with a mixture of curiosity and melancholy, as if searching for something or someone to fill the void. The scene stirred an emotional response in the boy, a profound sense of warmth and tenderness that he felt, knowing that he had discovered a kindred spirit in the abandoned animal. 素朴に非常に良い文章と感じましたが、Anthropic Claude / Cohere Command R+/ AI21 Labs Jamba 1.5 / ChatGPT (free) などで評価してもらったところ 85~95 点とやはり高得点でした。創作だけでなくトーンを維持した翻訳にも活用できそうです。 ビジネスに特化した Stockmark のモデル Amazon Bedrock Marketplace の使い方を理解したところで、固有の性質を持つモデルを試してみましょう。はじめに、ビジネスに特化した Stockmark のモデルを試してみましょう。Model catalog で検索します。 商用モデルの場合は “View subscription options” で契約内容を確認してから Deploy を行います。 Stockmark のモデルは Instruction Tuning されていないため、Single prompt から検証します。Instruction Tuning されていないとはいえ普通に質問に対し応答してくれます。 では、「日本の人工知能のスタートアップ企業を 1 社教えてください」に対する Stockmark 、Claude 3.5 v2 、Amazon Nova Pro の回答を並べて比較してみます。Stockmark のモデルは 13B でしかも RAG を行わない状況で設立年月日を答えてきて驚きました。 少し専門的な質問としてペロブスカイト太陽電池のスタートアップについて聞いてみましたが、こちらは Stockmark のみが正解でした。 他いくつか聞いてみましたが、箇条書きにしがちな Claude 、構造化された文章にしやすい Nova に比べて文章が日本語として自然だと感じました。 推論時のパラメーターで挙動を変更できる Karakuri のモデル Karakuri のモデルも試してみましょう。こちらはパラメーターで挙動がコントロールできる面白い特性を持っています。 Sample notebook を参考に、パラメーター付きのプロンプトを入力します。「この書類を明日までに完成させておいてくれませんか?」とお願いをしてみました。 <|START_OF_TURN_TOKEN|><|SYSTEM_TOKEN|>あなたは、人間をサポートするアシスタントです。<|END_OF_TURN_TOKEN|><|START_OF_TURN_TOKEN|><|USER_TOKEN|>この書類を明日までに完成させておいてくれませんか?<|END_OF_TURN_TOKEN|><|START_OF_TURN_TOKEN|><|CHATBOT_TOKEN|><attributes>helpfulness: 4 correctness: 4 coherence: 4 complexity: 4 verbosity: 4 quality: 4 toxicity: 0 humor: 0 creativity: 0</attributes 返答は次の通りです。AI らしい献身的な応答です。 もちろん、その書類を明日までに完成させておきます。どのような書類で、どのような内容を必要としていますか? また、どのフォーマットで、どのようなスタイルで作成すべきか教えていただけますか? 具体的な指示と要望があると、より正確に作業ができます。ご指示をお待ちしております。 プロンプトで指示している パラメーター は次のような意味があります。 helpfulness (デフォルト: 4): プロンプトに対する回答の全体的な有用性 correctness (デフォルト: 4): 誤りのない関連事実の包含度 coherence (デフォルト: 4): 表現の一貫性と明確さ complexity (デフォルト: 4): 回答を書くために必要な専門知識の度合い verbosity (デフォルト: 4): プロンプトで求められている内容に対する、回答に含まれる詳細の量 quality (デフォルト: 4): 回答の認識される良さ toxicity (デフォルト: 0): 下品、有害、または潜在的な偏見を含む望ましくない要素 humor (デフォルト: 0): 回答に含まれるユーモアの度合い creativity (デフォルト: 0): 非従来的な回答を生成する意欲 ここで、toxicity を 4 、有害な応答をあえてしてもらいます。すると・・・「 いいえ 」と一言。ことわってきました。helpfulness を下げても同様の挙動が得られます。塩対応の AI を作るには最適です。 別のパラメーターとして、humor / creativity を 4 に上げて金曜日に出かける相談をしたところ、「かもしれません」というアイデアを多く出してくれました。ブレインストーミングなどをするときはこのモードがいいかもしれません。 標準の応答 金曜日は週末で、多くの場所がにぎわっています。どのようなジャンルの場所をご希望か、また何を目的としているかによっておすすめの場所が変わってきます。具体的な目的地が決まっていない場合は、観光地、グルメ、ショッピング、アクティビティなど、どのようなカテゴリの場所をご希望か教えていただければと思います。または、「金曜日に○○をしたい」というご要望からおすすめの場所をご提案することも可能です。 humor / creativity を 4 に上げた応答 今日は金曜日ですね。どこかお出かけしましょうか ? お出かけの場所をいくつかご提案します。 新しくできたカフェ : 都内を中心に新店舗が続々オープンしているので、新しい空間を求めて足を運んでみるのも良いかもしれません。 最近話題の書店 : 知的好奇心をくすぐる書籍に出会えるチャンスかもしれません。 公園 : 自然の中でリフレッシュすることで、リラックス効果が得られるでしょう。 ショッピングモール : セールを行っている店舗が多いので、お得に買い物ができるかもしれません。 映画館 : 最新の映画を鑑賞することで、新たな発見や感動が得られるでしょう。 どこに行かれるか決まりましたか? おわりに 最終的に一人一人が AI エージェントを持つとき、エージェントは各国の文化や言語の理解はもちろん、主要なドメイン知識を持つ必要があると思います。 これまでの基盤モデルの特性から、単一のモデルであらゆる個性を表現することは可能かもしれませんが、機械学習の国際学会である NeurIPS で元 OpenAI の Ilya Sutskever 氏が指摘したように 学習に使えるデータは限界に達しつつあり 、学習から推論の回数を重ねる工夫も試みられています。この場合、推論にコストがかかるようになり大規模なモデルを何回も推論すると多額のコストがかかり身近なエージェントの実現は困難になります。Amazon Bedrock Marketplace には比較的小型でありながら特化したドメインでは高精度のモデルに匹敵する精度があったり、固有の言語に堪能だったり、Fine Tuning なしにパラメーターで挙動のカスタマイズといった興味深い特性を持つモデルがあることを紹介しました。今回ご紹介した PLaMo の開発を担う Preferred Elements 、また Stockmark 、カラクリはいずれも経済産業省 GENIAC 基盤モデル開発支援事業 (第2期) で採択されており、さらなる性能や使い勝手をもつモデルの開発に取り組んでおり AWS は計算リソースの提供を通じ開発を支援しています 。こうしたバリエーションを持つモデルの可能性がより探索されることで、よりユースケースに適合した生成 AI の活用が実現されると考えています。ぜひあなたのユースケースや好みに合うモデルを Amazon Bedrock Marketplace で探してみてください！

AWS re:Invent 2024 で事前発表した通り、 Amazon Bedrock の Stable Diffusion 3.5 Large を使用することで、様々なスタイルのテキスト記述から高品質な画像を生成し、メディア、ゲーム、広告、小売のお客様向けに、コンセプトアート、ビジュアルエフェクト、詳細な商品画像の作成を加速することができます。 2024 年 10 月、 Stability AI は Stable Diffusion 3.5 Large を発表しました。これは、 Amazon SageMaker HyperPod で学習させた 81 億のパラメータを持つ Stable Diffusion シリーズの中で最も強力なモデルで、優れた品質と迅速なアドヒアランスを備えています。Stable Diffusion 3.5 Large は、ストーリーボード作成、コンセプトアートの作成、視覚効果のラピッドプロトタイピングを加速します。キャンペーン、ソーシャルメディアの投稿、広告用に高品質の 1 メガピクセルの画像をすばやく生成できるため、クリエイティブなコントロールを維持しながら時間とリソースを節約できます。 Stable Diffusion 3.5 Large は、次のようなほぼ無限のクリエイティブな可能性をユーザーに提供します。 多彩なスタイル – 3 次元、写真、絵画、ラインアートなど、想像できるほぼすべてのビジュアルスタイルなど、さまざまなスタイルや美学の画像を生成できます。 プロンプトの順守 – Stable Diffusion 3.5 Large の高度なプロンプトアドヒアランスを使用すると、テキストのプロンプトに厳密に従うことができるため、効率的で高品質なパフォーマンスを得るのに最適な選択肢となります。 多様なアウトプット – 大々的なプロンプトを必要とせずに、異なる肌色や特徴を持つ人々をフィーチャーし、周りの多様な世界を代表する画像を作成することができます。 12 月 19 日、Amazon Bedrock の Stable Image Ultra が更新され、モデルの基盤となるアーキテクチャに Stable Diffusion 3.5 Large が含まれるようになりました。Stable Image Ultra は、Stable Diffusion 3.5 を含む Stability AI の最先端モデルを搭載し、画像生成の新しい基準を打ち立てました。タイポグラフィー、複雑な構図、ダイナミックな照明、鮮やかな色彩、芸術的なまとまりに優れています。 Amazon Bedrock の Stable Diffusion モデルの最新アップデートにより、創造性を高め、画像生成ワークフローを加速するための幅広いソリューションが手に入ります。 Amazon Bedrock の Stable Diffusion 3.5 Large から始めましょう Stability AI モデルを初めて使用する場合は、使用を開始する前に Amazon Bedrock コンソール にアクセスして、左下のペインで [モデルアクセス] を選択してください。Stability AI の最新モデルにアクセスするには、Stability AI の Stable Diffusion 3.5 Large へのアクセスをリクエストしてください。 Amazon Bedrock で Stability AI モデルをテストするには、左側のメニューペインの [ プレイグラウンド ] で [ 画像/動画 ] を選択します。次に、 [ デルを選択 ] を選択し、カテゴリとして Stability AI を選択し、モデルとして Stable Diffusion 3.5 Large を選択します。 プロンプトで画像を生成できます。画像を生成するためのサンプルプロンプトは次のとおりです。 夜のネオンに照らされた東京の路地でのエネルギッシュなストリートシーン。屋台から湯気が立ち上り、雨に濡れた歩道をカラフルなネオンサインが照らします。 また、 [API リクエストを表示] を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) や AWS SDK . でコードサンプルを使用してモデルにアクセスすることもできます。 stability.sd3-5-large-v1:0 をモデル ID として使用できます。 1 つのコマンドで画像を取得するために、出力 JSON ファイルを標準出力に書き込み、 jq ツールを使用してエンコードされた画像を抽出し、その場でデコードできるようにします。出力は img.png ファイルに書き込まれます。 AWS CLI コマンドのサンプルを次に示します。 $ aws bedrock-runtime invoke-model \ --model-id stability.sd3-5-large-v1:0 \ --body "{\"text_prompts\":[{\"text\":\"High-energy street scene in a neon-lit Tokyo alley at night, where steam rises from food carts, and colorful neon signs illuminate the rain-slicked pavement.\",\"weight\":1}],\"cfg_scale\":0,\"steps\":10,\"seed\":0,\"width\":1024,\"height\":1024,\"samples\":1}" \ --cli-binary-format raw-in-base64-out \ --region us-west-2 \ /dev/stdout | jq -r '.images[0]' | base64 --decode > img.jpg Stable Image Ultra 1.1 を使用して、 AWS SDK for Python (Boto3) のモデルの基盤となるアーキテクチャに Stable Diffusion 3.5 Large を組み込む方法は次のとおりです。このシンプルなアプリケーションは、テキストから画像へのプロンプトをインタラクティブに要求し、Amazon Bedrock を呼び出して、モデル ID として stability.stable-image-ultra-v1:1 を使用して画像を生成します。 import base64 import boto3 import json import os MODEL_ID = "stability.stable-image-ultra-v1:1" bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-west-2") print("Enter a prompt for the text-to-image model:") prompt = input() body = { "prompt": prompt, "mode": "text-to-image" } response = bedrock_runtime.invoke_model(modelId=MODEL_ID, body=json.dumps(body)) model_response = json.loads(response["body"].read()) base64_image_data = model_response["images"][0] i, output_dir = 1, "output" if not os.path.exists(output_dir): os.makedirs(output_dir) while os.path.exists(os.path.join(output_dir, f"img_{i}.png")): i += 1 image_data = base64.b64decode(base64_image_data) image_path = os.path.join(output_dir, f"img_{i}.png") with open(image_path, "wb") as file: file.write(image_data) print(f"The generated image has been saved to {image_path}") アプリケーションは、結果として得られる画像を output ディレクトリ (存在しない場合は作成されます) に書き込みます。既存のファイルを上書きしないように、コードは既存のファイルをチェックして、 img_<number>.png 形式で使用可能な最初のファイル名を見つけます。 詳細については、AWS SDK を使用する Invoke API の例 を参照して、さまざまなプログラミング言語を使用してイメージを生成するアプリケーションを構築してください。 興味深い例 Stable Diffusion 3.5 Large で作成された画像をいくつかご紹介します。 プロンプト: Amazon Bedrock の Stable Diffusion 3.5 という単語を前面に出した陽気な筆記体のタイポグラフィフォントで、テックプロジェクトに取り組んでいる全身の大学生。 プロンプト: 3 つのポーションの写真: 最初のポーションは「MANA」のラベルが付いた青、2 番目のポーションは「HEALTH」のラベルの付いた赤色、3 番目のポーションは「POISON」というラベルの付いた緑です。旧薬屋。 プロンプト: 写真、夕暮れのピンクのバラの花、輝く背景、タイル張りの家。 プロンプト: 愛犬と一緒に世界を旅する冒険家の 3D アニメーションシーン。 今すぐご利用いただけます Stable Diffusion 3.5 Large モデルは、本日、米国西部 (オレゴン) AWS リージョン の Amazon Bedrock で一般販売されています。今後の最新情報については、 詳細なリージョンリスト をご確認ください。詳細については、 Amazon Bedrock での Stability AI 製品ページと Amazon Bedrock の料金 ページをご覧ください。 Amazon Bedrock コンソール で Stable Diffusion 3.5 Large を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock まで、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。

本ブログは 2024 年 11 月 15 日に公開された「 Considerations for addressing the core dimensions of responsible AI for Amazon Bedrock applications 」を翻訳したものとなります。 生成 AI の急速な進歩は革新的なイノベーションを約束する一方で、重大な課題も提示しています。法的影響、AI が生成した出力の正確性、データプライバシー、そして広範な社会的影響に関する懸念が、責任ある AI の開発の重要性を浮き彫りにしています。責任ある AI とは、利益を最大化し、潜在的なリスクや意図しない害を最小限に抑えることを目標として、一連のディメンションに導かれた AI システムの設計、開発、運用の実践です。私たちのお客様は使用しているテクノロジーが責任を持って開発されたことを知りたいと考えています。また、自社組織内でそのテクノロジーを責任を持って実装するためのリソースとガイダンスを求めています。最も重要なことは、お客様は、展開するテクノロジーがエンドユーザーを含むすべての人の利益になることを確実にしたいということです。AWS では、責任ある方法で AI を開発することに取り組んでおり、教育、科学、そしてお客様を優先する人間中心のアプローチを採用し、AI のライフサイクル全体にわたって責任ある AI を統合しています。 責任ある AI を構成するものは、常に進化し続けています。現時点では、責任ある AI の 8 つの重要なディメンションを考慮しています。公平さ、説明可能性、プライバシーとセキュリティ、安全性、制御性、正確性と堅牢性、ガバナンス、そして透明性です。これらディメンションは、責任を持って安全に AI アプリケーションを開発し展開するための基礎を構成します。 AWS では、 Amazon Bedrock ガードレール のような目的に特化したサービスや機能を使い始めるためにツール、ガイダンス、リソースを提供することで、お客様が責任ある AI を理論から実践へと変換できるよう支援しています。本ブログでは、責任ある AI のコアディメンションを紹介し、Amazon Bedrock アプリケーションでこれらのディメンションに対処するための考慮事項と戦略を探ります。 Amazon Bedrock はフルマネージド型サービスで、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazon などの主要な AI 企業が提供する高性能な基盤モデル（FM）を単一の API を通じて選択できます。また、セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションを構築するための幅広い機能セットも提供しています。 安全性 責任ある AI における安全性のディメンションは、有害なシステム出力や悪用を防ぐことに焦点を当てています。これは、AI システムがユーザーと社会の幸福を優先するよう導くことに重点を置いています。 Amazon Bedrock は、様々な安全対策を組み込むことで、安全で信頼性の高い AI アプリケーションの開発を促進するように設計されています。以下のセクションでは、これらの安全対策を実装するための異なる側面を探り、それぞれについてガイダンスを提供します。 Amazon Bedrock ガードレールによりモデルの有害性に対処する Amazon Bedrock ガードレールは、アプリケーションが安全でない、または望ましくないとみなされるコンテンツを生成したり、そのコンテンツに関与しないようにすることで、AI の安全性をサポートします。これらの安全対策は、複数のユースケースに対して作成でき、アプリケーションと責任ある AI の要件に応じて、複数の FM にわたって実装できます。例えば、Amazon Bedrock ガードレールを使用して、有害なユーザー入力やモデル出力をフィルタリングしたり、ユーザー入力やモデル出力から機微情報をブロックまたはマスクしたり、アプリケーションが安全でないまたは望ましくないトピックに応答するのを防ぐことができます。 （訳者注）ガードレールは 2024 年 12 月 20 日時点で 英語のみをサポート しており、他の言語でテキストコンテンツを評価すると、信頼できない結果になる可能性があります。以後、本ブログで扱っているガードレールの機能についても同様です。 コンテンツフィルター は、有害または不適切なユーザー入力やモデルが生成した出力を検出してフィルタリングするために使用できます。コンテンツフィルターを実装することで、AI アプリケーションが不適切なユーザーの振る舞いに反応するのを防ぎ、安全な出力のみを提供することができます。これは、特定のユーザーの振る舞いが望ましくない状況では、まったく出力を提供しないことも意味します。コンテンツフィルターは、増悪、侮辱、性的、暴力、不正行為、プロンプト攻撃の 6 つのカテゴリーをサポートしています。フィルタリングは、ユーザーの入力と FM の応答を各カテゴリーにわたって信頼度分類に基づいて行われます。フィルターの強度を調整することで、有害なコンテンツのフィルタリングの感度を決定できます。フィルターを強くすると、望ましくないコンテンツをフィルタリングする確率が高くなります。 拒否トピック は、アプリケーションのコンテキストで望ましくないトピックのセットです。これらのトピックは、ユーザーのクエリやモデルの応答で検出された場合にブロックされます。拒否トピックは、そのトピックの自然言語による定義と、いくつかのオプションの例文を提供することで定義します。例えば、医療機関が AI アプリケーションで薬や治療に関するアドバイスを避けたい場合、拒否トピックを「病状、治療、または投薬に関連して顧客に提供される情報、ガイダンス、アドバイス、または診断」と定義し、オプションの入力例として「投薬 A の代わりに投薬 B を使用できますか」、「病気 Y の治療に投薬 A を使用できますか」、「このほくろは皮膚がんに見えますか」などを設定できます。開発者は、拒否トピックが検出された際にユーザーに表示されるメッセージを指定する必要があります。例えば、「私は AI ボットであり、この問題についてお手伝いすることはできません。カスタマーサービス/診療所にお問い合わせください」などです。本質的に有害ではないものの、エンドユーザーに潜在的に害を及ぼす可能性のある特定のトピックを避けることは、安全な AI アプリケーションを作成する上で極めて重要です。 単語フィルター は、望ましくない単語、フレーズ、および不適切な表現をブロックするためのフィルターを設定するために使用されます。そのような単語には、攻撃的な用語や、製品や競合他社の情報などの望ましくない出力が含まれる可能性があります。カスタム単語フィルターには最大 10,000 項目を追加でき、AI アプリケーションが生成したり関与したりしたくないトピックをフィルタリングすることができます。 機密情報フィルター は、ユーザー入力やモデル出力に含まれる個人を特定できる情報（personally identifiable information: PII）や、指定されたコンテキスト依存の機微情報などをブロックまたは編集するために使用されます。これは、機微データの取り扱いやユーザーのプライバシーに関する要件がある場合に役立ちます。AI アプリケーションが PII 情報を処理しない場合、ユーザーと組織は、PII の偶発的または意図的な誤用や不適切な取り扱いからより安全になります。フィルターは機微情報の要求をブロックするように設定されており、そのような検出時にはガードレールがコンテンツをブロックし、事前に設定されたメッセージを表示します。また、機微情報の編集またはマスクを選択することもでき、その場合はデータを識別子に置き換えるか完全に削除するかを選択できます。 Amazon Bedrock モデル評価によりモデルの有害性を測定する Amazon Bedrock では、 モデル評価 のための組み込み機能が提供されています。モデル評価は、異なるモデルの出力を比較し、ユースケースに最も適したモデルを選択するために使用されます。モデル評価ジョブは、テキスト生成、テキスト分類、質問への回答、テキスト要約など、大規模言語モデル（large language model: LLM）の一般的なユースケースをサポートしています。自動モデル評価ジョブを作成するか、人間の作業者を使用するモデル評価ジョブを作成するかを選択できます。自動モデル評価ジョブの場合、3 つの事前定義された指標（正確性、堅牢性、有害性）にわたる組み込みデータセットを使用するか、独自のデータセットを持ち込むことができます。AWS が管理するチームまたはお客様が管理するチームのいずれかで実施できる human-in-the-loop 評価の場合は、独自のデータセットを持ち込む必要があります。 有害なコンテンツに対する自動モデル評価の使用を計画している場合、まずはあなたの特定のアプリケーションにおいて何が有害なコンテンツを構成するかを定義することから始めてください。これには、攻撃的な言葉、ヘイトスピーチ、その他の有害なコミュニケーション形態が含まれる可能性があります。自動評価には、選択可能な厳選されたデータセットが付属しています。有害性については、RealToxicityPrompts または BOLD データセット、あるいはその両方を使用できます。カスタムモデルを Amazon Bedrock に持ち込む場合、主要なアップデートや再トレーニングの後など、モデル開発の重要な段階で定期的な有害性評価を開発パイプラインに組み込むことで、スケジュールされた評価を実装できます。早期発見のために、新しいデータやモデル出力に対して継続的に有害性評価を実行するカスタムテストスクリプトを実装してください。 Amazon Bedrock とその安全機能は、開発者が安全性と信頼性を優先する AI アプリケーションを作成するのを支援し、それによって AI 技術の信頼性を高め、倫理的な使用を促進します。選択した安全性アプローチを実験し、反復して望ましいパフォーマンスを達成する必要があります。多様なフィードバックも重要なので、安全性と公平さのためにモデルの応答を評価する human-in-the-loop テストの実施を検討してください。 制御性 制御性は、AI システムの振る舞いをモニタリングおよび制御するメカニズムを持つことに焦点を当てています。これは、AI システムが望ましいパラメータ内で動作することを確実にするために、管理、ガイド、制約する能力を指します。 Amazon Bedrock ガードレールを使用して AI の振る舞いをガイドする AI アプリケーションが生成または関与できるコンテンツを直接コントロールするために、安全性のディメンションで議論した Amazon Bedrock ガードレールを使用できます。これにより、システムの出力を効果的に誘導し管理することができます。 コンテンツフィルターを使用して、有害なコンテンツを検出する感度のレベルを設定することで、AI の出力を管理できます。コンテンツのフィルタリングの厳密さを制御することで、望ましくない応答を避けるように AI の振る舞いを制御できます。これにより、システムの相互作用と出力を要件に合わせてガイドすることができます。拒否トピックを定義し管理することで、AI の特定の主題への関与を制御するのに役立ちます。定義されたトピックに関連する応答をブロックすることで、AI システムが設定された境界内の動作に留まるのに役立ちます。 Amazon Bedrock ガードレールは、コンテンツポリシーとプライバシー基準への準拠のためにシステムの振る舞いをガイドすることもできます。カスタム単語フィルターを使用すると、特定の単語、フレーズ、および不適切な表現をブロックでき、AI が使用する言語を直接制御できます。また、機微情報の扱い方（ブロックまたは編集）を管理し、AI のデータプライバシーとセキュリティへのアプローチを制御できます。 Amazon Bedrock のモデル評価を用いて AI のパフォーマンスをモニタリングし調整する AI のパフォーマンスを評価し調整するために、Amazon Bedrock のモデル評価を確認することができます。これにより、システムが望ましいパラメータ内で動作し、安全性と倫理的基準を満たすことを支援します。自動評価と human-in-the-loop 評価の両方を試すことができます。これらの評価方法は、モデルが安全性と倫理的基準をどの程度満たしているかを評価することで、モデルのパフォーマンスをモニタリングしガイドするのに役立ちます。定期的な評価により、フィードバックとパフォーマンス指標に基づいて AI の振る舞いを調整し制御することができます。 開発パイプラインに定期的な有害性評価とカスタムテストスクリプトを組み込むことで、モデルの振る舞いを継続的にモニタリングし調整することができます。このような継続的な制御により、AI システムが望ましいパラメータに沿って維持され、新しいデータやシナリオに効果的に適応することを支援します。 公平さ 責任ある AI における公平さのディメンションは、AI が異なるステークホルダーグループに与える影響を考慮します。公平さを達成するには、継続的なモニタリング、バイアスの検出、そして AI システムの調整を行い、公平さと正義を維持する必要があります。 Amazon Bedrock 上に構築された AI アプリケーションの公平さを支援するため、アプリケーション開発者は機械学習（ML）ライフサイクルの異なる段階でモデル評価とヒューマンインザループのバリデーションを検討すべきです。モデルのトレーニング前後、そしてモデルの推論時にバイアスの存在を測定することが、バイアスを緩和する最初のステップです。AI アプリケーションを開発するときは、公平さの目標、メトリクス、および潜在的に許容可能な最小のしきい値を設定して、ユースケースに該当するさまざまな品質と人口統計にわたってパフォーマンスを測定する必要があります。これらに加えて、潜在的な不正確さやバイアスを緩和する計画を作成すべきです。これには、データセットの修正、バイアスの根本原因の特定と削除、新しいデータの導入、そして場合によってはモデルの再トレーニングが含まれる可能性があります。 Amazon Bedrock は、安全性のディメンションで記載したように、モデル評価のための組み込み機能を提供しています。モデルの堅牢性と有害性を測定するための一般的なテキスト生成の評価には、職業、性別、人種、宗教的イデオロギー、政治的イデオロギーの 5 つの領域に焦点を当てた組み込みの公平性データセットである Bias in Open-ended Language Generation Dataset（BOLD）を使用できます。他の領域やタスクの公平さを評価するには、独自のカスタムプロンプトデータセットを持ち込む必要があります。 透明性 生成 AI における透明性のディメンションは、AI システムがどのように決定を下すのか、なぜ特定の結果を生み出すのか、そしてどのようなデータを使用しているのかを理解することに焦点を当てています。透明性を維持することは、AI システムへの信頼を構築し、責任ある AI の実践を促進するために重要です。 透明性への高まる需要に応えるため、AWS は AWS AI サービスカード を導入しました。これは、AWS の AI サービスに関するお客様の理解を深めることを目的とした専用リソースです。AI サービスカードは、責任ある AI ドキュメンテーションの要となるもので、重要な情報を一箇所に集約しています。これらは、AWS の AI サービスの想定される使用事例、制限事項、責任ある AI 設計原則、そして展開とパフォーマンス最適化のためのベストプラクティスについて、包括的な洞察を提供します。これらは、サービスを責任ある方法で構築するために行う包括的な開発プロセスの一部です。 2024 年 11 月 23 日現在、Amazon Bedrock モデル向けに次の AI サービスカードが提供されています。 Amazon Titan Text Lite and Titan Text Express Amazon Titan Text Premier （訳者注：2024 年 12 月 20 日現在、以下の AI サービスカードもご利用いただけます） Amazon Nova Micro, Lite, Pro Amazon Nova Canvas Amazon Nova Reel Amazon Titan Image Generator Amazon Titan Text Embeddings 他の Amazon Bedrock モデルのサービスカードは、プロバイダーのウェブサイトで直接見つけることができます。各カードには、サービスの具体的な使用例、採用されている ML 技術、そして責任ある展開と使用のための重要な考慮事項が詳細に記載されています。これらのカードは、顧客のフィードバックと継続的なサービス改善に基づいて反復的に進化し、常に関連性と情報性を保っています。 透明性を提供するもう一つの取り組みは、Amazon Titan Image Generator の目に見えないウォーターマーク（透かし）です。Amazon Titan によって生成された画像には、デフォルトでこの目には見えないウォーターマークが付いています。このウォーターマークの検出メカニズムにより、Amazon Titan Image Generator によって生成された画像を識別することができます。これは、自然言語プロンプトを使用して、大量かつ低コストで現実のスタジオで製作されたような品質の画像を作成するように設計された FM です。ウォーターマーク検出を使用することで、生成 AI コンテンツに関する透明性を高め、有害なコンテンツ生成のリスクを緩和し、誤情報の拡散を減らすことができます。 コンテンツクリエイター、報道機関、リスク分析者、不正検出チームなどは、この機能を使用してAmazon Titan Image Generator によって作成された画像を識別し、認証することができます。検出システムは信頼性スコアも提供するため、元の画像が変更されていても、検出の信頼性を評価することができます。Amazon Bedrock コンソールに画像をアップロードするだけで、API は Amazon Titan モデルによって生成された画像に埋め込まれたウォーターマークを検出します。これには、ベースモデルとカスタマイズされたバージョンの両方が含まれます。このツールは責任ある AI の実践をサポートするだけでなく、生成 AI によって作成されたコンテンツの使用における信頼性を促進します。 正確性と堅牢性 責任ある AI における正確性と堅牢性のディメンションは、予期せぬ入力や敵対的な入力があっても、正確なシステム出力を達成することに焦点を当てています。このディメンションの主な焦点は、モデルのハルシネーション（幻覚）の可能性に対処することです。モデルのハルシネーションは、AI システムが妥当に思える虚偽や誤解を招く情報を生成する時に発生します。AI システムの堅牢性は、様々な条件下で、予期せぬ状況や不利な状況を含めて、モデルの出力が一貫性があり信頼できるものであることを確実にします。堅牢な AI モデルは、不完全または不正確な入力データに直面しても、その機能を維持し、一貫性のある正確な出力を提供し続けます。 Amazon Bedrock のモデル評価で精度と堅牢性を測定する AI の安全性と制御性のディメンションで紹介されたように、Amazon Bedrock は有害性、堅牢性、精度の観点からAI モデルを評価するためのツールを提供しています。これにより、モデルが有害、攻撃的、または不適切なコンテンツを生成しないようにし、予期せぬ入力や敵対的なシナリオを含む様々な入力に耐えられるようにします。 精度評価は、AI モデルが様々なタスクやデータセットにわたって信頼性の高い正確な出力を生成するのに役立ちます。組み込みの評価では、TREX データセットに対して精度が測定され、アルゴリズムはモデルの予測が実際の結果とどの程度一致するかを計算します。精度の実際の指標は選択されたユースケースによって異なります。例えば、テキスト生成では、組み込みの評価は実世界の知識スコアを計算し、これはモデルが実世界に関する事実的知識をエンコードする能力を調べます。この評価は、AI アプリケーションの完全性、信頼性、有効性を維持するために不可欠です。 堅牢性評価は、モデルが多様で潜在的に困難な条件下でも一貫したパフォーマンスを維持することを確認します。これには、予期せぬ入力、敵対的な操作、データ品質の変動に対して、パフォーマンスの大幅な低下なしに対処することが含まれます。 Amazon Bedrock アプリケーションにおける正確性と堅牢性を実現するための方法 LLM をアプリケーションで使用する際に、正確性と堅牢性を最大化するために検討できるいくつかの手法があります。 プロンプトエンジニアリング – モデルに対して、モデルが知っていることについてのみ対話を行い、新しい情報を生成しないよう指示することができます。 Chain-of-thought（CoT: 思考の連鎖） – CoT はモデルが最終的な答えに至る中間的な推論ステップを生成する技術です。これにより、モデルの思考プロセスを透明で論理的にすることで、複雑な問題を解決する能力が向上します。例えば、モデルに対してなぜ特定の情報を使用し、特定の出力を作成したのかを説明するよう求めることができます。これはハルシネーションを減らすための強力な方法です。モデルに出力を生成するために使用したプロセスを説明するよう求めると、モデルは実行したステップや使用された情報を識別しなければならないため、それによってハルシネーション自体が減少します。CoT や Amazon Bedrock で提供される LLM のその他のプロンプトエンジニアリング技術についてさらに学ぶには、 Amazon Bedrock のプロンプトエンジニアリングの概念 をご確認ください。 Retrieval Augmented Generation（RAG） – RAG は適切なコンテキストを提供し内部データでモデルが生成する出力を拡張することで、ハルシネーションを軽減するのに役立ちます。RAG を使用すると、モデルにコンテキストを提供し、提供されたコンテキストのみに基づいて応答するようモデルに指示することができ、これによりハルシネーションが少なくなります。 Amazon Bedrock ナレッジベース を使用すると、データの取り込みから検索、プロンプトの拡張までの RAG のワークフローを実装できます。ナレッジベースから取得された情報には、AI アプリケーションの透明性を向上させ、ハルシネーションを最小限に抑えるために、出典が含まれます。 ファインチューニングと事前トレーニング – これらは、特定のコンテキストに対するモデルの精度を向上させるための異なる技術です。RAG を通じて内部データを提供する代わりに、これらの技術では、データセットの一部としてデータをモデルに直接追加します。 Amazon Simple Storage Service （Amazon S3）バケットに保存されたデータセットを指定することで、 複数の Amazon Bedrock FM をカスタマイズできます。ファインチューニングでは、数十から数百のラベル付きサンプルを使用して、特定のタスクのパフォーマンスを向上させるためにモデルをトレーニングできます。モデルは特定の種類の入力に対して特定の種類の出力を関連付けることをトレーニングします。また、継続的な事前トレーニングを使用することもでき、これによりモデルにラベルなしデータを提供し、モデルが特定の入力に慣れ、パターンをトレーニングするようにします。これには、例えば、モデルが十分なドメイン知識を持っていない特定のトピックからのデータが含まれ、それによりその領域の精度が向上します。これらのカスタマイズオプションはどちらも、大量のアノテーションされたデータを収集することなく、正確なカスタマイズされたモデルを作成することを可能にし、結果としてハルシネーションを減少させます。 推論パラメータ – 推論パラメータ についても検討することができます。これらは、モデルの応答を修正するために調整可能な値です。設定できる推論パラメータは複数あり、それぞれモデルの異なる能力に影響を与えます。例えば、モデルの応答をより創造的にしたり、物語の文脈のように完全に新しい情報を生成したりしたい場合、temperature パラメータを調整することができます。これにより、モデルが確率分布全体から単語を探し、その空間でより離れた単語を選択する方法に影響を与えます。 コンテキストグラウンディング – 最後に、Amazon Bedrock ガードレールの コンテキストグラウンディング チェックを使用することができます。Amazon Bedrock ガードレールは、開発者がコンテンツフィルターを設定し、拒否トピックを指定することで、許可されたテキストベースのユーザー入力とモデル出力を制御できるメカニズムを Amazon Bedrock サービス内で提供します。モデルの応答がソースの情報に根拠がない（事実に反している、または新しい情報を追加している）場合や、ユーザーのクエリに関連がない場合、それらのハルシネーションを検出してフィルタリングすることができます。例えば、RAG アプリケーションにおいて、モデルの応答が取得された文章中の情報から逸脱している場合や、ユーザーの質問に答えていない場合、その応答をブロックまたはフラグ付けすることができます。 モデルプロバイダーやチューナーはこれらのハルシネーションを緩和できない可能性がありますが、ユーザーにハルシネーションが発生する可能性があることを知らせることはできます。これは、AI アプリケーションの使用はユーザー自身の責任で行うという免責事項を追加することで実現できます。現在、複数の出力間の変動（エントロピーとして測定）に基づいて不確実性を推定する方法の 研究 にも進展が見られます。これらの新しい方法は、質問が誤って回答される可能性が高い場合を特定することにおいて、以前の方法よりもはるかに優れていることが証明されています。 説明可能性 責任ある AI における説明可能性のディメンションは、システム出力の理解と評価に焦点を当てています。説明可能な AI フレームワークを使用することで、人間はモデルを調べ、どのように出力を生成しているかをより良く理解することができます。生成 AI モデルの出力の説明可能性については、正確性と堅牢性のディメンションで議論したように、トレーニングに使われたデータの出所を確認したり CoT プロンプティングなどの技術を使用できます。 出力された情報の出所を確認したいお客様には、Amazon Bedrock ナレッジベースを使用した RAG をお勧めします。RAG では可能性のある情報源がプロンプト自体に含まれているため、情報の出所を確認できます。ナレッジベースから取得された情報には情報源が含まれており、透明性を向上させハルシネーションを最小限に抑えることができます。Amazon Bedrock ナレッジベースは、エンドツーエンドの RAG ワークフローを管理します。RetrieveAndGenerate API を使用する際、出力には生成された応答、情報源、および取得されたテキストチャンクが含まれます。 セキュリティとプライバシー 生成 AI 技術を利用するすべての組織にとって、絶対に重要なことが一つあるとすれば、それはあなたの行うすべてのことがプライベートであり続けること、そしてあなたのデータが常に確実に保護されることです。責任ある AI におけるセキュリティとプライバシーのディメンションは、データとモデルが適切に取得され、使用され、保護されることに焦点を当てています。 Amazon Bedrock の組み込みセキュリティとプライバシー Amazon Bedrock では、データプライバシーとローカライゼーションの観点から、AWS はお客様のデータを保存しません。保存しないため、漏洩することも、モデルベンダーに見られることも、AWS が他の目的で使用することもありません。私たちが保存する唯一のデータは運用メトリクスです。例えば、正確な請求のために、AWS は特定の Amazon Bedrock モデルに送信したトークン数と、モデル出力で受け取ったトークン数に関するメトリクスを収集します。もちろん、ファインチューニングされたモデルを作成する場合、AWS がそれをホストするためにそのモデルを保存する必要があります。API リクエストで使用されるデータは、お客様が選択した AWS リージョン内に留まります。特定のリージョンの Amazon Bedrock API へのリクエストは、完全にそのリージョン内に留まります。 データセキュリティについて、よく言われることは「データが移動するのであれば暗号化する」ということです。Amazon Bedrock への、からの、そして内部での通信は、すべて転送中に暗号化されます。Amazon Bedrock には TLS を使用しないエンドポイントはありません。もう一つよく言われることは「動かないデータも暗号化する」ということです。デフォルトでは、ファインチューニングに用いるデータとモデルは AWSが管理する AWS Key Management Service （AWS KMS）キーを使用して暗号化されますが、お客様独自の KMS キーを使用するオプションもあります。 Amazon Bedrock リソースを使用する権限を持つユーザーを制御するのは、 AWS Identity and Access Management （IAM）です。各モデルに対して、アクションへのアクセスを明示的に許可または拒否することができます。例えば、あるチームやアカウントに Amazon Titan Text のキャパシティをプロビジョニングする権限を与えるけれども Anthropic モデルへのアクセスは許可しない、といったことが可能です。必要に応じて、広範囲または詳細な設定を行うことができます。 Amazon Bedrock API へのアクセスのためのネットワークデータフローを見る際、トラフィックが常に暗号化されていることを覚えておくことが重要です。 Amazon Virtual Private Cloud （Amazon VPC）を使用している場合、 AWS PrivateLink を利用して　Amazon Bedrock のフロントエンドフリートへリージョナルネットワークを通じたプライベート接続を提供し、インターネットゲートウェイを介したインターネットトラフィックへの露出を緩和することができます。同様に、企業のデータセンターの観点では、VPN または AWS Direct Connect を設定して VPC にプライベート接続し、そこから PrivateLink を介して Amazon Bedrock にトラフィックを送信することができます。これにより、オンプレミスシステムがインターネット経由で Amazon Bedrock 関連のトラフィックを送信する必要がなくなるはずです。AWS のベストプラクティスに従い、ゼロトラストの原則に基づいてセキュリティグループとエンドポイントポリシーを使用して PrivateLink エンドポイントへのアクセスを制御し保護します。 Amazon Bedrock のモデルカスタマイズにおけるネットワークとデータセキュリティについても見てみましょう。カスタマイズのプロセスでは、まずリクエストされたベースラインモデルを読み込み、その後お客様のアカウント内の S3 バケットからカスタマイズのためのトレーニングデータとバリデーションデータを安全に読み取ります。データへの接続は、 Amazon S3 用のゲートウェイエンドポイント を使用して VPC を通じて行うことができます。つまり、バケットポリシーを適用することができ、S3 バケットへのより広範なアクセスを開放する必要がありません。新しいモデルが構築されたら、暗号化されてカスタマイズされたモデルバケットに配信されます。モデルベンダーがお客様のトレーニングデータやカスタマイズされたモデルにアクセスしたり、可視化したりすることは一切ありません。トレーニングジョブの終了時には、元の API リクエストで指定した S3 バケットにトレーニングジョブに関する出力メトリクスも配信されます。前述のとおり、トレーニングデータとカスタマイズされたモデルの両方を、お客様が管理する KMS キーを使用して暗号化することができます。 プライバシー保護のベストプラクティス 生成 AI アプリケーションを実装する際に最初に念頭に置くべきことは、データの暗号化です。先ほど述べたように、Amazon Bedrock は転送中および保管時の暗号化を使用しています。保管時の暗号化については、デフォルトの AWS 管理の KMS キーの代わりに、お客様が管理する KMS キーを選択することができます。企業の要件によっては、お客様が管理する KMS キーを使用したい場合があるでしょう。転送中の暗号化については、Amazon Bedrock API に接続する際に TLS 1.3 を使用することをお勧めします。 モデルの利用規約とデータプライバシーについては、利用規約（End User License Agreement: EULA）を読むことが重要です。モデルプロバイダーはこれらの利用規約を設定する責任があり、お客様はこれらを評価し、アプリケーションに適しているかどうかを判断する責任があります。Amazon Bedrock でモデルアクセスをリクエストする場合も含め、常に利用規約を読み、理解してから同意するようにしてください。利用規約の内容に納得していることを確認してください。またテストデータが法務チームによって承認されていることを確認してください。 プライバシーと著作権に関して、トレーニングやファインチューニングに使用するデータが法的に利用可能で、実際にそれらのモデルのトレーニングやファインチューニングに使用できることを確認するのは、プロバイダーとモデルをチューニングする人の責任です。また、使用しているデータがモデルに適切であることを確認するのもモデルプロバイダーの責任です。公開されているデータは自動的に商業利用のための公開を意味するわけではありません。つまり、このようなデータを使用して何かをチューニングし、顧客に見せることはできません。 ユーザーのプライバシーを保護するために、安全性と制御性のディメンションで議論した Amazon Bedrock ガードレールの機密情報フィルターを使用することができます。 最後に、生成 AI を用いた自動化を行う際（例えば、 Amazon Bedrock のエージェント を使用する場合）、モデルが自動的に決定を下すことに問題がないか確認し、アプリケーションが誤った情報や行動を提供した場合の結果を考慮してください。したがって、ここではリスク管理を検討することが重要です。 ガバナンス AI システムが倫理基準、法的要件、社会的価値観に沿って開発、展開、管理されることを確実にするのがガバナンスのディメンションです。ガバナンスには、AI の開発と使用を安全で公正、かつアカウンタビリティを持つ方法で導く枠組み、方針、規則が含まれます。AI のガバナンスを設定し維持することで、ステークホルダーは AI アプリケーションの使用に関する情報に基づいた決定を下すことができます。これには、データの使用方法、AI の意思決定プロセス、ユーザーへの潜在的な影響についての透明性が含まれます。 堅牢なガバナンスは、責任ある AI アプリケーションを構築するための基盤です。AWS は、AI ガバナンスの実践を確立し運用するための様々なサービスとツールを提供しています。また、AWS は AI ガバナンスフレームワーク を開発し、データとモデルのガバナンス、AI アプリケーションのモニタリング、監査、リスク管理などの重要な分野におけるベストプラクティスに関する包括的なガイダンスを提供しています。 監査可能性について見ると、Amazon Bedrock は AWS Audit Manager から提供される AWS 生成 AI ベストプラクティスフレームワーク v2 と統合されています。このフレームワークを使用することで、エビデンスの収集を自動化し、Amazon Bedrock 内での生成 AI 使用の監査を開始できます。これにより、AI モデルの使用と権限の追跡、機密データのフラグ付け、問題のアラート通知に一貫したアプローチを提供します。収集されたエビデンスを使用して、責任、安全性、公平さ、持続可能性、レジリエンス、プライバシー、セキュリティ、正確性という 8 つの原則にわたって AI アプリケーションを評価できます。 モニタリングと監査の目的で、Amazon Bedrock は ビルトインで統合されている Amazon CloudWatch と AWS CloudTrail を利用できます。CloudWatch を使用してAmazon Bedrock をモニタリングできます。CloudWatch は生データを収集し、読みやすいリアルタイムに近いメトリクスに処理します。CloudWatch はモデル呼び出しやトークン数などの使用メトリクスを追跡するのに役立ち、1 つまたは複数の AWS アカウントの 1 つまたは複数の FM にわたって監査目的のカスタマイズされたダッシュボードを構築するのに役立ちます。CloudTrail は、Amazon Bedrock に対するユーザーと API アクティビティの記録を提供するログサービスです。CloudTrail は API データを証跡に収集します（証跡はCloudTrail サービス内で作成する必要があります）。証跡により、CloudTrail はログファイルを S3 バケットに配信できるようになります。 Amazon Bedrock は、モデル呼び出しのログ記録も提供しています。これは、Amazon Bedrock で使用される AWS アカウント内のすべての呼び出しについて、モデルに入力されたデータ、プロンプト、モデルの応答、リクエスト ID を収集するために使用されます。この機能により、モデルがどのように使用されているか、どのようなパフォーマンスを示しているかについての洞察が得られ、お客様とステークホルダーが AI アプリケーションの使用に関して、データに基づいた責任ある決定を下すことができます。モデル呼び出しログは有効にする必要があり、ログデータを S3 バケットと CloudWatch ログのどちらに保存するかを選択できます。 コンプライアンスの観点から、Amazon Bedrock は ISO、SOC、FedRAMP moderate、PCI、ISMAP、CSA STAR Level 2 などの一般的なコンプライアンス基準の対象となっており、Health Insurance Portability and Accountability Act（HIPAA）の対象にもなっています。また、General Data Protection Regulation（GDPR）に準拠して Amazon Bedrock を使用することもできます。Amazon Bedrock は Cloud Infrastructure Service Providers in Europe Data Protection Code of Conduct（ CISPE CODE ）の Public Register に含まれています。これは、Amazon Bedrock が GDPR に準拠して使用できることを独立して検証されたことを意味します。Amazon Bedrock が特定のコンプライアンスプログラムの対象範囲内にあるかどうかについての最新情報は、 コンプライアンスプログラムによる対象範囲内の AWS のサービス を参照し、関心のあるコンプライアンスプログラムを選択してください。 Amazon Bedrock アプリケーションにおける責任ある AI の実装 Amazon Bedrock でアプリケーションを構築する際は、アプリケーションのコンテキスト、ニーズ、エンドユーザーの振る舞いを考慮してください。また、組織のニーズ、法的および規制上の要件、責任ある AI を実装する際に収集したいまたは必要なメトリクスについても検討してください。利用可能な管理機能や組み込み機能を活用してください。以下の図は、責任ある AI の主要なディメンションに対応するために実装できる様々な対策を概説しています。これは網羅的なリストではありませんが、本ブログで言及された対策をどのように組み合わせることができるかの提案です。これらの対策には以下が含まれます。 モデル評価 – モデル評価を使用して、公平さ、正確性、有害性、堅牢性、その他のメトリクスを評価し、選択したFMとその性能を評価します。 Amazon Bedrock ガードレール – Amazon Bedrock ガードレールを使用して、コンテンツフィルター、禁止トピック、単語フィルター、機密情報フィルター、コンテキストグラウンディングの実装を確立します。ガードレールを使用することで、安全でない、または有害なトピックや単語を拒否し、エンドユーザーの安全を保護することでモデルの振る舞いをガイドすることができます。 プロンプトエンジニアリング – CoT などのプロンプトエンジニアリング技術を活用して、AI アプリケーションの説明可能性、正確性と堅牢性、安全性と制御可能性を向上させます。プロンプトエンジニアリングを使用することで、トーン、スコープ、応答の長さを含む、モデル応答の望ましい構造を設定できます。プロンプトテンプレートに禁止トピックを追加することで、安全性と制御可能性を強調できます。 Amazon Bedrock ナレッジベース – Amazon Bedrock ナレッジベースを使用して、エンドツーエンドの RAG 実装を行い、ハルシネーションを減少させ、内部データを使用するケースにおけるモデルの正確性を向上させます。RAG を使用することで、AI アプリケーションの正確性と堅牢性、安全性と制御可能性、説明可能性が向上します。 ロギングとモニタリング – 効果的なガバナンスを実施するために、包括的なロギングとモニタリングを維持します。 責任ある AI のコアディメンションに対応するために実施できる様々な対策の概要図 まとめ 責任ある AI アプリケーションの構築には、計画的で構造化されたアプローチ、反復的な開発、そして継続的な努力が必要です。Amazon Bedrock は、責任ある AI アプリケーションの開発と展開をサポートする堅牢な組み込み機能スイートを提供しています。カスタマイズ可能な機能と独自のデータセットを統合する能力を提供することで、Amazon Bedrock は開発者が特定のアプリケーションコンテキストに AI ソリューションを調整し、責任ある AI に関する組織の要件に合わせることを可能にします。この柔軟性により、AI アプリケーションが効果的であるだけでなく、倫理的で、公平さ、安全性、透明性、アカウンタビリティに関するベストプラクティスに沿ったものであることを確実にします。 責任ある AI のディメンションに従って AI を実装することは、AI ソリューションを透明性を持って、バイアス無く開発し使用するための鍵となります。AI の責任ある開発は、組織全体での AI 採用を促進し、エンドカスタマーとの信頼関係を構築するのにも役立ちます。アプリケーションの使用範囲と影響が広がるほど、責任ある AI のフレームワークに従うことがより重要になります。したがって、 AI の責任ある使用 について、AI の取り組みの早い段階からそのライフサイクル全体を通じて考慮し、対処することが重要です。 機械学習の責任ある使用のためのフレームワークについてさらに学ぶには、以下のリソースを参照してください。 機械学習の責任ある利用（英語） AWS 生成 AI ベストプラクティスフレームワーク v2 ヒューマンインザループを用いた生成 AI プロンプトのチェーン化のワークフロー（英語） 基盤モデル評価のライブラリ（英語） 著者について Laura Verghote は、EMEA の公共部門のお客様向けのシニアソリューションアーキテクトです。複雑なビジネス要件と技術的ソリューションの橋渡しをしながら、AWS クラウドでソリューションの設計と構築をお客様と共に行っています。彼女は AWS に技術トレーナーとして入社し、EMEA 全域の開発者、管理者、アーキテクト、パートナーにトレーニングコンテンツを提供した幅広い経験を持っています。 Maria Lehtinen  は、北欧の公共部門のお客様向けのソリューションアーキテクトです。彼女は信頼できるクラウドアドバイザーとしてお客様と協力し、AI/ML ワークロードに重点を置いたクラウドシステムの開発と実装をサポートしています。彼女は AWS の早期キャリア専門家プログラムを通じて入社し、以前は AWS Advanced Consulting Partner の 1 社でクラウドコンサルタントとして勤務していました。 翻訳はプロフェッショナルサービス本部の藤浦 雄大が担当しました。

AWS Backup は、AWS サービス全体のデータのバックアップを一元化し、自動化するフルマネージドバックアップサービスです。一元管理された AWS クラウドネイティブのソリューションは、ディザスタリカバリやコンプライアンス要件を満たすのに役立つグローバルなバックアップ機能を提供します。 AWS Backup は、Amazon EC2 上で動作する SAP HANA データベース向けに、シンプルでコスト効率が高く、アプリケーションに一貫性のあるバックアップとリストアのソリューションを提供します。前回の AWS Backup for SAP HANA データベースでは、Amazon EC2 上の SAP HANA High Availability データベースをサポートしました。私たちはお客様のニーズに応えるために革新を続け、AWS Backup for SAP HANA データベースが クロスリージョン と クロスアカウント バックアップ をサポートし、AWS のお客様が SAP HANA データベースのバックアップを異なるリージョンやアカウントにコピーできるようになったことを発表できることをうれしく思います。この新機能により、コピーしたバックアップをリストアしたり、必要に応じて クロスリージョン コピーや クロスアカウント コピーを作成したりすることができ、ディザスタリカバリや事業継続の要件を満たすことができます。スナップショットコピーは、ソースアカウントが偶発的または悪意のある削除、災害、ランサムウェアによって中断された場合に、追加の保護レイヤーを提供します。 はじめに このブログでは、オンデマンドバックアップをトリガーとして AWS Backup を使用して SAP HANA データベースのクロスリージョンおよびクロスアカウント バックアップ コピーを実行する方法を示します。 ここに 記載されているすべての手順に従って、すべての 前提条件 と AWS Backup 設定プロセスを完了します。次のステップに進む前に、SAP HANA リソースの保護を オプトイン します。前述の手順が完了したら、以下の手順に従って、ソースリージョンの SAP HANA データベースのオンデマンド バックアップを取ります。 1.  AWS Backup コンソールにアクセスします。 2. Dashboard をクリックし、 Create on-demand Backup を選択します。　 3. Resource type として SAP HANA on Amazon EC2 を選択し、SAP HANA database ID を選択します。　 Backup window 、 Cold Storage 、および Total retention period はデフォルト値のままにしておくか、要件に応じて調整します。 Backup vault は、デフォルトのものを選ぶか、すでにあれば専用のものを使います。 IAM ロールには、AWS Backup がお客様に代わってバックアップを作成・管理する際に想定する IAM ロールを指定し、ページ下部の Create on-demand backup をクリックします。 4. ジョブのステータスを示す画面が自動的に開きます。 ジョブが Completed ステータスになる前に、 Pending と Running のステータスを通過します。ジョブのステータスが Completed になるまで待ちます。 2～4 の手順を繰り返し、TenantDB のバックアップを取ります。 クロスリージョン コピー 5. Backup vaults を選択し、コピーするリカバリ ポイントが含まれるボールトを選択します。 6. Recovery points で、コピーするリカバリポイントを選択します。 7. Action のドロップダウンボタンを使用して、 Copy を選択します。 8. Copy Configuration でコピー先の AWS リージョンを選択し、 Destination Backup vault でコピー先のバックアップボールトを選択します。 (このデモでは、コピー先の AWS リージョンとして Sydney を使用します。） Cold storage と Total retention period はデフォルト値のままにしておくか、要件に応じて調整してください。 IAM ロールについては、AWS Backup がお客様に代わってバックアップを作成・管理する際に想定する IAM ロールを指定し、ページ下部の Create on-demand backup  をクリックします。 9. 一番下の Copy をクリック 10. ジョブ ステータスの画面が自動的に開くので、ステータスが Completed になるまで待ちます。 ステップ#6-9を繰り返して、TenantDB のリカバリポイントを宛先リージョンにコピーします。 また、AWS のドキュメント Scheduling Cross-Region backup で説明されているように、スケジュールされたバックアッププランを使用して、AWS リージョン間でバックアップをコピーすることもできます。 11. コピー先リージョンの AWS Backup コンソールにアクセスします。 12. Backup vaults  を選択し、ソースリージョンからコピーしたリカバリポイントを含むデータボールトを選択します。 13. ソースリージョンからコピーしたリカバリポイントがここにあることを確認します。 HANA データベースのリストア 以下のステップでは、コピー元リージョンからコピーしたリカバリポイントを使用して、コピー先リージョンで既存の HANA データベースのリストアを実行します。 14. SystemDB のリカバリポイント ID を 選択し 、Actions ドロップダウンから Restore を選択します。 15. 次の画面の Target database restore location で 、ソースリージョンからのコピーで上書きする SAP HANA データベースの SystemDB を選択します。 また、次のような警告も表示されます。システムコピーを実行しているときに、ターゲットデータベースに復元するソースデータベースを許可リストに追加するリソースポリシーをアタッチするように求められます。 16. Copy をクリックし、AWS CLI を使用してターゲットの SAP HANA データベースでコマンドを実行します。 17. Advanced restore settings で Don’t restore the catalog を選択し、 Restore backup をクリックします 。 . 18. 次の画面で、ボックスに overwrite と入力します。 19.ジョブステータスの画面が自動的に開くので、ステータスが Completed になるまで待ちます。 手順 #14～18 を繰り返し、TenantDB のリストアを実行します。 注：リソースポリシーをアタッチして、ターゲットデータベースに復元するソースデータベースを許可リストに追加するコマンドは、TenantDB の復元によって異なります。 クロスアカウントのバックアップとリストア このセクションでは、 AWS Backup を使用して SAP HANA データベースのクロスアカウントバックアップとリストアを実行する方法について説明します。ソースアカウントは、AWSリソースとプライマリバックアップが存在するアカウントです。宛先アカウントは、バックアップのコピーを保存するアカウントです。 SAP HANA バックアップのクロスアカウント コピーを有効にする手順 以下の手順に従って、SAP HANA バックアップのクロスアカウント コピーを有効にします。詳細なドキュメントについては、 Setting up Cross-Account backup を参照してください。 1.Management Account in AWS Organizations の管理アカウント 管理アカウントは、AWS Organizations で定義されている組織内のプライマリアカウントで、AWS アカウント全体のクロスアカウント バックアップを管理するために使用します。 a.   AWS Organizations にアクセスし、AWS 組織で管理アカウントを作成します。 b. ソースアカウントとデスティネーションアカウントを AWS Organizations の一部として追加します。このシナリオでは、ソースアカウントが管理アカウントになります。 c. ソースアカウントとデスティネーションアカウントが結合されていることを確認します。 2. AWS Backup コンソールでクロスアカウント バックアップを有効にする 以下の手順に従って、クロスアカウント バックアップを使用するには、ソースアカウントでクロスアカウント バックアップ機能を有効にする必要があります。 a. AWS Organizations 管理アカウントの認証情報を使用してログインします。クロスアカウント バックアップは、これらの資格情報を使用してのみ有効または無効にできます。 b.  AWS Backup console でクロスアカウントバックアップを有効にします。 c. My account で Settings を選択します。 d.  Cross-Account management の Cross-Account backup で、 Enable を選択します。Cross-Account backup Status が On になっていることを確認します。 3. デスティネーションボールト アクセスポリシーを有効にする a. デスティネーションアカウントで AWS Backup console に移動します。 b. Backup vaults で、宛先データボールトを選択します。 c. Access policy セクションで、  Add permissions を選択して  Allow access to a Backup vault from organization を選択します。 backup:CopyIntoBackupVault 以外のクロスアカウント アクションは拒否されます。 d. 次の画面 “Add permissions: Allow access to a Backup vault from organization”  で、 Save policy を選択し ます。 バックアップとリストアのクロスアカウントコピーのために実行するステップ この例では、すでにソースアカウントで  HANA SystemDB と TenantDB の両方のオンデマンドバックアップが成功しています。また、AWS ドキュメントの Scheduling Cross-Account backup にあるように、スケジュールされたバックアッププランを使用して、AWS アカウント間でバックアップをコピーすることもできます。以下の手順に従って、ソースアカウントから宛先アカウントへのオンデマンド HANA データベースバックアップのクロスアカウント コピーを実行します 1. ソースアカウントで、 AWS Backup console にコンソールに移動します。 2. Backup vaults でバックアップ元のバックアップボールトを選択します。SAP HANA データベース SystemDB バックアップの Recovery point ID を選択します。 Actions で Copy をクリックします。 3. 次の画面で、 Copy Configuration の下に、宛先アカウントの リージョン を 指定します。 4. Copy to another account’s vault オプシ ョ ンを設定し、 移動先ア カ ウ ン ト のデー タ ボールトの ARN を指定し ます。 ま た、 Allow Backup vault access で  Allow を ク リ ッ ク し てセカンダ リ ア カ ウ ン ト にバ ッ ク ア ッ プボールトへのバ ッ ク ア ッ プの コ ピーを許可 し ます。 5. Allow Backup vault access? の下にある新しいポップアップ画面で、 Allow をクリックして、バックアップ データをバックアップ データボールトにコピーするために必要なアクセス許可をアクセス ポリシーに与えます。 6. “Backup recovery has been enabled in your corresponding backup vault” というメッセージが表示されます。 7. IAMロールの下で Choose an IAM role を選択します。お客様に代わってバックアップを作成および管理する際に AWS Backup が引き受ける IAM ロールを指定します。 8. Backup details を確認します 。Copy をクリックします。 9. ジョブのステータスが表示される画面が自動的に開き、SystemDB のコピージョブが In-progress で、statusが Running に変わっていることがわかります。status が Completed になるまで待ちます。 上記のステップ#4-12 を繰り返して、TenantDB のコピーを実行します。以下のように、両方のコピージョブが正常に完了したことがわかります。 10. 保存先アカウントに切り替え、 AWS Backup console に移動します。 11. Backup vaults で、 宛先データボールト選択します。バックアップのリカバリポイント ID がソースアカウントから宛先アカウントにコピーされていることがわかります。 12. リストア手順を続行する前に、宛先アカウントの HANA データベースが HDB stop コマンドで停止していることを確認します。  sapcontrol コマンドで SAP プロセスのステータスを確認し、  hdbdaemon のステータスが  ‘GRAY’ および  ‘Stopped’ であることに注意してください。 注： AWS Systems Manager for SAP の新しくリリースされた Start/Stop 機能を使用して、HANA データベースシステムを開始/停止することもできます。 13. コピー先アカウントの AWS Backup console で、コピーした HANA データベースの SystemDB バックアップの Recovery point ID を選択します。 Actions で Restore を選択します。 14. 次の画面 Restore SAP HANA backup で Target database restore location のドロップダウンで、ターゲットの HANA SystemDB をリストア先として選択します。 15. また、ターゲットデータベースにリストアするソースデータベースを許可するために、必要なリソースポリシーを追加する必要があります。 Copy を クリックして CLI コマンドをコピーし、添付します。 16. セカンダリアカウントの AWS CLI から、以下のようにコピーしたコマンドを実行し、必要なポリシーをアタッチします。 17. Restore SAP HANA バックアップ コンソールに戻り、 Restore 権限 を確認します。 18. Advanced restore settings で、 Don’t restore the catalog を選択し、 Restore backup をクリックします 。 19. Restore backup and overwrite database の下に overwrite と入力します。 Restore backup を選択します。 20. 以下のようにリストア作業が進行中であることがわかります。 21. SystemDB のリストアジョブの status が Completed と表示されたら、TenantDB のリストアを実行します。手順#14-21を繰り返して、TenantDB のリストアを実行します。TenantDB のリストアジョブの status が Completed になっていることを確認します。 注：リソースポリシーをアタッチして、ターゲットデータベースに復元するソースデータベースを許可リストに追加するコマンドは、TenantDB の復元によって異なります。 22.  EC2 コンソールに 移動し、 AWS Session manager を使用して、デスティネーションアカウントのHANAデータベースにログインします。 <sid>adm ユーザーでログインし、 sapcontrol  コマンドで SAP プロセスのステータスを確認します。HANA SystemDB と TenantDB データベースが正常にリストアされ、すべてのプロセスが以下のように GREEN ステータスを表示していることを確認します。 まとめ このブログでは、AWS Backup サービスを使用して、クロスリージョンおよびクロスアカウントデータベースのバックアップとリストアを実行する方法を学びました。AWS Backup を使用して SAP HANA データベースのクロスリージョンおよびクロスアカウント バックアップ機能を使用すると、運用上またはセキュリティ上の理由から、組織内の 1 つまたは複数のリージョンまたはクロスアカウントにバックアップを安全にコピーすることができます。 月に請求されるクロスリージョンの金額は、2 つのリージョン間で転送されたデータ量であり、単一の AWSア カウント内または 2 つの AWS アカウントにまたがって転送されたデータ量です。AWS リージョンからデータを転送する場合にのみデータ転送料金が発生し、同じ AWS リージョン内での転送には料金は発生しません。データ転送料金は、データを転送するAWS アカウントに請求されます。バックアップストレージの料金は、データを受け取る AWS アカウントに請求されます。バックアップボールトからのデータ転送の料金は同じです。 AWS Backup サービスを始めるには、以下のドキュメントとブログを確認することをお勧めします。 SAP HANA databases on Amazon EC2 instances backup Automate and Simplify SAP HANA Backups with AWS Backup Simplify SAP Backups with AWS Services SAP ワークロードの移行、モダナイゼーション、革新において AWS が何千ものお客様から信頼されている理由については、 SAP for AWS のページをご覧ください。 翻訳は SAP Specialist SA 菅谷が担当しました。原文は こちら です。

はじめに Amazon Web Services（AWS）には、あらゆる規模の組織のニーズを満たす SAP の導入パターンが複数用意されています。AWS では、 AWS patterns for Resilience に従って、SAP のワークロードは AWS リージョン内の複数のアベイラビリティゾーン（AZ）にまたがって展開することができます。 当社の標準的な推奨事項は、SAP システム（例：S/4HANA または ECC ）に複数の SAP アプリケーションサーバーがある場合、SAP システムの可用性と信頼性を全体的に向上させるために、これらのアプリケーションサーバーを異なる AZ に展開することです（図1参照）。 図1：マルチ AZ に分散した複数の SAP アプリケーションサーバーを持つ SAP アプリケーション 図1 は簡略化したアーキテクチャ図であり、(1) SAP ユーザーは SAP アプリケーションサーバーに接続し、(2)アプリケーションサーバーはデータベースサーバーに接続します。 SAP のクライアント／サーバーアーキテクチャでは、アプリケーション層のスケールアウト、つまり複数の SAP アプリケーションサーバーを追加することで、大規模な SAP ワークロードをサポートすることができます。 このアーキテクチャのトレードオフは、一部のワークロード（パフォーマンスが重要なバッチジョブなど）において、AZ  間のレイテンシがランタイムパフォーマンスに影響する可能性があることです（ SAP Lens for Well Architected – Performance recommendations for latency および  SAP ノート 3496343 （SAP サポートポータルへのアクセスが必要です）参照）。 このブログでは、この問題を軽減するために、データベースサーバーと同じ AZ でホストされているアプリケーションサーバー上でバッチまたはパフォーマンスが重要なワークロードを実行するソリューションについて説明します。 レイテンシーに関する SAP の推奨 ブログ “ End-to-End Observability for SAP on AWS： Part 2 – SAP Network Latency Monitoring “では、SAP アプリケーション層とデータベース層間の SAP ネットワークパフォーマンスの重要性について説明しました。 パフォーマンスの良い SAP システムのためには、SAP アプリケーション層（つまりアプリケーションサーバー）とデータベースサーバー間のネットワークレイテンシが以下の SAP の推奨に従っていることを確認することが重要です： SAP ノート 1100926 に従って、SAP アプリケーションサーバーとデータベースサーバー間のネットワーク遅延を 0.7 ミリ秒（ms）未満にすること（SAP サポートポータルへのアクセスが必要です） 同期データレプリケーションを使用した HANA システムレプリケーションのネットワークレイテンシ（データ損失をゼロにするために必要）を 1ミリ秒未満 にすること AWS for SAP におけるレイテンシの影響 一般的に、AZ 間ネットワークのレイテンシは、上記の SAP のネットワーク推奨値を遵守しています。 ただし、このレイテンシは時間の経過とともに変化し、リージョンや AZ ペアによっても異なります。 お客様は、 AWS Network Manager – Infrastructure Performance または  SAP の NIPING （SAP サポートポータルへのアクセスが必要）を使用して、AZ 間のネットワークレイテンシ（Inter-AZ ネットワークレイテンシとして知られている）と同じ AZ 内のネットワークレイテンシ（Intra-AZ ネットワークレイテンシ）を測定することができます。 AZ 間の地理的距離を考慮すると、AZ 内ネットワークレイテンシは AZ 間ネットワークレイテンシよりも低くなります。 したがって、AZ 間の高可用性を実現するために SAP ワークロードをアーキテクトする場合は、ネットワークレイテンシが最も低い AZ ペアで展開することをお勧めします。 パフォーマンスクリティカルな SAP ビジネスプロセスの例として、自動車、消費財、食品・飲料、製薬などの製造業で使用されるバックフラッシュプロセス（自動出庫）があります。 自動車業界では、バックフラッシュプロセスでは、生産オーダーが確定すると、部品表（BOM）とルーティングに基づいて、在庫から原材料や部品の必要量を自動的に差し引きます。 例えば、あるメーカーが 100 個の自動車エンジンを生産する場合、各エンジンに 4 個のピストン、8 個のバルブ、1 個のクランクシャフトが必要であれば、バックフラッシュプロセスは、手入力することなく、自動的に 400 個のピストン、800 個のバルブ、100 個のクランクシャフトを在庫から差し引きます。 これにより、効率的で正確な在庫管理が保証され、手作業によるデータ入力が削減され、生産進捗と材料使用に関するリアルタイムの最新情報が提供されます。 このバックフラッシュプロセスの動作が遅いと、製造ラインの生産性に影響が出ます。 バックフラッシュプロセス（トランザクション MFBF）に対する AZ 間ネットワーク遅延の影響を理解するため、図2 に示すテストを実行しました。このテストによると、データベースサーバーとは異なる AZ にあるアプリケーションサーバー 2 および 3 で実行した場合、RFC 実行時間のパフォーマンスが 4～10 倍低下しました。 図2：パフォーマンスクリティカルなジョブおよびトランザクションに対する AZ 間ネットワーク遅延の影響の比較 図 2 によると、AZ 間レイテンシは、長時間実行されるトランザクションや、大量のデータベース呼び出し （ラウンドトリップ）を行うタイムクリティカルなパフォーマンス要件のバッチジョブに大きな影響を与えます。 したがって、レイテンシがより低い AZ  内ネットワークに利点があるため、これらのジョブをデータベースサーバーと同じ AZ 内の SAP アプリケーションサーバーで実行することをお勧めします。 次のセクションで説明するソリューションは、障害が発生し、プライマリデータベースがある AZ から別の AZ に移動した場合でも、このプロセスを自動化するのに役立ちます。 SAP ネットワークのパフォーマンスを自動的に最適化 SAP のワークロードが適切に管理され、SAP アプリケーションサーバーに均等に分散されるように、SAP は以下のワークロード バランシングまたは分散メカニズムを提供しています： 表1：SAPの負荷分散メカニズム 図3 のように、高可用性を備えた SAP S/4HANA を実行し、複数の SAP アプリケーションサーバーがデータベースサーバーに接続している自動車関連企業の例を見てみましょう。 パフォーマンスクリティカルなバックフラッシュバッチジョブは、表 1 にあるように、SAP の負荷分散メカニズムを使用してアプリケーションサーバー 1 で実行されるように構成されています。 図3：パフォーマンスクリティカルなジョブ/トランザクションについて、プライマリーデータベースと同じ AZ にあるアプリケーションサーバーを指すように SAP の負荷分散メカニズムを調整する パフォーマンスクリティカルなトランザクション / ジョブ用のログオン / バッチ / RFC サーバーグループは、プライマリ DB と同じ AZ にあるアプリケーションサーバー 1 を指すように構成されています。 プライマリ DB からスタンバイ DB にデータベースサーバーがフェイルオーバーした場合、アプリケーションサーバー1 から実行されるパフォーマンスクリティカルなトランザクション/ジョブは、AZ 内のネットワークレイテンシーがわずかに高くなるため、パフォーマンスが低下します。 この問題を解決するには、ログオン / バッチ / RFC サーバーグループを調整し、代わりにアプリケーションサーバー 2 を指すようにする必要があります。 提案するソリューションは、データベースと同じ AZ にあるアプリケーションサーバーを指すように、SAP の負荷分散メカニズム（ログオングループ、バッチサーバーグループ、RFCサーバーグループ）を自動的に更新します。 これにより、データベースのフェイルオーバー / フェイルバックが発生した場合でも、パフォーマンスが重要なトランザクションとジョブは、データベースと同じ AZ 内のアプリケーションサーバーで処理されます。 図4 は、提案ソリューションのハイレベル アーキテクチャを示しています。 図3 にアプリケーションサーバーを追加したものと似ています。 このソリューションは SAP の ABAP 言語で開発されているため、 AWS SDK for SAP ABAP を活用し、以下のステップ 4 に従って、 Amazon Simple Notification Service（SNS） を介して、SAP システムを管理する IT チームにこの変更の通知を送信することができます。 図 4 : SAP サーバーグループの動的更新と AWS ABAP SDK による通知 マルチ AZ ネットワーク最適化ソリューションの構築 このソリューションは、SAP ABAP 言語を使用するため、ABAP スタックを使用するあらゆる SAP アプリケーションとの互換性を保証し、RISE with SAP を含む、SAP Netweaver ABAP アーキテクチャ上で動作するあらゆる SAP for AWS 環境にインストールすることができます。 重要な考慮事項 このソリューションは、SAP S/4HANA 2023 で正常にテストされました。 ログオングループと RFC サーバーグループ (RZ12) を変更するために、このソリューションは SMLG_MODIFY 関数モジュールを使用します。 バックグラウンド処理グループ（SM61）を変更するには、CL_BP_SERVER_GROUP クラスを使用します。 AWS SDK for SAP ABAP から通知機能を使用する場合は、 Getting Started with the AWS SDK for SAP ABAP Blog を参照してください。 サンプル ABAP コードは、 Multi-AZ Network Optimized Solution github にあります。 3 つのロードバランシングメカニズムのいずれかを使用することができます（例えば、バッチサーバーグループのみを更新し、ログオングループと RFC サーバーグループはそのままにしておくことができます）。 パフォーマンスが重要なバッチジョブや、大量の RFC 呼び出しを行うジョブは、バッチサーバーグループと RFC サーバーグループを更新して、これらのジョブがデータベースと同じ AZ にあるアプリケーションサーバーで実行されるようにするのが得策です。 以前の S/4HANA または SAP ECC のバージョンでソリューションを実装したい場合は、上記の両方の機能モジュールの可用性を確認し、最初に Non-Production システムでテストしてください。 AZ/DB 障害の検出 AZ および/またはデータベースに障害が発生すると、スタンバイ データベースインスタンスは 高可用性クラスタソフトウェアによってアクティブな役割に変更されます。 そのため、プライマリデータベースインスタンスのホスト名が変更されます。このホスト名は、ABAP の SQL クエリで確認できます。 図5 : ソリューションのワークフロー このソリューションでは、2つのテーブルを使用します： /AWSSAMP/MAZ_DB : SQL クエリで取得したプライマリデータベースのホスト名が含まれています。 /AWSSAMP/MAZ_CO : アプリケーションサーバーと定義されたログオン/サーバーグループのコンフィギュレーション情報が含まれています。 このテーブルは、プライマリデータベースに対するアプリケーションサーバーの AZ を決定します。 図 6 : それぞれのログオン/サーバーグループに割り当てられたアプリケーションサーバーを示す表 /AWSSAMP/MAZ_CO AZ /データベースの障害状況を検出するコード スニペットです。 この SQL 実行結果をテーブル /AWSSAMP/MAZ_DB に保存しておけば、次回プログラム実行時に、データベースのホスト名が前回実行時と変わっていれば、AZ やデータベースに障害が発生したと判断できます。 DATA: lv_hostname TYPE char20. lo_con TYPE REF TO cl_sql_connection, lo_stmt TYPE REF TO cl_sql_statement, lo_result TYPE REF TO cl_sql_result_set, lv_sql TYPE string, lt_data TYPE REF TO data. TRY. lo_con = cl_sql_connection=>get_connection( ). lo_stmt = lo_con->create_statement( ). lv_sql = |select host from M_DATABASE|. lo_result = lo_stmt->execute_query( lv_sql ). get REFERENCE OF lv_hostname into lt_data. lo_result->set_param( lt_data ). lo_result->next( ). lo_con->close( ). CATCH cx_sql_exception INTO DATA(err). MESSAGE err->get_text( ) TYPE 'E'. ENDTRY. DATA: lo_get_dbhost TYPE REF TO /AWSSAMP/CL_MAZ_GET_DBHOST. * Get a result of previous execution. SELECT * INTO TABLE lt_dbhost FROM ZTAWSMULTIDB. * Compare a current SQL execution with the previous execution LOOP AT lt_dbhost INTO ls_dbhost. * If it is different, Updating the current result to a temporary table. IF lv_hostname NE ls_dbhost-dbhost. ls_current_dbhost-mandt = '100'. ls_current_dbhost-dbhost = lv_hostname. * Update current Active DB Hostname into /AWSSAMP/MAZ_DB UPDATE /AWSSAMP/MAZ_DB FROM ls_current_dbhost. ENDIF. ENDLOOP. ログオン/ RFC サーバーグループの変更 ログオングループはトランザクションコード  SMLG   で変更でき、RFC サーバーグループはトランザクションコード RZ12 で変更できます。 SAP Netweaver ABAP スタックには、これら 2 つのグループを照会および変更するための SMLG_GET_DEFINED_SERVERS および SMLG_MODIFY 標準関数が用意されています。 サーバーグループを変更する前に、SMLG_GET_DEFINED_SERVERS 関数を呼び出して現在登録されている既存のアプリケーションサーバーを確認し、SMLG_MODIFY 関数を呼び出して既存のアプリケーションサーバーを削除して新しいアプリケーションサーバーをリストに登録します。 以下は、ログオンおよび RFC サーバーグループを変更するためのコード スニペットです。 GROUPTYPE 入力パラメータでグループのタイプを指定します。 例えば、’S’ は RFC サーバーグループを意味します。 SMLG_MODIFY 関数は、グループ内のアプリケーションサーバーの削除や挿入にも使用されるため、サンプルコード 2 に示すように、MODIFICATN パラメータに適切なタイプを入力する必要があります。 例えば、削除を行う場合は ‘D’ を入力します。 DATA: BEGIN OF ls_group, group_name TYPE char20, group_type TYPE char1, END OF ls_group. DATA: lt_group LIKE TABLE OF ls_group, lv_grouptype TYPE char1. DATA: lt_modi TYPE TABLE OF RZLLIMODIF, ls_modi TYPE RZLLIMODIF, lt_del_server TYPE TABLE OF RZLLIAPSRV. ls_modi-CLASSNAME = ls_group-group_name. ls_modi-GROUPTYPE = ls_group-group_type. * Function Modification Type * I. insertion of an item * D. deletion of an item * U. update of an item ls_modi-MODIFICATN = 'D'. ls_modi_erfc-CLASSNAME = ls_group-group_name. ls_modi_erfc-GROUPTYPE = ls_group-group_type. ls_modi_erfc-MODIFICATN = 'U'. INSERT ls_modi_erfc INTO TABLE lt_modi_erfc. * Get exisiting application servers in Logon/RFC server group * Sever Group Type * '' Logon Server Group * 'S' RFC Server Group CALL FUNCTION 'SMLG_GET_DEFINED_SERVERS' EXPORTING GROUPTYPE = ls_group-group_type GROUPNAME = ls_group-group_name TABLES INSTANCES = lt_del_server EXCEPTIONS no_group_found = 1 OTHERS = 2. * Change application servers in Logon/RFC server group. CALL FUNCTION 'SMLG_MODIFY' EXPORTING GROUPTYPE = lv_grouptype TABLES MODIFICATIONS = lt_modi ERFC_MODIFICATIONS = lt_modi_erfc EXCEPTIONS no_group_found = 1 OTHERS = 2. バッチサーバーグループの変更 バッチサーバーグループは、トランザクションコード SM61 で変更できます。 SAP Netweaver ABAP スタックには、これを表示および変更するための標準クラス CL_BP_SERVER_GROUP が用意されています。 変更が必要なグループに関する情報を取得するには、LOAD_DB メソッドを呼び出す必要があります。LOAD_DB メソッドは保護されたセクションとして宣言されているので、このクラスを継承した別のカスタムビジネスオブジェクト（CBO）クラスを作成します。 以下は、バックアグラウンド処理グループを変更するためのコード スニペットです。 クラス内の LOAD_DB メソッドと GET_LIST メソッドを呼び出して既存のアプリケーションサーバー リストを取得し、DEL_FROM_LIST メソッドを呼び出して既存のアプリケーションサーバー リストを削除し、ADD_TO_LIST メソッドを呼び出して新しいアプリケーションサーバーを登録します。 変更を確実に保存するには、SAVE_DB メソッドを呼び出します。 * /AWSSAMP/CL_MAZ_BP_GROUP Class Definition CLASS /AWSSAMP/CL_MAZ_BP_GROUP DEFINITION INHERITING FROM CL_BP_SERVER_GROUP. PUBLIC SECTION. METHODS : LOAD_SRV_LIST IMPORTING p_groupname TYPE char20, GET_SRV_LIST EXPORTING p_list TYPE BPSRVENTRY, DEL_FROM_SRV_LIST IMPORTING p_srv TYPE BPSRVLINE, ADD_TO_SRV_LIST IMPORTING p_srv TYPE BPSRVLINE, SAVE_SRV_LIST_DB. ENDCLASS * /AWSSAMP/CL_MAZ_BP_GROUP Class Implementation CLASS /AWSSAMP/CL_MAZ_BP_GROUP IMPLEMENTATION. * LOAD_SRV_LIST method to call LOAD_DB. To load a group information from DB. METHOD LOAD_SRV_LIST. TRY. CALL METHOD LOAD_DB EXPORTING i_name = p_groupname. CATCH CX_BP_HEALTH_DATA. MESSAGE 'Data Inconsistency Found.' TYPE 'E'. CATCH CX_UUID_ERROR. MESSAGE 'Error Class for UUID Processing Errors.' TYPE 'E'. ENDTRY. ENDMETHOD. * GET_SRV_LIST method to call LOAD_DB. To get servers for a list. METHOD GET_SRV_LIST. CALL METHOD GET_LIST RECEIVING o_list = p_list. ENDMETHOD. * DEL_FROM_SRV_LIST method to call DEL_FROM_LIST. To delete a server in a list. METHOD DEL_FROM_SRV_LIST. CALL METHOD DEL_FROM_LIST EXPORTING I_SRV_ENTRY = p_srv. ENDMETHOD. * ADD_TO_SRV_LIST method to call ADD_TO_LIST. To add a server in a list. METHOD ADD_TO_SRV_LIST. CALL METHOD ADD_TO_LIST EXPORTING I_SRV_ENTRY = p_srv. ENDMETHOD. * SAVE_SRV_LIST_DB method to call SAVE_DB. To save a list in a DB. METHOD SAVE_SRV_LIST_DB. TRY. CALL METHOD SAVE_DB. CATCH CX_BP_DATABASE. MESSAGE 'An Error Occurred While Attempting to Write to DB.' TYPE 'E'. ENDTRY. ENDMETHOD. ENDCLASS. ABAP プログラムを定期的に実行するバックグラウンドジョブを作成する トランザクションコード SM36 を使用してバックグラウンドジョブを作成すると、ABAP プログラム（ /AWSSAMP/MAZ_SOL ）を定期的（たとえば 5 分ごと）に実行できます。 ジョブの作成時に、 Edit > Start time メニューから実行間隔を設定できます。 図 7 : トランザクション SM36  のジョブ設定 上記の Multi-AZ ネットワーク最適化ソリューション は、1 時間以内に SAP シ ステムに適用し、テストすることができます。 また、 AWS SDK for SAP ABAP を使用して Amazon SNS サービスに通知を発行し、SAP チームに電子メールまたは SMS でアラートを通知する機能も含まれています。 まとめ 企業のビジネスプロセスの中核となる SAP ソリューションには、可用性と信頼性の高いアーキテクチャを用意することが重要です。そのため、AWS は、 SAP lens Well-Architected Framework – Select an architecture suitable for your availability and capacity requirements に従い、SAP アプリケーションを複数の Availability Zone にわたってアーキテクトすることを推奨しています。 SAP トランザクションとバッチジョブの最適なパフォーマンスを確保するために、データベースサーバーのフェイルオーバー時に SAP ログオングループ（トランザクション SMLG）、RFC サーバーグループ（トランザクション RZ12）、バッチサーバーグループ（トランザクション SM61）の自動切り替えを有効にすることができます。 これにより、パフォーマンスが重要なトランザクションとバッチジョブは、常にデータベースサーバーと同じ AZ のアプリケーションサーバー上で実行されます。 このブログでは、ビジネスクリティカルなトランザクションやバッチジョブの最適なパフォーマンスを確保しながら、マルチ AZ アーキテクチャで高可用性と高信頼性を実現するために、SAP for AWS のメリットをどのように活用できるかをご紹介しました。 詳細については、 Multi-AZ network optimized solution github page でサンプルコードをご覧ください。 何千ものお客様が AWS for SAP を選択する理由については、 AWS for SAP のページ をご覧ください。 SAP for AWS のディスカッションに参加する お客様のアカウントチームと AWS サポートチャネルに加えて、私たちは re:Post – A Reimagined Q&A Experience for the AWS Communityを立ち上げました。 弊社の AWS for SAP Solution Architecture チームは、AWS for SAP のトピックを定期的に監視し、お客様やパートナー様を支援するためのディスカッションや質問にお答えしています。 もしあなたの質問がサポートに関連したものでなければ、re:Post で議論に参加し、コミュニティのナレッジベースに追加することを検討してください。 翻訳は SAP Specialist SA 菅谷が担当しました。原文は こちら です。

はじめに アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）はファクトセット・パシフィック様（以下、FactSet ）との共催で 2024 年 11 月 19 日に、 資産運用会社向けイベントを開催しました。 本イベントでは、資産運用業務に携わる企業の方々 （ 96 名） にご参加いただき、データ活用及び生成 AI の最新情報を AWS ジャパン、お客様セッション、パートナーセッションを通じてご紹介いたしました。また資産運用業界内のネットワーキングを目的とした懇親会も実施しました。本記事では、イベント開催概要と当日の内容をご紹介いたします。 【開催概要】　　 開催日時： 2024 年 11 月 19 日（火） 開催場所： AWS ジャパン 目黒オフィス 参加者人数： 96 人 当日のアジェンダ 第一部をセミナー、第二部を懇親会と分けて開催いたしました。第二部の懇親会では登壇企業、参加者同士のネットワーキングを実施しました。 オープニング AWS ジャパン 金融事業統括本部 銀行営業本部長 金子 達也 イベント冒頭では、AWS ジャパン金融事業統括本部 銀行営業本部長 金子 達也より開会のご挨拶をいたしました。本イベント開催の目的について、資産運用業界のデータ駆動型意思決定の加速と共創の場（コミュニティ）の醸成、業界全体の成長促進であることを述べました。 最後に「 AWS は、データ分析および AI / ML 、生成 AI によりイノベーションを提供し、データ駆動型の意思決定を行う為の DX 推進をパートナーと共に支援します。また本イベントを通じて、資産運用業界のリーダーや革新的な企業と連携し、ナレッジシェアとベストプラクティス共有の場を作ることで、未来志向の解決策を共に模索することができ、持続可能な成長支援を行ってまいります」と結びました。 金融業界のイノベーションを支える AWS AWS ジャパン 金融事業開発本部長 飯田 哲夫 次に AWS ジャパン 金融事業開発本部長 飯田 哲夫が登壇し、クラウドにおけるデータ活用の広がりとして金融機関の事例を紹介し、資本市場を始めとした金融領域においてクラウドがビジネス変革を推進している要因について述べました。 資産運用業界では、データ・生成 AI の広がりとして、投資判断、運用アドバイスのパーソナライゼーション、アナリスト支援など、様々なユースケースが出てきており、金融サービスにビジネス価値をもたらしていることを解説しました。 また、AWS の活用は、責任共有モデルや第三者認証による評価からも安全なデータ管理の下で活用することができるため、AWS パートナーとの連携を通じて、業務のライフサイクル全体に渡ってご支援させていただくことについても紹介しました。 お客様、パートナーセッション お客様、パートナーセッションでは、ニッセイアセットマネジメント株式会社と FactSet 、株式会社ナウキャストの 3 社が登壇しました。 ニッセイアセットマネジメント株式会社 ニッセイアセットマネジメント株式会社 デジタルイノベーション・ヘッド 山田 智久氏 まずは、ニッセイアセットマネジメント株式会社デジタルイノベーション・ヘッドの山田 智久氏によるご登壇です。 生成 AI の活用として大きく 2 つの事例を発表いただきました。 1 つ目の事例は、 分析業務特化型 AI チャットボット です。投資先企業へのインタビューを行う前の調査業務を効率化するため、生成 AI （ Amazon Bedrock-Claude 3 Opus ）を活用した分析業務特化型 AI チャットボットを構築されました。これにより、統合報告書や ESG 関連書類からの情報抽出や、自社独自の評価観点に基づく情報整理などの分析作業効率が 3 ～ 5 倍に向上されたことや、利便性が認められ、他の運用部門への利用も拡大予定ということをお話いただきました。 2 つ目の事例は、自社ファンドへの投資を検討中の機関投資家などから会社概要やファンドの運用内容について照会を受け、回答を作成する Request for Proposal 業務（以下、RFP 業務）の改善に向けた取り組み事例 についてです。RFP 業務は処理すべき情報量が多いだけでなく、依頼元ごとにフォーマットや書き方が異なるため、資産運用会社にとって非常に業務負荷の高い作業です。そこで、RFP 業務の効率化を図るため、生成 AI（ Amazon Bedrock-Claude 3.5 Sonnet / Amazon Titan ）を活用し、担当部署の振り分け作業、回答作成作業の 2 つの業務で本格活用に向け PoC を開始しているとご説明されました。 また、事例とは別に、 資産運用会社同士で様々な業務への生成 AI 適用の検討を目的とした勉強会 を主催する取り組みについてもご発表いただき、複数社合同でナレッジ共有やディスカッションを通じて、生成 AI を活用したソリューションを具体的に検討していきたいと今後の展望についても語られました。 FactSet FactSet 日本アナリティクス担当ディレクター 若林大毅氏 続いては、FactSet 日本アナリティクス担当ディレクター若林大毅 氏にご登壇いただきました。 安全なデータプラットフォームの構築と、多様なデータの統合が重要な課題となっている状況下で、FactSet がどのように環境構築の支援を出来るかについてご説明いただきました。 FactSet の強みとして、 100 種類以上のデータセット や 80 以上のプロバイダー からのデータを統合し、 20 以上のカテゴリーのコンテンツ を保有し、資産運用の各種業務領域に求められるデータ統合、分析、配信を一気通貫で提供していることを挙げられました。さらに、API やデータ共有機能を使用することで、リアルタイムでのデータ更新や変換が可能となり、社内データと外部データをスムーズに統合することができるだけではなく、一般的なマーケットデータや企業独自のデータを統合する際にも、ポートフォリオの要因分析やシナリオ分析など、多角的な視点からデータを評価することができるようになることについてもご紹介いただきました。 また、昨今では FactSet の持つデータプラットフォームに生成 AI を連携させることで、異なる種類のデータの統合、分析、共有をより効率的に行うことができ、こうした強力なデータ管理体制と多様なデータ統合を実現することで、AI や ML 技術を活用した高度な分析環境の構築に繋がると述べました。 株式会社ナウキャスト 株式会社ナウキャスト データ & AI ソリューション事業責任者 片山 燎平氏 最後は、株式会社ナウキャスト データ & AI ソリューション事業責任者 片山 燎平氏によるご登壇です。 生成 AI を駆使し、 資産運用業務の効率化を目指した事例 、および 本格的な活用に向けたポイント についてご紹介いただきました。 生成 AI 活用事例のパートでは、3 つの事例についてお話いただきました。1 つ目は、膨大な決算短信・有価証券報告書から情報を抽出・要約する業務。2 つ目は、顧客専用の高精度書き起こしモデルを半自動で構築するサービスの提供。3 つ目は、JCB消費NOW における消費動向データに対し、LLM によるコメントレポートを生成する業務の試験的な導入についてです。 さらに、資産運用業務の効率化に向け生成 AI を様々にご活用いただく中で、企業における生成 AI の本格的な活用に向けたポイントとして ①埋め込み型のユースケース、②データ蓄積、③組織作り の 3 点が重要であると述べました。生成 AI がタスクをこなすために十分なデータを裏側で AI に与え、その機能を業務システムやサービスに埋め込むことで、シームレスに高付加価値の機能を利用することができます。それに伴い、これまで以上にデータ基盤構築の重要性が高まり、データを活用することができる組織作りが求められてくるとお話いただきました。 最後に「資産運用業界における生成 AI 技術は、単なる業務の自動化を超えて、より戦略的で価値の高い業務に集中できる環境を創出しつつあります。今後も、技術の進化と組織的なアプローチの深化が期待されます」と結びました。 ※JCB消費NOW： 株式会社ナウキャストが提供する匿名加工されたクレジットカード決済データをもとにした国内消費指数 懇親会 懇親会の様子 第二部の懇親会では、資産運用業務に携わる企業の方々とセッションに登壇いただいた方々によるネットワーキングを実施しました。この機会を通じて、普段は接点の少ない方々との意見交換が活発に行われ、新たなビジネスチャンスや関係性構築に繋がる可能性を秘めた有意義な時間となりました。 おわりに 本イベントを通じて、資産運用業務におけるデータ・生成 AI 活用がもたらす無限の可能性を目の当たりにしました。本イベントは、ご参加いただいた企業の皆様、そして共催の FactSet 様のご協力なくしては実現しませんでした。心より御礼申し上げます。今後も皆様に役立つ情報をセミナーやブログで発信していきます。どうぞよろしくお願い致します。

今日の世界では、サステナビリティ ( 持続可能性 ) があらゆる業界の企業の大きな関心事となっています。気候変動や天然資源の減少という課題に直面する中、組織にとって、環境への影響を減らすために積極的な措置を講じることは不可欠です。 廃棄物を削減 し、環境負荷を最小限に抑え、再生可能エネルギーへシフトすることで、私たちはサステナビリティを促進できます。これは、すべての人々と企業に関わる目標であり、より持続可能な未来を実現するための集団的行動の必要性を強調しています。 環境・社会・ガバナンス（ESG）投資は、より多くの投資家が財務リターンだけでなく、社会にポジティブな成果をもたらすことを求めるようになるにつれて勢いを増しています。この傾向は、より持続可能で責任ある事業慣行が企業の全体的なパフォーマンスとリスクプロファイルに関連しているという信念の高まりを反映しています。 特にコンタクトセンターは、データベースやコンタクトセンターソフトウェアをホストする専用のサーバー、コンタクトセンターの電話システム、エージェントのワークステーション、エージェントが所在する建物に電力を供給するためのエネルギー消費によって、カーボンフットプリントが大きくなります。したがって、コンタクトセンターソリューションを選択する際、 ESG 基準やより持続可能で責任ある事業を実施すれば、長期的な利益を得たり、企業の評判を向上させることができます。 このブログでは、 AWS が提供するフルマネージドでクラウドベースのコンタクトセンターサービスである Amazon Connect を使用してコンタクトセンター運用を構築するためのサステナビリティのベストプラクティスについて説明します。クラウドを活用し、リソース利用を最適化し、AWS のサステナビリティへの取り組みに沿うことで、組織がコンタクトセンター運用の環境への影響をどのように削減できるか説明します。 一般的なコンタクトセンター 論文 Markov Models and Their Use for Calculations of Important Traffic Parameters of Contact Center (Erik Chromy, Jan Diezka, Matej Kavacky) で示されている通り、従来のコンタクトセンターアーキテクチャは、通常、コンタクトセンター電話システム ( 構内交換機 (PBX) と自動着信呼分配 (ACD)) と、コンピュータ電話統合 (CTI) 、音声自動応答 (IVR) 、コールマネジメントシステム (CMS) 、音声録音 (VR) 、キャンペーンマネージャー (CM) などのコンタクトセンターシステムで構成され、これらはすべてデータセンターで稼働しています。さらに、ワークステーションと電話回線を備えたエージェントとスーパーバイザーの職場があります。 従来のコンタクトセンターのアーキテクチャ Markov Models and Their Use for Calculations of Important Traffic Parameters of Contact Center (Erik Chromy, Jan Diezka, Matej Kavacky) より引用 コンタクトセンターのデータベースやシステムをホストするデータセンターは、専用サーバーの電力供給、冷却、インフラストラクチャ、およびデータセンター運用に関連するその他の活動のためのエネルギー消費により炭素を排出します。電話の発信や受信のための PBX や IP-PBX システムを含むコンタクトセンターの電話システムも、そのエネルギー消費により炭素を排出します。アナログ PBX システムは、物理的なハードウェアと銅線配線の必要性により、通常より多くのエネルギーを使用し、 セットアップ の規模と複雑さに応じて 100W から 500W のエネルギー使用量となります。デジタルおよび IP-PBX システムはより省エネルギーで、エネルギー使用量は 50W から 200W の範囲です。 さらに、コンタクトセンターは通常、各エージェントに顧客とのやり取りを処理するための専用デスクトップコンピューターとモニターを提供しています。 Journal of Corporate Real Estate の Govil, M., & Panda, M. (2013) による「Sustainable Contact Centers: Strategies for reducing energy consumption and carbon emissions」によると、デスクトップ PC は 60W から 250W の電力を消費し、モニターはワークステーションの消費電力を 30% から 50% 増加させる可能性があります。 世界経済フォーラム の調査によると、世界のエネルギー関連の炭素排出量の 40% はコンタクトセンターのような施設を含む建物から発生しています。さらに、 従業員が集中型のコールセンターに通勤 することで、交通渋滞、炭素排出、大気汚染が増加しています。 Amazon Connect: サステナブルなコンタクトセンターソリューション 従来のオンプレミスのデータセンターで運用されるコンタクトセンターとは対照的に、Amazon Connect は AWS が提供するフルマネージドのクラウドコンタクトセンターサービスです。Amazon Connect のワークロードは、以下のレイヤーに分けることができます：電話、Amazon Connect インターフェース/API、コンタクトフロー/IVR、エージェントワークステーション、メトリクスとレポーティングです。これらは従来のコンタクトセンターにおける、CTI、IVR などのコンタクトセンターアプリケーションと対応しています。 Amazon Connect のアーキテクチャには、炭素の排出を削減できる複数のコンポーネントがあります。 Amazon Connect は、AWS の グローバルインフラストラクチャ 上で実行されるマネージドクラウドサービスとして、AWS クラウドのサステナビリティの利点を最大限に活用しています Amazon Connect は、同じ効率的なインフラストラクチャ上で実行されるマネージドな電話サービスを提供します。これにより、電話の発信と受信のための PBX や IP-PBX システムの必要性が排除され、それに伴う炭素排出量も削減されます WebRTC 通話により、PBX システムや専用のエージェントワークステーションが不要となり、コンタクトセンターのハードウェア要件が削減されます ブラウザベースのエージェントワークステーションにより、エージェントはコンタクトセンターのオフィスに集中する代わりに在宅勤務が可能になります エージェントがコンタクトセンターのオフィスに通勤する必要がなくなり、輸送による炭素排出量が削減されます。 Our World Data によると、自動車やバスを含む道路輸送は、世界の輸送による炭素排出量の 45.1% を占めています 効率的なインフラストラクチャと再生可能エネルギー AWS のインフラストラクチャ規模により、一般的なオンプレミスのデータセンターよりも高いリソース利用率とエネルギー効率が可能になります。最近の報告書「 How moving Onto the AWS Cloud Reduces Carbon Emissions (AWS クラウドへの移行による炭素排出量の削減 ) 」によると、AWS のインフラストラクチャはオンプレミスと比較して最大 4.1 倍効率的であり、AWS 上でワークロードが最適化された場合、関連するカーボンフットプリントを最大 99% 削減できると推定されています。 また AWS は冷却効率を継続的に革新し、時期に応じて異なる冷却技術を使用し、リアルタイムのセンサーデータを活用して変化する気象条件に適応しています。2019 年、Amazon（AWS を含む）は、2030 年までに消費する電力の 100% を再生可能エネルギーで賄うという野心的な目標を設定しました。Amazon は 7 年早く 2023 年にこの目標を達成し、Amazon が消費する電力の 100% を再生可能エネルギー源で賄っています。 よりサステナブルなコンピューティングと AI AWS クラウドへの移行により炭素排出量が削減される という調査結果にあるように、人工知能 (AI) は世界最大の課題に取り組むためのテクノロジーの使用方法を急速に変革しています。AI の利用拡大と同時に、その環境への影響を最小限に抑えることが重要です。AWS が委託し Accenture が実施した調査によると、AI ワークロードのカーボンフットプリントを削減する効果的な方法は、オンプレミスのインフラストラクチャから世界中の AWS データセンターに移行することです。 Amazon Connect は、顧客とのインタラクションのあらゆる段階に AI を組み込んでいます。顧客の声を認識し、顧客が何について電話をしているかを理解し、生身のエージェントの代わりに AI が顧客に対応したり、顧客との会話を分析して顧客の問題を見つけ出し、顧客の感情を認識したりします。Amazon Connect は、リアルタイムの通話分析や通話後のサマリーを行う Contact Lens や、生成 AI エージェントアシストとしての Amazon Q in Connect など、顧客とのインタラクションに生成 AI 機能を組み込んでいます。 これらの複雑な AI、特に生成 AI ワークロードの実行に関して、AWS は幅広いハードウェアの選択肢を提供しています。パフォーマンスとエネルギー消費を最適化するために、 AWS Inferentia2 のような 目的に特化したチップ を開発しました。これは、同等の EC2 インスタンスと比較して最大 50% エネルギー効率が高くなっています。AWS が AI 向けのより効率的なハードウェアへの投資を続けるにつれて、Amazon Connect のお客様は個別の努力を必要とせず、自動的に効率性の向上の恩恵を受けることができます。 クラウドのサステナビリティに関わるベストプラクティス Amazon Connect のクラウドサステナビリティの利点を活用することに加えて、組織は Amazon Connect ベースのコンタクトセンターアーキテクチャを最適化することで、サステナビリティ効果を最大限に享受できます。 AWS Well-Architected Framework の持続可能性の柱は、最適化のための 6 つの重要な領域に焦点を当てています：コンタクトセンターを配置するリージョン、需要に合わせた調整、ソフトウェアとアーキテクチャ、データ、ハードウェアとサービス、開発とデプロイメントプロセスです。これらの重要な領域におけるベストプラクティスに従うことで、コンタクトセンターはリソースの無駄を減らし、利用率を最大化し、運用をサポートするために展開される総コンポーネントを最適化することで、クラウドフットプリントを最小限に抑えるのに役立ちます。 より持続可能な地域に業務を誘導する Amazon Connect の導入において、組織はビジネスの優先事項とサステナビリティの目標の両方に基づいてリージョンを選択すべきです。ビジネスの優先事項、コンプライアンス、レイテンシー、コスト、顧客とエージェントの所在地、サービスの可用性に基づいて、選択可能なリージョンを検討します。 AWS のブログ記事「 How to Select a Region for Your Workload Based on Sustainability Goals (サステナビリティの目標に基づいてワークロードのリージョンを選択する方法) 」では、Amazon Connect で適切な AWS リージョンを選択するためのマーケットを起点に考える方法と場所を起点に考える方法について説明しています。マーケットを起点とする方法では Amazon の再生可能エネルギープロジェクト の近くにあるリージョンを選択できますし、場所を起点とする方法では公表されている 電力消費に対する炭素強度が低い リージョンを選択できます。 ユーザーの行動に合わせた調整 このサステナビリティのベストプラクティスは、実行される活動に使用されるリソースを最適化することに関するものです。使用されるリソースは、ユーザーの需要に応じて規模を調整する必要があります。 Amazon Connect では、ユーザーがコンタクトセンターに電話をかけたり、その他の方法で対話したりすると、需要に基づいてスケールアップ・スケールダウンし、過剰なプロビジョニングを回避します。 さらに、顧客は Amazon Connect で一般的な クラウドコンタクトセンターのアーキテクチャ を最適化して、自社のコンタクトセンターのニーズに合わせることができます。 設計時に、コンタクトセンターソリューションに必要のないサービスを削除することで、実行されるサービスが少なくなり、消費エネルギーが減少します。例えば、ソリューションにテキスト読み上げ機能が不要な場合、Amazon Polly を除外することで、このサービスに関連するエネルギー消費と炭素排出を削減できます。さらに、ソリューションにアウトバウンドキャンペーンが含まれていない場合、設計時に Amazon Pinpoint をアーキテクチャから除外できます。メールが不要な場合は、Amazon Simple Email Service についても同様です。 Amazon Connect 自体においても、 Cases 、 Tasks 、 Contact Lens 、 予測、キャパシティプランニング、スケジューリング などのオプション機能は、顧客のソリューションで必要とされない場合は有効化されません。機能が有効化されていなければ、実行されず、エネルギーを使用せず、炭素排出も発生しません。 Amazon Connect コンタクトセンターアーキテクチャの主要コンポーネントは、サーバーレスコンピューティングサービスである AWS Lambda を使用しています。AWS Lambda 関数はトリガーされた時のみ実行され、アイドル状態のリソースを回避します。上記のアーキテクチャ図のように、このサービスは効率を最適化するイベント駆動型アーキテクチャのために Amazon Kinesis や Amazon Lex などの他のサーバーレステクノロジーを活用しています。 AWS Lambda は、関数に割り当てられたメモリ量に比例して中央処理装置 (CPU) パワー、ネットワーク帯域幅、ディスク入出力を割り当てることでサステナビリティをサポートしています。必要な時のみコードを呼び出し、受信リクエストの割合に応じて自動的にスケールします。これにより、ワークロードの環境への影響を効果的に最適化し、最小限に抑えることができます。 データ Amazon Connect は最近、 ゼロ ETL 分析データレイクの一般提供 を発表しました。 この機能 により、複雑なデータパイプラインの構築と維持が不要になります。分析データレイクでは、レコードが重複排除されるため、保存するデータ量が少なくなり、使用するリソースも少なくて済みます。 AWS は、お客様がデータ管理戦略を最新化できるようにするツールとガイダンスを提供しています。これには、AWS のフルマネージド型のストレージサービスを使用して、アクティブな「ホット」データと非アクティブな「コールド」データセットを分離して保管することが含まれます。さらに、AWS はお客様のデータレプリケーションプロセスを最適化し、レプリケーションのサイズとスループット要件を削減することで、エネルギー消費と炭素排出量の削減を支援します。 従来のコンタクトセンターと Amazon Connect の比較概要 要素 従来のコンタクトセンター Amazon Connect インフラストラクチャ オンプレミスデータセンター、PBX システム AWS クラウドインフラストラクチャ エネルギーの効率性 低い効率性、高い排出量 最大4.1倍の効率性 拡張性 過剰にプロビジョンされうる固定されたインフラストラクチャ 実際の利用に基づいた柔軟なスケーリング 必要なハードウェア 専用のサーバーやワークステーション、電話 ブラウザベース、WebRTC による通話 リモートワークの可能性 限定的 完全にサポート通勤やビルによる排出量の削減 結論 この記事では、最適なサステナビリティの実践方法について議論し、お客様がカーボンフットプリントを削減できる Amazon Connect クラウドベースのコンタクトセンターを構築する方法を示しました。管理されたインフラストラクチャ、最適化されたハードウェア、サーバーレステクノロジー、再生可能エネルギーの組み合わせにより、現在そして将来にわたって、より低いカーボンフットプリントで優れた顧客体験を提供するための、より持続可能な基盤が提供され、結果としてより持続可能な顧客体験につながります。 さあはじめましょう: コンタクトセンターのカーボンフットプリントを評価し、クラウドと Amazon Connect がどのようにそれを削減できるか探りましょう コンタクトセンターを Amazon Connect に移行し、AWS で最適化を行った場合、ワークロードのカーボンフットプリントを最大 99% 削減できる可能性があります Amazon Connect の導入をサステナビリティを考慮して設計しましょう。ワークロードの配置、ユーザー行動との整合性、サーバーレスアーキテクチャ、データと利用率に関するベストプラクティスの推奨事項に従いましょう AWS および Amazon Connect チームと協力 して、組織の環境目標により適合した、より持続可能なコンタクトセンターソリューションの構築方法についてさらに議論しましょう これらのステップに従うことで、コンタクトセンターをよりサステナブルに、エネルギー効率が高く、環境に優しい運用に変革することができます。 Amazon Connect でカスタマーサービス体験を変革する準備はできましたか？ お問い合わせください 筆者について Nada Reinprecht は AWS のシニアソリューションアーキテクトで、業界を超えて革新的な技術ソリューションを作り出し、お客様の複雑なビジネス課題を解決することに情熱を注いでいます。AWS に入社する前は、Accenture や IBM などで働き、オーストラリア、米国、ヨーロッパ、英国のお客様向けにソリューションの設計と提供を行っていました。Nada はブッシュウォーキング、ヨガ、ランニングが大好きです。 Mike Cairns は AWS のシニアソリューションアーキテクトで、多様な業界にわたる複雑なビジネス課題を解決するための革新的なクラウドベースのソリューションの設計と実装の経験があります。彼は AWS サービスに関する深い技術的専門知識を活かし、組織のインフラストラクチャの近代化、運用効率の向上、新しいビジネス機能の開拓を支援しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

皆様、こんにちは。AWS Game Solutions Architect の篠原 聡志です。今回は、アプリストアを介さない独自の課金システムの実装方法について、モバイルゲームを題材に決済サービスの一例として Stripe を活用した実装例をご紹介します。Stripe を活用することで、複雑な決済処理をオフロードし、開発者側の負担を軽減することができます。このブログでは、モバイルゲームという実用的な例を通じて、Stripe を用いたストア外・アプリ外決済の実装方法を詳しくご紹介します。 背景 アプリストアの手数料体系と規制緩和の動きが、アプリ開発者とユーザーに大きな影響を与えています。Apple App Store や Google Play Store では、アプリの売上の 15%～30% がプラットフォーム手数料として徴収されてきましたが、近年 EU や米国を中心に外部決済サービスの利用を認める規制緩和が進んでいます。日本でも 2024年6月に「 スマートフォンにおいて利用される特定ソフトウェアに係る競争の促進に関する法律 」（通称、「スマホソフトウェア競争促進法」）が成立したことがあり、日本でもアプリ外・ストア外課金が広まっていくものと推測されています。この変化により、開発者は収益を増やし、ユーザーはより多様な決済オプションを得られる可能性が出てきました。ストア外・アプリ外課金には、開発者とユーザーの双方にとって重要なメリットとデメリットがあります。 メリット 開発者向け: 手数料の削減：プラットフォームへの 15〜30% の手数料が不要となり、収益性が大幅に向上します 価格設定の自由度：プラットフォームの価格テーブルに縛られず、柔軟な価格設定が可能になります 決済手段の多様化：クレジットカード、銀行振込、コンビニ決済など、これまで課金することができなかったユーザーに対して多様な決済手段を提供できます ユーザー向け: 価格低下：決済手数料が上乗せされない分安価にサービスが利用できます 決済手段の多様化：クレジットカード、銀行振込、コンビニ決済など、多様な決済手段を利用でき、ポイントバックなどの決済手段が提供する恩恵を受けることができます デメリット 開発者向け: 導入の複雑さ：自社で決済システムを構築・運用する必要があり、初期コストと運用コストがかかります セキュリティリスク：決済情報の管理や安全性確保の責任が開発者側に生じます ユーザー離脱のリスク：外部サイトへの遷移が必要なため、ユーザーが離脱する可能性があります ユーザー向け: 利便性の低下：アプリ内でワンタッチで完結していた決済が、外部サイトへの遷移を必要とするため、やや煩雑になります セキュリティへの不安：慣れ親しんだプラットフォームを介さない決済に不安を感じる可能性があります このようなメリットから、日本でもストア外・アプリ外課金を実装するゲームが増えていますが、デメリットにあるように独自環境故の課題についても注意が必要です。続いて、既存のゲームにストア外・アプリ外課金を実装する方法をご紹介します。 Stripe とは Stripe（ストライプ）はオンラインで完結できる決済サービスで、さまざまな業種で利用されています。本ブログで紹介するソリューションは決済サービスとして Stripe を利用することで複雑な決済処理を Stripe 側にオフロードすることでアプリ外決済基盤の構築を容易にしています。 Stripe を利用するメリット Stripe は Amazon EventBridge との連携に対応しており、AWS 上で構築するアプリ外決済基盤に対して決済情報を安全に連携することが可能です。 Stripe 側の設定でイベントの送信先に Amazon EventBridge を選択することができます。 日本国内ではポピュラーなクレジットカード・コンビニ決済・銀行振込などの決済方法が利用可能です。また、海外での決済にも対応しており、その国で多く使われている決済方法を利用できるようにすることでゲームの国際展開をサポートすることが可能です。詳しくは Stripe – 日本での決済:徹底ガイド 及び ビジネスに適した Stripe の決済手段 をご覧ください。決済手数料については Stripe 公式ページ をご覧ください。 実装方法 ストアを通さない課金の実装方法には、主に2種類あります： アプリケーション組み込み型: アプリ内でシームレスにストア外決済を実行 ストアを通じた配信が制限されるため、独自に公式サイトなどからの配信が必要 外部ストアページ連携型: アプリ外部のストアページで有償通貨を購入 既存のゲームワークロードに追加しやすい スマホソフトウェア競争促進法では、他の課金システムを利用することを妨げてはならない旨の記載がある一方、ウェブサイトからアプリを直接ダウンロードできるようにすることまでの義務付けが無いため、本記事では後者の外部ストアページ連携型について詳しく説明します。 モバイルゲームを題材としたストア外・アプリ外課金アーキテクチャ紹介 それでは、ここからはストア外・アプリ外課金の実際の実装のイメージを掴むためにモバイルゲームを題材とした AWS と Stripe を組み合わせるためのアーキテクチャを見ていきましょう。 以下が外部ストアページ連携型の基本的なアーキテクチャです。Amazon DynamoDB を一時的な課金情報のストアとして利用し、Amazon DynamoDB Streams による AWS Lambda の実行でゲーム内に課金情報を反映します。ゲーム内有償通貨付与の際は Amazon DynamoDB の付与済フラグを確認することでべき等性を担保しています。 基本的なアーキテクチャは以下の通りです： ユーザーがスマートフォンでストアページにログインします。 ログインにはゲーム内ユーザーIDを用います。 Stripe を通じて商品を購入します。 購入の際に Idempotent requests (べき等なリクエスト) を利用することで商品の重複購入を防ぐことができます。詳しくは API リクエストのベストプラクティス を御覧ください。 Stripe からの決済成功イベント( checkout.session.completed )が Amazon EventBridge に通知されます。 Amazon EventBridge のフィルタで checkout.session.completed が検知され、 AWS Lambda が実行されます。 下記は AWS Lambda を呼ぶ際の Event の一部です。 { "oblect":{ "client_reference_id": "123456789", # ユーザー ID "created": 1732268759, "customer_details": { "email": "hogehoge@fugagufa.hoge", "name": "SATOSHI SHINOHARA", }, "metadata": { "item_id": "1111", # ユーザーが購入したアイテムの ID }, "payment_intent": "pi_XXXXXXXXXXXXXXXXXXXXXX", "status": "complete", } } Amazon EventBridge は AWS Lambda 関数を呼び出し、決済成功のレコードを Amazon DynamoDB に一時保存します。 Amazon DynamoDB のテーブルは後述のゲームへの有償通貨付与方法にてご紹介します。 Amazon DynamoDB にデータが書き込まれると、Amazon DynamoDB Streams がトリガーされます。 Amazon DynamoDB Streams によって起動された AWS Lambda 関数が、課金情報を確認し、ゲームへの付与フラグがないことを確認します。 AWS Lambda 関数は対象のユーザー ID に対してゲーム内の状態を管理する Amazon Aurora の UserDB に対してゲーム内有償通貨を付与します。 同様に AWS Lambda 関数から課金履歴を管理する課金 DB と課金情報を永続管理する Amazon S3 に課金ログを保存します。 本アーキテクチャは一般的なゲームアーキテクチャと連携できるように汎用的な構成をしております。有償通貨を付与し課金 DB や課金ログに書き込みを行う AWS Lambda をカスタマイズすることで、Apple App Store や Google Play Store のフォーマットと合わせることができ、既存の課金 DB や課金ログとの結合が容易です。一方、ゲーム内の状態を管理するの UserDB は払い戻しの観点から Apple App Store と Google Play Store で購入した有償通貨を別々に保存するのと同様にストア外課金用のカラム追加が必要な点には注意してください。 ゲームへの有償通貨付与方法 ゲームへの付与方法は、既存のゲーム処理に合わせて選択することをおすすめします： Amazon DynamoDB Streams 方式 ゲームクライアントが API を実行する度にゲーム内有償通貨を取得する場合に適しています。この方式はリアルタイムでの通貨付与が可能ですが、ゲームクライアントとサーバー間でのデータ整合性に注意が必要です。 購入情報が Amazon DynamoDB に書き込まれると、Amazon DynamoDB Streams がトリガーされます。 トリガーされた AWS Lambda 関数が実行されます。 購入情報からゲーム内への付与状態を確認します。 ゲームのユーザー DB に有償通貨を付与します。 Amazon DynamoDB に付与済フラグを設定します。 Amazon DynamoDB のテーブルは下記となります。 user_id: PK。ゲーム内のユーザーを識別する ID stripe_pi: SK。決済を識別する Stripe の Payment Intents item_id: 購入したアイテムの ID name: 決済時に入力された氏名 email: 決済時に入力されたメールアドレス created_datetime: Stripe 側で記録された決済時間 distributed_datetime: ゲーム内にアイテムが付与された時間＋一定期間。TTL が設定されており一定期間経過したレコードは削除される。付与済フラグとしても利用する distributed_datetime に Time to Live(TTL) を設定することで、付与が完了したレコードを一定期間保持の後に削除し、Amazon DynamoDB のコストを削減しています。 ゲームサーバ駆動型 ゲームログイン時や特定のイベント（例: ゲーム内ストアページへの遷移）のみ有償通貨を取得する場合に適しています。この方式は特定のタイミングで複数の課金情報をまとめて処理できるためシステム負荷を軽減しやすく、ゲームクライアントとサーバー間でのデータ整合性を保ちやすいという利点があります。 ユーザーがゲームへのログインやゲーム内ストアページへの遷移を行います。 ゲームサーバが Amazon DynamoDB にゲーム内未反映の課金情報があるかを確認します。 未反映の課金情報がある場合、ゲームサーバがユーザー DB に有償通貨を付与します。 Amazon DynamoDB に付与済フラグを設定します。 Amazon DynamoDB のテーブルは Amazon DynamoDB Streams 方式と同様です。 まとめ Stripe を活用したストア外・アプリ外決済の実装により、アプリデベロッパーは収益を増やし、ユーザーには多様な決済オプションを提供することができます。ただし、実装には慎重な設計と、既存のゲームシステムとの整合性を考慮する必要があります。 本記事が、皆様のアプリ開発の一助となれば幸いです。 著者 篠原 聡志 ゲーム企業を経て AWS に入社。主にゲーム業界のお客様を担当しています。好きな AWS サービスは Amazon Bedrock、Amazon S3 です。趣味はリズムゲームと VR ゲームです。

2024 年 11 月 22 日より、クロスゾーン負荷分散を有効にした Application Load Balancer (ALB) の Amazon Application Recovery Controller (ARC) ゾーンシフト サポートを発表しました。これは、 以前に発表された クロスゾーン負荷分散を使用する Network Load Balancer (NLB) のサポートを補完するものです。ゾーンシフトは、クロスゾーン負荷分散が設定されているかどうかに関係なく、NLB と ALB の両方で使用できるようになりました。また、 Amazon EC2 Auto Scaling グループ (ASG) や Amazon Elastic Kubernetes Service (EKS) などの他のリソースでもゾーンシフトを使用できます。ブログ記事 「単一の アベイラビリティゾーンでのアプリケーション障害からの迅速な復旧」 では、ゾーンシフトの仕組みと、クロスゾーン負荷分散が無効になっている場合の関連するベストプラクティスの概要が説明されています。この記事では、クロスゾーン負荷分散を有効にした状態でゾーンシフトを使用する場合の運用上のベストプラクティスを紹介します。 概要 ALB または NLB のゾーンシフトの使用を開始するには、ロードバランサーの zonal_shift.config.enabled 属性を true に設定する必要があります。クロスゾーン負荷分散を使用する NLB では、target_health_state.unhealthy.connection_termination.enabled が false に設定されていることも確認する必要があります。この機能を有効にすると、1 つのアベイラビリティーゾーン (AZ) で障害が発生していることが判明したときに、ゾーンシフトを開始して影響を軽減できます。 ゾーンシフトは、クロスゾーン負荷分散が有効になっている場合、2 つのアクションを実行します。はじめに、指定された AZ のロードバランサーノードの IP アドレスが DNS から削除されるので、新しいクエリがそのエンドポイントで解決されなくなります。これにより、今後クライアントリクエストがそのノードに送信されなくなります。次に、他の AZ のロードバランサーノードに、障害のある AZ のターゲットにリクエストをルーティングしないように指示します。図 1 に示すように、ゾーンシフト中も残りの AZ ではクロスゾーン負荷分散が引き続き使用されます。 図 1 – AZ 1 でゾーンシフトが有効なクロスゾーン負荷分散を使用する Application Load Balancer AZ 障害が発生している間は、ロードバランサーの背後にある ASG のゾーンシフトを実行することもできます。ゾーンシフト中に 異常のあるインスタンスを置き換える ように ASG を設定した場合、障害のある AZ ではインスタンスが終了し、他の AZ では新しいインスタンスが起動されることがあります。また、EC2 Auto Scaling がゾーンシフト中にアプリケーションをスケールアウトし、影響を受けていない AZ で新しいインスタンスを起動する可能性もあります。これにより、AZ 間でキャパシティのバランスが崩れる可能性があります。 AZ 障害が復旧したと判断したら、シフトをキャンセルして AZ へのトラフィックをリバランスすることができます。クロスゾーン負荷分散は、ロードバランサーのゾーンシフトを終了するとターゲットごとに受信されるトラフィックの全体的な割合が減少するため、キャパシティが不均衡になった場合にリバランスをより安全に行うのに役立ちます。これは、図 2 に示すように、ロードバランサーがターゲットグループの各ターゲットにトラフィックを均等に分散するためです。 図 2 – クロスゾーン負荷分散が有効化された Application Load Balancer これとは対照的に、クロスゾーン負荷分散を無効した状態では、トラフィックが各 AZ に均等に分散されます。その後、ロードバランサーはそのゾーン内の利用可能なターゲットにリクエストを分散します。AZ 間のキャパシティの不均衡により、ロードバランサーのゾーンシフトを終了した後に、特定のインスタンスが他のインスタンスよりも多くの負荷を受ける可能性があります。これにより、過負荷が発生し、アプリケーションに影響が及ぶ可能性があります。たとえば、図 3 は AZ 2 のインスタンスが AZ 1 と AZ 3 のターゲットの約 2 倍のトラフィックを受信している様子を示しています。この構成では、target_group_health.dns_failover.minimum_healthy_targets.count を使用して、十分な数の正常なホストが利用できるようになるまで AZ がトラフィックを受け入れないようにすることが重要です。 図 3 – クロスゾーン負荷分散が無効化された Application Load Balancer クロスゾーン負荷分散は、ALBではデフォルトで有効であり、NLBでもオプションで有効にできます。これにより、ALB ターゲットグループの構成を大幅に変更しなくても、ゾーンシフトを活用できます。ALB の ゾーンオートシフト をデフォルト設定でオプトインすることもできます。AWS は、お客様に影響を与える可能性のある AZ 障害が社内のテレメトリで示されたときに、オートシフトを開始します。ゾーンオートシフトは、 加重ランダム ルーティングアルゴリズムと組み合わせて使用できます。これにより、イベント発生時の復旧時間を最小限に抑えることができ、ゾーンシフトの活用に必要な追加のオブザーバビリティが軽減されます。 単一 AZ の影響に対応するには、ゾーンオートシフトと自動ターゲットウェイト (ATW) の異常緩和が推奨されますが、これらのツールでは特定のインフラストラクチャにおけるグレー障害やシングル AZ アプリケーションの障害を検出できない場合があります。たとえば、ある特定の AZ にデプロイされたバグを含むアプリケーションデプロイや、少数のインスタンスに影響する少量のパケットロスによってアプリケーションエラーが発生し始めた場合などです。このような状況を検出するには、追加のオブザーバビリティを開発する必要があるかもしれません。次のセクションでは、クロスゾーン負荷分散を有効にして 単一AZ の障害を検出する方法を調べます。 クロスゾーン負荷分散を有効にしたゾーンシフトの AZ オブザーバビリティ リクエスト数、障害率、AZ ごとのレイテンシーなどのメトリクスを監視することは、AZ で障害が発生している可能性があるタイミングを判断するための前提条件であり、潜在的な影響を安全に軽減することができます。次の 3 つのシグナルは、ゾーンシフトをいつ使用するかを判断するのに役立ちます。 可用性またはレイテンシーへの影響を示す AZ ヘルスメトリクス あるAZ が、他の AZ と比較して、障害率またはレイテンシの点で外れ値である 障害率または高レイテンシーが、複数のインスタンスで発生している それでは、各 AZ におけるアプリケーションの状態に関するメトリクスの収集を開始する方法を見てみましょう。 AZ ヘルスメトリクスの作成 レジリエンスのためのオブザーバビリティのベストプラクティス の1つは、合成カナリアを使って顧客体験をモニタリングすることです。これらは早期警告の指標として機能するので、顧客に気づかれる前に問題を自分自身に知らせることができます。 「単一アベイラビリティーゾーンでのアプリケーション障害からの迅速な復旧」 の投稿では、図 4 に示すように、Amazon CloudWatch Synthetics を使用して ALB と NLB の ゾーンエンドポイント をモニタリングし、AZ ごとのメトリクスを生成しました。 図4 – 各 AZ の Application Load Balancer エンドポイントに対して実行される合成カナリア クロスゾーン負荷分散を有効にした場合でも、シンセティックは引き続きベストプラクティスです。ただし、ALB や NLB について各ゾーンのエンドポイントをテストしても、どの AZ のターゲットからも応答が得られる可能性があるため、それほど有用ではありません。代わりに ALB の場合は、 ALB ロードバランサーの Amazon CloudWatch メトリクス を使用して、特定の AZ のターゲットで障害率やレイテンシーが上昇しているタイミングを特定できます。 ALB ターゲットメトリクス には、2XX、3XX、4XX、5XX のカウントと TargetResponseTime のメトリクスがあります。これらのメトリクスはすべて、レスポンスを生成したターゲットの AZ を表す メトリクスディメンション として AvailabilityZone を備えています。 NLBの場合、 ターゲットメトリクス はほとんどがレイヤー4の情報であるため、アプリケーションの状態の変化を判断するのがより難しい場合があります。TCP_Target_Reset_count メトリクスをアプリケーションの正常性の代用として監視することもできますが、それでもまだ不十分な場合があります。NLB またはそのターゲットグループでクロスゾーン負荷分散が有効になっている場合は、ターゲットの AZ をメトリクスディメンションとして提供するカスタムサーバーサイドメトリクスを利用する必要があります。これを実現する方法の詳細については、 「カスタムメトリクスの公開」 と 「CloudWatch 埋め込みメトリクス」 を参照してください。 ロードバランサーの UnhealthyHostCount ターゲットメトリクスをモニタリングすることもできます。AZ 障害が原因でターゲットのヘルスチェックが不合格になった場合、これはその影響を直接示しています。このメトリクスに自動的に対応するには、NLB または ALB ターゲットグループの target_group_health.dns_failover.minimum_healthy_targets.count 属性を使用できます。これにより、正常なホストが少なすぎる場合に、ロードバランサーが AZ から自動的に移動するようになります。 ALB メトリクスまたはカスタムサーバーサイドメトリクスのいずれかを使用して、各 AZ の影響を警告する CloudWatch アラームを作成できます。この例では、クロスゾーン負荷分散を有効にした ALB メトリクスを使用しています。ターゲットからのレイテンシーが特定のしきい値を超えたとき、またはアベイラビリティが指定された値を下回ったときにアラームがトリガーされるように設定しています。 レイテンシーアラームは以下のメトリクスを利用します（図5）： 図5 – 目標応答時間メトリクスを使用して AZ ごとにレイテンシーアラームを定義する また、可用性アラームはメトリクス計算を使用して AZ の障害率を決定します （図6）： 図6 – AZ ごとの可用性アラームを定義するためのロードバランサー障害率の決定 最後に、図 7 に示すように、単一の AZ における可用性またはレイテンシーの影響を特定するように CloudWatch 複合アラームを設定します。 図7 – 障害率またはレイテンシーへの影響に関する CloudWatch 複合アラーム定義 次に、同じ ALB メトリクスを使用して各 AZ 間の障害率とレイテンシーを比較し、1 つの AZ がいつ外れ値になるかを調べます。 外れ値検出の実行 あるAZ がヘルスメトリクスの外れ値である場合は、その 障害分離境界 に問題があることを示す良い指標になります。 カイ二乗検定 や、 標準得点 、 四分位範囲 (IQR) 、 中央絶対偏差 (MAD) など、さまざまな外れ値検出アルゴリズムを使用してヘルスメトリクスを比較できます。もっと簡単に始めるには、66% のような静的な値を使用する方法があります。つまり、ある AZ が全故障の 66% を占めていれば、それは外れ値とみなされます。 図 8 は、メトリクス計算を使用して計算された CloudWatch メトリクス e1 を示しています。これにより、単一の AZ (この場合は us-east-1b) 全体の障害の割合が決定されます。このメトリクス値が 0.66 より大きい場合にアラームを設定できます。 図8 – ある AZ に属する障害の割合を決定する外れ値検出用メトリクスの作成 レイテンシーについては、データポイントにおける標準偏差を決定するために標準得点を使用します。正規分布データの 99.7% は標準偏差が3以内であるため、値が3を超えると値が外れ値であることを示します。この計算では p99 のレイテンシーを調べ、この AZ と比較している他の 2 つの AZ の平均値を使用して ( Metrics () 関数を使用 )、外れ値のレイテンシーが標準偏差を歪めないようにしています。図 9 は CloudWatch メトリクスの計算を使用した計算を示しています。このメトリクスが 3 を超えた場合のアラームを設定できます。 図9 – あるAZ におけるレイテンシーの標準得点を用いた外れ値検出 複数インスタンスによる影響の特定 ターゲットがヘルスチェックに失敗した場合、UnhealthyHostCount ターゲットメトリクスは、影響が複数のインスタンスによって引き起こされているかどうかを確認するのに役立ちます。構造化された CloudWatch ログを作成している場合は、 CloudWatch Contributor Insights を使用することもできます。このサービスは、インサイトルールの UniqueContributors メトリクスを使って、アプリケーションの障害やレイテンシーの原因となった要因を特定するのに役立ちます。図 10 は、Contributor Insights メトリクスの計算を使用した CloudWatch メトリクスの例を示しています。 図10 – あるAZ における障害の要因の数を算出するためのContributor Insights を使用した CloudWatch メトリクス このメトリクスに値が 1 を超えた場合のアラームを設定して（フリートのサイズによってはもっと大きい数値を使用することもできます）、複数のインスタンスでエラーが発生していることを示すアラームを設定できます。 すべてをまとめる これで、単一 AZ の影響の特定に役立つ 3 つの条件のアラームが表示されるようになりました。 特定の AZ における可用性またはレイテンシーの影響 特定の AZ が障害やレイテンシーにおいて外れ値となっている 複数のインスタンスで問題が発生している 最後の CloudWatch 複合アラーム ( 図 11 参照 ) では、これらの各アラームからの信号を組み合わせて、ゾーンシフトを使用して対応できる単一AZ の影響が発生したことを通知します。 図11 – 単一 AZ の影響を決定するための CloudWatch 複合アラームの定義 これらのAZごとのアラームをダッシュボードに追加して、運用担当者が単一 AZ の障害をすばやく特定できるようにすることもできます（図12）。 図12 – あるAZ で問題が検知されたことを示す CloudWatch ダッシュボード 結論 この投稿では、クロスゾーン負荷分散を有効にした状態でゾーンシフトがどのように機能するかを確認しました。また、単一の AZ でアプリケーションの状態への影響を監視するための運用上のベストプラクティスについても紹介しました。ゾーンシフトまたはゾーンオートシフトを開始するには、Amazon Application Recovery Controller の ドキュメント をご覧ください。 著者について Michael Haken Michael は AWS Strategic Accounts チームのシニアプリンシパルソリューションアーキテクトであり、お客様のイノベーション、ビジネスの差別化、カスタマーエクスペリエンスの変革を支援しています。15 年以上にわたり、金融サービス、公共部門、デジタルネイティブの顧客をサポートしてきました。Michael はバージニア大学 (UVA) で学士号を、ジョンズ・ホプキンス大学でコンピューターサイエンスの修士号を取得しています。仕事以外では、彼は農場で家族や犬と遊んでいます。 翻訳はソリューションアーキテクトの松本が担当しました。原文は こちら です。

航空業界において効率的な手荷物追跡システムは不可欠であり、乗客の所持品を適時かつ完全な状態で配送するのに役立ちます。手荷物の取り扱いと追跡の誤りは、フライトの遅延や乗り継ぎの欠航から、荷物の紛失や顧客の不満まで、一連の複雑な問題を引き起こす可能性があります。このような混乱は航空会社の評判を損ない、重大な財務的損失をもたらす可能性があります。 そのため、航空会社は正確で効率的、かつ信頼性の高い手荷物追跡システムの開発と導入に多大なリソースを投じています。これらのシステムは、ほぼリアルタイムでの手荷物位置情報の更新を通じて顧客満足度を向上させ、定時出発をサポートするために運用ワークフローを最適化するのに役立ちます。 手荷物追跡システムの重要な役割は、パッケージを効果的に追跡し、業務をデジタル化し、再ルーティングが発生したとしても是正措置を効率化する能力にあります。このシステムは、フライトの円滑な運用、乗客の満足度、および荷物の配布のタイムリーな管理を維持するための鍵となっています。 従来の手荷物追跡プロセス 手荷物追跡システムは、チェックインされた手荷物が航空会社と空港のインフラ内をどのように移動するかを監視するため、手動および自動のバーコードスキャンを使用します。手荷物追跡システムは、航空会社が提供する製品やサービスをサポートするため、図1に示されているように、複数の機能に細分化することができます。 図1手荷物追跡システムに求められる要件(ハイレベル） 手荷物の追跡は、顧客のチェックインから始まり、いくつかの段階を経て進行します。チェックインでは、バーコードまたは無線自動識別（RFID）技術を使用して、手荷物にタグが付けられ、乗客と関連付けられます。その後、手荷物は適切なピアまたはバッグステーションに仕分けられ、搬送されます。 仕分けゲートウェイは、TCP/IP、HTTP、または独自のメッセージングプロトコルを使用してバックエンドシステムと通信します。手荷物はまず保管場所である「バッグルーム」に運ばれ、その後空港スタッフによって航空機に積み込まれる「ピアエリア」に移動します。場合によっては、手荷物は航空機内のコンテナに仕分けられます。 航空機が目的地に到着すると、手荷物は機内から下され、手荷物受取所または次のフライトへと搬送されます。受け取られなかった手荷物は、必要に応じて手荷物サービスオフィスエリアへと移動されます。 このプロセス全体を通じて、正確でほぼリアルタイムの追跡を実現するため、各段階で手荷物のスキャンが行われます。手荷物の取り扱いを誤ったり、紛失したりした場合、この追跡情報が手荷物の回収に不可欠となります。 図2 従来の手荷物追跡システムアーキテクチャ 図2に示されているように、従来の手荷物追跡アーキテクチャは、RESTフレームワークまたはSOAPプロトコルのいずれかで実装される、アプリケーションプログラミングインターフェース（API）を広範に活用しています。ほとんどの航空会社がバックエンドとしてメインフレームを利用しているため、APIの使用には2つの主要な経路があります：メインフレームへの直接的なデータ送信、またはリレーショナルデータベースの更新です。 別個のオフラインプロセスがデータを取得して処理し、その後、他のAPIやメッセージキュー(MQ)を通じてメインフレームに送信します。デバイス情報を受信した場合、通常その情報は限定的であり、その情報をメインフレームに送信するために追加の呼び出しを調整する別のバックグラウンドプロセスが必要となる場合があります。 このような動きにともないフェイルオーバが発生した場合には人が介入する余地があり、サービス中断が発生する可能性があります。 モダナイズの必要性 従来の手荷物追跡システムは、以下の重要なビジネス上および技術上の課題により、大きく妨げられています： オンサイトおよびオンプレミスのインフラストラクチャにおける、大量の手荷物追跡データとテレメトリに対するスケーラビリティの欠如。 不規則な運航（IROPS）時におけるデータ量の急増への対応の課題。 バッグルーム、受取所エリア、ピアエリア、出発スキャンなど、空港内のネットワークの接続性に関する懸念。 ミッションクリティカルなシステムの継続性に影響を与える必要なレジリエンスの欠如。 モビリティデバイスに関連する手荷物追跡の規制要件の変更に迅速に適応できない。 キオスク、仕分けゲートウェイ、セルフサービス手荷物預け入れ、ベルトローダー、固定リーダー、アレイデバイス、IoTデバイスなどのシステムとの統合による包括的な追跡とデータ収集。 グローバルオペレーターの運用効率を阻害し乗客体験に影響を与えるレイテンシーの問題。 追跡デバイスの監視と保守の不足により、運用の中断とダウンタイムが発生する可能性。 サイバーセキュリティの脅威とデータプライバシーに関する懸念。 手荷物追跡データのほぼリアルタイムインサイトの欠如。これにより、情報に基づく意思決定と運用の最適化が妨げられる。 手荷物追跡システムのモダナイズは、航空会社にとって、これらの課題に対処するために極めて重要です。スケーラビリティ、信頼性、セキュリティを維持しながら、運用効率と乗客満足度を向上させることができます。先進的な技術を取り入れることで、航空会社は急速に進化する業界において競争力を維持し、成長をサポートする態勢を整えることができます。 ソリューション 図3は、従来の手荷物追跡プロセスにおける課題に対する解決策を示しています。 スキャナー、ベルトローダー、センサーなどのデバイスは、それぞれのデバイスゲートウェイと通信を行います。これらのゲートウェイは、効率的な通信とテレメトリのために、AWS IoT CoreとMQTTプロトコルを介してAWSクラウドに接続し、通信を行います。このデザインでは、特にネットワークの帯域幅と接続性が制限された環境において最適なパフォーマンスを提供できるため、MQTTを使用しています。 AWS IoT Greengrass エッジゲートウェイは、デバイス間およびシステム間通信のためのオンサイトメッセージング、ローカルデータ処理、エッジでのデータキャッシングをサポートしています。このアプローチにより、レジリエンス、ネットワークレイテンシー、ネットワーク接続性が向上します。これらのゲートウェイは、ローカル通信用のMQTTブローカーを提供し、必要なデータとテレメトリをクラウドに送信します。 AWS IoT Coreは、バックエンドシステムへのタイムセンシティブな配信よりも、信頼性の高いデータ配信が重要なシナリオで特に有用です。さらに、デバイスシャドウのような機能を提供しており、これによってダウンストリームシステムは、デバイスが切断されている場合でも、デバイスの仮想表現と対話することができます。デバイスが接続を回復すると、デバイスシャドウは保留中の更新を同期します。このプロセスにより、接続が不安定な場合の動作が解決されます。 AWS IoTルールエンジンは、AWS Lambda、Amazon Simple Storage Service（Amazon S3）、Amazon Kinesis、Amazon MSKなどの必要な送信先にデータを送信することができ、必要なデバイスのテレメトリデータと手荷物追跡イベントは、ほぼリアルタイムでのデータのストリーミングと一時的な保存のためにAmazon MSKへ、テレメトリデータの長期保存のためにAmazon S3へ、そして低レイテンシーイベントへの対応のためにLambdaへと送信されます。 このイベント駆動型アーキテクチャは、信頼性が高く、レジリエンシーがあり、柔軟で、ニアリアルタイムのデータ処理を提供します。必要な回復力を提供するために、AWS IoT CoreとAmazon MSKは複数のリージョンにわたって展開されています。また、Amazon MSKは Kafka MirrorMaker2 を使用して、リージョンのフェイルオーバー時の信頼性を向上させ、ダウンストリームのコンシューマーのオフセットを同期します。 手荷物追跡データは、中央の手荷物取扱いデータストアに保存される必要があります。これにより、ダウンストリームアプリケーション、レポーティング、高度な分析機能をサポートします。必要なテレメトリデータを取り込むために、このソリューションではLambdaを使用して、それぞれのMSKトピックをサブスクライブし、スキャンを処理してからAmazon DynamoDBにデータを取り込みます。DynamoDBは、ほぼゼロのRPO（目標復旧時点）とRTO（目標復旧時間）を必要とするマルチリージョンのミッションクリティカルなアーキテクチャに理想的です。 手荷物の積み込み時、ベルトローダーやハンドヘルドスキャナーなどのデバイスは、最小限のレイテンシーで双方向通信を必要とすることが多くあります。同様のIoTデバイスにデータを配信する必要がある場合、Lambdaは直接AWS IoT Coreにメッセージを配信することができます。 大量のデバイステレメトリと手荷物追跡データを収集するにあたり、このソリューションではAmazon S3Intelligent-Tieringを使用して、安全かつコスト効率よくこのデータを保存します。また、固定リーダー、ベルトローダー、ハンドヘルドスキャナーのほぼリアルタイムのデバイス分析を生成するために、AWS IoT AnalyticsとAmazon QuickSightを使用します。 図3に示されているように、このソリューションはAWS IoT Coreからの受信MQTTデータストリームを収集、処理、分析し、目的に特化したタイムストリームデータストアに保存するサービスも使用します。Amazon AthenaとAmazon SageMakerは、さらなるデータ分析と機械学習（ML）処理に使用されます。Amazon Athenaは、複雑なデータインフラストラクチャや管理を必要とせずに、標準SQLを通じて大規模なデータセットのアドホック分析とクエリに使用されます。Amazon SageMakerとの統合により、手荷物追跡のためのMLモデルを便利に開発することができます。 おわりに 本記事では、AWS IoT、Amazon MSK、AWS Lambda、Amazon S3、Amazon DynamoDB、およびAmazon QuickSightを使用することで、航空会社は従来のシステムの制限に対処する、スケーラブルで回復力があり、安全な手荷物追跡ソリューションを実装できることについて説明しました。AWSサービスを活用した近代化されたソリューションは、ほぼリアルタイムの追跡を確保し、正確な追跡、取り扱いミスの削減、紛失手荷物の効率的な回収を通じて、運用効率と乗客体験を向上させます。さらに、サイバーセキュリティの脅威、データプライバシーの懸念、規制コンプライアンスに対処しながら、情報に基づく意思決定と運用の最適化のためのデータ分析とレポートを可能にします。 このソリューションのコンポーネントについてさらに詳しく知るには、参考文献のセクションをご覧ください。また、お客様のビジネスの加速化についてご相談させていただくには、 AWS トラベル＆ホスピタリティコンピテンシーパートナー をご覧いただくか、AWSの担当者までお問い合わせください。 さらに詳しく知るには？ AWS for Travel and Hospitality IBM Travel and Transportation IBM Consulting on AWS Modernize Baggage Acceptance Messaging with Enhanced Efficiency and Security Use MSK Connect for managed MirrorMaker 2 deployment with IAM authentication Amazon Managed Streaming for Apache Kafka Best Practices Deploy a predictive maintenance solution for airport baggage handling systems with Amazon Lookout for equipment How to implement a disaster recovery solution for IoT platforms on AWS How to Eliminate the Need for Hardcoded AWS Credentials in Devices by Using the AWS IoT Credentials Provider How to Use Your Own Identity and Access Management Systems to Control Access to AWS IoT Resources IBM Consulting は、AWSプレミアティアサービスパートナーとして、お客様がAWSを活用してイノベーションの力を引き出し、ビジネス変革を推進することを支援しています。彼らは、トラベル＆ホスピタリティコンサルティングを含む17以上のコンピテンシーにおいて、グローバルシステムインテグレーター（GSI）として認められています。詳細については、IBMの担当者まで お問い合わせください 。 翻訳はソリューションアーキテクトの矢形が担当しました。原文は こちら です。 著者一覧 Neeraj Kaushikは、IBMのオープングループ認定ディスティングイッシュアーキテクトで、クライアント対応の職務において20年の経験を持っています。彼の経験は、旅行・運輸、銀行、小売、教育、医療、人身売買防止など、複数の業界にわたります。信頼されるアドバイザーとして、クライアントの経営陣やアーキテクトと直接協力し、技術ロードマップを定義するためのビジネス戦略に取り組んでいます。実践的なチーフアーキテクトとしてAWSプロフェッショナル認定ソリューションアーキテクトおよび自然言語処理の専門家として、複数の複雑なクラウド近代化プログラムとAIイニシアチブを主導してきました。 Venkat Gomathamは、AWSのシニアパートナーソリューションアーキテクトとして、AWSシステムインテグレーター（SI）パートナーの卓越を支援しています。彼は20年以上にわたりITアーキテクトおよび技術者として働き、イノベーションと変革をリードしてきました。AWSではモノのインターネット（AWS IoT）分野の主題専門家（SME）および技術フィールドコミュニティ（TFC）メンバーとして、自動車およびAI/MLの専門性を持って活動しています。 Subhash Sharmaは、AWSのシニアパートナーソリューションアーキテクトです。彼は、マイクロサービス、AI/ML、モノのインターネット（IoT）、およびブロックチェーンをDevSecOpsアプローチで活用し、分散型で、スケーラブルで、高可用性があり、セキュアなソフトウェア製品の提供において25年以上の経験を持っています。余暇には、家族や友人と過ごしたり、ハイキングをしたり、ビーチを散歩したり、テレビを見たりすることを楽しんでいます。 Vaibhav Ghadageは、IBMのAWS ITスペシャリストで、現在IBM Consultingで働いています。彼はAWSプロフェッショナル認定ソリューションアーキテクトであり、主にクラウドに焦点を当てて活動しています。

航空会社の予約、フライト追跡、リワードプログラム、手荷物追跡、機内エンターテインメントなどの重要な機能を扱うアプリケーションは、乗客の航空旅行体験を変革しています。これらのアプリケーションに障害が発生すると、乗客に不便をもたらすだけでなく、最悪の場合、収益と乗客の信頼を失うことにもなりかねません。大幅な遅延につながる障害が発生した場合、航空会社に対してペナルティが科される可能性もあります。 航空会社のアプリケーションをクラウドに移行することで、スケーラビリティの向上と災害復旧能力の強化により、システム障害を軽減することができますが、クラウド運用の管理には課題が伴う場合があります。これらの課題には、クラウドコンピューティングスキルの不足、レガシーシステムとの統合、旧式のインシデント管理プロトコル、オンプレミスインフラへの依存、そして旧式の監視ソリューションの使用といった要因が含まれます。 このブログでは、ある大手航空会社がクラウド運用を改善するために、ミッションクリティカルなアプリケーションを AWS Incident Detection and Response (IDR) に移行した方法について説明します。 AWS incident Detection and Responseとは？ AWS Incident Detection and Responseは、重要なワークロードに対してプロアクティブな対応とインシデント管理を提供します。AWS Incident Detection and Responseでは、AWSインシデント管理エンジニア（IME）が24時間365日体制でワークロードを監視し、インシデントを検知し、AWSサポートの専門家と連携して、問題の緩和と復旧に向けたガイダンスを提供します。 Observabilityの向上 ：アプリケーション層とインフラストラクチャ層の間で適切な可観測性を確保し、ワークロードの障害を検知できるようにします。 より迅速な解決 ：アラーム発生から5分以内にAWSインシデントマネージャーと連携し、事前に定義された対応計画に基づいてインシデントを管理することで、復旧を加速します。 AWSで発生するイベントのインシデント管理 ：AWSサービスイベントに関する最新情報、影響の見通し、および軽減計画の実装に関するガイダンスを提供します。 要害発生頻度の低減 ：復旧を加速するだけでなく、過去のインシデントから得られた教訓をランブック、可観測性、対応計画の改善に活かすことで、継続的な改善のメカニズムを提供し、障害の可能性を低減します。 どのようにIDRはアプリケーションのレジリエンスを向上するか？ インフラストラクチャの近代化イニシアチブの一環として、この航空会社は複数年にわたるクラウド移行の取り組みを開始しました。このイニシアチブの一環としてクラウドに移行されたアプリケーションの1つが、滑走路状態報告（FICON）アプリケーションでした。FICONは、パイロットと運航計画担当者に滑走路の状態に関する情報を提供します。このアプリケーションの可用性への影響や復旧の遅延は、フライトの遅延を引き起こし、航空会社の運航と乗客に直接的な影響を及ぼします。 FICONは、ほぼゼロの目標復旧時間（RTO）を持つグランドストップアプリケーションです。移行の一環として、この航空会社は、クラウド環境でのアプリケーションの可観測性の設定、重大なインシデントへの迅速な対応、そしてチームの復旧をガイドするためにアプリケーションのコンテキストを理解している専門家へのアクセスが必要でした。 これらのニーズに対応するため、お客様はアプリケーションをAWS Incident Detection and Responseに移行することを決定しました。移行プロセスは、信頼性と運用の優位性についてアプリケーションを評価することから始まりました。AWSの専門家は航空会社のアプリケーションチームと協力して、システムのアプリケーション層とインフラストラクチャ層全体の可観測性を向上させるための主要な性能指標を特定し、インシデント発生時に警告するためのAmazon CloudWatchアラームを作成しました。また、重大なインシデント発生時のエスカレーション用にアプリケーション担当者のリストを含むランブックも作成されました。 AWS Incident Detection and Responseは、可観測性の向上と早期インシデント検知を通じて、FICONアプリケーションの運用効率を向上させました。5分以内の応答時間は、厳格な目標復旧時間（RTO）とデータ復旧時点の目標（RPO）を考慮した航空会社のグランドストップアプリケーションにとって重要でした。AWS Incident Detection and Responseは、重大なインシデントに対する平均対応時間（MTTE）と平均復旧時間（MTTR）を改善しました。 運用の優位性における改善を示す事例として、FICONアプリケーションのAmazon CloudWatchアラームが作動しました。このアラームは、API Gatewayがリクエストを中継してからバックエンドからレスポンスを受信するまでの時間である、Amazon API Gateway統合レイテンシーを監視していました。アラームに応答して自動的にサポートケースが作成され、アラーム作動から2分以内にインシデントマネージャーが対応を開始しました。 インシデントマネージャーは会議ブリッジを開始し、航空会社とAWSチームとの共同トリアージとインシデント解決を促進しました。AWS Lambdaサポートチームが会議セッションに参加し、ログを確認した結果、AWS Lambdaが同時実行制限に達していたことを特定しました。エンジニアは迅速にLambdaの同時実行制限を引き上げて問題を解決しました。統合された監視と自動化された対応ワークフローにより、プロアクティブな対応と迅速な問題緩和が可能となりました。インシデント解決後、AWSインシデントマネージャーは、問題の原因と再発防止のための推奨事項を含む事後インシデントレポートを共有しました。推奨事項には、プロビジョニングされた同時実行性の有効化とLambdaの同時実行制限を監視する新しいCloudWatchアラームの作成が含まれていました。チームはまた、検知を改善するためのアラームのしきい値に関する推奨事項を提示し、それに応じてランブックを更新しました。 IDRは実際にどのような対応がなされるか？ 以下に示すように、AWS Incident Detection and Responseとの統合設定は、既存のアーキテクチャを変更する必要がありません。アプリケーションパフォーマンスモニタリング（APM）ツール（Amazon CloudWatch、Datadog、New Relicなど）からアラームを取り込むために、AWS Health Service Linked Roleへのアクセスを提供するだけで、AWS Incident Detection and Responseとの統合を簡単に設定できます。 アラームが発生した場合、AWS Incident Detection and Responseの自動化システムはAmazon Event Bridgeを通じてアラームを取り込み、AWSインシデントマネージャーとの連絡のために、お客様のアカウントでサポートケースを作成します。また、AWSサービスイベントに関する通知のため、お客様のアカウントのAWS Personal Health Dashboardも更新されます。AWS Incident Detection and Responseは、サードパーティのAPMから直接、またはWebhookを介してイベントの取り込みをサポートしています。AWS Incident Detection and Responseでワークロードを設定する方法の詳細については、AWS Incident Detection and ResponseユーザーガイドのGetting Startedセクションを参照してください。 AWS Incident Detection and Responseとシステムの連携 おわりに AWS Incident Detection and Responseは、チケット発券、手荷物取扱い、航空運航、空港運営、乗務員管理などの分野における重要なアプリケーションのインシデント管理プロセスを改善することができます。厳格なRPO（目標復旧時点）とRTO（目標復旧時間）の要件を持つアプリケーションは、このプロアクティブな対応から恩恵を受けることができます。ミッションクリティカルなシステムに影響を与える問題を適時に特定し、修復することで、運用の中断とお客様への影響を最小限に抑えることができます。 詳細については、 AWS Incident Detection and Responseユーザーガイド をご覧いただくか、AWSのアカウント担当者にお問い合わせください。 翻訳はソリューションアーキテクトの矢形が担当しました。原文は こちら です。 Naseer Sayyad Naseer Sayyadは、Amazon Web Servicesのシニアテクニカルアカウントマネージャーです。NaseerはAWSのエンタープライズ顧客と協力し、クラウド変革の過程で成功を収められるよう支援しています。クラウドコンピューティングと自動化に情熱を注いでおり、仕事以外では旅行と写真撮影を楽しんでいます。 Neel Sendas Neel Sendasは、Amazon Web Servicesのプリンシパルテクニカルアカウントマネージャーです。Neelは企業のお客様と協力して、ビジネス目標を達成するためのクラウドアプリケーションの設計、導入、スケーリングを支援しています。また、機械学習にも熱心で、製造業や物流業界向けの様々な機械学習のユースケースに取り組んできました。顧客支援以外の時間には、ゴルフとサルサダンスを楽しんでいます。 Temitope Baiyewu Temitope Baiyewuは、Amazon Web Servicesのシニアプロダクトマネージャーです。TemiはAWS Incident Detection and Responseの製品開発を主導しており、顧客がAWS上で重要なワークロードをより効率的に運用できるよう支援することに情熱を注いでいます。Temiは読書が大好きで、チェルシーFCの熱烈なファンです。

ライアンエアー（欧州最大の航空会社で1日3,330便以上を運航）は、2034年までに旅客数を2倍に増やす計画を立てています。そのため、最前線のスタッフに効果的な業務遂行に必要なツールを提供することが不可欠です。最近、Amazon Web Services (AWS)と協力して、新しい客室乗務員向けアプリを開発しました。 複雑なスケジューリングの課題 ライアンエアーは90以上の拠点に客室乗務員を配置し、欧州全域で1日最大3,300便を運航しています。客室乗務員は4人1組のチームで働き、自身の拠点で1日を始め終えます。通常のシフトでは最大800人の乗客をライアンエアーの便でお迎えします。 乗務員のスケジューリングは本社の運航計画チームが管理し、航空機の定時運航と各シフト終了時の乗務員の帰還を確実にする任務を担っています。訓練、休暇、天候による混乱などを考慮すると、スケジューリングがいかに複雑になるかがわかります。 ライアンエアーの事業規模が拡大し続けるにつれ、計画チームには最新の計画ツールを提供する必要があります。これにより、乗務員のスケジュール管理に必要な手作業のプロセスを削減できます。これまで客室乗務員は、スケジュール変更を要求する際にチケットを提出し、長い待ち行列で待つ必要がありました。運航チームは平均して月に8,000件ものシフト交代のリクエストだけを手作業で処理していました。 Working Backwardsアプローチ AWSでは、最も効果的な解決策は「Working Backwards(顧客の課題やニーズから逆算する)」ことで生み出されると考えています。そのため、ライアンエアーのようなお客様にAmazonの物流センターの見学や、エグゼクティブ向けブリーフィング、ビジョン策定ワークショップなどに参加していただき、同様のアプローチを体験していただいています。 ライアンエアーは2017年からAWSと協力関係を築いており、従業員アプリのインスピレーションは、ティルベリーにあるAmazonの物流センターの見学から得られました。見学中、物流と航空会社における複雑な業務での人員管理の類似点が明確になり、ライアンエアーチームは、Amazonのスタッフが従業員用モバイルアプリを使って仕事と生活をどのように管理しているかを体験しました。 「Amazonの従業員アプリを見たとき、私たちの乗務員にもこれが必要だと直感しました！」- ライアンエアー機内サービス部門ディレクター シネード・クイン 見学の後すぐに、ライアンエアーとAWSのチームは、Amazonの「Working Backwards」手法を用いて、客室乗務員のための革新的なソリューションについてブレインストーミングを行いました。ライアンエアーの機内サービス部門と人事部門は、AmazonのPeople Experience and Technology Solutions（PXT Solutions）チームと協力し、グローバルとローカルの両レベルでの人員管理の方法を検討し、ライアンエアーに最適なソリューションを見出しました。 構想から実現まで、PXT SolutionsチームのAmazonのプロダクトマネージャーとライアンエアーチームの間で継続的な連携が行われました。Amazonは、グローバルな従業員への変更展開や、組織全体でのオーナーシップ提供に関する自社の経験を共有しました。 2023年9月、シネード・クインのビジョンは、Ryanair Connectの立ち上げとして実現しました。このアプリは、ライアンエアーの客室乗務員が手のひらで簡単に仕事と生活を一元管理できるツールです。導入から4週間以内に、Ryanair Connectはライアンエアーの90以上の拠点と15,000人の客室乗務員に採用されました。 ライアンエアーのプロダクトマネージャー、ジョナサン・ドックレルは次のように語っています。「私の役割は、先を見通すことです。エンドユーザー（客室乗務員）や開発チームと密接に協力しながら、インパクトのある製品に仕上げていくプロセスを楽しんできました。以前に同様の経験をしたAmazonのプロダクトマネージャーにアクセスできたことが、このローンチの成功につながりました！」 Ryanair Connectは、AWSのサーバーレスサービスを使用して構築されており、数千人の客室乗務員からの需要に効率的に対応できるよう拡張可能です。イベントベースのアーキテクチャを採用し、ライアンエアーの基幹システムと統合されています。アクセスはAWS WAFとAWS Shield Advancedで保護されています。 客室乗務員の活躍を支えるRyanair Connect Ryanair Connectにより、客室乗務員は自分のスケジュールとフライトの詳細をほぼリアルタイムで確認できるようになりました。また、年次休暇やシフト交代のリクエストもより便利に行えるようになりました。 フライトスケジュールを予定通りに実施するため、予期せぬ事態に対応できるよう各シフトには常に待機中の客室乗務員がいます。ライアンエアーの運航チームは、その日に必要な待機乗務員の人数を確実に把握しています。待機中の乗務員は、アプリを使って待機勤務から外れることを申請でき、ビーチで過ごしたり家族と時間を過ごしたりすることができます。 おわりに Ryanair Connectアプリの成功を受けて、客室乗務員たちはさらなる革新を求めています。そこでライアンエアーチームは、客室乗務員の体験をさらに向上させ、業務を簡素化するためのロードマップを作成しました。この新しいロードマップには、生成AIの力をどのようにRyanair Connectに活用し、さらなる機能強化を図るかという検討も含まれています。 従業員が成長できるような適切なツールを提供し、企業文化を作ることは、多くの組織が目指す目標ですが、それを実現することは容易ではありません。ライアンエアーは2017年からAWSと協力関係を築き、信頼に基づいた強固な関係を発展させてきました。この協力を通じて、ライアンエアーは自社のビジネスの仕組みと将来の展望を共有してきました。 そして、AmazonとAWSは、150万人以上の従業員を抱えるまでに成長した経験から得た知見を共有しました。ライアンエアーが2034年までに3億人の旅客数を目指す中で、私たちは協力して、現在そして将来の従業員のニーズに応えるアプリを作り上げることができました。 AWSのクラウドサービスやソリューションを活用して従業員や顧客の体験を向上させる方法については、 AWS トラベル＆ホスピタリティ をご覧ください。 ビジネスの加速についてご相談は、AWSの担当者までお問い合わせください。 翻訳はソリューションアーキテクトの矢形が担当しました。原文は こちら です。 Shane Routley シェーン・ラウトリーは、AWSのシニアカスタマーソリューションズマネージャーとして、UKI（英国およびアイルランド）地域のエンタープライズ顧客のクラウド導入を支援しています。20年にわたるIT変革と製品管理の経験を持ち、顧客がビジネス価値を生み出すテクノロジーソリューションを提供できるよう支援しています。テクノロジーサービス、ヘルスケア、FMCG（日用消費財）業界での経験を持ち、現在は英国を拠点としています。

このブログでは、Java Messaging System (JMS) 2.0 API を使って書かれたプロデューサクライアントアプリケーションを使用して、Amazon MQ の ActiveMQ ブローカーの トランザクション機能 について説明します。JMS 2.0 API は使いやすく、前のバージョンに比べてインターフェースが少なくなっています。ActiveMQ の JMS 2.0 サポートの詳細に関しては、 ActiveMQ の JMS2.0 に関するドキュメント を参照してください。また、 JMS 2.0 の新機能 も合わせてご確認ください。 Amazon MQ は ActiveMQ 5.18 をサポートするようになりました。また、Amazon MQ では新しいセマンティックバージョニングシステムが導入され、マイナーバージョン (例: バージョン5.18) を表示し、同一のマイナーバージョン内の新しいパッチ (例: バージョン5.18.4) でブローカーを最新の状態に保つことができます。ActiveMQ 5.18 は、JMS 2.0、Spring 5.3.x のサポートと、いくつかの依存関係の更新とバグ修正が加えられています。詳細については、Active MQ 5.18.x リリースシリーズの リリースノート を参照してください。 概要 分散システムにおけるメッセージングパターン メッセージブローカーベースの分散メッセージングにメッセージングサービスを実装する多くの場合、発信と受信を切り離すファイア・アンド・フォーゲットメカニズムが伴います。このとき、プロデューサはメッセージをブローカーに送信し、ブローカーがコンシューマーへのメッセージ配信を保証する責任があります。非トランザクションの利用事例では、各メッセージは互いに独立しています。ただし、時にはメッセージのグループを 1 つのトランザクションの一部としてコンシューマーに配信する必要があります。つまり、グループ内のすべてのメッセージがコンシューマーに配信されるか、またはそれらのメッセージが全く配信されないかのいずれかを意味します。 ActiveMQ 5.18 では、JMS トランザクションと XA トランザクションの 2 つのレベルのトランザクションサポートを提供しています。 JMS トランザクションは、複数のメッセージをアトミックな単位として ActiveMQ ブローカーに送信する必要がある場合に使用されます。このトランザクション機能は、Session(JMS 1.xの場合)またはJMSContext(JMS 2.0の場合)オブジェクトでcommit()およびrollback()メソッドを呼び出すことで有効になります。すべてのメッセージが正常に送信された場合、commit() メソッドによってトランザクションをコミットし、メッセージがユニットとして処理されることを保証できます。また、送信プロセス中に問題が発生した場合は、rollback() メソッドによってトランザクションをロールバックして、メッセージの部分的な配信を防ぐことができます。このようなトランザクション機能は、データの整合性を維持し、複雑なメッセージング操作が確実に実行されるために重要です。トランザクションの動作の詳細については、 ActiveMQ FAQ – トランザクションの動作方法 を参照してください。 XA トランザクションは、2 つ以上のメッセージを ActiveMQ ブローカーと その他の分散リソースに対してトランザクション方式で送信する必要がある場合に使用されます。これは XA リソースとしてはたらく XA セッションを使って実現されます。XA トランザクションの詳細については、ActiveMQ FAQ の Should I use XA transactions FAQ を参照してください。 注文管理システムにおけるトランザクション利用事例 このブログ記事の例では、メッセージの受け渡しを管理するソフトウェアである「メッセージブローカー」として ActiveMQ を使用した Order Management System (OMS) アプリケーションのトランザクション機能について説明します。受注時に、OMS アプリケーションはメッセージ 1 をウェアハウスキューに送信してパッキングプロセス(商品の梱包作業)を開始します。次に、アプリケーションは内部の業務処理を実行します。このプロセスが成功した場合、アプリケーションはメッセージ 2 を出荷キューに送信して配送プロセス(商品の出荷作業)を開始します。内部の業務処理が失敗した場合、メッセージ 2 が出荷キューに配信されるのを防ぎ、メッセージ 1 をウェアハウスキューからロールバック(取り消し)する必要があります。 下のフローチャートは、この例で紹介しているトランザクション利用事例のロジックを示しています。 トランザクション利用事例を説明するフローチャート JMS クライアントは、トランザクションが commit または rollback されるまで、メッセージを両方ともメモリ内に保存します。これは、メッセージプロデューサークライアントとブローカー間のトランザクションセッションを維持することで実現されます。トランザクションセッションとは、メッセージ配信を保証するためにトランザクションを使用するセッションのことです。この例では、トランザクションセッションが次の文で作成されています。 JMSContext jmsContext = connectionFactory.createContext(adminUsername, adminPassword, Session.SESSION_TRANSACTED); この記事のサンプルでは、メッセージプロデューサーとブローカー間でのトランザクションセッションを示しています。ブローカーとメッセージコンシューマー間のトランザクションは示していません。開発者の皆様は、同様のパターンを使って実装できます。 ActiveMQ ブローカーの作成 Amazon MQ で ActiveMQ ブローカーを作成するには、以下の前提条件が必要です。 前提条件: AWS コマンドラインツール (CLI) をインストールします。 Java 11 以上 をインストールします。 AWS CLI を AmazonMQFullAccess 権限が付与された IAM プリンシパル (ユーザー/ロール) で設定します。 ブローカーを作成する (AWS CLI): 次のコマンドを実行して、ブローカーを作成します。これは、テスト専用の公開ブローカーを作成します。本番環境用のブローカーを作成する場合は、 Amazon MQ のセキュリティベストプラクティス を遵守してください。 aws mq create-broker \ --broker-name \ --engine-type activemq \ --engine-version 5.18 \ --deployment-mode SINGLE_INSTANCE \ --host-instance-type mq.t3.micro \ --auto-minor-version-upgrade \ --publicly-accessible \ --users Username =,Password =,ConsoleAccess = true <broker-name> はブローカーに付けたい名前に置き換えてください。 <username> と <password> は create-broker CLI ドキュメント に従って置き換えてください。コマンドを実行すると、コマンドラインにBrokerArn と BrokerId が出力されるので、その値をメモしてください。ブローカーの作成には約 15 分かかります。 次のコマンドを実行して、ステータスを取得します。 aws mq describe-broker --broker-id --query 'BrokerState' ブローカーの状態が Running になれば、次に進んでください。 次のコマンドを実行して、コンソール URL とその他のブローカーエンドポイントを取得します。 aws mq describe-broker --broker-id --query 'BrokerInstances[0]' 出力から ConsoleURL と SSL エンドポイントをメモしてください。 メッセージプロデューサークライアントの設定 このブログのサンプルコードでは、JMS 2.0 API を使って書かれた サンプルのメッセージプロデューサクライアント を使用して、ActiveMQ ブローカーにメッセージを送信しています。 トランザクションが成功した場合、プロデューサークライアントはメッセージを最初のキューに送信し、15 秒待機します。次に、メッセージを 2 番目のキューに送信し、さらに 15 秒待機します。最後に、トランザクションをコミットします。 トランザクションが失敗した場合、プロデューサークライアントは最初のメッセージを送信し、15 秒待機します。次に、コードで意図的な失敗を発生させ、トランザクションをロールバックさせます。15 秒の待機時間があれば、プログラムがトランザクション フローを進めている間にブローカー側のメッセージ数を確認できます。成功したトランザクションの場合でも、プロデューサーがコミットするまではメッセージはブローカーに送信されません。 サンプルクライアントをダウンロードして設定するには: Amazon MQ トランザクションサンプル Jar を GitHub リポジトリの指定のリンクから Jar ファイルをダウンロードします。 サンプルクライアントを実行するには、jar ファイルにカプセル化されたプログラムを実行する -jar オプションを付けて java コマンド を使用します。サンプルクライアントを実行するための構文は次のとおりです。 java -jar / username password ssl-endpoint first-queue second-queue message is-transaction-successful 使い方: <path-to-jar-file> – jar ファイルをダウンロードしたローカルマシン上のパス。 <jar-filename> – jar ファイル名。 <username> – ブローカーの作成時に選択したユーザー名。 <password> – ブローカーの作成時に選択したパスワード。 <ssl-endpoint> – 上記の手順で控えた SSL エンドポイント。 <first-queue> – トランザクション内の最初のキューの名前。 <second-queue> – トランザクション内の 2 つ目のキューの名前。 <message> – メッセージのテキスト。 <is-transaction-successful> – トランザクションが成功するかどうかをプロデューサークライアントに伝えるフラグ。 正常な取引のテスト ActiveMQ での正常なトランザクションをテストするには、次の手順を実行します。 ActiveMQ コンソールでキューとメッセージ数を確認する Amazon MQ コンソール にアクセスし、 ActiveMQ ブローカーを選択します。 Connections パネルから ActiveMQ Web Console にログインします。 Manage ActiveMQ broker をクリックします。 ブローカー作成時に作成したユーザーのユーザー名とパスワードを入力します。 トップナビゲーションバーで Queues をクリックします。 warehouse-queue と shipping-queue がリストに表示されていないことを確認します。 以下のコマンドを実行して、order1 のメッセージを両方のキューに正常に送信します: java -jar <path-to-jar-file>/<jar-filename> <username> <password> <ssl-endpoint> warehouse-queue shipping-queue order1 true 上記のコマンド説明にあるようにプレースホルダーを置き換えてください。このコマンドで、サンプルのプロデューサークライアントが最初のメッセージを warehouse-queue に送信し、次のメッセージをコンソールに出力して 15 秒待ちます。 Sending message: order1 to the warehouse-queue Message: order1 is sent to the queue: warehouse-queue but not yet committed. この 15 秒の待機中に、ブラウザを更新すると、warehouse-queue がリスト表示されますが、保留中またはエンキューされたメッセージはありません。15 秒後、プロデューサークライアントが 2 つ目のメッセージを shipping-queue に送信し、次のメッセージをコンソールに出力して 15 秒待ちます。 Sending message: order1 to the shipping-queue Message: order1 is sent to the queue: shipping-queue but not yet committed. この 15 秒の待機中に、ブラウザウィンドウを再度更新すると、shipping-queue がリストに表示されますが、warehouse-queue と同様に、保留中またはエンキューされたメッセージはありません。 最後に、プロデューサークライアントが両方のメッセージをコミットし、次のメッセージを出力します。 Committing Transaction for Message: order1 is now completely committed. ブラウザを更新すると、warehouse-queue と shipping-queue に保留中とエンキューされたメッセージがそれぞれ 1 つずつあることを確認できます。リストは次のようになります: shipping と warehouse キュー この手順を繰り返し、さらに成功したトランザクションをテストしてください。 失敗したトランザクションのテスト 各キュー内の保留中のメッセージとエンキューされたメッセージの最初の数をメモします。 次のコマンドを実行し、 false を渡して人為的な障害を導入します。 java -jar <path-to-jar-file>/<jar-filename> <username> <password> <ssl-endpoint> warehouse-queue shipping-queue failedorder1 false このコマンドにより、サンプルのプロデューサークライアントは最初のメッセージをwarehouse-queueに送信し、以下のメッセージをコンソールに表示して15秒間待機します。 Sending message: failedorder1 to the warehouse-queue Message: failedorder1 is sent to the queue: warehouse-queue but not yet committed. 15秒間の待機中にブラウザを更新し、warehouse-queueとshipping-queueのカウントが変更されていないことを確認してください。 最後にクライアントは人為的にエラーを発生させ、トランザクションをロールバックし、以下を表示します： Message: failedorder1 cannot be delivered because of an unknown error. Hence the transaction is rolled back. ブラウザを更新して、両方のキューのカウントが変更されていないことを確認してください。この例では、失敗したトランザクション後も各キューに1つずつメッセージがある状態から始まります。 コンソール上 shipping キューと warehouse キューのカウントが変更されていない 成功と失敗の両方の場合において、トランザクションの一部としてキューに送信されるメッセージは、クライアント側でインメモリに格納されることに注意してください。これらのメッセージは、トランザクションがコミットされた時にのみブローカーに送信されます。 クリーンアップ 次のコマンドを実行してブローカーを削除します aws mq delete-broker --broker-id まとめ この記事では、ActiveMQ バージョン 5.18 の Amazon MQ ブローカーを作成しました。また、Amazon MQ で導入された新しいセマンティックバージョニングについても学びました。ActiveMQ 5.18.x は JMS 2.0、Spring 5.3.x、および依存ライブラリの更新をサポートしています。最後に、ActiveMQ 5.18.x ブローカーのトランザクション機能を示しているサンプルアプリケーションを JMS 2.0 API を使用して作成しました。Amazon MQ の詳細については、 https://aws.amazon.com/amazon-mq/ をご覧ください。 このブログは、シニアテクニカルアカウントマネージャーの Paras Jain とシニアソリューションアーキテクトの Vinodh Kannan Sadayamuthu によって執筆されたものをソリューションアーキテクト三厨が翻訳しました。原文は こちら 。