Scala Matsuri 2019に参加してきました
こんにちは！SHOWROOM Tech Studio 松本です！
今回は、Scala Matsuri 2019に参加してきたので、その様子を松本、相原、中村の三人でレポートしたいと思います。
Scala Matsuri とは？
プログラミング言語、Scalaのカンファレンスです。
年1回お台場で3日間ほど開催されます。 Scalaにまつわる技術的な発表や、Scala入門ハンズオン、LTなどを楽しむことができます。
https://2019.scalamatsuri.org/
6月28日（金）の様子
10時に会場入りしました。当日は台風が直撃しており、開催が危ぶまれましたが問題なく開催されました。
この日はカンファレンス形式で、スライドの発表が行われていました。 いくつか弊社エンジニアから見てよかったスライドを紹介します！
コードで理解するPlayFrameworkの脆弱性
コードで理解するPlayframeworkの脆弱性 - Speaker Deck
Scalaでよく利用されるフルスタックWEBフレームワークPlayFramework。
そんなPlayですが、一般的には堅牢でバグが少ないScalaで出来ているため脆弱性が少ないと言われています。
しかし、その実態は、全く脆弱性がないというわけではなく、やはり人間が関わっている以上様々な脆弱性が存在しました。
詳細な内容は発表資料を見ていただければと思いますが、例えば、過去にはソースコード内でWindowsでのファイルパスを考慮してなかったため、Windowsのパス文字「¥」がURL内にあった場合に、アクセスできてはいけないファイルにアクセス出来てしまうパストラバーサルという脆弱性があったりしました。
また、衝撃的だったのは、脆弱性でよく話題になるStrutsというフレームワークがあるのですが、より多くの人に使われているから、脆弱性が発覚しやすいというだけで、Playはマイナーだから脆弱性が発見されにくいだけかもしれないという発言を発表者の方がしていたことです。（あくまで個人の意見です）
ただ、Playだから大丈夫。Scalaだから大丈夫。という意識を持たず、常に危機感を持って、フレームワークのアップデートなどを定期的にしていくことは改めて大切だなと思い出させてくれました。
AWS LambdaでScalaをサクサク動かす
Running Scala on AWS Lambda in a Snappy Way - Speaker Deck
ScalaでAWS Lambda使おうとした場合大きな問題になるのがコールドスタートの遅さで、例えば、ただHello, Worldを返すだけのLambda関数で初回実行時の所要時間はなんと8588msにもなるそうです。
これに対しScalaで記述しながらコールドスタートが高速なLambda関数を実装する方法として以下の3つが提案されていました。
1つ目はScalaJSを使用し出力されたJSをNodeJSのLambdaとして実行するやり方です。利点としてはパッケージのサイズがとても軽量にできる、NodeJSの豊富なライブラリが使えるなどということでしたが、ScalaJSはかなり独自な書き方をしなければならないのでもはやScalaなのか・・・？と思いました。
2つ目はScalaNativeを使いバイナリを生成してカスタムランタイムで実行するやり方です。コールドスタートは高速ですが大きな欠点としてScalaNativeで使用できるライブラリがかなり限定されること、今だにScala2.12に対応していないことなどがあります。
３つ目はGraalVMのSubstrateVM機能を使いバイナリを生成してカスタムランタイムで実行するやり方です。上2つには若干劣るものの十分高速で使用できるライブラリの制約がScalaNativeよりかなり少ないという利点があります。しかし動的なClassLoaderがあると使用できないという問題があり、残念なことにAWS SDKがこれに該当してしまうそうです。
正直な感想としてそこまで無理にScalaでLamdaを使おうとしなくてもいいのでは？とも思いましたが、Scalaに対する愛が感じられて興味深い発表でした。
Scala における型クラス入門
Intro to typeclass in Scala - Speaker Deck
金曜日はBeginnerセッションも多くありScala初心者でも参加しやすかったです。
中でもとても説明がわかりやすく、参考になったのが、 Scala における型クラス入門 のセッションでした。
なかなか説明しづらい型クラス。型クラスはGofのストラテジパターンであると考えると理解できるという切り口でとてもわかり易い説明でした。
Scalaでは避けては通れないimplicit スライド Scalaにおけるimplicitの意味 はカオスでした。
型クラスで利用されるScala2のimplicitは非常に分かりづらかったのですがScala3ではdelegate forやgivenに置き換えられるようです。
Scala3の記述ですがスライド作成後にも変わったようでまだ決定ではないかも、とのことでした。
Cats、Scalazなどの主要なライブラリでも多くの型クラスがあり、今後の理解のためにも参考になりました。
お昼ご飯
今年もお弁当が豪華でした。数種類のお弁当から選ぶことができます。 ローストビーフ丼や、小分けになったおかずがたくさん入った弁当、野菜中心の弁当などなど
私はローストビーフ丼を食べました。大きさの割に密度があって、重くてボリューミーなお弁当でした。
ブースの様子
いくつかのブースにお邪魔させていただきました。
中でもビズリーチさんからいただいた扇子に「不変」「型安全」「暗黙」の文字が書かれており、Scalaの特徴を表した素晴らしいノベルティでした！
懇親会
お酒が充実のラインナップで、飲兵衛も大満足な懇親会でした。主催者が酒好き説（スーパードライ、ギネス黒、エビス、プレモル、ハイボール、チューハイ等なんでもあった）
また、オードブルも豪華で、中華、寿司、串、たこ焼きなど盛りだくさんで、中でもたこ焼きが最高でした。なぜか外にガチめの屋台があり、そんじょそこらのたこ焼きよりも美味でした！
6月29日（土）の様子
この日はアンカンファレス形式での発表でした。 アンカンファレス形式とは、発表者が当日まで決まっておらず、来場者が話したい内容を発表し、他の来場者が投票を行い発表内容を決めていくというスタイルの発表です。
色々と魅力的な内容の発表はあったのですが、今回は特に株式会社はてなさんの発表が印象的でした。 実は弊社でも、かつてPerlからScalaにフルリプレースを検討していた時期があり、はてなさんと状況がすごく似ていてこんな未来もあったのかもしれないというのを思った次第です。
いかにして我々は10年もののPerlプロダクトをScalaでリプレースしたか
How we replaced a 10-year-old Perl product using Scala - Speaker Deck
なぜScalaだったのか
Scalaに強いエンジニアがいたというのと、ロジックが巨大なサービスなので、Scalaの負債を生み出しにくい言語仕様との相性が良かったとのことでした。
リプレースに当たっての課題
・ビジネス側の説得が必要だった
現状すでに稼働しているサービスをわざわざリプレースする意味があるというのをエンジニア以外の方に納得していただくことが大変だったそうです。はてなさんの場合は、既存の仕様が複雑になりすぎてリファクタリングが失敗したという事件が起きたり、段々とビジネス側にもリプレースが必要というのが伝わって行ったとのことでした。
・Perlエンジニアが多い中でScalaをどう書いていくのか
メインジョブがPerlのエンジニアがScalaをやるということで、気をつけたことはCatzやScalazなどの難しいライブラリはあえて使わないということでした。会社のポリシーにもよりますが、あえて使わないという選択肢も忘れないことが大切です。一方で負債を残さないためにDDDやLayered Architectureは徹底したらしいです。
リプレースした方法
・一旦全ての機能追加を止めた
これはサービスの内容次第かと思われますが、はてなブックマークに関しては、一度全ての新規機能追加を停止してリプレース作業に専念したとのことです。 弊社でリプレースを検討した時にネックとなり、解決できないなとなった部分の一つです。
Aが既存サービスでBがリプレースしたサービスだとした時に、並行してAの新規開発を進めつつ、Bのリプレースが終わった時点で、Bは古い状態のサービスAと同じ仕様となってしまうため、BがAに追いつけないという問題が発生します。解決するためにはAを一時的に開発を止めるか、Bの開発速度をA以上にする必要があります。（予算や人員の問題で現実的に難しい）
・現行仕様の洗い出しを徹底的にやった
手戻りが起きないように、不要機能の整理、仕様の洗い出しを時間をかけて行ったとのこと。
・並行稼働させながら徐々に移行
エンジニアのモチベーションUPや対外的に進んでいる感を出すために、少しずつ既存サービスをScalaに変えて行ったとのこと。ただしサービスを稼働させながらのデータマイグレーションは辛かったとのことでした。
結果
当初の予定2年のところが4年かかってしまったらしいです。
しかし、サーバー台数を今までの半分にすることができ、レスポンスも早くなり、機能改修・追加も容易になったとのこと。
弊社もリプレースを考えるタイミングに来ており、参考にさせていただきたいと思います。
まとめ
Scala Matsuriは、発表の内容が楽しめるのはもちろん、細かい部分のホスピタリティが高く、行ってよかったなあと思えるカンファレンスでした。素敵なカンファレンスを開催してくれた運営の方、発表者の方、ありがとうございました。
最後に宣伝ですが、このように弊社ではカンファレンス参加費を補助してくれる制度があり、申請をすれば、平日もカンファレンスに行ける環境が整っております。（Slackで上長に申請すればOKです）
SHOWROOMでは、一緒に働いてくれるエンジニアを募集中です！
