『メンテナンス本格入門』レビュー

　さすがに本書全部を半日で読んでレビューするのはキツいので、特集５の「メンテナンス本格入門」をレビューします。
　「え？AmazonWebServicesの章じゃないの？」
　はい、cloudpackは至ってまじめにAWSなCIreです。
　しかし、メンテナンス、特にTCP/IPプロトコルから上については、実はオンプレミスのそれと大きな違いは無いのです。
　強いていうならば、スナップショットが取れる・取れない、サーバスペックを細かく調整できない、PCIeSSDが使えない、PXE Bootが使えないなどです。例えばIOPSが足りない時はRAIDコントローラでHDDをストライピングする代わりに、パフォーマンスが限られているEBSをストライピングするのも、オンプレミスと同じ考え方です。
（※LVMを事前に構成すればボリュームのスナップショットは取れますが、運用が大変なのであまりお勧めはできません。）
　ですので、あえてAWSではなく、メンテナンスの章について取り上げようと思いました。
　また、アメーバ社エンジニアが、自社プロダクト『ガールフレンド（仮）』や、『アメーバピグ』の実例を元に、これらを解説している事も大変魅力的です。

『修羅場をくぐり抜けた漢たちからの入門書』

この章を総評すると、上記の１文になるでしょう。
　クラウド上では、わずか10分程もあればインスタンスが生えてきてOSが入っていますが、オンプレミスではそうも行きません。時にはラックの下に潜る覚悟も必要です。
　そんな中、『メンテナンス』という名の、言うことを聞かないシステムと、言うことを聞かないユーザの間で戦った末、ふと振り返った時に、きっとこの章が書けるのでしょう。
　この章で書かれているメンテナンスや構成は、理想的なベストプラクティスではなく、全て必要な事・知識です。
　それは、10年間、データセンタからアプリケーション・クラウドと渡ってきた自分が、とても納得できた内容であり、沢山のうなずく所があった為です。
　システムは１つ１つ違い、決して同一のものはありません。ですので、理想の構成というものは現実には存在しないのですが、もしよろしければご自身が管理しているシステムを思い浮かべながら読んでみて頂けると幸いです。

第１章『メンテナンスとは』

　銀g...桑野さんの書かれた章です。彼の事は良く知っています。私事ではありますが、ご結婚・ご出産おめでとうございます。是非腕力を鍛えて下さいｗ
　さて、ここは「そもそもメンテナンスは必要なのか？」という所から、メンテナンスについて理由・種類・手法を掘り下げて整理する章です。ここでは各レイヤーを取り上げるのではなく、サービス全体のメンテナンスについて取り扱っています。
　泥臭いところはさておき、一旦「メンテナンス」という括りで全体を整理している章になります。
　もちろんユーザとして「メンテナンス」に当たりたくは無いのですが、人間が完全な生物では無いように、コンピュータ、アプリケーション、そしてサービスも完全ではありません。これらを修正したり改善する為に日頃のメンテナンスは必要な事です。
　また、後に登場するメンテナンスフリーなシステムについても、ここで軽く触れられています。

第２章『計画メンテナンスの流れ』

　松浦さんの記事です。計画的なメンテナンスに対し、何を準備し何をすべきか、ここでは触れられています。
　１度でも「計画メンテ」をされた方ならわかると思いますが、メンテナンスには事前作業・事後作業が発生します。その間、システムに誰か張り付き、準備やリハーサルを行ったり、経過を見守る必要があります。この章では、これらを体系的に解説しています。
　また、メンテナンスは必ずしもサービス停止を伴うものではありません。しかし、共通する事は「失敗する可能性は皆無ではない」という事です。この章では、失敗した際やサービス停止中のトラフィックの捌き方や、トラブルが発生した際の対処方法についても触れられています。
　この章の内容は、１ウェブサービス〜大規模サービスまで普遍的な、とても基本的な事のまとめになりますので、是非目を通す事をお勧めします。

第３章『緊急メンテナンスの流れ』

　同じく松浦さんの記事になります。
　24x365の現場を経験するとわかりますが、緊急メンテナンス…通称『障害対応』は、いつ起きるかわかりません。また、その要因も、物理障害・論理障害・人為的ミス・バグと様々です。この章では、突然発生する障害に対し、普段からの備えや対処方法、そして後の振り返りやナレッジ化（フィードバック）まで、ひと通り網羅されています。また、論理障害や物理障害の傾向と対策が解説されている事も、良いナレッジになるえしょう。
　論理障害は、実は僕も何度か遭遇しています。Linux Kernel2.6.18の初期のバグで、ファイルが継続的に壊れる事象がありました。これはカーネルをアップデートする事で解決されましたが、カーネルのキャッシュ制御のバグで、結果としてファイルとファイルシステムの破損が発生していた事がありました。もちろん、その後10TBのストレージを泣きながらfsckしたのは言うまでもありません。
　その他、監視ミスや設定ミスに物理障害やバグが重なるなどした時に、突然そのタイミングはやってきます。
　また、緊急対応時に慌てないよう、常にログを取ったり、流し込むコマンドをエディタで作ってから流し込むなど、基本的なポイントの他、障害の再発を防ぐためのナレッジ化についてまで触れられています。
　実は10年以上前から、ノートPCと携帯・データカードを持ち歩く運用は、まったく変わっていません。かつては電車の中で障害通知を受けて、駅のホームで対応した事もありました。もしあなたが若いサービス運用者であり、いざという時に窮地に追い込められたくなければ、ぜひこの章を読む事をお勧めします。

