マイクロサービスでウェブサービスを構築するときにAPI Gatewayのことを頭にいれておいたほうが良いんじゃないか説
新規開発でAWS ECSを使ったマイクロサービス構成でサービスを運用しているけれど、そこで学んだことのひとつに、API Gateway のことについて早い段階で考慮したほうがいいっていうのがある。
ウェブサービスの新規開発の場合なら、最初はマイクロサービスで行こうぜってなったとしても、どれくらいトラフィック来るかもわからなかったり、スケジュールの制約もあるので、実際に細かく分けることはない。
Client → App → DB
Clientが、ネイティブアプリだったり、ウェブページの情報取ってくるところ(Nodeやらウェブページやら)。App がいわゆるAPI。DBのデータを取ってきたり操作したりするところ。
最初にマイクロサービスっぽくなるところは、例えば検索機能とかあった場合に、Appから検索用のAPI(Search)を呼び出す場合。Searchでは裏で検索indexとかを作っているマイクロサービスとして見ることができる。
Client → App → DB `- → Search
こんな感じで機能がどんどん増えて行くと、Appがいろいろなところを呼び出すようになっていく。
Client → App → DB `+ → Search `+ → 機能1 `- → 機能2
すると、Appの存在が最初のモノリスティックな状態から、各機能から受け取ったデータをどう素早く取得して、適切な形式で返すかという機能に集中していくことになる。これがAPI Gateway になる。
なので、次第にAppとGatewayを分離したくなってくる。
Client → Gateway → App → DB `+ → Search `+ → 機能1 `- → 機能2
このときに、初期のデータ設計で、分離された状態を想定できていなかった場合に、移行の難易度が跳ね上がる。もしくは、分離しても各マイクロサービス間でデータのやり取りが一気に増えてしまう可能性がある。
依存関係の設計に頭を使おう
考えることは、どこまで並列に処理を実行できるかと、どこで情報の関連性を構築するか。これがデプロイにも影響するので、パッケージ管理も含まれる。これが意外とサービス発展の早い段階で着手する必要が出てくるので、もし最初からマイクロサービス的なアーキテクチャにしていこうとする場合は、頭に入れておいたほうがいいと思う。
参考
The Netflix Tech Blog: Optimizing the Netflix API