日々常々

ふつうのプログラマがあたりまえにしたいこと。

Tech Deep Dive #2 in Osakaに参加して思ったこと

techdeepdive.connpass.com

Tech Deep Dive #2 in Osakaに「ブログ書いてくれる人」の枠で参加したので、書きます。枠空いてたので一般参加枠でもよかったんだけど、なんとなく。

Webアプリに低レイテンシ・高可用性を求めるのは間違っているのだろうか reloaded

www.slideshare.net

再演ということでスライドは公開されています。reloadedということでいくらか更新/調整は入っていますが、大筋はこの通りでした。

話は「性能」と「可用性」をポイントとしていて、その背景に「クラウドにより技術がコストに直結する」という話は新鮮でした。性能が悪いと高価なインフラが必要になる。即時復旧やデータ整合性がコストに直結する。オンプレだと初期に固定されていたものが可変なパラメータとなったことで浮き彫りとなっている形ですね。

よくあるWebアプリケーションの構成をあげて、性能や可用性の面でどこが問題となり得るか。ある程度簡略化された構成だからこそ、それぞれの場所と結合部分に何かしらの問題がありえることは当然かと思います。これはスライドの図がわかりやすいですね。

https://image.slidesharecdn.com/techdeepdivewebapplication-171222125018/95/web-15-638.jpg?cb=1513947306

ああ、うんあるある。

タイトルの「高レイテンシ」を話は、ECサイトでどれだけの人数の同時購入を短時間に捌けるかと言ったシナリオ。パターンとして2種類、10,000商品に購入がそれなりに分散される場合と、1つの商品に購入が集中する場合。スケールアウト/スケールアップが効きやすい前者と、スケールアウト/アップが効きづらい後者というわかりやすい対比ですね。ここにキャッシュとインメモリデータグリッドのアプローチがどのような影響があるかの実測値で示され、確かにそうなるよねーと。

アーキテクチャや計測結果から読み取れることの説明を通して「この場合はこういうことが考えられる、こういう問題が起こり得る」と言った話が入り、実践する前に知識として持てているとだいぶ違います。

事象を聞いていると、2014年のJavaDayTokyoでせろさんが話された 実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡 の「DBがボトルネックなのに
 なんでAPサーバを
 スケールアウトするの?」とかを思い出しました。

https://image.slidesharecdn.com/anvg5ezbspmdzm9xoszp-signature-c1ca481fcc7191d99b160983ee307625e1b596fe1469c0d72735ca8985e1d83a-poli-141115014132-conversion-gate02/95/java-66-638.jpg?cb=1440743796

キーワード

  • 今の負荷は将来の負荷ではない
  • 障害の復旧時間を(事前に)測っていますか?
  • クラウドだと気軽にスケール頼りになっておかしくなる

もしもみなみんがアプリケーション開発者だったら

www.slideshare.net

前の話をうけて別の視点から、連続セッションだからこそできる話だと思いました。「構成を考えるのはできるけれど、実際作るのは難しい」とか、パフォーマンスの問題になったら「気軽に並列度をあげてたりすると、別のところに予期しない影響を与えるものだから徐々にしましょう」とか、「シャーディングは適切に分散されるように設計しないと効果がない」とか。

セッションはオペミスや性能などのよくある問題を挙げて、それに対する一般論の解決案が起こしうる問題の説明、理想的な解決や現実的な解決の提示という形で構成されていました。いくつかは踏んだこともあり、心当たりがありそうな参加者も多かったのが印象的でした。

インフラ側の言葉は初耳なものも多かった。

キーワード

  • 時間↓ = 処理量↓ / (速度 * 並列度)↑
  • まずは処理量をなんとかしましょう

感想

前提知識のハードルが高めに感じましたが、内容自体は一般的な知識の範囲で説明できるものだったと思います。それらを繋ぎ合わせてひとつなぎにしているところにこのイベントの価値があるのかなと思いました。ここで話された一通りを3時間程度で話せる気はしないので、素直にすごい。

一般的な知識の範囲とは言うものの、ギリギリいっぱいまで満たされていたと思います。ここから踏み込んだら現場の背景も全部入れないと的外れで「あー、うん、そうですよねー」な話にしかならない気がします。

と言うことで、経験が浅い人にこそ聞いてほしい話なんじゃないでしょうか。この知識がx年前にあれば、あの時もっと楽できたのになぁ、なんて。

