OSSは企業のソフトウェア開発も変えている

第一回の記事から随分時間が空いてしまいました。第二回です。第二回の今回は、GitHub.comとGitHub Enterprise、およびインナーソースについてお話したいと思います。

インナーソースって知ってますか？

今なにげなく"インナーソース"という言葉を使いましたが、皆さんはインナーソースという言葉を聞いたことはあるでしょうか？

日本語で検索する限り、まだまだほとんど情報は出てこないのが現状だと思います。英語で"Inner Source"または"Inner Sourcing"と検索すると、状況は少し違います。

おそらく、一部インナースペース的なスピリチュアルな記事が結果として出てくるとは思いますが、その後に出てくるのがオライリーの『Getting Started with InnerSource』という書籍だと思います。

これはPayPal社内の取り組みを例にとって、オープンソース・ソフトウェアの開発スタイル、文化を社内のソフトウェア開発に適用するとどうなるかについて語られた書籍です。この書籍は残念ながらまだ日本語化はされていませんが、英語に抵抗のない方はぜひ読んでみてください。一読の価値はあります。

Inner Sourceとは、オープンソース・ソフトウェアの開発プロセス、文化をファイアーウォールの後ろでも行う取り組みのことをいいます。この流れはこの1、2年でちょっとしたトレンドになりつつあります。

2015年のOSCONのキーノートとして、このInner Sourceについて語られた動画があります。こちらも英語のみとなってしまいますが、ぜひご覧ください。

このビデオにはJSONの発見者としても知られるダグラス・クロックフォードも出てきます。彼が今PayPalで働いていることもこのビデオから見て取れるわけですが、ここで語られているのは、今やオープンソース・ソフトウェアは世界を席巻しており、そこで成功したプロセス、文化というものは社内の開発にも有効である、ということです。そしてありがたいことにその中心に据えられているのがGitHubです。

部門間、プロジェクト間のサイロを壊し、開発者同士の自律的なコラボレーションを促進することが、企業の競争力にも繋がる時代が来ているということが言えます。彼らは専用のサイトも立ち上げており、それによると今年から定期的にカンファレンスも開催しているようです。ぜひチェックして見てください。

このような活動を行っているのはPayPalだけではありません。ウォールマートもまたInner Sourceへの取り組みに積極的です。ここでも語られていることは同じで、いかに社内のサイロを壊し、官僚主義をはびこらせないようにするか、社内の開発者に自律的なコラボレーションを促すことの重要性を語っています。ここでもその中心に据えられているのはGitHubです。

今年に入ってもInner Sourceについての言及は増えてきています。こちらの記事も参考になります。ここで語られているのはOSCON2015で語られたInner Sourceの動きはBloomberg社内でも同様に起きていること（もちろんここで使われているのもGitHubです）、そしてこの言葉の起源は実は既に2000年にティム・オライリーによって語られていたこと、などです。当時からオープンソース・ソフトウェアのスピードと勢いが企業のソフトウェア開発のあり方を変えるだろうことが予言されていたと思うと、感慨深いものがあります。GitHubとしても、その流れを推し進める手助けができたのではないかと密かに自負しています。

またこの記事では弊社のBrandon Keeperが弊社内でのInner Sourceのあり方について簡単に答えています。プロジェクトを始める時はまずタスクリスト付きのIssueを作り、関係者に @メンション をして通知することから始めます。彼が最近はじめたプロジェクトでは、Issueを開いて2分後には法務の担当者がそのプロジェクトに使おうとしている名称が他社の商標を侵害していないかどうかを調べ、問題なさそうであることをコメントし、その法務のコメントを受けてPRのチームが動き始め、5分もかからないうちにロゴが作られ始めました。

ここまで毎回すべてがうまくいくわけではありませんが、このようなプロジェクトの進め方は弊社ではごく普通に行われています。みなが臆することなく自律的に新しいプロジェクト、提案などを始めて、それに対して部署を超えて社員全員が議論をし、協力し、作業を分担して進めていきます。そこには部門間のサイロは全く無く、まさにオープンソース・ソフトウェアの開発者が毎日やっているのと同じ方法で新しいアイディアが生まれ、議論によって深められ、実行に移されていくのです。

このインナーソースを支えているのがGitHubであり、GitHub Flowであり、そして社内でGitHubを使うことのできる、GitHub Enterpriseという製品なのです。上記に挙げた事例では、いずれの企業も社内でGitHub Enterpriseを使うことで、Inner Sourceの取り組みを加速させることに成功しています。

GitHub Enterpriseの紹介

GitHub Flowについては次回の記事で詳しく解説しますが、今回は名前は耳にするけど実態がよくわからない、という声の多いGitHub Enterpriseについて解説したいと思います。

