■

いつかの社内勉強会でネタに使えるかもしれないので記録。

ContainerPatternで"Ambassador Pattern"(Googleで直訳すると、大使の紋章..めっちゃかっこいい)というのがある。

https://docs.microsoft.com/en-us/azure/architecture/patterns/ambassador

なにが大使やねんというと、サービスAがサービスBに接続するときにサービスA'がサービスAの代わりにしてくれるかららしい。外交官的な。

接続にかかわるもろもろ、回線の監視だとかリトライ処理だとか認証だとかそもそも接続する設定値だとかそういったものを代わりにやってくれるサービスを別途にもうけようぜという仕組みだそうだ。

その仕組みがはまる例として

・異なるプログラミング言語だとかフレームワークのサービスを織り交ぜている

・アプリ開発者が認証の仕組みまで意識して作りたくないよ

という時だそうだ。

ふむふむとうなづきつつ、アンチパターンの方で躓いた。

一つのプログラミング言語しか使ってない場合はメリット内からクライアントに直接通信用のライブラリ入れろよというのは納得...したんだが、

Consider the possible impact of including generalized features in the proxy.

For example, the ambassador could handle retries, but that might not be safe unless all operations are idempotent.

一般的な機能をプロキシに含める影響を考慮してください。例えば、リトライ処理をするとき、全ての処理(注釈: アンバサダー⇒リモートサービスに対する処理)が"冪等"でなければ安全ではないかもしれません。

冪等ってなに？え、リトライ処理でデメリットが生じることがあるの？(ログインの試行回数とか？)

有識者的にはあーっ知ってるよで終わる話(隣の技術者に聞いた感じ)なのかもしれないけどそもそもidempotentの訳を知らなかったので

ググると、"treasure data"の中の人のブログにたどり着いた。

リトライと冪等性のデザインパターン

これだよ！！これが俺が知りたかったことなんだ。ありがてぇありがてぇ。

接続しようとしている外部リモートサービスの話で合って、リトライする側のアンバサダーサービスが考える話ではないし、

接続しようとしているサービスに応じてアーキテクチャ設計が変わっちゃうと本末転倒感あるけど、

少なくとも考慮すべきポイントであることは了解だ。

...はぁ、勉強したー!!

Permalink | 記事への反応(1) | 17:49

ツイートシェア