様々な事業会社での経験
jfluteは、様々なWebサービス開発・運営の現場で支援をさせて頂いています。その経験から特にここ5年で切に感じたことです。
o 本番運用中に落ちた！
o もうまもなく落ちるところだった！
o このままリリースしてたら落ちてた！
「想定外のアクセス数などでインフラ的に耐えられなくて落ちる」という原因は想像しやすく、永遠の課題です。未然に防ぐにはどうしたらいいか？ずっと考えていくことでしょう。
一方で、「落ちた！」の中のそれなりの割合で存在するのが、ブログタイトルの通り「フレームワークの使い方を間違えて落ちる」だと感じています。完全に感覚値で正確ではないですが、3割から5割くらいはそれじゃないかっていう感覚です。
未然に防ぎたいという思いがあるのであれば「えっ、わりと簡単に防げたはずだけど？」と思うような原因で落ちることが...
よく
あるのです。
フレームワークの使い方とは？
使い方というのは広い意味で使っています。
...
単純に「使うメソッドを間違っているー」というようなわかりやすい事例とか...
フレームワークのメソッドを勘違いしていて不要なメソッドも呼び出していて、とあるケースで想定外の挙動をしてしまったとか...
フレームワークが想定している実装の仕方をせず、なんとなく動いてはいたけどレアケースでギャップが生まれて落ちてしまったとか...
フレームワークの挙動を理解せず、自分たちで仕組みを付け足して、レアケースでのギャップで落ちてしまったとか...
フレームワークにすでに存在する機能を知らず、自分たちで実装してバグで落ちてしまったとか...
要件的にどうしてもフレームワークをちょこっと拡張していたけど拡張の仕方が荒く、フレームワークのバージョンアップでギャップが生まれて想定外の挙動で落ちてしまったとか...
既知の不具合のある古いバージョンを使っていて、アップグレードしないといけないと思いながらも、いまいち危機感がなくずっと放ってしまっていて落ちてしまったとか...
必要なオプションを設定するときに、どれがどれだかよくわからずあれもこれもと別のオプションも有効にしてしまって落ちてしまったとか...
...
いやはや、千差万別でまとめきれません。ただ、まとめて言えることとしては...
ちょっと、そのフレームワークわかっていれば落ちてなかった。。。
ということに尽きます。
間違いが本質の問題ではない
間違えること自体はしょうがないと思います。人である限り防ぎようもないことではあります。ただ、それが本番まで行ってしまっているということは大きな問題です。
o 自己レビューで気づけなかったでしょうか？
o プルリクレビューで気づけなかったでしょうか？
仕組みを追求する姿勢が少しでもあれば、自己レビューで気づけたかもしれません。
仕組みに詳しい人が現場に一人でも二人でもいれば、プルリクレビューで気づけたかもしれません。
そして、「おや？」と思ったとき、フレームワークに詳しい人に聞けば、最初から間違わなかったかもしれません。
フレームワークに詳しい人が誰もいないというのもチーム状態の問題ですし、詳しいとまでいかなくて各人がフレームワークに対するアプローチを曖昧にしてしまっているのも問題です。
落ちるとまずいフェーズ？
先ほど「ここ5年」と書きましたが、5年より前は思ってなかったのか？ということでいうと、それより前はわりとスタートアップ直後の現場を見ることが多く、本番での安定稼働よりもビジネスを推し進めていくことが比重が高く、それこそ落ちるは日常茶飯事(ってのは言い過ぎ!?)ではあるので、そこまで意識はできませんでした。
サービスの黎明期は、もちろんフレームワークの使い方も当然ありますが、もっと原因も多様化していて「特にこれが」って着目するような感じでもなく、フレームワークの使い方による原因だけを未然に防いでも全体の落ちるの一部カテゴリなので、費用対効果も高くはありません。
そこから、事業も安定してきて徐々に「落ちるとまずい」というフェーズになってきて、組織や運用の仕方も変わり、様々なものが仕組み化されて単純な原因の「落ちる」は減っていきます。逆に増えてくるのがアクセス数の過多によるパフォーマンス劣化などでの「落ちる」ですが、なぜか生き残っているのがフレームワークの使い方間違いによる「落ちる」なのです。
多様化は本当の多様化？
「システムの技術は非常に多様化しているので、なかなか特定の技術を追求するのは難しい」という声はよく聞きますし、まったくその通りだということで、jfluteの教育も色々と配慮を試行錯誤しているところではあります。
ただ一方で、その多様化は本当に必要？と思うような場面もあります。「あれやってみたい、これやってみたい」というきっかけ(だけ)で、メンテナンスするツールをどんどん多様化していく現場。チャレンジは非常に大切なことなので良いのですが、そもそもいまメインで使っているツールの習熟が置き去りにされちゃってない？と疑問に思うこともあります。
アーキテクチャは会社の資産である以上、プラスアルファな多様化をするからには、それなりの覚悟は必要です。みなが、サービス維持のための習熟コストと多様化のチャレンジメリットのバランスを考えていかないといけません。
フレームワークを学ぶ価値
「普段は業務理解で一杯一杯なので、なかなかフレームワークを追求するのは難しい」という声はよく聞きますし、まったくその通りだということで、jfluteの教育も色々と配慮を試行錯誤しているところではあります。
ただ、本番運用中のサービスが落ちるトラブルを何度も何度も目の当たりにしたことで...
やはりサービスの落ちる落ちないに多大な影響を与えるフレームワークの理解というのは、特に落ちるとまずいフェーズにあるサービスのディベロッパーたちにとって重要なことである
という風に考えるようになりました。
例えば、フレームワークのソースコードリーディング会は、単なる趣味でもなく、個人のキャリアのためのトレーニングでもなく、いま目の前をサービスを落とさないようにするための一つの施策であるとも思えるようになりました。
いまいちど、jflute自身も「フレームワークを学ぶ価値」というのを見直して、よりサービスに貢献できるフォローイングを追求していきたいと思います。
