生産におけるKubernetesの成功事例。 パート5：Monzo Digital Bank

Kubernetesの一連のサクセスストーリーは、英国のスタートアップバンクMonzoのストーリーに続きます。 この若い会社は「チャレンジャーバンク」に分類されています（はい、これはすでにOxford Dictionaryの用語です ） 。 大規模で老舗の金融業界に挑戦するような小さな銀行。 これは、最新の情報技術をその基礎そのもので積極的かつ広範囲に使用することにより可能になります。 従来の形式での操作を拒否して、電子的なカウンターパートを支持し、定性的にコストを削減できるようにします（このアプローチの銀行は「デジタルのみ」とも呼ばれます） 。 わずか2年前に作成されたMonzoの例は、Kubernetesプラットフォーム、Go言語、およびDevOpsエンジニアに馴染みのある他の最新のオープンソース製品を支援し、大きな目標を達成するのに役立つという点で興味深いものです。

Monzoとは何ですか？

元々モンドとして知られていたモンゾ社は、2015年に別の挑戦者銀行からの移民チーム-1年前に作成されたスターリング銀行によって設立されました-当時成功した起業家トム・ブロンフィールドは当時29歳でした。 Monzoを「（伝統的な）銀行が嫌いな人のための銀行」と位置付け 、創業者たちはすぐに聴衆を見つけることができました。







同年8月、Monzo は銀行としての公式活動の最初の（制限付き）ライセンスを取得し、2017年4月に制限が解除され、Monzoは「完全に認可された銀行」となり、ユーザーに決済口座を提供できるようになりました。 最初の真にアクティブな暦年（2016年）に、Monzo は 83,700枚のカードを有効にし、スタッフを16から71に増やしました。



エンドユーザー向けの同社のサービスは、iOSおよびAndroidのモバイルアプリケーションとして利用可能な電子銀行であり、Monzo銀行カードを使用して行われたすべての支払いに関するプッシュ通知をリアルタイムで受信します。 また、支払いが行われた場所を示すトランザクション履歴と、お​​金を受け取る会社の種類に応じたカテゴリの自動割り当ても保存します（このデータは、クラウドソーシングによる提案アプローチに従ってユーザー自身によって改善されます）。 （アプリケーションおよび銀行機能のより詳細な説明は、この資料の範囲外です。）



2016年8月、IDCアナリストは、Monzoが「（従来の）銀行が提供するすべての保証を提供し、国内の大規模な多国籍銀行と効果的に競争できる」という自信を表明したレポートを公​​開しました。

インフラストラクチャとソリューション

Monzoのソフトウェアアーキテクチャとそれを提供するインフラストラクチャに関する最初のかなり詳細な情報は、同社のエンジニアを率いるOliver Beattieのレポート「 その時点で10人がバックエンドエンジニアリングチームで働いていた 」のおかげで明らかになりました。 このパフォーマンスはKubernetes London Meetup（16年10月）で行われ、その後KubeCon 2016（16年11月）で行われました。



銀行の主要なアプリケーションの主な要因の1つとして拡張性を考慮して、同社のエンジニアはすぐにマイクロサービスアーキテクチャを選択しました。これは、「今だけでなく10年後にも変更できない1つの大きな「肥大化」アプリケーションを取得したくないという事実によって説明されています「そして、これはまさに、Monzoで呼ばれている「レガシーバンク」で起こることです。

「多くの大規模銀行のITシステムは、変更を行うのが高すぎるという意味で拡大していません。 たとえば、ボタンを押すことでアプリケーションのカードをフリーズする機能を考えてみましょう。 RBSの友人（スコットランドのロイヤルバンク、英国の4大銀行の1つ-約Transl）。この機会を何度も検討してきたが、20のITシステムには変更が必要であり、それらの一部の変更は何年も凍結されています。 最終的に、このアイデアは高すぎるため破棄されました。」

-Jonas Huckestein 、 Monzoの共同設立者兼CTO

