分散システム構築の実体験から学んだこと

ソフトウェアアーキテクトや開発者として我々は今，分散の時代に生きている。分散システムの開発を簡略化するためには，我々が今いるビジネスの価値がどこにあるのか，というセンスを身に付ける必要がある。それができれば，リスクを取ることが妥当な場所とそうではない場所を理解することが可能になる。解決すべき問題にのみ取り組むことが必要だ – Stefan Tilkov氏とのインタビューで，Camille Fournier氏はこのような主張をした。

Rent the RunwayとGoldman Sachsにかつて在籍したFournier氏は，自身が好んで引用している，Leslie Lamport氏による分散システムの定義を紹介した。

分散システムとは，その存在さえも知らないコンピュータ障害が，コンピュータを利用不能にしてしまう可能性のあるものだ。

Fournier氏にとってLamport氏の定義は，障害の可能性を持ったごく小さな問題が，理由も分からないほど複雑なものになるという，まさに分散システムの核心を突いたものだ。

単にフローの中にネットワークが存在するという理由で，システムが分散システムと判断されることも少なくない。しかしながら，サーバとWebブラウザで構成されたシステムや従来型の3層アーキテクチャは，Fournier氏が一般的な分散システムとして定義するものではない。そのようなものは単に問題を複雑化しているだけだ，と氏は考える – 発生していない問題を心配する必要はないのだ。複雑なネットワークシステムを構築する場合であっても，それを構築して実現する上で，分散システムの世界の複雑さをすべて考慮しなくてはならない理由はない。

Fournier氏が考える，分散システムが問題として扱われるべき閾(しきい)値は，数多くのさまざまなシステムが本当に存在していて，それらを全体として実行しなくてはならない場合だ。サービスアーキテクチャ，特にマイクロサービス形式のアーキテクチャを扱う場合には，ある程度の複雑さは発生するにせよ，大規模な分散システムで起きる複雑性がすべて必要な訳ではない。分散システムはエンジニアリングの問題であると同時に理論的な問題でもある。つまりエンジニアリングの問題解決とともに，何らかの理論を適用することが必要なのだ。

Netflixほど大規模ではなくても，一定規模以上のソフトウェアを考える上で，それをマイクロサービスと呼ぶかどうかはともかく，サービスアーキテクチャは極めて健全な方法だとFournier氏は考えている。独立して運用可能なシステムのエンティティを検討してサービスに分割し，数十人の開発者によって個別の開発とデータ所有を行う方法には，大きな価値の可能性がある。モノリスが本質的に間違っているとは言わないが，それが必要であるということに加えて，クラウドによって構築が容易になったことも，分散システムが増えている理由のひとつだと氏は指摘する。

複雑化の原因は状態の管理にある。Fournier氏の指摘する，分散システム開発を考える上で重要な側面のひとつは，データの紛失や状態の不一致を防止する上で，統一性や一貫性をどのように考慮するかという点である。この問題で氏が利用するのは，トランザクションと従来型のリレーショナルデータベースだ。すべてのオーダが入力されたことを確認したいような場合が，そのような処理の一例になる。その他の，古いデータを参照しても大きな問題ではない，多少古いデータを参照しても不都合がない，データを失っても簡単に再生できるなどの状況であれば，一貫性はさほど気にする必要はない。このような部分にはNoSQLデータベースが便利だと氏は考えている。