JAWS DAYS 2018 参加レポート #jawsdays #jawsdays2018

勉強会メモ AWS

　JAWS DAYS 2018 参加してきました！

午前中からお昼にかけて、娘の習い事に行っていたため、午後からの参戦です。数セッションしか聴けませんでしたが、非常に勉強になりましたのでメモを投稿したいと思います。（取ったメモをほぼ修正せずに載せます。誤字脱字などあったらすみません。）

14:00-14:50 ユーザー企業におけるサーバレスシステムへの移行 #jd2018_g

なぜ、サーバレスに至ったのか

大規模システムはイヤ
  • システム変更の影響範囲が広いと、機能を追加しようとしたときに「まずは影響調査から」になってしまう。 そうなると、せっかく業務サイドが新しい機能を考えてくれても、「ビジネス的な効果 < 実装工数」となってしまう。
  • 過去に特定ベンダーじゃないと改修できない状況になっていた。ロックインにより、スピード感がでない。結果、ビジネスが伸びない。
  • よし、システムは小さく作ろう！
密結合はイヤ
  • 機能改修しやすくしたい
  • 間にキューやらを挟む構成を採用する
インフラ管理は嫌だ
  • オンプレで全て管理すると、インフラで抑えるべきことが多くなってしまい、「ビジネスのこと」を考えられない！
  • IaaS で随分ましになった。
  • でも、サーバレスで「アプリのみに集中」したい！
スケール「アップ」は嫌だ
  • 159億のレコードを扱うのにスケールアップ型じゃ太刀打ちできん。
  • 分散志向へ。
  • AWS のサービスもスケールアウト型が多い。
  • フルマネージドなサービスを使っていく。

サーバレス使ってみた

構成図

f:id:ketancho_jp:20180310155906j:plain:w500

AWS の各サービスの特徴を活かしていく
S3
  • 特徴
    • サーバありの場合は、冗長性、世代管理を考えないといけない
    • イベント検知（ファイルアップ完了のタイミング）についても自分で考える必要がある
    • S3 なら全部標準
  • 気をつけるポイント
    • ファイル移動が失敗することがある。全てのファイルを移動しようとしたときに、幾つか漏れてしまうことがある。ポーリングしてリトライする必要があり、そこは作り込んだ
    • ファイル名に気をつけろ。似たような名前にすると、全て同じパーティションに入ってしまうので、アクセス（検索）効率が悪い。なので、元々のファイル名の頭に、ハッシュ値を付けても良いかもね。
SQS
  • キューサービス
  • 良さ
    • スケーラブル
  • 気をつけるポイント
    • 実行は保証（実行せずに勝手に動くことはない）されるが、複数回動くことがある。必ず冪等性を確保し、複数回動いても良いようにする。
    • 順番も保証されないので、結果整合性となるように設計する。どうしても順番を守りたい場合は、FIFOオプションを使う。（高いけど）
  • Pub Sub
    • 「何も考えずにFanoutパターンで作ろうぜ」という文化ができているので、機能追加がしやすい f:id:ketancho_jp:20180310162901j:plain:w500
Lambda
  • アプリケーションコードを実行サービス
  • 気をつけるポイント
    • MAX5分しか動かないので、処理できる分だけデータを取るなどの工夫をしている
    • アップロードできるソースに容量制限がある。Pandas が結構重いので、他のライブラリが入らない。これは今でも解決してないとのこと。
DynamoDB
  • NoSQLサービス
    • RDSではコネプーの問題もあり、並列処理と相性が悪い。特にLambdaとの相性。今はDynamoDB一択。
  • 気をつけるポイント
    • 書き込みキャパシティユニットの設定によっては、Lambda の一部が書き込み待ちになる。その場合、5分制限に引っかかることがある。
    • 書き込みキャパを上げることで解決できるが、金がかかる。また、全ての処理を一気に終わらす、というのは DynamoDB の理念に反するはず？
    • Lambda の同時実行数を定義して、待ってしまう Lambda を減らすことで対応した。

開発手法

  • Cloud9
    • ローカルで開発すると、PCのスペック的にサクサク開発できなかった。そんな時に Cloud9 が出てきたので利用中。
  • GitHub
    • 1サービス1AWSアカウントという管理方針なので、CodeCommit は使わなかった。
    • PR 開発してるよ
  • CircleCI + CFn
    • CFn では Lambda 同時実行数はまだ未対応なので注意。その部分だけ CLI を使っている。

開発チームの感想

  • アプリチーム：最初は辛かった（2倍時間がかかった）が、いまはいい感じ（0.8倍くらいになった）。
    • 「制約があるから迷わない」のがいい
    • 優秀な先生がコミュニティなどにいっぱいいる。会話することでモチベーションも上がる。

作られたシステムの出来は？

  • インフラ：70点 → 90点
    • たまにサービスが落ちる？（EC2の話かな？）
    • これは設計で回避しないといけない世界だと思ってる。
  • アプリ：70点 → 90点
    • クラウドのメリットを簡単に＆大きく享受できた。

個人的な感想

  • 「何も考えずにFanoutパターンで作ろうぜ」という文化が非常によいと感じました。自分も設計するときそうしよう。
  • 「制約があるから迷わない」という意外な利点があるなーと思った。サーバレス化すると、自然にステートレスな設計にせざるをえなくなるし、副次的な効果が大きいと感じました。

