はじめに この記事では量子コンピューティングに関連するサービスをクラウド上に展開しているものを紹介しようと思います。 ここで一点お断りですが、単一のハードウェアを使うための手段としてクラウド提供しているもの（IBM QuantumやD-Wave Leap等々）まで挙げるには余白が狭すぎる、というのと、量子ハードウェアの記事と重複してしまうので、複数の量子系サービスを統合的に利用できるようなプラットフォームっぽいものをこの記事では取り上げていこうと思います。 そうすると、結局 AWS Azure GCP の三大クラウドのあたりに収束しますので、今回はそれらのクラウドサービスにおける量子コンピューティングプラットフォームについて現在の状況をまとめていきたいと思います。 クラウドで提供されると何が嬉しいか？注意することは？ クラウド上で量子コンピューティングプラットフォームが提供されると嬉しいことは、 ハードウェア提供者と契約を個別に取り交わすことなく開発者が慣れ親しんだクラウドサービス上で利用ができる 課金管理や権限管理がクラウドサービス内で完結する 複数の量子ハードウェアを利用することができるため比較検証ができる クラウドサービス上にある他のサービスとの連携がスムーズにできる といった点だと思います。 逆に注意するべき点としては、 直接ハードウェア提供者と契約をする場合よりも課金体系としてコストが割高になることがある ハードウェア提供者がリリースした最新の機能やデバイスを使えるようになるまでリードタイムがある という点が挙げられると思います。 とはいえ何よりも、未来のコンピュータと考えられていた量子コンピュータが気軽に使えるという点だけでも価値があるといえると思っています。 三大クラウドの状況はいかに？ Amazon Braket 大手クラウドサービス系としては一番最初に量子コンピューティングプラットフォームをリリースしたのがAWSのAmazon Braketで、2020年8月から一般提供が開始されました。 フルマネージドで利用ができるため、AWSアカウントを作成して、Amazon Braketを有効化するだけで利用を開始することができます。 利用することができる量子ハードウェアは 量子アニーリング型マシン D-Wave 量子ゲート型マシン IonQ Rigetti ですが、今後QuEra（冷却原子方式）、Oxford Quantum Circuits（超伝導方式）も使えるようになるとの発表が2021年12月にありました。 接続ができる実機としては上記の通りですが、その他にAWS独自の高性能な量子ゲート型シミュレータもマネージドサービスとして提供されております。 また、AWSからはAmazon Braket専用のSDKが提供されており、設計した回路をそのままに接続先ハードウェアを変えるようなこともできます。 そのため、計算実行に対する課金額が高い実機に接続する前にシミュレータで挙動を確認してから実機につないで計算を実行するような使い方も簡単にできます。 Amazon Braketの中にはJupyter Notebookも備えられており、さらにその中にチュートリアルも整備されています。 2021年12月にはAmazon Braket Hybrid Jobsという、古典コンピュータと量子コンピュータの両方を使いながら実行する変分アルゴリズム向けのサービスも発表されておりますので、今後も新機能の追加やアップデートに大きな期待がかかります。 AWSのではAmazon Braketのリリースに合わせてでしょうか、量子コンピューティングの研究者を採用したようで、そういった方々も積極的に情報発信 Azure Quantum 2021年2月にパブリックプレビュー版としてリリースされたAzureQuantumでは、 イジング最適化ソルバ（≠量子コンピュータ） Microsoft QIO 1QBit 1Qloud 東芝 SBM 量子ゲート型マシン Honeywell IonQ QCI をサポートしていると公式ページに記載があります このうち、東芝SBMはプライベートプレビュー状態のようで一般公開はされていないようです。 また、QCIについてはQCI自体の企業活動についての情報発信も更新が止まっており、当然そんな状況なのでAzure Quantumでも利用ができる状態まで至っていない様子です。 その他、注意すべき点として、 1QBit 1QloudとIonQについてはAzureのBillingRegionをUSにしておかないと利用することができない Honeywellの利用料金が月額定額での支払なのですが、Standardプランで\$125,000/月、Premiumプランで\$175,000/月となっている といった点が挙げられます。 一方、ドキュメントやチュートリアルは非常に充実しており、チュートリアルについてはAzure Quantum内のJupyter環境から実行することができます。 量子ゲート型の開発についてはMicrosoft QDKによる開発ももちろん可能ですが、QiskitやCirqを使うこともできます。 プレビュー版ということで対応ハードウェアの面では成熟していない感じもしますが、GA版リリースに向けて改善されていくのではないかと考えられます。 Google Cloud 実はGoogle Cloudには量子コンピューティングプラットフォーム的なものがまだ存在しておらず、筆者の認識が正しければ2021年6月に発表された通りIonQがMarketplace経由で利用できるだけです。 しかし、GoogleはCirqの開発も手掛けているGoogle Quantum AIという枠組みの中でQuantum Computing Serviceというプラットフォームを準備しており、そのうち準備が整った段階で公開がされるのではと見られますので、今後の動向には注目です。 Quantum Computing Serviceでは、おそらくですがCirqが対応している IonQ Alpine Quantum Technologies（イオントラップ方式） Pasqal（冷却原子方式） は使えることになるのでは？と個人的に予想しています。 最後に 今のところ最も量子コンピューティングのプラットフォームサービスに力が入っているのはAWSじゃないかなと思いますが、AzureやGCPの追い上げもきっとあるだろうと思いますので、この三大クラウドの競争は量子コンピュータの観点でも引き続き目が離せないと思います。 さて、このAdvent Calendarでは2日目～4日目まで、「量子コンピュータ市場の主要プレーヤーはどんな企業・サービスがあるのか？」という観点で自分なりにまとめてみました。 市場全体としてはかなり盛り上がりつつある領域ですが、実際のところ実用段階にはまだまだ達していないので過度な期待は禁物です。 とはいえ次々と新しい取り組みやプロダクトがこれからも世に放たれていくことが予測されます。 これまで筆者が挙げたものの他にも注目企業や注目サービスがあれば是非コメント等で教えていただけると大変嬉しいです！ 本記事に記載の会社名、製品またはサービスなどの名称は、各社の商号、商標もしくは登録商標です。本文中、および図中では、TM マーク、(R)マークは必ずしも表記しておりません。 なお、個々のコンテンツにおいて、個別に商標が示されている場合には、当該情報が優先されます。

はじめに 「QAエンジニアもAWSの基礎知識があったほうがいいのかも」ということで、まずはCLF試験に向けて学習をはじめ、現在はSAAに向けて学習を再開しようとしているところ 知識をつけた先は未知数 CLF合格に向けて集めた教材＆情報をまとめた アクションごとに、情報とやったことをまとめた SAAに関する情報も載せていきたいため、今後もSAA合格までは頻繁に更新をかけるかも知れない AWS、AWS CLFの概要を知る AWS初心者のための勉強会資料【入門編】〜結局AWSって何なの？〜 「おっしゃーAWS学ぶぞ〜まずは何から？」というときに見ると良かった 【AWS Black Belt Online Seminar】AWS 認定クラウドプラクティショナー取得に向けて 「おっしゃーAWS CLFやるぞ〜まずは何から？」というときに見ると良かった 2018年の動画なので情報が古い部分が存在する可能性はあるが、概要を掴むには役立つ AWS認定試験についての説明を飛ばしてクラウドプラクティショナーのことを知りたいなら12:20あたりから観ると良い 学習計画を立てる クラウドエンジニア(AWS)ロードマップ2021 - Qiita 学習の全体像をロードマップ図にまとめたもの 最終的に下記の流れで学習していくことに決めた ①本をざっと一周読む わからないことがあっても気にせず強引に一周する 実際にやってみると全部が分からないことに気付かされ、これから始まる学習への不安と期待が高まった ②UdemyのSAAのハンズオンを進める 休日にハンズオンに取り組む 隙間時間に講義を視聴する それにより、ざっと全体像や要点を把握する ②CLF対策としてCLFのUdemyの模試パック回す ハンズオンと同時進行。ゆえに番号を一緒にしている 一通り解いたあと、最後のSAAレベルの模試以外を周回した サービスごとに問題を集約させたプリントを作って眺めたりもした なお12/3現在でふりかえると、①の本の1周目とCLF模試各回の一周目がいちばんしんどかった。 ④CLF受ける←2021/11/20にここまで完了 ⑤SAAのUdemyの模試パック回す ⑥SAAの公式模試を受ける CLF受けるとSAAの模試が一回無料で受けられるためそれを利用しSAAのレベル感を把握する ⑦SAA受ける ⑧その後は実務も通して学んでいく 教材を買う（実際に買ったものだけ載せた） 本 AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第2版 いわゆるオレンジ本。CLFの緑本は購入せず、SAAを見越してこちらを購入。 はじめにざっと読んで、その後は適宜辞書的に使ったりしている。 Udemy これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版） SAAのハンズオン 「各サービスの概要→そのサービスのハンズオン」というような構成になっている スマホにアプリを入れて概要部分を隙間時間に聴くのがおすすめ この問題だけで合格可能！AWS 認定クラウドプラクティショナー 模擬試験問題集（7回分455問） CLFの模試 こちらもスマホアプリで解くのがおすすめ 各サービス、用語の概要を知る いろいろなサービスをひとことで説明している。 【2021年】AWS全サービスまとめ | DevelopersIO サービスや用語の説明で構成された単語帳。 AWS単語帳 - Qiita せっかくなので自作のマインドマップも載せておく Xmindで作った試験に良く出るサービスの概要 これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版）の講義を参考に作成した 部屋の良くみる場所に貼っておいたところ割と頭に入った whimsicalで作成中のWell-Architected フレームワークの説明 whimsicalはオンラインマインドマップツールとしての可能性を感じる 日本語が直接打てなくなるという致命的なバグを抱えているが、それ以外の操作性はいい。 公式情報にあたる 試験本番直後に「もっと公式情報にもあたっておけば良かったかも」と反省 AWS Well-Architected フレームワーク ホワイトペーパー(PDF) ベストプラクティス集。 各サービスのホワイトペーパーについてもSAA学習の際は適宜参照していきたいし、実務で関わる際にも参照していくことになると思う AWS Black Belt Online Seminar 製品・サービス別、ソリューション別、業種別のセミナーでYouTubeで視聴可能なものもある 申し込みをする AWSクラウドプラクティショナー試験の申込方法・当日の持ち物（ピアソンVUE版） この記事を参考に進めた。 なおメールの印刷はしていないが、受付で名前を伝えるだけでスムーズに案内された。 あくまで緊急事態に備えてのものなので、スマホでメールを表示できる準備があれば大丈夫そう。 CLF合格後、SAAに向けて動き出す AWS認定10資格について模擬試験が無料/解説付きで公式からリリースされたので受けてみた CLF合格した日に見つけた CloudTech AWSのオンラインスクール。フリーコース(無料)でも、SAAの問題が200問解ける。 AWS認定ソリューションアーキテクト アソシエイト試験：短期突破講座（300問の演習問題） Udemyの模試

