マイクロサービスは、個別に開発された小さなサービスを組み合わせて、一つのサービスを提供するというものです。

約1年前から新規事業のアイデア出しをやり始め、その後「https://zoto.gift」というソーシャルギフトサービスをリリースしました。中では、エンジニアとして、最も重視していたのが「要求の変化に対応するスピード」です。
そのため、変化に強く柔軟性の高いシステム構築手法であるマイクロサービスを導入しました。導入というより、マイクロサービスを意識しながら、システム開発と構築を行いました。
「zoto（ゾートー）」におけるマイクロサービスは、従来のシステム内の関数呼び出しだった処理が、「パーツ」と呼ばれているAPIの型で実現しました。現在、システム内では、たくさんの「パーツ（API）」が用意されている。

実際やってみて、感じたマイクロサービスのメリット・デメリットを共有します。

・メリット

API毎の独立性
各々の機能は、それぞれがAPIのインターフェースを呼び合うだけで、それ以外の依存関係は持ちません。
一つのAPIは一つの事しかやらないので、複数のAPIを組み合わせることで、一つの機能が提供できる。

障害の影響が限定される
APIの処理が独立しているので、障害が発生してもそれがシステム全体に連鎖しない。

デプロイの容易性
追加機能とバグ修正を迅速に本番環境に反映できる、Jenkinsと連携しているため、一連の流れが自動的に行われています。

テストが書きやすくなる
開発スピードが上げる一方で、品質も担保しなければならない、そのため、テストコードを書きます。
「処理が複雑なので、テストが書けない」というのがよくありますが、マイクロサービスを意識したうえで作られた関数では、シンプルな処理を行っているため、その問題が全くありません。
TDD/BDDの導入も楽になっているため、最低限の品質担保ができました。

進む速さが半端ない
一番感じだのが、APIの組み合わせで、一つの機能が出来上がり、足りない処理があれば、APIを作って、すぐ機能テストの段階に入れる。

その結果、 試行錯誤を繰り返している中でも、マイクロサービス化にすることで、新規サービスの検証スピードを上げることができました。

実際の例
次の週からキャンペーンをやろうとしているときに、開発するなら間に合わないと判断しますが、実際、必要な機能をリストアップし、既存のパーツ（API）があるかどうかを確認したら、使えるパーツの組み合わせをするだけで、開発なしで、デバッグ段階に入れることになった。

・デメリット

重複・類似処理に対する悩みが増えている
似たような処理を作る際に、本当に少し加えるだけで機能追加ができる時に、既存APIをいじるｋ？新規で作るか？よく悩みます、ですが、一つのパーツは一つのことしかできないのをかんがえてみると、悩みの解消になる。

パフォーマンスが悪くなる
一つの機能を呼ぶだけでも、複数APIの呼出しが発生することになります。このため、パフォーマンスの劣化が起きやすくなります。
ですが、負荷試験を行い、レスポンスが許容範囲になってあれば、大きな問題がないと判断しています。

トランザクションまわり
一般的に、データの一貫性を維持するには、トランザクション処理を行いますが、
マイクロサービス化にすることで、テータストアが分かれるので、その一貫性を維持することは難しくなります。

ところが、「マイクロサービスの使い過ぎは有害だ」という警告があります、それは、「マイクロサービス」の概念を広めた一人であるMartin Fowler氏から発せられています。
すべてのシステムにマイクロサービスを導入する必要がないことがわかったので、色々な事例とメリット・デメリットをしっかり理解したうえで、検討すべきだと思っています。

まだ、「zoto（ゾートー）」では自動化を徹底的に行っているため、次はマイクロサービスの運用に必要なDevOpsを話したいと思います。