scala: mobile backend on aws

Developers.IO 2016

B-1

荒井祐輔

Ⓒ Classmethod, Inc.

2016年02月20日

Scala: Mobile Backend on AWS

1

#cmdevio2016 #B

whoami

• Yusuke Arai

• Classmethod (2014/11~)

• Mobile Backend API Team (2015/02~)

• AWS / Scala / Javascript / android

• dev.classmethod.jp/author/arai-yusuke

http://dev.classmethod.jp/author/arai-yusuke

Today's topics

• Scalaのoverview

• Scalaを使ったモバイルバックエンドAPI

• なぜAWSネイティブの時代にScalaが必要か

• How to 説得 your client in "Scala使います!"

Scalaのoverview

Martin OderskyDeutscher Informatiker / 1958~

Scala

• JVM言語（Javaバイトコードを生成）

• Javaの既存コードを直接参照可能

• 強い静的型付け言語

• 名前は"Scalable"から

Scala の文法

• セミコロンのないJavaっぽくも書ける

• Rubyっぽくも書ける

• 記述量が少ない

• 詳しくはググってくださいm(_ _)m

Scala のウソ・ホント

よく耳にする話

• 関数型のプログラミング言語

• Rubyに近いのでLL経験者なら楽勝

• Javaがわかればすぐに書けるようになる

• エコシステム（Play）はRailsライク

全部ウソです

• 関数型のプログラミング言語

• Rubyに近いのでLL経験者なら楽勝

• Javaがわかればすぐに書けるようになる

• エコシステム（Play）はRailsライク

Scala のホント

Scalaのホント

• 洗練されたOOP言語ただしHaskellの影響を強く受けており、関数型の書き方で書くことも可能になっている

• JVMやJava言語への理解が必要

• エコシステム（Play）は強力な型システムを内包しFP, FRPを前提としている

Not 関数型言語

• 結構ある勘違い「Scalaは関数型言語DA!」

• Scala自体は洗練されたOOP言語

• ただし純粋関数ベースの開発を強くサポートしてる

• Haskellと同じ書き方をしようと思えば可能

主な理由としてScalaがアドホック多相性を表現できるから

Java/JVMの理解が必要

• JVMが型消去モデルであること（重要）

• GenericsはJava 1.5で追加されたこと,

ClassManifestの挙動, etc…

• Javaの文法などよりも、Javaの歴史に対する理解が必要

☓ LL話者なら馴染みやすい

• ScalaはaltJavaとしても利用できるが

それは"Scala言語"に限った話で、エコシステムがそれを許すとは限らない

• Play Framework 2.4 は強力な型システムを内部に持ち、随所で型システムへの理解を要求する。

• 例: JsResult は Applicative Functor

Writes は Contravariant Functor

視点を変える

Scala を使っていけば……

• JVMやJavaの歴史について深く理解できる

• 関数型のグッドプラクティスが取り込める

• 型クラス、代数的データ型、関手、モナドなどの鉄板パターンが使えるようになる

• 新しめの言語ではだいたい↑が一部または全部使える

例えばSwiftにもflatMapメソッドが用意されています

• 新しい機能を使いこなし品質の高いアプリを作ることが可能に！

Scalaのoverview は

こんな感じです

Today's topics





Scalaを使ったモバイルバックエンドAPI

モバイルAPIサーバーを作った

• 受託モバイルアプリ案件

• リリース後はC100Kがほぼ間違いない

• 安定して捌くためにフロントAPIサーバーには Play-Scalaを採用

• バックエンドもAkkaを使いたいという理由からPlay-Scalaにした

開発の進め方

• フルでテスト書く

（全クラスユニットテスト、API毎最低１結合テスト）

• pull reqレビュー必須

• ScalazやCatsは使わない

• 今リリース前なのでパフォーマンス・運用についてのことは何とも言えない（リリースできていたら運用ノウハウをお伝えしたかったです……）

開発で感じたこと

えげつないほど書きやすい

• ボイラープレートコードの少なさに咽び泣く

• 言語そのものがImmutableを推してくれてることの有り難みを思い知る

• 別にカッコよく書こうとしてないのに関数は

だいたい5行以内にまとまる

めっちゃ読みやすい

• 「Scalaは記号ばっかで読みにくい」ってとおい昔に聞いたことがあった

• それは超Haskellっぽく書いた場合の話だった

• シンプルに書いていくと英語っぽい文脈を持つ

• pull reqレビューが捗る

なんとなく英語っぽいのです

Akka

• 今回はワーカーをAkka Schedulerで実装

• AkkaのFault Toleranceを買った

• Amazon SQSやAmazon SNSとうまく結合する

• DynamoDB StreamやKinesisとくっつけたら絶対楽しいでよすね

AWS Java SDKが使える

• AWSのフルマネージドサービス（CognitoやDynamoDB）とやり取りするアプリを作る場合、AWS SDKのドキュメンテーション具合は死活問題