1.はじめに こちらの記事で、New Relic デビューをしてから5日が経過しました。 完全に理解した！！って最後に言ってますが、次のBlogを書いていたら、「お、完全に理解したし、ついでにやっとく？」と思いました。 ということで、New RelicとLambdaを完全に理解するための記事を一本書くことにしました。 2. AWS Lambdaアプリケーションの構成 意味は特になし。何も考えず、とりあえず、こんなアプリを作ろうと考えた。とりあえず、正規の流れと、エラー時のDLQがある感じ。 これがどう可視化されるのか、見せてもらおうか、New Relicさんよ 3. さて、困った。まずは環境を作ろう。 New Relicさんよ、これ、どう料理してくるの？と途方に暮れている。 Lambdaとつなげるだけなら、なんとなくイメージができるが、このリソースだけ連携したいってできるんだろうか。 まずは、上記リソースをSAMで定義。 テンプレートはこちら。 SAMテンプレート template.yml AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: > sam-lambda-eventfiltering Globals: Function: Timeout: 10 Resources: HttpAPI: Type: AWS::Serverless::HttpApi Properties: AccessLogSettings: DestinationArn: !GetAtt LogGroup.Arn Format: '{ "accountId" : "$context.accountId", "requestId" : "$context.requestId", "ip" : "$context.identity.sourceIp", "caller" : "$context.identity.caller", "user" : "$context.identity.user", "requestTime" : "$context.requestTime", "httpMethod" : "$context.httpMethod", "resourcePath" : "$context.routeKey", "path" : "$context.path", "status" : "$context.status", "protocol" : "$context.protocol", "responseLatency" : "$context.responseLatency","IntegrationLatency" : "$context.integrationLatency", "responseLength" : "$context.responseLength" }' DefinitionBody: Fn::Transform: Name: AWS::Include Parameters: Location: openapi.yml FailOnWarnings: true # Logs LogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub /apigateway/${AWS::StackName} RetentionInDays: 7 ProducerFunction: Type: AWS::Serverless::Function Properties: FunctionName: !Sub ${AWS::StackName}-ProducerFunction CodeUri: ProducerFunction/ Handler: app.lambda_handler Runtime: python3.9 Architectures: - x86_64 Environment: Variables: STREAM_NAME: !Ref Stream Policies: - Version: '2012-10-17' Statement: - Effect: Allow Action: kinesis:PutRecord Resource: - !GetAtt Stream.Arn # Logs LogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub /aws/lambda/${AWS::StackName}-ProducerFunction RetentionInDays: 7 Stream: Type: AWS::Kinesis::Stream Properties: Name: !Sub ${AWS::StackName}-Stream RetentionPeriodHours: 168 ShardCount: 1 BackendFunction: Type: AWS::Serverless::Function Properties: FunctionName: !Sub ${AWS::StackName}-BackendFunction CodeUri: BackendFunction/ Handler: app.lambda_handler Runtime: python3.9 Architectures: - x86_64 Environment: Variables: QUEUE_URL: !Ref Queue Events: KinesisEvent: Type: Kinesis Properties: Stream: !GetAtt Stream.Arn StartingPosition: LATEST BatchSize: 10 MaximumBatchingWindowInSeconds: 10 MaximumRetryAttempts: 2 DestinationConfig: OnFailure: Destination: !GetAtt FunctionDLQ.Arn Enabled: True FilterCriteria: Filters: - Pattern: '{"data": {"PRIORITY": [ { "numeric": [ "=", 100 ] } ]}}' Policies: - Version: '2012-10-17' Statement: - Effect: Allow Action: sqs:SendMessage Resource: - !GetAtt FunctionDLQ.Arn - !GetAtt Queue.Arn # Logs LogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub /aws/lambda/${AWS::StackName}-BackendFunction RetentionInDays: 7 Topic: Type: AWS::SNS::Topic Properties: KmsMasterKeyId: alias/aws/sns Queue: Type: AWS::SQS::Queue Properties: QueueName: !Sub ${AWS::StackName}-Queue RedrivePolicy: deadLetterTargetArn: !GetAtt SQSDLQ.Arn maxReceiveCount: 3 QueuePolicy: Type: AWS::SQS::QueuePolicy Properties: Queues: - !Ref Queue PolicyDocument: Statement: - Sid: AllowSNSSendMessage Effect: Allow Principal: "*" Action: - sqs:SendMessage Resource: !GetAtt Queue.Arn Condition: ArnEquals: aws:SourceArn: !Ref Topic SQSDLQ: Type: AWS::SQS::Queue Properties: QueueName: !Sub ${AWS::StackName}-SQS-DLQ SnsSubscription: Type: AWS::SNS::Subscription Properties: Protocol: sqs Endpoint: !GetAtt Queue.Arn Region: !Ref AWS::Region TopicArn: !Ref Topic EntityFunction: Type: AWS::Serverless::Function Properties: FunctionName: !Sub ${AWS::StackName}-EntityFunction CodeUri: EntityFunction/ Handler: app.lambda_handler Runtime: python3.9 Architectures: - x86_64 Events: SQSEvent: Type: SQS Properties: Queue: !GetAtt Queue.Arn BatchSize: 10 MaximumBatchingWindowInSeconds: 10 Enabled: True FilterCriteria: Filters: - Pattern: '{"body": {"PRIORITY": [ { "numeric": [ "<", 101 ] } ]}}' # Logs LogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub /aws/lambda/${AWS::StackName}-EntityFunction RetentionInDays: 7 FunctionDLQ: Type: AWS::SQS::Queue Properties: QueueName: !Sub ${AWS::StackName}-FunctionDLQ Outputs: HttpApiUrl: Description: URL of your API endpoint Value: Fn::Sub: 'https://${HttpAPI}.execute-api.${AWS::Region}.${AWS::URLSuffix}/' 上記をデプロイする際には、こちらで紹介されているAWS SAM Accelerate(Public Preview)を利用してみた。これ 最高 変更があったところだけをビルドしてくれる。 sam build sam sam build -c --use-container Starting Build use cache Starting Build inside a container Valid cache found, copying previously built resources from function build definition of 41b5f567-f801-4e26-8216-fcd6e91d084f Valid cache found, copying previously built resources from function build definition of 7e65aa0e-777d-4089-a680-e382ad85b126 Valid cache found, copying previously built resources from function build definition of 35723abb-a2eb-4191-a1d8-a4bc7e224f9b Build Succeeded Built Artifacts : .aws-sam/build Built Template : .aws-sam/build/template.yaml Commands you can use next ========================= [*] Invoke Function: sam local invoke [*] Test Function in the Cloud: sam sync --stack-name {stack-name} --watch [*] Deploy: sam deploy --guided そしてこれが最高。ビルドして、デプロイして、さらに変更を検知して自動デプロイしてくれる sam sync sam sam sync --stack-name sam-newrelic --watch Creating the required resources... Successfully created! Managed S3 bucket: aws-sam-cli-managed-default-samclisourcebucket-19pogohle14me Default capabilities applied: ('CAPABILITY_NAMED_IAM', 'CAPABILITY_AUTO_EXPAND') To override with customized capabilities, use --capabilities flag or set it in samconfig.toml This feature is currently in beta. Visit the docs page to learn more about the AWS Beta terms https://aws.amazon.com/service-terms/. The SAM CLI will use the AWS Lambda, Amazon API Gateway, and AWS StepFunctions APIs to upload your code without performing a CloudFormation deployment. This will cause drift in your CloudFormation stack. **The sync command should only be used against a development stack**. Confirm that you are synchronizing a development stack and want to turn on beta features. Enter Y to proceed with the command, or enter N to cancel: [y/N]: AWSReservedSSO_AdministratorAccess_5f16b3a82a040f87:~/environment/sam-newrelic $ sam sync --stack-name sam-newrelic --watch Managed S3 bucket: aws-sam-cli-managed-default-samclisourcebucket-19pogohle14me Default capabilities applied: ('CAPABILITY_NAMED_IAM', 'CAPABILITY_AUTO_EXPAND') To override with customized capabilities, use --capabilities flag or set it in samconfig.toml This feature is currently in beta. Visit the docs page to learn more about the AWS Beta terms https://aws.amazon.com/service-terms/. The SAM CLI will use the AWS Lambda, Amazon API Gateway, and AWS StepFunctions APIs to upload your code without performing a CloudFormation deployment. This will cause drift in your CloudFormation stack. **The sync command should only be used against a development stack**. Confirm that you are synchronizing a development stack and want to turn on beta features. Enter Y to proceed with the command, or enter N to cancel: [y/N]: y Experimental features are enabled for this session. Visit the docs page to learn more about the AWS Beta terms https://aws.amazon.com/service-terms/. Queued infra sync. Wating for in progress code syncs to complete... Starting infra sync. Manifest is changed for 41b5f567-f801-4e26-8216-fcd6e91d084f, downloading dependencies and copying/building source Building codeuri: /home/ec2-user/environment/sam-newrelic/ProducerFunction runtime: python3.9 metadata: {} architecture: x86_64 functions: ['ProducerFunction'] Manifest is changed for 7e65aa0e-777d-4089-a680-e382ad85b126, downloading dependencies and copying/building source Building codeuri: /home/ec2-user/environment/sam-newrelic/BackendFunction runtime: python3.9 metadata: {} architecture: x86_64 functions: ['BackendFunction'] Manifest is changed for 35723abb-a2eb-4191-a1d8-a4bc7e224f9b, downloading dependencies and copying/building source Building codeuri: /home/ec2-user/environment/sam-newrelic/EntityFunction runtime: python3.9 metadata: {} architecture: x86_64 functions: ['EntityFunction'] Running PythonPipBuilder:CleanUp Clean up action: .aws-sam/deps/35723abb-a2eb-4191-a1d8-a4bc7e224f9b does not exist and will be skipped. Running PythonPipBuilder:ResolveDependencies Running PythonPipBuilder:CleanUp Clean up action: .aws-sam/deps/7e65aa0e-777d-4089-a680-e382ad85b126 does not exist and will be skipped. Running PythonPipBuilder:ResolveDependencies Running PythonPipBuilder:CleanUp Clean up action: .aws-sam/deps/41b5f567-f801-4e26-8216-fcd6e91d084f does not exist and will be skipped. Running PythonPipBuilder:ResolveDependencies Running PythonPipBuilder:CopySource Running PythonPipBuilder:CopySource Running PythonPipBuilder:CopySource Build Succeeded Built Artifacts : .aws-sam/auto-dependency-layer Built Template : .aws-sam/auto-dependency-layer/template.yaml Commands you can use next ========================= [*] Invoke Function: sam local invoke -t .aws-sam/auto-dependency-layer/template.yaml [*] Test Function in the Cloud: sam sync --stack-name {stack-name} --watch [*] Deploy: sam deploy --guided --template-file .aws-sam/auto-dependency-layer/template.yaml Successfully packaged artifacts and wrote output template to file /tmp/tmp7tu7w5lb. Execute the following command to deploy the packaged template sam deploy --template-file /tmp/tmp7tu7w5lb --stack-name <YOUR STACK NAME> Deploying with following values =============================== Stack name : sam-newrelic Region : ap-northeast-1 Disable rollback : False Deployment s3 bucket : aws-sam-cli-managed-default-samclisourcebucket-abc Capabilities : ["CAPABILITY_NAMED_IAM", "CAPABILITY_AUTO_EXPAND"] Parameter overrides : {} Signing Profiles : null Initiating deployment ===================== 2021-12-03 02:55:06 - Waiting for stack create/update to complete CloudFormation events from stack operations ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ResourceStatus ResourceType LogicalResourceId ResourceStatusReason ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- CREATE_IN_PROGRESS AWS::CloudFormation::Stack sam-newrelic Transformation succeeded CREATE_IN_PROGRESS AWS::SNS::Topic Topic - CREATE_IN_PROGRESS AWS::SQS::Queue FunctionDLQ - CREATE_IN_PROGRESS AWS::CloudFormation::Stack AwsSamAutoDependencyLayerNestedStack - CREATE_IN_PROGRESS AWS::SQS::Queue SQSDLQ - CREATE_IN_PROGRESS AWS::Logs::LogGroup LogGroup - CREATE_IN_PROGRESS AWS::IAM::Role EntityFunctionRole - CREATE_IN_PROGRESS AWS::SNS::Topic Topic Resource creation Initiated CREATE_IN_PROGRESS AWS::IAM::Role EntityFunctionRole Resource creation Initiated CREATE_IN_PROGRESS AWS::Kinesis::Stream Stream - CREATE_IN_PROGRESS AWS::SQS::Queue FunctionDLQ Resource creation Initiated (省略) - ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- CloudFormation outputs from deployed stack -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Outputs -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key HttpApiUrl Description URL of your API endpoint Value https://xxxxxx.execute-api.ap-northeast-1.amazonaws.com/ -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Stack creation succeeded. Sync infra completed. {'StackId': 'arn:aws:cloudformation:ap-northeast-1:xxxxxx:stack/sam-newrelic/6bb4c260-53e4-11ec-a339-064a048f128d', 'ResponseMetadata': {'RequestId': 'xxxxxx-3414-xxxx-xxxx-2080f7b0907d', 'HTTPStatusCode': 200, 'HTTPHeaders': {'x-amzn-requestid': ''xxxxxx-3414-xxxx-xxxx-2080f7b0907d', 'content-type': 'text/xml', 'content-length': '387', 'date': 'Fri, 03 Dec 2021 02:55:06 GMT'}, 'RetryAttempts': 0}} Infra sync completed. この後、変更すると自動でデプロイ。すごく便利！でも、これ、テスト用であり、プロダクション用ではないのでご注意を。！！！ sam sync 自動更新の様子 Infra sync completed. Queued infra sync. Wating for in progress code syncs to complete... Starting infra sync. Manifest is not changed for 41b5f567-f801-4e26-8216-fcd6e91d084f, running incremental build Building codeuri: /home/ec2-user/environment/sam-newrelic/ProducerFunction runtime: python3.9 metadata: {} architecture: x86_64 functions: ['ProducerFunction'] Manifest is not changed for 7e65aa0e-777d-4089-a680-e382ad85b126, running incremental build Building codeuri: /home/ec2-user/environment/sam-newrelic/BackendFunction runtime: python3.9 metadata: {} architecture: x86_64 functions: ['BackendFunction'] Manifest is not changed for 35723abb-a2eb-4191-a1d8-a4bc7e224f9b, running incremental build Building codeuri: /home/ec2-user/environment/sam-newrelic/EntityFunction runtime: python3.9 metadata: {} architecture: x86_64 functions: ['EntityFunction'] Running PythonPipBuilder:CopySource Running PythonPipBuilder:CopySource Running PythonPipBuilder:CopySource Build Succeeded Built Artifacts : .aws-sam/auto-dependency-layer Built Template : .aws-sam/auto-dependency-layer/template.yaml Commands you can use next ========================= [*] Invoke Function: sam local invoke -t .aws-sam/auto-dependency-layer/template.yaml [*] Test Function in the Cloud: sam sync --stack-name {stack-name} --watch [*] Deploy: sam deploy --guided --template-file .aws-sam/auto-dependency-layer/template.yaml Successfully packaged artifacts and wrote output template to file /tmp/tmpxp_4u4_w. Execute the following command to deploy the packaged template sam deploy --template-file /tmp/tmpxp_4u4_w --stack-name <YOUR STACK NAME> Deploying with following values =============================== Stack name : sam-newrelic Region : ap-northeast-1 Disable rollback : False Deployment s3 bucket : aws-sam-cli-managed-default-samclisourcebucket- Capabilities : ["CAPABILITY_NAMED_IAM", "CAPABILITY_AUTO_EXPAND"] Parameter overrides : {} Signing Profiles : null Initiating deployment ===================== 2021-12-03 03:29:32 - Waiting for stack create/update to complete CloudFormation events from stack operations ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ResourceStatus ResourceType LogicalResourceId ResourceStatusReason ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ^[[6UPDATE_IN_PROGRESS AWS::CloudFormation::Stack sam-newrelic Transformation succeeded UPDATE_IN_PROGRESS AWS::CloudFormation::Stack AwsSamAutoDependencyLayerNestedStack - UPDATE_COMPLETE AWS::CloudFormation::Stack AwsSamAutoDependencyLayerNestedStack - UPDATE_IN_PROGRESS AWS::IAM::Role APIIAMRole - UPDATE_COMPLETE AWS::IAM::Role APIIAMRole - UPDATE_COMPLETE_CLEANUP_IN_PROGRESS AWS::CloudFormation::Stack sam-newrelic - UPDATE_COMPLETE AWS::CloudFormation::Stack sam-newrelic - UPDATE_COMPLETE AWS::CloudFormation::Stack AwsSamAutoDependencyLayerNestedStack - ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- CloudFormation outputs from deployed stack ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Outputs ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key HttpApiUrl Description URL of your API endpoint Value https://xxxxxx.execute-api.ap-northeast-1.amazonaws.com/ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Stack update succeeded. Sync infra completed. {'StackId': 'arn:aws:cloudformation:ap-northeast-1:0123456789012:stack/sam-newrelic/6bb4c260-53e4-11ec-a339-064a048f128d', 'ResponseMetadata': {'RequestId': '7a17b289-09c6-413d-b9e4-d69c38f64a29', 'HTTPStatusCode': 200, 'HTTPHeaders': {'x-amzn-requestid': '7a17b289-09c6-413d-b9e4-d69c38f64a29', 'content-type': 'text/xml', 'content-length': '387', 'date': 'Fri, 03 Dec 2021 03:29:31 GMT'}, 'RetryAttempts': 0}} Infra sync completed. よし、Outputに出力されたURLにCurlでアクセス。 curl https://dgz0kn4bnh.execute-api.ap-northeast-1.amazonaws.com/hoge {"message": "hello world"} お、応答された。全部動いてるかな～。ログを見てみよう。 sam logs --stack-name sam-newrelic --tail --beta-features 2021/12/03/[$LATEST]bbaca989cc4243d59493ccb5a80c19be 2021-12-03T03:47:15.927000 START RequestId: 657e7e13-cbdd-41fd-96e8-0bb5366f0356 Version: $LATEST 2021/12/03/[$LATEST]bbaca989cc4243d59493ccb5a80c19be 2021-12-03T03:47:15.930000 {'EVENT_TIME': '2021-12-03T03:47:15.930066', 'ID': 'ID-842574', 'PRICE': 23755, 'PRIORITY': 2} 2021/12/03/[$LATEST]bbaca989cc4243d59493ccb5a80c19be 2021-12-03T03:47:16.110000 END RequestId: 657e7e13-cbdd-41fd-96e8-0bb5366f0356 2021/12/03/[$LATEST]bbaca989cc4243d59493ccb5a80c19be 2021-12-03T03:47:16.110000 REPORT RequestId: 657e7e13-cbdd-41fd-96e8-0bb5366f0356 Duration: 180.69 ms Billed Duration: 181 ms Memory Size: 128 MB Max Memory Used: 65 MB 2021/12/03/[$LATEST]704ca1c4d7a9447e9f0b83d6da7dcf2e 2021-12-03T03:47:17.472000 START RequestId: 20c111d8-ca64-4a42-9c03-564c2639cb04 Version: $LATEST 2021/12/03/[$LATEST]704ca1c4d7a9447e9f0b83d6da7dcf2e 2021-12-03T03:47:17.475000 Decoded payload: {"EVENT_TIME": "2021-12-03T03:47:15.930066", "ID": "ID-842574", "PRICE": 23755, "PRIORITY": 100} 2021/12/03/[$LATEST]704ca1c4d7a9447e9f0b83d6da7dcf2e 2021-12-03T03:47:17.642000 END RequestId: 20c111d8-ca64-4a42-9c03-564c2639cb04 2021/12/03/[$LATEST]704ca1c4d7a9447e9f0b83d6da7dcf2e 2021-12-03T03:47:17.642000 REPORT RequestId: 20c111d8-ca64-4a42-9c03-564c2639cb04 Duration: 167.21 ms Billed Duration: 168 ms Memory Size: 128 MB Max Memory Used: 65 MB dgz0kn4bnh_.default-2021-12-03-03-47 2021-12-03T03:47:15.898000 { "accountId": "0123345678912", "requestId": "JwPyogbrNjMEMQg=", "ip": "0.0.0.0", "caller": "-", "user": "-", "requestTime": "03/Dec/2021:03:47:15 +0000", "httpMethod": "GET", "resourcePath": "ANY /{proxy+}", "path": "/hoge", "status": "200", "protocol": "HTTP/1.1", "responseLatency": "194", "IntegrationLatency": "192", "responseLength": "26" } 2021/12/03/[$LATEST]1f8a453df389493eb18366032fa2e637 2021-12-03T03:47:37.701000 START RequestId: ed6ada3e-edd6-595d-8a89-801d785435d9 Version: $LATEST 2021/12/03/[$LATEST]1f8a453df389493eb18366032fa2e637 2021-12-03T03:47:37.703000 {'Records': [{'messageId': '4e4da240-c5e7-4df3-a561-473593f515d5', 'receiptHandle': 'AQEB5rl7O9zr6YWajKAgsWAkeZP+NszWV/qwGf9UfsKYRLtyq076SRuLMv2FnfFy0D8Aq6fGcUgDdNjBooQzJ5y/k8NXequRCAGubm0Cgmk8vq4SBwyaRSY83ndwtLkrG8wsrDtr534NTxuI45yu3+bmB+uGcOzMAxTlwBKfrw/mTC4Zb4CcRcXDBgYa7i7M2tu1on0NZi93guBeRNaOLZ90H4mw==', 'body': '{"EVENT_TIME": "2021-12-03T03:47:15.930066", "ID": "ID-842574", "PRICE": 23755, "PRIORITY": 100}', 'attributes': {'ApproximateReceiveCount': '1', 'SentTimestamp': '1638503237633', 'SenderId': 'sam-newrelic-BackendFunction', 'ApproximateFirstReceiveTimestamp': '1638503237639'}, 'messageAttributes': {}, 'md5OfMessageAttributes': None, 'md5OfBody': 'bcc4264ef0de3380b966cf933cd892d0', 'eventSource': 'aws:sqs', 'eventSourceARN': 'arn:aws:sqs:ap-northeast-1:12345689012:sam-newrelic-Queue', 'awsRegion': 'ap-northeast-1'}]} 2021/12/03/[$LATEST]1f8a453df389493eb18366032fa2e637 2021-12-03T03:47:37.704000 END RequestId: ed6ada3e-edd6-595d-8a89-801d785435d9 2021/12/03/[$LATEST]1f8a453df389493eb18366032fa2e637 2021-12-03T03:47:37.704000 REPORT RequestId: ed6ada3e-edd6-595d-8a89-801d785435d9 Duration: 1.06 ms Billed Duration: 2 ms Memory Size: 128 MB Max Memory Used: 37 MB 3. よし、つなげるぞ、New Relicさん。 こちらに手順がある。まずこれやるか。 そのStep 1: Link your AWS and New Relic accounts CLI導入 今回用に新規に立てた、Cloud9を使っているから、権限、CLI,Pythonは大丈夫だから、まずは、これ。うむ簡単。 pip3 install newrelic-lambda-cli API Key作成&入手 次は？というとAPI Key。これで入手する画面に移動。新規にユーザーのキーを作成し入手。NameはAWSLambdaで作ってみました。 次は・・・Step 1: Link your AWS and New Relic accounts 設定 newrelic-lambda integrations install --nr-account-id YOUR_NR_ACCOUNT_ID \ --nr-api-key YOUR_NEW_RELIC_USER_KEY Validating New Relic credentials Retrieving integration license key Creating the AWS role for the New Relic AWS Lambda Integration Waiting for stack creation to complete... ✔️ Done ✔️ Created role [NewRelicLambdaIntegrationRole_XXXXXX] in AWS account. Linking New Relic account to AWS account ✔️ Cloud integrations account [New Relic AWS Integration - 0123456789012] was created in New Relic account [XXXXXX] with IAM role [arn:aws:iam::0123456789012:role/NewRelicLambdaIntegrationRole_XXXXXX]. Enabling Lambda integration on the link between New Relic and AWS ✔️ Integration [id=1093110, name=Lambda] has been enabled in Cloud integrations account [New Relic AWS Integration - 0123456789012] of New Relic account [XXXXXX]. Creating the managed secret for the New Relic License Key Setting up NewRelicLicenseKeySecret stack in region: ap-northeast-1 Creating change set: NewRelicLicenseKeySecret-CREATE-xxxxx Waiting for change set creation to complete, this may take a minute... Waiting for change set to finish execution. This may take a minute... ✔️ Done Creating newrelic-log-ingestion Lambda function in AWS account Setting up 'newrelic-log-ingestion' function in region: ap-northeast-1 Fetching new CloudFormation template url Creating change set: NewRelicLogIngestion-CREATE-xxxxx Waiting for change set creation to complete, this may take a minute... Waiting for change set to finish execution. This may take a minute... ✔️ Done ✨ Install Complete ✨ 待っていたら終わった。スタックが3つ作られている。。。 ここまで終わると、次はこれだな。Step2はオプションだし、3は学ぶためっぽいから。 Step 4: Instrument your own Lambda functions 私は、SAMテンプートが既にあるから、そこに追加しよう。以下の部分を追加したら、デプロイ！ 環境変数 Layer ポリシー Environment: Variables: # For the instrumentation handler to invoke your real handler, we need this value NEW_RELIC_LAMBDA_HANDLER: app.lambdaHandler # Distributed tracing needs your account ID, and your trusted account ID NEW_RELIC_ACCOUNT_ID: YOUR_ACCOUNT_ID_HERE # If your New Relic account has a parent account, this value should be that account ID. Otherwise, just # your account id. NEW_RELIC_TRUSTED_ACCOUNT_KEY: YOUR_PARENT_ACCOUNT_ID_HERE Layers: # This layer includes the New Relic Lambda Extension, a sidecar process that sends telemetry, # as well as the New Relic Agent for Node.js, and a handler wrapper that makes integration easy. - !Sub arn:${AWS::Partition}:lambda:${AWS::Region}:451483290750:layer:NewRelicNodeJS12X:34 Policies: # This policy allows the lambda to know the value of the New Relic licence key. We need this so # that we can send telemetry back to New Relic - AWSSecretsManagerGetSecretValuePolicy: SecretArn: !ImportValue NewRelicLicenseKeySecret-NewRelic-LicenseKeySecretARN 動いた！ 画面の右側には、AWSマネジメントコンソールへのリンクもあり、簡単にアクセスが可能。 設定その２ よし、次はX-Rayだ！この手順で、わずか数クリックで接続が可能。 でも、これだけじゃ、実はダメ。私のテンプレートではLambda 関数の設定としてTracingがActiveになっていないこと、X-Rayを利用する権限がないことから、この両方を追加しデプロイしたら見事、連携されました。 Lambda環境変数 Environment: Variables: # For the instrumentation handler to invoke your real handler, we need this value NEW_RELIC_LAMBDA_HANDLER: app.lambda_handler # Distributed tracing needs your account ID, and your trusted account ID NEW_RELIC_ACCOUNT_ID: xxxxxx # If your New Relic account has a parent account, this value should be that account ID. Otherwise, just # your account id. NEW_RELIC_TRUSTED_ACCOUNT_KEY: xxxxxx 全関数に共通で付与するためGlobalsにTracingを追加 Globals: Function: Timeout: 20 Tracing: Active LayerはNew Relicさんが提供してくれるものをそのまま利用してます。 Layer Layers: # This layer includes the New Relic Lambda Extension, a sidecar process that sends telemetry, # as well as the New Relic Agent for Node.js, and a handler wrapper that makes integration easy. - !Sub arn:${AWS::Partition}:lambda:${AWS::Region}:451483290750:layer:NewRelicNodeJS12X:34 結果 関数の全体 関数内の詳細 よし、SNS/SQS/Kinesisは？というと、X-Rayと同じだ。数クリックで設定完了。 ということで、Kinesis /SQS/ SNSも無事、New Relicに連携しました。 キューのメッセージの状況も可視化されてますね。 まとめ New Relicを使ったことが無いとは言えないとおもって使い始めました。アカウントのセットアップからLambdaとの連携まで試してみましたが、特に困ることなくセットアップできました。 ただ、使いこなせたか？というと、単につないだだけなので、もっといろいろ面白い世界があるはず・・・。 また、そのうち試してみたいと思います。 そして、API Gatewayに毎秒アクセスするcurlコマンドを出し続けるとこうなります。お気を付けを。

抽出コマンド AWSリソースの整理中、SNSトピックやSQSキューのみを抽出するためのコマンドが必要になったので、備忘録として残しておきます。以下のコマンドのプロファイルのみ修正することで、トピックやキューのみを抽出することが出来ます。 aws sns list-topics --profile XXX | jq -r '.Topics[].TopicArn' | cut -f 6 -d ":" aws sqs list-queues --profile XXX | jq -r '.QueueUrls[]' | cut -f 5 -d "/" コマンド解説 解説するまでもないようなコマンドですが、インプットも兼ねて。 aws sns list-topics (--profile XXX) # SNSトピックを取得 aws sns list-topics --profile XXX 出力結果 { "Topics": [ { "TopicArn": "arn:aws:sns:ap-northeast-1:${AccountId}:${トピック名1}" }, { "TopicArn": "arn:aws:sns:ap-northeast-1:${AccountId}:${トピック名2}" }, // 以下省略 ] } このままだと上記のようにトピックがjson形式で出力されるため、jqコマンドを利用して整形を行う。 jq -r '.Topics[].TopicArn' "Topics"配列内の"TopicArn"の内容を取得する。更に、-rオプションによりダブルクウォーテーションを取り除く。 # SNSトピックを取得し、jqコマンドでTopicArnのみを抽出 aws sns list-topics --profile XXX | jq -r '.Topics[].TopicArn' 出力結果 arn:aws:sns:ap-northeast-1:${AccountId}:${トピック名1} arn:aws:sns:ap-northeast-1:${AccountId}:${トピック名2} //　以下省略 この時点でTopicArnのみを抽出することが出来たので、最後にcutコマンドを用いて${トピック名}のみを取得する。 cut -f 6 -d ":" -dオプションで区切り文字に「:」を指定し、-fオプションで6つ目のフィールドのみを抽出する。 # SNSトピックを取得し、jqコマンドでTopicArnのみを抽出し、cutコマンドでトピック名のみを取得 aws sns list-topics --profile XXX | jq -r '.Topics[].TopicArn' | cut -f 6 -d ":" 出力結果 ${トピック名1} ${トピック名2} //　以下省略 おわりに SQSキューの取得に関してもやってることはほぼ同じなのでコマンド解説は省略します。これくらいのワンライナーのシェルは何も見ないでスラスラ書けるようになりたいものです。

Amplifyコンソールからデプロイしようとしたところ、「保存してデプロイ」押下しても反応がなくデプロイが始まらない現象が発生したので調べてみました 開発者ツールで確認してみた 開発者ツールで確認してみると、https://amplify.ap-northeast-1.amazonaws.com/apps/xxxxxxxxというAPIでエラーが発生していました。 詳細を確認したところ、Environment variables cannot start with the reserved prefix \"AWS\".というエラーメッセージでした。 ↓のようにAWS関連の環境変数であることが分かるように"AWS_XXXXX"のような名称で登録していたために引っかかってしまったようです。 リファレンス見ても特に書いてない気がしますが、AmplifyコンソールがデフォルトでAWSから始まる環境変数を定義しているからですかね？ https://docs.aws.amazon.com/amplify/latest/userguide/environment-variables.html 対策 環境変数の名称を"AWS"から始まらない名称に変更しました。 最後に エラーが起きてることくらい画面に出してほしいですね。。 ビルドしてるのかな？って感じで10分くらい待ってみたり、3回くらい登録しなおしたりしてしまいました。