第４章『メンテナンスフリーへのアプローチ（インフラ編）』

　続いて、松浦さん、中村さんの記事になります。
　メンテナンスフリーのシステムについて、どこまで人力をかけずに運用する為の構築をするか、ポイントがまとめられています。特に164ページのboningモード一覧は必見です!!!（この数年、大きく変わっていない基礎的な実装ですが、きちんと日本語でまとまっているものは少ないのです。）
　さて、システムは勝手に立ち上がって勝手に動くものではなく、従来天塩にかけて墓場まで育て続けるものでした。（かつてSCSIケーブルがモゲかけるまで運用されているシステムとかあったものです。）
　現在の世の中、仮想化・クラスタリングにはじまり技術の進歩により、SPOF(単一障害点)無いようにシステムを構成する事が可能になってきました。例えばL2スイッチのスタック化+LACPとbondingの組み合わせによりネットワーク機器を冗長したり、DBをマルチマスタ化する事でデータが損失する可能性を低くする事ができます。
　ここでは、ネットワーク機器・ミドルウェア・データベース構成・障害検知（監視）に分かれて解説されており、特にDBについてはMySQL・MongoDBを取り上げ5ページに渡り解説されています。
　インフラエンジニアに限らず、アプリケーションエンジニアやデータベースエンジニアも、良いサービスを構築する為に必見の章と言えるでしょう。

　追記するとなれば、bondingについて、昔はオンボードNICと拡張NICの両方を使ってポート冗長をしていました。これは、NICのチップやPCIバスの障害の際にもOSが動く限りサービスを提供する為の術の1つです。（ちなみに、当時はこれをSPARC Solarisで構築していました。）また、今でもそうですがNICとドライバの相性によっては挙動が変わる場合もあり、注意が必要です。例えばFreeBSDのrlドライバのソースに「史上最悪のチップ（low end）」と書かれている事は有名ですが、今でもNICによってバラつきはあります。最悪の場合NICはハングアップします。
　また、HAを構成をする場合、フェールオーバーする為の時間をあらかじめ障害試験で計測する・記録する事をお勧めします。VRRPやHSRP・NSRPといったルータ冗長に使われるプロトコルの場合は、ほぼ数秒で切り替わりますが、peacemakerやClusterProといったHAクラスタでは、リソースのフェールオーバーに数分かかり、その間に実装によってはデータの不整合が発生する場合もあります。その際、『sudo ping -i 0.2 <IP>』を使うと良いでしょう。

第５章『メンテナンスフリーへのアプローチ（アプリケーション編）』

　福永さん、中村さん、松浦さんの記事になります。
　ここではアプリケーションのリリース、通称『デプロイ』の手法とダウンタイムについて語られています。尚、cloudpackには＼(^o^)／すればデプロイできる『デプロイ王子』がおりましたが、今回はあまり関係ありません。
　さて、サービスのリリース作業も大切なメンテナンスの一つです。「系切り替え」「ホットデプロイ」「カナリアリリース」「静的ファイルのリリース」の４つのリリース方法が紹介されています。
　静的ファイルのリリースで、特にCDNやCMSを使う場合において、リリースタイミングは重要な要素です。この点がきちんと記述されている事を高評価します。たとえば、静的ファイルのリリースタイミングがずれると、HTMLと読み込むjQueryのバージョンが異なるなどし、アプリケーションが正常に動作しない場合が考えられます。また、リリースするファイルの内容によってはリリース前にファイル名を推測してアクセスされてしまう為、事前にデプロイできないといったケースもあります。（例えば株式市場に関わる事など）
　アプリケーション面では、イベントをインフラではなくアプリケーションで制御する方法について具体例が示されています。

第６章『ガールフレンド（仮）とアメーバピグの事例』

　福山さん、杉山さんの記事になります。
　ガールフレンド（仮）、及び桑野さんがサーバを作っていたアメーバピグの事例を踏まえ、メンテナンスという側面から、アプリケーションの開発やテスト、運用、メンテナンスについて失敗事例を含め紹介がされています。
　実はここで取り上げたいのですが、たとえばMySQLについて容易にリードレプリカを増やすのではなく、最初から「セット」を決めておく事が大事だと思っています。例えば、「MHA2台」「リードレプリカ2台」「バックアップ1台」と、5台1セットでインフラを構成する事で、最初からある程度の負荷に対応する事と、必要になったら計画メンテナンスでスケールアップする事が可能な為、割とおすすめです。また、同サービス内や他サービスへナレッジの横展開が容易になる事も挙げられます。
　同時に、小さく紹介されていますが、MySQLのSELECTクエリをロードバランサで分散するテクニックも紹介されています。MySQLクエリは一般的なL4スイッチで分散する事が可能です。クエリを発行するアプリケーションサーバ側で予め分散する事も可能ですが、水平・垂直分割をしていない限り、このテクニックで簡単に大量のクエリを捌く事ができます。

おわりに

　本章は、例えば半年程度運用の現場や開発の現場に居たエンジニアに、とてもオススメしたい内容と言えるでしょう。
　ぜひこの章を読んで、先輩エンジニアに是非質問をしてみてください。おそらく今後10年の経験が、たった3年になるかもしれません。それはあなたにとって、肉体的にも精神的にもプラスになる事でしょう。

　尚、僕がクロエ・ルメール（を演じる丹下桜さん）を好きなことは、このエントリには特に関係ありません。: