LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog

Blog


非同期を愛するオープンソース開発者、イ・ヒスンさんにインタビュー

Q. こんにちは。まず、簡単に自己紹介をお願いします。
A. こんにちは。LINEでArmeriaCentral Dogmaのようなオープンソースソフトウェアを開発しているイ・ヒスンです。LINEに入社する前は、Twitterで働いていました。Twitterでは、オープンソースソフトウェアであるNettyの、メンテナンスや新しい機能の開発、次のバージョンの開発を担当しました。

Q. イ・ヒスンさんは、Nettyプロジェクトでオープンソース開発者として有名になりました。そのNettyプロジェクトの近況はどうですか?
A. Nettyプロジェクトのリード役は、今Appleに勤めているNormanという方にバトンタッチしました。長い間プロジェクトを一緒に手掛けてきた方なので、スムーズに運営できていますね。まだ、Nettyには私の作業した部分がかなり多く残っています。そのため、時間のあるときは主なPR(Pull Request)をレビューする程度ですが、Nettyプロジェクトに参加しています。

Q. そうなんですか。では、今もレビューしていないPRが溜まっているんでしょうか? 
A. PRはいつも溜まっています(笑)。Nettyは、ローレベル(low level)のプロジェクトで、シニア開発者の参加が多いですね。シニア開発者は、PRレビューにかなり時間がかかったり、プロジェクトの方向と合わないPRは断られる可能性があったりするのを、ある程度認識しています。以前に比べると、はるかに多くの開発者がオープンソースプロジェクトの開発プロセスについて理解しているようです。

Q. イ・ヒスンさんは、LINEとTwitterで「会社に所属しているオープンソースプロジェクト管理者」として働いてきましたね。オープンソースプロジェクト管理者として正しいと考える方向と、会社が目指しているオープンソースの発展方向が食い違ったときに、中立を保つのが難しいときはありましたか?
A. 最近の会社は、純粋にエンジニアリングの観点からオープンソースソフトウェアに関わることが多くなっています。どのような方法でオープンソースソフトウェアに技術的な変化を適用するかについて、「会社に所属しているオープンソース開発者」にかなり高い自由度を与えています。そのためか、中立を保つのにそれほど苦労した記憶はありません。

Q. 企業がオープンソース開発者をわざわざ直接採用する理由はなぜだと思いますか?
A. 実は、オープンソースプロジェクトには誰もが貢献できます。オープンソース開発者を直接採用しなくても、PRを送る方法などで必要な機能が実装できますね。実際、私がTwitterに入社する前に、Twitterの他のエンジニアが、NettyにSPDYプロトコルを実装する貢献をしました。つまり、厳密に言えばオープンソースに必要な機能を実装するために、開発者を直接採用する必要はありません。でも、現実的にはオープンソースソフトウェアと同じ分野で有能な開発者を見つけるのはなかなか難しいので、企業としても、誰かを採用するなら、今そのプロジェクトに参加している人を採用したほうが当然いいでしょう。Twitterに勤めていた時、社内のエンジニアから要望があって非同期DNS(Domain Name System)クライアントやSOCKSプロトコルのような機能を実装したことがあります。そのときのことを振り返ってみても、該当する専門家を直接採用して、特定機能の開発を先にお願いできることが、オープンソース開発者を直接採用することで得られる大きなメリットだと思います。

Q. 以前のオープンソースプロジェクトでは、コミュニケーションツールとして伝統的なメーリングリストを使っていましたが、最近はいかがですか?
A. オープンソースプロジェクトごとに少し違うと思いますね。歴史の長いプロジェクトでは、今もメーリングリストを使っていますが、最近のプロジェクトではあまり使っていないようです。最近は、SlackGitterを多く使っているようで。現在Nettyでは質問をStack Overflowに書き込むように案内していますね。 Armeriaでは、質問があったらGitHubにissueを作成するように案内しています。issueを作成すると、私かプロジェクトメンバーがそのissueに「question」というラベルを付けて、誰でも簡単に質問をまとめて確認できるようにしておきます。プロジェクトがさらに大きくなったら他の方法を考えますが、issue tracker本来の機能を損ねるほどではないので、まだこの方法で大丈夫だと思います。

Armeria GitHubのissue trackerで確認できるquestionラベル