本記事は、サムザップ Advent Calendar 2021 の12/10の記事です。 はじめに この記事では、表題の通り億単位のレコード数のテーブルを含むDBをAWSのDMS（Database Migration Service）を使ってデータ移行する検証をしていた際に、時間が掛かり過ぎることが分かったので、それを解消するためにやったことを記載したいと思います。 普段はあまり使うことのないサービスだと思いますが、お引越し（オンプレ->クラウドやクラウドA->クラウドB）するときだけでなく、運用が長くなり、DBサーバーを統廃合するようなシチュエーションでも役に立つサービスだと思います。 弊社ではスマートフォン向けのゲームを数々運用してきましたが、運用が長くなり、ユーザーデータは増え続ける一方、アクセス数がピーク程ではななくなってきたサービス等において、DBサーバーを統廃合する際に重宝しています。 普段使わないだけに、いざやろうと思うと色々分からないことや躓きポイントがあったり、今回のように想定していた時間内にデータ移行が終わらない！！となって、困ることもあると思います。 少しでもそんな方々のお役に立てれば嬉しいです。 要約 データ移行時間を短縮するためにやったこと、その他各種Tipsを記載 タスクを分割する 特定のテーブルを別タスクに切り出す 更にそのタスクをfilterを使って分割する 用語 本記事では、基本的にDMSを利用したことがある方、利用しようとしてある程度ドキュメントを読んでいる方を対象としていますが、一応基本的なワードだけ簡単に説明します。 DMS データベースを AWS に迅速かつ安全に移行するためのサービス 引用元:https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/Welcome.html タスク データ移行の単位であり、それらの処理が行うもの・場所 AnAWSDatabase Migration Service (AWS DMS) タスクは、すべての処理が行われる場所です。ログ記録要件、制御テーブルデータ、エラー処理など、移行と特別な処理に使用するテーブル（またはビュー）とスキーマを指定します。 引用元:https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Tasks.html テーブルマッピング ソースフィルター ミッション 今回のミッションは、水平分割用に用意されたAuroraクラスターをメンテナンス時間10時間以内に半分にすること。 メンテナンス中にはその他作業もあるため、データ移行に当てられる時間は正味4時間くらい。 環境 Aurora MySQL エンジンバージョン:5.7.mysql_aurora.2系 経緯 とあるプロジェクトにおいて、DBサーバーの統廃合が遡上に登り、事前に実行時間を計測したところ、約6時間掛かることが分かりました。 メンテナンス時間を考慮すると、4時間以内に抑えたかったため、再度DBサーバー及びレプリケーションインスタンスをスケールアップし、4時間程度で完了できることを確認しました。 その後しばらくして運用中の各種施策のスケジュールを加味し、メンテナンス日時が確定し、改めてデータ移行を実施してみると… 6時間経っても終わらない！！状態になっていました。。 ということで、急ぎデータ移行時間を短縮する必要に迫られました。 確認したこと 多くはAWS様のドキュメントにまとまっており、そちらを参考にさせていただきました。 移行タスクの実行が遅くなる最も一般的な原因は、AWS DMSレプリケーションインスタンス。インスタンスのリソースが実行中のタスクのために十分であることを確認するには、レプリケーションのインスタンスの CPU、メモリ、スワップファイル、および IOPS の使用率をチェックします。 しかしいずれのリソースを確認しても特に問題があるように見えませんでした。 実施したこと そこで社内の他プロジェクトの方に相談し、どうやらタスクを分割すると速くなるという助言をもらいました。 元々は1DBスキーマ:1タスクという基本的な設定でしたが、これをテーブル単位に分割し、テーブルAはタスク1、テーブルBはタスク2…のような形（テーブルマッピング）にしました。 更にタスクのテーブル統計を確認したところ、レコード数が多い、もしくはデータ量の大きい一部のテーブルが突出して時間が掛かっていることが分かったため、ソースフィルターを使って１０００万レコードずつ別タスクに分割しました。 1DBスキーマ1タスクのルール 例1: Testスキーマ配下の全テーブルを対象とする場合 { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "Test", "table-name": "%" }, "rule-action": "include" } ] } テーブル毎にタスクを分割したルール 例2-1: Testスキーマ配下のtestテーブルのみを対象とする場合 { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "Test", "table-name": "test" }, "rule-action": "include" } ] } 例2-2: Testスキーマ配下のtestテーブル以外のテーブルを対象とする場合 { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "Test", "table-name": "%" }, "rule-action": "include" }, { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "Test", "table-name": "test" }, "rule-action": "exclude" } ] } ソースフィルターで更にテーブルを分割した図 例3: Testスキーマ配下のtestテーブル、かつid列の値が1〜10,000,000のレコードを対象とする場合 { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "Test", "table-name": "test" }, "rule-action": "include", "filters": [{ "filter-type": "source", "column-name": "id", "filter-conditions": [{ "filter-operator": "between", "value": "", "start-value": "1", "end-value": "10000000" }] }] } ] } ※例えば3億レコードあれば、start-valueとend-valueを変えて、30タスクの定義が必要 結果、データ移行自体は約2時間半程度で完了できるようになりました。 と、ここまでが今回の対応の主な内容となっています。 以下ここに到達するまでに試行錯誤した際のTIPSを記載します。 その他のTIPSや試したこと（試そうと思ったこと） timezoneに気をつける mysqlのtimestamp型は、システム変数time_zoneの影響を受けるため、ソースエンドポイント側のextra connection attributesにserverTimezone=Asia/Tokyo;を設定しないと、データ移行した際に-9時間でデータが生成されてしまいました。 ※逆にターゲットエンドポイント側に設定しても良いかも！？ ワイルドカード タスクのルールの定義内のobject-locator内のtable-nameは、状況によってワイルドカード（%）が使えたり、使えなかったりするので注意。 rule-typeがselectionで、かつrule-actionがincludeもしくはexcludeの場合は、ワイルドカードが使えると記載があり、実際使えるのですが、filters（ソースフィルタ）を指定した場合は使えないので注意。 タスクの起動数について タスクを多数に分割した結果、一度にタスクを起動すると、そもそもタスクが起動できず、失敗になるケースもありました。 再実行で正常に実行できましたが、エラー処理タスクの設定によっても挙動が変わると思いますので、同時起動するタスク数を調整した方が良いと思います。 同様にリソースを限界まで有効に使おうと、インスタンスタイプを調整したのですが、ある程度余裕がないと、途中でタスクが進捗しなくなり、最終的に失敗するケースがありました。 インスタンスタイプを変更する場合は、各種メトリクスや各DBのprocessの実行状況を確認し、ある程度余裕をもったインスタンスを用意することをオススメします。 （検証してから、本番までの間にもデータ量が増えると思いますし） MaxFullLoadSubTasks DMSには、上記のように手動でタスクを分割しなくてもタスク設定のFullLoadSettings内にMaxFullLoadSubTasksという設定があり、こちらを増やせば速度が上がりそうと思いましたが、レプリケーションインスタンスのコア数の2倍に設定しても、同じに設定しても変わらなかったので、コア数に合わせました。 まとめ AWS様のドキュメントにある通り、CPU、メモリ、スワップファイル、およびIOPSの使用率に問題がなく、スケールアップしてもデータ移行時間が短縮できない場合は、こちらで紹介したようにタスクを分割し、並列実行数を上げると劇的に速くなる場合があることが分かりました。 同じようにデータ移行の時間が長くて困っている方の一助となれば幸いです。 明日は @KoniroIris さんの記事です。

「AWS Amplify Studio」という機能の発表がありましたので、Amplifyのキャッチアップ自体もまだまだにもかかわらずとりあえず触ってみました。 以前に作成したアプリがあったので、開いてみたところ、「Studioを起動する」というボタンが出現していました。 クリックすると、以下のような画面が表示されました。 試しにDataを触ってみます。 目玉はUI libraryなのでしょうが。。。 Data クリックするとこのような画面となりました。 右上のDeploying...というところをクリックすると、プロビジョニングの進行状況が表示されます。 こんな感じに定義したのち、 Add a relationshipというところおからリレーションを設定してみました。 こんな風に設定出来るんですね。 Deployをクリックすると再度Deploying..となりました。 Deployが終わると当然環境も作成されていました。 GUIツールが導入された事により、一段とAmplifyでの開発の敷居が下がったと思います。 日本語ドキュメントの充実等、まだまだな部分はありますが今後に期待です。

概要 RDS Proxyをセットアップする手順を記載する なぜRDS Proxyを使わないといけないか LambdaからRDSへのアクセスはアンチパターンと言われています。（調べるまで知りませんでした） その理由は、Lambdaはリクエストごとに起動し、その都度RDSに対してコネクションを張ろうとするため、 コネクション上限を超えたLambdaからのアクセスはエラーとなってしまうためです。 Lambda起動の頻度が高いほどコネクションが多くなってしまうのですね。。。 lambdaが終了しても、コネクションが残ってしまい、接続数の上限に達してしまう 参考 AWS RDS Proxyについて https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html PostgreSQL関数lastvalを使用してはいけないw（Proxyを利用してるからしょうがない） PostgreSQLの一部バージョンに対応していない 10.10 and higher minor versions, and version 11.5 and higher minor versions 12, 13系に未対応なので、気をつける（2021年10月27日） https://stackoverflow.com/questions/67967745/rds-proxy-gives-empty-dropdown-for-database-when-using-rds-postgresql-13-2 使い方 https://aws.amazon.com/jp/blogs/news/using-amazon-rds-proxy-with-aws-lambda/ RDS Proxyについての記事 https://ichi-station.com/aws-rds-proxy-lambda-aurora/ https://sebenkyo.com/2020/11/04/post-1590/ https://qiita.com/curanosuke/items/9f17857efa24c138997f lambdaのコードをzipで圧縮してアップロード https://sig9.hatenablog.com/entry/2020/02/03/000000 前提 RDSにインスタンスとテーブルは作成されていること [検証用] RDSにインスタンスを作成し、テーブルの作成手順 ※ 起動の手順は省略 MySQL CREATE DATABASE stream_test; USE stream_test; CREATE TABLE `fruits` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL DEFAULT '', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; INSERT INTO `fruits` (name) VALUES ('orange'), ('apple'); PostgreSQL CREATE DATABASE stream_test; \c stream_test; CREATE TABLE "fruits" ( "id" SERIAL, "name" varchar(255) NOT NULL DEFAULT '' ); INSERT INTO "fruits" (name) VALUES ('strawberry'), ('banana'); 手順 シークレットマネージャーを登録する RDS Proxyを登録する Policyを作成する lambdaを登録する テストを実行する シークレットマネージャーを登録する RDS Proxyで利用されるuserとpasswordをシークレットマネージャーに登録 ユーザー名 パスワード データベース RDS Proxyを登録する プロキシ識別子: 任意 エンジンの互換性: 任意 Transport Layer Security が必要: PostgreSQLの場合は必須 データベース: 任意（PostgreSQLは、version 10 もしくは 11のみ対応） Secrets Manager シークレット: 前述のシークレット IAM ロール: IAMロールを作成 IAM 認証: 必須 サブネット　: （変更しない） Policyを作成する LambdaからRDS Proxyを参照できるPolicyを作成する タグ（任意） キー: Name 値 - オプション: 任意 名前: 任意（前述のタグと同じもの推奨） 説明: 任意( ex: Secret manager available in lambda ) JSON { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "secretsmanager:GetResourcePolicy", "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret", "secretsmanager:ListSecretVersionIds" ], "Resource": [ "{secretのARN}" ] } ] } lambdaを登録する "一から作成" を選択 関数名: 任意 ランタイム: Python3.8 （他の言語、バージョンでも良いが、今回利用するレイヤーが、3.8向けのものです） レイヤーの追加 Python3.8に対応したレイヤーを探して使う（2021年12月3日時点で、3.9向けのものは、このリポジトリでは準備されていない） PostgreSQLを利用したので、 psycopg2 を利用 今回は、こちらを参照 arn:aws:lambda:ap-northeast-1:770693421928:layer:Klayers-python38-aws-psycopg2:1 以下は他のサイトで見つけた psycopg2 arn:aws:lambda:ap-northeast-1:898466741470:layer:psycopg2-py38:1 設定 一般設定 タイムアウト: 30秒（任意です） IAMロール ポリシーの追加 前述で作成したPolcy AWSLambdaVPCAccessExecutionRole ※ kinesisを利用する場合は、AmazonKinesisFullAccessを追加 VPC VPC: RDSのあるVPC サブネット: 全て選択 セキュリティグループ: RDS Proxyと同じもの データベースプロキシ 既存のデータベースプロキシの選択: 前述のRDS Proxy データベースプロキシ追加後、IAMロール RDS ProxyのPolicyがあるか確認 ex) AWSLambdaRDSProxyExecutionRole-12345678-1234-1234-1234-123456789012 lambda登録 import json import os import sys import boto3 import psycopg2 import base64 # PostgreSQL Connection def connect(): ENDPOINT="{前述のRDS Proxyのエンドポイント}" PORT="5432" USR="{前述のRDS Proxyに登録したユーザ}" REGION="ap-northeast-1" DATABASE="{任意のデータベース名}" client = boto3.client('rds') token = client.generate_db_auth_token(DBHostname=ENDPOINT, Port=PORT, DBUsername=USR, Region=REGION) con = psycopg2.connect(host=ENDPOINT, database=DATABASE, user=USR, password=token) return con # EXECUTE SELECT def select_execute(con, sql, values): print(sql) with con.cursor() as cur: cur.execute(sql, values) records = cur.fetchall() return records def lambda_handler(event, context): con = connect() sql = 'SELECT COUNT(1) AS count FROM fruits' records = select_execute(con, sql, []) return { 'statusCode': 200, 'body': f"calllog_id: {records[0][0]}" } テストを実行する fruitsの個数が表示されれば、正常に完了です。 Test Event Name test1 Response { "statusCode": 200, "body": "fruits count: 2" } Function Logs START RequestId: 6f6d853f-e213-41e4-a75c-fc6f1a927238 Version: $LATEST SELECT COUNT(1) AS count FROM fruits END RequestId: 6f6d853f-e213-41e4-a75c-fc6f1a927238 REPORT RequestId: 6f6d853f-e213-41e4-a75c-fc6f1a927238 Duration: 1437.65 ms Billed Duration: 1438 ms Memory Size: 128 MB Max Memory Used: 74 MB Init Duration: 330.97 ms Request ID 6f6d853f-e213-41e4-a75c-fc6f1a927238

経緯 CloudFront+S3ではURLがディレクトリまでしかない場合は404エラーになります。つまり、 http://hogehoge.com の場合には index.html が表示されますが、 http://hogehoge.com/subdir/ の場合には index.html が表示されずに 404エラーになる訳です。 その解決方法として既に多くの記事で Lambda@edge を使って http://hogehoge.com/subdir/ （末尾にスラッシュあり） の場合に index.html を表示させる方法が紹介されていますが、http://hogehoge.com/subdir （末尾にスラッシュなし）の場合CSSやJSのパス当たらないなど、うまく動かなかったので、備忘録も兼ねて記事を書くことにしました。 方法を先に言ってしますと、スラッシュ（/）無しの場合にはスラッシュ（/）ありに301リダイレクトさせるというものです。 まずはLambda@edgeを用意しましょう。 2021/12現在、Lambda@edgeはバージニア北部リージョンしか利用できないので、バージニア北部リージョンに変更します。そこでLambda関数を新規で作成して、以下のコードを記述します。 Lambdaのコード 見てのとおり、内部で301リダイレクトしています。 exports.handler = (event, context, callback) => { const request = event.Records[0].cf.request; // スラッシュで終わらず拡張子がない場合はディレクトリとみなして末尾にスラッシュを付けるてリダイレクト if (!request.uri.match(/\/$/)) { const names = request.uri.split('/'); // ディレクトリ名に「.」が含まれるケースについては考慮外とする if (!names[names.length - 1].match(/.+\..+/)) { request.uri = request.uri.replace(/$/, '/'); const response = { status: 301, statusDescription: "Permanenoly Add", headers: { location: [{ key: 'Location', value: request.uri }] } }; return callback(null, response); } } // 末尾がスラッシュで終わっている場合はindex.htmlを付加する request.uri = request.uri.replace(/\/$/, '/index.html'); return callback(null, request); }; トリガーに使っているリージョンにCloudFrontを指定 次にLambdaの「トリガーを追加」をクリックして、自分の使っているリージョン（バージニア北部でなくてもOK）のCloudFrontを指定します。 以下のようなエラーが出るときがあります。 InvalidLambdaFunctionAssociationException: The function execution role must be assumable with edgelambda.amazonaws.com as well as lambda.amazonaws.com principals. Update the IAM role and try again. この場合には、Lambdaの設定＞アクセス権限＞該当の実行ロールをクリックしてロールの編集画面にいき、 ロール編集画面から「信頼関係」タブを選択し「信頼関係の編集」ボタンをクリックして、ポリシードキュメントを以下に変更してください。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "edgelambda.amazonaws.com", "lambda.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } その後、CloudFrontのキャッシュを削除して完了です。 http://hogehoge.com/subdir にアクセスして、http://hogehoge.com/subdir/ にリダイレクトされ、 index.htmlの内容が表示されれば成功です。 Basic認証をかけたいとき 余談ですが、Basic認証をかけたいときにはLambda関数は以下のコードになります。 exports.handler = (event, context, callback) => { const request = event.Records[0].cf.request; // スラッシュで終わらず拡張子がない場合はディレクトリとみなして末尾にスラッシュを付けるてリダイレクト if (!request.uri.match(/\/$/)) { const names = request.uri.split('/'); // ディレクトリ名に「.」が含まれるケースについては考慮外とする if (!names[names.length - 1].match(/.+\..+/)) { request.uri = request.uri.replace(/$/, '/'); const response = { status: 301, statusDescription: "Permanenoly Add", headers: { location: [{ key: 'Location', value: request.uri }] } }; return callback(null, response); } } //末尾がスラッシュで終わっている場合はindex.htmlを付加する request.uri = request.uri.replace(/\/$/, '/index.html'); //Basic認証処理 const headers = request.headers // ユーザー名とパスワードを設定 const authUser = 'username' const authPass = 'password' const authString = 'Basic ' + new Buffer(authUser + ':' + authPass).toString('base64') // 初アクセス or 認証NG if (typeof headers.authorization === 'undefined' || headers.authorization[0].value !== authString) { callback(null, { status: '401', statusDescription: 'Unauthorized', body: '<h1>401 Unauthorized</h1>', headers: { 'www-authenticate': [{key:'WWW-Authenticate', value:'Basic'}] } }) } // 認証OK else{ callback(null, request) } }; さらに複数のID/PWでBasic認証をかけたいときには以下のコードになります。 exports.handler = (event, context, callback) => { const request = event.Records[0].cf.request; // スラッシュで終わらず拡張子がない場合はディレクトリとみなして末尾にスラッシュを付けるてリダイレクト if (!request.uri.match(/\/$/)) { const names = request.uri.split('/'); // ディレクトリ名に「.」が含まれるケースについては考慮外とする if (!names[names.length - 1].match(/.+\..+/)) { request.uri = request.uri.replace(/$/, '/'); const response = { status: 301, statusDescription: "Permanenoly Add", headers: { location: [{ key: 'Location', value: request.uri }] } }; return callback(null, response); } } //末尾がスラッシュで終わっている場合はindex.htmlを付加する request.uri = request.uri.replace(/\/$/, '/index.html'); //Basic認証処理（複数版） const headers = request.headers; // Configure authentication var authUsers = [ { 'user':'username1', 'pass':'password1', }, { 'user':'username2', 'pass':'password2', }, ]; var authString = ''; // Require Basic authentication if (typeof headers.authorization != 'undefined') { authUsers.forEach(function(authUser){ // Construct the Basic Auth string authString = 'Basic ' + new Buffer(authUser.user + ':' + authUser.pass).toString('base64'); if (headers.authorization[0].value == authString) { // Continue request processing if authentication passed callback(null, request); } }); } // Reject request const body = 'Unauthorized'; const response = { status: '401', statusDescription: 'Unauthorized', body: '<h1>401 Unauthorized</h1>', headers: { 'www-authenticate': [{key: 'WWW-Authenticate', value:'Basic'}] }, }; callback(null, response); }; 参考にしたサイト https://qiita.com/nwsoyogi/items/6ccea086ddac98bb8af1 https://higelog.brassworks.jp/2955

タイトル通りの覚書です。 import boto3 from botocore.config import Config #-- 1.proxy definitions proxy_definitions = { 'http': 'http://xxxx.com:xxxx', 'https': 'https://xxxx.com:xxxx' } #-- 2.set config my_config = Config( region_name='us-east-1', proxies=proxy_definitions ) #-- 3.boto3 client client = boto3.client('kinesis', config=my_config) 1でプロキシアドレス入力して，2で設定をして，clientを呼び出すときにconfigを引数として入力。 リージョン名もConfig内で指定可能。

はじめに この記事は弥生 Advent Calendar 2021の4日目の記事です。 弥生の開発組織としての取り組みや文化において、コンフォートゾーンからラーニングゾーンへ促す仕組みがいくつか取り入れているなと思ったので、それを記事にしてみました。 自己紹介 はじめまして、弥生でプロジェクトマネージャーをしている飯田といいます。弥生に入社して5年目になります。 自分に甘々な性格ですが、あれこれ工夫して半年で12キロ痩せれたことが最近のトピックです。リモートワーク中なので妻以外に気付かないですが。。 弥生のプロジェクトマネージャーのお仕事 まずは簡単に弥生PMの代表的な仕事を紹介します。 プロジェクト・プロダクトの目標達成にフォーカスしたマネジメントを行う マーケティング部門、カスタマーサービス部門とも調整したうえで、より実現性の高い（遅れない）ロードマップを策定し、その実現のためにあらゆる手段を講じる 開発本部組織改善の検討・策定を実行し、成果を出すこと 開発本部員エンゲージメントに対する取り組みで成果を出すこと 弥生の開発のいま 弥生の開発本部はいま大きな転換期を迎えています。私が所属するのは次世代プロダクト開発という部署です。この部署はお客さまのために新たなサービスを世に送り出すことを目的に立ち上がった部署になります。2年前に数名から立ち上がり、今では50名を超える体制となりました。しかし、お客さまにより素晴らしい製品体験をしてもらうためには、組織としてはもちろん、個々のスキルを上げていくことも非常に重要な要素になります。 コンフォートゾーンとは この言葉を知っていますでしょうか？ビジネス書などでもたまに見かけると思いますが、居心地のいい快適な環境を意味します。 たとえば、毎日決まった業務をこなす仕事、長い付き合いで楽な人間関係などそれほど刺激がないかわりにリスクを感じることがない場所で、それがコンフォートゾーンです。 ただし、これらの環境は成長するうえでは必ずしもいいとはいえません。ひとはある程度のストレスを感じる環境に置かれた方が高い能力を育み発揮することができると言われています。でも楽で居心地のいい場所にい続けたいのは本能ですよね。楽な道と大変な道があれば楽な道を選ぶのは当たり前だと思います。 ラーニングゾーンとは 適度なストレスと高い学習効果が得られる環境のことで、人間が磨かれるのはまさにこの環境だと言われています。 適度なストレス環境に身を置くことは決して難しいことではないとも言われています。日常生活においてもわずかな視点の切り替えによって成長のチャンスを得ることが可能です。例えば気になるイベントを見つけたら迷わず参加ボタンを押す、これもコンフォートゾーンから抜け出す方法のひとつかと思います。 弥生でもよく業務中にITイベントに参加することも多いです。最近ではAWS関連のイベントに参加するメンバーが多いと思います（ちなみに参加結果のレポート提出などは不要です） 適度な負荷：学びを促す人員配置 弥生にはこのコンフォートゾーンを抜け出してラーニングゾーンへ進むための仕組みがいくつか組み込まれています。例えば人員配置です。 私個人の入社してからの配置異動を例にとります。 1年目：情報システム部門で契約・請求関連のシステムを担当 2年目：製品サービス部門に移籍し、弥生販売を担当 3年目：弥生販売に加えてデスクトップアプリ共通機能を担当 4年目：次世代プロダクト開発部門へ移籍、同部門の統括リーダーと共に組織戦略を策定し、アーキテクチャチームとインボイスチーム同時に立ち上げ。また、製品サービスと基幹システムをつなぐ認証認可サービスを担当 5年目：前年から引き続き、認証認可サービスを担当　←いまここ 弥生では、慣れてきたら新しいことをどんどんやってもらうという文化があります。 当然、本人適性や組織観点も考慮しますが、けっこう希望したプロジェクトに携わることができます。ただ、上記のように1年でそのプロジェクトに慣れて成果を出すのは普通に考えるとまぁまぁ大変かなと思います。 しかし、弥生のプロジェクトは前任者の引継ぎ・伴走がしっかりしているし、過去の経緯や目的はチケットに記載されているので、これまでの背景や段取りを知ることにもそれほど苦労をしません。 弥生はチケットでタスク管理を実施しており、基本、全てのプロジェクト作業はチケットを見ればわかるようになっています。ときおり、数年前のチケットをみて、当時の成果物や経緯を確認することがありますが、知りたかったことについて、よくわからないで終わるということは基本ありません。 DevAX：学びの機会 また、弥生はエンジニアにも学習を奨励していますし、そういった機会を積極的に設けるような取り組みがあります 直近ではDevAXというAWSハンズオンワークショップを実施しました。全8回のワークショップを毎週水曜日に終日開催する、一過性で終わらないものです。しかも100名規模での開催というAWS内でも類のない規模で開催されました。詳細は弥生の勉強会イベント「もくテク」で紹介する予定なのでぜひご参加ください。 AWSアカウントの無償提供：学びのハードルを下げる また、最近ではAWSアカウントの無償貸し出しも開始しました。自分が自由に使える環境で利用料を気にせず、学習したいという欲求はエンジニアの皆さんはだれしも抱えているかと思います。当然、マイニングしないでね、みたいなざっくりルールはありますが、基本は個人が自由に業務に関係なくAWSを触れる環境を提供しています。 大事なのはスモールステップ 大切なのは最初のステップを小さく、そして継続して学習できる仕組み作りかと思います。 開発本部の組織改善、エンゲージメントを高めるためにいくつもの取り組みをどんどん実施し、最終的にお客さまにいいサービスを届けることにつなげていきたいと思います。 興味を持った方はよかったら下記を見てみてください。 弥生では一緒に働く仲間を募集しています。

