本日も乙

ただの自己満足な備忘録。

AWS Summit Tokyo 2019に行ってきた

aws 参加レポート

3ヶ月ぶりのブログ更新。習慣から外れるとずっとなかなか書かなくなりますね･･･

今年も AWS Summit Tokyo に行ってきました。 昨年までは品川のグランドプリンスホテル新高輪だったのですが、参加者が増えて手狭になったのか、今年は幕張メッセ。遠かった〜。 来年はパシフィコ横浜なので、オフィスから割と行きやすいので良かったなと。

昨年とかは全日程参加してセッション参加しまくり、ブース見まくり、認定者ラウンジでくつろぎまくりだったのですが、今年は業務がおっつかなかったりと事情があり、1日目、3日目の参加で、受講が2セッション + ワークショップ（DeepRacer）のみでした。あまりセッションを聞かなかった代わりに、ブースを見て回ったり、認定者ラウンジで DeepRacer の評価関数を書いてたりしました（もちろん仕事もね･･･！）。

Sansanのビジネスを成長させるプロダクト開発とAWS

弊社CTO藤倉が登壇しました。

Sansanの強みは二つ。「大きなビジョン = プロダクト・コンセプト」と「顕在化した足元の課題解決」。

名刺管理はただ、名刺を管理するだけではなく、名刺交換による人と人との出会い。かなり壮大なビジョンですが、はじめから大きなビジョンでやっても顧客がついていなかったり、プロダクトが成長していないと話にならない。だから顕在化した課題に対して向き合う必要があります。

Sansanの創業期、変革期を振り返って、それぞれの転機における課題とその解決について紹介されました。

Sansan, Eight のプロダクトを支える、名刺のデータ化に焦点をあてていたのは珍しいと思いました。特に R&D による名刺のデータ化自動化の取り組みも今まであまり外部に発信されていなかった内容なので、フレッシュな気持ちで聞いていました。

DeepRacer ワークショップ

めっちゃ楽しみにしてました！DeepRacer を始めてみたかったのですが、イマイチ取り組み方が分からず、コツも教えてくれるかなという期待から参加してみました。 ちなみに、当ワークショップは募集開始してすぐ埋まってしまったので、枠を取れたのは運が良かったです。

ワークショップの内容はクラスメソッドさんのブログが詳しいので、そちらを読んだほうがいいのですが、私の個人メモも貼っておきます。

【DeepRacer】ワークショップの超丁寧な日本語資料で強化学習を体験する #AWSSummit ｜ DevelopersIO

ワークショップ資料

ワークショップは前半は座学、後半はハンズオン形式でした。後半のハンズオン資料は以下です。

aws-deepracer-workshops/Readme-Japanese.md at master · aws-samples/aws-deepracer-workshops · GitHub

AWS DeepRacer とは

強化学習をすべてのDeveloperに届けたいという想い

DeepRacer を走らせるには

  • カメラ（DeepLens）からの見え方によって、ルールベースで走る
  • すべての事象を登録するのは不可能
    • => 強化学習

機械学習

  • 教師あり学習
    • 学習データにラベル付け（アノテーション）する
  • 教師なし学習
    • 学習データにラベル不要
    • 例) カメラ付きの実機カーを熟練のドライバーが運転
  • 強化学習
    • 特定の環境下で一連の行動から学習
    • 報酬を与える
      • 例) 犬
        • 良い行動には報酬をあたえる
    • DeepRacerではこちらを使う

強化学習の用語

  • エージェント
    • 実世界でいうと犬
    • DeepRacer
  • 環境
    • コース
  • 報酬関数
    • 特定の行動にインセンティブを与える
    • 良い報酬関数があれば良い結果となる
    • レースのための報酬関数
    • 報酬関数がスカスカだと行動しづらい
    • 例) 真ん中を走るようにインセンティブを与える
    • 価値関数
    • 報酬関数の総和が最大になる期待値
    • ステップの割引率 0.9
      • 将来のことを加味する割引率。大きいほど将来のことを考える
    • 方策関数(reward function)
    • ポリシー
    • ランダムに行動
  • 強化学習アルゴリズム
    • ゴールは累積報酬の最大化
    • 学習がすすむまでは現在のポリシー（方策）をつかって、データを集める
    • 勾配の方向へポリシー（方策）を変えていく

