現代のダイナミックな市場におけるサプライチェーンの管理には多くの課題があります。なぜなら、企業は急速に変化する消費者需要、技術の進歩、経済の不安定性、競争の激化に対処しなければならないからです。 これらの要因は需要と供給のバランスを崩し、業務の複雑さを増します。 供給計画、つまり顧客の需要を満たすために必要な製品（または原材料や部品）の数量を見積もるプロセスは、サプライチェーンの最も重要な分野の1つです。 従来、供給計画担当者は、需要予測とサプライヤーのリードタイムデータを元に平均値や固定値を使用してこれらの計算を行っていました。 その後、計画担当者は余剰在庫の割合を加算して安全在庫を確保します。 このアプローチでは、リードタイムの変動や物流の遅延が考慮から外され、一定の誤差が生じるため、過剰在庫や在庫不足が発生します。 マッキンゼー・アンド・カンパニーによると、 2022年小売業者は在庫不足を緩和するために在庫を過剰に購入し続けたため 、余剰在庫は 12% 増加して 740 億ドルになりました。こうした状況に対し機械学習（ ML ）を活用した供給計画プロセスを採用することで、変化する状況や傾向に合わせてダイナミックな対応を行うデータドリブンで予測的な供給計画モデルを使用できます。 ガートナーは、 2026年までに商用サプライチェーンソリューションの 75% 以上が、高度な分析 ( AA )、人工知能 ( AI )、データサイエンスまたは機械学習 ( ML ) ベースの機能を標準プロセスに組み込むと予測しています。 このブログ記事では、クラウドベースのアプリケーションである AWS Supply Chain が ML ベースのリードタイム変動検出を使用して計画の精度を向上させる方法について説明します。 これにより、企業は顧客満足度を犠牲にすることなく、より優れたコスト管理戦略を実現できます。 従来型と ML ベースの2 つの供給計画アプローチを使用する場合の違いと、ML 機能によって精度がどのように向上するかについて学びます。 ML ベースのリードタイム計算と従来の方法との比較 2つの供給計画手法の違いを理解するために、一般的な消費財企業のシナリオを元に作成した以下の数値例を考えてみましょう。 下記のグラフは、従来の供給計画手法と ML ベースの供給計画方法を使用した在庫計画を示しています。 黒い線は毎月の需要を表しており、これは受注数量によるものです。 オレンジ色の線は、固定リードタイムまたは平均リードタイムを使用して従来の方法で計算された在庫レベルを表しています。 需要ラインと在庫ラインの両方が前月比で変動します。 季節的な需要によって大きな変動が生じる可能性があるため、需要ラインの変動が予想されます。 オレンジ色の線の変動は、ある月では在庫過多を引き起こし、他の月では在庫不足を引き起こすことを表しています。 固定的なデータのみ利用して計画するとこの種の変動の一因となるため、供給計画担当者は、需要を逃さないように必要な在庫を過大に見積もりして供給計画を手動で調整します。 このアプローチは有効ですが、その結果として、計画担当者がモデルの調整に費やす時間が長くなったり、余剰在庫によりコストが増加したりします。 青い線は、ML ベースの方法で計算された月次在庫レベルを表します。 この方法では、過去と現在の取引（未処理注文や出荷など）の両方を使用して、10パーセンタイル（ P10 ）、50パーセンタイル（ P50 ）、90パーセンタイル（ P90 ）に基づいて確率的リードタイム予測を決定します。 ML アルゴリズムは、曜日 (配送タイムライン用)、出荷数量 (履歴量)、輸送レーン定義 (出荷元、出荷先、インコタームズ（貿易取引条件）などの特性を含む) などの主要な製品機能を使用して予測モデルを作成およびトレーニングします。 これらの特徴量は、注文リードタイムや予測に影響するデータポイントですが、平均値を用いるリードタイムの見積もり方法では無視されています。 ML アルゴリズムは、これらの変数の変化を学習に組み込んで調整するため、確率的なリードタイム予測が計算されます。 P50 は納期の推定値を示しますが、P10 と P90 は製品の配送シナリオの最良シナリオと最悪のシナリオを評価するのに役立ちます。 上のグラフでは、P50 を使用して供給量を計算しています。 2つの在庫レベルの計算アプローチの違いは、需要と供給のばらつきを使用して比較することもできます。 需要と供給のばらつきは、需要予測と計画在庫レベルの差であり、通常は毎月追跡されます。 以下のグラフは、前述の例の需要と供給のばらつきを計算し、各供給計画アプローチの分散値を示しています。 グラフの X 軸は、1 月から 12 月までの月を表します。 Y 軸は需要予測と計画在庫の差を表し、マイナス 15 からプラス 25 までの数値を一覧表示します。 需要と供給が完全に一致している理想的なシナリオでは、分散値は 0 になります。 これは黒い点線で示され、比較のベースラインです。 オレンジ色の線は、従来の計画方法と平均リードタイムを使用した分散値を表しています。 青い線は ML モデルを使った分散値を表します。 従来のアプローチ（オレンジ色の線）のばらつきは、プラス面とマイナス面の両方に顕著です。 正の分散値は、供給レベルが需要を上回っていることを意味し、過剰在庫の状況を示しています。 過剰在庫は過剰な運転資本を必要とし、在庫が傷みやすいものや季節限定のものである場合にはほかのリスクを招きます。 負の分散値は、供給レベルが需要よりも低いことを意味し、在庫切れの状況を示しています。 在庫切れは、顧客の喪失、収益の損失、顧客満足度の低下につながる可能性があります。 ML ベースのアプローチ（青い線）は、ばらつきが少なく、より正確な供給計画を実現します。 ML モデルは適応性もあるため、多くの情報を収集すればするほど正確になります。 AWS Supply Chain で ML ベースのリードタイム変動検出を使用する AWS Supply Chain は、ML ベースのアルゴリズムを使用してリードタイムの変動を検出するのに役立つビジネスアプリケーションです。 このアプリケーションでは、過去の処理済みトランザクションと、未出荷や未発送などの処理中のトランザクションが考慮されます。 ML アルゴリズムには、季節性、製q33品特性、ベンダーの特徴、配送先サイトなどの追加情報も組み込まれ、モデルをトレーニングします。 ユーザが運用パラメーターと条件を定義すると、アプリケーションがトランザクションを監視して、予測リードタイムと予想される配送日（信頼レベル付き）を算出します。 AWS Supply Chain は想定リードタイムとの差異を計算し、その差異がユーザー定義の許容範囲 (標準偏差) を超える場合は、リードタイムを見積もり直すことを推奨します。 この ML ガイドによるリードタイムの変動検出により、供給計画担当者は需要を満たす適切な在庫レベルを自信を持って維持できます。 ウォッチリストによるリードタイムの逸脱に関するインサイトの監視 AWS Supply Chain はお客様のサプライチェーンネットワークを監視し、注文、出荷、在庫移動などのトランザクションデータから学習します。 ユーザーは、製品、場所などの特定の監視対象のパラメーターを、追跡する過去の期間などの条件とともに定義できます。 監視する基準と対象のパラメーターを指定して、ウォッチリストを作成します。 AWS Supply Chain アプリケーションでは、 [インサイトウォッチリストを作成] を選択します。 次の画面が表示され、追跡する主要なパラメーターを入力します。 まず、製品、場所、またはこれら2つの組み合わせを選択します。 次に、リードタイム標準偏差 (リードタイム差異の許容範囲) と時間間隔を入力してリードタイムデータを追跡します。 このウォッチリストを他のユーザーと共有するには、 [ウォッチャー] ボックスに名前を追加します。 次のスクリーンショットは、指定した基準に違反している製品について警告するインサイトダッシュボード画面を示しています。 このダッシュボードは、ウォッチリストに追加したユーザーとも共有されます。 ダッシュボードには、赤いボックスで特定の製品に対する基準違反が警告表示されます。 たとえば、次のスクリーンショットのダッシュボードには、 Deluxe Styler のリードタイムが Dallas DC で逸脱していることが示されています。 次に、Deviation (偏差) ボックスを選択すると、偏差の詳細を示す次の画面が表示されます。 画面には、ユーザ設定の初期の情報に基づいて期待するリードタイムが表示され、それに対する推奨リードタイムが表示されます。推奨リードタイムは、機械学習を使用して計算され、過去の実績に基づいて行われます。 ML は、過去の実績と予想されるパフォーマンスをモデル化し、予測値、あるいは設定値の 5 日間の目標ではなく、19 日間の予想リードタイムを推奨しています。 また、このアプリケーションでは、過去の実績データに基づいて、この場所での Miss Frequently (目標逸脱の頻度) が 100% であることも報告されます。 インサイトでは、進行中の注文の期待される ( expected ) 納期を確認することもできます。 次のスクリーンショットは、未処理の発注書と、サプライヤー、製品、数量の一覧を示しています。 画面には、調整後のリードタイムに基づく受領予定日と、信頼度が低い日付と信頼度の高い日付が表示されます。 これらの日付では、過去のパフォーマンスに基づく統計的モデリングが考慮され、納品可能な日付の範囲がわかります。 これにより、実際のパフォーマンスに基づいた総合的なビューが得られるため、供給計画を調整できます。 他のチームメンバーとのコラボレーション コラボレーションはサプライチェーンにとって不可欠な機能です。 前のセクションで説明した供給計画の変更には、他のチームとの調整とコラボレーションが必要です。 従来、供給計画の調整に関する連絡は、電子メールまたは電話で行われていました。 この方法は有効ですが、解決に遅延が生じたり、会話中に同じ情報を共有していないことで問題が生じる可能性があります。 AWS Supply Chain にはコラボレーションツールが組み込まれているため、チームメンバーはアプリケーションを離れることなくチャットして問題について話し合い、解決できます。 ユーザーは同じ画面で同じ情報をチャット画面に表示できるため、コミュニケーションと解決をより迅速に行うことができます。 結論 現代の市場は活発に変動する性質を持っており、顧客はそれに対応して、供給計画戦略の進化が求められています。 静的データと平均リードタイムに依存する従来の方法では、誤差、過剰在庫、在庫不足、および不要な経費が発生する可能性があります。 供給計画に機械学習を導入すると、計画の精度が向上し、需要と供給のばらつきが減少します。 ML はサプライヤーのリードタイムの異常を検出して計画を修正し、効果的なリスク軽減措置を実施します。 異常の検知や、長期利用に対する適応もリアルタイムで行われているため、最適化された、効率的で機敏なサプライチェーンが継続的に維持されます。 サプライチェーンの可視性が継続的かつ向上することで、ボトルネックや潜在的な混乱を特定できるようになり、また、意思決定を迅速化することで、業務に影響を与えることなく潜在的な問題軽減を迅速に行うことができます。 これらの改善により、顧客の需要に効果的に対応し、市場や環境の変化に適応し、運用コストを削減できるようになるため、サプライチェーンのレジリエンスが向上します。 ML ベースのリードタイム偏差に関するインサイトを利用するには、 AWS Supply Chain &nbsp; にアクセスして詳細を確認してから始めましょう。 また、&nbsp; AWS Workshop Studio にアクセスして、ご自分のペースでインスタンスの作成、データの取り込み、ユーザーインターフェイスの操作、インサイトの作成、在庫リスクの軽減、他のユーザーとのコラボレーション、需要計画の生成についての概要をご確認ください。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Vikram Balasubramanian は、サプライチェーンのシニア・ソリューション・アーキテクトです。Vikram は、サプライチェーンの経営幹部と緊密に連携して、彼らの目標や問題点を理解し、解決策の観点からベストプラクティスと連携させています。Vikram は17年以上にわたり、サプライチェーン分野のさまざまな業種のフォーチュン500企業で働いてきました。Vikram は、パデュー大学でインダストリアルエンジニアリングの修士号を取得しています。ヴィクラムはノースダラス地域を拠点としています。 <!-- '"` -->

資材のインバウンドサプライチェーンの目的は、予備部品、補修可能部品、消耗品を予定されたメンテナンス作業に間に合うように工場に届けることです。 しかし、パフォーマンスの低さ、チーム間の信頼の欠如、資材調達における可視性の低さなどが原因で、頻繁に再計画が行われ、メンテナンス作業を確実に実行するために必要以上に慌ただしくなります。 主要な鉱業およびエネルギー企業は、クラウドコンピューティング技術を活用して以下のようにビジネス成果の向上とリスクの軽減を図るケースが増えています。 作業開始日より前に資材が確実に届くようにすることで、設備のダウンタイムを削減します。ビジネス機会の規模は、運用設備1件あたり年間 $3 ～ 6M と推定されています。 メンテナンス実施チームが作業の移動や資材を探す時間を減らし、より多くの時間をメンテナンス作業に費やすことで、メンテナンスの生産性が向上します。 ビジネス機会の規模は、生産性が 5 〜 8% 向上することです。 資材の状態が可視化され、ベースとなるデータへの信頼性が確保されれば、余剰在庫が少なくなります。ビジネス機会の規模としては、在庫レベルを 1 〜 5% 削減し、速達便と航空貨物の出荷を 2 〜 5% 減らすことです。 エンジニアが直接かつガイド付きで購入できるようにすることで、調達の間接コストを削減します。 これにより、調達プロセスが合理化され、調達の役割が取引からコンサルティング業務へとレベルアップします。 目下のビジネス機会は、調達支出を最大 5% 削減することです。 このブログでは、特に鉱業およびエネルギー業界向けの保守の注文を監視・管制するコントロールタワーのユースケースと、関連するビジネス成果を紹介します。 クラウド技術を活用した保守の注文を監視・管制するコントロールタワー 私たちのビジョンは、各利害関係者が資材の流れを維持するために主要なアクションを完全に可視化し、彼らの決定がビジネス総コストに与える影響を理解できるようにする保守の注文（ MO ）の監視・管制するコントロールタワーを実現することです。 特定の日に MO をスケジュールまたは再スケジュールすることが、資材の入手可能性、メンテナンスの生産性、移動、宿泊施設の利用率にどのような影響を与えるかを透明化できます。 このビジョンに向かって進むには、企業はメンテナンス計画の段階とMOの計画段階の両方でデジタル機能と機械学習 ( ML ) 機能を構築する必要があります。 メンテナンス計画の時点での考慮事項 データドリブンな機械学習を活用した需要予測とシミュレーションによる将来の需要の可視化 メンテナンス計画の時点で、チームは一般に、大まかな作業と実行日を計画してスケジュールを立てるときに、必要な資材が現場にあることが確実ではありません。 その結果、頻繁な再計画とそれに伴う移動作業の両立、資材の発送依頼、メンテナンス作業のための人員の調整、資材が確実に利用できるようにするための安全在庫レベルの設定といったやりくりが必要になります。 サプライヤーは、将来の資材需要がどうなるかを把握できていません。 将来の需要の可視化は、生産計画に役立ち、購入者との関係を改善することにもつながります。 メンテナンス作業の再計画を減らす、つまり、期日通りに実行されるメンテナンスの注文を増やす 、そしてバランスの取れた在庫管理を実現するために、大手企業はクラウドベースのテクノロジーを資材需要予測、安全在庫分析、および What-if シナリオに適用しています。 Amazon SageMaker を用いた機械学習( ML )により、以下の要素を組み合わせて資材需要計画プロセスをサポートします。 今後の活動における資材需要予測のための過去の資材消費量 エンタープライズリソースプランニング（ ERP ）ソフトウェアシステムにおける機器向けの資材の消費ベースのデータ、また機器の設置台数ベースのデータ 後者では、分析を行って機器と資材の故障率（平均故障間隔）を計算できます。 これにより、メンテナンスプランナーは、メンテナンス作業、資材需要、および過去の資材消費量の可視性を自動的に予測できます。 また、将来の MO に関連する作業リストや部品表を簡単に確認できるようになります。 AWS はパートナーの Deloitte とともにあるエネルギー企業を支援し、データ品質 (資材マスターデータや作業リスト BOM など) に制約があったにもかかわらず、全資材の 25% の需要予測をうまく自動化できました。 さらなる取り組みの強化により、データ品質の問題にデータ拡張技術で対処すれば、全資材の約 50% までカバー範囲が拡大する可能性があります。 これにより、メンテナンス計画作業の半自動化が可能になります。 さらに、資材需要予測に基づいて、安全在庫レベルは静的ではなく動的に計算されます。 この計算では、希望するサービスレベル、資材の重要度、手持ち在庫、納期、資材のリードタイムが考慮されます。 資材管理者は、積極的に在庫を管理して全体的な在庫レベルを下げることができるため、安全在庫レベルの動的な計算によるメリットがあります。 最後に、What-if シミュレーション（たとえば、開始日を1か月変更するなど）により、生産の可用性、コスト、MO のスケジュール変更に伴う安全性への影響を可視化し、さらにはメンテナンス活動全体を経時的に把握できます。 これにより、メンテナンスのスケジューラーとプランナーは、特定の日に MO をスケジュールするときに、必要な資材のオンサイト在庫状況への影響をすばやく確認できます。 さらに大きく考えてみましょう。 このビューは資材だけに限定されるべきではありません。 人件費、移動、宿泊施設の利用状況、そして最も重要なことですが、保守対象の設備の稼働時間に関する潜在的なリスクなどの関連情報を使用して、ビジネス全体でのコストを検討しましょう。 ビジネスの全体像を把握するために、企業は強固な基盤となるデータプラットフォームと、 Amazon S3 を搭載した Lake House Architecture などの構造を通じて提供される強固なデータ構造が必要です。これにより、関連する財務、運用、資材の情報をすべて保存して迅速に取得できます。 資材入手と計画精度向上のための、現実的なベンダーリードタイムと輸送リードタイム 資材が現場に到着するまでにかかる時間についての情報が不十分なため、メンテナンスプランナーは MO の開始日を自信を持ってスケジュールできないことがよくあります。 直接購入の場合、ベンダーのリードタイムはエンドツーエンドのリードタイム全体の 60% 以上を占めることがよくあります。 また、アウトライン契約（他の業界のフレーム契約と同様）が締結されていなかったり、最近更新されていなかったりすると、メンテナンスプランナーは信頼できる情報を得ることができません。 SageMaker を用いた機械学習( ML )は、過去の PO ( Purchase Order ) 情報を分析して実際のベンダーリードタイムを予測します。 設備や機器の標準化があまり行われていないため、資材購入は一回限りのものであることが多く、過去のデータが不十分な場合は常に、同様の資材を使用して、 XGBoost などの監視付き ML アルゴリズムを資材レベルまたは資材グループおよびベンダーレベルで実行する必要があります。 これらのモデルでは、決定係数が 0.7 を超えると強い相関関係であることが証明されています。 重要な課題は、モデルが予測する信頼水準 ( 95% の確率水準など) を定義することです。 実際には、これは予測到着日が、必要なオンサイト日付より大幅に前にならないように予測アルゴリズムがトレーニングされていることを意味し、その結果、大量のバッファーが使用され、MO 計画が非現実的になります。 これとは対照的に、モデルで予測されるリードタイムが短すぎると、メンテナンスプランナーは信頼を失い、MO のタイムリーな実行がリスクにさらされます。 以下のグラフは、予定納期、ベンダー名、インコタームズ（貿易取引条件）、PO 作成月など、ベンダーのリードタイム予測に影響する要因の例を示しています。 このチャートは、特定のベンダーに関する高水準または低水準の予測因子、つまりどの要因が資材の到着を遅らせる可能性があるかをユーザーに提供します。 さらに、過去のベンダーの実績と契約上の義務を比較することで、ユーザーはそれに応じてベンダーの実績を管理しやすくなります。 インコタームズ(貿易取引条件)が買い手に輸送の手配を要求する場合（工場出荷時など）には、輸送、特に国際海上貨物輸送のリードタイムを予測する2番目の ML モデルを構築する必要があります。 船舶到着時刻の予測に機械学習を使用すると 、業界で広く使用されている従来の手動見積もり方法と比較して、陸上業務の計画と実施の精度が大幅に向上します。 メンテナンスの注文が計画されている場合 購入した資材の可視性 鉱業・エネルギー企業が資材のサプライチェーンを運営する際の共通の課題は、メンテナンスの利害関係者が注文承認から現場での入手までの進捗状況に関して、資材の可視性が限られていることです。 これは特にベンダーからの直接購入に当てはまり、在庫からの供給にもある程度は当てはまります。 調達チームとロジスティクスチームは、どの資材がクリティカルパスにあるのか、あるいはすでに遅延しているのかを把握することがほとんどできません。 また、どの作業を優先すべきかについてのガイダンスも不足しています。 このような可視性の欠如は、重要な資材が必要なときに現場にない場合や、予定日に間に合うように届くかどうか確信が持てない場合に、メンテナンス作業をリスクにさらします。 資材のコントロールタワーは、必要な資材がプロセス全体にわたってどのように進んでいるかを可視化します。 MO の承認からオンサイトでの納品まで、進捗状況を追跡するための一連のマイルストーンが定義されています。 この可視性により、メンテナンスの実行、調達、物流などのユーザーは、計画された実行日より前に資材が届くという貴重な洞察と確信を得ることができます。 さらに、可視性は、資材の流れと資材サプライチェーンにおける信頼を確保するために必要なアクションの優先順位付けと調整に役立ちます。 たとえば、調達チームは月に何千件もの購買依頼を処理しているのに、どの資材要求や関連アクションが最も重要か、どの資材が重要なのか、どの資材が重要なのか、どの資材が重要なのか、あるいはすでに遅延しているのかを理解していないことがよくあります。 優先順位付けエンジンは、ユーザーにいくつかの重要な作業を指示し、資材や注文の重要度、アクションやエスカレーションなどのサプライチェーンのさまざまな参加者が制御できるコンテキスト情報を提供します。 資材調達の進行が妨げられたり、状況の可視性が悪かったりすると、要求の所有者にとって資材の状況や解決の責任者が不明瞭になることがあります。 たとえば、ベンダーが品目を製造・納品できなくなった場合、資材が旧型のものになる可能性があります。 こうした障害は、発注と配送のプロセスの複数の段階で発生し、例えば PR ( Purchase Requisition )時や見積依頼（ RFQ ）の作成時に検知しうるものです。ソリューションが提供する推奨事項は、これに基づいて非常に状況に応じたものでなければなりません。 資材のコントロールタワーは、こうした障害を検知するコグニティブ機能を備えているだけでなく、類似のサプライヤーを見つけたり、クラスタリング技術を使って代替可能な資材を特定したりするなど、重要な推奨事項を提示するコグニティブ機能を備えています。 資材のコントロールタワーは資材の流れに焦点を当てており、計画と実行の両方のプロセスにまたがる MO 実行を監視・管制するコントロールタワーという私たちのビジョンの重要な構成要素です。 MO 実行を監視・管制するコントロールタワーには、資材だけでなく、メンテナンス実行チームや、メンテナンス作業の実行に必要なその他の活動（航空機やキャンプの運用など）も含まれています。 業界をリードする AWS のお客様の中には、AWS のサービスである AWS Supply Chain を活用して、次の 4 つのコア機能に沿った資材の追跡と推奨事項の提供を検討しているところもあります。 システムをまたぐデータの容易な接続 : 関連するメンテナンス計画、調達、ロジスティクスのデータはサイロ化していることが多く、関連するチームやユーザーは、エンドツーエンドのサプライチェーン全体にわたる資材の状態に関する使いやすいビューを作成するのに苦労しています。 AWS Supply Chain は、このようなサイロ化されたデータへのアクセスを支援し、事前にトレーニングされた自然言語処理 ( NLP ) モデルである ML アルゴリズムを使用して、既存のデータをターゲットデータモデルに変換します。 ML を活用した洞察 : 次に、AWS Supply Chain はデータを地図上に関連付けて表示し、各倉庫とサイトにおける資材の進捗状況、現在の在庫選択と数量、在庫の状態を強調表示します。 ML を使用した資材到着時間の予測 : この ML モデルは、残りのすべてのマイルストーンにリードタイムを追加し、障害解決時間を考慮して現場での現実的な到着日を見積もることで拡張できます。 在庫についての推奨事項提供とコラボレーションの支援機能 : ユーザーは、推奨アクションや緊急の在庫問題に関するインサイトを自動的に得ることができます。 監視リストを設定して、潜在的なサプライチェーンのリスクがある場合にアラートを受け取ることができます。 また、コラボレーション機能も備えているため、ユーザーは互いに通信したり、システム内の関連情報を追跡したりできます。 コグニティブ調達により、ビジネスユーザーに迅速でデータドリブンで Amazon ライクな購入体験を提供 資材サプライチェーンの最適化において調達が重要な役割を果たす理由は2つあります。 第一に、鉱業会社やエネルギー会社の調達支出は数十億ドルに上る傾向があり、支出削減は会社の収益に直接つながります。 第二に、PR からベンダー側での PO 承認までの平均時間は、数週間ではないにしても、数日かかることがよくあります。 これは特に、時間のかかる承認プロセスが原因で、購入履歴の処理時間のばらつきが限られている品目に当てはまります。そのため、調達プロセスにかかる時間を自信を持って把握することが複雑になります。 調達変革の中核には、保守エンジニアなどのビジネスユーザーがベンダーから直接品目を購入できるようにすることで、調達チームを取引的で事後対応型の役割からコンサルティング型の役割に変えたいという強い要望があります。 こうした要望により コグニティブ調達エンジン ( COPE ) というオファリングが支持されており、COPE は次のような機能を提供しています。 設定された上限金額を下回る補修部品発注のセルフサービスを提供します。 資材の Amazon のような購入体験により、適切な製品をより迅速、簡単、効率的に調達するためのエンドツーエンドのプロセスを実現します。 製品、価格、サプライヤー、過去の支出、個人ユーザーエクスペリエンスに関する比較分析用のデータ。これにより、パンチアウト（企業購買システム内でのベンダー提供カタログによる購買)が強化され、補完されます。 推奨事項、購入パターン、代替製品、および機器のタイプ、役割、購入履歴に基づいた焦点を絞ったオプションセットにより、ビジネスユーザーのニーズにより的確に対応できます。 購買支出の完全な可視化による調達チームの継続的な管理と、必要に応じて例外発生時のエスカレーションプロセスを設ける。 あるエンジニアが COPE Web ポータルにログインすると、入力された検索語に対する製品の選択肢がいくつか表示されます。 購入画面には、商品がフィットする理由とそうでない理由が表示されます。 O リングの例では、アイテム1と2は使用目的に非常に適しています。 それでも購入者がアイテム3が適していると見なす場合は、最も安いこの製品を選択できます。 こうした場合でも、適切なプロセスに適した機器を用意することで、安全性と設備寿命が向上し、メンテナンスコストが削減されます。 COPE による Amazon のような購買体験は、今日の購買慣行を一新し、時間とリソースを消費する調達プロセスの大部分を自動化し、調達支出を 5〜8% 削減する機会を提供します。 特にガスケットなどの価値の低い品目の場合、組織は PR から納品までの時間を短縮し、ロングテール品目の調達にかかる人件費を、1取引あたり $200 —300 から $5 —25 に削減できます。 一括注文と調達プロセスの改善のための Amazon Business Chevron や Exxon Mobile などのいくつかの企業は、 Amazon Business を活用しさらに一歩進んでいます。 Amazon Business は、Amazon のユーザーフレンドリーなショッピング体験をベースに、マルチユーザービジネスアカウントにより、特定の権限を持つ購買グループの作成、ガイド付き購入、高度な検索機能といった強力な支出の可視化と分析を可能にする現代の調達に不可欠な機能と組み合わせて活用しています。 たとえば、Chevron は幅広い資材を調達しており、その多くは Chevron に代わってビジネスパートナーが管理していました。 マネージャーは月次の出荷日に向けて購買リストを作成していました。 リストの作成、見積もりの取得、見積もりの承認、注文、配送の受け付けには4〜6週間かかります。 メンテナンスチームなどの社内顧客は、必要なものを正確に手に入れるためのコントロールが限られていたため、多くの拠点が失望していました。 Chevron は、購買を Amazon Business に移行しました。これは、支出を集約し、ダイナミックな店舗環境で誰もが必要な商品を見つけることができ、なおかつ大量注文のメリットを享受できます。 Amazon Business は Chevron の SMART GEP システムである Punchout と統合され、シームレスなユーザーエクスペリエンスを実現しました。 各ユーザーが個別に実施した注文は、経費マスターの報告用に自動的に1つの購入カードにまとめられ、注文は週1回の配送（ Amazon Day ）にまとめられます。 資材カテゴリーが過去の取引に合わせて細分化されていたなど課題もあったものの、柔軟な支払い条件で発注するなどして、サプライヤーを集約しました。 結論 このブログでは、鉱業およびエネルギー企業がクラウドコンピューティング技術を使用して資材サプライチェーンを最適化するビジネス機会について説明しました。 ビジネス機会は、メンテナンス計画プロセス中と資材需要が確認されたときの両方に存在します。 メンテナンス計画と実行の安定性が向上すると、メンテナンス実施チームの生産性が 5～ 8% 向上し、費用のかかる速達便や航空貨物の輸送が 2 ～ 5% 削減され、設備ダウンタイムのリスクが軽減され、運用設備あたり年間 $3 ～ 6M になる可能性があります。 AWS では、エンドツーエンドのサプライチェーン全体で資材の状態を可視化し、必要な期日より前に資材が現場に届くという確度を高め、間接調達支出を最大 5% 削減し、サプライチェーンのパフォーマンスとコミットメントに対する信頼を高めるのに役立つサービスをいくつか提供しています。 資材サプライチェーン管理に関するあなたのアプローチを学び、議論したいと思っているので、コメントにあなたの意見を残してください。 複雑なサプライチェーンの課題解決に AWS がどのように役立つかを知りたい場合は、担当の AWS アカウントマネージャーに連絡して、鉱業、エネルギー、工業 ( MEI ) 業務の業界専門家や、サプライチェーンや物流の専門家によるディスカバリーワークショップを開催してください。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Manuel Baeuml 博士は、アジア太平洋地域と日本の AWS ProServe サプライチェーンとロジスティクスの責任者です。Manuel と彼のチームは、主要なデジタルサプライチェーンの実践を共有し、AWS のクラウドテクノロジーとサービスを活用してお客様の喫緊のサプライチェーンの問題を解決する役割を持っています。過去 15 年間、彼は鉱業、エネルギー、小売/CPG、輸送、物流の分野で、アジア太平洋地域と ヨーロッパの業界リーダーと仕事をする機会に恵まれてきました。Manuel はシンガポールを拠点としています。 Ben van Vlietは、オーストラリアとニュージーランドの鉱業、エネルギー、産業分野の顧客を担当するシニア・カスタマー・デリバリー・アーキテクトです。Ben の仕事は、AWS ProServe のお客様がデジタル戦略と運用戦略を定義できるよう支援することから、サプライチェーン、産業用 IoT、グリーンフィールド製品開発における戦略的イニシアチブの策定と実施まで多岐にわたります。Ben は鉱業、 石油、ガスの分野で深い経歴を持ち、アウトバウンドのサプライチェーンの計画、メンテナンスの有効性、デジタルイノベーションの分野で実務担当やリーダーの役割を果たしてきました。Ben はオーストラリアのパースを拠点としています。 Brett Birkbeckは、オーストラリアとニュージーランドの鉱業、エネルギー、産業向けのソリューションアーキテクチャの責任者です。Brett は、お客様が AWS クラウドによる変革を実現できるよう支援する AWS プロフェッショナルチームを率いています。Brett は鉱業とエネルギーの分野で豊富な経験を持ち、デジタル戦略、テクノロジー主導の近代化、インダストリアル IoT、AI/ML、デジタルツインに関するアドバイスを提供しています。ブレットはオーストラリアのパースを拠点としています。 <!-- '"` -->

