結論としては、勉強になったし読み物として面白かった。
オペレーションに関係するソフトウェアの特徴・比較・使い方の詳細な記述はないが、
それらの関わりが簡潔にまとめられているおかげで、体系的な理解の助けになった。
この書籍は18の章から成っており、それぞれ著者が異なる。
ある章の結論が他の章の結論を直接的に否定しているわけではないが、
全体的には、ただ一つの正解は無いと言っているようで、考えさせられた。
内容が豊富で、すべては噛み砕けていないので、また読む。
データベース
データベースは、難しいということが分かった。
データベースは特にボトルネックになりやすく、またバックアップが必要である。一般的なマスタスレーブ構成の場合、スレーブへの非同期レプリケーションは厳密には一貫性を失うし、マスタ冗長化もまた一貫性を失う。
じゃあクラスタリング、とはいかなくて、ウェブデータベースのユースケースに適したクラスタはないと書かれている。2016年現在も無いのかどうかは、ちょっとわからない。
CAP定理は、Consistency, Availability, Partition Tolerance の3つを同時に達成できないことを示す。 データを複数サーバに分割した場合、トランザクションの信頼性を保証するACID (Atomicity, Consistency, Isolation, Durability) 特性は失われる。また、分散トランザクションは通信障害の影響から確実性が保証されていない。
スケールが可能なNoSQLの採用も考慮すべきである。
NoSQLにも、アーキテクチャの違いから、色々ある。
Redisとmemcachedしか触ったことがなかったので、とりあえず他の種類と特徴ぐらいは覚えておきたい。
データベースアーキテクチャに正解はないので、論理的な選択が必要。
DevOps
この本は2010年に出版されたものだが、2010年にもうDevOpsという言葉があったことに驚いた。
“DevOps”という単語が初出の発表(2009)では、開発と運用が互いのことを思いやるために、6つのツールと4つのカルチャーが挙げられていた。
自分の中では、DevOpsがすでに当たり前として受け入れてしまっているが、
これらのツールやカルチャーが無かった頃、そもそもなぜ開発と運用は分かれていたのだろうかと思った。
開発と運用が衝突する構図自体は理解できる。
雑に調べてみると、ITの内部統制によって、適切な権限管理の観点から、開発と運用を分離することが義務付けられているらしい。
アジャイル開発が積極的に用いられるようになってから、とにかく速くサイクルを回すために、自動テスト・継続的デプロイ・メトリクス可視化などの技術が発達し、それらの技術を共有するためのカルチャーも含めたプラクティスをDevOpsと呼ぶようになった、という感じなのだろうか。
最高のオペレーションとは
アーキテクチャの設計では、その設計が5年後動作するのかを考えなければならない、と言っていた。
しかし、データベースアーキテクチャ設計では、シャーディングのような、将来のスケールを見越したアーキテクチャは、可能な限り使うな、と。
また、複雑なシステムは本質的に危険なので、シンプルにすべきであると言っている。しかし、「シンプル」なデータベースアーキテクチャは、現実的ではない、とも言っている。
すなわち、汎用的に正解であるアーキテクチャは存在しないということなのだろう。
あるシステム特有のアーキテクチャにするのが正解だと。
あれもこれもやりますみたいにサービスが進化していくのは良くない。
結局どう決めればいいのかは、SLAに基づく運用ポリシーよる。
するとSLAの決め方が重要になってくる。
Webシステムに必要なのは「一貫性」ではなく「可用性」と結論づけていた。
まずは顧客を継続的に留めることが重要である。
また、レスポンスタイムは顧客の印象評価に直結することが示されている。
ビジネス、マーケティング目線のメトリクスももちろん必要。
これらのメトリクスをベースにしてSLAを決定する。
オペレーションの仕事は、全てのアーキテクチャを正常に運用し、収集したメトリクスをステークホルダに翻訳すること。 ウェブオペレーションは、常に危険があり、「絶対」はない。 つまり、本質的には進化は無限に続くということで、 日々発展する技術、アーキテクチャ、メトリクスをキャッチアップする必要がある。
考えたこと
自分が考える、運用チーム(SRE)が存在する理由は、インフラをコード化し、プロダクションと等しい開発環境と素早い柔軟なデプロイを提供することで、開発にかかるオーバーヘッドを削減し、開発チームには創造的で生産的な業務に集中してもらうことだと考えていた。
DevOpsを成功させる鍵は、サービスの安定性は全員の責任と認識すること、と書かれていた。 また、「サイトの安定性の責任が運用チームだけのものではないとすると、従来の運用チームの役割は消えてしまうのか？」という疑問に対しては、「サイトを稼働させる専門家としての存在」と答えている。 運用チームは、最初にアラートを受け取り、プロダクションの問題の経験もあるサイトの安定性に絶えず提案する役割がある。 DevOpsによって、運用における運用チームの負担は確実に減る。 そこで、運用チームは、一時しのぎで障害に対応するのではなく、長期的に成長するインフラを管理するような本質的なタスクに集中できる。
「たった一度だけデプロイする」ことが目的なら、
インフラをコード化するオーバーヘッドは確実にあるため、
コード化するデメリットのほうが大きいかもしれない。
しかし、現実的には継続的にデプロイするし、DevOpsのデメリットは
ほとんど無いように思う。
開発と運用がお互いに、真に生産的な業務を行うために、DevOpsはもっと当たり前になっていくだろう。
“アプリケーションはインフラであり、インフラはアプリケーションである” と書かれている通り、インフラレイヤーとアプリケーションレイヤーは近くなっている。 コードを書けないインフラ屋は必要とされない未来になると思うので、アプリケーションまで広く興味を持ち、コードを書けるようになりたい。