CAM TECH BLOG

株式会社CAMのエンジニア・デザイナーの活動を綴るブログです

株式会社CAMの技術ブログです。 エンジニアとデザイナーの活動や組織文化を綴ります。

プロジェクトEFK〜オンプレからAWSへ 前編・推進チーム対談

f:id:cam-engineer:20190204151314p:plain

2018年10月、ある1年がかりのビッグプロジェクトが完了しました。

「 Escape From KAMEIDO(亀戸データセンターからの脱出)」略してEFKと名付けられたこのプロジェクトは、創業以来オンプレミスで構築されてきた CAM の全てのサービスを AWS に移管する、というもの。難易度の高さをなぞらえるかのようなそのタイトルは、次第にチームを鼓舞する合言葉のように呼ばれるようになりました。

しかし、その道のりは決して楽なものではありませんでした。リスク、コスト、モチベーション等、課題の重圧に耐え、先頭に立って旗を振り続けた推進チームには、一体どんな困難と苦悩、工夫と成長があったのでしょうか。

◆ 参加者プロフィール(上記写真の並び順)

根立 宗一郎
(ねだて・そういちろう)

2004年中途入社。公式課金事業・広告事業などを経たのち、基盤チームにJoin。現在は、再び公式課金事業に従事。
神田 裕史
(かんだ・ひろし)

2005年CAM中途入社。広告事業部を経て基盤チームにJoin。埼玉県出身。
野口 大介
(のぐち・だいすけ)

2013年中途入社。サーバサイドエンジニア。基盤チームとしてAWS移管に従事、現在は機械学習関連のプロジェクトに携わる。
庭木 勝也
(にわき・かつや)

2012年新卒入社。インフラエンジニア。サービス移管プロジェクトではDBを担当


ー EFK が始まったきっかけは?

庭木: 直接は、データセンターの機器のサポート期限です。CAM の亀戸データセンターで2010年設立当時から使用しているネットワークスイッチが EOSL を迎えるので、新しい機器を購入してリプレイスする流れだったのですが、ここ数年でクラウドに詳しいエンジニアが増えて、情報量も増えてきていたので、両方のメリット・デメリットをみて、検討しようということになりました。


根立: 検討の結果、クラウドの方が将来的に費用を抑えられて利便性が高いという結論に至りました。ここまでは割とトントンと進みましたね。

f:id:cam-engineer:20190204153529p:plain
▲ コストと利便性の点で合意を得られ、最初はトントンと進んでいったという


庭木: でも、どの事業部からやるか、誰が手を動かすかなど、議論が具体的な内容に至ってからが大変で。当然、どこの事業部も、最初のリスクを取りたがらない

サービスを止めるわけにはいかないので、通常業務と平行の移管作業となると、スケジュール調整も難しい。それに、業務量が増えるエンジニアにとっても、エンジニアの工数を少しでも多く施策に寄せたいビジネス側にも、嬉しい話ではないですから、膠着状態が続きましたね。

でも起点を決めなければプロジェクトは進まないわけで、、、最初の難関はここでしたね。


神田: パートナー企業のサービスを扱っている事業部は、特に慎重にならざるを得ないので、どこも他の部署が成功したのを見てから動きたい、というスタンスでした。

で、長い議論の末、占い事業が先陣を切ることになりました。占いは自社サービスなので、それ以外に比べれば影響範囲が小さい、という判断でした。

それが決まってからは、担当のエンジニアがガツガツ、パワフルに進めてくれて、やっとプロジェクトが走り出した感じがでてきました。


庭木: そこから、推進チームと事業部側のエンジニアとのコミュニケーションは次第に密になり、ミーティングの頻度も当初の月1回から2週間に1回、最後は週に1回になりました。

多くの社員が訪れるカフェスペースで、僕たちが額を突き合わせて話あう姿が頻繁に見られるようになると、動きの鈍かった部署にも『やらないと』という機運が高まってきて、動き出してくれるようになりました。


