Open Source Summit Japan 2022参加報告

LINE Engineering2023-01-26

LINE Engineering Blog official account

Open Source Summit Japan 2022参加報告

LINEのOpen Source Program Office TFではオープンソースへの貢献を奨励し、それを推進する一助としてオープンソースを支えるコミュニティ組織との関係を強化していますが、その活動の中での縁から2022年12月5日(月)から7日(水)にかけてパシフィコ横浜で開催されたOpen Source Summit Japan 2022(以下、OSSJ2022)へゴールドスポンサーとしてスポンサードする機会に恵まれました。このOSSJ2022へは多数のLINEのエンジニアらが発表者、ブース運営者、一般聴講者として参加しましたが、本記事ではそれらの活動の模様をお伝えします。

Open Source Summitとは？

先ず、Open Source Summitの紹介を先にしておきましょう。

Open Source Summitは元来はLinuxConという名称であり、Linux Foundationの主催によって2009年に北米で開催されたのが最初です。Linux FoundationによるLinuxConという名称が示すように、当初はLinuxカーネルに強くフォーカスしたイベントとして開催されており、Linuxカーネルの開発関係者ではない一般の方も参加できるLinux関連イベントとしては最も権威のあるカンファレンスイベントでした。Linuxカーネルの生みの親であるLinus Torvalds氏を相手に1990年代からのオープンソース業界のカリスマであるDirk Hohndel氏がインタビュアーとして進行するセッションが名物のようになっており、日本でもこのコンビによるインタビューセッションが何度か開催されたことがあります。「ワタシハリナックスチョットデキル」と書かれたTシャツを着るLinus氏の写真を見たことがある方も多いと思いますが、まさにその写真はLinuxConでのインタビューセッション中の写真なのです。

Linuxが様々なIT領域に浸透するにつれ、LinuxConもイベントのテーマとして扱う領域を拡大させていきますが、その流れにおいてLinuxからオープンソースのエコシステム全体を扱うカンファレンスとして2017年にリブランディングされたのがOpen Source Summitです。LinuxConの形式を踏襲して北米、欧州および日本で年次開催し、Linuxカーネル全般を超え、サーバーから組み込みシステム、クラウド、AI、セキュリティ等の様々なテーマを扱うマイクロカンファレンスの集合体として構成され、オープンソースの今を伝える総合的なカンファレンスとなっています。

今日のOpen Source Summitは、日本で開催されるオープンソース関連イベントとしては最大級の規模かつ最も権威のあるカンファレンスの一つであり、オープンソースのエコシステムを支える開発者、エンジニアらが一堂に会する貴重な機会となっています。2020年及び2021年の過去二年はコロナ禍によりバーチャル開催を余儀なくされていましたが、OSSJ2022ではハイブリッドではあるものの三年ぶりに対面形式での開催となり、LINEとしてLinux Foundation関係イベントへの初めてのスポンサードの機会として非常に良いタイミングだったと思います。

OSSJ2022概況

今回のOSSJ2022は下記の10個のマイクロカンファレンスで構成され、それに加えてOpenSSF Day、ELISA Mini Summit、Open Source Compliance Summitといった独立イベントも併催されていた他、CNCF主催によるKubeDay Japanも隣のインターコンチネンタルホテルで開催されました。

LinuxCon
OSPOCon
Emerging OS Forum
Automotive Linux Summit
Critical Software Summit
Embedded IoT Summit
CloudOpen
Community Leadership Conference
Open AI + Data Forum
ContainerCon

OSSJ2022の枠内においては825名の一般参加者を記録し、そのうち508名が会場での直接の参加だったそうです。海外からの渡航解禁の時期の影響や日本国内では製造ラインを持つハード寄りの産業では出張が未だに許可されていない企業が多いという状況を踏まえると、まずまずの人数が参加したのだと思います。海外渡航比率に関しては30%弱が日本国外からの参加者でしたが、次回以降は跳ね上がっていくものと思われます。

LINEブースの運営

今回のOSSJ2022においてLINEはゴールドスポンサーでありましたが、そのスポンサーベネフィットとしての展示ブースを会場内の一室で構えつつ、スポンサーに相応しい形で講演者を推薦し、さらにLINEのエンジニアが現地で10名、バーチャルで15名ほどが参加するという割と大きな企画となりました。

まずLINEブースについてですが、基本的にはLINEもオープンソースエコシステムの一員であることを示すため、LINEの文化を伝えることを目的に開発者向けデザインのキャラクターステッカーや開発文化が記されたLINE Engineering Culture Bookの配布を行いました。

二日間での参加証読み取りベースで110名の来場を記録しましたが、二日目はとにかく多くの人と話すほうが良いとの判断からチェックはほぼ実施しませんでしたので、実際には150名以上の方々がLINEブースへ立ち寄ったのだろうと思います。ブース運営はOSPO TFメンバーだけでなく、スポンサー特典の無料チケットで現地参加した10名のLINEエンジニアがセッション聴講時以外の時間においてブース周辺に常駐するという陣容で構えていたのですが、さすがに来場者が開発者中心であることから技術的な質問もあり、LINE APIに関しての質問もあってその場で社内の担当者へ情報が共有されるといった一幕もありました。

なお、Linux Foundation主催イベントでは朝食、午前と午後のおやつ、夕方からのレセプションと飲食が提供される機会が多いのが特徴なのですが、今回のOSSI2022ではLINEブースの目の前のエリアが飲食の提供スペースとされたため、ピークのタイミングではLINEブース前でお皿の取り合いのような状況になっていました。

LINEからの講演者

肝心のLINEからの講演者については、Linux Foundation側からLINEという日本を代表するサービスなのですからそれを支えるクラウド基盤寄りの話題が良いでしょうとの助言を得て、Verda室OpenStackチームのマネージャーである室井雅仁と谷野光宏の両名がスポンサーセッションを担当することとなり、「LINE's Journey; Road to 4 Million Cores in the Private Cloud」と題したセッションがCloudOpenの枠内にて行われました。

OpenStackを利用したLINEのプライベートクラウド「Verda」は400万コアにまで規模を拡大させていますが、その2017年以来の5年間の歴史における各フェーズでの課題や教訓を紹介する内容でありました。参加者からの反応は上々だったようで、特にサーバー設定に要する時間を大幅短縮したことに対して関心を寄せられ、発表が終わった後に質問攻勢が続く姿も見られたそうです。詳細については、YouTube動画をご覧ください。

発表スライド：https://speakerdeck.com/line_developers/lines-journey-road-to-4-million-cores-in-the-private-cloud

また、12月7日にOSSJ2022の付属イベントとして開催されたOpen Compliance Summitにおいては、Security AutomationチームのSimon Vestionと二関学がSBOM（Software Bill of Materials）についての講演を行いました。昨年11月に開かれたLINEとヤフーの技術カンファレンスであるTech-Verse 2022でも紹介した内容ですが、オープンソースのセキュリティ脆弱性を効率的に管理するために、SBOM情報を静的ファイルからのみ収集するのではなく、実行時にランタイムで収集するという手法を提示し、静的と動的の双方のメリットとデメリットを解説するという内容でした。SBOMを利用した脆弱性管理については注目が集まりつつあるところであり、企業の関係者の目を引いていたようでした。

Open Compliance Summitについては残念ながらLinux Foundationメンバー企業に限定されたイベントであるため公開動画はありませんが、興味のある方はTech-Verse 2022での講演動画や資料を参照してください。

Tech-Verse発表資料：https://speakerdeck.com/techverse_2022/how-i-learned-to-stop-worrying-and-love-the-bom

他の講演セッション

OSSJ2022では90以上のセッションが実施されましたが、一部を除いてほぼ全てのセッションがYouTubeで公開されています。

Open Source Summit Japan 2022 YouTube再生リスト：https://youtube.com/playlist?list=PLbzoR-pLrL6owCzHwtlpNz8stbU03fbOJ

また、Frontendチーム峯友郎、 LIVEサーバ開発チーム朱凌墨による一部の講演のまとめもご覧下さい。

Building the Open Source Program Office at Goldman Sachs

講演者：Marty Pauley, Goldman Sachs
URL：https://sched.co/1D12k
要約 (峯友郎)：

Goldman Sachsは1年くらい前にOSPO部署を立ち上げたが、単純なオープンソース推進というだけでなく、オープンソースに関連する知見を高め、Goldman Sachs自身がコミュニティをリードし、コミュニティの方向性について影響力を得ることでより多くのベネフィットを得られるようにするというゴールが設定された。また、それによってコミュニティにおけるGoldman Sachsの知名度を高めて「金融サービスだけどOSSもやっている」という方向を普通のこととしていきたいとの思いもあるとのこと。

OSPO設置以前はCopyleft licenseに過度な不安を持たれたり、個人のオープンソース活動の申請や許可の判断の揺らぎや調整の手間が大きく、また就業中の活動が難しかった。しかし、OSPO設置後は外部でIssue/PRを建てる等の活動に対して社内SNS規程に追加され、個人的/無報酬ならば申請無しでOSS活動をしてよいということが明文化される等の制度の整備が進み、社員の貢献を追跡し、さらに社内コードを安全にGitHubへアップできるシステムを構築したことでより気楽に外部活動ができるようになった。

エンジニアは法律が専門ではないのでライセンス面での問題は残ったが、OSPOがあることで弁護士やメンテナに金銭を支払い、相談できるフローができたことはそれらへの問題対応も進んでいる。

How InnerSource Is Beginning to Change Software Development at IBM. Lessons Learned, Best Practices, and How You Can Apply Innersource at Your Workplace

講演者：Jeffrey Borek, IBM
URL：https://sched.co/1D12P
要約 (峯友郎)：

IBM Watsonは多くのOSSの上に成り立っていたが、それをIBMとしては外部に敢えて公言することはなく、そのままオープンソースコミュニティへ参加する機会を逃していた。世はAI時代になり、AIチームに対してオープンソース活動の働きかけをしたところ、色々なAI関連のmoduleが公開された。https://github.com/Trusted-AI

