Runner in the High

技術のことをかくこころみ

依存関係について再び考える

izumisy-tech.hatenablog.com

  • あとからこの過去記事を読み返して「ムム」と思うところがあったので改めて。

  • CategoryId ではなく Category を引数として渡すことでデータ構造が隠蔽されているという旨の説明をしているが、これは fetchArtclesByCategory を呼び出す側の責務が「Categoryの データとしてIDが取れる」という知識を持ってしまうのを防げるという意味で書いたのではないかと思う。

  • けれどもその実装だと、結局 fetchArticlesByCategory 関数側が、引数として受け取る Category からIDを取り出すという処理をせなばならず、ID呼び出しでないという設計指針が fetchArticlesByCategory に対して Category への依存を与えてしまっている。

  • この依存が別に構わないという可能性もあり、たとえば Categoryドメインモデルなのであれば、そのドメインモデルに対して単方向の依存を持つクリーンアーキテクチャ的観点でいうところの外部のレイヤとして fetchArticlesByCategory が存在していると考えることもできるので、さほど問題を感じなくなる。

  • ところで fetchArticlesByCategory 関数を呼び出すのは、アプリケーションの責務のうち誰になるのだろうか... またまたクリーンアーキテクチャを考えてしまうが、おそらくユースケース層ではないかと思う。

  • DDD的観点: CategoryId を渡す場合においての別の懸念点としては、もしも CategoryIdCategory という集約ルートにおける値オブジェクトだとしたら、それを CategoryId 単体で受け取ってしまえるインターフェースもった関数 fetchArticlesByCategoryId があることで、利用者によって不変条件を保たずにつくられたおかしな CategoryId が渡ってくる可能性があるのではないかということ。正直ここは実装の問題のような気もするけど...

クラウドバンクをやっている

OneTapBUYをやっていたときもこういう記事を書いていたので今回はクラウドバンクについて書く izumisy-tech.hatenablog.com

つい最近クラウドバンクも始めた。いまのところ投資額はOneTapBUYと同じくらいだが、パフォーマンスで言うと年6〜7%といったところらしく、さほどリスキーではなさそうな利幅でよろしいと思う。こちらもどういう風にお金が増えるのか楽しみだ。

ちょうどこの記事を書いた2017年の10月から始めていた。結論からいうと、自分のクラウドバンクのパフォーマンスは年利で3.8%という感じになっている。

f:id:IzumiSy:20180805121827p:plain

今現在で80万程度つっこんでいるわけだが、それで増えたのが1.8万くらい。こう見るとOneTapBUYにもっとお金を突っ込んでいたほうが今頃には利益がもっと出ていたかもしれない。

2017年の10月の記事ではOneTapBUYでは12万で1万の利益がでている! みたいに書いたが、その翌月には5000近くまで下がってしまっていた。もちろん株なんてものはそうやって上がったり下がったりするものではあるが「こういうの、いつも気になってしまってソワソワしてしまうな〜」という感覚を持った。その当時はまだ学生で毎月定期的な収入があるわけでもなかったため、いわゆるドルコスト平均法のような積立戦略を実践するにも難しさがあり、短期的な売買に終始していたからという理由もある。

その点クラウドバンクはある意味ただの投資に近いので、自分の利益が上がったり下がったりするのを見る必要はないし、そもそも見えない。預けたものに毎月分配金がつくだけでシンプル。見方を変えれば、株と違って自分で取捨選択をしている感覚がないので、地味といえば地味ではある。とはいえ、社会人にもなるとそんなに毎日自分のポートフォリオの上がり下がりを見ている余裕はそんなにないので、どちらかといえば勝手に誰かがやっていてくれるほうがうれしいというものだ。そういう理由もあって2017年の11月にはOneTapBUYで投資していた分を5000円プラスで売却し、クラウドバンクに突っ込むことにしたのだ。

f:id:IzumiSy:20180805122942p:plain

ココ最近のペースでは毎月3000円くらいの分配金が入ってきている。毎月一回くらい飲み会にタダでいける程度ではあるが、それでもこうやってお金が増えていく様子をみるのはうれしいものがある。

JavaScriptにおける配列操作の計算量オーダー

日本語だとググっても出てこなかったのでまとめた

操作 計算量
添字アクセス O(1)
挿入(splice) O(n)
削除(splice) O(n)
削除(delete) O(1)
最後に追加 O(1)
先頭に追加 O(n)
スワップ O(1)

添字アクセスがO(1)だったりするのは、JavaScriptの配列は連結リストなどではなく単なるインデクスをキーで持つObjectだから。

ちなみにdeleteを使った削除というのはspliceと違って要素がundefinedと交換されるだけのものなので後続要素への走査が走らないためO(1)になる。

