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

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

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

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

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

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

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

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

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

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

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

この投稿はネットアップ合同会社 岩井 陽太郎 氏に、サイバーレジリエンスの解説と AWS における実装ポイントについて寄稿いただいたものです。 皆様はサイバーレジリエンスという言葉に聞き覚えはありますか？企業のデジタル化が進む中、ビジネスにおける IT 部門の担う責任は日々重くなってきています。これまではサイバーセキュリティの考え方に則った、被害をどう防いでいくかに焦点を当てた「防御」の考え方に大きく注目が集まっていましたが、際限のない投資が必要なことから「セキュリティ疲れ」とも呼ばれる反動が起きています。そこで昨今では「防御」だけではなく、被災することを前提としてそこからいかに迅速に「回復」・「復旧」するかという「サイバーレジリエンス」という考え方が注目を集めています。 本ブログシリーズでは、サイバーレジリエンスについて組織の重要な資産である「データ」の観点でご紹介していきます。第 1 回ブログでは、「サイバーレジリエンス」に関する基礎的な内容を解説します。 組織を取り巻く様々な事業継続リスク 皆様を取り巻く環境には、ビジネスの継続を困難にする多くのリスクが存在しています。特に日本では、大規模な自然災害のリスクと常に隣り合わせにあります。南海トラフ地震のような予測不可能な災害に備えなければならなかったり、地球温暖化による台風の大型化/強大化も懸念されています。また、昨今猛威を振るうランサムウェア攻撃に対して防御策を講じることや、年々規制が厳しくなっているコンプライアンスや法令違反のリスクへの備えも重要です。これらの事業継続リスクについて、もう少し掘り下げていきます。 自然災害リスク 自然災害には地震、津波、土砂災害、台風、豪雨、感染症の流行などさまざまな種類があり、どれも大きな脅威です。このような大規模な災害が発生した場合、ビジネスを継続させるためには復旧作業だけでなく、限られた人員での運用や予期せぬ業務にも対応する必要があります。 地震を例に挙げて説明します。まず被害として、建物の倒壊、機材の破損などが想定されます。物理的な修復作業はもちろん必要ですが、被災時には予想外の業務が頻繁に発生します。たとえば市役所の場合、地震が発生すると住民に対して罹災証明書を発行するという通常は行わない業務が一時的に必要になります。これらの業務は、被災した社員や職員自身が行わなければならないため、非常に困難な作業となります。 サイバー攻撃リスク 特に最近では、国内外でサイバー攻撃による被害が増加しており、多くの企業が重大な事業継続リスクとして認識しています。特に近年では、ランサムウェアによる被害が拡大しており、関心が高まっています。かつて、コンピュータウイルスが広まった時代には、「誰でもいいから困らせたい」という愉快犯的な行為が主流でしたが、現在ではダークウェブ上でのランサムウェア攻撃がビジネスとして成立してしまっており、ランサムウェアを使った身代金を要求する犯罪が組織的に行われています。具体的には、ランサムウェアを開発するグループや、攻撃対象となる組織の認証情報を盗むアクセスブローカー、彼らからランサムウェアや有効な認証情報を購入し、実際に攻撃を実行するグループなど、分業体制が確立されています。 コンプライアンスの遵守や法令違反のリスク General data Protection Regulation (GDPR) という規制をご存知でしょうか？GDPR は、欧州連合 (European Union: EU) におけるデータ保護に関する規則で、世界で最も厳しいとされており、罰金の金額は増加傾向にあります。このような規制には、ヨーロッパ在住のユーザーに対してサービスを提供している場合や、現地法人を持ち、現地の従業員が働いている場合など、本社が海外にあったとしてもヨーロッパに関連する事業に対して適用されるという注意点があります。実際、2022 年には日本の大手システムインテグレーターが現地法人によるデータ漏洩の違反で罰金を支払うケースがありました。 また、日本国内でもデータに関する規制は厳しくなっており、大きく二つの法改正が行われています。一つは個人情報保護法の改正です。2020 年に改正され、法人による報告や通知の義務化、措置命令違反や不正流用に対する罰則が強化されました (改正前は 30 万円以下、改正後は 1 億円以下) 。もう一つは、2022 年に改正された電子帳票保存法です。この改正により、電子取引に関する情報を紙ではなく電磁気的に記録することが義務化されました。データの活用が進む中で、プライバシーやコンプライアンスに関する規制もより厳しくなっています。このような規制の改正は、ビジネスにおいて金銭的および社会的な大きなリスクとなる可能性があるため、注意が必要です。 そしてサイバーレジリエンスの考え方へ 企業は、さまざまな事業継続リスクに対して対策を策定する必要があります。しかし、攻撃者にとっては一度でも攻撃が成功すればよく、防御側は常に守り続けなければなりません。そのため、際限のない投資が必要となるのと同時に、コストをかけても効果が保証されるわけではありません。また、そのような投資は事業利益を直接的に生み出すわけではなく、被害が起こらなければ投資対効果を定量的に示すことが難しい場合もあるかもしれません。このような状況から、組織は慢性的な「セキュリティ疲れ」に悩まされることが増えており、対応を後回しにすることもあります。 数年前より欧米を中心に、サイバーレジリエンスという「復元力」に焦点を当てたアプローチが注目されています。様々なリスクによる被害を受けないよう有効な防御策を講じることは重要ですが、サイバーレジリエンスの考え方は、「被災することを前提として、そこからいかに迅速に回復・復旧するか」に焦点を当てます。こうしたシステムを守るための考え方について、アメリカ国立標準技術研究所 (National Institute of Standards and Technology: NIST) は 2014 年に「レジリエンス」の考え方を盛り込んだ、Cybersecurity Framework (CSF) の 1.0 版を公開しました。この CSF では、以下の 5 つの機能をフレームワークの「コア」として定義しています。 Identify [識別]: リスクの特定と評価 Protect [防御]: 適切な保護対策の実施 Detect [検知]: セキュリティイベントの発生の識別 Response [対応]: 関係者間調整や分析、影響緩和や改善の実施 Recover [復旧]: システムや資産の復旧 これら 5 つの機能を分類すると、「識別」と「防御」は防御力に焦点を当てた従来の「サイバーセキュリティ」に関する部分にあたるのに対し、後半の「検知」「対応」「復旧」では万が一被災した場合に変化する状況に適応しながら迅速にシステムを復旧させる「復元力：レジリエンス」に焦点を当てた機能という事が読み取れます。 サイバーレジリエンスの手法と取り組み方 CSF の内容は汎用的なフレームワークであり、サイバーレジリエンスの概念や体制を包括的にまとめています。さらに、個別のテーマに応じた具体的な手法や手順をまとめている 「 SP800-160 Vol.2 : Developing Cyber-Resilient Systems: A Systems Security Engineering Approach 」 (以下、ガイドライン) があり、「サイバーレジリエンス」に関連する取り組みの「目的」「目標」「手法」について解説しています。 図 1: サイバーレジリエンスの「目的」「目標」「手法」 これら手法の定義はやや抽象的な表現が用いられていますが、このガイドラインでは、より実装に近い「取り組み方」についても提案しています。各手法の詳細な解説は省略しますが、データの観点での「復元力」に関連する以下の 3 つの手法について掘り下げてみます。 権限の制限 データの外部からの保護機能が充実していても、ユーザーにおける対策が不十分だと、リスクを未然に防ぐことはできません。具体的には「最小権限の原則」に従い、特権ユーザーである「root」や「Administrator」を共有せず、役割に応じて必要最小限の特権を個々のユーザーに与える「ロールベースのアクセス制御」や、場所や時間帯によるアクセス制限、パスワード漏えい・詐取による不正ログインに対して耐性を高めるための多要素認証 (Multi-Factor Authentication: MFA) などが挙げられます。また、管理者権限を持つ悪意のあるユーザーや偶発的な誤操作によるリスクを防ぐためには、「複数管理者認証機能」など、特定の操作に他の管理者の承認が必要な仕組みも効果的です。 分析的な監視 最近では、データを破壊する攻撃だけでなく、データの窃盗も頻繁に発生しています。このような被害を防ぐ手段としては、監査ログの取得と保全、複数の事象からの合的な攻撃検出、そして異常な振る舞いの検知などが挙げられます。監査ログは、攻撃の検出や原因究明だけでなく、被害範囲の特定とピンポイントな復元のためにも重要です。また、内部者によるデータの持ち出しなどの操作は、気づかれずに行われることが多いです。通常と異なるデータへのアクセスの仕方を検出してアクセスを自動的に遮断し、管理者に通報すると同時に、その時点でのデータバックアップを即座に取得するなどの仕組みも効果的です。 冗長化 最後に、データの観点でのレジリエンスにおいて最もイメージしやすく、非常に重要となってくるのがこの「冗長化」ではないでしょうか。 NIST が公開してるガイドラインには、「冗長化」への取り組み方が ３ つ示されています。 余剰容量（surplus capacity） 複製（replication） 保護されたバックアップとリストア（protected backup and restore） 具体的には、システムにおける性能・容量を余剰容量として換算し、安全マージンを施した設計・設定で運用したり、クラウドを活用した一時的な拡張によるクラウドバースト、サーバーの冗長化、サービス提供ロケーション（アベイラビリティゾーン）の冗長化、データのバックアップなどが当てはまります。特に重要な経営資源となる「データ」は、一度失うと復旧は容易ではなく影響が大きなものとなるため、バックアップつまりは「データの冗長化」が必要になります。 データの冗長化、言い換えると、データのバックアップ取得の必要性については、AWS が公開している データバックアップとは何ですか?  で整理されていますので引用したいと思います。 データのバックアップが重要なのはなぜですか? あらゆる組織はシステムが常に想定どおりに動作することを望んでいますが、分離されたシステムコンポーネントでは障害が発生する可能性があり、実際に障害が発生しています。まれにではありますが、システム全体での障害が発生する可能性もあります。データバックアップとは、障害が発生したときに復元できるように、組織のデータをコピーするインフラストラクチャ、テクノロジー、プロセスをいいます。これには、適切なデータバックアップ戦略とソリューションを含むディザスタリカバリ計画が含まれます。 効果的なデータバックアップにより、災害時におけるデータとシステムの損失を防ぎます。これは、想定外の状況であっても、ビジネスの継続性と中断のないサービスを実現するのに役立ちます。重要なビジネスシステムは、ビジネスに対する影響を最小限に抑えながら、運用を迅速に開始できます。 適切なデータのバックアップと復旧がなければ、システムは数時間、数日、または数週間にわたってオフラインになる可能性があります。状況によっては、エキスパートのデジタルフォレンジックの助けを借りても、まったく復旧できない場合があります。 データの冗長化（バックアップ）実践 データの冗長化（バックアップ）として良く知られた考え方として、「3-2-1 ルール」があります。この 3-2-1 ルールについても AWS が公開している データバックアップとは何ですか? から引用してご紹介します。 このルールは、どのような種類の障害が発生しても最大限の復旧可能性を得るためには、2 つの異なる種類のメディアに少なくとも 3 つのデータコピーが必要であり、1 つはオフサイトコピーである必要があるという旨を規定するものです。多くの組織は、3-2-1 ルールに従うことを選択しています。 バックアップを取得する際には、更に「バックアップしたデータの保護」についても留意すべきです。昨今のランサムウェア攻撃では、オリジナルデータを暗号化・改ざん・削除するだけでなく、バックアップからの復元を妨げるためにバックアップデータも破壊する事例も登場しています。特権ユーザーによる悪意のある操作でバックアップデータが破壊された事例もあり、削除できない保護されたバックアップ（Immutable Backup）を取得する必要があります。 また、バックアップデータからの復旧の「しやすさ」についても考慮しておく必要があります。特にランサムウェア攻撃からのデータ復旧では、「最新のバックアップデータを利用して、すべてのデータをリストアする」といった単純なものではなく、「暗号化されたファイルやフォルダはなにか」「どのユーザーや経路から攻撃されたのか」といった解析を行うデジタルフォレンジックをシステム・サービスの復旧と並行で行う必要があります。 このため「暗号化されてしまったデータを攻撃される前のバックアップデータを利用して、別の安全な環境にリストアすることでシステム・サービスを復旧する」といった復旧のしやすさが重要になります。 AWS でどのように実装するか 皆様が抱えている事業継続のリスクに応じ、サイバーレジリエンスの考え方に基づきシステムを迅速に復旧させる仕組みを実装していかなければなりません。現在、多くのお客様がオンプレミスとクラウド両方の環境をお持ちであることを考慮し、まずは変更や機能の追加が迅速かつ容易なクラウド環境から取り組み始めてはいかがでしょうか？ クラウドサービスを利用する上で事業者 (AWS) とお客様の間で様々な責任を共有することになるため、利用者は自身の責任範疇を明確に理解する必要があります。AWS では、一般的なクラウド上でのベストプラクティスを述べた AWS Well-Architected Framework を公開しています。その中でも、レジリエンスに関連する「信頼性の柱」について説明している 回復に関する責任共有モデル を参照するとよいのではないでしょうか。クラウドの回復性：サービスを実行するインフラストラクチャの回復性に責任を持つ AWS と、クラウド内での回復性：利用するサービスごとに適切な設定を実行する責任を持つお客様でお互いの責任を理解し、ベストプラクティスに則った信頼性の高いインフラの構築にお役立てください。 まとめ これまで IT の世界では、いかに脅威や災害からシステムを「防御」するかについての対策が取られてきました。しかし、サイバー攻撃手法の多様化や災害大国という立地から、すべての被害を防ぎきることが難しくなりつつあります。「防御」だけでなく、被害からいかに迅速に「復旧」するか、つまり「サイバーレジリエンス」を考えることが重要です。NIST が発表している CSF や SP-800 シリーズといったドキュメントを読み解き、どのようにデータの「復元力」を実現するか本ブログシリーズを通してご紹介していきます。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 いよいよ今週は AWS Summit Japan です！たくさんのセッションをはじめとする、学びの機会をご用意すべくAWS Japanのスタッフ一同で力を注いできました。もちろん生成AIに関するコンテンツも充実しています。私自身は特定のブースに立っているわけではないのですが、会場を歩き回っている予定ですので見かけたらぜひお声がけくださいね。 それでは、6 月 10 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: レアジョブテクノロジーズ様、英会話レッスンレポートのさらなる充実に生成AIを活用 レアジョブグループ 様が展開する「 レアジョブ英会話 」では、PCやスマホで様々な講師と英会話レッスンが受講できます。従来、英会話の講師がメモを残し、受講者に対してフィードバックを作成する作業を行っており、講師側の負担になっていたそうです。それを生成AIで解決する事を狙い、Amazon Bedrockを活用した生成AIによる「AIレッスンレポート」を開発されました。現時点では一部のお客様に限定して展開しているそうですが、利用者からは好意的な反応が得られているそうです。 builders.flashにも記事が出ています ので、こちらもあわせてご覧ください。builders.flashのほうはブログ記事よりももう少し技術的な詳細に踏み込んでいますので、両方見ていただくと理解が深まります。 AWS生成AI国内事例ブログ: ファーストトレード様、海洋情報APIとAmazon Bedrockで海況自動文書化を実現 ファーストトレード株式会社 様は「 なみある？ 」というサーフィンを楽しむ方に向けた波情報アプリを提供していらっしゃいます。これまで、手作業で海況情報を作成していましたが、作業の非効率性や品質のばらつき、情報入手コストの高騰が課題になっていました。これに対してAmazon Bedrockで生成AIを組み込むことで、海況情報文書の自動作成による課題解決に取り組みました。これによって、手作業が自動化され無人による文書生成、波情報のリアルタイム更新が可能になりました。また、AIによる高品質な波情報の提供が可能になるとともに、文書化のコストが80%削減されるという結果を確認されています。 AWS生成AI国内事例ブログ: KDDIアジャイル開発センター株式会社様、Amazon Bedrock統合によるチャットボットをグループ4社に展開 KDDIアジャイル開発センター株式会社 様では、日常業務への生成AIの積極活用を推進していらっしゃいますが、同時にセキュリティやシャドーITなどのコンプライアンスに関する懸念がありました。これを解決することを目的に、社内で利用しているSlackをインタフェースとしてセキュアに利用できる生成AI環境をAmazon Bedrockを利用して開発されました。セキュリティを担保するために全ての履歴とログを保存するとともに、サーバ側との通信にはパブリックなエンドポイントを経由しない通信方式を採用することで社内のセキュリティ監査で認められ、業務情報にも活用できる環境を構築できたとのことです。現在、KDDI Digital Divergence Holdingsグループ4社の約1,200名に展開しており、非エンジニアの方の利用も広がっているそうです。 AWS生成AI国内事例ブログ: JFEエンジニアリング株式会社様、建設業における業務効率化に生成AIを活用 JFEエンジニアリング株式会社 様は、生成AIを活用したプラットフォーム「Pla’cello xChat」を開発し、建設業における見積もり等の業務の効率化に取り組んでいらっしゃいます。2023年9月にリリースされたPla’cello xChatですが、11月に実業務に役立つユースケースの特定に着手され、PoCを通じて効果が確認できたものをアプリケーションとして実装する作業を進めていらっしゃいます。その一例が、見積書からのデータ抽出です。ある事業部では年間5,000時間を要しているそうです。今回、OCRと生成AIを組み合わせる事で高い精度でのデータ抽出が実現され、実際に使用した事業部のユーザーによれば見積もり比較業務の時間を数十パーセント削減できることが期待できるとのことです。 ブログ記事「誰でも簡単に生成AIを活用！AWS Japanメンバーが作ったPartyRockアプリ集」を公開 AWSが提供する「 PartyRock 」は画面操作と自然言語による指示だけで簡単に生成AIを組み込んだアプリを作成し、URL共有により誰でもアクセスできるようにする仕組みです。6/20-21に開催される AWS Summit Japan にむけて、AWS JapanのメンバーがPartyRockで開発したアプリをブログで公開しました。PartyRockはこの記事を執筆した時点ではAWSアカウントもクレジットカードも不要で、無料でご利用頂けますのでぜひトライしてみてください。AWS Summit Japanでは、AWS Villageの生成AIコーナーでPartyRockのブースも用意していますので、こちらもお見逃しなく。 ブログ記事「生成AIのマーケティング戦略への適用: 入門編」を公開 生成AIは様々な分野への応用が期待されていますが、そのひとつにマーケティング分野があります。このブログ記事は「生成AIのマーケティング戦略への適用」というシリーズを構成するひとつで、AI主導のコンテンツ生成と効果的なコンテンツ配信のためのマーケター向けポータルの構築について解説しています。 サービスアップデート Amazon SageMaker Canvasで利用した基盤モデルの本番環境への転用が容易に Amazon SageMaker Canvasから、基盤モデルをSagaMakerのリアルタイム推論エンドポイントにデプロイできるようになりました。SageMaker Canvasは様々な基盤モデルをもとに、検索拡張生成(RAG)によるモデルの応答のカスタマイズや、基盤モデルの微調整が可能です。SageMaker Canvasで作業した成果を、Amazon SageMakerのリアルタイム推論エンドポイントにデプロイする事で、本番で利用するアプリケーションに容易に組み込みが可能です。リアルタイム推論エンドポイントはフルマネージドで負荷に応じてスケーリングしますので、運用の手間も最小化できます。 Amazon CloudWatchで自然言語によるクエリ生成が可能に Amazon CloudWatch は、収集されたログとメトリクスを分析することで潜在する問題や改善箇所の発見を容易にします。今回のアップデートで、生成AIの技術を活用することによって自然言語でログやメトリクスを分析するクエリを生成できるようになりました。現時点では英語に対応する形ですが、例えば「過去24時間で最も遅かったLambdaへのリクエストを表示して」「最もスロットリングが発生しているDynamoDBのテーブルは？」といった質問に対して、蓄積されたデータに基づいた応答を返します。 AWS CloudTrail Lakeで自然言語によるクエリ生成が可能に AWS CloudTrail はユーザアクティビティとAPIの使用状況をログとして記録するサービスで、 AWS CloudTrail Lake はその情報に対してSQLライクの言語でクエリが可能な仕組みです。今回、生成AIの技術によって自然言語を利用した問い合わせが可能になりました。現時点では英語に対応しており「過去一週間のエラー数とその原因は？」「昨日マネジメントコンソールでログインしたユーザを一覧表示して」といったリクエストに応答してくれます。 AWS Audit Manager generative AI best practicesの対象サービスにAmazon SageMakerを追加 AWS Audit Manager はAWSの使用状況を継続的にチェックし、リスクとコンプライアンスの評価を容易にするサービスです。責任あるAIの利用は重要なテーマですが、AWS Audit Managerは生成AIに関する ベストプラクティスをまとめたフレームワーク を提供しています。発表当初はAmazon Bedrockが対象となっていましたが、今回Amazon SageMakerが対象に含まれました。このツールを利用することでBedrockやSageMakerを介した生成AIアプリケーションのベストプラクティス準拠状況の把握や、監査に必要な情報収集が容易になります。 ブログ記事 もご確認ください。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 いよいよ、日本最大の “AWS クラウドを学ぶイベント” 、 AWS Summit Japan が今週、木曜・金曜日に幕張メッセで開催されます。私たちもより良い内容でお届けできるよう、最後の準備をしているところです。以下のサイトより事前登録が可能です。私は初日の14:50～「オンプレミス上のデータを AWS クラウドの分析基盤に取り込む手法の整理」での登壇と、それ以外にも両日AWSのブース等に居る予定です。ぜひ当日は幕張でお会いしましょう！ – AWS Summit Japan | 2024 年 6 月 20 日（木）, 21 日（金） 幕張メッセ会場とライブ配信で同時開催 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年6月10日週の主要なアップデート 6/10(月) AWS IAM Access Analyzer now offers recommendations to refine unused access – AWS AWS Identity and Access Management (IAM) Access Analyzer で、未使用のアクセス（権限）を削減するための推奨事項が提供されるようになりました。権限の設定、検証、調整するためのツールが追加され、最小限の権限しか与えないベストプラクティスにそった設定がより容易に実現できるようになりました。 Amazon CloudWatch Application Signals, for application monitoring (APM) is generally available – AWS Amazon CloudWatch の OpenTelemetry（OTel）互換のアプリケーションパフォーマンスモニタリング（APM）機能である Amazon CloudWatch Application Signals の一般提供が発表されました。これにより、AWS上のアプリケーションのサービスレベル目標（SLO）に対するパフォーマンスの計測や追跡が容易になります。CloudWatch Application Signalsでは、重要なメトリクス（ボリューム、可用性、レイテンシー、障害、エラー）を示すダッシュボードも提供されるため、ユーザー側でダッシュボードを構築する必要がなく、手作業でダッシュボードを構築する必要がありません。 AWS CloudFormation accelerates dev-test cycle with adjustable timeouts for custom resources – AWS AWS CloudFormation で、サービスタイムアウトと呼ばれるカスタムリソース用の新しいプロパティが利用可能になりました。これによりカスタムリソースでのプロビジョニングロジックの実行の最大タイムアウトを個別に設定できるようになるため、例えば開発/テストサイクルにおけるフィードバックループを速くすることが可能になります。 Amazon CloudWatch announces AI-Powered natural language query generation – AWS Amazon CloudWatch で、生成AI を利用した自然言語クエリ生成の一般提供を発表しました。この機能により、ログやメトリックスデータに関連するクエリを平易な言葉をもとに生成できるようになりました。例えば”Which DynamoDB table is most throttled”(最もスロットルされた DynamoDB テーブルはどれですか)というような形で指示を出すことができます。これにより、クエリ言語に関する知識がなくても、観測したデータからインサイトを集めることが可能になります。この機能は現在、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京) リージョンで利用可能です。 6/11(火) AWS Identity and Access Management now supports passkey as a second authentication factor – AWS AWS Identity and Access Management (IAM) で、パスキーが2つ目の認証要素（多要素認証）としてサポートされました。パスキー(Passkeys)は FIDO 標準で規定された認証技術のひとつです。これにより、スマートフォン、Apple MacBook の Touch ID や Windows Hello など、機器に組み込まれたパスキー対応の認証システムを使って、安全にIAM認証を行うことが可能になります。 Detect malware in new object uploads to Amazon S3 with Amazon GuardDuty – AWS Amazon GuardDuty Malware Protection for Amazon S3 (Amazon S3 向けの Amazon GuardDuty マルウェア対策) の一般提供が発表されました。この機能は、Amazon S3 バケットに新しくアップロードされたオブジェクトをスキャンして、潜在的なマルウェア、ウイルス、その他の疑わしいアップロードがないかスキャンします。また、スキャンした結果によりタグが付けられるので、それを使ったアクセス制御を実行したり、 Amazon EventBridge 経由で通知を受け取って追加のアクションを実行することが可能です。 詳細はこちらのブログ をご覧ください。 AWS CloudTrail Lake announces AI-powered natural language query generation (preview) – AWS AWS CloudTrail Lake で AI を活用した自然言語クエリ生成機能がプレビューで利用可能になりました。CloudTrail Lake は CloudTrail のデータを蓄積し、SQLライクなクエリ言語で分析を可能にするサービスですが、このクエリを自然言語、例えば “Show me all users who logged in using console yesterday” (昨日コンソールを使用してログインしたすべてのユーザーを表示) といった形で指示を出すことで、クエリを生成することが可能です。 6/12(水) Productionize Foundation Models from SageMaker Canvas – AWS Amazon SageMaker Canvasから、基盤モデル (FM) をSagaMakerのリアルタイム推論エンドポイントにデプロイできるようになりました。SageMaker Canvasは様々な基盤モデルをもとに、検索拡張生成(RAG)によるモデルの応答のカスタマイズや、基盤モデルの微調整が可能です。SageMaker Canvasで作業した成果を、Amazon SageMakerのリアルタイム推論エンドポイントにデプロイする事で、より迅速な開発が可能になります。 Amazon OpenSearch Serverless now supports Internet Protocol Version 6 (IPv6) – AWS Amazon OpenSearch Serverless で、OpenSearch Serverless collectio のエンドポイントに Internet Protocol Version 6 (IPv6) が利用可能になりました。現在、東京リージョンを含む11のリージョンで利用可能です。 Amazon ElastiCache Serverless now supports snapshot and restore for Memcached – AWS Amazon ElastiCache Serverless に、Memcached のデータを自動的にバックアップ、リストアする機能が追加されました。保存されたスナップショットはサービス復旧時に有用なだけでなく、Amazon ElastiCache Serverless に複製を作成するためにも利用可能です。 6/13(木) （この日は、本ブログで取り上げる発表がありませんでした） 6/14(金) Cross-region failover now available in AWS Elemental MediaPackage – AWS AWS Elemental MediaPackage Live で、Amazon CloudFront 等のコンテンツ配信ネットワーク (CDN) を経由して配信している構成において、CDNと複数の AWS リージョンにある AWS Elemental MediaPackage Live オリジン間で透過的にフェイルオーバーできるようになりました。プライマリのストリームが古くなったり不完全だったりした場合に、ユーザーの視聴を中断することなくシームレスにバックアップオリジンにフェイルオーバーする構成が実現可能です。 最後に1つお知らせを。以前より何度か紹介していますが、 Aurora MySQL-Compatible Edition version 2 の標準サポート終了が今年の10月31日に迫ってきています。まだ V2 をご利用の方は以下の記事等を参考に Aurora MySQL-Compatible Edition version 3 への更新を検討してください。更新が10月末に間に合わない場合は RDS Extended Support での一時的な保守の延長も合わせてご検討ください。 – Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート 1 – Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート2 それでは、また来週！ 著者について 下佐粉 昭(Akira Shimosako) @simosako 2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。

