はじめに
こんにちは。
大学3年生の時に、スタートアップの会社で1年弱CTOをしていました。
その会社では、マイクロサービスアーキテクチャを採用し、Kubernetesクラスタ上で運用していたので、その際に感じた課題感と対応策についてこちらに記述します。
開発したプロダクト
災害時対応のためのSaaSを開発していました。
このプロダクトの機能要件の作成やペルソナとユースケースの作成の段階から全て担当していました。
なぜマイクロサービスアーキテクチャなのか。
一般的には、スタートアップでマイクロサービスアーキテクチャを構築することってまずないと思います。
インフラ構築、運用の工数と難易度が爆発的に上がりますし、
DBが分離する事によって、依存関係を適切に切り分けないとサービスが機能しなくなるため、アプリケーションの設計の難易度も格段に上がります。
その中でマイクロサービスアーキテクチャを選定した理由は以下の2つです。
一つ目は、マイクロサービスアーキテクチャは組織のための技術であるということです。
僕の作りたい組織は、全員がリーダーシップを発揮する組織です。
トップダウンだけでなく、一人ひとりの意思が積み重なって総意になり、ボトムアップの意思決定が最終的に大規模なアプリケーションの品質を高めていくというような状態が理想だと考えています。
また、自分の所属しているマイクロサービスに対しては、オーナーシップを持って、自分で考えて意思決定して欲しい。
人は意思決定の数だけ成長すると考えているので、そうすることで、人が成長できる組織にできると考えられます。
一人一人のエンジニアが考えるべき影響範囲を極限まで減らすことで、チームとして内部実装へのknowledgeがたまりやすく、それぞれがオーナーシップを持てるような環境になるので、チームとしても個人としてもとてもいい影響があります。
そのような観点から、マイクロサービスアーキテクチャの採用に踏み切りました。
二つ目は、影響範囲を切り分け、信頼性を保つことです。
自然言語処理の機械学習モデルや、大量のニュースを処理するニュースページは、負荷が大きくこちらのインフラ要件を満たせなかったり、アプリケーションエラーが起きてしまったりすることで、メインサービスであるダッシュボードの機能まで落ちてしまうことを嫌ったため、マイクロサービス化する重要性が高くなりました。
また、アプリケーションレイヤーの更新は頻繁に起こるため、プログラムエラーによるダウンタイムがBCP機能に影響しないようにしたかったという意図もあります。
備蓄品管理やスケジュール管理などは数時間のダウンタイムがさほど大きな影響ではないのに対し、BCP機能は災害時にどうしても動作していてほしいプログラムです。
これが最大の理由です。
マイクロサービスの自由で許容していることいないこと
採用するアーキテクチャやライブラリは同一サービス内で統一されていればいいものとしています。
新しいマイクロサービスを作成する時に、過去のマイクロサービスよりも、より先進的なライブラリを用いて、フレキシブルかつスケーラブルな構成にしていこうという取り組みは、技術者を成長させていく上で欠かせません。
逆に規模の小さなサービスにクリーンアーキテクチャを当てはめるのは大げさになる可能性もあります。
なので、使用するアーキテクチャやライブラリはサービスごとに異なります。
しかし、言語選定レベルの自由は許容していません。
小さい会社でメンバーの入れ替わりが激しいので、長期的に見れば、別のマイクロサービスを開発する可能性が非常に高いからです。
その時に、Go言語とRustが混ざっていると、Go言語のエンジニアとRustのエンジニアは互いに交われないことになりますし、
社内で作成している静的解析ツールやメモリマネジメント、プロファイリングの知見が共有できなくなります。
ほとんどのマイクロサービスで、Go言語で統一しています。
例外的に、データ分析などではPythonが用いられていますし、簡単なスクリプトはRubyやPythonで書くことを許容しています。
マイクロサービスの運用での課題点
- サービスごとの境界線の定義、ドメインモデリング
- サービス間ネットワーキング
- DBの分離による一貫性と冪等性
- SLI/SLOとError Budget
- Observability
- Testability(unit testとE2E testとサービス結合テスト)
- CI/CDパイプライン(CIとCDの分離、GitOps)
- 機械学習の導入
これらの定義や運用には難しさを感じました。
mercariやYahoo!などのマイクロサービスを使っている会社について調べることで多くの課題を解決することができました。
一般的なマイクロサービス の解決策(Kubernetes, Saga, イベント駆動通信)を用いたので、そういった方法論で多くの課題は解決できます。
逆に、得られた成果は非常に大きかったです。
10人以上の開発組織でしたが、全員が自分の所属しているマイクロサービスについて深い理解を持ち、オーナーシップを発揮している組織にすることができました。
各マイクロサービスについて星の名前を割り振っていましたが、「その星に愛着が湧く」といっていたメンバーに他のメンバーも共感していたのが印象的でした。
そのくらい、オーナーシップを発揮できる環境を作ることができたのは、マイクロサービスアーキテクチャの導入も１つあったと思います。
皆さんも、スタートアップ企業でマイクロサービスアーキテクチャを導入してみてはいかがでしょうか！？