Oliverのスピーチの時点で、同社には約150のマイクロサービスが生産されていました（コンテナにはDockerが使用されていました）。 その過程で遭遇した問題の1つは、アプリケーションのパフォーマンスでした。 マイクロサービスがほとんどない場合、各マシンでそれらをすべて複製するだけで十分でしたが、時間の経過とともに（マイクロサービスの数が増加するにつれて）このアプローチは機能しなくなりました。 その後、エンジニアはマイクロホストを特定のグループ（ アプリ 、 コアなど）に分割して別のホストに配布し始めましたが、このオプションも有効になりませんでした： アプリの計算能力が不足し、 コアのあるマシンがアイドル状態になったことが起こりました。 この段階で、MonzoのエンジニアはKubernetesを思いつきました。Kubernetesを使用すると、アプリケーションを開始し、必要に応じて簡単にスケーリングできる「共通のリソースプールを持つことができます」。 この変更がITインフラストラクチャのコストにどのように影響したかは、それほど興味深いものではありませんでした。







このグラフの赤で、以前のインフラストラクチャのコストがマークされ、管理対象のKubernetesの白でマークされています。 （AWSクラウドは、Monzoのインフラストラクチャアイロンとして使用されます。）



次の問題は、相互接続された多くのマイクロサービスで構成される複雑なシステムの柔軟性です。 最初は、RabbitMQに基づくキューを使用することで部分的に解決されましたが、このアプローチはKubernetes向けではなく、ここに示されている要件の数は大幅に増加しました。







これらの要件の一般的な本質は、ユーザークエリへの応答の遅延を最小限に抑え、答えを出す機会を最大限に成功させるように削減されました。 これらの目標を達成するために、 linkerd （このプロジェクトおよびここで記述 したソフトウェアクラスとしてのサービスメッシュについて）およびFinagleを選択しました 。



マイクロサービスが起動された各ホストには、ローカルリンカーインスタンスがインストールされ、ローカルマイクロサービスがリクエストでアクセスし、彼はすでにこのリクエストの送信先を決定するためにリンカーの残りに連絡しました。





GETリクエストがUnicorn HTTPサーバーに表示される場合のリンカーの使用の図



インフラストラクチャのさまざまなゾーンのネットワーク分離を確保するために、MonzoはCalicoおよびKubernetesネットワークポリシーを採用しています。 たとえば、「スーパーセキュア」ゾーンを使用して、銀行カードの全数を保存できます（この情報を「純粋な形式で」送信することは、ほとんどのサービスでは必要ないため、他のゾーンに存在できます）。



2017年3月に開催された既にヨーロッパで開催されている次のKubeCon会議では、Monzoの同じOliverが再び会社のインフラストラクチャでのKubernetesの使用について短い話をし、その時点で生産中のマイクロサービスの数が200に増えたと述べました。 そして、それらのほとんどすべてがステートレスカテゴリに属していました。ステートフルからは、Apache Kafkaのみが言及されました。 「Monzoでのリアルマネーの処理とKubernetes and Linkerd」というタイトルの彼のプレゼンテーションは、Buoyant（Oliver Gould）の同名によって続けられました。そのレポートの一部は、Monzoとの特異性ではなく、linkerdとの一般的な知り合いに焦点を合わせていました。



また、Monzoインフラストラクチャに関する最新の事実は、レポート「 CoreOSでインフラストラクチャを保護する 」（5月31日、CoreOS Fest 2017）で確認されました。

• Monzoのマイクロサービスの数は230に増えました。
• Apache Cassandra DBMSは、すべてのデータを保存するために使用されます。
• Vault（Cassandraバックエンドを使用）はシークレットの保存に使用されますが、すべてのデータがまだ転送されているわけではありません。
• 支払いシステムと通信するため（または、AWSとこれらのシステムと直接通信するコロケーションとの間）に通信するために、「コンテナインフラストラクチャに最適」なWireGuardベースのVPNが使用されます。