複数の拠点に工場やプラントを持つ企業において、何千もあるモーターやポンプなど設備の保全タイミング管理は操業品質とコストに影響する重要な課題です。 AWS Japan ソリューションアーキテクトチームに所属する執筆者は、この課題に対するソリューションのデモを開発し、来る 2024 年 6 月 20 日、 21 日に開催する “ AWS Summit 2024 Japan “ にデモ展示します。デモは産業設備の予知保全サービス Amazon Monitron と AWS IoT SiteWise などのさまざまな AWS サービスを統合し、多拠点にある工場設備群の不良予知状況を可視化・スコア化して、 設備の健全性を一元管理するダッシュボードの展示です。このデモは、 Monitron が検知する設備の不良予兆状態を収集・蓄積し、拠点毎の健全性を評価します。そして保全が必要なタイミングで信号灯を点灯し、チャットアプリに通知して点検作業員を割り当てます。 このブログではこのデモで解決したい課題とユースケース、実現手法を二回に分けて解説します。 Part 1 では、主に開発したソリューションが解決する課題とデモの内容を解説します。 Part 2 ではデモの中で利用している各サービスの役割を解説します。 このブログを読んでいただきたい読者 工場、物流拠点、プラントを操業する企業の方、モーター・ベアリング・ポンプ・ファンなど多くの設備を稼働し、その保守・点検を改善することに課題をお持ちの方、そして、自社製の設備や製品の予知保全に関心を持つ方を想定しています。 本デモのユースケースと背景 本デモの想定するユースケースと背景は、AWS ブログ「 産業設備の予知保全サービス Amazon Monitron の紹介と、多拠点・大規模な設備群における保全効率化への取り組み 」にて説明しておりますので、御覧ください。 開発したデモが目指すもの 今回私達は、前述の大規模運用計画を支援するダッシュボードの概念を実際にデモンストレーションとして実演し、Amazon Monitron の予知保全機能が他のサービスや EAM (Enterprise Asset Management: 設備資産管理) システムと連携し、大規模な工場やプラントなど多拠点の設備保守に後付で予知保全機能を組み込めること、そして現場と全体管理者がコラボレーションして復旧に当たる運用を改善できることを示すことを目指しました。これにより、デモを見たユーザーは Monitron を活用した大規模な設備保全の効果、統合の難易度、運用への影響を理解し、より深く、検討をすすめることができます。 AWS Summit 2024 Japan イベントでは 3 種類のミニチュアファクトリーデモを展示します。そこで、私達はそれらのミニチュアファクトリーが日本の３箇所の離れた地域に存在すると想定して、全拠点の設備に Monitron センサーを配備し、各拠点の設備稼働状況を１つのダッシュボードで可視化・分析するソリューションを作ることにしました。 神奈川県川崎市：プロセス工場 大阪府：検査センター 山形県：組立工場 (図: 日本の 3 拠点に分散した工場を表現) さらに、私達は Amazon Monitron が設備保全タイミングを検知したことを視覚的に表現することで、現場での保全のイメージを具体化したいと考えました。そこで、拠点の健全性スコアが低くなったときに信号灯とチャットツールという２つの通知手段と連携するユーザーストーリーを考えました。 デモの内容 アクター (登場人物) として拠点全体を遠隔地から一元管理する「全体管理者」と各拠点に勤務し拠点の保全業務を行う「保全担当」を定義しました。ユーザーストーリーでは「全体管理者」と「保全担当」がソリューション実装を通じてお互いに情報を連携し、保全業務にあたることをストーリーを想定しました。下の図が、登場人物、設備、サービス全体の役割と行動を示したストーリーボードです。 (図: 多拠点工場群設備保全のストーリーボード)  多拠点・大規模な産業設備群の保全には多数の機器状態の効率的な把握や作業員との連携、 EAM と協調した機器交換計画の管理が必要になる場合があります。例えば、多数ある設備ごとに保全にかけつけるのは非効率的ですので、拠点ごとに現在保全が必要な機器数を知り、保全要員のスケジュールを決定したり、過去の保全履歴から不良の原因を分析し、保全マニュアルを改善したり機器交換のタイミングを計画します。また、予知保全により実際の不全より前に兆候を予知できる場合、保全作業に緊急性はなく、複数の作業をまとめることができます。 設備群管理ダッシュボード 多拠点にある多数の設備群を一元的に管理するためのダッシュボードには Amazon Managed Service for Grafana (AMG) を採用しました。AMG は時系列データをもとにした美しいダッシュボードを簡単・柔軟に提供できます。 過去の状況を確認できるよう、Grafana の GUI で表示期間を変更できるようにしました。 (図: 設備群管理ダッシュボードの画面) (図: ダッシュボードに表示する設備状態の項目) ダッシュボードのレイアウトは大きく 3 つの階層にわけました。管理者は画面の上から順に下に向かって視線を移動することで、より詳細な情報を分析できます。 プロジェクトビュー 上の階層は「プロジェクトビュー」として全拠点の健全性と過去の設備不良原因や対処内容の統計を表示します。左には地図があり、拠点の位置を表示します。中央には全拠点の健全性を表すスコアとスコアの時系列変化を示すグラフを表示します。右側には４つの円グラフがあります。この円グラフはそれぞれ、「拠点の状態の内訳」と、保守員が過去に Monitron アプリを使って報告した「障害モード」「障害の原因」「保守員が実行したアクション」の統計を表示します。スコアはサイトビュー各拠点の状態から計算式に基づいて算出します。スコアが一定値を下回ると、「複数の機器に異常の兆候が見られるため、メンテナンス作業の実施が必要」と判定し、保全要員への通知アクションを発生します。デモでは信号灯を点灯させ、チャットアプリへ保全要請を投稿します。 EAM と統合している場合は、 EAM でチケットを上げることができるでしょう。拠点に緊急の保全を要する設備がある場合はスコアが大きく下がり、より緊急性を要求する通知アクションを発生します。 サイトビュー 2 段目の階層は「サイトビュー」として各拠点の健全性と設備状態の分布を表示します。拠点ごとに 2 つの棒グラフと 1 つの円グラフがあります。 2 つの棒グラフは現在の拠点への保全の必要性を表しています。拠点内で一定数以上の設備で不良の予兆を検知した場合、棒グラフが黄色に変化します。円グラフは拠点内の全設備の状態の割合を表示します。すべてが正常であれば円グラフは緑色になります。 Monitron が設備の不具合予兆を検知していたり、すでに検知した後メンテナンス状態としたものは別の色で表示します。これにより、全体管理者は拠点の設備保全状態を確認できます。 設備ビュー 3 段目の階層は「設備ビュー」として、全拠点の全設備の状態と履歴を表示します。画面には 2 つの表があります。左の表は現在正常でない設備を表示します。例えば「不具合の予兆を検知 (Warning) 」「すぐに保全が必要 (Alarm) 」「メンテナンス中 (Need Maintenance) 」などです。右の表はこれまで発生した設備状態の変化の履歴を表示します。表示期間を変更したり、「拠点名」「設備名」といった表の項目でフィルタリングも可能です。 不具合箇所を特定したら、保守要員は Amazon Monitron アプリを用いてより詳細は設備状態 (振動や温度のグラフ、 Monitron が発生した不具合情報) を確認し現場で保全します。 デモンストレーション：拠点単位の保全推奨タイミングの判定と通知 イベント会場で私達は「検査センターにある複数の設備で不良予兆が検知された」というストーリーに基づいたデモを行います。具体的には以下のステップを再現します。 STEP 1 : はじめはすべての設備が正常状態で稼働しています。 STEP 2 : 検査センターにある複数の設備で “Warning” (不良の予兆を検知) が発生します。これにより、プロジェクトビューのスコアが低下します。その後、信号灯が点灯し、さらにチャットツールに保全を推奨するメッセージが投稿されます。監視者や保全要員はサイトビューや設備ビューを確認し、保全対象設備を特定します。 STEP 3 : 保全要員の担当者が決定すると、その保全要員はチャットアプリにある「私が担当します！」ボタンを押し、チームに保全を開始したことを知らせます。保全要員は Monitron アプリの「確認」ボタンを押します。これにより、ダッシュボードの設備は「NEED MAINTENANCE (保全中)」状態に変化します。 STEP 4 : 保全要員が現場で設備を点検し、適切な対処後に、 Monitron アプリに保全結果のフィードバックを入力し送信します。 フィードバックを受け取った Amazon Monitron は設備が正常な状態になったと解釈して状態を「正常 (Healthy) 」に変更し予知保全を再開します。 ダッシュボードは Monitron からの状態変化に連動してスコアを上げ、サイトビュー、プロジェクトビューの状態を変更するとともに、信号灯を消灯し、チャットアプリへ正常への変化を通知します。 Part 1 のおわりに このブログでは、2 部構成の Part 1として、主に開発したソリューションが解決する課題とデモの内容を解説しました。 このあとに続く Part 2 では開発したデモの中で利用している各サービスの役割を解説します。 より詳しく知るには この記事では、大規模・多拠点の設備を有する産業に向けた、設備群の不良予兆検知ダッシュボードとその実装構成について、 AWS Summit 2024 Japan で展示するデモンストレーションの内容を解説しました。 製造業を始めとする産業での AWS 利用について、実際の事例やリファレンスアーキテクチャを知りたい方は、 AWS の製造業に対する取り組み を御覧ください。 今回のデモで用いた各 AWS サービスの詳細はサービスの紹介ページを御覧ください。 Amazon Monitron (産業設備の不良予知保全) AWS IoT SiteWise (IoT データコレクター及びインタプリタ) Amazon Managed Service for Grafana (運用メトリクス、ログ、トレースのためのスケーラブルで安全なデータ視覚化) AWS IoT Events (イベントを検出し、対応) AWS Chatbot (チームチャットチャンネルから AWS のリソースを関し及び操作) AWS Lambda (イベント発生時にサーバーレスで処理を実行) Amazon Kinesis Data Streams (リアルタイム分析向けストリーミングデータサービス) AWS サービスについてより詳しく学びたい方は、 サービス毎のオンデマンドセミナー を公開しています。 パトライト社製品に関するご質問は、 パトライト社 のサイトからお問い合わせください。 今回のソリューションについて、自社の現場への導入にご興味のある方は、「 AWS に問い合わせする 」からお問い合わせください。 このブログについて このブログの内容は AWS Japan のソリューションアーキテクト 吉川晃平 、安田京太 、梶山 政伸 、三好史隆 、秦将之 、大井友三 が開発し、吉川晃平 が執筆しました。

