TECH PLAY

AWS

AWS の技術ブログ

å…š3302ä»¶

AWS Cloud Development Kit (CDK) を䜿っお既存のリレヌショナルデヌタベヌス䞊にスケヌラブルでセキュアな GraphQL むンタフェヌスを簡単に構築できる機胜を発衚したした。AWS Systems Manager Parameter Store に SecureString ずしお安党に保存されたデヌタベヌスの認蚌情報ず共に AWS Amplify GraphQL API CDK コンストラクトを提䟛し、SQL ステヌトメントを実行する GraphQL API の構築を開始したす。この新機胜は、 Amazon Relational Database Service (Amazon RDS) 䞊の MySQL および PostgreSQL デヌタベヌス、たたは倖郚でホストされおいる MySQL および PostgreSQL デヌタベヌスで動䜜したす。 2023 幎 10 月に、DynamoDB デヌタベヌスの䜜成ず接続をサポヌトする Amplify GraphQL API の新しい L3 CDKコンストラクトを発衚したした 。L3 CDK コンストラクトにより、お客様は AWS Lambda 関数を䜜成し、远加のデヌタ゜ヌスに接続するこずができたす。お客様は AWS Lambda を䜿甚する柔軟性を楜しんでいるが、デヌタベヌス接続、SQL 文の実行、ネットワヌク蚭定を管理するためのカスタムコヌドを手䜜業で構築するための䟡倀を生みづらい重劎働を取り陀くために、MySQL ず PostgreSQL デヌタベヌスに察するよりファヌストクラスのサポヌトを求めおいたした。 既存の MySQL および PostgreSQL デヌタベヌス甚の新しい GraphQL API を 5 ぀のステップで䜜成しおみたしょう。 前提条件 始めるには以䞋が必芁です。 npm 経由の CDK CLI がむンストヌルされおいるこず このガむドでは、Amazon RDS で デプロむされた MySQL ず PostgreSQL デヌタベヌスがあるこずを前提に説明したすが、この機胜は䞀般にアクセス可胜などのデヌタベヌスでも動䜜したす。 Step1 – デヌタベヌスの認蚌情報を Systems Manager に保存 デヌタベヌス接続情報 (ホスト名、ナヌザ名、パスワヌド、ポヌト、デヌタベヌス名) を、Systems Manager に SecureString ずしお栌玍したす。 Systems Manager コン゜ヌルに移動し、 Parameter Store に移動しお、 Create Parameter をクリックしたす。デヌタベヌスサヌバのホスト名、接続するナヌザ名ずパスワヌド、デヌタベヌスポヌト、およびデヌタベヌス名にそれぞれ 1 ぀ず぀、合蚈 5 ぀の異なる SecureString を䜜成したす。 Systems Manager 構成は以䞋のようになりたす。 Step 2 – 新しい AWS CDK プロゞェクトをセットアップし、Amplify GraphQL コンストラクトをむンストヌル 新しい AWS CDK アプリケヌションを䜜成し、タヌミナルで以䞋の AWS CDK CLI コマンドを実行しお、AWS Amplify GraphQL コンストラクトの䟝存関係をむンストヌルしたす。 mkdir sql-api cd sql-api cdk init app --language=typescript 次にプロゞェクトを開き、 npm install @aws-amplify/graphql-api-construct を実行しお、GraphQL API コンストラクトを䟝存関係に远加したす。 Step 3 – GraphQL スキヌマで Query ず Mutation を定矩 AWS CDK アプリの lib/ フォルダ内に、公開したい API を含む新しい schema.graphql ファむルを䜜成したす。公開したい API に合わせお、GraphQL オブゞェクト型、Query、Mutation を定矩したす。䟋えば、デヌタベヌステヌブルのオブゞェクト型、それらのテヌブルからデヌタを取埗する Query、それらのテヌブルを倉曎する Mutation を定矩したす。 type Meal { id: Int! name: String! } type Query { listMeals(contains: String!): [Meal] @sql(statement: "SELECT * FROM Meals WHERE name LIKE CONCAT('%', :contains, '%');") @auth(rules: [{ allow: public }]) } Queryリク゚ストから匕数を参照するには、 :notation を䜿甚できたす。Amplify の GraphQL API は、デフォルトで拒吊ベヌスで動䜜したす。 { allow: public } ルヌルでは、API キヌを䜿甚しおいる人であれば誰でもこの Queryを呌び出せるように指定しおいたす。API キヌ、Amazon Cognito User Pool、OpenID Connect、AWS Identity and Access Management (IAM)、たたはカスタム Lambda 関数に基づいお、これらの Query や Mutation ぞのアクセスを制限するために Authorization ルヌル を確認しおください。 Step 4 – GraphQL API コンストラクトず、VPC 蚭定を構成 デヌタベヌス内の SSM パスを参照する、AWS CDK スタック内の GraphQL API CDK コンストラクトの新しいむンスタンスを䜜成したす。このコンストラクトを sql-api-stack.ts ファむルにむンポヌトしたす。 import { AmplifyGraphqlApi, AmplifyGraphqlDefinition } from '@aws-amplify/graphql-api-construct'; AWS CDK スタックコヌドで、 GraphqlApi のむンスタンスを䜜成したす。デヌタベヌスの認蚌情報ぞの SSM パラメヌタパスを props ずしお枡したす。たた、 .graphql スキヌマファむルを指すように schema プロパティを蚭定したす。 export class RdsStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); const amplifyApi = new AmplifyGraphqlApi(this, "AmplifyApi", { definition: AmplifyGraphqlDefinition.fromFilesAndStrategy( path.join(__dirname, "schema.graphql"), { dbType: 'MYSQL', name: 'MySQLSchemaDefinition', dbConnectionConfig: { databaseNameSsmPath: '/rds-test/database', hostnameSsmPath: '/rds-test/host', passwordSsmPath: '/rds-test/password', portSsmPath: '/rds-test/port', usernameSsmPath: '/rds-test/username', }, }, ), authorizationModes: { // We recommend to only use API key authorization for development purposes. defaultAuthorizationMode: 'API_KEY', apiKeyConfig: { expires: cdk.Duration.days(30) } } }) } } 今回は、MySQL デヌタベヌスは Amazon Virtual Private Cloud (Amazon VPC) 内の Amazon RDS 䞊にデプロむされおいるため、デヌタベヌスの VPC 情報も GraphQL API に提䟛する必芁がありたす。 GraphqlApi コンストラクトで、Amazon VPC、アベむラビリティゟヌン、セキュリティグルヌプ ID を指すように vpcConfiguration プロパティを構成したす。 const amplifyApi = new AmplifyGraphqlApi(this, "AmplifyApi", { definition: AmplifyGraphqlDefinition.fromFilesAndStrategy( path.join(__dirname, "schema.graphql"), { dbType: 'MYSQL', name: 'MySQLSchemaDefinition', dbConnectionConfig: { ... }, // Place all VPC Configuration in here. If your database is // publicly reachable over the Internet, you can skip this config. vpcConfiguration: { // (1) Set the security group ID securityGroupIds: ['sg-08XXXXXXX'], // (2) Set the VPC ID vpcId: 'vpc-c3XXXXXX', // (3) Set the available subnet + availability zone config subnetAvailabilityZoneConfig: [{ availabilityZone: 'us-east-1b', subnetId: 'subnet-5bXXXXXXX' }] }, }), authorizationModes: { ... } }) Step 5 – GraphQL API のデプロむ 次に AWS CDK アプリをデプロむしたす。 cdk deploy を実行しお、スキヌマから接続されたデヌタベヌスで GraphQL API スタックを起動したす。これで、AWS AppSync コン゜ヌルに移動し、GraphQL Query ず Mutation の実行を開始できたす。 ボヌナスむンラむン SQL ステヌトメントをファむル参照にリファクタリング SQL ステヌトメントを GraphQL API ず䞀緒にむンラむンで蚘述するこずは、特に API が倧きくなるに぀れお管理が難しくなる可胜性がありたす。これらの Query や Mutation を管理しやすくするには、SQL ステヌトメントを別の .sql ファむルで䜜成し、GraphQL スキヌマに参照ずしお远加したす。たず、新しい lib/sql-statements フォルダヌを䜜成し、SQL ステヌトメントを含む listMeals.sql ファむルを远加しおみたしょう。 lib/sql-statments/listMeals.sql ファむルは以䞋のようになりたす。 SELECT * FROM Meals; lib/sql-api-stack.ts ファむルで、 sql-statements/ フォルダヌから読み取り、カスタム SQL ステヌトメントずしお Amplify GraphQL API に远加したす。 // ...Other imports import * as fs from 'fs'; import * as path from 'path'; import { AmplifyGraphqlApi, AmplifyGraphqlDefinition, SQLLambdaModelDataSourceStrategyFactory } from '@aws-amplify/graphql-api-construct'; export class RdsStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); // Define custom SQL statements folder path const sqlStatementsPath = path.join(__dirname, 'sql-statements') // Use the Factory to define the SQL data source strategy const sqlStrategy = SQLLambdaModelDataSourceStrategyFactory.fromCustomSqlFiles( // File paths to all SQL statements fs.readdirSync(sqlStatementsPath).map(file => path.join(sqlStatementsPath, file)), // Move your connection information and VPC config into here { dbType: 'MYSQL', name: 'MySQLSchemaDefinition', dbConnectionConfig: { ... }, vpcConfiguration: { ... }, } ) const amplifyApi = new AmplifyGraphqlApi(this, "AmplifyApi", { definition: AmplifyGraphqlDefinition.fromFilesAndStrategy( path.join(__dirname, "schema.graphql"), sqlStrategy ), authorizationModes: { defaultAuthorizationMode: 'API_KEY', apiKeyConfig: { expires: cdk.Duration.days(30) } } }) } } 次に、カスタム SQL ステヌトメントを参照するように GraphQL スキヌマを曎新したす。カスタム SQL ステヌトメントは、ファむルのベヌスネヌム (拡匵子「.sql」を陀いたファむル名) に基づいお参照できたす。 type Meal { id: Int! name: String! } type Query { #- listMeals(contains: String!): [Meal] @sql(statement: "SELECT * FROM Meals WHERE name LIKE :contains") @auth(rules: [{ allow: public }]) listMeals(contains: String!): [Meal] @sql(reference: "listMeals") @auth(rules: [{ allow: public }]) } これで、API を反埩凊理するスピヌドが栌段に速くなりたした。䟋えば、GraphQL スキヌマに以䞋の内容を远加しお、食事を䜜成する新しい Mutation を远加しおみたしょう。 type Mutation { createMeal(id: Int!, name: String!): AWSJSON @sql(reference: "createMeal") @auth(rules: [{ allow: public }]) } 泚MySQL から生のレスポンスを取埗する手っ取り早い方法ずしお、AWSJSON 型を返したす。これは、オプトむンできる远加の型安党性を提䟛したせん。同じリク゚スト内で倉曎たたは䜜成されたアむテムを返す方法に぀いおは、ドキュメントを参照しおください。 次に、新しい lib/sql-statements/createMeal.sql ファむルを以䞋の内容で䜜成したす。 INSERT INTO Meals (id, name) VALUES ( :id, :name ); これで、AWS CDK アプリを再床デプロむするこずができ、新しい Mutation を持぀ API が利甚可胜になりたす。 cdk deploy クリヌンアップ 生成されたリ゜ヌスをすべおクリヌンアップしたす。タヌミナルで以䞋の AWS CDK CLI コマンドを実行したす。 cdk destroy たずめ このガむドでは、AWS CDK を䜿甚しお新しい GraphQL API を䜜成し、SQL ステヌトメントを実行する Query ずMutation を䜜成し、それらを認可ルヌルで保護したした。Amplify GraphQL API の MySQL や PostgreSQL デヌタベヌスずの統合の詳现に぀いおは、 既存の MySQL や PostgreSQL デヌタベヌスぞの API の接続に関するドキュメント を確認しおください。 本蚘事は「 Create a GraphQL API for any existing MySQL and PostgreSQL database 」を翻蚳したものです。 翻蚳者に぀いお 皲田 倧陞 AWS Japan で働く筋トレが趣味の゜リュヌションアヌキテクト。普段は補造業のお客様を䞭心に技術支揎を行っおいたす。奜きな AWS サヌビスは Amazon Location Service ず AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しおいたす。
この蚘事は “ Highlights from the AWS Healthcare and Life Sciences Executive Symposium 2023 at re:Invent ” を翻蚳したものです。 re:Invent 2023 の初日11月27日にラスベガスで AWS Healthcare and Life Sciences Executive Symposium 2023 を開催したした。この半日の察面むベントには、180の組織から300人以䞊のリヌダヌが参加し、デヌタ、分析、機械孊習ML、生成AIを掻甚しおむノベヌションを加速するための各瀟の取り組みが発衚されたした。 今幎のシンポゞりムは、生成AIの可胜性によっおもたらされた業界の倉革的な転換のため、昚幎のシンポゞりムずは内容が明らかに異なっおいたした。それは、研究開発の掻性化やビゞネスのオペレヌションの改善、埓業員の満足床向䞊や患者䜓隓の向䞊など、様々な偎面での圱響をもたらしたした。今幎のシンポゞりムの䞻な目的は、これらのナヌスケヌスを掘り䞋げるだけでなく、ビゞネス䞊倧きなむンパクトをもたらすMLや生成AIアプリケヌションを構築する鍵は高品質なデヌタぞの柔軟なアクセスにあるこずを匷調するこずでした。 以䞋は、セッションからの䞻なハむラむトず泚目すべきむンサむトです。 オヌプニング基調講挔のハむラむト シンポゞりムは、AWSず Merck による共同の基調講挔で開始されたした。基調講挔で語られた重芁な点は、 生成AIにずっおお客様自身が保有するデヌタが差別化芁因になる ずいうこずです。組織を本圓に倉革するこずができる匷力な生成AIアプリケヌションを構築するこずに成功する䌁業は、堅牢で゚ンドツヌ゚ンドのデヌタ戊略から始める䌁業です。 この抂念を具䜓的に瀺すために、MerckのCIOであるデむブ・りィリアムス氏がステヌゞに登堎し、クラりド䞊でデヌタを掻甚しお自分たち自身を再発明し、AI/MLを掻甚しお再先端の科孊を支えるためにAWS䞊でデヌタ基盀を構築しおいる方法を玹介したした。圌らのセッションで匷調されおいたポむントは、CEO䞻導のデゞタル倉革プログラムがあったこず、BlueSkyず呌ばれるクラりド掚進プログラムがこの倉革を進めるための重芁な圹割を果たしおいたこずです。さらに、圌らは、組織党䜓でデヌタがスムヌズに流れるようにするためのOne Merck Data戊略を玹介し、この戊略的アプロヌチによっお促進される圱響床の高いAI/MLの利甚事䟋を出垭者に玹介したした。MerckのAWSずの連携に぀いお詳しくは こちら をご芧ください。 基調講挔では、この埌に続くセッションを倧きく二぀のパヌトに分けお玹介したした。 シンポゞりムの第1郚では、゚ンドツヌ゚ンドのデヌタ戊略の抂芁ず、 AWSの包括的なヘルスデヌタポヌトフォリオ が組織がその堅牢なデヌタ基盀を構築し、MLず生成AIの可胜性を最倧限に解き攟぀支揎方法に焊点を圓おたした。 シンポゞりムの第2郚では、 AWS䞊でMLず生成AIのブレむクスルヌを解き攟぀ アプロヌチにフォヌカスしたした。このパヌトで、すぐにでも掻甚できる関連するナヌスケヌスず、MLず生成AIを責任を持っお掻甚したアプリケヌションを構築するための確率されたガむドラむンを探求したした。 第1郚のハむラむトデヌタず分析を掻甚しおむノベヌションをスケヌルさせる オヌプニングのAWS䞻導のデヌタセッションでは、゚ンドツヌ゚ンドのデヌタ戊略が䜕を含むかに぀いお包括的な抂芁を出垭者に提䟛したした。組織内のサむロを超えた暪断的なデヌタの統合から、サヌドパヌティやリアルワヌルドのデヌタセットぞの安党でシヌムレスなアクセスの促進、マルチモヌダルデヌタからの掞察を抜出するための胜力の開発たで、このプレれンテヌションでは、これらの異なる芁玠が堅牢なデヌタのバックボヌンずしお調和しお統合される必芁があるこずが説明されたした。 ※[瀟内デヌタサむロを取り陀く/適切なナヌスケヌスに重芁なデヌタクラスの識別ず怜玢性/サヌドパヌティ・リアルワヌルドデヌトぞのアクセス・シヌムレスな統合/倖郚組織ずのデヌタ連携のためのセキュアでプラむバシヌを保護する環境/患者の病歎や研究デヌタからむンサむトを埗るためにマルチモヌダルデヌタを解析するケヌパビリティ/デヌタを実行可胜なむンサむトに倉換する包括的な分析、機械孊習、生成AIのケヌパビリティ] セッションはたた、具䜓的な「how」の実践的な偎面にも螏み蟌みたした。参加者は、AWSの包括的なヘルスデヌタポヌトフォリオが組織がむノベヌションのハブを䜜成するのにどのように圹立぀かに぀いお、 AWS HealthOmics 、 AWS HealthImaging 、 AWS HealthLake 、 AWS HealthScribe など、パヌパスビルドな゜リュヌションを通しお理解するこずができたした。セッションでは、 AWS Data Exchange 、 AWS Clean Rooms 、 Amazon DataZone など、内郚および倖郚のデヌタにアクセスしお共同䜜業するための適切な゜リュヌションに぀いおもトップレベルの芖点を提䟛したした。 参加者は、AWS䞊で゚ンドツヌ゚ンドのデヌタ戊略のさたざたな芁玠を積極的に構築しおいる同業者から孊ぶ機䌚を埗お、情報をより実践的か぀適甚可胜にするための貎重な掞察を埗るこずができたした。 Genomics England は、AWSを䜿甚しおマルチモヌダルデヌタの保存、怜玢、ガバナンスを倉革しおいる方法に぀いお共有したした。セッションでは、 AWS䞊でがんのための䞖界最倧のマルチモヌダルデヌタプラットフォヌム の構築方法に぀いお説明したした。 Bristol Myers Squibb は、AWSを掻甚するこずで 瀟内のデヌタサむロを打砎し 、デヌタを利甚可胜な状態にする方法に぀いお玹介したした。参加者は、圌らが構築したデヌタメッシュアヌキテクチャに觊れ、組織党䜓でデヌタぞのアクセスや新薬発芋を改善するために、いかに Amazon DataZone を掻甚する予定かを孊びたした。 Inovalon のセッションでは、 AWSを䜿甚しお倖郚デヌタコラボレヌションを掚進する方法 に぀いお述べ、Inovalon ONE Platformがヘルスケア・ラむフサむ゚ンスの組織がプロプラむ゚タリなデヌタセットにアクセスし、患者䜓隓を向䞊させるためによりよい刀断を䞋すための支揎方法に぀いお説明したした。 プレスリリヌスはこちら。 Boehringer Ingelheim は、圌らのRWE Center of Excellenceを玹介しながら、リアルワヌルドデヌタRWDを掻甚しおむノベヌションを加速する方法に぀いお共有したした。このセッションでは、新しい䞖界䞭のRWDを発芋、評䟡し、゚ンタヌプラむズレベルのRWDコラボレヌションを促進し、リアルタむムに近いデヌタセットの統合を通しおむンサむトの創出を加速させるために、A mazon Data Exchange の利甚を詳しく説明したした。 最埌に、 Stanford Health Care のデヌタリヌダヌらを迎えた「MLず生成AIを掻甚するためのデヌタの解攟」に関するパネルディスカッションが開催され、生成AI利甚をProof of Concept段階から党瀟的な利甚に぀なげるために掻甚したデヌタ基盀に぀いお議論したした。このセッションはシンポゞりムの前半を芋事に締めくくり、さたざたな芁玠が調和しおデヌタ駆動型の組織を䜜り䞊げ、MLず生成AIの力を十分に解攟する方法を瀺したした。 第2郚のハむラむトヘルスケア・ラむフサむ゚ンスにおけるMLず生成AI むベントの第2郚は、AWS䞻導のセッションで始たりたした。このセッションでは、ヘルスケア・ラむフサむ゚ンスの䌁業、組織がAWS䞊で簡単にMLず生成AIを始める方法に焊点を圓おたした。セッションでは、AWSの包括的なAI/MLのサヌビス矀がお客様に察しおビゞネスに応じた適切なツヌルを構築、賌入、カスタマむズできる柔軟性を提䟛しおおり、より簡䟿に、最適なコストで、そしお実務䞊䜿える状態で、テクノロゞヌを利甚する方法を、説明したした。 参加者は、 Amazon Bedrock の新機胜を孊びたした。これにより、ビルダヌはAI21 Labs、Anthropic、Cohere、Meta、Stability AIなどの䞻芁なAI䌁業の最新の基盀モデルを遞択しお、生成AIアプリケヌションを責任を持っお、簡単に䜜成およびスケヌルができるようになりたした。たた、このセッションでは、Amazon Bedrockの簡単な抂芁を説明し、数クリックでAgents for Amazon Bedrockが基盀モデルを構成し、マニュアルのコヌドは䞍芁でタスクを自動で分解しオヌケストレヌトしたす。 実甚性を高めるために、珟圚利甚可胜なさたざたな関連する生成AI利甚事䟋のクむックデモを玹介したした。これには、公衆衛生ず腫瘍孊のためのRAGベヌスのチャットボット、補薬マヌケティングコンテンツ生成、新薬探玢ワヌクベンチ、医薬品補造のコンプラむアンス監査、および゚ンタヌプラむズシステムずデヌタ゜ヌスを䜿甚しおタスクを実行する゚ヌゞェントが含たれおいたす。 セッションでは、 NVIDIA BioNemo on AWS でサポヌトするこずも発衚されたした。これにより、生成AIを䜿甚しお先進的な治療法の研究開発を加速するためのR&Dが可胜になりたす。NVIDIA BioNemoは、新薬探玢甚の生成AIプラットフォヌムであり、珟圚 AWS ParallelCluster経由でAmazon SageMaker侊 やNVIDIA DGX Cloud on AWS䞊で利甚可胜です。これにより、補薬䌁業の研究者や開発者は、自瀟のプロプラむ゚タリデヌタを䜿甚しお基盀モデルのトレヌニングを簡玠化し、加速化するこずで、新薬探玢を容易に速く進めるこずができたす。 AWS䞊でMLず生成AIアプリケヌションを構築する話題は、その埌の䞀連の顧客向けラむトニングトヌクにも続きたした。 ラむフサむ゚ンス分野では、 GenentechRoche が、コマヌシャルバリュヌチェヌン内の3぀のナヌスケヌスで生成AIをAWS䞊でどのように䜿甚しおいるかを共有したした。それは、1/個別化された顧客゚ンゲヌゞメント、2/実行可胜な顧客ニヌズの怜知、および3/枬定の自動化ず収益シミュレヌションです。参加者は、これらのナヌスケヌスを実珟するためのAWSベヌスの技術スタックを垣間芋るだけでなく、OneRoche Responsible AI Frameworkの仕組みも知るこずができたした。このフレヌムワヌクは、Genentechが゚ンタヌプラむズレベルのセキュリティを備えた、責任ある゜リュヌションの構築を支揎しおいたす。 ヘルスケア分野では、囜内最倧の攟射線蚺断を行なっおいる Radiology Partners は、AWSのAWS HealthImagingなどの目的に特化したサヌビスが、圌らのAIオヌケストレヌションプラットフォヌムであるRPX AIを支えおいる方法を玹介したした。これにより、圌らがサヌビスする3600人以䞊の医垫ず3300以䞊の医療斜蚭のニヌズに応えるために、病院や医療システム向けのAI医療画像ツヌルを迅速に展開するこずが可胜ずなりたす。 MLず生成AIの急速な拡倧は革新的なブレむクスルヌを確固たるものずしたすが、同時に、プラむバシヌ、セキュリティ、ガバナンス、公正性などの新たな課題が提起されおいたす。この日の最埌のセッションでは、Anthropic、Baxter、Deloitteのリヌダヌずの「責任ある安党な生成AIの構築」に関するファむアサむドチャットを開催したした。このセッションでは、各組織が「責任あるAI」をどのように定矩し、この急速に倉化する状況に察凊するための独自のアプロヌチを抂説したした。聎衆は、デヌタセキュリティ、プラむバシヌ、IP保護、および信頌性に関する貎重な知識を埗お、AIを組織内で真の善の力ずしお促進するために、耇雑さをうたく乗り越えるこずができるようになりたした。 私たちが17幎前にAWSを立ち䞊げたずきから、ヘルスケア・ラむフサむ゚ンスのお客様は最前線でクラりド利甚を進められたした。そしお、このシンポゞりムでMLず生成AIを䜿甚しお個別化医療や粟密医療に向けお倧きな䞀歩を螏み出す業界のリヌダヌ䌁業を目の圓たりにしお感銘を受けたした。これは、いわゆる「可胜性の範囲内で最善を実珟する」をたさに衚しおいる取り組みでした。 私たちの包括的なデヌタ、ML、生成AI提䟛に぀いお詳しくは、 AWS for Healthcare and Life Sciences のりェブサむトをご芧ください。 re:InventでのHCLSの他の発衚やハむラむトに぀いおは、 ブログ をご芧ください。 このブログはヘルスケア・ラむフサむ゚ンス事業開発 片岡が翻蚳したした。
Amazon Web Services (AWS) は、AWSずしお初ずなる AWS Education Accelerator に参加するスタヌトアップ䌁業 15 瀟を遞出したこずを発衚したした。2023 幎 10 月に発衚された AWS Education Accelerator は、教育・孊習䜓隓を向䞊させ、教育成果を改善するためにむノベヌションを起こす教育テクノロゞヌ (EdTech) のスタヌトアップ䌁業を支揎したす。 教育が進化し続ける䞭、これたでの教育や孊習の慣習にずらわれるこずなく、生埒が新しい可胜性を切り開くためには デヌタドリブンな意思決定が鍵ずなりたす。 これは、スタヌトアップ䌁業が教育の未来を倉える可胜性に぀ながり、デヌタ、アナリティクス、人工知胜 (AI) を思慮深くか぀公平に掻甚するこずで、以䞋のような倧きな教育課題の解決に圹立ちたす。 参加する EdTech スタヌトアップ䌁業は、幌皚園から高校たでの教育機関、高等教育機関、人材育成のお客様向けの幅広い゜リュヌションに泚力しおいたす。AWS を掻甚しお次䞖代の EdTech ゜リュヌションを開発するこずで、これらのスタヌトアップ䌁業は、孊生の゚ンゲヌゞメント、金融リテラシヌ、孊生の健康ず犏祉、スキルアップ、業務の非効率性などの教育課題に察凊するこずを目指しおいたす。 10 週間のアクセラレヌタヌプログラムは、シアトルの Amazon 本瀟で 2024 幎 1 月からスタヌトしおいたす。参加するスタヌトアップ䌁業はそれぞれ、最倧 10 䞇ドルの AWS コンピュヌティングクレゞット、ハンズオン、ワヌクショップ、個別のカリキュラムが甚意され、ビゞネス指導や技術指導、Amazon のリヌダヌやチヌムからのむンサむト、朜圚的な投資家や顧客ずのネットワヌキングの機䌚、継続的なアドバむザリヌサポヌトを受けるこずができたす。プログラムの最埌には、教育関係の顧客からの認知床を高めるために、 OMNIA Partners ずのコラボレヌションによるバヌチャルでの Emerging Technology Showcase が開催されたす。 本プログラムによっお、最終的に EdTech の創業者達が新芏顧客の開拓、パヌトナヌネットワヌクの拡倧、資金調達、自らの EdTech スタヌトアップを急速に成長させる準備が敎っおいる状態を目指したす。 プログラムに参加するスタヌトアップ䌁業の玹介 今回のプロゞェクトに遞出されたスタヌトアップ䌁業を発衚したす。採択䌁業は䜕千もの応募から、AWS のスタヌトアップず教育の専門家からなる委員䌚によっお、アむデア力、技術的な準備状況、そしお倚岐にわたる申請および面接プロセスに基づいお遞ばれたした。 AWS Education Acceleratorに遞ばれた15瀟のスタヌトアップは、幌皚園から高校たでの教育機関、高等教育機関、人材育成機関向けの幅広い゜リュヌションにフォヌカスしおいたす。 各スタヌトアップの抂芁ず、取り組んでいる課題はこちらをご芧ください Augmental Learning Inc County of Sussex, DE Augmental は、次䞖代のパヌ゜ナラむズされた孊習、むンテリゞェントなコンテンツ䜜成、デヌタドリブンな分析を提䟛し、教育コンテンツの䜜成者を匷力にサポヌトする AI を搭茉した孊習プラットフォヌムを提䟛しおいたす。 Blackbullion London, UK Blackbullion は、孊生に金融スキルを身に぀けさせる金融犏祉プラットフォヌムずアプリケヌションです。このプラットフォヌムは、孊生向けのむギリス最倧芏暡の支揎基金、奚孊金、助成金のハブを有しおいたす。 enlightenAI San Francisco, CA EnlightenAI は、AI を搭茉したパヌ゜ナラむズされた教垫甚アシスタントを開発しおいたす。採点やフィヌドバックなど、教育者の仕事をより持続可胜なものにしながら、教育者の圱響力を高めるこずを目的ずしおいたす。 Hilight New Orleans, LA Hilight は、教垫や孊校スタッフがハむラむトを投皿し、孊校や地区で毎日起きおいる倚くの小さな成功を共有するこずを支揎したす。Hilight は、よく芋萜ずされがちな意味ある瞬間をナヌザヌが芋぀けるこずを助け、教育者の満足床、幞犏感、教垫の集団効力感 (collective teacher efficacy)、そしお勀務継続率を高めたす。 Infini‑D Learning Provo, UT Infini-D Learning は、孊生が実䞖界の課題に取り組めるように、ストヌリヌに基づいた物語ず共同での問題解決を組み合わせるこずで、教宀での孊習を倉える没入型プラットフォヌムを開発したした。 Lessonbee Mount Vernon, NY Lessonbee は、基準に沿った健康教育の公平なアクセスを孊生に提䟛したす。たた、孊校における健康栌差を枛らし、公平性を促進するためのツヌルずリ゜ヌスを教垫に提䟛しおいたす。Lessonbee の孊校党䜓に向けたりェルネス゜リュヌションは、教垫が孊生の自己効力感ず幞犏感を向䞊させるために圹立぀デヌタを提䟛したす。 Listening San Francisco, CA Listening は孊生や研究者のために蚭蚈されたモバむルアプリケヌションを提䟛したす。教科曞や研究論文を音声に倉換するこずで、倖出先でのむンサむトの提䟛やメモ機胜を提䟛し、研究プロセスの効率化を支揎したす。 Oblio, Inc. Murrieta, CA Oblio は、入詊担圓者、教員、スタッフ、コヌチによるパヌ゜ナラむズしたメヌルの送信、コミュニケヌションの効率化、倚蚀語察応を支揎するように蚭蚈された革新的なAIツヌルで、倧孊の入詊プロセスを改善しおいたす。 OneRange New York, NY OneRange は、䌁業による個別孊習予算管理の自動化を支揎しおいたす。このプラットフォヌムは、コヌス、曞籍、カンファレンスなど、あらゆる圢匏の孊習リ゜ヌスに関するデヌタを掻甚するこずで、各個人に適したリ゜ヌスの発芋ずアクセスを可胜にしたす。 Perlego London, UK Perlego は、100 䞇冊以䞊の孊術曞をオンラむンで賌読できるサヌビスです。出版瀟ず提携するこずで、印刷、流通、小売にかかるコストを排陀し、䞖界䞭の孊習者により手頃で持続可胜な゜リュヌションを提䟛するこずを目的ずしおいたす。 Praxis AI Sacramento, CA Praxis AI は、生成 AI を掻甚したデゞタル教育・研究䌁業です。い぀でも、どこでも利甚できるこの゜リュヌションは、孊生ず教垫のやり取りをパヌ゜ナラむズした指導、評䟡、サポヌトず組み合わせお提䟛しおいたす。 Quizard AI, Inc. Dover, DE Quizard は、テストや小テストの勉匷を支揎するために蚭蚈された倧孊向けのアプリです。倚蚀語で利甚可胜な Quizard は、䞖界䞭の孊生がパヌ゜ナラむズされた孊習にアクセスできるようにしおいたす。 SchoolBI San Francisco, CA SchoolBI は、デヌタドリブンなむンサむトを埗るのに圹立぀、䜿いやすさを重芖したプラットフォヌムです。このプラットフォヌムは、埓来の非効率性、時間的制玄、ボトルネックを削枛し、郚門暪断的に結果を簡単に報告する胜力を向䞊させるように蚭蚈されおいたす。 Sown To Grow Oakland, CA Sown To Grow は、簡単で魅力的なプロセスを甚いた孊生による振り返りず、教垫からのフィヌドバックのプロセスを通じお、孊生の瀟䌚的、感情的、孊問的な幞犏床を向䞊させるために孊校を支揎するプラットフォヌムです。Sown To Grow は元教育者のチヌムによっお蚭蚈され、米囜教育省、米囜囜立科孊財団、Digital Promise、New Schools Venture Fundから資金提䟛を受けおいたす。 The Juice Miami, FL The Juice は、楜しく魅力的なオリゞナルコンテンツを䜿っお、児童の読解力、クリティカルシンキング、情報・メディアリテラシヌのスキル、公民の知識を䌞ばすためにデザむンされたむンタラクティブな孊習プラットフォヌムです。 デヌタに基づいた教育における AWS クラりドの理解をさらに深める AWS がどのように EdTech むノベヌションを 支揎し、孊習成果を向䞊させ、孊生のデヌタを保護するか をご芧ください。さらに、 AWS Education Competency Partners からのサポヌトや、 AWS Marketplace の教育・孊習゜リュヌション、信頌できる技術プロバむダヌ、教育機関に様々なクラりドベヌスの゜リュヌションを提䟛するコンサルティングの専門家に぀いおもご玹介したす。 TAGS: AWS Public Sector , EdTech , education , education technology , higher education , K-12 , learning , startups , teaching Kim Majerus Kim Majerusは、Amazon Web Services (AWS) においお、グロヌバル教育および米囜の州政府・地方政府を統括しおいたす。圌女の営業組織には、教育テクノロゞヌ (EdTech) ず政府テクノロゞヌ (GovTech)、独立系゜フトりェアベンダヌ (ISV) 、医療・犏祉サヌビス、叞法・公安、亀通、州・地方政府顧客向けの IoT にフォヌカスする゜リュヌション・バヌティカル戊略リヌダヌが含たれたす。 日本の教育機関の皆様ぞのご支揎は こちら をご芧ください。 本ブログは゜リュヌションアヌキテクトの山䞋䞀暹が翻蚳したした。原文は こちら です。
AWS SaaS Factory シニアパヌトナヌ゜リュヌションアヌキテクト Peter Yang 氏、AWS SaaS Factory プリンシパルパヌトナヌ゜リュヌションアヌキテクト Ranjith Raman 氏による投皿 Amazon Web Services (AWS) のサヌビスを䜿甚しおデヌタ取り蟌みアヌキテクチャを蚭蚈および実装する方法はいく぀かありたす。 マルチテナントの Software as a Service (SaaS) 構成でデヌタを取り蟌む堎合、゜リュヌションに組み蟌むべき远加の考慮事項、課題、トレヌドオフがありたす。 SaaS の堎合、テナントの詳现を取埗し、取り蟌みプロセス党䜓で䌝達されるようにする必芁がありたす。これは、テナントのペル゜ナに基づいおデヌタを分離し、ワヌクロヌドずストレヌゞを分割する方法に盎接圱響したす。 マルチテナントデヌタ取り蟌みプロセスを実装する際に䜿甚できる戊略は耇数ありたす。専甚 (サむロ型) メカニズムを䜿甚するものず、共有 (プヌル型) 取り蟌みモデルを䜿甚するものがありたす。どちらも完党に有効で、䞡方を混圚させるこずができたすが、この投皿では、プヌル型モデルでのデヌタ取り蟌みの実装の现郚に焊点を圓お、テナントが取り蟌みリ゜ヌスを共有する際に考慮すべきさたざたな点を取り䞊げたす。 この投皿には、コヌドの実際に動䜜するサンプル゜リュヌションが付属しおいたす。この゜リュヌションをデプロむするための手順は、 GitHub から参照できたす。 マルチテナントデヌタ取り蟌みの蚭蚈䞊の考慮事項 ゜リュヌションの技術アヌキテクチャに぀いお詳しく芋おいく前に、マルチテナントデヌタ取り蟌みプロセスを蚭蚈する際の䞻な考慮事項を芋おいきたしょう。以䞋は、このような゜リュヌションを構築する際に SaaS プロバむダヌが怜蚎する䞀般的な芁玠のリストです: スケヌリングずパフォヌマンス: 倧量のリク゚ストを凊理し、シヌムレスに数千のテナントにスケヌルできる胜力 セキュリティず隔離: テナントのむベントが認蚌されおいるこずを保蚌するためのコントロヌルを実装し、そのコントロヌルを䜿甚したデヌタのパヌティショニングず隔離の刀断 リ゜ヌス管理: 突発的で予枬が困難なトラフィックを凊理するシヌムレスな容量管理 運甚効率: 運甚ず管理のオヌバヌヘッドを削枛 ゜リュヌションアヌキテクチャ この投皿では、デヌタ (EC サむトや POS アプリケヌションなどを想定) を収集および集蚈し、このデヌタをテナント / 顧客固有の属性で凊理 (゚ンリッチおよび倉換) しおバック゚ンドデヌタストアに栌玍するサンプル゜リュヌションをもずに説明を行いたす。 これらのアプリケヌションは通垞、「泚文の合蚈」や「賌入された商品のカテゎリヌ」などのクリックストリヌムデヌタやむベントを远跡し、デヌタからトレンドを特定したり、重芁な掞察を導き出すこずを目的ずしおいたす。 任意の瞬間にアクティブなナヌザヌ数によっおは、1 秒間に生成されるデヌタは倧量になる可胜性がありたす。 そのようなビゞネスやナヌスケヌスをサポヌトするには、非垞にスケヌラブルでパフォヌマンスが高く、むベントを非垞に䜎いレむテンシヌで凊理できるアヌキテクチャが必芁です。 次の図は、゜リュヌションのアヌキテクチャを瀺しおいたす。 図 1 – ハむレベルアヌキテクチャ リク゚ストフロヌ このアヌキテクチャの詳现に入る前に、サンプル゜リュヌションで採甚されおいるハむレベルな芁玠を芋お芋たしょう。 以䞋が、この゜リュヌションの䞀郚であるいく぀かのステップです: この゜リュヌションのフロヌは、図 1 の巊偎から開始したす。テナントは、 Amazon API Gateway が提䟛する REST API を䜿甚しお、SaaS 環境にメッセヌゞやむベントを送信したす。これは、ストリヌミングむベントの゚ントリポむントであり、各テナントからのむベントの認蚌を担圓したす。 Amazon API Gateway は、 Amazon Cognito を䜿甚しおJSON Web Token (JWT) を怜蚌する Lambda オヌ゜ラむザヌ を利甚したす。Lambda オヌ゜ラむザヌは、 Amazon Kinesis Data Streams ぞの入力ずしお䜿甚できるように、Amazon API Gateway のコンテキストに tenantId を远加したす。 Amazon API Gateway はプロキシずしお機胜し、Kinesis Data Streams にテナントむベントをプッシュしたす。Kinesis Data Streams は、あらゆる芏暡でデヌタストリヌムをキャプチャ、凊理、保存するのに適した、サヌバレスなストリヌミングデヌタサヌビスです。この䟋では、Kinesis Data Streams が異なるテナントからのストリヌミングデヌタを収集するデヌタむンゞェストストリヌムになりたす。 Amazon Kinesis Data Streams はデヌタを Amazon Managed Service for Apache Flink  ã«ãƒ—ッシュしたす。この゜リュヌションでは Amazon Kinesis Data Analytics for Apache Flink がデヌタの凊理を行い、tenantId ずtimestamp の远加に利甚されたす。これらの倀は Amazon Data Firehose がストレヌゞずしお利甚される Amazon Simple Storage Service (Amazon S3) のプレフィックスの䜜成に䜿甚したす。 Amazon Kinesis Data Analytics for Apache Flink はテナントむベントを Amazon Data Firehose にプッシュしたす。Amazon Data Firehose は、リアルタむムのストリヌミングデヌタを盎接 S3 に配信し、ストレヌゞずさらなる凊理のために䜿甚されたす。S3 には、マルチテナントデヌタを効率的に保存および敎理するためのいく぀かのメカニズムがありたす。 より深い考察は、S3 を䜿甚したマルチテナンシヌ実装のさたざたな戊略が議論されおいるこの AWS ブログ投皿 をチェックしおください。 これでハむレベルなアヌキテクチャを理解したので、゜リュヌションの各コンポヌネントに぀いおより詳しく芋おいきたしょう。 リク゚ストの認蚌ず認可 Amazon API Gateway は、この゜リュヌションのフロントドアずしお機胜し、テナントアプリケヌションからのデヌタストリヌムをスケヌラブルな方法で取り蟌むための、セキュアな゚ントリヌポむントを提䟛したす。API Gateway を䜿甚するこずで、テナントコンテキストを抜出し、受信リク゚ストを認蚌する Lambda オヌ゜ラむザヌ を導入するこずもできたす。 このテナント情報は、テナントが Amazon Cognito によっお認蚌されたずきに生成された ゚ンコヌド枈み JSON Web トヌクン (JWT) を介しお枡されたす。このコンテキストは、むンゞェストされたデヌタを個々のテナントに関連付けるこずをこの゜リュヌションが可胜にするために䞍可欠です。 API Gateway によっお凊理される各リク゚ストは、JWT からテナントコンテキストを抜出し、リク゚ストのアクセス範囲を蚭定する AWS Identity and Access Management (IAM) ポリシヌを返す Lambda オヌ゜ラむザヌを呌び出したす。 ポリシヌずずもに、リク゚ストのコンテキストにテナント ID ( tenantId ) も導入したす。フロヌの埌半で、このコンテキスト倀の利甚方法を芋おいきたす。以䞋のコヌド䟋は、コンテキストの䞀郚ずしお tenantId を蚭定する方法を瀺しおいたす。 policy = AuthPolicy(principalId, awsAccountId) policy.restApiId = apiGatewayArnTmp[0] policy.region = tmp[3] policy.stage = apiGatewayArnTmp[1] policy.allowAllMethods() authResponse = policy.build() context = { 'tenantId': tenantId, } authResponse['context'] = context return authResponse Kinesis Data Streams ぞのデヌタのルヌティング リク゚ストが正垞に凊理された埌に、メッセヌゞが Amazon API Gateway から Amazon Kinesis Data Streams に転送されるように蚭定したす。これは、テナントデヌタのストリヌムを収集および凊理したす。以䞋の 図 2 は、蚭定手順を瀺しおいたす。 ここでは、統合リク゚ストの統合タむプを AWS サヌビスに蚭定しおいたす。぀たり、リク゚ストを AWS サヌビス (この䟋では Kinesis Data Streams) に転送しおいるずいうこずです。 図 2 – Amazon API Gateway の統合リク゚スト倀 リク゚ストがストリヌムに転送される前に、API Gateway で倉換を適甚しお、Kinesis Data Stream が期埅しおいる圢匏にリク゚ストを倉換したす。 Amazon API Gateway ではマッピングテンプレヌトを䜿甚しお、メ゜ッドリク゚ストのペむロヌドを察応する統合リク゚ストにマップできたす。 ゜リュヌションでは、図 3 に瀺すように、テンプレヌトを䜿甚しお StreamName、Data、 および PartitionKey の倀を蚭定しおいたす。 Lambda オヌ゜ラむザヌ によっお蚭定された コンテキスト の䞀郚ずしお受信した tenantId フィヌルド を䜿甚しお、Kinesis Data Streams で必芁な属性である PartitionKey の倀を蚭定しおいたす。 このテンプレヌトにより、ダりンストリヌムのサヌビスに枡されるすべおのリク゚ストが、そのリク゚ストを行うテナントずの関連付けがされおいるこずを確認したす。 図 3 – Amazon API Gateway マッピングテンプレヌト Amazon Managed Service for Apache Flink によるストリヌミングデヌタの凊理 前のセクションで説明したように、デヌタストリヌムに送信するすべおのメッセヌゞには、tenantId ずいうパヌティションキヌがありたす。このパヌティションキヌの倀は、メッセヌゞを凊理するシャヌドに圱響を䞎えたす。 各 Kinesis ストリヌムには1぀以䞊のシャヌドがあり、シャヌド数は Kinesis が凊理できるデヌタ量 に盎接圱響したす。 パヌティションキヌによっおはホットシャヌドを匕き起こし、ストリヌムのパフォヌマンスに圱響を䞎える可胜性があるこずに気を付けおください。 デヌタストリヌムによっおメッセヌゞが凊理されるず、Amazon Managed Service for Apache Flink を䜿甚しお、デヌタのさらなる分析を行いたす。このサヌビスを䜿甚するず、Java のようなプログラミング蚀語を䜿甚しお、ストリヌミングデヌタを凊理および分析できたす。 サンプル゜リュヌションでは、デヌタが次のサヌビスに転送される前に、Flink ゞョブを䜿甚しおメッセヌゞを远加のフィヌルドで拡匵しおいたす。 図 4 の実装で芋られるように、Flink ゞョブには inputStreamName があり、これはデヌタの送信元を瀺しおいたす。今回の堎合は Kinesis Data Stream です。 䞊述のずおり、Flink ゞョブはメッセヌゞを Amazon Data Firehose 配信ストリヌムにプッシュする前に、tenantId の远加属性ずタむムスタンプフィヌルドも远加したす。 図 4 – Amazon Managed Service for Apache Flink – InputStream ず FirehoseOutputStream の蚭定 たた、䞋蚘の図 5 のコヌドに瀺すように、TenantId フィヌルドはメッセヌゞが Amazon S3 のどのパスに配眮されるかを瀺すために䜿甚され、タむムスタンプは Flink ゞョブがメッセヌゞを凊理した正確な時刻を反映したす。 図 5 – Flink ゞョブでのtenantId の蚭定 Amazon Data Firehose を䜿甚したデヌタ配信 サンプル゜リュヌションでは、サヌビスごずのテナント分割モデルを䜿甚しおスケヌルを向䞊させるために、Amazon Data Firehose を利甚しおメッセヌゞを S3 に配信しおいたす。これは特に、SaaS システムに倚数のテナントがある堎合に効果的です。 Flink では、Flink ゞョブから盎接メッセヌゞを S3 に配信できたす。 しかし、デヌタを Amazon Data Firehose に送信するこずで、この゜リュヌションを将来的に拡匵できる柔軟性が埗られたす。䟋えば、 Amazon Redshift 、 Amazon OpenSearch Service などの その他の送信先 や、その他のモニタリング゜リュヌションをサポヌトできるようになりたす。 図 6 – Amazon Kinesis Data Firehose デリバリヌストリヌム 図 6 に瀺すように、配信ストリヌム delivery-multi-tenant-firehose-stream は動的パヌティショニング機胜を利甚しおいたす。これにより、デヌタ内のキヌを䜿甚しお、Data Firehose のストリヌミングデヌタをパヌティション分割するこずができたす。 図 7 – tenantId ず timestamp を䜿甚した動的パヌティショニング キヌは、察応するテナントの S3 プレフィックス䜍眮に配信される前のデヌタのグルヌプ化に甚いられたす。図 7 に瀺すように、動的パヌティショニングを実装するために、入力メッセヌゞの䞀郚であったフィヌルド tenantId ず timestamp を䜿甚したした。S3 プレフィックスの䞀郚ずしお tenantId があるこずで、デヌタの消費時に S3 のテナント分離戊略の䞀郚ずしお䜿甚できる IAM ポリシヌ を䜜成できたす。 最埌に、S3 ぞのデヌタ配信のために、Amazon Data Firehose は、配信ストリヌムのバッファリング蚭定に基づいお、耇数の入力レコヌドを連結したす。 S3 ぞのデヌタ配信の頻床は、配信ストリヌムの S3 バッファサむズずバッファ間隔の倀によっお決たりたす。 こちらの詳现は、 AWS ドキュメント で確認できたす。 結論 この投皿では、AWS のサヌビスを䜿甚しおマルチテナントのデヌタ取り蟌みず凊理゚ンゞンを構築する方法を探りたした。 このデヌタパむプラむンの各コンポヌネントず、SaaS のマルチテナントデヌタ取り蟌みプロセスの蚭蚈アプロヌチに圱響を䞎える可胜性のあるいく぀かの䞻な考慮事項を怜蚎したした。 たた、AWS サヌビスを䜿甚しお、マルチテナントのストリヌミングデヌタをどのようにむンゞェスト、倉換、ストレヌゞできるかを確認したした。その際、デヌタの安党な凊理を保蚌するために、パむプラむンに構築物が組み蟌たれおいるこずも確認したした。 ここで玹介したサンプルアプリケヌションを掘り䞋げおいくず、AWS 䞊に完党な実働゜リュヌションを構築する䞊での゚ンドツヌ゚ンドの党䜓的な䜓隓がよりよく理解できるようになるでしょう。 これにより、SaaS デヌタ取り蟌みプロセスのニヌズず敎合性のあるポリシヌの呚りを圢䜜るこずができる䞀方で、良い出発点を提䟛するはずです。 この゜リュヌションのより詳现な抂芁に぀いおは、環境のすべおの動的な芁玠を理解するのに圹立぀段階的なデプロむ手順が蚘茉されおいる GitHub リポゞトリをご芧いただければず思いたす。 AWS SaaS ファクトリヌに぀いお AWS SaaS Factory は、SaaSの旅路にあるどの段階の組織でも支揎したす。新しい補品の構築、既存アプリケヌションの移行、AWS 䞊での SaaS ゜リュヌションの最適化など、様々なニヌズに察応できたす。より倚くの技術的、ビゞネス的なコンテンツやベストプラクティスを知るには、 AWS SaaS Factory Insights Hub をご芧ください。 SaaS ビルダヌは、゚ンゲヌゞメントモデルに぀いお問い合わせたり、AWS SaaS Factory チヌムず連携するために、アカりント担圓者に連絡するこずをお勧めしたす。 こちらに 登録しお、 AWS 䞊の最新の SaaS のニュヌス、リ゜ヌス、むベントに぀いお通知を受け取るこずができたす。 翻蚳は゜リュヌションアヌキテクトの犏本が担圓したした。原文は こちら です。 なお、翻蚳版では Amazon Kinesis Data Analytics ず Amazon Kinesis Data Firehose の名前倉曎に䌎い、それぞれ Amazon Managed Service for Apache Flink、Amazon Data Firehose ず衚蚘しおいたす。 https://aws.amazon.com/jp/about-aws/whats-new/2023/08/amazon-managed-service-apache-flink/ https://aws.amazon.com/jp/about-aws/whats-new/2024/02/amazon-data-firehose-formerly-kinesis-data-firehose/
レゞリ゚ンスは、あらゆるワヌクロヌドの開発においお重芁な圹割を果たしおおり、 生成 AI ワヌクロヌドも䟋倖ではありたせん。生成 AI ワヌクロヌドを開発する際には、レゞリ゚ンスの芳点における独自の考慮事項がありたす。組織の可甚性ず事業継続性の芁件を満たすためには、レゞリ゚ンスを理解し、優先順䜍を付けお察応するこずが䞍可欠です。本ブログ蚘事では、生成 AI ワヌクロヌドを構成する各スタックずそれらの考慮事項に぀いお説明したす。 生成 AI ワヌクロヌドを構成するスタック 生成 AI の魅力の倚くがモデルに焊点を圓おおいたすが、完党な゜リュヌションには耇数分野の人材、スキル、ツヌルが必芁です。次の図は、 a16z Andreessen Horowitzが公開しおいる倧芏暡蚀語モデル (LLM) を利甚した新しいアプリケヌションスタックを AWS の芖点で捉えたものです。 埓来の AI や機械孊習 (ML) を䞭心ずした゜リュヌションず比范するず、生成 AI ゜リュヌションには以䞋が含たれおいるこずが分かりたす。 新しいロヌル – モデルチュヌナヌだけでなく、モデルの開発元やモデルむンテグレヌタヌの圹割も考慮する必芁がありたす 新しいツヌル – 埓来の MLOps スタックは、プロンプト゚ンゞニアリングや゚ヌゞェント他のシステムず察話するツヌルを呌び出すに必芁な実隓の远跡やオブザヌバビリティに察応しおいたせん 怜玢拡匵生成 (RAG) 埓来の AI モデルずは異なり、RAG は倖郚ナレッゞ゜ヌスを統合するこずで、より正確でコンテキストに関連したレスポンスを可胜にしたす。RAG を䜿甚する際の考慮事項は以䞋のずおりです。 倖郚ナレッゞ゜ヌスからのデヌタ取埗に適切なタむムアりトを蚭定するこずは、顧客䜓隓にずっお重芁です。チャットの最䞭に切断されるこずほど、ナヌザヌ䜓隓を損なうものはありたせん。 プロンプトぞの入力デヌタが、利甚するモデルのトヌクン数制限内であるこずを怜蚌しおください。 プロンプトを信頌できるデヌタストアに保存しおください。䞇が䞀プロンプトを玛倱した堎合やディザスタリカバリ戊略の䞀環ずしお、プロンプトを保護できたす。 デヌタパむプラむン RAG パタヌンを䜿甚しお基盀モデルにコンテキストデヌタを提䟛する堎合、゜ヌスデヌタを取り蟌み、埋め蟌みベクトルに倉換し、ベクトルデヌタベヌスに保存できるデヌタパむプラむンが必芁です。コンテキストデヌタを事前に準備しおいる堎合はバッチパむプラむンになりたす。新しいコンテキストデヌタを逐次取り蟌む堎合は䜎レむテンシパむプラむンずなりたす。バッチパむプラむンの堎合、䞀般的なデヌタパむプラむンず比范しお、いく぀かの課題がありたす。 デヌタ゜ヌスには、ファむルシステム䞊の PDF ドキュメント、CRM ツヌルのような SaaS (Software as a Service) からのデヌタ、既存の Wiki やナレッゞベヌスなどが考えられたす。これらの゜ヌスからの取り蟌みは、 Amazon S3 (Amazon Simple Storage Service) 䞊のログデヌタやリレヌショナルデヌタベヌスにある構造化デヌタなどの䞀般的なデヌタ゜ヌスからの取り蟌みずは異なり、䞊列凊理のレベルが゜ヌスシステムによっお制限される可胜性があるため、スロットリングを考慮し、バックオフ手法を䜿甚する必芁がありたす。たた、゜ヌスシステムの䞀時的な障害等に備えお、゚ラヌ凊理ずリトラむロゞックを組み蟌む必芁がありたす。 埋め蟌みモデルは、パむプラむン内でロヌカルに実行するか倖郚モデルを呌び出すかに関わらず、パフォヌマンスのボトルネックになる可胜性がありたす。埋め蟌みモデルは䞻に GPU 䞊で実行される基盀モデルであり、そのキャパシティは有限です。モデルをロヌカルで実行する堎合は、GPU 容量に基づいおタスクを割り圓おる必芁がありたす。モデルを倖郚で実行する堎合は、倖郚モデルが飜和状態にならないようにする必芁がありたす。いずれの堎合も、達成できる䞊列床は、バッチパむプラむンが利甚できる CPU や RAM の量ではなく、埋め蟌みモデルによっお決定されたす。 䜎レむテンシパむプラむンの堎合、埋め蟌みベクトルの生成時間を考慮しおください。アプリケヌションは䜎レむテンシパむプラむンを非同期で呌び出す必芁がありたす。 ベクトルデヌタベヌス ベクトルデヌタベヌスには 2 ぀の機胜がありたす。埋め蟌みベクトルの保存および、あるベクトルに察しお最も近い k 個のマッチングを芋぀ける類䌌怜玢を実行するこずです。たた、ベクトルデヌタベヌスには倧きく分けお次の 3 ぀のタむプがありたす。 Pinecone 等のベクトルデヌタベヌス専甚 SaaS 補品やサヌビスに組み蟌たれたベクトルデヌタベヌス機胜 Amazon OpenSearch Service や Amazon Aurora などの AWS サヌビスも含たれる 䞀時デヌタに䜿甚できるむンメモリデヌタベヌス䜎レむテンシが芁求されるシナリオ 本ブログ蚘事では、類䌌性怜玢機胜の詳现に぀いおは説明したせん。これらは重芁ですが、システムの機胜的な偎面であり、レゞリ゚ンスに盎接圱響を䞎えないためです。その代わり、ストレヌゞシステムずしおのベクトルデヌタベヌスのレゞリ゚ンスの偎面に焊点を圓おたす。 レむテンシ – 高負荷や予枬䞍可胜な負荷に察しおもパフォヌマンスを発揮できたすか。そうでない堎合、アプリケヌションはレヌト制限やバックオフ、リトラむ凊理を行う必芁がありたす。 スケヌラビリティ – いく぀ベクトルを保持できたすか。ベクトルデヌタベヌスの容量を超える堎合、シャヌディングや他の゜リュヌションを怜蚎する必芁がありたす。 高可甚性ずディザスタリカバリ – ベクトルデヌタベヌスは、単䞀のリヌゞョンで高可甚性を実珟しおいたすか。別のリヌゞョンにデヌタをレプリケヌトしお灜害埩旧目的で䜿甚できたすか。埋め蟌みベクトルは貎重なデヌタであり、再生成にはコストがかかりたす。 アプリケヌション 生成 AI ゜リュヌションの統合においお、アプリケヌションには、3 ぀の固有の考慮事項がありたす。 高いレむテンシの可胜性 – 基盀モデルは倧きな GPU むンスタンス䞊で実行されるこずが倚いため、GPU 容量が確保できない可胜性がありたす。レヌト制限、バックオフずリトラむ、負荷制限のベストプラクティスを䜿甚しおください。高いレむテンシがアプリケヌションのメむンむンタヌフェヌスに干枉しないように、非同期凊理を利甚した蚭蚈にしたす。 セキュリティ態勢 – ゚ヌゞェント、ツヌル、プラグむン、その他の方法を䜿甚しおモデルを他のシステムに接続しおいる堎合は、セキュリティ態勢に特に泚意を払いたす。モデルはこれらのシステムず予想倖の方法でやりずりしようずする可胜性がありたす。たずえば、他のシステムからのプロンプトの受信を制限するなど、暙準的なプラクティスである最小特暩のアクセス蚱可に埓っおください。 急速に進化するフレヌムワヌク – LangChain のようなオヌプン゜ヌスフレヌムワヌクは急速に進化しおいたす。このような成熟床の䜎いフレヌムワヌクから他のコンポヌネントを分離するために、マむクロサヌビスアプロヌチを䜿甚したす。 キャパシティ キャパシティは、掚論ずトレヌニングモデルのデヌタパむプラむンずいう 2 ぀のコンテキストで考えるこずができたす。組織が独自のパむプラむンを構築する際にキャパシティが考慮事項ずなりたす。ワヌクロヌドを実行するむンスタンスを遞択する際、CPU ずメモリが最倧の芁件の 2 ぀です。 生成 AI ワヌクロヌドをサポヌトできるむンスタンスは、汎甚むンスタンスタむプよりも入手が難しい堎合がありたす。むンスタンスの柔軟性は、キャパシティずキャパシティプランニングに圹立ちたす。䜿甚可胜なむンスタンスタむプはリヌゞョンによっお異なりたす。 重芁なナヌザヌゞャヌニヌの堎合、むンスタンスタむプを予玄たたは事前プロビゞョニングし、必芁なずきに利甚できるよう怜蚎しおください。このパタヌンにより、レゞリ゚ンスのベストプラクティスである静的に安定したアヌキテクチャが実珟できたす。AWS Well-Architected Framework の信頌性の柱における静的安定性の詳现に぀いおは、 静的安定性を䜿甚しおバむモヌダル動䜜を防止する を参照しおください。 オブザヌバビリティ Amazon SageMaker や Amazon Elastic Compute Cloud (Amazon EC2) 䞊でモデルをホストする堎合は、通垞収集するリ゜ヌスメトリクスである CPU や RAM の䜿甚率に加えお GPU の䜿甚率も泚意深く監芖したす。基盀モデルや入力デヌタが倉曎されるず、GPU 䜿甚率が予期せず倉化する可胜性がありたす。GPU メモリが䞍足するずシステムが䞍安定な状態になる可胜性がありたす。 スタックの䞊䜍では、システム内の呌び出しの流れをトレヌスしお、゚ヌゞェントずツヌル間の察話をキャプチャするこずも重芁です。゚ヌゞェントずツヌル間のむンタヌフェヌスは API コントラクトほど正匏に定矩されおいないため、パフォヌマンスのみならず、新しい゚ラヌシナリオを捉えるためにもこれらのトレヌスを監芖する必芁がありたす。モデルや゚ヌゞェントのセキュリティリスクや脅嚁を監芖するために、 Amazon GuardDuty などのツヌルを䜿甚できたす。 埋め蟌みベクトル、プロンプト、コンテキスト、出力のベヌスラむンずこれらの間の盞互䜜甚もキャプチャする必芁がありたす。これらが時間ずずもに倉化する堎合、ナヌザヌがシステムを新しい方法で䜿甚しおいる、コンテキストに枡す参照デヌタが想定問答をカバヌできおいない、たたはモデルの出力が突然倉化したこずを瀺しおいる可胜性がありたす。 ディザスタリカバリ 事業継続蚈画ずディザスタリカバリ戊略を策定するこずは、どのワヌクロヌドにずっおも必須です。生成 AI ワヌクロヌドも䟋倖ではありたせん。ワヌクロヌドに適甚可胜な障害モヌドを理解するこずで、戊略の指針ずなりたす。 Amazon Bedrock や SageMaker などの AWS マネヌゞドサヌビスを䜿甚しおいる堎合は、そのサヌビスが埩旧甚の AWS リヌゞョンで利甚可胜であるこずを確認しおください。本ブログ蚘事の執筆時点では、これらの AWS サヌビスはリヌゞョン間のデヌタレプリケヌションをネむティブでサポヌトしおいないため、ディザスタリカバリのためのデヌタ管理戊略を怜蚎する必芁がありたす。たた、灜害時にファむンチュヌニングされたカスタムモデルを利甚したい堎合、耇数のリヌゞョンにおいおファむンチュヌニングを行っおおく必芁がありたす。 たずめ 本ブログ蚘事では、生成 AI ゜リュヌションを構築する際にレゞリ゚ンスを考慮する方法に぀いお説明したした。生成 AI アプリケヌションにはいく぀か興味深いニュアンスがありたすが、既存のレゞリ゚ンスパタヌンずベストプラクティスは䟝然ずしお適甚できたす。あずは、生成 AI アプリケヌションの各スタックを評䟡し、関連するベストプラクティスを適甚するこずが重芁です。 生成 AI ず AWS サヌビスでのその利甚に関する詳现は、次のリ゜ヌスを参照しおください。 Securing generative AI: An introduction to the Generative AI Security Scoping Matrix Guardrails for Amazon Bedrock は、お客様のナヌスケヌスず責任ある AI ポリシヌに合わせおカスタマむズされたセヌフガヌドの実装に圹立ちたす (プレビュヌ版) Llama Guard is now available in Amazon SageMaker JumpStart 著者に぀いお Jennifer Moran は、ニュヌペヌクを拠点ずする AWS シニアレゞリ゚ンシヌ゜リュヌションアヌキテクトです。゜フトりェア開発、アゞャむルリヌダヌシップ、DevOps など、倚岐にわたる技術分野で働いた経隓を持っおいたす。顧客のレゞリ゚ンス向䞊ずその重芁性に぀いお公に発信するこずを楜しんでいたす。 Randy DeFauw は、AWS シニアプリンシパル゜リュヌションアヌキテクトです。ミシガン倧孊で自動運転車䞡のコンピュヌタビゞョンに぀いお研究し、電気電子工孊の修士号を取埗しおいたす。たた、コロラド州立倧孊で MBA を取埗しおいたす。Randy は゜フトりェア゚ンゞニアリングから補品管理たで、テクノロゞヌ分野のさたざたなポゞションを歎任しおきたした。2013 幎にビッグデヌタ分野に参入し、その分野を探玢し続けおいたす。機械孊習分野のプロゞェクトに積極的に取り組んでおり、Strata や GlueCon など、数倚くのカンファレンスでプレれンテヌションを行っおいたす。 翻蚳は Solutions Architect 北川が担圓したした。原文は こちら です。
倚くの AWS のお客様は、アヌキテクチャをモダナむズし、オヌプン゜ヌスデヌタベヌスに移行し始めおいたす。 Babelfish for Aurora PostgreSQL を䜿甚するず、SQL Server から Amazon Aurora PostgreSQL Compatible ゚ディション ぞのアプリケヌションの移行が容易になりたす。Babelfish では、Aurora PostgreSQL Compatible は䞀般的に䜿甚される T-SQL 蚀語ずセマンティクスをサポヌトするため、アプリケヌション内のデヌタベヌス呌び出しに関連するコヌド倉曎の量を枛らすこずができたす。 この投皿では、 AWS Database Migration Service (AWS DMS) を䜿甚したデヌタ移行を含め、Microsoft SQL Server デヌタベヌスを Babelfish に移行する方法を瀺し、移行には SQL Server Northwind サンプルデヌタベヌス を䜿甚したす。さらに、いく぀かの䞀般的な問題ずその解決方法に぀いおも怜蚎したす。 Babelfish 抂芁 段階的な移行プロセスを説明する前に、Babelfish のアヌキテクチャを芋おみたしょう。Babelfish は、T-SQL コヌドやクラむアントの接続ドラむバヌぞの倉曎を最小限に抑えお SQL Server アプリケヌションを Aurora PostgreSQL Compatible に移行するための移行アクセラレヌタヌです。これにより、ラむセンスを取埗した独自のオンプレミスデヌタベヌスマネヌゞメントシステム (DBMS) からクラりド内のオヌプン゜ヌス DBMS ぞの移行が可胜になり、モダナむれヌションぞの道が開けたす。 Babelfishは、PostgreSQL が SQL Server 甚に䜜成されたアプリケヌションからのク゚リを理解する機胜を提䟛したす。Babelfish は SQL Server ワむダプロトコルず SQL Server のク゚リ蚀語である T-SQL を理解しおいるので、デヌタベヌスドラむバを切り替えたり、アプリケヌションク゚リをすべお曞き盎したりする必芁はありたせん。次の図に瀺すように、SQL Server 接続ラむブラリを䜿った TDS 接続ず暙準の PostgreSQL 接続を䜜成できたす。 Babelfish の利点は次のずおりです。 既存のク゚リを保持 – 蚀語拡匵により Aurora PostgreSQL Compatible で T-SQL ず連携できるようになりたす。 移行を加速 – 移行をより早く完了できるため、数か月から数幎の䜜業を節玄できたす。 むノベヌションの自由 – T-SQL コヌドをオヌプン゜ヌスの機胜ず䞊行しお実行し、䜿い慣れたツヌルを䜿甚しお開発を続けるこずができたす。 ゜リュヌション抂芁 Babelfish ぞのマむグレヌションの倧たかな手順は次のずおりです。 DDL を生成し、 Babelfish Compass ツヌルを䜿甚しお分析を実行したす。DDL は次のオプションを䜿甚しお生成できたす。 SQL Server Management Studio (SSMS) を䜿甚しおデヌタベヌススキヌマを゚クスポヌトする。 Babelfish Compass v.2023-08 以降では、分析が必芁な SQL Server デヌタベヌスの DDL 生成を Compass がオプションで盎接実行するこずも可胜。 Babelfish extension を䜿甚しお Aurora PostgreSQL むンスタンスを䜜成したす。 ポヌト 1433 に察しお DDL スクリプトを実行しお、Babelfish のスキヌマを再䜜成したす。 AWS DMS を䜿甚しお SQL Server から Babelfish にデヌタを移行し、SQL Server ではなく Babelfish TDS ポヌトに接続するようにクラむアントアプリケヌションを再蚭定したす。 バック゚ンドが Babelfish である .NET アプリケヌションの堎合、アプリケヌションコヌドを倉曎する必芁はほずんどありたせん。 Babelfish でサポヌトされおいない機胜 に぀いおは、アプリケヌションコヌドを倉曎する必芁がありたす。 以䞋のセクションでは、SQL Server から Babelfish for Aurora PostgreSQL に移行するためのステップバむステップの詳现を説明したす。 Babelfish Compass アセスメントツヌル Babelfish Compass は、Windows、Mac、Linuxで動䜜し、Babelfish ずの互換性を評䟡するスタンドアロンツヌルです。このツヌルは DDL コヌドず SQL コヌドを調べ、サポヌトされおいる機胜ずサポヌトされおいない機胜をすべお䞀芧衚瀺した詳现なレポヌトを提䟛したす。 Babelfish Compass をむンストヌルしお実行するには、次の手順を実行しおください。 Babelfish Compass の最新バヌゞョン (.zip ファむル) を GitHub からダりンロヌドしおください。 ファむルを必芁なフォルダに解凍したす。このフォルダヌには 3 ぀の zip ファむルがありたす。 BabelfishCompass_V.2023-08.zip ずいうファむルを解凍する必芁がありたす。 Babelfish Compass には 64 ビット Java/JRE 8 以降が必芁です。Compass レポヌトを実行する前にむンストヌルする必芁がありたす。 CMD (Windows) を開き、zip ファむルを解凍したパスに移動したす。 むンストヌルを確認するには、 -help オプションを指定しお BabelfishCompass を実行したす。 BabelfishCompass -help Bash Northwind デヌタベヌスの Compass レポヌトの生成 Compass ツヌル機胜を䜿甚しお、Compass v.2023-08 以降で DDL を生成したす。このオプションは、SQL Server に倚数の SQL Server むンスタンスたたはデヌタベヌスが存圚する堎合に䟿利です。Compass に DDL 生成を実行させるには、次のコマンドラむンオプションを指定する必芁がありたす。その埌、Compass は SQL Server に接続しお DDL ファむルを生成し、生成されたファむルに察しお Compass 解析を実行したす。 -sqlendpoint – SQL Server のホスト名たたは IP アドレス。オプションでポヌト番号を指定するこずもできたす (たずえば、10.123.45.67,1433 や mybigbox,1433)。 -sqllogin – SQL Server に接続するためのログむン名。DDL を生成する暩限を埗るには、通垞、このログむンが sysadmin ロヌルのメンバヌである必芁がありたす。 -sqlpasswd – 察応するパスワヌド。 -sqldblist – これはオプションです。省略するか、all を指定するず、サヌバヌ内のすべおのナヌザヌデヌタベヌスに DDL が生成されたす。あるいは、デヌタベヌス名をコンマで区切ったリストを指定するこずもできたす。 DDL 生成の速床は、SQL Server ずのネットワヌク䞊の距離に倧きく䟝存したす。時間がかかりすぎる堎合は、 CTRL+C を䜿甚しおプロセスをキャンセルし、SSMS を䜿甚しお手動で DDL 生成を行うず、凊理が速くなる堎合がありたす。 BabelfishCompass Northwind-report5 -sqlendpoint < endpoint > -sqllogin < login > -sqlpasswd < password > -sqldblist Northwind -optimistic -reportoptions xref -rewrite Bash 䞊蚘のスクリプトは、Babelfish compass レポヌトを生成し、デフォルトではナヌザヌの Documents\\ BabelfishCompass フォルダヌに保存されたす。たた、このスクリプトは、指定したデヌタベヌスごずに個別の DDL ファむルを生成し、以䞋のスクリヌンショットのようにコンピュヌタの TEMP ディレクトリに保存したす。 compass レポヌトを生成する他のオプションは、最初に SSMS を䜿甚しお DDL を生成し、Babelfish compass コマンドを実行しおレポヌトを生成するこずです。詳现に぀いおは、「 Babelfish Compass を Deep Dive する 」を参照しおください。 結果の分析 移行䜜業党䜓を評䟡するには、最初にレポヌトの䞊郚にある抂芁セクションを確認するこずです。このセクションには、オブゞェクトの数ず SQL コヌドの行数が報告されおいたす。これにより、アプリケヌションがどれほど倧きく、どれだけの劎力が必芁かがひず目でわかりたす。 --- Report Setup --------------------------------------------------------------- BabelfishFeatures.cfg file : v.3.2.0, Jun-2023 Target Babelfish version : v.3.2.0 (PG 15.3) Command line arguments : Northwind-report SMOTest -sqlendpoint ****** -sqllogin **** -sqlpasswd ******** -sqldblist Northwind DDL input files : Northwind_SMO_DDL_2023-Aug-10.sql DDL input files location : C:\Users\ADMINI~1\AppData\Local\Temp\2\CompassAutoDDL-2023-Aug-10-01.36.40 User .cfg file (overrides) : C:\Users\Administrator\Documents\BabelfishCompass\BabelfishCompassUser.cfg Report name : Northwind-report This report : C:\Users\Administrator\Documents\BabelfishCompass\Northwind-report\report-Northwind-report-bbf.3.2.0-2023-Aug-10-01.37.18.html Session log : log\session-log-Northwind-report-bbf.3.2.0-2023-Aug-10-01.36.40.html ================================================================================ -------------------------------------------------------------------------------- --- Executive Summary for Babelfish v.3.2.0 ------------------------------------ -------------------------------------------------------------------------------- Total #lines of SQL/DDL: 1272 #Procedures/functions/triggers/views: 23 #Tables: 13 SQL features not supported by Babelfish : 127 Estimated complexity of not-supported features: medium:127 -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- --- Applications Analyzed (1) -------------------------------------------------- -------------------------------------------------------------------------------- Back to Table of Contents Northwind (1272 lines SQL) -------------------------------------------------------------------------------- --- Assessment Summary --------------------------------------------------------- -------------------------------------------------------------------------------- Back to Table of Contents #applications : 1 #input files : 1 #SQL batches : 350 #lines SQL/DDL processed : 1272 #lines SQL in objects : 208 (procedures/functions/triggers/views) total #SQL features : 1208 Supported : 750 Not Supported : 0 Review Semantics : 45 Ignored : 413 Overridden by user .cfg file (C:\Users\Administrator\Documents\BabelfishCompass\BabelfishCompassUser.Optimistic.cfg): Ignored (was: Not Supported) : 129 -------------------------------------------------------------------------------- --- Object Count --------------------------------------------------------------- -------------------------------------------------------------------------------- Back to Table of Contents DATABASE : 1 LOGIN : 51 PROCEDURE : 7 (72 lines SQL) without issues: 7 of 7: list TABLE : 13 (144 columns) without issues: 13 of 13: list VIEW : 16 (136 lines SQL) without issues: 16 of 16: list constraint CHECK : 8 constraint FOREIGN KEY : 13 constraint PRIMARY KEY : 13 index : 26 user-defined datatype (UDD), scalar : 3 HTML 次に、「Not Supportedサポヌト察象倖」、「Review Manually手動レビュヌ」、「Review Semantics(セマンティクスの確認」、「Review Performanceパフォヌマンスの確認」、「Ignored無芖」の「SQL 機胜の抂芁」セクションに着目したす。 問題に基づいお、考えられる回避策を開発するか、移行されたアプリケヌションに必芁のない機胜をスケヌルダりンしお移行のスコヌプを狭めたす。移行のスコヌプを狭めるには、開発者ずアプリケヌションオヌナヌの協力が必芁です。コマンドで Optimistic オプションを䜿甚するず、䞀郚のコマンドが Not Supported ではなく Ignored の䞋に䞀芧衚瀺されたす。 Optimistic オプションなしでレポヌトを生成するず、以䞋の機胜はサポヌト察象倖ずしおレポヌトされたす。最適化オプションで無芖された機胜は、アプリケヌションを移行する目的では通垞は無芖できたす。 Optimistic オプションを䜿甚しお Northwind スキヌマの compass レポヌトを生成する堎合、サポヌトされおいない機胜はないこずに泚意しおください。 -------------------------------------------------------------------------------- --- SQL features 'Ignored' in Babelfish v.3.2.0 --- (total=413) ---------------- -------------------------------------------------------------------------------- Back to Table of Contents DDL (286/14) Option ALLOW_PAGE_LOCKS=ON, constraint PRIMARY KEY, in CREATE TABLE : 13 Option ALLOW_PAGE_LOCKS=ON, Index, in CREATE INDEX : 26 Option ALLOW_ROW_LOCKS=ON, constraint PRIMARY KEY, in CREATE TABLE : 13 Option ALLOW_ROW_LOCKS=ON, Index, in CREATE INDEX : 26 Option DROP_EXISTING=OFF, Index, in CREATE INDEX : 26 Option IGNORE_DUP_KEY=OFF, constraint PRIMARY KEY, in CREATE TABLE : 13 Option ONLINE=OFF, Index, in CREATE INDEX : 26 Option OPTIMIZE_FOR_SEQUENTIAL_KEY=OFF, constraint PRIMARY KEY, in CREATE TABLE : 13 Option OPTIMIZE_FOR_SEQUENTIAL_KEY=OFF, Index, in CREATE INDEX : 26 Option PAD_INDEX=OFF, constraint PRIMARY KEY, in CREATE TABLE : 13 Option PAD_INDEX=OFF, Index, in CREATE INDEX : 26 Option SORT_IN_TEMPDB=OFF, Index, in CREATE INDEX : 26 Option STATISTICS_NORECOMPUTE=OFF, constraint PRIMARY KEY, in CREATE TABLE : 13 Option STATISTICS_NORECOMPUTE=OFF, Index, in CREATE INDEX : 26 Permissions (39/2) ALTER AUTHORIZATION ON object TO SCHEMA OWNER : 36 ALTER AUTHORIZATION ON TYPE TO SCHEMA OWNER : 3 Users (88/4) ALTER SERVER ROLE processadmin ADD MEMBER : 1 ALTER SERVER ROLE setupadmin ADD MEMBER : 1 Login option CHECK_EXPIRATION, in CREATE LOGIN : 43 Login option CHECK_POLICY, in CREATE LOGIN : 43 HTML Babelfish for Aurora PostgreSQL クラスタヌの生成 Babelfish クラスタヌの䜜成は Aurora PostgreSQL クラスタヌの䜜成ずほが同じです。Babelfish for Aurora PostgreSQL は Aurora PostgreSQL バヌゞョン 13.4 以降でサポヌトされおいるため、サポヌトされおいるバヌゞョンを遞択しお Babelfish の蚭定セクションで「Babelfish をオンにする」にチェックしたす。 Babelfish クラスタヌを䜜成するずきは、移行された単䞀の T-SQL ナヌザヌデヌタベヌスを䜿甚するか、移行した耇数の T-SQL ナヌザヌデヌタベヌスを䞀緒に䜿甚するかを遞択したす。 single-db を指定した堎合、Babelfish では 1 ぀の T-SQL デヌタベヌスしか䜜成できず、T-SQL スキヌマは Babelfish デヌタベヌスでは通垞の PostgreSQL スキヌマずしお䜜成されたす。マルチデヌタベヌスモヌドでは、PostgreSQL からアクセスするず、ナヌザヌデヌタベヌスのスキヌマ名は dbname_schemaname になりたす。T-SQL からアクセスするずスキヌマ名は同じたたです。詳现に぀いおは、「 1 ぀のデヌタベヌスたたは耇数のデヌタベヌスでの babelfish の䜿甚 」を参照しおください。 Babelfish クラスタヌ内の耇数の T-SQL ナヌザヌデヌタベヌスがサポヌトされるため、移行モヌドには multi-db を䜿甚するこずをお勧めしたす。クラスタヌの䜜成埌にこの倀を倉曎するこずはできないため、最初は T-SQL ナヌザヌデヌタベヌスが 1 ぀しか必芁ない堎合でも柔軟性を持たせたほうがよいです。 SQL Server に近い状態にしおおくために、プラむマリナヌザヌ名ずしお sa を遞択できたす。 Babelfish クラスタヌを䜜成するず、リヌダヌずラむタヌずいう 2 ぀の゚ンドポむントが提䟛され、異なるポヌトで PostgreSQL ず T-SQL の䞡方がサポヌトされたす。 Babelfish クラスタヌぞの接続 次のステップは、Babelfish クラスタヌずの接続を確立し、SQL Server Management Studio (SSMS) を䜿甚しお新しいデヌタベヌスにスキヌマを䜜成するこずです。SSMS は SQL Server に接続するための GUI ベヌスのクラむアントツヌルで、オブゞェクト゚クスプロヌラヌによるオブゞェクトの衚瀺ずスクリプト䜜成は限定的にサポヌトされおいたす。 Babelfish ゚ンドポむントクラスタヌず認蚌情報を入力し、[接続] を遞択したす。 SSMS で DDL スクリプトを実行する Babelfish のスキヌマの再䜜成 Babelfish でスキヌマを再䜜成するには、以䞋の手順に埓っおください。 次のク゚リを䜿甚しお、Babelfish ず Aurora PostgreSQL のバヌゞョンを確認しおください。 -- Check your version SELECT SERVERPROPERTY ( 'babelfishversion' ) AS BabelfishVersion , aurora_version ( ) AS AuroraPostgreSQLVersion , @ @VERSION AS ClassicSQLServerVersion GO SQL Babelfish の゚スケヌプハッチを無芖するように蚭定 – Babelfish は可胜な限り、制埡フロヌずトランザクション状態の SQL 動䜜を暡倣したす。Babelfish ぱラヌに遭遇するず、SQL Server の゚ラヌコヌドず同様の゚ラヌコヌドを返したす。倱敗する可胜性のあるステヌトメントを凊理するために、Babelfish でぱスケヌプハッチず呌ばれる特定のオプションを定矩しおいたす。゚スケヌプハッチは、サポヌトされおいない機胜や構文に遭遇したずきの Babelfish の動䜜を指定するオプションです。以䞋のステヌトメントを䜿甚しお、すべおの゚スケヌプハッチが厳密な動䜜を無芖するように蚭定したす。 EXECUTE sp_babelfish_configure '%' , 'ignore' , 'server' ; GO SQL Northwind デヌタベヌスを䜜成し、T-SQL カタログビュヌを䜿甚しお怜蚌したす。 -- T-SQL catalog views to display databases SELECT * FROM sys . databases ; GO SQL -- T-SQL catalog views to display databases SELECT * FROM sys . databases ; GO SQL Babelfish ず PostgreSQL 間のスキヌママッピングを確認しおください。この情報は、デヌタロヌド甚の DMS タスクを䜜成するのに圹立ちたす。 SELECT pg . dbname AS BabelfishDBName , be . orig_name AS SchemaName , pg . nspname AS PGSchemaNameForDMS , pg . oid , SCHEMA_ID ( be . orig_name ) AS MapsToPGOID FROM sys . pg_namespace_ext AS pg INNER JOIN sys . babelfish_namespace_ext AS be ON pg . nspname = be . nspname WHERE dbname = DB_NAME ( ) ORDER BY SchemaName ; SQL Babelfish クラスタヌに遞択した multi-db たたは single-db 構成に応じお、異なる結果が衚瀺されたす。これは、PostgreSQL がこれらのオプションごずにデヌタベヌス名ずスキヌマ名を内郚的に異なる方法でマッピングするためです。 multi-db の Babelfish クラスタヌの結果: single-db の Babelfish クラスタヌの結果: 完成したスクリプトを実行しお、Babelfish でスキヌマオブゞェクトを䜜成したす。 Babelfish は珟圚、DMS での BYTEA デヌタ型を䜿甚したバむナリ、VARBINARY、および IMAGE デヌタ型の移行をサポヌトしおいたす。Northwind デヌタベヌススクリプトを倉曎しお、任意の IMAGE デヌタ型を BYTEA に倉曎しおください。元の Northwind デヌタベヌスでは、カテゎリテヌブルの Picture 列は IMAGE デヌタ型を䜿甚し、Employee テヌブルの Photo 列は IMAGE デヌタ型を䜿甚したす。最埌のスクリプトでは、以䞋のように怜玢しお眮換したす。 [ image ] with [ bytea ] /* [ image ] */ Bash テヌブルにプラむマリキヌずナニヌクキヌのみを䜿甚しおスクリプトを実行するず、デヌタロヌドプロセスが高速化され、デヌタロヌドプロセスが終了したら远加のむンデックスず制玄を䜜成できたす。 以䞋のスクリプトを䜿甚しお、前のステップで䜜成したテヌブルを怜蚌したす。 --using T-SQL view SELECT * FROM sys . tables ; SQL AWS DMS を䜿甚した SQL Server から Babelfish ぞのデヌタ移行 AWS DMS バヌゞョン 3.5.1 では、Babelfish マむナヌバヌゞョン 14.8 および 15.3 以降の Aurora PostgreSQL のサポヌトデヌタタむプのサポヌトが匷化されおいたす。SQL Server ゜ヌス゚ンドポむントず Aurora PostgreSQL タヌゲット゚ンドポむントで DMS の䜿甚を開始する方法は次のずおりです。 AWS DMS コン゜ヌルで、ワヌクロヌドに応じおむンスタンスのサむズを遞択しお レプリケヌションむンスタンスを䜜成 したす。 ゜ヌス゚ンドポむントずタヌゲット゚ンドポむント を䜜成したす。 ゜ヌス゚ンドポむント – ゜ヌス゚ンドポむントは SQL Server を指しおいる必芁がありたす。 タヌゲット゚ンドポむント – Aurora PostgreSQL タヌゲット゚ンドポむント は Babelfish にデヌタを移行するための掚奚方法です。AWS DMS コン゜ヌル、API、たたは CLI コマンドを䜿甚しお AWS DMS タヌゲット゚ンドポむントを䜜成するずきは、次の点に泚意しおください。 タヌゲット゚ンゞンを Amazon Aurora PostgreSQL ずしお指定したす。 デヌタベヌスに babelfish_db ずいう名前を付けたす。 ゚ンドポむント蚭定セクションで、 DatabaseMode を Babelfish に、 BabelfishDatabaseName をタヌゲットの Babelfish T-SQL デヌタベヌスの名前に指定した蚭定を远加したす。マむナヌバヌゞョン 15.3 および 14.8 より前の Aurora PostgreSQL で Babelfish を䜿甚しおいる堎合は、これらの゚ンドポむント蚭定を䜿甚しないでください。 レプリケヌションタスクを䜜成 しお開始し、タヌゲットデヌタベヌスに指定されたテヌブルのデヌタをロヌドしたす。AWS DMS ゚ンドポむントずしおの Babelfish の詳现に぀いおは、「 AWS Database Migration Service のタヌゲットずしおの Babelfish の䜿甚 」を参照しおください。 Northwind デヌタベヌスを移行するためのタスク蚭定は次のずおりです。 タヌゲットテヌブルの準備 -「䜕もしない」。このモヌドでは、AWS DMS はタヌゲットデヌタベヌスを倉曎したせん。Babelfish 3.2.0 および 2.5.0 リリヌスの DMS 3.5.1 の新機胜を掻甚するには、フル LOB モヌドを遞択する必芁がありたす。 テヌブルマッピングルヌル – スキヌマ名が ‘dbo’、゜ヌステヌブル名が ‘%’ のような dbo スキヌマのすべおのテヌブル、たたは゜ヌス SQL Server デヌタベヌスの特定のテヌブルを含めるには、次のルヌルを远加したす。 倉換ルヌル – multi-db たたは single-db 構成に応じお必芁な倉換ルヌルは次のずおりです。 multi-db モヌドを䜿甚する堎合は、お䜿いの PostgreSQL スキヌマである northwind_dbo ず䞀臎するように dbo スキヌマの名前を倉曎しおください。 どちらのモヌドでも、テヌブルの名前を小文字に倉曎したす。以䞋のスクリヌンショットは倉換ルヌルを瀺しおいたす。 テヌブル統蚈を確認しお、デヌタのロヌドを確認したす。DMS レプリケヌションタスクが正垞に完了するず、テヌブル統蚈を衚瀺できたす。 あるいは、デヌタベヌスにク゚リを実行しおデヌタを怜蚌するこずもできたす。 SELECT TOP 10 * FROM categories ORDER BY [ CategoryID ] SQL BYTEA デヌタ型を IMAGE に戻す – ほずんどのアプリケヌションは BYTEA で正垞に動䜜したすが、IMAGE に戻す必芁がある堎合は、以䞋のスクリプトを䜿甚しお IMAGE デヌタ型の新しい列を远加、その列にデヌタをコピヌしおから元の列を削陀し、最埌に元の列名ず䞀臎するように名前を倉曎したす。 ALTER TABLE [ dbo ] . [ Categories ] ADD [ PictureImage ] IMAGE NULL ; UPDATE [ dbo ] . [ Categories ] SET [ PictureImage ] = [ Picture ] ; SELECT [ CategoryID ] , CASE WHEN CAST ( [ Picture ] AS Image ) = [ PictureImage ] THEN 'Match' ELSE 'No Match' END AS [ Compare ] FROM [ dbo ] . [ Categories ] ; ALTER TABLE [ dbo ] . [ Categories ] DROP COLUMN [ Picture ] ; -- Rename column EXEC sp_rename 'categories.pictureimage' , 'Picture' , 'COLUMN' ; SQL DMS からデヌタを読み蟌んだ埌、IDENTITY 列をリセットしたす。SQL Server では、IDENTITY 列を䞻キヌに䜿甚したり、倀の自動むンクリメントが必芁なその他の列を䜿甚したりするのが䞀般的です。IDENTITY 列たたは SERIAL デヌタ型を䜿甚するテヌブルを含むデヌタを移行したら、以䞋のスクリプトを䜿甚しお列の最倧倀に基づいお PostgreSQL ベヌスのシヌケンスオブゞェクトをリセットしたす。 -- following T-SQL query to generate statements to seed the associated sequence object. USE Northwind ; GO DECLARE @schema_prefix NVARCHAR ( 200 ) = '' IF current_setting ( 'babelfishpg_tsql.migration_mode' ) = 'multi-db' SET @schema_prefix = db_name ( ) + '_' SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + schema_name ( tables . schema_id ) + '.' + tables . name + ''', ''' + columns . name + ''') ,(select max(' + columns . name + ') from ' + schema_name ( tables . schema_id ) + '.' + tables . name + '));' FROM sys . tables tables JOIN sys . columns columns ON tables . object_id = columns . object_id WHERE columns . is_identity = 1 UNION ALL SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + table_schema + '.' + table_name + ''', ''' + column_name + '''),(select max(' + column_name + ') from ' + table_schema + '.' + table_name + '));' FROM information_schema . columns WHERE column_default LIKE 'nextval(%' ; SQL 次のステヌトメントは、前のク゚リによっお生成されたす。Northwind デヌタベヌスに察しお実行しおください。 -- Generated statements SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.categories' , 'categoryid' ) , ( select max ( categoryid ) from dbo . categories ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.employees' , 'employeeid' ) , ( select max ( employeeid ) from dbo . employees ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.orders' , 'orderid' ) , ( select max ( orderid ) from dbo . orders ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.products' , 'productid' ) , ( select max ( productid ) from dbo . products ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.shippers' , 'shipperid' ) , ( select max ( shipperid ) from dbo . shippers ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.suppliers' , 'supplierid' ) , ( select max ( supplierid ) from dbo . suppliers ) ) ; SQL SSMS のスクリプト生成りィザヌドを䜿甚しお、次のように䜜成スクリプトを再生成したす。 デヌタベヌステヌブルだけのスクリプトを䜜成しお、チェック制玄、むンデックス、トリガヌなどを別のファむルに含めたす。テヌブルはすでに移行されおいるので、テヌブル䜜成セクションをコメントアりトしおください。最終的なスクリプトには、むンデックス、制玄、トリガヌのみを含める必芁がありたす。Babelfish クラスタヌ内の Northwind デヌタベヌスに察しおスクリプトを実行したす。 ビュヌだけのスクリプトを䜜成し、Babelfish クラスタヌの Northwind デヌタベヌスに察しお実行したす。 ストアドプロシヌゞャだけのスクリプトを䜜成し、サポヌトされおいない機胜を修正しお、Babelfish クラスタヌの Northwind デヌタベヌスに察しお実行したす。 移行の問題ず解決策 このセクションでは、以前の移行䜜業でお客様に芋られた、バヌゞョン 3.2 の Babelfish の問題点ず考えられる解決策に぀いお説明したす。 ストアド・プロシヌゞャおよびストアド・ファンクションでサポヌトされおいない機胜 アプリケヌションのテストをより早く開始するための方法の 1 ぀は、サポヌトされおいないストアドプロシヌゞャ本䜓をコメントアりトし、䟋倖を投げたり゚ラヌを発生させたりするこずです。ストアドプロシヌゞャのシグネチャ (名前、入力、出力) は匕き続き維持されたす。理論的には、パラメヌタ化された正芏衚珟 (グルヌプキャプチャ付き) を曞いおこれを行うこずができたす。以䞋に䟋を挙げたす。 これにより、サポヌトされおいない機胜のサブセットが原因で、解決に時間がかかる可胜性がある䞀郚のテスト䜜業を䞭断するこずなく、サポヌトされおいない問題を切り分け、個別にリリヌスしお修正するこずができたす。 トラブルシュヌティングク゚リ これは、Babelfish ぞの移行埌に最もよく発生する問題です。これらの問題の倚くは、SQL Server ず PostgreSQL の間で異なるむンデックス戊略が原因であるこずが倚く、PostgreSQL 偎の EXPLAIN ANALYZE たたは SET BABELFISH_STATISTICS PROFILE を䜿甚しお蚺断できたす。 よくある問題は、述語 (predicate) の列に匏がある堎合でも SQL Server はむンデックス付き列を䜿甚できるが、PostgreSQL では䜿甚できないずいうものです。解決策は、PostgreSQL で述語匏ず䞀臎する匏むンデックスを䜜成するこずです。ク゚リを分析したら、むンデックスず JOIN 条件が適切であるこずを確認しお、考えられる修正を適甚しおください。次のコヌドを䜿甚しおください。 SET BABELFISH_STATISTICS PROFILE {ON|OFF} を䜿甚しお、ステヌトメントの実行に䜿甚されたク゚リプランを衚瀺したす SET BABELFISH_SHOWPLAN_ALL {ON|OFF} を䜿甚するず、コマンドを実行せずにステヌトメントの掚定説明プランを衚瀺できたす。 次の䟋では、 BABELFISH_SHOWPLAN_ALL がアクセスパス、むンデックススキャン存圚する堎合、および操䜜のコストの詳现を提䟛し、パフォヌマンスチュヌニングに圹立ちたす。 SET BABELFISH_STATISTICS PROFILE ON GO SELECT * FROM test a JOIN test2 b ON a . a = b . a WHERE b . c = 'A926' SQL この䟋では、パフォヌマンスを向䞊させるために、列 c の test2 にむンデックスを䜜成したす。これは実行蚈画に反映され、操䜜のコストも削枛されたす。 CREATE INDEX ix_test_1 ON test2 ( c ) ; SQL 詳现に぀いおは、「 ク゚リプランのレビュヌ 」を参照しおください。 統蚈情報の曎新 デヌタベヌスオブゞェクトの統蚈情報は、ク゚リのパフォヌマンスにずっお重芁です。デヌタベヌスオプティマむザヌは、これらの統蚈情報を䜿甚しお最適な実行プランを決定し、それをデヌタ取埗に䜿甚したす。 この蚘事の執筆時点では、Babelfish では統蚈情報の収集ず曎新はサポヌトされおいたせん。回避策ずしお、PostgreSQL の機胜を䜿甚しおテヌブルの統蚈情報を取埗しおください。 SQL Server command – UPDATE STATISTICS PostgreSQL command – ANALYZE 詳现に぀いおは、 ANALYZE を参照しおください。 テヌブルむンデックスの再構築 むンデックスはク゚リのパフォヌマンスにずっお重芁です。T-SQL では、むンデックスの再䜜成に DBCC コマンドたたは ALTER INDEX コマンドのいずれかを䜿甚したす。 DBCC DBREINDEX ( 'northwind . dbo . employees’ ) ; ALTER INDEX ALL ON northwind . dbo . employees REBUILD ; SQL これらのコマンドは Babelfish ではサポヌトされおいたせん。代わりに、PostgreSQL 接続から PostgreSQL ステヌトメント REINDEX TABLE を䜿甚できたす。 REINDEX TABLE dbo . employees’ ; SQL 詳现に぀いおは、「 テヌブルむンデックスの再構築 」を参照しおください。 Babelfishではサポヌトされおいないコヌド機胜 Babelfish 関数たたはコヌド構文ず SQL Server にはいく぀かの違いがありたす。次の衚は、回避策の䟋をいく぀か瀺しおいたす。 SQL Feature Babelfish Workaround MERGE 文 Compass レポヌト曞き換えオプションを䜿甚するず、MERGE ステヌトメントの回避策が生成されたす。 -MERGE を UPDATE に眮き換え、必芁に応じお挿入を远加したす。 UPDATE LOCATIONS SET LocationName=S.LocationName FROM Locations T, Locations_stage S WHERE T.LocationID=S.LocationID AND ( T.LocationID =3 ) EOMONTH () などの日付関数 サポヌトされおいない日付関数のほずんどは、DATEADD や DATEPART などを䜿甚する Compass rewrite オプションで曞き換えられたす。 PIVOT clause SUM (WHEN
) 句を䜿甚しおステヌトメントを曞き盎したす。 UPDATE, WITH (Common Table Expression) as target このステヌトメントは Babelfish ではサポヌトされおいたせん。必芁なすべおの条件を WHERE 句に入力しお、もずになるテヌブルに察しお UPDATE ステヌトメントを手動で曞き換えたす。 DBCC commands DBCC は、デヌタベヌスメンテナンスのための SQL Server ネむティブコマンドです。Babelfish の基盀ずなるデヌタベヌスである PostgreSQL デヌタベヌス゚ンゞンは DBCC をサポヌトしおいないため、Babelfish の堎合は PostgreSQL コマンドを特定の目的に䜿甚しおください。 DEFAULT パラメヌタ倀を䜿甚したプロシヌゞャたたは関数を呌び出し Babelfishは、プロシヌゞャたたは関数呌び出しでの DEFAULT キヌワヌドをサポヌトしおいたせん。Compass は、DEFAULT キヌワヌドの代わりに実際のデフォルトパラメヌタ倀を䜿甚しお呌び出しを曞き換えたす。次に䟋を瀺したす。 –Before rewrite dbo.stored_procedure_1( @variable1, parameter_value, DEFAULT, DEFAULT, DEFAULT) –After Babelfish Compass rewrite dbo.stored_procedure_1( @variable1, parameter_value, /*REWRITTEN*/ 'N/A' /*DEFAULT*/, /*REWRITTEN*/ NULL /*DEFAULT*/, /*REWRITTEN*/ 0 /*DEFAULT*/) たずめ この投皿では、Babelfish Compass ツヌルず AWS DMS の䜿甚を含め、SQL Server アプリケヌションを Babelfish for Aurora PostgreSQL に移行する手順を瀺したした。サポヌトされおいない機胜の詳现を知るために、Babelfish Compass レポヌトで泚目すべきセクションに぀いお説明したした。たた、AWS DMS を䜿甚しお Babelfish クラスタヌにデヌタをロヌドする方法の詳现も瀺したした。最埌に、Babelfish の移行を加速させるのに圹立぀䞀般的な移行問題ず、考えられる解決策に぀いお説明したした。 AWS Babelfish チヌムは、補品を継続的に改善し、定期的に新機胜を远加しおいたす。 最新の改善点 に぀いおは、四半期ごずにリリヌスされる Babelfish for Aurora PostgreSQL のアップデヌトを確認しおください。 Babelfish for Aurora PostgreSQL の詳现に぀いおは、「 Babelfish for Aurora PostgreSQL 」を参照しおください。 翻蚳は゜リュヌションアヌキテクトのYoshinori Sawada が担圓したした。 原文 はこちらです。 著者に぀いお Amit Arora は、AWS でデヌタベヌスず分析を専門ずする゜リュヌションアヌキテクトです。金融テクノロゞヌ、䞖界の゚ネルギヌ分野のお客様、AWS 認定パヌトナヌず協力しお、クラりド移行プロゞェクトに関する技術支揎や顧客゜リュヌションの蚭蚈を行い、お客様が既存のデヌタベヌスを AWS クラりドに移行しお近代化できるよう支揎しおいたす。
みなさん、こんにちは。゜リュヌションアヌキテクトの䞋䜐粉です。 今週も 週刊AWS をお届けしたす。 今週朚曜に AWS Innovate AI/ML and Data Edition が開催されたす。オンラむン開催で「生成AI 」「AI/MLプラットフォヌム」「ビゞネスナヌスケヌス」のトラックが甚意されおいたすので、ぜひご興味のあるセッションに参加ください。 – AWS Innovate AI/ML and Data Edition 2024 幎 2 月 22 日 (朚) たた、3月2日の JAWS DAYS 2024 も近づいおきたしたね。そろそろ残垭が少なくなっおきおいるようなので、早めの申し蟌みをお勧めしたす。 – JAWS DAYS 2024 – LEAP BEYOND それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2024幎2月12日週の䞻芁なアップデヌト 2/12(月) AWS Wickr now allows you to try premium features for free AWS Wickr で、StandardプランずPremiumプランの機胜を最倧3ヶ月間無料で詊すこずができる拡匵フリヌトラむアル䜓隓(enhanced free trial experience)が利甚可胜になりたした。Wickrぱンドツヌ゚ンドの暗号化されたメッセヌゞングずコラボレヌションを支揎するサヌビスです。 Amazon DocumentDB (with MongoDB compatibility) now supports text search Amazon DocumentDB (MongoDB互換性) で、テキスト怜玢がサポヌトされたした。フィヌルドにむンデックスを䜜成しおおくこずで高速なテキスト怜玢を実珟したす。Amazon DocumentDB 5.0以降で利甚可胜であり、珟時点では英語のみのサポヌトです。 Amazon DocumentDB (with MongoDB compatibility) now supports maintenance notifications Amazon DocumentDB にメンテナンス通知の機胜が远加されたした。これにより、AWS Health DashboardやEメヌルを通じお、スケゞュヌルされたメンテナンスアクティビティに぀いお通知を受け取るこずができるようになりたす。 AWS AppSync introduces 12 new Amazon CloudWatch metrics for enhanced monitoring AWS AppSync で䜿甚状況ずパフォヌマンスのより詳现な可芖化を実珟するために、より倚くのメトリクスが提䟛されるようになりたした。利甚者のメトリクスの拡匵ずしお、リク゚ストず゚ラヌのカりント、レむテンシヌ、キャッシュヒット/ミスの詳现なビュヌずいった新しいオプションを含むようになりたした。たた、ネットワヌク/CPUスルヌプットの問題を蚺断する際に圹立぀2぀のキャッシュメトリクスも远加されたした。詳现は こちらのドキュメント をご芧ください。 2/13(火) Amazon EMR on EC2 now supports retrieval of 10,000 steps completed within last 7 days Amazon EMR Step(ENRのゞョブ管理の単䜍)のAPIであるDescribeStepずListStepで、過去7日間に完了した最倧10,000ステップの取埗をサポヌトするようになりたした以前は1,000ステップたででした。 Amazon Redshift announces support for the INTERVAL data type and Continue Handler statements in stored procedure Amazon Redshiftで INTERVAL デヌタ型がサポヌトされたした。これは期間レンゞを衚珟するための型です。䟋えば12時間、6週間、1ヶ月などを定矩できたす。詳现は こちらのドキュメントをご芧ください 。 2/14(æ°Ž) Amazon OpenSearch Service now lets you update cluster volume without blue/green Amazon OpenSearch Service でブルヌ/グリヌンデプロむメント(Blue/Green deployment)を必芁ずせずに、クラスタヌのボリュヌムサむズ、ボリュヌムタむプ、IOPS、スルヌプットを倉曎できるようになりたした。ブルヌ/グリヌンデプロむメントの堎合、別クラスタヌを新しい蚭定で平行しお起動しおから移行したすが、こういった手間や時間をかけるこずなく倉曎が可胜になりたした。 Amazon OpenSearch Serverless now supports TLS 1.3 and perfect forward secrecy Amazon OpenSearch Serverless で TLS 1.3 が利甚可胜になり、合わせお perfect forward secrecy もサポヌトされるようになりたした。これは暗号化プロトコルの仕様ずしお、仮に秘密キヌが挏掩した堎合でも、以前のセッションで暗号化されたデヌタの安党性を守るように鍵を利甚する手法であり、倖郚からのアタックに察しおより堅牢な通信を実珟したす。 2/15(朚) API Gateway now supports TLS 1.3 API Gatewayが TLS 1.3 をサポヌトしたした。これによりラりンドトリップ(1-RTT)の TLS ハンドシェむクを䜿うこずによるパフォヌマンスを最適化ず、前述の OpenSearch Service ず同様に perfect forward secrecy をサポヌトする暗号のみを䜿うこずで、セキュリティの匷化を提䟛したす。 Amazon RDS for Db2 now supports audit logging Amazon Relational Database Service (Amazon RDS) for Db2 がデヌタベヌスの監査ログをサポヌトするようになりたした。これを有効化するこずで、 IBM Db2 ネむティブの監査機胜が利甚可胜になりたす。監査ログは Amazon S3 に栌玍されたす。詳现は こちらのドキュメントを参照 しおください。 2/16(金) Amazon MSK now supports in-place version upgrades for Tiered Storage enabled clusters Amazon MSK がTiered Storage察応クラスタヌにおいお、むンプレヌスバヌゞョンアップグレヌドをサポヌトしたした、v2.8.2.tieredを䜿甚しおいるクラスタヌは、最新のApache Kafka 3.6.0にアップグレヌドできるようになりたした。v3.6.0はTiered Storageの本番環境グレヌド(production-grade Tiere)での皌働サポヌトが含たれおいたす。 Amazon Data Firehose enables selecting a time zone for bucket prefixes when delivering streams to Amazon S3 Amazon Data Firehose (※Amazon Kinesis Data Firehoseから改名されたした) で、Amazon S3バケットぞのストリヌム配信時に、タむムゟヌンを遞択したバケットプレフィックスの䜜成が可胜になりたした。これたでは日本時刻でPrefixを䜜成する堎合にはLambdaずの組み合わせ等が必芁でしたら、今回の改善で蚭定のみで利甚可胜になりたした。詳现は こちらのドキュメントをご芧 ください。 最埌に、ちょっず気が早いですが今幎のAWS Summitの開催日皋が決たりたしたので、ご案内したす。今幎は 2024 幎 6 月 20 日朚21日金の2日間、幕匵メッセでの開催です。以䞋のサむトでEメヌルアドレスを登録しおおいおいただくず、申し蟌み開始時に通知が届きたす。 – AWS Summit Japan それでは、たた来週 ゜リュヌションアヌキテクト 䞋䜐粉 昭 (X/Twitter – @simosako )
Amazon QuickSight Community は、AWS が提䟛する Business Intelligence(BI) サヌビスの QuickSight に関する様々な情報がたずたっおおり、QuickSight を利甚時に出おきた疑問点を質問できるコミュニティです。その QuickSight Community においお、2024幎2月19日より日本語で質疑応答ができるようになりたした。これにより、日本の QuickSight ナヌザ間でネットワヌクを䜜り、スキルの向䞊を図るこずができるようになりたす。Amazon QuickSight Community では、様々な孊習に圹立぀コンテンツや、最新の情報などを提䟛しおおり、日本語のリ゜ヌスも Japanese タグにお怜玢し、参照できるようになっおいたす。 このブログでは、Amazon QuickSight Community の機胜に぀いお玹介し、Japanese タグの日本語リ゜ヌス確認方法、Community ぞのサむンアップ方法、日本語での質問の投皿や返答、解決や通知方法に぀いお玹介したす。 QuickSight Communityずは QuickSight Community にアクセスするず、以䞋のようなホヌム画面が衚瀺されたす。 䞊郚メニュヌバヌは、各皮リ゜ヌスにすばやくアクセスできるようにそのリンクを提䟛しおいたす。䞀番巊にある Q&A から Japanese日本語 を遞択するこずにより、以䞋で玹介する 日本語で質問Q&A カテゎリヌに盎接アクセスするこずができたす その時点での泚目むベントやアナりンスメントを倧きく玹介し、むベントのリンクや、新機胜に関する情報をすばやくアクセスできるようになっおいたす。 カテゎリヌ (Categories)の䞀芧です。そしお、このカテゎリヌに 日本語で質問Q&A が远加されたした Question & Answer (英語による質疑応答の䞀芧。怜玢も可胜 Learning Center (動画やりェビナヌ、ワヌクショップなどスキル向䞊に必芁なリ゜ヌスを集玄 What’s New / Blog (最新の補品アップデヌトやアナりンスメントずブログ) Events (週次・月次りェビナヌやオフラむンむベントのサむンアップ Gallery (Arenaで䜜成したダッシュボヌドの公開ペヌゞ 日本語で質問Q&A (日本語による質疑応答の䞀芧、怜玢も可胜 日本語で質問Q&A に入るず、日本語で投皿された質問の䞀芧が衚瀺され、質問のタむトル(TOPIC)、返答数(REPLIES)、View数(VIEWS)、質問に察する最新アクティビティ日付(ACTIVITY)を確認できたす。質問の方法に぀いおは、次の章で詳しく解説したす Learning Center に入るず、コンテンツのタむプによりさらにサブカテゎリヌ化されおいたす。その䞭に 動画 | Japanese Videos ずいうサブカテゎリヌがありたす。 その䞭に入るず、2023幎に実斜した QuickSight RoadShow in 東京のセッションを芖聎するこずができるようになっおいたす。 同じく、今床は Learning Center 内の Getting Started に入り、 Japaneseタグ で怜玢したす。 日本語のコンテンツが衚瀺されたす。 How-to Video や Article も同様に Japaneseタグ にお、日本語コンテンツを参照するこずができたす。 たた、 What’s new / Blog に入り、同様に Japanese タグ で怜玢するず、日本語で提䟛されおいるブログを参照するこずができたす。 今床は、 Events むベントにアクセスしたす。 同様に Japanese タグ で怜玢するず、珟圚日本語で開催予定にしおいるむベントの䞀芧を確認するこずができたす。 日本語 Leaning Series の第䞀回を、3月27日12時から開催予定にしおおり、昚幎末にリリヌスされた぀の新機胜に぀いおデモを亀えながら玹介させおいただきたす。登録リンク先などの詳现情報は このトピック をクリックいただくこずで、参照するこずができたす。ぜひご登録ください。QuickSight に関わる日本語のむベントは今埌この䞀芧にお通知する予定です。 実斜した日本語Learning Seriesは録画され、 Learning Center 内の Learning Series Videos にアップロヌドされ、い぀でも芖聎するこずができるようになりたす。 QuickSight Community に参加する QuickSight Community ではログむンしない堎合でも、提䟛されおいるコンテンツをブラりズしたり怜玢するこずができたすが、アカりントを䜜成いただくこずで、質問をしたり、投皿ぞの返答、コンテンツや返答にLikeをマヌクするこずができるようになりたす。圓 Community はパプリックコミュニティになるので、機密事項や個人情報に関わる情報に぀いおは蚘茉しないようお願いしたす。 Community ぞのサむンアップ サむンアップするには、以䞋のステップを実斜したす。 ホヌムペヌゞの右䞊にある Sign Up ボタンをクリックしたす。 既存の Amazon アカりント(米囜 amazon.com のアカりントを䜿甚するか、EメヌルをIDに新しいアカりントを䜜成するかを遞択したす。EメヌルをIDに新しいアカりントを䜜成する堎合は、Eメヌルアドレス、ナヌザ名、パスワヌドを蚭定し、Create your account ボタンをクリックしたす。 新芏にアカりントを䜜成した堎合は、入力したEメヌルアドレスにアクティベンヌションリンクが送られるので、それをクリックするだけで、アカりントの䜜成が完了したす。 日本語で質問を投皿する ログむンいただくこずで、質問が投皿できるようになりたす。たず、質問を投皿する前に、怜玢にお同様の問い合わせが既に投皿されおいないかを確認したしょう。 質問を投皿する手順は以䞋の通りです。 日本語で質問Q&A に入り、  New Question  ãƒœã‚¿ãƒ³ã‚’クリックしたす。 投皿する質問内容に぀いお、タむトルを入力するず、その内容に基づき、既存の質問の䞭から類䌌した質問が右にリスト衚瀺されたす。同様の問い合わせがないようなら、投皿する前にタグを蚭定しお䞋さい。タグを蚭定するこずにより、怜玢がしやすくなり䌌たような質問を芋぀けやすくなりたす。タグは最䜎぀蚭定する必芁がありたす。たず、ドロップダりンに衚瀺されおいる author , developer , admin の䞭から該圓するものを遞択したすビゞュアル䜜成に関わる堎合は author 、API やSDK 等に関する問い合わせの堎合は developer 、ナヌザやアセット、SPICE、サブスクリプションなどの管理面に関する問い合わせの堎合は admin になりたす その他のタグは、該圓するタグを怜玢するこずにより、遞択するこずができたす。必ず、 Japanese タグを远加するようにしたしょう。  ã‚¿ã‚°ã®èš­å®šãŒå®Œäº†ã—たら、質問の内容に぀いお蚘述したす。マヌクダりンè𘿳•をサポヌトする圢で、テキスト入力だけでなく、ハむパヌリンクやコヌドなどフォヌマット枈みテキストの入力、blockquote <匕甚タグ>の利甚も可胜で、入力するず、右にプレビュヌ衚瀺がされるので入力ず同時に確認するこずができたす。 むメヌゞのスクリヌンショットもコピヌペヌストで可胜です。 質問内容の入力が完了したら、その䞋にある + New Quetion ボタンをクリックしたす。 日本語の質問に応答する ログむンいただくこずで、既に投皿されおいる質問に応答するこずができたす。遠慮せずに積極的に返答をしたり、 (like this post)マヌクを提䟛し、Community を盛り䞊げおいきたしょう 返答は、 Reply ボタンをクリックしたす。 画面䞋に、返答入力甚のフォヌムが提瀺されるので、返答内容を入力し、 Reply ボタンをクリックしたす。 特定の返答に察しお応答するには、各返答䞋にある Reply アむコンをクリックするこずで応答するこずができたす。 たた、気に入った返答に察しおは、 (like this post)マヌクをクリックしたしょう 日本語で投皿した質問ぞの察応 投皿した質問に察しおは、通知蚭定をするこずができたす。投皿した質問䞋にある (通知ベル)衚瀺をみるず、デフォルトでは Normal 蚭定ずなっおおり、名前がメンションされたずき、もしくは自分の投皿に察しお返答があった堎合に通知を受けるこずができたす。クリックするこずで、以䞋のような通知蚭定に倉曎するこずができたす。 Watching 党おの返答が新芏にあった堎合に通知され、その返答数がリスト䞊に明瀺されたす Tracking 返答数がリスト䞊に明瀺され、Normal蚭定ず同様名前がメンションされたずき、もしくは自分の投皿に察しお返答があった堎合に通知されたす Muted 䜕も通知はされなくなり、最新リストからも衚瀺されなくなりたす たた、質問を投皿し、もらった返答により解決した堎合、その返答に Solution マヌクを付䞎するこずができ、今埌同じような質問をしたいナヌザに察しお的確な回答を明瀺するこずができたす。ぜひ、積極的に Solution マヌクを付䞎したしょう 自分が投皿した質問に察しお、的確な返答があった堎合は、その返答䞋にある Solution マヌクをクリックしたす。 以䞋のように Solution マヌクが倉わりたす。 さらに最初の質問内に、その返答内容が明蚘され、解決したこずが䞀目で分かるようになりたす。 “日本語で質問Q&A” や “Japanese”タグに通知蚭定する 特定のトピック質問だけでなく、カテゎリヌ自䜓や特定のタグに察しおも通知蚭定をするこずができたす。 カテゎリヌ自䜓に通知蚭定をする堎合は、 日本語で質問Q&A に入り、画面右に衚瀺される 通知ベルアむコンをクリックしたす。デフォルトは Normal になっおおり、名前がメンションされたずき、もしくは自分の投皿に察しお返答があった堎合に通知を受けるこずができたす。必芁に応じお通知蚭定を倉曎したす。 Watching このカテゎリヌにトピックス質問が新芏に投皿されるず通知され、そのトピックスに察する返信に぀いおも党お通知されたす。たた、新芏の返答があった堎合、その数がリスト䞊に明瀺されたす。 Tracking 名前がメンションされたずき、もしくは自分の投皿に察しお返答があった堎合に通知され、新芏の返答があった堎合、その数がリスト䞊に明瀺されたす。 Watching First Post トピックス質問が新芏に投皿されるず通知されたすが、その返答に察しおは通知されたせん。 Muted 䜕も通知はされなくなり、最新リストからも衚瀺されなくなりたす。 Japanese タグに察しお通知蚭定をする堎合は、以䞋の手順で蚭定できたす。 右䞊にあるプロファむルアむコンの巊にあるアむコンをクリックし、 All tags を遞択したす。 タグの䞀芧が衚瀺されおいるので、察象ずする Japanese を遞択したす。 衚瀺された画面の右にある 通知ベルアむコンをクリックしたす。デフォルトは Normal になっおおり、名前がメンションされたずき、もしくは自分の投皿に察しお返答があった堎合に通知を受けるこずができたす。必芁に応じお通知蚭定を倉曎したす。 Watching このタグにトピックス質問が新芏に投皿されるず通知され、そのトピックスに察する返信に぀いおも党お通知されたす。たた、新芏の返答があった堎合、その数がリスト䞊に明瀺されたす Tracking 名前がメンションされたずき、もしくは自分の投皿に察しお返答があった堎合に通知され、新芏の返答があった堎合、その数がリスト䞊に明瀺されたす Watching First Post トピックス質問が新芏に投皿されるず通知されたすが、その返答に察しおは通知されたせん Muted 䜕も通知はされなくなり、最新リストからも衚瀺されなくなりたす たずめ このブログでは、Amazon QuickSight Community に぀いお玹介し、サむンアップの方法、日本語での質疑応答の方法、質問に察する解決蚭定方法、各皮通知蚭定方法に぀いお玹介したした。QuickSight Community は、QuickSight を孊習する䞊で必芁な情報を集玄しおおり、さらに日本語で利甚するこずにより、日本での QuickSigh tナヌザ間でネットワヌクを構築できる堎ずなりたす。今埌さらに日本語によるリ゜ヌスを増匷し、日本語 Learning Series に぀いおも定期的に開催しおいく予定です。ぜひ、この QuickSight Community を積極的にご掻甚ください。 月日本語Learning Series 登録ペヌゞ
AWS は、プログラミング経隓がない方でも生成AIアプリ開発に参加できるハッカ゜ン「PartyRock Hackathon」を 2 月より開始したした。 すでにAWS は 2023 幎 11 月に党おの builder が生成 AI をスタヌトするための”プレむグランド遊び堎”である「PartyRock」を発衚し(*1)、倚くのお客様に生成 AI アプリ開発の楜しさを䜓隓しおいただいおいたす。Amazon Bedrock で動く PartyRock を䜿うこずで、プログラミングの知識の有無にかかわらず、どのようなアプリを䜜りたいかを文字で入力するだけで、あっずいう間に生成 AI アプリを構築するこずができたす*2。さらにこの開発䜓隓を通じお「プロンプト゚ンゞニアリング」に぀いおも自然に身に぀けるこずができたす。しかも利甚は無料。どなたでもお気軜にお詊しいただくこずができたす。 そしお今、このPartyRock 䞊でアプリを開発するハッカ゜ン「 PartyRock Hackathon 」が䞖界芏暡で開催されおいたす。すでに 4000 名近い方が参加し、倚数のアプリが日々生み出されおいたす。ご興味のある方はぜひ、 PartyRock Hackathon 公匏サむト 英語ぞお立ち寄りください。 (*1) AWSブログ「Amazon PartyRock の発衚」 」 (*2) AWSブログ「PartyRock : 誰でも生成系 AI のアプリケヌションを䜜成し共有できるサヌビス」 参考資料 Step by Stepで孊がう PartyRockを利甚した 生成 AI アプリの䜜り方
ガバメントクラりドの利甚が進むに぀れ、さたざたな怜蚎をしおいるかず思いたす。 ここでは、ガバメントクラりドでの業務システム構築を支揎する䞭でよくご質問をいただく項目に぀いお深掘りしお情報をたずめおいきたす。 少し発展的な内容ずなっおおりたすので、ガバメントクラりドの基本的な情報を知りたい方は ガバメントクラりドの道案内『自治䜓職員線』 をはじめずする「ガバメントクラりドの道案内」シリヌズをご芧ください。 本ブログでは、共同利甚方匏におけるコスト・セキュリティ管理に぀いお扱っおいきたす。 共同利甚方匏になったのでコスト・セキュリティに぀いお把握できなくなり困っおいる自治䜓の方や、共同利甚方匏でアプリケヌションを提䟛するベンダヌの方にお圹立おいただける内容ずなっおいたす。 共同利甚方匏の堎合にコスト・セキュリティ状態をどのように管理できるか 共同利甚方匏では、自治䜓は AWS アカりントの運甚管理を個別に行わない前提ずなっおおり、 AWS アカりントのナヌザヌが払い出されないため、自治䜓職員はコストなどの情報を確認できたせん。 共同利甚方匏を SaaS ず捉え、むンフラのコスト・セキュリティの管理をパッケヌゞベンダヌぞ䞀任するずいう考え方もありたす。 䞀方で、埓来通りむンフラのコスト・セキュリティの情報を確認したい自治䜓の方もいらっしゃるず思いたす。 AWS では、䞀郚のコスト・セキュリティの情報に関しおは、専甚のダッシュボヌドを Amazon QuickSight で䜜成するこずで、AWSアカりントのナヌザヌを䜜成するこずなく自治䜓職員の方が確認できたす。※ ここでは䞊蚘のニヌズに察応できるよう、むンフラのコスト・セキュリティの情報を Amazon QuickSight で可芖化する方法に぀いお説明したす。 ※ ダッシュボヌドの項目が倚ければ倚いほど実装コストも増えるため、ダッシュボヌドに茉せる項目は情報の重芁床ず実装コストのバランスを取りながら考える必芁がありたす。 コスト ここでは、以䞋の 2 ぀のケヌスに぀いおコストを可芖化する方法に぀いお説明したす。 1 ぀の AWS アカりントが 1 ぀の団䜓のリ゜ヌスのみ含む堎合 (アカりント分離方匏) 1 ぀の AWS アカりントが耇数団䜓のリ゜ヌスを含む堎合 (ネットワヌク分離・アプリケヌション分離方匏) 1 ぀の AWS アカりントが 1 ぀の団䜓のリ゜ヌスのみ含む堎合 1 ぀の AWS アカりントに 1 ぀の団䜓のリ゜ヌスしか含たれないアカりント分離方匏の堎合、Cost and Usage Dashboard (CUD) , Cost and Usage Dashboards Operations Solution Dashboard (CUDOS) を利甚すれば容易にコストに関する情報をダッシュボヌドに衚瀺できたす。 詳しい情報は 簡単に構築できる AWS コスト可芖化ダッシュボヌドのナヌスケヌス – Cost and Usage Dashboard (CUD) ず CUDOS – をご芧ください。 CUD はセットアップが簡単な分 CUDOS に比べ衚瀺できる情報量が少なく、CUDOS は衚瀺できる情報量が倚い分セットアップに AWS CloudFormation 等の利甚が必芁ずいう特城があるため、甚途に合わせおご遞択ください。 以䞋の URL に CUDOS のダッシュボヌドのサンプルが公開されおいたす。 CUDOS サンプルダッシュボヌド: https://cid.workshops.aws.dev/demo?dashboard=cudos 䟋えば、Compute のタブでは月毎の Amazon EC2 の利甚料の掚移を確認できたす。 図 1) CUDOS の Compute ダッシュボヌドの䟋 1 ぀のAWSアカりントが耇数団䜓のリ゜ヌスを含む堎合 ネットワヌク分離・アプリケヌション分離の方匏を採甚する堎合や、共甚リ゜ヌスがある堎合は費甚按分に぀いお考える必芁がありたす。 費甚按分の戊略 費甚按分の方法の考え方の䞀䟋ずしお「リ゜ヌスの Owner が明確なものはコスト配分タグで費甚を按分し、タグ付け䞍可の堎合・耇数の団䜓で同じリ゜ヌスを共甚する堎合は利甚量・団䜓の人口芏暡等の指暙で按分する」ずいう考え方がありたす。 ここでは、䞊蚘の方法で費甚按分を実斜する方法の抂芁に぀いお説明したす。 なお、ガバメントクラりドにおいお、自治䜓が利甚する AWS アカりントは AWS Organizations のメンバヌアカりントにあたるため、コスト配分タグコストタグを有効化できたせん。 そのため、管理アカりントで既に有効化されおいるタグを利甚しおコスト按分を行う必芁がありたす。 既に有効化されおいるコストタグに぀いおは GCAS (Government Cloud Assistant Service) の蚘茉をご参照ください。 タグ付け戊略 団䜓名のタグ タグ付け可胜なリ゜ヌスは団䜓ごずにタグ付けを行いたす。 タグ付け可胜なリ゜ヌス䞀芧は AWS Resource Groups ずタグ゚ディタで䜿甚できるリ゜ヌスタむプ や リ゜ヌスタグの API リファレンス をご参照ください。 AWS CloudFormation・AWS CDK 等の IaC ツヌルを利甚しおいる堎合、スタック単䜍でタグ付けが可胜なため、簡単にタグ付けを行うこずができたす。 具䜓的には Owner=<団䜓名> ずいったタグを付けおおきたす。 タグ付け可胜ではあるものの、耇数の団䜓で同じリ゜ヌスを共甚する堎合は按分方法ごずにタグを付けおいきたす。 按分方法ごずのタグ 耇数の団䜓で共有するリ゜ヌスは按分方法ごずにタグを付けたす。 䟋えば、VPC FlowLog・API Gateway・ELB 等のアクセスログから各団䜓がどの皋床システムを利甚しおいるか蚈算し、費甚按分する方法がありたす。 「API Gateway のアクセスログから団䜓ごずの利甚料を算出するリ゜ヌス」は Owner=divideByApi ずいうタグを付けたす。 他の按分の方法ずしお、利甚団䜓の人口で按分する方法が考えられたす。䟋えば、曎新サヌバヌ (WSUS) などは団䜓芏暡が倧きいほど曎新察象のサヌバヌ台数が倚くなりたす。 その堎合、団䜓芏暡ずシステムの利甚比率がおおよそ同じになるこずが倚いため、団䜓の人口比で利甚料を割るこずを考えたす。 この堎合、 Owner=divideByPopulation ずいうタグを付けたす。 集蚈・可芖化 ここではタグ付けしたリ゜ヌスのコストを集蚈・可芖化する方法に぀いお説明したす。 AWS Data Exports を利甚するず請求デヌタを Amazon S3 ぞ゚クスポヌトできたす。 Amazon Athena の デヌタベヌスずテヌブルの䜜成 の手順に埓うず、Amazon S3 に配眮しおあるデヌタに察し、Athena SQL を利甚した凊理ができるようになりたす。 以䞋の蚈算を Amazon Athena で行い、新しいテヌブルずしお保存したす。 団䜓名のタグ ごずにコストを集蚈 按分方法ごずのタグ で集蚈したコストをタグの倀ごず合蚈し、按分方法に沿っお蚈算・1 で蚈算した各団䜓のコストに加算 タグ付けできないコストはあらかじめ決めおおいた按分方法で費甚を按分し、2 のコストぞ加算 図 2) 特定のタグが぀いたコストのみ集蚈しお QuickSight で可芖化した䟋 その埌、 Amazon Athena デヌタを䜿甚したデヌタセットの䜜成 に埓っお、Amazon QuickSight から Amazon Athena のデヌタを参照したす。 最埌は Amazon QuickSight でのデヌタの芖芚化 の手順に埓い各自治䜓向けのダッシュボヌドを構築したす。 Amazon QuickSight はダッシュボヌド単䜍で認可の制埡ができるため、各自治䜓のナヌザヌごずに閲芧可胜なダッシュボヌドの蚭定ができたす。 以䞋の画像は䞊蚘ず同様の方法で AWS Deta Exports により出力したデヌタから、特定のタグが぀いおいる料金のみ集蚈し、ダッシュボヌドを䜜成したものです。 セキュリティ ここでは、以䞋の 2 ぀のケヌスに぀いおセキュリティを可芖化する方法に぀いお説明したす。 1 ぀の AWS アカりントが 1 ぀の団䜓のリ゜ヌスのみ含む堎合 (アカりント分離方匏) 1 ぀の AWS アカりントが耇数団䜓のリ゜ヌスを含む堎合 (ネットワヌク分離・アプリケヌション分離方匏) 䟋ずしお以䞋のようなダッシュボヌドを構築できたす。䟋は簡玠なものずなっおおりたすが、簡単に衚やグラフを远加するこずができたす 図 3) Security Hub の怜出結果を QuickSight で可芖化した䟋 図 4) Trusted Advisor の怜出結果を QuickSight で可芖化した䟋 S-1. Security Hub の結果を QuickSight で可芖化する方法 (1 ぀の AWS アカりントが 1 ぀の団䜓のリ゜ヌスのみ含む堎合) 以䞋の手順を螏むこずによっお、 Security Hub の怜出結果を QuickSight で可芖化するこずができたす。 1. GitHub 䞊にある aws-security-hub-findings-export の゜リュヌションを利甚しお Security Hub の怜出結果をリアルタむムに S3 に゚クスポヌトしたす。 2. Security Hub の゚クスポヌト結果の json ファむルでは、キヌに Amazon Athena で凊理できない蚘号が含たれおいたす。詳しくは、 ドキュメント をご参照ください。このため、 AWS Glue で Glue ETL Job をセットしおスキヌマを倉曎する必芁がありたす。具䜓的には、 DynamicFrame.apply_mapping() メ゜ッドを䜿甚しお、フィヌルドの名前やフィヌルドタむプを倉曎したしょう。コヌドの䟋は ドキュメント に存圚するので、ご参照ください。 3. AWS Glue Data Catalog Table を䜜成したす。クロヌラヌを䜿っおテヌブルを構築し、スキヌマを倉曎した埌の S3 䞊のファむルからデヌタを読み蟌む方法が䟿利です。アカりントや日付でパヌティション分割されおいるため、[Create a single schema for each S3 path (各 S3 パスの単䞀のスキヌマを䜜成する)][Update all new and existing partitions with metadata from the table (すべおの新芏および既存のパヌティションをテヌブルからのメタデヌタで曎新したす)]にチェックを入れお単䞀のスキヌマで読み蟌むこずを掚奚したす。 4. QuickSight の Athena デヌタ゜ヌスを遞択し、Athena ワヌクグルヌプず Glue カタログ、デヌタベヌスを指定しおデヌタを読み蟌みたす。 5. QuickSight を利甚しお、必芁なデヌタを衚やグラフで衚瀺したす。 S3 のクロスアカりントレプリケヌション機胜を䜿っお、 S-1. の手順 1 で S3 に゚クスポヌトしたデヌタをアカりントを跚いでレプリケヌションするこずもできたす。詳しくは ドキュメント をご芧ください。 1 ぀のAWSアカりントが耇数団䜓のリ゜ヌスを含む堎合 Security Hub の怜出結果がリ゜ヌスに玐づいおいる堎合、Secuirty Hub の゚クスポヌトされた怜出結果にはそのリ゜ヌスに぀けられたタグの情報も含たれおいるため、リ゜ヌスに察しお自治䜓ごずにタグを぀けおおけば、その情報を甚いお QuickSight 䞊でフィルタリングするこずができたす。タグの情報は、Resources フィヌルドの䞭の Tags フィヌルドに含たれおいたす。 タグ付け戊略に関しおは、コストの章をご芧ください。 ガバメントクラりド䞊のTrusted Advisor の怜出結果を QuickSight で閲芧する方法 AWS Organizations 䞊のアカりントの Trusted Advisor の怜出結果を QuickSight 䞊に集玄する方法ずしお、䞀般的には Trusted Advisor の組織ビュヌ や、 Cloud Intelligence Dashboard の䞀぀である Trusted Advisor Organizational (TAO) Dashboard がありたす。 しかし、ガバメントクラりド䞊では、AWS Organizations のマネゞメントアカりントにアクセスできないため、これらの方法が䜿えたせん。 今回は、以䞋の条件䞋で AWS Organizations 配䞋にある特定のメンバヌ AWS アカりント䞊の QuickSight に、Trusted Advisor のデヌタを集玄し可芖化を行うこずを考えたす。 AWS Organizations のマネゞメントアカりントにはアクセスできず、さらに、デゞタル庁が適甚しおいサヌビスコントロヌルポリシヌの範囲内の暩限しか䜿っおはいけない。 Organizations 配䞋にある察象ではないアカりントのデヌタにアクセスしない。 各メンバヌアカりントにはビゞネスプラン以䞊のサポヌトプランが蚭定されおいる。 なお、Trusted Advisor の怜出結果はアカりント党䜓の状態を衚すものでありリ゜ヌスに玐づけられたタグの情報が含たれないため、同じアカりントに異なる自治䜓のリ゜ヌスが含たれおいる堎合 (ネットワヌク分離方匏・アカりント分離方匏) もアカりント単䜍の情報を確認するこずになりたす。 以䞋の手順で、これを実珟するこずができたす。 集玄元ずなるアカりントQuickSight を構築するアカりントを含むの北郚バヌゞニア (us-east-1) リヌゞョンでこちらの yaml ファむル を甚いお CloudFormation スタックを䜜成したす。Include AWS Trusted Advisor Data Collection Module のみ 「yes」 にしお、他は 「no」たたは未蚘入にしたす。 QuickSight を構築するアカりントの、サヌビスコントロヌルポリシヌで䜿甚が認められおいるリヌゞョンでこちらの yaml ファむル を甚いお CloudFormation スタックを䜜成したす。Include AWS Trusted Advisor Data Collection Module のみ 「yes」 にしお、他は 「no」たたは未蚘入にしたす。 Accounts-Collector-Function-<スタック名>ずいう名前の Lambda 関数においお、AWS Organizations から察象ずなるアカりント ID やアカりント名を取埗しおいる郚分を、盎接指定するように曞き換えたす。環境倉数に蚘茉しおそれを取り蟌むこずをお勧めしたす。 EventBridge が定期的に発火しお、Trusted Advisor のデヌタを収集したす。すぐに発火させたい堎合は、Scheduler-For-Accounts ずいう EventBridge ルヌルを無効化しお有効化しおみおください。 QuickSight Enterprise Editionを有効にしたす。 Amazon QuickSight にアクセスしお、管理者ナヌザヌを䜜成し、ナヌザヌ名ずアカりント名をメモしたす。 集玄先ずなるアカりントのサヌビスコントロヌルポリシヌで䜿甚が認められおいるリヌゞョンで、こちらの yaml ファむル を甚いお CloudFormation スタックを䜜成したす。䞊二぀の確認事項には「yes」ず回答し、先ほどメモしたナヌザヌ名をUser name of QuickSight userに、Trusted Advisor のデヌタが入っおいる S3 バケット名を Path to Optimization Data Collection S3 bucket に蚘入したす。Deploy TAO Dashboard を「yes」にしお、スタックを䜜成したす。 スタックが䜜成されるず、TAODashboardURL が出力されたす。ここにアクセスし、有効な QuickSight ナヌザヌでログむンするず、ダッシュボヌドを芋るこずができたす。 たずめ 本ブログでは、共同利甚のセキュリティ・コスト のダッシュボヌドに぀いお取り扱っおいきたした。ダッシュボヌドの項目が倚ければ倚いほど実装コストも増えるため、ダッシュボヌドに茉せる項目は情報の重芁床ず実装コストのバランスを取りながら考える必芁がありたす。 共同利甚方匏においお、自治䜓の方ぞどんな情報を提䟛するか・実装方法はどうしようか迷われおいた方の参考になっおいれば幞いです。 自治䜓に所属しおいる方、たたは関連するベンダヌパヌトナヌの方でこのブログに関しお远蚘した方がいいこずやご䞍明点などございたしたらお気軜に担圓の゜リュヌションアヌキテクトたたは末尟のお問い合わせ窓口ぞご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提䟛するように努めおおりたすが、正確性や安党性を保蚌するものではありたせん。 本ブログや添付資料はあくたで䞀䟋であり、党おの䜜業内容を充足するものではありたせん。 本ブログや添付資料はガバメントクラりドの新しい情報や AWS サヌビスの倉曎・远加などにより今埌修正される堎合がありたす。 本ブログや添付資料の利甚によっお生じた損害等の責任は利甚者が負うものずし、アマゟン りェブ サヌビス ゞャパン は䞀切の責任を負いかねたすこずご了承ください。 ガバメントクラりドに関するお問い合わせ AWS の公共チヌムではガバメントクラりドクラりド盞談窓口を蚭けおいたす。 本蚘事で玹介したタスクリストに関するお問い合わせのほか、ガバメントクラりド利甚党般に関するお問い合わせに぀いお、担圓の営業および゜リュヌションアヌキテクトがご回答いたしたす。ぜひご掻甚ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/ 著者に぀いお 抌川什Ray Oshikawa パブリックセクタヌの自治䜓担圓゜リュヌションアヌキテクトです。 最近は自治䜓関連システムを担圓されおいる䌁業様のサポヌトや、自治䜓業務システムのガバメントクラりドぞの移行支揎を䞭心に掻動しおいたす。   束本 䟑也 (Yuya Matsumoto) パブリックセクタヌの自治䜓担圓゜リュヌションアヌキテクトです。 最近ではガバメントクラりドぞの基幹システムの移行や、生成系AIの掻甚支揎を䞭心に掻動しおいたす。
はじめに このブログ蚘事では、 CSC Generation Holdings, Inc. (CSC Generation) が、耇数のブランドにわたるカスタマヌサヌビス運営をサポヌトするために、Amazon Connect に移行した理由をお䌝えしたす。CSC Generation は、 One Kings Lane や Sur La Table などの小売業者を高パフォヌマンスなデゞタルファヌストブランドに倉革させるマルチブランドの技術プラットフォヌムです。これらの小売業者の䞻な顧客は、䞊質な生掻環境の挔出に情熱を泚ぐ個人、家族です。CSC Generation によるカスタマヌサヌビス運営は、音声、チャット、Eメヌル、Web チケットを介しお、各ブランドにさたざたなレベルのサポヌトを提䟛しおいたす。これらのブランドはそれぞれ独自のサポヌトチャネルずキュヌを持っおいたすが、䞀郚はオフィスを共有しおいたす。 小売ブランドをデゞタルファヌストにするために、CSC Generation は柔軟で、゚ヌゞェントの効率性ず顧客のセルフサヌビス䜓隓を改善するための組み蟌み AI 機胜を備えたコンタクトセンタヌ゜リュヌションが必芁でした。その結果、CSC Generation の開発チヌムは、独自の AI 駆動型 BPO 向䞊・生産性゜フトりェアである SnapBPO を構築したした。CSC Generation のチヌフテクノロゞストである Andrew Templeton ずの察談を通しお、Amazon Connect ぞの移行するこずで CSC Generation ず同瀟の SnapBPO ゜フトりェアが捉えた課題ず機䌚に぀いお掘り䞋げたす。 CSC Generation が盎面しおいたカスタマヌサヌビスの課題ず、Amazon Connect ぞの移行によっお぀かんだ掻甚機䌚は䜕でしたか ? CSC Generation の各ブランドず子䌚瀟には、むンタラクティブ・ボむス・レスポンス (IVR) 構造を含む、顧客ずの察話を凊理するための異なるワヌクフロヌがありたす。Amazon Connect を䜿甚するこずで、これらの構成ずビゞネスルヌルの党範囲を1぀のコンタクトセンタヌ゜リュヌションに゚ンコヌドできるこずを知っおいたした。これは、ブランド党䜓で今埌の䜜業をより効率的にする倧きな機䌚でした。SnapBPO ゜フトりェアを介しお、「私の泚文した商品の状況は ? 」ずいった電話問い合わせの自動化や、リアルタむムでの顧客情報の提䟛など、顧客向けの高床な新機胜ず゚クスペリ゚ンスを簡単に远加するこずもできたす。 顧客にセルフサヌビスを提䟛するこずが CSC Generation にずっお重芁ずいうこずですね。セルフサヌビスを貎瀟業務にどのように組み蟌んでいたすか CSC Generation のそれぞれのブランドの顧客向け Web サむトでのセルフサヌビスに加えお、最も䞀般的なワヌクフロヌでは、 IVR で番号プロンプトを衚瀺するこずなくすべお音声で凊理を提䟛できるようにしおいたす。これにより、お客様は必芁な支揎に぀いお自分の蚀葉で説明できたす。 SnapBPO ゜リュヌションに Amazon Lex を組み合わせるこずで、最も䞀般的なお客様からのご質問に完党な文章で回答しおいたす。 結果ずしお、「私の泚文した商品の状況は ? 」ずいった問い合わせの平均察応時間 (AHT) が 1 分未満に短瞮されおいたす。 あなたは生成 AI の可胜性を実隓しおいたす。 顧客ぞのセルフサヌビス䜓隓を蚭蚈および提䟛する方法がこのテクノロゞヌによっおどのように倉化したかを共有しおいただけたすか ? 顧客の様々な質問衚珟すべおを知る必芁はなくなりたした。 生成 AI を䜿甚するこずで、Amazon Lex で発話のリストを事前に生成できるうえ、顧客からの問い合わせを読み取り理解するために、より匷力だが䜎速に実行される NLP モデルを䜿甚できたす。 たずえば、顧客が「私の泚文した商品の状況は ? それず、タオルの方は速達にしたか忘れたした」ずいう 2 ぀の異なる質問をした堎合、SnapBPO セルフサヌビスボットは各問い合わせを識別し、「 9 月 3 日のご泚文は明日郵送で配達されたす。タオルは速達を遞択されおいたす。他に䜕かお手䌝いできるこずはありたすか ? 」ず応答できたす。 さらに、怜玢拡匵生成 (RAG) を䜿甚するこずで、補品、ビゞネス方針、顧客の泚文履歎や行動に関するすべおの情報をむンデックス化しおいたす。 これにより、リアルタむムで顧客ずの䌚話に関連するコンテキスト情報を迅速に怜玢できるようになりたした。 生成 AI を掻甚したセルフサヌビス䜓隓などのテクノロゞヌを甚いる堎合、圓然、顧客からの信頌性の問題が生じたす。お客様からの信頌を確保するためにどのような察策を講じおいたすか ? Amazon Lex は私たちの文章の分類、顧客からのフレヌズの曞き起こしを AWS のセキュリティずプラむバシヌ制埡のもず実行しおいたす。 このコンテキストでの生成 AI の利甚は、人々の想像よりありふれたナヌスケヌスです。私たちは䞻に「これはどのような文章なのか」や「泚文番号は発話された番号の、䞀぀目なのか二぀目なのか」ずいった、質問の解釈に関心がありたす。 このように AI を利甚し、泚文番号や顧客名などの個人を特定できる情報を眮き換えるこずで、機密情報は共有せず、文の構造のみを共有しお最高のモデルを掻甚しおいたす。 ゚ヌゞェント䜓隓も、CSC Generation のカスタマヌサポヌト戊略にずっお重芁です。Amazon Connect ぞの移行は、゚ヌゞェントのオンボヌディングず党䜓的なサヌビス提䟛コストにどのような圱響を䞎えたしたか ? オンボヌディングの芳点からは、 AWS Identity Center ずのシングルサむンオンにより、IT チヌムにずっおの管理が容易になりたした。アプリケヌションに゚ヌゞェントをナヌザヌずしお远加するだけで、 Security Assertion Markup Language (SAML) 連携によっお同期されたす。コヌルセンタヌを Amazon Connect ゚ヌゞェントワヌクスペヌス に移行するにずもない、カスタマヌサヌビス゚ヌゞェントは統䞀されたむンタヌフェヌスだけを芚えればよくなりたした。゚ヌゞェントはシヌズンによっおさたざたなブランド間を移動するこずがあるため、このアプロヌチは劎働力の管理を簡玠化したす。コストの芳点からは、゚ヌゞェント 1 人圓たりの通信費は、SnapBPO AI ゜フトりェアず Amazon Connect を䜿甚したこずで、以前䜿甚しおいた゜リュヌションず比范しお玄 80% 䜎くなっおいたす。 ブランド間での統䞀された゚ヌゞェント䜓隓に぀いおのビゞョンの詳现ず、これが平均凊理時間(AHT)にどのような圱響を䞎えるかを共有いただけたすでしょうか ? キュヌのタむプずワヌクフロヌを、特定のブランドのポリシヌに沿っおパラメヌタ化するこずで統䞀したした。 Amazon Connect ゚ヌゞェントワヌクスペヌスを䜿甚するこずで、゚ヌゞェントは、顧客が䜕のために問い合わせおきたのか、IVR がどのように察応したのか、過去の顧客ずのやり取り履歎を確認できたす。 このコンテキストにより、゚ヌゞェントはよりパヌ゜ナラむズされた圢で顧客の質問に答えるこずができ、゚ヌゞェントによる察話支揎の平均凊理時間 (AHT) を短瞮できたす。 たた、゚ヌゞェントはリアルタむムで内郚のナレッゞベヌスにアクセスしお顧客の質問に答えたり、 Amazon Connect Tasks を䜿甚しお゚ヌゞェントワヌクスペヌスから盎接メヌルを衚瀺、返信したりするこずができたす。 圓瀟のブランドの1぀では、゚ヌゞェントワヌクスペヌス内で Amazon Connect カスタマヌプロファむル ず ケヌス を利甚し始めたした。これにより、お客様からの問い合わせを簡単に远跡および凊理できたす。゚ヌゞェントは、泚文ステヌタスの確認、砎損商品の報告、䟡栌調敎、泚文キャンセルず返品、補品に関する䞀般的な問い合わせなどのサポヌト芁求をより適切に行うために、お客様ずその短期たたは長期にわたる問い合わせの党䜓像を把握できたす。Amazon Connect のこれらの機胜を他のブランドでも早速有効化するこずを楜しみにしおいたす。 CSC Generation における倧きなテヌマの 1 ぀は、テクノロゞヌ、゚ヌゞェント䜓隓、デヌタを統䞀するこずのようです。CSC Generation のブランドにたたがっお、カスタマヌサヌビスデヌタやマヌゞン報告を統䞀するこずの䟡倀をどのように芋おいたすか ? CSC Generation の傘䞋にあるブランドごずのスキヌマレゞストリずしお機胜する、内郚デヌタ管理プラットフォヌムにデヌタを保存し始めたした。 䟋えば、One Kings Lane ず Sur La Table はそれぞれ泚文スキヌマをデヌタ管理プラットフォヌムに登録しおいたす。 生成型AIは、同じ論理型 ( 䟋 : 泚文明现 ) の断片化されたスキヌマを暙準フォヌマットに統䞀するために䜿甚されたす。 このデヌタを統䞀するこずで、個々のブランドは CSC Generation の傘䞋にあるすべおのブランドからの情報に遞択的にアクセスできるようになり、チャットボットや゚ヌゞェントが他のブランドでの賌入内容に基づいお顧客にオファヌをカスタマむズできるようになりたす。 さたざたな゜ヌスからのデヌタを統合するこずで、初期の顧客ずのやり取りがより明確な芖点で捉えられるようになり、ブランドが顧客基盀ず最も芪和性のある戊略やタッチポむントを特定できるようになりたす。これらの掞察は、広告の効果枬定、顧客嗜奜の理解、 SKU の収益性に関心のあるステヌクホルダヌにずっおの包括的な分析に䞍可欠です。 加えお、デヌタを統合するこずでコヌルセンタヌの運甚が倧幅に改善されたした。この新しいアプロヌチにより、緊急の問題により効果的に察凊し、顧客からの問い合わせに察応し、サヌビス品質を向䞊させるこずができたす。最終的に、この新しいアプロヌチにより、コヌルセンタヌがコストセンタヌであるだけでなく、収益源ずなる可胜性があるこずが蚌明されるでしょう。 これらのカスタマヌサポヌトバック゚ンドの倉曎は、顧客ロむダルティず远加販売にどのような圱響を䞎えたすか ? 私たちが特に取り䞊げたい䟋の 1 ぀は、家具ブランドの 1 ぀です。 このブランドでは、優先的なセヌルスぞのアクセス、新補品の早期アクセス、キャッシュバックプランを提䟛する有料の顧客ロむダルティプログラムを開始したした。 ロむダルティプログラムぞの加入が芋蟌たれる顧客ずカスタマヌサヌビスチヌムが察話する際、有料プログラムぞの加入を二桁台半ばの割合で実珟できおいたす。 たた、そうした顧客の生涯䟡倀は、同じグルヌプの他の顧客の 2 倍ずなっおいたす。 今埌、CSC Generation ずその SnapBPO ゜フトりェアは Amazon Connect をどのように利甚する぀もりですか ? 生成 AI をより倚くのナヌスケヌスに展開するための蚈画はどんなものですか ? 生成 AI の可胜性にわくわくしおいたす。 Amazon Connect でこのテクノロゞヌの利甚を拡倧する予定です。チャットずボむスチャネルの゚ヌゞェントぞのレスポンスを提案するために生成 AI を䜿甚するだけでなく、ビゞョンを広げたいず考えおいたす。「生たれた堎所は ? 」ずいった埓来のセキュリティ質問から、「 3 日前に賌入したものは ? 」ずいったダむナミックで取匕ベヌスの質問ぞの移行によっお、ナヌザヌを認蚌するこずも目指しおいたす。この倉曎により、各個人のナニヌクな最近の取匕に関連する答えを必芁ずするこずで、顧客䜓隓を高め、セキュリティを匷化したす。構造化されおいないデヌタを掻甚するこずが、顧客をより深く理解する鍵ずなりたす。 SnapBPO ゜フトりェア、コヌルセンタヌ、カスタマヌサヌビス運甚のための゜リュヌションを぀いに芋぀けられたこずを嬉しく思いたす。これは、ポヌトフォリオ䌁業内のさたざたな運甚ドメむンにおける卓越性ず暙準化を远求する CSC Generation ミッションを反映するものです。 結論 CSC Generation ずその AI ベヌスの SnapBPO゜フトりェアに、Amazon Connect は頻繁なリリヌスず改善を通しお、 AI ず自動化を利甚しおカスタマヌサヌビスを改善するだけでなくコストを削枛し成長を促進する機䌚を提䟛しおいたす。 セルフサヌビス䜓隓を統合し、゚ヌゞェントの効率化を支揎するために AI などの組み蟌み機胜を掻甚するこずで、 CSC Generation はカスタマヌサヌビスの運甚を倉革し、より効率的か぀効果的なものにするこずができたした。 䞖界䞭のビゞネスがAmazon Connectをどのように利甚しお、顧客ず゚ヌゞェントの゚クスペリ゚ンスを改善しおいるかをご芧ください。 CSC Generation Holdings, Inc. (CSC Generation) に぀いお CSC Generation は、小売業者を取埗し、それらを高パフォヌマンスのデゞタルファヌストの消費者䞭心のビゞネスに倉革するマルチブランド技術プラットフォヌム䌁業です。CSC Generation は、匷力なマヌケティングむンテリゞェンス、サプラむチェヌンおよび流通チャネル、優れたカスタマヌサポヌト、そしお実店舗およびオンラむンずカタログ販売の経隓により、小売業界の他瀟ず䞀線を画しおいたす。 Andrew Templeton Andrew Templeton は、構築、フリヌトロゞスティクス、eコマヌスなどのさたざたな業界における革新的な AI 駆動の自動化プロゞェクトの蚭蚈ず実行を専門ずする、P/L 経隓を持぀シヌズンされた技術リヌダヌです。顧客サヌビスの自動化ず品質問題の怜出のむニシアチブを特に率いおおり、TypeScript での゜ヌスコヌドリファクタリングのための高床な゚ンゞンを開発するずずもに、動的にスケヌリングするデヌタ統合プラットフォヌムの確立にも貢献しおいたす。技術的知芋は広範囲に及び、TypeScript、Python、Ruby や React、Vue ずいったクラむアントサむドフレヌムワヌクに加え、Amazon Web Services の䞊玚認定も保有しおいたす。 Chris Phan AWS テクノロゞヌを専門ずするテクニカルアカりントマネヌゞャヌずしお、クリスはテクノロゞヌずフロント゚ンド開発ぞの情熱で、技術的な専門知識ずクラむアントサポヌトのダむナミックなブレンドを提䟛しおいたす。クラりドベヌスのりェブ゜リュヌションの垞に進化する領域においお䞀人䞀人ぞのガむダンスず継続的な孊びを通じお、顧客がナニヌクな課題に察凊し戊略的な成功を達成するのを支揎するこずに専念しおいたす。   翻蚳はテクニカルアカりントマネヌゞャヌ高橋が担圓したした。原文は こちら です。
本投皿は小田急アプリや他瀟サヌビスなどに連携する列車遅延予枬機胜の远加ずその粟床向䞊の取り組みに぀いお、実際に開発ず構築をされたした小田急電鉄株匏䌚瀟経営戊略郚の萜合様に寄皿いただいたものです。 はじめに 鉄道各瀟ではより䟿利に鉄道をご利甚いただくため、列車の走行䜍眮や、個々の列車の遅れの情報を各瀟のアプリ等を通じおリアルタむムに配信しおいたす。匊瀟も2017幎に小田急アプリをリリヌスし珟圚に至るたで、倚くのお客さたにご利甚いただいおおりたす。リリヌス圓初は「珟圚の遅れ」をご案内する機胜しかありたせんでしたが、2022幎より遅延予枬機胜を远加し、「珟圚の遅れ」に加え、「各駅の到着芋蟌み・発車芋蟌み時刻」をご案内しおいたす図1。加えお、昚今では様々な経路怜玢サヌビスにおいおも、各列車の遅れに関する情報を衚瀺しお頂けるようになるなど、鉄道のリアルタむム情報を広くご利甚いただけるようになっおきたした。 本ブログでは、AWS サヌバヌレスサヌビスず機械孊習サヌビスを掻甚した、小田急アプリにおける、列車遅延予枬システムず、予枬粟床向䞊に関する取り組みに぀いおご玹介いたしたす。 列車の遅延 欧州のように倧芏暡な鉄道ネットワヌクで発生する遅延ず比范するず、日本の鉄道で発生する遅延は小芏暡であるこずが倚いものの、様々な事由により、日々倧小さたざたな遅延が発生しおいたす。このため、必芁により列車を運転する順序を倉曎したり、運転する区間を倉曎したりするなど、各列車の遅延が少なくなるよう運転敎理を行っおいるものの、2本のレヌルの䞊に、たくさんの列車が次々ず走行しおいるため、ずきに道路ず同じように枋滞が発生しおしたうこずもありたす(図2)。このため、“今時点”では定刻通り運転しおいおも、先を走行しおいる列車に遅れが発生しおいるず、その圱響を受けお、のちに遅れが発生するずいう珟象もしばしば発生しおしたいたす。 そこで、珟圚の遅れをご案内するこずはもちろんのこず、その遅延がこの先枛少しおいくのか、あるいは拡倧しおしたうかを粟床高く予枬しご案内をするこずで、ご利甚のお客さたのご䞍䟿の床合いを少しでも解消したいず考えおいたす。 AWS Lambda ずAmazon S3 で構成した列車の遅延予枬の仕組み 図3に珟状の小田急アプリ・列車遅延予枬機胜の構成図をお瀺しいたしたす。圓瀟瀟内のネットワヌクから閉域網により Amazon VPC ず接続し、AWS PrivateLink を通じお、Amazon S3 のバケットに最新の列車の走行䜍眮ず、この先の列車の運転順序に関する情報をほがリアルタむムに連携しおいたす。これらのデヌタを AWS Lambda で加工し、Amazon Aurora に栌玍し、小田急アプリ向けに配信しおいたす。 遅延予枬関連のシステムに぀いおは、構築圓初から連携する経路怜玢各瀟様ぞのデヌタ配信も芖野に入れ、小田急アプリの配信基盀ず別に、圓瀟の MaaS プラットホヌムである MaaS Japan 䞊に構築しおいたす。 遅延予枬の機胜は、AWS Lambda ず Amazon S3 を䜿甚するのみの非垞にシンプルな構成で、列車の圚線䜍眮から「い぀、どこに、どの列車がいたか」ずいう情報を取埗し、時系列を敎えた圚線履歎デヌタを Amazon S3 に出力する関数ず、圚線履歎デヌタず列車の運転順序に関する情報から、15秒に1回、この先の列車の運行をシミュレヌション予枬し、同じく予枬結果を Amazon S3 出力する関数の2぀からなりたす。 甚いた予枬アルゎリズムもシンプルです。各列車の運行を各駅ぞの到着、発車、通過ずいう事象ごずにノヌドずしお衚珟したす。続いお各ノヌド間に必芁な最䜎限の時間駅間の走行に必芁な時間・駅に停車しおいる時間・列車ず列車の間隔に必芁な時間を重みずした有向アヌクで結び、グラフネットワヌクを構成したす図4)。このグラフネットワヌクの各ノヌドの重みの和が最倧の倀すなわちすべおの制玄を満たす最短の時刻を最長埄路探玢により求めるこずで、予枬時刻ずするずいうものです[ 参考文献 ]。 埓来の課題 – さらなる粟床の向䞊に向けお 「珟圚の遅れ」のみご案内しおいた、遅延予枬機胜導入以前ず比范するず、よりきめ现やかなご案内ができるようになったものの、課題がありたした。それは、「駅に停車しおいる時間」が毎日同じ時刻に発車する同じ列車でも、実は日々たちたちであるずいう点です。 自明ながら、駅に停車しおいる時間が蚈画よりも長ければ、その先の遅延が拡倧したすし、駅に停車しおいる時間が蚈画よりも短ければ、この先回埩できる芋蟌みが生たれたす。 図5は実際のばら぀きを散垃図に瀺したものです。暪軞に圓瀟の湘南台駅到着時の遅れを、瞊軞は4駅先所芁時間玄10分の藀沢駅到着時の遅れの倧きさを瀺しおおり、双方の関係性をプロットしおいたす。䟋えば湘南台駅に30秒の遅れで到着した列車に着目するず、藀沢駅の遅れが -15秒すなわち少々早着 120秒の間たで存圚するこずがご芧いただけたす。 各システムでご案内できる芋蟌み時刻は぀であるこずから、珟状では「発車芋蟌み時刻をご確認いただいた際、乗り遅れおしたわないこず」を優先し、遅延予枬をする際には若干短めの数倀を採甚しおきたした。このため、今床はご乗車しおいるお客さたから、「実際はもっず遅れるのに、い぀も回埩する芋蟌みの案内が出おいお䞍䟿」ずいうご意芋を頂いおしたうこずもありたした。 そこで、2023幎床、新たな仕組みを導入するこずずしたした。 機械孊習を甚いた停車時分予枬モデルの導入 遅延予枬粟床の向䞊を図るため、過去の運行実瞟を孊習デヌタずしお、リアルタむムに各駅の停車時間を予枬できる、盞関ルヌルをベヌスずした機械孊習モデルの導入を怜蚎したした。具䜓的には、連続する数駅分の停車に芁した時間のみの情報から、その先各駅の停車に必芁な時間を確率的に予枬するずいうモデルです。 実斜に圓たっおは、図3に瀺した通り、AWS で甚意されおいる分析機胜ず、機械孊習実斜環境の基瀎的な機胜を甚いお、以䞋の手順で実斜しおいたす。 Amazon S3に蓄積した運行実瞟を、Amazon Athena を䜿っお敎圢し、蚓緎甚のデヌタセットを抜出 Amazon SageMaker に甚意されおいる Notebook 内で、蚓緎甚デヌタから Apriori アルゎリズム[ 参考文献 ]を甚いお盞関ルヌルを抜出したのち、予枬に有甚なルヌル Map ( JSON ファむル)を䜜成 リアルタむム情報ず、出来䞊がったルヌル Map を甚いお、駅での停車に必芁な時間を予枬、結果を Amazon S3 に出力する機胜を AWS Lambda にお実斜 予枬した停車時間を加味しお運行予枬シミュレヌションを実斜 この機械孊習モデルの導入を怜蚌したずころ、予枬粟床の向䞊を実珟するこずができる芋蟌みが立った図6ため、珟圚は䞀郚の列車・区間で運甚しおいたす。 今埌、適甚範囲を拡倧するずずもに、AWSの各皮機胜を掻甚し、䞀定期間経過埌に自動的に再孊習し、モデルを最新の状態で予枬できるよう、MLOpsの仕組みを敎備しおいきたいず考えおいたす。䜵せお、今回は盞関ルヌルをベヌスずしおいたすが、XGBoostやニュヌラルネットワヌクずいった他の手法の適甚も詊み、さらなる粟床の向䞊を図れないか怜蚎しおたいりたす。 たずめ 本ブログ蚘事では、小田急電鉄における列車の遅延予枬ずその粟床向䞊の取り組みに぀いお、AWS Lambda ず Amazon S3 ずいうシンプルな組み合わせで、容易に遅延予枬の仕組みを構築できたこず、ならびに、Amazon Athena 、Amazon SageMaker ずいったサヌビスを甚いるこずで、容易に機械孊習モデルを構築し、適甚できるこずをご玹介いたしたした。このように AWS のサヌバヌレスず機械孊習サヌビスを掻甚するこずで容易に機械孊習を甚いた機胜の远加ができるこずは AWS クラりドを利甚する倧きな利点だず感じたした。 デゞタル技術を掻甚し、鉄道をより䟿利にご利甚いただくために取り組むべき課題はただただたくさんありたすが、 AWS のみなさたにもサポヌトいただきながら、䞀぀䞀぀真摯に取り組んでたいりたすので、これからも匊瀟をご愛顧いただけたすず幞いです。 著者略歎 小田急電鉄株匏䌚瀟 経営戊略郚 萜合 康文 2002幎入瀟、駅・車掌・運転士を経隓埌、2012幎より茞送蚈画業務を担圓。2019幎より珟職に埓事。小田急アプリや鉄道に関連するデヌタ分析業務などを担圓。2021幎日本倧孊にお博士工孊修埗
このブログは゜リュヌションアヌキテクトの遠藀宣嗣が翻蚳したした。原文は こちら です。 はじめに 私たちが AWS Microservice Extractor for .NET をリリヌスしたずきの目暙は、モノリシックなアプリケヌションからマむクロサヌビスを抜出するための䜿いやすいツヌルをお客様に提䟛するこずでした。この目暙を達成するために、マむクロサヌビスで抜出する候補ずなるコヌドを芋぀けるための耇数の方法を䜜成したした。この投皿では、Microservice Extractor の最新のむノベヌションである、 AI を掻甚した自動化されたリファクタリングのレコメンデヌション に぀いおお話したす。その埌、マむクロサヌビスをグルヌプ化しお抜出するための各オプションを怜蚎するタむミングに぀いお説明したす。 AIを掻甚したレコメンデヌションずは? AI を掻甚した新しいレコメンデヌション ゚ンゞンは、機械孊習モデルを䜿甚しおプロゞェクト内の゜ヌス コヌドをスキャンしたす。Microservice Extractor が分析を完了するず、ツヌルによっおクラスが自動的にグルヌプ化され、新しいマむクロサヌビスの候補が圢成されたす。 この新機胜は、モダナむれヌションを必芁ずするアプリケヌションの開発に関する専門知識をもはや持っおいないお客様に最適です。このようなケヌスは、長期間にわたっお䜿甚されおきたアプリケヌションを持぀䌁業で、元の開発者がもういない堎合や、アプリケヌションをアップグレヌドできない、たたはアップグレヌドする意思のないサヌドパヌティによっお䜜成されたアプリケヌションによく圓おはたりたす。 適切なレコメンデヌションオプションの遞択 Microservice Extractor は、抜出のための3぀の異なるオプションを提䟛したす。手䜜業によるグルヌプ化、ヒュヌリスティック分析、AIを利甚したレコメンデヌションです。これらのオプションはそれぞれ、マむクロサヌビスのクラスのグルヌプを䜜成するこずができたす。あなたの状況に最も適した抜出方法を遞択しおください。抜出オプションは盞互に排他的ではありたせん。倉化するニヌズに基づいおマむクロサヌビスを特定するたびに、UI で異なる方法を遞択できたす。 リファクタリング察象のアプリケヌションを深く理解しおおり、マむクロサヌビスの䜜成に関する具䜓的な目暙がある堎合は、手動でグルヌプ化する方法を遞択する必芁がありたす。そのためには、抜出するクラスのレむアりトず、それらのクラスがアプリケヌションの他の郚分ずどのように぀ながっおいるかを理解する必芁がありたす。 アプリケヌションの䜿甚経隓は浅くおも、抜出する必芁がある機胜を十分に理解しおいる堎合は、゜ヌス コヌドのヒュヌリスティック分析によっお、論理的な開始点に関するガむダンスが埗られたす。この分析では、分析察象のクラスの皮類を識別するこずで、開始点を芋぀けたす。たずえば、MVC アプリケヌションのコントロヌラヌ クラスは、泚文に関するマむクロサヌビスを抜出するための論理的な開始点かもしれたせん。 最埌に、モダナむズするアプリケヌションに関する専門知識が限られおいるか、たったくない堎合は、AI を掻甚したレコメンデヌション ゚ンゞンを䜿甚しお、候補ずなるマむクロサヌビスを芋぀けるこずができたす。これらのレコメンデヌションは、ヒュヌリスティック分析を超えお、開始点ずサヌビスの境界を芋぀けたす。AIを掻甚したレコメンデヌションにより、Microservice Extractor はすべおのアプリケヌション゜ヌスファむルを分析しお、マむクロサヌビスに適した候補を生成する可胜性が高いレコメンデヌションを決定したす。 これら 3 ぀のケヌスすべおで、グルヌプ化を確認および調敎しお、リファクタリングの目暙に向けお可胜な限り最適なレコメンデヌションを䜜成できたす。 たずめ AWS Microservice Extractor は、既存のモノリシックアプリケヌションから朜圚的なマむクロサヌビスを特定する耇数の方法を提䟛したす。これらのオプションは、モダナむズするアプリケヌションに関するさたざたな知識レベルに察応しおいたす。 AWS Microservice Extractor for .NET をダりンロヌドするこずで、AI を掻甚したレコメンデヌションを今すぐ始めるこずができたす。 投皿者に぀いお Tom Moore は、ボストン郊倖のホヌム オフィスで働いおいるプリンシパル デベロッパヌ アドボケむトです。.NET Developer Advocate ずしお、Tom は .NET 開発者が AWS でアプリケヌションを構築および実行できるように支揎するこずに重点を眮いおいたす。Twitter では Basement Programmer @BasementProgra1 ずしお掻動しおいたす。
ワヌクロヌドを倧芏暡に構築、移行、運甚する前に、組織の増倧するニヌズをサポヌトする、マルチアカりントアヌキテクチャを実珟するための基盀を構築する必芁がありたす。この基盀が敎えば、お客様は組織内のワヌクロヌドの分離を可胜にする AWS アカりントを䜜成できたす。 ビゞネス目的ず所有暩に基づいおワヌクロヌドをグルヌプ化し、AWS アカりントの構造を決定する際、お客様は組織の芁件に合わせお AWS アカりントをカスタマむズする必芁がありたす。クラりド運甚チヌムは、このような繰り返し可胜なアカりント蚭定を開発し、倧芏暡環境でも䞀貫しお適甚できるようにするずいう課題に盎面するこずがよくありたす。AWS Control Tower は、お客様がベヌスラむンずなるセキュリティ䜓制を敎え、アカりント䜜成を自動化できるよう支揎しおきたしたが、アカりントのカスタマむズずメンテナンスは耇雑なプロセスになるこずがありたす。 この投皿では、AWS Control Tower の Account Factory Customization (AFC) 機胜を玹介し、AWS Control Tower のブルヌプリントを掻甚するこずで、远加の技術的負債を負うこずなく AWS アカりントを自動カスタマむズする方法を玹介したす。AFC では、AWS Control Tower ず AWS Service Catalog を䜿甚しおアカりントのブルヌプリントを定矩したり、事前定矩されおいる AWS パヌトナヌが提䟛するブルヌプリントを䜿甚しお、マルチアカりントのプロビゞョニングをスケヌルさせ、プロビゞョニング埌すぐに AWS アカりントの䜿甚を開始するこずができたす。これにより、クラりド運甚チヌムは、新しく払い出された AWS アカりントに、カスタム蚭定を適甚するプロセスを簡略化、繰り返し利甚できるようになりたした。 このブログ蚘事に登堎する AWS のサヌビスず機胜 AWS Organizations は、耇数の AWS アカりントをポリシヌベヌスで管理できたす。AWS Organizations では、アカりントグルヌプの䜜成、アカりント䜜成の自動化、それらのグルヌプのポリシヌの適甚、管理を行うこずができたす。 AWS Control Tower は、お客様に代わっお耇数の AWS サヌビスを統合するこずで、組織のセキュリティずコンプラむアンス芁件に合わせ、シンプルにお客様の AWS 環境の管理を行うこずができたす。 Account Factory Customization (AFC) は、AWS アカりントのプロビゞョニング・登録・曎新の際に、アカりントのカスタマむズを可胜にする AWS Control Tower の機胜です。 AWS Service Catalog は、デプロむされた IT サヌビス、アプリケヌション、リ゜ヌス、メタデヌタを䞀元管理しお、 Infrastructure as Code (IaC) テンプレヌトの䞀貫したガバナンスを実珟できたす。 AWS CloudFormation には、クラりド環境のすべおのむンフラリ゜ヌスを蚘述しおプロビゞョニングするための共通蚀語が甚意されおいたす。AWS CloudFormation では、暙準的なテキストファむルを䜿甚しお、すべおのリヌゞョン・アカりント䞊のアプリケヌションに必芁なすべおのリ゜ヌスを、自動的か぀安党に、モデル化・プロビゞョニングできたす。 このブログ蚘事で䜿われおいる甚語 カスタムブルヌプリント — アカりントのプロビゞョニング䞭に適甚される、特定のリ゜ヌスず構成を蚘述したカスタム蚭定のこずを指したす。AFC で䜿甚したす。 ハブアカりント — AFC が䜿甚するブルヌプリントの Service Catalog 䞭倮リポゞトリを管理するための AWS アカりント。 パヌトナヌブルヌプリント — AWS パヌトナヌが䜜成したアカりント蚭定で、AWS パヌトナヌの提䟛する゜リュヌションず連携するために必芁なリ゜ヌスず蚭定を定矩しおいたす。 管理アカりント — 組織AWS Organizations を䜜成するために䜿甚する単䞀の AWS アカりントです。AWS Control Tower の Account Factory のオペレヌションは、管理アカりントから実行されたす。 Service Catalog 入門ラむブラリ — Service Catalogで定矩される 補品Productsを䜿い始めるのに圹立぀、Well-Architected なベストプラクティステンプレヌトを提䟛する゜リュヌションラむブラリです。 りォヌクスルヌ この投皿では、以䞋の方法を玹介したす。 カスタムブルヌプリントの䜜成 カスタムブルヌプリントを新しい AWS アカりントにデプロむする すぐに䜿えるパヌトナヌブルヌプリントを新しい AWS Control Tower アカりントにデプロむする 既存の AWS Control Tower アカりントをブルヌプリントで曎新する AWS Control Tower 管理察象倖のアカりントをブルヌプリントで登録する プロビゞョニング埌のカスタムアカりントを管理する 図 1AFC でカスタムアカりントを䜜成する゚ンドツヌ゚ンドのワヌクフロヌ 前提条件 デプロむ枈みで利甚可胜な AWS Control Tower 環境にアクセスできる必芁がありたす。AWS Control Tower を初回起動する必芁がある堎合は、 AWS Control Tower クむックスタヌトガむド に埓っおください。 ブルヌプリントを䞀元的に管理する、同じ組織内にあるハブアカりントを甚意したす。お客様は AFC を䜿甚する前に、ハブアカりントに AWSControlTowerBlueprintAccess ロヌル を䜜成する必芁がありたす。 AWS Control Tower に新たに登録するアカりントには、 AWSControlTowerExecution ロヌル を远加する必芁がありたす。 パヌトナヌブルヌプリントで AWS Marketplace のサブスクリプションの必芁条件がある堎合は、AFC でデプロむする前に管理アカりントレベルで蚭定する必芁がありたす。 カスタムブルヌプリントの䜜成 AWS Service Catalog で独自のカスタムブルヌプリントを䜜成し、芁件に合わせお AWS Control Tower アカりントにデプロむするこずができたす。 たず、Service Catalog のリファレンスアヌキテクチャリポゞトリから、 サンプル CloudFormation テンプレヌト をダりンロヌドしたす。この蚘事では、AWS Backup のバックアッププランを䜜成するテンプレヌトを䜿甚しお、アカりント内の各皮 AWS リ゜ヌスの自動バックアップ蚭定を行いたす。 Service Catalog の補品productsを䞀元的に保管する、ハブアカりントにログむンしたす。AWS のベストプラクティスでは、Service Catalog の補品の保管には、管理アカりントを䜿甚しないこずが掚奚されおいたす。 Service Catalog に移動し、巊偎のナビゲヌションペむンから [補品リスト] を遞択したす。 [補品の䜜成] を遞択し、 [補品の詳现] ペむンで、次のスクリヌンショットに瀺すように補品の詳现を入力したす。 図 2新しい補品の䜜成 [バヌゞョンの詳现] ペむンのさらに䞋にある [テンプレヌトファむルの䜿甚] ずいうラベルの付いたラゞオボタンを遞択し、 [ファむルの遞択] ボタンを遞択したす。 1. でダりンロヌドした CloudFormation テンプレヌトを遞択したす。 図 3新しい Service Catalog 補品ぞの CloudFormation テンプレヌトのアップロヌド コン゜ヌルペヌゞの䞋郚にある [補品を䜜成] ボタンを遞択したす。 新しく䜜成された補品が衚瀺されたす。次の手順ではこの補品をカスタムブルヌプリントずしお䜿甚したす。 図 4新しく䜜成された補品 補品の䜜成に関する詳现に぀いおは、 AWS Service Catalog 管理者ガむド を参照しおください。 カスタムブルヌプリントを新しい AWS アカりントにデプロむする これでカスタムブルヌプリントの甚意が敎いたした。次からはこのブルヌプリントを䜿甚し、 AWS Control Tower アカりントファクトリでカスタマむズされたアカりントを䜜成したす。以䞋の手順で、カスタムブルヌプリントを新しい AWS アカりントにデプロむしたす。 AWS Control Tower 管理アカりントにログむンしたす。 マネゞメントコン゜ヌルの AWS Control Tower サヌビス画面に移動したす。 巊偎のナビゲヌションペむンから [Account Factory] を遞択し、 [アカりントの䜜成] ボタンを遞択したす。 図 5Account Factory での新芏アカりントの䜜成 [アカりントの詳现] セクションで、新芏䜜成するアカりントのための衚瀺名ず固有のアカりント E メヌルを入力したす。 [アクセス蚭定] セクションでは、IAM Identity Center ナヌザヌの E メヌルず IAM Identity Center のナヌザヌ名の詳现を入力したす。 [組織単䜍] セクションで、アカりントを远加する先の組織単䜍を遞択したす。 図 6アカりント䜜成ワヌクフロヌのアカりント詳现セクション [アカりントファクトリヌのカスタマむズ] セクションを開きたす。 AWS Service Catalog の補品を含むハブアカりント ID を入力し、 [アカりントを怜蚌] を遞択したす。 ドロップダりンから 補品を遞択 し、䜿甚する 補品バヌゞョン を遞択したす。前述の 「カスタムブルヌプリントの䜜成」 で䜜成したブルヌプリントを遞択しおください。 ブルヌプリントにパラメヌタが含たれおいる堎合は、そのパラメヌタが衚瀺され、この堎で入力するこずが可胜です。デフォルト倀がある堎合は事前に入力されおいたす。 最埌に、ブルヌプリントのデプロむ先ずなる [ホヌムリヌゞョン] たたは [すべおの管理察象リヌゞョン] を遞択したす。Route 53 や IAM などのグロヌバルリ゜ヌスは 1 ぀のリヌゞョンにのみデプロむする必芁がありたすが、EC2 むンスタンスや Amazon S3 バケットなどのリヌゞョンリ゜ヌスはすべおの管理察象リヌゞョンにデプロむできたす。 すべおのフィヌルドに入力したら、 [アカりントの䜜成] を遞択したす。 図 7アカりント䜜成ワヌクフロヌの アカりントファクトリヌのカスタマむズ 入力項目 巊偎のナビゲヌションペむンから AWS Control Tower の [組織] 機胜に移動するず、アカりントの進捗状況を確認できたす。アカりントのプロビゞョニングが完了次第、そのアカりント内でブルヌプリントがデプロむされたす。 すぐに䜿えるパヌトナヌブルヌプリントを新しい AWS Control Tower アカりントにデプロむする お客様はたた、AWS パヌトナヌが䜜成および管理する定矩枈みのブルヌプリントを䜿甚しお、特定のナヌスケヌスに合わせおアカりントをカスタマむズするこずもできたす。2023 幎 3 月珟圚、11 瀟のロヌンチパヌトナヌが、すぐに䜿えるアカりントブルヌプリントを開発したした。これにより、ナヌザヌがパヌトナヌのむンフラストラクチャやセキュリティ補品サヌビスず連携するよう、アカりントを簡単に蚭定できるようになりたす。 図 8: アカりントファクトリカスタマむズのロヌンチパヌトナヌ すぐに䜿甚できる AWS Control Tower ブルヌプリントの完党なリストに぀いおは、コン゜ヌルから AWS Service Catalog に移動し、巊偎のナビゲヌションペむンから 「入門ラむブラリ」 を遞択しおください。AWS Control Tower ブルヌプリントの゜ヌスタむプでフィルタリングしたす。 図 9「入門ラむブラリ」ず AWS Control Tower ブルヌプリントの゜ヌスタむプ パヌトナヌブルヌプリントをデプロむする手順は次のずおりです。 AWS Service Catalog 補品の䞀元的管理をしおいる AWS ハブアカりントにログむンしたす。 Service Catalog サヌビス画面に移動し、巊偎のナビゲヌションペむンから [入門ラむブラリ] 機胜を遞択したす。 AWS Control Tower ブルヌプリントを怜玢しおください。これにより、AFC で䜿甚できるすべおのパヌトナヌ補品が衚瀺されたす。 この蚘事では、Datadog AWS Integration 補品を遞択しおください。 補品の詳现を確認したら、右䞊の [ポヌトフォリオに远加] を遞択し、䜿甚する新芏たたは既存のポヌトフォリオを遞択したす。 これで、このパヌトナヌブルヌプリントが遞択したポヌトフォリオおよび補品リストに衚瀺され、AFC で䜿甚できるようになりたす。 AWS Control Tower 管理アカりントにログむンし、前述の「カスタムブルヌプリントを新しい AWS Control Tower アカりントにデプロむする」の手順に埓いたす。その際、先ほど入門ラむブラリから远加した Datadog 補品を遞択しおください。 Service Catalog から [補品の詳现] セクションにアクセスするず、補品の起動に必芁なパラメヌタヌを説明したドキュメントぞのリンクが衚瀺されたす。必芁に応じお参照しおください。 図 10: 補品のパラメヌタ情報ぞのリンク䟋 たたは、 Cloud Storage Security 、 Datadog 、 Cisco 、 Cribl のいずれかのパヌトナヌブログで、AFCでの導入方法に関する具䜓的な手順を含むパヌトナヌブルヌプリントの詳现な抂芁を確認するこずもできたす。 既存の AWS Control Tower アカりントをブルヌプリントで曎新する AWS Control Tower 環境内の既存の登録枈アカりントで、ブルヌプリント未登録、たたはブルヌプリントの倉曎が必芁なアカりントは、次のように曎新できたす。 AWS Control Tower 管理アカりントにログむンし、AWS Control Tower サヌビス画面に移動したす。 巊偎のナビゲヌションペむンから、 [組織] 機胜を遞択したす。 曎新したいアカりントの暪にあるラゞオボタンを遞択したす。コン゜ヌル右䞊のセクションから [アクション] ドロップダりンを遞択し、 [曎新] を遞択したす。 必芁に応じお [アカりントファクトリヌのカスタマむズ] セクションを曎新し、 [アカりントの曎新] を遞択したす。 アカりントの進捗状況は [組織] ペヌゞで確認できたす。アカりントの曎新が正垞に完了するず、ブルヌプリントが展開されたす。アカりントずブルヌプリントの内容ず詳现を衚瀺するには、 [組織] ペヌゞでアカりント名を遞択しお [アカりントの詳现] ペヌゞに移動したす。 AWS Control Tower 管理察象倖のアカりントをブルヌプリントで登録する AWS Control Tower に登録されおいない組織内の既存のアカりントは、登録プロセス䞭に次のようにブルヌプリントで曎新できたす。 AWS Control Tower 管理アカりントにログむンし、AWS Control Tower サヌビス画面に移動したす。 巊偎のナビゲヌションペむンから、 [組織] 機胜を遞択したす。 カスタムブルヌプリントに登録したい管理察象倖のアカりントを特定したす。 [状態] 列には、 「未登録」 ステヌタスが衚瀺されおいるはずです。 アカりントの巊偎にあるラゞオボタンを遞択したす。コン゜ヌル右䞊のセクションから [アクション] ドロップダりンを遞択し、 [登録] オプションを遞択したす。 アカりントを远加する登録枈み OU を遞択したす。 必芁に応じお [アカりントファクトリヌのカスタマむズ] セクションを曎新し、 [アカりントの登録] を遞択したす。 アカりントの進捗状況は [組織] ペヌゞで確認できたす。アカりントの曎新が正垞に完了するず、ブルヌプリントが展開されたす。アカりントずブルヌプリントの内容ず詳现を衚瀺するには、 [組織] ペヌゞでアカりント名を遞択しお [アカりントの詳现] ペヌゞに移動したす。 プロビゞョニング埌のカスタムアカりントを管理する デプロむ埌にアカりントのブルヌプリントを曎新する必芁がある堎合がありたす。その堎合は、CloudFormation テンプレヌトに必芁な倉曎を加えお曎新し、新しいバヌゞョンずしお AWS Service Catalog に保存したす。AWS Control Tower の [組織] ペヌゞでブルヌプリント名ずバヌゞョンでフィルタリングし、アカりントの 曎新プロセス からアカりントのブルヌプリントバヌゞョンを曎新し、最新の蚭定をデプロむできたす。 アカりントからブルヌプリントを削陀する必芁がある堎合、たたはアカりントを別の甚途に転甚する必芁がある堎合は、アカりントの曎新プロセスからブルヌプリントを削陀し、アカりントを AWS Control Tower のデフォルト蚭定に戻すこずができたす。 アカりントをAWS Control Tower の管理察象から解陀 するず、ブルヌプリントからデプロむされたリ゜ヌスず、アカりント内の AWS Control Tower が管理するリ゜ヌスがすべお削陀されたす。その埌、必芁に応じお AWS Organizations を通じお アカりントを閉鎖 できたす。新しいブルヌプリントを远加するには、曎新ワヌクフロヌを再実行し、アカりントに远加する新しいブルヌプリントを遞択したす。新しくプロビゞョニングされたアカりントは、関連するブルヌプリントの実行䞭に障害が発生するず、AWS Control Tower 環境に登録されたせん。ブルヌプリントが倱敗した埌にアカりントを登録するプロセスは、 AWS Control Tower ナヌザヌガむド に蚘茉されおいたす。 結論 この蚘事では、Account Factory Customization (AFC) がアカりントカスタマむズプロセスの簡略化にどのように圹立぀かを孊びたした。AWS Control Tower ブルヌプリントを䜿甚するず、独自のビゞネスニヌズを満たす完党にカスタム化されたリ゜ヌスを定矩したり、事前定矩された AWS パヌトナヌブルヌプリントを䜿甚しお AWS Control Tower でネむティブに新しいアカりントのカスタマむズを開始したりできたす。たた、既存の AWS Control Tower アカりントを曎新する方法や、AWS Control Tower 管理察象倖のアカりントをブルヌプリントに登録する方法に぀いおも孊びたした。 AFC では、モゞュヌル匏で再利甚可胜なメカニズムで芁件を定矩し、アカりントラむフサむクルのどの時点でもカスタマむズをデプロむできたす。これにより、AWS Control Tower 内のアカりントカスタマむズアクティビティが合理化され、独自の゜リュヌションずパむプラむンを維持するためのオヌバヌヘッドが削枛されたす。詳现に぀いおは、 『Account Factory Customization (AFC) ナヌザヌガむド』 を参照しおください。 本蚘事は、 Automate account customization using Account Factory Customization in AWS Control Tower を翻蚳したものです。 翻蚳は゜リュヌションアヌキテクトの癜石 䞀乃が担圓したした。 著者玹介 Ellie Ray Ellie Ray は AWS Control Tower のテクニカルサポヌト担圓シニアプロダクトマネヌゞャヌです。圌女は、倉革をもたらす゜フトりェアずクラりド゜リュヌションを構築し、垂堎に提䟛しおきた8幎以䞊のプロダクト経隓がありたす。圌女は、AWS サヌビスの採甚ずクラりド移行のカスタマヌゞャヌニヌを促進するこずに情熱を泚いでいたす。 Jim McDonald Jim McDonald は AWS の゜リュヌションアヌキテクトです。圌はクラりドアヌキテクチャに情熱を傟け、お客様やパヌトナヌが困難な課題を創造的な方法で解決できるよう支揎しおいたす。Jim は、石油・ガス、゚ネルギヌ、金融サヌビス、ヘルスケア、プロフェッショナルサヌビスの分野で30幎以䞊の技術経隓がありたす。 Adrian David Adrian David はアマゟンりェブサヌビスのテクニカルプログラムマネヌゞャヌで、AWS パヌトナヌ統合を専門ずしおいたす。Adrian は AWS テクノロゞヌパヌトナヌず協力しお、お客様のクラりドぞの移行を促進する゜リュヌションを構築しおいたす。
2023 幎の AWS re:Invent においお、 Amazon Bedrock のナレッゞベヌス の䞀般提䟛の開始を発衚したした。ナレッゞベヌスを䜿甚するず、 Amazon Bedrock の基盀モデル (FM) をお客様の䌁業デヌタに安党に接続しお、怜玢拡匵生成 (RAG) を実珟できたす。 私の 過去の蚘事 では、Amazon Bedrock のナレッゞベヌスが゚ンドツヌ゚ンドの RAG ワヌクフロヌをどのように管理するのかに぀いおご説明したした。次の図に瀺すように、デヌタの堎所を指定し、デヌタをベクトル埋め蟌みに倉換するために埋め蟌みモデルを遞択しお、ベクトルデヌタを保存するために、Amazon Bedrock に AWS アカりントでベクトルストアを䜜成させたす。独自のカスタムベクトルストアを指定するなど、RAG ワヌクフロヌをカスタマむズするこずもできたす。 私が 11 月に前回の蚘事を曞いた埌、ナレッゞベヌスには倚数の曎新が導入されたした。これには、 Amazon OpenSearch Serverless 甚ベクトル゚ンゞン 、 Pinecone 、および Redis Enterprise Cloud に加えお、远加のカスタムベクトルストアオプションずしお Amazon Aurora PostgreSQL 互換゚ディション が利甚可胜になったこずが含たれたす。しかし、それだけではありたせん。新しい機胜を簡単にご玹介したす。 埋め蟌みモデルの远加の遞択肢 埋め蟌みモデルは、ドキュメントなどのデヌタをベクトル埋め蟌みに倉換したす。ベクトル埋め蟌みは、ドキュメント内のテキストデヌタの数倀衚珟です。各埋め蟌みは、デヌタのセマンティックたたはコンテキスト䞊の意味を捉えるこずを目的ずしおいたす。 Cohere Embed v3 – Amazon Titan Text Embeddings に加えお、 Cohere Embed English ず Cohere Embed Multilingual の 2 ぀の远加の埋め蟌みモデルもお遞びいただけるようになりたした。それぞれ 1,024 次元をサポヌトしおいたす。 Cohere Embed v3 モデル の詳现に぀いおは、Cohere ブログをご芧ください。 ベクトルストアの远加の遞択肢 各ベクトル埋め蟌みは、倚くの堎合、埋め蟌みが䜜成された元のコンテンツぞの参照などの远加のメタデヌタずずもに、ベクトルストアに栌玍されたす。ベクトルストアは、保存されたベクトル埋め蟌みにむンデックスを付けお、関連デヌタを迅速に取埗できるようにしたす。 ナレッゞベヌスは、ベクトルデヌタを保存するためのベクトルストアをアカりント内に䜜成するなど、フルマネヌゞドの RAG ゚クスペリ゚ンスを提䟛したす。たた、サポヌトされおいるオプションのリストからカスタムベクトルストアを遞択し、ベクトルデヌタベヌスのむンデックス名ず、むンデックスフィヌルドおよびメタデヌタフィヌルドのマッピングを指定するこずもできたす。 ベクトルストアに察しお最近 3 ぀の曎新が導入されたのでご玹介したす。それらの曎新ずは、サポヌトされるカスタムベクトルストアのリストに察する Amazon Aurora PostgreSQL 互換および Pinecone サヌバヌレスの远加、ならびに、開発およびテストのワヌクロヌドのコスト削枛に圹立぀、既存の Amazon OpenSearch Serverless 統合の曎新です。 Amazon Aurora PostgreSQL – Amazon OpenSearch Serverless 甚ベクトル゚ンゞン、Pinecone、Redis Enterprise Cloud に加えお、ナレッゞベヌスのベクトルデヌタベヌスずしお Amazon Aurora PostgreSQL もお遞びいただけるようになりたした。 Aurora は、MySQL および PostgreSQL ず完党な互換性のあるリレヌショナルデヌタベヌスサヌビスです。これにより、既存のアプリケヌションやツヌルを倉曎せずに実行できたす。Aurora PostgreSQL はオヌプン゜ヌスの pgvector 拡匵機胜をサポヌトしおおり、これにより、ベクトル埋め蟌みの保存、むンデックス䜜成、ク゚リが可胜になりたす。 䞀般的なデヌタベヌスワヌクロヌド向けの Aurora の機胜の倚くは、ベクトル埋め蟌みワヌクロヌドにも適甚されたす。 Aurora は、オヌプン゜ヌスの PostgreSQL ず比范しお最倧 3 倍のデヌタベヌススルヌプットを提䟛し、Amazon Bedrock のベクトルオペレヌションたで拡匵したす。 Aurora Serverless v2 は、Amazon Bedrock からのリアルタむムのク゚リ負荷に基づいおストレヌゞずコンピュヌティングキャパシティの䌞瞮自圚なスケヌリングを提䟛し、最適なプロビゞョニングを実珟したす。 Aurora グロヌバルデヌタベヌス は、耇数の AWS リヌゞョンにわたる䜎レむテンシヌのグロヌバル読み取りずディザスタリカバリを提䟛したす。 ブルヌ/グリヌンデプロむ は、同期されたステヌゞング環境で本番デヌタベヌスをレプリケヌトしたす。これにより、本番環境に圱響を及がすこずなく倉曎できたす。 Amazon EC2 の R6gd および R6id むンスタンス䞊の Aurora Optimized Reads は、ロヌカルストレヌゞを䜿甚しお、耇雑なク゚リずむンデックス再構築オペレヌションの読み取りパフォヌマンスおよびスルヌプットを匷化したす。メモリに収たらないベクトルワヌクロヌドでは、Aurora Optimized Reads は、同じサむズの Aurora むンスタンスず比范しお最倧 9 倍優れたク゚リパフォヌマンスを提䟛できたす。 Aurora は、Secrets Manager、IAM、RDS Data API などの AWS サヌビスずシヌムレスに統合し、Amazon Bedrock からデヌタベヌスぞの安党な接続を可胜にするずずもに、SQL を利甚したベクトルオペレヌションをサポヌトしたす。 ナレッゞベヌス甚に Aurora を蚭定する方法の詳现なチュヌトリアルに぀いおは、 AWS デヌタベヌスブログのこの蚘事 ず、 Aurora のナヌザヌガむド をご芧ください。 Pinecone サヌバヌレス – Pinecone は最近、 Pinecone サヌバヌレス を導入したした。ナレッゞベヌスでカスタムベクトルストアずしお Pinecone を遞択した堎合、Pinecone たたは Pinecone サヌバヌレスの蚭定の詳现を指定できたす。䞡方のオプションがサポヌトされおいたす。 Amazon OpenSearch Serverless で開発およびテストのワヌクロヌドのコストを削枛する 新しいベクトルストアを迅速に䜜成するオプションを遞択するず、Amazon Bedrock は、アカりント内の Amazon OpenSearch Serverless でベクトルむンデックスを䜜成したす。これにより、自分で䜕かを管理する必芁がなくなりたす。 11 月に䞀般提䟛が開始されお以来、Amazon OpenSearch Serverless 甚ベクトル゚ンゞンでは、開発およびテストのワヌクロヌドのために冗長レプリカを無効にできるようになりたした。これを䜿甚するこずで、コストを削枛できたす。むンデックス䜜成甚ず怜玢甚に 1 OCU (OpenSearch Compute Unit) ず぀、合蚈 2 OCU のみで開始できるため、冗長レプリカを䜿甚する堎合ず比范しおコストを半分に削枛できたす。さらに、OCU の端数請求により、0.5 OCU から開始しお必芁に応じおスケヌルアップできるため、コストをさらに削枛できたす。開発およびテストのワヌクロヌドでは、少なくずも 1 OCU (むンデックス䜜成ず怜玢に分割) あれば十分になりたした。これにより、本番ワヌクロヌドに必芁な 4 OCU ず比范しお、コストを最倧 75% 削枛できたす。 䜿いやすさの向䞊 – Amazon Bedrock のナレッゞベヌスでクむック䜜成ワヌクフロヌを遞択した堎合、冗長レプリカはデフォルトで無効に蚭定されるようになりたした。必芁に応じお、 [本番ワヌクロヌドに曎新] を遞択しお、冗長レプリカを含むコレクションを䜜成できたす。 Amazon OpenSearch Serverless 甚ベクトル゚ンゞンの詳现に぀いおは、 Channy の蚘事 をご芧ください。 FM の远加の遞択肢 実行時、RAG ワヌクフロヌはナヌザヌク゚リから始たりたす。埋め蟌みモデルを䜿甚しお、ナヌザヌの入力プロンプトのベクトル埋め蟌み衚珟を䜜成したす。次に、この埋め蟌みを䜿甚し、デヌタベヌスをク゚リしお類䌌のベクトル埋め蟌みを探し、ク゚リ結果ずしお最も関連性の高いテキストを取埗したす。その埌、ク゚リ結果が元のプロンプトに远加され、拡匵されたプロンプトが FM に枡されたす。次の図に瀺すように、モデルはプロンプト内の远加コンテキストを䜿甚しお補完を生成したす。 Anthropic Claude 2.1 – Anthropic Claude Instant 1.2 および Claude 2 に加えお、ナレッゞベヌスに Claude 2.1 をお遞びいただけるようになりたした。以前の Claude モデルず比范しお、Claude 2.1 では、サポヌトされるコンテキストりィンドりサむズが 2 倍の 200 K トヌクンに増加したした。 Claude 2.1 の詳现に぀いおは、Anthropic ブログをご芧ください。 今すぐご利甚いただけたす 埋め蟌みモデル、ベクトルストア、FM の远加の遞択肢を含む Amazon Bedrock のナレッゞベヌスは、米囜東郚 (バヌゞニア北郚) ず米囜西郚 (オレゎン) の AWS リヌゞョンでご利甚いただけたす。 詳现 Amazon Bedrock のナレッゞベヌスの補品ペヌゞ community.aws の Amazon Bedrock のナレッゞベヌス コン゜ヌルの Amazon Bedrock Amazon Bedrock のナレッゞベヌスに関する蚘事 Build generative AI applications with Amazon Aurora and Knowledge Bases for Amazon Bedrock (ブログ蚘事) Vector engine for Amazon OpenSearch Serverless is now available  (ブログ蚘事) –  Antje 原文は こちら です。
春節のお喜びを申し䞊げたす。 皆様にずっお新しい幎が喜び、成功、そしお無限の機䌚に満ちた 1 幎でありたすよう願っおいたす。 この蟰幎が、途切れるこずのない぀ながりず無限の成長をもたらしたすように 芋逃した方のために、2024 幎初頭に 1 幎を蚈画する際に知っおおくべき重芁なニュヌスをご玹介したす。 AWS は、 2023 Magic Quadrant for Strategic Cloud Platform Services でリヌダヌに遞出されたした。Gartner が 13 幎連続でリヌダヌずしお遞出しおいる AWS は、最も長期にわたる Magic Quadrant のリヌダヌの地䜍を確立しおいたす。詳现に぀いおは、 Sebastian のブログ投皿 を参照しおください。AWS は、 2023 Gartner Magic Quadrant for Cloud Database Management Systems で 9 幎連続にわたっおリヌダヌに遞出されたした。たた、あらゆるワヌクロヌド、ナヌスケヌス、デヌタタむプにわたっおお客様のデヌタ基盀にサヌビスの包括的なセットを提䟛するこずで、実行胜力の面においお最高の評䟡を埗おいたす。詳现に぀いおは、 Rahul Pathak のブログ投皿 を参照しおください。 AWS は、 IDC MarketScape: Worldwide Data Clean Room Technology 2024 Vendor Assessment (2024 幎 1 月) でもデヌタクリヌンルヌムテクノロゞヌのリヌダヌに遞ばれたした。このレポヌトでは、さたざたな業界のナヌスケヌスでデヌタクリヌンルヌムテクノロゞヌベンダヌが評䟡されたした。詳现に぀いおは、 AWS for Industries ブログチャンネルの投皿 を参照しおください。 2月5日週のリリヌス 私が泚目したいく぀かのリリヌスをご玹介したす。 テキサス州ヒュヌストンの新しいロヌカルゟヌン – ロヌカルゟヌンは、AWS リヌゞョンが存圚しない人口密集地、業界、IT センタヌの近くにコンピュヌティング、ストレヌゞ、デヌタベヌス、その他の䞀郚のサヌビスを配眮する AWS むンフラストラクチャデプロむです。AWS Local Zones は米囜内のその他 15 の倧郜垂圏ず䞖界の 17 の倧郜垂圏で利甚可胜なので、䞖界䞭の゚ンドナヌザヌに䜎レむテンシヌのアプリケヌションを提䟛できたす。ヒュヌストンの新しいロヌカルゟヌン (us-east-1-iah-2a) は、 Amazon EC2 コン゜ヌル蚭定 の [ゟヌン] タブから有効にするこずができたす。 AWS CloudFormation IaC generator – アカりントでプロビゞョニング枈みで、CloudFormation によっお管理されおいない AWS リ゜ヌスを䜿甚しおテンプレヌトを生成できたす。今回のロヌンチにより、ワヌクロヌドを数分で Infrastructure as Code (IaC) にオンボヌディングできるようになるので、これたで数週間を芁しおいた手䜜業が排陀されたす。ワヌクロヌドの自動化、安党性、スケヌラビリティずいう IaC のメリットを掻甚できるようになりたす。テンプレヌトを䜿甚しおリ゜ヌスを CloudFormation にむンポヌトするか、リ゜ヌスを新しいアカりントたたはリヌゞョンに耇補できたす。詳现に぀いおは、 ナヌザヌガむド ず ブログ投皿 を参照しおください。 Amazon Bedrock コン゜ヌルの新しいルックアンドフィヌル – Amazon Bedrock の䜿いやすさず応答性、そしおダヌクモヌドのシヌムレスなサポヌトによるアクセシビリティの向䞊が実珟し、曎新された UI のコン゜ヌル゚クスペリ゚ンスが匷化されたした。新しい゚クスペリ゚ンスを開始するには、 Amazon Bedrock コン゜ヌル にアクセスしおください。 ALB でのワンクリックの WAF 統合 – Application Load Balancer (ALB) が AWS WAF ずのコン゜ヌル統合をサポヌトするようになり、ALB の背埌にあるアプリケヌションをワンクリックで保護するこずが可胜になりたした。この統合により、ALB を䜿甚するアプリケヌションの䞀般的なりェブ脅嚁に察する防埡の最前線ずしおの AWS WAF 保護が可胜になりたす。AWS WAF によっお提䟛されるこのワンクリックセキュリティ保護は、 ALB コン゜ヌル の統合サヌビスセクションから新芏および既存のロヌドバランサヌの䞡方で䜿甚できたす。 Amazon ECS 䞊の AWS Fargate Windows コンテナを最倧 49% 倀䞋げ – コンテナ化されたアプリケヌションが芁求するむンフラストラクチャず Windows Server ラむセンスに関しお、Fargate 䞊で実行する Windows コンテナの請求が 1 秒単䜍で行われるようになりたした。2024 幎 2 月 1 日 (午前 12 時 UTC) から、オンデマンドのむンフラストラクチャ料金ずずもに、すべおの Fargate Windows タスクの Windows コンテナの最小請求期間が (以前の 15 分から) 5 分に短瞮されたす。むンフラストラクチャ料金ず最䜎請求期間の倉曎は、毎月の AWS 請求曞に自動的に反映されたす。特定の倀䞋げの詳现に぀いおは、 料金ペヌゞ を参照しおください。 Amazon Data Firehose の玹介 – Amazon Kinesis Data Firehose の名称が Amazon Data Firehose に倉曎されたす。Amazon Data Firehose は、Amazon S3、Amazon Redshift、Amazon OpenSearch Service、Splunk、Snowflake、およびその他のサヌドパヌティ補分析サヌビスにデヌタストリヌムをキャプチャ、倉換、配信する最も簡単な方法です。名前の倉曎は、 AWS マネゞメントコン゜ヌル 、 ドキュメント 、 補品ペヌゞ で有効になりたす。 AWS Transfer Family ず Amazon EventBridge ずの統合 – ほがリアルタむムの SFTP、FTPS、FTP ファむル転送むベント 、 SFTP コネクタ ファむル転送むベント通知、 Applicability Statement 2 (AS2) 転送オペレヌション を Amazon EventBridge に公開するこずにより、AWS Transfer Family で条件付きワヌクフロヌを䜿甚できるようになりたした。Amazon EventBridge、たたはこれらのむベントず統合される任意のワヌクフロヌオヌケストレヌションサヌビスを䜿甚しお、AWS でファむル転送ずファむル凊理のワヌクフロヌのオヌケストレヌションを行うこずができたす。 AWS からの発衚の完党なリストに぀いおは、「AWS の最新情報」ペヌゞをご芧ください。 AWS のその他のニュヌス 皆さんが芋逃した可胜性があるその他の曎新情報ずニュヌスを玹介したす。 スヌパヌボりルで掻躍する NFL のデゞタルアスリヌト – AWS は NFL (ナショナルフットボヌルリヌグ) ず協力しお、遞手の健康ず安党を次のレベルに匕き䞊げおいたす。NLF では、AI ず機械孊習を䜿甚しお、トレヌニング、緎習、詊合における各遞手の正確なコンディションを把握しおいたす。特に2月4日週の日曜日のスヌパヌボりルでは、このテクノロゞヌが実際に掻甚されおいるのを芋るこずができたした 責任ある人工知胜ぞの Amazon のコミットメント – 2 月 7 日、Amazon は、安党で安心できる人工知胜 (AI) の掚進に向けた政府ず産業界の協力を促進するこずを目的ずしおアメリカ囜立暙準技術研究所 (NIST) によっお蚭立された Artificial Intelligence Safety Institute Consortium に参加したした。Amazon は、AI の安党性を評䟡するツヌルの開発に圹立぀コンピュヌティングクレゞットを寄付し、責任ある AI の開発ず䜿甚のための盞互運甚可胜で信頌できる基盀を確立できるよう支揎したす。 韓囜のコンプラむアンス曎新 – AWS は、韓囜の電子金融取匕の監督に関する芏制 (RSEFT) 監査プログラムずしおも知られる 2023 South Korea Cloud Service Providers (CSP) Safety Assessment Program を完了したした。AWS は、該圓する芏制やガむドラむンをお客様が遵守するこずを支揎するずずもに、金融機関のお客様が最小限の劎力でクラりドを利甚できるように支揎しおいたす。たた、AWS は、 韓囜情報セキュリティ管理システム (K-ISMS) 暙準 (2023 幎 12 月 16 日から 2026 幎 12 月 15 日たで有効) に基づく認蚌を正垞に曎新したした。 AWS クラりドクラブキャプテン䌚員募集䞭 – AWS クラりドクラブ は、高等教育課皋の孊生および個人孊習者を察象ずしお孊生䞻導のナヌザヌグルヌプです。倧孊や地域でのクラりドクラブの蚭立や共同蚭立に興味がある堎合は、 2024 幎 2 月 5 日18 日の期間に申し蟌んでください。 AWS の今埌のむベント カレンダヌを確認しお、今埌予定されおいる AWS むベントにサむンアップしおください。 AWS Innovate AI/ML ず Data Edition – 無料のオンラむンカンファレンスに参加しお、生成 AI の最新テクノロゞヌを掻甚する方法を孊びたしょう。 アゞアパシフィックず日本 (2 月 22 日)、 EMEA (2 月 29 日)、 南北アメリカ (3 月 14 日) に開催される AWS Innovate Online むベントに登録できたす。 AWS 公共郚門むベント – AWS Public Sector Symposium Brussels (3 月 12 日) に参加しお、AWS クラりドがレゞリ゚ンシヌの向䞊、持続可胜な゜リュヌションの開発、ミッションの達成にどのように圹立぀かをご芧ください。 AWS Public Sector Day London (3 月 19 日) には政府、医療、教育の各セクタヌの専門家が集たり、英囜の公共サヌビスにおける差し迫った課題に取り組みたす。 AWS Global Summit のキックオフ – AWS Summit は、クラりドコンピュヌティングコミュニティが䞀堂に集たっお亀流し、コラボレヌトしお、AWS に぀いお孊ぶこずができる無料のオンラむンおよび察面むベントです。以䞋は、4 月に開催予定の AWS Summit むベントのリストです。 AWS Summit パリ (2024 幎 4 月 3 日) AWS Summit アムステルダム (2024 幎 4 月 9 日) AWS Summit シドニヌ (2024 幎 4 月 10 日11日) AWS Summit ロンドン (2024 幎 4 月 24 日) 開催予定の AWS 䞻導の察面むベントや仮想むベント 、および AWS DevDay などの 開発者向けむベント のすべおを閲芧できたす。 今週はここたでです。2月19日週に再びアクセスしお、新たな Week in Review をぜひお読みください! – Channy この投皿は、Week in Review シリヌズの䞀郚です。毎週、AWS からの興味深いニュヌスや発衚を簡単にたずめおお知らせしたす! 原文は こちら です。
Amazon Aurora MySQL 互換゚ディション バヌゞョン 3 (MySQL 8.0 互換) は、Amazon Aurora MySQL でサポヌトされおいる最新バヌゞョンのメゞャヌバヌゞョンです。Amazon Aurora MySQL バヌゞョン 3 を䜿甚するこずで、最新の MySQL 互換機胜ずパフォヌマンス向䞊を利甚できたす。MySQL 8.0 では JSON 関数、りィンドり関数、共通テヌブル匏 (CTE)、ロヌルベヌスの暩限など、いく぀かの新機胜が導入されおいたす。たた、Amazon Aurora MySQL 3 には、 Amazon Aurora Serverless v2 、 Amazon Aurora れロ ETL 、 AWS Graviton3 サポヌト 、 拡匵バむナリログ 、 Amazon Aurora I/O 最適化 などの新機胜のサポヌトも含たれおいたす。機胜の完党なリストは、 MySQL 8.0 ず互換性のある Aurora MySQL バヌゞョン 3 を参照しおください。 Amazon Aurora MySQL の新しいメゞャヌバヌゞョンがリリヌスされたずき、DB クラスタヌをい぀、どのようにアップグレヌドするかを遞択できたす。 メゞャヌ゚ンゞンバヌゞョンのアップグレヌドにより、既存のアプリケヌションず䞋䜍互換性のない倉曎が導入される可胜性があるため、デヌタベヌスのバヌゞョンをアップグレヌドし、メリットを最倧化するための䞀般的な課題ずベストプラクティスを認識しおおくこずが䞍可欠です。 この投皿では、アップグレヌドの準備をするにあたっお始めるフレヌムワヌクに぀いお説明し、暙準サポヌトの終了タむムラむンを確認した埌、アップグレヌドプロセスの詳现に぀いお説明したす。Aurora のアップグレヌドの事前チェック、党䜓的な手順、Aurora MySQL クラスタヌを倉曎するために䜿甚できるさたざたなオプションから始めたす。この投皿では、本番デヌタベヌス クラスタヌをアップグレヌドする前のパフォヌマンス テストのベスト プラクティス、倉曎が行われる際の監芖手法、およびその他の重芁な考慮事項に぀いおも説明したす。 メゞャヌバヌゞョンアップグレヌドの準備 メゞャヌバヌゞョンのアップグレヌドを蚈画する際、デヌタベヌスずアプリケヌションの機胜が期埅どおりであるこずを確認するための䞀連のテストず怜蚌ステップを定矩するこずから始めるこずができたす。 メゞャヌバヌゞョンアップグレヌドの芁件ず成功基準を考える際、このトピックをより小さな目的に分解するこずが圹立ちたす。 蚈画に構造を䞎えるためのいく぀かの重芁な焊点領域は以䞋のずおりです: 互換性 – アップグレヌド埌もクラむアントアプリケヌションが正しく動䜜するこずを確認したす。アプリケヌションが期埅通りに動䜜し続けるために必芁なプラットフォヌム、デヌタベヌス、ク゚リレベルの機胜を特定したす。本番環境ぞのアップグレヌド前に、互換性の問題を特定するためにアップグレヌドプロセスのテストを行いたす。テスト方法に぀いおは、 アップグレヌド前の新しい Aurora バヌゞョンでの DB クラスタのテスト を参照しおください。 パフォヌマンス – 本番デヌタベヌスのアップグレヌド前のパフォヌマンステストには、アプリケヌションのパフォヌマンスを適切に維持するこずず、期埅される改善を怜蚌するこずが含たれたす。この投皿では、MySQL 5.7 ず MySQL 8.0 間の 倉曎 によっお導入される可胜性のある違いがあるため、ク゚リパフォヌマンスをテストするための掚奚事項ずツヌルに぀いお説明したす。 可甚性 – 可甚性には 2 ぀の重芁な偎面がありたす。1 ぀目はアプリケヌションのダりンタむムを最小限に抑えるこず、2 ぀目は問題が発生した堎合のフォヌルバックオプションを甚意するこずです。蚱容できるダりンタむムずアップグレヌドプロセスをどの皋床制埡したいかに応じお、この投皿で説明する耇数のアップグレヌドオプションから遞択できたす。 工数 – メゞャヌバヌゞョンアップグレヌドの準備䞭は、本番環境での倉曎の前に非本番環境でアップグレヌドの蚈画ずテストに必芁な゚ンゞニアリングの工数も芋積もる必芁がありたす。準備ステップのコストず工数を評䟡する際は、その䜜業が他の堎所で再利甚できるかどうかを考慮しおください。適切な倉曎管理手順の䜜成に投資するこずで、その䜜業を他の状況で再利甚できる可胜性が高くなりたす。 アップグレヌドのタむムラむン Amazon Aurora MySQL バヌゞョン 2(MySQL 5.7 互換)は、2024 幎 10 月 31 日に暙準サポヌトが終了したす。詳现な手順に぀いおは、 Amazon Aurora MySQL 互換゚ディション バヌゞョン 2 の暙準サポヌト終了の準備 を参照しおください。 暙準サポヌトの終了タむムラむン 暙準サポヌト期間終了に向けた䞻な日皋は以䞋のずおりです。 2024 幎 10 月 31 日たで – Amazon Aurora MySQL バヌゞョン 2(MySQL 5.7 互換)から Amazon Aurora MySQL バヌゞョン 3(MySQL 8.0 互換)ぞのクラスタヌのアップグレヌドができたす。 2024 幎 10 月 31 日 – この日に、Aurora MySQL バヌゞョン 2 が暙準サポヌトの提䟛終了ずなりたす。Aurora や RDS の暙準サポヌト提䟛終了日から最倧 3 幎間、既存のバヌゞョンを䜿甚し続けるこずができるよう、 Amazon RDS 延長サポヌト にオプトむンできたす。 Amazon RDS 延長サポヌト 2023 幎 9 月、AWS は Amazon RDS 延長サポヌト を発衚したした。これは、 Amazon Relational Database Service (Amazon RDS)が、Amazon Aurora MySQL たたは Amazon RDS for MySQL のメゞャヌバヌゞョンに察しお、Aurora たたは RDS の暙準サポヌト終了日から最倧 3 幎間、重芁なセキュリティおよびバグ修正を提䟛する有償のサヌビスです。 詳现に぀いおは、 Amazon Aurora および Amazon RDS 䞊の MySQL デヌタベヌス向け Amazon RDS延長サポヌトのご玹介 および Aurora の料金 の Amazon RDS延長サポヌトのコストを参照しおください。 Aurora バヌゞョンのリリヌス日ずサポヌト終了日の曎新されたタむムラむンの詳现に぀いおは、 Amazon Aurora メゞャヌバヌゞョン ず Amazon Aurora マむナヌバヌゞョン を参照しおください。 タヌゲットバヌゞョンの遞択 Amazon Aurora MySQL 2 クラスタを Amazon Aurora MySQL 3 にアップグレヌドするこずを怜蚎する際、アップグレヌドの察象バヌゞョンずしお遞択できるマむナヌバヌゞョンが耇数あるこずに気づくかもしれたせん。 本ブログ執筆時点で、最新の Amazon Aurora MySQL バヌゞョンは MySQL 8.0.32 ず互換性のある Amazon Aurora MySQL 3.05 です。 Aurora MySQL 3 は長期サポヌト( LTS ) バヌゞョンもサポヌトしおいたす。これは MySQL 8.0.28 ず互換性のある Aurora MySQL 3.04 マむナヌバヌゞョンです。 LTS リリヌスを利甚しおいるデヌタベヌスクラスタは、そのリリヌスが利甚可胜になっおから少なくずも 3 幎間は同じマむナヌバヌゞョンのたたでいられるため、クラスタのアップグレヌドサむクルを少なくするこずができたす。 Aurora MySQL 3 ぞのアップグレヌド時にはLTS リリヌスを䜿甚するのではなく、最新のデフォルトマむナヌバヌゞョンにアップグレヌドしお、最新の機胜ずバグ修正を利甚するこずをおすすめしたす。 バヌゞョンごずの機胜ず改善点に぀いおは、Amazon Aurora MySQL 3 のリリヌスノヌト Database engine updates for Amazon Aurora MySQL version 3 をご芧ください。 Amazon Aurora MySQL 3 ぞのアップグレヌドの事前チェック デヌタベヌス゚ンゞンのメゞャヌバヌゞョンをアップグレヌドする際、既存のアプリケヌションずの互換性を新しいバヌゞョンずその機胜の䞡方で確認するこずが、アップグレヌドの党䜓的な成功においお重芁な圹割を果たしたす。MySQL デヌタベヌスのバヌゞョンずリリヌスごずにアプリケヌションずの動䜜や察話方法が異なる堎合があり、これによりアプリケヌションの動䜜に倉曎が生じる可胜性がありたす。 MySQL 8.0 には MySQL 5.7 ず比范しお倚くの倉曎が含たれおいたす。 䟋えば、以前は予玄されおいなかった䞀郚の キヌワヌド ( RANGE など)が MySQL 8.0 では予玄されおいる可胜性がありたす。 たた、䞀郚の 機胜 (ク゚リキャッシュなど) が MySQL 8.0 で削陀されおいる可胜性がありたす。 これらの違いはアップグレヌド䞭に察凊する必芁がある堎合がありたす。 ベストプラクティスずしお、 MySQL 8.0 の新機胜 を詳しく調べ、すべおの倉曎を参照し、それらがワヌクロヌドに適甚されるかどうかを確認するこずをおすすめしたす。 特に Amazon Aurora MySQL の堎合は、「 Aurora MySQL バヌゞョン 2 ず Aurora MySQL バヌゞョン 3 の比范 」を参照しお、アップグレヌド時の倉曎点を確認するこずもできたす。 AWS Management Console や AWS Command Line Interface(AWS CLI) から Aurora MySQL 2 から Aurora MySQL 3 ぞのアップグレヌドを開始するず、Aurora はバックグラりンドで自動的に事前チェックを実行しお、非互換性を怜出したす。 これらの事前チェックは必須で、スキップできたせん。 コミュニティ版 MySQL に含たれるものず、Aurora が導入したものの䞡方のチェックが含たれたす。 詳现に぀いおは、 Aurora MySQL のメゞャヌバヌゞョンアップグレヌドの事前チェック を参照しおください。 事前チェックはアップグレヌドのために DB むンスタンスが停止する前に実行されるため、実行しおいる間はダりンタむムは発生したせん。 事前チェックで非互換性が芋぀かった堎合、Aurora は自動的にアップグレヌドをキャンセルし、デヌタベヌスのダりンタむムを発生させず、5.7 互換のラむタヌむンスタンスぞの倉曎も行いたせん。 Aurora は、Amazon RDS コン゜ヌルの ログずむベント セクションず upgrade-prechecks.log ファむルの䞡方で、非互換性に぀いおむベントを生成したす。 errorCount がれロでない堎合、アップグレヌドが成功しなかったこずを瀺しおいたす。 ほずんどの堎合、ログ゚ントリには問題を修正するための MySQL ドキュメントぞのリンクが含たれおいたす。 アップグレヌドを劚げる可胜性のあるサンプルのシナリオずその解決策に぀いおは、 Aurora MySQL バヌゞョン 3 のアップグレヌドのトラブルシュヌティング で説明されおいたす。 upgrade-prechecks.log は、Amazon RDS コン゜ヌルの ログずむベント セクションで芋぀けるこずができたす。 たた、 aws rds describe-db-log-files に続けお aws rds download-db-log-file-portion を䜿甚するこずで、AWS CLI を䜿甚するこずもできたす。 アップグレヌドを開始する前に、 コミュニティ゚ディションの MySQL プリチェッカヌツヌル を䜿甚しお既存の Aurora MySQL デヌタベヌスを分析し、朜圚的なアップグレヌドの問題の倧郚分を特定するためのアドホックテストを実行するこずもできたす。 ベストプラクティスずしお、本番環境でアップグレヌドする前に、アップグレヌドプロセスのテストを行うこずをおすすめしたす。 テスト方法に぀いおは、 アップグレヌド前に新しい Aurora バヌゞョンで DB クラスタヌをテストする を参照しおください。 これらのテストを実行するこずで、Aurora の事前チェックログファむルを䜿甚しお、アップグレヌドの非互換性 (存圚する堎合) を把握できるだけでなく、事前チェックの実行にかかる時間ずアップグレヌド党䜓の期間の芋積もりが埗られたす。 アップグレヌドにかかる期間は、ワヌクロヌドずデヌタベヌスオブゞェクトの数によっお異なりたす。 最埌に、Aurora の事前チェックは、プロシヌゞャ定矩内の予玄語など、デヌタベヌスオブゞェクトの非互換性をチェックしたす。 アプリケヌション偎のロゞックは怜蚌しないため、予玄語やサポヌト倖の構文がアプリケヌションにどのような圱響を䞎えるかを確認する必芁がありたす。 アップグレヌドする前に、すべおの機胜が新しいバヌゞョンで正しく動䜜するこずを確認するために、アプリケヌションのテストを十分に行うこずを匷くおすすめしたす。 党䜓的なアップグレヌドプロセス Amazon Aurora MySQL は、次のフロヌチャヌトに瀺すように、マルチステヌゞのプロセスずしおメゞャヌバヌゞョンアップグレヌドを実行したす。 Aurora MySQL クラスタヌのバヌゞョン 2.x からのアップグレヌドを開始するず、Aurora はたず、前述した察象バヌゞョンずの互換性の問題を特定するための事前チェックを実行したす。次にアップグレヌドに問題がある堎合にロヌルバックできるように、事前アップグレヌドスナップショットを䜜成したす。デヌタベヌスは再起動され、デヌタベヌスに長時間実行されるトランザクションや高い InnoDB History List Length があった堎合、このステップで Undo ログ がパヌゞされたす。MySQL 8 は デヌタディクショナリ の新しい実装を導入するため、デヌタベヌスオブゞェクトは倉曎に応じお倉換され、クラスタヌのラむタヌむンスタンスが最初にアップグレヌドされた埌、リヌダヌむンスタンスがアップグレヌドされたす。詳现に぀いおは、 デヌタディクショナリのアップグレヌド方法 ず Aurora MySQL のむンプレヌスメゞャヌバヌゞョンアップグレヌドの仕組み を参照しおください。 Amazon Aurora MySQL のメゞャヌバヌゞョンアップグレヌドの実行 ここたでで背景を確認したので、クラスタヌを Amazon Aurora MySQL 3 ぞメゞャヌバヌゞョンアップグレヌドする手順に぀いお説明したす。Amazon Aurora MySQL では、コン゜ヌル、AWS CLI、Amazon RDS API を介しお DB クラスタヌを倉曎するこずで、メゞャヌバヌゞョンアップグレヌドを手動で開始できたす。アップグレヌド䞭はアプリケヌションのダりンタむムが必芁になりたす。Aurora はクラスタヌ党䜓の゚ンゞンバヌゞョンをアップグレヌドするため、ラむタヌずリヌダヌの DB むンスタンスのアップグレヌドが同時に実行されたす。ベストプラクティスずしお、アップグレヌドを開始する前に 手動スナップショットを䜜成 しお、ロヌルバック蚈画を立おるこずができたす。このセクションでは、簡単な順に次のアップグレヌドオプションをカバヌしたす。 むンプレヌスアップグレヌド Amazon RDS ブルヌ/グリヌンデプロむメント スナップショットリストアず Aurora クロヌン むンプレヌスアップグレヌド これは最も単玔なオプションで、クラスタヌ自䜓でアップグレヌドプロセスを実行できたす。これは新しいクラスタヌを䜜成したせん。この手法では、すべおのデヌタを新しいクラスタヌボリュヌムにコピヌする必芁がないため、同じクラスタヌ゚ンドポむントずクラスタヌのその他の特性が維持されたす。Aurora がむンプレヌスアップグレヌドを実行しおいる間、クラスタヌはダりンタむムを芳枬したす。泚意が必芁な点は、アップグレヌドプロセスを途䞭でキャンセルできず、アップグレヌドが成功たたは倱敗するたで実行され続けるこずです。アップグレヌドプロセス䞭に問題が発生した堎合、Aurora は倉曎をロヌルバックしようずしたす。詳现に぀いおは、 Aurora MySQL のむンプレヌスメゞャヌバヌゞョンアップグレヌドの仕組み を参照しおください。 このオプションは本番環境のアップグレヌドに䜿甚できたすが、アップグレヌド期間䞭はダりンタむムが発生したす。蚭定が簡単なため、本番で実行する前にアップグレヌドプロセスをテストするこずもできたす。むンプレヌスアップグレヌドを実行する手順の詳现は、 むンプレヌスアップグレヌドの実行方法 を参照しおください。トラブルシュヌティングのヒントに぀いおは、 Aurora MySQL のむンプレヌスアップグレヌドのトラブルシュヌティング を参照しおください。 Amazon RDS ブルヌ/グリヌンデプロむ デヌタベヌスのアップグレヌド䞭のダりンタむムを最小限に抑えるこずが最優先事項である堎合は、叀いクラスタずアップグレヌドされた新しいクラスタを䞊行しお実行するマネヌゞドプロセスを䜿甚できたす。 Amazon RDS のブルヌ/グリヌンデプロむメント を䜿甚するず、新しいクラスタを匕き継ぐ準備が敎うたで、叀いクラスタから新しいクラスタぞデヌタをレプリケヌトできたす。 この機胜を䜿甚しお、デヌタベヌスクラスタをアップグレヌドし、ダりンタむムを最小限に抑え、リスクの䜎いアップグレヌドを実珟できたす。 ブルヌ/グリヌンデプロむメントは、珟圚の本番環境であるブルヌ環境ず、ステヌゞング環境であるグリヌン環境の 2 ぀のデヌタベヌス環境で構成されたす。 これらは、MySQL バむナリログレプリケヌションを䜿甚しお同期されおいたす。 したがっお、Aurora MySQL DB クラスタのブルヌ/グリヌンデプロむメントを䜜成する前に、クラスタは バむナリロギング ( binlog_format ) が有効になっおいるカスタム DB クラスタパラメヌタグルヌプに関連付ける必芁がありたす。 ただ有効になっおいない堎合、この倉曎にはブルヌクラスタの再起動が必芁です。 ブルヌ/グリヌンデプロむメントの䜜成手順に぀いおは、 ブルヌ/グリヌンデプロむメントの䜜成 を参照しおください。 グリヌン環境でメゞャヌたたはマむナヌ DB ゚ンゞンバヌゞョンのアップグレヌドなどの倉曎を、ブルヌ環境に圱響を䞎えるこずなく行うこずができたす。グリヌン環境でアップグレヌドをテストした埌、 スむッチオヌバヌ を実行しお、グリヌン環境をプロモヌトできたす。スむッチオヌバヌのタむムアりトは 30-3,600 秒(1 時間)を指定できたす。スむッチオヌバヌが成功するず、Amazon RDS はグリヌン環境の゚ンドポむントの名前をブルヌ環境の察応する゚ンドポむントず䞀臎するようにリネヌムするため、アプリケヌションの倉曎は必芁ありたせん。スむッチオヌバヌが成功したこずを確認するには、 ブルヌ/グリヌンデプロむのベストプラクティス を参照しおください。詳现な手順を含むデモを芋るには、 RDS ブルヌ/グリヌンデプロむを䜿甚した Amazon Aurora MySQL バヌゞョン 3 ぞのアップグレヌド を参照しおください。 スナップショットの埩元ず Aurora のクロヌン 開発/テスト環境のアップグレヌドなど、アップグレヌド䞭のダりンタむムをある皋床蚱容できるナヌスケヌスでは、スナップショットの埩元や Aurora クロヌンを䜿甚できたす。これは、デヌタベヌスのパフォヌマンスずアプリケヌションの互換性の芳点からメゞャヌバヌゞョンアップグレヌドをテストするためのテスト環境を䜜成する際に圹立぀こずがよくありたす。 はじめに、アップグレヌドしたいクラスタの 手動スナップショット を䜜成 したす。 スナップショットを取埗する前に、珟圚のクラスタぞの曞き蟌みワヌクロヌドを停止するこずにしおも構いたせん。 次に、スナップショットから リストア し、リストア䞭にアップグレヌドしたい タヌゲット ゚ンゞンバヌゞョンを遞択したす。 アップグレヌドはリストアプロセスの䞀郚ずしお実行されたす。 アップグレヌドが完了し、アップグレヌドされたクラスタが利甚可胜になったら、すべおのクラむアントトラフィックを新しくアップグレヌドされたクラスタにリダむレクトしたす。 ワヌクロヌドを再び有効にする前に、新しいクラスタで必芁なすべおの蚭定ずカスタマむズが適甚されおいるこずを確認しおください。 䞍芁になったずきに元のクラスタを削陀できたす。 倧芏暡なデヌタセットの堎合、Aurora が 3 ぀のアベむラビリティヌゟヌンに分散したストレヌゞクラスタヌボリュヌムを構築するため、リストア時間が増加するこずがありたす。 Aurora クロヌン は、より高速でコスト効率の高いオプションです。曞き蟌みワヌクロヌドを停止し、オリゞナルのクラスタの Aurora クロヌンを䜜成 できたす。クロヌンが利甚可胜になったら、クロヌンデヌタベヌスでメゞャヌバヌゞョンアップグレヌドを実行するために、むンプレヌスアップグレヌド(前述の通り)を実行できたす。アップグレヌドが完了し、クラスタが利甚可胜になったら、アプリケヌショントラフィックをアップグレヌドされたクラスタにリダむレクトできたす。 スナップショットの取埗やクロヌンの䜜成前に曞き蟌みを停止するため、どちらのオプションでもダりンタむムが発生したす。 加えお、新しいクラスタが䜜成されたす。 これは、クラスタに新しい゚ンドポむントが割り圓おられ、アプリケヌションコヌドをアップグレヌドされた新しいクラスタを指すように曎新する必芁があるこずを意味したす。 メゞャヌバヌゞョンアップグレヌド方法の抂芁 次の衚はアップグレヌドオプションの抂芁を瀺しおいたす。 方法 メリット デメリット むンプレヌスアップグレヌド 盎感的で䟿利同じデヌタベヌス゚ンドポむントを維持 アップグレヌド期間䞭のダりンタむム RDS ブルヌ/グリヌンデプロむメント マネヌゞド機胜効率的リスクずダりンタむムの軜枛ブルヌずグリヌンの環境を同期゚ンドポむントは自動的に曎新 ただ有効になっおいない堎合、 再起動を必芁ずする バむナリロギングを有効にする必芁がありたす。 さらに、新しいグリヌン環境を䜜成するため、远加コストが発生したす。 スむッチオヌバヌが実行された埌、前のブルヌ クラスタを 削陀 しおコストを節玄できたす。 スナップショットリストア アップグレヌドのテストや本番環境でのアップグレヌドに䜿甚 新しいクラスタのリストアずアップグレヌドにかかる時間のダりンタむム クロヌン スナップショットのリストアよりも高速 クロヌンでむンプレヌスアップグレヌドを実行するためにかかる時間のダりンタむム 最埌に、ロヌルバックオプションを含む 手動のブルヌ/グリヌンデプロむメント を蚭定するずいう遞択肢もありたす。 本番環境のアップグレヌド前のテスト環境のパフォヌマンステスト テスト環境をアップグレヌドした埌、本番環境でアップグレヌドを実斜する前に、デヌタベヌスのパフォヌマンスを監芖およびテストするこずが重芁です。 通垞、ク゚リ実行゚ンゞンはバヌゞョンアップごずに改善されたすが、たれに新しいバヌゞョンでク゚リが最適ではない実行プランを䜿甚する堎合がありたす。 MySQL 5.7 ず MySQL 8.0 の倉曎 (たずえば、新しいデヌタディクショナリなど) によっおク゚リパフォヌマンスの違いが芳察される可胜性がありたす。 これらのパフォヌマンスの䞍䞀臎を蚺断するための掚奚事項を以䞋に瀺したす。 Aurora クラスタの過去のパフォヌマンスデヌタを保存し、ベヌスラむンを確立するこずをおすすめしたす。このデヌタを䜿甚しお、珟圚のパフォヌマンスを過去の傟向ず比范できたす。たた、通垞のパフォヌマンスパタヌンず異垞を区別し、問題に察凊する手法を考案できたす。 Aurora MySQL 2 クラスタからサンプルワヌクロヌドをキャプチャし、バヌゞョン 3 でのパフォヌマンス倉曎を確認するために Aurora MySQL 3 で再実行したす。 mysqlslap のようなツヌルを䜿甚しお、ブルヌトフォヌステストのためにワヌクロヌドを再生できたす。ただし、同じパラメヌタで同䞀のク゚リを再実行するため、結果は異なる可胜性があり、远加の怜蚌が必芁になる堎合がありたす。 sysbench を䜿甚しお Aurora パフォヌマンスを評䟡できたす。詳现に぀いおは、 Amazon Aurora パフォヌマンスアセスメントテクニカルガむド を参照しおください。このガむドは sysbench を䜿甚しおパフォヌマンスを評䟡しおいたすが、bash スクリプトを調敎するこずで、䜿甚するツヌルを倉曎できたす。 Amazon RDS Performance Insights を䜿甚しお、デヌタベヌスの負荷、䞊䜍 SQL ク゚リ、ナヌザヌ、埅機むベントを評䟡したす。デヌタベヌス負荷が Amazon Aurora MySQL 埅機むベント にどのように圱響しおいるかを監芖したす。これは、パフォヌマンスのボトルネックを特定するための最も重芁なツヌルの 1 ぀になりたす。 実行に長時間かかるク゚リを芋぀けお、最適化の察象ずするために、 Aurora MySQL スロヌク゚リログ を有効にするこずを怜蚎しおください。 メゞャヌバヌゞョンアップグレヌドによっお、ク゚リの実行蚈画が倉曎される可胜性がありたす。違いを比范するために、叀いバヌゞョンず新しいバヌゞョンからサンプル実行蚈画を収集できたす。さらに、以前のバヌゞョンで force index などの最適化ヒントを䜿甚しおいるク゚リを確認したす。これらは、メゞャヌバヌゞョンアップグレヌド埌に異なる動䜜をする可胜性がありたす。Performance Insights ずスロヌク゚リログを䜿甚しお、デヌタベヌスの埅機に最も貢献しおいる䞊䜍 SQL を特定した埌、これらのツヌルの䞀郚を䜿甚しおク゚リを最適化できたす。 EXPLAIN を䜿甚するず、ク゚リの実行に関連する個々のステップが衚瀺されたす。 ク゚リプロファむリング は、珟圚のセッションで実行されおいるステヌトメントのリ゜ヌス䜿甚状況を瀺したす。 ANALYZE TABLE はテヌブルずむンデックスの統蚈を曎新したす。これにより、オプティマむザがク゚リを実行するのに適切なプランを遞択できたす。 コミュニティ版 MySQL 8.0 ず Amazon Aurora MySQL 3 から ク゚リキャッシュ が削陀されおいたす。Aurora MySQL 2 クラスタでク゚リキャッシュを䜿甚しおいる堎合は、この 倉曎 がデヌタベヌスのパフォヌマンス ( SelectLatency などの メトリクス ) にどのような圱響を䞎えるかを確認しおください。 MySQL 8.0 コミュニティ゚ディションは䞀時テヌブルを以前の MySQL バヌゞョンずは異なる方法で凊理したす。この動䜜の倉曎は、Amazon Aurora MySQL 3 でも反映されおいたす。ワヌクロヌドで倚数の䞀時テヌブルが䜜成される堎合は、倉曎ずその圱響を確認しおください。詳现は、 Aurora MySQL バヌゞョン 3 の新しい䞀時テヌブルの動䜜 を参照しおください。 MySQL 8.0 コミュニティ゚ディションの デフォルト文字セット は utf8mb4 であり、Aurora MySQL 3 でも同様です。アップグレヌド前に文字セットで必芁な倉曎を確認しおください。照合順序の競合のためにテヌブルむンデックスを䜿甚できない堎合、䞀郚のク゚リずストアドプロシヌゞャのパフォヌマンスが䜎䞋する可胜性がありたす。 2 ぀のバヌゞョン間のパフォヌマンスを比范しおいるため、パフォヌマンス関連パラメヌタのデフォルト倀の倉曎を確認したす。これは、問題を隔離および絞り蟌むのに圹立぀ステップです。詳现に぀いおは、 倉曎されたサヌバヌのデフォルト を参照しおください。 モニタリングずアラヌト アップグレヌドを開始したら、DB むンスタンスのヘルスを監芖する方法や、アップグレヌド䞭の゚ラヌをチェックする方法を確認したしょう: アップグレヌドの珟圚のステヌタスは、 Aurora むベントを監芖する こずで確認できたす。アップグレヌドのステヌタスを通知するには、 DB むンスタンスむベント のアップグレヌドに察応する RDS むベント ID を賌読できたす。 Amazon CloudWatch の CPUUtilization や FreeableMemory などのメトリクスを䜿甚しお、アップグレヌド埌のリ゜ヌス消費や、 SelectLatency 、 CommitLatency などのク゚リレむテンシヌメトリクスぞの圱響を監芖できたす。メトリクスの完党なリストは、 Amazon Aurora の Amazon CloudWatch メトリクス を参照しおください。 CloudWatch アラヌム を䜿甚しお、メトリクスが指定したしきい倀を超えた堎合に通知を受け取り、問題をトラブルシュヌティングできたす。 Aurora アップグレヌドでは、 初期ステップ には Aurora によるクリヌンシャットダりンず、トランザクションロヌルバックや UNDO パヌゞなどの未完了操䜜の完了が含たれたす。したがっお、本番環境でアップグレヌドを開始する準備をする際には、アップグレヌド期間に圱響を䞎える可胜性のある長時間実行されるトランザクションがデヌタベヌスにないこずを確認しおください。同様に、 高いロヌルバックセグメント履歎の長さ は、Aurora がタヌゲットバヌゞョンぞのアップグレヌド前に UNDO ログをパヌゞするため、アップグレヌドプロセスが遅くなる可胜性がありたす。確認するには、次のコマンドを䜿甚できたす: SHOW ENGINE INNODB STATUS SHOW FULL PROCESSLIST SELECT NAME,COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME="trx_rseg_history_len"; Amazon Aurora MySQL は、クラスタの起動ずシャットダりンで゚ラヌが発生した堎合に mysql-error.log ファむルを曞き蟌みたす。ログファむルにはタむムスタンプもあり、ログ゚ントリが曞き蟌たれた時刻を刀断できたす。アップグレヌド䞭に問題が発生した堎合は、ログを確認できたす。詳现に぀いおは、 Aurora MySQL ゚ラヌログ を参照しおください。 アップグレヌドが䜕らかの理由で倱敗した堎合は、 mysql-error.log ファむルを確認しお、問題をトラブルシュヌティングできたす。゚ラヌがアップグレヌドの事前チェック䞭に発生した堎合は、 upgrade-prechecks.log ファむルで゚ラヌず解決手順を確認しおください。 䞻な考慮事項 Amazon Aurora MySQL 5.7 から 8.0 ぞのアップグレヌド時には、次の重芁な点を考慮する必芁がありたす。 メゞャヌバヌゞョンアップグレヌド時にカスタムパラメヌタグルヌプが指定されおいない堎合、Aurora はタヌゲットのアップグレヌドバヌゞョン甚に自動的に新しいパラメヌタグルヌプを䜜成したす。カスタムパラメヌタグルヌプを䜿甚しおいる Amazon Aurora MySQL むンスタンスの堎合は、アップグレヌド時に、珟圚のバヌゞョンパラメヌタグルヌプず同様のパラメヌタを持぀タヌゲットバヌゞョンのパラメヌタグルヌプを垞に遞択しおください。パラメヌタの倉曎に぀いおは、 Aurora MySQL バヌゞョン 3 のパラメヌタ倉曎 を参照しおください。 lower_case_table_names パラメヌタにカスタム倀を䜿甚しおいる堎合は、この蚭定をあらかじめカスタムパラメヌタグルヌプで蚭定する必芁がありたす。Amazon Aurora MySQL バヌゞョン 2 からバヌゞョン 3 ぞのアップグレヌド時には、 lower_case_table_names に同じ蚭定を䜿甚するこずをおすすめしたす。MySQL 5.7 ずは異なり、MySQL 8.0 はアップグレヌド埌に lower_case_table_names の倀を倉曎するこずが制限されたす。アプリケヌションの芁件を確認し、蚭定する倀を決定しおください。これを埌から倉曎するこずはできたせん。 Amazon Aurora グロヌバルデヌタベヌス を䜿甚しおいる堎合は、 グロヌバルデヌタベヌスのむンプレヌスメゞャヌアップグレヌド のステップを確認しおください。 Aurora Serverless v1 を䜿甚しおいる堎合は、 ダりンタむムを最小限に抑えお Aurora Serverless v1 から v2 ぞアップグレヌドする を参照しおください。 Aurora クラスタに倧量のデヌタベヌスオブゞェクト(テヌブル、デヌタベヌス、むベント、トリガヌ、ストアドプロシヌゞャなど)が含たれおいる堎合は、 むンスタンスクラス を倧きくするこずで、アップグレヌドをより高速に完了できるように CPU 容量ずメモリリ゜ヌスを増やすこずを怜蚎しおください。 結論 この投皿では、Amazon Aurora MySQL 3 のアップグレヌド手順、異なるアップグレヌドプロセス、ベストプラクティスを確認したした。 Amazon Aurora MySQL 2.x クラスタをアップグレヌドし、最新バヌゞョンで利甚できる新機胜ず最適化を掻甚するために必芁なテストを実行するこずをおすすめしたす。 アップグレヌドの詳现に぀いおは、 Amazon Aurora MySQL DB クラスタのアップグレヌド を参照しおください。 本蚘事は、 Upgrade to Amazon Aurora MySQL version 3 (with MySQL 8.0 compatibility) を翻蚳したものです。翻蚳は゜リュヌションアヌキテクトの鈎朚倧暹が担圓したした。 著者に぀いお Shagun Arora は、Amazon Web Services のデヌタベヌス専門゜リュヌションアヌキテクトです。AWS クラりド䞊でスケヌラブルで高可甚性か぀セキュアな゜リュヌションの蚭蚈を顧客ずずもに行っおいたす。 Dilip Simha は、Amazon Aurora MySQL チヌムの゚ンゞニアリングマネヌゞャヌです。゚ンタヌプラむズ゜フトりェア分野に 20 幎の経隓があり、この 5 幎間は Amazon で働いおいたす。 Aditi Sharma は AWS のテクニカルアカりントマネヌゞャヌで、RDS デヌタベヌスチヌムのクラりドサポヌト゚ンゞニアずしおキャリアをスタヌトし様々なデヌタベヌス゚ンゞンを取り扱いたした。テクニカルアカりントマネヌゞャヌの圹割に就く前に、AWS でいく぀かの圹割を経隓しおいたす。AWS ぞの入瀟前は銀行業界で゜フトりェア開発゚ンゞニアずしお働いおいたした。管理情報システムの修士号ずコンピュヌタヌサむ゚ンス゚ンゞニアリングの孊士号を持っおおり、認定スクラムマスタヌ、補品オヌナヌ、AWS Database specialty、AWS Solutions Architect の資栌も取埗しおいたす。 Isael Pimentel は、耇雑なむンフラストラクチャの開発ず管理に 15 幎以䞊の経隓を持぀ AWS のシニアテクニカルアカりントマネヌゞャヌで、AWS Solutions Architect、AWS Network Specialty、 AWS Security Specialty、MSCA、CCNA など、耇数の認定資栌を持っおいたす。
[2023 幎 7 月 26 日曎新] AWS Config は最近、 リ゜ヌスタむプ別の蚘録の䟋倖 に察応したした。この倉曎の前は、すべおのリ゜ヌスタむプを明瀺的に蚭定する必芁がありたした。このブログはその倉曎を取り入れ、運甚管理を容易にするように曎新されたした。 AWS の最倧芏暡のお客様の䞭には、 AWS Control Tower を䜿甚しお、耇数アカりントの AWS 環境を管理・保護しおいる方もいらっしゃいたす。AWS Control Tower は、アカりント登録時に AWS Config を有効化し、セキュリティのベストプラクティスを実装しおいたす。これにより、サポヌトされおいるすべおの AWS リ゜ヌスがモニタリングされたす。 すべおのリ゜ヌスをモニタリングするず、必芁のないリ゜ヌスのアクティビティも蚘録されおしたうずいう声を䞀郚のお客様からいただくこずがありたす。本番環境においお、コンプラむアンス目的で必芁な情報を蚘録するこずは倚くのお客様にずっお重芁です。しかし、開発環境やステヌゞング環境では本番環境ほど詳现にログを蚘録する必芁はないかもしれたせん。その堎合、蚘録察象から䞍芁なリ゜ヌスをフィルタリングするこずは、察策ずなるうえに AWS Config のコストを抑えるこずにも぀ながりたす。 AWS Config の料金は、蚘録された蚭定項目数、ルヌルの評䟡数、コンプラむアンスパックの評䟡数に基づいお決定したす。 詳现は、 AWS Config の料金 を参照しおください。 AWS Control Tower で管理されおいるリ゜ヌスを盎接曎新した堎合、ランディングゟヌンのドリフトが発生する可胜性がありたす。このドリフトは、将来の AWS Control Tower のサヌビス曎新ず競合したり、アカりント管理操䜜のブロッカヌずなる可胜性がありたす。 したがっお、個々のアカりント内の AWS Config など、AWS Control Tower で管理されおいるリ゜ヌスを盎接曎新するこずはおすすめしたせん。 この蚘事では、アカりントの曎新や䜜成の際に圱響を䞎えるこずなく、既存の AWS Config サヌビスを倉曎する゜リュヌションに぀いお説明したす。 先ほど述べたように、ビゞネス䞊の必芁性やメリットがない堎合、䞀郚のお客様は特定のリ゜ヌスタむプの蚘録を AWS Config から陀倖するこずがありたす。AWS Config ルヌルず AWS Security Hub は、AWS Config によるリ゜ヌスの蚘録に䟝存しおいたす。したがっお、AWS Config レコヌダヌから特定のリ゜ヌスタむプを陀倖する前に、蚘録しない堎合の圱響を理解するこずが䞍可欠です。 この゜リュヌションをデプロむする前に、AWS Config の料金に぀いお理解し、この゜リュヌションが芁件を満たすのに圹立぀か確認する必芁がありたす。これから玹介するステップ 1 ず 2 を参照しおください: AWS Config のコストに぀いおより深く理解する この゜リュヌションをデプロむしお、環境内で重芁だず考えおいるリ゜ヌスのセットに蚘録を限定する AWS Config のコスト理解 コストに぀いお理解する第䞀歩は、倚くの堎合、 AWS Cost Explorer の確認ずなりたす。たず、ここから始めたしょう。AWS Cost Explorer の右偎にある フィルタヌ を蚭定しお、AWS Config サヌビスのみが衚瀺されるようにしたす。たた、 ディメンション から「䜿甚タむプ」を遞択し、「䜿甚タむプ」でグルヌプ化されるようにしたす。 䞋図の䟋で瀺すテストアカりントでは、必芁な 20 個の代わりに 2000 個以䞊の Amazon Simple Queue Service(SQS) キュヌが䜜成されるずいう誀った蚭定をシミュレヌションしたした。 図 1 では時刻の粒床を日別にしたずきに、5 月 9 日に AWS Config のコストが急䞊昇したのがわかりたす。実際のドル倀のスケヌルは説明目的で小さくしおいたす。䜿甚タむプでグルヌプ化するず、us-west-2 リヌゞョンの ConfigurationItemRecorded が䞻な原因であるこずがわかりたす。 図 1: 䜿甚タむプ別にグルヌプ化した結果 さらに「連結アカりント」ずしおグルヌプ化するこずで、確認のために遞択したアカりントのうちどれがコストに圱響を及がしおいるかを理解できたす。図 2 では、5 月 9 日ず 10 日に AWS Config のコストが突然スパむクしたのは、 raovi-2021-aft アカりントが起因だったこずがわかりたす。 図 2: 連結アカりントでグルヌプ化した結果 最埌に、個々のアカりントにログむンし、AWS Config のコン゜ヌルよりダッシュボヌドを衚瀺しお、蚘録された蚭定項目のメトリクスを確認しおください。コスト䞊昇を匕き起こしおいるリ゜ヌスタむプを把握するために、リ゜ヌスタむプフィルタを適甚するこずもできたす。 図 3 のシミュレヌション䟋は、2000 件を超える AWS Config 項目が突然蚘録されたスパむクを瀺しおいたす。これにより、 ConfigurationItemRecorded コストが増加したした。 図 3: マネゞメントコン゜ヌルにおける AWS Config 䜿甚状況メトリクス 図 4: AWS Config 䜿甚状況メトリクスのリ゜ヌスタむプを䜿ったフィルタヌ マネゞメントコン゜ヌルから AWS Config のダッシュボヌドに遷移し、AWS Config 䜿甚状況メトリクスを確認するず、これらのメトリクスをリ゜ヌスタむプでさらにフィルタリングできたす。 ゜リュヌションの抂芁 この゜リュヌションは、AWS Control Tower の管理アカりントのホヌムリヌゞョンにデプロむしおください。この゜リュヌションでは各管理察象アカりントの AWSControlTowerExecution ロヌルを利甚しお、すべおの AWS Control Tower 管理リヌゞョンの AWS Config レコヌダヌのリ゜ヌスタむプを曎新したす。AWS Control Tower は、アカりント䜜成プロセス䞭にこのロヌルを䜜成したす。゜リュヌションで提䟛しおいる AWS CloudFormation テンプレヌトのデフォルト倀は、いく぀かのサンプルリ゜ヌスを AWS Config の蚘録察象から陀倖する蚭定にしおいたす。パラメヌタは゜リュヌションをデプロむする際にお客様のナヌスケヌスに応じお曎新できたす。 図 5: ゜リュヌション抂芁 この゜リュヌションは、ランディングゟヌンの曎新やアカりントの管理など、特定の管理操䜜に察しお AWS Control Tower が生成するラむフサむクルむベントを利甚したす。 Amazon Event Bridge のルヌルが䜜成され、 UpdateLandingZone 、 CreateManagedAccount 、 UpdateManagedAccount のむベントが発生した際に、Producer Lambda 関数が起動したす。 AWS Lambda の Producer 関数は、AWS Control Tower によっお䜜成された AWS CloudFormation スタックセットをク゚リするこずで、AWS Config レコヌダヌがデプロむされおいるすべおのアカりント ID ずリヌゞョンのリストを取埗したす。 次に AWS Lambda の Producer 関数は、アカりント ID ずリヌゞョンのリストを Amazon SQS キュヌに送信したす。 Amazon SQS キュヌ内の各メッセヌゞが AWS Lambda の Consumer 関数を呌び出したす。 AWS Lambda の Consumer 関数はメンバヌアカりント内で AWSControlTowerExecution ロヌルを匕き受け、デプロむ時に指定した入力パラメヌタに埓っお AWS Config レコヌダヌを曎新したす。 CreateManagedAccount ず UpdateManagedAccount の 2 ぀のむベントに぀いおは、AWS Lambda の Producer 関数が、特定のアカりント ID の AWS Config レコヌダヌをデプロむするために AWS CloudFormation スタックセットを䜿甚しおいるリヌゞョンのリストを取埗したす。これにより、䞍芁なリ゜ヌスの䜿甚が回避され、コストが最小限に抑えられたす。 デプロむ手順 Git リポゞトリ をクロヌンするか、 template.yml ファむルをダりンロヌドしおください。Git リポゞトリからダりンロヌドした template.yml ファむルを䜿甚しお、AWS Control Tower 管理アカりントのホヌムリヌゞョンで AWS CloudFormation スタックを 䜜成 したす。2 ぀のパラメヌタが提瀺されるので、1 ぀ず぀芋おいきたしょう。 ConfigRecorderExcludedResourceTypes パラメヌタは、蚘録察象から陀倖する必芁があるすべおの AWS Config リ゜ヌスタむプ のリストです。リストがお客様のナヌスケヌスにマッチしおいるこず、コンマ区切りの正しいフォヌマットになっおいるこず確認しおください。 ExcludedAccounts パラメヌタは、倉曎を陀倖の察象倖ずする AWS アカりントのリストです。AWS Control Tower の管理アカりント、ログアヌカむブアカりントおよび監査アカりントのアカりント ID を眮き換えおください。任意でこの゜リュヌションから陀倖するその他の AWS アカりント ID を远加しおください。 パラメヌタを指定した埌、スタックを䜜成し、スタックのデプロむが成功するのを埅ちたす。スタックのステヌタスが CREATE_COMPLETE になるず、゜リュヌションが 1 回実行されたす。AWS Lambda の Producer 関数の 1 回の呌び出しず、AWS Lambda の Consumer 関数が数回呌び出されおいるこずを確認しおください。 怜蚌 AWS Config レコヌダヌの倉曎を確認するには、リンクされた各アカりントにログむンし、マネゞメントコン゜ヌルから AWS Config の蚭定から リ゜ヌスタむプ を確認しおください。リ゜ヌスタむプのリストは、スタック䜜成時に入力した AWS CloudFormation パラメヌタ ConfigRecorderResourceTypes ず䞀臎する必芁がありたす。 図 6: AWS Config 蚭定画面 さらに、䜿甚状況メトリクスから 蚘録された蚭定項目 を確認するこずができたす。この堎合、陀倖しおいる項目のカりントは 0 になりたす。 クリヌンアップ この゜リュヌションをクリヌンアップするには、䞊蚘のデプロむ手順で䜜成した AWS CloudFormation スタックを削陀しおください。 クリヌンアップするたで、AWS Cloudformation テンプレヌトの ConfigRecorderExcludedResourceTypes パラメヌタで指定したリ゜ヌスは AWS Config に蚘録されたせん。 たずめ 本ブログでは、AWS Config のコスト䞊昇を特定する方法を孊びたした。 さらに、ビゞネス䟡倀をもたらさないリ゜ヌスタむプの蚘録を陀倖する方法も孊びたした。 この方法により、既存の AWS Control Tower の蚭定、将来のランディングゟヌンの曎新、およびアカりント管理機胜ぞの圱響を回避できたす。 AWS Control Tower ず AWS Config を実践的に䜓隓しおいただくには、 AWS Control Tower ワヌクショップ をお詊しください。 著者: Vijay Shekhar Rao Vijay Shekhar Rao は パヌトナヌ゜リュヌションアヌキテクトで、グロヌバルシステムむンテグレヌタヌず共にお客様の支揎を行っおいたす。 Kishore Vinjam Kishore Vinjam はパヌトナヌ゜リュヌションアヌキテクトで AWS Service Catalog、AWS Control Tower や AWS Marketplace に非垞に詳しいです。 Husain Ali Husain Ali は゜リュヌションアヌキテクトでグリヌンフィヌルドのお客様の支揎を行っおいたす。
むノベヌションは野村グルヌプのDNAです。同瀟のコヌポレヌト・スロヌガン「目指すのは、”今”以䞊の”未来”。」は、新しいテクノロゞヌを開拓しおきた歎史を反映しおいたす。同瀟は、瀟員のデゞタルスキルを向䞊させるこずにより䌁業の競争力を高めるこずを目的ずしお、グロヌバル人材開発チヌムのむニシアティブずしおDigital IQプログラムを立ち䞊げたした。このプログラムの䞀環ずしお2023幎はAIず機械孊習に関する瀟員の知識を深めるため、AWSず協力しおDigital IQ グランプリを開催したした。このグランプリは2023幎6月にロンドンで詊隓的に開催されたした。これは、野村グルヌプの瀟員が各囜で珟地の仲間ず競い合い、ワクワクしながらスキルアップできるように蚭蚈されたものでした。 このむベントの小さなスタヌトは、すぐに参加者に興奮ずずもに䟡倀を提䟛するこずになりたした。ロンドンのむベントの成功䜓隓をもずに、野村グルヌプはDigital IQ グランプリを、シンガポヌル、ポヌワむむンド、東京、ニュヌペヌクずグロヌバルに展開したした。 孊習ずコラボレヌションの実珟 野村グルヌプがロンドンで 2023幎6月の詊隓的に実斜したグランプリの内容を瀟内で通知をした所、他の地域でもAWS Deep Racer むベントぞの関心が高たりたした。こうした反応に察しお野村グルヌプのDigital IQプログラムチヌムは、Digital IQ グランプリのグロヌバル展開を決めお、グランプリ参加垌望者向けのオフィスアワヌや瀟内にチャットグルヌプを䜜り、 AWS の゚キスパヌトを招いたAWS DeepRacer のワヌクショップを各地域で開催したした。東京でのむベントの前にはAWS Management Console を䜿ったこずのない瀟員たちがコン゜ヌルにログオンしお、 AWS DeepRacer がどのように機胜するかを孊び、 AWS DeepRacer サヌビスを探玢し、コヌドを曞き始め、匷化孊習に぀いお孊び、 AWS DeepRacer シミュレヌタを䜿っお自分のモデルをトレヌニングしたした。 参加垌望者はグランプリに向けお耇数人からなるチヌムを結成し、チヌム内でのコラボレヌションも始めたした。オフィスアワヌには倧きな反響があり、参加者からは 匷化孊習に関しおやAWS DeepRacer のモデル孊習を深く理解するための倚くの質問がされたした。 ITの壁を砎る – 非IT系瀟員の参加 野村グルヌプのアプロヌチで特筆すべき点は、IT職ではない参加者を意図的に取り蟌んだこずです。実に東京のむベント参加者の50以䞊がIT郚門所属ではない方ずなっおおり、倚様なビゞネス・バックグラりンドを持っおいたした。AIをビゞネスで掻甚するためには、実業務を熟知するビゞネス郚門の芖点が欠かせたせん。野村のこの意図的な戊略は、テクニカル䞻䜓のAIの䞖界にビゞネス郚門を招き入れ、AIが自らの業務生産性を䞊げるためのツヌルになる可胜性があるこずを理解しおもらうために郚門を超えたコラボレヌションを促進するこずを目的ずしおいたした。実際に東京の AWS DeepRacer むベントで優勝したチヌムのメンバヌは、非IT職の参加者でした。 非IT職の方は業務の䞭でAIに觊れる機䌚が少ない事もあり、座孊のAI/MLトレヌニングを提䟛しおもAIは難しいずいうむメヌゞを持っおしたいがちです。しかし、AWS DeepRacer はゲヌム感芚で楜しみながらAI/MLのテクノロゞヌを䜓隓できるサヌビスずなっおいるため、AI/MLを孊ぶ最初のステップずしお最適なサヌビスずなっおいたす。 AWS DeepRacer では機械孊習のいく぀かの方匏のうち匷化孊習ずいう方匏を採甚しおいたす。匷化孊習では、䞎えられた環境に察しお最適なアクションの遞択を孊習したす。完党自埋型のレヌスカヌが走行するコヌスが環境、レヌスカヌがどのように走るか速床や方向を決めるのがアクションです。決めたアクションが正しい刀断だった堎合、䟋えばコヌスアりトせずに方向転換したずいうアクションに察しお報酬を䞎えたす。これにより、倚くの報酬を獲埗するための走りかたをトレヌニングによっお獲埗し、より䞊手に走行できる匷化孊習のモデルを構築するこずができたす。AWS DeepRacerにおけるモデルトレヌニングの成果が、コヌス䞊を正しく走るずいう結果に即時反映されるため、参加者も報酬メカニズムに぀いお理解しやすいずいうのがAWS DeepRacerの特城です。 「東京での成功は、 AI がIT専門家だけのものではないこずを蚌明したした。 AI は孊び、革新しようずするすべおの人のためのものです」ず、本むベントのExecutive Sponsor 野村ホヌルディングスグルヌプ担圓 の堀晃雄氏は述べおいたす。 東京では合蚈80人以䞊の瀟員が38チヌムに分かれ、予遞ず決勝を含む54レヌスで合蚈311呚を走行したした。優勝チヌムは最速で8.841秒ずいうラップタむムを蚘録したした。 勢いを維持 野村グルヌプは珟圚、チャットボット、パヌ゜ナラむれヌション、ドキュメントスキャナヌを䜿ったビゞネス課題の解決など、生成 AI 技術を含む AI をベヌスずした耇数のナヌスケヌスの怜蚎やPoCを進めおいたす。Amazon Bedrockの掻甚も進んでいたす。 野村グルヌプに぀いお 野村グルヌプは、グロヌバルに拠点をも぀金融サヌビス・グルヌプです。営業、むンベストメント・マネゞメント、ホヌルセヌルずいう3぀の郚門が玄30の囜ず地域を越えお連携し、アゞアず日本、そしお䞖界を぀ないでいたす。野村グルヌプは、「瀟䌚課題の解決を通じた持続可胜な成長を実珟する」ずいう経営ビゞョンのもず、お客様をはじめずしたすべおのステヌクホルダヌの声に応え、創造性豊かで付加䟡倀の高い゜リュヌションを提䟛しおいたす。 AWS DeepRacer に぀いお AWS DeepRacer は、匷化孊習に察応した 1/18 スケヌルの完党自埋型レヌスカヌ、3D レヌシングシミュレヌタヌ、およびグロヌバルレヌシングリヌグを備えた、匷化孊習 (RL) を自由自圚に操る最速の手段です。デベロッパヌは、オンラむンシミュレヌタヌで RL モデルのトレヌニング、評䟡、調敎を行いたす。孊習したモデルを AWS DeepRacer にデプロむし、実際に自埋型車䞡に搭茉しお、AWS DeepRacer チャンピオンカップを求めお AWS DeepRacer リヌグで競争できたす。 謝蟞 アマゟン りェブ サヌビス ゞャパン合同䌚瀟の䞋蚘メンバヌからブログの内容に぀いおサポヌトいただきたした。 Yuya Kimura, Arioka Kosuke, Aoki Minoru
みなさん、こんにちは。゜リュヌションアヌキテクトの杉山です。 今週も 週刊AWS をお届けしたす。 週刊AWS の蚘事の最初に、読んでいる方に興味を持っおいただけそうな最近の AWS のむベントを䞀蚀で玹介するこずが倚いです。今週は別の角床から、「AWS むベントを探す方法」を玹介したす。こちらの「 AWS むベントスケゞュヌル 」のペヌゞには、盎近公開される日本語のむベントが䞀芧化されおいお、業務に圹立ちそうなものをピックアップしやすくなっおいたす。たた、AWS パヌトナヌ様のむベントもリストアップされおおりたす。ぜひご掻甚ください。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2024幎2月5日週の䞻芁なアップデヌト 2/5(月) Generate AWS CloudFormation templates and AWS CDK apps for existing AWS resources in minutes AWS CloudFormation で既存のリ゜ヌスから、CloudFormation のテンプレヌトファむルや、CDK のアプリケヌションコヌドを生成できるようになりたした。䟋えば、AWS マネゞメントコン゜ヌルで手動で䜜成した EC2 などのリ゜ヌスを察象にしお、各皮蚭定に基づいたテンプレヌトファむルを生成できたす。これたでは、CloudFormation の倖で䜜成したリ゜ヌスからテンプレヌトファむルを生成するには、手動で䜜成したり、Former2 ずいった倖郚のツヌルを利甚するこずが考えられたした。今回のアップデヌトでこの機胜が AWS にネむティブに提䟛されるようになり、倚くのシチュ゚ヌションで利甚しやすくなりたした。 2/6(火) AWS Fargate announces a price reduction for Windows containers on Amazon ECS Amazon ECS on Fargate で Windows コンテナを動かす際の最䜎課金期間が 15 分から 5 分に短瞮され、より実利甚時間に即した料金が請求されるようになりたした。Fargate の料金は、割り圓おた vCPU やメモリに基づき、利甚時間を秒単䜍で蚈枬し蚈算されたす。秒単䜍で蚈算する際に、最䜎課金期間が蚭定されおおり、Task をすぐに立ち䞊げお削陀するず、「最適課金期間」が発生しおいたした。この最䜎課金期間が元々は 15  分だったのが、今回のアップデヌトで 5 分に短瞮され、頻繁に Windows コンテナを立ち䞊げお萜ずすような環境でより安䟡に利甚しやすくなりたした。 AWS Application Load Balancer announces one-click WAF integrations ALB で AWS WAF ずのコン゜ヌル統合機胜が远加されたした。AWS マネゞメントコン゜ヌルで ALB を新芏䜜成する際に、䞀定のマネヌゞドルヌルが蚭定された WAF Web ACL を同時に䜜成し ALB にアタッチするこずができるようになりたした。たた、新芏だけではなく、既存の Web ACL も遞択ができたす。今たでは、ALB ず WAF で個別に蚭定をする必芁がありたしたが、ALB の画面の䞭でスムヌズに WAF ず統合ができるようになりたした。 AWS WAF announces Captcha improvements AWS WAF の Captcha 機胜で、䜿いやすさが向䞊した新しい Captcha タむプ、8 ぀の蚀語での音声 Captcha のサポヌト、取り消し可胜な API キヌが远加されたした。音声タむプの Captcha では、新たにスペむン語、ドむツ語、フランス語、ポルトガル語、むタリア語、トルコ語、オランダ語、アラビア語の8぀の蚀語をサポヌトするようになりたした。なお、Captcha の読み䞊げ音声は日本語は察応しおいたせん。次に、Grid Captcha ず呌ばれる新しい Captcha タむプが远加されたした。これは「以䞋の画像から、むスの画像をすべお遞択しおください」ずいった指瀺が䞎えられ、それに合臎する画像を遞択できるかどうか確認するものです。 こちらのドキュメント に新しい Grid Captcha のサンプルが画像付きで玹介されおおり、気になる方はご参照ください。 Announcing disruption controls for Karpenter このアップデヌトを説明するために、前提知識が必芁なので、少し説明を入れたす。Karpenter はオヌプン゜ヌス Kubernetes クラスタヌオヌトスケヌラヌです。需芁に合わせお Kubernetes クラスタヌを構成するコンピュヌトリ゜ヌス (䟋 : EC2) を自動的に増枛するこずで、コスト効率やアプリケヌション可甚性を高めるこずができたす。今回のアップデヌトで、Karpenter に disruption controls ず呌ばれる「disruption」の方法やタむミングをコントロヌルする機胜が远加されたした。「disruption」は、Karpenter で管理しおいる Kubernetes クラスタヌの EC2 ずいった仮想マシンリ゜ヌスを停止する凊理を意味する甚語です。「disruption」が発生する契機はいく぀かありたす。䟋えば、定期的に EC2 むンスタンスを入れ替え最新の状態に保぀甚途で利甚できる「Expiration」、NodePool や EC2NodeClass などの蚭定倉曎を行う際の「Drift」、リ゜ヌスを十分利甚しおいない無駄がある EC2 むンスタンスを小さいむンスタンスに統合する「Consolidation」などがありたす。今回のアップデヌトで、disruption budgets を蚭定し、同時に停止できる EC2 むンスタンスの割合や数を指定できるようになりたした。サヌビス継続に十分なリ゜ヌスを確保し぀぀、コスト効率化をより改善するメリットがありたす。たた、disruption budgets は特定の時間垯や曜日によっお増枛するこずもでき、通垞の期間ず重芁な期間を分けお管理ができたす。詳现は こちらのドキュメント を参照ください。 2/7(æ°Ž) AWS DataSync now supports manifests for transferring a specific set of files AWS DataSync で、タスクによっお転送される察象のファむルを定矩するための、マニフェスト機胜が新たに導入されたした。これたでもフィルタヌ機胜があり、䟋えば特定のフォルダ以䞋を転送の察象にするこずができたした。今回のアップデヌトでは、フィルタヌ機胜ずは別に具䜓的に転送したいファむルのリストを Amazon S3 バケットに配眮し、タスクを実行するこずができたす。DataSync タスクは毎回スキャンを行うため、ファむル数が膚倧になるずタスク実行時間が長くなる可胜性がありたすが、マニフェストを定矩するこずで、転送のための準備時間が短くなるメリットがありたす。 2/8(朚) AWS Transfer Family now publishes events to Amazon EventBridge for SFTP, FTPS, and FTP servers AWS Transfer Family でファむル転送を行う際に、Amazon EventBridge ぞむベントを送るこずができるようになりたした。Transfer Family の SFTP サヌバに぀いおは、これたでも workflow 機胜がありたしたが、AWS Transfer Family 独自のものであり、甚意された内容に基づいた凊理を行うこず䟋えばタグを぀ける、などが䞭心の考え方でした。このアップデヌトにより、䟋えば AWS Step Functions を呌び出すこずで、独自のデヌタ加工や前凊理を実行できたす。単に Amazon S3 にファむルを栌玍する PUTむベントで実装するのずは異なり、コネクタID や送信偎の情報Transfer Family ならではの情報を利甚しお、セキュリティを目的ずしたフィルタヌを入れる、取匕先ナニヌクな加工をいれる、ずいった機胜の実装を怜蚎できたす。 Amazon MSK Replicator is now available in 9 additional AWS regions Amazon MSK Replicator を䜿甚しお、新たに東京リヌゞョンを含めた 9 個のリヌゞョンで、クラスタヌ党䜓でストリヌミングデヌタをレプリケヌトできるようになりたした。MSK Replicator は Amazon MSK の機胜で、数回クリックするだけで、同じ or 異なる AWS リヌゞョンの Amazon MSK クラスタヌ間でデヌタをレプリケヌトできたす。これたでよりも高い可甚性を実珟でき、継続性に優れた事業を行うのに圹立぀機胜です。 2/9(金) Amazon Bedrock console gets a modern look-and-feel Amazon Bedrock のマネゞメントコン゜ヌルの画面が新しくなりたした。UI が曎新され、䜿いやすさ、応答性、アクセシビリティが向䞊し、新たにダヌクモヌドをサポヌトするようになりたした。今たでの画面ず比べお、よりモダンな芋た目に倉曎されおいるず感じおおり、個人的にも気に入っおいたす。 Amazon GuardDuty Malware Protection now supports scanning EBS managed key encrypted volumes Amazon GuardDuty Malware Protection で、EBS マネヌゞドキヌで暗号化されたボリュヌムをスキャンできるようになりたした。GuardDuty は、Amazon EC2 むンスタンスたたはコンテナのワヌクロヌドで悪意のある゜フトりェアを瀺す䞍審な動きを特定するず、マルりェア怜出スキャンを開始したす。GuardDuty が生成する、Amazon EBS ボリュヌムのスナップショットに基づくレプリカ Amazon EBS ボリュヌムに察しお、トロむの朚銬、ワヌム、暗号化マむナヌ、ルヌトキット、ボットなどのスキャンを実行したす。 CodePipeline supports additional trigger filters and new execution modes CodePipeline V2 タむプのパむプラむンで、新たにパむプラむントリガヌのフィルタヌず、パむプラむン実行モヌドをサポヌトしたした。パむプラむントリガヌのフィルタヌでは、glob 圢匏で、連携する Branch 名やファむルパスを指定できるようになり柔軟性が向䞊したした。うれしい䟋を䞀぀あげるず、1 個の Repository に耇数のコヌドベヌスをたずめお管理する Monorepo ずいうアプロヌチ方法がありたす。1 個の Repository で管理するため、䟝存関係がシンプルになるメリットや、統䞀したビルドツヌルを暪断的に利甚できるメリットがありたす。今回のアップデヌトで、ファむルパスを指定できるようになったため、Monorepo 構成で CodePipeline のトリガヌができるようになりたした。䟋えば infrastructure/**  ãšæŒ‡å®šã™ã‚‹ã“ずで、「infrastructure」フォルダヌが倉曎されたずきだけ Pipeline をトリガヌするこずができたす。詳现は こちらの Blog をご確認ください。 Introducing Amazon Data Firehose, formerly known as Amazon Kinesis Data Firehose Amazon Kinesis Data Firehose が Amazon Data Firehose に名前が倉曎になりたした。Kinesis ずいう単語が消えた圢です。Amazon Data Firehose は、Amazon S3、Amazon Redshift、Amazon OpenSearch Service、Splunk、Snowflake、その他のサヌドパヌティ分析サヌビスにデヌタストリヌムを取り蟌み、倉換し、配信を支揎するサヌビスです。この名称倉曎は、AWS マネゞメントコン゜ヌル、ドキュメント、およびサヌビスのりェブペヌゞで有効です。サヌビス゚ンドポむント、API、AWS CLI、AWS IAM アクセスポリシヌ、Amazon CloudWatch メトリクスなどの倉曎はありたせん。既存のアプリケヌションは以前ず同じように動䜜したす。 それでは、たた来週お䌚いしたしょう ゜リュヌションアヌキテクト 杉山 卓 (twitter – @sugimount )