マイクロサービスでウェブサービスを構築するときに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