AWS SUMMIT TOKYO 2019 参加レポ

（株）いい生活 サーバープラットフォームチーム の @es-y-tada です。
サーバサイドエンジニアとして、最近では EKS を基盤とした新規APIの開発を行っています。
今回は先日行われた AWS SUMMIT TOKYO 2019 のセッションのなかから、個人的に印象的だったセッションのいくつかについてレポートをします。

注目のセッション

「サービスメッシュは本当に必要なのか？何を解決するのか？」
アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト 原 康紘

Abstract

AWS 上でのマネージド・サービスメッシュを実現する AWS App Mesh や、Kubernetes ワークロードとの親和性が高い Istio など、サービスメッシュの世界には数々のプロダクトやソリューション、アイデアが生まれつつあります。本セッションでは、マイクロサービスにおけるベストプラクティスの集大成とも言えるサービスメッシュについて、その解決すべき課題と人々が熱狂する理由、サービスメッシュそのものの必要性について掘り下げます。同時に、サービスメッシュを実現する上で最も重要なコンポーネントの一つとも言える Envoy の詳細にも触れながら、皆さまがサービスメッシュを活用する手助けとなるヒントを紹介します。

My Interest

EKS（Kubernetes）でサービス構築中ということもあり、サービスメッシュや Istio は度々話題になる言葉ではありましたが、実際のところどういうものかは詳しく知りませんでした。
またこのセッション以前に参加したセッションで AWS App Mesh について触れられていたので気になっていました。
そのあたりの知識を補完しつつ、 AWS で実現可能な選択肢を持ち帰って FB できたらと思い、参加しました。

In Breaf

なぜ Envoy は必要になったか

「マイクロサービス化されていない」ことは 悪ではない

• 課題が表出してマイクロサービス化を考えた瞬間から Monolish （悪いニュアンスを含む）になる

現実世界のモノリスは複雑なので、障害特定などの場面でトレーシングすることは難しいのではないか？

• はじめからトレーシングすることを考えて準備しておけば、適切なツールを使って追うことは十分可能

「マイクロサービス化」の難しさにも目を向けるべき

• サービスを適切に分割することがそもそも難しい
• マイクロサービス軍団とミドルウェア合わせた統合テストは Monilish 並みに（よりも）難しい
• マイクロサービス内部に影響範囲を収めることは難しい
• サービス間通信の信頼性
• サービス間通信の可観測性

サービス間の信頼性 -Reliability-

• 通信が失敗する前提での防御的な実装が必要
  • サービスディスカバリ、リトライ、サーキットブレーカ、タイムアウト、スロットリング

サービス間通信の可観測性 -Observability-

• システムを観測する仕組みが必要
• ログ/メトリクス/トレース情報出力
  • 各サービスの既存実装の出力フォーマットが不揃いだとコンテキストが見えない
  • 共通化の必要性

システム全体で共通のフォーマットを実装し切ることは困難

• 各サービスで個別実装してしまう、複数の言語やフレームワークが異なる、実装担当者と品質担保方法の違いなど
• 逆に、統一フォーマット変更時のコストが課題に

共通ライブラリという方法は銀の弾丸ではない

• アプリケーション改修が必要になる
• ライブラリを入れたらパフォーマンスが悪化してしまう可能性も十分有る
• 共通ライブラリを、対応していない言語/バージョンに追従させ続けていく必要性がある
• なにより粗結合な実装、自律的チーム関係の維持というマイクロサービスの根幹と相反する

サービスメッシュの世界

プロキシへのオフロードというアイデア

• プロキシにリトライやメトリクス収集を担保させてアプリケーションから切り離す
• すべてのマイクロサービスがプロキシを通して通信する -> サービスメッシュの世界

Envoy

• Envoy Proxy の設定は yaml で定義される
• proxy （の設定ファイル）は誰が管理するのか、という問題
  • アプリケーションとproxy設定の間ではデプロイタイミングのハレーションが起こってしまう
• これを解決するのが AWS App Mesh
  • 動的に envoy 設定を配信、更新できる
  • AWS App Mesh はサービスメッシュのコントロールプレーンとして働き、マイクロサービスの設定、トポロジーを管理する

AWS App Mesh

• アプリケーションレベルのネットワークを管理できる
• クラスタやサービスにまたがるメッシュの構築
  • コンテナに限らない。 EC2 でも
  • EC2 ECS EKS 関わらず1つのメッシュに
