トレタ Advent Calendar 2020 の 12 日目の記事です。
こんにちは、wind-up-bird です。
2020年のアドベントカレンダー3回目の登場です。
今回は割と肩の力を抜いて書いてみます。（なので、主観とかが多分に含まれます）
ところで、トレタに入社して約2年が経ちました。
入社した当時と比べると、SREチームで使っているツールや AWS のサービスも大きく変わってきました。今回はこの2年間で導入したものや変更点などをいくつかピックアップして紹介しようと思います。（ピックアップの基準も完全に主観。）
Kubernetes の導入と集約
トレタで最初に k8s を導入したのは トレタ Now です。*1 ネイティブアプリのバックエンドとして当時は GKE 上で稼働していました。
その後、他のサービスでも k8s (EKS) の導入が始まり、このときはサービス毎に EKS クラスターを起動していました。クラスターを分割していた理由は、クラスター毎に環境が分離されており自由度が高かったこと、また問題が発生した場合は各クラスター内で影響範囲が閉じていること、というところが理由です。
しかし、これによってとても小さなサービスでもクラスターが作成されていき、乱立してしまう状態となってしまいました。これは費用対効果の面で疑問が出てきました。また、各サービスごとにクラスターのアップグレードも必要になるため、運用負荷も無視できなくなっていきました。
そこで、これは 1つのEKSクラスターにまとめて、各サービスは Namespace で分割する仕組みに変更しました。現在は、6個のサービスが EKS上で稼働しています。
ECS の採用
アドベントカレンダー3日目のブログでも書きましたが、トレタの顧客台帳・予約台帳サービスのバックエンドは ECS を採用しました。
脊髄反射的に EKS 上にホストしたかった気持ちをぐっとこらえて、移行対象のサービス特性や Pros/Cons を検討した結果、最終的には ECS に決めました。
従って、現在トレタでは EKS、ECS 両方運用しています。今後も、サービスの特徴や課題によって、どちらの基盤を採用するか都度検討して行こうと思っています。
ちなみに、今はEKSもECSもどちらも同じくらい好きです。
サーバーレス
いくつかのサービスでは、 Serverless Framework を導入しています。
ウェブ版 トレタ Now
今日、これから入れる飲食店が予約できる | Toreta now
トレタCC
トレタCCにAmazonConnectを導入した話 - トレタ開発者ブログ
導入の背景は、デプロイやログの確認が容易であったり、プラグインの充実、学習コストなどの面でメリットが大きいのかなと思います。これらのサービスはフロントエンドエンジニアが主体となって継続的に開発・デプロイを行っています。
それ以外にも lambroll や AWS SAM なども目的や用途に応じて積極的に検証・導入していってます。
AWS Organizations と SSO の導入
これに関しては、もうブログを読んで頂くのが一番早いです。
記事の中にもある通り、以前は各AWSアカウントで IAMユーザの払い出しや、EC2へのSSH鍵の配布などの運用業務が発生していました。しかし、 現在では SSO による一元管理、SSM Sessions Manager の導入など、セキュリティや管理・運用面でも劇的に改善しています。
ちなみに、最近では WebAuthN にも対応しており、自分も Mac の Touch ID をMFAとして利用しています。
IAM のコード管理とレビュー体制の確立
これはどちらかというと技術というより思想の話になるかもしれません。
入社当時は、Terraform は導入していたものの IAM はAWSコンソールからポチポチと設定する運用になっていました。この問題点は、強力な権限を持った IAMロール や IAMユーザ が生み出されてしまうリスクがあり、IAMのベストプラクティスからも外れてしまいます。
そこで、IAM はコード管理しつつ、レビューおよびCI/CDの仕組みを導入しました（導入してもらいました）。ツールは Miam を利用しています。
自分も予想していなかったのですが導入後の効果はとても大きくて、今ではすべてのサービスや案件において、真っ先に IAMどうするか？をチーム内で議論するようになりました。
もう少し具体的に説明すると、例えば最小権限を設定したい場合、
- AWS のリソースは何が必要か？
- AWSのリソース間はどのように連携するのか？
- 作成するリソース名は何か？（言い換えると、そのリソースは何をするものか？）
etc…
というのをきちんと理解しておかないと、Action/Resource/Principal などが適切に設定できないためです。
ということで AWSの設計はIAMありき というのが今のSREチームの共通認識となっています。（多分）
最後に
ということで、4つほど紹介してみました。
ここで紹介しきれなかったものもまだまだありますが、それはまた別の機会ということで。
最後の最後に、おなじみのやつです。
*1:正確には、内部的な利用はあったのですが、プロダクトの基盤として使われたのはこれが初めて。