以下、ポエム

仕事スイッチが入ってしまい、純粋に技術の話として楽しめなくなったポエム書きます。「Tech Deep Dive」に技術だけを求めた私の期待が外してただけなんでしょうけど、「おースゲー!なるほどー!」ってなりたかった。

事前にパフォーマンスを含めてアーキテクチャを検討する。もちろん重要なのですが、そんなの考えても仕方ないから今は考えないでおこうぜというバランスがあります。例えば「今はそれは考えない、何故なら・・・。このような条件が整ったら検討をはじめ・・・。それで間に合うように・・・・。」と言った判断を保留するアーキテクチャを採用する(かどうかすらも判断する必要があります)。このような「今は考えないでおこうぜ」という判断をするために、このイベントでの語られた知識は持っておく必要はありますが、その道具を常に振るうべきかというと否です。このバランスを取れない人にはミスリードになるのではないかと思ってしまいました。(そういうエンジニアは存在して、悪いとは言いづらいのだけど、そういう人が「エンジニアは話が通じない」と思われる原因になってるよなーというのもあって、もにょもにょ……)

例えば「10,000商品」と「1商品」と言ったシナリオがありましたが、これもECサイトならよくあるのかもしれませんが、そのプロダクトが扱う業務の性質としての取捨選択の上で成立するものです。少なくとも「1商品に注文が殺到し、それが同期処理でなければならず、待たせることがビジネスリスクだったり、本来得られるはずの利益を損ねる」ところまでが前提であり、そうでないものには無用の長物です。もちろんそんなことは当然の前提としているのだとは思うのですが、なんとなく「こういうのがあったらよくないですか?」みたいなところから銀の弾丸臭がすごく感じました。技術ってそういうものじゃない、と私は思ってます。

「インメモリデータグリッド最強」で話が終わるところにはなんとも言えません。この解決策が招く問題もあり、そちらを対処できなければ他のところに問題が移動するだけです。他と比べて重視しているものが違うという口頭でのやりとりもありましたが、それまで他のアーキテクチャでの懸念を挙げていたのにここだけ語られなかったところに疑問はありました。もちろん「でも、お高いんでしょう?」という話もありましたし、ハードウェアスペックがボトルネックにならないのも前提として提示されてはいますが、インメモリデータグリッドがパフォーマンスを発揮する前提条件がそもそも満たされないことも多くあります。認知度が低いのも確かに事実ではあるのですが、ミッションクリティカルシステム以外で使われない理由はそれだけではないわけで。

また気になったところとして、「アプリはインフラを意識したくない」というものの実現手段。疎結合は意識するところなのですが、「これで意識しなくていい」という方法がDAOの実装差し替えだとすると、これは多くの場合アプリケーションエンジニアの意識すべきレイヤーにあります。SQLを書かない世界(JPAでJPQLすら書かない場合などでしょうか)では妥当なのかもしれませんが、データベース設計などがアプリケーションエンジニアの守備範囲にある以上、意識せざるを得ない状況は変わりません。これを下手に「意識しなくていい」と言ってしまうと不適切に伝わる現場もあるのは悩ましいところですね。

金の弾丸は大抵の場合に有効です。適切なところに投資すれば、多くの場合にコストは抑えられるものです。一方、慎重になりすぎてか単にケチなのかはわかりませんが、このイベントで語られたようなものに一切手を出さず、独自技術症候群なのかなんなのかは知りませんが、力技で手当たり次第に場当たり対処して結果的に高くついているプロジェクトも多くあるのも悩ましいところです。

このイベントに限らず、アプリ/インフラと分けられた文脈で「意識しなくていい」「考えなくていい」という話はよくされます。でも「考えなくていい」というのはちょっと違うんじゃないかなと思いました。むしろ考えないためは知識を持つ必要があるはずです。知らずに領域を侵すことは頻繁にあり、それは知識が無いと止めるすべはありません。認知の外ってやつですね。知った上で、考えないでいいようにと言うよりも、邪魔しないように、適切に扱う必要があります。こういうものに「意識しなくていい」「考えなくていい」「勝手にやってくれる」となった瞬間に、なぜか「その領域の知識を持たなくていい」と解釈されるものなんだよね・・・違うよね。

とかなんとかだらだらと書きましたが、イベントも話もとても良かったとは思っています。長時間セッションで疲れたってのはありますが、続けて開催されるなら参加したいなぁ。