はじめに

ちょうどピンポイントでためになりそうなセッションがあったので、
お休みを頂いてAWS Dev Day Tokyo 2019に行ってきました。

会場は神田明神ホールです。
初めて行ったんですが、完全に神田明神の中にあるんですね。
えっ、この門の中にAWSの札持ってる人いるんだけど…とびっくりしました。

帰り際に撮った写真なのですが、ちょうどランチセッション前の移動中だったので人がたくさん！
男性ばっかりだった…かな…。（笑）



セッション

G-1 マイクロサービスを支えるインフラアーキテクチャ（株式会社メタップス　山北 尚道 氏）

  1. 事例紹介 pring
  2. 構成管理の応用事例
  3. 今後のロードマップ

pringというQR決済サービスを支えるアーキテクチャ

ASIS TOBE
アーキテクチャ EC2 + RDS + ElastiCache APW Gateway + Fargate Lambda
バック PHP + Node.js Ruby on Rails + OpenAPI + Trailblazer
ネイティブ Cordova + Kotlin Cordova + Kotlin
外部サービス Firebase Cloud Messaging + Twilio Firebase Cloud Messaging + Twilio
認証 ？ Cognito
プッシュ ？ DynamoDB

なぜマイクロサービス化に至ったのか

  • エンジニアの人数不足
  • スケールが困難

移行TODO

  1. 現状のシステム構成分析
  2. アーキテクチャの再設計
  3. データベースの再設計
  4. インフラの再設計
  5. メッセージ基盤

1. 現状のシステム構成分析

インフラ

  • トラフィック増加に伴うスケーリング方針が定義されているか？
  • AWSが推奨する運用設計がされているか？
  • インフラ構成を安全に変更できる管理体制となっているか？
  • データ分析のための基盤が整備されているか？
  • リソース監視が適切に行われているか？
  • 情報セキュリティマネジメント

アプリケーション

  • AWSに適したアーキテクチャが採用されているか？（e.g. 非同期処理をどうしているか？）
  • DRYの原則が守られているか？
  • アプリケーションはスケールしやすい構成か？
  • SQLアンチパターンの検証
  • コードレビューやテストのポリシー
  • Gitの運用

2. アーキテクチャの再設計

Well-Architected

Twelve-Factor App

  • 特定のプログラミング言語やインフラに依存せず適用することができる
  • Beyond the Twelve Factor App

SAP Strangler Application Pattern

  • Martin Fowlerが提唱
  • 一度にリプレースすることは困難なので、少しずつレガシーコードを破棄する
  • v1のAPIとv2のAPIが同時に存在する

3. データベースの再設計

  • データベースの分離はテーブル数から断念
  • 完全にインフラの移行が終わったら分離を計画
  • 新規追加する機能は分離

4. インフラの再設計

  • Terraformを利用（GitHub/Datadogで使うためCloudFormationでは都合が悪い）
  • 利用サービス：APIGW DynamoDB ECS Cognito
    • AWSのコンソールを操作して設定変更することはほぼない
  • 開発言語：PHP→Ruby on rails Trailblazer
    • OpenAPIを使い、スケーラビリティや外部公開を視野に入れた
  • 認証基盤：アプリも管理画面もCognitoに
    • Amplifyを使用
    • Cognitoの中にユーザがいない場合はLambdaを使ってRDSに聞きに行く（移行完了したら不要になる処理）
    • API GatewayでLambda Authorizerを使っている

5. メッセージ基盤

  • ECSで動く
  • DynamoDBにメッセージを保存
  • RDSに送金トランザクションを保存
  • ElastiCacheにルーム状態のキャッシュを保存

ECSの運用

稼動システム数：26
クラスタ：50（Web/API/Batch→Datadogで監視　Log→fluentdでS3に転送し、Elasticsearch/Kibanaを利用）
サービス：約200

デプロイ

  • 内製で開発（genova）

セキュリティ

  • 人為的ミスの防止
  • 攻撃に対するリソースの保護
  • イベント監視Lambdaで分析し、重要度の高いイベントはSlackに通知
  • 監視ツールはServerless Framework

3. 今後のロードマップ

ESC Engineer Steering Committee

組織的なエンジニアリングの最適化を目的とし、全社的な運用方針の決定を行っていく組織。
エンジニアの働きやすい環境づくり、エンジニアの成長サイクルを考えていきたい。



G-2 サーバーレスで作るモバイルアプリ向け Backend For Frontend（株式会社 Timers　椎名 アマド 氏）

