re:Inventとは

re:Inventとは、アマゾン・ウェブ・サービス（AWS）がラスベガスで年に一度開催しているグローバルカンファレンスです。2012年から毎年開催されており、今年で8回目の開催となります。2019年12月2～6日の5日間の日程で、3,000+のセッション、全世界から65,000+、日本からは1,700+の参加人数となりました。

BTCは2017年のre:Inventから参加し、2018年のre:Invent（参加レポートはこちら）に引き続き今年は5名が現地を訪れ、キーノートを始めとした多くのセッション、ワークショップ等に参加してきました。re:Invent 2019前後のUpdateと合わせて、多くの新サービス、新機能がリリースされていますので、我々が注目しているサービスについて、現地の状況を交えご紹介したいと思います。

Keynote

毎年、キーノート（基調講演）で多くの新サービスが発表されますが、今年も多くの新サービスの発表、事例の紹介が行われました。

コンピューティング環境の進化

AWSのコンピューティング環境の根幹を担うEC2インスタンスについて、仮想化ハイパーバイザーのAWS Nitro Systemに対して、AWSは継続的に投資を行い、再開発を行った結果、ベアメタルで構成されたシステムと区別できないほど高いパフォーマンスを低コストで実現できるようになりました。

また、AWSは独自のチップの設計、構築を行い、AWS Gravitonと呼ばれるアームベースのチップを昨年発表しました。今年はAWS Graviton2を搭載した新世代のインスタンスであるM6g、R6G、およびC6gインスタンスを発表しました。旧インスタンスのM5、C5、R5と比較して、40%の価格性能比の性能向上が図られています。

機械学習の開発環境の整備

今年のre:Inventでは機械学習に関する発表が目白押しとなりました。SageMakerの統合開発環境であるSageMaker Studio、共同開発のためのSageMaker Notebook、機械学習の前処理後処理を担うSageMaker Processingなど、機械学習関連の多くの新サービスが一気に追加となりました。

機械学習に関する開発環境が一気に整備されたことで、2020年は機械学習関連の開発や事例が一気に出てくるのでは無いでしょうか。

メインフレームからマイクロサービスへ：Vanguard社の事例

クラウドへのマイグレーション事例として、Vanguard社の発表がありました。発表の全量はYoutubeで動画が公開されていますが、内容を簡潔にまとめてご紹介したいと思います。

Vanguard社のクラウドジャーニー
– 6年前にクラウドへの移行を開始。当初はプライベートクラウドへの移行を考えていたが、構築期間、コストの問題からパブリッククラウドとしてAWSを選択
– 推進体制としてクラウド推進チームを組成してプロジェクトを推進
– モノリシックなオンプレのシステム（仮想化もされていない）からパブリッククラウドへの段階的な移行を実施
– セキュリティガイドラインに従い、セキュリティネットワーク（VPC）の構築からスタート
– ホストコンピュータにつながった分散キャッシュシステム、キャッシュシステムと連動して動くPaaS環境をVPC内に移行
– HadoopをEMRに移行
– さらなるセキュリティ対応、Secret Manager(鍵保管)、Macie(機械学習セキュリティ)、AWS Shield Advance(DDoS対策)の構築
– ホストコンピュータのデータ変更をCDCを使ってキャプチャし、Aurora RDSに連携
– DynamoDBを追加し、分散キャッシュをDynamoDBに移行、また、データストリームもKinesisを使って取り込む
– ECS(Fargate)を導入し、PaaSを一部コンテナ化、その後アプリケーションもすべてコンテナ化し

Vanguard社はメインフレームを含むオンプレシステムのクラウド移行により、システムの維持にかかるコストを30％削減、システムの開発にかかるコストを30%削減、システムのリリースの速度を20倍に高速化を達成しました。
現在のシステム構成では、一部のメインフレームのシステムを除き、全てAWSクラウド上にシステムが構築され、多くのアプリケーションはFargateのコンテナ上で動作し、また、AWSが提供するマネージドサービスを活用して、クラウドネイティブな基盤にシステムが構築されています。

Vanguard社の現在のシステム構成（発表資料より弊社で書き起こし）

