2018年10月22日〜23日におこったGitHubの障害から考える

2018年10月22日 8:09〜2018年10月23日 8:03(日本時間)にかけて、GitHubのサービス障害が発生し、多くの企業やオープンソースプロジェクトのコミュニティーに影響を及ぼしました。

GitHubによれば、今回の障害によってデータが失われるという自体にはいたらず、復旧作業完了後は各種データが正常に表示されるようになりました。

今回のGitHubの障害について、以下にてGitHub社より報告が上がっています。(いずれも「The GitHub Blog」へのリンク。全文英語)

•  [October 21 Incident Report]
•  [October 22 Incident Update]

さて、今回はそれについて考察を述べていきます。

障害およびその復旧までのタイムライン

今回のGitHubの障害のタイムラインは以下のようになっているとのことです（いずれも日本時間）。

• 2018年10月21日 19:52: GitHub.comの複数のサービスがネットワークパーティションやその後のデータベース障害の影響により、ウェブサイトの情報に不整合が発生した。
• 2018年10月22日 8:09: エラー発生率が高まったことが「GitHub Status」に報告される。
• 8:13: サービス障害が報告される。
• 9:05: データストレージシステムの復旧対応を開始したことが報告される。
• 17:19: 「[October 21 Incident Report](https://blog.github.com/2018-10-21-october21-incident-report/)」が作成される。
• 20:56: 復旧プロセスの大半が完了。1時間後には全てのデータの一貫性が回復される見込みとなる。
• 22:18: データストア間の情報一貫性を検証、ウェブフックおよびページビルドは停止したまま。
• 2018年10月23日 1:24: データの整合性の検証完了。1:45以降にウェブフックが再開予定。
• 1:45: ウェブフック処理が再開(途中2:32に問題が発生して停止、3:26に再開)。
• 1:51: ページのビルドが再開。
• 8:03: 完全復旧

この件の障害の原因として、GitHubのデータストレージシステムに障害が起きたことによるものであるということは報告されていますが、データストレージシステムの障害の原因については、詳細には書かれていないようです。

GitHubで障害が起こった時はどうすべきか

今回のGitHubの障害で、その利用者は多かれ少なかれ影響が出ています。幸い、今回の場合はデータの消失が避けられたため、復旧した段階で作業を再開できましたが、今後も問題が起きる可能性は十分にあるため、あらかじめ対策を取っておく必要があると言えます。

その上で、GitおよびGitHubの特性を考えた場合、どういう風に対策を取るのがあるのか考えてみましょう。

前提条件: Gitは分散型バージョン管理システムである

まず、Gitは分散型バージョン管理システムであるという前提に立ち返りましょう。つまり、Gitは、それぞれの開発者が自身でリポジトリーを持っているということがあります。したがって、少なくともこまめにGitHubのリポジトリーをローカルに保存しているのであれば、第三者のローカルのデータ以外はバックアップが取れているということになります。

したがって、その特性がわかっていれば、万一GitHubに障害が起こったとしても、ローカルにデータが保持されていれば、最悪の自体は避けられると言えます。とは言え、ローカルのマシンに障害が発生した場合までは対処しきれませんが、基本的には複数人で開発していれば、データがなくなるということはそうそう考えづらいでしょう。

サーバーを分散化させる

対処法として、共有用のリポジトリーを分散化させるという手法が考えられます。この場合は、万一GitHubがダウンしても、適切に運用できていればリポジトリーを切り替えることで凌ぐことができるようになります。

しかしながら、複雑になり、コストもかかるので、個人ではあまり推奨できないでしょう。

GitLabやBitbucket

GitのホスティングサービスはGitHubが最もメジャーですが、それ以外にもGitLabやBitbucketなどがあります。多くの場合、プルリクエストなどのGitHubの機能の多くも似たようなのがあるため、やや利用しやすいでしょう。

ただし、プルリクエストなどはそれぞれのサービスに入ってしまうので、情報が散逸する可能性はやや高くなると言えます。

独自のGitサーバーを立てる

万一GitHubが使えなくなったときのことを考えたときは、独自にGitサーバーを立てるという方法があります。この場合は、万一GitHubが使えなくなった場合でも、共有用のリポジトリーがあるので、うまく使い分けていくということができるようになります。

一方で、プルリクエストやIssueなどは使えないので、情報共有の方針策定などでは若干難しくなる可能性があります。オンプレミス版のGitLabやGitHub Enterpriseなどを使った場合はプルリクエスト等も使えるようになりますが、コストは大幅に上がります。

最後に

今回のGitHubの障害は比較的長期間となったことで、GitHubを使って開発を行なっている企業やコミュニティーにとってはかなりの不便を強いられる結果となりました。

ただ、データの消失がなかったとのことであるということが幸いであり、最悪の場合データが消失してしまう可能性があるというのを考慮すると、如何にしてバックアップや適切なデータの分散化をするのかが考えなければならないことであるとも考えています。

GitHubは非常に便利なツールである一方で、万一の自体が起こると、それで不便を強いられてしまうので、万一の時に備えて如何にして障害が起きても影響を最小限にするのかということは、今後の開発を進めていく上で重要になっていくんじゃないのかな？と考えています。

案件量が豊富なアルマサーチ

最後に、アルマサーチのご紹介！

アルマサーチはフリーランス向けに案件をご紹介することに特化したエージェントサービスです。豊富な案件量から、安定して継続的な案件のご紹介を実現しており、口コミから登録エンジニアが急増中です。

アルマサーチが選ばれる理由

1. 豊富な案件量。週3?4日の案件や在宅リモート案件も。
2. 優秀なコンサルタント陣。
3. 案件に参画後もしっかりサポート。

豊富な案件量

フリーランス向けに特化し、業界屈指の案件量を誇ります！週3?4日の案件や、在宅リモート案件もありますし、その他あらゆる希望をしっかりお伝えください。最適な案件のご紹介をさせていただきます。

優秀なコンサルタント陣

技術に疎く、開発の希望を伝えても響かないエージェント・・・嫌ですよね。アルマサーチにはそのような者は一切おりません！さらに独立にまつわる税金や保険関係に詳しいスタッフが徹底的にサポートさせていただきます。

案件に参画後もしっかりサポート

常駐先が決まった瞬間に、一度も連絡が取れなくなるエージェント・・・いますよね？アルマサーチでは、そのようなことは一切ありません！常に電話やメールは即対応しますし、月に１度のランチミーティングなどから現場の状況を細かくヒアリングし、就業環境改善に尽力いたします。