皆様、こんにちは！PSA (Partner Solutions Architect) の Yukki です。 本記事では直近新規公開された、AWS 初学者向けのコンテンツをご紹介いたします。 皆様や皆様の周りでこのようなお悩みを持っている方はいませんか？ 「クラウドという言葉はよく聞くけど、実はどういうものか説明できない」 「あまりにも学習リソースが多すぎて、何から始めればいいかわからない」 「AWS って結局何ができるの？」 このような方をこの記事の対象として、 2023 年 9 ～ 11 月に公開された初学者向けの動画コンテンツ をご紹介します。   1. QuizKnock 鶴崎 氏が語る AWS の魅力 (提供：アマゾン ウェブ サービス ジャパン合同会社) QuizKnock【クイズノック】はクイズ王・伊沢 拓司 氏率いる東大発の知識集団です。 QuizKnock の YouTube チャンネル 登録者は 212 万人を突破。(2023 年 10 月時点) そのメンバーである鶴崎 修功 氏はなんと AWS ユーザー。「AWS でどんなツールを作ったの？」「ユーザーの視点から見てどんな点がいいの？」といった内容を、実際の AWS ユーザーならではの実感を持って語っていただきます。 AWS の推しサービスの話もあり、熱量を感じ取ることができる動画です。 言わずと知れたクイズ王・伊沢 拓司 氏が初学者の目線から質問をしてくれるので、初めて AWS に触れるという方も楽しさが伝わる内容になっています。まずは気軽に開発の世界に触れてみたいという皆様、ぜひご覧ください。 また動画で紹介されたコンテンツは、以下のページにまとめられていますので合わせてチェックしてみてください。 https://aws.amazon.com/jp/local/quizknock-tie-up/   2. Cloud for Beginners on-demand training こちらの動画は IT 初学者の方を対象に、基礎的な IT 用語の説明と AWS クラウドを学習する上で必要となる IT 知識について解説する合計約 3 時間のオンデマンドコンテンツです。ウェブサービスや、サーバーはどのように構成されているのか、CPU やメモリはどのような働きをしているのか、 AWS クラウドがどういうものなのかといった、AWS の学習をはじめる際に前提となる知識を効率よく学ぶことができます。IT に関する専門用語について適宜解説しながら進行しているので、AWS に関心がある非 IT 領域の方々や学生の皆様にお勧めです。登録不要ですぐにご覧いただけます。 ご視聴はこちらから： ご視聴ページ        3. AWSome Day Online Conference AWS クラウド初学者向け大規模オンラインイベント AWSome Day Online Conference が 2023 年 11 月 16 日（木）に開催 されます！今回で年内最後の開催となります。上記の 1, 2 で概要についての予備知識を手に入れたあなたなら、きっとより楽しめるのがこのイベントです。実は私がこのイベントの講師をしています。私 Yukki と、トレーニングチームでプログラムマネージャーをしている平賀の 2 名による台本無しの掛け合い形式で進行していきます。平賀さんは皆様の立場になって質問をしたりコメントをしますので、聞きやすくなっています。 さらにそれぞれのトピックでは、AWS を実際に操作するデモを取り入れました。デモも掛け合いを行っていますので、ぜひ皆様は平賀さんの立場になって聞いていただけると、より操作するイメージが湧きやすくなると思います！もし聞いている中で疑問に思うことがあったら、すぐにプライベートチャットで AWS エキスパートに質問することができます。その場で疑問を解消していくことがスムーズな学習のコツ！ということで、ぜひこの機会をご活用ください。資料のダウンロードもできるので、復習にも役立ちます。 こちらのオンラインイベントは参加登録が必要です。お忘れなく！また AWSome Day の画面でお会いしましょう！！ ご登録はこちらから： 登録ページ        まとめ 本記事では、AWS 初学者向けに最近公開されたコンテンツをご紹介しました。このほかにも、2023 年 10 月にはロールプレイング形式で AWS クラウドについて学べる AWS Cloud Quest の日本語版 の公開もされるなど、数多くの入り口が用意されています。 これらのリソースを活用して、今日から AWS の学習を早速始めてみましょう！最後まで読んでいただき、本当にありがとうございました！！

イントロダクション Amazon VPC Lattice は、AWS ネットワークインフラストラクチャに直接組み込まれた、フルマネージドなアプリケーションネットワーキングサービスです。複数のアカウント、複数の仮想プライベートクラウド (VPC) にまたがる全てのサービスの接続、セキュア化、監視に使用できます。 Amazon Elastic Kubernetes Service ( Amazon EKS ) では、 Kubernetes Gateway API の実装である AWS Gateway API コントローラー を通じて、Amazon VPC Lattice を使用できます。Amazon EKS のお客様は、Amazon VPC Lattice を用いることで、シンプルかつ一貫性のある方法で、標準的な Kubernetes のセマンティクスによりクラスターをまたいだ接続を設定できます。 一方で、特定のお客様ではアプリケーションレイヤーのセキュリティを強化したいという要望がありました。Amazon VPC Lattice のデザインはセキュアバイデフォルトです。これは、どのサービスを共有したいのか、どの VPC にアクセスを提供したいのかを、明確にする必要があるためです。 Amazon VPC Lattice は 3 レイヤーのフレームワーク を提供しており、ネットワークの複数のレイヤーで多層防御戦略を実装できます。これらのレイヤーには、サービスネットワークと VPC の関連付け、セキュリティグループ、ネットワークアクセスコントロールリスト (ACL)、AWS Identity and Access Management ( AWS IAM ) 認証ポリシーが含まれ、Amazon VPC Lattice を構成することでセキュリティとコンプライアンスの目標を達成することができます。 VPC 内のセキュリティグループのサービスネットワークへの関連付けと認証ポリシーは、どちらもオプションです。セキュリティグループを設定せずに、サービスネットワークを VPC に関連付けることができます。また、認証タイプを NONE に設定して、認証ポリシーを使用しないこともできます。 本記事では、3 つ目のレイヤー、すなわちサービスネットワークと各々のサービスに適用できる、VPC Lattice の認証ポリシーに焦点を当てます。通常、サービスネットワークの認証ポリシーはネットワーク管理者あるいはクラウド管理者によって運用され、粗い粒度での認証を実装します。例えば、AWS Organizations の指定した組織からの認証済みリクエストのみ許可します。一方、サービスの認証ポリシーでは、サービスのオーナーはネットワーク管理者やクラウド管理者がサービスネットワークのレベルで適用した粗い粒度での認証ルールよりも制限の厳しい、きめ細やかな制御を設定できます。認証ポリシーを使用することで、お客様はアプリケーションのコードを変更することなく、 誰が、どのサービスに対して、どのアクションを実行できるか を定義することができます。 我々の実装では、以下の方法を示します。 Amazon VPC Lattice サービスネットワークと Amazon EKS を構築し、Amazon VPC Lattice サービスの認証ポリシーを有効にします。 Amazon EKS と Amazon VPC Lattice でのサイドカーパターンと Init コンテナパターンを用いて、サービスの呼び出し元が AWS IAM 認証で Amazon VPC Lattice サービスに対しての HTTP リクエストの生成を自動的におこなえるようにするソリューションを構築します。呼び出し元のアプリケーションのソースコードの変更は必要ありません。 サービスの呼び出し元が Amazon VPC Lattice サービスネットワーク内の複数のサービスに接続できることを確認します。 ソリューション概要 Amazon VPC Lattice は AWS IAM と統合され、お客様独自のサービス間通信のために、現在 AWS サービスとやり取りする時に慣れ親しんでいるのと同様の認証・認可の機能を提供します。 サービスのアクセス制御を設定するために、アクセスポリシーを使用できます。アクセスポリシーは、サービスネットワークと個々のサービスに関連付けることができる AWS IAM リソースポリシーです。アクセスポリシーでは、PARC (Principal、Action、Resource、Condition) モデルを使用して、サービスのコンテキスト固有のアクセス制御を適用できます。例えば、所有するサービスに対してアクセス可能なサービスを定義するために、アクセスポリシーを使用できます。 Amazon VPC Lattice はクライアント認証に AWS Signature Version 4 (SigV4) を使用します。Amazon VPC Lattice のサービスで認証ポリシーを有効化した後に、署名付き Authorization ヘッダー、 x-amz-content-sha256 、 x-amz-date 、 x-amz-security-token が HTTP リクエストに含まれるよう、サービスを呼び出す側を変更する必要があります。AWS SigV4 の詳細は こちら を参照してください。 Amazon VPC Lattice サービスへのリクエストに署名するために、お客様には以下の選択肢があります。 AWS SDK を用いて、対応するプログラミング言語でリクエストに署名します。このソリューションはパフォーマンスが最適化されますが、アプリケーション開発者によるコードの変更を必要とします。実装については Amazon VPC Lattice のドキュメント を参照してください。 AWS SIGv4 プロキシアドミッションコントローラーを活用し、 AWS SIGv4 プロキシ を用いて HTTP リクエストをフォワードし、AWS Sigv4 ヘッダーを追加します。詳細については、こちらの 記 事 を参照してください。しかし、上記のソリューションには 1 つの制限があります。AWS SIGv4 プロキシアドミッションコントローラーを使用する場合、単一のホストしかサポートされません。 サンプルのマニフェスト では、フロントエンドのコンテナは localhost:8005 にリクエストをしていて、Host ヘッダーは sidecar.aws.signing-proxy/host Annotations で静的に定義された datastore-lambda.sarathy.io に置き換えられていることがわかります。言い換えると、呼び出し元のサービスは単一の Amazon VPC Lattice サービスにのみ接続できます。クライアントが複数の Amazon VPC Lattice サービスに接続する場合に、課題となります。 この記事では、完全に透過的に複数の Amazon VPC Lattice サービスに対する接続をサポートする、最適化されたソリューションを紹介します。 はじめに、Kubernetes の Pod に Init コンテナとサイドカーコンテナを導入します。 Init コンテナ： iptables を実行し、ポート 8080 をリッスンする AWS SigV4 プロキシから Amazon VPC Lattice サービスへのトラフィックをインターセプトします。 SigV4 プロキシ： --name vpc-lattice-svcs, --unsigned-payload フラグとロギングのオプションを含む args を指定して実行します。プロキシコンテナは AWS IAM roles for service accounts (IRSA) によって取得された認証情報を使用して、自動的にリクエストに署名します。 次に、Init コンテナとサイドカーコンテナを自動的に注入します。開発チームが既存の Kubernetes マニフェストに変更を加えないようにするためです。ポリシーエンジンとして Kyverno を使用します。Kyverno は Kubernetes のために設計されており、Kubernetes クラスター内で Dynamic Admission Controller として動作します。この場合、Kyverno は Kubernetes API サーバーから Mutating Admission Webhook の HTTP コールバックを受け取り、マッチするポリシーを適用して、Admission Policy を強制する結果を返します。言い換えると、Kyverno は Init コンテナとサイドカーコンテナをコーディングを必須とせずに自動的に注入することができます。 ウォークスルー Amazon EKS における Amazon VPC Lattice と認証ポリシー 前提条件 管理者権限を持つ AWS アカウント AWS Command Line Interface ( AWS CLI )、 kubectl 、 eksctl 、 Git のインストール Amazon EKS クラスターと Amazon VPC Lattice サービスの準備 ソリューションをテストするための環境を準備する必要があります。 Amazon EKS クラスターの作成と、Amazon VPC Lattice のための Gateway API コントローラーのインストール Kyverno のインストール サンプル httpbin アプリケーションを Amazon VPC Lattice サービスとしてデプロイする 以下のコマンドを使用して、httpbin を Amazon VPC Lattice サービスとしてデプロイします。 git clone https://github.com/aws/aws-application-networking-k8s.git cd aws-application-networking-k8s/examples ## Create the GatewayClass, Gateway, HTTPRoute, Service and Deployment objects kubectl apply -f gatewayclass.yaml kubectl apply -f my-hotel-gateway.yaml kubectl apply -f httpbin.yaml kubectl apply -f httpbin-route.yaml ## Create another VPC Lattice Service (HTTPRoute), Service and Deployment object cat << EOF > another-httpbin.yaml apiVersion: apps/v1 kind: Deployment metadata: name: another-httpbin labels: app: another-httpbin spec: replicas: 1 selector: matchLabels: app: another-httpbin template: metadata: labels: app: another-httpbin spec: containers: - name: httpbin image: mccutchen/go-httpbin --- apiVersion: v1 kind: Service metadata: name: another-httpbin spec: selector: app: another-httpbin ports: - protocol: TCP port: 80 targetPort: 8080 EOF cat << EOF > another-httpbin-route.yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: another-httpbin spec: parentRefs: - name: my-hotel sectionName: http rules: - backendRefs: - name: another-httpbin kind: Service port: 80 EOF ## Another VPC Lattice Service kubectl apply -f another-httpbin.yaml kubectl apply -f another-httpbin-route.yaml Bash サービスネットワークの保護 この機能を実証するために、 httpbin サービスに認証ポリシーを適用し、認証されたアクセスのみを許可します。 ドキュメント を参照することで、粒度の細かいポリシーを定義できます。 AWS コンソールの VPC セクションに移動し、 VPC Lattice の下の Services 、右ペインの httpbin-default サービスを選択します。 次のページで Access タブの Edit access settings を選択します。 表示される Service access 画面で、 AWS IAM から Apply policy template > Allow only authenticated access を選択します。次に Save changes を選択します。 ここで、サービスが AWS IAM 認証を必要とし、そうでなければ HTTP 403 Forbidden エラーを返すかを示すテストを実施します。 kubectl run curl --image alpine/curl -ti -- /bin/sh curl -v http://httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws * Trying 169.254 .171.32:80 .. . * Connected to httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws ( 169.254 .171.32 ) port 80 ( #0) > GET / HTTP/1.1 > Host: httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws > User-Agent: curl/8.0.1 > Accept: / < HTTP/1.1 403 Forbidden < content-length: 253 < content-type: text/plain < date: Mon, 31 Jul 2023 07:24:10 GMT < * Connection #0 to host httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws left intact AccessDeniedException: User: anonymous is not authorized to perform: vpc-lattice-svcs:Invoke on resource: arn:aws:vpc-lattice:us-west-2:091550601287:service/svc-09ff9bb5d43b72048/ because no service-based policy allows the vpc-lattice-svcs:Invoke action # Bash 呼び出し元のアプリケーションのデプロイ ここで、AWS IAM roles for service accounts (IRSA) を使用するようプロキシを構成し、プロキシがリクエストに署名するために AWS IAM ロールの認証情報を使用できるようにします。アイデンティティベースのポリシーである VPCLatticeServicesInvokeAccess を AWS IAM ロールにアタッチすることで、Amazon VPC Lattice サービスを呼び出す権限をロールに付与できます。 Service Account 用の IAM ロールの作成 export CLUSTER_NAME = my-cluster export NAMESPACE = default export SERVICE_ACCOUNT = default eksctl create iamserviceaccount \ --cluster = $CLUSTER_NAME \ --namespace = $NAMESPACE \ --name = $SERVICE_ACCOUNT \ --attach-policy-arn = arn:aws:iam::aws:policy/VPCLatticeServicesInvokeAccess \ --override-existing-serviceaccounts \ --approve Bash 準備が完了したら、プロキシコンテナと一緒にサービスを呼び出すアプリケーションを準備します。プロキシコンテナはポート 8080 をリッスンし、ユーザー ID 101 として実行します。YAML スニペットは以下のとおりです。 - name : sigv4proxy image : public.ecr.aws/aws - observability/aws - sigv4 - proxy : latest args : [ "--unsigned-payload" , "--log-failed-requests" , "-v" , "--log-signing-process" , "--name" , "vpc-lattice-svcs" , "--region" , "us-west-2" , "--upstream-url-scheme" , "http" ] ports : - containerPort : 8080 name : proxy protocol : TCP securityContext : runAsUser : 101 YAML ここでは、メインのアプリケーションからのトラフィックをインターセプトし、 iptables ユーテリティを使って Amazon VPC Lattice CIDR 169.254.171.0/24 に接続するトラフィックを EGRESS_PROXY チェーンにルーティングし、ローカルのポート 8080 にリダイレクトしています。プロキシコンテナによってトラフィックが送信される際の無限ループを避けるため、UID が 101 かどうかをチェックすることで識別し、再度リダイレクトされないようにしています。 initContainers : # IPTables rules are updated in init container - image : public.ecr.aws/d2c6w7a3/iptables name : iptables - init securityContext : capabilities : add : - NET_ADMIN command : # Adding --uid-owner 101 here to prevent traffic from envoy proxy itself from being redirected, which prevents an infinite loop - /bin/sh - - c - > iptables -t nat -N EGRESS_PROXY; iptables -t nat -A OUTPUT -p tcp -d 169.254.171.0/24 -j EGRESS_PROXY; iptables -t nat -A EGRESS_PROXY -m owner --uid-owner 101 -j RETURN; iptables -t nat -A EGRESS_PROXY -p tcp -j REDIRECT --to-ports 8080; YAML コンテナイメージ public.ecr.aws/d2c6w7a3/iptables は、シンプルに iptables がインストールされた Ubuntu Linux ディストリビューションのベースイメージです。 FROM ubuntu:focal RUN apt update && apt install -y iptables Bash 完全な YAML マニフェストは以下のようになります。 apiVersion: apps/v1 kind: Deployment metadata: name: client-app labels: app: client-app spec: replicas: 1 selector: matchLabels: app: client-app template: metadata: labels: app: client-app spec: serviceAccountName: default initContainers: # IPTables rules are updated in init container - image: public.ecr.aws/d2c6w7a3/iptables name: iptables-init securityContext: capabilities: add: - NET_ADMIN command: # Adding --uid-owner 101 here to prevent traffic from aws-sigv4-proxy proxy itself from being redirected, which prevents an infinite loop - /bin/sh - -c - > iptables -t nat -N EGRESS_PROXY ; iptables -t nat -A OUTPUT -p tcp -d 169.254 .171.0/24 -j EGRESS_PROXY ; iptables -t nat -A EGRESS_PROXY -m owner --uid-owner 101 -j RETURN ; iptables -t nat -A EGRESS_PROXY -p tcp -j REDIRECT --to-ports 8080 ; containers: - name: app image: alpine/curl command: [ "/bin/sh" , "-c" , "sleep infinity" ] - name: sigv4proxy image: public.ecr.aws/aws-observability/aws-sigv4-proxy:latest args: [ "--unsigned-payload" , "--log-failed-requests" , "-v" , "--log-signing-process" , "--name" , "vpc-lattice-svcs" , "--region" , "us-west-2" , "--upstream-url-scheme" , "http" ] ports: - containerPort: 8080 name: proxy protocol: TCP securityContext: runAsUser: 101 Bash curl を実行することで、/get のレスポンスが表示されます。レスポンスは HTTP 200 OK です。 ➜ kubectl get gateway -o yaml | yq '.items[0].status.addresses[].value' another-httpbin-default-03422a15c25e5fca4.7d67968.vpc-lattice-svcs.us-west-2.on.aws httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws ➜ VPC_LATTICE_SERVICE_ENDPOINT = http://httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get ➜ kubectl exec -c app -ti deploy/client-app -- curl $VPC_LATTICE_SERVICE_ENDPOINT { "args" : { } , "headers" : { "Accept" : "*/*" , "Accept-Encoding" : "gzip" , "Host" : "httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws" , "User-Agent" : "curl/8.0.1" , "X-Amz-Content-Sha256" : "UNSIGNED-PAYLOAD" , "X-Amzn-Source-Vpc" : "vpc-027db8599a32b83e2" } , "origin" : "192.168.46.245" , "url" : "http://httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get" } Bash プロキシコンテナのログを確認することで、ヘッダーがプロキシによって追加されたことを確認できます。 Authorization ヘッダーと、 x-amz-content-sha256 、 x-amz-date 、 x-amz-security-token といったヘッダーがリクエストに追加されています。 ➜ kubectl logs deploy/vpc-lattice-client -c sigv4proxy time = "2023-08-07T10:14:59Z" level = debug msg = "signed request" region = us-west-2 service = vpc-lattice-svcs time = "2023-08-07T10:14:59Z" level = debug msg = "proxying request" request = "GET /get HTTP/1.1 \r \n Host: httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws \r \n Accept: */* \r \n Authorization: AWS4-HMAC-SHA256 Credential=ASIARKUGXKBDQVWU6BFX/20230807/us-west-2/vpc-lattice-svcs/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date;x-amz-security-token, Signature=<redacted> \r \n User-Agent: curl/8.0.1 \r \n X-Amz-Content-Sha256: UNSIGNED-PAYLOAD \r \n X-Amz-Date: 20230807T101459Z \r \n X-Amz-Security-Token: IQoJb3JpZ2luX2VjEMr//////////<redacted>== \r \n \r \n " Bash ここでは、 VPC_LATTICE_SERVICE_ENDPOINT を 2 つ目のホスト名に置き換えることができます。アプリケーションコードの変更は必要としないので、複数の Amazon VPC Lattice サービスに接続することができます。 ➜ VPC_LATTICE_SERVICE_ENDPOINT = http://another-httpbin-default-03422a15c25e5fca4.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get ➜ kubectl exec -c app -ti deploy/client-app -- curl $VPC_LATTICE_SERVICE_ENDPOINT { "args" : { } , "headers" : { "Accept" : "*/*" , "Accept-Encoding" : "gzip" , "Host" : "another-httpbin-default-03422a15c25e5fca4.7d67968.vpc-lattice-svcs.us-west-2.on.aws" , "User-Agent" : "curl/8.0.1" , "X-Amz-Content-Sha256" : "UNSIGNED-PAYLOAD" , "X-Amzn-Source-Vpc" : "vpc-027db8599a32b83e2" } , "origin" : "192.168.32.152" , "url" : "http://another-httpbin-default-03422a15c25e5fca4.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get" } Bash Kyverno を使って、Init コンテナとサイドカーコンテナを自動で注入する ここで、Kyverno を活用して、Init コンテナとサイドカーコンテナを自動で注入するようにします。Kyverno がインストールされたクラスターでは、注入するための ClusterPolicy を書くことができます。Deployment オブジェクトに vpc-lattices-svcs.amazonaws.com/agent-inject が true であるアノテーションが設定されると、Deployment に Init コンテナとサイドカーコンテナが注入されます。 環境変数 AWS_REGION を指定する必要もあります。 apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: inject-sidecar annotations: policies.kyverno.io/title: Inject Sidecar Container spec: rules: - name: inject-sidecar match: any: - resources: kinds: - Deployment mutate: patchStrategicMerge: spec: template: metadata: annotations: ( vpc-lattices-svcs.amazonaws.com/agent-inject ) : "true" spec: initContainers: # IPTables rules are updated in init container - image: public.ecr.aws/d2c6w7a3/iptables name: iptables-init securityContext: capabilities: add: - NET_ADMIN command: # Adding --uid-owner 101 here to prevent traffic from envoy proxy itself from being redirected, which prevents an infinite loop - /bin/sh - -c - > iptables -t nat -N EGRESS_PROXY ; iptables -t nat -A OUTPUT -p tcp -d 169.254 .171.0/24 -j EGRESS_PROXY ; iptables -t nat -A EGRESS_PROXY -m owner --uid-owner 101 -j RETURN ; iptables -t nat -A EGRESS_PROXY -p tcp -j REDIRECT --to-ports 8080 ; containers: - name: sigv4proxy env: - name: AWS_REGION value: "us-west-2" image: public.ecr.aws/aws-observability/aws-sigv4-proxy:latest args: [ "--unsigned-payload" , "--log-failed-requests" , "-v" , "--log-signing-process" , "--name" , "vpc-lattice-svcs" , "--region" , \ $( AWS_REGION ) , "--upstream-url-scheme" , "http" ] ports: - containerPort: 8080 name: proxy protocol: TCP securityContext: runAsUser: 101 Bash このアプローチでは、Kubernetes Deployment の YAML に vpc-lattices-svcs.amazonaws.com/agent-inject: "true" を指定すると、Deployment に Init コンテナとサイドカーコンテナが注入されます。 クライアントの YAML は以下です。 apiVersion: apps/v1 kind: Deployment metadata: name: vpc-lattice-client labels: app: vpc-lattice-client spec: replicas: 1 selector: matchLabels: app: vpc-lattice-client template: metadata: labels: app: vpc-lattice-client annotations: vpc-lattices-svcs.amazonaws.com/agent-inject: "true" spec: serviceAccountName: default containers: - name: app image: alpine:curl command: [ "/bin/sh" , "-c" , "sleep infinity" ] Bash サイドカーは自動的に注入されます。 ➜ kubectl describe deploy vpc-lattice-client Name: vpc-lattice-client Namespace: default CreationTimestamp: Thu, 20 Jul 2023 11 :01:32 +0800 Labels: app = vpc-lattice-client Annotations: deployment.kubernetes.io/revision: 1 policies.kyverno.io/last-applied-patches: inject-sidecar.inject-sidecar.kyverno.io: added /spec/template/spec/containers/0 .. . Bash パッチが当たった YAML マニフェストは以下のようになります。 ➜ kubectl get deploy vpc-lattice-client -o yaml apiVersion: apps/v1 kind: Deployment metadata: annotations: deployment.kubernetes.io/revision: "1" kubectl.kubernetes.io/last-applied-configuration: | { "apiVersion" : "apps/v1" , "kind" : "Deployment" , "metadata" : { "annotations" : { } , "labels" : { "app" : "vpc-lattice-client" } , "name" : "vpc-lattice-client" , "namespace" : "default" } , "spec" : { "replicas" :1, "selector" : { "matchLabels" : { "app" : "vpc-lattice-client" } } , "template" : { "metadata" : { "annotations" : { "vpc-lattices-svcs.amazonaws.com/agent-inject" : "true" } , "labels" : { "app" : "vpc-lattice-client" } } , "spec" : { "containers" : [ { "command" : [ "/bin/sh" , "-c" , "sleep infinity" ] , "env" : [ { "name" : "HTTP_PROXY" , "value" : "localhost:8080" } ] , "image" : "nicolaka/netshoot" , "name" : "app" } ] , "serviceAccountName" : "default" } } } } policies.kyverno.io/last-applied-patches: | inject-sidecar.inject-sidecar.kyverno.io: added /spec/template/spec/containers/0 creationTimestamp: "2023-07-20T03:01: labels: app: vpc-lattice-client name: vpc-lattice-client namespace: default spec: selector: matchLabels: app: vpc-lattice-client template: metadata: annotations: vpc-lattices-svcs.amazonaws.com/agent-inject: " true" creationTimestamp: null labels: app: vpc-lattice-client spec: containers: - args: - --unsigned-payload - --log-failed-requests - -v - --log-signing-process - --name - vpc-lattice-svcs - --region - $( AWS_REGION ) - --upstream-url-scheme - http env: - name: AWS_REGION value: us-west-2 image: public.ecr.aws/aws-observability/aws-sigv4-proxy:latest imagePullPolicy: Always name: sigv4proxy ports: - containerPort: 8080 name: proxy protocol: TCP resources: { } securityContext: runAsUser: 101 terminationMessagePath: /dev/termination-log terminationMessagePolicy: File - command: - /bin/sh - -c - sleep infinity image: alpine:curl imagePullPolicy: Always name: app initContainers: - command: - /bin/sh - -c - | iptables -t nat -N EGRESS_PROXY ; iptables -t nat -A OUTPUT -p tcp -d 169.254 .171.0/24 -j EGRESS_PROXY ; iptables -t nat -A EGRESS_PROXY -m owner --uid-owner 101 -j RETURN ; iptables -t nat -A EGRESS_PROXY -p tcp -j REDIRECT --to-ports 8080 ; image: public.ecr.aws/d2c6w7a3/iptables name: iptables-init securityContext: capabilities: add: - NET_ADMIN .. . Bash また、クライアントが Amazon VPC Lattice サービスに正常にアクセスできることも確認できます。 ❯ VPC_LATTICE_SERVICE_ENDPOINT = http://httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get kubectl exec -c app -ti deploy/vpc-lattice-client -- curl $VPC_LATTICE_SERVICE_ENDPOINT { "args" : { } , "headers" : { "Accept" : "*/*" , "Accept-Encoding" : "gzip" , "Host" : "httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws" , "User-Agent" : "curl/8.0.1" , "X-Amz-Content-Sha256" : "UNSIGNED-PAYLOAD" , "X-Amzn-Source-Vpc" : "vpc-027db8599a32b83e2" } , "origin" : "192.168.32.152" , "url" : "http://httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get" } Bash クリーンアップ 将来的な課金を避けるため、以下のコマンドを使用して Amazon VPC Lattice リソースと Amazon EKS クラスターを含む、全てのリソースを削除します。 kubectl delete -f httpbin.yaml kubectl delete -f httpbin-route.yaml kubectl delete -f another-httpbin.yaml kubectl delete -f another-httpbin-route.yaml kubectl delete -f my-hotel-gateway.yaml kubectl delete -f gatewayclass.yaml eksctl delete cluster -f $CLUSTER_CONFIG Bash まとめ この記事では、Amazon VPC Lattice に AWS IAM 認証を実装する方法を、以下のようなソリューションを用いて紹介しました。 Init コンテナを使って iptables コマンドを実行し、VPC Lattice へのトラフィックをインターセプトする。 Kyverno を用いて Init コンテナとサイドカーコンテナを自動的に注入する。 呼び出し元のサービスは、VPC Lattice サービスネットワーク内の IAM 認証で複数のサービスに接続できるようになる。 VPC Lattice をベースにソリューションを構築し、VPC Lattice の IAM 認証を活用してセキュリティ体制を強化したい場合に、本ブログで共有した内容がお役に立てば嬉しいです。Amazon VPC Lattice の詳細については、 ドキュメント やその他の ブログ を参照してください。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