GitHubには、企業向けのバージョンが存在します。これをGitHub Enterpriseとよんでいます。クラウドサービスであるGitHubを、社内ネットワーク内でも使えるようにしたものです。

社内ネットワーク内で使えるため、コンプライアンス的なニーズを満たし、セキュリティ要件をクリアできます。またバックアップなどの運用フローも会社のポリシーに則って行うことが可能です。監査証跡も残りますし、監視ツールやテクニカルサポートも充実しているのが特徴です。

GitHub.comとEnterpriseの関係

GitHub Enterpriseに関するよくある誤解が、"GitHub.comとは全く別のものなんでしょ？"というものです。GitHub EnterpriseはGitHub.comとコードベースは全く同一です。ですので、GitHub.comで使える機能はすべてGitHub Enterpriseでも同じように使えると考えて大丈夫です（JupyterのサポートのようにEnterpriseでは使えないものがありますが、ごくごく一部に限られます）。

さらにGitHub Enterpriseには、運用管理をサポートするものを中心に、Enterprise版だけ利用可能な機能が搭載されています。イメージとしては、GitHub.comにEnterprise特有の機能が追加されているものと捉えてください。

どのようにリリースされているのか

GitHub Enterpriseは4半期に1回のフィーチャーリリースを行っています。毎回前もってリリース時期を決めることはしていませんが、概ね3ヶ月毎にリリースしています。最新の2.7は2016年の8月に出ましたし、2.6は5月、2.5は2月にリリースしています。

また、脆弱性対応やバグフィックスは適宜リリースしています。詳しくはこちらをご確認ください。

GitHub.comで動くものはGitHub Enterpriseでも同様に動作する

先ほど説明したとおり、GitHub.comとGitHub Enterpriseはコードベースが同一ですから、一方で動作するものは他方でも同様に動作します。機能もそうですし、APIやWebhookも同様です。このことはGitHubと一緒に使うことの多いCIやCDツールの相互運用性の担保にもつながり、GitHub.comとGitHub Enterpriseを同時に利用する際にも大きなメリットがあります。

この連載において、今後GitHubの様々な機能や使い方を紹介していく予定ですが、そこで触れられたものは基本的にすべて、 GitHub.comでもGitHub Enterpriseでも同じように動作します。そのことをまずこの連載でお伝えしたいこともあり、GitHub Enterpriseの話を第二回に持ってきました。

GitHub Enterpriseの特徴とメリット

繰り返しになってしまいますが、GitHub Enterpriseのメリットは社内ネットワーク内でGitHub.comで使える機能がすべて使えること です。コンプライアンスやセキュリティポリシーをクリアしつつ、Pull Requestを中心としたGitHub Flowが使え、部門化を超えたコラボレーションが可能になります。検索機能もGitHub.comと同様に利用でき、社内のナレッジベースとして使うことも可能になります。

GitHub Flowやその他機能については次回以降の記事で詳細に解説していきますが、ここではEnterprise特有の特徴やメリットについて説明します。

メンテナンスの容易性

GitHub EnterpriseはシングルVMアプライアンスという方式で製品を提供しています。GitHubを構成する技術要素としては、Ruby、Rails、Redis、MySQL、Elasticsearch、git、Linuxカーネル、etc... と多岐に渡りますが、これらを1つのVMに収め、アプライアンスとして提供しています。

運用担当者は、各技術要素、各コンポーネントを意識することなく運用することが可能です。1つのVMで5,000ユーザーまでは楽々リクエストをさばけるように設計されており、多数実績もあります。もちろん、運用に際して必要なスペックも明示されています。ハイパーバイザーとしてはvSphere、Hyper-V、Xen、OpenStack KVMをサポートしています。またパブリッククラウドとしてはAWSとAzureもサポートしており、それぞれすぐに使えるよう、AMIやTemplateが用意されています。

VMで用意されていることから分かる通り、バージョンアップもGitHubが用意したコマンドを使ってVMを入れ替えるだけで済むため、大変容易になっています。もちろんユーザーデータが格納される領域とGitHub Enterpriseが利用する領域は分かれていますので、VMの入れ替えによってデータが消える心配はありません。

アカウント管理が可能

アカウント管理を可能にするため、GitHub.comと同様の認証方式に加え、LDAP、SAML、CASといった認証方式をサポートしています。社内でActive Directoryなどを使っている場合もLDAP連携できますし、Oktaのようなツールでシングルサインオンを組んでいる場合もSAMLを使って連携できます。

