メンテナンスは必要？

• メンテナンスなんてない方がよい
• それでも行う必要があるとき
  • 歴史的かつ技術的な負債
  • 作業難度のトレードオフ

メンテナンスの種類

計画メンテナンス

事前に計画し、ユーザー告知を行って作業を行う。これに当たる主だった作業としては

• ハードウェアの保留／入れ替え
• データベースの設定変更
• ネットワークの保留

手順：

• 作業手順作成
• 事前準備：Sorryサーバーの準備
• テスト環境での予行演習
• 作業実施：作業チェック、問題発生時の対処
• 確認作業：モニタリング、作業の振り返り

緊急メンテナンス

障害が発生した場合などに原因を解決／追求品ケラバサービス継続が難しい場合などに行う。内容は

• 障害復旧
• 障害の現状保存
• 障害の詳細調査

手順

• 障害検知
• 原因調査
• メンテナンス判断
• 作業実施
• 確認作業
• 振り返り・ノウハウ化
• その他：ユーザーへ告知、補償

メンテナンスの手法

• 全停止メンテナンス
• 一部停止メンテナンス
• 無停止メンテナンス

メンテフリーへのアプローチ

メンテフリーとはサビースを停止せずメンテナンスを行う。そのためには、設計、構築、運用のすべての段階で「いかにSPOFをなくし、システム停止せずに作業できるか」を考え続ける必要がある。アプローチは様々あるが、弊社に適したものは以下にあげられる。

Webサーバー、アプリケーションサーバー

ロードバランサによって複数のサーバーにアクセスを振り分け、２台以上用意する。Apache/Nginx・アプリケーションサーバーの設定変更や再起動といった作業でユーザーに影響があるシステム構成いなっているものは好ましくない

データベース設計：

• スキーマ変更の頻度高いサービスはMongoDBへ
• RDBの場合はマスタスレーブ構成やマスタ分割、スキーマ変更のコストを下げる。MySQLの場合はオンラインスキーマ変更がある

リリース：

• ロードバランサ切り離しによるリリース：ロードバランサからアプリケーションサーバーを分離し、１台ずつアプリケーションを入れ替えていく。Jenkinsなどでサーバーに順次デプロイしていくと良い
• 系切り替えによるリリース：稼働系と待機系の２系統を準備し、ロードバランサでクライアントの向き先を切り替えてリリースする
• ホットデプロイによる動的リリース：アプリケーションを再起動せずにモジュールを更新する機能。UnicornやPumaなどはこの機能がある（と書いてある）
• カナリアリリース：一部のユーザーから徐々に新バージョンのアプリケーションを適用していく手法。FacebookやGoogleの大規模サービスはこの方法でデプロイされている

結論

サービスの種類・規模や原因によって様々なパータンがある。いつ起こるのもわからない。そのため、監視ツールを導入や毎日心構えが必要である（エンジニアの辛い道）

• TIL
• Japanese