流れ

  1. モデル作成
  2. 報酬関数
  3. ハイパーパラメータ
    • Learning rate
    • Batch size
    • Epochs
    • Discount factor
    • of episodes
      • 学習するエピソード数
  4. 行動空間
    • スピードとステアリング（角度）の組み合わせで定義
  5. 学習の設定
  6. 学習
  7. 60分程度
  8. DeepRacerが自分の位置（座標; X, Y）を知ることができる
  9. 参照点（waypoints)
    • どのぐらいのスピード、角度で進んだか
  10. 評価
  11. バーチャルサーキット or 実機
  12. モデルの調整 => 2に戻る

DeepRacer のハードウェア詳細

  • Wi-Fi: 802.11ac
  • CPU: Intel Atom
  • Memory: 4GB
  • ストレージ: 32GB
  • バッテリーは2種類
    • 15分走るとバテてくる
  • OS: Ubuntu 16
  • カメラ: DeepLens

シミュレーションと実環境のドメイン転移

  • シミュレーションで上手くいっても実環境でうまくいかないことが多い
  • シミュレーション画像を利用して学習しているが、実機は実世界の画像を利用している

  • 実状況をシミュレーションに反映させるのが難しい

  • 戦略

    • 実環境に近づける
    • いろんなノイズを入れてタフにする
    • モデルのモジュール化
    • どこが悪いのかを特定しやすく

リソース削除

NAT Gatewayなど使ってなくても課金は発生するので、使わないときは「Reset resource」で関連リソースを削除しておきましょう。 詳細はこちらのスライドをご参照ください。

やってみた感想

強化学習や報酬関数など少しつまんだことがあったので、多少とっつきやすかったですが、「じゃあ具体的にどうやって報酬を定めるの？」というのはなかなか難しいです。 しかし、DeepRacer 側で3種類のサンプルが用意されており、それをベースにできるので、私の初心者でも動かすことはできます。 本当は AWS Summit 中に DeepRacer リーグに参戦したかったのですが、2日目が忙しく、3日目で頑張って報酬関数と学習をしていて、終了時間（16時半？）を過ぎていました。1日目と同じ18時だと思って油断してました。無念。

週末も試行錯誤して学習した結果、仮想シミュレーション上で1周20秒程度で完走できるようになりました。

twitter.com

今後もちょくちょく改良を重ねて次の機会をうかがいたいと思います。

サービスメッシュは本当に必要なのか、何を解決するのか

今流行りのサービスメッシュ、おおよその理解はできているつもりですが、復習がてらサービスメッシュで何を解決できるのか改めて再認識すべく受講しました。

既存のアプリにおける課題

  • LB -> App -> DB という構成を例にとる
  • 開発が進んでアプリの規模が大きくなる
  • 障害がポツポツ出るようになる
    • マイクロサービス化しよう！
    • マイクロサービス化しようと言い始めてから既存アプリはモノリスになる

モノリスにおける課題

  • 関係者間調整のオーバーヘッド
    • デプロイ日など
  • モジュール構造をきれいに維持する困難さ
  • 多数ある機能の一つだけをスケールアウトしたいが、まとめてスケールアウトしなければならない
    • 非効率なスケーリング
  • テスト・ビルドに時間がかかる

マイクロサービス化に期待される効果

  • 影響範囲の局所化
  • 独立したデプロイとスケーリング
  • アーキテクチャ、プログラミング言語の変更容易さ
    • 例) PHP -> Golang

モノリスにおける考察

ALB -> App on EC2/Container -> Aurora

  • 通常は複数のEC2

  • SQS, S3, ElastiCacheなど多数のサービスとの連携

  • 「たまにレイテンシが遅い場合がある」

    • レイテンシのメトリクスは特に問題なし
    • ログを見ると、確かに遅いリクエストがあった
      • ただ、どこに時間がかかったのか分からない
      • => AWS X-Ray
  • AWS X-Ray
    • 分散トレーシングサービス
    • リクエスト単位で遅い処理を特定することができる
    • AWS SDKを組み込む必要がある

