冪等性の基本概念
皆さんこんにちは。 雨宿りとWEBの小噺へようこそ。
パーソナリティのkeethこと桑原です。 この番組では、目まぐるしく変化するWEB業界で、ちょっとひと息つける裏話や小噺などをお届けします。
皆さんは、同じことを繰り返してもいいんだろうか? という問いに対して、どのように感じられますかね。
おそらく多くの方っていうのは、これに対してノーだと思われると思いますが、ことエンジニアとかプログラマーにおいてはですね、
むしろ同じことっていうのが望ましいケースが豊穣にしてありまして、そうあれべきと思っているぐらいなんですよ。
ということで今回の話題は、冪等性、エンジニアがよく使う言葉をお話しようと思っています。
英語でアイデンポテンシーと書いたりします。 もしかしたら辞書を調べたら出てこないかもしれないですね。
僕の手元の辞書にはなかった。 またこの言葉自体やはり聞き慣れない方も多いと思いますが、聞いたことはあると思いますね。
冪等と。 実はこの言葉、結構ですね我々の日常にも密接に関わっていたりするんですよね。
そんなお話を今日はしようかなと思っています。 一つのエンジニアの文化というか、そういう人種なんだなっていう一つの面を見せたくなりました。
まず、冪等性という言葉の意味からお話しますけど、これは同じ操作を何度繰り返したとしても結果が変わらない性質のことを言います。
例えば皆さんのお家のリビングとかに電気のスイッチあると思いますけど、そのスイッチを考えてみた時に、これ冪等ではないんですよね。
押すたびに状態が変わりますよね。 押したら必ず電気切れるって状態だとしたら、そんなスイッチ使いたくないですよ。
1回押すと点灯、もう1回押すと消灯というような感じ。 一方でエレベーターのボタンとかはどうでしょうか。
こっちは一度押しても焦って10回連打しようが、エレベーター同じ階に止まるし、閉じるボタンを押したら必ず閉じますよね。
これは冪等だっていうふうに言えます。 じゃあコンビニとかでATMを使ったことある方もいらっしゃると思いますけど、
引き出しボタン、あれを20、30に押してしまった場合どうなると思いますか。 これ結果的には全然大丈夫だし、システム的にはそうならないようになっているはずなんですけど、
でもこれは冪等性だっていうお話につながると思っています。 で、この冪等性という概念ですけど、ウェブの基本技術であるHTTPメソッドというものがありまして、
聞いたことある方いるかちょっとわからないですけど、そういうものがあってこれにも深く関わっております。 いわゆるゲットとプットとデリート、あとポストもありますけど、
その最初言ったゲット、プット、デリートっていうHTTPメソッドは冪等ではあります。 ただポストは非冪等とされています。
これは変更するからっていうところがあるんですけど、これですね、昔インターネット、冷免器まで戻るかわかんないんですけど、
ネットワークの信頼性ってかなり低かったんですね。 で、ブラウザーでページを読み込んでいる途中で、ネットワークの不備だったり、それが遅くて、
途中で切れてしまうみたいなことを珍しくはなかったんですね。 サイン読み込みしますかというダイアログが出てきたりすると。
で、これほんまに押して大丈夫かなみたいな。 ページによっては、例えばカート画面に進んでて、注文完了前のところでこれもう一回押して大丈夫かって思ったり、
2回注文されてしまうみたいなこともあるんではないかと。 そんな不安を解消するために、HTTPの設計者たちは何度リクエストを送っても安全なメソッドと、
一度だけ実行すべきメソッドっていうのを明確に分けるようにしたんですよね。 それがGet、Put、DeleteとPost。明確な分け方です。
で、あとはね、一つ別の話もしようと思って。 ある大手のECサイト、インターネットコマースですね。アメリカだった気がしますけど。
支払い処理システムに問題が発生したと。 ネットワークのタイムアウトが起きて、お客に二重で請求するバグが発生したことがありましたと。
支払いは完了しませんでしたけど、もう一回試してくださいみたいなメッセージをお客さんが見て、 結局再度決済ボタンを押して、裏では二重に課金されていたというわけです。
この問題が明るみに出た時、数百件の二重請求というのが実は発生していて、 このお客さんだけじゃなかったんですよね。
で、返金対応と信頼回復のためのキャンペーンで、 推定100万ドル以上損失が出たというふうにありますと。
結構デカいですよね。100万ドル以上、1億ですからね。 この一件はきっかけに、この会社さんでは全てのトランザクションに適当性キーという仕組みを導入することになりまして、
冪等性の実生活での事例
各取引に1位のIDというのを付与して、 同じIDのリクエストが来た場合は2回目のリクエストだなというふうに判断して実行をスキップするというような仕組みを入れたと。
あった一つの実装漏れで100万ドルの損失が起きたという、これデカい話ですよ。
あとはクラウドサービスで有名なAmazonウェブサービス、 AWSの設計思想にも適当性というのが深く関わっています。
AWSは皆さんにはあんまり馴染みないかもしれないです。 AmazonというとECサイトの会社ですよねというふうに思われるかもしれないですけど、
僕らエンジニアにおいて言えば、 AmazonというとECもありますけど、どっちかというとサーバーのサービスをやっているというふうに認識する人の方が多いと思います。
詳しくはちょっと調べてみてください。 AWSというものがあります。 全世界でたくさん使われていて、 AWSが潰れると世界が止まると言われているようなサービスですね。
余談でした。 AWSのシステム設計における有名な教訓、いくつかあるんですけど、その中の一つに、
メッセージは一度だけ配信されるとは思うな。 メッセージは必ず一度は配信されると思うな。
メッセージの順序は保存されると思うなというものがあります。 つまりシステムは必ず失敗する前提で設計しなさいということを言っているというふうに捉えていいと思います。
この教訓から彼らはですね、全てのシステム操作を適当に設計するという原則を採用しました。
すなわち同じリクエストが複数回来たとしても問題ないように作るし、同じようなレスポンスが返ってくるというふうに作ると。
これによってAWSの分散システムとは他社に比べて高い信頼性を実現できたというふうに言われています。
いろんな例を出したんですけど、僕もですね、実際ECサイトで波重決済は経験したことが実はあります。
どのサイトとは言わないですし、どの会社さんのシステムとも名前は伏せますけど。 裏で決済代行システムというのを導入してて決済のフローだったんですけど、びっくりしましたね。
いきなりメールが来て、厳密に言うとメールというか、注文完了メールは1通だったんですけど、その後の決済の話の連絡を見たら、
なんか同じ金額で2個決済されてるぞっていうのが来て、システムに問い合わせたら実際に二重決済だったというところで、自分でもあるんだなと思いました。
同じようにネットワークの調子が悪かったか、向こうのシステムが負荷が高くてちょっとレスポンスが遅かったので、もう一回押してみたんですよ。
まあそういう時は素直に待てばよかったと思いますけど、そういうこともあるんで、実際怖い話ではありますけど。
そんなことでいろんな例を出しましたけど、適当性という言葉、実は身近にたくさんあるなっていうお話をしたくなりましたというところですね。
今システムとかECとかの話が結構多かったと思いますけど、さっきの電気の話もそうですし、あとはドアの話。
ドアに適当性という概念を持ち込むのみたいな話はちょっとありますけど、ドアっていうのは開ける操作は適当だけど、
人によってはドアって押すたびに開いたり閉まったりするみたいな、ちょっと壊れたドアもあったり、もしくは回転式のドアだったり、
押すたびに開閉するトワイプのドアっていうのがあったりするんで、適当性って説明意外と難しかったりするんですけど、
とにかく同じことをやったら同じ結果が返ってくるっていうのはシステムとかアプリでは本当に根幹の概念なんですよ。
これから毎回違った結果が返ってきたり、毎回あべこべな結果になってしまうと、そのシステムとかサイトって信用性がまあないから、
みなさん使わないっていうので、僕らエンジニアはそういうことをしっかり考慮して実装していくっていうのが大事になってくるという感じですね。
一応僕らでは適当っていうのは本当当たり前の概念で、これがあるからこその信頼性っていうのをしっかり担保する、結構大事だと思いました。
というところで、では今回もエンディングです。
はい、さて、今回は適当性という難そうな概念について話したんですけど、同じ操作を何度繰り返しても結果変わらないという単純な原則ではあるんですが、
我々のデジタル生活の安全と信頼性を支えているというものでですね、僕らが当たり前に使うこの言葉、背景には実は昔はなくて、たくさんの試行錯誤とかいろんな失敗だったり障害だったり問題が起きて今に至る。
もしですね、ネットショッピングをしていて、途切れたシステムであればボタンを連打しても二重請求はされないはずですけどね、
その時に、あ、そういえばこれが適当か、みたいなことを思い出してもらえたら、これがしっかり担保されていれば、エンジニアはしっかりこの適当性担保した実装をしているんだなというふうに思っていただけると良いかなと思います。
はい、ではここから宣伝です。この番組面白かったよという方は是非チャンネル登録もお願いします。
もし聞いていて気になることや話してほしいトピック、感想などございましたら、概要欄のフォームやXでハッシュタグウェーブ小話でつぶやいてください。
ウェーブはアルファベット、小話は漢字でもひらがなでも大丈夫です。
今回もお聞きくださりありがとうございました。甘えどりを考える技術の編成、次回もどうぞお楽しみに。甘えどりとウェブの小話、お相手はキースでした。
さよなら。