ここからは、いくつかのカテゴリについて新サービスとアップデートを紹介していきます。

機械学習

今回のRe:Inventでは、AI関連サービス追加やML関連サービスの機能拡張の発表が非常に多く、AWSが今力を入れている分野の筆頭がAI/MLなのだろうという印象を強く受けました。特にSageMakerシリーズの開発者向け機能が多い点から、開発者の利便性を重視していることがわかりました。

Amazon SageMaker
Amazon SageMakerはML関連のサービスの総称となっていますが、今回のre:InventではSageMaker関連サービスと連携可能な統合開発環境であるAmazon SageMaker Studioが発表されました。これは、Webブラウザ上で動作するものです。

Amazon SageMaker Studio

また、SageMaker Studioと連動する新サービスが複数発表されました。

＜引用＞https://pages.awscloud.com/rs/112-TZM-766/images/3_reinvent2019_wrap-up.pdf

従来の課題に対する解決策として新サービスを開発している、というスタンスが強く伺えます。また、これらすべてがSageMaker Studioから連携できるサービスとなっていることからも、AWSがいかに開発者の利便性を向上することに力を入れているかがわかります。
2019年12月時点ではプレビューのステータスとなっており、オハイオリージョンでしか利用できず、実際にSageMaker Studioドメインを作成すると、マネジメントコンソール上で削除できないなど、細かいところにはまだ手が回ってない印象を受けましたが、GAの際は東京リージョンでも利用できるようになることを祈ります。

ストレージ、データベース

ストレージ・データベースの分野については新規サービス発表もありましたが、既存サービスに関する発表も新サービスの発表と比べて遜色なく、既存ユーザへの利便性提供という観点でAmazonの顧客至上主義が強く感じられるものでした。

Amazon S3 Access Points
従来、複数のアプリケーションが同一のS3バケットにアクセスするような構成にてそれぞれのアプリケーションに対して個別のアクセス制限をしたいというようなセキュリティ要件を実現するには、1つのS3バケットポリシーですべてのアプリケーションに対してポリシーの設定をする必要がありました。この場合、アプリケーション数が増えてきたときにS3バケットポリシーが煩雑になるという課題がありました。
そのような課題の解決策として、Amazon S3 Access Pointsが提供されました。本機能により、S3バケットをアクセスポイントという単位に分割し、アクセスポイント単位でアクセスポリシーを編集できるようになります。
既存環境をアクセスポイントで分割する場合は、アプリケーションが指定する先をS3バケットからS3アクセスポイントに変更することになるためアプリケーションの修正が必要となりますが、新規環境構築であればS3アクセスポイントでの管理の方がインフラをシンプルに保つことができそうです。

Amazon RDS Proxy
DBのコネクションプールというと、Javaアプリケーションサーバの多くには実装されていますが、WebサーバとPHPを組みあわせるシステム構成では実装されてないことがしばしばあります。そのような場合、PHPの各プロセスからDBに都度コネクションが作成されることとなります。また、LambdaからDBに接続する場合も、Lambda自体にコネクションプーリングするような機能はないため、同様の処理が行われます。
このような構成だと、負荷が増えたときにDBへのコネクション数が増えて、DBの負荷が高くなることが問題となり得ます。この問題の解決策となるサービスとして、RDS Proxyが発表されました。

＜引用＞https://aws.amazon.com/jp/rds/proxy/

上図のような構成とすることで、アプリケーションでの負荷上昇・プロセス数増加が直接DBへのコネクション数には影響せず、RDS Proxyで制御できるようになります。
当面、対応するDBエンジンはMySQLのみとのことですが、今後増えていくことが期待されます。