マイクロサービスの課題

  • サービスの分割が適切か
    • ドメインレベル(DDD)
    • 正解がないので難しい（チーム状況などによっても変わってくる）
  • テストが難しい
  • 影響範囲を自サービス内に収めることが難しい
    • 呼び出し元に影響する

サービス間通信の信頼性を高める防御的実装

  • 呼び出し先サービスの位置は一定ではない
    • 名前解決
    • => サービスディスカバリ
  • 一時的な呼び出しの失敗
    • => リトライ
  • 継続した呼び出しの失敗
    • => サーキットブレーカー
    • 呼び出し先サービスの復旧の邪魔になってしまう
  • 呼び出し先サービスのパフォーマンス悪化
    • => タイムアウト
  • 呼び出し元システムの不具合
    • ずっと400になるようなリクエストをしてくるかもしれない
    • => スロットリング

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

  • あるとき、システムからエラーが返ってきた
  • 外からみると、マイクロサービス郡の大きな「システム」
  • 失敗は、どこで、なぜ起きたのか
    • 観測が必要
  • ログ/メトリクス/トレース情報の出力
  • 各サービスの既存実装の出力フォーマットが不揃いだとコンテキストが見えない
    • 個々のサービスだと見えるが、全体で見えづらい
    • 全サービスのフォーマットの統一化が必要
  • すべて実装しきること、それを見ることができるのか
    • スキル差、言語、フレームワークによって難しい
    • 統一フォーマットを変更することの困難さ

共通ライブラリという解決策

  • マイクロサービス = アプリケーションコード + 共通ライブラリ
    • アプリケーションコードの改修が必要になり、やってくれないことも
    • 共通ライブラリでパフォーマンス悪化になることも（トレーシングでは起こり得る）
    • 特定言語でライブラリが提供されていないこともある
    • ライブラリを入れてくれないチーム
    • ライブラリのアップデートをしてくれない

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

  • プロキシにログ、メトリクスなどを仕込む
  • プロキシを経由して通信する
    • => サービスメッシュ

Envoy Proxy

  • プロキシのデファクト
  • OSS
  • コミュニティサポート
  • 多数のインテグレーション

  • 多数の本番環境利用実績

  • プロキシの設定をYAMLで定義する

  • プロキシは誰が管理するのか？

    • セントラルのチーム
  • プロキシの設定だけを変えるのにアプリもデプロイし直すの？
    • => それを解決するのが AWS App Mesh
    • Envoyの設定変更に、アプリケーションへの影響はない
  • App Meshはサービスメッシュのコントロールプレーン

AWS App Mesh

  • ECS, Fargate, EKS, K8s on EC2

  • コンテナ以外にも、EC2にも対応している

  • トラフィック管理

  • ロギング
  • メトリクス

  • 分散トレーシング

  • App Mesh のパブリックロードマップがでている

あなたのシステムにサービスメッシュは本当に必要なのか？

  • 課題に対する必要性を検討する
  • サービスメッシュが必要か
    • X-Rayだけで済むならそれだけでも良い
    • OSSライブラリの利用で十分なケース
      • Netflixも長い間共通ライブラリでやってきた
  • 動的なサービスメッシュが必要か

感想

モノリシックなアプリケーションをマイクロサービス化にするにあたって顕在化してくる課題に対して、どのようなアプローチが良いのか、サービスメッシュが出てきた背景あたりを丁寧に解説されていました。いいことづくめに思えるサービスメッシュですが、自分たちのシステムにとって本当に必要なのか、分散トレーシングだけなら X-Ray だけを使えばいい、共通ライブラリで頑張ればいい。なぜサービスメッシュが必要なのか、課題を明確にしましょうというのが最も重要なメッセージでした。

まとめ

今年は参加途中だったので不完全燃焼気味でしたが、会場をうろうろしてお世話になっているAWSの人に挨拶できたので良かったなと思います。

こんなツイートしたらCTOにいいねされました。やばい。

twitter.com