運用フリーを目指す運用管理術 株式会社ぐるなび インフラストラクチャサービスグループ 遠藤 耕平 GitLab Meetup Tokyo #8: GitLab 11.0

自己紹介 ● 株式会社ぐるなび（2010入社） ○ インフラストラクチャサービスグループ（サーバチーム） ○ サイトのインフラ構築 /運用 ○ インフラ作業の自動化 ○ 性能試験, 障害試験, 障害対応 ○ etc.. ● 出没界隈 ○ Cloud Native ○ Microservice ○ Chaos Engineering ○ etc..

● お話する内容 ○ オンプレで運用している方向け ○ 運用を始めてからの悩み ○ 構成/運用のポイント ○ 運用フリーを目指して工夫したこと

ぐるなびでの利用(since 2014, v7.4) Users：1300+ Groups：250+ Projects：3500+ Use Omnibus Package (Community Edition) Active Users : 40~50 Active SSHs : 20~30

リポジトリホスティング導入の歩み 2014~ ~2011 2011~ 入社前より存在していたので導 入の経緯は不明。開発者/デザイ ン/マークアップが利用。2011年 頃に開発者からGitやMercurial の要望が出てきて検討を開始 GitとMercurial共に利用できる Rhodecodeを導入。Subversionは 利用継続。一方でRhodecodeのみ では実現できなかった要件を Backlogで満たすといったホスティン グ戦国時代 デプロイ環境の抜本的な見直しと共にホスティ ングの見直しに着手。オンプレでの運用を前提 に検討し、最終的にGitHub Enterpriseと GitLabに絞られ、金額面を考慮しGitLab導入 に決定。 Subversion/Rhodecode/Backlogの利用も現 在はなくなりGitLabに統一された

運用を始めてからの悩み ①ロゴのインパクトが強すぎた ②Merge Requestが終わらない ④I/Oが思った以上に出ない ⑤reconfigureで元に戻る ③システムを複雑に構成してしまった ● 視線を感じる ● 「変えて欲しい」との声多し ● 8.xで現在のロゴがデフォルトに ● 先勝ち or 後勝ちが発生 ● 該当Issueは未確認 ● 8.xで改善を確認 ● 各コンポーネントを別々のサーバで構成 ● バージョンアップの調査検証が大変に.. （しなくなっていった） ● 現在はオールインワンで構成 ● リポジトリをNFS上に配置 ● IOPSが10もいかず ● getattrが4k/s （ACT/ACTで分散したらよかったかも） ● LVMに変更すると30~50 IOPS ● reconfigureすることは結構ある （no_proxyの追加など） ● そのたびに独自設定が元に戻る （timeout/threshold tuning） ● gitlab.rbで編集できるのが一番 （scriptの直編集はよくない） →　バージョンアップで随時対応

構成/運用のポイント ● バージョンアップを毎月実施する（前頁①,②,⑤） ○ 機能追加, バグ改修, 性能改善, Security Fix, etc.. ● オールインワン構成でも事足りる（前頁③） ○ https://docs.gitlab.com/ee/install/requirements.html#hardware-requirements ○ 2000users = 4コア/16GB ○ 足りない場合はスケールアップでの対応 ● 容量拡張目的ならストレージはLVMで（前頁④） ○ NFSにする場合はNFSリクエストを分散できる構成を検討

その他：運用フリーを目指して工夫したこと 1. バージョンアップ作業の自動化 a. 22日直前がおすすめ i. 毎月22日がバージョンアップDay ii. 適用が早すぎるとバグを踏む 1. 10.3.0で503エラー多発(#41510) 2. 10.3.3まで修正が長引いた b. 機能テストで失敗したらロールバック 2. 機能テストの自動化 a. 全ての変更の事前キャッチアップは困難 b. 機能テストを実施＆自動化することで構成変更時 の異常を早期キャッチアップ i. Group/Project作成 ii. Commit/Push iii. Branch/Issue iv. Merge Request/Merge 3. ELK/EFKによるログの可視化 a. production_json/api_json ログ i. 「誰が」「どこで」がより明確に取得 b. 50xエラーを検知したら発砲 i. バグ/設定ミス/タイムアウト c. どのリソースが不足しているか i. Active users / IOPS / Projects etc.. 4. 応答遅延/50xエラー検知で再起動 a. zabbixエージェントを利用 b. APIのURLを監視し、以下条件でGitLab再起動 i. 応答遅延 ii. 50x系エラー c. 適切なエラーと対処については模索中

運用フリー ≠ 放置 ● Deprecationsの確認は大事 ○ 11.0：APIv3の完全廃止 　　　Mattermostのオプション変更 　　　DSA SSHキーのサポート終了 　　　9.5未満のPostgreSQLサポート終了 　　　etc..（重たいものはメジャーバージョン時が多い） ○ 事前に告知されているのでリリースページで確認する ● 新機能の追加 ○ GitLab Runner / ContainerRegistry / Auto DevOps / etc.. ○ 運用をフリーにして浮いた時間で新機能の検証を！！

まとめ ● 運用しやすい構成にする ● 自動化で運用フリーにする ● 浮いた時間でよりよい運用の輪を ○ Deprecationsは確認大事 ○ 新機能の追加

ご清聴ありがとうございました