このブログは 2023 年 2 月 8 日に Luca Mezzalira (Principal Solutions Architect)、Federica Ciuffo (Sr. Containers Solutions Architect)、Laura Hyatt (Solutions Architect)、Vittorio Denti (Machine Learning Engineer)、Zamira Jaupaj (Enterprise Solutions Architect) によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 持続可能性 は、テクノロジー業界だけでなく社会全体にとっても重要なトピックであり、天然資源や環境を枯渇させることなく、長期間にわたってプロセスや機能を果たし続ける能力と定義されています。 持続可能なワークロードを設計するための重要な要素の 1 つは、ソフトウェアアーキテクチャです。イベント駆動型アーキテクチャがバッチ処理やキューなどのソリューションを活用して複数のマイクロサービスの負荷を軽減するのにどのように役立つかを考えてみてください。このような場合、多くのネットワークトラフィックはクラウドワークロードの入り口で処理され、システム内部への負荷の緩和に役立ちます。アーキテクチャに加えてデータパターン、ハードウェア最適化、マルチ環境戦略など、クラウドにおける持続可能な姿勢を促進するソフトウェア開発ライフサイクルの多くの側面について考えてみましょう。 重要なポイントは、持続可能性を念頭に置いて設計することで、耐久性があるだけでなく、ビジネスに必要な俊敏性を維持できる柔軟性を備えたアプリケーションを構築できるということです。 今回の投稿では、クラウドアプリケーションをより持続可能にするためのハンズオンアクティビティ、ケーススタディ、ヒントやコツを紹介します。 持続可能な設計と AWS の二酸化炭素排出量の削減 アマゾンウェブサービス (AWS) は、組織による AWS サービスの利用の評価と最適化を支援するために AWS Well-Architected Framework の 持続可能性の柱 を立ち上げ、組織が AWS フットプリントを監視、分析、削減できるように Customer Carbon Footprint Tool を構築しました。 このセッションでは、これらのプログラムの最新情報を提供し、AWS アーキテクチャを最適化するための最も効果的な手法に焦点を当てます。Amazon Prime Video がこれらのツールをどのように使用してベースラインを確立し、AWS 利用全体の効率を大幅に向上させたかをご覧ください。 この re:Invent 2022 の動画はこちら! 持続可能性を考慮してアーキテクチャを設計する方法を理解するための Prime Video のケーススタディ 持続可能性を実現するために最新のデータアーキテクチャを最適化 モダンなデータアーキテクチャは、ビジネスインテリジェンスを可能にする持続可能でスケーラブルなプラットフォームの基盤です。この AWS Architecture Blog シリーズでは、持続可能性を念頭に置いてモダンなデータアーキテクチャを開発する方法についてのヒントを紹介しています。 2 つの記事で構成されていて持続可能性を損なうことなく、現在のデータアーキテクチャを再検討して強化するのに役立ちます。 Part 1 はこちら! | Part 2 はこちら! AWS データ・アーキテクチャ：持続可能性を考慮する時です AWS Well-Architected Labs: Sustainability このワークショップでは、AWS Well-Architected Framework を参加者に紹介します。AWS Well-Architected Framework は、パフォーマンス、拡張性、コスト効率のよいアプリケーションを AWS 上で設計および運用するための一連のベストプラクティスです。ワークショップでは、ソフトウェアアーキテクチャにとって持続可能性がいかに重要であるか、また AWS Well-Architected Framework を使用してアプリケーションの持続可能性パフォーマンスを向上させる方法についても説明します。 ワークショップはこちら! 持続可能性導入のベストプラクティスとモニタリング Rust と AWS Graviton によるクラウド内の持続可能性 この動画では、 Rust と AWS Graviton がエネルギー消費量の削減とパフォーマンスの向上にもたらすメリットについて学ぶことができます。Rust は C などのプログラミング言語のリソース効率と Java などの言語のメモリ安全性を兼ね備えています。また、この動画では、パフォーマンスとコストが最適化されたクラウドワークロードを提供するように設計された AWS Graviton プロセッサから得られる利点についても説明しています。このリソースは、持続可能性がどのようにコスト最適化の原動力になり得るのかを理解するのに非常に役立ちます。 re:Invent 2022 動画はこちら！ Rust と AWS Graviton がワークロードの持続可能性とパフォーマンスを向上させるのにどのように役立つかをご覧ください また次回お会いしましょう！ クラウド内の持続可能性についてのディスカッションにご参加いただきありがとうございます。2 週間後にアーキテクト向けのツールについてお話ししますので、またお会いしましょう。 このシリーズのすべてのブログを検索するには、AWS Architecture Blog の Let’s Architect! のコンテンツのリストをチェックしてください。 翻訳はネットアップ合同会社の Yotaro,Iwai 氏、監修はソリューションアーキテクトの沢田 吉伯が担当しました。 TAGS: case study , data architecture , Let’s Architect , re:Invent , software , Sustainability , workshop Luca Mezzalira Luca Mezzalira はロンドンを拠点とするプリンシパル・ソリューション・アーキテクトです。複数の著書を持ち、国際的な講演者でもある彼は、主にソリューション・アーキテクトの分野で専門知識を発揮しています。ルカは、マイクロフロントエンドを使ったフロントエンドアーキテクチャのスケーラビリティに革命をもたらし、ワークフローの効率化から製品の品質向上に至るまで高い評価を得ています。 Federica Ciuffo Federica Ciuffo は、AWS のシニア コンテナ ソリューション アーキテクトです。彼女はネットワークとコンテナに情熱を持っています。オフィスの外では、読書や絵を描いたり、友人たちと時間を過ごしたり、レストランでさまざまな料理の新しい料理を試したりすることを楽しんでいます。 Laura Hyatt Laura Hyatt は、AWS 公共部門のソリューションアーキテクトであり、英国の教育機関の顧客を支援しています。 Laura は、お客様がスケーラブルなソリューションを設計および開発するだけでなく、現在教育セクターが直面している問題に対して、革新的なソリューションを考える一役を担っています。 Laura の専門は IoT で、EMEA 全体の教育向け Alexa SME も務めています。 Vittorio Denti Vittorio Denti は、ロンドンを拠点とする Amazon の機械学習エンジニアです。ミラノ工科大学 (ミラノ) と KTH 王立工科大学 (ストックホルム) でコンピューターサイエンスとエンジニアリングの修士号を取得後、AWS に入社しました。 Vittorio は分散システムと機械学習のバックグラウンドを持っています。彼は特にソフトウェア エンジニアリングと機械学習科学の最新のイノベーションに情熱を注いでいます。 Zamira Jaupaj Zamira Jaupaj は、オランダを拠点とするエンタープライズ ソリューション アーキテクトです。彼女は非常に情熱的な IT プロフェッショナルであり、中小企業向けのコンテナ、サーバーレス、データ分析を使用した重要で複雑なソリューションの設計と実装において様々な国で 10 年以上の経験を持っています。

この記事は Announcing additional Linux controls for Amazon ECS tasks on AWS Fargate (記事公開日 : 2023 年 8 月 9 日) の翻訳です。 導入 Amazon Elastic Container Service ( Amazon ECS ) タスクは、同時かつ同一の AWS Fargate インスタンス または Amazon EC2 コンテナインスタンス にスケジューリングされる、1 つ以上のコンテナで構成されます。コンテナでは Linux namespace を使用してワークロードの分離を実現するため、Amazon ECS タスク内で複数のコンテナが一緒にスケジューリングされた場合にも、コンテナ同士、あるいはコンテナとホスト間は分離されます。 本日より、AWS Fargate 上の ECS タスクで Linux カーネルパラメータを調整できるようになりました。Linux カーネルパラメータを調整することで、コンテナ化されたネットワークプロキシの ネットワークスループットを最適化 したり、不要な接続を適切に終了するように TCP キープアライブパラメータを調整 し、ワークロードの信頼性を向上させることが可能になります。今回の発表により、AWS Fargate を使用する際にも、Amazon EC2 を使用する場合とより近い形で ECS タスクを実行できるようになりました。 さらに、本日より AWS Fargate 上の ECS タスク内のすべてのコンテナ間で、プロセス ID (PID) namespace を共有できるようになりました。ECS タスク内のコンテナ間で PID namespace を共有することで、AWS Fargate ワークロードの可観測性を実現する手段が広がります。例えば、コンテナランタイムセキュリティツールなどの可観測性ツールをサイドカーコンテナとして実行し、同じ ECS タスク内のコンテナのプロセスを監視することが容易になります。 awsvpc ネットワークモード を使用した場合の Network namespace に加えて、PID namespace も、AWS Fargate 上の ECS タスク内のコンテナ間で共有可能な namespace の一員となりました。 この記事では、AWS Fargate の System Controls と PID namespace の共有について深堀りしていきます。 System controls Linux システムでは、コマンドラインユーティリティ sysctl でカーネルパラメータを調整できます。 Docker や finch などのコマンドラインインターフェースを使用してコンテナをローカルで起動する場合、 --sysctl フラグを指定することでカーネルパラメータを変更できます。ECS タスクの場合、 タスク定義 の systemControl キーでパラメータを定義できます。 コンテナ化されたネットワークプロキシを AWS Fargate 上で実行しているお客様からは、ワークロードにおいてより高いスループットを実現するために net.* カーネルパラメータを調整する必要がある、という 声 を頂いていました。特に要望が多かったカーネルパラメータには、接続要求を格納するキューの深さ net.core.somaxconn や、TCP/UDP 接続時に使用する一時的なエフェメラルポートの範囲 net.ipv4.ip_local_port_range などがあります。 信頼性の高いワークロードを設計する際に、AWS Fargate 上の ECS タスクの TCP キープアライブパラメータをカスタマイズしたい、という声も頂いていました。短い TCP キープアライブタイムアウトを設定することで、アプリケーションはネットワーク障害を迅速に検知し、失敗した接続を閉じることができます。TCP キープアライブを調整するユースケースの例としては、コンテナワークロードが Amazon Aurora PostgreSQL クラスター と通信している場合や、Amazon VPC NAT Gateway の トラブルシューティング を行う場合などが考えられます。 以前は、EC2 上で ECS タスクを実行する場合にのみ systemControl キーを設定可能でしたが、本日より AWS Fargate 上の ECS タスクにおいても、同様に設定可能となります。2 つのカーネルパラメータを調整する Amazon ECS タスク定義の例を以下に示します。 { ... "containerDefinitions": [ { "name": "myproxy", "image": "111222333444.dkr.ecr.eu-west-1.amazonaws.com/myproxy:latest", "essential": true, "systemControls": [ { "namespace": "net.core.somaxconn", "value": "6000" }, { "namespace": "net.ipv4.ip_local_port_range", "value": "1024 65000" } ] } ] } AWS Fargate / Amazon EC2 上の ECS タスクで設定可能なすべてのパラメータは、 Amazon ECS ドキュメント で確認できます。 IPC namespace のカーネルパラメータを使用する場合、IPC namespace はタスク内のコンテナ間で共有されないため、各コンテナに固有の値を設定できます。一方、Network namespace のカーネルパラメータを使用する場合、1 つのコンテナにパラメータを設定すると、タスク内のすべてのコンテナのパラメータが変更されます。具体的には、以下のように設定が適用されます。 コンテナ 1 に net.ipv4.tcp_keepalive_time=100 を設定した場合、この変更はコンテナ 2 にも反映されます。 コンテナ 1 に net.ipv4.tcp_keepalive_time=100 を、コンテナ 2 に net.ipv4.tcp_keepalive_time=200 を設定した場合、タスク内で最後に起動するコンテナのパラメータのみが適用されます。 PID namespace の共有 PID namespace は、コンテナ内のプロセスが参照可能なプロセスを制限します。デフォルトでは、コンテナ内のプロセスは同じコンテナ内のプロセスのみを参照でき、他のコンテナ内、または実行基盤となるホスト上のプロセスは参照できません。コンテナ間で PID namespace を共有する一般的なユースケースとして、可観測性ツールがあります。コンテナランタイムセキュリティツールは、多くの場合サイドカーコンテナで実行されます。このとき、サイドカーコンテナ内のプロセスがアプリケーションコンテナ内のプロセスを監視し、不審なシステムコールが実行されていないかどうかを確認します。 今回の発表により、タスク定義内の pidMode キーの値を task に設定することで、AWS Fargate においても ECS タスク内のコンテナ間で PID namespace を共有できるようになりました。 ウォークスルー このウォークスルーでは、まず PID namespace を共有した ECS タスクを作成します。このタスクには、アプリケーションコンテナ (nginx) とサイドカーコンテナ (デモ用の sleep プロセス) の 2 つのコンテナが含まれています。その後、サイドカーコンテナ内のプロセスが、アプリケーションコンテナ内のプロセスとどのようにやり取りできるかを確認します。 前提条件 このウォークスルーでは、Amazon VPC 内に作成した Amazon ECS クラスターを使用します。自身の AWS アカウントで新たに作成する場合は、 Amazon ECS getting started guide を参照してください。 AWS アカウントとコマンド実行環境の両方において、 ECS exec の前提条件 を満たしていることを確認してください。 AWS Fargate 上で ECS タスクを実行する 1. pidMode を有効化した、2 つのコンテナを含むタスク定義を作成します。以下の例では、タスク定義内の IAM ロール ( executionRoleArn と taskRoleArn ) を、前提条件で作成した IAM ロールに置き換えてください。 $ cat &lt;&lt;EOF &gt; taskdef.json { "family": "fargatepidsharing", "executionRoleArn": "arn:aws:iam::111222333444:role/ecsTaskExecutionRole", "taskRoleArn": "arn:aws:iam::111222333444:role/ecsTaskExecRole", "networkMode": "awsvpc", "requiresCompatibilities": [ "FARGATE" ], "containerDefinitions": [ { "name": "nginx", "image": "public.ecr.aws/nginx/nginx:1.25-perl", "essential": true }, { "name": "sleeper", "image": "public.ecr.aws/amazonlinux/amazonlinux:2", "essential": true, "command": [ "sleep", "infinity" ], "linuxParameters": { "initProcessEnabled": true } } ], "cpu": "256", "memory": "512", "pidMode": "task" } EOF 2. aws ecs register-task-definition コマンドを実行し、タスク定義を登録します。 $ aws ecs register-task-definition \ --cli-input-json file://taskdef.json 3. aws ecs run-task コマンドを実行し、AWS Fargate 上で ECS タスクを実行します。以下の例では、ECS クラスター名、VPC サブネット、セキュリティグループの値を置き換える必要があります。外部からこのタスクにアクセスする必要はないので、プライベートサブネットと、イングレスルールを持たないセキュリティグループ (デフォルトのセキュリティグループなど) で十分です。 $ aws ecs \ run-task \ --count 1 \ --launch-type FARGATE \ --task-definition fargatepidsharing \ --cluster mycluster \ --enable-execute-command \ --network-configuration "awsvpcConfiguration={subnets=[subnet-07bd4d10ea848a008],securityGroups=[sg-061b33f4ed6b97c34],assignPublicIp=DISABLED}" 4. ECS タスクが正常に起動したら、 aws ecs execute-command コマンドを実行して、ECS タスク内のサイドカーコンテナでターミナルセッションを開始します。このコマンド実行時にエラーが発生する場合は、 amazon-ecs-exec-checker スクリプトを使用して、すべての前提条件を満たしていることを確認してください。 # ECS タスク ID を取得する $ aws ecs list-tasks \ --cluster mycluster { "taskArns": [ "arn:aws:ecs:us-west-2:111222333444:task/moira-prod/5ce56f226dd4477a9f57918a98fc852f" ] } # 実行中の ECS タスクで bash シェルを起動する $ aws ecs execute-command \ --cluster mycluster \ --task 5ce56f226dd4477a9f57918a98fc852f \ --container sleeper \ --interactive \ --command "/bin/bash" 5. ECS exec のターミナルセッションで、共有した PID namespace を確認できます。そのために、サイドカーコンテナ内に診断ツールをインストールします。 $ yum install procps strace -y 6. ps コマンド (上記でインストールした procps パッケージに含まれます) を使用することで、共有した PID namespace で実行中のすべてのプロセスを確認できます。このコマンドの出力には、サイドカーコンテナのプロセスだけでなく、アプリケーションコンテナの nginx プロセスも表示されます。また、ECS exec の機能を提供する AWS Systems Manager Session Manager のプロセスも表示されます。 $ ps -aef --forest UID PID PPID C STIME TTY TIME CMD root 38 0 0 09:53 ? 00:00:00 /managed-agents/execute-command/amazon-ssm-agent root 72 38 0 09:53 ? 00:00:00 \_ /managed-agents/execute-command/ssm-agent-worker root 34 0 0 09:53 ? 00:00:00 /managed-agents/execute-command/amazon-ssm-agent root 73 34 0 09:53 ? 00:00:00 \_ /managed-agents/execute-command/ssm-agent-worker root 266 73 0 09:58 ? 00:00:00 \_ /managed-agents/execute-command/ssm-session-worker ecs-execute-command-0147ec3fd84d94d24 root 276 266 0 09:58 pts/1 00:00:00 \_ /bin/bash root 286 276 0 09:59 pts/1 00:00:00 \_ ps -aef –forest root 8 0 0 09:53 ? 00:00:00 /dev/init -- sleep infinity root 19 8 0 09:53 ? 00:00:00 \_ sleep infinity root 7 0 0 09:53 ? 00:00:00 nginx: master process nginx -g daemon off; 101 56 7 0 09:53 ? 00:00:00 \_ nginx: worker process 101 285 7 0 09:59 ? 00:00:00 \_ nginx: worker process root 1 0 0 09:53 ? 00:00:00 /pause 7. PID namespace を共有することで、アプリケーションコンテナ内のプロセスが実行するシステムコールを監視することができます。ステップ 5 でインストールした strace パッケージを使用して、メインの nginx プロセスを監視してみましょう。システムコールを生成するには、 kill コマンドで nginx ワーカープロセスを強制終了します。以下の例では、メインの nginx プロセスは PID 7 で、ワーカープロセスは PID 56 です。これらの値は実行する環境によって異なる場合があるため、自身の環境に合わせて値を置き換えてください。 # プロセスの監視を開始する $ strace -p 7 -o straceoutput.txt &amp; # nginx ワーカープロセスを強制終了する $ kill -9 56 # プロセスの監視ログを表示する $ cat straceoutput.txt rt_sigsuspend([], 8) = ? ERESTARTNOHAND (To be restarted if no handler) --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=56, si_uid=101, si_status=SIGKILL, si_utime=0, si_stime=0} --- gettid() ... このウォークスルーでは、PID namespace を共有することで、サイドカーコンテナ内のプロセスが ECS タスク内の他のコンテナで実行中のすべてのプロセスを参照し、監視できることを確認しました。ステップ 7 では、アプリケーションコンテナ内のプロセスを強制停止させ、それに伴ってアプリケーションコンテナ内で実行されるシステムコールをサイドカーコンテナから確認しました。 後片付け 以下の手順を実行し、作成したリソースを削除します。 1. ECS Exec のターミナルセッションで exit コマンドを実行し、ECS exec を終了します。 2. aws ecs stop-task コマンドを実行し、ECS タスクを停止します。 $ aws ecs stop-task \ --cluster mycluster \ --task 5ce56f226dd4477a9f57918a98fc852f 3. aws ecs deregister-task-definition コマンドを実行し、ECS タスク定義を登録解除します。 aws ecs deregister-task-definition \ --task-definition fargatepidsharing:1 PID namespace を共有する際の注意点 AWS Fargate 上の ECS タスク内のコンテナ間で PID namespace を共有できるようになりましたが、これには注意すべき点がいくつかあります。それらの注意点を、ウォークスルーで作成したアプリケーション/サイドカーコンテナの例に沿って説明します。 サイドカーコンテナ内のプロセスは、アプリケーションコンテナ内のプロセスを監視するだけでなく、停止または再起動できます。 サイドカーコンテナ内のプロセスは、アプリケーションコンテナのファイルシステムに部分的にアクセスできます。例えば、アプリケーションが PID 7 として実行されている場合、サイドカーコンテナ内では /proc/7/root/ にあるアプリケーションコンテナのファイルシステムにアクセスできます。このとき、Unix ファイルパーミッションが、アプリケーションコンテナのファイルシステムを保護する唯一の仕組みとなります。 ECS タスクで PID namespace を共有する場合、 pause プロセスが PID 1 として新しく実行されます。 アプリケーションコンテナ内で実行されるプロセスの完全なトレーサビリティを実現するためには、ECS タスクに SYS_PTRACE Linux capability を追加することを検討してください。 まとめ 今回の発表によって、AWS Fargate 上でより多くのワークロードを実行されることを楽しみにしています。PID namespace の共有とカーネルパラメータの調整は、 AWS Containers Roadmap でリクエストされていた機能です。私たちは皆様の声を大切にしており、GitHub issue による追加の機能要望や改善に関するフィードバックを心待ちにしています。AWS Fargate のセキュリティアーキテクチャの詳細については、 AWS Fargate セキュリティホワイトペーパー を参照してください。

