@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

「クラウドアプリケーション 10の設計原則」を読んだ

レビューすることも多いし、何が正しいのだろうと考えることもたくさんあるので読んでみようとおもった。

目次という名の原則は以下。

第1章 すべての要素を冗長化する (Make all things redundant)
第2章 自己復旧できるようにする (Design for self healing)
第3章 調整を最小限に抑える (Minimize coordination)
第4章 スケールアウトできるようにする (Design to scale out)
第5章 分割して上限を回避する (Partition around limits)
第6章 運用を考慮する (Design for operations)
第7章 マネージドサービスを活用する (Use platform as a service options)
第8章 用途に適したデータストアを選ぶ (Use the best data store for your data)
第9章 進化を見込んで設計する (Design for evolution)
第10章 ビジネスニーズを忘れない (Build for business needs)
付録A 守りは左から固める
付録B 目的別参考ドキュメント集

はじめにで、ベストプラクティスとは何かと言う話から始まっているのが面白い。これが正しいからこれに従えというのではなく、知見であるのでそれに盲目的に従えば良いわけではないことが書かれている。原則を理解することで、効率的なプラクティスの吟味ができるようになると言って、10の原則が紹介されている。
Azure のサービスが少しは紹介されているが偏った話はほぼなく、他のクラウドだろうとオンプレだろうと使える話がたくさん書かれているのでどの環境を使っている人でも読んで役に立つと思う。

読んでいてよく出てくる話は冪等性の担保、疎結合だったと思っている。何回でも実行できるよう作成されていれば、エラー対応などについても考えることが少ないのはそのとおりなので、これからレビューをするときはまずはこのあたりを見るようにしようと思った。
また、運用を考慮した作りにすることが原則として入っていて説明されているのと、ビジネスニーズを忘れないが原則として入っているのがとても良いことだと思っている。ただ、アーキテクチャとして良くするわけではなく、使い改善し続けることが考えられることは本当に必要なことだと思う。ビジネスニーズも、お金に見合わないものを作ってもしょうがないし、誰も欲しがっていないものをいつまでも頑張って面倒みる必要はないので、忘れてはいけないことだと思っているので頷きながら読んだ。

原則の1つとしても入っているし、データストアについては知識を深めたいなと思った。

まとめ

  • ベンダー依存ではないので、どこで動いているシステムについてでも反映できるので自分たちのシステムを見直したい
  • 短い原則になっているので覚えやすい
  • とはいえすぐに忘れるだろうから見直しやすいところに置いておこう