Q. オープンソースプロジェクトに参加して大変だったことがあれば教えてください。
A. まれに短時間で成功するプロジェクトもありますが、ほとんどは成功まで長い時間がかかります。Nettyだけを見ても、プロジェクトがある程度軌道に乗るまでかなりの時間がかかりました。Apache MINAの後を継ぐものとして注目を集めたにも関わらず、ユーザーが十分に増えるまで数年かかったので。地道に進めるのが本当に大事だと思います。

Q. お仕事を「コーディング」「コードレビュー」「その他」に分けるとしたら、どのように時間を割り振っていますか?
A. 私は、「コードレビュー」に最も時間を割いています。その次が、「コーディング」ですね。

Q. そうなんですね。コードをレビューする時は、主にどのようなコメントを残すのですか?
A. 私は、全体の構造から切り出して具体的にリーダビリティーを最適化する方向でコメントします。リーダビリティーについては、コードがきれいに見える(リーダビリティーの良い)コーディングの仕方をコメントしたり、ネーミングやインデント(字下げ)の規約についてコメントします。それからもう一つ、エラーメッセージにも規約がありますね。このライブラリーを利用すれば、エラーメッセージがこのような形で出る、という一種の暗黙的なルールがあるんです。ルールとは違う形でエラーメッセージが出たら、ユーザーが戸惑うかもしれないので、エラーメッセージの規約についてもコメントを残します。

Q. コードをレビューする中で、意見が食い違ったらどうするんでしょうか?
A. 普段お互いの意見が食い違う場合、「agree to disagree」と言いますね。あなたと私がお互い違う意見を持っていることに同意する、とのことです。2つの意見にそれぞれ長短があるので、できるだけ話し合って技術的には一つの選択をします。もちろん、心の中では「それでも私はこっちが正しいと思うけど、あなたがそう言うなら…まあ…」と思ったりします(笑)。

Q. 私は文章で意見を交わしていると、顔を合わせて話したほうがスムーズに進むのでは?と思う時がたびたびありますね。ヒスンさんはどういうタイプですか?
A. 私は顔を合わせて話すよりは、きちんと文章にまとめたうえで議論するのを好みますね。直接話すと言葉に詰まったり、まともな文にならないこともありますので。そして、オープンソースプロジェクトに参加する全員が、英語によるリアルタイムのコミュニケーションが得意でもないし、その場にいなかった人は後でどんな議論が交わされたか分からないところもあるんですね。仮に、顔を合わせて何かを決めたとしても、結局は文章にまとめておく必要はあります。特に、オープンソースプロジェクトのようなコミュニティーでは、こうした透明性が保証されないとうまく運営できないと思います。

Q. 本格的にArmeriaについて話す前に、一つ軽い質問をしたいです。開発者の趣味は開発という話がありますが、いかがでしょうか?
A. ハハハ。前はそういう傾向があったんですが、最近は時間があったら家族と過ごすことが多くなりました。家では、Xiaomiのウォーキングパッドで運動しながらYouTubeでカンファレンス動画を見たりします。

非同期マイクロサービスフレームワーク、Armeria

Q. Armeriaは、LINEに入社されてからのプロジェクトですか?どういうきっかけで始めたんですか?
A. Nettyでローレベルを構築したので、そのうえにより便利にサーバーが構築できる何かがあればいいな、と漠然とした思いは持っていました。でも、私が具体的に何かを直接作る必要があるとは思わなかったんです。Nettyだけでも十分忙しかったので(笑)。ところが、LINEに入ってみたらそういうのが必要だという明確なニーズ(needs)があったので、Armeriaの開発を本格的にスタートしました。