このブログは 2023 年 8 月 14 日に Virgil Ennes（Specialty Sr. Solutions Architect）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 多くのお客様は、プラットフォーム間で権限モデルが異なっていても、Linux と Windows から同時にアクセスができる高性能な共有ファイルシステムを必要としています。たとえば、メディアとエンターテイメント企業では、Linux と Windows クライアントでワークロードを双方でレンダリングする場合があります。これらのお客様は、「ユーザー名マッピング」などのメカニズムを使用して、Windows クライアントから NFS 経由で共有ファイルシステムをマウントし、ファイルアクセスの競合を回避できるようにしています。 Amazon FSx for OpenZFS （FSx for OpenZFS）はフルマネージドの AWS サービスとして、高性能アプリケーション向けのスケーラブルな OpenZFS ファイルシステムを提供します。スナップショットや暗号化などのデータ管理機能を備え、100 万以上の IOPS と 21 GB/s のスループットをサポートし、ビッグデータや、DevOps、研究のワークロードに適しています。異なるオペレーティングシステムと独自の権限モデル間のギャップを埋めるために、多くお客様では「ユーザー名マッピング」などのソリューションを使用して、NFS 経由でのシームレスなファイル共有を実現しています。 この記事では、Network File System（NFS）プロトコルバージョン 3 を使って、FSx for OpenZFS に保存されているデータを Linux と Windows クライアントで同時に共有するためのさまざまな認証方法を紹介します。これにより、クロスプラットフォームでのデータアクセスや、セキュリティ強化、効率的なデータ管理が可能になり、生産性の向上とリソースの最適化につながります。 NFS と FSx for OpenZFS のバックグラウンド NFS は Linux のネイティブプロトコルです。Linux 標準の mount コマンドと、ボリュームに関連付けられたドメインネームシステム（DNS）名を使用して、FSx for OpenZFS を Linux にマウントできます。 NFS プロトコルのバージョン 3 および 4.0、4.1、4.2 を使用して、FSx for OpenZFS ファイルシステム上のデータにアクセスできます。Linux クライアントは NFS バージョン 3 と 4.x をネイティブにサポートしており、Linux 標準の mount コマンドを使用してファイルシステムをマウントします。Windows クライアントは NFS バージョン 2 と 3 をサポートしており、NFS クライアントのインストールが必要です。 Linux クライアントと Windows クライアントを同時に FSx for OpenZFS に接続する場合は、両方のプラットフォームでサポートされている NFS バージョンである NFS バージョン 3 を使用します。 AWS 記事の「 新機能 – Amazon FSx for OpenZFS 」では、FSx for OpenZFS ファイルシステムのセットアップに関する情報を提供しています。 ソリューションのウォークスルー このソリューションを実装する手順の概要を以下に示します。 Windows に NFS クライアントをインストールして設定する Windows クライアントより NFS プロトコルを使用して&nbsp;FSx for OpenZFS をマウントするために必要です。 ファイルシステムをマウントする FSx for OpenZFS ファイルシステムを Windows クライアントと Linux クライアントの両方からマウントして、データにアクセスできるようにします。 ID マッピングと NFS 認証方法を選択して設定する ユーザー名マッピングサーバー、または Active Directory（AD）統合、匿名認証のいずれかを選択して、FSx for OpenZFS のファイルにアクセスするユーザーをマッピングし、認証します。 1. Windows に NFS クライアントをインストールして設定する Windows に NFS クライアントをインストールして設定する必要があります。Windows に NFS クライアントをインストールする手順は以下のとおりです。GUI または Windows powershell が使用できます。 以下に、Windows Server 2019 で GUI を使用した手順の例を記載します（この手順は Windows Server 2022 でも利用できます）。 （a）インストール Windows サーバーにて「 サーバーマネージャー 」を開きます。 ダッシュボードの「 クイックスタート 」より「 役割と機能の追加 」を選択し、ダイアログボックスで「 次へ 」を選択します。 「 インストールの種類 」で、「 役割ベースまたは機能ベースのインストール 」を選択し、「 次へ 」を選択します。 「 サーバーの選択 」画面で、サーバー名を選択し、「 次へ 」を選択します。 「 サーバーの役割 」画面で、「 ファイルサービスと記憶域サービス 」を展開します。 「ファイルサービスと記憶域サービス」の「 記憶域サービス 」を選択し、「 次へ 」を選択します。 「 機能 」画面で、「 NFS クライアント 」を選択し、「 次へ 」を選択します。 「 確認 」画面で、「 インストール 」を選択します。 図 1: Windows サーバーで NFS クライアントのインストール （b）設定 Windows に NFS クライアントをインストールした後に、設定を行う必要があります。Windows サーバーの GUI 上で NFS クライアントを使用して、クライアントの設定と、既定のファイルのアクセス許可、セキュリティモデルをカスタマイズします。デフォルト設定（以下参照） は、ほとんどの環境で機能します。ただし、デフォルトのファイル権限が必要となるセキュリティ対策に対応しているか、Linux ディストリビューションのデフォルトと一致するかを考慮する必要があります。 ※補足：以下の「NFS 用サービス」ツールは、NFS サーバーの機能を追加する必要があります 図 2: Windows サーバーの NFS クライント – デフォルトのファイル権限 2. ファイルシステムをマウントする Linux と Windows クライアントにファイルシステムをマウントして、データにアクセスします。 ファイルシステムをマウントするために DNS 名が必要です。FSx コンソールを使用して、FSx for OpenZFS ファイルシステムの「 ネットワークとセキュリティ 」タブに移動し、DNS 名をコピーしてください。以下の 図 3 で、FSx for OpenZFS ファイルシステムの DNS 名が記載されている個所を示しています。 図 3: ファイルシステムの DNS 名取得 2. ファイルシステムの DNS 名と、以下の mount コマンド（基本的な mount コマンド）を使用して、Linux サーバーにファイルシステムをマウントします。 mount -t nfs -o vers=3 fs-04fcff18e33270111.fsx.us-west-2.amazonaws.com:/fsx/sync_vol /fsxsync 図 4: Linux にファイルシステムをマウント 3. 以下のコマンドを使用して、Windows サーバにファイルシステムをマウントします。 mount \\fs-04fcff18e33270111.fsx.us-west-2.amazonaws.com\fsx\sync_vol\ Z: 図 5: Windows にファイルシステムをマウント ファイルシステムの性能を最適化する手順については、FSx for OpenZFS の ドキュメント を参照してください。 3. ID マッピングと NFS 認証方法を選択して設定する Linux と Windows では、使用するアカウントとセキュリティシステムが異なります。Linux は、ユーザー識別子（UID）とグループ識別子（GID）でユーザーを表します。Windows は、一意のセキュリティ識別子（SID）でユーザーとグループを表します。ユーザー名マッピングは、Linux の UID と GID を Windows の SID に変換する、またはその逆に変換するプロセスです。ユーザー名マッピングは、Windows ユーザーが透過的にファイルへのアクセスと、変更、作成を行うためのクリーンなデフォルトの権限セットを提供します。 「NFS と FSx for OpenZFS のバックグラウンド」セクションで説明したように、NFS のサービスをインストールして設定したら、適切な ID マッピングと認証方法を選択して設定を行う必要があります。ユーザー名マッピングサーバー、または Active Directory（AD）統合、匿名認証を使用できます。 AUTH_SYS または AUTH_UNIX：アカウントマッピングに UID と GID 識別子を使用する AUTH_SYS または AUTH_UNIX アカウントマッピングは、Linux の UID と GID を、対応する Windows ユーザーおよびグループの SID と照合するプロセスです。 Windows 用の NFS クライアントでは、スタンドアロンサーバー用の %windir%\system32\etc\passwd を使用する方法と、ドメインに参加しているサーバー用に AD を使用する方法の、2 つのアカウントマッピング方法をサポートしています。 3.1 スタンドアロンサーバー：/etc/passwd /etc/passwd を使用して、Linux の UID と GID を Windows ユーザーおよびグループの SID へ 1 対 1 でマッピングします。 1. はじめに、Windows 用 NFS クライアントを使用して「 ユーザー名マッピングサーバー 」を指定します。この例では、マッピングサーバーはパスワードファイルを含むサーバーです。 図 6: Windows サーバーの NFS クライント – ユーザー名マッピングサーバー 2. 次に、パスワード（passwd）ファイルを Windows のパス %SYSTEMROOT%\system32\drivers\etc に配置します。ファイル内の各 Windows ユーザーや SID は、ファイル内の UID と GID に基づいて Linux ユーザーと照合されます。 3. /etc/passwd ファイルとマッピングサーバーを設定した後に、Windows で NFS クライアントを再起動します。powershell コマンドの nfsadmin client stop と、nfsadmin client start を使用できます。NFS クライアントを再起動する前に、ファイルシステムが Windows からアンマウントされていることを確認してください。 図 7: NFS クライアントの再起動 以下は、Windows クライアントの %SYSTEMROOT%\system32\drivers\etc にある /etc/passwd ファイルを使用したユーザーマッピングの例です。 図 8: Windows passwd ファイルの例 各行には、コロンで区切られた次のフィールドがあります：Windows ユーザー名, Linux UID, Linux GID, 説明, Windows ホームディレクトリ 以下の例では、Linux と Windows の両方に mary というユーザーを作成しました。Windows サーバーにログインしてファイルシステムをマウントした後、以下のような mount コマンドを実行することで、mary の UID と GID（この例では UID は 1002 、GID は 1007）が有効であることが確認できます。 図 9: マウントポイントの有効な UID と GID 4. Linux でファイルを作成し、Windows からそのファイルを確認します。Linux に mary のアカウントでログインして、 /sync_vol にマウントした FSx for OpenZFSファイルシステムへ mary-file-linux.txt という名前のテキストファイルを作成します。以下では、 mary-file-linux.txt ファイルの所有権と、グループメンバーシップ、権限を確認できます。 図 10: ファイルの権限 – Linux 5. Windows 側からそのファイルを確認します。 Windows で mary のアカウントでログインして、FSx for OpenZFS ファイルシステムをマップしたドライブを開きます。ファイルにアクセスすることができ、Linux と同じ所有権と、グループメンバーシップ、権限を保持していることがわかります。 図 11 の赤いボックスには、Windows によって割り当てられたファイル権限と、ユーザー ID、グループ ID が表示されています。 図 11: ファイル権限 – Windows ファイルプロパティ 6. Windows でファイルを作成し、Linux からそのファイルを確認します。 Windows に mary のアカウントでログインしてテキストファイルを作成し、FSx for OpenZFS のファイル共有をマップした Z: ドライブに保存します。 図 12: Z: ドライブに保存したサンプルテキストファイル Windows より、Windows の NFS クライアントが Linux 標準の所有者、グループ、その他、および R、W、X を使って権限を割り当てていることが確認できます。割り当てられた権限には、Windows の NFS クライアントに設定されたデフォルトのファイル権限が適用されています（ 図 3 ）。さらに、Windows に格納されている passwd ファイルから UID と GID が割り当てられています。 図 13: ファイル権限 – Windows ファイルプロパティ 7. FSx for OpenZFS の Linux マウントポイントより同じファイルを確認します。ファイルの内容を確認し、Windows で表示されている権限と所有権が Linux と一致していることが確認できます。 図 14: ファイル権限 – Linux さらに、ユーザー名は Linux から Windows、またはその逆の Windows から Linux で一致させる必要がないことに注意してください。たとえば、Windows の以下 passwd ファイルでは、Windows のユーザ jeff を UID 1004 にマッピングしています。Linux での UID 1004 は phill という Linux ユーザーです。Windows はマッピングに Linux ユーザー名（この例では phill）ではなく、UID を使用します。 図 15: ユーザー名マッピング – jeff を UID 1004（phill） 3.2 AD 参加サーバー 1. AD に参加しているサーバーの場合、AD ドメイン（本例では example.com）を使用するには、NFS クライアントで ID マッピングソースを選択する必要があります。 図 16: Windows サーバーの NFS クライアント – AD ドメイン名 2. 次に、AD 組織単位（OU）のユーザー共通名（CN）属性を更新する必要があります。ADSI エディタを使用して、Windows ユーザーの「GIDNumber」と「UIDNumber」を、対応する Linux ユーザーの Linux UID と GID に一致させるように更新します。以下の手順に従ってください。 a. AD ドメインサーバーで、Windows の検索バーに「adsi」と入力して ADSI エディターを開きます。 図 17: ADSI エディター b. ADSI エディターの「 Users 」サブツリーに移動し、ドメインから OU 内の該当ユーザーを選択します。該当ユーザーを右クリックして、「 プロパティ 」を選択します。 図 18: ADSI エディター – ユーザーの CN 変更 本例では、Windows ユーザー&nbsp;brian の CN 属性「 gidNumber 」と「 uidNumber 」を更新して、Linux ユーザー brian の UID 1013 と GID 1005 と一致させます。 c. uidNumber &nbsp;を 1013 に変更します。 図 19: ADSI エディター – uidNumber 属性の変更 d. gidNumber を 1005 に変更します。 図 20: ADSI エディター – gidNumber 属性の変更 3. Linux から Windows にマップするすべてのユーザーでこのプロセスを繰り返します。完了したら NFS クライアントを再起動します。NFSクライアントの再起動には、powershell コマンドの nfsadmin client stop と nfsadmin client start を使用します。NFS クライアントを再起動する前に、必ず Windows でファイルシステムをアンマウントしてください。 4. Linux にユーザー brian としてログインしてファイルを作成し、そのファイルの所有権と、グループメンバーシップ、権限を確認します。 図 21: Linux ファイル詳細 5. 最後に、example.com AD のドメインユーザー brian として Windows にログインしてファイルを確認します。Linux の所有権と、グループメンバーシップ、権限が Linux ユーザー brian のものと想定どおり一致していることが確認できます。 図 22: AD を使用したユーザ名マッピングの検証 3.3 AUTH_NONE：匿名認証 匿名認証を使用して、Linux ユーザーのユーザー ID とグループ ID を Windows クライアントにマップすることができます。 匿名認証は、ファイルシステムへの読み取り/書き込みアクセスを提供する一般的な方法です。ただし、ファイルへの書き込みアクセスを調停する厳密なメカニズムは提供されないことに注意してください。さらに、ユーザー/グループレベルで権限を設定することはできません。このため、匿名認証は推奨される方法ではありません。セキュリティが問題にならない状況でのみ検討してください。 匿名認証を設定するには、次のレジストリキーを追加し、再起動する必要があります。 New-ItemProperty HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default -Name AnonymousUID -Value &lt;Linux_uid&gt; -PropertyType "DWord" New-ItemProperty HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default -Name AnonymousGID -Value &lt;Linux_gid&gt; -PropertyType "DWord" レジストリキーを追加して再起動後、以下のように匿名オプション（ -o anon ）を使用して Windows にファイルシステムをマウントできます。UID と GID には -2 が割り当てられていることに注意してください。これは、匿名アクセスが使用中であることを意味します。 図 23: 匿名認証 クリーンアップ 今後不要な課金が発生しないようにするため、本ソリューションで使用されているリソースを削除したい場合は、 FSx for OpenZFS ユーザーガイド に従って、ファイルシステムをアンマウントし、FSx for OpenZFS ファイルシステムを削除してください。 まとめ この記事では、Windows サーバの NFS クライアントを使用して FSx for OpenZFS ファイルシステムのデータにアクセスし、Linux と Windows クライアント間でデータが共有できるようにする方法について説明しました。ファイルシステムをマウントし、認証によって保護し、パフォーマンスを調整するプロセスを確認しました。 主なポイントは、Linux プラットフォームと Windows プラットフォームの両方で FSx for OpenZFS を使用して、共有ファイルストレージに NFS プロトコルを使用できる点です。 その利点として、クロスプラットフォームのデータアクセスや、セキュリティの強化、効果的なデータ管理などがあり、生産性が向上し、リソースを最適化できます。この戦略を採用することで、FSx for OpenZFS のパワーを活用するだけでなく、異なるオペレーティングシステム間のギャップを効果的に埋めることができます。 FSx for OpenZFS サービスをより深く理解するために、以下の「リファレンス」セクションを詳しく確認してください。 リファレンス FSx for OpenZFS – OpenZFS ユーザーガイド FSx for OpenZFS パフォーマンス Nfsadmin Utility 翻訳はプロフェッショナルサービス本部の葉山が担当しました。 Virgil Ennes Virgil Ennes は AWS の Specialty Sr. Solutions Architect です。Virgil は、AWS が提供する俊敏性、コスト削減、イノベーション、グローバルリーチを活用できるようお客様を支援することを楽しんでいます。彼は主にストレージ、AI、ブロックチェーン、分析、IoT、クラウド経済学に焦点を当てています。余暇には、家族や友人と時間を過ごしたり、お気に入りのサッカークラブ（GALO）を見たりすることを楽しんでいます。