今日はAWSの「世にも奇妙な物語」を語ってみたいと思います。 マニアックな話なので、あまり知られていないネタです。 2021年アドベントカレンダーとして今年を振り返りつつ、AWSで知っておいた方が良い豆知識も散りばめていますので、ぜひ最後までご覧ください。 はじめに。AWSのアベイラビリティゾーンとは？ AWSとは？ AWS（Amazon Web Services）はご存じでしょうか。 TV放送の裏側にTV局や電波塔があるように、皆さんが毎日使っているスマホアプリやWebサービスの裏側には「ITインフラ」があります。そのITインフラを置いておく場所として、最近はパブリッククラウドが多く採用され、AWSはその中でトップシェアのクラウドサービスです。 （皆さん毎日AWSを使っているはずなのに全く見えません。目に見えないものを説明するのは本当に難しいです。説明するたびに全然伝わってない空気を感じるので、上記説明がピンと来なかったとしても許してください...笑） アベイラビリティゾーンとは？ AWS グローバルインフラストラクチャ | AWS より 2021年12月現在 ご覧のようにAWSは世界中に展開しており、多数のリージョンでAWSのサービスが提供されています。リージョン（Region）は「地域」という意味の英語で、東京・大阪・ロンドン・パリなど、AWSのサービスを利用できる地域を表しています。 1つのリージョンはさらに複数のアベイラビリティゾーン（Availability Zone、略してAZ）で構成されます。AZは多数のコンピュータやネットワーク機器が置かれたデータセンターを指しています。物理的に離れたAZを複数使うことで、どこかのAZが障害でダウンしても、他のAZで補い合う「冗長化」と呼ばれる構成になっています。 ここだけの話。実は所在地がバレちゃってる？ データセンターをご覧になったことはありますか？ 表札がなく（もしくは全然関係ない表札がついた）、窓のない、屋上に空調の室外機がやたらたくさんある、謎の建物です。室内はコンピュータを24時間365日稼働し続けることを優先にしているため、年中寒く、空調やコンピュータの音でうるさい異様な空間です。 個人情報が多数保管されていたり、テロリストの攻撃(?)によってサービスを止めないために、所在地が公開されないことの多い建物です。ところがAWSのデータセンターの所在地が暴露されたことがあり、興味ある方は WikiLeaksがAWSのデータセンター所在地を暴露したので詳細を見る - Qiita をご覧ください。 Googleマップでご覧になると、どんな建物か分かると思います。私もインフラエンジニアの頃は自社のデータセンターに良く行っていましたが、クラウドエンジニアになるとAWS管理になるのでもう行くことはなくなりました。ちょっと寂しいですね...。 本題。あなたが使っているAZ-Aと私が使っているAZ-Aが違う？ ようやく本題に入りますが、例えば東京リージョンにはAZが「A」と「C」と「D」の3つあります。実は昔契約された方は欠番の「B」も使えるので4つ見えています。 AZ ID まずAZには固有のIDが振られています。このID自体は2018年に公開されました。それまでは秘密だったんですね。 AZ ID 所在地（公開されていないので仮です） apne1-az1 東京都 ○○市 ×××× apne1-az2 神奈川県 △△市 ×××× apne1-az3 千葉県 □□市 ×××× apne1-az4 埼玉県 ☆☆市 ×××× この組み合わせは誰にとっても同じ、つまりあなたも私も同じです。 当たり前に聞こえますが...。 ちなみに「apne1」は東京リージョンを表していて、「Asia アジア」「Pacific 太平洋」地域の「North 北」「East 東」にある「1」番目のリージョンという意味です。世界では5番目、震災の直前2011年3月2日にサービスを開始しましたので、今年で10周年となりました。 AZ Name ただ普段AZ IDは使いません。使うのはAZの名前です。 AZ Name ap-northeast-1a ap-northeast-1b ap-northeast-1c ap-northeast-1d 「ap-northeast-1」が先ほどの通り、東京リージョンを表していて、その中にa～dという名前のAZがあるわけです。よく「1a」や「1c」をAZの名前として書かれている方が多いですが、「1」はリージョン名の一部なので、正確には「a」～「d」がAZを表しています。「AZ-A」と書くか「ap-northeast-1a」と略さずに書くのが望ましいでしょう。 ややこしいのが次ですね。AZ IDとAZ Nameの組み合わせは、AWSアカウント（簡単に言うとAWSの契約者）ごとに違うんです！ 例えばあなたは AZ ID 所在地（公開されていないので仮です） AZ Name apne1-az1 東京都 ○○市 ×××× ap-northeast-1a apne1-az2 神奈川県 △△市 ×××× ap-northeast-1b apne1-az3 千葉県 □□市 ×××× ap-northeast-1c apne1-az4 埼玉県 ☆☆市 ×××× ap-northeast-1d のような組み合わせかもしれませんが、私は AZ ID 所在地（公開されていないので仮です） AZ Name apne1-az1 東京都 ○○市 ×××× ap-northeast-1c apne1-az2 神奈川県 △△市 ×××× ap-northeast-1d apne1-az3 千葉県 □□市 ×××× ap-northeast-1b apne1-az4 埼玉県 ☆☆市 ×××× ap-northeast-1a の組み合わせで使っています。 つまり あなたは東京都のデータセンターを「AZ-A (ap-northeast-1a)」と思って使っていて、私は埼玉県のデータセンターを「AZ-A」と思って使っている という状況です。同じ「AZ-A」なのに別の世界を見ているんですね。 このネタは個別指導の中でもご説明していますが、皆さん最初聞いた時はキツネにつままれた感じになります 笑 公式ドキュメントのリンクも貼り付けておきます。日本語版は機械翻訳で変だったので英語版です。 参考：Availability Zone IDs for your AWS resources - AWS Resource Access Manager で、気にした方がいいことはあるの？ 普段はAZ-Aが物理的にどこにあるか？ AZ IDが何か？ といったことは全く気にせず、使っています。AWSアカウントによって組み合わせが違うなんてことも知らなくて全く影響ありません。 恐らくAWSの狙いとしては、負荷がどこかのデータセンターに偏らないように（例えばA～Dの中で、皆さん最初にAを使ったり、Dを使わなかったりすることが多いので偏らないように）するための仕組みなのでしょう。 ただ唯一知っておいて良かったというケースは、AWSで大規模な障害が発生した場合です。今年も2021年2月19日に「az1」で冷却システムの故障により、一部で室温が上昇し、大規模な障害が発生しました。 参考：2021年2月19日23時50分頃に発生したAWS障害について | クラスメソッド 参考：今までに起こった AWS 障害情報履歴 | kubalog 「az1」ということは、あなたは「AZ-A (ap-northeast-1a)」で障害が起きたと認識し、私は「AZ-C (ap-northeast-1c)」で障害が起きたと認識することになります。そう、Twitterや世間では「AZ-A」でも「AZ-C」でも、人によっては「AZ-B」でも「AZ-D」でも障害が起きたと騒がれることになります。 落ち着いてください。同時多発テロが起きたわけではありません。障害が起きたのは物理的に1か所のデータセンター（AZ ID: az1）だけです。そのカラクリはもうお分かりでしょう。 最後に。自己紹介 「駆け出しエンジニアの頼れるお兄さん」という肩書きで、フリーランスエンジニアの傍ら、AWSの個別相談や個別指導をしているルビコン（@RubiconLink）と申します。インフラエンジニア歴14年・AWSクラウドエンジニア歴6年です。 今年、メンターマッチングサービスのMENTAでは上位1%のゴールドメダルを獲得し、AWSのYouTubeで有名なくろかわこうへいさんのCloudTechでは公認メンターを任せて頂きました。 最近はYouTubeチャンネルも始めました（ https://youtube.com/RubiconLink ） AWSを学び、転職・フリーランス独立を有利に進めたい方は、ぜひフォロー・チャンネル登録頂けると嬉しいです！ 独り言 最近世の中おかしいなと感じることが多いです。この投稿のように世の中の同じ事象を見ても、人によって全く違う世界を見ている（正反対にすらなる）ことが増えた気がします。 世の中、個人でも組織でも情報発信者は自分に有利なことしか主張せず、本当のことは隠されます。目立つ意見は参考にしつつも、自分の頭で本当はどうなのか考えたり、どなたの意見を参考にするかは慎重に見極めたいです。

はじめに 先日 AWS re:Invent 2021 セッションにて発表された Amazon Personalize の新機能についてまとめていきます。 アップデート履歴は以下公式ドキュメントにあります。 https://docs.aws.amazon.com/personalize/latest/dg/document-history.html 関連記事 【Amazon Personalize】Part.1 概要、データセットの要件 【Amazon Personalize】Part.2 映画レコメンデーション作成のデモ 1. 非構造化テキストデータに対応 製品データセットにおいて、商品の説明や商品レビューなどの非構造化テキストデータから情報を抽出できるようになりました。（英語のみ） 詳細：https://docs.aws.amazon.com/personalize/latest/dg/items-datasets 2. 類似アイテムレシピの推奨 アイテム間の類似性をより正確に識別するために、新しい類似性アルゴリズムが追加されました。 インタラクションデータとアイテムメタデータの両方に基づいて、指定したアイテムに類似するアイテムのレコメンドが生成されます。 詳細：https://docs.aws.amazon.com/personalize/latest/dg/native-recipe-similar-items.html 3. ビジネス指標のための最適化 新たにビジネス指標の設定が可能になり、収益や利益率などの指標を考慮しながら推奨項目をレコメンドすることができるようになりました。 詳細：https://docs.aws.amazon.com/ja_jp/personalize/latest/dg/optimizing-solution-for-objective.html 4. ユーザーセグメンテーションレシピ（今回初公開の機能） ユーザーの行動データを分析し、機械学習を使用してよりインテリジェントなユーザーセグメントを構築できるようになりました。 この機能を使用すると、特定のアイテムまたはジャンル、製品カテゴリ、ブランドなどのアイテム属性に対するユーザーの親和性に基づいてユーザーをセグメント化できます。 特定の映画を視聴したり、ブランドごとに特定の製品を購入したりする可能性が最も高いユーザーを対象としたマーケティングキャンペーンを作成したい場合などに使用することができます。 詳細：https://docs.aws.amazon.com/personalize/latest/dg/user-segmentation-recipes.html 5. ドメインデータセットグループ（今回初公開の機能） メディア・eコマースなどの一般的なユースケースに最適化されたレコメンダーを選択できるようになりました。 詳細：https://docs.aws.amazon.com/personalize/latest/dg/domain-dataset-groups.html 5-1. メディア・エンターテインメントに最適化されたレコメンド あなたにおすすめ 過去に視聴した X からおすすめ より Y に類似に似たもの Hot picks 5-2. 小売りに最適化されたユースケース あなたにおすすめ 同じ商品を見たユーザー よく一緒に購入されるもの 最も見られているもの ベストセラー

まずはじめに 今回、AWS認定試験であるAdvanced Networking Specialtyに合格しましたので受験記を記録として残しておきます。 今後受ける方の参考になりますと幸いです。 スコア 　　 　　　　　　　試験名 　点数 　 AWS Certified Advanced Networking - Specialty 890 受験歴 2020年の7月から取得を始めて1年と4か月ほどで12冠まで辿り着きました。 今回受けたANSが最後の試験となります。 世の中には数か月で全冠する猛者も沢山いるので自分はマイペースにやってきた方かと思います。 　　　　　　　　　試験名 　受験日 　 受験回数 AWS Certified Cloud Practitioner 2020-07-23 1 AWS Certified Solutions Architect - Associate 2020-11-19 1 AWS Certified SysOps Administrator - Associate 2020-12-23 1 AWS Certified Alexa Skill Builder - Specialty 2021-03-18 1 AWS Certified Developer - Associate 2021-06-16 1 AWS Certified DevOps Engineer - Professional 2021-07-19 1 AWS Certified Security - Specialty 2021-08-13 1 AWS Certified Solutions Architect - Professional 2021-09-13 1 AWS Certified Database - Specialty 2021-10-15 1 AWS Certified Data Analytics - Specialty 2021-10-29 1 AWS Certified Machine Learning - Specialty 2021-11-15 1 AWS Certified Advanced Networking - Specialty 2021-11-29 1 難易度 あくまで個人の感想ですが以下の様な立ち位置になるかと思います。 DASとMLSに関しては普段業務とは関わりのない分野でありゼロスタートであったため難易度が高かったと思います。 CLF<SOA<DVA<SAA<AXS<SCS<DBS<DOP<ANS<SAP<DAS<MLS 使用した教材と勉強方法 公式のサンプル問題 ・本番でも類似した問題などが出題される事があるため、ANSに限った話ではなくその他の試験でも1度解いておくのはオススメ。 Web問題集で学習しよう ・まずここを1周して出題傾向を確認しつつ、1問解く毎に答えが表示されるためすぐに見直しができる為、オススメです。 Udemy AWS Certified Advanced Networking - Specialty Practice Test ・Web問題集で学習した内容が理解できるか再学習も兼ねて1周します。 Whizlabs AWS Certified Advanced Networking Specialty ・Freeの問題だけを最近はサンプル問題と同じような用途で腕試しとして使用します。 ・問題は英語ですがChromeの翻訳機能を使用すれば問題無く解くことができます。 AWS Certified Advanced Networking – Speciality (ANS-C00) Exam Learning Path ・試験の出題傾向が見やすく網羅的にまとめられているので最終の見直しとして使用します。 基本的な流れとしては以下、 Web問題集→Udemyを1通りやる→Whizlab→公式のサンプル問題で腕試し→Learning Pathでポイントの再確認 こちらも分かりやすかったので視聴しました。 所感 基本的にTransitGatewayやRoute53 Resolverは出てくる前の話。 なので代わりにEC2インスタンスを立てて代用する必要がある。 DirectConnectやVPNについては深い理解が必要。 Route53の位置情報ルーティングポリシーと地理的近接性ルーティングポリシーの違いを問われるが勘違いしやすいので要チェック。 BGPコミュニティの範囲を問う問題やルーティングポリシーの優先度なども出るので覚えておくこと。 https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/routing-and-bgp.html EC2のMTUや拡張ネットワーキングについての理解も必要。 DirectConnectを使用することで課金される料金についての理解が必要。 DirectConnectでBFDを有効化するために必要なものを理解しておくこと https://aws.amazon.com/jp/premiumsupport/knowledge-center/enable-bfd-direct-connect/ AWS CloudHSM クラスターについて理解しておくこと ヒント：https://docs.aws.amazon.com/ja_jp/cloudhsm/latest/userguide/clusters.html NATGWでErrorPortAllocation エラーが出る際の解決策 https://aws.amazon.com/jp/premiumsupport/knowledge-center/vpc-resolve-port-allocation-errors/ DVAレベルの基本的なCloudFormationの理解 CloudFrontとLambda@Edgeのユースケースの理解 EC2メタデータの仕様と利用方法の理解 LOA-CFAの取り扱いや構築時の流れについての理解が必要 https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/create-connection.html#create-connection-loa-cfa

まずはじめに 今回、AWS認定試験であるAdvanced Networking Specialtyに合格しましたので受験記を記録として残しておきます。 今後受ける方の参考になりますと幸いです。 スコア 　　 　　　　　　　試験名 　点数 　 AWS Certified Advanced Networking - Specialty 890 受験歴 2020年の7月から取得を始めて1年と4か月ほどで12冠まで辿り着きました。 今回受けたANSが最後の試験となります。 世の中には数か月で全冠する猛者も沢山いるので自分はマイペースにやってきた方かと思います。 　　　　　　　　　試験名 　受験日 　 受験回数 AWS Certified Cloud Practitioner 2020-07-23 1 AWS Certified Solutions Architect - Associate 2020-11-19 1 AWS Certified SysOps Administrator - Associate 2020-12-23 1 AWS Certified Alexa Skill Builder - Specialty 2021-03-18 1 AWS Certified Developer - Associate 2021-06-16 1 AWS Certified DevOps Engineer - Professional 2021-07-19 1 AWS Certified Security - Specialty 2021-08-13 1 AWS Certified Solutions Architect - Professional 2021-09-13 1 AWS Certified Database - Specialty 2021-10-15 1 AWS Certified Data Analytics - Specialty 2021-10-29 1 AWS Certified Machine Learning - Specialty 2021-11-15 1 AWS Certified Advanced Networking - Specialty 2021-11-29 1 難易度 あくまで個人の感想ですが以下の様な立ち位置になるかと思います。 DASとMLSに関しては普段業務とは関わりのない分野でありゼロスタートであったため難易度が高かったと思います。 CLF<SOA<DVA<SAA<AXS<SCS<DBS<DOP<ANS<SAP<DAS<MLS 使用した教材と勉強方法 公式のサンプル問題 ・本番でも類似した問題などが出題される事があるため、ANSに限った話ではなくその他の試験でも1度解いておくのはオススメ。 Web問題集で学習しよう ・まずここを1周して出題傾向を確認しつつ、1問解く毎に答えが表示されるためすぐに見直しができる為、オススメです。 Udemy AWS Certified Advanced Networking - Specialty Practice Test ・Web問題集で学習した内容が理解できるか再学習も兼ねて1周します。 Whizlabs AWS Certified Advanced Networking Specialty ・Freeの問題だけを最近はサンプル問題と同じような用途で腕試しとして使用します。 ・問題は英語ですがChromeの翻訳機能を使用すれば問題無く解くことができます。 AWS Certified Advanced Networking – Speciality (ANS-C00) Exam Learning Path ・試験の出題傾向が見やすく網羅的にまとめられているので最終の見直しとして使用します。 基本的な流れとしては以下、 Web問題集→Udemyを1通りやる→Whizlab→公式のサンプル問題で腕試し→Learning Pathでポイントの再確認 こちらも分かりやすかったので視聴しました。 所感 基本的にTransitGatewayやRoute53 Resolverは出てくる前の話。 なので代わりにEC2インスタンスを立てて代用する必要がある。 DirectConnectやVPNについては深い理解が必要。 Route53の位置情報ルーティングポリシーと地理的近接性ルーティングポリシーの違いを問われるが勘違いしやすいので要チェック。 BGPコミュニティの範囲を問う問題やルーティングポリシーの優先度なども出るので覚えておくこと。 https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/routing-and-bgp.html EC2のMTUや拡張ネットワーキングについての理解も必要。 DirectConnectを使用することで課金される料金についての理解が必要。 DirectConnectでBFDを有効化するために必要なものを理解しておくこと https://aws.amazon.com/jp/premiumsupport/knowledge-center/enable-bfd-direct-connect/ AWS CloudHSM クラスターについて理解しておくこと ヒント：https://docs.aws.amazon.com/ja_jp/cloudhsm/latest/userguide/clusters.html NATGWでErrorPortAllocation エラーが出る際の解決策 https://aws.amazon.com/jp/premiumsupport/knowledge-center/vpc-resolve-port-allocation-errors/ DVAレベルの基本的なCloudFormationの理解 CloudFrontとLambda@Edgeのユースケースの理解 EC2メタデータの仕様と利用方法の理解 LOA-CFAの取り扱いや構築時の流れについての理解が必要 https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/create-connection.html#create-connection-loa-cfa

