scala: mobile backend on aws
Post on 15-Apr-2017
140 Views
Preview:
TRANSCRIPT
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
Today's topics
• Scalaのoverview
• Scalaを使ったモバイルバックエンドAPI
• なぜAWSネイティブの時代にScalaが必要か
• How to 説得 your client in "Scala使います!"
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のoverview
• Scalaを使ったモバイルバックエンドAPI
• なぜAWSネイティブの時代にScalaが必要か
• How to 説得 your client in "Scala使います!"
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
• Scalaのoverview
• Scalaを使ったモバイルバックエンドAPI
• なぜAWSネイティブの時代にScalaが必要か
• How to 説得 your client in "Scala使います!"
なぜAWSネイティブ時代に Scalaが必要か
マイクロサービス アーキテクチャ
マイクロサービスアーキテクチャ
• 一つの役割をもった疎結合で小さなサービス（コンポーネント）の集合で大きなサービス（アプリケーション）を構築する
• それぞれのサービスはDockerコンテナやEC2インスタンスとして表現される
• マイクロサービス同士はHTTPSなどで通信
© NGINX via https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/
実際どうなの
• 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
©Amazon Web Services via http://www.slideshare.net/AmazonWebServices/arc308-the-serverless-company-using-aws-lambda/
Evolution of Compute – ServerlessApplication code
©Amazon Web Services via http://www.slideshare.net/AmazonWebServices/arc308-the-serverless-company-using-aws-lambda/
実際どうなの
• 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
さて
でアプリケーションを開発する場合の選択肢
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を使う上で乗り越えなければならないのは”結合テストの書きにくさ”
• 結合テストガンガン書いてぴゅんぴゅん進めようぜという文化とはうまく合致しない
• ユニットテストのみでより多くの心配事を解消するにはどうすべきか
強い静的型システムの堅牢さと 関数型の異常系表現力を駆使すべし！
関数型の異常系表現力
• ある振る舞いをテストするにあたり、その振る舞いが起こす副作用込みでテストするのではなく、異常系やIOアクセスを表現可能な型を扱い、副作用の発生箇所をギリギリまでアプリケーションの外側に持ち越すようにすることで、副作用発生直前の値が正しいこと（==）を保証するテストが書ける。
現状の細かいCons
• Artifact ZIPに50MB制限がある→ 作り方を工夫する必要があるものの、
マイクロサービスの考え方を継承するならば
対処可能な制限
• JVMの初回起動コストがオーバーヘッドに？
→ Lambda in VPCならばENIコストもあるので、
初回は遅いものと割り切る
一番伝えたかった事なので ちょっと振り返り
なぜAWS時代にScalaか
• Lambda Xデーは必ず来る
• 大規模アプリをLambdaで作る日がくる
• AWS結合テストを無理やり書くのではなくユニットテストで担保できる領域を増やす
• そういう書き方を強くサポートしているのがScala
Today's topics
• Scalaのoverview
• Scalaを使ったモバイルバックエンドAPI
• なぜAWSネイティブの時代にScalaが必要か
• How to 説得 your client in "Scala使います!"
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
JVM
えっ、 それ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ならば安心” という幻想をぶち壊す！
Developers.IO 2016
ご静聴ありがとうございました。 スライドは後日ブログで公開します。
97
A-1
Ⓒ Classmethod, Inc.
#cmdevio2016
top related