こんなタイトルですが、私もSSHログインしてます。
というか、shell大好きです。
で、何が言いたいかというと、SSHしなくてもいいように設計しましょう。ということ。
運用中にSSHしなければいけない理由
まず、運用中にSSHをしなければいけない理由は以下あたりかと思います。
1. 設定変更、確認
2. 障害調査、対応
障害調査の場合は、以下などを行います。
1. サーバへSSH
2. リソース状況を確認する
3. ログを確認する
4. etc…(システム特有の何か)
上記の作業をする上で最も恐れるべきは「オペミス」です。
そして、調査精度は個人のスキルに依存します。
特にオペミスの場合は、再発防止策とかすごく難しいんですよね。
「経験不足」や「本番と開発環境を間違えていた」とか、「手順を間違えた」とか、、、
どう再発防止しましょうか。。。いっその事ログインしない運用とか。。。
「ログインしなければ問題起きないよね」を考えてみる
という事で「極論、ログインしなければ問題起きないよね」という発想の元、考えてみましょう。というのが今回の趣旨です。
オペミス等の問題も起きずに、素早く且つ確実に情報収集、対応出来たらWin-Winですね。
障害調査
では、障害調査をSSHログインしないで行う方法を考えてみました。
要は、ログインして確認しているものを外出し（見える化）しましょう。ということです。
| リソース系 | 必要な情報をモニタリングツールで収集（cloudwatch/zabbix/Grafana/Graphiteなど） |
|---|---|
| ログ系 | ログ収集基盤 + KVS + 分析ツールでログの見える化 |
| cloudwatch logs + ElasticSearchService (in Kibana) | |
| Fluentd + ElasticSearch + Kibana | |
| etc | システム特有のものも上記で収集する |
これである程度は外から見えるようになるのでは無いでしょうか。
最近流行りの監視ツール(Mackerel/Datadog)とかでもモニタリング出来ると思います。
ちなみに何でもかんでも取得すると、何を見たらいいか分からなくなり自己満システムになってしまいます。
ポイントは「システムに応じた、必要最小限」です。難しいですが、設計者の腕の見せどころです。
障害対応
次に障害対応ですが、よくあるのは「service httpd stop/start」、、、の前に
「service tomcat stop/start」を打って、、、とか手順や順序を守って作業。などありますよね。
「あ、順番間違えた！」とかは、無いと思いますが、システムが増えてくると手順も増えて資料も増えてレビューして・・・・・・
あれ？資料どこいったっけ？どれが最新？更新漏れてた・・・orz
とかやってられないですよね。
だから、手順はいつも１つ！（コナン風）
「インスタンス再起動！！」（しかも、マネジメントコンソール or CLIから！）
OS起動時に順序等を守るように設計・構築しておけば、起動時は正常に立ち上がってくる（はず）
まとめ
上記のように、内部の見える化とともに障害対応手順も簡素化することで、
オペミスや個人スキルへの依存、資料作成・管理等の負荷なども大幅削減出来るのではないでしょうか。
また、上記のような仕組みにしておくことで、場合によっては
「ある障害の場合に、自動的に再起動をかける」などの自動化への一歩にもなるかもしれません。
最終手段としてはSSHすることもあると思いますが、
出来るだけしないように作っておくことが幸せの第一歩と考えてます。
他にこんなアイディアあるよ！という方はコメントくださいー。
PS. 先日リリースされた機能でのアイディア
先日以下の機能がリリースされました。
これを使えば、
「cloudwatch => SNS => Lambda => Run command（OS上でshell実行など）」って実行して、
「インスタンス再起動」という暴挙に出なくてもよくなるかもしれません。
（run commandで個別要件は取りきれそう）
以上、
