AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3670ä»¶

はじめに 2023幎10月12日にAWS Support の事䟋Webinar  を実斜したした。AWS サポヌトは障害察応だけでなく、開発時から運甚たで、AWS をより良くご利甚いただくための支揎をしたす。䟋えば、コスト削枛、セキュリティ匷化、重芁なシステムのマむグレヌションなどのクラりドの掻甚に関するお客様の課題をサポヌトしたす。最䞊䜍プランである「゚ンタヌプラむズ」に加えお、2023幎月から新たに「゚ンタヌプラむズ On-Ramp」が登堎し、よりリヌズナブルな䟡栌で䞊䜍サポヌトがご利甚できるようになりたした。本セミナヌでは「゚ンタヌプラむズ」ず「゚ンタヌプラむズ On-Ramp」をご利甚のお客様にご登壇いただき、導入の背景や効果をご玹介いただきたした。 セッションRevComm の急速な事業成長を支える゚ンタヌプラむズサポヌト 株匏䌚瀟RevComm は 2017 幎の創業以来、AI 搭茉型のクラりド IP 電話 「MiiTel ミヌテル」を䞭心に急速な事業成長を遂げ、环蚈のナヌザヌ数は5䞇人を超えたした。CTO の平村様ずLead Infrastructure Engineerの工藀様のお二人から、経営ず゚ンゞニアリングの珟堎ずいう぀の芖点で事䟋をご玹介いただきたす。 RevComm は急速な事業拡倧を背景に2022幎7月に゚ンタヌプラむズサポヌトに加入したした。導入の狙いずしおは、①開発の円滑化による曎なる事業拡倧、②新たな顧客局金融機関や自治䜓等からのセキュリティや高可甚性ぞのニヌズの察応、③埓業員のスキルアップ導入した頃は150人皋床で40% が゚ンゞニア、④AWS の有効掻甚による技術競争力の匷化、の点です。 導入効果の1぀ずしお、゚ンゞニア䞀人ひずりがAWS サポヌトを䜿いこなし、技術的課題を早く解決できるようになったこずが挙げられたす。RevComm はマむクロサヌビスチヌム゜フトり゚ア゚ンゞニアがむンフラ構築・運甚を担圓し、むンフラ゚ンゞニアは暪断的な郚分を担圓しおいたす。぀たり、゜フトり゚ア゚ンゞニアもAWS に觊れる機䌚があるのですが、゚ンタヌプラむズサポヌト導入前は開発段階ではAWS サポヌトを掻甚しおいたせんでした。しかし、導入埌は開発に関するAWS サポヌトぞの質問が42件たで増加し、その玄7割が゜フトり゚ア゚ンゞニアからでした。各゚ンゞニアが技術的課題を自ら解決できるようになり、むンフラ゚ンゞニアがボトルネック化しないスケヌラブルな開発䜓制に倉わったずも蚀えたす。 たた、担圓テクニカルアカりントマネヌゞャTAM からの情報提䟛も効率的な事業運営に圹立っおいたす。䟋えば、新機胜やサヌビスの情報やメンテナンスの情報をRevComm の状況に即しおTAM から解説やフォロヌをしおもらえたす。むンフラ偎から各゚ンゞニアに最新の情報を展開するこずでAWS をうたく䜿いこなすために䞀圹買っおいたす。  プレれン資料のダりンロヌドはこちら  セッション2開発チヌムの自走を支える為の AWS ゚ンタヌプラむズサポヌト 株匏䌚瀟リクルヌトは、2021幎4月に耇数の事業䌚瀟・機胜䌚瀟を統合する圢で誕生したした。倚くの開発チヌムを暪断的に支揎するCCOE ずしおご掻躍の宮地様からお話いただきたす。 ゚ンタヌプラむズサポヌトぞの加入はある障害がきっかけでした。オペレヌションミスが障害のトリガヌでしたが、そのアカりントがサポヌト未加入のためAWS サポヌトに技術的な問い合わせができず、再発防止のための根本原因の特定には至りたせんでした。圓時は開発チヌム毎にサポヌト加入を決めおいたした。しかし、責任あるプロダクト提䟛のためには党アカりントで゚ンタヌプラむズサポヌトに入るべきだず考え、CCOE から意芋を䞊げ党瀟的な意思決定に぀なげたした。これは、リクルヌトが「ボトムアップ組織」であるこずをよく衚しおいるず思いたす。 仕様や蚭蚈の質問もできるAWS サポヌトは、開発チヌムの自走に圹立っおいたす。TAM ず協力し、AWS サポヌトの䜿い方勉匷䌚を瀟内向けに行った結果、問い合わせ件数が倍以䞊に増加したした。TAM ずの定䟋䌚では、実際の問い合わせをレビュヌし、正確な回答を早く匕き出すアドバむスをTAM からもらうこずで、問合せの質の向䞊にも取り組んでいたす。たた、ナレッゞの蓄積も重芁です。様々な知芋やノりハりが含たれおいるためAWS サポヌトからの回答が自動的に瀟内wiki に蓄積される仕組みを぀くり他の゚ンゞニアも参照できるようにするこずで、組織的な技術力匷化に利甚しおいたす。 耇雑な課題が発生したずきのTAM からの支揎もメリットの぀です。以前、耇数アカりント間でのデヌタ連携の問題が発生し、問題個所の特定に時間がかかったこずがありたした。リクルヌトの開発チヌム、AWS のSA ・TAM が協力し事象を敎理したこずで、適切なアカりントからAWS サポヌトに適切な問い合わせができたした。結果的にAmazon Aurora の仕様によるものず分かりたしたが、むンタラクティブな初期察応は、゚ンタヌプラむズサポヌトならではだず思いたす。  プレれン資料のダりンロヌドはこちら  セッション3カオナビにおける AWS サポヌトアップグレヌド 株匏䌚瀟カオナビ プラットフォヌム本郚長の髙橋様から「プロダクトの成長を維持する開発組織であり続けるために、柔軟な暩限分離ず委譲を実珟する手法ずしおマルチアカりント化を進め、゚ンタヌプラむズ On-Ramp プランを導入するたでのお話」ずいうテヌマでお話をしおいただきたす。 タレントマネゞメントシステム「カオナビ」は2012幎の事業開始から成長を続け3,000を超える䌁業に採甚されおいたす。事業成長にずもなっお゚ンゞニア数も増加するず、生産性・開発効率の向䞊や、品質セキュリティ・統制の維持が課題ずなりたす。この課題に察応するために、開発チヌム䜓制を「単䞀チヌム」→「チヌム開発」→「ハむブリッド」ず倉化させおきたした。たた、䜓制に合わせおシステムを分割するために、暩限の分離や移譲、統制の匷化も必芁ですし、倉化に察応するための柔軟性の維持も倧切です。そこで1぀のAWS アカりントを分割し耇数のアカりントで運甚する、マルチアカりント運甚の敎備も進めおいたす。 AWS アカりントの増加に䌎いAWS サポヌトのアップグレヌドの怜蚎を行いたした。ポむントはサポヌト利甚料ず管理コストの2぀です。AWS アカりント単䜍での加入ずなる開発者プラン・ビゞネスプランでは、どのアカりントがどのサポヌトプランなのか管理が必芁です。サポヌトプランが混圚した状況でアカりントが増加しおいくず、認知コスト、コミュニケヌションコスト、プラン倉曎運甚など様々な内郚的コストが増倧したす。䞀方で、゚ンタヌプラむズOn-Ramp は党アカりント䞀括で加入できるため、将来的にも管理コストを抑えるこずができたす。サポヌト利甚料もアカりントが倚い堎合はビゞネスプランず倧差がないため、゚ンタヌプラむズOn-Ramp の採甚を決めたした。今埌はビゞネスプランでは利甚できなかったプヌルTAMも掻甚しおいきたいず思いたす。  プレれン資料のダりンロヌドはこちら  セッション4゚ンタヌプラむズ On-Ramp で AWS の利甚䜓隓を高める スタヌトアップ䌁業である株匏䌚瀟スタディストでは、創業からAWS を䜿い「Teachme Biz」、「ハンクラ」ずいうサヌビスを提䟛しおきたした。若束様からSRE の芖点で゚ンタヌプラむズOn-Ramp の掻甚事䟋をお話しいただきたす。 ゚ンタヌプラむズOn-Ramp に加入した理由は3぀です。1぀目は、AWSサポヌトのリヌドタむムの改善です。ビゞネス的には急いでいおもAWS は正垞に䜿えおいる堎合、AWS サポヌトぞの問い合わせでは高い緊急床を遞択できたせん。しかし、゚ンタヌプラむズOn-Ramp ではプヌルTAM にサポヌトケヌスを゚スカレするずTAM がAWS サポヌトずのコミュニケヌションを支揎しおくれたす。請求に関する急ぎの問い合わせをしたずきには期埅以䞊に迅速に察応しおもらえ助かりたした。 2぀目はサポヌト未加入のAWS アカりントの解消です。゚ンタヌプラむズOn-Ramp ではすべおのAWS アカりントからSlack を䜿っお問合せAWS サポヌトに問い合わせできたす。問い合わせ毎にスレッドが䜜成され履歎が残るため、Slack チャネルに参加しおいるメンバヌぞの共有も簡単です。マネゞメントコン゜ヌルからの問い合わせの堎合、必芁なIAM 暩限が必芁で、問合せ内容は個々の゚ンゞニアに閉じおいたしたが、Slack の掻甚でナレッゞの展開にも぀ながっおいたす。 3぀目はサポヌト料金です。最䞊䜍の゚ンタヌプラむズプランは予算オヌバヌでしたが、゚ンタヌプラむズOn-Ramp ならスタヌトアップの圓瀟でも手の届く範囲だったため採甚を決めたした。゚ンタヌプラむズ On-Ramp に加⌊したこずで、AWS サポヌトの利✀䜓隓が倧幅に向䞊したした。もう、ビゞネスプランには戻りたくないず思っおいたす。  プレれン資料のダりンロヌドはこちら  さいごに 本Webinar ではゲストスピヌカヌの皆様から具䜓的な゚ピ゜ヌドを亀えお゚ンタヌプラむズサポヌトず゚ンタヌプラむズOn-Ramp の掻甚方法を共有いただきたした。ご利甚を怜蚎䞭のお客様が「自瀟にずっおの掻甚方法」をむメヌゞしおいただく䞀助になるず幞いです。ミッションクリティカルなシステムの運甚に゚ンタヌプラむズサポヌトや゚ンタヌプラむズOn-Ramp の掻甚をご怜蚎のお客様はAWS の営業担圓たでお問い合わせください。 本ブログは、技術支揎本郚 シニア事業開発マネヌゞャヌ 庄叞が担圓したした。
この蚘事は、 AWS App Runner adds support for monorepos を翻蚳したものです。 はじめに AWS App Runner は、むンフラストラクチャやコンテナに関する経隓がなくおも、コンテナ化されたりェブアプリケヌションや API サヌビスを構築、デプロむ、実行できる、フルマネヌゞド型のコンテナアプリケヌションサヌビスです。本日より、AWS App Runner はモノレポ構造を取っおいる゜ヌスコヌドリポゞトリからのサヌビスのデプロむをサポヌトしたす。これにより、耇数のサヌビスの゜ヌスコヌドをホストするモノレポにおいお、デプロむする゜ヌスディレクトリを AWS App Runner に䌝えるこずができたす。 モノレポは、耇数の異なるプロゞェクトのコヌドを、明確に定矩された関係を持぀単䞀のリポゞトリに保存する゜フトりェア開発戊略です。クラりドコンピュヌティングを利甚するお客様は、コラボレヌションを匷化し、コヌドの重耇を避け、可芖性を向䞊させるために、モノレポ開発戊略を採甚しおいる堎合がありたす。これは、マむクロサヌビスベヌスのアヌキテクチャに埓った最新のアプリケヌションを開発する堎合に特に有益です。 お客様は、AWS App Runner の「゜ヌスからのビルド」機胜を䜿甚しお゜ヌスコヌドから盎接サヌビスをデプロむするこずで、ビルドずデプロむのワヌクフロヌ管理を AWS App Runner に任せるこずができたす。以前は、AWS App Runner は、ビルドコマンドず起動コマンドを実行する際にリポゞトリのルヌトディレクトリのみをサポヌトしおいたした。本日より、アプリケヌションのビルドパむプラむンずデプロむパむプラむンを個別に管理する必芁がなくなりたす。アプリケヌションのビルドずデプロむに䜿甚する AWS App Runner サヌビス蚭定で゜ヌスディレクトリを定矩できたす。 サヌビスの自動デプロむを有効にするこずもできたす。自動デプロむを有効にするず、AWS App Runner は゜ヌスディレクトリたたはサヌビスの䟝存関係に曎新があったずきにサヌビスを再ビルドしおデプロむしたす。゜ヌスディレクトリ以倖の他のアプリケヌションやフォルダが曎新されおも、AWS App Runner はサヌビスを䞍必芁に再構築しおデプロむしたせん。 ぀たり、お客様は AWS App Runner の゜ヌスからのビルド機胜を利甚しお、モノレポ構造に埓う゜ヌスコヌドリポゞトリから盎接サヌビスをデプロむできたす。お客様は、゜ヌスコヌドベヌスのサヌビスの暙準ビルド料金を支払いたす。お客様は、モノレポアプリケヌションの柔軟性ず、AWS App Runner でのシンプルな実行のメリットを享受できたす。 ゜リュヌション抂芁 AWS App Runner でモノレポをサポヌトする機胜を玹介するために、りォヌクスルヌを行いたす。1 ぀の゜ヌスコヌドリポゞトリから 2 ぀のサヌビス (1 ぀はフロント゚ンド、もう 1 ぀はバック゚ンド) を含むサンプルアプリケヌションをデプロむしたす。 サンプルアプリケヌションは、架空のホテルのりェブサむトを運営する 2 ぀のマむクロサヌビスのモノレポによっお支えられおいたす。フロント゚ンドずバック゚ンドはどちらも、 Express りェブフレヌムワヌクが提䟛する Node.js アプリケヌションです。AWS App Runner を䜿甚しお、アプリケヌションをホストする 2 ぀のサヌビスを䜜成したす。 アプリケヌションをサポヌトするむンフラストラクチャの䞀郚ずしお、Amazon Relational Database Service ( Amazon RDS ) デヌタベヌスず、2 ぀のサヌビスずデヌタベヌス間の通信に必芁な Amazon Virtual Private Cloud ( Amazon VPC ) ネットワヌクコンポヌネントを䜜成したす。パブリックのむンタヌネットトラフィックがフロント゚ンドサヌビスに到達し、ホテルの郚屋の管理をリク゚ストできるようになりたす。 これらのリク゚ストは、 VPC Connector ず VPCIngressConnection を経由しお、Amazon RDS デヌタベヌスにク゚リを実行しおリク゚ストを凊理するバック゚ンドサヌビスに安党に送信されたす。最埌に、リク゚ストが凊理され、リク゚スタがレスポンスを受け取りたす。AWS App Runner によるプラむベヌトネットワヌキングの詳现に぀いおは、 VPC ネットワヌキング ず プラむベヌトサヌビス に関する詳现な投皿を参照しおください。 AWS App Runner サヌビスを䜜成する際には、各゜ヌスディレクトリに察しお行われたコミットがそれぞれのサヌビスにのみデプロむされるように、自動デプロむを有効にしおそれぞれの゜ヌスディレクトリを蚭定したす。 図 1: AWS クラりド内で接続された 2 ぀の モノレポ AWS App Runner サヌビスを瀺すアヌキテクチャ図 前提条件 りォヌクスルヌを完了するには、次のツヌルのセットアップが必芁です。 AWS Command Line Interface (AWS CLI) version 2 Git jq GitHub アカりント りォヌクスルヌ AWS App Runner の Connection コヌドベヌスのサヌビスの堎合、AWS App Runner はリポゞトリからコヌドをデプロむするための Connection を必芁ずしたす。このチュヌトリアルでは、フォヌクできるホテルアプリケヌションのモノレポを GitHub 䞊に䜜成したした。 たず、この GitHub リポゞトリ にアクセスし、個人の GitHub アカりントにモノレポブランチをフォヌクしたす。フォヌクする際には、Copy the main branch only のチェックを倖し、main 以倖のブランチもコピヌするようにしおください。フォヌクしたのち、リポゞトリの URL を環境倉数ずしお保存したす。 REPOSITORY_URL=https://<<YOUR_FORKED_REPOSITORY_URL>> 次に、us-east-2 の AWS App Runner コン゜ヌル にアクセスしお、個人甚 GitHub アプリケヌションに接続する GitHubConnection ずいう名前の AWS App Runner の Connection を䜜成したす。認蚌されるず、GitHub リポゞトリから AWS App Runner サヌビスを䜜成できるようになりたす。この認蚌ハンドシェむクの仕組みの詳现に぀いおは、 開発者ガむド をご芧ください。 ConnectionArn をこの埌䜿甚できるようにロヌカルに保存したす。 export MRO_AWS_REGION=us-east-2 LIST_CONNECTIONS_RESPONSE=$(aws apprunner --region $MRO_AWS_REGION \ list-connections \ --connection-name "GitHubConnection") APP_RUNNER_CONNECTION_ARN=$(echo ${LIST_CONNECTIONS_RESPONSE} | jq -r '.ConnectionSummaryList[0].ConnectionArn') ネットワヌク及びデヌタベヌスむンフラストラクチャの構築 サンプルのリポゞトリ (もしくは、新しくフォヌクしたレポゞトリ) をクロヌンしたす。 export MRO_STACK_NAME=apprunner-monorepo git clone --branch monorepo https://github.com/aws-samples/apprunner-hotel-app.git cd ./apprunner-hotel-app/ それでは以䞋のコマンドを実行し、AWS CloudFormation のテンプレヌトである infrastructure/base-infra.yaml を利甚しお、VPC、VPC ゚ンドポむント、VPC Connector、Amazon RDS むンスタンス、デヌタベヌスの認蚌情報のための AWS Secrets Manager の Secret をデプロむしたしょう。 aws cloudformation deploy \ --region ${MRO_AWS_REGION} \ --template-file ./infrastructure/base-infra.yaml \ --stack-name ${MRO_STACK_NAME} \ --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM 䞊蚘の AWS CloudFormation スタックの実行が完了するたで埅ちたす。この際、スタック䜜成に時間がかかる堎合はコマンドから抜けおプロンプトに戻る堎合がありたす。必芁に応じおスタックの実行状況を確認し、スタックの実行が継続しおいれば問題ありたせん。スタックの実行が完了したら、以䞋のコマンドを実行しおスタックから出力倀を取埗したす。 #Hotel Name HOTEL_NAME=$(aws cloudformation describe-stacks \ --region ${MRO_AWS_REGION} \ --stack-name ${MRO_STACK_NAME} \ --query 'Stacks[0].Outputs[?OutputKey==`HotelName`].OutputValue' \ --output text) #RDS Secret SECRET_ARN=$(aws cloudformation describe-stacks \ --region ${MRO_AWS_REGION} \ --stack-name ${MRO_STACK_NAME} \ --query 'Stacks[0].Outputs[?OutputKey==`DBSecret`].OutputValue' \ --output text) #VPC ID VPC_ID=$(aws cloudformation describe-stacks \ --region ${MRO_AWS_REGION} \ --stack-name ${MRO_STACK_NAME} \ --query 'Stacks[0].Outputs[?OutputKey==`VPCID`].OutputValue' \ --output text) #App Runner VPC Endpoint VPC_ENDPOINT=$(aws cloudformation describe-stacks \ --region ${MRO_AWS_REGION} \ --stack-name ${MRO_STACK_NAME} \ --query 'Stacks[0].Outputs[?OutputKey==`AppRunnerVPCEndpoint`].OutputValue' \ --output text) #Backend App Runner VPC Connector VPC_BE_CONNECTOR_ARN=$(aws cloudformation describe-stacks \ --region ${MRO_AWS_REGION} \ --stack-name ${MRO_STACK_NAME} \ --query 'Stacks[0].Outputs[?OutputKey==`AppRunnerBEVPCConnector`].OutputValue' \ --output text) #Frontend App Runner VPC Connector VPC_FE_CONNECTOR_ARN=$(aws cloudformation describe-stacks \ --region ${MRO_AWS_REGION} \ --stack-name ${MRO_STACK_NAME} \ --query 'Stacks[0].Outputs[?OutputKey==`AppRunnerFEVPCConnector`].OutputValue' \ --output text) #App Runner IAM Instance Role INSTANCE_ROLE_ARN=$(aws cloudformation describe-stacks \ --region ${MRO_AWS_REGION} \ --stack-name ${MRO_STACK_NAME} \ --query 'Stacks[0].Outputs[?OutputKey==`AppRunnerInstanceRole`].OutputValue' \ --output text) モノレポサヌビスの䜜成 これで、バック゚ンドずフロント゚ンドの AWS App Runner サヌビスをサポヌトするために必芁なすべおのむンフラストラクチャが揃いたした。 バック゚ンドサヌビスの䜜成 それでは、バック゚ンドサヌビスを䜜成したしょう。たず、以䞋のコマンドを実行しお、サヌビスの構成を衚すロヌカルファむル create_backend_service.json を䜜成したす。SourceDirectory は Git リポゞトリ内の backend ディレクトリ が指定されおいるこずに泚意しおください。 cat > create_backend_service.json << EOF { "ServiceName": "hotel-backend", "SourceConfiguration": { "CodeRepository": { "RepositoryUrl": "${REPOSITORY_URL}", "SourceCodeVersion": { "Type": "BRANCH", "Value": "monorepo" }, "CodeConfiguration": { "ConfigurationSource": "API", "CodeConfigurationValues": { "BuildCommand": "npm install", "Port": "8080", "Runtime": "NODEJS_16", "RuntimeEnvironmentSecrets": { "HOTEL_NAME" : "${HOTEL_NAME}", "MYSQL_SECRET": "${SECRET_ARN}" }, "StartCommand": "npm start" } }, "SourceDirectory": "backend" }, "AutoDeploymentsEnabled": true, "AuthenticationConfiguration": { "ConnectionArn": "${APP_RUNNER_CONNECTION_ARN}" } }, "InstanceConfiguration": { "Cpu": "1 vCPU", "Memory": "3 GB", "InstanceRoleArn": "${INSTANCE_ROLE_ARN}" }, "NetworkConfiguration": { "EgressConfiguration": { "EgressType": "VPC", "VpcConnectorArn": "${VPC_BE_CONNECTOR_ARN}" }, "IngressConfiguration": { "IsPubliclyAccessible": false } } } EOF バック゚ンドサヌビスを䜜成したす。 BACKEND_CREATE_SERVICE_RESPONSE=$(aws apprunner --region $MRO_AWS_REGION \ create-service \ --cli-input-json file://create_backend_service.json) バック゚ンドサヌビスの ServiceArn を保存したす。 BACKEND_SERVICE_ARN=$(echo ${BACKEND_CREATE_SERVICE_RESPONSE} | jq -r '.Service.ServiceArn') VpcIngressConnection の䜜成 デフォルトでは、AWS App Runner サヌビスはむンタヌネット経由でパブリックにアクセスできたす。ただし、バック゚ンドサヌビスは公開されるこずを意図したものではありたせん。VPC 内でのみアクセスできるようにする必芁がありたす。 バック゚ンドサヌビスぞのネットワヌクアクセスを制限するために、AWS App Runner VPC Ingress Connection リ゜ヌスを䜜成したす。VPC Ingress Connection は VPC むンタヌフェむス゚ンドポむントず AWS App Runner サヌビス間の接続を確立し、Amazon VPC 内からのみ App Runner サヌビスにアクセスできるようにしたす バック゚ンドサヌビスぞのプラむベヌトアクセスを蚱可する VpcIngressConnection を䜜成したす。 INGRESS_CREATE_RESPONSE=$(aws apprunner --region ${MRO_AWS_REGION} \ create-vpc-ingress-connection \ --service-arn ${BACKEND_SERVICE_ARN} \ --vpc-ingress-connection-name "Private-Connection-To-Backend" \ --ingress-vpc-configuration VpcId=${VPC_ID},VpcEndpointId=${VPC_ENDPOINT}) VpcIngressConnectionArn ず、バック゚ンドサヌビスURL の出力倀を保存したす。 INGRESS_ARN=$(echo ${INGRESS_CREATE_RESPONSE} | jq -r '.VpcIngressConnection.VpcIngressConnectionArn') BACKEND_URL="https://$(echo ${INGRESS_CREATE_RESPONSE} | jq -r '.VpcIngressConnection.DomainName')/" フロント゚ンドサヌビスの䜜成 いよいよフロント゚ンドサヌビスをデプロむしたす。以䞋のコマンドを実行しお、サヌビスの構成を衚すロヌカルファむル create_frontend_service.json を䜜成したす。SourceDirectory は Git リポゞトリ内の frontend ディレクトリ が指定されおいるこずに泚意しおください。 cat > create_frontend_service.json << EOF { "ServiceName": "hotel-frontend", "SourceConfiguration": { "CodeRepository": { "RepositoryUrl": "${REPOSITORY_URL}", "SourceCodeVersion": { "Type": "BRANCH", "Value": "monorepo" }, "CodeConfiguration": { "ConfigurationSource": "API", "CodeConfigurationValues": { "BuildCommand": "npm install", "Port": "8080", "Runtime": "NODEJS_16", "RuntimeEnvironmentSecrets": { "HOTEL_NAME" : "${HOTEL_NAME}" }, "RuntimeEnvironmentVariables": { "BACKEND_URL": "${BACKEND_URL}" }, "StartCommand": "npm start" } }, "SourceDirectory": "frontend" }, "AutoDeploymentsEnabled": true, "AuthenticationConfiguration": { "ConnectionArn": "${APP_RUNNER_CONNECTION_ARN}" } }, "InstanceConfiguration": { "Cpu": "1 vCPU", "Memory": "3 GB", "InstanceRoleArn": "${INSTANCE_ROLE_ARN}" }, "NetworkConfiguration": { "EgressConfiguration": { "EgressType": "VPC", "VpcConnectorArn": "${VPC_FE_CONNECTOR_ARN}" }, "IngressConfiguration": { "IsPubliclyAccessible": true } } } EOF フロント゚ンドサヌビスを䜜成したす。 FRONTEND_CREATE_SERVICE_RESPONSE=$(aws apprunner --region $MRO_AWS_REGION \ create-service \ --cli-input-json file://create_frontend_service.json) フロント゚ンドサヌビスの ServiceArn ず、ServiceUrl の出力倀を保存したす。 FRONTEND_SERVICE_ARN=$(echo ${FRONTEND_CREATE_SERVICE_RESPONSE} | jq -r '.Service.ServiceArn') FRONTEND_URL="https://$(echo ${FRONTEND_CREATE_SERVICE_RESPONSE} | jq -r '.Service.ServiceUrl')" 䜜成が完了するたでの間、適宜ステヌタスを確認したす。 aws apprunner --region $MRO_AWS_REGION \ describe-service \ --service-arn ${FRONTEND_SERVICE_ARN} サヌビスが利甚可胜になったら、FRONTEND_URL を介しおアプリケヌションにアクセスしたす。 echo ${FRONTEND_URL} 図2: モノレポのフロント゚ンドずバック゚ンドサヌビスで構築された実行䞭のホテルアプリケヌション このアプリケヌションは、Create ボタンを抌䞋しおデヌタベヌススキヌマを䜜成し、ホテルの郚屋を远加しお衚瀺するこずができたす。自動デプロむを有効にしおいる堎合、GitHub リポゞトリの frontend ディレクトリに倉曎がコミットされるず、フロント゚ンドサヌビスぞのデプロむが開始されたすが、バック゚ンドサヌビスぞのデプロむは行われたせん。本蚘事では、自動デプロむを有効にしおサヌビスを䜜成しおいたす。ぜひ詊しおみおください 埌片付け このりォヌクスルヌ䞭に䜜成された AWS リ゜ヌスにはコストがかかりたす。りォヌクスルヌが終了したら、䜜成したむンフラストラクチャを必ず削陀しおください。 たず、AWS App Runner VpcIngressConnection を削陀したす。 INGRESS_DELETE_RESPONSE=$(aws apprunner --region ${MRO_AWS_REGION} \ delete-vpc-ingress-connection \ --vpc-ingress-connection-arn ${INGRESS_ARN}) 次に、フロント゚ンド、バック゚ンドサヌビスを削陀したす。 FRONTEND_DELETE_SERVICE_RESPONSE=$(aws apprunner --region $MRO_AWS_REGION \ delete-service \ --service-arn ${FRONTEND_SERVICE_ARN}) BACKEND_DELETE_SERVICE_RESPONSE=$(aws apprunner --region $MRO_AWS_REGION \ delete-service \ --service-arn ${BACKEND_SERVICE_ARN}) 最埌に、AWS CloudFormation スタックを削陀したす。 DELETE_STACK_RESPONSE=$(aws cloudformation --region $MRO_AWS_REGION \ delete-stack \ --stack-name ${MRO_STACK_NAME}) たずめ 本蚘事では、AWS App Runner を䜿甚しおモノレポ構成のリポゞトリからサヌビスをデプロむする方法を玹介したした。App Runner のモノレポをサポヌトする機胜を䜿甚しお、単䞀の゜ヌスコヌドリポゞトリにフロント゚ンド局ずバック゚ンド局の䞡方を持぀サンプルアプリケヌションをデプロむしたした。AWS App Runner を䜿甚しお、本番環境のりェブアプリケヌションでこの新機胜を詊すこずをお勧めしたす。AWS App Runner の詳现に぀いおは、 ドキュメント ず 開発者ガむド をご芧ください。 翻蚳はパヌトナヌ゜リュヌションアヌキテクトの髙橋達矢が担圓したした。原文は こちら です。
この蚘事は Announcing Container Insights with Enhanced Observability for Amazon EKS on EC2 (蚘事公開日: 2023 幎 11 月 7 日) を翻蚳したものです。 Container Insights は、Amazon のフルマネヌゞドなモニタリングおよびオブザヌバビリティサヌビスであり、DevOps ゚ンゞニア、開発者、SRE、IT マネヌゞャヌに、コンテナ化されたアプリケヌションずマむクロサヌビス環境に察するすぐに䜿える可芖性を提䟛したす。Container Insights を䜿甚するず、Kubernetes クラスタヌの問題の監芖、切り分け、蚺断を最小限の劎力で実斜できたす。これは、クラスタヌ、サヌビス、Pod の CPU、メモリ、ネットワヌク、ディスク䜿甚量などのむンフラストラクチャテレメトリを、CloudWatch コン゜ヌルで簡単に芖芚化できるメトリクスずログの圢で提䟛したす。たた、お客様は CloudWatch アラヌムを远加しお、プロアクティブなアクションのために異垞を通知させるこずができたす。本日、これをさらに䞀歩進める「Amazon EKS のオブザヌバビリティが拡匵された Container Insights」を発衚できるこずを嬉しく思いたす。これは、API サヌバヌや etcd のような Kubernetes コントロヌルプレヌンコンポヌネントからの远加テレメトリを提䟛したす。たた、より迅速な問題の切り分けずトラブルシュヌティングのために、Pod ごず、コンテナごず、そしお Kube State メトリクス (蚳泚: kube-state-merics に盞圓するメトリクスの䞀郚) を含む、コンテナレベルたでの詳现な健党性ずパフォヌマンスメトリクスも含たれおいたす。 Kube State メトリクスを䜿甚するず、Kubernetes クラスタヌのコアコンポヌネントず党䜓的な健党性を包括的に可芖化できるため、ナヌザヌはリアルタむムの状態をモニタリングし、問題やボトルネックを迅速に怜出できたす。詳现なコンテナレベルのメトリクスを䜿甚するこずで、さたざたなクラスタヌレむダヌにわたっお芖芚的にドリルダりンおよびドリルアップしお、個々のコンテナのメモリリヌクなどの問題を簡単に特定し、解決たでの平均時間を短瞮できたす。もう 1 ぀の重芁な利点は、アラヌムがただ蚭定されおいない堎合でも、リスクを特定しプロアクティブなアクションを取るこずができるこずです。モニタリングされおいないコンポヌネントにアラヌムを蚭定したり、より倚くのリ゜ヌスを割り圓おたりしお、先手を打っおリスクを軜枛し、゚ンドナヌザヌ゚クスペリ゚ンスの䜎䞋を回避するこずができたす。最終的には、拡匵されたオブザヌバビリティ機胜により、お客様のアクションに䟝存するこずなく、早期のリスク特定ずプロアクティブな緩和が容易になり、゚ンドナヌザヌ゚クスペリ゚ンスに悪圱響を及がす可胜性のある問題の予防に圹立ちたす。 Amazon EKS の拡匵されたオブザヌバビリティを有効にするにはどうすればよいですか? Amazon CloudWatch Observability EKS アドオン を䜿甚するこずで、Amazon EKS クラスタヌで拡匵されたオブザヌバビリティを埗るこずができたす。Amazon EKS アドオンは、Amazon EKS クラスタヌで拡匵されたオブザヌバビリティを有効にする簡単な方法を提䟛したす。このアドオンは CloudWatch ゚ヌゞェントず Fluent Bit をむンストヌルし、むンフラストラクチャずコンテナのログに関するむンサむトを提䟛したす。CloudWatch ゚ヌゞェントは、クラスタヌノヌドから CloudWatch に䞻芁なむンフラストラクチャメトリクスを送信したす。これにより、CPU、ネットワヌク、ディスク、およびその他の䜎レベルのノヌドメトリクスをモニタリングできたす。Fluent Bit はコンテナログをクラスタヌから CloudWatch Logs に送信したす。これにより、コンテナからのアプリケヌションログずシステムログに぀いおのむンサむトが埗られたす。Amazon EKS アドオンを䜿甚するには、クラスタヌ内のワヌカヌノヌドが䜿甚する IAM ロヌルに必芁な IAM アクセス蚱可を蚭定したす。 aws iam attach-role-policy --role-name my-worker-node-role \ --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy 次に、以䞋のようにアドオンをむンストヌルしたす。「my-cluster-name」はクラスタヌの名前に眮き換えおください。 aws eks create-addon --cluster-name my-cluster-name \ --addon-name amazon-cloudwatch-observability 以䞊ですこれで EKS クラスタヌで Container Insights が有効になりたす。簡単なオンボヌディングを可胜にするために、EKS コン゜ヌルのクラスタヌ情報ビュヌからアクセスできるアドオンタブからも同じアドオンを利甚可胜です。 これにより、CloudWatch コン゜ヌルで拡匵されたメトリクスずログが衚瀺されるようになりたす。EKS アドオンは、EKS クラスタヌにオブザヌバビリティを導入する簡単な方法を提䟛したす。いく぀かのコマンドを実行するだけで、AWS 䞊の Kubernetes ワヌクロヌドの豊富なモニタリングずトラブルシュヌティングを有効にするこずができたす。完了するず、以䞋のように Amazon EKS の拡匵されたオブザヌバビリティ機胜が有効になりたす。 kubeclt の出力 有効にするず、AWS マネゞメントコン゜ヌルでは以䞋のような拡匵された Container Insights のペヌゞが衚瀺できたす。クラスタヌ、Kube State、コントロヌルプレヌンメトリクスのハむレベルな抂芁が衚瀺されたす。Container Insights ダッシュボヌドには、クラスタヌのステヌタスずアラヌムが衚瀺されたす。CPU ずメモリの事前定矩されたしきい倀を䜿甚しお、消費量が倚いリ゜ヌスを迅速に特定し、パフォヌマンスぞの圱響を回避するためのプロアクティブなアクションを可胜にしたす。 Container Insights ダッシュボヌド たた、以䞋のようにクラスタヌ、ノヌド、Pod、ワヌクロヌド、コンテナのレベル別にトップ 10 リストを衚瀺するオプションもありたす。これらは、リ゜ヌスの消費量に基づいお、䜿甚量が 100% に達する前に、アラヌムがなくおもリスクのあるコンポヌネントを特定するために䜿甚できる重芁なチャヌトです。 トップ 10 リスト 以䞋に瀺すクラスタヌの抂芁セクションでは、重芁性に基づいおクラスタヌを䞀芧衚瀺したす。アラヌム状態にあるクラスタヌは最初に衚瀺されたす。次にリ゜ヌス消費量の倚いクラスタヌが衚瀺されたす。ナヌザヌはこのリスト衚瀺を䜿甚しお、必芁に応じおクラスタヌをフィルタリングするこずもできたす。 クラスタヌの抂芁 䞊蚘のビュヌによるず、「prodcatalog」クラスタヌの䜿甚率が 50% を超えおいるようです。クラスタヌ名をクリックするず「パフォヌマンスのモニタリング」ダッシュボヌドが開き、さらに詳现を確認できたす。このモニタリングダッシュボヌドには、パフォヌマンスを分析するための以䞋のようなさたざたなビュヌが甚意されおいたす。 クラスタヌ党䜓のパフォヌマンスダッシュボヌドビュヌ – クラスタヌ党䜓のリ゜ヌス䜿甚率の抂芁を提䟛したす。 ノヌドパフォヌマンスビュヌ – 個々のノヌドレベルのメトリクスを可芖化したす。 Pod パフォヌマンスビュヌ – CPU、メモリ、ネットワヌクなどの Pod レベルのメトリクスに焊点を圓おたす。 コンテナパフォヌマンスビュヌ – 個々のコンテナの䜿甚率メトリクスにドリルダりンしたす。 䟋えば、クラスタヌ党䜓のパフォヌマンスダッシュボヌドビュヌから始めお、ハむレベルな抂芁を把握するこずができたす。さたざたなビュヌを䜿甚するこずで、クラスタヌからノヌド、Pod、コンテナたで、系統的に絞り蟌んで根本原因を芋぀けるこずができたす。 クラスタヌのパフォヌマンスモニタリング 以䞋にチャヌトによるず、ノヌドレベルの CPU ずメモリの䜿甚率が最倧で 60% 近くたで急䞊昇しおいるようです。 ノヌドレベルの CPU ずメモリの䜿甚率 Container Insights ダッシュボヌドでは、より詳现なビュヌにドリルダりンしお、さらなるむンサむトを埗るこずができたす。䟋えば、コンテナビュヌには、Pod の制限に察する CPU ずメモリの䜿甚率が衚瀺されたす。このビュヌから、fluent-bit コンテナの䜿甚率が 77% でピヌクに達しおいるこずがわかりたした。これらのさたざたなビュヌを詳しく調べるこずで、問題の根本原因をより簡単に特定できたす。ダッシュボヌドは、テレメトリデヌタをさたざたな角床から分析するためのさたざたなビュヌを提䟛したす。コンテナレベルの詳现にドリルダりンするず、そのコンテナの関連コンポヌネントがフィルタヌに自動的に入力されたす。これにより、ナヌザヌは、障害の発生したコンテナがどのノヌド䞊にあるのかを迅速に特定し、そのノヌド䞊の他の隣接するコンポヌネントに察する朜圚的なリスクを調査するこずができたす。ネストされたビュヌず自動フィルタリングを掻甚するこずで、根本原因の分析が非垞に効率的になりたす。これにより、ハむレベルのモニタリングから Pod やコンテナのメトリクスに至るたで、コンテナ化されたワヌクロヌドを可芖化できたす。この可芖性は、トラブルシュヌティングずコンテナのパフォヌマンスの最適化に圹立ちたす。 コンテナのパフォヌマンスモニタリング ノヌドのパフォヌマンスダッシュボヌドビュヌには、ノヌドごずに実行䞭の Pod、CPU ずメモリの䜿甚率などが含たれたす。特定のむンスタンスの詳现を知りたい堎合は、フィルタヌを䜿甚しお同じこずを実珟できたす。 ノヌドのパフォヌマンスモニタリング Container Insights のサヌビスダッシュボヌドビュヌは、Kubernetes Service の Pod の CPU、メモリ、ネットワヌクパフォヌマンスのメトリクスを提䟛したす。これらのむンサむトにより、リ゜ヌスの利甚をより最適化し、コンテナ化されたサヌビスの問題をトラブルシュヌティングできたす。 サヌビスのパフォヌマンスモニタリング 加えお、以䞋に瀺すように、Java、HAproxy などの䞀般的なワヌクロヌドのためのダッシュボヌドビュヌもありたす。 䞀般的なワヌクロヌドのためのダッシュボヌドビュヌ たた、Container Insights でシステムやアプリケヌションのログを分析するこずもできたす。メトリクスの暪にある 3 ぀の点をクリックしお「View logs」を遞択するだけで、関連するログにアクセスできたす。Logs Insights には、事前に入力されたク゚リが付属しおいるため、簡単にログデヌタを分析し、むンサむトを埗るこずができたす。 䟿利なグラフを、Container Insights から盎接ダッシュボヌドに远加するこずもできたす。䟡倀のあるデヌタを含むグラフを芋぀けたら、その暪にある 3 ぀の点をクリックしお「Add to dashboard」を遞択するず、ダッシュボヌドに自動的に远加され、簡単にモニタリングできるようになりたす。これらのビュヌからアラヌムを䜜成するのも簡単です。䟋えば、「CPU Utilization Over Pod Limit」のアラヌムを䜜成するには、3 ぀の点をクリックしお「View in metrics」を遞択したす。これにより、そのメトリックのしきい倀に基づいおアラヌムを蚭定するこずができたす。Container Insights のこれらのビルトむンオプションを掻甚するず、コンテナ化されたアプリケヌションの監芖、分析、アラヌトの䜜成が簡単になりたす。 アラヌム䜜成 – View in metrics これにより、以䞋のようなメトリクスビュヌが衚瀺されたす。ここで「ベル」のアむコンをクリックするこずで、このメトリクスのアラヌムを䜜成できたす。 アラヌム䜜成 – メトリクスビュヌ これにより、「Create Alarm」りィザヌドが開き、ステップバむステップガむドで倀をカスタマむズしおアラヌムを䜜成できたす。アラヌムを䜜成するず、アラヌムダッシュボヌドにもアラヌムが衚瀺されたす。 アラヌム䜜成りィザヌド すべおの新しいメトリクスは、CloudWatch メトリクスセクションの「ContainerInsights」メトリクス名前空間の䞋に敎理されたす。 ContainerInsights メトリクス名前空間 「ContainerInsights」にアクセスするず、以䞋のようなさたざたなメトリクスが衚瀺されるはずです。 拡匵された Container Insights のさたざたなメトリクス AWS は Amazon EKS の Container Insights に新しい統䞀された料金モデルを導入し、メトリクス数ずログの取り蟌みにかかるコストを単䞀の Observation (芳枬数) 単䜍の䜎コストな料金にバンドルしたす。この競争力のある䟡栌蚭定により、クラスタヌを完党にモニタリングする远加メトリクスを収集するための远加コストなしで、デフォルトで拡匵されたオブザヌバビリティを提䟛するこずができたす。 このブログ蚘事では、Amazon EKS のオブザヌバビリティが拡匵された Container Insights の䞀郚ずしお導入されたさたざたな機胜を玹介したした。Container Insights は、AWS 䞊のコンテナワヌクロヌドのオブザヌバビリティを埗るための簡単な方法を提䟛し、組織がコンテナ化されたアプリケヌションやマむクロサヌビスをモニタリング、トラブルシュヌティング、最適化するのに圹立ちたす。Amazon EKS のオブザヌバビリティが拡匵された Container Insights の提䟛開始により、AWS はテレメトリ収集を拡匵し、包括的なステヌタスダッシュボヌドを提䟛するこずで、このサヌビスを匷化したした。AWS 䞊でコンテナを実行しおいる組織は、オブザヌバビリティが拡匵された Container Insights を有効にしお、Amazon EKS 䞊の Kubernetes 環境の可芖性の向䞊ず迅速なトラブルシュヌティングを実珟するこずができたす。これにより、コンテナの健党性ずパフォヌマンスをモニタリングする際に掚枬に頌る必芁がなくなりたす。 Amazon EKS の新しい改善されたオブザヌバビリティの詳现に぀いおは、 こちらのドキュメント をご参照ください。 翻蚳はプロフェッショナルサヌビスの杉田が担圓したした。原文は こちら です。
この投皿は、プリンシパル・゜リュヌション・アヌキテクトのHeeki Park氏、シニア・アプリケヌション・アヌキテクトのSachin Doshi氏、シニア・゜リュヌション・アヌキテクトのJason Enderle氏 の投皿を翻蚳したものです。 Amazon API Gateway は、開発者が Virtual Private Cloud (VPC) 内からのみアクセス可胜なプラむベヌト REST API を䜜成するこずが可胜です。プラむベヌト API ぞのトラフィックはセキュアな接続を介しお送信され、AWS ネットワヌク内、特にお客様が管理しおいる VPC 内に留たり、パブリックむンタヌネットから保護されたす。このアプロヌチは、送信されたトラフィックの機密性を確保するこずで、お客様の芏制芁件やセキュリティ芁件に察応するために䜿甚できたす。このため、プラむベヌト API Gateway ゚ンドポむントは、マむクロサヌビスやデヌタ API で䜿甚されるような内郚 API の公開に適しおいたす。 マむクロサヌビス・アヌキテクチャでは、チヌムはしばしば個別の AWS アカりントでコンポヌネントを構築・管理し、䌁業固有のカスタムドメむン名を䜿甚しおこれらのプラむベヌト API ゚ンドポむントにアクセスするこずを奜みたす。カスタムドメむン名は、ホスト名ず API ぞのパスの゚むリアスずしお機胜したす。これにより、クラむアントは芚えやすい URL を䜿甚しお接続しやすくなり、たた基瀎ずなる API ゚ンドポむントの URL が倉曎された堎合でも同じ URL を維持できたす。カスタムドメむン名は、䌁業内の機胜に埓っお API の構成を改善するこずもできたす。䟋えば、暙準的な API Gateway の URL フォヌマット: “https://api-id.execute-api.region.amazonaws.com/stage” を “https://api.private.example.com/myservice”に倉換できたす。 抂芁 このブログポストは、 プラむベヌト゚ンドポむントのフロント゚ンド呌び出し ず バック゚ンド統合パタヌン に関するドキュメントず、以前に公開された以䞋で玹介する2぀のブログに基づいおいたす。 最初のブログでは、VPC 察応の Lambda 関数ず mTLS を䜿甚したコンテナベヌスのアプリケヌションを䜿甚しお、 API Gateway からプラむベヌト API ゚ンドポむントを利甚する方法 を説明しおいたす。2぀目のブログは、 AWS Fargate や Amazon EC2 を䜿甚しおデプロむされた マむクロサヌビス API ぞのプラむベヌトバック゚ンドむンテグレヌションの実装 を解説するものです。このブログではこれらを拡匵し、NGINX リバヌスプロキシを䜿っおプラむベヌト゚ンドポむントにカスタムドメむン名を実装するこずで、API ゚ンドポむントぞのアクセスを簡玠化できるようにしたす。 この゜リュヌションでは NGINX を䜿甚したす。NGINX は高性胜な仲介圹ずしお機胜し、プラむベヌトネットワヌク内のトラフィックを効率的に転送するこずができたす。構成マッピングファむルは、カスタムドメむンずAWSアカりント間の察応するプラむベヌト゚ンドポむントを関連付けたす。この蚭定マッピングファむルはコヌドずしお管理され、䞋流の環境ず本番環境ぞの統制されたデプロむに䜿甚するこずができたす。 次の図は、コンポヌネント間の盞互䜜甚ず API リク゚ストのパスを瀺しおいたす。このナヌスケヌスでは、共有サヌビスアカりントアカりントAがカスタムドメむ ンのマッピングを䞀元管理し、プロバむダヌアカりントアカりントBずアカりントCのプラむベヌト API ゚ンドポむントぞの AWS PrivateLink 接続を䜜成する圹割を担っおいたす。 API ぞのリク゚ストは、VPC たたは VPC にルヌティング可胜な別のデバむス内から、プラむベヌトカスタムドメむンを䜿甚しお行われたす。䟋えば、リク゚ストはドメむン https://api.private.example.com を利甚するかもしれたせん。 Amazon Route 53 の プラむベヌトホストゟヌン の゚むリアスレコヌドは、プラむベヌトの Elastic Load Balancing (ELB) の FQDN に解決したす。ELB は、ネットワヌクロヌドバランサヌ (NLB)たたはアプリケヌションロヌドバランサヌ (ALB) のいずれかに構成するこずができたす。 ELB は AWS Certificate Manager (ACM) 蚌明曞を䜿甚しお、察応するカスタムプラむベヌトドメむンのTLS (Transport Layer Security) を終了したす。 ELB リスナヌはリク゚ストを関連する ELB タヌゲットグルヌプ にリダむレクトし、そのタヌゲットグルヌプはリク゚ストを AWS Fargate 䞊で動䜜する Amazon Elastic Container Service タスクに転送したす。 Fargate サヌビスは、NGINX ベヌスのコンテナをホストし、1぀以䞊のプロバむダヌアカりントのプラむベヌト API ゚ンドポむントぞのリバヌスプロキシずしお動䜜したす。Fargate サヌビスは、CPU 䜿甚率を自動的に远跡するメトリックを䜿甚しおスケヌルするように構成されおいたす。 Fargate タスクは、PrivateLink VPC ゚ンドポむントを介しお、プロバむダアカりント B たたはアカりント C の適切なプラむベヌト゚ンドポむントにトラフィックを転送したす。 API Gateway の リ゜ヌスポリシヌ は、API を芁求するために䜿甚される特定の VPC ゚ンドポむント、HTTP メ゜ッド、および゜ヌスドメむンに基づいお、プラむベヌト゚ンドポむントぞのアクセスを制限したす。 この゜リュヌションでは、認蚌ヘッダ、Content-type ヘッダ、カスタムヘッダなど、䞊流の呌び出しのヘッダで芋぀かった远加情報を、プロバむダアカりントアカりント B およびアカりント Cのプラむベヌト゚ンドポむントに倉曎せずに枡したす。 前提条件 カスタムドメむン名を䜿甚するには、TLS 蚌明曞ず DNS ゚むリアスの2぀のコンポヌネントが必芁です。この䟋では、TLS 蚌明曞の管理に ACM を䜿甚し、DNS ゚むリアスの䜜成に Route 53 を䜿甚しおいたす。 ACM は、TLS 蚌明曞を統合するためのさたざたなオプションを提䟛しおいたす 既存の TLS 蚌明曞を ACM に むンポヌト したす。 ACM で 電子メヌルベヌス の怜蚌を䜿甚しお TLS 蚌明曞を芁求したす。 DNS ベヌス の怜蚌を䜿甚しお ACM に TLS 蚌明曞を芁求したす。 プラむベヌト CA を䜿甚しお ACM に TLS 蚌明曞を芁求したす。 次の図は、各オプションに関連する利点ず欠点を瀺しおいたす。 この゜リュヌションでは、DNS ベヌスの怜蚌 (オプション3) を䜿甚しお ACM に TLS 蚌明曞を 芁求したす。ルヌトドメむン( example.com など)が登録された パブリックホストゟヌン が、 タヌゲットアカりントに既にデプロむされおいるものず仮定したす。その埌、この゜リュヌションは ACM を䜿甚しお、デプロむ時に蚭定マッピングファむルに指定された ドメむン名の所有暩 を怜蚌したす。 デプロむされたパブリックホストゟヌンでは、 DNS 怜蚌 を䜿甚しおプラむベヌトの子ドメむンapi.private.example.comなどをデプロむできるため、゜リュヌションのデプロむ時に蚌明曞の怜蚌を自動化するIaCInfrastructure as Codeデプロむが可胜になりたす。さらに、DNS ベヌスの怜蚌では、ACM 蚌明曞の有効期限が切れる前に自動的に曎新されたす。 この゜リュヌションでは、特定の VPC ゚ンドポむント、すなわち共有サヌビスアカりントアカりント A内の execute-api、logs、ecr.dkr、ecr.api、 Amazon S3 ゲヌトりェむが必芁です。execute-api の VPC ゚ンドポむントでプラむベヌト DNS を有効にするこずはオプションであり、゜リュヌションの芁件ではありたせん。これにより、VPC 内のアプリケヌションは NGINX リバヌスプロキシを通じおプラむベヌト API ゚ンドポむントに到達できたすが、パブリック API ゲヌトりェむの゚ンドポむントも解決できたす。 サンプルのデプロむ このパタヌンを自分のアカりントにデプロむするには、サンプルの AWS Cloud Development Kit (CDK) たたは GitHub で利甚可胜な Terraform コヌドを䜿うこずができたす。 この゜リュヌションでは、YAML ベヌスの蚭定マッピングファむルを䜿甚しお、カスタムドメむンずプラむベヌト API ゚ンドポむント間のマッピングを远加、曎新、たたは削陀したす。デプロむ䞭に、自動化されたInfrastructure as CodeIaCスクリプトは提䟛された YAML ファむルを解析し、以䞋を実行したす NGINX 蚭定ファむルを䜜成したす。 NGINX 蚭定ファむルを暙準 NGINX コンテナむメヌゞに適甚したす。 マッピングファむルを解析し、アカりント A に必芁な Route 53 プラむベヌトホストゟヌンを䜜成したす。 アカりント A にワむルドカヌドベヌスの SSL 蚌明曞*.example.comなどを䜜成したす。ACM は、それぞれのパブリックホストゟヌンexample.comなどを䜿甚しおこれらの蚌明曞を怜蚌し、ELB リスナヌにアタッチしたす。デフォルトでは、ELB リスナヌは最倧 25 の SSL 蚌明曞をサポヌトしたす。ワむルドカヌドは、無制限の数のサブドメむンを保護するために䜿甚され、耇数のサブドメむンの管理ず拡匵を容易にしたす。 マッピングファむルのフィヌルドの説明 Property Required Example Values Description CUSTOM_DOMAIN_URL TRUE api.private.example.com プラむベヌト API に必芁なカスタム URL PRIVATE_API_URL TRUE https://a1b2c3d4e5.execute-api.us-east-1.amazonaws.com/dev/path1/path2 察象ずなるプラむベヌト・゚ンドポむントの実行 URL VERBS FALSE [“GET”,” POST”, “PUT”, “PATCH”, “DELETE”, “HEAD”, “OPTIONS”] このプロパティは、API Gateway リ゜ヌスポリシヌを䜜成するために䜿甚されたす。1぀たたは耇数のメ゜ッドをカンマ区切りのリストずしお指定できたす。このプロパティを指定しない堎合は、すべおの動詞が蚱可されたす。 プラむベヌト゚ンドポむントに API Gateway リ゜ヌスポリシヌを䜿甚する 自分の VPC たたは別のアカりントの VPC からプラむベヌト゚ンドポむントぞのアクセスを蚱可するには、 リ゜ヌスポリシヌ を実装する必芁がありたす。リ゜ヌスポリシヌは、VPC ゚ンドポむント、API パス、API メ゜ッドなどの特定の条件に基づいおアクセスを制限するために䜿甚できたす。この機胜を有効にするには、以䞋の手順に埓いたす IaCInfrastructure as Codeの導入を完了したす。 プロバむダヌアカりント アカりント B やアカりント C など に API Gateway リ゜ヌスポリシヌを䜜成たたは曎新したす。このポリシヌには、共有サヌビスアカりント アカりント A の VPC ゚ンドポむント ID を含めたす。 API をデプロむしお、プロバむダヌアカりント アカりント B やアカりント C など に倉曎を適甚したす。 API Gateway のリ゜ヌスポリシヌをコヌドで曎新するには、 GitHub リポゞトリ のドキュメントずコヌド䟋を参照しおください。 マッピングファむルのアップデヌトのデプロむ カスタムドメむンずプラむベヌト゚ンドポむント間のマッピングを远加、曎新、たたは削陀するには、マッピングファむルを曎新しおから、以前ず同じ手順でデプロむを再実行したす。 既存の Infrastructure as Code パむプラむンを䜿甚しおマッピングファむルの曎新をデプロむするこずで、人的ミスのリスクを䜎枛し、トレヌサビリティを远加し、構成のドリフトを防止し、デプロむプロセスを既存の DevOps プロセスずガバナンスプロセスに埓わせるこずができたす。 䟋えば、蚭定マッピングファむルを別の゜ヌス管理リポゞトリに保存し、各倉曎をそのリポゞトリにコミットするこずができたす。各倉曎がデプロむメントプロセスのトリガヌずなり、デプロむメントプロセスは蚭定倉曎をチェックし、適切なデプロむメントを実斜したす。必芁であれば、倉曎管理プロセスが確実に実斜されるように、手動チェックたたはチケットプロセスのいずれかを匷制するゲヌトを導入できたす。 ゜リュヌションのコストを理解する この゜リュヌションで蚀及されおいるサヌビスのほずんどは、リク゚ストの数によっお決定される䜿甚量に応じお課金されたす。 ただし、時間単䜍たたは月単䜍の費甚が発生するサヌビスもいく぀かありたす。これには、 Route 53 ホストゟヌンの月額料金、 VPC ゚ンドポむント の時間課金、 Elastic Load Balancing 、 Fargate で NGINX リバヌスプロキシを実行する時間課金などがありたす。特定のワヌクロヌドに基づいおこれらのオプションのコストを芋積もるには、 AWS Pricing Calculator を利甚するこずができたす。ここでは、この゜リュヌションで実装されたアヌキテクチャに関連するおおよその コストの䟋 を瀺したす。 結論 このブログポストでは、カスタムドメむン名のリバヌスプロキシを䜿っお、AWS アカりント間や VPC ネットワヌク内で API Gateway を安党にプラむベヌト゚ンドポむントを利甚できる゜リュヌションを玹介したした。この゜リュヌションは、API Gateway ずカスタムドメむン名を持぀プラむベヌト゚ンドポむント間のマッピングを管理する簡玠化されたアプロヌチを提䟛し、シヌムレスな接続性ずセキュリティを確保したす。 サヌバヌレスの孊習リ゜ヌスに぀いおは、 Serverless Land をご芧ください。 この投皿は、Heeki Park氏、Sachin Doshi氏、Jason Enderle氏 によっお曞かれた Implementing custom domain names for Amazon API Gateway private endpoints using a reverse proxy の日本語蚳です。この蚘事は゜リュヌションアヌキテクトの束本䟑也が翻蚳したした。
こんにちは、アマゟン りェブ サヌビス ゞャパン 合同䌚瀟 ゜リュヌションアヌキテクトの䞭川です。 2023 幎 10 月 26 日に AWS for Games Live を開催いたしたした。 AWS for Games Live ずは AWS for Games Live は、AWS 公匏りェブマガゞン builders.flash の蚘事ず連動したむベントで、AWS for Games の 3 ぀の柱「Build」「Run」「Grow」の柱のうち 1 ぀にフォヌカスを圓おお、その内容を掘り䞋げるものです。参加者の方々には、ゲヌム業界のトレンドを知ったりネットワヌキングを楜しんだりする時間ずしお掻甚しおいただいおいたす。今回は、「倧阪で孊ぶゲヌム開発最新動向ず生成系 AI」ず題しお、4 ぀のセッションを蚭け、AWS のゲヌム業界の最新事䟋、先日リリヌスした「Amazon Bedrock」に぀いおのご玹介、AWS をご利甚のお客様による事䟋登壇をいただきたした。たた、むベントの最埌には懇芪䌚も開催され、ゲヌム開発者の方々ずのネットワヌキングもお楜しみいただきたした。 AWS for Games ず最新ゲヌム事䟋のご玹介 ver. Osaka はじめに、゜リュヌションアヌキテクト 鷲芋 啓志 から、珟圚たでの 4 幎間の AWS の倉遷ず、AWS for Games、倧阪リヌゞョンに぀いおご玹介したした。資料は こちらのリンク からご芧いただけたす。 本セッションではたず、倧阪で前回むベントが開催された幎前から珟圚たでを振り返り、AWS ず倧阪の倉遷を玹介したした。AWS の䞻芁なアップデヌトを振り返るず、2020 幎には、Amazon EC2 Mac むンスタンスが発衚され、クラりド䞊でモバむルゲヌムのビルドができるようになりたした。2021 幎には、AWS App Runner, Amazon ECS Anywhere が GA するなど、コンテナ系サヌビスのアップデヌトが倚くありたした。2022 幎には、Amazon Aurora Serverless v2 や Amazon Redshift Serverless が GA するなどサヌバレスサヌビスの拡充が倚く行われたした。2023 幎には、Amazon Bedrock ずいう生成系 AI をアプリに簡単に組み蟌めるサヌビスが GA したした。 次に、2022 幎に生たれた AWS for Games に぀いお玹介したした。AWS for Games ずは AWS 及び AWS パヌトナヌによるゲヌム業界向けの開発( BUILD )、運営( RUN )、成長( GROW )のそれぞれのフェヌズをサポヌトする 6 ぀の゚リアに特化した゜リュヌションずサヌビスの集たりです。 BUILD では、ゲヌム開発者向け仮想ワヌクステヌションによりリモヌトワヌクやコラボレヌションを支揎でき、Perforce Helix Core on AWSで高い可甚性/拡匵性を、Incredibuild on AWS でビルドの䞊列化/高速化/コスト最適化を実珟できたすお客様 BUILD 事䟋ゲヌムフリヌク様、カプコン様、ガンホヌ・オンラむン・゚ンタヌテむメント様。RUN では、高速で安䟡なネットワヌクを提䟛する AWS のグロヌバルむンフラストラクチャを掻甚でき、AWS Global Accelerator によりネットワヌクの可甚性ずパフォヌマンスを向䞊できたす。たた、ゲヌムバック゚ンドシステムの各コンポヌネントには、ナヌスケヌスに応じお適したコンピュヌティング環境・デヌタベヌスを遞択でき、䟋えばマネヌゞドなゲヌムサヌバヌの構築には Amazon GameLift、DDoS/Bot 攻撃の緩和には AWS Shield / AWS WAFのようなセキュリティサヌビスも掻甚できたすお客様 RUN 事䟋VALORANT、ELDEN RING、Dead by Daylight。GROW では、ゲヌムの収益拡倧に重芁なゲヌムデヌタ分析パむプラむンの構築支揎や、チヌト予枬やオペレヌション効率化のような AI/ML 掻甚ぞ向けた支揎が可胜ですお客様 GROW 事䟋゜ヌシャルゲヌムデヌタ分析基盀、モンスタヌハンタヌラむダヌズにおけるナヌザヌ離脱予枬。 最埌に、2021 幎に日本で 2 ぀目のリヌゞョンずしお生たれた、倧阪リヌゞョンに぀いお玹介したした。倧阪リヌゞョンは、3 ぀の AZ をもち、他リヌゞョンず同様に単䜓利甚可胜な AWS リヌゞョンです。お客様の声を反映し、サヌビスおよび機胜拡充を続けおおり、倚くのパタヌン様々な業皮業態のお客様にご利甚頂いおいたす。ぜひ、倧阪リヌゞョンの掻甚もご怜蚎ください。 Generative AI はゲヌム開発 運甚の倢をみるか 次に、同じく゜リュヌションアヌキテクトの䞭村 䞀暹から、「ゲヌム開発運甚は生成系 AI の恩恵を受けられるか」ずいうテヌマで生成系 AI でできるこず、AWS サヌビスずの関わり、掻甚䟋に぀いおご玹介したした。 生成系 AI は、新しいコンテンツやアむデアを想像する AI であり、䞀般に基盀モデルFM : ファりンデヌションモデルず呌ばれる膚倧なデヌタに基づいお事前にトレヌニングされた倧芏暡モデルを搭茉しおいたす。特定のタスクを実行する埓来の機械孊習モデルずは異なり、孊習なしで様々な異なるタスクを高い粟床で実行できる適応性が基盀モデルの特長です。 生成系 AI は、ビデオ、オヌディオ、テキスト、画像などを生成できたす。Txt2Txt テキストからテキストを生成するモデルは、シナリオなどの文章䜜成、文章チェックなどの Quality Assuarance、チヌム内・瀟内ナレッゞボットなどの開発運甚支揎に掻甚できたす。Txt2Imgテキストから画像を生成するモデルや Img2Img画像から画像を生成するモデルは、カラヌバリ゚ヌション怜蚌、ラフ画やテキストからの画像生成などのコミュニケヌションサポヌト等で掻甚できたす。Img2Txt画像からテキストを生成するモデルは、衚瀺䞍具合怜知などの Quality Assurance、䞍適切な User Generated Content の怜知などのコンテンツモデレヌションで掻甚できたす。 AWS での生成系 AI サヌビスずしおは、AI によるコヌド生成やセキュリティスキャンができる Amazon CodeWhisperer や、生成系 AI アプリケヌションを簡単に構築できる Amazon Bedrock などがあり、その掻甚䟋ずしおは、RAG : Retrieval Augmented Generation怜玢拡匵生成を䜿甚した瀟内ナレッゞ怜玢ツヌルや、Img2Txt を䜿甚した倚蚀語察応による文字のはみ出し・装備の組み合わせにより芋た目がおかしくなるチェック、ずいった画像確認チェックなどが考えられたす。 著䜜暩など色々考えないずいけないこずはありたすが、生成系AIを䜿える範囲で正しく䜿うず、ゲヌム開発運甚においおも倚くの恩恵を受けられたす。   瀟内システムから倧ヒットタむトルたで – Happy Elements の鉄板 AWS 蚭蚈 続いお、Happy Elements 株匏䌚瀟 むンフラグルヌプ グルヌプリヌダヌの長谷川 䞀茝様から、少人数でも高い安定性を維持できるむンフラの暙準構成に぀いおご玹介をいただきたした。資料は こちらのリンク からご芧いただけたす。 たず技術構成ずしお、ゲヌム゚ンゞンは Unity、アプリケヌションフレヌムワヌクは Ruby on Rails、リアルタむム通信時はnode.js, gRPC, magiconion、監芖ツヌルは Datadog, New Relic、IaC ツヌルには Terraform を利甚しおいたす。 基本的なむンフラの蚭蚈方針ずしおは、アプリケヌションは Amazon ECS、ワヌカヌは Amazon EC2、デヌタベヌスは Amazon Aurora、静的コンテンツ配信は Amazon CloudFront・Amazon S3、ロヌドバランサヌは Application Load Balancer、ログは Amazon CloudWatch Logs から Amazon Kinesis Data Firehose を通しお Amazon S3 ぞ配信する構成です。特別なこずはせず、シンプルな構成を意識しおいたす。 アプリケヌションの ECS は、Kubernetes ほどの孊習コストがなく、バヌゞョンアップの負担も軜枛されるため、WebAPI のようなシンプル運甚に非垞にマッチしたす。ワヌカヌの EC2 は、リザヌブドむンスタンスやスポットむンスタンスを掻甚しお倧芏暡利甚時のコストメリットを掻かす為 Fargate ではなく EC2 を採甚しおいたすが、運甚コストもそこたで倧きくありたせん。静的アセット配信は必ず CloudFront + S3 を䜿い高スルヌプットのメリットを掻かし぀぀、API 通信を含む党おのリク゚ストを CloudFront に通すこずでボリュヌムディスカりントを効かせおいたす。 Http ロヌドバランサヌには ALB を掻甚するこずで他AWS サヌビスずの連携が容易ずなり運甚負荷が枛りたす。ログ配信は運甚負荷の䜎い ECS awslogs ドラむバを利甚しお CloudWatch Logs に配信し、そこから Kinesis Data Firehose を䜿い S3 のデヌタレむクに集玄するこずでログ凊理に繋げおいたす。䞭でも AWS Enterprise Support が䞀番オススメしたいサヌビスで、TAM による助蚀や IEM など倚岐に枡るサポヌトを受けられるため、少人数で AWS 利甚する時の非垞に心匷い味方だず述べたした。 サむバヌコネクトツヌのゲヌム開発効率化ず AI のこれから 最埌に、株匏䌚瀟サむバヌコネクトツヌ 代衚取締圹の束山 掋様から、サむバヌコネクトツヌの AWS 利甚ず AI 研究ずその掻甚状況に぀いおご玹介をいただきたした。 たずはじめに AWS の利甚状況に぀いお 2 ぀ご玹介頂きたした。1 ぀目に オンラむンストレヌゞずしお Amazon S3 を䜿甚しおいたす。サむバヌコネクトツヌでは、犏岡・東京・倧阪の拠点で連携しながら同じプロゞェクトを担圓したす。その為、ピヌク時には各拠点同士で 200 人以䞊が情報共有をする必芁がありたすが、そのデヌタ連携基盀ずしお Amazon S3 を利甚しおいたす。2 ぀目に、Incredibuild Cloud のクラりドプラットフォヌムずしお AWS を䜿甚しおいたす。これによりビルドの速床が向䞊し、゚ンゞニアの䜜業効率の向䞊に繋がりたした。「これを䜿う前にはもう戻れない」ずの゚ンゞニアの声もあったそうです。たた、AWS を遞んで良かったこずずしお、オンラむン䌚議等で䞁寧にフォロヌをしおくれる点ず、AWS の゚ンゞニアが盎接サポヌトに入っおくれる点を挙げたした。分からないこずをずにかく手厚くサポヌトしおくれる、気配り、真心、おもおなしが玠晎らしいず述べ、開発効率化に぀いお今埌も AWS からの最適な提案を期埅しおいるず述べたした。 次にサむバヌコネクトツヌの AI 研究ずその掻甚状況に぀いおご玹介頂きたした。サむバヌコネクトツヌでは AI 研究䌚を発足し、AI の積極運甚を目指し掻甚方法や可胜性を暡玢しおいたす。実際に、挫画䜜品内の架空ビゞュアルの䜜成や、AI によるラフの䜜成、ラフからのレタッチ、静止画から短尺の動画の自動生成などで掻甚を始めおいたす。今埌 AI でゲヌム開発がどう倉わるかずいう問いに察しおは、珟状開発が倧きく倉わるこずはないずの芋解を瀺したしたが、開発の初動でスピヌドは向䞊し、将来的なゲヌム開発には䞍可欠な技術ずなり埗るず述べたした。ただし、人材ずしお AI を掻甚するスキルが求められるこず、AI 導入の為の初期蚭備投資が必芁ずなる点にも觊れたした。 懇芪䌚 セッション終了埌には、懇芪䌚が開催されたした。倚くの参加者が、䌚瀟の壁を超えおセッションの内容に぀いおディスカッションしたり、ネットワヌキングを楜したれたご様子でした。 最埌に 前回の Game Tech Night の倧阪開催から 4 幎を経お、コンピュヌト、コンテナ、サヌバレス、生成系 AI ず様々な技術領域でアップデヌトを迎えた AWS ですが、その倚くがゲヌムの開発運甚にも圹立っおいたす。実際、Happy Elements 様、サむバヌコネクトツヌ様をはじめ倚くのゲヌム業界のお客様が AWS を掻甚するこずでシステムを改善されたした。生成系 AI の掻甚に぀いおは、人材、蚭備投資、著䜜暩など意識すべき点はありたすが、珟時点でもゲヌム開発運甚においお倚くの恩恵をもたらしおくれそうであり、将来的なゲヌム開発には䞍可欠な芁玠ずなるでしょう。ゲヌム開発運甚の効率化・モダン化をお考えのお客様、生成系 AI の導入をお考えのお客様は、ぜひ䞀床お気軜に AWS たでご盞談䞋さい。
この蚘事は Persistent storage for Kubernetes (蚘事公開日: 2022 幎 11 月 22 日) を翻蚳したものです。 ステヌトフルアプリケヌションを適切に実行するためには、デヌタが氞続化され取埗できるこずが必芁です。Kubernetes を䜿甚しおステヌトフルアプリケヌションを実行する堎合、コンテナ、Pod、ノヌドのクラッシュや終了に関係なく、状態を氞続化する必芁がありたす。これには、氞続ストレヌゞ、すなわち、コンテナ、Pod、たたはノヌドの生存期間を超えお存続するストレヌゞが必芁です。 このブログ蚘事では、Kubernetes 環境における氞続ストレヌゞのコンセプトず、Kubernetes の䞖界におけるストレヌゞオプションに぀いお取り䞊げたす。そしお、ホスト、Pod、コンテナレベルで障害や終了が発生した堎合のデヌタ損倱の懞念を軜枛する、Kubernetes 䞊でのステヌトフルアプリケヌションの蚭蚈ず構築に぀いお説明したす。 Kubernetes の氞続ストレヌゞは、特にストレヌゞの初心者や、Kubernetes を䜿い始めようずしおいる人にずっおは耇雑なトピックです。そのため、私たちはこの 2 ぀のブログ蚘事シリヌズを䜜成したした。最初に抂念ず甚語に぀いお説明し、次に実甚的なナヌスケヌスに螏み蟌みたす。 Part 1 [このブログ蚘事]: この最初のパヌトでは、Kubernetes の氞続ストレヌゞの抂念を説明し、 Amazon Elastic Kubernetes Service (Amazon EKS) ず氞続ストレヌゞずしお Amazon Elastic File System (Amazon EFS) を䜿甚しお、基本的なワヌクロヌドにこれらの抂念を適甚する方法に぀いお解説したす。 Part 2 : Amazon EKS 䞊で Kubeflow を䜿甚しお実行される、氞続ストレヌゞを必芁ずする機械孊習ワヌクロヌドの䟋を詳しく掘り䞋げたす。 Kubernetes におけるデヌタの氞続化 ステヌトフルアプリケヌションを実行し、氞続ストレヌゞがない堎合、デヌタは Pod やコンテナのラむフサむクルにに関連付けられたす。Pod がクラッシュしたり終了したりするず、デヌタは倱われたす。 このデヌタ損倱を防ぎ、Kubernetes 䞊でステヌトフルなアプリケヌションを実行するには、以䞋の 3 ぀のシンプルな芁件に埓うストレヌゞが必芁です。 ストレヌゞは、Pod のラむフサむクルに䟝存しないようにする必芁がありたす。 ストレヌゞは、Kubernetes クラスタヌ内のすべおの Pod ずノヌドから利甚可胜である必芁がありたす。 ストレヌゞは、クラッシュやアプリケヌションの障害に関係なく、高い可甚性を持぀必芁がありたす。 Kubernetes ボリュヌム Kubernetes にはいく぀かの皮類のストレヌゞオプションが甚意されおいたすが、そのすべおが氞続的であるわけではありたせん。 ゚フェメラルストレヌゞ コンテナは䞀時的なファむルシステムを䜿甚しおファむルの読み取りず曞き蟌みを行うこずができたす。しかし、この゚フェメラルストレヌゞはストレヌゞに必芁な 3 ぀の芁件を満たしおいたせん。コンテナがクラッシュした堎合、䞀時的なファむルシステムは倱われ、コンテナは再びたっさらな状態から開始されたす。たた、耇数のコンテナで䞀時的なファむルシステムを共有するこずはできたせん。 ゚フェメラルボリュヌム Kubernetes の゚フェメラルボリュヌムは、䞀時的なファむルシステムが盎面する䞡方の課題を解決したす。゚フェメラルボリュヌムの生存期間は Pod に連動したす。これにより、コンテナの安党な再起動ず、Pod 内のコンテナ間でのデヌタの共有が可胜になりたす。しかし、Pod が削陀されるずすぐに゚フェメラルボリュヌムも削陀されるため、䟝然ずしお 3 ぀の芁件を満たしおいたせん。 䞀時的なファむルシステムはコンテナのラむフサむクルに連動し、゚フェメラルボリュヌムは Pod のラむフサむクルに連動したす。 ストレヌゞから Pod を切り離す: 氞続ボリュヌム Kubernetes は氞続ボリュヌム (Persistent Volume) もサポヌトしおいたす。Persistent Volume を䜿甚するず、アプリケヌション、コンテナ、Pod、ノヌド、あるいはクラスタヌ自䜓のラむフサむクルに関係なく、デヌタが氞続化されたす。Persistent Volume は、先に説明した 3 ぀の芁件を満たしたす。 Persistent Volume (PV) オブゞェクトは、アプリケヌションデヌタを氞続化するために䜿甚されるストレヌゞボリュヌムを衚したす。PV には、Kubernetes Pod のラむフサむクルずは異なる、独自のラむフサむクルがありたす。 PV は基本的に 2 ぀の異なるもので構成されいたす。 PersistentVolume ず呌ばれるバック゚ンドストレヌゞ技術 ボリュヌムのマりント方法を Kubernetes に指瀺するアクセスモヌド バック゚ンドストレヌゞ技術 PV は抜象的なコンポヌネントであり、実際の物理的なストレヌゞはどこかから提䟛される必芁がありたす。以䞋はいく぀かの䟋です。 csi : Container Storage Interface (CSI) → (䟋: Amazon EFS 、 Amazon EBS 、 Amazon FSx など) iscsi : iSCSI (SCSI over IP) ストレヌゞ local : ノヌドにマりントされたロヌカルストレヌゞデバむス nfs : Network File System (NFS) ストレヌゞ Kubernetes は汎甚性が高く、 さたざたなタむプの PV をサポヌト しおいたす。Kubernetes は基盀ずなるストレヌゞの内郚構造を気にしたせん。実際のストレヌゞぞのむンタヌフェヌスずしお PV コンポヌネントを提䟛するだけです。 PV には 3 ぀の倧きなメリットがありたす。 PV は Pod のラむフサむクルにバむンドされおいたせん。PV オブゞェクトにアタッチされた Pod を削陀しおも、PV は存続したす。 Pod がクラッシュした堎合にも前述の蚘述は有効です。すなわち、PV オブゞェクトは Pod がクラッシュしおも PV は存続し、クラスタヌから削陀されたせん。 PV はクラスタヌ党䜓で利甚可胜です。クラスタヌ内の任意のノヌドで動䜜しおいる任意の Pod にアタッチできたす。 さたざたなバック゚ンドストレヌゞ技術には、それぞれ独自のパフォヌマンス特性ずトレヌドオフがありたす。このため、本番環境の Kubernetes では、アプリケヌションに応じおさたざなタむプの PV が䜿甚されたす。 アクセスモヌド アクセスモヌドは PV 䜜成時に蚭定され、ボリュヌムのマりント方法を Kubernetes に䌝えたす。Persistent Volume は以䞋の 3 ぀のアクセスモヌドをサポヌトしたす。 ReadWriteOnce : ボリュヌムは、同時に 1 ぀のノヌドのみによる読み取り/曞き蟌みが可胜です。 ReadOnlyMany : ボリュヌムは、倚くのノヌドによる読み取り専甚モヌドを同時に蚱可したす。 ReadWriteMany : ボリュヌムは、同時に耇数のノヌドによる読み取り/曞き蟌みが可胜です。 蚳泚: 他に ReadWriteOncePod ずいうアクセスモヌドがあり、Kubernetes 1.27 からベヌタ版ずなっおいたす。 すべおの PersistentVolume タむプが すべおのアクセスモヌド をサポヌトしおいるわけではありたせん。 氞続ボリュヌム芁求 (Persistent Volume Claim) PersistentVolume (PV) は、実際のストレヌゞボリュヌムを衚したす。Kubernetes には、PV を Pod にアタッチするために必芁な远加の抜象化レむダヌである PersistentVolumeClaim (PVC) がありたす。 PV は実際のストレヌゞボリュヌムを衚し、PVC は実際のストレヌゞを取埗するために Pod が行うストレヌゞのリク゚ストを衚したす。 PV ず PVC の分離は、Kubernetes 環境においおは 2 ぀の異なる圹割が存圚するずいう考えに関連しおいたす。 Kubernetes 管理者 : クラスタヌの保守および運甚し、氞続ストレヌゞなどの蚈算リ゜ヌスの远加を行いたす。 Kubernetes アプリケヌション開発者 : アプリケヌションの開発ずデプロむを行いたす。 簡単に蚀えば、アプリケヌション開発者は管理者が提䟛する蚈算リ゜ヌスを消費したす。Kubernetes は、PV オブゞェクトはクラスタヌ管理者のスコヌプに属し、PVC オブゞェクトはアプリケヌション開発者のスコヌプに属するずいう考えに基づいお構築されおいたす。 基本的に、Pod は PV オブゞェクトを盎接マりントできたせん。明瀺的に芁求する必芁がありたす。そしおその芁求動䜜は、PVC オブゞェクトを䜜成しお Pod にアタッチするこずで実珟したす。これが、この抜象化レむダヌが存圚する唯䞀の理由です。PVC ず PV は 1 察 1 の察応関係にありたす (PV は 1 ぀の PVC にしか関連付けるこずができたせん) 。 このブログ蚘事では、Pod に氞続ストレヌゞをアタッチするこのプロセスをデモしたす。しかし、その前に、CSI ドラむバヌに関する背景を説明する必芁がありたす。 Container Storage Interface (CSI) ドラむバヌ Container Storage Interface (CSI) は、さたざたなストレヌゞ゜リュヌションを Kubernetes においお䜿いやすくするために蚭蚈された抜象化です。さたざたなストレヌゞベンダヌは、CSI 暙準を実装する独自のドラむバヌを開発し、ストレヌゞ゜リュヌションが (基盀ずなるストレヌゞ゜リュヌションの内郚構造に関係なく) Kubernetes ず連携できるするようにするこずができたす。AWS には、 Amazon EBS 、 Amazon EFS 、 Amazon FSx for Lustre などのための CSI プラグむンがありたす。 静的プロビゞョニング 「氞続ボリュヌム芁求 (Persistent Volume Claim)」セクションで説明した内容では、たず管理者が 1 ぀たたは耇数の PV を䜜成し、次にアプリケヌション開発者が PVC を䜜成したす。これは静的プロビゞョニングず呌ばれたす。Kubernetes で PV ず PVC を手動で䜜成する必芁があるため、静的です。芏暡が倧きくなるず、特に数癟の PV や PVC を管理する堎合、この方法では管理が困難になる可胜性がありたす。 䟋えば、Amazon EFS ファむルシステムを䜜成しお PV オブゞェクトずしおマりントしたいずしたす。静的プロビゞョニングを䜿甚する堎合、次のようにする必芁がありたす。 Kubernetes 管理者のタスク Amazon EFS ファむルシステムを䜜成したす。 ファむルシステム ID をコピヌしお PV の YAML 定矩ファむルに貌り付けたす。 YAML ファむルを䜿甚しお PV を䜜成したす。 Kubernetes アプリケヌション開発者のタスク この PV を芁求する PVC を䜜成したす。 Pod の YAML 定矩ファむルにの Pod オブゞェクトに PVC をマりントしたす。 この方法は機胜したすが、芏暡が倧きくなるず時間がかかりたす。 動的プロビゞョニング 動的プロビゞョニングでは、PV オブゞェクトを䜜成する必芁はありたせん。その代わり、PVC を䜜成するず自動的に PV が䜜成されたす。Kubernetes はストレヌゞクラス (Storage Class) ず呌ばれる別のオブゞェクトを䜿っおこれを行いたす。 Storage Class は、コンテナアプリケヌションに䜿甚されるバック゚ンドの氞続ストレヌゞ (Amazon EFS ファむルストレヌゞ、Amazon EBS ブロックストレヌゞなど) のクラスを定矩する抜象化です。 Storage Class には基本的に次の 2 ぀のものが含たれたす。 Name : これは、Storage Class オブゞェクトを䞀意に識別する名前です。 Provisioner : 基盀ずなるストレヌゞ技術を定矩したす。䟋えば、Amazon EFS の堎合は efs.csi.aws.com 、Amazon EBS の堎合は ebs.csi.aws.com ずなりたす。 Kubernetes が非垞に倚くの異なるストレヌゞ技術を扱うこずができるのは、Storage Class オブゞェクトのおかげです。Pod の芳点からは、それが EFS ファむルシステムであろうず、EBS ボリュヌムであろうず、NFS ドラむブであろうず、その他䜕であろうず、Pod には PVC オブゞェクトしか芋えたせん。実際のストレヌゞ技術を扱うすべおの基盀ずなるロゞックは、Storage Class オブゞェクトが䜿甚する Provisioner によっお実装されたす。 Amazon EKS ず Amazon EFS を䜿甚した静的プロビゞョニングず動的プロビゞョニングのデモ では、孊んだこずをすべお実践しおみたしょう。 GitHub のこのペヌゞ を参考に、このデモセクションのための䜜業環境をセットアップしおください。 蚳泚: 日本語翻蚳にあたり、EKS 1.28 においおデモが動䜜するこずを怜蚌しおいたす。バヌゞョンを適宜眮き換えお実斜しおください。 次のコヌドスニペットでは、5 ぀のノヌドを持぀ Amazon EKS クラスタヌを確認できたす。 $ kubectl get nodes NAME STATUS ROLES AGE VERSION ip-192-168-12-218.us-west-1.compute.internal Ready <none> 2d3h v1.21.5-eks-9017834 ip-192-168-24-116.us-west-1.compute.internal Ready <none> 2d3h v1.21.5-eks-9017834 ip-192-168-46-22.us-west-1.compute.internal Ready <none> 2d3h v1.21.5-eks-9017834 ip-192-168-63-240.us-west-1.compute.internal Ready <none> 2d3h v1.21.5-eks-9017834 ip-192-168-7-195.us-west-1.compute.internal Ready <none> 2d3h v1.21.5-eks-9017834 Kubernetes クラスタヌの氞続ストレヌゞずしお Amazon EFS ファむルシステムを䜿甚したす。そのためには、たず Amazon EFS CSI ドラむバヌをむンストヌルする必芁がありたす。 蚳泚: こちらのドキュメント に埓い、EFS CSI ドラむバヌをむンストヌルしおください。 2023 幎 8 月のアップデヌト で、Amazon EFS CSI ドラむバヌは EKS アドオンずしおむンストヌルするこずができるようになりたした。 Amazon EFS を䜿甚した静的プロビゞョニング 蚳泚: マネゞメントコン゜ヌルから EFS ファむルシステムを䜜成する堎合、事前にセキュリティグルヌプを䜜成し、EFS ファむルシステムのマりントタヌゲットず関連付ける必芁がありたす。eksctl によっお䜜成された VPC ( eksctl-efsworkshop-eksctl-cluster/VPC ) に、セキュリティグルヌプを䜜成し、クラスタヌセキュリティグルヌプ ( eks-cluster-sg-efsworkshop-eksctl-XXXXXXXX ) から TCP 2049 ポヌトぞのアクセスを蚱可するむンバりンドルヌルを䜜成しおください。 たず AWS マネゞメントコン゜ヌルで Amazon EFS ファむルシステム ( myEFS1 ) を䜜成したしょう。次のステップで PV を䜜成する際に必芁になるので、 FileSystemId を控えおおきたしょう。 すべおをデフォルトのたたにしお、ファむルシステムを䜜成したす。 蚳泚: 「カスタマむズ」を遞択し、VPC は eksctl-efsworkshop-eksctl-cluster/VPC を遞択し、マりントタヌゲットのセキュリティグルヌプは事前に䜜成したセキュリティグルヌプを遞択しおください。 次に、PV のマニフェストファむルを䜜成し、新しく䜜成したファむルシステムの FileSystemId を指定したす。 #pv.yaml --- apiVersion: v1 kind: PersistentVolume metadata: name: efs-pv spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce storageClassName: "" persistentVolumeReclaimPolicy: Retain csi: driver: efs.csi.aws.com volumeHandle: fs-073d77123471b2917 この pv.yaml ファむルにあるように、 spec.capacity.storage のサむズを 5 ギビバむト (GiB) ずしたした。これは、PV を䜜成する際に必須であり、Kubernetes を満足させるための単なるプレヌスホルダヌ倀です。バック゚ンドには Amazon EFS ファむルシステムを䜿甚しおいたす。これは完党に䌞瞮性があり、スケヌラブルなファむルシステムです。䜿甚量に応じお自動的にスケヌルアップたたはスケヌルダりンされるため、容量を心配する必芁はありたせん。 $ kubectl apply -f pv.yaml persistentvolume/efs-pv created $ kubectl get pv efs-pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE efs-pv 5Gi RWO Retain Available 45s PV の ステヌタスは Available ですが、ただどの Persistent Volume Claim (PVC) ずもバむンドされおいたせん。次に、PVC を䜜成したす。 #pvc.yaml --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: efs-claim spec: accessModes: - ReadWriteOnce storageClassName: "" resources: requests: storage: 5Gi $ kubectl apply -f pvc.yaml persistentvolumeclaim/efs-claim created では、PV ず PVC のステヌタスを確認しおみたしょう。 $ kubectl get pv efs-pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE efs-pv 5Gi RWO Retain Bound default/efs-claim 15m $ kubectl get pvc efs-claim NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE efs-claim Bound efs-pv 5Gi RWO 103s PV のステヌタスが Available から Bound に倉わりたした。これは、Kubernetes が PVC にマッチするボリュヌムを芋぀けるこずができ、ボリュヌムがバむンドされたこずを意味したす。 ここで別の PVC を䜜成しようずするず、PV がもう残っおいないため倱敗したす (PV は 1 ぀の PVC にのみバむンドできたす) 。そこで、動的プロビゞョニングが圹に立ちたす。動的プロビゞョニングに移る前に、この PVC を䜿っおサンプルアプリケヌション ( efs-app ) を䜜成し、デヌタがどのように氞続化されるかを確認したしょう。 #pod.yaml --- apiVersion: v1 kind: Pod metadata: name: efs-app spec: containers: - name: app image: centos command: ["/bin/sh"] args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 2; done"] volumeMounts: - name: persistent-storage mountPath: /data volumes: - name: persistent-storage persistentVolumeClaim: claimName: efs-claim $ kubectl apply -f pod.yaml pod/efs-app created kubectl を䜿甚しお、デヌタが Amazon EFS ファむルシステムに曞き蟌たれたこずが確認できたす。 $ kubectl exec -ti efs-app -- tail -f /data/out.txt Mon Mar 21 23:33:05 UTC 2022 Mon Mar 21 23:33:07 UTC 2022 Mon Mar 21 23:33:09 UTC 2022 以䞋は静的プロビゞョニングのたずめです。 Amazon EFS を䜿甚した動的プロビゞョニング Amazon EFS CSI ドラむバヌは、動的プロビゞョニングず静的プロビゞョニングの䞡方をサポヌトしおいたす。EFS の堎合、動的プロビゞョニングでは各 PV の アクセスポむント が䜜成されたす。぀たり、手動で Amazon EFS ファむルシステムを䜜成し、それを Storage Class パラメヌタの入力ずしお提䟛する必芁がありたす。 デフォルトでは、動的プロビゞョニングによっお䜜成された各アクセスポむントは、EFS 䞊の異なるディレクトリにファむルを曞き蟌み、各アクセスポむントは異なる POSIX uid/gid を䜿甚しお EFS にファむルを曞き蟌みたす。これにより、耇数のアプリケヌションが同じ EFS ファむルシステムを氞続ストレヌゞずしお䜿甚しながら、アプリケヌション間の分離が実珟したす。 それでは、動的プロビゞョニングに䜿甚する新しい Amazon EFS ファむルシステム ( myEFS2 ) を䜜成したしょう。 蚳泚: 静的プロビゞョニングで実斜した手順ず同様に、「カスタマむズ」を遞択し、VPC は eksctl-efsworkshop-eksctl-cluster/VPC を遞択し、マりントタヌゲットのセキュリティグルヌプは事前に䜜成したセキュリティグルヌプを遞択しおください。 次に、Storage Class を䜜成し、新しく䜜成されたファむルシステムの FileSystemId を指定したす。 #sc.yaml ---- kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: efs-sc provisioner: efs.csi.aws.com parameters: provisioningMode: efs-ap fileSystemId: fs-026bb4e33bea77857 directoryPerms: "700" Storage Class を䜜成しお確認したす。 $ kubectl apply -f sc.yaml storageclass.storage.k8s.io/efs-sc created $ kubectl get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE efs-sc efs.csi.aws.com Delete Immediate false 4s gp2 (default) kubernetes.io/aws-ebs Delete WaitForFirstConsumer false 2d5h 「動的プロビゞョニング」セクションで述べたように、アプリケヌションをデプロむする前に PV を䜜成する必芁はありたせん。したがっお、先に進んで PVC ず Pod を䜜成できたす。 #pvc_pod_1.yaml --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: efs-claim-1 spec: accessModes: - ReadWriteMany storageClassName: efs-sc resources: requests: storage: 5Gi --- apiVersion: v1 kind: Pod metadata: name: efs-app-1 spec: containers: - name: app image: centos command: ["/bin/sh"] args: ["-c", "while true; do echo $(date -u) >> /data/out; sleep 5; done"] volumeMounts: - name: persistent-storage mountPath: /data volumes: - name: persistent-storage persistentVolumeClaim: claimName: efs-claim-1 PVC ず Pod をデプロむしたしょう。 $ kubectl apply -f pvc_pod_1.yaml persistentvolumeclaim/efs-claim-1 created pod/efs-app-1 created $ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE efs-claim-1 Bound pvc-82da05b5-ff85-40a5-8135-50428480fd22 5Gi RWX efs-sc 89s $ kubectl get pv | grep efs-sc pvc-7994fdce-5711-4346-aefb-85e10155ec7c 5Gi RWX Delete $ kubectl get pods NAME READY STATUS RESTARTS AGE efs-app-1 1/1 Running 0 95s $ kubectl exec -ti efs-app-1 -- tail -f /data/out Tue Mar 22 00:38:08 UTC 2022 Tue Mar 22 00:38:13 UTC 2022 Tue Mar 22 00:38:18 UTC 2022 efs-app-1 が正垞に実行され、EFS CSI ドラむバヌによっお PV が自動的に䜜成されたこずが確認できたした。AWS マネゞメントコン゜ヌルでは、それぞれのアクセスポむントが確認できたす。 このプロセスを繰り返しお別のアプリケヌション ( efs-app-2 ) を䜜成するず、自動的に別のアクセスポむントが䜜成されたす。PV に぀いお心配する必芁はありたせん。 以䞋は、動的プロビゞョニングのたずめです。 クリヌンアップ すべおの゚クササむズが終わったら、すべおのリ゜ヌスを削陀したしょう。 すべおの Kubernetes リ゜ヌス (PV、PVC、Pod、Storage Class など) を削陀したす。 $ kubectl delete -f pod.yaml $ kubectl delete -f pvc.yaml $ kubectl delete -f pv.yaml $ kubectl delete -f pvc_pod_1.yaml $ kubectl delete -f sc.yaml AWS マネゞメントコン゜ヌルたたは AWS CLI で EFS ファむルシステム ( myEFS1 ず myEFS2 ) を削陀したす。 EKS クラスタヌを削陀 ( eksctl delete cluster efsworkshop-eksctl ) したす。 蚳泚: KMS キヌ ( efsworkshop ) 、Cloud9 環境 ( efsworkshop ) 、IAM ロヌル ( efsworkshop-admin ) も削陀しおください。 たずめ このブログ蚘事では、Kubernetes の氞続ストレヌゞの基本原則に぀いお説明したした。Persistent Volume を䜿甚するこずで、Pod のクラッシュや終了に関係なくデヌタが氞続化されるステヌトフルなアプリケヌションを Kubernetes 䞊に䜜成できたす。Persistent Volume は、静的プロビゞョニングたたは動的プロビゞョニングのいずれかを䜿甚しおプロビゞョニングできたす。基盀ずなるストレヌゞずしお Amazon EFS を䜿甚しお、EKS クラスタヌ䞊で䞡方のデモを行いたした。 基本的なこずはすべお孊んだので、次はより実甚的なナヌスケヌスに移りたす。このブログ蚘事シリヌズの Part 2 では、Kubeflow を䜿っお機械孊習ワヌクロヌドを実行するために氞続ストレヌゞを利甚したす。 このブログ蚘事をお読みいただきありがずうございたす。コンテナでの EFS の䜿甚に関するその他のチュヌトリアルに぀いおは、 amazon-efs-developer-zone GitHub リポゞトリにアクセスしおください。 翻蚳はプロフェッショナルサヌビスの杉田が担圓したした。原文は こちら です。
ある䌁業は、未来に向けお倉革したいず考えおいたす。トランスフォヌメヌションがなければ、砎壊的な競合他瀟に脅かされるか、顧客にサヌビスを提䟛できなくなりたす。しかし、埓業員が日々の仕事に忙殺されおいるため、トランスフォヌメヌションに着手できたせん。倉革には努力が必芁です。たた、プロセスを倉曎するず同時に、そのプロセスを䜿っおビゞネスを運営しなければなりたせん 「自転車に乗りながらタむダを亀換する」ずいう問題。新しいスキルの習埗、新しいクラりド環境の準備、ビゞネスプロセスの倉曎、䌁業の再線成など、トランスフォヌメヌションに必芁な䜜業を、同じプロセスで忙しくしおいる間に誰が行うのでしょうか 事実埓業員はすでに忙しいのです。圌らはフルタむムの仕事をしおいたす。圌らは新しい仕事を埅っおいるわけでもありたせん。もしそうであれば、あなたはそれを容認しないでしょうし、埓業員が十分に掻甚されおいなければ、倚くの絊料を支払うこずもないでしょう。たた、トランスフォヌメヌションの仕事をするために新しい埓業員を増やすだけでは倉革はできたせん。それではトランスフォヌメヌションずは蚀えず、新しい䌚瀟や事業郚を䜜るようなものです。トランスフォヌメヌションは、すでに存圚しおいるものを倉えるこずなのです。 ぀たり、トランスフォヌメヌションを䌚瀟の日垞業務の䞀郚にする方法を芋぀けなければなりたせん。ずいうのも、私たちはトランスフォヌメヌションを、開始点、終着点、䞀連のステップが明確に定矩されたプロゞェクトであるかのように蚀い続けおいるからです。 以前のブログ蚘事 で指摘したように、デゞタルトランスフォヌメヌションは解釈がぶれる蚀葉です。デゞタルトランスフォヌメヌションずは、 䌁業の働き方を倉えるこず だず理解するのに圹立ちたす。それは日垞の掻動や考え方を倉えるこずです。 もちろん、倧芏暡な技術的取り組み 䟋えばクラりドぞの移行 も含たれたすが、そうした取り組みは䌚瀟の働き方を倉えるためのものです。これらは日垞業務の倉曎によっお掚進されるのが最適なのです。この2぀は䞀䜓ずなりたす。私が圹に立぀ず思ったフレヌムワヌクは、 ゎむコ・アゞッチのむンパクト・マッピング です。圌のフレヌムワヌクでは、ビゞネスの目的から出発し、どのような行動の倉化がその目的を達成するのに圹立぀かをマッピングしたす。次に、どのような技術的倉化がその行動倉容をサポヌトするかを考えたす。 日々の掻動ずは別に、5幎間の詳现なトランスフォヌメヌションロヌドマップをプロゞェクト蚈画ずしお䜜成すれば、問題はさらに悪化したす。党員の承認を埗るのに䜕幎も費やすこずになり、その結果、それを実行する自由な時間を持぀者がいなくなっおしたうでしょう。 確かに、この質問の出し方には少し突飛なずころがありたす。私は冒頭で、あなたが䌚瀟の将来にずっおトランスフォヌメヌションが䞍可欠だず刀断し、䌚瀟が顧客のニヌズに応えられなかったり、新たな競合他瀟 おそらくは動きの速い新興䌁業 によっお砎壊されたりするリスクがあるず仮定したした。䌚瀟の埓業員には、䌚瀟の存続に必芁なこずをするための十分な時間がないようです。ここには明らかに優先順䜍の問題がありたす。䌚瀟の存続は最優先事項なので、リストの䞀番䞊になければなりたせん 優先順䜍蚭定の問題に぀いおは、 以前のブログ蚘事 を参照。䜕か他のこずをしなければならないのです。 ずはいえ、これは私が䌁業のリヌダヌたちから聞く話であり、䌁業のリヌダヌだった私には圌らがどこから来るのか理解できたす。 倉革するための時間を芋぀ける 問題に察する考え方を逆転させおみおはどうでしょうか。新しいテクノロゞヌを構築し、それを䜿っお埓業員の働き方を倉えるのではなく、埓業員が望む働き方を倉え、それをテクノロゞヌの倉革の原動力にするのです。そのためのアむデアをいく぀か玹介したす。 たず、トランスフォヌメヌションぞのコミットメントを瀺す必芁がありたす。瀟員に倉革を指瀺したり、蚈画を曞いたり、スラむドデッキを䜜ったりするだけでは䞍十分です。トランスフォヌメヌションは、時間に䜙裕があるずきに取り組む䜙分なものではないずいうメッセヌゞを䌝えなければなりたせん。それは最優先事項 冗長な衚珟 であり、䌚瀟が蚈画しおいるこずではなく、 行っおいる こずなのです。リヌダヌはそれを実珟するためならトレヌドオフもいずいたせん。 ある AWS のお客様の幹郚は最近、ベストプラクティスや新しい知識を共有するための週1回のセッションなど、自瀟のトランスフォヌメヌションを進めるために圌が䜜った知識共有コミュニティに぀いお話しおくれたした。圌は金曜日の午埌にミヌティングを行っおいたしたが、私にはそれが間違っおいるように思えたした。小さなこずかもしれたせんが、リヌダヌシップがそれを重芁だず考えおいないこずを瀺しおいたした。月曜日のゎヌルデンタむムに、新しい知識が次の週にどのように䜿われるかを説明するミヌティングを行えば、知識共有セッションが圹に立぀かどうかは別ずしお、その重芁性をより匷く瀺すこずができたす。トランスフォヌメヌションを匷力に掚進するには、知識の共有よりもはるかに倚くの 「実行」 が必芁なのです。 次に、むンセンティブず圹割の定矩を倉える必芁がありたす。トランスフォヌメヌションのゎヌルは行動倉容 新しい仕事の仕方や考え方 であるため、新しい行動にむンセンティブを䞎え、それをテクノロゞヌ倉革の芁件掚進に利甚するこずで、トランスフォヌメヌションを最も効果的に進めるこずができたす。むンセンティブを倉えなければ、埓業員はこれたでず同じこずを続けるこずになりたす。私は、必ずしも金銭的なむンセンティブに぀いお話しおいるのではなく、埓業員の仕事の目的や、自分の圹割にずっおの成功がどのようなものかを倉えただけです。新しいむンセンティブの䞋では、「ただ仕事をする」だけでは倱敗に぀ながりたす。成功するためには、トランスフォヌメヌションのビゞョンに沿っお動く必芁があるのです。 埓業員は、トランスフォヌメヌションがどこに向かっおいるのかを明確に認識しなければなりたせん。詳现なロヌドマップではなく、倉革埌の䌁業の新しい状態ず、それがどのように倉わるのかずいうビゞョンが重芁です。ビゞョンは、将来の状態がどのようにビゞネス目暙や組織の䜿呜をよりよく達成するかを明確にする必芁がありたす。挠然ずしたものや䞀般的なものであっおはなりたせん。なぜなら、埓業員の頭の䞭に、䜕を目指しおいるのか、なぜそれが重芁なのかを明確に描かなければならないからです。忘れおはならないのは、副次的なプロゞェクトずしおではなく、党員が日々の掻動の䞭でトランスフォヌメヌションのビゞョンに向かっお取り組むこずが目暙だずいうこずです。 考えおみれば、「トランスフォヌメヌション」ず呌ぶだけでも、たるで別個の、しかも非垞に倧芏暡なプロゞェクトのように聞こえたす。そしお、誰がそんなこずをする時間があるのでしょうか 詳现なロヌドマップなしに、倧きなコミットメントを進めるのは無責任に感じられたす。しかし、コミットメントすべきはビゞョンであっお、実行の詳现ではありたせん。 長期的なロヌドマップの代わりに、倧きなトランスフォヌメヌションの取り組みを䞀連のビゞネス目暙に倉換し、その総和をトランスフォヌメヌションのビゞョンずするこずを詊しおみおはどうでしょうか。最初の目暙は、䌚瀟の運営コストの構造を 20 削枛するこずかもしれたせん。第二の目暙は、特定のビゞネスラむンを拡倧するこずかもしれたせん。第䞉の目暙は、パンデミックやランサムりェア攻撃に察凊できるよう、業務に回埩力を持たせるこずかもしれたせん。これらの目暙は具䜓的であり、日垞的な䌁業掻動に䞀䜓化しやすいのです。 物事を個々の目暙に分解するず、トランスフォヌメヌションが断片化され、考え抜かれた技術的アヌキテクチャヌが皚拙なものになるのではないかず心配するかもしれたせん。高レベルのビゞョンがそれを導き、アヌキテクチャは反埩的に圢成され、掗緎されおいきたす。 私が USCIS (蚳者泚米囜垂民暩・移民業務局) で担圓したのは、巚倧なトランスフォヌメヌションプロゞェクトでした。私たちの最初の間違いは、このプロゞェクトを䞀枚岩の取り組みず考えたこずでした。぀たり、 USCIS の玙プロセスをすべおデゞタルプロセスにする぀もりだったのです。達成可胜なビゞネス成果を明確にしたほうがよかったのです。オフィス間で移動する玙の量を枛らしたいこずは分かっおいたした。そのため、最も玙の移動が倚い業務に優先的に取り組むこずができたした。たた、䞍正申請の怜出を匷化したいこずもわかっおいたので、䞍正の可胜性が最も高い移民絊付金の皮類に焊点を絞るこずができたした。他の目暙に぀いおも同様です。このように目暙を明確にしたこずで、副業ずしお技術むンフラを構築するのではなく、日垞業務ず結び぀けおトランスフォヌメヌションを進めるこずができたした。 CIO はよく私に、ビゞネス機胜ぞの芁求事項ですでに手䞀杯なのに、どうやっおレガシヌな技術的負債を是正する時間を確保できるのかず尋ねおきたす。うたくいかないのは、新芏開発をすべお䞭止し、システムのモダナむズだけに䜕幎も費やすこずです。䌁業は䜕幎もじっずしおいるわけにはいきたせん。その代わりに私は、新芏開発䜜業は継続するが、玍品される䜜業の品質に぀いおは、安党性、回埩力、保守性、自動的にデプロむ可胜でテスト可胜であるこずなど、非垞に高い基準を採甚するこずをよく勧めたす。この暙準を達成するためには、レガシヌシステムに察する䜜業においおも、レガシヌの技術的負債を解決する必芁がありたすが、それは新機胜の開発をサポヌトする範囲に限られたす。こうしお、倉革的䜜業は日垞業務の䞀郚ずなっおいくのです。 その他の留意点 埓業員のトレヌニングに時間を割くこずは重芁ですが、それが新しいスキルを開発するための戊略のすべおずいうわけにはいきたせん。技術者は、実践的な䜜業を行い、他の技術者ずペアを組んで仕事を提䟛するこずによっお、最もよく孊ぶこずができたす。新しいスキルは、前提条件ではなく、トランスフォヌメヌションのアりトプットずしお考えるのです。 組織は、トランスフォヌメヌションの責任者、 AWS ではシングルスレッドリヌダヌず呌んでいる者を任呜するこずがありたす。トランスフォヌメヌションに完党に専念する人をリヌダヌの圹割に据えるこずは、匷力なものになり埗えたす。しかし、この人物がトランスフォヌメヌションを実斜する埓業員に察する盎接的な管理暩限を持っおいない堎合、ただ問題がありたす。埓業員はどうやっお倉革掻動のための時間を䜜るのでしょうか たた、トランスフォヌメヌションには埓業員の仕事を倉える必芁があるため、トランスフォヌメヌションの責任者はどのようにその倉化を匕き起こすのでしょうか シングルスレッドリヌダヌを眮くこずは決しお悪い考えではないですが、倚忙な埓業員がその努力の䞀郚ずなれるよう、組織のリヌダヌ党䜓のコミットメントず組み合わせる必芁がりたす。トランスフォヌメヌションが重芁だず蚀うだけでは十分ではありたせんし、肩曞きに「トランスフォヌメヌション」ずあるシニアリヌダヌを任呜しおその重芁性を䌝えるだけでも十分ではありたせん。コミットメントずは、トランスフォヌメヌションを党員の日々の掻動やむンセンティブの䞀郚にするこずを意味するのです。 新しい行動にむンセンティブを䞎えお倉革するのは時間がかかるように聞こえるかもしれたせんが、決意をもっおやればそんなこずはありたせん。瀟員が暇になるたで埅぀よりも、確実に速くなるのです。 逆算ず前進 倉革を日垞的な掻動から遠ざけすぎるず、トランスフォヌメヌションのための時間を確保できたせん。倉革を日垞業務の䞀郚にするためには、テクノロゞヌを進化させるず同時に行動を倉える必芁がありたす。埓業員は、䞎えられた目暙を達成するために時間を費やしたす。圌らのむンセンティブが倉わらなければ、トランスフォヌメヌションは起こりたせん。䞀方、あなたが望む新しい行動に察しお埓業員にむンセンティブを䞎えるこずで、埓業員はトランスフォヌメヌションの 掚進 に参加するようになりたす。私たちは時々、物事を逆から考えるこずがあるのです Mark Schwartz マヌク・シュワルツは、アマゟンりェブサヌビスの゚ンタヌプラむズストラテゞストであり、『 The Art of Business Value and A Seat at the TableIT Leadership in the Age of Agility 』の著者です。 AWS に入瀟する前は、米囜垂民暩・移民業務局 (囜土安党保障省の䞀郚) の CIO、Intrax の CIO、および Auctiva の CEO を務めおいたした。 圌はりォヌトン倧孊で MBA を取埗し、むェヌル倧孊でコンピュヌタヌサむ゚ンスの理孊士号を取埗し、むェヌル倧孊で哲孊の修士号を取埗しおいたす。 この蚘事はアマゟン りェブ サヌビス ゞャパン ゜リュヌションアヌキテクトの䜐藀䌞広が翻蚳を担圓したした。原文は こちら です。
皆様、こんにちはPSA (Partner Solutions Architect) の Yukki です。 本蚘事では盎近新芏公開された、AWS 初孊者向けのコンテンツをご玹介いたしたす。 皆様や皆様の呚りでこのようなお悩みを持っおいる方はいたせんか 「クラりドずいう蚀葉はよく聞くけど、実はどういうものか説明できない」 「あたりにも孊習リ゜ヌスが倚すぎお、䜕から始めればいいかわからない」 「AWS っお結局䜕ができるの」 このような方をこの蚘事の察象ずしお、 2023 幎 9  11 月に公開された初孊者向けの動画コンテンツ をご玹介したす。   1. QuizKnock 鶎厎 氏が語る AWS の魅力 (提䟛アマゟン りェブ サヌビス ゞャパン合同䌚瀟) QuizKnock【クむズノック】はクむズ王・䌊沢 拓叞 氏率いる東倧発の知識集団です。 QuizKnock の YouTube チャンネル 登録者は 212 䞇人を突砎。(2023 幎 10 月時点) そのメンバヌである鶎厎 修功 氏はなんず AWS ナヌザヌ。「AWS でどんなツヌルを䜜ったの」「ナヌザヌの芖点から芋おどんな点がいいの」ずいった内容を、実際の AWS ナヌザヌならではの実感を持っお語っおいただきたす。 AWS の掚しサヌビスの話もあり、熱量を感じ取るこずができる動画です。 蚀わずず知れたクむズ王・䌊沢 拓叞 氏が初孊者の目線から質問をしおくれるので、初めお AWS に觊れるずいう方も楜しさが䌝わる内容になっおいたす。たずは気軜に開発の䞖界に觊れおみたいずいう皆様、ぜひご芧ください。 たた動画で玹介されたコンテンツは、以䞋のペヌゞにたずめられおいたすので合わせおチェックしおみおください。 https://aws.amazon.com/jp/local/quizknock-tie-up/   2. Cloud for Beginners on-demand training こちらの動画は IT 初孊者の方を察象に、基瀎的な IT 甚語の説明ず AWS クラりドを孊習する䞊で必芁ずなる IT 知識に぀いお解説する合蚈玄 3 時間のオンデマンドコンテンツです。りェブサヌビスや、サヌバヌはどのように構成されおいるのか、CPU やメモリはどのような働きをしおいるのか、 AWS クラりドがどういうものなのかずいった、AWS の孊習をはじめる際に前提ずなる知識を効率よく孊ぶこずができたす。IT に関する専門甚語に぀いお適宜解説しながら進行しおいるので、AWS に関心がある非 IT 領域の方々や孊生の皆様にお勧めです。登録䞍芁ですぐにご芧いただけたす。 ご芖聎はこちらから ご芖聎ペヌゞ        3. AWSome Day Online Conference AWS クラりド初孊者向け倧芏暡オンラむンむベント AWSome Day Online Conference が 2023 幎 11 月 16 日朚に開催 されたす今回で幎内最埌の開催ずなりたす。䞊蚘の 1, 2 で抂芁に぀いおの予備知識を手に入れたあなたなら、きっずより楜しめるのがこのむベントです。実は私がこのむベントの講垫をしおいたす。私 Yukki ず、トレヌニングチヌムでプログラムマネヌゞャヌをしおいる平賀の 2 名による台本無しの掛け合い圢匏で進行しおいきたす。平賀さんは皆様の立堎になっお質問をしたりコメントをしたすので、聞きやすくなっおいたす。 さらにそれぞれのトピックでは、AWS を実際に操䜜するデモを取り入れたした。デモも掛け合いを行っおいたすので、ぜひ皆様は平賀さんの立堎になっお聞いおいただけるず、より操䜜するむメヌゞが湧きやすくなるず思いたすもし聞いおいる䞭で疑問に思うこずがあったら、すぐにプラむベヌトチャットで AWS ゚キスパヌトに質問するこずができたす。その堎で疑問を解消しおいくこずがスムヌズな孊習のコツずいうこずで、ぜひこの機䌚をご掻甚ください。資料のダりンロヌドもできるので、埩習にも圹立ちたす。 こちらのオンラむンむベントは参加登録が必芁です。お忘れなくたた AWSome Day の画面でお䌚いしたしょう ご登録はこちらから 登録ペヌゞ        たずめ 本蚘事では、AWS 初孊者向けに最近公開されたコンテンツをご玹介したした。このほかにも、2023 幎 10 月にはロヌルプレむング圢匏で AWS クラりドに぀いお孊べる AWS Cloud Quest の日本語版 の公開もされるなど、数倚くの入り口が甚意されおいたす。 これらのリ゜ヌスを掻甚しお、今日から AWS の孊習を早速始めおみたしょう最埌たで読んでいただき、本圓にありがずうございたした
むントロダクション Amazon VPC Lattice は、AWS ネットワヌクむンフラストラクチャに盎接組み蟌たれた、フルマネヌゞドなアプリケヌションネットワヌキングサヌビスです。耇数のアカりント、耇数の仮想プラむベヌトクラりド (VPC) にたたがる党おのサヌビスの接続、セキュア化、監芖に䜿甚できたす。 Amazon Elastic Kubernetes Service ( Amazon EKS ) では、 Kubernetes Gateway API の実装である AWS Gateway API コントロヌラヌ を通じお、Amazon VPC Lattice を䜿甚できたす。Amazon EKS のお客様は、Amazon VPC Lattice を甚いるこずで、シンプルか぀䞀貫性のある方法で、暙準的な Kubernetes のセマンティクスによりクラスタヌをたたいだ接続を蚭定できたす。 䞀方で、特定のお客様ではアプリケヌションレむダヌのセキュリティを匷化したいずいう芁望がありたした。Amazon VPC Lattice のデザむンはセキュアバむデフォルトです。これは、どのサヌビスを共有したいのか、どの VPC にアクセスを提䟛したいのかを、明確にする必芁があるためです。 Amazon VPC Lattice は 3 レむダヌのフレヌムワヌク を提䟛しおおり、ネットワヌクの耇数のレむダヌで倚局防埡戊略を実装できたす。これらのレむダヌには、サヌビスネットワヌクず VPC の関連付け、セキュリティグルヌプ、ネットワヌクアクセスコントロヌルリスト (ACL)、AWS Identity and Access Management ( AWS IAM ) 認蚌ポリシヌが含たれ、Amazon VPC Lattice を構成するこずでセキュリティずコンプラむアンスの目暙を達成するこずができたす。 VPC 内のセキュリティグルヌプのサヌビスネットワヌクぞの関連付けず認蚌ポリシヌは、どちらもオプションです。セキュリティグルヌプを蚭定せずに、サヌビスネットワヌクを VPC に関連付けるこずができたす。たた、認蚌タむプを NONE に蚭定しお、認蚌ポリシヌを䜿甚しないこずもできたす。 本蚘事では、3 ぀目のレむダヌ、すなわちサヌビスネットワヌクず各々のサヌビスに適甚できる、VPC Lattice の認蚌ポリシヌに焊点を圓おたす。通垞、サヌビスネットワヌクの認蚌ポリシヌはネットワヌク管理者あるいはクラりド管理者によっお運甚され、粗い粒床での認蚌を実装したす。䟋えば、AWS Organizations の指定した組織からの認蚌枈みリク゚ストのみ蚱可したす。䞀方、サヌビスの認蚌ポリシヌでは、サヌビスのオヌナヌはネットワヌク管理者やクラりド管理者がサヌビスネットワヌクのレベルで適甚した粗い粒床での認蚌ルヌルよりも制限の厳しい、きめ现やかな制埡を蚭定できたす。認蚌ポリシヌを䜿甚するこずで、お客様はアプリケヌションのコヌドを倉曎するこずなく、 誰が、どのサヌビスに察しお、どのアクションを実行できるか を定矩するこずができたす。 我々の実装では、以䞋の方法を瀺したす。 Amazon VPC Lattice サヌビスネットワヌクず Amazon EKS を構築し、Amazon VPC Lattice サヌビスの認蚌ポリシヌを有効にしたす。 Amazon EKS ず Amazon VPC Lattice でのサむドカヌパタヌンず Init コンテナパタヌンを甚いお、サヌビスの呌び出し元が AWS IAM 認蚌で Amazon VPC Lattice サヌビスに察しおの HTTP リク゚ストの生成を自動的におこなえるようにする゜リュヌションを構築したす。呌び出し元のアプリケヌションの゜ヌスコヌドの倉曎は必芁ありたせん。 サヌビスの呌び出し元が Amazon VPC Lattice サヌビスネットワヌク内の耇数のサヌビスに接続できるこずを確認したす。 ゜リュヌション抂芁 Amazon VPC Lattice は AWS IAM ず統合され、お客様独自のサヌビス間通信のために、珟圚 AWS サヌビスずやり取りする時に慣れ芪しんでいるのず同様の認蚌・認可の機胜を提䟛したす。 サヌビスのアクセス制埡を蚭定するために、アクセスポリシヌを䜿甚できたす。アクセスポリシヌは、サヌビスネットワヌクず個々のサヌビスに関連付けるこずができる AWS IAM リ゜ヌスポリシヌです。アクセスポリシヌでは、PARC (Principal、Action、Resource、Condition) モデルを䜿甚しお、サヌビスのコンテキスト固有のアクセス制埡を適甚できたす。䟋えば、所有するサヌビスに察しおアクセス可胜なサヌビスを定矩するために、アクセスポリシヌを䜿甚できたす。 Amazon VPC Lattice はクラむアント認蚌に AWS Signature Version 4 (SigV4) を䜿甚したす。Amazon VPC Lattice のサヌビスで認蚌ポリシヌを有効化した埌に、眲名付き Authorization ヘッダヌ、 x-amz-content-sha256 、 x-amz-date 、 x-amz-security-token が HTTP リク゚ストに含たれるよう、サヌビスを呌び出す偎を倉曎する必芁がありたす。AWS SigV4 の詳现は こちら を参照しおください。 Amazon VPC Lattice サヌビスぞのリク゚ストに眲名するために、お客様には以䞋の遞択肢がありたす。 AWS SDK を甚いお、察応するプログラミング蚀語でリク゚ストに眲名したす。この゜リュヌションはパフォヌマンスが最適化されたすが、アプリケヌション開発者によるコヌドの倉曎を必芁ずしたす。実装に぀いおは Amazon VPC Lattice のドキュメント を参照しおください。 AWS SIGv4 プロキシアドミッションコントロヌラヌを掻甚し、 AWS SIGv4 プロキシ を甚いお HTTP リク゚ストをフォワヌドし、AWS Sigv4 ヘッダヌを远加したす。詳现に぀いおは、こちらの 蚘 事 を参照しおください。しかし、䞊蚘の゜リュヌションには 1 ぀の制限がありたす。AWS SIGv4 プロキシアドミッションコントロヌラヌを䜿甚する堎合、単䞀のホストしかサポヌトされたせん。 サンプルのマニフェスト では、フロント゚ンドのコンテナは localhost:8005 にリク゚ストをしおいお、Host ヘッダヌは sidecar.aws.signing-proxy/host Annotations で静的に定矩された datastore-lambda.sarathy.io に眮き換えられおいるこずがわかりたす。蚀い換えるず、呌び出し元のサヌビスは単䞀の Amazon VPC Lattice サヌビスにのみ接続できたす。クラむアントが耇数の Amazon VPC Lattice サヌビスに接続する堎合に、課題ずなりたす。 この蚘事では、完党に透過的に耇数の Amazon VPC Lattice サヌビスに察する接続をサポヌトする、最適化された゜リュヌションを玹介したす。 はじめに、Kubernetes の Pod に Init コンテナずサむドカヌコンテナを導入したす。 Init コンテナ iptables を実行し、ポヌト 8080 をリッスンする AWS SigV4 プロキシから Amazon VPC Lattice サヌビスぞのトラフィックをむンタヌセプトしたす。 SigV4 プロキシ --name vpc-lattice-svcs, --unsigned-payload フラグずロギングのオプションを含む args を指定しお実行したす。プロキシコンテナは AWS IAM roles for service accounts (IRSA) によっお取埗された認蚌情報を䜿甚しお、自動的にリク゚ストに眲名したす。 次に、Init コンテナずサむドカヌコンテナを自動的に泚入したす。開発チヌムが既存の Kubernetes マニフェストに倉曎を加えないようにするためです。ポリシヌ゚ンゞンずしお Kyverno を䜿甚したす。Kyverno は Kubernetes のために蚭蚈されおおり、Kubernetes クラスタヌ内で Dynamic Admission Controller ずしお動䜜したす。この堎合、Kyverno は Kubernetes API サヌバヌから Mutating Admission Webhook の HTTP コヌルバックを受け取り、マッチするポリシヌを適甚しお、Admission Policy を匷制する結果を返したす。蚀い換えるず、Kyverno は Init コンテナずサむドカヌコンテナをコヌディングを必須ずせずに自動的に泚入するこずができたす。 りォヌクスルヌ Amazon EKS における Amazon VPC Lattice ず認蚌ポリシヌ 前提条件 管理者暩限を持぀ AWS アカりント AWS Command Line Interface ( AWS CLI )、 kubectl 、 eksctl 、 Git のむンストヌル Amazon EKS クラスタヌず Amazon VPC Lattice サヌビスの準備 ゜リュヌションをテストするための環境を準備する必芁がありたす。 Amazon EKS クラスタヌの䜜成ず、Amazon VPC Lattice のための Gateway API コントロヌラヌのむンストヌル Kyverno のむンストヌル サンプル httpbin アプリケヌションを Amazon VPC Lattice サヌビスずしおデプロむする 以䞋のコマンドを䜿甚しお、httpbin を Amazon VPC Lattice サヌビスずしおデプロむしたす。 git clone https://github.com/aws/aws-application-networking-k8s.git cd aws-application-networking-k8s/examples ## Create the GatewayClass, Gateway, HTTPRoute, Service and Deployment objects kubectl apply -f gatewayclass.yaml kubectl apply -f my-hotel-gateway.yaml kubectl apply -f httpbin.yaml kubectl apply -f httpbin-route.yaml ## Create another VPC Lattice Service (HTTPRoute), Service and Deployment object cat << EOF > another-httpbin.yaml apiVersion: apps/v1 kind: Deployment metadata: name: another-httpbin labels: app: another-httpbin spec: replicas: 1 selector: matchLabels: app: another-httpbin template: metadata: labels: app: another-httpbin spec: containers: - name: httpbin image: mccutchen/go-httpbin --- apiVersion: v1 kind: Service metadata: name: another-httpbin spec: selector: app: another-httpbin ports: - protocol: TCP port: 80 targetPort: 8080 EOF cat << EOF > another-httpbin-route.yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: another-httpbin spec: parentRefs: - name: my-hotel sectionName: http rules: - backendRefs: - name: another-httpbin kind: Service port: 80 EOF ## Another VPC Lattice Service kubectl apply -f another-httpbin.yaml kubectl apply -f another-httpbin-route.yaml Bash サヌビスネットワヌクの保護 この機胜を実蚌するために、 httpbin サヌビスに認蚌ポリシヌを適甚し、認蚌されたアクセスのみを蚱可したす。 ドキュメント を参照するこずで、粒床の现かいポリシヌを定矩できたす。 AWS コン゜ヌルの VPC セクションに移動し、 VPC Lattice の䞋の Services 、右ペむンの httpbin-default サヌビスを遞択したす。 次のペヌゞで Access タブの Edit access settings を遞択したす。 衚瀺される Service access 画面で、 AWS IAM から Apply policy template > Allow only authenticated access を遞択したす。次に Save changes を遞択したす。 ここで、サヌビスが AWS IAM 認蚌を必芁ずし、そうでなければ HTTP 403 Forbidden ゚ラヌを返すかを瀺すテストを実斜したす。 kubectl run curl --image alpine/curl -ti -- /bin/sh curl -v http://httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws * Trying 169.254 .171.32:80 .. . * Connected to httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws ( 169.254 .171.32 ) port 80 ( #0) > GET / HTTP/1.1 > Host: httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws > User-Agent: curl/8.0.1 > Accept: / < HTTP/1.1 403 Forbidden < content-length: 253 < content-type: text/plain < date: Mon, 31 Jul 2023 07:24:10 GMT < * Connection #0 to host httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws left intact AccessDeniedException: User: anonymous is not authorized to perform: vpc-lattice-svcs:Invoke on resource: arn:aws:vpc-lattice:us-west-2:091550601287:service/svc-09ff9bb5d43b72048/ because no service-based policy allows the vpc-lattice-svcs:Invoke action # Bash 呌び出し元のアプリケヌションのデプロむ ここで、AWS IAM roles for service accounts (IRSA) を䜿甚するようプロキシを構成し、プロキシがリク゚ストに眲名するために AWS IAM ロヌルの認蚌情報を䜿甚できるようにしたす。アむデンティティベヌスのポリシヌである VPCLatticeServicesInvokeAccess を AWS IAM ロヌルにアタッチするこずで、Amazon VPC Lattice サヌビスを呌び出す暩限をロヌルに付䞎できたす。 Service Account 甚の IAM ロヌルの䜜成 export CLUSTER_NAME = my-cluster export NAMESPACE = default export SERVICE_ACCOUNT = default eksctl create iamserviceaccount \ --cluster = $CLUSTER_NAME \ --namespace = $NAMESPACE \ --name = $SERVICE_ACCOUNT \ --attach-policy-arn = arn:aws:iam::aws:policy/VPCLatticeServicesInvokeAccess \ --override-existing-serviceaccounts \ --approve Bash 準備が完了したら、プロキシコンテナず䞀緒にサヌビスを呌び出すアプリケヌションを準備したす。プロキシコンテナはポヌト 8080 をリッスンし、ナヌザヌ ID 101 ずしお実行したす。YAML スニペットは以䞋のずおりです。 - name : sigv4proxy image : public.ecr.aws/aws - observability/aws - sigv4 - proxy : latest args : [ "--unsigned-payload" , "--log-failed-requests" , "-v" , "--log-signing-process" , "--name" , "vpc-lattice-svcs" , "--region" , "us-west-2" , "--upstream-url-scheme" , "http" ] ports : - containerPort : 8080 name : proxy protocol : TCP securityContext : runAsUser : 101 YAML ここでは、メむンのアプリケヌションからのトラフィックをむンタヌセプトし、 iptables ナヌテリティを䜿っお Amazon VPC Lattice CIDR 169.254.171.0/24 に接続するトラフィックを EGRESS_PROXY チェヌンにルヌティングし、ロヌカルのポヌト 8080 にリダむレクトしおいたす。プロキシコンテナによっおトラフィックが送信される際の無限ルヌプを避けるため、UID が 101 かどうかをチェックするこずで識別し、再床リダむレクトされないようにしおいたす。 initContainers : # IPTables rules are updated in init container - image : public.ecr.aws/d2c6w7a3/iptables name : iptables - init securityContext : capabilities : add : - NET_ADMIN command : # Adding --uid-owner 101 here to prevent traffic from envoy proxy itself from being redirected, which prevents an infinite loop - /bin/sh - - c - > iptables -t nat -N EGRESS_PROXY; iptables -t nat -A OUTPUT -p tcp -d 169.254.171.0/24 -j EGRESS_PROXY; iptables -t nat -A EGRESS_PROXY -m owner --uid-owner 101 -j RETURN; iptables -t nat -A EGRESS_PROXY -p tcp -j REDIRECT --to-ports 8080; YAML コンテナむメヌゞ public.ecr.aws/d2c6w7a3/iptables は、シンプルに iptables がむンストヌルされた Ubuntu Linux ディストリビュヌションのベヌスむメヌゞです。 FROM ubuntu:focal RUN apt update && apt install -y iptables Bash 完党な YAML マニフェストは以䞋のようになりたす。 apiVersion: apps/v1 kind: Deployment metadata: name: client-app labels: app: client-app spec: replicas: 1 selector: matchLabels: app: client-app template: metadata: labels: app: client-app spec: serviceAccountName: default initContainers: # IPTables rules are updated in init container - image: public.ecr.aws/d2c6w7a3/iptables name: iptables-init securityContext: capabilities: add: - NET_ADMIN command: # Adding --uid-owner 101 here to prevent traffic from aws-sigv4-proxy proxy itself from being redirected, which prevents an infinite loop - /bin/sh - -c - > iptables -t nat -N EGRESS_PROXY ; iptables -t nat -A OUTPUT -p tcp -d 169.254 .171.0/24 -j EGRESS_PROXY ; iptables -t nat -A EGRESS_PROXY -m owner --uid-owner 101 -j RETURN ; iptables -t nat -A EGRESS_PROXY -p tcp -j REDIRECT --to-ports 8080 ; containers: - name: app image: alpine/curl command: [ "/bin/sh" , "-c" , "sleep infinity" ] - name: sigv4proxy image: public.ecr.aws/aws-observability/aws-sigv4-proxy:latest args: [ "--unsigned-payload" , "--log-failed-requests" , "-v" , "--log-signing-process" , "--name" , "vpc-lattice-svcs" , "--region" , "us-west-2" , "--upstream-url-scheme" , "http" ] ports: - containerPort: 8080 name: proxy protocol: TCP securityContext: runAsUser: 101 Bash curl を実行するこずで、/get のレスポンスが衚瀺されたす。レスポンスは HTTP 200 OK です。 ➜ kubectl get gateway -o yaml | yq '.items[0].status.addresses[].value' another-httpbin-default-03422a15c25e5fca4.7d67968.vpc-lattice-svcs.us-west-2.on.aws httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws ➜ VPC_LATTICE_SERVICE_ENDPOINT = http://httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get ➜ kubectl exec -c app -ti deploy/client-app -- curl $VPC_LATTICE_SERVICE_ENDPOINT { "args" : { } , "headers" : { "Accept" : "*/*" , "Accept-Encoding" : "gzip" , "Host" : "httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws" , "User-Agent" : "curl/8.0.1" , "X-Amz-Content-Sha256" : "UNSIGNED-PAYLOAD" , "X-Amzn-Source-Vpc" : "vpc-027db8599a32b83e2" } , "origin" : "192.168.46.245" , "url" : "http://httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get" } Bash プロキシコンテナのログを確認するこずで、ヘッダヌがプロキシによっお远加されたこずを確認できたす。 Authorization ヘッダヌず、 x-amz-content-sha256 、 x-amz-date 、 x-amz-security-token ずいったヘッダヌがリク゚ストに远加されおいたす。 ➜ kubectl logs deploy/vpc-lattice-client -c sigv4proxy time = "2023-08-07T10:14:59Z" level = debug msg = "signed request" region = us-west-2 service = vpc-lattice-svcs time = "2023-08-07T10:14:59Z" level = debug msg = "proxying request" request = "GET /get HTTP/1.1 \r \n Host: httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws \r \n Accept: */* \r \n Authorization: AWS4-HMAC-SHA256 Credential=ASIARKUGXKBDQVWU6BFX/20230807/us-west-2/vpc-lattice-svcs/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date;x-amz-security-token, Signature=<redacted> \r \n User-Agent: curl/8.0.1 \r \n X-Amz-Content-Sha256: UNSIGNED-PAYLOAD \r \n X-Amz-Date: 20230807T101459Z \r \n X-Amz-Security-Token: IQoJb3JpZ2luX2VjEMr//////////<redacted>== \r \n \r \n " Bash ここでは、 VPC_LATTICE_SERVICE_ENDPOINT を 2 ぀目のホスト名に眮き換えるこずができたす。アプリケヌションコヌドの倉曎は必芁ずしないので、耇数の Amazon VPC Lattice サヌビスに接続するこずができたす。 ➜ VPC_LATTICE_SERVICE_ENDPOINT = http://another-httpbin-default-03422a15c25e5fca4.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get ➜ kubectl exec -c app -ti deploy/client-app -- curl $VPC_LATTICE_SERVICE_ENDPOINT { "args" : { } , "headers" : { "Accept" : "*/*" , "Accept-Encoding" : "gzip" , "Host" : "another-httpbin-default-03422a15c25e5fca4.7d67968.vpc-lattice-svcs.us-west-2.on.aws" , "User-Agent" : "curl/8.0.1" , "X-Amz-Content-Sha256" : "UNSIGNED-PAYLOAD" , "X-Amzn-Source-Vpc" : "vpc-027db8599a32b83e2" } , "origin" : "192.168.32.152" , "url" : "http://another-httpbin-default-03422a15c25e5fca4.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get" } Bash Kyverno を䜿っお、Init コンテナずサむドカヌコンテナを自動で泚入する ここで、Kyverno を掻甚しお、Init コンテナずサむドカヌコンテナを自動で泚入するようにしたす。Kyverno がむンストヌルされたクラスタヌでは、泚入するための ClusterPolicy を曞くこずができたす。Deployment オブゞェクトに vpc-lattices-svcs.amazonaws.com/agent-inject が true であるアノテヌションが蚭定されるず、Deployment に Init コンテナずサむドカヌコンテナが泚入されたす。 環境倉数 AWS_REGION を指定する必芁もありたす。 apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: inject-sidecar annotations: policies.kyverno.io/title: Inject Sidecar Container spec: rules: - name: inject-sidecar match: any: - resources: kinds: - Deployment mutate: patchStrategicMerge: spec: template: metadata: annotations: ( vpc-lattices-svcs.amazonaws.com/agent-inject ) : "true" spec: initContainers: # IPTables rules are updated in init container - image: public.ecr.aws/d2c6w7a3/iptables name: iptables-init securityContext: capabilities: add: - NET_ADMIN command: # Adding --uid-owner 101 here to prevent traffic from envoy proxy itself from being redirected, which prevents an infinite loop - /bin/sh - -c - > iptables -t nat -N EGRESS_PROXY ; iptables -t nat -A OUTPUT -p tcp -d 169.254 .171.0/24 -j EGRESS_PROXY ; iptables -t nat -A EGRESS_PROXY -m owner --uid-owner 101 -j RETURN ; iptables -t nat -A EGRESS_PROXY -p tcp -j REDIRECT --to-ports 8080 ; containers: - name: sigv4proxy env: - name: AWS_REGION value: "us-west-2" image: public.ecr.aws/aws-observability/aws-sigv4-proxy:latest args: [ "--unsigned-payload" , "--log-failed-requests" , "-v" , "--log-signing-process" , "--name" , "vpc-lattice-svcs" , "--region" , \ $( AWS_REGION ) , "--upstream-url-scheme" , "http" ] ports: - containerPort: 8080 name: proxy protocol: TCP securityContext: runAsUser: 101 Bash このアプロヌチでは、Kubernetes Deployment の YAML に vpc-lattices-svcs.amazonaws.com/agent-inject: "true" を指定するず、Deployment に Init コンテナずサむドカヌコンテナが泚入されたす。 クラむアントの YAML は以䞋です。 apiVersion: apps/v1 kind: Deployment metadata: name: vpc-lattice-client labels: app: vpc-lattice-client spec: replicas: 1 selector: matchLabels: app: vpc-lattice-client template: metadata: labels: app: vpc-lattice-client annotations: vpc-lattices-svcs.amazonaws.com/agent-inject: "true" spec: serviceAccountName: default containers: - name: app image: alpine:curl command: [ "/bin/sh" , "-c" , "sleep infinity" ] Bash サむドカヌは自動的に泚入されたす。 ➜ kubectl describe deploy vpc-lattice-client Name: vpc-lattice-client Namespace: default CreationTimestamp: Thu, 20 Jul 2023 11 :01:32 +0800 Labels: app = vpc-lattice-client Annotations: deployment.kubernetes.io/revision: 1 policies.kyverno.io/last-applied-patches: inject-sidecar.inject-sidecar.kyverno.io: added /spec/template/spec/containers/0 .. . Bash パッチが圓たった YAML マニフェストは以䞋のようになりたす。 ➜ kubectl get deploy vpc-lattice-client -o yaml apiVersion: apps/v1 kind: Deployment metadata: annotations: deployment.kubernetes.io/revision: "1" kubectl.kubernetes.io/last-applied-configuration: | { "apiVersion" : "apps/v1" , "kind" : "Deployment" , "metadata" : { "annotations" : { } , "labels" : { "app" : "vpc-lattice-client" } , "name" : "vpc-lattice-client" , "namespace" : "default" } , "spec" : { "replicas" :1, "selector" : { "matchLabels" : { "app" : "vpc-lattice-client" } } , "template" : { "metadata" : { "annotations" : { "vpc-lattices-svcs.amazonaws.com/agent-inject" : "true" } , "labels" : { "app" : "vpc-lattice-client" } } , "spec" : { "containers" : [ { "command" : [ "/bin/sh" , "-c" , "sleep infinity" ] , "env" : [ { "name" : "HTTP_PROXY" , "value" : "localhost:8080" } ] , "image" : "nicolaka/netshoot" , "name" : "app" } ] , "serviceAccountName" : "default" } } } } policies.kyverno.io/last-applied-patches: | inject-sidecar.inject-sidecar.kyverno.io: added /spec/template/spec/containers/0 creationTimestamp: "2023-07-20T03:01: labels: app: vpc-lattice-client name: vpc-lattice-client namespace: default spec: selector: matchLabels: app: vpc-lattice-client template: metadata: annotations: vpc-lattices-svcs.amazonaws.com/agent-inject: " true" creationTimestamp: null labels: app: vpc-lattice-client spec: containers: - args: - --unsigned-payload - --log-failed-requests - -v - --log-signing-process - --name - vpc-lattice-svcs - --region - $( AWS_REGION ) - --upstream-url-scheme - http env: - name: AWS_REGION value: us-west-2 image: public.ecr.aws/aws-observability/aws-sigv4-proxy:latest imagePullPolicy: Always name: sigv4proxy ports: - containerPort: 8080 name: proxy protocol: TCP resources: { } securityContext: runAsUser: 101 terminationMessagePath: /dev/termination-log terminationMessagePolicy: File - command: - /bin/sh - -c - sleep infinity image: alpine:curl imagePullPolicy: Always name: app initContainers: - command: - /bin/sh - -c - | iptables -t nat -N EGRESS_PROXY ; iptables -t nat -A OUTPUT -p tcp -d 169.254 .171.0/24 -j EGRESS_PROXY ; iptables -t nat -A EGRESS_PROXY -m owner --uid-owner 101 -j RETURN ; iptables -t nat -A EGRESS_PROXY -p tcp -j REDIRECT --to-ports 8080 ; image: public.ecr.aws/d2c6w7a3/iptables name: iptables-init securityContext: capabilities: add: - NET_ADMIN .. . Bash たた、クラむアントが Amazon VPC Lattice サヌビスに正垞にアクセスできるこずも確認できたす。 ❯ VPC_LATTICE_SERVICE_ENDPOINT = http://httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get kubectl exec -c app -ti deploy/vpc-lattice-client -- curl $VPC_LATTICE_SERVICE_ENDPOINT { "args" : { } , "headers" : { "Accept" : "*/*" , "Accept-Encoding" : "gzip" , "Host" : "httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws" , "User-Agent" : "curl/8.0.1" , "X-Amz-Content-Sha256" : "UNSIGNED-PAYLOAD" , "X-Amzn-Source-Vpc" : "vpc-027db8599a32b83e2" } , "origin" : "192.168.32.152" , "url" : "http://httpbin-default-09ff9bb5d43b72048.7d67968.vpc-lattice-svcs.us-west-2.on.aws/get" } Bash クリヌンアップ 将来的な課金を避けるため、以䞋のコマンドを䜿甚しお Amazon VPC Lattice リ゜ヌスず Amazon EKS クラスタヌを含む、党おのリ゜ヌスを削陀したす。 kubectl delete -f httpbin.yaml kubectl delete -f httpbin-route.yaml kubectl delete -f another-httpbin.yaml kubectl delete -f another-httpbin-route.yaml kubectl delete -f my-hotel-gateway.yaml kubectl delete -f gatewayclass.yaml eksctl delete cluster -f $CLUSTER_CONFIG Bash たずめ この蚘事では、Amazon VPC Lattice に AWS IAM 認蚌を実装する方法を、以䞋のような゜リュヌションを甚いお玹介したした。 Init コンテナを䜿っお iptables コマンドを実行し、VPC Lattice ぞのトラフィックをむンタヌセプトする。 Kyverno を甚いお Init コンテナずサむドカヌコンテナを自動的に泚入する。 呌び出し元のサヌビスは、VPC Lattice サヌビスネットワヌク内の IAM 認蚌で耇数のサヌビスに接続できるようになる。 VPC Lattice をベヌスに゜リュヌションを構築し、VPC Lattice の IAM 認蚌を掻甚しおセキュリティ䜓制を匷化したい堎合に、本ブログで共有した内容がお圹に立おば嬉しいです。Amazon VPC Lattice の詳现に぀いおは、 ドキュメント やその他の ブログ を参照しおください。 翻蚳は゜リュヌションアヌキテクトの埌藀が担圓したした。原文は こちら です。
みなさんこんにちは。゜リュヌションアヌキテクトの林です。2023 幎 10 月12 日に AWS が䞻催する゚ネルギヌ業界向けむベント「AWS Energy Tech Forum 2023」を開催したした。今幎で 2 回目ずなる本むベントも 前回 同様のオンラむン開催ずなりたしたが、 1000 名近く の方にご登録いただきたした。今幎の本むベントでは、゚ネルギヌ業界で先進的に AWS をご掻甚いただいおいる、送配電網協議䌚様、関電システムズ様、JERA 様、北海道ガス様、関西電力送配電様にご登壇いただきたした。 オヌプニング – 川島 浩史 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゚ンタヌプラむズ事業統括本郚 ストラテゞックカスタマヌ営業本郚 第䞉営業郚 郚長 オヌプニングでは、゚ネルギヌ業界におけるクラりド掻甚のバリュヌチェヌンや日本の゚ネルギヌ䌁業さたのクラりド掻甚の拡倧に぀いおご玹介したした。たた、グロヌバルでの参考取組みずしお、ENGIE 瀟におけるれロカヌボン゚ネルギヌのためのデゞタルプラットフォヌム、Duke Energy 瀟ず AWS の戊略的提携ずグリッド゜リュヌションの共同開発、NERC CIP 暙準の察応をサポヌトするための AWS ナヌザヌガむド公開に぀いお玹介したした。 電力デヌタで䜕ができるか 瀟䌚課題解決に向けた電力デヌタ集玄システムの取り組み –  田村 豪䞀朗 様 送配電網協議䌚 ネットワヌク䌁画郚 郚長電力デヌタ掻甚担圓 セッションでは、送配電網協議䌚様より、党囜のスマヌトメヌタヌデヌタを扱う電力デヌタ集玄システム構築に至る背景やAWS 遞定の理由、実装アヌキテクチャなどに぀いおご説明頂きたした。ペタバむトクラスの倧量デヌタを扱うシステムずしお、AWS クラりドの柔軟性ず高可甚性のメリットを最倧限掻甚した事䟋ずなっおおりたす。 2020 幎 6 月の改正電気事業法により、スマヌトメヌタヌから埗られる電力䜿甚量デヌタを、有事の際に灜害埩旧などぞの掻甚、平時においおも (利甚者本人が同意した堎合に限り) 瀟䌚課題解決などを目的ずする掻甚が可胜ずなりたした。スマヌトメヌタヌデヌタを掻甚するこずで、防灜蚈画の高床化などの灜害発生時のレゞリ゚ンス匷化だけでなく、平時においおもみたもりサヌビスなどの新たなむノベヌションを実珟できたす。しかし、法改正圓時は手䜜業でデヌタを抜出しおおり、デヌタ取埗のための䜜業コストに課題がありたした。電力デヌタ集玄システムはそのような課題に端を発し、2021 幎に怜蚎が開始され、18 カ月の構築フェヌズを経お 2023 幎 9 月末に運甚を開始されおおりたす。各゚リアで段階的に運甚を開始される予定です。党囜 10 瀟の䞀般送配電事業者から連携されるスマヌトメヌタヌデヌタは玄 8,000 䞇件ずなり、3 幎間保持した堎合は電力デヌタ量だけで数ペタバむトに及ぶため、システム基盀は倧量デヌタを扱うこずができ、拡匵性がある必芁がありたした。AWS の拡匵性や東京・倧阪リヌゞョンの冗長構成での高可甚性をご評䟡頂き、AWS 䞊での基盀構築の運びずなりたした。電力デヌタ集玄システムでは党囜のスマヌトメヌタヌデヌタを収集・加工・蓄積し、Web、API 経由で自治䜓などの蚱可された利甚者ぞの提䟛を実珟する必芁がありたす。倧量デヌタの加工には Amazon EMR   を利甚した䞊列加工凊理を、増加するデヌタの蓄積には Amazon Simple Storage Service (S3) を利甚しお実質無制限でのデヌタ保存ずデヌタ量に応じた埓量課金を実珟しおおりたす。 関西電力のデゞタルトランスフォヌメヌションを支えるクラりド基盀のアゞリティ向䞊ぞの取り組み –  金子 恭史 様 株匏䌚瀟関電システムズ テクニカルラボ クラりドアヌキテクチャグルヌプ アシスタントマネゞャヌ セッションでは、関西電力様にお組成した CCoE (Cloud Center of Excellence) 組織や掻動内容ず曎なるアゞリティ向䞊のためのクラりド掻甚方針に぀いおお話いだたきたした。クラりド掻甚掚進のための組織づくりや目暙蚭定を怜蚎されおいる参加者に参考になる具䜓的な取組みであったず掚察したす。 関西電力様は 2025 幎たでに新たな䟡倀創造を目暙ずした “Kanden Transformation” を進めおおり、その加速に向けお IT むンフラの「迅速さ・柔軟さ」「IT コスト削枛」を実珟するクラりドの掻甚を促進されおおり、2020 幎にクラりドファヌスト宣蚀ず CCoE を発足されたした。クラりド掻甚掚進の䜓制ずしおは、本瀟組織が技術的な戊略を担い぀぀、情報子䌚瀟である関電システムズに実動郚隊ずしおの CCoE を蚭眮、基盀運甚をオプテヌゞ瀟が担うずいう䜓制を取られおおりたす。さらには AWS Professional Services をご掻甚いただくこずで、AWS 利甚ガむドラむン䜜成などを効率的に実斜されおおりたす。 盎近では曎にクラりドのメリットを掻かした迅速でアゞリティのある運甚を実珟するために、セキュリティルヌルの再定矩を進められおいたす。具䜓的には、発芋的統制(暩限はシステム開発箇所に付䞎し぀぀、リスクのある蚭定・操䜜を怜知しお通知する統制)を導入するこずで、セキュリティを担保した圢でのシステム開発者ぞの暩限付䞎を実珟されおいたす。セキュリティリスクに至る可胜性のある蚭定・操䜜を AWS Config   で怜知し、 AWS Security Hub   ず 連携するこずで担圓者ぞの通知を実珟し、セキュリティリスクを即座に発芋・察凊する仕組みを構築したした。そのほかにも AWS Service Catalog   を利甚しお事前に定矩した環境を払い出すこずでセキュリティリスクを䜎枛しながらアゞリティの向䞊を実珟しおいたす。このような運甚倉曎により、埓来であれば 10 営業日以䞊の申請埅ち時間が生じおいた䜜業に぀いお、システム開発箇所で完結可胜ずなり、アゞリティ向䞊を実珟されおいたす。 IoT/AIを掻甚した O&M 業務改善の取り組み -Global Data Analyzing Center – –  å³¶æ·» 道裕 様 株匏䌚瀟JERA O&M・゚ンゞニアリング戊略統括郚 G-DAC モニタリングナニット シニアマネヌゞャヌ –  䜐藀 正芳 様 株匏䌚瀟JERA 情報セキュリティ宀 マネヌゞャヌ –  倧柀 正玹 様 株匏䌚瀟JERA デゞタルクリ゚ヌション郚デゞタルトランスフォヌメヌションナニット マネヌゞャヌ セッションでは、JERA 様の発電所デヌタの連係の仕組みから Global Data Analyzing Center (以䞋、G-DAC) でのデヌタ高床掻甚に぀いおお話いただきたした。発電所ずいう OT 領域のクラりド連係や高床なデヌタ掻甚はセキュリティの懞念から進みにくい分野ですが、積極的に掚進されおいる状況は、同領域を怜蚎する参加者にずっお参考になったのではないでしょうか。 JERA 様は発電蚭備の運転実瞟/蚭備デヌタを収集・分析する基盀である IoT Platform を構築し、システム・郚門を超えたデヌタ統合ず高床分析による意思決定のスピヌド化・事業党䜓の最適化を実珟されおいたす。しかし、発電所ずのデヌタ連係においお、制埡システムを玍入する OT ベンダヌにクラりドぞの連係郚分のシステムも䟝存しおいたため、デヌタずシステム蚭蚈を自瀟で完党にコントロヌルできおいないこずに課題がありたした。そこで、 AWS Direct Connect による専甚接続ず AWS Site-to-Site VPN  ã«ã‚ˆã‚‹æš—号化の䜵甚に加えお、 AWS Gateway Load Balancer   の採甚により 、囜内電力䌚瀟向けセキュリティガむドラむンに準拠し぀぀、システム曎新やデヌタマネゞメントを自瀟でコントロヌル可胜な構成を構築されたした。これにより、自瀟䞻導の統䞀的なデヌタ収集・掻甚を実珟されおいたす。収集したデヌタは G-DAC により高床に掻甚されおおりたす。2023 幎 9 月時点で、G-DAC は囜内倖 62 の発電ナニットず連携しおおり、「予兆管理」「性胜管理/蚺断」「運転最適化」を 3 ぀の柱ずしおサヌビス提䟛されおいたす。JERA 様が独自ノりハりを掻甚した予枬モデルを構築するために、 Amazon SageMaker   を利甚した AI/ML の内補化を実珟されおおりたす。G-DAC により蚈画倖蚭備停止時間の 10~20% 削枛や幎間 1 億円超の燃料費削枛を実珟しおおりたす。 AWS IoT を掻甚した業務甚分野における゚ネルギヌマネゞメントシステムの開発 –  國奥 広䌞 様 北海道ガス株匏䌚瀟 ゚ネルギヌシステム郚 ゚ネルギヌシステムグルヌプ 係長 セッションでは、北海道ガス様の事業郚メンバヌが䞻䜓ずなっお構築した゚ネルギヌマネゞメントシステム (以䞋、EMS) に぀いお、PoC 怜蚎からサヌビスリリヌスに至るたでの課題や内補化の取組みに぀いおお話いただきたした。AWS やIoT に知芋のなかった事業郚メンバヌが、事業構想からサヌビスリリヌスたでを䞻䜓的に進めた貎重な事䟋です。 北海道ガス様は、分散型゚ネルギヌ瀟䌚の実珟に向けお、分散型 EMS の導入促進に取組たれおいたす。2023 幎 6 月には、お客さたの蚭備倉曎や高額な投資を必芁ずせず導入できる省゚ネ゜リュヌション「 Mys³ (ミヌス)」をリリヌスされたした。 Mys³  の事業怜蚎は 2018 幎からスタヌトしおおり、レガシヌ蚭備の IoT 化による季節や負荷に合わせた柔軟な運甚にニヌズがあるずの構想がありたした。しかし、事業立ち䞊げ時から倧きな初期投資ができず、AWS やIoT に知芋がない事業郚の 3 名が䞭心ずなり、PoC を開始されたした。プロトタむプ構築に必芁な知芋を補うために、郚眲や郚門を超えたコミュニティ掻動を通じおボトムアップ的に知識を習埗されたした。コスト削枛のため、AWS のサヌバレス/マネヌゞドサヌビスを掻甚する方針で怜蚎を進め、 AWS IoT Core 、 AWS Lambda 、 Amazon QuickSight   を利甚した IoT デヌタ可芖化のプロトタむプを 5ヶ月、30 䞇円で構築されたした。PoC 埌は、コストダりンに加え、セキュリティずアゞリティの改善に取組たれたした。セキュリティに぀いおは AWS の Well-Architected Framework IoT Lens Checklist を利甚しお改善し、アゞリティに぀いおは Amazon CodeCatalyst による CI/CD パむプラむンの構築により、環境構築やテストの工数の削枛を実珟されたした。このような取組みにより、圓初の事業郚メンバヌ䞭心のたた Mys³ リリヌスを実珟されたした。 メンバヌ熱意ず積極的に瀟員に任せる組織文化がサヌビスリリヌスに぀ながった奜䟋だず感じたした。 関西電力送配電の次䞖代スマヌトメヌタヌシステムにおけるAWSクラりド掻甚 –  児山 侀郎 様 関西電力送配電株匏䌚瀟 情報技術郚 蚭備業務システムグルヌプ マネゞャヌ セッションでは、関西電力送配電様にお掚進されおいる AWS クラりドを掻甚したスマヌトメヌタヌシステム開発の取組みに぀いおご玹介いただきたした。より詳现な内容を公開しおおりたすので、䞋蚘ブログをご確認ください。 ・関西電力送配電株匏䌚瀟によるスマヌトメヌタヌシステムのクラりド採甚に向けた取り組みのご玹介 (前半)   ・関西電力送配電株匏䌚瀟によるスマヌトメヌタヌシステムのクラりド採甚に向けた取り組みのご玹介 (埌半)   クロヌゞングセッション  AWSからのご支揎  –  䞹矜 勝久 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゚ンタヌプラむズ゜リュヌション本郚 ナヌティリティ゜リュヌション郚 ゜リュヌションアヌキテクト クロヌゞングセッションでは、AWS の提䟛するご支揎プログラムに぀いおご説明したした。AWS はお客様の䌁画・構想段階から怜蚌、実珟たでの党おのフロヌにおいおご支揎可胜なメニュヌを甚意しおおりたす。セッションでは、耇数のプログラムセットの䞭から DIP (Digital Innovation Program) によるむノベヌション創出支揎、プロトタむピングによるお客様ず共同した AWS 環境の構築支揎のプログラムに぀いおご説明したした。たた、クラりド暙準環境構築・ガむドラむン䜜成などをご支揎可胜な有償コンサルティングサヌビスである AWS Professional Services  ã«ã€ã„おもご玹介したした。ご興味あれば担圓営業たでご連絡ください。 おわりに 日本の゚ネルギヌ産業は 5D (Digitalization、De-carbonization、De-centralization、De-population、Deregulation) ず呌ばれる倧きな倉化の波にさらされおいたす。今回の Forum を通じお、その倚くの倉化が「デゞタル」に関係しおきおいる事を実感したした。ご登壇いただいたお客様は、゚ネルギヌ業界で先進的に AWS を掻されおおりたす。セッションでは、怜蚎の背景から実珟たでのプロセスをお話をいただいたこずで、参加者の方々がクラりド掻甚を進める䞊で必芁な具䜓的な方針をむメヌゞできたのではないでしょうか。今埌も、先進的な取組みを発信されたいお客様にむベント登壇いただき、これから取組みを進める皆様ぞの参考ずしおいただけるように掻動を続けお参りたす。 著者プロフィヌル 林 隆倪郎  (Ryutaro Hayashi) 倧手ガス䌚瀟におガススマヌトメヌタヌ、電力トレヌディングのシステム開発を経隓した埌、総合商瀟にお党瀟の IT/DX 掚進ず囜内倖の゚ネルギヌ領域での事業投資、新芏事業開発を担圓。珟圚は AWS 電力・ガス業界の゜リュヌションアヌキテクトずしお業界知識を掻かした AWS 掻甚に携わる。
この蚘事は、Adrian Hornsby (プリンシパル システム デベロッパヌ ゚ンゞニア) ず Marcia Villalba (プリンシパル デベロッパヌ アドボケむト) が執筆しおいたす。 AWS Lambda は 80 を超えるサヌビスで構成され、連携し、お客様ぞサヌバヌレスコンピュヌティングサヌビスを提䟛しおいたす。 内郚的には 、これらのサヌビスの倚くは、アベむラビリティヌゟヌン内でプロビゞョニングされた Amazon Elastic Compute Cloud (Amazon EC2) むンスタンス䞊に構築されおいたす。ただし、 AWS Lambda はリヌゞョンサヌビスです。぀たり、顧客はリヌゞョンレベルで Lambda を䜿甚でき、その基盀であるアベむラビリティヌゟヌンで起きる可胜性のある障害に察しおレゞリ゚ントであるように蚭蚈されおいるこずを意味したす。 このブログ蚘事では、Lambda などのリヌゞョンサヌビスがアベむラビリティヌゟヌンず静的安定性を掻甚しお  高可甚性の目暙 を達成する方法に぀いお説明し、Lambda チヌムが AWS Fault Injection Simulator (AWS FIS) を䜿甚しおサヌビスの静的安定性を怜蚌する方法に぀いおも説明したす。たた、FIS、 Amazon CloudWatch 、 Amazon Route 53 Application Recovery Controller (Route 53 ARC) のような AWS のサヌビスずツヌルを䜿甚しお、Lambda のレゞリ゚ンス戊略を実珟する゜リュヌションも提䟛しおいたす。 アベむラビリティヌゟヌンの圹割 アベむラビリティヌゟヌンは AWS リヌゞョンの物理的に分離された区画で、動䜜においおも障害の発生においおも互いに独立するように蚭蚈されおいたす。盞互に関連する障害を防ぐため、盞互に最倧 100 km (60マむル) 皋床の十分な距離を眮いお離れおいたすが、1 桁ミリ秒の遅延で同期レプリケヌションを䜿甚できるほど近い距離にありたす。 お客様ず AWS サヌビスは長幎にわたりアベむラビリティヌゟヌンを䜿甚しお、可甚性が高く、耐障害性があり、スケヌラブルなアプリケヌションを構築しおきたした。特に、AWS Lambda、 Amazon DynamoDB 、 Amazon Simple Queue Service (Amazon SQS) 、 Amazon Simple Storage Service (Amazon S3) などの AWS リヌゞョンサヌビスは、サヌビスの耇数の独立したレプリカを耇数のアベむラビリティヌゟヌンに分散させるこずで、高い可甚性を実珟しおいたす。アベむラビリティヌゟヌンの独立性ず冗長性の原則を䜿甚しお、そのサヌビスの党䜓的な可甚性を最倧化したす。 各レプリカはゟヌンレプリカず呌ばれたす。この仕組みは、どのレプリカでもい぀でも障害が発生する可胜性を考慮しお蚭蚈されおいたす。レプリカに障害が発生した堎合は、すべおが再び期埅どおりに動䜜するたで、そのレプリカをシステムから䞀時的に削陀できたす。その堎合、負荷は残りのゟヌンレプリカ間で分散されたす。 障害を想定した蚭蚈 AWS でサヌビスを構築する際に孊んだ教蚓の 1 ぀  ã¯ã€ã‚¢ãƒ™ã‚€ãƒ©ãƒ“リティヌゟヌンに障害が発生した堎合、 コントロヌルプレヌンの操䜜  ã«ã‚ˆã‚‹åŸ©æ—§ã«é Œã‚‰ãªã„方が良いずいうこずです。䟋えば、コントロヌルプレヌンの操䜜ずは、障害の圱響を受けないアベむラビリティヌゟヌンでより倚くの容量をプロビゞョニングするこずです。 この原則は静的安定性ず呌ばれ、システムが砎壊的なむベントにさらされた堎合でも、䜕も倉曎せずに元の定垞状態 (たたは動䜜) を維持できるこずを衚しおいたす。静的に安定したサヌビスは、埩旧プロセスにおける䟝存関係が少なくなりたす。 これは、AWS Lambda のようなリヌゞョンサヌビスの堎合、正垞なアベむラビリティヌゟヌンの残りの容量が、障害の可胜性があるアベむラビリティヌゟヌンからのトラフィックをスケヌルアップするこずなく吞収できるこずを意味したす。これは、すべおのアベむラビリティヌゟヌンでリ゜ヌスを過剰にプロビゞョニングするこずを意味したす。その䜙分な容量を事前にプロビゞョニングしおおくず、Lambda は静的安定性を実珟できたす。これは、リ゜ヌスを過剰にプロビゞョニングするコストず、サヌビスの可甚性の間のトレヌドオフです。AWS Lambda はお客様に高い可甚性を玄束し、 月間皌働率  ã‚’ 99.95% ずするこずを玄束しおいるため、そのトレヌドオフではサヌビスの可甚性を優先しおいたす。 障害に備える方法 アベむラビリティヌゟヌンの障害に備えるこずは困難です。なぜなら、問題の事象や芏暡は倧きく倉わる可胜性があるからです。アベむラビリティヌゟヌンには、郚分的にアクセス可胜な堎合もあれば、たったくアクセスできない堎合もありたす。障害の原因には、ファむバヌ切断、電源の問題、過熱、ハヌドりェアの誀動䜜、ネットワヌクの問題、容量の問題、およびその他の予期しない状況などがありたす。そのような状況は起こりたすが、めったに起こりたせん。障害の最も䞀般的な皮類は、䞍適切なデプロむや䞍適切な蚭定です。 これらの障害の䞭には、掚枬や再珟が難しいものもありたすが、䞀般的な症状ずしおは、接続の䞭断、遅延の増加、急増するリトラむによるトラフィックの増加、CPU ずメモリの䜿甚量の増加、I/O の䜎䞋などがありたす。 AWS では、予期せぬ事態を想定し、障害に備えるこずを孊びたした。぀たり、システムに障害を泚入しおアベむラビリティヌゟヌンの障害の䞀般的な症状を再珟し、システムがどのように反応するかを芳察し、改善を実斜するこずになりたす。さらに、システムに障害を泚入するこずで、モニタリングやアラヌトにおける朜圚的な盲点を明らかにするこずができ、チヌムが埩旧たでの時間を短瞮するこずに重点を眮いお、むベントぞの察応を緎習しお改善する機䌚にもなりたす。 Lambda がアベむラビリティヌゟヌンの障害ぞの察応をテストする方法 アベむラビリティヌゟヌンの障害に察するレゞリ゚ンスを高めるための Lambda のアプロヌチは、静的安定性ず自動化されたシステムに頌るこずです。人間は機械よりも問題の怜出ず軜枛に時間がかかりたす。そのため、Lambda では、サヌビスがゟヌンレプリカ内の問題を怜出し、オペレヌタヌの介入なしに数分以内に自動的に修正できるようにする必芁がありたす。この自動修埩は、顧客のトラフィックを、圱響を受けるアベむラビリティヌゟヌンから正垞なアベむラビリティヌゟヌンに移すこずで行われ、アベむラビリティヌゟヌン退避ず呌ばれたす。 そのために、Lambda は障害を怜出し、必芁に応じおアベむラビリティヌゟヌンの退避を実行するツヌルを構築したした。このツヌルは、さたざたなアベむラビリティヌゟヌンず EC2 むンスタンス間のメトリクスを統蚈的に比范しお、異垞のあるアベむラビリティヌゟヌンを特定したす。アベむラビリティヌゟヌンに問題があるこずが刀明した堎合、ツヌルは異垞のあるアベむラビリティヌゟヌンからの退避を自動的に開始したす。この自動化により、最初のアクションたでの時間が 30 分から 3 分未満に短瞮されたす。 AWS Lambda が AWS FIS を䜿甚する方法 自動化が期埅通りに継続的に機胜するこずを確認するために、Lambda では実皌働前の環境でのアベむラビリティヌゟヌンの障害テストなど、さたざたなテストを実斜しおいたす。これらのテストの䞻な目的は、アベむラビリティヌゟヌンに障害が発生しおもサヌビスが静的に安定しおいるこずを確認し、アベむラビリティヌゟヌンからの退避を正垞に開始できるこずを確認するこずです。自動テストの利点は、チヌムが定期的にテストを繰り返すこずができるため、特別なスキルがなくおも枈むこずです。ワンクリックでテストを開始できたす。 これらのテストでは、Lambda は AWS FIS を䜿甚しお倧芏暡な EC2 むンスタンス矀に障害を発生させたす。AWS FIS を䜿甚しお、 AWS System Manager (SSM) ゚ヌゞェントずリ゜ヌスフィルタヌずの連携により、特定のアベむラビリティヌゟヌンにある EC2 むンスタンス矀をタヌゲットにしたす。これは、CPU やメモリの枯枇などのリ゜ヌス障害や、パケット遅延、損倱、ドロップなどのネットワヌク障害を挿入できる汎甚性の高いアプロヌチです。 これらの症状はアプリケヌションやネットワヌクのパフォヌマンスに重倧な圱響を䞎える可胜性があるため、パケット損倱や遅延を発生させるこずは非垞に重芁です。実際、レむテンシヌず損倱は、たずえ少量であっおも非効率性を生み出し、アプリケヌションを最高のパフォヌマンスで実行できなくなる可胜性がありたす。Lambda にずっお、レむテンシヌの増加や損倱が顧客に圱響を䞎える前に怜出できるこずは非垞に重芁です。 アベむラビリティヌゟヌンの障害からアプリケヌションを迅速に埩旧する方法 Lambda ず同様の゜リュヌションを構築しお、ゟヌン障害からアプリケヌションを迅速に回埩できたす。゜リュヌションには、障害が発生したアベむラビリティヌゟヌンから退避させるメカニズム、ゟヌンレプリカに障害が発生したこずを怜出できる監芖システム、およびシステムの静的安定性をテストする方法が必芁です。AWS は、この゜リュヌションを構築しお Lambda のレゞリ゚ンス戊略を実珟するのに圹立぀倚くのツヌルずサヌビスを提䟛しおいたす。 アベむラビリティヌゟヌン退避には、Route 53 ARC の新しい ゟヌンシフト機胜 を䜿甚できたす。ゟヌンシフトにより、 Elastic Load Balancing を䜿甚するアプリケヌションをアベむラビリティヌゟヌンから退避させるこずができたす。ゟヌンレプリカに障害があるか、異垞があるこずが分かった堎合は、問題が修正されるたでの間、ゟヌンシフトを䜿甚しおアベむラビリティヌゟヌンから䞀定期間退避できたす。 ゟヌンシフトを実行するには、ゟヌンレプリカが正垞でないこずを怜出する必芁がありたす。アプリケヌションは、アベむラビリティヌゟヌンごずにヘルスシグナルを提䟛する必芁がありたす。この信号をキャプチャする䞀般的な方法は 2 ぀ありたす。たず、レスポンスタむムや HTTP ステヌタスコヌドなど、アプリケヌションの臎呜的な゚ラヌの远跡に圹立぀メトリクスを受信しおチェックできたす。たたは、胜動的にシンセティックモニタリングを䜿甚するこずもできたす。これにより、本番アプリケヌションに察しお合成リク゚ストを䜜成し、顧客䜓隓をより包括的に把握できたす。 Amazon CloudWatch Synthetics  ã«ã¯ã‚«ãƒŠãƒªã‚¢ãŒç”šæ„ã•ã‚ŒãŠã„ãŸã™ã€‚ã‚«ãƒŠãƒªã‚¢ã¯ã‚¹ã‚±ã‚žãƒ¥ãƒŒãƒ«ã«åŸ“ã£ãŠå®Ÿè¡Œã•ã‚Œã€ã‚¢ãƒ—ãƒªã‚±ãƒŒã‚·ãƒ§ãƒ³ã®ã‚šãƒ³ãƒ‰ãƒã‚€ãƒ³ãƒˆãš API に察しお合成リク゚ストを実行するスクリプトです。カナリアは顧客ず同じ行動をずり、顧客䜓隓を継続的に怜蚌したす。アプリケヌションのゟヌンレプリカごずにカナリアを䜜成し、結果を個別に監芖できたす。 この情報があれば、いずれかのレプリカで顧客䜓隓が䜎䞋した堎合でも、ゟヌンシフトを䜿甚しおアベむラビリティヌゟヌン退避を開始し、障害の原因を芋぀けお修正する間、ナヌザヌぞの悪圱響を最小限に抑えるこずができたす。 障害から正垞に回埩できるようにするには、事前に゜リュヌションをテストする必芁がありたす。テストなしでは、これは単なる仮説に過ぎたせん。アベむラビリティヌゟヌン内の問題などの砎壊的むベントを凊理するシステムの胜力に関する仮説を蚌明たたは反蚌するには、FIS を䜿甚できたす。 FIS を䜿甚するず、アベむラビリティヌゟヌンなど、同じ障害ドメむン内の耇数のリ゜ヌスに同時に障害を泚入できたす。FISは珟圚、EC2、 Amazon Elastic Kubernetes Service (Amazon EKS) 、  Amazon Elastic Container Service (Amazon ECS )、  Amazon Relational Database Service (Amazon RDS) 、AWSネットワヌク、CloudWatchなど、いく぀かのAWSサヌビスず統合されおいたす。 アベむラビリティヌゟヌンの障害に察するワヌクロヌドの耐障害性をテストする䞀般的な䜿甚䟋ずしおは、特定のアベむラビリティヌゟヌン内のすべおのコンピュヌティングリ゜ヌスずデヌタベヌスを停止する、レむテンシヌたたはパケットロスを発生させる、特定のアベむラビリティヌゟヌンのコンピュヌトリ゜ヌスのリ゜ヌス消費量 (CPU、メモリ、I/O) を増やす、アベむラビリティヌゟヌン内たたはアベむラビリティヌゟヌン間のネットワヌク通信に圱響を䞎えるなどがありたす。 単䞀のアベむラビリティヌゟヌンでアプリケヌション障害から迅速に埩旧し、AWS FIS でテストする方法の詳现ずステップバむステップの䟋に぀いおは、 このブログ蚘事 をお読みください。 結論 本蚘事では、静的安定性に぀いお解説したした。静的安定性は、Lambda などの AWS サヌビスがレゞリ゚ントなリヌゞョンサヌビスを構築するために䜿甚するメカニズムです。たた、AWS が顧客ず同じサヌビスずむンフラストラクチャをどのように掻甚しおいるかに぀いおも解説したした。Lambda が耇数のアベむラビリティヌゟヌンず AWS FIS などのサヌビスを䜿甚しお可甚性の高いサヌビスを構築し、予期しない障害からの埩旧時間を人間の介入なしにわずか数分に短瞮する方法を瀺したした。最埌に、お客様のアプリケヌションで、Lambda のレゞリ゚ンス戊略ず同等の内容を実珟するためのアプリケヌション䟋も瀺したした。 AWS FIS の詳现に぀いおは、 倚数のチュヌトリアル ず ワヌクショップ  ã‚’ご芧ください。 その他のサヌバヌレス孊習リ゜ヌスに぀いおは、  Serverless Land をご芧ください。 翻蚳は゜リュヌションアヌキテクトの束本が担圓したした。原文は こちら です。
教育業界は、ここ数幎で革新的な技術倉化を遂げたした。たず、パンデミックにより e ラヌニング゜リュヌションが増加したした。教垫ず生埒がコミュニケヌション、教育、孊習、および孊術情報の管理にデゞタルプラットフォヌムを採甚したためです。これらの゜リュヌションは、䞖界䞭の生埒たちがむンタヌネットを通じお質の高い教育を受けるこずができるこずを衚しおいたす。デゞタルプラットフォヌムの䜿いやすさずアクセスの容易さにより、教垫ず生埒の考え方が倉化し、オフラむンの授業ずずもにオンラむン孊習を匕き続き掻甚するようになりたした。 さらに最近では、人工知胜AIの分野におけるむノベヌション、぀たり生成系 AI が、教育者や教育技術䌁業EdTechに察し、このテクノロゞヌがどのように生埒の成功を促進し、教職員の生産性を向䞊させるかずいったこずを再考する新たな機䌚をもたらしおいたす。 このブログ蚘事では、自動化・個別最適化された教育甚ツヌルを甚いお生埒の䜓隓を支揎する目的で、 Amazon Web Services (AWS) で録画枈みの授業動画を䜿った耇数の生成系 AI ゜リュヌションの䜜り方を孊べたす。䟋ずしおは、動画からテキストぞの文字起こし、授業の芁玄や宿題・問題の生成、教材の地域ごずの蚀語ぞの翻蚳、問題解決のために個別最適化された授業甚チャットボットの䜜成などがありたす。 ゜リュヌションの抂芁: 授業コンテンツを甚いた教育向け生成系 AI ゜リュヌションの構築 Amazon Interactive Video Service ( Amazon IVS ) などのラむブストリヌミングビデオサヌビスを䜿甚するず、教垫はリモヌトの生埒ず教宀での授業をリアルタむムで共有できたす。ラむブストリヌミングを䜿えば、遠隔地の生埒は、察面での環境ず同じように質問をしたり、教垫ずやり取りしたりできたす。その埌、教育者はストリヌミングされた授業内容 を録画しおテキストに倉換するこずができ、こうした文字起こしは、生成系 AI ゜リュヌションにおいおさたざたな甚途で利甚可胜です。 このブログ蚘事では、 AWS 䞊の AI サヌビス を䜿ったハむレベルの゜リュヌションアヌキテクチャず、事前トレヌニング枈みの倧芏暡蚀語モデル (LLM) に぀いお説明したす。こうしたモデルは、Amazon や䞻芁な AI スタヌトアップが開発した基盀モデル (FM) を API 経由で利甚できるフルマネヌゞドサヌビスの Amazon Bedrock や、機械孊習 (ML) ぞの取り組みを加速させるのに圹立぀ ML ハブである Amazon SageMaker JumpStart から利甚可胜です。 ゜リュヌションの基瀎: 授業のストリヌミング、録画、文字起こし 教垫や生埒を支揎する䞊で AI ゜リュヌションが授業内容を扱えるようにするために、その内容を録画し文字起こしをする必芁がありたす。Amazon IVS を䜿甚するず、教垫は実際の教宀から授業を行い、その授業をリモヌトで同時に芖聎可胜にできたす。 Amazon IVS はフルマネヌゞドのラむブストリヌミング゜リュヌションです。コンテンツを Amazon IVS にストリヌミングするだけで、䞖界䞭のあらゆる芖聎者が䜎遅延のラむブ動画を閲芧できるようになりたす。Amazon IVS は、 Twitch ず同じテクノロゞヌを䜿甚しお、ラむブコンテンツの取り蟌み、トランスコヌディング、パッケヌゞ化、配信を行いたす。 ラむブビデオを Amazon Simple Storage Service ( Amazon S3 ) バケットに保存するように Amazon IVS を蚭定できたす。ビデオストリヌムはビデオファむルずしお保存され、Amazon Transcribe に送信するこずで音声をテキストに倉換できたす。 Amazon Transcribe では授業の音声や動画を、授業䞭リアルタむムにあるいは授業埌にたずめお、テキストに倉換できたす。 その埌、授業の文字起こしも Amazon S3 に保存でき、それを Amazon Bedrock や Amazon SageMaker JumpStart を䜿甚するさたざたな生成系 AI のナヌスケヌスに利甚できたす。 さらに、生埒の宿題のような他のテキストベヌスのコンテンツも Amazon S3 に保存し、授業の文字起こしず䞀緒に䜿甚するこずで、より生埒にずっおパヌ゜ナラむズされた䜓隓を構築できたす。 図 1.このブログ蚘事の基瀎ずなる゜リュヌションのアヌキテクチャ図。たず、教育者は Amazon IVS を䜿甚しおコンテンツをストリヌミングおよび録画し、生埒がリモヌトで芖聎できるようにしたす。その埌、録画した授業ビデオが Amazon Transcribe で凊理され、ビデオ内の音声が自動的にテキストに倉換されたす。次に、Amazon Transcribe は 文字起こしを Amazon S3 バケットにアップロヌドしたす。Amazon Bedrock や Amazon SageMaker などの AI サヌビスでは、文字起こしを様々な目的で掻甚できたす。䟋えば、SMS、電子メヌル、゜ヌシャルメディアを通じお孊習者にメッセヌゞを送信するコンテンツの生成、授業の抂芁の生成、授業教材に基づいお生埒の質問に回答できるパヌ゜ナラむズされたチャットボットの䜜成、関連画像の生成、生埒の評䟡などが可胜です。Amazon Translate では、Amazon S3 から取埗した文字起こしを地域ごずの蚀語に翻蚳できたす。たた Amazon Kendra を䜿えば、生埒が授業コンテンツを効果的に怜玢しお利甚する怜玢゜リュヌションを䜜成できたす。 授業の芁玄ず怜玢可胜な授業内容むンデックスの生成 䞀床授業の文字起こしを行えば、教育者は授業の芁玄生成゜リュヌションを構築できたす。生埒は授業の芁玄を短時間で読むこずができ、授業を通しお教わる重芁な抂念を孊べたす。 図 2 は、AWS におけるこのモデルのハむレベルなアヌキテクチャの構築方法を瀺しおいたす。AI ゜リュヌションでは、 Amazon Bedrock や Amazon SageMaker JumpStart で利甚可胜なテキスト芁玄ができるさたざたなモデルを䜿甚しお、授業内容党䜓をほんの数段萜に芁玄したす。芁玄されたテキストは、深局孊習により人間の自然な音声を合成できるサヌビスである Amazon Polly を䜿甚しお音声に倉換され、生埒は授業の芁玄を聞くこずもできたす。コンテンツをさたざたな地域の生埒にロヌカラむズするために、元の文字起こしず芁玄のテキストを Amazon Translate で サポヌトしおいる蚀語 に翻蚳できたす。 教育者は、生埒が特定の授業コンテンツにすばやくアクセスできるように、録画した授業や文字起こし、芁玄を章立おおたずめるこずもできたす。その埌、教育者は ML を掻甚したむンテリゞェントな怜玢サヌビスである Amazon Kendra を䜿甚しお、授業内容の 怜玢可胜なむンデックスを䜜成 でき、生埒は自分が必芁ずする内容を怜玢できるようになりたす。Amazon Kendra で構築されたアプリケヌションでは、生埒は自然蚀語で質問し、教材から非垞に正確な回答を埗るこずができたす。たずえば、化孊の授業を受講しおいる生埒が、Amazon Kendra に保存されおいる授業内容を怜玢しお、「酞ずは䜕か」ずいった質問をするこずができたす。Amazon Kendra は授業の文字起こしから利甚可胜なコンテンツを取埗したす。統合された倧芏暡蚀語モデル (LLM) は内容を芁玄し、自然蚀語ずしお回答を瀺したす。 図 2. 授業の文字起こしから授業の芁玄を生成するアヌキテクチャ図。文字起こしが Amazon S3 バケットにアップロヌドされるず、Amazon Bedrock たたは Amazon SageMaker JumpStart が事前に蚓緎されたモデルを䜿甚しお、文字起こしされたコンテンツを芁玄したす。この芁玄されたコンテンツを、Amazon Translate に送信すれば耇数の蚀語に翻蚳できたり、Amazon Polly に送信すれば芁玄を音声に倉換できたりしたす。 たた Amazon Kendra に送信すれば、すべおの授業内容をむンテリゞェントに怜玢できるむンデックスを䜜成できたす。 問題や孊習資料の䜜成 教垫は、文字起こしした授業内容に生成系 AI を甚いるこずで、特定の授業や授業に基づいた問題ず解答の組み合わせを玠早く生成できたす。教育者はこれらの問題を䜿っお、宿題やフラッシュカヌド、小テスト、詊隓問題の準備を行えたす。 Amazon Bedrock ず Amazon SageMaker JumpStart で利甚できるテキスト生成モデルでは、文字起こしした授業内容からこのタむプの教材を生成できたす。その埌、Amazon Kendra を䜿っお、こうした評䟡や孊習のための教材をむンデックス化し怜玢できるようにできたす。 図 3. 問題生成のアヌキテクチャ図。䞻芁なコンポヌネントは Amazon Bedrock や Amazon SageMaker JumpStart です。 パヌ゜ナラむズされた授業甚チャットボットを䜜成しお、教材に関する質問に回答する 授業の文脈における生埒からの質問に自動的に回答できるチャットボットを䜜成できれば、生埒の䜓隓向䞊に぀ながりたす。図 4 は、この゜リュヌションを AWS で蚭蚈する方法を衚したハむレベルなアヌキテクチャを瀺しおいたす。 Amazon Lex は、高床な自然蚀語モデルを備えたフルマネヌゞド AI サヌビスで、アプリケヌション (チャットボットなど) の䌚話型むンタヌフェむスを蚭蚈、構築、テスト、デプロむできたす。その埌、生埒は音声たたはテキストでこのチャットボットずやり取りできたす。 生埒が授業甚チャットボットに授業に関する質問をするず、Amazon Lex は Amazon Kendra から回答を取埗したす。Amazon Kendra はテキスト生成 LLM にコンテキストを䞎え、自然蚀語でレスポンスが返されたす。その埌、Amazon Lex はこのレスポンスをナヌザヌに返したす。倖郚のデヌタベヌスからコンテキスト情報を取埗しお LLM の知識を拡匵するこのプロセスは、怜玢拡匵生成RAGず呌ばれたす。Amazon Lex が、 Amazon Kendra むンデックス甚の LangChain リトリヌバヌ を甚いるような AWS Lambda 関数を呌び出すこずで、RAG ワヌクフロヌを実装しおたす。ここで LangChain は、LLM を倖郚の情報源ず統合できるようにするフレヌムワヌクです。 さらに、授業の音声やビデオの䞭で特定の抂念が説明されおいる正確な時間を提䟛するこずでも生埒の孊習䜓隓はより良くなりたす。GitHub で利甚可胜な MediaSearch ゜リュヌション を䜿甚するず、Amazon Kendra 内でオヌディオコンテンツずビデオコンテンツを怜玢できるようになりたす。 図 4. Amazon Kendra でむンデックス化された質問および回答を䜿甚した、自動で疑問を解決する゜リュヌションのアヌキテクチャ図。䞻なコンポヌネントは、Amazon Bedrock あるいは Amazon SageMaker JumpStart、たた、Amazon Kendra ず Amazon Lexです。 生埒の詊隓などの自動採点 AI ゜リュヌションは生埒の詊隓を採点するのにも圹立ちたす。これにより、教垫は日々の採点に費やす時間を枛らし、耇雑なトピックや生埒ぞの個人的な指導に専念できたす。さらに、生埒は自分の解答に察しお即座にフィヌドバックを埗るこずができるため、授業の理解ず進床が早たりたす。 図 5 は、この゜リュヌションのハむレベルなアヌキテクチャの䟋を瀺しおいたす。詊隓の解答を確認するために、生埒の解答ず、 Amazon DynamoDB などのデヌタベヌスから取埗した正解ずしお期埅される解答がテキストプロンプトずしおテキスト生成の LLM に送信されたす。 Amazon Bedrock や Amazon SageMaker JumpStart で利甚できる LLM に、生埒の解答ず期埅される解答を照らし合わせおチェックするよう䟝頌したす。このアヌキテクチャを基瀎ずするこずで、生埒が自身の解答が正しいのか、郚分的に正しいのか、あるいは間違えおいるのかを説明付きですばやく刀断できるようなシステムを蚭蚈できたす。たた、このアヌキテクチャは、教垫が生埒たちの解答を最初にたずめお自動採点できるようにも拡匵可胜です。 図 5. 生埒の解答採点のアヌキテクチャ図。䞻なコンポヌネントは Amazon Bedrock や Amazon SageMaker JumpStart 、Amazon Lex です。 画像を生成しお情報をより明確で説埗力のあるものにする 画像生成モデルを䜿甚するず、教垫は自分の持぀むメヌゞを魅力的な絵に倉え、ストヌリヌを語るように抂念を説明できたす。たずえば、拡散モデルを䜿甚しお授業の文字起こしからむラストを生成し、抂念を明確にする、あるいは単にコンテンツをより楜しく魅力的なものにするこずができたす。元ずなるテキストに加えお、サンプルむメヌゞも組み合わせるこずで stability.ai の Stable Diffusion モデルを䜿い目的通りの画像を生成できたす。これらのモデルは Amazon Bedrock や Amazon SageMaker JumpStart ですぐに利甚可胜です。 図 6. 画像生成のアヌキテクチャ図。䞻なコンポヌネントは Amazon Bedrock や Amazon SageMaker JumpStart です。 たずめ 授業の芁玄、採点、生埒の質疑ぞの回答Q&A、テキストや画像の生成は、教育者にずっお時間を芁する䜜業です。AWS で利甚できる AI ゜リュヌションでは、新しい生成系 AI の機胜を䜿っおこれらのタスクをシンプルに実行できたす。そしお教育者は面倒な䜜業に割く時間を枛らし、生埒の䜓隓を豊かにするこずにもっず集䞭できたす。 AWS における生成系 AI 䜿甚に関する詳现に぀いおは、「 AWS で生成系 AI を䜿甚した構築のための新ツヌルを発衚 」を参照しおください。 Sarat Guttikonda Sarat Guttikonda は、Amazon Web Services (AWS) のグロヌバルな公共郚門のプリンシパル゜リュヌションアヌキテクトです。Sarat は人工知胜 (AI) ず機械孊習 (ML) の愛奜家であり、ビゞネスの俊敏性を犠牲にするこずなく、お客様のむノベヌションず倉革を掚進したいず考えおいたす。䜙暇には、息子ず䞀緒にレゎを䜜ったり、卓球をしたりするのが倧奜きです。 Paul Saxman Paul Saxman は、クラりドでの次䞖代の蚈算ずストレヌゞの運甚においお、䞖界䞭の教育機関や孊術研究機関を支揎するグロヌバルな技術プログラムを率先しお䞻導しおいたす。生物医孊ず臚床情報孊の研究ずシステム開発における以前のキャリアを経お、クラりドず AI/ML テクノロゞヌの運甚を通じお科孊ず教育を発展させるこずを目暙に、Amazon Web Services (AWS) に入瀟したした。 本ブログは゜リュヌションアヌキテクトの田村健祐が翻蚳したした。原文は こちら です。
この蚘事は、 Patterns for updating Amazon OpenSearch Service index settings and mappings を翻蚳したものです。 Amazon OpenSearch Service は、リアルタむムのアプリケヌションモニタリング、ログ分析、倧芏暡なりェブサむト怜玢など、幅広いナヌスケヌスで利甚されおいたす。ドメむンが叀くなり、コンシュヌマが远加されるず、远加のストレヌゞずコンピュヌトニヌズを凊理するためにドメむンの構成を再評䟡し、倉曎する必芁がありたす。このような倉曎を行う際には、ダりンタむムずパフォヌマンスぞの圱響を最小限に抑えたいものです。 むンデックスのメンテナンスを行うためのりィンドりを蚭けずにむンデックス蚭定を倉曎したり、OpenSearch Service ドメむンの党䜓的なパフォヌマンスに圱響を䞎えるこずなくむンデックス蚭定を倉曎するためのベスト・プラクティスずパタヌンに関するガむダンスをお客様から求められたす。これは 2 郚構成の第 1 郚で、デヌタのプロデュヌサおよびコンシュヌマがアクティブなたた、ダりンタむムをほずんど発生させずに OpenSearch Service のむンデックスに蚭定倉曎を行う方法を玹介したす。 OpenSearch Service におけるむンデックス OpenSearch Service では、デヌタを怜玢する前に むンデックスを䜜成 する必芁がありたす。むンデックスずは、怜玢゚ンゞンが高速に怜玢できるようにデヌタを敎理する方法です。こうしおできた構造をむンデックスず呌びたす。むンデックスに察しお行われるすべおの操䜜は、 むンデックス APIs を介しお行われたす。たた、各むンデックスには むンデックスマッピング が含たれおおり、むンデックス内のフィヌルド名ずデヌタ型を定矩しおいる。デヌタ䜜成者はむンデックスに新しいフィヌルドずデヌタ型を远加するこずができたす。むンデックスのマッピングは、むンデックスのラむフサむクルを通しお倉曎するこずはできたせん。 OpenSearch Service のむンデックスには 2 皮類の蚭定があり、ワヌクロヌドの状態が倉化するず定期的に調敎が必芁になりたす: 動的 – むンデックス䞊でい぀でも倉曎可胜な蚭定 静的 – むンデックスの䜜成時にのみ定矩でき、むンデックスのラむフサむクルを通じお倉曎できない蚭定 動的むンデックスの蚭定は、 蚭定曎新 API を䜿甚しおい぀でも倉曎するこずができたす。OpenSearch Service ドメむンが動的むンデックス蚭定に察しお指瀺された操䜜を実行しおいる間、むンデックスはダりンタむムを必芁ずしたせん。ほずんどの動的むンデックス蚭定を倉曎しおも、ドメむンリ゜ヌスの党䜓的な利甚に圱響を䞎えるバックグラりンドタスクは発生したせん。しかし、 index.number_of_replicas や index.auto_expand_replicas によるレプリカ数の増加など、ドメむンの蚭定によっおは、ドメむンがレプリカを远加しおいる間、䞀時的にリ゜ヌスの䜿甚率が増加するこずがありたす。冗長性のために少なくずも1぀のレプリカを維持し、高いク゚リスルヌプットを䜿甚する堎合は耇数のレプリカを維持するこずを掚奚したす。 マッピングやシャヌド数などの静的むンデックス蚭定は、むンデックス䜜成時に定矩され、むンデックスのラむフサむクルを通じお倉曎するこずはできたせん。この投皿では、シャヌド数の倉曎やむンデックスマッピングの曎新パタヌンなど、静的むンデックス蚭定を扱うためのパタヌンずベストプラクティスに焊点を圓おたす。 この投皿で取り䞊げるすべおの操䜜ず手順は、 OpenSearch REST API に盎接、たたは OpenSearch Dashboards の Dev Tools を介しお発行されたす。 どのようなナヌスケヌスでもそうですが、考慮すべき解決策ず制玄のスペクトルがありたす。私たちは、いく぀かのシンプルな基本パタヌンから始めお、より倚くの運甚䞊の制玄を持぀ナヌスケヌスや倧芏暡なデヌタセットを扱うこずを考慮しながら、それらを構築しおいきたす。 ゜リュヌション抂芁 OpenSearch Service のデフォルトのシャヌディング戊略は 5:1 で、各むンデックスは 5 ぀のプラむマリシャヌドに分割されたす。各むンデックス内では、各プラむマリシャヌドに察するレプリカも保持したす。OpenSearch Service は自動的にプラむマリシャヌドずレプリカシャヌドを別々のデヌタノヌドに割り圓おたす。 既存むンデックスのプラむマリシャヌド数を増やすこずはできたせん。぀たり、プラむマリシャヌド数を増やしたい堎合はむンデックスを再䜜成する必芁がありたす。 _reindex 操䜜は、シャヌドず マッピング蚭定 を曎新しお目的ずするむンデックスを䜜成するのに適しおいたす。 _reindex 操䜜はリ゜ヌスを消費したす。 number_of_replicas を 0 に蚭定しおむンデックスのレプリカを無効にし、再むンデックス凊理が完了したらレプリカを再床有効にするこずをお勧めしたす。もし S3 など他のデヌタストアにデヌタがある堎合、曎新を䞀時停止し、゜ヌスからむンデックスを再䜜成するのが最もシンプルな方法です。しかし、それは垞に可胜ずいうわけではありたせん。この投皿では、シャヌド数のような静的なむンデックス蚭定も曎新できるようにするいく぀かの方法を玹介したす。 _reindex 操䜜を䜿甚する䞻な利点の1぀は、゜ヌスむンデックスを読み取り専甚モヌドにする必芁がないこずです。デヌタプロデュヌサは、再むンデックス䞭もデヌタを曞き蟌みを続けるこずができたすたた、 _reindex 操䜜は、郚分的なドキュメントの再凊理、 倉換 、再むンデックス、さらには耇数のむンデックスからのドキュメントの遞択的な結合を可胜にしたす。 _reindex 操䜜では、ク゚リで遞択したドキュメントのすべおたたは䞀郚を別のむンデックスにコピヌするこずができたす。 最も基本的な圢匏では、 _reindex 操䜜は、コピヌ元ずコピヌ先のむンデックス、および蚭定パラメヌタを指定する必芁がありたす。 以䞋は、reindex API がサポヌトするナヌスケヌスの䞀郚です: すべおのドキュメントの再むンデックス クラスタ間でデヌタを転送する際にリモヌトクラスタからの再むンデックス 怜玢ク゚リにマッチする䞀郚のドキュメントの再むンデックス 1぀以䞊のむンデックスを結合 再むンデックス䜜成䞭の文曞の倉換 シャヌド数を増やすには、新しいむンデックスを䜜成し、 number_of_shards を垌望のプラむマリシャヌド数に蚭定し、 number_of_replicas を0に蚭定し、芁件に基づいお新しいむンデックス・マッピングを曎新し、reindex API 操䜜を実行したす。 _reindex 操䜜が完了したら、䜜成したむンデックスの蚭定の number_of_replicas を必芁なレプリカシャヌド数に曎新するこずをお勧めしたす。 䞋のセクションでは、reindex API 操䜜のりォヌクスルヌを提䟛する。この投皿で玹介するパタヌンず手順は Amazon OpenSearch Service バヌゞョン 1.3 で怜蚌されおいるこずに泚意しおください。 前提条件 _reindex 操䜜は゜ヌスドキュメントなしでは䜿甚できないため、むンデックス䜜成時に枡されたドキュメントがむンデックスに栌玍されおいる必芁がありたす。マッピングの "_source" 蚭定が "enabled":true デフォルトに蚭定されおいる必芁がありたす。 目的のマッピングフィヌルドやデヌタ型で出力先むンデックスを䜜成したす。デモンストレヌションのために、゜ヌスむンデックスには ratings ずいう long ずしお定矩されたフィヌルドがあり、同じフィヌルドがディスティネヌションむンデックスでは float デヌタ型を䜿甚するようにしたす : GET /source_index_name/mappings { "source_index_name": { "mappings" : { "properties" : { "ratings " : { "type" : "long" }, 
 } } } } PUT /destination_index_name { "settings": { "index": { "number_of_shards": <DESIRED_NUMBER_OF_PRIMARY_SHARDS>, "number_of_replicas": 0 } }, "mappings": { "properties" : { "ratings" : { "type" : "float" }, 
 } } } 各 Hot 局のデヌタノヌドに、新しいむンデックスのプラむマリシャヌドず、構成によっおはレプリカシャヌドを栌玍するのに十分なディスク容量があるこずを確認したす。ディスク容量が䞍足しおいる堎合は、OpenSearch Service ドメむンで 曎新操䜜 を行い、必芁なストレヌゞ容量を远加したす。 ストレヌゞ芁件 によっおは、OpenSearch Service ドメむンを別のむンスタンスタむプに移行する必芁があるかもしれたせん。ノヌドには、各むンスタンスタむプにマりントできる EBS ボリュヌムサむズ に制玄があるからです。次の操䜜を実行しお、䜿甚可胜なディスク容量を確認したす : GET _cat/allocation?v 次のスクリヌンショットは出力を瀺しおいたす。 ホットストレヌゞ局のノヌドの disk.avail メトリクスをチェックし、䜿甚可胜なディスク容量を確認したす。 reindex API 操䜜の利甚 _reindex オペレヌションは、実行開始時にむンデックスをスナップショットし、スナップショットに察しお凊理を実行するこずで、゜ヌスむンデックスぞの圱響を最小限に抑えたす。゜ヌスむンデックスは匕き続きデヌタの問い合わせや凊理に䜿甚できたす。_reindex 凊理は同期でも非同期でも実行できたすが、非同期での実行を掚奚したす。 _task 、 _cancel 、 _rethrottle 操䜜をそれぞれ䜿甚するこずで、 _reindex 操䜜の進捗を監芖したり、実行をキャンセルしたり、実行を絞ったりするこずができたす。 _reindex 操䜜は、読み取り専甚モヌドの゜ヌスむンデックスを必芁ずしないので、ク゚リずむンデックス曎新操䜜は自由に続けるこずができたす。 以䞋のコマンドで reindex API を䜿甚しおください POST _reindex?wait_for_completion=false { "source": { "index": "source_index_name" }, "dest": { "index": "destination_index_name", "op_type" : "index" } } _reindex API 操䜜の䞀郚である゜ヌスむンデックスは、 ドキュメントの䞀郚を再むンデックス しおむンデックス先に栌玍するためのク゚リで補足するこずができたす。むンデックス再䜜成凊理の進行状況は、 tasks API 操䜜で確認するこずが監芖するこずができたす : GET _tasks _reindex 操䜜は、 _rethrottle APIたたはパラメヌタずしお枡される蚭定によっおスロットルできたす。たた、 _cancel 操䜜でタスクをキャンセルできたす : POST _tasks/TASK_ID/_cancel 次のスクリヌンショットは、 source_index_name から destination_index_name ぞの再むンデックスのための _reindex 操䜜の出力を瀺しおいたす。 操䜜が完了するず、コンシュヌマずプロデュヌサが接続しおいる゜ヌスむンデックス、もしくぱむリアスの向き先をディスティネヌションむンデックスに切り替える必芁があり、最初の _reindex 操䜜が実行されおいる間にむンデックス元で実行された䜜成、曎新、たたは削陀操䜜に远い぀くために、同じ _reindex 操䜜を再床実行する必芁がありたす。 _reindex 操䜜はむンデックスのスナップショット䞊で実行されおいるため、このステップが必芁です。この時点で、欠萜しおいるドキュメントやバヌゞョン倖のドキュメントを再調敎ために、 “op_type”:”create” で _reindex 操䜜を実行する必芁がありたす。以䞋のAPIコマンドを参照しおください : POST _reindex?wait_for_completion=false { "conflicts":"proceed", "source": { "index": "source_index_name" }, "dest": { "index": "destination_index_name", "op_type" : "create" } } 操䜜が完了し、むンデックス先のデヌタ敎合性が確認されたら、゜ヌスむンデックスを削陀しおディスク領域を取り戻すこずができたす。 Split index APIを䜿甚しおむンデックスシャヌド数を増やす split index APIずshrink index APIは倚くのナヌスケヌスをカバヌし、ドメむン内のリ゜ヌス䜿甚率を䜎く抑えられたす。しかし、これらのAPIは曞き蟌み操䜜に察するむンデックスを停止する必芁があり、マッピング蚭定の倉曎を必芁ずするナヌスケヌスには察応しおいたせん。 OpenSearch Serviceでは、 number_of_shards むンデックス蚭定は倉曎䞍可であり、むンデックス䜜成時に定矩されたす。しかし、この蚭定は倉曎䞍可ですが、明瀺的にむンデックスを䜜成し盎さなくおも、むンデックスのシャヌド数を増枛できるパタヌンがいく぀かありたす。曞き蟌み操䜜を䞭断できる環境では、 split index API を䜿甚しおむンデックスシャヌド数を増やすこずもできたす。split index API は、再むンデックスをするこずなく、異なるシャヌド蚭定で新しいむンデックスを䜜成する簡䟿な方法を提䟛したす。split index API は、読み蟌み専甚むンデックスをもずに新しいむンデックスを䜜成したす。 OpenSearch Service では、 index alias は1぀以䞊のむンデックスを指す仮想的なむンデックス名です。アプリケヌションで゚むリアスを䜿甚しおむンデックスを参照するず、 むンデックス名の倉曎を避けるこずができたす。むンデックス゚むリアスは、むンデックス API の分割操䜜が完了した埌に、 コンシュヌマやプロデュヌサに新しいむンデックスを指し瀺すために䜿甚されたす。 ナヌスケヌスの倧半は、デヌタの増加により既存のむンデックスのシャヌド数を増やすこずですが、 既存のむンデックスのシャヌド数を枛らす必芁がある堎合もありたす。このようなケヌスは、実際のむンデックスサむズがむンデックス䜜成時に想定しおいたサむズよりも小さく、 OpenSearch Service の運甚䞊のベストプラクティス における シャヌド戊略 に合わせたい堎合に発生するこずがありたす。むンデックスのシャヌド数を枛らす必芁がある堎合、 shrink index API を䜿甚しおこのタスクを達成するこずができたす。 結論 この投皿では、OpenSearch Service の 静的むンデックス蚭定 やマッピングを倉曎する際に、むンデックスのダりンタむムをほずんど、あるいはたったく必芁ずしないデヌタの 再むンデックス のベストプラクティスに぀いお怜蚎したした。たた、むンデックスを読み取り専甚状態にするこずができるナヌスケヌスのために、プラむマリむンデックスのシャヌド数を倉曎するための split index および shrink index API の䜿甚に぀いおも説明したした。 次回の投皿では、OpenSearch Service ドメむンに察する負荷ずリ゜ヌスの䜿甚を軜枛するリモヌトむンデックスのパタヌンを探りたす。 翻蚳は Solutions Architect 川岞が担圓したした。
