QCon ロンドンデジタル銀行 Monzo のソフトウェア エンジニアは、ロンドンで開催された QCon イベントで、同社が銀行システムを 1,600 のマイクロサービスで実行している方法と理由を開発者に説明しました。
QConでのMonzoのセッションは、月曜日のプレゼンテーションでサム・ニューマン氏がマイクロサービス・アーキテクチャは「最後の手段」だと警告したのとは対照的だった。シニアエンジニアのマット・ヒース氏とスハイル・パテル氏は、2015年に設立され、現在400万人以上の顧客を抱える同銀行にとって、マイクロサービスがどのようにうまく機能しているかを説明した。
大幅な成長を目指す新規事業として、Monzoは拡張性、拡張性、耐障害性、そしてセキュリティを備えたテクノロジープラットフォームを必要としていました。当初の構想は、いくつかの基本的な銀行サービスから始め、時間とリソースが許す限り、さらにサービスを追加していくというものでした。
Monzoは早い段階から分散システムの価値を確信していました。銀行は、複雑なフェイルオーバー機能を備え、決して稼働させなくて済むことを願うような、単一の大規模で堅牢なシステムを望んでいませんでした。
「フェイルオーバーモードを実際に使用しなければ、確実に動作しているとどうやって判断できるでしょうか？」とヒース氏は語った。彼らは当初、クラスタ管理にMesosを使用していたが、2016年には「新興市場のリーダー」としてKubernetes（K8s）に切り替えた。
目標の一つは、インフラの複雑さを抽象化することだった。「インフラの拡張、サービスのプロビジョニング、データベースの可用性の確保といった複雑な作業はすべて、特定のチームが担当するべきだと考えています。そうすることで、エンジニアは製品開発に集中できるのです」とパテル氏は述べた。システムはAmazon Web Services（AWS）上で稼働している。
Matt HeathとSuhail PatelがQCon Londonに登場
K8sは完全に問題がないわけではありません。2017年には、Monzoは「K8sとetcd、linkerdとの相互作用に問題があり、テストが非常に困難な複数のバグが重なり、大規模な障害が発生しました」とヒース氏は述べています。
Monzo が Cassandra をデータベースとして選択したのは、水平方向に拡張できるためです (つまり、より大きなシステムに移行する必要がなく、ハードウェアを追加するだけで拡張できます)。
コーディング面について、「私たちはGoを主要なプログラミング言語として使っています」とヒース氏は言います。「Goは非常にシンプルで静的型付けなので、採用しやすいのです。」Goは後方互換性が保証されているため、新しいバージョンがリリースされても既存のコードを再コンパイルするだけで、ガベージコレクタなどの機能アップデートのメリットを享受できます。また、Goはエラー処理に関する厳格なポリシーにも適しています。
「エラーを隠蔽していないか確認するために、静的分析を実施しています」とパテル氏は語った。
銀行システムはモジュール型のアプローチに非常に適しています。BACS、CHAPS、Visa、Mastercard、Apple Pay、Google Payなど、様々なシステムとの連携が求められます。「これらのシステムを個別のシステムとして追加することで、よりシンプルに保つことができます」とヒース氏は述べています。Monzoは、レジリエンスとパフォーマンスをより細かく制御するため（そして長期的にはコスト削減にもつながるため）、サードパーティの実装ではなく、可能な限り社内で統合を構築しています。社内およびサポート用に独自のチャットシステムも構築しています。
MonzoはAWSやK8sと連携するための独自のツールも開発しており、例えばShipperは個々のサービスをデプロイまたはロールバックできます。Shipperは、Gitリポジトリで管理されているコードの更新を表すプルリクエストから直接デプロイできます。
Monzoの各マイクロサービスはDockerコンテナ内で実行されます。「マイクロサービスの作成方法に関して、私たちの最大の決定の一つはアプローチでした」とPatel氏は述べています。共有コアライブラリはすべてのサービスで利用可能で、基本的にはすべてのコンテナにコピーされますが、ビルドプロセスによって未使用のコードは削除されます。つまり、「エンジニアがデータのマーシャリングなどのコア抽象化を書き換える必要がない」ということです。また、すべてのサービスでメトリクスが有効になっているため、デプロイ後すぐにCPU使用率やネットワーク呼び出しなどの分析結果がダッシュボードに表示されます。自動アラート機能により、パフォーマンスが低下したサービスを特定できます。
Monzoはあらゆるマイクロサービス内で利用できる広範な共有ライブラリを持っています
各サービスが公開するインターフェースやAPIには、多くの検討が凝らされています。チームは、少数の複雑なサービスではなく、それぞれが単一の目的に特化した多数の小さなサービスを作成することを好んでいます。「なぜこれほど細分化されているのでしょうか？ 変更のリスクを最小限に抑えたいからです」とパテル氏は言います。「例えば、非接触型決済の仕組みを変えたい場合、ICチップと暗証番号のシステムには影響を与えません。」
1,600ものマイクロサービスをラップトップで実行するのは不可能だとしたら、開発者はどのようにコードを開発するのでしょうか？「サブセットを実行していることになります」とヒース氏は言います。「現在実行されていないダウンストリームにリクエストを送信しようとしていることを検出し、コンパイルして起動し、リクエストを送信できるRPCフィルターがあります。」
マイクロサービスは、Monzoではうまく機能する一方で、複雑性を高めるだけでメリットがほとんどない場合もあるのはなぜでしょうか？The Registerは数多くのQConイベントに参加してきましたが、ソフトウェア開発のトレンドは年々変化していますが、変わらない点もあります。一つは、開発者がチーム内（そして経営陣と）でどのようにやり取りするかが、どのような開発手法を採用するかよりも重要であるということです。もう一つは、漸進的なアプローチが、時折の大規模な変更よりも優れているということです。「Monzoでは、反復的なプロセスを重視しています」とヒース氏は言います。「インフラストラクチャの観点からも、製品の観点からもです。小さな変更を頻繁に行うことで、正しい方向に進んでいることを確信できます。」
QConで繰り返し取り上げられるもう一つのテーマは、複雑さよりもシンプルさが優先されるという点です。Monzoのシステムは全体として非常に複雑ですが、その複雑さをより小さくシンプルな部分に分割し、コード開発を行う開発者の負担を軽減する形で設計されています。「1,600ものサービスがどのように機能するかを全て把握する必要はありません」とヒース氏は述べています。K8sの管理という困難な作業は、専門家に委ねられているのです。
ヒース氏によると、モンゾは「少数の技術選択肢」を標準化し、「グループとして、これらのツールを共同で改善できる」ようにしたという。これは、技術の好みが異なる開発者にとってはフラストレーションになるかもしれないが、全員が同じツールセットを習得するため、コラボレーションには大きく役立つはずだ。「コードは他の人間にとって読みやすくなければなりません」とパテル氏は述べた。「私たちは読みやすさを重視してコードを最適化しています。私たちのエンジニアリング原則の一つは、ボトルネックにならない限り（パフォーマンスを）最適化しないということです。」
Monzo が QCon で発表したものは、多くのコンポーネントを持つ複雑なシステムがあり、要件の変更や機能の追加に迅速に対応する必要がある場合のソフトウェア開発および展開のための強力なテンプレートであると思われます。
ヒース氏とパテル氏はマイクロサービスの価値を力強く主張しました。ただし、Monzoは多くのカスタムメイドの社内ツールやライブラリを使用しており、それらは容易に再現できないという点に留意してください。さらに、彼らが提示した原則の多くは、クリーンで読みやすく、規律のあるコードを書く、厳選された少数の技術に注力する、段階的なアプローチを採用するといったもので、あらゆるソフトウェアアーキテクチャにおいて成功の鍵となるものです。®
