Amazon Web Services ブログ

週刊AWS – 2019/12/2週（re:Invent特別号）

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。

先週は 年に一度の大きなイベント AWS re:Invent 2019がラスベガスで開催されて、いつも以上に多くの新サービスや新機能が発表されましたね！エキサイティングな発表が多くて嬉しいのですが、とてもこの連載の枠に全ての重要な発表が収まりそうにりません。

そこで今回の週刊AWSでは、AWS re:Invent 2019 で発表された内容から、筆者ら（小林、下佐粉）が「個人的に凄いと思った発表10選」を独断でチョイスしてお送りします。なお、re:Invent 2019で発表された内容を全部知りたい！という方向けに関連資料も最後にまとめています。では、厳選10個のアップデートをご覧ください。

2019年12月2日週の主要なアップデート(re:invent週特別版、順不同)

  • AWS Outposts がGA（一般提供開始）
    • AWSの環境をオンプレミスにまで延長するAWS OutpostsがGAになり、東京リージョンでも利用可能になりました。またこの発表に合わせてOutposts内で稼働するサービスにEMRが追加され、将来の予定としてS3対応も追加されています。
    • Outpostsは、AWS環境をお客様環境（オンプレミス）に物理的に近い位置に配置する試みです。これによりオンプレミス環境とAWS環境の通信遅延を小さくする事が出来るため、専用線でAWSのリージョンと結んでもリージョンへの通信レイテンシが問題になるようなユースケースに対応できるようになります。
    • AWSでは、このようにサービス（の一部）をユーザ側に物理的に近づけるという試みを色々と行ってきました。たとえばAWS IoT Geengrassは、IoT端末に近い場所で処理を行うためのものですし、CloudFront上でLambda関数を動かすLambda@Edgeもその一種と言って良いでしょう。同時に発表されたAWS Local Zonesもそういった試みの１つで、通常のリージョンとOutpostsの中間的な位置づけとも言えますね。こういった多様な処理形態を提供することで、より多くのニーズでAWSをお使いいただける環境が整えられていっています。
    • 関連Blog – AWS Outpostsが一般提供開始になりました
  • Redshift新機能 – RA3インスタンスGAと AQUAプレビュー
    • クラウドDWHのAmazon Redshiftに大きな新機能が2つ追加されました。1つはRA3という新しいノードタイプのGA（一般提供開始）です。これはCPUやストレージ性能が向上した第3世代のRedshiftノードですが、性能向上だけでなく、「ストレージとCPUを分離する」という大きな変更が加えられています。
    • これまでは、Redshiftの各Compute nodeには、内蔵ストレージが含まれており、ユーザのデータはS3からこの内臓ストレージにロードしてから処理する形になっていました。Spectrumという機能でS3上に置かれたファイルを外部表として参照可能でしたが、読み取りのみ対応等の制限がありました。
    • 今回のRA3では、データはあくまでS3に置いてあるものが「正」で、内蔵ストレージは「キャッシュ」と役割が変更されました。ただしユーザから見た場合は特に意識する必要はなく、これまで通りのSQL操作が可能で、ヒット率が高いデータが自動的にキャッシュで保持される仕組みになっています。ストレージとCPU(ノード)の分離により、内蔵ストレージ以上のデータを扱うことが可能になっています。RA3は東京リージョンで利用可能になっています。
    • もう一つがAQUA(Advanced Query Accelerator)という新しいサービス層の発表（限定プレビュー受付開始）で、RedshiftノードとS3の間に挟まる新しいキャッシュ層です。ここに専用のFPGAを搭載したサーバ群を置き、Redshiftノードに代わってデータのフィルタリングやアグリゲーションを実施します。これによりRedshiftノードのCPU負荷が下がり、さらなる性能向上が期待できます。RA3もAQUAも、既存のRedshiftとの互換性は保ったままになる予定です。
    • 関連Blog – Amazon Redshift の新機能 – 次世代コンピュートインスタンスと、マネージドで分析に最適化したストレージ
    • 関連動画 – AWS re:Invent 2019: Leadership session: Trends with data lakes and analytics (ANT206-L)
  • UltraWarm for Amazon Elasticsearch Service
    • Amazon Elasticsearch Service (AES) にUltraWarmという新しいストレージ階層が発表されました（現在プレビュー）。このUltraWarm層ではデータはAmazon S3に格納され、自動的にキャッシュされる仕組みになっています。
    • AESでは通常はノードに接続されたディスク（多くの場合ローカルストレージ）に全データが保存されます。また冗長性を考えるとデータは１つか2つのノードにレプリカして保存される事が一般的です。このため巨大なデータを扱う場合にはノードの費用とストレージの費用が大きくなりがちでした。
    • UltraWarmではデータはS3にあるため、安価に維持できるだけでなくレプリカノードも不要になります(S3自体が高い耐久性を持つため)。このため大きく費用を削減可能になります。以下のBlogでは最大90%安価な構成が可能と試算されています。もちろん、通常のデータノードの方がより性能を発揮しますので用途によって使い分けるのが良いでしょう。
    • 関連Blog – UltraWarm for Amazon Elasticsearch Service を使用して少ないコストでより多くのデータを維持する
  • Managed Apache Cassandra Service
    • Apache Cassandra互換のサーバレスサービス、Amazon Managed Apache Cassandra Service (MCS)が発表されました。現在オープンプレビューで、どなたでも利用する事が可能です。通常、大規模なCassandra環境には運用の負荷が高いという課題がありますが、それをサーバレスでサービスを提供することで解消します。
    • サーバレスですので、ユーザはCassandraサーバの管理をする必要はありません。一方でCassandra Query Language(CQL) 3.11 APIとの互換があるため、既存のアプリケーションコードやツールをそのまま利用することが出来るようになっています。キャパシティ管理もAWS側で行われるようになっており、通常時はどんな規模でも安定して一桁ミリ秒の読み書きレイテンシを実現するよう設計されています。
    • データ領域についても、事前にストレージサービスをプロビジョニングする必要はなく、保存されたデータは自動的に3つのAZにコピーすることで保護するようになっています。
    • 関連Blog – Amazon Managed Apache Cassandraサービス（MCS）がアナウンスされました
  • SageMaker関連の多くのアップデート
    • AWSの機械学習環境であるSageMakerファミリーに多くのアップデートが発表されました。以下に一部抜粋で紹介します。
    • SageMaker Model Monitorはデプロイ済の機械学習モデルのクオリティを継続的に監視し、問題が発生したら通知してくれるサービス（関連Blog）
    • SageMaker Debuggerは各種機械学習フレームワークに対応した、トレーニングジョブ開発時のデバッグを効果的に行うための新機能（関連Blog）
    • SageMaker Autopilotはクラス分類と回帰のためのモデルを自動的に生成する、いわゆるAutoMLを実現するための新機能（関連Blog）
    • SageMaker Studioは機械学習向けのウェブベース統合開発環境(IDE)。上記新機能への対応も含んでいます（関連Blog）
  • AWS Lambda Provisioned Concurrency
    • AWS LambdaにProvisioned Concurrencyという機能が追加されました。これはLambdaのいわゆる「コールドスタート（起動時の遅延）」を回避するための機能で、一貫した時間でのLambda関数の起動を実現するものです
    • Lambda起動にかかる起動時間にばらつきがあったとしても、一般的な用途ではほとんど問題になりません。ですが、遅延を許容するのが難しいようなユースケースではこのProvisioned Concurrencyが役に立ちます。Provisioned Concurrencyで指定された分のLambda関数がすぐ実行できるように準備された状態で待機させておくことで遅延の発生を抑えます。
    • Lambdaにはここ最近、VPC内部へのアクセスが高速化されるというアップデートがあり、またこの後に説明するRDS Proxyを使うとLambdaからRDBへの大量並列アクセスの問題も回避することが可能になるなど、”Lambdaのアンチパターン”がどんどん無くなりつつあります。ぜひこういった最新機能と共にLambdaを活用してください。
    • 関連Blog – 新機能 – Lambda 関数のプロビジョニングされた同時実行性
  • Amazon RDS Proxy
    • RDS用のプロキシーサービスが発表されました。現在はPreviewで、RDS MySQLとAurora MySqL 5.6/5.7に対応したプロキシーを利用可能です。つまりアプリ->RDS Proxy->RDSのように接続します。アプリからはRDS ProxyがRDSのように見えます。
    • RDS ProxyはマルチAZに配置されるマネージドサービスで、機能としてはDBへのコネクションプールと、Proxy配下のDBの切り替えのハンドリングです。用途の1つはDB障害時のアプリへの影響の最小化です。DB障害が起きてもRDS Proxyに問題がなければアプリケーションの接続は切断されません。
    • もう一つの利用用途は、Lambdaからの接続です。Lambdaはイベントごとに並列で関数が起動するモデルのため、例えばAPI Gateway – Lambda – RDSという組み合わせで利用するとAPI Gatewayに同時に10,000アクセスあった場合は10,000個のLambda関数が起動し、これがRDSに10,000個の接続を試みます。しかしRDS(RDB）は一般的にはこういった膨大な接続には対応できないため、これまでは多くのイベントが同時に発生するLambda関数の後ろでRDBに接続に行くのはアンチパターンと考えられていました。しかしRDS Prpxyを挟むことで、アンチパターンでは無くなります。詳しくは以下のBlogを参照してください。
    • 関連Blog – Using Amazon RDS Proxy with AWS Lambda
  • Amazon EKS + AWS Fargate が利用可能に
    • Amazon Elastic Kubernetes Service (EKS) でAWS Fargateの上でPODの実行が可能になりました。
    • コンテナ環境を準備するには、まず仮想マシンを複数台準備し（AWSであればEC2を用意し）、それをオーケストレーションする仕組み(k8sやECS)に預けます。そうすることでコンテナを実行する環境が用意できます。Fargateはそういった実行環境の管理を不要にするサービスです。ユーザはコンテナ実行環境がどうなっているかを気にする必要はなく、またパッチ適用やオートスケール等の管理を考える必要もありません。
    • これまでFargateはECSからのみ利用可能でしたが、この発表でEKS(k8s)からも利用可能になりました。運用管理負荷を下げつつ、k8s環境を利用できるEKS+Fargateをぜひ試してみてください。
    • 関連Blog – AWS Fargate 上の Amazon EKS を一般公開
  • Amazon Event Bridge schema registry
    •  Amazon EventBridgeはサーバレスのイベントバスサービスです。これに利用を容易にする大きなアップデートが行われました。
    • １つはSchema Registry で、イベントスキーマの情報が格納され、アプリケーションで使われるスキーマを検索、追跡することを可能にするサービスです。AWSがソースとなるスキーマは自動的に追加されます。
    • もう１つがSchema Discovery で、 EventBridgeに送信されたイベントスキーマを自動登録するサービスです。これは通常、開発環境でのみオンにする機能です。
    • こうしてスキーマがレジストリに登録されると、Java、Python、TypeScript向けのコードバインディングが利用可能になり、Visual Studio CodeやIntelliJから利用可能になります。
    • 関連Blog – Introducing Amazon EventBridge schema registry and discovery – In preview
  • Rekognition カスタムラベル
    • 画像認識のAIサービスであるRekognitonでカスタムラベルが利用可能になりました。これまでRekognitionは、AWS側で用意したモデルを使った画像認識を行うサービスでしたが、この機能追加によって色々な画像認識に対応できるようになりました。
    • 機能としては、自分で用意したラベル付きの画像を学習させ、そのモデルを利用して画像を認識させることができるようにするというものです。AWS標準のモデルでは識別が難しい物体を判別できるように調整が可能になります。
    • 一方で機械学習の知識は不要であることは変わりありません。ラベルがついた画像さえ用意できれば、すぐに利用が可能です。
    • 関連Blog – Amazon Rekognition カスタムラベルの発表

ここまで独断チョイスの10個を説明してきましたが、re:Invent 2019での全発表は以下の記事にまとまっていますので、全部知りたいという方はぜひご覧ください。

また、これらの発表を1時間にまとめて説明した動画＆資料が以下で公開されています。

これに加えて、re:Inventのテクニカルセッションの動画は以下のサイトに続々とあがっていますので、興味を持ったサービス名等で検索してみてください。

それでは、また来週！

ソリューションアーキテクト 下佐粉 昭 (twitter – @simosako)