GREE Tech Talk: GitHub:E Casual Talk
2013/3/12
ピンクのユニコーンを見ないための工夫がずらり！
かのLinus Torvaldsが始めた分散バージョン管理システム「Git」はリポジトリに対する変更の概念を大きく変えた。そして、Gitリポジトリをホスティングするサービス「GitHub」は文字通りGitのハブとしての存在になり、「フォーク」という最大の特徴を生かして世界中の開発者たちの間で急速に広がっていった。
そしていま、企業ユーザーから熱い視線を浴びているのがGitHubが有料で提供するエンタープライズ向けサービス「GitHub Enterprise（以下、GHE）」である。
GitHubの利便性はそのままに、GitHubが用意するすべての機能を制限なく使え、さらに、オープンソース開発だけではなく社内のプライベートなリポジトリとしても活用できるサービスとして、Webサービス事業者を中心に利用者が増えつつある。
とはいうものの、やはりフリーミアムモデルにおいて無料から有料へとシフトするにはいくつかの壁があるのも事実。その壁を取り払うには、やはり実際に使っているユーザーの声が最も力を発揮するといえる。
本稿では2013年1月23日に東京・六本木にあるグリー本社で開催されたGitHubユーザーのためのイベント「GitHub:E Casual Talk - 第2回GREE Tech Talk」の模様を紹介、GHEのメリットや運用に当たっての注意点などを考えてみたい。また、最後にGitHubの新機能も紹介する。
- グリーの活用事例から見るGHEのメリットと問題点
- ドリコムはいかにしてSVNからGitlabに移行したのか
- クックパッドにおけるGHEとAWSの連携レシピ
- はてながSVN→Git→GHEと滑らかに移行できた理由
- ペパボはGitHubを人事評価とデザイン共有に使う
- DeNAが明かすGHEの中身と大規模運用3つのポイント
- 次期バージョンのGitHubに期待してほしい
グリーの活用事例から見るGHEのメリットと問題点
500人の定員が満席となったグリーの大会議室で最初に登壇したのは、そのグリー 開発本部に所属する大場光一郎氏。2012年2月からGHEを運用しているグリーだが、グリーほど大規模な事例はGHEの中でもほとんど存在せず、大場氏はこの1年の苦労を次のように冗談交じりに振り返っている。
「GHEの運用に当たっては相当な地雷を踏んできた。2012年の3月から6月にかけて、ほぼすべてのプロジェクトをGHE上に移行したが、5月以降にGHEを使い始めたユーザーの皆さんはグリーに感謝してください（笑）」（大場氏）
GHEの5つの主なメリット
大場氏はまずGHEのメリットとして以下を挙げている。
- オンプレミスな環境でGitHubのすべての機能を制限なく利用でき、社外に公開できないソースも置けるため、セキュリティ的にも安心
- GitHub.comがメンテナンス中でも問題なく使える
- LDAPやActive Directoryなどのディレクトリサービスと結合でき、社員番号による認証なども可能
- どんなプロセスが走っているか確認できるマネジメントコンソール、ストレージの残りサイズまでチェックできるアドミンバーなど、運用のためのインターフェイスが使いやすい。ターミナルコンソールも利用できる
- アップグレード機能でGitHubから提供されるパッチキットが自動で適用される
特に「sshでログインして中の状態を見ることができるコマンドコンソール」（大場氏）は、GHEならではの便利な機能だという。
GHEのコストパフォーマンス
GHEのコストパフォーマンスについては、「ライセンスは20ユーザー／年間5000ドルという単位でしか購入できないが、1ユーザー当たりに換算すると月間20ドルほど。大体コーヒー2杯分くらいで1カ月GitHubが好きに利用できると考えればお得なのでは」（大場氏）と語る。
GHEの運用における3つのコワい実話
そして肝心のGHEの運用に関しては「便利なことも多い半面、安定した運用が難しいのも事実。運用に当たっては自己犠牲の精神とエンジニアの下支えが欠かせない」（大場氏）と強調する。現段階では、自ら他山の石となる心構えがなければGHEのオペレーションに立ち向かうのは、やや困難のようだ。
大場氏はGHEを運用していて「実際にあった3つのコワい話」として、以下を挙げた。
- root disk full
- Indexer overload
- Upgrade failures
特に被害が大きかったのが1の「root disk full」だという。
GHEのrootパーティションサイズはデフォルトで10Gbytesしかなく、そのことを意識せずに使い続けていたらログやアップデート、テンポラリなどがどんどん増えていき、「重要なサービスのリリース直前に突然、死を迎えた（GitHubがまったく起動しなくなった）。当時はコンソールで入る機能がなかったため、GitHubにバックドアを作ってもらうことで何とか対応した。データはUbuntuのリカバリモードでシフトした」（大場氏）とのこと。
この事件をきっかけに「$ ghe-grow-roootというコマンドをGitHubに作ってもらったが、このときは結局1度しか利用せず、パーティションサイズも30Gbytesくらいまでしか増やすことができなかった」という。
このように致命的なトラブルを経験しつつも「GHEのサポート体制はきちんとしている」と大場氏は評価している。ただしサポートは英語、そして西海岸の時間帯に合わせることになる。「GHEを運用するにはさまざまな面で覚悟が必要。でもその分、得られるものは大きい」という大場氏の言葉にあるように、5000ドルの初期費費用のほかに、ユーザーサイドがGHEとともにノウハウを作っていく覚悟は、少なくとも現段階では欠かせないようだ。
ドリコムはいかにしてSVNからGitlabに移行したのか
Git、そしてGitHub全盛のWebサービス開発において、実は「ウチはまだSubversionを使っている」という組織も少なくない。SubversionからGitHubへの移行を試みてはいるものの、さまざまな“大人の事情”でSubversionを使い続けている開発者は現状をどのように改善しようとしているのか。ドリコム 大仲能史氏が同社におけるSubversionからGitへの移行について語った。
暗黒のSubversion期
ドリコムではSubversionを使い、3つのメインブランチ（trunk／staging／release）間をコミット→チェリーピック＆ステージング→リリース→再びコミット……というサイクルを回していくスタイルで開発が行われていたが、このやり方では「数多くの課題が山積していた」（大仲氏）という。
「まずブランチ作成コストが重く、ブランチが切れない。さらに数百コミットの中からリリースすべき100コミットを見つけ出してコンフリクトしないようにマージするなど、チェリーピックがもはや職人芸の域に達していた。これだと、1つのアプリに1人のマージ職人が必要になるので、職人の数しかアプリが作れないことになる。加えてマージインフォが膨れ上がってディスクI/Oを食い、とにかく遅くてしょうがなかった」（大仲氏）
GHEの試用→挫折
Subversionに募る不満は自然と巷で人気のGitへと目を向けさせる。大仲氏はGHEの試用版（45日限定の無料トライアル版）の導入を図ってみた。しかし、ここでの結論は「試用版は、やはり試してみる程度にしか使われない。Gitを使っているのは自分だけで周りは全員Subversionのまま」（大仲氏）という痛ましくもよくありがちな事態に見舞われる。
「長過ぎたSubversion時代が、Subversionでも“回せる”状態を作ってしまった。取りあえず回っているものを無理やり移行させようとしても、そのありがたみは伝わりにくい」と、大仲氏は敗因を分析している。
速くて「プルリクエスト駆動」な今風のGitだが、200アカウント（5000ドル）の初期投資に教育コスト、移行期のごたごたによる運用速度の（一時的な）低下というデメリットもある。「Gitという文化の価値をお金に換算することが難しく、また確実性に欠けるということでGHEの導入は見送りとなった」と大仲氏は当時を振り返る。
Gitlabを選定
しかし、やはりプルリクエスト文化を実現するGitへの想いは断ち切れなかった。「何とかイニシャルコストを掛けずに始める方法はないものか」と考え抜いた大仲氏は、以下の選定基準で新たなバージョン管理システムを探し始める。
- GitHubライクなWebユーザーインターフェイス
- 管理もWebユーザーインターフェイスから可能
- プルリクエスト機能がある
- 今後数年、主流を行きそう
そこで目に留まったのがRuby on Railsで書かれた「Gitlab」だった。ドリコム社内には80名を超えるRailsエンジニアが在籍しており、「モダンなRailsアプリの運用には慣れており、最新のRailsで今風のライブラリがたくさん使われている」（大仲氏）ことが選択の決め手となった。
また、経験からメンテナーを固定すると失敗プロジェクト一直線になってしまうことが分かっていたため、複数人のメンテナーを社内に置けるGitlabは運用に関しても問題ないと判断したという。ただし大仲氏は、ここで「（GHEを導入できる)お金があればしなくていい苦労です！」とも強調している。
SubversionからGitlabへの移行
SubversionからGitlabに移行するに当たっては、前回のGHE試用版での失敗を踏まえ、まず全員にGitに慣れてもらい、Subversionから離れる準備をしてもらうところから始めた。また、Subversionとの併用期間中はリリースに関する運用を変えないことで、移行にまつわる混乱を最小限に抑えている。「リリースフローにチェリーピックを使わない状態を作れば、Subversionは捨てられるはず」という考えの下、結局、数週間ほどでプロジェクトをすべてGitlabへの移行を果たしたという。
「移行に当たって、Gitlabに新たな機能をいくつか追加した」と大仲氏。例えば、全プロジェクトを全ユーザーが閲覧可能にする、git-svnによるクロスコミット、監視などの機能だ（ここで再び「お金さえあればしなくていい苦労です!!」と強調)。また、移行によって弱体化した部分を補強するため、各種通知のためのボットも作成している。「Subversion補強ツールを作るより負けた感が少ない」（大仲氏）
俺たちの戦いはこれからだ
実はドリコムでは、「まだSubversionとGitの併用期間中だ」と大仲氏。それでもGitlabを導入することで「やはりプルリクエスト文化は“正義”だと感じた。ようやく正しい手順でコード開発ができるようになった」と強調する。
「プルリクエストのない環境で、その文化を作るのは、すごく難しい。だがGitlabによって、何とかその文化を手に入れることができた。GHEであれば、しなくて済む苦労がほとんどだが、自分たちの技術で何とかなるなら、それを極めてみたいという気持ちもあった。ただコスト的には結果として（GHEを導入する場合と）同じくらい掛かったかもしれない」と総括した大仲氏。苦労の末に手にしたプルリクエスト文化が、今後のドリコムのアプリケーションを変えていく。
クックパッドにおけるGHEとAWSの連携レシピ
国内最大規模のレシピ提供サイト「クックパッド」はそのサービスをAmazon Web Services（以下、AWS）のクラウドを使って提供していることでも知られている。またアプリケーションの開発もAWS上で行われており、いわばAWSはクックパッドを内側と外側の両方から支える最も重要なインフラと言える。しかし、実はAWSとGitHubおよびGHEの連携に関しては、ほとんど事例が見当たらない状況にある。
クックパッドのインフラの要であるAWSとGHEはいかにしてジョイントすることが可能になったのか、クックパッド 高井直人氏が解説を行った。
冒頭から冗談交じりのコメントでプレゼンを始めた高井氏。やはりGHEの運用には、それなりの覚悟が必要であることが感じさせられる。
クックパッドのサイトには月間2000万を超えるユニークユーザーが訪れ、130万以上のレシピが格納されている。デプロイは1日に10回ほどだが多いときは20回を超え、プルリクエスト数は4400を数える。
現在クックパッドでは、VMware ESXi（Intel Core i7-2600Kおよび16Gbytesのメモリ）上でGHEを動かしており、毎日スナップショットを取りながら運用しているという。レポジトリ数は300を超える。
GHE導入以前はGitHub.comを使っていなかったクックパッド
GHE導入以前、クックパッドではGitHub.comは使わず、AWS上に構築したGitサーバを同じくAWS上に置いたCIサーバと連携させながら運用しており、開発者はsshでログインして利用していた。GitHub.comを使わなかったのは、クックパッドのセキュリティポリシーに合わなかったこと、サービスの信頼性に疑問があったことが主な理由だという。
「セキュリティに対する懸念が払拭されなかったこと、それからベンチャー企業なのでどこかに買収された場合、ポリシーが変更されるのは避けたかった。またサービスがよく落ちることを聞いていたので、サービス提供者側としてはつらいものがあった」（高井氏）
だがサイトとしてのクックパッドは急速に成長し、次第に従来のGitサーバでは支え切れなくなっていく。「コードベースの増え方が急激で、トラック変更を追うことが難しくなってきた。レビューが困難になり、開発者に苦痛を強いるようになってしまった」と高木氏は当時を振り返る。新しく効率的なコードレビューのためのバージョン管理システムとして、2012年4月にGHEを導入する。
GHE導入後のクックパッドでの課題
しかし、ここに最大の難関があった。クックパッドのサーバはほとんどがAWS上にある。当時、GHEはAWS上で動かなかった。高井氏は「おそらく現在も動かないはず」というが、どうしてもAWS上にあるLDAPサーバやSMTPサーバと接続させねばならず、また開発者が外部のネットワークからアクセスできることも必須だった。さらに、Gitのデプロイプロセスに大きな変更を加えないことも重要なポイントだった。
「GHE導入時はLinuxベースといえども、ほとんどブラックボックスだった。AWSにあるサーバとどうつなぐのか、これが最大の課題だった」（高井氏）
これらの解決に大きく貢献したのがSSHトンネルの存在だ。GHEを置いたLANとサーバ群を抱えるAWSはダイレクトアクセスができない状態にある。そこで、SSHトンネルを使ってSMTPとLDAPの口を用意し、LAN側に置いたたヘルパーのポートを叩くことで通信を実現した。なお、高井氏によれば「いまではautosshを使っている」という。
SSHトンネルを活用
開発者がインターネット越しに外部からアクセスするときもSSHトンネル（autossh）が活躍している。AWS上にリバースプロキシサーバを立て、AWSとLANの間にあるゲートウェイに接続し、SSHトンネルを経由してヘルパーからGHEへとアクセスを可能にした。このとき内部の名前解決と外部の名前解決をそろえてやることがポイントになるという。
デプロイのプロセスも変わった
また高井氏は「GitでSSHを使いたいなら、.ssh/configは設定次第で、けっこう何でもできる。ホストの方で名前解決をすれば、外部からゲートウェイにアクセスすることも可能」としている。
またデプロイのプロセスに関してもSSHトンネルの存在が前提となっている。LAN側のGHEをヘルパーの口からSSHトンネル経由でAWS上のGitサーバと接続し、開発者がGHEにプッシュしたら、いったんGitサーバにプッシュする仕組みにしている。こうすることで、すべてのコミットがGitサーバ上に置かれることになるので、GHEが落ちてアクセスできなくなったとしても、SSHでGitサーバにプッシュすればよいので安心して運用できるというわけだ。
もっとも「実際は、そう簡単にはいかない」と高井氏。そこでクックパッドでは、Sinatoraで書かれた「clone pusher」というスクリプトを使い、GHEのサービスフックを介してAWS上のGitサーバにプッシュしているという。
AWS上でGHEを直接扱えない現状ではSSHトンネルを利用したオンプレミスとの接続が最善の選択というクックパッドの事例。今後、クラウド上でGHEを利用したいというニーズの高まりに、GitHubがどう対応していくのかにも注目していきたい。
はてながSVN→Git→GHEと滑らかに移行できた理由
ドリコムの大仲氏が紹介したSubversionからGitlabへの移行事例のように、ある環境から別の環境へと移行するとき、急激な変更をユーザーに強いると、うまくいかないケースが多い。多少時間がかかったとしても、現在の環境と並行しながら徐々に切り替えていく方がユーザーの心理的にも受け入れやすいといえそうだ。はてなの伏井洋平氏がプレゼンを行ったGitからGHEへの移行も、やはり“滑らか”であることが欠かせなかったようだ。
はてなでは、2008年5月にいろいろと問題が多かったSubversionから移行し、いまでは700を超えるリポジトリを抱えている。数多いリポジトリを管理しやすくするための内製リポジトリビューアや、ブログベースのグループウェアなど、Gitで開発をしやすくするための環境を整えてきた。
GitからGHEへ移行した際の課題
だが、GitHubがブームになるにつれ次第に、はてなの中にも「プルリクエストしたい」という要望が強くなってくる。「時代的に間違いなくGitHubが来ている」と判断し、かねてユーザーであったGHEへの移行を決断した。
移行に当たっては当然、いくつかの課題があった。前述したとおり、はてなには700を超えるGitリポジトリがあり、中には昔のインターンが作ったコードなども。「こんなモノを移行する必要があるのか？ と個別の判断に悩むことも多かった」と伏井氏。また、GHEをまったく必要としないチームもあり、「一気にすべてのプロジェクトをGHEに移行するのは現実的ではなく、しかしGHEに移行したいユーザーはすぐに開始できるような、段階的で滑らかな移行が必要だった」と伏井氏は当時を振り返る。
また、サーバの移行に関しては「GHEについては、いろいろとコワい話を聞いていたので、移行によってデプロイ作業が中断するようなことは絶対に避けたかった」（伏井氏）ため、8コア／500GbytesのSSDにVMware ESXi、アクティブ／スタンバイ構成というハイスペックな環境を用意したという。
「はてなはGitをかなり使い込んでいたので、正直GHEに移行するのはつらかったが、何とかしのげたのはミラーリングのおかげ」と伏井氏は語っている。GHE移行前は、開発者はリポジトリサーバ（Hatena Repos Server）にプッシュし、それからアプリケーションサーバにプログラムをデプロイしていた。移行後は、GHEとはてなレポジトリの間でミラーリングできるペア（ミラー元のソースをGHEに、デスティネーション先をはてなレポに）を作成しておき、GHEからWebフックでリポジトリサーバに対してミラーリングする。
内製のミラーリングペア管理ツール「ghm」でWebフック
Webフックは内製のミラーリングペア管理ツール「ghm」を使って行う。こうすることで開発者がGHEにフックするとリポジトリの内容が常に一致している状態が保たれる。「ミラーリングの設定はある程度手動でやらないと無理なので、手が掛かるのは確か」と伏井氏。ミラーリングの設定が、ややこし過ぎるという声に応え、ミラーリングを自動化する「git hatena mirror」「git hatena sync」といったコマンドも用意し、GHEに移行したいユーザーが誰でもスタートできる環境を整えてている。
2012年8月からGHEの本格活用を開始、現在はてなでは「80％のチームがGHEを利用しており、アクティブリポジトリのうち25％がGHE上で動いている」とのこと。ハイスペックなサーバを使っているせいか、いまのところGitHubがダウンしたときに現れる「ピンクのユニコーンは見たことがない」（伏井氏）というほど順調な運用を続けている。急激な変更ではなく現状を維持しながら“滑らかな移行”を目指したことで成功した好例といえる。
ペパボはGitHubを人事評価とデザイン共有に使う
GitHubを使ってバージョン管理だけではなくプロジェクト管理を行うユーザーも増えているが、paperboy&co.（以下、ペパボ）の宮下剛輔氏が紹介した内容は、もう少し変わっている。同社では社内の技術者向け人事評価と、デザイナ間でデザインプロセスを共有するのにGitHubを利用しているという。
変わった使い方【1】技術者向け人事評価にGitHubを使う
同社では技術者に対しては2段階の評価が適用されており、テクニカルマネージャによる1次評価と、経営会議メンバーによる2次評価に分かれている。宮下氏はテクニカルマネージャを務めているため1次評価を行う立場にある。
まず、評価される側の技術者がフォーマットに従ってマークダウン方式で自己評価を行い、指定されたGitリポジトリにプッシュし、プルリクエストを送る。評価者は文書の内容に基づきエンジニアと面談を行い、各人が提出した文書に評価ポイントを追記してマージし、再びプッシュする。Gitリポジトリは社内の誰もが参照できるようにしてあり、マークダウン方式で書かれた文書もHTML変換がなされて、誰もが読める状態で公開されているという。面談以外の評価プロセスが透明化されている点が特徴だ。
GitHubによる評価プロセスを適用しているのは技術者だけだが、その理由について宮下氏は「デザイナと比較して、技術者は評価するポイントやプロセスを明確にしやすいから」と説明している。
変わった使い方【2】デザイナ間でのデザイン共有にGitHubを使う
また、もう1つの変わった使い方として、社内のデザイナ間でのデザイン共有にもGitHubを利用している。「スクリーンショットを置くためのリポジトリを作ったり、デザインの共有をissueベースで行っている。誰がデザインしたものなのかもすぐ分かるし、いろんな人がコメントを付け合うことでプロセスの共有が進む。GitHubはアイコンや絵文字が使えるのがすごく良い。コミュニケーションにも役立つ」とGitHubがデザイナ向きであることを強調する宮下氏。
なお、ペパボではデザイナでも普通にコマンドライン（GitHub for Windows）からGitHubを使っているという。
「ペパボは技術よりもデザインで評価されている会社なので、こういう使い方はペパボらしいと言えるかもしれない」と宮下氏。今後は「社内や社外でやるイベントの共有もissueを使ってやってみたい」など、新たな取り組みへの意欲も見せる。エンタープライズじゃないGHEの使い方をこれからも編み出してくれそうだ。
DeNAが明かすGHEの中身と大規模運用3つのポイント
ユーザー事例として最後に登壇したのはディー・エヌ・エー（以下、DeNA） IT基板部ネットワーク＆セキュリティグループの吉田拓真氏。2011年12月からGHE導入および運用にかかわっている。
DeNAでGHEを導入した結果
GHEを導入するまでDeNAでは「SubversionやTrac、Gitなどが技術者によってバラバラに運用されている状態だった」（吉田氏）ため、これを統一するためにGHEの導入に踏み切ったという。GHE導入後は、GHEとJIRAを連携して稼働させており、アプリケーション開発、リリース、障害対応のほか、プロジェクト管理からエンジニア間コミュニケーションに至るまでGHEを中心としたシステマティックな開発環境が構築できたとのこと。
「現状はかなり快適」と吉田氏は評価するが、一方で「裏を返すとGHEが死んでしまうと致命的」（吉田氏）であると認識しており、「大規模でGHEを運用するコツ、バックアップ、セキュリティなどは、ちゃんと運用するために押さえておかないといけない」と強調する。
DeNAではGHEをOVAファイルとしてVMwareホストにデプロイしている。インスタンス構成は「すごくシンプルに、アクティブ／コールドスタンバイ構成を取っている。VMware ESXi 5とGHEは1対1の割合」（吉田氏）とのこと。できるだけシンプルな構成を心がけている点が印象的だ。
「GHEをDeNAで運用して思ったこと」として吉田氏はまず「サーバの負荷は、それほど気にならない」という点を挙げている。「メモリは20GbytesもあればOK。ディスクI/Oもネックにならず、3Tbytes程度のIAサーバ1台で十分。SSDなどの必要性は特に感じない」としている。
また、ネットワークの負荷についても「利用時間が激しいときでもそれほど帯域の圧迫を感じないが、ギガバイト単位のバイナリ（動画など）には向かない」と指摘する。大規模での運用といっても、それほど特別な環境を必要としないようだ。
GHEをDeNAで運用した際の課題
ただし、やはり課題もあって「ちゃんとした冗長構成を取りたいのだが、OVAパッケージとして提供されるので、GHEの中身をカスタマイズすることはできない。GitHub社はVMware HAソリューションを推奨するが、高価なのと、GHE自体の冗長化にはならないので意味がない」と吉田氏。そうした制限がある中、GHEを安定運用するには「adminユーザーでsshログイン、すべてはここから始まる」と強調する。
「デフォルトでは無理だが（マネジメントコンソールから簡単に設定可能）、admin権限ではさまざまなオペレーションコマンドが利用できる。バージョン11.10.260まではこれができなかったので、すごく苦労した」（吉田氏）
adminユーザーでsshログインを行えばかなりのことができるが、吉田氏は「欲を言えば、やはりroot権限は欲しい」という。sshログインできるようになると、コマンドラインユーティリティ（Commnand-line Utilities）が使えるようになるので、「まずはルート（/）領域を拡張すべき」と吉田氏。GHEのデフォルトルート領域は10Gbytesなので、クエリログ（resque.log）もこの中に作られるため、アクセスが増えたりすると、当然ルート領域を圧迫する。
「2012年秋、アクセスの爆発とともに、こちらが死亡してしまい、広報からめちゃくちゃ怒られた」と振り返る吉田氏。やはりGHE運用にはつらい思い出が付きものらしい。このときは急きょサーバをリプレイスし、グリーの大場氏のプレゼンにも登場した「ghe-grow-root」コマンドでルート領域をオンライン拡張することで乗り切った。「VMware ClientでGHE仮想マシンに割り当てたディスク容量分、めいっぱい拡張してくれた」（吉田氏）
大規模GHE運用時のポイント【1】ログ
その他、大規模運用する際に覚えておきたいポイントとして吉田氏は「ログを見る」ことを挙げている。ログを見るコマンドは「ghe-logs-tail」で、オプションを利用するとアプリ、認証、システムログなどを個別に細かく参照できる。トラブルが起こったときは必須となる作業だ。
大規模GHE運用時のポイント【2】バックアップ
バックアップについては「VMwareのスナップショットはお勧めしない」と強調する。自動化が大変なのと負荷的に厳しいことが主な理由で、スナップショットを取ったまま放っておくと「ゾンビみたいな差分データファイルがどんどん作成され、肥大化し、ディスクが枯渇する状態になり、再起動しても何も起こらないという恐ろしいことになる」（吉田氏）とのこと。ここでお勧めするのは、やはりコマンドラインユーティリティで、以下の6種類を使いこなすようにするといいとしている。
- ghe-export-mysql ＆ ghe-import-mysql
- ghe-exporrt-redis ＆ ghe-import-redis
- ghe-export-repositories ＆ ghe-import-repositories
ただし、ここにも「罠はある」と吉田氏。それぞれのコマンドの中身をよく見ると、例えばMySQLのダンプを取るghe-export-mysqlは以下のようになっている。
mysqldump \ -u root \ --hex-blob \ github_enterprise
10分置きに回していたらテーブルロックが起こってしまい、ピンクのユニコーンが現れる羽目になったという。
そこで、new-ghe-export-mysqlというファイルにして、中身を以下のように書き換えて対処したとのこと。
mysqldump \ -u root \ --hex-blob \ --single-transaction \ ←追加 github_enterprise
用意されているコマンドの中身を確認するのもGHE管理者の仕事の1つのようだ。
大規模GHE運用時のポイント【3】セキュリティ
もう1つのポイントであるセキュリティについては、「ghe-logs-tail -a」というコマンドを使えば、「いつ誰がどのリポジトリに対してプル／プッシュ／クローンを行ったか」を簡単に監視できるとしている。怪しい動きに対してアラートを投げることも可能だ。
「ghe-support-bundle」というコマンドを使えばログ周り一式を圧縮保存できる。「GHEのログは7日間でローテーションされるので、外部サーバに逃してやって定期運用することもできる」（吉田氏）
また、DeNAではあえてLDAP連携はしていないという。その理由は「ユーザーの退職時の処理が面倒」であるため。その代わり「ghe-user-supend」という特定のユーザーを利用停止にする機能を使い、退職時に自動サスペンドするようにしている。
最後にまとめとして、「GHEを安定運用させるには、GHEの仕組みをしっかり把握すること、そして、コマンドラインユーティリティを（中身を見ながら）使い倒すこと。後は、Octocatを愛でること（笑）」と結んだ吉田氏。「本格的に運用したいなら中身を知ろうとする努力は、ものすごく大切。中身が分かると障害も見えてくる」と強調する吉田氏の言葉には、GHEだけではなく、大規模インフラを安定稼働させるためのポイントが詰まっている。
次期バージョンのGitHubに期待してほしい
ユーザーからの講演がすべて終了した後、特別講演としてGitHub社のDrew Wood氏が短いプレゼンを行った。
「GHEはツールと新しい働き方の両方を提供するもの。ブランチ、フォーク、プルリクエスト……。みんなで一緒に開発したことを実感できるこうしたGitHubの文化が、より多くのカスタマに広がっていってほしいと願っている。そのためにわれわれが最も重要視しているのはシンプルフィーチャーであるということ。すべてがWebブラウザから操作できて、運用も極めてシンプルに行えないといけない。そうすればGitの良さを知らない人たちに対しても、高い教育コストを払うことなくGitHubの良さを分かってもらうことができる」（Woods氏）
期待が掛かる次のバージョンでは、「みんなのフィードバックをたくさん反映させる予定。たくさんの新機能を搭載する予定」（Woods氏）とのこと。特に要望が多かったコントリビューション機能の改善を図っているという。その他、プルリクエストをマージした後にブランチを削除する機能やマネジメントコンソールAPI（ドキュメントはまだ）、マルチプルSSHキー、ノードロード、リポジトリ・レストアなどが追加されるという。
会場からの「（GHEには）どのくらいのマシンスペックが必要？」という質問には「まず、あなたがいくら持っているかだね」と軽くかわしながらも、「プロセッサはそれほど重要じゃない。一番重要なのはストレージI/Oかな。メモリは最低8Gbytesは欲しいところ」とコメントしている。
GHEの課題と期待
500名の大会議室が平日夜でも満席になったGitHub／GHEの勉強会。いまや世界中の開発者の間でプルリクエスト文化が主流になりつつある現在、それを社内の開発にも応用したいというニーズが生まれるのは当然の成り行きと言える。
だが、GHEはエンタープライズ向けのサービスというには、あまりにも突っ込みどころが多く、ユーザー自身がその欠点を受け入れつつ、自ら先行事例となって使いやすいシステムに変えていく意思がなければ、GHEを使いこなすことは難しいだろう。ユーザーがともに成長させていく過程を、お金を払いながらでも楽しめるかどうか、そう思える企業が増えれば、GHEは国内でもニーズが増えていきそうだ。
参考資料
本勉強会で使われた講演資料は、「GREE Tech Talk: GitHub:E Casual Talk：資料まとめ | イベントカレンダー＋ログ」から一覧できるので、参照してほしい。
「イベントカレンダー＋ログ」レポート投稿募集中！
このレポート記事が掲載されている本サービス「イベントカレンダー＋ログ」では、イベント登録者がレポートを投稿したり、資料を一覧できるまとめページを作成できます。新着レポートは一覧に表示され、こちらのRSSにも配信されるので、ぜひご活用ください。