BtoB のSaaS プロダクトを提供する ログラスでのクラウドインフラの立ち上げと関わり方 / How we built Cloud Infra Team in Loglass

Transcript

1. 1 ©2023 Loglass Inc. BtoB のSaaS プロダクトを提供する ログラスでのクラウドインフラの立ち上げと関 わり方 2023/08/29 勝丸 真
2. 2 ©2023 Loglass Inc. 自己紹介 ・勝丸 真（かつまる しん） @shin1988 ・2020年5月 Loglass入社（副業自体は2019年の途中から） ・ログラスの1人目フルタイム正社員 （CTO坂本がいるのでエンジニアとしては 2人目） ・AWS周りの管理者をやっていた経験が長い ・坂本とは新卒同期で、副業で関わりつつ、転職を考えた時に誘われ る形でJOIN ・入社後はインフラ、バックエンド、フロント ...何でも屋 ・現在はエンジニアリングマネージャーをしています
3. 3 ©2023 Loglass Inc. BtoB のSaaS プロダクトを提供する ログラスでのクラウドインフラの立ち上げと関 わり方
4. 4 ©2023 Loglass Inc. プロダクトのサービス価値を 最短で顧客に届けるには？
5. 5 ©2023 Loglass Inc. サービス立ち上げ時の状況 ・当時の状況は、サービス本番リリース前。もちろん売上は 0。 ・毎月バーンレートを気にしている状態（たしか Runwayが10ヶ月とか） ・エンジニアがCTO坂本と2名体制で、自分がインフラ専任になるとそれだけで、機能開発の出力が半分になる ・ある程度開発に集中できるようなインフラを 最初に構築しきるということを考えていた ・自分がインフラエンジニアをやるとサービスが死ぬと思っていた
6. 6 ©2023 Loglass Inc. リリース初期は機能開発の方が重要度が圧倒的に大きい 機能開発 運用 自分はこれをやりたい！は二の次。まずは売上を立てることこそが最重要事項！！
7. 7 ©2023 Loglass Inc. あればいいはなくても良い https://twitter.com/Fukahire109/status/1337012555449917448
8. 8 ©2023 Loglass Inc. 本番リリースを最優先させるという状況で考えていたことは 3つ 初期インフラの設計思想 1 放っておけるインフラ • EC2は極力使わない方針でECS（Fargate）を選択 • DBはAurora PostgreSQLを選択 シンプルかつ壊しやすい 2 最低限のセキュアさ 3 • Terraform でインフラをコード化 • Kubernetes は不採用 • CI / CDを初期リリース時から作った • AWS環境を分けてサービスイン • 監査がし易い様に色んなログを1つのバケットに入れる設計に • DBのパスワードなどは全部SSMへ
9. 9 ©2023 Loglass Inc. 放っておけるインフラ 初期インフラの設計思想 ・ECS（Fargate）を選択し、仮にコンテナが落ちても復帰するように ・EC2の退役やImageの管理で苦労した経験から。 ・DBはAurora PostgreSQLを選択 ・PostgreSQL自体はCTO坂本の決定。運用観点から Aurora一択。 ・PostgreSQLの運用自体はしたことがなく、 MySQLの経験しか無かった。 ・データの持ち方は、本当にこれが最適なんだろうか？は考えたが、本番カットオーバー前から考えることで はないと思った。データの持ち方で死ぬより、売上が立たなくて死ぬ可能性の方が高い。
10. 10 ©2023 Loglass Inc. シンプルかつ壊しやすいインフラ 初期インフラの設計思想 ・初期のインフラはすべて Tarraform化 ・放っておくスタンスだが、もし人が増えた時にわかりやすいように ・依存する方向を考えて、壊しやすいように作った ・Kubernetesは不採用 ・自分に本番で運用経験が無かったため（イチ個人としてはやりたかった） ・将来的にも絶対に必要になるという感覚は自分には無かった ・CI / CDはAWS Codepipeline （CodeBuild / CodeDeploy） ・特定ブランチがマージされたらそれぞれの環境へデプロイされ、通知される ・DatadogのMonitorなどもTerraform化していたが、こちらは割に合わないと思って辞めてしまった ・監視追加するのにTerraformを覚える必要があるは本末転倒
11. 11 ©2023 Loglass Inc. 最低限セキュアなインフラに 初期インフラの設計思想 ・AWS環境を分けてサービスイン ・過去の経験から環境を分けたくなることはわかっていたので分けた ・ログを1つのバケットに放り込む設計に ・サブディレクトリを切る形ですべて 1つのバケットに ・DBのパスワードなどは全部 SSMへ ・創業当初は副業的に関わってくれるメンバーも多かったので、コードにベタで書かない ・意外と後々まで残りそうだなと思った
12. 12 ©2023 Loglass Inc. 一方で放っておいてはいけないこと ...
13. 13 ©2023 Loglass Inc. まとめ ・事業フェーズで得たいROIを考えよう ・運用は一人ではできないので、チーム化を考えた作りにしよう ・「サービス価値にコミット」は事業フェーズで全然違うので、自分の責務なんなのかを考えよう
14. 14 ©2023 Loglass Inc. 段々と運用業務も大事なフェーズへ 機能開発 運用 運用 この後の原の発表では、運用の重要性が上がりつつあつ直近 1年の話をします