Webサービスの大がかりなアーキテクチャ更新を進めており、山を越えつつある。
既存サービスの互換性を維持しながら部分的に差し替える必要があり、着手から2年近くかかっている。
論点はいくつもあるが、分かりやすいのは脱Railsの側面だろう。
ここまでは Ruby on Rails のマイクロサービス群を作ってきた。これはコード構成の面では効果があったが、けっきょくミドルウェア以下のインフラ面で限界を迎えた。
プロダクト数はどのような制約を受けるのか
1つには、サービス間の互換性の維持が難しい。直面したのはセッションの互換性で、ライブラリのバージョン統一を継続しないといけない。
マイクロサービスの目的として、個別にメンテナンスを進めても他サービスに影響がなく、順次進化していけることを求めていた。しかし主にセキュリティ面の要求で、サービス群の一括更新が避けられない展開がありうる。
セッションアルゴリズム変更のケースは、不具合を発見しだい即座に修正リリースで乗り切ったが、不具合は出ていたしユーザーからの問い合わせもあった。
サービスの数を増やしていけば、いずれ対応不能に陥るのは間違いない。
もう1点はリソース消費、とくにRAMのフットプリントがネックになってきた。
kubernetesの浸透により、インフラの潮流はコンテナになった。帰趨は決しているものの、まだ品質が万全ではない面がありリソース管理は注意を要する。
RAMを使い切れば新規コンテナが起動しないため、もちろん新サービスを投入できない。ただ、実際にはそれ以前に挙動が不安定になる。
顧客サポートのためrails consoleを起動したらサービスがクラッシュしたことがある。
操作したRailsコンテナだけがクラッシュするならまだマシだ。期待と異なり、サーバーノード上の全コンテナがクラッシュする展開となった。
もちろん即座にコンテナ再構成が走るので、大局的に見れば堅牢ではあるものの、局所的には脆弱きわまりない。
移行先は何ら確立していない
これまで選択していた技術がRailsだったからRailsの限界を観測しているが、Railsに限った問題ではない。
VM上で動作する言語やリッチなオブジェクトを生成する言語は、程度の差こそあれメモリ肥大化やランタイムのガベージコレクションがある。
よって、Python, PHP, Java, Go, C#などを避け、基本的にRustを採用することとした。
すでにいくつかのサービスを置き換えており、Rustベースのサービスは極めて快調と言える。
Rustの難点は、ライブラリが出揃っていない点だ。
低レイヤのツールチェインは完備しており腕前があれば何でも可能だが、すべてのエンジニアに使いこなせる設計力があるわけではないだろう。
現時点でRustを選択するということは、自らコンプリートしなくてはならない選択でもある。
莫大なローンを抱えるかわりに、分割払いをとれるようなものだ。
ただこれは僕が、代表取締役という何からも保護されていない存在だから可能な選択でもある。
従業員には労働時間の規制がかかっているため、時間内におさまらないような技術選択は日本では不可能になったのかもしれない。
田舎化が進行する日本
ここまでは分かりやすさのため、脱Railsと言ってきた。
これは一面であり、アーキテクチャ移行は総合的に設計している。たとえば、一般的なWebフレームワークが採用しているMVC(Model-View-Controller)やO/Rマッパーも併せて捨てた。
全体的に説明を割愛するが、ネイティブアプリと同様のアーキテクチャに誘導している。
Rustに限らず、MVCから出ると情報がないため、一つひとつパーツ別に設計する必要がある。
情報は乏しいのだが、乏しい中にも日本はさらに立ち遅れている印象は強い。
いくつかのキーとなるミドルウェアについて、要素技術に関する情報すら日本語では存在していない。
ひとつには、ひと昔前のWeb2.0ブームを最後に出版業界がどうやら技術書を出せなくなっていて、入口を見失っている。
ただ単に買われないから無くなったのだろう。この間、マンガの電子書籍市場が立ち上がっている。
「ソフトウェア技術は英語を前提とするスキルである」という要因が強まったに過ぎず、日本人は学生時代に英語をたくさん学んでいるので、とくに問題はない。
ただ、アウトプットの質を見る限り、実際にはこのスキル獲得プロセスには何か大きな欠陥があるのだろう。
水面下で問われる設計能力
願わくば、いま手がけているアーキテクチャがある時点で主流になって欲しいと考えている。
そうならなければ、もう一度やり直す。ただ、やり直せるかは別問題だ。
おそらくJavascript上にRails相当のフレームワークが確立した方が良い。いまのところ展開がよれていて、まとまりを欠いている。
DartがJavascriptを置き換えたかった動機は、まだ課題としてそのまま残っているのだろう。
要するに、Webサービスの技術は過渡期であり、おそらく決定版はまだ出てこない。
米国などの大規模サービスの個別実装を参考に、各自ホーミングすべき状況なのだと考えている。
ロードマップの面で難しいのは、コモディティスキルのMVCフレームワークがプロダクトの最終形と連続性がないケースだろう。
長い目で見れば、少なくとも2つの異なるサービスを開発し、互換性のレイヤを追加して移行することになる。
展開を見通すためには、フルスタックの各レイヤについて深く理解することが第一の前提条件と言える。