この記事はレコチョク Advent Calendar 2021の5日目の記事となります。 自己紹介 こんにちは。 株式会社レコチョクでサーバーサイドエンジニアをしている原です。 弊社では音楽サービスを提供しているので、自己紹介として自分の好きな音楽について少し話そうと思います。 好きなジャンルは、シューゲイザー、叙情/激情/ポエトリーリーディングバンド、J-ロックなどいろいろです。 好きなアーティストは、クレナズム、Fall of Tears、amazarashi、mol-74などなどが好きです。もちろん音楽を聴くときは弊社のサービスを利用しています。 小さい頃からいろいろな音楽を聴いているので、他にも好きなアーティストや曲はあるのですが、長くなるのでこの辺にしようと思います。 はじめに 私は、今年2021年10月1日にリリースされた新サブスクリプション音楽配信サービスである TOWER RECORDS MUSIC の開発に携わっています。 そして、上記サービスのリリース前負荷テストとして、AWSの負荷テストソリューションである Distributed Load Testing on AWSを利用しました。 本記事では、Distributed Load Testing on AWS を使ってみて、どんなところが便利だったのかを簡単にお伝えできたら良いなと思っています。 それでは、よろしくお願いします。 JMeterを用いた負荷テスト 早速、 Distributed Load Testing on AWS の説明をしていこうかと思ったのですが、 以前利用していたJMeterを比較対象とする方が話を進めやすいので、先にJMeterについて説明させていただきます。 負荷テストツール JMeter について JMeterは、Apacheソフトウェア財団が開発しているオープンソースの負荷検証ツールです。 負荷テストのツールとしては、定番なのかなと思います。 ただ、JMeterで負荷テストをする時に気をつけなければいけないことがあります。 それが、JMeterにはGUIとCUIで負荷テストを実行できるのですが、GUIで負荷テストをすると正しい結果が得られない ということです。 そのため、下の記事のように負荷テストの計画を作るのはGUI、テスト自体の実行はCUIで実施するようにしていました。 これが意外に手間で、かつ、テスト実行結果をExcelに書き出しグラフ化させるのも地味に手間でした。(プログラムで自動化すればよかったかもしれないですが、そこまで手が回らず...) 結局、以下のような流れで負荷テストを実行していました。 1. 負荷をかける/かけられるサーバーを用意 2. 負荷をかけるサーバーにJavaとJMeterをインストール 3. 負荷をかけるサーバーにテスト計画のファイル(.jmx)を移動 4. JMeterの実行コマンドでテスト計画のファイル(.jmx)を実行 5. テスト結果を保存 6. Excelでテスト結果を集計し、グラフ化 Distributed Load Testing on AWS とは AWS公式サイトから抜粋してきました。 「Distributed Load Testing on AWS」は、 HTTP または HTTPS のエンドポイントに対して、数万の同時接続をシミュレートし、負荷テストを実行することが可能なソリューションです。本ソリューションをデプロイ後、 Amazon S3 にてホストされる Web コンソールにアクセスし、接続先エンドポイント、同時接続数、テスト時間などを指定することでテストを実行できます。 上記の通り、エンドポイントに対して同時接続して、負荷テストを実行してくれる便利なソリューションです。 Distributed Load Testing on AWSを構築しているAWSサービスやコスト面などについては、AWS公式サイトに詳細が記載されています。 コストの具体的な計算式は以下になりますが、TOWER RECORDS MUSICで実際にかかった費用としては、数千円程度でした。 CPU の月額料金 合計 vCPU 料金 = (タスク数) × (vCPU 数) × (CPU 秒あたりの料金) × (秒単位の 1 日あたりの CPU 使用時間) × (日数) メモリの月額料金 合計メモリ料金 = (タスク数) × (メモリ (GB)) × (1 GB あたりの料金) × (秒単位の 1 日あたりのメモリ使用時間) × (日数) Distributed Load Testing on AWS での負荷テストの流れ 今回 Distributed Load Testing on AWS を導入してみたところ、以下の手順で負荷テストを実施できました。 Distributed Load Testing on AWS での負荷テスト実施手順 1. 負荷テスト用JMeterファイルを作成 2. Distributed Load Testing on AWSに 作成したJMeterファイルをエクスポート 3. 同時接続数や同時接続時間を設定し、 テスト実施 4. Distributed Load Testing on AWS上でテスト結果確認 【再掲】JMeterでの負荷テスト実施手順 1. 負荷をかける/かけられるサーバーを用意 2. 負荷をかけるサーバーにJavaとJMeterをインストール 3. 負荷をかけるサーバーにテスト計画のファイル(.jmx)を移動 4. JMeterの実行コマンドでテスト計画のファイル(.jmx)を実行 5. テスト結果を保存 6. Excelでテスト結果を集計し、グラフ化 また、構築する手間は少なく、以下の手順で構築が完了したので簡単だったそうです。(私は構築しておらず...) 1. DockerHubのアカウント作成 2. DockerHubのアカウントのシークレット設定 3. Cloudformation実行 実際に使い、JMeterと比較して1番便利だなと思ったことは、すべてGUIで完結できたということです。 設定値を決めて負荷テストを実行すれば、結果がグラフとして表示されるというのはかなり便利でした。 レスポンスタイムなども詳細に記載されているので、この結果を見ればサービスの品質担保をある程度チェックできるかなと思いました。 以下が、実際のテスト結果になります。 Distributed Load Testing on AWS のメリット ここからは、個人的に役に立った箇所を紹介していこうと思います。 1. テストシナリオは、JMeterのシナリオを指定できる JMeterファイルをそのまま利用できるため、以前JMeterで負荷テストを実施していた私にとってはとてもありがたい仕様でした。 追加する方法も簡単で、以下の画像のようにテストシナリオを設定する項目にJMeterの項目があるので、そこから追加すればOKです。 2. 今まで実施したテスト要件と結果がリスト化されている 次に、以下のように今まで実施したテスト要件と結果がリスト化されているところです。(負荷テスト名と負荷テストの説明文は隠しています) 履歴として残っているため、履歴を参考にしながら新しい負荷テストを実施できるので、 引き継ぎとして教える際にも簡単にこのソリューションの使い方を伝授できます。 終わりに いかがだったでしょうか？ リリース前の負荷テストは、リリース時にサーバーへの負荷がかかりすぎないかを確認するためにとても大事な作業だと思います。 ただ、負荷テストは準備に意外に手間がかかるため、手間を最小限に、かつ正確な結果を返してくれるソリューションとして Distributed Load Testing on AWS は、おすすめだと思います。 皆様がこの記事をきっかけに Distributed Load Testing on AWS に興味を持っていただけると幸いです。 明日のレコチョク Advent Calendar 2021は6日目「QuickSightの埋め込みダッシュボードを使ってサービス開発した話」です。お楽しみに！ この記事はレコチョクのエンジニアブログの記事を転載したものとなります。 参考記事

弊社では、人事・労務管理に SmartHR というサービスを使用しています。 SmartHR も SAML 2.0 による Single Sign On に対応しているようなので、AWS SSO から接続できるように設定してみました。 AWS SSO へのアプリケーション登録 Applications から New Application　として Add a Custom SAML 2.0 application を選択します。 次に表示される画面で AWS SSO SAML metadata file をダウンロードしておきます。 他の箇所は特に変更する必要はないです。 Display name と Description だけ、お好みで変更してください。 SmartHR でのシングルサインオン設定 SmartHR の公式ドキュメントを読んで設定しましょう。 SAML認証（SSO）を使ってログインする サービスプロバイダ情報から metadata をエクスポートしておくと、AWS SSO のアプリケーション設定が楽になります。 AWS SSO アプリケーションの設定変更 Application metadata の設定 SmartHR からエクスポートした metadata を Application metadata としてインポートします。 Attribute mappings の設定 以下のように設定します。 User attribute in the application Maps to this string value or user attribute in AWS SSO Format Subject ${user:email} emailAddress email ${user:email} unspecified SmartHR のアカウント情報の変更 SmartHR の公式ドキュメントを読んで設定しましょう。 連携IdPアカウント は、AWS SSO のユーザに設定されているメールアドレスを登録します。 SAML認証（SSO）を使ってログインする これで、設定完了です。 AWS SSO から SmartHR にログインできるようになります。

