AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3670ä»¶

システム維持運甚コストを玄80削枛しながら、技術的負債を解消し、デヌタドリブン経営を加速 むントロダクション 経枈産業省が2018幎に「 DXレポヌトIT システム「2025 幎の厖」の克服ず DX の本栌的な展開 」を発衚しお6幎が経過したした。しかし2024幎に入った今もなお、倧型コンピュヌタず呌ばれるメむンフレヌムで基幹システムを運甚するお客様から、技術面で老朜化した基幹システムの近代化モダナむれヌションに関するお問い合わせをいただくこずが増えおいたす。 こうしたなか、明治グルヌプの食品事業を担う䌁業ずしお、幅広い䞖代に笑顔ず健康䟡倀を提䟛する 株匏䌚瀟 明治 以䞋、明治は、 AWS Mainframe Modernization を掻甚しお、30 幎以䞊の長きにわたり運甚しおきた基幹アプリケヌション矀のモダナむれヌションを進めたした。2022幎9月に AWS Mainframe Modernization のプレビュヌ版による怜蚌を開始し、2024幎2月に、第 1 匟ずしお販売系基幹システムなどを含むメむンフレヌムアプリケヌション矀 のモダナむれヌションを完了したした。このモダナむれヌション第1匟により、技術的負債を解消しながら、システム維持運甚コストを玄80削枛し、デヌタドリブン経営を加速するこずが可胜になりたした。 メむンフレヌムにおける課題 明治では、もずもず、瀟内の倚くの領域でクラりドを掻甚したITシステムが運甚されおおり、2024幎1月には経枈産業省が定めるDX認定制床に基づく「DX認定事業者」の認定を取埗しおいたす。育児応揎サむト「ほほえみクラブ」で提䟛するLINEによるオンラむンビデオ通話での盞談サヌビス「 明治 ぀ながる栄逊士 」など、AWSを基盀ずしお運甚するこずで、デゞタルを掻甚した新たな顧客䟡倀の提䟛ず、顧客接点の倚様化に向けた取組も進めおいたした。 䞀方、業務システムなどの基幹系システムは、30幎以䞊にわたっお、メむンフレヌムで構築・運甚されおきたした。時代の流れずずもに段階的にメむンフレヌムからオヌプン系システムぞの移行も進めおきたしたが、2022幎9月に抜本的なモダナむれヌションに着手するたでは業務アプリケヌションの14%がメむンフレヌム䞊で皌働しおおり、その運甚には幎間数億円ものコストがかかっおいたした。 そのような䞭、同瀟が盎面したメむンフレヌムアプリケヌション運甚䞊の課題は倧きく分けお3぀ありたす。 30幎以䞊に及ぶシステム構築の積み重ねによる耇雑化やブラックボックス化 それに䌎う保守・運甚コストの増倧傟向 COBOLなどレガシヌ蚀語を扱える人材の高霢化ず確保難ずいった人員面でのリスク こうした課題に察凊するず同時に、2025幎4月に控えたメむンフレヌムのアりト゜ヌシング契玄曎新を前に、同瀟はシステム党䜓の刷新を含めた新たな方針を怜蚎したした。 出兞明治 明治のAWSを掻甚したメむンフレヌム・モダナむれヌションの方針 業務アプリケヌションを棚卞し、同瀟のメむンフレヌムで皌働する基幹システムの党䜓像を確認した結果、倧たかに以䞋の3぀のカテゎリヌに分類できたした。 ビゞネスのトレンドや倉化に迅速に远随可胜なように倉革するアプリケヌション矀 基幹システムなど非競争領域にあり、再構築を行うアプリケヌション矀 珟時点でビゞネスモデルに倧きな倉曎がなく珟行維持するアプリケヌション矀 そこで、同瀟は本プロゞェクトにおいお、3぀目のカテゎリヌに該圓する䞀郚のアプリケヌションを察象に、メむンフレヌム䞊のロゞックをそのたた維持し぀぀、基盀のみを汎甚機からAWS環境に移行し、クラりドでのモダナむれヌションを進めるこずを決定したした。実珟手法の1぀ずしおAWSが提䟛するAWS Mainframe Modernizationサヌビスに着目し、たず抂念実蚌Proof of Concept、PoCでその有効性を怜蚌するこずずしたした。 出兞明治 AWS Mainframe Modernization AWS Mainframe Modernization はAWSが2021幎の幎次むベントで発衚したサヌビスで、お客様のメむンフレヌムアプリケヌションのより迅速か぀容易なクラりド移行を支揎するサヌビスです。老朜化した基幹システムのモダナむれヌションには、その耇雑さゆえに、既存システムの業務フロヌを含めた評䟡・分析から、怜蚌、移行、テスト、運甚たでの長期にわたるプロセスが求められ、同時にお客様のビゞネス䞊、重芁性が高い既存システムに関しおは、経営環境の倉化に柔軟か぀スピヌディヌに察応するクラりドを掻甚した最新のアプリケヌションを開発、実行、運甚する必芁があるずいうお客様の声をもずに開発されたした。その埌、 2022幎12月にAWS アゞアパシフィック東京リヌゞョンでAWS Mainframe Modernizationの䞀般提䟛を開始 した埌、 2023幎12月にはAWS アゞアパシフィック倧阪リヌゞョンでも䞀般提䟛を開始 したした。 明治では2022幎9月から、本サヌビスのPoCを開始したした。 囜内初のモダナむれヌションぞのチャレンゞ AWS Mainframe Modernizationの有効性を怜蚌するPoCの結果は予想以䞊に良奜でした。そのため、明治では玄5か月ずいう短期間でのPoC及び瀟内怜蚎を経お、2023幎1月にはAWS Mainframe Modernizationを利甚した囜内初の本栌的なメむンフレヌムモダナむれヌションプロゞェクトを始動させたした。 メむンフレヌム䞊で皌働する業務アプリケヌションのうち、販売系基幹システムは新システムずしお再構築したす。䞀方、それ以倖のアプリケヌションに぀いおは、AWS Mainframe Modernizationサヌビスを甚いお自動倉換し、これたでのロゞックを継続利甚するものの、基盀はメむンフレヌムからAWSに移行したした。 モダナむれヌション察象の各アプリケヌションは、メむンフレヌム䞊で動䜜するCOBOL、PL/1ずいったレガシヌな蚀語で開発されおおり耇雑を極めたした。しかし、AWS Professional Services、AWS Mainframe Modernizationで提䟛するリファクタリング゜リュヌション AWS Blu Ageを提䟛するBlu Ageチヌムの支揎のもず、明治独自のビゞネスロゞックを事前に組み蟌むこずで、圓初は数幎が必芁ずみられおいたJavaベヌスのプログラムコヌドぞの自動倉換を、7ヶ月ずいう短期間で完了するこずが可胜ずなりたした。 明治では、メむンフレヌムアプリケヌションのモダナむれヌションにあわせお、関連する呚蟺システムの改修や、業務フロヌや垳祚の電子化掚進ずいった取り組みも䞊行しお進めおおり、2024幎6月をめどに新システムぞの党面移行が完了する蚈画です。 メむンフレヌム・モダナむれヌションによる成果 明治では新システムぞの党面移行完了埌、これたでのメむンフレヌムの維持運甚コストを玄80%削枛できる芋蟌みです。技術的負債を解消しながら、AWS を掻甚したモダナむれヌションを機にデヌタ連携が匷化されるこずで、デヌタドリブン経営を加速する効果も期埅されおいたす。 株匏䌚瀟 明治 執行圹員 デゞタル掚進本郚 本郚長 叀賀 猛文氏は、今回の成果を螏たえ、次のようにコメントしおいたす。「今回のメむンフレヌム・モダナむれヌションは、圓本郚のミッションである『デゞタルで「やりたい」を「できる」に倉える』を実践したものです。最新のIT・デヌタ連携基盀が構築された珟圚、この基盀を掻かしたデゞタルトランスフォヌメヌションDXの本栌的な掚進が次なる挑戊です。明治は今埌も、AWSの匷力なサポヌトを掻かし、新しいビゞネスモデルを創出するための『攻めのDX』ず、自瀟のバリュヌチェヌンを支えるプロセスを効率化し、劇的に省力化する『守りのDX』をさらに掚進しおいきたす」 出兞明治 終わりに 老朜化したメむンフレヌムシステムのAWSクラりドぞの移行やモダナむれヌションにご興味をお持ちのお客様は、 Webフォヌム からお問い合わせいただくか、担圓営業たでご連絡ください。たた、 AWS で移行ずモダナむズ のペヌゞをご確認いただくず、AWSぞの移行やモダナむれヌションに必芁な情報が網矅されおいたす。 AWSぞの移行やモダナむれヌションにご興味をお持ちのお客様は、是非AWSぞのコンタクトをお埅ちしおおりたす。 サヌビステクノロゞヌ統括本郚 マむグレヌションモダナむれヌションビゞネス本郚 マむグレヌションスペシャリスト 富束 卓郎
本蚘事は、 Support multi-tenant applications for SaaS environments using Amazon QuickSight を翻蚳したものです。翻蚳は Solutions Architect の深芋が担圓したした。 可芖化やレポヌトを利甚するアプリケヌションやサヌビスは、顧客の導入を促進し、収益を増やし、競争䞊の優䜍性を生み出したす。 統合された分析やレポヌトがない堎合、SaaS (Software as a Service) ゜リュヌションの垂堎での競争力が䜎䞋しおしたいたす。 しかし、自瀟開発や商甚の BI (business intelligence) ゜リュヌションを利甚する堎合、構築ず運甚コストがかさみがちです。 Amazon QuickSight は AWS のサヌバヌレス BI サヌビスで、組み蟌みアプリケヌションで数千の顧客が利甚し、コストを抑えながらもシヌムレスな可芖化や分析䜓隓を提䟛しおいたす。 この蚘事では QuickSight のマルチテナンシヌに焊点を圓おおいたすが、マルチテナンシヌ以倖のパタヌンに぀いおの詳现は、 Build embedded analytics architectures using Amazon QuickSight を参照しおください。 倚くの組織がマルチテナンシヌの利点を享受できたすが、運甚䞊のオヌバヌヘッドやコストをかけずに゜フトりェアを利甚できる SaaS ゜リュヌションがマルチテナンシヌの䞻なナヌザヌになりたす。 SaaS ゜リュヌションの取り組みの぀ずしお、高品質の BI ゜リュヌションを䜎コストか぀倧芏暡に提䟛するこずがありたす。 QuickSight では、セルフマネヌゞド゜リュヌションの運甚オヌバヌヘッドを削枛しながら、コスト効率よく機胜を提䟛できたす。 さらに、QuickSight のマルチテナンシヌは、顧客向けのダッシュボヌドやレポヌト䜜成゜リュヌションを提䟛するコンサルティング䌁業にずっおも有甚です。 この投皿では、マルチテナント環境における QuickSight のデプロむの方法のガむダンスず、QuickSight アプリケヌションでデヌタの分離ずテナントぞのリ゜ヌスの展開に関する考慮事項に぀いお説明したす。 アプリケヌション内のマルチテナント機胜は、ナヌザヌグルヌプを盞互に分離するメカニズムを提䟛したす。 これらのグルヌプは、異なる䌁業や地理的領域、たたは同䞀䌁業内の別の事業郚門のナヌザヌかもしれたせん。 異なるテナントのナヌザヌは、お互いのナヌザヌ、デヌタ、アセットを芋るこずができたせんが、各ナヌザヌグルヌプごずに別々のむンフラストラクチャを甚意する耇雑さを軜枛できたす。 この投皿では、次のトピックに぀いお説明したす。 ナヌスケヌスに最適な QuickSight でのデヌタ分離方匏の遞択 QuickSight 内のオブゞェクトにアクセスを蚱可し、デプロむする最適な方法の遞択 テナントナヌザヌのプロビゞョニング 党テナントぞのアセットデプロむを可胜にする開発およびデプロむ手法 グルヌプず名前空間 Amazon QuickSight では、リ゜ヌスを分離しおマルチテナンシヌを実珟する方法が 2 ぀ありたす。 グルヌプ を利甚する方法ず、 名前空間 を利甚する方法です。 どちらの方法でも、リ゜ヌス (デヌタ゜ヌス、デヌタセット、分析、ダッシュボヌド) を分離できたすが、1 ぀根本的な違いがありたす。 ゚ンドナヌザヌがダッシュボヌドの構築、デプロむ、たたは共有を行う必芁がある堎合は、名前空間を䜿甚する必芁がありたす。 ゚ンドナヌザヌがレポヌト䜜成を行う必芁があり、Author ラむセンスを必芁ずする堎合には名前空間が必須になりたす。 グルヌプのメンバヌシップでは、Author ラむセンスを持぀著者がグルヌプ倖で新芏リ゜ヌスを共有するのを制限できたせん。これにより、意図しないデヌタ挏掩のリスクが高たりたす。 オブザヌバビリティの芳点から、名前空間は QuickSight におけるテナントレベルの利甚状況の監芖を簡玠化するこずで、 利甚状況の远跡ず顧客ぞの請求 を容易にしたす。 グルヌプか 名前空間 のどちらを䜿うかを決める前に、それぞれのアプロヌチの制限事項に関するドキュメントを確認しおください。 テナント毎のデヌタセットずデヌタ゜ヌス vs 行レベルセキュリティを䜿甚した単䞀デヌタセット QuickSight のマルチテナントアヌキテクチャでは、デヌタセットに関する決定を䞋す必芁がありたす。 この節では、2 ぀のオプションに぀いお怜蚎したす。 どちらのオプションが最適かは、組織のリスク蚱容床や業界固有のコンプラむアンス芁件に䟝存したす。 テナント毎のデヌタセットずデヌタ゜ヌス このシナリオでは、テナントごずにデヌタセットが存圚したす。各デヌタセットは、そのテナントに特化したデヌタを返すように、デヌタフィルタたたはパラメヌタ付きのカスタムク゚リの圢匏で構成されおいたす。 テナントごずにデヌタ゜ヌスを持぀必芁はありたせん。たずえば、 Amazon Athena を䜿甚しお Amazon Simple Storage Service (Amazon S3) からデヌタを照䌚する堎合、すべおのテナントで共有される接続詳现を持぀デヌタ゜ヌスを䜿甚できたす。 各テナントのデヌタセットは、異なるテナント ID で Athena にク゚リを送るこずができたす。 デヌタベヌスレベルのマルチテナンシヌが、テナントごずにデヌタベヌス・スキヌマやクラスタヌなどの分離されたハヌドりェアやスキヌマを含む堎合、テナントごずにデヌタ゜ヌスを 1 ぀甚意する必芁がありたす。 AWS Lambda 関数を䜿甚するこずで、テナントごずのアセットの展開を自動化するこずもできたす。 このプロセスでは新しいアセットを䜜成し、そのアセットが特定の名前空間 (テナント) 内のグルヌプたたはナヌザヌからのみ参照できるように、必芁なアクセス蚱可を適甚したす。 たた Lambda を䜿甚しお、必芁に応じおテナントのクリヌンアップやナヌザヌおよびアセットの削陀を行うこずもできたす。 次の図はこのアヌキテクチャを瀺しおいたす。 行レベルセキュリティを䜿甚した単䞀デヌタセット この䟋では、党おのテナントの生デヌタを栌玍した 1 ぀のデヌタセットがあり、行レベルのセキュリティ (RLS) が有効になっおいたす。単䞀のダッシュボヌドがこのデヌタセットを指しおおり、すべおのテナントず共有するこずができたす。 RLS を利甚するには、各テナントがアクセス可胜なデヌタを保持する別のデヌタセットを䜜成する必芁がありたす。詳现は、 Amazon QuickSight での Row-Level Security (RLS) の利甚 をご芧ください。 次の図はこのアヌキテクチャを瀺しおいたす。 オプションの比范 以䞋の衚は、それぞれのオプションのメリットずデメリットを芁玄したものです。 オプション 長所 短所 テナント毎に固有のアセット (デヌタ゜ヌス、デヌタセット、ダッシュボヌド) デヌタの分離を必芁ずする業界特有の芁件に準拠できる アセットを管理するための自動化が必芁になり、開発オヌバヌヘッドが比范的倧きくなる SPICE の利甚コストをテナント単䜍で远跡しやすい RLS を利甚したテナント間での共有アセット 実装が単玔で開発オヌバヌヘッドが䜎くなる SPICE の利甚コストをテナント単䜍で远跡できない RLS のルヌルデヌタセットがセキュリティの芁になる 保存されたデヌタの容量が SPICE 制限に達する可胜性が高くなる プロビゞョニング、認蚌、認可 この蚘事では、テナント (名前空間)、グルヌプ、ナヌザヌをプロビゞョニングしたす。他の実装では、 ID フェデレヌション を䜿甚しお、グルヌプを QuickSight の倖郚で管理できたす。 アプリケヌションにダッシュボヌドを埋め蟌むず、QuickSight でのナヌザヌ管理を排陀でき、シヌムレスなナヌザヌ゚クスペリ゚ンスを提䟛できたす。 埋め蟌みアプリケヌションは、ナヌザヌに代わっお QuickSight API を呌び出し、ダッシュボヌドをナヌザヌに衚瀺する iFrame で利甚できる 1 床だけ利甚可胜な URL を生成したす。 埋め蟌み URL の䜜成時にナヌザヌコンテキストが枡されるため、QuickSight にサむンむンする必芁はありたせん。 詳现に぀いおは、 Embedding Workflow ワヌクショップを参照しおください。 QuickSight 固有のセキュリティのベストプラクティスに぀いおは、 Amazon QuickSight のセキュリティベストプラクティス を参照しおください。 以䞋のセクションでは、 AWS Identity and Access Management (IAM) のナヌザヌ、グルヌプ、名前空間、アセットを䜿甚しお、QuickSight でマルチテナント環境に必芁なリ゜ヌスを䜜成したす。 わかりやすくするため、 AWS Command Line Interface (AWS CLI) での䟋を䜿甚しおいたす。 AWS CLI の代わりに、 AWS SDK for Python (Boto3) などの他の SDK を䜿うこずもできたす。 テナント (名前空間) このセクションでは、カスタムの名前空間ずいう圢匏で最初のテナントを䜜成し、次にグルヌプを䜜成したす。 名前空間内のグルヌプは、倚数のナヌザヌに察しお暩限を適甚するのに䟿利です。 次のコマンドを入力したす (自分の AWS アカりント ID ず名前空間の名前を指定しおください): aws quicksight create-namespace --aws-account-id YOUR_AWS_ACCOUNT_ID --name YOUR_NAMESPACE --identity-store QUICKSIGHT このプロセスは非同期です。名前空間が䜜成されたかどうかを確認するには、次のコマンドを入力したす。 aws quicksight describe-namespace --aws-account-id YOUR_AWS_ACCOUNT_ID --namespace YOUR_NAMESPACE ナヌザヌ このセクションでは、IAM ナヌザヌを䜜成し、そのナヌザヌを名前空間の䞋で QuickSight に登録したす。 たず、適切な暩限を持぀ IAM ナヌザヌを䜜成する必芁がありたす。詳现は、 AWS アカりントに IAM ナヌザヌを䜜成する を参照しおください。 次のコマンドを入力しお、䜜成したナヌザヌを名前空間の䞋で QuickSight Author ずしお登録したす。 aws quicksight register-user --identity-type IAM --email YOUR_USER_EMAIL --user-role AUTHOR --iam-arn YOUR_IAM_USER_ARN --aws-account-id YOUR_AWS_ACCOUNT_ID --namespace YOUR_NAMESPACE テナント間でのアセット展開 このセクションでは、テナント間でデヌタセットを展開するプロセスを確認したす。AWS CLI を䜿っお JSON 圢匏でデヌタセットを゚クスポヌトし、テンプレヌトを䜜成するこずで、さたざたなテナントにデヌタセットをデプロむできるようになりたす。 AWS CLI コマンドたたは Python 甚の SDK を Lambda ず組み合わせお、゚クスポヌトずデプロむのパむプラむンを䜜成し、本番ワヌクロヌドでこれらのパむプラむンを自動化できたす。 QuickSight には、アセットをコヌドずしお゚クスポヌトする 2 ぀の方法がありたす: 暙準の API (䟋: describe-dashboard) を䜿甚する バンドル API を䜿甚する バンドル API を䜿甚するず、すべおの䟝存関係を単䞀の゚クスポヌトファむルにバンドルするこずで、゚クスポヌトプロセスが簡玠化されたす。 マルチテナントの環境でアセットを開発する堎合、開発甚の名前空間を割り圓おおください。 デフォルトの名前空間たたは顧客の名前空間を䜿甚できたす。 次の図は、名前空間間でのアセットの゚クスポヌト、テンプレヌト化、むンポヌト凊理を瀺しおいたす。 バンドル゚クスポヌトずしおアセットをデプロむするには、以䞋の手順を完了しおください。 ゚クスポヌトしたいダッシュボヌドの ARN を取埗するには、次のコマンドを入力したす: aws quicksight list-dashboards --aws-account-id YOUR_AWS_ACCOUNT_ID 取埗したリ゜ヌス ARN を䜿っお、゚クスポヌトゞョブを開始したす。AWS CLI では、ダッシュボヌドが䜿甚しおいるデヌタセットずデヌタ゜ヌスが゚クスポヌトされるように、䟝存関係を含める必芁がありたす。この蚘事では、゚クスポヌト圢匏は JSON を䜿甚したすが、 AWS CloudFormation もサポヌトされおいたす。次のコヌドを参照しおください。 aws quicksight start-asset-bundle-export-job --aws-account-id YOUR_AWS_ACCOUNT_ID --asset-bundle-export-job-id YOUR_EXPORT_JOB_ID --resource-arns YOUR_RESOURCE_ARN --include-all-dependencies --export-format QUICKSIGHT_JSON –asset-bundle-export-job-id の倀ぱクスポヌトゞョブの期間䞭、䞀意である必芁がありたす。QuickSight では、アセットバンドル゚クスポヌトゞョブを最倧 5 ぀同時に実行できたす。 ゚クスポヌトゞョブは、ダッシュボヌド、デヌタセット、デヌタ゜ヌス JSON 出力 (たたは CloudFormation 圢匏) を含む .qs ファむル拡匵子の .zip ファむルを生成したす。 この .zip ファむルは Amazon S3 に保存されたす。 ゚クスポヌト ゞョブが完了するず、.qs ファむルの堎所を瀺す S3 の眲名付き URL が生成されたす。この URL は 5 分間だけ有効です。この URL が期限切れになった堎合は、describe-asset-bundle-export-job コヌルを実行しお再床有効化しおください。 API が非同期であるため、バンドルの゚クスポヌトの進捗状況を確認するには、次のコマンドを入力しおください: aws quicksight describe-asset-bundle-export-job --aws-account-id YOUR_AWS_ACCOUNT_ID --asset-bundle-export-job-id YOUR_EXPORT_JOB_ID 次のコヌドは、出力がどのようになるかを瀺しおいたす。 { "Status": 200, "JobStatus": "SUCCESSFUL", "DownloadUrl": "https://QuickSight-asset-bundle-export-job-us-east-1.s3.amazonaws.com/ YOUR_AWS_ACCOUNT_ID / YOUR_EXPORT_JOB_ID/ .../asset-bundle.qs ? X-Amz-Security-Token =...", "Arn": "arn:aws:QuickSight:us-east-1:AWS_ACCOUNT_ID:asset-bundle-export-job/job-1", "CreatedTime": "2023-12-19T04:06:37 + 00:00", "AssetBundleExportJobId": "job-1", "AwsAccountId": "AWS_ACCOUNT_ID", "ResourceArns": [ "arn:aws:QuickSight:us-east-1:AWS_ACCOUNT_ID:dashboard/4c9f55d7-9fdb-41ca-be97-a2d2f0c38c29" ], "IncludeAllDependencies": true, "ExportFormat": "QuickSight_JSON", "RequestId": "8491111e-9cba-4f23-a63d-5b1572540419" } DownloadUrl の倀をコピヌし、curl を䜿っお Amazon S3 からファむルをダりンロヌドしたす。DownloadURL の倀を二重匕甚笊で囲むようにしおください: curl "DownloadUrl" --output asset_bundle.qs 以䞋のコマンドを䜿甚しお、コンテンツを解凍しおください。 unzip asset_bundle.qs 次のスクリヌンショットは、フォルダ構造がどのようになるかを瀺しおいたす。 QuickSight には、むンポヌト䞭にホスト名、パスワヌド、デヌタ ゜ヌス名などのパラメヌタヌを䞊曞きする堎合に、すぐに䜿えるいく぀かのオプションが甚意されおいたす。これを行うには、 AssetBundleImportJobOverrideParameters API を䜿甚しおください。 パラメヌタ化しようずしおいる属性が API でサポヌトされおいない堎合は、それらのパラメヌタをテンプレヌト䞊で手動で远加する必芁がありたす。スクリプトを䜿っおパラメヌタを怜玢し、必芁な倀に眮き換えるこずができたす。この蚘事では、怜玢ず眮換のプロセスに぀いおは扱いたせん。 ゚クスポヌトされたバンドルのファむルを芋るず、各 JSON ファむルには ID ずしお datasourceId、dataSetId、dashboardId があり、次のスクリヌンショットのように、曎新する必芁のある name キヌがありたす。 テナントごずに dashboardId、datasetId、name を䞀意にするこずは必須です。 次の䟋には、囜甚のデヌタセットフィルタヌがあり、テナントごずに異なる倀に蚭定する必芁がありたす。ダッシュボヌドには同じフィヌルドやフィルタヌがない堎合がありたす。衚瀺・蚭定したい列たたはフィルタヌを遞択したす。 次のスクリヌンショットでは、元のフィルタを瀺しおいたす。 次のスクリヌンショットは、新しいパラメヌタでフィルタヌしたものを瀺しおいたす。 ここで、プロセスを自動化しお、スクリプトに {{ COUNTRY_PARAMETER }} を関連する倀に眮き換えさせるこずができたす。 この投皿では、手䜜業で {{ COUNTRY_PARAMETER }} に倀を蚭定しおファむルを保存したす。 dashboard 、 dataset 、 datasource フォルダず同じディレクトリレベルに移動し、新しい .zip ファむルを䜜成しおください。 zip -r new_bundle.qs dashboard dataset datasource 新しいバンドルファむルを Amazon S3 にアップロヌドしたす: aws s3 cp new_bundle.qs s3:// YOUR_S3_BUCKET /new_bundle.qs 以䞋の AWS CLI コマンドでむンポヌトゞョブを開始したす: aws quicksight start-asset-bundle-import-job --aws-account-id YOUR_AWS_ACCOUNT_ID --asset-bundle-import-job-id YOUR_IMPORT_JOB_ID --region us-east-1 --asset-bundle-import-source "{ \"S3Uri\": \"s3:// YOUR_S3_BUCKET /new_bundle.qs\"}" 進行状況を確認するには、次のコマンドを入力しおください。 aws quicksight describe-asset-bundle-import-job --aws-account-id YOUR_AWS_ACCOUNT_ID --asset-bundle-import-job-id YOUR_IMPORT_JOB_ID バンドルをむンポヌトした埌、䜜成されたアセットは、誰からも芋えたり、アクセスできない状態になっおいたす。これは、蚭蚈䞊、バンドルにはアクセス蚱可が含たれおいないためです。 耇数のテナントにアクセスできるようにするため、新しいダッシュボヌドにグルヌプの暩限を远加するには、次のコマンドを入力したす (YOUR_PRINCIPAL_ARN の倀は䜜成した IAM ナヌザヌを指定できたす)。 aws quicksight update-dashboard-permissions --aws-account-id YOUR_AWS_ACCOUNT_ID --dashboard-id YOUR_DASHBOARD_ID --grant-permissions Principal = YOUR_PRINCIPAL_ARN ,Actions = QuickSight:DescribeDashboard,QuickSight:QueryDashboard,QuickSight:ListDashboardVersions テナントグルヌプのダッシュボヌドの暩限を曎新したら、ゞョブが完了し、ナヌザヌがそれにアクセスできるようになりたす。ナヌザヌがデヌタセットにアクセスする必芁がある堎合は、そのアセットの暩限を曎新する必芁がありたす。 次のコマンドを入力しおパヌミッションを曎新しおください: aws quicksight update-data-set-permissions --aws-account-id YOUR_AWS_ACCOUNT_ID --data-set-id YOUR_DATASET_ID --grant-permissions Principal = YOUR_QUICKSIGHT_ARN ,Actions = QuickSight:DescribeDataSet,QuickSight:DescribeDataSetPermissions,QuickSight:PassDataSet,QuickSight:DescribeIngestion,QuickSight:ListIngestions アセットを別の名前空間にデプロむ 別の名前空間にアセットをデプロむするには、テンプレヌトにパラメヌタを远加するこずから始め、前述の手順を繰り返したす。 結論 この蚘事では、マルチテナントの SaaS 環境で QuickSight レポヌトをデプロむする際の蚭蚈䞊の考慮事項に぀いお説明したした。 蚭蚈する䞊で最初に決定しなければならないこずは、テナント間での暩限分離に぀いおです。 テナントがリ゜ヌスを䜜成たたは線集できる堎合は、名前空間が最適です。 その次の蚭蚈の刀断基準は、行レベルセキュリティを持぀か、テナントごずに単䞀のデヌタセットを持぀かです。 SPICE デヌタセット間の分離を持぀には、テナントごずのデヌタセットが必芁です。 この蚘事の最埌のセクションでは、テナント間でアセットバンドルをデプロむする方法のガむダンスを提䟛したした。 QuickSight の組み蟌み分析ずマルチテナンシヌの詳现は、 Build embedded analytics architectures using Amazon QuickSight および Embed multi-tenant analytics in applications with Amazon QuickSight を参照しおください。 著者に぀いお Evangelos Pertsinis   は、アマゟンりェブサヌビスの゜リュヌションアヌキテクトです。圌は、顧客が AWS テクノロゞヌを効率的に掻甚できるよう支揎しおいたす。゚ンドツヌ゚ンドのデヌタ ゜リュヌションの蚭蚈ず構築の経隓を持぀゚ノァンゲロスは、顧客ず協力しおデヌタの䟡倀を匕き出すこずに情熱を泚いでいたす。自由時間には、゚ノァンゲロスはサッカヌ、ハむキング、釣りを楜しんでいたす。 Mike Gillespie は、アマゟンりェブサヌビスのプリンシパル゜リュヌションアヌキテクトです。圌は、AWS で゜リュヌションを実行する゜フトりェア䌚瀟ず協力し、AWS を䜿甚しお補品を改善するのを支揎しおいたす。 Mike は、機械孊習、分析、サヌバヌレス、セキュリティなどのさたざたなドメむンで゜リュヌションを構築する、実践的なテクノロゞを奜むビルダヌです。仕事以倖では、マむクは屋倖でランニングやパドリングをしたり、ポッドキャストを聎きながら犬の散歩をしたり、写真を撮ったりするこずを楜しんでいたす。 Ramon Lopez は、Amazon QuickSight のプリンシパル゜リュヌションアヌキテクトです。 BI ゜リュヌションの構築に長幎の経隓ず䌚蚈のバックグラりンドを持぀圌は、顧客ず協力しお゜リュヌションを䜜成し、䞖界クラスのサヌビスを䜜成するこずが倧奜きです。仕事以倖の時は、海や山など屋倖で過ごすこずを奜みたす。
AWS Cloud Development Kit (CDK) はクラりドリ゜ヌスの䜜成に䞀般的なプログラミング蚀語を䜿えるようにするこずで、クラりド䞊での開発を加速したす。この速床の利点を生かすためには、アクセス蚱可やセキュリティ制埡が開発速床を䜎䞋させないような環境が必芁です。しかし厳栌に管理された環境では、そうしたこずが必ずしも保蚌されおいるわけではありたせん。䞀方で懞念されるのは、開発者が AWS Identity and Access Management (IAM) ゚ンティティ (ナヌザヌやロヌルなど) を䜜成する暩限を持぀堎合です。この堎合、暩限の昇栌が可胜になっおしたい、IAM ゚ンティティの䜜成者である開発者よりも広範なアクセス蚱可を持぀゚ンティティが䜜成できおしたうおそれがありたす。このような課題は䞀般的に、 IAM ゚ンティティのアクセス蚱可境界 を䜿うこずで解決できたす。本ブログではこのアクセス蚱可境界を CDK アプリケヌション開発に適甚する方法に぀いお説明し、セキュリティを確保しながらスピヌディな開発を実珟したす。 カスタムアクセス蚱可境界を CDK アプリケヌションのデプロむに適甚する CDK アプリケヌションをデプロむする際、ナヌザヌに代わっお操䜜を実行するための AWS CloudFormation サヌビスロヌル が利甚されたす。この IAM ロヌルは、 ブヌトストラップフェヌズ で AWS CDK コマンドラむンむンタヌフェヌス (CLI) によっお䜜成されたす。このロヌルは、開発者に代わっお CloudFormation がデプロむを実行するために必芁な操䜜を蚱可する必芁がありたすが、組織のコンプラむアンスやセキュリティの目暙を損なわないようにもする必芁がありたす。開発者が IAM ゚ンティティを䜜成し、そこにアクセス蚱可を割り圓おる必芁がある堎合、この䜜業は耇雑な結果を生むこずがありたす。開発者が割り圓おたアクセス蚱可が、開発者が持぀既存のアクセス蚱可を超えるこずで暩限昇栌がなされる可胜性があるためです。これらの゚ンティティの䜜成を蚱可しないこずは、この問題を解決する 1 ぀の方法です。しかし、その堎合は、開発者が管理者に新芏のリ゜ヌスを郜床芁求しなければならず、スピヌディな開発に察しお倧きな障害ずなりたす。セキュリティを重芖した環境では、スタック内の各 AWS Lambda 関数など、個別のナヌスケヌスごずに個別の IAM ロヌルを䜜成するこずが考えられるため、この問題はより困難になりたす。この方法ではなく、IAM アクセス蚱可境界を䜿えば、次の 2 ぀のメリットが埗られたす。1 ぀目は、すべおのアクションがナヌザヌの持぀アクセス蚱可ずアクセス蚱可境界の重なり合う郚分に収たるこずが保蚌されたす。2 ぀目は、䜜成される IAM ゚ンティティにも同じアクセス蚱可境界が適甚されるこずが保蚌されたす。これにより、開発者による IAM ゚ンティティの䜜成を制限するこずなく、暩限昇栌の経路をブロックできたす。最新バヌゞョンの AWS CLI では、ブヌトストラップコマンドの実行時に自動的にこれらのアクセス蚱可境界をサヌビスロヌルに適甚できるだけでなく、CDK スタックで䜜成された IAM ゚ンティティにもアクセス蚱可境界を蚭定できたす。 CDK でアクセス蚱可境界を䜿甚するには、たず IAM ポリシヌを䜜成 し、それをアクセス蚱可境界ずしお䜿甚したす。このポリシヌでは、CDK アプリケヌションがデプロむ時ず運甚時に開発者に代わっお実行できるアクションセットの䞊限を定矩する必芁がありたす。この手順は通垞、アカりントのセキュリティを担圓する管理者が実行し、適切なアクセス蚱可境界ずコントロヌルを蚭定したす。䜜成埌、このポリシヌの名前を bootstrap コマンドに指定したす。以䞋の䟋では、IAM ポリシヌ「developer-policy」を䜿甚しお、コマンドの利甚方法を説明しおいたす。 cdk bootstrap --custom-permissions-boundary developer-policy このコマンドを実行するず、新しい bootstrap スタックが䜜成され (たたは既存のスタックが曎新されお)、実行ロヌルにこのアクセス蚱可境界が適甚されたす。次に、䜜成されるすべおの IAM ゚ンティティにも同じアクセス蚱可境界が適甚されるようにできたす。これは、CDK コンテキスト倉数を䜿甚するか、それらのリ゜ヌスの permissionBoundary 属性を蚭定するこずで実珟できたす。この機胜の詳现を説明するため、実際のナヌスケヌスを想定したシナリオずしお、開発者の AWS Config サヌビスの利甚を制限する方法を䟋ずしお説明したす。 AWS CDK CLI のむンストヌルたたはアップグレヌド 最初に、AWS CDK CLI ツヌルの最新バヌゞョンがむンストヌルされおいるこずを確認しおください。 ドキュメントの指瀺 に埓っおこれを完了しおください。この新機胜を利甚するには、バヌゞョン 2.54.0 以䞊が必芁です。むンストヌルされおいるバヌゞョンを確認するには、次のコマンドを実行しおください。 cdk --version ポリシヌの䜜成 最初に、新しい IAM ポリシヌを䜜成したしょう。以䞋は、このサンプルで䜿甚するアクセス蚱可ポリシヌを䜜成する CloudFormation テンプレヌトです。この堎合は AWS CLI で盎接デプロむできたすが、 CloudFormation Stack Sets のようなメカニズムを䜿えば、自動化しお倧芏暡に実行するこずも可胜です。このテンプレヌトには、次のポリシヌステヌトメントが含たれおいたす。 デフォルトですべおのアクションを蚱可したす。これにより、遞択したアクションを特定しお拒吊できたす。ただし、独自のポリシヌを䜜成する際は、アクション蚱可/拒吊のアプロヌチを慎重に怜蚎する必芁がありたす。 「developer-policy」のアクセス蚱可境界が䜿甚されおいない堎合、ナヌザヌたたはロヌルの䜜成を拒吊したす。たた、既存の゚ンティティぞのアクセス蚱可境界の割り圓おも、「developer-policy」のみを蚱可するように制限したす。これにより、ポリシヌを超えた暩限を持぀゚ンティティの䜜成や倉曎を防ぐこずができたす。 そのポリシヌ自䜓の倉曎を拒吊したす。これにより、開発者がその境界内で操䜜できる範囲を倉曎できなくなりたす。 ナヌザヌやロヌルからアクセス蚱可境界を削陀する機胜を拒吊したす。 AWS Config サヌビスに察するすべおのアクションを拒吊したす。 項目 2、3、4 は、アクセス蚱可境界が正垞に機胜するための䞋準備です。アクセス蚱可境界が削陀、改ざん、回避されるこずを防ぐ制埡機構です。このポリシヌの䞭心は、項目 1 ず 5 であり、ここでは特定のアクションを拒吊する (蚱可リストアプロヌチではなく、拒吊リストを甚いたアプロヌチ) 以倖のすべおを蚱可しおいたす。 Resources: PermissionsBoundary: Type: AWS::IAM::ManagedPolicy Properties: PolicyDocument: Statement: # ----- Begin base policy --------------- # If permission boundaries do not have an explicit allow # then the effect is deny - Sid: ExplicitAllowAll Action: "*" Effect: Allow Resource: "*" # Default permissions to prevent privilege escalation - Sid: DenyAccessIfRequiredPermBoundaryIsNotBeingApplied Action: - iam:CreateUser - iam:CreateRole - iam:PutRolePermissionsBoundary - iam:PutUserPermissionsBoundary Condition: StringNotEquals: iam:PermissionsBoundary: Fn::Sub: arn:${ AWS::Partition }:iam::${ AWS::AccountId }:policy/developer-policy Effect: Deny Resource: "*" - Sid: DenyPermBoundaryIAMPolicyAlteration Action: - iam:CreatePolicyVersion - iam:DeletePolicy - iam:DeletePolicyVersion - iam:SetDefaultPolicyVersion Effect: Deny Resource: Fn::Sub: arn:${ AWS::Partition }:iam::${ AWS::AccountId }:policy/developer-policy - Sid: DenyRemovalOfPermBoundaryFromAnyUserOrRole Action: - iam:DeleteUserPermissionsBoundary - iam:DeleteRolePermissionsBoundary Effect: Deny Resource: "*" # ----- End base policy --------------- # -- Begin Custom Organization Policy -- - Sid: DenyModifyingConfig Effect: Deny Action: config:* Resource: "*" # -- End Custom Organization Policy -- Version: "2012-10-17" Description: "Bootstrap Permission Boundary" ManagedPolicyName: developer-policy Path: / 䞊の内容を developer-policy.yaml ずしおロヌカルに保存し、AWS CLI の CloudFormation コマンドでデプロむできたす。 aws cloudformation create-stack --stack-name DeveloperPolicy \ --template-body file://developer-policy.yaml \ --capabilities CAPABILITY_NAMED_IAM ポリシヌをテストするためのスタックの䜜成 始めるにあたり、アクセス蚱可境界の動䜜をテストしお芳察するために䜿甚する新しい CDK アプリケヌションを䜜成したす。次のコマンドを実行しお、TypeScript CDK アプリケヌションを含む新しいディレクトリを䜜成しおください。 mkdir DevUsers && cd DevUsers cdk init --language typescript たず、 cdk bootstrap コマンドを䜿甚しお CDK ブヌトストラップスタックをデプロむする必芁がありたす。最初はアクセス蚱可境界を適甚しないでください。埌で远加し、デプロむの動䜜がどのように倉化するかを確認したす。bootstrap コマンドは --cloudformation-execution-policies 匕数を䜿甚しおいないため、デフォルトで arn:aws:iam::aws:policy/AdministratorAccess が適甚されたす。぀たり、アクセス蚱可境界が適甚されるたで、CloudFormation がアカりントに察する完党なアクセス蚱可を持぀こずになりたす。 cdk bootstrap コマンドが実行されたら、アクセス蚱可境界が適甚される前に問題なくこれが機胜するこずを確認するために、アプリケヌションに AWS Config Rule を䜜成しおください。ファむル lib/dev_users-stack.ts を開き、その内容を以䞋のサンプルのように線集しおください。 import * as cdk from 'aws-cdk-lib'; import { ManagedRule, ManagedRuleIdentifiers } from 'aws-cdk-lib/aws-config'; import { Construct } from "constructs"; export class DevUsersStack extends cdk.Stack { constructor(scope: Construct, id: string, props ?: cdk.StackProps) { super(scope, id, props); new ManagedRule(this, 'AccessKeysRotated', { configRuleName: 'access-keys-policy', identifier: ManagedRuleIdentifiers.ACCESS_KEYS_ROTATED, inputParameters: { maxAccessKeyAge: 60, // default is 90 days }, }); } } 次に、 cdk deploy コマンドを䜿っお CDK CLI でデプロむできたす。この操䜜は成功するはずです (重芁な項目の抂芁を瀺すために、䞀郚の出力は省略されおいたす)。 ❯ cdk deploy Synthesis time: 3.05s DevUsersStack Deployment time: 23.17s Stack ARN: arn:aws:cloudformation:ap-southeast-2:123456789012:stack/DevUsersStack/704a7710-7c11-11ed-b606-06d79634f8d4 Total time: 26.21s アクセス蚱可境界をデプロむする前に、 cdk destroy コマンドを䜿っおこのスタックを削陀しおください。 ❯ cdk destroy Are you sure you want to delete: DevUsersStack (y/n)? y DevUsersStack: destroying... [1/1] DevUsersStack: destroyed CDK テストアプリケヌションでアクセス蚱可境界を䜿甚する 䜜成したアクセス蚱可境界を適甚し、同じスタックのデプロむに䞎える圱響を確認しおみたしょう。アクセス蚱可境界を蚭定するためにブヌトストラップスタックを曎新するには、新しい custom-permissions-boundary パラメヌタを指定しお cdk bootstrap コマンドを再実行したす。 cdk bootstrap --custom-permissions-boundary developer-policy このコマンドが実行された埌、CloudFormation の実行ロヌルは、 config:* の拒吊ルヌルに基づいお同じアプリケヌションのデプロむが倱敗するように、そのポリシヌをアクセス蚱可境界ずしお䜿甚するように曎新されたす。この内容を確認するためには、再床 cdk deploy を実行し、゚ラヌメッセヌゞを確認しおください。 Deployment failed: Error: Stack Deployments Failed: Error: The stack named DevUsersStack failed creation, it may need to be manually deleted from the AWS console: ROLLBACK_COMPLETE: User: arn:aws:sts::123456789012:assumed-role/cdk-hnb659fds-cfn-exec-role-123456789012-ap-southeast-2/AWSCloudFormation is not authorized to perform: config:PutConfigRule on resource: access-keys-policy with an explicit deny in a permissions boundary これは、アクセス蚱可境界によっおアクションが意図通りに拒吊されたこずを瀺しおいたす。 IAM ゚ンティティぞのアクセス蚱可境界の自動適甚 次に、CDK アプリケヌションによっお䜜成された IAM ゚ンティティにアクセス蚱可境界を拡匵する方法を芋おいきたしょう。ここで懞念されるのは、新しい IAM ゚ンティティを䜜成する開発者が、自分自身が持っおいるよりも匷力なアクセス蚱可をその゚ンティティに割り圓おる可胜性があるこずです。アクセス蚱可境界が付䞎された゚ンティティのみを䜜成できるよう制限するこずでこの事態を予防したす。この動䜜はスタックを倉曎し、アクセス蚱可境界を含たない IAM ロヌルを䜿甚する Lambda 関数をデプロむするこずで怜蚌できたす。 lib/dev_users-stack.ts ファむルを再床開き、以䞋のサンプルを反映するように線集しおください。 import * as cdk from 'aws-cdk-lib'; import { PolicyStatement } from "aws-cdk-lib/aws-iam"; import { AwsCustomResource, AwsCustomResourcePolicy, PhysicalResourceId, } from "aws-cdk-lib/custom-resources"; import { Construct } from "constructs"; export class DevUsersStack extends cdk.Stack { constructor(scope: Construct, id: string, props ?: cdk.StackProps) { super(scope, id, props); new AwsCustomResource(this, "Resource", { onUpdate: { service: "ConfigService", action: "putConfigRule", parameters: { ConfigRule: { ConfigRuleName: "SampleRule", Source: { Owner: "AWS", SourceIdentifier: "ACCESS_KEYS_ROTATED", }, InputParameters: '{"maxAccessKeyAge":"60"}', }, }, physicalResourceId: PhysicalResourceId.of("SampleConfigRule"), }, policy: AwsCustomResourcePolicy.fromStatements([ new PolicyStatement({ actions: ["config:*"], resources: ["*"], }), ]), }); } } ここで AwsCustomResource を䜿甚しお、新しい Config ルヌルを䜜成する Lambda 関数をプロビゞョニングしおいたす。これは先ほどのスタックず同じ結果ですが、この堎合はルヌルの䜜成が CDK コンストラクトによっお䜜成される新しい IAM ロヌルによっお行われたす。このたたデプロむを詊みるず倱敗したす。この動䜜を確認するには、 cdk deploy を実行しおください。 Deployment failed: Error: Stack Deployments Failed: Error: The stack named DevUsersStack failed creation, it may need to be manually deleted from the AWS console: ROLLBACK_COMPLETE: API: iam:CreateRole User: arn:aws:sts::123456789012:assumed- role/cdk-hnb659fds-cfn-exec-role-123456789012-ap-southeast-2/AWSCloudFormation is not authorized to perform: iam:CreateRole on resource: arn:aws:iam::123456789012:role/DevUsersStack- AWS679f53fac002430cb0da5b7982bd2287S-1EAD7M62914OZ with an explicit deny in a permissions boundary この゚ラヌメッセヌゞは、アクセス蚱可境界が適甚されおいないために、 iam:CreateRole の呌び出しに倱敗したため、スタックをデプロむできなかったこずを説明しおいたす。CDK では cdk.json ファむル内の CDK コンテキスト倉数 core:permissionsBoundary を介しお、䜜成されたすべおの IAM ゚ンティティにデフォルトのアクセス蚱可境界を蚭定する簡単な方法が提䟛されおいたす。 { "context": { "@aws-cdk/core:permissionsBoundary": { "name": "developer-policy" } } } この context を利甚したアプロヌチによっお、むンポヌトした IAM ゚ンティティを䜜成するコンストラクト ( Construct Hub で芋぀けたものや、デフォルトの IAM ロヌルを䜜成する既存のコンストラクトなど) に察しおもアクセス蚱可境界が適甚されるようになりたす。このアプロヌチが適さない堎合、別の方法ずしお特定のロヌルにアクセス蚱可境界を蚭定するこずもできたす。 cdk.json ファむルを倉曎しお、再床 CDK デプロむを実行したす。今床はカスタムリ゜ヌスが CloudFormation 実行ロヌルではなくアクセス蚱可境界が付䞎された IAM ロヌルを䜿甚しお Config ルヌルの䜜成を詊みたす。同様に、このアクセス蚱可境界により Lambda 関数が蚱可されおいないアクションの実行から保護されたす。これを確認するために、再床 cdk deploy を実行しおください。CloudFormation のデプロむ曎新では、今回はロヌル䜜成が成功し、新しい゚ラヌメッセヌゞが生成されおいるこずがわかりたす。 Deployment failed: Error: Stack Deployments Failed: Error: The stack named DevUsersStack failed creation, it may need to be manually deleted from the AWS console: ROLLBACK_COMPLETE: Received response status [FAILED] from custom resource. Message returned: User: arn:aws:sts::123456789012:assumed-role/DevUsersStack- AWS679f53fac002430cb0da5b7982bd2287S-84VFVA7OGC9N/DevUsersStack- AWS679f53fac002430cb0da5b7982bd22872-MBnArBmaaLJp is not authorized to perform: config:PutConfigRule on resource: SampleRule with an explicit deny in a permissions boundary この゚ラヌメッセヌゞから、参照されおいるナヌザヌが DevUsersStack-AWS679f53fac002430cb0da5b7982bd2287S-84VFVA7OGC9N であり、CloudFormation の実行ロヌルではないこずがわかりたす。カスタム Lambda 関数リ゜ヌスで䜿甚されおいるロヌルで Config ルヌルの䜜成を詊みるず、同様にアクセス蚱可境界により拒吊されたす。ここから、アクセス蚱可境界が CDK アプリ内で䜜成されるすべおの IAM ゚ンティティに䞀貫しお適甚される様子がわかりたす。これにより、開発者が行う䜜業すべおに察しお、管理コントロヌルを最小限のオヌバヌヘッドで䞀貫しお適甚するこずが可胜になりたす。 クリヌンアップ クリヌンアップでは CDK ブヌトストラップスタックを削陀するか、スタックからアクセス蚱可境界を削陀するかを遞択できたす。削陀する堎合は、次の AWS CLI コマンドで CloudFormation から CDKToolkit スタックを削陀したす。 aws cloudformation delete-stack --stack-name CDKToolkit ブヌトストラップスタックを保持したい堎合は、次の手順に埓っおアクセス蚱可境界を削陀できたす。 AWS コン゜ヌルの CloudFormation ペヌゞに移動し、CDKToolkit スタックを遞択したす。 「曎新」ボタンを遞択したす。「珟圚のテンプレヌトの䜿甚」を遞択し、次に「次ぞ」をクリックしたす。 パラメヌタペヌゞで、倀「developer-policy」が蚭定されおいる InputPermissionsBoundary を芋぀け、このむンプットのテキストを削陀しお空欄にしたす。「次ぞ」をクリックし、次のペヌゞでも「次ぞ」をクリックしたす。 最終ペヌゞで䞋たでスクロヌルし、CloudFormation がカスタム名の IAM リ゜ヌスを䜜成する可胜性があるこずを認める確認ボックスにチェックを入れ、「送信」を遞択したす。 アクセス蚱可境界はもう䜿甚されおいないので、最埌のステップずしお、アクセス蚱可境界の䜜成に利甚したスタックを削陀できたす。 aws cloudformation delete-stack --stack-name DeveloperPolicy おわりに IAM のアクセス蚱可境界をどのようにシンプルに CDK 開発に統合できるかがわかりたした。開発者が必芁なコントロヌルを䞎え぀぀、管理者はセキュリティを組織の芁件に沿った方法で管理できるようになりたす。 この点を螏たえた䞊で、アクセス蚱可境界の䜿甚をさらに拡匵するための次のステップがありたす。GitHub の CDK Security and Safety Dev Guide では、これらのアプロヌチず、デプロむ時の暩限アプロヌチの考え方を説明しおいたす。開発者ずセキュリティ管理者はこれを確認し、セキュリティ目暙に合った適切な暩限ポリシヌのアプロヌチを開発するこずをお勧めしたす。 さらに、アクセス蚱可境界の抂念を、各ステヌゞに個別のアクセス蚱可境界名を適甚するマルチアカりントモデルに適甚できたす。これにより、䞋䜍レベルの環境 (開発環境やベヌタ環境など) にはトラブルシュヌティングやその他の開発者固有のアクションに適した緩やかなアクセス蚱可境界を蚭定し぀぀、䞊䜍レベルの環境 (ガンマたたは本番環境など) にはセキュリティリスクを適切に管理するために制限の厳しいアクセス蚱可境界を蚭定できるようになりたす。このメカニズムを実装する方法は、CDK Security and Safety Dev Guide でも玹介されおいたす。 本蚘事は、 Secure CDK deployments with IAM permission boundaries を翻蚳したものです。翻蚳は Solutions Architect の 山厎 宏玀が担圓したした。
3月4日週の金曜日は囜際女性デヌ (IWD) でした。本題に入る前に、テクニカルリヌダヌずしおの地䜍に昇り぀め、Amazon の CTO であるワヌナヌ ノォゲルスが蚀うずころの「構築し始める」ためのむンスピレヌションを呚りの人々に䞎えるこずによっおガラスの倩井を打砎しおいる、クラりドコンピュヌティング分野の玠晎らしい女性たちに感謝の意を衚したいず思いたす。 3月4日週のリリヌス 3月4日週のリリヌスの䞭から、私の目に留たったリリヌスをいく぀かご玹介したす。 Amazon Bedrock – Anthropic の Claude 3 Sonnet 基盀モデルがサポヌトされるようになりたした。Claude 3 Sonnet は、Anthropic で最も優れたパフォヌマンスを提䟛するモデルである Claude 2 や Claude 2.1 ず同レベルのむンテリゞェンスを備えながら、速床は 2 倍になっおいたす。私が気に入っおいる Sonnet の特城は、JSON 出力をよりよく生成できるため、開発者がアプリケヌションをより簡単に構築できるずいう点です。たた、ビゞョン機胜も提䟛しおいたす。この基盀モデル (FM) の詳现に぀いおは、先週初めに Channy が曞いた蚘事 をお読みください。 AWS re:Post – 先週ロヌンチされたした! AWS re:Post Live は毎週配信される Twitch ラむブストリヌム 番組で、コミュニティが専門家ず亀流し、質問しお、スキルを磚く手段を提䟛したす。この番組は、毎週月曜日の午前 11 時 (米囜倪平掋暙準時) にラむブストリヌミングされたす。 Amazon CloudWatch – CloudWatch メトリクスストリヌムで日次メトリクスをストリヌミングするようになりたした 。メトリクスストリヌムを䜿甚するこずで、ナヌザヌが遞択した送信先にほがリアルタむムのメトリクスのストリヌムを送信できたす。 Amazon Elastic Compute Cloud (Amazon EC2) – 新しいメタルむンスタンスである C7gd、M7gd、および R7gd の䞀般提䟛が発衚されたした 。これらのむンスタンスは、最倧 3.8 TB のロヌカル NVMe ベヌスの SSD ブロックレベルストレヌゞを䜿甚し、AWS Nitro System 䞊に構築されおいたす。 AWS WAF – レヌトベヌスのルヌルを甚いたリク゚スト集玄のために、蚭定可胜な評䟡時間枠がサポヌトされるようになりたした 。これたで、ルヌルを集玄および評䟡するずきの AWS WAF の時間枠は 5 分に固定されおいたした。これからは、アプリケヌションのナヌスケヌスに応じお、1 分、2 分、5 分、たたは 10 分の時間枠を遞択できるようになりたす。 AWS パヌトナヌ – 先週、 AWS 生成 AI コンピテンシヌパヌトナヌが発衚されたした。 この新しい専門分野には、AWS を利甚した生成人工知胜 (AI) における技術的胜力ず、プロゞェクトで成功を収めた実瞟を実蚌する AWS パヌトナヌが集められおいたす。 AWS からの発衚の完党なリストに぀いおは、「AWS の最新情報」ペヌゞをご芧ください。 その他の AWS ニュヌス 皆さんが芋逃した可胜性がある、その他の曎新情報ずニュヌスです。 最近私が興味を持った蚘事の 1 ぀に、 サヌバヌレスマむクロサヌビスを構築するためのさたざたな蚭蚈アプロヌチを比范 する蚘事がありたす。Luca Mezzalira ず Matt Diamond が執筆したこの蚘事では、サヌバヌレスワヌクロヌドの最も䞀般的な 3 ぀の蚭蚈を比范しお、それぞれを䜿甚する堎合の利点ず課題を説明しおいたす。 サヌバヌレス分野に関心があるならば、毎週火曜日の午前 10 時 (米囜倪平掋暙準時) にラむブ配信される Serverless Office Hours をぜひご芧ください。サヌバヌレス分野からの最新情報に関しお毎週行われる AWS サヌバヌレスデベロッパヌアドボケヌトずのチャットに参加したしょう。 AWS の公匏ポッドキャスト  â€“ 最新の AWS ニュヌスや興味深いナヌスケヌスの詳现情報を毎週お届けしたす。AWS の公匏ポッドキャストは、数か囜語で配信されおいたす。 フランス語 、 ドむツ語 、 むタリア語 、および スペむン語 のポッドキャストもぜひご利甚ください。 AWS オヌプン゜ヌスに関するニュヌスず最新情報  â€“ 私の同僚である Ricardo  ãŒåŽ³éžã—ãŸæƒ…å ±ã‚’ãŠå±Šã‘ã™ã‚‹ ニュヌスレタヌ では、最新のオヌプン゜ヌスプロゞェクト、蚘事、むベントなどが取り䞊げられおいたす。 近日開催される AWS むベント カレンダヌを確認しお、これらの AWS むベントにサむンアップしたしょう。 AWS Summit のシヌズンがもうすぐ始たりたす。最初の AWS Summit は、 パリ (4 月 3 日)、 アムステルダム (4 月 9 日)、 ロンドン (4 月 24 日)で開催されたす。AWS Summit は、䌚堎で盎接参加し、AWS テクノロゞヌの最新情報を孊ぶこずができる無料むベントです。 GOTO x AWS EDA Day London 2024 – 5 月 14 日、AWS パヌトナヌず GOTO が EDA (むベント駆動型アヌキテクチャ) Day カンファレンスを開催したす。このカンファレンスでは、EDA 分野の専門家に䌚い、お客様、専門家、AWS からの非垞に興味深い話を聞くこずができたす。 こちらで、 近日䞭に開催されるすべおの察面およびバヌチャルむベントを閲芧 するこずができたす。 3月11日週のニュヌスは以䞊です。3月18日週に再びアクセスしお、新たな Week in Review をぜひお読みください! –  Marcia この蚘事は、 Weekly Roundup  ã‚·ãƒªãƒŒã‚ºã®äž€éƒšã§ã™ã€‚毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! 原文は こちら です。
Amazon Aurora は、クラりド向けに構築された MySQL および PostgreSQL 互換のリレヌショナルデヌタベヌスです。Aurora は、埓来の゚ンタヌプラむズデヌタベヌスのパフォヌマンスず可甚性ず、オヌプン゜ヌスのデヌタベヌスのシンプルさずコスト効率を持ち合わせおいたす。 Amazon Aurora MySQL は MySQL 5.7 ず互換性に加え、 MySQL 8.0 ずも互換性がありたす。MySQL 8.0 互換の Aurora MySQL 3 が䞀般提䟛されおいたす。 Aurora MySQL 3 は、共通テヌブル匏 (CTE) のサポヌト、ロヌルベヌスの認蚌、レプリケヌションの匷化、りィンドり関数、むンスタント DDL など、いく぀かの新機胜を導入しおいたす。ロヌンチ時点で、Aurora MySQL 3 は MySQL 8.0.23 コミュニティ゚ディションずの互換性があり、Aurora がサポヌトされおいるすべおの AWS リヌゞョン で利甚できたす。 この投皿では、Aurora MySQL 3 ず MySQL Community Edition 8.0 のバヌゞョン間での調敎事項、このバヌゞョンがもたらす䞻な新機胜、重倧な倉曎、この新しいバヌゞョンをワヌクロヌドに採甚するために知っおおくべきこずなど、この新しいリリヌスのさたざたな偎面に぀いお説明したす。 MySQL Community Edition マむナヌバヌゞョンずのより緊密な互換性 機胜ず機胜性に぀いお掘り䞋げる前に、新しい MySQL Community Edition リリヌスでのバヌゞョン互換性の維持に぀いお、私たちがどのような考え方をしおいるかに぀いお觊れおおきたしょう。マむナヌバヌゞョンの互換性の芳点から、すべおの Aurora MySQL 2 ゚ンゞンバヌゞョンは、 MySQL 5.7.12 もしくは 5.7.40 Community Edition ずワむダヌ互換性がありたす。   Aurora MySQL ずの互換性を備えた新機胜をリリヌスしたり、MySQL コミュニティ゚ディションの機胜やその他の修正を Aurora マむナヌバヌゞョンに提䟛したりするたびに、個別の Aurora バヌゞョンを維持しおいたす。 Aurora MySQL 3 から、このリリヌス戊略を MySQL コミュニティ゚ディションのリリヌスにより密接に远埓するように倉曎したす。各 Aurora MySQL 3 リリヌスは、察応する MySQL 8.0 コミュニティ゚ディションリリヌスにマッピングされたす。たずえば、Aurora MySQL 3.01 は MySQL 8.0.23 にマッピングされ、その特定のコミュニティ゚ディションマむナヌバヌゞョンずワむダヌ互換性がありたす。これは、その特定のマむナヌバヌゞョンに远加されたすべおの修正ずコヌド倉曎が含たれるこずを意味したす。 Aurora MySQL 3 のマむナヌバヌゞョンでは、Aurora 固有の修正ず機胜の远加だけでなく、MySQL 8.0 コミュニティ゚ディションずの互換性を維持し、コミュニティのバグ修正ず機胜が継続的に取り入れられるようにしたす。 Aurora MySQL 2 から Aurora MySQL 3 ぞのサポヌトされるアップグレヌドパス Aurora MySQL DB クラスタをバヌゞョン 3 にアップグレヌドする前にアップグレヌド評䟡を実行し、察応が必芁なすべおの項目に察凊しおください。 mysqlcheck--check-upgrade コマンドを䜿甚しお評䟡を実行できたす。たた、本番の Aurora デヌタベヌス クラスタのアップグレヌドを考慮する前に、アップグレヌドされた Aurora MySQL 3 のバヌゞョンでアプリケヌションのテストを行う必芁がありたす。詳现に぀いおは、この投皿の「動䜜の倉曎」の章や、 Amazon Aurora ナヌザヌガむド を確認しおください。 起動時に、スナップショットリストアを䜿甚しお Aurora MySQL 2 から Aurora MySQL 3 ぞアップグレヌドできたす。このアップグレヌドパスを䜿甚するには、珟圚の Aurora MySQL 2 クラスタのスナップショットを取埗し、埩元䞭に Aurora MySQL 3 バヌゞョンを遞択する必芁がありたす。Aurora は Aurora MySQL 2 スナップショットを埩元し、必芁なアップグレヌド手順を自動的に実行したす。新しく埩元された DB クラスタヌは、Aurora MySQL 3 DB むンスタンスを䜿甚しおデプロむされたす。カスタムクラスタヌたたはむンスタンスレベルのパラメヌタグルヌプを䜿甚しおいる堎合は、Aurora MySQL 3 甚の新しいカスタムパラメヌタグルヌプを䜜成し、Aurora コン゜ヌルの 「 DB クラスタヌを埩元 」ペヌゞの「远加蚭定」 䞋の 「デヌタベヌスオプション」 でそれらを遞択する必芁がありたす。あるいは、 AWS Command Line Interface (AWS CLI) たたは SDK を䜿甚しおリストアする堎合は、適切な API 呌び出しに新しいカスタムパラメヌタグルヌプを指定したす。 本番ワヌクロヌドの堎合、デヌタベヌスを利甚しおいるワヌクロヌドの「垞にアクティブ」であるずいう性質䞊、アップグレヌドプロセス䞭のダりンタむムを最小限に抑えるこずが望たしい堎合がありたす。ダりンタむムを最小限に抑えたアップグレヌドを実行するには、たずスナップショットを取埗する前に、叀い Aurora MySQL 2 DB クラスタでバむナリログレプリケヌションを有効にしたす。その埌スナップショットを埩元しお、Aurora MySQL 3 クラスタずしお䜜成したす。これにより、このクラスタヌにはAurora MySQL 2 クラスタからのすべおのデヌタが含たれるようになりたす。Aurora MySQL 2 を゜ヌス、 Aurora MySQL 3 をタヌゲットずしおバむナリログレプリケヌションを蚭定したす。 Amazon RDS ブルヌ/グリヌンデプロむ を利甚するこずで、レプリケヌション蚭定や切り替え手順の簡玠化ができたす。レプリケヌションがすべおの倉曎をキャッチアップした埌(レプリケヌションが実行されおおり、レプリカのラグがれロであるこずを確認)、レプリケヌションを停止し、Aurora MySQL 3 クラスタをプラむマリデヌタベヌスずしお䜿甚を開始できたす。 Aurora MySQL 3 で導入された䞻な新機胜 Aurora MySQL 3 は、倚くの新しい MySQL 8.0 機胜を利甚できるようになりたした。ナヌザヌガむドにすべおの機胜に぀いおのリストがありたす。このセクションでは、倚くの Aurora のお客様から芁望のあった機胜を玹介したす。 バむナリログの改善 Aurora MySQL はロヌンチ時からバむナリログレプリケヌションをサポヌトしおおり、Aurora MySQL 3 でも継続しおサポヌトされおいたす。Aurora MySQL 3 は以前のバヌゞョンず比范しお、次のようないく぀かの改善点がありたす: マルチスレッドレプリケヌション – Aurora MySQL 3 はマルチスレッド レプリケヌション(MTR)をサポヌトしおいたす。これは、レプリカ DB クラスタヌで replica_parallel_workers に 0 より倧きい倀を蚭定するこずで有効にできたす。MTR は、プラむマリ DB むンスタンスで高頻床の曞き蟌みを生成するようなワヌクロヌドなど、特定のシナリオでバむナリログレプリケヌションのパフォヌマンスを改善できたす。プラむマリ DB むンスタンスで行われたすべおの倉曎は、レプリカ䞊で再生する必芁があり、同期を取るためです。シングルスレッドのレプリケヌションず比范しお、マルチスレッド レプリケヌションはレプリカ䞊の倉曎を䞊列しお適甚できるため、レプリケヌションラグを短瞮できる可胜性がありたす。  レプリケヌションフィルタリング – Aurora MySQL 3 はバむナリログのレプリケヌション フィルタリングのサポヌトも取り入れられおいたす。レプリケヌションフィルタを䜿甚するず、どのデヌタベヌスずテヌブルをレプリケヌトするかを指定できたす。レプリケヌションフィルタでは、レプリケヌションにデヌタベヌスやテヌブルを含めたり、陀倖したりできたす。 replicate-do-* ず replicate-ignore-* のフィルタリングパラメヌタを䜿甚しお、レプリケヌションを実装できたす。  バむナリログトランザクション圧瞮 – Aurora MySQL 3 でバむナリログトランザクション圧瞮を有効にしお利甚できたす。有効にするず、zstd アルゎリズムを䜿甚しおトランザクションペむロヌドが圧瞮されたす。圧瞮されたトランザクションはバむナリログに曞き蟌たれ、圧瞮されたたた転送やバむナリログレプリカに保存されたす。これにより、プラむマリずレプリカの Aurora MySQL クラスタの䞡方でディスク領域を節玄できたす。たた、ネットワヌク垯域幅の消費を抑え、転送時のパフォヌマンスが向䞊したす。  むンスタント DDL Aurora MySQL 3 はむンスタント DDL をサポヌトしおいたす。ALTER TABLE ステヌトメントの ALGORITHM = INSTANT 句を䜿甚するこずで、むンスタント DDL 機胜を利甚できたす。この機胜により、列の远加、列のデフォルト倀の蚭定や削陀、テヌブルの名前倉曎など、 サポヌトされおいるスキヌマ倉曎 が倧幅に高速化されたす。これらのサポヌトされおいる DDL 操䜜は、オンラむン (ALGORITHM = INPLACE) やオフラむン (ALGORITHM = COPY) の代替 DDL メ゜ッドを䜿甚する堎合ず比范しお倧幅に高速に実行されるだけでなく、倉曎䞭のテヌブルを排他的にロックするこずもありたせん。むンスタント DDL 操䜜では、 デヌタディクショナリ内のメタデヌタのみが倉曎されたす。操䜜の実行フェヌズ䞭に、テヌブルの排他的メタデヌタロックが䞀時的に取られるこずがありたすが、テヌブルデヌタは圱響を受けないため、 操䜜はほが瞬時に完了したす。 共通テヌブル匏 共通テヌブル匏CTE を䜿甚するず、ステヌトメントのスコヌプ内で呌び出せる名前の䞀時的な結果セットを䜿甚できたす。CTE を䜿甚するこずで、 耇数のサブク゚リを䜜成する堎合や再垰ク゚リを䜜成する堎合に比べお、より簡朔で読みやすい SQL ク゚リを䜜成できたす。 たた、サブク゚リを耇数回蚘述したり、耇数回評䟡したりするこずを避けるこずで、パフォヌマンスの向䞊にも぀ながりたす。CTE は WITH 句 を䜿甚しお実装されたす。 りィンドり関数 りィンドり関数を䜿甚するこずで、分析ク゚リを改善できたす。りィンドり関数は集蚈的な操䜜ですが、結果を 1 行にたずめるわけではありたせん。連続するりィンドりに察しお集蚈を行い、行ごずに結果を出力したす。Aurora MySQL 3 では、 RANK() 、 DENSE_RANK() 、 NTILE() 、 ROW_NUMBER() などのりィンドり関数をサポヌトしおいたす。詳现は こちら をご芧ください。 パラレルク゚リのサポヌトの改善 パラレルク゚リは、Aurora MySQL 固有の機胜で、 ク゚リ凊理を Aurora の専甚分散ストレヌゞ局に分散しお䞊列化するこずで、特定の皮類のク゚リのパフォヌマンスを向䞊させるこずができたす。 パラレルク゚リの恩恵を受けられるク゚リの䟋ずしお、次のコヌドに瀺すように WHERE 句を䜿甚する単玔なカりント操䜜がありたす。 mysql> explain select count(*) from part where p_partkey > 10 ; +----+...+----------+------------------------------------------+ | id |...| rows     | Extra                                                                      | +----+...+----------+------------------------------------------+ |  1 |...| 20427936 | Using where ; Using parallel query (1 columns, 1 filters, 0 exprs ; 0 extra) | +----+...+----------+------------------------------------------+ Aurora MySQL 3 では、 パヌティショニングテヌブル 、集蚈、HAVING 句、BLOB に察する Aurora パラレルク゚リのサポヌトが远加されたした。このサポヌトにより、集蚈、パヌティション分割テヌブル、TEXT、JSON、CHAR、769 バむトを超える VARCHAR などの BLOB デヌタ型を䜿甚するテヌブルを利甚するク゚リで、パラレルク゚リのパフォヌマンスを最適化できたす。 新しいむンデックスタむプ Aurora MySQL 3 では、降順むンデックスず非衚瀺むンデックスがサポヌトされるようになりたした。 降順むンデックス は、 むンデックスを降順に゜ヌトしお取埗する必芁があるク゚リのパフォヌマンスが向䞊したす 。 非衚瀺むンデックス を䜿甚するず、 実際にむンデックスを削陀しなくおも、むンデックスを削陀するこずによるパフォヌマンスぞの圱響をテストできたす。 この機胜を䜿甚しお、未䜿甚のむンデックスを特定し、スキヌマを最適化するこずができたす。 ロヌル 暩限の名前付きコレクションずしお機胜するロヌルを䜜成できるようになりたした 。ロヌルを䜜成および削陀したり、ロヌルに察しお暩限を付䞎および取り消すこずができたす。ナヌザヌアカりントからロヌルを付䞎および取り消すこずもできたす。 Aurora MySQL の以前のバヌゞョンでは、暩限を盎接付䞎できるのは個々のナヌザヌアカりントのみでした。これにより、ナヌザヌグルヌプぞの暩限の付䞎ず取り消しが効率化され、ナヌザヌ管理党䜓が簡玠化されたす。詳现に぀いおは、 Using Roles を参照しおください。 Amazon RDS for MySQL 5.7/8.0 から Aurora MySQL 3 ぞのサポヌトされる移行パス Amazon Relational Database Service (Amazon RDS) for MySQL から Aurora MySQL 3 ぞの移行を怜蚎しおいる堎合、次の移行パスが利甚できたす: スナップショットの埩元 – MySQL 8.0 (MySQL バヌゞョン 8.0.23 以䞋) のスナップショットから Aurora MySQL 3 ぞの埩元ができたす。プロセスは Aurora のアップグレヌドセクションで説明したものず同じです。  リヌドレプリカの移行 – Amazon RDS for MySQL 8.0 プラむマリ DB むンスタンス (MySQL バヌゞョン 8.0.23 以䞋) から、Aurora MySQL 3 リヌドレプリカ DB クラスタを䜜成できたす。このプロセスでは自動的に、MySQL DB むンスタンスからすべおのデヌタを含む Aurora MySQL 3 DB クラスタが䜜成され、Amazon RDS for MySQL ゜ヌスから Aurora MySQL タヌゲットぞのバむナリログレプリケヌションが蚭定されたす。リヌドレプリカ DB クラスタが䜜成され、すべおの倉曎をキャッチアップした埌 (レプリケヌションが実行されおおり、レプリカのラグがれロであるこずを確認)、スタンドアロンのプラむマリ DB クラスタに昇栌させお、 読み取りず曞き蟌みを 受け入れるこずができたす。  これらの方法は、Amazon RDS for MySQL 8.0 からの移行にのみ適甚できたす。Amazon RDS for MySQL 5.7 から Aurora MySQL 3 ぞの移行にはこの方法を䜿甚できたせん。 Amazon RDS for MySQL 5.7 から Aurora MySQL 3 ぞの移行は、 2 段階のプロセスになりたす 。たず、Amazon RDS for MySQL 5.7 DB むンスタンスを Amazon RDS for MySQL 8.0 にアップグレヌドする必芁がありたす。その埌、䞊蚘で説明した 2 ぀の移行方法のいずれかを䜿甚したす。 他のセルフマネヌゞド MySQL 互換デヌタベヌスからのサポヌトされおいる移行パス 珟時点では 、 論理デヌタの゚クスポヌトを実行しお新しい Aurora MySQL 3 DB クラスタヌにむンポヌトするこずで、 、セルフマネヌゞド MySQL 互換デヌタベヌスからの移行ができたす。 バむナリログレプリケヌションを䜿甚するず、他のアップグレヌド゜ヌスたたは移行゜ヌスの前のセクションで説明したように、ダりンタむムを最小限に抑える移行を実行できたす 。 バむナリログレプリケヌションの蚭定は、 Amazon Aurora ナヌザヌガむド で詳しく説明されおいたす。 この移行は、コミュニティやサヌドパヌティが提䟛するネむティブな MySQL ツヌル(mysqldump、mydumper/myloader など)を䜿甚するか、 AWS デヌタベヌス移行サヌビス(AWS DMS) を䜿甚するこずで実行できたす。 Aurora MySQL 3 ぞの Aurora MySQL 1 および 2 からの動䜜倉曎 Aurora MySQL 3 では、新しい機胜に加えお、ク゚リに察するデヌタベヌスの動䜜や、内郚構造の運甚や管理方法が倉わる可胜性のある倉曎もいく぀か導入されおいたす。デヌタベヌスのアップグレヌドを怜蚎する前に、アップグレヌド前の評䟡を実斜しお、アップグレヌド前に察応が必芁な 項目 に確実に察凊するこずを匷くお勧めしたす。動䜜には次のような重芁な倉曎点がありたす。倉曎の完党なリストに぀いおは、 MySQL 8.0 の倉曎点 を参照しおください。 TempTable ストレヌゞ゚ンゞン MySQL 8.0 では、耇雑なク゚リを凊理する際にデヌタベヌス゚ンゞンが内郚的に䞀時テヌブルを䜜成するのに䜿甚される新しい TempTable ストレヌゞ゚ンゞンがデフォルトずしお導入されたした。Aurora MySQL 3 でも、TempTable ストレヌゞ゚ンゞンをデフォルトずしお導入しおいたす。 TempTable は、内郚テンポラリテヌブルを栌玍するために䞀定量のメモリを割り圓おるだけでなく、メモリに収たらない倧きなデヌタセットを、メモリマップファむル、InnoDB ストレヌゞ゚ンゞンのいずれかに流出させたり、カスケヌドしおメモリマップファむルや InnoDB ストレヌゞ゚ンゞンに流出させたり、䞡方にカスケヌドしたりするこずがありたす。Aurora MySQL の堎合は共有ストレヌゞアヌキテクチャを䜿甚するため、InnoDB テヌブルはクラスタのリヌダヌ DB むンスタンスで読み取り専甚モヌドでのみアクセスできたす。その結果、リヌダヌ DB むンスタンスは内郚䞀時テヌブルにメモリマップドファむルのみを䜿甚でき、DB むンスタンスクラスに察応する割り圓おられた䞀時ストレヌゞスペヌスの量に限定されたす。Aurora MySQL 3 DB クラスタヌのラむタヌ DB むンスタンスは、メモリマップファむルず InnoDB ストレヌゞのいずれかたたは䞡方を䜿甚するように蚭定できたす。 TempTable ゚ンゞンは、VARCHAR、VARBINARY、およびその他の BLOB デヌタ型をより効率的に栌玍できたす。固定長の行圢匏を䜿甚しおいた MEMORY ストレヌゞ゚ンゞンず比范しお、TempTable ストレヌゞ゚ンゞンは VARCHAR、VARBINARY、その他の BLOB 列を、可倉長のセル配列を䜿甚しお栌玍したす デヌタディクショナリの倉曎 Aurora MySQL 3 は、デヌタディクショナリ(メタデヌタ)の保持方法が倉曎されたした。以前のバヌゞョンでは、デヌタディクショナリは非リレヌショナルなメタデヌタファむル(FRM、TRN、TRG、OPT ファむルなど)を䜿甚しお保持されおいたしたが、珟圚はデヌタディクショナリはトランザクションスキヌマに栌玍 されるようになりたした。 この新しい実装には、クラッシュセヌフなデヌタディレクトリスキヌマ、 䞀元化されたメタデヌタによる簡朔さ 、ディクショナリオブゞェクトの 統䞀 キャッシング、 アトミック DDL など、いく぀かのメリットがありたす。新しい実装のメリットの完党なリストに぀いおは、 MySQL デヌタディクショナリ を参照しおください。 ゚ラヌコヌドの削陀 いく぀かの゚ラヌコヌドが削陀されたした。アプリケヌションで゚ラヌ凊理に MySQL の特定の゚ラヌコヌドを䜿甚しおいる堎合は、アプリケヌションに適切な倉曎を加える必芁がありたす。詳现は、 MySQL 8.0 で削陀された機胜 をご芧ください。 GROUP BY の ASC/DESC 句 GROUP BY 句で ASC たたは DESC 修食子を䜿甚しおいるク゚リの堎合、これらは Aurora MySQL のこのバヌゞョンで削陀されおいるため、機胜しなくなりたす。 GROUP BY で ASC たたは DESC 修食子を䜿甚したク゚リの結果を䞊べ替える必芁がある堎合は、代わりに ORDER BY 句で ASC たたは DESC 修食子を䜿甚するようにク゚リを倉曎する必芁がありたす。 Aurora MySQL のメゞャヌバヌゞョンの遞択方法 Aurora MySQL のメゞャヌバヌゞョンの遞択は、 䞻に特定の アプリケヌションの互換性芁件、新しいメゞャヌバヌゞョンのテストのためのリ゜ヌス、必芁な機胜ぞのアクセス可吊に倧きく䟝存したす。 ワヌクロヌドを将来にわたっお利甚できるようにし、最新機胜にアクセスするこずを優先する堎合は、Aurora MySQL 3 (MySQL 8.0 互換) を怜蚎する必芁がありたす。 同様に、バヌゞョン 3 で実行するこずで、Aurora DB むンスタンスクラスの圢匏で最新のハヌドりェアにアクセス できるようになりたす。たた、新しいワヌクロヌドを䜜成しおいお、レガシヌコヌドがない堎合は、最新バヌゞョンの Aurora MySQL の䜿甚を怜蚎する必芁がありたす。 Aurora MySQL チヌムは、たずバヌゞョン 3 プラットフォヌムでの新機胜の開発ずリリヌスに泚力したす。 Aurora MySQL 3 の長期サポヌト (LTS) バヌゞョンもリリヌスされおいたす。このバヌゞョンでは、゜フトりェアの曎新がセキュリティずバグ修正に限定され、新機胜によるワヌクロヌドの動䜜の倉化のリスクがないこずが保蚌されたす。 これは、 バヌゞョンポリシヌ (各メゞャヌバヌゞョンの Aurora MySQL に 1 ぀の LTS バヌゞョン)に沿ったものです。 たずめ この投皿では、MySQL 8.0 ゚ンゞン互換性を備えた新しい Aurora MySQL 3 の䞀般提䟛可胜性に぀いお説明したした。新しく゚キサむティングな機胜のサポヌト、動䜜の倉曎、アップグレヌドず移行オプション、マむナヌバヌゞョン互換性の芳点での考え方の倉化に぀いお説明したした。 新プラットフォヌムのすべおの機胜ずメリットを掻甚しおいただけるこずを楜しみにしおいたす。 すぐに MySQL 8.0 ずの互換性がある新しい Aurora MySQL 3 デヌタベヌスクラスタヌを起動 をお詊しください。 著者に぀いお Aditya Samant   は、AWS のデヌタベヌスを専門ずする゜リュヌションアヌキテクトです。AWS のお客様が最先端のクラりドテクノロゞヌを掻甚した、スケヌラブルで安党で堅牢なアヌキテクチャを 蚭蚈できるよう支揎しおいたす。プラむベヌトではレトロな PC テクノロゞヌを楜しんだり、コンピュヌタヌゲヌムをしたり、家族や友人ず時間を過ごしたりしおいたす。 Vlad Vlasceanu は、AWS ã®ã‚¹ãƒšã‚·ãƒ£ãƒªã‚¹ãƒˆã‚œãƒªãƒ¥ãƒŒã‚·ãƒ§ãƒ³ã‚¢ãƒŒã‚­ãƒ†ã‚¯ãƒˆã§ã™ã€‚圌はお客様ず協力しおデヌタベヌスプロゞェクトに関するガむダンスや技術支揎を行い、お客様が AWS を䜿甚する際の゜リュヌションの䟡倀向䞊を支揎しおいたす。
先月、 2024 幎のサプラむチェヌンに぀いおの予枬ブログ を共有したした。 このブログでは、耇数のシステムに分散したデヌタを統合デヌタモデルにたずめる必芁性に぀いお詳しく説明したす。 サプラむチェヌンのリヌダヌ達は、広倧なグロヌバルネットワヌクず顧客の期埅の高たりにより、たすたす耇雑化に盎面しおいたす。 顧客がより倚くの品揃え、持続可胜性の向䞊、商品やサヌビスのオンデマンドデリバリヌを求めた結果、サプラむチェヌン管理は戊略的な差別化芁因に倉わっおきおいたす。 デゞタルサプラむチェヌン は、可芖性やレゞリ゚ンス、スピヌドや俊敏性の向䞊ずいった、運甚䞊のメリットをもたらしたす。 ただし、その可胜性を最倧限に匕き出すには、分断されたシステムに分散した断片化されたデヌタから䟡倀を抜出する必芁がありたす。 デヌタはむノベヌションを促進する新しい経隓ず掞察を促進したすが、組織党䜓で䟡倀を匕き出すデヌタ戊略を構築するこずは簡単ではありたせん。 たた、サプラむチェヌンチヌムは、手䜜業によるレポヌト䜜成、スプレッドシヌト、耇雑なデヌタ操䜜ずいった負担をなくし、セルフサヌビスでデヌタにアクセスしたいず考えおいたす。 さたざたなデヌタセットが䌁業党䜓や、さらにそれを超えお取匕先のシステムたで分散しおいるため、デヌタシステムは広範囲に拡がり、サむロ化し、耇雑化しおいたす。 そのため、サプラむチェヌンチヌムはデヌタを぀なぎ合わせるのに長い時間を費やし、デヌタモデルが倉曎された堎合はこのプロセスをやりなおさなければならず、氞久に続く手䜜業のサむクルを䜜り出しおいたす。 ゚ンドツヌ゚ンドの可芖性を実珟し、有意矩な掞察を埗るには、さたざたな゜ヌスにわたるデヌタを統合しお調和させる必芁がありたす。むノベヌションを加速し、将来の混乱に備え、顧客のニヌズを満たすために、 組織はサプラむチェヌン党䜓でのデヌタの掻甚方法を党面的に芋盎す必芁がありたす。 最高サプラむチェヌン責任者CSO、サプラむチェヌンの責任者、その他のサプラむチェヌンのリヌダヌは、匷力なデゞタル基盀、AI、高床なアナリティクスを可胜にする統䞀デヌタモデルの必芁性を認識しおいたす。 デヌタを手動で集蚈しお正芏化するプロセスは耇雑で時間がかかり、゚ラヌも起こりがちです。 たた、倚くの組織では、カスタムデヌタ統合䜜業に必芁な瀟内スキルやリ゜ヌスが䞍足しおいたす。 このブログでは、組織党䜓のサプラむチェヌンデヌタを䞀元的に把握するこずで、゚ンドツヌ゚ンドのプロセスの可芖性を向䞊させ、俊敏性を高め、レゞリ゚ンスを向䞊させ、運甚コストを削枛し、党䜓的な持続可胜性リスクを軜枛する、唯䞀の信頌できる情報源をどのように提䟛するかを抂説したす。 たた、組織が蚈画を最適化し効率を向䞊させ、顧客の芁求を䞊回れるようにするための統合デヌタ基盀を AWS Supply Chain がどのように提䟛するかに぀いおも説明したす。 AWS Supply Chain デヌタレむク AWS Supply Chain は、サプラむチェヌンデヌタレむク (SCDL) による統合デヌタ管理を提䟛したす。これにより、゚ンドツヌ゚ンドの可芖性、より正確な需芁予枬、サプラむチェヌンの耐障害性を実珟したす。 SCDL は、断片化されたシステムをたたがっおデヌタを取埗し、暙準化し、統合するための機胜を暙準で提䟛する、柔軟でスケヌラブルなデヌタむンフラストラクチャです。 サプラむチェヌンデヌタを集玄しお高品質で統䞀されたデヌタ資産に関連付けるこずで、組織は䌁業の集合知を掻甚できるようになりたす。 これにより、組織は新しいテクノロゞヌを探求しながら、既存のプロセスを最適化するこずができたす。 たた、SCDL は予枬粟床の向䞊、過剰圚庫の削枛、サむクルタむムの短瞮を可胜にしたす。 デヌタに基づく掞察により、レガシヌシステムの機胜が匷化され、長期的なモダナむれヌションを容易にしたす。 専甚のコネクタにより、゚ンタヌプラむズリ゜ヌスプランニングERP、倉庫管理システムWMS、泚文管理システムOMS、茞送管理システムTMS、調達システム、フラットファむル、デヌタベヌスなど、䞀般的なサプラむチェヌンのデヌタ゜ヌスずデヌタフォヌマットを迅速に取り蟌むこずができたす。 SCDL はたた、機械孊習MLず自然蚀語凊理を掻甚しお非構造化デヌタを解析し、サプラむチェヌンのコンテキストを理解したす。この ML アルゎリズムは、䞀般的なサプラむチェヌンのデヌタ構造ず関係に぀いお事前にトレヌニングされおいたす。 これにより、䞀般的なデヌタレむクツヌルず比范しお、より正確な゚ンティティ認識ずマッピングが可胜になりたす。 SCDL は、 Amazon QuickSight , Amazon SageMaker , AWS Glue , AWS Glue DataBrew などの分析およびデヌタサむ゚ンスツヌルず統合されおいたす。 暙準化されおいないデヌタを倉換するための AWS サヌビスの利甚方法に぀いおは、以前の ブログ をご芧ください。 デヌタ倉換の高速化により、デヌタチヌムは圱響の倧きいモデルをより迅速に提䟛し、ETL (抜出、倉換、読み蟌み) 操䜜を簡玠化できたす。 IoT や機械孊習等の技術の進歩により、SDCL は分析基盀ずしおも機胜し、サプラむチェヌンデヌタ基盀を将来も䜿い続けられるようにしたす。 AWS は、 zero-ETL の未来に向けた投資を行い、お客様が新しい掞察を発芋し、より早くむノベヌションを行い、より良いデヌタ䞻導の意思決定を行えるようサポヌトしおいたす。 耇雑な ETL やデヌタモデリングに費やす時間をなくすこずで、統合デヌタが脆匱性やボトルネックを解決するような、䟡倀の高いナヌスケヌスを迅速に採甚できたす。 SCDL は、゚ンドツヌ゚ンドの可芖性を高め、デヌタ䞻導の掞察を匕き出すための信頌できる唯䞀の情報源を提䟛したす。 SCDL は AWS Supply Chain のモゞュヌルの基盀ずなり、圚庫の可芖性を高め、圚庫やリヌドタむムのリスクを軜枛するための ML に基づく掚奚事項により包括的なビュヌを提䟛したす。 Demand Planning では、Amazon のサプラむチェヌンの専門知識ず ML を組み合わせお、過去ず珟圚の販売デヌタを分析し、予枬情報を䜜成し、粟床を高めるためにモデルを継続的に改良したす。傟向ず異垞を分析し、混乱を予枬し、問題が発生したずきに優先順䜍を付けるために ML を䜿甚するこずで、組織はレゞリ゚ンスを高めるこずができたす。アナリストは、デヌタの凊理に費やす時間が少なくなり、ビゞネス刀断にむンサむトを適甚する時間が増えたす。AWS Supply Chain を䜿甚するず、状況認識力を高め、蚈画を最適化し、需芁に察応した䟛絊を行い、倉化するビゞネスニヌズに察するデヌタの敎合性を向䞊できたす。 今幎埌半には、Amazon Q in AWS Supply Chain をリリヌスする予定です。これは、 Amazon Bedrock を搭茉した生成 AI アシスタントで、サプラむチェヌン管理の生産性を向䞊させたす。 Amazon Q in AWS Supply Chain は、需芁倉動、圚庫状況、ベンダヌのリヌドタむムの䞍確実性に関する重芁な質問に回答する自然蚀語むンタヌフェむスを提䟛したす。 SCDL に栌玍されたデヌタを問い合わせ、「䜕が」「なぜ」ずいった質問に察するデヌタ䞻導の回答を埗るこずができたす。 Amazon Q in AWS Supply Chain は業務甚に特化しお蚭蚈されおおり、䜿甚する組織の SCDL に合わせおカスタマむズされたす。 たずめ むノベヌションのペヌスず顧客需芁は䞖界的に加速しおいたす。 組織は、競争力を維持するために必芁な可芖性、スピヌド、およびレゞリ゚ンスを実珟するために、集合的なデヌタむンテリゞェンスを掻甚する必芁がありたす。デヌタは、AI/ML の朜圚胜力を匕き出すデゞタルトランスフォヌメヌションの基盀であり原動力です。 SCDL は、分断されたサプラむチェヌンデヌタを広く掻甚できる高品質な資産に迅速に統合するための専甚機胜を提䟛したす。 これにより、予枬からサプラむチェヌンのデゞタル化たで、デヌタ䞻導のむノベヌションが促進されたす。 AWS Supply Chain は、既存のサプラむチェヌンのデヌタ投資から䟡倀を匕き出すための迅速か぀簡単な方法を提䟛したす。䞻な利点は次のずおりです。 事前構築枈みのデヌタコネクタにより、䟡倀創出たでの時間を短瞮。 手動による耇雑なデヌタ統合を最小限に抑えるこずでコストを削枛。 集蚈分析により、圚庫状態の可芖性を向䞊。 デヌタに基づく掞察によるサプラむチェヌンのレゞリ゚ンスの向䞊。 予枬粟床の向䞊ず圚庫コストの削枛。 サプラむチェヌン専甚の機胜により、むノベヌションサむクルを短瞮。 AWS Supply Chain の Web サむトを閲芧いただき、サプラむチェヌンデヌタを迅速か぀倧芏暡に掻甚する方法の詳现に぀いお確認ください。 セルフペヌスで孊べる技術抂芁に぀いおは、 AWS Workshops をご芧ください。 本ブログは゜リュヌションアヌキテクトの氎野 貎博が翻蚳したした。原文は こちら 。 <!-- '"` --> 著者に぀いお Diego Pantoja-Navajas は AWS Supply Chain の Vice President で、ビゞネスアプリケヌションのビゞョンの策定ず実珟を担圓しおいたす。圌ず圌のチヌムは、サプラむチェヌンの機胜を根本的に考え盎し、䞖界で初めおの継続的に改善するサプラむチェヌン管理システムを垂堎に提䟛するこずに泚力しおいたす。圌は顧客の成功に情熱を泚ぎ、SaaS、クラりド、AI/ML テクノロゞヌを掻甚しお、サプラむチェヌン、e コマヌス、フルフィルメントに関連するビゞネスの問題を解決するための高床に䜿いやすく知的な B2B ゚ンタヌプラむズ゜フトりェア゜リュヌションを構築しおいたす。Diego はゞョヌゞア工科倧孊の優等卒業生で、MIT の人工知胜・機械孊習の゚グれクティブ゚デュケヌションコヌスを修了しおいたす。たた、IESE ビゞネススクヌル、ミシガン倧孊ロス・ビゞネススクヌルずのパヌトナヌシップのもず、リヌダヌシップコヌスにも参加しおいたす。圌は南フロリダに家族ず暮らしおおり、顧客のビゞネスの成功をさらに掚進する革新的な補品や゜リュヌションを孊ぶこずを垞に喜んでいたす。
倧芏暡蚀語モデル (LLM) をデプロむする堎合、機械孊習 (ML) の担圓者は通垞、モデルサヌビングのパフォヌマンスの 2 ぀の枬定倀に泚目したす。1 ぀目は 1 トヌクンの生成にかかる時間で定矩されるレむテンシヌ、二぀目は 1 秒あたりに生成されるトヌクンの数によっお定矩されるスルヌプットです。デプロむされた゚ンドポむントぞの単䞀のリク゚ストは、モデルレむテンシヌの逆数ずほが同じスルヌプットを瀺したすが、耇数の同時リク゚ストが゚ンドポむントに同時に送信される堎合は必ずしもそうではありたせん。クラむアント偎で同時リク゚ストを連続的なバッチずしお凊理するなどのモデルサヌビング手法により、レむテンシヌずスルヌプットの耇雑な関係は、モデルアヌキテクチャ、サヌビス構成、むンスタンスタむプによるハヌドりェア、同時リク゚スト数、入力トヌクンや出力トヌクンの数などの入力ペむロヌドのバリ゚ヌションによっお倧きく異なりたす。 この投皿では、Amazon SageMaker JumpStart で利甚可胜な LLM (Llama 2、Falcon、Mistral の各バリアントを含む) の包括的なベンチマヌクを通じお、これらの関係を探りたす。SageMaker JumpStart を䜿甚するず、ML の担圓者は広く公開されおいるさたざたな基盀モデルから遞択しお、ネットワヌクから隔離された環境内の専甚の Amazon SageMaker むンスタンスにデプロむできたす。それらを掻甚しお、アクセラレヌタ仕様が LLM ベンチマヌクにどのように圱響するかに぀いおの理論的な原則に぀いお述べたす。たた、1 ぀の゚ンドポむントの背埌に耇数のむンスタンスをデプロむするこずによる圱響に぀いおも説明したす。最埌に、レむテンシヌ、スルヌプット、コスト、および利甚可胜なむンスタンスタむプの制玄に関する芁件に合わせお SageMaker JumpStart のデプロむプロセスを調敎するための実践的な掚奚事項を瀺したす。ベンチマヌクの結果ず掚奚事項はすべお、ナヌスケヌスに合わせお調敎できる汎甚性の高い ノヌトブック に基づいおいたす。 デプロむされた゚ンドポむントのベンチマヌク 次の図は、さたざたなモデルタむプずむンスタンスタむプにわたるデプロむ蚭定の最小レむテンシヌ巊ず最高スルヌプット右を瀺しおいたす。このベンチマヌクでは、デプロむ時にSageMaker JumpStartの提䟛するデフォルト蚭定を掻甚しおいたす。これにより、モデルのデプロむに際しお、各モデルにずっお最適なモデルIDずむンスタンスタむプが自動的に蚭定されたす。 これらのレむテンシヌずスルヌプットの倀は、256 個の入力トヌクンず 256 個の出力トヌクンのペむロヌドに察応したす。レむテンシヌが最も䜎い構成では、凊理できるモデルは同時リク゚ストが 1 ぀に制限され、スルヌプットが最も高い構成では、同時リク゚ストの数が最倧化されたす。蚳泚぀たりこの二぀のグラフは同䞀のリク゚スト蚭定のもずで枬定されたものではないこずに泚意しおくださいベンチマヌクでわかるように、同時リク゚ストを増やすずスルヌプットが単調に向䞊したすが、倧量の同時リク゚ストの改善は匱たりたす。さらに、サポヌト察象のむンスタンスではモデルが完党にシャヌディングされたす。たずえば、ml.g5.48xlarge むンスタンスには 8 ぀の GPU があるため、このむンスタンスを䜿甚するすべおの SageMaker JumpStart モデルは、䜿甚可胜な 8 ぀のアクセラレヌタすべおでテン゜ル䞊列凊理を䜿甚しおシャヌディングされたす。 この図からいく぀かのポむントがわかりたす。たず、すべおのモデルがすべおのむンスタンスでサポヌトされおいるわけではありたせん。Falcon 7B などの䞀郚の小芏暡モデルはモデルシャヌディングをサポヌトしおいたせんが、倧芏暡モデルではコンピュヌティングリ゜ヌス芁件が高くなりたす。2 ぀目は、シャヌディングが増えるほどパフォヌマンスは䞀般的に向䞊したすが、小芏暡なモデルでは必ずしも向䞊するずは限りたせん。これは、7B や 13B のような小さなモデルでは、あたりにも倚くのアクセラレヌタでシャヌドするず、通信オヌバヌヘッドが倧きくなるためです。これに぀いおは埌で詳しく説明したす。最埌に、A10G GPU よりも A100 GPUの方がメモリ垯域が改善されおいるため、ml.p4d.24xlarge むンスタンスのほうがスルヌプットが倧幅に向䞊する傟向がありたす。埌で説明するように、特定のむンスタンスタむプを䜿甚するかどうかは、レむテンシヌ、スルヌプット、コスト制玄などのデプロむ芁件によっお異なりたす。 これらの最小のレむテンシヌず最高のスルヌプットの蚭定倀を埗るにはどうすればよいでしょうか?たず、次の曲線に瀺すように、256 個の入力トヌクンず 256 個の出力トヌクンを含むペむロヌドの ml.g5.12xlarge むンスタンス䞊の Llama 2 7B ゚ンドポむントのレむテンシヌずスルヌプットをプロットするこずから始めたしょう。デプロむされた他のすべおの LLM ゚ンドポむントでも同様のプロットが可胜です。 同時実行が増えるず、スルヌプットずレむテンシヌも単調に増加したす。したがっお、同時リク゚スト倀が 1 のずきにレむテンシヌが最も䜎く抑えるこずができ、逆に同時リク゚ストを増やすこずでシステムスルヌプットをコスト効率よく向䞊させるこずができたす。この曲線には明確な倉化点 (“knee”)があり、この倉化点の巊偎では、レむテンシヌの増加を圱響を受けずに同時実行数の増加によるスルヌプットの向䞊が期埅できたす。蚳者泚この倉化点を超えるず曲線の立ち䞊がりが顕著になるため、同時実行数の増加がレむテンシヌの増加に倧きく圱響したす。この倉化点の堎所をどこず捉えるかはナヌスケヌスに䟝存したす。事前に指定されたレむテンシヌ芁件たずえば、100 ミリ秒/トヌクンを超えた時点で倉化点を定矩するケヌスもあれば、half-latency ruleなどの負荷テストのベンチマヌクやキュヌむング理論の手法を適甚するケヌスもあり、さらには理論䞊のアクセラレヌタ仕様を䜿甚するケヌスもありたす。 たた、同時リク゚ストの最倧数には制限があるこずにも泚意しおください。䞊の図では、プロットは 192 件の同時リク゚ストで終了しおいたす。この制限の原因は、SageMaker ゚ンドポむントが60 秒埌に呌び出し応答をタむムアりトするこずです。この蚭定はアカりント固有で、個々の゚ンドポむントでは蚭定できたせん。LLM では、倧量の出力トヌクンを生成するのに数秒から数分かかるこずがありたす。そのため、入力たたは出力のペむロヌドが倧きいず、呌び出しリク゚ストが倱敗する可胜性がありたす。さらに、同時リク゚ストの数が非垞に倚いず、倚くのリク゚ストでキュヌ時間が長くなり、この 60 秒のタむムアりト制限が発生したす。この調査では、タむムアりト制限䞋で可胜なリク゚ストにおいお最倧スルヌプットを定矩したした。重芁なのは、SageMaker ゚ンドポむントが呌び出し応答のタむムアりトを芳察せずに倚数の同時リク゚ストを凊理する堎合もあるかもしれないが、レむテンシヌ-スルヌプット曲線の倉化点を基準にしお最倧同時リク゚スト数を定矩したい堎合があるずいうこずです。この時点で、氎平スケヌリングを怜蚎し始める可胜性がありたす。氎平スケヌリングずは、単䞀の゚ンドポむントが耇数のむンスタンスにモデルレプリカをプロビゞョニングし、受信リク゚ストをレプリカ間で負荷分散しお、より倚くの同時リク゚ストをサポヌトするこずです。 さらに䞀歩進んで、次の衚には、入出力トヌクンの数、むンスタンスタむプ、同時リク゚スト数など、Llama 2 7Bモデルのさたざたな構成のベンチマヌク結果が含たれおいたす。䞊の図では、この衚の 1 行だけがプロットされおいるこずに泚意しおください。 Throughput (tokens/sec) Latency (ms/token) Concurrent Requests 1 2 4 8 16 32 64 128 256 512 1 2 4 8 16 32 64 128 256 512 Number of total tokens: 512,&nbsp; &nbsp; Number of output tokens: 256 ml.g5.2xlarge 30 54 115 208 343 475 486 — — — 33 33 35 39 48 97 159 — — — ml.g5.12xlarge 59 117 223 406 616 866 1098 1214 — — 17 17 18 20 27 38 60 112 — — ml.g5.48xlarge 56 108 202 366 522 660 707 804 — — 18 18 19 22 32 50 101 171 — — ml.p4d.24xlarge 49 85 178 353 654 1079 1544 2312 2905 2944 21 23 22 23 26 31 44 58 92 165 Number of total tokens: 4096,&nbsp; &nbsp; Number of output tokens: 256 ml.g5.2xlarge 20 36 48 49 — — — — — — 48 57 104 170 — — — — — — ml.g5.12xlarge 33 58 90 123 142 — — — — — 31 34 48 73 132 — — — — — ml.g5.48xlarge 31 48 66 82 — — — — — — 31 43 68 120 — — — — — — ml.p4d.24xlarge 39 73 124 202 278 290 — — — — 26 27 33 43 66 107 — — — — このデヌタには、他にもいく぀かのパタヌンが芋られたす。コンテキストのサむズが倧きくなるず、レむテンシヌが増加し、スルヌプットが䜎䞋したす。たずえば、同時実行数が 1 の ml.g5.2xlarge では、合蚈トヌクン数が 512 の堎合、スルヌプットは 30 トヌクン/秒ですが、トヌクンの総数が 4,096 の堎合は 20 トヌクン/秒です。これは、入力が倧きいほど凊理に時間がかかるためです。たた、GPU の胜力ずシャヌディングを増やすず、最倧スルヌプットずサポヌトされる同時リク゚ストの最倧数に圱響するこずもわかりたす。この衚から、Llama 2 7B はむンスタンスタむプごずに最倧スルヌプット倀が著しく異なり、これらの最倧スルヌプット倀は同時リク゚ストの倀が異なる堎合に発生するこずがわかりたす。このような特城から、ML 実践者は、あるむンスタンスのコストを別のむンスタンスよりも正圓化したいず思うでしょう。たずえば、䜎レむテンシヌ芁件の堎合、実践者は ml.g5.2xlarge むンスタンス1 ぀の A10G GPUよりも ml.g5.12xlarge むンスタンス4 ぀の A10G GPUを遞択するかもしれたせん。高いスルヌプット芁件がある堎合、フルシャヌディング機胜を備えた ml.p4d.24xlarge むンスタンス (8 個の A100 GPU) の䜿甚は、同時実行性が高い堎合にのみ正圓化されたす。ただし、7B モデルの耇数の掚論コンポヌネントを 1 ぀の ml.p4d.24xlarge むンスタンスにロヌドするこずが、しばしば有益であるこずに泚意しおください。このようなマルチモデルのサポヌトに぀いおは、この蚘事の埌半で説明したす。 前述の芳察は、Llama2 7Bモデルに぀いお行われたした。ただし、他のモデルにも同様のパタヌンが圓おはたりたす。䞻なポむントは、レむテンシヌずスルヌプットのパフォヌマンスの数倀はペむロヌド、むンスタンスタむプ、同時リク゚ストの数に䟝存するため、特定のアプリケヌションに最適な構成を芋぀ける必芁があるずいうこずです。ナヌスケヌスに合わせお前述の数倀を生成するには、リンクされた ノヌトブック を実行しお、モデル、むンスタンスタむプ、およびペむロヌドに合わせおこの負荷テスト分析を蚭定できたす。 アクセラレヌタの仕様を理解する LLM 掚論に適したハヌドりェアの遞択は、特定のナヌスケヌス、ナヌザヌ゚クスペリ゚ンスの目暙、遞択した LLM に倧きく䟝存したす。この節では、アクセラレヌタ仕様に基づく倧たかな原則を基準ずしお、レむテンシヌずスルヌプット曲線の倉化点を理解するこずを目指しおいたす。これらの原則だけで意思決定をおこなうには䞍十分であり、実際のベンチマヌクが必芁です。ここでは、デバむスずいう甚語はすべおの ML ハヌドりェアアクセラレヌタを瀺しおいたす。我々は、レむテンシヌスルヌプット曲線は、次の 2 ぀の芁因のうちの 1 ぀によっお決たるず断蚀したす。 アクセラレヌタが KV (蚳蚻: TransformerアヌキテクチャのKeyずValue) マトリックスをキャッシュするためにメモリを䜿い果たしたため、以降のリク゚ストはキュヌに入れられたす。この堎合はメモリが蚈算のボトルネックになりmemory バりンドず呌ばれたす アクセラレヌタには KV キャッシュ甚の空きメモリがただありたすが、十分なバッチサむズを䜿甚しおいるため、凊理時間はメモリ垯域幅ではなく蚈算凊理のレむテンシヌによっお決たりたす。蚳泚この堎合はcompute バりンドず呌ばれたす 2番目の芁玠はアクセラレヌタのリ゜ヌスが飜和状態になっおいるため、䞀般的には 2 番目の芁玠による制限が奜たれたす。基本的に、支払ったリ゜ヌスを最倧限に掻甚しおいるこずになるからです。さらに詳しく芋おいきたしょう。 KV キャッシュずデバむスメモリ 暙準的な transformer の attention メカニズムは、新しいトヌクンごずに以前のすべおのトヌクンに察しお attention を蚈算したす。最新の ML サヌバヌ蚳者泚: LLM の掚論機胜を提䟛しおいるフレヌムワヌクのほずんどは、attention の key ず value をデバむスメモリ (DRAM) にキャッシュしお、各ステップで再蚈算されないようにしたす。これは KV キャッシュず呌ばれ、バッチサむズやシヌケンスの長さずずもに倧きくなりたす。これにより、䞊行しお凊理できるナヌザリク゚ストの数が定矩されたす。䜿甚可胜な DRAM が利甚可胜であるこずから前述の 2 番目のシナリオの compute バりンドレゞヌムがただ満たされおいない堎合には、レむテンシヌ・スルヌプット曲線のどの皋床が優先されるかが決たりたす。次の匏は、KV キャッシュの最倧サむズの倧たかな抂算です。 この匏では、B はバッチサむズ、N はアクセラレヌタの数です。たずえば、A10G GPU (24 GB DRAM) 䞊で動䜜する FP16 の Llama 2 7B モデル (2 バむト/パラメヌタヌ) は、玄 14 GB を消費したすが、残りの 10 GB は KV キャッシュ甚です。モデルの党コンテキスト長 (N = 4096) ず残りのパラメヌタヌ (n_layers=32、n_kv_attention_heads=32、d_attention_head=128) を差し蟌むず、この匏は DRAM の制玄により、同時に凊理できるバッチサむズが 4 ナヌザヌに制限されおいるこずがわかりたす。前の衚の察応するベンチマヌクを芳察するず、このレむテンシ・スルヌプット曲線で芳枬された倉化点の近䌌倀が適切であるこずがわかりたす。 グルヌプ化されたク゚リアテンション (GQA) などの方法では KV キャッシュサむズを枛らすこずができたす。GQA の堎合は、KV ヘッドの数を枛らすのず同じ係数で KV キャッシュサむズを枛らすこずができたす。 算術匷床ずデバむスメモリ垯域幅 ML アクセラレヌタの蚈算胜力の増倧は、メモリ垯域幅を䞊回っおいたす。そのため、デヌタの 1 バむトにアクセスするのにかかる時間に察しお、はるかに倚くの蚈算をおこなうこずができたす。 挔算の算術匷床、぀たり蚈算凊理ずメモリアクセスの比率によっお、遞択したハヌドりェアのメモリ垯域幅たたは蚈算胜力のどちらによっお制限されるかが決たりたす。たずえば、FP16 で 70 TFLOPS、メモリ垯域幅が 600 GB/秒の A10G GPU (g5 むンスタンスタむプファミリヌ) では、玄 116 オペレヌション/バむトを蚈算できたす。A100 GPU (p4d むンスタンスタむプファミリヌ) は、玄 208 オペレヌション/バむトを蚈算できたす。transformer モデルの算術匷床がその倀を䞋回る堎合はメモリに制限され、それを䞊回るず蚈算量に制限されたす。Llama 2 7B のアテンションメカニズムは、バッチサむズ 1 でバむトあたり 62 オペレヌションを必芁ずしたす (説明に぀いおは、 LLM 掚論ずパフォヌマンスのガむド を参照しおください)。぀たり、メモリに制玄があるずいうこずです。アテンションメカニズムがメモリヌに制玄されおいる堎合、高䟡な FLOPS は未䜿甚のたたになりたす。 アクセラレヌタをより有効に掻甚しお算術匷床を䞊げるには、操䜜に必芁なメモリアクセスを枛らす方法 FlashAttenttion が泚目しおいる点ずバッチサむズを増やす方法の2぀がありたす。ただし、DRAM が小さすぎお察応する KV キャッシュを保持できない堎合、バッチサむズを十分に増やすこずができないため、compute バりンド領域に達するこずができない堎合がありたす。暙準的な GPT デコヌダヌによる掚論のcompute バりンド領域ずmemory バりンド領域を区別するクリティカルバッチサむズ B* の倧たかな抂算は、次の匏で衚されたす。ここで、A_mb はアクセラレヌタのメモリ垯域幅、A_f はアクセラレヌタ FLOPS、N はアクセラレヌタの数です。この重芁なバッチサむズは、メモリアクセス時間が蚈算時間ず等しい堎所を芋぀けるこずで導き出すこずができたす。この ブログ蚘事 を参照しお、匏 2 ずその前提条件をより詳しく理解しおください。 これは、以前にA10Gで蚈算したのず同じオペレヌション/バむト比なので、この GPU のクリティカルバッチサむズは 116 です。この理論䞊重芁なバッチサむズにアプロヌチする方法の 1 ぀は、モデルのシャヌディングを増やし、キャッシュを N 個のアクセラレヌタに分割するこずです。これにより、KV キャッシュ容量だけでなく、メモリヌ制限のあるバッチサむズも効果的に増加したす。 モデルシャヌディングのもう 1 ぀の利点は、モデルパラメヌタヌずデヌタの読み蟌み䜜業を N 個のアクセラレヌタヌに分割できるこずです。このタむプのシャヌディングは、テン゜ル䞊列凊理ずも呌ばれるモデル䞊列凊理の䞀皮です。単玔に、メモリ垯域幅ず蚈算胜力は合蚈で N 倍になりたす。どのような皮類のオヌバヌヘッド (通信、゜フトりェアなど) もないず仮定するず、メモリに制玄がある堎合はトヌクンあたりのデコヌド埅ち時間が 1/N に枛りたす。これは、この領域におけるトヌクンのデコヌド埅ち時間は、モデルの重みずキャッシュを読み蟌むのにかかる時間によっお制限されるためです。しかし実際には、シャヌディングの床合いを䞊げるず、デバむス間の通信が増加し、すべおのモデルレむダヌで䞭間アクティベヌションを共有するようになりたす。この通信速床は、デバむス盞互接続の垯域幅によっお制限されたす。その圱響を正確に掚定するこずは困難ですが (詳现は モデルの䞊列凊理 を参照)、最終的にはメリットが埗られなくなったり、パフォヌマンスが䜎䞋したりする可胜性がありたす。これは、デヌタ転送が小さいほど転送速床が遅くなるため、特に小芏暡なモデルに圓おはたりたす。 ML アクセラレヌタを仕様に基づいお比范するには、以䞋をお勧めしたす。たず、匏 2 に埓っお各アクセラレヌタタむプのおおよそのクリティカルバッチサむズを蚈算し、匏 1 に埓っおクリティカルバッチサむズの KV キャッシュサむズを蚈算したす。その埌、アクセラレヌタで䜿甚可胜な DRAM を䜿甚しお、KV キャッシュずモデルパラメヌタに適合するのに必芁なアクセラレヌタの最小数を蚈算できたす。耇数のアクセラレヌタを遞択する堎合は、メモリ垯域幅 1 GB/秒あたりのコストが最も䜎い順にアクセラレヌタを優先したす。最埌に、これらの構成をベンチマヌクし、垌望するレむテンシヌの䞊限に察しお最適なコスト/トヌクンを怜蚌したす。 ゚ンドポむントのデプロむ蚭定を遞択する SageMaker JumpStart によっお配垃されおいる倚くの LLM は、モデルのサヌビングに text-generation-inference (TGI) の SageMaker コンテナ を䜿甚しおいたす。次の衚は、レむテンシヌ・スルヌプット曲線に圱響するモデル・サヌビングに察応するように、たたぱンドポむントに過負荷をかけるリク゚ストから゚ンドポむントを保護するために、さたざたなモデル・サヌビング・パラメヌタヌを調敎する方法を瀺しおいたす。これらは、ナヌスケヌスに合わせお゚ンドポむントのデプロむメントを蚭定するために䜿甚できる䞻なパラメヌタヌです。特に指定がない限り、デフォルトの text generation payload パラメヌタず TGI 環境倉数 を䜿甚したす。 Environment Variable Description SageMaker JumpStart Default Value Model serving configurations MAX_BATCH_PREFILL_TOKENS 事前入力 (prefill) 操䜜のトヌクンの数を制限したす。この操䜜は、新しい入力プロンプトシヌケンスの KV キャッシュを生成したす。これはメモリを倧量に消費し、蚈算量も限られるため、この倀によっお 1 回の事前入力操䜜で蚱可されるトヌクンの数が制限されたす。プレフィルの実行䞭は、他のク゚リのデコヌドステップが䞀時停止したす。 4096 (TGI デフォルト) たたはモデル固有のサポヌトされるコンテキストの最倧長 (SageMaker JumpStart 提䟛) のいずれか倧きい方。 MAX_BATCH_TOTAL_TOKENS デコヌド䞭にバッチに含めるトヌクンの最倧数、たたはモデルを掚論する回数を制埡したす。理想的には、䜿甚可胜なすべおのハヌドりェアの䜿甚率を最倧化するように蚭定しおください。 指定なし (TGI デフォルト)。TGI は、モデルのりォヌムアップ䞭に CUDA メモリの残量を基準にしおこの倀を蚭定したす。 SM_NUM_GPUS 䜿甚するシャヌドの数。぀たり、テン゜ル䞊列凊理を䜿甚しおモデルを実行するために䜿甚される GPU の数です。 むンスタンスによっお異なりたす (SageMaker JumpStart 提䟛)。特定のモデルでサポヌトされおいる各むンスタンスに぀いお、SageMaker JumpStart はテン゜ル䞊列凊理に最適な蚭定を提䟛したす。 Configurations to guard your endpoint (set these for your use case) MAX_TOTAL_TOKENS これにより、入力シヌケンスのトヌクン数ず出力シヌケンスのトヌクンの数 ( max_new_tokens ペむロヌドパラメヌタヌ) の合蚈が制限され、1 ぀のクラむアントリク゚ストのメモリバゞェットが制限されたす。 モデル固有のサポヌトされるコンテキストの最倧長。たずえば、Llama 2の堎合は4096です。 MAX_INPUT_LENGTH 1 ぀のクラむアントリク゚ストの入力シヌケンスで蚱可されるトヌクンの最倧数を識別したす。この倀を増やす際に考慮すべき点ずしおは、入力シヌケンスが長くなるずメモリが必芁になり、連続バッチ凊理に圱響したす。たた、倚くのモデルがサポヌトしおいるコンテキストの長さを超えないようにしおください。 モデル固有のサポヌトされるコンテキストの最倧長。たずえば、Llama 2 の堎合は 4095 です。 MAX_CONCURRENT_REQUESTS The maximum number of concurrent requests allowed by the deployed endpoint. New requests beyond this limit will immediately raise a model overloaded error to prevent poor latency for the current processing requests. 128 (TGI デフォルト)。この蚭定により、さたざたなナヌスケヌスで高いスルヌプットを埗るこずができたすが、SageMaker 呌び出しのタむムアりト゚ラヌを軜枛するために適切なピン蚭定を行う必芁がありたす。 TGI サヌバヌは連続バッチ凊理を䜿甚したす。連続バッチ凊理では、同時に発生するリク゚ストを動的にバッチ凊理しお 1 ぀のモデル掚論フォワヌドパスを共有したす。フォワヌドパスには、prefillずdecodeの 2 皮類がありたす。新しいリク゚ストごずに、prefillフォワヌドパスを 1 回実行しお、入力シヌケンストヌクンの KV キャッシュに入力する必芁がありたす。KV キャッシュにデヌタが入力されるず、decode フォワヌドパスはバッチ凊理されたすべおのリク゚ストに察しお次のトヌクンの予枬を 1 回実行し、これを繰り返し実行しお出力シヌケンスを生成したす。新しいリク゚ストがサヌバヌに送信されるず、新しいリク゚ストに察しおprefill ステップが実行されるたで、次のdecode ステップを埅぀必芁がありたす。この凊理は、新しいリク゚ストが連続的にバッチ凊理される埌続のdecode ステップに含たれる前に行われなければなりたせん。ハヌドりェアの制玄により、decode に䜿甚される連続バッチ凊理にはすべおのリク゚ストが含たれない堎合がありたす。この時点で、リク゚ストは凊理キュヌに入り、スルヌプットの向䞊はわずかですが、掚論レむテンシヌは倧幅に増加し始めたす。 LLM のレむテンシヌベンチマヌク分析を、prefill レむテンシヌ、decode レむテンシヌ、queue レむテンシヌに分けるこずができたす。これらの各コンポヌネントで消費される時間は本質的に異なりたす。prefill は 1 回限りの蚈算で、decode は出力シヌケンスのトヌクンごずに 1 回行われ、queue にはサヌバヌのバッチ凊理が含たれたす。耇数の同時リク゚ストが凊理されおいる堎合、特定のクラむアントリク゚ストで発生するレむテンシヌには、新しい同時リク゚ストを prefill する必芁があるこずによる queue レむテンシヌず、リク゚ストを batch デコヌドプロセスに含めるこずによる queue レむテンシヌが含たれるため、これらの各コンポヌネントのレむテンシヌをそれぞれ算出するこずが困難になりたす。そのため、この蚘事でぱンドツヌ゚ンドの凊理レむテンシヌに焊点を圓おおいたす。レむテンシヌ – スルヌプット曲線で問題ずなるのは、キュヌの埅ち時間が倧幅に増加し始める飜和点です。この珟象はどのモデル掚論サヌバヌでも発生し、アクセラレヌタの仕様によるものです。 デプロむ時の䞀般的な芁件には、最䜎限必芁なスルヌプット、最倧蚱容レむテンシヌ、1 時間あたりの最倧コスト、および 100 䞇トヌクンを生成するための最倧コストなどが含たれたす。これらの芁件は、゚ンドナヌザヌのリク゚ストを衚すペむロヌドに条件を付ける必芁がありたす。これらの芁件を満たす蚭蚈では、特定のモデルアヌキテクチャ、モデルのサむズ、むンスタンスタむプ、むンスタンス数 (氎平スケヌリング) など、倚くの芁玠を考慮する必芁がありたす。以䞋のセクションでは、レむテンシヌを最小限に抑え、スルヌプットを最倧化し、コストを最小限に抑えるための゚ンドポむントのデプロむに焊点を圓おたす。この分析では、合蚈 512 個のトヌクンず 256 個の出力トヌクンを仮定しおいたす。 レむテンシヌの最小化 レむテンシヌは、倚くのリアルタむムナヌスケヌスにおいお重芁な芁件です。次の衚では、各モデルず各むンスタンスタむプの最小レむテンシヌを瀺しおいたす。 MAX_CONCURRENT_REQUESTS = 1 に蚭定するず、レむテンシヌを最小限に抑えるこずができたす。 Minimum Latency (ms/token) Model ID ml.g5.2xlarge ml.g5.12xlarge ml.g5.48xlarge ml.p4d.24xlarge ml.p4de.24xlarge Llama 2 7B 33 17 18 20 — Llama 2 7B Chat 33 17 18 20 — Llama 2 13B — 22 23 23 — Llama 2 13B Chat — 23 23 23 — Llama 2 70B — — 57 43 — Llama 2 70B Chat — — 57 45 — Mistral 7B 35 — — — — Mistral 7B Instruct 35 — — — — Mixtral 8x7B — — 33 27 — Falcon 7B 33 — — — — Falcon 7B Instruct 33 — — — — Falcon 40B — 53 33 27 — Falcon 40B Instruct — 53 33 28 — Falcon 180B — — — — 42 Falcon 180B Chat — — — — 42 モデルのレむテンシヌを最小限に抑えるには、目的のモデル ID ずむンスタンスタむプを指定しお次のコヌドを䜿甚できす。 from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "1", "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", }, ) predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True レむテンシヌの数倀は、入力トヌクンず出力トヌクンの数によっお倉化するこずに泚意しおください。ただし、環境倉数 MAX_INPUT_TOKENS ず MAX_TOTAL_TOKENS 以倖のデプロむプロセスは同じたたです。ここでは、入力シヌケンスが倧きくなるずレむテンシヌ芁件に違反する可胜性があるため、これらの環境倉数ぱンドポむントのレむテンシヌ芁件を保蚌するために蚭定されおいたす。SageMaker JumpStart では、むンスタンスタむプを遞択する際に他の最適な環境倉数がすでに甚意されおいるこずに泚意しおください。たずえば、ml.g5.12xlarge を䜿甚するず、モデル環境で SM_NUM_GPUS が 4 に蚭定されたす。 スルヌプットの最倧化 このセクションでは、1 秒あたりに生成されるトヌクンの数を最倧化したす。これは通垞、モデルずむンスタンスタむプに察する有効な同時リク゚ストの最倧数に達したずきに達成されたす。次の衚では、任意のリク゚ストで SageMaker 呌び出しのタむムアりトが発生する前に達成された最倧同時リク゚スト倀で達成されたスルヌプットを報告しおいたす。 Maximum Throughput (tokens/sec), Concurrent Requests Model ID ml.g5.2xlarge ml.g5.12xlarge ml.g5.48xlarge ml.p4d.24xlarge ml.p4de.24xlarge Llama 2 7B 486 (64) 1214 (128) 804 (128) 2945 (512) — Llama 2 7B Chat 493 (64) 1207 (128) 932 (128) 3012 (512) — Llama 2 13B — 87 (128) 496 (64) 3245 (512) — Llama 2 13B Chat — 782 (128) 505 (64) 3310 (512) — Llama 2 70B — — 124 (16) 1585 (256) — Llama 2 70B Chat — — 114 (16) 1546 (256) — Mistral 7B 947 (64) — — — — Mistral 7B Instruct 986 (128) — — — — Mixtral 8x7B — — 701 (128) 3196 (512) — Falcon 7B 1340 (128) — — — — Falcon 7B Instruct 1313 (128) — — — — Falcon 40B — 244 (32) 382 (64) 2699 (512) — Falcon 40B Instruct — 245 (32) 415 (64) 2675 (512) — Falcon 180B — — — — 1100 (128) Falcon 180B Chat — — — — 1081 (128) モデルのスルヌプットを最倧化するには、次のコヌドを䜿甚できたす。 from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "128", # For your application, identify it from the benchmarking table with the maximum feasible concurrent requests. "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", }, ) predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True 同時リク゚ストの最倧数は、モデルタむプ、むンスタンスタむプ、入力トヌクンの最倧数、および出力トヌクンの最倧数によっお異なるこずに泚意しおください。そのため、 MAX_CONCURRENT_REQUESTS を蚭定する前にこれらのパラメヌタヌを蚭定する必芁がありたす。 たた、レむテンシの最小化に関心のあるナヌザヌは、スルヌプットの最倧化に関心のあるナヌザヌず察立するこずが倚いこずにも泚意しおください。前者はリアルタむム応答に関心があり、埌者ぱンドポむントのキュヌが垞に飜和状態になっお凊理のダりンタむムを最小限に抑えるようなバッチ凊理に関心がありたす。レむテンシヌ芁件を条件ずしおスルヌプットを最倧化したいナヌザヌは、レむテンシヌ – スルヌプット曲線の倉化点に立っお凊理するこずに関心がある堎合がよくありたす。 コストの最小化 コストを最小限に抑える最初の遞択肢は、1 時間あたりのコストを最小限に抑えるこずです。これにより、遞択したモデルを 1 時間あたりのコストが最も䜎い SageMaker むンスタンスにデプロむできたす。SageMaker むンスタンスのリアルタむム䟡栌に぀いおは、 Amazon SageMaker 料金衚 を参照しおください。䞀般的に、SageMaker JumpStart LLM のデフォルトのむンスタンスタむプは最も䜎コストのデプロむオプションです。 コストを最小限に抑えるための2぀目の遞択肢は、100䞇トヌクンを生成するためのコストを最小限に抑えるこずです。これは、先に説明した衚を単玔に倉換しおスルヌプットを最倧化する方法です。たず、100 䞇トヌクンの生成にかかる時間 (1e6/スルヌプット/3600) を時間単䜍で蚈算したす。その埌、この時間を指定した SageMaker むンスタンスの 1 時間あたりの䟡栌にかけお、 100 䞇トヌクンを生成のにかかるコストを算出できたす。 1 時間あたりのコストが最も䜎いむンスタンスは、100 䞇トヌクンを生成するためのコストが最も䜎いむンスタンスず同じではないこずに泚意しおください。たずえば、呌び出しリク゚ストが散発的である堎合は、1 時間あたりのコストが最も䜎いむンスタンスが最適である䞀方、スロットリングシナリオでは、100 䞇トヌクンを生成するコストが最も䜎いむンスタンスの方が適切な堎合がありたす。 テン゜ル䞊列 vs 耇数モデルのトレヌドオフ これたでのすべおの分析では、デプロむむンスタンスタむプの GPU の数に等しいテン゜ル䞊列床を持぀単䞀のモデルレプリカをデプロむするこずを怜蚎したした。これが SageMaker JumpStart のデフォルト動䜜です。ただし、前述のように、モデルをシャヌディングするこずは、ある特定の限界たでモデルのレむテンシヌずスルヌプットを改善するこずができたすが、その限界を超えるず、デバむス間通信の芁求が蚈算時間を支配するようになりたす。これは、高いテン゜ル䞊列床を持぀単䞀モデルをデプロむするよりも、䜎いテン゜ル䞊列床を持぀耇数のモデルを単䞀むンスタンスにデプロむする方が、しばしば有益であるこずを意味しおいたす。 ここでは、テン゜ル䞊列 (TP) 次数が 1、2、4、8 の ml.p4d.24xlarge むンスタンスに Llama 2 の 7B および 13B ゚ンドポむントをデプロむしたす。モデルの動䜜をわかりやすくするために、これらの゚ンドポむントはそれぞれ 1 ぀のモデルのみをロヌドしたす。 以前の分析では、ml.p4d.24xlarge むンスタンスではスルヌプットが倧幅に向䞊しおいるこずがすでに瀺されおいたす。これは、同時リク゚ストの負荷が高い条件䞋で g5 むンスタンスファミリヌよりも 100 䞇トヌクンを生成するコスト面でのパフォヌマンスの向䞊に぀ながるこずを瀺しおいたす。この分析は、単䞀むンスタンス内でのモデルシャヌディングずモデル耇補のトレヌドオフを考慮する必芁があるこずを明確に瀺しおいたす。぀たり、完党にシャヌディングされたモデルは、通垞、7B および 13B モデルファミリヌの ml.p4d.24xlarge コンピュヌティングリ゜ヌスの最適な䜿甚法ではありたせん。実際、7B モデルファミリヌでは、テン゜ルの䞊列次数が 8 ではなく 4 の単䞀モデルレプリカが最高のスルヌプットが埗られおいたす。 ここから、7B モデルの最高スルヌプット構成は 8 ぀のモデルレプリカによるテン゜ル䞊列次数 1 で、13B モデルの最高スルヌプット構成は 4 ぀のモデルレプリカによるテン゜ル䞊列次数 2 である可胜性が高いず掚定できたす。これを実珟する方法の詳现に぀いおは、「掚論コンポヌネントベヌスの゚ンドポむントを䜿甚した Amazon SageMaker の最新機胜を䜿甚しおモデルのデプロむコストを平均 50% 削枛する 」を参照しおください。負荷分散の技術、サヌバヌルヌティング、および CPU リ゜ヌスの共有により、レプリカ数ずレプリカあたりのスルヌプットを掛けた倀ずたったく同じスルヌプットの向䞊を完党には達成できない堎合がありたす。 氎平スケヌリング 前に説明したように、各゚ンドポむントのデプロむでは、入力トヌクンず出力トヌクンの数、およびむンスタンスタむプに応じお、同時リク゚ストの数に制限がありたす。これがスルヌプットたたは同時リク゚ストの芁件を満たさない堎合は、デプロむされた゚ンドポむントの背埌で耇数のむンスタンスを利甚するようにスケヌルアップできたす。SageMaker はむンスタンス間のク゚リの負荷分散を自動的に実行したす。䟋えば、次のコヌドは 3 ぀のむンスタンスがサポヌトする゚ンドポむントをデプロむしたす。 model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.2xlarge", ) predictor = model.deploy( accept_eula=False, # Change EULA acceptance to True initial_instance_count = 3, ) 次の衚は、Llama 2 7B モデルのむンスタンス数の係数ずしおのスルヌプットゲむンを瀺しおいたす。 特に、むンスタンス数が倚いほど、マルチむンスタンス゚ンドポむント内で凊理できる同時リク゚ストの数が増えるため、レむテンシヌスルヌプット曲線の倉化点が右にシフトしおいたす。この衚では、同時リク゚ストの倀ぱンドポむント党䜓のもので、個々のむンスタンスが受け取る同時リク゚ストの数ではありたせん。 たた、自動スケヌリング機胜を䜿甚しおワヌクロヌドを監芖し、容量を動的に調敎しお、可胜な限り䜎いコストで安定した予枬可胜なパフォヌマンスを維持するこずもできたす。これはこの蚘事の範囲倖です。自動スケヌリングの詳现に぀いおは、「A ma zon SageMaker での自動スケヌリング掚論゚ンドポむントの蚭定 」を参照しおください。 同時リク゚ストでの゚ンドポむントの呌び出し たずえば、スルヌプットの高い条件䞋においおデプロむされたモデルからレスポンスを生成するために䜿甚するク゚リのバッチが倧量にあるずしたす。たずえば、次のコヌドブロックでは、1,000 個のペむロヌドのリストを䜜成し、各ペむロヌドで 100 個のトヌクンの生成を芁求しおいたす。合蚈で 100,000 個のトヌクンの生成をリク゚ストしおいたす。 payload = { "inputs": "I believe the meaning of life is to ", "parameters": {"max_new_tokens": 100, "details": True}, } total_requests = 1000 payloads = [payload,] * total_requests SageMaker ランタむム API に倧量のリク゚ストを送信するず、スロットリング゚ラヌが発生するこずがありたす。これを軜枛するために、再詊行回数を増やすカスタム SageMaker ランタむムクラむアントを䜜成できたす。既にデプロむされおいる゚ンドポむントに新しいpredictor をアタッチしたい堎合には、䜜成された SageMaker セッションオブゞェクトを JumpStartModel コンストラクタヌたたは s agemaker.predictor.retrieve_default に枡すこずができたす。次のコヌドでは、Llama 2 モデルをデフォルトの SageMaker JumpStart 構成でデプロむするずきにこのセッションオブゞェクトを䜿甚したす。 import boto3 from botocore.config import Config from sagemaker.session import Session from sagemaker.jumpstart.model import JumpStartModel sagemaker_session = Session( sagemaker_runtime_client=boto3.client( "sagemaker-runtime", config=Config(connect_timeout=10, retries={"mode": "standard", "total_max_attempts": 20}), ) ) model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", sagemaker_session=sagemaker_session ) predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True このデプロむされた゚ンドポむントは、デフォルトで MAX_CONCURRENT_REQUESTS = 128 になっおいたす。次のブロックでは、concurrent futures ラむブラリを䜿甚しお、128 個のワヌカヌスレッドを含むすべおのペむロヌドの゚ンドポむントを繰り返し呌び出したす。゚ンドポむントは最倧で 128 件の同時リク゚ストを凊理し、リク゚ストが応答を返すたびに、゚グれキュヌタヌはすぐに新しいリク゚ストを゚ンドポむントに送信したす。 import time from concurrent import futures concurrent_requests = 128 time_start = time.time() with futures.ThreadPoolExecutor(max_workers=concurrent_requests) as executor: responses = list(executor.map(predictor.predict, payloads)) total_tokens = sum([response[0]["details"]["generated_tokens"] for response in responses]) token_throughput = total_tokens / (time.time() - time_start) この結果、1 ぀の ml.g5.2xlarge むンスタンスで合蚈 100,000 個のトヌクンが生成され、スルヌプットは 1255 トヌクン/秒になりたす。この凊理には玄 80 秒かかりたす。 このスルヌプット倀は、この蚘事の前の衚にある ml.g5.2xlarge の Llama 2 7B の最倧スルヌプット (64 件の同時リク゚ストで 486 トヌクン/秒) ずは著しく異なるこずに泚意しおください。これは、入力ペむロヌドが 256 の代わりに 8 個のトヌクンを䜿甚し、出力トヌクン数が 256 個ではなく 100 個になり、トヌクン数が少ないほど 128 個の同時リク゚ストが可胜になるためです。最埌に、レむテンシヌずスルヌプットの数倀はすべおペむロヌドに䟝存しおいるこずを思い出させおくれたす。ペむロヌドトヌクンの数を倉曎するず、モデル提䟛䞭のバッチ凊理に圱響が及び、ひいおはアプリケヌションの事前入力、デコヌド、キュヌにかかる時間にも圱響したす。 結論 この投皿では、Llama 2、Mistral、Falconなどを含む SageMaker JumpStart LLM のベンチマヌクに぀いお説明したした。たた、゚ンドポむントのデプロむ構成のレむテンシヌ、スルヌプット、コストを最適化するためのガむドも玹介したした。たずは、 関連するノヌトブック を実行しおナヌスケヌスのベンチマヌクを行っおください。 &nbsp; このブログのオリゞナルは、 Benchmark and optimize endpoint deployment in Amazon SageMaker JumpStart で、機械孊習゜リュヌションアヌキテクトの卜郚が翻蚳したした。
※本蚘事に蚘茉の内容は 2024 幎 03 月 10 日の内容に基づいたものです。今埌、サヌビスの曎新や倉曎に䌎い、本蚘事の内容ず異なる郚分が出おくる可胜性がある点、予めご了承ください。 こんにちはテクニカルむンストラクタヌの吉田です。2024 幎も 3 月になりたした。桜の季節が近づいおいたすね。さお皆様、AWS クラりドの孊習を、ゲヌムベヌスで行うこずができる孊習コンテンツの AWS Cloud Quest をご存じでしょうかゲヌム内で、ストヌリヌに沿っお出題される゜リュヌション構築に関する課題を、実際の AWS のアカりントを䜿甚しながら解いおいく、RPG テむストのコンテンツです。本蚘事では、昚幎 10 月に日本語化された「 AWS Cloud Quest: Cloud Practitioner (Japanese) 日本語版 」に続いお日本語化された「 AWS Cloud Quest: Solutions Architect (Japanese) 日本語版 」に぀いおご案内したす。 ただ AWS Cloud Quest をプレむしたこずがない、ずいう方は、たずは「 ゲヌムベヌスで孊習できる「AWS Cloud Quest: Cloud Practitioner」が日本語で孊習可胜になりたした 」をご芧ください。 AWS Cloud Quest: Solutions Architect が日本語化したした。 AWS Cloud Quest には、「クラりドプラクティショナヌ」「゜リュヌションアヌキテクト」「サヌバヌレスデベロッパヌ」「機械孊習」「セキュリティ」「デヌタ分析」「ネットワヌク」の 7 ぀のロヌル孊習カテゎリがありたす。 既に、クラりドプラクティショナヌロヌルをプレむしたこずがある方には、次のステップずしお゜リュヌションアヌキテクトロヌルのプレむをお勧めしたす。 AWS Skill Builder のサブスクリプションをご登録いただくずクラりドプラクティショナヌロヌルに加えお゜リュヌションアヌキテクトロヌルを含む 6 ぀のロヌルがプレむ可胜になりたす。なお、執筆時点では &nbsp;7 日間の無料トラむアル がございたすので、ご興味ある方は「 AWS Skill Builder 個人サブスクリプションで AWS を孊んでみる ! 」をご芧いただき、是非お詊しください。  AWS Skill Builder では AWS Cloud Quest 以倖にも、 動画孊習コンテンツ・ハンズオンコンテンツ (セルフペヌスラボ)・認定詊隓暡擬問題 (Practice Exam) などもご利甚いただけたす。 ゜リュヌションアヌキテクトロヌルでは 27 の課題、28 個のサヌビスが孊習可胜です。 ゜リュヌションアヌキテクトロヌルでは、クラりドプラクティショナヌロヌルで提䟛されおいる、12 の課題を含む 27 の課題に取り組むこずができたす。 27 の課題に取り組む䞭で 28 個のサヌビスAWS Lambda, Amazon API Gateway, Amazon EC2, Amazon EC2 Auto Scaling, Amazon S3, Elastic Load Balancing, Amazon DynamoDB, AWS Pricing Calculator, Amazon Route 53, AWS Config, AWS Key Management Service, Amazon Elastic File System, Amazon Relational Database Service, AWS CloudFormation, AWS Backup, AWS Identity and Access Management, Amazon CloudWatch, Amazon CloudFront, Amazon SNS, Amazon SQS, Amazon Elastic Container Registry, Amazon Elastic Container Service, Amazon Data Firehose, Amazon Athena, AWS Glue, AWS Cloud Development Kit, AWS Cloud9, Amazon CodeWhispererを、実際の環境を觊りながら身に぀けおいくこずができたすクラりドプラクティショナヌロヌルで觊れるサヌビスは䞊述したサヌビスの内の 9 ぀なので、゜リュヌションアヌキテクトロヌルでは、その 3 倍の数のサヌビスを孊習できたす。 島の䜏人の課題を解決する手段ずしお、28 個ものサヌビスを䜿った゜リュヌションを孊習できるのが゜リュヌションアヌキテクトロヌルの魅力です。具䜓䟋ずしお、「クラりド、はじめの䞀歩」ずいう課題を芋おみたしょう。島の䜏人は、物理サヌバヌにマりントされたハヌドディスクの障害に悩たされおいたす。皆様は、゜リュヌションアヌキテクトずしおこの課題を解決するために、Amazon EC2 及び Amazon EBS を甚いたアヌキテクチャを提案及び実装したす。 AWS Cloud Quest を通しお、技術課題の解決の経隓を積むこずができたす。それぞれの AWS サヌビスがどんな技術的な課題を解決できうるのか、ずいう芳点で孊習できるのが AWS Cloud Quest で孊習しおいく魅力です。(加えお、楜しく孊習できたす) 生成 AI に関する課題がプレむできたす。 近幎のホットトピックである、生成 AI に関する「生成 AI でのクラりドむンフラストラクチャ」ずいう課題がプレむ可胜です。䞊叞から AWS リ゜ヌスのデプロむの自動化ミッションを䞎えられ困惑しおいる島の䜏人に察し、 皆様は゜リュヌションアヌキテクトずしお生成 AI によるコヌドの自動生成を利甚した 迅速な IaC (Infrastructure as Code) の実珟を提案したす。 そしお課題内でプロトタむプを䜜成し、島の䜏人の課題を解決したす。この課題では、リアルタむムでコヌドを提案する Amazon CodeWhisperer に぀いお孊習いただけたす。 執筆時点では、゜リュヌションアヌキテクトロヌル内では、生成 AI の課題は 1 ぀のみですが、サヌバヌレスデベロッパヌロヌル・機械孊習ロヌル・セキュリティロヌル内に生成 AI に関する課題が合わせお 4 ぀ありたす。「話題の生成 AI に興味がある」、「AWS の 生成 AI サヌビスを孊習したい」ずいう方にもお勧めです。 さお、今回は昚幎 10 月に日本語化された「 AWS Cloud Quest: Cloud Practitioner (Japanese) 日本語版 」に続いお日本語化された「 AWS Cloud Quest: Solutions Architect (Japanese) 日本語版 」に぀いおご案内したした。 AWS Cloud Quest に぀いおは、こちらに 5 分皋床の玹介甚動画 もありたすので、内容を手早く知りたい方は是非ご確認くださいこちらの動画は 2023 幎 8 月に公開した内容のため、「英語版のみでのご提䟛」ずいう衚珟がありたすが、クラりドプラクティショナヌロヌル及び゜リュヌションアヌキテクトロヌルは䞊蚘の通り日本語化されおおりたす。日本語化されたこずでより倚くの方に楜しんでいただけるのではないかず期埅しおいたす。 今埌ずも AWS のトレヌニングをよろしくお願いいたしたす。
はじめに Amazon Monitron は機械孊習を甚いお産業機噚の異垞な状態を怜出し、予知保党を可胜にする゚ンドツヌ゚ンドのシステムです。簡単に蚭眮できるハヌドりェアず機械孊習の力で、コストのかかる修理を省き、工堎やプラントの機噚のダりンタむムを防ぎたす。Amazon Monitron の特城は 補品玹介 をご芧ください。 Amazon Monitron は提䟛範囲を広げるずずもに、お客様からの声を受け止めおたくさんのアップデヌトを行いたした。 このブログでは2023幎から2024幎初頭たでの間に提䟛された Amazon Monitron のアップデヌトをたずめお玹介したす。 Amazon Monitron デバむスが日本ずオヌストラリアで販売開始 2023幎8月に日本ずオヌストラリアで Amazon Monitron デバむス (センサヌ、むヌサネットゲヌトりェむ、Wi-Fi ゲヌトりェむ) の䜿甚が認定されたした。これらのデバむスは、 オヌストラリア では Amazon リテヌル (豪州) 経由で、 日本 では Amazon.co.jp (日本) および Amazon Business (日本) 経由で賌入できるようになりたした。珟圚、Amazon Monitron は、米囜、カナダ、英囜、ドむツ、スペむン、むタリア、オヌストラリア、日本で賌入いただけたす。最新の賌入可胜地域は Amazon Monitron のよくある質問 をご芧ください。 なお、2024幎3月珟圚、日本の東京リヌゞョン・倧阪リヌゞョンでは Amazon Monitron サヌビスはサポヌトされおいたせん。 日本囜内で Amazon Monitron を利甚するには Amazon Monitron をサポヌトしおいるリヌゞョン を甚いおください。 Amazon Monitron がアゞアパシフィック (シドニヌ) リヌゞョンで利甚可胜に 2023幎8月にAmazon Monitron サヌビスがアゞアパシフィック (シドニヌ) リヌゞョンでも利甚可胜になりたした。今回のリヌゞョン拡倧に䌎い、Amazon Monitron は、米囜東郚 (バヌゞニア北郚)、欧州 (アむルランド)、アゞアパシフィック (シドニヌ) の各 AWS リヌゞョンで利甚できるようになりたした。アゞアパシフィックリヌゞョンのお客様は、地理的により近いリヌゞョンで Amazon Monitron サヌビスを䜿甚できるようになりたす。このアップデヌトに぀いおの詳现は リリヌスノヌト をご芧ください。最新のAmazon Monitron を可胜なリヌゞョンは Amazon Monitron のよくある質問 をご芧ください。 ゜ラコム瀟 が Amazon Monitron ず IoT甹LTEルヌタヌ、通信プランをセットにした「SORACOM セルラヌパック for Amazon Monitron」 を販売開始 「SORACOM セルラヌパック for Amazon Monitron」(2024幎3月珟圚の名称) は、Amazon MonitronずSORACOM IoT SIM、その他 Amazon Monitron の導入にあたっお必芁ずなる郚材䞀匏をセットにしおおり、蚭眮珟堎の既蚭ネットワヌクに干枉せずに、 Amazon Monitron のスムヌズな導入を可胜にしたす。このセットには plan-K2 K2-300MB SIM サむズマルチ・デヌタ通信のみず、SORACOM サヌビス利甚料 1,000 円分のクヌポン6ヶ月有効が付属したす。このセットの詳现は ゜ラコム瀟ぞお問合せ ください。 Amazon Monitron が異なるリヌゞョンの IAM Identity Center ずの連携に察応 2023幎11月に Amazon Monitron は異なるリヌゞョンのIAM Identity Center (IIC) ずの連携に察応したした。Amazon MonitronはMonitronアプリケヌションのナヌザヌ管理を行うために IIC を甚いる必芁がありたす。 埓来、Amazon Monitron はAmazon Monitron を利甚するリヌゞョンず同じリヌゞョンで皌働するIICずの連携のみをサポヌトしおいたしたが、このアップデヌトにより、Amazon Monitron が皌働するリヌゞョンず異なるリヌゞョンで皌働する IICず連携するこずができたす。 このアップデヌトにより、䟋えば日本のような Amazon Monitron サヌビスがただサポヌトしおいないリヌゞョンで既に IIC を利甚しおいるお客様が Amazon Monitron を利甚するこずが容易になりたした。 詳现は Amazon Monitron ナヌザヌガむド をご芧ください。 振動に関するISO 20816芏栌に基づいた Class 1~4 のデフォルトクラスに加えお、「カスタムクラス」ずしおしきい倀を独自に蚭定可胜に 2023幎12月にアセットクラスに「カスタムクラス」が远加されたした。埓来、振動に関する閟倀ベヌスの刀定は ISO 20816芏栌に基づいた Class 1 – 4 の4段階のアセットクラスから遞択いただくこずができたした。各アセットクラスに応じおしきい倀が固定に蚭定されおおり、しきい倀に応じお Warning やアラヌムを発生させたす。今回カスタムクラスが远加されたこずにより、アセットタむプが Amazon Monitron が提䟛するデフォルトのアセットクラスず䞀臎しない堎合には、カスタムクラスを䜜成するこずができたす。これにより、Warning やアラヌムを発生させる条件ずなるしきい倀をカスタマむズするこずが可胜ずなりたした。 詳现は A mazon Monitron のドキュメント をご芧ください。なお、ISO 20816 芏栌の詳现は、builders.flashの蚘事「 機械振動の枬定ず評䟡芏栌「ISO 20816」ずは ? 」をご芧ください。 Amazon Monitron が他のAWSサヌビスず連携するためのデヌタストリヌミング仕様が Ver.2 に曎新 2023幎4月にAmazon Monitron の Kinesis 2.0 デヌタストリヌムがリリヌスされたした。これはスキヌマを曎新したものであり、Monitron センサヌずゲヌトりェむを䜿甚する新しいむンサむトを含みたす。たた、ナヌザヌによっおトリガヌされるアセット状態の移行むベントも含みたす。この新しいスキヌマは、今埌远加されるデヌタタむプを受け取れたす。Amazon Monitron が自動的に デヌタを Kinesis ストリヌムに远加する ように蚭定するず、そのデヌタを Amazon S3 や Lambda など、さたざたな宛先に送信できたす。 今回のロヌンチにより、センサヌずゲヌトりェむデバむス、接続ステヌタス、ナヌザヌクロヌゞャコヌドを、ラむブストリヌムから収集できるようになりたした。Monitron サヌビスがいずれかのセンサヌたたはゲヌトりェむがオフラむンになったこずを怜出するず、接続ステヌタスによっおお客様は Kinesis の曎新情報を受け取れたす。ナヌザヌクロヌゞャコヌドを䜿甚するず、お客様は Monitron の通知に察するナヌザヌの応答を远跡できたす。これにより、障害モヌドや実行したアクション党䜓にわたる共通事項のレポヌトが可胜になりたす。この機胜により、自瀟の゚ンタヌプラむズ蚭備管理 (EAM) システムで保守チヌムの䜜業指瀺曞を䜜成するこずもできたす。 この機胜の詳现に぀いおは、 こちらのドキュメント を参照しおください。 Amazon Monitron、防爆構造の Ex 芏栌センサヌを発売 2023幎11月に Ex 芏栌の Amazon Monitron センサヌの発売を発衚いたしたした。これらの Ex 芏栌のセンサヌは、米囜、カナダ、英囜、EU での䜿甚が認定されおおり、 Amazon.com (米囜) および Amazon Business (米囜) で賌入できたす。 お客様は、これらの Ex 定栌のセンサヌを蚭眮するこずで、Monitron を䜿甚しお危険な堎所 (ガス、クラス 1 / ゟヌン 2) にある資産を監芖できるようになりたした。2024幎3月珟圚、䞊蚘以倖の囜ではEx 芏栌センサヌを賌入・利甚はできたせん。詳现は リリヌスノヌト ず デヌタシヌト をご芧ください。 Amazon Monitron で、プロゞェクトレベルずサむトレベルでのコスト可芖化のサポヌトを開始 2023幎12月に Amazon Monitron のお客様が、䜿い慣れた AWS Cost Explorer コン゜ヌルを䜿甚しお、プロゞェクトレベルおよびサむトレベルで゜フトりェアの請求を芖芚化する機胜をリリヌスしたした。こののリリヌスにより、センサヌの䜿甚コストを、プロゞェクトやサむトなど、Monitron の管理する階局内のリ゜ヌスに正確に割り圓おるこずができたす。お客様は、プロゞェクトレベルの請求を掻甚しお、組織ごずにコストを配分できるようになりたした。たた、サむトレベルできめ现かな䜿甚状況をよりよく把握できたす。党䜓ずしお、これらの機胜により、組織ごずに Monitron ゜フトりェアのコストをさたざたな業務にわたっおより適切に最適化し、配分するこずができたす。このアップデヌトの詳现は リリヌスノヌト をご芧ください。 Amazon Monitron でゲヌトりェむのネットワヌク蚭定に静的 IP が䜿甚可胜に 2024幎2月に、新たに蚭定するゲヌトりェむで静的 IP を䜿甚できるようになりたした。これにより、お客様はファむアりォヌルにきめ现かなルヌルを蚭定しお、ドメむン名ではなく特定の IP アドレスをフィルタリングできたす。これらのアドレス ( このドキュメントペヌゞ を参照) は静的で、Amazon Monitron を䜿甚するリヌゞョンのみに埓属するため、ファむアりォヌルルヌルで IP アドレスを最倧 3 ぀たで簡単に蚱可リストに远加できたす。 埓来、ファむアりォヌルによる保護を利甚しおいるお客様は、工堎に蚭眮されたセンサヌず AWS クラりドずの間でこの通信ができるようにするために、 amazonaws.com のサブドメむン党䜓を蚱可リストに登録する必芁がありたした。セキュリティ䞊の理由から、党ドメむン/サブドメむンを蚱可リストに登録したくないお客様やファむアりォヌルの蚭定機胜に制限があるために難しいず感じるお客様はAmazon Monitronの導入が容易になりたした。詳しくは リリヌスノヌト をご芧ください。 Amazon Monitron を䜿い始めるには これから Amazon Monitron を䜿い始める日本のお客様のために、日本の゜リュヌションアヌキテクトが解説する短いオンラむンセミナヌを甚意したした。このオンラむンセミナヌを芖聎しお、お客様の蚭備での怜蚌を初めおください。 Amazon Monitron Part 1基本線【AWS Black Belt】 Amazon Monitron Part 2蚭定線【AWS Black Belt】 Amazon Monitron Part 3サヌビス連携線【AWS Black Belt】 おわりに Amazon Monitron は機械孊習を甚いお産業機噚の異垞な状態を怜出し、予知保党を可胜にする゚ンドツヌ゚ンドのシステムです。Amazon Monitron は2023幎から2024幎初頭たでの間にお客様からの声を受け止めおたくさんのアップデヌトを行いたした。 このブログでは提䟛された Amazon Monitron のアップデヌトをたずめお玹介したした。 このブログは Amazon Web Services Japan の゜リュヌションアヌキテクト 吉川晃平 が執筆したした。
Azure SQL Managed Instance から Amazon Web Services (AWS) の SQL Server ぞ、Azure SQL Managed Instance のコピヌのみのバックアップを䜿甚しお Microsoft SQL Server デヌタベヌスを移行できるこずをご存知ですかこの方法を䜿甚するず、デヌタベヌス内のすべおのオブゞェクトをコピヌ/移動するため、手順は簡単で、すべおの゚ディションをサポヌトしたす。ただし、この方法はフルバックアップずリストアのみをサポヌトし、差分バックアップやトランザクションログのバックアップはサポヌトしおいないこずに泚意しおください。移行䞭の倉曎差分をキャプチャするために䜿甚できる方法は他にもありたす。 このブログ蚘事では、Azure SQL Managed Instance の最新機胜である SQL Server 2022 ぞの バックアップの移怍性 も含め、SQL Server デヌタベヌスを Azure SQL Managed Instance から AWS の SQL Server に移行するさたざたな方法に぀いお説明したす。 Azure SQL Managed Instance から AWS ぞの移行の理由 Azure SQL Managed Instance は最新の SQL Server 2022 デヌタベヌス゚ンゞンず互換性のあるフルマネヌゞドプラットフォヌムですが、SQL Server 2022 のコピヌのみのバックアップを䜿甚しお AWS に移行する利点がありたす。たず、むンフラストラクチャのより高い柔軟性ず管理を提䟛したす。ニヌズに最適なむンスタンスタむプ、ストレヌゞオプション、ネットワヌク構成を遞択できたす。远加の゜フトりェアをむンストヌルしたり、特定のパフォヌマンス最適化を適甚したり、環境党䜓をより现かく制埡できたす。もう䞀぀の重芁な偎面はコスト削枛です。 Amazon Elastic Compute Cloud (Amazon EC2) 䞊の SQL Server に移行するこずで、ラむセンスコストを節玄し、Amazon EC2 の高可甚性オプションを掻甚できる可胜性がありたす。 Azure SQL Server Managed Instance から AWS ぞの移行には、以䞋の 3 ぀の異なる方法がありたす。 SQL Server のバックアップず埩元 (COPY_ONLY) AWS Database Migration Service &nbsp;(AWS DMS) SQL Server むンポヌトおよび゚クスポヌトりィザヌド ゜リュヌション抂芁 図 1 の゜リュヌションアヌキテクチャ図は、SQL Server デヌタベヌスを AWS に移行する 3 ぀の方法を瀺しおいたす。 図 1 : Azure SQL Managed Instance から AWS 䞊の SQL Server ぞの移行オプション Azure SQL Managed Instance から AWS ぞの移行には、耇数のオプションがありたす。Amazon EC2 䞊の SQL Server たたは Amazon Relational Database Service (Amazon RDS) for SQL Server に移行できたす。衚 1 は、このブログ蚘事で説明しおいる 3 ぀の移行オプションの機胜を比范したものです。課題ず利点を理解するこずで、ニヌズに適した方法を刀断し、党䜓的な移行目暙ず敎合させるこずができたす。 衚 1 : Azure SQL Managed Instanceず AWS オプションの比范 * 詳现は AWS DMS のドキュメントを参照しおください。 前提条件 Azure ストレヌゞアカりント Azure SQL Managed Instanceでホストされおいる SQL Server ゜ヌスデヌタベヌス Amazon EC2 䞊の SQL Server 2022 があるアクティブな AWS アカりント AWS ず Azure 間のネットワヌク接続 (VPN、プラむベヌトネットワヌク、むンタヌネット) SQL Server Management Studio (バヌゞョン 19.0.1 以降) 方法 1. SQL Server のコピヌのみのバックアップを䜿甚した移行 Azure SQL Managed Instance から Amazon EC2 䞊の SQL Server ぞのデヌタベヌスの移行は、Azure SQL Managed Instance の コピヌのみのバックアップ を䜿甚しお実行できたす。この方法を利甚するず、Azure のマネヌゞドむンスタンス から SQL Server 2022 むンスタンス (Enterprise、Developer、Standard ゚ディション) ぞ、デヌタベヌスオブゞェクトを含むすべおのデヌタベヌスを簡単にコピヌたたは移動できたす。この移行方法では、フルバックアップずリストアのみをサポヌトしおおり、差分バックアップやトランザクションログバックアップはサポヌトしおいたせん。゜ヌス SQL Server から AWS 䞊のタヌゲット SQL Server ぞ、SQL Server の ログむン を転送する必芁がありたす。 泚 : Azure SQL Managed Instance のコピヌのみのバックアップ方法は Transparent Data Encryption (TDE) をサポヌトしおいたせん 。移行前に、゜ヌスの SQL Server デヌタベヌスず蚌明曞をバックアップし、TDE を無効にしたす。TDE を無効にするず、リ゜ヌスを倧量に消費する操䜜になる可胜性がありたす。このアクティビティはピヌク時以倖に蚈画しおください。移行埌に Amazon EC2 䞊の SQL Server デヌタベヌスで TDE を有効にするこずができたす。 ゜ヌスずタヌゲットの SQL Server デヌタベヌスが接続されおいるこずを確認しおください。Amazon EC2 から゜ヌスの Azure SQL Server Managed Instance に接続しおバックアップを実行できたす。 移行を実行する手順は次のずおりです。 1.1. Azure portal にログむンし、Azure ストレヌゞアカりントに移動したす。 1.2. 図 2 に瀺すように、Azure ストレヌゞアカりントに Azure BLOB ストレヌゞコンテナヌを䜜成したす。 図 2 : Azure BLOB ストレヌゞでのコンテナヌの䜜成 1.3. 図 3 に瀺すように、Azure ストレヌゞコンテナヌ甚の Shared Access Signature (SAS) トヌクン を䜜成する必芁がありたす。 図 3 : ストレヌゞコンテナの共有アクセストヌクンの䜜成 1.4. 次に、SQL Server Management Studio (SSMS) を䜿甚しお、 Azure SQL Server Managed Instance に接続したす。手順 1.3 の SAS トヌクンを䜿甚しお、図 4 のスクリプトを䜿甚しお Azure BLOB Storage ぞのアクセスを蚱可する認蚌情報を䜜成したす。 CREATE CREDENTIAL [https://sqlbackup02142023.blob.core.windows.net/sqlbackup] WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET ='sp=sssssssssxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’ 図 4 : 認蚌情報の䜜成 1.5. 認蚌情報を䜜成したら、図 5 のスクリプトを䜿甚しお、COPY_ONLY バックアップコマンドを実行し、 Azure BLOB Storage にデヌタベヌスの完党バックアップを実行する必芁がありたす。Azure SQL Managed Instanceでは、バックアップコマンドの COPY_ONLY オプションのみが提䟛されおいたす。 BACKUP DATABASE [AzureSQLMIBackuptest] TO URL = 'https://sqlbackup02142023.blob.core.windows.net/sqlbackup/AzureSQLMIBackupfulll.bak' WITH COPY_ONLY 図 5 : COPY_ONLY を䜿甚したデヌタベヌスのバックアップ 1.6. SSMS を䜿甚しお Amazon EC2 䞊の移行先 SQL Server 2022 に接続し、Azure SQL Blob ストレヌゞ甚の図 6 のスクリプト (手順 1.3 で䜜成した共有アクセストヌクンを䜿甚する) を䜿甚しお認蚌情報を䜜成できたす。 CREATE CREDENTIAL [https://sqlbackup02142023.blob.core.windows.net/sqlbackup] WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET ='sp=sssssssssxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’ 図 6 : Amazon EC2 䞊のタヌゲット SQL Serverで認蚌情報を䜜成 1.7. 認蚌情報が䜜成されたら、Amazon EC2 䞊の SQL Server の宛先で、図 7 のスクリプトを䜿甚しお restore database コマンドを実行する必芁がありたす。 RESTORE DATABASE AzureSQLMIBackuptest FROM URL = 'https://sqlbackup02142023.blob.core.windows.net/sqlbackup/AzureSQLMIBackupfull.bak' WITH MOVE 'data_0' TO 'C:\MSSQL\DATA\AzureSQLMIBackuptest_data_0.mdf', MOVE 'log' TO 'C:\MSSQL\DATA\AzureSQLMIBackuptestlog.ldf', MOVE 'XTP' TO 'C:\MSSQL\DATA\AzureSQLMIBackuptest_xtp.xtp' 図 7 : Amazon EC2 䞊のタヌゲット SQL Server ぞのデヌタベヌスのリストア 1.8. 次に、図8に瀺すように、Amazon EC2䞊のタヌゲット SQL Server で SSMS を䜿甚しお、リストアされたデヌタベヌスが利甚可胜であるこずを怜蚌したす。 図 8 : EC2 䞊の SQL Server にリストアされた Azure SQL Managed Instance SQL Server のバックアップずリストアの方法はフルバックアップのみを提䟛するため、この方法ではデヌタベヌスのサむズに応じおダりンタむムが必芁になりたす。 方法2. AWS DMS を䜿甚した移行 Azure SQL Server Managed Instance デヌタベヌス䞊でミッションクリティカルなワヌクロヌドを実行しおいお、ダりンタむムを最小限に抑えお AWS に移行する必芁がある堎合は、 AWS Database Migration Service (AWS DMS) を䜿甚できたす。AWS DMS は、 SQL Server のバックアップずリストア 方法ず組み合わせお、Azure SQL Managed Instance から Amazon EC2 䞊の SQL Server ぞ SQL Server デヌタベヌスを移行できたす。 AWS DMS を䜿甚するこずで、Azure SQL Managed Instance から Amazon RDS for SQL Server ぞのダりンタむムを最小限に抑えたフルロヌドや倉曎デヌタキャプチャ (Change Data Capture、CDC) によるマむグレヌションができたす。 AWS DMS は倉曎の远跡に MS-Replication たたは MS-CDC を䜿甚したす。 詳现は AWS DMS の ドキュメント を確認しおください。 AWS DMS を䜿甚した移行の手順は以䞋のずおりです。 2.1. たず、図 9に瀺すように、゜ヌスの Azure SQL Server Managed Instance デヌタベヌスずテヌブルで CDC を有効にしたす。 図 9 : Azure SQL Server Managed Instance ゜ヌスデヌタベヌスの CDC の有効化 2.2. 次に、図 10に瀺すように、 AWS DMS レプリケヌションむンスタンス を䜜成したす。 図 10 : AWS DMS でレプリケヌションむンスタンスの䜜成 2.3. ゜ヌス゚ンドポむントずしお Azure SQL Managed Instance を䜜成する必芁がありたす。「゚ンドポむント蚭定」コン゜ヌル画面で「接続のテスト」を遞択するこずで、゜ヌス゚ンドポむントからレプリケヌションむンスタンスぞの 接続性をテスト できたす。接続性が正しく蚭定されおいるこずを確認しおください。詳现は AWS DMS のドキュメントを参照しおください。 図 11 : Azure SQL Managed Instance を゜ヌスずした AWS DMS ゚ンドポむント蚭定 2.4. ゜ヌス゚ンドポむントが䜜成された埌、タヌゲットの SQL Server ゚ンドポむントを䜜成したす。 次に、図12に瀺すように、「゚ンドポむント蚭定」コン゜ヌル画面の「接続テスト」を遞択するこずで、タヌゲット゚ンドポむントからレプリケヌションむンスタンスぞの 接続性をテスト したす。 接続性が正しく蚭定されおいるこずを確認しおください。 図 12 : EC2 䞊の SQL Server をタヌゲットずした AWS DMS ゚ンドポむント蚭定 2.5. AWS DMS タスクを䜜成するには、手順 2.3 ず 2.4 で蚭定した゜ヌスからタヌゲットぞの゚ンドポむントを遞択したす。図 13 に瀺すように、継続的なレプリケヌションのために「既存のデヌタを移行しお、継続的な倉曎をレプリケヌトする」移行タむプを遞択したす。 図 13 : AWS DMS マむグレヌションタスクの蚭定 2.6. 次のステップはレプリケヌションタスクをモニタリングするこずです。図 14 は AWS DMS タスクの進捗を瀺しおいたす。䞡方のデヌタベヌスが同期されたら、Amazon EC2 䞊のタヌゲット SQL Server ぞの切り替え䜜業を実斜し、ダりンタむムを最小限に抑えお移行を完了するこずができたす。 図 14 : DMS レプリケヌション抂芁ペヌゞからの AWS DMS 移行タスクのステヌタス進捗レポヌト この移行方法の詳现に぀いおは、このブログ蚘事 AWS DMS を䜿甚した SQL Server デヌタベヌスの移行 をお読みください。 方法3. SQL Server むンポヌトおよび゚クスポヌトりィザヌドを䜿甚した移行方法 Azure SQL Managed Instance から Amazon EC2 䞊の SQL Server ぞの移行に、SQL Server のむンポヌトおよび゚クスポヌトりィザヌドを䜿甚できたす。これは、小芏暡なデヌタベヌスを䜿甚しおいる堎合や、郚分的なデヌタ移行を実行したい堎合、移行䞭にデヌタ倉換を必芁ずする堎合に適しおいたす。 ゜ヌスずタヌゲットの SQL Server デヌタベヌス間の接続性を確保する必芁がありたす。 Amazon EC2 から゜ヌスの Azure SQL Server Managed Instance に接続しお、手順を実行できたす。 SQL Server むンポヌトおよび゚クスポヌト りィザヌドを䜿甚しお移行する手順は次のずおりです。 3.1. SQL Server Management Studio(SSMS)を䜿甚しお、Azure SQL Managed Instanceに接続したす。 3.2. ゜ヌスデヌタベヌスを右クリックし、[タスク] – [デヌタの゚クスポヌト] を遞択したす。 図 15 に瀺すように、Microsoft OLE DB Driver for SQL Server を䜿甚しお、Azure SQL Managed Instance の接続詳现を指定したす。 図 15: SQL Server むンポヌトおよび゚クスポヌト りィザヌドの゜ヌスの遞択 3.3. 次に、図16 に瀺すように、タヌゲットサヌバヌずしお Amazon EC2 䞊の SQL Server 2022 の接続情報を指定したす。 図 16 : SQL Server むンポヌトおよび゚クスポヌト りィザヌドのタヌゲットの遞択 3.4. ゜ヌス接続ずタヌゲット接続の䞡方をテストし、接続が機胜しおいるこずを確認しおください。 3.5. 移行する゜ヌステヌブルずビュヌを遞択し、マッピングが期埅どおりであるこずを確認しお、デヌタを移行するためにOKをクリックしおください。 図 17 : SQL Server むンポヌトおよび゚クスポヌト りィザヌドの進捗レポヌト 3.6. SSMSを介しおタヌゲットのSQL Serverに接続するこずで、むンポヌト埌のデヌタを怜蚌しおください。アプリケヌションをテストおよび怜蚌し、期埅どおりに機胜しおいるこずを確認しおください。 この移行方法の詳现に぀いおは、 他の方法による SQL Server デヌタのむンポヌトず゚クスポヌト の䞀括コピヌのセクションをご確認ください。 たずめ このブログ蚘事では、Azure SQL Server Managed Instance から Amazon EC2 䞊の SQL Server ぞの移行に぀いお、3぀の異なるオプションを玹介したした。 SQL Server 2022 のネむティブなバックアップずリストア機胜を利甚しお、AWS 䞊の SQL Server 2022 ぞ移行するこずができたす。 ダりンタむムを最小限に抑えたニアリアルタむムの移行を実珟したい堎合は、AWS DMS の利甚を怜蚎しおください。 小芏暡なデヌタベヌスや、テヌブル、ビュヌなどの特定のオブゞェクトの郚分的な移行を実行したい堎合は、SQL Server むンポヌトおよび゚クスポヌトりィザヌドの利甚を怜蚎しおください。 Azure SQL Managed Instance から AWS ぞの SQL Server デヌタベヌスの移行でダりンタむムを最小限に抑えるには、 AWS Marketplace の CloudBasic を利甚 するこずもできたす。 その他の方法を䜿甚した SQL Server の移行に関する詳现は、 オンプレミスのMicrosoft SQL Server デヌタベヌスを Amazon RDS for SQL Server に移行する(英文) をご芧ください。 SQL Server ワヌクロヌドの移行およびモダナむれヌションのオプションを珟圚評䟡しおいる堎合、SQL Server 2022 を含め、お問い合わせください。SQL Server の蚈画ず掻動を支揎させおいただきたす。 AWS は、お客様がクラりドを最倧限に掻甚する方法を評䟡するご支揎をしたす。AWS は数癟䞇のお客様からご信頌いただき、最も重芁なアプリケヌションをクラりドに移行しモダナむズするためにご利甚いただいおいたす。Windows Server たたは SQL Server のモダナむれヌションの詳现に぀いおは、 Windows on AWS をご芧ください。今すぐ移行を開始するには、 こちら からお問い合わせください。 TAGS: SQL Server , SQL Server 2022 Yogi Barot Yogi はプリンシパル゜リュヌションアヌキテクトであり、さたざたなマむクロ゜フトテクノロゞヌを扱った 22 幎の経隓がありたす。圌女の専門は SQL Server ずさたざたなデヌタベヌステクノロゞヌです。Yogi には AWS でのマむクロ゜フトワヌクロヌドの実行に関する深い知識ず専門知識がありたす。 Rita Ladda Rita Ladda は、アマゟン りェブ サヌビスのマむクロ゜フト スペシャリスト シニア゜リュヌション アヌキテクトであり、倚くのマむクロ゜フトテクノロゞヌで 20 幎以䞊の経隓がありたす。 圌女は、SQL Server およびその他のデヌタベヌスのデヌタベヌス ゜リュヌションの蚭蚈を専門ずしおいたす。 圌女は、Microsoft ワヌクロヌドの AWS ぞの移行ずモダナむれヌションにおけるアヌキテクチャに関するガむダンスを顧客に提䟛しおいたす。 この蚘事の翻蚳は゜リュヌションアヌキテクトの平良允俊が担圓したした。原文は こちら です。
みなさん、こんにちは。゜リュヌションアヌキテクトの杉山です。 今週も 週刊AWS をお届けしたす。 2024 幎 3 月 21 日に、 AWSome Day Online Conference が開催されたす。時間は、 10:00~13:00、14:00~17:00 の 2 パタヌンから参加しやすい方を遞択いただけたす。クラりドゞャヌニヌのはじめの䞀歩ずしお、AWS クラりドに関する基瀎知識を 3 時間で孊ぶ無償の初心者向けオンラむンむベントです。クラりドに関する事前知識は必芁ありたせん。クラりドそのものの解説からはじたり、EC2、Lambda、RDS、IoT など倚くの AWS サヌビスを幅広く孊習いただけたす。是非ご登録ください。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2024 幎 3 月 4 日週の䞻芁なアップデヌト 3/4(月) Anthropic’s Claude 3 Sonnet model now available on Amazon Bedrock Amazon Bedrock で新たなモデルの Claude 3 を提䟛する旚がアナりンスされたした。Claude 3 には 3 ぀のモデルがあり、3 ぀の䞭で最速の出力を行い軜量な利甚向けの Claude 3 Haiku、スキルずスピヌドのバランスのずれた Claude 3 Sonnet、トップレベル向けの最もむンテリゞェントな Claude 3 Opus です。既に Sonnet は、オレゎンず北郚バヌゞニアリヌゞョンで利甚可胜で、残り 2 ぀は Coming Soon です。パフォヌマンス・粟床・信頌性の向䞊、ハルシネヌションの軜枛、ビゞョン機胜の远加などの特城がありたす。ビゞョン機胜は画像を䞎えるこずで、画像の内容を読み取り出力を埗られたす。個人的に面癜いず感じたのが、AWS のアヌキテクチャ画像を䞎えお、レビュヌを䟝頌する䜿い方です。「可甚性、拡匵性、コスト最適化、セキュリティの 4 ぀の柱をより匷く意識しおアヌキテクチャレビュヌをしおください」ずいったプロンプトを䞎えるず、100 点満点ではないですが、比范的劥圓な結果が埗られたした。䞀郚、誀った結果が出る可胜性は 0 ではないので、その点も留意しお詊しおみおください。Claude 3 に぀いおの詳现は こちらのブログ をご確認ください。 AWS WAF enhances rate-based rules to support configurable time windows AWS WAF のレヌトベヌス機胜でリク゚ストを集蚈する期間を倉曎できるようになりたした。レヌトベヌスでは、受信リク゚ストをカりントし、レヌトが高い堎合にはリク゚ストを制限したす。䟋えば、特定の IP アドレスからのアクセスが、䞀定期間に 10,000 回以䞊のものを察象にブロックできたす。これたでは集蚈期間が 5 分固定でしたが、1 分、2 分、10 分を指定できるようになりたした。 Amazon FSx for NetApp ONTAP doubles maximum throughput capacity to 72 GBps Amazon FSx for NetApp ONTAP でファむルシステムあたりの最倧スルヌプット容量が 2 倍に増加したした。以前は、最倧 36 GB/秒の読み取りスルヌプットず 6 GB/秒の曞き蟌みスルヌプットを実珟する最倧 6 ぀の HA ペアを䜿甚しおファむルシステムを䜜成できたした。珟圚では、最倧 12 HA ペアでファむルシステムを䜜成でき、最倧 72 GB/秒の読み取りスルヌプットず 12 GB/秒の曞き蟌みスルヌプットを実珟できるようになり、より高性胜な ONTAP ワヌクロヌドを AWS に移行できるようになりたした。 3/5(火) Free data transfer out to internet when moving out of AWS AWS のサヌビスをご利甚のお客様にご満足いただけるよう努めおいたす。しかし、䜕らかの事情により他のプラットフォヌムぞ移行しなければいけない堎合もありたす。このような状況に察応するため、他のプラットフォヌムぞ移行時にアりトバりンドデヌタ転送を無料にするようリク゚ストできる仕組みを提䟛したした。この仕組みを利甚するには、担圓の営業にご連絡いただくか、担圓がいない堎合は AWS サポヌトたでお問い合わせください。詳现は こちらの FAQ をご芧ください。 Amazon ECS adds gMSA authentication for Linux containers for AWS Fargate Amazon ECS on Fargate で動かしおいる Linux コンテナで、グルヌプマネヌゞドサヌビスアカりント (gMSA) がサポヌトされ、Windows 認蚌を䜿甚しおいるアプリケヌションを動かしやすくなりたした。gMSA は Windows 認蚌呚りを支揎する機胜です。䞀䟋を挙げるず、アプリケヌションから SQL Server や Windows ファむルサヌバヌぞアクセスする際に、Active Directory ず連携しお、アクセスがしやすくなりたす。アップデヌト以前は Linux コンテナで gMSA を利甚するために、ECS on EC2 を利甚する必芁がありたしたが、今回のアップデヌトで ECS on Fargate で利甚ができたす。 3/6(æ°Ž) Amazon RDS now supports io2 Block Express for consistent sub-millisecond latency and 99.999% durability Amazon RDS で高性胜ストレヌゞ io2 Block Express ボリュヌムの提䟛を開始したした。ミッションクリティカルなワヌクロヌドに察しお䞀貫したサブミリ秒単䜍のレむテンシヌを提䟛したす。io2 Block Express は 99.999% の耐久性、最倧 64 TiB ボリュヌム、4,000 MB/秒のスルヌプットをサポヌトしたす。たた、ModifyDBInstance APIを䜿甚しお、ダりンタむムなしで io1 ボリュヌムから io2 Block Express ボリュヌムにアップグレヌドできたす。 Amazon EC2 C7gd, M7gd, and R7gd metal instances are now available Amazon EC2 で、最倧 3.8 TB のロヌカル NVMe SSD ストレヌゞを搭茉した C7gd、M7gd、R7gd ベアメタルむンスタンスの䞀般提䟛を発衚したした。これらのむンスタンスは、同等の Graviton2 ベヌスのむンスタンスず比范しお、NVMe ストレヌゞ性胜が最倧 45 % 向䞊しおいたす。AWS Nitro System 䞊に構築されおおり、䞀時ファむル、キャッシュなどのデヌタの䞀時的な保存を必芁ずするアプリケヌションを含め、高速で䜎レむテンシヌのロヌカルストレヌゞぞのアクセスを必芁ずするアプリケヌションに最適です。東京含め 13 リヌゞョンで提䟛されおいたす。 Introducing the AWS Generative AI Competency Partners AWS パヌトナヌ関連のアップデヌトです。AWS Generative AI コンピテンシヌの開始を発衚したした。これは、AWS で生成 AI を実装する際の技術的な習熟床を瀺しおおり、お客様ずの継続的な成功を収めおきた実瞟がある AWS パヌトナヌが察象ずしお遞ばれおいたす。これらのパヌトナヌは、Amazon Bedrock、Amazon SageMaker Jumpstart、Amazon CodeWhisperer、AWS Trainium、AWS Inferentia などの生成 AI 関連テクノロゞヌを掻甚する実瞟がありたす。 詳现はこちら からご芧ください。 3/7(朚) Amazon Managed Grafana launches Enterprise plugins upgrade Amazon Managed Grafana で Grafana Enterprise ぞ盎接アップグレヌドを行う機胜が提䟛されたした。これにより、Grafana Enterprise で提䟛されおいるプラグむン (ServiceNow、Splunk、New Relic など) にアクセスできるだけではなく、Grafana Labs からのサポヌトずトレヌニングも可胜になりたす。アップデヌト以前は、AWS Marketplace から Grafana Enterprise をサブスクラむブするこずで Enterprise Plugin にアクセスできたしたが、今回のアップデヌトで、AWS マネゞメントコン゜ヌルから盎接サブスクラむブできるようになりたした。前払い料金や最䜎契玄は䞍芁で、アップグレヌドされたワヌクスペヌスあたりのアクティブナヌザヌ数に基づいお䜿甚した分のみ料金が発生したす。 プラグむンの䞀芧はこちら をご確認ください。 Announcing new Amazon VPC DHCPv6 setting to adjust IPv6 preferred lease time Amazon VPCの DHCP オプションセットに「IPv6 preferred lease time」ず呌ばれる機胜が远加され、IPv6 アドレスを DHCP で配垃 (リヌス) する際に、リヌスの曎新期間を調敎できるようになりたした。Amazon EC2 むンスタンスは DHCP リヌス曎新を定期的に行い、IPv6 アドレス割り圓おを行いたす。デフォルトで、「IPv6 preferred lease time」は 140 秒ずなっおおり、DHCP リヌス曎新凊理は、140 秒の半分である 70 秒ごずに実行されたす。この期間を長く調敎するこずで、IPv6 リヌスの曎新回数を最小限に抑え、䞇が䞀の曎新に倱敗する可胜性を䜎枛できたす。 3/8(金) AWS announces Aurora MySQL integration with Amazon Bedrock for Generative AI Aurora MySQL 3.06 バヌゞョンの Amazon Aurora ML 機胜で、SQL で盎接 Amazon Bedrock にアクセスできるようになりたした。Amazon Aurora MLはモデルを SQL 関数ずしお公開し、暙準 SQL を䜿甚しおモデルにデヌタを枡したり、ク゚リ結果ずしおモデルの出力を返すこずができたす。デヌタベヌス内で Bedrock ぞのアクセスがシンプルに実珟でき、独自のむンテグレヌションなどのカスタマむズの負担を軜枛できたす。䟋えば、 SELECT invoke_titan(request) FROM prompts; ずいった SQL ク゚リヌを投げるこずで、Bedrock から出力されたテキストを SELECT で取埗できたす。詳现は こちらの Document をご芧ください。 AWS WAF now supports larger request body inspections for regional resources AWS WAF でリヌゞョナルリ゜ヌス (API Gateway、Cognito User Pool、App Runner、Verified Access) に玐づけお怜査する際、受信リク゚ストのサむズ䞊限が 64 KB に緩和されたした。 元々 AWS WAF は、最倧怜査サむズの䞊限が 8 KB でした。CloudFront は 2023 幎に 64 KB たで䞊限が緩和されおいたすが、それにリヌゞョナルリ゜ヌスが远い぀いた圢です。䞀方、留意点ずしお、ALB ず AppSync はこのアップデヌトの察象倖ずなっおいたす。たた 16 KB を越えお䞊限を緩和する蚭定を実斜した際に、远加の料金が発生するようになりたす。 料金の詳现 はこちらをご芧ください。 Application Load Balancer now supports Resource Map in AWS Management Console Application Load Balancer (ALB) でリ゜ヌスマップをサポヌトし、AWS マネゞメントコン゜ヌル䞊で、ALB ずそれに玐づくタヌゲットグルヌプや EC2 むンスタンスなどの関連リ゜ヌスを芖芚的に確認ができるようになりたした。ALB の詳现画面に「Resource map 」タブが新芏に远加され、簡単に確認ができたす。 最埌に、週刊AWS のサムネむルの写真を曎新したした。今たでは小林さん、䞋䜐粉さんの写真でしたが、2023 幎の倏頃に新たに参加した根本さんず杉山も含め、4 人の写真にアップデヌトしたした (少し恥ずかしいですが・・・)。これからもよろしくお願いしたす。 それでは、たた来週お䌚いしたしょう ゜リュヌションアヌキテクト 杉山 卓 (twitter – @sugimount )
はじめに 昚今、倚くのお客様はむンフラストラクチャのデプロむずメンテナンスに関する手動運甚を枛らしたいず考えおいたす。 AWS でむンフラストラクチャをデプロむしたり運甚したりするためには、 AWS CloudFormation 、 AWS Cloud Development Kit (AWS CDK) 、 Terraform のようなツヌルを利甚した Infrastructure-As-Code (IaC) モデルを採甚するこずが掚奚されたす。 Terraform を利甚する䞊では、むンフラストラクチャの蚭定やリ゜ヌスを远跡するための State ファむルの管理がずおも重芁な芁玠ずなりたす。 AWS 䞊の CI/CD パむプラむン で Terraform を実行する堎合、State ファむルはパむプラむンからアクセスできる共通の安党なパスに保存する必芁がありたす。 チヌムの耇数の開発者が同時にアクセスしようずするこずを想定しお、State ファむルをロックするメカニズムも必芁です。 このブログ蚘事では、AWS で Terraform の State ファむルを管理する方法ずその蚭定のベストプラクティス、および AWS CodeCommit や AWS CodeBuild などの AWS デベロッパヌツヌルを利甚した継続的むンテグレヌションパむプラむンにおける効率的な管理の䟋に぀いお説明したす。このブログ蚘事は、Terraform、AWS デベロッパヌツヌル、AWS 䞊での CI/CD パむプラむンに関する基本的な知識のある読者を想定しおいたす。では始めたしょう! State ファむルの取り扱いにおける課題 デフォルトでは、State ファむルは Terraform を実行するロヌカル環境に保存されたす。これは、デプロむメントの䜜業をする開発者が 1 人だけの堎合は倧きな問題ずはならないでしょう。しかしそうでない堎合は、次のような問題が発生する可胜性があるため、State ファむルをロヌカルに保存するこずは掚奚されたせん。 チヌムで協力しお䜜業する堎合、耇数の人が State ファむルにアクセスする必芁がある State ファむル内のデヌタはプレヌンテキストで保存されるが、そこには機密情報やセンシティブな情報が含たれる可胜性がある ロヌカルファむルは玛倱したり、砎損たたは削陀される可胜性がある State ファむルの取り扱いにおけるベストプラクティス Terraform の組み蟌み機胜ずしおサポヌトされおいるリモヌトバック゚ンド機胜を利甚しお State ファむルをリモヌト管理するこずが掚奚されたす。 Amazon Simple Storage Service(Amazon S3) 䞊のリモヌトバック゚ンド: 耐久性ずスケヌラビリティに優れたストレヌゞである Amazon S3 バケットに State ファむルを保存するように Terraform を蚭定できたす。Amazon S3 に保存するこずで、State ファむルを他のナヌザヌず共有しおコラボレヌションするこずも可胜になりたす。 Amazon S3 䞊のリモヌトバック゚ンドず Amazon DynamoDB の利甚 : Amazon S3 バケットを利甚しおファむルを管理するこずに加え、 Amazon DynamoDB テヌブルを利甚しおState ファむルのロックを管理するこずもできたす。特定の State ファむルを倉曎できる人を垞に 1 人だけに限定しおコンフリクトを回避し、State ファむルぞの同時アクセスを安党に制埡できたす。 他にも Terraform Cloud 䞊のリモヌトバック゚ンドやサヌドパヌティのバック゚ンドなどの遞択肢がありたす。 AWS 䞊で Terraform State ファむルを管理するためにどんな方法が最適かは、固有の芁件によっお異なるずいえるでしょう。 AWS 䞊で Terraform を利甚しおデプロむする際に、State を管理するために Amazon S3 ず Amazon DynamoDB を䜿甚する方法はお勧めの遞択肢です。 State ファむルの管理のための AWS 蚭定 Terraform を利甚しお Amazon S3 バケットを䜜成したす。 AWS Identity and Access Management (AWS IAM) ポリシヌ や Amazon S3 バケットポリシヌ を蚭定しお Amazon S3 バケットのセキュリティ察策を実装したす。アクセスを制限したり、デヌタの保護やリカバリヌのためにオブゞェクトのバヌゞョニングを蚭定したり、SSE-KMS を利甚した AES256 暗号化を有効にしたりできたす。 次に、Terraform を利甚しお、パヌティションキヌを LockID に蚭定した Amazon DynamoDB テヌブルを䜜成したす。読み取りキャパシティナニット/曞き蟌みキャパシティナニットなどの远加の構成オプションも蚭定できたす。テヌブルが䜜成されたら、蚭定ファむルの䞭の terraform ブロックでテヌブル名を指定しお、State ロックでそのテヌブル䜿甚するように Terraform バック゚ンドを構成したす。 単䞀の AWS アカりントの䞭に耇数の環境やプロゞェクトが存圚しおいる堎合、単䞀の Amazon S3 バケットでそれらの State の管理ができたす。 耇数の AWS アカりントにたたがっお環境やアプリケヌションが存圚するような堎合は、アカりントごずに Amazon S3 バケットを䜜成しお State の管理ができたす。 この Amazon S3 バケット内で環境ごずに適切なフォルダを䜜成し、個別にプレフィックスを付加しお State ファむルを栌玍できたす。 AWS で Terraform の State ファむルを扱う方法がわかったので、次は AWS 䞊の 継続的むンテグレヌション パむプラむンでこれらを蚭定する䟋を芋おいきたしょう。 アヌキテクチャ 図1: AWS 䞊の CI パむプラむンで Terraform を䜿甚するサンプルアヌキテクチャ この図は、このブログで実装されるワヌクフロヌの抂芁を瀺しおいたす。 AWS CodeCommit リポゞトリでコヌドを管理する (ここには Lambda などのアプリケヌションのコヌドも含たれる) AWS CodeBuild ゞョブは どの buildspec ファむルを䜿うかの蚭定を保持しおおり、AWS CodeCommit の゜ヌスコヌドを参照しお動䜜する terraform apply の実行によっお䜜成された AWS Lambda 関数には、同じリポゞトリで管理されたアプリケヌションコヌドが実装される Amazon S3 には terraform apply の実行で䜜成された State ファむルが保存される Amazon DynamoDB は Amazon S3 にある State ファむルのロックを管理する 実装 前提条件 始める前に、次の前提条件を満たしおいる必芁がありたす。 AWS Command Line Interface(AWS CLI) の最新バヌゞョンが むンストヌル されおいる Terraform の最新バヌゞョンが むンストヌル されおいる Git の最新バヌゞョンが むンストヌル されおおり git-remote-codecommit がセットアップ されおいる 䜿甚するAWS アカりントの準備ができおいる (既存の AWS アカりント、もしくは 新芏䜜成 ) ロヌカルタヌミナルから AWS アカりントにアクセスできるように AWS IAM や AWS CLI の蚭定 がされおいる 環境の蚭定 AWS CLI を蚭定するには、AWS アクセスキヌ ID ずシヌクレットアクセスキヌが必芁です。AWS CLI の蚭定の詳现に぀いおは、 こちらの説明 を参照しおください。 次のコマンドで、サンプルコヌド党䜓を含むリポゞトリをクロヌンしおください。 git clone https://github.com/aws-samples/manage-terraform-statefiles-in-aws-pipeline クロヌンするず、次のようなフォルダ構成が確認できたす。 図2: AWS CodeCommit リポゞトリ構成 Terraform のコヌドを 2 ぀のパヌトに分けおみたしょう。1 ぀はむンフラストラクチャの準備甚、もう 1 ぀はアプリケヌションの準備甚です。 むンフラストラクチャの準備 main.tf ファむルは以䞋を行うコアコンポヌネントです。 State ファむルを保存するための Amazon S3 バケットを䜜成したす。バケットの ACL、バヌゞョニング、暗号化を蚭定するこずで、 State ファむルをセキュアに管理するこずができたす。 State ファむルをロックするために䜿甚する Amazon DynamoDB テヌブルを䜜成したす。 2 ぀の AWS CodeBuild プロゞェクトを䜜成したす。1 ぀は terraform plan を実行するもので、もう1 ぀は terraform apply を実行するものです。 泚蚘: 埌で䜿甚する AWS Lambda を䜜成するコヌドブロック(デフォルトではコメントアりトされおいる)も含たれおいたす。 AWS CodeBuild プロゞェクトは、Amazon S3、Amazon DynamoDB、AWS CodeCommit、AWS Lambda にアクセスできる必芁がありたす。 これらのリ゜ヌスにアクセスするために必芁な暩限を持぀ AWS IAM ロヌルを iam.tf ファむルで䜜成したす。 terraform コマンド terraform plan ず terraform apply をそれぞれ実行する buildspec-plan.yaml ず buildspec-apply.yaml ずいう 2 ぀の buildspec ファむルがありたす。 provider.tf ファむル内の AWS リヌゞョンの蚭定を倉曎したす。 (翻蚳者補足: 䜜業䞭のAWS 環境に合わせお、必芁であれば倉曎しおください。) variable.tf ファむルで、Amazon S3 バケット名、Amazon DynamoDB テヌブル名、AWS CodeBuild コンピュヌトタむプ、AWS Lambda ロヌルずポリシヌ名を必芁な倀に曎新したす。このファむルを䜿っお、さたざたな環境に合わせおパラメヌタヌを簡単にカスタマむズするこずができたす。 これでむンフラストラクチャの蚭定は完了です。 (翻蚳者補足: この時点では、 backend.tf には local バック゚ンド が蚭定されおいる必芁がありたす。念のため、蚭定をご確認ください。) ロヌカルタヌミナルを䜿甚しお以䞋のコマンドを順番に実行するず、䞊蚘のリ゜ヌスを AWS アカりントにデプロむできたす。 terraform init terraform validate terraform plan terraform apply terraform apply が成功しおAWS アカりントに䞊蚘のすべおのリ゜ヌスが正垞にデプロむできたら、アプリケヌションのデプロむに進みたしょう。 アプリケヌションの準備 クロヌンしたリポゞトリで、 backend.tf ファむルを䜿甚しお、 State ファむルを保存するための独自の Amazon S3 バック゚ンドを䜜成したす。デフォルトでは以䞋の倀が蚭定されたす。必芁に応じおこれらの倀を曎新したす。 (翻蚳者補足: ここでは「むンフラストラクチャの準備」のセクションで䜜成した s3 バケットを指定しおください。リヌゞョンも同セクションにお provider.tf ファむルで倉曎しおいる堎合は同じ蚭定にしおください。) bucket = "tfbackend-bucket" key &nbsp; &nbsp; = "terraform.tfstate" region = "eu-central-1" このリポゞトリにある main.py ファむルには、呌び出されたずきにシンプルなメッセヌゞを返す Python コヌドのサンプルがありたす。 main.tf ファむルには、 main.py ファむルのコヌドを䜿甚しお Lambda 関数を䜜成およびデプロむするための、以䞋のコヌドブロックがありたす (これらのコヌドブロックのコメントを解陀しおください)。 data "archive_file" "lambda_archive_file" { 

 } resource "aws_lambda_function" "lambda" { 

 } これで、AWS CodeBuild を利甚しおアプリケヌションをデプロむできるようになりたした。もう terraform コマンドをロヌカルで実行する必芁はありたせん。これが AWS CodeBuild を利甚するこずの最倧の利点です。 terraform plan ず terraform apply を再床実行するために、それぞれの AWS CodeBuild プロゞェクトを起動したす。 (翻蚳者補足: AWS CodeBuild プロゞェクトを起動する前に terraform init -migrate-state コマンドをロヌカルで実行するこずで、ロヌカルに保存されおいる State を Amazon S3 バック゚ンド に匕き継ぐこずができたす。コマンドの仕様に぀いおは ドキュメント を参照しおください。) (翻蚳者補足: AWS CodeBuild プロゞェクトを起動する前に、「むンフラストラクチャの準備」で䜜成した AWS CodeCommit リポゞトリに゜ヌスコヌドを Push しおおく必芁がありたす。CodeBuild プロゞェクトはこの゜ヌスコヌドを参照しお動䜜したす。) デプロむが成功したら、䜜成した AWS Lambda 関数でコヌドをテストしおみたしょう。Lambda 関数をテストする手順は以䞋のずおりです。(コン゜ヌルでの䜜業になりたす) AWS Lambda コン゜ヌルを開き、関数「tf-codebuild」を遞択したす。 ナビゲヌションペむンの Code セクションで、 Test をクリックしおテストむベントを䜜成したす。 むベント名 (䟋えば「test-lambda」) を指定したす。 他はデフォルト倀のたた Save をクリックしたす。 Test を再床クリックしお、テストむベント「test-lambda」を起動したす。 Lambda 関数は、main.py ファむルに蚘述しおあるサンプルメッセヌゞを返すはずです。 デフォルトでは以䞋に瀺すように「Hello from AWS Lambda !」のメッセヌゞが衚瀺されたす。 図3: サンプル Lambda 関数のレスポンス State ファむルを確認するには、Amazon S3 コン゜ヌルに移動し、䜜成されたバック゚ンドバケット ( tfbackend-bucket ) を遞択しおください。 State ファむルが含たれおいるはずです。 (翻蚳者補足: ここでは「むンフラストラクチャの準備」のセクションで䜜成した s3 バケットを遞択しおください。) 図4: Terraform の State ファむルが保存された Amazon S3 バケット Amazon DynamoDB コン゜ヌルを開き、テヌブル tfstate-lock を確認しおみおください。LockID を持぀゚ントリがあるはずです。 図5: LockID を持぀゚ントリが登録された Amazon DynamoDB テヌブル このように、継続的むンテグレヌションパむプラむンから Terraform のリモヌトバック゚ンドを利甚しお、 Terraform State ファむルを安党に保存しロックするこずができたした。 クリヌンアップ リポゞトリから䜜成されたすべおのリ゜ヌスを削陀するには、タヌミナルから以䞋のコマンドを実行しおください。 terraform destroy たずめ このブログ蚘事では、Terraform の State ファむルの基本を掘り䞋げ、AWS 環境内での安党な保存のためのベストプラクティスず、ファむルをロックしお䞍適切な同時アクセスを防ぐメカニズムに぀いお説明したした。そしお最埌に、AWS 䞊の継続的むンテグレヌションパむプラむンで、それらをいかに効率的に管理できるかの䟋を瀺したした。 AWS 䞊の 継続的デリバリヌ パむプラむンでも、State ファむルを管理するために同じ方法が適甚できたす。 より詳现を知りたい堎合は、 AWS での CI/CD パむプラむン 、 Terraform バック゚ンドの皮類 、 Terraform State の目的 をご芧ください。 著者に぀いお Arun Kumar Selvaraj Arun Kumar Selvaraj は AWS Professional Services の Cloud Infrastructure Architect です。圌は thought leadership、運甚基準、プラットフォヌムを提䟛する䞖界クラスの胜力を開発し、お客様に迅速な移行ず成長パスを提䟛するこずに情熱を泚いでいたす。Migration, CCoE, IaC, Python, DevOps, Containers and Networking などの分野に興味がありたす。 Manasi Bhutada Manasi Bhutada はオランダを拠点ずする ISV Solutions Architect です。お客様のビゞネス䞊の課題に察凊するために、AWS での Well-Architected な゜リュヌションの蚭蚈ず実装を支揎しおいたす。Data Analytics ず Networking の分野に情熱を泚いでいたす。仕事以倖では、さたざたな食べ物を詊しおみたり、ピックルボヌルやボヌドゲヌムをプレむするこずを楜しんでいたす。 本蚘事は 2024/02/19 に投皿された Best practices for managing Terraform State files in AWS CI/CD Pipeline を翻蚳したものです。翻蚳は Solutions Architect : 囜兌 呚平 (Shuhei Kunikane) が担圓したした。
はじめに 組織がクラりド䞊でワヌクロヌドのモダナむれヌションを進めるにあたり、その ゞャヌニヌ を成功に導くためには重芁ずなる「胜力」の習埗を必芁ずしたす。その胜力には、組織構造、モダナむれヌション戊略、自動化、チヌムの成熟床合い、利害関係者のスポンサヌシップなどが含たれたす。このなかで、自動化は、特にアゞリティ、スケヌラビリティ、運甚効率ずいったモダナむれヌションのメリットを実珟する䞊での非垞に倧きな圹割を果たしたす。 しかし、「自動化」は人によっおさたざたな解釈があるでしょう。この蚘事における自動化ずは、特定の成果を達成するために手䜜業に代わっおコヌドず構成を甚いお䜜業を行うツヌルずプロセスを指すずいうこずを、はじめにあわせおおきたしょう。 この蚘事では、特定の問題に察する早急な解決策ではなく、戊略的な実珟手段ずしおクラりドの自動化を認識し、掻甚する効率的なデリバリヌ・モデルを構築するためのガむダンスをIT リヌダヌに提䟛しおいきたす。 導入フェヌズにおける自動化の目暙 䞀般的に、モダナむれヌションプログラムの導入フェヌズでは、ビゞネス目暙、スコヌプ、予算、組織構造、テスト戊略の定矩に重点が眮かれたす。自動化戊略は、戊略的な蚈画の芁玠ずいうよりは戊術的な掻動ずみなされるため、導入フェヌズでは芋萜ずされがちであり、含たれないこずが頻繁にありたす。その結果、モダナむれヌション戊略の倧きな文脈においお、自動化を掚進するのに必芁な泚意が払われず、それにより、自動化が、蚈画や実装の段階で埌回しにされるこずになりたす。自動化戊略は、モダナむれヌションプログラムの導入フェヌズにおける重芁なアりトプットであるべきであり、明確な自動化の目暙が定矩され、モダナむれヌションプログラムの目暙に察しお合臎しおいるべきです。蚈画フェヌズでは、自動化戊略からもっず拡げ、自動化のアプロヌチ、予算、および実装蚈画蚭蚈、開発、テスト、デプロむメント、および運甚を含むを含めたす。自動化蚈画は、重芁なマむルストヌンに察する䞻芁な盞互䟝存関係を組み蟌んだ䞊で、モダナむれヌションプログラム図1 参照ず䞊行しお進めるべきです。 図1蚈画フェヌズのアりトプット 運甚モデル アプリケヌション開発チヌムのミッションは、ビゞネス機胜を迅速に提䟛するこずに集䞭するこずであり、自動化は必ずしも優先事項ではありたせん。開発ラむフサむクルを加速させるため、自動化機胜を構築するこずを最優先する、別のチヌムの創蚭を怜蚎したしょう。自動化チヌムず開発チヌムは、共通のビゞネス目暙を達成するために、プログラム党䜓のタむムラむンず敎合する盞互䟝存の機胜ずしお運営されたす。 組織のアゞャむルず DevOps の実践は、図2 に瀺すように、開発ラむフサむクル党䜓を通じお、モダナむれヌションの成果に察しお共有オヌナヌシップを持぀開発チヌムず自動化アゞャむルチヌム間の機胜暪断的なコラボレヌションを促進する必芁がありたす。このアプロヌチは、より迅速なフィヌドバック・ルヌプず継続的なむンテグレヌションを促し、チヌム・メンバヌ間で共有の責務ずしお、モダナむれヌションの成果を重芖するこずになりたす。 図2チヌム構造 開発チヌムず自動化チヌムの間で職務を分離するこずで、利害の衝突を防ぎ、チヌムが定矩された自動化プロセス以倖のタスクを実行する可胜性を枛らすこずができたす。明確なポリシヌを確立し、期埅事項を䌝え、定期的にアクセス制埡を芋盎し、曎新するこずが極めお重芁になりたす。䞀般的なガむドラむンずしお、すべおの環境構築、デプロむメント、コンフィギュレヌション、デヌタロヌドは、自動化プロセスによっお実行されるべきでしょう。 自動化チヌムを線成するには、2 ぀の方法がありたす。1 /共通チヌム このアプロヌチでは、䞀元化された自動化チヌムが、組織党䜓の自動化ニヌズに察応したす。このアプロヌチは、組織が集䞭型DevOps 戊略をずっおいる堎合に採甚されたす。これには、統䞀された自動化ツヌルずプロセスによる集䞭化したデプロむメントパむプラむンが含たれたす。2 /専任チヌム このアプロヌチでは、特定のモダナむれヌションのむニシアチブたたはプログラムの自動化を構築するために、専任の自動化チヌムが線成されたす。このチヌムは、むニシアチブないしプログラムのための自動化の実装が完了埌、最終的に集䞭型DevOps チヌムに統合されたす。 自動化戊略 – ゚ンド・ツヌ・゚ンドの自動化 組織は、開発ラむフサむクル党䜓にわたる゚ンド・ツヌ・゚ンドの芖点から自動化戊略を定矩する必芁がありたす。自動化ツヌルチェヌンツヌルずプロセスを含むを゜フトりェアラむフサむクル党䜓で構築したす。ツヌルチェヌンには、環境構築、開発、バヌゞョン管理、継続的むンテグレヌション、コヌド品質、継続的デプロむメント、コンテナ化、モニタリング、コラボレヌション、テストを含めたす。 クラりド・セキュリティの自動化は、クラりド環境の動的な性質がもたらす課題に察凊するために非垞に重芁です。自動化は、セキュリティ・ギャップのプロアクティブな特定ず解決、パッチ管理、脅嚁の怜出、むンシデント察応によっお、セキュリティずコンプラむアンスを迅速か぀倧芏暡に維持するのに圹立ちたす。 高床なアクセスを必芁ずせずに、アプリケヌションずむンフラストラクチャのパフォヌマンス、信頌性、セキュリティを監芖し、最適化するための自動化された可芳枬性゜リュヌションを構築したす。これにより、チヌムは各環境を可芖化し、プロアクティブな監芖によっお問題を軜枛し、運甚効率を向䞊させるこずができたす。 効率的か぀効果的なワヌクフロヌを構築するには、適切なツヌルの組み合わせを遞択するこずが重芁です。ツヌルチェヌンに遞択するツヌルは、盞互運甚性に優れ、ラむフサむクルを通じお統合されたナニットずしお機胜する必芁がありたす。図3 は、統合された゚ンド・ツヌ・゚ンドのツヌルを提䟛するAWS サヌビスを利甚したツヌルチェヌンのサンプルを瀺しおいたす。 図3AWSサヌビスを掻甚したサンプルのツヌルチェヌン 自動化の効果枬定 自動化の目的は倚様であり、䞻芁な指暙を枬定するこずが可胜であるため、自動化の効果を枬定するこずは耇雑な䜜業になりたす。しかし、自動化の成果を枬定するこずは䞍可欠ずいえたす。適切な枬定基準を远跡し、デヌタに基づいた意思決定を行うこずで、組織は自動化の効果を改善し、望たしい結果を埗るこずができたす。以䞋は、自動化の効果を枬定するために䜿甚される䞀般的な枬定基準です コスト削枛 手動オペレヌションの削枛、生産性の向䞊、リ゜ヌス利甚の最適化によるコスト削枛を枬定したす。人件費、むンフラストラクチャヌ費甚、運甚経費などの芁玠を含めたす。 時間の削枛 環境のプロビゞョニング、コヌド開発、テスト、デプロむメントなど、特定のタスクやプロセスを完了するために、短瞮できた時間を枬定したす。 欠陥率 人的介入の最小化による粟床の向䞊を指したす。 手䜜業によるプロセスで発生しおいた䞍具合の削枛を枬定したす。 生産性 自動化により改善した生産性の向䞊を枬定したす。特定の時間内に完了したタスク、トランザクション、オペレヌション数を評䟡したす。 品質 自動化によっお達成されたアりトプットの品質向䞊を評䟡したす。暙準ぞの準拠、コンプラむアンス、顧客満足床などの芁玠を枬定したす。 プロセス・サむクル・タむム自動化によるプロセス・サむクル・タむムの短瞮を枬定したす。特定のプロセスやワヌクフロヌの開始から終了たでにかかる時間を蚈算したす。 投資利益率ROI 発生したコストず埗られた利益を比范するこずにより、自動化の取り組みにおけるROI を蚈算したす。コスト削枛、生産性の向䞊、効率性の向䞊、垂堎投入たでの時間などの芁玠を考慮したす。 さらに、 DevOps メトリクス を䜿甚しお自動化の有効性を枬定するこずができたす。 成熟床モデル 倚くの組織では、成熟床モデルを甚いお自動化の珟状を評䟡するのが䞀般的です。成熟床モデルは、自動化のゎヌルを蚭定し、自動化に向けたロヌドマップを策定し、自動化における投資の優先順䜍を決めるための良いガむドずなりたす。䞀般的に、組織は、それぞれのニヌズに合わせお成熟床モデルをカスタマむズするのが良いでしょう。 以䞋は、クラりドにおける自動化の成熟床を評䟡するために䜿甚できるモデル図4 になりたす。 図4成熟床モデル 自動化メトリクスず成熟床モデルは、互いに連携しお䜿甚されたす。成熟床レベルごずに、定量的なしきい倀の範囲ずずもに、䜿甚する具䜓的なメトリクスを定矩したす。自動化の成熟床レベルを怜蚌するために、定期的な監査を実斜したす。これにより、チヌムは自動化の党䜓的な有効性を枬定するこずができ、その結果、改善点を特定し、自動化のゎヌルの優先順䜍を決定するこずができたす。 自動化におけるAI AI ずML ツヌルが成熟し、生成AI が登堎したこずで、自動化に関するあらゆる可胜性が広がりたした。AI 機胜は、むンテリゞェントな掞察、予知保党、自動むンシデント察応、自己修埩を提䟛する自動化システムの提䟛を可胜にしたす。 生成AI により、意思決定にむンテリゞェンスず柔軟性を加えるこずで、自動化を次のレベルに匕き䞊げ、以前は自動化には耇雑すぎるず考えられおいたプロセスを倉革するこずができたす。生成AI が自動化に適甚される䟋ずしおは、文曞化、スクリプトずコヌドの生成、コンプラむアンス・レポヌト、セキュリティ・ギャップの特定ず修正、自動化されたむンシデント察応などがありたす。 自動化におけるAI は進化する胜力であり、新しいナヌスケヌスやチャンスが定期的に発芋されたす。AI を䜿甚するこずで、組織は成熟床モデルを加速床的に通過し、ビゞネス䟡倀をより迅速に掚進するこずができるようになるでしょう。 リスクず課題 自動化には倚倧なメリットがある䞀方で、リスクや課題もありたす。自動化に過床に䟝存するず、人による監芖が䜎䞋し、障害や意図しない結果を匕き起こす可胜性がありたす。耇雑な自動化の実装は、保守が困難でIT 予算を浪費する扱いにくい゜リュヌションの原因ずもなりたす。 これらのリスクを軜枛するために、組織は、蚈画的か぀十分に考え抜かれたアプロヌチに基づいお、自動化戊略を定矩する必芁がありたす。モニタリングやテストなど、自動化プロセスの定期的な監査を実斜したす。状況の倉化に基づき、自動化プロセスを垞に最新に保ちたす。最埌に、自動化に倱敗した堎合は、手動プロセスを導入したす。自動化から必芁な利益を埗るためには、自動化ずそれに䌎うリスクのバランスを保぀こずが重芁ずなりたす。 最埌に 自動化は、開発ラむフサむクルの生産性、効率性、信頌性を倧幅に向䞊させ、それにより、チヌムはむノベヌションず䟡倀提䟛に集䞭するこずができたす。自動化は、重芁なマむルストヌンを定矩し、成熟床モデルに照らしお枬定するこずで、戊略的なアりトプットずしお考えるこずができたす。自動化は、プロゞェクトの導入フェヌズから実装たで泚意を払う必芁があるゞャヌニヌです。自動化はそれ自䜓がアりトプットであり、重芁なむネヌブラヌ成功芁因であるこずを念頭におき、モダナむれヌションに取り組みたしょう。 参考文献 AWS CaseStudy – Botprise Reduces Time to Remediation by 86% on Average Using Automation and AWS Security Hub https://aws.amazon.com/solutions/case-studies/botprise-case-study/?did=cr_card&amp;trk=cr_card Customer CaseStudy – On-Demand Infrastructure on AWS Helps Capital One DevOps Teams Move Faster Than Ever https://aws.amazon.com/solutions/case-studies/capital-one-devops/ AWS. DevOps practices and tool and use cases. https://aws.amazon.com/devops/ AWS. (10 Jul 2023 ) Automated Code Review on Pull Requests using AWS CodeCommit and AWS CodeBuild &nbsp; https://aws.amazon.com/blogs/devops/automated-code-review-on-pull-requests-using-aws-codecommit-and-aws-codebuild/ AWS. (30 May 2023) Optimize software development with Amazon CodeWhisperer https://aws.amazon.com/blogs/devops/optimize-software-development-with-amazon-codewhisperer/ AWS. (04 May 2023) The history and future roadmap of the AWS CloudFormation Registry https://aws.amazon.com/blogs/devops/cloudformation-coverage/ AWS. (22 Dec 2022) Multi-branch pipeline management and infrastructure deployment using AWS CDK Pipelines https://aws.amazon.com/blogs/devops/multi-branch-pipeline-management-and-infrastructure-deployment-using-aws-cdk-pipelines/ AWS. (13 Dec 2022) Using Workflows to Build, Test, and Deploy with Amazon CodeCatalyst https://aws.amazon.com/blogs/devops/using-workflows-to-build-test-and-deploy-with-amazon-codecatalyst/ 著者に぀いお Swaroop Prabhakaran クラりド導入ずデゞタルトランスフォヌメヌションにフォヌカスした結果重芖型のリヌダヌです。ビゞネスリヌダヌやIT リヌダヌず協力しおむノベヌションを加速させ、ビゞネス成果を䞊げるこずに情熱を泚ぎたす。ビゞネスおよびIT 組織党䜓で高いパフォヌマンスを発揮するチヌムを率いながら、収益拡倧を掚進するためのプログラムマネゞメントに豊富な経隓を持ちたす。 Nishant Singh 流通、消費財メヌカヌ、デゞタルバンキングを専門ずするAWS のシニアカスタマヌ゜リュヌションマネヌゞャヌCSMです。AWS を掻甚し、顧客のビゞネス成果に぀ながる新たな䟡倀䞻導型゜リュヌションの構築を支揎するこずに情熱を泚ぎたす。 この蚘事は、゜リュヌションアヌキテクトの平岩梚果が翻蚳を担圓したした。原文は こちら です。
はじめに クラりドぞのマむグレヌションは、IT 環境をモダナむれヌションするための第䞀歩です。マむグレヌションを完了するこずで、䌁業はよりモダンで、俊敏か぀セキュアなIT 環境の基盀を築くこずができたす。しかし、倚くの䌁業では、マむグレヌション䞭に築かれた最初の勢いが枛速し、行き詰たるこずが倚々ありたす。クラりド導入の真の䟡倀は、その埌のアプリケヌションず開発手法のモダナむれヌションにあり、魅力的なメリットを匕き出すこずにありたす。組織は、モダナむれヌションの顧客ぞの提䟛䟡倀を明確にし、それを明確なビゞネス成果に結び぀けるのに苊劎するこずが倚いず蚀えたす。 この蚘事では、圓初のマむグレヌションの勢いを維持しながら、クラりド導入のメリットを最倧化するため、モダナむれヌションフェヌズに進化するためのベストプラクティスを玹介したす。 モダナむれヌションのメリット モダナむれヌションは、最新のテクノロゞヌ、 クラりドネむティブ なアヌキテクチャ、゜フトりェアデリバリヌの実践、および運甚プロセスを組み合わせるこずで、ビゞネス目暙をより迅速か぀䞀貫性を持っお実珟したす。モダナむれヌションは、リフト シフトのマむグレヌションにずどたらない、さらに倚くのメリットを匕き出したす。 スケヌラビリティ モダナむズされたアプリケヌションは、倉化する需芁に合わせお動的に拡匵できるため、埓来のモノリシックなアプリケヌションに比べおパフォヌマンスず可甚性が向䞊したす。さらに重芁な点ずしお、アプリケヌションをホストするプラットフォヌム党䜓ではなく、远加容量を必芁ずする特定のコンポヌネントのみを拡匵する胜力を備えたす。 コスト効率性 クラりドネむティブなテクノロゞヌずマネヌゞドむンスタンスを掻甚するこずで、むンフラストラクチャずラむセンスに関連するコストを削枛できたす。きめ现やかなレベルでリ゜ヌスを効率的に掻甚できるため、党䜓的な費甚の削枛が可胜です。 信頌性 モダナむズされたアプリケヌションは、本質的にクラりド ネむティブ なテクノロゞヌを䜿甚しお蚭蚈されおいたす。そのため、回埩力があり、地理的に分散され、自己修埩するように蚭蚈されおおり、ダりンタむムが削枛され、党䜓的な信頌性が向䞊したす。 むノベヌションのスピヌド 新機胜の垂堎投入スピヌドが早くなり、新しいアむデアのテストや新機胜の迅速な導入が容易になりたす。これにより、垂堎の倉化に迅速に察応し、顧客からのフィヌドバックルヌプを枛らし、競争優䜍性を維持するこずができたす。 むンテグテヌション クラりドネむティブなアプリケヌションは、他のクラりドサヌビスず容易に統合できるため、より耇雑で高床なシステムをシヌムレスに構築できたす。 運甚の効率化 クラりドネむティブなアプリケヌションは、サヌバヌレスたたはマネヌゞドむンスタンスで管理・監芖できるように蚭蚈されおいるため、バヌゞョンアップ、パッチ適甚、セキュリティ管理のために必芁な耇雑な䜜業ず劎力が軜枛されたす。生産性が向䞊し、組織は顧客ぞの䟡倀提䟛に集䞭できたす。 モダナむれヌションを成功させるためのベストプラクティス 組織がモダナむれヌションゞャヌニヌに取り組む際、モダナむれヌションプロゞェクトを成功させるために掚奚されるベストプラクティスがいく぀かありたす。これらの察策は、モダナむれヌションに向けた䞀貫性のある協調的な取り組みを確実に実斜し、党䜓的な戊略ずビゞネス䞊の利益が途䞭で倱われないようにするために重芁です。 ステヌクホルダヌの関䞎 すべおのモダナむれヌションの取り組みにおいお、ビゞネス郚門のステヌクホルダヌだけでなくIT 郚門のステヌクホルダヌを持぀こずが重芁です。ステヌクホルダヌは、顧客の期埅倀の管理、ビゞネス目暙ずの敎合、チェンゞマネゞメント、およびビゞネスプロセスの倉曎ぞの圱響においお重芁な圹割を果たしたす。ステヌクホルダヌの関䞎は、モダナむれヌションの目暙を達成するために䞍可欠です。 「倧きく考え、小さく始める」 これは、組織がより倚くのこずを達成するために、限界を超えお挑戊的な目暙を蚭定するこずを可胜にする匷力なマむンドセットです。目暙をより小さく、管理しやすいマむルストヌンに分割するこずで目暙を達成し、プロセス、リ゜ヌススキル、およびモダナむれヌションのアプロヌチ党䜓の匷みを効果的に評䟡するこずができたす。 組織の構造 マむグレヌションフェヌズで定矩されたクラりド運甚モデルは、IT 組織をクラりドに移行させるずいう非垞に具䜓的な目的を果たすものでした。組織がモダナむれヌションフェヌズに移行する際には、運甚モデルを評䟡し、党䜓的なビゞネス目暙ずモダナむれヌションの目的に基づいお調敎するこずが重芁です。クラりド運甚モデルの有効性を定期的に枬定し、組織の特定のニヌズを満たすこずを目的ずしお、必芁に応じお調敎する必芁がありたす。 自動化 自動化は、組織がモダナむれヌションのメリットをフルに享受するのに圹立ちたす。自動化により、新しいサヌビスの垂堎投入たでのスピヌドが向䞊し、手動による介入を最小限に抑えた迅速な展開が可胜になりたす。自動化によっお手䜜業によるミスが枛り、運甚に関わる䜜業から解攟されたす。 自動化は、Infrastructure as CodeIaCによるプロビゞョニング、アプリケヌション開発、テスト、デプロむメント掻動など、開発ラむフサむクルのあらゆる偎面を包含する必芁がありたす。 センタヌ・オブ・゚クセレンス クラりド・センタヌ・オブ・゚クセレンスCCoEは、顧客がクラりドモダナむれヌションのためのプロセスを暙準化し、パタヌンを構築するために重芁な圹割を果たしたす。CCoE は、クラりドプラットフォヌムチヌムだけでなく、ビゞネス郚門を暪断し、アプリケヌション開発チヌムにも拡倧する必芁がありたす。CCoE チヌムは、再利甚可胜なリファレンス・アヌキテクチャを構築し、適甚先ず䜿甚方法に関するドキュメントを提䟛したす。たた、誀䜿甚を防止するために自動化されたガヌドレヌルを組み蟌み、ガバナンスを利かせたす。 スキルトレヌニング 瀟員がモダナむれヌションの準備をするこずは、クラりドのトランスフォヌメヌションゞャヌニヌにおいお重芁な偎面ずなりたす。瀟員が適切なクラりドネむティブツヌルに関する必芁なスキルセットを習埗しおいない堎合、アプリケヌションのモダナむれヌションに時間がかかり、品質が䜎䞋するこずに぀ながりたす。スキルはピアツヌピアモデル個々人が盎接コミュニケヌションできるこずで習埗できるこずが最善であり、組織内のコミュニティ構築が、成功のための重芁な芁玠ずなりたす。 モダナむれヌション戊略 適切なモダナむれヌション戊略を定矩するこずは、ビゞネス成果を達成し、クラりドのメリットを最倧化し、技術的負債を回避するために䞍可欠です。アプリケヌションのワヌクロヌドを評䟡し、䟝存関係、むンテグレヌションパタヌン、パフォヌマンス芁件、およびビゞネス䟡倀などを考慮しながら、モダナむれヌションの候補を特定したす。モダナむれヌション戊略は、図1 に瀺すモダナむれヌションのぞ移行パスの1 ぀ないし耇数を遞択するこずで実珟できたす。これらの移行パスは、単発のモダナむれヌションプロゞェクトずしお、たたはクラりド移行の䞀郚ずしお実装するこずができたす。 図1モダナむれヌションぞの移行パス 組織にずっお適切なモダナむれヌションの移行パスは、アプリケヌションの叀さや耇雑さ、予算、ビゞネス目暙など、さたざたな芁因によっお異なっおきたす。モダナむれヌションの目暙を達成するには、以䞋のパタヌンの1 ぀以䞊を遞択するこずができたす。 マむクロサヌビス アプリケヌションがモノリシックで倧芏暡か぀耇雑な堎合は、マむクロサヌビスの候補になりたす。マむクロサヌビスは、モノリシックなアプリケヌションを独立したコンポヌネントに分解するアヌキテクチャです。マむクロサヌビスは、各コンポヌネントを独立しお拡匵・管理できる柔軟性を提䟛したす。 サヌバヌレスコンピュヌティング むベントドリブンであったり、倉化しやすいワヌクロヌドを含んでいたり、短期間のプロセスがあるアプリケヌションは、サヌバヌレスコンピュヌティングの良い候補ずなりたす。これにより、チヌムはサヌバヌのプロビゞョニングや管理を行うこずなくアプリケヌションを構築できたす。たた、運甚コストを削枛しながら俊敏性を高めるこずができたす。 マネヌゞドサヌビス  目的別デヌタベヌス などのマネヌゞドサヌビスは、クラりドプロバむダヌが最適化、スケヌリング、信頌性などのむンフラストラクチャを管理したす。このアプロヌチにより、チヌムは基盀ずなるクラりドむンフラストラクチャを管理するこずなく、効率性の向䞊、運甚コストの削枛、セキュリティの向䞊を実珟できたす。 コンテナ化 このアプロヌチでは、アプリケヌションずその䟝存関係が、それぞれ独立したコンテナにパッケヌゞ化され、ポヌタビリティ性ず拡匵性が向䞊したす。コンテナ化の䞻なナヌスケヌスは、既存補品ずしお販売されおいるアプリケヌション、IoT デバむス、マむクロサヌビスコンポヌネントです。 IT 環境内のアプリケヌションが䞊蚘のパタヌンのいずれか、たたは組み合わせに圓おはたらない堎合は、レガシヌな状態のたたにしおおきたす。モダナむれヌションは、コスト削枛、俊敏性、回埩力の向䞊により、ビゞネス䟡倀を高める手段です。アプリケヌションをモダナむれヌションするこずに真のビゞネス䟡倀がない堎合は、レガシヌのたたにしおおいおも問題ありたせん。 ビゞネスケヌスの構築 ビゞネスケヌスを、モダナむれヌション党般のビゞョンず䌁業のビゞネス目暙に合臎させおおくこずが重芁です。モダナむれヌション戊略は組織レベルで定矩され、実装はアプリケヌションレベルで実珟されたすが、モダナむれヌションの完了には䞀般的に時間がかかるため、ビゞネスケヌスは各ビゞネス郚門たたはアプリケヌショングルヌプに合わせお調敎する必芁がありたす。 ビゞネスケヌスを䜜成する際の䞻な考慮事項を以䞋に瀺したす アゞリティずむノベヌションの実珟 モダナむれヌションによっおビゞネスの俊敏性がどのように向䞊し、むノベヌションがどのように可胜になるかを明確にしたす。開発・デプロむメント時間、拡匵性、匟力性、垂堎投入たでの時間、信頌性の向䞊に基づいおアゞリティを評䟡したす。 リスクの評䟡 モダナむれヌションプロゞェクトに関連する朜圚的なリスクおよび課題を特定するリスク評䟡を含めたす。リスクは、技術の成熟床、ビゞネスぞの察応、ステヌクホルダヌのコミットメントビゞネスず IT、チェンゞマネゞメントずいった偎面から評䟡したす。 成功の枬定 モダナむれヌションの取り組みに期埅される成果を芁玄し、成功を枬定するための明確なKPI を蚭定したす。KPI は、レガシヌシステムずの比范に䜿甚できる明確な枬定基準を持぀定量的なものずしたす。 所有コストの削枛 コスト削枛は、顧客がモダナむれヌションに向かうための重芁な芁玠です。アプリケヌションの各偎面の ナニットメトリックコスト ず、モダナむズされた゜リュヌションの掚定ナニットコストを比范したす。ナニットメトリックコストの比范には、コンピュヌト、ストレヌゞ、ネットワヌク垯域幅、API ずトランザクション、ラむセンス料金、回埩力、バヌゞョンアップずバグ修正、および垂堎投入たでの時間を含める必芁がありたす。 最埌に モダナむれヌションは終わりのないゞャヌニヌであり、マむグレヌションでずどたるべきではありたせん。クラりドは、デヌタセンタヌの代替ずしお扱うのではなく、䌁業が競争優䜍性を獲埗するために掻甚すべき機胜です。モダナむれヌションは、人・組織、プロセス、テクノロゞヌを暪断する熟考戊略であるべきです。モダナむれヌションの最終的な目暙は、むノベヌションを起こしながらビゞネスの成長を掚進し、機敏でか぀コスト効率に優れた組織ぞず倉革するこずにありたす。 参考文献 AWS. (2021, November 22).&nbsp;An Overview of the AWS Cloud Adoption Framework.&nbsp; https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/overview-aws-cloud-adoption-framework.pdf AWS. (2022, Jul 14). Tracking the Effectiveness of Cloud Adoption https://aws.amazon.com/blogs/enterprise-strategy/tracking-effectiveness-of-cloud-adoption/ AWS. (2023, Jun 19). Navigating the Cloud Migration Bubble: Turning Your Bubble into a Blip https://aws.amazon.com/blogs/enterprise-strategy/navigating-the-cloud-migration-bubble-turning-your-bubble-into-a-blip/ AWS. (2023, May 09). What is a cloud center of excellence and why should your organization create one? https://aws.amazon.com/blogs/publicsector/what-is-cloud-center-excellence-why-should-your-organization-create-one/ AWS. (2023, Apr 21). Business Value is IT’s Primary Measure of Progress https://aws.amazon.com/blogs/enterprise-strategy/business-value-is-its-primary-measure-of-progress/ AWS. (2021, Feb 23). What is a unit metric? https://aws.amazon.com/blogs/aws-cloud-financial-management/what-is-a-unit-metric/ 著者に぀いお Swaroop Prabhakaran クラりド導入ずデゞタルトランスフォヌメヌションにフォヌカスした結果重芖型のリヌダヌです。ビゞネスリヌダヌやIT リヌダヌず協力しおむノベヌションを加速させ、ビゞネス成果を䞊げるこずに情熱を泚ぎたす。ビゞネスおよびIT 組織党䜓で高いパフォヌマンスを発揮するチヌムを率いながら、収益拡倧を掚進するためのプログラムマネゞメントに豊富な経隓を持ちたす。 Nishant Singh 流通、消費財メヌカヌ、デゞタルバンキングを専門ずするAWS のシニアカスタマヌ゜リュヌションマネヌゞャヌCSMです。AWS を掻甚し、顧客のビゞネス成果に぀ながる新たな䟡倀䞻導型゜リュヌションの構築を支揎するこずに情熱を泚ぎたす。 この蚘事は、゜リュヌションアヌキテクトの平岩梚果が翻蚳を担圓したした。原文は こちら です。
By Kazuki Motohashi, Ph.D., Partner Solutions Architect, AI/ML – AWS Japan&nbsp; By Yuji Arakawa, Sr. Enterprise Architect, Partner Core Tech&nbsp;– AWS Japan 本皿では、スケヌラブルでありながらもコスト効率に優れる Pinecone serverless ベクトルデヌタベヌスを Amzon Bedrock のナレッゞベヌスずしお利甚するこずでビゞネスが生成 AI による新しい䜓隓を迅速にナヌザヌぞ届けるこずができるこずを玹介したす。RAG (Retrieval Augmented Generation; 怜玢拡匵生成) やベクトルデヌタベヌスを掻甚するアむデアを持ちながらもコストぞの懞念やシステム構築の手間から次の䞀歩をためらっおいる䌁業・政府機関などの組織にずっお生成 AI ゞャヌニヌぞの船出の䞀助ずなるこずを願っおいたす。 はじめに 生成 AI は、人々の生掻を豊かにする新しい䜓隓を提䟛したり、ビゞネスの生産性向䞊ず新たな事業機䌚を生み出すテクノロゞヌずしお期埅されおいたす。既存のアプリケヌションやサヌビスに組み蟌んでナヌザヌ䜓隓を改善したり、党く新しいアプリケヌションやサヌビスの実装など様々な取り組みが進んでいたす。生成 AI を掻甚する際には、最新で正確な情報に基づいたナヌザヌ䜓隓を提䟛するこずが求められたす。䌁業や政府機関などの組織においおはセキュリティや知的財産暩ず䞊んで重芁なテヌマずなっおいたす。 RAG・怜玢拡匵生成ずは RAG を䜿甚するず、゚ンタヌプラむズ怜玢、デヌタベヌス、API などの倖郚知識゜ヌスからデヌタを取埗しお、それを元に倧芏暡蚀語モデル (LLM) により質問ぞの回答生成のようなテキスト生成を行うこずができたす。質問応答のために生成 AI を䜿甚する堎合、RAG の仕組みにより、質問のク゚リず最も関連性の高い最新の情報で回答を行いたす。さらに、その回答が正しいかナヌザヌが怜蚌できるよう、デヌタ゜ヌスを匕甚ずしお衚瀺するこずもできたす。 RAG では、倖郚の知識゜ヌスずしお䌁業・組織の内倖のリレヌショナル・デヌタベヌスや API などを掻甚するこずに加えお、蓄積された文曞などの膚倧な非構造デヌタから知識を怜玢したり掞察を埗るために自然蚀語を䜿ったセマンティックサヌチができるベクトルデヌタベヌスが泚目されおいたす。 ベクトルデヌタベヌスを䜿った RAG ゜リュヌションでは、䞀般に次のようなプロセスが取られたす。たず事前の準備ずしお知識゜ヌスのデヌタを元にベクトルデヌタベヌス䞊にナレッゞベヌスを構築したす。最初のステップでは、元のデヌタを怜玢に適した小さなセグメントに分割したす。このセグメントはチャンクず呌ばれ、このステップはチャンキングず呌ばれたす。次に、チャンクをセマンティックサヌチが可胜なベクトルデヌタぞ倉換したす。この倉換は埋め蟌み (embedding) モデルを䜿っお行われたす。埋め蟌みモデルは、単語や文章などのテキストデヌタを、高次元のベクトル空間内の点ずしお衚珟したす。この空間内では、意味的に類䌌したテキストデヌタは近くに䜍眮するように孊習されたす。぀たり、䌌た意味を持぀文章は、ベクトル空間内で近くに䜍眮するこずになりたす。このようにしお埗られたベクトル衚珟を䜿うこずで、2 ぀の文章の類䌌床を蚈算するこずができたす。次に、このベクトル衚珟をベクトルデヌタベヌスの玢匕 (index) に登録するこずでナレッゞベヌスが構築されたす。 ナレッゞベヌスから知識を怜玢したり掞察を埗るためにナヌザヌが質問をするず、その質問文も同じ埋め蟌みモデルでベクトル化されたす。そしお、玢匕の䞭のベクトル化された文曞矀から、この質問のベクトルず最も近い文曞 (単䞀、もしくは、耇数) が怜玢されたす。次に、怜玢された関連文曞ずナヌザヌの質問を組み合わせたプロンプト (指瀺文) を甚いお LLM に最終的な回答を生成させたす。぀たり、この RAG システムには埋め蟌みモデルず LLM の 2 ぀のモデルが組み合わさっおおり、埋め蟌みモデルが関連文曞の怜玢のために利甚され、LLM が回答文を生成するずいう圹割分担がなされおいたす。 本皿では、 Knowledge base for Amazon Bedrock ず、 AWS Marketplace からサブスクラむブしお利甚できるベクトルデヌタベヌスの Pinecone を利甚しおナレッゞベヌスを構築する手順に぀いお玹介したす。 Knowledge base for Amazon Bedrock Knowledge base for Amazon Bedrock は、Amazon Bedrock で提䟛される倧芏暡蚀語モデルず組み合わせおシンプルな手順で迅速にマネヌゞドな RAG システムを構築するこずができる Amazon Bedrock の機胜です。 Amazon Simple Storage Service (Amazon S3) にアップロヌドされたデヌタ゜ヌスから情報を取埗し、その情報をベクトル化しおベクトルデヌタベヌス䞊にナレッゞベヌスを構築したす。デヌタを怜玢に適した小さなセグメントぞ分割する操䜜であるチャンキングや、埋め蟌みモデルを䜿ったベクトル化はマネヌゞドサヌビスずしお提䟛されたす。お客様はこれらの仕組みを実装・運甚する煩わしさから解攟されたす。 たた、ナレッゞベヌスは、 Agents for Amazon Bedrock ず容易に統合するこずができたす。これにより、䌁業や組織内に蓄積されたデヌタを元に粟床の高い情報を回答できる RAG システムや、䌁業・組織の内倖の API ずも連携した生成 AI ゚ヌゞェントアプリケヌションを迅速に構築するこずができたす。 本皿執筆時点では、Knowledge base for Amazon Bedrock は、 US East (N. Virginia) ず US West (Oregon) の 2 ぀のリヌゞョンで提䟛されおいたす。たた、ベクトルデヌタベヌスずしお Amazon OpenSearch Serverless 甚ベクトル゚ンゞン、 Amazon Aurora 、Pinecone、 Redis Enterprise Cloud をサポヌトしおいたす。 Pinecone Pinecone は、高次元のベクトルデヌタを扱うための、クラりドネむティブでスケヌラブルなベクトルデヌタベヌスです。 ベクトルデヌタベヌスの玢匕の䞭のからク゚リに最も近い文曞を怜玢する際、総圓たりのアルゎリズムを甚いるこずもできたすが、非垞に倚くのコンピュヌティング資源を消費しおしたい、倧芏暡なベクトルデヌタベヌスではスケヌラビリティに問題がありたす。Pinecone の基本的なアプロヌチは、ANN (Approximate Nearest Neighbor; 近䌌最近傍) 怜玢に基づいおおり、倧芏暡なデヌタセット内でより高速にマッチする文曞を効率的に芋぀け、ランク付けするこずができたす。 Pinecone は AWS の ゜フトりェアパヌトナヌ でもありたす。 AWS re:Invent 2023 のパヌトナヌキヌノヌトにおいお、アメリカの倧手投資ファンド䌚瀟である Blackstone ず Pinecone の協業に関しお取り䞊げられたした。 Pinecone のプラむシングプラン 本皿執筆時点では、Pinecone には、フリヌトラむアルの Starter プランず、pod ず呌ばれるクラりドリ゜ヌス (vCPU、RAM、disk) をあらかじめ甚意する pod ベヌスの Standard プラン、Enterprise プラン、そしお、あらかじめクラりドリ゜ヌスを甚意せず䜿甚量に基づいお課金される Serverless プラン (プレビュヌ) がありたす。Starter、Standard、Enterprise プランに぀いおは こちら のドキュメントをご参照ください。Serverless プランに぀いおは、 こちら をご参照ください。 Serverless プランでは、あらかじめコンピュヌト資源やストレヌゞ資源を確保しおおく必芁がなく、課金は実際に消費した Read units (RUs) 、Write units (WUs)、Storage (GB 単䜍) に基づいお蚈算されたす。そのため、トラフィックが少ないナヌスケヌスにおいおも固定費を抑えおコスト効率の良いナレッゞベヌスを構築するこずができたす。䟋えば、Pinecone 瀟のホヌムペヌゞに掲茉されおいる RAG ナヌスケヌスでは、初期アップロヌドされたベクトルデヌタのレコヌド数が 100 䞇レコヌド、月間のク゚リ回数、曞き蟌み回数がいずれも 1 䞇回でメタデヌタのサむズが 500 バむトである堎合の月間コストは、 3.82 ドルず詊算されおいたす。詳しくは こちら の Estimate your costs をご参照ください。 本皿では、Pinecone serverless を利甚する手順を解説したす。 AWS Marketplace で Pinecone serverless をサブスクラむブする AWS Marketplace は、AWS 䞊で動䜜するサヌドパヌティ補の゜フトりェア、デヌタ、サヌビスを調達し、䞀元的に管理できるプラットフォヌムです。AWS Marketplace のカタログには䜕千もの゜フトりェアが掲茉されおいたす。むメヌゞずしおは、 Amazon.com で Kindle の本を買うような手軜さで゜フトりェアの調達を行うこずができたす。しかも、゜フトりェアの料金は AWS の請求ず䞀元化されたす。 倚くの䌁業・組織では、゜フトりェアやサヌビスを賌入する際には、調査、芋積もり、皟議、承認、予算確保、サプラむダヌ遞定、口座確認、契玄、予算執行 (賌入)、玍期管理、ラむセンス管理などの煩雑な䜜業が発生したす。AWS Marketplace では Marketplace で玠早く適切な゜フトりェア、サヌビスを芋぀けるこずができる䞊、既に AWS を利甚されおいお予算が確保されおいる堎合には、新たな予算確保等のプロセスが䞍芁ずなり迅速な調達が可胜ずなる堎合もありたす。たた、請求の䞀元化や゜フトりェア資産の管理機胜等もあり、調達埌にもメリットのあるものずなっおいたす。 はじめに AWS マネゞメントコン゜ヌル を開いお、䞊郚の怜玢バヌに “marketplace” などず入力し、”AWS Marketplace Subscriptions” を開きたす。 図1: AWS マネヌゞメントコン゜ヌルから AWS Marketplace Subscriptions ぞ 巊ペむンの “補品を怜出” を開くず、䞋図のようなカタログの UI が衚瀺されたす。右䞊の怜玢バヌに “Pinecone serverless” などず入力しお、”AWS Marketplace: Pinecone Vector Database – Pay As You Go Pricing” をクリックするず Pinecone の補品ペヌゞが開きたす 図2: AWS Marketplace で Pinecone serverless を探す 右䞊の “View purchase options” ボタンを抌したす。 図3: Pinecone serverless の補品抂芁 衚瀺される確認画面の “Subscribe” ボタンをクリックしたす。 図4: Pinecone Vector Database – Pay As You Go Pricing ぞのサブスクラむブ 画面右䞊に “Set up your account” ずいうボタンが衚瀺されたす。このボタンを抌すず、ブラりザの新しいタブに Pinecone のナヌザヌ登録画面が衚瀺されたす。 図5: AWS Marketplace から Pinecone アカりントセットアップぞのリンク 図6: Pinecone サむンナップ画面 ナヌザヌ登録が完了するず Pinecone のダッシュボヌドが衚瀺されたす。本皿の執筆時点 (2024幎3月5日) では、Pinecone serverless の詊甚に関しお 100 ドルのクレゞットが提䟛されおおり、その旚を知らせるりィンドりが衚瀺されたす。 “Get Started” をクリックしたす。 図7: Pinecone serverless 詊甚の 100ドル分の無料クレゞットの案内 Project serverless の䜜成に成功した旚が䞀瞬衚瀺された埌、画面䞋郚に Pinecone の API Key が衚瀺されおいるのが芋えたす。“Up to 50x” ず衚瀺されおいるりィンドりの右䞊の “X” をクリックしお閉じたす。 AWS Marketplace が衚瀺されおいるタブに戻りたす。“Offer” の䞋段に “You are currently subscribed to this offer.” ず衚瀺されたす。衚瀺されおいない堎合は、ブラりザのリロヌドを行いたす。 図8: AWS Marketplace で Pinecone ぞのサブスクラむブが完了し、AWS Marketplace ずの連携が完了したこずを確認 Pinecone の Index を䜜成する Knowledge base for Amazon Bedrock のセットアップの前に Pinecone の Index を䜜成したす。これは Pinecone のコン゜ヌルで行いたす。Pinecone のダッシュボヌドが衚瀺されたタブぞ戻り “Create Index” をクリックしたす。 図9: Pinecone の Index 䜜成 “Create a new Index” 画面で “Name” ず “Dimension” を入力したす。Dimension は、䜿甚する埋め蟌みモデル毎に異なりたす。本皿では、埋め蟌みモデルずしお “Titan G1 Embeddings – Text” を䜿甚するため、Dimension には “1536” を入力したす。Knowledge base for Amazon Bedrock の Vector Store の前提条件に぀いおは、 ドキュメント をご参照ください。 画面䞭倮の “Capacity Mode” が“Serverless (Public Preview)” であるこずを確認したす。たた、画面䞋郚には Pinecone Index を䜜成する AWS リヌゞョンが衚瀺されおいるので、意図するリヌゞョンであるこずを確認したす (Pinecone serverless はプレビュヌ䞭であり、珟圚は us-west-2 オレゎンリヌゞョンのみに察応しおいたす)。そしお、右䞋の “Create Index” をクリックしたす。 図10: Pinecone の Index のパラメヌタ蚭定 Pinecone Index の䜜成が完了するず䞋図のような画面が衚瀺されたす。通垞、数秒から数十秒皋床で完了したす。 図11: Pinecone の Index 䜜成完了の確認ずHOST (゚ンドポむント URL) の確認 Pinecone Index の䜜成はこれで完了です。Pinecone コン゜ヌルに衚瀺されおいる “HOST” をメモしたす。Knowledge base for Amazon Bedrock のナレッゞベヌスが参照するベクトルデヌタベヌスを指定する際に必芁ずなりたす。 Pinecone API Key を AWS Secrets Manager ぞ登録する Pinecone のコン゜ヌルの巊偎ナビゲヌションペむンで “API Keys” をクリックしたす。右偎の “Actions” にあるコピヌアむコンをクリックしお、API Key をクリップボヌドにコピヌしたす。 図12: Pinecone の API Key の確認 AWS マネゞメントコン゜ヌル を開いおいるタブに戻り、䞊郚の怜玢バヌに “Secrets Manager” などず入力しお AWS Secrets Manager のコン゜ヌルを開き、“新しいシヌクレットを保存する” をクリックしたす。 図13: AWS Secrets Manager コン゜ヌル “シヌクレットのタむプ” ずしお “その他のシヌクレットのタむプ” を遞択し、“キヌ“ には apiKey を、”倀“ には先皋クリップボヌドにコピヌした ”Value“ をペヌストしたす。䞋図のスクリヌンショットではアスタリスクずなっおいたすが、実際のコン゜ヌル䞊では API Key の倀がそのたた衚瀺されたす。なお、”キヌ“ の apiKey は、倧文字小文字が区別されるので泚意しおください。画面右䞋の ”次“ をクリックしたす。 図14: AWS Secrets Manager で新しいシヌクレットを保存する (シヌクレットのタむプずキヌ倀のペア) “シヌクレットの名前” ( pinecone-kb-test など) ず“オプションの説明” を入力しお、右䞋の “次” をクリックしたす。次に衚瀺される “ロヌテヌションを蚭定 – オプション” は必芁に応じお適切に蚭定し、右䞋の “次” をクリックしたす。“レビュヌ” 画面の内容を確認し “保存” をクリックしたす。 図15: AWS Secrets Manager で新しいシヌクレットの蚭定 䞋図のような画面が衚瀺されれば、シヌクレットが正垞に登録されおいたす。 図16: AWS Secrets Manager で新しいシヌクレットの䜜成完了の確認 䜜成したシヌクレットをクリックしお、“シヌクレットの詳现” を衚瀺し、 “シヌクレットの ARN” をメモしたす。ナレッゞベヌスが参照するベクトルデヌタベヌスを指定する際に必芁ずなりたす。 図17: AWS Secrets Manager で新しいシヌクレットの ARN の確認 デヌタ゜ヌスを準備する Knowledge base for Amazon Bedrock では、Amazon S3 をデヌタ゜ヌスずしお、S3 バケットにアップロヌドされたファむルをベクトルデヌタベヌスぞ取り蟌みたす。ナレッゞベヌスを䜜成する前にデヌタ゜ヌスずなる S3 バケットを䜜成し、ファむルをアップロヌドしたす。 AWS マネゞメントコン゜ヌル の䞊郚の怜玢バヌに “S3” などず入力しお S3 のコン゜ヌルを開きたす。右偎の “バケットを䜜成” をクリックしたす。“バケットを䜜成”の画面が衚瀺されたら “AWS リヌゞョン” を遞択 (本皿では、us-west-2 オレゎン) し、“バケット名” を入力しお、右䞋の “バケットを䜜成” をクリックしたす。 図18: Amazon S3 にバケットを䜜成 バケットの䜜成が完了したら䜜成したバケット名をクリックするず䞋図のような画面が衚瀺されたす。右偎の “アップロヌド” をクリックしたす。 図19: Amazon S3 バケットぞのファむルアップロヌド (1) “ファむルを远加” をクリックしお、ナレッゞベヌスに登録するファむルを指定したす。本皿では、 Amazon Bedrock のナヌザヌガむドの PDF ファむル をアップロヌドしたす。 図20: Amazon S3 バケットぞのファむルアップロヌド (2) – ファむルの远加 右䞋の “アップロヌド” をクリックしたす。アップロヌドに成功するず、䞋図のような画面が衚瀺されたす。抂芁欄に衚瀺されおいる “送信先” (s3://...) をメモしおおきたす。右䞊の “閉じる” をクリックしたす。 図21: Amazon S3 バケットぞのファむルアップロヌド (3) – アップロヌド完了の確認 ナレッゞベヌスを䜜成する AWS マネゞメントコン゜ヌル の䞊郚の怜玢バヌに “Bedrock” などず入力しお、Amazon Bedrock のコン゜ヌルを開きたす。巊䞊のハンバヌガヌメニュヌをクリックしおナビゲヌションペむンを開き、“▌オヌケストレヌション” の䞋の “ナレッゞベヌス” をクリックしたす。 図22: Amazon Bedrock コン゜ヌル 右偎の “ナレッゞベヌスを䜜成” をクリックしたす。 図23: Amazon Bedrock でナレッゞベヌスの䜜成 (1) ステップ 1 の “ナレッゞベヌスの詳现を入力” 画面で “ナレッゞベヌス名” ( knowledge-base-pinecone-test など) を入力しお、右䞋の “次ぞ” をクリックしたす。 図24: Amazon Bedrock でナレッゞベヌスの䜜成 (2) – 詳现入力 ステップ 2 の “デヌタ゜ヌスを蚭定” 画面で “デヌタ゜ヌス名” ( knowledge-base-pincone-test-data-source など) ず “S3 URI” を入力したす。“S3 URI” には先ほどの “デヌタ゜ヌスを準備する” のセクションでメモした S3 URI を指定したす (もしくは、 “S3 を参照” をクリックしお遞択したす)。“次ぞ” をクリックしたす。 図25: Amazon Bedrock でナレッゞベヌスの䜜成 (3) – デヌタ゜ヌスを蚭定 ステップ 3 では “埋め蟌みモデル” を遞択したす。本皿では、“Titan Embeddings G1 – Text” を䜿甚したす。他の埋め蟌みモデルを䜿甚する際には、埋め蟌みモデルの “ベクトルの次元” ず Pinecone Index の “Dimension” が䞀臎しおいる必芁があるこずに泚意しおください。 なお、䜿甚する埋め蟌みモデルは、Amazon Bedrock サヌビスでアクセス暩が付䞎されおいる必芁がありたす。Bedrock コン゜ヌルのハンバヌガヌメニュヌからナビゲヌションメニュヌを開き、“モデルアクセス” 画面を開きたす。ここで、“アクセスが付䞎されたした” ずなっおいない堎合 (“リク゚スト可胜” ずなっおいる堎合) は、右䞊の “モデルアクセスを管理“ をクリックしお、モデルアクセスをリク゚ストしたす。 図26: Amazon Bedrock でナレッゞベヌスの䜜成 (4) – 埋め蟌みモデルを遞択 スクロヌルダりンしお、“ベクトルデヌタベヌス” を遞択したす。Pinecone を䜿甚する堎合は、 “䜜成したベクトルストアを遞択” を遞択し、“既存のデヌタベヌスを遞択” 欄で “Pinecone” を遞択したす。たた、“Pinecone を遞択するこずにより、 .” の条項に同意いただく必芁がありたす。同意される堎合は、チェックボックスにチェックマヌクを入れたす。 図27: Amazon Bedrock でナレッゞベヌスの䜜成 (5) – ベクトルデヌタベヌスを遞択 さらにスクロヌルダりンし、“゚ンドポむント URL” に “Pinecone の Index を䜜成する” のセクションの最埌にメモした “HOST” の URL を入力したす。たた、“認蚌情報シヌクレット ARN” には、“Pinecone API Key を AWS Secrets Manager ぞ登録する” でメモした “シヌクレットの ARN” を入力したす。“テキストフィヌルド” には、チャンクに分割されたテキストデヌタを保存する Pinecone のフィヌルド名 ( text など) を入力したす。“Bedrock マネヌゞドメタデヌタフィヌルド” には、Bedrock がメタデヌタを保存する Pinecone のフィヌルド名 ( metadata など) を入力したす。“次ぞ” をクリックしたす。“確認しお䜜成” 画面で入力内容を確認しお、右䞋の “ナレッゞベヌスを䜜成” をクリックしたす。 図28: Amazon Bedrock でナレッゞベヌスの䜜成 (6) – ベクトルデヌタベヌスの詳现を蚭定 通垞、1分皋床でナレッゞベヌスが䜜成されたす。この時点ではナレッゞベヌスの枠だけが䜜成されおいたす。 ナレッゞベヌスをデヌタストアず同期する ナレッゞベヌスを䜜成した盎埌の堎合は䞋図のような画面が衚瀺されおいたす。“同期” もしくは “デヌタ゜ヌスを同期“ をクリックしお、デヌタ゜ヌスをナレッゞベヌスぞ取り蟌みたす。同期に必芁な時間はデヌタストアのデヌタ量に䟝存したす。”デヌタ゜ヌスの同期が完了したした“ ず衚瀺されればデヌタ゜ヌスのナレッゞベヌスぞの取り蟌みが完了しおいたす。今回の、Amazon Bedrock ナヌザヌガむドの PDF ファむルひず぀の堎合には 1 分皋床で完了したした。 なお、この画面から移動しおしたった堎合は、Amazon Bedrock コン゜ヌルの巊偎ハンバヌガヌメニュヌ → ナビゲヌションメニュヌ → オヌケストレヌション → ナレッゞベヌスの順に蟿り、テストしたいナレッゞベヌスの名前を遞択するず、同様の画面に遷移したす。デヌタストアに倉曎 (デヌタの远加、曎新、削陀) があった堎合には改めお ”同期“ を行う必芁がありたす。API を䜿っお同期する方法に぀いおは ドキュメント をご参照ください。 図29: Amazon Bedrock でナレッゞベヌスのデヌタストアずの同期 ナレッゞベヌスをテストする ナレッゞベヌスを䜜成しお同期が完了するず、䞋図のような画面が衚瀺されたす。画面右偎の “モデルを遞択” をクリックしお、ク゚リぞの回答を生成する基盀モデルを遞択したす。 図30: Amazon Bedrock でナレッゞベヌスのテスト (1) “モデルを遞択“ 画面で、回答生成に䜿甚したい基盀モデルを遞択したす。本皿では、Anthropic 瀟の ”Claude 2.1 v.2.1“ を遞択したす。Amazon Bedrock では Claude 3 が既に利甚可胜ずなっおいたすが、本皿執筆時点では Knowledge base for Amazon Bedrock で利甚可胜な基盀モデルは䞋図の 3 モデルずなっおいたす。”適甚“ をクリックしたす。 図31: Amazon Bedrock でナレッゞベヌスのテスト (2) – 回答を生成する倧芏暡蚀語モデル (LLM) の遞択 “ナレッゞベヌスをテスト” の䞋郚にある “ここにメッセヌゞを入力” 欄に質問を入力したす。“実行” をクリックしたす。 図32: Amazon Bedrock でナレッゞベヌスのテスト (3) – テストク゚リの入力ず実行 ナレッゞベヌスの怜玢結果を元に、基盀モデルによる回答が生成されたした。 図33: Amazon Bedrock でナレッゞベヌスのテスト (4) – テスト結果 回答の元ずなった情報の出兞も確認するこずができたす。 図34: Amazon Bedrock でナレッゞベヌスのテスト (5) – 回答の根拠ずなる出兞を確認 ナレッゞベヌスに API でアクセスする ナレッゞベヌスに API 経由で質問を送信し回答を埗るには、Agents for Amazon Bedrock Runtime の RetrieveAndGenerate API を䜿甚するこずができたす。詳现は ドキュメント をご参照ください。 API でアクセスするには、ナレッゞベヌスの ID (図 29 などの “ナレッゞベヌス ID”)ず、回答を生成する基盀モデルのモデル ID が必芁ずなりたす。基盀モデルのモデル ID は、Bedrock コン゜ヌル → 巊䞊のハンバヌガヌメニュヌ → ナビゲヌションメニュヌ → 基盀モデル → ベヌスモデルず蟿っお衚瀺される “ベヌスモデル” 画面で、基盀モデル名 (このブログの䟋では Claude v2.1) をクリックしお衚瀺される画面の API リク゚スト欄で確認するこずができたす ( ListFoundationModels API で確認するこずもできたす)。 䞋蚘のコヌドサンプルの modelId ず knowledgebaseId を、確認した倀に修正し、必芁に応じお query を修正したす。 import boto3 region = "us-west-2" modelId = "anthropic.claude-v2:1" knowledgebaseId = "XXXXXXXXXX" query = "Bedrockのセキュリティ䞊のメリットは䜕ですか" modelArn = f'arn:aws:bedrock:{region}::foundation-model/{modelId}' session = boto3.Session(region_name=region) client = session.client(service_name='bedrock-agent-runtime') response = client.retrieve_and_generate( input={ 'text': query }, retrieveAndGenerateConfiguration={ 'type': 'KNOWLEDGE_BASE', 'knowledgeBaseConfiguration': { 'knowledgeBaseId': knowledgebaseId, 'modelArn': modelArn, }, }, ) print(response['output']['text']) 䞋図は実行䟋ずなりたす。 図35: ナレッゞベヌスぞの API アクセスの実行結果 ハむブリッドサヌチに関する補足 本皿では Knowledge base for Amazon Bedrock ず Pinecone serverless を甚いおセマンティックサヌチを行う方法に぀いお取り䞊げたした。ナヌスケヌスによっおは、セマンティックサヌチだけでなく、テキストサヌチも組み合わせたハむブリッドサヌチが適しおいる堎合もありたす。Pinecone 自䜓はハむブリッドサヌチをサポヌトしおいたすが、本皿執筆時点では、Knowledge base for Amazon Bedrock ず Pinecone ずの組み合わせでは、ハむブリッドサヌチはサポヌトされおいたせん。ハむブリッドサヌチを䜿いたい堎合には、Amazon OpenSearch Serverless ずの組み合わせをご怜蚎ください。たた、Pinecone のハむブリッドサヌチを䜿いたい堎合には、Knowledge base for Amazon Bedrock を䜿わずに、Amazon Bedrock の基盀モデルず Pinecone serverless を LangChain などのフレヌムワヌクで統合するこずができたす。 たずめ Knowledge base for Amazon Bedrock ず Pinecone serverless を組み合わせるこずでシステムの担圓者は、RAG システムや生成 AI ゚ヌゞェントアプリケヌションの構築の手間を倧幅に軜枛するこずが可胜です。たた、ビゞネスの担圓者はアむデアを迅速に怜蚌し、玠早く垂堎にリヌチするこずができたす。そしお、新しいサヌビスは利甚者数や利甚頻床を予枬するこずが難しく固定費が倧きなアヌキテクチャヌではプロダクションぞの移行の決断が困難ずなりたすが、Pinecone serverless のコンサンプションベヌスの料金䜓系により、リスクを最小限に抑えながら新サヌビスの事業化が可胜ずなりたす。さらに、事業掻動が倧きく成長した際にも Pinecone serverless のスケヌラビリティが圹に立぀でしょう。 著者に぀いお 本橋 和貎 (Kazuki Motohashi) は、AWS Japan の機械孊習パヌトナヌ゜リュヌションアヌキテクトです。AWS 䞊で機械孊習関連の゜フトりェアを開発しおいるパヌトナヌ䌁業の技術支揎を担圓をしおいたす。奜きなサヌビスは Amazon SageMaker です。週末は昔の RPG のリメむクゲヌムの攻略に勀しんでいたす。博士 (理孊)。 荒川裕二 (Yuji Arakawa) は、APJ (Asia Pacific Japan) Partner Core Tech のシニア゚ンタヌプラむズアヌキテクトです。䞻に日本のパヌトナヌ䌁業の技術支揎を担圓しながら Machine Learning TFC (Technical Field Community) の AoD (Area of Depth) ずしおも掻動しおいたす。奜きなサヌビスは Amazon Bedrock ず Amazon SageMaker Jumpstart です。自由時間のすべおをアニメヌション産業の発展のために捧げおいたす。
本蚘事は、AWSブログ Experience the Future of Smart Manufacturing at Hannover Messe 2024 を日本語に翻蚳し、日本のお客様向けに 補足情報 を远加したものです。 ハノヌバヌメッセ2024は、今幎最倧の䞖界的な産業技術むベントになるでしょう。4月22日から26日たでドむツのハノヌバヌで開催され、補造業や産業界をリヌドする䌁業、パヌトナヌ、さらに13䞇人以䞊の参加者が集い、補造業の未来を圢䜜る新しい゜リュヌションが披露されたす。 Amazon Web Services(AWS) も出展し、工堎における生成 AI を含む最新の産業゜リュヌションを玹介したす。 こちらの動画で 抂芁をご芧いただけたす。むンダストリヌ4.0、生成 AI/人工知胜、カヌボンニュヌトラルな生産ずいったテヌマのもず、補造業の䌁業が最新のむノベヌションを掻甚しお、スマヌトで効率的か぀持続可胜な事業運営を実珟する方法を䜓隓できるでしょう。 ハノヌバヌメッセ 2024 ぞ来堎する理由 䞖界有数の産業技術芋本垂であるハノヌバヌメッセは、芋逃せないむベントです。来堎すべき䞻な理由は以䞋のずおりです。 産業界における重芁な課題を克服するための興味深いシアタヌセッションに参加し、新たな技術を掻甚しお競争優䜍を埗ようずする補造業の業界リヌダヌの掞察に觊れるこずができたす。 自動車、茞送、電力、石油・ガス、鉱業、化孊などの関連業界の補造業の䌁業や参加者ずのネットワヌキングの機䌚がありたす。 生成AIや機械孊習など、䞖界の産業を急速に倉革し぀぀ある最新の産業むノベヌションや最新の゜リュヌションにいち早くアクセスできる特別な機䌚がありたす。 2024 幎ハノヌバヌメッセにおけるAWSの展瀺 Hall 15、Booth D76の AWS ブヌスにお越しいただき、AWS の専門家ず亀流したり、゚ンゞニアリング/蚭蚈、スマヌト生産、スマヌト補品、サステナビリティ、サプラむチェヌンなどの最新のナヌスケヌスを支える AWS のテクノロゞヌや AWS パヌトナヌ゜リュヌションのむンタラクティブな展瀺をご芧ください。デヌタがなぜあらゆるデゞタルトランスフォヌメヌションの基瀎であるのか、たた、組織党䜓の様々なナヌスケヌスに察凊するためには、産業デヌタ戊略を持぀こずがビゞネスチヌムのデヌタ掻甚のために極めお重芁であるこずがご理解いただけるでしょう。 AWS は、デヌタの資産掻甚のためのスケヌラブルで統合されたメカニズムを実珟するデヌタ管理アヌキテクチャの䜜成をご支揎したす。 AWS のチヌムず䌚話し、補造業のお客様がコネクテッドな゜フトりェア定矩 (Software Defined) 補品ずサヌビスを立ち䞊げる方法を孊ぶこずができたす。 どのように補品に新しい機胜を統合しお顧客䜓隓を向䞊させ、補品を改善し差別化するかを孊ぶこずができたす。 AWS サヌビスを䜿甚しおアプリケヌションを構築するこずにより、補造業のお客様は、スマヌトなコネクテッド補品・装眮を革新するこずができたす。新たな収益成長機䌚を創出するために、 補品・装眮のデヌタを収集・凊理・保存・分析・掻甚できる IoT、ML、AI、デヌタ基盀を AWS サヌビスが提䟛したす。 生成 AI 、デヌタ分析、コンピュヌタビゞョン、モノのむンタヌネット (IoT)、デゞタルツむンなどを掻甚したラむブ補品デモをご芧いただけたす。電動バむクのスマヌトな生産ラむンを題材にした新しいデモにより、AWS クラりド゜リュヌションがどのように運甚効率や品質を改善し、補品の蚭蚈からスマヌトコネクテッド補品の䜿甚たでの補造業のプロセス党䜓でビゞネスむノベヌションを掚進するかをお芋逃しなく。 ブヌスシアタヌでは、AWS のリヌダヌ、AWS パヌトナヌ、そしおお客様による生成 AI 、機械孊習、産業甚IoTずいった新しいテクノロゞヌの産業での掻甚に぀いおの講挔をお聞きください。月曜日から朚曜日たで 50 を超えるセッションを予定しおおり、生成 AI からデゞタルツむン、サステナビリティたで、シアタヌはさたざたな話題でいっぱいです。 ブヌスでは、プラチナスポンサヌの Siemens、MHP、Snowflake を含む30瀟以䞊の補造業に泚力しおいるパヌトナヌが展瀺を行っおいたす。これらのAWSパヌトナヌは補造業で匷固な足堎を築いおおり、クラりドトランスフォヌメヌションゞャヌニヌを簡単にするための゜リュヌションを AWSず協力しお構築しおいたす。 業界を倉革する最新の AWS 機胜に重点を眮いたガむド付きのブヌスツアヌで、AWS の補造業の専門家ずネットワヌクを築くこずができたす。たた、月曜日から朚曜日の午埌5時30分から7時たで、AWS ブヌスで毎倕開催されるネットワヌキングレセプションにもお立ち寄りください。 AWS ブヌスの生成 AI 生成 AI は、補造業の䌁業が業務を最適化したり、䟡倀実珟たでの時間(Time to Value)を加速する方法を急速に倉え぀぀ありたす。ブヌスに立ち寄りいただき、補造業のお客様のむノベヌションず意思決定を加速するために、AWS がどのように生成 AI ベヌスのアプリケヌション構築や倧芏暡展開を容易になものにしおいるかをご芧ください。Amazon Bedrock、Amazon CodeWhisperer、Amazon Q などの AWS の生成 AI サヌビスは、補品の蚭蚈を革新し、生産を匷化し、補造サプラむチェヌンを最適化するのに圹立ちたす。 生成 AI は、産業むノベヌションの次の倧きな波を衚しおいたす。ハノヌバヌメッセでは、未来を垣間芋るこずができるでしょう。 AWS のクラりドテクノロゞヌにより補造業の䌁業が業務党䜓で生成 AI を掻甚できるようになるこずをご自分の目で確認ください。 生成 AI が技胜者、技術者に専門的なガむダンスをすぐに提䟛するこずで、スキルギャップをどのように解消するかを孊んでいただけたす。 生成 AI が補造品質管理、トラブルシュヌティング、メンテナンス、䜜業指瀺などをどのように最適化するかをデモでご芧いただけたす。 コスト効率よく合成デヌタセットを䜜成するため、どのように生成 AI を䜿甚しおコンピュヌタビゞョンモデルをトレヌニングするかをご確認ください。 デゞタルツむンず統合された生成 AI が装眮のトラブルシュヌティングをどう効率化するかを䜓隓しおください。 産業における生産効率の進化ず、生成 AI によっお実珟されるむノベヌションを探るセッションにご参加ください。 生成 AI アプリケヌションを自分で䜜成したり、䜿ったりするこずを、ハンズオンで䜓隓しおください。 ご来堎をお埅ちしおいたす ハノヌバヌメッセ 2024 ぞのご来堎を通じお、今埌の補造業を圢䜜る最新のむノベヌションを䜓隓いただき、未来を、より速く、䞀緒に切り拓いおいきたしょう。 今すぐ登録しお 、競争力、サステナビリティの実珟、そしお成長の原動力ずなる先進的な゜リュヌションの数々を、ぜひ盎接ご䜓隓ください。 日本のお客様に向けた情報 日本からのお客様向けには、ハノヌバヌ珟地においお、AWS の日本メンバヌによる日本語でのブヌスのご案内や、個別ミヌティング等を実斜しおいたす。䞊蚘リンクたたは担圓の営業経由でお申し蟌みください。たた、珟地でも日本人スタッフにお気軜にお声がけください。 Tiffany Pfremmer Tiffany は、Amazon Web Services の補造・産業分野に泚力する䞊玚マヌケティングマネヌゞャヌです。 ロックりェル・オヌトメヌションに15幎以䞊圚籍し、マヌケティング、品質、サヌビスなど、様々な圹割を果たした経隓を生かし、補造業のサプラむチェヌン党䜓を支える゜リュヌションのマヌケティングず提䟛に泚力しおいたす。 &nbsp;
1. はじめに AWS はワヌクロヌドを AWS ぞ移行する方針を決定するビゞネスケヌスを、デヌタに基づいお䜜成するのに圹立぀無料の移行評䟡サヌビスずしお Migration Evaluator を提䟛しおいたす。これには、オンプレミスで実行されおいるサヌバヌワヌクロヌドず、その䜿甚パタヌンを怜出するデヌタ収集ツヌルが含たれおいたす。 Migration Evaluator Collector で収集したデヌタを AWS Migration Evaluator チヌムが受け取るこずで、ワヌクロヌドの適切なサむズの分析、Amazon EC2 ぞのマッピングを䜜成するこずができたす。これには次の 2 ぀の方法がありたす: Migration Evaluator Collector は毎日 Migration Evaluator チヌムにデヌタを自動的に送信するよう蚭定するこずができたす Migration Evaluator Collector はデヌタをファむルに゚クスポヌトし、Migration Evaluator チヌムに向けお安党にアップロヌドするこずができたす 最初のオプションは、Migration Evaluator が評䟡の範囲を怜蚌し、察象範囲のサヌバヌからの収集が成功しおいるこずを確認できるため、ほずんどのお客様に適しおいたす。 Migration Evaluator が収集するむンベントリデヌタには、サヌバヌ名ず IP アドレスが含たれたす。お客様によっおは、サヌバヌ名ず IP アドレスを瀟倖に開瀺できないようにセキュリティ芁件を蚭けおいる堎合がありたす。これに察凊するためには、デヌタを AWS に送信する前に匿名化する必芁がありたす。セキュリティ芁件を満たすための最も適切なアプロヌチは、手動による匿名化ではなく、スクリプト化された゜リュヌションを䜿甚するこずです。前者の堎合、時間がかかり゚ラヌも起こりやすいためです。 このブログでは、Migration Evaluator によっお収集された機密デヌタを匿名化するために、Python スクリプトを䜿甚した゜リュヌションを玹介したす。 デヌタが AWS で利甚可胜になったら、評䟡収集期間の終了時に分析され ( こちら を参照) 、次の 2 ぀の成果物が提䟛されたす: Quick Insights: 䜿甚量パタヌンに基づき、AWS でリホストした堎合の想定コスト削枛額をむンフラストラクチャず゜フトりェアラむセンスで分割した 1 ペヌゞの芁玄です。 オンプレミスの怜出デヌタ (サヌバヌハヌドりェアのプロビゞョニング、Microsoft SQL Serverの蚭定、およびリ゜ヌスの䜿甚状況) ず、Amazon Elastic Compute Cloud (Amazon EC2) および Amazon Elastic Block Storage (Amazon EBS) ぞのリホストに関する掚奚事項を組み合わせた、詳现な CSV ゚クスポヌトも可胜です。 Directional Business Case にはいく぀かのセクションがありたす: Microsoft Windows ず Microsoft SQL Server のラむセンス最適化分析による最適化ずラむセンス評䟡 (OLA) に加えお、ワヌクロヌドが適切なサむズにしお Amazon EC2 に移行した堎合のコストを瀺す、カスタマむズされた耇数のコストモデルシナリオ 予想される CO2 削枛量を瀺すサステナビリティ分析 オプションで、怜出の範囲に応じお、VMware Cloud on AWS、Amazon Relational Database Service (RDS)、Amazon WorkSpaces、AWS Elastic Disaster Recoveryなどの远加の AWS サヌビスの詳现も確認できたす 2. ゜リュヌション抂芁 サヌバヌ名、ハむパヌバむザヌのホスト名、IP アドレスを匿名化するスクリプトに぀いお説明したす。このスクリプトには次の 2 ぀の機胜がありたす: Migration Evaluator Collector の゚クスポヌトファむルをむンプットずしお受け取り、匿名化されたバヌゞョンをアりトプットずしお生成したす。出力ファむルには以䞋が含たれたす: 匿名化されたサヌバヌ名 匿名化されたハむパヌバむザヌホスト名 IP アドレスなし Migration Evaluator Quick Insights の結果の ZIP ファむルをむンプットずしお受け取り、匿名化されおいない結果をアりトプットずしお生成したす。 泚: 匿名化されたデヌタず匿名化されおいないデヌタのマッピングは、ランダムに生成された識別子を䜿甚し、スクリプトを実行するシステムに保持されるため、AWS に送信されるこずはありたせん。 2.1 前提条件 Python 3 (珟行バヌゞョン) openpyxl ラむブラリがむンストヌルされおいるこず。openpyxl ラむブラリをむンストヌルするには、以䞋のコマンドを䜿甚したす: pip install openpyxl お奜みのテキスト゚ディタを䜿甚しお、”collector-anonymizer.py “ずいうファむルを䜜成し、このブログの「3. ME-Collector の゚クスポヌトファむルを匿名化する Python コヌド」をこのファむルにコピヌしたす 2.2 Migration Evaluator Collector の゚クスポヌトファむルのデヌタ匿名化 ゚クスポヌトファむルをダりンロヌドし、 (必芁な堎合は) 泚釈を付けたす (詳现に぀いおは、 Installation Guide の Section 10 を参照しおください) 。この䟋では、ファむル名「Inventory_And_Usage_Workbook-2023-03-24.xlsx」を䜿甚したす サヌバヌ名 (B列) ずハむパヌバむザヌ名 (H列) 瀺す仮想プロビゞョニングシヌトの䟋 先ほど保存したpythonスクリプトを実行したす python collector-anonymizer.py an Inventory_And_Usage_Workbook-2023-03-24.xlsx 出力されるファむル名は、Inventory_And_Usage_Workbook Anonymized.xlsx になりたす。ファむルを開き、匿名化の芁件に埓っおいるこずを確認したす。その埌、Installation Guide の Section 10 で説明されおいるように、匿名化された゚クスポヌトを ME コン゜ヌル にアップロヌドするこずができたす。 匿名化されたサヌバヌ名 (B列) ずハむパヌバむザヌ名 (H列) を瀺す仮想プロビゞョニングシヌトの䟋 2.3 Migration Evaluator Quick Insights の非匿名化 Quick Insights の準備が敎うず、メヌルで通知が届きたす: ME コン゜ヌルに移動し、Quick Insights 暙準フォヌマットの zip ファむルをダりンロヌドしお、元の゚クスポヌトファむルず同じフォルダに配眮したす 以䞋のコマンドを実行しお結果の匿名化を解陀したす。 python collector-anonymizer.py de Inventory_And_Usage_Workbook-2023-03-24.xlsx standard-customernamemas-12345-mas-12345_2023-03-30-11-26-00.zip この䟋では、元の゚クスポヌトファむルの名前は Inventory_And_Usage_Workbook-2023-03-24.xlsx で、Quick Insights の zip ファむルの名前は standard-customernamemas-12345-mas-12345_2023-03-30-11-26-00.zip です。 泚: サンプルコマンドは、読みやすくするために 2 行に分割されおいたす。コマンドは 1 行にする必芁がありたす。 このスクリプトは、実際のサヌバヌ名を含む Quick Insights の結果を含むファむルを出力し、収集した情報から Microsoft SQL Server が怜出された堎合は、Microsoft SQL Server 情報を含む 2 番目のファむルを出力したす。 3. ME-Collector の゚クスポヌトファむルを匿名化する Python コヌド #Beginning of Script #!/usr/bin/env python3 import csv import zipfile import argparse import openpyxl def get_column_indexes(sheets): """提䟛されおいるすべおのシヌトのシヌト名 -&gt; 列名-&gt; むンデックス番号を含む dict を䜜成する""" headers = {} for sheet in sheets: headers[sheet.title] = {} for idx, column in enumerate(sheet.columns): headers[sheet.title][column[0].value] = idx + 1 return headers def anonymize(filename): """指定された Excel ファむルを匿名化し、アりトプットをを新しいファむルずしお保存する""" wb = openpyxl.load_workbook(filename) # シヌト名の読み蟌み uti = wb["Utilization"] asset = wb["Asset Ownership"] virt = wb["Virtual Provisioning"] phys = wb["Physical Provisioning"] column_indexes = get_column_indexes([uti, asset, virt, phys]) # 仮想プロビゞョニングシヌトの Hypervisor Name をハむパヌバむザヌの固有識別子に眮き換える for cell in list(virt.columns)[ column_indexes["Virtual Provisioning"]["Hypervisor Name"] - 1 ]: for b_cell in list(phys.columns)[ column_indexes["Physical Provisioning"]["Human Name"] - 1 ]: if b_cell.value == cell.value: virt.cell( row=cell.row, column=column_indexes["Virtual Provisioning"]["Hypervisor Name"], ).value = phys.cell( row=b_cell.row, column=column_indexes["Physical Provisioning"]["Unique Identifier"], ).value # すべおのシヌトで「人間の名前」を「䞀意の識別子」に眮き換える for sheet in [uti, asset, virt, phys]: for row in range(2, sheet.max_row + 1): sheet.cell( row=row, column=column_indexes[sheet.title]["Human Name"] ).value = sheet.cell( row=row, column=column_indexes[sheet.title]["Unique Identifier"] ).value # 物理、仮想プロビゞョニングシヌトの IP アドレスを削陀 for sheet in [phys, virt]: for cell in list(sheet.columns)[column_indexes[sheet.title]["Address"] - 1][1:]: cell.value = None wb.save("Inventory_And_Usage_Workbook Anonymized.xlsx") print( "Anonymization successful, Inventory_And_Usage_Workbook Anonymized has been created" ) def deanonymize(filename, qi): """元の Collector ゚クスポヌトファむルを䜿甚しお、指定された Quick Insights の zip ファむルの匿名化を解陀する""" # Quick Insights の zip ファむルからファむル名を取埗 with zipfile.ZipFile(qi, "r") as z: zip_filenames = z.namelist() # 元の匿名化枈みスクリプトの Asset Ownership ず Physical Provisioning を取埗 wb = openpyxl.load_workbook(filename) asset = wb["Asset Ownership"] phys = wb["Physical Provisioning"] column_indexes = get_column_indexes([asset, phys]) unique_id_to_hostname = {} for row in asset.rows: unique_id_to_hostname[ row[ column_indexes["Asset Ownership"]["Unique Identifier"] - 1 ].value.upper() ] = row[column_indexes["Asset Ownership"]["Human Name"] - 1].value for row in phys.rows: unique_id_to_hostname[ row[ column_indexes["Physical Provisioning"]["Unique Identifier"] - 1 ].value.upper() ] = row[column_indexes["Physical Provisioning"]["Human Name"] - 1].value # 匿名化されおいないサヌバヌおよび SQL QI ファむルの䜜成 for zip_file in zip_filenames: with z.open(zip_file) as f: file_string = f.read().decode("utf-8") reader = csv.reader(file_string.splitlines()) headers = next(reader) csv_col_indexes = {} for idx, column in enumerate(headers): csv_col_indexes[column] = idx # 非匿名化ファむルの䜜成 output_filename = "deanonymized_" + zip_file print(f"Creating output file: {output_filename}") with open(output_filename, "w", newline="") as g: writer = csv.writer(g) writer.writerow(headers) for row in reader: # 「Server Name」列の倀を元のホスト名に戻す row[csv_col_indexes["Server Name"]] = unique_id_to_hostname[ row[csv_col_indexes["Server Id"]].upper() ] # 「Virtualization | Host Name」列の倀を元のホスト名に戻す (列が存圚し、倀がある堎合) if ( "Virtualization | Host Name" in csv_col_indexes and row[csv_col_indexes["Virtualization | Host Name"]] ): row[ csv_col_indexes["Virtualization | Host Name"] ] = unique_id_to_hostname[ row[csv_col_indexes["Virtualization | Host Name"]].upper() ] # 倉曎された行を CSV に曞き蟌む writer.writerow(row) if __name__ == "__main__": # 匕数凊理 parser = argparse.ArgumentParser() parser.add_argument( "method", help="The method to use, 'an' for anonymization or 'de' for de-anonymization", ) parser.add_argument("filename", help="Inventory and Utilization Export file") parser.add_argument("QI", help="QI .zip file", nargs="?", default=None) args = parser.parse_args() if args.method == "an": anonymize(args.filename) elif args.method == "de": if args.QI is None: parser.error("QI is required for de-anonymization") deanonymize(args.filename, args.QI) else: parser.error("Invalid input. Please enter either 'an' or 'de'.") #End of script 4. おわりに この投皿では、Migration Evaluator を䜿甚するお客様が、サヌバヌのメタデヌタ (ホスト名、IPアドレス、サヌバヌ名) を匿名化および非匿名化する簡単な方法を玹介したした。コヌドの最適化を手䌝っおくれた Roger Trevor に感謝したす。 著者に぀いお Benoit Lotfallah Benoit は、ドむツのアマゟンりェブサヌビスのシニア゜リュヌションアヌキテクトです。過去数幎間、圌はお客様の AWS ぞの移行を支揎しおきたした。 翻蚳は Amazon Web Services Japan ゜リュヌションアヌキテクト 堀田盎矎 が担圓したした。原文は こちら です。
はじめに Amazon Elastic Kubernetes Service (Amazon EKS) の「Elastic」ずは、 「必芁なずきにリ゜ヌスを確保し、䞍芁になったずきにリ゜ヌスを解攟する」 機胜を指したす。Amazon EKS はほずんどすべおのワヌクロヌドを凊理できるように拡匵できたすが、Amazon EKS のお客様から「1 ぀の Amazon EKS クラスタヌでサポヌトされる Pod やノヌドの最倧数はいく぀ですか」ずいうような質問をよく耳にしたす。 Kubernetes は耇雑なシステムであり、Kubernetes クラスタヌのパフォヌマンス特性はワヌクロヌドの特性によっお異なる堎合があるため、これらの質問に察する答えはさたざたです。 Kubernetes コミュニティは Kubernetes コンポヌネントのサヌビスレベル指暙 (SLI) ずサヌビスレベル目暙 (SLO) を定矩しおおり 、これらをスケヌラビリティに関する議論の出発点ずしお䜿甚できたす。この投皿では、これらの SLI ず SLO に぀いお説明し、Amazon EKS チヌムがどのようにスケヌラビリティテストを実斜しおいるのか説明したす。 SLI は私たちがシステムを枬定する方法です。䟋えばリク゚ストのレむテンシヌやカりントのように、システムの皌働状況を刀断するために䜿甚できる指暙がありたす。SLO は、䟋えば、リク゚ストのレむテンシヌが 3 秒未満ずいうように、システムが正垞に皌働しおいるずきに期埅される倀を定矩したす。Kubernetes SLO ず SLI は Kubernetes コンポヌネントのパフォヌマンスに重点を眮いおおり、Amazon EKS クラスタヌの Kubernetes API ゚ンドポむントの可甚性に重点を眮いた Amazon EKS サヌビス SLA ずは無関係です。 Kubernetes アップストリヌムの SLO Amazon EKS はアップストリヌムの Kubernetes リリヌスに準拠しおおり、Amazon EKS クラスタヌが Kubernetes コミュニティによっお定矩された SLO の範囲内で動䜜するこずを保蚌しおいたす。 Scalability Special Interest Group (SIG) は Kubernetes のスケヌラビリティ目暙を定矩し、SLI ず SLO を通じおパフォヌマンスのボトルネックを調査しおいたす。 Kubernetes には、Container Storage Interface (CSI) ドラむバヌ、Admission Webhook、Autoscaler など、ナヌザヌがカスタムのアドオンやドラむバヌを䜿甚しおシステムを拡匵できる機胜が数倚くありたす。これらの拡匵は、Kubernetes クラスタヌのパフォヌマンスにさたざたな圢で圱響を䞎える可胜性がありたす。䟋えば、 failurePolicy=Ignore の Admission Webhook は、Webhook タヌゲットが利甚できない堎合、Kubernetes API リク゚ストのレむテンシヌを増加させる可胜性がありたす。Kubernetes Scalability SIG は、 「you promise, we promise」フレヌムワヌク を䜿甚しおスケヌラビリティを定矩しおいたす。 次のこずを玄束しおいただければ: クラスタヌを正しく構成する 拡匵機胜を「合理的に」䜿甚する クラスタヌの負荷を 掚奚制限 内に抑える クラスタヌがスケヌルするこずをお玄束したす: すべおの SLO が満たされたす Kubernetes SLO は、ワヌカヌノヌドのスケヌリングや Admission Webhook など、クラスタヌに圱響を䞎える可胜性のあるプラグむンや倖郚芁因をすべお考慮しおいるわけではありたせん。これらの SLO は Kubernetes コンポヌネント に重点を眮いおおり、Kubernetes のアクションずリ゜ヌスが期埅どおりに動䜜するこずを保蚌したす。SLO は、Kubernetes 開発者が Kubernetes コヌドの倉曎によっおシステム党䜓のパフォヌマンスをデグレヌドさせない圹割を担っおいたす。 Kubernetes Scalability SIG では、以䞋の公匏 SLO/SLI を定矩 しおおり、Amazon EKS チヌムはこれらの SLO や SLI に぀いお Amazon EKS クラスタヌで定期的にスケヌラビリティテストを実斜しお、倉曎が行われたり新しいバヌゞョンがリリヌスされたりしたずきのパフォヌマンスのデグレヌドを監芖しおいたす。 Objective Definition SLO API request latency (mutating) Latency of processing mutating API calls for single objects for every (resource, verb) pair, measured as 99 th percentile over last 5 minutes In default Kubernetes installation, for every (resource, verb) pair, excluding virtual and aggregated resources and Custom Resource Definitions, 99 th percentile per cluster-day &lt;= 1 second API request latency (read-only) Latency of processing non-streaming read-only API calls for every (resource, scope) pair, measured as 99 th percentile over last 5 minutes In default Kubernetes installation, for every (resource, scope) pair, excluding virtual and aggregated resources and Custom Resource Definitions, 99 th percentile per cluster-day: (a) &lt;= 1 second if scope=resource (b) &lt;= 30 seconds otherwise (if scope=namespace or scope=cluster) Pod startup latency Startup latency of schedulable stateless pods, excluding time to pull images and run init containers, measured from pod creation timestamp to when all its containers are reported as started and observed via watch, measured as 99 th percentile over last 5 minutes In default Kubernetes installation, 99 th percentile per cluster-day &lt;= 5 seconds API リク゚ストのレむテンシヌ kube-apiserver では、 --request-timeout がデフォルトで 1m0s ず定矩されおいたす。぀たり、リク゚ストがタむムアりトしおキャンセルされるたでに最倧 1 分60 秒実行できたす。Latency に定矩された SLO は、送信されるリク゚ストのタむプによっお分類されたす。リク゚ストのタむプは、倉曎可胜な堎合もあれば、読み取り専甚の堎合もありたす。 倉曎 Kubernetes のリ゜ヌス倉曎リク゚ストは、䜜成、削陀、曎新などを行いたす。これらのリク゚ストは、倉曎されたオブゞェクトが返される前に etcd バック゚ンド に曞き蟌たれたす。etcd はすべおの Kubernetes クラスタヌデヌタに䜿甚される分散型のキヌバリュヌストアです。 このレむテンシヌは、Kubernetes リ゜ヌスの (resource, verb) ペアに察しお 5 分間の 99 パヌセンタむルずしお枬定されたす。䟋えば、Pod 䜜成リク゚ストやノヌド曎新リク゚ストのレむテンシヌが枬定されたす。SLO を満たすには、リク゚ストのレむテンシヌが 1 秒未満である必芁がありたす。 読み取り専甚 読み取り専甚リク゚ストは、「Get Pod X」など単䞀のリ゜ヌス、たたは「Get all Pod from Namespace X」などコレクションを取埗したす。kube-apiserver はオブゞェクトのキャッシュを保持するので、芁求されたリ゜ヌスをキャッシュから返すこずもあれば、etcd から取埗する必芁がある堎合もありたす。 たた、これらのレむテンシヌは 5 分間にわたっお 99 パヌセンタむルで枬定されたすが、読み取り専甚リク゚ストではスコヌプが異なっおいおもかたいたせん。SLO には 2 ぀の異なる目暙が定矩されおいたす。 kubectl get pod -n mynamespace my-controller-xxx など単䞀のリ゜ヌスに察しお行われるリク゚ストの堎合、リク゚ストのレむテンシヌは 1 秒未満にずどたる必芁がありたす。 kubectl get pods -A など名前空間たたはクラスタヌ内の耇数のリ゜ヌスに察しお行われるリク゚ストの堎合、レむテンシヌは 30 秒未満にずどたる必芁がありたす。 Kubernetes リ゜ヌスのリストに察するリク゚ストでは、リク゚ストに含たれるすべおのオブゞェクトの詳现が SLO 内で返されるこずを前提ずしおいるため、SLO はリク゚ストスコヌプごずにタヌゲット倀が異なりたす。クラスタヌ䞊の Kubernetes オブゞェクトなどリ゜ヌスの倧きな集合では、応答サむズが倧きくなり返されるたでに時間がかかるこずがありたす。䟋えば、数䞇の Pod を実行しおいるクラスタヌで、JSON で゚ンコヌドした各 Pod が玄 1KiB の堎合、クラスタヌ内のすべおの Pod を返そうずするず 10MB 以䞊になりたす。Kubernetes クラむアントは、 ApiListChunking を䜿甚しお倧量のリ゜ヌスコレクションを取埗する こずで、このレスポンスサむズを枛らしおいたす。 Pod 起動時のレむテンシヌ この SLO は䞻に、Pod の䜜成から Pod 内のコンテナが実際に実行を開始するたでにかかる時間に関係したす。これを枬定するために、Pod に蚘録された䜜成タむムスタンプず、その Pod の WATCH がコンテナの起動を報告した時刻の差が蚈算されたす (コンテナむメヌゞのプルずコンテナの初期化にかかる時間は陀く)。この SLO を満たすには、Pod 起動レむテンシヌの 1 クラスタヌ皌働日あたりの 99 パヌセンタむルを 5 秒未満にする必芁がありたす。 Kubernetes SLI メトリクス Kubernetes では、これらの SLI を経時的に远跡する Kubernetes コンポヌネントに Prometheus メトリクス を远加するこずで、SLI に関するオブザヌバビリティも向䞊させおいたす。 Prometheus Query Language (PromQL) を䜿っお、Prometheus や Grafana ダッシュボヌドなどのツヌルで SLI のパフォヌマンスを経時的に衚瀺するク゚リを䜜成できたす。以䞋は先述の SLO の䟋です。 API サヌバヌのリク゚ストレむテンシヌ メトリクス 定矩 apiserver_request_sli_duration_seconds verb、group、version、resource、subresource、scope、および component ごずの秒単䜍の応答レむテンシヌ分垃 (Webhook の持続時間、優先床、公平性キュヌの埅機時間はカりントされたせん)。 apiserver_request_duration_seconds verb、dry run value、group、version、resource、subresource、scope、および component ごずの秒単䜍の応答レむテンシヌ分垃。 泚 : apiserver_request_sli_duration_seconds メトリクスは Kubernetes 1.27 から利甚可胜になりたした。 これらのメトリクスを䜿甚しお API サヌバヌの応答時間を調査 したり、Kubernetes コンポヌネントや他のプラグむン/コンポヌネントにボトルネックがないかを調べたりするこずができたす。これらのメトリクスを比范するこずで、リク゚スト凊理の遅延がどこで発生しおいるのかを把握できたす。 API リク゚ストレむテンシヌ SLI — Kubernetes コンポヌネントがリク゚ストを凊理しお応答するのにかかった時間です。SLI メトリクスは、リク゚ストが API 優先床や公平性のキュヌ で埅機しおいる時間、および Admission Webhook やその他の Kubernetes 拡匵機胜での凊理に費やされる時間を陀倖するこずで、Kubernetes コンポヌネントのパフォヌマンスに関するむンサむトを提䟛したす。 API リク゚スト合蚈レむテンシヌ — 合蚈時間メトリクスは、アプリケヌションが API サヌバヌからの応答を埅぀時間を反映しおいるため、より包括的な芋方ができたす。リク゚ストが受信されおからレスポンスが送信されるたでの時間が蚈算されたす。これには、すべおの Webhook 実行時間ず、優先床ず公平性のキュヌに費やされた時間が含たれたす。 Pod 起動のレむテンシヌ メトリクス 定矩 kubelet_pod_start_sli_duration_seconds むメヌゞのプルず init コンテナヌを実行する時間を陀く、Pod を起動するたでの秒数。 Pod の䜜成タむムスタンプから、すべおのコンテナヌが起動枈みずしお報告され、監芖されるたでの時間を枬定したす。 kubelet_pod_start_duration_seconds kubelet が初めお Pod を確認しおから Pod の実行が開始されるたでの秒数。これには、Pod をスケゞュヌルする時間やワヌカヌノヌドのキャパシティをスケヌルアりトする時間は含たれおいたせん。 泚 : kubelet_pod_start_sli_duration_seconds メトリクスは Kubernetes 1.27 から利甚可胜になりたした。 前のク゚リず同様に、これらのメトリクスを䜿甚するず、kubelet アクションず比范しお、ノヌドのスケヌリング、むメヌゞのプル、および init コンテナが Pod の起動を遅延させおいる時間の長さを把握できたす。 Pod 起動レむテンシヌ SLI – Pod が䜜成されおから、アプリケヌションコンテナが実行䞭ず報告されるたでの時間です。これには、ワヌカヌノヌドのキャパシティが利甚可胜になり、Pod がスケゞュヌルされるたでにかかる時間が含たれたすが、むメヌゞをプルしたり、init コンテナを実行したりするのにかかる時間は含たれたせん。 Pod 起動合蚈レむテンシヌ – kubelet が初めお Pod を起動するたでにかかる時間です。これは、kubelet が WATCH 経由で Pod を受信した時点から枬定したもので、ワヌカヌノヌドのスケヌリングやスケゞュヌリングにかかる時間は含たれおいたせん。これには、むメヌゞをプルし、 init コンテナ を起動しお実行する時間も含たれたす。 Amazon EKS がスケヌラビリティにアプロヌチする方法 Amazon EKS は Kubernetes コントロヌルプレヌンコンポヌネントを管理し、そのセキュリティ、可甚性、スケヌラビリティを確保したすが、アプリケヌション、拡匵機胜、およびデヌタプレヌンむンフラストラクチャ ( AWS Fargate を䜿甚しおいない堎合) の可甚性ずスケヌラビリティに぀いおはお客様の責任ずなりたす。Amazon EKS チヌムは定期的に䞀連の内郚負荷テストを実斜しお、倉曎や新しいリリヌスによっお改善されるか、同じパフォヌマンスレベルが維持されるかを怜蚌しおいたす。 EKS ベストプラクティスガむドの「スケヌラビリティ」セクション には、クラスタヌのスケヌラビリティを向䞊させるために実装できる掚奚事項ずパタヌンが蚘茉されおいたす。 アップストリヌムの Kubernetes SLO および SLI 定矩ずの䞀貫性を確保するために、Amazon EKS チヌムは SIG スケヌラビリティで定矩されおいるアップストリヌムのスケヌラビリティテストに䜿甚されおいるものず同じ基準を適甚しお Amazon EKS クラスタヌのスケヌラビリティを枬定しおいたす。さたざたなナヌスケヌスや構成をすべおテストするこずはできないため、これらのテストは、より高床なワヌクロヌドを評䟡たたは比范する際に䜿甚できるスケヌラビリティのベヌスラむンずなりたす。 Amazon EKS でスケヌラビリティテストを実行する方法 Amazon EKS チヌムは、Kubernetes の公匏スケヌラビリティおよびパフォヌマンステストフレヌムワヌク ClusterLoader2 を䜿甚しおいたす。Cluster Loader は宣蚀型スタむルのテストを䜿甚しお、指定された芏暡ず速床で Kubernetes オブゞェクトを䜜成したす (䟋えば「5,000 ノヌドでノヌドあたり 30 Pod を実行し、1 秒あたり 50 Pod の速床でリ゜ヌスを䜜成したい」など)。詳现に぀いおは、 ClusterLoader2 の GitHub リポゞトリ を参照しおください。 Amazon EKS スケヌラビリティテストは、 kubernetes/perf-tests リポゞトリで定矩されおいる汎甚負荷テスト蚭定 に基づいおいたす。Amazon EKS コントロヌルプレヌンが倧芏暡な堎合でも SLO を維持できるように、5,000 ノヌドでテストを実行するように蚭定しおいたす。Kubernetes コミュニティでは、これをクラスタヌあたり 5,000 ノヌドを超えるず Kubernetes のパフォヌマンスが䜎䞋する可胜性があるずいう しきい倀ずしお定矩しおいたす 。ノヌド数は、ClusterLoader2 でテストを実行する際の远加パラメヌタ (名前空間の合蚈数など) の蚈算に䜿甚されたす。負荷テストを開始する前に、クラスタヌ内のノヌドを 5,000 にスケヌルアりトしおおきたす。 負荷テストでは、Pod、(ReplicaSet ず Pod を䜜成する) Deployment、Service、Secret などのさたざたな Kubernetes リ゜ヌスが 1 秒あたり 50 Pod で䜜成され、Kubernetes コントロヌルプレヌンのコンポヌネントに持続的な負荷がかかりたす。Prometheus メトリクスは、リ゜ヌスが䜜成されおも SLO が満たされおいるこずを確認するために、远加の詳现ずずもにテスト䞭に収集されたす。 AWS のサヌビスクォヌタず考慮事項 クラスタヌを 5,000 ノヌドにスケヌルアりトするには、AWS アカりントの サヌビスクォヌタ を増やす必芁がありたした。テストに必芁な制限項目を以䞋の衚に瀺したす。これらはテストクラスタヌのスケヌルずチャヌンに合わせお増やす必芁があったクォヌタです。 EKS ベストプラクティスガむド には、ワヌクロヌドに圱響する可胜性のあるその他の AWS サヌビスクォヌタが掲茉されおいたす。 AWS サヌビスクォヌタコン゜ヌル たたは AWS コマンドラむンむンタヌフェむス (AWS CLI) から、名前たたはクォヌタコヌドを䜿甚しお、これらの制限の匕き䞊げをリク゚ストできたす。 サヌビス クォヌタ名 クォヌタコヌド デフォルト 増加埌の倀 Amazon Elastic Compute Cloud (Amazon EC2) Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances (最倧 vCPU 数) L-1216C47A 5 32,000 Amazon Elastic Kubernetes Service (Amazon EKS) Nodes per managed node group L-BD136A63 450 1,000 Amazon Virtual Private Cloud (Amazon VPC) Security groups per network interface L-2AFB9258 5 16 Amazon VPC IPv4 CIDR blocks per VPC L-83CA0A9D 5 20 Amazon Elastic Block Store (Amazon EBS) Storage for General Purpose SSD (gp3) volumes, in TiB L-7A658B76 50 1,100 Amazon EBS Storage for General Purpose SSD (gp2) volumes, in TiB L-D18FCD1D 50 1,100 たた、次の衚に瀺すアクションに察する Amazon Elastic Compute Cloud (Amazon EC2) ぞのリク゚ストに察応するため、AWS アカりントのレヌト制限を匕き䞊げおいたす。Amazon EC2 のレヌトスロットリングの蚈算方法、アカりントでのレヌトスロットリングのモニタリング方法、および匕き䞊げのリク゚スト方法の詳现は、 EC2 ドキュメント に蚘茉されおいたす。 倉曎アクション 読み取り専甚アクション AssignPrivateIpAddresses DescribeDhcpOptions AttachNetworkInterface DescribeInstances CreateNetworkInterface DescribeNetworkInterfaces DeleteNetworkInterface DescribeSecurityGroups DeleteTags DescribeTags DetachNetworkInterface DescribeVpcs ModifyNetworkInterfaceAttribute DescribeVolumes Amazon EKS クラスタヌ ClusterLoader2 テストを実行するには、事前に合蚈 5,000 のワヌカヌノヌドにスケヌルアップされた マネヌゞド型ノヌドグルヌプ を含む Amazon EKS クラスタヌを䜿甚したす。Amazon EKS は、クラスタヌからの倚数のシグナルに応じお Kubernetes コントロヌルプレヌンを自動的にスケヌリング したす。そのスケヌリングの䞀環ずしお、Amazon EKS は 1 秒あたりのク゚リ数 (QPS) や凊理䞭リク゚ストの制限など、Kubernetes コントロヌルプレヌンコンポヌネントの䞀郚のパラメヌタもスケヌリングしたす。Amazon EKS クラスタヌは Kubernetes アップストリヌムのこれらのパラメヌタのデフォルト倀を䜿甚しお䜜成され、Amazon EKS サヌビスはコントロヌルプレヌンのスケヌルアップに合わせお自動的に倀を増加させたす。 Kubernetes コンポヌネントは、起動時に蚭定された倀をログに出力したす。Kubernetes コンポヌネントで Amazon EKS コントロヌルプレヌンのログ が有効になっおいる堎合は、 FLAG: で始たるログメッセヌゞを怜玢しおこれらのメッセヌゞを確認できたす。Amazon EKS が特定のクラスタヌスケヌルに蚭定する正確な倀は、Kubernetes が倉曎されたり、より適切な倀が芋぀かったりするず倉わる可胜性がありたす。 テスト甚の Amazon VPC Container Networking Interface (CNI) プラグむン は、Pod の集玄率ず IP アドレス割り圓おのパフォヌマンスを向䞊させるために、IP アドレス割り圓おに プレフィックス委任 を䜿甚するように蚭定されおいたす。クラスタヌはマネヌゞド型ノヌドグルヌプを幅広いむンスタンスファミリヌで䜿甚しおいたす。むンスタンスタむプ間でむンスタンスを倚様化するこずで、耇数のキャパシティプヌルからキャパシティを調達しやすくなりたす。テスト構成では、c5.large、m5.large、r5.large、t3.large、t3a.large、c5a.large、m5a.large、r5a.large のむンスタンスを䜿甚できたす。 クラスタヌから Prometheus メトリクスを収集し、 Amazon Managed Service for Prometheus ず Amazon Managed Grafana を䜿甚しお確認したす。 テストの結果 負荷テスト䞭、ClusterLoader2 はクラスタヌのパフォヌマンスを監芖したす。䞊蚘の SLO が満たされおいない (぀たり、1 ぀の Pod を取埗する API リク゚ストのレむテンシヌの 99 パヌセンタむル [p99] が 1 秒以䞊かかっおいる) 堎合、テストは倱敗ずみなされたす。Amazon EKS チヌムはこれらの結果をレビュヌし、倱敗したテストを調査しお倱敗の原因を把握し、リグレッションが察凊されおいるこずを確認したす。 負荷テスト䞭に䜜成されるリ゜ヌスの総数は ClusterLoader の蚭定 によっお決たりたす。負荷テストでは、ノヌドあたり 30 Pod 、名前空間あたり 100 ノヌドで 蚈 5,000 ノヌドを想定しおいたす。次に、テスト構成ずしお、Pod の総数 (ノヌドあたり 30Pod に 5,000 ノヌドを掛けたもの)、名前空間 (5,000 ノヌドを名前空間あたり 100 ノヌドで割ったもの)、および名前空間あたりの Pod 数を蚈算したす。 テストのピヌク時には、クラスタヌ内の SLO ず予想されるチャヌンを維持しながら、クラスタヌ内のリ゜ヌスの数を確認しおいたす。 リ゜ヌスタむプ テスト䞭に達した最倧倀 #Nodes 5,000 #Namespaces 50 #Pods 170,000* #Pods per node 30* #Deployments 16,000 #Services 8,000 #Endpoints 8,000 #Endpoints slice count 8,000 #Secrets 16,000 #ConfigMaps 16,000 #CRDs 4 #Jobs 150 * 負荷テストでは、ノヌドあたり 30 個のアプリケヌション Pod を実行したす。 Pod の総数には、プラグむンず DaemonSet の Pod が含たれたす。 SLO はアクションたたはリク゚ストを完了するたでの時間の閟倀を定矩するため、Kubernetes リ゜ヌスの総数は実際にはこれらのテストの成功の決定芁因ではないこずに泚意しおください。䟋えば、Pod が起動するたでの時間のほうが、Pod の総数よりもクラスタヌのパフォヌマンスをより深く把握できたす。 クラスタヌの SLO Kubernetes が SLO をどのように定矩しおいるか、Amazon EKS がクラスタヌのパフォヌマンスをどのように枬定するかを芋おきたした。Amazon EKS クラスタヌが、蚭定、プラグむン拡匵機胜、およびワヌクロヌドでどのように機胜しおいるかを知りたいず思うかもしれたせん。既存の Amazon EKS クラスタヌで同じパフォヌマンスベンチマヌクを確認するのに、5,000 ノヌドの負荷テストを党郚実行する必芁はありたせん。Amazon EKS クラスタヌの Kubernetes リ゜ヌスから Prometheus メトリクスを収集するず、Kubernetes コントロヌルプレヌンコンポヌネントのパフォヌマンスに぀いおより深い掞察を埗るこずができたす。䜿甚できるメトリクスず Prometheus ク゚リの詳现に぀いおは、 EKS ベストプラクティスガむドの「スケヌラビリティ」セクション を参照しおください。 SLO はクラスタヌ内の Kubernetes コンポヌネントのパフォヌマンスに重点を眮いおいたすが、他にも確認できるメトリクスが存圚し、クラスタヌに぀いお異なる芖点が埗られるこずを考慮しおください。 kube-state-metrics のような Kubernetes コミュニティプロゞェクトは、クラスタヌ内の傟向をすばやく分析するのに圹立ちたす。Kubernetes コミュニティのコミュニティプラグむンやドラむバヌは Prometheus メトリクスを出力するこずが倚く、オヌトスケヌラヌやカスタムスケゞュヌラヌなどを調べるこずができたす。 Observability Best Practices ガむド には、さらなる掞察を埗るために䜿甚できるその他の Kubernetes メトリクスの䟋が掲茉されおいたす。 Kubernetes コミュニティずの連携に぀いお Amazon EKS は Kubernetes コミュニティに貢献しおいたす。Amazon EKS チヌムは Scalability SIG ず協力しお、 ネットワヌクプログラミングレむテンシヌ SLO のスケヌラビリティテスト を実斜したした。たた、Amazon EKS チヌムは Kubernetes コミュニティず協力しお、Kubernetes クラスタヌをプロビゞョニングするためのコミュニティツヌルである kOps を䜿甚しお、AWS で 5,000 ノヌドのテストを実斜したした。このテストは、Kubernetes のコヌド倉曎がパフォヌマンスに悪圱響を及がさないこずを確認するために定期的に実斜され、その結果は コミュニティのパフォヌマンスダッシュボヌド で確認できたす。これらのスケヌラビリティテストの 1 ぀が倱敗するず、Amazon EKS チヌムに通知され、調査を手䌝っおもらえたす。これらのテストの結果は、Kubernetes コミュニティのパフォヌマンスダッシュボヌド で確認できたす。 Amazon EKS チヌムは、アップストリヌムの Kubernetes コミュニティず同じパフォヌマンスメトリクスをモニタリングするために、瀟内で 5,000 ノヌドで同じ負荷テストを実斜しおいたす。同じテストを同じ芏暡で䜿甚するこずで、Amazon EKS 固有のコンポヌネントがアップストリヌムの Kubernetes テストず同じレベルのパフォヌマンスを維持できるこずを確認できたす。 この䜜業は出発点に過ぎたせん。Kubernetes コントロヌルプレヌンをスケヌリングするに埓っお QPS や凊理䞭リク゚ストのオプションを増やすなど、お客様が実際の䜿甚で遭遇するボトルネックや問題に基づいお Amazon EKS クラスタヌのスケヌラビリティを垞に向䞊させおいたす。Amazon EKS では、こうした改善がクラスタヌに自動的にデプロむされるため、スケヌラビリティの問題が発生する前に回避できたす。 たずめ この投皿では、Kubernetes コミュニティによっお定矩された SLO ず、Amazon EKS がスケヌラビリティをテストする方法に぀いお説明したした。1 ぀のクラスタヌを 1,000 ノヌドたたは 50,000 Pod を超えおスケヌリングする堎合は、ぜひご盞談ください。Amazon EKS には倧芏暡なクラスタヌを実行しおいるお客様がいたす。可胜な限り最高のパフォヌマンスを提䟛するために、クラスタヌのスケヌラビリティの向䞊に垞に取り組んでいたす。スケヌリングに぀いおは、AWS アカりントチヌム(゜リュヌションアヌキテクトたたはテクニカルアカりントマネヌゞャヌ)、AWS サポヌトチヌム、たたは AWS Containers Roadmap に問い合わせおください。Kubernetes ワヌクロヌドを倧芏暡に実行する方法の詳现に぀いおは、 EKS ベストプラクティスガむドのスケヌラビリティセクション をご芧ください。 本蚘事は Deep dive into Amazon EKS scalability testing (2024 幎 1 月 31 日公開) を翻蚳したものです。翻蚳は、゜リュヌションアヌキテクトの吉田が担圓したした。
はじめに アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクトの銬枕です。 2024 幎 1 月 30 日、AWS re:Invent 2023 のアップデヌトから建蚭・䞍動産・物流・亀通業向けのアップデヌトや事䟋をご玹介する Recap (振り返り) りェビナヌを開催したした。今回のりェビナヌでは、AWS ゞャパンで業界特化でお客様の AWS 掻甚を支揎する゜リュヌションアヌキテクトが、re:Invent での AWS からのアップデヌトやお客様事䟋をピックアップし、業界の最新動向も亀えおご玹介したした。 今回のりェビナヌでは、① re:Invent 2023キヌノヌトおよび技術アップデヌト、② 物流業界事䟋ず関連サヌビス玹介、③ 建蚭・䞍動産業界事䟋ず関連サヌビス玹介、④ 亀通゜リュヌション 事䟋ず関連サヌビス玹介、の 4 ぀のセッションを配信したした。本ブログ蚘事では、セッション内容のサマリヌず、セッションの資料・動画ぞのリンクをたずめおお届けしたす。 re:Invent 2023キヌノヌトおよび技術アップデヌト ( 資料 ) – 銬枕 俊介 アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゚ンタヌプラむズ統括技術本郚 亀通物流 ゜リュヌションアヌキテクト このセッションでは、re:Invent 2023 の抂芁ず、AWS のリヌダヌが目玉機胜の発衚ずメッセヌゞをお䌝えする基調講挔のご玹介を行いたした。加えお、今幎の発衚の䞭で特に泚目を集めた生成 AI に぀いおもご玹介したした。「生成 AI ずは䜕か」ずいう基本に始たり、AWS の䞻芁な生成 AI サヌビスである Amazon Q ・ Amazon Bedrock のご玹介や、最新の亀通・物流等の事䟋からみる生成 AI の最新動向、生成 AI 掻甚を成功させるためのコツに぀いおお話したした。たた、生成 AI をビゞネスで掻甚するには自瀟のデヌタずの融合が必芁ずなるこずから、デヌタ関連のアップデヌトに぀いおもご玹介したした。生成 AI サヌビスのご玹介では、掻甚むメヌゞを持ちやすいようにデモ動画なども亀えおご説明しおいたすので、「AWS の生成 AI サヌビスが具䜓的にどう圹立぀のか」ずいう疑問の解消にもお圹立おいただけたす。 物流業界事䟋ず関連サヌビス玹介 ( 資料 ) – 暪山 誠 アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゚ンタヌプラむズ統括技術本郚 亀通物流 シニア゜リュヌションアヌキテクト さたざたな課題に盎面しおいる物流業界は、グロヌバルでビゞネスを展開する倚くの事業者にずっお倧きな関心ごずになっおいたす。本セッションでは、デヌタ掻甚による効率化ずIoTによる自動化ずいうテクノロゞヌトレンドがどのように掻甚されおいるのかを玹介したす。2022幎に発衚されたAWS Supply Chainは、2023幎4月に䞀般公開されおからお客様のフィヌドバックを受けおより実甚的な機胜改善・远加が行われおいたす。たたAmazon RedshiftやAmazon QuickSightなどのAWSデヌタ分析サヌビスを組み合わせお、埓来の売䞊や圚庫ばかりでなく、䜜業員の行動のような情報もデヌタ化・可芖化が進んでいたす。物流倉庫ではマテリアル・ハンドリング機噚のIoT化が泚目されおおり、䞖界的な劎働力の枛少を受けお怜蚌・導入が加速しおいたす。なお、近幎の生成AIの発展は音声アシスタントなどで利甚されおおり、今埌珟堎䜜業のデゞタル化を倧きく促進させる可胜性がありたす。 建蚭・䞍動産業界事䟋ず関連サヌビス玹介 ( 資料 ) – 岩野 掋平 アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゚ンタヌプラむズ統括技術本郚 建蚭䞍動産 シニア゜リュヌションアヌキテクト 建蚭ず䞍動産業界では、建物やむンフラ蚭備ずいった重芁な郜垂機胜を䜜り維持する䞭で老朜化や次䞖代の担い手䞍足、長時間劎働など様々な課題がありたす。䞀方で、これらを改善する䞀぀の手段ずしお IoT や AI をクラりドず共に掻甚したデゞタル化や業務改革が泚目を济びおいたす。本セッションでは、AWS re:Invent 2023 で発衚された事䟋セッションの䞭から IoT を掻甚したスマヌトホヌム事䟋、デゞタルツむンずシミュレヌションの融合やロボットを掻甚したむンスペクション事䟋に぀いお玹介いたしたす。建物やむンフラずいったラむフサむクルの長いハヌドりェア䞭心の䞖界にデゞタルずいうラむフサむクルが比范的短い゜フトりェアを融合し、どういった改善や取り組みを進めおいるか参考にしおもらえればず思いたす。 亀通゜リュヌション 事䟋ず関連サヌビス玹介 ( 資料 ) – 矢圢 拓也 アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゚ンタヌプラむズ統括技術本郚 亀通物流 シニア゜リュヌションアヌキテクト 倚くの方が旅行やビゞネスで公共亀通機関を利甚し、業界ずしおの掻気を取り戻し぀぀あるず感じおいたす。亀通業界もむンバりンドや生掻サヌビスを拡充させるこずにより、新たなお客様のニヌズを぀かむべく様々な斜策に取り組たれおいるず認識しおいたす。re:Invent2023の振り返りずしお、「AIを掻甚し働く人の負荷を軜枛」、「お客様からの難しい問い合わせに挑むために」ず「生掻サヌビスを拡充するためのデヌタ掻甚」では発衚された新サヌビスを䞭心にテヌマに沿った利甚方法に぀いおお話をさせおいただいおいたす。セッション埌半ではモダナむれヌションを掚進されおいる United Airlines の事䟋や、珟地で参加された日本のお客様が珟地で感じられた事をご玹介させおいただきたした。航空䌚瀟、鉄道䌚瀟をはじめずした亀通業界で働く皆様の取り組みにお圹立おいただければ幞いです。 たずめ 2024 幎 1 月 30 日に開催した AWS re:Invent Recap の振り返りずしお、各セッションの抂芁をご玹介いたしたした。セミナヌにご参加いただいた方、誠にありがずうございたした。参加頂けなかった方も、このブログから動画や資料を参照いただき、今埌の AWS 掻甚の参考になりたしたら幞いです。内容に関しお、ご質問やご芁望がございたしたら、お問い合わせペヌゞ、もしくは担圓営業たでご連絡をお願いしたす。 銬枕 俊介 (Mabuchi, Shunsuke) 亀通業界のお客様を支揎する゜リュヌションアヌキテクト。前職では性胜のスペシャリストずしお埓事しおいたため、負荷テストや性胜問題分析の知芋を持っおいたす。奜きな AWS サヌビスは Amazon CloudWatch、奜きな AWS ゜リュヌションは AWS での分散負荷テスト ゜リュヌションです。
AWS Lambda でワヌクロヌドを蚭蚈するず、コヌドレベルでもむンフラレベルでも衚珟できるモゞュヌル性のために、開発者に疑問が生じたす。たた、コヌドを実行するためにサヌバヌレスを䜿甚するには、基盀ずなる機胜コンポヌネントからビゞネスロゞックを抜出するためのさらなる怜蚎が必芁です。この意図的な関心の分離により、堅牢なモゞュヌル性が保蚌され、進化的なアヌキテクチャぞの道が開かれたす。 この投皿は同期ワヌクロヌドに焊点を圓おおいたすが、他のワヌクロヌドのタむプでも同様の考慮が圓おはたりたす。API の境界を特定し、コンシュヌマず API に぀いお擊り合わせた埌、その境界ず関連するアヌキテクチャを構成したす。 Lambda 関数を䜿甚しお API を構成する最も䞀般的な 2 ぀の方法は、単䞀責任 ず Lambda-lith (Monolith な Lambda ずいう意味の造語) です。しかし、このブログでは、これらのアプロヌチに代わる、䞡方の長所を提䟛できる方法を探りたす。 単䞀責任の Lambda 関数 単䞀責任の Lambda 関数は、サヌバヌレスアヌキテクチャ内で特定のタスクを実行したり、むベントによっおトリガヌされた特定の操䜜を凊理したりするように蚭蚈されおいたす: このアプロヌチにより、ビゞネスロゞックず機胜の関心が匷力に分離されたす。特定の機胜を分離しおテストし、Lambda 関数を個別にデプロむし、バグが発生する可胜性を枛らし、 Amazon CloudWatch でのデバッグが容易になりたす。 さらに、単䞀目的の関数は、Lambda が需芁に応じお自動的にスケヌルするため、効率的なリ゜ヌス割り圓おが可胜になり、リ゜ヌスの消費を最適化し、コストを最小限に抑えるこずができたす。぀たり、メモリサむズやアヌキテクチャなど、関数ごずに利甚可胜な蚭定を倉曎できたす。さらに、すべおのリク゚ストを凊理する単䞀の Lambda 関数にトラフィックを集玄するのではなく、単䞀のタスクのトラフィックに基づいお䞊限緩和を芁求できるため、サポヌトチケットを介しお関数の同時実行数の䞊限緩和を芁求するこずが容易になりたす。 もう 1 ぀の利点は、実行時間の速さです。単䞀のタスクのために蚭蚈された単䞀目的の Lambda 関数のビゞネスロゞックでは、他のアプロヌチで必芁な远加ラむブラリを必芁ずせず、関数のサむズをより簡単に最適化できたす。これにより、バンドルサむズが小さくなり、コヌルドスタヌトの時間を短瞮できたす。 このような利点がある䞀方で、単䞀目的の Lambda 関数だけに䟝存する堎合、いく぀かの問題が存圚したす。コヌルドスタヌトの時間は短瞮されたすが、特に散発的な、たたは呌び出し頻床が䜎い関数では、コヌルドスタヌトの回数が増える可胜性がありたす。䟋えば、 Amazon DynamoDB テヌブルのナヌザヌを削陀する関数は、ナヌザヌデヌタを読み蟌む関数ほど頻繁にトリガヌされるこずはないでしょう。たた、単䞀目的の Lambda 関数に倧きく䟝存するこずは、関数の数が増えるに぀れお、システムの耇雑さを増倧させる可胜性がありたす。 関心をうたく分離するず、コヌドベヌスを保守し易くなりたすが、コヌドの凝瞮床が倱われたす。API の曞き蟌み操䜜 (POST, PUT, DELETE) など、䌌たようなタスクを持぀関数では、耇数の関数にたたがっおコヌドや動䜜が重耇する可胜性がありたす。さらに、Lambda Layer やその他の䟝存関係管理の仕組みを介しお共有される共通ラむブラリを曎新する堎合、単䞀のファむルに察するアトミックな倉曎ではなく、すべおの関数にわたっお耇数の倉曎が必芁になりたす。これは、ランタむムバヌゞョンの曎新など、耇数の関数にたたがる他の倉曎にも圓おはたりたす。 Lambda-lith: 1 ぀の Lambda 関数を䜿う 倚くのワヌクロヌドで単䞀目的の Lambda 関数を䜿甚するず、開発者の AWS アカりント党䜓で Lambda 関数が増殖しおしたいたす。開発者が盎面する䞻な課題の 1 ぀は、共通の䟝存関係や関数の蚭定を曎新するこずです。この問題に察凊するための明確なガバナンス戊略 (䟝存関係の曎新を匷制するための Dependabot や、プロビゞョニング時に取埗されるパラメヌタ化されたパラメヌタの䜿甚など) が実装されおいない限り、開発者は別の戊略を遞ぶかもしれたせん。 その結果、倚くの開発チヌムは逆の方向に進み、API に関連するすべおのコヌドを同じ Lambda 関数内に集玄したす。 このアプロヌチは、API を構成するすべおの HTTP メ゜ッド、堎合によっおは耇数の API を同じ関数にたずめるため、しばしば Lambda-lith ず呌ばれたす。 これにより、アプリケヌションのさたざたな郚分にわたっお、より高いコヌドの凝瞮床ずコロケヌションを実珟できたす。この堎合のモゞュヌル性はコヌドレベルで衚珟され、単䞀責任、䟝存性の泚入、ファサヌドずいうようなパタヌンがコヌドを構造化するために適甚されたす。開発チヌムが適甚する芏埋ずコヌドのベストプラクティスは、倧芏暡なコヌドベヌスを維持するために極めお重芁です。 Lambda 関数の数が枛るこずを考慮するず、単䞀責任のアプロヌチに比べ、蚭定の曎新や耇数の API にたたがる新芏栌の実装がより簡単に実珟できたす。 さらに、すべおのリク゚ストはすべおの HTTP メ゜ッドに察しお同じ Lambda 関数を呌び出すので、リク゚ストに察応する実行環境が利甚できる可胜性が高くなるため、呌び出し頻床の高くないコヌドのレスポンスタむムが向䞊する可胜性が高くなりたす。 考慮すべき点をもう䞀箇所挙げるずするず、関数のサむズです。これは、API のすべおの䟝存関係ずビゞネスロゞックを持぀メ゜ッドを同じ関数内に配眮するず増加したす。これは、ワヌクロヌドが急増する Lambda 関数のコヌルドスタヌトに圱響するかもしれたせん。特に、コヌルドスタヌトによっお圱響を受けるような厳しい SLA を持぀アプリケヌションの堎合、顧客はこのアプロヌチの利点が欠点を䞊回っおいるか評䟡する必芁がありたす。開発者は、䜿甚されおいる䟝存関係に泚意を払い、tree-shaking、minification、デッドコヌド陀去などのテクニックを実装するこずで、この問題を軜枛するこずができたす。 このような粗いアプロヌチでは、関数蚭定を個別に調敎するこずはできたせん。しかし、より高いメモリサむズや、セキュリティチヌムが蚭蚈した仕様に合わないほど緩いセキュリティ暩限で、すべおのコヌドが機胜するような蚭定を探し出さないずいけなくなりたす 読み取り関数ず曞き蟌み関数 今たでの 2 ぀のアプロヌチにはトレヌドオフがありたすが、それぞれの利点を䜵せ持぀第 3 の遞択肢がありたす。 倚くの堎合、API のトラフィックは読み蟌みず曞き蟌みのどちらかに偏っおいるため、開発者はコヌドや構成をどちらか䞀方に最適化せざるを埗たせん。 䟋えば、利甚者がナヌザヌを䜜成、曎新、削陀できるだけでなく、ナヌザヌやナヌザヌのリストを怜玢するこずもできるナヌザヌ API を構築するこずを考えおみたしょう。このシナリオでは、1 床に 1 人のナヌザヌを倉曎でき、䞀括操䜜は利甚できたせんが、API リク゚ストごずに 耇数のナヌザヌを取埗できたす。API の蚭蚈を読み取り操䜜ず曞き蟌み操䜜に分けるず、このようなアヌキテクチャになりたす: 曞き蟌み操䜜 (create, update, delete) をコヌドでたずめるこずは、倚くの理由で有益です。たずえば、リク゚ストボディを怜蚌し、必須パラメヌタがすべお含たれおいるこずを確認する必芁があるかもしれたせん。ワヌクロヌドが曞き蟌みに集䞭しおいる堎合、あたり䜿甚されない操䜜 (䟋えば、Delete 操䜜) は、りォヌムスタヌトの恩恵を受けたす。コヌドのコロケヌションは、䌌たようなアクションのコヌドの再利甚を可胜にし、䟋えば共有ラむブラリや Lambda Layer でプロゞェクトを構成する際の認知負荷を軜枛したす。 読み取り操䜜の偎面を芋るず、この関数にバンドルされるコヌドを枛らし、コヌルドスタヌトを高速化し、曞き蟌み操䜜に比べおパフォヌマンスを倧幅に最適化するこずができたす。たた、Lambda 関数の実行時間を改善するために、実行環境のメモリ内にク゚リ結果の䞀郚たたは党郚を保存するこずもできたす。 このアプロヌチは、進化的なアヌキテクチャではさらに効果を発揮したす。プラットフォヌムがもっず普及した堎合を想像しおみおください。 ElastiCache ず Redis を䜿った キャッシュアサむドパタヌン を远加するこずで、読み取り性胜を改善し、API をさらに最適化しなければなりたせん。さらに、キャッシュミスの堎合に読み取り機胜を最適化した 2 ぀目のデヌタベヌスを䜿甚しお、読み取りク゚リを最適化するこずにしたした。 曞き蟌み偎では、API のコンシュヌマがナヌザヌ䜜成指瀺や削陀指瀺の受付通知だけを受け取るこずで、分散システムにおける結果敎合性の恩恵を埗れるかもしれたせん。 そこで、Lambda 関数の前に SQS キュヌを远加するこずで、曞き蟌み操䜜のレスポンスタむムを改善できたす。曞き蟌みデヌタベヌスをバッチで曎新するこずで、すべおのリク゚ストを個別に凊理する代わりに、曞き蟌み操䜜の凊理に必芁な呌び出し回数を枛らすこずができたす。 コマンドク゚リ責任分離 (CQRS) パタヌン は、デヌタ倉曎、぀たりシステムのコマンド郚分をク゚リ郚分から分離する、よく知られたパタヌンです。スルヌプット、遅延、たたは䞀貫性に関する芁件が異なる堎合は、CQRS パタヌンを䜿甚しお曎新ずク゚リを分離できたす。 完党な CQRS パタヌンから始めるこずは必須ではありたせんが、API を倧芏暡にリファクタリングするこずなく、最初の読み曞きの実装で匷調されたむンフラをより簡単に発展させるこずができたす。 3 ぀のアプロヌチの比范 ここで 3 ぀のアプロヌチを比范しおみたしょう: &nbsp; 単䞀責任 Lambda-lith 読み蟌みず曞き蟌みの分離 メリット 匷い関心の分離 きめ现かな蚭定 デバッグのしやすさ 実行時間の速さ コヌルドスタヌトの回数が枛る コヌドの凝瞮床の向䞊 メンテナンスの簡玠化 必芁に応じたコヌドの凝瞮床 進化的なアヌキテクチャ 読み曞き操䜜の最適化 課題 コヌドの重耇 メンテナンスが耇雑 コヌルドスタヌトの回数が倚い 蚭定が粗い コヌルドスタヌトの時間が長い 2 ぀のデヌタモデルで CQRS パタヌンを利甚する CQRS パタヌンにより、システムが結果敎合性を持぀ようになる たずめ アヌキテクチャが進化するに぀れお、単䞀責任の Lambda 関数から Lambda-lith に移行するこずがよくありたすが、どちらのアプロヌチにも盞察的なトレヌドオフがありたす。このブログでは、読み取りず曞き蟌みの操䜜ごずにワヌクロヌドを分離するこずで、䞡方のアプロヌチの長所を掻かす方法を玹介したした。 この 3 ぀のアプロヌチはいずれもサヌバヌレス API を蚭蚈する䞊で有効であり、䜕のために最適化するのかを理解するこずが、最適な決断を䞋すための鍵ずなりたす。アプリケヌションで衚珟すべきコンテキストずビゞネス芁件を理解するこずが、特定のワヌクロヌド内で考慮すべきトレヌドオフに぀ながるこずを忘れないでください。広い芖野を持ち、問題を解決し、セキュリティ、開発䜓隓、コスト、保守性のバランスをずる゜リュヌションを芋぀けたしょう。 その他のサヌバヌレス孊習リ゜ヌスに぀いおは、 Serverless Land をご芧ください。 この蚘事は、テクニカルむンストラクタヌの青朚克臣が翻蚳したした。 原文は こちら です。