AWS新サービス紹介と所感 from re:Invent 2015

はじめまして。mediba インフラストラクチャー部所属の沼沢と申します。

2015/10/06 〜 2015/10/09 に行われた AWS 最大のグローバルカンファレンス、re:Invent 2015 に参加してきました。
そこで発表された新サービスや、新機能の紹介をしつつ、弊社でどう活用できるか、どのようなことが期待できるかなどを綴りたいと思います。
公式やブログなど、色んな所で既に紹介されているので今更感ありますが、お付き合いいただければと思います。


Day1

Amazon QuickSight

クラウドベースの BI ツールということで新たに登場しました。
データソースを指定するだけで、データの可視化が可能になります。
AWS の BI 対応は以前から噂されていましたが、満を持して登場したというところでしょうか。

  • 多彩なデータソースアクセス
    • Redshift や RDS はもちろん、Kinesis など AWS の各サービスに対応
    • その他、コネクター経由でサードパーティも指定可能
  • データを直感的に可視化
  • SPICE という高速なAWS独自エンジンを採用
    • Super-fast, Parallel, In-memory Calculation Engine
    • SSD の3倍の速度性能
  • フルマネージドで管理不要、スケールも自動
  • 簡単に、低コストでの利用
  • サードパーティの BI ツールとの連携も可能
    • Tableau など

RDS for Amazon Aurora が東京リージョンで利用可能に

これは多くのユーザが待ち望んでいたのではないでしょうか。
基調講演の中では特に語られませんでしたが、今回のイベントに合わせてローンチされたようです。
東京リージョンに来たら移行しようと考えていた方々は、要チェックです。

パフォーマンスは最大で MySQL の5倍の性能で、MySQL 5.6 との完全互換があり、ダウンタイム無しでの移行が可能です。
また、容量は自動で拡張するため、空き容量を監視する必要がありません。

★ mediba 的観点

AWS で商用稼働しているサービスの中には、RDS for MySQL を利用しているサービスがあります。
昨年の re:Invent で Aurora が発表されてから、RDS for MySQL で稼働しているシステムは Aurora へ移行したいと考えていたため、東京リージョンのローンチは心待ちにしていました。

例えば、弊社が AWS 上に構築/運用しているサービスの中に、RDS for MySQL を利用しているサービスがあり、そのサービス内のとある機能で、結構ハードにレプリカを参照する部分があります。
その機能に関連した訴求のために Push 配信を行うことがあり、その際には参照先のレプリカが高負荷になりがちなため、少し控えめに Push 配信をしているという現状があります。
RDS for MySQL ではレプリカを5個までしか配置できませんが、Aurora では 15 個のレプリカを配置することができるため、Aurora に移行することで、単純に参照性能の向上が見込まれるため、訴求の強化も期待できます。

上記のように、弊社で構築/運用しているサービスにおいて、Aurora へ移行することで改善が見込まれるケースが多々あると考えています。

ただし、Aurora に移行するにはいくつかの注意点があります。

  • Aurora では InnoDB のみがサポートされているため、MySQL 上で MyISAM を使用している場合は事前に InnoDB に変換する必要がある
  • 現時点で Aurora で選択できるインスタンスファミリーは r3(メモリ最適化)のみで、タイプは large からとなっており、MySQL の同タイプと比べると若干お高いので、コスト面も注意が必要
  • Aurora を利用するということは、AWSにロックインされるので、そこに関しての考慮も必要

etc..

今後、導入が実現した際には、ブログで書けたらと思います。

RDS for MariaDB

RDS の DB エンジンの選択肢がまた1つ増えました。
今まで MariaDB が無いから移行を決断できなかったアプリケーションやサービスなど、RDS の MariaDB 対応によって、移行を進める企業は多いのではないでしょうか。

AWS Database Migration Service

主に、オンプレミスの DB を AWS に移行することを想定して作られたサービスです。

移行後も同期をとり続けることが可能とのことなので、移行元の DB を運用したまま徐々に切り替えるなどの方法で、ダウンタイムを最小限に移行することが可能だと思われます。

同一の DB エンジン間(MySQL → MySQL等)はもちろん、AWS Schema Conversion Tool を利用することで、異なるDBエンジンへの移行も実行可能。
AWS Schema Conversion Tool では、DB スキーマやストアドプロシージャ等の移行の手助けをしてくれるそうです。

★ mediba 的観点

弊社では、オンプレミスで稼働しているサービスもいくつか存在し、それらをクラウドに移行するかどうかはまだ検討段階です。
今後、オンプレミスで稼働中のサーバ群が EOSL を迎えるタイミング等で、AWS への移行が行われることになった場合には、稼働中の DB の移行をする時に非常に手助けになるのではないかと思います。
特に Aurora への移行という要件は少なからずありそうなので、その場合は非常に有用なサービスになります。

Amazon Kinesis Firehose

Kinesis Stream に渡したストリーミングデータを、S3, Redshift に直接ロードするためのサービス。

Kinesis に渡したストリーミングデータは、そのデータを操作するワーカーが必要ですが、「S3/Redshiftにロードする」という単純な処理について、ワーカーを用意する必要がなくなったというイメージでしょうか。

これに伴い、従来の「Amazon Kinesis」は「Amazon Kinesis Stream」に名称が変更になりました。

★ mediba 的観点

特に大量のデータが流れる広告事業のサービスにて有用なサービスだと考えられます。
例えば、ユーザの行動履歴のトラッキングをする場合に、トラッキングリクエストの受け口に利用することで、サーバーレスで大量のトラッキングリクエストを受けることができ、更にはコーディングレスで S3 or Redshift にダイレクトで保存が可能になるため、構築/運用の手間が減少し、更にビジネスロジックへ集中することができる=広告商品をより良いものへ昇華させることが期待できます。