みなさんこんにちは。ソリューションアーキテクトの林です。2023 年 10 月12 日に AWS が主催するエネルギー業界向けイベント「AWS Energy Tech Forum 2023」を開催しました。今年で 2 回目となる本イベントも 前回 同様のオンライン開催となりましたが、 1000 名近く の方にご登録いただきました。今年の本イベントでは、エネルギー業界で先進的に AWS をご活用いただいている、送配電網協議会様、関電システムズ様、JERA 様、北海道ガス様、関西電力送配電様にご登壇いただきました。 オープニング – 川島 浩史 アマゾン ウェブ サービス ジャパン合同会社 エンタープライズ事業統括本部 ストラテジックカスタマー営業本部 第三営業部 部長 オープニングでは、エネルギー業界におけるクラウド活用のバリューチェーンや日本のエネルギー企業さまのクラウド活用の拡大についてご紹介しました。また、グローバルでの参考取組みとして、ENGIE 社におけるゼロカーボンエネルギーのためのデジタルプラットフォーム、Duke Energy 社と AWS の戦略的提携とグリッドソリューションの共同開発、NERC CIP 標準の対応をサポートするための AWS ユーザーガイド公開について紹介しました。 電力データで何ができるか 社会課題解決に向けた電力データ集約システムの取り組み –  田村 豪一朗 様 送配電網協議会 ネットワーク企画部 部長（電力データ活用担当） セッションでは、送配電網協議会様より、全国のスマートメーターデータを扱う電力データ集約システム構築に至る背景やAWS 選定の理由、実装アーキテクチャなどについてご説明頂きました。ペタバイトクラスの大量データを扱うシステムとして、AWS クラウドの柔軟性と高可用性のメリットを最大限活用した事例となっております。 2020 年 6 月の改正電気事業法により、スマートメーターから得られる電力使用量データを、有事の際に災害復旧などへの活用、平時においても (利用者本人が同意した場合に限り) 社会課題解決などを目的とする活用が可能となりました。スマートメーターデータを活用することで、防災計画の高度化などの災害発生時のレジリエンス強化だけでなく、平時においてもみまもりサービスなどの新たなイノベーションを実現できます。しかし、法改正当時は手作業でデータを抽出しており、データ取得のための作業コストに課題がありました。電力データ集約システムはそのような課題に端を発し、2021 年に検討が開始され、18 カ月の構築フェーズを経て 2023 年 9 月末に運用を開始されております。各エリアで段階的に運用を開始される予定です。全国 10 社の一般送配電事業者から連携されるスマートメーターデータは約 8,000 万件となり、3 年間保持した場合は電力データ量だけで数ペタバイトに及ぶため、システム基盤は大量データを扱うことができ、拡張性がある必要がありました。AWS の拡張性や東京・大阪リージョンの冗長構成での高可用性をご評価頂き、AWS 上での基盤構築の運びとなりました。電力データ集約システムでは全国のスマートメーターデータを収集・加工・蓄積し、Web、API 経由で自治体などの許可された利用者への提供を実現する必要があります。大量データの加工には Amazon EMR   を利用した並列加工処理を、増加するデータの蓄積には Amazon Simple Storage Service (S3) を利用して実質無制限でのデータ保存とデータ量に応じた従量課金を実現しております。 関西電力のデジタルトランスフォーメーションを支えるクラウド基盤のアジリティ向上への取り組み –  金子 恭史 様 株式会社関電システムズ テクニカルラボ クラウド＆アーキテクチャグループ アシスタントマネジャー セッションでは、関西電力様にて組成した CCoE (Cloud Center of Excellence) 組織や活動内容と更なるアジリティ向上のためのクラウド活用方針についてお話いだたきました。クラウド活用推進のための組織づくりや目標設定を検討されている参加者に参考になる具体的な取組みであったと推察します。 関西電力様は 2025 年までに新たな価値創造を目標とした “Kanden Transformation” を進めており、その加速に向けて IT インフラの「迅速さ・柔軟さ」「IT コスト削減」を実現するクラウドの活用を促進されており、2020 年にクラウドファースト宣言と CCoE を発足されました。クラウド活用推進の体制としては、本社組織が技術的な戦略を担いつつ、情報子会社である関電システムズに実動部隊としての CCoE を設置、基盤運用をオプテージ社が担うという体制を取られております。さらには AWS Professional Services をご活用いただくことで、AWS 利用ガイドライン作成などを効率的に実施されております。 直近では更にクラウドのメリットを活かした迅速でアジリティのある運用を実現するために、セキュリティルールの再定義を進められています。具体的には、発見的統制(権限はシステム開発箇所に付与しつつ、リスクのある設定・操作を検知して通知する統制)を導入することで、セキュリティを担保した形でのシステム開発者への権限付与を実現されています。セキュリティリスクに至る可能性のある設定・操作を AWS Config   で検知し、 AWS Security Hub   と 連携することで担当者への通知を実現し、セキュリティリスクを即座に発見・対処する仕組みを構築しました。そのほかにも AWS Service Catalog   を利用して事前に定義した環境を払い出すことでセキュリティリスクを低減しながらアジリティの向上を実現しています。このような運用変更により、従来であれば 10 営業日以上の申請待ち時間が生じていた作業について、システム開発箇所で完結可能となり、アジリティ向上を実現されています。 IoT/AIを活用した O&M 業務改善の取り組み -Global Data Analyzing Center – –  島添 道裕 様 株式会社JERA O&M・エンジニアリング戦略統括部 G-DAC モニタリングユニット シニアマネージャー –  佐藤 正芳 様 株式会社JERA 情報セキュリティ室 マネージャー –  大澤 正紹 様 株式会社JERA デジタルクリエーション部デジタルトランスフォーメーションユニット マネージャー セッションでは、JERA 様の発電所データの連係の仕組みから Global Data Analyzing Center (以下、G-DAC) でのデータ高度活用についてお話いただきました。発電所という OT 領域のクラウド連係や高度なデータ活用はセキュリティの懸念から進みにくい分野ですが、積極的に推進されている状況は、同領域を検討する参加者にとって参考になったのではないでしょうか。 JERA 様は発電設備の運転実績/設備データを収集・分析する基盤である IoT Platform を構築し、システム・部門を超えたデータ統合と高度分析による意思決定のスピード化・事業全体の最適化を実現されています。しかし、発電所とのデータ連係において、制御システムを納入する OT ベンダーにクラウドへの連係部分のシステムも依存していたため、データとシステム設計を自社で完全にコントロールできていないことに課題がありました。そこで、 AWS Direct Connect による専用接続と AWS Site-to-Site VPN  による暗号化の併用に加えて、 AWS Gateway Load Balancer   の採用により 、国内電力会社向けセキュリティガイドラインに準拠しつつ、システム更新やデータマネジメントを自社でコントロール可能な構成を構築されました。これにより、自社主導の統一的なデータ収集・活用を実現されています。収集したデータは G-DAC により高度に活用されております。2023 年 9 月時点で、G-DAC は国内外 62 の発電ユニットと連携しており、「予兆管理」「性能管理/診断」「運転最適化」を 3 つの柱としてサービス提供されています。JERA 様が独自ノウハウを活用した予測モデルを構築するために、 Amazon SageMaker   を利用した AI/ML の内製化を実現されております。G-DAC により計画外設備停止時間の 10~20% 削減や年間 1 億円超の燃料費削減を実現しております。 AWS IoT を活用した業務用分野におけるエネルギーマネジメントシステムの開発 –  國奥 広伸 様 北海道ガス株式会社 エネルギーシステム部 エネルギーシステムグループ 係長 セッションでは、北海道ガス様の事業部メンバーが主体となって構築したエネルギーマネジメントシステム (以下、EMS) について、PoC 検討からサービスリリースに至るまでの課題や内製化の取組みについてお話いただきました。AWS やIoT に知見のなかった事業部メンバーが、事業構想からサービスリリースまでを主体的に進めた貴重な事例です。 北海道ガス様は、分散型エネルギー社会の実現に向けて、分散型 EMS の導入促進に取組まれています。2023 年 6 月には、お客さまの設備変更や高額な投資を必要とせず導入できる省エネソリューション「 Mys³ (ミース)」をリリースされました。 Mys³  の事業検討は 2018 年からスタートしており、レガシー設備の IoT 化による季節や負荷に合わせた柔軟な運用にニーズがあるとの構想がありました。しかし、事業立ち上げ時から大きな初期投資ができず、AWS やIoT に知見がない事業部の 3 名が中心となり、PoC を開始されました。プロトタイプ構築に必要な知見を補うために、部署や部門を超えたコミュニティ活動を通じてボトムアップ的に知識を習得されました。コスト削減のため、AWS のサーバレス/マネージドサービスを活用する方針で検討を進め、 AWS IoT Core 、 AWS Lambda 、 Amazon QuickSight   を利用した IoT データ可視化のプロトタイプを 5ヶ月、30 万円で構築されました。PoC 後は、コストダウンに加え、セキュリティとアジリティの改善に取組まれました。セキュリティについては AWS の Well-Architected Framework IoT Lens Checklist を利用して改善し、アジリティについては Amazon CodeCatalyst による CI/CD パイプラインの構築により、環境構築やテストの工数の削減を実現されました。このような取組みにより、当初の事業部メンバー中心のまま Mys³ リリースを実現されました。 メンバー熱意と積極的に社員に任せる組織文化がサービスリリースにつながった好例だと感じました。 関西電力送配電の次世代スマートメーターシステムにおけるAWSクラウド活用 –  児山 一郎 様 関西電力送配電株式会社 情報技術部 設備業務システムグループ マネジャー セッションでは、関西電力送配電様にて推進されている AWS クラウドを活用したスマートメーターシステム開発の取組みについてご紹介いただきました。より詳細な内容を公開しておりますので、下記ブログをご確認ください。 ・関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介 (前半)   ・関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介 (後半)   クロージングセッション ～ AWSからのご支援 ～ –  丹羽 勝久 アマゾン ウェブ サービス ジャパン合同会社 エンタープライズソリューション本部 ユーティリティソリューション部 ソリューションアーキテクト クロージングセッションでは、AWS の提供するご支援プログラムについてご説明しました。AWS はお客様の企画・構想段階から検証、実現までの全てのフローにおいてご支援可能なメニューを用意しております。セッションでは、複数のプログラムセットの中から DIP (Digital Innovation Program) によるイノベーション創出支援、プロトタイピングによるお客様と共同した AWS 環境の構築支援のプログラムについてご説明しました。また、クラウド標準環境構築・ガイドライン作成などをご支援可能な有償コンサルティングサービスである AWS Professional Services  についてもご紹介しました。ご興味あれば担当営業までご連絡ください。 おわりに 日本のエネルギー産業は 5D (Digitalization、De-carbonization、De-centralization、De-population、Deregulation) と呼ばれる大きな変化の波にさらされています。今回の Forum を通じて、その多くの変化が「デジタル」に関係してきている事を実感しました。ご登壇いただいたお客様は、エネルギー業界で先進的に AWS を活されております。セッションでは、検討の背景から実現までのプロセスをお話をいただいたことで、参加者の方々がクラウド活用を進める上で必要な具体的な方針をイメージできたのではないでしょうか。今後も、先進的な取組みを発信されたいお客様にイベント登壇いただき、これから取組みを進める皆様への参考としていただけるように活動を続けて参ります。 著者プロフィール 林 隆太郎  (Ryutaro Hayashi) 大手ガス会社にてガススマートメーター、電力トレーディングのシステム開発を経験した後、総合商社にて全社の IT/DX 推進と国内外のエネルギー領域での事業投資、新規事業開発を担当。現在は AWS 電力・ガス業界のソリューションアーキテクトとして業界知識を活かした AWS 活用に携わる。

この記事は、Adrian Hornsby (プリンシパル システム デベロッパー エンジニア) と Marcia Villalba (プリンシパル デベロッパー アドボケイト) が執筆しています。 AWS Lambda は 80 を超えるサービスで構成され、連携し、お客様へサーバーレスコンピューティングサービスを提供しています。 内部的には 、これらのサービスの多くは、アベイラビリティーゾーン内でプロビジョニングされた Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上に構築されています。ただし、 AWS Lambda はリージョンサービスです。つまり、顧客はリージョンレベルで Lambda を使用でき、その基盤であるアベイラビリティーゾーンで起きる可能性のある障害に対してレジリエントであるように設計されていることを意味します。 このブログ記事では、Lambda などのリージョンサービスがアベイラビリティーゾーンと静的安定性を活用して  高可用性の目標 を達成する方法について説明し、Lambda チームが AWS Fault Injection Simulator (AWS FIS) を使用してサービスの静的安定性を検証する方法についても説明します。また、FIS、 Amazon CloudWatch 、 Amazon Route 53 Application Recovery Controller (Route 53 ARC) のような AWS のサービスとツールを使用して、Lambda のレジリエンス戦略を実現するソリューションも提供しています。 アベイラビリティーゾーンの役割 アベイラビリティーゾーンは AWS リージョンの物理的に分離された区画で、動作においても障害の発生においても互いに独立するように設計されています。相互に関連する障害を防ぐため、相互に最大 100 km (60マイル) 程度の十分な距離を置いて離れていますが、1 桁ミリ秒の遅延で同期レプリケーションを使用できるほど近い距離にあります。 お客様と AWS サービスは長年にわたりアベイラビリティーゾーンを使用して、可用性が高く、耐障害性があり、スケーラブルなアプリケーションを構築してきました。特に、AWS Lambda、 Amazon DynamoDB 、 Amazon Simple Queue Service (Amazon SQS) 、 Amazon Simple Storage Service (Amazon S3) などの AWS リージョンサービスは、サービスの複数の独立したレプリカを複数のアベイラビリティーゾーンに分散させることで、高い可用性を実現しています。アベイラビリティーゾーンの独立性と冗長性の原則を使用して、そのサービスの全体的な可用性を最大化します。 各レプリカはゾーンレプリカと呼ばれます。この仕組みは、どのレプリカでもいつでも障害が発生する可能性を考慮して設計されています。レプリカに障害が発生した場合は、すべてが再び期待どおりに動作するまで、そのレプリカをシステムから一時的に削除できます。その場合、負荷は残りのゾーンレプリカ間で分散されます。 障害を想定した設計 AWS でサービスを構築する際に学んだ教訓の 1 つ  は、アベイラビリティーゾーンに障害が発生した場合、 コントロールプレーンの操作  による復旧に頼らない方が良いということです。例えば、コントロールプレーンの操作とは、障害の影響を受けないアベイラビリティーゾーンでより多くの容量をプロビジョニングすることです。 この原則は静的安定性と呼ばれ、システムが破壊的なイベントにさらされた場合でも、何も変更せずに元の定常状態 (または動作) を維持できることを表しています。静的に安定したサービスは、復旧プロセスにおける依存関係が少なくなります。 これは、AWS Lambda のようなリージョンサービスの場合、正常なアベイラビリティーゾーンの残りの容量が、障害の可能性があるアベイラビリティーゾーンからのトラフィックをスケールアップすることなく吸収できることを意味します。これは、すべてのアベイラビリティーゾーンでリソースを過剰にプロビジョニングすることを意味します。その余分な容量を事前にプロビジョニングしておくと、Lambda は静的安定性を実現できます。これは、リソースを過剰にプロビジョニングするコストと、サービスの可用性の間のトレードオフです。AWS Lambda はお客様に高い可用性を約束し、 月間稼働率  を 99.95% とすることを約束しているため、そのトレードオフではサービスの可用性を優先しています。 障害に備える方法 アベイラビリティーゾーンの障害に備えることは困難です。なぜなら、問題の事象や規模は大きく変わる可能性があるからです。アベイラビリティーゾーンには、部分的にアクセス可能な場合もあれば、まったくアクセスできない場合もあります。障害の原因には、ファイバー切断、電源の問題、過熱、ハードウェアの誤動作、ネットワークの問題、容量の問題、およびその他の予期しない状況などがあります。そのような状況は起こりますが、めったに起こりません。障害の最も一般的な種類は、不適切なデプロイや不適切な設定です。 これらの障害の中には、推測や再現が難しいものもありますが、一般的な症状としては、接続の中断、遅延の増加、急増するリトライによるトラフィックの増加、CPU とメモリの使用量の増加、I/O の低下などがあります。 AWS では、予期せぬ事態を想定し、障害に備えることを学びました。つまり、システムに障害を注入してアベイラビリティーゾーンの障害の一般的な症状を再現し、システムがどのように反応するかを観察し、改善を実施することになります。さらに、システムに障害を注入することで、モニタリングやアラートにおける潜在的な盲点を明らかにすることができ、チームが復旧までの時間を短縮することに重点を置いて、イベントへの対応を練習して改善する機会にもなります。 Lambda がアベイラビリティーゾーンの障害への対応をテストする方法 アベイラビリティーゾーンの障害に対するレジリエンスを高めるための Lambda のアプローチは、静的安定性と自動化されたシステムに頼ることです。人間は機械よりも問題の検出と軽減に時間がかかります。そのため、Lambda では、サービスがゾーンレプリカ内の問題を検出し、オペレーターの介入なしに数分以内に自動的に修正できるようにする必要があります。この自動修復は、顧客のトラフィックを、影響を受けるアベイラビリティーゾーンから正常なアベイラビリティーゾーンに移すことで行われ、アベイラビリティーゾーン退避と呼ばれます。 そのために、Lambda は障害を検出し、必要に応じてアベイラビリティーゾーンの退避を実行するツールを構築しました。このツールは、さまざまなアベイラビリティーゾーンと EC2 インスタンス間のメトリクスを統計的に比較して、異常のあるアベイラビリティーゾーンを特定します。アベイラビリティーゾーンに問題があることが判明した場合、ツールは異常のあるアベイラビリティーゾーンからの退避を自動的に開始します。この自動化により、最初のアクションまでの時間が 30 分から 3 分未満に短縮されます。 AWS Lambda が AWS FIS を使用する方法 自動化が期待通りに継続的に機能することを確認するために、Lambda では実稼働前の環境でのアベイラビリティーゾーンの障害テストなど、さまざまなテストを実施しています。これらのテストの主な目的は、アベイラビリティーゾーンに障害が発生してもサービスが静的に安定していることを確認し、アベイラビリティーゾーンからの退避を正常に開始できることを確認することです。自動テストの利点は、チームが定期的にテストを繰り返すことができるため、特別なスキルがなくても済むことです。ワンクリックでテストを開始できます。 これらのテストでは、Lambda は AWS FIS を使用して大規模な EC2 インスタンス群に障害を発生させます。AWS FIS を使用して、 AWS System Manager (SSM) エージェントとリソースフィルターとの連携により、特定のアベイラビリティーゾーンにある EC2 インスタンス群をターゲットにします。これは、CPU やメモリの枯渇などのリソース障害や、パケット遅延、損失、ドロップなどのネットワーク障害を挿入できる汎用性の高いアプローチです。 これらの症状はアプリケーションやネットワークのパフォーマンスに重大な影響を与える可能性があるため、パケット損失や遅延を発生させることは非常に重要です。実際、レイテンシーと損失は、たとえ少量であっても非効率性を生み出し、アプリケーションを最高のパフォーマンスで実行できなくなる可能性があります。Lambda にとって、レイテンシーの増加や損失が顧客に影響を与える前に検出できることは非常に重要です。 アベイラビリティーゾーンの障害からアプリケーションを迅速に復旧する方法 Lambda と同様のソリューションを構築して、ゾーン障害からアプリケーションを迅速に回復できます。ソリューションには、障害が発生したアベイラビリティーゾーンから退避させるメカニズム、ゾーンレプリカに障害が発生したことを検出できる監視システム、およびシステムの静的安定性をテストする方法が必要です。AWS は、このソリューションを構築して Lambda のレジリエンス戦略を実現するのに役立つ多くのツールとサービスを提供しています。 アベイラビリティーゾーン退避には、Route 53 ARC の新しい ゾーンシフト機能 を使用できます。ゾーンシフトにより、 Elastic Load Balancing を使用するアプリケーションをアベイラビリティーゾーンから退避させることができます。ゾーンレプリカに障害があるか、異常があることが分かった場合は、問題が修正されるまでの間、ゾーンシフトを使用してアベイラビリティーゾーンから一定期間退避できます。 ゾーンシフトを実行するには、ゾーンレプリカが正常でないことを検出する必要があります。アプリケーションは、アベイラビリティーゾーンごとにヘルスシグナルを提供する必要があります。この信号をキャプチャする一般的な方法は 2 つあります。まず、レスポンスタイムや HTTP ステータスコードなど、アプリケーションの致命的なエラーの追跡に役立つメトリクスを受信してチェックできます。または、能動的にシンセティックモニタリングを使用することもできます。これにより、本番アプリケーションに対して合成リクエストを作成し、顧客体験をより包括的に把握できます。 Amazon CloudWatch Synthetics  にはカナリアが用意されています。カナリアはスケジュールに従って実行され、アプリケーションのエンドポイントと API に対して合成リクエストを実行するスクリプトです。カナリアは顧客と同じ行動をとり、顧客体験を継続的に検証します。アプリケーションのゾーンレプリカごとにカナリアを作成し、結果を個別に監視できます。 この情報があれば、いずれかのレプリカで顧客体験が低下した場合でも、ゾーンシフトを使用してアベイラビリティーゾーン退避を開始し、障害の原因を見つけて修正する間、ユーザーへの悪影響を最小限に抑えることができます。 障害から正常に回復できるようにするには、事前にソリューションをテストする必要があります。テストなしでは、これは単なる仮説に過ぎません。アベイラビリティーゾーン内の問題などの破壊的イベントを処理するシステムの能力に関する仮説を証明または反証するには、FIS を使用できます。 FIS を使用すると、アベイラビリティーゾーンなど、同じ障害ドメイン内の複数のリソースに同時に障害を注入できます。FISは現在、EC2、 Amazon Elastic Kubernetes Service (Amazon EKS) 、  Amazon Elastic Container Service (Amazon ECS )、  Amazon Relational Database Service (Amazon RDS) 、AWSネットワーク、CloudWatchなど、いくつかのAWSサービスと統合されています。 アベイラビリティーゾーンの障害に対するワークロードの耐障害性をテストする一般的な使用例としては、特定のアベイラビリティーゾーン内のすべてのコンピューティングリソースとデータベースを停止する、レイテンシーまたはパケットロスを発生させる、特定のアベイラビリティーゾーンのコンピュートリソースのリソース消費量 (CPU、メモリ、I/O) を増やす、アベイラビリティーゾーン内またはアベイラビリティーゾーン間のネットワーク通信に影響を与えるなどがあります。 単一のアベイラビリティーゾーンでアプリケーション障害から迅速に復旧し、AWS FIS でテストする方法の詳細とステップバイステップの例については、 このブログ記事 をお読みください。 結論 本記事では、静的安定性について解説しました。静的安定性は、Lambda などの AWS サービスがレジリエントなリージョンサービスを構築するために使用するメカニズムです。また、AWS が顧客と同じサービスとインフラストラクチャをどのように活用しているかについても解説しました。Lambda が複数のアベイラビリティーゾーンと AWS FIS などのサービスを使用して可用性の高いサービスを構築し、予期しない障害からの復旧時間を人間の介入なしにわずか数分に短縮する方法を示しました。最後に、お客様のアプリケーションで、Lambda のレジリエンス戦略と同等の内容を実現するためのアプリケーション例も示しました。 AWS FIS の詳細については、 多数のチュートリアル と ワークショップ  をご覧ください。 その他のサーバーレス学習リソースについては、  Serverless Land をご覧ください。 翻訳はソリューションアーキテクトの松本が担当しました。原文は こちら です。