ー 最初の困難を乗り越えてからの展開は?

庭木: 実は、いきなり出鼻を挫かれる事態となりました。

2つのサービスの WEB サーバー、データベース、決済システム、バッチ等を一気に移管しようとして失敗しまして。。。

すぐに切り戻したので事なきを得たのですが、、、一同、肝を冷やしましたね。まとめてやるリスクの大きさを痛感し、ここから部分移管にシフトしました。

部分移管とは、まずデータベース、次に決済システム、そして WEB というように、段階的に AWS へ移管するという方法です。

ヘタにここで成功しなくてよかったというか、いい教訓になりました。これがあったおかげで、チームにピリッとした緊張感が出て、気持ちが引き締まる結果になりました。

f:id:cam-engineer:20190204153523p:plain
▲ 好調に見えた滑り出しが、いきなり暗転する事態に


神田: ただ、部分移管は細かく移管する分、メンテナンス回数が大幅に増えるというデメリットもあるので、もともとの計画のおよそ3倍、約60回のメンテナンスを行うことになりました。

さらに当初は不慣れで動作確認の段取りが悪く、テストがスムーズに進まない事も多くありました。外部サービスに接続できなかったり、テストを開始するページや手順を決めていなくて、混乱が生じたり。

これも学びとして、2度目以降はテスト方法を資料にまとめ、確認用 URL の QR コードを紙に大きく印刷して張り、デバッガーがすぐにアクセスできるようにするなど、工夫を重ねました。その結果、しだいに効率よくテストができるようになりました。


根立: テスト関連の課題でいうと、移設後にテスト項目が不足していたことが判明したこともありました。なので、推進チームが用意した共通項目以外に、各事業部に特化した項目も用意するようになりました。

テストの項目数自体はそこまで多くはないのですが、フィーチャーフォン・スマートフォン分それぞれ × 各キャリア分のテストを、部分移管のたびに2回(検証環境&本番環境)実施するので、最終的にはかなりのボリュームになりました。


庭木: 基本的に、メンテナンスとメンテナンスの間に、次のメンテナンスの打ち合わせをするという流れだったので、この時期ばかりは、休みも睡眠もないという気持ちでやっていましたね。


ー やってよかったと思うことは?

庭木: 初めてのことだったので、正確な情報を集めるため、AWS の担当者と直接、定期的にミーティングを行いました。

複数のサーバーにまたがるデータベースを、どのように1つや2つのインスタンスに集めるかとか、事業部・サービスごとの細かい要件の相談にも応じてもらいました。他社の事例や、詳細な機能説明が、実に参考になりました。


神田: 影響範囲を狭めるため、データベースはデータベース、課金は課金、といった具合に、部分移設を行った事もよかったですね。

細かく分ける事で、不具合があっても原因究明がしやすかったですし、移管に成功した事業部のやり方やエラー解消法を、後続の事業部に伝達できたため、どんどんスムーズになっていきました。

また、一歩一歩、着実に進んでいるなという実感が感じられたことも、僕はよかったと思います。期間の長いプロジェクトだったので、進歩を感じられる事の精神的メリットは大きかったと思います。


f:id:cam-engineer:20190204153535p:plain
▲ サービスの断捨離も行ったことも大きな成功要因に

野口: EFK をきっかけに、思い切ってサービスの断捨離を行ったことも大きかったです。

古くからある占いやライフスタイル系の事業は、サービスの数が多いだけじゃなく、フィーチャーフォン版サイトも細々ながら稼働していました。

それらも含めた全てを移管対象にするとなると、膨大な時間とコストが必要ですが、事業部の責任者の英断で、将来性や売上規模の点で移管コストに見合わないサービスは、このタイミングでクローズすることになりました。それによって、随分助けられましたね。


神田: 全員が現状把握がしやすいツールを用意したことも、今思えば良かったなと思います。