• マネージドコントロールプレーン
• 無料

サービスメッシュは本当に必要なのか

サービスメッシュは自分のシステムに必要なのか、課題に対する必要性を検討しつつ考えること

• そもそもサービスメッシュが必要ないかもしれない
  • X-Ray での分散トレーシングで十分かもしれない
  • トラフィックコントロールは ALB で十分かもしれない
  • OSS ライブラリの利用で十分低コストに共通フォーマット化できるかもしれない
• それでもサービスメッシュが必要だったとして、動的でなくても良いかもしれない
  • envoy の静的設定ファイルで十分かもしれない

In My Opinion

なぜマイクロサービスが必要になり、サービスメッシュへと到達したのかまで、よくわかりました。
そのうえで、AWS が提供するものは何で、どれを選択するかは目的ありきで考えるべし、という熱い問いかけを開発者に投げかけられた講演でした。
「モダンな開発してる俺、カッケー」では0点ということを心に刻んでおきたいと思います。

システムのフェーズに合わせて必要なものを選ぶのが重要で、ある程度開発者や言語の多様性が進んだ大きなサービスでない限りは、サービスメッシュは必須ではないのではないかな、というのが個人的な感想です。
（とはいえ、ある程度システムが成長した段階では避け得ない課題でしょうから、心の準備は必要なんでしょうね）

役立ちそうなセッション

データレイク構築における成功の秘訣 ～マインドと進め方、設計ベストプラクティス～

アマゾン ウェブ サービス ジャパン株式会社 プロフェッショナルサービス本部 コンサルタント 畔勝 洋平

Abstract

多くの企業は勘と経験の経営からデータドリブンな経営に生まれ変わろうとしています。そのような環境の中、ある日突然、データレイクや分析基盤の構築プロジェクトを担当することになるお客様は少なくありません。本セッションではAWSでデータレイクを構築する際のプロジェクトの進め方や勘所、設計ベストプラクティスをご紹介します。

My Interest

当社ではサービス提供を通じて不動産・広告・ユーザアクティビティ・契約・マネーフローなどの幅広いデータを蓄積していますが、二次利用が進んでいないという課題感があります。
将来的な課題解決に向けて、 データレイクを AWS で構築する場合の構成について聞きたい、と思い臨みました。

In Breaf

データレイクがやること

• 詳細なデータを消さずにすべてそのまま蓄積する
• 多様なフォーマットのデータをそのまま保存する
• データとともに メタデータ を登録することで価値が生まれる

4つのマインドをもつことが大事

1. Working Backwards --ステークホルダが多く全員の総意を得るのが難しい問題

• 全ては（自分たちにとっての）お客様を起点に逆算して考える
• ステークホルダの目線を合わせる。迷子になったら立ち戻る

1. スモールスタート

• AWSサービスや分析アプリの進化は速い
• 将来を見越した 過度な 要件定義・技術選定・標準化には こだわらない
• まずは必要なデータ活用ワークフローを作って、改善サイクルを回し始めることが大事

1. ハンズオントレーニング

• エンジニアだけでなくIT戦略の意思決定に関わる ステークホルダにもハンズオンに参加させる
• 地味に意思決定に効いてくる
• ex) AWS Data Lake ハンズオンセミナー
• ex) 有償クラストレーニング（1−3日の集合研修）
• プロジェクトが始まる前に

1. PoC ドリブン設計

8つのベストプラクティス

1. S3のデータをSQLで分析

• Athena, EMR で直接 SQL できる
• DWH としての Redshift と使い分け
  • 収集用バケット(S3) -> Glue -> 蓄積用バケット(S3)
• フィルタ条件（SQLのキー）をキーにして適切にパーティション分割するのがおすすめ
• きちんとやれば劇的にスキャンサイズを下げられ、実行時間、利用コストともに削減可能
• parquet などの列指向フォーマットに変換するとパフォーマンスを上げられる

1. S3バケットの分け方

• 人が見てわかりやすい単位
• バージョニング、ライフサイクルポリシー、オブジェクトロックの違いで分ける
• また、バケット単位のサービス上限に当たらないように

1. マルチアカウント構成

• データレイク用のアカウントを分けるのがおすすめ
  • アカウント単位で明確に権限、課金、設定変更の影響範囲を分割
  • バケット数上限にふれづらくなるメリットも

1. S3 バケット間コピーを活用する

