Slackはスピードと信頼性を両立したソフトウェア開発をどのように実現しているのか？

ITサービスを取り巻く環境が刻一刻と変化する中で、ソフトウェア開発のスピードと信頼性の両立は開発現場で重要視されるポイントのひとつです。チームコミュニケーションツール「Slack」のエンジニアであるJonathan Chang氏とMichael Deng氏が、自社でソフトウェア開発を行う流れをSlackのブログで解説しています。

Deploys at Slack - Several People Are Coding
https://slack.engineering/deploys-at-slack-cd0d28c61701

SlackではGitを利用した開発を行っており、社内でのコードレビューやテストを通過すると、開発者はプルリクエストをmasterブランチにマージできるようになります。masterブランチの開発環境へのデプロイは、予期せぬ問題に対応できるよう、北アメリカにある拠点の営業時間内に行われます。デプロイは毎日12回行われ、それぞれのデプロイに対して責任者が割り当てられているとのこと。デプロイを細分化しているのは、エラーの影響を最小限に抑えるためだそうです。

Slackがソフトウェアの新しいビルドをリリースする際は、まずGit上でreleaseブランチを作成します。releaseブランチはリリースの履歴をタグ付けするために必要なもので、本番環境へのロールアウト中に見つかった問題を修正するポイントになります。releaseブランチでの作業が終わったら、非公開のテスト環境に新しいビルドをデプロイし、テストを実施。テストを通過したビルドは社内の従業員によって試用され、問題がなければSlack全体の利用者のうち2％を占める早期リリース環境へデプロイされます。そこで安定した動作が確認できたら、全利用者のうち10％、25％、50％、75％、100％と、段階的に新しいビルドを公開していく仕組みになっているとエンジニアは語っています。

デプロイで問題が生じた場合は、各デプロイの責任者が対応を指示するとのこと。なるべく早期に問題の原因であるプルリクエストを発見し、問題箇所を修正して新しいビルドを作成しますが、本番環境にデプロイした後で問題が発生した場合は、以前のビルドにロールバックするそうです。

こうした開発フローを確立するまでに、数多くの試行錯誤があったとのこと。Slack自体が現在よりもはるかに小規模だった時代は、Amazon AWSの10インスタンスでサービスを運用しており、rsyncによって全サーバーを同期するシステムでした。開発フローはテスト環境でのテストを通過したら本番環境に即デプロイするというシンプルなもので、開発者からサーバーへ自由に自身のコードをデプロイすることができたそうです。

しかし、Slackのサービス規模拡大により開発が加速するにつれて、開発者が各サーバーへ働きかけてコードをデプロイし、全サーバーをrsyncで同期する方法は限界に到達。そこで、各サーバーがConsulのキーを監視し、キーの変更通知を受け取ったサーバーがAmazon S3に対してデプロイを要求する方式に変更したとのこと。この変更により、サービス規模拡大による開発の加速に対応することができたそうです。

現在のデプロイ体制を支えるもうひとつのプロジェクトが「アトミックデプロイ」であるとのこと。アトミックデプロイを採用する前は、稼働中の本番環境へ直接デプロイを行っていたため、新しい関数よりも先にその関数を呼び出すための記述が適用されてしまい、エラーが発生したりウェブページが壊れてしまったりすることがあったそうです。アトミックデプロイでは稼働中のバージョンであるホットディレクトリと、稼働していないコールドディレクトリを用意し、新しいバージョンをコールドディレクトリに適用して、ホットディレクトリとコールドディレクトリを置き換えることで、エラーを発生させずに新バージョンをデプロイすることができるようになったと述べられています。

Chang氏とDeng氏は「私たちは開発システムをよりよいツールと自動化によって改善し続けていきます」とコメントしています。