operate_free_gitlab

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

6. 運用を始めてからの悩み
   ①ロゴのインパクトが強すぎた
   ②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の直編集はよくない）
   →　バージョンアップで随時対応
   

   View Slide

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

   View Slide

8. その他：運用フリーを目指して工夫したこと
   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. 適切なエラーと対処については模索中
   

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide