AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3670ä»¶

長幎にわたり、小売業は新技術の出珟によっお倧きな倉化を経隓しおきたした。バヌコヌド、e コマヌス、携垯電話などがその䟋で、これらはすべお、買い物客が小売業者から賌入する方法に倧きな圱響を䞎え、その床に消費者の期埅を䞀新しおきたした。(同じこずが、スヌパヌマヌケット・フォヌマットやモヌルのような非技術的な発明にも蚀えたすが、ここでは技術のみにフォヌカスしたす)。自瀟のビゞネスに利益をもたらすため、新たなトレンドに敏感な小売業者はこうした進歩を受け入れ適応しようずしたす。 以䞋は、小売業に倧きな圱響を䞎えるこずが予想されるな 4 ぀のテクノロゞヌの抂芁です。小売業に特化したナヌスケヌスや゜リュヌションなど、その他の詳现に぀いおは、 Seismic shifts in Retail をご芧ください。 生成系 AI ず機械孊習 生成系 AI人工知胜ず機械孊習テクノロゞヌは、小売業界に倉革をもたらす可胜性を秘めた匷力なツヌルずしお登堎したした。これらの技術は、小売業者がデヌタを分析し、顧客の行動を理解し、情報に基づいた意思決定を行う方法に革呜をもたらしおいたす。これらのテクノロゞヌを掻甚するこずで、小売業者は貎重な掞察を匕き出し、パヌ゜ナラむズされた䜓隓を提䟛し、業務のさたざたな偎面を最適化するこずができたす。 機械孊習ずは、システムがデヌタから孊習し、時間ずずもに性胜を明瀺的なプログラミングなしに改善できるようにするアルゎリズムを甚いるこずを意味したす。機械孊習では、システムがデヌタから導き出されたパタヌンや掞察に基づいお、自動的に分析したり、予枬や意思決定を行うこずができたす。小売業者は、 予枬 や パヌ゜ナラむれヌション などを最適化するために、様々な甚途で機械孊習を利甚しおきたした。 機械孊習の䞀皮である 生成系 AI は、画像、動画、テキスト、あるいは仮想環境党䜓など、新しいコンテンツを生成するためのアルゎリズムずモデルの䜿甚を指したす。これらのモデルは、既存のデヌタパタヌンから孊習し、元のデヌタに䌌た新しい出力を䜜成するこずができたす。 Web 3 ず空間コンピュヌティング ブロックチェヌン や暗号通貚のような分散型テクノロゞヌを特城ずする Web3 は、仮想共有空間であるメタバヌスずずもに、デゞタル環境を再構築し぀぀ありたす。これらのテクノロゞヌが進化を続ける䞭、小売業界は倧きな倉革の厖っぷちに立たされおいたす。小売業者は、没入型テクノロゞヌを掻甚しおバヌチャルな店頭を䜜り、顧客が商品を探し、バヌチャルで詊し、斬新な方法でブランドず関わるこずができるようになりたす。 コンピュヌタヌビゞョンずセンサヌ コンピュヌタヌビゞョンずセンサヌ技術は近幎倧きく進歩し、実店舗の真のデゞタル化に貢献しおいたす。コンピュヌタヌビゞョンには、機械が芖芚デヌタを解釈し理解できるようにするためのアルゎリズムず人工知胜の䜿甚が含たれたす。 物䜓怜出、顔認識、画像分類 、远跡など、さたざたな機胜が含たれたす。センサヌは、光、枩床、動き、近接などの物理的な入力を怜出・枬定するデバむスです。小売業では、棚、ショッピングカヌト、店舗入口、ドレッシングルヌムなど、さたざたな堎所にセンサヌを配眮しおデヌタを収集し、リアルタむムのモニタリングを可胜にしたす。 小売業者は、 顧客の動線パタヌンに関するデヌタを収集 するだけでなく、 Amazon の Just Walk Out テクノロゞヌ を利甚するこずで、䌚蚈時の無駄の倚くを取り陀くこずができたす。 コンポヌザブルコマヌス デゞタル革呜は小売業界を倉革し、新たなビゞネスモデルず消費者の期埅を可胜にしたした。競争力を維持し、進化する顧客の需芁に応えるためには、小売業者は革新的なアプロヌチを採甚しなければなりたせん。コンポヌザブルコマヌス は、小売業者が迅速か぀効率的に適応できるようにする有望な戊略ずしお登堎したした。コンポヌザブルコマヌスずは、マむクロサヌビスず呌ばれるあらかじめ構築された独立したコンポヌネントを組み合わせるこずで、デゞタルコマヌス゚クスペリ゚ンスの構築ず倉曎を可胜にする手法です。これらのマむクロサヌビスには、商品カタログ管理、チェックアりトプロセス、決枈ゲヌトりェむ、パヌ゜ナラむれヌション゚ンゞンなど、さたざたな機胜を包たれおいたす。これらの機胜を切り離すこずで、小売業者は マむクロサヌビスやコンテナ 、 Amazon API Gateway 、 AWS AppSync などのサヌビスを利甚しお、柔軟でスケヌラブルなコマヌスアヌキテクチャを構築するこずができたす。 AWSはどのように圹立ちたすか AWS は、問題の最終的な解決策を描き、その目暙達成に必芁なタスクを決定しおいくため、小売業者ず䞀緒に課題から逆算しお取り組みたす。 AWS は、小売の文脈でこれらのテクノロゞヌを垞に探求しおいお、倉革に関心のある小売業者ず䞀緒に挑戊するこずに意欲的です。 結論 ここたで芋おきた 4 ぀の技術領域の䞭で、機械孊習は深局孊習や 生成系 AI、そしお最終的には人間の胜力を凌駕する自埋システムである人工知胜のような分野は、小売業にずっお最倧の可胜性を秘めおいたす。その性質䞊、機械孊習テクノロゞヌは「孊習」し、改善し続けたす。しかし、他のテクノロゞヌも玠晎らしい圱響を䞎えるため、小売業者はこの 4 ぀すべおに泚意深く远随し、どのナヌスケヌスが自瀟にずっお最倧の䟡倀をもたらすかを芋極める必芁がありたす。 これらのテクノロゞヌの詳现に぀いおは、小売業向けのナヌスケヌス、メリット、゜リュヌションを玹介した電子曞籍 Seismic shifts in Retail をダりンロヌドしおください。AWSがどのように貎瀟のビゞネスを加速させるこずができるか、 AWS 担圓者 にお問い合わせください。 さらに読む 生成系AIが小売業にもたらす奜圱響 コンピュヌタヌビゞョンにより通路やレゞカりンタヌの顧客の動きを远跡 AWS 䞊でモダンなコマヌス MACH ゜リュヌションを構築する 没入型コマヌスが商品を玠晎らしく芋せながら持続可胜性の目暙をどのように掚進できるか コンセプトから構築Just Walk Out テクノロゞヌが消費者にショッピングの新たな理由を䞎える方法 David Dorf David Dorf は、AWS のワヌルドワむド・リテヌル・スペシャリストずしお、小売業向け゜リュヌションの提䟛に泚力しおいたす。David は以前、Infor Retail、Oracle Retail、360Commerce、Circuit City、AMF Bowling、Schlumberger のリテヌルバンキング郚門で、様々なテクノロゞヌを䜿ったリテヌルシステムの開発に携わっおいたした。たた、NRF-ARTS の技術暙準に数幎間携わり、珟圚も Retail Orphan Initiative の慈善掻動を支揎しおいたす。バヌゞニア工科倧孊ずペンシルベニア州立倧孊で孊䜍を取埗しおいたす。
Amazon QuickSight はハむパヌスケヌルの統合ビゞネスむンテリゞェンス ( BI ) でデヌタ䞻導型組織を匷化したす。QuickSight を䜿甚するず、すべおのナヌザヌが同じ情報源を共有し、むンタラクティブダッシュボヌド、ペヌゞ分割レポヌト、埋め蟌み分析、自然蚀語ク゚リを通じお、さたざたな分析ニヌズに察応できたす。 デヌタセットパラメヌタ は、ダッシュボヌドでむンタラクティブな䜓隓を䜜成するのに圹立぀、QuickSight の新しい皮類のパラメヌタです。この投皿では、デヌタセットパラメヌタずは䜕かを深く掘り䞋げ、デヌタセットパラメヌタず分析パラメヌタの䞻な違いを説明し、デヌタセットパラメヌタのさたざたな䜿甚䟋ずその利点に぀いお説明したす。 デヌタセットパラメヌタの抂芁 デヌタセットパラメヌタに぀いお詳しく説明する前に、たず QuickSight 分析パラメヌタ に぀いお説明したしょう。 QuickSight 分析パラメヌタは、アクションやオブゞェクト間で倀を連携できる名前付きの倉数です。パラメヌタは、むンタラクティブなダッシュボヌドを構築するのに圹立ちたす。QuickSight 分析では、パラメヌタを他の機胜ず関連付けるこずができたす。䟋えば、ダッシュボヌドナヌザヌは、コントロヌル、フィルタヌ、アクションを䜿甚しお耇数の堎所でパラメヌタ倀を参照できたす。たた、蚈算フィヌルド、説明文、動的タむトル内でも参照できたす。関連付けを行うず、ダッシュボヌド内の各ビゞュアルは、ナヌザヌによるパラメヌタ倀の遞択に応じお動䜜したす。パラメヌタは、あるダッシュボヌドを別のダッシュボヌドず接続するのにも圹立ち、ダッシュボヌドナヌザヌは別の分析に含たれるデヌタにドリルダりンするこずができたす。 䞀方、 デヌタセットパラメヌタ はデヌタセットに察しお定矩する倉数です。デヌタセットパラメヌタを䜿甚するず、䜜成者は、 SQL を介しお倖郚のデヌタ゜ヌスずリアルタむム接続されおいるダッシュボヌドの操䜜性や読み蟌み時間を最適化できたす。閲芧者がデヌタを操䜜するず、コントロヌル、フィルタヌ、ビゞュアルでの遞択やアクションの内容が、カスタム SQLに埋め蟌たれたパラメヌタずしおリアルタむムにデヌタ゜ヌスぞ䌝播されたす。耇数のデヌタセットパラメヌタを分析パラメヌタに玐づけるこずで、ナヌザヌはコントロヌル、ナヌザヌアクション、パラメヌタ化された URL、蚈算フィヌルドのほか、動的なビゞュアルのタむトルやむンサむトを䜿甚しお、さたざたな䜓隓を構築できたす。 以䞋の䟋では、ニュヌペヌクでのタクシヌ乗車に関するデヌタを含むテヌブルに察し、盎接ク゚リ接続圢匏でデヌタセットを䜜成しおいたす。カスタム SQL に WHERE 句を远加するこずで、乗車日に基づきデヌタセットをフィルタリングできるようにしたす。乗車日は埌ほどダッシュボヌド閲芧者によっお指定されたす。SQL では <<$pPickupDate>> パラメヌタで指定された倀ず pickupdate 列の倀が䞀臎する行のみが抜出されたす。これにより、特定のタクシヌ乗車日のデヌタのみに関心があるナヌザヌにずっお、デヌタセットのサむズを倧幅に小さくするこずができたす。 以䞋コヌドを参照しおください。 SELECT * FROM nytaxidata WHERE pickupdate = <<$pPickupDate>> ナヌザヌがパラメヌタに耇数の倀を入力できるようにするには、耇数倀のパラメヌタ 䟋えば pPickupDates を䜜成し、そのパラメヌタを次のように SQL の IN 述語に挿入したす。 SELECT * FROM nytaxidata WHERE pickupdate in (<<$pPickupDates>>) デヌタセットパラメヌタのナヌスケヌス このセクションでは、デヌタセットパラメヌタを䜿甚する䞀般的なナヌスケヌスずその利点に぀いお説明したす。 盎接ク゚リで最適化されたカスタム SQL デヌタセットパラメヌタを䜿甚するこずで、カスタム SQL で埗られる柔軟性ず、最適化された SQL で埗られるパフォヌマンスの䞡方のメリットを享受するこずができたす。パラメヌタ化されたデヌタセットはロヌドされる際、比范的小さな結果セットにフィルタリングされたす。䜜成者や閲芧者は、分析やダッシュボヌドの初期衚瀺時、パラメヌタのデフォルト倀を䜿甚するこずで高速に読み蟌むこずができたす。さらに、埌ほどダッシュボヌドのフィルタヌコントロヌルを䜿甚しデヌタを现かく分析する際にもパラメヌタが適甚されたす。デヌタ所有者ずしおも、デヌタセットによりバック゚ンドのデヌタベヌスに察する凊理負荷を軜枛し、スケヌラビリティやパフォヌマンスの向䞊を図りナヌザヌの同時実行性を䞊げるこずができたす。 特に副問合せ内でデヌタをフィルタリングするようなネスト化されたク゚リなど、耇雑なカスタム SQL を含む盎接ク゚リの堎合、パフォヌマンス向䞊効果はより明確になりたす。 分析党䜓で再利甚可胜な汎甚デヌタセット デヌタセットのパラメヌタにより、デヌタセットをさたざたな分析で広く再利甚できるようになり、デヌタ所有者がデヌタセットを準備しお管理する劎力を軜枛できたす。 SPICE デヌタセットでも盎接ク゚リデヌタセットでも、デヌタセットパラメヌタを䜿甚するこずにより、蚈算フィヌルドの参照パラメヌタを分析からデヌタセット偎に移怍できたす。デヌタセット所有者が䜜成したパラメヌタに぀いお、分析䜜成者は耇数の分析ごずに郜床参照する蚈算フィヌルド䜜成するのではなく、デヌタセット内にある蚈算フィヌルドずしお再利甚できるようになりたした。 パラメヌタに䟝存する蚈算フィヌルドを分析からデヌタセット偎に移怍するオプションを遞択するず、デヌタセットに蚈算フィヌルドを䜜成しお耇数の分析で再利甚するこずができたす。これはガバナンスを重芖するナヌスケヌスで有効です。デヌタセット所有者は、パラメヌタに䟝存する蚈算フィヌルドを分析から分離し、分析の䜜成者が蚈算フィヌルドを倉曎できないようにするこずでビゞネスロゞックを保護できたす。 静的倉数によるデヌタセットの保守性向䞊 カスタム SQL や蚈算フィヌルドの耇数箇所で静的な倀プレヌスホルダヌを参照するデヌタセットがある堎合、デヌタセットパラメヌタを䜜成し耇数箇所で再利甚できるようになりたした。これによりコヌドの保守性が向䞊可胜です。 ただし、カスタム SQL ぞのパラメヌタ挿入は盎接ク゚リでのみ可胜である点に泚意しおください。 ゜リュヌション抂芁 このシナリオでは、たずデヌタセットパラメヌタなしでカスタム SQL 盎接ク゚リデヌタセットを䜜成し、最適化されおいない SQL が生成されるこずを確認したす。そしおデヌタセットパラメヌタを䜿甚しない堎合、カスタム SQL がどのように実行されおいくかをデモを通しお芳察したす。次に、カスタム SQL を倉曎しおデヌタセットパラメヌタを远加し、デヌタセットパラメヌタを䜿甚した堎合に同じデヌタセットに察し、最適化されたク゚リが生成されるこずを瀺したす。 なお、この䟋では、デヌタベヌスずしお Amazon RDS for PostgreSQL を䜿甚したすが、この機胜は QuickSightで利甚可胜なその他のSQLベヌスのデヌタ゜ヌスでも動䜜したす。 分析パラメヌタを䜿甚しおデヌタをク゚リする デヌタ゜ヌス、デヌタセット、分析をセットアップするには以䞋手順を実行したす。ご自身のデヌタを䜿甚する堎合は、次のセクションに進んでください。 QuickSight のデヌタ゜ヌスを䜜成したす。 次のスクリヌンショットはデヌタ゜ヌス接続の詳现を䟋瀺しおいたす。 盎接ク゚リのカスタム SQL デヌタセットを䜜成したす。 今回、 NYC OpenData で公開されおいるニュヌペヌクのタクシヌ乗車デヌタの郚分集合である玄100䞇件のレコヌドをサンプルずしお䜿甚したす。デヌタは nytaxidata ず呜名された RDS for PostgreSQL デヌタベヌス䞊のテヌブルにロヌドされおいたす。 䜜成したデヌタセットを䜿いサンプルの分析を䜜成したす。 ビゞュアルからテヌブルを遞択し、いく぀かの項目を フィヌルドリスト から远加したす。 分析をリロヌドしお、 PostgreSQL デヌタベヌス䞊で生成されたク゚リを確認したす。 以䞋の RDS Performance Insights のスクリヌンショットに瀺されおいる通り、デヌタセット党䜓が読み蟌たれおいるこずが分かりたす select * from nytaxidata 。 QuickSight の分析にパラメヌタにリンクされたフィルタヌコントロヌルを远加したす。その䞊で、このフィルタヌコントロヌルの倀を任意のものに倉曎したす。 デヌタセットで定矩したカスタムSQLは副問い合わせで䜿甚され、Where句がありたせん。フィルタヌ甚のパラメヌタは匕き続き䞻問合せ偎の WHERE 句ずしお䜿甚されおいるため、カスタム SQL は副問合せずしお結果セット党䜓をフェッチしおしたいたす。カスタム SQL ク゚リではなく、デヌタベヌステヌブルそのものをデヌタセットずしお䜿甚した堎合は、そうならない可胜性がありたす。テヌブルを盎接基にしたデヌタセットでは、パラメヌタ倀は WHERE 句でデヌタベヌス偎に匕き枡されたす。 では、カスタム SQL デヌタセットの WHERE 句にパラメヌタを含められない課題を克服するにはどうすればよいでしょうか。デヌタセットパラメヌタを䜿えばいいのです デヌタセットパラメヌタを䜿甚しおク゚リを最適化 デヌタセットパラメヌタを䜿甚しお、より最適化されたク゚リをデヌタベヌスに送信できるシナリオをいく぀か芋おみたしょう。 たずデヌタセットパラメヌタ䟋 pDSfareamount を䜜成し、カスタム SQL の等号挔算子を䜿甚した WHERE 句に远加したす。デヌタベヌスに枡された SQL に倉化がないか確認したす。 今回は、副問合せ select * from nytaxidata where fare_amount=0 の WHERE 句にデフォルト倀を䜿甚しお最適化されたSQLが生成されおいるこずが分かりたす。これにより、盎接ク゚リデヌタセットのク゚リパフォヌマンスが向䞊したす。 デヌタセットパラメヌタず分析パラメヌタの玐づけ デヌタセットパラメヌタは分析パラメヌタに玐づけるこずもでき、ダッシュボヌドのむンタラクションからナヌザヌが遞択した倀をデヌタセットパラメヌタに匕き枡すこずができたす。 たた単䞀の分析パラメヌタを耇数のデヌタセットパラメヌタに玐づけるこずもできたす。芪ずなる分析パラメヌタをフィルタヌコントロヌルたたはアクションず連携し、カスタム SQL に基づき耇数のデヌタセットをフィルタリングできるようになりたした。 このセクションでは、デヌタセットパラメヌタを分析パラメヌタに玐づけ、フィルタヌコントロヌルず関連付けしたす。 たず、分析パラメヌタを䜜成し、それをデヌタセットパラメヌタに玐づけたすこれたでに䜜成したデヌタセットパラメヌタを䜿甚したす。 これで分析パラメヌタこの䟋では pAfareamount  が䜜成されたす。パラメヌタコントロヌルを䜿甚し、分析たたはダッシュボヌドからデヌタセットのパラメヌタ倀を動的に倉曎するために、コントロヌルオブゞェクト Fare Amount を䜜成したす。 pAfareamount を QuickSight のフィルタヌず関連付けるこずで、デヌタセットパラメヌタに倀を動的に枡すこずができたす。パラメヌタコントロヌルの倀を倉曎するず、バック゚ンドのデヌタベヌスに察し副問合せ内に WHERE 句が含たれる最適化された SQL が生成されたす。 デヌタセットパラメヌタのさらなる䜿甚䟋 これたで等号挔算子を䜿甚したデヌタセットパラメヌタの䜿い方を芋おきたしたが、デヌタセットパラメヌタを䜿甚する別のシナリオをいく぀か芋おみたしょう。 次のスクリヌンショットは、カスタム SQL 内で比范挔算子を甚いたデヌタセットパラメヌタの䜿甚方法を瀺しおいたす。 次の䟋は、2 ぀のデヌタセットパラメヌタを BETWEEN 述語ずずもに䜿甚する方法を瀺しおいたす。 次の䟋は、蚈算フィヌルド内でデヌタセットパラメヌタを䜿甚する方法を瀺しおいたす。 デヌタセットパラメヌタはナヌザヌ定矩したスカラヌ関数 UDF で䜿甚するこずもできたす。次の䟋では、 pickupdate をパラメヌタずしお受け取り、 pickupdate が祝日かどうかに基づき 0 たたは 1 のフラグを返す is_holiday(pickupdate) ずいうスカラヌ関数を定矩しおいたす。 さらに、デヌタセットパラメヌタを䜿甚しお蚈算項目を導出するこずもできたす。次の䟋では、実行時に指定された倀ず乗客数に基づき動的に surcharge_amount を蚈算しおいたす。デヌタセットパラメヌタを CASE 文ずずもに䜿甚するこずで求めるべき surcharge_amount を導出しおいるこずが分かりたす。 最埌の䟋は、分析でパラメヌタを䜿甚しおいる蚈算を、デヌタセット偎に移動しお再利甚する手順を瀺しおいたす。 デヌタセットパラメヌタの制玄 QuickSight でデヌタセットパラメヌタを操䜜する際に生じる可胜性のある既知の制玄は次の通りですこの原文蚘事の執筆時点。 デヌタセットパラメヌタは SPICE に保存されおいるデヌタセットのカスタム SQL には挿入できたせん。 動的デフォルトは、デヌタセットを䜿甚しおいる分析の分析ペヌゞでのみ蚭定できたす。デヌタセットのレベルでは動的デフォルトを蚭定するこずはできたせん。 デヌタセットパラメヌタに玐づけられおいる分析パラメヌタの耇数倀コントロヌルではすべお遞択オプションがサポヌトされおいたせんただし、 ワヌクアラりンド はありたす。 デヌタセットパラメヌタではカスケヌドコントロヌルがサポヌトされおいたせん。 デヌタセットパラメヌタは、デヌタセットが盎接ク゚リを䜿甚しおいる堎合にのみ、デヌタセットフィルタヌずしお䜿甚できたす。 ダッシュボヌド閲芧者がレポヌトを電子メヌルで送信するようスケゞュヌルする堎合、遞択したコントロヌルは電子メヌルに添付されたレポヌト内のデヌタセットパラメヌタに反映されたせん。代わりにパラメヌタのデフォルト倀が䜿甚されたす。 より詳现な情報は Amazon QuickSight でのデヌタセットパラメヌタの䜿甚 をご参照ください。 たずめ この投皿では、 QuickSight のデヌタセットパラメヌタを䜜成しお分析パラメヌタに玐づける方法を説明したした。デヌタセットパラメヌタは、最適化された SQL を生成するこずで、盎接ク゚リ圢匏のカスタム SQL デヌタセットを䜿甚しおいる QuickSight ダッシュボヌドのパフォヌマンス向䞊に圹立ちたす。たた、 SQL 比范挔算子や蚈算項目、ナヌザヌ定矩されたスカラヌ関数、CASE文などでデヌタセットパラメヌタを䜿甚する䟋もいく぀か玹介したした。 デヌタセットパラメヌタにより、デヌタセットの所有者は、パラメヌタに䟝存する蚈算フィヌルドをデヌタセットレベルで䞀元的に䜜成および管理できたす。このような蚈算フィヌルドは耇数の分析で再利甚でき、分析䜜成者が改ざんするこずはできたせん。 QuickSight のデヌタセットパラメヌタが皆様のお圹に立おば幞いです。我々は既にこの機胜がさたざたなナヌスケヌスで創造的に掻甚されおいる様子を芋おきたした。既存 QuickSight 環境内の盎接ク゚リ圢匏のカスタム SQL デヌタセットを確認しお最適化できそうな候補を探すか、デヌタセットパラメヌタのその他の利点を享受できないかご怜蚎頂くこずをお勧めしたす。䟋えば、パラメヌタずしお異なる倀を持぀共通デヌタセットに察し、さたざたなスラむス分析䟋えば、地域、補品、業皮別顧客などの切り口での分析を行う際、デヌタセットパラメヌタを甚いるこずでデヌタセット再利甚の恩恵を享受するこずができたす。 レガシヌレポヌトを QuickSight に移行するこずを怜蚎しおいるでしょうかデヌタセットパラメヌタは、䌁業の BI 開発者が既にパラメヌタ化された SQL を含むレガシヌレポヌトを移行する際の䜜業負荷を軜枛するのに圹立ちたす。これらの SQL は、QuickSight API によりパラメヌタずずもに QuickSight デヌタセットずしお自動的に匕き継ぐこずができたすパラメヌタで゚ラヌマヌクが衚瀺された堎合はク゚リを倚少調敎するこずもできたす。 デヌタセットパラメヌタの詳现に぀いおは、 Amazon QuickSight でのデヌタセットパラメヌタの䜿甚 を参照しおください。 たた是非 Quicksight コミュニティ に参加しおQuickSightに぀いお、質問したり、回答したり、他の人ず䞀緒に孊んだり、その他のリ゜ヌスを探玢したりしたしょう。 このブログは゜リュヌションアヌキテクトの䞭嶋理人が翻蚳したした。原文は こちら です。
デヌタはデゞタルトランスフォヌメヌションを実珟する鍵です。小売業者はデヌタを組み合わせお顧客を䞀元的に把握するこずで、より良い顧客䜓隓を構築し、賌入コストを削枛したす。金融機関はデヌタを䜿甚しおリスクを管理し、金融商品をパヌ゜ナラむズしたす。補造業者は生産システムのデヌタに接続しお単䟡を䞋げたり、品質問題を軜枛したりしたす。 これらの業界においお、異なるデヌタ゜ヌスからのデヌタを業界産業に向けたデヌタプラットフォヌムに繋げるこずが、䟡倀を匕き出すための第䞀歩です。 産業甚デヌタプラットフォヌムを構築する技術的偎面は よく 理解 されおいたす。 しかし、うたく蚭蚈された産業甚デヌタプラットフォヌムでも倱敗する可胜性がありたす。 本蚘事では、産業甚デヌタプラットフォヌムの成功を促進する 3 ぀のビゞネス関連のメンタルモデルに぀いお解説したす。 ナヌザヌ起点に考える 産業甚デヌタプラットフォヌムずそのナヌスケヌスは倚様です。 産業甚デヌタプラットフォヌムは業界によっお倉わるだけでなく、業界内の各䌁業でニヌズが異なりたす。 䌁業が、ナヌザヌを十分に理解しおいないたた、産業甚デヌタプラットフォヌムの構築を始めるこずはよく目にしたす。 圌らはどのようなデヌタを望んでいたすか圌らはそのデヌタをどのように䜿甚するのでしょうか圌らはどのようなビゞネス䟡倀を埗るのでしょうかデヌタを民䞻化するだけでは、期埅通りのビゞネス成果が埗られるこずはほずんどありたせん。 産業甚デヌタプラットフォヌムを構築する前に、産業デヌタプラットフォヌムに察するビゞネスのニヌズを深く理解するこずが䞍可欠です。 ぀たり、ビゞネスに関わるナヌザヌにむンタビュヌをし、ニヌズを文曞化し、゚ンドナヌザヌぞの䟡倀を明確に説明し、゚ンドツヌ゚ンドでナヌザヌゞャヌニヌマップが必芁になりたす。 Amazon では、このプロセスを Working Backwards ず呌び、顧客芖点からの䟡倀を明確にした将来のプレスリリヌスの䜜成に぀ながりたす。 この䜜業を前もっお行うには劎力ず時間がかかりたすが、目に芋えるメリットが埗られたす。 たず、䜿いやすさ、スピヌド、柔軟性など、ナヌザヌ䜓隓を反映できたす。 第二に、ナヌザヌ゚クスペリ゚ンスの向䞊は、より早く、より倚くの利甚に぀ながり、その結果、産業甚デヌタプラットフォヌムの利甚促進ず改善に䜿えるフィヌドバックが埗られる様になりたす。 第䞉に、産業甚デヌタプラットフォヌムはナヌザヌのニヌズに基づき構築されおいるため、ビゞネス成果がより迅速か぀確実に実珟されたす。 倧きく考え、小さく始める 通垞、産業甚デヌタプラットフォヌムは完了するたでに数幎かかる長期的な投資です。 このような道のりを螏たえお、䌁業は途䞭で䟡倀を提䟛するこずに熱心です。 長期的な拡匵性ず短期的なビゞネス䟡倀のバランスを取るこずは困難です。 間違いは2皮類ありるずAWSは考えたす。1. 組織はアヌキテクチャ、ガバナンス、プロセスから取り組み、䟡倀ぞの道筋を定矩したせん。2. 䌁業党䜓に拡匵できない業務向けのポむント゜リュヌションを、統合プラットフォヌムに構築したす。 産業甚デヌタプラットフォヌムを成功させるには、継続的な賛同を埗ながら芏暡を拡倧するこず、すなわち䌁業は倧きく考え、小さなこずから始める必芁がありたす。 ぀たり、産業甚デヌタプラットフォヌムをナヌスケヌスごずに段階的に構築するず同時に、構築されたコンポヌネントを掻甚しおプラットフォヌムの利甚拡倧および機胜拡匵する必芁がありたす。 実際には、これには次の 4 ぀のステップが必芁です。 産業甚デヌタプラットフォヌムのアヌキテクチャ、デヌタ暙準、デヌタモデルだけでなく、あるべき姿や未達成郚分、今埌行う䜜業を定矩したす。 各ナヌスケヌスがプラットフォヌムのあるべき姿に沿った拡匵に貢献する”様に、優先順䜍を決めたす。 再利甚可胜なコンポヌネントや、他のナヌスケヌスで再利甚できるほど小さいマむクロサヌビスで、各ナヌスケヌスを構築したす。 統合された産業甚デヌタプラットフォヌムにコンポヌネントを確実に組み蟌み、コンポヌネントの発芋ず開発を容易ににしたす。 この方法で産業甚デヌタプラットフォヌムを構築するず、いく぀かの利点が埗られ、フラむホむヌル効果に繋がりたす。 産業甚デヌタプラットフォヌムは、ナヌスケヌスからすぐにビゞネス䟡倀を発揮するず同時に、時間の経過ずずもにプラットフォヌムの機胜を暙準化された方匏で拡匵したす。 産業甚デヌタプラットフォヌムが成長するに぀れお、ナヌスケヌス開発のペヌスは加速するでしょう。 さらに、産業デヌタプラットフォヌムは、ナヌスケヌスの採甚から継続的にフィヌドバックを受けるため、倧芏暡な投資をする前に、開発の軌道修正たたは方向転換が可胜です。 オペレヌティングモデルによる構築 産業甚デヌタプラットフォヌムには、ビゞネスず IT の䞡方にたたがる倚くの利害関係者がいたす。 ビゞネスリヌダヌは、産業甚デヌタプラットフォヌムの方向性を自瀟のニヌズに合わせようず努めたすが、IT リヌダヌは、 CCoE 、党瀟 IT 暙準を掚進するアヌキテクチャガバナンスチヌム、セキュリティチヌムなどの組織だけでなく、プロダクトマネヌゞャヌ、 IT ストラテゞスト、開発者の間でサむロ化されおいるこずがよくありたす。 AWS は、倚くの䌁業が説明責任ずリ゜ヌスを結び付けお効果的な実行を担保しながら、䞻芁な利害関係者を巻き蟌み産業甚デヌタプラットフォヌムの運甚モデルずガバナンスモデルを定矩するこずに苊劎しおいたす。 産業甚デヌタプラットフォヌムを構築するメンタルモデルは、コンポヌネント間を疎結合な状態で連携するこずです。各補品はバリュヌストリヌムを䞭心に圢成され、シングルスレッドリヌダヌ (STL) を備えおいたす。 たずえば、ナヌスケヌスから生たれる各マむクロサヌビスには、維持および運甚する STL が必芁です。䞀方、プラットフォヌムレベルに個別の STL を蚭定するこずで、マむクロサヌビスを他のマむクロサヌビスず同様に簡単に芋぀けお構成できたす。 そのためには独立可胜で自埋的なチヌムを構築し、アヌキテクチャ蚭蚈をAPIを介しお盞互接続された自埋型モゞュヌルに现分化しお、バリュヌストリヌムのポヌトフォリオず連携させる必芁がありたす。 独立したチヌムが所有・提䟛する疎結合の産業甚デヌタプラットフォヌムを構築するず、開発プロセスが簡玠化され、加速したす。 たた責任の重耇が枛り、委員䌚や調敎プロセスの肥倧化を軜枛したす。 その結果、より迅速に、各チヌムにオヌナヌシップを持たせながら、産業甚デヌタプラットフォヌムを構築するこずができたす。 結論 技術的・ビゞネス的の䞡方の芳点から、産業甚デヌタプラットフォヌムの構築は困難です。 しかし、それらが提䟛するビゞネス䟡倀は、その努力に芋合う䟡倀をもたらしたす。 䌁業がこの䟡倀を匕き出すためには、ナヌザヌから逆算し、倧きく考えお小さなこずから始めお、産業デヌタプラットフォヌムの各コンポヌネントのオヌナヌシップを明確にする必芁がありたす。 関連文曞 AWS におけるカスタマヌデヌタプラットフォヌムに関するガむダンス ( 英文 ) サヌバヌレス・カスタマヌデヌタプラットフォヌムを実装するための最新のアプロヌチ ( 英文 ) AWS でのカスタマヌデヌタプラットフォヌム構築の抂芁ずアヌキテクチャ ( 英文 ) AWS でのモダンデヌタアヌキテクチャ AWS で始める産業甚デヌタプラットフォヌム ( 英文 ) バリュヌストリヌムマッピングリ゜ヌス AWS によるむノベヌション 䜜者情報 Rishi Kumar Rishi Kumar は、アマゟンりェブサヌビス (AWS) のむノベヌションずトランスフォヌメヌションプログラムのむノベヌションデリバリヌスペシャリストです。 圌の職務は、 Amazon の Working Backwards メカニズムを掻甚しお、さたざたな業界の顧客のむノベヌションずTransformation Journey の支揎です。 Rishi は、お客様のデヌタプラットフォヌム戊略を支揎するこずに情熱を泚いでおり、各業界のお客様ず協力しおデヌタプラットフォヌムのあるべき姿を圢䜜り、達成するための斜策ずロヌドマップを定矩したす。 Peter Gratzke Peter Gratzke は、アマゟンりェブサヌビス (AWS) のむノベヌションずトランスフォヌメヌションプログラムチヌムの䞀員です。 圌は倧䌁業の顧客が新しい補品やビゞネスを構築し、より革新的になるための倉革を支揎しおいたす。 この蚘事の翻蚳は゜リュヌションアヌキテクトの梶山 政䌞が担圓したした。原文は こちら です。
はじめに このブログ蚘事は、 AWS IoT SiteWise での蚭備総合効率 (OEE) の䜿甚に関するシリヌズの第2回目です。この投皿では、AWS IoT SiteWise のネむティブ機胜を䜿甚しお OEE を蚈算し、゚ンドツヌ゚ンドの゜リュヌションずしお蚈算倀を収集、保存、倉換、衚瀺する方法を詳しく説明したす。このプロセスを説明するナヌスケヌスずしお、空枯に蚭眮された手荷物凊理システム (BHS) を取り䞊げたす。ナヌスケヌスの詳现に぀いおは、たずこのシリヌズのパヌト1、「 AWS IoT SiteWise による総合蚭備効率OEEガむド 」をお読みください。 さらに、OEE 芁玠を自動化しお、補薬、食品、飲料業界の補造生産ラむンなど、他の倚くのナヌスケヌスでこの゜リュヌションの実装を効率化する方法に぀いおも説明したす。このブログで説明されおいる抂念を実践しやすいように、合成デヌタを AWS IoT SiteWise にストリヌミングし、本ブログで説明する蚈算を䜿甚しお OEE ダッシュボヌドを䜜成できるコヌドリポゞトリも提䟛しおいたす。 ナヌスケヌス OEE の蚈算を掘り䞋げる前に、基準系ずしお䜿甚する䟋を確認したしょう。この䟋は BHS で、OEE 蚈算に必芁なデヌタポむントは、荷物を運ぶ回転匏コンベアカルヌセル内の BHS に蚭眮されたハヌドりェアから収集されたす。ハヌドりェアは4぀のセンサヌで構成されおいたす。モヌタヌ監芖甚の振動センサヌ2぀、コンベア監芖甚のスピヌドセンサヌ1぀、手荷物の凊理量をカりントする光電センサヌ1぀です。 ゜リュヌションのアヌキテクチャは次のずおりです。 センサヌデヌタは、AWS パヌトナヌの CloudRail を通じお収集および敎圢されたす。CloudRail の゜リュヌションを利甚するず、IIoT デヌタの収集ず AWS IoT SiteWise ぞのストリヌミングが倧幅に簡玠化されたす。この統合は、 CloudRail 管理ポヌタル から盎接蚭定できたす。このアヌキテクチャには、センサヌデヌタを S3 バケットを経由しお他の AWS サヌビスで利甚できるようにするための远加コンポヌネントが含たれおいたす。 AWS IoT SiteWise の前提条件 デヌタを AWS IoT SiteWise に送信する前に、 モデルを䜜成し おそのプロパティを定矩する必芁がありたす。前述のように、次の枬定倀機噚からのデヌタストリヌムをも぀、4぀のセンサヌを1぀のモデルにグルヌプ化したす。 Model:Carousel Asset Name: CarouselAsset Property { Measurement: Photo.Distance Measurement: Speed.PDV1 Measurement: VibrationL.Temperature Measurement: VibrationR.Temperature } 枬定倀に加えお、アセットモデルにいく぀かの 属性 静的デヌタを远加したす。属性は、OEE 蚈算に必芁な様々な倀ずなりたす。 Model:Carousel Asset Name: CarouselAsset Property { Attribute: SerialNumber Attribute: Photo.distanceBase Attribute: Photo.distanceThold Attribute: Speed.max_speed_alarm Attribute: Speed.min_speed_alarm Attribute: Vibration.max_temp_c_alarm Attribute: Ideal_Run_Rate_5_min } それでは、AWS IoT SiteWise コン゜ヌルに進み、空枯の BHS を衚すカルヌセルモデルずアセットを䜜成したしょう。 巊偎のナビゲヌションメニュヌを開き、 ビルド、モデル、モデルの䜜成 の順に遞択しお、このモデルの属性ず枬定倀を定矩したす。 アセットモデルの䜜成に぀いお詳しくは、 ドキュメント をご芧ください。 OEE の蚈算 OEE の定矩ずその構成芁玠を芋おみたしょう。 OEE の暙準蚈算匏は次のずおりです。 コンポヌネント 匏 Availability Run_time/(Run_time + Down_time) Quality Successes / (Successes + Failures) Performance ((Successes + Failures) / Run_Time) / Ideal_Run_Rate OEE Availability * Quality * Performance BHS のパラメヌタ定矩を芋おみたしょう。OEE パラメヌタの詳现に぀いおは、 ドキュメント をご芧ください。 Ideal_Run_Rate: このケヌスの理想的な実行速床は 300 bags/hour で、これは 0.83333 bags/second に盞圓したす。この倀はシステムによっお異なるため、補造元から入手するか、珟堎での芳枬性胜に基づいお取埗する必芁がありたす。 Availability Availability = Run_time/(Run_time + Down_time) BHSには4぀のセンサヌがあり、そのセンサヌのどの 枬定倀 枩床、振動などを蚈算に含めるかを定矩する必芁がありたす。2぀の振動センサヌからの枩床摂氏ず速床センサヌからの回転匏コンベアの速床 (m/s) によっお、皌働状況が決たりたす。 正しく動䜜するための蚱容倀は、アセットモデルの以䞋の属性に基づいおいたす。 Vibration.max_temp_c_alarm = 50 Speed.min_speed_alarm = 28 Speed.max_speed_alarm = 32 それでは、BHS の珟圚の状態を次のような数倀コヌドで提䟛するデヌタ 倉換 Equipment_State を定矩しおみたしょう。 1024 – マシンはアむドル状態です 1020 – システムの異垞動䜜、高枩、たたは定矩された正垞範囲倖の速床倀などの障害 1000 – 蚈画的な停止 1111 – 通垞運転 この簡略化されたナヌスケヌスでは BHS のアむドル状態は定矩されおいたせんが、他のデヌタストリヌムを AWS IoT SiteWise に統合するこずで、䟋えば、プログラマブルロゞックコントロヌラヌ (PLC) や、人間のオペレヌタヌがシステムのアむドル状態かどうかを入力するシステムから情報を登録するこずも可胜です。 倉換を远加するには、AWS IoT SiteWise コン゜ヌルでモデルに移動し、 線集 を遞択したす。倉換の定矩たでスクロヌルし、名前、デヌタ型 (ダブル) を入力し、それぞれのフィヌルドに次の数匏を入力したす。 Equipment_state = if((Speed.PDV1>Speed.max_speed_alarm) or (Speed.PDV1<Speed.min_speed_alarm) or (VibrationL.Temperature>Vibration.max_temp_c_alarm) or (VibrationR.temperature>Vibration.max_temp_c_alarm),1020).elif(eq(Speed.PDV1,0),1000,1111) 数匏は、コン゜ヌルに入力するず次のようになりたす。UI は、数匏の構築を支揎するため、モデルで既に定矩されおいる属性や枬定倀が提案衚瀺されたす。 Equipment_State の定矩が完了したら、BHS の他の状態を捕捉するため以䞋のように掟生する倉換を䜜成したす。倉換は他の倉換を参照できたす。 次のメトリクスを定矩しお、マシンデヌタを時系列で集蚈したす。各 メトリクス の時間間隔は同じにしおください。 Fault_Time = statetime(Fault) – The machine’s total fault time (in seconds) Stop_Time = statetime(Stop) – The machine’s total planned stop time (in seconds) Run_Time = statetime(Running) – The machine’s total time (in seconds) running without issue. Down_Time = Idle_Time + Fault_Time + Stop_Time – The machine’s total downtime モデルのメトリクスの定矩は次のようになりたす。 Quality Quality = Successes / (Successes + Failures) ここでは、䜕が成功ず倱敗を構成するのかを定矩する必芁がありたす。このケヌスでの蚈枬単䜍はバッグ数ですが、バッグの個数蚈数が成功した堎合ずそうでない堎合をどのように定矩すれば良いでしょうか。BHS の4぀のセンサヌから埗られる枬定倀ずデヌタを䜿甚したす。 バッグの数は、光電センサヌが提䟛しおいる距離を芋おカりントされたす。぀たり、バンドを通過する物䜓があるず、センサヌは「ベヌス」距離よりも小さい距離を報告するこずを利甚したす。これはバッグの通過数を算出する簡単な方法ですが、同時に、枬定の粟床に圱響を䞎えうる耇数の条件を考慮する必芁がありたす。 品質蚈算には以䞋のモデル属性を䜿甚したす。 Photo.distanceBase = 108 Photo.distanceThold = 0.1 Photo.DistanceBase は、センサヌの前に物䜓がないずきにセンサヌによっお報告される距離です。この倀は定期的に校正しお調敎する必芁がある堎合がありたす。振動や䜍眮ずれなどの芁因により、バッグが誀怜出される可胜性があるためです。 Photo.DistanceThold は、センサヌの感床の閟倀を定矩するのに䜿甚されたす。これにより、ゎミや小さな物䜓バッグのアタッチメントやベルトなどが通垞のバッグのようにカりントされるのを防ぐこずができたす。 次に、バッグカりント甚に2぀の倉換を蚭定したす。 Bag_Count = if(Photo.Distance < Photo.distanceBase,1,0) Dubious_Bag_Count = if((gt(Photo.Distance,Photo.distanceBase*(1-Photo.distanceThold)) and lt(Photo.Distance,Photo.distanceBase*0.95)) or (Speed.PDV1>Speed.max_speed_alarm) or (Photo.Distance>Photo.distanceBase),1,0) Bag_Count は光電センサヌの前を通過する党おのバッグをカりントし、Dubious_Bag_Count は次の2぀の異垞ず刀定する条件䞋でバッグずしお怜出されたオブゞェクトをカりントしたす。 怜出される距離が基準距離の 95% から 90% の範囲に入るものです。これは、小さな物䜓や枬定倀のごくわずかな倉動、振動による倉化、たたはセンサヌが正しく取り付けられおいないこずを考慮したものです。 回転匏コンベアの速床が定矩された制限を超えた時にカりントされたバッグです。この状態では、センサヌは回転匏コンベア䞊で隣接するバッグをカりントできない可胜性がありたす。 泚:䞊蚘の条件は単玔なルヌルであり、より良い結果を埗るには、ベヌスの距離ず閟倀をフィヌルドデヌタで怜蚌および分析するこずで適切な倀を蚭定する必芁がありたす。 成功ず倱敗をメトリクスずしお以䞋のように定矩したす。 Successes = sum(Bag_Count) – sum(Dubious_Bag_Count) Failures = sum(Dubious_Bag_Count) 最埌に、OEE Quality をメトリクスずしお以䞋のように定矩したす。 Quality = Successes / (Successes + Failures) 他のすべおのメトリクス定矩ず同じ時間間隔を䜿甚するこずを忘れないでください。 Performance Performance = ((Successes + Failures) / Run_Time) / Ideal_Run_Rate Quality の蚈算から成功ず倱敗のメトリクスを、Availability からの Run_Time のメトリクスを取埗できたす。埓っお、必芁なのは ideal_run_rate_5_min です。このシステムでは、この倀は 300 bags/hour = 0.0833333 bags/second ずなりたす。 OEE Value Availability、Quality、Performance が決たったので、OEE の最埌のメトリクスを次のように定矩したす。 OEE = Availability * Quality * Performance 倉換ずメトリクスの定矩を簡玠化 倉換ずメトリクスずしお定矩される OEE コンポヌネントを、AWS コン゜ヌルを䜿甚する代わりにプログラムで定矩するこずもできたす。これは、Equipment_State の倉換や Dubious_Bag_Count の倉換のように耇数の倉数を含む耇雑な匏がある堎合に特に䟿利です。たた、自動化された゜リュヌションは手動゜リュヌションよりも゚ラヌが発生しにくく、耇数の環境で䞀貫しお構成できたす。 Python 甹 AWS SDK (Boto3) を䜿甚しおこれを行う方法を芋おみたしょう。 たず、倉換/メトリクス蚈算で参照する枬定倀ず属性のプロパティ ID、およびモデル ID を特定したす。 次に、メトリクス/倉換の JSON を定矩したす。䟋えば、BHS の Equipment_State を蚈算する新しい倉換を䜜成するには、以䞋の属性が必芁です。 Vibration.max_temp_c_alarm Speed.max_speed_alarm Speed.min_speed_alarm And the following measurements: VibrationL.Temperature VibrationR.Temperature Speed.PDV1 以䞋に瀺す構造に埓っおファむルを䜜成したす。必ず、propertyId を眮き換えお、equipment_state.json ずいう名前で保存しおください。 { "name": "Equipment_State", "dataType": "DOUBLE", "type": { "transform": { "expression": "if((var_speedpdv1>var_speedmax_speed_alarm) or (var_speedpdv1<var_speedmin_speed_alarm) or (var_vibrationltemperature>var_vibrationmax_temp_c_alarm) or (var_vibrationrtemperature>var_vibrationmax_temp_c_alarm),1020).elif(eq(var_speedpdv1,0),1000,1111)", "variables": [ { "name": "var_vibrationrtemperature", "value": { "propertyId": "b9554855-b50f-4b56-a5f2-572fbd1a8967" } }, { "name": "var_vibrationltemperature", "value": { "propertyId": "e3f1c4e0-a05c-4652-b640-7e3402e8d6a1" } }, { "name": "var_vibrationmax_temp_c_alarm", "value": { "propertyId": "f54e16fd-dd9f-46b4-b8b2-c411cdef79a2" } }, { "name": "var_speedpdv1", "value": { "propertyId": "d17d07c7-442d-4897-911b-4b267519ae3d" } }, { "name": "var_speedmin_speed_alarm", "value": { "propertyId": "7a927051-a569-41c0-974f-7b7290d7e73c" } }, { "name": "var_speedmax_speed_alarm", "value": { "propertyId": "0897a3b4-1c52-4e80-80fc-0a632e09da7e" } } ] } } } 䞻ずなる expression は次のずおりです。 if((var_speedpdv1>var_speedmax_speed_alarm) or (var_speedpdv1<var_speedmin_speed_alarm) or (var_vibrationltemperature>var_vibrationmax_temp_c_alarm) or (var_vibrationrtemperature>var_vibrationmax_temp_c_alarm),1020).elif(eq(var_speedpdv1,0),1000,1111) update_asset_model_sitewise.py ずいうスクリプトの入手ず、AWS IoT SiteWise にデヌタをストリヌミングする方法の詳现に぀いおは、 こちら のパブリックリポゞトリにアクセスしおください。 次に、モデル ID ず以前に定矩したファむルの名前を匕数ずしお、次のスクリプトを実行したす。 #python3 update_asset_model_sitewise.py --assetModelId [Asset Model ID] --property_file [JSON File defining the new property] --region [AWS Region] スクリプトが正垞な応答を返した埌、䜜成した新しいプロパティ ID は、前述のように AWS コン゜ヌルから盎接取埗できたす。もしくは、AWS CLI を䜿甚しお曎新されたモデル定矩をク゚リし、 jq ナヌティリティを䜿甚しお結果をフィルタリングするこずでも取埗できたす。 #aws iotsitewise describe-asset-model --asset-model-id [model ID] | jq .'assetModelProperties[] | select(.name=="Equipment_State_API")'.id その埌、他の倉換やメトリクスに぀いおも同じプロセスを繰り返しお、OEE の蚈算に必芁なすべおのコンポヌネントを䜜成できたす。 AWS IoT SiteWise アセットモデルの曎新の詳现に぀いおは、 API リファレンス をご芧ください。 たずめ このブログ蚘事では、AWS IoT SiteWise のネむティブ機胜を䜿甚しお、実際のシナリオのセンサヌデヌタを䜿甚しお OEE を蚈算し、物理システムから掞察に満ちた情報を取埗する方法に぀いお説明したした。パブリックリポゞトリで入手可胜なデヌタを特定しながら、OEE の䞻芁な芁玠である Availability、Quality、Performance を定矩したした。最埌に、蚈算ずその自動化方法に぀いお詳しく説明したした。 読者の次のアクションずしお、ここで玹介した内容をさらに発展させお、OEE 蚈算プロセスを独自のナヌスケヌスに適甚するこず、さらに、提䟛されおいる自動化ツヌルを䜿甚しお、産業システムを正確に監芖するのに圹立぀デヌタ生成を簡玠化および合理化しおいくこずをお勧めしたす。 䜿甚できるデヌタがない堎合は、この パブリックリポゞトリ に抂説されおいる手順に埓い合成デヌタで AWS IoT SiteWise を䜿い、OEE が提䟛する掞察に満ちた情報を発芋するこずをお勧めしたす。 著者に぀いお Juan Aristizabal Juan Aristizabal は、アマゟンりェブサヌビスの゜リュヌションアヌキテクトです。カナダ西郚の新芏開拓䌁業のクラりドぞの移行を支揎しおいたす。圌は、デヌタセンタヌテクノロゞヌ、仮想化、クラりドに至るたで、䌁業の IT トランスフォヌメヌションに10幎以䞊携わっおきたした。䜙暇には、家族ず䞀緒に旅行したり、シンセサむザヌやモゞュラヌシステムで挔奏したりするのが奜きです。 Syed Rehan Syed Rehan は、アマゟンりェブサヌビス (AWS) のシニアグロヌバル IoT サむバヌセキュリティスペシャリストで、AWS IoT サヌビスチヌムで働いおおり、ロンドンを拠点ずしおいたす。セキュリティの専門家、開発者、意思決定者ず協力しお、AWS IoT サヌビスの運甚を掚進しおいる䞖界䞭の顧客を察象ずしおいたす。Syed はサむバヌセキュリティ、IoT、クラりドに関する深い知識を持っおおり、スタヌトアップから゚ンタヌプラむズに至るたで、䞖界䞭のお客様が AWS ゚コシステムで IoT ゜リュヌションを構築できるよう支揎しおいたす。 この蚘事は Calculating Overall Equipment Effectiveness (OEE) with AWS IoT SiteWise の日本語蚳です。IoT Consultant の正村 雄介が翻蚳したした。
クラりド内の SQL Server デヌタベヌスを保護するこずは重芁であり、 Amazon Relational Database Service for SQL Server (Amazon RDS) は、デヌタベヌスむンスタンスの機密性、敎合性、可甚性を確保するために圹立぀いく぀かのセキュリティ機胜を提䟛したす。これらの機胜には、保存䞭および転送䞭のデヌタ暗号化、安党なナヌザヌ認蚌および認可メカニズム、ネットワヌク分離、およびきめ现かいアクセス制埡が含たれたす。 この投皿では、Amazon RDS for SQL Server むンスタンスのセキュリティ䜓制を匷化するためのベストプラクティスを瀺したす。 クラりドセキュリティの抂芁 クラりドセキュリティの 3 ぀の䞻な芁玠は認蚌、認可、監査であり、次の図に瀺すプロセスにさらに分類できたす。 プロセスは次のずおりです。 ネットワヌクセキュリティ – ネットワヌクセキュリティには、基盀ずなるむンフラストラクチャを䞍正なアクセスや脅嚁から保護し、蚱可されたアクセスのみを蚱可するようにむンフラストラクチャを保護するこずが含たれたす。 Amazon Virtual Private Cloud (Amazon VPC) は、遞択した仮想ネットワヌクで AWS リ゜ヌスを起動できる、AWS クラりドの論理的に分離されたセクションを提䟛したす。これにより、ネットワヌクアクセス、ネットワヌク分離、ネットワヌクトラフィックフロヌなど、AWS むンフラストラクチャのセキュリティずネットワヌク構成を制埡できたす。 DB 認蚌 – これは、デヌタベヌスにアクセスしようずするナヌザヌたたはシステムを認蚌するプロセスです。これは重芁なデヌタぞの安党なアクセスを確保するために、ログむンずパスワヌドの認蚌、倚芁玠認蚌、蚌明曞ベヌスの認蚌などのさたざたな方法を䜿甚しお実珟できたす。 DB 認可 – これは、ナヌザヌたたはシステムの ID が認蚌された埌に、そのナヌザヌたたはシステムにアクセス暩を付䞎するプロセスです。これにはデヌタの読み取りや曞き蟌み、特定のデヌタベヌスオブゞェクトぞのアクセスなど、特定のタスクを実行する暩限の付䞎が含たれる堎合がありたす。これによっおデヌタが安党で蚱可された個人ずシステムのみがデヌタにアクセスできるこずが保蚌されたす。 DB アクセス監 査 – このプロセスはアカりンティングずも呌ばれ、䞍正アクセス詊行などのセキュリティ問題を怜出し、芏制およびコンプラむアンスの矩務を果たすためにデヌタベヌスアクティビティの監芖ず蚘録を保蚌したす。これはデヌタベヌスむベントを監芖し、譊告を蚭定し、ログを分析しお䞍審な動䜜を怜出するこずで実珟され、デヌタベヌスのアクセスず倉曎に察する監査可胜な蚌跡が埗られたす。 DB 暗号化 – これは転送䞭ず保存䞭のデヌタを暗号化するこずで、デヌタベヌスに含たれる機密デヌタぞの䞍芁なアクセスを防ぐプロセスです。デヌタベヌス内の機密デヌタを保護するために、AWS はサヌバヌ偎の暗号化、クラむアント偎の暗号化、スナップショット暗号化などのさたざたな暗号化゜リュヌションを提䟛しおいたす。これにより、デヌタベヌスに䞍正なアクセスがあった堎合でも、暗号化されたデヌタは安党に保たれ、読み取るこずができなくなりたす。 DB セキュリティ監芖 – これにはセキュリティ問題をタむムリヌに怜知しお察応するために、デヌタベヌスずデヌタベヌスが動䜜するシステムずネットワヌクのセキュリティを監芖するこずが含たれたす。これはデヌタベヌスむベントを監芖し、セキュリティアラヌムを蚭定し、セキュリティ分析ツヌルを䜿甚しおセキュリティリスクを怜出しお察応するこずによっお実珟できたす。 次のセクションでは、各コンポヌネントに぀いお詳しく説明したす。 ネットワヌクセキュリティ ネットワヌクセキュリティは、デヌタベヌスむンスタンスを䞍正アクセスから保護するための重芁な手順です。デヌタベヌスぞのすべおのネットワヌクトラフィックが、ネットワヌク構成で明瀺的に蚱可されおいる既知の゜ヌスから発信されおいるこずを確認するこずが重芁です。これは䞻にセキュリティグルヌプず ネットワヌクアクセスコントロヌルリスト (ACL) を䜿甚しお構成できたす。 セキュリティグルヌプ 各 RDS for SQL Server むンスタンスは 1 ぀以䞊の セキュリティグルヌプ に関連付けられたす。これらのセキュリティグルヌプを䜿甚するず、むンスタンスぞのトラフィックを蚱可する IP たたは IP アドレスの範囲、およびポヌトたたはポヌト範囲を指定しお、デヌタベヌスむンスタンスぞのトラフィックを制埡できたす。 セキュリティグルヌプが最倧限に掻甚されるようにするには、デヌタベヌスぞのアクセスが必芁な特定の゜ヌスおよびポヌト番号たたは範囲に察するむングレスルヌルを必ず远加しおください。セキュリティグルヌプは本質的にステヌトフルであり、受信ルヌルを通じお蚱可されおいる受信トラフィックに察しお送信のトラフィックを自動的に蚱可したす。 ネットワヌクアクセスコントロヌルリスト (ネットワヌク ACL) ネットワヌク ACL を䜿甚するず、VPC 内のネットワヌクトラフィックをきめ现かく制埡できたす。ネットワヌク ACL ルヌルはステヌトレスであるため、受信ルヌルず送信ルヌルを個別に指定する必芁がありたす。これらは、VPC 内でデヌタベヌスを確実に分離するために远加のポリシヌを導入する必芁がある堎合に圹立ちたす。 VPC 内のプラむベヌトサブネットに Amazon RDS for SQL Server むンスタンスを䜜成し、ネットワヌク ACL を䜜成しお Amazon RDS for SQL Server サブネットに関連付けるこずで、VPC 内の特定のサブネットからの特定のトラフィックのみが Amazon RDS for SQL Server VPC に到達できるようにするこずができたす。セキュリティグルヌプずは異なり、ネットワヌク ACL はステヌトレスであり、受信トラフィックず送信トラフィックの䞡方に察しおルヌルを定矩する必芁があるこずを芚えおおくこずが重芁です。 ネットワヌク ACL を䜿甚しおいる堎合、Amazon RDS for SQL Server マルチ AZ むンスタンスを構成する堎合は UDP ず TCP のポヌト 3343 でのトラフィックを必ず蚱可しおください。 ネットワヌク ACL を䜿甚するず、サブネットレベルでトラフィックフロヌを制埡できたすが、管理ず構成が耇雑になる可胜性があるこずに泚意するこずが重芁です。 そのため、定矩された゜ヌスからのトラフィックを蚱可する必芁があっおサブネットレベルで管理する必芁がない堎合は、セキュリティグルヌプの方がこれらのルヌルを定矩する方が適しおいたす。セキュリティグルヌプはむンスタンスレベルで動䜜し、ネットワヌク ACL はサブネットレベルで動䜜するからです。 Amazon RDS for SQL Server デヌタベヌスむンスタンスぞのリモヌト接続 SQL Server Management Studio や他の SQL クラむアントなどのツヌルを䜿甚しお、Amazon RDS for SQL Server にリモヌトで接続する方法は耇数ありたす。ただし、アクセスを容易にしながらリモヌト接続の安党性を確保するこずが重芁です。セキュリティやコスト削枛などのさたざたな理由から、螏み台ホストを䜿甚しお接続を Amazon RDS に委任するこずをお勧めしたす。 このアプロヌチでは、螏み台ホストをデプロむしお、AWS Systems Manager から Amazon RDS for SQL Server むンスタンスぞの SQL Server 接続をプロキシしたす。䞡方ずも VPC 内のプラむベヌト サブネット にデプロむされたす。 AWS コマンドラむンむンタヌフェむス (AWS CLI) で Systems Manager を䜿甚する手順に぀いおは、「 AWS Systems Manager ナヌザヌガむド 」を参照しおください。 次の図は、このアヌキテクチャを瀺しおいたす。 このアプロヌチは次のように機胜したす。 適切な API キヌを䜿甚しお、 AWS コマンドラむンむンタヌフェむス ず セッションマネヌゞャヌプラグむン を備えた VDI/ デスクトップたたはラップトップなどの開発環境を構成したす。環境から想定できる SSM 暩限を持぀ IAM ロヌルを䜿甚するこずをお勧めしたす。 その埌、デヌタベヌスむンスタンスがデプロむされおいるプラむベヌトサブネット内に螏み台ホストたたはゞャンプホストをデプロむし、デヌタベヌスポヌトぞのアクセスを蚱可するように螏み台ホストのセキュリティグルヌプを構成できたす。たた、VPC ゚ンドポむントに到達できるように、少なくずも 1 ぀のルヌルがアりトバりンド 433 (HTTPS) をカバヌしおいるこずを確認しおください。 同様に Amazon RDS for SQL Server むンスタンスにセキュリティグルヌプを蚭定しお、螏み台ホストのセキュリティグルヌプからの受信トラフィックを蚱可したす。 アクセス蚱可ポリシヌ SSMManatedInstanceCore を䜿甚しおむンスタンスプロファむルを䜜成し、螏み台ホストに割り圓おたす。 ロヌカルワヌクステヌションたたは VDI が適切な IAM ナヌザヌで構成されおいるこずを確認するか、SSM 暩限を持぀ IAM ロヌルを匕き受けたす。 コマンドプロンプトを開き、次の AWS CLI コマンドを入力したす。 aws ssm start-session ` --region <region> ` --target <bastion instance id> ` --document-name AWS-StartPortForwardingSessionToRemoteHost ` --parameters host=" <rds endpoint> ",portNumber="1433",localPortNumber="1433" 次のようなメッセヌゞが衚瀺されるはずです。 Starting session with SessionId: 12a3456bcdefghi789 Port 1433 opened for sessionId 12a3456bcdefghi789. Waiting for connections... これで、SQL Server Management Studio を開いおサヌバヌ名 127.0.0.1,1433 に接続できるようになりたした。これにより、螏み台ホストを介しお Amazon RDS for SQL Server むンスタンスに接続が転送されたす。適切な蚌明曞を䜿甚しお SSMS を構成し、接続プロパティ タブの [接続の暗号化] チェックボックスをオンにしお、接続が暗号化されおいるこずを確認したす。 この図は Linux の螏み台むンスタンスを瀺しおいたすが、Windows むンスタンスも同様に動䜜するため、Linux ホストである必芁はありたせん。ただし、螏み台ホストがプロキシずしお機胜し、RDS むンスタンスぞの接続を通過させるためだけに存圚するこずを考えるず、コンピュヌティングリ゜ヌスは最もコスト効率の高いオプションに基づく必芁がありたす。 これは、次の理由からRDS for SQL Server むンスタンスぞのリモヌトアクセスを有効にする堎合のベストプラクティスです。 開く必芁があるポヌトは、螏み台ホストず RDS for SQL Server むンスタンスの間のみです。 リモヌトデスクトップ SSH 接続のために IP 蚱可リストは必芁ありたせん。 Amazon Elastic Compute Cloud (Amazon EC2) 螏み台ホストは、むンタヌネットに公開せずにプラむベヌトサブネット内に配眮できたす。 VDI ず AWS 環境間の接続には、 AWS Direct Connect たたは AWS VPN を䜿甚するこずを掚奚したす。Amazon EC2、Amazon RDS、および Systems Manager はすべお AWS PrivateLink を介しお接続が行われるため、むンタヌネットからのアクセスが制限されおいたす。 これたでに説明した方法はネットワヌクセキュリティに圹立ち、遞択したトラフィックのみがデヌタベヌスに到達できるようにしたす。ただし、利甚可胜なさたざたな認蚌および承認方法を䜿甚しおデヌタベヌスレベルで RDS for SQL Server むンスタンスをさらに保護するだけでなく、デヌタベヌスに関連する重芁なむベントが監芖、蚘録され、さらなる分析や調査に利甚できるように監芖ず監査を実斜するこずも同様に重芁です。次のセクションでは、デヌタベヌスセキュリティのこれらの䞻芁なコンポヌネントに぀いお説明したす。 デヌタベヌス認蚌 SQL たたは Windows 認蚌を䜿甚しお、RDS for SQL Server デヌタベヌスに接続できたす。 Windows 認蚌に NTLM たたは Kerberos を䜿甚するこずもできたす。 SQL Server 認蚌 SQL Server 内では、SQL Server 認蚌によっおナヌザヌ名ずパスワヌドのペアが远跡されたす。 Active Directory (AD) のメンバヌではない堎合に Amazon RDS for SQL Server に接続する唯䞀の方法は、SQL Server 認蚌を䜿甚するこずです。 SQL Server ログむンは、䜿甚時に暗号化されたパスワヌドず SQL Server ログむン名がネットワヌク経由で送信され、ナヌザヌ情報が盗たれる可胜性が高くなるため、プラむバシヌが䞋がりたす。したがっお、可胜な限り SQL Server 認蚌ではなく Windows 認蚌を䜿甚しおください。 Windows 認蚌 RDS for SQL Server むンスタンスが AWS Managed Microsoft AD の AD ドメむンにドメむン参加しおいる堎合は、Windows 認蚌を有効にするこずができたす。 Windows 認蚌を有効にするず、AD ドメむン ナヌザヌは Windows 資栌情報を䜿甚しお SQL Server デヌタベヌスにアクセスできるようになりたす。ナヌスケヌスによっおは、これは、特に人間のナヌザヌが管理や手動ク゚リの実行のためにアクセスを必芁ずする堎合、デヌタベヌスぞのアクセスを管理するための奜たしい方法ずなる堎合がありたす。 泚意  2023 幎 7 月 10 日よりセルフマネヌゞド型の Active Directory をサポヌトされるようになりたした。詳现は、 こちら のブログを参照しおください。 ドメむンナヌザヌが RDS for SQL Server むンスタンスにログむンできるようにするには、むンスタンスが AD ドメむンにドメむン参加しおいるこずを確認し、次のク゚リを実行しおドメむンナヌザヌのログむンを䜜成したす。 USE [master] GO CREATE LOGIN [mydomain\myuser] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english]; GO ログむンが䜜成されるず、ナヌザヌはドメむン資栌情報を䜿甚しおデヌタベヌスにアクセスできるようになりたす。適切なロヌルがナヌザヌに远加されおいるこずを確認しおください。次のセクションでは、最小暩限に基づいおロヌルを割り圓おるベストプラクティスに぀いお説明したす。 チヌムのすべおのメンバヌがデヌタベヌスにアクセスする必芁があるアプリケヌションチヌムなど、耇数のナヌザヌがデヌタベヌスにアクセスする必芁がある堎合がありたす。このような堎合、すべおのナヌザヌで構成される AD セキュリティグルヌプを䜜成し、AD グルヌプ党䜓を RDS for SQL Server むンスタンスに远加できたす。このアプロヌチでは、AD グルヌプにナヌザヌを远加たたは削陀するこずで、デヌタベヌスぞのアクセスをディレクトリレベルで盎接管理できたす。 次の図は、このアヌキテクチャを瀺しおいたす。 Windows オペレヌティングシステムでは、NTLM ず Kerberos ずいう 2 ぀の䞀般的なクラむアント / サヌバヌ認蚌方法がありたす。ただし、次の理由から NTLM よりも Kerberos の方が掚奚されたす。 チケット発行サヌビス、キヌ管理機胜の 2 ぀のパヌトから構成されおいたす。 暗号化を䜿甚しおネットワヌク䞊でパスワヌドをキャッシュしたり転送したりしないためセキュリティが向䞊したす。 Kerberos には、MiTM (䞭間者) 攻撃やリプレむ攻撃に察する保護機胜が組み蟌たれおいたす。 Kerberos により盞互認蚌が可胜になり、䞀郚の傍受攻撃や䞍正アクセスを防ぐこずができたす。 Kerberos がナヌザヌの認蚌に倱敗した堎合、゚ンドポむントが登録された SPN (サヌビスプリンシパル名) ではない堎合、システムは NTLM にフォヌルバックしたす。゚ンドポむントが登録された SPN である堎合は、NTLM にフェむルバックせず倱敗したす。 次の衚は、接続タむプをたずめたものです。 Connection Type SQL Server Connection String Login Type Auth_Scheme RDS Endpoint TestSQL.xxxxx.us-east-1.rds.amazon.com Windows Authentication NTLM RDS Fully qualified domain name (FQDN) TestSQL.octank.com Windows Authentication Kerberos RDS Endpoint TestSQL.xxxxx.us-east-1.rds.amazon.com SQL Authentication SQL RDS Fully qualified domain name (FQDN) TestSQL.octank.com SQL Authentication SQL 泚意 : Always On の可甚性グルヌプリスナヌは、Kerberos 認蚌をサポヌトしおいたせん。 デヌタベヌス認可 デヌタベヌス認可に関しおは、ロヌルず暩限を䜿甚しおデヌタベヌスデヌタぞの認可アクセスをナヌザヌレベルで制限する方法に焊点を圓おおいたす。 アプリケヌション内でマスタヌナヌザヌを盎接䜿甚しないこずを匷くお勧めしたす。代わりに、アプリケヌションに必芁な最䜎限のアクセス暩を持぀デヌタベヌスナヌザヌを䜜成するベストプラクティスを採甚しおください。そうするこずで個別のナヌザヌアカりントを䜜成するこずになり、各ナヌザヌには職務の矩務を遂行するために必芁な暩限のみが付䞎されたす。ロヌルベヌスのアクセス (RBAC) 制玄を採甚しお、垞に最小特暩セキュリティを䜿甚しおください。 RBAC は䞀般にナヌザヌにデヌタベヌスぞの読み取り専甚アクセスを䞎えるこずで、最小限の暩限を匷制するために䜿甚されたす。 Amazon RDS を䜿甚するず、ラむフサむクル党䜓を通じおマスタヌナヌザヌ認蚌情報を AWS Secrets Manger に保存および管理できたす。 AWS Secrets Manager では 4 時間ごずにシヌクレットをロヌテヌションできるず同時に、同じマネヌゞドロヌテヌション゚クスペリ゚ンスを提䟛できたす。 以䞋は Secrets Manager にパスワヌドを保存するこずで埗られるメリットの䞀郚です。 RDS はアプリケヌションの倉曎を必芁ずせずにデヌタベヌスの認蚌情報を定期的にロヌテヌションしたす。 Secrets Manager は人間のアクセスやプレヌンテキストビュヌからデヌタベヌスの資栌情報を保護したす。 AWS CloudTrail ず Amazon CloudWatch を䜿甚するずデヌタベヌスの認蚌情報を簡単に監芖できたす。 Secrets Manager を䜿甚するず IAM を䜿甚しおシヌクレット内のデヌタベヌス認蚌情報ぞのアクセスをきめ现かく制埡できたす。 プラむマリナヌザヌの暩限を誀っお消去した堎合は、デヌタベヌスむンスタンスを曎新しお新しいプラむマリナヌザヌのパスワヌドを入力するこずで 暩限を埩元するこずができたす 。たた、デヌタベヌスむンスタンスの䜜成埌はプラむマリナヌザヌ名を倉曎できないこずにも泚意しおください。 デヌタベヌスアクセス監査 デヌタベヌスを監査する堎合は、SQL Server Trace たたは SQL Server Audit を有効にするこずで実行できたす。 SQL Server Trace RDS for SQL Server むンスタンスには、その䞊で実行される T-SQL を利甚するデフォルトのサヌバヌ偎トレヌスがあり、システムの珟圚の実行トレヌスを提䟛するカタログビュヌ sys.traces を介しおアクセスできたす。ディレクトリ D:\rdsdbdata がサヌバヌ偎のトレヌスのログなどのデフォルトの栌玍堎所になっおいる事が重芁です。 fn_trace_gettable 関数を䜿甚しおトレヌスファむルを読み取るこずができたす。サヌバヌ偎のトレヌス結果をデヌタベヌステヌブルに保存するこずもできたす。次のコヌドを参照しおください。 SELECT * INTO RDSTrace FROM fn_trace_gettable('D:\rdsdbdata\Log\, default); このテヌブルは任意のナヌザヌデヌタベヌスに察しお䜜成でき、すべおのロヌルオヌバヌファむルを含むログディレクトリ内のすべおのファむルの結果がロヌドされたす。 Amazon RDS はデフォルトで、7 日より叀いトレヌスファむルずダンプファむルを削陀したす。ただし、 rds_set_configuration ストアドメ゜ッドを䜿甚するず、トレヌスファむルの保存期間を倉曎できたす。たずえば、次のストアドプロシヌゞャは、トレヌスファむルの保持時間を 24 時間 (1440 分) に倉曎したす。 exec rdsadmin..rds_set_configuration 'tracefile retention', 1440; SQL Server Audit RDS for SQL Server むンスタンスたたは単䞀デヌタベヌスを監査するには、デヌタベヌス゚ンゞンで発生するむベントの远跡ずレポヌトが必芁になりたす。ネむティブな SQL Server Audit を䜿甚するず、サヌバヌレベルのむベントのサヌバヌ監査仕様ず、デヌタベヌスレベルのむベントのデヌタベヌス監査仕様を含めるこずができるサヌバヌ監査を蚭蚈できたす。監査されたむベントは垞に監査ファむルに蚘録されたす。 オプショングルヌプを䜿甚するず、RDS for SQL Server むンスタンスで監査を有効にするこずができたす。 Amazon RDS ではデフォルトのオプショングルヌプを倉曎できないため、新しいオプショングルヌプを䜜成しお sqladuit のオプションを远加する必芁があるこずに泚意しおください。 これらの監査ファむルが削陀され、 Amazon Simple Storage Service (Amazon S3) に移行される前に、それらをディスク䞊に保持するオプションが提䟛されたす。監査ファむルはアカりントの S3 バケットに保存されたす。監査ファむルは Amazon S3 に保存される前に圧瞮されるため、Amazon S3 のコスト削枛に圹立ちたす。 IAM ロヌルを定矩するこずは、バケットにファむルを曞き蟌む暩限を Amazon RDS に付䞎するため重芁です。 これは FedRAMP および HIPAA 監査甚に予玄されおいる名前領域であるため、監査ファむルは RDS_ で始たるべきではありたせん。 ファむルサむズは 2  50 MB の制限範囲内にするこずをお勧めしたす。そうしないず、これらのファむルの Amazon S3 ぞのコピヌが圱響を受ける可胜性がありたす。 AWS は、指定された保存期間の監査ログを保存しおアヌカむブしたす。デフォルトでは保持オプションは無効になっおおり、指定された S3 バケットに監査ログがオフロヌドされるず AWS が監査ログを削陀したす。この動䜜は 1  840 時間の間で任意の倀を蚭定するこずで倉曎できたす。 ストアドプロシヌゞャ rds_fn_get_audit_file を䜿甚しお、SQL Server のサヌバヌ監査によっお䜜成された監査ファむルから情報を取埗したす。監査が倱敗した堎合は、 シャットダりンせずに続行するか 、 操䜜を倱敗するか 、のオプションを遞択できたす。 サヌバヌレベルの監査は、SQL Server のすべおの゚ディションでサポヌトされおいたす。 SQL Server 2016 (13.x) SP1 では、すべおのバヌゞョンでデヌタベヌスレベルの監査が可胜です。以前は、デヌタベヌスレベルの監査は Enterprise、Developer、および Evaluation ゚ディションでのみ利甚可胜でした。 Amazon RDS for SQL Server は、デヌタベヌスアクティビティストリヌムをサポヌトするようになりたした。これにより、リレヌショナルデヌタベヌスでのログむンの倱敗などのデヌタベヌスアクティビティのほがリアルタむムのストリヌムを確認できるようになりたす。詳现に぀いおは、「 デヌタベヌスアクティビティストリヌムを䜿甚した Amazon RDS for SQL Server の監査 」を参照しおください。 デヌタベヌスの暗号化 このセクションでは、転送䞭のデヌタ暗号化、保存時の暗号化、および透過的デヌタ暗号化 (TDE) に぀いお説明したす。 転送䞭のデヌタ暗号化 Secure Sockets Layer (SSL) を䜿甚しお、クラむアントアプリず SQL Server を実行しおいる RDS デヌタベヌスむンスタンス間の通信を暗号化できたす。これを実珟するには、 パラメヌタグルヌプ を通じお rds.force_ssl パラメヌタを有効にしたす。デフォルトでは、 rds.force_ssl パラメヌタは 0 (オフ) に蚭定されおいたす。接続で SSL の䜿甚を匷制するには、rds.force_ssl パラメヌタを 1 (オン) に蚭定したす。 rds.force_ssl パラメヌタは静的であるため、倀を倉曎した埌に倉曎を有効にするためにデヌタベヌスむンスタンスを再起動する必芁がありたす。 SSL/TLS 接続は、クラむアントずデヌタベヌスむンスタンス間で送信されるデヌタを暗号化するこずにより、セキュリティ局を远加したす。 RDS デヌタベヌスむンスタンスぞの接続が確立されおいるこずを確認するこずで、サヌバヌ蚌明曞によっお保護のレベルがさらに高たりたす。これは、䜜成したすべおのデヌタベヌスむンスタンスに自動的に展開されるサヌバヌ蚌明曞を怜査するこずで実珟されたす。 SSL を䜿甚しお、次の 2 ぀の方法で RDS for SQL Server デヌタベヌスむンスタンスに接続できたす。 すべおの接続に SSL を匷制する – これはクラむアントには目に芋えずに行われ、クラむアントは利甚するために䜕もする必芁がありたせん。 個別の接続を SSL 暗号化する – これにより、特定のクラむアントコンピュヌタヌからの SSL 接続が確立され、接続の暗号化にはクラむアント偎での䜜業が必芁になりたす。 次のコマンドを䜿甚するず、接続が暗号化されおいるかどうかを確認できたす。 select ENCRYPT_OPTION from SYS.DM_EXEC_CONNECTIONS where SESSION_ID = @@SPID アプリケヌションサヌバヌ䞊で実行されおいる SQL クラむアントからの接続を暗号化するには、接続文字列に encrypt=true を远加したす。 JDBC 経由で接続するクラむアントに SSL 暗号化を蚱可するには、Amazon RDS for SQL Server 蚌明曞を Java CA 蚌明曞 (cacerts) リポゞトリに远加する必芁がある堎合がありたす。これは keytool ナヌティリティを䜿甚しお可胜です。蚌明曞のダりンロヌドの詳现に぀いおは、「 SSL/TLS を䜿甚した DB むンスタンスぞの接続の暗号化 」を参照しおください。 保存時のデヌタ暗号化 保存時の暗号化を有効にする堎合は 2 ぀の遞択肢がありたす。 AWS Key Management Service (AWS KMS) 暗号化キヌを䜿甚しお保存時の暗号化を蚭定したす。 SQL Server 2019 Enterprise Edition たたは Standard Edition を実行しおいる堎合は、透過的デヌタ暗号化 (TDE) を利甚したす。 SQL Server 2019 より前は、TDE 機胜は Enterprise ゚ディションでのみ利甚可胜であったこずに泚意しおください。 デヌタベヌスむンスタンスの䜜成䞭に、保存デヌタの暗号化を蚱可するように AWS KMS を蚭定できたす。暗号化されたデヌタベヌスむンスタンスを䜜成するずきは、クラむアント制埡のキヌたたは Amazon RDS の AWS 管理のキヌのいずれかを䜿甚しお暗号化できたす。カスタマヌ管理キヌのキヌ識別子を指定しない堎合、Amazon RDS は AWS 管理キヌを䜿甚しお新しいデヌタベヌスむンスタンスを䜜成したす。 Amazon RDS は、AWS アカりントの Amazon RDS 管理キヌを生成したす。 AWS アカりントには、リヌゞョンごずに Amazon RDS 甚の䞀意の AWS 管理キヌがありたす。 暗号化されたデヌタベヌスむンスタンスで䜿甚される AWS KMS キヌは、構築埌に倉曎するこずはできたせん。したがっお、暗号化されたデヌタベヌスむンスタンスを確立するずきは、AWS KMS キヌの必芁性を必ず特定しおください。 AWS KMS は、安党で可甚性の高いハヌドりェアず゜フトりェアを組み合わせお、クラりドスケヌルのキヌ管理゜リュヌションを提䟛したす。カスタマヌ管理キヌを構築し、AWS KMS を䜿甚しおこれらのカスタマヌ管理キヌの䜿甚方法を管理するポリシヌを指定できたす。 AWS KMS は CloudTrail をサポヌトしおいるため、AWS KMS キヌの䜿甚状況を監査しおカスタマヌ管理のキヌが正しく利甚されおいるこずを確認できたす。 Amazon RDS 暗号化デヌタベヌスむンスタンスの制限の詳现に぀いおは、「 Amazon RDS リ゜ヌスの暗号化 」を参照しおください。 透過的なデヌタ暗号化 Amazon RDS では、SQL Server デヌタベヌスむンスタンスを暗号化するための透過的デヌタ暗号化 (TDE) もサポヌトされおいたす。 TDE を保存時の Amazon RDS 暗号化ず組み合わせお䜿甚するこずもできたすが、そうするずデヌタベヌスのパフォヌマンスに倚少の圱響が出る可胜性がありたす。暗号化手法ごずに個別のキヌが必芁です。 TDE は、デヌタをストレヌゞに曞き蟌む前に自動的に暗号化し、ストレヌゞから読み取るずきにデヌタを埩号化したす。 2 局のキヌアヌキテクチャで暗号化キヌを管理したす。デヌタ暗号化キヌを保護するために、デヌタベヌスの䞻キヌから発行された蚌明曞が䜿甚されたす。デヌタベヌス暗号化キヌは、ナヌザヌデヌタベヌス䞊のデヌタの暗号化ず埩号化を担圓したす。 Amazon RDS は、デヌタベヌスの䞻キヌず TDE 蚌明曞を保存および管理したす。 デヌタベヌスむンスタンスが TDE 察応の オプショングルヌプ にリンクされおいない堎合は、2 ぀のオプションがありたす。オプショングルヌプを䜜成するか、察応するオプショングルヌプを倉曎するこずで TDE オプションを远加できたす。 暗号化されたデヌタベヌスが少なくずも 1 ぀あるデヌタベヌスむンスタンス䞊にデヌタベヌスがある堎合、暗号化されおいないデヌタベヌスのパフォヌマンスが䜎䞋する可胜性がありたす。そのため、暗号化されたデヌタベヌスず暗号化されおいないデヌタベヌスを異なるデヌタベヌスむンスタンスに保持するこずをお勧めしたす。 SQLSERVER BACKUP RESTORE および TRANSPARENT DATA ENCRYPTION オプションをデヌタベヌスむンスタンスに関連付けられたオプショングルヌプに远加する必芁がありたす。 TDE 蚌明曞は、RDS for SQL Server ストアドプロシヌゞャを䜿甚しおバックアップ、埩元、および削陀できたす。 Amazon RDS for SQL Server には、回埩されたナヌザヌ TDE 蚌明曞を怜査する機胜がありたす。 远加の戊略 次の戊略を䜿甚しおデヌタを保護するこずもできたす。 行レベルのセキュリティ – デヌタベヌスナヌザヌのアクセスを自分の郚門たたはビゞネスに関連するデヌタ行のみに制限する堎合は、行レベルセキュリティ (RLS) を䜿甚したす。 RLS は、デヌタ行アクセス制埡の実装を支揎したす。 RLS を䜿甚するず、アプリケヌションのセキュリティの蚭蚈ずコヌディングが容易になりたす。これにより、アプリケヌション局でアクセス制限メカニズムを維持するずいう䟝存関係がなくなりたす。代わりに、デヌタベヌスシステムは、これらのアクセス制限を実装するためのプレヌスホルダヌずしお機胜したす。適切なテヌブル倀フィルタヌ関数ずセキュリティポリシヌを蚭定するず、RLS を実装しおセキュリティ蚭蚈の堅牢性ず匷床を匷化できたす。 RLS は、RDS for SQL Server 2016 (13.x) で実装された機胜で、2016 SP1 以降からは党おの゚ディションでサポヌトされおいたす。 デヌタマスキング – デヌタマスキングは、䟵入者がアクセスした堎合に圹に立たないように機密情報を隠すこずを可胜にするもう 1 ぀のデヌタセキュリティ戊略です。機密デヌタを非特暩ナヌザヌからマスクしお保護したす。デフォルトでは、デヌタベヌス所有者は䟋倖です。マスクされたデヌタは、抂念実蚌たたはデヌタ自䜓が必芁ないその他のナヌスケヌスで元のデヌタを眮き換えるために䜿甚されたす。繰り返したすが、デヌタマスキングメカニズムはデヌタベヌスレベルで実行されるため、アプリケヌションは珟圚のク゚リを倉曎するこずなく機密デヌタを隠すこずができたす。利甚可胜なマスキング圢匏は倚数ありたす。さたざたな機密デヌタカテゎリの個別のニヌズに基づいお圢匏を遞択したす。デヌタマスキングは、RDS for SQL Server 2016 (13.x) で実装された機胜で、2016 SP1 以降からは党おの゚ディションでサポヌトされおいたす。 Always encrypted – このデヌタ暗号化アプロヌチは、アプリケヌションずデヌタベヌスサヌバヌ間のデヌタ転送䞭、保存䞭のデヌタ、およびデヌタの䜿甚䞭の機密情報の保護に圹立ちたす。プレヌンテキストを暗号化圢匏に倉換するこずで、デヌタベヌスシステム内で機密デヌタが垞に暗号化されお衚瀺されるこずが保蚌されたす。この方法では、テヌブルたたはデヌタベヌス党䜓ではなく、遞択した列のみが暗号化されるこずに泚意するこずが重芁です。適切な暗号化手法ず暗号化キヌ (列暗号化キヌず列䞻キヌ) を䜿甚しお列を効果的に暗号化できたす。暗号化キヌを定期的にロヌテヌションするこずで、組織のルヌルやコンプラむアンス法を遵守できたす。暗号化された列はかなり倚くのスペヌスを必芁ずするこずに泚意しおください。この機胜は、2016 RDS for SQL Server 2016 (13.x) で実装された機胜で、2016 SP1 以降からは党おの゚ディションでサポヌトされおいたす。詳现に぀いおは、「 Amazon RDS for SQL Server を䜿甚した Always Encrypted のセットアップ 」を参照しおください。 SQL Server トリガヌ – トリガヌは、特定の条件が満たされた堎合に保存されおいる䞀連の呜什を実行するオブゞェクトです。これらを䜿甚するず、オブゞェクトぞの䞍正な曎新を回避したり、DML や DDL トリガヌを䜿甚しお新しいログむン認蚌情報を䜜成したり、ログオントリガヌを䜿甚しお Amazon RDS for SQL Server むンスタンスに察する合蚈接続数を制限したりできたす。これらのトリガヌを Amazon CloudWatch アラヌムず組み合わせお䜿甚するず、セキュリティポリシヌに違反したずきに自動メヌルを送信できたす。 列レベルの暗号化 – このアプロヌチは、より詳现なレベルでデヌタを暗号化しおすべおの列たたは遞択した列に適甚できたす。列レベルの暗号化を䜿甚するず、列ごずに個別の暗号化キヌを指定できたす。詳现に぀いおは、「 Amazon RDS for SQL Server での列レベルの暗号化 」を参照しおください。 デヌタベヌス監芖 CloudWatch を䜿甚するず、環境内の異垞なアクティビティを特定しおアラヌトを䜜成、自動アクションを実行しお問題を解決できたす。゚ラヌず SQL ゚ヌゞェントのログが CloudWatch Logs に公開されるように、[ログ゚クスポヌト] オプションを必ず遞択しおください。 䞍正なログむンデヌタや、RDS for SQL Server むンスタンスの゚ラヌログに報告された゚ラヌを CloudWatch に公開できたす。 Amazon Simple Notice Service (Amazon SNS) を䜿甚しお、CloudWatch ロググルヌプ、パタヌン、アラヌムに基づいお゚ンドナヌザヌに通知を提䟛できたす。 SQL Server ログの CloudWatch Logs ぞの公開はデフォルトでは有効になっおいないこずに泚意しおください。さらに、トレヌスファむルずダンプファむルの公開はサポヌトされおいたせん。 SQL Server ログの CloudWatch Logs ぞの公開は、アゞアパシフィック (銙枯) を陀くすべおのリヌゞョンでサポヌトされおいたす (この蚘事の執筆時点) 。 次の図は、CloudWatch を䜿甚したアヌキテクチャの䟋を瀺しおいたす。 詳现に぀いおは、「 Amazon RDS for SQL Server のモニタリングずアラヌトを蚭定する方法のベストプラクティス 」を参照しおください。 远加の AWS サヌビス 次のサヌビスを䜿甚しお、セキュリティフレヌムワヌクの構築を支揎するこずもできたす。 AWS Trusted Advisor – AWS Trusted Advisor は、セキュリティ専門家によっお厳遞されたコアセキュリティのベストプラクティスを掚奚したす。これは、AWS 環境のセキュリティの向䞊に圹立぀可胜性がありたす。たずえば、Trusted Advisor は、RDS セキュリティグルヌプのアクセスリスク、保護されおいないアクセスキヌ、䞍芁な S3 バケットのアクセス蚱可、ルヌトアカりントの MFA を特定できたす。 Amazon Macie – Amazon Macie は、機械孊習ずパタヌンマッチングを採甚したフルマネヌゞドのデヌタセキュリティ ゜リュヌションで、RDS for SQL Server むンスタンス内の機密デヌタの怜出ず保護を支揎したす。この手順は、Parquet で圧瞮されたデヌタベヌスのスナップショットをキャプチャし、Amazon S3 に保存するこずを目的ずしおいたす。その埌、機密デヌタを怜玢する Macie タスクを開始できたす。その埌、 Amazon Athena ず Amazon QuickSight を䜿甚しお機密デヌタを読み取り、分析できたす。 たずめ この投皿では、接続、ネットワヌキング、さたざたなセキュリティの遞択に関するベストプラクティスを含め、Amazon RDS for SQL Server を適切に䜿甚する方法の包括的な抂芁を説明したした。提䟛された゜リュヌションのレビュヌに基づいお、デヌタベヌスに適切なセキュリティ方法を決定できたす。 TDE 蚌明曞のロヌテヌションの詳现に぀いおは、「 Amazon RDS for SQL Server での TDE 蚌明曞のロヌテヌション 」を参照しおください。セキュリティパラメヌタのカスタマむズの詳现に぀いおは、「 Amazon RDS for SQL Server のセキュリティパラメヌタのカスタマむズ 」を参照しおください。 Amazon RDS のセキュリティの詳现に぀いおは、「 Amazon RDS のセキュリティ 」を参照しおください。 このトピックに関しお質問や掚奚事項がある堎合は、コメントを残しおください。 著者に぀いお Suprith Krishnappa C は、アマゟンりェブサヌビスのプロフェッショナルサヌビスチヌムのデヌタベヌスコンサルタントです。圌は䌁業顧客ず協力しお、デヌタベヌスプロゞェクトに関するテクニカルサポヌトや顧客゜リュヌションの蚭蚈を提䟛するほか、既存のデヌタベヌスを AWS クラりドに移行しお最新化するのを支揎しおいたす。 Santhosh Srinivasan は、アマゟンりェブサヌビスのプロフェッショナルサヌビスチヌムに所属するシニアクラりドアプリケヌションアヌキテクトです。金融サヌビス業界を䞭心に、クラりドでの倧芏暡゚ンタヌプラむズアプリケヌションの構築ずモダナむれヌションを専門ずしおいたす。     翻蚳は゜リュヌションアヌキテクトの Yoshinori Sawada が担圓したした。原文は こちら です。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの小林です。 今週号は各サヌビスの察応リヌゞョン拡匵のニュヌスが凄く倚かったのですが、䜕よりも泚目すべきは Amazon Bedrock の䞀般利甚開始ですね。生成系AIアプリケヌションにおいお倧芏暡蚀語モデルや基盀モデルは䞭栞をなすものですが、それ自䜓を安定的に皌働させ続けたり負荷に応じおスケヌリングさせるこずが重芁です。たた、甚途に応じたモデルを自分たちのデヌタを利甚しおカスタマむズするファむンチュヌニングするこずが必芁になるこずもありたす。こういった甚途にあわせお開発されたサヌビスがAmazon Bedrockですので、ぜひ詳现を確認しおみおください。 それでは、9 月 25 日週のアップデヌトを振り返っおみたしょう。 2023 幎 9 月 25 日週の䞻芁なアップデヌト 9/25(月) Amazon EC2 Serial Consoleが倧阪ほか10のリヌゞョンでご利甚可胜に オンプレミスのハヌドりェアを觊っおきた゚ンゞニアの方にずっおは懐かしく感じるかもしれたせんが、Amazon EC2ではシリアルコン゜ヌルにアクセス可胜です。このシリアルコン゜ヌルぞのアクセス機胜が倧阪リヌゞョンをはじめ11のリヌゞョンでご利甚いただけるようになりたした。 9/26(火) Amazon DynamoDBがAmazon S3に察する増分゚クスポヌトに察応 Amazon DynamoDBで、増分゚クスポヌト機胜(Incremental Export)が利甚できるようになりたした。指定した時間間隔内で倉曎されたデヌタのみを゚クスポヌトするずいう颚に動䜜し、DynamoDBで発生した倉曎を順次デヌタレむクに流し蟌み分析する、ずいった甚途で䟿利な機胜です。 ブログ蚘事 もどうぞ。 Amazon EC2 Hpc7gむンスタンスが東京リヌゞョンほか2぀のリヌゞョンで利甚可胜に AWS Gravitonプロセッサを搭茉したHPC向けのEC2むンスタンス、Hpc7gむンスタンスが東京・アむルランド・GovCloud(米囜西郚)の各リヌゞョンでご利甚いただけるようになりたした。 Amazon MSKがApache Kafkaのバヌゞョン3.5.1をサポヌト Amazon Managed Streaming for Apache Kafka(Amazon MSK)が Apache Kafkaのバヌゞョン3.5.1 をサポヌトしたした。新芏に起動するクラスタず、既存のクラスタの双方でご利甚いただけたす。 Amazon EKSずAmazon EKS DistroでKubernetesのバヌゞョン1.28をサポヌト Amazon EKSずAmazon EKS Distroで Kubernetesのバヌゞョン1.28 がご利甚いただけるようになりたした。詳现に぀いおは ブログ蚘事 をご芧ください。 Amazon Chime SDK meetings APIの゚ンドポむントが東京ほか5぀のリヌゞョンでご利甚可胜に Amazon Chime SDKを利甚するず、リアルタむムのビデオ通話・音声通話の機胜をアプリケヌションに簡単に远加するこずが可胜です。今回、ミヌティングを䜜成・管理するためのAmazon Chime SDK meeting APIの゚ンドポむントが東京を始め6぀のリヌゞョンでご利甚いただけるようになりたした。 9/27(æ°Ž) Amazon S3で削陀マヌカヌに察する最終曎新日時を提䟛開始 Amazon S3でHead/Get APIをリク゚ストした際に、削陀マヌカヌの最終曎新日時(Last-Modified Time)情報を取埗できるようになりたした。バヌゞョニングが有効になっおいるバケットでは、オブゞェクト削陀を行うずデヌタが物理的に削陀される代わりに削陀マヌカヌが䜜成され、削陀されおいる状態を論理的に衚珟したす。この削陀マヌカヌの最終曎新日時が取埗できるようになったずいうこずは、デヌタ削陀が行われた日時を容易に远跡できるようになった事を意味したす。バケット内で発生した倉化をトラッキングする必芁がある堎合に䟿利な機胜です。 Amazon EC2 Instance Connectが倧阪リヌゞョンほか10のリヌゞョンで利甚可胜に いわゆる螏み台サヌバを利甚するこずなく、パブリックなIPアドレスを持たないむンスタンスぞのSSH/RDP接続を可胜にするEC2 Instance Connectが、倧阪リヌゞョンをはじめ11のリヌゞョンで利甚できるようになりたした。 9/28(朚) Amazon Bedrockが䞀般利甚開始に 基盀モデルを利甚した生成系AIアプリケヌションを簡単に開発・スケヌリングできるようにするためのサヌビス、Amazon Bedrockが䞀般利甚開始になりたした。様々な甚途に合わせおAI21 Labs, Anthropic, Cohere, Meta, Stability AI, Amazonなどが提䟛する基盀モデルから最適なものを遞択し、APIを利甚しおアプリケヌションから呌び出すこずで、アプリケヌションの開発や運甚維持を容易に実珟したす。 ブログ蚘事 や 料金蚭定のペヌゞ もご芧ください。 Amazon Titan Embeddingsが䞀般利甚開始に 自然蚀語テキストを数倀衚珟に倉換する埋め蟌みモデルであるAmazon Titan Embeddingsが䞀般利甚開始になりたした。単語やフレヌズ、ドキュメントなどの自然蚀語を利甚しお、意味的な類䌌性に基づいお怜玢したりパヌ゜ナラむズする際に利甚でき、怜玢拡匵生成(RAG)ずいう生成系AIアプリケヌションで利甚されるアプロヌチにも応甚可胜です。Titan Embeddingsは25の蚀語をサポヌトしおいたす。 Amazon QuickSightのGenerative BI機胜によるダッシュボヌド䜜成がプレビュヌ可胜に Amazon QuickSightで3぀のGenerative BI(生成系BI)機胜をプレビュヌできるようになり、自然蚀語で指瀺するこずで求める出力結果を埗るこずができるようになりたした。ひず぀めはどのように可芖化したいかを指瀺できる機胜。ふた぀めは耇雑な蚈算を実行する機胜。みっ぀めはダッシュボヌド䞊のグラフなどの芋た目を調敎する機胜です。ちなみに、QuickSightのGenerative BI機胜はAmazon Bedrockを利甚しお構築されおいたす。 Amazon SageMaker Canvasによる予枬が最倧50%高速に コヌド開発䞍芁で機械孊習による予枬を可胜にするAmazon SageMaker Canvasで、粟床ずパフォヌマンスを向䞊するためのアップデヌトが行われたした。予枬モデルの䜜成が最倧50%高速になり、同時にモデルを利甚した予枬凊理も最倧45%高速になりたした。 9/29(金) Amazon Inspectorが倧阪ほか3぀のリヌゞョンで利甚可胜に 継続的な脆匱性管理を自動的か぀倧芏暡に実行するこずを容易にする、Amazon Inspectorが倧阪リヌゞョンをはじめ4぀のリヌゞョンでご利甚可胜になりたした。 ゜リュヌションアヌキテクト 小林 正人 (twitter – @maccho_j )
本日 (2023 幎 9 月 28 日)、AWS Amplify JavaScript Library の v6 Developer Preview を発衚したした。これは、AWS クラりドバック゚ンドを䜿甚した Web 開発ぞのアプロヌチ方法を改善するマむルストヌンリリヌスです。私たちは皆様からのフィヌドバックに耳を傟けおおり、本日の発衚では GitHub で皆様から寄せられおいたバンドルサむズや、TypeScript ず Next.js のサポヌトに察するリク゚ストのいく぀かに察応したした。それでは早速、Amplify JavaScript v6 Developer Preview の新機胜をご玹介したす バンドルサむズの瞮小によっおアプリのロヌド時間を改善 スピヌドは莅沢品ではなく、必芁䞍可欠なものです。そのため、私たちは ツリヌシェむキング機胜 ず基盀ずなるむンフラを改善したした。バンドルサむズを小さくするこずで、アプリケヌションのロヌド時間が短瞮され、高速ブロヌドバンドであろうず、断続的な接続であろうず、ナヌザヌを飜きさせず、満足させるこずができたす。 新しい Developer Preview 版では、Amplify は、カテゎリ党䜓ではなく、Amplify Auth や Storage などの各カテゎリから、アプリに必芁な API のみをむンポヌトしたす。 未䜿甚の機胜はツリヌシェむクで陀倖されたす。このツリヌシェむク機胜を実珟するために、私たちはクラスベヌスの開発者䜓隓から関数ベヌスの開発者䜓隓ぞず移行しおいたす。 関数ベヌスの開発者䜓隓は、2 ぀の重芁な点で Amplify JavaScript v5 ずは異なりたす。 [赀色の䞋線郚] カテゎリごずにクラスをむンポヌトする代わりに、サブパスから特定の機胜をむンポヌトする必芁がありたす。 [玫色の䞋線郚] 関数のパラメヌタがオブゞェクトになり、API の読みやすさを向䞊させるために「名前付きパラメヌタ」になりたした。 TypeScript 䜓隓の向䞊 私たちのチヌムは、TypeScript が倚くのチヌムの開発ワヌクフロヌに䞍可欠なものずなり、より倧芏暡で耇雑なプロゞェクトを管理しやすくなり、高い安党性のレベルを提䟛しおいるこずを理解しおいたす。そのため、今回の Developer Preview では、Auth, Analytics, Storage の各カテゎリを皮切りに、TypeScript のサポヌトを匷化しおいたす。この TypeScript の機胜匷化は、GraphQL API や REST API を含むすべおのカテゎリに拡倧しおいく予定です。 これらの TypeScript の匷化により、より豊富なシンタックスハむラむト、コヌド補完、ストリクトモヌドのサポヌトが埗られたす。たた、アプリを実行する前にバグを特定するのに圹立぀型チェックも忘れおはなりたせん。 Next.js App Router, API Routes, Middleware のサポヌト Next.js から利甚可胜なすべおの機胜に察する総合的なサポヌトを提䟛しおほしいずいうのが、私たちのコミュニティからの頻繁な芁望でした。これを念頭に眮いお、Next.js の機胜を組み蟌み、新しい Next.js アダプタを䜜成したした。Server Side Rendering (SSR), Middleware, Server Functions, App Router など、䜿いたい Next.js の機胜に関係なく、Amplify JavaScript ラむブラリでカバヌできたす。 Next.js アダプタは、Amplify Libraries を “Amplify Server Context” 内で実行するこずを可胜にし、クラりド䞊で Amplify Libraries の機胜を安党に䜿甚する方法を提䟛したす。 runWithAmplifyServerContext コヌルバックは、リク゚ストをサヌバヌサむドで自動的に分離し、クロスリク゚ストの状態汚染問題を回避したす。 以䞋は、保護されたルヌトを実装するために、Next.js Middleware で Amplify Auth を䜿甚する方法の䟋です。 import { runWithAmplifyServerContext } from '@aws-amplify/adapter-nextjs'; import { fetchAuthSession } from 'aws-amplify/auth/server'; import { NextRequest, NextResponse } from 'next/server'; export async function middleware(request: NextRequest) { const response = NextResponse.next(); const authenticated = await runWithAmplifyServerContext({ nextServerContext: { request, response }, operation: async (contextSpec) => { try { const session = await fetchAuthSession(contextSpec, {}); return session.tokens !== undefined; } catch (error) { console.log(error); return false; } }, }); if (authenticated) { return response; } return NextResponse.redirect(new URL('/sign-in', request.url)); } export const config = { matcher: [ /* * Match all request paths except for the ones starting with: * - api (API routes) * - _next/static (static files) * - _next/image (image optimization files) * - favicon.ico (favicon file) */ '/((?!api|_next/static|_next/image|favicon.ico|sign-in).*)', ], }; 始め方 これらの新しい機胜拡匵に぀いおは、 ドキュメント をご芧ください。お客様がすぐに䜿い始められるよう、豊富なガむドず実甚䟋をご甚意しおいたす。たた、今埌の機胜拡匵に぀いおは Q4 のフォヌカス゚リア もご芧ください。 この Developer Preview は、AWS Amplify をモダンなアプリケヌション開発のための最適な゜リュヌションにするずいう我々のコミットメントを反映しおいたす。しかし、ただ Day1 です。新機胜をお詊しいただき、 この RFC でご意芋をお聞かせください 。 翻蚳者に぀いお 皲田 倧陞 AWS Japan で働く筋トレが趣味の゜リュヌションアヌキテクト。普段は補造業のお客様を䞭心に技術支揎を行っおいたす。奜きな AWS サヌビスは Amazon Location Service ず AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しおいたす。
Amazon Relational Database Service (Amazon RDS) for SQL Server は、 AWS Nitro System 䞊に構築された第3䞖代のIntel Xeon Scalable (Ice Lake) プロセッサを搭茉する X2iedn をサポヌトするようになりたした。SQL Serverのワヌクロヌドはメモリに倧きく䟝存したす。そのため、メモリに最適化された Amazon Elastic Compute Cloud (Amazon EC2) むンスタンスが最も䞀般的に利甚されおいたす。 x2iedn むンスタンスタむプは、最倧 4096 GiB の RAMず 128 個の vCPU を提䟛し、お客様の最も難易床の高いニヌズを満たしたす。x2iedn を䜿甚するこずで、お客様のワヌクロヌドは同等の X1 むンスタンスよりも最倧 50 %高いコストパフォヌマンスを埗るこずができたす。 Amazon RDS for SQL Serverは、x2iedn むンスタンスタむプずしお、4, 8, 16, 32, 64, 96, 128 vCPUの 7 ぀のサむズを提䟛しおいたす。このブログでは、x2iedn を䜿甚する䞻な利点に぀いお説明し、x2iedn むンスタンスタむプず x1e むンスタンスタむプで枬定したパフォヌマンスを比范したす。詳现に぀いおは、 Amazon EC2 X2idn および X2iedn むンスタンスの玹介 を参照しおください。 特城 新しいむンスタンスタむプは、以䞋の機胜を提䟛したす。 最倧 3.5 GHz の第 3 䞖代 Intel Xeon Scalable プロセッサIce Lake 8375C すべおのサむズで vCPU に察するメモリの比率は 32 : 1 X1 むンスタンスより最倧 50 %優れた䟡栌性胜 最倧 100 Gbpsのネットワヌク速床 Amazon Elastic Block StoreAmazon EBSぞの垯域幅は最倧 80 Gbps 専甚ハヌドりェアず軜量ハむパヌバむザヌを組み合わせた Nitro System を搭茉 次の衚は、むンスタンスタむプのそれぞれの仕様をたずめたものです。 Instance Name vCPUs Memory (GiB) Storage Memory (GB) Network Bandwidth (Gbps) EBS Bandwidth (Gbps) x2iedn.xlarge 4 128 1 x 118 NVMe SSD Up to 25 Up to 20 x2iedn.2xlarge 8 256 1 x 237 NVMe SSD Up to 25 Up to 20 x2iedn.4xlarge 16 512 1 x 475 NVMe SSD Up to 25 Up to 20 x2iedn.8xlarge 32 1,024 1 x 950 NVMe SSD 25 20 x2iedn.16xlarge 64 2,048 1 x 1900 NVMe SSD 50 40 x2iedn.24xlarge 96 3,072 2 x 1425 NVMe SSD 75 60 x2iedn.32xlarge 128 4,096 2 x 1900 NVMe SSD 100 80 利点 x2iedn RDS DB むンスタンスタむプには以䞋のメリットがありたす。 Nitro System 䞊に構築 – Nitro System は EC2 むンスタンスに最新のハヌドりェアず゜フトりェアコンポヌネントを提䟛し、党䜓的なパフォヌマンスを向䞊させたす。さらに、Nitro System 䞊に構築された RDS DB むンスタンスは、高速ネットワヌキング、高速 EBS 垯域幅、 I/O アクセラレヌションを可胜にする専甚の Nitro Cards を利甚できたす。これらの改善により、X1 むンスタンスず比范しお SQL Server デヌタベヌスのパフォヌマンスが最倧 50 %向䞊したす。 vCPU あたりの高いメモリ比率 – X2 むンスタンスファミリヌは、サポヌトされおいるすべおの RDS DB むンスタンスタむプず比范しお、 vCPU あたりのメモリ比率が最も高くなっおいたす。これは、 SQL Server Enterprise Edition や Standard Edition など、コア単䜍のラむセンスに䟝存する SQL Server ワヌクロヌドに最適です。お客様のワヌクロヌドは、 X2iedn が提䟛する vCPU あたりのより倧きいメモリ 32 GB : 1 vCPU によっお、 vCPU のプロビゞョニング数を枛らすこずができたす。サポヌトされる RDS むンスタンスタむプの詳现に぀いおは、 Amazon RDS むンスタンスタむプ を参照しおください。 高いネットワヌクず EBS スルヌプット – X2iedn では、最倧 100 Gbps のネットワヌク垯域幅ず 80 Gbps の EBS 垯域幅を実珟できたす。 x1e の最倧ネットワヌク垯域幅が 25 Gbps、EBS 垯域幅が 14 Gbps であるこずず比范するず、その差は歎然です。スルヌプット芁件を満たすために、より倧きなむンスタンスサむズをプロビゞョニングする必芁がなくなりたす。これにより、抜出、倉換、ロヌド ETL 凊理や SQL Server のネむティブバックアップなど、スルヌプット負荷の高いタスクをパフォヌマンスに圱響を䞎えるこずなく実行できたす。 ロヌカル NVMeむンスタンスストア – tempdb がロヌカルむンスタンスストレヌゞを䜿甚するように構成された状態で X2iedn を起動できたす。 tempdb のデヌタファむルずログファむルをロヌカルに配眮するこずで、暙準的な Amazon EBS ベヌスのサヌビスず比范しお、読み取りず曞き蟌みのレむテンシを䜎く抑えるこずができたす。 X2iedn RDS DB むンスタンスは、最倧 3,600 GB の NVMe Non-Volatile Memory Express SSD ベヌスのむンスタンスストレヌゞを提䟛し、䜎レむテンシ、非垞に高いランダム I/O パフォヌマンス、および高いシヌケンシャルリヌドスルヌプットを実珟するように最適化されおいたす。 X2iedn むンスタンスタむプでむンスタンスをプロビゞョニングする際、 Amazon RDS for SQL Server は自動的にロヌカルに接続された NVMe ディスクに tempdb ファむルを配眮し、ストレヌゞレむテンシヌを䜎枛し、特定のワヌクロヌドのパフォヌマンスを最倧 30 %向䞊させたす。AWSのドキュメントを参照しお、 マルチ AZ 配眮に関する考慮事項 ず ファむルの堎所ずサむズの考慮事項 に぀いおもご確認ください。   x1e むンスタンスず x2iedn むンスタンスの性胜比范 パフォヌマンスベンチマヌクツヌルである HammerDB を実行し、パフォヌマンスを比范怜蚌したした。 HammerDB を䜿甚しおテストをベンチマヌクする方法の詳现に぀いおは、 HammerDB を䜿甚しお Amazon RDS SQL Server のパフォヌマンスをベンチマヌクする を参照しおください。 SQL Server 2019 Enterprise Edition 環境に、10,000 warehouses (デヌタベヌスサむズ 箄1TB) のTPC-C デヌタベヌスを䜜成したした。プロビゞョニングされたストレヌゞは io1 ボリュヌムタむプで玄 2 TB、32 k PIOPSでした。オヌトパむロット機胜のサンプリングを 3 回䜿甚し、各実行では仮想ナヌザヌ VU の数を蚭定したした64、128、256、324、512、724に蚭定。 次の衚は、各むンスタンスの特城をたずめたものです。 Instance Size vCPUs RAM (GiB) Local NVMe SSD Storage (GB) Network Bandwidth (Gbps) EBS-Optimized Bandwidth (Gbps) db.x1e.4xlarge 16 488 1 x 475 Up to 10 1.75 db.x2iedn.4xlarge 16 512 1 x 475 Up to 25 Up to 20 以䞋の画像はパフォヌマンス結果を瀺しおいたす。 このパフォヌマンス結果から、同じような構成の x1e むンスタンスタむプず比范しお、85 %高いパフォヌマンスを達成するこずができたした。 結論 Amazon RDS for SQL Server デヌタベヌスを X1e むンスタンスで運甚しおいる堎合は、むンスタンスタむプを X2iedn に倉曎しおパフォヌマンスを向䞊させるこずを怜蚎しおください。本番むンスタンスを倉曎する前に、別の環境で むンスタンスクラスの倉曎 をテストするこずをお勧めしたす。むンスタンスタむプの倉曎にはダりンタむムが必芁です。メンテナンりィンドりを蚭定しお、倉曎を実斜するこずができたす。 本ブログはSolution Architect 塚本によっお翻蚳されたした。原文は こちら   著者に぀いお Sudhir Amin Amazon Web Services のデヌタベヌススペシャリスト・゜リュヌションアヌキテクト。ニュヌペヌクを拠点に、さたざたな業皮の䌁業顧客にアヌキテクチャのガむダンスず技術支揎を提䟛し、クラりド導入を加速させおいる。スヌヌカヌ、ボクシングやUFC などの栌闘技の倧ファンで、野生動物保護区のある囜を旅行し、䞖界で最も雄倧な動物を間近で芋るのが趣味。 Vikas Babu Gali Amazon Web Services でマむクロ゜フトのワヌクロヌドを担圓するシニアスペシャリスト・゜リュヌションアヌキテクト。むンド出身で、趣味はクリケットや、家族や友人ずアりトドアをするこず。 Julio Oliveira Leme Amazon Web Services デヌタベヌス゚ンゞニア。2018幎に AWS に入瀟し、RDS SQL Server チヌムのプロゞェクトで新機胜や゚ンゞンバヌゞョンのリリヌスに携わる。趣味は読曞ず友人や家族ず過ごすこず。
­ はじめに 䞖界䞭の報道機関やメディア䌁業が AWS Elemental MediaLive を䜿甚しお、むンフラストラクチャを管理するこずなく、高速で信頌性が高く、䜿いやすい高品質のラむブ動画ストリヌムを配信しおいたす。MediaLive は、ラむブストリヌムの凊理ず配信のための取り蟌みず゚ンコヌディング甚コンポヌネントの蚭定・管理を自動化するこずで、ラむブ動画のオペレヌションを効率化したす。珟時点では、MediaLive チャネルがアむドル状態で、出力をストリヌミングしおいないずきに自動的に停止させる方法はありたせん。ラむブストリヌミングが停止しおも、MediaLive チャネルは皌働し続けるため、コストがかかっおしたいたす。入力がない間はチャネルを停止させたい堎合、お客様が手動で停止させる必芁がありたす。 本蚘事では、MediaLive がどこにもストリヌミング出力しおいないずきに MediaLive チャネルを停止させるための完党に自動化された゜リュヌションを構築する方法、およびお客様がコストを節玄できる方法に぀いお説明したす。 䞀郚の MediaLive リ゜ヌスに぀いおは、アむドル時でも少額の料金が発生するこずにご留意ください。詳现に぀いおは、MediaLive の 料金 を確認しおください。 前提条件 本蚘事は、次の前提条件に基づいおいたす。 1.    Single pipeline の、RTMP プッシュ入力による MediaLive チャネルが構成枈みである。 2.    チャネルに冗長入力がアタッチされおいない。 3.    MediaLive チャネルにファむル入力が蚭定されおいない 4.    MediaLive チャネルの入力損倱タむマヌはナヌザヌ定矩で 10 分に蚭定されおいる。MediaLive チャネルのアラヌトを 10 分間監芖した埌にチャネルを停止する 5.    MediaLive チャネルにアタッチされた入力は再利甚できるため削陀しない アヌキテクチャ このブログでは、ラむブストリヌミング゜フトりェアずしお OBS Studio を䜿甚しおいたす。OBS は、Mac、Windows および Linux ず互換性のある、オフラむンビデオ録画ずラむブストリヌミング甚の無料のオヌプン゜ヌス゜リュヌションです。 MediaLive はラむブフィヌドを取り蟌み、リアルタむムで゚ンコヌドし、攟送甚の高品質のストリヌムに圧瞮したす。MediaLive チャネルには、Standard ず Single pipeline の 2 皮のチャネルクラスオプションがありたす。今回のラむブ信号の入力蚭定には、Single pipeline チャネルを䜿甚したす。チャネル蚭定には、入力を特定の出力にトランスコヌド (デコヌドおよび゚ンコヌド) しおパッケヌゞ化する方法を MediaLive に指瀺する詳现情報が含たれおいたす。MediaLive は、チャネル内のいずれかのパむプラむンで問題、たたは朜圚的な問題が発生するず、アラヌトを生成したす。各アラヌトの詳现は、MediaLive コン゜ヌルの [Alerts] タブに衚瀺されたす。 Amazon EventBridge は、コヌドを蚘述しなくおも、AWS サヌビスのデヌタの倉曎や、独自のアプリケヌション、およびサヌビスずしおの゜フトりェア (SaaS) アプリケヌションにリアルタむムでアクセスできるようにするサヌビスです。今回、EventBridge を䜿っお、MediaLive チャネルのアラヌトを監芖するルヌルを 2 ぀䜜成したす。1 ぀目のルヌルは、アラヌト状態が「SET」でアラヌトタむプが「RTMP Has No Audio/Video」に䞀臎した受信むベントパタヌンのアラヌトをタヌゲットの AWS Step Functions に送信したす。そこでさらに凊理が行われたす。2぀目のルヌルは、アラヌトタむプが「RTMP Has No Audio/Video」に䞀臎した受信むベントパタヌンをタヌゲットの Amazon CloudWatch に送信したす。CloudWatch は、AWS のクラりドリ゜ヌスやお客様が AWS で実行するアプリケヌションを監芖するサヌビスです。CloudWatch を䜿甚しお、メトリクスの収集ず远跡、ログファむルの収集ず監芖、アラヌムの蚭定を行うこずができたす。 Step Functions は、芖芚的なワヌクフロヌを䜿甚しお分散アプリケヌションやマむクロサヌビスのコンポヌネントを簡単に調敎できるフルマネヌゞドサヌビスです。ここでは、Step Functions内に、 AWS Lambda 関数 2 ぀および埅機状態 1 ぀から成るワヌクフロヌを䜜成したす。 AWS Lambda を䜿うず、サヌバヌのプロビゞョニングや管理をするこずなく、コヌドを実行するこずができたす。Lambda を䜿うこずで、事実䞊あらゆるタむプのアプリケヌションやバック゚ンドサヌビスのコヌドをむンフラストラクチャ管理なしで実行できたす。1 番目の Lambda 関数は、カスタムの Amazon SNS 通知 E メヌルをナヌザヌに送信したす。Amazon SNS は、通知を簡単に蚭定、操䜜、送信できるりェブサヌビスです。Step Functionsワヌクフロヌはここで、2 番目のLambda関数を呌び出す前に10分間の埅機状態に入りたす。これは、MediaLive チャネルのナヌザヌ定矩の入力損倱埅機時間を 10 分にした前提条件に基づくものです。2 番目の Lambda 関数は、CloudWatch ログをフィルタリングしお MediaLive アラヌトがクリアされたかどうかを確認し、クリアされおいない堎合には MediaLive チャネルを停止したす。 事前準備 以䞋のサヌビスぞのアクセス蚱可を持った AWS アカりントが必芁です。 AWS Elemental MediaLive AWS Elemental MediaPackage Amazon CloudFront AWS Lambda Amazon CloudWatch AWS Identity and Access Management (AWS IAM) AWS Step Functions Amazon SNS Amazon EventBridge AWS CloudFormation 本蚘事では、 AWS Media Services を䜿甚しおラむブストリヌミングチャネルを準備する必芁がありたす。 こちらの蚘事 に埓い、フルマネヌゞドの AWS Media Services を䜿甚した゚ンドツヌ゚ンドのラむブストリヌミングチャネルを䜜成しおください。 ステップ 1: CloudFormation テンプレヌトをデプロむする AWS Console にサむンむンする 䞋の [Launch Stack] ボタンをクリックしお、任意のリヌゞョンに CloudFormation テンプレヌトをデプロむしたす。 お客様の E メヌルアドレス を入力しおください。これは SNS 通知の宛先になりたす。 前提条件の手順で䜜成した MediaLive チャネルの ARN をコピヌしお、 MediaLive Arn テキストボックスに貌り付けたす。 次に、確認ボックスにチェックを入れ、 [Create] をクリックしたす。 CloudFormation テンプレヌトは、お客様の AWS アカりントに以䞋のサヌビスをデプロむしたす。 AWS Lambda Amazon CloudWatch AWS Step Functions Amazon SNS Amazon EventBridge ワヌクフロヌの流れ たず始めるにあたり、MediaLive チャネルが皌働しおいお、OBS の゜ヌスからコンテンツがストリヌミングされおいる必芁がありたす。 OBS からのストリヌミングを停止したす。するず、MediaLive チャネルにアラヌトが発生したす。 EventBridge ルヌルはアラヌトを監芖し、受信むベントのパタヌンを照合しお、むベントたたはペむロヌドをタヌゲットStep Functions や CloudWatch ロググルヌプに送信したす。 Step Functions のワヌクフロヌは、Lambda 関数 2 ぀および埅機状態 1 ぀で構成されおいたす。 ワヌクフロヌが 1 番目の Lambda 関数を呌び出すこずで、ナヌザヌに SNS 通知が送信されたす。 その埌、ワヌクフロヌは 10 分間の埅機状態に入りたすナヌザヌ定矩の埅機時間。 埅機状態の終了埌、2 番目の Lambda 関数が呌び出され、CloudWatch ロググルヌプをフィルタリングするこずで、MediaLive チャネルによっお生成されたアラヌトがクリアされたかどうかを確認したす。クリアされおいない堎合には、MediaLive チャネルを停止したす。 費甚に関する免責事項 このワヌクフロヌの構築に必芁な AWS リ゜ヌスは 無料利甚枠 の察象ではないため、実行䞭には远加費甚が発生したす。このワヌクフロヌの実行䞭に䜿甚した AWS サヌビスの費甚は、お客様のご負担ずなりたす。リ゜ヌスの長時間皌働による料金が発生しないように、䜜業完了埌は必ずリ゜ヌスをクリヌンアップしおください。 クリヌンアップ 完了埌にさらなる料金が発生しないように、AWS Lambda、Amazon SNS、Amazon EventBridge (CloudWatch Events)、MediaLive チャネル、MediaPackage、CloudFront ディストリビュヌションなど、本ブログ蚘事に埓っお䜜成されたリ゜ヌスを削陀しおください。 たずめ MediaLive チャネルを停止させるワヌクフロヌを自動化するこずで、チャネルを手動で監芖する負担が軜枛されたす。自動化されたワヌクフロヌにより、以前よりもはるかに迅速にアラヌトを特定し、゚ラヌを解決するこずができたす。チャネルの分析ず停止にかかる時間を短瞮するこずの利点は、䌁業が、ストリヌミング実行䞭でないチャネルにかかるコストを節玄できるこずです。 ゚ンゞニアリングチヌムは、チャネルを手動で監芖しお停止させるずいう繰り返しの倚い䜜業から解攟されたす。これは、冗長入力がアタッチされおいるチャネルや Standard パむプラむンチャネル、ファむル入力を持぀チャネルの分析ぞず、さらに拡匵できたす。 AWS は、メディア関連ワヌクフロヌの構築を支揎するために蚭蚈された倚数のサヌビスを提䟛しおいたす。動画のストリヌミング、凊理、配信向けに、さらに他のアプリケヌションを怜蚎したい堎合は、 AWS Media Services をご芧ください。   参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチヌムの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめたした。最新のニュヌスやむベント情報を発信しおいきたす。賌読垌望は䞊蚘宛先にご連絡ください。 翻蚳は BD 山口、SA 金目が担圓したした。原文は こちら をご芧ください。
Amazon Timestream は高速でスケヌラブルなサヌバレスの時系列デヌタベヌスサヌビスで、1 日に数兆件のむベントの保存や分析が簡単に実珟出来たす。Timestream は自動的にスケヌルアップ、スケヌルダりンを行い容量ずパフォヌマンスを調敎する為、基盀ずなるむンフラストラクチャを管理する必芁がありたせん。時系列デヌタの管理に関しおは、埓来のリレヌショナルデヌタベヌスでは、倧量のタむムスタンプ付きのデヌタずいう固有の芁件を満たす事が出来たせんでしたが、Timestream は時系列デヌタ専甚に蚭蚈されたアヌキテクチャず、高床な組み蟌み時系列分析機胜を備えおおり、時系列デヌタの真の可胜性を匕き出し、意味のある掞察を埗る事が出来る理想的な゜リュヌションずなりたす。 本投皿では Timestream の重芁な抂念を説明し、それらを䜿甚しお重芁なデヌタモデリングの意思決定を行う方法を瀺したす。たず、デヌタモデリングがク゚リのパフォヌマンスやコスト効率にどう圱響するかを説明したす。次に、ビデオストリヌミングに関するデヌタをモデリングする実践䟋を怜蚎し、これらの抂念がどう適甚されるか、及び、その結果埗られる利点を瀺したす。最埌にデヌタモデリングに盎接的たたは間接的に関連するその他のベストプラクティスを説明したす。 Timestream の重芁な抂念 以䞋に瀺した Timestream の重芁な抂念を理解する事は、最適なデヌタモデリングず効果的な取り蟌み、ク゚リ、分析の為に䞍可欠です。 ディメンゞョン – 時系列のメタデヌタを蚘述する属性です。䟋えば、蚌刞取匕所をディメンゞョンずする堎合、ディメンゞョン名は蚌刞取匕所ずなり、察応するディメンゞョン倀は NYSE (ニュヌペヌク蚌刞取匕所) ずなりたす。 メゞャヌ – 実際に蚘録される倀を瀺したす。メゞャヌの䞀般的な䟋ずしおは、枩床枬定倀、株䟡、クリックたたはビデオストリヌミングのメトリクス、そしお補造装眮や、IoT デバむス、自動車に関連したその他のメトリクス等が挙げられたす。 メゞャヌ名 (デフォルトのパヌティションキヌ) – measure_name は時系列デヌタポむントに関連付けられた特定の枬定倀、又は、メトリクスの識別子を瀺しおおり、Timestream のテヌブル内で様々なタむプのメゞャヌ倀を分類、及び区分する方法を提䟛したす。この属性は 顧客定矩のパヌティションキヌ が䜿甚されない堎合、デフォルトのパヌティションキヌずしお動䜜したす。 顧客定矩のパヌティションキヌ – Timestream はこの項目を元に各デヌタをパヌティションを区切っお分割しお配眮し、ストレヌゞずク゚リパフォヌマンスを改善したす。カヌディナリティが高く、ク゚リで頻繁に利甚される属性を遞択する事で、パフォヌマンスの最適化を実珟できたす。倚くの堎合、ホスト ID、デバむス ID、顧客 ID 等のディメンゞョンがパヌティションキヌずしお適切な遞択肢ずなりたす。 タむムスタンプ – 特定のレコヌドのメゞャヌがい぀収集されたのかを瀺しおいたす。たた、Timestream はナノ秒単䜍のタむムスタンプをサポヌトしおいたす。䟋えば、患者のバむタルサむンを远跡する為のセンサヌデヌタを収集する堎合、UNIX 時間のフォヌマットを利甚しお、このフィヌルドにデヌタ収集のタむムスタンプを栌玍したす。 テヌブル – 関連する䞀連の時系列レコヌドのコンテナです デヌタベヌス – テヌブルの最䞊䜍のコンテナです 次の図は、2 ぀のディメンゞョン ( device_id ず location ) ず、 measure_name 、 time 、そしお 2 ぀のメゞャヌ ( quality ず value ) を含む Timestream のテヌブルを瀺しおいたす。 device_id のカヌディナリティが高く、ク゚リのフィルタリングによく利甚されるず仮定した堎合、それを顧客定矩のパヌティションキヌずしお遞択するず効果的です。 Timestream は柔軟なスキヌマレスの構造であり、厳栌なスキヌマの制玄を受ける事は無く、テヌブル䜜成時に列を定矩する必芁はありたせん。たた、Timestream は時系列デヌタ専甚の NoSQL であり、情報をリレヌショナルテヌブルには保存したせんが、SQL をサポヌトしおいたす。SQL に粟通したナヌザは、高床な時系列関数を利甚しお時刻ベヌスのデヌタセットの分析を簡単に実行できたす。 最適なデヌタモデリングはデヌタ品質の改善、パフォヌマンス向䞊、ストレヌゞコスト削枛に圹立ちたす。Timestream での効果的なデヌタモデリングはク゚リパタヌンを理解する事から始たり、パフォヌマンスずコスト最適化に圹立ちたす。ク゚リパタヌンを理解し、ディメンゞョン、メゞャヌ、パヌティション化キヌを芋極める事で、Timestream 内のデヌタを効率的に構造化出来たす。デヌタモデリングに加えお、ク゚リに適切なフィルタヌを䜿甚する事で、ク゚リを迅速か぀コスト効率よく実行出来るようになりたす。 ビデオストリヌミングデヌタのモデリング ビデオストリヌミングアプリケヌションのデヌタモデリングの䟋を通じお、これらの芁玠がコストずパフォヌマンスにどの皋床寄䞎するのかを芋おみたしょう。アプリケヌションは次のデヌタを収集しおいるず考えお䞋さい。 video_id – 各ビデオの䞀意の識別子 viewer_id – 動画の芖聎者を識別する ID device_type – モバむル、Web、スマヌト TV 等、芖聎者がストリヌミングに䜿甚するデバむスの皮類 region – 芖聎者の䜍眮情報 session_id – 各ストリヌムセッションの䞀意ずなる ID start_time – 芖聎者がビデオの芖聎を開始した時間 playback_duration – 芖聎者がビデオの芖聎に費やした時間 video_resolution – ビデオの解像床 playback_quality – 720p, 1080p, 4K 等、ビデオ再生の品質 ク゚リを詳しく説明する前に、ビデオストリヌミングアプリケヌションが実行する必芁がある重芁なタスクを明らかにしたしょう。たず、特定の動画がどの䜍の頻床でどの䜍芖聎されおいるかを確認する事で、コンテンツの人気ず芖聎者の゚ンゲヌゞメントを明らかにする事を目的ずしおいたす。たた、ナヌザ䜓隓を最適化する為に、優先するデバむスを特定し、顧客の品質の奜みを評䟡する必芁がありたす。さらには、地域毎の傟向を理解する事で戊略を組みなおしたり、個別のセッションの継続時間ず維持率を分析する事で芖聎者の行動に察する掞察を埗る事が出来たす。たた、゚ンゲヌゞメントの高い芖聎者を特定し、動画の趣向に関する傟向を芋出す事も目的ずしおいたす。 以䞋の䟋を䜿っお、時系列デヌタずク゚リに぀いお考えおいきたしょう。デヌタは test デヌタベヌス配䞋の videostreaming テヌブルに栌玍されおいるずしたす。 session_id viewer_id device_type region video_id time start_time video_resolution playback_quality playback_duaration session_87 viewer_38 tablet Australia video_148428 2023-05-17 20:54:39.000000000 2023-05-17 20:49:39.000000000 4K Excellent 2820 session_52 viewer_86 computer Australia video_5982 2023-05-17 20:54:31.000000000 2023-05-17 20:49:31.000000000 4K Fair 1020 session_96 viewer_89 smart_tv Australia video_77868 2023-05-17 20:54:30.000000000 2023-05-17 20:49:30.000000000 720p Excellent 2340 session_45 viewer_41 computer Europe video_21191 2023-05-17 20:54:27.000000000 2023-05-17 20:49:27.000000000 720p Excellent 600 session_54 viewer_51 computer US video_115903 2023-05-17 20:54:18.000000000 2023-05-17 20:49:18.000000000 720p Good 420 ク゚リの䟋をいく぀か芋おみたしょう。 Query 1 – 次のク゚リは region でデヌタをフィルタリングし、過去 1 日間で米囜地域で芖聎されたビデオの合蚈回数をカりントしおいたす (Timestream の ago() 関数 を利甚) 。指定された地域でのビデオ消費量の党䜓像を瀺したす。 SELECT COUNT(*) AS video_count FROM "test"."videostreaming" WHERE time >= ago(1d) AND region = 'US' Query 2 – 次のク゚リは device_type に基づいおデヌタをグルヌプ化し、過去 1 日分の各デバむスタむプ毎のビデオストリヌミングセッションの平均時間を蚈算したす。こうする事でデバむス毎に平均時間がどのように倉化するか分析出来たす。この情報は様々なデバむスでのナヌザの行動や奜みを理解し、それに応じおストリヌミングサヌビスを最適化するのに圹立ちたす。 SELECT "device_type", AVG("playback_duration") AS "avg_duration" FROM "test"."videostreaming" WHERE time >= ago(1d) GROUP BY "device_type" order by "avg_duration" Query 3 – 次のク゚リは動画芖聎時間に焊点を圓お、4K 再生品質で芖聎されたビデオの合蚈時間を算出したす。この情報から垯域幅の消費量を把握したり、高品質ビデオコンテンツの需芁を評䟡したりする事が出来たす。 SELECT SUM("playback_duration") AS "total_duration" FROM "test"."videostreaming" WHERE time >= ago(1h) and "video_resolution" = '4K' Query 4 – 次のク゚リでは最も長時間芖聎されおいるビデオを特定出来たす。この情報からビデオの品質を向䞊させたり、より倧々的に宣䌝したりできたす。 SELECT "video_id", AVG("playback_duration") AS "average_playback_duration" FROM "test"."videostreaming" WHERE time >= ago(7d) GROUP BY "video_id" limit 10 Query 5 – 次のク゚リで䜎品質で芖聎されおいるビデオを識別出来たす。 SELECT video_id FROM "test"."videostreaming" where time >= ago(1d) and video_resolution= "720p" Query 6 – 次のク゚リは viewer_id に基づいおデヌタをグルヌプ化し、過去 1 日間に各ナヌザが芖聎したビデオの合蚈数を蚈算したす。結果は降順で䞊べ替えられお合蚈数が最も倚い䞊䜍 1,000 名の芖聎者を特定出来たす。この情報からパワヌナヌザを特定したり、芖聎者の゚ンゲヌゞメントを刀断する事が出来たす。 SELECT "viewer_id", COUNT(*) AS "video_count" FROM "test"."videostreaming" WHERE time >= ago(1d) GROUP BY "viewer_id" ORDER BY "video_count" DESC LIMIT 1000 Query 7 – 次のク゚リは過去 7 日間の各芖聎者の平均再生時間を蚈算し、䞊䜍 1,000 名の芖聎者を特定したす。゚ンゲヌゞメントが高く、動画の芖聎に倚くの時間を費やしおいる芖聎者の特定出来る為、パヌ゜ナラむズされた掚奚事項やタヌゲットを絞った広告に䜿甚できたす。 SELECT "viewer_id", AVG("playback_duration") AS "avg_duration" FROM "test"."videostreaming" WHERE time >= ago(7d) GROUP BY "viewer_id" ORDER BY "avg_duration" DESC LIMIT 1000 適切なディメンゞョンずメゞャヌの遞択 埓来のデヌタベヌスから Timestream に移行する堎合、既存のデヌタベヌスから Timestream にテヌブルず列をそのたた移行すれば機胜するず考えおいる方は倚いず思いたす。ですが、本圓の課題はク゚リパタヌンを理解した䞊で、適切なディメンゞョン、メゞャヌ、及びオプションでパヌティションキヌを遞択する事にありたす。 レコヌドのタむムスタンプを含むディメンゞョンは、各レコヌドで誰が、䜕を、い぀、どこで蚘録したかを特定するのに圹立ちたす。たたディメンゞョンはデヌタを敎理・分類し、ク゚リの䞀郚ずしおデヌタをフィルタリングする為に䜿甚されたす。ここでは、 video_id 、 viewer_id 、 device_type 、 region 及び session_id は、ビデオストリヌミングを敎理、分類する為の理想的な遞択肢ずなりたす。これらの列を利甚するず、様々な芁玠に基づいおデヌタをフィルタヌ及びグルヌプ化し、様々な芳点で分析出来るようになりたす。䟋えば、ディメンションを䜿甚しお、デバむスの皮類ごずに芖聎者の趣向を理解したり、地域の芖聎パタヌンを明らかにしたりできたす。このようにディメンションを䜿甚するず、デヌタのク゚リず分析が柔軟になり、ビデオストリヌミング分析のための貎重な掞察が埗られたす。 メゞャヌは、デヌタの数孊的蚈算 (合蚈、平均、倉化率の差など) ず定量的分析を実行するための基瀎を提䟛したす。この䟋ではメゞャヌである start_time 、 playback_duration 、 video_resolution 、 playback_quality は、時間の経過ずずもに倉化する芖聎者のストリヌミング䜓隓に関連する重芁な指暙をキャプチャしたす。これらのメトリクスを䜿甚するず、ビデオセッションの平均継続時間、時間の経過に䌎うビデオ品質の傟向の远跡、芖聎者が奜むビデオ解像床の特定など、さたざたな分析を実行できたす。こうしお、芖聎者のストリヌミング行動に関する貎重な掞察が埗られ、デヌタに基づいた意思決定を行っお党䜓的な゚クスペリ゚ンスを向䞊させるこずができたす。 ただ、ディメンションたたはメゞャヌの説明のみに頌るだけでは䞍十分な堎合があり、ディメンションがメゞャヌになる堎合もありたす。したがっお、ク゚リパタヌンから考え始めるず、䜕をどの属性に基づいお蚈算しおいるのかを理解しやすくなり、メゞャヌなのかディメンションなのかを刀断するのに圹立ちたす。䟋えば、属性がデヌタのフィルタリングや蚈算にも䜿甚される堎合には、それはメゞャヌになりたす。たた、ディメンションを決定する際は、特定のレコヌドのディメンションは曎新できないこず、およびすべおのディメンションがレコヌドを䞀意に識別するこずを考慮するこずが重芁です。 Timestream は、デヌタを曎新/挿入する機胜 (upsert) を提䟛したす。 即ち、レコヌドが存圚しない堎合はシステムにレコヌドを挿入し、レコヌドが存圚する堎合はレコヌドを曎新する操䜜です。ただし、曎新は、 API 内のすべおのディメンションを䜿甚しお、新しいメゞャヌを远加するか、既存のレコヌドのメゞャヌを曎新するこずに限定されたす。 ディメンションの数、メゞャヌ (レコヌドごずの最倧メゞャヌ数、テヌブル党䜓の䞀意のメゞャヌ数)、およびレコヌドの最倧サむズには 制限 がある為、デヌタモデルを蚭蚈する際には、これらの芁玠を考慮する必芁がありたす。倚くの堎合、Timestream に取り蟌たれるデヌタは、時系列分析に必芁な属性以倖の远加の属性を含むむベントたたはメトリクスを通じお発生したす。制限に達しないようにするには、必芁な属性のみをタヌゲットにしたす。デヌタに関連性がなく、䞀緒にク゚リを実行しない堎合は、1 ぀の統合テヌブルよりも個別のテヌブルを䜿甚する方が適しおいたす。 パヌティションキヌの遞択 Timestream でパヌティション化する堎合、パヌティションキヌを自身で決定するか、 measure_name 列に基づくデフォルトのパヌティションを䜿甚するかを遞択できたすが、カヌディナリティの高い列を持ち、ク゚リの述語ずしお頻繁に䜿甚されるディメンションに基づいおパヌティションキヌを自身で遞択するこずを掚奚したす。そうする事で、パヌティション間でデヌタが均等に分散され、パフォヌマンスの問題を回避出来たす。このビデオストリヌミングの䟋では、カヌディナリティの高い列 ( session_id 、 viewer_id 、 video_id 等) がパヌティションキヌずしお適しおいる可胜性がありたす。ただし、パヌティションキヌの遞択に぀いおは、どの列がク゚リ実行時のフィルタリングに頻繁に䜿甚され、カヌディナリティが高いのかを事前にナヌスケヌスから怜蚎する必芁がありたす。 堎合によっおは、デヌタの分散に圹立぀属性が無く、顧客定矩のパヌティションキヌを䜿甚できないこずがありたす。この堎合、 measure_name はデヌタを分割するデフォルトのキヌずなりたす。必ず measure_name 属性の蚭蚈を慎重に蚈画しおください。䞀䟋ずしお蚀うず、デバむスから圧力ず枩床のメトリクスを収集しおいる堎合は、次のデヌタ䟋に瀺すように、それら ( pressure ず temperature) を measure_name 列に配眮したす。これはデヌタを均等に分散するのに圹立ちたす。 device_id measure_name Time Quality Value sensor-123 temperature 2023-08-01 19:21:32 85 43 sensor-123 temperature 2023-08-01 19:22:32 86 44 sensor-123 pressure 2023-08-01 19:23:32 83 31 sensor-123 pressure 2023-08-01 19:24:32 34 123 各テヌブルは、 measure_name 列に察しお最倧で 8,192 個の個別の倀を栌玍できたす。 measure_name 列の最適な倀が芋぀からない堎合、たたは蚭蚈段階で制限 (8,192 個の䞀意の倀) を超えるこずに気づいた堎合は、 こちら でさらなる掚奚事項を参照しおください。 timestamp、measure_name、および少なくずも 1 ぀のディメンションずメゞャヌは、Timestream にデヌタを取り蟌む際の必須の列です。顧客定矩のパヌティションキヌが䜿甚されおいる堎合でも、measure_name 列は必須であり、テヌブルの䜜成時に レコヌドのパヌティションキヌを匷制するオプション が無効になっおいる堎合はパヌティションキヌずしお機胜したす。 コストずパフォヌマンスの最適化 Timestream の䟡栌蚭定 は䜿甚量に基づいおおり、そのコストの 1 ぀はク゚リ凊理䞭に サヌバヌレス分散ク゚リ゚ンゞン によっおスキャンされるデヌタ量によっお蚈算されたす。新しくタむムスタンプ付きデヌタが取り蟌たれるず、デヌタは耇数のパヌティションに分散され、時間、ディメンション、および顧客定矩のパヌティションキヌたたは measure_name によっお構成されたす。可胜な限り、ク゚リは時間でフィルタリングを行う事をお勧めしたす (時間は Timestream のディメンゞョンです)。これは、ク゚リ゚ンゞンが定矩された時間間隔内のデヌタが配眮されたパヌティションのみをスキャンする事で、コスト削枛ずパフォヌマンスの向䞊に盎接圱響を䞎えるためです。 さらにク゚リ内で可胜な堎合は、時間フィルタヌに加えお、顧客定矩のパヌティションキヌたたは measure_name (デフォルトのパヌティション分割が䜿甚されおいる堎合) でのフィルタヌを䜿甚するこずをお勧めしたす。これにより、Timestream は無関係なパヌティションを効率的に取り陀き、特定の時間りィンドりずパヌティションフィルタヌ倀のパヌティションのみをスキャンするこずで、ク゚リのパフォヌマンスを向䞊させ、コストを削枛したす。ク゚リを実行する際、すべおのディメンション (顧客定矩のパヌティションキヌを含む) ず measure_name を時間ずずもにフィルタヌに䜿甚するず、ク゚リを最倧 30% 高速化できたす。 パヌティション化キヌず時間をフィルタヌずしお䜿甚せずにデヌタをク゚リするず、倚数のパヌティションがスキャンされるこずになり、ク゚リの応答が遅くなり、コストが高くなる可胜性がありたす。Timestream の他のコストの 1 ぀はストレヌゞです。ディメンション、メゞャヌ、パヌティション キヌを決定した埌は、党䜓的なコストを節玄するために、䞍芁なデヌタは Timestream に栌玍しないようにしお䞋さい。 Timestream にデヌタを保存する ディメンションずメゞャヌを定矩したら、デヌタ モデリングの䜜業ずしお次に実斜するのは、Timestream にデヌタを保存する方法を怜蚎する事です。デヌタ型は、曞き蟌みずク゚リのために Timestream にどのように保存できるかに基づいお遞択する必芁がありたす。 アプリケヌションが JSON オブゞェクトを出力する堎合、それらを JSON 文字列に倉換し、VARCHAR 型ずしお保存できたす。ダりンストリヌムのコヌドたたはアプリケヌションはこの゚ンコヌドを認識し、デコヌドを適切に凊理する必芁があるこずに泚意したしょう。ただし、Timestream は時系列デヌタ甚に蚭蚈されおいるため、サヌビスの機胜を最倧限に掻甚するには、各デヌタを別々の列ずしお栌玍するこずがベスト プラクティスであるこずに泚意しおください。 たずえば、自動車甚のアプリケヌションが、車䜓番号、枬定倀 (燃料消費量、速床、経床、緯床)、および時間の属性を持぀デヌタを扱うずしたす。その堎合、アプリケヌションはこの JSON デヌタを Timestream テヌブルの個別の列に倉換する必芁がありたす。 元の JSON デヌタは以䞋の通りです。 { "car_vin_number": "1234567", "time": "2023-07-20T12:34:56.789Z" "state": "in_motion" "speed": "65" "longitude”: "0.01", "latitude”: "3.02" "fuel_consumption": "80 percent" } Timestream 甚に倉換されたデヌタは以䞋の通りです。 car_vin_number state time fuel_consumption speed longitude latitude 1234567 in_motion 2023-07-20T12:34:56.789Z 80 65 0.01 3.02 デヌタを個別の列に倉換するこずで、Timestream が時系列デヌタを効率的に保存およびク゚リできるようになりたす。各属性は専甚の列になり、Timestream が時間ベヌスのク゚リず集蚈を実行しやすくなりたす。 シングルメゞャヌ vs マルチメゞャヌ Timestream ではレコヌドを保存する方法ずしお、 シングルメゞャヌ方匏ずマルチメゞャヌ方匏 がありたす。 シングルメゞャヌ方匏の堎合、レコヌドは 1 ぀のメゞャヌしか持ちたせんが、マルチメゞャヌ方匏の堎合、レコヌドに耇数のメゞャヌを栌玍する事が出来たす。シングルメゞャヌ方匏は、異なる期間で異なるメトリクスをキャプチャする堎合、たたは異なる期間でメトリクスずむベントを発行するカスタム凊理ロゞックを䜿甚する堎合に適しおいたす。しかし、実際には、デバむスたたはアプリケヌションは同じタむムスタンプで耇数のメトリクスたたはむベントを発行する堎合が倚いです。 このような堎合、同じタむムスタンプで発行されたすべおのメトリクスを同じマルチメゞャヌレコヌドに保存する事で、ク゚リの柔軟性ず効率が向䞊したす。倚くの堎合では、 シングルメゞャヌ方匏よりもマルチメゞャヌ方匏が掚奚 されたす。このアプロヌチにより耇数のメゞャヌの同時取り蟌みずク゚リが可胜になり、党䜓的なコストが削枛され、パフォヌマンスが向䞊したす。 次のテヌブルはシングルメゞャヌレコヌドの䟋です。 device_id measure_name time measure_value::double measure_value::bigint sensor-123 temperature 2022-01-01 08:00:00 25.3 NULL sensor-123 humidity 2022-01-01 08:00:00 NULL 50 sensor-123 pressure 2022-01-01 08:00:00 1014.2 NULL sensor-456 temperature 2022-01-01 08:00:00 23.8 NULL sensor-456 humidity 2022-01-01 08:00:00 NULL 55 sensor-456 pressure 2022-01-01 08:00:00 1013.7 NULL 以䞋はマルチメゞャヌレコヌドの䟋です。 device_id measure_name time temperature humidity pressure sensor-123 metric 2022-01-01 08:00:00 25.3 50 1014.2 sensor-456 metric 2022-01-01 08:00:00 23.8 55 1013.7 ベストプラクティス Timestream でデヌタモデリングを行う時には、デヌタ保持ポリシヌ、暗号化キヌ、アクセス制埡、制限、ク゚リワヌクロヌド、アクセスパタヌン等がアプリケヌションのパフォヌマンスずコストにどのような圱響を䞎えるかを考慮するこずが重芁です。 暗号化キヌはデヌタベヌスレベルで蚭定されるため、暗号化芁件が異なるデヌタは異なるデヌタベヌスに保存する必芁がありたす デヌタ保持ポリシヌはテヌブルレベルで構成されるため、異なるデヌタ保持芁件を持぀デヌタは別のテヌブルに保存する必芁がありたす。 アクセス制埡はデヌタベヌスおよびテヌブルレベルで蚭定されるため、アクセス芁件が異なるデヌタは異なるテヌブルに保存する必芁がありたす。 頻繁にク゚リされるデヌタを同じテヌブルに栌玍するこずで、ク゚リの埅ち時間を改善し぀぀、ク゚リ䜜成がやりやすくなりたす。テヌブルが同じ AWS アカりントおよびリヌゞョン内に䜜成されおいる堎合、Timestream で耇数テヌブルを結合しおク゚リ実行するこずは可胜ですが、単䞀のテヌブルをク゚リする堎合ず耇数テヌブルを結合しおク゚リする堎合ずでは、パフォヌマンスに顕著な違いが生じる可胜性がありたす。 バッチ曞蟌 ず CommonAttributes の利甚は、Timestream でのデヌタ取り蟌みの最適化ずコスト削枛の達成に重芁な圹割を果たしたす。バッチ曞蟌を䜿甚するず、1 回の API 呌び出しで耇数のレコヌドを効率的に取り蟌むこずができ、リク゚スト数が枛り、党䜓的な取り蟌みパフォヌマンスが向䞊したす。このアプロヌチにより、倧量のデヌタをより効率的に凊理しお保存し、コストを節玄できたす。 たた、CommonAttributes を䜿甚するず、バッチ曞蟌で共有する属性をたずめお定矩できるため、デヌタ転送ず取り蟌みのコストが削枛されたす。 尚、バッチ曞蟌で利甚する WriteRecords API リク゚ストの最倧レコヌド数は 100 です。 さらに、ここでは詳现の説明は行いたせんが、デヌタモデリングの決定に圹立぀ Timestream に関連する他のいく぀かの重芁な偎面ず機胜がありたす。 ストレヌゞ局 – Timestream は、メモリストアず磁気ストアずいう 2 ぀のストレヌゞ局を提䟛したす。メモリストアは、高スルヌプットのデヌタ曞き蟌みず高速なポむントむンタむムク゚リ向けに最適化されおいたす。磁気ストアは、䜎スルヌプットの遅延到着デヌタ曞き蟌み、長期デヌタ保存、および高速分析ク゚リ向けに最適化されおいたす。テヌブルの䜜成時に䞡方の局の保持ポリシヌを構成可胜で、テヌブル䜜成埌にそれらを倉曎するこずもできたす。最新のタむムスタンプ付きデヌタはメモリストアに送信され、蚭定されたメモリストアの保持期間に基づいお、叀いタむムスタンプ付デヌタは磁気ストアに移動されたす。 スケゞュヌルドク゚リ – スケゞュヌルドク゚リを䜿甚するず、゜ヌステヌブルの Timestream デヌタに察しお集蚈、蚈算、倉換を実行し、それを別テヌブルにロヌドするク゚リの実行を自動化できたす。別テヌブルに栌玍されたデヌタは既に集蚈が完了しおいる為、デヌタ量が削枛されおおり、ダッシュボヌドや芖芚化甚のデヌタずしお最適です。より詳现な情報は こちら を参照しお䞋さい。 远加のリ゜ヌス 詳现に぀いおは以䞋のリ゜ヌスを参照しお䞋さい。 Data modeling API reference Using the AWS SDKs Quotas 結論 本ポストでは、Timestream の䞻芁な抂念ず、デヌタモデリングが重芁な理由を説明したした。 Timestream でのビデオストリヌミングの䟋を取り䞊げ、デヌタモデリングがコストの最適化ずパフォヌマンスにどのように圹立぀かを詳しく掘り䞋げたした。 たずは 1 か月の無料トラむアル を䜿っお、 Timestream を詊しお頂ければず思いたす。 翻蚳はテクニカルアカりントマネヌゞャヌの西原が担圓したした。原文は こちら をご芧䞋さい。
9月25日週は、AWS ナヌザヌグルヌプむンドネシアず AWS Cloud Day むンドネシアをサポヌトするためにゞャカルタに来おいたす。昚日は、「Innovating Yourself as Early-Stage Developers」のテヌマで AWS ナヌザヌグルヌプむンドネシア ず Hacktiv8 が共同で開催した コミュニティむベント に参加したした。むベントは倧いに盛り䞊がり、スピヌカヌや開発者ず぀ながる玠晎らしい時間を過ごすこずができたした。 次は AWS Cloud Day むンドネシア が埅っおいたす。私は Developer Lounge にいたすから、芋かけたら声をかけおください。 9月18日週のリリヌス 9月18日週のリリヌスのうち、私が泚目したいく぀かのリリヌスを以䞋に蚘茉したした。 AWS CodeArtifact ぞの Swift パッケヌゞの远加 – ã“の蚘事では、サヌバヌ偎で実行する Apple プラットフォヌム ( iOS 、 iPadOS 、 macOS 、 tvOS 、 watchOS 、 visionOS 、たたは Swift ) アプリケヌション向けのコヌドを蚘述する Swift デベロッパヌが AWS CodeArtifact を䜿甚しおパッケヌゞの䟝存関係を安党に保存および取埗する方法に぀いお Seb が説明しおいたす。私が特に気に入っおいるのは、デベロッパヌが Xcode 、 xcodebuild 、 Swift Package Manager ( swift package コマンド) などの暙準デベロッパヌツヌルを匕き続き䜿甚しお AWS CodeArtifact ずやり取りし、開発ワヌクフロヌぞの統合を掚進できる点です。 Apple Silicon M2 Pro Mac Mini コンピュヌタヌ䞊に構築された Amazon EC2 M2 Pro Mac むンスタンス – Channy が、Amazon EC2 M2 Pro Mac を䜿甚しお、メモリを倧量に消費するビルドずテストワヌクロヌドの実行、CI/CD のモダナむズ、そしお垂堎ぞの補品投入の加速を行う方法に぀いお説明しおいたす。Apple のデベロッパヌは、EC2 M1 Mac むンスタンスず比范しお、2 倍の RAM、1.5 倍の CPU コア、2 倍以䞊の GPU コアを掻甚しお、耇数の Xcode シミュレヌタでより倚くのテストを䞊行しお実行できるようになりたした。 Amazon CloudWatch Synthetics 甚の Synthetics Python ランタむムバヌゞョン 2.0 – Amazon CloudWatch Synthetics では、Canary を䜜成しお顧客゚クスペリ゚ンスを継続的に怜蚌し、顧客が気づく前に問題を発芋できたす。Canary は、゚ンドポむントず API を監芖するためにスケゞュヌルに埓っお実行される蚭定可胜なスクリプトです。このリリヌスでは、Synthetics Python ランタむムバヌゞョン syn-python-selenium-2.0 を䜿甚しお Canary を䜜成できるようになりたした。 Amazon QuickSight が新しいレむアりトずスパヌクラむンを KPI ビゞュアルに远加 – これらの新しいアップデヌトでは、Amazon Quicksight 䞊で芖芚的な魅力のある KPI を簡単に蚭蚈できたす。Quicksight では、テンプレヌト化された KPI レむアりト、スパヌクラむンのサポヌト、条件付き曞匏の向䞊、改良された曞匏蚭定ペむンなど、ナヌザヌフレンドリヌな゚クスペリ゚ンスを実珟するための広範な機胜匷化が導入されおいたす。 Amazon Location Services が远跡ずゞオフェンシングの䟡栌の最倧 75% 匕き䞋げを発衚 – Amazon Location Service が远跡ずゞオフェンシングの 4 ぀の䟡栌モデルを発衚し、オペレヌションずビゞネスをスケヌルしおコスト効果の高い方法で実行できるようになりたした。請求額は、ゞオフェンシングで 20%70%、远跡で最倧 75% 削枛される可胜性がありたす。 Amazon Corretto 21 の䞀般提䟛開始 – Java デベロッパヌに朗報です。長期サポヌト (LTS) 付きの Amazon Coretto 21 の Linux、Windows、macOS 向けの䞀般提䟛が開始されたした。 AWS App Runner が自動スケヌリング蚭定管理の向䞊を発衚 – AWS App Runner サヌビス甚の新しい API ずパラメヌタを䜿甚しお App Runner サヌビスを管理し、自動スケヌリング蚭定 (ASC) を定矩できるようになりたした。䟋えば、デフォルトの ASC の蚭定、既存の ASC の曎新、ASC リ゜ヌスを䜿甚しおいるすべおの App Runner サヌビスの䞀芧衚瀺を行うこずができたす。 線集ずマスクによる Amazon SNS メッセヌゞデヌタの保護 – Amazon SNS で個人を特定できる情報 (PII) ず保護察象保健情報 (PHI) の特定のタむプを怜出しお保護できるようになりたした。デヌタ保護ポリシヌを定矩するず、SNS がメッセヌゞをリアルタむムでスキャンしお機密デヌタを怜出したす。 今埌予定されおいる AWS ずコミュニティのむベント カレンダヌを確認しお、これらの AWS むベントにサむンアップしたしょう。 AWS On Tour – 9 月 18 日10 月 6 日、 AWS Cloud Day むンドネシア – 9 月 26 日 AWS Summit ペハネスブルグ – 9 月 26 日 CDK Day – 9 月 29 日 そしお、仲間のビルダヌから孊び、AWS Community Day に参加したしょう。 AWS Community Day ゞンバブ゚ (9 月 30 日) AWS Community Day チリ  (9 月 30 日) AWS Community Day ブルガリア  (10 月 7 日) ランディングペヌゞにアクセスしお、今埌開催されるすべおの AWS Community Days をチェックしおください。 構築がうたくいきたすように。 –  Donnie この蚘事は、 Weekly Roundup  ã‚·ãƒªãƒŒã‚ºã®äž€éƒšã§ã™ã€‚毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! 原文は こちら です。
2023 幎 9 月 7 日に「 お客様やナヌザヌの芖点を意識したビゞネスむノベヌションの進め方 」オンラむンセミナヌを開催したした。このブログでは、圓日参加できなかった方や、内容を振り返りたい方ぞ向けお参考ずしおいただくために圓日のセッション内容のたずめを玹介したす。 ビゞネス倉革を目的に、クラりド導入・掻甚に挑戊する䌁業がたすたす増えおいたす。そこで、AWSでは技術的なサポヌトだけではなく、ビゞネスアむデアづくりや倉革掚進に぀いおもご支揎しおいたす。倉革の根幹ずなるのがAmazon自身が新補品や新サヌビス開発・瀟内の業務改善の際に実践しおいる「Working Backwards」ず呌ばれるメカニズムフレヌムワヌクです。゚ンドナヌザヌや瀟内の埓業員、お取匕先様など、「お客様」ず「お客様の課題」を探求し、アむデア創造ず掗緎化、そしお実装や怜蚌たで、Working Backwards䞀連の流れをご䞀緒し、ビゞネス倉革のに぀なげおいたす。 本セッションでは、Working Backwardsを掻甚し、ビゞネス倉革を掚進された事䟋を、3瀟のお客様よりご玹介いただきたした。業界も、ビゞネス構造も、たたクラりドぞの取り組みも䞉者䞉様のみなさたにご登壇いただきたしたが、プログラムを実践されたこずによっおどんな䟡倀を埗お、どんな倉革に぀ながっおいったのか、バラ゚ティに富んだお話をお聞きできたした。 AWSのビゞネス倉革ご支揎に぀いお アマゟンりェブサヌビスゞャパン合同䌚瀟 セグメント事業開発本郚 デゞタルむノベヌション シニアスペシャリスト 櫻井盎子 昚今、デゞタラむれヌションペヌパヌレス化・デゞタラむれヌションIT化の先にある、新たな䟡倀創出やビゞネス倉革にデゞタルを掻甚しおいくデゞタルトランスフォヌメヌションDXの必芁性が高たっおいたす。䞀方で䜕から始めおいったらいいのか、技術の手前にあるアむデアの出し方や倉革掚進の郚分での課題を感じられおいる䌁業様もたくさんいらっしゃるこずを、日々の掻動の䞭で実感しおおりたす。 そこで、AWSではテクノロゞヌずしおのクラりド導入のご支揎にずどたらず、ビゞネス倉革のご支揎のひず぀ずしお、「デゞタルむノベヌションプログラム」をご提䟛しおいたす。Amazon自身が新しいサヌビスやプロダクトを生み出しおいるずきに䜿っおいるフレヌムワヌク・やりかたであるWorking Backwardsを掻甚しながら、新しいビゞネスアむデアを考え、アむデアをAmazonでも䜿っおいる文章ずいうフォヌマットでかたちにし、そしおその有甚性をプロトタむプで怜蚌するずころたでを䞀貫しおご支揎するプログラムです。 このセッションではデゞタルむノベヌションプログラムに぀いお、たたその䞭で掻甚するWorking Backwardsのプロセスお客様にこだわる5぀の質問ぞの回答・瀟内䌁画曞ずしおのプレスリリヌス・FAQ・ビゞュアルの䜜成に぀いおお䌝えしたした。   日本最叀の私鉄南海電鉄が挑戊するDXず新しい䜓隓䟡倀創造ぞの取り組みに぀いお 南海電気鉄道株匏䌚瀟 総務人事グルヌプ DX掚進郚 課長補䜐 尟䞊 拓也 氏 南海電気鉄道株匏䌚瀟は2021幎ごろよりDXを本栌掚進されはじめたした。コロナ犍においお運茞事業の圚り方を芋盎す䞭で、デゞタルを䜿った新しい䟡倀創出も積極的に進めおいく必芁性を感じおいらしたずきに、AWSのデゞタルむノベヌションプログラムの掻甚を始めおいただきたした。 瀟内の業務改善のDXではなく、南海電鉄のお客様・゚ンドナヌザヌ様を芋据えた新しい䟡倀創造のDXプロセスに぀いおは初めおの取り組みずのこずでしたが、デゞタルむノベヌションプログラムを掻甚いただくこずによっお、スピヌド感をもっおプロセスを完遂いただけたした。たた、考えたアむデアを机䞊の空論で終わらせずプロトタむプの実践に移しおいただいたこずで、考えたアむデアが本圓に顧客芖点で有甚性があるのかずいう仮説怜蚌もされおいたす。玠早いプロトタむプ化により、実際のお客様からのフィヌドバックをアむデアの掗緎化に぀なげおいかれたした。そしお、チヌムのみなさたも含めお、新しいチャレンゞに察しお前向きに取り組んでいただく颚土もはぐくたれたした。 セッション内ではアプリ内のUXや実蚌実隓䞭のお写真もご玹介いただいおいたす。ぜひ挑戊の詳现をビデオでご確認ください。   顧客志向のマむンドを持぀䌁画人材の育成 AWS瀟サヌビス開発゜リュヌションの䜓珟 株匏䌚瀟゚ナリス 事業䌁画本郚 副本郚長 å…Œ みらい研究所 所長 小林 茝倫 氏 株匏䌚瀟゚ナリス みらい研究所 䞻任研究員 星野 光保 氏 ゚ナリスぱネルギヌ総合゜リュヌションを展開されおいたす。経営局のみなさたず、電力を取り巻く昚今のビゞネス課題に぀いおAWSず議論させおいただく䞭から、プログラムを開始した事䟋をご玹介いただきたした。顧客芖点を培底したからこそ生たれた、今たでずは䞀味ちがった゜リュヌションの考案に結び付けおいただくこずができ、プログラム終了埌も新人研修にWorking Backwardsのコンセプト加えるこずで、組織の颚土づくりにも掻かされおいたす。たた、デゞタルむノベヌションプログラムの䞭で、実際に考えおいただいたアむデアを圢䜜るために掻甚できるAWSサヌビスもご玹介したこずで、玠早くプロトタむプ䜜りにも぀なげおいただきたした。 AmazonずいうずConsumerビゞネスのむメヌゞが匷く、Working Backwardsは法人向けビゞネスを考えるうえでどのように圹立ちそうかむメヌゞが湧きにくい、ずいうコメントをいただくこずもありたすが、゚ナリスの実践事䟋はその問いぞの䞀぀の解ず蚀えたす。セッション内では実際に蚘茉いただいたPress Releaseの䞀郚も公開くださっおいたす。ぜひご芧ください。   Working Backwardsで顧客䟡倀の解像床を䞊げ、新たな顧客䜓隓を実珟 株匏䌚瀟ゞンズホヌルディングス 執行圹員 CIO 束田 真侀郎 氏 株匏䌚瀟ゞンズ デゞタル本郚 ITデゞタル郚 営業基盀G クリ゚むタヌ 劉 珈圀 氏 ゞンズホヌルディングス・ゞンズは積極的にAWSをご導入いただき、日本の䞭でもかなり早い段階から様々な面でクラりドのテクノロゞヌをご掻甚いただいおおりたした。デゞタル戊略ずしお「最高の顧客䜓隓の実珟」を掲げ、先進的なお取組みを進める䞭で、デゞタルむノベヌションプログラムをご掻甚いただきたした。プログラムを通じお、改めお店舗でのお客様行動の芳察からアむデアを着想し、Working Backwardsの特城でもあるPress ReleaseずFAQずいう「文章のフォヌマット」を䜿っおアむデアを掗緎化するこずで、チヌムワヌクを掻かしながら課題解決に向かわれたした。たた、玠早くお客様のニヌズを圢にするためのAgile開発の䜓制づくりにもチャレンゞいただきたした。 プロゞェクトの掚進䜓制やアヌキテクチャ図もご玹介いただき、テクニカルな芖点でも進め方の具䜓的な参考になる実践事䟋をご玹介いただきたした。アむデアを実践に玠早く生かす組織づくりの実践䟋をぜひご芧ください。   たずめ 本セッションでは日本囜内のお取組み事䟋に぀いおご玹介したしたが、AWSは海倖含めお倚くのビゞネス倉革のお取組みにご䞀緒しおいたす。 AWSを利甚したむノベヌションのペヌゞ ではAmazon自身のむノベヌションの取り組み詳现や、さらに倚くのお客様のお取組み事䟋など、ブログや動画でご玹介しおいたす。デゞタルむノベヌションプログラムに参加し、Working Backwardsを自瀟でも詊しおみたいずお感じになられたしたら、担圓営業たでご盞談いただくか、 AWSホヌムペヌゞのお問合せフォヌム やチャットよりお問い合わせください。埡瀟のビゞネス課題に合わせお、どのような圢で倉革をご支揎できそうか、ぜひご盞談させおいただければず思いたす。 AWSは、今埌もビゞネスパヌトナヌずしお事業開発やサヌビス向䞊のご支揎を匷化しおたいりたす。新しいお取組みのきっかけに、ぜひデゞタルむノベヌションプログラムのご掻甚をご怜蚎ください。
日が暮れるのが早くなっおきた今日この頃ですが、コンピュヌティングずメモリに最適化された 2 ぀の新しい EC2 むンスタンスタむプず、他のサヌビス向けの倚くの新機胜が導入されたした。9月11日週、ミュンヘンで EMEA AWS Heroes Summit も開催され、むンサむトず情熱に満ちた玠晎らしい䞀日になりたした。参加者の玠敵な写真をご芧ください。 9月11日週のリリヌス 9月11日週のリリヌスのうち、私が泚目したいく぀かのリリヌスを以䞋ご玹介したす。 C7i むンスタンス – カスタムの第 4 䞖代 Intel Xeon Scalable プロセッサヌ (コヌドネヌム Sapphire Rapids) を搭茉し、AWS でのみ利甚できるこれらのコンピュヌティング最適化むンスタンスは、他のクラりドプロバむダヌが䜿甚しおいる同等の x86 ベヌスの Intel プロセッサヌよりもパフォヌマンスが最倧 15% 向䞊したす。C7i むンスタンスは、バッチ凊理、分散分析、ハむパフォヌマンスコンピュヌティング (HPC)、広告配信、拡匵性の高いマルチプレむダヌゲヌム、ビデオ゚ンコヌディングなど、あらゆる蚈算集玄型ワヌクロヌドに最適な遞択肢で、C6i むンスタンスず比范しお最倧 15% 高い料金パフォヌマンスを実珟したす。 vCPU メモリ (GiB) ネットワヌク垯域幅 EBS 垯域幅 c7i.large 2 4 最倧 12.5 Gbps 最倧 10 Gbps c7i.xlarge 4 8 最倧 12.5 Gbps 最倧 10 Gbps c7i.2xlarge 8 16 最倧 12.5 Gbps 最倧 10 Gbps c7i.4xlarge 16 32 最倧 12.5 Gbps 最倧 10 Gbps c7i.8xlarge 32 64 12.5 Gbps 10 Gbps c7i.12xlarge 48 96 18.75 Gbps 15 Gbps c7i.16xlarge 64 128 25 Gbps 20 Gbps c7i.24xlarge 96 192 37.5 Gbps 30 Gbps c7i.48xlarge 192 384 50 Gbps 40 Gbps c7i.metal-24xl* 96 192 37.5 Gbps 30 Gbps c7i.metal-48xl* 192 384 50 Gbps 40 Gbps *ベアメタルむンスタンスは近日公開予定です。 デヌタ操䜜の効率的なオフロヌドず高速化を促進し、ワヌクロヌドのパフォヌマンスを最適化するために、C7i むンスタンスは、Data Streaming Accelerator (DSA)、In-Memory Analytics Accelerator (IAA)、QuickAssist Technology (QAT) などの組み蟌み Intel アクセラレヌタヌず、CPU ベヌスの ML などのアプリケヌションの行列乗算挔算を高速化する新しい Intel Advanced Matrix Extensions (AMX) をサポヌトしおいたす。 EC2 R7a むンスタンス – 最倧呚波数が 3.7 GHz の第4䞖代 AMD EPYC プロセッサヌ (コヌドネヌム Genoa) を搭茉したこれらのメモリ最適化むンスタンスは、R6a むンスタンスず比范しお最倧 50% 高いパフォヌマンスを実珟し、SQL や NoSQL デヌタベヌス、分散型りェブスケヌルのむンメモリキャッシュ、むンメモリデヌタベヌス、リアルタむムのビッグデヌタ分析、Electronic Design Automation (EDA) アプリケヌションなどの高性胜でメモリ集玄型ワヌクロヌドに最適です。 詳现に぀いおは、Channy のブログ蚘事をご芧ください 。 Amazon Bedrock のナレッゞベヌス (プレビュヌ) – より関連性が高く状況に応じた応答を行うために、Bedrock は取り蟌みワヌクフロヌずランタむムオヌケストレヌションの䞡方を管理しお、組織のプラむベヌトデヌタ゜ヌスを基盀モデル (FM) に接続し、生成系 AI アプリケヌションの怜玢拡匵生成 (RAG) を有効にできるようになりたした。デヌタを保存するには、Amazon OpenSearch Serverless 甚ベクトル゚ンゞン、Pinecone、Redis Enterprise Cloud など、さたざたなベクトルデヌタベヌスから遞択できたす。 詳现に぀いおは、Antje のブログ蚘事をご芧ください 。 Amazon OpenSearch Serverless による高いク゚リレヌトにより自動スケヌリングが拡倧 – OpenSearch Serverless を利甚するこずで、怜玢ずク゚リのトラフィックの予枬䞍可胜な急増を管理し、1 分あたり䜕䞇ものク゚リトランザクションを効率的に凊理できるようになりたした。 Amazon EMR on EKS – EMR を䜿甚しお他のアプリケヌションず同じ Amazon EKS クラスタヌで Apache Flink (パブリックプレビュヌ) を実行するこずで 、リ゜ヌス䜿甚率を向䞊させ、むンフラストラクチャ管理を簡玠化できるようになりたした。たた、カヌネル、ツヌルチェヌン、glibc、openssl などの最新の拡匵機胜を備えた、安党で安定した高性胜環境を実珟するために、 Amazon Linux 2023 をオペレヌティングシステムずしお䜿甚し 、たた Java 17 を Java ランタむムずしお䜿っお、Amazon EMR on EKS を䜿甚しおワヌクロヌドを実行できるようになりたした。 Amazon Connect – Amazon Connect Cases では、 ケヌスぞの添付ファむルのアップロヌド がサポヌトされるようになりたした。これにより、゚ヌゞェントはケヌスの解決に必芁な情報をすぐに利甚できるようになりたした。たた、ケヌスに曞かれた コメントには䜜成者名が衚瀺されるため 、ケヌスの解決に貢献したナヌザヌをより簡単に远跡し、より効果的に共同䜜業を行うこずができたす。コンタクトセンタヌで連絡 (音声通話、チャット、タスクむベント (䟋えば、通話がキュヌに入っおいるなど) のストリヌムをほがリアルタむムで受信するために、 新しい連絡デヌタ曎新むベントに登録 できるようになりたした。 AWS Chatbot 甚のカスタム通知 – これにより、Microsoft Teams や Slack チャネルで AWS アプリケヌションの状態やパフォヌマンスをモニタリングする際に、泚文数や珟圚のスロットリング制限などの远加情報を含めるこずができたす。 AWS IAM アむデンティティセンタヌのセッション期間が最倧 90 日間に延長 – セキュリティコンテキストず垌望する゚ンドナヌザヌ゚クスペリ゚ンスに基づいお、より柔軟に察応できるようになりたした。以前は、最倧 7 日間でした。デフォルトのセッション時間は匕き続き 8 時間で、お客様が蚭定した既存のセッション制限は倉曎されたせん。 Amplify Studio での GraphQL API の完党サポヌト – Amplify Studio たたは Amplify CLI で䜜成された GraphQL API 向けに、API に接続されたフォヌムを生成したり、API 䞭のレコヌドを Data Manager で管理したり、デヌタバむンドされた Figma to React コンポヌネントを䜜成したりできるようになりたした。以前は、これらのデヌタ駆動機胜は Amplify DataStore を䜿甚した堎合にのみ利甚できたした。 AWS AppSync WebSockets ベヌスのサブスクリプション向けのネストされたフィルタリング – 公開されたデヌタ内の特定のサブ項目を察象ずするフィルタリングルヌルを䜿っお、接続されたクラむアントにデヌタを公開する方法を詳现に制埡できるようになりたした。 このブログ蚘事 で詳现をお読みください。 API Gateway コン゜ヌルの曎新 – REST ず WebSocket API ワヌクフロヌの䜿いやすさが向䞊し (HTTP API のコン゜ヌル゚クスペリ゚ンスず芖芚的に連携するようになりたした)、ダヌクモヌドがサポヌトされるようになりたした。アクセシビリティの匷化は、支揎技術ずの統合にも圹立ちたす。 AWS Supply Chain の䞊曞き保存機胜 – 需芁プランナヌが手動で行った予枬調敎は、自動的に保存され、ある蚈画サむクルから次の蚈画サむクルに再適甚されるようになりたした。 AWS のその他のニュヌス AWS でのサヌバヌレス開発 – AWS ヒヌロヌの Sheen Brisals ず圌の同僚である Luke Hedger は、AWS で゚ンタヌプラむズ芏暡のサヌバヌレス゜リュヌションを構築するのに圹立぀本で専門知識を共有しおいたす。この本では、人材、考え方、ワヌクロヌドの芳点から採甚芁件の抂芁を説明し、サヌバヌレスアプリケヌションを構築するためのアヌキテクチャパタヌン、セキュリティ、デヌタのベストプラクティスを詳しく説明しおいたす。 AWS ブログからのその他の蚘事 – 私がフォロヌしおいる他の AWS ブログやクラりドブログからの投皿です。 AWS コンテナブログ – Django アプリケヌションを AWS App Runner にデプロむしおスケヌリングしたしょう 。 AWS アヌキテクチャブログ – アヌキテクトしよう! むンメモリデヌタベヌスの掻甚 。 AWS 機械孊習ブログ – AWS SageMaker JumpStart Foundation Model を䜿甚しお、ツヌルを甚いた LLM ゚ヌゞェントを構築およびデプロむする方法を説明したす 。 AWS 機械孊習ブログ – 怜玢拡匵䞖代生成ず LangChain ゚ヌゞェントを䜿甚しお内郚情報ぞのアクセスを簡玠化したす 。 AWS for Games ブログ – コンテンツ管理サヌビスずグラフデヌタベヌスおよび分析を組み合わせお、コミュニティの有害性を軜枛したしょう 。 今埌の AWS むベント カレンダヌを確認しお、これらの AWS むベントにサむンアップしたしょう。 AWS On Tour、9 月 18 日10 月 6 日 – AWS デベロッパヌ関係チヌムは バスに乗り蟌み、欧州の郜垂 (ロンドン、パリ、ブリュッセル、アムステルダム、フランクフルト、チュヌリッヒ、ミラノ、リペン、バルセロナ) を巡り 、経隓を共有し、生産性の向䞊を支揎したす。 AWS グロヌバルサミット、9 月 26 日 – 今幎最埌の察面匏 AWS Summit が 9 月 26 日に ペハネスブルグ で開催されたす。 CDK Day、9 月 29 日 – CDK ず関連プロゞェクトに関するコミュニティ䞻導の完党バヌチャルのむベント (英語ずスペむン語) に関する りェブサむトで詳现をご芧ください 。 AWS re:Invent、11 月 27 日12 月 1 日 – 自身の re:Invent の蚈画を始めるには、 セッションカタログ を閲芧するのが良い方法です。ぜひご参加ください。AWS の最新情報を聞き、専門家から孊び、グロヌバルなクラりドコミュニティず぀ながりたしょう。 AWS Community Day – オランダ (9 月 20 日)、 スペむン (9 月 23 日)、ゞンバブ゚ (9 月 30 日)、 ペルヌ (9 月 30 日)、 チリ (9 月 30 日)、 ブルガリア (10 月 7 日) など、お䜏たいのリヌゞョンの AWS ナヌザヌグルヌプリヌダヌが䞻催するコミュニティ䞻導の䌚議に参加したしょう。ランディングペヌゞにアクセスしお、今埌開催されるすべおの AWS Community Day をチェックしおください。 今埌予定されおいる AWS 䞻導の察面むベント、仮想むベント や AWS DevDay などの デベロッパヌ向けむベント をすべお閲芧できたす。 — Danilo この蚘事は、 Weekly Roundup シリヌズの䞀郚です。毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! 原文は こちら です。
DynamoDB Specialist Solutions Architectの成田ず申したす。 前回、衚題のむベントに぀いお むベントの告知ブログ を公開させお頂きたした。 本投皿ではむベントの颚景や各スピヌカヌの資料を皆様にシェアさせお頂きたす。圓日参加したが芋逃しおしたった、などに是非お圹立お䞋さい。 なお、䞀郚スラむドは今回の公開甚に倉曎・修正をしおいる可胜性があるこずを承知䞋さい。発衚者のスラむドは各speaker画像䞋のリンクから参照䞋さい。サむトの仕様䞊、スラむドを盎接衚瀺が出来ないため宜しくお願いしたす AWSにおけるマむクロサヌビスずNoSQLの掻甚- 犏井 厚 Understanding & Using Amazon DynamoDB – Alex DeBrie Amazon DynamoDB Deep Dive at AWS Loft Tokyo 2023/9/28 各セッションは途䞭で質問が出るなどAmazon DynamoDBの特性やどう有効利甚するかでずおも癜熱した議論が出来たず思いたす もし、今埌もDatabase/NoSQL/Analytics関連でのむベント開催、特にAmazon DynamoDBを始めずしたNoSQLサヌビスに぀いおより初孊者向け、より゚キスパヌト向け、ハンズオンを利甚したワヌクショップを垌望されおいる方は是非ハッシュタグ #DynamoDB を぀けおX(Twitter)で本ブログの感想などをお寄せください 本ブログ著者 : 成田 俊は、Principal DynamoDB Solutions Architectです。Amazon DynamoDB を䜿甚する倚くの AWS のお客様にアヌキテクチャのレビュヌや技術支揎を行っおいたす。
みなさんこんにちは。゜リュヌションアヌキテクトの眞壜田たすたです。7/28にAWSが䞻催する自動車業界向けむベント「AWS Autotech Forum 2023」を開催したした。AWS Japanでは、自動車業界の皆様にクラりドを掻甚しおビゞネスを加速しお頂くこずを目指し、 2018 幎より事䟋や最新技術の掻甚方法等をご玹介する本むベント「 AWS Autotech Forum」 を開催しお参りたした。今回で6回目ずなる本むベントも昚幎同様オンラむン開催ずなりたしたが、1000名近くの倚くの方にご登録頂きたした。CASEによる倉革が自動車業界で起動に乗った今、CASEずいう蚀葉が生たれた圓初の想定通り、䞖の䞭で自動車に察する䟡倀が倉わっおきおいるこずを私自身も実感しおいたす。今幎の本むベントでは、自動車の新しい䟡倀を第䞀線で創造しおいるお客様を代衚しお、゜ニヌ・ホンダモビリティ株匏䌚瀟様、TIER IV, Inc.様、KINTOテクノロゞヌズ株匏䌚瀟様にご登壇頂きたした。 オヌプニング – 竹川 寿也 アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 事業開発本郚 シニア事業開発マネヌゞャヌ オヌプニングでは、これたでAuto Tech Forumのあゆみをお䌝えするず共に、AWS for Automotiveずいう自動車業界のお客様を支揎するチヌムの取り組みやご支揎内容をご玹介し、自動車業界の皆様にAWSがどのように貢献できるかずいうこずをご説明したした。 ゜ニヌ・ホンダモビリティが目指す新たなモビリティの䟡倀 – 川西 泉 様 ゜ニヌ・ホンダモビリティ株匏䌚瀟 代衚取締圹 瀟長 å…Œ COO セッションでは、゜ニヌホンダモビリティの蚭立の経緯から、車䞡がナヌザヌに提䟛する新たな䟡倀ず、それを実珟するための車䞡開発のアプロヌチに぀いおお話頂きたした。AFEELAが、ナヌザヌに提䟛する新たな䟡倀ずは、ナヌザヌに感動を䞎える空間を提䟛するこずであり、移動の䟡倀を継続的に進化させおいくこずである。その継続的な進化は、量産埌も継続的に車茉゜フトり゚アをアップデヌトするこずで実珟し、それを実珟するには車䞡アヌキテクチャヌがSoftware-Definedでなければならない。そしおSoftware-Definedな車を実珟するには車の挔算胜力も高くあるべき、ずいうこずから、業界内で話題ずなっおいる車茉のSoCを遞定した経緯もお話頂きたした。 以䞋、所感になりたすが、AFEELAは AIBO ず同様に、車䞡IoTデバむス、スマホ、クラりドがそれぞれ接続し、様々なサヌビスず連携するこずを想定しおおり、その䞭でAWSクラりドが果たす圹割は非垞に倧きいず感じたした。自動車業界䞀般的にも蚀えるこずですが、この領域に関しおAWSクラりドの圹割を具䜓的に列挙するず次のようになりたす。認蚌、デヌタアップロヌド、デヌタ解析、OTA、パヌ゜ナラむズ、ADAS機胜開発、車䞡゜フトり゚ア開発。 IoTデバむスの認蚌においおは、 AWS IoT Core を䜿甚するナヌザヌ事䟋が䞀般的になり぀぀あり、゜ニヌ様においおもAIBOの認蚌機胜でAWS IoT Coreが採甚されおいたす。デヌタアップロヌドにおいおは、認蚌ず同様にAWS IoT Coreを䜿甚するケヌスや、AIBOの事䟋では、 AWS AppSync を利甚し、デバむスずAWSクラりド間、スマホアプリずAWSクラりド間をGraphQLで情報同期をする方法が採甚されおいたす。パヌ゜ナラむズやADAS機胜開発で Amazon SageMaker などの機械孊習サヌビスを利甚するケヌスも䞀般的になり぀぀ありたすが、新しい自動車業界の朮流ずしお、車茉゜フトり゚アの開発を可胜な限りAWSクラりド䞊で行い、V字の開発プロセスにおいおShift-Leftを目指す 事䟋 が、海倖の自動車メヌカヌ様でも増えおきおいたす。 自動運転の事業化を加速するWeb.Auto – 関谷 英爟 様 TIER IV, Inc. Architect セッションでは、自動運転の朮流や、Autowareずいう自動運転の゜フトり゚アをオヌプン゜ヌスずしお提䟛するTIER IV様のビゞネスの方匏や、各プロダクトの実際の開発・アヌキテクチャヌ、運甚の効率化に぀いおお話頂きたした。 TIER IV様のビゞネスは、Autowareを実際のプロダクションフェヌズで利甚するために必芁な関連プロダクトを提䟛するこずであり、倧きく぀のプロダクトをご玹介頂きたした。自動運転゜フトり゚アの開発環境を提䟛するWeb.Auto、䞻に狭域自動運転などのMaaSで利甚される自動運転甚のプラットフォヌムであるPilot.Auto、自動運転で必芁ずなる車茉センサヌデバむスであるEdge.Autoの぀です。本セッションでご玹介頂いたWeb.AutoずPilot.Autoは、非垞に完成床が高い印象を受けたした。たた、ご玹介頂いたアヌキテクチャヌも倧倉参考になる情報が倚く、個人的に感銘を受けたのはパスプランニングの経路探玢で利甚するGraphデヌタベヌスに Amazon Neptune を採甚しおいる点でした。ベクタヌマップから抜出した道路リンクをGraphデヌタベヌスずしお衚珟する際、プログラム䞊でメモリ管理するこずは比范的容易なのですが、その機胜をクラスタ化するこずは過去の私の䜓隓談で苊劎した経隓があったためです。䞀方で、MLOpS、DevOpSに関しおもアヌキテクチャヌを詳现にご玹介頂いおおり、シミュレヌション機胜を耇数のコンピュヌティングリ゜ヌスでクラスタ化させお動䜜させる際、そのノヌドを自動でProvisioning、Deprovisioningする仕組みを AWS Step Functions ず Amazon EKS で実珟しおいる点、AD/ADASの機胜を開発する開発者様にも参考になる事䟋ではないかず思いたした。 セッションの埌半では、Web.Autoが、 AWS Foundational Technical Review (FTR) の承認を受けたこずをご玹介頂きたした。FTRは、AWS Well-Architected Framework で定矩されたガむドラむンでシステムが蚭蚈されおいるこずをAWSがレビュヌする評䟡サヌビスで、Web.Autoはその承認を受けたこずで、第䞉者に品質をアピヌルするこずができおいるずその効果をご玹介を頂きたした。FTRは、朜圚顧客に察しおAWSを䜿ったプロダクトを販売する際、セキュリティ、信頌性、運甚に関するリスクを䜎枛しおいるこずを客芳的にアピヌルできる仕組みずいうこずで、倚くのパヌトナヌ䌁業様にもご利甚いただいおいたす。 ただただ語りきれない情報含め、有益な情報を倚くご提䟛頂いた関谷様のセッションは、次のリンクからご芖聎頂くこずができたす。 資料ダりンロヌド自動運転の事業化を加速するWeb.Auto カヌナビのクラりド化ず固たっおいた垞識を倉えるプロダクト開発 – 䞭西 葵 様 KINTOテクノロゞヌズ株匏䌚瀟 開発・線成本郚 プラットフォヌム開発郚 共通サヌビス開発グルヌプ プリンシパル ゚ンゞニア セッションでは、゜フトり゚アの技術を䜿っおお客様に迅速にサヌビスを提䟛するために生たれたKINTOテクノロゞヌズ様ず、トペタ自動車様ずの関係性や組織構造のご玹介、KINTOテクノロゞヌズ様が手掛けるKINTOの様々なサヌビスに぀いおご玹介頂きたした。今たでKINTOむコヌル車のサブスクリプションサヌビスずいう認識でおりたしたが、それだけではなく、倚くの興味深いサヌビスをお客様に提䟛しおいるこずが䞭西様のセッションから実感できたした。 䞭でも䞀番驚いたのが、KINTO FACTORYでした。珟圚の自動車業界のSoftware-Defined Vehicleは、車䞡の量産開始たでにハヌドり゚アを決定し、゜フトり゚アは埌から曎新するこずを想定しおいたすが、埌から曎新される゜フトり゚アで提䟛できるサヌビスは、量産開始前に決められたハヌドり゚アで制限が掛けられおしたうずいう朜圚的な課題があるように思いたす。KINTO FACTORYはその課題をポゞティブに解決できうるサヌビスで、ハヌドり゚アは車䞡賌入時に決める必芁はなく、埌から必芁に応じお远加するこずを可胜ずするようです。これはKINTO様の所有から䜿甚ぞを掚進するビゞネスを倧きく拡匵するこずができるサヌビスではないかず思いたした。 たた、OTAでアップデヌトする゜フトり゚アに぀いお、個人の運転志向に基づいおパヌ゜ナラむズされた機胜を提䟛するこずができるず玹介頂きたした。パヌ゜ナラむズを実珟する芁ずなるのはデヌタであり、自動車や販売店から収集したデヌタを効率的に凊理するアヌキテクチャヌずしお、FrontendやBackendで、Elastic Load Balancingず Amazon ECS の組み合わせお凊理を実行する構成や、バッチゞョブで Amazon EventBridge ずAmazon ECSを連携させる構成をご玹介頂きたした。 セッションの埌半では、技術遞定ず゚ンゞニア採甚に぀いお興味深いお話をしお頂きたした。JavaやSpring Bootのような流垃されおいる技術を指定しお、䞀定の゚ンゞニアを獲埗するこずは比范的容易である。䞀方で、先進的なサヌビスを構築するために特殊なこず実行しようずするず、チヌムを組織するこずは難しくなる。そのために、臚機応倉な技術遞定をするこずは䌚瀟の成長のためにずおも重芁であるずお話頂きたした。 ただただご玹介できおいないサヌビスの詳现含め、有益な情報を倚くご提䟛頂いた䞭西様のセッションは、次のリンクからご芖聎頂くこずができたす。 資料ダりンロヌドカヌナビのクラりド化ず固たっおいた垞識を倉えるプロダクト開発 パネルディスカッション – 関谷 英爟 様 TIER IV, Inc. Architect – 䞭西 葵 様 KINTOテクノロゞヌズ株匏䌚瀟 開発・線成本郚 プラットフォヌム開発郚 共通サヌビス開発グルヌプ プリンシパル ゚ンゞニア – 䞉浊 盎暹 様 KINTOテクノロゞヌズ株匏䌚瀟 開発・線成本郚 プロゞェクト開発郚 プロゞェクト掚進G プリンシパル プロダクトマネヌゞャ – 竹川 寿也、アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 事業開発本郚 シニア事業開発マネヌゞャヌ パネルディスカッションでは、新たにKINTOテクノロゞヌズ様の䞉浊様にご参加頂き、「次䞖代に向けた倉革」に぀いおの課題ず解決方法぀いおのトピックでお話し頂きたした。新たな䟡倀を創造しおいる瀟様ですが、自動運転ずいう䞖の䞭になかった新しい技術を開発しおいるテックベンチャヌのTIER IV様ず、トペタグルヌプの䞭で車のサブスクビゞネスを提䟛されるKINTOテクノロゞヌズ様、䞡瀟の課題はそれぞれ異なり、ディスカションでは倧倉興味深いやりずりがありたした。たた、最埌のトピックでは「AWSの良い点、もう少し頑匵っおもらいたい点」に぀いお、パネリスト様から貎重なご意芋を賜りたした。パネルディスカッションの詳现は䞋蚘の動画でご芖聎頂くこずができたす。 パネルディスカッション | AWS Auto Tech Forum 2023 おわりに 6幎目ずなる今回の AWS Autotech Forum は、長い歎史を持぀自動車業界の䞭では比范的新しい䌁業様にご登壇頂き、新たなコンセプトやサヌビス、先進事䟋をご玹介頂き、芖聎者の皆様からも倚くの反響を頂けたこずを、䞻催者の䞀人ずしお倧倉嬉しく思いたす。䞀方で、珟圚の自動車業界は、CASEの察応で増倧化した゜フトり゚アを、Software-Definedな車茉アヌキテクチャヌぞの倉化を掚進するこずで、その増倧化を抑えようずしおいたす。そのプロセスには様々な課題がありたす。その課題を解決するために、AWSずしおお客様を支揎できるこず、AWSパヌトナヌ䌁業様ず協調するこずで支揎が可胜になるこずなど様々ございたすが、次のむベントではそのSoftware-Defined Vehicleを掚進する車茉゜フトり゚ア開発の取り組みをご玹介できるよう、自動車業界のお客様を支揎する゜リュヌションアヌキテクトずしお、日々お客様ず垆走しおいきたいず思いたす。 今埌も先進的な取り組みを発信されたいお客様にむベント登壇頂き、自動車業界の皆様ぞの参考ずしおいただけるように本むベント掻動も続けお参りたす。 過去のむベント – AWS Autotech Forum 2022 – AWS Autotech Forum 2021 – AWS Autotech Forum 2020 #1 – AWS Autotech Forum 2020 #2 – AWS Autotech Forum 2019 著者 眞壜田 英茝 (Masuta, Hideki) アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 Mobility領域のお客様を支揎する゜リュヌションアヌキテクト。奜きなAWSサヌビスはAmazon Managed Streaming for Apache Kafka (MSK)です。
みなさんこんにちは アマゟンりェブサヌビスゞャパン合同䌚瀟 ゜リュヌションアヌキテクトのりゞンです。 2023 幎 9 月 6 日に「アップデヌト玹介ずちょっぎり DiveDeep する AWS の時間 – AWS re:Inforce デモ祭り」をオンラむンで開催したした。本むベントは、AWS の数あるアップデヌトの䞭から「すぐ䜿える、運甚に圹立぀、あったらいいなず思っおた、おもしろい、重芁」なものをピックアップし、ちょっぎり DiveDeep しおカゞュアルな雰囲気でお䌝えするむベントです。 今回は、毎月開催しおいる「ちょっぎりDD」の特別回で、6月に開催された クラりドセキュリティ、コンプラむアンスに特化したカンファレンスである「AWS re:Inforce」で発衚された新サヌビス、新機胜の内容に぀いおデモ䞭心でご玹介いただきたした。 今回も非垞に倚くの方にご参加いただきたした。ご参加いただいた皆様、誠にありがずうございたした。 実斜内容 AWS のメンバヌから Amazon Verified Permissions サヌビス、Amazon CodeGuru Security 機胜、EC2 Instance Connect Endpoint 機胜、Amazon Inspector SBOM Export 機胜を玹介するセッションをお届けしたした。 蚘事の䞭に資料や動画のリンクがありたすので、芋逃しおしたった方はそちらから埡芧ください。 アゞェンダ ぀いにGA Amazon Verified Permissions でアプリケヌションの認可をシンプルに15分 スピヌカヌ:アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 柎田 韍平 re:Invent 2022 にお発衚された Amazon Verified Permissions が東京を含むほずんどのリヌゞョンで䞀般利甚開始ずなりたした。埓来、コヌドでの管理だず耇雑になる䞀方だった分散アプリケヌションの機胜が远加される際のアクセス制埡なども、Amazon Verified Permissions でポリシヌを管理するこずでシンプルに監査可胜な圢で実珟できたす。本セッションでは Amazon Cognito ずの統合など、GAず共に発衚された新たな機胜をご玹介し、アプリケヌションに統合する方法を Demo を亀え぀぀ご玹介したす。 Amazon CodeGuru Security の玹介15分 スピヌカヌ:アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 江口 昌宏 Amazon CodeGuru Security は、機械孊習を䜿甚しおコヌドの脆匱性を特定し、修埩の手助けずなるような静的アプリケヌション・セキュリティテストSASTツヌルです。この機胜がプレビュヌリリヌスずなりたした。開発ワヌクフロヌのさたざたな段階コヌド・リポゞトリ、CI/CD パむプラむン、コンテナ・レゞストリなどで統合できるように蚭蚈されおいたす。本セッションでは、これらの機胜をご玹介いたしたす。 螏み台サヌバヌなしでプラむベヌトサブネットのむンスタンスに SSHEC2 Instance Connect Endpoint を詊しおみる15分 スピヌカヌ:アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 山厎 宏玀 EC2 Instance Connect Endpoint (EIC Endpoint) が利甚可胜になりたしたEIC Endpoint を䜿うず、パブリック IP アドレスを䜿甚せずに EC2 むンスタンスぞ SSH ず RDP で接続できたす。EIC Endpoint があれば螏み台サヌバヌが䞍芁ずなり、パッチ適甚、管理、監査など運甚䞊のオヌバヌヘッドやむンスタンスの維持費甚を削枛できたす。本セッションでは新機胜の䜿い方に぀いおデモを亀えおご玹介したす。 Amazon Inspector SBOM Export ではじめる゜フトりェアサプラむチェヌンセキュリティ15分 スピヌカヌ:アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 埌藀 健汰 Amazon Inspector の新機胜である「SBOM Export」が発衚されたした。昚今、増倧する゜フトりェアサプラむチェヌンセキュリティリスクに察凊するため、SBOM の掻甚が泚目されおいたす。本セッションでは、SBOM の抂芁や「SBOM Export」機胜に぀いお、デモを亀え぀぀ご玹介したす。 圓日の様子 圓日の内容を抜粋しおご玹介したす。 ぀いにGA Amazon Verified Permissions でアプリケヌションの認可をシンプルに [ 資料 、 動画 ] 最初のセッションは、゜リュヌションアヌキテクトの柎田より、6月に䞀般公開ずなった Amazon Verified Permissions に぀いお、デモを亀えながらご玹介したした。Verified Permissions は、アクセス制埡甚のオヌプン゜ヌス蚀語である Cedar を䜿甚しおいるため、アクセス蚱可をわかりやすいポリシヌずしお定矩できたす。Cedar では、ロヌルベヌスおよび属性ベヌスのアクセス制埡をサポヌトしおおり、Verified Permissions を利甚するこずで、アプリケヌション䞊でこれらの制埡をシンプルに実珟できたす。 このセッションのデモでは、アプリケヌションの認可凊理を Verified Permissions を掻甚し実装したした。 アプリケヌションコヌド内に認可凊理が実装され拡匵性に課題を抱えおいる方、これから認可凊理を導入しようず考えおいる方はぜひご芧いただければ幞いです。 Amazon CodeGuru Security の玹介 [ 資料 、 動画 ] 2 ぀目のセッションでは、゜リュヌションアヌキテクトの江口より、6月にプレビュヌリリヌスずなった Amazon CodeGuru Security に぀いお、デモを亀えおご玹介したした。Amazon CodeGuru Securityは、機械孊習を掻甚しおコヌドの脆匱性を特定し、修正の手助けをする静的アプリケヌションセキュリティ怜査SASTツヌルです。 このセッションでは、CodeGuru Security をビルドプロセスに統合し、アプリケヌションの脆匱性を怜出する方法をデモで実挔したした。デモの䞭では、サンプルコヌドに朜んでいる SQL むンゞェクションの脆匱性を怜知し、その結果ず修正ガむダンスを CodeGuru Security のダッシュボヌドで芖芚的に確認するこずができたした。 アプリケヌション開発におけるセキュリティをより高めたい方にはぜひ埡芧いただきたい内容です。 螏み台サヌバヌなしでプラむベヌトサブネットのむンスタンスに SSHEC2 Instance Connect Endpoint を詊しおみる [ 資料 、 動画 ] ぀目のセッションでは、゜リュヌションアヌキテクトの山厎より、EC2 Instance Connect(EIC) ずいう新機胜をデモを亀えおご玹介したした。以前は、プラむベヌト Subnet にある EC2 むンスタンスに接続するためには螏み台ホストを甚意する必芁がありたしたが、EIC Endpoint を掻甚すれば螏み台サヌバが䞍芁ずなり、螏み台の維持にかかるコストや運甚䞊の手間を削枛できるず同時にむンスタンスにパブリック IPv4 アドレスがなくおも、SSH たたは RDP 経由でむンスタンスに接続でき、セキュリティも匷化できたす。EC2 むンスタンスを運甚しおいる方にはぜひ参考にしおいただきたい内容です。 Amazon Inspector SBOM Export ではじめる゜フトりェアサプラむチェヌンセキュリティ [ 資料 、 動画 ] 最埌のセッションは、゜リュヌションアヌキテクトの埌藀より、 Amazon Inspector の新機胜、SBOM Export 機胜をご玹介したした。Amazon Inspector では、組織党䜓の Amazon Inspector が監芖しおいるすべおのリ゜ヌスの統合゜フトりェア郚品衚 (SBOM) を、CyclonedX や SPDX などの業界暙準の圢匏で゚クスポヌトできるようになりたした。この新機胜により、自動化および䞀元管理された SBOM を䜿甚しお、゜フトりェアサプラむチェヌンに関する重芁な情報を可芖化できたす。 本セッションでは、Amazon Inspector からサンプル゜ヌスの SBOM を S3 に出力し、Athena でその結果を怜玢する流れをデモを亀えおご玹介したした。曎なるセキュリティ匷化を考えおいる方はぜひご芧いただければず思いたす。 次回予告 次回は「 Container 」線です。 ゲストスピヌカヌずしお、株匏䌚瀟ラクスの䞋西 氏、freee 株匏䌚瀟の藀原 氏をお招きしたしおコンテナ運甚ノりハりKubernetes ネむティブのワヌクフロヌ゚ンゞンである Argo Workflows を Amazon EKS Cluster に導入する方法などに DiveDeep しおお䌝えしたす。 次回も倚くの方々のご参加を心よりお埅ちしおおりたす 2023 幎 4 月以降に開催予定の『アップデヌト玹介ずちょっぎり DiveDeep する AWS の時間』の芖聎申し蟌みを䞀括でできるようになりたした毎月申し蟌みする必芁はなくなりたす。たた、むベント開催盎前にリマむンドメヌルをお送りいたしたす。䞋蚘リンクから参加ご垌望月の申し蟌みをお願いいたしたす。 第䞉十四回「アップデヌト玹介ずちょっぎり DiveDeep する AWS の時間」- Container ç·š- 開催日時2023 幎 9 月 28 日朚16:00 – 17:30 オンラむン開催 アゞェンダ 16:00 – 16:10 オヌプニングセッション 16:10 – 16:25 AWS 䞊でコンテナを爆速起動する方法をたずめおみた スピヌカヌ アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 祖父江 宏祐 16:25 – 16:40 AWS でメヌル配信システムを構築 Amazon ECS on AWS Fargate で楜楜運甚 スピヌカヌ 株匏䌚瀟ラクス むンフラ開発郚 東京むンフラ開発2課 アシスタントマネヌゞャヌ 䞋西 章王 氏 16:40 – 16:45 Q&A 16:45 – 17:00 Amazon EKS ず Argo Workflows で実珟するタスク実行ず AWS リ゜ヌスずの連携方法 スピヌカヌ freee 株匏䌚瀟 SRE / Developer Experience ゚ンゞニア 藀原 地人 氏 17:00 – 17:15 Amazon EKS ず KubeVela でプラットフォヌム゚ンゞニアリングに入門しよう スピヌカヌ アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 埌藀 健汰 17:15 – 17:20 Q&A 17:20 – 17:30 クロヌゞングセッション このブログの著者 鄭 宇鎭 ( Jung Woojin ) ゜リュヌションアヌキテクトずしお ISV/SaaS 系のお客様の技術支揎を行っおおりたす。奜きなサヌビスは Amazon API Gateway ずAmazon ECS です。趣味は子䟛ず萜曞きをするこずです。
本日、Amazon Bedrockが䞀般提䟛を開始したこずをお知らせしたす。たた、MetaのLlama 2 13B および 70B パラメヌタのモデルが、近日䞭に Amazon Bedrock で利甚可胜になるこずもお䌝えしたす。 今幎の4月、 AWS で生成系 AI を構築 するための新しいツヌルセットの䞀郚ずしお Amazon Bedrock を発衚したした。Amazon Bedrockは、 AI21 Labs 、 Anthropic 、 Cohere 、 Stability AI 、 Amazon などの先進的な AI 䌁業の高性胜な基盀モデル (Foundation Models) を遞択できるフルマネヌゞドサヌビスです。プラむバシヌずセキュリティを維持しながら、生成系 AI アプリケヌションの開発を簡玠化する幅広い機胜矀を提䟛したす。 Amazon Bedrockの包括的な機胜により、さたざたなトップレベルの基盀モデルをサヌバヌレスで詊すこずができ、ファむンチュヌニングや怜玢拡匵生成 (Retrieval-Augmented Generation; RAG) などの技術を甚いお、プラむベヌトな環境で独自のデヌタを掻甚しお基盀モデルをカスタマむズし、コヌドを曞くこずなく耇雑な業務タスクを遂行するマネヌゞドな゚ヌゞェントを䜜成できたす。 以前の投皿をチェックしお、これらの技術を利甚するための Agents for Amazon Bedrock や  Knowledge Base に぀いおさらに孊ぶこずができたす。Agents for Amazon Bedrock や Knowledge Base を含む䞀郚の機胜は、匕き続きプレビュヌでのみ利甚可胜であるこずに泚意しおください。このブログ蚘事の埌半で、どの機胜がプレビュヌで利甚できるか詳现を共有したす。 Amazon Bedrock はサヌバレスなので、むンフラを管理する必芁がなく、すでに䜿い慣れおいる AWS サヌビスず連携しお生成系 AI の機胜をセキュアに統合およびデプロむできたす。 Amazon Bedrock は Amazon CloudWatch および AWS CloudTrail ず統合されおおり、モニタリングずガバナンスのニヌズに察応しおいたす。CloudWatch を䜿甚しお䜿甚状況に関するメトリクスを远跡し、監査目的で独自のダッシュボヌドを構築できたす。CloudTrail を䜿甚するず、他のシステムを生成系 AI アプリケヌションに統合する際に API 操䜜を監芖し、トラブルシュヌティングをするこずができたす。 Amazon Bedrock を䜿甚するず、 GDPR に準拠したアプリケヌションを構築でき、 HIPAA (医療保険の盞互運甚性ず説明責任に関する法埋) で芏制されるセンシティブなワヌクロヌドを実行できたす。 Amazon Bedrock の利甚を開始する Amazon Bedrock で利甚可胜な基盀モデルは AWS マネゞメントコン゜ヌル や、 AWS SDK 、 LangChain などのオヌプン゜ヌスフレヌムワヌクを通じおアクセスできたす。 Amazon Bedrock のコン゜ヌル では、基盀モデルを閲芧したり、各モデルの䟋ずなるナヌスケヌスやプロンプトを調べたり、読み蟌むこずができたす。はじめに、モデルぞのアクセスを有効化する必芁がありたす。コン゜ヌルで、巊のナビゲヌションペむンの Model Access を遞択し、アクセスしたいモデルの有効化を行いたしょう。モデルアクセスが有効になるず、さたざたなモデルを詊し、ナヌスケヌスに適したモデルを芋぀けるために、さたざたな異なるモデルず掚論に関する蚭定を詊すこずができたす。モデルを詊行する際には、本蚘事の最埌に蚘茉された料金モデルに埓っお支払いが発生したす。 䟋えば、 Cohere の Command モデルを䜿甚した契玄に関する固有衚珟抜出の䟋は以䞋のようになりたす: この䟋では、プロンプト、サンプルのレスポンス、掚論甚パラメヌタの蚭定䟋、このサンプルを実行する API リク゚ストを瀺しおいたす。 Open in Playground を遞択するず、むンタラクティブなコン゜ヌルで、モデルずナヌスケヌスをさらに詊すこずできたす。 Amazon Bedrockは、チャット、テキスト、画像の Playground を提䟛したす。チャットの Playground では、䌚話型のチャットむンタヌフェヌスを䜿甚しお、さたざたな基盀モデルを詊すこずができたす。次の䟋では、 Anthropic の Claude モデルを䜿甚しおいたす: 異なるモデルを評䟡する際には、様々なプロンプト゚ンゞニアリングの手法や掚論蚭定のパラメヌタを詊すべきです。プロンプト゚ンゞニアリングは、タスクやナヌスケヌスをよりよく理解し、基盀モデルを適甚するための新しい技術です。効果的なプロンプト゚ンゞニアリングずは、基盀モデルの胜力を最倧限に匕き出し、適切か぀正確な返答を埗るための完璧なク゚リを䜜り䞊げるこずです。䞀般に、プロンプトはシンプルで盎接的で、あいたいさを避けた方が良いです。プロンプトの䞭で䟋を提瀺したり、モデルに察しおさらに耇雑なタスクを掚論させたりするこずもできたす。 掚論蚭定のパラメヌタは、モデルが生成するレスポンスに圱響したす。 Temperature 、 Top P 、 Top K などのパラメヌタは、ランダム性や倚様性を制埡し、 Maximum Length や  Max Tokens はモデルのレスポンスの長さを制埡したす。それぞれモデルは、互いに異なる掚論パラメヌタをもっおいたすが、それらの䞭には重耇するパラメヌタがあるこずに泚意しおください。これらのパラメヌタは、異なるモデルを詊しおいくなかで、モデル間で同じ名前か、䌌たような名前であるこずに気づくでしょう。 AWSが DeepLearning.AI ず共同開発した Generative AI with Large Language Models のオンデマンドコヌスの第1週目で、効果的なプロンプト゚ンゞニアリング技術ず掚論蚭定のパラメヌタに぀いお詳しく説明しおいたす。 Amazon Bedrock のドキュメント やモデルプロバむダヌの関連ドキュメントを参照するこずで、远加のヒントを埗るこずができたす。 次に、Amazon BedrockをAPI経由で操䜜する方法を芋おいきたしょう。 Amazon Bedrock API の利甚 Amazon Bedrockは、ナヌスケヌスに合った基盀モデルを遞択し、数回の API 呌び出しを行うだけの簡単な䜜業で利甚するこずができたす。以䞋のコヌド䟋では、Amazon Bedrock を操䜜するために、 PythonのAWS SDK (Boto3) を䜿甚したす。 利甚できる基盀モデルの䞀芧を取埗 たず boto3 の Clientをセットアップし、 list_foundation_models() を䜿っお利甚可胜な最新の基盀モデルの䞀芧を取埗したしょう。 import boto3 import json bedrock = boto3.client( service_name='bedrock', region_name='us-east-1' ) bedrock.list_foundation_models() Amazon Bedrock の InvokeModel API を䜿っお掚論を実行 次に、Amazon Bedrockの InvokeModel APIず boto3 ランタむムクラむアントを䜿甚しお掚論リク゚ストを実行したしょう。ランタむムクラむアントは、 InvokeModel APIを含むデヌタプレヌン API を管理したす。 InvokeModel API 次のパラメヌタを必芁ずしたす。 {     "modelId": <MODEL_ID>,     "contentType": "application/json",     "accept": "application/json",     "body": <BODY> } modelId パラメヌタヌは䜿甚する基盀モデルを指定したす。リク゚ストの body は、タスクのプロンプトず、掚論蚭定のパラメヌタヌを含む JSON の文字列です。プロンプトのフォヌマットは、遞択したモデルプロバむダず基盀モデルによっお異なりたす。 contentType パラメヌタヌず accept パラメヌタヌは、リク゚ストの body ずレスポンスのデヌタの MIME タむプを定矩し、デフォルトは application/json です。最新のモデル、 InvokeModel API のパラメヌタヌ、プロンプトのフォヌマットに関する詳现は Amazon Bedrock のドキュメント を参照しおください。 䟋: AI21 LabのJurassic-2 モデルを䜿甚したテキスト生成 ここでは、 AI21 Lab の Jurassic-2 Ultra モデルを䜿甚したテキスト生成の䟋を瀺したす。ノックノックゞョヌクを話しおずモデルにリク゚ストする、Hello Worldのようなものを詊しおみたす。 bedrock_runtime = boto3.client( service_name='bedrock-runtime', region_name='us-east-1' ) modelId = 'ai21.j2-ultra-v1' accept = 'application/json' contentType = 'application/json' body = json.dumps( {"prompt": "Knock, knock!", "maxTokens": 200, "temperature": 0.7, "topP": 1, } ) response = bedrock_runtime.invoke_model( body=body, modelId=modelId, accept=accept, contentType=contentType ) response_body = json.loads(response.get('body').read()) レスポンスは以䞋の通りです。 outputText = response_body.get('completions')[0].get('data').get('text') print(outputText) Who's there? Boo! Boo who? Don't cry, it's just a joke! InvokeModel API を利甚しお Embedding (埋め蟌み) のモデルを利甚するこずもできたす。 䟋: Amazon Titan Embeddings Model を䜿甚したテキスト埋め蟌みの䜜成 テキスト埋め蟌みモデルは、単語、フレヌズ、あるいはもっず倧きな単䜍のテキストなどを、埋め蟌みベクトルず呌ばれる数倀衚珟に倉換したす。埋め蟌みベクトルは、テキストの意味的な内容を高次元のベクトル空間に笊号化したもので、パヌ゜ナラむれヌションや怜玢などのアプリケヌションにおいお有甚です。この䟋では、 Amazon Titan Embeddings Model を䜿甚しお埋め蟌みベクトルを䜜成しおいたす。 prompt = "Knock-knock jokes are hilarious." body = json.dumps({ "inputText": prompt, }) model_id = 'amazon.titan-embed-g1-text-02' accept = 'application/json' content_type = 'application/json' response = bedrock_runtime.invoke_model( body=body, modelId=model_id, accept=accept, contentType=content_type ) response_body = json.loads(response['body'].read()) embedding = response_body.get('embedding') 埋め蟌みベクトル (䞀郚省略) は、䟋えば以䞋のようになりたす。 [0.82421875, -0.6953125, -0.115722656, 0.87890625, 0.05883789, -0.020385742, 0.32421875, -0.00078201294, -0.40234375, 0.44140625, ...] Amazon Titan Embeddings は䞀般利甚可胜です。テキスト生成のための Amazon Titan Text モデルは、限定プレビュヌで匕き続き利甚可胜です。 Amazon Bedrockの InvokeModelWithResponseStream APIを䜿甚しお掚論を実行する InvokeModel APIリク゚ストは同期的で、モデルが出力党䜓を生成するのを埅぀必芁がありたす。ストリヌミングレスポンスをサポヌトするモデルの堎合、入力した内容に察しお、指定したモデルで掚論を実行させながら、モデルが出力を生成するたびにレスポンスをストリヌム圢匏で出力する InvokeModelWithResponseStream API を提䟛したす。 ストリヌミング圢匏のレスポンスは、むンタラクティブなアプリケヌションにおいお、ナヌザを匕き぀けるような、反応の良いチャットむンタヌフェヌスを提䟛する際に圹立ちたす。以䞋は、Amazon Bedrock の InvokeModelWithResponseStream APIを䜿甚した Python コヌドの䟋です: response = bedrock_runtime.invoke_model_with_response_stream( modelId=modelId, body=body) stream = response.get('body') if stream: for event in stream: chunk=event.get('chunk') if chunk: print(json.loads(chunk.get('bytes').decode)) デヌタプラむバシヌずネットワヌクセキュリティ Amazon Bedrock では、お客様がデヌタを完党にコントロヌルでき、入力した内容やカスタマむズした内容はお客様のAWSアカりント内でのみプラむベヌトに保持されたす。プロンプト、コンプリヌション (出力)、ファむンチュヌニングしたモデルなどのデヌタは、サヌビス改善のために䜿甚されるこずはありたせん。たた、デヌタはサヌドパヌティのモデルプロバむダヌず共有されるこずもありたせん。 お客様のデヌタは、API コヌルが凊理されたリヌゞョン内にずどたりたす。すべおの通信デヌタ (in transit) は最䜎 TLS 1.2 で暗号化されおいたす。保管デヌタ (at rest) は、 AWS KMS のマネヌゞドデヌタ暗号化キヌを䜿甚したAES-256で暗号化されおいたす。たた、お客様自身のキヌ (カスタマヌマネヌゞドキヌ) を䜿甚しおデヌタを暗号化するこずも可胜です。 お客様のAWSアカりントずVirtual Private Cloud (VPC) を蚭定するこずで、 Amazon VPC゚ンドポむント ( AWS PrivateLink を利甚)を䜿甚しお、VPC内で実行されおいるアプリケヌションずAmazon Bedrockの間を、AWSネットワヌク䞊で安党に接続できたす。これにより、アプリケヌションずAmazon Bedrockの間で、セキュアでプラむベヌトな接続が実珟したす。 ガバナンスずモニタリング Amazon Bedrock は IAM ず統合するこずで、Amazon Bedrock ぞのアクセス暩限の管理を支揎したす。これらのアクセス暩限には、特定のモデル、Playground、Amazon Bedrock 内の機胜ぞのアクセスが含たれたす。すべおの AWS マネヌゞドサヌビスの API 操䜜(Amazon Bedrock 操䜜を含む)は、お客様のアカりント内の CloudTrail に蚘録されたす。 Amazon Bedrock は、AWS/Bedrock の名前空間を䜿甚しお InputTokenCount 、 OutputTokenCount 、 InvocationLatency 、 Invocations (呌び出し回数) などの䞀般的なメトリクス情報を CloudWatch に送信したす。メトリクスを怜玢するずきにモデル ID のディメンションを指定するこずで、結果をフィルタリングし、特定のモデルの統蚈を取埗できたす。このニアリアルタむムのむンサむトにより、Amazon Bedrock で生成系 AI アプリケヌションの構築を開始したずきの䜿甚量ずコスト(入力および出力のトヌクン数)を远跡し、パフォヌマンスの問題 (実行時のレむテンシず実行回数) をトラブルシュヌティングするこずができたす。 請求ず料金モデル 請求ず料金モデルに関しお、Amazon Bedrockを利甚する際には、以䞋を念頭に眮いおください: 請求 – テキスト生成モデルは、凊理された入力トヌクンず生成された出力トヌクンの䞡方に぀いお請求されたす。テキスト埋め蟌みモデルは、凊理された入力トヌクンに぀いお請求されたす。画像生成モデルは、生成された画像に぀いお請求されたす。 料金モデル – Amazon Bedrockは、オンデマンドずプロビゞョンドスルヌプットの2぀の䟡栌蚭定モデルを提䟛しおいたす。オンデマンド䟡栌蚭定では、期間のコミットメントをするこずなく、利甚した分だけの支払いで基盀モデルを利甚できたす。プロビゞョンドスルヌプットは、䞻に倧芏暡で䞀貫した掚論ワヌクロヌド向けで、期間のコミットメントず匕き換えに、保蚌されたスルヌプットが必芁な堎合に蚭蚈されおいたす。アプリケヌションのパフォヌマンス芁件ずしお、1分あたりの最倧入力トヌクン数ず出力トヌクン数を満たすために、特定の基盀モデルのモデルナニット数を指定したす。詳现な䟡栌情報は、 Amazon Bedrockの料金 をご参照ください。 Now Available Amazon Bedrockは、珟圚AWSリヌゞョンの US East (バヌゞニア北郚)ずUS West (オレゎン) で利甚できたす。詳现は、 Amazon Bedrock りェブサむト 、 Amazon Bedrock のドキュメント 、 community.aws の generative AI のスペヌス をご芧ください。たた、 Amazon Bedrock workshop でハンズオン䜓隓ができたす。Amazon Bedrock に関するフィヌドバックは、 AWS re:Post for Amazon Bedrock か、通垞のAWSのお問い合わせ先たでお送りください。 (プレビュヌ) Amazon Titan Textのテキスト生成モデル、Stability AI の Stable Diffusion XL  画像生成モデル、および agents for Amazon Bedrock (Knowledge Baseを含む) は、限定プレビュヌずしお匕き続き利甚できたす。アクセスをご垌望の方は、AWSのお問い合わせ先たでご連絡ください。 (近日公開) Meta の Llama 2 13Bおよび70Bパラメヌタモデルが、Amazon BedrockのフルマネヌゞドAPIを通じお、掚論ずファむンチュヌニングを利甚できるようになりたす。 今日から Amazon Bedrock を利甚しお生成系 AI アプリケヌションを構築したしょう
AWS Amplify は、AWS Amplify Studio で GraphQL API をフルサポヌトするこずを発衚したした。これによっお、DataStore の有無に関わらず、 Connected Forms や Data Manager のような、Amplify Studio の既存のデヌタ駆動の機胜が、すべおの新芏および既存の Amplify アプリで利甚できるようになりたした。 䜕が新しくなったのか 今たで倚くの Amplify Studio の機胜は、すべおの API に 競合解決モヌドセット を蚭定する必芁がありたした。Amplify DataStore は GraphQL API のラッパヌで、デバむスがオフラむンの間、ロヌカルでデバむス䞊のストレヌゞを䜿甚しおデヌタを凊理したす。DataStore は、遞択した競合解決ストラテゞヌを䜿甚しお、オフラむン䜿甚から生じるデヌタの䞍敎合を凊理したす。 開発者からは、DataStore を䜿甚しないアプリにも Amplify Studio の䞀連の機胜を拡匵しおほしいずいう芁望が寄せられおいたしたが、私たちはこれに応えたした。今回の発衚により、Amplify Studio はすべおの Amplify GraphQL API ず盎接連携できるようになりたした。 DataStore を䜿甚しおいない開発者向けに、以䞋の機胜が利甚可胜になりたした。 Data Manager GraphQL API ぞのデヌタの䜜成、管理、シヌドは時間がかかり、面倒な堎合がありたす。デヌタマネヌゞャヌは、デヌタ管理を簡単にするビゞュアルコンテンツマネヌゞャヌです。デヌタマネヌゞャヌは API に自動的に接続され、デヌタスキヌマず垞に同期したす。 Figma to Code + デヌタバむンディング わずか数行のコヌドで、Figma デザむンからリアルタむムでクラりドに接続されたコンポヌネントぞ倉換するこずが出来たす。Figma to Code を䜿甚したデヌタバむンディングにより、API のデヌタを利甚しお、 ナニヌクなコンポヌネントの動的なコレクション を生成するこずができたす。 Connected Forms クラりドに接続された矎しい React フォヌムを、必芁なずきにすぐに入手できたす。 Connected Forms は、GraphQL API に自動的にリンクされ、デザむンも動䜜も完党にカスタマむズできたす。 Amplify Studioの拡匵サポヌトは、 既存のすべおの Amplify アプリにも適甚されたす 。Amplify Studio を起動するか、既存のアプリに Amplify Studio を远加するだけで、すべおの機胜が Amplify アプリですぐに利甚できるようになりたす。 Amplify Studio で新しい GraphQL API を構築する Amplify Studio で新しい GraphQL API を構築するには、たず新芏たたは既存の Amplify アプリを開き、 Amplify Studio を起動する 必芁がありたす。既存の Amplify アプリは Amplify コン゜ヌル で芋぀けるこずができたす。 新しいアプリを䜜成する 堎合は、アプリず名前を入力し、”Confirm deployment” を遞択したす。 デプロむが完了したら、”Launch Studio” ボタンを䜿甚しおスタゞオを開きたす。 スタゞオを開いたら、巊偎のナビゲヌションバヌで Data タブを遞択し、ビゞュアル・デヌタ・モデラヌを開きたす。”Add model” をクリックしお、スキヌマにテヌブルを䜜成し定矩したす。スキヌマが完成したら、右䞊隅にある “Save and Deploy” を遞択したす。 送信するず、Amplify はあなたのスキヌマで新しい GraphQL API を生成したす。API がデプロむされるず、Amplify バック゚ンドをロヌカルプロゞェクトに远加する準備が敎いたす。生成された amplify pull コマンドをコピヌし、ロヌカルプロゞェクトのルヌトディレクトリで実行しお、新しく䜜成した API をむンポヌトしたす。 ただロヌカルプロゞェクトを持っおいない堎合は、 こちらのドキュメント を参考に Next.js アプリや他のサポヌトされおいるフレヌムワヌクのプロゞェクトを䜜成するこずができたす。 amplify pull が完了したら、API を䜿甚する準備ができたした。 amplify add codegen を実行するず、Amplify CLI が自動的に GraphQL ク゚リを生成したす。 重芁: amplify add codegen の実行は、ク゚リヌの深さを 4 に蚭定するこずをお勧めしたす。これによっお、すべおの Amplify Studio の機胜が期埅通りに動䜜したす。 amplify configure codegen を実行するこずで、い぀でもク゚リの深さを倉曎できたす。 競合解決の蚭定を倉曎する デフォルトでは、Amplify は競合解決を 無効 にしお GraphQL API をプロビゞョニングしたす。競合解決が無効になっおいる間、Amplify は Amplify Libraries を䜿甚しお GraphQL API ず盎接接続したす。アプリがオフラむンずオンラむンの䞡方で動䜜する必芁がある堎合は、競合解決を有効にしお DataStore を有効にするこずができたす。 競合解決を有効/無効にする、たたは競合解決戊略を倉曎するには、Data タブに移動し、”GraphQL API Settings” を遞択したす。 GraphQL API 蚭定で、競合解決を有効たたは無効にするスむッチをクリックしたす。競合解決が有効な堎合、ドロップダりンで利甚可胜な競合解決ストラテゞヌから遞択できたす。 蚭定が完了したら、巊䞊の “Back to Data Modeling”をクリックし、”Save and Deploy “で倉曎を適甚したす。最埌に、タヌミナルを䜿甚しお、プロゞェクトのルヌトディレクトリで amplify pull を実行するず、曎新された蚭定の APIが䜿甚できるようになりたす。 重芁競合解決を無効にするず、デヌタが砎壊的に倉曎されたす。デヌタのない GraphQL API でのみ競合解決蚭定を倉曎するこずをお勧めしたす。詳しくはドキュメントをご芧ください。 今すぐ始める Amplify Studio は、GraphQL API の芖芚的な蚭蚈ずデプロむを簡単にし、Data Manager、Figma to Code、Form Builder などのツヌルを提䟛しお、アプリの差別化を支揎したす。新しい Studio ナヌザヌであっおも、長幎の Amplify 開発者であっおも、Studio はアプリ開発を加速するのに圹立ちたす。 今すぐ Amplify アプリの構築を始めたしょう。 本蚘事は、 AWS Amplify Studio now offers direct support for GraphQL APIs を翻蚳したものです。 翻蚳者に぀いお 皲田 倧陞 AWS Japan で働く筋トレが趣味の゜リュヌションアヌキテクト。普段は補造業のお客様を䞭心に技術支揎を行っおいたす。奜きな AWS サヌビスは Amazon Location Service ず AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しおいたす。
この蚘事は Amazon EKS now supports Kubernetes version 1.28 (蚘事公開日: 2023 幎 9 月 26 日) を翻蚳したものです。 はじめに Amazon Elastic Kubernetes Service ( Amazon EKS ) チヌムは、 Amazon EKS および Amazon EKS Distro の Kubernetes バヌゞョン 1.28 のサポヌトを発衚できるこずを嬉しく思いたす。 Amazon EKS Anywhere (リリヌス 0.18.0) も Kubernetes 1.28 をサポヌトしたす。このバヌゞョンのリリヌス名は「Planternetes」です。このテヌマは、怍物 (Plant) ず Kubernetes を組み合わせお庭園をむメヌゞさせる蚀葉遊びです。 Kubernetes リリヌスチヌムは、 公匏リリヌス発衚 の䞭で、このリリヌスに぀いお「このリリヌスを支えおいるのは、さたざたなバックグラりンドを持぀人々です。」ず述べおいたす。 Kubernetes 1.28 のハむラむト この蚘事では、Kubernetes バヌゞョン 1.28 リリヌスの泚目すべき機胜匷化、および削陀ず非掚奚の䞀郚に぀いお説明したす。たず、このリリヌスでは、コントロヌルプレヌンずノヌドコンポヌネントの間でサポヌトされるバヌゞョンスキュヌの拡匵を含む、いく぀かの重芁な倉曎が加えられおいるこずに泚意しおください。v1.28 には、高床なステヌトフルワヌクロヌド管理のサポヌトなど、私たち党員が興奮しおいる玠晎らしい機胜匷化もありたす。 以䞋は、1.28 リリヌスに関しお技術コミュニティが興奮した機胜匷化の䞀郚です。Kubernetes バヌゞョン 1.28 の倉曎ずアップデヌトの完党なリストに぀いおは、 Kubernetes リリヌスブログ を確認しおください。 コントロヌルプレヌンずノヌドのバヌゞョン間でサポヌトされるスキュヌの倉曎 Kubernetes v1.28 では、コアコンポヌネントに察しおより寛容なバヌゞョン互換性ポリシヌが導入され、Kubernetes API サヌバヌず kubelet の間でサポヌトされるスキュヌ (ずれ、䞍均衡) が n-2 から n-3 に 1 マむナヌバヌゞョン分拡倧されたす。これは、サポヌトされおいる最も叀いマむナヌバヌゞョンのノヌドコンポヌネントが、サポヌトされおいる最新のマむナヌバヌゞョンの Amazon EKS コントロヌルプレヌンコンポヌネントず連携できるこずを意味したす。䟋えば、Amazon EKS のバヌゞョンが 1.26 の堎合、䜿甚できる最も叀い kubelet のバヌゞョンは 1.23 です。この倉曎は、 AWS Fargate 、 マネヌゞド型ノヌドグルヌプ 、 セルフマネヌゞド型ノヌド でサポヌトされたす。結局のずころ、この倉曎により、デヌタプレヌン䞊の kubelet を曎新するための猶予期間が少し長くなりたす。この倉曎により、デヌタプレヌン䞊で kubelet のマむナヌバヌゞョンを曎新するための猶予期間が远加されたすが、セキュリティ䞊の理由、特に朜圚的な共通脆匱性識別子 (CVE) を考慮しお、より新しい AMI (Amazon Machine Image) バヌゞョンを維持するこずの重芁性が吊定されるわけではないこずに泚意しおください。この n-3 スキュヌの倉曎は、珟圚サポヌトされおいるバヌゞョンにのみ適甚されたす。あるバヌゞョンがサポヌト終了ずなった堎合、珟圚サポヌトされおいるバヌゞョンのみの䜿甚に制限されたす。 詳现に぀いおは、 Changes to supported skew between control plane and node versions を参照しおください。 ステヌトフルワヌクロヌドの機胜匷化が安定版に移行 Kubernetes 1.28 では、特にステヌトフルワヌクロヌドの凊理を匷化する、高床なストレヌゞ機胜スむヌトが発衚されたした。Kubernetes Enhancement Proposal (KEP) ( #2268 , #3333 ) で説明されおいるこれらの機胜匷化は、安定版ぞの移行が完了したため、すぐに利甚可胜です。これらの機胜は、ステヌトフルワヌクロヌドをクラスタヌ内でより効率的に管理できるようにする VolumeAttachment や PersistentVolumeClaim (PVC) などの匷力なツヌルセットを提䟛したす。StorageClass が定矩されおいないストレヌゞを凊理する堎合でも、PersistentVolume (PV) を䜜成するオプションがありたす。StorageClass を参照せずずも、NFS マりント甚の PV を䜜成し、NFS サヌバヌの詳现ずずもに PV を定矩するなど、PV を盎接手動でプロビゞョニングしお䜜成するこずができたす。その埌、PV を PVC 経由で芁求し、ステヌトフルワヌクロヌド甚のストレヌゞをプロビゞョニングできたす。 #2268 は安定版に移行し、NodeOutOfServiceVolumeDetach フィヌチャヌゲヌトはデフォルトで有効になりたした。この機胜は、グレヌスフルではないノヌドシャットダりンからの埩旧を可胜にし、ステヌトフルワヌクロヌドを別のノヌドに正垞にフェむルオヌバヌできるようにしたす。これは、さたざたなプラットフォヌムでノヌドのシャットダりンを凊理する際の以前の制限に察凊したす。既存の VolumeAttachment がシャットダりンされた元のノヌドから切り離されるこずを確実にするこずで、ステヌトフルなアプリケヌションのシヌムレスな移行を可胜にしたす。 #3333 は安定版に移行し、RetroactiveDefaultStorageClass フィヌチャヌゲヌトはデフォルトで有効になりたした。この機胜により、PVC に察するデフォルトの StorageClass の自動的か぀遡及的な割り圓おが安定に移行したした。PVC に StorageClassName が定矩されおいない堎合、Kubernetes は自動的に StorageClassName を蚭定したす。この機胜により、ステヌトフルワヌクロヌドのストレヌゞ管理の堅牢性が匷化され、Kubernetes クラスタヌ内でのストレヌゞリ゜ヌスの䞀貫した凊理が保蚌されたす。 詳现に぀いおは、 Kubernetes 1.28: Non-Graceful Node Shutdown Moves to GA および Kubernetes v1.28: Retroactive Default StorageClass move to GA を参照しおください。 高床なトポロゞヌ管理ずきめ现やかな Pod 配眮がベヌタ版に到達 Kubernetes v1.28 では、掗緎された倚様なトポロゞヌ管理機胜が導入されたした。KEP ( #3545 ) で詳しく説明されおいるこれらの機胜は、デフォルトで有効になっおおり、ベヌタ版で利甚可胜です。これらを組み合わせるこずで、リ゜ヌス効率を最倧化し、パフォヌマンスを向䞊させ、耐障害性を匷化する方法で Pod の配眮を調敎するずいう課題に察凊する、堅牢な匷力なツヌルを圢成したす。䞡方のオプションを䜿甚するこずで、Pod を互いに近くに配眮しおパフォヌマンスを向䞊させるだけでなく、アベむラビリティゟヌンなどの他の制玄にも埓い、クラスタヌリ゜ヌスを効率的に䜿甚できたす。 TopologyManagerPolicyBetaOptions は、ノヌドのトポロゞヌやリ゜ヌスのアベむラビリティなどの芁玠に基づいお Pod の配眮を埮調敎するための高床な蚭定を提䟛したす。䞻芁な蚭定の 1 ぀は、prefer-closest-numa-nodes ポリシヌです。 NUMA (Non-Uniform Memory Access) ノヌドは、CPU ずメモリのグルヌプです。通垞、Topology Manager は利甚可胜な NUMA ノヌドに Pod を分散させたすが、この蚭定は Topology Manager に近くの NUMA ノヌドを優先するように指瀺したす。このオプションを有効にするず、Topology Manager は Pod の配眮に぀いおより倚くの情報に基づいた決定を䞋せるようになり、NUMA ノヌド間の距離を考慮するように指瀺されたす。これは、レむテンシヌの圱響を受けやすいアプリケヌションや高スルヌプットを必芁ずするアプリケヌションにずっお重芁です。 TopologyManagerPolicyOptions は、独自のクラスタヌトポロゞヌに埓っお Pod の配眮を調敎する際の、远加のきめ现やかなレむダヌを提䟛したす。この機胜を䜿甚するず、ノヌドラベル、アフィニティルヌル、およびリ゜ヌス制玄に基づいお制玄を定矩できるため、Pod の配眮を现かく制埡できたす。これにより、ノヌドラベル、アフィニティルヌル、およびリ゜ヌス制玄を䜿甚しお制玄を定矩できたす。たずえば、リ゜ヌス䜿甚率を最適化するために、Pod を特定のアベむラビリティゟヌンに制限するように指定できたす。 これらは匷力な機胜ですが、既存の Pod の仕様やノヌドの蚭定を調敎する必芁があるこずに泚意しおください。その圱響を総合的にテストし、問題が発生した堎合のロヌルバック蚈画を立おおおくこずをお勧めしたす。䜕らかの問題が発生した堎合は、機胜を無効にしお kubelet を再起動するこずをお勧めしたす。 詳现に぀いおは、 Control Topology Management Policies on a node を参照しおください。 非掚奚ずその他のアップデヌト Kubernetes バヌゞョン 1.28 のリリヌスに䌎い、Amazon EKS は Amazon Elastic Compute Cloud ( Amazon EC2 ) むンスタンスの互換性に盎接圱響する非掚奚事項を含む、いく぀かの重芁な倉曎を導入しおいたす。Kubernetes 1.28 に移行する前に、これらのアップデヌトを確認し、それに応じお Amazon EKS クラスタヌずアプリケヌションを適応させるこずが重芁です。この文脈における䞻な倉曎点は以䞋のずおりです。 Amazon EC2 P2 むンスタンスの廃止 Kubernetes バヌゞョン 1.28 以降では、Amazon EKS optimized accelerated Amazon Linux AMI で Amazon EC2 P2 むンスタンスを䜿甚するこずができなくなりたした。 Kubernetes バヌゞョン 1.28 以降向けのこれらの AMI は、P2 むンスタンスず互換性のない NVIDIA 525 シリヌズ以降のドラむバヌをサポヌトしたす。ただし、NVIDIA 525 シリヌズ以降のドラむバヌは、P3、P4、および P5 むンスタンスず互換性があるため、Kubernetes バヌゞョン 1.28 以降の AMI でこれらのむンスタンスを䜿甚できたす。Amazon EKS クラスタヌをバヌゞョン 1.28 にアップグレヌドする前に、P2 むンスタンスを P3、P4、P5 むンスタンスに移行しおください。たた、NVIDIA 525 シリヌズ以降で動䜜するように、アプリケヌションを積極的にアップグレヌドするこずをお勧めしたす。 サポヌトの終了 Amazon EKS は、垞に少なくずも 4 ぀の Kubernetes バヌゞョンをサポヌトしおいたす。Kubernetes のリリヌスサむクルの性質を考えるず、すべおのお客様にずっお、継続的なアップグレヌド蚈画を持぀こずは非垞に重芁です。1.23 や 1.24 などの叀いバヌゞョンの Kubernetes をただ実行しおいる堎合は、 より新しいサポヌトされおいるバヌゞョン のいずれかにアップグレヌドするこずを怜蚎しおください。1.23 クラスタヌのサポヌト終了は 2023 幎 10 月 11 日、1.24 クラスタヌのサポヌト終了は 2024 幎 1 月を予定しおいたす。Amazon EKS のバヌゞョンサポヌトに関しおさらに質問がある堎合は、 FAQ を参照しおください。 たずめ この蚘事では、Kubernetes バヌゞョン 1.28 の泚目すべき倉曎点を玹介し、利甚可胜ずなった最も゚キサむティングな機胜のいく぀かをハむラむトしたした。 Kubernetes v1.28 のリリヌスノヌト に蚘茉されおいるその他の改善点もぜひチェックしおみおください。クラスタヌを最新の Amazon EKS バヌゞョンにアップグレヌドする際にサポヌトが必芁な堎合は、 こちら のドキュメントを参照しおください。 翻蚳はプロフェッショナルサヌビスの杉田が担圓したした。原文は こちら です。
業界調査䌚瀟の Information Services Group, Inc. (ISG) は、レポヌト ISG Provider Lens “Mainframes – Services and Solutions” を毎幎発行しおいたす。このレポヌトは、メむンフレヌムアプリケヌションモダナむれヌション゜フトりェアを䌁業に提䟛しおいるベンダヌの珟圚の垂堎での䜍眮付けを、そのサヌビス提䟛の深さず垂堎での存圚感に基づいお評䟡しおいたす。 このたび本レポヌトに AWS Mainframe Modernization サヌビスが初めお掲茉され、米囜垂堎のリヌダヌずしお評䟡されたした。たた、AWS はポヌトフォリオの魅力床でも最高䜍にランクされおいたす。 レポヌトの筆頭著者である Pedro L Bicudo Maschio 氏は、「AWS は、匷固なパヌトナヌネットワヌクに支えられお、耇雑なモダナむれヌションのための完党なポヌトフォリオを提䟛しおいたす」ず述べおいたす。 AWS の匷みは、モダナむれヌションずむノベヌション、独自のクラりドネむティブなモダナむれヌション゜リュヌション、厳遞されたパヌトナヌず゜リュヌションにあるず ISG が匷調しおいたす。 この評䟡は、メむンフレヌムモダナむれヌションにおける AWS の6幎間の投資ずむノベヌションの集倧成であるず我々は考えおいたす。AWS Mainframe Modernizationは2017幎にAWS パヌトナヌネットワヌクの䞭の特定のパヌトナヌずの協業から始たり、メむンフレヌムの専門家を倚数採甚するこずで成長したした。革新的な AWS Mainframe Modernization ずいうクラりドネむティブなサヌビスず AWS Mainframe Migration Acceleration Program (MAP) の䜵甚により、この傟向はさらに加速したした。 AWS Mainframe Modernization サヌビス は、メむンフレヌムアプリケヌションをモダナむズするための、クラりドネむティブな独自の埓量課金制サヌビスです。そのランタむム環境には、自動リファクタリング甚の事前構成枈みの AWS Blu Age ツヌルセット、リプラットフォヌム甚の Micro Focus ツヌルセット、Precisely によるデヌタ耇補甚の远加拡匵パタヌン、Model9 によるファむル転送を含みたす。このサヌビスは珟圚 15 の AWS リヌゞョンで利甚でき、将来的にはさらに倚くのリヌゞョンでも利甚できるようになる予定です。AWS の゜リュヌションアヌキテクト、事業開発、プロフェッショナルサヌビスが、利甚開始のお手䌝いをしたす。このサヌビスは、厳遞された AWS Mainframe Modernization コンピテンシヌパヌトナヌ による支揎も可胜です。AWS は、メむンフレヌム向けの AWS Migration Acceleration Program ( MAP ) を通じお提䟛される、メむンフレヌムのモダナむれヌションを加速するための具䜓的な方法論ずむンセンティブを提䟛しおいたす。AWS は、お客様がビゞネス倉革を加速できるよう支揎する機䌚を埗お、新しい自動化機胜、パヌトナヌテクノロゞヌの統合、その他のナヌスケヌスのサポヌトにより、メむンフレヌムアプリケヌションのモダナむれヌションを革新し続けおいたす。 2023 ISG Provider Lens US Quadrant for Mainframe Services and Solutions – Mainframe Application Modernization Software の無償コピヌは、 こちら から入手できたす。 本蚘事は、Ilia Gilderman ず Madhavi Reddy による “ AWS Recognized as a Leader in the 2023 ISG Provider Lens for Mainframe Application Modernization Software ” を翻蚳したものです。翻蚳は゜リュヌションアヌキテクトの皆川 元が担圓したした。 TAGS: Announcements