今日は僕の誕生日です。誕生日の7時間をかけて書きました。笑
ようやく最後の章です。 Exampleは取り上げた例が特殊すぎたかな、とちょっと反省しています。 が、時間がない。次々いきます。 ※最後の章はほぼ思想論です。そういうのが好きでない人は読み飛ばしてください。 さて改めて考えてみます。 優れたシステム・アーキテクチャとはどのようなものでしょう？ 第１章でも取り上げましたが、システムは「データを管理し、それを利活用すること」が目的です。 そして、データとそれを利活用した機能の間をどう繋ぐかはエンジニアの自由です。 すなわち、この自由がどう担保できるか、が、システム・アーキテクチャを考える上で最も重要なことです。 重要なポイントはいくつもありますが、あえて絞るとすれば、以下７つです。
- Data lake managementは基本中の基本
- BrushUp Point / Benefit Lineをできるだけ絞り込む
- 採用するプログラミング言語やライブラリ・IaaS・SaaS・ミドルウェアの哲学や文化背景を知る
- Abstract roles to build
- 作るメンバーを知る（社会の中で・チームの中で）
- 不自由なエンジニアリングを認識する
そのくらい、システムアーキテクチャの基本的な考え方には共通点が多いのです。
もう少し実装よりのチームだとSLOの明確な定義と共により具体なインフラ・アーキテクチャ・マップとして起こすことになりますが、簡易的なMicroServiceであれば、この粒度の概念と基本的なService Unitがあれば、システムの実装は始めることができます。むしろ、サービスの目的に応じたdata lakeの設計に多くの時間を使うべきです。
Data lakeは基本中の基本
２章の①でも触れました。 １つのデータに対して様々な利活用を模索する現代では、data lakeは基本中の基本です。 データのモデリングはMVCの時代から機械学習全盛の現在に至るまで、プログラミング言語に閉じることなく様々なレイヤーで実現されてきた概念ですが、これをどう実現するのか、は、週末のお酒をやめて一向にふける価値がある、興味尽きないテーマです。BrushUp Point / Benefit Lineをできるだけ絞り込む
システム・アーキテクチャの中で、本当にブラッシュアップし続けなければならないポイントは限られています。そうしたポイントをいかにAsility高い状態に置くことができるか。これは優れた設計を象徴する最終的な目的とも言えます。ここが様々な制約から解放された形を作り出せたら、アーキテクトの仕事の80%は終わったと言えるでしょう。 ビジネスはまた流動的にその姿を変えますから、システムが追随できなくなったときに、再びアーキテクトの眠れない日々が始まるのですが。 そうしたリファクタリング、リアーキテクチャもまた醍醐味のひとつです。なぜプログラミング言語やミドルウェアの哲学や文化が重要なのか？
昨今変化の激しいエンジニアリング環境ですから、プログラミング言語やミドルウェアのキャラクターもどんどん変わっていきます。 その変化のエコシステムの中で、多くの言語やミドルウェアを運営する各チームはお互いが行き着く先に迷うことがないよう「こういう方針で開発を継続している」という指針を出しています。また、それはチームごとの独自の哲学により運営されています。 システムアーキテクチャのベストプラクティスは、勝手に変わっていっているのではなく、お互いが相互して変え合っているということを認識すべきです。 あなたのサービスが社会のエンジニアリング資産を再利用しているだけの存在に見えても、それは幻想でしかありません。 データの利活用の立場に立ったとき、ほぼ全てのサービスはその哲学に相互に影響し合っている。 ことWEBサービスにおいては、そのことは断言できます。Abstract roles to build
「役割を抽象化して設計する」 この過程を省くと、社会にある様々なシステムが持つ哲学の「今」の姿に踊らされて設計することになってしまいます。 すると、社会の流れを見誤った設計を生み出しがちです。 このことからわかるように、抽象化はあなたが運営するシステムの哲学そのものになり得ます。 一見すると自社サービスと捉えがちな手元のサービスも、スクレイパーや検索エンジンからすれば一つのサードパーティツールであり、気付けば人間にとってのdata lakeだったりします。 このようなサードパーティエコシステムの中で社会のツールやミドルウェアの奴隷にならないためには、同じく意見を言い合える芯が必要なのです。 設計を抽象化して理想を生み出し、それを実現する方法を考え、また壁にぶつかって理想をを調整する。これはアーキテクチャが上手くなる唯一の方法といえるでしょう。 USのエンジニアはこのAbstract roles to buildの能力に長けています。 それは、設計が抽象化されていればいるほど、結合が疎になるからです。それを体現した近年の一つの例が、マイクロサービスであるとも言えます。 Reactive Manifestoに代表される様々な抽象概念を経て、今尚「本当に作りやすいアーキテクチャとはなんなのか」を追い求めているのです。 またAbstract roleと前述したunknown（不明）の概念を理解すると、機械学習の挙動を容易にシステム・アーキテクチャに取り入れることができます。 こうして新しいキャラクターを持つ概念やインフラキャラクターが現れても、システム・アーキテクチャのベスト・プラクティスを見出す優れた方法を探し続けることが今のベスト・プラクティスそのものなのではないかと僕は考えています。作るメンバーを知る（社会の中で・チームの中で）
あなたの管理するシステムがPHPで作られていて、並列分散処理を実装しなければならない程度にサービスが伸びたとしましょう。 優秀なメンバーの中に「実はここはPHPではなくGoを書きたいんだ」という意見を持っているメンバーがいたとしたら、pthreadsではなくてGoを選ぶ価値が十分にあります。 優秀なメンバーであればあるほど「自然な環境」でコードを書きたいと願います。独特のガベージコレクト実装の中でメモリリークに怯えながら書く（最近は違うかもしれない）よりは、それに向いた言語の習得を選ぶ勇気を持つメンバーは、長期的にみてアーキテクトの掛け替えのない友となりえます。 また、逆にそうした勇気を持つメンバーがいない状態での「自然な環境」は、社会とシンクロしていないローカルな存在でありながら、それがそのチームにいとってのベストプラクティスである可能性が十分あります。 システム・アーキテクチャの正解は社会の中にのみ存在するものではありません。 それを共に運営していくメンバーの存在は、その何万倍も規模が大きい社会と同じくらい大きく、尊重すべき存在です。 そして、チームの中でアーキテクチャの話をする際に、上記の「Abstract roles to build」を忘れないようにしてください。 ここからずれなければ、議論はどこまで深めても有用なものになり得ます。不自由なエンジニアリングを認識する
最後になりました。（やっと書き終わる。笑） 上記のポイントを頭に入れたら、あなたにとって、チームにとって、不自由なエンジニアリングを探しに行きましょう。- より良いものを作ろうという活動の自由を奪うものを、不自由と呼ぶ。
- 自由なエンジニアリングは「より自然に作れる状態」を言う。