教育業界は、ここ数年で革新的な技術変化を遂げました。まず、パンデミックにより e ラーニングソリューションが増加しました。教師と生徒がコミュニケーション、教育、学習、および学術情報の管理にデジタルプラットフォームを採用したためです。これらのソリューションは、世界中の生徒たちがインターネットを通じて質の高い教育を受けることができることを表しています。デジタルプラットフォームの使いやすさとアクセスの容易さにより、教師と生徒の考え方が変化し、オフラインの授業とともにオンライン学習を引き続き活用するようになりました。 さらに最近では、人工知能（AI）の分野におけるイノベーション、つまり生成系 AI が、教育者や教育技術企業（EdTech）に対し、このテクノロジーがどのように生徒の成功を促進し、教職員の生産性を向上させるかといったことを再考する新たな機会をもたらしています。 このブログ記事では、自動化・個別最適化された教育用ツールを用いて生徒の体験を支援する目的で、 Amazon Web Services (AWS) で録画済みの授業動画を使った複数の生成系 AI ソリューションの作り方を学べます。例としては、動画からテキストへの文字起こし、授業の要約や宿題・問題の生成、教材の地域ごとの言語への翻訳、問題解決のために個別最適化された授業用チャットボットの作成などがあります。 ソリューションの概要: 授業コンテンツを用いた教育向け生成系 AI ソリューションの構築 Amazon Interactive Video Service ( Amazon IVS ) などのライブストリーミングビデオサービスを使用すると、教師はリモートの生徒と教室での授業をリアルタイムで共有できます。ライブストリーミングを使えば、遠隔地の生徒は、対面での環境と同じように質問をしたり、教師とやり取りしたりできます。その後、教育者はストリーミングされた授業内容 を録画してテキストに変換することができ、こうした文字起こしは、生成系 AI ソリューションにおいてさまざまな用途で利用可能です。 このブログ記事では、 AWS 上の AI サービス を使ったハイレベルのソリューションアーキテクチャと、事前トレーニング済みの大規模言語モデル (LLM) について説明します。こうしたモデルは、Amazon や主要な AI スタートアップが開発した基盤モデル (FM) を API 経由で利用できるフルマネージドサービスの Amazon Bedrock や、機械学習 (ML) への取り組みを加速させるのに役立つ ML ハブである Amazon SageMaker JumpStart から利用可能です。 ソリューションの基礎: 授業のストリーミング、録画、文字起こし 教師や生徒を支援する上で AI ソリューションが授業内容を扱えるようにするために、その内容を録画し文字起こしをする必要があります。Amazon IVS を使用すると、教師は実際の教室から授業を行い、その授業をリモートで同時に視聴可能にできます。 Amazon IVS はフルマネージドのライブストリーミングソリューションです。コンテンツを Amazon IVS にストリーミングするだけで、世界中のあらゆる視聴者が低遅延のライブ動画を閲覧できるようになります。Amazon IVS は、 Twitch と同じテクノロジーを使用して、ライブコンテンツの取り込み、トランスコーディング、パッケージ化、配信を行います。 ライブビデオを Amazon Simple Storage Service ( Amazon S3 ) バケットに保存するように Amazon IVS を設定できます。ビデオストリームはビデオファイルとして保存され、Amazon Transcribe に送信することで音声をテキストに変換できます。 Amazon Transcribe では授業の音声や動画を、授業中リアルタイムにあるいは授業後にまとめて、テキストに変換できます。 その後、授業の文字起こしも Amazon S3 に保存でき、それを Amazon Bedrock や Amazon SageMaker JumpStart を使用するさまざまな生成系 AI のユースケースに利用できます。 さらに、生徒の宿題のような他のテキストベースのコンテンツも Amazon S3 に保存し、授業の文字起こしと一緒に使用することで、より生徒にとってパーソナライズされた体験を構築できます。 図 1.このブログ記事の基礎となるソリューションのアーキテクチャ図。まず、教育者は Amazon IVS を使用してコンテンツをストリーミングおよび録画し、生徒がリモートで視聴できるようにします。その後、録画した授業ビデオが Amazon Transcribe で処理され、ビデオ内の音声が自動的にテキストに変換されます。次に、Amazon Transcribe は 文字起こしを Amazon S3 バケットにアップロードします。Amazon Bedrock や Amazon SageMaker などの AI サービスでは、文字起こしを様々な目的で活用できます。例えば、SMS、電子メール、ソーシャルメディアを通じて学習者にメッセージを送信するコンテンツの生成、授業の概要の生成、授業教材に基づいて生徒の質問に回答できるパーソナライズされたチャットボットの作成、関連画像の生成、生徒の評価などが可能です。Amazon Translate では、Amazon S3 から取得した文字起こしを地域ごとの言語に翻訳できます。また Amazon Kendra を使えば、生徒が授業コンテンツを効果的に検索して利用する検索ソリューションを作成できます。 授業の要約と検索可能な授業内容インデックスの生成 一度授業の文字起こしを行えば、教育者は授業の要約生成ソリューションを構築できます。生徒は授業の要約を短時間で読むことができ、授業を通して教わる重要な概念を学べます。 図 2 は、AWS におけるこのモデルのハイレベルなアーキテクチャの構築方法を示しています。AI ソリューションでは、 Amazon Bedrock や Amazon SageMaker JumpStart で利用可能なテキスト要約ができるさまざまなモデルを使用して、授業内容全体をほんの数段落に要約します。要約されたテキストは、深層学習により人間の自然な音声を合成できるサービスである Amazon Polly を使用して音声に変換され、生徒は授業の要約を聞くこともできます。コンテンツをさまざまな地域の生徒にローカライズするために、元の文字起こしと要約のテキストを Amazon Translate で サポートしている言語 に翻訳できます。 教育者は、生徒が特定の授業コンテンツにすばやくアクセスできるように、録画した授業や文字起こし、要約を章立ててまとめることもできます。その後、教育者は ML を活用したインテリジェントな検索サービスである Amazon Kendra を使用して、授業内容の 検索可能なインデックスを作成 でき、生徒は自分が必要とする内容を検索できるようになります。Amazon Kendra で構築されたアプリケーションでは、生徒は自然言語で質問し、教材から非常に正確な回答を得ることができます。たとえば、化学の授業を受講している生徒が、Amazon Kendra に保存されている授業内容を検索して、「酸とは何か？」といった質問をすることができます。Amazon Kendra は授業の文字起こしから利用可能なコンテンツを取得します。統合された大規模言語モデル (LLM) は内容を要約し、自然言語として回答を示します。 図 2. 授業の文字起こしから授業の要約を生成するアーキテクチャ図。文字起こしが Amazon S3 バケットにアップロードされると、Amazon Bedrock または Amazon SageMaker JumpStart が事前に訓練されたモデルを使用して、文字起こしされたコンテンツを要約します。この要約されたコンテンツを、Amazon Translate に送信すれば複数の言語に翻訳できたり、Amazon Polly に送信すれば要約を音声に変換できたりします。 また Amazon Kendra に送信すれば、すべての授業内容をインテリジェントに検索できるインデックスを作成できます。 問題や学習資料の作成 教師は、文字起こしした授業内容に生成系 AI を用いることで、特定の授業や授業に基づいた問題と解答の組み合わせを素早く生成できます。教育者はこれらの問題を使って、宿題やフラッシュカード、小テスト、試験問題の準備を行えます。 Amazon Bedrock と Amazon SageMaker JumpStart で利用できるテキスト生成モデルでは、文字起こしした授業内容からこのタイプの教材を生成できます。その後、Amazon Kendra を使って、こうした評価や学習のための教材をインデックス化し検索できるようにできます。 図 3. 問題生成のアーキテクチャ図。主要なコンポーネントは Amazon Bedrock や Amazon SageMaker JumpStart です。 パーソナライズされた授業用チャットボットを作成して、教材に関する質問に回答する 授業の文脈における生徒からの質問に自動的に回答できるチャットボットを作成できれば、生徒の体験向上につながります。図 4 は、このソリューションを AWS で設計する方法を表したハイレベルなアーキテクチャを示しています。 Amazon Lex は、高度な自然言語モデルを備えたフルマネージド AI サービスで、アプリケーション (チャットボットなど) の会話型インターフェイスを設計、構築、テスト、デプロイできます。その後、生徒は音声またはテキストでこのチャットボットとやり取りできます。 生徒が授業用チャットボットに授業に関する質問をすると、Amazon Lex は Amazon Kendra から回答を取得します。Amazon Kendra はテキスト生成 LLM にコンテキストを与え、自然言語でレスポンスが返されます。その後、Amazon Lex はこのレスポンスをユーザーに返します。外部のデータベースからコンテキスト情報を取得して LLM の知識を拡張するこのプロセスは、検索拡張生成（RAG）と呼ばれます。Amazon Lex が、 Amazon Kendra インデックス用の LangChain リトリーバー を用いるような AWS Lambda 関数を呼び出すことで、RAG ワークフローを実装してます。ここで LangChain は、LLM を外部の情報源と統合できるようにするフレームワークです。 さらに、授業の音声やビデオの中で特定の概念が説明されている正確な時間を提供することでも生徒の学習体験はより良くなります。GitHub で利用可能な MediaSearch ソリューション を使用すると、Amazon Kendra 内でオーディオコンテンツとビデオコンテンツを検索できるようになります。 図 4. Amazon Kendra でインデックス化された質問および回答を使用した、自動で疑問を解決するソリューションのアーキテクチャ図。主なコンポーネントは、Amazon Bedrock あるいは Amazon SageMaker JumpStart、また、Amazon Kendra と Amazon Lexです。 生徒の試験などの自動採点 AI ソリューションは生徒の試験を採点するのにも役立ちます。これにより、教師は日々の採点に費やす時間を減らし、複雑なトピックや生徒への個人的な指導に専念できます。さらに、生徒は自分の解答に対して即座にフィードバックを得ることができるため、授業の理解と進度が早まります。 図 5 は、このソリューションのハイレベルなアーキテクチャの例を示しています。試験の解答を確認するために、生徒の解答と、 Amazon DynamoDB などのデータベースから取得した正解として期待される解答がテキストプロンプトとしてテキスト生成の LLM に送信されます。 Amazon Bedrock や Amazon SageMaker JumpStart で利用できる LLM に、生徒の解答と期待される解答を照らし合わせてチェックするよう依頼します。このアーキテクチャを基礎とすることで、生徒が自身の解答が正しいのか、部分的に正しいのか、あるいは間違えているのかを説明付きですばやく判断できるようなシステムを設計できます。また、このアーキテクチャは、教師が生徒たちの解答を最初にまとめて自動採点できるようにも拡張可能です。 図 5. 生徒の解答採点のアーキテクチャ図。主なコンポーネントは Amazon Bedrock や Amazon SageMaker JumpStart 、Amazon Lex です。 画像を生成して情報をより明確で説得力のあるものにする 画像生成モデルを使用すると、教師は自分の持つイメージを魅力的な絵に変え、ストーリーを語るように概念を説明できます。たとえば、拡散モデルを使用して授業の文字起こしからイラストを生成し、概念を明確にする、あるいは単にコンテンツをより楽しく魅力的なものにすることができます。元となるテキストに加えて、サンプルイメージも組み合わせることで stability.ai の Stable Diffusion モデルを使い目的通りの画像を生成できます。これらのモデルは Amazon Bedrock や Amazon SageMaker JumpStart ですぐに利用可能です。 図 6. 画像生成のアーキテクチャ図。主なコンポーネントは Amazon Bedrock や Amazon SageMaker JumpStart です。 まとめ 授業の要約、採点、生徒の質疑への回答（Q&A）、テキストや画像の生成は、教育者にとって時間を要する作業です。AWS で利用できる AI ソリューションでは、新しい生成系 AI の機能を使ってこれらのタスクをシンプルに実行できます。そして教育者は面倒な作業に割く時間を減らし、生徒の体験を豊かにすることにもっと集中できます。 AWS における生成系 AI 使用に関する詳細については、「 AWS で生成系 AI を使用した構築のための新ツールを発表 」を参照してください。 Sarat Guttikonda Sarat Guttikonda は、Amazon Web Services (AWS) のグローバルな公共部門のプリンシパルソリューションアーキテクトです。Sarat は人工知能 (AI) と機械学習 (ML) の愛好家であり、ビジネスの俊敏性を犠牲にすることなく、お客様のイノベーションと変革を推進したいと考えています。余暇には、息子と一緒にレゴを作ったり、卓球をしたりするのが大好きです。 Paul Saxman Paul Saxman は、クラウドでの次世代の計算とストレージの運用において、世界中の教育機関や学術研究機関を支援するグローバルな技術プログラムを率先して主導しています。生物医学と臨床情報学の研究とシステム開発における以前のキャリアを経て、クラウドと AI/ML テクノロジーの運用を通じて科学と教育を発展させることを目標に、Amazon Web Services (AWS) に入社しました。 本ブログはソリューションアーキテクトの田村健祐が翻訳しました。原文は こちら です。

この記事は、 Patterns for updating Amazon OpenSearch Service index settings and mappings を翻訳したものです。 Amazon OpenSearch Service は、リアルタイムのアプリケーションモニタリング、ログ分析、大規模なウェブサイト検索など、幅広いユースケースで利用されています。ドメインが古くなり、コンシューマが追加されると、追加のストレージとコンピュートニーズを処理するためにドメインの構成を再評価し、変更する必要があります。このような変更を行う際には、ダウンタイムとパフォーマンスへの影響を最小限に抑えたいものです。 インデックスのメンテナンスを行うためのウィンドウを設けずにインデックス設定を変更したり、OpenSearch Service ドメインの全体的なパフォーマンスに影響を与えることなくインデックス設定を変更するためのベスト・プラクティスとパターンに関するガイダンスをお客様から求められます。これは 2 部構成の第 1 部で、データのプロデューサおよびコンシューマがアクティブなまま、ダウンタイムをほとんど発生させずに OpenSearch Service のインデックスに設定変更を行う方法を紹介します。 OpenSearch Service におけるインデックス OpenSearch Service では、データを検索する前に インデックスを作成 する必要があります。インデックスとは、検索エンジンが高速に検索できるようにデータを整理する方法です。こうしてできた構造をインデックスと呼びます。インデックスに対して行われるすべての操作は、 インデックス APIs を介して行われます。また、各インデックスには インデックスマッピング が含まれており、インデックス内のフィールド名とデータ型を定義している。データ作成者はインデックスに新しいフィールドとデータ型を追加することができます。インデックスのマッピングは、インデックスのライフサイクルを通して変更することはできません。 OpenSearch Service のインデックスには 2 種類の設定があり、ワークロードの状態が変化すると定期的に調整が必要になります: 動的 – インデックス上でいつでも変更可能な設定 静的 – インデックスの作成時にのみ定義でき、インデックスのライフサイクルを通じて変更できない設定 動的インデックスの設定は、 設定更新 API を使用していつでも変更することができます。OpenSearch Service ドメインが動的インデックス設定に対して指示された操作を実行している間、インデックスはダウンタイムを必要としません。ほとんどの動的インデックス設定を変更しても、ドメインリソースの全体的な利用に影響を与えるバックグラウンドタスクは発生しません。しかし、 index.number_of_replicas や index.auto_expand_replicas によるレプリカ数の増加など、ドメインの設定によっては、ドメインがレプリカを追加している間、一時的にリソースの使用率が増加することがあります。冗長性のために少なくとも1つのレプリカを維持し、高いクエリスループットを使用する場合は複数のレプリカを維持することを推奨します。 マッピングやシャード数などの静的インデックス設定は、インデックス作成時に定義され、インデックスのライフサイクルを通じて変更することはできません。この投稿では、シャード数の変更やインデックスマッピングの更新パターンなど、静的インデックス設定を扱うためのパターンとベストプラクティスに焦点を当てます。 この投稿で取り上げるすべての操作と手順は、 OpenSearch REST API に直接、または OpenSearch Dashboards の Dev Tools を介して発行されます。 どのようなユースケースでもそうですが、考慮すべき解決策と制約のスペクトルがあります。私たちは、いくつかのシンプルな基本パターンから始めて、より多くの運用上の制約を持つユースケースや大規模なデータセットを扱うことを考慮しながら、それらを構築していきます。 ソリューション概要 OpenSearch Service のデフォルトのシャーディング戦略は 5:1 で、各インデックスは 5 つのプライマリシャードに分割されます。各インデックス内では、各プライマリシャードに対するレプリカも保持します。OpenSearch Service は自動的にプライマリシャードとレプリカシャードを別々のデータノードに割り当てます。 既存インデックスのプライマリシャード数を増やすことはできません。つまり、プライマリシャード数を増やしたい場合はインデックスを再作成する必要があります。 _reindex 操作は、シャードと マッピング設定 を更新して目的とするインデックスを作成するのに適しています。 _reindex 操作はリソースを消費します。 number_of_replicas を 0 に設定してインデックスのレプリカを無効にし、再インデックス処理が完了したらレプリカを再度有効にすることをお勧めします。もし S3 など他のデータストアにデータがある場合、更新を一時停止し、ソースからインデックスを再作成するのが最もシンプルな方法です。しかし、それは常に可能というわけではありません。この投稿では、シャード数のような静的なインデックス設定も更新できるようにするいくつかの方法を紹介します。 _reindex 操作を使用する主な利点の1つは、ソースインデックスを読み取り専用モードにする必要がないことです。（データプロデューサは、再インデックス中もデータを書き込みを続けることができます）また、 _reindex 操作は、部分的なドキュメントの再処理、 変換 、再インデックス、さらには複数のインデックスからのドキュメントの選択的な結合を可能にします。 _reindex 操作では、クエリで選択したドキュメントのすべてまたは一部を別のインデックスにコピーすることができます。 最も基本的な形式では、 _reindex 操作は、コピー元とコピー先のインデックス、および設定パラメータを指定する必要があります。 以下は、reindex API がサポートするユースケースの一部です: すべてのドキュメントの再インデックス クラスタ間でデータを転送する際にリモートクラスタからの再インデックス 検索クエリにマッチする一部のドキュメントの再インデックス 1つ以上のインデックスを結合 再インデックス作成中の文書の変換 シャード数を増やすには、新しいインデックスを作成し、 number_of_shards を希望のプライマリシャード数に設定し、 number_of_replicas を0に設定し、要件に基づいて新しいインデックス・マッピングを更新し、reindex API 操作を実行します。 _reindex 操作が完了したら、作成したインデックスの設定の number_of_replicas を必要なレプリカシャード数に更新することをお勧めします。 下のセクションでは、reindex API 操作のウォークスルーを提供する。この投稿で紹介するパターンと手順は Amazon OpenSearch Service バージョン 1.3 で検証されていることに注意してください。 前提条件 _reindex 操作はソースドキュメントなしでは使用できないため、インデックス作成時に渡されたドキュメントがインデックスに格納されている必要があります。（マッピングの "_source" 設定が "enabled":true （デフォルト）に設定されている必要があります。） 目的のマッピング（フィールドやデータ型）で出力先インデックスを作成します。デモンストレーションのために、ソースインデックスには ratings という long として定義されたフィールドがあり、同じフィールドがディスティネーションインデックスでは float データ型を使用するようにします : GET /source_index_name/mappings { "source_index_name": { "mappings" : { "properties" : { "ratings " : { "type" : "long" }, … } } } } PUT /destination_index_name { "settings": { "index": { "number_of_shards": <DESIRED_NUMBER_OF_PRIMARY_SHARDS>, "number_of_replicas": 0 } }, "mappings": { "properties" : { "ratings" : { "type" : "float" }, … } } } 各 Hot 層のデータノードに、新しいインデックスのプライマリシャードと、構成によってはレプリカシャードを格納するのに十分なディスク容量があることを確認します。ディスク容量が不足している場合は、OpenSearch Service ドメインで 更新操作 を行い、必要なストレージ容量を追加します。 ストレージ要件 によっては、OpenSearch Service ドメインを別のインスタンスタイプに移行する必要があるかもしれません。ノードには、各インスタンスタイプにマウントできる EBS ボリュームサイズ に制約があるからです。次の操作を実行して、使用可能なディスク容量を確認します : GET _cat/allocation?v 次のスクリーンショットは出力を示しています。 ホットストレージ層のノードの disk.avail メトリクスをチェックし、使用可能なディスク容量を確認します。 reindex API 操作の利用 _reindex オペレーションは、実行開始時にインデックスをスナップショットし、スナップショットに対して処理を実行することで、ソースインデックスへの影響を最小限に抑えます。ソースインデックスは引き続きデータの問い合わせや処理に使用できます。_reindex 処理は同期でも非同期でも実行できますが、非同期での実行を推奨します。 _task 、 _cancel 、 _rethrottle 操作をそれぞれ使用することで、 _reindex 操作の進捗を監視したり、実行をキャンセルしたり、実行を絞ったりすることができます。 _reindex 操作は、読み取り専用モードのソースインデックスを必要としないので、クエリとインデックス更新操作は自由に続けることができます。 以下のコマンドで reindex API を使用してください： POST _reindex?wait_for_completion=false { "source": { "index": "source_index_name" }, "dest": { "index": "destination_index_name", "op_type" : "index" } } _reindex API 操作の一部であるソースインデックスは、 ドキュメントの一部を再インデックス してインデックス先に格納するためのクエリで補足することができます。インデックス再作成処理の進行状況は、 tasks API 操作で確認することが監視することができます : GET _tasks _reindex 操作は、 _rethrottle APIまたはパラメータとして渡される設定によってスロットルできます。また、 _cancel 操作でタスクをキャンセルできます : POST _tasks/TASK_ID/_cancel 次のスクリーンショットは、 source_index_name から destination_index_name への再インデックスのための _reindex 操作の出力を示しています。 操作が完了すると、コンシューマとプロデューサが接続しているソースインデックス、もしくはエイリアスの向き先をディスティネーションインデックスに切り替える必要があり、最初の _reindex 操作が実行されている間にインデックス元で実行された作成、更新、または削除操作に追いつくために、同じ _reindex 操作を再度実行する必要があります。 _reindex 操作はインデックスのスナップショット上で実行されているため、このステップが必要です。この時点で、欠落しているドキュメントやバージョン外のドキュメントを再調整ために、 “op_type”:”create” で _reindex 操作を実行する必要があります。以下のAPIコマンドを参照してください : POST _reindex?wait_for_completion=false { "conflicts":"proceed", "source": { "index": "source_index_name" }, "dest": { "index": "destination_index_name", "op_type" : "create" } } 操作が完了し、インデックス先のデータ整合性が確認されたら、ソースインデックスを削除してディスク領域を取り戻すことができます。 Split index APIを使用してインデックスシャード数を増やす split index APIとshrink index APIは多くのユースケースをカバーし、ドメイン内のリソース使用率を低く抑えられます。しかし、これらのAPIは書き込み操作に対するインデックスを停止する必要があり、マッピング設定の変更を必要とするユースケースには対応していません。 OpenSearch Serviceでは、 number_of_shards インデックス設定は変更不可であり、インデックス作成時に定義されます。しかし、この設定は変更不可ですが、明示的にインデックスを作成し直さなくても、インデックスのシャード数を増減できるパターンがいくつかあります。書き込み操作を中断できる環境では、 split index API を使用してインデックスシャード数を増やすこともできます。split index API は、再インデックスをすることなく、異なるシャード設定で新しいインデックスを作成する簡便な方法を提供します。split index API は、読み込み専用インデックスをもとに新しいインデックスを作成します。 OpenSearch Service では、 index alias は1つ以上のインデックスを指す仮想的なインデックス名です。アプリケーションでエイリアスを使用してインデックスを参照すると、 インデックス名の変更を避けることができます。インデックスエイリアスは、インデックス API の分割操作が完了した後に、 コンシューマやプロデューサに新しいインデックスを指し示すために使用されます。 ユースケースの大半は、データの増加により既存のインデックスのシャード数を増やすことですが、 既存のインデックスのシャード数を減らす必要がある場合もあります。このようなケースは、実際のインデックスサイズがインデックス作成時に想定していたサイズよりも小さく、 OpenSearch Service の運用上のベストプラクティス における シャード戦略 に合わせたい場合に発生することがあります。インデックスのシャード数を減らす必要がある場合、 shrink index API を使用してこのタスクを達成することができます。 結論 この投稿では、OpenSearch Service の 静的インデックス設定 やマッピングを変更する際に、インデックスのダウンタイムをほとんど、あるいはまったく必要としないデータの 再インデックス のベストプラクティスについて検討しました。また、インデックスを読み取り専用状態にすることができるユースケースのために、プライマリインデックスのシャード数を変更するための split index および shrink index API の使用についても説明しました。 次回の投稿では、OpenSearch Service ドメインに対する負荷とリソースの使用を軽減するリモートインデックスのパターンを探ります。 翻訳は Solutions Architect 川岸が担当しました。

