maybe daily dev notes

私の開発日誌

TIL: ソフトウェア文脈における modal behavior とは

最近話題になっている AWS Fault Isolation Boundaries を読んでいると、こんな言葉が目に入った:

Allowing individual workloads to make their own failover decisions makes the coordination less complex, but introduces modal behavior through the significant difference in latency that occurs across Regions compared to inside a single Region.

抄訳: 個々のワークロードにフェイルオーバーを任せれば〜〜複雑性は下がる一方で、リージョン間とリージョン内のレイテンシーの違いにより modal behavior を生じさせます。

ということで modal behavior が生じるデメリットがあるらしいが、あまりピンとこない。いろいろ調べたり社内で聞いてみたりしたが、以下のような意味の言葉らしい。

まずはmodal - モーダルとは

アプリケーションの中にはその動作に「モード」が存在することもある。「モード」は日本語でも想像しやすい意味の通りで、これによりアプリケーションの動作が変わるもの。

例えば vim には入力モードやコマンドモードがあり、モードによりキー入力などに対する挙動が変化する。あるいはUI文脈でモーダルウィンドウというものがあるが、これも語源はモードである。モーダルウィンドウが表示されることである種アプリケーションの動作・モードが変わるのでそのように呼ばれている。

モーダルウィンドウの例。このときAWSマネコンは削除確認モードに入っていると言える。

モーダルというのはモードを形容詞にしたものであるので、modal behavior は 「モードがあることによる振る舞い」 というような意味になるだろう。モード自体は良いことでも悪いことでもないように思うが、元の文章では明らかに悪いこととして捉えられている (複雑性が下がることとの対比。) これはなぜだろうか。

まず、この文章における modal behavior とは具体的にどのようなモードによるものなのか考えたい。ヒントは リージョン間とリージョン内のレイテンシーの違い個々のワークロードにフェイルオーバーを任せる ことにより引き起こされるものということである。なおここでいうフェイルオーバーとは、リージョンAがダウンしたのでリージョンBに切り替えるというような動作が想定されている。

あるマルチリージョンシステムのフェイルオーバーにおける主要な動作モードは、リージョンAとリージョンBのどちらを使うかということだと考えられる。特に元文脈のマイクロサービスを考慮すれば、それぞれのサービスは下流*1 のマイクロサービスを呼び出しており、下流に接続する際にどちらのリージョンのサービスに繋ぐかのモードを持つことになる。

AWSリージョンの配置図。遠いものは遠い

このモードがどのような問題を引き起こすだろうか。ここで出てくるのが、元文章でも言及されているレイテンシーの違いである。実際リージョン内の通信は1msオーダーの遅延だが、リージョンをまたぐ際は条件により100ms以上の遅延が発生する場合もあるはずだ。

フェイルオーバー前後のモードで下流サービスのレイテンシーが100倍も違うと、様々な問題のある挙動を誘発する可能性がある。例えば:

  • 多数の下流APIを呼び出す機能は、顕著に処理時間が増大する
  • リクエストが想定時間を超えてタイムアウトする
  • タイムアウトの結果、リトライが頻発して下流の負荷が増大する
  • レスポンス速度の低下によるユーザー体験への影響

私の思いつくのはこれくらいだが、他にも色々あるんじゃないだろうか。元文章では、これらの悪しき副作用・振る舞いをひっくるめて modal behavior とまとめたのだと思われる。なかなかハイコンテキストだった。

まとめ

modal behaviorはアプリケーションのモードによる振る舞いのこと。コレ自体は良いものでも悪いものでもない。文脈により意図するところが大きく変わりうる言葉なので、注意したい。

それはそうと元文章を読んでたら、マルチリージョンで可用性を確保するシステムの設計はつらそうとしか思えなくなってきた。事例見てみたい。

*1:ちなみに下流・上流も2つの真逆な定義があるが、今回は呼び出される側を下流と呼ぶ。