現在位置: ホーム / ビッグデータ ブログ / AWS Summit Tokyo 2017 Day2 参加レポート

AWS Summit Tokyo 2017 Day2 参加レポート

AWS Summit Tokyo 2017 Day2 (2017年5月31日) の基調講演、印象に残ったセッション内容をレポートします。

AWS Summit Tokyo 2017 Logo

サイオステクノロジー 水倉です。

いよいよ始まりました。AWS Summit Tokyo 2017!
5月31日の2日目に参加してきました。基調講演の概要と、個人的に印象に残ったセッションを紹介していきます。

※撮影禁止でしたので写真無しです(>_<)

 

基調講演

オープニングは、三味線とエレクトリックギター、バイオリンをフィーチャーした生演奏、AWS の変遷を数字で示していくスタイリッシュな映像(60 回以上の値下げ、42 ヶ所の Availability Zone 等々)でワクワク感がありました。

昨年の AWS Summit からさらに大規模になり、1日追加の4日間開催、ゲストスピーカー、スポンサーブース数も去年の2倍だそうです。

クラウド導入が加速している理由、AWS の強みが紹介されていき、各企業のスピーカーも多数ありました。ここでは、気になる新サービスについて紹介します。

新サービス

  • Amazon Lightsail が東京リージョンでサービスイン
    • Virtual Private Server (VPS) サービス
      • サービス導入時に製品知識の習得、費用が確定しないといった悩みを解消するもの
      • 好きな OS や開発環境、アプリケーションなどがセットアップされたサーバを、数回のクリックで立ち上げ可能
  • 大阪ローカルリージョンの開設(2018年提供予定)
    • DR 用途を想定し、特定顧客に対して提供
  • 準拠法、管轄裁判所が選択可能になった
  • 準拠法に日本国法、管轄裁判所に東京地裁。日本での導入が増えそうです
  • 日本円での決裁が可能になった
  • AWS マネジメントコンソールの日本語化をさらに推進
    • 2017年6月末には100%日本語化予定

ここからは、個人的に印象に残ったセッションを紹介していきます。

ナビタイムサービスにおける、Amazon ECS を活用したシステム移行 ~『乗換NAVITIME』での移行事例 ~

スピーカー:株式会社ナビタイムジャパン サーバーグループ プロジェクトマネージャ 萱島 克英氏

オンプレ稼働の「乗換NAVITIME」のAmazon EC2 Container Service (ECS) を活用した移行事例です。

オンプレ構成イメージ

APサーバ ⇒ APIサーバ ⇒ 全文検索エンジン (Solr) / 経路検索エンジン / バックエンド DB (PostgreSQL、MySQL)

 

移行に至った理由

  • 利用者の増加
  • インフラ面の課題
    • アクセス増加時に自動スケールできない(過去の統計情報からアクセス数を予想し、余剰サーバ追加する運用)
    • インフラ構築に時間がかかっている(構築作業のCode化が進んでいない)
  • 社内で部分的に利用していたAWS活用事例から効果が見えてきていた
    • 開発効率の向上、リードタイムの短縮
      • 「交通コンサルティング」
        • ログの転送、加工、可視化
        • Lambda、Kinesis、S3、EMR(加工)
      • 「NAVITIME Transit」
        • EC2 から ECS へ移行。CloudFormation を活用

 

移行内容

  • APサーバのコンテナ化
    • 一部のオンプレで Ansible を試験利用していたことから、ansible-containerを使ってDockerコンテナを作成
  • CloudFormation
    • AWS環境構築手順の Code 化
    • メリット
      • 環境の作成/更新/削除が簡単にできる
        • インスタンスタイプの変更
        • 性能比較をするために EBS ボリュームの種類を2つ用意するなど
      • 他システムへ CloudFormation を流用することで迅速なサービスインを実現
  • 一部の機能はオンプレ
    • Rest API 化して連携できるようにする

 

Amazon ECS の活用事例

  • 構成
    • Application Load Balancer (ALB) => EC2コンテナ
    • コンテナのオーケストレーションはECSが担当)

  • 便利な ECS 機能
    • 死活監視
      • 落ちた EC2 を ALB のバランシング先から外し、新規コンテナを起動
    • 柔軟な Deploy 方法(Rolling Update, Blue/Green)


