BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース きれいで代表的なモデルが高性能

きれいで代表的なモデルが高性能

原文(投稿日:2014/06/22)へのリンク

先頃ロンドンで開催されたDDD Exchangeで、Martin Thompson氏は、自分の書いたコードが全く最適化されておらず、コードがきれいなきわめて性能の良いシステムを開発することができるはずだ、と語った

氏はハイパフォーマンスシステムの世界で働いており、世界有数のカタログシステムや秒間に大量のイベントが発生する高トランザクションシステムを手がけてきた。氏の経験によれば、ハイパフォーマンスなコードは汚くて読めたものではないという一般的な理解とは反対で、性能とはモデルのきれいさや表現力にかかっている。

氏のふたつのコンセプト、きれいであることと代表的(representative)であることは、DDDの意味するところにも通ずる。きれいなモデルはドメインの言葉とデータ構造だけを含んでいる。SpringORMといった技術要素が現れれば、性能問題を起こし、モデルのメンテナンスや進化を阻害してしまう。モデルはドメインの理解を捉えているときが最高だ。そのときが問題領域を捉えている生き生きとしたモデルなのだ。

ハイパフォーマンスシステムの場合、内部のサーバやCPUを考慮するのはとても大事だ。氏はデータの在処によってコード実行の速度がいかに変わるかを説明した。例えばローカルキャッシュからメモリへデータが移動すると遅延が高まる。

氏は性能を考慮したモデルの実装についていくつかのヒントを示している。

  • 参照のローカリティを尊重する。凝集度の高い分離されたコンテキストで、きれいで通信が最小化されているの最も適切。氏が言うには、優れた設計原則はフラクタルだ。つまり、小さくても大きくても問題なく動作する。
  • データ構造になじむ。エンティティを忘れてエンティティ間の関連に着目する。
  • オンラインシステムにとってバッチ処理は優れている。同一のリソースにマルチスレッドでアクセスすると不快なキューイング問題が発生するかもしれない。これをキューとバッチ処理で仲介することでスループットは向上する。
  • 抽象化について。氏は抽象化を使わない。高コストだからだ。みな、すぐに抽象化したがるというのが氏の考えだ。抽象化の代わりにコピーをして、まったく同じものだという確信を得たときにだけ抽象化するべきだ。

氏は最後に、継続的統合のひとつのプロセスとして性能テストをする必要があると強調した。そして次のように語り、プレゼンを終わりにした。

モデルが優れており、エレガントだったら、性能も良いのです。

来年のDDD Exchangeは2015年6月19日に開催される予定。

この記事に星をつける

おすすめ度
スタイル

BT