はじめに

estie VPoEの青木と申します。

弊社ではインフラ基盤として主にAWSを利用しています。
AWSを利用していると、日々そのサービスがアップデートされ機能拡充されていくことに驚きますよね。
実際、AWSのリリースページによると、2019年だけで本日(12/02)までに1671ものアップデートリリースがあります！

本日は、その中で特に個人的にグッと来たリリースをランキング形式でご紹介したいと思います。
（私自身がデータエンジニアとしてのキャリアが長いため、少し偏ったランキングとなっているかもしれませんがご容赦ください）

なお、本日（12/2）から6日にかけてAWSのイベントであるre:Inventが開催され、
多くのアップデートが発表されるかと思いますが、本記事はそちらの発表前時点で選ばせていただいています。

第5位： Glue・AthenaのprivateLink対応

できるようになったこと

Athena（S3内のファイルに対して直接クエリを実行できるサービス）とGlue(フルマネージドなETLサービス)がそれぞれ、VPCインターフェイスエンドポイントに対応しました。
これにより、インターネットを経由せずに各サービスに接続し利用することが可能となりました。

どんなことが嬉しいのか

これまではインターネット経由のアクセスが厳しく制限されているプロダクトでは、AthenaやGlueを利用することができませんでした。
今回のリリースにより、セキュリテイ要件の厳しい案件など、より幅広いサービスで利用することが可能になりました！

リリース記事

AWS Glue
Athena

第4位： EC2 Instance Connect

できるようになったこと

IAM（Identity and Access Management）情報を用いて、一回限りのアクセスキーを発行してEC2へのSSH接続できます。
合わせて、マネジメントコンソール経由でブラウザからアクセスすることも可能になりました。

どんなことが嬉しいのか

運用上作業が多くなりがちだがセキュリティ上重要なEC2へのアクセス権限の整理を全てIAMで管理することが可能に。
昨年発表された「AWS Systems Manager セッションマネージャー」と合わせ、EC2接続周りの利便性はかなり向上し、今後のアクセス情報管理のスタンダートが大きく変わる可能性を秘めてると感じました！

リリース記事

AWS instanceConnect紹介

第3位： Step Functionsで複雑なパターンを実行可能に(ネスト/外部コールバック/動的並列処理)

できるようになったこと

AWS Step Functions(AWS Lambdaなどのマイクロサービスのワークフローエンジン)がより様々なワークフローに対応しました。

ステートマシンをネストして使用することが可能となり、より大規模なフローの構築が簡易に
コールバックへの対応が可能となり、外部ユーザやAWS外のアプリケーションとの結合が可能に
動的に複数のLambdaを呼び出すような並列処理が可能に

どんなことが嬉しいのか

これまでであれば、他のワークフローエンジンを用いていたような複雑又は大規模な開発案件においても、
Lambda+Step Functionsだけでクイックにサーバレスかつ運用しやすい環境を構築することが可能となりました。
今後もStep Functionsがアップデートされていくと、かなりのパターンではこのような構成で完結していくようになるのかもしれませんね！

リリース記事

ネスト
 コールバック
 動的並列処理

第2位： savings Plans

できるようになったこと

将来一定期間（1年or3年）のEC2利用量を前もってコミットすることで、最大72%コスト削減できるようになりました。

どんなことが嬉しいのか

これまでもReserved Instanceという将来一定期間の利用を約束することでの割引機能は存在したのですが、購入時点でインスタンスタイプを指定する必要がありました。
本サービスでは合計の利用量だけをコミットすれば良いため、サービス拡大に伴うスケールアウトやスケールアップにも問題なく対応できます。
しかも割引率もReserved Instanceと比較しても遜色なさそうです。
サービス利用状況の予測が立てづらい弊社のようなスタートアップには、ありがたいサービスですね！

リリース記事

savings Plansの紹介

第1位： Redshiftでの最適な分散キーの推奨

できるようになったこと

Redshift（DWH向け列志向のMPPデータベース）において、テーブル利用実績を元に最適な分散キー設定を推奨するようになった。
また、以前はテーブル作成後には変更できなかった分散キーがALTER TABLEコマンドにより変更可能となった。

どんなことが嬉しいのか

Redshiftの高速なクエリパフォーマンスの鍵となるのは、複数のノードにデータを分散させるために用いられる分散キーの情報です。
以前までこのキー情報がテーブル作成後にはコマンドでは変更できず、どうしても処理時間が長すぎるクエリがある場合には、新しい分散キーの設定されたテーブルを作成した上で、古いテーブルからデータをINSERTする必要がありました。
その際、Redshiftのテーブルは多くの場合かなり多くの件数のデータが含まれるため、このINSERT処理はかなりの時間がかかるとともに、場合によっては圧縮を解凍した際にDB全体で容量不足となりクエリが失敗することもありました。

今年こちらの仕様も変更され、ALTER TABLEコマンドでテーブルの分散キー、ソートキー（INTERLEAVED SORTKEYは未対応）を変更ができるようになりました。今回のリリースはさらに、この最善なソートキーを自動で推奨してくれる機能となります。

今回の一連の改善により、以前は初期構築時の大事な一発勝負の感があった分散キー設計が、恒常的に改善可能な設計内容へとだいぶハードルが下がったと感じました。

去年リリースされた短時間でのノード数変更を可能とするElasticResizeや、最近公開されたマテビューへの対応など、Redshift関連のアップデートはかなり高速で進んでいる印象があります。
今年のre:InventでもRedshiftについて大きなリリースがあるかもしれませんね！

リリース記事

最適な分散キーの推奨

終わりに

リリース内容を振り返って

振り返ってみると、ランクインしていないものも含めて、たくさんのアップデートがありましたね。
やはりAWSのようなサービスを使うにあたっては、最新のアップデート情報を仕入れることが大切だと感じました。

まだestieでは試せていないものもありますので、re:Inventで発表されるであろう分も含めて、
どんどん試してサービスに反映させていきたいと思います！

estieについて

estieでは、新しい技術にアンテナを張っているエンジニア、フルスタックのエンジニアを常に募集しています！
https://www.wantedly.com/companies/company_6314859/projects

estie -> https://www.estie.jp
estiepro -> https://pro.estie.jp
会社サイト -> https://www.estie.co.jp