一定期間利用していないユーザーをサスペンドしてライセンス費用を浮かすこともできますし（GitHub EnterpriseもGitHub.comと同様、アカウントごとのお支払いとなりますが、サスペンドされているアカウントはカウントしません）、ユーザーのパスワードをリセットすることなどもできます。

もちろんGitHub.comと同様、2要素認証をサポートしていますので、セキュリティ的な対策も万全です。

手厚いサポート

GitHub Enterpriseの最大の特徴の1つが手厚いテクニカルサポートです。GitHub Enterpriseのライセンス費用には24時間x5営業日のテクニカルサポートと、24時間365日の緊急サポートが無償でついてくることを知らない方は意外と多いです。サポートページはこちらです。

GitHub Enterpriseのテクニカルサポートはアウトソースをせずに、GitHubberが直接サポートしていることが特徴です。弊社のサポートエンジニアは全タイムゾーンに住んでいます。アメリカの各タイムゾーンはもちろんのこと、ヨーロッパの各国、アジアの各国、日本、オーストラリアにそれぞれサポートエンジニアがおり、リモートワークをしながらGitHub Enterpriseのお客様をサポートしています。

皆、自らGitHubのバグフィックスやエンハンスを行う人達で、GitHubのコードによく精通しています。またバックグラウンドとしてVMのスペシャリストやインフラエンジニア、OSSのデベロッパーといった多種多様なスキルを持った人が集まっており、迅速かつ的確なサポートを提供しています。サポートの質はお客様から称賛の声をよく頂いています。

現状は基本的に英語のみのサポートとなっていますが、日本語でもサポートできるよう準備を進めているところですのでご期待ください。

そのほかの機能

無償のGit LFSサポート

巨大なファイルをGitで扱うためのオープンソースプロジェクトとしてGit LFSというものがあります。こちらはGitHub.comでは追加費用が必要なサービスですが、GitHub Enterpriseの場合はLFSサーバが予め同梱されており、追加費用なしで利用できます。

詳細についてはまた別の機会に解説したいと思います。

権限管理

これはGitHub.comにある機能ですが、OrganizationとTeamを使うことで、権限の管理が可能です。社内全体に見せるようにしたいリポジトリ、特定のOrganizationに所属していない人だけに見せたいリポジトリを分けて管理できますし、Teamごとユーザーごとリポジトリごとに、Write/Read/Adminといった権限を分けて設定することが可能です。

GitHub.comの場合Organizationごとに別々の料金が必要となってしまいますが、GitHub Enterpriseの場合はインスタンス内に複数Organizationを作ることができますので、適切に管理することが可能になります。

可用性ソリューションとバックアップ

ソフトウェア開発の重要性は日増しに高まっています。ソフトウェア開発に使っているツールが突然止まったり、障害が発生してしまっては、多大な機会損失や、直接的な損害が出てしまう可能性があります。

これを防ぐためにはシステムの可用性（High Availability）を高めることと、もしものためのバックアップ取得が重要です。

GitHub Enterpriseはこれらも予め用意して提供しています。

可用性ソリューションとしては、リアルタイムにレプリケーションをするツールを用意しており、当然ですが追加費用無しで利用できます。ドキュメントももちろんあります。設定はとても簡単で、プライマリノードに加えてレプリカノードを1台用意した上で、ドキュメントに従ってツールを設定するだけです。30分もあれば設定は終わるかと思います。

このツールを設定するだけで、Gitリポジトリはもちろん、RedisやElasticsearch、MySQLも含めたすべてのデータをレプリケーションします。このレプリケーションはアプリケーションレイヤーで行われますので、ハイパーバイザーレベルのレプリケーションと組み合わせて使うこともできます。プライマリノードに障害が発生した時には、用意されたプロモートコマンドを使ってレプリカノードをプライマリノードに昇格させ、DNSを切り換えてプライマリノードに向くようにするだけで終わりです。詳しくはGitHubにお問い合わせください。

バックアップはbackup-utilsというツールをOSSとして提供しています。GitHubのサポートエンジニアが中心となってメンテナンスしており、もちろんドキュメントも用意されています。こちらもCronにセットしておくだけで、すべてのデータをインクリメンタルにバックアップしてくれます。リストアのコマンドも用意していますので、バックアップデータからリストアするのも簡単です。

日々の可用性担保にはレプリケーションを、ディザスタリカバリ対応としてはbackup-utilsと、それぞれ用意しており、GitHub Enterpriseの導入を始めたその日からすぐに簡単にこれらの対応ができるのも大きな特徴です。

将来のユーザー拡大に容易に対応可能

前述したとおり、GitHub Enterpriseは1台のVMで、5,000人までは楽々さばきます。可用性やバックアップのソリューションも用意されており万全です。

