AWS DevDayに、弊社SREエンジニアの山北が登壇するという噂を聞きつけ、行ってきました！
当日は、ライブ中継も行なってましたが、
やはり生で参加して聞く方が印象に残りますよね！
そもそもAWS DevDayって？
AWS DevDayは名前の通り、AWSが主催しているテクニカルカンファレンスで年に1回行われています。今回は10/3-10/4 の2日間にわたって行われました。
去年より会場が広くなり、ホールは3つに分かれ、講演が開かれていました。
AWSのサービスは年が追うごとにどんどんサービスが増えているのでこういったタイミングで、情報収集を一気にするいい機会ですね。
場所は、まさかの神田明神。
神社併設のホール内でイベントが行われていました。
初めて神田明神に足を運びましたが、綺麗かつ壮麗な雰囲気で、ITと神社というミスマッチさが、いい意味で面白かったです。
いやー綺麗ですね..!
もちろん帰り際に、お参りして来ました。笑
さて、気を取り直して、弊社SREエンジニアの山北が登壇するセッションに移りましょう。
弊社SREエンジニアの山北、登場。
2日目の最初のセッションで、弊社SREエンジニアの山北が発表すると聞いた我々は、ソワソワしながら待機。
(登壇する山北よりDevDayに浮かれた私がソワソワしているのは内緒)
講演内容はマイクロサービスを支えるインフラアーキテクチャ。
朝一にもかかわらず、会場には多くの人が…!
それもそのはず、今回発表するタイトルが
「マイクロサービスを支えるインフラアーキテクチャ」
レガシーな環境を、マイクロサービスへと移行する方法・ナレッジの共有など興味深い内容っ…!!
自然と会場の熱も上がります。
そして、ついに、登壇っ…!
Agenda マイクロサービスの移行から応用事例まで
登壇時間は45分。
pring(プリン)というサービスが、モノリシックからマイクロサービスへ移行した話と、そこから得たナレッジを他の自社サービスへ展開して行った応用事例。
そして、今後のロードマップについて話してくれました。
ここからは、スライドの内容を抜粋して紹介するため、
全てのスライドが見たい！という方は、
こちらからどうぞ
pringのマイクロサービスへの移行
pringは個人間の送受信を可能にするFintech系のサービスです。
2年前の2017年時点での技術構成としては以下の構成。
- 一般的なAWS構成（EC2,ElastiCache,RDS）
- 監視は、Mackerel
- バックエンドは、PHP/非同期はNode.js
しかし、このままでは急拡大を続けるサービスに耐えれないインフラ設計になっていることが発覚。
このタイミングでスケールのしやすさなどから、マイクロサービス化を進めることを決意。
AWSのアカウントレベルから見直し、
アプリケーションも開発言語から再選定をしていきました。
とはいえ、マイクロサービスにどうやって移行していこう…？
マイクロサービスに移行するといっても、何から始めるべきか悩みますよね？
移行作業を分解すると
1.現状把握
2.アーキテクチャの再設計
3.データベースの再設計
4.インフラの再設計
5.アプリケーションの再設計
という5段階に分けられます。
現状把握で抑えるべきポイント
現状把握で抑えるべきポイントは
具体的にインフラは
- Autoscaleに対応しているか
- PublicとPrivateのサブネットが分離されているか
- バケットの非公開の対策
- アクセスログを一元化しているか
- アラートをエスカレーションする機能があるか
アプリケーションでは
- インフラをスケールした際に、バッチがエラーを起こさないか
- コードレビューやテストカバレッジ
- Gitの運用やデプロイは誰でも簡単に行えるか
などをチェックしていきましょう。
すごく重要なことだらけですね。基本的なことですが抑えていきましょう。
推奨設計かどうかは、AWS Well-Architectedのチェックリストが便利
先ほど、AWSが推奨する設計になっているか確認するのに役に立つのがAWS Well-Architectedです。
これはAWSのベストプラクティス集で
- データのアクセスパターン（インデックスや水平スケーリング）
- 疎結合なアーキテクチャーで、ワークフローやELBが設定されているか
- ネットワークの構成管理ツールなどを管理、自動化するTerraformなどを採用しているか
などのチェックリストに、基づき推奨する設計を確認できます。
使わない手はありませんね。
Beyond the Twelve Factor Appで、ネイティブアプリのベストプラクティスを。
ネイティブアプリのためのベストプラクティス集として、Twelve-Factor Appというのもある。
これ自体は少し古いのだが、アップデート版であるBeyond the Twelve-Factor Appも出ているので、こちらをオススメします。
特定の言語やインフラに依存せずに適用することができるため、一読の価値ありですね。
Terraformでインフラのコード管理は苦労したが、メリット大
AWS Well-Architectedのルールに則った設計は苦労したところだが、メリットは大きく、やるべきだと強く押していました。
実際に設計から運用まで行い感じたメリットは
- リソースの変更をIssueベースで管理することでレビュー体制を整えることができた
- AWS Configと組み合わせることで、リソースの変更履歴の自動追跡も可能
という点です。
認証基盤はCognitoへ移行
Cognitoを採用し、認証基盤を外部化することで、ビジネスロジックの実装にフォーカス可能に。
移行方法としては、Amplifyを介してCognitoにアクセスし、RDSと通信。
アカウントがあれば、JWTを返すなどして実装。
将来的には、RDBとLambdaのやり取りは、なくす予定と熱を込めて話す山北。
ECSのクラスタ設計
メタップスは、2016年という割と初期からECSを本番環境で運用しECSの上で動いているサービスは、200を超えるらしい...!
(し、知らなかった...)
そこで培ったクラスタ構成がこちら。
サイドカーとしてDatadogsが動いており、アプリケーションの各種ログはログクラスタへ集約。
Fluendで整形したログをElasticsearchやS3に配送し、必要に応じてアラートはSlackに通知、ログの可視化にはKibanaを採用。
ログを一元管理し、システムが増えたとしても、ログを管理しやすくしています。
OSSデプロイツール「genova」
今回のAWS DevDayでも多くの講演やノウハウがあった項目として、デプロイ関連があります。
どうしてもAWS以外のサービスを組み込むと、デプロイ方法が複雑になりがちです。
誰でも簡単に。Slackからでもデプロイできる仕組みを。
そんな機能を持たせたOSSツールを、開発しました。
- タスクスケジュールでのデプロイ
- CLIデプロイ
- Slackを用いた対話形式のデプロイ（これが便利！）
（これを使えばスマホからデプロイも余裕です！）
正直、めちゃ便利なので、デプロイまわりで苦しんでいる人は、一度試してみてください。
https://github.com/metaps/genova
構築したインフラの応用事例
pringというサービスをマイクロサービス化する過程で、練りに練られ、コード管理化までされたインフラを、他のサービスにも展開していきました。
展開したサービスはこちら。
インフラをコード管理したことで、
- インフラ構築コストの削減
- コード共有に伴う技術共有
- 全社的なインフラスキルの向上
などのメリットがあり、導入は正解だったと山北。
登壇お疲れ様でした！
〜【後日談】AWS DevDay 2019 裏話〜
登壇後の山北に裏話を聞いてきました！
おつかれさまです！なにか質問されているようでしたが...？
(山北) Cognitoを用いた認証周りの質問は多かったですね。やはり、認証周りは外だししてビジネスロジックに集中したいという企業が多いからだと思います。
一番苦労されたのは？やはりインフラのコード化ですか？
(山北) そうですね。 Teraformは社内でも知見が少なかったこともあり、そこそこ時間を要しました。OSSのgenovaは、マイクロサービスに移行する以前から開発しており、デプロイ周りの構築にはそこまで時間をかけずに済みました。。
発表された後、反響はありましたか？
(山北) SNSだけでなく、ブログなどで「参考になった」「実践してみる」などの声を数多くいただき、また社内でも、これをきっかけに「このインフラも構築してほしい」といった要望も受ける機会が増えました。
社内でインフラに関するナレッジの共有や、コミュニケーションの活発化などが進むなど非常に良い影響が生まれたので良かったと思います。
本当にお疲れ様でした。
最後に
自動デプロイツールgenovaはこちら
https://github.com/metaps/genova
【スライド】マイクロサービスを支えるインフラアーキテクチャ
マイクロサービスを支えるインフラアーキテクチャ/microservice-infra-architecture - Speaker Deck
