どうも！アプリケーション基盤チームの@yokotasoです。 3月11日にBattle Conference U30 というイベントでお話をさせていただきました。 準備がてら作成したディスクリプションを公開します。
キーノートはSpeakerDeckからどうぞ!こちらも参考にしていただければ、嬉しい限りです。
では、どうぞ！
障害にすてるところなし
サイボウズ株式会社の横田です。
「障害に捨てるところなし」というタイトルで少しお話させていただきます。お手柔らかによろしくお願いします。
運用障害の話
まずはじめに、今回のお話をするにあたりまして
運用障害でご迷惑をおかけしたみなさま、大変申し訳ありません。 より快適に利用いただけるサービスを目指しまして、対策・改善をおこなっております。
これからも、弊社製品をよろしくお願いいたします。
クラウドの規模と稼働率
障害の話をする前に、サイボウズのクラウドの規模感についてお話させてください。
ご契約いただいている会社様は18000社、ビジネス規模では、年間の売上が40億程度の規模になってきています。 稼働率は99.9 % をだいたいクリアするくらいです。
さて本題
障害というとネガティブなイメージを持たれがちなんですが、
ちょっとまってそんなことないよと。
チョットイイね！くらいまで持っていこうよという話をしたいなと思います。イイねマーク、気持ち小さくなっております。
４つのネタで、失敗から徹底的に学ぶ障害学習の話をしていきたいと思います。
基礎知識を身につける
さて、1ネタ目。基礎知識を身につける。基礎的な素養を磨く話です。
障害からコンピュータの基礎を学ぶ
コンピュータの稼働状況を表す基本的な指標としてCPU、メモリ、ディスク、OSキャッシュなどがあります。
障害調査はボトルネック探しからはじます。
大規模サービス技術入門 という素晴らしい本があります。本を参考にしながら、何度も障害調査をしていくと、基礎的知識が身につきます。私もお世話になりました。
障害のたびにメトリクス監視ツールなどを眺めることになると思いますが、こういう経験をしていくと基礎的な素養と経験が身につきます。
障害がコンピュータの基礎を教えてくれた
こうして得た知識と経験は今の私にとっては素晴らしい財産です。障害調査、設計などにとても役に立っています。 問題の原因がわからないとき、落ち着いて基本的な指標に立ち返って解決に向かったこともあります。
「コンピューターの大切なことは、障害が教えてくれた」といってもいいと思います
知識を深掘りする
2つめのネタは、知識を深掘りする話です。
障害を通して、動作原理を深く理解しましょう。
MySQLのIndexが使えないことが原因で障害になったことがあります。
原因としましては、重複を取り除くために安易につけたGROUP BYが原因でした。
MySQLはJOINのときにIndexを利用するんですが、そのIndex とは違う列で GROUP BY を行うのでusing filesort になってしまう。
味わい深いですね。
この問題、MySQLのIndex に関する動作原理からすると非常にあたり前な現象です。
この障害を通して、MySQL の Index を使った動作原理が実は理解できていなかったことがわかりました。
障害調査のたびに、ハイパフォーマンスMySQL を何度も読み返してやっと理解できたなと。
最初は理解できないことでも、直面した問題を読み解くことで、プログラムに関する深い理解が得られるのです。 障害は最高の良問だと私は思っています。
チームで強くなる
3つめは、チームの話です。失敗がすることは誰でもあります。であれば、失敗を受け入れるほうに注力するのも筋は悪くないはずです。
失敗の名は
弊社もご多分に漏れず、おおきな失敗をしております。 S2DaoからHibernateへの移行に失敗しました。パフォーマンス劣化、障害を起こしました。ご迷惑をおかけしました。 言い訳になりますが、S2Dao、いいフレームワークなんです。EOLなのが残念です。
失敗を受け入れる文化
じゃあ、どうやって失敗をうけいれるのかという話です。
私がおすすめするのはPostmortemを書くことです。Postmortemは振り返り文章のことで、失敗を整理、分析、共有するのに役立ちます。超有名企業の大規模障害のPostmortemをWebで読めるようになっていたりします。Webに公開する必要はないですが、チームでこういった文章を共有して話せる文化があるといいですよね。
失敗を共有する文化
失敗を共有することで、同じ失敗を繰り返さないように組織の問題として捉え直すことが出来ます。
ありがちな話ですが、失敗を共有するのは恥じらいや申し訳無さから難しいことが多いです。 話してくれた人には圧倒的感謝を。謙虚・尊敬・信頼(HRT) の精神で傾聴をぜひお願いします。
手前味噌になりますが、この移行失敗の顛末はブログに公開していますので、興味があればぜひ読んでみてください。 参考: 我々はいかにして技術選択を間違えたのか 2016
転んでもただでは起き上がらない
失敗を受け入れる話をしてきましたが、失敗は成功の道半ばでしかないという開き直りも大事です。
失敗したときの悔しいエネルギーがないと改善できないことってあると思うんです。
弊社も今回の失敗から立ち直るべく JdbcTemplate を使ってS2DAOに近いORMapperを再設計しました。
近いうちにOSSとして公開したいと思っているので、お楽しみに
失敗の共有は恥だが役に立つという話でした
よこしまな生き方について
4つめ。エモい話ですけど、よこしまな生き方についてです。
Javaの謎のパフォーマンス現象との戦い
Javaの謎のパフォーマンス劣化現象に苦しめられていた時期がありました。
無事解決しまして、原因はJIT Compilerでした。 JIT Compilerが停止したままになるのと、最適化されたコードを捨てる機能があり、これが悪さをしていました。
解決の糸口
どうやって解決したのか？という話なんですが、JVMはGCに使われるスレッドはCPUのコア数から決まります。 そして、GCスレッドは、CPUを100%専有する仕様になっています。このあたりの話はJavaパフォーマンスにあります。
これを前提にすると、GCが常に発生していたとしても、運用環境のCPUはまだ余裕がありました。そこで初めて、GCを原因から排除しました。 あとは、CPUを消費するケースをMLで読み漁りまして、発見したのが今回の現象でした。
ブログに公開
調査に苦労したので、少しでも元を取ろうということでブログ記事に公開しました。
公開時に読んでいただいた方もいるかもしれません。ご愛読ありがとうございます。 記事は大好評でした。OSSにお世話になっているので、情報公開で貢献したい気持ちもありました。
結果的には、3日間ぐらいドヤ顔してましたが。
ずぶとく生きるように
このときの経験から、調査のモチベーションがガラリとかわりました。 現金なもので、面白いことがあるかもしれないと調査していると不思議と楽しいです。疲れますけど。
JIT Compilerの問題が長期間、原因不明だったので開き直れるようになりました。 いざとなったら逃げてもいいと実感できたことはとても大きな学びでした。
ずぶとくネタを使いまわして、今日も喋りに来ているわけです。
常にネタを探しているお笑い芸人みたいですけど、ちょっとよこしまな気持ちを持っていたほうが人は楽しく生きられるのかもしれません。
おわりに
最後になりますが、今日の話を聞いて障害調査に興味を持っていただける人が増えたらうれしいです。
障害学習、はかどりまっか？
障害にすてるところなしという話でした。ありがとうございました
引用
プレゼンテーションで引用させていただきました。日々、業務でお世話になっております