このブログ記事では、 IBM PC の物語と比較しながら、自動車アプリケーション向けのオープンハードウェアプラットフォームの導入が、自動車業界のイノベーション、ディスラプション、トランスフォーメーションの推進において同様の環境を作り出す可能性があることを紹介します。また、このブログ記事では、こうしたプラットフォームをリリースする最初の自動車業界の企業が得る可能性のある優位性についても議論します。 IBM が最初の PC を導入した経緯 1981年の IBM PC のリリースは、パーソナルコンピューティングの歴史における重要なマイルストーンでした。これは大企業が製造・販売した最初のパーソナルコンピュータであり、現代の世界を形作る一助ともなった、コンピュータ業界にとっての一つの標準を打ち立てました。 IBM PC の開発の物語は、1970年代後半、フロリダの IBM ボカラトン事業所のエンジニアチームがパーソナルコンピューターの開発プロジェクトに着手したときに始まりました。チームは Don Estridge が率いていました。Estridge ははっきりした目標を描いており、手頃な価格で使いやすく、ビジネスアプリケーションの実行に十分な処理能力を備えたマシンを作ることを目指していました。 1981年8月12日の IBM PC の発売は、コンピューター業界と社会全体に大きな影響を与えました。これにより、コンピューティングの民主化への道が開かれ、強力なテクノロジーをより多くのユーザーが利用できるようになりました。また、 PC をコンピューティングの主要なプラットフォームとして確立させ、現代では様々な形でPCが社会を形成していると言えます。 IBM PC の成功に貢献した主な要因の 1 つは、マシンのオープンアーキテクチャでした。IBM はコンピューターの技術仕様を他のメーカーにも公開しました。サードパーティ企業は IBM PC と互換性のあるハードウェアとソフトウェアを開発できるようになりました。これにより、製品とサービスのエコシステムが繁栄し、IBM PC は長年にわたってパーソナル・コンピューター市場の主要なプラットフォームとなりました。 IBM は、新しい製品やテクノロジーの革新と開発を続けることで、コンピューター業界の主要プレーヤーとしての地位を維持することができました。この結果、PC 業界のハードウェア製造の面では他企業が IBM を追い越し始めても、成長を続ける PC 市場から IBM は利益を得続けることができました。 IBM PC の物語は、車載ハードウェアでも繰り返されるでしょうか？ 今日、車載アプリケーション向けのオープンハードウェアプラットフォームはまだ存在していません。しかし、このようなプラットフォームの登場は、自動車業界にとって重要なマイルストーンとなる可能性があります。1980年代に IBM PC がパーソナル・コンピューター業界を変革したように、車載アプリケーション向けのオープンハードウェアプラットフォームは、新しいアイデアやイノベーションの急増につながる可能性があります。 IBM PC は相互運用性を念頭に置いて設計されてたため、さまざまなメーカーのソフトウェアとハードウェアのコンポーネントがシームレスに連携できました。同じように、ソフトウェア・デファインド・ビークル (Software Defined Vehicle, SDV) の開発者は、さまざまなコンポーネントやシステムがシームレスに連携できるような、車載アプリケーション向けのオープンハードウェアプラットフォームを目指すべきです。 車載アプリケーション向けのオープンハードウェアプラットフォームの仕様を作成した最初の自動車メーカーには、次の4つの優位性を得る可能性があります。 俊敏性の向上 オープンハードウェアプラットフォームでは、仮想化されたモデルをオープンに開発し共有することができます。このような仮想化モデルを使用することで、桁違いに多くの人々や組織が車載アプリケーションの作成に参加できるようになります。AWS は、お客様が必要に応じてリソースを迅速に立ち上げ、数分で数百、数千のコンピューティングインスタンスをデプロイできるように支援します。このような機能があれば、自動車メーカーはより迅速かつ頻繁に実験や革新を行うことができます。 その一例が Stellantis のバーチャルエンジニアリングワークベンチです 。 戦略的優位性 オープンハードウェアプラットフォームを最初に開発した自動車メーカーは、より迅速なイノベーション、ブランドの評判の向上、業界でのリーダーシップを通じて競争力を獲得する可能性があります。今後、ハードウェアはコモディティ化し、ソフトウェアが差別化要因となるでしょう。お客様に代わってイノベーションを起こす自動車メーカーにとって、AWS は最適なパートナーであると私たちは考えています。なぜなら、AWS は最も包括的なサービスを提供し、最大かつ最も活気のあるお客様・パートナーのコミュニティと、最も実績のあるオペレーションとセキュリティの専門知識を備えているからです。 コラボレーション 車載アプリケーション向けのオープンハードウェアプラットフォームは、構築と革新のための技術的基盤を提供するデファクトスタンダードとしての地位を確立することができます。車載アプリケーション向けのオープンハードウェアプラットフォームの仕様をインターネットで入手できることは、自動車メーカーに複数の利点をもたらす可能性があります。たとえば、自動車メーカーはこの仕様を使用して、新しい電子制御ユニット (ECU) 開発プロジェクトの技術的基礎をパートナーに伝えることができます。ソフトウェアベンダーはプラットフォーム用のアプリケーションを独立して開発できるため、これらの企業に新たな機会が開かれます。AWS では、この種のコラボレーションをサポートする 2 つのサービスが提供されています。 AWS Clean Rooms を使用すると、お客様とそのパートナーは、互いの元データ自体を共有したりコピーしたりすることなく、集計データのみをより簡単かつ安全に分析できます。 組織内では、共通の目標を共有しているが共通のデータセットを持たないさまざまな事業部門が Amazon DataZone を使用できます。Amazon DataZone を使用すると、お客様は組織の事業部門全体でデータを大規模に共有し、検索し、発見できます。さらに、統合データ分析ポータルを介してデータプロジェクトで協力することもできます。 環境の一致 ARM ベースの SoC (System On a Chip) は、さまざまな電子機器におけるデファクト・スタンダードです。これらの機器には、スマートフォン、タブレット、スマートウォッチ、および車載システムなどの組み込みシステムが含まれます。その結果、ハードウェアベンダーは、特に車載の中央演算ユニット向けに、 ARM ベースの SoC を自社の製品に組み込むことが増えています。 Amazon EC2 上で動作する ARM ベースの AWS Graviton プロセッサを使用すると、開発者は車載アプリケーションバイナリをコンパイルし、車載器同様に AWS クラウドでも実行できます。 その観点から、組み込みエッジ向け Scalable Open Architecture for Embedded Edge (SOAFEE） は、重大性が混在する (mixed criticality) 車載アプリケーション向けに、クラウドネイティブなアーキテクチャ設計と、対応するリファレンス実装を開発し、商用・非商用目的で提供することを目指しています。SOAFEE の組織運営メンバーには、ARM , Bosch, Cariad, Contintenal, RedHat, SUSE, Woven Planet, AWS が含まれます。 AWS は業界の変革をどう支えるか AWS は、仮想化された車載ハードウェアを実行および操作するための幅広いツールとリソースを提供しています。私たちは、ソフトウェアが主な差別化要因となる未来に向けた自動車業界の移行を支援することを決意しています。 詳細については、 AWS for Automotive のウェブサイトからお問い合わせください。 TAGS: SDV Daniel Schleicher Daniel Schleicher は AWS の Continental 社担当シニアソリューションアーキテクトで、ソフトウェアデファインドビークルを専門としています。彼はこの分野で、クラウドコンピューティングの原理を車載アプリケーションに適用し、仮想化されたハードウェアを利用して車載アプリケーションのソフトウェア開発プロセスを進めることに興味があります。以前の役職では、ダニエルは Volkswagen でエンタープライズ統合プラットフォームの AWS への移行を主導し、プロダクトマネージャーとして Mercedes Intelligent Cloud の中心的なサービスの構築に貢献しました。 Aleksandar Tolev Aleksandar Tolev は、アマゾンウェブサービスのソリューションアーキテクトマネージャーで、製造業と自動車業界のお客様に情熱を注いでいます。Aleksandar は、ソフトウェア開発と複雑な課題に対するリーンアーキテクチャの活用に情熱を注いでいます。余暇には、スポーツ、メンタルトレーニング、料理をするのが大好きです。 本記事は AWS ブログ Learning From the IBM PC : How an open hardware platform for automotive applications can help transform the industry を翻訳したものです。翻訳はソリューションアーキテクトの山本が担当しました。

AWS re:Invent 2021 の基調講演で、Werner Vogels 博士は、「 どこにでもあるクラウド 」が AWS のハードウェアとサービスを通して AWS を新しいロケールに提供している方法に関するインサイトを共有し、自身の ブログ記事 の中で 2022 年以降のテクノロジー予測の 1 つとして紹介しました。 「2022 年、そして今後さらに顕著になるのは、従来の一元的なインフラストラクチャモデルを超えて、特殊なテクノロジーを必要とする新しい環境へと加速するクラウドです。クラウドは、車、ティーポット、テレビの中に存在するようになります。道路を走るトラックから、物資を輸送する船や飛行機まで、クラウドはあらゆるものの中に存在するようになります。クラウドはグローバルに分散され、地球上だけでなく、宇宙上のほとんどすべてのデジタルデバイスやシステムに接続されるようになります」。 AWS は、大都市圏、5G ネットワーク、オンプレミスの拠点、モバイル、モノのインターネット (IoT) デバイスに至るまで、お客様が業務を行うさまざまな環境でクラウドからアプリケーションを構築して実行するための真に一貫したセキュアなエクスペリエンスを提供します。 詳細については、2023 年 8 月 30 日の午前 10 時 (太平洋夏時間) (東部標準時午後 1 時) から開催される参加費無料の 1 日の仮想イベント、 AWS Hybrid Cloud &amp; Edge Day にご参加ください。このイベントは、 LinkedIn Live 、 Twitter 、 YouTube 、 Twitch など、複数のプラットフォームで同時にストリーミングされます。 ハイブリッドクラウドとエッジコンピューティングの最新のトレンドや新しいテクノロジーに関する AWS のリーダーと業界アナリストの話を聞き、クラウド環境全体で AWS ハイブリッドクラウドとエッジサービスを使用するためのベストプラクティスを学ぶことができます。また、AWS のお客様からデータ戦略と主要なユースケースを学び、AWS ハイブリッドクラウドとエッジサービス、新機能と利点についての理解を深めることができます。 このイベントで予定されているハイライトをいくつかご紹介します。 リーダーシップセッション –&nbsp;キックオフとして、EC2 Edge のバイスプレジデント Jan Hofmeyr を迎え、最近発表された AWS ハイブリッドクラウド、エッジ、IoT 機能を使用して、お客様が高性能でインテリジェントなアプリケーションを構築している方法についてのインサイトを共有するリーダーシップセッションを開催します。次に、EK Media Group のリサーチ部門の長を務める Elias Khnaser 氏が加わり、ハイブリッドクラウドとエッジコンピューティングに影響を与えるグローバル、ビジネス、経済のトレンドについて話し合い、お客様の要件とユースケースについて議論します。 クラウドクローザーセッション –&nbsp;AWS が大都市圏や通信ネットワークにクラウドを近づけている方法について説明します。 AWS Local Zones 、 AWS Outposts ファミリー、 AWS Wavelength などのサービスは、クラウドコンピューティングとストレージのパワーを 5G ネットワークのエッジにもたらし、よりパフォーマンスの高いモバイルエクスペリエンスを実現します。AWS リージョンとエッジの間における運用の一貫性を活用した Norton LifeLock 、 Electronic Arts 、 Epic Games などの新しい革新的なユースケースを紹介します。また、MindBody、ElToro、Onica の例や その他のお客様事例 など、ハイブリッドクラウドシナリオをオンプレミスの拠点にデプロイする方法も紹介します。 オンプレミスセッション – AWS クラウドをデータセンターやオンプレミスの拠点に導入して、環境全体で真に一貫したエクスペリエンスを実現するためのオプションについて学びます。AWS のハイブリッドサービスとエッジサービスがどのようにデータのローカル処理、応答時間の短縮、迅速な意思決定を実現する方法について、実際の例を紹介します。また、 トヨタ が Amazon ECS と Amazon EKS のハイブリッドオプションを活用して、複数の環境にわたって使い慣れた管理ツールを使用してアプリケーションをモダナイズした方法も紹介します。デジタル主権とデータレジデンシーの重要な側面において、オンプレミスの規制要件と現実世界のシナリオを効果的に満たす方法を学ぶことができます。 堅牢なエッジセッション –&nbsp; AWS Snow ファミリー のような堅牢でモバイル、そして接続されていないエッジをサポートする AWS のサービスについて学びます。組織は、ネットワーク接続が拒否される、中断する、断続的になる、制限される環境 (DDIL = Denied, Disrupted, Intermittent or Limited) 接続のロケーションにコンピューティングワークロードをデプロイできます。 DDR.Live が AWS Private 5G を使用して、ワイヤレス接続が制限された場所でのライブイベント配信のために独自の 4G/LTE または 5G プライベートネットワークをデプロイした方法を紹介します。トレーニング済みのオブジェクト検出モデルのデプロイやエッジでのアプリケーションの設計など、主なユースケースについて説明します。最後に、エッジでの運用に関するメリットと要件について、Constellation Research, Inc. のバイスプレジデント兼プリンシパルアナリストを務める Holger Mueller 氏とのディスカッションが予定されています。 IoT パネルディスカッション – AWS IoT のお客様と業界の専門家のパネリストがイノベーションへのジャーニーについて議論します。 EuroTech が、エッジでの接続によって業務効率を向上させる一連のデバイスとサービスを市場に投入した方法を紹介します。EV の 充電会社である Wallbox が AWS IoT サービス で運用コストを削減し、効率性をスケールした方法についても紹介します。 マルチクラウドセッション – AWS は、ガバナンス、運用管理、オブザーバビリティなどの領域でマルチクラウドオペレーションを実行およびサポートする多くの ツール を提供しています。ハイブリッド環境とマルチクラウド環境の一般的な課題に加えて、AWS がプロセスの管理、運用、自動化にどのように役立つかを説明します。また、 Rackspace が AWS Systems Manager を使用してハイブリッド環境とマルチクラウド環境全体のインスタンスパッチを適用し、クラウドプロバイダー全体のインフラストラクチャ管理を自動化した方法も紹介します。 このイベントは、ハイブリッドクラウド、エッジコンピューティング、IoT、ネットワーキング、コンテンツ配信、5G について詳しく知りたいと考えているすべてのお客様とビルダーを対象としています。低レイテンシー、ローカルデータ処理、またはデータレジデンシー要件の理由でオンプレミスまたはエッジに配置する必要があるアプリケーションをサポートする方法について説明します。 詳細、イベントスケジュール、および AWS Hybrid Cloud &amp; Edge Day への登録については、 イベントページ にアクセスしてください。 — Channy 原文は こちら です。

様々な業界 (ヘルスケア、ライフ サイエンス、金融サービス、小売など) のお客様は、より強力なセキュリティ体制を必要としています。特に、ホストしているデータベースにクレジット カード番号や国民識別番号 (米国の社会保障番号など) などの機密データが含まれている場合、このデータを暗号化してデータベース管理者へのアクセスを制御できるソリューションを提供することが重要になります。 Always Encrypted は、このセキュリティ要件に対する Microsoft SQL Server の機能です。 Always Encrypted を使用すると、クライアントはクライアント アプリケーション内の機密データを暗号化し、暗号化キーをデータベース エンジンに公開することがなくなります。これにより、データを所有し閲覧できるユーザーと、データを管理するがアクセス権を持たないユーザー (データベース管理者、クラウド データベース オペレーター、またはその他の高い権限を持つ未承認ユーザー) が分離されます。その結果、Always Encrypted を使用すると機密データをクラウドに自信を持って保存できるようになり、悪意のある内部関係者によるデータ盗難の可能性を軽減できます。 Always Encrypted はアプリケーションに対して暗号化が透過的に行われます。クライアント コンピューターにインストールする Always Encrypted 対応ドライバーは、クライアント アプリケーション内の機密データを自動的に暗号化および復号化することで透過的なアクセスを実現します。ドライバーは、データをデータベースエンジンに渡す前に機微な情報を保持するカラムのデータを暗号化し、アプリケーションへのセマンティクスが保持されるようにクエリを自動的に書き換えます。同様に、ドライバーはクエリ結果に含まれる暗号化されたデータベースのカラムに保存されたデータを透過的に復号化します。 この投稿では、Windows 証明書ストアを使用して Amazon Relational Database Service (Amazon RDS) for SQL Server インスタンスに Always Encrypted を設定する方法を順番に説明します。 Always Encrypted で使用できる他のキー ストア (Azure Key Vault、ハードウェア セキュリティ モジュール) については、この記事の執筆時点ではサポートされていません。 前提条件 このソリューションをセットアップするには、次のリソースを備えた作業環境が必要です。 SQL Server がインストールされた開発ホスト (Always Encrypted 証明書が生成される Windows デバイス)。 Windows を実行している Amazon Elastic Compute Cloud (Amazon EC2) でホストされているターゲット アプリケーション サーバー。 SQL Server 2016 以降のインスタンス (RDS for SQL Server インスタンス)。 証明書ファイルを保存する Amazon Simple Storage Service (Amazon S3) バケット。 Always Encrypted 証明書。 開発マシンで実行されているローカル SQL Server インスタンスを使用して列マスター キーの証明書を生成するには、次の手順を実行します。 SQL Server Management Studio (SSMS) を使用して、暗号化するデータベースの セキュリティ ノードの下にある [ 列マスター キー ] フォルダーを開き、[列マスター キー] フォルダーを右クリックして、[新しい列マスター キー] を選択します。オプションを表示します。 証明書を「Windows 証明書ストア – 現在のユーザー」 キー ストアに保存します。 Microsoft 管理コンソール (MMC) の [ 証明書 ] オプションを使用して、Always Encrypted 証明書を見つけ、サムプリントをメモします (証明書を選択して詳細ダイアログ ボックスを開きます)。このサムプリントは、プロセスを自動化するために開発したスクリプトで必要になります。これまでに証明書スナップインにアクセスしたことがない場合は、ここに記載されている詳細な手順に従ってください。 Microsoft 管理コンソール (MMC)を開きます。 [ ファイル ]メニューに移動し、[ スナップインの追加または削除 ]オプションを選択します。 リスト化されている利用可能なスナップインから [ 証明書 ] オプションを選択します。 個人 / 証明書 フォルダに移動します。 「 Always Encrypted 証明書 」をダブルクリックします。 [ 詳細 ] タブを選択し、下にスクロールして、[ サムプリント ] プロパティを選択します。 次のダイアログ ボックスが示すように、[ ファイルにコピー ] を選択して、証明書を PFX ファイルにエクスポートします。 [証明書のエクスポート ウィザード] ダイアログ ボックスで [ 次へ ] を選択します。 「 はい、秘密キーをエクスポートします 」オプションを選択し、[ 次へ ] を選択します。 [ Personal Information Exchange (.PFX) 形式 ] オプションを選択し、[ 次へ ] を選択します。 パスワード を入力し、「 AES256-SHA256 」暗号化オプションを選択して、[ 次へ ] を選択します。 適切な パスとファイル名 を指定します。 [ 次へ ] を選択します。 [ 完了 ] を選択して、証明書のエクスポート プロセスを完了します。 このファイルを指定された S3 バケット にアップロードします。 RDS for SQL Server インスタンスで Always Encrypted を構成する 前提条件となる手順がすべて完了し、Always Encrypted 証明書を PSX ファイルに正常にエクスポートできたら、Amazon RDS for SQL Server インスタンスで Always Encrypted を設定する準備が整います。これを行うには、次の手順を実行します。 Microsoft リモート デスクトップ プロトコル クライアント (RDP) を利用して、ターゲットのアプリケーション サーバー (Windows EC2 クライアント) にリモートで接続します。 Amazon S3 からローカルフォルダーに証明書を含む PSX ファイル をダウンロードします。 証明書をターゲットとなるアプリケーション サーバーにインポート します。 以下に示すように、Always Encrypted オプションを有効にして SQL Server Management Studio (SSMS) を使用して Amazon RDS for SQL Server に接続します。 新しいクエリ ウィンドウを開き、「Enable parameterization for Always Encrypted」にチェックをいれます。 暗号化されたデータをホストするための新しいデータベースを作成します。 USE master; GO IF DB_ID('AlwaysEncrypted') IS NULL CREATE DATABASE [AlwaysEncrypted]; GO 前に取得した証明書のサムプリントを参照して、列マスター キーを作成します。 CREATE COLUMN MASTER KEY [AE_ColumnMasterKey] WITH ( KEY_STORE_PROVIDER_NAME = 'MSSQL_CERTIFICATE_STORE', KEY_PATH = 'CurrentUser/My/a619fb0c4029cfcd9d9e935dbb8dc98e0902000f', ); GO 列暗号化キーを作成します。 1 つのオプションは、SQL Server Management Studio GUI を活用することです。この場合、「Always Encrypted Keys」ノードの下に ある 「 Column Encryption Keys 」フォルダを見つけ、その フォルダ を 右クリック して「 新しい列暗号化キー 」オプションを 選択 します。列暗号化キーに対する適切な名前を入力し、上で作成した列マスター キーを選択して、 [OK] をクリック します。あるいは、以下の T-SQL スクリプトを利用することもできます。次のコードに示されている ENCRYPTED_VALUE を実際に使用している環境の証明書と一致するように調整してください。 CREATE COLUMN ENCRYPTION KEY [AE_ColumnEncryptionKey] WITH VALUES ( COLUMN_MASTER_KEY = [AE_ColumnMasterKey], ALGORITHM = 'RSA_OAEP', ENCRYPTED_VALUE = 0x016E000001630075007200720065006E00740075007300650072002F006D0079002F006100360031003900660062003000630034003000320039006300660063006400390064003900650039003300350064006200620038006400630039003800650030003900300032003000300030006600374AEE2DA655985A4822614237F61F217171DD13882CE89120BC7B2D5DDD6863668EC2EFE24A64E55ADA2E8A52B0F1E758CD3717157E6612784BB21DE65FDD005322EAA78BC96EA9CB833F5F73E1DD859DB0AE92A6F9D272DEDF53934AF9B43445A01E9FBDBDEF5FCD68087D4EDE85D7479F2BE3D21E401CEABBC6630C004BE1A4BD29BBE2167850F2A08F688BD4AA430F73959D934B44412C62E8EE63D2949B31A1AA07EC80248E1351CF53F5E0C94A142FBE05817A2DEBA87E191B158A748F8925854E52EEBC5D0D620C9BE9BB8157880105A2108F4409B30EE8E8FBF5B51B8C2A884F69B08C568709176A8F9DC1C56E005363BFB2E8E0C5FB27C17551A447E5626432546249839A5AAF334371004BD105F553F5FFCB138C83B4AF54F62163FC08825365B11B0888AF1DB2487C41FBFFE6138C0091500C2B3AD5D3326D36504F5D00C1725C4418263C8D2943BF1DD93B0454DF952975AB795191CF309154B7B6430E55725BF1FC0529C3617B3D44B4A25B983C75339ED999C0143137BB728EB0ACD2878C1DB5780513F456AA50334913931F777297B2EFA42DC5916CCD4F01D05D25F654E65058DED9BF45BE712036AD57A627A8011B14B6406B4C5459C8A7A41D92957C364997FFFDC016A0A64923B1F5794819186443D891F5C534805FDF12EFFF65BCC60FBD4757D9F06E7727C50FE3F5EF440B80292E3AB7536CF09D98 ); GO 暗号化が適切に設定されていることを確認します (参照用にサンプル出力が含まれています)。 USE [AlwaysEncrypted]; GO select * from sys.column_master_keys; select * from sys.column_encryption_keys; select * from sys.column_encryption_key_values; GO 暗号化された列を含むテーブルを作成します。次のサンプルには、列暗号化キーの両方のオプション (DETERMINISTICとRANDOMIZE) が含まれています。一般に最も使用されるオプションは、非常に高速であるためDETERMINISTICですが、使用例によっては、RANDOMIZEの方が優れたオプションです (列のカーディナリティが非常に低い場合など)。以下の T-SQL ステートメントでは、文字列項目に対するDETERMINISTIC暗号化オプションには バイナリ コード ポイント照合 (_BIN2) が必要であることに注意することが重要です。 IF OBJECT_ID('dbo.CustomerInfo', 'U') IS NOT NULL DROP TABLE dbo.CustomerInfo; GO CREATE TABLE dbo.CustomerInfo ( CustomerId INT IDENTITY(10000,1) NOT NULL PRIMARY KEY, CustomerName NVARCHAR(100) COLLATE Latin1_General_BIN2 ENCRYPTED WITH ( ENCRYPTION_TYPE = DETERMINISTIC, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', COLUMN_ENCRYPTION_KEY = AE_ColumnEncryptionKey ) NOT NULL, CustomerPhone NVARCHAR(11) COLLATE Latin1_General_BIN2 ENCRYPTED WITH ( ENCRYPTION_TYPE = RANDOMIZED, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', COLUMN_ENCRYPTION_KEY = AE_ColumnEncryptionKey ) NOT NULL ); GO 最近作成したテーブルをクエリします SELECT TOP 3 * FROM dbo.CustomerInfo WITH(NOLOCK); GO いくつかのレコードを挿入します。このサンプルでは、挿入操作を単一のステートメントとして保持することが重要です。そうしないと、SSMS がエラーをスローします。 DECLARE @CName AS nvarchar(100) = 'CustomerA', @CPhone AS nvarchar(11) = '12123330988'; INSERT INTO [dbo].[CustomerInfo] VALUES (@CName, @CPhone); GO DECLARE @CName AS nvarchar(100) = 'CustomerB', @CPhone AS nvarchar(11) = '14152220786'; INSERT INTO [dbo].[CustomerInfo] VALUES (@CName, @CPhone); GO DECLARE @CName AS nvarchar(100) = 'CustomerC', @CPhone AS nvarchar(11) = '19255550484'; INSERT INTO [dbo].[CustomerInfo] VALUES (@CName, @CPhone); GO 再度、テーブルをクエリします。 SELECT TOP 3 * FROM dbo.CustomerInfo WITH(NOLOCK); GO 値は暗号化されていないことに注意してください。証明書がデプロイされていない他のクライアントからこのクエリを実行すると、暗号化された値のみが表示されます。考えられるテストは、クライアントから証明書を削除してからクエリを再度実行することです。 結論 この投稿では、Windows 証明書ストアを使用して Amazon RDS for SQL Server インスタンスに Always Encrypted を設定する方法を説明しました。 Microsoft SQL Server Always Encrypted は多くの 制限付き でリリースされており、Amazon RDS for SQL Server インスタンスでこの機能をセットアップした後も制限は引き続き適用されることに留意することが重要です。この投稿に含まれる手順に従って作成されたリソースを使用する必要がない場合は、環境をクリーンアップすることを忘れないでください。演習中に作成された Amazon RDS for SQL Server インスタンスを削除し、PSX のホストに使用された Amazon S3 バケットを削除します。証明書ファイルを削除し、ターゲット アプリケーション サーバー (Always Encrypted Client) として使用されている Amazon EC2 インスタンスを終了します。 ご質問、コメント、フィードバックがありましたら、この投稿のコメントセクションに残してください。 About the authors Camilo Leon は、データベースを専門とする AWS のプリンシパル ソリューション アーキテクトであり、カリフォルニア州サンフランシスコを拠点としています。彼は AWS の顧客と協力して、AWS リレーショナル データベースのワークロードとビジネス アプリケーションの設計、デプロイ、管理に対するアーキテクチャのガイダンスと技術サポートを提供しています。余暇には、マウンテン バイク、写真、映画を楽しんでいます。 &nbsp; 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

2023 年 7 月 : この投稿には、オンプレミスの SMTP サーバーを使用してデータベース メールを構成する手順が追加されました。 Amazon RDS for SQL Server が SQL Server データベース メールを完全にサポートするようになったことを発表できることを嬉しく思います。このリリースより前にデータベース メールを有効にするには、 リンク サーバー の使用などさまざまな回避策を使用する必要がありました。SQL Server 用データベース メールのリリースでは、DB パラメータ グループを使用してデータベース メールをシームレスに有効にすることができます。 データベース メールは、Microsoft SQL Server で頻繁に使用される機能の 1 つです。データベース メールを使用すると、SMTP (Simple Mail Transfer Protocol) サーバーを使用して SQL Server からユーザーにメッセージを送信できます。この投稿では、データベース メールを設定し、 Amazon Simple Email Service (Amazon SES) 経由で RDS for SQL Server DB インスタンスから E メールを送信する方法を学びます。 データベース メールの一般的なユースケースは次のとおりです。 テキストメッセージの送信 クエリ結果またはレポートをテキストまたは添付ファイルとして送信 プロシージャまたはジョブ内でプログラムによる電子メール通知の送信 この投稿では、次の AWS サービスを使用します。 Amazon RDS for SQL Server – データベース メールは、SQL Server の Web、Standard および Enterprise エディションでサポートされています。 Amazon SES – Amazon SES を SMTP サーバーとして使用します。これは 1 つのオプションにすぎません。代わりに、別の SMTP サーバーを使用することもできます。その場合は、Amazon SES のセットアップに関する次のセクションをスキップしてください。 Amazon SES のセットアップ Amazon SES を SMTP サーバーとして使用して、電子メールを迅速に送信します。 Amazon SES は、あらゆるアプリケーション内から E メールを送信できるコスト効率が高い柔軟でスケーラブルな E メール サービスです。まず、次の手順を実行します。 Amazon SES コンソールで、[ SMTP 設定 ] を選択します。 「 サーバー名 」と「 ポート 」の値に注目してください。 [ SMTP 認証情報の作成 ] を選択します。 注意 : Amazon SES SMTP インターフェイス経由で E メールを送信するために使用する認証情報は、各 AWS リージョンで固有です。詳細については、「 Amazon SES SMTP 認証情報の取得 」を参照してください。 AWS Identity and Access Management の名前を入力します。 (IAM) ユーザーにするか、デフォルトのままにします。 「 作成 」を選択します。 SMTP 認証情報を安全な場所に保存します。ダウンロードできるのはこのときだけです。 Amazon SES コンソールで、[ E メールアドレス ] を選択します。 [ 新しいメール アドレスの確認 ] を選択します。 確認メールを受信するには、所有しているメール アドレスを入力してください。 メールを確認すると、「 検証ステータス 」に 認証済み と表示されます。 この時点で、SMTP サーバーに関する必要な情報がすべて揃ったので、データベース メールの構成を開始することができます。 データベース メールのセットアップ データベース メールを構成する前に、まず DB パラメータ グループを通じてデータベース メールを有効にします。 DB パラメータ グループによるデータベース メールの有効化 データベース メールは、RDS インスタンスでは DB パラメータグループを通じて 有効にします。 Amazon RDS では、パラメータグループは、1 つ以上の DB インスタンスに適用されるエンジン設定値のコンテナとして機能します。各 RDS インスタンスには、デフォルトのパラメータ グループが関連付けられています。ただし、変更することはできません。新しいパラメータグループを使用することも、既存の作成済みパラメータ グループを使用することもできます。既存のパラメータグループを選択する場合は、SQL Server インスタンスのエディションとバージョンがサポートされている必要があります。新しいパラメータグループの作成の詳細については、「 DB パラメータ グループの操作 」を参照してください。パラメータ グループを通じてデータベース メールを有効にするには、次の手順を実行します。 Amazon RDS コンソールで、[ パラメータグループ ] を選択します。 使用するパラメータグループを選択します。 検索ボックスに「database mail xps」と入力します。 「 編集 」を選択して値を変更します。 [ 値 ] で 1 を選択します。 変更を保存します。 Amazon RDS コンソールで、[ データベース ] を選択します。 使用するインスタンスを選択します。 「 変更 」を選択します。 「 データベース オプション 」で、database mail xps に1 が設定されているパラメータグループを選択します。 「 続行 」を選択します。 「 変更のスケジュール 」で、「 すぐに適用 」を選択します。 [ DB インスタンスを変更 ] を選択して変更を適用します。 パブリックサブネット内のインスタンスのデータベースメールの構成 次の図は、データベース メール構成の例を示しています。 User1 は、Profile 1 を介してアカウント 1 とアカウント 2 にアクセスできます。User2 は、両方のプロファイルを介してすべてのアカウントにアクセスできます。 User3 は、Profile 2 を介してアカウント 2 とアカウント 3 にアクセスできます。 データベース メールを使用する前に、メール構成をセットアップする必要があります。 SQL Server Management Studioを起動します。 データベース メールが有効になっている RDS インスタンスの SQL Server エンジンに接続します。 新しいクエリを開きます。 次のストアド プロシージャを使用して、単純なデータベース メール構成を作成します。 データベース メール プロファイルを作成します (プロファイルは電子メール アカウントを保存するために使用されるコンテナです)。次のコードを参照してください。 use msdb go EXECUTE msdb.dbo.sysmail_add_profile_sp @profile_name = 'Notifications', @description = 'Profile used for sending outgoing notifications using SES.' ; プロファイルにプリンシパルを追加します。 public を使用すると、すべてのユーザーがプロファイルにアクセスできるようになります。 use msdb go EXECUTE msdb.dbo.sysmail_add_principalprofile_sp @profile_name = 'Notifications', @principal_name = 'public', @is_default = 1 ; 必要に応じてデータベース メール オブジェクトに対するアクセス許可を付与できますが、現時点では public で問題ありません。 データベース メール アカウントを作成します (必ず正しい SMTP 資格情報を入力してください)。 use msdb go EXECUTE msdb.dbo.sysmail_add_account_sp @account_name = 'Acc1', @description = 'Mail account for sending outgoing notifications.', @email_address = ' example@example.com ', @display_name = 'Automated Mailer', @mailserver_name = ' email-smtp.us-west-2.amazonaws.com ', @port = 587 , @enable_ssl = 1, @username = 'SMTP-username' , @password = 'SMTP-password' ; この手順は、パブリック サブネットでホストされている RDS インスタンスに適しています。ただし、RDS インスタンスがプライベート サブネットに配置されている場合は、次のセクションで詳細なガイダンスを参照してください。 データベース メール アカウントをデータベース メール プロファイルに追加します。 use msdb go EXECUTE msdb.dbo.sysmail_add_profileaccount_sp @profile_name = 'Notifications', @account_name = 'Acc1', @sequence_number = 1; プライベート・サブネット内のインスタンスのデータベース・メールの構成 RDS for SQL Server インスタンスがプライベート サブネットでホストされている場合は、Amazon SES の VPC エンドポイントを使用する必要があります。これにより、RDS for SQL Server インスタンスと SMTP サーバー間の通信が可能になります。先に進む前に、まず前のセクションのステップ 1 ～ 5 を完了することが重要です。これらの最初のステップは、その後のステップの基礎となります。 SES の VPC エンドポイントのセキュリティグループの作成 Amazon VPC コンソール を開きます SES VPC エンドポイントの セキュリティ グループ を作成します。 新しいインバウンドルールを作成します。 [タイプ] で、[ カスタム TCP ] を選択します。 [ ポート範囲 ] に、電子メールの送信に使用するポート番号を入力します。 25、465、587 を使用できます。 [ ソース タイプ ] で、[ カスタム ] を選択します。 [ ソース ] に、RDS for SQL Server インスタンスにアタッチされているセキュリティ グループを入力します。 VPC エンドポイントの作成 Amazon VPC コンソール を開き、[エンドポイント] を選択します。 「エンドポイントの作成」を選択します。 名前を入力します。 [サービス カテゴリ] で [AWS サービス] を選択します。 「サービス」で「smtp」を検索し、そのリージョンに固有の SMTP VPC エンドポイントを選択します。 「VPC」セクションで、このエンドポイントが作成される VPC を選択します。 追加設定では、デフォルトで DNS 名の DNS 名を有効化 にチェック、DNS レコードの IP タイプでは Ipv4 がチェックされていることを確認してください。 「サブネット」で、アベイラビリティーゾーン内のサブネットを選択します。 &nbsp;[セキュリティ グループ] で、前に作成したセキュリティ グループを選択します。 「エンドポイントの作成」をクリックします。 VPC エンドポイントが利用可能な状態になったら、エンドポイントを選択し、DNS フィールドで見つかった最初のエントリをコピーします。 SMTP サーバー名の代わりに、前に作成した VPC エンドポイントの DNS 名を使用してデータベース メール アカウントを作成します。 (必ず正しい SMTP 資格情報を入力してください) use msdb go EXECUTE msdb.dbo.sysmail_add_account_sp @account_name = 'Acc1', @description = 'Mail account for sending outgoing notifications.', @email_address = 'example@example.com' , @display_name = 'Automated Mailer', @mailserver_name = 'vpce-XXXXX-XXXX.email-smtp.us-west-2.vpce.amazonaws.com' , -- VPC endpoint created in previous step @port = 587 , @enable_ssl = 1, @username = 'SMTP-username' , @password = 'SMTP-password' ; データベース メール アカウントをデータベース メール プロファイルに追加します。 use msdb go EXECUTE msdb.dbo.sysmail_add_profileaccount_sp @profile_name = 'Notifications', @account_name = 'Acc1', @sequence_number = 1; テストメールの送信 ストアド プロシージャ sp_send_dbmail を実行して電子メールを送信します (次のコードを参照)。受信者は、 Amazon SES シミュレーター を使用して、メールの送信が成功したかどうかを簡単にテストできます。その他のテスト オプションについては、「メールボックス シミュレーターの使用」を参照してください。実際の受信者に送信したい場合は、このプロセスを繰り返して追加の電子メール アドレスを確認する必要があります。 EXEC msdb.dbo.sp_send_dbmail @profile_name = 'Notifications', @recipients = 'success@simulator.amazonses.com', @body = 'The database mail configuration was completed successfully.', @subject = 'Automated Success Message'; GO 次に、次に示すストアド プロシージャを実行してすべての電子メール アイテムを表示します。 SELECT * FROM msdb.dbo.sysmail_allitems sent_status 列で、ステータスが送信されたことを確認します。 オンプレミスの SMTP サーバーを使用したデータベース メールの構成 一部の顧客は、オンプレミスの SMTP サーバーを使用して Amazon RDS for SQL Server でメールを設定したいと考えていました。このセクションでは、オンプレミスの SMTP サーバーをメール サーバーとして使用して、RDS for SQL Server DB インスタンスから電子メールを送信するようにデータベース メールを構成する方法について詳しく説明します。 前提条件 次の前提条件を満たしている必要があります。 前のセクションの DB パラメータ グループを通じて database mail xps が有効になっている DB パラメータを持つ RDS for SQL Server インスタンスであること SMTP サーバーでの認証に有効な資格情報を持つオンプレミス SMTP サーバーであること オンプレミス SMTP サーバーの構成を変更するための十分なアクセス権限を持つこと オンプレミスの SMTP サーバー接続を確認する オンプレミスの SMTP サーバーが正しく構成されており、電子メールを送信できることを確認します。次のことを確認してください。 SMTP サーバー アドレス – SMTP サーバーの IP アドレスまたはホスト名を取得します。 ポート番号 – SMTP サーバーで使用されるポート番号をメモします (通常、暗号化されていない接続の場合はポート 25、TLS/SSL 暗号化された接続の場合はポート 587 )。 認証資格情報 – SMTP サーバーでの認証に必要なユーザー名とパスワードがあることを確認します。 暗号化要件 – SMTP サーバーに安全な接続 (TLS/SSL) が必要かどうかを決定します。 ネットワーク接続を有効にする ネットワーク接続を有効にするには、次の手順を実行します。 SMTP サーバーは AWS ネットワークの外部に存在するため、サーバーが指定された IP 範囲内の Amazon RDS for SQL Server からの接続を許可していることを検証する必要があります。 Amazon RDS for SQL Server の IP 範囲またはパブリック IP が SMTP サーバーの許可リストに含まれていることを確認する必要があります。これを実現するための具体的な手順は、組織のポリシーや設定によって異なる場合があることに注意してください。 RDS for SQL Server インスタンスのセキュリティ グループを変更し、SMTP サーバーからの接続を許可する新しい受信ルールを追加します。 RDS インスタンスが実行されている AWS アカウントでは、ポート 25 がデフォルトでスロットルされます。ポート 25 がブロックされていないことを確認するには、AWS に SMTP (ポート 25) スロットリングを削除するようにリクエストする必要があります。これを行うには、 電子メール送信制限の削除リクエスト フォーム を使用します。 SMTP サーバーの DNS を解決するための Amazon Route 53 ルールを追加します。これにより、RDS インスタンスから電子メールを送信するときに SMTP サーバーのドメインが解決されます。 データベースメールの構成 次の手順でデータベース メールを構成します。 「 パブリック サブネット内のインスタンスのデータベース メールの構成 」セクションと同じ手順に従って、データベース メールを設定します。 データベース メール アカウントを作成するとき、メール サーバー名には、オンプレミスの SMTP サーバー名または IP (例えば mysmtpsvr.com など) を使用します。 データベース メール アカウントを作成します (必ず正しい SMTP 資格情報を入力してください)。 use msdb go EXECUTE msdb.dbo.sysmail_add_account_sp @account_name = 'Acc1', @description = 'Mail account for sending outgoing notifications.', @email_address = 'example@example.com', @display_name = 'Automated Mailer', @mailserver_name = 'mysmtpsvr.com', @port = 587, @enable_ssl = 1, @username = 'On-Prem-SMTP-username', @password = 'On-Prem-SMTP-password'; データベース メール アカウントをデータベース メール プロファイルに追加します。 use msdb go EXECUTE msdb.dbo.sysmail_add_profileaccount_sp @profile_name = 'Notifications', @account_name = 'Acc1', @sequence_number = 1; 結論 この投稿では、Amazon SES を使用してデータベース メールを設定する方法を説明しました。 SQL Server 用データベース メールのリリースにより、データベース メールを有効にして使用するための回避策を見つける必要がなくなりました。このソリューションは、他のサードパーティ SMTP サーバーにも使用できます。今すぐ AWS マネジメントコンソール でデータベースメールを試して、コメントであなたの考えや経験を共有してください。 About the authors Andrew Zhou は、アマゾン ウェブ サービスのソフトウェア開発エンジニアです。彼は AWS RDS チームと協力して、商用データベース エンジンと SQL Server に重点を置いています。彼は技術的な課題に取り組むことを楽しんでおり、新しいテクノロジーを学ぶことに情熱を持っています。 Chandra Shekar Ramavath iは、アマゾン ウェブ サービスのデータベース エンジニアです。彼は AWS RDS チームと協力して、商用データベース エンジン、SQL Server、Oracle に重点を置いています。 Sid Vantair は、戦略アカウントを担当する AWS のソリューション アーキテクトです。リレーショナル データベースを扱う 10 年以上の経験を持つ彼は、顧客のハードルを克服するために複雑な技術的問題を解決することに熱心に取り組んでいます。仕事以外では、家族と過ごす時間を大切にし、子供たちの好奇心を育んでいます。 Bharath Kumar は、AWS プロフェッショナル サービス チームのリード データベース コンサルタントです。彼は、顧客がオンプレミス データセンターから AWS クラウドにデータベースを移行できるようにサポートし、また商用データベース エンジンから Amazon のオープンソース データベースへの移行もサポートしてきました。 Nishad Mankar は、AWS プロフェッショナル サービスのリード データベース コンサルタントです。彼は、顧客が AWS クラウド上でデータベースを移行して最新化できるよう支援しています。 &nbsp; &nbsp; &nbsp; 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

この記事は、“ Improving medical imaging workflows with AWS HealthImaging and SageMaker ” を翻訳したものです。 医用画像は、医療における患者の診断と治療計画において重要な役割を果たします。しかし、医療提供者は、医用画像の管理、保存、分析に関していくつかの課題に直面しています。このプロセスには時間がかかり、エラーが発生しやすく、コストがかかる可能性があります。 また、地域や医療制度全体では放射線科医が不足しており、人口の高齢化、画像技術の進歩、医療における画像診断の重要性の増大により、この専門分野の需要が高まっています。 画像検査の需要が高まり続ける中、対応できる放射線科医の数が限られているため、検査予約や適切な診断が遅れています。テクノロジーによって臨床医と患者への医療提供の改善が可能になる一方で、病院は最も差し迫った課題を解決するために次のような追加のツールを求めています。 画像検査および診断サービスに対する需要の高まりによる専門家の燃え尽き症候群 体積測定や画像の構造的セグメンテーションなど、手間のかかる作業 利便性、使いやすさ、個別化の観点から、小売やテクノロジーに匹敵する質の高い医療体験を期待する患者からの期待の高まり 臨床医と患者の体験を向上させるには、人工知能（AI）対応の画像診断クラウドソリューションでPicture Archiving and Communication System（PACS: 医用画像サーバー）を運用して、重要な知見を安全に取得し、医療へのアクセスを改善してください。 AIは自動化により放射線科医の燃え尽き症候群を低減するのに役立ちます。たとえば、AIは放射線科医の胸部X線画像の診断時間を節約します。また、精密検査が必要な領域を特定するための強力なツールでもあり、当初は特定できなかった二次的な発見も得るのに役立ちます。相互運用性と分析の進歩により、放射線科医は患者の健康記録を360度縦断的に把握できるようになり、より低コストでより良い医療を提供できるようになりました。 AWS は、これらの課題に対処するサービスを提供しています。このブログ記事では、 AWS HealthImaging (AWS AHI) と Amazon SageMaker 、およびこれらを併用して医療提供者の医用画像ワークフローを改善する方法について説明します。これにより、最終的に画像診断が加速し、放射線医学の生産性が向上します。AWS AHI を使用すると、開発者はクラウドネイティブな医用画像アプリケーションにパフォーマンス、セキュリティ、およびスケールを提供できます。これにより、Digital Imaging and Communication in Medicine (DICOM) 画像を取り込むことができます。Amazon SageMaker は AI と機械学習のためのエンドツーエンドのソリューションを提供します。 自動車事故後のX線に関する使用例を見てみましょう。この医用画像診断ワークフローでは、患者は救急室にいます。そこから: 患者は骨折の有無を確認するためにX線撮影を受けます。 スキャンされた撮影装置の画像はPACSシステムに送られます。 放射線科医は、この検査で取得した情報を確認し、レポートを作成します。 依頼医にレポートが提供されるまで、患者のワークフローは継続されます。 次世代の画像処理ソリューションとワークフロー 医療提供者は AWS AHI と Amazon SageMaker を併用することで、次世代の画像診断ソリューションを実現し、医用画像診断ワークフローを改善できます。次のアーキテクチャは、この例を示しています。 図 1: X 線画像が AWS HealthImaging に送信され、Amazon SageMaker エンドポイントが分析情報を抽出します。 アーキテクチャと主要なコンポーネントを見てみましょう。 1. イメージスキャナー:患者の体から画像をキャプチャします。モダリティによっては、X線検出器、CTスキャナーの検出器アレイ、MRIスキャナーの磁場と高周波コイル、または超音波センサーなどがあります。この例では X 線デバイスを使用しています。 AWS IoT Greengrass : DICOM C-Store SCP で設定されたエッジランタイムとクラウドサービスで、画像を受信して Amazon Simple Storage Service (Amazon S3 ) に送信します。画像と関連するメタデータは、それぞれ Amazon S3 と Amazon Simple Queue Service (Amazon SQS) に送信され、ワークフローがトリガーされます。 2. Amazon SQS メッセージキュー:S3 バケットからのイベントを受信し、 AWS Step Functions ワークフローオーケストレーションをトリガーします。 3. AWS Step Functions は変換ジョブとインポートジョブを実行して画像を処理し、AWS AHI データストアインスタンスにインポートします。 4. 最終的な診断画像は、関連する患者情報およびメタデータとともに、AWS AHI データストアに保存されます。これにより、画像データの検索と管理を効率的に行うことができます。また、クラウドネイティブ API と AWS パートナーのアプリケーションにより、医用画像データへのアクセスも可能になり、1 秒未満の大規模な画像取得レイテンシーを実現できます。 5. ML 画像のラベリングを担当する放射線科医は、 Amazon SageMaker Ground Truth を使用して医用画像にアノテーションを付けます。カスタムデータラベリングワークフロー（組み込みまたはカスタムのデータラベリングワークフローをサポートするフルマネージドデータラベリングサービス）を使用して DICOM 画像を視覚化およびラベル付けします。また、 3D Slicer などのツールを活用して、インタラクティブな医用画像にアノテーションを付けています。 6. データサイエンティストは、Amazon SageMaker のアノテーション付き画像を使用して、組み込みのディープラーニングモデルを構築または活用します。SageMaker には、低レイテンシーや高スループットから長時間実行される推論ジョブまで、さまざまな展開オプションが用意されています。これらのオプションには、バッチ、リアルタイム、または ニアリアルタイム の推論に関する考慮事項が含まれます。 7. 医療提供者は AWS AHI と Amazon SageMaker を使用して、AI を活用した検出と解釈のワークフローを実行しています。このワークフローを使用して、見えにくい骨折、脱臼、軟部組織損傷を特定し、外科医や放射線科医が自信を持って治療を選択できるようになります。 8. 最後に、AWS AHI に保存された画像はモニターやその他の視覚出力デバイスに表示され、放射線科医やその他の医療専門家が分析および解釈できます。 Open Health Imaging Foundation （OHIF）ビューアーは、オープンソースのウェブベースの医用画像プラットフォームです。複雑な画像処理アプリケーションを構築するためのコアフレームワークを提供します。 Radical Imaging と Arterys は、OHIF ベースの医用画像ビューアを提供する AWS パートナーです。 これらの各コンポーネントは、医用画像システムの全体的な性能と精度だけでなく、診断結果と患者ケアの向上に焦点を当てた継続的な研究開発においても重要な役割を果たします。AWS AHI は、効率的なメタデータエンコーディング、可逆圧縮、プログレッシブ解像度データアクセスを使用して、業界トップクラスのパフォーマンスを画像読み込みで提供します。効率的なメタデータのエンコーディングにより、画像ビューアと AI アルゴリズムは、画像データを読み込まずに DICOM 検査の内容を理解できます。 セキュリティ AWS の責任共有モデルは、AWS AHI と Amazon SageMaker におけるデータ保護に適用されます。 Amazon SageMaker は HIPAA の対象であり、保護対象保健情報 (PHI) を含むデータを扱うことができます。転送中のデータの暗号化は SSL/TLS によって提供され、Amazon SageMaker のフロントエンドインターフェイス (ノートブック) との通信時と Amazon SageMaker が他の AWS サービスとやり取りする場合の両方に使用されます。 AWS AHI は HIPAA 適格のサービスでもあり、メタデータレベルでのアクセス制御が可能なため、各ユーザーとアプリケーションには、それぞれのロールに基づいて必要な画像とメタデータフィールドのみが表示されます。これにより、患者のPHIの増加が防止されます。AWS AHI API へのすべてのアクセスは、 AWS CloudTrail に詳細に記録されます。 これらのサービスはどちらも AWS Key Management Service (AWS KMS) を活用して、PHI データを保存時に暗号化するという要件を満たします。 まとめ この投稿では、症状の早期発見と治療のための一般的な使用例を概説し、その結果、患者の治療成績が向上しました。また、テクノロジーの力を活用して医用画像の精度、効率、アクセス性を向上させることで、放射線医学分野を変革できるアーキテクチャについても取り上げました。 参考文献 AWS HealthImaging Partners AWS features AWS HealthImaging at RSNA22 Annotate DICOM images and build an ML model using the MONAI framework on Amazon SageMaker MLOps deployment best practices for real-time inference model serving endpoints with Amazon SageMaker Sukhomoy Basak Sukhomoy Basak はアマゾンウェブサービスのソリューションアーキテクトで、データおよび分析ソリューションに情熱を注いでいます。Sukhomoy は、企業のお客様と協力して、ビジネス成果を達成するためのアプリケーションの設計、構築、拡張を支援しています。 Hassan Mousaid Hassan Mousaid 博士は、アマゾンウェブサービスの主任ソリューションアーキテクトであり、ヘルスケアおよびライフサイエンス (HCLS) のお客様が、Amazon のイノベーションメカニズムを使用してアイデアを市場に投入するプロセスを加速できるようサポートしています。エンタープライズおよびクラウドトランスフォーメーション、ヘルスケアIT、医用画像分野で20年の経験があります。 翻訳は Solutions Architect 窪田が担当しました。原文は こちら です。

この記事は、“ Enhancing multidisciplinary collaboration in digital pathology with cloud-based PACS ” を翻訳したものです。 病理医は凍結切片法を用いて生検した組織の分析を行います。従来、凍結切開では組織生検の可視化に顕微鏡検査のみに頼っていました。ただし、顕微鏡スライドは壊れやすく、細胞構造の視覚化に使用される色素は時間の経過とともに色あせてしまうため、情報の共有とデータ保存に重大な問題が生じます。顕微鏡用カメラの発明により、スライドキャプチャが簡単になりました。それでも、画像はローカルストレージに最適化するために圧縮されることが多く、レポートの作成中に画像をキャプチャするという手作業が追加されるため、病理医の通常のワークフローが中断されることになります。 ホールスライドスキャナーは画像キャプチャの負担を軽減すると、当初はデジタル病理学において関心を呼びましたが、完全なエンドツーエンドのソリューションではありません。世界中の多くの病院は、まだデジタル病理学の可能性を最大限に活用していません。 韓国に拠点を置くヘルスケアテクノロジー（ HealthTech ）企業である INFINITT Healthcare は、スライド標本全体画像（WSI）の出力を医療における Digital Imaging and Communications in Medicine（DICOM）ファイルとして抽出して変換することで、状況を変えることに取り組んでいます。DICOM は、病理医が時間と資源を節約し、多分野のコミュニケーションを効率化し、患者ケアのソリューションを実現するまでの時間を短縮するのに役立つWSIのデジタルバージョンです。その後、これはアマゾンウェブサービス（AWS）上に構築されたクラウドベースの Digital Pathology System（DPS）に保存されます。 デジタル病理学のパイロットリサーチ計画 専門の腫瘍センターを備えたソウル有数の病院である Samsung Medical Center（SMC: サムスン医療センター）は、デジタル病理学の導入を先導しています。SMCは年間200万人以上の患者を診察しており、1,200人の医師と2,300人の看護師を含む約7,400人のスタッフが配置されている三次病院です。INFINITT との共同リサーチ計画で、 SMC は2019年に病理部門でクラウドネイティブな Picture Archiving and Communication System（PACS）を試験的に導入しました。 SMC の病理部門は、年間52,000件の症例をサポートしており、これは1日あたり平均約214人の患者です。病理医は、本院から離れた別の建物で働いています。通常、搬送者が生検標本を搬送し、臨床検査技師が顕微鏡検査のために処理と準備を行い、最終的に病理医が検体を診断する必要があります。緊急の所見は、電話で主治医に伝えられます。 病理学におけるデジタル化の直接的なメリット 以前は、病理医は生検スライドを分析し、その結果を診療ノートに個別のレポートとして記述していました。腫瘍検査中に所見について話し合いたい場合は、顕微鏡に接続されたカメラで顕微鏡画像を撮影し、組織病理学的所見を含む PowerPoint ファイルを準備する必要がありました。さらに、生検スライドが壊れている場合、病理医は同じスライド画像を得るためにパラフィンブロックの再切断を依頼する必要があります。 スライド全体をデジタル化することで、病理医は所見を画像に直接アノテーションできるようになりました。その後、腫瘍ボード中に画像を INFINITT DPS で直接開くことができるため、時間と労力を節約できるだけでなく、患者のケアに焦点を当てたより多くの情報に基づいた意思決定が可能になります。 クラウドベースの DPS は、複数の専門分野にわたる腫瘍学チームにおけるコミュニケーションを即座に改善しました。病理医は、 INFINITT が提供するソフトウェアシステムを使用して、プライマリケアチームに電話をかけ、一緒に WSI をレビューできます。双方向の診断ツールとして、ウェブブラウザに搭載された最新の画面共有技術により、複数の遠隔地の病理医がスライド画像全体を同時に見て、まとめて診断することができます。これが可能なのは、各ユーザーが自分のマウスカーソルでスライドを動かして特定の位置を指すことができ、他の全員がリアルタイムですべてを見ることができるからです。 DPS は、国家レベルでの研究協力を可能にするために、アジア太平洋地域の一部の医療センターで実施されています。その後、韓国病理学会は会員の教育と訓練を目的として DPS を採用しました。 病理医のコミュニティ全体では、新しい DPS によってコストのかかるローカル IT インフラストラクチャの必要性が軽減され、データガバナンスを改善したという意見が一致しています。これまで、研究データ保持ポリシーを大規模に実施することは困難でした。ポリシーに準拠するため、サーバーラックをサードパーティベンダーが廃棄する必要がありました。クラウドベースの DPS では、データ保持ポリシーは Amazon Simple Storage Service (Amazon S3) バケットに書き込まれ、自動的にバックアップされます。 INIFITT が AWS を使用して WSI をデジタル化する方法 図 1.SMC の支援に役立った INFINITT のソリューションのアーキテクチャ図 INFINITT は DPS ソフトウェアで複数の AWS サービスを使用しています。図 1 は、このソリューションの大まかなアーキテクチャを示しています。 1) さまざまな学術機関から提供された DICOM 形式の WSI は、 Amazon Virtual Private Cloud (Amazon VPC) の Amazon Elastic Block Store (Amazon EBS) にエクスポートされ、保存されます。 2) INFINITT DPS は VPC の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでホストされます。 3) ユーザーはウェブポータルを介してWSIの検査にアクセスします。 4) アノテーションが付けられた WSI イメージは Amazon S3 に保存されます。 Amazon SageMaker は、人工知能 (AI) と機械学習 (ML) のワークフロー全体を管理し、関心のある特定の疾患に関するモデルをトレーニングするために使用されます。その後、処理された画像は Amazon S3 に保存され、INFINITT DPS 経由でアクセスできるようになります。 5) Amazon Cognito は INFINITT DPS ロードマップに追加され、臨床研究者の役割分担やアクセスガバナンスの強化など、役割分担によるデータへの安全なアクセスをサポートします。 INFINITT の DPS ソリューションは、病理学者のコミュニケーションと学際的なコラボレーションを強化するのに役立ちます。さらに、従来の IT インフラストラクチャからクラウドベースの PACS に切り替えることで、病院システムは50〜70％の節約になります。DPS は WSI データの自動バックアップをサポートし、データ保持ポリシーのガバナンスを容易にします。 デジタル病理学の次は？ 一般に、WSI の出力は、非圧縮画像の場合は2.5ギガバイト (GB) から10GB までさまざまです。病理検査ラボの一般的な作業負荷は、1日あたり約1,000枚の画像で、これは毎日生成される10テラバイト（TB）のデータに相当します。WSIの研究はGB単位の規模になることがあります。これは、デジタル画像検査の平均サイズが通常数十メガバイト（MB）から数百メガバイト（MB）である放射線画像検査などの他の専門分野とは対照的です。 SMC の病理検査部門全体が100％WSI を使用する方向に向かっているため、長期的にはクラウドベースの DPS の方がはるかに費用対効果が高い可能性があります。スライドのデジタル化により、SMC はさらなる革新と Amazon SageMaker を使った実験を計画しています。 SMC は、WSI での病理所見の検出を加速できる AI および ML アルゴリズムを構築する予定です。さらに、乳がんと前立腺がんに必要な面倒な悪性度判定プロセスを自動化して、病理医の臨床作業負荷を軽減したいと考えています。 世界的な労働力の高齢化により、 病理学は専門職の人員不足に直面しています。 しかし、 がんの診断数は増加しています。 したがって、病理学におけるデジタルトランスフォーメーションは、病院が今後数十年にわたって最適な状態で機能し続けるために不可欠です。クラウドネイティブなアプローチは、病院の情報システムに追加の資本的負担や運用上の負担をかけることなく、スタッフと患者の治療成績をサポートするのに役立ちます。 ヘルスケア向け AWS の詳細はこちら 世界中の医療機関や製薬企業は、連携の方法、データ主導の臨床および業務上の意思決定、精密医療の実現、医療費の削減の方法を改革しています。ヘルスケアおよびライフサイエンス組織がビジネス上および技術上の目標を達成できるように、AWS for Health は AWS のサービスと AWS パートナーソリューションを提供しており、世界中の何千ものお客様が使用しています。AWS が世界中の重要な医療ミッションをどのように支援しているかについての詳細は、 AWS for healthcare hubにアクセスする か、 AWS 公共部門チームにお問い合わせください。 AWS 公共部門ブログで関連記事を読む: Large scale AI in digital pathology without the heavy lifting Automating clinical lab workflow at scale for chronic disease monitoring with the cloud Alzheimer’s disease research portal enables data sharing and scientific discovery at scale Designing a biometric IoMT solution to support health equity with AWS ProServe AMILI helps advance precision medicine by building microbiome library on AWS Transforming radiology workflows with clinical decision support powered by AWS AWS Public Sector Blog ニュースレターを購読して 、公共部門の AWS ツール、ソリューション、イノベーションの最新情報をメールで受け取ることができます。または、 お問い合わせください。 このアンケートで AWS Public Sector Blog を使った感想をぜひお聞かせください。 アンケートからのフィードバックをもとに、読者の好みに沿ったコンテンツをさらに作成します。 MinSung Cho MinSung Cho は、韓国のアマゾンウェブサービス (AWS) ヘルスケアのリーダーです。彼は、Picture Archiving and Communication System（PACS）と電子医療記録（EMR）でヘルスケア企業のIT分野で10年以上の経験があり、GEヘルスケアでの前職からは医療用IoT（モノのインターネット）デバイスに関する8年以上の経験があります。 Dr. Sun Park Park 博士は神経内科医であり、医療業界で12年以上の経験を持ち、GEヘルスケア・コリアで6年間のデジタルイノベーションに携わってきた経験もあります。患者中心のケアと、病院のニーズを満たす適切なテクノロジーの導入に情熱を注いでいます。彼女は現在、韓国のアマゾンウェブサービス (AWS) の公的医療部門の事業開発業務を統括しています。 Dr. Petty Chen Chen 博士 は、アジア太平洋および日本 (APJ) の電子医療記録 (EMR) およびアマゾンウェブサービス (AWS) の病院エンゲージメントリーダーです。ハーバード大学で公衆衛生学修士（MPH）を、デューク国立大学医学部で医学博士（MD）を取得しています。ヘルスケアとテクノロジーの交差点で働く彼女は、人工知能（AI）と機械学習（ML）対応のソフトウェア開発における経験豊富なプロダクトリーダーであり、イノベーションの導入においてアジア全域の病院の責任者と緊密に協力してきました。 翻訳は Solutions Architect 窪田が担当しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 AWS Black Belt オンラインセミナーをご存じでしょうか？AWSではいろいろなイベント・セミナーを開催していますが、このBlack BeltシリーズはAWSのサービス単体にフォーカスして解説を提供するものです。このBlack Beltの先月分の内容が以下に公開されています。オンデマンドで過去のセミナーをいつでも閲覧できますし、PDFで資料もダウンロード可能になっていますので活用してください。 – 2023 年 7 月の AWS Black Belt オンラインセミナー資料及び動画公開のご案内 それでは、先週の主なアップデートについて振り返っていきましょう。 2023年8月14日週の主要なアップデート 8/14(月) AWS CodePipeline now supports GitLab フルマネージドの継続的デリバリーサービスである AWS CodePipeline でソースレポジトリとしてGitLab.comがサポートされました。GitLab.comの変更をもとにビルドパイプラインを実行することが可能です。 AWS IAM Identity Center integration is now generally available for Amazon QuickSight Amazon QuickSight が AWS IAM Identity Center (旧AWS SSO)との連携をサポートしました。これにより容易に IAM Identity Center 経由でのフェデレーションサインインでQuickSightへのログインを実現可能です。具体的な連携例としては こちらのブログを参照してください 。 8/15(火) Amazon OpenSearch Serverless expands support for larger workloads and collections Amazon OpenSearch Serverless が拡張され、時系列コレクションの最大インテックスデータが6 TBに増加し(以前は1 TB)、検索・時系列コレクションの最大OpenSearch Compute Units (OCU)数も最大100 OCU(以前は50 OCU)まで拡張されました。OCUはOpenSearch Serverlessの仮想的なコンピューティング性能値です。 Amazon Kinesis Video Streams improves image sampling frequency to 5 frames per second 動画のストリーミング分析サービスである Amazon Kinesis Video Streams で動画から画像の切り出し頻度がこれまでの3秒に1枚から、最大で1秒あたり5枚に改善され、より短い頻度での分析処理が実行可能になりました。 8/16(水) AWS Backup Audit Manager now supports delegated backup administrator AWS Backup Audit Manager で、backup administrator の権限をAWS Organizations内のユーザーに移譲できるようになり、より柔軟な運用に対応可能になりました。 Announcing general purpose Amazon EC2 M7a instances Amazon EC2 の M7a インスタンスが一般提供開始（GA）になりました。現在 Ohio、N. Virginia、Oregon、Irelandリージョンで利用可能です。M7a インスタンスは第四世代AMD EPYC プロセッサ(Genoa)を搭載し、前世代のM6aと比較して最大50%高いパフォーマンスを実現します。詳細は こちらのブログをご覧ください 。 Amazon EC2 D3en instances are now available in additional regions Amazon EC2 D3en インスタンスが利用可能なリージョンが拡大され、新たにTokyo、Frankfurt、Singaporeの3リージョンで利用可能になりました。D3enは最大で 336 TB のローカルHDDを搭載したインスタンスで、最大 75 Gbps のネットワーク帯域と7 Gbps のEBS帯域を提供します。 Amazon RDS now supports M6g and R6g database instances in six additional AWS regions Amazon RDS で AWS Graviton2ベースの M6g、R6gインスタンスが選択可能なリージョンが追加され、新たにOsaka、 Cape Town、Jakarta、Melbourne、Zurich、 Bahrain の6リージョンにおいて利用可能になりました。サポートされるDBエンジンはPostgreSQL、 MySQL、 MariaDB です。 同時にT4gインスタンスのリージョン拡張もアナウンス されており、大阪リージョンを含む前述のリージョンで利用可能になっています。 Amazon RDS Performance Insights provides an on-demand analysis experience Amazon RDS の Performance Insights に新しいメトリクスが追加されました。このリリースにより、選択した期間のパフォーマンスのデータを分析できます。たとえばアプリケーションがスローダウンした期間を分析して、データベースの動作が変化したかどうか、またどのように変化したかを確認したり、それを是正するためのアドバイスを得ることが可能です。この機能は Aurora MySQL、 Aurora PostgreSQL、 RDS for PostgreSQL で利用可能です。 8/17(木) Announcing Amazon EC2 Hpc7a instances Amazon EC2 の Hpc7a インスタンスが一般提供開始（GA）になりました。現在 Ohio、 GovCloud (US-West) リージョンで利用可能です。Hpc7a インスタンスは第四世代 AMD EPYCプロセッサ(Genoa)を搭載し、前世代のHpc6aと比較して最大2.5倍の性能を提供します。詳細は こちらのブログ をご覧ください。 Announcing Amazon GameLift support for instances powered by AWS Graviton3 processors 信頼性が高くスケーラブルなゲームサーバーホスティングを提供する Amazon GameLift で AWS Graviton3 プロセッサを搭載したC7gインスタンスが利用可能になりました。Graviton2 と比較して最大25%高いパフォーマンスを提供可能です。 Amazon FSx for NetApp ONTAP now provides additional performance metrics and an enhanced monitoring dashboard Amazon FSx for NetApp ONTAP に新しいCloudWatchメトリクスが追加され、新たにCPU使用率、SSDのIOPS等が確認可能になりました。詳細は こちらのドキュメント をご覧ください。 8/18(金) AWS Batch on Amazon ECS now supports AL2023 AWS Batch on ECS において、ECSに最適化された Amazon Linux 2023 (AL2023) AMIが選択可能になりました。AL2023は2028年3月までの長期サポートを提供しています。AL2023については こちらのブログを参照してください 。 AWS Audit Manager adds integration with Amazon EventBridge AWS Audit Manager で Amazon EventBridge との連携をサポートしました。Audit Managerのイベントを元にEventBrigde経由で、AWS Lambdaや AWS Step Functionsに連携することが可能です。 AWSのユーザーグループである JAWS-UG をご存じの方も多いと思います。ユーザーグループ主導で各技術領域や地域別にいろいろな勉強会やイベントが毎週実施されています。そのいろいろなイベントの予定について、 こちらのNote で定期的に情報がまとめられているのをご存じでしょうか？今週・来週にどういったイベントがあるのか一覧できるようになっているので、ユーザーグループの活動についてご興味がある方は参考にしてください。 それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (twitter – @simosako )

(本記事は 2023/01/27に投稿された Differences to expect when migrating from Azure Cosmos DB to Amazon DynamoDB を翻訳した記事です。) Azure Cosmos DBのワークロードを Amazon DynamoDB に移行することを検討しているお客様から、どのような違いが想定されるのかと聞かれることがあります。この記事では、Azure Cosmos DBからDynamoDBへの移行時に想定される相違点と、それに備えるための計画について説明します。DynamoDBは、一般的なアクセスパターン (通常は大量のデータの保存と取得) に合わせて最適化された、サーバーレスなキーバリュー型のデータベースです。DynamoDBではマルチリージョン、アクティブーアクティブなフルマネージドのデータベースであり、あらゆる規模で１桁ミリ秒という一貫したレイテンシー、保存時の暗号化、バックアップと復元、インメモリキャッシュを実現します。DynamoDBはイベント駆動型アーキテクチャの一部として一般的に使用されており、他のAWS サービスを使用することでDynamoDBの機能を拡張することができます。 用語とアーキテクチャの比較 Azure Cosmos DBとDynamoDBはどちらもNoSQLデータベースですが、移行を開始する前にアーキテクチャと用語の違いを考慮する必要があります。 DynamoDB Azure Cosmos DB テーブル Table コレクション Collection 項目（最大サイズは400 KB） Item (maximum size is 400 KB) ドキュメント（最大サイズは2 MB） Document (maximum size is 2 MB) 属性 Attribute フィールド Field プライマリーキー：パーティションキー Primary key: Partition key パーティションキー Partition key プライマリーキー：ソートキー（任意） Primary key: Sort key (optional) 複合プライマリーキー：プライマリーキー + 追加フィールド Composite key: Partition key + additional fields 複合プライマリーキー：プライマリーキー + ソートキー Composite key: Partition key + Sort key 複合プライマリーキー：プライマリーキー + 追加フィールド Composite key: Partition key + additional fields ローカルセカンダリインデックス（LSI） ：パーティションキーはメインテーブルと同様で、ソートキーと非キー属性が異なる Local secondary index (LSI) : Same partition key as the main table but different sort key and non-key attributes 複合プライマリーキー：プライマリーキー + 追加フィールド Composite key: Partition key + additional fields グローバルセカンダリインデックス（GSI） ：メインテーブルとは異なるパーティションキーとソートキーおよび非キー属性 Global secondary Index (GSI) : Different partition and sort key than in the main table and non-key attributes 複合プライマリーキー：プライマリーキー + 追加フィールド Composite key: Partition key + additional fields Amazon Kinesis Data Stream と Amazon DynamoDB Streams Amazon Kinesis Data Streams and Amazon DynamoDB Streams 変更フィード Change Feed 1 RCU: 1 つの読み込みキャパシティーユニットは、強力な整合性を実現するには 1 秒あたり4KB、結果整合性を維持するために 1 秒あたり8KB One RCU: One read capacity unit is 4 KB per second for strong consistency and 8 KB per second for eventual consistency.1 WCU: 1 つの書き込みキャパシティーユニットは 1 秒あたり1KB One WCU: One write capacity unit is 1 KB per second. 1 RU: 要求ユニット (読み取りの場合、1 KBで) One RU: Request unit (1 KB for read)5 RU: 要求ユニット (書き込みの場合、1 KBで) Five RU: Request unit (1 KB for write) 複数のパーティションとテーブルにわたる トランザクションサポート Transaction support across multiple partitions and tables パーティション内のみのトランザクションサポート Transaction support only within a partition Amazon DynamoDB Accelerator (DAX) による読み取り時の応答時間をマイクロ秒で実現 Amazon DynamoDB Accelerator (DAX) for microsecond response time on reads 利用不可 Not available 使用可能なモード: プロビジョンド、オートスケーリング、オンデマンド Available modes: provisioned, autoscaling, and on-demand 使用可能なモード:プロビジョンド、オートスケーリング、サーバーレス Available modes: Provisioned, autoscaling, and serverless 保存時と転送時の暗号化 Encryption at rest and in transit 保存時と転送時の暗号化 Encryption at rest and in transit 論理パーティション Logical partitions 論理パーティション Logical partitions API サポート:DynamoDB API と PartiQL API support: DynamoDB API and PartiQL APIサポート：Core (SQL)、Cassandra、Gremlin、MongoDB、TableおよびPostgreSQL API support: Core (SQL), Cassandra, Gremlin, MongoDB, Table, and PostgreSQL 表 1: DynamoDB と Azure Cosmos DB の用語とアーキテクチャの比較 （注：より理解しやすいように本文の英語を併記しています） Amazon DynamoDB テーブル、スキーマ、およびインデックス 移行をシンプルにするため、Azure Cosmos DBのコレクションとDynamoDBのテーブル間を１対 １でマッピングするようにしてください。DynamoDBにはデータベースの概念はなく、テーブルと呼ばれるエンティティがあります。Azure Cosmos DBのコレクションに基づいてDynamoDBのテーブルを作成する場合： カーディナリティの高いパーティションキーを選択します。DynamoDBはパーティションキーの値を内部ハッシュ関数への入力として使用します。ハッシュ関数の出力によって、項目が保存されるパーティションが決まります。各項目の場所は、そのパーティションキーのハッシュ値によって決定されます。ほとんどの場合、同じパーティションキーを持つ項目は項目コレクションにまとめて格納されます。項目コレクションは、パーティションキーは同じでソートキーが異なる項目のグループとして定義されます。複合プライマリキーを含むテーブルでは、ソートキーはパーティションの境界として使用できます。DynamoDBは、コレクションサイズが10 GBを超えると、仮想的なパーティションをソートキーごとに分割します。ソートキーを使用してAzure Cosmos DBのプライマリ複合インデックスを置き換えることもできます。パーティションキーを選択する方法の詳細については、「 Choosing the Right DynamoDB Partition Key 」を参照してください。 同じパーティションキーと異なるソートキーを必要とするクエリパターンの場合では、非キー属性とともに、メインテーブル作成時にGSIまたはLSIを作成できます。GSIは、非キー属性とともに、テーブルの作成中または作成後でも作成することができます。 注: GSIが推奨されるオプションです。LSIを使用する場合、１つのパーティションキー値に対するインデックス項目の合計サイズが 10GB を超えることはできません。 プライマリキーとソートキーが異なるクエリパターンには、GSIを使用することが推奨されます。GSIはメインテーブルの作成中または作成後に、非キー属性とともに作成することができます。 Amazon Simple Storage Service (Amazon S3) から DynamoDB データをインポート する場合、インポート中にGSIが追加されます。ローカルおよびグローバルセカンダリインデックスは、一度定義されると、DynamoDBによって自動的に管理されます。セカンダリインデックスを使用すると、ベーステーブルと比較してデータサイズを削減するのに役立ちます。セカンダリインデックスのサイズが小さくなるかどうかは、使用される非キー属性の数によって異なりますが、プロビジョニングされたスループットのパフォーマンスを向上させるのに役立ちます。プロビジョニングモードのテーブルにGSIを作成する場合、そのインデックスに予想される負荷に応じて読み取りと書き込みキャパシティーユニットを指定する必要があります。GSI上でのクエリ操作は、ベーステーブルではなく、インデックスから読み取りキャパシティユニットを消費します。テーブル内の項目を追加、更新、削除すると、そのテーブルのグローバルセカンダリインデックスは非同期で更新され、インデックス更新は、ベーステーブルではなくインデックスの書き込みキャパシティーユニットを消費します。テーブル属性をGSIに投影する場合は、新しい更新がベーステーブルとGSIの両方に書き込みを行うため、プロビジョニングされた書き込みキャパシティーユニットをベーステーブルの書き込み容量と同等かそれ以上の値に設定することを推奨します。なお、GSIの更新には ２つの書き込みが必要となり、１つは、インデックスから前の項目を削除する書き込み、もう１つはGSIのパーティションキーまたはソートキーである属性を更新する際に、新しい項目をインデックスに追加するための書き込みとなります。 Azure Cosmos DBは、２つ以上のプロパティを持つ複合インデックスをサポートしています。ソートキーを連結して DynamoDBプライマリキーとセカンダリインデックスにマッピングできます。例えば、Azure Cosmos DBのEmployee ID、Country、State、Cityの各フィールドが複合キーとして定義されている場合、DynamoDB では、Employee IDをパーティションキー、ソートキーを country#state#city に置き換えます。なお、ソートキーの#はユーザー指定の区切り文字で、コロン（:）、カンマ（,）、チルダ（~）などの他の区切り文字に変更できることに注意してください。 DynamoDBはAzure Cosmos DBのデータ型をサポートしているほか、バイナリとセットのデータ型もサポートしています。Azure Cosmos DBからDynamoDBへの属性マッピングについては、表２を参照してください。 DynamoDB Azure Cosmos DB DynamoDB description Number Number 38桁の精度を持つ数値 String String UTF-8バイナリエンコードによるUnicode Boolean Boolean True or False List Array 順序付きの値のコレクション Map Object 順序なしの名前と値のペアのコレクション。Azure Cosmos DBのフィールドにある深くネストされたJSONデータには、このDynamoDBデータ型を使用してください。 Set Not supported 数値、文字列、バイナリなどの同じデータ型のコレクション Binary Not supported 圧縮されたテキスト、画像、または暗号化されたデータ 表 2: DynamoDB 属性マッピング DynamoDBインデックスはAzure Cosmos DBとは異なります。Azure Cosmos DBは転置インデックスを使用しますが、DynamoDBはテーブルパーティションとインデックスパーティションにハッシュアルゴリズムを使用します。Azure Cosmos DBのネストされたJSONインデックスを移行する場合、Azure Cosmos DBのインデックス付き属性は DynamoDB のプライマリキー、LSI、または GSIの一部である必要があります。ネストされたインデックス化されていないオブジェクトをマップデータ型として追加できます。 DynamoDBにはAzure Cosmos DBストアドプロシージャやユーザー定義関数と同等のものはありませんが、 AWS Lambda またはDynamoDB StreamsとLambdaの組み合わせを使用して同等の機能を実行することは可能です。DynamoDBクライアントはDynamoDBデータの事後後処理に責任を持ちます。 キャパシティユニット DynamoDBには、読み取りキャパシティーユニット (１つの RCU は、強力な整合性のある読み取りでは1秒あたり4KB、結果整合性のある読み取りでは 8KB/秒) と書き込みキャパシティーユニット (1 WCU はDynamoDBテーブルへの書き込みで1秒あたり1KB) があります。DynamoDBの RCUとWCU の要件を把握するには、DynamoDBをオンデマンドモードで実行することをお勧めします。移行を完了する前にオンデマンドモードでテーブルの負荷テストを実行することで、アプリケーションとテーブルがライブトラフィックに最適化されていることを確認できます。トラフィックパターンが急上昇するような場合には、引き続きDynamoDBオンデマンドモードの使用を継続します。予測可能なトラフィックパターンでは、負荷テストのベースラインを使用してプロビジョニングされたキャパシティを設定します。DynamoDBがアプリケーショントラフィックの増加に合わせてスケールすることができ、プロビジョニングされたスループットが不十分であることによるエラーを回避できるようにするために、プロビジョニングされたキャパシティーでオートスケーリングを使用することを推奨します。 グローバルテーブル の場合、書き込みキャパシティーの設定は、使用する各リージョンのレプリカテーブルとセカンダリインデックス全体で一貫して設定する必要があります。また、グローバルテーブルのレプリカの読み込みキャパシティー設定は、リージョンの読み取り要件に基づいている必要があります。 有効期限 (TTL) Azure Cosmos DBの有効期限（TTL）設定をDynamoDBに移植できます。Azure Cosmos DBのTTL（秒単位）をDynamoDB のエポックタイムに変換する必要があります。 DynamoDB TTL では、項目ごとにタイムスタンプを定義して、項目が不要になる時期を判断できます。項目が不要になったことを示すタイムスタンプから 48時間以内 に、DynamoDB は書き込みスループットを消費せずにその項目をテーブルから削除します。TTL は、ワークロードのニーズに合わせて最新の項目のみを保持することで、保存されるデータ量を削減する手段として、追加コストなしで提供されます。 DynamoDBのきめ細かなアクセス Azure Cosmos DBには、ロールベースのアクセス制御（RBAC）が組み込まれています。DynamoDBは、 AWS Identity and Access Management（IAM） を使用して、 項目および属性レベルでのきめ細かなアクセス を提供します。IAMポリシーは、DynamoDBのテーブルに格納された項目や属性へのアクセスを制御します。以下は、きめ細かいアクセス制御の２つの例です。 ユーザーの位置情報に基づいて近くの空港の情報を表示するモバイルアプリ。アプリは、航空会社名、到着時刻、フライト番号などの属性にアクセスして表示することができます。ただし、パイロットの名前や乗客数にアクセスしたり表示したりすることはできません。 ユーザーのハイスコアを１つのテーブルに保存するモバイルゲーム。各ユーザーは自分のスコアを更新できますが、他のプレイヤーのスコアを更新することはできません。 マイクロ秒単位のパフォーマンスを実現するAmazon DynamoDB DAX Azure Cosmos DBの読み取り時でマイクロ秒のレスポンスにサードパーティのキャッシュソリューションを使用している場合、 Amazon DynamoDB Accelerator（DAX） を使用することもできます。DAXを使用すると、コードをリファクタリングすることなくキャッシュソリューションを組み込むことができます。DAXは、DynamoDBのための結果整合性のあるライトスルーキャッシュレイヤーです。DAX は、必要に応じてリードスルーモード、ライトスルーモード、またはライトアラウンドモードで使用することができます。 Azure Cosmos DB変更フィードをDynamoDBに再設計する Azure Cosmos DBは、Azure Cosmos DBの変更フィードを使用して他のAzureサービスに変更を伝搬します。DynamoDBには、 変更データキャプチャ（CDC） 用に Amazon Kinesis Data Streams と Amazon DynamoDB Streams という２つのストリーミングオプションがあります。それぞれのストリーミングオプションは、以下で説明するユースケースに対応しています。 Kinesis Data Streamsは、ログデータのキャプチャ、リアルタイムメトリックスとレポート、リアルタイムデータ分析、複雑なストリーム処理などのユースケースに使用します。データストリームは、レコードの順序付けや重複が重要ではない場合に使用します（最終的な宛先で重複を処理し、冪等性のある処理を実現することができます）。たとえば、 Amazon OpenSearch Service では、複数のコンシューマーが無制限のスループットでストリームを並行処理する必要がある場合や、24時間を超えるデータ保持が必要な場合に、バージョニングと一意のIDを組み合わせて処理の重複を防ぐことができます。 DynamoDB Streamsは、時系列の変更ストリームをキャプチャし、この情報を最大24時間ログに保持します。その後、アプリケーション内から DynamoDB Streams Kinesis Adapter とDynamoDB Streams APIを使用して、専用のエンドポイントからデータレコードを読み取ることができます。また、Lambdaを自動スケーリングで使用してDynamoDB Streamsのデータを処理することもできます。 DynamoDB Streamsを使用する場合、ストリーミングデータを利用するには Kinesis Adapterが推奨されます。DynamoDB Streams Kinesis Adapterは、アプリケーションに代わって シャード管理 （シャードの有効期限と分割）を自動化します。また、「 DynamoDB Streams Kinesis Adapter を使用したストリームレコードの処理 」に記載されている、その他の利点もあります。Lambdaを使用してDynamoDBの追加、更新、削除イベントを開始できます。Azure Cosmos DBトリガーの代わりに DynamoDB StreamsとLambdaトリガーを使用することを検討してください。 DynamoDB Streamsの使用方法の詳細については、「 DynamoDB Streams Use Cases and Design Patterns 」を、Kinesis Data Streamsと DynamoDB Streamsの詳細な比較については DynamoDB ドキュメント を参照してください。 400 KB を超える項目の処理 DynamoDB の最大項目サイズは400KB で、これには属性名のバイナリ長 (UTF-8の長さ) と属性値の長さ (バイナリの長さ) の両方が含まれます。DynamoDBでは、400KBを超える項目に対して、GZIPなどの圧縮アルゴリズムを使ってから項目を挿入したり、大きな項目を複数の小さな項目に分割したりすることができます。また、これらの大きなオブジェクトをS3バケットに保存し、S3オブジェクトのURLを属性としてDynamoDBテーブルに保存することもできます。このアプローチでは、DynamoDBのインデックスを使用して高速な検索を行い、S3を耐久性が高く費用対効果の高いオブジェクトストアとして使用できます。 例として、あるアプリケーションが従業員の記録（名前、住所、その他の情報）を管理し、各従業員の600×400ピクセルの画像も保存する必要があるとします。この場合、1人の従業員の項目サイズが 400 KB の制限を超えています。さらに、ユーザーは従業員の項目がDynamoDBに追加されたら、すぐに人事アプリケーションを更新する必要があります。画像のURLを従業員の項目の属性として保存し、イメージを S3 バケットに保存できます。DynamoDB Streamsを使用してLambda関数を起動し、人事アプリケーションを更新できます。以下の図 1 は、このアプローチを示しています。 図１：大きなアイテムサイズを扱うためのアーキテクチャ この記事に記載されているソリューションオプションの詳細については、「 Large object storage strategies for Amazon DynamoDB 」と「 Use vertical partitioning to scale data efficiently in Amazon DynamoDB 」を参照してください。 グローバルテーブルとリージョナルテーブル DynamoDBグローバルテーブルは、独自のクロスリージョンレプリケーションソリューションを構築、維持することなく、マルチリージョン、アクティブーアクティブデータベースを展開するためのフルマネージドソリューションです。テーブルを利用したいリージョンを指定することができ、DynamoDBはそれらのリージョンを介して継続的なデータ変更をテーブルに伝搬します。これにより、ユーザーがどこにいても、低レイテンシーのデータアクセスが可能になります。Azure Cosmos DBのグローバルデータレプリケーションの代わりに DynamoDBグローバルテーブルを簡単に使用することができます。 DynamoDB はレプリカと同期するための非同期レプリケーションを提供し、通常1秒未満でリージョン間のレプリケーションを行います。レプリカの競合が発生した場合、DynamoDBグローバルテーブルでは、ベストエフォートで最終書き込み者優先が使用されます。DynamoDBグローバルテーブルは、グローバルに分散したユーザを持つ地理的に分散したアプリケーションに最適です。 Amazon DynamoDBのバックアップとリストア機能 DynamoDB には、データをバックアップおよびリストアするためのオプションがいくつかあります。 ポイントインタイムリカバリ（PITR） を使用すると、偶発的なDynamoDBテーブルへの書き込みや削除から保護することができます。PITRは継続的にデータをバックアップするので、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス（AWS CLI） 、または DynamoDB API を使用して、過去35日間の任意の時点にテーブルをリストアできます。PITRを使用することで、オンデマンドバックアップの作成、管理、スケジュールについて心配する必要はありません。また、DynamoDB のオンデマンドバックアップ機能を使用して、テーブルのフルバックアップを作成し、長期保存したり、コンプライアンスの対応に合わせてアーカイブを作成することができます。PITRとオンデマンドバックアップはどちらも、テーブルのパフォーマンスや APIレイテンシーには影響を与えません。 Azure Cosmos DB データを DynamoDB に移行 Azure Cosmos DBからDynamoDBへのデータ移行は以下の手順で行います。 Azure Azure データエクスプローラー を使用して CSV 形式でデータをエクスポートします。 データがCSV形式になったら、 AWS Database Migration Service (AWS DMS) を使用して DynamoDB に移行します。AWS DMS に関するチュートリアルについては、「 Migrate Delimited Files from Amazon S3 to an Amazon DynamoDB NoSQL Table Using AWS Database Migration Service and AWS CloudFormation 」を参照してください。 DMSを利用してデータを同期させます。 AWS Glue を使用してCosmos DBを移行できます。詳細については、「 Migrate from Azure Cosmos DB to Amazon DynamoDB using AWS Glue 」を参照してください。 Amazon S3 からテーブルデータをインポートすることもできます。詳細については、「 Amazon DynamoDB can now import Amazon S3 data into a new table 」を参照してください。 まとめ この記事では、Azure Cosmos DBとDynamoDBの関連する機能の違いと、移行時に考慮すべきアーキテクチャパターンについて説明しました。相違点はあるものの、それに適応するための方法があります。グローバルセカンダリインデックスのシャーディングとインデックスの過負荷への戦略、マテリアライズドクエリを使用したスケーラブルなグラフ処理、複合キーを使用したリレーショナルモデリング、そして、DynamoDBでのトランザクションワークフローの実行に関する詳細情報は「 DynamoDB Deep Dive: Advanced Design Patterns 」を参照してください。 質問や提案がある場合は、コメントを残してください。 著者について Utsav Joshi はAWSのプリンシパルテクニカルアカウントマネージャーです。ニュージャージー州在住で、AWSのお客様と協力してアーキテクチャ、運用、およびコスト最適化の課題を解決することを楽しんでいます。余暇には、旅行、ロードトリップ、子供たちとの遊びを楽しんでいます。 Joydeep Dutta はAWSのシニアソリューションアーキテクトです。Joydeepは、AWSのお客様と協力してワークロードを AWS クラウドに移行し、コストを最適化し、アーキテクチャのベストプラクティスを支援することを楽しんでいます。彼は、企業のコストと複雑さを軽減するのに役立つエンタープライズアーキテクチャに情熱を注いでいます。彼はニュージャージー州に住んでおり、余暇には音楽を聴いたり、屋外で過ごしたりしています