組織やプロダクトの構造

  • 家族アプリFamm
  • カンバン（Agile）を採用

課題

  1. サーバーAPI複雑化
  2. Android/iOSで複雑なAPIを扱うビジネスロジックの分散

思いの違い

サーバ側 アプリ側
RESTAPIを作りたい UIにあったAPIがほしい
1リソースに1APIにしたい 1画面で1APIコールで済ませたい
  • iOS/Androidの両方でAPIから取得したデータを使ったビジネスロジックを分散したくない
  • ステータスに応じた文言の出し分けが多いが、クライアントの責務になっていた
  • コミュニケーションによる調整コストが増加
  • 複数OSや複数バージョンの影響範囲を考慮しながら巨大APIをメンテするのはしんどい

対策案①：品質管理の徹底

  • 自動テストの網羅によりデグレを防ぐ
  • API修正のたびに過去バージョンも考慮した手動テストを行う

→生産性を考えるとスマートな解ではない

対策案②：Kotlin/NativeなどでiOS/Androidともに利用できるビジネスロジックをライブラリ化

  • まとめられる
  • 整理が必要なことが多い（社内に有識者がいない状態だった）
    • 技術調査コスト
    • 共通ライブラリ修正時のCIフローの検討

→一部で有効かもしれないが、コストが高い割に完全に幸せにはならない

対策案③：APIに表示ロジックを寄せる

  • 文字列だけを返す
  • 必要な整形を済ませる
  • ビジネスロジックコードの大幅削減
  • サーバAPIでテストを充実させていれば品質担保も可能

→方向性は悪くないが、片方の課題（2. Android/iOSで複雑なAPIを扱うビジネスロジックの分散）しか解決できていない

対策案④：BFF

BFFとは

「One backend per user experience」
1つのユーザー体験に密結合なバックエンド

決めたこと

  • クライアントエンジニアが管理する
    • 責務の分離：クライアントごとの出し分けや調整をサーバサイドがやるのはキツい
    • 集約と変換：通信を減らす
  • iOSとAndroidで同じBFFを共有　※異なるユーザー体験を提供するアプリであれば別にするのが良いかも
  • サーバレスで実現する（クライアントエンジニアが管理するので簡易化したい）
  • サーバレスで実現するための環境整備はサーバサイドエンジニアが担当する

言語

TypeScript
※他のLambdaはGoで書かれていたが、クライアントエンジニアのスキルに寄せた

環境

  • EC2(PHP) – ELB – Lambda(Node.js/Experss) – APIGW -iOS/Android
  • Lambda(TypeScript/Express) +
  • API endpointは1つ
  • Lambdaのアプリケーションは1つ

※もっと複雑なアプリケーションになるなら、複数持つ案も考えたほうが良いかも

認可と認証

  • BFF用のAPIキーとBackendAPI用のTokenを両方ともクライアントサイドから渡している
    →いまはほとんどマイクロサービスがないから問題ないが、いずれ見直しが必要

i18n(internationalization)

i18n npmモジュールで対応

テスト

  • Jest
  • develop/masterにマージされたらCircleCI経由でそれぞれデプロイが走る
  • servelessCLIのdeployコマンドがあるのでCIも簡単に構築

今後やりたいこと

  • BFFが複数マイクロサービスと通信できるような設計（認証認可）
  • BFFは一度インターネットに出てからBackAPIと通信しているが、VPC内で通信完結させて速度の最適化を図りたい
  • 他にもBFF移行したい（今移行できているのは一部）

導入にあたって大切なこと

  • チームやプロダクトの課題は何なのかを考え、それを解決するソリューションを考える。
  • モダンだから、トレンドだからで入れてはいけない。失敗する。
  • 課題ドリブンで思考し、導入すること。



終わりに

AWS Summitは盛り盛りで参加したのですが、今回は2セッション（企業セッションのみ）にしてみました。
AWSセッションとは異なり、AWS導入にあたっての考慮点や進め方にフォーカスが当たっていて、
「AWS（のxx）を使ってみたいけど、どうやって始めれば？」と悩む人向けだと感じました。
インフラエンジニア的には物足りないと思いますが、
アプリエンジニアや（まだAWSを導入していない／導入途中の）アーキテクトにはためになる内容でした。

個人的にはもっと、BFFを導入したあとの話（困ったことがあったか、改修したか等）があると助かったなあと思います。
でも、ServerlessFrameworkの導入は検討してみようかな。

帰りにしっかりアンケートに答えて、「IT情報安全祈願」をもらってきました！（笑）

スポンサーリンク