参考: https://stackoverflow.com/questions/11514308/big-o-of-javascript-arrays

結果整合性について

歴史

  • かつて、分散システムのデータ複製における唯一無二の理想は「更新されたデータは即座に反映される」というものだった。
  • 70年台の分散システム技術において試みられているものの多くは、いくら背後にたくさんのシステムが控えているとしても「使う人間からはひとつのシステムを使っている」ように見せることで、その観点から主に議論されていたものの多くはデータの一貫性(Consistency)をいかにして獲得するかという部分に主眼が置かれたものだった。
  • 90年台中頃からインターネット・システムの規模が大型化してくると、開発者の多くはデータの一貫性を犠牲にしてもスケーラビリティを担保することが重要なのではないかと考えはじめた。
  • AWSは世界規模で利用されるシステムを開発するにあたってあらゆる場所でレプリケーション技術を活用してきたが、その中で結果整合性モデルはレプリケーションにおいてデータの一貫性を担保するための技術として提供されてきた。
  • AmazonのCTOであるWerner Vogelsは「並行処理における書き込み・読み込みパフォーマンスの担保」と「データロックによるノードの可用性の低下の抑止」の2つの観点から、データの一貫性はスケーラブルな大規模システムにおいてはさほど重視される必要はないと考えている。

強整合性と結果整合性の違い

強整合性 結果整合性
データのロック あり なし
スケーラビリティ 低い 高い
一貫性 担保される すぐには担保されない
  • 強整合性 の場合、データの更新の際にデータベースをロックすることによってデータの一貫性(Consistency)を担保するが、ロックされる期間が長いほどその間のデータベース・アクセスがブロックされ、可用性(Availability)を犠牲にすることになる。
  • 結果整合性 はデータの更新でデータベースがロックされることはないため、可用性とスケーラビリティを維持することができる。その代わりノード間でのデータの一貫性はデータ複製にかかる時間に依存することになるため、必ずしも担保されない。

その他

結果整合性は必ずしも高度な分散システム固有の難解な技術ではなく、多くのモダンなRDBMSは同期・非同期レプリケーションのシステムが組み込まれている。同期的レプリケーションの場合にはレプリケーションの更新はトランザクションの一部として行われるが、非同期的レプリケーショントランザクションログの伝播の前にプライマリーでのデータ更新が失敗すると、ノード間で一貫性のないデータが生まれることになる。つまり非同期レプリケーションRDBMSにおける古典的な結果整合性のケースのひとつである。

参考

AnyValを継承する意味

ScalaでDDDなコードのアプリケーションを作ろうとしているときに UserId など値型はどうするべきか の記事を読み、「専用の値クラスを作る」のパターンでふと 「ここでケースクラスが AnyVal を継承する理由ってなんだ...?」 と思ったので調べた。

case class PersonId(value: Long) extends AnyVal
case class PersonName(value: String) extends AnyVal
case class OrganizationId(value: Long) extends AnyVal

case class Person(id: PersonId, name: PersonName, organizationId: OrganizationId)
// ...

AnyValを継承すると

AnyValを継承すると値オブジェクトになる。値オブジェクトを継承したクラスはひとつの値しかとれない。

// OK
class Melo(val a: Int) extends AnyVal

// NG
class Melo(val a: Int, val n: String) extends AnyVal

AnyVal を使うことによって 実行時のオブジェクト割り当てを回避することができる ようになる。具体的には上の例でいうと Melo クラスはコンパイル時は Melo クラスだが、実行時は Int として解釈される(アンボクシング)

だが、パターンマッチングなどで型検査が必要になると、 Int としてアンボクシングされた値が再び Melo としてボクシングされることになるため、パフォーマンスに影響を与える。

結論

雑に言うと AnyValを継承したクラスを使うとパフォーマンスが向上する っぽい。

個人的にはDDDにおける値オブジェクトをコードで表現するにあたって、もし 引数がひとつしかない のであれば、どんなケースでも AnyVal を継承しない理由がないように思える... というか、調べていて値クラスという名前がたまたまDDDっぽいだけであって、これならべつにエンティティの実装だって可能なら AnyVal 継承クラスでえんちゃうの、と思ってしまった。

ただ、例えばバリデーションロジックで 「〜文字以下かどうかをチェックする」 みたいなビジネスルールがあったとき、クラスの中に MAXIMUM_LENGTH みたいな定数を宣言するのは普通だが AnyVal を継承しているクラスの中で val による宣言ができないという制約がある。

コレに関しては、以下のようなメソッドを定義してしまえばいいのでは、という同期からのアイデアをもらったが、果たしてアリなのか...?

class Text(value: String) extends AnyVal {
  def MAXIMUM_LENGTH = 100
}

参考文献