Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a 激白！GROWI.cloudの可用性向上の取り組み【WESEEK Tech Conf #16】
Semelhante a 激白！GROWI.cloudの可用性向上の取り組み【WESEEK Tech Conf #16】 (20)
Mais de WESEEKWESEEK
Mais de WESEEKWESEEK (11)
激白！GROWI.cloudの可用性向上の取り組み【WESEEK Tech Conf #16】
- 2. #WESEEK_tech 会社概要 株式会社WESEEK 所在地 ● 本社：〒169-0051東京都新宿区西早稲田2-20-15高田馬場アクセス10F ● サテライトオフィス：〒874-0838大分県別府市荘園9-1 ルーデンス荘園305 Lead with the web -Webで未来をリードする- 2
- 3. #WESEEK_tech 現在の主な事業 1. 通信大手企業の業務フロー自動化プロジェクト 2. ソーシャルゲームの受託開発 3. 自社発オープンソースプロダクト「GROWI」「GROWI.cloud」の開発 3
- 4. #WESEEK_tech GROWIとは 4 快適な情報共有を、全ての人へ ● OSSとして公開している情報共有ツール(ナレッジベース) ● エンジニアに馴染みのあるMarkdown形式で記述可能 ● 柔軟な階層構造での情報管理が可能
- 5. #WESEEK_tech GROWI.cloudとは 情報共有をもっと身近に、もっと手軽に ● OSSであるGROWIを専門的知識がなくても簡単に運用・管理できる、 法人・個人向けの商用サービス ● エンタープライズプランの導入事例 ○ インターネットマルチフィード株式会社様 ○ 株式会社エイチーム様 5
- 6. #WESEEK_tech 質問の受付方法について ● Zoomのチャット機能で、発表中も随時質問を受け付けます ○ メッセージの送信先設定は「全員」で！ ● 発表終了後に10分程度、質疑応答の時間を設けています 6
- 8. 本日の発表 8
- 10. #WESEEK_tech 自己紹介 今間 俊介 Syunsuke Komma 10 2013年にWESEEKに入社 node.js/Kubernetes を中心としたインフラ/ア プリの設計・構築・運用に携わる。 GROWI.cloud の運用にリリース当初(2018～) より従事。 業務 @gutalla
- 11. #WESEEK_tech GROWI.cloud の現状規模 ● 2021/12/23 現在 ● 総ノード数: 56 ● ユーザアプリ数 ○ GROWI: 318 ○ HackMD: 111 ○ Keycloak: 15 ● 可用性(SLI/過去1か月) ○ 通常ノード上の GROWI: 99.995% ○ 全ノード上の GROWI: 99.846% 11
- 12. #WESEEK_tech 本日のアジェンダ 1. サービス運営の上で必要な監視項目とは ○ SRE の考え方から、本当に監視すべき項目を設定する 1. サービスの可用性を計測・可視化する手法 ○ 1. を実現するために必要な情報を揃える手段を実装する 1. 可用性を維持/向上するために必要な取り組み ○ 1./2. を用意した上で、実際にどのような取り組みを実施しているか 12
- 13. #WESEEK_tech 本日のアジェンダ 1. サービス運営の上で必要な監視項目とは ○ SRE の考え方から、本当に監視すべき項目を設定する 1. サービスの可用性を計測・可視化する手法 ○ 1. を実現するために必要な情報を揃える手段を実装する 1. 可用性を維持/向上するために必要な取り組み ○ 1./2. を用意した上で、実際にどのような取り組みを実施しているか 13
- 16. #WESEEK_tech 闇雲にアラートを出すと ● アラートの絶対量が人間の対応できる範囲を超える ○ アラートばかりで寝られない ■ そこまで重大じゃないと思われるアラートで起こされる ○ そのアラートはホントに顧客サービスに直接影響するのか？ ■ 直接影響しないものもアラートとして出てしまう ○ ほとんどスルーしてよいという認識になり、いずれ対応されなくなる ■ 本当に対応しないといけないアラートが見逃される ● 運用者は人間 ○ 人間が対応できる範囲のアラート量に調整する必要がある 16 サービス運営の上で 必要な監視項目
- 17. #WESEEK_tech SRE の考え方 ● Site Reliability Engineering ○ Google が提唱したエンジニアの役割 ■ https://sre.google/ ○ システムの信頼性に焦点を置いている ○ 可用性がシステム運用における成功の前提条件になっている ● 以下の用語が定義されている ○ SLO (サービスレベル目標/Service Level Objective) ■ サービスレベルの目標値(ex. 99.9%) ○ SLA (サービスレベル契約/Service Level Agreement) ■ 一定期間で SLO 以上のレベルを満たすことが、利用者との契約に含まれる値 ○ SLI (サービスレベル指標/Service Level Indicator) ■ システムの監視項目が成功した頻度 ■ SLO を下回る場合は何かしらの処置が必要 17 サービス運営の上で 必要な監視項目
- 18. #WESEEK_tech SRE の考え方 ● Site Reliability Engineering ○ Google が提唱したエンジニアの役割 ■ https://sre.google/ ○ システムの信頼性に焦点を置いている ○ 可用性がシステム運用における成功の前提条件になっている ● 以下の用語が定義されている ○ SLO (サービスレベル目標/Service Level Objective) ■ サービスレベルの目標値(ex. 99.9%) ○ SLA (サービスレベル契約/Service Level Agreement) ■ SLO が一定期間で特定のレベルを満たすことが、利用者との契約に含まれる ○ SLI (サービスレベル指標/Service Level Indicator) ■ システムの監視項目が成功した頻度 ■ SLO を下回る場合は何かしらの処置が必要 18 サービス運営の上で 必要な監視項目 本当に守るべきものは、この軸で測定できそう？ ところで…可用性ってなんだっけ？
- 19. #WESEEK_tech 可用性とは ● https://www.idcf.jp/words/availability.html より 19 可用性（Availability）とは、システムを障害（機器やパーツの故障・災害・アクシデ ントなど）で停止させることなく稼働し続けること、またはその指標のことをいいま す。 長い時間、システムを稼働し続けられることを高可用性（High Availability）ともいい ます。 サービス運営の上で 必要な監視項目
- 20. #WESEEK_tech 可用性とは ● https://www.idcf.jp/words/availability.html より 20 可用性（Availability）とは、システムを障害（機器やパーツの故障・災害・アクシデ ントなど）で停止させることなく稼働し続けること、またはその指標のことをいいま す。 長い時間、システムを稼働し続けられることを高可用性（High Availability）ともい います。 サービス運営の上で 必要な監視項目 今回はまさにこれ 冗長化できるソフト/ ハードでよく聞く単語
- 21. #WESEEK_tech 運用で守るべきこと ● 顧客に提供しているサービスが SLO 以上で正常に稼働していること ○ = 可用性を SLO に保つ ○ サービスの裏側で動くミドルウェアの状態が、必ずしも直接顧客サービスに影響すると は限らない ■ ex.) 縮退状態でもサービスは動く(その為の冗長化) ○ SLO 値を算出するために SLI を定義する必要がある 21 サービス運営の上で 必要な監視項目
- 22. #WESEEK_tech GROWI.cloud における SLO ● GROWI.cloud ではプランごとに 99.4% or 99.9% と設定 ○ Closed β での稼働状況を見つつ、正式リリース時に決定した ○ GCE プリエンプティブルインスタンスを利用したプランでは、24 時間以内に必ず再起 動する ■ WESEEK Tech Conference #2 で発表も行っています ■ コスト7割減!Kubernetes本番サービス環境の運用ノウハウ ○ 再起動にかかる時間を考慮し、99.4% という値を設定した ● 参考) 各 SLO における許容される down 時間 22 サービス運営の上で 必要な監視項目 SLO 期間 1日 1か月(30日) 1年(365日) 99.4% 8分38秒 約4時間20分 約52時間半 99.9% 1分26秒 約43分 約8時間45分
- 23. #WESEEK_tech GROWI.cloud における SLO ● GROWI.cloud の SLO(企業向けプラン) ○ https://growi.cloud/price-and-features より 23 サービス運営の上で 必要な監視項目 ここに記載されています！
- 24. #WESEEK_tech GROWI.cloud における SLO ● GROWI.cloud の SLO(個人向けプラン) ○ https://growi.cloud/introduce-for-person より 24 サービス運営の上で 必要な監視項目 ここに記載されています！
- 27. #WESEEK_tech まとめ ● サービス運用で守るべきこと ○ = 顧客がサービスを使える状態であること ○ = 可用性を維持すること ○ ≠ サービス提供に必要なシステム全てが、完璧な状態で稼働していること ● 可用性の指標 ○ SLO ■ サービスレベルの目標値 ○ SLI ■ 監視項目が成功した頻度 ● 可用性の指標を運用に乗せれば、うまくいきそう 27 サービス運営の上で 必要な監視項目
- 28. #WESEEK_tech (再)本日のアジェンダ 1. サービス運営の上で必要な監視項目とは ○ SRE の考え方から、本当に監視すべき項目を設定する 1. サービスの可用性を計測・可視化する手法 ○ 1. を実現するために必要な情報を揃える手段を実装する 1. 可用性を維持/向上するために必要な取り組み ○ 1./2. を用意した上で、実際にどのような取り組みを実施しているか 28
- 30. #WESEEK_tech 指標は決まった…が ● サービス運用で活用できなければ意味がない ○ 継続的に SLI を計測できているか？ ○ 継続的に SLO を達成できているか？ ○ すぐに確認できる環境整備が必要 ● SLI を計測し、SLO と比較できる環境を準備する必要がある 30 サービスの可用性を 計測・可視化する手法
- 31. #WESEEK_tech 可用性の計測・可視化に必要な事項 1. 監視・可視化ツールの選択 2. 監視ダッシュボードの作成 ○ 何をどのように可視化するかを決める ○ システム全体と個別のコンポーネント、それぞれのカットで見られると望ましい 31 サービスの可用性を 計測・可視化する手法 ゴール: サービス運営に必要な SLI を簡単に 確認できること
- 32. #WESEEK_tech 導入時の前提 ● 稼働環境 ○ GKE(Google Kubernetes Engine) 上で稼働 ○ ノード数 ■ サービス開始時には 15 台程度 ■ 顧客が増える、サービスが拡大すると、ノード数が増える可能性がある ● その他の希望 ○ スモールスタートで始められて、最初はあまり費用がかからない ○ 最初は取れるメトリックは全部取って、後で取捨選択できるとよい 32 サービスの可用性を 計測・可視化する手法
- 33. #WESEEK_tech 監視・可視化ツールの選択 ● マネージドサービス ○ New Relic ○ DataDog ○ Google Cloud Monitoring ○ Mackerel ○ etc… ● OSS ○ Prometheus ○ Zabbix ○ Nagios ○ etc… 33 サービスの可用性を 計測・可視化する手法
- 34. #WESEEK_tech 監視・可視化ツールの選択 ● マネージドサービス ○ New Relic ○ DataDog ○ Google Cloud Monitoring ○ Mackerel ○ etc… ● OSS ○ Prometheus ○ Zabbix ○ Nagios ○ etc… 34 サービスの可用性を 計測・可視化する手法 最初からあまり費用をかけたくない… ノードごと/コンテナごと課金がある…
- 35. #WESEEK_tech 監視・可視化ツールの選択 ● マネージドサービス ○ New Relic ○ DataDog ○ Google Cloud Monitoring ○ Mackerel ○ etc… ● OSS ○ Prometheus ○ Zabbix ○ Nagios ○ etc… 35 サービスの可用性を 計測・可視化する手法
- 36. #WESEEK_tech GROWI.cloud の事例 ● Prometheus を選択 ○ 可視化には Prometheus をサポートしている Grafana を選択 ● 選択理由 ○ Cloud Native 界隈で話題になっていたから ○ GROWI.cloud が載っている Kubernetes と相性がよさそうだったから ■ Service Discovery 機構がついていた ● プロセスの再起動をすることなく、動的に監視ターゲットを増やせる ■ デプロイ手法が整備されていた ● helm chart が既にあった ○ exporter を増やすことで任意のメトリックを溜め、アラートを出すことができるから 36 サービスの可用性を 計測・可視化する手法
- 37. #WESEEK_tech 採用ツールのご紹介(1/2) ● Prometheus ○ Go 製 ○ メトリックを出力する外部ツール (exporter) からデータを取得し、 自身が持つ DB に入れる ○ メトリックにはラベルを付加でき、 ラベルを基に様々な操作を行う ■ ex.) アラート対象 ○ コンポーネント間の通信はすべて HTTP ○ アラート/可視化は別のツールで行 う 37 サービスの可用性を 計測・可視化する手法 refs: https://prometheus.io/docs/introduction/overview/#architecture
- 38. #WESEEK_tech 採用ツールのご紹介(2/2) ● Grafana ○ Go 製 ○ 任意のダッシュボードを作成可能 ○ グラフ、数値出力など豊富な表示コ ンポーネントを装備 ○ Prometheus, Graphite など様々な データソースに対応 38 サービスの可用性を 計測・可視化する手法 refs: https://ja.wikipedia.org/wiki/Grafana
- 41. #WESEEK_tech GROWI.cloud 上での可視化例(1/4) ● システム全体の情報 ○ 過去 30 日間の SLI 値 ■ ノードタイプごとに分離して出力している ○ インストール GROWI 数 ● 個別コンポーネントの情報 ○ 各 GROWI ごとの SLI 値、許容される残り down 時間 ○ ミドルウェア情報(CPU/メモリ使用量/コネクション数など) ○ ノード情報(CPU/メモリ使用量など) 41 サービスの可用性を 計測・可視化する手法
- 44. #WESEEK_tech GROWI.cloud 上での可視化例(3/4) ● 個別コンポーネントの情報(GROWI 個別情報/可用性) 44 サービスの可用性を 計測・可視化する手法
- 45. #WESEEK_tech GROWI.cloud 上での可視化例(4/4) ● 個別コンポーネントの情報(GROWI 個別情報/リソース) 45 サービスの可用性を 計測・可視化する手法
- 46. #WESEEK_tech まとめ ● 1. で決定した SLO/SLI を継続的に確認できるような環境を整備 ○ 監視・可視化ツールの選択 ○ 監視ダッシュボードの作成 ● GROWI.cloud では以下の構成で監視を実施している ○ Prometheus/Grafana を選択 ○ 全 GROWI / 各 GROWI に関する SLI の値を確認できるようにダッシュボードを用意 ○ GROWI が再起動してしまった原因を探りやすくするために、以下のようなグラフも併 せて用意している ■ メモリ/CPU使用率 ■ リクエスト数、等 46 サービス運営の上で 必要な監視項目
- 47. #WESEEK_tech (再)本日のアジェンダ 1. サービス運営の上で必要な監視項目とは ○ SRE の考え方から、本当に監視すべき項目を設定する 1. サービスの可用性を計測・可視化する手法 ○ 1. を実現するために必要な情報を揃える手段を実装する 1. 可用性を維持/向上するために必要な取り組み ○ 1./2. を用意した上で、実際にどのような取り組みを実施しているか 47
- 49. #WESEEK_tech 可用性を維持するためには ● SLI を SLO 以上に維持するように意識する ○ これに限ります ○ GROWI down が発生した場合は、すぐに様子を見る ■ ex.) SLO を下回りそうな GROWI については早急に何らかの対策を講じる ○ 今後発生しうる障害に前もって対応する ■ ex.) ミドルウェアのストレージ容量減少、冗長性低下 ○ これらの対応に必要な情報が、一目でわかるようなアラートを設定する 49 可用性を維持/向上する ために必要な取り組み
- 50. #WESEEK_tech 可用性を維持するためには ● SLI を SLO 以上に維持するように意識する ○ これに限ります ○ GROWI down が発生した場合は、すぐに様子を見る ■ ex.) SLO を下回りそうな GROWI については早急に何らかの対策を講じる ○ 今後発生しうる障害に前もって対応する ■ ex.) ミドルウェアのストレージ容量減少、冗長性低下 ○ これらの対応に必要な情報が、一目でわかるようなアラートを設定する 50 可用性を維持/向上する ために必要な取り組み アラート対応例を 1 つご紹介します
- 51. #WESEEK_tech 主に実施されるアラート対応例(1/2) 1. Alertmanager から Slack にアラートが通知される 1. Grafana を確認し、原因を調査する ○ 以下は、冗長化された GROWI が両方再起動された例 51 可用性を維持/向上する ために必要な取り組み
- 52. #WESEEK_tech 主に実施されるアラート対応例(2/2) 3. 稼働しているノードの再起動時間を調査する ○ 本事象時は、プリエンプティブルノードの再起動時間が近かった 4. GROWI の搭載ノードを変える 52 可用性を維持/向上する ために必要な取り組み このままだと 24 時間後にもう一度同じ 状況になってしまう → SLI 低下
- 53. #WESEEK_tech アラート対応時に見ているもの ● 先述した Prometheus/Grafana をフル活用 ○ アラートも Prometheus 上のメトリックをベースに出している ○ アラートには、当該の GROWI で SLO を達成するための許容される残りダウン時間も 記載している ○ 一目で GROWI がどういう状態なのかを把握できるようにするための情報を出している 53 可用性を維持/向上する ために必要な取り組み
- 54. #WESEEK_tech 可用性を向上するためには ● 可用性の値を逐次気にして、可用性を高められる箇所がないか探す ○ 「Availability 向上施策」として集中的に行った時期もあった ● 障害対応履歴を残す 54 可用性を維持/向上する ために必要な取り組み
- 55. #WESEEK_tech Availability 向上施策実例 ● プリエンプティブルノードを利用したプランでの冗長化 ○ ライト、バリュープラン ○ リリース当初は、プリエンプティブルノードに 1 GROWI しか乗せていなかったが、 99.4% の SLO を保てなかったため ○ 施策実施前 SLI: 99.00% ○ 施策実施後 SLI: 99.93% 55 可用性を維持/向上する ために必要な取り組み
- 56. #WESEEK_tech 障害対応履歴を残す ● 障害発生時に、振り返れるように経緯を残すのが大切 ○ ポストモーテム ■ https://qiita.com/an_sony/items/0565ad980f9097c76d11 ● 記録は重要！ ○ 対応者以外にも障害内容を伝えられる ■ 週次でチーム全体に報告し、対策内容について検討、実施へ繋げている ○ 有識者の知見を借りられる ○ 今後、似たような障害が起きないように、正しい対策を打てる ■ 対応後に、改めて監視で収集したデータと突き合せ、より効果的な対策へ ○ 今後、似たような障害が起きた時に、自分が/他の人が参考にできる ■ 自分が忘れないため 56 可用性を維持/向上する ために必要な取り組み
- 57. #WESEEK_tech まとめ(本日のアジェンダより) 1. サービス運営の上で必要な監視項目とは 1. サービスの可用性を計測・可視化する手法 1. 可用性を維持/向上するために必要な取り組み 57
- 58. #WESEEK_tech まとめ 1. サービス運営の上で必要な監視項目とは ○ 真に監視するべきものは何かを洗い出す ○ SLO を設定する 2. サービスの可用性を計測・可視化する手法 ○ SLI を算出できるメトリックを整備する ○ SLI を簡単に確認できるような環境を整備する ■ ex.) ダッシュボードを整備する、アラート内容に記載する、等 3. 可用性を維持/向上するために必要な取り組み ○ 対応時は、1./2. で整備したものをフル活用 ○ 対応後は、対応内容を残してチームに共有 ○ 継続的に SLI を改善できるような動きへ 58
- 59. #WESEEK_tech 今後 ● GROWI 上で実際に利用されるリクエストのエラー率で SLO を決定できる ようにしたい ○ 現状は、ヘルスチェックエンドポイントへの監視成功/失敗で判定している ○ より利用者の立場に立った監視ができるようになる 59
- 60. 質疑応答 60
- 61. #WESEEK_tech お知らせ① 次回のWESEEK Tech Conf 61
- 62. #WESEEK_tech お知らせ② GROWIについて GROWIのOSS開発に参加しませんか？ GROWI は、WESEEKが開発を行いMITライセンスで公開している オープンソースソフトウェアです。 開発を手伝っていただけるエンジニアの方を募集しております。 詳しくはGROWI公式サイトのJOIN USをご覧ください。 https://growi.org/ja/#joinus 62