Amazon Aurora の活用事例

  • Aurora 採用理由
    • 1. Route53 (CNAME に Aurora Endpoint 設定) で Blue/Green切替が容易なため
    • 2. リードレプリカ機能のメリットが大きかったため
      • ロードバランシング機能(⇒構成がシンプルになった)
      • 自動復旧機能があるため、切り離し、再起動、クラスターへの再投入を自動でやってくれる

検証/切替の方法

  • 検証方法
    • API レスポンス比較
      • 内政ツールでオンプレと AWS で API レスポンスに差異がないこと
    • JMeter を使った負荷試験
      • Auto Scaling グループで JMeter クラスターを構築

 

  • オンプレから AWS への切替方法
    • 事前にドメイン管理を Route53 へ移行
    • Route53 の Weighted Routing 機能を使って切替
      • 段階1. 100% オンプレへ振る
      • 段階2. 50% AWS へ振る
      • 段階3. 問題無いことを確認して100% AWS へ振る

 

クラウド移行とコンテナ化がもたらした効果

  • コード化により、プルリクでインフラ構成チェックが可能になり品質向上
  • Docker 化により、ポータビリティが向上
  • AWS 移行により、
    • アクセス数に応じたオートスケール
    • インフラエンジニアの運用コストが減った(現状ほぼ0になった)

 

〜マイクロサービスを設計する全ての開発者に送る〜クラウド時代のマイクロサービス設計徹底解説!

スピーカー:グロースエクスパートナーズ株式会社 アーキテクチャ事業本部 執行役員 鈴木 雄介氏

冒頭で「マイクロサービス設計徹底解説」ではなく、「マイクロサービス化設計入門」です、と説明があったように、なぜマイクロサービスなのか?から始まり、設計のポイントに触れられていました。 嬉しいことに 資料が公開されています ので、ここでは簡単な所感のみとします。

個人的には、マイクロサービスはサービス分割の観点をどうするかが迷いどころです。ドメインモデルを成熟させていくには時間がかかり一朝一夕にはいかないわけで・・・・ 本セッションでの、ドメインだけでは辛いので、業務や利用の観点で同時に変更が発生するものは一緒にしておけばいい(変更要因のタイミングや理由が同じものをくくる)という考え方はなるほど、と思いました。

また、マイクロサービス化するには不整合を許容できる必要があるという点も大事なポイントです。

不整合の例

  • Amazon 社の商品が配達完了になっているのに届いていない場合に問合せしたら Amazon クーポンをもらえた
    ⇒ サービス間の疎結合を重視して、運用でリカバリする方がメリットあるならクーポンという手もあり、というメッセージは印象的でした。

何のためのマイクロサービスかという目的を見失って、マイクロサービスという手段が目的になってしまっていないか、陥りがちなポイントだと思いました。マイクロサービス化の具体的な方法には触れていませんが、示唆に富んだ興味深い内容でした。

 

Athena 指向アナリティクス 〜真面目に手を抜き価値を得よ〜

スピーカー:JapanTaxi Co.,Ltd. 開発部 技術基盤チーム リーダー 梅田 昌太氏

Athena 概要

  • 雑に扱える Presto
  • 課金がスキャン量のみ(転送量も気にしないで良い)
  • S3 がそのままデータソースとして使える(⇒ データロードが不要)
  • 対応データ形式:json、csv、parquet・・・etc

Amazon Elastic MapReduce (EMR) との使い分け

  • EMR はマネージドな Presto
  • 前後処理、ストリーム処理が必要なら EMR 一択
  • ゼロベースならまずは Athenaを検討

アプリ「全国タクシー」のログ解析システムの機能と構成

  • データ収集(全て S3 へ)
    • ログ (nginx、Ruby on Rails、.NET アプリ、Windows イベントログ)
      • Fluentd で S3 へ格納
    • DBデータ (MySQL、SQLServer)
      • Embulk (ETL ツールとして利用)
  • フロー制御
    • Digdag
  • 可視化
    • Redash
      • 多様なデータソースに対応
      • Athena も正式サポート
      • SQL 書けば Web UI でダッシュボードが提供可能

Athena 活用例

ケース1. 予約注文の可視化

  • Athena と Redash でリアルタイム可視化

ケース2. 地図上での時系列データの可視化

  • Embulk + Athena
    • Athena は AWS CLI で制御
  • curl コマンド (地図 API へ CSV を投げる)
  • 全体フロー制御は Digdag

今後のAthenaへの期待

  • 東京リージョンでのサービスイン
  • UDF サポート
  • Output Result への選択 (Athena から DWH/DMへ出力して BI で可視化などしたい)

 

私は Athena は S3 上のデータを手軽に分析できることからアドホックな利用イメージでいたのですが、分析から可視化まで自動化して活用されている本セッションを聞いて Athena のイメージが変わりました。活用していきたいと思います。

 

Sansan がメッセージング (Amazon SQS) でスケーラビリティを手に入れた話: using C# on Windows

Sansan株式会社 Sansan事業部 開発部 部長  神原 淳史氏

メッセージングとは

  • キューを介してプロセス/アプリ間でデータや制御を伝達する仕組み
  • メッセージはテキスト
  • エラーの場合、再度処理対象となる(リトライ)
  • 一定回数失敗した場合、別キューに ( Dead Letter Queue)  入る

 

AWS のメッセージングサービス

  • SQS Standard Queue
    • 1秒当たりのトランザクション数: ほぼ無制限
    • At-Most-Once: 非対応 (At-Least-Once。メッセージの重複配信の可能性がある)
    • FIFO: ベストエフォート (メッセージの順序は保証されない)
  • SQS FIFO Queue 
    • At-Most-Once、FIFO をサポートしているが、秒間トランザクション数に制限。性能と厳密さのトレードオフ。

Sansan 社では SQS Standard Queue を利用中。


メッセージングによる課題解決例

巨大なトランザクション

  • ユーザ別の名刺の参照・更新権限の洗替処理
  • レコード件数がユーザ数 x ユーザ数分になった。5000ユーザの場合、1トランザクションで2500万件のレコード DELETE/INSERT
    • 対策
      • SQS から Consumer (EC2) ユーザ単位でトランザクションを分割して SQS から並列 (5000ユーザの場合、1トランザクション5000件といった具合)
      • 構成イメージ: Web API => SQS => Consumer A (EC2 ※トランザクション分割) => SQS => Consumer B (EC2 ※ここが並列) => DB

終わらないバッチ処理

  • 処理A => 処理B => 処理C
    • 直列処理で処理A は処理B を知っていないといけない。
  • 処理A => Event Aggregator
    => 処理B
    => 処理C ※Event Aggregatorから処理B/Cへ振られるイメージ
    • DDD (Domain-Driven Design) で言うところの Domain Event で実装
    • 構成イメージ: Publisher => SNS
      => SQS Subscriber Queue A => Subscriber A
      => SQS Subscriber Queue B => Subscriber B 

急激に変化する DB 負荷

  • 時間帯によって DB 負荷にばらつき
  • 対策
    • 平均的な負荷にならす(ピークの先送り)
    • 構成イメージ: Web API => SQS => Consumer (EC2 ※並列) => DB
    • 並列の制御は、
      • インスタンスレベル:Auto Scaling グループ
      • スレッドレベル:言語で制御 (C# だと セマフォ

 

低いメンテナンス自由度

  • メンテするために連携先の別社内サービスとの調整が必要
    • 対策
      • 別サービス呼出し処理の前に SQS を配置
      • 構成イメージ: Web API => SQS => Consumer (EC2 ※並列) => 別サービス
      • Consumer を停止しても SQS にメッセージがキューイングされるため、Consumer を起動するだけで復帰

 

リカバリ不可能な処理

  • SQS があることで、
    • リトライ標準装備
    • 失敗し続けても Dead Letter Queue に入る (どうあれテキストという形で残るため救いようがある)

 

それでも銀の弾丸はない

そして、最後に銀の弾丸がないことをしっかりと説明されている点が素晴らしかったです。

  • メッセージング注意点
    • 冪等性が保証されない
    • 順序が保証されない
      • メッセージ間の依存がある場合はアプリ側で制御する必要がある
    • 結果整合性モデルになる
      • 並列でトランザクション分割しているため、ビジネストランザクションとして整合性は取れない
        ⇒ 要件として必須なら、ビジネストランザクションが完了するまでユーザに参照させないといった仕組みが必要 (ただし、設計は難しい)

「特性を知り、適切な方法、場面で使用するのが肝心」と締めくくられていました。当たり前のことですが、見失いがちな大事な点ですね。

 

最後に

以上、AWS Summit Tokyo 2017 Day2 のレポートでした。

Day4 も参加予定ですので、レポートしたいと思います。

Enjoy AWS!!!