前回の記事 では、ストアコンピュータや、POS といった店舗に配置されているワークロードを AWS で稼働させるにあたってのメリットや構成について可用性と応答性能に焦点をあてて考察しました。本記事では、AWS クラウドに移行後のアーキテクチャと、実現に向けたアプローチについて考察します。 アーキテクチャとして検討すべき対象範囲 店舗システムをクラウド化するメリットとして、前回の記事では以下のメリットを述べました。 コスト削減（ストアコンピュータレス） 運用効率化（システム集約化、ハードウェアライフサイクルからの解放） 機能の高度化（データ活用のし易さ、ハードウェアリソース制約からの解放） 最後の機能の高度化について、店舗システムということで、POS や検品や陳列、発注やスタッフ管理といった店舗業務が検討範囲であることは言うまでもありませんが、”顧客の購買体験を提供する店舗” として考えた場合、購買体験がテクノロジーの進歩と共に変わっていることは、顧客でもある皆様はご理解いただけるのではないでしょうか。 以前：顧客の購買体験は店舗で完結 現在：顧客の購買体験は店舗で完結するわけでなく、ECやモバイルなどをまたがっている（例えばモバイルオーダーで注文して店舗で受け取る、フードデリバリーのように顧客は店舗に来店しないが店舗が介在する） 図1：購買体験の変化 購買体験が変化すると、店舗オペレーションや店舗システムも対応する必要があります。従って、アーキテクチャを考えるにあたり、既存業務の継続はいうまでもありませんが、絶えず変化する顧客ニーズや購買体験の変化に対応できるアーキテクチャが求められます。つまり、下図のような店舗システムにおける主要な機能とデータの配置を、そのままクラウドに移行することはできますが、変化により対応しやすいアーキテクチャに変更する契機と捉えることもできます。 図2：店舗システムと連携先システム 多様で変化する顧客ニーズに統一的な体験を提供するユニファイドコマース 絶えず変化する顧客ニーズや購買体験の変化に対して、リアル店舗やアプリケーションを含めた統一した体験を提供する ユニファイドコマース を通して顧客体験を向上させることに取り組まれています。小売業者がリアル店舗、EC サイトなど複数の販売チャネルを消費者に向けて用意する販売戦略がオムニチャネル戦略ですが、それぞれのチャネルにおいて消費者へ “統一された ( Unified ) ” 購買体験を提供することを目指す考え方がユニファイドコマースです。 ユニファイドコマースを実現するにあって、統一された顧客体験を提供するため、顧客との接点であるモバイルアプリ、店頭のタブレット、店舗の POS 端末など、様々なチャネルから顧客の行動履歴やオペレーションのデータをリアルタイムで受け取る必要があります。そして、チャネルが様々であっても、注文や在庫などの複数の拠点から随時更新される情報は最新の正しい値を特定できるようにデータを一元管理し、各チャネルからのリクエストに応じて共通のコマース機能を通してリアルタイムに情報を返す必要があります。 図3：ユニファイドコマース実現イメージ アーキテクチャは、多くの小売業者が注目している MACH (Microservices-based, API-first, Cloud-native SaaS, Headless) アーキテクチャを取り入れることで実現できます。ビジネスの機能別に開発できるようなマイクロサービスで設計し、機能間の連携は API を通して行い、クラウドの柔軟性やスケーラビリティを活用し、フロントエンドはヘッドレスな設計にすることでバックエンドのロジックと切り離して疎結合とする、という原則に基づいたアーキテクチャです。 図4：MACH アーキテクチャによる実店舗と EC が連携するアーキテクチャイメージ ユニファイドコマースを実現するにあたってのガイダンス AWS は、ユースケース別の AWS ベストプラクティスに基づく設計や実装として、AWS Solutions / Solutions Guidance / AWS Samples を用意してます。これらを利用することによって、全てを 1 から考えて自社向けに開発して、他社との差別化にならない部分に時間とお金を投資することを避けられます。 ユニファイドコマースについては、Solutions Guidance（ソリューションガイダンス）が用意されていて、「 AWS でのユニファイドコマースに関するガイダンス 」を参考にできます。 図5：アーキテクチャ図 詳しくは、ソリューションガイダンスのウェブページに加えて、本ソリューションガイダンスを解説しているこちらのブログ（ ビジネスアジリティを加速する AWS のアーキテクチャ part 2 – Unified Commerce on AWS ）にまとめられていますが、MACH アーキテクチャの原則に則っています。 店舗システムの移行にあたってのコンポーザブルアプローチ 店舗システムは、様々な業務機能やデータから構成されています。ストコン や POS といった機器に分かれているものの、長年運用していると、初めは別々に作られていた機能が、相互に関連し合う、いわゆる密結合となっていることは起こり得ます。また、クラウド移行後のユニファイドコマース、MACH アーキテクチャを紹介しましたが、今後を見据えてアーキテクチャを変更するものもあれば、差別化にはならないためそのまま移行するものもあります。 店舗業務の分類 業務システムに対する期待 システム/機能の例 移行方針の例 接客・販売 多様で変化する顧客ニーズに素早く対応することが期待される POS セルフレジ、スマフォレジを展開をしやすくするためアーキテクチャを変更する 在庫 モバイルオーダー、フードデリバリーとの連携をしやすくするためアーキテクチャを変更する バックヤード・店舗管理 接客・販売に注力できるための効率化が、業務だけでなくシステム面でも期待される 検品 既存機能を踏襲するので単純移行する スタッフ勤怠管理 開発と運用の負担を軽減するため SaaS を利用する 1 回で移行するビッグバンアプローチは、シンプルではあるものの移行失敗時による変革のリスクがありますが、共通のコマースメカニズムをマイクロサービスで提供するユニファイドコマースにおいては、必要となる仕組みを段階的に組み立てていくコンポーザブルアプローチにより、リスクの軽減を図りつつ、すばやく実現していくことができます。 密結合となっている、結果として一枚岩（モノリス）なアプリケーションを段階的に移行する設計パターンとして、ストラングラーフィグパターンを利用することができます。利用できるケースや考慮事項、実装といった詳細については、AWS の規範的ガイダンスのクラウドの設計パターン、アーキテクチャ、実装にまとめられています（ こちら ）。 この他、モノリスのアプリケーションからマイクロサービスとして機能を切り出すにあたっては、AWS の規範的ガイダンスの モノリスをマイクロサービスに分解 に、ビジネス能力別に分解、サブドメインによる分解、トランザクションによる分解、チームごとのサービスパターンなどの各パターンの利点と欠点を含む特徴がまとめられているので参考になります。さらに、マイクロサービス間でデータを永続化するためのパターンについては、 マイクロサービスにおけるデータ永続性の実現 にまとめられています。 まとめ 本記事では、店舗システムの AWS クラウドに移行後のアーキテクチャと、実現に向けたアプローチについて考察しました。顧客の購買体験を提供する店舗として、店舗に限らない各販売チャネルで統一した体験を提供するユニファイドコマースとして検討していく必要性と、ユニファイドコマースを実現する MACH アーキテクチャを紹介し、AWS より提供するソリューションガイダンスや規範的ガイダンスを利用することで、1 から考える必要がなく、実現に向けて迅速に進められることを説明しました。 コンビニエンスストアやスーパーマーケットなど多店舗展開している小売業では、どの機能からどのような移行方針で進めるか、という観点だけではなく、全店舗一斉に切り替えるのか、あるいは地域や店舗形態などの分類単位より段階的に切り替えるのか、という観点も考える必要があります。本記事によって、店舗システムのクラウド化にあたって考えなければならないことが減り、それによりクラウド移行が促進され、結果としてビジネスの成長につながれば幸いです。

