CAM TECH BLOG

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

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

プロジェクトEFK〜オンプレからAWSへ 後編・事業部メンバ対談

f:id:cam-engineer:20190206161435p:plain シーエー・モバイル(以降、CAM)で2018年10月に完結した1年がかりのAWS移管プロジェクト「EFK」( Escape From KAMEIDO〜亀戸データセンターからの脱出〜)。

前編記事では、旗振り役となったプロジェクト推進チームに話を伺いましたが、後編では、実働部隊、中でも特に難易度の高いサービスの移管作業に携わった事業部側のエンジニア2名を取材しました。

◆ 対談メンバープロフィール(上記写真の並び順)

馬 賽
(ま・さい)

クライアントビジネス担当(※ 当時)。サーバサイドエンジニア。
藤井 拓大
(ふじい・たくひろ)

占いビジネス担当。サーバサイドエンジニア。


ー 担当の事業部固有の事前課題はありましたか?

藤井: 僕が所属する占いの事業部は、CAMの中でも歴史が長いため、とにかくサービス数が多く、フィーチャーフォンサイトも今だに相当数ありました。そのため、移管完了までの作業工数が、概算の見積の時点で既に他の事業部の2〜8倍にのぼりました。

事業責任者と相談したところ、サービスの将来性を鑑みて移管コストに見合わないと思われるフィーチャーフォンサイトは、このタイミングに思い切って閉鎖しようということになりました。この英断にはだいぶ救われました。

馬: 僕の担当したクライアントサービスでは、パートナー企業の意向もあるので、CAMの都合だけを優先するわけにはいきません。一つ一つの方針を決めるのに、きちんと説明を尽くさなければならないため、作業が始まるまでのステップにそれなりの時間を割きました。

動きのないフィーチャーフォンサイトであっても、ユーザーが1人でもいたら、閉鎖はできません。占い等の自社ビジネスだったら、閉鎖ジャッジの可能性もありますが、クライアントサービスでは、効果・効率だけが正ではないからです。

普段から求められるクオリティレベルがとても髙いのですが、今回も同様でミスやバグは一切許されない状況でした。それこそ銀行システムレベルです。そのプレッシャーは大きかったですね。

f:id:cam-engineer:20190206161439p:plain
▲ 膨大なサイト数、説明の難しさ、要求クオリティの高さ…行く手を阻む要素がいっぱい


ー 厳しい条件の元のスタートだったのですね。

藤井: 個人的には、各サイトのディレクターへの説明でも苦戦しました。AWS 移管にかかるインフラのコストや、メンテナンスでサイトを停止する時間など、デメリットについては、なかなか理解を得られなくて

微に入り細に入り説明を試みたのですが、分からない単語の量が増えるせいか、余計に難しく感じさせる結果になり。。。なので「ともかく、大丈夫ですよ!」と元気いっぱいに励まして、僕ら技術者を信頼してもらうことでクリアしました。

f:id:cam-engineer:20190206161424p:plain
▲ 非技術者に、技術の話を理解してもらうことの難しさを痛感

馬: そうなんですよね、僕らのとこでも、内部の人間への説明はけっこうなハードルでした。

パートナー企業との対話は、基本的にディレクターが行うルールなので、この移管に関しても同様だったのですが、そのディレクターに理解してもらうのに、5回は同じ説明をした気がします(笑)。

クラウドサーバーの安定性やメリット、今後の拡張性とか、デメリット含めてもなおプラスがあることを丁寧にお伝えしたつもりなのですが「でも、、、、今のままでも動くんでしょ?」と。まあ、そうなんですけど。。。

切り口を業界のトレンドだったりCAM全体の方針であるといった内容に変えて、あとはこちらも信頼で任せてもらう感じでしたね。


ー 作業フェーズに入ってからはいかがでしたか?

藤井: 前編でも言及がありますが)僕たちが全てのサービスの先陣を切って、最初の移管作業をしました。そして、いきなり失敗しました。大慌てで切り戻しましたが、あの時は焦りましたね。

でも、それがきっかけでディレクター陣がより協力的になってくれたのと、やっちゃいけないことの知見が溜まって他部所に展開できたので、結果的には良かったのかもしれません。

馬: 藤井さんたちの失敗のおかげで、意識が変わりました。より慎重に考えるようになり、もしかしたら担当するサービスの全部を移行するのは不可能なのでは、という不安がよぎりました。

というのも、僕らが携わっていたサービスも相当歴史が長くて、できた当初から今に至るまでの全像や仕様を知っている技術者が誰もいなかったんです。

蓋を開けてみると、想像以上に驚くことがいっぱいで。

例えば、メンテナンス画面がなかったこと。24時間365日稼働を標榜し、メンテナンスは一切しないというスタンスで運用されてきたので、なくて当然なのですが。