Watson以後、さまざまなチームがAIに挑戦し、それぞれの方法でAIを推進したが、そのためにAIソリューションが分散し、無駄が多い状態だった。そこで、みんなでメンテして、かついろいろなプロジェクトに適用できる社内用のAI core moduleを作成した。これによってコア部分の実装を省略できるようになり、各チームはプロジェクトに特有の部分だけに集中できるようになった。NLP分野では、共通コアの作成コスト$2.4M に対して、共通化によるコスト削減が $9.6M 得られた(2020)とのこと。

なお、Q&Aにて、セキュリティ面においてはオープンソースをどのように利用するかについて考えずにオープンソースを活用する時代は既に終わりつつあるとのことが示された。

TCP Socket Lookup Degradation and per-Netns Ehash

講演者：Kuniyuki Iwashima, Amazon Web Services
URL：https://sched.co/1D13r
要約 (朱凌墨)：

このセッションでは、LinuxカーネルにTCPにまつわる3つのハッシュテーブルであるbhash、lhash、ehashとその役割をソケットAPI利用の流れで紹介し、その後に既存のハッシュテーブル実装の性能が劣化する原因としてそのシナリオを紹介しつつ、性能劣化の緩和策としての新しい実装を紹介していました。

まず、TCPのソケットについて、通常ではサーバ側はsocket() bind() listen()を経て、accept()でクライアントとの接続ソケットを受け取ってやり取りをする。一方、クライアント側はsocket()とconnect()で接続を確立する。bhash(bound sockets)はbind() listen() connect()の時、lhash(listening sockets)はSYNが来る時、ehash(establishing/ed sockets)はSYN以外すべてパケットが来る時に照会される。

なお、上記３つのハッシュテーブルは連鎖法で衝突を処理することと、シングルリンクリストなので新しく入れたものがリストの頭に置くことで、それらのハッシュテーブルに衝突頻度が高ければ紐づいているリンクリストが長くなる。そしてリストにあるソケットの照会は古いほど遅くなり、またbhashについてbind()とlisten()による照会にspinlockが掛かるので性能インパクトが大きい。そのため、如何に衝突を減らすかが効率向上において肝心となる。bhashとlhashは元々netnsとlportだけでハッシュするので比較的に分かりやすい考え方であるが、laddrもハッシュに入れることで衝突の確率を減らすことになった。その改良したlhash2は4.16からカーネルにマージし、完成度を高めつつ5.19からlhashを完全に置き換え、Bhash2は6.1に入れられた。

しかし、ehashについては最初からnetns, laddr, lport, raddr, rportでハッシュするので、別の要素を入れる余地がない。しかも接続ごとにエントリがあるので長くなりやすく、netnsの間に隔離がないのでnetnsの間にも影響が発生する。AWSでの測定によると、リンクリストの長さが128に達したところ性能が8割、384に達したところ半分まで落ちることになった。それを解決するため、netnsごとに別々のehashテーブルを持つことにした実装のehash2が誕生し、6.1にマージされた。Sysctlで制御可能であり、同じ仕組みはNUMAでも適用でき、ehashを同じnodeにするか、もしくは別のnodeに分布させることも可能。UDPにも対応する実装は6.2に入れる予定とのことです。

個人の感想としては、今後コンテナの運用には役に立ちそうな情報だと思います。まずこれらの性能ボトルネックはTCP接続の直接やり取りがないと影響しない。なので、VMの場合はホストには最悪でもあくまでIP forwardしか発生しないので影響されないと思います。ですが、スペックが大きいVMかベアメタルサーバを例えばkubernetesのnodeとして運用する場合、同じnodeの上に沢山のpodが走っているのならその数のnetnsがあるので、状況次第でehashによるボトルネックが発生し得ると思います。なおnetns分離ehash2を運用する場合、繊細な調整も必要であるので、本格運用するまでの課題になると思います。

おわりに

今回は機会に恵まれ、今までやってそうでやっていなかったLinux Foundation主催イベントに参加しましたが、OSPO TFとしては日本国内の大きなイベントへ参加するというのは初めてだったこともあり不手際も多くありました。ブース運営要員用の昼食チケットを(ステッカーと間違えて？)一般来場者に持っていかれてしまったり、LINE Developersのスタンドバナーを破壊してしまったり、ブース内での動画再生用のMacの全てのパスワードを忘れてしまったり、という珍事件もありましたが、そもそもOpen Source Summitの本質である講演セッションにおいてLINEであればもっと多数のエンジニアが講演者側にまわっても不思議ではなく、後になってこの領域であればLINE側から講演者を出したかったなと考えさせられることになりました。ただ、日本内外と問わず次回以降のLinux Foundation関連イベントへの参加の良い練習になったのではないかと思いますし、何よりも久しぶりの対面イベントへ多くのLINEエンジニアが参加する機会を作ったことで貴重な経験が得られたと思います。

OSPO TFとしては、LINEエンジニアの知見、経験を効率的に外部へアピールする機会を作り、オープンソースエコシステムへの貢献に繋げていければと願っています。