しばしば組織の「個性」と表現される組織文化は、人々の働き方、相互作用、変化や課題への対応を決定します。組織の文化が変革の成功を左右する強力な要因であるという認識は、 エビデンス にも裏付けられています。文化の影響は、クラウドの変革においてさらに大きくなります。というのも、クラウドの機能がいかに有用だとしても、その実際の有用性は人々がどのように使うかによって決まるからです。 しかしながら、組織文化が存在し、従業員の行動を形成するということに誰もが同意するとしても、それは主観的で無形のものです。組織文化は、Well-Architected なシステムのように、意図して思慮深く設計および構築することは可能でしょうか？ この記事では、ビジネスの成果を達成するためにクラウド導入を加速する適切な組織文化を構築するためのベストプラクティスを提供します。 なぜクラウド導入に適した組織文化が重要なのか？ クラウドは、コスト削減、業務のアジリティ向上、運用の強靭性、スタッフの生産性向上など、多くの利点を提供しています。クラウドは急速に成長し、広く運用されているにもかかわらず、クラウドサービスのもたらす価値の実現において他の組織よりも成功している組織があります。 私たちのお客さまは、クラウドを利用して企業のデジタル変革を推進する上で、非技術的な要因、特に文化的変革が最大の課題だと述べています。すべての組織には既存の文化があります。文化には、クラウドへの対応を助ける側面もあれば、中立的な側面もあり、はたまた対立する側面もあります。成功している企業は、文化的な手段を活用して潜在的な問題点を特定して対処することで、クラウド導入を加速させています。 たとえば、クラウド導入を成功させるには、セルフサービスと再利用を重要視するオープンで協力的な文化が必要です。クラウドによって、企業は完璧さよりもスピードを優先するようになります。考えられるすべての結果に対して過度に分析する必要はありません。実験が奨励され、従業員は 試行錯誤 を通じて学ぶことができます。一方、指揮統制に基づいて意思決定を行う階層的な文化を持つ組織は、イノベーションを阻害し、クラウド導入における課題に直面する可能性があります。 組織文化の構築（アーキテクティング） 本来、または目的があって、すべての組織には文化があります。成功する企業文化は偶然の産物ではなく、慎重かつ意図的に構築されたものです。文化にはある程度の自発性と予測不可能性があるかもしれませんが、目的意識のある行動によっても影響を受け、形成されることもあります。 お客さま中心の文化 ：クラウドプラットフォームは、ビジネスソリューションを構築するための既製のビルディングブロックを提供します。お客さま中心の文化を促進することで、チームは「 他社との差別化につながらない面倒な重労働 」を省き、IT 内部ではなくビジネス価値とイノベーションに集中できるようになります。お客さま中心の文化は、お客さまのニーズ、嗜好、および行動を深く理解することを含みます。Amazon ではこれを「 Working Backwards 」（お客さまを起点に考え行動する）と呼んでいます。すべてのレベルの従業員がお客さまの満足を優先し、積極的にフィードバックを求め、お客さまからいただいた洞察に基づいて製品とサービスを改善するよう奨励されるべきです。 模範となるリーダーシップの文化 ：CEO はしばしば企業の文化、価値観、および長期的な目標を定義する一連の原則を実施します。これらの原則は、従業員に一体感をもたらすのに役立ちます。ただし、真に効果的なものであるためには、これらの原則が示されるだけでなく、組織のあらゆるレベルで実践される必要があります。リーダーは、「なぜクラウドなのか？」を明確に説明する中で、定義され、測定可能で、期待されるビジネス成果を伝える必要があります。変革をもたらすリーダーは、クラウド戦略の設定と伝達において、「これが私たちの未来です。そのためのロードマップがあり、その道のりを成功させるために必要なリソースを提供します。」と企業自身、自分たちの事業に対して伝えます。信頼を育み、リソースを提供し、自律性とコラボレーションを促進することで、リーダーは従業員が主体性を発揮し、前向きな変化を推進できるよう支援します。また、従業員が叱責を恐れることなく問題をエスカレーションできるオープンで安全な環境も醸成します。 データ駆動の意思決定文化 ：今日の意思決定には、固定的なオペレーション情報だけでなく、次のステップや将来の見通しをリアルタイムで分析する必要があります。クラウドは、事業において戦略的意思決定を行うために膨大な量のデータを処理するための強力な人工知能（AI）および機械学習（ML）ツールを提供します。クラウド導入のメリットを最大化するには、データを使用して情報を提供し、優先順位を付け、意思決定の指針を決めることに重点を置く、データ駆動の意思決定文化が必要です。たとえば、製造業ではクラウドベースの AI と ML ツールを使用してセンサーデータを分析し、ダウンタイムを最小限に抑え、コストを削減するためのメンテナンスを予測しスケジュールすることができます（予知保全）。データ駆動の意思決定文化を実施することで、予知保全分析からの得た知見を活用してメンテナンスタスクを優先順位付けし、リソースを効率的に割り当てることができます。 アジリティ、イノベーション、実験、リスクを取る文化 ：クラウドコンピューティングはアジャイル開発文化に適しています。それは実験、柔軟性、インクリメンタル（段階的）な提供の原則に基づいています。クラウドネイティブ技術は、サービス提供に影響を与えることなく、システムの迅速かつ頻繁な変更をサポートします。アジャイル開発アプローチでは、完璧よりもスピードが重視されます。望ましくない結果が発生した場合に、実行してはいけないアクションを知っておくことには価値があります。たとえば、Amazon では、 リーダーシッププリンシプル を指針として誘導し実行するためのメンタルモデルを使用しています。「Bias for Action」はその指針の 1 つで、「ビジネスにおいてスピードが重要です。多くの決定と行動は元に戻せるため、詳細な調査は必要ありません。計算されたリスクテイクを大切にします。」と述べています。 継続的な学習の文化 ：これは、従業員がクラウドの環境に対応するスキルと知識を持つことを確実にするために、組織が従業員のトレーニングと教育を優先する必要があることを意味します。これにはクラウドサービスに関する技術的なトレーニングだけでなく、コミュニケーションやコラボレーションといったソフトスキルを含みます。学習は自助努力で為すべきであり、イベント駆動のものでは成り立ちません。組織全体で絶え間なく学ぶためには、測定と報酬の仕組みが必要です。トレーニングだけでなく、クラウドの経験が豊富な従業員が新しいチームメンバーを指導するための社内メンターシッププログラムを設立することもできます。 再利用の文化 ：クラウドの価値を高めるためには、ソフトウェア資産の再利用が必要です。再利用により、組織は既存の実証済みで信頼性の高いソフトウェアコンポーネントを活用して、効率性の向上、コスト削減、市場投入までの時間の短縮を実現できます。たとえば、従来のソフトウェア開発者はインフラストラクチャリソースの複雑さを理解するのに時間を費やし、ビジネス価値を提供するソフトウェアの構築に充分な時間を割くことができませんでした。クラウドでは、 Infrastructure as Code (IaC) を使用することで、開発者は事前に構築されテストされた再利用可能なテンプレートを選択し、ソフトウェアアプリケーションを構築するために必要なインフラストラクチャコンポーネントを自動的にプロビジョニングします。再利用の文化には、個人が自分の知識、経験、リソースを他者と積極的に共有できる、オープンで協力的な考え方が必要です。 自動化とセルフサービスの文化 ：クラウド導入には、クラウドの強力な自動化ツールとセルフサービス機能を活用したリソースの提供、管理、利用が含まれます。セルフサービスには、従業員が信頼されて権限を持ち、自らのタスクに責任を持つような文化の変革が必要です。たとえば、オンプレミス環境では、アプリケーションチームは通常、IT インフラストラクチャチームにインフラのプロビジョニングを依頼します。クラウドでは、チームは自分自身で（セルフサービスで）自動化プロセスを通じてインフラをプロビジョニングします。これにより、開発者は自由になり、チケット処理を待つ代わりにビジネス価値を提供するための時間を増やすことができます。クラウド導入には集中的かつ組織的な取り組みが必要ですが、これを推進する Cloud Centre of Excellence (CCoE) が役立つ場合があります。この多種専門的なチームは、クラウドポリシー、ベストプラクティス、トレーニング、アーキテクチャを反復可能で自動化された、セルフサービス型の方法で提供することで、企業の成熟度を高めることができます。 セキュリティとコンプライアンスの文化 ：クラウド導入ではセキュリティとコンプライアンスに関する新たな考慮事項が生じます。組織はクラウド環境におけるデータ保護、プライバシー、および規制遵守を優先する必要があります。セキュリティとコンプライアンスに重点を置いた文化は、 責任共有 の意識を持つことで、セキュリティ対策がクラウド導入のあらゆる側面に統合されることを保証します。 ガバナンスの文化 ：クラウドサービスの利用を開始するのは容易になりましたが、企業のクラウド導入はより複雑になりました。適切なガバナンスがないと、クラウドの利用がすぐに制御を失う可能性があります。クラウドでは、インフラストラクチャの容量が「固定」から「無制限」に変わりますし、コストモデルも固定費から変動費（pay-as-you-go；従量課金）に変わります。これにより価値を提供するのに必要なアジリティは提供されるものの、シャドウ IT や経緯が不明のコストが発生することがあります。ここでクラウドガバナンスの文化が重要となります。ガバナンスの文化は、組織がクラウドの利用を管理し制御するために実施する一連のポリシー、手順、プロセスです。それはリアルタイムで自動化された「ガードレール」を通じてアジリティを維持しながら統制力を犠牲にすることなく実施されます。 おわりに 企業はそれぞれが複雑でユニークであり、文化が異なることもあります。組織文化は変革にとって重要であり、従業員のマインドセット、エンゲージメント、コラボレーション、変化への適応性、レジリエンスを形成します。変革の目標をサポートし、それに沿った文化を育むことで、組織は成功かつ持続可能な変革の実現可能性を高めることができます。Amazon のイノベーションへのアプローチは、文化からプロセス、テクノロジーに至るまでの一連の方法論、概念、ツールに基づいています。 参考情報 AWS CAF – Culture Evolution AWS Well-Architected Mental Models for Your Digital Transformation AWS Prescriptive Guidance – Accelerating cloud adoption through culture, change and leadership Learn from Amazon’s Approach to Innovation Leading and Innovating with Leadership Principles Elements of Amazon’s Day 1 Culture The Imperatives of Customer-Centric Innovation How to create a data-driven culture 本記事は、Nurani Parasuraman および Siraj Gadne による「 Maximize Cloud Adoption Benefits with a Well-Architected Organizational Culture 」を翻訳したものです。翻訳はカスタマーソリューションマネージャの山泉 亘が担当しました。 ＜原著執筆者について＞ Nurani Parasuraman AWS のカスタマーソリューションチームの一員です。彼は、人、プロセス、テクノロジー全体にわたる基本的な移行から大規模なクラウド変革への推進を通じて、企業が成功し、クラウド運用から大きなメリットを実現できるよう支援することに情熱を注いでいます。AWS に入社する前は、複数の上級管理職を歴任し、ファイナンスサービス、小売、通信、メディア、製造におけるテクノロジーの提供と変革を主導していました。彼は金融学の MBA と機械工学の理学士号を取得しています。 Siraj Gadne アマゾンウェブサービスのカスタマーソリューションチームのリーダーです。彼は真のビルダーであり、移行、モダナイゼーション、トランスフォーメーションを通じて顧客がクラウド運用のメリットを最大化できるよう支援することに情熱を注いでいます。Siraj は、25 年間のキャリアの中で、コンサルティングと企業の分野でいくつかの指導的地位を歴任してきました。AWS に入社する前、Siraj はザ・コカ・コーラ社、Merkle Inc.、キャップジェミニに勤務し、クラウド対応とデジタルトランスフォーメーションの分野で顧客にサービスを提供していました。

2023 年 7 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon Personalize 基礎編 レコメンドを機械学習の専門知識無しで利用できる Amazon Personalize の使い方を紹介します 資料（ PDF ） | 動画（ YouTube ） 対象者 レコメンドの導入を検討されている方 本 BlackBelt で学習できること Amazon Personalize がなぜ必要なのかと基本的な使い方 スピーカー 近藤健二郎 ソリューションアーキテクト Amazon Neptune ではじめるグラフデータベース入門 近年注目を集めているグラフデータベースについて、 Amazon Neptune の便利機能や簡単なクエリの実行結果を交えながらご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースに関する基本的な知識を持っている方 データベースに関連する開発や運用経験を持っている方 グラフデータベースに興味を持っている方 Amazon Neptune に興味を持っている方 本 BlackBelt で学習できること グラフデータベースの概念やユースケース グラフデータベースのクエリ基礎知識 Amazon Neptune の概要 グラフデータベースの学習方法 スピーカー 木村達也 ソリューションアーキテクト DX の加速に向けた AWS クラウド導入フレームワーク (AWS CAF) の活用 AWS クラウド導入フレームワーク (AWS CAF) は、AWS の経験とベストプラクティスを活用しており、AWS の利用によるデジタルトランスフォーメーション (DX) とビジネスの成果の加速を促すフレームワークです。本セミナーでは、AWS CAF を活用していただくために、そのホワイトペーパーを読み解くための、コツやポイントを紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 DX 推進の施策を検討中の システム / DX 部門の方 クラウド活用を体系的に進めたい IT 担当者、または CCoE の方 オンプレミスとクラウドの考え方の違いを確認したいシステム部門の方 本 BlackBelt で学習できること AWS クラウド導入フレームワーク (AWS CAF) の読み解く方法を学習でき、クラウドを活用したデジタルフォーメーション（DX）の進め方を学ぶことができます。 スピーカー 釈迦郡一郎 カスタマーソリューションマネージャー モダナイゼーションプロジェクト立ち上げに向けたポイント ここ数年でモダナイゼーションという言葉が浸透し、実際に取り組まれている事例が増えています。一方で、抽象的なために全容が把握しずらい、検討したが関係者の共通認識がはかれないまま進めた結果頓挫してしまった、どこから手をつければいいか分からない、といった声も聞くようになってきました。本セッションでは、モダナイゼーションプロジェクトの立ち上げに向けて、事前に検討・考慮すべきポイントについてお話します。 資料（ PDF ） | 動画（ YouTube ） 対象者 モダナイゼーションに取り組むうえで、企画フェーズでの検討内容に関心があるリーダー、責任者の方 システムのモダナイゼーションに取り組もうとしているが、その対象選定や方針策定のポイントを確認したい方 本 BlackBelt で学習できること モダナイゼーションプロジェクト立ち上げ前に検討・考慮すべきポイント モダナイゼーションに取組む上での対象選定や方針策定の進め方 スピーカー 平岩梨果 ソリューションアーキテクト Modernize Enterprise Java Application エンタープライズにおける Java アプリケーションをモダナイゼーションするポイントやアプローチについて、AWS の各種サービスの組み合わせ方を紹介しながら理解を深めます。 資料（ PDF ） | 動画（ YouTube ） 対象者 Java アプリケーションのモダナイゼーションに関心のある、IT アーキテクトやソフトウェアエンジニア Java アプリケーションの維持運用に課題を感じている方 本 BlackBelt で学習できること エンタープライズの Java アプリケーションの構成要素や処理方式に対し、AWS の各種サービスを組み合わせることでどのようなモダナイゼーションが実現できるのか、どのようなメリットがあるのか、について理解を深めることができます。 スピーカー 倉元貴一 ソリューションアーキテクト AWS CDK 概要 (Basic #1) AWS Cloud Development Kit (AWS CDK) の概要から開発の流れまでをご紹介します。AWS CDK で Amazon VPC をデプロイするデモも含んでいます。 資料（ PDF ） | 動画（ YouTube ） 対象者 インフラ構築の手間や作業ミスにお悩みの方 インフラを含めたアプリ全体を素早くデプロイしたいエンジニア プログラミングの知識がある、あるいはこれから学ぶ方 本 BlackBelt で学習できること Infrastructure as Code の基礎から、AWS CDK のコンセプトや誕生ストーリー、開発の流れまでを概観できます。 スピーカー 高野賢司 ソリューションアーキテクト AWS CloudFormation#1 基礎編 AWS CloudFormation は、インフラストラクチャをコードとして扱うことで、AWS およびサードパーティーのリソースをモデル化、プロビジョニング、管理することができます。 本セミナーは、AWS CloudFormation について解説するシリーズの初回である基礎編です。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS CloudFormation をこれから学ぶ方、概要をお知りになりたい方 本 BlackBelt で学習できること AWS CloudFormation を扱う上で必要になる用語や、基本機能について解説しています。 AWS CloudFormation の基本的な使い方について学習いただけます。 スピーカー 福井敦 パートナーソリューションアーキテクト Amazon GameLift FlexMatch マルチプレイヤーゲーム用のマネージドなマッチメイキングサービス Amazon GameLift FlexMatch について網羅的に解説します 資料（ PDF ） | 動画（ YouTube ） 対象者 マッチメイキングの導入を検討されている方 現行のマッチメイキングの仕組みに課題を感じている方 本 BlackBelt で学習できること Amazon GameLift FlexMatch の抑えておきたい概念と仕組みについて網羅的に学習できます スピーカー 秋山周平 ソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2023-08 AWS Cloud Development Kit (CDK) 開発の基礎 ソリューションアーキテクト 高野 賢司 2023-08 AWS Control Tower 基本編 ソリューションアーキテクト 桂井俊朗 2023-08 AWS Control Tower 手順編 既存 Organizations での有効化 クラウドサポートエンジニア 大西朔 2023-08 Amazon CloudFront ( レポート / モニタリング / ロギング編 ) ソリューションアーキテクト 長谷川純也 2023-08 Amazon Personalize 応用編 ソリューションアーキテクト 近藤健二郎 2023-09 AWS Batch HPC スペシャリストソリューションアーキテクト 小林広志 2023-09 Amazon Managed Grafana ソリューションアーキテクト 大井友三 2023-09 Amazon Kinesis Video Streams 基礎編 ソリューションアーキテクト 宇佐美雅紀 2023-09 Amazon Kinesis Video Streams 応用編 IoT スペシャリストソリューションアーキテクト 三平悠磨 2023-09 AWS SimSpace Weaver コンセプト編 ソリューションアーキテクト 阿南麻里子 2023-09 Virtual Andon on AWS ソリューションアーキテクト 山田航司 2023-09 ミニチュア工場デモ : AWS IoT によるデータ集約と可視化 ソリューションアーキテクト 鈴木健吾 2023-09 AWS Key Management Service セキュリティソリューションアーキテクト 平賀敬博 2023-09 AWS Secrets Manager ソリューションアーキテクト 押川令 2023-09 Amazon GameLift FleetIQ ソリューションアーキテクト 安藤怜央 &nbsp;

デジタルの力で地域活性化を目指すデジタル田園都市国家構想に基づき、それぞれの地域の社会課題の解決や、その地域の強みや特色を活かしたデジタルトランスフォーメーション（DX）が加速しています。また2021年9月のデジタル庁発足後、ガバメントクラウドの導入が各自治体で本格的に進み始めています。一方でそれを推進すべきデジタル人材の不足は大きな課題です。 2006年に他社に先駆けてサービスを開始して以来、世界で最も包括的かつ幅広く採用されたクラウドサービスを提供するアマゾン ウェブ サービス（以下、AWS）は、クラウドサービスの提供にとどまらず、デジタル人材の育成支援にも取り組んでおり、最新のデジタルテクノロジーやグローバルの知見の提供などを通じて、地域経済活性化や地域創生に向けたDXの加速を支援しています。 アマゾン ウェブ サービス ジャパン合同会社（以下、AWSジャパン）では、全国の自治体や地域行政におけるイノベーションを支援し、より良い社会と市民生活の実現に貢献すべく、様々な自治体、関係団体との連携を図っています。2022年9月にはつくば市と研究開発型スタートアップの成長加速に向けた連携協定、また、同年同月に浜松市とデジタル・スマートシティ浜松の実現に向けた連携協定、2023年5月には新潟県と地域産業の活性化に向けた包括的な連携協定を締結しました。そしてこのたび、地域創生に向けた自治体におけるDXの加速を支援するため、AWSジャパンは2023年8月17日に北九州市と連携協定を締結しました。 アマゾン ウェブ サービス ジャパン合同会社 執行役員　パブリックセクター 統括本部長　宇佐見 潮は次のように述べています。「北九州市は『デジタルで快適・便利な幸せなまち』というミッションの実現を目指して、市の行政および地域産業全体でデジタルトランスフォーメーション（DX）に取り組まれています。また、同市は地域のポテンシャルや強みを生かした独自の戦略を打ち出し、“バックアップ首都構想”の実現や宇宙産業の推進に力を入れています。これらを支援する今回のイニシアチブは、デジタル田園都市国家構想が目指す地域創生の布石となることでしょう。北九州市との連携を通じて AWS のクラウドテクノロジーと多様な支援プログラムを提供し、北九州の目指すミッションに向けて伴走できることを心から嬉しく思います」 &nbsp; （写真左）AWSジャパン　執行役員 パブリックセクター統括本部長 宇佐見 潮／（写真右）北九州市 市長 武内 和久 北九州市は、「デジタルで快適・便利な幸せな街へ」のミッションのもと、DXを契機に必要な見直し・改善に取り組み、市民サービスの向上と業務の効率化を同時に実現することを推し進めています。 AWSジャパンは、北九州市の地域の特色や強みを活かしながら地域課題を解決するためのDXの推進に向けて、以下の4つの項目において、最新のクラウドテクノロジー、グローバルの知見・ネットワーク、デジタルスキル支援を通じて、北九州市のミッション実現を支援します。 1）“バックアップ首都構想 ”の実現に向けた支援 2）行政や地域のDX促進に向けた支援 3）スタートアップ育成に向けた支援 4）宇宙産業の推進に向けた支援 1. “バックアップ首都構想”実現に向けた支援 北九州市は、低災害リスクや、エネルギーや水の安定供給など、北九州市のポテンシャルを活かし、首都圏に集中する企業などが災害時にも業務を維持できるよう、バックアップ機能を誘致する“バックアップ首都構想”を掲げています。 この構想に基づく企業誘致には、北九州市におけるデジタル人材、特にクラウド人材が不可欠です。そこでAWSジャパンは在北九州市の企業と連携し、ハンズオンセッションを実施するなど、地域の企業にクラウドスキルトレーニングを提供し、デジタル人材の育成を支援します。 2. 行政や地域のDX促進に向けた支援 地域のイノベーションを推進するために、地域の産業やビジネスのイノベーション、DXを支える北九州市の職員がクラウドについて理解を深めていただくことが重要です。AWSのパートナー企業が実施するクラウド人材育成プログラムを市の職員に提供し、職員のデジタルスキルの向上をサポートしていきます。 また、地域のデジタル人材の層を厚くし、北九州市全体のイノベーションを促進・支援するために、地域の高等教育機関などと連携し、クラウド学習プログラムであるAWS Academy を活用した学生のクラウドスキルトレーニングや将来のデジタル人材育成を行います。 AWS Academyを通じて、教材や実習環境だけではなく、講師の登壇までのトレーニングも含むパッケージ化されたプログラムを高等教育機関向けに提供し、学生たちが将来、業界で認知されている認定資格を取得し、需要の高いクラウド関連の仕事に就けるように支援します。 3. スタートアップ育成に向けた支援 AWSでは、クラウドをはじめとしたデジタルテクノロジーを社会実装するうえで、スタートアップが欠かせないと考えています。それにより、過去10年にわたり数千におよぶ日本のスタートアップを支援してきました。北九州市との連携においてもそのノウハウを共有し、北九州市のスタートアップのすそ野をより一層拡大していきます。 まず、「COMPASS小倉」等の市内コワーキングスペースを利用する企業に対し、AWSのクレジットを利用できる AWS Activate などの支援プログラムを提供します。AWS Activateとは、スタートアップが自身のビジネスの立ち上げや拡大に向けてAWSを速やかに運用開始するために必要なリソースを包括的に提供するスタートアップ支援プログラムです。 4. 宇宙産業の推進に向けた支援 北九州市は市の成長戦略の一つとして宇宙産業に力を入れており、宇宙ビッグデータの利活用などを進めていく方針を打ち出しています。AWSは2020年に航空宇宙・衛星産業におけるイノベーションの加速に特化したチームを立ち上げ、官民のお客様の宇宙関連のビジネスをサポートしています。 今後、AWSの宇宙産業に関する知見や企業間のネットワークを北九州市と共有することで、市の宇宙産業推進のステージに合わせた連携を図っていきます。また、宇宙に関するアイデアコンテストやハッカソン等の共同開催も予定していきます。 AWSは、デジタル技術を活用して地域創生や社会課題解決に取り組む自治体や地域産業、スタートアップを、AWSの最新のテクノロジーやサービスなどの提供を通じて支援します。それにより市民や住民のより良い豊かな市民の暮らしに貢献することを、様々なステークホルダーと共に目指していきます。

2021 年 11 月、最高 3.6 GHz の周波数で動作する第 3 世代 AMD EPYC (Milan) プロセッサを搭載した Amazon EC2 M6a インスタンスがリリース されました。これにより、M5a インスタンスに比べてコストパフォーマンスが最大 35% 向上します。SAP など、x86 命令に依存するワークロードを実行する 多くのお客様 は、クラウドの利用を最適化する方法を模索しています。これらのお客様は、EC2 が提供するコンピューティングオプションを活用しています。 8月15日、最大周波数 3.7 GHz の第 4 世代 AMD EPYC (Genoa) プロセッサを搭載した新しい汎用 Amazon EC2 M7a インスタンスの一般提供をお知らせします。このインスタンスでは、M6a インスタンスと比べてパフォーマンスが最大 50% 向上しています。このパフォーマンスの向上により、データ処理の高速化、ワークロードの統合、保有コストの削減が実現します。 M7a インスタンスは、 AVX-512、Vector Neural Network Instructions (VNNI) 、および bfloat16 (Brain Floating Point 16) をサポートします。これらのインスタンスには、データインメモリへの高速アクセスが可能な Double Data Rate 5 (DDR5) メモリが搭載されていて、M6a インスタンスに比べて 2.25 倍のメモリ帯域幅を提供するので、レイテンシーを低く抑えることができます。 SAP 認定の M7a インスタンスは、金融アプリケーション、アプリケーションサーバー、シミュレーションモデリング、ゲーム、中規模データストア、アプリケーション開発環境、キャッシングフリートなど、高パフォーマンスと高スループットのメリットを活用するアプリケーションに理想的です。 M7a インスタンスでは、768 GiB の RAM で最大 192 の vCPU を使用できます。詳細な仕様は次のとおりです。 名前 vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) m7a.medium 1 4 最大 12.5 最大 10 m7a.large 2 8 最大 12.5 最大 10 m7a.xlarge 4 16 最大 12.5 最大 10 m7a.2xlarge 8 32 最大 12.5 最大 10 m7a.4xlarge 16 64 最大 12.5 最大 10 m7a.8xlarge 32 128 12.5 10 m7a.12xlarge 48 192 18.75 15 m7a.16xlarge 64 256 25 20 m7a.24xlarge 96 384 37.5 30 m7a.32xlarge 128 512 50 40 m7a.48xlarge 192 768 50 40 m7a.metal-48xl 192 768 50 40 M7a インスタンスには最大 50 Gbps の拡張ネットワーキングと 40 Gbps の EBS 帯域幅があり、これは M6a インスタンスと同様です。ただし、1 つの vCPU、4 GiB を提供する新しいミディアムインスタンスサイズでは、ワークロードのサイズをより正確に調整できます。最大サイズは 192 の vCPU、768 GiB です。 新しいインスタンスは、従来の仮想化機能の多くを専用ハードウェアにオフロードするビルディングブロック技術の集合体である AWS Nitro System をベースに構築されており、高性能、高可用性、高セキュリティのクラウドインスタンスが実現しています。 今すぐご利用いただけます 8月15日、Amazon EC2 M7a インスタンスは、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド) の AWS リージョンで利用できるようになりました。Amazon EC2 でいつも支払うのと同じように、使用した分の料金のみをお支払いいただきます。詳細については、 Amazon EC2 の料金ページ を参照してください。 詳細については、 EC2 M7a インスタンス と AWS/AMD パートナーページ を参照してください。 ec2-amd-customer-feedback@amazon.com 、 AWS re:Post for EC2 、または通常の AWS サポートの担当者を通じて、ぜひフィードバックをお寄せください。 — Channy 原文は こちら です。