要約 デフォルトで、AWS-VPC（以下、VPCと呼称する。）内の通信手段としてブロードキャスト・マルチキャストの利用は制限されています。 「AWS Transit Gatewayのマルチキャスト機能」を使うとこの制約の一部を回避することが可能です。 ただし、「マルチキャスト・パケット転送」がカーネルビルド時に無効オプションがデフォルトとされており、それに起因して使いづらい部分もあること。 Dockerから使う場合などなど。 はじめに ROS2元年！？ ROSCon JP 2021やROS World 2021の発表を見ると、その多くがROS2を使って実行されていることが分かります。ROS Noetic NinjemysのEOLは2025年5月と、移行の猶予時間はまだ残っている段階ですが、事例も増えてきておりROS2への理解も深めていくタイミングとしては2021年は良いタイミングと感じました。 そこで本記事では「ROS2のノードの一部（ROSbagとか!?）をクラウドサービス上で動かしたいなー」と考える方に向けて、選択肢の一つを提示できればと思います。 VPC(Virtual Private Cloud)ではブロードキャスト・マルチキャストが制限されている VPCは、パブリッククラウド内に論理的に分離された仮想ネットワーク空間を提供します。我々、利用者はこの中にEC2(仮想マシン)、RDS(データベースサービス)などの各リソースを配置して「目的に応じたインフラを自由に構築」していくわけです。 自由に〜と書きつつも、制約もあります。その一つとして、「VPC内の通信手段としてブロードキャスト・マルチキャストの利用が制限せれている点」が挙げられます。※1 一般的には通信量の抑制のために必要な措置とされています。論理的に同一サブネットを構成しつつも、物理的にはそうなっていないわけです。ブロードキャストやマルチキャストはパケットを1つ飛ばすとみんなに届くという、オンプレでは省エネな通信方式ですが、これを物理的にはバラバラな状況下で忠実に再現するのはあまり現実的な選択肢でないことも頷けるかと思います。(例：クラスBのローカルアドレスだと65534個に送信…!) Transit Gatewayのマルチキャスト機能 そんな中、登場したのが「AWS Transit Gatewayのマルチキャスト機能」です。 「Transit Gateway」は、クラウドルーターと総称される機能群を提供します。 Amazon VPC、AWS アカウント、オンプレミスネットワークを単一のゲートウェイに簡単に接続（引用：AWSのホームページのヘッダより） その中で「マルチキャスト機能」は2019年の更新時に追加された比較的新しい機能です。当初はIGMPが使えず、マルチキャストグループに所属するEC2(それにアタッチしているENI)を、興味関心があるシステムとは別手動で管理せねばならず、使いづらいところがありました。 そんな中、2020年末にIGMPパケットへのサポートが発表され、2021年4月には、東京リージョンで使えるようになっていました。 東京リージョンに2つのAWS Transit Gateway アップデート： AWS Transit Gateway Connect と Internet Group Management Protocol (IGMP) Multicast | Amazon Web Services ブログ IGMP(Internet Group Management Protocol) IGMPについての解説の詳細は割愛するが、ROS2との関わりという視点で、本記事と関連がある部分を少しだけ見ていきます。 ROS2で一般的なDDS実装である、FastDDS及び、Cyclone DDS では、Multicast-UDPモードで動作する場合、IGMPパケットを送出してから通信を開始していることを確認できます。 （図1 ros2 run demo_nodes_cpp talkerパケットキャプチャ結果 - FastDDS(Multicast-UDP)） 2021年現在売られているスイッチングハブでは「IGMPスヌーピング機能」が有効化されている機種が非常に多くあります。これらは、IGMPパケットを盗み見（スヌーピング）して、どの送信元がどのマルチキャストグループに属しているかを、スイッチングハブ側でも把握することで、マルチキャストパケットの送信先を絞っています。やはりこちらも、Transit Gateway同様に不要な通信で帯域を無駄遣いしないための工夫です。※2 構築手順 公式のドキュメントはこちら。AWS上で図2のような簡単な環境を作って、ROS2のPub/Subを試してみましょう。なお、制限については公式ドキュメントに詳しく載っていますが、特に、Amazon EC2はニトロシステムに対応したインスタンス（t3、c5、m5など）を利用しなければならない点にご注意下さい。※3 （図2 AWS構成図） これはいわゆる、「踏み台」を使った要塞構成と呼ばれるもので、AWSでもクイックスタートでおすすめしている風の構成です。詳しい構築方法はこちら。AWS での Linux 踏み台ホスト - クイックスタート また、各EC2のOSがUbuntu20.04、ROS2 Foxyがインストールされているものとします。 ここでは、Transit Gatewayやセキュリティグループの設定を見ていきます。 Transit Gatewayの設定 AWSの「コンソールのホーム」→「VPC」、左側メニュー「Transit Gateway」→「Transit Gateway」の順に進み、Transit Gatewayの設定画面を表示し、「Transit Gatewayを作成」ボタンをクリックします。 （図3 VPC画面の左側メニューのうちTransit Gateway部分を抜粋） 「Transit Gatewayを作成」画面では、任意の名前タグ（ここではros2-mudp）を付与し、「Transit Gatewayを設定」→「マルチキャストサポート」チェックボックを有効にして、画面下部の「Transit Gatewayを作成」ボタンをクリックします。 （図4 「Transit Gatewayを作成」画面） 「Transit Gateway」の一覧画面に遷移するので、左側メニュー「Transit Gateway アタッチメント」→「Transit Gateway アタッチメントを作成」ボタンをクリックします。 「Transit Gateway アタッチメントを作成」画面-詳細ブロックでは、任意の名前タグ（ここではros2-mudp）、「Transit Gateway ID」セレクトボックスに対して先に作った「Transit Gateway ID」を指定し、「アタッチメントタイプ」セレクトボックスがVPCとなっていることを確認してください。 （図5 「Transit Gatewayアタッチメントを作成」画面） 「Transit Gateway アタッチメントを作成」画面-VPCアタッチメントブロックでは、今回のターゲットとなるROS2が載ったEC2が所属する、VPCやそのサブネットを指定して下さい。詳細・VPCアタッチメントの各ブロックの入力内容に問題ないことを確認して、画面下部の「Transit Gateway アタッチメントを作成」ボタンをクリックします。 （図6 「Transit Gatewayアタッチメントを作成」画面） 「Transit Gateway アタッチメント」の一覧画面に遷移するので、左側メニュー「Transit Gateway Multicast」→「Transit Gateway マルチキャストドメインを作成」ボタンをクリックします。 「Transit Gateway マルチキャストドメインを作成」画面では、任意の名前タグ（ここではros2-mudp）を付与し、「Transit Gateway ID」セレクトボックスに対して先に作った「Transit Gateway ID」を指定し、「Transit Gateway マルチキャストドメインを設定」→「IGMPv2 のサポート」チェックボックスを有効にします。入力内容に問題ないことを確認して、画面下部の「Transit Gateway マルチキャストドメインを作成」ボタンをクリックします。 （図7 「Transit Gateway マルチキャストドメインを作成」画面） 「Transit Gateway マルチキャストドメイン」の一覧画面に遷移するので、今回作成したマルチキャストドメイン（ros2-mudp）を選択し、下側メニュータブの「関連付け」タブをクリックして下さい。タブ画面が遷移した後に表示される「関連付けを作成」ボタンをクリックしてください。 （図8 マルチキャストドメインの関連付けを作成する） 「関連付けを作成」画面では、「関連付けるアタッチメントを選択」セレクトボックスでは、先に作成したものを、「関連付けるサブネットを選択」セレクトボックスでは「Transit Gateway アタッチメント」と同様に予め作っておいたサブネットを関連付けます。入力内容に問題ないことを確認して、画面下部の「関連付けを」作成ボタンをクリックしてください。 （図9 「Transit Gateway マルチキャストドメイン - 関連付けを作成」画面） ネットワークACL、セキュリティグループ マルチキャストのルーティング - Amazon Virtual Private Cloudを参考に、自身のセキュリティポリシーに応じて、適切なルールを宣言する必要があります。Transit Gatewayと同様に、AWSの「コンソールのホーム」→「VPC」、左側メニュー「セキュリティ」より設定可能です。 ひとつ、つまずきやすいポイントとしては、セキュリティグループの「ソース」はネットワークIPもしくはCIDRで指定する必要があるようです。（セキュリティグループ指定はできません。） EC2でIGMPの設定を変更する IGMP 設定を管理するには以下の通りの記載があります。 EC2 のデフォルトの IGMP バージョンは IGMPv3 です。すべての IGMP グループメンバーのバージョンを変更する必要があります。以下のコマンドを実行できます。 sudo sysctl net.ipv4.conf.eth0.force_igmp_version=2 ということで、コンソールで各EC2にログインし、上記コマンドを実行しておいて下さい。 動作確認 では、実際にROS2のデモおなじみの「demo_nodes_cpp」を動かしてみましょう。ROS-Baseとかでインストールした方は、おそらくインストールされていないので、お試し頂きたい場合は、以下コマンドで追加することも可能です。 sudo apt install ros-foxy-demo-nodes-cpp -y では、こちらが実際に動かした様子です。ここではRMW_IMPLEMENTATIONは特に指定しません。（＝デフォルトのFastDDSを使う） 端末A ros2 run demo_nodes_cpp talker 端末B ros2 run demo_nodes_cpp listener （図10 ROS2のデモプログラムによる動作確認） この時、「Transit Gateway マルチキャストドメイン」の画面で、今回作成したマルチキャストドメイン（ros2-mudp）を選択し、下側メニュータブの「グループ」タブをクリックして下さい。すると、FastRTPSのデフォルトのマルチキャストグループである「239.255.0.1」によるグループが作成されていることが確認できます。 （図11 AWSのコンソールでマルチキャストグループを確認する） ちなみに、「239.0.0.0/8」に該当するアドレスはプライベートスコープとして定められたアドレスです。RFC2365によって組織内で使用するためのプライベートアドレスとして割り当てられています。 ベンチマーク ここでは、iperfを使って軽く実行したパフォーマンス測定結果を掲示します。頻度、データサイズ、インスタンスを変えた場合、同一AZ、オンプレとの比較をして考察を添えるべきかと思いますが、時間切れになってしまいました。。。。 データ無しで語る雰囲気としては、TransitGatewayを介しているからといってAWSのネットワーク性能が落ちている訳ではないように感じます。また、AZを跨いだ厳しい測定条件にも関わらずレイテンシーが3σで2〜5msで収まっているのはさすがだなというところ。 数字として今回は取れていませんが、Discoverが少し遅い点は少し気になる人もいるかもしれません。（実機でやっているときより2〜3秒遅いという肌感覚） 条件 東京リージョン（ap-northeast-1bと1c） EC2インスタンス：t3.medium 2vCPU（Xeon Platinum 8000　 ブーストで@3.1GHz） 4GiB ネットワークバースト幅：5Gbps 1Hz - 20Mbpsを5並列 基本統計量 Latency_avg Latency_min Latency_max Latency_stdev Jitter 平均 3.535268041 平均 3.491902062 平均 6.062958763 平均 0.135654639 平均 0.02357732 標準誤差 0.00964557 標準誤差 0.00933292 標準誤差 0.117311208 標準誤差 0.00733046 標準誤差 0.001129145 中央値 （メジアン） 3.5295 中央値 （メジアン） 3.4945 中央値 （メジアン） 6.322 中央値 （メジアン） 0.1205 中央値 （メジアン） 0.019 最頻値 （モード） 3.467 最頻値 （モード） 3.559 最頻値 （モード） 3.921 最頻値 （モード） 0.029 最頻値 （モード） 0.019 標準偏差 0.134347243 標準偏差 0.129992529 標準偏差 1.633956059 標準偏差 0.10210149 標準偏差 0.015727165 分散 0.018049182 分散 0.016898058 分散 2.669812402 分散 0.010424714 分散 0.000247344 尖度 -0.791325596 尖度 -0.770579324 尖度 -1.133331214 尖度 0.386623598 尖度 5.888190464 歪度 0.005190191 歪度 -0.063748029 歪度 0.173594446 歪度 0.931138478 歪度 2.262671108 範囲 0.527 範囲 0.527 範囲 5.808 範囲 0.432 範囲 0.084 最小 3.278 最小 3.222 最小 3.666 最小 0.019 最小 0.006 最大 3.805 最大 3.749 最大 9.474 最大 0.451 最大 0.09 合計 685.842 合計 677.429 合計 1176.214 合計 26.317 合計 4.574 標本数 194 標本数 194 標本数 194 標本数 194 標本数 194 最大値(1) 3.805 最大値(1) 3.749 最大値(1) 9.474 最大値(1) 0.451 最大値(1) 0.09 最小値(1) 3.278 最小値(1) 3.222 最小値(1) 3.666 最小値(1) 0.019 最小値(1) 0.006 信頼区間(99.0%) 0.02509336 信頼区間(99.0%) 0.024279987 信頼区間(99.0%) 0.305190097 信頼区間(99.0%) 0.019070503 信頼区間(99.0%) 0.002937518 レイテンシー ジッター おまけ：iRobot ROS2 performance evaluation framework 一応計測しましたが、同一マシン上でのパフォーマンステストではTransitGatewayを介さないっぽいですね。FASTRTPS_DEFAULT_PROFILES_FILE環境変数で指定したプロファイルXMLを使ってSHMを無効化して測定したのですが、それにしては速すぎるような。（よく分かっていないのでオマケ扱い。この辺の詳しい情報をお持ちの方がおられましたら教えて頂ければ幸いです。） $ FASTRTPS_DEFAULT_PROFILES_FILE=fastrtps-profile.xml ./irobot-benchmark topology/sierra_nevada.json --ipc off 〜略〜 node topic size[b] received[#] late[#] too_late[#] lost[#] mean[us] sd[us] min[us] max[us] freq[hz] duration[s] lyon amazon 36 501 0 0 0 86 63 46 902 100 5 hamburg danube 8 501 1 0 0 92 181 45 3506 100 5 hamburg ganges 16 501 0 0 0 62 49 38 935 100 5 hamburg nile 16 501 0 0 0 71 46 43 851 100 5 hamburg tigris 16 500 1 0 0 105 104 49 2074 100 5 osaka parana 12 501 0 0 0 74 108 44 1662 100 5 mandalay danube 8 501 1 0 0 113 187 63 3649 100 5 mandalay salween 48 50 0 0 0 79 36 50 305 10 5 ponce danube 8 501 1 0 0 124 188 68 3663 100 5 ponce missouri 10000 50 0 0 0 113 198 63 1430 10 5 ponce volga 8 10 0 0 0 78 59 43 245 2 5 barcelona mekong 100 10 0 0 0 82 8 62 92 2 5 georgetown lena 50 50 0 0 0 107 210 58 1556 10 5 geneva congo 16 50 0 0 0 77 25 48 196 10 5 geneva danube 8 501 1 0 0 132 189 74 3675 100 5 geneva parana 12 501 0 0 0 92 112 55 1711 100 5 arequipa arkansas 16 50 0 0 0 111 277 54 2043 10 5 Publishers stats: node topic size[b] received[#] late[#] too_late[#] lost[#] mean[us] sd[us] min[us] max[us] freq[hz] duration[s] montreal amazon 36 0 0 0 0 19 12 6 107 100 5 montreal danube 8 0 0 0 0 30 159 5 3419 100 5 montreal ganges 16 0 0 0 0 13 9 3 98 100 5 montreal nile 16 0 0 0 0 16 11 3 108 100 5 lyon tigris 16 0 0 0 0 24 24 3 203 100 5 hamburg parana 12 0 0 0 0 16 13 5 118 100 5 osaka salween 48 0 0 0 0 16 11 5 64 10 5 mandalay missouri 10000 0 0 0 0 21 13 13 92 10 5 ponce congo 16 0 0 0 0 16 8 9 39 10 5 ponce mekong 100 0 0 0 0 17 2 12 21 2 5 barcelona lena 50 0 0 0 0 16 14 6 107 10 5 georgetown volga 8 0 0 0 0 16 16 5 64 2 5 geneva arkansas 16 0 0 0 0 14 7 6 53 10 5 System total: received[#] mean[us] late[#] late[%] too_late[#] too_late[%] lost[#] lost[%] 5279 95 5 0.09471 0 0 0 0 制約事項 要約で記した通り、「マルチキャスト・パケット転送」がカーネルビルド時に無効オプションがデフォルトとされており、それに起因してDockerなどの仮想ネットワークから本機能を使うことが基本的には出来ないようになっています。Dockerから使う場合は「hostネットワーク」を有効にして、ホスト側のネットワークに頼るというような対応を取る必要があります。 あくまでも、コンテナにこだわる場合はKubernetesでUDPマルチキャストに対応したクラスターネットワーク（例えば、WeaveNet）を使うという手もあります。ただし、現状でAWSのマネージドKubernetesサービスであるAmazon Elastic Kubernetes Service (EKS)でWeaveNetを使うと、マネージドな有り難みを9割方スポイルしてしまうという問題もあります。 んー難しい。。。。 おわりに 面倒・制約が残るものの、AWSのネイティブなネットワーク（トンネリング技術を使わないという意味で）でROS2(FastDDS-Multicast-UDP)を使ったPub/Subが行えることが分かりました。 ユニットテストやシステムテストをAWS上で実行する ROSBagとかをデータ耐久性の高いクラウドストレージでバックアップする などに使えないだろうか！？ また、EC2のARMプロセッサーのインスタンスであるGravition2シリーズのコスパが物凄いことになってきています。 x86のインスタンスと比較して40％の価格性能比 先日のre:Invent2021ではGravition3も発表されており、クラウド高いなーとも言えない状況が出来つつある気がしました。ロボット系の皆様に於かれましては、クラウドも含めてオールARMプロセッサーっていうこともありうるのでは！？と思ったりもしています。 と妄想を膨らませつつ記事を締めたいと思います。 補足 ※1 公式ドキュメントでその旨が「主題として」書かれているドキュメントを探すことが出来ませんでした。以下のような感じでさらっと書いてあるところとかは見つけましたが。この制限は暗黙の了解だったのでしょうか。 VPC とサブネット - Amazon Virtual Private Cloud 10.0.0.255: ネットワークブロードキャストアドレスです。VPC ではブロードキャストがサポートされないため、このアドレスを予約します。 ※2 マルチキャスト - IGMPスヌーピングとは ※3 NITROについてはメチャクチャ詳しい記事がありました。 AWS Nitro とは何かを理解する | Powering next-gen Amazon EC2: Deep dive on the Nitro System #CMP301 #reinvent | DevelopersIO!

要約 デフォルトで、AWS-VPC（以下、VPCと呼称する。）内の通信手段としてブロードキャスト・マルチキャストの利用は制限されています。 「AWS Transit Gatewayのマルチキャスト機能」を使うとこの制約の一部を回避することが可能です。 ただし、「マルチキャスト・パケット転送」がカーネルビルド時に無効オプションがデフォルトとされており、それに起因して使いづらい部分もあること。 Dockerから使う場合などなど。 はじめに ROS2元年！？ ROSCon JP 2021やROS World 2021の発表を見ると、その多くがROS2を使って実行されていることが分かります。ROS Noetic NinjemysのEOLは2025年5月と、移行の猶予時間はまだ残っている段階ですが、事例も増えてきておりROS2への理解も深めていくタイミングとしては2021年は良いタイミングと感じました。 そこで本記事では「ROS2のノードの一部（ROSbagとか!?）をクラウドサービス上で動かしたいなー」と考える方に向けて、選択肢の一つを提示できればと思います。 VPC(Virtual Private Cloud)ではブロードキャスト・マルチキャストが制限されている VPCは、パブリッククラウド内に論理的に分離された仮想ネットワーク空間を提供します。我々、利用者はこの中にEC2(仮想マシン)、RDS(データベースサービス)などの各リソースを配置して「目的に応じたインフラを自由に構築」していくわけです。 自由に〜と書きつつも、制約もあります。その一つとして、「VPC内の通信手段としてブロードキャスト・マルチキャストの利用が制限せれている点」が挙げられます。※1 一般的には通信量の抑制のために必要な措置とされています。論理的に同一サブネットを構成しつつも、物理的にはそうなっていないわけです。ブロードキャストやマルチキャストはパケットを1つ飛ばすとみんなに届くという、オンプレでは省エネな通信方式ですが、これを物理的にはバラバラな状況下で忠実に再現するのはあまり現実的な選択肢でないことも頷けるかと思います。(例：クラスBのローカルアドレスだと65534個に送信…!) Transit Gatewayのマルチキャスト機能 そんな中、登場したのが「AWS Transit Gatewayのマルチキャスト機能」です。 「Transit Gateway」は、クラウドルーターと総称される機能群を提供します。 Amazon VPC、AWS アカウント、オンプレミスネットワークを単一のゲートウェイに簡単に接続（引用：AWSのホームページのヘッダより） その中で「マルチキャスト機能」は2019年の更新時に追加された比較的新しい機能です。当初はIGMPが使えず、マルチキャストグループに所属するEC2(それにアタッチしているENI)を、興味関心があるシステムとは別手動で管理せねばならず、使いづらいところがありました。 そんな中、2020年末にIGMPパケットへのサポートが発表され、2021年4月には、東京リージョンで使えるようになっていました。 東京リージョンに2つのAWS Transit Gateway アップデート： AWS Transit Gateway Connect と Internet Group Management Protocol (IGMP) Multicast | Amazon Web Services ブログ IGMP(Internet Group Management Protocol) IGMPについての解説の詳細は割愛するが、ROS2との関わりという視点で、本記事と関連がある部分を少しだけ見ていきます。 ROS2で一般的なDDS実装である、FastDDS及び、Cyclone DDS では、Multicast-UDPモードで動作する場合、IGMPパケットを送出してから通信を開始していることを確認できます。 （図1 ros2 run demo_nodes_cpp talkerパケットキャプチャ結果 - FastDDS(Multicast-UDP)） 2021年現在売られているスイッチングハブでは「IGMPスヌーピング機能」が有効化されている機種が非常に多くあります。これらは、IGMPパケットを盗み見（スヌーピング）して、どの送信元がどのマルチキャストグループに属しているかを、スイッチングハブ側でも把握することで、マルチキャストパケットの送信先を絞っています。やはりこちらも、Transit Gateway同様に不要な通信で帯域を無駄遣いしないための工夫です。※2 構築手順 公式のドキュメントはこちら。AWS上で図2のような簡単な環境を作って、ROS2のPub/Subを試してみましょう。なお、制限については公式ドキュメントに詳しく載っていますが、特に、Amazon EC2はニトロシステムに対応したインスタンス（t3、c5、m5など）を利用しなければならない点にご注意下さい。※3 （図2 AWS構成図） これはいわゆる、「踏み台」を使った要塞構成と呼ばれるもので、AWSでもクイックスタートでおすすめしている風の構成です。詳しい構築方法はこちら。AWS での Linux 踏み台ホスト - クイックスタート また、各EC2のOSがUbuntu20.04、ROS2 Foxyがインストールされているものとします。 ここでは、Transit Gatewayやセキュリティグループの設定を見ていきます。 Transit Gatewayの設定 AWSの「コンソールのホーム」→「VPC」、左側メニュー「Transit Gateway」→「Transit Gateway」の順に進み、Transit Gatewayの設定画面を表示し、「Transit Gatewayを作成」ボタンをクリックします。 （図3 VPC画面の左側メニューのうちTransit Gateway部分を抜粋） 「Transit Gatewayを作成」画面では、任意の名前タグ（ここではros2-mudp）を付与し、「Transit Gatewayを設定」→「マルチキャストサポート」チェックボックを有効にして、画面下部の「Transit Gatewayを作成」ボタンをクリックします。 （図4 「Transit Gatewayを作成」画面） 「Transit Gateway」の一覧画面に遷移するので、左側メニュー「Transit Gateway アタッチメント」→「Transit Gateway アタッチメントを作成」ボタンをクリックします。 「Transit Gateway アタッチメントを作成」画面-詳細ブロックでは、任意の名前タグ（ここではros2-mudp）、「Transit Gateway ID」セレクトボックスに対して先に作った「Transit Gateway ID」を指定し、「アタッチメントタイプ」セレクトボックスがVPCとなっていることを確認してください。 （図5 「Transit Gatewayアタッチメントを作成」画面） 「Transit Gateway アタッチメントを作成」画面-VPCアタッチメントブロックでは、今回のターゲットとなるROS2が載ったEC2が所属する、VPCやそのサブネットを指定して下さい。詳細・VPCアタッチメントの各ブロックの入力内容に問題ないことを確認して、画面下部の「Transit Gateway アタッチメントを作成」ボタンをクリックします。 （図6 「Transit Gatewayアタッチメントを作成」画面） 「Transit Gateway アタッチメント」の一覧画面に遷移するので、左側メニュー「Transit Gateway Multicast」→「Transit Gateway マルチキャストドメインを作成」ボタンをクリックします。 「Transit Gateway マルチキャストドメインを作成」画面では、任意の名前タグ（ここではros2-mudp）を付与し、「Transit Gateway ID」セレクトボックスに対して先に作った「Transit Gateway ID」を指定し、「Transit Gateway マルチキャストドメインを設定」→「IGMPv2 のサポート」チェックボックスを有効にします。入力内容に問題ないことを確認して、画面下部の「Transit Gateway マルチキャストドメインを作成」ボタンをクリックします。 （図7 「Transit Gateway マルチキャストドメインを作成」画面） 「Transit Gateway マルチキャストドメイン」の一覧画面に遷移するので、今回作成したマルチキャストドメイン（ros2-mudp）を選択し、下側メニュータブの「関連付け」タブをクリックして下さい。タブ画面が遷移した後に表示される「関連付けを作成」ボタンをクリックしてください。 （図8 マルチキャストドメインの関連付けを作成する） 「関連付けを作成」画面では、「関連付けるアタッチメントを選択」セレクトボックスでは、先に作成したものを、「関連付けるサブネットを選択」セレクトボックスでは「Transit Gateway アタッチメント」と同様に予め作っておいたサブネットを関連付けます。入力内容に問題ないことを確認して、画面下部の「関連付けを」作成ボタンをクリックしてください。 （図9 「Transit Gateway マルチキャストドメイン - 関連付けを作成」画面） ネットワークACL、セキュリティグループ マルチキャストのルーティング - Amazon Virtual Private Cloudを参考に、自身のセキュリティポリシーに応じて、適切なルールを宣言する必要があります。Transit Gatewayと同様に、AWSの「コンソールのホーム」→「VPC」、左側メニュー「セキュリティ」より設定可能です。 ひとつ、つまずきやすいポイントとしては、セキュリティグループの「ソース」はネットワークIPもしくはCIDRで指定する必要があるようです。（セキュリティグループ指定はできません。） EC2でIGMPの設定を変更する IGMP 設定を管理するには以下の通りの記載があります。 EC2 のデフォルトの IGMP バージョンは IGMPv3 です。すべての IGMP グループメンバーのバージョンを変更する必要があります。以下のコマンドを実行できます。 sudo sysctl net.ipv4.conf.eth0.force_igmp_version=2 ということで、コンソールで各EC2にログインし、上記コマンドを実行しておいて下さい。 動作確認 では、実際にROS2のデモおなじみの「demo_nodes_cpp」を動かしてみましょう。ROS-Baseとかでインストールした方は、おそらくインストールされていないので、お試し頂きたい場合は、以下コマンドで追加することも可能です。 sudo apt install ros-foxy-demo-nodes-cpp -y では、こちらが実際に動かした様子です。ここではRMW_IMPLEMENTATIONは特に指定しません。（＝デフォルトのFastDDSを使う） 端末A ros2 run demo_nodes_cpp talker 端末B ros2 run demo_nodes_cpp listener （図10 ROS2のデモプログラムによる動作確認） この時、「Transit Gateway マルチキャストドメイン」の画面で、今回作成したマルチキャストドメイン（ros2-mudp）を選択し、下側メニュータブの「グループ」タブをクリックして下さい。すると、FastRTPSのデフォルトのマルチキャストグループである「239.255.0.1」によるグループが作成されていることが確認できます。 （図11 AWSのコンソールでマルチキャストグループを確認する） ちなみに、「239.0.0.0/8」に該当するアドレスはプライベートスコープとして定められたアドレスです。RFC2365によって組織内で使用するためのプライベートアドレスとして割り当てられています。 ベンチマーク ここでは、iperfを使って軽く実行したパフォーマンス測定結果を掲示します。頻度、データサイズ、インスタンスを変えた場合、同一AZ、オンプレとの比較をして考察を添えるべきかと思いますが、時間切れになってしまいました。。。。 データ無しで語る雰囲気としては、TransitGatewayを介しているからといってAWSのネットワーク性能が落ちている訳ではないように感じます。また、AZを跨いだ厳しい測定条件にも関わらずレイテンシーが3σで2〜5msで収まっているのはさすがだなというところ。 数字として今回は取れていませんが、Discoverが少し遅い点は少し気になる人もいるかもしれません。（実機でやっているときより2〜3秒遅いという肌感覚） 条件 東京リージョン（ap-northeast-1bと1c） EC2インスタンス：t3.medium 2vCPU（Xeon Platinum 8000　 ブーストで@3.1GHz） 4GiB ネットワークバースト幅：5Gbps 1Hz - 20Mbpsを5並列 基本統計量 Latency_avg Latency_min Latency_max Latency_stdev Jitter 平均 3.535268041 平均 3.491902062 平均 6.062958763 平均 0.135654639 平均 0.02357732 標準誤差 0.00964557 標準誤差 0.00933292 標準誤差 0.117311208 標準誤差 0.00733046 標準誤差 0.001129145 中央値 （メジアン） 3.5295 中央値 （メジアン） 3.4945 中央値 （メジアン） 6.322 中央値 （メジアン） 0.1205 中央値 （メジアン） 0.019 最頻値 （モード） 3.467 最頻値 （モード） 3.559 最頻値 （モード） 3.921 最頻値 （モード） 0.029 最頻値 （モード） 0.019 標準偏差 0.134347243 標準偏差 0.129992529 標準偏差 1.633956059 標準偏差 0.10210149 標準偏差 0.015727165 分散 0.018049182 分散 0.016898058 分散 2.669812402 分散 0.010424714 分散 0.000247344 尖度 -0.791325596 尖度 -0.770579324 尖度 -1.133331214 尖度 0.386623598 尖度 5.888190464 歪度 0.005190191 歪度 -0.063748029 歪度 0.173594446 歪度 0.931138478 歪度 2.262671108 範囲 0.527 範囲 0.527 範囲 5.808 範囲 0.432 範囲 0.084 最小 3.278 最小 3.222 最小 3.666 最小 0.019 最小 0.006 最大 3.805 最大 3.749 最大 9.474 最大 0.451 最大 0.09 合計 685.842 合計 677.429 合計 1176.214 合計 26.317 合計 4.574 標本数 194 標本数 194 標本数 194 標本数 194 標本数 194 最大値(1) 3.805 最大値(1) 3.749 最大値(1) 9.474 最大値(1) 0.451 最大値(1) 0.09 最小値(1) 3.278 最小値(1) 3.222 最小値(1) 3.666 最小値(1) 0.019 最小値(1) 0.006 信頼区間(99.0%) 0.02509336 信頼区間(99.0%) 0.024279987 信頼区間(99.0%) 0.305190097 信頼区間(99.0%) 0.019070503 信頼区間(99.0%) 0.002937518 レイテンシー ジッター おまけ：iRobot ROS2 performance evaluation framework 一応計測しましたが、同一マシン上でのパフォーマンステストではTransitGatewayを介さないっぽいですね。FASTRTPS_DEFAULT_PROFILES_FILE環境変数で指定したプロファイルXMLを使ってSHMを無効化して測定したのですが、それにしては速すぎるような。（よく分かっていないのでオマケ扱い。この辺の詳しい情報をお持ちの方がおられましたら教えて頂ければ幸いです。） $ FASTRTPS_DEFAULT_PROFILES_FILE=fastrtps-profile.xml ./irobot-benchmark topology/sierra_nevada.json --ipc off 〜略〜 node topic size[b] received[#] late[#] too_late[#] lost[#] mean[us] sd[us] min[us] max[us] freq[hz] duration[s] lyon amazon 36 501 0 0 0 86 63 46 902 100 5 hamburg danube 8 501 1 0 0 92 181 45 3506 100 5 hamburg ganges 16 501 0 0 0 62 49 38 935 100 5 hamburg nile 16 501 0 0 0 71 46 43 851 100 5 hamburg tigris 16 500 1 0 0 105 104 49 2074 100 5 osaka parana 12 501 0 0 0 74 108 44 1662 100 5 mandalay danube 8 501 1 0 0 113 187 63 3649 100 5 mandalay salween 48 50 0 0 0 79 36 50 305 10 5 ponce danube 8 501 1 0 0 124 188 68 3663 100 5 ponce missouri 10000 50 0 0 0 113 198 63 1430 10 5 ponce volga 8 10 0 0 0 78 59 43 245 2 5 barcelona mekong 100 10 0 0 0 82 8 62 92 2 5 georgetown lena 50 50 0 0 0 107 210 58 1556 10 5 geneva congo 16 50 0 0 0 77 25 48 196 10 5 geneva danube 8 501 1 0 0 132 189 74 3675 100 5 geneva parana 12 501 0 0 0 92 112 55 1711 100 5 arequipa arkansas 16 50 0 0 0 111 277 54 2043 10 5 Publishers stats: node topic size[b] received[#] late[#] too_late[#] lost[#] mean[us] sd[us] min[us] max[us] freq[hz] duration[s] montreal amazon 36 0 0 0 0 19 12 6 107 100 5 montreal danube 8 0 0 0 0 30 159 5 3419 100 5 montreal ganges 16 0 0 0 0 13 9 3 98 100 5 montreal nile 16 0 0 0 0 16 11 3 108 100 5 lyon tigris 16 0 0 0 0 24 24 3 203 100 5 hamburg parana 12 0 0 0 0 16 13 5 118 100 5 osaka salween 48 0 0 0 0 16 11 5 64 10 5 mandalay missouri 10000 0 0 0 0 21 13 13 92 10 5 ponce congo 16 0 0 0 0 16 8 9 39 10 5 ponce mekong 100 0 0 0 0 17 2 12 21 2 5 barcelona lena 50 0 0 0 0 16 14 6 107 10 5 georgetown volga 8 0 0 0 0 16 16 5 64 2 5 geneva arkansas 16 0 0 0 0 14 7 6 53 10 5 System total: received[#] mean[us] late[#] late[%] too_late[#] too_late[%] lost[#] lost[%] 5279 95 5 0.09471 0 0 0 0 制約事項 要約で記した通り、「マルチキャスト・パケット転送」がカーネルビルド時に無効オプションがデフォルトとされており、それに起因してDockerなどの仮想ネットワークから本機能を使うことが基本的には出来ないようになっています。Dockerから使う場合は「hostネットワーク」を有効にして、ホスト側のネットワークに頼るというような対応を取る必要があります。 あくまでも、コンテナにこだわる場合はKubernetesでUDPマルチキャストに対応したクラスターネットワーク（例えば、WeaveNet）を使うという手もあります。ただし、現状でAWSのマネージドKubernetesサービスであるAmazon Elastic Kubernetes Service (EKS)でWeaveNetを使うと、マネージドな有り難みを9割方スポイルしてしまうという問題もあります。 んー難しい。。。。 おわりに 面倒・制約が残るものの、AWSのネイティブなネットワーク（トンネリング技術を使わないという意味で）でROS2(FastDDS-Multicast-UDP)を使ったPub/Subが行えることが分かりました。 ユニットテストやシステムテストをAWS上で実行する ROSBagとかをデータ耐久性の高いクラウドストレージでバックアップする などに使えないだろうか！？ また、EC2のARMプロセッサーのインスタンスであるGravition2シリーズのコスパが物凄いことになってきています。 x86のインスタンスと比較して40％の価格性能比 先日のre:Invent2021ではGravition3も発表されており、クラウド高いなーとも言えない状況が出来つつある気がしました。ロボット系の皆様に於かれましては、クラウドも含めてオールARMプロセッサーっていうこともありうるのでは！？と思ったりもしています。 と妄想を膨らませつつ記事を締めたいと思います。 補足 ※1 公式ドキュメントでその旨が「主題として」書かれているドキュメントを探すことが出来ませんでした。以下のような感じでさらっと書いてあるところとかは見つけましたが。この制限は暗黙の了解だったのでしょうか。 VPC とサブネット - Amazon Virtual Private Cloud 10.0.0.255: ネットワークブロードキャストアドレスです。VPC ではブロードキャストがサポートされないため、このアドレスを予約します。 ※2 マルチキャスト - IGMPスヌーピングとは ※3 NITROについてはメチャクチャ詳しい記事がありました。 AWS Nitro とは何かを理解する | Powering next-gen Amazon EC2: Deep dive on the Nitro System #CMP301 #reinvent | DevelopersIO!

受験動機 2019/10にSAA、2021/4にSOAを取得していたのでアソシエイト三冠を達成するため 使用した機材について AWS WEB問題集で学習しよう おなじみkoiwaclubのオンライン問題集 SAA、SOAに比べるとちょっと問題数は少なめ？ですが、本試験との難易度は同じぐらい このサービスの本試験モードで満点が取れれば大抵は合格できる ポケットスタディ AWS認定 デベロッパーアソシエイト 内容はとても良い、解説も丁寧で誤植もない 本編パートの理解度クイズはやや細かすぎる感じはあるが、冒頭の参考問題と巻末の模擬試験の内容はよく練られている 模擬試験でほぼ満点がとれれば絶対合格できる whizlabs.com 以前SAA取得後にセールでSOA,DVAのオンライン講座を購入していたので、知識範囲を広げるために再開 しょっちゅうセールをやっているのでタイミングを狙えば安く入手できる、利用期限もないし問題集だけ買えるのは便利(解説動画は英語出来る人以外は不要) Chromeの翻訳拡張機能オプションを連動させれば、基本日本語化して利用できる 解説パートのクイズはだいぶ難しく、細かいところを聞いてくる問題が多め クイズの問題順番と選択肢順番がシャッフルされないので、視覚的に答えを記憶してしまいがち（この問題だと確か正答はこの一番長いやつ…みたいな） 受験まで 2020/05~ SOAに合格したのでひとまず「ポケットスタディ AWS認定 デベロッパーアソシエイト」を購入 ざっと中身を見てみるが、SAAと重なっている領域(インフラ系)とそれ以外(開発系)で自分の知識量の差が激しい… Lambda + APIgateway構成は業務で構築したことがあるので多少分かるけど(Lambdaの環境変数やエイリアス、APIgatewayのステージなど)それ以外はなんとなく概念が分かる程度 とりあえず時間あるときにパラパラと開いてみる 2020/06~ 転職イベント対応でしばらく勉強は放置 2020/08~ 新しい職場で勤務開始 前職はほぼリモート勤務でしたが、まさかのリアル出勤勤務で生活リズムが激変 通勤時間で「ポケットスタディ AWS認定 デベロッパーアソシエイト」を開いて勉強を始める 参考書は読みやすいけど、理解度クイズはどうしてもやりづらい(問題ページと解答ページが分かれているから)なんとなくスルーしていた 2020/09~ 参考書でそれなりにスコープ範囲のサービスは頭に入った（ような気がした）ので「AWS WEB問題集で学習しよう」の利用を開始 ライセンス期限から逆算して、試験日ターゲットを11月中旬ぐらいに決める(AWS試験は落ちると二週間再受験できないので、もし落ちても期限内に収まるように調整) 2020/10~ 引き続き通勤時間でオンライン問題集をひたすらやる だいたい自分の苦手なところが分かってくる(IAM権限、Cognito、Cloudformation…) 2020/11(前半) オンライン問題集でほぼ満点が取れるようになったので、模擬試験をやってみる なんと55点しか取れず衝撃を受ける！ 模擬試験が妙に難しかったというのもあるが、「間違えた(理解できていなかった)」よりも「そのような機能オプションの存在を知らなかった(知識不足)」なのが点数が低い原因 オンライン問題集の「出てくる問題」範囲だけだと足りないかも？と思い、以前購入したwhizlabsでのオンライン講座を再開 そもそもポケットスタディの冒頭参考問題をちゃんとやっても半分ぐらいしか正答出来てないので、本編の再読と理解度クイズにちゃんと取り組む 2020/11(後半) ポケットスタディの本編＆理解度クイズがちゃんと頭に入ってくるとだいぶ違う、今まで曖昧だったリソースポリシーとアイデンティティポリシーの違いとかようやく理解できた気がする whizlabsの解説パート理解度クイズはちょっと細かすぎるのでさらっと見ておくだけで充分、模擬試験クイズは本番よりやや難しい？レベルなのでわりと実用的 合格ラインはこれでクリア出来た？ような気がしたので、本試験を申し込む 試験前日はオンライン問題集を全通しで一周して、whizlabsの本試験モードをやっておく 受験当日 前回と同じCBTS歌舞伎座テストセンターで受験、日曜なので受験者は多かった フラグ立てつつ65問回答までで約1時間、その後フラグ問題の検討で10分、見直し1回で10分ぐらいの時間消費 フラグ立てた数も確か3~4個程度、それも二択までは絞り込みができて本文解釈からどちらにすべきか…という感じ インフラ寄り(SAA,SOA)の問題が1/3ぐらい、DVAスコープ範囲でも簡単なのが1/3、難易度それなりが1/3という印象 多くの人がレポートしているが日本語があやしいところが結構ある、公式では「デプロイ」で用語は統一されているのに、問題解答では「展開」と書かれていたりするところがあるので、疑わしいと思ったら英語に切り替えて確認 受験結果 無事合格(スコア959) 模擬試験に比べるとかなり簡単だった 要点 自分のようなインフラエンジニア出身の場合、開発系のサービスはイメージを把握するのが難しい 参考書を読んでなんとなく理解したつもりになっても、手を動かした事がないと応用問題では正答が分からない たまたま業務でlambda + APIgatewayの構築経験があった事がすごく役立った、ここはハンズオンでも時間かからないので是非自分でやっておいた方が良い DynamoDBのRCU/WCUに関する問いは必ず出る、間違えると悔しいのでボーナス問題だな～と思うぐらいまで理解しておくべき 模擬試験はやたらと難しいけど、本試験はずっと簡単（これは今でも謎、DOPの問題が混じっているとか？） 今後 SAPに挑戦するしかないのか…？ SAPは合格記を読んでも「一度落ちた」とか「難易度桁違い」とか厳しいワードばかりで尻込みしてます(w

この記事はレコチョク Advent Calendar 2021の4日目の記事となります。 はじめに 本記事は Advent Calendar へ掲載される日 (12/4) の2週間前に執筆しております。 つまり AWS re:Invent 2021 の開催前となるため今年発表されたサービスについて触れられておりません。予めご了承ください。 本記事は、レコチョクがこれまで AWS re:Invent へどのように関わってきのか、過去実施してきたレコチョク主催イベントの振り返りをしつつ、私個人の「来年こそラスベガスでの大規模開催」を望む気持ちについて、開催前のワクワクを抑えながら書かせて頂きました。 よろしくお願い致します AWS re:Invent について (*画像は2019開催時のラズベガス ベネチアンホテルから Registration 会場に向かう途中で撮影したものです) 2012年からAWS が毎年12月にラスベガスで開催しているグローバルカンファレンスはすでにみなさんご存知かと思います。 毎年大量の新サービスや新機能、アップデート情報が発表される一大イベントですが、数年経験した身からすると、通常の業務と並行してキャッチアップしきるのは非常に難易度が高いなと感じております。。。 2020年時は、新型コロナウイルスの影響で「オンライン」での開催が初めて用意され、2021年は規模を縮小してのラスベガス(現地)開催 + オンライン開催の ハイブリット開催 となりましたね。 （現地開催の規模が小さいのか or 意外と現地参加者の申し込みが多かったのか、例年と変わらず11月後半には現地チケットはSOLD OUT(完売)していた模様です） これまでのレコチョク参加実績とイベント開催 レコチョクでは re:Invent 開催2年目となる2013年から2019年の「7年連続」で参加メンバーが入れ替わり現地参加しております。2018年にレコチョク入社した私も翌年の2019年時に参加させて頂きましたが、ラズベガスのホテルを貸し切ったカンファレンスの規模感とほぼ1週間AWSにだけ集中・注目できるイベントのボリューム感には圧倒させられました。 2020年に入りコロナ禍といわれてから海外出張の自粛を余儀なくされていたため、来年(2022年)の現地参加と現地状況がどうなるのか気になるところです・・・。 また、ラスベガス参加したメンバーによる帰国後の Re:cap イベントを開催するなども過去実施して参りました。中にはイベントを通じて交流できた会社様と合同で開催したりなど re:Invent ならではの「エンジニア交流」も密に実施してきたと思います。 connpass　(2017年〜2019年) 2019年 re:Invent 初参加した際 当時一発目のイベント(Midnight Madness) で発表されたDeepComposer。音楽キーボードから入力した数秒のメロディを機械学習技術を用いてオリジナル楽曲として自動構築してくれるサービスですが、機械学習スキルを伸ばすために設計されたサービスが大きく注目を浴びていたと思います。 (* DeepComposer のコンソール画面とワークショップでゲットした小さめの MIDI キーボード) (* 発表されたばかりの DeepComposer ワークショップに朝一並べた様子) 弊社は音楽関連のサービスを扱うということもあり、機械学習の可能性を体験すべくハンズオンのワークショップにいち早く参加し興奮していたのを今でも覚えております。最終的に機械学習の技術を使って会社内でサービス展開するには至ってはいないですが、こういう目新しいサービスや技術 / 機能には素早く手に触れて検証を続けていく姿勢でいたいですね。 2022年の参加について 今年に引き続き来年もハイブリッド開催であった場合、、、 「有料の現地参加を選ばずとも、無料でオンライン参加するのが得なのでは」 という点に悩むんだろうなと個人的に考えています。 幸運にも現地参加させて頂いた経験も踏まえると、確かに上記の意見も正しくはあるなと思いつつも、現地参加する魅力はいくつかあると考えています。 例にあげるとすれば、AWSに興味のある世界中から集まったエンジニアの熱量が肌で感じられる事とモチベーションの創出に繋がるイベントが夜通し開催され個人の意欲が高まりやすい点でしょうか。 (* 左：JTB主催の日本人参加者交流イベント (Japan Night)｜右：ラスベガス最大のフェスティバル会場で開催される野外イベント (re:Play)) オンライン参加だとセッション聴講して終わりになりがちですが、現地ではセッション聴講し終わってからもイベントが多く続き、例えば日本人参加者だけのパーティーや各種ライブ等の催し物が数多く用意されて、そこでも人脈作りや獲得できたナレッジをそのまま共有しあえる場など、常に刺激にあふれた時間を体験できる点が大きな点だなと感じています（2020年のオンライン参加を通じてどうしてもその熱量が薄れてしまったなと感じる私でした） おわりに この記事が公開されている今頃、アップデート情報を整理するのに藻掻いている自分がいるんだなとワクワクしながら締めを書いております。。。きっと多くの Re:cap イベントが開催されるんだろうと期待しつつ、少しでも現地で体験した熱量と多くのエンジニアが同時に盛り上がっている場に身を寄せて、今年の re:Invent も楽しみきりたいと思っています。本記事の内容は以上になります。ありがとうございました！ 今後の「レコチョク Advent Calendar」内には AWS サービスを使ったナレッジもいくつか記事に上がる予定ですので続いてお楽しみに！ さっそく明日のレコチョク Advent Calendar 2021 5日目は、 「AWSの負荷テストソリューション Distributed Load Testing on AWS を負荷テストで使ってみた」 です。引き続きご注目のほどよろしくお願い致します。 この記事はレコチョクのエンジニアブログの記事を転載したものとなります。

AWSSSO 属性 SSO ユーザープロファイル ${user:AD_GUID} ユーザー ID ${user:email} プライマリ E メール ${user:familyName} 姓 ${user:givenName} 名 ${user:middleName} ${user:name} 表示名 ${user:preferredUsername} 表示名 ${user:subject} ユーザー名 ミドルネームはおそらく設定すると対応すると思われる。 name　と preferredUsername が同じだったのでどちらかは姓、名をくっつけた文字列ではないか、ニックネームを設定するとどちらかが対応するのではないか、など疑ったがどちらも表示名だった。

はじめに 最近Cloudfromationを触っているのアウトプットも兼ねて投稿です。 S3バケットを作成 advent-calendar-2021という名前のバケットを作成しておきます。 Cloudformationスタックを作成 S3バケットを作成するだけの簡単なテンプレートでスタックを作成します。 AWSTemplateFormatVersion: "2010-09-09" Resources: Test: Type: "AWS::S3::Bucket" DeletionPolicy: Retain Properties: BucketName: "advent-calendar-2021" 問題点 スタック作成時に以下のエラーがでてしまいます。作ろうとしたものと同じ名前のS3バケットが既に存在しますといった趣旨の内容です。 解決方法 Cloudformationから既存のリソースをインポートします。 先程と同じYMLファイルをアップロードします。 S3バケットの名前を入力します 画面操作を進めていきリソースをインポートします。 インポートが完了しました 補足：　Cloudfromationのスタックは一旦削除して作り直しました。 インポートできるリソース一覧 Cloudformationでインポートできるリソース一覧を見つけたのでURLを貼ります。 https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html おわりに 最後までご覧いただきありがとうございました。

はじめに 前回の記事では、AWS X-Ray の概要を紹介しました。今回の記事では、JavaのフレームワークであるQuarkusとAWS X-Ray SDK for Javaを用いて実際にアプリケーションを作成し、分散トレーシングを実現する手順を紹介します。 記事の構成 本連載は以下の3部で構成されています。 AWS X-Rayによる分散トレーシング その1 (概要編) AWS X-Rayによる分散トレーシング その2 (Java編) ← 今回 AWS X-Rayによる分散トレーシング その3 (Node.js編) 環境 システム構成 今回作成したテスト用アプリケーションのシステム構成 (最終形) を以下に示します。 図中に示した通り、コンテナの実行環境にECS、テスト用のクライアントにCloud9を使用し、サービス間の呼び出しはECSサービスディスカバリ (Cloud Map、Route 53との連携) を使用しました。また、コンテナレジストリとしてECRを使用し、他の環境で開発したコンテナを持ち込んで使用しています。(そのため、ECRにアクセスするためのVPCエンドポイントや、プライベートサブネットのCloud9に接続するためのVPCエンドポイントなど、X-Ray以外のVPCエンドポイントも作成しています。) バージョン情報 使用したソフトウェアのバージョンは以下になります。 Quarkus 2.4.1.Final AWS X-Ray SDK for Java 2.10.0 X-Ray Daemon 3.3.3 Fargateプラットフォーム 1.4.0 やってみた ここからは、実際にアプリケーションを構築する手順と分散トレーシングの結果を確認する手順を記載します。なお、アプリケーションの作成は、実行環境 (前述の図) とは別で構築したインターネットに接続できる環境のCloud9で実施しました。 基本となるアプリケーションの作成 まずはQuarkusとAWS X-Ray SDK for Javaを使用して、トレース情報を取得するREST API (Service-A) を作成します。 Quarkusプロジェクトの作成 まず、ベースとなるQuarkusプロジェクトを作成します。今回はREST APIを作成するため、Quarkus公式ガイドの「Writing JSON REST Services」に従ってプロジェクトを作成します。以下のコマンドを実行することで、「service-a」フォルダが作成され、その配下にプロジェクトが作成されます。 $ mvn io.quarkus.platform:quarkus-maven-plugin:2.4.1.Final:create \ -DprojectGroupId=sample.xray \ -DprojectArtifactId=service-a \ -DclassName="sample.xray.application.resource.ServiceAResource" \ -Dpath="/servicea" \ -Dextensions="resteasy-jackson" ServiceAResourceクラスを確認すると、”Hello RESTeasy”という文字列を返すAPIを「/service-a」というパスで公開するためのソースコードが確認できます。 (なお、この段階ではこのクラスをそのまま使用します。) 依存関係の追加 次に、作成されたpom.xmlを開き、AWS X-Ray SDK for Javaを使用するための依存関係をdependencyManagement配下、および、dependencies配下に追加します。 pom.xml <?xml version="1.0"?> ... <dependencyManagement> <dependencies> ... <dependency> <groupId>com.amazonaws</groupId> <artifactId>aws-xray-recorder-sdk-bom</artifactId> <version>2.10.0</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> ... <dependency> <groupId>com.amazonaws</groupId> <artifactId>aws-xray-recorder-sdk-core</artifactId> </dependency> </dependencies> ... また、web.xmlを使用するために、「quarkus-undertow」への依存性を追加します。 $ ./mvnw quarkus:add-extension -Dextensions="quarkus-undertow" Servlet Filterの追加 受信リクエストのトレースには、X-Ray SDKが提供しているServlet Filterを使用します。Quarkusでは「resources/META-INF」配下に、以下のようなweb.xmlを作成します。 web.xml <web-app> <filter> <filter-name>AWSXRayServletFilter</filter-name> <filter-class>com.amazonaws.xray.javax.servlet.AWSXRayServletFilter</filter-class> <init-param> <param-name>fixedName</param-name> <param-value>Service-A</param-value> </init-param> </filter> <filter-mapping> <filter-name>AWSXRayServletFilter</filter-name> <url-pattern>*</url-pattern> </filter-mapping> </web-app> アプリケーションのビルド アプリケーションをECSで実行するためにビルド (コンテナ化) します。まず、「container-image-docker」への依存性を追加します。 $ ./mvnw quarkus:add-extension -Dextensions="container-image-docker" 次に、ビルドを実行します。 $ ./mvnw clean package -Dquarkus.container-image.build=true ビルドを実行すると、コンテナイメージが追加されていることが確認できます。 (なお、X-Ray Daemonを起動していないため、ビルト時のテスト用リクエストに対する処理でエラーが発生しますが、ここでは無視します。) $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE xxxxxxxx/service-a 1.0.0-SNAPSHOT xxxxxxxxxxxx 26 seconds ago 394MB … 最後に、Amazon ECR ユーザーガイドを参考に、作成したコンテナイメージをECRにプッシュします。これで、基本となるアプリケーションの作成は完了です。 アプリケーションのデプロイと実行 次に、作成したコンテナをECS上にデプロイし、X-Ray Daemon経由でトレース情報をX-Rayに送信します。なお、ECSを実行するVPCやサブネット、VPCエンドポイント、および、クライアントとなるCloud9は作成済とします。 ECSクラスタの作成 AWSマネジメントコンソールからECSを開き、クラスターの作成からECSクラスターを作成します。この際、クラスターテンプレートは「ネットワーキングのみ」を選択し、クラスター名は任意の名称を入力します。 ECSタスク用IAMロールの作成 Amazon ECS 開発者ガイドを参考に、ECSタスクが使用するIAMロールを作成します。今回はX-Ray Daemonが必要とする「AWSXRayDaemonWriteAccess」ポリシーを付与したIAMロールを作成します。 ECSタスク定義とサービスの作成 Amazon ECS 開発者ガイドとAWS X-Ray デベロッパーガイドを参考に、ECSのタスク定義を作成します。AWS X-Ray SDK for Javaのデフォルト設定は、X-Ray Daemonが同一ホスト上の2000番ポートで動作していることを前提としているため、この前提を満たすようにService-AのコンテナとX-Ray Daemonを同一のタスク定義に配置します。 タスク定義を作成したら、Amazon ECS 開発者ガイドを参考に、ECSサービスを作成します。なお、Cloud9からDNS名でサービスにアクセスできるようにサービスディスカバリ統合を有効化します。サービスディスカバリ統合を有効化してサービスを作成すると、Route53にホストゾーンが作成され、Aレコードが登録されます。 Cloud9からの実行 Cloud9でcurlコマンドを実行し、デプロイしたサービスへリクエストを送信します。 $ curl http://qiita-ecs-service-a.local:8080/servicea その後、ECSのコンソールからX-Ray Daemonのログを確認すると、トレース情報が送信されたことが確認できます。 トレース情報の確認 次に、ECSから送信したトレース情報をX-Rayのコンソールから確認します。前述の通り、X-Rayでは「システム全体のトレース情報」と「特定トレース情報の詳細」の2つを可視化できます。 システム全体のトレース情報 X-Rayのコンソールから「Service Map」を開き、時間帯を選択すると、その時間帯のトレース情報 (呼出関係、頻度、処理時間、エラー率) が可視化できます。 現時点では、クライアントからService-Aを呼び出しただけなので、クライアントとService-Aの呼出関係が表示されています。 特定トレース情報の詳細 次に、トレース情報を1つ選択し、その詳細を可視化します。コンソールから「トレース」を選択すると、トレースの一覧が表示されます。 トレースIDのリンクをクリックすると、トレースの詳細が可視化できます。 こちらも現時点では、1つのセグメントのみが表示されています。 呼出先へのトレースIDへの連携 次に、Service-Aから別のサービス (Service-B、Service-C) を呼び出し、呼出関係が可視化できることを確認します。 Service-B, Service-Cの実装とデプロイ 『基本となるアプリケーションの作成』、『アプリケーションのデプロイと実行』の手順と同様に、Service-BとService-Cを作成し、ECSにデプロイします。なお、ECSのクラスターはService-Aと同じクラスターを使用します。 Service-Aの改修 Service-Aについて、Service-BとService-Cを呼び出すように改修します。呼出先へトレースIDを連携し、一連のトレースとして扱うためには、AWS X-Ray SDK for Javaが提供するHTTPクライアントを使用して呼出処理を実装します。 まず、pom.xmlを開き、dependencies配下にHTTPクライアントを使用するための依存性を追加します。 pom.xml <?xml version="1.0"?> ... <dependencies> ... <dependency> <groupId>com.amazonaws</groupId> <artifactId>aws-xray-recorder-sdk-apache-http</artifactId> </dependency> </dependencies> ... 次に、Service-BとService-Cを呼び出すように修正します。 ServiceAResource.java package sample.xray.application.resource; import javax.ws.rs.GET; import javax.ws.rs.Path; import javax.ws.rs.Produces; import javax.ws.rs.core.MediaType; import java.io.IOException; import org.eclipse.microprofile.config.inject.ConfigProperty; import com.amazonaws.xray.proxies.apache.http.HttpClientBuilder; import org.apache.http.impl.client.CloseableHttpClient; import org.apache.http.client.methods.HttpGet; import org.apache.http.client.methods.CloseableHttpResponse; import org.apache.http.util.EntityUtils; import org.jboss.logging.Logger; @Path("/servicea") public class ServiceAResource { private static final Logger logger = Logger.getLogger(ServiceAResource.class); @ConfigProperty(name="serviceb.url") String serviceBUrl; @ConfigProperty(name="servicec.url") String serviceCUrl; @GET @Produces(MediaType.TEXT_PLAIN) public String hello() { try ( CloseableHttpClient httpClient = HttpClientBuilder.create().build()) { HttpGet httpGet = new HttpGet(serviceBUrl); try (CloseableHttpResponse response = httpClient.execute(httpGet)) { String text = EntityUtils.toString( response.getEntity() ); logger.info("Response from Service-B : " + text); } httpGet = new HttpGet(serviceCUrl); try (CloseableHttpResponse response = httpClient.execute(httpGet)) { String text = EntityUtils.toString( response.getEntity() ); logger.info("Response from Service-C : " + text); } } catch (IOException e) { throw new RuntimeException(e); } return "Hello RESTEasy"; } } HttpClientBuilderがAWS X-Ray SDK for Javaで提供されているクラスで、このクラスを使用してHttpClientを作成します。作成したHttpClientはApache HttpClientと同様に使用することができます。 (なお、serviceBUrlとserviceCUrlはプロパティファイルから取得するように設定しています。) application.properties serviceb.url=http://qiita-ecs-service-b.local:8080/serviceb servicec.url=http://qiita-ecs-service-c.local:8080/servicec 結果の確認 改修した Service-A のコンテナイメージを作成し、ECSにデプロイします。そして、Cloud9でcurlコマンドを実行し、リクエストを送信します。 $ curl http://qiita-ecs-service-a.local:8080/servicea 次にX-Rayのコンソールを開き、トレース情報を確認すると、以下のような呼出関係が確認できます。 ログへのトレースIDの出力 最後に、ログにトレースIDを出力し、各サービスが出力したログを紐づけて確認できるようにします。なお、この手順は3つのサービス全てに実施する必要があります。 依存性の追加 ログへのトレースIDの出力は、MDC (Mapped Diagnostic Context) にトレースIDを挿入することで実現します。これはX-Ray SDK for Javaから提供されているSegmentListenerで実現するため、まず、dependencies配下に必要な依存関係を追加します。 pom.xml <?xml version="1.0"?> ... <dependencies> ... <dependency> <groupId>com.amazonaws</groupId> <artifactId>aws-xray-recorder-sdk-slf4j</artifactId> </dependency> </dependencies> ... ServletContextListenerの実装 次に、ServletContextListenerを実装したクラスを作成し、SegmentListenerを組み込んだX-Ray Recorderを登録する処理を実装します。 XrayListener.java package sample.xray.application.listener; import javax.servlet.ServletContextEvent; import javax.servlet.ServletContextListener; import com.amazonaws.xray.AWSXRay; import com.amazonaws.xray.AWSXRayRecorderBuilder; import com.amazonaws.xray.slf4j.SLF4JSegmentListener; public class XrayListener implements ServletContextListener { @Override public void contextInitialized(ServletContextEvent event) { AWSXRayRecorderBuilder builder = AWSXRayRecorderBuilder .standard() .withSegmentListener( new SLF4JSegmentListener()); AWSXRay.setGlobalRecorder(builder.build()); } @Override public void contextDestroyed(ServletContextEvent event){ //Do nothing } } 作成したリスナーをweb.xmlに設定します。 web.xml <web-app> ... <listener> <listener-class>sample.xray.application.listener.XrayListener</listener-class> </listener> </web-app> ログフォーマットの定義 最後に、MDCに挿入したトレースIDをログに出力するために、application.propertiesにログフォーマットを定義します。 application.properties quarkus.log.console.format=%d{yyyy-MM-dd HH:mm:ss.SSS} %-6p [%c{3.}#%M] [%X{AWS-XRAY-TRACE-ID}] %m %n これで、アプリケーションの改修は完了です。なお、デフォルトのResourceクラスにはログを出力する処理が含まれていないため、ログの出力処理を実装するのを忘れないでください。 結果の確認 各サービスのコンテナイメージを作成し、ECSにデプロイします。そして、Cloud9でcurlコマンドを実行し、リクエストを送信します。 $ curl http://qiita-ecs-service-a.local:8080/servicea ECSのコンソールからService-Aのログを参照すると、トレースID(1-618b5ac8-c32cea0094537acc6dd2bc50)が出力されていることが確認できます。 CloudWatch Logs Insightsからの検索 最後に、同一リクエストに対して、各サービスが出力したログを紐づけて確認します。 ECSのデフォルトの設定では、ログはCloudWatch Logsに送信されます。この際、タスク定義ごとに異なるロググループに送信されるため、タスク定義を跨ってログを検索するためにはCloudWatch Logs Insightsを使用します。CloudWatch Logs Insightsでは、まず、以下のようにロググループの選択で複数のロググループを選択します。 次に、以下のように検索条件を指定して実行します。 fields @message | filter @message like "1-618b5ac8-c32cea0094537acc6dd2bc50" | sort @timestamp asc 結果は以下のようになります。同一リクエストによってService-A、Service-B、Service-C から出力されたログが時系列に表示されていることが確認できます。 まとめ 以上、AWS X-Ray を使用して、Javaアプリケーションの分散トレーシングを実現する方法を紹介しました。次回の記事では、Node.js 編をお届けします。 参考資料 本記事に執筆にあたっては以下の資料を参考にいたしました。 AWS X-Ray デベロッパーガイド https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/aws-xray.html Amazon ECS 開発者ガイド https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/Welcome.html Quarkus https://quarkus.io/ Amazon Web Services、および、その他のAWS 商標は、米国およびその他の諸国におけるAmazon.com, Inc.またはその関連会社の商標です。 Javaは、Oracle Corporation、および、その子会社、関連会社の米国及びその他の国における登録商標です。 その他、本資料に記述してある会社名、製品名は、各社の登録商品または商標です。

はじめに DevOpsの重要な要素である俊敏性 (Agility) を実現するためには、CI / CDプロセス以外に目を向けることも重要です。例えば、アプリケーションアーキテクチャの分野では、マイクロサービスアーキテクチャが注目されています。 マイクロサービスアーキテクチャとは、簡単に言うと「単機能のサービスを組み合わせて、1つのアプリケーションを構成するアーキテクチャ」です。マイクロサービスアーキテクチャを採用すると、1つ1つのサービスのサイズが小さくなり、改修が容易となるため、新機能を迅速にリリースできるようになります。 一方で、マイクロサービスアーキテクチャは各サービスが連動して動作する分散システムのため、可観測性 (Observability) を実現すること重要になってきます。可観測性とは、簡単に言うと「システムの状態を観測できる能力」で、マイクロサービスアーキテクチャでは、主に、ログ、メトリクス、分散トレーシングの3つで構成されます。 本連載では、可観測性の中でも分散トレーシングに着目し、AWS上で分散トレーシングを実現するAWS X-Rayの使用方法を紹介します。 記事の構成 本連載は以下の3部で構成されています。 AWS X-Rayによる分散トレーシング その1 (概要編) ← 今回 AWS X-Rayによる分散トレーシング その2 (Java編) AWS X-Rayによる分散トレーシング その3 (Node.js編) 今回は概要編ということで、AWS X-Rayの概念や機能を紹介します。次回以降の記事では、実際にアプリケーションを構築する手順を紹介します。 AWS X-Rayの概要 AWS X-Rayでできること AWS X-Rayを使用することで、以下の3点を実現できます。 システム全体におけるサービス間の呼出関係の可視化 特定リクエストにおけるサービス間の呼出関係の可視化 (特定リクエストの処理経路の可視化) 特定リクエストで出力された一連のログの検索 操作手順等は次回以降の記事に記載するため、本記事ではそれぞれの機能のみを紹介します。 システム全体におけるサービス間の呼出関係の可視化 まず、「システム全体におけるサービス間の呼出関係の可視化」です。これは、システム内の各サービスの応答時間と呼出頻度、エラー率を見ることができます。これにより、応答が遅くなっているサービスや障害が発生しているサービスの有無など、システム全体の概況を把握できます。 例えば、以下の図では Service-C の一部のリクエストでエラーが発生していることが分かります。 特定リクエストにおけるサービス間の呼出関係の可視化 次に、「特定リクエストにおけるサービス間の呼出関係の可視化」です。これは、X-Rayに連携されたトレースを1つ選択し、そのトレースにおけるサービスの呼出順序やそれぞれの処理時間を見ることができます。これにより、特定リクエストで応答が遅延した場合やエラーが発生した場合に、その原因箇所を知るための一助とすることができます。 例えば、以下の図では Service-A から Service-B、Service-C の順で呼び出しており、Service-C でエラーが発生したことが確認できます。 特定リクエストで出力された一連のログの検索 最後は、「特定リクエストで出力された一連のログの検索」です。マイクロサービスアーキテクチャでは各サービスは独立してログを出力するため、特定のリクエストで出力されたログを紐づけて出力するには、リクエストごとに割り当てられる一意のキーが必要となります。X-RayではリクエストごとにトレースIDを付与するため、このIDをログに出力すると、当該リクエストで出力されたログを紐づけることができます。 (一連のログをまとめて検索するには、各サービスが出力したログを集約して検索するための仕組みが必要となります。) 例えば、AWSではCloudWatch Logs Insightsを使用して、以下のように Service-A、B、C の3つのログをまとめて表示することができます。これにより、特定リクエストで応答が遅延した場合やエラーが発生した場合に、その原因調査をスムーズに行うことができます。 トレース情報 X-Rayではトレース情報を以下の単位で管理します。 No 単位 説明 1 トレース 1つのリクエストから生成された全てのセグメントの集合。1つのリクエストで複数サービスを呼び出す場合、それらのセグメントは同じトレースに含まれます。 2 セグメント 1つのアプリケーションでのトレース情報。例えば、REST APIやLambda関数の1回の実行が1つのセグメントとなります。 3 サブセグメント セグメントの一部を任意のタイミングで区切った区間。処理時間を注視したい特定処理をサブセグメントとして切り出すことができます。 また、X-Rayのトレースは一意なトレースIDを持ちます。このトレースIDをサービス間で引き渡すことで、一連のセグメントを1つのトレースとして管理できます。なお、トレース情報の保存期間は30日間です。 X-Rayが収集するトレース情報 X-Rayが収集するトレース情報には主に2つのパターンが存在します。1つはX-Rayと統合されているAWSサービスが収集するトレース情報で、これらは簡単な設定を行うだけでトレースを取得できます。もう1つは、任意のアプリケーションが収集するトレース情報で、これらはX-Ray SDKを使用してアプリケーション内に作りこむ必要があります。 X-Rayと統合されているAWSサービス： Lambda APIGateway Elastic Beanstalk ELB(ALB) EventBridge SNS SQS X-Ray SDKを使用してアプリケーションで収集するトレース情報： Incoming HTTP(S) (TomcatやSpring、Express、Django、Flask等の各言語の代表的なWebフレームワークをサポート) Outgoing HTTP(S) (Apache HttpComponentsやNode.jsのhttp/httpsモジュールをサポート) SQL呼出 (PostgreSQLかMySQLのクライアントからのSQL実行) AWS SDKによるAWSサービス呼出 (DynamoDB、S3、SQS。これら以外は汎用ノードとして表示される) その他カスタムセグメント (X-Ray SDKでカスタムセグメントを作成することにより任意の処理データを収集可能) アプリケーションのトレースに必要な機能 X-Rayを使用して、アプリケーションの分散トレーシングを実現するためには、前述のトレース情報の取得だけでなく、以下の機能が必要となります。 No 機能 説明 1 トレース情報の取得 X-Ray SDKを使用してアプリケーションで実現します。例えば、Incoming HTTP(S)のトレース情報を取得する場合、X-Ray SDKがセグメントを作成し、トレースIDが採番されていない場合には、併せて採番します。また、Outgoing HTTP(S)やSQL呼出はSDKが提供するクライアントモジュールを使用することで、トレースIDが連携され、一連のトレースとして記録できます。 2 トレース情報の送信 X-Ray SDKを使用したアプリケーションとX-Ray Daemonで実現します。X-Ray SDKは記録したセグメントをX-Ray Daemonに送信し、X-Ray DaemonがAWS X-Ray APIに送信します。 3 ログへのトレースIDの出力 AWS X-Ray SDKを使用してアプリケーションで実現します。SDKが提供するセグメントリスナーを使用することで、トレースIDをログのMDCに設定できます。 まとめ 本記事では、AWS X-Rayによる分散トレーシングの概要を紹介しました。次回以降の記事では実際にアプリケーションを作成する手順を紹介します。 Amazon Web Services、および、その他のAWS 商標は、米国およびその他の諸国におけるAmazon.com, Inc.またはその関連会社の商標です。 Javaは、Oracle Corporation、および、その子会社、関連会社の米国及びその他の国における登録商標です。 その他、本資料に記述してある会社名、製品名は、各社の登録商品または商標です。

AWS re:Invent 2021にて、S3の新たなストレージクラスの追加が発表されました。 Amazon S3 新規ストレージクラス Glacier Instant Retrieval ストレージクラスが追加 S3 Glacier → S3 Glacier Flexible Retrieval に名称変更 新規ストレージクラス（Glacier Instant Retrieval）の特徴 アーカイブ向け（四半期に一度程度のアクセス頻度） スタンダードや標準-IAと同様ミリ秒単位のアクセス 標準-IAと比べ最大68％のストレージコスト削減 ストレージクラス比較 今回追加されたストレージは、標準 - IA と Glacier Flexible Retrieval （旧 Glacier）の間に位置しています。 下表のストレージクラスのうち、下に行くほど以下特徴があります。 ストレージ料金（月額データ料金）が安い データ取得料金が高い 取得時間が長い 想定アクセス頻度が低い ストレージクラス ストレージ料金 1 データ取得料金 2 取得時間 想定アクセス頻度 標準 $0.025 $0.0047 ミリ秒単位 1か月に1回以上 標準 - IA（標準 - 低頻度アクセス） $0.0138 $0.01 ミリ秒単位 1か月に1回 Glacier Instant Retrieval $0.005 $0.02 ミリ秒単位 四半期に1回 Glacier Flexible Retrieval （旧 Glacier） $0.0045 $0.0343 数分～数時間 1年に1回 Glacier Deep Archive $0.002 $0.065 数時間 1年に1回未満 ※ストレージクラスの比較を目的とした表です。 　料金はデータ量やリージョンで変わってきますが、ここでは代表値を載せてます。 ※Intelligent-Tiering、1 ゾーン – IA、Outposts ストレージクラスはアクセス頻度以外の 　要素も入ってくるので対象外としています。 （2021/12/03現在） 　　S3の料金ページなど、日本語版のサイトは上記内容が更新されていないので注意です。 　　言語を英語に変えるとGlacier Instant Retrievalが載ってます。 参考サイト https://dev.classmethod.jp/articles/reinvent2021-amazon-s3-glacier-instant-retrieval-storage-class/ 東京リージョン、最初の50TB/月の料金を記載。GB単位。 ↩ 東京リージョン、PUT・COPY・POST・LISTリクエストの料金を記載。1,000リクエスト単位。 ↩

前回のEC2デプロイ①に続き、今回はRDSの作成についてご紹介していきます！ RDSを作成 1.サービス画面から「RDS」で検索し、RDSコンソール画面にアクセス。 2.左メニューバーの「データベース」にアクセス→「データベースを作成」で各項目入力。 ※注意点は、バージョンをポートフォリオのバージョンに合わせることと、テンプレートを「無料利用枠」にすること。 3.「接続」までスクロール→赤線枠の箇所を入力。 4.「追加設定」までスクロール→「最初のデータベース名」を入力→一番下までスクロールして「データベースを作成」 5.数分したらDBが作成完了→作成したDB（database-1)をクリック 6.作成された「VPCセキュリティグループ」をクリック。 7.「セキュリティグループ」をクリック→「インバウンドのルールを編集」をクリック 8.EC2インスタンス作成時に設定したセキュリティグループを選択。 すると、赤字でエラーメッセージが出ます。 その対処として、一度ルールを削除してから再度ルールを追加します。 接続 1.ターミナルからインスタンスに接続。 .ssh $ ssh -i "sample-key.pem" ec2-user@ec2-52-68-186-250.ap-northeast-1.compute.amazonaws.com Last login: Thu Dec 2 13:52:30 2021 from p3014131-ipoe.ipoe.ocn.ne.jp __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ 2.パッケージのアップデート [ec2-user@ip-172-31-45-44 ~]$ sudo yum update -y 読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd amzn2-core | 3.7 kB 00:00:00 No packages marked for update 3.MySQL、Git、Apache、cURLをインストール [ec2-user@ip-172-31-45-44 ~]$ sudo yum -y install mysql git httpd curl ・・・ #省力 完了しました! 4.nginx起動 [ec2-user@ip-172-31-45-44 ~]$ sudo systemctl start nginx.service #起動 [ec2-user@ip-172-31-45-44 ~]$ sudo systemctl status nginx.service #起動確認 ● nginx.service - The nginx HTTP and reverse proxy server Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled) Active: active (running) since 木 2021-12-02 12:38:54 UTC; 5h 22min ago Main PID: 1217 (nginx) CGroup: /system.slice/nginx.service ├─1217 nginx: master process /usr/sbin/nginx └─1218 nginx: worker process 12月 02 12:38:54 ip-172-31-45-44.ap-northeast-1.compute.internal systemd[1]: St... 12月 02 12:38:54 ip-172-31-45-44.ap-northeast-1.compute.internal nginx[1211]: n... 12月 02 12:38:54 ip-172-31-45-44.ap-northeast-1.compute.internal nginx[1211]: n... 12月 02 12:38:54 ip-172-31-45-44.ap-northeast-1.compute.internal systemd[1]: St... Hint: Some lines were ellipsized, use -l to show in full. 5.MySQLに接続 #mysqlログインコマンド $ mysql -h database-1.csqevja7nem5.ap-northeast-1.rds.amazonaws.com -P 3306 -u admin -p 「database-1.csqevja7nem5.ap-northeast-1.rds.amazonaws.com」の部分は、RDSコンソールで作成したDBをクリックすれば、エンドポイントから確認できます。 また、ログインコマンド実行後にパスワードの入力を求められますが、そちらは自身で設定したマスターパスワードになります。 ※もしマスターパスワードを忘れた場合はこちらの手順で変更できます [ec2-user@ip-172-31-45-44 ~]$ mysql -h database-1.csqevja7nem5.ap-northeast-1.rds.amazonaws.com -P 3306 -u admin -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MySQL connection id is 24 Server version: 8.0.23 Source distribution Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MySQL [(none)]> show databases; #DB確認 +--------------------+ | Database | +--------------------+ | information_schema | | laravel_zaiko | | mysql | | performance_schema | | sys | +--------------------+ 5 rows in set (0.00 sec) show databases;で作成したDBを確認し、作成したDB（laravel_zaiko）が存在してれば問題ありません！ 続く とりあえずここまででDBの作成と接続は完了です！ 次回はLaravelの起動を行っていきます！ 参考記事

1.概要 自分自身が業務をするときに少しつまずいたので、 Windows10にて、AWS CLIからコマンドでMFAをして接続する方法についてまとめました。 ブラウザからはMFAをしてAWSにログインできるが、 AWS CLIからの接続方法が分からない人に読んでいただけると幸いです。 また、この記事が面白いと思った方は高評価、チャンネル登録をお願いします！ (*^^)v 参考URL https://aws.amazon.com/jp/premiumsupport/knowledge-center/authenticate-mfa-cli/ 2.そもそもMFAとは MFAとはMulti-factor authentication（多要素認証）の頭文字で、 以下の情報の中から2つ以上を必要とする認証のことです。 知識情報（例：ユーザ名、パスワード） 所持情報（例：スマホで確認できるコード） 生体情報（例：指紋） 従来のユーザ名、パスワードだけの認証よりもセキュリティが向上します。 参考URL https://moconavi.jp/blog/2021/06/5812/ 3.前提条件 前提条件を以下に記載します。 Windows10を使用していること IAMユーザの作成が完了し、MFAをする設定が有効化されていること スマホでMFAコードが確認できること AWS CLIのバージョン2をPCにインストールしていること AWS CLIにIAMユーザのアクセスキー、シークレットアクセスキーの設定が完了していること 4.手順 本題となりますが、以下にAWS CLIでMFAをする方法について記載します。 4.1. スマホにてMFAのコードを確認する 4.2. AWS CLIにて以下のコマンドを実行する aws sts get-session-token --serial-number arn:aws:iam::(AWSアカウントIDの数字12桁):mfa/(IAMユーザ名) --token-code (MFAのコード6桁) ※コマンドを打ち終わる前にMFAのコードが時間切れになった場合は、再度手順4.1を実行してください 4.3.コマンド実行結果として、以下が返ってくることを確認する { "Credentials": { "AccessKeyId": "(アクセスキーの情報)", "SecretAccessKey": "（シークレットアクセスキーの情報）", "SessionToken": "（セッショントークンの情報）", "Expiration": "(セッショントークンの有効期限)" } } 4.4.コマンド実行結果をメモ帳等にコピーする 4.5.AWS CLIにて以下のコマンドを実行する set AWS_ACCESS_KEY_ID = (手順4.3で確認したアクセスキーの情報) set AWS_SECRET_ACCESS_KEY = (手順4.3で確認したシークレットアクセスキーの情報) set AWS_SESSION_TOKEN = (手順4.3で確認したセッショントークンの情報) 以上でMFAが有効の場合でもAWS　CLIからコマンドを使用することができるようになります。 また、AWS CLIを再起動すると接続できなくなりますが、 セッショントークンの有効期限内であれば再度手順4.5を実行すれば接続できます。 5.補足手順 再起動のたび手順4.5を実行するのが手間な場合は手順4.5の代わりに以下の手順5.1~5.4を実行してください。 セッショントークンの有効期限内であれば、複数回再起動しても最初から接続できる状態となります。 ※セッショントークンの有効期限が切れた場合は、以下のコマンドを実行し、AWS CLIを再起動し、手順4.1から実施してください setx AWS_PROFILE default 5.1.エクスプローラを開き、C:\Users\user.aws\credentialsをメモ帳等で開く 5.2.末尾に以下を追記し、保存する [(プロファイル名)] aws_access_key_id = (手順3で確認したアクセスキーの情報) aws_secret_access_key = (手順3で確認したシークレットアクセスキーの情報) aws_session_token = (手順3で確認したセッショントークンの情報) 5.3.AWS CLIにて、以下のコマンドを実行する setx AWS_PROFILE (手順7で入力したプロファイル名) 5.4.AWS CLIを再起動する