はじめに このブログ記事は、 AWS IoT SiteWise での設備総合効率 (OEE) の使用に関するシリーズの第2回目です。この投稿では、AWS IoT SiteWise のネイティブ機能を使用して OEE を計算し、エンドツーエンドのソリューションとして計算値を収集、保存、変換、表示する方法を詳しく説明します。このプロセスを説明するユースケースとして、空港に設置された手荷物処理システム (BHS) を取り上げます。ユースケースの詳細については、まずこのシリーズのパート1、「 AWS IoT SiteWise による総合設備効率（OEE）ガイド 」をお読みください。 さらに、OEE 要素を自動化して、製薬、食品、飲料業界の製造生産ラインなど、他の多くのユースケースでこのソリューションの実装を効率化する方法についても説明します。このブログで説明されている概念を実践しやすいように、合成データを AWS IoT SiteWise にストリーミングし、本ブログで説明する計算を使用して OEE ダッシュボードを作成できるコードリポジトリも提供しています。 ユースケース OEE の計算を掘り下げる前に、基準系として使用する例を確認しましょう。この例は BHS で、OEE 計算に必要なデータポイントは、荷物を運ぶ回転式コンベア（カルーセル）内の BHS に設置されたハードウェアから収集されます。ハードウェアは4つのセンサーで構成されています。モーター監視用の振動センサー2つ、コンベア監視用のスピードセンサー1つ、手荷物の処理量をカウントする光電センサー1つです。 ソリューションのアーキテクチャは次のとおりです。 センサーデータは、AWS パートナーの CloudRail を通じて収集および整形されます。CloudRail のソリューションを利用すると、IIoT データの収集と AWS IoT SiteWise へのストリーミングが大幅に簡素化されます。この統合は、 CloudRail 管理ポータル から直接設定できます。このアーキテクチャには、センサーデータを S3 バケットを経由して他の AWS サービスで利用できるようにするための追加コンポーネントが含まれています。 AWS IoT SiteWise の前提条件 データを AWS IoT SiteWise に送信する前に、 モデルを作成し てそのプロパティを定義する必要があります。前述のように、次の測定値（機器からのデータストリーム）をもつ、4つのセンサーを1つのモデルにグループ化します。 Model:Carousel Asset Name: CarouselAsset Property { Measurement: Photo.Distance Measurement: Speed.PDV1 Measurement: VibrationL.Temperature Measurement: VibrationR.Temperature } 測定値に加えて、アセットモデルにいくつかの 属性 （静的データ）を追加します。属性は、OEE 計算に必要な様々な値となります。 Model:Carousel Asset Name: CarouselAsset Property { Attribute: SerialNumber Attribute: Photo.distanceBase Attribute: Photo.distanceThold Attribute: Speed.max_speed_alarm Attribute: Speed.min_speed_alarm Attribute: Vibration.max_temp_c_alarm Attribute: Ideal_Run_Rate_5_min } それでは、AWS IoT SiteWise コンソールに進み、空港の BHS を表すカルーセルモデルとアセットを作成しましょう。 左側のナビゲーションメニューを開き、 ビルド、モデル、モデルの作成 の順に選択して、このモデルの属性と測定値を定義します。 アセットモデルの作成について詳しくは、 ドキュメント をご覧ください。 OEE の計算 OEE の定義とその構成要素を見てみましょう。 OEE の標準計算式は次のとおりです。 コンポーネント 式 Availability Run_time/(Run_time + Down_time) Quality Successes / (Successes + Failures) Performance ((Successes + Failures) / Run_Time) / Ideal_Run_Rate OEE Availability * Quality * Performance BHS のパラメータ定義を見てみましょう。OEE パラメータの詳細については、 ドキュメント をご覧ください。 Ideal_Run_Rate: このケースの理想的な実行速度は 300 bags/hour で、これは 0.83333 bags/second に相当します。この値はシステムによって異なるため、製造元から入手するか、現場での観測性能に基づいて取得する必要があります。 Availability Availability = Run_time/(Run_time + Down_time) BHSには4つのセンサーがあり、そのセンサーのどの 測定値 （温度、振動など）を計算に含めるかを定義する必要があります。2つの振動センサーからの温度（摂氏）と速度センサーからの回転式コンベアの速度 (m/s) によって、稼働状況が決まります。 正しく動作するための許容値は、アセットモデルの以下の属性に基づいています。 Vibration.max_temp_c_alarm = 50 Speed.min_speed_alarm = 28 Speed.max_speed_alarm = 32 それでは、BHS の現在の状態を次のような数値コードで提供するデータ 変換 Equipment_State を定義してみましょう。 1024 – マシンはアイドル状態です 1020 – システムの異常動作、高温、または定義された正常範囲外の速度値などの障害 1000 – 計画的な停止 1111 – 通常運転 この簡略化されたユースケースでは BHS のアイドル状態は定義されていませんが、他のデータストリームを AWS IoT SiteWise に統合することで、例えば、プログラマブルロジックコントローラー (PLC) や、人間のオペレーターがシステムのアイドル状態かどうかを入力するシステムから情報を登録することも可能です。 変換を追加するには、AWS IoT SiteWise コンソールでモデルに移動し、 編集 を選択します。変換の定義までスクロールし、名前、データ型 (ダブル) を入力し、それぞれのフィールドに次の数式を入力します。 Equipment_state = if((Speed.PDV1>Speed.max_speed_alarm) or (Speed.PDV1<Speed.min_speed_alarm) or (VibrationL.Temperature>Vibration.max_temp_c_alarm) or (VibrationR.temperature>Vibration.max_temp_c_alarm),1020).elif(eq(Speed.PDV1,0),1000,1111) 数式は、コンソールに入力すると次のようになります。UI は、数式の構築を支援するため、モデルで既に定義されている属性や測定値が提案表示されます。 Equipment_State の定義が完了したら、BHS の他の状態を捕捉するため以下のように派生する変換を作成します。変換は他の変換を参照できます。 次のメトリクスを定義して、マシンデータを時系列で集計します。各 メトリクス の時間間隔は同じにしてください。 Fault_Time = statetime(Fault) – The machine’s total fault time (in seconds) Stop_Time = statetime(Stop) – The machine’s total planned stop time (in seconds) Run_Time = statetime(Running) – The machine’s total time (in seconds) running without issue. Down_Time = Idle_Time + Fault_Time + Stop_Time – The machine’s total downtime モデルのメトリクスの定義は次のようになります。 Quality Quality = Successes / (Successes + Failures) ここでは、何が成功と失敗を構成するのかを定義する必要があります。このケースでの計測単位はバッグ数ですが、バッグの個数計数が成功した場合とそうでない場合をどのように定義すれば良いでしょうか。BHS の4つのセンサーから得られる測定値とデータを使用します。 バッグの数は、光電センサーが提供している距離を見てカウントされます。つまり、バンドを通過する物体があると、センサーは「ベース」距離よりも小さい距離を報告することを利用します。これはバッグの通過数を算出する簡単な方法ですが、同時に、測定の精度に影響を与えうる複数の条件を考慮する必要があります。 品質計算には以下のモデル属性を使用します。 Photo.distanceBase = 108 Photo.distanceThold = 0.1 Photo.DistanceBase は、センサーの前に物体がないときにセンサーによって報告される距離です。この値は定期的に校正して調整する必要がある場合があります。振動や位置ずれなどの要因により、バッグが誤検出される可能性があるためです。 Photo.DistanceThold は、センサーの感度の閾値を定義するのに使用されます。これにより、ゴミや小さな物体（バッグのアタッチメントやベルトなど）が通常のバッグのようにカウントされるのを防ぐことができます。 次に、バッグカウント用に2つの変換を設定します。 Bag_Count = if(Photo.Distance < Photo.distanceBase,1,0) Dubious_Bag_Count = if((gt(Photo.Distance,Photo.distanceBase*(1-Photo.distanceThold)) and lt(Photo.Distance,Photo.distanceBase*0.95)) or (Speed.PDV1>Speed.max_speed_alarm) or (Photo.Distance>Photo.distanceBase),1,0) Bag_Count は光電センサーの前を通過する全てのバッグをカウントし、Dubious_Bag_Count は次の2つの異常と判定する条件下でバッグとして検出されたオブジェクトをカウントします。 検出される距離が基準距離の 95% から 90% の範囲に入るものです。これは、小さな物体や測定値のごくわずかな変動、振動による変化、またはセンサーが正しく取り付けられていないことを考慮したものです。 回転式コンベアの速度が定義された制限を超えた時にカウントされたバッグです。この状態では、センサーは回転式コンベア上で隣接するバッグをカウントできない可能性があります。 注:上記の条件は単純なルールであり、より良い結果を得るには、ベースの距離と閾値をフィールドデータで検証および分析することで適切な値を設定する必要があります。 成功と失敗をメトリクスとして以下のように定義します。 Successes = sum(Bag_Count) – sum(Dubious_Bag_Count) Failures = sum(Dubious_Bag_Count) 最後に、OEE Quality をメトリクスとして以下のように定義します。 Quality = Successes / (Successes + Failures) 他のすべてのメトリクス定義と同じ時間間隔を使用することを忘れないでください。 Performance Performance = ((Successes + Failures) / Run_Time) / Ideal_Run_Rate Quality の計算から成功と失敗のメトリクスを、Availability からの Run_Time のメトリクスを取得できます。従って、必要なのは ideal_run_rate_5_min です。このシステムでは、この値は 300 bags/hour = 0.0833333 bags/second となります。 OEE Value Availability、Quality、Performance が決まったので、OEE の最後のメトリクスを次のように定義します。 OEE = Availability * Quality * Performance 変換とメトリクスの定義を簡素化 変換とメトリクスとして定義される OEE コンポーネントを、AWS コンソールを使用する代わりにプログラムで定義することもできます。これは、Equipment_State の変換や Dubious_Bag_Count の変換のように複数の変数を含む複雑な式がある場合に特に便利です。また、自動化されたソリューションは手動ソリューションよりもエラーが発生しにくく、複数の環境で一貫して構成できます。 Python 用 AWS SDK (Boto3) を使用してこれを行う方法を見てみましょう。 まず、変換/メトリクス計算で参照する測定値と属性のプロパティ ID、およびモデル ID を特定します。 次に、メトリクス/変換の JSON を定義します。例えば、BHS の Equipment_State を計算する新しい変換を作成するには、以下の属性が必要です。 Vibration.max_temp_c_alarm Speed.max_speed_alarm Speed.min_speed_alarm And the following measurements: VibrationL.Temperature VibrationR.Temperature Speed.PDV1 以下に示す構造に従ってファイルを作成します。必ず、propertyId を置き換えて、equipment_state.json という名前で保存してください。 { "name": "Equipment_State", "dataType": "DOUBLE", "type": { "transform": { "expression": "if((var_speedpdv1>var_speedmax_speed_alarm) or (var_speedpdv1<var_speedmin_speed_alarm) or (var_vibrationltemperature>var_vibrationmax_temp_c_alarm) or (var_vibrationrtemperature>var_vibrationmax_temp_c_alarm),1020).elif(eq(var_speedpdv1,0),1000,1111)", "variables": [ { "name": "var_vibrationrtemperature", "value": { "propertyId": "b9554855-b50f-4b56-a5f2-572fbd1a8967" } }, { "name": "var_vibrationltemperature", "value": { "propertyId": "e3f1c4e0-a05c-4652-b640-7e3402e8d6a1" } }, { "name": "var_vibrationmax_temp_c_alarm", "value": { "propertyId": "f54e16fd-dd9f-46b4-b8b2-c411cdef79a2" } }, { "name": "var_speedpdv1", "value": { "propertyId": "d17d07c7-442d-4897-911b-4b267519ae3d" } }, { "name": "var_speedmin_speed_alarm", "value": { "propertyId": "7a927051-a569-41c0-974f-7b7290d7e73c" } }, { "name": "var_speedmax_speed_alarm", "value": { "propertyId": "0897a3b4-1c52-4e80-80fc-0a632e09da7e" } } ] } } } 主となる expression は次のとおりです。 if((var_speedpdv1>var_speedmax_speed_alarm) or (var_speedpdv1<var_speedmin_speed_alarm) or (var_vibrationltemperature>var_vibrationmax_temp_c_alarm) or (var_vibrationrtemperature>var_vibrationmax_temp_c_alarm),1020).elif(eq(var_speedpdv1,0),1000,1111) update_asset_model_sitewise.py というスクリプトの入手と、AWS IoT SiteWise にデータをストリーミングする方法の詳細については、 こちら のパブリックリポジトリにアクセスしてください。 次に、モデル ID と以前に定義したファイルの名前を引数として、次のスクリプトを実行します。 #python3 update_asset_model_sitewise.py --assetModelId [Asset Model ID] --property_file [JSON File defining the new property] --region [AWS Region] スクリプトが正常な応答を返した後、作成した新しいプロパティ ID は、前述のように AWS コンソールから直接取得できます。もしくは、AWS CLI を使用して更新されたモデル定義をクエリし、 jq ユーティリティを使用して結果をフィルタリングすることでも取得できます。 #aws iotsitewise describe-asset-model --asset-model-id [model ID] | jq .'assetModelProperties[] | select(.name=="Equipment_State_API")'.id その後、他の変換やメトリクスについても同じプロセスを繰り返して、OEE の計算に必要なすべてのコンポーネントを作成できます。 AWS IoT SiteWise アセットモデルの更新の詳細については、 API リファレンス をご覧ください。 まとめ このブログ記事では、AWS IoT SiteWise のネイティブ機能を使用して、実際のシナリオのセンサーデータを使用して OEE を計算し、物理システムから洞察に満ちた情報を取得する方法について説明しました。パブリックリポジトリで入手可能なデータを特定しながら、OEE の主要な要素である Availability、Quality、Performance を定義しました。最後に、計算とその自動化方法について詳しく説明しました。 読者の次のアクションとして、ここで紹介した内容をさらに発展させて、OEE 計算プロセスを独自のユースケースに適用すること、さらに、提供されている自動化ツールを使用して、産業システムを正確に監視するのに役立つデータ生成を簡素化および合理化していくことをお勧めします。 使用できるデータがない場合は、この パブリックリポジトリ に概説されている手順に従い合成データで AWS IoT SiteWise を使い、OEE が提供する洞察に満ちた情報を発見することをお勧めします。 著者について Juan Aristizabal Juan Aristizabal は、アマゾンウェブサービスのソリューションアーキテクトです。カナダ西部の新規開拓企業のクラウドへの移行を支援しています。彼は、データセンターテクノロジー、仮想化、クラウドに至るまで、企業の IT トランスフォーメーションに10年以上携わってきました。余暇には、家族と一緒に旅行したり、シンセサイザーやモジュラーシステムで演奏したりするのが好きです。 Syed Rehan Syed Rehan は、アマゾンウェブサービス (AWS) のシニアグローバル IoT サイバーセキュリティスペシャリストで、AWS IoT サービスチームで働いており、ロンドンを拠点としています。セキュリティの専門家、開発者、意思決定者と協力して、AWS IoT サービスの運用を推進している世界中の顧客を対象としています。Syed はサイバーセキュリティ、IoT、クラウドに関する深い知識を持っており、スタートアップからエンタープライズに至るまで、世界中のお客様が AWS エコシステムで IoT ソリューションを構築できるよう支援しています。 この記事は Calculating Overall Equipment Effectiveness (OEE) with AWS IoT SiteWise の日本語訳です。IoT Consultant の正村 雄介が翻訳しました。