ですが、さらなる規模の対応もできるのがGitHub Enterpriseの特徴です。5,000ユーザーを超えた規模になってくると、利用状況によっても変わってきますが、1台では足りないケースが出てきます。そんな時には、Clusteringオプションを有効にすることで、水平にスケールアウトさせることも可能になります。

つまり、将来全社的にGitHub Enterpriseを使うことになって、そのユーザー規模が1万や2万、3万を超えたとしても、いま使っているGitHub Enterpriseから別のものに移行せずにそのまま使い続けることが可能となります。Clusteringオプションにも追加費用は発生しません。

証跡管理

ユーザーのログインやGitの操作を含む各種操作がすべて監査証跡として残ります。下記のようにグローバルでの動きを閲覧することもでき、検索も可能です。もちろんこのログを取り出して保存することも可能ですし、後述のログ転送機能を使って外部の監視/分析ツールに転送して分析することも可能です。

ログ転送、監視機能

GitHub Enterpriseは下図のような独自のモニタリングツールを用意しており、そのメトリクスも50以上に渡っています。CPUやメモリの使用状況から、RedisやElasticsearchの負荷状況までモニターできます。

もちろんSplunkのような監視ツールを利用されているケースも想定して、ログ転送もサポートしています。FluentdやLogstashなども使えます。

そのほか、SNMPやCollectdにも対応していますので様々な形で運用監視が可能になっています。

pre-receive hook

2.6からサポートされたのがpre-receive hookです。

Gitには元々、サーバサイドフックとしてpre-receive hookとpost-receive hookが用意されていて、GitがPushを受け取る前のタイミングと後のタイミングにそれぞれ処理を挟むことができるようになっています。

従来、GitHubはWebhookという形で、post-receive hookだけをサポートしてきました。GitHub.comはマルチテナント型のサービスであるため、現時点ではpre-receive hookをサポートすることが難しいのですが、GitHub Enterpriseは企業ごとに別々のインスタンスを管理できるため、GitHub Enterpriseにおいてのみpre-receive hookをサポートできるようになっています。

詳細な使い方などは別の機会に解説したいと思いますが、用途としては、インスタンスレベルで何らかの制限をかけたい時などに便利です。例えば、

• 特定の拡張子のファイルは一律受け入れを拒否したい
• 一定のサイズを超えるファイルがPushに含まれていた場合は拒否し、LFSの利用を促したい
• 何らかのパスワードや鍵と思われる文字列が含まれていないかチェックし、含まれていたら拒否したい
• 各コミットにGPG署名が適切にされているかチェックし、ないものは拒否したい

などのユースケースが考えられます。

そのほか

そのほかにも様々な機能がGitHub Enterpriseには備わっています。今後の連載の中でできるだけ解説していきたいと考えています。

いますぐ詳しい話を聞きたいという方は、ぜひこちら(apac@github.com)にお問い合わせください。こちらのメールアドレスは日本語によるお問い合わせも受け付けています。

.comがマッチするケース、Enterpriseがマッチするケース

では、GitHub.comとGitHub Enterpriseはどのように使い分ければいいのでしょうか。答えはユーザー様次第、というのが実際のところです。オープンソースプロジェクトも会社で管理していて、社内の開発とオープンソースの活動を分けたくないというケースではGitHub.comがマッチしますし、社内のツールと連携して使いたい、自社のポリシーで運用したいというケースではGitHub Enterpriseのほうが向いています。

GitHub Enterpriseの運用コストは他のオンプレミスの開発ツールと比べると、大変低くなっています。VMで提供されていて、可用性やバックアップまで同梱しているためです。それでもGitHub.comに比べれば運用コストがかかりますし、価格体系も違います。さらに、複数のOrganizationを使いたい場合には、GitHub Enterpriseのほうが価格的に割安になるケースもあり、一概にこうだとは言えません。

これまで見てきたところによると、オープンソースプロジェクトや、社外の方とコラボレーションする目的でGitHub.comを、社内に閉じたプロジェクトにはGitHub Enterpriseを、と使い分けているケースが多いようです。

この辺りの使い分けについてもご相談に乗っていますのでぜひお問い合わせください。

GitHub Universe 2016

さて、今回はGitHub Enterpriseとインナーソースについて解説しました。この記事でも書いたとおり、GitHub.comで搭載された機能はGitHub Enterpriseにも搭載されます。そういう意味で、ぜひGitHubのブログは注視していてください。

そして、来る9月13~15日には、サンフランシスコでGitHub Universeというカンファレンスを実施します。ここでもかなり大きな発表が目白押しになる予定です。今後のGitHubおよびGitHub Enterpriseがどうなっていくかを占う意味でもぜひ注目していてください。当日はストリームも用意される予定です。