はじめに コンタクトセンターではエージェントのパフォーマンスを把握するために労力をかけています。これは、大量のインタラクションと、顧客とのコミュニケーションに使用されるさまざまなチャネルに起因しています。更に、パフォーマンス分析のために関連するデータポイントを抽出・収集する事は難しい作業です。幸い、 Amazon Connect Contact Lens には、評価フォームを使用したエージェントのパフォーマンス評価機能があります。コンタクトセンターのマネージャーは、トークスクリプトの遵守や機密データ収集の遵守などの特定の基準に基づき、評価フォームを作成します。Contact Lens の機械学習を活用した会話分析により、これらの評価フォームにスコアを付けて、エージェントのパフォーマンスを包括的に把握する事ができます。 更に、Contact Lens を使用すると、組織は 評価フォームの出力 データと コンタクトレコード （以前のコンタクト追跡レコード）をデータレイクにストリーミングできるため、高度な分析が可能になります。この分析手法により、マネージャーはエージェントのパフォーマンス傾向に関するインサイトを確認し、データドリブンな意思決定を行い、カスタマーサービスを向上させる事ができます。FrontDoor や Ameriflex のような当社のお客様では、品質保証の業務効率を向上させることで評価機能のメリットを享受しています。パートナーの Cognizant は、エージェントのパフォーマンスについてより多くのインサイトを取得し、トレーニングの機会を特定し、彼らのユーザー企業がコンタクトセンターの運用を強化できるように支援します。 このブログでは、Amazon Connect からコンタクトレコードをストリーミングする方法、評価フォームデータを処理する方法、それらのデータを関連付ける方法、そして、 Amazon QuickSight を使用して分析結果を視覚化する方法を学習します。これらの強力な機能を使用することで、カスタマーサービス業務を最適化し、カスタマーエクスペリエンスを向上させることができます。 概要 図1：ハイレベルなアーキテクチャー図 上記のアーキテクチャーにより、Amazon Kinesis Streams と Kinesis Data Firehose を使用した Amazon Connect Contact Center からのデータのリアルタイム処理が可能になり、AWS Glue Data Catalog、Amazon Athena、Amazon QuickSight を使用したデータのクエリと視覚化が可能になります。 Amazon Kinesis Streams は、Amazon Connect コンタクトレコード (CTR) を Amazon Simple Storage Service (S3) バケットに送信するために使用します。 コンタクトレコードからコンタクトセンターで発生するコンタクトのイベント情報を取得する事ができます。 Amazon Connect は、CTR を少なくとも 1 回配信する事を保証しています。また、最初に CTR が配信されてから新しいイベント情報が発生する場合は、同じコンタクトに対して追加の CTR を配信する場合があります。 Amazon Connect のパフォーマンス評価機能が有効になっている場合、評価が完了すると、評価フォームの出力ファイルが同じ S3 バケットに直接配信されます。 この出力ファイルの配信により Amazon EventBridge イベントがトリガーされ、Amazon Kinesis Data Firehose にイベント情報が送信されます。 Kinesis Data Firehose は、指定した間隔でこれらのイベントを収集し、 AWS Lambda を使用して S3 バケットから各ファイルのコンテンツを取得します。 Kinesis Data Firehose は、AWS Glue カタログで定義されたスキーマを使用して、これらのファイルから取得したレコードを Parquet ファイル に圧縮し、S3 バケットに保存します。 AWS Glue Data Catalog には、CTR と評価フォーム出力ファイルのテーブル定義があります。 Contact Id フィールドを使用してこれらを関連付けることができ、Amazon Athena を使用してクエリーを実行する事ができます。 Amazon QuickSight は視覚化の目的で使用されます。 前提条件 このブログ投稿で紹介されているソリューションを進めるには、次の AWS のサービスと機能について理解しておく必要があります。 Amazon Connect Amazon EventBridge AWS Lambda Amazon Simple Storage Service (S3) AWS CloudFormation Amazon Kinesis Amazon Athena AWS Glue AWS Identity and Access Management (IAM) Amazon Connect コンソールにて、 セキュリティプロファイル の[ 分析および最適化 ]セクションにある以下のアクセス権限を割り当てる事で、Amazon Connect のユーザーが評価フォームを作成、定義し、アクセスできるようになります。 評価フォーム – 評価の実行 評価フォーム – フォーム定義の管理 更に、 AWS Cloud Development Kit (CDK) データパイプラインをデプロイするには、以下の前提条件を満たす必要があります。 AWS アカウント Administrator 権限が割り当てられた AWS IAM ユーザー Contact Lens および 評価機能 が有効化された Amazon Connect インスタンス Node (v16) と NPM (v8.5) がインストール、設定された端末 AWS Command-Line Interface (CLI) (v2) がインストール、設定された端末 AWS CDK (v2) がインストール、設定された端末 本ブログシナリオのデプロイメントでは、6 つの S3 バケットが作成されます。 全てのスタータープロジェクトをデプロイするには 12 個の S3 バケットが必要となります。 ウォークスルー このウォークスルーは 2 つのパートから構成されています。 まず、CDK データパイプラインをデプロイします。 次に、CloudFormation Template(CFT) を使用してデプロイする事で、 Amazon QuickSight でダッシュボードを作成します。 データパイプラインをデプロイする データ分析のサンプルプロジェクトは、GitHub https://github.com/aws-samples/amazon-connect-data-analytics-sample から入手できます。 以下の手順は、AWS CDK CLI を使用してソリューションをデプロイする方法です。 Windows デバイスを使用している場合は、 Git Bash ターミナルを使用し、強調表示されている代替のコマンドを使用して下さい。 端末上にソリューションのクローンを作成します。: git clone https://github.com/aws-samples/amazon-connect-data-analytics-sample AWS CLI 設定を確認します。: AWS CDK は AWS CLI のローカル認証情報とリージョンを使用します。 aws configure で意図したリージョンで作業していることを確認してください。 NPM パッケージをインストールします。: ターミナル (Windows では Git Bash) を開き、 amazon-connect-data-analytics-sample/cdk-stacks に移動します。 npm run install:all を実行します。 CDK スタックを構成します。 ターミナル (Windows では Git Bash) で、 amazon-connect-data-analytics-sample/cdk-stacks に移動します。 このガイドでは、対話モード npm run configure で構成スクリプトを開始します。 このブログに必要な機能を有効にするには、 ctr-stack-enabled、ctr-partitioning-schedule-enabled、ef-stack-enabled、ef-partitioning-schedule-enabled、 および ef-reporting-stack-enabled を true に設定する必要があります。 プロンプトが表示されたら、次のパラメータを入力します。 aws-glue-database-name : Amazon Connect データ分析用のテーブルを保持する AWS Glue データベースの名称を入力します (デフォルトは AmazonConnectDataAnalyticsDB ) ctr-stack-enabled : コンタクト追跡レコード (CTR) スタックを展開するには true に設定します。 ctr-partitioning-schedule-enabled : Amazon EventBridge で CTR パーティショニング ジョブをスケジュールする場合は true に設定します。 ae-stack-enabled : エージェントイベント (AE) スタックをデプロイするには true に設定します。 ae-partitioning-schedule-enabled : Amazon EventBridge で AE パーティショニング ジョブをスケジュールする場合は true に設定します。 cfl-stack-enabled : コンタクトフローログ (CFL) スタックを展開するには true に設定します。 cfl-partitioning-schedule-enabled : Amazon EventBridge で CFL パーティショニング ジョブをスケジュールする場合は true に設定します。 connect-contact-flow-logs-cloudwatch-log-group : Amazon Connect のコンタクトフロー ログが保存される Amazon CloudWatch ロググループを設定します (例: /aws/connect/<your-instance-alias> ) cl-stack-enabled : コンタクト レンズ (CL) スタックを展開するには true に設定します。 connect-contact-lens-s3-bucket-name : Amazon Connect が Contact Lens の出力ファイル (および Amazon Connect 通話録音) を保存する S3 バケットの名称を設定します。 cl-partitioning-schedule-enabled : Amazon EventBridge で CL パーティショニング ジョブをスケジュールする場合は true に設定します。 ef-stack-enabled : true に設定すると、評価フォーム (EF)スタックがデプロイされます。 connect-evaluation-forms-s3-bucket-path : Amazon Connect が評価フォームの出力ファイルを保存する S3 バケット名とプレフィックス ( <your-bucket-name>/connect/<your-instance-alias>/ContactEvaluations )を設定します。 ※末尾のスラッシュは含めません。 ef-partitioning-schedule-enabled : Amazon EventBridge で EF パーティショニング ジョブをスケジュールする場合は、 true に設定します。 ef-reporting-stack-enabled : ビジュアライズを実施する場合は、 true に設定します。 これにより、Amazon 　QuickSight ダッシュボードがデータ ソースとして使用する Amazon Athena ビューがデプロイされます。 CDK スタックをデプロイします。 ターミナル (Windows 上の Git Bash) で、 amazon-connect-data-analytics-sample/cdk-stacks に移動します。 新しい環境で開始した場合は、 cdk bootstrap コマンドを使用して CDK をブートストラップします。 npm run cdk:deploy スクリプトを実行します。 Windows デバイスでは、 npm run cdk:deploy:gitbash を使用します。 コンソールコンフィグレーション: 希望するリージョンで   AWS マネジメント コンソール にサインインします。 Amazon Connect インスタンス の S3 バケット (Amazon Connect が Contact Lens 出力ファイルと通話録音を保存するバケット) に移動し、[ プロパティ ] タブを選択します。 [ Amazon EventBridge ] セクションで、[ 編集 ] ボタンを選択し、通知を オン に切り替えます。 Amazon Connect インスタンス にて、[ データ ストリーミング ] の設定を表示し、[ データ ストリーミングを有効化 ] にチェックを入れます。 コンタクトレコード(コンタクト追跡レコード)を取得するために、Kinesis ストリームのリストから CDK スタックによって作成された CTRKinesisStream を選択します。 Amazon Connect インスタンス にて、[ データ ストレージ ] 設定を表示し、[ Contact evaluation s] が有効になっている事を確認します。設定がSDKスタックで指定した[ connect-evaluation-forms-s3-bucket-path ]と一致している事を確認します。 サービスから Amazon Athena にて、メニューから クエリエディター を表示し、[ 設定 ] タブに移動し、[ クエリの結果と暗号化 ] で[ 管理 ]ボタンを押下し、[ クエリ結果の場所 -オプション ]に、バケット名 amazonconnectdataanalyticssample-ar-<account-id>-<region> を設定します。 注: バケット名の「al」は「アクセス ログ」を示すため[ amazonconnectdataanalyticssample-ar-al-<account-id>-<region> ]を選択しないでください。 Athena コンソールの クエリエディター に戻ります。 データベースを[ amazonconnectdataanalyticsdb ]に切り替え、[ ビュー ]セクションにて、各ビュー名の横に表示される3 つのドットをクリックします。 [ クエリを表示/編集 ] を選択し、[ 実行 ] ボタンを選択します。 次の順序でビューを実行します。 connect_ctr_denormalized connect_ef_evaluationquestionanswers_view connect_ef_evaluationsscores_view connect_ef_evaluationsall_view final_connect_ef_evaluationsall_view final_connect_evaluation_ctr_view 評価フォームダッシュボードをデプロイ 希望するリージョンで AWS マネジメント コンソールにサインインします。 Amazon QuickSight のアカウントを作成します (すでに QuickSight アカウントをお持ちの場合は、この手順をスキップしてください) コンソールから Amazon QuickSight サービスに移動します。 [ Sign up for QuickSight ] ボタンを選択します。 エディションを選択し、「 続行 」を選択します。 データパイプラインがデプロイされているのと 同じリージョン を選択します。 アカウント名 と 通知メールアドレス を入力します。 続いて、以下の手順の通り、 Amazon Athena Workgroup の書き込みアクセス許可を有効 にした形で、 Amazon Athena および Amazon S3 出力バケット (特に amazonconnectdataanalyticssample の一部としてデプロイされたすべてのバケット) への access and autodiscovery を許可し、[ 完了 ] を選択します。 注: すでに Amazon QuickSight アカウントをお持ちの場合は、以下の手順に従ってください。 Amazon QuickSight に移動し、右上隅のアイコンをクリックして、[ QuickSight を管理 ]を選択します。 [ セキュリティとアクセス権限 ]をクリックします。 [ QuickSight の AWS のサービスへの アクセス ] で、[ 管理 ]ボタン を選択します。 この CDK データレイク ソリューションによって作成された Amazon Athena と Amazon S3 バケットを選択し、各 S3 バケットおよび Amazon Athena Workgroup の書き込みアクセス許可にチェックを入れて [保存]します。 以下 [ スタックの起動 ] ボタンを押下して、評価フォーム分析ソリューションを希望のリージョンにデプロイします。: 一意の[ スタック名 ]を入力します。 パラメータ AwsGlueDatabaseName にはデフォルト値( AmazonConnectDataAnalyticsDB )を使用するか、データパイプラインのセットアップ中に別の Glue データベース名を選択した場合は一致するように更新して下さい。[ スタックの作成 ]を選択します。 CloudFormation スタックの作成が完了したら、QuickSight コンソールで ユーザーアイコン (右上) を選択してメニューを開き、[ QuickSight を管理 ] を選択します。 管理ページのメニューから、[ アセットの管理 ] > [ ダッシュボード ] の順に選択します。 <stack-name>-EvaluationFormAnalytics_v1 にチェックを入れて、[ 共有 ] を選択します。 必要に応じて、ダッシュボードをさらにカスタマイズするには、[ アセットの管理 ] > [ 分析 ]で <stack-name>-EvaluationFormAnalytics_v1 を共有し、[ アセットの管理 ] > [ データセット ]で <stack-name>-EvaluationFormAnalytics_v1 を共有します。 アセットを共有画面が表示されたら、 ユーザーまたはグループ を入力し、再度 [ 共有 ] を選択します。 テスト手順 リポジトリ から「 contact-flows/SimpleInboundFlow 」コンタクト フローをダウンロードします。 Amazon Connect のコンソールにログインし、「 ルーティング 」>「 フロー 」の順に移動します。 [ フローを作成 ] ボタンを選択します。 フロー デザイナーが表示されたら、画面右上にある下矢印▼を選択し、[ インポート ] を選択します。 SimpleInboundFlow を選択し、Amazon Connect インスタンスにインポートし、[ 公開 ] をします。 Amazon Connect コンソールにて、[ チャネル ] > [ 電話番号 ] の順に移動します。 テストで使用する電話番号に SimpleInboundFlow フローを関連付けます。 Amazon Connect コンソールにて、[ 分析と最適化 ] > [ Contact Lens ] > [ 評価フォー ム] の順に移動し、 評価フォーム を作成します。 詳細については、ドキュメント「 評価フォームの作成 」を参照してください。 Amazon Connect インスタンスにエージェントとしてサインインし、 コンタクトコントロール パネル (CCP) を開きます。 顧客として 電話番号 に電話します。 IVR の分岐メニューでいずれかを選択すると、エージェントにルーティングされます。 CCP で電話に応答し、コンタクトセンターにおける顧客とエージェントのやりとりを真似した短い会話を行ってください。 通話が終了したら、Amazon Connect のナビゲーション ウィンドウで、[ 分析と最適化 ] > [ コンタクトの検索 ] を選択し、先の手順で通話した評価対象のコンタクトを検索します。 [ コンタクト ID ] をクリックして、[ 評価 ] または [ < ] アイコンを選択します。 評価を開始するには、ドロップダウン メニューから評価を選択し、[ 評価の開始 ] を選択します。 評価フォームに記入し、「 送信 」をクリックします。 CTR と EF の両方の S3 の宛先バケットに Kinesis Data Firehose ファイルが作成されたことを確認します。 評価フォームのデータが宛先バケットに表示されるまでに最大 3 分かかる場合があります。 処理されたレコードは、宛先バケット amazonconnectdataanalyticssample-ef-<account-id>-<region> に書き込まれます。 amazonconnectdataanalyticssample-ef-al-<account-id>-<region> に追加の「al」が付いたものは、アクセス ログ バケットを示すことに注意してください。 Amazon Athena クエリエディター に移動します。 「 テーブル 」セクションで、 connect_ef の横にある 3 つのドットを選択し、「 パーティションのロード 」をクリックします。 Amazon Athena は MSCK REPAIR TABLE `connect_ef` を実行して新しいパーティションをロードします。 connect_ctr テーブルに対しても同じ手順を繰り返します。connect_ctr テーブルの横にある 3 つのドットを選択し、[ パーティションのロード ] をクリックします。 注: 通常、パーティショニング プロセスは毎日午前 0 時に実行され、前日のデータが取り込まれます。 結果をすぐに確認するために、データを手動でインポートしています。 Amazon QuickSight のダッシュボードでは、数分で評価フォーム データが表示されます。 QuickSight、ダッシュボード に移動し、 <stack-name>-EvaluationFormAnalytics_v1 を選択します。 サンプルダッシュボードの概要 [ Team ] ビューには、評価フォームの概要が表示されます。 総合評価スコアと平均評価スコアが表示され、ワードクラウドも含まれています。 評価フォームの詳細かつ包括的な分析が必要な場合は、表形式のビューが最適なオプションになります。 このビューには、評価フォームの質問、結果の値、件数の内訳が表示されます。 カスタムフィルターを適用する事で独自のビューを作成できます。 [ Agent ] ビューは、コンタクト センター エージェントに対するハイレベルな分析を提供します。 このビューには、評価フォームのスコアの内訳が含まれており、これによって最もパフォーマンスの高いエージェントや、コーチングが必要な領域を特定する事ができます。 エージェント、キュー、ルーティングプロファイルなどの条件に基づいてフィルターを適用できるため、絞り込んだ検索や、容易に必要な関連データを見つける事が可能です。 [ Evaluator ]ビューには、コンタクト センターの評価者に対するハイレベルな概要が包括的に表示されます。 実行された評価の合計数と各フォームの平均スコアを視覚化した内容が表示されます。 さらに、サンキー図では、どの評価者が各評価フォームを入力したかを強調表示にて視覚的に確認する事ができます。 クリーンアップ このブログによって作成されたリソースを削除するには: CloudFormation テンプレートを削除します。 CloudFormation テンプレートから作成された S3 バケットを空にして削除します。 CloudFormation テンプレートから作成された Glue データベースを削除します。 CDK データ パイプライン ソリューションをアカウントから削除するには、次の手順に従います。 CDK スタックを削除します。 ターミナルで、 amazon-connect-data-analytics-sample/cdk-stacks に移動します。 cdk destroy --all を実行します。 AWS System Manager パラメータ ストアからデプロイメント パラメータを削除します。 ターミナルで、 amazon-connect-data-analytics-sample/cdk-stacks に移動します。 node configure.js -d を実行します。 まとめ このブログでは、Amazon Kinesis と Amazon EventBridge を使用してコンタクトレコードと評価フォームのデータをストリーミングする方法を学びました。 また、QuickSight ダッシュボードを使用してこのデータを視覚化する方法も示しました。 Amazon Connect のデータソースに関するさらなるインサイトと分析機能については、Amazon Connect Reporting ブログシリーズをご覧ください。 Analyze Amazon Connect Contact Trace Record (CTR) Analyze Amazon Connect Contact Lens Analyze Amazon Connect Chat sentiments Analyze Amazon Connect Chatbot performance Analyze Amazon Connect Agent Event Stream (AES) Automating Amazon QuickSight dashboard creation for analyzing Amazon Connect data Analyze data for Amazon Connect Outbound Campaigns (Contact event Streams) Create Custom Reports for Amazon Connect Cases この記事は Ankur Taunk、 Angela Yu、 Mehmet Demir、 Karletha Paxton によって書かれた Managing Agent Quality using Amazon Connect Contact Lens and Evaluation Capabilities の日本語訳です。この記事はソリューションアーキテクトの梅田裕義が翻訳しました。

Amazon Finance Technologies（FinTech）の payment transmission（支払い送信）チームは、請求書の作成から支払が行われるまでのプロセスにおける、Accounts Payable（AP）チームの製品を管理しています。彼らの一連のサービスは、請求書の作成から決済が終わるまで、受け取り側が確実に支払いを受け取れるよう、支払いプロセスの処理を行います。 Amazon Business は、デジタル作家、アプリケーション開発者、小売業者、電力会社、税理士法人など、非常に多様な支払先に送金を行っています。2022年、FinTech の payment transmission チームは、アメリカで使用されている送金ネットワークの一つである ACH や電信送金などの様々な送金オプションを通じて、150カ国、60通貨以上で4,200万件以上の送金をサポートしました。 このブログでは、 Amazon DynamoDB をあらゆるスケールでミリ秒のレイテンシを提供するキーバリュー及びドキュメントデータベースとして使用して、拡張可能で復元力が高いイベント駆動型の送金通知サービスを構築した方法を紹介します。 要件 Amazon での送金の過程にはいくつかのステップがあります。送金先名や金額などの詳細が記載された請求書の作成から始まり、送金先の銀行パートナーを特定し、最終的に金額、国、ビジネスタイプに応じて最適な送金方法を選択します。必要な情報が集まると、送金の指示が銀行パートナーに送信されます。送金が行われたことを銀行パートナーが確認した後、Amazon は送金完了の通知を顧客に送ります。送金完了時にタイムリーに顧客に通知することで、顧客は支払い状況を把握し、カスタマーサービスへの問い合わせを最小限に抑えることができます。決済される量は日によって、また地域によって異なるため、送金完了の通知を正確に行うためには、必要に応じてサービスの拡張ができることが重要でした。 私たちは以下の項目を主要要件をして設定しました。 シームレスなスケーラビリティ 確実な処理と送金通知 効率的なエラー処理 メンテナンスの容易さ スケーリング問題の解決策 堅牢な送金サービスを構築するために、私たちは AWS のコンピューティングとデータベースのテクノロジーを使用しました。 AWS Lambda はサーバーレスでイベント駆動型のコンピューティングサービスで、DynamoDB とネイティブに統合されています。この記事では、データベースを選択する基準と、その機能をどのように使ってシステムを設計したかに焦点を当てて紹介します。 使用するデータベースサービスを決定するために、私たちは2つの主要な要件を特定しました。まず一つ目は、大量の支払いを処理し、お客様へのタイムリーな通知を維持するために、シームレスにスケールできるデータベースであることです。そして二つ目は、送金先のタイプ、トランザクションのタイプ、国など、支払いに影響を与えるさまざまな要因を考慮したスキーマの柔軟性があることです。急速に変化する財務状況の中で、決められたスキーマを維持することは難しいため、すべてのデータ要素を前もって定義しなければならないような、厳格なスキーマでのシステム構築はしたくありませんでした。こうした点を考慮し、私たちは DynamoDB を選択しました。 DynamoDB は、ハイパフォーマンスなアプリケーションを大規模に実行するために設計された、フルマネージド、サーバーレスの key-value NoSQL データベースです。 DynamoDB は、ビルトインのセキュリティ、継続的なバックアップ、自動化されたマルチリージョンでのレプリケーション、インメモリキャッシング、データのインポートとエクスポートツールを提供します。これらの機能により、ビジネスの差別化には繋がらないデータベースの管理や拡張といった作業は無くなり、私たちは顧客向けの送金アプリケーションの構築に集中することができました。 DynamoDB の オンデマンドキャパシティモード は、キャパシティ予測無しで毎秒何千ものリクエストに対応します。また、使用量に応じた従量課金により、最適なパフォーマンスを維持しながらコストを低く抑えることも可能です。 お客様の支払いを可能にするための処理に必要な情報は、銀行パートナーに送信されます。銀行パートナーが送金処理に成功すると、確認メッセージが送信されます。これらのメッセージには、請求書や支払明細などの追加情報が含まれます。これら2つの処理は異なるシステムで動作するため、2つの異なるサービスに分離し、それぞれが同じ再利用可能なパターン（後ほど説明）に従いながら独自のタスクを実行できるようにしました。処理を分離することで、 FinTech はソリューションをシンプルに保つことができ、また、サービスごとに拡張することができます。 私たちのアプリケーションでは、以下の2つのサービスを使用しています： エンリッチメント・サービス – このサービスは、送金成功時に銀行パートナーからの通知を受信し、詳細情報を追加する役割を果たします。 通知サービス – このサービスは、詳細情報が追加されたメッセージを受信し、通知を顧客に送信します。 エンリッチメント・サービス 次の図は、エンリッチメント・サービスの流れです。 銀行パートナーからの通知は、 Amazon Simple Queue Service （Amazon SQS）の送金イベントキューで受信されます。これらのメッセージは Lambda 関数によって処理され、 DynamoDB のテーブルに格納されます。 DynamoDB の挿入または更新操作は、 Amazon DynamoDB Streams （テーブルアイテムの変更に関する情報の順序付けられたフロー）を介して変更データキャプチャ（ CDC ）イベントのトリガーとなります。 Lambda を使用して特定の CDC イベントを処理し、 AWS Step Functions のワークフローをトリガーします。このワークフローは必要な検証、エンリッチメント、変換を実行します。加工されたメッセージは最終的に Amazon Simple Notification Service ( Amazon SNS ) のトピックにパブリッシュされ、また、DynamoDB テーブルを更新します。この SNS トピックは、通知サービスから、顧客に通知を行うために使用されます。 次の図は、テーブルの設計を示しています。 新しいレコードは、イベントのアトミック性と高いカーディナリティのため、 request ID を主キー、ソートキーは無しで DynamoDB に挿入されます。また、メッセージごとに Step Functions 固有の実行 ARN 名を生成して保存します。事前に ARN を生成することには、主に2つの利点があります。1つ目は、Strep Fcuntions イベントのアップデートを取得する際、ステータスを更新する DynamoDB のレコードを正しく識別するために ARN を参照します。2つ目は、 Step Functions は同じ ARN での実行を許可しないため、偶発的な再実行や重複処理を最小限に抑えることができます。これは arn:aws:states:<region>:<account>:execution:<state machine name>:<Execution Name> という形式です。各メッセージに対してこの一意な実行名を生成するために、request ID と他の値にほとんど静的な値を使用します。Sweeper や通知ワークフローなどの複数のプロセスが、ステータスを更新するために同じレコードにアクセスする可能性があります。 楽観的ロック を有効にするために versionId 属性を使用し、バージョン番号を効果的に管理するために DynamoDBVersionAttribute 注釈で便利なソリューションを提供する AWS SDK for DynamoDB for Java を使用しています。 FinTech の要件の1つはエラー処理能力の向上であったため、Step Functions のワークフローによってトリガーされる依存サービスの停止など、いくつかの理由によって引き起こされるワークフローの失敗を処理することを目指しました。これを実現するために、テーブル上のグローバルセカンダリインデックス ( GSI ) に依存する、sweeper パターンと呼ばれる、FinTech の内部設計パターンを導入しました。 送金テーブルについては、対応するステータスにあるジョブを識別するために、3つの GSI キー（ Retry Job GSI、 Failed Job GSI、Running Job GSI ）を作成しました。ワークフローが失敗するたびに、エンリッチメント・サービスは対応するテーブル・ アイテムを更新し、request ID と同じ値で Retry Job 属性を修正します。Sweeper という名前の Lambda 関数は、失敗したメッセージを再実行するために呼び出され、再実行のしきい値に達していない失敗したアイテムを見つけるために、 GSI キーの Retry Job 属性をスキャンします。GSI は スパース なので、それらの属性に値を持つアイテムだけを抽出します。失敗した項目だけが GSI キーの Retry Job 属性に request ID を持ち、正常に処理されたレコードは表示されません。アイテムを特定した後、Lambda 関数は Step Functions の実行 ARN を生成し、ジョブを再度トリガーします。このアプローチは失敗を最小化します。また、この関数は失敗したワークフローを特定するために数時間ごとに実行されるようにスケジュールされているため、GSI をスキャンすることはこのケースでは実現可能です。 通知サービス 通知サービスは、エンリッチメント・サービスと同様の設計とテーブルスキーマを使用し、出力されたメッセージは同様のパターンに従って消費・処理され、送金通知を顧客に送信します。このサービスには、ユーザー特性、目的、または地域に基づいて、正しい通知テンプレートが使用されることを確認するための追加ルールがあります。 次の図は、通知サービスの流れです。 まとめ Amazon FinTech チームは、DynamoDB データベースを利用して、スケーラブルで信頼性が高く、イベント駆動型の送金サービスを構築しました。彼らは、DynamoDB Streams とスパースな GSI を使ってソリューションをシンプルにし、Sweeper パターン設計を実装しました。さらに、DynamoDB Streams、GSI、スキーマの柔軟性など、DynamoDB ですぐに利用できる機能を使うことで、FinTech チームは、検討した他の選択肢と比較して開発工数を40%削減し、送金および通知サービスを早期に開始することができました。 DynamoDB を使い始めるための詳細については、 ドキュメント を参照してください。DynamoDB を使ったイベントドリブンパターンをより深く知りたい方は、 Serverless Land をご覧ください。 作者情報 Balajikumar Gopalakrishnan は Amazon Finance Technology のプリンシパルエンジニア。2013年から Amazon に勤務し、Amazon の顧客の生活に直接影響を与えるテクノロジーを通じて現実世界の課題を解決している。仕事以外の趣味は、ハイキング、絵画、家族と過ごすこと。映画好きでもある！ Pradeep Misra は AWS のスペシャリスト・ソリューション・アーキテクト。最新の分散アナリティクスと AI/ML ソリューションのアーキテクトと設計に Amazon 全体で取り組んでいる。データ、アナリティクス、AI/ML を用いて顧客の課題を解決することに情熱を注いでいる。仕事以外では、新しい場所を探検したり、新しい料理に挑戦したり、家族とボードゲームをしたりするのが好き。また、娘たちと科学実験をするのも大好きだ。   （本記事は 2023/08/22に投稿された How Amazon Finance Technologies built an event-driven and scalable remittance service using Amazon DynamoDB を翻訳したものです。翻訳は Solutions Architect の嶋田朱里が担当しました。）

Amazon Simple Storage Service (Amazon S3) は、様々な作業を可能にする強力なプラットフォームです。特筆すべき機能として、FQDN でバケットを作成し、 バケットのWebサイトのエンドポイントにエイリアスレコードを指定する ことで、HTTP の静的ウェブサイトをすぐに立ち上げることができます。静的ウェブサイトの HTTPS トラフィックを提供したい場合は、 Amazon CloudF ront を使用して、キャッシュと HTTPS 証明書の両方を公開ユーザーに提供することができます。 ユーザがイントラネットやプライベートネットワーク内にいる場合は、 AWS PrivateLink for S3 のインターフェイスエンドポイントを使用して S3 バケットへのアクセスを提供します。また、ユーザーは portal.example.com のようなフレンドリーなドメイン名を使って静的ウェブサイトにアクセスしたいでしょう。HTTPS は共通の s3-website.<region>.amazonaws.com といったドメイン名で利用可能です。しかし、カスタムドメインでは、TLS証明書を提供するために追加の内部プロキシが必要になります。これは、内部の アプリケーションロードバランサー (ALB) で実現できます。 ソリューション概要 このソリューションは、VPC への既存のプライベート接続と内部 ALB を活用して、カスタム S3 バケットドメインの TLS 証明書をエンドユーザーに提示します。 ALB は AWS Certificate Manager (ACM) を活用し、信頼できる Amazon S3 VPC Endpoint への安全な TLS 接続を維持しながら、エンドユーザーに有効な証明書を提示します。これにより、静的ウェブサイトのカスタムドメイン名の使用が可能になります。 ウォークスルー このチュートリアルでは、Amazon S3 VPC Endpoint と、既存の AWS 接続で利用できる Internal ALB を作成します。 前提条件 このチュートリアルでは、以下の前提条件が必要です： AWSアカウント ACMでインポートしたドメインの プライベート証明書 または インポートした証明書 （任意のリージョン） ACM証明書と一致するドメイン名の Amazon S3 バケット（” portal.example.com “など）。 Amazon S3を使い始める には、こちらをお読みください。また、 Amazon S3バケットでの作業 については、こちらをお読みください。 バケット上で静的ウェブサイトホスティングを有効にする必要はありません。バケットへのリクエストはプライベート REST API を経由します。 少なくとも2つのプライベートサブネットを持つ VPC 既存の Direct Connect、Site-to-Site VPN、またはクライアント VPN 接続で、VPC に正しくルーティングされていること。これはプライベートインバウンド接続と呼ばれます。 カスタムドメイン名の プライベートホストゾーン VPC 内で稼働する Amazon Elastic Compute Cloud（Amazon EC2）インスタンスなど、VPC ネットワークにアクセスできるリソース S3バケットに入力された index.html エントリページを含む静的ウェブサイト Step 1: Amazon S3 のVPC Endpoint を作成する ALB を安全かつプライベートにS3バケットに接続するには、まず Amazon S3 VPC Endpointを作成する 必要があります。 VPC ダッシュボードにログインします。 左側のメニューから「エンドポイント」ページに移動します。 「Create Endpoint」を選択します。 サービスリストで “s3″を検索し、Amazon S3 Interface Endpoint サービスを選択します。 プライベートインバウンド接続を含む VPC と、エンドポイントが属するサブネットを少なくとも 2 つ選択します。インターフェイスエンドポイントの フォールト・アイソレーションを活用する ため、2つ以上の異なるアベイラビリティゾーン（AZ）に属するサブネットを選択することをお勧めします。 VPC エンドポイントを保護するセキュリティグループを選択します。このセキュリティグループは、最低でも ALB のセキュリティグループからのポート 80 と 443 でのアクセスを許可する必要があります。 セキュリティグループの詳細 については、こちらを参照してください。 VPC Endpointのポリシー は “Full Access” を選択します。このポリシーは、VPC で作業している全ての AWS プリンシパルが、どの S3 バケットでも VPC Endpoint にアクセスできるようにします。これは S3 バケットに定義するセキュリティポリシーをバイパスするものではないです。ただし、ALB を作成した後で、このポリシーを制限して ALB へのアクセスのみを許可することもできます。 「Create endpoint」を選択します。 新しい VPC Endpoint ID を選択して、新しい VPC Endpoint を作成する画面に移動します。 下のタブで「Subnets」に移動します。 VPC Endpoint の IPv4 アドレスは後で必要になるのでメモしておきます。 Step 2: VPCエンドポイントから S3 へのアクセスを許可する VPC EndpointsのS3バケットポリシーについて は、こちらをご覧ください。 S3バケットに移動し、「Permissions」タブに移動します。 「Bucket policy」までスクロールダウンし、「Edit」を選択します。 提供されているドキュメントに基づいてポリシーを追加します。参考までに、この提供されたポリシーを使用して、VPC Endpoint のみが明示的に許可されるようにすることもできます。 { "Version": "2012-10-17", "Id": "Policy1415115909152", "Statement": [ { "Sid": "Access-to-specific-VPCE-only", "Principal": "*", "Action": "s3:GetObject", "Effect": "Allow", "Resource": ["arn:aws:s3:::yourbucketname", "arn:aws:s3:::yourbucketname/*"], "Condition": { "StringEquals": { "aws:SourceVpce": "vpce-1a2b3c4d" } } } ] } Step 3: Internal ALB を設定する 内部 ALBは、クライアント向けの TLS 接続を終了します。 AWS ConsoleのEC2ダッシュボードに移動します。 左側のメニューで、「Load Balancers」を選択します。 「ロードバランサーの作成」を選択します。 「Application Load Balancer」ボックスで「Create」を選択する。 ALB に名前を付け、「internal」スキームを選択する。 リスナープロトコルを「HTTPS」に切り替えます。 ALB がサービスを提供するプライベートサブネットを選択します。「Next」を選択します。 クライアントに提供する ACM 証明書を選択します。静的S3バケットのドメイン/名前と一致する必要があることに注意してください。「Next」を選択します。 既存のプライベート接続がロードバランサーのポート 443 に接続できるようにするセキュリティグループを選択または作成します。「Next」を選択します。 まだ設定していない場合は、ここで定義したALBセキュリティグループへのアクセスを許可するように、VPCエンドポイントのセキュリティグループを更新してください。 HTTPS プロトコルを使用する IP をターゲットとする新しいターゲットグループを作成します。ヘルスチェックでHTTPプロトコルを使用します。「ヘルスチェックの詳細設定」で、「ポートオーバーライド」がHTTPプロトコルと一致するように80に設定されていることを確認します。 ALB の ヘルスチェックホストヘッダーにはドメイン名が含まれない ため、S3 は200以外の HTTP レスポンスコードを返します。ヘルスチェックの成功コードに 「307,405」を追加します。「Next」を選択します。 ステップ1で確認した VPC エンドポイントの IP アドレスをターゲットグループに登録します。「Next」を選択します。 ステップ 4: リスナー・ルールの追加設定 Amazon S3 PrivateLink EndpointはREST API Endpoint であるため、末尾のスラッシュを含むリクエストはデフォルトで XML ディレクトリリストを返します。これを回避するには、リダイレクトルールを作成して、末尾にスラッシュを含むすべてのリクエストを index.html に向けるようにします。 内部 ALB に移動します。それを選択し、「Listeners」タブを開きます。 HTTPS リスナーのテーブルの右側で、「View/edit rules」を選択します。 上部近くの「+」アイコンを選択し、新しいルールを挿入できるようにします。 「IF」の下で 「Add Condition」を選択し、「Path…」を選択します。 パスの値の下に 「 */ 」を入力します。 「THEN」で 「Add Action」を選択し、「Redirect to…」を選択します。 「Enter port」の下に 「 #{port} 」と入力します。 ドロップダウンから「Custom host, path, query」を選びます。 「パス」を「 /#{path}index.html 」に修正します。 右上の「保存」を選択します。 Step 5: DNS を設定し、ALB をテストする オンプレミスまたはプライベートの DNS エントリを設定し、Internal ALB を指すようにします。 Route53 プライベートホストゾーン （PHZs）を使用してプライベートエイリアスレコードを設定し、PHZをVPCに関連付けることができます。また、 オンプレミスからのインバウンドDNSクエリをVPCに転送する こともできます。 Step 6: ALB をテストする 内部 ALBにアクセスするには、VPC へのプライベートアクセスを持つリソースを使用する必要があります。リソースに接続し、新しいプライベート DNS エントリにナビゲートしてみてください。リソースへのコンソールアクセスしかない場合は、cURL コマンドを使用してプライベート静的ウェブサイトを検証することもできます。 クリーンアップ クリーンアップのために、このガイドで作成したリソースを以下の順序で削除または元に戻すことができます： Route53 PHZ DNS entries ALB Load Balancer ターゲットグループ Amazon S3 VPCエンドポイント 作成したリソースに関連するセキュリティグループ S3 バケットポリシー まとめ この投稿では、Amazon EC2でプロキシをプロビジョニングすることなく、カスタムドメインでプライベートな静的 Amazon S3 ウェブサイトを作成する方法を学びました。これは、大規模な内部ユーザ・ベースに対して静的ウェブサイトをスケーリングする際に便利です。また、 Amazon EC2 プロキシインスタンスのアップグレード、セキュア化、スケーリングと行ったの差別化につながらない重労働を管理する必要がなくなるというメリットもあります。 静的ウェブサイトに認証メカニズムを追加したい場合は、ドキュメントで提供されている使用例の1つを使用してALB を使用して認証を活用するか、 AWS Verified Access を使用することができます。 翻訳はソリューションアーキテクトの松本が担当しました。原文は こちら です。

