最近のブログ投稿で、Twitterは彼らのパブリック・クラウドへのジャーニーを発表した。内部ではPartly Cloudyとして知られているプロジェクトである。ブログ記事は、過去に取り組んだ際に、彼らの障壁となったいくつかの制約について述べられており、またなぜ今がこのトランスフォーメーションに乗り出す良い時期なのかについて説明されている。Twitterは3年以上前に投資を始めたが、実現不可能として考えをとどめていた。最終的に、新しいクラウド製品の活用、より広い地域へ供給できる能力が、クラウド移行の再開を促した。
3年以上前、Twitterが最初にクラウド移行への作業負荷を見積もった際、今は適切なタイミングではなく、Twitterのインフラストラクチャをリフトアンドシフト（訳注：クラウドに上げて、変更すること）も不可能であると判断された。TwitterのシニアソフトウェアマネージャであるJoep Rottinghuis氏は、当時の懸念についてこう述べている：
われわれのインフラストラクチャをクラウドに置くのはシンプルなように聞こえます：リフトアンドシフトするだけでしょう？しかしながら、われわれのデータインフラストラクチャは単独で1兆超のイベントを取り込んでおり、何百というペタバイトを処理し、何ダースものクラスタの上で何十、何千というジョブを毎日実行しているのです - シンプル以外の何物でもないですよね。
Twitterチームは、クラウドに移行するための対象となる、いくつかのユースケースを特定している。しかしながら、他のチームがクラウド移行に注力している間、既存のプロジェクトが凍結するという懸念があった。既存のオンプレミスインフラストラクチャを管理し続けるという決定が下された。
Twitterは既に、自社のデータセンターの管理において費用効果の高いスケールを設置していたが、ハイパースケール・クラウドプロバイダによってリリースされる新しい機会を失っていると感じていた。これらの失われた機会は利用可能性、順応性、拡張性と関連していた。
2018年5月、Hadoopクラスタ用にコールドデータストレージを管理するため、TwitterがGoogleとパートナーシップを締結することがわかる新しいイニシアチブがローンチされた。TwitterのCTOであるParag Agrawal氏は、このユースケースにおけるクラウド利用の原動力について説明した：
[クラウドへの移行で]データプラットフォームに従事しているエンジニアリングチームの経験と生産性を強化できるようになりました。
Twitterは、Hadoopクラスタ用に4つの異なるユースケースを特定している。何十、何千というサーバをまたがって300PB以上のデータをホストするものだ。
- リアルタイムクラスタ。ユーザによって生成されたデータを取り込む
- プロセシングクラスタ。そこで定期的にスケジュールされたジョブが実行される
- アドホッククラスタ。単発のクエリと不定期の分析を行う
- デディケイティッド・デンスストレージクラスタ。クラウドデータを管理する
Twitterチームは、クラウドの性能から最もリスクが小さく、最も利益を上げられる機会を探していた。そしてアドホックと、Google Cloud Platformへのコールドデータユースケースをサポートする双方のクラスタを移行する決定に至った。
Twitterが直面している別の課題は、インフラストラクチャツールの合理化だ。これらのツールは10年以上前、ソフトウェアデプロイメント、モニタリング、セキュリティ、ロギングをサポートするために開発され、必ずしもクラウドを念頭に置いて設計されておらず、新しいクラウドベースのモデルをサポートするために改善を必要としているのである。
Twitterがクラウドジャーニーを練るにあたり、エンジニアリングブログにより詳しい情報をシェアすることを企画している。