• 同じリージョン内なら無料でアカウント跨ぎコピー可能

1. S3 クロスアカウントアクセス制御

• バケットポリシーで aws:PrincipalOrgID を推奨
  • aws アカウントIDで記述するとバケットポリシーのサイズ上限に引っかかる

1. SSE-KMS による暗号化

• SSE: サーバサイド暗号化
  • 暗号化を行いつつも S3 側でデータの絞り込みを効かせられる
  • 暗号化キーへのアクセス許可のあるユーザ以外は、 S3 をパプリック公開してもアクセスできない状態にできる

1. S3 パプリック公開防止

• S3 Block Public Access
  * アカウントレベルで有効化しておけばOK

1. SCP による特定操作の禁止

• root でさえ操作を不許可にできる

In My Opinion

AWS 前提でデータ基盤の構築を考える場合、いったん全てのデータを S3 に集約する。
逆に言えばそれさえやってしまえば AWS のサービスを利用してなんでも構築できそう、というのがよくわかったセッションでした。

このときの S3 運用のまさしくベストプラクティスが端的にまとまりつつ、一歩踏み込んだ内容も含まれており聴き応えがありました。
特にバケット分割やパーティション分割はじめ、実際に構築する段階になって悩むことになりそうな部分の指針を聞けたのは収穫だったとおもます

内容には（社内）ステークホルダの期待値コントロールの話題まで含んでおり、スタートアップだけでなく、「データは溜まってきているが分析基盤の形にはできていない」それなりの規模の会社にとって、指針となりうる考え方が散りばめられていたように思います。

ダークホースだったセッション

Amazon Pinpoint でユーザーを掴んで離すな

アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト 塚田 朗弘
Amazon Web Services Principal Solutions Architect John Burry

Abstract

柔軟で高機能なカスタマーエンゲージメントサービス、Amazon Pinpoint を隅々まで、国内外の事例を交えて解説します。サービスの成長のためには、適切なメッセージを、適切なタイミング、ユーザー、チャネルに送信する必要があります。また、その結果を迅速に可視化し、解析することも重要です。
Amazon Pinpoint では、モバイルプッシュ通知やスケジューリング・A/Bテスト機能、ダッシュボードなど一般的な機能に加え、送信速度調整やカスタムチャネル、Event Stream といったユニークで役立つ機能を提供しており、様々な業種・業態のお客様の多様なニーズに答えます。

My Interest

実は当初聞きにいく予定のセッションではなかったのですが、「誰かこのセッション聞きに行かないの？」という社内の声を見かけたため、急遽参加しに行きました。

Amazon Pinpoint というサービス自体ほとんど初耳の状態で、始まる前はあまり期待をしていなかったというのが正直なところで、
当社システム中でのメール・通知に関する部分のリプレース候補になるかだけ確認しよう、という程度の思いでした。

In Breaf

デジタルユーザーエンゲージメント

• 2025年までに750億のエンドポイントが相互に接続されると予想
  • SNS だけでなく IoT まで含めてすべて「エンドポイント」としてカウント
  • 多くユーザは画一的な扱いではなく、適切に個人に対して パーソナライズされたメッセージング を望んでいる
  • 内容だけでなく、メッセージがメールなのかpush通知なのかSNSなのか、などもパーソナライズ
  • サイロ化（孤立した）体験から、連続性のある繋がった体験
    • あるメディア/デバイスにインプットした内容が別のメディア/デバイスに連動されていく

エンゲージメントのためのサービス: Amazon Pinpoint

• Amazon Pinpoint: ユーザエンゲージメントプラットフォーム
  • デバイスに入れることでユーザ行動を AWS クラウドに収集、解析、可視化
  • ダッシュボード上から選択した条件に合うユーザに通知を送信可能
    • マーケターにも開発者にもわかりやすい UI
• ファネル分析
  • ユーザが行動がどこまで到達したか（メール開封・リンク先への遷移など）を可視化し、改善効果の高いところを明らかにする
• イベントベース通知機能
  • イベントトリガーの通知配信が可能（たとえば決済通知）
• Voice チャネルサポート
  • Poly と統合されており、自然な自動音声で電話をかけられる
• 配信性能ダッシュボード
  • Eメールがスパム判定されていないかなど、ユーザにメッセージが正しく届いているかチェック、チューニング