クラウド内の SQL Server データベースを保護することは重要であり、 Amazon Relational Database Service for SQL Server (Amazon RDS) は、データベースインスタンスの機密性、整合性、可用性を確保するために役立ついくつかのセキュリティ機能を提供します。これらの機能には、保存中および転送中のデータ暗号化、安全なユーザー認証および認可メカニズム、ネットワーク分離、およびきめ細かいアクセス制御が含まれます。 この投稿では、Amazon RDS for SQL Server インスタンスのセキュリティ体制を強化するためのベストプラクティスを示します。 クラウドセキュリティの概要 クラウドセキュリティの 3 つの主な要素は認証、認可、監査であり、次の図に示すプロセスにさらに分類できます。 プロセスは次のとおりです。 ネットワークセキュリティ – ネットワークセキュリティには、基盤となるインフラストラクチャを不正なアクセスや脅威から保護し、許可されたアクセスのみを許可するようにインフラストラクチャを保護することが含まれます。 Amazon Virtual Private Cloud (Amazon VPC) は、選択した仮想ネットワークで AWS リソースを起動できる、AWS クラウドの論理的に分離されたセクションを提供します。これにより、ネットワークアクセス、ネットワーク分離、ネットワークトラフィックフローなど、AWS インフラストラクチャのセキュリティとネットワーク構成を制御できます。 DB 認証 – これは、データベースにアクセスしようとするユーザーまたはシステムを認証するプロセスです。これは重要なデータへの安全なアクセスを確保するために、ログインとパスワードの認証、多要素認証、証明書ベースの認証などのさまざまな方法を使用して実現できます。 DB 認可 – これは、ユーザーまたはシステムの ID が認証された後に、そのユーザーまたはシステムにアクセス権を付与するプロセスです。これにはデータの読み取りや書き込み、特定のデータベースオブジェクトへのアクセスなど、特定のタスクを実行する権限の付与が含まれる場合があります。これによってデータが安全で許可された個人とシステムのみがデータにアクセスできることが保証されます。 DB アクセス監 査 – このプロセスはアカウンティングとも呼ばれ、不正アクセス試行などのセキュリティ問題を検出し、規制およびコンプライアンスの義務を果たすためにデータベースアクティビティの監視と記録を保証します。これはデータベースイベントを監視し、警告を設定し、ログを分析して不審な動作を検出することで実現され、データベースのアクセスと変更に対する監査可能な証跡が得られます。 DB 暗号化 – これは転送中と保存中のデータを暗号化することで、データベースに含まれる機密データへの不要なアクセスを防ぐプロセスです。データベース内の機密データを保護するために、AWS はサーバー側の暗号化、クライアント側の暗号化、スナップショット暗号化などのさまざまな暗号化ソリューションを提供しています。これにより、データベースに不正なアクセスがあった場合でも、暗号化されたデータは安全に保たれ、読み取ることができなくなります。 DB セキュリティ監視 – これにはセキュリティ問題をタイムリーに検知して対応するために、データベースとデータベースが動作するシステムとネットワークのセキュリティを監視することが含まれます。これはデータベースイベントを監視し、セキュリティアラームを設定し、セキュリティ分析ツールを使用してセキュリティリスクを検出して対応することによって実現できます。 次のセクションでは、各コンポーネントについて詳しく説明します。 ネットワークセキュリティ ネットワークセキュリティは、データベースインスタンスを不正アクセスから保護するための重要な手順です。データベースへのすべてのネットワークトラフィックが、ネットワーク構成で明示的に許可されている既知のソースから発信されていることを確認することが重要です。これは主にセキュリティグループと ネットワークアクセスコントロールリスト (ACL) を使用して構成できます。 セキュリティグループ 各 RDS for SQL Server インスタンスは 1 つ以上の セキュリティグループ に関連付けられます。これらのセキュリティグループを使用すると、インスタンスへのトラフィックを許可する IP または IP アドレスの範囲、およびポートまたはポート範囲を指定して、データベースインスタンスへのトラフィックを制御できます。 セキュリティグループが最大限に活用されるようにするには、データベースへのアクセスが必要な特定のソースおよびポート番号または範囲に対するイングレスルールを必ず追加してください。セキュリティグループは本質的にステートフルであり、受信ルールを通じて許可されている受信トラフィックに対して送信のトラフィックを自動的に許可します。 ネットワークアクセスコントロールリスト (ネットワーク ACL) ネットワーク ACL を使用すると、VPC 内のネットワークトラフィックをきめ細かく制御できます。ネットワーク ACL ルールはステートレスであるため、受信ルールと送信ルールを個別に指定する必要があります。これらは、VPC 内でデータベースを確実に分離するために追加のポリシーを導入する必要がある場合に役立ちます。 VPC 内のプライベートサブネットに Amazon RDS for SQL Server インスタンスを作成し、ネットワーク ACL を作成して Amazon RDS for SQL Server サブネットに関連付けることで、VPC 内の特定のサブネットからの特定のトラフィックのみが Amazon RDS for SQL Server VPC に到達できるようにすることができます。セキュリティグループとは異なり、ネットワーク ACL はステートレスであり、受信トラフィックと送信トラフィックの両方に対してルールを定義する必要があることを覚えておくことが重要です。 ネットワーク ACL を使用している場合、Amazon RDS for SQL Server マルチ AZ インスタンスを構成する場合は UDP と TCP のポート 3343 でのトラフィックを必ず許可してください。 ネットワーク ACL を使用すると、サブネットレベルでトラフィックフローを制御できますが、管理と構成が複雑になる可能性があることに注意することが重要です。 そのため、定義されたソースからのトラフィックを許可する必要があってサブネットレベルで管理する必要がない場合は、セキュリティグループの方がこれらのルールを定義する方が適しています。セキュリティグループはインスタンスレベルで動作し、ネットワーク ACL はサブネットレベルで動作するからです。 Amazon RDS for SQL Server データベースインスタンスへのリモート接続 SQL Server Management Studio や他の SQL クライアントなどのツールを使用して、Amazon RDS for SQL Server にリモートで接続する方法は複数あります。ただし、アクセスを容易にしながらリモート接続の安全性を確保することが重要です。セキュリティやコスト削減などのさまざまな理由から、踏み台ホストを使用して接続を Amazon RDS に委任することをお勧めします。 このアプローチでは、踏み台ホストをデプロイして、AWS Systems Manager から Amazon RDS for SQL Server インスタンスへの SQL Server 接続をプロキシします。両方とも VPC 内のプライベート サブネット にデプロイされます。 AWS コマンドラインインターフェイス (AWS CLI) で Systems Manager を使用する手順については、「 AWS Systems Manager ユーザーガイド 」を参照してください。 次の図は、このアーキテクチャを示しています。 このアプローチは次のように機能します。 適切な API キーを使用して、 AWS コマンドラインインターフェイス と セッションマネージャープラグイン を備えた VDI/ デスクトップまたはラップトップなどの開発環境を構成します。環境から想定できる SSM 権限を持つ IAM ロールを使用することをお勧めします。 その後、データベースインスタンスがデプロイされているプライベートサブネット内に踏み台ホストまたはジャンプホストをデプロイし、データベースポートへのアクセスを許可するように踏み台ホストのセキュリティグループを構成できます。また、VPC エンドポイントに到達できるように、少なくとも 1 つのルールがアウトバウンド 433 (HTTPS) をカバーしていることを確認してください。 同様に Amazon RDS for SQL Server インスタンスにセキュリティグループを設定して、踏み台ホストのセキュリティグループからの受信トラフィックを許可します。 アクセス許可ポリシー SSMManatedInstanceCore を使用してインスタンスプロファイルを作成し、踏み台ホストに割り当てます。 ローカルワークステーションまたは VDI が適切な IAM ユーザーで構成されていることを確認するか、SSM 権限を持つ IAM ロールを引き受けます。 コマンドプロンプトを開き、次の AWS CLI コマンドを入力します。 aws ssm start-session ` --region <region> ` --target <bastion instance id> ` --document-name AWS-StartPortForwardingSessionToRemoteHost ` --parameters host=" <rds endpoint> ",portNumber="1433",localPortNumber="1433" 次のようなメッセージが表示されるはずです。 Starting session with SessionId: 12a3456bcdefghi789 Port 1433 opened for sessionId 12a3456bcdefghi789. Waiting for connections... これで、SQL Server Management Studio を開いてサーバー名 127.0.0.1,1433 に接続できるようになりました。これにより、踏み台ホストを介して Amazon RDS for SQL Server インスタンスに接続が転送されます。適切な証明書を使用して SSMS を構成し、接続プロパティ タブの [接続の暗号化] チェックボックスをオンにして、接続が暗号化されていることを確認します。 この図は Linux の踏み台インスタンスを示していますが、Windows インスタンスも同様に動作するため、Linux ホストである必要はありません。ただし、踏み台ホストがプロキシとして機能し、RDS インスタンスへの接続を通過させるためだけに存在することを考えると、コンピューティングリソースは最もコスト効率の高いオプションに基づく必要があります。 これは、次の理由からRDS for SQL Server インスタンスへのリモートアクセスを有効にする場合のベストプラクティスです。 開く必要があるポートは、踏み台ホストと RDS for SQL Server インスタンスの間のみです。 リモートデスクトップ SSH 接続のために IP 許可リストは必要ありません。 Amazon Elastic Compute Cloud (Amazon EC2) 踏み台ホストは、インターネットに公開せずにプライベートサブネット内に配置できます。 VDI と AWS 環境間の接続には、 AWS Direct Connect または AWS VPN を使用することを推奨します。Amazon EC2、Amazon RDS、および Systems Manager はすべて AWS PrivateLink を介して接続が行われるため、インターネットからのアクセスが制限されています。 これまでに説明した方法はネットワークセキュリティに役立ち、選択したトラフィックのみがデータベースに到達できるようにします。ただし、利用可能なさまざまな認証および承認方法を使用してデータベースレベルで RDS for SQL Server インスタンスをさらに保護するだけでなく、データベースに関連する重要なイベントが監視、記録され、さらなる分析や調査に利用できるように監視と監査を実施することも同様に重要です。次のセクションでは、データベースセキュリティのこれらの主要なコンポーネントについて説明します。 データベース認証 SQL または Windows 認証を使用して、RDS for SQL Server データベースに接続できます。 Windows 認証に NTLM または Kerberos を使用することもできます。 SQL Server 認証 SQL Server 内では、SQL Server 認証によってユーザー名とパスワードのペアが追跡されます。 Active Directory (AD) のメンバーではない場合に Amazon RDS for SQL Server に接続する唯一の方法は、SQL Server 認証を使用することです。 SQL Server ログインは、使用時に暗号化されたパスワードと SQL Server ログイン名がネットワーク経由で送信され、ユーザー情報が盗まれる可能性が高くなるため、プライバシーが下がります。したがって、可能な限り SQL Server 認証ではなく Windows 認証を使用してください。 Windows 認証 RDS for SQL Server インスタンスが AWS Managed Microsoft AD の AD ドメインにドメイン参加している場合は、Windows 認証を有効にすることができます。 Windows 認証を有効にすると、AD ドメイン ユーザーは Windows 資格情報を使用して SQL Server データベースにアクセスできるようになります。ユースケースによっては、これは、特に人間のユーザーが管理や手動クエリの実行のためにアクセスを必要とする場合、データベースへのアクセスを管理するための好ましい方法となる場合があります。 注意 ： 2023 年 7 月 10 日よりセルフマネージド型の Active Directory をサポートされるようになりました。詳細は、 こちら のブログを参照してください。 ドメインユーザーが RDS for SQL Server インスタンスにログインできるようにするには、インスタンスが AD ドメインにドメイン参加していることを確認し、次のクエリを実行してドメインユーザーのログインを作成します。 USE [master] GO CREATE LOGIN [mydomain\myuser] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english]; GO ログインが作成されると、ユーザーはドメイン資格情報を使用してデータベースにアクセスできるようになります。適切なロールがユーザーに追加されていることを確認してください。次のセクションでは、最小権限に基づいてロールを割り当てるベストプラクティスについて説明します。 チームのすべてのメンバーがデータベースにアクセスする必要があるアプリケーションチームなど、複数のユーザーがデータベースにアクセスする必要がある場合があります。このような場合、すべてのユーザーで構成される AD セキュリティグループを作成し、AD グループ全体を RDS for SQL Server インスタンスに追加できます。このアプローチでは、AD グループにユーザーを追加または削除することで、データベースへのアクセスをディレクトリレベルで直接管理できます。 次の図は、このアーキテクチャを示しています。 Windows オペレーティングシステムでは、NTLM と Kerberos という 2 つの一般的なクライアント / サーバー認証方法があります。ただし、次の理由から NTLM よりも Kerberos の方が推奨されます。 チケット発行サービス、キー管理機能の 2 つのパートから構成されています。 暗号化を使用してネットワーク上でパスワードをキャッシュしたり転送したりしないためセキュリティが向上します。 Kerberos には、MiTM (中間者) 攻撃やリプレイ攻撃に対する保護機能が組み込まれています。 Kerberos により相互認証が可能になり、一部の傍受攻撃や不正アクセスを防ぐことができます。 Kerberos がユーザーの認証に失敗した場合、エンドポイントが登録された SPN (サービスプリンシパル名) ではない場合、システムは NTLM にフォールバックします。エンドポイントが登録された SPN である場合は、NTLM にフェイルバックせず失敗します。 次の表は、接続タイプをまとめたものです。 Connection Type SQL Server Connection String Login Type Auth_Scheme RDS Endpoint TestSQL.xxxxx.us-east-1.rds.amazon.com Windows Authentication NTLM RDS Fully qualified domain name (FQDN) TestSQL.octank.com Windows Authentication Kerberos RDS Endpoint TestSQL.xxxxx.us-east-1.rds.amazon.com SQL Authentication SQL RDS Fully qualified domain name (FQDN) TestSQL.octank.com SQL Authentication SQL 注意 : Always On の可用性グループリスナーは、Kerberos 認証をサポートしていません。 データベース認可 データベース認可に関しては、ロールと権限を使用してデータベースデータへの認可アクセスをユーザーレベルで制限する方法に焦点を当てています。 アプリケーション内でマスターユーザーを直接使用しないことを強くお勧めします。代わりに、アプリケーションに必要な最低限のアクセス権を持つデータベースユーザーを作成するベストプラクティスを採用してください。そうすることで個別のユーザーアカウントを作成することになり、各ユーザーには職務の義務を遂行するために必要な権限のみが付与されます。ロールベースのアクセス (RBAC) 制約を採用して、常に最小特権セキュリティを使用してください。 RBAC は一般にユーザーにデータベースへの読み取り専用アクセスを与えることで、最小限の権限を強制するために使用されます。 Amazon RDS を使用すると、ライフサイクル全体を通じてマスターユーザー認証情報を AWS Secrets Manger に保存および管理できます。 AWS Secrets Manager では 4 時間ごとにシークレットをローテーションできると同時に、同じマネージドローテーションエクスペリエンスを提供できます。 以下は Secrets Manager にパスワードを保存することで得られるメリットの一部です。 RDS はアプリケーションの変更を必要とせずにデータベースの認証情報を定期的にローテーションします。 Secrets Manager は人間のアクセスやプレーンテキストビューからデータベースの資格情報を保護します。 AWS CloudTrail と Amazon CloudWatch を使用するとデータベースの認証情報を簡単に監視できます。 Secrets Manager を使用すると IAM を使用してシークレット内のデータベース認証情報へのアクセスをきめ細かく制御できます。 プライマリユーザーの権限を誤って消去した場合は、データベースインスタンスを更新して新しいプライマリユーザーのパスワードを入力することで 権限を復元することができます 。また、データベースインスタンスの作成後はプライマリユーザー名を変更できないことにも注意してください。 データベースアクセス監査 データベースを監査する場合は、SQL Server Trace または SQL Server Audit を有効にすることで実行できます。 SQL Server Trace RDS for SQL Server インスタンスには、その上で実行される T-SQL を利用するデフォルトのサーバー側トレースがあり、システムの現在の実行トレースを提供するカタログビュー sys.traces を介してアクセスできます。ディレクトリ D:\rdsdbdata がサーバー側のトレースのログなどのデフォルトの格納場所になっている事が重要です。 fn_trace_gettable 関数を使用してトレースファイルを読み取ることができます。サーバー側のトレース結果をデータベーステーブルに保存することもできます。次のコードを参照してください。 SELECT * INTO RDSTrace FROM fn_trace_gettable('D:\rdsdbdata\Log\, default); このテーブルは任意のユーザーデータベースに対して作成でき、すべてのロールオーバーファイルを含むログディレクトリ内のすべてのファイルの結果がロードされます。 Amazon RDS はデフォルトで、7 日より古いトレースファイルとダンプファイルを削除します。ただし、 rds_set_configuration ストアドメソッドを使用すると、トレースファイルの保存期間を変更できます。たとえば、次のストアドプロシージャは、トレースファイルの保持時間を 24 時間 (1440 分) に変更します。 exec rdsadmin..rds_set_configuration 'tracefile retention', 1440; SQL Server Audit RDS for SQL Server インスタンスまたは単一データベースを監査するには、データベースエンジンで発生するイベントの追跡とレポートが必要になります。ネイティブな SQL Server Audit を使用すると、サーバーレベルのイベントのサーバー監査仕様と、データベースレベルのイベントのデータベース監査仕様を含めることができるサーバー監査を設計できます。監査されたイベントは常に監査ファイルに記録されます。 オプショングループを使用すると、RDS for SQL Server インスタンスで監査を有効にすることができます。 Amazon RDS ではデフォルトのオプショングループを変更できないため、新しいオプショングループを作成して sqladuit のオプションを追加する必要があることに注意してください。 これらの監査ファイルが削除され、 Amazon Simple Storage Service (Amazon S3) に移行される前に、それらをディスク上に保持するオプションが提供されます。監査ファイルはアカウントの S3 バケットに保存されます。監査ファイルは Amazon S3 に保存される前に圧縮されるため、Amazon S3 のコスト削減に役立ちます。 IAM ロールを定義することは、バケットにファイルを書き込む権限を Amazon RDS に付与するため重要です。 これは FedRAMP および HIPAA 監査用に予約されている名前領域であるため、監査ファイルは RDS_ で始まるべきではありません。 ファイルサイズは 2 ～ 50 MB の制限範囲内にすることをお勧めします。そうしないと、これらのファイルの Amazon S3 へのコピーが影響を受ける可能性があります。 AWS は、指定された保存期間の監査ログを保存してアーカイブします。デフォルトでは保持オプションは無効になっており、指定された S3 バケットに監査ログがオフロードされると AWS が監査ログを削除します。この動作は 1 ～ 840 時間の間で任意の値を設定することで変更できます。 ストアドプロシージャ rds_fn_get_audit_file を使用して、SQL Server のサーバー監査によって作成された監査ファイルから情報を取得します。監査が失敗した場合は、 シャットダウンせずに続行するか 、 操作を失敗するか 、のオプションを選択できます。 サーバーレベルの監査は、SQL Server のすべてのエディションでサポートされています。 SQL Server 2016 (13.x) SP1 では、すべてのバージョンでデータベースレベルの監査が可能です。以前は、データベースレベルの監査は Enterprise、Developer、および Evaluation エディションでのみ利用可能でした。 Amazon RDS for SQL Server は、データベースアクティビティストリームをサポートするようになりました。これにより、リレーショナルデータベースでのログインの失敗などのデータベースアクティビティのほぼリアルタイムのストリームを確認できるようになります。詳細については、「 データベースアクティビティストリームを使用した Amazon RDS for SQL Server の監査 」を参照してください。 データベースの暗号化 このセクションでは、転送中のデータ暗号化、保存時の暗号化、および透過的データ暗号化 (TDE) について説明します。 転送中のデータ暗号化 Secure Sockets Layer (SSL) を使用して、クライアントアプリと SQL Server を実行している RDS データベースインスタンス間の通信を暗号化できます。これを実現するには、 パラメータグループ を通じて rds.force_ssl パラメータを有効にします。デフォルトでは、 rds.force_ssl パラメータは 0 (オフ) に設定されています。接続で SSL の使用を強制するには、rds.force_ssl パラメータを 1 (オン) に設定します。 rds.force_ssl パラメータは静的であるため、値を変更した後に変更を有効にするためにデータベースインスタンスを再起動する必要があります。 SSL/TLS 接続は、クライアントとデータベースインスタンス間で送信されるデータを暗号化することにより、セキュリティ層を追加します。 RDS データベースインスタンスへの接続が確立されていることを確認することで、サーバー証明書によって保護のレベルがさらに高まります。これは、作成したすべてのデータベースインスタンスに自動的に展開されるサーバー証明書を検査することで実現されます。 SSL を使用して、次の 2 つの方法で RDS for SQL Server データベースインスタンスに接続できます。 すべての接続に SSL を強制する – これはクライアントには目に見えずに行われ、クライアントは利用するために何もする必要がありません。 個別の接続を SSL 暗号化する – これにより、特定のクライアントコンピューターからの SSL 接続が確立され、接続の暗号化にはクライアント側での作業が必要になります。 次のコマンドを使用すると、接続が暗号化されているかどうかを確認できます。 select ENCRYPT_OPTION from SYS.DM_EXEC_CONNECTIONS where SESSION_ID = @@SPID アプリケーションサーバー上で実行されている SQL クライアントからの接続を暗号化するには、接続文字列に encrypt=true を追加します。 JDBC 経由で接続するクライアントに SSL 暗号化を許可するには、Amazon RDS for SQL Server 証明書を Java CA 証明書 (cacerts) リポジトリに追加する必要がある場合があります。これは keytool ユーティリティを使用して可能です。証明書のダウンロードの詳細については、「 SSL/TLS を使用した DB インスタンスへの接続の暗号化 」を参照してください。 保存時のデータ暗号化 保存時の暗号化を有効にする場合は 2 つの選択肢があります。 AWS Key Management Service (AWS KMS) 暗号化キーを使用して保存時の暗号化を設定します。 SQL Server 2019 Enterprise Edition または Standard Edition を実行している場合は、透過的データ暗号化 (TDE) を利用します。 SQL Server 2019 より前は、TDE 機能は Enterprise エディションでのみ利用可能であったことに注意してください。 データベースインスタンスの作成中に、保存データの暗号化を許可するように AWS KMS を設定できます。暗号化されたデータベースインスタンスを作成するときは、クライアント制御のキーまたは Amazon RDS の AWS 管理のキーのいずれかを使用して暗号化できます。カスタマー管理キーのキー識別子を指定しない場合、Amazon RDS は AWS 管理キーを使用して新しいデータベースインスタンスを作成します。 Amazon RDS は、AWS アカウントの Amazon RDS 管理キーを生成します。 AWS アカウントには、リージョンごとに Amazon RDS 用の一意の AWS 管理キーがあります。 暗号化されたデータベースインスタンスで使用される AWS KMS キーは、構築後に変更することはできません。したがって、暗号化されたデータベースインスタンスを確立するときは、AWS KMS キーの必要性を必ず特定してください。 AWS KMS は、安全で可用性の高いハードウェアとソフトウェアを組み合わせて、クラウドスケールのキー管理ソリューションを提供します。カスタマー管理キーを構築し、AWS KMS を使用してこれらのカスタマー管理キーの使用方法を管理するポリシーを指定できます。 AWS KMS は CloudTrail をサポートしているため、AWS KMS キーの使用状況を監査してカスタマー管理のキーが正しく利用されていることを確認できます。 Amazon RDS 暗号化データベースインスタンスの制限の詳細については、「 Amazon RDS リソースの暗号化 」を参照してください。 透過的なデータ暗号化 Amazon RDS では、SQL Server データベースインスタンスを暗号化するための透過的データ暗号化 (TDE) もサポートされています。 TDE を保存時の Amazon RDS 暗号化と組み合わせて使用することもできますが、そうするとデータベースのパフォーマンスに多少の影響が出る可能性があります。暗号化手法ごとに個別のキーが必要です。 TDE は、データをストレージに書き込む前に自動的に暗号化し、ストレージから読み取るときにデータを復号化します。 2 層のキーアーキテクチャで暗号化キーを管理します。データ暗号化キーを保護するために、データベースの主キーから発行された証明書が使用されます。データベース暗号化キーは、ユーザーデータベース上のデータの暗号化と復号化を担当します。 Amazon RDS は、データベースの主キーと TDE 証明書を保存および管理します。 データベースインスタンスが TDE 対応の オプショングループ にリンクされていない場合は、2 つのオプションがあります。オプショングループを作成するか、対応するオプショングループを変更することで TDE オプションを追加できます。 暗号化されたデータベースが少なくとも 1 つあるデータベースインスタンス上にデータベースがある場合、暗号化されていないデータベースのパフォーマンスが低下する可能性があります。そのため、暗号化されたデータベースと暗号化されていないデータベースを異なるデータベースインスタンスに保持することをお勧めします。 SQLSERVER BACKUP RESTORE および TRANSPARENT DATA ENCRYPTION オプションをデータベースインスタンスに関連付けられたオプショングループに追加する必要があります。 TDE 証明書は、RDS for SQL Server ストアドプロシージャを使用してバックアップ、復元、および削除できます。 Amazon RDS for SQL Server には、回復されたユーザー TDE 証明書を検査する機能があります。 追加の戦略 次の戦略を使用してデータを保護することもできます。 行レベルのセキュリティ – データベースユーザーのアクセスを自分の部門またはビジネスに関連するデータ行のみに制限する場合は、行レベルセキュリティ (RLS) を使用します。 RLS は、データ行アクセス制御の実装を支援します。 RLS を使用すると、アプリケーションのセキュリティの設計とコーディングが容易になります。これにより、アプリケーション層でアクセス制限メカニズムを維持するという依存関係がなくなります。代わりに、データベースシステムは、これらのアクセス制限を実装するためのプレースホルダーとして機能します。適切なテーブル値フィルター関数とセキュリティポリシーを設定すると、RLS を実装してセキュリティ設計の堅牢性と強度を強化できます。 RLS は、RDS for SQL Server 2016 (13.x) で実装された機能で、2016 SP1 以降からは全てのエディションでサポートされています。 データマスキング – データマスキングは、侵入者がアクセスした場合に役に立たないように機密情報を隠すことを可能にするもう 1 つのデータセキュリティ戦略です。機密データを非特権ユーザーからマスクして保護します。デフォルトでは、データベース所有者は例外です。マスクされたデータは、概念実証またはデータ自体が必要ないその他のユースケースで元のデータを置き換えるために使用されます。繰り返しますが、データマスキングメカニズムはデータベースレベルで実行されるため、アプリケーションは現在のクエリを変更することなく機密データを隠すことができます。利用可能なマスキング形式は多数あります。さまざまな機密データカテゴリの個別のニーズに基づいて形式を選択します。データマスキングは、RDS for SQL Server 2016 (13.x) で実装された機能で、2016 SP1 以降からは全てのエディションでサポートされています。 Always encrypted – このデータ暗号化アプローチは、アプリケーションとデータベースサーバー間のデータ転送中、保存中のデータ、およびデータの使用中の機密情報の保護に役立ちます。プレーンテキストを暗号化形式に変換することで、データベースシステム内で機密データが常に暗号化されて表示されることが保証されます。この方法では、テーブルまたはデータベース全体ではなく、選択した列のみが暗号化されることに注意することが重要です。適切な暗号化手法と暗号化キー (列暗号化キーと列主キー) を使用して列を効果的に暗号化できます。暗号化キーを定期的にローテーションすることで、組織のルールやコンプライアンス法を遵守できます。暗号化された列はかなり多くのスペースを必要とすることに注意してください。この機能は、2016 RDS for SQL Server 2016 (13.x) で実装された機能で、2016 SP1 以降からは全てのエディションでサポートされています。詳細については、「 Amazon RDS for SQL Server を使用した Always Encrypted のセットアップ 」を参照してください。 SQL Server トリガー – トリガーは、特定の条件が満たされた場合に保存されている一連の命令を実行するオブジェクトです。これらを使用すると、オブジェクトへの不正な更新を回避したり、DML や DDL トリガーを使用して新しいログイン認証情報を作成したり、ログオントリガーを使用して Amazon RDS for SQL Server インスタンスに対する合計接続数を制限したりできます。これらのトリガーを Amazon CloudWatch アラームと組み合わせて使用すると、セキュリティポリシーに違反したときに自動メールを送信できます。 列レベルの暗号化 – このアプローチは、より詳細なレベルでデータを暗号化してすべての列または選択した列に適用できます。列レベルの暗号化を使用すると、列ごとに個別の暗号化キーを指定できます。詳細については、「 Amazon RDS for SQL Server での列レベルの暗号化 」を参照してください。 データベース監視 CloudWatch を使用すると、環境内の異常なアクティビティを特定してアラートを作成、自動アクションを実行して問題を解決できます。エラーと SQL エージェントのログが CloudWatch Logs に公開されるように、[ログエクスポート] オプションを必ず選択してください。 不正なログインデータや、RDS for SQL Server インスタンスのエラーログに報告されたエラーを CloudWatch に公開できます。 Amazon Simple Notice Service (Amazon SNS) を使用して、CloudWatch ロググループ、パターン、アラームに基づいてエンドユーザーに通知を提供できます。 SQL Server ログの CloudWatch Logs への公開はデフォルトでは有効になっていないことに注意してください。さらに、トレースファイルとダンプファイルの公開はサポートされていません。 SQL Server ログの CloudWatch Logs への公開は、アジアパシフィック (香港) を除くすべてのリージョンでサポートされています (この記事の執筆時点) 。 次の図は、CloudWatch を使用したアーキテクチャの例を示しています。 詳細については、「 Amazon RDS for SQL Server のモニタリングとアラートを設定する方法のベストプラクティス 」を参照してください。 追加の AWS サービス 次のサービスを使用して、セキュリティフレームワークの構築を支援することもできます。 AWS Trusted Advisor – AWS Trusted Advisor は、セキュリティ専門家によって厳選されたコアセキュリティのベストプラクティスを推奨します。これは、AWS 環境のセキュリティの向上に役立つ可能性があります。たとえば、Trusted Advisor は、RDS セキュリティグループのアクセスリスク、保護されていないアクセスキー、不要な S3 バケットのアクセス許可、ルートアカウントの MFA を特定できます。 Amazon Macie – Amazon Macie は、機械学習とパターンマッチングを採用したフルマネージドのデータセキュリティ ソリューションで、RDS for SQL Server インスタンス内の機密データの検出と保護を支援します。この手順は、Parquet で圧縮されたデータベースのスナップショットをキャプチャし、Amazon S3 に保存することを目的としています。その後、機密データを検索する Macie タスクを開始できます。その後、 Amazon Athena と Amazon QuickSight を使用して機密データを読み取り、分析できます。 まとめ この投稿では、接続、ネットワーキング、さまざまなセキュリティの選択に関するベストプラクティスを含め、Amazon RDS for SQL Server を適切に使用する方法の包括的な概要を説明しました。提供されたソリューションのレビューに基づいて、データベースに適切なセキュリティ方法を決定できます。 TDE 証明書のローテーションの詳細については、「 Amazon RDS for SQL Server での TDE 証明書のローテーション 」を参照してください。セキュリティパラメータのカスタマイズの詳細については、「 Amazon RDS for SQL Server のセキュリティパラメータのカスタマイズ 」を参照してください。 Amazon RDS のセキュリティの詳細については、「 Amazon RDS のセキュリティ 」を参照してください。 このトピックに関して質問や推奨事項がある場合は、コメントを残してください。 著者について Suprith Krishnappa C は、アマゾンウェブサービスのプロフェッショナルサービスチームのデータベースコンサルタントです。彼は企業顧客と協力して、データベースプロジェクトに関するテクニカルサポートや顧客ソリューションの設計を提供するほか、既存のデータベースを AWS クラウドに移行して最新化するのを支援しています。 Santhosh Srinivasan は、アマゾンウェブサービスのプロフェッショナルサービスチームに所属するシニアクラウドアプリケーションアーキテクトです。金融サービス業界を中心に、クラウドでの大規模エンタープライズアプリケーションの構築とモダナイゼーションを専門としています。     翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 今週号は各サービスの対応リージョン拡張のニュースが凄く多かったのですが、何よりも注目すべきは Amazon Bedrock の一般利用開始ですね。生成系AIアプリケーションにおいて大規模言語モデルや基盤モデルは中核をなすものですが、それ自体を安定的に稼働させ続けたり負荷に応じてスケーリングさせることが重要です。また、用途に応じたモデルを自分たちのデータを利用してカスタマイズするファインチューニングすることが必要になることもあります。こういった用途にあわせて開発されたサービスがAmazon Bedrockですので、ぜひ詳細を確認してみてください。 それでは、9 月 25 日週のアップデートを振り返ってみましょう。 2023 年 9 月 25 日週の主要なアップデート 9/25(月) Amazon EC2 Serial Consoleが大阪ほか10のリージョンでご利用可能に オンプレミスのハードウェアを触ってきたエンジニアの方にとっては懐かしく感じるかもしれませんが、Amazon EC2ではシリアルコンソールにアクセス可能です。このシリアルコンソールへのアクセス機能が大阪リージョンをはじめ11のリージョンでご利用いただけるようになりました。 9/26(火) Amazon DynamoDBがAmazon S3に対する増分エクスポートに対応 Amazon DynamoDBで、増分エクスポート機能(Incremental Export)が利用できるようになりました。指定した時間間隔内で変更されたデータのみをエクスポートするという風に動作し、DynamoDBで発生した変更を順次データレイクに流し込み分析する、といった用途で便利な機能です。 ブログ記事 もどうぞ。 Amazon EC2 Hpc7gインスタンスが東京リージョンほか2つのリージョンで利用可能に AWS Gravitonプロセッサを搭載したHPC向けのEC2インスタンス、Hpc7gインスタンスが東京・アイルランド・GovCloud(米国西部)の各リージョンでご利用いただけるようになりました。 Amazon MSKがApache Kafkaのバージョン3.5.1をサポート Amazon Managed Streaming for Apache Kafka(Amazon MSK)が Apache Kafkaのバージョン3.5.1 をサポートしました。新規に起動するクラスタと、既存のクラスタの双方でご利用いただけます。 Amazon EKSとAmazon EKS DistroでKubernetesのバージョン1.28をサポート Amazon EKSとAmazon EKS Distroで Kubernetesのバージョン1.28 がご利用いただけるようになりました。詳細については ブログ記事 をご覧ください。 Amazon Chime SDK meetings APIのエンドポイントが東京ほか5つのリージョンでご利用可能に Amazon Chime SDKを利用すると、リアルタイムのビデオ通話・音声通話の機能をアプリケーションに簡単に追加することが可能です。今回、ミーティングを作成・管理するためのAmazon Chime SDK meeting APIのエンドポイントが東京を始め6つのリージョンでご利用いただけるようになりました。 9/27(水) Amazon S3で削除マーカーに対する最終更新日時を提供開始 Amazon S3でHead/Get APIをリクエストした際に、削除マーカーの最終更新日時(Last-Modified Time)情報を取得できるようになりました。バージョニングが有効になっているバケットでは、オブジェクト削除を行うとデータが物理的に削除される代わりに削除マーカーが作成され、削除されている状態を論理的に表現します。この削除マーカーの最終更新日時が取得できるようになったということは、データ削除が行われた日時を容易に追跡できるようになった事を意味します。バケット内で発生した変化をトラッキングする必要がある場合に便利な機能です。 Amazon EC2 Instance Connectが大阪リージョンほか10のリージョンで利用可能に いわゆる踏み台サーバを利用することなく、パブリックなIPアドレスを持たないインスタンスへのSSH/RDP接続を可能にするEC2 Instance Connectが、大阪リージョンをはじめ11のリージョンで利用できるようになりました。 9/28(木) Amazon Bedrockが一般利用開始に 基盤モデルを利用した生成系AIアプリケーションを簡単に開発・スケーリングできるようにするためのサービス、Amazon Bedrockが一般利用開始になりました。様々な用途に合わせてAI21 Labs, Anthropic, Cohere, Meta, Stability AI, Amazonなどが提供する基盤モデルから最適なものを選択し、APIを利用してアプリケーションから呼び出すことで、アプリケーションの開発や運用維持を容易に実現します。 ブログ記事 や 料金設定のページ もご覧ください。 Amazon Titan Embeddingsが一般利用開始に 自然言語テキストを数値表現に変換する埋め込みモデルであるAmazon Titan Embeddingsが一般利用開始になりました。単語やフレーズ、ドキュメントなどの自然言語を利用して、意味的な類似性に基づいて検索したりパーソナライズする際に利用でき、検索拡張生成(RAG)という生成系AIアプリケーションで利用されるアプローチにも応用可能です。Titan Embeddingsは25の言語をサポートしています。 Amazon QuickSightのGenerative BI機能によるダッシュボード作成がプレビュー可能に Amazon QuickSightで3つのGenerative BI(生成系BI)機能をプレビューできるようになり、自然言語で指示することで求める出力結果を得ることができるようになりました。ひとつめはどのように可視化したいかを指示できる機能。ふたつめは複雑な計算を実行する機能。みっつめはダッシュボード上のグラフなどの見た目を調整する機能です。ちなみに、QuickSightのGenerative BI機能はAmazon Bedrockを利用して構築されています。 Amazon SageMaker Canvasによる予測が最大50%高速に コード開発不要で機械学習による予測を可能にするAmazon SageMaker Canvasで、精度とパフォーマンスを向上するためのアップデートが行われました。予測モデルの作成が最大50%高速になり、同時にモデルを利用した予測処理も最大45%高速になりました。 9/29(金) Amazon Inspectorが大阪ほか3つのリージョンで利用可能に 継続的な脆弱性管理を自動的かつ大規模に実行することを容易にする、Amazon Inspectorが大阪リージョンをはじめ4つのリージョンでご利用可能になりました。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )

本日 (2023 年 9 月 28 日)、AWS Amplify JavaScript Library の v6 Developer Preview を発表しました。これは、AWS クラウドバックエンドを使用した Web 開発へのアプローチ方法を改善するマイルストーンリリースです。私たちは皆様からのフィードバックに耳を傾けており、本日の発表では GitHub で皆様から寄せられていたバンドルサイズや、TypeScript と Next.js のサポートに対するリクエストのいくつかに対応しました。それでは早速、Amplify JavaScript v6 Developer Preview の新機能をご紹介します！ バンドルサイズの縮小によってアプリのロード時間を改善 スピードは贅沢品ではなく、必要不可欠なものです。そのため、私たちは ツリーシェイキング機能 と基盤となるインフラを改善しました。バンドルサイズを小さくすることで、アプリケーションのロード時間が短縮され、高速ブロードバンドであろうと、断続的な接続であろうと、ユーザーを飽きさせず、満足させることができます。 新しい Developer Preview 版では、Amplify は、カテゴリ全体ではなく、Amplify Auth や Storage などの各カテゴリから、アプリに必要な API のみをインポートします。 未使用の機能はツリーシェイクで除外されます。このツリーシェイク機能を実現するために、私たちはクラスベースの開発者体験から関数ベースの開発者体験へと移行しています。 関数ベースの開発者体験は、2 つの重要な点で Amplify JavaScript v5 とは異なります。 [赤色の下線部] カテゴリごとにクラスをインポートする代わりに、サブパスから特定の機能をインポートする必要があります。 [紫色の下線部] 関数のパラメータがオブジェクトになり、API の読みやすさを向上させるために「名前付きパラメータ」になりました。 TypeScript 体験の向上 私たちのチームは、TypeScript が多くのチームの開発ワークフローに不可欠なものとなり、より大規模で複雑なプロジェクトを管理しやすくなり、高い安全性のレベルを提供していることを理解しています。そのため、今回の Developer Preview では、Auth, Analytics, Storage の各カテゴリを皮切りに、TypeScript のサポートを強化しています。この TypeScript の機能強化は、GraphQL API や REST API を含むすべてのカテゴリに拡大していく予定です。 これらの TypeScript の強化により、より豊富なシンタックスハイライト、コード補完、ストリクトモードのサポートが得られます。また、アプリを実行する前にバグを特定するのに役立つ型チェックも忘れてはなりません。 Next.js App Router, API Routes, Middleware のサポート Next.js から利用可能なすべての機能に対する総合的なサポートを提供してほしいというのが、私たちのコミュニティからの頻繁な要望でした。これを念頭に置いて、Next.js の機能を組み込み、新しい Next.js アダプタを作成しました。Server Side Rendering (SSR), Middleware, Server Functions, App Router など、使いたい Next.js の機能に関係なく、Amplify JavaScript ライブラリでカバーできます。 Next.js アダプタは、Amplify Libraries を “Amplify Server Context” 内で実行することを可能にし、クラウド上で Amplify Libraries の機能を安全に使用する方法を提供します。 runWithAmplifyServerContext コールバックは、リクエストをサーバーサイドで自動的に分離し、クロスリクエストの状態汚染問題を回避します。 以下は、保護されたルートを実装するために、Next.js Middleware で Amplify Auth を使用する方法の例です。 import { runWithAmplifyServerContext } from '@aws-amplify/adapter-nextjs'; import { fetchAuthSession } from 'aws-amplify/auth/server'; import { NextRequest, NextResponse } from 'next/server'; export async function middleware(request: NextRequest) { const response = NextResponse.next(); const authenticated = await runWithAmplifyServerContext({ nextServerContext: { request, response }, operation: async (contextSpec) => { try { const session = await fetchAuthSession(contextSpec, {}); return session.tokens !== undefined; } catch (error) { console.log(error); return false; } }, }); if (authenticated) { return response; } return NextResponse.redirect(new URL('/sign-in', request.url)); } export const config = { matcher: [ /* * Match all request paths except for the ones starting with: * - api (API routes) * - _next/static (static files) * - _next/image (image optimization files) * - favicon.ico (favicon file) */ '/((?!api|_next/static|_next/image|favicon.ico|sign-in).*)', ], }; 始め方 これらの新しい機能拡張については、 ドキュメント をご覧ください。お客様がすぐに使い始められるよう、豊富なガイドと実用例をご用意しています。また、今後の機能拡張については Q4 のフォーカスエリア もご覧ください。 この Developer Preview は、AWS Amplify をモダンなアプリケーション開発のための最適なソリューションにするという我々のコミットメントを反映しています。しかし、まだ Day1 です。新機能をお試しいただき、 この RFC でご意見をお聞かせください 。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

Amazon Relational Database Service (Amazon RDS) for SQL Server は、 AWS Nitro System 上に構築された第3世代のIntel Xeon Scalable (Ice Lake) プロセッサを搭載する X2iedn をサポートするようになりました。SQL Serverのワークロードはメモリに大きく依存します。そのため、メモリに最適化された Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが最も一般的に利用されています。 x2iedn インスタンスタイプは、最大 4096 GiB の RAMと 128 個の vCPU を提供し、お客様の最も難易度の高いニーズを満たします。x2iedn を使用することで、お客様のワークロードは同等の X1 インスタンスよりも最大 50 %高いコストパフォーマンスを得ることができます。 Amazon RDS for SQL Serverは、x2iedn インスタンスタイプとして、4, 8, 16, 32, 64, 96, 128 vCPUの 7 つのサイズを提供しています。このブログでは、x2iedn を使用する主な利点について説明し、x2iedn インスタンスタイプと x1e インスタンスタイプで測定したパフォーマンスを比較します。詳細については、 Amazon EC2 X2idn および X2iedn インスタンスの紹介 を参照してください。 特徴 新しいインスタンスタイプは、以下の機能を提供します。 最大 3.5 GHz の第 3 世代 Intel Xeon Scalable プロセッサ（Ice Lake 8375C） すべてのサイズで vCPU に対するメモリの比率は 32 : 1 X1 インスタンスより最大 50 %優れた価格性能 最大 100 Gbpsのネットワーク速度 Amazon Elastic Block Store（Amazon EBS）への帯域幅は最大 80 Gbps 専用ハードウェアと軽量ハイパーバイザーを組み合わせた Nitro System を搭載 次の表は、インスタンスタイプのそれぞれの仕様をまとめたものです。 Instance Name vCPUs Memory (GiB) Storage Memory (GB) Network Bandwidth (Gbps) EBS Bandwidth (Gbps) x2iedn.xlarge 4 128 1 x 118 NVMe SSD Up to 25 Up to 20 x2iedn.2xlarge 8 256 1 x 237 NVMe SSD Up to 25 Up to 20 x2iedn.4xlarge 16 512 1 x 475 NVMe SSD Up to 25 Up to 20 x2iedn.8xlarge 32 1,024 1 x 950 NVMe SSD 25 20 x2iedn.16xlarge 64 2,048 1 x 1900 NVMe SSD 50 40 x2iedn.24xlarge 96 3,072 2 x 1425 NVMe SSD 75 60 x2iedn.32xlarge 128 4,096 2 x 1900 NVMe SSD 100 80 利点 x2iedn RDS DB インスタンスタイプには以下のメリットがあります。 Nitro System 上に構築 – Nitro System は EC2 インスタンスに最新のハードウェアとソフトウェアコンポーネントを提供し、全体的なパフォーマンスを向上させます。さらに、Nitro System 上に構築された RDS DB インスタンスは、高速ネットワーキング、高速 EBS 帯域幅、 I/O アクセラレーションを可能にする専用の Nitro Cards を利用できます。これらの改善により、X1 インスタンスと比較して SQL Server データベースのパフォーマンスが最大 50 %向上します。 vCPU あたりの高いメモリ比率 – X2 インスタンスファミリーは、サポートされているすべての RDS DB インスタンスタイプと比較して、 vCPU あたりのメモリ比率が最も高くなっています。これは、 SQL Server Enterprise Edition や Standard Edition など、コア単位のライセンスに依存する SQL Server ワークロードに最適です。お客様のワークロードは、 X2iedn が提供する vCPU あたりのより大きいメモリ（ 32 GB : 1 vCPU ）によって、 vCPU のプロビジョニング数を減らすことができます。サポートされる RDS インスタンスタイプの詳細については、 Amazon RDS インスタンスタイプ を参照してください。 高いネットワークと EBS スループット – X2iedn では、最大 100 Gbps のネットワーク帯域幅と 80 Gbps の EBS 帯域幅を実現できます。 x1e の最大ネットワーク帯域幅が 25 Gbps、EBS 帯域幅が 14 Gbps であることと比較すると、その差は歴然です。スループット要件を満たすために、より大きなインスタンスサイズをプロビジョニングする必要がなくなります。これにより、抽出、変換、ロード（ ETL ）処理や SQL Server のネイティブバックアップなど、スループット負荷の高いタスクをパフォーマンスに影響を与えることなく実行できます。 ローカル NVMe（インスタンスストア） – tempdb がローカルインスタンスストレージを使用するように構成された状態で X2iedn を起動できます。 tempdb のデータファイルとログファイルをローカルに配置することで、標準的な Amazon EBS ベースのサービスと比較して、読み取りと書き込みのレイテンシを低く抑えることができます。 X2iedn RDS DB インスタンスは、最大 3,600 GB の NVMe（ Non-Volatile Memory Express ）SSD ベースのインスタンスストレージを提供し、低レイテンシ、非常に高いランダム I/O パフォーマンス、および高いシーケンシャルリードスループットを実現するように最適化されています。 X2iedn インスタンスタイプでインスタンスをプロビジョニングする際、 Amazon RDS for SQL Server は自動的にローカルに接続された NVMe ディスクに tempdb ファイルを配置し、ストレージレイテンシーを低減し、特定のワークロードのパフォーマンスを最大 30 %向上させます。AWSのドキュメントを参照して、 マルチ AZ 配置に関する考慮事項 と ファイルの場所とサイズの考慮事項 についてもご確認ください。   x1e インスタンスと x2iedn インスタンスの性能比較 パフォーマンスベンチマークツールである HammerDB を実行し、パフォーマンスを比較検証しました。 HammerDB を使用してテストをベンチマークする方法の詳細については、 HammerDB を使用して Amazon RDS SQL Server のパフォーマンスをベンチマークする を参照してください。 SQL Server 2019 Enterprise Edition 環境に、10,000 warehouses (データベースサイズ 約1TB) のTPC-C データベースを作成しました。プロビジョニングされたストレージは io1 ボリュームタイプで約 2 TB、32 k PIOPSでした。オートパイロット機能のサンプリングを 3 回使用し、各実行では仮想ユーザー（ VU ）の数を設定しました（64、128、256、324、512、724に設定）。 次の表は、各インスタンスの特徴をまとめたものです。 Instance Size vCPUs RAM (GiB) Local NVMe SSD Storage (GB) Network Bandwidth (Gbps) EBS-Optimized Bandwidth (Gbps) db.x1e.4xlarge 16 488 1 x 475 Up to 10 1.75 db.x2iedn.4xlarge 16 512 1 x 475 Up to 25 Up to 20 以下の画像はパフォーマンス結果を示しています。 このパフォーマンス結果から、同じような構成の x1e インスタンスタイプと比較して、85 %高いパフォーマンスを達成することができました。 結論 Amazon RDS for SQL Server データベースを X1e インスタンスで運用している場合は、インスタンスタイプを X2iedn に変更してパフォーマンスを向上させることを検討してください。本番インスタンスを変更する前に、別の環境で インスタンスクラスの変更 をテストすることをお勧めします。インスタンスタイプの変更にはダウンタイムが必要です。メンテナンウィンドウを設定して、変更を実施することができます。 本ブログはSolution Architect 塚本によって翻訳されました。原文は こちら   著者について Sudhir Amin Amazon Web Services のデータベーススペシャリスト・ソリューションアーキテクト。ニューヨークを拠点に、さまざまな業種の企業顧客にアーキテクチャのガイダンスと技術支援を提供し、クラウド導入を加速させている。スヌーカー、ボクシングやUFC などの格闘技の大ファンで、野生動物保護区のある国を旅行し、世界で最も雄大な動物を間近で見るのが趣味。 Vikas Babu Gali Amazon Web Services でマイクロソフトのワークロードを担当するシニアスペシャリスト・ソリューションアーキテクト。インド出身で、趣味はクリケットや、家族や友人とアウトドアをすること。 Julio Oliveira Leme Amazon Web Services データベースエンジニア。2018年に AWS に入社し、RDS SQL Server チームのプロジェクトで新機能やエンジンバージョンのリリースに携わる。趣味は読書と友人や家族と過ごすこと。

­ はじめに 世界中の報道機関やメディア企業が AWS Elemental MediaLive を使用して、インフラストラクチャを管理することなく、高速で信頼性が高く、使いやすい高品質のライブ動画ストリームを配信しています。MediaLive は、ライブストリームの処理と配信のための取り込みとエンコーディング用コンポーネントの設定・管理を自動化することで、ライブ動画のオペレーションを効率化します。現時点では、MediaLive チャネルがアイドル状態で、出力をストリーミングしていないときに自動的に停止させる方法はありません。ライブストリーミングが停止しても、MediaLive チャネルは稼働し続けるため、コストがかかってしまいます。入力がない間はチャネルを停止させたい場合、お客様が手動で停止させる必要があります。 本記事では、MediaLive がどこにもストリーミング出力していないときに MediaLive チャネルを停止させるための完全に自動化されたソリューションを構築する方法、およびお客様がコストを節約できる方法について説明します。 一部の MediaLive リソースについては、アイドル時でも少額の料金が発生することにご留意ください。詳細については、MediaLive の 料金 を確認してください。 前提条件 本記事は、次の前提条件に基づいています。 1.    Single pipeline の、RTMP プッシュ入力による MediaLive チャネルが構成済みである。 2.    チャネルに冗長入力がアタッチされていない。 3.    MediaLive チャネルにファイル入力が設定されていない 4.    MediaLive チャネルの入力損失タイマーはユーザー定義で 10 分に設定されている。MediaLive チャネルのアラートを 10 分間監視した後にチャネルを停止する 5.    MediaLive チャネルにアタッチされた入力は再利用できるため削除しない アーキテクチャ このブログでは、ライブストリーミングソフトウェアとして OBS Studio を使用しています。OBS は、Mac、Windows および Linux と互換性のある、オフラインビデオ録画とライブストリーミング用の無料のオープンソースソリューションです。 MediaLive はライブフィードを取り込み、リアルタイムでエンコードし、放送用の高品質のストリームに圧縮します。MediaLive チャネルには、Standard と Single pipeline の 2 種のチャネルクラスオプションがあります。今回のライブ信号の入力設定には、Single pipeline チャネルを使用します。チャネル設定には、入力を特定の出力にトランスコード (デコードおよびエンコード) してパッケージ化する方法を MediaLive に指示する詳細情報が含まれています。MediaLive は、チャネル内のいずれかのパイプラインで問題、または潜在的な問題が発生すると、アラートを生成します。各アラートの詳細は、MediaLive コンソールの [Alerts] タブに表示されます。 Amazon EventBridge は、コードを記述しなくても、AWS サービスのデータの変更や、独自のアプリケーション、およびサービスとしてのソフトウェア (SaaS) アプリケーションにリアルタイムでアクセスできるようにするサービスです。今回、EventBridge を使って、MediaLive チャネルのアラートを監視するルールを 2 つ作成します。1 つ目のルールは、アラート状態が「SET」でアラートタイプが「RTMP Has No Audio/Video」に一致した受信イベントパターンのアラートをターゲットの AWS Step Functions に送信します。そこでさらに処理が行われます。2つ目のルールは、アラートタイプが「RTMP Has No Audio/Video」に一致した受信イベントパターンをターゲットの Amazon CloudWatch に送信します。CloudWatch は、AWS のクラウドリソースやお客様が AWS で実行するアプリケーションを監視するサービスです。CloudWatch を使用して、メトリクスの収集と追跡、ログファイルの収集と監視、アラームの設定を行うことができます。 Step Functions は、視覚的なワークフローを使用して分散アプリケーションやマイクロサービスのコンポーネントを簡単に調整できるフルマネージドサービスです。ここでは、Step Functions内に、 AWS Lambda 関数 2 つおよび待機状態 1 つから成るワークフローを作成します。 AWS Lambda を使うと、サーバーのプロビジョニングや管理をすることなく、コードを実行することができます。Lambda を使うことで、事実上あらゆるタイプのアプリケーションやバックエンドサービスのコードをインフラストラクチャ管理なしで実行できます。1 番目の Lambda 関数は、カスタムの Amazon SNS 通知 E メールをユーザーに送信します。Amazon SNS は、通知を簡単に設定、操作、送信できるウェブサービスです。Step Functionsワークフローはここで、2 番目のLambda関数を呼び出す前に10分間の待機状態に入ります。これは、MediaLive チャネルのユーザー定義の入力損失待機時間を 10 分にした前提条件に基づくものです。2 番目の Lambda 関数は、CloudWatch ログをフィルタリングして MediaLive アラートがクリアされたかどうかを確認し、クリアされていない場合には MediaLive チャネルを停止します。 事前準備 以下のサービスへのアクセス許可を持った AWS アカウントが必要です。 AWS Elemental MediaLive AWS Elemental MediaPackage Amazon CloudFront AWS Lambda Amazon CloudWatch AWS Identity and Access Management (AWS IAM) AWS Step Functions Amazon SNS Amazon EventBridge AWS CloudFormation 本記事では、 AWS Media Services を使用してライブストリーミングチャネルを準備する必要があります。 こちらの記事 に従い、フルマネージドの AWS Media Services を使用したエンドツーエンドのライブストリーミングチャネルを作成してください。 ステップ 1: CloudFormation テンプレートをデプロイする AWS Console にサインインする 下の [Launch Stack] ボタンをクリックして、任意のリージョンに CloudFormation テンプレートをデプロイします。 お客様の E メールアドレス を入力してください。これは SNS 通知の宛先になります。 前提条件の手順で作成した MediaLive チャネルの ARN をコピーして、 MediaLive Arn テキストボックスに貼り付けます。 次に、確認ボックスにチェックを入れ、 [Create] をクリックします。 CloudFormation テンプレートは、お客様の AWS アカウントに以下のサービスをデプロイします。 AWS Lambda Amazon CloudWatch AWS Step Functions Amazon SNS Amazon EventBridge ワークフローの流れ まず始めるにあたり、MediaLive チャネルが稼働していて、OBS のソースからコンテンツがストリーミングされている必要があります。 OBS からのストリーミングを停止します。すると、MediaLive チャネルにアラートが発生します。 EventBridge ルールはアラートを監視し、受信イベントのパターンを照合して、イベントまたはペイロードをターゲット（Step Functions や CloudWatch ロググループ）に送信します。 Step Functions のワークフローは、Lambda 関数 2 つおよび待機状態 1 つで構成されています。 ワークフローが 1 番目の Lambda 関数を呼び出すことで、ユーザーに SNS 通知が送信されます。 その後、ワークフローは 10 分間の待機状態に入ります（ユーザー定義の待機時間）。 待機状態の終了後、2 番目の Lambda 関数が呼び出され、CloudWatch ロググループをフィルタリングすることで、MediaLive チャネルによって生成されたアラートがクリアされたかどうかを確認します。クリアされていない場合には、MediaLive チャネルを停止します。 費用に関する免責事項 このワークフローの構築に必要な AWS リソースは 無料利用枠 の対象ではないため、実行中には追加費用が発生します。このワークフローの実行中に使用した AWS サービスの費用は、お客様のご負担となります。リソースの長時間稼働による料金が発生しないように、作業完了後は必ずリソースをクリーンアップしてください。 クリーンアップ 完了後にさらなる料金が発生しないように、AWS Lambda、Amazon SNS、Amazon EventBridge (CloudWatch Events)、MediaLive チャネル、MediaPackage、CloudFront ディストリビューションなど、本ブログ記事に従って作成されたリソースを削除してください。 まとめ MediaLive チャネルを停止させるワークフローを自動化することで、チャネルを手動で監視する負担が軽減されます。自動化されたワークフローにより、以前よりもはるかに迅速にアラートを特定し、エラーを解決することができます。チャネルの分析と停止にかかる時間を短縮することの利点は、企業が、ストリーミング実行中でないチャネルにかかるコストを節約できることです。 エンジニアリングチームは、チャネルを手動で監視して停止させるという繰り返しの多い作業から解放されます。これは、冗長入力がアタッチされているチャネルや Standard パイプラインチャネル、ファイル入力を持つチャネルの分析へと、さらに拡張できます。 AWS は、メディア関連ワークフローの構築を支援するために設計された多数のサービスを提供しています。動画のストリーミング、処理、配信向けに、さらに他のアプリケーションを検討したい場合は、 AWS Media Services をご覧ください。   参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は BD 山口、SA 金目が担当しました。原文は こちら をご覧ください。

Amazon Timestream は高速でスケーラブルなサーバレスの時系列データベースサービスで、1 日に数兆件のイベントの保存や分析が簡単に実現出来ます。Timestream は自動的にスケールアップ、スケールダウンを行い容量とパフォーマンスを調整する為、基盤となるインフラストラクチャを管理する必要がありません。時系列データの管理に関しては、従来のリレーショナルデータベースでは、大量のタイムスタンプ付きのデータという固有の要件を満たす事が出来ませんでしたが、Timestream は時系列データ専用に設計されたアーキテクチャと、高度な組み込み時系列分析機能を備えており、時系列データの真の可能性を引き出し、意味のある洞察を得る事が出来る理想的なソリューションとなります。 本投稿では Timestream の重要な概念を説明し、それらを使用して重要なデータモデリングの意思決定を行う方法を示します。まず、データモデリングがクエリのパフォーマンスやコスト効率にどう影響するかを説明します。次に、ビデオストリーミングに関するデータをモデリングする実践例を検討し、これらの概念がどう適用されるか、及び、その結果得られる利点を示します。最後にデータモデリングに直接的または間接的に関連するその他のベストプラクティスを説明します。 Timestream の重要な概念 以下に示した Timestream の重要な概念を理解する事は、最適なデータモデリングと効果的な取り込み、クエリ、分析の為に不可欠です。 ディメンジョン – 時系列のメタデータを記述する属性です。例えば、証券取引所をディメンジョンとする場合、ディメンジョン名は証券取引所となり、対応するディメンジョン値は NYSE (ニューヨーク証券取引所) となります。 メジャー – 実際に記録される値を示します。メジャーの一般的な例としては、温度測定値、株価、クリックまたはビデオストリーミングのメトリクス、そして製造装置や、IoT デバイス、自動車に関連したその他のメトリクス等が挙げられます。 メジャー名 (デフォルトのパーティションキー) – measure_name は時系列データポイントに関連付けられた特定の測定値、又は、メトリクスの識別子を示しており、Timestream のテーブル内で様々なタイプのメジャー値を分類、及び区分する方法を提供します。この属性は 顧客定義のパーティションキー が使用されない場合、デフォルトのパーティションキーとして動作します。 顧客定義のパーティションキー – Timestream はこの項目を元に各データをパーティションを区切って分割して配置し、ストレージとクエリパフォーマンスを改善します。カーディナリティが高く、クエリで頻繁に利用される属性を選択する事で、パフォーマンスの最適化を実現できます。多くの場合、ホスト ID、デバイス ID、顧客 ID 等のディメンジョンがパーティションキーとして適切な選択肢となります。 タイムスタンプ – 特定のレコードのメジャーがいつ収集されたのかを示しています。また、Timestream はナノ秒単位のタイムスタンプをサポートしています。例えば、患者のバイタルサインを追跡する為のセンサーデータを収集する場合、UNIX 時間のフォーマットを利用して、このフィールドにデータ収集のタイムスタンプを格納します。 テーブル – 関連する一連の時系列レコードのコンテナです データベース – テーブルの最上位のコンテナです 次の図は、2 つのディメンジョン ( device_id と location ) と、 measure_name 、 time 、そして 2 つのメジャー ( quality と value ) を含む Timestream のテーブルを示しています。 device_id のカーディナリティが高く、クエリのフィルタリングによく利用されると仮定した場合、それを顧客定義のパーティションキーとして選択すると効果的です。 Timestream は柔軟なスキーマレスの構造であり、厳格なスキーマの制約を受ける事は無く、テーブル作成時に列を定義する必要はありません。また、Timestream は時系列データ専用の NoSQL であり、情報をリレーショナルテーブルには保存しませんが、SQL をサポートしています。SQL に精通したユーザは、高度な時系列関数を利用して時刻ベースのデータセットの分析を簡単に実行できます。 最適なデータモデリングはデータ品質の改善、パフォーマンス向上、ストレージコスト削減に役立ちます。Timestream での効果的なデータモデリングはクエリパターンを理解する事から始まり、パフォーマンスとコスト最適化に役立ちます。クエリパターンを理解し、ディメンジョン、メジャー、パーティション化キーを見極める事で、Timestream 内のデータを効率的に構造化出来ます。データモデリングに加えて、クエリに適切なフィルターを使用する事で、クエリを迅速かつコスト効率よく実行出来るようになります。 ビデオストリーミングデータのモデリング ビデオストリーミングアプリケーションのデータモデリングの例を通じて、これらの要素がコストとパフォーマンスにどの程度寄与するのかを見てみましょう。アプリケーションは次のデータを収集していると考えて下さい。 video_id – 各ビデオの一意の識別子 viewer_id – 動画の視聴者を識別する ID device_type – モバイル、Web、スマート TV 等、視聴者がストリーミングに使用するデバイスの種類 region – 視聴者の位置情報 session_id – 各ストリームセッションの一意となる ID start_time – 視聴者がビデオの視聴を開始した時間 playback_duration – 視聴者がビデオの視聴に費やした時間 video_resolution – ビデオの解像度 playback_quality – 720p, 1080p, 4K 等、ビデオ再生の品質 クエリを詳しく説明する前に、ビデオストリーミングアプリケーションが実行する必要がある重要なタスクを明らかにしましょう。まず、特定の動画がどの位の頻度でどの位視聴されているかを確認する事で、コンテンツの人気と視聴者のエンゲージメントを明らかにする事を目的としています。また、ユーザ体験を最適化する為に、優先するデバイスを特定し、顧客の品質の好みを評価する必要があります。さらには、地域毎の傾向を理解する事で戦略を組みなおしたり、個別のセッションの継続時間と維持率を分析する事で視聴者の行動に対する洞察を得る事が出来ます。また、エンゲージメントの高い視聴者を特定し、動画の趣向に関する傾向を見出す事も目的としています。 以下の例を使って、時系列データとクエリについて考えていきましょう。データは test データベース配下の videostreaming テーブルに格納されているとします。 session_id viewer_id device_type region video_id time start_time video_resolution playback_quality playback_duaration session_87 viewer_38 tablet Australia video_148428 2023-05-17 20:54:39.000000000 2023-05-17 20:49:39.000000000 4K Excellent 2820 session_52 viewer_86 computer Australia video_5982 2023-05-17 20:54:31.000000000 2023-05-17 20:49:31.000000000 4K Fair 1020 session_96 viewer_89 smart_tv Australia video_77868 2023-05-17 20:54:30.000000000 2023-05-17 20:49:30.000000000 720p Excellent 2340 session_45 viewer_41 computer Europe video_21191 2023-05-17 20:54:27.000000000 2023-05-17 20:49:27.000000000 720p Excellent 600 session_54 viewer_51 computer US video_115903 2023-05-17 20:54:18.000000000 2023-05-17 20:49:18.000000000 720p Good 420 クエリの例をいくつか見てみましょう。 Query 1 – 次のクエリは region でデータをフィルタリングし、過去 1 日間で米国地域で視聴されたビデオの合計回数をカウントしています (Timestream の ago() 関数 を利用) 。指定された地域でのビデオ消費量の全体像を示します。 SELECT COUNT(*) AS video_count FROM "test"."videostreaming" WHERE time >= ago(1d) AND region = 'US' Query 2 – 次のクエリは device_type に基づいてデータをグループ化し、過去 1 日分の各デバイスタイプ毎のビデオストリーミングセッションの平均時間を計算します。こうする事でデバイス毎に平均時間がどのように変化するか分析出来ます。この情報は様々なデバイスでのユーザの行動や好みを理解し、それに応じてストリーミングサービスを最適化するのに役立ちます。 SELECT "device_type", AVG("playback_duration") AS "avg_duration" FROM "test"."videostreaming" WHERE time >= ago(1d) GROUP BY "device_type" order by "avg_duration" Query 3 – 次のクエリは動画視聴時間に焦点を当て、4K 再生品質で視聴されたビデオの合計時間を算出します。この情報から帯域幅の消費量を把握したり、高品質ビデオコンテンツの需要を評価したりする事が出来ます。 SELECT SUM("playback_duration") AS "total_duration" FROM "test"."videostreaming" WHERE time >= ago(1h) and "video_resolution" = '4K' Query 4 – 次のクエリでは最も長時間視聴されているビデオを特定出来ます。この情報からビデオの品質を向上させたり、より大々的に宣伝したりできます。 SELECT "video_id", AVG("playback_duration") AS "average_playback_duration" FROM "test"."videostreaming" WHERE time >= ago(7d) GROUP BY "video_id" limit 10 Query 5 – 次のクエリで低品質で視聴されているビデオを識別出来ます。 SELECT video_id FROM "test"."videostreaming" where time >= ago(1d) and video_resolution= "720p" Query 6 – 次のクエリは viewer_id に基づいてデータをグループ化し、過去 1 日間に各ユーザが視聴したビデオの合計数を計算します。結果は降順で並べ替えられて合計数が最も多い上位 1,000 名の視聴者を特定出来ます。この情報からパワーユーザを特定したり、視聴者のエンゲージメントを判断する事が出来ます。 SELECT "viewer_id", COUNT(*) AS "video_count" FROM "test"."videostreaming" WHERE time >= ago(1d) GROUP BY "viewer_id" ORDER BY "video_count" DESC LIMIT 1000 Query 7 – 次のクエリは過去 7 日間の各視聴者の平均再生時間を計算し、上位 1,000 名の視聴者を特定します。エンゲージメントが高く、動画の視聴に多くの時間を費やしている視聴者の特定出来る為、パーソナライズされた推奨事項やターゲットを絞った広告に使用できます。 SELECT "viewer_id", AVG("playback_duration") AS "avg_duration" FROM "test"."videostreaming" WHERE time >= ago(7d) GROUP BY "viewer_id" ORDER BY "avg_duration" DESC LIMIT 1000 適切なディメンジョンとメジャーの選択 従来のデータベースから Timestream に移行する場合、既存のデータベースから Timestream にテーブルと列をそのまま移行すれば機能すると考えている方は多いと思います。ですが、本当の課題はクエリパターンを理解した上で、適切なディメンジョン、メジャー、及びオプションでパーティションキーを選択する事にあります。 レコードのタイムスタンプを含むディメンジョンは、各レコードで誰が、何を、いつ、どこで記録したかを特定するのに役立ちます。またディメンジョンはデータを整理・分類し、クエリの一部としてデータをフィルタリングする為に使用されます。ここでは、 video_id 、 viewer_id 、 device_type 、 region 及び session_id は、ビデオストリーミングを整理、分類する為の理想的な選択肢となります。これらの列を利用すると、様々な要素に基づいてデータをフィルター及びグループ化し、様々な観点で分析出来るようになります。例えば、ディメンションを使用して、デバイスの種類ごとに視聴者の趣向を理解したり、地域の視聴パターンを明らかにしたりできます。このようにディメンションを使用すると、データのクエリと分析が柔軟になり、ビデオストリーミング分析のための貴重な洞察が得られます。 メジャーは、データの数学的計算 (合計、平均、変化率の差など) と定量的分析を実行するための基礎を提供します。この例ではメジャーである start_time 、 playback_duration 、 video_resolution 、 playback_quality は、時間の経過とともに変化する視聴者のストリーミング体験に関連する重要な指標をキャプチャします。これらのメトリクスを使用すると、ビデオセッションの平均継続時間、時間の経過に伴うビデオ品質の傾向の追跡、視聴者が好むビデオ解像度の特定など、さまざまな分析を実行できます。こうして、視聴者のストリーミング行動に関する貴重な洞察が得られ、データに基づいた意思決定を行って全体的なエクスペリエンスを向上させることができます。 ただ、ディメンションまたはメジャーの説明のみに頼るだけでは不十分な場合があり、ディメンションがメジャーになる場合もあります。したがって、クエリパターンから考え始めると、何をどの属性に基づいて計算しているのかを理解しやすくなり、メジャーなのかディメンションなのかを判断するのに役立ちます。例えば、属性がデータのフィルタリングや計算にも使用される場合には、それはメジャーになります。また、ディメンションを決定する際は、特定のレコードのディメンションは更新できないこと、およびすべてのディメンションがレコードを一意に識別することを考慮することが重要です。 Timestream は、データを更新/挿入する機能 (upsert) を提供します。 即ち、レコードが存在しない場合はシステムにレコードを挿入し、レコードが存在する場合はレコードを更新する操作です。ただし、更新は、 API 内のすべてのディメンションを使用して、新しいメジャーを追加するか、既存のレコードのメジャーを更新することに限定されます。 ディメンションの数、メジャー (レコードごとの最大メジャー数、テーブル全体の一意のメジャー数)、およびレコードの最大サイズには 制限 がある為、データモデルを設計する際には、これらの要素を考慮する必要があります。多くの場合、Timestream に取り込まれるデータは、時系列分析に必要な属性以外の追加の属性を含むイベントまたはメトリクスを通じて発生します。制限に達しないようにするには、必要な属性のみをターゲットにします。データに関連性がなく、一緒にクエリを実行しない場合は、1 つの統合テーブルよりも個別のテーブルを使用する方が適しています。 パーティションキーの選択 Timestream でパーティション化する場合、パーティションキーを自身で決定するか、 measure_name 列に基づくデフォルトのパーティションを使用するかを選択できますが、カーディナリティの高い列を持ち、クエリの述語として頻繁に使用されるディメンションに基づいてパーティションキーを自身で選択することを推奨します。そうする事で、パーティション間でデータが均等に分散され、パフォーマンスの問題を回避出来ます。このビデオストリーミングの例では、カーディナリティの高い列 ( session_id 、 viewer_id 、 video_id 等) がパーティションキーとして適している可能性があります。ただし、パーティションキーの選択については、どの列がクエリ実行時のフィルタリングに頻繁に使用され、カーディナリティが高いのかを事前にユースケースから検討する必要があります。 場合によっては、データの分散に役立つ属性が無く、顧客定義のパーティションキーを使用できないことがあります。この場合、 measure_name はデータを分割するデフォルトのキーとなります。必ず measure_name 属性の設計を慎重に計画してください。一例として言うと、デバイスから圧力と温度のメトリクスを収集している場合は、次のデータ例に示すように、それら ( pressure と temperature) を measure_name 列に配置します。これはデータを均等に分散するのに役立ちます。 device_id measure_name Time Quality Value sensor-123 temperature 2023-08-01 19:21:32 85 43 sensor-123 temperature 2023-08-01 19:22:32 86 44 sensor-123 pressure 2023-08-01 19:23:32 83 31 sensor-123 pressure 2023-08-01 19:24:32 34 123 各テーブルは、 measure_name 列に対して最大で 8,192 個の個別の値を格納できます。 measure_name 列の最適な値が見つからない場合、または設計段階で制限 (8,192 個の一意の値) を超えることに気づいた場合は、 こちら でさらなる推奨事項を参照してください。 timestamp、measure_name、および少なくとも 1 つのディメンションとメジャーは、Timestream にデータを取り込む際の必須の列です。顧客定義のパーティションキーが使用されている場合でも、measure_name 列は必須であり、テーブルの作成時に レコードのパーティションキーを強制するオプション が無効になっている場合はパーティションキーとして機能します。 コストとパフォーマンスの最適化 Timestream の価格設定 は使用量に基づいており、そのコストの 1 つはクエリ処理中に サーバーレス分散クエリエンジン によってスキャンされるデータ量によって計算されます。新しくタイムスタンプ付きデータが取り込まれると、データは複数のパーティションに分散され、時間、ディメンション、および顧客定義のパーティションキーまたは measure_name によって構成されます。可能な限り、クエリは時間でフィルタリングを行う事をお勧めします (時間は Timestream のディメンジョンです)。これは、クエリエンジンが定義された時間間隔内のデータが配置されたパーティションのみをスキャンする事で、コスト削減とパフォーマンスの向上に直接影響を与えるためです。 さらにクエリ内で可能な場合は、時間フィルターに加えて、顧客定義のパーティションキーまたは measure_name (デフォルトのパーティション分割が使用されている場合) でのフィルターを使用することをお勧めします。これにより、Timestream は無関係なパーティションを効率的に取り除き、特定の時間ウィンドウとパーティションフィルター値のパーティションのみをスキャンすることで、クエリのパフォーマンスを向上させ、コストを削減します。クエリを実行する際、すべてのディメンション (顧客定義のパーティションキーを含む) と measure_name を時間とともにフィルターに使用すると、クエリを最大 30% 高速化できます。 パーティション化キーと時間をフィルターとして使用せずにデータをクエリすると、多数のパーティションがスキャンされることになり、クエリの応答が遅くなり、コストが高くなる可能性があります。Timestream の他のコストの 1 つはストレージです。ディメンション、メジャー、パーティション キーを決定した後は、全体的なコストを節約するために、不要なデータは Timestream に格納しないようにして下さい。 Timestream にデータを保存する ディメンションとメジャーを定義したら、データ モデリングの作業として次に実施するのは、Timestream にデータを保存する方法を検討する事です。データ型は、書き込みとクエリのために Timestream にどのように保存できるかに基づいて選択する必要があります。 アプリケーションが JSON オブジェクトを出力する場合、それらを JSON 文字列に変換し、VARCHAR 型として保存できます。ダウンストリームのコードまたはアプリケーションはこのエンコードを認識し、デコードを適切に処理する必要があることに注意しましょう。ただし、Timestream は時系列データ用に設計されているため、サービスの機能を最大限に活用するには、各データを別々の列として格納することがベスト プラクティスであることに注意してください。 たとえば、自動車用のアプリケーションが、車体番号、測定値 (燃料消費量、速度、経度、緯度)、および時間の属性を持つデータを扱うとします。その場合、アプリケーションはこの JSON データを Timestream テーブルの個別の列に変換する必要があります。 元の JSON データは以下の通りです。 { "car_vin_number": "1234567", "time": "2023-07-20T12:34:56.789Z" "state": "in_motion" "speed": "65" "longitude”: "0.01", "latitude”: "3.02" "fuel_consumption": "80 percent" } Timestream 用に変換されたデータは以下の通りです。 car_vin_number state time fuel_consumption speed longitude latitude 1234567 in_motion 2023-07-20T12:34:56.789Z 80 65 0.01 3.02 データを個別の列に変換することで、Timestream が時系列データを効率的に保存およびクエリできるようになります。各属性は専用の列になり、Timestream が時間ベースのクエリと集計を実行しやすくなります。 シングルメジャー vs マルチメジャー Timestream ではレコードを保存する方法として、 シングルメジャー方式とマルチメジャー方式 があります。 シングルメジャー方式の場合、レコードは 1 つのメジャーしか持ちませんが、マルチメジャー方式の場合、レコードに複数のメジャーを格納する事が出来ます。シングルメジャー方式は、異なる期間で異なるメトリクスをキャプチャする場合、または異なる期間でメトリクスとイベントを発行するカスタム処理ロジックを使用する場合に適しています。しかし、実際には、デバイスまたはアプリケーションは同じタイムスタンプで複数のメトリクスまたはイベントを発行する場合が多いです。 このような場合、同じタイムスタンプで発行されたすべてのメトリクスを同じマルチメジャーレコードに保存する事で、クエリの柔軟性と効率が向上します。多くの場合では、 シングルメジャー方式よりもマルチメジャー方式が推奨 されます。このアプローチにより複数のメジャーの同時取り込みとクエリが可能になり、全体的なコストが削減され、パフォーマンスが向上します。 次のテーブルはシングルメジャーレコードの例です。 device_id measure_name time measure_value::double measure_value::bigint sensor-123 temperature 2022-01-01 08:00:00 25.3 NULL sensor-123 humidity 2022-01-01 08:00:00 NULL 50 sensor-123 pressure 2022-01-01 08:00:00 1014.2 NULL sensor-456 temperature 2022-01-01 08:00:00 23.8 NULL sensor-456 humidity 2022-01-01 08:00:00 NULL 55 sensor-456 pressure 2022-01-01 08:00:00 1013.7 NULL 以下はマルチメジャーレコードの例です。 device_id measure_name time temperature humidity pressure sensor-123 metric 2022-01-01 08:00:00 25.3 50 1014.2 sensor-456 metric 2022-01-01 08:00:00 23.8 55 1013.7 ベストプラクティス Timestream でデータモデリングを行う時には、データ保持ポリシー、暗号化キー、アクセス制御、制限、クエリワークロード、アクセスパターン等がアプリケーションのパフォーマンスとコストにどのような影響を与えるかを考慮することが重要です。 暗号化キーはデータベースレベルで設定されるため、暗号化要件が異なるデータは異なるデータベースに保存する必要があります データ保持ポリシーはテーブルレベルで構成されるため、異なるデータ保持要件を持つデータは別のテーブルに保存する必要があります。 アクセス制御はデータベースおよびテーブルレベルで設定されるため、アクセス要件が異なるデータは異なるテーブルに保存する必要があります。 頻繁にクエリされるデータを同じテーブルに格納することで、クエリの待ち時間を改善しつつ、クエリ作成がやりやすくなります。テーブルが同じ AWS アカウントおよびリージョン内に作成されている場合、Timestream で複数テーブルを結合してクエリ実行することは可能ですが、単一のテーブルをクエリする場合と複数テーブルを結合してクエリする場合とでは、パフォーマンスに顕著な違いが生じる可能性があります。 バッチ書込 と CommonAttributes の利用は、Timestream でのデータ取り込みの最適化とコスト削減の達成に重要な役割を果たします。バッチ書込を使用すると、1 回の API 呼び出しで複数のレコードを効率的に取り込むことができ、リクエスト数が減り、全体的な取り込みパフォーマンスが向上します。このアプローチにより、大量のデータをより効率的に処理して保存し、コストを節約できます。 また、CommonAttributes を使用すると、バッチ書込で共有する属性をまとめて定義できるため、データ転送と取り込みのコストが削減されます。 尚、バッチ書込で利用する WriteRecords API リクエストの最大レコード数は 100 です。 さらに、ここでは詳細の説明は行いませんが、データモデリングの決定に役立つ Timestream に関連する他のいくつかの重要な側面と機能があります。 ストレージ層 – Timestream は、メモリストアと磁気ストアという 2 つのストレージ層を提供します。メモリストアは、高スループットのデータ書き込みと高速なポイントインタイムクエリ向けに最適化されています。磁気ストアは、低スループットの遅延到着データ書き込み、長期データ保存、および高速分析クエリ向けに最適化されています。テーブルの作成時に両方の層の保持ポリシーを構成可能で、テーブル作成後にそれらを変更することもできます。最新のタイムスタンプ付きデータはメモリストアに送信され、設定されたメモリストアの保持期間に基づいて、古いタイムスタンプ付データは磁気ストアに移動されます。 スケジュールドクエリ – スケジュールドクエリを使用すると、ソーステーブルの Timestream データに対して集計、計算、変換を実行し、それを別テーブルにロードするクエリの実行を自動化できます。別テーブルに格納されたデータは既に集計が完了している為、データ量が削減されており、ダッシュボードや視覚化用のデータとして最適です。より詳細な情報は こちら を参照して下さい。 追加のリソース 詳細については以下のリソースを参照して下さい。 Data modeling API reference Using the AWS SDKs Quotas 結論 本ポストでは、Timestream の主要な概念と、データモデリングが重要な理由を説明しました。 Timestream でのビデオストリーミングの例を取り上げ、データモデリングがコストの最適化とパフォーマンスにどのように役立つかを詳しく掘り下げました。 まずは 1 か月の無料トライアル を使って、 Timestream を試して頂ければと思います。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

9月25日週は、AWS ユーザーグループインドネシアと AWS Cloud Day インドネシアをサポートするためにジャカルタに来ています。昨日は、「Innovating Yourself as Early-Stage Developers」のテーマで AWS ユーザーグループインドネシア と Hacktiv8 が共同で開催した コミュニティイベント に参加しました。イベントは大いに盛り上がり、スピーカーや開発者とつながる素晴らしい時間を過ごすことができました。 次は AWS Cloud Day インドネシア が待っています。私は Developer Lounge にいますから、見かけたら声をかけてください。 9月18日週のリリース 9月18日週のリリースのうち、私が注目したいくつかのリリースを以下に記載しました。 AWS CodeArtifact への Swift パッケージの追加 – この記事では、サーバー側で実行する Apple プラットフォーム ( iOS 、 iPadOS 、 macOS 、 tvOS 、 watchOS 、 visionOS 、または Swift ) アプリケーション向けのコードを記述する Swift デベロッパーが AWS CodeArtifact を使用してパッケージの依存関係を安全に保存および取得する方法について Seb が説明しています。私が特に気に入っているのは、デベロッパーが Xcode 、 xcodebuild 、 Swift Package Manager ( swift package コマンド) などの標準デベロッパーツールを引き続き使用して AWS CodeArtifact とやり取りし、開発ワークフローへの統合を推進できる点です。 Apple Silicon M2 Pro Mac Mini コンピューター上に構築された Amazon EC2 M2 Pro Mac インスタンス – Channy が、Amazon EC2 M2 Pro Mac を使用して、メモリを大量に消費するビルドとテストワークロードの実行、CI/CD のモダナイズ、そして市場への製品投入の加速を行う方法について説明しています。Apple のデベロッパーは、EC2 M1 Mac インスタンスと比較して、2 倍の RAM、1.5 倍の CPU コア、2 倍以上の GPU コアを活用して、複数の Xcode シミュレータでより多くのテストを並行して実行できるようになりました。 Amazon CloudWatch Synthetics 用の Synthetics Python ランタイムバージョン 2.0 – Amazon CloudWatch Synthetics では、Canary を作成して顧客エクスペリエンスを継続的に検証し、顧客が気づく前に問題を発見できます。Canary は、エンドポイントと API を監視するためにスケジュールに従って実行される設定可能なスクリプトです。このリリースでは、Synthetics Python ランタイムバージョン syn-python-selenium-2.0 を使用して Canary を作成できるようになりました。 Amazon QuickSight が新しいレイアウトとスパークラインを KPI ビジュアルに追加 – これらの新しいアップデートでは、Amazon Quicksight 上で視覚的な魅力のある KPI を簡単に設計できます。Quicksight では、テンプレート化された KPI レイアウト、スパークラインのサポート、条件付き書式の向上、改良された書式設定ペインなど、ユーザーフレンドリーなエクスペリエンスを実現するための広範な機能強化が導入されています。 Amazon Location Services が追跡とジオフェンシングの価格の最大 75% 引き下げを発表 – Amazon Location Service が追跡とジオフェンシングの 4 つの価格モデルを発表し、オペレーションとビジネスをスケールしてコスト効果の高い方法で実行できるようになりました。請求額は、ジオフェンシングで 20%～70%、追跡で最大 75% 削減される可能性があります。 Amazon Corretto 21 の一般提供開始 – Java デベロッパーに朗報です。長期サポート (LTS) 付きの Amazon Coretto 21 の Linux、Windows、macOS 向けの一般提供が開始されました。 AWS App Runner が自動スケーリング設定管理の向上を発表 – AWS App Runner サービス用の新しい API とパラメータを使用して App Runner サービスを管理し、自動スケーリング設定 (ASC) を定義できるようになりました。例えば、デフォルトの ASC の設定、既存の ASC の更新、ASC リソースを使用しているすべての App Runner サービスの一覧表示を行うことができます。 編集とマスクによる Amazon SNS メッセージデータの保護 – Amazon SNS で個人を特定できる情報 (PII) と保護対象保健情報 (PHI) の特定のタイプを検出して保護できるようになりました。データ保護ポリシーを定義すると、SNS がメッセージをリアルタイムでスキャンして機密データを検出します。 今後予定されている AWS とコミュニティのイベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS On Tour – 9 月 18 日～10 月 6 日、 AWS Cloud Day インドネシア – 9 月 26 日 AWS Summit ヨハネスブルグ – 9 月 26 日 CDK Day – 9 月 29 日 そして、仲間のビルダーから学び、AWS Community Day に参加しましょう。 AWS Community Day ジンバブエ (9 月 30 日) AWS Community Day チリ  (9 月 30 日) AWS Community Day ブルガリア  (10 月 7 日) ランディングページにアクセスして、今後開催されるすべての AWS Community Days をチェックしてください。 構築がうまくいきますように。 –  Donnie この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

2023 年 9 月 7 日に「 お客様やユーザーの視点を意識したビジネスイノベーションの進め方 」オンラインセミナーを開催しました。このブログでは、当日参加できなかった方や、内容を振り返りたい方へ向けて参考としていただくために当日のセッション内容のまとめを紹介します。 ビジネス変革を目的に、クラウド導入・活用に挑戦する企業がますます増えています。そこで、AWSでは技術的なサポートだけではなく、ビジネスアイデアづくりや変革推進についてもご支援しています。変革の根幹となるのがAmazon自身が新製品や新サービス開発・社内の業務改善の際に実践している「Working Backwards」と呼ばれるメカニズム（フレームワーク）です。エンドユーザーや社内の従業員、お取引先様など、「お客様」と「お客様の課題」を探求し、アイデア創造と洗練化、そして実装や検証まで、Working Backwards一連の流れをご一緒し、ビジネス変革のにつなげています。 本セッションでは、Working Backwardsを活用し、ビジネス変革を推進された事例を、3社のお客様よりご紹介いただきました。業界も、ビジネス構造も、またクラウドへの取り組みも三者三様のみなさまにご登壇いただきましたが、プログラムを実践されたことによってどんな価値を得て、どんな変革につながっていったのか、バラエティに富んだお話をお聞きできました。 AWSのビジネス変革ご支援について アマゾンウェブサービスジャパン合同会社 セグメント事業開発本部 デジタルイノベーション シニアスペシャリスト　櫻井直子 昨今、デジタライゼーション（ペーパーレス化）・デジタライゼーション（IT化）の先にある、新たな価値創出やビジネス変革にデジタルを活用していくデジタルトランスフォーメーション（DX）の必要性が高まっています。一方で何から始めていったらいいのか、技術の手前にあるアイデアの出し方や変革推進の部分での課題を感じられている企業様もたくさんいらっしゃることを、日々の活動の中で実感しております。 そこで、AWSではテクノロジーとしてのクラウド導入のご支援にとどまらず、ビジネス変革のご支援のひとつとして、「デジタルイノベーションプログラム」をご提供しています。Amazon自身が新しいサービスやプロダクトを生み出しているときに使っているフレームワーク・やりかたであるWorking Backwardsを活用しながら、新しいビジネスアイデアを考え、アイデアをAmazonでも使っている文章というフォーマットでかたちにし、そしてその有用性をプロトタイプで検証するところまでを一貫してご支援するプログラムです。 このセッションではデジタルイノベーションプログラムについて、またその中で活用するWorking Backwardsのプロセス（お客様にこだわる5つの質問への回答・社内企画書としてのプレスリリース・FAQ・ビジュアルの作成）についてお伝えしました。   日本最古の私鉄：南海電鉄が挑戦するDXと新しい体験価値創造への取り組みについて 南海電気鉄道株式会社 総務人事グループ DX推進部 課長補佐　尾上 拓也 氏 南海電気鉄道株式会社は2021年ごろよりDXを本格推進されはじめました。コロナ禍において運輸事業の在り方を見直す中で、デジタルを使った新しい価値創出も積極的に進めていく必要性を感じていらしたときに、AWSのデジタルイノベーションプログラムの活用を始めていただきました。 社内の業務改善のDXではなく、南海電鉄のお客様・エンドユーザー様を見据えた新しい価値創造のDXプロセスについては初めての取り組みとのことでしたが、デジタルイノベーションプログラムを活用いただくことによって、スピード感をもってプロセスを完遂いただけました。また、考えたアイデアを机上の空論で終わらせずプロトタイプの実践に移していただいたことで、考えたアイデアが本当に顧客視点で有用性があるのかという仮説検証もされています。素早いプロトタイプ化により、実際のお客様からのフィードバックをアイデアの洗練化につなげていかれました。そして、チームのみなさまも含めて、新しいチャレンジに対して前向きに取り組んでいただく風土もはぐくまれました。 セッション内ではアプリ内のUXや実証実験中のお写真もご紹介いただいています。ぜひ挑戦の詳細をビデオでご確認ください。   顧客志向のマインドを持つ企画人材の育成 ～AWS社サービス開発ソリューションの体現～ 株式会社エナリス 事業企画本部 副本部長 兼 みらい研究所 所長 小林 輝夫 氏 株式会社エナリス みらい研究所 主任研究員 星野 光保 氏 エナリスはエネルギー総合ソリューションを展開されています。経営層のみなさまと、電力を取り巻く昨今のビジネス課題についてAWSと議論させていただく中から、プログラムを開始した事例をご紹介いただきました。顧客視点を徹底したからこそ生まれた、今までとは一味ちがったソリューションの考案に結び付けていただくことができ、プログラム終了後も新人研修にWorking Backwardsのコンセプト加えることで、組織の風土づくりにも活かされています。また、デジタルイノベーションプログラムの中で、実際に考えていただいたアイデアを形作るために活用できるAWSサービスもご紹介したことで、素早くプロトタイプ作りにもつなげていただきました。 AmazonというとConsumerビジネスのイメージが強く、Working Backwardsは法人向けビジネスを考えるうえでどのように役立ちそうかイメージが湧きにくい、というコメントをいただくこともありますが、エナリスの実践事例はその問いへの一つの解と言えます。セッション内では実際に記載いただいたPress Releaseの一部も公開くださっています。ぜひご覧ください。   Working Backwardsで顧客価値の解像度を上げ、新たな顧客体験を実現 株式会社ジンズホールディングス 執行役員 CIO 松田 真一郎 氏 株式会社ジンズ デジタル本部 ITデジタル部 営業基盤G クリエイター 劉 珈彤 氏 ジンズホールディングス・ジンズは積極的にAWSをご導入いただき、日本の中でもかなり早い段階から様々な面でクラウドのテクノロジーをご活用いただいておりました。デジタル戦略として「最高の顧客体験の実現」を掲げ、先進的なお取組みを進める中で、デジタルイノベーションプログラムをご活用いただきました。プログラムを通じて、改めて店舗でのお客様行動の観察からアイデアを着想し、Working Backwardsの特徴でもあるPress ReleaseとFAQという「文章のフォーマット」を使ってアイデアを洗練化することで、チームワークを活かしながら課題解決に向かわれました。また、素早くお客様のニーズを形にするためのAgile開発の体制づくりにもチャレンジいただきました。 プロジェクトの推進体制やアーキテクチャ図もご紹介いただき、テクニカルな視点でも進め方の具体的な参考になる実践事例をご紹介いただきました。アイデアを実践に素早く生かす組織づくりの実践例をぜひご覧ください。   まとめ 本セッションでは日本国内のお取組み事例についてご紹介しましたが、AWSは海外含めて多くのビジネス変革のお取組みにご一緒しています。 AWSを利用したイノベーションのページ ではAmazon自身のイノベーションの取り組み詳細や、さらに多くのお客様のお取組み事例など、ブログや動画でご紹介しています。デジタルイノベーションプログラムに参加し、Working Backwardsを自社でも試してみたいとお感じになられましたら、担当営業までご相談いただくか、 AWSホームページのお問合せフォーム やチャットよりお問い合わせください。御社のビジネス課題に合わせて、どのような形で変革をご支援できそうか、ぜひご相談させていただければと思います。 AWSは、今後もビジネスパートナーとして事業開発やサービス向上のご支援を強化してまいります。新しいお取組みのきっかけに、ぜひデジタルイノベーションプログラムのご活用をご検討ください。

日が暮れるのが早くなってきた今日この頃ですが、コンピューティングとメモリに最適化された 2 つの新しい EC2 インスタンスタイプと、他のサービス向けの多くの新機能が導入されました。9月11日週、ミュンヘンで EMEA AWS Heroes Summit も開催され、インサイトと情熱に満ちた素晴らしい一日になりました。参加者の素敵な写真をご覧ください。 9月11日週のリリース 9月11日週のリリースのうち、私が注目したいくつかのリリースを以下ご紹介します。 C7i インスタンス – カスタムの第 4 世代 Intel Xeon Scalable プロセッサー (コードネーム Sapphire Rapids) を搭載し、AWS でのみ利用できるこれらのコンピューティング最適化インスタンスは、他のクラウドプロバイダーが使用している同等の x86 ベースの Intel プロセッサーよりもパフォーマンスが最大 15% 向上します。C7i インスタンスは、バッチ処理、分散分析、ハイパフォーマンスコンピューティング (HPC)、広告配信、拡張性の高いマルチプレイヤーゲーム、ビデオエンコーディングなど、あらゆる計算集約型ワークロードに最適な選択肢で、C6i インスタンスと比較して最大 15% 高い料金パフォーマンスを実現します。 vCPU メモリ (GiB) ネットワーク帯域幅 EBS 帯域幅 c7i.large 2 4 最大 12.5 Gbps 最大 10 Gbps c7i.xlarge 4 8 最大 12.5 Gbps 最大 10 Gbps c7i.2xlarge 8 16 最大 12.5 Gbps 最大 10 Gbps c7i.4xlarge 16 32 最大 12.5 Gbps 最大 10 Gbps c7i.8xlarge 32 64 12.5 Gbps 10 Gbps c7i.12xlarge 48 96 18.75 Gbps 15 Gbps c7i.16xlarge 64 128 25 Gbps 20 Gbps c7i.24xlarge 96 192 37.5 Gbps 30 Gbps c7i.48xlarge 192 384 50 Gbps 40 Gbps c7i.metal-24xl* 96 192 37.5 Gbps 30 Gbps c7i.metal-48xl* 192 384 50 Gbps 40 Gbps *ベアメタルインスタンスは近日公開予定です。 データ操作の効率的なオフロードと高速化を促進し、ワークロードのパフォーマンスを最適化するために、C7i インスタンスは、Data Streaming Accelerator (DSA)、In-Memory Analytics Accelerator (IAA)、QuickAssist Technology (QAT) などの組み込み Intel アクセラレーターと、CPU ベースの ML などのアプリケーションの行列乗算演算を高速化する新しい Intel Advanced Matrix Extensions (AMX) をサポートしています。 EC2 R7a インスタンス – 最大周波数が 3.7 GHz の第4世代 AMD EPYC プロセッサー (コードネーム Genoa) を搭載したこれらのメモリ最適化インスタンスは、R6a インスタンスと比較して最大 50% 高いパフォーマンスを実現し、SQL や NoSQL データベース、分散型ウェブスケールのインメモリキャッシュ、インメモリデータベース、リアルタイムのビッグデータ分析、Electronic Design Automation (EDA) アプリケーションなどの高性能でメモリ集約型ワークロードに最適です。 詳細については、Channy のブログ記事をご覧ください 。 Amazon Bedrock のナレッジベース (プレビュー) – より関連性が高く状況に応じた応答を行うために、Bedrock は取り込みワークフローとランタイムオーケストレーションの両方を管理して、組織のプライベートデータソースを基盤モデル (FM) に接続し、生成系 AI アプリケーションの検索拡張生成 (RAG) を有効にできるようになりました。データを保存するには、Amazon OpenSearch Serverless 用ベクトルエンジン、Pinecone、Redis Enterprise Cloud など、さまざまなベクトルデータベースから選択できます。 詳細については、Antje のブログ記事をご覧ください 。 Amazon OpenSearch Serverless による高いクエリレートにより自動スケーリングが拡大 – OpenSearch Serverless を利用することで、検索とクエリのトラフィックの予測不可能な急増を管理し、1 分あたり何万ものクエリトランザクションを効率的に処理できるようになりました。 Amazon EMR on EKS – EMR を使用して他のアプリケーションと同じ Amazon EKS クラスターで Apache Flink (パブリックプレビュー) を実行することで 、リソース使用率を向上させ、インフラストラクチャ管理を簡素化できるようになりました。また、カーネル、ツールチェーン、glibc、openssl などの最新の拡張機能を備えた、安全で安定した高性能環境を実現するために、 Amazon Linux 2023 をオペレーティングシステムとして使用し 、また Java 17 を Java ランタイムとして使って、Amazon EMR on EKS を使用してワークロードを実行できるようになりました。 Amazon Connect – Amazon Connect Cases では、 ケースへの添付ファイルのアップロード がサポートされるようになりました。これにより、エージェントはケースの解決に必要な情報をすぐに利用できるようになりました。また、ケースに書かれた コメントには作成者名が表示されるため 、ケースの解決に貢献したユーザーをより簡単に追跡し、より効果的に共同作業を行うことができます。コンタクトセンターで連絡 (音声通話、チャット、タスク）イベント (例えば、通話がキューに入っているなど) のストリームをほぼリアルタイムで受信するために、 新しい連絡データ更新イベントに登録 できるようになりました。 AWS Chatbot 用のカスタム通知 – これにより、Microsoft Teams や Slack チャネルで AWS アプリケーションの状態やパフォーマンスをモニタリングする際に、注文数や現在のスロットリング制限などの追加情報を含めることができます。 AWS IAM アイデンティティセンターのセッション期間が最大 90 日間に延長 – セキュリティコンテキストと希望するエンドユーザーエクスペリエンスに基づいて、より柔軟に対応できるようになりました。以前は、最大 7 日間でした。デフォルトのセッション時間は引き続き 8 時間で、お客様が設定した既存のセッション制限は変更されません。 Amplify Studio での GraphQL API の完全サポート – Amplify Studio または Amplify CLI で作成された GraphQL API 向けに、API に接続されたフォームを生成したり、API 中のレコードを Data Manager で管理したり、データバインドされた Figma to React コンポーネントを作成したりできるようになりました。以前は、これらのデータ駆動機能は Amplify DataStore を使用した場合にのみ利用できました。 AWS AppSync WebSockets ベースのサブスクリプション向けのネストされたフィルタリング – 公開されたデータ内の特定のサブ項目を対象とするフィルタリングルールを使って、接続されたクライアントにデータを公開する方法を詳細に制御できるようになりました。 このブログ記事 で詳細をお読みください。 API Gateway コンソールの更新 – REST と WebSocket API ワークフローの使いやすさが向上し (HTTP API のコンソールエクスペリエンスと視覚的に連携するようになりました)、ダークモードがサポートされるようになりました。アクセシビリティの強化は、支援技術との統合にも役立ちます。 AWS Supply Chain の上書き保存機能 – 需要プランナーが手動で行った予測調整は、自動的に保存され、ある計画サイクルから次の計画サイクルに再適用されるようになりました。 AWS のその他のニュース AWS でのサーバーレス開発 – AWS ヒーローの Sheen Brisals と彼の同僚である Luke Hedger は、AWS でエンタープライズ規模のサーバーレスソリューションを構築するのに役立つ本で専門知識を共有しています。この本では、人材、考え方、ワークロードの観点から採用要件の概要を説明し、サーバーレスアプリケーションを構築するためのアーキテクチャパターン、セキュリティ、データのベストプラクティスを詳しく説明しています。 AWS ブログからのその他の記事 – 私がフォローしている他の AWS ブログやクラウドブログからの投稿です。 AWS コンテナブログ – Django アプリケーションを AWS App Runner にデプロイしてスケーリングしましょう 。 AWS アーキテクチャブログ – アーキテクトしよう! インメモリデータベースの活用 。 AWS 機械学習ブログ – AWS SageMaker JumpStart Foundation Model を使用して、ツールを用いた LLM エージェントを構築およびデプロイする方法を説明します 。 AWS 機械学習ブログ – 検索拡張世代生成と LangChain エージェントを使用して内部情報へのアクセスを簡素化します 。 AWS for Games ブログ – コンテンツ管理サービスとグラフデータベースおよび分析を組み合わせて、コミュニティの有害性を軽減しましょう 。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS On Tour、9 月 18 日～10 月 6 日 – AWS デベロッパー関係チームは バスに乗り込み、欧州の都市 (ロンドン、パリ、ブリュッセル、アムステルダム、フランクフルト、チューリッヒ、ミラノ、リヨン、バルセロナ) を巡り 、経験を共有し、生産性の向上を支援します。 AWS グローバルサミット、9 月 26 日 – 今年最後の対面式 AWS Summit が 9 月 26 日に ヨハネスブルグ で開催されます。 CDK Day、9 月 29 日 – CDK と関連プロジェクトに関するコミュニティ主導の完全バーチャルのイベント (英語とスペイン語) に関する ウェブサイトで詳細をご覧ください 。 AWS re:Invent、11 月 27 日～12 月 1 日 – 自身の re:Invent の計画を始めるには、 セッションカタログ を閲覧するのが良い方法です。ぜひご参加ください。AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。 AWS Community Day – オランダ (9 月 20 日)、 スペイン (9 月 23 日)、ジンバブエ (9 月 30 日)、 ペルー (9 月 30 日)、 チリ (9 月 30 日)、 ブルガリア (10 月 7 日) など、お住まいのリージョンの AWS ユーザーグループリーダーが主催するコミュニティ主導の会議に参加しましょう。ランディングページにアクセスして、今後開催されるすべての AWS Community Day をチェックしてください。 今後予定されている AWS 主導の対面イベント、仮想イベント や AWS DevDay などの デベロッパー向けイベント をすべて閲覧できます。 — Danilo この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

DynamoDB Specialist Solutions Architectの成田と申します。 前回、表題のイベントについて イベントの告知ブログ を公開させて頂きました。 本投稿ではイベントの風景や各スピーカーの資料を皆様にシェアさせて頂きます。当日参加したが見逃してしまった、などに是非お役立て下さい。 なお、一部スライドは今回の公開用に変更・修正をしている可能性があることを承知下さい。発表者のスライドは各speaker画像下のリンクから参照下さい。（サイトの仕様上、スライドを直接表示が出来ないため宜しくお願いします） AWSにおけるマイクロサービスとNoSQLの活用- 福井 厚 Understanding & Using Amazon DynamoDB – Alex DeBrie Amazon DynamoDB Deep Dive at AWS Loft Tokyo 2023/9/28 各セッションは途中で質問が出るなどAmazon DynamoDBの特性やどう有効利用するかでとても白熱した議論が出来たと思います！ もし、今後もDatabase/NoSQL/Analytics関連でのイベント開催、特にAmazon DynamoDBを始めとしたNoSQLサービスについてより初学者向け、よりエキスパート向け、ハンズオンを利用したワークショップを希望されている方は是非ハッシュタグ #DynamoDB をつけてX(Twitter)で本ブログの感想などをお寄せください！ 本ブログ著者 : 成田 俊は、Principal DynamoDB Solutions Architectです。Amazon DynamoDB を使用する多くの AWS のお客様にアーキテクチャのレビューや技術支援を行っています。

みなさんこんにちは。ソリューションアーキテクトの眞壽田（ますた）です。7/28にAWSが主催する自動車業界向けイベント「AWS Autotech Forum 2023」を開催しました。AWS Japanでは、自動車業界の皆様にクラウドを活用してビジネスを加速して頂くことを目指し、 2018 年より事例や最新技術の活用方法等をご紹介する本イベント「 AWS Autotech Forum」 を開催して参りました。今回で6回目となる本イベントも昨年同様オンライン開催となりましたが、1000名近くの多くの方にご登録頂きました。CASEによる変革が自動車業界で起動に乗った今、CASEという言葉が生まれた当初の想定通り、世の中で自動車に対する価値が変わってきていることを私自身も実感しています。今年の本イベントでは、自動車の新しい価値を第一線で創造しているお客様を代表して、ソニー・ホンダモビリティ株式会社様、TIER IV, Inc.様、KINTOテクノロジーズ株式会社様にご登壇頂きました。 オープニング – 竹川 寿也　アマゾン ウェブ サービス ジャパン 合同会社 事業開発本部 シニア事業開発マネージャー オープニングでは、これまでAuto Tech Forumのあゆみをお伝えすると共に、AWS for Automotiveという自動車業界のお客様を支援するチームの取り組みやご支援内容をご紹介し、自動車業界の皆様にAWSがどのように貢献できるかということをご説明しました。 ソニー・ホンダモビリティが目指す新たなモビリティの価値 – 川西 泉 様　ソニー・ホンダモビリティ株式会社　代表取締役 社長 兼 COO セッションでは、ソニーホンダモビリティの設立の経緯から、車両がユーザーに提供する新たな価値と、それを実現するための車両開発のアプローチについてお話頂きました。AFEELAが、ユーザーに提供する新たな価値とは、ユーザーに感動を与える空間を提供することであり、移動の価値を継続的に進化させていくことである。その継続的な進化は、量産後も継続的に車載ソフトウエアをアップデートすることで実現し、それを実現するには車両アーキテクチャーがSoftware-Definedでなければならない。そしてSoftware-Definedな車を実現するには車の演算能力も高くあるべき、ということから、業界内で話題となっている車載のSoCを選定した経緯もお話頂きました。 以下、所感になりますが、AFEELAは AIBO と同様に、車両（IoTデバイス）、スマホ、クラウドがそれぞれ接続し、様々なサービスと連携することを想定しており、その中でAWSクラウドが果たす役割は非常に大きいと感じました。自動車業界一般的にも言えることですが、この領域に関してAWSクラウドの役割を具体的に列挙すると次のようになります。認証、データアップロード、データ解析、OTA、パーソナライズ、ADAS機能開発、車両ソフトウエア開発。 IoTデバイスの認証においては、 AWS IoT Core を使用するユーザー事例が一般的になりつつあり、ソニー様においてもAIBOの認証機能でAWS IoT Coreが採用されています。データアップロードにおいては、認証と同様にAWS IoT Coreを使用するケースや、AIBOの事例では、 AWS AppSync を利用し、デバイスとAWSクラウド間、スマホアプリとAWSクラウド間をGraphQLで情報同期をする方法が採用されています。パーソナライズやADAS機能開発で Amazon SageMaker などの機械学習サービスを利用するケースも一般的になりつつありますが、新しい自動車業界の潮流として、車載ソフトウエアの開発を可能な限りAWSクラウド上で行い、V字の開発プロセスにおいてShift-Leftを目指す 事例 が、海外の自動車メーカー様でも増えてきています。 自動運転の事業化を加速するWeb.Auto – 関谷 英爾 様　TIER IV, Inc. Architect セッションでは、自動運転の潮流や、Autowareという自動運転のソフトウエアをオープンソースとして提供するTIER IV様のビジネスの方式や、各プロダクトの実際の開発・アーキテクチャー、運用の効率化についてお話頂きました。 TIER IV様のビジネスは、Autowareを実際のプロダクションフェーズで利用するために必要な関連プロダクトを提供することであり、大きく３つのプロダクトをご紹介頂きました。自動運転ソフトウエアの開発環境を提供するWeb.Auto、主に狭域自動運転などのMaaSで利用される自動運転用のプラットフォームであるPilot.Auto、自動運転で必要となる車載センサーデバイスであるEdge.Autoの３つです。本セッションでご紹介頂いたWeb.AutoとPilot.Autoは、非常に完成度が高い印象を受けました。また、ご紹介頂いたアーキテクチャーも大変参考になる情報が多く、個人的に感銘を受けたのはパスプランニングの経路探索で利用するGraphデータベースに Amazon Neptune を採用している点でした。ベクターマップから抽出した道路リンクをGraphデータベースとして表現する際、プログラム上でメモリ管理することは比較的容易なのですが、その機能をクラスタ化することは過去の私の体験談で苦労した経験があったためです。一方で、MLOpS、DevOpSに関してもアーキテクチャーを詳細にご紹介頂いており、シミュレーション機能を複数のコンピューティングリソースでクラスタ化させて動作させる際、そのノードを自動でProvisioning、Deprovisioningする仕組みを AWS Step Functions と Amazon EKS で実現している点、AD/ADASの機能を開発する開発者様にも参考になる事例ではないかと思いました。 セッションの後半では、Web.Autoが、 AWS Foundational Technical Review (FTR) の承認を受けたことをご紹介頂きました。FTRは、AWS Well-Architected Framework で定義されたガイドラインでシステムが設計されていることをAWSがレビューする評価サービスで、Web.Autoはその承認を受けたことで、第三者に品質をアピールすることができているとその効果をご紹介を頂きました。FTRは、潜在顧客に対してAWSを使ったプロダクトを販売する際、セキュリティ、信頼性、運用に関するリスクを低減していることを客観的にアピールできる仕組みということで、多くのパートナー企業様にもご利用いただいています。 まだまだ語りきれない情報含め、有益な情報を多くご提供頂いた関谷様のセッションは、次のリンクからご視聴頂くことができます。 資料ダウンロード（自動運転の事業化を加速するWeb.Auto） カーナビのクラウド化と固まっていた常識を変えるプロダクト開発 – 中西 葵 様　KINTOテクノロジーズ株式会社　開発・編成本部 プラットフォーム開発部 共通サービス開発グループ プリンシパル エンジニア セッションでは、ソフトウエアの技術を使ってお客様に迅速にサービスを提供するために生まれたKINTOテクノロジーズ様と、トヨタ自動車様との関係性や組織構造のご紹介、KINTOテクノロジーズ様が手掛けるKINTOの様々なサービスについてご紹介頂きました。今までKINTOイコール車のサブスクリプションサービスという認識でおりましたが、それだけではなく、多くの興味深いサービスをお客様に提供していることが中西様のセッションから実感できました。 中でも一番驚いたのが、KINTO FACTORYでした。現在の自動車業界のSoftware-Defined Vehicleは、車両の量産開始までにハードウエアを決定し、ソフトウエアは後から更新することを想定していますが、後から更新されるソフトウエアで提供できるサービスは、量産開始前に決められたハードウエアで制限が掛けられてしまうという潜在的な課題があるように思います。KINTO FACTORYはその課題をポジティブに解決できうるサービスで、ハードウエアは車両購入時に決める必要はなく、後から必要に応じて追加することを可能とするようです。これはKINTO様の所有から使用へを推進するビジネスを大きく拡張することができるサービスではないかと思いました。 また、OTAでアップデートするソフトウエアについて、個人の運転志向に基づいてパーソナライズされた機能を提供することができると紹介頂きました。パーソナライズを実現する要となるのはデータであり、自動車や販売店から収集したデータを効率的に処理するアーキテクチャーとして、FrontendやBackendで、Elastic Load Balancingと Amazon ECS の組み合わせて処理を実行する構成や、バッチジョブで Amazon EventBridge とAmazon ECSを連携させる構成をご紹介頂きました。 セッションの後半では、技術選定とエンジニア採用について興味深いお話をして頂きました。JavaやSpring Bootのような（流布されている）技術を指定して、一定のエンジニアを獲得することは比較的容易である。一方で、先進的なサービスを構築するために特殊なこと実行しようとすると、チームを組織することは難しくなる。そのために、臨機応変な技術選定をすることは会社の成長のためにとても重要であるとお話頂きました。 まだまだご紹介できていないサービスの詳細含め、有益な情報を多くご提供頂いた中西様のセッションは、次のリンクからご視聴頂くことができます。 資料ダウンロード（カーナビのクラウド化と固まっていた常識を変えるプロダクト開発） パネルディスカッション – 関谷 英爾 様　TIER IV, Inc. Architect – 中西 葵 様　KINTOテクノロジーズ株式会社　開発・編成本部 プラットフォーム開発部 共通サービス開発グループ プリンシパル エンジニア – 三浦 直樹 様　KINTOテクノロジーズ株式会社 開発・編成本部 プロジェクト開発部 プロジェクト推進G プリンシパル プロダクトマネージャ – 竹川 寿也、アマゾン ウェブ サービス ジャパン 合同会社　事業開発本部 シニア事業開発マネージャー パネルディスカッションでは、新たにKINTOテクノロジーズ様の三浦様にご参加頂き、「次世代に向けた変革」についての課題と解決方法ついてのトピックでお話し頂きました。新たな価値を創造している２社様ですが、自動運転という世の中になかった新しい技術を開発しているテックベンチャーのTIER IV様と、トヨタグループの中で車のサブスクビジネスを提供されるKINTOテクノロジーズ様、両社の課題はそれぞれ異なり、ディスカションでは大変興味深いやりとりがありました。また、最後のトピックでは「AWSの良い点、もう少し頑張ってもらいたい点」について、パネリスト様から貴重なご意見を賜りました。パネルディスカッションの詳細は下記の動画でご視聴頂くことができます。 パネルディスカッション | AWS Auto Tech Forum 2023 おわりに 6年目となる今回の AWS Autotech Forum は、長い歴史を持つ自動車業界の中では比較的新しい企業様にご登壇頂き、新たなコンセプトやサービス、先進事例をご紹介頂き、視聴者の皆様からも多くの反響を頂けたことを、主催者の一人として大変嬉しく思います。一方で、現在の自動車業界は、CASEの対応で増大化したソフトウエアを、Software-Definedな車載アーキテクチャーへの変化を推進することで、その増大化を抑えようとしています。そのプロセスには様々な課題があります。その課題を解決するために、AWSとしてお客様を支援できること、AWSパートナー企業様と協調することで支援が可能になることなど様々ございますが、次のイベントではそのSoftware-Defined Vehicleを推進する車載ソフトウエア開発の取り組みをご紹介できるよう、自動車業界のお客様を支援するソリューションアーキテクトとして、日々お客様と帆走していきたいと思います。 今後も先進的な取り組みを発信されたいお客様にイベント登壇頂き、自動車業界の皆様への参考としていただけるように本イベント活動も続けて参ります。 過去のイベント – AWS Autotech Forum 2022 – AWS Autotech Forum 2021 – AWS Autotech Forum 2020 #1 – AWS Autotech Forum 2020 #2 – AWS Autotech Forum 2019 著者 眞壽田 英輝 (Masuta, Hideki) アマゾン ウェブ サービス ジャパン 合同会社 Mobility領域のお客様を支援するソリューションアーキテクト。好きなAWSサービスはAmazon Managed Streaming for Apache Kafka (MSK)です。

みなさんこんにちは！ アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクトのウジンです。 2023 年 9 月 6 日に「アップデート紹介とちょっぴり DiveDeep する AWS の時間 – AWS re:Inforce デモ祭り」をオンラインで開催しました。本イベントは、AWS の数あるアップデートの中から「すぐ使える、運用に役立つ、あったらいいなと思ってた、おもしろい、重要」なものをピックアップし、ちょっぴり DiveDeep してカジュアルな雰囲気でお伝えするイベントです。 今回は、毎月開催している「ちょっぴりDD」の特別回で、6月に開催された クラウドセキュリティ、コンプライアンスに特化したカンファレンスである「AWS re:Inforce」で発表された新サービス、新機能の内容についてデモ中心でご紹介いただきました。 今回も非常に多くの方にご参加いただきました。ご参加いただいた皆様、誠にありがとうございました。 実施内容 AWS のメンバーから Amazon Verified Permissions サービス、Amazon CodeGuru Security 機能、EC2 Instance Connect Endpoint 機能、Amazon Inspector SBOM Export 機能を紹介するセッションをお届けしました。 記事の中に資料や動画のリンクがありますので、見逃してしまった方はそちらから御覧ください。 アジェンダ ついにGA！ Amazon Verified Permissions でアプリケーションの認可をシンプルに！（15分） スピーカー:アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 柴田 龍平 re:Invent 2022 にて発表された Amazon Verified Permissions が東京を含むほとんどのリージョンで一般利用開始となりました。従来、コードでの管理だと複雑になる一方だった分散アプリケーションの機能が追加される際のアクセス制御なども、Amazon Verified Permissions でポリシーを管理することでシンプルに監査可能な形で実現できます。本セッションでは Amazon Cognito との統合など、GAと共に発表された新たな機能をご紹介し、アプリケーションに統合する方法を Demo を交えつつご紹介します。 Amazon CodeGuru Security の紹介（15分） スピーカー:アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 江口 昌宏 Amazon CodeGuru Security は、機械学習を使用してコードの脆弱性を特定し、修復の手助けとなるような静的アプリケーション・セキュリティテスト（SAST）ツールです。この機能がプレビューリリースとなりました。開発ワークフローのさまざまな段階（コード・リポジトリ、CI/CD パイプライン、コンテナ・レジストリなど）で統合できるように設計されています。本セッションでは、これらの機能をご紹介いたします。 踏み台サーバーなしでプライベートサブネットのインスタンスに SSH？EC2 Instance Connect Endpoint を試してみる！（15分） スピーカー:アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 山崎 宏紀 EC2 Instance Connect Endpoint (EIC Endpoint) が利用可能になりました！EIC Endpoint を使うと、パブリック IP アドレスを使用せずに EC2 インスタンスへ SSH と RDP で接続できます。EIC Endpoint があれば踏み台サーバーが不要となり、パッチ適用、管理、監査など運用上のオーバーヘッドやインスタンスの維持費用を削減できます。本セッションでは新機能の使い方についてデモを交えてご紹介します。 Amazon Inspector SBOM Export ではじめるソフトウェアサプライチェーンセキュリティ（15分） スピーカー:アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 後藤 健汰 Amazon Inspector の新機能である「SBOM Export」が発表されました。昨今、増大するソフトウェアサプライチェーンセキュリティリスクに対処するため、SBOM の活用が注目されています。本セッションでは、SBOM の概要や「SBOM Export」機能について、デモを交えつつご紹介します。 当日の様子 当日の内容を抜粋してご紹介します。 ついにGA！ Amazon Verified Permissions でアプリケーションの認可をシンプルに！ [ 資料 、 動画 ] 最初のセッションは、ソリューションアーキテクトの柴田より、6月に一般公開となった Amazon Verified Permissions について、デモを交えながらご紹介しました。Verified Permissions は、アクセス制御用のオープンソース言語である Cedar を使用しているため、アクセス許可をわかりやすいポリシーとして定義できます。Cedar では、ロールベースおよび属性ベースのアクセス制御をサポートしており、Verified Permissions を利用することで、アプリケーション上でこれらの制御をシンプルに実現できます。 このセッションのデモでは、アプリケーションの認可処理を Verified Permissions を活用し実装しました。 アプリケーションコード内に認可処理が実装され拡張性に課題を抱えている方、これから認可処理を導入しようと考えている方はぜひご覧いただければ幸いです。 Amazon CodeGuru Security の紹介 [ 資料 、 動画 ] 2 つ目のセッションでは、ソリューションアーキテクトの江口より、6月にプレビューリリースとなった Amazon CodeGuru Security について、デモを交えてご紹介しました。Amazon CodeGuru Securityは、機械学習を活用してコードの脆弱性を特定し、修正の手助けをする静的アプリケーションセキュリティ検査（SAST）ツールです。 このセッションでは、CodeGuru Security をビルドプロセスに統合し、アプリケーションの脆弱性を検出する方法をデモで実演しました。デモの中では、サンプルコードに潜んでいる SQL インジェクションの脆弱性を検知し、その結果と修正ガイダンスを CodeGuru Security のダッシュボードで視覚的に確認することができました。 アプリケーション開発におけるセキュリティをより高めたい方にはぜひ御覧いただきたい内容です。 踏み台サーバーなしでプライベートサブネットのインスタンスに SSH？EC2 Instance Connect Endpoint を試してみる！ [ 資料 、 動画 ] ３つ目のセッションでは、ソリューションアーキテクトの山崎より、EC2 Instance Connect(EIC) という新機能をデモを交えてご紹介しました。以前は、プライベート Subnet にある EC2 インスタンスに接続するためには踏み台ホストを用意する必要がありましたが、EIC Endpoint を活用すれば踏み台サーバが不要となり、踏み台の維持にかかるコストや運用上の手間を削減できると同時にインスタンスにパブリック IPv4 アドレスがなくても、SSH または RDP 経由でインスタンスに接続でき、セキュリティも強化できます。EC2 インスタンスを運用している方にはぜひ参考にしていただきたい内容です。 Amazon Inspector SBOM Export ではじめるソフトウェアサプライチェーンセキュリティ [ 資料 、 動画 ] 最後のセッションは、ソリューションアーキテクトの後藤より、 Amazon Inspector の新機能、SBOM Export 機能をご紹介しました。Amazon Inspector では、組織全体の Amazon Inspector が監視しているすべてのリソースの統合ソフトウェア部品表 (SBOM) を、CyclonedX や SPDX などの業界標準の形式でエクスポートできるようになりました。この新機能により、自動化および一元管理された SBOM を使用して、ソフトウェアサプライチェーンに関する重要な情報を可視化できます。 本セッションでは、Amazon Inspector からサンプルソースの SBOM を S3 に出力し、Athena でその結果を検索する流れをデモを交えてご紹介しました。更なるセキュリティ強化を考えている方はぜひご覧いただければと思います。 次回予告 次回は「 Container 」編です。 ゲストスピーカーとして、株式会社ラクスの下西 氏、freee 株式会社の藤原 氏をお招きしましてコンテナ運用ノウハウKubernetes ネイティブのワークフローエンジンである Argo Workflows を Amazon EKS Cluster に導入する方法などに DiveDeep してお伝えします。 次回も多くの方々のご参加を心よりお待ちしております！ 2023 年 4 月以降に開催予定の『アップデート紹介とちょっぴり DiveDeep する AWS の時間』の視聴申し込みを一括でできるようになりました！毎月申し込みする必要はなくなります。また、イベント開催直前にリマインドメールをお送りいたします。下記リンクから参加ご希望月の申し込みをお願いいたします。 第三十四回「アップデート紹介とちょっぴり DiveDeep する AWS の時間」- Container 編- 開催日時：2023 年 9 月 28 日（木）16:00 – 17:30 オンライン開催 アジェンダ 16:00 – 16:10 オープニングセッション 16:10 – 16:25 AWS 上でコンテナを爆速起動する方法をまとめてみた スピーカー： アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 祖父江 宏祐 16:25 – 16:40 AWS でメール配信システムを構築！ Amazon ECS on AWS Fargate で楽楽運用 スピーカー： 株式会社ラクス インフラ開発部 東京インフラ開発2課 アシスタントマネージャー 下西 章王 氏 16:40 – 16:45 Q&A 16:45 – 17:00 Amazon EKS と Argo Workflows で実現するタスク実行と AWS リソースとの連携方法 スピーカー： freee 株式会社 SRE / Developer Experience エンジニア 藤原 彰人 氏 17:00 – 17:15 Amazon EKS と KubeVela でプラットフォームエンジニアリングに入門しよう！ スピーカー： アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 後藤 健汰 17:15 – 17:20 Q&A 17:20 – 17:30 クロージングセッション このブログの著者 鄭 宇鎭 ( Jung Woojin ) ソリューションアーキテクトとして ISV/SaaS 系のお客様の技術支援を行っております。好きなサービスは Amazon API Gateway とAmazon ECS です。趣味は子供と落書きをすることです。

本日、Amazon Bedrockが一般提供を開始したことをお知らせします。また、MetaのLlama 2 13B および 70B パラメータのモデルが、近日中に Amazon Bedrock で利用可能になることもお伝えします。 今年の4月、 AWS で生成系 AI を構築 するための新しいツールセットの一部として Amazon Bedrock を発表しました。Amazon Bedrockは、 AI21 Labs 、 Anthropic 、 Cohere 、 Stability AI 、 Amazon などの先進的な AI 企業の高性能な基盤モデル (Foundation Models) を選択できるフルマネージドサービスです。プライバシーとセキュリティを維持しながら、生成系 AI アプリケーションの開発を簡素化する幅広い機能群を提供します。 Amazon Bedrockの包括的な機能により、さまざまなトップレベルの基盤モデルをサーバーレスで試すことができ、ファインチューニングや検索拡張生成 (Retrieval-Augmented Generation; RAG) などの技術を用いて、プライベートな環境で独自のデータを活用して基盤モデルをカスタマイズし、コードを書くことなく複雑な業務タスクを遂行するマネージドなエージェントを作成できます。 以前の投稿をチェックして、これらの技術を利用するための Agents for Amazon Bedrock や  Knowledge Base についてさらに学ぶことができます。Agents for Amazon Bedrock や Knowledge Base を含む一部の機能は、引き続きプレビューでのみ利用可能であることに注意してください。このブログ記事の後半で、どの機能がプレビューで利用できるか詳細を共有します。 Amazon Bedrock はサーバレスなので、インフラを管理する必要がなく、すでに使い慣れている AWS サービスと連携して生成系　AI の機能をセキュアに統合およびデプロイできます。 Amazon Bedrock は Amazon CloudWatch および AWS CloudTrail と統合されており、モニタリングとガバナンスのニーズに対応しています。CloudWatch を使用して使用状況に関するメトリクスを追跡し、監査目的で独自のダッシュボードを構築できます。CloudTrail を使用すると、他のシステムを生成系 AI アプリケーションに統合する際に API 操作を監視し、トラブルシューティングをすることができます。 Amazon Bedrock を使用すると、 GDPR に準拠したアプリケーションを構築でき、 HIPAA (医療保険の相互運用性と説明責任に関する法律) で規制されるセンシティブなワークロードを実行できます。 Amazon Bedrock の利用を開始する Amazon Bedrock で利用可能な基盤モデルは AWS マネジメントコンソール や、 AWS SDK 、 LangChain などのオープンソースフレームワークを通じてアクセスできます。 Amazon Bedrock のコンソール では、基盤モデルを閲覧したり、各モデルの例となるユースケースやプロンプトを調べたり、読み込むことができます。はじめに、モデルへのアクセスを有効化する必要があります。コンソールで、左のナビゲーションペインの Model Access を選択し、アクセスしたいモデルの有効化を行いましょう。モデルアクセスが有効になると、さまざまなモデルを試し、ユースケースに適したモデルを見つけるために、さまざまな異なるモデルと推論に関する設定を試すことができます。モデルを試行する際には、本記事の最後に記載された料金モデルに従って支払いが発生します。 例えば、 Cohere の Command モデルを使用した契約に関する固有表現抽出の例は以下のようになります: この例では、プロンプト、サンプルのレスポンス、推論用パラメータの設定例、このサンプルを実行する API リクエストを示しています。 Open in Playground を選択すると、インタラクティブなコンソールで、モデルとユースケースをさらに試すことできます。 Amazon Bedrockは、チャット、テキスト、画像の Playground を提供します。チャットの Playground では、会話型のチャットインターフェースを使用して、さまざまな基盤モデルを試すことができます。次の例では、 Anthropic の Claude モデルを使用しています: 異なるモデルを評価する際には、様々なプロンプトエンジニアリングの手法や推論設定のパラメータを試すべきです。プロンプトエンジニアリングは、タスクやユースケースをよりよく理解し、基盤モデルを適用するための新しい技術です。効果的なプロンプトエンジニアリングとは、基盤モデルの能力を最大限に引き出し、適切かつ正確な返答を得るための完璧なクエリを作り上げることです。一般に、プロンプトはシンプルで直接的で、あいまいさを避けた方が良いです。プロンプトの中で例を提示したり、モデルに対してさらに複雑なタスクを推論させたりすることもできます。 推論設定のパラメータは、モデルが生成するレスポンスに影響します。 Temperature 、 Top P 、 Top K などのパラメータは、ランダム性や多様性を制御し、 Maximum Length や  Max Tokens はモデルのレスポンスの長さを制御します。それぞれモデルは、互いに異なる推論パラメータをもっていますが、それらの中には重複するパラメータがあることに注意してください。これらのパラメータは、異なるモデルを試していくなかで、モデル間で同じ名前か、似たような名前であることに気づくでしょう。 AWSが DeepLearning.AI と共同開発した Generative AI with Large Language Models のオンデマンドコースの第1週目で、効果的なプロンプトエンジニアリング技術と推論設定のパラメータについて詳しく説明しています。 Amazon Bedrock のドキュメント やモデルプロバイダーの関連ドキュメントを参照することで、追加のヒントを得ることができます。 次に、Amazon BedrockをAPI経由で操作する方法を見ていきましょう。 Amazon Bedrock API の利用 Amazon Bedrockは、ユースケースに合った基盤モデルを選択し、数回の API 呼び出しを行うだけの簡単な作業で利用することができます。以下のコード例では、Amazon Bedrock を操作するために、 PythonのAWS SDK (Boto3) を使用します。 利用できる基盤モデルの一覧を取得 まず boto3 の Clientをセットアップし、 list_foundation_models() を使って利用可能な最新の基盤モデルの一覧を取得しましょう。 import boto3 import json bedrock = boto3.client( service_name='bedrock', region_name='us-east-1' ) bedrock.list_foundation_models() Amazon Bedrock の InvokeModel API を使って推論を実行 次に、Amazon Bedrockの InvokeModel APIと boto3 ランタイムクライアントを使用して推論リクエストを実行しましょう。ランタイムクライアントは、 InvokeModel APIを含むデータプレーン API を管理します。 InvokeModel API 次のパラメータを必要とします。 {     "modelId": <MODEL_ID>,     "contentType": "application/json",     "accept": "application/json",     "body": <BODY> } modelId パラメーターは使用する基盤モデルを指定します。リクエストの body は、タスクのプロンプトと、推論設定のパラメーターを含む JSON の文字列です。プロンプトのフォーマットは、選択したモデルプロバイダと基盤モデルによって異なります。 contentType パラメーターと accept パラメーターは、リクエストの body とレスポンスのデータの MIME タイプを定義し、デフォルトは application/json です。最新のモデル、 InvokeModel API のパラメーター、プロンプトのフォーマットに関する詳細は Amazon Bedrock のドキュメント を参照してください。 例: AI21 LabのJurassic-2 モデルを使用したテキスト生成 ここでは、 AI21 Lab の Jurassic-2 Ultra モデルを使用したテキスト生成の例を示します。ノックノックジョークを話してとモデルにリクエストする、Hello Worldのようなものを試してみます。 bedrock_runtime = boto3.client( service_name='bedrock-runtime', region_name='us-east-1' ) modelId = 'ai21.j2-ultra-v1' accept = 'application/json' contentType = 'application/json' body = json.dumps( {"prompt": "Knock, knock!", "maxTokens": 200, "temperature": 0.7, "topP": 1, } ) response = bedrock_runtime.invoke_model( body=body, modelId=modelId, accept=accept, contentType=contentType ) response_body = json.loads(response.get('body').read()) レスポンスは以下の通りです。 outputText = response_body.get('completions')[0].get('data').get('text') print(outputText) Who's there? Boo! Boo who? Don't cry, it's just a joke! InvokeModel API を利用して Embedding (埋め込み) のモデルを利用することもできます。 例: Amazon Titan Embeddings Model を使用したテキスト埋め込みの作成 テキスト埋め込みモデルは、単語、フレーズ、あるいはもっと大きな単位のテキストなどを、埋め込みベクトルと呼ばれる数値表現に変換します。埋め込みベクトルは、テキストの意味的な内容を高次元のベクトル空間に符号化したもので、パーソナライゼーションや検索などのアプリケーションにおいて有用です。この例では、 Amazon Titan Embeddings Model を使用して埋め込みベクトルを作成しています。 prompt = "Knock-knock jokes are hilarious." body = json.dumps({ "inputText": prompt, }) model_id = 'amazon.titan-embed-g1-text-02' accept = 'application/json' content_type = 'application/json' response = bedrock_runtime.invoke_model( body=body, modelId=model_id, accept=accept, contentType=content_type ) response_body = json.loads(response['body'].read()) embedding = response_body.get('embedding') 埋め込みベクトル (一部省略) は、例えば以下のようになります。 [0.82421875, -0.6953125, -0.115722656, 0.87890625, 0.05883789, -0.020385742, 0.32421875, -0.00078201294, -0.40234375, 0.44140625, ...] Amazon Titan Embeddings は一般利用可能です。テキスト生成のための Amazon Titan Text モデルは、限定プレビューで引き続き利用可能です。 Amazon Bedrockの InvokeModelWithResponseStream APIを使用して推論を実行する InvokeModel APIリクエストは同期的で、モデルが出力全体を生成するのを待つ必要があります。ストリーミングレスポンスをサポートするモデルの場合、入力した内容に対して、指定したモデルで推論を実行させながら、モデルが出力を生成するたびにレスポンスをストリーム形式で出力する InvokeModelWithResponseStream API を提供します。 ストリーミング形式のレスポンスは、インタラクティブなアプリケーションにおいて、ユーザを引きつけるような、反応の良いチャットインターフェースを提供する際に役立ちます。以下は、Amazon Bedrock の InvokeModelWithResponseStream APIを使用した Python コードの例です: response = bedrock_runtime.invoke_model_with_response_stream( modelId=modelId, body=body) stream = response.get('body') if stream: for event in stream: chunk=event.get('chunk') if chunk: print(json.loads(chunk.get('bytes').decode)) データプライバシーとネットワークセキュリティ Amazon Bedrock では、お客様がデータを完全にコントロールでき、入力した内容やカスタマイズした内容はお客様のAWSアカウント内でのみプライベートに保持されます。プロンプト、コンプリーション (出力)、ファインチューニングしたモデルなどのデータは、サービス改善のために使用されることはありません。また、データはサードパーティのモデルプロバイダーと共有されることもありません。 お客様のデータは、API コールが処理されたリージョン内にとどまります。すべての通信データ (in transit) は最低 TLS 1.2 で暗号化されています。保管データ (at rest) は、 AWS KMS のマネージドデータ暗号化キーを使用したAES-256で暗号化されています。また、お客様自身のキー (カスタマーマネージドキー) を使用してデータを暗号化することも可能です。 お客様のAWSアカウントとVirtual Private Cloud (VPC) を設定することで、 Amazon VPCエンドポイント ( AWS PrivateLink を利用)を使用して、VPC内で実行されているアプリケーションとAmazon Bedrockの間を、AWSネットワーク上で安全に接続できます。これにより、アプリケーションとAmazon Bedrockの間で、セキュアでプライベートな接続が実現します。 ガバナンスとモニタリング Amazon Bedrock は IAM と統合することで、Amazon Bedrock へのアクセス権限の管理を支援します。これらのアクセス権限には、特定のモデル、Playground、Amazon Bedrock 内の機能へのアクセスが含まれます。すべての AWS マネージドサービスの API 操作(Amazon Bedrock 操作を含む)は、お客様のアカウント内の CloudTrail に記録されます。 Amazon Bedrock は、AWS/Bedrock の名前空間を使用して InputTokenCount 、 OutputTokenCount 、 InvocationLatency 、 Invocations (呼び出し回数) などの一般的なメトリクス情報を CloudWatch に送信します。メトリクスを検索するときにモデル ID のディメンションを指定することで、結果をフィルタリングし、特定のモデルの統計を取得できます。このニアリアルタイムのインサイトにより、Amazon Bedrock で生成系 AI アプリケーションの構築を開始したときの使用量とコスト(入力および出力のトークン数)を追跡し、パフォーマンスの問題 (実行時のレイテンシと実行回数) をトラブルシューティングすることができます。 請求と料金モデル 請求と料金モデルに関して、Amazon Bedrockを利用する際には、以下を念頭に置いてください: 請求 – テキスト生成モデルは、処理された入力トークンと生成された出力トークンの両方について請求されます。テキスト埋め込みモデルは、処理された入力トークンについて請求されます。画像生成モデルは、生成された画像について請求されます。 料金モデル – Amazon Bedrockは、オンデマンドとプロビジョンドスループットの2つの価格設定モデルを提供しています。オンデマンド価格設定では、期間のコミットメントをすることなく、利用した分だけの支払いで基盤モデルを利用できます。プロビジョンドスループットは、主に大規模で一貫した推論ワークロード向けで、期間のコミットメントと引き換えに、保証されたスループットが必要な場合に設計されています。アプリケーションのパフォーマンス要件として、1分あたりの最大入力トークン数と出力トークン数を満たすために、特定の基盤モデルのモデルユニット数を指定します。詳細な価格情報は、 Amazon Bedrockの料金 をご参照ください。 Now Available Amazon Bedrockは、現在AWSリージョンの US East (バージニア北部)とUS West (オレゴン) で利用できます。詳細は、 Amazon Bedrock ウェブサイト 、 Amazon Bedrock のドキュメント 、 community.aws の generative AI のスペース をご覧ください。また、 Amazon Bedrock workshop でハンズオン体験ができます。Amazon Bedrock に関するフィードバックは、 AWS re:Post for Amazon Bedrock か、通常のAWSのお問い合わせ先までお送りください。 (プレビュー) Amazon Titan Textのテキスト生成モデル、Stability AI の Stable Diffusion XL  画像生成モデル、および agents for Amazon Bedrock (Knowledge Baseを含む) は、限定プレビューとして引き続き利用できます。アクセスをご希望の方は、AWSのお問い合わせ先までご連絡ください。 (近日公開) Meta の Llama 2 13Bおよび70Bパラメータモデルが、Amazon BedrockのフルマネージドAPIを通じて、推論とファインチューニングを利用できるようになります。 今日から Amazon Bedrock を利用して生成系 AI アプリケーションを構築しましょう！

AWS Amplify は、AWS Amplify Studio で GraphQL API をフルサポートすることを発表しました。これによって、DataStore の有無に関わらず、 Connected Forms や Data Manager のような、Amplify Studio の既存のデータ駆動の機能が、すべての新規および既存の Amplify アプリで利用できるようになりました。 何が新しくなったのか？ 今まで多くの Amplify Studio の機能は、すべての API に 競合解決モードセット を設定する必要がありました。Amplify DataStore は GraphQL API のラッパーで、デバイスがオフラインの間、ローカルでデバイス上のストレージを使用してデータを処理します。DataStore は、選択した競合解決ストラテジーを使用して、オフライン使用から生じるデータの不整合を処理します。 開発者からは、DataStore を使用しないアプリにも Amplify Studio の一連の機能を拡張してほしいという要望が寄せられていましたが、私たちはこれに応えました。今回の発表により、Amplify Studio はすべての Amplify GraphQL API と直接連携できるようになりました。 DataStore を使用していない開発者向けに、以下の機能が利用可能になりました。 Data Manager GraphQL API へのデータの作成、管理、シードは時間がかかり、面倒な場合があります。データマネージャーは、データ管理を簡単にするビジュアルコンテンツマネージャーです。データマネージャーは API に自動的に接続され、データスキーマと常に同期します。 Figma to Code + データバインディング わずか数行のコードで、Figma デザインからリアルタイムでクラウドに接続されたコンポーネントへ変換することが出来ます。Figma to Code を使用したデータバインディングにより、API のデータを利用して、 ユニークなコンポーネントの動的なコレクション を生成することができます。 Connected Forms クラウドに接続された美しい React フォームを、必要なときにすぐに入手できます。 Connected Forms は、GraphQL API に自動的にリンクされ、デザインも動作も完全にカスタマイズできます。 Amplify Studioの拡張サポートは、 既存のすべての Amplify アプリにも適用されます 。Amplify Studio を起動するか、既存のアプリに Amplify Studio を追加するだけで、すべての機能が Amplify アプリですぐに利用できるようになります。 Amplify Studio で新しい GraphQL API を構築する Amplify Studio で新しい GraphQL API を構築するには、まず新規または既存の Amplify アプリを開き、 Amplify Studio を起動する 必要があります。既存の Amplify アプリは Amplify コンソール で見つけることができます。 新しいアプリを作成する 場合は、アプリと名前を入力し、”Confirm deployment” を選択します。 デプロイが完了したら、”Launch Studio” ボタンを使用してスタジオを開きます。 スタジオを開いたら、左側のナビゲーションバーで Data タブを選択し、ビジュアル・データ・モデラーを開きます。”Add model” をクリックして、スキーマにテーブルを作成し定義します。スキーマが完成したら、右上隅にある “Save and Deploy” を選択します。 送信すると、Amplify はあなたのスキーマで新しい GraphQL API を生成します。API がデプロイされると、Amplify バックエンドをローカルプロジェクトに追加する準備が整います。生成された amplify pull コマンドをコピーし、ローカルプロジェクトのルートディレクトリで実行して、新しく作成した API をインポートします。 まだローカルプロジェクトを持っていない場合は、 こちらのドキュメント を参考に Next.js アプリや他のサポートされているフレームワークのプロジェクトを作成することができます。 amplify pull が完了したら、API を使用する準備ができました。 amplify add codegen を実行すると、Amplify CLI が自動的に GraphQL クエリを生成します。 重要: amplify add codegen の実行は、クエリーの深さを 4 に設定することをお勧めします。これによって、すべての Amplify Studio の機能が期待通りに動作します。 amplify configure codegen を実行することで、いつでもクエリの深さを変更できます。 競合解決の設定を変更する デフォルトでは、Amplify は競合解決を 無効 にして GraphQL API をプロビジョニングします。競合解決が無効になっている間、Amplify は Amplify Libraries を使用して GraphQL API と直接接続します。アプリがオフラインとオンラインの両方で動作する必要がある場合は、競合解決を有効にして DataStore を有効にすることができます。 競合解決を有効/無効にする、または競合解決戦略を変更するには、Data タブに移動し、”GraphQL API Settings” を選択します。 GraphQL API 設定で、競合解決を有効または無効にするスイッチをクリックします。競合解決が有効な場合、ドロップダウンで利用可能な競合解決ストラテジーから選択できます。 設定が完了したら、左上の “Back to Data Modeling”をクリックし、”Save and Deploy “で変更を適用します。最後に、ターミナルを使用して、プロジェクトのルートディレクトリで amplify pull を実行すると、更新された設定の APIが使用できるようになります。 重要：競合解決を無効にすると、データが破壊的に変更されます。データのない GraphQL API でのみ競合解決設定を変更することをお勧めします。詳しくはドキュメントをご覧ください。 今すぐ始める Amplify Studio は、GraphQL API の視覚的な設計とデプロイを簡単にし、Data Manager、Figma to Code、Form Builder などのツールを提供して、アプリの差別化を支援します。新しい Studio ユーザーであっても、長年の Amplify 開発者であっても、Studio はアプリ開発を加速するのに役立ちます。 今すぐ Amplify アプリの構築を始めましょう。 本記事は、 AWS Amplify Studio now offers direct support for GraphQL APIs を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

この記事は Amazon EKS now supports Kubernetes version 1.28 (記事公開日: 2023 年 9 月 26 日) を翻訳したものです。 はじめに Amazon Elastic Kubernetes Service ( Amazon EKS ) チームは、 Amazon EKS および Amazon EKS Distro の Kubernetes バージョン 1.28 のサポートを発表できることを嬉しく思います。 Amazon EKS Anywhere (リリース 0.18.0) も Kubernetes 1.28 をサポートします。このバージョンのリリース名は「Planternetes」です。このテーマは、植物 (Plant) と Kubernetes を組み合わせて庭園をイメージさせる言葉遊びです。 Kubernetes リリースチームは、 公式リリース発表 の中で、このリリースについて「このリリースを支えているのは、さまざまなバックグラウンドを持つ人々です。」と述べています。 Kubernetes 1.28 のハイライト この記事では、Kubernetes バージョン 1.28 リリースの注目すべき機能強化、および削除と非推奨の一部について説明します。まず、このリリースでは、コントロールプレーンとノードコンポーネントの間でサポートされるバージョンスキューの拡張を含む、いくつかの重要な変更が加えられていることに注意してください。v1.28 には、高度なステートフルワークロード管理のサポートなど、私たち全員が興奮している素晴らしい機能強化もあります。 以下は、1.28 リリースに関して技術コミュニティが興奮した機能強化の一部です。Kubernetes バージョン 1.28 の変更とアップデートの完全なリストについては、 Kubernetes リリースブログ を確認してください。 コントロールプレーンとノードのバージョン間でサポートされるスキューの変更 Kubernetes v1.28 では、コアコンポーネントに対してより寛容なバージョン互換性ポリシーが導入され、Kubernetes API サーバーと kubelet の間でサポートされるスキュー (ずれ、不均衡) が n-2 から n-3 に 1 マイナーバージョン分拡大されます。これは、サポートされている最も古いマイナーバージョンのノードコンポーネントが、サポートされている最新のマイナーバージョンの Amazon EKS コントロールプレーンコンポーネントと連携できることを意味します。例えば、Amazon EKS のバージョンが 1.26 の場合、使用できる最も古い kubelet のバージョンは 1.23 です。この変更は、 AWS Fargate 、 マネージド型ノードグループ 、 セルフマネージド型ノード でサポートされます。結局のところ、この変更により、データプレーン上の kubelet を更新するための猶予期間が少し長くなります。この変更により、データプレーン上で kubelet のマイナーバージョンを更新するための猶予期間が追加されますが、セキュリティ上の理由、特に潜在的な共通脆弱性識別子 (CVE) を考慮して、より新しい AMI (Amazon Machine Image) バージョンを維持することの重要性が否定されるわけではないことに注意してください。この n-3 スキューの変更は、現在サポートされているバージョンにのみ適用されます。あるバージョンがサポート終了となった場合、現在サポートされているバージョンのみの使用に制限されます。 詳細については、 Changes to supported skew between control plane and node versions を参照してください。 ステートフルワークロードの機能強化が安定版に移行 Kubernetes 1.28 では、特にステートフルワークロードの処理を強化する、高度なストレージ機能スイートが発表されました。Kubernetes Enhancement Proposal (KEP) ( #2268 , #3333 ) で説明されているこれらの機能強化は、安定版への移行が完了したため、すぐに利用可能です。これらの機能は、ステートフルワークロードをクラスター内でより効率的に管理できるようにする VolumeAttachment や PersistentVolumeClaim (PVC) などの強力なツールセットを提供します。StorageClass が定義されていないストレージを処理する場合でも、PersistentVolume (PV) を作成するオプションがあります。StorageClass を参照せずとも、NFS マウント用の PV を作成し、NFS サーバーの詳細とともに PV を定義するなど、PV を直接手動でプロビジョニングして作成することができます。その後、PV を PVC 経由で要求し、ステートフルワークロード用のストレージをプロビジョニングできます。 #2268 は安定版に移行し、NodeOutOfServiceVolumeDetach フィーチャーゲートはデフォルトで有効になりました。この機能は、グレースフルではないノードシャットダウンからの復旧を可能にし、ステートフルワークロードを別のノードに正常にフェイルオーバーできるようにします。これは、さまざまなプラットフォームでノードのシャットダウンを処理する際の以前の制限に対処します。既存の VolumeAttachment がシャットダウンされた元のノードから切り離されることを確実にすることで、ステートフルなアプリケーションのシームレスな移行を可能にします。 #3333 は安定版に移行し、RetroactiveDefaultStorageClass フィーチャーゲートはデフォルトで有効になりました。この機能により、PVC に対するデフォルトの StorageClass の自動的かつ遡及的な割り当てが安定に移行しました。PVC に StorageClassName が定義されていない場合、Kubernetes は自動的に StorageClassName を設定します。この機能により、ステートフルワークロードのストレージ管理の堅牢性が強化され、Kubernetes クラスター内でのストレージリソースの一貫した処理が保証されます。 詳細については、 Kubernetes 1.28: Non-Graceful Node Shutdown Moves to GA および Kubernetes v1.28: Retroactive Default StorageClass move to GA を参照してください。 高度なトポロジー管理ときめ細やかな Pod 配置がベータ版に到達 Kubernetes v1.28 では、洗練された多様なトポロジー管理機能が導入されました。KEP ( #3545 ) で詳しく説明されているこれらの機能は、デフォルトで有効になっており、ベータ版で利用可能です。これらを組み合わせることで、リソース効率を最大化し、パフォーマンスを向上させ、耐障害性を強化する方法で Pod の配置を調整するという課題に対処する、堅牢な強力なツールを形成します。両方のオプションを使用することで、Pod を互いに近くに配置してパフォーマンスを向上させるだけでなく、アベイラビリティゾーンなどの他の制約にも従い、クラスターリソースを効率的に使用できます。 TopologyManagerPolicyBetaOptions は、ノードのトポロジーやリソースのアベイラビリティなどの要素に基づいて Pod の配置を微調整するための高度な設定を提供します。主要な設定の 1 つは、prefer-closest-numa-nodes ポリシーです。 NUMA (Non-Uniform Memory Access) ノードは、CPU とメモリのグループです。通常、Topology Manager は利用可能な NUMA ノードに Pod を分散させますが、この設定は Topology Manager に近くの NUMA ノードを優先するように指示します。このオプションを有効にすると、Topology Manager は Pod の配置についてより多くの情報に基づいた決定を下せるようになり、NUMA ノード間の距離を考慮するように指示されます。これは、レイテンシーの影響を受けやすいアプリケーションや高スループットを必要とするアプリケーションにとって重要です。 TopologyManagerPolicyOptions は、独自のクラスタートポロジーに従って Pod の配置を調整する際の、追加のきめ細やかなレイヤーを提供します。この機能を使用すると、ノードラベル、アフィニティルール、およびリソース制約に基づいて制約を定義できるため、Pod の配置を細かく制御できます。これにより、ノードラベル、アフィニティルール、およびリソース制約を使用して制約を定義できます。たとえば、リソース使用率を最適化するために、Pod を特定のアベイラビリティゾーンに制限するように指定できます。 これらは強力な機能ですが、既存の Pod の仕様やノードの設定を調整する必要があることに注意してください。その影響を総合的にテストし、問題が発生した場合のロールバック計画を立てておくことをお勧めします。何らかの問題が発生した場合は、機能を無効にして kubelet を再起動することをお勧めします。 詳細については、 Control Topology Management Policies on a node を参照してください。 非推奨とその他のアップデート Kubernetes バージョン 1.28 のリリースに伴い、Amazon EKS は Amazon Elastic Compute Cloud ( Amazon EC2 ) インスタンスの互換性に直接影響する非推奨事項を含む、いくつかの重要な変更を導入しています。Kubernetes 1.28 に移行する前に、これらのアップデートを確認し、それに応じて Amazon EKS クラスターとアプリケーションを適応させることが重要です。この文脈における主な変更点は以下のとおりです。 Amazon EC2 P2 インスタンスの廃止 Kubernetes バージョン 1.28 以降では、Amazon EKS optimized accelerated Amazon Linux AMI で Amazon EC2 P2 インスタンスを使用することができなくなりました。 Kubernetes バージョン 1.28 以降向けのこれらの AMI は、P2 インスタンスと互換性のない NVIDIA 525 シリーズ以降のドライバーをサポートします。ただし、NVIDIA 525 シリーズ以降のドライバーは、P3、P4、および P5 インスタンスと互換性があるため、Kubernetes バージョン 1.28 以降の AMI でこれらのインスタンスを使用できます。Amazon EKS クラスターをバージョン 1.28 にアップグレードする前に、P2 インスタンスを P3、P4、P5 インスタンスに移行してください。また、NVIDIA 525 シリーズ以降で動作するように、アプリケーションを積極的にアップグレードすることをお勧めします。 サポートの終了 Amazon EKS は、常に少なくとも 4 つの Kubernetes バージョンをサポートしています。Kubernetes のリリースサイクルの性質を考えると、すべてのお客様にとって、継続的なアップグレード計画を持つことは非常に重要です。1.23 や 1.24 などの古いバージョンの Kubernetes をまだ実行している場合は、 より新しいサポートされているバージョン のいずれかにアップグレードすることを検討してください。1.23 クラスターのサポート終了は 2023 年 10 月 11 日、1.24 クラスターのサポート終了は 2024 年 1 月を予定しています。Amazon EKS のバージョンサポートに関してさらに質問がある場合は、 FAQ を参照してください。 まとめ この記事では、Kubernetes バージョン 1.28 の注目すべき変更点を紹介し、利用可能となった最もエキサイティングな機能のいくつかをハイライトしました。 Kubernetes v1.28 のリリースノート に記載されているその他の改善点もぜひチェックしてみてください。クラスターを最新の Amazon EKS バージョンにアップグレードする際にサポートが必要な場合は、 こちら のドキュメントを参照してください。 翻訳はプロフェッショナルサービスの杉田が担当しました。原文は こちら です。

業界調査会社の Information Services Group, Inc. (ISG) は、レポート ISG Provider Lens “Mainframes – Services and Solutions” を毎年発行しています。このレポートは、メインフレームアプリケーションモダナイゼーションソフトウェアを企業に提供しているベンダーの現在の市場での位置付けを、そのサービス提供の深さと市場での存在感に基づいて評価しています。 このたび本レポートに AWS Mainframe Modernization サービスが初めて掲載され、米国市場のリーダーとして評価されました。また、AWS はポートフォリオの魅力度でも最高位にランクされています。 レポートの筆頭著者である Pedro L Bicudo Maschio 氏は、「AWS は、強固なパートナーネットワークに支えられて、複雑なモダナイゼーションのための完全なポートフォリオを提供しています」と述べています。 AWS の強みは、モダナイゼーションとイノベーション、独自のクラウドネイティブなモダナイゼーションソリューション、厳選されたパートナーとソリューションにあると ISG が強調しています。 この評価は、メインフレームモダナイゼーションにおける AWS の6年間の投資とイノベーションの集大成であると我々は考えています。AWS Mainframe Modernizationは2017年にAWS パートナーネットワークの中の特定のパートナーとの協業から始まり、メインフレームの専門家を多数採用することで成長しました。革新的な AWS Mainframe Modernization というクラウドネイティブなサービスと AWS Mainframe Migration Acceleration Program (MAP) の併用により、この傾向はさらに加速しました。 AWS Mainframe Modernization サービス は、メインフレームアプリケーションをモダナイズするための、クラウドネイティブな独自の従量課金制サービスです。そのランタイム環境には、自動リファクタリング用の事前構成済みの AWS Blu Age ツールセット、リプラットフォーム用の Micro Focus ツールセット、Precisely によるデータ複製用の追加拡張パターン、Model9 によるファイル転送を含みます。このサービスは現在 15 の AWS リージョンで利用でき、将来的にはさらに多くのリージョンでも利用できるようになる予定です。AWS のソリューションアーキテクト、事業開発、プロフェッショナルサービスが、利用開始のお手伝いをします。このサービスは、厳選された AWS Mainframe Modernization コンピテンシーパートナー による支援も可能です。AWS は、メインフレーム向けの AWS Migration Acceleration Program ( MAP ) を通じて提供される、メインフレームのモダナイゼーションを加速するための具体的な方法論とインセンティブを提供しています。AWS は、お客様がビジネス変革を加速できるよう支援する機会を得て、新しい自動化機能、パートナーテクノロジーの統合、その他のユースケースのサポートにより、メインフレームアプリケーションのモダナイゼーションを革新し続けています。 2023 ISG Provider Lens US Quadrant for Mainframe Services and Solutions – Mainframe Application Modernization Software の無償コピーは、 こちら から入手できます。 本記事は、Ilia Gilderman と Madhavi Reddy による “ AWS Recognized as a Leader in the 2023 ISG Provider Lens for Mainframe Application Modernization Software ” を翻訳したものです。翻訳はソリューションアーキテクトの皆川 元が担当しました。 TAGS: Announcements

メインフレームはビジネス成長を支えるサービスとして長く利用されていますが、複雑性、運用保守コストや人材不足が課題となっています。ベンダーの製造・販売からの撤退も大きな衝撃をもたらしています。本ブログではMainframe Modernizationへのアプローチとして、 前編 では（１）ビジネス状況に応じたビジネスゴールの設定、（２）Mainframe Modernizationに向けた戦略立案についてご紹介し、後編では（３） AWS Mainframe Modernization でのソリューション選定についてご紹介します。 （３）AWS Mainframe Modernizationでのソリューション選定 AWSや AWSパートナー はさまざまな移行ソリューションを提供しており、用途に合わせた最適なソリューションを選定することができます。ここではAWS Mainframe Modernizationが提供する「 自動リファクタリング 」、「 リプラットフォーム 」についてご紹介します。なお、データ移行の新しいソリューションとしては、「 データレプリケーション 」、「 ファイル転送 」があります。 a. 「自動リファクタリング」ソリューション AWS Blu Age は、新しいウェブ・フレームワークとクラウド DevOps のベストプラクティスを駆使し、レガシーな言語アプリケーションをアジャイルなJavaベースのサービスに自動変換する強力なリファクタリング・ソリューションです。AWS Blu Ageは業務ロジックの変更を最小限に抑え、初期投資を削減することを目指しています。これにより、既存のシステムを効率的にアップデートし、ビジネスへの影響を低く抑えることができます。アップデートされたシステムと幅広いソリューションのオプションにより、新しいニーズにも素早く対応できるのは大きな利点です。また、AWS Blu AgeはJavaとの親和性を活かし、既存のシステムと新たなシステムをシームレスに連携させることができます。さらに、AWS Blu Ageは、システム全体に与えるリファクタリングによる影響を事前に評価し、品質を確保することができるため、安定したシステム運用を維持しつつアップデートを進める信頼性があります。このように、AWS Blu AgeとJavaを組み合わせることは、効率的かつ確実な業務モダナイゼーションを実現するための有力な手段です。 b. 「リプラットフォーム」ソリューション Micro Focusツールチェーン を使用して、COBOLアプリケーションの移行を行うアプローチは、特に注目されています。なぜなら、COBOLは長い歴史を持ち、その安定性と信頼性が確立されており、多くの企業で広く利用されているからです。したがって、既存のCOBOLシステムを維持しながら、プラットフォームをアップデートすることで、ビジネス運用の安定性を確保することが可能です。リプラットフォームのアプローチは、新たなシステムへの移行に比べてコストを大幅に削減できる点でも魅力的です。既存のシステムを基盤として、必要な部分を最新の技術で更新することで、コストを節約しながらシステムをモダナイゼーションできます。また、COBOLのスキルを持つエンジニアや開発者が新たなスキルを習得するためには時間とリソースが必要ですが、既存の人材を活用することでシステムの継続的な運用を確立することができます。統合されたMicro Focusツールチェーンを使用したCOBOLアプリケーションの移行は、AWS Mainframe Modernizationの成功事例の一つとしてビジネスに大きな価値を提供します。 おわりに Mainframe Modernizationは、ビジネスゴールを明確に設定し、最適な戦略を立案し、最適なソリューションを選択することで、多くのビジネス・メリットを享受することが出来ます。新しいテクノロジーとアプローチを活用することで、コストの削減、アジリティの向上、技術的負債とリスクの低減などが実現可能です。ビジネスのさらなる発展に向けてMainframe Modernizationへの取り組みは現代のビジネス環境に不可欠なステップになります。

メインフレームはビジネス成長を支えるサービスとして長く利用されていますが、複雑性、運用保守コストや人材不足が課題となっています。ベンダーの製造・販売からの撤退も衝撃をもたらしています。本ブログではMainframe Modernizationへのアプローチの前編として（１）ビジネス状況に応じたビジネスゴールの設定、（２）Mainframe Modernizationに向けた戦略立案についてご紹介します。 （１）ビジネス状況に応じたビジネスゴールの設定 メインフレームを運用しているお客様がビジネスゴールを設定するには、主要な観点を考慮した上でビジネス状況に応じた検討を行うことが重要です。 a. 財務上の成果 メインフレームの運用保守コストは他のコンピュータ資源に比べ高額であり、上昇傾向にあります。財務上の成果を達成するために、コストを削減し、運用効率を向上させる必要があります。 b. ビジネスリスクの軽減 メインフレームの技術的負債や人的リスク等のリスクを軽減し、競争力を確保するためには、最新のテクノロジーに適応させる必要があります。モダナイゼーションやクラウド移行により、目標とするビジネスゴールを設定します。 c.　ワークロードの特性 メインフレームのワークロードには、ビジネスの中心で利用され今後も更改され続けるもの、現状ほとんど変更がなく維持を継続する個々のワークロードの特性があります。その特性に合わせたビジネスゴールを設定します。 d. 俊敏性とインサイトの確保 メインフレームのデータはマスタデータとして広く活用されていますが、特有のデータ構造のため俊敏性や拡張性に劣ります。最新のテクノロジーの採用とデータ利用の革新性を高め、ビジネスプロセスの改善や意思決定のサポートに役立てるビジネスゴールを設定します。 （２）Mainframe Modernizationに向けた戦略立案 メインフレームをモダナイズするには、ビジネスゴール、ワークロードの特性および移行コスト等を考慮した移行戦略を立案します。その上で、ビジネスニーズに合った最適な移行ソリューションを選定します。 a. Migration & Modernization（移行とモダナイゼーション） 対象のワークロードをクラウドに移行することで、コストの削減、アジリティの向上、技術的負債とリスクの低減を実現することができます。ビジネスゴールに従って7Rアプローチによる移行戦略を策定します。以下に戦略策定の例を示します。 リプラットフォーム：短期間にできる限りコストを掛けずに他のプラットフォームに移行します。 リファクタリング：モダナイゼーションと俊敏性を高めつつコストを抑えて移行します。 リパーチェス、リライト：積極的に投資をおこない革新的な環境に作り直します。 b. Augmentation & Integration（拡張と統合） クラウドによる俊敏性と革新性を提供することで、メインフレームのデータから最大限の価値を引き出すことができます。ここでは、データの価値を高めるための戦略を策定します。 クラウド上でのデータ活用：メインフレームからクラウドにリアルタイムでデータを連携し、クラウド上で新しいチャネルや機能を提供し、顧客に新たな価値を提供します。 クラウド上でのデータ分析: データをクラウド上で分析し、洞察を得て戦略的な意思決定に活用します。 クラウドストレージ を使用したバックアップとアーカイブ: データの安全なバックアップと長期保存をクラウドストレージで行うことで、データの保護と可用性を向上させます。 Mainframe Modernizationのアプローチは、ビジネスゴールを設定した上で移行戦略を策定することが重要です。その上でソリューションを選定することでビジネスニーズに沿ったアプローチが可能になります。 後編 では、（３） AWS Mainframe Modernization でのソリューション選定についてご紹介します。

ソリューションアーキテクトの浅野です。2023年8月24日に「 製造業の設計開発領域向けセミナー ～AWSのHPCを活用した製品の設計開発期間の削減～ 」をオンライン開催しました。 本セミナーでは製造業での製品設計の研究・開発をされているお客様に向けて、流体解析や構造解析などで用いら入れるCAEなどでのAWS活用をご紹介いたしました。AWSからは、実際にAWSのHPCを活用頂いているお客様にご登壇頂き、設計者の方々ににいかに簡単にご利用いただけるか、セキュリティへの対応、実際のアプリケーション性能、AI/MLの活用事例をご紹介頂きました。AWSからは高パフォーマンスを実現する AWS のユニークなテクノロジや HPC に関連する AWS サービスの解説の他、hpc6a インスタンスや Graviton3 プロセッサなど最新のアップデートについてもご紹介しております。 本記事では、発表内容の概要と、発表資料を掲載します。 セミナー概要 タイトル :「製造業の設計開発領域向けセミナー ～AWSのHPCを活用した製品の設計開発期間の削減～」 日時 : 2023 年 8 月 24 日 (木) 10:00 – 12:00 10:00 – 10:05 オープニング スピーカー: AWS シニアビジネスデベロップメントマネージャー 舛重 国規 10:05 – 10:35 クラウドで設計・開発プロセスを爆速化！AWSを活用したオムロン独自の研究開発環境「RDinX」 スピーカー: オムロン株式会社 経営基幹職 津田 学 氏 自社セキュリティ基準に準拠したオムロン独自のAWS開発環境「RDinX」を構築。CAE・最適化のための演算リソースの柔軟な確保を実現し、パワーエレクトロニクス技術のプロセスを大幅削減！ 講演資料 10:35 – 11:05 プラントエンジニアリングのCAEにおけるHPC on AWS活用事例（ベンチマークを中心として） スピーカー: 千代田化工建設株式会社 リードエンジニア 髙城 恭司 氏 長年3次元流動解析（CFD）をHigh Performance Computing基盤にて実施しているが、近年はCPUおよびGPUの選択肢が増えている。本講演では、プラントエンジニアリングにおけるCAE活用事例や、各種CPUおよびGPUの実検討モデルにおけるベンチマーク結果（計算速度）について発表する。 講演資料 11:05 – 11:35 マテリアルズ・インフォマティクスと画像検査自動化への挑戦 スピーカー: 三協立山株式会社 三協マテリアル社 林 良和 氏、佐藤 晃太 氏 MI（林 様）: 材料工学の分野で「機械学習を活用した材料探索」（MI）が注目されています。本セッションではAmazon SageMakerを用いたMIによる材料開発について紹介します。 画像解析（佐藤 様）: Pythonを始めて数か月のエンジニアが、社内で蓄積された画像検査データとAmazon SageMakerを使って、画像検査の自動化に挑戦した過程をご紹介します。 講演資料 11:35 – 11:55 HPC on AWS の概要と最新動向 スピーカー: AWS シニアソリューションアーキテクト 吉廣 理 AWS では HPC 環境に求められる高レベルな CPU /ネットワーク/ストレージパフォーマンスは勿論、VDI やオーケストレーションなどクラウド HPC 環境をアシストする機能を兼ね備えています。本セッションでは高パフォーマンスを実現する AWS のユニークなテクノロジや HPC に関連する AWS サービスの解説の他、hpc6a インスタンスや Graviton3 プロセッサなど最新のアップデートについてもご紹介します。 講演資料 11:55 – 12:00 クロージング スピーカー: AWS シニアデベロップメントマネージャー 舛重 国規 おわりに 今回のセミナーでは、設計・開発分野でAWSを活用頂いているお客様より、実際の活用例や、導入にあたっての課題といったリアルな使い方についてご紹介頂きました。実業務での使い心地や導入時の課題に関心がある方々にとって、参考にして頂ける内容になっております。AWSでは、HPC環境を簡単に構築でき、コスト効率よくご利用いただけます。ぜひ設計・開発業務でもAWSをご活用ください！