Yakstは、海外の役立つブログ記事などを人力で翻訳して公開するプロジェクトです。
5年弱前投稿

私のモノリスを返して

マイクロサービス化のトレードオフと、筆者がモノリスを愛する背景

原文
Give me back my monolith - Craig Kerstiens (English)
翻訳依頼者
D98ee74ffe0fafbdc83b23907dda3665 907f339337a8fe2a4d4c498d1545231b
翻訳者
A3e9a72544c34898bde469ab10cddc25 meiq
翻訳レビュアー
D98ee74ffe0fafbdc83b23907dda3665 doublemarket
原著者への翻訳報告
1801日前 Twitterで報告済み 1801日前 原著者承諾済み 編集


どうやら、マイクロサービスの話題の盛り上がりはピークを過ぎ始めているように感じます。「モノリスを150個のサービスへ移行した話」みたいなブログ記事を、週に何度も見かけるようなことはなくなりました。最近よく聞くのは、むしろ「モノリスが嫌なわけなんじゃなくて、性能をいい感じに保ちたいだけなんだ」といった話です。実際に、マイクロサービスをモノリスに戻す移行事例も見たことがあります。

大きな一つのアプリケーションをいくつもの小さなサービス群へ持っていくためには、たくさんの新しいことに取り組まなければなりませんし、かつてはシンプルだったけれども改めて見直さなければならなくなっている諸々の事柄を、ここに挙げていきましょう。

入門化学から量子力学レベルになってしまったセットアップ

基本的なデータベースと自分のアプリケーションをバックグラウンドプロセスと共にセットアップすることは、極めて定型的なプロセスでした。Github上にreadmeがあれば、たいてい一時間ないし二、三時間もあれば新しいプロジェクトを立ち上げられたものです。エンジニアリングの新人研修をやっても、少なくとも初期環境に関する内容なら初日に終わりました。

それがマイクロサービスへ足を踏み入れるにつれ、研修に必要な時間は激増しました。もちろん、最近はDockerやK8sのようなオーケストレーションツールが助けになりますが、新人エンジニアの研修用にゼロからK8sクラスタを稼働させるまでにかかる時間は、数年前と比較して桁違いに増えています。多くの新人エンジニアとって、実のところこれが、必要以上に複雑な負担になるのです。

自分たちのシステムを理解するのにどれほどかかるのか

しばらく、このまま新人エンジニアの視点で見ていきましょう。

アプリケーションがモノリシックだった頃は、エラーが起きたらどこから発生したのかが分かる明快なスタックトレースが出て、すぐにデバッグに取りかかれたものです。それが今では、とあるサービスが処理するメッセージ通路上に何かをキューイングするサービスがあり、さらにこのサービスと会話するまた別のサービスがある、そんな状況下でエラーが見つかったりします。

これら全てをパズルのピースのように一つ一つ組み合わせてようやく、サービスAはバージョン11だったけれどもサービスQは既にバージョン12であることを期待していた、なんてことが分かるのです。標準的で集約されたログがあり、インタラクティブなターミナルやデバッガーで好きなだけステップ毎にプロセスを解析できた頃とは対照的です。

デバッグすること、理解することは、いまや本質的に複雑になっています。

デバッグができなくても、たぶんテストはできるけど

継続的インテグレーションと継続的な開発は、ごく普通のことになりつつあります。最近見かけるたいていのアプリケーションは、新しいプルリクエストが来れば自動的にビルドしてテストが走り、チェックイン前にはテストの通過とレビューが必要です。これは素晴らしいプロセスで、多くの組織に大きな変化をもたらしました。

しかし、真の意味でサービスをテストしようと思ったら、完全に動作するバージョンのアプリケーション全体を持ってこなければなりません。150個のサービスからなるK8sクラスタを新人研修で扱う話を覚えていますか? そう、どうやってそのシステム全体を立ち上げて、どうしたら実際に正しく動作しているかテストできるのかをCIのシステムに教えこむ必要があります。おそらくそれでは労力がかかりすぎるので一つ一つの部品を切り離して別々にテストするわけですが、この手法をとるからには、仕様がぬかりなくAPIが万全で、サービスが落ちてもきっちり分離されているから他に影響を与えない、という前提でないといけませんよね。

トレードオフにはもっともな理由があるはず、ですよね?

マイクロサービスに移行する理由はたくさんあります。聞いたことがあるのは、よりアジャイルにするため、チームをスケールするため、パフォーマンスのため、より柔軟サービスにするため、といった理由です。けれどもそれは、今でも成熟を続けているモノリス界隈の開発手法とツールに数十年が費やされてきた現実と同じことです。

私は職場で、多くの異なるスタックの仲間たちと働きます。たいてい私たちの話題はスケーリングに関することになるのですが、それは彼らがシングルノードのPostgresデータベースの限界に直面しているからです。私たちの会話のほとんどは、データベースをスケールさせることに焦点を当てています。

ですが、そんな会話の中でも、私は彼らのアーキテクチャを学ぶことに魅力を感じます。彼らはマイクロサービス化とは無縁でしょう。実際「私たちはモノリシックなアプリケーションでいいんです」という反応を見る機会が増えているのは興味深い傾向です。

多くの人にとってマイクロサービスへの道のりは結構なもので、そこに至るまでの苦労を上回る利益が得られるのかもしれませんが、私個人としては、モノリシックなアプリが手元にあって、どこかのビーチにでも居られればそれで満足なのです。

次の記事
MySQLの準同期レプリケーションに関する質問への回答と詳細
前の記事
CharsetとCollationの設定がMySQLのパフォーマンスに与える影響

Feed small 記事フィード

新着記事Twitterアカウント