DevLOVE甲子園2014 「稼働10年超のシステムの上手な子守の仕方」#devlove守
はじめに
こんにちは植木和樹です。去る8月23日（土）にDevLOVE現場甲子園2014 東日本大会が開かれました。
中の人からお誘いを受け「守トラック」（インフラ、運用、アーキテクチャ）で20分お話させていただきました。
2週間程前に発表順を教えていただいたのですが、5回裏（10人中10人目）というトリを務めさせていただきました（焦）。
「稼働10年超のシステムの上手な子守の仕方」発表スライド
以下が発表スライドになります。
発表時に口頭で補足説明いれたので、簡単にまとめておきます。
ソフトウェアはバージョンアップする
構築した立場の人間からみればOSやミドルウェアなどの基盤ソフトウエアはバージョンアップせずに越したことはないのですが、残念ながら必ず更新されます。更新されてしまう理由はいくつかあります。
- 実装する上で必要な機能が、新しいバージョンに追加された。
- 運用回避が難しいソフトウェアの不具合解消のためバージョンアップした。
- ベンダーからの該当バージョンのソフトウェア保守が終了になるため、バージョンアップを余儀なくされた。
- セキュリティ脆弱性解消のためライブラリをアップデートしたら、依存ライブラリもまとめてアップデートされた。
- 連携先のDBがメジャーバージョンしたため、クライアントライブラリの更新が必要になった。
- ファームウェアのバージョンアップにあわせて、OSのドライバーも含めて諸々バージョンアップされた。
- ハードウェアを入れ替えたら、現行のOSバージョンに対応していなかった。
- 当時のバージョンのインストールメディアを紛失した。
ソフトウェアは更新され、動作環境は変わるものです。そして更新のたびに1から動作検証を設計していたら毎回膨大な金額を保守ベンダーに支払う必要があります。更新は定期的に計画的に少しずつノウハウをためながら行うのが良いと思います。
それとシステム構築時に監視や運用の設計・実装はどうしても後回しにされがちです。障害がでてから監視の必要性に気付くものなのです。なのでインスタンス起動と同時に監視が始まるCloudWatchは素晴らしいのです。
ハードウェアは壊れる
形あるものいずれ壊れます。特に100台サーバーがあれば、毎月どこかのハードディスクが壊れます。RAID5が2本同時に壊れるのは3回目撃しました。あと設計時キャパシティプランニングしたハードウェアスペックは大抵過剰な方向に外れます。
なのでハードウェアを意識せずスペック変更ができ、インスタンスリブートだけで障害から回復してくれるEC2は素晴らしいのです。
ハードウェアと合わせOSも含めた環境の賞味期限は3年、消費期限は5年と見積もっておくと良いと思います。いまから5年前といえば2009年ですね。
AWSを使っても賞味期限3年問題は残ると思っています。これをどうエレガントに乗り越えるかが当面の関心分野です。
人は辞める
そのシステムを開発した人はだいたい3年〜5年でいなくなります。環境が3年前、5年前の古いものになり開発意欲が沸かなくなるにつれ、優秀なエンジニアは魅力的な職場を求めて巣立っていくものです。これも仕方ないのです。
開発した人が何を考え、何を意図してそのシステムを設計したのかドキュメントに残してくれていると、後任者としてはとても助かりました。
- どうしてバッチ起動が毎日23時なの？
- 前日の締め処理に2時間かかり、翌2時までに本社に結果を送る必要があるため。
- どうしてscpでなく、ftpなの？
- 送信元のOSにscpコマンドがインストールできないため。
- どうして◯◯は検討されていないの？
- 仕様決定時に確定できず後日必要になったら再検討となったため。
当時、分かりやすい仕様書ってどんなのだろう？と思った自分は「Joel on Software」を読んで、なるほど思いましたのでご紹介しておきます。
まとめ
ハードウェアで苦労した立場で言えば、サーバーを自由に追加・変更できるAWS（クラウド）は天国です。ただしサーバーを自由に追加・変更できる代わりに、以下に素早く・確実に環境を再構築できるかが現在注目を浴びてきています。サーバ保守エンジニアはハードウェアから解放された代わりに、よりプログラマー的な素養が求められています。
- Immutable Infrastructure
- 継続的インテグレーション
- Infrastructure as Code
今後も「なぜその技術が生まれたのか？」「その技術がサーバー保守にどう役に立つのか？」という視点を持ちつつ技術のキャッチアップに努めたいと思います。
