ご挨拶
皆さんこんにちは！
外資クラウドベンダーで働く、自分でも何が本職なのかわからない、Kazuyaです！
今日は、先日（といっても数か月前ですが・・）お話しした、某有名企業のスーパーエンジニアな方が
お話していた内容で自分でももう一度勉強しておきたいなぁと思ったキーワードが多数あったので、
覚書です！
1.ボトルネック解消のためのＡＰＩ構成
まず前段になっちゃいますが。
ＡＰＩといっても、ＥＣサイトなどの場合、複数のＡＰＩを呼び出さないと、
必要なデータが得られない。
フロント⇔サーバーのターンアラウンドが多いと、当然レンダリングが遅延する。
その遅延を減らすべく、１ＡＰＩでいくつかのＤＢアクセスなどをすることになるのですが。
そうなると、汎用性がなくなる。
でここで登場するのが、ＡＰＩをハイレベルとローレベルの分割。
・ＤＢアクセスなどをローレベルに配置。
・ハイレベルＡＰＩは、それらのローレベルＡＰＩをいくつか呼び出し、フロントエンドにデータを返す役割。
うん。昔の３層構造の中間層みたいな。ビジネスロジックみたいな。
そんな役割がよみがえってきた感じですね。
2.サーキットブレーカー
上述1の構成だと、ローレベル側でＤＢアクセスを呼び出すＡＰＩを、ハイレベルＡＰＩが
たくさん呼んでしまうと、遅延が発生しやすい。
そうなると、API障害が発生して、わけのわからないことが起きる。
そうなると、連鎖障害が発生して、本来独立性の高いはずのＡＰＩが連鎖して障害やレイテンシー低下を起こす。
これでは「マイクロ」じゃないじゃん・・・と。
そのため、コアになるサービスのヘルスチェックを常時行い、
その障害が発生したローレベルＡＰＩへの通信を遮断し、
遮断した場合でも、サービスが継続できるようにする仕組みを前提にしたアーキテクチャを組んでおくことが
これに当たります。
当然障害が出たあと、復旧した場合は、ローレベルAPI（サービス）への通信を自動再開。
このあたりの継続的なヘルスチェックと、必要に応じて連鎖を防ぐためのサーキットブレーカーが、
マイクロサービスアーキテクチャでは重要ですね👌
3.スロットリング
いわゆる、流量制限。
F5アタックの抑止にもつながる（といっても、それは通常WAFなどで対応しますが）、
特定の操作に対して、送信できるリクエストの数を制限するプロセス。
リクエストが殺到しても、待機させ、制限を上回るリクエストがなされた際には、拒否してエラーコードを返す仕様にできる。
つまり、その仕様であるI/Fを公開しておけば、リクエスト量が多すぎたのでアクセスできなかったという、
アプリ挙動が実現可能、と。
こういった、「イレギュラー」や「レスポンス・レイテンシー」といったあたり。
単に「プログラムが組める」ではなくて、
実際の運用においては不可避の領域になってきます。
アプリを組むだけじゃなくて、
「どうしてその組み方にするのか」
「こうなったときどうするのか」といったあたりを、
気にしたプログラミングがしたいですね。
それでは本日はこの辺で！
See you next time!!