クラウドサービスが増えて、APIでキックすればよしなにサービスが受けられる仕組みが増えたおかげで、APIを活用したシステム設計がオープンループかクローズドループかで悶々することが増えたのでブログを書いてみます。
オープンループとクローズドループ、もしくはフィードバックというのは制御システムの設計に使う言葉です。
オープンループとは、「アウトプットがどうなってるかはあまり気にせず、出力を制御する方法」です。例えば電球が切れてるかもしれないけど、とりあえずスイッチオンをすれば電球がついたことにしておく、というもの。
alexaを使って部屋の電気をつけるなんて仕組みがありますが、実際に電気がついたことをalexaは確認していないですよね。そういうのをオープンループ制御と呼びます。インターネットの時代で、ここまでで仕事したつもりになる発想は結構浸透しているんじゃないかと思ったりします。
特にスタートアップ的なスピード優先という言葉の中に、こういう発想でのOK感は否めないと思うことも少なくありません。
一方、フィードバック制御とは、
「アウトプットがどういう状態になってるのか？を調べながら、出力を制御する方法」
です。モータの回転が希望通りの回転になっているか？を調べながら、回転数を制御する仕組みなどに用いられます。つまり目的の回転数に達するまでに徐々に電圧を上げていき、目的の速度に到達するまでの制御をするというものです。自動運転で一定速度を維持するなどでも用いられます。
もし、これぐらいスピードが出てるよねってのをオープンループで制御すると、とりあえず50%開度でアクセルONなどとやりますが、坂道と下り坂、路面の状況でスピードが変わってしまうので、あっという間に事故が起きて人が死んでしまいます。
ソースコードを書いてunittestを回したデプロイフローってのも、ある意味フィードバックループを回しているとも言えますね。ソースコードを開発し、テストでエラーが０になることを前提としたデプロイシステムを構築して、何かあったら人間が修正するという、その一連のプロセスにフィードバック図を書くことができます。
AIシステムもフィードバックループのシステム開発の代表例です。ロボットとAIの相性が良いのは、フィードバックシステムの設計方針の中に推薦、推定などの仕組みが組み込まれるべきだからでしょう。
さて、もっと身近な例、この二つの例として、Amazon SESを使ってメールを送るシーンを考えます。
Amazon SESのAPIに情報を投げると、とりあえず受付OK/NGの結果が帰ってきます。しかし、メール処理は、非同期処理ですので、実際メールを送ったら何かの理由でエラーだったかどうかまではわかりません。
ここまでのステータスで、「とりあえずメールを送ったつもりになる」というのがオープンループ制御です。
大多数のケースでメール送信はできていますから、ここで満足する手もありますが、それをあえてやっているならともかく、何も問題ないからと無自覚にやっているのは、設計者としては若干の恐怖感を抱いてしまいます。
これでOK感というか、ここまでしか設計できないことを「オープンループ思想」と呼びたいと思っています。
しかし、実際はbounceしていたり、SESが障害で正しくキューを処理できなかった可能性もあります。
AWSのドキュメントをちゃんと調べると、メール送信結果のイベントはAmazon SNSを通じてフィードバックを受けることができます。
「バウンス、苦情、配信」の３つのイベントをSNSを通じて自社のメール配信ステータスまでフィードバックすることが可能です。
このステータスを受取、再送処理やエラー通知までしっかり作り込むと、比較的堅牢なシステムを作り上げることができます。
これを「フィードバック制御思想」と呼びたいと思います。
クラウドサービスで非同期型APIをキックすることが増えた今、その成功失敗をどう受け取るか？はしっかり作り込まないと、大量データ処理を実現しても、実際はスリップしまくりで、結果的に得られるユーザ満足度が低いなどと言ったことが起きてしまいますし、オープンループ思想しか持ってないエンジニアでは、この問題を解決することができません。
なお、「比較的堅牢」と書いたのは、メールサーバの向こう側の世界は不明だからです。これがインターネットにおける甘えの元凶になります。
例えばキャリアメールは、何もフィードバックを返さずに、メールをもみ消したりすることがあるようで、ワールドワイド規模のメール送信サービスからは鼻つまみ者扱いされています。そういうガラパゴスな状況は、基本的に無視されることが多いため、「比較的」と書きました。また、メール側をHTMLメールにして、着信情報をトラッキングする技もありますが、これはメーラー側がHTMLを許可しないとダメなため、あくまでも限定的です。特に画像を表示する、しないをユーザが制御する設定になっていれば、トラッキングのフィードバックは得られません。
問題はこういったインターネットの特殊性、複雑性を隠れ蓑に、オープンループ発想のままで進化しないケースがあるような気がしていて、それはよくないよと思ったので、こういう記事を書いてみました。昔、Windowsはいろんな不具合に対する複雑性が高いので、とりあえず障害原因をマイクロソフトのせいにしておけば、普段Unixしか使ってない相手に対してコンセンサスを得られるなどと言った時代がありましたが、僕らはそういう複雑なコンピューティングの中で、誰かのせいにして自分の身を守ることに慣れすぎたような気もします。
特にPHPのメソッドは同期処理が多いので、サービスが順調に成長して、スケーラビリティを求められた瞬間に、非同期処理の世界に足を突っ込んでいかないといかなくなったりしますので、そこら辺の己の進化はしっかりやっていきましょう。
これまで何も問題なかった安定性は、ハイパフォーマンスな同期処理＋ローカルで安定したミドルウエアに支えられていただけかもしれないですので、そこのありがたみは実感した上でコードを書いていきたいものです。
【PR】ご意見、感想などは是非、mstdn.fmのローカルタイムラインでお聞かせください