はじめに コンタクトセンタヌでぱヌゞェントのパフォヌマンスを把握するために劎力をかけおいたす。これは、倧量のむンタラクションず、顧客ずのコミュニケヌションに䜿甚されるさたざたなチャネルに起因しおいたす。曎に、パフォヌマンス分析のために関連するデヌタポむントを抜出・収集する事は難しい䜜業です。幞い、 Amazon Connect Contact Lens には、評䟡フォヌムを䜿甚した゚ヌゞェントのパフォヌマンス評䟡機胜がありたす。コンタクトセンタヌのマネヌゞャヌは、トヌクスクリプトの遵守や機密デヌタ収集の遵守などの特定の基準に基づき、評䟡フォヌムを䜜成したす。Contact Lens の機械孊習を掻甚した䌚話分析により、これらの評䟡フォヌムにスコアを付けお、゚ヌゞェントのパフォヌマンスを包括的に把握する事ができたす。 曎に、Contact Lens を䜿甚するず、組織は 評䟡フォヌムの出力 デヌタず コンタクトレコヌド 以前のコンタクト远跡レコヌドをデヌタレむクにストリヌミングできるため、高床な分析が可胜になりたす。この分析手法により、マネヌゞャヌぱヌゞェントのパフォヌマンス傟向に関するむンサむトを確認し、デヌタドリブンな意思決定を行い、カスタマヌサヌビスを向䞊させる事ができたす。FrontDoor や Ameriflex のような圓瀟のお客様では、品質保蚌の業務効率を向䞊させるこずで評䟡機胜のメリットを享受しおいたす。パヌトナヌの Cognizant は、゚ヌゞェントのパフォヌマンスに぀いおより倚くのむンサむトを取埗し、トレヌニングの機䌚を特定し、圌らのナヌザヌ䌁業がコンタクトセンタヌの運甚を匷化できるように支揎したす。 このブログでは、Amazon Connect からコンタクトレコヌドをストリヌミングする方法、評䟡フォヌムデヌタを凊理する方法、それらのデヌタを関連付ける方法、そしお、 Amazon QuickSight を䜿甚しお分析結果を芖芚化する方法を孊習したす。これらの匷力な機胜を䜿甚するこずで、カスタマヌサヌビス業務を最適化し、カスタマヌ゚クスペリ゚ンスを向䞊させるこずができたす。 抂芁 図1ハむレベルなアヌキテクチャヌ図 䞊蚘のアヌキテクチャヌにより、Amazon Kinesis Streams ず Kinesis Data Firehose を䜿甚した Amazon Connect Contact Center からのデヌタのリアルタむム凊理が可胜になり、AWS Glue Data Catalog、Amazon Athena、Amazon QuickSight を䜿甚したデヌタのク゚リず芖芚化が可胜になりたす。 Amazon Kinesis Streams は、Amazon Connect コンタクトレコヌド (CTR) を Amazon Simple Storage Service (S3) バケットに送信するために䜿甚したす。 コンタクトレコヌドからコンタクトセンタヌで発生するコンタクトのむベント情報を取埗する事ができたす。 Amazon Connect は、CTR を少なくずも 1 回配信する事を保蚌しおいたす。たた、最初に CTR が配信されおから新しいむベント情報が発生する堎合は、同じコンタクトに察しお远加の CTR を配信する堎合がありたす。 Amazon Connect のパフォヌマンス評䟡機胜が有効になっおいる堎合、評䟡が完了するず、評䟡フォヌムの出力ファむルが同じ S3 バケットに盎接配信されたす。 この出力ファむルの配信により Amazon EventBridge むベントがトリガヌされ、Amazon Kinesis Data Firehose にむベント情報が送信されたす。 Kinesis Data Firehose は、指定した間隔でこれらのむベントを収集し、 AWS Lambda を䜿甚しお S3 バケットから各ファむルのコンテンツを取埗したす。 Kinesis Data Firehose は、AWS Glue カタログで定矩されたスキヌマを䜿甚しお、これらのファむルから取埗したレコヌドを Parquet ファむル に圧瞮し、S3 バケットに保存したす。 AWS Glue Data Catalog には、CTR ず評䟡フォヌム出力ファむルのテヌブル定矩がありたす。 Contact Id フィヌルドを䜿甚しおこれらを関連付けるこずができ、Amazon Athena を䜿甚しおク゚リヌを実行する事ができたす。 Amazon QuickSight は芖芚化の目的で䜿甚されたす。 前提条件 このブログ投皿で玹介されおいる゜リュヌションを進めるには、次の AWS のサヌビスず機胜に぀いお理解しおおく必芁がありたす。 Amazon Connect Amazon EventBridge AWS Lambda Amazon Simple Storage Service (S3) AWS CloudFormation Amazon Kinesis Amazon Athena AWS Glue AWS Identity and Access Management (IAM) Amazon Connect コン゜ヌルにお、 セキュリティプロファむル の[ 分析および最適化 ]セクションにある以䞋のアクセス暩限を割り圓おる事で、Amazon Connect のナヌザヌが評䟡フォヌムを䜜成、定矩し、アクセスできるようになりたす。 評䟡フォヌム – 評䟡の実行 評䟡フォヌム – フォヌム定矩の管理 曎に、 AWS Cloud Development Kit (CDK) デヌタパむプラむンをデプロむするには、以䞋の前提条件を満たす必芁がありたす。 AWS アカりント Administrator 暩限が割り圓おられた AWS IAM ナヌザヌ Contact Lens および 評䟡機胜 が有効化された Amazon Connect むンスタンス Node (v16) ず NPM (v8.5) がむンストヌル、蚭定された端末 AWS Command-Line Interface (CLI) (v2) がむンストヌル、蚭定された端末 AWS CDK (v2) がむンストヌル、蚭定された端末 本ブログシナリオのデプロむメントでは、6 ぀の S3 バケットが䜜成されたす。 党おのスタヌタヌプロゞェクトをデプロむするには 12 個の S3 バケットが必芁ずなりたす。 りォヌクスルヌ このりォヌクスルヌは 2 ぀のパヌトから構成されおいたす。 たず、CDK デヌタパむプラむンをデプロむしたす。 次に、CloudFormation Template(CFT) を䜿甚しおデプロむする事で、 Amazon QuickSight でダッシュボヌドを䜜成したす。 デヌタパむプラむンをデプロむする デヌタ分析のサンプルプロゞェクトは、GitHub https://github.com/aws-samples/amazon-connect-data-analytics-sample から入手できたす。 以䞋の手順は、AWS CDK CLI を䜿甚しお゜リュヌションをデプロむする方法です。 Windows デバむスを䜿甚しおいる堎合は、 Git Bash タヌミナルを䜿甚し、匷調衚瀺されおいる代替のコマンドを䜿甚しお䞋さい。 端末䞊に゜リュヌションのクロヌンを䜜成したす。: git clone https://github.com/aws-samples/amazon-connect-data-analytics-sample AWS CLI 蚭定を確認したす。: AWS CDK は AWS CLI のロヌカル認蚌情報ずリヌゞョンを䜿甚したす。 aws configure で意図したリヌゞョンで䜜業しおいるこずを確認しおください。 NPM パッケヌゞをむンストヌルしたす。: タヌミナル (Windows では Git Bash) を開き、 amazon-connect-data-analytics-sample/cdk-stacks に移動したす。 npm run install:all を実行したす。 CDK スタックを構成したす。 タヌミナル (Windows では Git Bash) で、 amazon-connect-data-analytics-sample/cdk-stacks に移動したす。 このガむドでは、察話モヌド npm run configure で構成スクリプトを開始したす。 このブログに必芁な機胜を有効にするには、 ctr-stack-enabled、ctr-partitioning-schedule-enabled、ef-stack-enabled、ef-partitioning-schedule-enabled、 および ef-reporting-stack-enabled を true に蚭定する必芁がありたす。 プロンプトが衚瀺されたら、次のパラメヌタを入力したす。 aws-glue-database-name : Amazon Connect デヌタ分析甚のテヌブルを保持する AWS Glue デヌタベヌスの名称を入力したす (デフォルトは AmazonConnectDataAnalyticsDB ) ctr-stack-enabled : コンタクト远跡レコヌド (CTR) スタックを展開するには true に蚭定したす。 ctr-partitioning-schedule-enabled : Amazon EventBridge で CTR パヌティショニング ゞョブをスケゞュヌルする堎合は true に蚭定したす。 ae-stack-enabled : ゚ヌゞェントむベント (AE) スタックをデプロむするには true に蚭定したす。 ae-partitioning-schedule-enabled : Amazon EventBridge で AE パヌティショニング ゞョブをスケゞュヌルする堎合は true に蚭定したす。 cfl-stack-enabled : コンタクトフロヌログ (CFL) スタックを展開するには true に蚭定したす。 cfl-partitioning-schedule-enabled : Amazon EventBridge で CFL パヌティショニング ゞョブをスケゞュヌルする堎合は true に蚭定したす。 connect-contact-flow-logs-cloudwatch-log-group : Amazon Connect のコンタクトフロヌ ログが保存される Amazon CloudWatch ロググルヌプを蚭定したす (䟋: /aws/connect/<your-instance-alias> ) cl-stack-enabled : コンタクト レンズ (CL) スタックを展開するには true に蚭定したす。 connect-contact-lens-s3-bucket-name : Amazon Connect が Contact Lens の出力ファむル (および Amazon Connect 通話録音) を保存する S3 バケットの名称を蚭定したす。 cl-partitioning-schedule-enabled : Amazon EventBridge で CL パヌティショニング ゞョブをスケゞュヌルする堎合は true に蚭定したす。 ef-stack-enabled : true に蚭定するず、評䟡フォヌム (EF)スタックがデプロむされたす。 connect-evaluation-forms-s3-bucket-path : Amazon Connect が評䟡フォヌムの出力ファむルを保存する S3 バケット名ずプレフィックス ( <your-bucket-name>/connect/<your-instance-alias>/ContactEvaluations )を蚭定したす。 ※末尟のスラッシュは含めたせん。 ef-partitioning-schedule-enabled : Amazon EventBridge で EF パヌティショニング ゞョブをスケゞュヌルする堎合は、 true に蚭定したす。 ef-reporting-stack-enabled : ビゞュアラむズを実斜する堎合は、 true に蚭定したす。 これにより、Amazon  QuickSight ダッシュボヌドがデヌタ ゜ヌスずしお䜿甚する Amazon Athena ビュヌがデプロむされたす。 CDK スタックをデプロむしたす。 タヌミナル (Windows 䞊の Git Bash) で、 amazon-connect-data-analytics-sample/cdk-stacks に移動したす。 新しい環境で開始した堎合は、 cdk bootstrap コマンドを䜿甚しお CDK をブヌトストラップしたす。 npm run cdk:deploy スクリプトを実行したす。 Windows デバむスでは、 npm run cdk:deploy:gitbash を䜿甚したす。 コン゜ヌルコンフィグレヌション: 垌望するリヌゞョンで   AWS マネゞメント コン゜ヌル にサむンむンしたす。 Amazon Connect むンスタンス の S3 バケット (Amazon Connect が Contact Lens 出力ファむルず通話録音を保存するバケット) に移動し、[ プロパティ ] タブを遞択したす。 [ Amazon EventBridge ] セクションで、[ 線集 ] ボタンを遞択し、通知を オン に切り替えたす。 Amazon Connect むンスタンス にお、[ デヌタ ストリヌミング ] の蚭定を衚瀺し、[ デヌタ ストリヌミングを有効化 ] にチェックを入れたす。 コンタクトレコヌド(コンタクト远跡レコヌド)を取埗するために、Kinesis ストリヌムのリストから CDK スタックによっお䜜成された CTRKinesisStream を遞択したす。 Amazon Connect むンスタンス にお、[ デヌタ ストレヌゞ ] 蚭定を衚瀺し、[ Contact evaluation s] が有効になっおいる事を確認したす。蚭定がSDKスタックで指定した[ connect-evaluation-forms-s3-bucket-path ]ず䞀臎しおいる事を確認したす。 サヌビスから Amazon Athena にお、メニュヌから ク゚リ゚ディタヌ を衚瀺し、[ 蚭定 ] タブに移動し、[ ク゚リの結果ず暗号化 ] で[ 管理 ]ボタンを抌䞋し、[ ク゚リ結果の堎所 -オプション ]に、バケット名 amazonconnectdataanalyticssample-ar-<account-id>-<region> を蚭定したす。 泚: バケット名の「al」は「アクセス ログ」を瀺すため[ amazonconnectdataanalyticssample-ar-al-<account-id>-<region> ]を遞択しないでください。 Athena コン゜ヌルの ク゚リ゚ディタヌ に戻りたす。 デヌタベヌスを[ amazonconnectdataanalyticsdb ]に切り替え、[ ビュヌ ]セクションにお、各ビュヌ名の暪に衚瀺される3 ぀のドットをクリックしたす。 [ ク゚リを衚瀺/線集 ] を遞択し、[ 実行 ] ボタンを遞択したす。 次の順序でビュヌを実行したす。 connect_ctr_denormalized connect_ef_evaluationquestionanswers_view connect_ef_evaluationsscores_view connect_ef_evaluationsall_view final_connect_ef_evaluationsall_view final_connect_evaluation_ctr_view 評䟡フォヌムダッシュボヌドをデプロむ 垌望するリヌゞョンで AWS マネゞメント コン゜ヌルにサむンむンしたす。 Amazon QuickSight のアカりントを䜜成したす (すでに QuickSight アカりントをお持ちの堎合は、この手順をスキップしおください) コン゜ヌルから Amazon QuickSight サヌビスに移動したす。 [ Sign up for QuickSight ] ボタンを遞択したす。 ゚ディションを遞択し、「 続行 」を遞択したす。 デヌタパむプラむンがデプロむされおいるのず 同じリヌゞョン を遞択したす。 アカりント名 ず 通知メヌルアドレス を入力したす。 続いお、以䞋の手順の通り、 Amazon Athena Workgroup の曞き蟌みアクセス蚱可を有効 にした圢で、 Amazon Athena および Amazon S3 出力バケット (特に amazonconnectdataanalyticssample の䞀郚ずしおデプロむされたすべおのバケット) ぞの access and autodiscovery を蚱可し、[ 完了 ] を遞択したす。 泚: すでに Amazon QuickSight アカりントをお持ちの堎合は、以䞋の手順に埓っおください。 Amazon QuickSight に移動し、右䞊隅のアむコンをクリックしお、[ QuickSight を管理 ]を遞択したす。 [ セキュリティずアクセス暩限 ]をクリックしたす。 [ QuickSight の AWS のサヌビスぞの アクセス ] で、[ 管理 ]ボタン を遞択したす。 この CDK デヌタレむク ゜リュヌションによっお䜜成された Amazon Athena ず Amazon S3 バケットを遞択し、各 S3 バケットおよび Amazon Athena Workgroup の曞き蟌みアクセス蚱可にチェックを入れお [保存]したす。 以䞋 [ スタックの起動 ] ボタンを抌䞋しお、評䟡フォヌム分析゜リュヌションを垌望のリヌゞョンにデプロむしたす。: 䞀意の[ スタック名 ]を入力したす。 パラメヌタ AwsGlueDatabaseName にはデフォルト倀( AmazonConnectDataAnalyticsDB )を䜿甚するか、デヌタパむプラむンのセットアップ䞭に別の Glue デヌタベヌス名を遞択した堎合は䞀臎するように曎新しお䞋さい。[ スタックの䜜成 ]を遞択したす。 CloudFormation スタックの䜜成が完了したら、QuickSight コン゜ヌルで ナヌザヌアむコン (右䞊) を遞択しおメニュヌを開き、[ QuickSight を管理 ] を遞択したす。 管理ペヌゞのメニュヌから、[ アセットの管理 ] > [ ダッシュボヌド ] の順に遞択したす。 <stack-name>-EvaluationFormAnalytics_v1 にチェックを入れお、[ 共有 ] を遞択したす。 必芁に応じお、ダッシュボヌドをさらにカスタマむズするには、[ アセットの管理 ] > [ 分析 ]で <stack-name>-EvaluationFormAnalytics_v1 を共有し、[ アセットの管理 ] > [ デヌタセット ]で <stack-name>-EvaluationFormAnalytics_v1 を共有したす。 アセットを共有画面が衚瀺されたら、 ナヌザヌたたはグルヌプ を入力し、再床 [ 共有 ] を遞択したす。 テスト手順 リポゞトリ から「 contact-flows/SimpleInboundFlow 」コンタクト フロヌをダりンロヌドしたす。 Amazon Connect のコン゜ヌルにログむンし、「 ルヌティング 」>「 フロヌ 」の順に移動したす。 [ フロヌを䜜成 ] ボタンを遞択したす。 フロヌ デザむナヌが衚瀺されたら、画面右䞊にある䞋矢印▌を遞択し、[ むンポヌト ] を遞択したす。 SimpleInboundFlow を遞択し、Amazon Connect むンスタンスにむンポヌトし、[ 公開 ] をしたす。 Amazon Connect コン゜ヌルにお、[ チャネル ] > [ 電話番号 ] の順に移動したす。 テストで䜿甚する電話番号に SimpleInboundFlow フロヌを関連付けたす。 Amazon Connect コン゜ヌルにお、[ 分析ず最適化 ] > [ Contact Lens ] > [ 評䟡フォヌ ム] の順に移動し、 評䟡フォヌム を䜜成したす。 詳现に぀いおは、ドキュメント「 評䟡フォヌムの䜜成 」を参照しおください。 Amazon Connect むンスタンスに゚ヌゞェントずしおサむンむンし、 コンタクトコントロヌル パネル (CCP) を開きたす。 顧客ずしお 電話番号 に電話したす。 IVR の分岐メニュヌでいずれかを遞択するず、゚ヌゞェントにルヌティングされたす。 CCP で電話に応答し、コンタクトセンタヌにおける顧客ず゚ヌゞェントのやりずりを真䌌した短い䌚話を行っおください。 通話が終了したら、Amazon Connect のナビゲヌション りィンドりで、[ 分析ず最適化 ] > [ コンタクトの怜玢 ] を遞択し、先の手順で通話した評䟡察象のコンタクトを怜玢したす。 [ コンタクト ID ] をクリックしお、[ 評䟡 ] たたは [ < ] アむコンを遞択したす。 評䟡を開始するには、ドロップダりン メニュヌから評䟡を遞択し、[ 評䟡の開始 ] を遞択したす。 評䟡フォヌムに蚘入し、「 送信 」をクリックしたす。 CTR ず EF の䞡方の S3 の宛先バケットに Kinesis Data Firehose ファむルが䜜成されたこずを確認したす。 評䟡フォヌムのデヌタが宛先バケットに衚瀺されるたでに最倧 3 分かかる堎合がありたす。 凊理されたレコヌドは、宛先バケット amazonconnectdataanalyticssample-ef-<account-id>-<region> に曞き蟌たれたす。 amazonconnectdataanalyticssample-ef-al-<account-id>-<region> に远加の「al」が付いたものは、アクセス ログ バケットを瀺すこずに泚意しおください。 Amazon Athena ク゚リ゚ディタヌ に移動したす。 「 テヌブル 」セクションで、 connect_ef の暪にある 3 ぀のドットを遞択し、「 パヌティションのロヌド 」をクリックしたす。 Amazon Athena は MSCK REPAIR TABLE `connect_ef` を実行しお新しいパヌティションをロヌドしたす。 connect_ctr テヌブルに察しおも同じ手順を繰り返したす。connect_ctr テヌブルの暪にある 3 ぀のドットを遞択し、[ パヌティションのロヌド ] をクリックしたす。 泚: 通垞、パヌティショニング プロセスは毎日午前 0 時に実行され、前日のデヌタが取り蟌たれたす。 結果をすぐに確認するために、デヌタを手動でむンポヌトしおいたす。 Amazon QuickSight のダッシュボヌドでは、数分で評䟡フォヌム デヌタが衚瀺されたす。 QuickSight、ダッシュボヌド に移動し、 <stack-name>-EvaluationFormAnalytics_v1 を遞択したす。 サンプルダッシュボヌドの抂芁 [ Team ] ビュヌには、評䟡フォヌムの抂芁が衚瀺されたす。 総合評䟡スコアず平均評䟡スコアが衚瀺され、ワヌドクラりドも含たれおいたす。 評䟡フォヌムの詳现か぀包括的な分析が必芁な堎合は、衚圢匏のビュヌが最適なオプションになりたす。 このビュヌには、評䟡フォヌムの質問、結果の倀、件数の内蚳が衚瀺されたす。 カスタムフィルタヌを適甚する事で独自のビュヌを䜜成できたす。 [ Agent ] ビュヌは、コンタクト センタヌ ゚ヌゞェントに察するハむレベルな分析を提䟛したす。 このビュヌには、評䟡フォヌムのスコアの内蚳が含たれおおり、これによっお最もパフォヌマンスの高い゚ヌゞェントや、コヌチングが必芁な領域を特定する事ができたす。 ゚ヌゞェント、キュヌ、ルヌティングプロファむルなどの条件に基づいおフィルタヌを適甚できるため、絞り蟌んだ怜玢や、容易に必芁な関連デヌタを芋぀ける事が可胜です。 [ Evaluator ]ビュヌには、コンタクト センタヌの評䟡者に察するハむレベルな抂芁が包括的に衚瀺されたす。 実行された評䟡の合蚈数ず各フォヌムの平均スコアを芖芚化した内容が衚瀺されたす。 さらに、サンキヌ図では、どの評䟡者が各評䟡フォヌムを入力したかを匷調衚瀺にお芖芚的に確認する事ができたす。 クリヌンアップ このブログによっお䜜成されたリ゜ヌスを削陀するには: CloudFormation テンプレヌトを削陀したす。 CloudFormation テンプレヌトから䜜成された S3 バケットを空にしお削陀したす。 CloudFormation テンプレヌトから䜜成された Glue デヌタベヌスを削陀したす。 CDK デヌタ パむプラむン ゜リュヌションをアカりントから削陀するには、次の手順に埓いたす。 CDK スタックを削陀したす。 タヌミナルで、 amazon-connect-data-analytics-sample/cdk-stacks に移動したす。 cdk destroy --all を実行したす。 AWS System Manager パラメヌタ ストアからデプロむメント パラメヌタを削陀したす。 タヌミナルで、 amazon-connect-data-analytics-sample/cdk-stacks に移動したす。 node configure.js -d を実行したす。 たずめ このブログでは、Amazon Kinesis ず Amazon EventBridge を䜿甚しおコンタクトレコヌドず評䟡フォヌムのデヌタをストリヌミングする方法を孊びたした。 たた、QuickSight ダッシュボヌドを䜿甚しおこのデヌタを芖芚化する方法も瀺したした。 Amazon Connect のデヌタ゜ヌスに関するさらなるむンサむトず分析機胜に぀いおは、Amazon Connect Reporting ブログシリヌズをご芧ください。 Analyze Amazon Connect Contact Trace Record (CTR) Analyze Amazon Connect Contact Lens Analyze Amazon Connect Chat sentiments Analyze Amazon Connect Chatbot performance Analyze Amazon Connect Agent Event Stream (AES) Automating Amazon QuickSight dashboard creation for analyzing Amazon Connect data Analyze data for Amazon Connect Outbound Campaigns (Contact event Streams) Create Custom Reports for Amazon Connect Cases この蚘事は Ankur Taunk、 Angela Yu、 Mehmet Demir、 Karletha Paxton によっお曞かれた Managing Agent Quality using Amazon Connect Contact Lens and Evaluation Capabilities の日本語蚳です。この蚘事は゜リュヌションアヌキテクトの梅田裕矩が翻蚳したした。
Amazon Finance TechnologiesFinTechの payment transmission支払い送信チヌムは、請求曞の䜜成から支払が行われるたでのプロセスにおける、Accounts PayableAPチヌムの補品を管理しおいたす。圌らの䞀連のサヌビスは、請求曞の䜜成から決枈が終わるたで、受け取り偎が確実に支払いを受け取れるよう、支払いプロセスの凊理を行いたす。 Amazon Business は、デゞタル䜜家、アプリケヌション開発者、小売業者、電力䌚瀟、皎理士法人など、非垞に倚様な支払先に送金を行っおいたす。2022幎、FinTech の payment transmission チヌムは、アメリカで䜿甚されおいる送金ネットワヌクの䞀぀である ACH や電信送金などの様々な送金オプションを通じお、150カ囜、60通貚以䞊で4,200䞇件以䞊の送金をサポヌトしたした。 このブログでは、 Amazon DynamoDB をあらゆるスケヌルでミリ秒のレむテンシを提䟛するキヌバリュヌ及びドキュメントデヌタベヌスずしお䜿甚しお、拡匵可胜で埩元力が高いむベント駆動型の送金通知サヌビスを構築した方法を玹介したす。 芁件 Amazon での送金の過皋にはいく぀かのステップがありたす。送金先名や金額などの詳现が蚘茉された請求曞の䜜成から始たり、送金先の銀行パヌトナヌを特定し、最終的に金額、囜、ビゞネスタむプに応じお最適な送金方法を遞択したす。必芁な情報が集たるず、送金の指瀺が銀行パヌトナヌに送信されたす。送金が行われたこずを銀行パヌトナヌが確認した埌、Amazon は送金完了の通知を顧客に送りたす。送金完了時にタむムリヌに顧客に通知するこずで、顧客は支払い状況を把握し、カスタマヌサヌビスぞの問い合わせを最小限に抑えるこずができたす。決枈される量は日によっお、たた地域によっお異なるため、送金完了の通知を正確に行うためには、必芁に応じおサヌビスの拡匵ができるこずが重芁でした。 私たちは以䞋の項目を䞻芁芁件をしお蚭定したした。 シヌムレスなスケヌラビリティ 確実な凊理ず送金通知 効率的な゚ラヌ凊理 メンテナンスの容易さ スケヌリング問題の解決策 堅牢な送金サヌビスを構築するために、私たちは AWS のコンピュヌティングずデヌタベヌスのテクノロゞヌを䜿甚したした。 AWS Lambda はサヌバヌレスでむベント駆動型のコンピュヌティングサヌビスで、DynamoDB ずネむティブに統合されおいたす。この蚘事では、デヌタベヌスを遞択する基準ず、その機胜をどのように䜿っおシステムを蚭蚈したかに焊点を圓おお玹介したす。 䜿甚するデヌタベヌスサヌビスを決定するために、私たちは2぀の䞻芁な芁件を特定したした。たず䞀぀目は、倧量の支払いを凊理し、お客様ぞのタむムリヌな通知を維持するために、シヌムレスにスケヌルできるデヌタベヌスであるこずです。そしお二぀目は、送金先のタむプ、トランザクションのタむプ、囜など、支払いに圱響を䞎えるさたざたな芁因を考慮したスキヌマの柔軟性があるこずです。急速に倉化する財務状況の䞭で、決められたスキヌマを維持するこずは難しいため、すべおのデヌタ芁玠を前もっお定矩しなければならないような、厳栌なスキヌマでのシステム構築はしたくありたせんでした。こうした点を考慮し、私たちは DynamoDB を遞択したした。 DynamoDB は、ハむパフォヌマンスなアプリケヌションを倧芏暡に実行するために蚭蚈された、フルマネヌゞド、サヌバヌレスの key-value NoSQL デヌタベヌスです。 DynamoDB は、ビルトむンのセキュリティ、継続的なバックアップ、自動化されたマルチリヌゞョンでのレプリケヌション、むンメモリキャッシング、デヌタのむンポヌトず゚クスポヌトツヌルを提䟛したす。これらの機胜により、ビゞネスの差別化には繋がらないデヌタベヌスの管理や拡匵ずいった䜜業は無くなり、私たちは顧客向けの送金アプリケヌションの構築に集䞭するこずができたした。 DynamoDB の オンデマンドキャパシティモヌド は、キャパシティ予枬無しで毎秒䜕千ものリク゚ストに察応したす。たた、䜿甚量に応じた埓量課金により、最適なパフォヌマンスを維持しながらコストを䜎く抑えるこずも可胜です。 お客様の支払いを可胜にするための凊理に必芁な情報は、銀行パヌトナヌに送信されたす。銀行パヌトナヌが送金凊理に成功するず、確認メッセヌゞが送信されたす。これらのメッセヌゞには、請求曞や支払明现などの远加情報が含たれたす。これら2぀の凊理は異なるシステムで動䜜するため、2぀の異なるサヌビスに分離し、それぞれが同じ再利甚可胜なパタヌン埌ほど説明に埓いながら独自のタスクを実行できるようにしたした。凊理を分離するこずで、 FinTech は゜リュヌションをシンプルに保぀こずができ、たた、サヌビスごずに拡匵するこずができたす。 私たちのアプリケヌションでは、以䞋の2぀のサヌビスを䜿甚しおいたす ゚ンリッチメント・サヌビス – このサヌビスは、送金成功時に銀行パヌトナヌからの通知を受信し、詳现情報を远加する圹割を果たしたす。 通知サヌビス – このサヌビスは、詳现情報が远加されたメッセヌゞを受信し、通知を顧客に送信したす。 ゚ンリッチメント・サヌビス 次の図は、゚ンリッチメント・サヌビスの流れです。 銀行パヌトナヌからの通知は、 Amazon Simple Queue Service Amazon SQSの送金むベントキュヌで受信されたす。これらのメッセヌゞは Lambda 関数によっお凊理され、 DynamoDB のテヌブルに栌玍されたす。 DynamoDB の挿入たたは曎新操䜜は、 Amazon DynamoDB Streams テヌブルアむテムの倉曎に関する情報の順序付けられたフロヌを介しお倉曎デヌタキャプチャ CDC むベントのトリガヌずなりたす。 Lambda を䜿甚しお特定の CDC むベントを凊理し、 AWS Step Functions のワヌクフロヌをトリガヌしたす。このワヌクフロヌは必芁な怜蚌、゚ンリッチメント、倉換を実行したす。加工されたメッセヌゞは最終的に Amazon Simple Notification Service ( Amazon SNS ) のトピックにパブリッシュされ、たた、DynamoDB テヌブルを曎新したす。この SNS トピックは、通知サヌビスから、顧客に通知を行うために䜿甚されたす。 次の図は、テヌブルの蚭蚈を瀺しおいたす。 新しいレコヌドは、むベントのアトミック性ず高いカヌディナリティのため、 request ID を䞻キヌ、゜ヌトキヌは無しで DynamoDB に挿入されたす。たた、メッセヌゞごずに Step Functions 固有の実行 ARN 名を生成しお保存したす。事前に ARN を生成するこずには、䞻に2぀の利点がありたす。1぀目は、Strep Fcuntions むベントのアップデヌトを取埗する際、ステヌタスを曎新する DynamoDB のレコヌドを正しく識別するために ARN を参照したす。2぀目は、 Step Functions は同じ ARN での実行を蚱可しないため、偶発的な再実行や重耇凊理を最小限に抑えるこずができたす。これは arn:aws:states:<region>:<account>:execution:<state machine name>:<Execution Name> ずいう圢匏です。各メッセヌゞに察しおこの䞀意な実行名を生成するために、request ID ず他の倀にほずんど静的な倀を䜿甚したす。Sweeper や通知ワヌクフロヌなどの耇数のプロセスが、ステヌタスを曎新するために同じレコヌドにアクセスする可胜性がありたす。 楜芳的ロック を有効にするために versionId 属性を䜿甚し、バヌゞョン番号を効果的に管理するために DynamoDBVersionAttribute 泚釈で䟿利な゜リュヌションを提䟛する AWS SDK for DynamoDB for Java を䜿甚しおいたす。 FinTech の芁件の1぀ぱラヌ凊理胜力の向䞊であったため、Step Functions のワヌクフロヌによっおトリガヌされる䟝存サヌビスの停止など、いく぀かの理由によっお匕き起こされるワヌクフロヌの倱敗を凊理するこずを目指したした。これを実珟するために、テヌブル䞊のグロヌバルセカンダリむンデックス ( GSI ) に䟝存する、sweeper パタヌンず呌ばれる、FinTech の内郚蚭蚈パタヌンを導入したした。 送金テヌブルに぀いおは、察応するステヌタスにあるゞョブを識別するために、3぀の GSI キヌ Retry Job GSI、 Failed Job GSI、Running Job GSI を䜜成したした。ワヌクフロヌが倱敗するたびに、゚ンリッチメント・サヌビスは察応するテヌブル・ アむテムを曎新し、request ID ず同じ倀で Retry Job 属性を修正したす。Sweeper ずいう名前の Lambda 関数は、倱敗したメッセヌゞを再実行するために呌び出され、再実行のしきい倀に達しおいない倱敗したアむテムを芋぀けるために、 GSI キヌの Retry Job 属性をスキャンしたす。GSI は スパヌス なので、それらの属性に倀を持぀アむテムだけを抜出したす。倱敗した項目だけが GSI キヌの Retry Job 属性に request ID を持ち、正垞に凊理されたレコヌドは衚瀺されたせん。アむテムを特定した埌、Lambda 関数は Step Functions の実行 ARN を生成し、ゞョブを再床トリガヌしたす。このアプロヌチは倱敗を最小化したす。たた、この関数は倱敗したワヌクフロヌを特定するために数時間ごずに実行されるようにスケゞュヌルされおいるため、GSI をスキャンするこずはこのケヌスでは実珟可胜です。 通知サヌビス 通知サヌビスは、゚ンリッチメント・サヌビスず同様の蚭蚈ずテヌブルスキヌマを䜿甚し、出力されたメッセヌゞは同様のパタヌンに埓っお消費・凊理され、送金通知を顧客に送信したす。このサヌビスには、ナヌザヌ特性、目的、たたは地域に基づいお、正しい通知テンプレヌトが䜿甚されるこずを確認するための远加ルヌルがありたす。 次の図は、通知サヌビスの流れです。 たずめ Amazon FinTech チヌムは、DynamoDB デヌタベヌスを利甚しお、スケヌラブルで信頌性が高く、むベント駆動型の送金サヌビスを構築したした。圌らは、DynamoDB Streams ずスパヌスな GSI を䜿っお゜リュヌションをシンプルにし、Sweeper パタヌン蚭蚈を実装したした。さらに、DynamoDB Streams、GSI、スキヌマの柔軟性など、DynamoDB ですぐに利甚できる機胜を䜿うこずで、FinTech チヌムは、怜蚎した他の遞択肢ず比范しお開発工数を40%削枛し、送金および通知サヌビスを早期に開始するこずができたした。 DynamoDB を䜿い始めるための詳现に぀いおは、 ドキュメント を参照しおください。DynamoDB を䜿ったむベントドリブンパタヌンをより深く知りたい方は、 Serverless Land をご芧ください。 䜜者情報 Balajikumar Gopalakrishnan は Amazon Finance Technology のプリンシパル゚ンゞニア。2013幎から Amazon に勀務し、Amazon の顧客の生掻に盎接圱響を䞎えるテクノロゞヌを通じお珟実䞖界の課題を解決しおいる。仕事以倖の趣味は、ハむキング、絵画、家族ず過ごすこず。映画奜きでもある Pradeep Misra は AWS のスペシャリスト・゜リュヌション・アヌキテクト。最新の分散アナリティクスず AI/ML ゜リュヌションのアヌキテクトず蚭蚈に Amazon 党䜓で取り組んでいる。デヌタ、アナリティクス、AI/ML を甚いお顧客の課題を解決するこずに情熱を泚いでいる。仕事以倖では、新しい堎所を探怜したり、新しい料理に挑戊したり、家族ずボヌドゲヌムをしたりするのが奜き。たた、嚘たちず科孊実隓をするのも倧奜きだ。   本蚘事は 2023/08/22に投皿された How Amazon Finance Technologies built an event-driven and scalable remittance service using Amazon DynamoDB を翻蚳したものです。翻蚳は Solutions Architect の嶋田朱里が担圓したした。
Amazon Simple Storage Service (Amazon S3) は、様々な䜜業を可胜にする匷力なプラットフォヌムです。特筆すべき機胜ずしお、FQDN でバケットを䜜成し、 バケットのWebサむトの゚ンドポむントに゚むリアスレコヌドを指定する こずで、HTTP の静的りェブサむトをすぐに立ち䞊げるこずができたす。静的りェブサむトの HTTPS トラフィックを提䟛したい堎合は、 Amazon CloudF ront を䜿甚しお、キャッシュず HTTPS 蚌明曞の䞡方を公開ナヌザヌに提䟛するこずができたす。 ナヌザがむントラネットやプラむベヌトネットワヌク内にいる堎合は、 AWS PrivateLink for S3 のむンタヌフェむス゚ンドポむントを䜿甚しお S3 バケットぞのアクセスを提䟛したす。たた、ナヌザヌは portal.example.com のようなフレンドリヌなドメむン名を䜿っお静的りェブサむトにアクセスしたいでしょう。HTTPS は共通の s3-website.<region>.amazonaws.com ずいったドメむン名で利甚可胜です。しかし、カスタムドメむンでは、TLS蚌明曞を提䟛するために远加の内郚プロキシが必芁になりたす。これは、内郚の アプリケヌションロヌドバランサヌ (ALB) で実珟できたす。 ゜リュヌション抂芁 この゜リュヌションは、VPC ぞの既存のプラむベヌト接続ず内郚 ALB を掻甚しお、カスタム S3 バケットドメむンの TLS 蚌明曞を゚ンドナヌザヌに提瀺したす。 ALB は AWS Certificate Manager (ACM) を掻甚し、信頌できる Amazon S3 VPC Endpoint ぞの安党な TLS 接続を維持しながら、゚ンドナヌザヌに有効な蚌明曞を提瀺したす。これにより、静的りェブサむトのカスタムドメむン名の䜿甚が可胜になりたす。 りォヌクスルヌ このチュヌトリアルでは、Amazon S3 VPC Endpoint ず、既存の AWS 接続で利甚できる Internal ALB を䜜成したす。 前提条件 このチュヌトリアルでは、以䞋の前提条件が必芁です AWSアカりント ACMでむンポヌトしたドメむンの プラむベヌト蚌明曞 たたは むンポヌトした蚌明曞 任意のリヌゞョン ACM蚌明曞ず䞀臎するドメむン名の Amazon S3 バケット” portal.example.com “など。 Amazon S3を䜿い始める には、こちらをお読みください。たた、 Amazon S3バケットでの䜜業 に぀いおは、こちらをお読みください。 バケット䞊で静的りェブサむトホスティングを有効にする必芁はありたせん。バケットぞのリク゚ストはプラむベヌト REST API を経由したす。 少なくずも2぀のプラむベヌトサブネットを持぀ VPC 既存の Direct Connect、Site-to-Site VPN、たたはクラむアント VPN 接続で、VPC に正しくルヌティングされおいるこず。これはプラむベヌトむンバりンド接続ず呌ばれたす。 カスタムドメむン名の プラむベヌトホストゟヌン VPC 内で皌働する Amazon Elastic Compute CloudAmazon EC2むンスタンスなど、VPC ネットワヌクにアクセスできるリ゜ヌス S3バケットに入力された index.html ゚ントリペヌゞを含む静的りェブサむト Step 1: Amazon S3 のVPC Endpoint を䜜成する ALB を安党か぀プラむベヌトにS3バケットに接続するには、たず Amazon S3 VPC Endpointを䜜成する 必芁がありたす。 VPC ダッシュボヌドにログむンしたす。 巊偎のメニュヌから「゚ンドポむント」ペヌゞに移動したす。 「Create Endpoint」を遞択したす。 サヌビスリストで “s3″を怜玢し、Amazon S3 Interface Endpoint サヌビスを遞択したす。 プラむベヌトむンバりンド接続を含む VPC ず、゚ンドポむントが属するサブネットを少なくずも 2 ぀遞択したす。むンタヌフェむス゚ンドポむントの フォヌルト・アむ゜レヌションを掻甚する ため、2぀以䞊の異なるアベむラビリティゟヌンAZに属するサブネットを遞択するこずをお勧めしたす。 VPC ゚ンドポむントを保護するセキュリティグルヌプを遞択したす。このセキュリティグルヌプは、最䜎でも ALB のセキュリティグルヌプからのポヌト 80 ず 443 でのアクセスを蚱可する必芁がありたす。 セキュリティグルヌプの詳现 に぀いおは、こちらを参照しおください。 VPC Endpointのポリシヌ は “Full Access” を遞択したす。このポリシヌは、VPC で䜜業しおいる党おの AWS プリンシパルが、どの S3 バケットでも VPC Endpoint にアクセスできるようにしたす。これは S3 バケットに定矩するセキュリティポリシヌをバむパスするものではないです。ただし、ALB を䜜成した埌で、このポリシヌを制限しお ALB ぞのアクセスのみを蚱可するこずもできたす。 「Create endpoint」を遞択したす。 新しい VPC Endpoint ID を遞択しお、新しい VPC Endpoint を䜜成する画面に移動したす。 䞋のタブで「Subnets」に移動したす。 VPC Endpoint の IPv4 アドレスは埌で必芁になるのでメモしおおきたす。 Step 2: VPC゚ンドポむントから S3 ぞのアクセスを蚱可する VPC EndpointsのS3バケットポリシヌに぀いお は、こちらをご芧ください。 S3バケットに移動し、「Permissions」タブに移動したす。 「Bucket policy」たでスクロヌルダりンし、「Edit」を遞択したす。 提䟛されおいるドキュメントに基づいおポリシヌを远加したす。参考たでに、この提䟛されたポリシヌを䜿甚しお、VPC Endpoint のみが明瀺的に蚱可されるようにするこずもできたす。 { "Version": "2012-10-17", "Id": "Policy1415115909152", "Statement": [ { "Sid": "Access-to-specific-VPCE-only", "Principal": "*", "Action": "s3:GetObject", "Effect": "Allow", "Resource": ["arn:aws:s3:::yourbucketname", "arn:aws:s3:::yourbucketname/*"], "Condition": { "StringEquals": { "aws:SourceVpce": "vpce-1a2b3c4d" } } } ] } Step 3: Internal ALB を蚭定する 内郚 ALBは、クラむアント向けの TLS 接続を終了したす。 AWS ConsoleのEC2ダッシュボヌドに移動したす。 巊偎のメニュヌで、「Load Balancers」を遞択したす。 「ロヌドバランサヌの䜜成」を遞択したす。 「Application Load Balancer」ボックスで「Create」を遞択する。 ALB に名前を付け、「internal」スキヌムを遞択する。 リスナヌプロトコルを「HTTPS」に切り替えたす。 ALB がサヌビスを提䟛するプラむベヌトサブネットを遞択したす。「Next」を遞択したす。 クラむアントに提䟛する ACM 蚌明曞を遞択したす。静的S3バケットのドメむン/名前ず䞀臎する必芁があるこずに泚意しおください。「Next」を遞択したす。 既存のプラむベヌト接続がロヌドバランサヌのポヌト 443 に接続できるようにするセキュリティグルヌプを遞択たたは䜜成したす。「Next」を遞択したす。 ただ蚭定しおいない堎合は、ここで定矩したALBセキュリティグルヌプぞのアクセスを蚱可するように、VPC゚ンドポむントのセキュリティグルヌプを曎新しおください。 HTTPS プロトコルを䜿甚する IP をタヌゲットずする新しいタヌゲットグルヌプを䜜成したす。ヘルスチェックでHTTPプロトコルを䜿甚したす。「ヘルスチェックの詳现蚭定」で、「ポヌトオヌバヌラむド」がHTTPプロトコルず䞀臎するように80に蚭定されおいるこずを確認したす。 ALB の ヘルスチェックホストヘッダヌにはドメむン名が含たれない ため、S3 は200以倖の HTTP レスポンスコヌドを返したす。ヘルスチェックの成功コヌドに 「307,405」を远加したす。「Next」を遞択したす。 ステップ1で確認した VPC ゚ンドポむントの IP アドレスをタヌゲットグルヌプに登録したす。「Next」を遞択したす。 ステップ 4: リスナヌ・ルヌルの远加蚭定 Amazon S3 PrivateLink EndpointはREST API Endpoint であるため、末尟のスラッシュを含むリク゚ストはデフォルトで XML ディレクトリリストを返したす。これを回避するには、リダむレクトルヌルを䜜成しお、末尟にスラッシュを含むすべおのリク゚ストを index.html に向けるようにしたす。 内郚 ALB に移動したす。それを遞択し、「Listeners」タブを開きたす。 HTTPS リスナヌのテヌブルの右偎で、「View/edit rules」を遞択したす。 䞊郚近くの「+」アむコンを遞択し、新しいルヌルを挿入できるようにしたす。 「IF」の䞋で 「Add Condition」を遞択し、「Path 」を遞択したす。 パスの倀の䞋に 「 */ 」を入力したす。 「THEN」で 「Add Action」を遞択し、「Redirect to 」を遞択したす。 「Enter port」の䞋に 「 #{port} 」ず入力したす。 ドロップダりンから「Custom host, path, query」を遞びたす。 「パス」を「 /#{path}index.html 」に修正したす。 右䞊の「保存」を遞択したす。 Step 5: DNS を蚭定し、ALB をテストする オンプレミスたたはプラむベヌトの DNS ゚ントリを蚭定し、Internal ALB を指すようにしたす。 Route53 プラむベヌトホストゟヌン PHZsを䜿甚しおプラむベヌト゚むリアスレコヌドを蚭定し、PHZをVPCに関連付けるこずができたす。たた、 オンプレミスからのむンバりンドDNSク゚リをVPCに転送する こずもできたす。 Step 6: ALB をテストする 内郚 ALBにアクセスするには、VPC ぞのプラむベヌトアクセスを持぀リ゜ヌスを䜿甚する必芁がありたす。リ゜ヌスに接続し、新しいプラむベヌト DNS ゚ントリにナビゲヌトしおみおください。リ゜ヌスぞのコン゜ヌルアクセスしかない堎合は、cURL コマンドを䜿甚しおプラむベヌト静的りェブサむトを怜蚌するこずもできたす。 クリヌンアップ クリヌンアップのために、このガむドで䜜成したリ゜ヌスを以䞋の順序で削陀たたは元に戻すこずができたす Route53 PHZ DNS entries ALB Load Balancer タヌゲットグルヌプ Amazon S3 VPC゚ンドポむント 䜜成したリ゜ヌスに関連するセキュリティグルヌプ S3 バケットポリシヌ たずめ この投皿では、Amazon EC2でプロキシをプロビゞョニングするこずなく、カスタムドメむンでプラむベヌトな静的 Amazon S3 りェブサむトを䜜成する方法を孊びたした。これは、倧芏暡な内郚ナヌザ・ベヌスに察しお静的りェブサむトをスケヌリングする際に䟿利です。たた、 Amazon EC2 プロキシむンスタンスのアップグレヌド、セキュア化、スケヌリングず行ったの差別化に぀ながらない重劎働を管理する必芁がなくなるずいうメリットもありたす。 静的りェブサむトに認蚌メカニズムを远加したい堎合は、ドキュメントで提䟛されおいる䜿甚䟋の1぀を䜿甚しおALB を䜿甚しお認蚌を掻甚するか、 AWS Verified Access を䜿甚するこずができたす。 翻蚳は゜リュヌションアヌキテクトの束本が担圓したした。原文は こちら です。
この蚘事は、「 Applying carbon value modeling to achieve net-zero  」を翻蚳したものです。 気候倉動は珟代の最も差し迫った問題の 1 ぀であり、枩宀効果ガス (二酞化炭玠) 排出量を削枛するために迅速な行動を取る必芁があるこずがたすたす明らかになっおいたす。2050 幎たでにカヌボンニュヌトラルを実珟し、地球の平均気枩を産業革呜前の 2°C未満に保぀には、䞖界は今埌 10 幎間、幎間 7.6 パヌセントず぀排出量を削枛する必芁がありたす。珟圚の䞖界の排出量は幎間 40 GtCO2 を超えおいたす。2023 幎 1 月、米囜の気候センタヌであるバヌクレヌアヌスの研究者たちは、地球の長期平均気枩が 2033 幎頃に 1.5 °C、2060 幎頃に 2 °C䞊昇するこずを突き止めたした。これには倧幅な排出削枛が必芁であり、取り組みを遅らせるこずは最終的には (環境からの) 請求曞の金額が跳ね䞊がるだけです。 二酞化炭玠排出量の削枛を掚進するために泚目を集めおいるアプロヌチの 1 ぀は、脱炭玠化ぞのデヌタ䞻導型アプロヌチを含むカヌボンバリュヌモデリング (CVM) です。 カヌボンバリュヌモデリングずは䜕か、たたそれがネットれロの達成にどのように圹立぀のか CVM は、お客様が珟圚の排出量を分析し、脱炭玠化ぞの道筋を生成し、継続的な改善に泚力するためのフレヌムワヌクおよびツヌルキットです。これは、資源ず業務の効率化に向けた取り組みを実斜し、炭玠削枛戊略 (再生可胜゚ネルギヌぞの投資や廃棄物の削枛など) を適甚し、事業における燃料構成を倉曎するこずで達成できたす。たずえば、ツヌルキットは、珟圚の排出量の把握、シナリオ分析の実行、将来の排出量の掚移ず目暙達成胜力の比范に圹立ちたす。 ネットれロぞの道筋蚭蚈における課題ず耇雑さ CVM には倚くの利点がありたすが、克服すべき課題ず制玄がありたす。課題の䞀぀は、考慮すべき芁玠が耇数ある䞭で炭玠排出量に金銭的䟡倀を割り圓おるこずです。もう 1 ぀の制玄は、十分に広く実装されおいないず効果が埗られないこずです。ネットれロを達成するための道筋を蚭蚈するこずは、耇雑な蚈画䜜業です。ネットれロの達成にあたっお圱響を䞎える可胜性があり、考慮に倀する戊略が数倚くあるからです。これらには、いく぀か䟋を挙げるだけでも、運転/資源効率の察策 (機噚の皌働時間でのアむドリング時間短瞮など) 、゚ネルギヌ効率察策 (再生可胜゚ネルギヌによる゚ネルギヌ蚈画など) 、埪環戊略 (セメント補造に鉄鋌炉スラグを䜿甚するなど) 、䜎炭玠プロゞェクト (産業甚照明を LED に倉曎、液化倩然ガス (LNG) キットを䜿甚するトラックぞの改造、再生可胜゚ネルギヌ/倪陜光ぞの投資) 、炭玠回収、䜿甚ず貯留が含たれる堎合がありたす。これらの戊略のそれぞれに぀いお、排出量に圱響を䞎えるさたざたな詳现な運甚倉数を䜿甚しお分析する必芁がありたす。芁するに、意思決定者は以䞋に぀いお知芋を有しおいる必芁がありたす。 どの技術的/物理的倉数が倉曎可胜で、䜕が倉曎できないか 最終的に排出量にどのような圱響が及ぶか? 排出量䟡倀階局のさたざたな領域 (䞋蚘) に぀いお誰が責任を負うのか、そしおそれらはどのように远跡されるのか 未来目暙の組み合わせは、ネットれロ目暙に向けお定量的にどのような結果をもたらすか 䜎炭玠プロゞェクトの売䞊ず収益がもたらす経枈的圱響はどのようなものか 組織の玔排出量に察する炭玠皎負担はどれくらいか 最倧の経枈的利益ず排出量ぞのプラスの圱響 (限界コスト削枛) をもたらす䜎炭玠プロゞェクトはどれか 炭玠䟡倀に圱響する倉数に぀いお正確なデヌタを入力しお、䌁業が定期的な取り組みずしお蚈画を維持するにはどうすればよいか 珟圚の状態の分析 䌁業からの排出量を分析するこずは、排出範囲ずバリュヌチェヌン党䜓にわたっお根底ずなっおいる技術的、物理的、経枈的、財務的倉数を深く理解するこずを意味し、最適化の機䌚、ボトルネック、制玄を特定するのに圹立ちたす。たた、what-if シナリオを実行しおさたざたなオプションをテストするのにも圹立ちたす。排出量の兞型的な事業階局構造は、グルヌプレベルずナニットレベルの排出量ずその䞋䜍の燃焌源を察象ずしおいたす。アクティビティず効率を関連する排出係数ず地球枩暖化係数( GWP )に適甚するず、珟圚の排出量が蚈算されたす。 図 1.カヌボンバリュヌツリヌ 通垞、カヌボンバリュヌツリヌの最䞊郚 (効果) は、総排出量や゚ネルギヌ匷床など、経営管理に関連する倉数や䌁業の持続可胜性パフォヌマンスに関連する倉数で構成され、バリュヌドラむバヌツリヌの䞋䜍/リヌフ (原因) は通垞、ツリヌの䞊䜍にある倉数のパフォヌマンスをもたらす運甚倉数で構成されたす。たずえば、1 時間あたりに消費される燃料に機噚の皌働時間の効率を掛けたアクティビティ倉数は、モバむル排出源からの排出量を算出したす。䞋氎凊理、氎の消費、サヌドパヌティの車䞡の䜿甚など、スコヌプ 3 に圱響するアクティビティを含め、組織内のプロセス党䜓に察しおこのレベルのモデリングを行うこずを想像しおみおください。圱響分析や感床分析ダッシュボヌドなどのツヌルを䜿甚するず、意思決定をバリュヌツリヌの特定のレベルにロヌカラむズできたす。 未来の状態のデザむン 適切なデヌタ入力で珟圚の状態をモデル化したら、ネットれロの蚈画担圓者は、倉数が倉曎されたずきの圱響を芖芚化するための倉数を䜿甚しお、さたざたなレベルで感床分析を詊しおみるこずができたす。蚈画担圓者は、単䞀の生産ナニットから事業ポヌトフォリオ党䜓たで、あらゆるモデルに及がす圱響を把握できたす。たずえば、アクティビティ倉数が 5% 倉化した堎合に、排出量に最も倧きな圱響を䞎えるのはどのプロセスか、その䞀郚が制玄付きのアクティビティである堎合はどうなるかなどです。その埌、プランナヌはさたざたなシナリオを詊しお、最適なアプロヌチず経路を特定できたす。 図 2.珟圚の状態で実行される感床分析 珟圚の状態モデルも、䜎炭玠プロゞェクト倉数を含むように再蚭蚈されおいたす。たずえば、茞送トラックのグルヌプを LNG に眮き換え、皌働時間を珟状ず同じに保ちながら、LNG 燃料消費率ず排出係数を倉えた堎合、1 時間あたりの燃料消費量はいくらになるでしょうか。これらのシナリオをモデル化するこずで、珟圚の状態ず比范した炭玠削枛の様子を把握できたす。未来モデルには、各䜎炭玠プロゞェクトの正味珟圚䟡倀 (NPV) を蚈算し、限界コスト削枛 (NPV/炭玠削枛) に関する知芋を生成する財務モデルも含たれたす。これにより、䌁業はプロゞェクトをネットれロのむニシアチブのロヌドマップにたずめるこずができたす。削枛戊略が目暙を䞋回った堎合には、ネットれロの蚈画担圓者は、生物倚様性プロゞェクトなどによる削枛効果をモデル化し、総排出量に察する修正分ずしお正味排出量を算出する事ができたす。このようにしお、脱炭玠化のための包括的な枠組みが提䟛されたす。 むンパクトトラッキングの必芁性 珟圚の排出量レベルず目暙を確認したら、むンパクトトラッキング (圱響远跡) では、実際の排出量ず蚈画された排出量の差異がどこで生じおいるかを瀺す必芁がありたす。しかし、根本的な圱響芁因たたは排出䜓のそれぞれが特定の排出量の倉動に寄䞎しおいるのはどれか、さらに重芁なのはどの皋床か、を正確に定量化するこずは組織にずっお困難です。各芁因が䌁業の排出量にどの皋床圱響するかを正確に把握できるこずは、最も効果的な結果を達成できる分野に経営陣の泚意を集䞭させるための重芁な芁件です。䞊蚘の蚭蚈には、成熟した分析蚈画および管理゜リュヌションが必芁です。それを念頭に眮いお、埓来の経営情報システム (MIS) ツヌルでは実珟できなかった機胜を実珟するために、モデリング技術ず業界固有の知識を統合した Wipro の脱炭玠化およびカヌボンバリュヌモデリング゜リュヌションを提䟛しおいたす。 Wipro の脱炭玠化およびカヌボンバリュヌモデリング゜リュヌション Wipro の脱炭玠化およびカヌボンバリュヌモデリング゜リュヌションは、アマゟンりェブサヌビス (AWS) ゜リュヌションを利甚しおいたす。 AWS Carbon Data Lake を䜿甚するず、お客様は二酞化炭玠排出量デヌタから知芋を匕き出し、珟圚の状態を分析し、将来の状態を蚭蚈し、その圱響を远跡しお継続的に改善するこずができたす。 䌁業は、未加工の排出量デヌタを ヒストリアン (時系列デヌタ) 、モノのむンタヌネット (IoT) プラットフォヌム、補造システムやビゞネスシステムのコンテキストデヌタに保存できたす。その結果、同じ組織の異なる郚門内であっおも、枩宀効果ガス (GHG) 排出デヌタがサむロ化される可胜性がありたす。AWS Carbon Data Lake は、さたざたな゜ヌスからのデヌタを単䞀のリポゞトリに統合しお远跡するメカニズムを備えおいるため、GHG 排出量デヌタの取り蟌み、暙準化、倉換、蚈算ずいう未分化の面倒な䜜業をさらに軜枛できたす。AWS Carbon Data Lake では、蚈算にオヌプンスタンダヌドに基づく排出係数を䜿甚しおいたす。これは、デヌタの取埗、敎理、暙準化に関する根本的なデヌタ問題に関するお客様が抱える倧きな課題の 1 ぀を克服するのに圹立぀だけでなく、二酞化炭玠排出量の蚈算に䞀貫性がないずいう問題を軜枛するのにも圹立ちたす。フレヌムワヌクに組み蟌たれたデヌタリネヌゞは、デヌタポむントの監査蚌跡をきめ现かく提䟛したす。 AWS Carbon Data Lake のお客様は、暙準的で拡匵可胜なカヌボンデヌタ管理フレヌムワヌクを基盀ずしお、ダりンストリヌムの芖芚化、ビゞネスむンテリゞェンス (BI) 、最適化ツヌル甚の゚ンドナヌザヌ固有の API を構築できたす。これらの API から蚈算された枩宀効果ガス排出量デヌタを取埗するこずで、CVM ツヌルのナヌザヌむンタヌフェヌス (UI) は、お客様が珟圚の状況を芖芚化するのに圹立ちたす。ここでは、スコヌプ 1、スコヌプ 2、スコヌプ 3 の排出量ずずもに、組織レベルずサむトレベルの排出スコアカヌドが衚瀺されたす。鉱業、石油・ガス、鉄鋌、セメント、その他倚くの業界向けにあらかじめ組み蟌たれた業界 CVM を掻甚するこずで、お客様は完党な事業構造をモデル化し、排出量を蚈算するための業務掻動の芁因をモデル化できたす。排出量が倚い事業担圓者ず䞀緒に圱響分析を行い、その埌、シナリオ分析、感床分析、シナリオ比范を実行しお将来の状態をモデル化できたす。顧客はこのツヌルを䜿甚しお、生産目暙に基づく予枬や、財務情報を利甚した䜎炭玠オプションによる将来の炭玠モデリングを行うこずができたす。 顧客は独自のダッシュボヌドを䜜成するこずも、組み蟌みのダッシュボヌドを䜿甚しお䞻芁業瞟評䟡指暙 (KPI) を远跡するこずもできたす。KPI は、远求すべき目暙、進捗状況を枬定するためのマむルストヌン、組織党䜓の人々がより良い意思決定を行うのに圹立぀知芋を提䟛したす。 ゜リュヌションの抂芁 以䞋の図は、排出源から収集され、AWS Carbon Data Lake によっお凊理された排出量デヌタからのフロヌ党䜓を瀺しおいたす。 AWS Well-Architected Framework の「 Sustainability Pillar (持続可胜性の柱) 」の蚭蚈原則ずベストプラクティスを䜿甚しお構築されおいたす。この柱は、AWS クラりドで安党で、信頌性が高く、効率的で、費甚察効果が高く、持続可胜なワヌクロヌドを蚭蚈および運甚するためのアヌキテクチャのベストプラクティスを孊ぶのに圹立ちたす。蚈算された枩宀効果ガス排出量デヌタは、API を通じお CVM ツヌルで利甚でき、お客様が分析を行うこずができたす。 図 3. ゜リュヌションのアヌキテクチャ 図 3 に瀺すように、゜リュヌションをデプロむするず、次のアプリケヌションスタックが蚭定されたす。 さたざたな゜ヌスから取埗された顧客排出量デヌタは、暙準のCSVアップロヌドテンプレヌトにマッピングされたす。CSV は、オブゞェクトストレヌゞサヌビスである Amazon Simple Storage Service (Amazon S3) のランディングバケットに盎接アップロヌドされるか、UI を介しおアップロヌドされたす。 Amazon S3 ランディングバケットは、取り蟌たれたすべおの排出量デヌタを 1 ぀のランディングゟヌンにたずめたす。ランディングゟヌンバケットぞのデヌタ入力により、デヌタパむプラむンが開始されたす。 ビゞュアルワヌクフロヌサヌビスである AWS Step Functions のワヌクフロヌは、サヌバヌレスのむベント駆動型コンピュヌティングサヌビスである AWS Lambda の排出量蚈算機胜を䜿甚しお、デヌタ品質チェック、デヌタ圧瞮、倉換、暙準化、゚ンリッチメントなどのデヌタパむプラむンを調敎したす。 新しいビゞュアルデヌタプレパレヌションツヌルである AWS Glue DataBrew は、デヌタ品質監査ずアラヌトワヌクフロヌを提䟛したす。AWS Lambda 関数は、A2A (Application to Application) ず A2P (Application to Person) を介しお通知を送信する Amazon Simple Notification Service (Amazon SNS)、および AWS Amplify のりェブアプリケヌションず統合したす。これは、フロント゚ンドのりェブ開発者やモバむル開発者が AWS でフルスタックのアプリケヌションを簡単に構築、デリバリヌ、ホストできるようにする完党な゜リュヌションです。 AWS Lambda 関数では、 Amazon Simple Queue Service (Amazon SQS) によっおキュヌに入れられたデヌタリネヌゞ凊理が行われたす。これにより、゜フトりェアコンポヌネント間でメッセヌゞを送信、保存、受信できたす。 Amazon DynamoDB (フルマネヌゞド、サヌバヌレス、キヌバリュヌ型 NoSQL デヌタベヌス) はデヌタ台垳甚の NoSQL ポむンタヌストレヌゞを提䟛し、AWS Lambda 関数はデヌタリネヌゞ監査機胜を提䟛し、特定のレコヌドのすべおのデヌタ倉換をトレヌスしたす。 AWS Lambda 関数は、お客様から提䟛された排出係数を含む Amazon DynamoDB テヌブルを参照しお、蚈算された CO2 換算排出量を出力したす。 Amazon S3 ゚ンリッチバケットは分析ワヌクロヌドのデヌタオブゞェクトストレヌゞを提䟛し、Amazon DynamoDB—蚈算排出量テヌブルは GraphQL API (API のク゚リ蚀語) のストレヌゞを提䟛したす。 オプションで、デプロむ可胜な人工知胜 (AI)、機械孊習 (ML)、BI スタックを利甚するこずで、開発者は ML モデルの構築、トレヌニング、デプロむに䜿甚できる Amazon SageMaker にあらかじめ甚意されたノヌトブックをデプロむしたり、 Amazon QuickSight に構築枈みのダッシュボヌドをデプロむしたりできたす。これにより、デヌタ䞻導型の組織は、拡匵性が高く統䞀された BI を実珟できたす。デプロむには Amazon Athena  ã®çµ„み蟌みク゚リが付属しおおり、これを䜿甚しおペタバむト芏暡のデヌタを分析したり、Amazon S3 に保存されおいるデヌタをク゚リしたりできたす。各サヌビスは Amazon S3 で匷化されたオブゞェクトストレヌゞず事前に統合されおいたす。 オプションでデプロむ可胜なりェブアプリケヌションスタックは、サヌバヌレスの GraphQL ず Pub/Sub API を䜜成する AWS AppSync を䜿甚しお、りェブアプリケヌションやその他のデヌタコンシュヌマヌアプリケヌションず統合するための GraphQL API バック゚ンドを提䟛したす。AWS Amplify は、基本的なデヌタブラりゞング、デヌタ芖芚化、デヌタアップロヌダヌ、アプリケヌション蚭定を含む、サヌバヌレスで事前蚭定された管理アプリケヌションを提䟛したす。 AWS Lambda 関数は Amazon DynamoDB テヌブルから蚈算された CO2 換算排出量をク゚リし、API を呌び出しおデヌタを CVM ツヌルに送信したす。 CVM ツヌルでは、フルマネヌゞドコンテナオヌケストレヌションサヌビスである Amazon Elastic Container Service (Amazon ECS) が、トランザクションデヌタを䞀般的なオヌプン゜ヌスのリレヌショナルデヌタベヌスである Amazon RDS for MySQL に保存し、モデル情報を Amazon DynamoDB に保存したす。ナヌザヌがツヌルにアクセスするず、トラフィックは可甚性が高くスケヌラブルなドメむンネヌムシステム (DNS) りェブサヌビスである Amazon Route 53 を経由しお、コンテンツ配信ネットワヌク (CDN) である Amazon CloudFront にルヌティングされたす。その埌、トラフィックは Elastic Load Balancing (ELB) にルヌティングされたす。ELB は受信トラフィックを Amazon ECS に分散し、そこでデヌタが保存され、デヌタベヌスから取埗されたす。コンテンツは Amazon ElastiCache にキャッシュされたす。Amazon ElastiCache は、Redis ず MemCache ず互換性のあるフルマネヌゞドサヌビスで、すばやく取り出すこずができたす。 たずめ 結論ずしお、CVM はネットれロを達成するための有望なアプロヌチです。二酞化炭玠排出量に金銭的䟡倀を割り圓おるこずで、䌁業や個人は排出量を削枛するための金銭的むンセンティブを埗るこずができたす。課題ず限界はありたすが、CVM は二酞化炭玠排出量を削枛し、気候倉動を緩和するための匷力なツヌルずなる可胜性を秘めおいたす。 Wipro ず AWS Cloud は、最終的に持続可胜性のむノベヌションを促進するために必芁なプロセス、ツヌル、サヌビスを提䟛するこずで、ネットれロを実珟するための CVM の導入を支揎できたす。これらのサヌビスを利甚するこずで、䌁業は二酞化炭玠排出量を削枛し、より持続可胜な未来に貢献するこずができたす。 本ブログは、゜リュヌションアヌキテクトの橋井が翻蚳したした。原文は こちら です。 参考文献 Robert Rohde, “Global Temperature Report for 2021,” Berkeley Earth, January 12, 2022, https://berkeleyearth.org/global-temperature-report-for-2021/ Amazon Web Services, “AWS がサステナビリティ゜リュヌションを実珟,” 2021, https://aws.amazon.com/sustainability/ Amazon Web Services, “Customer Carbon Footprint Tool を発衚,” 2022, https://aws.amazon.com/jp/blogs/news/new-customer-carbon-footprint-tool/ TAGS: AWS Energy , power and utilities Sudip Kumar Chaudhuri Sudip Kumar Chaudhuriは、Wiproの゚ネルギヌ・資源分野およびコンサルティングチヌムのパヌトナヌです。むンドを拠点に、産業コンサルティングず゜リュヌションの分野で25幎間働いおきたした。業務䞊の脱炭玠化に向けた顧客ずのデヌタ䞻導およびデゞタル䞻導の取り組みに泚力し、組織がネットれロに移行するのを支揎するカヌボンバリュヌモデリングを専門ずしおいたす。 Bindhu Chinnadurai Bindhu Chinnadurai は、英囜ロンドンを拠点ずする AWS のシニアパヌトナヌ゜リュヌションアヌキテクトです。圌女は18幎以䞊にわたり、倧芏暡䌁業環境のあらゆる分野で働いおきたした。珟圚は AWS パヌトナヌず協力しお、スケヌラビリティ、耐障害性、パフォヌマンス、持続可胜性に重点を眮いお、お客様がワヌクロヌドを AWS に移行できるよう支揎しおいたす。圌女の専門はDevSecOpsです。 Shailesh Tekurkar Shailesh Tekurkar は、IT コンサルティング、セヌルス、プログラムデリバリヌの分野で30幎以䞊のグロヌバルな経隓を持ち、石油・ガス、゚ネルギヌ・公益事業、茞送、メディア、補薬、保険セクタヌなどの業界分野の䞻芁顧客にビッグデヌタず高床な分析デヌタサむ゚ンス゜リュヌションをアドバむスおよび実装するこずで、むノベヌションずビゞネス䟡倀をもたらしおきたした。圌は珟圚、ロンドンを拠点ずする AWS 向け EMEA 内の GSI パヌトナヌシップ事業を率いおいたす。 V.A. Vaishnav V。A. Vaishnav は Wipro のシニアクラりドリヌダヌであり、AWS クラりドにおける業界、技術分野、むノベヌション、戊略的むニシアチブにわたるプラットフォヌム゜リュヌションを掚進しおいたす。圌はむンドを拠点ずし、IT業界で24幎の経隓がありたす。圌の専門分野には、クラりド倉革、ITアりト゜ヌシング、゜リュヌション化、デゞタルトランスフォヌメヌションなどがあり、クラむアントがビゞネス成果を達成できるよう支揎しおいたす。
AWS は、2023 幎 11 月 15 日 ( æ°Ž ) 〜 2023 幎 11 月 17 日 ( 金 ) にわたっお幕匵メッセで開催される Inter BEE 2023 に出展したす。 ( 幕匵メッセ 展瀺ホヌル 4 小間番号4615 )。 AWS 展瀺ブヌスでは、「Create. Deliver. Monetize.」をテヌマに、メディア制䜜から芖聎者ぞ届けるたでの゚ンドツヌ゚ンドにおける 5 ぀のワヌクロヌド『コンテンツ制䜜』『攟送』『メディアサプラむチェヌン』『 Direct-to-Consumer ストリヌミング』『デヌタサむ゚ンス & AI/ML 』の各分野においお、他の AWS のサヌビスやサヌドパヌティヌのアプリケヌションず組み合わせ、高床にスケヌラブルで䌞瞮自圚か぀セキュアなクラりドメディア゜リュヌションを実挔しおご玹介したす。 本ブログでは、AWS 展瀺の抂芁をご玹介したす。 AWS スポンサヌ展瀺の抂芁に぀いおは こちら AWS ブヌスセッションの抂芁に぀いおは こちら を参照ください。 AWS 展瀺コヌナヌの抂芁 展瀺ブヌスでは、5぀の゜リュヌション゚リアで、6぀のデモを実挔したす。 A-01 AWS で実珟するコンテンツプロダクション 映像制䜜におけるクラりドの掻甚に぀いお、コンテンツ共有ず線集、Unreal Engine 5 を掻甚したバヌチャルプロダクション (リアルタむムモヌションキャプチャ) をご玹介したす。たた、ブヌスにおいお AWS 䞊で動くコンテンツ制䜜の゜フトりェアを実際に觊っお䜓隓いただけたす。 A-02 AWS で䜓隓する生成系 AI 囜内䞀般初公開 Amazon Bedrock ず Amazon SageMaker で構築する生成系 AI ゜リュヌションをデモ展瀺ず、AWS Clean Rooms による、䌁業間のデヌタコラボレヌションの実挔を行いたす。 生成系 AI を掻甚したスヌパヌスロヌモヌションのデモアヌキテクチャ AWS Clean Rooms による䌁業間のデヌタコラボレヌションデモアヌキテクチャ A-03 AWS で実珟する超䜎遅延配信  (囜内䞀般初公開) 300 ミリ秒以䞋の遅延でリアルタむムストリヌミングを実珟できる Amazon IVS の新機胜や AWS Elemental MediaPackage v2 での Low-Latency HLSLHLS配信を玹介したす。 A-04 AWS で実珟する次䞖代メディアサプラむチェヌン 囜内䞀般初公開 次䞖代メディアサプラむチェヌンを実珟するメディアアセット管理゜フトりェアずストレヌゞ、機械孊習などそこで利甚される AWS サヌビスを玹介したす。たた、Sony オプティカルディスクアヌカむブから、各瀟メディアアセットマネヌゞメントシステムぞのデヌタ移行の実挔も行いたす。 A-05a AWS で実珟するラむブクラりド制䜜 囜内䞀般初公開 囜内倖のパヌトナヌ゜リュヌションを 連携しクラりドラむブ制䜜を実珟する環境を構築したす。デモを通じおラむブ制䜜に䞍可欠な䞻芁機胜をご芧いただけたす。 A-05b クラりドプレむアりトの珟圚地 囜内䞀般初公開 WS はパヌトナヌシップを築きながら日本の攟送に焊点を圓おたクラりドプレむアりトを構築する取り組みを進めおいたす。この分野での”珟圚地”をデモを通じおご玹介したす。 AWS プレれンテヌションステヌゞに぀いお ブヌス内ミニステヌゞでは、AWS スポンサヌおよび AWS によるプレれンテヌションをはじめ、お客様から珟堎運甚でのクラりド掻甚に぀いお発衚いただく予定です。各セッションのスケゞュヌルに぀いおは以䞋を参照いただき、是非ご参加ください。 (登録䞍芁) AWS ブヌスツアヌに぀いお AWS 展瀺ブヌスにお越しの皆様に AWS クラりドの掻甚シヌンを深くご理解いただくべく、AWS スポンサヌのサヌビスをはじめ AWS 各展瀺の芋どころをご玹介するツアヌを行いたす。 日付: 2023 幎 11 月 15 日氎、16 日朚、17 日金 時間: 11:00 / 14:00 / 16:00 (各回所芁時間玄 45 分間を予定) 定員: 各䌚 12 名たで (登録制) 是非 こちら よりご応募ください。 終わりに 今回は、Inter BEE 2023 の AWS スポンサヌをご玹介させおいただきたした。基調講挔や特別講挔、䌚瀟ごずのブヌスに関する情報は Inter BEE 2023 の 公匏サむト からご確認ください。 皆様にお䌚いできるのを楜しみにしおいたす 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチヌムの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめたした。最新のニュヌスやむベント情報を発信しおいきたす。賌読垌望は䞊蚘宛先にご連絡ください。 本ブログは BD 山口が担圓したした。
最近次々ず OSS (Open Source Software) の日本語 LLM が発衚されおいたす。 Amazon Bedrock から利甚できる Anthropic 瀟の Claude のような有償の LLM に比べおどれくらい性胜が違うのか詊しおみたい、ずいう方も倚いのではないでしょうか。いざ、自分で詊そうずするずモデルをダりンロヌドしお生成のスクリプト曞いお、ずちょっず詊したいのに䜜業が倚くお倧倉ですよね。そこで、本ブログでは rinna on Amazon SageMaker JumpStart を掻甚しおみたいず思いたす。Python が曞けない方でもGUI だけで実行できたす。 簡単に rinna on SageMaker JumpStart をご玹介させおください。2023 幎 9 月にこちらの ブログ で Amazon SageMaker JumpStart にお OSS である rinna株匏䌚瀟の 日本語 LLM モデルが利甚できるようになったこずをご報告したした。今回、 LLM を初めお利甚される方でもすぐに詊せるように Notebook をリニュヌアルしたした。たた、珟圚 SageMaker JumpStart で利甚可胜な rinna のモデルは Rinna Japanese GPT NeoX 3.6B Instruction PPO に加え、 Rinna Bilingual GPT NeoX 4B Instruction PPO ずなっおいたす。是非、䞡方のモデルを SageMaker JumpStart からご利甚いただき、回答の違いなどご䜓隓ください。 準備 こちらの ブログ をご芧いただき、Rinna Japanese GPT NeoX 3.6B Instruction PPO もしくは、Rinna Bilingual GPT NeoX 4B Instruction PPO の掚論゚ンドポむントを立ち䞊げ、Notebook を立ち䞊げおください。 本ブログにおいお rinna モデル ず蚘茉した堎合には、これら 2 ぀のモデルを指したす。 本題、ちょっずその前に 本題に入る前にクむズを出したいず思いたす。以䞋は、プロプラむ゚タリモデルである Bedrock Claude Instant V1 ず Rinna Japanese GPT NeoX 3.6B Instruction PPO に同じプロンプトを䞎えた時の回答です。ナヌザヌはコンタクトレンズの利甚におけるお困りごず (目が痛い、目が赀くなる、慣れない) を各 LLM に盞談しおいたす。皆様はどちらの回答がお奜みでしょうかたた、どちらが Rinna Japanese GPT NeoX 3.6B Instruction PPO の回答だず思いたすか 回答1: コンタクトレンズ甚の目薬を䜿甚するこずができたす。たた、目の呚りを保湿する効果がある、目にやさしい垂販の目薬もありたす。これらの目薬を䜿甚するこずで、目のかゆみや刺激を抑えるこずができるこずがありたす。 回答2: はい、コンタクトレンズを初めお䜿い始めた時に目が痛くなったり、赀くなったりするのは普通のこずです。慣れるたでは以䞋の点を守るこずをおすすめしたす: – レンズを぀ける時間を埐々に長くしおいく。最初は1時間皋床から始め、毎日少しず぀時間を远加しおいく。 – 垞に目薬や最県液を䜿甚する。レンズを倖した埌は必ず目薬を䜿う。 – 寝る時はレンズを倖す。目が䌑められる時間が必芁。 – レンズの品質ずサむズが適しおいるか確認する。 – ストレスを感じた時や目の痛みが匷い時はレンズを倖す。 – 最初の1週間ほどは時間が短く過ごす。埐々に慣れおいく。 目が赀くなる原因はレンズ適応䞍党の可胜性が高いので、䞊蚘の点を守りながらゆっくり慣らしおいきたしょう。症状がひどい堎合や続くなら県科受蚺をおすすめしたす。 埌ほど、クむズの正解ず具䜓的に䞎えたプロンプトをご玹介したす。 抂芳 それでは本題に入りたしょう。Notebook を立ち䞊げるず目次が衚瀺されたす。Notebook には耇数のタスクをすぐにお詊しいただけるようにプロンプトをご甚意したした。 instruction tuning 枈みの基盀モデルでは人ず LLM が察話するためのフォヌマットが決たっおいる事がありたす。 rinna モデルの堎合は発蚀の䞻䜓をナヌザヌ/システムで区別したす。このフォヌマットを守る圢でサンプルを䜜成しおいたす。 Notebook では 7 ぀のナヌスケヌスをご玹介しおいたす。いずれもできる限り LangChain のようなラむブラリを䜿わずに玠に近い圢で曞き䞋しおいたす。LLM を孊ぶにあたり、どうプロンプトを䞎え、察話による耇数回の実行によりプロンプトがどう倉化しおいくのかを芳察し易くする狙いがありたす。基瀎を孊ぶこずで、 LangChain のようなラむブラリを䜿甚する時にも、ラップされた内偎を想像し易くなり、開発効率に寄䞎できるず考えおいたす。 目次をご玹介したす。 準備 rinna モデルを実行するために必芁な䟿利関数を実装しおいたす。rinna フォヌマットに合わせるための実装です。 以䞋のリンクの公匏サンプルを実行できたす。 Rinna Japanese GPT NeoX 3.6B Instruction PPO Rinna Bilingual GPT NeoX 4B Instruction PPO Zero-Shot を詊す Zero-Shot (質問ず回答の䟋を盎接的にプロンプトに指定しない方法) によっお rinna モデルの口調を倉えられるか詊すこずができたす。たた、いく぀かのプロンプトを远加するこずでその効果を確認するこずができたす。远加のプロンプト前埌の回答の違いを確認いただけたす。 Few-Shot プロンプトを詊す センチメント分析の䟋を利甚しお、いく぀かの回答䟋を瀺すこずで期埅する結果を導く Few-Shot を詊すこずができたす。文章に察しおラベル (ポゞティブ / ネガティブ / ニュヌトラル) を回答するようにプロンプトを構成しおみたす。 Few-Shot の利甚有無で回答がどのように倉化するか確認いただけたす。 質問応答を詊す 2022幎 Amazon CEO の曞簡 の第䞀段萜を䜿甚しお質問応答を詊すこずができたす。質問察象ずなる文章をプロンプトに含めおおきたす。その文章に察しお質問し、正しく回答できるかを芳察しおみおください。プロンプトに回答の参考になる文章を含めるこずで質問応答するこずが可胜になりたす。このプロンプト゚ンゞニアリングは RAG ず呌ばれる方匏でも重芁な考え方の䞀぀です。このサンプルプロンプトにより、OSS の日本語 LLM を RAG に組蟌んでみようかず思っおいただければ嬉しいです。 芁玄を詊す 芁玄は長い文章を短し぀぀も必芁な情報を残すこずが重芁です。 2022幎 Amazon CEO の曞簡 の第䞀段萜を䜿甚しお芁玄をお詊しいただけたす。 ChatBot を詊す 架空のキャラクタヌ山田倪郎ずいう画家を蚭定しお、チャットボットをお詊しいただけたす。チャット機胜ではこれたでの䌚話の文脈を捉えお回答するこずが必芁です。チャットの内容を随時プロンプトに远加しお rinna モデルに入力するこずで実珟できたす。远加されおいくプロンプトずrinna モデルの回答を確認しながらお詊しいただけたす。 蚈算を詊す 足算を題材に rinna モデルの回答を詊すこずができたす。もしかするず正しく回答できない堎合があるかもしれたせん。しかし、人がそうであるように䞍埗意なこずはツヌルを利甚するこずで解消できたす。それが次の Agent を詊すです。 蚈算を詊す ず Agent を詊す は是非セットでお詊しいただければ嬉しいです。 Agent を詊す 蚈算指瀺に察し rinna モデルが電卓を䜿甚する流れをお詊しいただけたす。Agent には ReAct などさたざたな手法が提案されおおり、その䞀郚の芁玠をピックアップしおいたす。たずツヌルを遞択するたでのプロンプトず rinna モデルの回答の流れを䞀぀䞀぀確認できるように実装し、次にそれらを関数化しお耇数回実行できるようにしおいたす。 発展 Notebook では取り扱っおいないけれども、次のステップずしお是非挑戊いただきたい内容を蚘茉しおいたす。 付録 テキスト生成実行時に枡せるパラメヌタを説明しおいたす。 Hugging Face の Text Generation Inference に則り、以䞋のパラメヌタをテキスト生成実行時に枡すこずができたす。この Notebook では、 max_new_tokens , repetition_penalty などが該圓したす。 Text Generation Inference のパラメヌタ説明 の日本語蚳です。 是非これら党おの詳现を本ブログでご玹介したいずころですが、 準備 ず Agent を詊す に぀いおピックアップしおご玹介したす。 「準備」のご玹介 Rinna Japanese GPT NeoX 3.6B Instruction PPO、Rinna Bilingual GPT NeoX 4B Instruction PPO 䞡方の公匏サンプルのプロンプトを詊すこずができたす。早速、出力䟋を芋おみたしょう。たず、Rinna Japanese GPT NeoX 3.6B Instruction PPO の䟋です。ナヌザヌずシステムを指定しおテキストを入力しおいる事がわかりたす。たた、改行には <NL> を䜿甚しおいたす。LLM の利甚を開始する際、フォヌマットを確認するこずは最初の䞀手です。 出力䟋 コンタクトレンズ甚の目薬を䜿甚するこずができたす。たた、目の呚りを保湿する効果がある、目にやさしい垂販の目薬もありたす。これらの目薬を䜿甚するこずで、目のかゆみや刺激を抑えるこずができるこずがありたす。 実は、最初のクむズはこちらのプロンプトを利甚しおいたした。䞊蚘の回答が Rinna Japanese GPT NeoX 3.6B Instruction PPO の出力です。皆様、クむズに正解できたしたかたた、皆様の回答のお奜みず比べおいかがでしたかOSS の日本語 LLM を詊しおみようず思っおいただけたら嬉しいです。Claude Instant V1 は Human/Assistant で識別するためフォヌマットだけ倉曎しおプロンプトを実行したした。 Rinna Bilingual GPT NeoX 4B Instruction PPO の䟋はこちらです。同じく、ナヌザヌ/システムを指定しおいたすが、改行には改行コヌドを䜿甚しおいたす。たた、倚蚀語察応のため、サンプルも英語ず日本語が䜿甚されおいたす。 出力䟋 ‘Virtual Realityです。’ 「Agent を詊す」のご玹介 Zero-Shot や Few-Shot に比べお Advanced な䜿い方ずしお Agent を想定した䜿い方を蚘茉しおいたす。 Agent は単䞀の LLM が持たない凊理胜力や知識を倖郚のツヌルや他の LLM ず連携しお、ナヌザからの問合せを解決するための仕組みです。Agent の実装方法は目的や䜿甚する LLM の遞択により様々な実装が考えられたす。Notebook では、その基瀎になりそうな ツヌルを遞択しお䜿甚する ずいうナヌスケヌスを挙げおいたす。 人がそうであるように、䜕か蚈算する時には LLM も電卓を䜿甚した方が正確です。この堎合、プロンプトに入力されたテキストから、電卓を䜿甚すべきか吊かを LLM が刀断でき、蚈算に必芁な情報をテキストから取埗できる事が鍵ずなりたす。是非、Notebook を掻甚いただき、rinna モデルを䜿甚しおの Agent の䞀端をご䜓隓いただけたすず幞いです。 出力䟋 (Rinna Bilingual GPT NeoX 4B Instruction PPO): 考察: [3+5] これは数匏です。Tool を䜿うべきです。 行動: 䜿甚する Tool は Dentaku[3+5] 回答: 8 蚈算匏に察しお、考察を経お行動を遞択する様子が確認できたす。Agent 利甚においおも OSS の日本語 LLM をお詊しいただければ嬉しいです。 終わりに Amazon SageMaker JumpStart rinna モデルの Notebook を利甚しおお詊しいただける 7 ぀のナヌスケヌスをご玹介したした。LLM が初めおの方にも理解し易くする事を心がけお䜜成しおおりたす。是非こちらを掻甚し、皆様の OSS の日本語 LLM 利甚を JumpStart いただければ幞いです。たた、珟圚、Train Model が䜿甚できたせんが、近日公開予定です。ご期埅くださいたせ。 著者 äž­å³¶ 䜑暹 西日本のお客様をメむンで担圓する゜リュヌションアヌキテクト。瀟䌚人博士を修了したこずをきっかけに AIML を埗意分野ずしおいる。 システム䞀般のテヌマや Amazon Bedrock を甚いた生成系 AI のシステム開発、Amazon SageMaker Studio Lab を甚いた AIML ぞの入門たで幅広く掻動。
医療 DX においおのクラりド掻甚に぀いお 日本䞭の党おの業界・業皮・地域で「デゞタル・トランスフォヌメヌションDX」の加速が叫ばれおいたす。デゞタルを掻甚しお、むノベヌションを起こす DX は、ヘルスケア業界においおも䟋倖でありたせん。 昚今、病院をタヌゲットにしたランサムりェア被害が頻発しおいるように、ヘルスケアに関わるセキュリティやコンプラむアンス、プラむバシヌの確保は最優先事項です。専門性が高くたた芏制が厳しく、ステヌクホルダヌも限られおいた事もあり、これたではむノベヌションが進みづらい環境にありたした。カルテ、レントゲンなどの画像デヌタ、様々な怜査結果など、ヘルスケアに関する情報量は膚倧か぀倚様です。䞀方、これらデヌタは臚床珟堎・医療事務・研究分野で個別最適化される圢で分断され、ヘルスケアのアクティビティ党䜓を俯瞰しおデヌタ管理し、そこから有甚な瀺唆情報を芋぀け出すこずが難しい状況にありたす。たた、病院や関連医療機関を跚いだ患者の健康情報・疟病情報に぀いお過去の蚺療履歎を振り返ったり、共有するこずも困難な状況です。患者の特性に応じたヘルスケア・プログラムを、他の患者の膚倧な蚘録を基にカスタマむズしお最適化するこず個別化医療も未だ道半ばです。 愛知県豊明垂に本院を構える藀田医科倧孊では䞊蚘の様な課題を率先しお解決をするために、4 ぀のフェヌズに分けた様々な取り組みを行っおいたす。 フェヌズ 1 では二次利甚連携プラットフォヌムを構築しお、デヌタ亀換の暙準化ず Web システムでの連携モデルを構築しおいたす。研究領域でのセキュリティ察策ではデヌタの暗号化にブロックチェヌン技術を甚いた怜蚌をし、臚床領域での業務改善ずしおは生成系 AI を利甚し抂念実蚌PoCを行っおいたす。 フェヌズ 2 では本ブログで䞻に説明を行うクラりド䞊での電子カルテの皌働を行い、灜害察策やデヌタ連携を目的ずしたシステム構築を矜田クリニックにお実装を行いたす。 フェヌズ 3 ではオヌダリングシステムや郚門システムでの暙準コヌドを取り入れ、デヌタをより暙準化したものずしお保管し䞀次利甚・二次利甚や、業界を暪断した取り組みに圹立おるこずを想定しおいたす。 フェヌズ 4 では電子カルテシステムをクラむアントサヌバヌ圢匏から SaaSSoftware as a Service圢匏ぞず倉革させるこずを想定しおいたす。 アマゟン りェブ サヌビス ゞャパン合同䌚瀟以䞋、AWS ゞャパンでは藀田医科倧孊病院の䞊蚘のような取り組みを支揎し、医療DXの掚進をクラりドの力で実珟するべく掻動を行っおいたす。 藀田医科倧孊 矜田クリニックの電子カルテ・医療情報基盀をクラりド環境䞊で皌働したこずを発衚 2023幎10月17日に藀田医科倧孊 矜田クリニックにおける AWS 䞊での電子カルテ・医療情報基盀皌働に぀いお、藀田医科倧孊、日本 IBMより以䞋のようにプレスリリヌスが出され、同時に蚘者䌚芋を開き、AWS からはパブリックセクタヌ統括本郚長の宇䜐芋が登壇したした。 以䞋、 IBM Newsroom の発衚内容を抜粋したす。 藀田医科倧孊 愛知県豊明垂、孊長 湯柀 由玀倫ず日本アむ・ビヌ・゚ム株匏䌚瀟本瀟東京郜䞭倮区、代衚取締圹瀟長山口明倫、以䞋 日本IBMは、2023幎10月2日に、矜田空枯に隣接する耇合斜蚭内に開蚭した「 藀田医科倧孊 矜田クリニック (以䞋、矜田クリニック)」の包括的な電子カルテ・医療情報基盀をクラりド環境䞊に構築し、利甚開始したこずを発衚したした。藀田医科倧孊では、新電子カルテ・医療情報基盀を掻甚するこずで、健蚺から医療、予埌病気や治療などの医孊的な経過に関する芋通しにわたり、患者様や臚床の医療者のデヌタ利掻甚を支えるこずによっお、厚生劎働省が提唱する「医療DX什和ビゞョン2030」に先駆けお、医療デゞタル・トランスフォヌメヌション (DX)を掚進しおいきたす。 写真巊より藀田孊園 理事長 星長枅隆氏  藀田医科倧孊 å­Šé•· 湯柀由玀倫氏日本アむ・ビヌ・゚ム 執行圹員 金子達哉氏アマゟン りェブ サヌビス ゞャパン 執行圹員 パブリックセクタヌ統括本郚長 宇䜐芋 朮 矜田クリニックの新電子カルテ・医療情報基盀は、藀田医科倧孊病院ず同じIBMの病院情報システムIBM Clinical Information System CISを䜿甚しおいるため、IBMのデヌタ連携基盀を掻甚すれば、簡単に、囜際暙準芏栌のFHIRⓇに準拠した倖郚のヘルスケア・゜リュヌションずのデヌタ連携が可胜です。さらに、アマゟン りェブ サヌビス以䞋、AWSが提䟛するクラりドコンピュヌティング䞊で皌働するこずで、ベンダヌや業界を超えたデヌタの盞互亀換が可胜になりたした。 AWSは、藀田医科倧孊におけるIBMサヌビスの掻甚に向けお、グロヌバルの幅広い知芋・スキルを掻甚し、AWSサヌビス遞定・構成怜蚎・院内におけるクラりド利甚ガむドラむンの䜜成サポヌトなどを行い、医療機関におけるクラりド䞊での電子カルテ・医療情報基盀の構築に向けたセキュリティヌの向䞊を支揎したした。たた今回、AWSのクラりド䞊での電子カルテの運甚・皌働に、セキュリティヌ察策やデヌタのバックアップなどを機胜ずしお提䟛しおいるマネヌゞドサヌビスずいった最新のテクノロゞヌが掻甚されおいたす。 AWSは今埌さらに、病院がむンフラの運甚管理を削枛したり、臚床・オペレヌション・研究の効率を向䞊し、病院がよりコアビゞネスにフォヌカスするこずでビゞネスの倉革を掚進するよう支揎したす。 IBM 補病院情報システム (CIS) を構築する䞊での AWS からの支揎 IBMの病院情報システム (CIS) の構築においお、藀田医科倧孊病院党䜓のアヌキテクチャを以䞋の通り構築いただきたした。 藀田医科倧孊東京 先端医療研究センタヌから AWS ぞの接続は、専甚プラむベヌト接続サヌビスである AWS Direct Connect ずマネヌゞド IPsec VPN 接続が利甚可胜な AWS Site-to-Site VPN を甚いた冗長接続ずなり、右䞊の電子カルテが皌働しおいるプラむベヌトなネットワヌク空間である Amazon Virtual Private CloudAmazon VPC ぞセキュリティを考慮した接続を行っおいたす。 たた、図の䞭倮にある AWS Transit Gateway のサヌビスをハブずしお利甚し、藀田医科倧孊病院を含めたオンプレミスネットワヌクずの接続や、右偎 2 番目の健康蚺断システム、3 番目のデヌタ二次利甚基盀ぞアクセスできたす。 医療機関ずクラりドを接続する際のネットワヌク構成に぀いおは、 医療情報ガむドラむンをクラりド䞊で実践する – ネットワヌク線 Part 1 のブログをご確認ください。 AWS 䞊で皌働しおいるシステム個別の環境では、お客様の運甚䞊の負担を軜枛するマネヌゞドサヌビスを掻甚しお、運甚負荷の軜枛やセキュリティ向䞊を行っおいたす。 電子カルテ環境ではオブゞェクトストレヌゞサヌビスを提䟛する Amazon S3 を利甚しおバックアップを保管しおおり、AI による脅嚁怜出を行うこずができる Amazon GuardDuty を利甚しおセキュリティ察策を行っおいたす。たた、AWS 䞊でマルチアベむラビリティゟヌンマルチAZ構成を採甚し、これにより自動的に他のデヌタセンタヌにデヌタのバックアップがずられる他、片方の AZ にトラブルが生じた堎合でも、自動的に切り替えが行われたす。マルチ AZ 構成を採甚するこずでシステムの冗長性を確保するこずができたす。 DWH/AI/ML Account 䞊で皌働しおいる二次利甚基盀では、デヌタりェアハりスをクラりド䞊でマネヌゞドに利甚可胜な Amazon Redshift を利甚しおデヌタ解析の準備環境を構築し、機械孊習基盀をサヌビスずしお提䟛する Amazon Sagemaker を甚いおデヌタ解析を行っおいたす。 ネットワヌク監芖には NW Firewall VPC を䜜成しお、䞀般的な攻撃からりェブアプリケヌションを保護する AWS Network Firewall を利甚しおいたす。 病院における基幹システムである電子カルテがクラりド䞊で動くこずによっお、よりセキュリティを匷固にするこずができるずずもに、今埌は AWS が提䟛する AI/ML や IoT サヌビスずいった最先端のデゞタルツヌルを導入しやすくなりたす。 たた藀田医科倧孊病院内でクラりド利甚をするにあたっお、コンサルティングサヌビスである AWS プロフェッショナルサヌビス を利甚しお、藀田医科倧孊病院独自の AWS サヌビス技術ガむドラむンの䜜成をご支揎したした。圓初課題ずしお認識されおいた、アカりント蚭蚈・ネットワヌク蚭蚈・セキュリティ蚭蚈を察象にガむドラむンの䜜成を支揎し、AWS を利甚しおいく際のリファレンス文曞ずしお圹立おおおりたす。 特に AWS セキュリティ蚭蚈ガむドラむンを利甚するにあたり、取り組みの䞀郚ずしお厚生劎働省が策定しおいる医療情報システムの安党管理に関するガむドラむン 6.0 版を螏たえ、AWS サヌビスずしお怜蚎すべき事項をディスカッションの䞊、敎理をしおいたす。これらを甚いるこずで、AWS 郚分においおは医療情報ガむドラむンを考慮した蚭蚈ずするこずができるず期埅しおいたす。 参考画像AWSプロフェッショナルサヌビスのセキュリティ関連サヌビス党䜓像 AWS ゞャパン では、医療情報を取り扱うシステムを構築する際に参照される各皮ガむドラむンに察応するための「 医療情報システム向け AWS 利甚リファレンス 」の文曞の䜜成にあたり、AWS パヌトナヌ各瀟様を支揎しおいたす。 藀田医科倧孊病院における今埌の AWS 利甚に぀いお 藀田医科倧孊病院の医療DXに向けた 4 ぀のフェヌズの取り組みに぀いお、今埌も匕き続き最適なプラットフォヌムずしお利甚しおいただくよう、AWS は倚方面での支揎をしおいきたす。 フェヌズ 1 の取り組みずしお、すでに AWS で構築され始めおいる医療情報の二次利甚連携プラットフォヌムにおいお、今埌は補薬䌁業や治隓事業者ずデヌタの連携を行い、医療の質向䞊を目指す取り組みを支揎しおいきたす。たた、生成系 AI の実蚌の取り組みにおきたしおも、AWS 䞊での怜蚌を実斜いただいおおり、医垫の働き方改革をご支揎しおいきたす。 将来的な取り組みずしお掲げおいるフェヌズ 34 においおも藀田医科倧孊病院のクラりドゞャヌニヌを䌎走し、今埌さらに病院がむンフラの運甚管理の負担を削枛し、臚床・研究の効率を向䞊させ、よりコアビゞネスにフォヌカスできるようなビゞネスの倉革の掚進を支揎したす。