Armeriaの公式ホームページ(https://line.github.io/armeria/)

Q. Armeriaについて、簡単な説明をお願いします。
A. Nettyは、さまざまなプロトコルを交換できる一種のローレベル汎用フレームワークです。ArmeriaはNettyの上に実装した、より高いレベルのWebベースマイクロサービスフレームワークです。Armeriaを使えば、高性能の非同期リアクティブ(reactive)Webサービスを簡単に開発できます。セッションレイヤでは、ArmeriaはHTTP/1HTTP/2だけでなくHAProxyプロトコルまで対応するんですね。アプリケーションレイヤでは、REST API以外にもgRPCThriftにも対応している、唯一のオープンソースフレームワークです。さらには、すでに作成しているJava EE(Enterprise Edition)ベースのWebアプリケーションをArmeriaと一緒に起動できるので、従来のシステムから徐々に移行することも可能になります。それ以外にもマイクロサービスのアーキテクチャーを実装する際に、必須機能であるservice discoverycircuit breakersclient-side load-balancingmetricsなどのさまざまな機能をArmeriaでは提供しています。

Q. Webサービスの実装には、まだ同期型APIが広く使われています。一方、Armeriaは非同期で動作することに焦点が合わせられていますが、何か理由はありますか?
A. 伝統的なWebフレームワークから提供する同期型のAPIを使うサービスでは、規模が大きくなってくるにつれ、同期型のAPIだけでは処理しきれなくなります。したがってサービスの規模が大きくなってきたら、非同期型やリアクティブなものに進化する必要があります。つまり、Armeriaのようなリアクティブ・プログラミング・パラダイムや非同期パラダイム対応のWebフレームワークが必要になるのです。

Q. 非同期で処理すれば、より多くのリクエストを処理できるんですか?
A. 状況によって答えが変わる質問ですね。それでもできるだけ一般的な観点から答えてみますと、ストレージ(storage)の応答時間が長くなればなるほど、非同期型がはるかに有利になります。特に、バックエンド(back-end)の一部に障害や過負荷などが生じて応答スピードが落ちると、同期型は問題が発生したバックエンドとは関係のないリクエストまで被害を受けるので、大きな障害につながることが多くなります。一方、非同期型は問題が発生したバックエンドとは関係のないリクエストは、特にチューニングしなくてもきれいに処理できるので、大きな障害になりません。データを分散して保存する仕組みでは重要な違いだと言えます。

Q. それでもまだ同期型のAPIが主流になっていますが、非同期型がなかなか広がらない理由はなんでしょう?
A. まず、非同期型のアーキテクチャーが効果を得るには、そのサービスの規模が、一定以上に大きい必要があります。100人程度がアクセスするサービスであれば、非同期型で実装しても同期型で実装してもで大差ないかもしれません。サーバーが十分なパフォーマンスを持って、メモリー容量も十分であれば、同期型で実装したサービスも大きな問題なくリクエストを処理できるでしょう。問題は、サービスが成長して格段と多くのユーザーがアクセスするときに発生します。特に同期型では特定の時間帯、あるいは急に短時間でユーザーが押し寄せたときに、ユーザーのアクセスを正しく処理するのが難しくなるかもしれません。こうした問題は、非同期型で実装するだけで簡単に解決できます。つまり、最初から非同期で開発すれば、サービスが成長したときでもより簡単に対応できると思います。最近はプログラミング言語やライブラリーでもだんだん非同期で実装する傾向があります。最近多く使われているNode.jsも基本的に非同期ですね。開発者の間で、非同期やリアクティブプログラミングへの関心がますます高くなって、理解も深くなっているようです。

QSpringフレームワークベースでは、非同期APIを作ることはできませんか?
A. 前は難しかったですね。でも最近、Spring WebのリアクティブバージョンであるSpring WebFluxが登場してSpringフレームワークベースでも非同期WebアプリケーションやリアクティブWebアプリケーションを開発できるようになりました。考えてみると、非同期への関心が高まっているいい例として、Springフレームワークを取り上げることができますね。以前は、非同期という概念を開発者が理解するのは難しかったので、Springフレームワークはほとんど同期で実装されました。そのSpringフレームワークに非同期が導入されたのは、最近のWebサービスの規模がだんだん大きくなり、開発者が非同期に関心を持つようになり、理解が深くなっていることを意味すると思います。

Q. LINEにもArmeriaを使っているサービスが多いですね。ヒスンさんが考えているArmeriaのロードマップと今すぐLINEのサービスに必要な要望の間で、優先順位や方向性について悩んだことはないですか?
A. オープンソースプロジェクトは、基本的に顧客、つまりそのソフトウェアを利用する他の開発者のフィードバックに応じて動くものです。したがって、どんなフィードバックであれ、フィードバックはそれだけでいいものですね。愛の反対は憎しみではなく無関心だという言葉もあります。だから、何か要望があれば、あまり待たせることなく必要な機能を実装します。それと同時に、全体のロードマップに基づいて調和のとれた絵を描ければ、素晴らしいと思います。オープンソースプロジェクトでは、何かをいつまでに終わらせるべき、という考え方がありません。もちろん、目指しているロードマップはあるかもしれませんが、もし顧客が早く必要とする機能があるなら、そちらを先に進めることもできます。ただ、顧客からの要望だとしても、プロジェクトが根本的に目指している目標や基本的なプロジェクトの骨子から外れる作業をしてはいけません。でも、そういうレベルのトラブルはあまり起こらないですね。普段は、プロジェクトの範囲外の機能の開発をわざわざプロジェクトに要望することはありません。

Q. サービスは、競い合って成長することもたくさんあります。例えば、UberLyftのようにですね。では、Armeriaの競合は何でしょう?先ほど触れたSpring WebFluxでしょうか?
A. Spring WebFluxは、競合とも言えるし、協力し合う関係とも言えるでしょう。非同期プログラミングがだんだん成長していると言っても、まだ同期プログラミングに比べたら規模が小さいのが現実です。それなら、より多様な選択肢があってエコシステムが豊かになったほうが、お互い得になると思います。また、Armeriaは実際のWebサービス、中でもマイクロサービスの実装を簡単にする手助けに集中していますが、Springはそれよりずっと多くの機能を提供しています。Springのほうが機能が多いため、ArmeriaはSpringと簡単に統合できるように統合モジュールも提供しています。例えば、Spring WebFluxを使用する場合に、HTTP通信レイヤのみArmeriaを使うこともできます。LINEにもSpringベースで作られたアプリケーションが多くありますが、ThriftやRPC通信にはArmeriaを、Java EEベースのWebアプリケーションにはSpringを使うようにする場合が多くあります。

Q. ところで「Armeria」という名前はどうやって決まったんですか?
A. Armeriaをはじめたきっかけは、LINEで使っていたThrift RPCスタックをより現代的なHTTP/2ベースの非同期に変更して、LINEが苦労していたスケール問題を解決するためでした。だから、この「Thrift」は肝心な言葉でしたね。Thriftという言葉を辞書で引いてみると「節約」という意味もありますが、野花の一つである「armeria」を指す意味もあります。この2番目の意味に着目してプロジェクト名を「Armeria」にしました。プロジェクトのロゴは、図式化した3つの花房が重なっている形なんですが、それぞれの花がマイクロサービスを意味しています。いろんなマイクロサービスが集まって一つの大きなサービスになるという意味を込めています。

Armeriaロゴの初期バージョンと最終バージョン

LINEで一緒に働きましょう!

Q. どういうきっかけでLINEに入社することになったのですか?
A. Twitterで何年か働いていたら、Nettyのメンテナンスも良かったんですが、新しい仕事もやってみたいと思いましたね。そこで探してみたんですが、LINEには開発チームも多く、技術的にも興味深い仕事が多くありました。腕のいい知り合いがすでに働いていたので、仕事をしやすい環境になるとも思いました(笑)。

Q. どういう人と一緒に働きたいですか?
A. こちらのチームではArmeriaとCentral Dogmaを両方とも扱っています。オープンソース開発の経験があれば嬉しいですが、実はあまり期待していません。フレームワークやライブラリーの開発経験がある人であれば一緒に働きたいと思います。そして、新しいAPIをデザインする際には、言語へのより深い理解が求められるので、Javaをきちんと理解している人であればいいですね。また、几帳面な人であれば、なお歓迎です。例えば、あるPRに同じような修正がいくつかあったりしますが、コメントしたところだけ修正する人よりは、いちいち言わなくても全体的に修正する人と一緒に仕事したいですね。最後に、テキストでコミュニケーションをとることが苦手じゃない人が欲しいです。メッセンジャーで会話していると「非同期」で仕事をすることが多いですね。テキストで自分の考えを表現するときに、因果関係を明確にして詳しく書いてくれる人と働きたいです。

Q. 几帳面な仕事ぶりというのは、実際一緒に仕事してみないと検証が難しいことですね。どのような方法で確認されるのでしょうか?
A. そうですね。どうしてもただの基本的なレベルのコーディングテストだけでは、几帳面な人なのかどうかを検証するのは難しいです。そこで、GitHubポートフォリオを検討したり、他のプロジェクトに送ったPRを検討したりするなどのプロセスを経ています。もし独自のオープンソースプロジェクトがあったら、よりきちんと確認できると思います。

Q. 最後に一言お願いします。
A. オープンソース開発者として活動していると、「オープンソースプロジェクトに参加したいけど、どのプロジェクトにどう参加すればいいか分からない」という質問をよく受けます。最も重要なのは、質問だけで終わらず、自分にできることをとりあえずスタートして、そこから自分自身を限界に追い込み続けることです。何でもやってみて、初めて方向が見えてくるはずです。「どの道がいいかな?」という質問にとらわれすぎるのはよくないですね。今日すぐ、ArmeriaやCentral Dogmaに送るPRを準備してみるのはいかがでしょうか?(笑)