夏を満喫するためにカリフォルニアで数日を過ごしている間に AWS では多くのことが起こりました。一緒に見ていきましょう！ 8月7日週のリリース 私が注目したリリースを以下に記載しました。 Amazon MWAA での Apache Airflow バージョン 2.6 のサポート – Amazon Managed Workflows for Apache Airflow (Amazon MWAA) は エンドツーエンドのデータパイプラインをクラウドでセットアップして運用するために使用できる Apache Airflow 用のマネージドオーケストレーションサービスです。Apache Airflow バージョン 2.6 では、ワークフローのセキュリティと信頼性を強化する重要なセキュリティ更新とバグ修正が導入されています。現在 Apache Airflow バージョン 2.x を実行している場合は、バージョン 2.6.3 にシームレスにアップグレードできるようになりました。 この AWS ビッグデータブログの投稿 をご覧ください。 Amazon EMR Studio が AWS Lake Formation のきめ細かいアクセスコントロールのサポートを追加 – Amazon EMR Studio は、 Amazon EMR クラスター上で実行するフルマネージド型の Jupyter Notebook 用のウェブベースの統合開発環境 (IDE) です。EMR Studio ワークスペースから EMR クラスターに接続する際、接続する AWS Identity and Access Management (IAM) ロールを選択できるようになりました。Apache Spark インタラクティブノートブックは、このランタイム IAM ロールにアタッチされたポリシーで許可されているデータとリソースにのみアクセスします。 AWS Lake Formation で管理されているデータレイクからデータにアクセスする場合、このランタイムロールにアタッチされたポリシーを使用して、テーブルレベルと列レベルのアクセスを強制できます。詳細については、 Amazon EMR のドキュメント をご覧ください。 AWS Security Hub が 12 の新しいセキュリティコントロールをローンチ – AWS Security Hub は、セキュリティのベストプラクティスチェックを実行し、アラートの集約と自動修復の有効化を行う Cloud Security Posture Management (CSPM) サービスです。新たにリリースされたコントロールにより、Security Hub は Amazon Athena 、 Amazon DocumentDB (MongoDB 互換)、 Amazon Neptune という 3 つの AWS のサービスをサポートするようになりました。Security Hub では、 Amazon Relational Database Service (Amazon RDS) に対するコントロールも追加されています。AWS Security Hub では、現在、276 のコントロールが提供されています。詳細については、 AWS Security Hub のドキュメント を参照してください。 AWS イスラエル (テルアビブ) リージョンで利用可能になった AWS のサービス – AWS イスラエル (テルアビブ) リージョンが 2023 年 8 月 1 日にオープンしました 。8月7日週、イスラエル (テルアビブ) リージョンで利用可能なサービスのリストに、 AWS Service Catalog 、 Amazon SageMaker 、 Amazon EFS 、 Amazon Kinesis Data Analytics が追加されました。可用性に関する最新情報については、 AWS リージョン別のサービス表 を確認してください。 AWS のお知らせの完全なリストについては、「AWS の最新情報」ページをご覧ください。 その他の AWS のニュース 興味深いと思われるその他のブログ投稿とニュース項目をいくつかご紹介いたします。 2023 Gartner Magic Quadrant において AWS が Amazon Connect で Contact Center as a Service のリーダーに認定 – 柔軟な AI 搭載のクラウドコンタクトセンターである Amazon Connect が 2017 年にローンチされて以来、AWS は初のリーダーに選出されました。 全文を読む。 生成系 AI を使用したクリエイティブな広告生成 – この AWS Machine Learning ブログ投稿 では、生成系 AI を使用して魅力的で革新的な広告を大規模に生成する方法を示しています。Inpainting の手法に加えて、画像の背景、視覚的に魅力的なコンテンツをシームレスに作成する方法、そして不要な画像アーティファクトを削減する方法について説明します。 AWS オープンソースニュースと更新情報 – 私の同僚の Ricardo が 週刊のオープンソースニュースレター を執筆し、AWS コミュニティの新しいオープンソースプロジェクト、ツール、デモを紹介しています。 AWS の今後のイベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 生成系 AI 上での構築 – 生成系 AI のすべてを網羅した 週刊 Twitch ショー のシーズン 2 が始まりました。 毎週月曜日 9:00 (米国太平洋標準時) に同僚の Emily と Darko が AWS の新しい技術的および科学的パターンについて考察し、ゲストスピーカーを招いてその作業のデモを行い、生成系 AI の状態を改善するために構築されたものを紹介します。 本日のエピソードでは、Emily と Darko が最新モデルの LLAMA-2 と Falcon について話し、Retrieval-Augmented Generation のデザインパターンで探求します。 ビデオはこちらからご覧いただけます 。 ショーのノートとエピソードの完全なリストについては、community.aws をチェックしてください 。 AWS NLP カンファレンス 2023 – 9 月 13 日から 14 日にロンドンで開催 されるこの対面式イベントで AWS の自然言語処理 (NLP) 機能を活用する最新のトレンド、画期的な研究、革新的なアプリケーションの詳細を確認してください。今年のカンファレンスでは、多くの生成系 AI アプリケーションやユースケースのバックボーンを形成する大規模言語モデル (LLM) に主な焦点を当てます。 こちらからご登録 いただけます。 AWS グローバルサミット – 2023 年の AWS Summit シーズンを締めくくるのは、 メキシコシティ (8 月 30 日) とヨハネスブルグ (9 月 26 日) の 2 回の対面イベントです。 AWS Community Day – AWS ユーザーグループリーダーが主催し、お住まいの地域のコミュニティが主導するカンファレンスにご参加ください。 西アフリカ (8 月 19 日)、 台湾 (8 月 26 日)、 ニュージーランド (9 月 6 日)、 レバノン (9 月 9 日)、 ミュンヘン (9 月 14 日) で開催されます。 AWS re:Invent (11 月 27 日～12 月 1 日) – ぜひご参加ください。AWS の最新情報を聞き、専門家から学び、グローバルなクラウドコミュニティとつながりましょう。 登録が開始されました 。 近日開催予定の実地イベントやバーチャルイベントをすべてご覧いただけます。 8月14日週はここまでです。8月21日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください。 —&nbsp; Antje P.S.私たちは、より良いカスタマーエクスペリエンスを提供するためにコンテンツの改善に注力しており、そのためにはお客様からのフィードバックが必要です。 この短いアンケート にご回答いただき、AWS ブログに関するご感想をお聞かせください。なお、このアンケートは外部企業によって実施されているため、リンク先は当社のウェブサイトではありません。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。 原文は こちら です。

この記事では、 Amazon Neptune Serverless の一般的なユースケースと、推奨されるベストプラクティスに従ってコストとパフォーマンスの両方を最適化する方法を紹介します。 Amazon Neptune は、グラフ・アプリケーションの構築と実行を容易にする、クラウド向けに最適化されたフルマネージド・データベース・サービスです。 RDF と プロパティグラフ 両方のグラフ・データモデルをサポートしています。データベース管理を簡素化し、新規アプリケーションの構築や既存アプリケーションの移行を迅速に行うことができます。高価なライセンス料からの脱却を目指す組織は、Neptuneに移行することで、最新のオープンソース・イノベーションの恩恵を受けることができます。求められる要件に対してカスタマイズできるよう、 高可用性や耐久性 など幅広い機能を提供します。 Neptune Serverless は、オンデマンドの自動スケーリング構成で、必要に応じてNeptuneクラスタをスケールするようにデザインされています。Neptune Serverlessでは、 いくつかの制限 はありますが、プロビジョニングされたインスタンスと同じ機能を使用できます。費用対効果が高く、データベースの容量を管理・最適化することなく、グラフのワークロードを実行し、迅速にスケーリングすることができます。Neptune Serverlessインスタンスでは、次のようなメリットがあります。 迅速かつ無停止のキャパシティ・スケーリング きめ細かく予測可能なキャパシティ調整 高可用性、ディザスタリカバリ、拡張機能 すでにNeptuneを使用している場合、アプリケーションを変更することなく簡単に移行することが可能 Neptune Serverlessクラスタのスケーリング構成は Neptune Capacity Unit （NCU）で定義され、NCUはそれぞれ2 GBのメモリと、関連する仮想プロセッサ（vCPU）およびネットワーク容量で構成されます。サポートされる NCU の最小値は 1.0 で、最大値は 128 です。NCU 構成は 0.5 NCU 単位で調整できます。Neptune Serverlessはコンピュートリソースのみスケールすることにご注意ください。 ストレージの上限 は変わらず、サーバーレスのスケーリングの影響を受けません。 Neptune Serverlessの一般的な使用例 Neptune Serverlessは、非定常的かつ突発的なトラフィックを伴うワークロードに最適です。定常的で予測可能なトラフィックを持つワークロードに使用することはお勧めしません。その理由は、定常的なワークロードの場合、プロビジョニングされたインスタンスの方がコスト効率が良いからです。たとえば、プロビジョニングされた db.r5.xlarge インスタンスを選択する方が、NCU=16 最小値=最大値に設定して 、NCU=16 のままのサーバーレスインスタンスよりも費用対効果が高くなります。 以下は、サーバーレスがデータの分離や費用対効果などの利点を提供できる、その他の使用例です。 Neptuneの新規利用あるいは新規アプリケーションに対するリソースの最適化 Neptuneを初めて利用するお客様にとって、グラフデータのワークロードに必要なインフラストラクチャを決定することが困難な場合があります。お客様のワークロードに 最適なインスタンスサイズを推定する方法 を提供していますが、クエリのレイテンシや予想されるトラフィックなどの追加情報が必要であり、初期段階では明らかにできないケースが多くあります。そのため、新規でNeptuneを利用するお客様や新規アプリケーションにとっては、キャパシティ要件を決定することが難しくなります。代わりに、コンピュートリソースの計算を気にせずにNeptune Serverlessを開始し、それまでのリソース消費量を確認することで要件を満たすプロビジョニング・インスタンス・サイズを特定することができます。また、アプリケーションの書き込み/読み込みが多かったり、トラフィックにばらつきがあることに気づいたら、 サーバーレスインスタンスとプロビジョニングインスタンス を1つのクラスタで組み合わせることもできます。 開発環境とテスト環境 多くのお客様は、本番環境ではない開発環境とテスト環境でコストを削減する新しい方法を模索しています。開発チームやテストチームが大規模なインスタンスをデプロイし、その停止や削除を忘れてしまうことは、多くのお客様にとって懸念事項です。しかし、開発チームやテストチームは、大規模な負荷テストを実行できるインスタンスをデプロイしなければいけません。サーバーレスは両方の長所を提供することができます。つまり、稼働していない期間中のコストを削減するために最小NCU数が少ないサーバーレスインスタンスをデプロイすることができ、開発チームやテストチームが高稼働期間中に迅速にスケーリングできるように最大NCU数が多いサーバーレスインスタンスをデプロイすることができます。 テナントごとのデータベースを備えたマルチテナント・アプリケーション 何千人ものエンドユーザーにサービスを提供する SaaS (Software as a Service) アプリケーションのようなプラットフォームでは、現在または予想される需要に基づいて Neptune クラスタを過剰または過小にプロビジョニングすることがよくあります。また、個々の顧客データを分離する必要がある場合、データの分離要件に直面することもあります。Neptune Serverlessを使用すると、個々のNeptuneクラスタを提供することで各顧客のデータを物理的に分離できるだけでなく、Neptune Serverlessの自動スケーリング機能を使用して、基盤となるインフラストラクチャを積極的に管理する必要がなくなり、各テナントデータベースを独立してスケーリングできます。 データベースに支えられたいくつかのアプリケーション 今日の最新のアプリケーション・アーキテクチャでは、何百、何千ものカスタム・アプリケーションが存在し、それぞれが1つ以上のデータベースによって成り立っています。アプリケーションの要件が進化するにつれて、それらをサポートし続けるためのデータベース容量も追随しなければなりません。費用対効果の高い方法でデータベース・フリートの容量調整を管理することは、困難かつ労力を要します。サーバーレスは、アプリケーションと関連するキャパシティ要件が進化するにつれて、データベース・キャパシティの管理負担を軽減するのに役立ちます。 効率的な水平および垂直スケーリング スケーラビリティを必要とするアプリケーションは、より高いスループットを得るために、データベースを複数のインスタンスに分割することがお勧めです。各インスタンスの容量を予測するのは困難で非効率的です。なぜなら、予想されるリクエスト数と各クエリのレイテンシに関する複雑な情報や経験が必要だからです。インスタンスの数が少なすぎると、データを再配置しなければならず、ダウンタイムが発生します。インスタンスの数が多すぎると、すべてのインスタンスが均等に利用されないため、高いコストを支払うことになります。サーバーレスインスタンスを使用することで、初期コストをあまり追加することなく、アプリケーションを複数のインスタンスにシャードすることができ、シャードされたデータベースはそれぞれ、必要なときに必要な容量を垂直方向に拡張することができます。過少利用や過剰なプロビジョニング、不要なコストの支払いは必要ありません。 Global DatabaseとNeptune Serverlessによるディザスタリカバリ Neptune Global Database は、プライマリーインスタンスと最大 5 つのセカンダリーリージョン間でグラフデータをレプリケートする機能を提供します。これにより、リージョン全体が停止した場合のディザスタリカバリの機能を提供します。しかし現実には、リージョン全体で障害が発生する可能性は低いため、セカンダリーリージョンにプロビジョニングされたNeptuneインスタンスは十分に活用されないケースもあります。セカンダリーリージョンでプロビジョニングされたインスタンスの代わりにサーバーレスインスタンスを使用することで、NCUの最小値を許容可能な最小値に設定することで、積極的に使用されていない間のコストを節約することができます。また、必要に応じて、クラスタ構成を更新することでNCU値を増やし、新しい需要に合わせて自動的にスケールさせることもできます。 Neptune Serverlessのベストプラクティス このセクションでは、Neptune Serverlessを使用する際のベストプラクティスを紹介します。 ワークロードと機能に最適な最小および最大NCUの構成 次のことを検討します。 一括ロードを使用するワークロード – バルクロードのようなリソース集約型のワークロードには、Neptune Serverlessを適切に構成することをお勧めします。最大 NCU は、希望するレートでデータを取り込むことができるレベルに設定する必要があります。たとえば、バルクロード操作時に 128 NCU に設定すると、Neptune は一括ロードに必要なリソースを確保できます。正確な最大 NCU は、取り込むデータ量と希望するデータ取り込みレートに依存します。また、NCU 最小値=最大値 とする構成は、スケーリングが容易にならないため、この種のユースケースではアンチパターンです。この場合、同じようなサイズ（メモリ・サイズとvCPU数）のプロビジョニングされたNeptuneインスタンスの方が良い選択かもしれません。 サーバーレスリーダーインスタンスを大規模なプロビジョニングされたプライマリーインスタンスと組み合わせて使用する場合、書き込みの数に追いつけず、共有ストレージからの読み込みを再起動するような状況が発生します。この場合、プライマリーからのレプリケーショントラフィックを満たすためにサーバーレスリーダーインスタンスの最小NCU構成を1NCU以上の値にスケールアップするか、一括ロード操作中に一時的に削除する必要があります。詳細については、 一括ロード中に再起動を繰り返さないようにする を参照してください。 IAMデータベース認証が有効になっているNeptuneクラスタ – AWS Identity and Access Management (IAM)データベース認証 が有効になっているNeptuneクラスタでは、エラーを回避するために最低でも2以上の最小NCU値が必要です。 トラフィックが急増するワークロードをサーバーレスインスタンスに切り替える 需要が急増し、一貫性のないワークロードに対しては、サーバーレスインスタンスを使用することで、Neptuneクラスタに関連するコンピュートリソースを垂直方向にスケールする自動化されたコスト効率の高いメカニズムが提供されます。しかし、トラフィックが一貫しているワークロードでは、サーバーレスインスタンスを使用すると、同じ容量のプロビジョニングされたインスタンスを使用する場合と比較してコスト効率が悪くなります。また、サーバーレスクラスターでNCU 最小値=最大値を設定することは、推奨されるパターンに反しています。要件によっては、プロビジョニングされたインスタンスの方がコスト効率とパフォーマンスが高く、ニーズを満たせるかもしれません。 最小容量を増やし、より高速なスケーリングを可能にする Neptune Serverlessは、最小NCUの設定値に基づく速度でスケールします。最小NCUが1.0に設定されている場合、サーバーレスクラスターが重いトラフィックに対応する容量を提供するためにスケールアップするのに時間がかかります。これは、Neptune Serverlessが 現在使用されているサーバーレス容量に基づいてスケーリング増分を選択 するためです。これを高い値に設定することで、特にデータベースへの需要が増加することが分かっているイベントの前に、Neptune Serverless はより高いスケーリング率を使用し、需要に対応するためにより速くスケールアップします。 リーダーインスタンスの正しい昇格階層を設定する Neptune Serverlessリーダーインスタンスが最小NCUまでスケールダウンせず、プライマリーインスタンスと同じかそれ以上の容量にとどまっている場合は、リーダーインスタンスの昇格階層を確認してください。Tier 0または1では、サーバーレスリーダーインスタンスはライターインスタンスと同じ容量に維持されます。リーダーの昇格階層を2以上に変更することで、ライターから独立してスケールアップあるいはスケールダウンするようになります。詳細については、 Neptune Serverlessインスタンスの昇格階層 の設定を参照してください。 Neptune Serverlessと自動スケーリングの組み合わせ Neptuneリードレプリカ自動スケーリング を使用して、接続要件とワークロードに基づいてNeptuneクラスタ内のレプリカ数を自動的に調整できます。また、Neptune Serverless を使用して、アプリケーションからの突然のトラフィック急増にも対応することができます。CPU使用率ベースの自動スケーリングを使用する場合、最小値と最大値の両方のNCUを低く設定したり、最小値と最大値のNCUの範囲を狭く実装したりすると、Neptuneリードレプリカの追加と削除が急激に行われることがあります。 クエリのタイムアウトを正しく設定し、クエリがバックグラウンドで実行され、コストがかかるのを防ぐ プロビジョンドインスタンスと比較して、長時間稼働するワークロードに対してNeptune Serverlessを実行するコストは高くなるため、特定の要件に対応できるように クエリタイムアウトパラメータ(neptune_query_timeout) を調整することをお勧めします。短時間のクエリのみが予想される場合は、クエリタイムアウトを短く設定します。これは、バックグラウンドで実行されている予期せぬ長時間実行クエリによって不要なコストが発生するのを避けるためです。 サーバーレスインスタンスを監視してコストと最適化を図る サーバーレスクラスターやインスタンスを監視するために、 サーバーレスインスタンス用のAmazon CloudWatchメトリクス が2つ追加されています。 ServerlessDatabaseCapacity – (インスタンスレベルの) 現在のインスタンス容量、または (クラスタレベルの) 全インスタンスの全値の平均を提供する NCUUtilization – ServerlessDatabaseCapacity を NCU の最大値で割って、使用可能な容量の割合をレポートする もし NCUUtilization メトリックが100%に近づいている場合は、サーバーレスインスタンス全体でNCUの最大値を増やすことを検討してください。 Neptune Serverlessの価格 サーバーレスインスタンスをデプロイする際、価格設定などはプロビジョニングインスタンスと同じ要素が適用されます。 ストレージはGB/月で請求 消費されたI/Oオペレーション バックアップ・ストレージ データ転送料金 Global Database やスナップショットエクスポートなどの特別機能の料金 サーバーレスインスタンスの課金の主な違いは、 1時間あたりのNCUでの使用量 に基づいて価格が設定されることです。実際のコストは、Neptuneクラスタがデプロイされたリージョンによって異なります。 Neptune Serverlessの価格比較 以下は、サーバーレスインスタンスと db.r6g.8xlarge プロビジョニングインスタンスを使用した場合の、30日間にわたるスパイク上のトラフィックと一貫したトラフィックを持つワークロードのコスト比較です。どちらの見積もりにも以下の構成が含まれています。 リージョンは us-east-1 50GBのデータと100GBのバックアップ 月間2億回のI/Oオペレーション 月間50GBのデータ転送 月間10GBのデータ転送 次の表は、トラフィックが急増しているワークロードの例を比較したものです。最大 NCU (128) で 1 日あたり 1 時間、最小 NCU (1) で 1 日あたり 23 時間です。 Serverless Provisioned (db.r6g.8xlarge) Instance charges $728.42 $3,804.62 Storage charges $7.10 $7.10 I/O charges $40.00 $40.00 Data transfer charges $0.00 $0.00 Total charges $775.52 $3,851.72 サーバーレスを使用した場合、プロビジョニングされたインスタンスと比較して、スパイク特性の高いワークロードにかかるコストの差は、月額 3,076.20ドル の節約となりました。 次の表は、最大NCU（128）で1日あたり23時間、最小NCU（1）で1日あたり1時間、一貫したトラフィックのワークロードの例を比較したものです。 Serverless Provisioned (db.r6g.8xlarge) Instance charges $14,206.80 $3,804.62 Storage charges $7.10 $7.10 I/O charges $40.00 $40.00 Data transfer charges $0.00 $0.00 Total charges $14,253.90 $3,851.72 一貫したワークロードに対してプロビジョニングされたインスタンスとサーバーレスを使用した場合のコストの差は、月額 10,402.18ドル の増加となりました。 Neptune Serverlessの制約 Neptune Serverlessは垂直スケーラビリティとコスト効率を迅速に提供できますが、その制約を理解することが重要です。 サーバーレスは すべての地域で利用できるわけではない （訳注:東京リージョンではご利用可能です） エンジンリリース1.2.0.1 以降で使用可能 Neptuneの ルックアップキャッシュ とは互換性がない サーバーレスインスタンスの最大メモリは256GB（最大NCUは128） 詳細は Amazon Neptune Serverless constraints を参照してください。 まとめ この投稿では、Neptune Serverlessの一般的なユースケースとベストプラクティスについて説明しました。様々なトラフィックやデータ分離を必要とするワークロードに対してプロビジョニングされたインスタンスよりもサーバーレスインスタンスを使用したり、本番環境ではない開発環境やテスト環境などで高い費用対効果を得たりすることでメリットを得ることができます。さらに、同じNeptuneクラスタ内でサーバーレスインスタンスと従来のプロビジョニングされたインスタンスを組み合わせることで、最も負荷の高いワークロードに対して柔軟性とスケーラビリティを提供する方法についても説明しました。 Neptune Serverlessを始めるには、 Neptuneコンソール にアクセスするか、 Amazon Neptune Serverless を参照して詳細を確認してください。 著者について Kevin Phillips は、Amazon Web Servicesの英国で働くNeptuneスペシャリスト・ソリューション・アーキテクトです。18年にわたる開発とソリューション・アーキテクチャの経験を生かし、顧客のサポートと指導にあたっています。 Ankit Gupta は、インドの Amazon Neptune Platform チームのソフトウェア開発マネージャーで、製品立ち上げ当初から Neptune チームの一員です。AWSの顧客や社内の開発チームと協力し、Neptuneのユーザビリティ、パフォーマンス、スケーラビリティ、ユーザーエクスペリエンスの向上に取り組んでいます。 本記事は 2023/06/28に投稿された Use cases and best practices to optimize cost and performance with Amazon Neptune Serverless を翻訳した記事です。翻訳はソリューションアーキテクトの木村 達也が行いました。