モノリスのカテゴリ

この数年の間に，多数のマイクロサービスをめぐる記事が公開された。さまざまなアンチパターンをめぐるものやモノリスとの関連性，マイクロサービスアーキテクチャへの移行において注意すべき点など，その内容はさまざまだ。マイクロサービスを使ったアプリケーション開発をスクラッチないし白紙状態から始める開発者もいるが，既存のモノリシックなアプリケーションの分解手段として，マイクロサービスの採用を検討する場合も多い。それに関する経験談を語ってくれた人たちはこれまでもあったが，先日Derek C. Ashmore氏は，(おそらくは)マイクロサービスとして実装可能な，より管理性の高いコンポーネントに分解する方法を議論する前提として，モノリスの分類を試みた。

モノリスとは，規模が大きくなり過ぎて効果的な管理ができなくなったアプリケーションのことです。つまり，拡張や修正が困難なものです。モノリスの修正は，時として予期しない結果をもたらします — 何かを変えると，他のどこかが壊れるような状態なのです。モノリスは特定の技術に強く結び付いており，新たな技術の進化と成熟の追求を困難にします。基礎となるモノリスコードのサイズと複雑さゆえに，新メンバの参加は(覚えることが多過ぎるために)高価で時間の掛かる作業になります。こうした開発面の特徴から，ビジネスの面では，選択肢としてのアウトーソーシング移行が制限を受けることになります。

それでは氏の定義したカテゴリの内容を見てみよう。氏は前述のような特徴について，単一のモノリシックアプリケーションに共通するものだと述べている。最初に氏があげるのは，“機能過剰なWebアプリケーション”だ。

このタイプのモノリスはWebアプリケーションに特有のものです。新たな機能が加えられる度に，アプリケーションは大規模で複雑なものになります。そのような新機能のいくつかは，アプリケーション設計時には考慮されていなかったものであるため，結果として粗雑に“後付けされる”ことになり，アプリケーションの初期設計に適合しなくなっています。通常，保守やサポートが容易な方法で新機能を追加できるように，アプリケーションを再設計するような時間や予算はありません。この結果は多くの場合，不要な結合性という技術的負債になります。

氏はこのカテゴリの一般的な理由と，その影響についても説明している。新機能の追加によるアプリケーション全体の複雑性の増加はそのひとつだ。

新機能はユーザインターフェースだけでなく，そのインターフェースを支えるサーバ側のバックコードや，基盤となるデータベースにも影響を与えます。それらのバックコードとデータベースは，ユーザインターフェースと密接に結合していることも少なくありません。現在のインターフェースで実装しているものがビジネスプロセスである，という“前提”がそこにあります。

さらにモノリシックなアプリケーションでは，特定の機能の使用状況の測定や追跡は行われていないのが通常だ。

その結果，機能は追加されるのみで，削除されることはありません。利用されない，あるいはほとんど利用されない機能は，そのコードを保持することによる複雑性が，将来的に新たな機能を追加する上で負の影響を与えることを考慮すれば，理屈の上からは削除すべきものです。しかし残念なことに，機能を削除することのメリットを測るのは難しく，説明も困難であることから，ほとんどの組織では予算の獲得が難しいというのが実情です。

次のタイプのモノリスは，”データストアの抑圧”だ。

データベース(リレーショナルおよび非リレーショナル)は古くから使用されているにも関わらず，データベース設計のスキルは，ほとんどの組織ではまったく不十分です。その結果が，プロセス指向のデータベース構造に現れます。つまり，データベースをサポートするアプリケーションが，現時点で実装しているプロセスに特化したデータベース構造になるのです。

マイクロサービス開発においてデータが難しい部分であることは，以前にもChristian Posta氏が指摘しているが，それがモノリス化の要因のひとつであり，分離の難しい部分であるという点では，氏も意見を同じくしている。氏が言うように，データベースのリファクタリングはアプリケーションのリファクタリングに比較すると難易度が高く，時間を要することが少なくない。

データベースのリファクタリングでは，通常は既存コードのサポートを維持しなくてはなりません。同時にデータベースのリファクタリングでは，その一環としていくつかのデータ型を変換する必要があります。その一方で，コードは一時的な状態を保持するに過ぎません。つまり，その状態は実行時のみ存在するのです。データベースの状態は永続的ですから，データベースを変更する場合は，新しい形式で格納されたデータの変換も同時に行なう必要があります。

さらに氏の経験からは，データベースのリファクタリングはコードのリファクタリングよりもリスクの高い場合がある。リファクタ実施後に問題が発覚したとき，リファクタ後に入力されたデータを失うことなく，データベースを元に戻す手順が複雑であるためだ。ほとんどの組織において，データの紛失は許容される選択肢ではない。

氏のあげた最後のカテゴリは“スペック過剰のtarボールコンポーネント”である。これは氏が，実行中のタスク達成を開発者が“退屈に感じて，面白そうなものを必要以上に探す”ような態度を批判的に指摘したものだ。当初の開発者が業務を離れた場合に，これが波及効果を生み出すことになる。このような態度で追加された複雑性が，その開発者の頭の中だけで理解(および文書化)されていることで，コードの維持が困難になるのだ。

以上のものが，今日までに氏が体験したモノリスのカテゴリである。今後のブログ記事では，こういったモノリスをより扱いやすいコンポーネントないしアプリケーションに分割する方法について取り上げることを考えている。そうなれば我々もそれを試してみて，フォローアップ記事を公開したいと思う。