初めてのメンテナンス画面を表示をさせる意味や意義を、パートナー企業に説明して、ユーザーに対するデメリットを最小限にとどめるために、アクセスが比較的少ない深夜に移管作業を行う、ということで合意を取りつけることができました。

f:id:cam-engineer:20190206161429p:plain
▲ 開けてみたら、想定以上の難易度に驚く

また作業の時間帯は決まったものの、日程が決まるのが作業日直前になることが多く、体制を組むのにかなり苦労しました。

あと、見た目は似ている4つのサービスが、全て異なるシステム構成だったのも想定外でした。最初に1つ移管して、それを他のサービスに横展開する、という当初の楽観的プランが、脆くも崩れていきました。

7回行ったメンテナンスのうち2回は失敗でした。移管作業担当のエンジニアだけでは全く人手不足で、膨大な検証項目がこなしきれませんでした。

外部の検証会社に委託し、最終的にはなんとかなったのですが、その分、想定外のコストがかかりました。非エンジニアでも、検証作業はできるのだから、もっとビジネスサイドの人を巻き込むべきだった、と振り返り感じます。

他にも、あれこれ、色々ありましたね。我ながらよくやったとな思います。

藤井: やればできる!と(笑)。


ー 数々の失敗から、どのようなことを学び、リカバリしていったのでしょう?

馬: 検証の部分でつまずいたので、検証を効率化するために、プロキシサーバーをたてて、本番環境とほぼ同じ環境を整備しました。さらにタイムスケジュールを厳密化して、作業はみんな揃って一斉にやるようにしました。

藤井: 僕らも、開発環境で移行して本番化するというやり方から、準本番環境の向き先を変えるだけのやり方に変えたところ、失敗しなくなりました。

馬: ホワイトボードを活用したことで作業効率化が進みました。

それぞれのサービスで3つのキャリア別決済、クレジットカード、Webマネー決済などの支払い方法の種別があり、ユーザーの状態も会員・非会員状態で全て条件が異なるため、検証項目が多いだけではなく、一つ一つをしっかりチェックしなければ、後で大きなトラブルに繋がります。

f:id:cam-engineer:20190206161431p:plain
▲ 先発隊の知見を共有できたことで、かなり作業が効率化された

データベース、課金関連機能など、段階を切り分けて移管するので、検証にはとても時間がかかります。

なので、作業が始まってから何かを探したり調べたりせずに済むよう、ホワイトボードにチェック項目やテストページのQRや担当者などを掲出し、必要な情報がいつでも見られてアップデートしやすい状態にしました。

また、事前準備は入念に行い、何が正しいのか、という共通認識をみんなで持つようにしました。仕様を把握しておくことで迷うことが少なくなり、もし仮に迷っても、ジャッジが速くなりました。

そうしていくうちに、みんな慣れて検証作業が速くなりましたね。

藤井: 慣れは大事ですね。うち(社内サービス)も慣れる前と後では、テストにかかる時間は倍くらい違いましたから。

 

ー 振り返ってみて、やって良かったことは?

馬: ゴールを明確にしたことでしょうか。全員の目線を揃えることができたと思います。

それと、移管と直接関係はないのですが、移管に伴う運営フローの変化に対応するため、効率化ツールも作りました

管理画面を改修し、運営担当が全ての作業を、社内サーバーにアクセスすることなく、ブラウザ経由でできるようにしました。これにより、エンジニアが不在の深夜の時間帯でも、24時間運用が可能になりました。

移管作業にプラスして、これまで以上に仕事しやすい環境にできたことは良かったと思います。

藤井: 移管作業を通じて、旧いサービスの構成を知り、整えられたのは大きな収穫だったと思います。

ミドルウエアのバージョンが違ったり、サイトによって構成が特殊だったり、バラバラでしたが、今回、大まかな構成は共通化できました。

f:id:cam-engineer:20190206161445p:plain
▲ 大変だったが、結果的にはやって良かったというのが2人の率直な感想

馬: サイトごとの特殊性をなくして共通化が進んだことで、部署間のエンジニアの異動や、新しいエンジニアの配置もスムーズになるのではないかと期待しています。

藤井: サービス単体でも、開発がしやすくなるなどのメリットがあると思います。

エンタメ系サービスだと、イベントに合わせてサーバを増減したいというニーズがありますが、今後はそれに応えやすく、利便性がアップすると思います。

もちろん、不都合な点が皆無というわけではないですが、技術的な水準が上がったことが、個人的には一番大きかったと感じています。


一筋縄では行かなかった AWS 移管ですが、全体的な技術水準が上がり、レガシーシステムが多い CAM のサービスの構成がおおまかに統一できたことが、大きな収穫となったようです。


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

tech.cam-inc.co.jp