|
51CTO読者成長プログラムコミュニティ募集中。お問い合わせはアシスタント（WeChat ID: CTOjishuzhan）までご連絡ください。 ヤン・ジェン著 4ヶ月で16回の中断。Githubはユーザーを本当に怒らせました。 MicrosoftのGitHubは、バージョン管理とコラボレーションのためのコードホスティングプラットフォームを提供しています。過去3ヶ月間で13件の同様のインシデントが発生し、先週だけでも3件のサービス停止が発生しました。 5月16日、GitHubの最高セキュリティ責任者であるマイク・ハンリー氏は、「GitHubにおける最近の可用性問題の解決」と題したブログ記事を公開し、「先週、GitHubは長期のものも短期のものも含め、複数の可用性インシデントを経験しました。その後、これらのインシデントを軽減し、現在すべてのシステムは正常に動作しています」と述べています。 ハンリー氏はさらに、「これらのインシデントの根本原因は互いに関連性がありませんが、全体として、GitHubが提供するサービスに対する組織や開発者の信頼に悪影響を及ぼしました。これは容認できるものではなく、当社の基準にも合致しません」と述べました。 1. 3つの事件の回顧的分析と原因同社によると、5月9日、10日、11日に発生した3件のインシデントは、GitHubが提供する重要なサービスのほとんどに影響を与えました。これらのインシデントにより、以下の重大なGitHubサービス障害が発生しました。 1. 5月9日のGitデータベースインシデント日付: 2023年5月9日 イベント: 構成の変更により Git データベースのパフォーマンスが低下しました 影響: 10 の主要なサービスのうち 8 つがダウングレードされました。 同社によれば、5月9日のインシデントでは、設定変更によりGitHubのデータベースが混乱したという。 ハンリー氏はブログ投稿で、「5月9日にインシデントが発生し、ステータスポータル上の10サービスのうち8サービスに重大な（赤色ステータスの）障害が発生しました。障害のほとんどは1時間強続きました」と述べています。 Gitプッシュエラー率：11:30頃、エラー率はゼロから約30,000に上昇しました。その後、エラー率は25,000から35,000の間で変動を続け、12:30頃には再びゼロに戻りました。 ハンリー氏は、障害発生中、多くのサービスが新たに書き込まれたGitデータを読み込めず、広範囲にわたる障害が発生したと説明した。また、障害発生後、一部のプルリクエストとプッシュイベントの復旧時間が延長されたと付け加えた。 ハンリー氏は、この障害は Git データを提供する内部サービスの構成変更によって発生したと述べた。 この変更は接続の飽和を防ぐために設計されており、Gitバックエンドの他の場所では既に導入済みでした。導入後まもなく、クラスターでフェイルオーバーが発生しました。構成変更を復元し、数分以内にロールバックを試みましたが、内部インフラストラクチャエラーのためロールバックは失敗しました。 2. 5月10日のGitHub App認証トークンインシデント日付: 2023年5月10日 イベント: 負荷の減少により GitHub App 認証トークンの発行が影響を受ける 影響: 10 の主要なサービスのうち 6 つが拒否されました。 5月10日に発生したインシデントは、GitHub のアプリケーション認証トークンの発行能力が低下したことが原因で、10 個の重要な GitHub サービスのうち 6 つに影響を与えました。 ハンリー氏はブログ投稿で、「5月10日、GitHubアプリの認証トークンを提供するデータベースクラスターで、GitHubアプリの権限（ステータスは黄色で表示）の書き込みレイテンシが7倍に増加していることが分かりました。このインシデント発生中のほとんどの期間、これらの認証トークンリクエストの失敗率は8～15%でしたが、短期間で76%に達しました」と述べています。 5月10日、GitHubアプリケーション認証トークンを提供するデータベースクラスタにおいて、GitHubアプリケーション権限（黄色のステータス）の書き込みレイテンシが7倍に増加しました。この期間の大部分において、これらの認証トークンリクエストの失敗率は8～15%でしたが、短期間で76%に達するピークを迎えました。 レイテンシの経時変化を示す折れ線グラフ：5月10日（水）午後12時30分から5月11日（木）午前0時まで、レイテンシはゼロから「3e14」付近まで変動しました。この期間中、ピークレイテンシは「1e15」に近づいた回数が5回ありました。 最高セキュリティ責任者は、トークン発行の問題はGitHubアプリケーションの権限を管理するAPIが「非効率的」だったために発生したと説明し、同社がインストール状況の変化をチェックするためにAPIを更新していると付け加えた。 3. 5月11日のGitデータベースインシデント日付: 2023年5月11日 イベント: 読み取り専用コピーの損失により Git データベースがダウングレードされました 影響: 10 の主要なサービスのうち 8 つがダウングレードされました。 同社は、GitHubのデータベースが5月11日にコピーの読み取り損失により再び攻撃を受けたと述べています。Hanley氏はブログ投稿で、「Gitの読み取りと書き込みは多くのGitHubシナリオの中心となるため、レイテンシの増加と障害により、GitHub Actionsワークフローはデータの取得に失敗したり、更新されていないリクエストを取得したりしました」と述べています。 成功したオペレーションの推移を示す折れ線グラフは、典型的な値として約250万件を示しています。グラフによると、13:30にオペレーション数が約150万件まで減少し、その後着実に増加して250万件に戻り、14:00に正常値に戻っています。 II. これらのイベントが他の GitHub サービスに影響を与えるのはなぜですか?ハンリー氏はブログ記事で、「私たちは、サービスの障害耐性を可能な限り高めたいと考えています。分散システムにおける障害は避けられませんが、複数のサービスに深刻な障害を引き起こすべきではありません。3つのインシデントすべてにおいて、広範囲にわたるパフォーマンス低下が見られました。Gitデータベースのインシデントでは、Gitの読み取りと書き込みは多くのGitHubシナリオの中心となるため、レイテンシの増加と障害により、GitHub Actionsワークフローがデータのプルに失敗したり、プルリクエストが更新されなかったりしました」と述べています。 さらに、GitHub Appsインシデントにおけるトークン発行の影響は、トークンを使用して実行されるGitHub関数にも影響を及ぼしました。これらのトークンは、GitHub Actionsの各GITHUB_TOKENのソースであり、GitHub Codespacesにリポジトリへのアクセスを許可するために使用されます。また、プライベートGitHubページへのアクセスを保護する手段でもあります。トークン発行に失敗すると、GitHub ActionsとGitHub Codespacesは実行に必要なデータにアクセスできなくなり、起動できなくなりました。 III. GitHub は同様のインシデントを防ぐための対策を講じています。ハンリー氏は、今後同様の事件が起きないように、社内のプロセスを慎重に見直して調整し、変更が常により安全に展開されるようにするなど、複数の面で取り組んでいると述べた。 もちろん、これらの事象のすべてが生産上の変更によって引き起こされたわけではありませんが、これは改善が必要な分野だと考えています。 さらに、ハンリー氏は、「通常のインシデント後の分析とレビューに加えて、これらのインシデントがサービスに及ぼす影響の範囲を分析し、将来同様の障害が発生した場合に、どこで影響を軽減できるかを判断しています」と付け加えた。 一方、GitHubは「高コストで低ボリュームのクエリパターン」の観測性を向上させ、こうした問題を迅速に診断・軽減する能力全般を強化することに取り組んでいます。その他の対策としては、データベースフェイルオーバーの問題に対処し、フェイルオーバーによって常に介入なしで完全な復旧が実現されるようにすること、複数のGitデータベースクラッシュイベントを把握することなどが挙げられます。 GitHubの透明性への取り組みの一環として、GitHubサービスのパフォーマンス低下を引き起こしたすべてのイベントの概要を月次可用性レポートで公開します。「最近のこれらのイベントの範囲と期間を考慮すると、コミュニティと協力してこれらの問題を今すぐ解決することが重要であると考えています。」 ハンリー氏は、5 月の可用性レポートにはこれらのイベントとさらなる詳細、および GitHub の可用性向上の進捗状況に関する全般的な最新情報が含まれると述べました。 IV. サービスパフォーマンスの低下イベントが 4 か月間継続して発生しました。GitHub は停止問題の解決に取り組んでいると主張しているが、過去 4 か月間で GitHub は多数の停止を経験しており、4 月に 4 回、3 月に 6 回、2 月に 3 回発生している。 V. ユーザーは激怒しています。あるRedditユーザーは、GitHubの可用性の問題は最近だけでなく、長年続いているものだと述べています。GitHub、あるいはその一部のサービスは頻繁に停止していますが、GitHubがそれらの問題について何も公表していないことに驚いています。「Actionsは頻繁にクラッシュし、Codespacesのダウンタイムが頻繁に発生していることが、私のチームがGitHubを辞める大きな理由です。」また、GitHubのステータスページにおけるイベント履歴の更新にも不満を表明しています。 別のネットユーザーはこう答えた。「あるクラウドプロバイダーがステータスページを変更しない理由は、多くのSLAポイントと顧客への補償が発生するからだ。」 多くのネットユーザーもこの意見に同調している。「コードスペースの問題に遭遇するたびに、ステータス ページにも間違いなく問題は表示されません」「Slack のサードパーティ ステータス チャンネルにスパムが届くので、特定のサービスが頻繁にダウングレードされていることはよくわかっています」「3 月には 20 件のインシデントが発生しました。ほぼ毎日 1 件のインシデントです」 VI. 結論数え切れないほどの良心的なコードを擁するプラットフォームでありコミュニティであるGitHubは、世界中の開発者にとってオープンソースの聖地となっています。しかし、今回のサービス停止は、GitHubの頻繁な「中断」に対するユーザーの不満をかき立てたようです。 ハンリー氏が述べたように、分散システムにおける障害は避けられません。しかし、ユーザーに対して約束した可用性は維持されなければなりません。もしこれが保証できないのであれば、SLA（サービスレベル契約）は空約束となってしまいます。一体何の目的があるのでしょうか？ 参考リンク:https://www.infoworld.com/article/3696279/github-owns-up-to-service-issues-multiple-outages.html https://github.blog/2023-05-16-addressing-githubs-recent-availability-issues/ |