アセットマネジメント業務において、ポートフォリオマネージャーは、リスクと機会を把握し投資判断を導くために、投資対象企業を綿密に監視する必要があります。決算報告書や信用格下げのような直接的なイベントを追跡することは簡単で、企業名を含むニュースに関する通知を設定することができます。しかし、サプライヤー、顧客、パートナー、あるいは企業のエコシステム内の他のエンティティでのイベントから生じる二次的・三次的な影響を検知することは難しいのが現状です。 例えば、主要ベンダーでサプライチェーンの混乱が発生すると下流の製造業者に悪影響を及ぼす可能性があります。また、主要クライアントで最大の顧客を失うとサプライヤーにとってデマンドリスクになります。このような出来事は、直接影響を受ける企業に注目が集まるほどの大きな出来事ではない場合が多い一方で注意を払う必要はあります。このブログでは、リアルタイムニュースとリレーションシップマップを照合するための、ナレッジグラフと 生成 AI (Generative AI) を組み合わせた自動化ソリューションを示します。 このソリューションには大きく 2 つのステップがあります。第一に、企業 (顧客、サプライヤー、取締役) 間の複雑な関係をナレッジグラフに構築します。第二に、このナレッジグラフと生成 AI を用いてニュースイベントがもたらす二次的・三次的な影響を検知します。このソリューションによって、例えばポートフォリオ内の自動車メーカーでサプライヤーのパーツ遅延が生産ラインへ影響を与える可能性があることを、直接の言及がなくても明らかにする事ができます。 AWS では、このソリューションをサーバーレス、スケーラブル、完全にイベント駆動なアーキテクチャでデプロイできます。このブログでは、グラフによる知識表現と自然言語処理に適した 2 つの主要な AWS サービス ( Amazon Neptune と Amazon Bedrock ) を使用した概念実証システムを紹介します。Amazon Neptune は、高度に接続されたデータセットで動作するアプリケーションを簡単に構築して実行できる、高速で信頼性の高いフルマネージド型のグラフデータベースサービスです。Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの主要な AI 企業の高性能な基盤モデル (Foundational Model: FM) を単一の API で提供するフルマネージドサービスで、セキュリティ・プライバシー・責任ある AI に配慮しながら生成 AI アプリケーションを構築するための幅広い機能を備えています。 全体として、このプロトタイプはナレッジグラフと生成 AI によって実現可能な技術、つまりさまざまな要素を結びつけてシグナルを導き出すことができることを示しています。これは、ノイズを避けて重要な情報の進展に常に注目できるという点において専門家にとって重要です。 知識グラフの構築 このソリューションの第一歩はナレッジグラフを構築することです。ナレッジグラフにとって価値があるが、しばしば見過ごされているデータソースが企業の年次報告書です。公式の企業出版物は発行前に精査されるため、その中に含まれる情報は正確で信頼できるものと考えられます。しかし、年次報告書は人間が読むことを想定した非構造化形式で書かれているため、機械で処理するにはふさわしくありません。この潜在力を引き出すには、その中に含まれる豊富な事実と関係性を体系的に抽出し、構造化する方法が必要になります Amazon Bedrock のような生成 AI サービスを使うことで、この処理を自動化できるようになりました。年次報告書を取り込み、小さな単位（チャンク）に分割し、自然言語処理を適用して重要なエンティティとリレーションシップを抽出する処理パイプラインを実行できるようになります。 例えば、「[ 企業 A] は [ 企業 B] から 1,800 台の電気バンを発注し、ヨーロッパでの電気配送車両の拡大を図った」という文章があれば、Amazon Bedrock は以下の情報を特定できます。 [企業 A] が顧客であること [企業 B] が供給者であること [企業 A] と [企業 B] との間がサプライヤー関係にあること 「電動配達バンのサプライヤー」というサプライヤー関係の詳細 非構造化文書から構造化データを抽出するには、企業や人物などのエンティティと、顧客やサプライヤーなどのリレーションシップを、テキストから抽出できるように適切に作成されたプロンプトを大規模な言語モデル (LLM) に対して与える必要があります。プロンプトには、注目すべき点と出力データの構造についての明確な指示が含まれています。この処理を年次報告書全体にわたり繰り返すことで、関連するエンティティとリレーションシップを抽出し、情報が豊富なナレッジグラフを構築できます。 ただし、抽出した情報をナレッジグラフに記録する前にまずエンティティの曖昧さを解決する必要があります。例えば、ナレッジグラフに既に別の「[企業 A]」エンティティがあっても、同名の別の組織を表している可能性があります。Amazon Bedrock では、ビジネスの重点領域・業界・収益を生む業界・他のエンティティとの関係などの属性の推論と比較によって、2 つのエンティティが実際に別物かを判断します。これにより、無関係の企業を 1 つのエンティティとして誤って統合することを防ぎます。 曖昧さの解決が完了すると、Amazon Neptune に格納されているナレッジグラフにエンティティとリレーションシップを追加して、年次報告書から抽出された事実によってナレッジグラフの持つ情報を拡充できます。時間が経つにつれて、信頼性の高いデータの取り込みや信頼性の高いデータソースの統合によって包括的なナレッジグラフが構築され、グラフクエリや分析によって重要な洞察が得られるようになります。 この生成 AI による自動化によって数千もの年次報告書を処理することが可能になり、手作業では非常に多大な労力が必要なために活用されなかったであろうナレッジグラフキュレーションのための非常に貴重な資産を活用できるようになります。 次のスクリーンショットは、 Graph Explorer ツールを使用して Amazon Neptune グラフデータベースで可能なビジュアル探索の例を示しています。 ニュース記事の処理 ソリューションの次のステップは、ポートフォリオマネージャのニュースフィードを自動的に充実させ、彼らの関心や投資に関連する記事を強調することです。ニュースフィードについては、ポートフォリオマネージャは AWS Data Exchange からサードパーティのニュースプロバイダやその他のニュース API を利用することができます。 ニュース記事がシステムに入ると、コンテンツを処理するためのデータ取り込みパイプラインが呼び出されます。年次報告書の処理と同様の手法を使用して、Amazon Bedrock はニュース記事からエンティティ、属性、リレーションシップを抽出します。その後、抽出された情報についてナレッジグラフに対して曖昧さを解決し、ナレッジグラフ内の対応するエンティティを特定します。 ナレッジグラフには企業と人物のリレーションシップが存在するので、記事内のエンティティを既存のノードにリンクさせることでポートフォリオマネージャーが着目している企業が 2 ホップ以内に含まれているかを特定できます。このようなリレーションシップが見つかるということは、記事がポートフォリオマネージャーに関連する可能性があることを意味します。また、基となるデータがナレッジグラフで表現されているため、ポートフォリオマネージャーがこの関連性の理由や仕組みを理解しやすいよう可視化することもできます。さらに、Amazon Bedrock を使えば、参照されているエンティティの感情分析も行えます。 最終的な出力は、ポートフォリオマネージャの関心分野や投資に影響を与えると思われる記事を表示するよう強化されたニュースフィードです。 ソリューション概要 ソリューション全体のアーキテクチャは次の図のようになります。 ワークフローは以下のステップで構成されています。 ユーザーが公式報告書 (PDF 形式) を Amazon Simple Storage Service (Amazon S3) バケットにアップロードします。ナレッジグラフに不正確なデータを含めないために、公式に発行された報告書である事が望ましいです (ニュースや週刊誌とは対照的です)。 S3 イベント通知が AWS Lambda 関数を呼び出し、S3 バケットとファイル名を Amazon Simple Queue Service (Amazon SQS) キューに送信します。First-In-First-Out (FIFO) キューを使用すると、報告書の受信処理が順次行われるため、ナレッジグラフに重複データが含まれる可能性が低くなります。 Amazon EventBridge の時間ベースのイベントが毎分実行され、非同期で AWS Step Functions ステートマシンの実行を開始します。 Step Functions ステートマシンは、一連のタスクを実行してアップロードされた文書から重要な情報を抽出し、ナレッジグラフに挿入します。 Amazon SQS からキューメッセージを受信します。 Amazon S3 から PDF レポートファイルをダウンロードし、複数の小さな文章チャンク (約 1,000 語) に分割し、それらの文章チャンクを Amazon DynamoDB に保存します。 Anthropic の Claude v3 Sonnet on Amazon Bedrock を使用して、最初のいくつかの文章チャンクを処理し、報告書が参照する主なエンティティと関連する属性 (業界など) を特定します。 DynamoDB から文章チャンクを取得し、各チャンクで Lambda 関数を呼び出して、Amazon Bedrock を使用してエンティティ (企業や個人など) とそのエンティティが主なエンティティとの関係 (顧客、サプライヤー、パートナー、競合相手、ディレクターなど) を抽出します。 抽出された全ての情報を統合します。 Amazon Bedrock を使用して、ノイズや無関係なエンティティ (「消費者」などの一般的な用語) を除去します。 Amazon Bedrock を使用して、抽出された情報とナレッジグラフ内の類似エンティティのリストを照合し、推論によって曖昧さを解決します。エンティティが存在しない場合は新規にインサートし、そうでない場合はナレッジグラフ内の既存のエンティティを使用します。抽出された全てのリレーションシップをインサートします。 クリーンアップとして、SQS キューメッセージと S3 ファイルを削除します。 ユーザーは React ベースの Web アプリケーションにアクセスし、エンティティ、感情、接続パスの情報を補足したニュース記事を表示します。 Web アプリケーションを使用して、ユーザーは監視する接続パスのホップ数 (デフォルト N = 2) を指定します。 Web アプリケーションを使用して、ユーザーは追跡するエンティティのリストを指定します。 フィクションのニュースを生成するには、ユーザーは Generate Sample News を選択して、ニュース受信プロセスに送信するランダムなコンテンツを持つ 10 件のサンプル金融ニュース記事を生成します。コンテンツは Amazon Bedrock を使用して生成され、完全に架空のものです。 実際のニュースをダウンロードするには、ユーザーは Download Latest News を選択して、本日のトップニュース (NewsAPI.org で提供) をダウンロードします。 ニュースファイル (TXT 形式) が S3 バケットにアップロードされます。手順 8 と 9 では、ニュースを自動的に S3 バケットにアップロードしますが、お好みのニュースプロバイダー (AWS Data Exchange やサードパーティのニュースプロバイダなど) との統合を構築して、ニュース記事をファイルとして S3 バケットにドロップすることもできます。ニュースデータファイルのコンテンツは <date>{dd mmm yyyy}</date><title>{title}</title><text>{news content}</text> の形式にする必要があります。 S3 イベント通知が S3 バケットまたはファイル名を Amazon SQS (標準) に送信し、複数の Lambda 関数を呼び出してニュースデータを並列で処理します。 Amazon Bedrock を使用して、ニュース内で言及されたエンティティとそれに関連する情報、リレーションシップ、感情を抽出します。 Amazon Neptuneに格納されているナレッジグラフを参照し、Amazon Bedrock を使用して曖昧さを解決します。ニュースとナレッジグラフからの情報を利用して推論し、対応するエンティティを特定します。 エンティティが特定された後、ナレッジグラフ内の INTERESTED = YES とマークされたエンティティへの N = 2 ホップ以内の接続パスを検索し、返します。 Web アプリケーションは 1 秒ごとに自動的に最新の処理済みニュースセットを取得し、Web アプリケーションに表示します。 プロトタイプのデプロイ プロトタイプのソリューションをデプロイして、自分で検証を始めることができます。プロトタイプは GitHub から入手でき、以下の詳細が含まれています。 デプロイの前提条件 デプロイのステップ クリーンアップのステップ 概要 このポストでは、ポートフォリオマネージャーがモニタリングしている企業への直接の言及がされていないニュースイベントによる 2 次リスクや 3 次リスクを検出するための概念実証ソリューションを紹介しました。Amazon Neptune に格納されている複雑な企業関係のナレッジグラフと、Amazon Bedrock を使ったリアルタイムのニュース分析を組み合わせることで、サプライヤーの問題による生産遅延などの影響の連鎖を明らかにすることができます。 このソリューションはプロトタイプにすぎませんが、ナレッジグラフと言語モデルが様々な要素を結びつけてシグナルを導き出す可能性を示しています。これらの技術は、リレーションシップのマッピングと推論により、専門家がリスクをより早く発見することを支援します。全体として、このソリューションは投資分析と意思決定を補助するための検証が必要なものの、グラフデータベースと AI の有望な応用例となっています。 この金融サービスにおける生成 AI の例がビジネスにとって興味深いものであれば、またはそれと同様のアイデアがあれば、AWS アカウントマネージャーにご連絡ください。 本ブログはソリューションアーキテクトの三厨が翻訳しました。原文は こちら 。 著者について Xan Huang はシンガポールを拠点とするAWSのシニアソリューションアーキテクトです。主要な金融機関と協力し、クラウド上で安全で、拡張性が高く、高可用性のソリューションを設計および構築しています。仕事の合間には、ほとんどの自由時間を家族と過ごし、3歳の娘に振り回されています。 Xan の  LinkedIn はこちら。