• 細やかな配信設定
  • 秒間最大送信数（送信速度調整、一斉送信の結果アクセスが集中するとサーバ負荷に懸念）
  • ユーザが受け取る通知数制御
  • 配信除外時間

Amazon Pinpoint の周りのサービス

• インポート機能による柔軟なセグメンテーション
  • 通知するための条件を json などでインポートできる
  • athema や RDS に対してクエリして抽出し、csv,jsonをs3に配置。これを Amazon Pinpoint でインポートして通知
  • 高速通知基盤として活用可能
• イベントストリームを前提としたより柔軟な分析
  • イベントを Kinesis に流せる
• カスタムチャネルでは Lambda を呼び出すことで柔軟な動作が可能

Amazon Pinpoint + Amazon Personalize

• 継続的改善
• 自分の収集したデータでユーザにパーソナライズされた自分のモデルを作成できる
• AWS の AutoML サポートでより容易に
  1. 例えばメール配信を起点に、ユーザ行動を取得し、 Personalize で分析
  2. その結果を FB してパーソナライズし、画面表示を変えたり、通知を変えたり

Amazon Pinpoint + Amazon QuickSight

• BIツール
  • PAmazon inpoint -> Kinesis Stream -> SPICE(QuickSight) に集約
  • Amazon Pinpoint のダッシュボードよりも QuickSight のほうがカスタマイズ性が高い

In My Opinion

爆発的に増加していくエンドポイントとユーザアクティビティログをいかに収集し、良いデジタルユーザーエンゲージメントに繋げられるか？という問いかけからスタート。

Amazon Pinpoint にはエッジデバイスからのアクティビティログ収集サポートを含むものの、本質的にはメッセージングハブと言えるでしょう。
多様なエッジデバイスに対するメッセージングを集約できること自体にメリットがあるうえ、エッジデバイスからのアクティビティログ収集が可能であったり、東京リージョンで利用可能になったばかりの Amazon Personalize をはじめとして AWS のデータ分析・機械学習サービスと柔軟に連携可能であったりする点が魅力だと感じました。

セッションでは AWS Japan の SA だけでなく、米国 AWS の SA もデモンストレーションのために登壇するなど、 AWS の熱の入り様も印象的でした。

メッセージングを Amazon Pinpoint にリプレースした後の世界に面白そうなネタが大量に広がっていることがよくわかったので、かなりモチベーションが上がりました。

まとめ

現在の課題（コンテナ技術・サービスメッシュ）、直近の課題（データレイク）、将来的な展望（AWS Pinpoint）とバランスよくモチベーションの上がる話をたくさん聞けた3日間でした。
今回紹介した3つのセッションでは、

• コンテナベースのシステムでまずできるようにすることがなにかの指針を得られた。マイクロサービスやサービスメッシュ自体を目指すのではなく、システムのステージに合わせて適切なトレーニングや継続的改善がしやすい世界を構築するためにどうするか考えるべし、という指針が得られた
• データレイクは S3 へのデータアップロードを入り口かつベースに考える。その後はとりあえず Amazon Athena, Amazon EMR を中心に考えつつ DWH の構築も視野に入れて考えれば良い。その頃には新しい分析サービスが出ている可能性もあるので、そのあたりにアジャストすることにこだわり過ぎずに、むしろ S3 にうまくデータを貯める仕組みをデザインするほうが有益そう
• Pinpoint 中心にユーザアクティビティを収集して分析・機械学習と絡めるプラットフォームは整いつつある。エンドポイントが多様化する中で1つのプラットフォームに集約して管理・分析できるメリットは大きく、特にメッセージングというサービスの提供とアクティビティの収集というデータの蓄積がシームレスに一括して行える点は嬉しいと感じる

など個人的には多くの学びを得ることができたと思っています。

セッション別のレポートではあまり触れられませんでしたが、全体として

• AWS のサービスは顧客の要望に寄り添って作られている。やりたいと思ったことをできるようにしてくれる
• AWS というプラットフォームの連携力はやはり強力

ということも感じました。

エンジニアとしては、今まさに直面している課題に対する解決策（の候補）を提示してもらえるのはものすごくありがたいですし、
その上に「どんな課題が解決できるか」「どんな新サービスを実現できるか」という想像力の掻き立てられ、個人的にモチベーションがものすごくアップしました。

これからも AWS 使い倒していきたいと思います。

さいごに

株式会社いい生活では一緒に働く仲間を募集しています。