数年前、Dropboxがパブリッククラウドの採用をほとんど止めて、
独自のデータセンターを構築することに決めたことは、多くの人々に衝撃を与えた。だが最近、
Atlassianはこれとは逆向きに、ほとんどのデータセンターを閉じてクラウドに移行した。企業たちは、さまざまな理由でこうした選択を行う。
Atlassianの現在のCTOであるSri Viswanathが取締役会に加わったのは2016年だったが、彼は同社の最大のアプリケーションをAWSに移行する決定を下した。
これは部分的には、時間が経つにつれてアプリケーションたちが厄介なコードの層に邪魔されて、更新も保守も行うことが困難になる、技術的負債に関わる話である。2002年に設立されたAtlassianにとって、Viswanathが会社にやって来た2016年が、いわば先延ばしにしていた年貢の納め時だったということだ。
Atlassianは、未来に進むためには、コードを更新する必要があることには既に気がついていた。彼らがViswanathを取締役会に加えた理由の1つが、その仕事の指揮をとって貰うことを狙ってのことだが、そうした仕事の必要性そのものは、彼がやってくる前に十分に認識されていた。2015年には新しいクラウドベースのアプローチに向けたビジョンとアーキテクチャを検討する小さなチームが立ち上げられていたが、その成果を十二分に達成するために、最初のCTOを採用したいと考えたのだ。
マイクロサービスへの移行
彼は計画を実行に移し、内部コードネームVertigoを与えた。おそらく、彼らのソフトウェアスタックの大部分をパブリッククラウドに移行させるという考えは、エンジニアリングチームにとって、想像するだけでもめまいがするようなものだっただろう。このプロジェクトの目標は、その最大の製品であるJiraとConfluenceから始めて、ソフトウェアを再構築することだった、もちろん次の10年を大きな困難なしに支えてくれるような基礎とすることが狙いだ。
写真：WILLIAM WEST/AFP/Getty Images
彼らは2016年の大部分をソフトウェアの書き直しに費やし、それをAWS上に置くことにした。15年に渡って蓄積されてきたコードをマイクロサービスに転換することに注力した結果、最終的にはコードベースも小さなものにすることができた。彼は、技術的負債は大変な問題だったが、車輪の再発明をしないように注意深く行う必要があったと語った。いつでも、本当に変更する必要がある場所だけを変えるようにしていたのだ。
「コードベースは相当な大きさでしたので、作業に際して、私たちは2つのことをしなければなりませんでした。マルチテナントアーキテクチャのために構築したいと思っていましたし、マイクロサービスを提供したいと思っていたのです」と彼は語った。「もし引っ張り出して自己完結型にすることのできるサービスがあれば、そうしたことでしょう。でも私たちは新しいサービスを全体プロセスの一部にしたかったのです」。
運用しながらの顧客移行
移行が行われたのは昨年だった。そしてすべての顧客を残らず新システムに移行させるにはまるまる1年が必要だった。その移行は1月に始まり12月に終了したが、数万の顧客が移行の対象となった。
写真：KTSDesign/Science Photo Library
まず第一に、彼らは可能な限り自動化を行い、移行の順番についても非常に慎重に考慮し、難しく見える移行に関しても注意深く取り扱った。「どのような順番で移行を行うべきかに関しては非常に慎重に考えました。単に最初に簡単なものから始めて最後に難しいものをやろう、とは思っていませんでした。かといって困難なものばかりに取り組んで、進捗があまりないことも望む所ではなかったのです。私たちは（自分たちのアプローチ）を適宜ブレンドし、プロジェクト全体のバグと課題を解決して行かなければなりませんでした」と彼は語った。
Viswanathは、とにかく重要な目標は、顧客を重大な問題を起こすこと無く移行させることだったと述べた。「マイグレーションを行った人と話したことがあるなら、それは大変なことだとわかります。誰もがマイグレーションで多かれ少なかれ傷を負っているのです。これを本当に慎重に行うことを意識していました」。驚くべきことに、それは完璧ではなかったものの、大規模な停止を招くことなく彼らはこの仕事を乗り切ることができた。誇るべき仕事だと言えるだろう。もちろんだからといって、それがずっと順調で簡単だったというわけではない。
「『私たちは注意深く考え移行しました』と聞くと、まるで簡単なように響きますが、実際には毎日が戦争でした。移行する度に、壁にあたり思わぬ反応が起きました。一年を通して、それが私たちにとって日常的な事だったのです」と彼は説明した。エンジニアリング、プロダクト、サポートを含むチーム全体の努力が必要とされた。その努力の一環として、日々のスクラムミーティング（スクラムはアジャイル手法の1つ）にはカスタマーサポートの人間も参加してもらい、顧客が抱えるあらゆる問題に関する感覚を掴み、それを可能な限り迅速に解決できるようにしていた。
彼らが得たもの
どのようなクラウドプロジェクトでも、アプリケーションをクラウドに移行することには、柔軟性、敏捷性、資源弾力性といったものに関わる、一般的なメリットがあるものだが、今回のプロジェクトにはそれ以上のものがあった。
写真： Ade Akinrujomu/Getty Images
まず第一に、マイクロサービスがたっぷり使われているために、複数の配備を同時に迅速に展開することが可能になった。すなわち、新しい機能を格段に早く追加することができるようになったのだ。移行期間の年は、移行のためにできるだけものごとを静的に留めておきたいと考えていたために、ほとんどの新機能の追加は延期されていた。しかし新しいシステムを導入することで、新しい機能の追加をはるかに迅速に行うことができるようになったのだ。
パフォーマンスも大幅に向上した、そしてこの先もしパフォーマンスのボトルネックが発生しても、クラウドであるためリソースをただ追加することができるのだ。さらには、EU内で現地拠点を持つことができるようになり、エンドユーザーに近い場所にアプリケーションを配置することでパフォーマンスが向上した。
最後に、クラウドに移動したすべての企業に当てはまるわけではないが、彼らにとってはクラウドがより経済的な選択肢であることが本当に実証されたのだ。データセンターを閉鎖して、ハードウェアの購入費用や、それを維持するためのIT担当者を雇用することに伴うコストを削減することによって、全体のコストを削減することができた。
人間的側面の管理
これは長期にわたるプロジェクトだったが、彼らはそれと同様に、人間的側面も考える必要に迫られていた。彼らは、技術者が常に新鮮な気持ちでいられるように配置換えを行い、移行支援作業で技術者たちを疲弊させないようにした。
企業文化そのものも役立ったものの1つだ。Viswanathはそれを率直に、オープンなコミュニケーションと、問題を隠し立てしない文化によるものだと説明した。「わたしたちはオープンなコミュニケーションの維持を心がけています。たとえ物事がうまく進んでいないときでもそれは変わりません。もし自分の手に負えなくなったときには、エンジニアは手を挙げて助けを求めます。そうすることで私たちは支援を行うことができるのです」と彼は言う。
彼は同社の中にある種の不安があったことを認めた。彼個人にしてもこの規模のプロジェクトの実施に関しては不安を抱えていた。しかし彼らは組織の未来のためには、これを行う必要があることを理解していたのだ。「もしこのプロジェクトがうまくいかなければどうなるんだ、という緊張は確かにありました。でもその方向は正しいもののように見えましたし、私たちはそれをやらなければならなかったのです。真のリスクは、私たちが遂行に失敗して、あるべき利便性を実現しそこなうことでした」。
結局のところ、それは大変な作業だったが上手く行き、将来のためのシステムを手にすることができた。「次の10年を戦う準備が整いました」と彼は言った。
