今回はココネのインフラに迫る。ココネでは従来のオンプレミス環境とクラウド環境が混在している。どのように使い分けているのか、またクラウドへのリフト&シフトをどのように進めたのか、インフラ室の尹姓元氏と中野大介氏にお伺いした。
――自己紹介をお願いします。
尹姓元
中野大介
――ココネにおけるインフラ環境の変遷について教えてください。
尹 かつてココネではオンプレ環境がメインでした。規模が大きく安定したサービスなら、オンプレ環境のほうが同規模のクラウドと比較して費用が抑えられ、オンプレのままでもよかったからです。しかしオンプレは、特に初期費用がかかり、運用工数もかかります。柔軟にサーバの追加やスペックの変更ができないのも難点となります。
中野 2017年ごろから、新しくリリースするサービスにはオンプレ環境よりクラウドを使うようになりました。日本向けサービスではAWSを選ぶことが多かったものの、グローバル展開するならGoogle Cloudが検証では有利でしたので、グローバルを視野に入れたサービスではGoogle Cloudを選ぶ傾向にありました。のちにAWSではGlobal Acceleratorが加わるなど、どのクラウドでもグローバルで稼働させるための改善が進みました。
尹 AWSとGoogle Cloudの両方を使うのは、いずれかのクラウドベンダーだけに頼らないようにするという意味もありました。
大規模なオンプレ環境をクラウドにリフト
――オンプレからクラウドに移行したシステムはありますか?
尹 ココネ本体ではなくグループ会社となりますが、新たなサービスの運用環境を1年半ほどかけてクラウドに移行した事例があります。大きな目的としては運用体制とコスト面の課題を解決するためです。サーバは数百台もあり、かなりの規模でしたので2段階に分けて進めました。何度も現地に出張したのを覚えています。
中野 1段階目はWebサーバとアプリケーションサーバをクラウドに移行し、データベースサーバは
尹 2段階目はオンプレに残ったOracle DatabaseをAmazon RDS for Oracleに移行しました。時間をかけてデータベースの中身を解析し、慎重に移行しました。長く続いているサービスでしたので、がらりと中身を一新すると開発側で工数が必要になりますし、時間もかかります。選択と集中でした。結果的にデータベースが整理され、全体のコストも半分に抑えることができました。またグループ会社にインフラ組織を結成することも行いました。
――苦労したところは?
中野 移行1段階目のハイブリッド状態において、専用線で接続していたにもかかわらず、オンプレに比べると遅延が多めに生じていました。それがシステムの許容範囲を超えていたため、タイムアウトになるなどの不具合が発生してしまいました。
尹 解析を進めていく中で、データベースを扱うロジックで詰めの甘いところが見つかりました。オンプレなら高スペックで、多少無駄があっても問題にならなかったのです。その後、遅延を少なくするようにデータベースからの呼び出し回数を減らしたり、タイムアウトまでの時間を延ばすなどの対応をすることで、問題を解消することができました。
中野 やはり同じ設備内で稼働させるオンプレに比べると、クラウドでは同じアベイラビリティゾーンでも距離がありますから、多少のレイテンシが生じてしまうことがあります。
尹 この件に対応したメンバーは、ココネの社内表彰制度で表彰されました。一般的にインフラは
開発チームとの境界線をあいまいにしたい
――現在のインフラ室の体制は?
中野 私が入社した当時は3人でしたが、今は8人です。かつては社内ヘルプデスク的な業務も兼ねていましたが、それは総務部に移管しました。一方、新たにセキュリティチームを結成し、私はセキュリティチームも兼任しています。
尹 かつては開発側からインフラに
中野 両者が一緒に設計を進めることで、開発チームがサーバ構成を理解できるといいですし、逆にインフラチームもパフォーマンスチューニングをするにはある程度アプリケーションのしくみや動きを理解しておくことが重要だと考えています。
――セキュリティチームはどのようなことを?
尹 これまでも個々でセキュリティ対策はしていましたが、ココネの組織も大きくなりましたし、Web3の仮想通貨やブロックチェーンも扱うようになりましたので、あらためてセキュリティ組織を新設することになりました。
中野 社内のセキュリティ意識強化から始まり、脆弱性診断の体制強化などを通して、よりDevSecOpsに近づけるようにと活動しています。
次回はココネのインフラの特徴について深掘りする