10月27日の大事件

このサクセスストーリーの軟膏のハエは、先月の終わりに発生したイベントによって追加されます。 要するに、Kunernetesの既知のバグと状況の組み合わせにより、Monzoでの生産は約80分間正しく動作しませんでした。



敬意は、Monzoコミュニティフォーラムで、同じオリバーがKubernetesについて最初に聞いた人でさえ説明で何が起こったかについて非常に詳細な事後分析を投稿したという事実です。 問題の本質は、インシデントの2週間前に、Monzoのエンジニアがetcdクラスターに変更を加え、ノード数を3から9に増やし、同時にetcdバージョンを更新し、その操作性を確認したことでした...しかし、更新されたサービスの次のロールアウトで奇妙なことが起こりました正常なバージョンにロールバックしても解決されなかったシステムの問題。



インフラストラクチャの操作における特定のイベントシーケンスに加えて、Kubernetesのバグ＃ 47131（特定のバージョンのetcd（まだ閉じられていない）で現れる）、linkerdのバグ＃1219 （linkerd 1.0のリリースで4月に閉じられた）がこの事件で役割を果たしました。 。 会社のエンジニアの運用作業と、事故が発生した場合の既存のプロセス/メカニズムは問題を最小限に抑えましたが、20分間の完全な単純な銀行プラットフォーム（および1時間以上の重大な問題）は、もちろん、このような「若者」のスタートアップにとっても容認できない間違いです。 しかし、このエンジニアリングポストに対するコミュニティの反応は、Monzoのオーディエンスのポジティブなムードにうれしく驚きました。Monzoのオーディエンスは、起こった後の会社のオープンさと誠実さを歓迎しました。

独自の開発

GitHubの Monzoアカウントで数十のリポジトリを見つけることができます。そのうちのいくつかはGoの独自開発です。 特に：

• typhon-マイクロサービス間の相互作用のためのRPCフレームワーク。
• slog-（各イベントのコンテキストと任意のキーと値のペアを考慮して）構造化された形式でログを受信し、それらをseelogに送信するためのライブラリ。
• phosphor -GoogleのDapperやTwitterのZipkinに似た分散トレースシステム。
• terrors-Golangエラーを追加情報でラップするためのパッケージ。

MonzoでのGoの開発方法の詳細については、今年3月にMonzo Distributed Systems Engineer（Matt Heath）が発表したレポート「 Go with bank with Go 」を参照してください。

要約する

10月30日の時点で、Monzoユーザーの数は 469千人でした。11月に終了した最後の投資により、71百万ポンドが会社にもたらされました 。これは、プロジェクトの大きな展望を示しています。



一般に、MonzoとKubernetesは同年代だけでなく、彼らが世界にもたらす価値によっても統一されており、今日多くの人が夢見たものや業界の論理的な発展を可能にします。 もちろん、10月の事件はどの銀行の評判にも影響を与えませんが、その後の反応から、この場合、自信の崩壊につながるよりもすぐに非常に才能のあるエンジニアのチームに新しい有用な経験をもたらすと結論付けることができます。

サイクルからの他の記事

• 「 Kubernetesの生産における成功事例。 パート1： eBayの4,200の囲炉裏とTessMaster 」
• 「 Kubernetesの生産における成功事例。 パート2： ConcurとSAP 。」
• 「 Kubernetesの生産における成功事例。 パート3： GitHub 。」
• 「 Kubernetesの生産における成功事例。 パート4： SoundCloud（著者プロメテウス） 。」
• 「 Kubernetesの生産における成功事例。 パート6： BlaBlaCar 。」
• 「 Kubernetesの生産における成功事例。 パート7： BlackRock 。」
• 「 Kubernetesの生産における成功事例。 パート8： Huawei 。」
• 「 Kubernetesの生産における成功事例。 パート9： CERNおよび210 K8sクラスター。
• 「 Kubernetesの生産における成功事例。 パート10： Reddit 。」