プロジェクトに関わる人数も多いため、スケジュールや担当の割り振りがかなり複雑になっていました。混乱やミスを避けるために、「これを見れば、誰でも状況が把握できる」ものが必要だと考えました。

それで用意したのが、大判のホワイトボードです。常に見えるところに置いておき、日時とタスク、誰がどのサービスで、何をして、どう進捗しているのかを書き、絶えず更新しました。

f:id:cam-engineer:20190204153541p:plain
▲ ホワイトボード(※ 再現)には、今誰が何をしているかなどが細かく記載された

問題が発生すると、ポストイットに書いて貼り、解決したら外していきました。このホワイトボードの活用で、みんなの認識のズレを防ぐことができました


庭木: プロジェクト認知度を上げるために、社内広報を活用しました。スタートしてしばらくの間は、エンジニア以外からは移管作業の様子が見えづらかったせいか、「本当にやっているの?」という声がでたりしたため、周知不足に気づきました。

そこで技術広報と連携してポスターを作り、 EFK の社内認知キャンペーンを展開しました。

ポスター作戦は有効でした。社内のいたるところに貼り、誰でも必ず目にする状況を作りました。その結果、詳細内容は知らないまでも、ポスターは見たことがある、という状態を作ることができました。

またポスターは、作業が進捗するとコマを進められる、すごろくのような構成にすることで、プロジェクトの進捗状況がわかるようにしました。6つの部門を横軸に、部門それぞれのマイルストーンを縦軸にして、コマは面ファスナーで着脱できるようにしました。

f:id:cam-engineer:20190204161710p:plain
▲ 左が実際のポスター。事業責任者の顔も入れることで、全員が関係者であるというメッセージを込めた

全ての課題をクリアしたら、ポスターと一緒にその部門の担当メンバーの写真に撮って workplace などの社内活性ツールに掲載して、みんなで労い祝うという流れを作り、盛り上げていきました。


根立: マネジャークラスの会議でもこまめに進捗報告をすることで、役員の耳にも届くようにしました。アピールの甲斐あって、少しずつ社内に浸透し、最後は知らない人はいなくなりました。


ー 一方で反省点は?

神田: テストの時に、SIM が入ったテスト端末が足りなくなった事ですね。スマートフォン46台、フィーチャーフォン10台を用意していたのですが、キャリア決済のテストを何度もしていると、あっという間に課金上限に達してしまい、途中で SIM を買いに走ることになりました。。。

その都度中断するのは非効率なので、テスト用端末や SIM、残高のリストはしっかり準備しておくと安心だと思います。

f:id:cam-engineer:20190204153547p:plain
▲ しみじみと当時の反省点を振り返るメンバー


根立: あと今回、先述の通り、移設せずにクローズを決めたサービスがいくつかありましたが、その中でユーザ向けの終了告知を出すべきタイミングを逸してしまったものがあり、結果、終了告知表示の必要日数(※)を満たすためだけの移管作業が発生してしまいました。(※ 通信キャリアのレギュレーションで、終了告知を表示すべき期間が定められています。)

このような無駄が起こらないよう、移設日から逆算して、少なくとも4ヶ月前には動き出すスケジュールを組むべきですね。

その他、外部システムと連携しているものが遮断されて使えなかったり、特定の環境だけで発生するエラーに手こずったり、売却済のサービスがまだ CAM サーバにあることが発覚したり、、。

細かいところを挙げれば、反省点はまだ色々あるのですが、それはまた別の機会にお話ししましょう。

 

プロジェクトを推進する側にとって、「想定外」は常に悩ましいものです。一方で、推進チームのディレクションを受けながら実際の移管作業を進めた事業部側のエンジニアは、どんな経験をしたのでしょうか。後編は、その視点からのインタビューをお届けします。


(技術 / クリエイティブ広報:桑田)

tech.cam-inc.co.jp