イベントレポート
IIJ Technical WEEK 2020
Webブラウザーで動く第4の言語“WebAssembly”はどう凄い？ C++もコンパイル……～IIJがアプリケーション分野の革新を振り返る～
「オンライン勉強会が不便？そうだ、専用アプリを作ってしまおう」も……
2020年12月24日 12:33
株式会社インターネットイニシアティブ（IIJ）は、ITエンジニアを対象とした年次の技術イベント「IIJ Technical WEEK 2020」を開催した。会期は12月14日から17日の計4日間で、今回はオンライン開催となった。
4日間それぞれにテーマが設定され、DAY1は「セキュリティ」、DAY2は「インターネット・バックボーン」、DAY3が「アプリケーション」、DAY4が「データセンター」となっている。
本稿では、DAY3（16日）のアプリケーション寄りのテーマを扱ったセッションの模様をレポートする。なお、セッション内容は後日、動画でも公開されている。記事の最後に紹介しているので、詳しく見たい方はそちらも見てほしい。
開発勉強会がオンライン化するも課題発生…「既存アプリがないなら作ろう」進捗確認や質問などのコミュニケーションを改善
IIJ 中日本事業部 名古屋支社 技術部 技術2課の韮塚凌平氏による「コロナ禍の開発勉強会～社内教育ツールの開発と実装」では、コロナ禍によって新人向け勉強会がオンラインになったことによる課題と、それを解決するために自分たちで作った社内向けアプリケーションを解説した。
IIJでは、毎年1回、有志で開催する「IIJ Bootcamp」という新人向け勉強会を開催している。ここではフロントエンドやバックエンド、セキュリティなど浅く広くテーマを扱っている。
IIJ Bootcampは、今年はコロナ禍により、Teams会議によるオンライン開催になった。ただし、十分な準備ができていなかったので進行が難航していたという。そこで、今年のIIJ Bootcampは6月末と7月下旬の2つの時期に分けていたため、前半が終わったところで課題を調査した。
そこで挙げられた課題としては、「受講者が質問するハードルが高い」「講師が受講者の進捗を把握しづらい」「TAが資料のURLを定期的にTeamsチャットに貼って教える必要がありTAの本来の講義サポートができない」があったという。
「ないなら作ろう」でできたVisualBootcamp
この課題を、勉強会の受講状況や受講者の進捗をリアルタイムで確認できるようにするシステムで解決しようとした、と韮塚氏は言う。「しかし、既存のツールは見つからなかったので、ないなら作ろうということで開発した」。
このシステムがVisualBootcampだ。開発者は2人で、後半に間に合うよう短期間で開発された。名前の由来は、IIJ Bootcamp＋可視化だという。
VisualBootcampの機能について、韮塚氏は先述の3つの課題ごとに紹介した。
まず、「受講者が質問するハードルが高い」という課題については、チェックポイント機能が用意された。ハンズオンで一連の作業を進めるときに、要所要所にチェックポイントが設けられ、受講者ができているか確認する。受講者はどのチェックポイントで躓いているかを伝えればいいので、気軽かつ的確に質問ができるようになるという。
次に「講師が受講者の進捗を把握しづらい」という課題については、リアルタイム進捗確認機能が用意された。受講者ごとの状況が表形式で表示され、進捗がゲージで表される。これにより、各自の進捗が一目でわかり、発表速度を調整できるほか、進捗がよくない受講者に声かけができる。受講履歴も見られるため、適切なサポートができるようになっているという。
最後に「TAが資料のURLを定期的にTeamsチャットに貼る」という課題については、講義情報の確認機能が用意された。講義ページを開けば受講に必要な情報を一目で把握できる。
VisualBootcampの開発体制も韮塚氏は説明した。目指したことは「OSSのように誰でも開発に参加できる構成にしたい」「開発者はインフラ基盤をできる限り考えないように」「テストは自動化」の3つだという。
VisualBootcampはRuby on Railsで開発。ソースコードを社内GitHubで管理し、DroneによるCIでビルドとテストを実行する。デプロイでは、社内Dockerリポジトリにプッシュして、自動的に社内Kubernetesプラットフォームにデプロイする。
音声通話でつなぎっぱ、そして黙々と作業する「さぎょいぷ」で進捗を共有
目指したとおり、社内GitHubによって誰でも開発に参加できるようにしたため、社内からイシューやプルリクエストが来て、2人での開発で期間までに完了できたという。また、利用が始まってからも、使いづらい箇所についてはイシューから要望を受け取ったという。
また、開発した2人は名古屋（韮塚氏）と東京に分かれ、開発中には一度も直接顔を合わせていないと韮塚氏は語った。かわりに、Teamsの音声通話でつなぎっぱなしにして黙々と作業する「さぎょいぷ」（言葉の由来はSkypeから）で進捗共有をしたという。
もう1つ、開発メンバー間で待ちの状態を作らないことを心がけたという。今回については、アプリ開発とデプロイ環境構築に分けて作業した。
韮塚氏は受講者や講師・TAからの好評の声も紹介し、「自信につながった」など役に立ったという声がうれしいと述べた。
Webブラウザで動く第4の言語「WebAssembly」C++もコンパイルできるバイナリ形式、Google Meetの「ぼかし」などでも活用
基礎研究組織であるIIJイノベーションインスティテュート（IIJ-II）のエンジニアの山本悠滋氏による「フロントからバックエンドまで - WebAssemblyで広がる可能性」で、WebAssemblyの概要や動作モデル、最新の技術動向などが紹介された。
山本（悠）氏はWebAssemblyを「ウェブブラウザー上でJavaScriptのように（プラグインなしで）動作させることを目的として作られた命令セットと、そのバイナリーフォーマット」と説明した。主要なWebブラウザーがサポートしており、W3CによりHTML・CSS・JavaScriptに続く「Webブラウザーで動く4つめの言語」として標準化されている。
山本（悠）氏はWebAssemblyの採用例も紹介した。
Google Meetでは、背景ぼかし機能を、C++で書かれたGoogle製機械学習フレームワークをWebAssemblyにコンパイルして実現していることが発表されている。また、動画や音声のフォーマットを相互変換するFFmpegをWebAssemblyに移植した「FFMPEG.WASM」によって、動画のエンコードなどが全部Webブラウザー上で完結する。MicrosoftのWebアプリケーションフレームワークASP.NET Core Blazorでは、処理をWebブラウザー側で処理する「Blazor WebAssembly」機能を持っている。また、グラフィックスエンジン「Magnum Engine」のWebに掲載されたサンプル集では、サンプルが「Webブラウザ―で直接実行できるプログラム」として公開されている（こうした場合、従来は動画で見せるしかなかった）
「送られてきたバイナリコード」をどう安全に実行するか？
続いて山本（悠）氏は、サーバーから送られてきたバイナリコードをWebブラウザーで安全にする実行モデルを、「 ホストのデータからの分離 」「 ホストのAPIからの分離 」「 index空間の分離 」の3つで説明した。なお、ここでホストとはWebブラウザーなどWebAssemblyを実行するプログラムを指す。
「ホストのデータからの分離」としては、WebAssemblyは原則としてホストのメモリーには勝手にアクセスできないことが説明された。ホストとデータをやりとりするには、ホスト側で作ったMemoryオブジェクトを使う。
「ホストのAPIからの分離」としては、WebAssemblyからはリンクした関数やOSのシステムコールは、明示的にimportしないと呼べないことが紹介された。
「index空間の分離」としては、普通の機械語では指定したアドレスにどこにでもジャンプできるのに対し、WebAssemblyでは関数呼び出しやブロックから抜け出す分岐命令のbrなどごとに指定できるものが別々になっているという。
活用はWebブラウザ―以外にも
WebAssemblyはWebブラウザー以外にも広がっていることを山本（悠）氏は紹介した。
これについては、PostgreSQLやKubernetesなどが挙げられた。
まず、PostgreSQLについては、汎用WebAssembly処理系を開発しているWasmerが「PostgreSQLのSQLからWebAssemblyで定義した関数が呼べる機能」を実装しているほか、マイクロサービス向けのプロキシサーバーであるEnvoyでは、WebAssemblyで拡張機能を作れるとのこと。また、Kubernetes関連のOSSを多数開発しているDeis Labsは、コンテナイメージのかわりにWebAssemblyのモジュールを動かす「Krustlet」を開発している。
こうしたWebブラウザー以外での利用に向け、WebAssemblyがPOSIX風のAPIを利用できるようにするための標準仕様「WASI（WebAssembly System Interface）」も策定されている。
こうしたWebブラウザー以外での利用について、山本（悠）氏は「実験的なものが大半で、広く使われるには至っていない」という。そして、実用的に使うための問題をカバーするための取り組みを紹介した。
まず、WASIでは、現状ではネットワーク機能がないため、ソケットの接続やリッスンのAPIが策定中だという。また、多くの言語からWebAssemblyに対応しやすくするために、例外処理やガーベージコレクションの仕様が策定されているという。
ホストとの連携を強めるための機能としては、「演算はできないポインターのようなもの」の型が追加されることで、importしたホストのAPIをWebAssemblyでラップするのが簡単になるという。
ホストとの連携を強めるための機能としてもう1つ、Inteface Typesというプロポーザルが出されていることも紹介した。WebAssemblyによる関数には数値しか渡せないのに対し、文字列などを渡せるように見えるラッパーの仕様を標準化するという。
QUICはTCPとどう違うか
その後に開催された「今抑えておきたいQUIC」は、新しいトランスポートプロトコルであるQUICを解説する5分のショートセッション。解説を行ったのはIIJ-II 技術開発室 室長の山本和彦氏だ。
まず山本（和）氏は、QUICについて、「TCPの置き換えだが、それ以上の機能を提供している」と説明した。
そしてTCP＋HTTP/2とQUIC＋HTTP/3の機能を比較。QUICは信頼性やフロー/輻輳制御、セキュリティ、多重化などを含む大きなトランスポートプロトコルであるため、下のUDPや上のHTTP/3は薄い層となっていると語った。
山本（和）氏は、氏が考えるQUICの利点として、2点を挙げた。1つは、0-RTTという機能のおかげで2回目の通信が高速なこと。TCPは毎回3ウェイハンドシェイクで接続を確立する手間があり、それを避けるためのTCP Fast Openも登場したが必ず利用できるわけではない。
もう1つはユーザー空間（OSの上で動くソフトウェア）で実装されているので、進化＆普及が早いこと。TCPはOSの中で実装されているので、アップデートは年1～2回程度で進化や普及が遅いという。
一方、QUICの欠点としては、ハードウェアなどによる最適化がなされるTCPに対して、QUICではそうした最適化はこれからだという点を挙げた。
山本（和）氏は最後にQUICで今起きていることとして、IETFでの標準化が最終段階にあること、ChromeでIETFのQUIC（GoogleのQUICではなく）がすでに利用可能なこと、GoogleやFacebokのサービスでIETFのQUICがすでに利用可能で、よいユーザー体験が報告されていることを紹介した。
IIJ Technical WEEK 2020レポート記事
（協力：株式会社インターネットイニシアティブ）