AWS の Amazon Elastic Kubernetes Service (Amazon EKS) を使用してアプリケーションをモダナイズする際、ユーザーはしばしばスケールに伴う IPv4 アドレス空間の枯渇という深刻な問題に直面します。ユーザーは、運用の複雑さを増やすこと無く、EKS 上の Pod に割り当てられた VPC の CIDR とサブネットをできる限り活用したいと考えています。IPv6 アドレス空間の利用が、スケーラブルなネットワークソリューションを構築するための長期的な解決策になると考えられています。しかし、他のネットワークコンポーネントやアプリケーションの IPv6 サポートの制約から、Amazon EKS ユーザーは IPv4 環境を強いられている可能性もあります。そこで、Amazon EKS ではネットワーク設定を合理化し、運用の複雑さを増やすことなく IPv4 ベースのクラスターをスケーリングできるように、拡張サブネットディスカバリーのサポートを導入しました。 どのように機能するか EKS クラスターの各 Amazon Elastic Compute Cloud (Amazon EC2) ワーカーノードに Amazon VPC Container Network Interface (CNI) プラグイン がデプロイされています。このプラグインは、ワーカーノードに Elastic Network Interface (ENI) を作成して接続するとともに、EKS クラスター内の各 Pod に VPC CIDR からプライベート IPv4、IPv6 アドレスを割り当てます。デフォルトでは、VPC CNI はワーカーノードのプライマリ ENI と同じサブネットから Pod に IP アドレスを割り当てます。これは時々、「利用可能なサブネット」と呼ばれます。追加の設定を行わない場合、ワーカーノードは EC2 インスタンスが起動された「利用可能なサブネット」から ENI を接続できます。VPC CNI の新しい機能により、「利用可能なサブネット」の範囲が拡張されました。拡張サブネットディスカバリーを有効にすると、利用対象としてタグ付けされた VPC 内のすべての提供可能なサブネット/CIDR から Pod の IP アドレスが自動的に割り当てられるようになります。 新しいサブネットを作成して、「kubernetes.io/role/cni」という特定のタグを付与することで、既存のネットワーク設定にシームレスに統合されます。この機能により、継続的な運用の中断を最小限に抑えつつ、アプリケーションを効果的にスケーリングできるようになります。 前提条件 この機能を利用するための前提条件は以下の通りです。 AWS アカウント バージョン 1.25 以降の EKS クラスター (ウォークスルーでは v1.29 を利用) バージョン 1.18.0 以降の Amazon VPC CNI 利用しているデバイスにインストール済みの最新バージョンの AWS Command Line Interface (AWS CLI) 、または AWS CloudShell eksctl – EKS クラスターの作成と管理を簡単に行うことができる CLI ツール (バージョン 0.165.0 以降) セットアップ export AWS_REGION= #Replace with your AWS Region export AWS_ACCOUNT= #Replace with your AWS Account number export CLUSTER_NAME=eks-enhsubsel-demo #Replace with your EKS cluster name このウォークスルーでは、/24 の CIDR ブロック (256 個の IP アドレス) を持つ Amazon VPC を作成し、IP アドレス枯渇のシナリオをシュミレーションします。この VPC は、3 つのパブリックサブネットと 3 つのプライベートサブネットに分かれており、それぞれ /27 の CIDR ブロック (28 個の IP アドレス) が割り当てられています。これは、次の図のような構成になります。VPC の CIDR ブロック内の IP アドレスが枯渇した後、VPC にセカンダリ CIDR を関連付けます。その後、「kubernetes.io/role/cni」タグを付与した VPC サブネットを作成します。これにより、VPC CNI が新しいサブネットを自動的に検出し、 Pod に IP アドレスの割り当てができるようになります。 図 1: Amazon VPC のセットアップ 次に、バージョン 1.18.0 の VPC CNI がインストールされた EKS クラスターを作成します。 cat << EOF > cluster.yaml apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: ${CLUSTER_NAME} region: ${AWS_REGION} version: "1.29" vpc: cidr: 10.0.0.0/24 addons: - name: vpc-cni version: 1.18.0 - name: coredns - name: kube-proxy managedNodeGroups: - name: ${CLUSTER_NAME}-mng instanceType: m6a.large privateNetworking: true minSize: 2 desiredCapacity: 2 maxSize: 5 EOF eksctl create cluster -f cluster.yaml クラスターの作成が完了するのを待ち、vpc-cni アドオンがクラスター内で実行されていることを確認します。 aws eks describe-addon --addon-name vpc-cni --cluster-name $CLUSTER_NAME --region $AWS_REGION { "addon": { "addonName": "vpc-cni", "clusterName": "eks-enhsubsel-demo", "status": "ACTIVE", "addonVersion": "v1.18.0-eksbuild.1", .... } } サブネットには /27 の CIDR が割り当てられているため、プライベートサブネットでは利用可能な IP アドレスがほとんどまたは全くないことに注目します。 aws ec2 describe-subnets --region $AWS_REGION \ --filters Name=tag:Name,Values="eksctl-eks-enhsubsel-demo-cluster/SubnetPrivate*" \ --query "Subnets[].{VPC:VpcId,SubnetId:SubnetId,AvailableIPs:AvailableIpAddressCount}" \ --output table ----------------------------------------------------------------------- | DescribeSubnets | +--------------+----------------------------+-------------------------+ | AvailableIPs | SubnetId | VPC | +--------------+----------------------------+-------------------------+ | 16 | subnet-08411e385d62f29da | vpc-07f75e9b1d954689a | | 7 | subnet-0755097835150b642 | vpc-07f75e9b1d954689a | | 0 | subnet-0975a78066e7e76d6 | vpc-07f75e9b1d954689a | +--------------+----------------------------+-------------------------+ サンプルアプリケーションをデプロイし、EKS クラスター内で IP アドレス枯渇のシナリオをシュミレーションします。 cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: inflate spec: replicas: 50 selector: matchLabels: app: inflate template: metadata: labels: app: inflate spec: terminationGracePeriodSeconds: 0 containers: - name: inflate image: public.ecr.aws/eks-distro/kubernetes/pause:3.7 resources: requests: cpu: 50m EOF サブネット内の IP アドレスが不足しているため、Amazon VPC CNI が IP アドレスを割り当てることができず、多くの Pod が「ContainerCreating」状態であることに注目します。次に、VPC CNI の拡張サブネットディスカバリーの機能を使って、割り当て可能な IP アドレススペースを持つ新しい VPC サブネットを自動検出し、Pod に IP アドレスを割り当てる方法を確認します。 Amazon VPC は最大 5 つのセカンダリ CIDR ブロックをサポートしており、これにより VPC の IP アドレススペースを拡張できます。まず、Amazon EKS を作成した VPC にセカンダリ CIDR ブロック「10.1.0.0/16」を追加します。 export EKS_VPC_ID=$(aws eks describe-cluster --name $CLUSTER_NAME \ --region $AWS_REGION --query "cluster.resourcesVpcConfig.vpcId" --output text) aws ec2 associate-vpc-cidr-block --vpc-id $EKS_VPC_ID \ --cidr-block "10.1.0.0/16" --region $AWS_REGION { "CidrBlockAssociation": { "AssociationId": "vpc-cidr-assoc-06515a22930a5d6e9", "CidrBlock": "10.1.0.0/16", "CidrBlockState": { "State": "associating" } }, "VpcId": "vpc-07f75e9b1d954689a" } セカンダリ CIDR ブロックの関連付けが完了するのを待ってから、セカンダリ CIDR ブロックから新しい VPC サブネットを作成します。また、VPC CNI がこれらのサブネットを自動検出できるように、サブネットに「kubernetes.io/role/cni=1」タグを付与します。 aws ec2 create-subnet --vpc-id $EKS_VPC_ID --region $AWS_REGION \ --availability-zone "$AWS_REGION"a --cidr-block 10.1.0.0/19 \ --tag-specifications "ResourceType=subnet,Tags=[{Key=kubernetes.io/role/cni,Value=1}]" aws ec2 create-subnet --vpc-id $EKS_VPC_ID --region $AWS_REGION \ --availability-zone "$AWS_REGION"b --cidr-block 10.1.32.0/19 \ --tag-specifications "ResourceType=subnet,Tags=[{Key=kubernetes.io/role/cni,Value=1}]" aws ec2 create-subnet --vpc-id $EKS_VPC_ID --region $AWS_REGION \ --availability-zone "$AWS_REGION"c --cidr-block 10.1.64.0/19 \ --tag-specifications "ResourceType=subnet,Tags=[{Key=kubernetes.io/role/cni,Value=1}]" デフォルトの設定では、VPC CNI は Amazon EKS ワーカーノードのプライマリ ENI に関連付けられた VPC サブネットから、ENI のプライマリ IP アドレスとセカンダリ IP アドレスの両方を割り当てます。 aws ec2 describe-network-interfaces --region $AWS_REGION \ --query "NetworkInterfaces[*].{ID:NetworkInterfaceId,DNSName:PrivateDnsName,PrimaryIP:PrivateIpAddress,SecondaryIPs:PrivateIpAddresses[].PrivateIpAddress}" \ --filters Name=tag:cluster.k8s.amazonaws.com/name,Values=$CLUSTER_NAME \ --output table -------------------------------------------------------------------------------------- | DescribeNetworkInterfaces | +-------------------------------------------+-------------------------+--------------+ | DNSName | ID | PrimaryIP | +-------------------------------------------+-------------------------+--------------+ | ip-10-0-0-155.us-west-2.compute.internal | eni-07f66d0e6b2408fc7 | 10.0.0.155 | +--------------------------------------------+------------------------+--------------+ || SecondaryIPs || |+-----------------------------------------------------------------------------------+| || 10.0.0.155 || || 10.0.0.136 || || 10.0.0.140 || || 10.0.0.141 || || 10.0.0.145 || || 10.0.0.150 || || 10.0.0.135 || || 10.0.0.151 || || 10.0.0.148 || || 10.0.0.149 || |+-----------------------------------------------------------------------------------+| ......... |+----------------------------------------------------------------------------------+| | DescribeNetworkInterfaces | +--------------------------------------------+-------------------------+-------------+ | DNSName | ID | PrimaryIP | +--------------------------------------------+-------------------------+--------------+ | ip-10-0-0-102.us-west-2.compute.internal | eni-087692b80786865e0 | 10.0.0.102 | +--------------------------------------------+-------------------------+--------------+ || SecondaryIPs || |+-----------------------------------------------------------------------------------+| || 10.0.0.102 || || 10.0.0.105 || || 10.0.0.110 || || 10.0.0.126 || || 10.0.0.124 || || 10.0.0.125 || || 10.0.0.118 || || 10.0.0.100 || || 10.0.0.116 || || 10.0.0.117 || |+-----------------------------------------------------------------------------------+| Amazon VPC CNI アドオンの環境変数「ENABLE_SUBNET_DISCOVERY」を確認して、新しい拡張サブネットディスカバリーの機能が有効になっているか確認します。kubectl を利用してこれを確認します。 kubectl describe ds aws-node -n kube-system | grep ENABLE_SUBNET_DISCOVERY ENABLE_SUBNET_DISCOVERY: true この記事の執筆時点では、拡張サブネットディスカバリーの機能は バージョン 1.18.0 以降のAmazon VPC CNI でデフォルトで有効になっています。環境変数が true に設定されていない場合は、kubectl または AWS CLI を使って設定することができます。 kubectl set env daemonset aws-node -n kube-system ENABLE_SUBNET_DISCOVERY=true \ -c aws-node または、 aws eks update-addon --cluster-name $CLUSTER_NAME --region $AWS_REGION \ --addon-name vpc-cni \ --configuration-values '{"env":{"ENABLE_SUBNET_DISCOVERY":"true"}}' この機能を有効にすると、VPC CNI は「kubernetes.io/role/cni」タグが付与された割り当て可能な IP アドレススペースを持つ VPC サブネットを探します。そして、それらのサブネットから追加の ENI を Amazon EKS ワーカーノードに接続し、Pod に IP アドレスを割り当てられるようにします。ウォークスルーでは、多くの Pod が「ContainerCreating」の状態だったため、VPC CNI は /19 の CIDR である新しいサブネットを自動的に検出し、既存のワーカーノードにそれらを接続しました。次のコマンドでこれを確認します。 kubectl get pods -o wide | grep ContainerCreating <<EMPTY OUTPUT>> ワーカーノードに接続されている ENI を確認すると、セカンダリ CIDR サブネットから追加の ENI が接続されており、Pod に 10.1.x.x の IP アドレス範囲が割り当てられていることがわかります。 aws ec2 describe-network-interfaces --region $AWS_REGION \ --query "NetworkInterfaces[*].{ID:NetworkInterfaceId,DNSName:PrivateDnsName,PrimaryIP:PrivateIpAddress,SecondaryIPs:PrivateIpAddresses[].PrivateIpAddress}" \ --filters Name=tag:cluster.k8s.amazonaws.com/name,Values=$CLUSTER_NAME \ --output table -------------------------------------------------------------------------------------- | DescribeNetworkInterfaces | +-------------------------------------------+-------------------------+--------------+ | DNSName | ID | PrimaryIP | +-------------------------------------------+-------------------------+--------------+ | ip-10-0-0-152.us-west-2.compute.internal | eni-0525ae09d044a6688 | 10.0.0.152 | +--------------------------------------------+-------------------------+--------------+ || SecondaryIPs || |+-----------------------------------------------------------------------------------+| || 10.0.0.152 || || 10.0.0.144 || || 10.0.0.154 || || 10.0.0.147 || || 10.0.0.133 || || 10.0.0.157 || || 10.0.0.153 || || 10.0.0.158 || || 10.0.0.146 || || 10.0.0.132 || |+-----------------------------------------------------------------------------------+| | DescribeNetworkInterfaces | +--------------------------------------------+-------------------------+--------------+ | DNSName | ID | PrimaryIP | +--------------------------------------------+-------------------------+--------------+ | ip-10-1-79-53.us-west-2.compute.internal | eni-0b2632fa77e9fbf68 | 10.1.79.53 | +--------------------------------------------+-------------------------+--------------+ || SecondaryIPs || |+-----------------------------------------------------------------------------------+| || 10.1.79.53 || || 10.1.78.231 || || 10.1.75.23 || || 10.1.81.171 || || 10.1.95.26 || || 10.1.86.60 || || 10.1.76.92 || || 10.1.65.140 || || 10.1.75.174 || || 10.1.94.30 || |+-----------------------------------------------------------------------------------+| クリーンアップ AWS アカウントで継続的に課金が発生するのを避けるため、作成した EKS クラスターのリソースを必ず削除しておきます。 # Delete EKS cluster resources eksctl delete cluster -f cluster.yaml 留意すべき考慮事項 共有サブネット この機能を複数の AWS アカウントに跨るシナリオ (VPC とサブネットを中央の AWS アカウントで作成し、参加者の AWS アカウントと共有して EKS クラスターをデプロイする) 場合、クラウターを起動する参加者の AWS アカウントでサブネットにタグを付与する必要があります。詳しいクォークスルーについては、「 Use shared VPC subnets in Amazon EKS 」を参照してください。 カスタムネットワーキング IP アドレスの枯渇問題への対応として、Amazon VPC CNI の機能であるカスタムネットワーキングを利用することで、セカンダリ VPC の IP アドレス範囲から Pod に IP アドレスを割り当てることができます。VPC CNI でカスタムネットワーキングを有効にすると、セカンダリ VPC CIDR から作成された代替となるサブネット CIDR 範囲を含む ENIConfig というカスタムリソースで定義されたサブネット内に、セカンダリ ENI を作成することができます。VPC CNI は ENIConfig カスタムリソースで定義された CIDR 範囲から Pod に IP アドレスを割り当てます。さらに、Pod はノードのプライマリ ENI とは異なるセキュリティグループを利用できます。そのため、異なるネットワークと異なるセキュリティグループで Pod を実行する必要がある場合、カスタムネットワーキングを検討する価値があります。一方、拡張サブネットディスカバリーは、ENIConfig カスタムリソースの作成を必要としないため、設定のオーバーヘッドが少なく済みます。VPC CNI で両方の機能が有効になっている場合は、カスタムネットワーキングが優先されます。 Pod ネットワーキングのユースケース この機能は、「 Pods の SNAT 」、「 Pods のセキュリティグループ 」、「 Kubernetes ネットワークポリシーのクラスターを構成する 」、「 Amazon EC2 ノードで使用可能な IP アドレスの量を増やす 」といった、他の VPC CNI のユースケースと組み合わせて利用できます。詳細な比較については、「 Pod ネットワークのユースケースの選択 」を参照してください。 まとめ この記事では、Amazon VPC CNI ベースのサブネットディスカバリーの機能が運用オーバーヘッドを抑えながら、EKS クラスターの成長に合わせた IPv4 アドレスの割り当てに対する拡張性と柔軟性をどのように提供できるのか紹介しました。この機能が、どのようにクラスターサイズの変化に適応でき、昨今の IT 環境の動的なニーズをサポートしながらIP アドレスの管理を簡素化するか実演しました。EKS クラスターを安全にスケーリングするための推奨事項と追加の検討事項については、「 Amazon EKS ベストプラクティスガイド 」を参照してください。 Amazon VPC CNI のインストール手順については、 Amazon EKS ユーザーガイド を参照してください。GitHub の AWS Containers Roadmap にコメントするか Issue を作成することで、 Amazon VPC CNI プラグイン へフィードバックを提供できます。 本記事は、 Amazon VPC CNI introduces Enhanced Subnet Discovery (2024 年 4 月 4 日公開) を翻訳したものです。翻訳は、ソリューションアーキテクトの鈴木が担当しました。