この記事は、「 Applying carbon value modeling to achieve net-zero  」を翻訳したものです。 気候変動は現代の最も差し迫った問題の 1 つであり、温室効果ガス (二酸化炭素) 排出量を削減するために迅速な行動を取る必要があることがますます明らかになっています。2050 年までにカーボンニュートラルを実現し、地球の平均気温を産業革命前の 2°C未満に保つには、世界は今後 10 年間、年間 7.6 パーセントずつ排出量を削減する必要があります。現在の世界の排出量は年間 40 GtCO2 を超えています。2023 年 1 月、米国の気候センターであるバークレーアースの研究者たちは、地球の長期平均気温が 2033 年頃に 1.5 °C、2060 年頃に 2 °C上昇することを突き止めました。これには大幅な排出削減が必要であり、取り組みを遅らせることは最終的には (環境からの) 請求書の金額が跳ね上がるだけです。 二酸化炭素排出量の削減を推進するために注目を集めているアプローチの 1 つは、脱炭素化へのデータ主導型アプローチを含むカーボンバリューモデリング (CVM) です。 カーボンバリューモデリングとは何か、またそれがネットゼロの達成にどのように役立つのか？ CVM は、お客様が現在の排出量を分析し、脱炭素化への道筋を生成し、継続的な改善に注力するためのフレームワークおよびツールキットです。これは、資源と業務の効率化に向けた取り組みを実施し、炭素削減戦略 (再生可能エネルギーへの投資や廃棄物の削減など) を適用し、事業における燃料構成を変更することで達成できます。たとえば、ツールキットは、現在の排出量の把握、シナリオ分析の実行、将来の排出量の推移と目標達成能力の比較に役立ちます。 ネットゼロへの道筋設計における課題と複雑さ CVM には多くの利点がありますが、克服すべき課題と制約があります。課題の一つは、考慮すべき要素が複数ある中で炭素排出量に金銭的価値を割り当てることです。もう 1 つの制約は、十分に広く実装されていないと効果が得られないことです。ネットゼロを達成するための道筋を設計することは、複雑な計画作業です。ネットゼロの達成にあたって影響を与える可能性があり、考慮に値する戦略が数多くあるからです。これらには、いくつか例を挙げるだけでも、運転/資源効率の対策 (機器の稼働時間でのアイドリング時間短縮など) 、エネルギー効率対策 (再生可能エネルギーによるエネルギー計画など) 、循環戦略 (セメント製造に鉄鋼炉スラグを使用するなど) 、低炭素プロジェクト (産業用照明を LED に変更、液化天然ガス (LNG) キットを使用するトラックへの改造、再生可能エネルギー/太陽光への投資) 、炭素回収、使用と貯留が含まれる場合があります。これらの戦略のそれぞれについて、排出量に影響を与えるさまざまな詳細な運用変数を使用して分析する必要があります。要するに、意思決定者は以下について知見を有している必要があります。 どの技術的/物理的変数が変更可能で、何が変更できないか？ 最終的に排出量にどのような影響が及ぶか? 排出量価値階層のさまざまな領域 (下記) について誰が責任を負うのか、そしてそれらはどのように追跡されるのか？ 未来目標の組み合わせは、ネットゼロ目標に向けて定量的にどのような結果をもたらすか？ 低炭素プロジェクトの売上と収益がもたらす経済的影響はどのようなものか？ 組織の純排出量に対する炭素税負担はどれくらいか？ 最大の経済的利益と排出量へのプラスの影響 (限界コスト削減) をもたらす低炭素プロジェクトはどれか？ 炭素価値に影響する変数について正確なデータを入力して、企業が定期的な取り組みとして計画を維持するにはどうすればよいか？ 現在の状態の分析 企業からの排出量を分析することは、排出範囲とバリューチェーン全体にわたって根底となっている技術的、物理的、経済的、財務的変数を深く理解することを意味し、最適化の機会、ボトルネック、制約を特定するのに役立ちます。また、what-if シナリオを実行してさまざまなオプションをテストするのにも役立ちます。排出量の典型的な事業階層構造は、グループレベルとユニットレベルの排出量とその下位の燃焼源を対象としています。アクティビティと効率を関連する排出係数と地球温暖化係数( GWP )に適用すると、現在の排出量が計算されます。 図 1.カーボンバリューツリー 通常、カーボンバリューツリーの最上部 (効果) は、総排出量やエネルギー強度など、経営管理に関連する変数や企業の持続可能性パフォーマンスに関連する変数で構成され、バリュードライバーツリーの下位/リーフ (原因) は通常、ツリーの上位にある変数のパフォーマンスをもたらす運用変数で構成されます。たとえば、1 時間あたりに消費される燃料に機器の稼働時間の効率を掛けたアクティビティ変数は、モバイル排出源からの排出量を算出します。下水処理、水の消費、サードパーティの車両の使用など、スコープ 3 に影響するアクティビティを含め、組織内のプロセス全体に対してこのレベルのモデリングを行うことを想像してみてください。影響分析や感度分析ダッシュボードなどのツールを使用すると、意思決定をバリューツリーの特定のレベルにローカライズできます。 未来の状態のデザイン 適切なデータ入力で現在の状態をモデル化したら、ネットゼロの計画担当者は、変数が変更されたときの影響を視覚化するための変数を使用して、さまざまなレベルで感度分析を試してみることができます。計画担当者は、単一の生産ユニットから事業ポートフォリオ全体まで、あらゆるモデルに及ぼす影響を把握できます。たとえば、アクティビティ変数が 5% 変化した場合に、排出量に最も大きな影響を与えるのはどのプロセスか、その一部が制約付きのアクティビティである場合はどうなるかなどです。その後、プランナーはさまざまなシナリオを試して、最適なアプローチと経路を特定できます。 図 2.現在の状態で実行される感度分析 現在の状態モデルも、低炭素プロジェクト変数を含むように再設計されています。たとえば、輸送トラックのグループを LNG に置き換え、稼働時間を現状と同じに保ちながら、LNG 燃料消費率と排出係数を変えた場合、1 時間あたりの燃料消費量はいくらになるでしょうか。これらのシナリオをモデル化することで、現在の状態と比較した炭素削減の様子を把握できます。未来モデルには、各低炭素プロジェクトの正味現在価値 (NPV) を計算し、限界コスト削減 (NPV/炭素削減) に関する知見を生成する財務モデルも含まれます。これにより、企業はプロジェクトをネットゼロのイニシアチブのロードマップにまとめることができます。削減戦略が目標を下回った場合には、ネットゼロの計画担当者は、生物多様性プロジェクトなどによる削減効果をモデル化し、総排出量に対する修正分として正味排出量を算出する事ができます。このようにして、脱炭素化のための包括的な枠組みが提供されます。 インパクトトラッキングの必要性 現在の排出量レベルと目標を確認したら、インパクトトラッキング (影響追跡) では、実際の排出量と計画された排出量の差異がどこで生じているかを示す必要があります。しかし、根本的な影響要因または排出体のそれぞれが特定の排出量の変動に寄与しているのはどれか、さらに重要なのはどの程度か、を正確に定量化することは組織にとって困難です。各要因が企業の排出量にどの程度影響するかを正確に把握できることは、最も効果的な結果を達成できる分野に経営陣の注意を集中させるための重要な要件です。上記の設計には、成熟した分析計画および管理ソリューションが必要です。それを念頭に置いて、従来の経営情報システム (MIS) ツールでは実現できなかった機能を実現するために、モデリング技術と業界固有の知識を統合した Wipro の脱炭素化およびカーボンバリューモデリングソリューションを提供しています。 Wipro の脱炭素化およびカーボンバリューモデリングソリューション Wipro の脱炭素化およびカーボンバリューモデリングソリューションは、アマゾンウェブサービス (AWS) ソリューションを利用しています。 AWS Carbon Data Lake を使用すると、お客様は二酸化炭素排出量データから知見を引き出し、現在の状態を分析し、将来の状態を設計し、その影響を追跡して継続的に改善することができます。 企業は、未加工の排出量データを ヒストリアン (時系列データ) 、モノのインターネット (IoT) プラットフォーム、製造システムやビジネスシステムのコンテキストデータに保存できます。その結果、同じ組織の異なる部門内であっても、温室効果ガス (GHG) 排出データがサイロ化される可能性があります。AWS Carbon Data Lake は、さまざまなソースからのデータを単一のリポジトリに統合して追跡するメカニズムを備えているため、GHG 排出量データの取り込み、標準化、変換、計算という未分化の面倒な作業をさらに軽減できます。AWS Carbon Data Lake では、計算にオープンスタンダードに基づく排出係数を使用しています。これは、データの取得、整理、標準化に関する根本的なデータ問題に関するお客様が抱える大きな課題の 1 つを克服するのに役立つだけでなく、二酸化炭素排出量の計算に一貫性がないという問題を軽減するのにも役立ちます。フレームワークに組み込まれたデータリネージは、データポイントの監査証跡をきめ細かく提供します。 AWS Carbon Data Lake のお客様は、標準的で拡張可能なカーボンデータ管理フレームワークを基盤として、ダウンストリームの視覚化、ビジネスインテリジェンス (BI) 、最適化ツール用のエンドユーザー固有の API を構築できます。これらの API から計算された温室効果ガス排出量データを取得することで、CVM ツールのユーザーインターフェース (UI) は、お客様が現在の状況を視覚化するのに役立ちます。ここでは、スコープ 1、スコープ 2、スコープ 3 の排出量とともに、組織レベルとサイトレベルの排出スコアカードが表示されます。鉱業、石油・ガス、鉄鋼、セメント、その他多くの業界向けにあらかじめ組み込まれた業界 CVM を活用することで、お客様は完全な事業構造をモデル化し、排出量を計算するための業務活動の要因をモデル化できます。排出量が多い事業担当者と一緒に影響分析を行い、その後、シナリオ分析、感度分析、シナリオ比較を実行して将来の状態をモデル化できます。顧客はこのツールを使用して、生産目標に基づく予測や、財務情報を利用した低炭素オプションによる将来の炭素モデリングを行うことができます。 顧客は独自のダッシュボードを作成することも、組み込みのダッシュボードを使用して主要業績評価指標 (KPI) を追跡することもできます。KPI は、追求すべき目標、進捗状況を測定するためのマイルストーン、組織全体の人々がより良い意思決定を行うのに役立つ知見を提供します。 ソリューションの概要 以下の図は、排出源から収集され、AWS Carbon Data Lake によって処理された排出量データからのフロー全体を示しています。 AWS Well-Architected Framework の「 Sustainability Pillar (持続可能性の柱) 」の設計原則とベストプラクティスを使用して構築されています。この柱は、AWS クラウドで安全で、信頼性が高く、効率的で、費用対効果が高く、持続可能なワークロードを設計および運用するためのアーキテクチャのベストプラクティスを学ぶのに役立ちます。計算された温室効果ガス排出量データは、API を通じて CVM ツールで利用でき、お客様が分析を行うことができます。 図 3. ソリューションのアーキテクチャ 図 3 に示すように、ソリューションをデプロイすると、次のアプリケーションスタックが設定されます。 さまざまなソースから取得された顧客排出量データは、標準のCSVアップロードテンプレートにマッピングされます。CSV は、オブジェクトストレージサービスである Amazon Simple Storage Service (Amazon S3) のランディングバケットに直接アップロードされるか、UI を介してアップロードされます。 Amazon S3 ランディングバケットは、取り込まれたすべての排出量データを 1 つのランディングゾーンにまとめます。ランディングゾーンバケットへのデータ入力により、データパイプラインが開始されます。 ビジュアルワークフローサービスである AWS Step Functions のワークフローは、サーバーレスのイベント駆動型コンピューティングサービスである AWS Lambda の排出量計算機能を使用して、データ品質チェック、データ圧縮、変換、標準化、エンリッチメントなどのデータパイプラインを調整します。 新しいビジュアルデータプレパレーションツールである AWS Glue DataBrew は、データ品質監査とアラートワークフローを提供します。AWS Lambda 関数は、A2A (Application to Application) と A2P (Application to Person) を介して通知を送信する Amazon Simple Notification Service (Amazon SNS)、および AWS Amplify のウェブアプリケーションと統合します。これは、フロントエンドのウェブ開発者やモバイル開発者が AWS でフルスタックのアプリケーションを簡単に構築、デリバリー、ホストできるようにする完全なソリューションです。 AWS Lambda 関数では、 Amazon Simple Queue Service (Amazon SQS) によってキューに入れられたデータリネージ処理が行われます。これにより、ソフトウェアコンポーネント間でメッセージを送信、保存、受信できます。 Amazon DynamoDB (フルマネージド、サーバーレス、キーバリュー型 NoSQL データベース) はデータ台帳用の NoSQL ポインターストレージを提供し、AWS Lambda 関数はデータリネージ監査機能を提供し、特定のレコードのすべてのデータ変換をトレースします。 AWS Lambda 関数は、お客様から提供された排出係数を含む Amazon DynamoDB テーブルを参照して、計算された CO2 換算排出量を出力します。 Amazon S3 エンリッチバケットは分析ワークロードのデータオブジェクトストレージを提供し、Amazon DynamoDB—計算排出量テーブルは GraphQL API (API のクエリ言語) のストレージを提供します。 オプションで、デプロイ可能な人工知能 (AI)、機械学習 (ML)、BI スタックを利用することで、開発者は ML モデルの構築、トレーニング、デプロイに使用できる Amazon SageMaker にあらかじめ用意されたノートブックをデプロイしたり、 Amazon QuickSight に構築済みのダッシュボードをデプロイしたりできます。これにより、データ主導型の組織は、拡張性が高く統一された BI を実現できます。デプロイには Amazon Athena  の組み込みクエリが付属しており、これを使用してペタバイト規模のデータを分析したり、Amazon S3 に保存されているデータをクエリしたりできます。各サービスは Amazon S3 で強化されたオブジェクトストレージと事前に統合されています。 オプションでデプロイ可能なウェブアプリケーションスタックは、サーバーレスの GraphQL と Pub/Sub API を作成する AWS AppSync を使用して、ウェブアプリケーションやその他のデータコンシューマーアプリケーションと統合するための GraphQL API バックエンドを提供します。AWS Amplify は、基本的なデータブラウジング、データ視覚化、データアップローダー、アプリケーション設定を含む、サーバーレスで事前設定された管理アプリケーションを提供します。 AWS Lambda 関数は Amazon DynamoDB テーブルから計算された CO2 換算排出量をクエリし、API を呼び出してデータを CVM ツールに送信します。 CVM ツールでは、フルマネージドコンテナオーケストレーションサービスである Amazon Elastic Container Service (Amazon ECS) が、トランザクションデータを一般的なオープンソースのリレーショナルデータベースである Amazon RDS for MySQL に保存し、モデル情報を Amazon DynamoDB に保存します。ユーザーがツールにアクセスすると、トラフィックは可用性が高くスケーラブルなドメインネームシステム (DNS) ウェブサービスである Amazon Route 53 を経由して、コンテンツ配信ネットワーク (CDN) である Amazon CloudFront にルーティングされます。その後、トラフィックは Elastic Load Balancing (ELB) にルーティングされます。ELB は受信トラフィックを Amazon ECS に分散し、そこでデータが保存され、データベースから取得されます。コンテンツは Amazon ElastiCache にキャッシュされます。Amazon ElastiCache は、Redis と MemCache と互換性のあるフルマネージドサービスで、すばやく取り出すことができます。 まとめ 結論として、CVM はネットゼロを達成するための有望なアプローチです。二酸化炭素排出量に金銭的価値を割り当てることで、企業や個人は排出量を削減するための金銭的インセンティブを得ることができます。課題と限界はありますが、CVM は二酸化炭素排出量を削減し、気候変動を緩和するための強力なツールとなる可能性を秘めています。 Wipro と AWS Cloud は、最終的に持続可能性のイノベーションを促進するために必要なプロセス、ツール、サービスを提供することで、ネットゼロを実現するための CVM の導入を支援できます。これらのサービスを利用することで、企業は二酸化炭素排出量を削減し、より持続可能な未来に貢献することができます。 本ブログは、ソリューションアーキテクトの橋井が翻訳しました。原文は こちら です。 参考文献 Robert Rohde, “Global Temperature Report for 2021,” Berkeley Earth, January 12, 2022, https://berkeleyearth.org/global-temperature-report-for-2021/ Amazon Web Services, “AWS がサステナビリティソリューションを実現,” 2021, https://aws.amazon.com/sustainability/ Amazon Web Services, “Customer Carbon Footprint Tool を発表,” 2022, https://aws.amazon.com/jp/blogs/news/new-customer-carbon-footprint-tool/ TAGS: AWS Energy , power and utilities Sudip Kumar Chaudhuri Sudip Kumar Chaudhuriは、Wiproのエネルギー・資源分野およびコンサルティングチームのパートナーです。インドを拠点に、産業コンサルティングとソリューションの分野で25年間働いてきました。業務上の脱炭素化に向けた顧客とのデータ主導およびデジタル主導の取り組みに注力し、組織がネットゼロに移行するのを支援するカーボンバリューモデリングを専門としています。 Bindhu Chinnadurai Bindhu Chinnadurai は、英国ロンドンを拠点とする AWS のシニアパートナーソリューションアーキテクトです。彼女は18年以上にわたり、大規模企業環境のあらゆる分野で働いてきました。現在は AWS パートナーと協力して、スケーラビリティ、耐障害性、パフォーマンス、持続可能性に重点を置いて、お客様がワークロードを AWS に移行できるよう支援しています。彼女の専門はDevSecOpsです。 Shailesh Tekurkar Shailesh Tekurkar は、IT コンサルティング、セールス、プログラムデリバリーの分野で30年以上のグローバルな経験を持ち、石油・ガス、エネルギー・公益事業、輸送、メディア、製薬、保険セクターなどの業界分野の主要顧客にビッグデータと高度な分析データサイエンスソリューションをアドバイスおよび実装することで、イノベーションとビジネス価値をもたらしてきました。彼は現在、ロンドンを拠点とする AWS 向け EMEA 内の GSI パートナーシップ事業を率いています。 V.A. Vaishnav V。A. Vaishnav は Wipro のシニアクラウドリーダーであり、AWS クラウドにおける業界、技術分野、イノベーション、戦略的イニシアチブにわたるプラットフォームソリューションを推進しています。彼はインドを拠点とし、IT業界で24年の経験があります。彼の専門分野には、クラウド変革、ITアウトソーシング、ソリューション化、デジタルトランスフォーメーションなどがあり、クライアントがビジネス成果を達成できるよう支援しています。

AWS は、2023 年 11 月 15 日 ( 水 ) 〜 2023 年 11 月 17 日 ( 金 ) にわたって幕張メッセで開催される Inter BEE 2023 に出展します。 ( 幕張メッセ 展示ホール 4 小間番号：4615 )。 AWS 展示ブースでは、「Create. Deliver. Monetize.」をテーマに、メディア制作から視聴者へ届けるまでのエンドツーエンドにおける 5 つのワークロード『コンテンツ制作』『放送』『メディアサプライチェーン』『 Direct-to-Consumer ＆ストリーミング』『データサイエンス & AI/ML 』の各分野において、他の AWS のサービスやサードパーティーのアプリケーションと組み合わせ、高度にスケーラブルで伸縮自在かつセキュアなクラウドメディアソリューションを実演してご紹介します。 本ブログでは、AWS 展示の概要をご紹介します。 AWS スポンサー展示の概要については こちら AWS ブースセッションの概要については こちら を参照ください。 AWS 展示コーナーの概要 展示ブースでは、5つのソリューションエリアで、6つのデモを実演します。 A-01 AWS で実現するコンテンツプロダクション 映像制作におけるクラウドの活用について、コンテンツ共有と編集、Unreal Engine 5 を活用したバーチャルプロダクション (リアルタイムモーションキャプチャ) をご紹介します。また、ブースにおいて AWS 上で動くコンテンツ制作のソフトウェアを実際に触って体験いただけます。 A-02 AWS で体験する生成系 AI （国内一般初公開） Amazon Bedrock と Amazon SageMaker で構築する生成系 AI ソリューションをデモ展示と、AWS Clean Rooms による、企業間のデータコラボレーションの実演を行います。 生成系 AI を活用したスーパースローモーションのデモアーキテクチャ AWS Clean Rooms による企業間のデータコラボレーションデモアーキテクチャ A-03 AWS で実現する超低遅延配信 　(国内一般初公開) 300 ミリ秒以下の遅延でリアルタイムストリーミングを実現できる Amazon IVS の新機能や AWS Elemental MediaPackage v2 での Low-Latency HLS（LHLS）配信を紹介します。 A-04 AWS で実現する次世代メディアサプライチェーン （国内一般初公開） 次世代メディアサプライチェーンを実現するメディアアセット管理ソフトウェアとストレージ、機械学習などそこで利用される AWS サービスを紹介します。また、Sony オプティカルディスクアーカイブから、各社メディアアセットマネージメントシステムへのデータ移行の実演も行います。 A-05a AWS で実現するライブクラウド制作 （国内一般初公開） 国内外のパートナーソリューションを 連携しクラウドライブ制作を実現する環境を構築します。デモを通じてライブ制作に不可欠な主要機能をご覧いただけます。 A-05b クラウドプレイアウトの現在地 （国内一般初公開） WS はパートナーシップを築きながら日本の放送に焦点を当てたクラウドプレイアウトを構築する取り組みを進めています。この分野での”現在地”をデモを通じてご紹介します。 AWS プレゼンテーションステージについて ブース内ミニステージでは、AWS スポンサーおよび AWS によるプレゼンテーションをはじめ、お客様から現場運用でのクラウド活用について発表いただく予定です。各セッションのスケジュールについては以下を参照いただき、是非ご参加ください。 (登録不要) AWS ブースツアーについて AWS 展示ブースにお越しの皆様に AWS クラウドの活用シーンを深くご理解いただくべく、AWS スポンサーのサービスをはじめ AWS 各展示の見どころをご紹介するツアーを行います。 日付: 2023 年 11 月 15 日（水）、16 日（木）、17 日（金） 時間: 11:00 / 14:00 / 16:00 (各回所要時間約 45 分間を予定) 定員: 各会 12 名まで (登録制) 是非 こちら よりご応募ください。 終わりに 今回は、Inter BEE 2023 の AWS スポンサーをご紹介させていただきました。基調講演や特別講演、会社ごとのブースに関する情報は Inter BEE 2023 の 公式サイト からご確認ください。 皆様にお会いできるのを楽しみにしています！ 参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 本ブログは BD 山口が担当しました。

