簡単に自己紹介をお願いします。Dogmaのようなオープンソースソフトウェアを開発しているイ・ヒスンです。LINEに入社する前は、Twitterで働いていました。Twitterでは、オープンソースソフトウェアであるNettyの、メンテナンスや新しい機能の開発、次のバージョンの開発を担当しました。イ・ヒスンさんは、Nettyプロジェクトでオープンソース開発者として有名になりました。Nettyプロジェクトのリード役は、今Appleに勤めているNormanという方にバトンタッチしました。長い間プロジェクトを一緒に手掛けてきた方なので、スムーズに運営できていますね。Nettyには私の作業した部分がかなり多く残っています。Request)をレビューする程度ですが、Nettyプロジェクトに参加しています。PRはいつも溜まっています(笑)。level)のプロジェクトで、シニア開発者の参加が多いですね。シニア開発者は、PRレビューにかなり時間がかかったり、プロジェクトの方向と合わないPRは断られる可能性があったりするのを、ある程度認識しています。以前に比べると、はるかに多くの開発者がオープンソースプロジェクトの開発プロセスについて理解しているようです。イ・ヒスンさんは、LINEとTwitterで「会社に所属しているオープンソースプロジェクト管理者」として働いてきましたね。最近の会社は、純粋にエンジニアリングの観点からオープンソースソフトウェアに関わることが多くなっています。どのような方法でオープンソースソフトウェアに技術的な変化を適用するかについて、「会社に所属しているオープンソース開発者」にかなり高い自由度を与えています。そのためか、中立を保つのにそれほど苦労した記憶はありません。実は、オープンソースプロジェクトには誰もが貢献できます。オープンソース開発者を直接採用しなくても、PRを送る方法などで必要な機能が実装できますね。実際、私がTwitterに入社する前に、Twitterの他のエンジニアが、NettyにSPDYプロトコルを実装する貢献をしました。厳密に言えばオープンソースに必要な機能を実装するために、開発者を直接採用する必要はありません。現実的にはオープンソースソフトウェアと同じ分野で有能な開発者を見つけるのはなかなか難しいので、企業としても、誰かを採用するなら、今そのプロジェクトに参加している人を採用したほうが当然いいでしょう。System)クライアントやSOCKSプロトコルのような機能を実装したことがあります。そのときのことを振り返ってみても、該当する専門家を直接採用して、特定機能の開発を先にお願いできることが、オープンソース開発者を直接採用することで得られる大きなメリットだと思います。オープンソースプロジェクトごとに少し違うと思いますね。歴史の長いプロジェクトでは、今もメーリングリストを使っていますが、最近のプロジェクトではあまり使っていないようです。最近は、SlackやGitterを多く使っているようで。Overflowに書き込むように案内していますね。Armeriaでは、質問があったらGitHubにissueを作成するように案内しています。issueを作成すると、私かプロジェクトメンバーがそのissueに「question」というラベルを付けて、誰でも簡単に質問をまとめて確認できるようにしておきます。tracker本来の機能を損ねるほどではないので、まだこの方法で大丈夫だと思います。オープンソースプロジェクトに参加して大変だったことがあれば教えてください。まれに短時間で成功するプロジェクトもありますが、ほとんどは成功まで長い時間がかかります。Nettyだけを見ても、プロジェクトがある程度軌道に乗るまでかなりの時間がかかりました。MINAの後を継ぐものとして注目を集めたにも関わらず、ユーザーが十分に増えるまで数年かかったので。地道に進めるのが本当に大事だと思います。私は、「コードレビュー」に最も時間を割いています。その次が、「コーディング」ですね。私は、全体の構造から切り出して具体的にリーダビリティーを最適化する方向でコメントします。リーダビリティーについては、コードがきれいに見える(リーダビリティーの良い)コーディングの仕方をコメントしたり、ネーミングやインデント(字下げ)の規約についてコメントします。それからもう一つ、エラーメッセージにも規約がありますね。このライブラリーを利用すれば、エラーメッセージがこのような形で出る、という一種の暗黙的なルールがあるんです。ルールとは違う形でエラーメッセージが出たら、ユーザーが戸惑うかもしれないので、エラーメッセージの規約についてもコメントを残します。disagree」と言いますね。あなたと私がお互い違う意見を持っていることに同意する、とのことです。2つの意見にそれぞれ長短があるので、できるだけ話し合って技術的には一つの選択をします。心の中では「それでも私はこっちが正しいと思うけど、あなたがそう言うなら...まあ...」と思ったりします(笑)。私は文章で意見を交わしていると、顔を合わせて話したほうがスムーズに進むのでは?と思う時がたびたびありますね。私は顔を合わせて話すよりは、きちんと文章にまとめたうえで議論するのを好みますね。話すと言葉に詰まったり、まともな文にならないこともありますので。オープンソースプロジェクトに参加する全員が、英語によるリアルタイムのコミュニケーションが得意でもないし、その場にいなかった人は後でどんな議論が交わされたか分からないところもあるんですね。仮に、顔を合わせて何かを決めたとしても、結局は文章にまとめておく必要はあります。オープンソースプロジェクトのようなコミュニティーでは、こうした透明性が保証されないとうまく運営できないと思います。本格的にArmeriaについて話す前に、一つ軽い質問をしたいです。前はそういう傾向があったんですが、最近は時間があったら家族と過ごすことが多くなりました。家では、Xiaomiのウォーキングパッドで運動しながらYouTubeでカンファレンス動画を見たりします。Nettyでローレベルを構築したので、そのうえにより便利にサーバーが構築できる何かがあればいいな、と漠然とした思いは持っていました。私が具体的に何かを直接作る必要があるとは思わなかったんです。Nettyだけでも十分忙しかったので(笑)。ところが、LINEに入ってみたらそういうのが必要だという明確なニーズ(needs)があったので、Armeriaの開発を本格的にスタートしました。Armeriaについて、簡単な説明をお願いします。Nettyは、さまざまなプロトコルを交換できる一種のローレベル汎用フレームワークです。ArmeriaはNettyの上に実装した、より高いレベルのWebベースマイクロサービスフレームワークです。Armeriaを使えば、高性能の非同期リアクティブ(reactive)Webサービスを簡単に開発できます。HTTP/2だけでなくHAProxyプロトコルまで対応するんですね。API以外にもgRPCとThriftにも対応している、唯一のオープンソースフレームワークです。Edition)ベースのWebアプリケーションをArmeriaと一緒に起動できるので、従来のシステムから徐々に移行することも可能になります。load-balancing、metricsなどのさまざまな機能をArmeriaでは提供しています。Webサービスの実装には、まだ同期型APIが広く使われています。伝統的なWebフレームワークから提供する同期型のAPIを使うサービスでは、規模が大きくなってくるにつれ、同期型のAPIだけでは処理しきれなくなります。したがってサービスの規模が大きくなってきたら、非同期型やリアクティブなものに進化する必要があります。Armeriaのようなリアクティブ・プログラミング・パラダイムや非同期パラダイム対応のWebフレームワークが必要になるのです。状況によって答えが変わる質問ですね。それでもできるだけ一般的な観点から答えてみますと、ストレージ(storage)の応答時間が長くなればなるほど、非同期型がはるかに有利になります。バックエンド(back-end)の一部に障害や過負荷などが生じて応答スピードが落ちると、同期型は問題が発生したバックエンドとは関係のないリクエストまで被害を受けるので、大きな障害につながることが多くなります。非同期型は問題が発生したバックエンドとは関係のないリクエストは、特にチューニングしなくてもきれいに処理できるので、大きな障害になりません。データを分散して保存する仕組みでは重要な違いだと言えます。非同期型のアーキテクチャーが効果を得るには、そのサービスの規模が、一定以上に大きい必要があります。100人程度がアクセスするサービスであれば、非同期型で実装しても同期型で実装してもで大差ないかもしれません。サーバーが十分なパフォーマンスを持って、メモリー容量も十分であれば、同期型で実装したサービスも大きな問題なくリクエストを処理できるでしょう。問題は、サービスが成長して格段と多くのユーザーがアクセスするときに発生します。同期型では特定の時間帯、あるいは急に短時間でユーザーが押し寄せたときに、ユーザーのアクセスを正しく処理するのが難しくなるかもしれません。した問題は、非同期型で実装するだけで簡単に解決できます。最初から非同期で開発すれば、サービスが成長したときでもより簡単に対応できると思います。最近はプログラミング言語やライブラリーでもだんだん非同期で実装する傾向があります。最近多く使われているNode.jsも基本的に非同期ですね。開発者の間で、非同期やリアクティブプログラミングへの関心がますます高くなって、理解も深くなっているようです。前は難しかったですね。WebFluxが登場してSpringフレームワークベースでも非同期WebアプリケーションやリアクティブWebアプリケーションを開発できるようになりました。考えてみると、非同期への関心が高まっているいい例として、Springフレームワークを取り上げることができますね。以前は、非同期という概念を開発者が理解するのは難しかったので、Springフレームワークはほとんど同期で実装されました。そのSpringフレームワークに非同期が導入されたのは、最近のWebサービスの規模がだんだん大きくなり、開発者が非同期に関心を持つようになり、理解が深くなっていることを意味すると思います。LINEにもArmeriaを使っているサービスが多いですね。オープンソースプロジェクトは、基本的に顧客、つまりそのソフトウェアを利用する他の開発者のフィードバックに応じて動くものです。したがって、どんなフィードバックであれ、フィードバックはそれだけでいいものですね。愛の反対は憎しみではなく無関心だという言葉もあります。何か要望があれば、あまり待たせることなく必要な機能を実装します。それと同時に、全体のロードマップに基づいて調和のとれた絵を描ければ、素晴らしいと思います。オープンソースプロジェクトでは、何かをいつまでに終わらせるべき、という考え方がありません。目指しているロードマップはあるかもしれませんが、もし顧客が早く必要とする機能があるなら、そちらを先に進めることもできます。顧客からの要望だとしても、プロジェクトが根本的に目指している目標や基本的なプロジェクトの骨子から外れる作業をしてはいけません。いうレベルのトラブルはあまり起こらないですね。普段は、プロジェクトの範囲外の機能の開発をわざわざプロジェクトに要望することはありません。サービスは、競い合って成長することもたくさんあります。UberとLyftのようにですね。WebFluxは、競合とも言えるし、協力し合う関係とも言えるでしょう。非同期プログラミングがだんだん成長していると言っても、まだ同期プログラミングに比べたら規模が小さいのが現実です。それなら、より多様な選択肢があってエコシステムが豊かになったほうが、お互い得になると思います。Armeriaは実際のWebサービス、中でもマイクロサービスの実装を簡単にする手助けに集中していますが、Springはそれよりずっと多くの機能を提供しています。Springのほうが機能が多いため、ArmeriaはSpringと簡単に統合できるように統合モジュールも提供しています。WebFluxを使用する場合に、HTTP通信レイヤのみArmeriaを使うこともできます。EEベースのWebアプリケーションにはSpringを使うようにする場合が多くあります。RPCスタックをより現代的なHTTP/2ベースの非同期に変更して、LINEが苦労していたスケール問題を解決するためでした。この「Thrift」は肝心な言葉でしたね。Thriftという言葉を辞書で引いてみると「節約」という意味もありますが、野花の一つである「armeria」を指す意味もあります。この2番目の意味に着目してプロジェクト名を「Armeria」にしました。プロジェクトのロゴは、図式化した3つの花房が重なっている形なんですが、それぞれの花がマイクロサービスを意味しています。いろんなマイクロサービスが集まって一つの大きなサービスになるという意味を込めています。Twitterで何年か働いていたら、Nettyのメンテナンスも良かったんですが、新しい仕事もやってみたいと思いましたね。そこで探してみたんですが、LINEには開発チームも多く、技術的にも興味深い仕事が多くありました。腕のいい知り合いがすでに働いていたので、仕事をしやすい環境になるとも思いました(笑)。Dogmaを両方とも扱っています。オープンソース開発の経験があれば嬉しいですが、実はあまり期待していません。フレームワークやライブラリーの開発経験がある人であれば一緒に働きたいと思います。新しいAPIをデザインする際には、言語へのより深い理解が求められるので、Javaをきちんと理解している人であればいいですね。几帳面な人であれば、なお歓迎です。あるPRに同じような修正がいくつかあったりしますが、コメントしたところだけ修正する人よりは、いちいち言わなくても全体的に修正する人と一緒に仕事したいですね。最後に、テキストでコミュニケーションをとることが苦手じゃない人が欲しいです。メッセンジャーで会話していると「非同期」で仕事をすることが多いですね。テキストで自分の考えを表現するときに、因果関係を明確にして詳しく書いてくれる人と働きたいです。几帳面な仕事ぶりというのは、実際一緒に仕事してみないと検証が難しいことですね。してもただの基本的なレベルのコーディングテストだけでは、几帳面な人なのかどうかを検証するのは難しいです。そこで、GitHubポートフォリオを検討したり、他のプロジェクトに送ったPRを検討したりするなどのプロセスを経ています。独自のオープンソースプロジェクトがあったら、よりきちんと確認できると思います。最後に一言お願いします。オープンソース開発者として活動していると、「オープンソースプロジェクトに参加したいけど、どのプロジェクトにどう参加すればいいか分からない」という質問をよく受けます。重要なのは、質問だけで終わらず、自分にできることをとりあえずスタートして、そこから自分自身を限界に追い込み続けることです。何でもやってみて、初めて方向が見えてくるはずです。「どの道がいいかな?」という質問にとらわれすぎるのはよくないですね。Developers日本語English。