マイクロサービス関連の覚えておきたいアーキテクチャキーワード集


ご挨拶

皆さんこんにちは!
外資クラウドベンダーで働く、自分でも何が本職なのかわからない、Kazuyaです!
今日は、先日(といっても数か月前ですが・・)お話しした、某有名企業のスーパーエンジニアな方が
お話していた内容で自分でももう一度勉強しておきたいなぁと思ったキーワードが多数あったので、
覚書です!

1.ボトルネック解消のためのAPI構成

まず前段になっちゃいますが。
APIといっても、ECサイトなどの場合、複数のAPIを呼び出さないと、
必要なデータが得られない。
フロント⇔サーバーのターンアラウンドが多いと、当然レンダリングが遅延する。

その遅延を減らすべく、1APIでいくつかのDBアクセスなどをすることになるのですが。
そうなると、汎用性がなくなる。

でここで登場するのが、APIをハイレベルとローレベルの分割。

・DBアクセスなどをローレベルに配置。
・ハイレベルAPIは、それらのローレベルAPIをいくつか呼び出し、フロントエンドにデータを返す役割。

うん。昔の3層構造の中間層みたいな。ビジネスロジックみたいな。
そんな役割がよみがえってきた感じですね。

2.サーキットブレーカー

上述1の構成だと、ローレベル側でDBアクセスを呼び出すAPIを、ハイレベルAPIが
たくさん呼んでしまうと、遅延が発生しやすい。

そうなると、API障害が発生して、わけのわからないことが起きる。
そうなると、連鎖障害が発生して、本来独立性の高いはずのAPIが連鎖して障害やレイテンシー低下を起こす。
これでは「マイクロ」じゃないじゃん・・・と。

そのため、コアになるサービスのヘルスチェックを常時行い、
その障害が発生したローレベルAPIへの通信を遮断し、
遮断した場合でも、サービスが継続できるようにする仕組みを前提にしたアーキテクチャを組んでおくことが
これに当たります。

当然障害が出たあと、復旧した場合は、ローレベルAPI(サービス)への通信を自動再開。
このあたりの継続的なヘルスチェックと、必要に応じて連鎖を防ぐためのサーキットブレーカーが、
マイクロサービスアーキテクチャでは重要ですね👌

3.スロットリング

いわゆる、流量制限。
F5アタックの抑止にもつながる(といっても、それは通常WAFなどで対応しますが)、
特定の操作に対して、送信できるリクエストの数を制限するプロセス。
リクエストが殺到しても、待機させ、制限を上回るリクエストがなされた際には、拒否してエラーコードを返す仕様にできる。
つまり、その仕様であるI/Fを公開しておけば、リクエスト量が多すぎたのでアクセスできなかったという、
アプリ挙動が実現可能、と。

こういった、「イレギュラー」や「レスポンス・レイテンシー」といったあたり。
単に「プログラムが組める」ではなくて、
実際の運用においては不可避の領域になってきます。

アプリを組むだけじゃなくて、
「どうしてその組み方にするのか」
「こうなったときどうするのか」といったあたりを、
気にしたプログラミングがしたいですね。

それでは本日はこの辺で!
See you next time!!