最近次々と OSS (Open Source Software) の日本語 LLM が発表されています。 Amazon Bedrock から利用できる Anthropic 社の Claude のような有償の LLM に比べてどれくらい性能が違うのか試してみたい、という方も多いのではないでしょうか。いざ、自分で試そうとするとモデルをダウンロードして生成のスクリプト書いて、とちょっと試したいのに作業が多くて大変ですよね。そこで、本ブログでは rinna on Amazon SageMaker JumpStart を活用してみたいと思います。Python が書けない方でもGUI だけで実行できます。 簡単に rinna on SageMaker JumpStart をご紹介させてください。2023 年 9 月にこちらの ブログ で Amazon SageMaker JumpStart にて OSS である rinna株式会社の 日本語 LLM モデルが利用できるようになったことをご報告しました。今回、 LLM を初めて利用される方でもすぐに試せるように Notebook をリニューアルしました。また、現在 SageMaker JumpStart で利用可能な rinna のモデルは Rinna Japanese GPT NeoX 3.6B Instruction PPO に加え、 Rinna Bilingual GPT NeoX 4B Instruction PPO となっています。是非、両方のモデルを SageMaker JumpStart からご利用いただき、回答の違いなどご体験ください。 準備 こちらの ブログ をご覧いただき、Rinna Japanese GPT NeoX 3.6B Instruction PPO もしくは、Rinna Bilingual GPT NeoX 4B Instruction PPO の推論エンドポイントを立ち上げ、Notebook を立ち上げてください。 本ブログにおいて rinna モデル と記載した場合には、これら 2 つのモデルを指します。 本題、ちょっとその前に 本題に入る前にクイズを出したいと思います。以下は、プロプライエタリモデルである Bedrock Claude Instant V1 と Rinna Japanese GPT NeoX 3.6B Instruction PPO に同じプロンプトを与えた時の回答です。ユーザーはコンタクトレンズの利用におけるお困りごと (目が痛い、目が赤くなる、慣れない) を各 LLM に相談しています。皆様はどちらの回答がお好みでしょうか？また、どちらが Rinna Japanese GPT NeoX 3.6B Instruction PPO の回答だと思いますか？ 回答1: コンタクトレンズ用の目薬を使用することができます。また、目の周りを保湿する効果がある、目にやさしい市販の目薬もあります。これらの目薬を使用することで、目のかゆみや刺激を抑えることができることがあります。 回答2: はい、コンタクトレンズを初めて使い始めた時に目が痛くなったり、赤くなったりするのは普通のことです。慣れるまでは以下の点を守ることをおすすめします: – レンズをつける時間を徐々に長くしていく。最初は1時間程度から始め、毎日少しずつ時間を追加していく。 – 常に目薬や潤眼液を使用する。レンズを外した後は必ず目薬を使う。 – 寝る時はレンズを外す。目が休められる時間が必要。 – レンズの品質とサイズが適しているか確認する。 – ストレスを感じた時や目の痛みが強い時はレンズを外す。 – 最初の1週間ほどは時間が短く過ごす。徐々に慣れていく。 目が赤くなる原因はレンズ適応不全の可能性が高いので、上記の点を守りながらゆっくり慣らしていきましょう。症状がひどい場合や続くなら眼科受診をおすすめします。 後ほど、クイズの正解と具体的に与えたプロンプトをご紹介します。 概観 それでは本題に入りましょう。Notebook を立ち上げると目次が表示されます。Notebook には複数のタスクをすぐにお試しいただけるようにプロンプトをご用意しました。 instruction tuning 済みの基盤モデルでは人と LLM が対話するためのフォーマットが決まっている事があります。 rinna モデルの場合は発言の主体をユーザー/システムで区別します。このフォーマットを守る形でサンプルを作成しています。 Notebook では 7 つのユースケースをご紹介しています。いずれもできる限り LangChain のようなライブラリを使わずに素に近い形で書き下しています。LLM を学ぶにあたり、どうプロンプトを与え、対話による複数回の実行によりプロンプトがどう変化していくのかを観察し易くする狙いがあります。基礎を学ぶことで、 LangChain のようなライブラリを使用する時にも、ラップされた内側を想像し易くなり、開発効率に寄与できると考えています。 目次をご紹介します。 準備 rinna モデルを実行するために必要な便利関数を実装しています。rinna フォーマットに合わせるための実装です。 以下のリンクの公式サンプルを実行できます。 Rinna Japanese GPT NeoX 3.6B Instruction PPO Rinna Bilingual GPT NeoX 4B Instruction PPO Zero-Shot を試す Zero-Shot (質問と回答の例を直接的にプロンプトに指定しない方法) によって rinna モデルの口調を変えられるか試すことができます。また、いくつかのプロンプトを追加することでその効果を確認することができます。追加のプロンプト前後の回答の違いを確認いただけます。 Few-Shot プロンプトを試す センチメント分析の例を利用して、いくつかの回答例を示すことで期待する結果を導く Few-Shot を試すことができます。文章に対してラベル (ポジティブ / ネガティブ / ニュートラル) を回答するようにプロンプトを構成してみます。 Few-Shot の利用有無で回答がどのように変化するか確認いただけます。 質問応答を試す 2022年 Amazon CEO の書簡 の第一段落を使用して質問応答を試すことができます。質問対象となる文章をプロンプトに含めておきます。その文章に対して質問し、正しく回答できるかを観察してみてください。プロンプトに回答の参考になる文章を含めることで質問応答することが可能になります。このプロンプトエンジニアリングは RAG と呼ばれる方式でも重要な考え方の一つです。このサンプルプロンプトにより、OSS の日本語 LLM を RAG に組込んでみようかと思っていただければ嬉しいです。 要約を試す 要約は長い文章を短しつつも必要な情報を残すことが重要です。 2022年 Amazon CEO の書簡 の第一段落を使用して要約をお試しいただけます。 ChatBot を試す 架空のキャラクター山田太郎という画家を設定して、チャットボットをお試しいただけます。チャット機能ではこれまでの会話の文脈を捉えて回答することが必要です。チャットの内容を随時プロンプトに追加して rinna モデルに入力することで実現できます。追加されていくプロンプトとrinna モデルの回答を確認しながらお試しいただけます。 計算を試す 足算を題材に rinna モデルの回答を試すことができます。もしかすると正しく回答できない場合があるかもしれません。しかし、人がそうであるように不得意なことはツールを利用することで解消できます。それが次の Agent を試すです。 計算を試す と Agent を試す は是非セットでお試しいただければ嬉しいです。 Agent を試す 計算指示に対し rinna モデルが電卓を使用する流れをお試しいただけます。Agent には ReAct などさまざまな手法が提案されており、その一部の要素をピックアップしています。まずツールを選択するまでのプロンプトと rinna モデルの回答の流れを一つ一つ確認できるように実装し、次にそれらを関数化して複数回実行できるようにしています。 発展 Notebook では取り扱っていないけれども、次のステップとして是非挑戦いただきたい内容を記載しています。 付録 テキスト生成実行時に渡せるパラメータを説明しています。 Hugging Face の Text Generation Inference に則り、以下のパラメータをテキスト生成実行時に渡すことができます。この Notebook では、 max_new_tokens , repetition_penalty などが該当します。 Text Generation Inference のパラメータ説明 の日本語訳です。 是非これら全ての詳細を本ブログでご紹介したいところですが、 準備 と Agent を試す についてピックアップしてご紹介します。 「準備」のご紹介 Rinna Japanese GPT NeoX 3.6B Instruction PPO、Rinna Bilingual GPT NeoX 4B Instruction PPO 両方の公式サンプルのプロンプトを試すことができます。早速、出力例を見てみましょう。まず、Rinna Japanese GPT NeoX 3.6B Instruction PPO の例です。ユーザーとシステムを指定してテキストを入力している事がわかります。また、改行には <NL> を使用しています。LLM の利用を開始する際、フォーマットを確認することは最初の一手です。 出力例： コンタクトレンズ用の目薬を使用することができます。また、目の周りを保湿する効果がある、目にやさしい市販の目薬もあります。これらの目薬を使用することで、目のかゆみや刺激を抑えることができることがあります。 実は、最初のクイズはこちらのプロンプトを利用していました。上記の回答が Rinna Japanese GPT NeoX 3.6B Instruction PPO の出力です。皆様、クイズに正解できましたか？また、皆様の回答のお好みと比べていかがでしたか？OSS の日本語 LLM を試してみようと思っていただけたら嬉しいです。（Claude Instant V1 は Human/Assistant で識別するためフォーマットだけ変更してプロンプトを実行しました。） Rinna Bilingual GPT NeoX 4B Instruction PPO の例はこちらです。同じく、ユーザー/システムを指定していますが、改行には改行コードを使用しています。また、多言語対応のため、サンプルも英語と日本語が使用されています。 出力例： ‘Virtual Realityです。’ 「Agent を試す」のご紹介 Zero-Shot や Few-Shot に比べて Advanced な使い方として Agent を想定した使い方を記載しています。 Agent は単一の LLM が持たない処理能力や知識を外部のツールや他の LLM と連携して、ユーザからの問合せを解決するための仕組みです。Agent の実装方法は目的や使用する LLM の選択により様々な実装が考えられます。Notebook では、その基礎になりそうな ツールを選択して使用する というユースケースを挙げています。 人がそうであるように、何か計算する時には LLM も電卓を使用した方が正確です。この場合、プロンプトに入力されたテキストから、電卓を使用すべきか否かを LLM が判断でき、計算に必要な情報をテキストから取得できる事が鍵となります。是非、Notebook を活用いただき、rinna モデルを使用しての Agent の一端をご体験いただけますと幸いです。 出力例 (Rinna Bilingual GPT NeoX 4B Instruction PPO): 考察: [3+5] これは数式です。Tool を使うべきです。 行動: 使用する Tool は Dentaku[3+5] 回答: 8 計算式に対して、考察を経て行動を選択する様子が確認できます。Agent 利用においても OSS の日本語 LLM をお試しいただければ嬉しいです。 終わりに Amazon SageMaker JumpStart rinna モデルの Notebook を利用してお試しいただける 7 つのユースケースをご紹介しました。LLM が初めての方にも理解し易くする事を心がけて作成しております。是非こちらを活用し、皆様の OSS の日本語 LLM 利用を JumpStart いただければ幸いです。また、現在、Train Model が使用できませんが、近日公開予定です。ご期待くださいませ。 著者 中島 佑樹 西日本のお客様をメインで担当するソリューションアーキテクト。社会人博士を修了したことをきっかけに AIML を得意分野としている。 システム一般のテーマや Amazon Bedrock を用いた生成系 AI のシステム開発、Amazon SageMaker Studio Lab を用いた AIML への入門まで幅広く活動。

医療 DX においてのクラウド活用について 日本中の全ての業界・業種・地域で「デジタル・トランスフォーメーション（DX）」の加速が叫ばれています。デジタルを活用して、イノベーションを起こす DX は、ヘルスケア業界においても例外でありません。 昨今、病院をターゲットにしたランサムウェア被害が頻発しているように、ヘルスケアに関わるセキュリティやコンプライアンス、プライバシーの確保は最優先事項です。専門性が高くまた規制が厳しく、ステークホルダーも限られていた事もあり、これまではイノベーションが進みづらい環境にありました。カルテ、レントゲンなどの画像データ、様々な検査結果など、ヘルスケアに関する情報量は膨大かつ多様です。一方、これらデータは臨床現場・医療事務・研究分野で個別最適化される形で分断され、ヘルスケアのアクティビティ全体を俯瞰してデータ管理し、そこから有用な示唆情報を見つけ出すことが難しい状況にあります。また、病院や関連医療機関を跨いだ患者の健康情報・疾病情報について過去の診療履歴を振り返ったり、共有することも困難な状況です。患者の特性に応じたヘルスケア・プログラムを、他の患者の膨大な記録を基にカスタマイズして最適化すること（個別化医療）も未だ道半ばです。 愛知県豊明市に本院を構える藤田医科大学では上記の様な課題を率先して解決をするために、4 つのフェーズに分けた様々な取り組みを行っています。 フェーズ 1 では二次利用連携プラットフォームを構築して、データ交換の標準化と Web システムでの連携モデルを構築しています。研究領域でのセキュリティ対策ではデータの暗号化にブロックチェーン技術を用いた検証をし、臨床領域での業務改善としては生成系 AI を利用し概念実証（PoC）を行っています。 フェーズ 2 では本ブログで主に説明を行うクラウド上での電子カルテの稼働を行い、災害対策やデータ連携を目的としたシステム構築を羽田クリニックにて実装を行います。 フェーズ 3 ではオーダリングシステムや部門システムでの標準コードを取り入れ、データをより標準化したものとして保管し一次利用・二次利用や、業界を横断した取り組みに役立てることを想定しています。 フェーズ 4 では電子カルテシステムをクライアントサーバー形式から SaaS（Software as a Service）形式へと変革させることを想定しています。 アマゾン ウェブ サービス ジャパン合同会社（以下、AWS ジャパン）では藤田医科大学病院の上記のような取り組みを支援し、医療DXの推進をクラウドの力で実現するべく活動を行っています。 藤田医科大学 羽田クリニックの電子カルテ・医療情報基盤をクラウド環境上で稼働したことを発表 2023年10月17日に藤田医科大学 羽田クリニックにおける AWS 上での電子カルテ・医療情報基盤稼働について、藤田医科大学、日本 IBMより以下のようにプレスリリースが出され、同時に記者会見を開き、AWS からはパブリックセクター統括本部長の宇佐見が登壇しました。 以下、 IBM Newsroom の発表内容を抜粋します。 藤田医科大学 （愛知県豊明市、学長 湯澤 由紀夫）と日本アイ・ビー・エム株式会社（本社：東京都中央区、代表取締役社長：山口明夫、以下 日本IBM）は、2023年10月2日に、羽田空港に隣接する複合施設内に開設した「 藤田医科大学 羽田クリニック (以下、羽田クリニック)」の包括的な電子カルテ・医療情報基盤をクラウド環境上に構築し、利用開始したことを発表しました。藤田医科大学では、新電子カルテ・医療情報基盤を活用することで、健診から医療、予後（病気や治療などの医学的な経過に関する見通し）にわたり、患者様や臨床の医療者のデータ利活用を支えることによって、厚生労働省が提唱する「医療DX令和ビジョン2030」に先駆けて、医療デジタル・トランスフォーメーション (DX)を推進していきます。 （写真左より）藤田学園 理事長 星長清隆氏 ／ 藤田医科大学 学長 湯澤由紀夫氏／日本アイ・ビー・エム 執行役員 金子達哉氏／アマゾン ウェブ サービス ジャパン 執行役員 パブリックセクター統括本部長 宇佐見 潮 羽田クリニックの新電子カルテ・医療情報基盤は、藤田医科大学病院と同じIBMの病院情報システムIBM Clinical Information System （CIS）を使用しているため、IBMのデータ連携基盤を活用すれば、簡単に、国際標準規格のFHIRⓇに準拠した外部のヘルスケア・ソリューションとのデータ連携が可能です。さらに、アマゾン ウェブ サービス（以下、AWS）が提供するクラウドコンピューティング上で稼働することで、ベンダーや業界を超えたデータの相互交換が可能になりました。 AWSは、藤田医科大学におけるIBMサービスの活用に向けて、グローバルの幅広い知見・スキルを活用し、AWSサービス選定・構成検討・院内におけるクラウド利用ガイドラインの作成サポートなどを行い、医療機関におけるクラウド上での電子カルテ・医療情報基盤の構築に向けたセキュリティーの向上を支援しました。また今回、AWSのクラウド上での電子カルテの運用・稼働に、セキュリティー対策やデータのバックアップなどを機能として提供しているマネージドサービスといった最新のテクノロジーが活用されています。 AWSは今後さらに、病院がインフラの運用管理を削減したり、臨床・オペレーション・研究の効率を向上し、病院がよりコアビジネスにフォーカスすることでビジネスの変革を推進するよう支援します。 IBM 製病院情報システム (CIS) を構築する上での AWS からの支援 IBMの病院情報システム (CIS) の構築において、藤田医科大学病院全体のアーキテクチャを以下の通り構築いただきました。 藤田医科大学東京 先端医療研究センターから AWS への接続は、専用プライベート接続サービスである AWS Direct Connect とマネージド IPsec VPN 接続が利用可能な AWS Site-to-Site VPN を用いた冗長接続となり、右上の電子カルテが稼働しているプライベートなネットワーク空間である Amazon Virtual Private Cloud（Amazon VPC） へセキュリティを考慮した接続を行っています。 また、図の中央にある AWS Transit Gateway のサービスをハブとして利用し、藤田医科大学病院を含めたオンプレミスネットワークとの接続や、右側 2 番目の健康診断システム、3 番目のデータ二次利用基盤へアクセスできます。 医療機関とクラウドを接続する際のネットワーク構成については、 医療情報ガイドラインをクラウド上で実践する – ネットワーク編 Part 1 のブログをご確認ください。 AWS 上で稼働しているシステム個別の環境では、お客様の運用上の負担を軽減するマネージドサービスを活用して、運用負荷の軽減やセキュリティ向上を行っています。 電子カルテ環境ではオブジェクトストレージサービスを提供する Amazon S3 を利用してバックアップを保管しており、AI による脅威検出を行うことができる Amazon GuardDuty を利用してセキュリティ対策を行っています。また、AWS 上でマルチアベイラビリティゾーン（マルチAZ）構成を採用し、これにより自動的に他のデータセンターにデータのバックアップがとられる他、片方の AZ にトラブルが生じた場合でも、自動的に切り替えが行われます。マルチ AZ 構成を採用することでシステムの冗長性を確保することができます。 DWH/AI/ML Account 上で稼働している二次利用基盤では、データウェアハウスをクラウド上でマネージドに利用可能な Amazon Redshift を利用してデータ解析の準備環境を構築し、機械学習基盤をサービスとして提供する Amazon Sagemaker を用いてデータ解析を行っています。 ネットワーク監視には NW Firewall VPC を作成して、一般的な攻撃からウェブアプリケーションを保護する AWS Network Firewall を利用しています。 病院における基幹システムである電子カルテがクラウド上で動くことによって、よりセキュリティを強固にすることができるとともに、今後は AWS が提供する AI/ML や IoT サービスといった最先端のデジタルツールを導入しやすくなります。 また藤田医科大学病院内でクラウド利用をするにあたって、コンサルティングサービスである AWS プロフェッショナルサービス を利用して、藤田医科大学病院独自の AWS サービス技術ガイドラインの作成をご支援しました。当初課題として認識されていた、アカウント設計・ネットワーク設計・セキュリティ設計を対象にガイドラインの作成を支援し、AWS を利用していく際のリファレンス文書として役立てております。 特に AWS セキュリティ設計ガイドラインを利用するにあたり、取り組みの一部として厚生労働省が策定している医療情報システムの安全管理に関するガイドライン 6.0 版を踏まえ、AWS サービスとして検討すべき事項をディスカッションの上、整理をしています。これらを用いることで、AWS 部分においては医療情報ガイドラインを考慮した設計とすることができると期待しています。 （参考画像）AWSプロフェッショナルサービスのセキュリティ関連サービス全体像 AWS ジャパン では、医療情報を取り扱うシステムを構築する際に参照される各種ガイドラインに対応するための「 医療情報システム向け AWS 利用リファレンス 」の文書の作成にあたり、AWS パートナー各社様を支援しています。 藤田医科大学病院における今後の AWS 利用について 藤田医科大学病院の医療DXに向けた 4 つのフェーズの取り組みについて、今後も引き続き最適なプラットフォームとして利用していただくよう、AWS は多方面での支援をしていきます。 フェーズ 1 の取り組みとして、すでに AWS で構築され始めている医療情報の二次利用連携プラットフォームにおいて、今後は製薬企業や治験事業者とデータの連携を行い、医療の質向上を目指す取り組みを支援していきます。また、生成系 AI の実証の取り組みにおきましても、AWS 上での検証を実施いただいており、医師の働き方改革をご支援していきます。 将来的な取り組みとして掲げているフェーズ 3，4 においても藤田医科大学病院のクラウドジャーニーを伴走し、今後さらに病院がインフラの運用管理の負担を削減し、臨床・研究の効率を向上させ、よりコアビジネスにフォーカスできるようなビジネスの変革の推進を支援します。

はじめに 持続可能性は製造業の要となっています。ステークホルダーがますます 持続可能性を優先 するようになる中、製造業はこうした要求に応えるため、技術革新に目を向けています。このような技術革新の中でも、 デジタルツイン のコンセプトは、持続可能性を目指す製造業にとって、特に変革をもたらすものとして際立っています。 製造業には幅広いトピックが含まれるが、本稿では特に消費者向けパッケージ商品（CPG）分野の製造業に焦点を当てます。CPG 企業にとって、デジタルツインは、製造プロセス、製品ライン、パッケージング・システム、あるいは包括的なサプライ・チェーンのダイナミックな仮想レプリカとして機能します。IoT センサー、マシンメトリクス、過去のパフォーマンス記録などのソースから実世界のデータを統合することで、これらのモデルはパフォーマンスの綿密なモニタリング、シミュレーション、最適化を可能にします。製品ライフサイクルのプロトタイピング、テスト、最適化の各フェーズをバーチャル環境に移行することで、企業はプロトタイプを何度も繰り返し作成するために必要な材料だけでなく、現在および将来の製品やプロセスを開発するために必要な材料の需要や副産物の量も 大幅に削減 することができます。デジタルツインの分類と様々な成熟度レベルの詳細については、「 AWS のデジタルツイン：ビジネスの価値と成果を解き放つ 」を参照してください。 この記事では、製造業が優先する重要なサステナビリティ KPI を掘り下げ、デジタルツインがその測定をどのように大きく変えることができるかを探ります。エネルギーと水の節約を定量化するためにデジタルツインテクノロジーを巧みに活用したグローバル CPG ブランドのケーススタディにスポットを当てます。最も重要なこととして、製造業にデジタルツインを導入するための様々な AWS サービスについて学び、二酸化炭素排出量を 20 ％削減することで持続可能性の目標をサポートします。 サステイナビリティ目標を推進するデジタルツイン デジタルツインは、組織が物理的なシステムの性能を定量化し、環境への影響を削減するのを支援することで、持続可能な取り組みにおいて重要な役割を果たしています。バーチャルの領域での注目すべきアプリケーションは、エネルギー消費、水消費、廃棄物を削減するための新しい製品設計、代替パッケージング、製造構成のシミュレーションです。この先制的なモデリングにより、持続可能性の向上を特定することができ、実際に実施する前であっても、これらを確実に組み込むことができます： エネルギー効率 ：製造企業はデジタルツインを活用してエネルギー消費パターンを微調整し、 スコープ 1、スコープ 2、スコープ 3 の温室効果ガス排出量を大幅に削減することができます。 専門サービス会社 EY の最近のレポート によると、デジタルツインは、最大 35 ％のコスト削減とともに、既存建物の温室効果ガス排出量とカーボンフットプリントを最大 50 ％削減するのに役立ちます。 廃棄物管理 ： デジタルツインは事実上、抽出、生産、消費、廃棄という現在の産業モデルの枠を超えることに役立ちます。そのため、企業や都市全体が、 汚染や廃棄物の発生をほぼゼロ にし、製品や素材をリサイクル・ループ内に長くとどめ、自然システムの再生を助ける「循環型経済」システムに移行する選択肢を持つことができます。 持続可能なデザイン ：デジタルツインは、サプライチェーン全体のカーボンフットプリントをリアルタイムで追跡し、製品設計と開発のライフサイクルのカーボンフットプリントを算出することで、透明で持続可能な設計から納品までの道のりを保証します。 製品の持続可能な設計をリードする戦略 に関するこの記事では、この戦略についてより詳しい情報を提供しています。従来の設計技術を活用することで、企業は製品の環境負荷を最大 40 ％削減することができます。 物流排出削減 ：デジタルツインは物流と流通の 最適化 を支援し、物流に関連する二酸化炭素排出を抑制します。ロジスティクスでは、デジタルツイン・テクノロジーを活用することで、 収益が最大 10 ％増加 し、製品の品質が最大 25 ％向上します。 節水 ：デジタルツインは、水使用量の多い製造業において極めて重要な役割を果たし、最適な節水戦略を実現します。 戦略的計画 ：製造企業は、デジタルツインを活用して予測的洞察を得ることで、持続可能な成長のための資源配分や投資戦略を導くことができます。 ステークホルダーエンゲージメント ：デジタルツインでは、持続可能性に関連する戦略を視覚的かつ定量的に表現できるため、ステークホルダーへの持続可能性の方策の伝達が効率化されます。 アーキテクチャの概要 以下に、工場での実装用に設計され、持続可能性の目標を監視するように調整されたリファレンス・アーキテクチャの概要を示します。このアーキテクチャは、炭酸飲料、水、様々なフルーツジュースを生産する顧客のボトリング工場に導入されました。 このリファレンス・アーキテクチャで使用されている主要な AWS サービスは、 AWS IoT SiteWise （産業機器からのデータを簡単に収集、保存、整理、監視できるマネージド・サービス）と、 AWS IoT SiteWise Edge （オンプレミスでのデータ収集と整理を効率化するローカル・ハードウェアまたは AWS デバイスにインストールされるサービス）です。これらのサービスを組み合わせることで、工場のオペレーターは、クラウド接続が断続的な場合でも機能を維持しながら、稼働時間、製品品質、効率を向上させるための機器データに対する洞察を得ることができます。 さらにこのソリューションは、 Amazon S3 、 AWS Lambda 、 Amazon DynamoDB 、 Amazon Kinesis Data Firehose 、 AWS Glue 、 Amazon Athena 、 Amazon Managed Grafana などの AWS サービスも使用しています。 データ収集に必要なコア IoT コンポーネント、テンプレート、アセットモデル、メトリックコレクションが AWS IoT SiteWise に含まれており、4 週間で実装を行いました。 この実装では、 AWS IoT SiteWise Edge がオンプレミスデバイスにインストールされ、 KepserverEX のような OPC/UA サーバーを介して PLC からIoT データを収集します。データはクラウドに送信され、AWS IoT SiteWise を使用してビジネスルールとプロセス関連情報を使用してさらにエンリッチされます。メトリクスの計算とデータの保存には、 AWS Lambda 、 Amazon DynamoDB 、 Amazon S3 、 AWS Glue 、 AWS Kinesis Data Firehose の組み合わせが使用されます。消費データの、ほぼリアルタイムの可視化、およびさらなる分析や表示には、 Amazon Athena と Amazon Managed Grafana ダッシュボードが使用されています。 この初期アーキテクチャをベースに、 AWS IoT TwinMaker のような AWS サービスを統合することで、包括的なコマンド、制御、可視化機能を実現できる。AWS IoT TwinMaker により、開発者は現実世界のシステムのデジタルツインを作成し、包括的な運用ビューのために既存のデータと 3D モデルを使用して、ビル運用を合理化し、生産を強化し、機器の性能を向上させることができます。 サステナビリティ KPI 指標の算出方法 上記で説明したデジタルツイン導入フレームワークを活用することで、工場は、持続可能な操業の認定を受けるために、コンプライアンスや報告目的で必要とされる可能性のある様々な持続可能性 KPI を把握することができます。この CPG のお客様の場合、最初の概念実証はエネルギー効率と省エネルギーに焦点を当てました。これは後に、節水と廃棄物管理にまで拡大されました。 デジタルツイン・ソリューションの導入には、現在のエネルギー使用量と節約の可能性を計算するステップ・バイ・ステップのアプローチが含まれます。まず、包括的なエネルギー監査によって、工場のエネルギー消費量を把握します。 AWS IoT SiteWise Edge を使用して、このデータを AWS IoT SiteWise に中継します。この監査データは、全体的なエネルギー使用量と主なエネルギー消費機器を把握するのに役立ちます。エネルギー消費はさらに、部門やプロセス、エネルギーの種類ごとに分類されます。これに続いて、エネルギー効率メトリクスが計算され、通常、出力対エネルギー入力比を表します。これにより、既存設備の更新から運用の非効率性への対応まで、改善が必要な分野を特定するための段階が整います。 エネルギーと水の節約を定量化する方法 持続可能性を高めるために用いられる主な戦略には、水効率の高い機器への移行、水のリサイクルの促進、廃棄物の削減と排除、持続可能な実践に関するスタッフ・トレーニングの促進、そして最後に、機器の故障を予測してダウンタイムを回避するための予知保全ソリューションの導入などがあります。節水対策を実施する際には、目標 KPI に対する達成度を評価することが重要です。これにより、利益が定量化されるだけでなく、持続可能な対策への長期的な取り組みが保証される。これらの KPI を定期的に評価することで、継続的な改善が保証されると同時に、外部からの検証や認証を受けることで、環境に配慮したオペレーションに対する工場の献身を確認し、増幅させることができます。 このような追跡・監視手段を導入すれば、組織は、導入後の消費量を基準値と比較することで、エネルギーと水の消費削減量を定量化することができます。これらのエネルギー、廃棄物管理、水の節約は、現在の市場価格を用いて金額に換算することができます。これらの取り組みの長期的な成功に不可欠なのは、定期的な監査と組み合わせたこれらのシステムの継続的なモニタリングの採用です。 サステナビリティ KPI 指標の追加方法 デジタルツインは、追加メトリクスを取得するためのベースラインを確立するため、新しいサステナビリティ KPI メトリクスの追加は比較的簡単です。例えば、製造工場が節水メトリクスや廃棄物削減メトリクスを追加したい場合、上記の文書化されたプロセスが繰り返されます。例えば、最初の監査では、水の消費量と廃棄物の発生量に関するベースライン指標を取得し、その後、水を大量に消費する工程と廃棄物を大量に排出する工程を特定し、改善の可能性がある領域を特定します。製造工場は、水の使用量を特定の部署や工程などの起源ごとに区分し、廃棄物をその種類と起源に基づいて分類することにより、非効率を監視するための持続可能性 KPI を効果的に設定することができる。 デジタルツインの機能拡張 例えば、 Amazon Lookout for Equipment は、 AWS IoT SiteWise が収集した工場設備のセンサーデータを活用し、予知保全や異常検知を行う AWS サービスです。 AWS IoT TwinMaker は、製造アセット、建物、プラント、HVAC システムの 3D レプリカを作成し、コマンド・アンド・コントロール機能でデジタルツインの機能を強化するもう 1 つの AWS サービスです。つまり、単一の仮想システムでオペレーション全体の全体像を把握することができるということです。 まとめ この記事では、AWS 上で展開可能なデジタルツイン の実装について掘り下げました。さらに、追跡すべき主要業績評価指標（KPI）を強調し、持続可能性の目標達成に向けて正しい道を歩んでいることを確認しました。製造システム、生産ライン、さらには製品の仮想レプリカを構築することで、デジタルツインは、水、エネルギー消費、廃棄物管理などのサステナビリティ KPI をほぼリアルタイムで監視・モニタリングすることができます。デジタルツインから得られるこれらの洞察を活用することで、企業はリソースの利用をさらに最適化し、二酸化炭素排出量を削減し、より持続可能な生産と流通に向けて戦略を調整することができます。CPG 業界においてデジタルツインの機能を活用することで、将来の世代のために持続可能で強靭なエコシステムの構築に向けて、測定可能な進歩を遂げることができます。AWS がどのようにデジタルツインの実装と持続可能性の目標について他のお客様をサポートしているか、より詳細な情報をお知りになりたい場合は、以下のリソースをご覧ください： Building Efficient Digital Twins in the Construction Industry Digital twins and CPG manufacturing transformation How to make digital technologies for the circular economy work for your business Accelerating the shift towards a sustainable economy using HPC on AWS この記事は Ajith Surendran、Kavita Chhabria、David Bounds によって書かれた Improving Sustainability in Manufacturing with Digital Twins の日本語訳です。この記事はソリューションアーキテクトの戸塚智哉が翻訳しました。 著者について Ajith Surendran Ajith は、AWS のカスタマー・ソリューション・マネージャーです。IT 分野で 20 年以上の経験を持ち、主に家電と IoT に注力してきました。AWS では、顧客に適切なソリューションを提供し、クラウドへの移行を促進することを主な任務としている。英国在住のアジスは、野菜を栽培する畑での時間を大切にしています。また、IoT や AI/ML 技術を深く掘り下げ、カーナティック音楽を鑑賞し、飛行機を楽しんでいます。 Kavita Chhabria Kavita はジョージア州アトランタを拠点とするシニアカスタマーソリューションマネージャーです。AWS に入社して 2 年 6 ヶ月、CPG/小売、サプライチェーンとロジスティクス、プロフェッショナルサービス、Agtech ドメインにフォーカスしてきました。AWS 入社以前は、Macy’s Technology 社でデジタルトランスフォーメーション・プログラム・リーダーを務め、28 年以上にわたってテクノロジー部門に不可欠な存在となっています。カヴィタはサステナビリティ TFC の一員であり、AOD を目指しています。サステナビリティに非常に熱心で、顧客とともにサステナビリティへの取り組みを積極的に推進しています。 David Bounds David は AWS のエンタープライズソリューションアーキテクトです。AWS 上でワークロードを高速化するために顧客と協働しています。機械学習と生成 AI にフォーカスし、あらゆる種類、視点、経験レベルの顧客に技術的支援を提供しています。David はロンドンに住み、ロンドンの気候が好きで、飼い犬のボクサーの散歩と物語を集めています。 <!-- '"` -->