数か月前に発表された「Lambda 関数が VPC 環境で改善されます」(https://aws.amazon.com/jp/blogs/news/announcing-improved-vpc-networking-for-aws-lambda-functions/)による利便性向上と合わせて、今後はLambda-RDS構成の採用率が上がり、システムのサーバレス化がこれまで以上に促進されることになりそうです。

Amazon Aurora: Machine Learning
Amazon Aurora(MySQL Compatibility)ではこれまで、ストアドプログラムからLambda関数を呼び出す機能が追加されるなど、RDS for MySQLと機能面での差別化が進められてきましたが、今回更にSageMakerやComprehendをRDSからSQLで呼ぶための機能が追加されました。このような、既存サービスとの融合がクラウドベンダーとして先行しているAWSの強みのように感じられます。
Wrap-upセッションでは、テーブルに格納された商品レビューコメントが商品に対して好意的か否かをComprehendと連携してSQLで取得するというような説明がされていました。
RDSとAuroraを比較すると、RDSの方がDBの新しいバージョンへの対応が早いため、DBの新しい機能を使いたい場合はRDS、AWSの他サービスとの連携をしたい場合はAuroraを選ぶ、など技術選択の際の検討項目が増えてきました。

ネットワーク

ネットワークは、VPCをはじめ、AWS上での環境構築時には欠かせない分野です。現状でもAWSとオンプレミス間の通信だけでなく、AWS上でのアカウント間やリージョン間の通信など様々なユースケースに対応していますが、より柔軟な通信を実現しようとすると、設定が複雑化する傾向にありました。今回はTransit Gatewayを中心に以下3件のサービスアップデートについて紹介します。

Transit Gateway マルチキャスト
これまではマルチキャストのワークロードを作成するためには、特別な回避策を用いて実現していました。（GRE tunnel、L2 Peer-to-Peer VPN、Multi-Unicasting）
しかし、今回のアップデートによりTransit Gatewayをマルチキャストルータとして扱うことが可能となりました。Transit Gatewayに接続されたVPCのサブネット間でマルチキャストトラフィックのルーティングをサポートし、複数の受信インスタンス宛のトラフィックを管理できるようになりました。

Transit Gateway inter-Region Peering
これまでは複数のアカウントや他VPCにまたがったプライベートなネットワークを形成する場合、VPCピアリングやPrivateLinkを作成して管理していました。
ただし、この方法では接続先が増加する度に、個別にVPCピアリングやPrivateLinkを作成しないといけないため、管理が複雑化する傾向にありました。
本アップデートにより、Transit Gateway間でプライベートな相互アクセスが可能（リージョンをまたがった通信も可能）となり、管理がTransit Gateway内で一本化できるため、上記の複雑さを軽減することが可能となりました。

Transit Gateway Network Manager
前述のTransit Gateway inter-Region Peeringのアップデートに合わせ、Transit Gateway Network Managerが発表されました。Transit Gatewayで作成された環境を視覚化および監視できるようにしたサービスです。
本サービスとinter-Region Peeringを組み合わせて利用することにより、Transit Gatewayを利用して構築したAWSリージョン間やDirect Connectのネットワークの監視や可視化、つまりグローバルネットワークのモニタリングが可能となりました。

＜引用＞https://aws.amazon.com/jp/blogs/news/new-for-aws-transit-gateway-build-global-networks-and-centralize-monitoring-using-network-manager/

データ分析

AWSではデータ分析の中心として、S3をデータレイクとすることを提唱しています。
ただ、S3をデータレイクとする際には、データの加工処理を行うなど必ずしも親和性は高くありませんでした。
今回のアップデートではRedshiftのサービスを中心に、データレイクの効率化やデータ分析を行う際の各種AWSサービスとの親和性が高まった以下の3サービスについて紹介します。

Amazon Redshift Data Lake Export
Amazon Redshift Data Lake Exportは、Parquet形式でAmazon S3にエクスポートすることができるサービスです。ParquetはCSVのような行志向ではなく、分析に効率的な列志向のデータ形式です。これまではGlueを用いて変換する必要がありましたが、本アップデートで不要となりました。
この形式でS3をデータレイクとすることにより、他の分析系サービス（Redshift SpectrumやAmazon Athena）との連携が容易となるだけでなく、S3のストレージ使用量の軽量化やデータ抽出速度の高速化を図ることが可能となりました。

Amazon Redshift Federated Query
Amazon Redshift Federated Queryにより、RDS PostgreSQLやAurora PostgreSQLなどのデータベースに格納されているデータに直接アクセスすることが可能になりました。また、S3のデータにも直接アクセス可能となり、ETL処理を介さずにデータを抽出することが可能となりました。さらにクエリの抽出結果をS3にアップロードすることも可能です。
S3にデータをアップロードし、QuickSightと連携することにより可視化が可能となるなど、データ分析の幅は広がりました。

＜引用＞https://aws.amazon.com/jp/blogs/news/new-for-amazon-redshift-data-lake-export-and-federated-queries/

Amazon Athena　Federated Query
上記のRedshift Federated Queryに加えてAthenaでもFederated Queryが可能となりました。
AthenaはS3上のデータに対してSQLを利用して抽出するサービスです。本機能により、Athenaを利用してS3だけでなくLambdaを介すことによって、CloudWatch logsやRDS、Redisなどのデータソースからのデータ抽出が可能となりました。AthenaからS3以外のデータに対して直接アクセス可能となったことにより、「SQLだけ」で横断的なデータ検索が可能となりました。
ログの調査をする際など、RDSやCloudWatch logsなど別々のリソースにアクセスを行わずとも調査できるのは大きな利点と言えそうです。

＜引用＞https://aws.amazon.com/jp/blogs/news/query-any-data-source-with-amazon-athenas-new-federated-query/

コンテナ

コンテナは、仮想マシンと比べてオーバーヘッドが小さく高速にスケール・イン／アウトが可能です。また、アプリケーションの実行環境をコンテナイメージとしてパッケージングすることで、アプリケーションを動作させる環境の影響を受けません。昨今、これらのメリットを活かして本番環境をコンテナで運用するケースも多くなってきました。その結果、より多くのコンテナを管理する必要が出てきました。AWS環境では、AWS独自のコンテナオーケストレーションツールであるAmazon ECS（Elastic Container Services）だけでなく、昨年6月に正式リリースされたkubernetesベースのマネージドサービスであるAmazon EKS（Elastic Kubernetes Service）も利用できます。クラウドネイティブを主導するCNCF（Cloud Native Computing Foundation）のロードマップでも、コンテナ化（Containerization）はクラウドネイティブの前提条件（※必須Step）として定義されており、今後、さらにコンテナの利用が広がっていくものと考えられます。

＜引用＞https://github.com/cncf/landscape/blob/master/README.md#trail-map

Amazon EKS on AWS Fargate
Amazon EKSを利用して、KubernetesのPodsをAWS Fargateで稼働させることが可能になりました。これによりPodsのインフラ管理やプロビジョニングなしにKubernetesベースのアプリケーションを実行できるようになり、Kubernetesのオペレーションの専門家がいなくてもセキュアで拡張可能なクラスタを容易に構成できるようになります。これまでのように、ワーカーノードのEC2インスタンスをメンテナンスする手間もなくなるため運用作業負荷が軽減されます。

Amazon EKS on AWS Fargate

このサービスは既にAsia pacific(Tokyo)を含むUS East(N. Virginia)、US East(Ohio)、Europe(Ireland)の各リージョンで使用できるようになっています。この新リリースにより、これまで運用作業負荷を気にしてKubernetesの採用に踏み出せなかった企業にとっての技術的な障壁が下がったため、価格面での折り合いさえつけば、今後は日本国内でもKubernetesを利用する企業が増えるのではないでしょうか。

AWS Fargate Spot
Fargateの価格から最大70％の割引で、中断耐性のあるAmazon Elastic Container Service（Amazon ECS）タスクが実行可能になりました。
EC2スポットインスタンスと同様の仕組みで、AWSクラウドの予備容量を使用してタスクを実行します。AWS Fargate Spotで実行しているタスクは中断される可能性があるため、中断を許容できない場合は使用できないため注意が必要です。

AWS EC2 Spot と AWS Fargate Spotの比較

この新サービスは、並列化可能なワークロード（画像レンダリング、モンテカルロシミュレーション、ゲノム処理など）や高可用性が必要なWebサイトやAPIなどのECSサービス（の一部）の実行に向いています。アプリケーションがステートレスに設計されていれば、このサービスを活用することで、運用作業負荷を下げつつ、コストを削減することが可能になります。この新機能は後述するECS Capacity Providersと組み合わせて利用します。

ECS Capacity Providers
必要に応じてコンテナのCapacity providerを設定することで、タスクをどこ（オンデマンド or スポット）で稼働させるかを柔軟に制御できるようになりました。作成したCapacity providerは、Capacity provider strategyで指定して使用します。前述した「AWS Fargate Spot」で記載したように、オンデマンドとスポットを組み合わせ、かつ、システムの可用性を考慮した戦略に沿って設定する必要があります。

ECS Capacity Providers設定例

例えば、上図（ECS Capacity Providers設定例）の場合だとオンデマンド（FARGATE）は【Base=1】となっていますが、これは常にオンデマンド（FARGATE）のタスクが1つ存在することを示しています。次にオンデマンド（FARGATE）とスポット（FARGATE_SPOT）のWeight（比）が【1：1】となっているので、2つめのタスクはスポット（FARGATE_SPOT）で起動されます。その後のスケーリングでは、オンデマンドとスポットが同数ずつ追加されていくという動作となります。この新機能をうまく活用することで、スケーリング時のコストを削減しつつシステムの可用性を確保することができます。
この新サービスはECSが利用可能なすべてのリージョン（東京リージョン含む）で利用できます。今後、新規でECSクラスタを作成する場合は、積極的に活用していきたい機能だと思います。

サーバレス

2014にAWS Lambdaが発表されてから5年、部分的な処理に使われていたものからアプリケーション全体をカバーするまでに利用が広がってきているサーバレスですが、代表的な組み合わせであるAmazon API Gateway + AWS Lambda + Amazon DynamoDBでも用途や使い方が制限されるなど、複雑な業務システムを構築するには高いハードルがありました。

複雑なデータを取り扱うにはRDBMSの利用が避けて通れないのですが、LambdaとRDBMSの組み合わせの相性が悪く、これまではアンチパターンとされていましたがいよいよその問題を解消する発表が立て続けに出てきました。2020年はサーバレスの活用が進む年となるのでしょうか。

Amazon RDS Proxy with AWS Lambda[Preview]
これまでアンチパターンとされていた、Lambda x RDSの組み合わせ問題がいよいよ解消します。
アプリケーションからRDS（RDBMS）に接続するには、アプリケーション内部でコネクションプールを生成しDBに接続します。LambdaからRDSに接続する場合、Lambda間でコネクションプールの再利用ができず、多くのLambdaが実行されるとコネクションプールが枯渇してしまうという理由からLambda x RDSの組み合わせはアンチパターンとされてきました。

RDSプロキシの登場によりLambdaからRDSの接続について、RDSプロキシを経由することで、RDSのコネクションプールを枯渇させることなく、RDSに接続できるようになります。また、Lambdaから見た場合、RDSなのかRDSプロキシなのか違いを識別することは不要で、シームレスなRDSへの接続が提供され、RDSへの接続ドライバを変える必要もありません。

（2019年12月23日現在）
Amazon RDS MySQLまたはAurora MySQLの5.6 or 5.7がサポートされ、Tokyoリージョンを含む5つのリージョンで、プレビュー版が提供されています。GAされるのが待ち遠しいサービスとなります。

Provisioned Concurrency for Lambda Functions
キャンペーンなどで大量の流入（スパイクアクセス）がある場合、Lambdaのコールドスタートが発生し、処理パフォーマンスが大幅に低下し、大量のアクセスをさばけないという問題がありました。このような問題を回避するため、CloudWatchイベントで予めLambdaを実行し、暖機運転をしておくことでコールドスタートを回避するようなテクニックが知られていましたが、これからはProvisioned Concurrencyを設定しておくことでこのような問題を回避することができるようになりました。

すでに東京リージョンで利用可能な状態となっており、Provisioned Concurrencyを設定するだけで、すぐに利用できます。これまで、スパイクアクセスが発生する場所でLambdaを利用していた場合、Provisioned Concurrencyを設定することでコールドスタートの発生を抑制できるようになります。

Improved VPC networking for AWS Lambda functions
こちらは2019年9月に発表されていたアナウンスとなりますが、サーバレスに関連する大事なUpdateとなるため、合わせてご紹介させていただきます。

アンチパターンとされていたLambda x RDSの組み合わせ問題と同様に、VPC内でのLambda利用において、IPアドレスが枯渇する問題がありました。また、LambdaをVPC内で起動する場合、Lambda起動毎にENIが生成され、アタッチされるまで10〜30秒程度の時間がかかる問題があり、VPC内でのLambda利用は必ずしも使い勝手のいいものではありませんでした。

今回のUpdateで、Lambda関数作成時にVPC to VPC NATを経由してENIが生成され、以降はこのENIが使われ続けます。従って、大量にENIが生成されることもなく、またENIの生成を待ってLambda関数が実行される事がなくなり、処理性能と使い勝手が大幅に改善します。

Lambda関数のセキュリティ要件が厳しい場合は、VPCにアタッチするとインターネット接続を遮断できるため、これまでアンチパターンだったものが、ベストプラクティスとして活用することもできるようになるなど、大幅な改善がもたらされました。
すでにロールアウトは始まっており、2019年9月の発表から数ヶ月に渡って徐々に展開がされています。

HTTP APIs for Amazon API Gateway[Preview]
HTTPSプロトコルに特化したAPI Gatewayの新機能が発表されました。
これまで提供されていたREST API、WebSocket APIに加えて、新たにHTTP APIが機能追加となりました。HTTP APIはREST APIと比べて、大幅に機能が簡略化されており、簡略化により利用コストは70%減となっています。

リソースポリシー、WAF、X-Ray、使用量プラン、キャッシュ、メソッドリクエスト、統合リクエスト、メソッドレスポンス、統合レスポンスが廃止となっており、統合バックエンドからHTTP、Lambdaを呼び出すことに特化した機能となっています。認証はJWTオーソライザーのみ対応(Cognitoにも利用可)となり、Lambda Authorizerでコードを書く必要がなくなった反面、Lambda Authorizerでのカスタム認証が使えなくなった点は注意が必要です。

セキュリティ

クラウドを扱う上でセキュリティは重要で、AWSからもホワイトペーパーとしてセキュリティベストプラクティスが公開されています。ここではIAMサービスやデータの保護、セキュリティモニタリングなどについてまとめられています。

AWSでは、マネジメントコンソールで簡単にリソースを管理できるようにはなっているのですが、定期的にリソースの設定を確認して修正していくのは手間がかかります。また、脅威に対する防御は一度設定したら終わりではなく継続的に進化させていく必要があります。そういった理由から、構築したシステムのリスク分析と自動修正が可能なサービスが必要になってきます。セキュリティ面でもチェックは可能な限りAWSのサービスに任せ、生産的な作業に時間をさけるようにしたいところです。

AWS IAM Access Analyzer
リソースにアタッチされたアクセスコント ロールポリシーを解析して、パブリックまたは他のアカウントからアクセスできるリソースを探索できるサービスです。権限の設定は複雑になりがちですが、ミスが許されない部分でもあります。Access Analyzerを利用することで、外部からの意図しないアクセスから保護されていることを
簡単に確認することができます。Amazon CloudWatchイベントと統合されていることで、修正の自動化ができるところもありがたいですね。
また、費用はかからず有効化も容易に出来るということで、積極的に利用していきたいと思います。
対応しているサービスは以下の通りです。
・S3
・IAMロール
・KMSキー
・Lambda
・SQS

AWS Security Hub IAM Access Analyzerとの統合
AWS Security Hubは、Amazon GuardDuty、Amazon Inspector、Amazon Macieなどのセキュリティ系サービスの結果を一元的に集約できるサービスです。
上記サービスを利用している場合は有効化すべきサービスですが、re:Invent2019で発表されたIAM Access Analyzerとも統合できるようになっているようです。

AWS Detective[Preview]
AWS Detectiveは、ログデータを自動的に収集し、潜在的なセキュリティ問題や不審なアクティビティの根本原因を簡単に分析、調査して、迅速な特定を可能にするためのサービスです。これまでもAmazon GuardDutyやAmazon Macie、パートナーセキュリティ製品を利用してセキュリティ的な問題を検知できました。
しかし、根本原因の特定は複雑なプロセスとなる場合もあり、ETLや分析用サービスの利用が必要になると
調査チームが長時間の調査を実施しなくてはならなくなります。
AWS Detectiveは複数のデータソースから大量のイベントを分析し、根本原因を特定することができるため、
調査チームが問題に対応するプロセスを簡素化することができます。まだプレビュー版ですので、GAとなったら試してみたいサービスです。

開発者用ツール

AWSでは、これまで多くの開発者用ツールが提供されてきました。Dev(Sec)Opsが注目される中、昨年もAWS CDKやCode系サービスへの機能追加が発表されています。開発者用ツールの充実により、デリバリの効率化・高速化が可能になります。
今年は例年とは毛色の異なるサービスが発表されました。

Amazon Builders’ Library
本サービスは、Amazonのエンジニアが培ってきたテクノロジーを開発、設計、リリース、
操作するベターな方法を紹介した記事の集合です。
https://aws.amazon.com/builders-library/

（2019年12月23日現在）
記事数は13ですが、今後コレクションは成長していくとのことですので、楽しみに待ちましょう。
また、Amazonが公開している方法より良い方法があれば（当然あるかもしれない、というスタンスのようです）、
フィードバックや議論に耳を傾けるというのも顧客至上主義のAmazonらしいですね。

Amazon CodeGuru
開発におけるノウハウ集以外にも、コードレビューの自動化を可能にするサービスも発表されました。デプロイに関しては自動化するサービスは充実してきており、ミスなく素早く頻繁にデプロイ作業を実施することが可能になってきています。ただし、エンジニアのコードをレビューする作業にも時間はかかっており、reviewerによって品質が変わってきたりします。
本サービスを活用することによって、一定以上の品質を保つようなコーディングが可能になるのではないかと期待しています。また、コードレビューの自動化だけでなく性能改善のためのガイドも行うようです。東京リージョンでのGAが待ち遠しいですね。

コンピテンシー

「コンピテンシー」とは「AWS コンピテンシープログラム」のことで、パートナーが特定のソリューション分野の専門知識を持っている証明となるものです。コンピテンシーを取得するには厳しいAPN ティア要件を満たす必要があり、弊社でもコンピテンシー取得に向けて動いています。

昨年は「コンテナ」コンピテンシープログラムが発表されましたが、今年は2つ追加されましたので、簡単にご紹介します。

AWS Retail Competency
お客様の時間を節約し、小売業に関して成功を収め、深い技術的能力を持っている業界専門のAPNパートナー証明するコンピテンシーです。既に12の会社が名を連ねていました。

AWS Public Safety & Disaster Response Competency
安全で信頼性の高いクラウド対応製品を導入し、公共の安全と災害への対応を強化する技術力のあるAPNパートナー証明するコンピテンシーです。
以下3つの中から1つ以上のカテゴリで公共安全および災害対応機能を強化する能力を証明できれば取得できるようです。
・緊急管理業務
・データと分析
・インフラストラクチャのレジリエンスとリカバリ

AWSパブリックセクターパートナーに認定されている弊社としましては、本コンピテンシーにも注目していきたいと考えています。

量子コンピューティング

AWSにも量子コンピューティングの波がやってきました。Amazon Braketは、開発者・研究者らが量子コンピューティングに関する開発・実行を行えるフルマネージドサービスです。なお、ML関連ではInferentiaというAWSがカスタムした推論チップ開発が話題になっていましたが、Amazon Braketに関してはあくまでD-Wave社などの他社量子ハードウェアをAWSがサービスとして提供するという構成のものです。
Braketの発表と同時にre:Inventでのセッションが追加され、そのセッションでの受講内容をレポートいたします。

re:Inventのセッション「CMP213-R – Introducing quantum computing with AWS 」では以下のような点について講演されていました。
・量子コンピューティングについての概要
・Braketで利用する量子ハードウェアの紹介
・Quantum Solutions Labの紹介

セッションで使用されたスライドは以下に配置されていますので、ぜひご参照ください。
https://d1.awsstatic.com/events/reinvent/2019/NEW_LAUNCH_REPEAT_Introducing_quantum_computing_with_AWS_CMP213-R.pdf

少し意外だったのは、セッションの前半がBraketの説明ではなく、量子コンピューティング技術全般の説明だったという点でした。量子コンピューティングがまだこれから育っていくジャンルだということが感じられます。また、セッション内で触れられていた点で興味深かったのが以下の説明でした。
・量子コンピューティングが適用される範囲として、暗号化、物理・科学、材料科学、最適化があげられる
・直近では、従来のCPUを置き換えるものではなく、コプロセッサとして動作する。CPU＋GPUのように、CPU＋QPUというような形で使われる
・「Potential for a new paradigm in computing: not 10X performance improvement but 10^x」

10^Xのパフォーマンス成長が実際に達成されれば、まさにパラダイムシフトです。量子コンピューティングの秘めている可能性が伝わってきて、今後のコンピューティング全般について考えたくなる、そんなセッションでした。弊社が実業務で使うのはまだ当分先かもしれませんが、出遅れないよう継続してウォッチしていく必要がある要素だと考えられます。

まとめ

変革とリーダーシップ
Andy Jassyのキーノートでは大きなテーマの1つとして、Transformation（変革）が取り上げられ、変革に必要なものとしてリーダーシップについて言及されていました。日本でも昨年、経済産業省にてガイドラインが取りまとめられたことを受けて、デジタル・トランスフォーメーションがビジネスの大きなテーマの1つとして取り上げられ、2019年は日本でもDX元年となりました。

Andy Jassyの発言をなぞると、クラウドを活用したデジタル・トランスフォーメーションを推進していくには各組織のリーダーの信念を一致させ、早く組織を動かすためのトップダウンの目標が必要となります。また、新しい技術に組織を対応するためもトレーニングも重要な要素となります。
主要な国々の中で日本はクラウド支出の割合が最低レベルにあると直近のガートナーのレポートで報告されている通り、日本でのクラウドの取り組みはまだまだこれからの状況です。

BTCでは、2019年のこの1年でAWS Certifiedの認定資格者を一気に増やし（社員に占める認定資格の保有割合も5％→22％に大幅増）、まさにクラウドに対応できる組織づくりを行ってきました。
DXを推進するには我々のようなコンサルティング・IT専門のファームのみならず、お客様自身の組織がDXに対応できる組織づくりを行っていく必要があり、我々はその変革のための支援していきたいと思います。

少し気が早いですが、来年のre:Invetは2020年11月30日〜12月4日の日程で開催される予定です。変革を推進したい組織のリーダーの方々は是非、来年のre:Inventに参加し、その熱気とスケールを体感して、各組織の変革を推進していただきたいと思います。
AWS re:Invent

著者紹介

光永 英二

• 執筆担当セクション
  • 導入部
  • サーバレス
  • まとめ
• 保有AWS認定資格
  • AWS Certified Solutions Architect – Associate

砂田 文宏

• 執筆担当セクション
  • コンテナ
• 保有AWS認定資格
  • AWS Certified Solutions Architect – Professional
  • AWS Certified Solutions Architect – Associate

松波 宏之

• 執筆担当セクション
  • 機械学習
  • ストレージ、データベース
  • 量子コンピューティング
• 保有AWS認定資格
  • AWS Certified Solutions Architect – Professional
  • AWS Certified DevOps Engineer – Professional
  • AWS Certified Solutions Architect – Associate

西村 翼

• 執筆担当セクション
  • セキュリティ
  • 開発者用ツール
  • コンピテンシー
• 保有AWS認定資格
  • AWS Certified Solutions Architect – Professional
  • AWS Certified DevOps Engineer – Professional
  • AWS Certified Security – Specialty
  • AWS Certified Developer – Associate
  • AWS Certified SysOps Administrator – Associate
  • AWS Certified Solutions Architect – Associate

原田 大雅

• 執筆担当セクション
  • ネットワーク
  • データ分析
• 保有AWS認定資格
  • AWS Certified Solutions Architect – Professional
  • AWS Certified Solutions Architect – Associate