qpstudyに参加してエンシェントな焼酎をふるまってきました
初心者にもやさしい(頃もあった)勉強会、qpstudyに初参加してきました。
www.zusaar.com
今回のテーマは監視＆運用＋自動化。
本編
最初は @koemu さんによる「ITインフラ監視の今後を考える」。
惰性的に行われてきた面もある監視を根本から見直してみようという意欲的な問題提起でした。
経営や事業評価の視点も交えて誰にどういう価値を提供するか、という観点もあり非常に刺激的でした。
speakerdeck.com
後半挙げられた３つの課題が印象的だったので整理。
- 1.PaaSをどう監視するか
監視させてくれない/見えない部分が多い、検知しても対応は事業者任せでできることが無い
監視も事業者提供ツール頼み？ cf. http://www.stackdriver.com/
SaaSはコストが明瞭、その分高く見える場合も
DIYの場合の構築コスト/運用コスト/提供価値のトータルで比較してみる必要がある
- 3.監視の細かさ
対応の必要なものを確実に通知
通知内容の優先度
- 障害でなければ通知は要らない？
- HDD容量など予防的通知は？
- 冗長したWEbのうち1台落ちたときは？
- ステークホルダーと合意は取れているか？
続いて前佛さんの「Re:運用に自動化を求めるのは間違っているだろうか？」
当初予定の時間枠では半分強しか話せずw懇親会で延長戦も行われました。
冒頭のスライドの通り、ポイントは３＋１つ。
- 運用における自動化範囲の整理・分類
- 自動化で運用はこんなにも楽しくなる
- トラブルシューティング自動化は未解決課題
- 本来あるべき状態から逆算して運用業務を楽しくしよう
運用における自動化範囲の整理・分類
ツールや手法で改善可能になった部分もある
-設計＆構築 <- 構成管理ツール、Dockerfileからの起動
-監視設定 <- オートディスカバリー、テンプレートエージェント
会場からQ. 環境構築の自動化でDockerが構成管理ツールよりも優れている点は？
前佛さんA. ツールは一長一短あるのでどちらでも
Dockerは間違いなく同じ環境を作ることができます
会場からQ. システムのライフサイクルを考えて維持管理や変更にDockerは耐えうるか
前佛さんA. Dockerだからどう、という問題点ではないと思います
会場からQ. コンテナ作成のタイミングというか依存ライブラリのバージョンが変わってしまう場合の対策は？
前佛さんA. 現で点ではローカルのResistryServerに作成したDockerイメージを置いてください
トラブルシューティング自動化
使えそうなツールはいくつか出てきた
-時系列メトリクスを何台分も並べて見ることができるもの(Elasticとか)
-クラスタ制御ツール(serf, consulとか)
よくある「サーバー重いんだけどちょっと見て」という状況に、コンテナ化されるインフラでどう対応するか。
-ツールによって"当たりをつける"ことの支援は可能
-問題の特定や支援はまだちょっと先？
他の業界で確立している手法に学んでみようシリーズ
-大事故,大規模災害時のトリアージ -> 障害の深刻度や対応復旧の優先度
-管制とレーダー -> オートディスカバリーでのクラスタ状態(の変化)の把握と各インベントリ,メトリクスの取得
(この辺で時間切れ)
グループディスカッション
それぞれ自分の業種の立場から、監視業務の価値を見直してより良い今後を考えよう、という内容で
3-4名 -> 各テーブル(8名程度) -> 全体 の三段階でのブレスト形式
自分のグループではクラウド化なんてできていないオンプレなメンバーが結構いたので
レガシーなところにも付与可能な価値、ということで一覧性の話をしたり、
DIY(オンプレ)な監視基盤の監視のためにSaaS系を用いる話、
cronやサービスウインドウを調整して日中など障害が起きるとしても対応しやすい時間に起こるようにする話、をしました。
なおテーブル班での議論を発表する際、「レガシー」という単語をど忘れして
「エンシェントなシステム」と言ってしまったのがちょっとハネたので結果オーライです。
他のチームでは経営層に響くレポートの話や、内製で引き継ぎが無いとかそもそも独りとかのツラい話が今なお心を掴んでいたりととても多様な意見とそれでも共通したある種の危機感があって面白かったです。
懇親会＆LT
自動化というトピックでちょうど良いかな、と思ってStackStormの紹介をLTしました。
単発作業の自動化/マクロ化はできていることが多いと思いますが、ノード間やクラスタ間をまたいだ自動化は急にハードルが高くなりがちなので役に立つかもしれません。
iftttとかplagerを想起させるツールなので、前佛さん資料の"ピタゴラ装置的な仕組み"を作る基盤になれるものだと思います。
StackStorm.pdf - Zoho Docs
以前、SoftwareDesign誌で"運用現場で役立ち開発力"という特集があったり昨今DevOpsというキーワードがあったりしますが、個人的にはインフラエンジニアが作るシェルスクリプトの品質という問題意識があります。会社の中でも開発部門にはコーディング規約があったりしてもインフラ運用部門は触れたこともないし出荷検品のプロセスも無いような状況というのがあるんじゃないかと思います。
ChefだとかこのStackStormのようなツールを利用することで、エラー処理や正規表現など書式のハンドリングといった部分を個別に書かずに済むフレームワーク的なメリットも得られ、テストやレビューも行いやすくなる点もあると思うので、何かしらツールを使ってみるという現状改善のアプローチもあると思います。
Software Design 2009年4月号｜技術評論社
Enterprise版のお値段の質問がありましたが、やはり非公開になっていました。月額$500以下ぐらいで12ヶ月契約と書かれています。
Pricing - StackStorm
ただし現時点ではほとんどの機能がGitHubから落とせるOSS版で利用できます。Enterprise版のみの機能は、デモでお見せしたWorkflowのGUIエディタとLDAP連携、ロールベースアクセス制御の部分のみです。
stackstorm.com
監視におけるフルリゾルバのキャッシュ by ttkzwさん
DNSやドメイン情報に起因する障害が発生している場合に監視基盤がリゾルバのキャッシュを使っていて検知できない、というようなケースをどう回避するかという課題設定。
理想的にはキャッシュDNS上のTTLをすべて監視間隔に合わせて、都度新しい情報で監視することを示され、例としてunboundでのcache-max-ttl設定をご紹介されました。(bindは省略というか足切りされましたが、max-cache-ttl/max-ncache-ttlで設定が可能です)
この問題ってFWのポリシーを名前ベースで設定する時にもからんできたりしますね。あと監視基盤がWindowsだとスタブリゾルバでもキャッシュしそうな気がします。
クラウドポリシーチェックリスト --間違えてました-> Wall-Architected フレームワーク by yktkoさん
冒頭に好きなAWSサービスはaws-cliとの言があって、そこ？と思いましたw
興味深かったので終わったあとに「Trusted Advisorと統合されないんですか？」と訊いてみましたが、汎用的にできていて「バックアップちゃんと採っていますか」といった項目もあるのでチェックリストにはなるけどすべてが機械診断に反映できるものではない旨言われ、納得でした。
こういうのはベストプラクティス的にそれぞれで経験されたものが集約されていって欲しいですね。
AWS Certificate Manager by mnakajima18さん
いろいろ理想値にすれば導入も更新も30分＋アルファ＋アルファ＋アルファくらいでできた実績のお話。
Tokyoリージョンに無いのと、Let's Encryptという競合および既存大手との争いも気になりますね。Let's Encryptは更新のcronジョブの時に80/443がサービスリスタートよりも長い時間、多分1分弱くらい停止する点が気になっています。ACMはどういう動作をするんでしょうか。
MongoDB on EC2 by kuwa_twさん
「ログを入れるなって言ってるだろう」....すみません、StackStormでもMongoDBはログやauditの置き場です....
WiredTigerストレージエンジンなら改善されるか負荷テストしてみた、という結果グラフでしたが負荷がキツすぎて結果が正直すぎて良さが伝わりにくいというか....I/O waitが80%から60%に改善されたってterribly slowがvery slowになったとしか感じないのですが。とは言えwiredTigerへの期待およびMySQLでのFalconのように今後StorageEngineの開発がいろいろ進む先陣になることへの期待があります。
4/26お昼時のBlackBeltがMongoDB on AWSとのことです。
[Black Belt Online Seminar] AWSで使うMongoDB
あと、私が熊本生まれ宮崎育ちということで熊本の焼酎を差し入れしました。
www.fusanotsuyu.jp
35度とちょっと強めでしたが30年古酒にしたこともあって飲みやすいと好評で売り切れて良かったです。お気に召した方は、是非熊本や大分のお酒を入手してみてください。
日本酒ならば阿蘇の一所懸命とかメッセージ感もあっていかがでしょうか。
吟醸焼酎 一所懸命720ml | 商品のご購入はこちらから | 熊本の阿蘇にある酒屋【阿蘇・岡本】のオリジナルのお酒・リキュールやお土産にも喜ばれる地サイダーの通販サイト
感想・考察・補足情報
ただ監視するだけではなく、運用の改善やメタに役立つことを実装することもできるという面でZabbixに高い評価と期待が感じられた一方、導入の障壁(をDockerで緩和)や導入を後押しするメリットが欲しいという話も多く聞かれた気がします。
まずは仮想アプライアンスとかでPC上のVirtualBoxで起動してみるのもいかがでしょうか？
http://www.zabbix.com/jp/download.php#appliance
ただ問題意識も経験的比較対象もなく試しても判断しにくいと思うので、メールソフトやテキストエディタをいくつか試したことがあるならばその感じで試してみても良いと思います。
「最初に触るのがZabbixという若手にメリットを理解してもらいたい」という話に前佛さんが「Zabbix無しで同じものを得る環境を作らせてみては」ということをおっしゃっていたので「BigBrotherでやらせてみては？」と野次ってみました。
BBは極論として、解は一つではないと思うので私の好きなOSS監視ソフトも挙げておきます。どちらも仮想アプライアンスやLiveCDがあります。
PandoraFMS http://pandorafms.org/ja/features/download
ichinga2 https://www.icinga.org/download/
