More Related Content
What's hot
What's hot (20)
Similar to Scala: Mobile Backend on AWS
Similar to Scala: Mobile Backend on AWS (20)
Recently uploaded
Recently uploaded (8)
Scala: Mobile Backend on AWS
- 1. Developers.IO 2016 B-1 荒井 祐輔 Ⓒ Classmethod, Inc. 2016年02月20日 Scala: Mobile Backend on AWS 1
- 3. whoami • Yusuke Arai • Classmethod (2014/11~) • Mobile Backend API Team (2015/02~) • AWS / Scala / Javascript / android • dev.classmethod.jp/author/arai-yusuke
- 4. Today's topics • Scalaのoverview • Scalaを使ったモバイルバックエンドAPI • なぜAWSネイティブの時代にScalaが必要か • How to 説得 your client in "Scala使います!"
- 5. Today's topics • Scalaのoverview • Scalaを使ったモバイルバックエンドAPI • なぜAWSネイティブの時代にScalaが必要か • How to 説得 your client in "Scala使います!"
- 7. Martin Odersky Deutscher Informatiker / 1958~
- 8. Scala • JVM言語（Javaバイトコードを生成） • Javaの既存コードを直接参照可能 • 強い静的型付け言語 • 名前は"Scalable"から
- 9. Scala の文法 • セミコロンのないJavaっぽくも書ける • Rubyっぽくも書ける • 記述量が少ない • 詳しくはググってくださいm(_ _)m
- 10. Scala のウソ・ホント
- 11. よく耳にする話 • 関数型のプログラミング言語 • Rubyに近いのでLL経験者なら楽勝 • Javaがわかればすぐに書けるようになる • エコシステム（Play）はRailsライク
- 12. 全部ウソです • 関数型のプログラミング言語 • Rubyに近いのでLL経験者なら楽勝 • Javaがわかればすぐに書けるようになる • エコシステム（Play）はRailsライク
- 13. Scala のホント
- 14. Scalaのホント • 洗練されたOOP言語 ただしHaskellの影響を強く受けており、関数型の 書き方で書くことも可能になっている • JVMやJava言語への理解が必要 • エコシステム（Play）は強力な型システムを内包し FP, FRPを前提としている
- 15. Not 関数型言語 • 結構ある勘違い「Scalaは関数型言語DA!」 • Scala自体は洗練されたOOP言語 • ただし純粋関数ベースの開発を強くサポートしてる • Haskellと同じ書き方をしようと思えば可能 主な理由としてScalaがアドホック多相性を表現でき るから
- 16. Java/JVMの理解が必要 • JVMが型消去モデルであること（重要） • GenericsはJava 1.5で追加されたこと, ClassManifestの挙動, etc… • Javaの文法などよりも、Javaの歴史に対する 理解が必要
- 17. ☓ LL話者なら馴染みやすい • ScalaはaltJavaとしても利用できるが それは"Scala言語"に限った話で、エコシステムがそれを 許すとは限らない • Play Framework 2.4 は強力な型システムを内部に持ち、 随所で型システムへの理解を要求する。 • 例: JsResult は Applicative Functor Writes は Contravariant Functor
- 18. 視点を変える
- 19. Scala を使っていけば…… • JVMやJavaの歴史について深く理解できる • 関数型のグッドプラクティスが取り込める • 型クラス、代数的データ型、関手、モナド などの鉄板パターンが使えるようになる • 新しめの言語ではだいたい↑が一部または全部使える 例えばSwiftにもflatMapメソッドが用意されています • 新しい機能を使いこなし品質の高いアプリを作ることが可能に！
- 21. Today's topics • Scalaのoverview • Scalaを使ったモバイルバックエンドAPI • なぜAWSネイティブの時代にScalaが必要か • How to 説得 your client in "Scala使います!"
- 23. モバイルAPIサーバーを作った • 受託モバイルアプリ案件 • リリース後はC100Kがほぼ間違いない • 安定して捌くためにフロントAPIサーバーには Play-Scalaを採用 • バックエンドもAkkaを使いたいという理由から Play-Scalaにした
- 25. 開発の進め方 • フルでテスト書く （全クラスユニットテスト、API毎最低１結合テスト） • pull reqレビュー必須 • ScalazやCatsは使わない • 今リリース前なのでパフォーマンス・運用についてのことは何とも 言えない（リリースできていたら運用ノウハウをお伝えしたかったです……）
- 26. 開発で感じたこと
- 27. えげつないほど書きやすい • ボイラープレートコードの少なさに咽び泣く • 言語そのものがImmutableを推してくれてる ことの有り難みを思い知る • 別にカッコよく書こうとしてないのに関数は だいたい5行以内にまとまる
- 28. めっちゃ読みやすい • 「Scalaは記号ばっかで読みにくい」って とおい昔に聞いたことがあった • それは超Haskellっぽく書いた場合の話だった • シンプルに書いていくと英語っぽい文脈を持つ • pull reqレビューが る
- 29. なんとなく英語っぽいのです
- 30. Akka • 今回はワーカーをAkka Schedulerで実装 • AkkaのFault Toleranceを買った • Amazon SQSやAmazon SNSとうまく結合する • DynamoDB StreamやKinesisとくっつけたら 絶対楽しいでよすね
- 31. AWS Java SDKが使える • AWSのフルマネージドサービス（CognitoやDynamoDB） とやり取りするアプリを作る場合、 AWS SDKのドキュメンテーション具合は死活問題 • AWS Java SDKには何の心配もなかった • Scalaの言語思想として「mutable実装をimmutableなイン タフェースで隠 」というのがある → AWS Java SDK はインフラ層で隠 できるので無問題
- 32. アーキテクチャの利点（1） • 純粋関数型言語だとmain関数の外側、つまり自分でコント ロールできない領域まで副作用を遅延しなければならない （ことが多い） • Scalaでは副作用を起こすタイミングを自分で コントロールしてOK ※ HaskellにもunsafePerformIOとかはありますが…… • 本当に遅延すべき副作用（ドメインロジックが起こす副作用） とそれ以外（ログとか）を別のものとして扱うことが容易 ソフトウェア
- 33. アーキテクチャの利点（2） • 言語レベルでDIを強くサポートするので DIP達成の前提があるアーキテクチャと馴染む • Layered Architecture, Onion Architecture… • DDDなどでよく採用されるアーキテクチャ ソフトウェア
- 35. Today's topics • Scalaのoverview • Scalaを使ったモバイルバックエンドAPI • なぜAWSネイティブの時代にScalaが必要か • How to 説得 your client in "Scala使います!"
- 37. マイクロサービス アーキテクチャ
- 38. マイクロサービスアーキテクチャ • 一つの役割をもった疎結合で小さなサービス （コンポーネント）の集合で大きなサービス （アプリケーション）を構築する • それぞれのサービスはDockerコンテナやEC2 インスタンスとして表現される • マイクロサービス同士はHTTPSなどで通信
- 40. 実際どうなの • ScalaMatsuri 2016で色々なセッションを 聞いて来ましたが「リアクティブ」や「マイクロ サービス」にまつわるセッションが多数 • 日本の方よりも海外の方のセッション多し → 海外では既にデファクトになってきてそう • “リアクティブはResiliencyのための手段である”
- 41. 更に先を眺める
- 43. AWS Lambda が主体へ • バックエンドにあるmicro servicesへの オーケストレーションではない • ドメインロジックがAWS Lambda Functionと して表現されるサーバーレスアーキテクチャ • 単位が micro services から functions へ
- 44. Evolution of Compute – Public Cloud InfrastructureInstances Application code ©Amazon Web Services via http://www.slideshare.net/AmazonWebServices/arc308-the-serverless-company-using-aws-lambda/
- 45. Evolution of Compute – Containers InfrastructureInstances Application codeContainers ©Amazon Web Services via http://www.slideshare.net/AmazonWebServices/arc308-the-serverless-company-using-aws-lambda/
- 46. Evolution of Compute – Serverless Application code ©Amazon Web Services via http://www.slideshare.net/AmazonWebServices/arc308-the-serverless-company-using-aws-lambda/
- 47. 実際どうなの • AWS re:Invent 2015でマイクロサービス関連のセッ ションが多く発表される中で、世界に向けて発信され た概念（発表されたのはすでに実践されたもの） • いずれ、必ず来るサーバーレスの未来を象徴している • その”未来”が来る日のことを、 個人的に”Lambda Xデー”と呼んでます
- 51. 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
- 52. さて
- 57. Scala in AWS Lambda • LambdaはScalaで書けます。これはScalaに限った話 ではなく、JVM言語ならOK。 • ざっと試した感じでは無理やり感がでることもなく、 いい感じに書けます。 • 技術調査を進めていて、もう少しナレッジが溜まれば 近いうちに本番適用可能になりそう。
- 58. Scala in AWS Lambda • LambdaはScalaで書けます。これはScalaに限った話 ではなく、JVM言語ならOK。 • ざっと試した感じでは無理やり感がでる こともなく、いい感じに書けます。 • 技術調査を進めていて、もう少しナレッジが溜まれば 近いうちに本番適用可能になりそう。 この辺りを掘り下げる話を５月に福岡でします！ 【Scala福岡2016】で検索検索！
- 59. なぜScalaを選ぶべきか • AWS Lambdaを使う上で乗り越えなければならな いのは”結合テストの書きにくさ” • 結合テストガンガン書いてぴゅんぴゅん進めようぜ という文化とはうまく合致しない • ユニットテストのみでより多くの心配事を 解消するにはどうすべきか
- 60. なぜScalaを選ぶべきか • AWS Lambdaを使う上で乗り越えなければならな いのは”結合テストの書きにくさ” • 結合テストガンガン書いてぴゅんぴゅん進めようぜ という文化とはうまく合致しない • ユニットテストのみでより多くの心配事を 解消するにはどうすべきか 強い静的型システムの堅牢さと 関数型の異常系表現力を駆使すべし！
- 65. 現状の細かいCons • Artifact ZIPに50MB制限がある → 作り方を工夫する必要があるものの、 マイクロサービスの考え方を継承するならば 対処可能な制限 • JVMの初回起動コストがオーバーヘッドに？ → Lambda in VPCならばENIコストもあるので、 初回は遅いものと割り切る
- 67. なぜAWS時代にScalaか • Lambda Xデーは必ず来る • 大規模アプリをLambdaで作る日がくる • AWS結合テストを無理やり書くのではなく ユニットテストで担保できる領域を増やす • そういう書き方を強くサポートしているのがScala
- 68. Today's topics • Scalaのoverview • Scalaを使ったモバイルバックエンドAPI • なぜAWSネイティブの時代にScalaが必要か • How to 説得 your client in "Scala使います!"
- 69. How to 説得 your client in "Scala使いたい!"
- 71. 代表的Framework • Ruby on Rails (Ruby) • Express (Node.js) • Laravel (PHP) • Play Framework (Java) • etc
- 72. 前 戦 vs Rails, Node, PHP
- 73. vs Rails, Node, PHP • Play-Scalaとは問題解決のモデルがはっきり 違うので、説明（説得）しやすい。 • 耐障害性（Resiliency）, 伸縮性（Elasticity） 信頼性（Reliability）などで圧勝する。 • 強いて言えば1インスタンスでC100Kの功績がある Nodeが一番のライバル。
- 74. 耐障害性（Resiliency） • AkkaのFault Tolerance戦略はErlang/OTPなど と並び最強クラスの耐障害性を提供 • 仕組みを理解して正しく使えば、金融基盤や インフラ基盤に用いうるレベル • 前 戦では説得のメインウェポン
- 75. 伸縮性（Elasticity） • 広義でのスケーラビリティ • Akkaベースのクラスタリングが容易 • PlayもAkkaの仕組みの上で動いている • Play-Scalaの単体処理性能はNodeより高い ※ 2015/05時点のベンチマーク
- 76. 信頼性（Reliability） • なんだかんだ言ってもJVMで動くアプリ • JVMの歴史と信頼性をそのまま引き継ぐことがで きる • チューニングから運用まで実績・文献ともに豊富 • javapコマンドなどで解析すると結構読めます
- 77. 耐障害性、伸縮性、信頼性を しっかり抑えれば Rails, Node, PHPに 競り負けることはない ※ APIサーバー開発の話です
- 78. 難攻不落 vs Java
- 79. 先ほど挙げた 耐障害性、伸縮性、信頼性は それぞれ Play, Akka → 耐障害性 Akka → 伸縮性 JVM → 信頼性
- 80. Play-Java
- 81. Akka for Java
- 82. JVM
- 84. 難攻不落 vs Java
- 85. JavaよりScalaを使いたい理由 • コード記述量が圧倒的に少ない（ナウい） • 関数型で書ける（ナウい） • Akka, PlayはScalaで書かれてるから追いやすい • …だけじゃなくSparkとかKafkaとか最近の 重要なOSSがScalaで書かれまくってる（ナウい）
- 86. Javaを使ってほしい理由 • 言語話者の母数が圧倒的に多い • ゆえにハイアリングが楽 • ゆえに保守・運用体制を立てやすい • ゆえに安心感がある
- 87. 本当にそうでしょうか？
- 90. Java7話者を育てればよい？
- 91. ならScalaで やりましょう！
- 92. "JavaよりもScala"を説得する • Scalaを使った場合の利点を説明し • Java8話者が必ずしも多くなく、かつJava8には かなり学習コストがかかることを説明し • （上司には）同じ学習コストを払うならばScalaを使うべき だと伝えるべし！ • （お客さんには）Scalaでもリスク大差ないと伝えるべし！
- 94. まとめ
- 95. まとめ • Scalaは関数型もできるOOP言語ですよ！ • 来るLambda Xデーには、Scalaは開発者に多くの幸 せをもたらすでしょう。 • Resiliency, Elasticity, Reliability!! • Scalaを使う利点をしっかり説明した上で “Javaならば安心” という幻想をぶち壊す！
- 97. Developers.IO 2016 ご静聴ありがとうございました。 スライドは後日ブログで公開します。 97 A-1 Ⓒ Classmethod, Inc. #cmdevio2016