株式会社オライリー・ジャパン主催の「マイクロサービスアーキテクチャ」出版記念イベントで数年ぶりに人前で話してきました。
制限時間 20 分で Microservices を語るのは厳しいと判断し、自分のトークは開発現場でありがちな面白い話や、Microservices の難しさなどのトピックに絞りました。
どの帽子をかぶるべきか
Microservices を人前で語るときは、どの帽子をかぶるべきかで悩みます。
ひとりのエンジニアとしては、必要がなくても Microservices アーキテクチャに手を出したくなります。自宅で無駄に巨大なファイルシステムを構築して、ニヤニヤするのと似た感覚ですね。対して、例えば生まれたてのプロダクトを育てる立場だと、手間のかかる Microservices アーキテクチャに否定的になるでしょう。
今日の正解は明日の不正解
テクノロジー業界は動きが速く、システムというものは状況の変化に弱いものです。例えば、ひとつの大きな案件によってプロダクトの前提が変わってしまうのはよくあることです。エンジニアが心底嫌うやつですね。プロダクトがうまくいっていると、必ずこういう状況に遭遇します。したがって、過去の選択を後悔せず、常に頭を柔軟にしながら、前に進むのが大事という話をしました。
流行るものは流行る
Microservices アーキテクチャを採用したからといって、プロダクトは流行りません。まずは頑丈なユーザベースを築き、成長軌道に乗ることが最優先です。そういったステージでは、モノリシックな設計のほうが圧倒的に合理的です。ステージによって、そのとき最良と考えられる手を打ちながら前進しましょう。
最初から 100 万人を快適にサーブできるシステム開発に尽力しても、そこに到達するよりもチームが解散する確率の方が高い、という論点に似ていますね。
キラキラネーム現象
Microservice は API が公開されるだけであって、プロジェクト名やリポジトリ名が外部に露出することがありません (たまにエラー出力で漏れてる会社もありますが)。したがって、エンジニアやアーキテクト間の利便性のために、コードネームが Microservice に割り当てられます。自分の観測範囲内だと、コードネームは作者やチームの趣味で、面白い名前がつけられがちです。
Fastly の場合、創業者がスキー好きなので、初期から存在する Microservices には、スキーリゾートの名前がつけられています。最近はいろいろです。
モニタリングの重要性
Microservices アーキテクチャは動くパーツが多いので、モニタリングが極めて重要です。John Lewis と Martin Fowler を引用しつつ、Datadog や New Relic などの紹介をしました。Fastly は社内でもいろんなモニタリングが実装されています。
開発環境
とてもディープなトピックです。プログラマの日常的な視点から考えると、ある瞬間の興味対象の Microservice って、担当プロジェクトに関連するひとつやふたつだけではないでしょうか。とはいえ、依存している Microservice (たとえば監査サービスなど) があると、動作確認ができなくて困ります。したがって、良い感じに自動で開発環境が構築される仕組みがあると生産的という話をしました。
Fastly では、エンジニアはほとんど Mac を使っていて (一部 Linux)、仮想マシン上に複数の LXC がたっている環境で開発しています。各 LXC がサービスを表すノードということになります。この開発環境は専門のチームがメンテしてくれていて、困ったことがあるとチャットで助けてくれます。
レジリエンスのテスト
プログラマからすると、ある Microservice がどこで動いているかは本来どうでもいいことです。例えば、同じホスト内、別ホスト、別 IDC などです。Microservices アーキテクチャは動いているソフトウェアが多かったり、外部要因 (物理障害など) によって、影響を受けやすいという話をしました。
上記の理由から、Microservices アーキテクチャでは、レジリエンス (回復力) のテストが極めて重要になってきます。レジリエンスのテスト手法として、Shopify が公開している toxiproxy という簡易的にネットワーク環境をエミュレートする仕組みや、Netflix の Chaos Monkey や Chaos Kong といった常識はずれのテスト手法を紹介しました。
Fastly の Polyglot な環境
以前このブログで紹介したように、Fastly ではいろんなプログラミング言語を活用して全体的なシステムを構築しています。結論からいうと、狙ってそうなったのではなく、必然的に複数の言語が活用される環境になったのではないかと自分は考えています。
Fastly は適切な言語とテクノロジーを活用しています。たとえばスループットが死活問題なリアルタイム・ログ処理などの課題に、表現力が豊かなものの、計算速度に劣る言語を選択する理由はありません。逆に、ウェブ関連の文字列操作や、テンプレートエンジンを使い倒す課題には、スクリプト言語の方が理にかなっています。健全な Microservices の成り立ちと、あり方ではないかと思います。
プロダクトの性質との相性というのもありそうです。
大事なこと
Microservices という言葉をよく耳にするようになったものの、結局はアーキテクチャのひとつです。万能なアーキテクチャは存在せず、誤った選択は逆に技術者の生産性や幸せ度を低下します。Microservices も例外ではありません。大事なことは、自分や仲間にとってのメリットを冷静に考えて、合理的な選択をすることではないでしょうか。
Microservices Casual Talk はソフトウェア開発のむずかしさや、奥の深さを再確認できた良いイベントでした。これを機にもっとイベントに顔を出していければと思います。