はじめに 昨今、生成 AI の進化が目覚ましく、さまざまなコンテンツを生成できるようになってきました。このような生成 AI の活用シーンを、誰でも簡単にアプリケーション化して共有できるようになったのが、AWS の新しいツール「 PartyRock 」です。PartyRock では、自然言語による画面操作だけで生成 AI を組み込んだアプリを作成し、URL を共有するだけで誰とでも利用できます。そして PartyRock は 2024 年 6 月 13 日現在、AWS アカウントやクレジットカード登録が一切不要で、誰でも無料で利用することができます。エンジニアだけでなく、プログラミング未経験の方でも気軽に生成 AI を活用できます。PartyRock のより詳細な説明は 「PartyRock : 誰でも生成系 AI のアプリケーションを作成し共有できるサービス」 からご確認ください。 本記事では、PartyRock のサンプルアプリをご紹介し、誰でも簡単に生成 AI アプリを作成できることをお伝えします。アプリ紹介の中では、アプリを作った AWS Japan メンバーへのインタビューも掲載しています！PartyRock で作成したアプリは URL を用いて共有することができ、本記事で紹介するサンプルアプリも後述の URL から簡単に試すことができます。楽しく直感的に生成 AI アプリを作ることができる PartyRock をぜひ試してみてください！ AWS Summit Japan PartyRock ブースの紹介 日本最大の “AWS を学ぶイベント” AWS Summit Japan が 2024年 6月 20 日 (木)、21 日 (金) の二日間に渡り幕張メッセで開催されます。クラウドコンピューティングコミュニティが一堂に会して、アマゾン ウェブ サービス (AWS) に関して学習し、ベストプラクティスの共有や情報交換ができる、クラウドでイノベーションを起こすことに興味がある全ての皆様のためのイベントです。基調講演・150 を超えるセッション、250 を超える EXPO コンテンツがあり、その中には PartyRock のブースもあります。AWS アカウント不要の生成 AI プレイグラウンド PartyRock を体験しませんか？専門知識がなくても大丈夫！あなたのアイディアをその場でアプリ化してみましょう！ 場所：AWS Village・生成 AI コーナー ブース名：あなたのアイディアをその場でアプリ化！生成 AI プレイグラウンド PartyRock AWS Summit Japan は下記からご登録できます。PartyRock のブース以外にも数多くのブース・セッションがあります。皆様のご登録・ご来場をお待ちしています！ https://aws.amazon.com/jp/summits/japan/ サンプルアプリ ビデオ書き起こし要約アプリ 作成者：Shintaro Okamoto ソリューションアーキテクト アプリ説明 このアプリでは、ビデオの書き起こし文を入力すると、要約文の自動生成および内容に関する質問回答を行なってくれます。PartyRock を用いるとこのような実用的なアプリも簡単に素早く作成することができます。 このアプリは「Video Transcript」「Video Summary」「Ask About Video」の 3 つのウィジェットから構成されています。「Video Transcript」にビデオの書き起こし文をアップロードすると、「Video Summary」にビデオの内容の要約が生成されます。もしビデオの内容について何かわからないことがある場合は、「Ask About Video」で生成 AI にビデオの内容を聞くこともできます。 「Ask About Video」で会話できる生成 AI は「Video Transcript」と「Video Summary」の内容を知った上で会話してくれるのがポイントです。「Ask About Video」の右上の設定アイコンからプロンプト (生成 AI に与えられる入力) を見てみると、「Video Transcript」と「Video Summary」を参照しているのがわかります。 PartyRock ではどのようなアプリを作りたいかをテキストで入力するだけでアプリが作成されますが、作成された後に編集を行うこともできます。ウィジェットの出力が英語でされてしまう場合は、このプロンプトの最後のように「日本語で出力して」と付け足すだけで、日本語で出力してくれるようになることがあります。 書き起こし文ファイルのアップロードは 2024 年 5 月に追加された Document ウィジェットで行っています。Document ウィジェットを用いると、PDF や DOCX などの一般的なファイルやドキュメントのテキストコンテンツを PartyRock アプリに直接統合することができます。以前までの PartyRock では、このようなユースケースではファイルからテキストを手作業で抽出する必要がありましたが、Document ウィジェットの活用により、より効率的に作業を行うことができるようになりました。今回は書き起こし文としてテキストファイルをアップロードしています。 作成者へのインタビュー 著者 > Okamotoさん、普段は AWS でどんな仕事をされているんですか？ Okamoto > AWS を利用している・これから利用されるお客様に対し技術支援を行っています。 著者 > PartyRock を使ってみた感想を教えてください。 Okamoto > 生成 AI といえばチャットボットを思い浮かべる方が多いと思いますが、実際にはチャット以外の多様なユースケースに活用できる技術です。PartyRock は様々なデータ処理に生成 AI を利用できることをすぐに実感できるプレイグラウンドだと感じました。特に、IT の知識不要ですぐにアイディアを形にできるところが優れていると思います。 著者 > 確かにチャット以外の活用例を見られるのは参考になりますね。普段開発される際と比べると PartyRock はどうでしょうか? Okamoto > 私は普段お客様とお話する際に、お客様が取り組みたい生成 AI 活用テーマをその場でデモすることがしばしばあります。PartyRock は事前準備なしで、ご要望に合わせて様々なデモをその場で行いながら、お客様のイメージを形にしていくツールとして使い勝手がよいものだと考えています。 著者 > なるほど、目に見えるものがその場ですぐにできるのは非常に便利ですね。ありがとうございました！ PartyRock は自然言語で作りたいアプリケーションアイデアを入力するだけで、 ビデオ書き起こし要約アプリ のような実用的なツールを簡単に素早く作成することが可能です。 Document ウィジェットが利用できるようになり、ますます PartyRock を活用できる幅が広がっています。 生成 AI モデル 比べるくん 作成者：Ritaro Kasai 営業担当 アプリ説明 このアプリでは、Amazon Bedrock で使える複数の生成 AI モデルの出力を見比べることができます。PartyRock を使うと手軽に Amazon Bedrock のモデルを試すことができます。 上記のスクリーンショットには 4 つのウィジェットが写っており、左上のウィジェットにアプリ説明、左下に生成 AI への入力、右側の 2 つに生成 AI の出力が表示されています。実際のアプリではもっと多くの生成 AI モデルの出力を見ることができます。 左下の「入力欄：生成 AI への質問を入れてみよう」に生成 AI に与えたいプロンプトを入れると、その内容に対する生成 AI の回答が右側出力用ウィジェットに表示されます。右側のそれぞれのウィジェットにはそれぞれ異なる生成 AI モデルが設定されています。例えば「Claude 3 Sonnet モデルによる出力」の設定を見てみると、 Claude 3  Sonnet がモデルとして指定されていることがわかります。 プロンプトを見てみると、ユーザーの入力がそのまま右側のウィジェットに渡されるという構成になっていることも確認できます。 作成者へのインタビュー 著者 > Kasai さん、普段は AWS でどんな仕事をされているんですか? Kasai > 私は「手触り感」のある生成 AI の可能性をお客様に説いて回る仕事をしています。人材不足と高齢化が差し迫る日本で、おもてなし感のある温かいサービスを 10 年後も維持するには、生成 AI が機械とヒトとの接点を担う部分が激増すると信じているんです。しかし、どこまで使えるのか具体的に考え抜けている人がマーケットには少ないので、その伝道師活動が日本のための使命だと感じています。 著者 > なるほど、生成 AI の実用化に向けて大切な役割を担われているんですね。どうして比べるくんをお作りになられたのですか？ Kasai > 生成 AI モデルが数多くあるよと言われても、その違いがわかりにくかったからです。だから同じお題に対して、違うモデルが一気に回答する「比べるくん」を作ってみました。すると Claude 3 最軽量モデルの Claude 3 Haiku がより高精度なモデルの Claude 3 Sonnet よりも本当に 返答が早いことや、難しい文脈を扱わないものなら十分だな、とか直感的に見えてきて、私も勉強になりました。 著者 > PartyRock の魅力はなんでしょうか? Kasai > AI や IT のエンジニアではない私でもの人でも作れるアプリ！自由度と簡単さのバランスが良かったです。直感的に、プログラミング不要で、PC でもスマホでもアプリが作れたことに感動しました。「ちょっとしたアイデア」があるときに考えるより先に作って、周りの人の感想を聞いてから具体的に考えられる。そんなパラダイム・チェンジが起こせる存在だと思いました。 著者 > 確かに、アイデアを形にしてからブラッシュアップできるのは大きなメリットですね。ありがとうございました！ PartyRock は AI や IT の専門知識をお持ちでない方にとっても、自然言語で作りたいアプリケーションアイデアを入力するだけで、このように形にしやすい点はお客様から評価いただけるポイントです。また、PartyRock では複数の基盤モデルを使用でき、用途に合わせて最適なモデルを選べることが評価される点です。 生成 AI モデル 比べるくん のようなモデルの違いを可視化できるようなアプリケーションを、生成 AI の検討段階に使ってみてはいかがでしょうか。 気分に合わせて格言をお届けします 作成者：Yuri Kinoshita 営業担当 アプリ説明 このアプリでは、今の気持ちを入力するとそれに合わせた格言を生成 AI が考えてくれます。自分では思ってもみなかった視点を生成 AI が与えてくれるかもしれません。PartyRock ではこのように人生を豊かにしてくれるようなちょっとしたツールが簡単に作れます。 「今日のあなたに贈る格言！」に今日の気分を入力すると、その内容に合わせた格言と画像が「どうなるかな…」と「イメージ」にそれぞれ表示されます。 「イメージ」のプロンプトを見ると、「今日のあなたに贈る格言！」の内容から画像を生成していることがわかります。 PartyRock では、このように Image Generation ウィジェットを用いることで画像生成を行うこともできます。 「どうなるかな…」のプロンプトを見てみると、実際の格言の例がプロンプトに入っていることがわかります。 （中略） このようなカスタマイズを試すことにより思い通りの出力に近づけられることもあります。プロンプトをカスタマイズしたい場合には、 Amazon Bedrock  の プロンプトエンジニアリングガイドライン をご参照ください。PartyRock で使われている生成 AI モデルは Amazon Bedrock により提供されています。 作成者へのインタビュー 著者 > Kinoshita さん、普段は AWS でどんな仕事をされているんですか？ Kinoshita > 私は首都圏を中心としたお客様に対して AWS の導入・活用支援を行っております。 著者 > このアプリを思いついたきっかけを教えてください。 Kinoshita > 実際に生成 AI に触ってもらう際に誰でもわかりやすいアウトプットは何だろうと考えた時、占い的な要素があるととっつきやすいのではと思ったんです。普段お客様と会話する際に生成 AI を活用したいが自社にはまだ早すぎる、と仰る方々も多いので、まずは気兼ねなく触ってもらえる遊びの要素を取り入れたアプリを作りました。実際自分たちならどう活用できるかな? とアイデアにつなげる第一歩として使ってもらえると嬉しいです！ 著者 > なるほど、生成 AI に親しんでもらうきっかけ作りですね。PartyRock を使ってみてどうでしたか？ Kinoshita > エンジニア経験はない私が、10 分ほどでアプリを作れたので簡単さに感動しました！サンプルとして、実際の格言データをいくつか入れているのですが、自社のデータに置き換えてまずは試してみる、がすぐにできるのが PartyRock の醍醐味だと感じました。 著者 > 確かに、無料で気軽にアレンジを試せるのが魅力ですよね。ありがとうございました！ PartyRock は遊びの要素も持ち合わせることから、誰でも生成 AI を気軽に体験できるツールとして利用でき、生成 AI に親しむきっかけになりそうです。 各アプリのタイトルをクリックすると、アプリをご自身でお試しいただけます。 気分に合わせて格言をお届けします のような簡単に遊べるツールを体験して Party に参加してみませんか。PartyRock の Remix 機能を使って既存のアプリをカスタマイズしたり、独自に作成したりすることも可能です。 まとめ PartyRock を使えば、機械学習やプログラミングの経験がなくても生成 AI を搭載したアプリを手軽に作ることができます。 サンプルアプリと作成者の生の声から、 PartyRock で生成 AI の幅広い活用方法を見つけられる可能性を感じていただけましたでしょうか。生成 AI に興味がある方は、ぜひ PartyRock で気軽にアプリ作りに挑戦してみてください。 本ブログは、ソリューションアーキテクトの石岡とプロフェッショナルサービスの若田が執筆し、ソリューションアーキテクトの松本が監修しました。 著者について 若田佳菜子 (Kanako Wakata) アマゾンウェブサービスジャパン合同会社 プロフェッショナルサービスコンサルタント 2024 年 4 月入社のプロフェッショナルサービスコンサルタントです。 趣味は旅行とスノーボード、最近はフィルムカメラとアコースティックギターにはまっています。 石岡陸 (Riku Ishioka) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 2024 年 4 月入社のソリューションアーキテクトです。 ゲームと開発が趣味です。 松本 敢大 (Kanta Matsumoto) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 普段は小売業のお客様を中心に技術支援を行っています。 好きな AWS サービスは AWS IoT Core。趣味はカメラで、犬が好きです。