• AWS Java SDKには何の心配もなかった

• Scalaの言語思想として「mutable実装をimmutableなインタフェースで隠蔽」というのがある

→ AWS Java SDK はインフラ層で隠蔽できるので無問題

アーキテクチャの利点（1）

• 純粋関数型言語だとmain関数の外側、つまり自分でコントロールできない領域まで副作用を遅延しなければならない（ことが多い）

• Scalaでは副作用を起こすタイミングを自分で

コントロールしてOK※ HaskellにもunsafePerformIOとかはありますが……

• 本当に遅延すべき副作用（ドメインロジックが起こす副作用）とそれ以外（ログとか）を別のものとして扱うことが容易

ソフトウェア

アーキテクチャの利点（2）

• 言語レベルでDIを強くサポートするのでDIP達成の前提があるアーキテクチャと馴染む

• Layered Architecture, Onion Architecture…

• DDDなどでよく採用されるアーキテクチャ

ソフトウェア

続きはまた後で時間に余裕があれば

Today's topics





なぜAWSネイティブ時代に Scalaが必要か

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

• 一つの役割をもった疎結合で小さなサービス（コンポーネント）の集合で大きなサービス（アプリケーション）を構築する

• それぞれのサービスはDockerコンテナやEC2インスタンスとして表現される

• マイクロサービス同士はHTTPSなどで通信

実際どうなの

• ScalaMatsuri 2016で色々なセッションを聞いて来ましたが「リアクティブ」や「マイクロサービス」にまつわるセッションが多数

• 日本の方よりも海外の方のセッション多し

→ 海外では既にデファクトになってきてそう

• “リアクティブはResiliencyのための手段である”

更に先を眺める

その先に控えるのは

が主体のアーキテクチャ

AWS Lambda が主体へ

• バックエンドにあるmicro servicesへのオーケストレーションではない

• ドメインロジックがAWS Lambda Functionとして表現されるサーバーレスアーキテクチャ

• 単位が micro services から functions へ

Evolution of Compute – Public Cloud

InfrastructureInstances

Application code

©Amazon Web Services via http://www.slideshare.net/AmazonWebServices/arc308-the-serverless-company-using-aws-lambda/

Evolution of Compute – Containers

InfrastructureInstances

Application codeContainers


Evolution of Compute – ServerlessApplication code


実際どうなの

• AWS re:Invent 2015でマイクロサービス関連のセッションが多く発表される中で、世界に向けて発信された概念（発表されたのはすでに実践されたもの）

• いずれ、必ず来るサーバーレスの未来を象徴している

• その”未来”が来る日のことを、

個人的に”Lambda Xデー”と呼んでます

深みにダイブしたい方は弊社丹内の記事をぜひチェック！

reinvent2015 マイクロサービス

For Your Information

2015.02 Lambda in VPC!!©Amazon Web Services

via http://aws.typepad.com/aws_japan/2016/02/access-resources-in-a-vpc-from-your-lambda-functions.html

http://aws.typepad.com/aws_japan/2016/02/access-resources-in-a-vpc-from-your-lambda-functions.html

さて

でアプリケーションを開発する場合の選択肢

Scala in AWS Lambda

• LambdaはScalaで書けます。これはScalaに限った話ではなく、JVM言語ならOK。

• ざっと試した感じでは無理やり感がでることもなく、いい感じに書けます。

• 技術調査を進めていて、もう少しナレッジが溜まれば近いうちに本番適用可能になりそう。

Scala in AWS Lambda

• LambdaはScalaで書けます。これはScalaに限った話ではなく、JVM言語ならOK。

• ざっと試した感じでは無理やり感がでることもなく、いい感じに書けます。

• 技術調査を進めていて、もう少しナレッジが溜まれば近いうちに本番適用可能になりそう。

この辺りを掘り下げる話を５月に福岡でします！

【Scala福岡2016】で検索検索！

なぜScalaを選ぶべきか

• AWS Lambdaを使う上で乗り越えなければならないのは”結合テストの書きにくさ”

• 結合テストガンガン書いてぴゅんぴゅん進めようぜという文化とはうまく合致しない

• ユニットテストのみでより多くの心配事を解消するにはどうすべきか

なぜScalaを選ぶべきか

• AWS Lambdaを使う上で乗り越えなければならないのは”結合テストの書きにくさ”

• 結合テストガンガン書いてぴゅんぴゅん進めようぜという文化とはうまく合致しない

• ユニットテストのみでより多くの心配事を解消するにはどうすべきか

強い静的型システムの堅牢さと関数型の異常系表現力を駆使すべし！

rapture.core.Resultvia https://github.com/propensive/rapture

https://github.com/propensive/rapture

scalaz.\/via https://github.com/scalaz/scalaz

（EitherTもあるんだよ！）

https://github.com/scalaz/scalaz