15:00-15:50 実践Serverless x Microservices #jd2018_d

なぜマイクロサービスなのか

マイクロサービス化するために

　下記のポイントを意識しているとのこと。 f:id:ketancho_jp:20180310180638j:plain:w500

サービス分割
データの分離
  • データは各サービスごとに持つ
    • そうしないとデータ構造が変わると、サービス間で引きづられる
    • 各サービスを持っているチームが、好きな機能を、好きなタイミングでデプロイできるようにする、がモットーなのでこれは必須と考えている。
    • データの不整合の許容範囲（時間）を合意する
  • メッセージングの仕組みを使う
    • Kinesis, SQS, SNS
    • Pub/Sub によって表現する
トレーサビリティ
  • サービス間の追跡性が非常に重要
    • リクエストやサービス間通信にIDを発行する
    • 各サービスはログを吐く
    • ログからアラーム／オートスケール
レジリエンス（回復力）
  • 障害が起きたら、自ら復旧する
  • 一つのサービスの障害が全体に波及しないように設計する
  • 可用性／柔軟性に繋がる
  • サーキットブレーカー：障害の伝搬を阻止する
無停止デプロイ
  • マイクロサービスにすると、デプロイ量が多くなる
  • コードがサービスインするまでの一覧を自動化
  • 数多くのマイクロサービス全体を作るのが辛い
  • BGデプロイ、カナリアリリース
  • インテリジェントルーター、自分の居場所は自分で登録
テスト戦略
  • サービス内テスト
    • モックを使ったユニットテスト
  • サービス間テスト
    • 他サービスとの連携
  • レジリエンステスト（障害を起こすテスト？避難訓練）
    • 障害発見ではなく、障害が起こったら何をするか

AWS の各サービスのくせの話

Kinesis
  • ストリーミングサービス
  • Kinesis と SQS の使い分けf:id:ketancho_jp:20180310164629j:plain:w500
  • Kinesis Stream x Lambda
    • getRecord の成功率が下がり、遅延に繋がった。
    • 制約を考えると、後ろには3つくらいのLambda しかつけられないが32個ぶら下げていた。
Step Functions
  • Kinesis -> Lambda -> StepFunctions -> Lambda(s) という構成に変更した。
  • Lambda が ホットスタンバイかどうかで実行タイミングがかわり、順序性が崩壊した。
    • DynamoDB によって Step Functions の状態を管理した
  • まれに Lambda 呼び出しが失敗することがあって辛い。Step Functions を叩くスクリプトを用意して、タイムアウト管理した。
X-Ray
  • Kinesis の前と後で、枝葉が変わって見えてしまう
  • X-Ray はやめて、処理フローにIDを採番して、CWLogs で見る方式に変えた
DynamoDB
  • スパイクに対するオートスケール間に合わない問題がある
ElasticSearchService
  • メモリプレッシャー機能によって、メモリが80-90%に到達すると Full GC が走ると Lambda から 数ms, 数s接続できない
  • Lambda 側にリトライ処理を書く必要がある

便利ツール

  • sbt-aws-serverless
  • S3の中身、CWLogs を全部消すツール
  • DynamoDB の差分バックアップツール

QA

サーバレスのソース管理
  • リポジトリはドメインコンテキスト（関心事）単位で切ってる
  • リポジトリの一部のみをデプロイできるような仕組みを作っている
ローカル開発

下記の流れで進めている。 * ローカルのテストはAWSのサービスは全てモック化している。LocalStack なども使ってる。 * モック化している部分のテストは、AWSに上げてやる。 * S3 のイベントドリブンテストは、ローカルにファイルをおいてそれを返すようにしている

Lambda - RDS 問題
  • 時間を許容できるサービスは RDS を使っている
    • その場合は、RDS が受け付けられるコネクション数も意識する
  • そうでない場合は、DynamoDB を使う
Lambda の JVM 問題
  • 依存ライブラリを削って容量制限に引っかからないようにした
  • コールドスタート時間がかかる問題は、それを許容するように設計するしかない
REST API によってサービス間を繋げる場合に後方互換性をどうしているか

他のAPIを呼ぶということは、他のチームのAPIを呼ぶということ * 仕様変更に合わせて変える * パスを切る という選択肢があるが、前者の方法をとっている。つまり、チーム間の合意に基づいて仕様変更している。ここは密結合になってしまっているので、どうにかしたいと思っている。

参考）構成図

f:id:ketancho_jp:20180310180733j:plain:w500

感想

  • こちらのセッションでも Pub Sub な設計について触れられていました。
  • マイクロサービス本、DDD本の紹介があったので読んでみたい。
  • 「Step Functions の状態管理のために DynamoDB」のくだりはつらみを感じました。

雑感

　下の記事にも書きましたが、JAWS DAYS は知識を得るという意味ではもちろんですが、すごい人たちの話を聞くことでかなりモチベーションが上げられるイベントだと思います。AWS界隈で有名な方々のお話が聞けるのは本当に楽しいです。おすすめです。

www.ketancho.net

　こんなに大きなイベントでは怖くて無理ですが、私も今年は勉強会でスピーカーをやってみたいなーと改めて思いました。いいイベントないか探してみたいと思います。

　スピーカー＆運営の方々、お疲れ様でした！ありがとうございました！