本稿は、JFE エンジニアリング株式会社による生成 AI を活用した業務効率化の取り組みについて、プラットフォーム開発をリードされた 上野 晶鋭 様、 武内 数馬 様より寄稿いただきました。 イントロダクション JFE エンジニアリング株式会社 (以降、当社） は、エネルギー、環境、社会インフラ、産業機械など幅広い分野でプラントや構造物のEPC（設計・調達・建設）、製造、運営事業を展開しています 。また、 AI や IoT を活用したプラント運営の最適化、デジタルツイン技術によるプロセス可視化、データ解析プラットフォーム Pla’cello® や遠隔監視システム GRC の運営など、多岐にわたるデジタルトランスフォーメーションを実行しています。 今回はそれらの取り組みの中で、生成 AI を活用したプラットフォーム「 Pla’cello xChat 」 (以下 xChat) を開発し、建設業における見積りなどの業務を効率化した事例をご紹介します。ブログの中では、プロジェクトの背景、開発体制、 AWS の活用方法についても解説します。 導入経緯 当社では生成 AIでどのようなビジネス価値を創出できるのかを検証するために、 2023 年 5 月より生成 AI 活用のプラットフォームを開発するプロジェクトを開始し、同年 9 月に生成 AI プラットフォーム「 Pla’cello xChat 」をリリースしました。独自のセキュリティ対策と利用ガイドラインを整備し情報漏洩リスクを最小限に抑えた安全な利用環境を提供しており、現在弊社内で 1,000 名以上がこのサービスを利用しています。そして、さらなる利便性向上のために、同年 11 月に事業部メンバーを対象として実際の業務に役立つユースケースを議論するイベントを開催し、そこで集まった 10 件の有望なユースケースについて 3 ヶ月間で PoC を実施し効果検証を行いました。効果のあったユースケースについては、アプリケーションとして xChat への組み込みを進めています。 開発体制・開発フロー方針 生成 AI 活用による成果を素早くかつ確実に挙げるために、適切な分業を行う開発体制・開発フロー・アーキテクチャを整えました。 具体的には、プラットフォームとしての xChat の開発は AWS に詳しい「プラットフォーム開発チーム」が担当し、xChat を使用した生成 AI 活用のユースケースの効果検証は生成 AI に詳しい「データサイエンスチーム」と業務知見を持つ「事業部メンバー」が実施できる体制を作りました。 xChat には PoC を実施するための API を用意しているため、データサイエンスチームと事業部メンバーはすぐにユースケースの効果検証を始めることができます。また、 API を使用することで PoC ごとにプラットフォーム開発チームが xChat の UI などを追加開発する必要がないため、最低限の実装コストで効果検証が行えるようになっています。そして、効果のあるユースケースについては事業部メンバーが実業務で使いやすい形になるように、プラットフォーム開発チームが UI を実装して提供します。以上のような開発フローにより効率良くかつ確実に生成 AI 活用の成果を挙げることが可能となり、利用ユーザーの幅も広がっています。 図 1 開発フロー図 ソリューションの概要 生成 AI による業務効率化を実現するために、xChat において 以下 3 つのコンポーネントを開発しています。 1 つ目は API です。PoC は業務知見をもつ事業部メンバーと生成 AI の知見を持った社内のデータサイエンスチームが共同で実施します。その際、効果検証をすぐに開始できるよう、プラットフォーム開発チームはAPI を公開しました。 2 つ目はユーザーインタフェース (UI) です。PoC の結果、効果があると判断されたユースケースを簡単かつ便利に利用できるようにするために、UI を開発して提供しています。 3 つ目は社内データ検索の仕組みです。実業務に役立つ情報を生成 AI で出力するためには、業務に関連する「社内文書」、「過去のプロジェクトデータ」、「技術資料」などの社内データ参照が不可欠です。これらのデータを検索して生成 AI に読み込ませることで、生成 AI が持つ知識を補い、回答の質や精度の向上が期待できます。当社では Retrieval-Augmented Generation (RAG) の技術を利用して、社内データを検索する仕組みを構築しています。しかし、セキュリティの観点から部署間で検索できるデータ範囲を制限する必要があります。当社では Amazon OpenSearch Service へのクエリ発行時にフィルタを利用することで、部署ごとに検索できるデータの分離を実現しました。 上記 3 つのコンポーネントを表したものが「システムアーキテクチャ図」です。また、「 AWS アーキテクチャ図」のとおり、生成 AI サービスには Amazon Bedrock を採用し、 AWS Lambda をはじめとしたフルサーバレス構成を採用しています。 図 2 システムアーキテクチャ図 図 3 AWS アーキテクチャ図 具体的な成果事例 PoC を経て実装されたユースケースの具体例として見積書からのデータ抽出があります。これまで見積書を比較検討する際、各取引業者で違ったフォーマットの見積書から手作業でデータを抽出する必要がありました。ある事業部ではこの作業に年間 5,000 時間もかかっていると言われており、過去には OCR でのデータ抽出自動化を試みましたが、フォーマットが異なるため抽出したデータの比較が難しく業務効率化を実現できませんでした。本課題を解決するために、OCR の文字読取り機能と生成 AI の文章補正を組み合わせ、より精度の高い見積書からのデータ抽出を実現しました。実業務では各社の見積書を xChat にアップロードするだけで、データ抽出と統一フォーマットでの出力を生成 AI が行ってくれるため、事業部メンバーは効率的に見積りの比較が行えます。実際に事業部ユーザーに使用していただいたところ、見積り比較業務を数十 ％ 削減できるとのフィードバックを得ることができました。 まとめと今後の展望 当社は建設業における業務効率化に生成 AI を活用して取り組んでいます。これまでは、素早くかつ確実に生成 AI 活用の成果を挙げるために開発体制・フロー・アーキテクチャを整備し、AWS 上で生成 AI のアプリケーションを構成することで、ビジネス上の効果を得ることができました。今後は xChat を活用して更なるユースケースの拡大や横展開を継続していきます。また、RAG を用いた社内データ連携の強化やマルチモーダルなデータの取り込み、 Agents for Amazon Bedrock などを活用し、事業部メンバーがより便利に xChat を利用できるよう、更なるプラットフォームの機能拡張も継続していきます。 執筆者 上野晶鋭 JFE エンジニアリング株式会社 DX 本部 ICT センター データプラットフォーム開発部 Pla’cello 開発室 主幹 大学卒業後、通信業界、小売業界、製薬業界のサービス・システム開発リーダー、システムアーキテクトとして従事後、2022 年に JFE エンジニアリングに入社。入社後はデータ解析プラットフォーム （Pla’cello®） の開発を担当し、現在は生成AI活用基盤 （Pla’cello xChat） の開発・活用を推進。 武内数馬 JFE エンジニアリング株式会社 DX 本部 ICT センター データプラットフォーム開発部 Pla’cello 開発室 主任 情報通信企業、AI ベンチャーを経て 2021 年に JFE エンジニアリングに入社。ソフトウェアエンジニアとして、データ解析プラットフォーム （Pla’cello®） におけるローコード ETL ツール、生成 AI 活用基盤 （Pla’cello xChat） の開発を担当。好きな AI は「月は無慈悲な夜の女王」のマイク。

世界の核融合エネルギー（フージョンエネルギー）研究を支える核融合科学研究所では大型ヘリカル装置(LHD)の実験データを大規模に保有しており、今回AWSの基盤にてオープンデータとして公開した 核融合科学研究所は、大型ヘリカル装置(LHD)の実験データの25年分 約2PB（ペタバイト）をオープンデータとしてアマゾン ウェブ サービス（以下、AWS）の クラウド上で公開しました。学術研究基盤LHDは、核融合科学研究所が、25年にわたって世界最大級の超伝導プラズマ閉じ込め装置として実験研究しているものです。学術研究基盤LHDでは、超高温プラズマを安定に生成し、多様な高精細計測装置を用いてプラズマの内部構造を計測することによって、核融合に限らず宇宙、天体プラズマにも共通する様々な複雑現象の原理に迫り、超高温、極低温、放射線などの極限環境における材料科学などの分野においても革新的な進歩が期待できます。またグリーンイノベーションとして、太陽と同じ核融合を地上でエネルギー源として利用する核融合発電の実現に必要な要素の一つである超高性能プラズマの定常保持の実証を行っています。日本政府の科学技術・イノベーション戦略でも、新たなムーンショット型研究開発制度が始まっており、核融合エネルギー（フュージョンエネルギー）もその目標の中にあります。 核融合科学研究所では、学術研究基盤LHDを国内外の共同研究者に利便性高く利用可能としており、標準化されたデータの公開を進めていました。25年にわたるデータアーカイブがありかつ大規模データであるため、公開用のストレージとデータ提供基盤、データ転送に関わるネットワークに課題がありました。オープンデータとして公開するデータは約2PBにもなり、この規模のストレージを長期的に維持していくことが必要です。保守期限を迎えるとその入れ替えに手間や時間がかかることが想定されており、データを利用するユーザーとしては大容量のデータとなるため転送にも時間がかかりすぐに解析等処理ができないことが課題となっていました。また今後LHDのデータ利用が進み大量のデータのダウンロード行われていくと研究所の対外接続用ネットワークの帯域が占有されてしまう可能性があり通常業務への影響も懸念されていました。これらの理由などから、核融合科学研究所ではオープンデータを安定的に提供する基盤を探していました。 AWSオープンデータスポンサーシッププログラム には、数百以上のデータセットが集められ、AWS アカウントの有無にかかわらず、これらのオープンデータを誰でも検索して見つけることができ、誰でもが利用することが可能です。クラウドでの利用に向いた高価値データセットのストレージコストを AWS が負担することによってコミュニティの研究や開発の加速に寄与するオープンデータスポンサーシッププログラム をデータプロバイダーと協力して実施しています。 このたび核融合科学研究所は、AWSオープンデータスポンサーシッププログラムを利用し、学術研究基盤LHD の25年分にわたる実験データをオープンデータとして公開しました。データは AWS のオープンデータプログラム上で提供されるため、先に触れましたように、AWS アカウントの有無にかかわらず利用可能です。核融合科学研所がAWSを採用した理由は、スケーラビリティや耐久性の高さからAmazon Simple Storage Service (Amazon S3)へのデータ格納に価値を見出していた結果です。また、AWS 上で解析をする場合には、利用者にとってデータ転送にかかる手間を減らしてクラウド上ですぐにデータを解析できる環境を提供することができるようになります。AWS の基盤からのデータの配信となるため、核融合科学研究所のネットワークへの負荷も無く、研究所内のシステムと切り離した形でデータ提供も実現できました。 AWS 上へのデータ移行に関しては、AWS が SINET6 向けに SINET クラウド接続サービス内で提供している回線を利用し、平均 10Gbps 以上の伝送速度で核融合科学研究所から AWS 上へ伝送が行われ、データ伝送が比較的短期間で実施できたことも核融合科学研究所から評価いただけました。 今後 AWS 上で今回のデータを使って解析をする簡単な手順や、ワークショップなどを核融合研究所で実施されていく予定となっております。 アマゾン ウェブ サービス ジャパン合同会社 執行役員 パブリックセクター 統括本部長 宇佐見 潮は、次のように述べています。「核融合科学研究所様との連携により、フージョンエネルギーの活用に弊社が貢献できること、大変嬉しく思います。国内の学術研究分野にとどまらず、全世界の産業界からこの オープンデータが活用され、様々な科学分野において技術革新が進むことを期待します。」 詳細について、核融合科学研究所のプレスリリースをご覧ください。 https://www.nifs.ac.jp/news/collabo/240614.html 大学共同利用機関法人 自然科学研究機構 核融合科学研究所(NIFS)について 核融合科学研究所(NIFS: National Institute for Fusion Science)は、大学共同利用機関法人自然科学研究機構を構成する研究所の1つであり、1989年に核融合科学分野における国立の研究所として設置されました。大学共同利用機関として国内外の研究機関から研究施設の共同利用が行われています。総合研究大学院大学をはじめとして大学院の学生に対する教育も実施しています。日本政府の科学技術・イノベーション戦略でも、新たなムーンショット型研究開発制度が始まっており、フュージョンエネルギーもその目標の中にあります。詳細については以下の URL をご覧ください。 https://www.nifs.ac.jp/ 大型ヘリカル装置(LHD)について 大型ヘリカル装置(LHD:Large Helical Device)は核融合科学研究所により、25年にわたって世界最大級の超伝導プラズマ閉じ込め装置として実験研究されています。LHDでは、超高温プラズマを安定に生成し、多様な高精細計測装置を用いてプラズマの内部構造を計測することによって、核融合に限らず宇宙、天体プラズマにも共通する様々な複雑現象の原理に迫り、超高温、極低温、放射線などの極限環境における材料科学などの分野においても革新的な進歩が期待できます。この規模の実験装置は世界的にも簡単には製作できず実験も大がかりなものとなるため、実験によって計測されたデータは様々な研究機関や企業にとって貴重な研究材料となります。現在も実験が行われていますが、これまでも25年にわたって様々なデータをとり続け、現在約2PBもの大規模データとなっています。