scala.util.Eithervia https://github.com/scala/scala

https://github.com/scala/scala

関数型の異常系表現力

• ある振る舞いをテストするにあたり、その振る舞いが起こす副作用込みでテストするのではなく、異常系やIOアクセスを表現可能な型を扱い、副作用の発生箇所をギリギリまでアプリケーションの外側に持ち越すようにすることで、副作用発生直前の値が正しいこと（==）を保証するテストが書ける。

現状の細かいCons

• Artifact ZIPに50MB制限がある→ 作り方を工夫する必要があるものの、

　マイクロサービスの考え方を継承するならば

　対処可能な制限

• JVMの初回起動コストがオーバーヘッドに？

→ Lambda in VPCならばENIコストもあるので、

　初回は遅いものと割り切る

一番伝えたかった事なのでちょっと振り返り

なぜAWS時代にScalaか

• Lambda Xデーは必ず来る

• 大規模アプリをLambdaで作る日がくる

• AWS結合テストを無理やり書くのではなくユニットテストで担保できる領域を増やす

• そういう書き方を強くサポートしているのがScala

Today's topics





How to 説得 your client in "Scala使いたい!"

"Play-Scalaを使います!" という提案をするためにはいくつかのFrameworkと比較検討を行う必要があった

代表的Framework

• Ruby on Rails (Ruby)

• Express (Node.js)

• Laravel (PHP)

• Play Framework (Java)

• etc

前哨戦 vs Rails, Node, PHP

vs Rails, Node, PHP

• Play-Scalaとは問題解決のモデルがはっきり違うので、説明（説得）しやすい。

• 耐障害性（Resiliency）, 伸縮性（Elasticity）

信頼性（Reliability）などで圧勝する。

• 強いて言えば1インスタンスでC100Kの功績があるNodeが一番のライバル。

耐障害性（Resiliency）

• AkkaのFault Tolerance戦略はErlang/OTPなどと並び最強クラスの耐障害性を提供

• 仕組みを理解して正しく使えば、金融基盤やインフラ基盤に用いうるレベル

• 前哨戦では説得のメインウェポン

伸縮性（Elasticity）

• 広義でのスケーラビリティ

• Akkaベースのクラスタリングが容易

• PlayもAkkaの仕組みの上で動いている

• Play-Scalaの単体処理性能はNodeより高い

※ 2015/05時点のベンチマーク

信頼性（Reliability）

• なんだかんだ言ってもJVMで動くアプリ

• JVMの歴史と信頼性をそのまま引き継ぐことができる

• チューニングから運用まで実績・文献ともに豊富

• javapコマンドなどで解析すると結構読めます

耐障害性、伸縮性、信頼性をしっかり抑えれば

Rails, Node, PHPに競り負けることはない

※ APIサーバー開発の話です

難攻不落 vs Java

先ほど挙げた耐障害性、伸縮性、信頼性は

それぞれ Play, Akka → 耐障害性

Akka → 伸縮性 JVM → 信頼性

Play-Java

Akka for Java

えっ、それJavaでいいですよね？

難攻不落 vs Java

JavaよりScalaを使いたい理由

• コード記述量が圧倒的に少ない（ナウい）

• 関数型で書ける（ナウい）

• Akka, PlayはScalaで書かれてるから追いやすい

• …だけじゃなくSparkとかKafkaとか最近の

重要なOSSがScalaで書かれまくってる（ナウい）

Javaを使ってほしい理由

• 言語話者の母数が圧倒的に多い

• ゆえにハイアリングが楽

• ゆえに保守・運用体制を立てやすい

• ゆえに安心感がある

本当にそうでしょうか？

Java8を実務レベルで書けるエンジニアって

そんなに多いんでしょうか

(StreamAPIにflatMapとかありますけどそれは大丈夫なんですかね)※ScalaにもSwiftにもHaskell(*bind)にもあるよ！

Java8話者かつDDD話者のエンジニアのハイアリングってそんなに楽でしょうか

Java7話者を育てればよい？

ならScalaでやりましょう！

"JavaよりもScala"を説得する

• Scalaを使った場合の利点を説明し

• Java8話者が必ずしも多くなく、かつJava8にはかなり学習コストがかかることを説明し

• （上司には）同じ学習コストを払うならばScalaを使うべきだと伝えるべし！

• （お客さんには）Scalaでもリスク大差ないと伝えるべし！

時間に余裕があればここで Scala愛を語る

電撃、初恋、相手のこともっと知りたい、…

まとめ

まとめ

• Scalaは関数型もできるOOP言語ですよ！

• 来るLambda Xデーには、Scalaは開発者に多くの幸せをもたらすでしょう。

• Resiliency, Elasticity, Reliability!!

• Scalaを使う利点をしっかり説明した上で“Javaならば安心” という幻想をぶち壊す！

scala: mobile backend on aws

Technology