製造業は変革の最中にあります。 最新のクラウドテクノロジーを利用することで、製造業のお客様は業務を最適化し、コストを削減し、新たな収益源を生み出すことができるのです。 11月27日から12月1日までラスベガスで開催される AWS re:Invent 2023 に参加すると、先進的な製造業のお客様が AWS のクラウドテクノロジーを活用して、業務を変革し、新しい顧客体験のためのソフトウェア定義型製品を開発し、サステナビリティへの取り組みを加速している内幕を知ることができます。気づきを与える基調講演、教育的なワークショップやブートキャンプ、参加者同士のネットワーキング機会のため、ぜひラスベガスに1週間いらしてください。 直接参加できない方のために、バーチャルなプログラムも用意しています。バーチャル re:Invent には、基調講演とイノベーショントークのライブストリーミング、ブレークアウトセッションへのアクセスなどが含まれます。詳細や登録は 登録ページ をご覧ください。 イベントのハイライト:生成系 AI がイノベーションを促進 生成系 AI が今年の目玉です。このブログの原稿は、AWS の生成系 AI サービスを使用して作成されました! 一週間の会期を通して、AWS の製造業やその他業界のお客様が、実際の生成系 AI アプリケーションからビジネス価値を提供している方法について、ブレークアウトセッションで共有します。 AWS のリーダーであるアダム・セリプスキー、ワーナー・ヴォーゲルス、スワミ・シバスブラマニアンが、生成系 AI の最新情報を提供します。また、生成系 AI の専門家と直接対話し、生成系 AI が製造業のお客様の真のイノベーションにどのように役立つかを体験できるワークショップやインタラクティブデモも用意されます。 re:Invent 2023 は、顧客事例、デモ、展示を通じて、製造業のお客様が実現できることの可能性を示すことを約束します。 さまざまなセッションや展示場のインタラクティブデモを通じて、製造業のお客様が AWS サービス、AWS ソリューション、AWS パートナーソリューションを利用して、生産性を向上させ、サプライチェーンの回復力を高め、新しいデジタル体験で顧客を喜ばせている様子がおわかりいただけるでしょう。以下は、その予告です。 AWS Industrial Demo Area: デジタル変革の起点 ベネチアンホテルのエキスポにある AWS Industrial Demo Area では、クラウドを使って製造業のお客様が迅速に実現できる主要なユースケースを紹介します。スマートオペレーションから予知保全まで、製造業のお客様がクラウドですぐに有効活用できるソリューションをご覧いただけます。メインのエキスポホールの奥左にある AWS Industries Pavilion 内でご案内いたします。 エキスポのデモエリアでは、産業 IoT、機械学習、生成系 AI などの AWS のテクノロジーをご覧いただけます。このエリアの目玉は、インタラクティブなスマートファクトリーのデモで、設備の PLC データ、運用データ、IT データを AWS に安全に取り込むためのデータ戦略を構築することで、製造業者がクラウドの旅をどのように始められるかを紹介しています。スマートコネクテッドプロダクト、製品設計、サステナビリティ、サプライチェーンなどのハンズオンデモもご利用いただけます。Siemens、Belden、InfluxData などの主要 AWSパートナーのソリューションが AWS 上でどのように運用を最適化できるかのデモもご覧いただけます。 エキスパートが提供する製造業向けセッション 製造業向けのトラックと、 約80の製造業タグが付けられたセッション では、先進的な製造業のお客様が AWS でデジタル変革を遂げている実例をご紹介します。お客様の実装事例に焦点を当て、AWS のソリューションが製造業のお客様のイノベーションとデジタル変革をどのように加速しているかを解説します。 製造業トラックでは以下の内容を予定しています: Ferrari、Panasonic Energy、Northvolt、Autodesk、Heidelberger Druckmaschinen などのお客様によるブレイクアウトセッション 技術的な深掘りセッション ハンズオンのワークショップとビルダーセッション エキスポホールでのNXPによるライトニングトーク イノベーションセッションで製造業の可能性を探る 製造・自動車の担当 VP であるウェンディ・バウアーがホストを務めるイノベーションセッション「AUT207-INT Manufacturing and Mobility Innovation in the Cloud」が11月28日(火)午前11時から正午までベネチアンで開催されます。このセッションでは、製造業の企業がクラウドを活用して運用を最適化し、時間を市場に投入を加速し、新たな収益源を創出する方法について説明します。イノベーションセッションでは、 Siemens が AWS を用いて産業オートメーション製品のイノベーションをどのように加速しているか、Honda が AWS を活用して製品開発、サプライチェーン、製造のイノベーションを加速しているかについて内部情報を提供します。 実際にイベントに参加する 製造業やその他の産業に従事されているお客様は、ぜひ re:Invent 2023 にご参加ください。下記のような様々な内容をご用意しています: re:Invent 2023のウェブサイト を確認して、イベントの最新情報を把握する 現地またはバーチャルでのイベントに 参加申し込み する AWS Industrial Attendee Guide を使用してカスタムのアジェンダを作成し、ショーでの体験を構築する 生成系 AI 関連プログラム を確認して、 生成系 AI に関する専門家のセッションやワークショップについて情報を入手する ラスベガスに後滞在されている間に、ベネチアンのエキスポホールにある Industries Pavilion に立ち寄り、AWS の製造および産業ソリューションについてもっと詳しく知る AWS re:Invent 2023 は、ビジネスを変革したい製造業のリーダーにとって必須のイベントとなることが期待されます。ぜひご参加ください! Scot Wlodarczak Scot は 2018 年 7 月に AWS に入社し、現在は製造業のマーケティング活動を管理しています。Scot はこれまで、シスコとロックウェル・オートメーションに勤務し、インダストリアル・マーケティング・マネージャーおよびリージョナル・マーケティング・リーダーを務めました。 Scot は、デジタル変革の過程にある産業界の顧客へのマーケティングと、IT と OT のギャップを埋めることに重点を置いてきました。 彼は幅広い業界でオートメーションの経験があります。 Scot は、ニューヨーク州立大学バッファロー校で機械工学の学位を、コロラド大学で経営学の修士号を取得しています。 コロラド在住。 本記事は AWS ブログ Unlock Your Factory’s Potential: An Inside Look at AWS re:Invent 2023 を翻訳したものです。翻訳はソリューションアーキテクトの山本が担当しました。

本記事は、製薬企業で 大規模言語モデル（LLM）の効果が大きく期待できる様々なユースケースについて業務部門毎に整理し、解説する3 部構成のシリーズの 3 つ目のブログ記事です。 パート 1 では、臨床開発でのデータクリーニング作業、メディカルライティングを始めとした文書業務の効率化について、ファーマコビジランス部門では AI アプリケーションを利用した SNS 上の有害事象を検知について説明しました。 パート2 では、メディカルアフェアーズ部門での社内レビュー業務の効率改善、マーケティング部門における医療関係者向け、患者さん向けの生成系 AI チャットボットの有用性ついて説明しました。この パート 3 では、責任ある AI 開発のためのアプローチについて解説し、それを実現するための AWS が提供する生成系 AI サービスについてご紹介します。 &nbsp; 責任ある AI 開発のためのアプローチ 生成系 AI は、企業内のデータを学習しチューニングすることで、ある特定の業務に特化した AI モデルを構築することができます。お客様はより直感的で正確な AI 体験を顧客に提供する、あるいは社内の文書業務の効率化を図ることができます。ただし、残念ながら生成系 AI も完璧ではありません。学習していない情報に関して正しい回答が行えないだけでなく、ハルシネーション（学習した情報にもとづかない回答）を提供してしまうという問題があります。 この重要な問題を低減するためには、現在、検索拡張生成 (RAG, Retrieval Augmented Generation) と呼ばれる手法を用いることができます。この RAG という手法を利用し、自社データに基づいて回答するようにクエリをチューニングすることで、モデルのハルシネーションを軽減できます。加えてエンドユーザーのコンテンツアクセス権限に応じて回答をフィルタリングする、つまり LLM 自体に特定の社内情報が追加学習されると、本来アクセス権限のない社員がその社内情報を取得してしまう可能性がありますが、RAG では社内情報へのアクセス自体を制限して問題を防ぐことができます。 RAG を使用して開発される AI アプリケーションは、エンタープライズリポジトリから、ユーザーのリクエストに最も関連する情報を取得し、それをプロンプトとしてユーザーのリクエストと共にコンテキストに含めて LLM に送信し、生成系 AI レスポンスを取得します。従って、質問のニュアンスに合った回答を生成する効果的な生成系アプリケーションの設計に重要なのは、RAG 設計の中で LLM がエンタープライズリポジトリから最も関連性が高く、簡潔なコンテキスト（質問の意図に最も合う社内情報）を受け取れるかどうかとなり、自社データベース内のコンテンツ検索が非常に重要なステップとなります。 Amazon Kendra は、機械学習を利用した検索機能を備え、ドキュメントや文章のランク付けを高精度に行うことができる完全マネージド型のエンタープライズ検索サービスです。 Amazon Kendra の高精度検索を利用することで、社内のリポジトリから最も関連性の高いコンテンツとドキュメントの検索を可能にし、その結果、RAG アプローチの質を最大限に高めることで、生成系 AI アプリケーションのパフォーマンスを改善することができます。キーワードベースの検索ソリューションを使用して得られる出力よりも、はるかに包括的、インテリジェントな検索手法で、ユーザーは本来の質問意図に準じた回答を得ることができるようになります。例えば、担当者が医学論文、他リージョンの先行事例、MR の活動情報、競合情報など、様々な形式（ワード、エクセル、パワーポイント、PDF、ウェブ）、多様な表現（テキスト、テーブル、グラフ）で格納されている社内の大量のデータから欲しい情報を特定したいといった場面を想像していただければと思います。このような場面で、従来のキーワード検索に感じているもどかしさに対して、RAG の手法は非常に有用であると言えます。生成系 AI を使ったエンタープライズ検索について興味のある方は、アストラゼネカ社の日本における取り組みを紹介した ブログ をぜひ参考ください。 &nbsp; AWS が提供する生成系 AI サービス ここでは、生成系 AI を活用するAWSのサービスとして、 Amazon Bedrock 、 Amazon SageMaker （ Amazon SageMaker JumpStart ）の二つを紹介したいと思います。 基盤モデルを使用して生成系 AI アプリケーションを構築およびスケーリングする最も簡単な方法 Amazon Bedrock は基盤モデルを使用して最も簡単に生成系 AI アプリケーションを開発、横展開できるサービスです。生成系 AI アプリケーションの開発を加速し、各種基盤モデルを単一 API からシンプルに利用することができます。インフラ管理が不要で、Amazon 自身が開発した基盤モデルから、最先端スタートアップが提供する AI21 Labs、Anthropic、Stability AI、Cohere、Meta などの幅広い選択肢から、お客様のニーズに沿ったモデルを選択することが可能です。自社データは非公開で基盤モデルを使用でき、生成系 AI アプリケーション開発を安全にカスタマイズすることが可能です。 Amazon Titan は、Amazon 自身の経験に基づいて磨き上げられた高性能な基盤モデルです。20 年以上の Amazon の機械学習活用経験と自社事業での稼働実績を強みとし、テキスト要約、生成、分類、情報抽出などの言語に関わるタスクを自動化することができます。また、不適切・有害なコンテンツ（ヘイトスピーチ、冒涜、暴力など）の出力を制限することで「生成系 AI の責任ある利用」をサポートしています。 機械学習 (ML) のハブとして、基盤モデル、組み込みアルゴリズム、および数回のクリックでデプロイできる事前構築済みの機械学習ソリューション Amazon SageMaker JumpStart は、すぐに基盤モデルを使いたい場合に利用できるサービスです。 Amazon Bedrock よりも数多くの基盤モデルを用意し、さらに幅広い選択肢の中から自社のアプリケーションに合ったモデルを組み込める環境を提供しています。ポピュラーな基盤モデルを数クリックするだけで稼働することができ、お客様が取り組まれている課題に対して、最適な基盤モデルはどれなのかを実際に試しながら選ぶことができるのが特徴です。 &nbsp; おわりに 今回の寄稿では、製薬企業内における生成系 AI の可能性、特に LLM の応用が大きく期待できる文書業務について事例を中心にまとめてきました。製薬企業の文書作成は、各企業の基本ルール、スタイルガイドや用語集が存在しており、その文書作成の“お作法”そのものが秘匿性の高い社内ノウハウとして保護すべき知的財産であるという側面があります。生成系 AI アプリケーションの開発には、いかにセキュアに構築された環境で社内ノウハウを最大限に利用するかが重要であり、そのアプローチの一つとして RAG は有用な手法と言えます。 さらに、生成される文章の精度に対し、社内レポジトリから最も関連性が高く簡潔なコンテキストを検索する能力を提供する Amazon Kendra は、RAG を利用した生成系 AI のアプリケーション開発には欠かせないツールと言えるでしょう。製薬企業の組織に存在する膨大な文書業務を考慮すれば、今後、生成系 AI がその業務プロセスに与える効率化の可能性は計り知れないでしょう。 &nbsp; 亀田　俊樹 (Toshiki Kameda) ヘルスケア・ライフサイエンス事業開発部 シニア事業開発マネージャー。 製薬業界で 20 年以上の経験を持ち、特にメディカルアフェアーズ、コマーシャルと製薬デジタル戦略（ DTx 含む）を得意としている。慶應義塾大学で医療政策・管理学の博士号を取得し、ポスドク研究員として医療データ分析、アウトカムリサーチを学びました。趣味はドライブと BBQ。

AWS は、2023 年 11 月 15 日 ( 水 ) 〜 2023 年 11 月 17 日 ( 金 ) にわたって幕張メッセで開催される Inter BEE 2023 に出展します。 ( 幕張メッセ 展示ホール 4 小間番号：4615 )。 AWS 展示ブースでは、「Create. Deliver. Monetize.」をテーマに、メディア制作から視聴者へ届けるまでのエンドツーエンドにおける 5 つのワークロード『コンテンツ制作』『放送』『メディアサプライチェーン』『 Direct-to-Consumer ＆ストリーミング』『データサイエンス &amp; AI/ML 』の各分野において、他の AWS のサービスやサードパーティーのアプリケーションと組み合わせ、高度にスケーラブルで伸縮自在かつセキュアなクラウドメディアソリューションを実演してご紹介します。 AWS パートナー展示コーナーの概要 展示ブースでは、 AWS パートナー 9 社に参加いただき、AWS クラウド上で構築および AWS サービスと連携し、AWS 展示ブース全体で、一気通貫なメディアワークフローを展示します。 パートナー各社の展示概要: S-01 : KKCompany Japan 合同会社 「動画の力でビジネスを動かす」企業向け動画配信プラットフォーム・BlendVision One をご紹介。また、AI に特化したコンサルティング / SI を提供するサービス・GoingCloud も同時展示いたします。 S-02 : 株式会社ユニゾンシステムズ クラウド営放（編成、営業、CM、放送）、番組入稿、自動作案などの開発事例展示。クラウドで共通化されたメディアワークフローと、放送局の主要業務における AI を活用する未来についてご紹介します。 S-03 : ソニーマーケティング株式会社 撮影～クラウド共有・コンテンツ管理～アーカイブまでのワークフローを、ワンストップサービスでご提供します。幅広いカメラや多彩なフォーマット・コーデックに対応しており、さまざまな関係者へのコンテンツ展開を、素早く対応することができます。 S-04 : ブライトコーブ株式会社 スマホからコネクテッド TV まで多様なデバイスに対して、高品質な動画ストリーミングと豊富なカスタマイズオプションを提供し、コンテンツの魅力を最大限に引き立てます。 S-05 : ATEME ATEME (アテメ)が提供する、集信から CDN までエンドツーエンドで対応した動画配信ソリューションを展示します。オンプレミス、クラウドなど、プラットフォームに依存しないデプロイメントを実現します。 S-06 : 東芝インフラシステムズ株式会社 AWS 上に展開したバンクアプリケーションや VIDEOS core によって、クラウド上でのマスター準備・送出運用を体感頂ける展示を行います。 S-08 : 株式会社トラフィック・シム クラウドマスターでご活用いただけるマルチビュー / 同録 / アナライズや新製品の電流モニタリングなど、「難しいをひも解く」トラフィック・シムのクラウドサービスを展示します。 S-09 : 株式会社 PLAY PLAY CLOUD の中からメディアサプライチェーンを支援する KRONOS DRIVE をご紹介します。 コンテンツレイク、ファイル共有、動画編集などさまざまな機能をデモを交えて展示します。 S-10 : 日本電気株式会社 制作現場のワークフロー改善を実現する、クラウド上での素材管理を展示。NEC の素材管理システムを AWS 上で実現し、実際の画面を見ていただくことが可能です。 AWS プレゼンテーションステージについて ブース内ミニステージでは、AWS パートナーおよび AWS によるプレゼンテーションをはじめ、お客様から現場運用でのクラウド活用について発表いただく予定です。各セッションのスケジュールについては以下を参照いただき、是非ご参加ください。 (登録不要) AWS ブースツアーについて AWS 展示ブースにお越しの皆様に AWS クラウドの活用シーンを深くご理解いただくべく、AWS パートナーのサービスをはじめ AWS 各展示の見どころをご紹介するツアーを行います。 日付: 2023 年 11 月 15 日（水）、16 日（木）、17 日（金） 時間: 11:00 / 14:00 / 16:00 (各回所要時間約 45 分間を予定) 定員: 各会 12 名まで (登録制) 是非 こちら よりご応募ください。 終わりに 今回は、Inter BEE 2023 の AWS パートナーをご紹介させていただきました。基調講演や特別講演、会社ごとのブースに関する情報は Inter BEE 2023 の 公式サイト からご確認ください。 皆様にお会いできるのを楽しみにしています！ 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog　(日本語) AWS Media &amp; Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 本ブログは BD 山口が担当しました。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 2023 年 11 月 23 日に AWSome Day Online Conference が開催されます。このイベントは、クラウドジャーニーのはじめの一歩として、AWS クラウドに関する基礎知識を 3 時間で学ぶ無償の初心者向けオンラインイベントです。AWS の概要、コンピューティング、ストレージ、データベース、ネットワーク、IoT、機械学習などを知識を幅広く身に付けられます。事前登録が可能となっておりますので、ぜひ興味のある方はご登録をよろしくお願いいたします。 それでは、先週の主なアップデートについて振り返っていきましょう。 2023 年 10 月 30 日週の主要なアップデート 10/30(月) AWS Elemental MediaTailor now available in seven additional regions AWS Elemental MediaTailor が大阪リージョンを含む 7 つの新しいリージョンで利用可能になりました。AWS Elemental MediaTailor は、複数の動画を 1 つのチャンネルに組み合わせたり、広告を挿入するなど、ライブ配信を支援する機能を提供するサービスです。このサービスを利用することで、チャンネルやその他のライブストリームを、様々なデバイスでパーソナライズされた広告とともに収益化し、視聴者にシームレスな体験を提供することができます。 Introducing eight new Amazon EC2 bare metal instances Amazon EC2 で、C7i、M7i、R7i、R7iz の新しいベアメタルインスタンスが利用可能になりました。M7i、C7i、R7i インスタンスは、AWS 向けにカスタマイズされた第 4 世代 Intel Xeon プロセッサーを搭載しています。同等の x86 ベースの Intel プロセッサーと比較して、最大 15% のパフォーマンス向上が図られています。このインスタンスは、オハイオ、バージニア、オレゴン、アイルランド、スペイン、ストックホルムの 6 つのリージョンで提供されています。R7iz インスタンスは、ターボクロック周波数が 3.9 GHz の Sapphire Rapids ベースのインスタンスとなっており、バージニアとオレゴンの 2 つのリージョンで提供されています。 AWS Trusted Advisor adds 64 new checks powered by AWS Config AWS Trusted Advisor が、AWS Config との統合により、「運用上の優秀性」カテゴリーで新たに 64 個のベストプラクティスチェック項目を提供開始しました。Trusted Advisor は、コスト最適化、パフォーマンス、セキュリティ、耐障害性、運用上の優秀性などのカテゴリーで、お客様の AWS 環境がベストプラクティスとどの程度乖離しているかをチェックし、継続的な改善に役立てることができるサービスです。この新しい 64 項目は、AWS Support の Business Support プラン以上で利用可能です。 10/31(火) AWS Elemental MediaPackage now available in Asia Pacific (Osaka) region AWS Elemental MediaPackage が大阪リージョンで利用可能になりました。MediaPackage は、動画配信時に様々なストリーミング形式にパッケージングすることで、携帯電話、パソコン、タブレット、ゲーム機など、多様なデバイスでの再生を可能にするサービスです。ライブ配信やオンデマンド配信の際に、スタートオーバー、一時停止、巻き戻しなどの一般的な動画機能を簡単に実装できます。また、デジタル著作権管理 (DRM) 技術を使って、コンテンツを保護することも可能です。 Amazon Athena announces one hour reservations for Provisioned Capacity Amazon Athena で、1 時間単位のキャパシティ予約が利用可能になりました。キャパシティ予約機能は、クエリ処理のための専用コンピュートリソースを確保するものです。これにより、ビジネスクリティカルなクエリーをほぼゼロレイテンシーでキューイングなしに処理できます。また、Athena の利用料金を固定化することでコントロールがやりやすくなるメリットもあります。アップデート前は最低 8 時間のキャパシティ予約が必要でしたが、今回のアップデートにより、最低 1 時間からのキャパシティ予約が可能になりました。東京を含む 8 つのリージョンで利用できます。 Amazon S3 Object Lambda now integrates with Amazon Athena Amazon S3 Object Lambda が Amazon Athena と統合され、Athena でクエリされる S3 データを自動的に変換できるようになりました。S3 Object Lambda を使用することで、S3 の GET、HEAD、LIST API リクエストに独自のコードを追加し、アプリケーションに返されるデータを変更できます。例えば、Athena でクエリを実行する際、Lambda 関数を使って機密データの列を自動的にマスクすることが可能です。 11/1(水) Amazon EC2 Capacity Blocks for ML Amazon EC2 Capacity Blocks for ML の一般提供が開始されました。これは、大規模な機械学習向けに設計された新しいタイプのキャパシティ予約の仕組みです。EC2 Capacity Blocks を利用すると、利用開始日と終了日を事前に指定し、その期間内に空きがあるか確認しながら GPU インスタンスのキャパシティを予約できます。既存の On-Demand Capacity Reservation が「現時点から」の予約に対して、EC2 Capacity Blocks は未来の日付で予約が可能なのが特徴です。現在、Amazon EC2 P5 インスタンスがオハイオリージョンで予約できるようになっています。利用にあたっては、予約期間は 1 日 ~ 14 日、予約インスタンス数は 1、2、4、8、16、32、64 台から選択する必要があるなどの制限があります。詳細は ドキュメント をご参照ください。 Amazon Redshift Multi-AZ is generally available for RA3 clusters Amazon Redshift で RA3 クラスタの Multi-AZ を一般提供開始しました。Redshift の Multi-AZ は、複数のアベイラビリティゾーンでデータウェアハウスを同時に実行し、不測の障害シナリオでも運用を継続しやすくする機能です。Multi-AZ により、Redshift の SLA が 99.99% に上がりました。ミッションクリティカルな使い方に対して、可用性の高い Redshift 環境をご利用頂けます。東京・大阪リージョンを含めた、25 リージョンで利用可能です。 Announcing new user roles for Amazon CodeCatalyst Amazon CodeCatalyst に、Power user、Limited access、Reviewer、Read only の 4 つの新しいユーザーロールが追加されました。Power user はプロジェクトの作成や AWS アカウントの追加ができます。Limited access はスペースメンバーのデフォルトロールで、プロジェクトの一覧表示ができます。Reviewer は Issue 機能の利用やプルリクエストの承認ができますが、ソースコードやワークフローの変更はできません。Read only はリソースの読み取りのみ可能で、作成・更新・削除はできません。 これらの新しいロールにより、アクションとプロジェクトへのアクセスをより細かくコントロールできるようになりました。 11/2(木) AWS IAM action last accessed information for more than 60 additional services AWS IAM で最後にアクセスしたアクション情報を確認する機能について、新たに 60 個の AWS サービスがサポートされました。最後にアクセスしたアクション情報を確認することで、使用されていない権限を発見し、許可するアクションのみ制限することがやりやすくなります。このアップデートで、AWS Auto Scaling、Amazon Redshift、Amazon Route 53 などのサービスが追加されました。 AWS Global Accelerator extends IPv6 support to dual stack NLB endpoints AWS Global Accelerator のデュアルスタックアクセラレータの機能を拡張し、デュアルスタックの ALB と EC2 に加えて、新たに NLB をサポートしました。デュアルスタックアクセラレータを利用することで、IPv4 と IPv6 の両方のネットワークトラフィックを、デュアルスタックの設定をしている NLB にルーティングできます。Global Accelerator は 2 つの静的な IPv4 アドレスに加えて、2 つの静的な IPv6 アドレスを持ちます。IPv6 を意識した環境を準備しやすくなるアップデートです。 11/3(金) AWS App Runner now supports Internet Protocol Version 6 (IPv6) for public inbound traffic AWS App Runner でパブリックなエンドポイントを構成する際に、IPv4 と IPv6 を同時に利用できるデュアルスタック構成をサポートしました。IPv4 と IPv6 の両方のクライアントは、App Runner のパブリックエンドポイントに直接アクセスが可能です。なお、プライベートエンドポイントは IPv4 のみサポートしています。パブリックエンドポイントからプライベートエンドポイントへ設定変更を行うと、IPv6 の通信が出来なくなるのでご注意ください。 2023 年 AWS re:Invent 速報 が事前登録開始になっています。AWS re:Invent の会期中に発表された新サービス・新機能を 1 時間で網羅してご紹介するものです。ぜひお見逃しの無いように事前登録をお願いします。 それでは、また来週お会いしましょう！ ソリューションアーキテクト 杉山 卓 (twitter – @sugimount )

