値クラスを使っていて不可解な挙動があったので、まとめたのとその対処法をメモしておきます。
値クラスとはIntやStringが継承しているAnyValを継承させたクラスです。
一つの値しか持ちませんが拡張メソッドを実装できるため、DDDなどを実現するためのドメインモデルの記述に役立つ記法です。
値クラスと汎用トレイト - Scala Documentation
コンパイル時の型は統一されていますが、実行時の型が不定という問題。
上のように、コンパイル時の内部で保持している型は共にAttributesクラス（値クラス）なのですが、
実際に実行してみると、
ということで、非常に不便な状況です。
serverlessconfに参加してきました。
serverlessに関しての知見があまりなかったので、すごい有意義な勉強会となりました。
パネルディスカッションでも盛り上がっていましたが、 Serverlessとは何を指すのか？
実際にCPUなどのリソース管理をしないServerlessと FaaS（Function as a Service）の機能をベースとして構成としてのServerless の２つが議論に上がっていました。
自分なりには、前者に関してはいわゆるマネージドサービスであると思っているので、 後者のものをServerlessの概念として考えています。
Serverless自体が注目されてたのは、AWS lambdaがきっかけです。 AWS lambdaとは、サーバを管理するのではなく、コード（ファンクション）を管理するのみで、デプロイもコードです。 lambdaが呼び出されるたびに毎回起動してファンクションが実行されます。
そのlambdaの登場によってリソース管理が必要なくなります。 今まではサーバにデプロイしていたため、そのサーバの要件に対してリソースが少ない場合、作り直す必要がありました。 しかし、lambdaを利用する場合、リソースに関しては気にしなくてもよいのです。 そう、圧倒的に運用負荷が下がるのです。
www.slideshare.net
上記のスライドを是非見てもらいたいのですが、serverless の思想が示されています
ItoNaoyaさんも言っていましたが、マイクロサービス的観点だと、１サーバに載せる機能は境界づけられたコンテキスト内の内容でした。 しかし上記の思想を取り入れると、lambdaで担保するものは１機能になっていきます。
現状のlambdaでは、以下のデメリットがあります。
薄いサービスならば作成できると思いますが、全てをserverlessで置き換えることはまだまだ難しそうです。 そもそも、その要件が満たせる状況になっても置き換えるかというのは疑問です。 というのも、複雑なビジネスロジックであればあるほど、コードとして再利用がし辛くなり抽象化ができなくなってしまうからです。
では、対応例として考えられるものは
serverlessという単語自体が曖昧な単語となってしまって、実際バズワードにもなりそうですが、 今後一つの潮流として、素早いサービスを作る上で絶対に避けて通れない考え方だと思います。
サービスを作る際に、serverlessも一つの手法の対象として考えれるようにキャッチアップしていく必要がありそうです。
sprayフレームワークを使っていると、HTTPリクエストの部分はspray-canを利用すると思います。
しばらく、spray-canを使っていたのですが、いくつか重い処理を走らせるとCPUを使い切っていないのに、sprayがリクエストを受け付けなくなってしまい、502 BadGateway を出すようになってしまいました。
そこで色々試したのですが、結果として設定のconfをいじるのではなく、responseを非同期にすればできました。
負荷をかけると以下のような connection reset by peerという502エラーが発生しました。
read: connection reset by peer
application.confを色々いじってみましたが、結局実装が間違っていたため、根本的なパフォーマンスは変わりませんでした。
spray/application.conf at master · spray/spray · GitHub
が、本家のベンチマークに使っているconf設定です。
sprayのconfは、
以下のようにいじりました。
spray-stress/application.conf at master · moc-yuto/spray-stress · GitHub
が計測してもパフォーマンスは変わらず。。。
FutureDirectiveを使うことでした。
使い方は、
spray | Documentation » 1.2.2 / 1.3.2 » spray-routing » Predefined Directives (by trait) » List of predefined directives by trait » FuturesDirectives » onComplete
です。
レスポンスにFutureを組み込むことで、502エラーが発生していたものが一切発生しなくなり、パフォーマンスを一気にあげることができました。
負荷にはvegetaを使用しました。
https://github.com/tsenart/vegeta
vegeta attack -rate=100 -duration=30s -targets=st.txt > st.bin #st.txt GET http://localhost:8080/st
Get http://localhost:8080/st に対する結果
Requests [total, rate] 3000, 100.03 Duration [total, attack, wait] 44.486880886s, 29.989999801s, 14.496881085s Latencies [mean, 50, 95, 99, max] 7.155629141s, 4.389581282s, 22.700462005s, 30.001109336s, 30.003361727s Bytes In [total, mean] 0, 0.00 Bytes Out [total, mean] 0, 0.00 Success [ratio] 0.00% Status Codes [code:count] 0:3000 Error Set: Get http://localhost:8080/st: dial tcp 0.0.0.0:0->[::1]:8080: getsockopt: connection refused Get http://localhost:8080/st: dial tcp 0.0.0.0:0->[::1]:8080: i/o timeout
Get http://localhost:8080/st2 に対する結果
Requests [total, rate] 3000, 100.03 Duration [total, attack, wait] 43.215084995s, 29.989999893s, 13.22508510 2s Latencies [mean, 50, 95, 99, max] 6.767752449s, 2.182035276s, 30.002461808s , 30.005316637s, 30.074779909s Bytes In [total, mean] 30691, 10.23 Bytes Out [total, mean] 0, 0.00 Success [ratio] 31.10% Status Codes [code:count] 200:933 0:2067 Error Set: Get http://localhost:8080/st2: dial tcp 0.0.0.0:0->[::1]:8080: getsockopt: connection refused Get http://localhost:8080/st2: EOF Get http://localhost:8080/st2: read tcp 127.0.0.1:54219->127.0.0.1:8080: read: c onnection reset by peer Get http://localhost:8080/st2: read tcp 127.0.0.1:54217->127.0.0.1:8080: read: c onnection reset by peer
以上のような結果になりました。
さらにパラメータをチューニングした値は、また別途検証したいと思います。
負荷を受けさせたソースはこちら
github.com
以前（http://yuutookun.hatenablog.com/entry/2015/04/04/190539）、ドメイン駆動に関して調べてみてから、ちょこちょこ勉強しつつ、ちょうど自分の新規プロジェクトが動き始めたので、反映させてみた感想をまとめてみました。
・採用したDDD手法
・言語
・パッケージ構成
・どうやって作っていったか
・良かったところ
・悪かったところ
昔ながらのレイヤードであったり、オニオンだったり、ヘキサゴナルだったりありますが、
今回はクリーンアーキテクチャを採用しました。
Scalaで実装しています
以下を参考に作成しました。
https://speakerdeck.com/yoskhdia/ddd-plus-clean-architecture-plus-ucdom-fullban
http://qiita.com/kondei/items/41c28674c1bfd4156186
https://speakerdeck.com/usrnameu1/genbafalsekurinakitekutiya-scala-play-puroziekutoshe-ji-falseohua
|- domain # データモデル
L enum # ドメインに定数
|- usecase # コアロジック（旧Model）, 別パッケージからは呼び出さない
|- util or service # 状態を持たないutil系
L adaptor # 各usecaseとcontrollerと橋渡し (daoとのやり取りなど)
|- repository # DBとのアクセス
|- input # リクエストを受け取る型の定義
|- output # レスポンスを受け取る型の定義
L transformer # repository層とuse case層の型変換
|- controller # リクエスト受け取り部分
|- input # リクエストを受け取る型の定義
|- output # レスポンスを受け取る型の定義
L transformer # controller層とuse case層の型変換
ドメイン駆動開発（以下DDD）は、ドメインエキスパート（そのビジネス領域に関してのエキスパート）との対話によって、設計を行う手法です。
まずは、何がエンティティで何が値オブジェクトかを確定させます。
エンティティに応じた操作をusecaseで記述します。
DBとのアクセスはrepositoryを通じて行います。
http ⇔ controller ⇔ use case ⇔ repository ⇔ DB
entity
DBで使うオブジェクトとフロントで使うオブジェクトがキレイに切り離されるので、影響範囲が特定しやすいです。
Entityをベースに考えるので、アウトプットを変えたいと言う時に、アウトプットのオブジェクトを作って、そこにEntityの情報を突っ込むだけで追加できるというのが変更に強いです。
やはり、モデルの変換が多いため、実装がどうしても多くなってしまいます。
まだそこまで大きな範囲には適用していないのですが、DDDの威力が垣間見れました。
特にScalaは、DDDと相性がいいなーと思った次第です。