Amazon Import/Export Snowball

物理の箱に大容量のデータを格納し、物理的にAWSのDCへの移行を実現するサービス。
“超BigData(数百PB)の移行をより簡単により早くするには?"を考えた結果、作成されたとのことです。

Snowball

※画像は Amazon Web Services ブログ より引用

  • 1つあたり50TB
  • 複数台同時利用でPBクラスのデータをおよそ1週間で転送可能
  • 暗号化、改ざんを防止をして安全にデータを出荷し、出荷状況などのステータスを監視でき、非常にセキュアである
  • 従来の1/5のコスト
  • データ変換も自動的にできる(レガシーからオブジェクトなど)
  • 東京リージョンは現時点で予定なし(必要だという声が多ければ実現するかも)

AWS WAF

言わずと知れた、WAF(Web Application Firewall)が AWS で登場。
これによって、EC2 に登録しているアプリケーションをより堅牢にガードすることができます。
従量課金制で、お支払いは使った分だけです。

AWS Config Rules

昨年の re:Invent で、AWS の構成(リソース)を管理するサービスとして AWS Config が発表され、構成変更の履歴の管理などができるようになりました。
その AWS Config の新たな機能として発表されたのが、AWS Config Rules です。
この機能では、AWS の構成変更について、ルールを策定することで、そのルールに沿った構成変更に限定することができます。

例えば

  • EC2インスタンスに適切にタグが付与されていること
  • EIPがアタッチされていること

などをルールとすることで、構成変更の抜け漏れを防ぐと同時に、余計な設定をすることを防ぐことにも役立てることができるでしょう。

★ mediba 的観点

現在、AWS で商用稼働しているサービスは多々ありますが、それらの構成変更には制限がありません。いくらルールを策定しても、権限を持っている IAM ユーザであれば、悪意の有無に関わらず、意図しない構成に変更ができてしまいます。

どう構成を組んだら良いか・おかしな構成になっていないかなどを、システム的に制御できるようになると、より一層、安定して安心な運用が可能になります。
Config Rules の利用で、安心・安全な運用の手助けになることを期待しています。

AWS Inspector

自動化されたセキュリティ診断サービスです。
一般的な脆弱性はもちろん、ネットワークやOS、アプリケーションレベルにおいても、それぞれの観点のセキュリティベストプラクティスをもとに、診断を実施してくれるサービスだそうです。
また、APIを利用することで、開発プロセスに組み込んで自動化することも可能です。

Day2

Amazon API Gateway が東京リージョンで利用可能に

こちらも Aurora と同様、基調講演の中では特に語られませんでしたが、今回のイベントに合わせてローンチされました。
これで、東京リージョンでの API 構築が格段に楽なものになります。

★ mediba 的観点

現在オンプレミスで稼働しているものの中には、アプリ向けに API を提供しているサービスがあります。
オンプレミスではサーバーをスケールするのは容易ではありませんが、API リクエストの受け口として API Gateway を挟み、スロットル機能を活用することで、オンプレミス側の API サーバのバーストを防止でき、安定した API 運用が実現できそうです。

Amazon Kinesis Analytics

Kinesis Streams に格納されたストリーミングデータを SQL を利用して簡単に分析することができる、いわゆるストリーミング SQL データベースのサービスです。

EC2 の新インスタンスが追加に

  • x1 インスタンスファミリー
    • 最大 2TB のメモリ、100以上のvCPU
  • t2.nano インスタンス
    • 512MB のメモリ、1vCPU
    • 他の t2 シリーズと同様、バースト機能あり

Amazon EC2 Container Registry (Amazon ECR)

Docker のコンテナイメージを管理するレジストリのフルマネージドなサービスです。
これにより、高可用性を備えたフルマネージドな Docker レジストリの利用が可能になります。

AWS Lambda の各種アップデート

  • Python 2.7が利用可能に
  • バージョニングとエイリアス機能の追加
  • VPC Support(まもなく利用可能に)
    • VPC内のリソースへ、インターネットを経由せずにアクセス可能に
  • タイムアウト時間の延長
    • 60 秒 → 300 秒に延長
  • スケジュール実行が可能に
    • cron 形式で指定
    • 最短のインターバルは5分

Mobile Hub

Cognito, SNS, MobileAnalytics, S3, CloudFront など、AWS のモバイル関連サービスにおける実装について、ウィザード形式で選択していくことでベースとなるコードを生成してくれるサービスです。

AWS IoT

IoT(Internet of Things)の分野において、センサーなどのデータを収集、処理、分析、結果に応じたアクションを実行するためのサービスです。
以下のような機能群で構成されています。

  • Device Gateway
    • MQTT, HTTPを用いてセキュアに通信するためのサービス
  • Rules
    • デバイスからのメッセージをルールに基づいて様々なアプリケーションに引き渡すためのサービス
  • Shadow
    • デバイスに対してもコミュニケーションを容易にするためのサービス
    • デバイスが電源Offや故障、オフラインになってしまった場合などに、復旧までデータを蓄積/保持し、復旧したら最新情報を送ることができる
  • Device SDK
    • AWS IoTのための各種SDK(C, JavaScript, Arduino)も同時にリリース

まとめ

上記以外にも細々した発表がありましたが、主要なものをご紹介しました。
現時点では、弊社では活用方法のイメージが湧かないものもありましたが、今回発表されたサービスは今後さらに機能追加やブラッシュアップが行われ、非常に強力なものになっていくことでしょう。
今後も AWS から目が離せません。