本ブログでは2023年9月21日（木）に開催された、「現場の業務変革を実現するAI・データ活用(鉄道/運輸編・建設/プラント編)」のご講演サマリをお届けします。 1. JR九州の「AWS×データ分析」によるDX推進の取り組み 2. 電気設備に対する画像分類モデルの開発と生成AIを活用した異常画像生成の取り組み 3. 「建設デジタルプラットフォーム」によるデジタルデータ活用 4. ファストデジタルツインでちゃぶ台返し～保全の現場から市場を創る、ものづくりを変える～ 5. 現場業務変革を実現するAWSテクノロジー 　1. JR九州の「AWS×データ分析」によるDX推進の取り組み 資料ダウンロード 九州旅客鉄道株式会社様 (JR九州様)　からは、AWSとデータ分析を掛け合わせたDX推進の取り組みについてご紹介いただきました。 まず東村様より、JR九州様のグループ会社(JR九州グループ)としてのDX取り組みの経緯についてご紹介いただきました。 JR九州グループの組織として2019年に設立されたデジタル推進室では、当初、2030年までの長期ビジョンでデジタル技術の活用を推進していく想定でした。しかし、2019年以後のコロナウイルスの感染拡大により、リモートワークの増加、お客様のライフスタイル変化等により、JR九州グループは各ビジネス部門のDXやデータ活用の強化が早急に求められるようになりました。その対策として、JR九州グループDX戦略を策定し、2022年からDX戦略に沿った活動を開始されました。DX戦略の中の3つの目標として、お客様の体験価値の向上、オペレーション・メンテナンス改革、働き方改革・生産性向上を掲げられており、その目標の実現に向けて、様々な新技術の導入、クラウド・ネットワーク・ガバナンスなどの基盤整備、そしてDX推進人材の育成と体制強化への取り組みについて述べられていました。推進組織（CoE）だけに止まらず、各事業部に対してDXの専任となる人材を配置することで、CoEと各事業部の連携を強化し、DX推進を加速する仕組み作りが特徴的でした。 続いて、DX戦略のPJの一例として、データ分析プロジェクトについてお話をいただきました。データ分析PJは、JR九州グループ全体で専門チームを立ち上げられたプロジェクトで、2021年4月に、社内にどんなデータが保存されているかを一覧化してくことから取り組みを開始しました。一覧化したデータと各事業部でヒヤリングした結果に基づき、どのような分析と活用を実施すべきかを決めるテーマを洗い出し、2021年10月にデータ分析CoEの立ち上げと共にデータ分析がスタートしました。2022年4月には事業部専任の社員がアサインされ、現在では分析結果をベースにした業務やビジネスの構築と共に、社内外へのPJの発信にも注力されています。 データ分析PJを進めていく上で苦労したポイントは2点あり、1つはデータの把握でした。社内データは各課と各PJで細分化されており、どこにどのようなデータがあるのか、またそれぞれのデータの管轄はどこなのか不明で、それらを調べ一覧化することに非常に労力をかけることになりました。また、データの形式も非構造化データと呼ばれるデータが多く、活用できるデータなのかどうなのかを整理し、一覧化するところにも労力をかけることになりました。もう1つの苦労ポイントは分析チームの立ち上げ時で、今まで存在しなかったCoEといった枠組みに対し、新たに他部門からメンバーを選出するにあたり、関係各所への説明を実施して理解していただく必要がありました。こういった苦労がありながら、2021年に10月に分析PJチームを立ち上げが実現し、現在に至っております。 AWSを活用したデータ分析PJの事例として、動画データを活用した鉄道沿線設備の保全高度化と、販売データを活用した駅弁当の発注業務効率化の取り組みについて、それぞれ東村様と姫野様よりご紹介いただきました。本記事では、前者の事例についてご紹介いたします。 動画データを活用した鉄道沿線設備の保全高度化の事例についてご紹介します。JR九州様は、2020年4月より営業車両カメラシステムRED EYEを導入し、検査業務の一部効率化を行っておりました。しかし、このRED EYEのシステムは一部の検査を効率化するにとどまっており、活用幅の拡大が検討されました。そのためデータ分析PJとして、RED EYEシステムで取得できる前方の列車映像を活用し、既存のシステムでは検知できない「鉄道設備及び設備周辺の正常性」を保守社員が容易に確認できる業務支援ツールを内製開発で AWS 上に展開しました。支援ツールを用いた取り組みの内容についてお話します。まず事前に定期的に設備の周辺状況を確認したい画像データ群を用意し、定期的に録画されるRED EYEシステムの前方列車映像データから、それぞれの画像データに最も類似した動画フレームを抜き出します。それにより最新の設備周辺画像が抽出され、その画像のみを目視で確認することで、設備の状態を容易に確認でき、保全の計画や実施に役立てるといった取り組みになります。また、これらの画像データは、簡易Webアプリケーションを通して、保守担当社員が容易に確認できるようになっています。このシステムにより、例えば雑草繁茂によって視認しづらくなる設備の予兆検知が効率的に行えるようになりました。 姫野様より、生成系AIの活用についてもお話いただけました。JR九州グループは、「JR九州グループ共通 ChatGPT等生成AI利用ガイドライン」制定し、積極的な生成AIの活用を検討されているとのことでした。また、ガイドラインだけではなく、生成AIとはどのようなモノか、どのような使い道があるか、ガイドラインの要点は何か等をまとめた資料も展開し、日々の情報発信とあわせて社内での積極的な利用を推進されているとのことでした。具体的な生成AIの活用事例として、現在はJRキューポへのお客様お問い合わせメールの作成支援を提供しているとのことです。現在はローカルアプリによる提供となっていますが、社内の他のお問い合わせ業務への展開にむけて、AWSへの移行を検討されているとのことです。 最後に、データ分析基盤としてAWSを選択された理由と、今後についてお話いただけました。AWSを選択した理由は主に2つあり、1つ目はAWSには非常に多くのサービスが存在し、PoCも実施しやすいため、検証から本番活用までをスピーディに行える点でした。2つ目はJR九州様のDMP(Data Management Platform)基盤とJR九州グループの仮想環境基盤がAWSに存在しており、データ連係が行いやすい点でした。しかし、AWSのサービスを分析基盤として使用し始めて、まだ2年程度であるため、AWSをまだ活かしきれていないことを課題に感じておられました。今後は、よりAWSを活用してビジネスを加速させるため、Amazon S3を用いたDatalakeアーキテクチャ、Amazon SageMakerを筆頭とするAWSのAI/MLサービス、AWS IoTサービス、Amazon QuickSightなどの利用を検討されているとのことでした。 本登壇では、JR九州グループのDX戦略の全体像と取り組みをご紹介いただきました。また具体的なお話として、DX戦略の取り組みの1つであるデータ分析PJについて、事例を出しながらお話いただきました。JR九州様は、自社のデータとAWSを実際の業務に活用しながら、今後にも目を向けており、より一層自社データとAWSを活用していくことで、鉄道業界における様々な課題解決を目指しております。 2. 電気設備に対する画像分類モデルの開発と生成AIを活用した異常画像生成の取り組み 資料ダウンロード JR東日本情報システム様（JEIS様）からは鉄道の電気設備メンテナンス業務へのAI/ML活用についてご講演いただきました。この取り組みは鉄道の電気設備メンテナンスを鉄道事業者向けに提供されている東日本電気エンジニアリング様（TEMS様）様と共同で取り組まれています。 まず、電気設備に対する画像分類モデルの開発について方志様よりお話をいただきました。こちらは2023年5月のAWS Blogに寄稿いただいた「 Amazon RekognitionとAmazon SageMakerを組み合わせた効率的なAI開発 」を一段深掘りした内容です。外環検査時にメンテナンス現場で撮影した16の設備、13,000枚の画像を使い、Amazon RekognitionとAmazon SageMakerそれぞれの評価結果をご紹介いただきました。 分類対象となる設備は配線箱の内の配線自体が異なるものの、配線箱という大きなくくりで考えると特徴が似通っています。従来の教師あり学習を使った分類では対応できないのではないかという仮説を検証するためAmazon Rekognitionを利用した分類に取り組まれました。結果は1138枚のテストデータの内、996枚の画像判定に成功され概ね良い結果が得られました。 それぞれの設備個々の正解率に着目し結果を確認すると、特定の設備に関する正解率が低いことに気づきました。画像を確認すると、設備自体の形状は同じにもかかわらず用途の違いにより分類が異なりました。これらの設備は画像単体で見ると保守担当者でも分類の判断が難しく、画像から分類できないため別のアプローチを試みました。 別のアプローチでは画像という外形上の特徴だけでなく、撮影された時刻に着目し、前後の撮影された画像と共に外観以外の特徴を含む画像分類モデルをAmazon SageMakerを利用し開発をされました。このモデルはAmazon Rekognitionで判定が難しかった設備分類においても98％の分類精度を実現しました。総計の正解率ではAmazon Rekognitionの84%よりも高い95%の正解率を実現しました。 また、画像モデルだけでは分類を実際に利用したいTEMS様の作業に従事される方から直接利用することは難しいことに着目されました。サーバレスやマネージドサービスを活用したアプリケーション開発も行われ現場の方が利用しやすいWebアプリケーション作成も行われAI/MLサービスの利用から現場への展開までの一連のプロセスにおいてAWSを活用いただいていています。 稲森様からは、生成AIを活用した取り組みについてご発表いただきました。TEMS様のメンテナンス業務において、摂津日検査は大量の画像から異常を見つける作業であり、陣原の注意力に異存する作業となっています。業務を効率化するため異常を判定するAIを作ろうとすると、正常/異常の各データを用意しモデルを作り利用します。ただし鉄道設備における異常を記録する場合、鉄道設備の異常発生率が低いため、モデルをつくるに十分な異常データを準備できず少ない異常データでモデルを作成しても精度が上がらないという課題を抱えています。異常判定モデル作成に必要な異常データを、生成系AIを利用して生成し利用することで異常判定モデルの精度を高めるためことを目的に研究されました。 画像生成AIとしてStable DiffusionをAmazon SageMaker上で利用し、異常画像全体を生成するのではなく現存する電気配線の一部分だけをリアリスティックに異常を発生させるため、部分的な書き換えに特化したIn Paintingモデルを利用し構築しました。まず、Stability AI社のファンデーションモデルをそのまま利用し書き換えを試みたもののリアルな異常を安定的に生成することは困難でした。TEMS様が持つ実際の異常画像を加えて学習させ独自モデルを作り、再度検証するとリアルかつ、豊富な異常画像生成を可能としました。 本来の目的である異常画像を判定するためのモデルに必要なデータとして、生成系AIが作り出したデータの有効性を簡易的に検証するため、Amazon Rekognitionカスタムラベルにて検証されました。AIが生成した画像のみを使い学習させたモデルを利用し、実際の異常画像を分類したところ良好な結果を得ることができ、このアプローチは異常が少ない器機に対する異常判定モデルを作る際の手法として有用だと考えられます。研究に際し、Amazon SageMaker Studioをご利用いただきました。Amazon SageMaker Studioノートブックを複数並列で利用いただき効率的な開発も出来たとご評価いただきました。 鉄道インフラは数千キロに及ぶ設備のメンテナンスが日々行われることで安全・安心な輸送が実現されています。人口減少による少子高齢化が叫ばれる昨今、メンテナンス業務の省人化に向けたAIの開発にメンテナンス現場とIT技術者が協力して日々取り組まれていることに感銘を受けました。セッション後の質疑応答で方志様から課題を持っている事業者であるTEMS様が1万件以上ある画像にラベリングを実施されたことが今回成功した要因の1つとご紹介いただきました。利用者とIT技術者の二人三脚が鉄道のメンテナンス業務のこれからを作っていくのではないでしょうか。 3. 「建設デジタルプラットフォーム」によるデジタルデータ活用 資料ダウンロード 株式会社 竹中工務店 美里様からは“建設デジタルプラットフォームによるデジタルデータ活用”についてお話しいただきました。 まずは建設業界が直面している課題についてのご説明がありました。建設業界での課題として、一般的な日本の各種業界の課題に加えて、建設業ならではの課題があるという点について、数字根拠を含めて説明いただいています。キーワードとしては労働生産性・技能労働者不足・働き方改革。建設業に迫る避けられない課題が浮き彫りになります。 そしてこれらの課題に対して竹中工務店様では「新しいテクノロジーの活用」によって様々な取り組みに着手されています。その中からいくつかの取り組みをご説明いただきました。 最初にご説明いただいたのは登壇タイトルにもなっている建設デジタルプラットフォーム。デジタル活用が遅れていると言われることが多い建設業の中で、徹底した業務のデジタル化・デジタル活用を推進することで、生産性向上や生産性改革を推進するための仕組みとなります。 その他にもロボットの活用による労働環境改善や、新しい価値創造のためのスマートビル・オープンイノベーションといった取組による課題解決への動きをご説明いただいています。 後半では、建設デジタルプラットフォームを中心とした取組についてご紹介いただきました。建設デジタルプラットフォームは2021年11月より運用されており、事業に係る全てのデータを一元的に蓄積、AI等で高度利活用するための基盤と定義されています。データレイクのようなデータ基盤のみではなく、アプリケーション群と統合された基盤である点が特徴的です。アプリケーション群はIoT・BI・AIといったデータの高度利活用を担う部分になっています。 データ基盤についてはAWSのマネージドサービスを中心にした構成を取っていただいている部分も特徴の1つとなります。社内データはもとより社外データ・社外のサービス・前述のアプリケーション群との連携部分を含めて担う構成において、マネージドサービスの活用は非常に有効そうです。次にデータ集約・蓄積の機能についてご説明いただきました。まずは構造化データの集約・蓄積を整備し、活用できる状態にあるとのこと。今後は非構造データにも取り組む予定とのことです。非構造データの集約・蓄積・活用は注目度も高いと思いますので、今後の進化に期待したい部分です。基盤系の説明としては最後にIoT基盤についてのご説明をいただきました。一般的なIoT基盤と違い、都市OSなどの社外データ基盤との連携を視野に入れて、FIWAREを採用されている部分は特徴な部分では無いでしょうか。 そして基盤の次には実際のデータ活用の取り組みについていくつかご紹介いただきました。全社データ活用に向けた取り組みではデータ資産に対してのルールや体制整備に加えて、データ活用の民主化推進のための利用環境整備も実施しているというご説明がありました。データ活用ホームページの設置や、データカタログの整備など、利用者目線での取り組みは全社データ活用の大きな推進力の1つとなりそうです。またAIによるデータ活用についても具体的な例でご紹介いただいています。今回ご紹介いただいた例としては2点。1つ目は建物劣化診断。ファシリティマネジメントの領域で専門家の対応軽減を期待できる仕組みとして、適用範囲の拡大に現在も取り組まれているとのことでした。もう1つは安全情報分析。過去の労働災害データを元に、現在の作業所で予測される災害情報をAIで予測してアラートを出すという仕組み。各作業所での注意喚起に加えて、本社・本部での俯瞰管理用とでも活用されているとのことでした。 ※ AIを利用した建物劣化診断に関してはAWS Innovate -Data and Ai/ML Editionのオンデマンド配信にて、「 Amazon SageMakerを用いた建設業でのAIアプリ開発 」として佐藤氏よりご講演をいただいておりますのでこちらもご覧ください。 そして最後には更なるデータ活用への取り組みについてご紹介をいただきました。こちらも2つあり、1つ目は生成系AIなどの活用。最近話題の大規模言語モデル（LLM）の業務活用について検討・試行を進めておられるとのことです。生成系AIには大きな可能性を考えておられ、社内のデータサイエンティストにより組成されているアナリティクスチームを中心に業務部門を巻き込みながら取組を進めているとのこと。もう1つはデジタルツインの実現に向けての取組をご紹介いただきました。AWS IoT TwinMakerを活用した実際の画面等もご紹介いただいています。製造業では徐々に浸透を始めているデジタルツイン。建設業での実用にも期待がもたれます。 本登壇では幅広い形でデジタルデータ活用・デジタル変革への取組をご紹介いただきました。2024年に向けて大きな転換期を迎える建設業。竹中工務店様は建設デジタルプラットフォームを活用して、各種課題を解決していこうとされております。最先端技術の活用も含めて、今後の竹中工務店様の取組には注目が集まりそうです。 4. ファストデジタルツインでちゃぶ台返し～保全の現場から市場を創る、ものづくりを変える～ 資料ダウンロード ブラウンリバース株式会社 代表取締役 CEO 金丸様からは、“ファストデジタルツインでちゃぶ台返し〜保全の現場から市場を創る、ものづくりを変える〜”についてお話しいただきました。 プラント業界では、設備の高経年劣化、労働者不足、化石燃料設備統廃合や脱炭素などの市場変化へ対応をしなければならないことが経営課題となっています。また、現場目線で見ると人が少ないにもかかわらず、現場が遠く、広く、管理する設備の点数も多く、現場によっては中に入るたびに健康診断が必要であったり、クリーンルームを通る必要があったりと入るまでの手続きが多い状況になっています。このため、仮想空間上で三次元的に見られる仕組みがあると非常に助かるといった現場の声を聞きますが、今ある業界のツールを現場の設備管理の方が使うには機能が多すぎたり、自分の PC では動かないなどの理由でうまく使えてなかったりします。ブラウンリバース株式会社では Google Map のように直ぐに検索して使えるレベルの手軽さで設備管理の方が使えることを意識して INTEGNANCE VR の開発に取り組んでいます。 INTEGNANCE VR はファストデジタルツインをコンセプトに「いつでも」「どこでも」「誰でも」「すぐに」ご利用頂けるプラントの 3D マップ閲覧サービスで、圧倒的なモデル構築速度が売りの１つです。従来はレーザースキャナーを使ってモデル化しているが、三脚を立てて計測士がきちっと測って、エンジニアがプラントをモデル化していました。INTEGNANCE VR ではモビリティタイプのレーザースキャナーを利用して、400 m の競技場トラックぐらいのプラントであれば 1 日〜 2 日でスキャンし、翌日にはブラウザのビューワー上からお客様がプラントを確認できます。従来と比較して十分の一程度に提供時間を圧縮できます。また、スキャンした点群データや写真データは AWS に保管し、AWS 上のデータをリンクさせて、ビューワーをお客様のポータルのような使い方をしてもらって、図面を通してではなく、ブラウザを通してプラントの設備管理情報や整備記録をみたり、フランジ間の距離を測ったり、写真データにマーキングして情報共有したり、配管をナビゲーションする機能などを提供しています。 最後に産業界をひっくり返す２つのポイントについてもご説明頂きました。１つ目が、現場で見えているものと同じものが仮想空間にあるだけでは目的に到達するまでの時間や手間がかかり過ぎて敬遠される点で、紙ではできないタンクやタワーの断面を見られたり、重機の配置のシミュレーションが簡単にできると、現場の使い勝手が良いという話を頂けました。２つ目が、現場で色々な更新が行われていて、図面に落ちきっていないと、現場から図面に一所懸命に落とそうとして紙に縛られている点で、点群データなり写真データなりから検出した物体の前後関係を抽出して、図面に近い情報を引っ張り出して、機械が読み取れる情報に変換する仕組みができたら、紙から解放される世界ができるというメッセージをお伝えいただきました。 5. 現場業務変革を実現するAWSテクノロジー 資料ダウンロード 本セッションではAWS山下より現場の変革にAWSテクノロジーがお客様のデジタルトランスフォーメーション(DX)に、どのように貢献できるかについてお話しさせていただきました。 現場業務では、人、環境、セキュリティといった要素が課題として挙げられます。少子高齢化により労働集約的な資材配送業務で労働者の数が足りず、人件費の高騰が予測されます。環境といった側面では、温室効果ガス削減を前提としたオペレーションが求められています。鉄道・運輸や製造業・プラントはサイバー攻撃の対象とされる可能性が高いとされています。セキュリティ対応が義務化されていくという流れも見受けられます。 一方でこれらの課題を解決するためのDX推進活動において、避けられない課題もあります。鉄道・運輸の領域では膨大な器機からの大量データが集められているものの、保存されているだけで活動されていないとされています。製造業でもデータの90％は様々な環境に隔離されて保存されているという状況です。プラント業界でもデータの活用を進めているものの、実ビジネスに直結した活動は全体の30％程度と言われておりPoCの域を出ていません。やはりまだまだデータ活用に課題感があるのではないでしょうか。 DXの推進が進んでいないという訳ではなく、課題がありつつも進んでいるという認識です。DX白書ではアメリカの企業と比べて後れがあるものの20％以上の企業でAIやIoTが利用され、60％以上の会社でDXの成果が出ていると答えられています。日本において各社取り組みが進んでいるという認識です。 DX推進に必要なポイントとして、明確な課題、必要な技術、リスクを管理しながらチャレンジする環境が必要です。クラウドはこの3つの要素に対する解決策となり得ると考えています。スモールスタートで始められ、必要な時に必要なだけ利用できます。これによりアイディアから実装までの時間を短縮できると考えています。 産業分野の業務改善の流れとして、産業器機からの情報を取得するためのゲートウェイ、データの保管場所、データの可視化を行った上で、データを活用するという流れがあります。それぞれの領域においてAWSはサービスをご用意させていただいています。 本イベントでの講演で各社様が取り組まれていたAI/ML領域で、AWSは機械学習の開発者向け環境提供から、アプリケーションにAIを組み込む際に組み込みしやすいAIサービスをご用意しています。生成系AIのモデルは2018年より言語系だけで見ても数が増えており、AWSではコモディティ化が進むと考えています。Amazon Bedrockというサービスを発表しており、複数の企業が提供する基盤モデルから用途に最適なものを選択していただくことで、お客様に利用しやすい環境を提供するというコンセプトで開発しました。セキュリティに関しても様々なサービスをご用意しておりますのでぜひご利用いただければと思います。 関連記事リンク 【開催報告 ＆ 資料公開 】 鉄道業界向け DX セミナー 【開催報告】建設不動産 DX セミナー 建設業界パート 開催報告 この記事は以下のメンバーで担当しました。 竹川寿也 アマゾンウェブサービスジャパン合同会社 事業開発本部 シニア事業開発マネージャー 藤倉和明 アマゾンウェブサービスジャパン合同会社 技術統括本部 シニアソリューションアーキテクト 矢形拓也 アマゾンウェブサービスジャパン合同会社 技術統括本部 シニアソリューションアーキテクト 伊藤 一成 アマゾンウェブサービスジャパン合同会社 技術統括本部 ソリューションアーキテクト 村田 京介 アマゾンウェブサービスジャパン合同会社 技術統括本部 ソリューションアーキテクト 堀 竜慈 アマゾンウェブサービスジャパン合同会社 技術統括本部 アソシエイトリューションアーキテクト

前回の投稿 では、 Amazon Route 53 、 Amazon Relational Database Service (Amazon RDS) for SQL Server 、 Amazon Simple Storage Service (Amazon S3) を使用して、マルチリージョンのディザスタリカバリブループリントをデプロイしました。この記事では、AWS セカンダリリージョンで RDS for SQL Server を昇格させ、デプロイしたブループリントを使用してクロスリージョンフェイルオーバーを実行するプロセスについて説明します。 前回の投稿の簡単な振り返り 大まかに説明すると、次の手順を実行しました。 クロスリージョンリードレプリカで実行されている Amazon RDS for SQL Server データベースを確認します。 RDS インスタンスとのアプリケーション接続を設定するために Amazon Route 53 プライベートホストゾーン CNAME レコードを作成しました。 プライマリ AWS リージョンとセカンダリ AWS リージョン間のインターネットトラフィックを管理するように Amazon Route53 パブリックホストゾーンを設定しました。 ディザスタリカバリファイルをホストするために、両方のリージョンに個別の Amazon S3 バケットを作成しました。 パブリックドメイン名を使用してインターネットトラフィックの接続をテストしました。 このソリューションのアーキテクチャは、次の図に示されています。プライマリリージョンとセカンダリリージョンの両方が稼働している場合、Amazon Route53 はインターネットトラフィックをアクティブリージョン (この例では us-east-1 ) にルーティングします。インターネットトラフィックはパッシブリージョン (この例では us-east-2 ) にルーティングされません。 クロスリージョンフェイルオーバーに関する主な考慮事項: クロスリージョンフェイルオーバーを開始するには、さまざまな要因を十分に考慮する必要があります。考慮すべき重要な点をいくつか紹介します。 プライマリリージョンでアプリケーションが依存している 1 つ以上の AWS サービスが応答していないこと セカンダリリージョンにデプロイされたアプリケーション層は完全に更新され、主要な役割を引き受ける準備ができていること。Amazon Route 53 アプリケーションリカバリーコントローラーには、マルチリージョンの準備状況チェック機能があります。詳細については、 Amazon Route 53 アプリケーションリカバリーコントローラーの準備状況チェック を参照してください。 カスタマーサービスを回復する唯一の方法は、ライブトラフィックをセカンダリージョンに切り替えること セカンダリリージョンの RDS for SQL Server リードレプリカのレプリカラグは、ビジネスにとって許容可能な範囲 (RPO) を下回っていること。レプリカラグがゼロでない状態でクロスリージョンフェイルオーバーを開始すると、データが失われる可能性があります。詳細については、「 SQL Server リードレプリカの問題のトラブルシューティング 」を参照してください。 次の図は、ディザスタリカバリイベント中のアーキテクチャを示しています。 クロスリージョンフェイルオーバーの手順: イベントの順序に従って、このソリューションがどのように機能するかを見てみましょう。 ディザスタリカバリイベントを宣言し、SQL Server インスタンスのプライマリ RDS への書き込みを無効にします。 RDS for SQL Server クロスリージョンリードレプリカをセカンダリージョンのスタンドアロン DB インスタンスに昇格させます。 RDS for SQL Server リードレプリカの昇格が成功したら、 スモークテスト と呼ばれることが多いエンドツーエンドの検証を実施します。この検証プロセスにより、アプリケーションが正しく機能し、セカンダリ AWS リージョンで外部トラフィックを受け入れる準備ができていることを確認します。 ディザスタリカバリブループリントとともにデプロイされた Amazon S3 バケットにディザスタリカバリファイルを作成してアップロードします。Route53 パブリックレコードヘルスチェックの HTTP エンドポイントで指定されているのと同じファイル名を使用してください。 このファイルをアップロードすると、プライマリリージョンの Route 53 ヘルスチェックが失敗し、セカンダリリージョンへのフェイルオーバーが開始されます。 セカンダリリージョンへのフェイルオーバーが完了したら、アプリケーションスタックとデータベースの正常性を確認し、それらが正しく機能していて外部トラフィックを受信していることを確認します。このステップで、アプリケーションのダウンタイムは完了です。 セカンダリリージョンの RDS インスタンスを変更し、マルチ AZ オプションを有効にして、リージョン内の高可用性を再度有効にします。これは、RDS for SQL Server インスタンスにクロスリージョンリードレプリカを作成する際の前提条件でもあります。 AWS リージョンのプライマリリージョンが利用可能になったら、新しい RDS for SQL Server クロスリージョンレプリカを手動で作成して、クロスリージョンディザスタリカバリソリューションを再作成します。 Route53 のプライベートホストゾーン rds_sqlserver_private_hosted_zone を変更し、 rdsprimarydb.rds_sqlserver_private_hosted_zone CNAME レコードを更新して、プライマリリージョンに新しく作成されたリードレプリカを指すようにします。 フェイルオーバーの実装 クロスリージョンフェイルオーバーを開始するには、次の手順に従います。 ディザスタリカバリイベントを宣言し、プライマリリージョンの SQL Server インスタンスの RDS への書き込みを無効にします。アプリケーションがアクセスできる場合は、DR のフェイルオーバー中に現在のプライマリデータベースに誤って書き込まれないようにアプリケーションを停止します。 セカンダリリージョンでは、 Amazon CloudWatch メトリックスの Replica Lag を使用して SQL Server の RDS リードレプリカの遅延（ラグ）を確認します。この クエリ をプライマリデータベースで実行して、すべてのリードレプリカのレプリケーションラグに関する情報を取得することもできます。クロスリージョンのレプリケーションラグがゼロか、ビジネスで許容できる範囲 (RPO) を下回っている場合にのみ、次のステップに進んでください。レプリケーションラグがゼロでない状態でクロスリージョンフェイルオーバーを開始すると、データが失われる可能性があります。 Amazon Route 53 コンソール に移動します。 パブリックホストゾーンを選択し、ルーティングポリシーを確認します。 Amazon Route 53 ヘルスチェックダッシュボード に移動します。 プライマリリージョンのヘルスチェックレコード用の S3 ファイルエンドポイントの URL を書き留めておきます。この段階では、両方のリージョンのヘルスチェックの状態が正常である必要があります。 プライベートホストゾーン rds_sqlserver_private_hosted_zone に移動して CNAME エントリを確認します。セカンドリージョンのアプリケーションスタックは rdssecondarydb.rds_sqlserver_private_hosted_zone の CNAME レコードを使って RDS インスタンスに接続します。 セカンドリージョンで、RDS for SQL Server クロスリージョンリードレプリカを昇格させます。 AWS Lambda 関数 を作成して、このステップを自動化することもできます。参考となる Python コードは、この GitHub リポジトリ で見つけることができます。関数の作成手順については、 AWS Lambda 開発者ガイド を参照してください。 RDS for SQL Server インスタンスを昇格しても、RDS エンドポイント URL は変更されません。したがって、Route53 プライベートホストゾーンの CNAME レコードを更新する必要はありません。アプリケーションは、 rdssecondarydb.rds_sqlserver_private_hosted_zone レコードを使用して、昇格した RDS for SQL Server インスタンスに接続できます。 内部 スモークテスト またはアプリケーションの健全性チェックを実行してアプリケーションが正しく機能し、セカンダリリージョンでインターネットトラフィックを受け入れる準備ができていることを確認します。 セカンダリリージョンのアプリケーションスタックがインターネットトラフィックを受け入れる準備ができたら、フェールフェイルオーバープロセスを開始します。 手順 6 を参照してリカバリファイルの URL を取得します。このリカバリファイルをセカンダリリージョンの Amazon S3 バケットにアップロード します。この例では、ファイル名は initiate_failover.dr です。 このファイルを Amazon S3 バケットにアップロードすると、プライマリリージョンの Route53 ヘルスチェックが失敗します (Route 53 ヘルスチェックで ヘルスチェックステータスを反転する オプションを有効にしたことを思い出してください)。プライマリリージョンが異常とマークされると、Route53 はインターネットトラフィックのセカンダリリージョンへのフェイルオーバーを開始します。フェイルオーバーの遅延は、ヘルスチェック設定、 リクエスト間隔 、および 失敗しきい値 によって異なります。 フェイルオーバーが完了すると、アプリケーションはセカンダリ AWS リージョンでインターネットトラフィックの受信を開始します。 このステップではアプリケーションはダウンタイムから回復しますが、単一の AWS アベイラビリティゾーンで実行されます。リージョン内の高可用性をセットアップするには、セカンダリリージョンの RDS インスタンスを 変更 し、Amazon RDS for SQL Server のマルチ AZ を有効にします。 AWS プライマリリージョンが再び利用可能になったら、新しい RDS for SQL Server クロスリージョンリードレプリカを手動で作成して、クロスリージョンの災害復旧ソリューションを再作成します。 Route 53 プライベートホストゾーン rds_sqlserver_private_hosted_zone を更新し、新しい RDS for SQLServer クロスリージョンリードレプリカエンドポイントを使用して CNAME レコード値 rdsprimarydb.rds_sqlserver_private_hosted_zone を編集します。 次の図は、フェイルオーバー後の最終的なアーキテクチャを示しています。 後片付け このソリューションを実装するために作成されたリソースを削除するには、次の手順を実行します。 作成したパブリックおよびプライベートのホストゾーンを削除します。 アプリケーション構成を元の状態に変更します。 作成した Amazon S3 バケットを削除します。 まとめ この投稿では、アクティブ/パッシブ戦略を採用したマルチリージョン構成でデプロイされたアプリケーションのフェイルオーバープロセスについて説明しました。 Amazon Route 53 パブリックホストゾーンポリシーは、プライマリリージョンとセカンダリリージョン間のトラフィックをフェイルオーバーします。 Amazon Route53 プライベートホストゾーンポリシーは、適切なデータベースエンドポイントへのトラフィックのルーティングを処理します。これにより、アプリケーションが使用する統一された共通エンドポイントが提供され、障害時にアプリケーション構成を変更する必要がなくなります。 AWS Lambda 関数を使用して、RDS インスタンスの昇格に必要な手動タスクのスクリプトを作成できます。関数を 手動 でトリガーすることも、 イベントを使用する こともできます。 AWS アカウントでこのソリューションを試してください。 著者について Ravi Mathur は、AWS のシニアソリューションアーキテクトです。彼はお客様と連携して、さまざまな AWS サービスに関する技術支援やアーキテクチャに関するガイダンスを提供しています。彼は、さまざまな大規模企業でソフトウェアエンジニアリングとアーキテクチャの役割に数年間携わった経験を持っています。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。