読者です 読者をやめる 読者になる 読者になる

Anonymous Function

tmaesaka の lifelog | カルチャー、ときどきテクノロジー

Microservices Casual Talks で話してきました

株式会社オライリー・ジャパン主催の「マイクロサービスアーキテクチャ」出版記念イベントで数年ぶりに人前で話してきました。

travis-luna

制限時間 20 分で Microservices を語るのは厳しいと判断し、自分のトークは開発現場でありがちな面白い話や、Microservices の難しさなどのトピックに絞りました。

どの帽子をかぶるべきか

Microservices を人前で語るときは、どの帽子をかぶるべきかで悩みます。

ひとりのエンジニアとしては、必要がなくても Microservices アーキテクチャに手を出したくなります。自宅で無駄に巨大なファイルシステムを構築して、ニヤニヤするのと似た感覚ですね。対して、例えば幼いプロダクトを育てている立場だと、手間のかかる Microservices アーキテクチャに否定的になるでしょう。

今日の正解は明日の不正解

テクノロジー業界は動きが速く、システムというものは状況の変化に弱いものです。例えば、ひとつの大きな案件によって設計の前提が変わってしまうという話は、テック業界ではよくあることです。エンジニアが心底嫌うやつですね。プロダクトがうまくいっていると、必ずこういう状況に遭遇します。したがって、過去の選択を後悔せず、常に頭を柔軟にしながら、前に進むのが大事という話をしました。

流行るものは流行る

Microservices アーキテクチャを採用したからといって、プロダクトは流行りません。まずは頑丈なユーザベースを築き、成長軌道に乗ることが最優先です。そういったステージでは、モノリシックな設計のほうが圧倒的に合理的です。ステージによって、そのとき最良と考えられる手を選びながら前進しましょう。

最初から 100 万人を快適にサーブできるシステム開発に尽力しても、そこに到達するよりも先にチームが解散する可能性の方が高い、という論点に似ていますね。

キラキラネーム現象

Microservice は API が公開されるだけであって、プロジェクト名やリポジトリ名が外部に露出することがありません (たまにエラー出力で漏れてる会社もあるけど)。したがって、エンジニアやアーキテクト間の利便性のために、よくコードネームが Microservice につけられます。自分の観測範囲内だと、コードネームは作者やチームの趣味で、面白い名前がよくつけられています。

Fastly の場合、創業者がスキー好きなので、初期から存在する Microservices には、スキーリゾートの名前がつけられています。最近はいろいろです。

モニタリングの重要性

Microservices アーキテクチャは動くパーツが多いので、モニタリングが極めて重要です。James LewisMartin Fowler を引用しつつ、Datadog や New Relic などの紹介をしました。Fastly では迅速に障害に対応するために、社内でもいろんなモニタリングが実装されています。

開発環境

とてもディープなトピックです。プログラマの日常的な視点から考えると、ある瞬間の興味対象の Microservice って、担当プロジェクトに関連するひとつやふたつだけではないでしょうか。とはいえ、依存している Microservice (たとえば監査サービスなど) があると、動作確認ができなくて困ります。したがって、良い感じに自動で開発環境が構築される仕組みがあると生産的という話をしました。

Fastly では、エンジニアはほとんど Mac を使っていて (一部 Linux)、仮想マシン上に複数の LXC が立ち上がっている環境で開発しています。各 LXC がサービスを表すノードということになります。この開発環境は専門のチームがメンテしてくれていて、困ったことがあるとチャットで助けてくれます。

レジリエンスのテスト

プログラマからすると、ある Microservice がどこで動いているかは本来どうでもいいことです。同じホスト内、別ホスト、別 IDC などです。しかも、Microservices アーキテクチャは動いているパーツが多かったりなどで、外部要因 (物理障害など) による影響を受けやすいアーキテクチャです。

上記の理由から、Microservices アーキテクチャでは、レジリエンス (回復力) のテストが極めて重要になってきます。レジリエンスのテスト手法として、Shopify が公開している toxiproxy という簡易的に厳しいネットワーク環境をエミュレートできる仕組みや、NetflixChaos MonkeyChaos Kong といった常識はずれのテスト手法を紹介しました。

Fastly の Polyglot な環境

以前このブログで紹介したように、Fastly ではいろんなプログラミング言語を活用して全体的なシステムを構築しています。結論からいうと、狙ってそうなったのではなく、必然的に複数の言語が活用される環境になったのではないかと自分は考えています。

Fastly は課題に合わせて適切な言語とテクノロジーを活用しています。たとえばスループットが死活問題なリアルタイム処理などの課題に、表現力が豊かなものの、計算速度に難のある言語を選択するメリットはありません。逆に、文字列操作や、テンプレートエンジンを使い倒すウェブ系のプロジェクトには、スクリプト言語の方が理にかなっています。健全な Microservices の成り立ちと、あり方ではないかと思います。

大事なこと

Microservices という言葉をよく耳にするようになったものの、結局はアーキテクチャのひとつです。万能なアーキテクチャは存在せず、誤った選択は逆に技術者の生産性や幸せ度を低下します。Microservices も例外ではありません。大事なことは、自分や仲間にとってのメリットを冷静に考えて、合理的な選択をすることではないでしょうか。

Microservices Casual Talks はソフトウェア開発のむずかしさや、奥の深さを再確認できた良いイベントでした。これを機にもっとイベントに顔を出していければと思います。

関連リンク