まずは、会場に来て下さった皆様、本当にありがとうございました。 ご来場の皆様が何か少しでも得るものがあったのであればいいなぁ…と考えます。 面白いイベントを企画して僕を呼んでくれた jxck には感謝しかありません。
このエントリでは、話足りなくてモヤモヤした部分を勢いで書きなぐってる感じなので、無駄に長い割にオチが無いので暇な人だけが読んで下さい。
観客として参加したセッションについて#
僕が見ていたセッションは、
- server_perf
- standardization
- http2
- monitoring
です。僕の主観としては余り未来の話をしてなくて現状確認に終始した後に、最後の 15 分くらい未来をチラ見せみたいな感じだったかなぁ…と感じています。
しかしもって、未来みたいなものの話をするのは兎に角難しいので、少しでも未来っぽい話出来ればそれで良いんじゃないかと考えます。
セッションについて#
僕のセッションでは途中、yugui さんの面白い返しで頭が真っ白になったりもしましたが最後まで出来て本当に良かった。 太一の思考が事故ってる部分を見たい方は是非動画を確認してください。
サーバアーキテクチャについて#
そもそもアーキテクチャ等と言うものは要件ありきのものであるし、特定のテクノロジに立脚して成立するアーキテクチャと言うのは、システム全体から見た時にはごく一部でしかないという前提を共有するのを忘れていました、ええ。
僕の経験や知識の範囲に収まるように誠意を持ってお話させて頂くという風に考えた場合、課題に対する物事の取捨選択がアーキテクチャ策定です。 変な例えですけども、アーキテクチャ策定は冷蔵庫の中に入ってるもので作るカレーです。ただ、うちの冷蔵庫には他所で見かけない変な食材が入ってることはあります、ええ。
誰も見た事の無いような素晴らしい何がしかを生み出すというのは、少なくとも僕の認識としてはアーキテクチャ策定ではありません。
んで、今回はサーバアーキテクチャと言っているので、多分きっとソフトウェアアーキテクチャの話をすべきなんだろうなぁ…とは考えていました。
ウェブアプリケーションにおけるサーバが担う役割と言うのは非常に広いですね、はい。
基本的には共有リソースをどの様に各ユーザに効率よく割当てる事で、より多くのリソースを獲得し、その獲得したリソースを使ってアプリケーションを改善していくか、という事に還元されると考えます。
ここでいうリソースは、何か色々あるのですけども僕の認識としては以下の四つのうちどれかに含まれるものです。
- ヒト
- モノ
- カネ
- トキ
リソースとは#
僕の認識としては余り沢山ヒトにリソース配分するとボラティリティというかリスクが大きくなる傾向にあるので、ヒトにリソース配分する際にはリスクをキチンと管理しましょう。
できる限りモノにリソース配分できるとスケールするのでビジネスとしては勝てる感じが出てくると考えています。
カネは汎用性が高いリソースなんですけども、明確に扱える量に上限がある。上手く沢山のカネを入力しつつ、それを上手くヒトやモノに割当てていけるとイイナァという話です。
トキは一番貴重なリソースなのに黙ってても減っていく本当にヤバいリソースです。トキをキチンと管理できてないプロジェクトは滅びる。
アーキテクチャとリソース#
んで、ソフトウェアアーキテクチャというと大体がモノの話に終始しがちで、今回のセッションでも大体、そういう話しかしなかったと言うか出来なかったのが、残念極まりない部分です。
ヒトの話#
例えば、ヒトについて話すのであればプロジェクトメンバの教育や成長の話、キャリアパスの話になります。特に高度なエンジニアと言うのは、レアなので基本的に自前実装するしかありません。
しかし、自分たちのプロジェクトに特化した知識を詰め込むだけでは高度なエンジニアには決してなれませんので、各自が自習する事を期待します。僕の認識としては、その自習時間を開発プロセスの中にどれだけ組込めるか、また、その内容や成果をどうプロジェクトに取込んでいくのかみたいな事は考えないといけない課題です。
ただ、基礎的な技術と言うのは習得に凄く時間がかかる上に直接は役に立たないので、残念ながら給与の出ないプライベートな時間を使って学習することを期待せざるをえないのが現状です。
つまり、プライベートな時間を仕事のための学習に割当てるような生活サイクルを持ってる人間を雇用するか、もしくはプロジェクトメンバを何らかの方法で、そのような生活サイクルの中に嵌め込むようなことをせざるをえません。
自習を期待すると言っても、極めて貴重なリソースであるトキを消費することになりますので非効率なやり方をされては困ります。自習の効率を上げるためにそのプライベートな時間に対して何らかの関与が必要になります。これをやり過ぎた会社は、ブラック企業と呼ぶのに相応しいというのが僕の認識です。
会社組織として個人の時間に関与するからには、それなりに責任を持たなければならない筈ですが、企業が個人に対して出来る補償というのは概ねカネに還元しうるものだけなので、無給のプライベートな時間に関与している時点で、そこに矛盾があります。
また、その関与の内容が誤ってしまうこともあるでしょう。その場合、失われたトキを取り戻すことはできません。
こういう微妙なさじ加減の話はあぶなっかしいので、録画されているような場で話すのは難しいのですけども、知見としてマージされる事に一定の価値はあるしょう。
カネの話#
アーキテクチャの話なのにカネの話するのか？ってのはあると思うんですけども、結局もっとも汎用的で代替の効くリソースであるカネの話をすっ飛ばしてアーキテクチャの話するのは片手落ち感あると言わざるをえないのです。
単純な話、基幹系 SI と B2C 系 Web では予算規模が全く違いますのでハードウェアやサービスを購入する際の基準が全く違います。そもそも、誰のカネなのかって部分が違いますので、カネの使い方についても自ずと差異が発生するでしょう。
尚、予算規模が多いからといって良いかというと、そうでもないと言う所までは、皆様合意して頂けるとは思います。
変な話ですけども、大勢の Web 系エンジニアが MySQL+memcached で頑張っているのを眺めていると、Oracle+Coherence って選択肢はどうかなー？みたいな気持ちになることがあります。超高額なライセンス料の話は別途あるし、カジュアルな知見がインターネット上にないテクノロジってどうなの？みたいな話もあります。
標準的なエンジニアの待遇についても、随分と差があるのでカネに対する認識も随分と違うんだろうなぁ…とボンヤリ考えたりもします。
しかしもって、カネの話は正直パブリックな場所じゃ出来ませんよね、ええ。
トキの話#
ヒトの話と大分被る部分もありつつ、プロジェクトマネジメント的な課題とエンジニアリング的な課題を、どういう風にマージしていくのかみたいな事はトキの話なります。
今は不安定だけど将来性を強く感じるテクノロジを今から使うのかどうか問題なんかは最たるものですね。いや、それ地獄しか見えねぇんだけどってのはごもっともです、はい。
monitoring のセッションで盛んに話されていた小数の運用エンジニアが 24 時間 365 日障害通知をうけとる問題なんかも、ヒトとトキの複合課題です。短絡的にはカネで何とかしろって事なんですけども。
gRPC や HTTP/2 みたいに新しいテクノロジには自分たちのプロジェクト内における学習コストの問題もありますけども、周りのハードウェアや IaaS ベンダの対応待ちみたいないかんともし難いトキの問題を含んでいます。
最後に#
長くなってきてそろそろ辛いので、尻切れトンボ感ありますけども、これ位で終わりにしておきます。
そもそも、俺モデレータやったの人生で初めてかもしれない。 大体が、立派なモデレータの皆様に「太一ちょっと静かに」的な目線くらったりしながら、好き放題しゃべるだけ喋ってきたような気がします、ええ。