エンジニアに、新しい取り組みを行う余白を。インフラの開発スピードを向上させた「Wallet Station のAWS移行」
インフキュリオンでは、2022年11月にWallet Station（ウォレットステーション）のインフラをAWSへ移行しました。移行をすることになった背景や、移行に際してインフラチームのエンジニアが行ったこと、移行後にどのような効果・メリットがあったかについて、CTOの長田さんにお話しいただきました。
長田
株式会社インフキュリオン CTO
大学卒業後、2005年よりライブドアにて決済システムの開発、運用に従事。2006年よりビットキャッシュにてプリペイド型電子マネー決済の開発、運用に携わる。2012年からは、ベンチャー企業であるミイルにて写真共有SNSの開発、モバイルアプリ向けAPIの開発を手掛けた。2015年よりフリーランスとして独立し、飲食店予約サービスのバックエンドシステム開発やオフィス向け受付サービスの開発などに従事。2016年7月ネストエッグに取締役CTOとして入社、2021年12月インフキュリオンCTOに就任し兼務する。
※この記事は2023/10/26に公開されたものです。
※所属や業務などは取材時点の内容です。
Wallet Stationではプロジェクトごとにインフラ構築・運用を担う
─ インフラチームはどのような組織ですか。
Wallet Stationというプロダクトをメインで扱うEmbedded Fintech事業部に所属する形で、インフラチームは6名のメンバーと2名のマネジャーで構成されています（2023年10月25日時点）。Wallet Stationは導入先や機能開発などの単位でプロジェクト化されており、そのメンバーの中から各プロジェクトへ担当者をアサインする体制をとっています。
メンバーの出身業界はさまざまですが、SIer出身の方、証券会社や保険会社の情報システム部門やグループの開発会社に在籍していた方が多いですね。メンバーのほとんどは30歳前後です。クラウドについて経験の多少は人によって異なりますが、前職の業務で使っていた方や、個人で勉強して資格取得のために勉強して、その過程でAWSを使った経験がある方たちです。
─ 日常的にどのような業務をされているのでしょうか。
クライアントのWallet Station導入が決まるとプロジェクトが組成されます。その中で、インフラチームの業務は、サービスリリースに向けた「構築」とリリース後の「運用」に大きく分かれます。また構築の中でも、開発が始まる序盤、構築を実際に行う中盤、リリースの手前の終盤で業務内容は大きく違ってきます。
プロジェクトの序盤では、要件定義にインフラチームからも担当者が参加し、主に非機能要件について開発チームと共に取りまとめていきます。
要件がまとまると、構築を実際に行う中盤フェーズに移ります。Teraformを使ったコード作成やテストを行ったり、ドキュメントをつくりながら構築作業を行っていきます。アプリケーションの要件が既存のプロジェクトと異なり、インフラに対しても何か変更を施さなくてはならない場合は、開発チームにヒアリングしつつ新たにその部分を構築していくこともあります。
終盤は、テストが中心です。インフラ担当は、主に性能面のテストや、セキュリティ観点でのテストを担当します。
リリース後、運用フェーズに入ると、ログのアラート対応などを行います。安定運用に入ってしまえば、アラート対応もそう頻繁にあるわけではないので、次の新しいプロジェクトにアサインされたり、または新しいサービスやツールに関しての情報収集などを行います。
─ 常に複数のプロジェクトが走っているのですか。
多い時で3〜4のプロジェクトが同時進行しています。基本的に1人のエンジニアが構築・運用の両方を担当しますが、構築に比重を置いている人もいれば運用を中心に担当している人もいて、必ずしも均等になっているわけではありません。
時期によっても比重が変わってきますが、ある時期に構築フェーズのプロジェクトが極端に集中するようなことはないため、メンバーのリソースについては効率よく回っているかと思います。
AWS移行を決断した背景と移行プロジェクトの一部始終
─ ここからはAWSへの移行プロジェクトについてお聞きします。移行はいつ頃から、どのような経緯で考え始めたのでしょうか。
2022年1月頃でしたから、私がCTOに就任したすぐ後です。移行したのは同年11月なので、約10カ月のプロジェクトでした。ただ移行といっても、すでに動いているプロジェクトを移行したわけではなく、2022年11月に新規リリースしたプロジェクトからAWSを使うようになった、というのが正確なところです。
AWSへの移行を考えた理由はいくつかあるのですが、インフラチームのエンジニアから移行したいという希望があったことが大きかったと思います。AWSの技術を習得している人や、これからスキルを伸ばしていきたいと考えるエンジニアから、AWSを実務で使う経験を積みたいという強い希望がありました。背景には、既存インフラのメンテナンス対応などで業務負担が大きくなっていたこともありました。
あとは、コスト面の理由です。ライセンス製品を使っていくと、今後サービスが拡大した場合、インフラの費用を回収できないのではという懸念がありました。効率よくインフラをつくっていく必要があるだろうということで、オープンソースの技術を幅広くサポートするAWSへの移行を検討し始めました。
─ 検討から移行まで、どのように進めていったのでしょうか。
検討フェーズでは、はじめにAWS上で実際にWallet Stationを動作させられるのか、そのためにどういったサービスを導入する必要があるのかを調べながら、メンバーが中心になってフィージビリティの確認を行いました。
並行して、これまでのシステムでは対応できていた要件が、AWSに移行した場合にも問題なく対応できるのかという観点でポイントを洗い出し、確認しました。
例えば、Wallet Stationのサービス開始当時にAWSを選ばなかった理由の1つに、DR（Disaster Recovery）の観点での問題がありました。国内データセンターで複数のリージョン構成が取れることが要件としてあるのですが、我々がWallet Stationを開発し始めた2018年当時、AWSには東京リージョンしか存在しなかったのです。しかし、2021年3月に大阪リージョンがローンチしたためこの問題はクリアできるようになりました。
また、我々は基本的にFISC安全対策基準に準拠する形で運用できるようにしていますが、2018年当時はデータセンターへ立ち入り監査ができる体制が必要だとされていたため、立ち入り監査ができないAWSを採用できなかったのです。しかし2022年の時点では、FISC安全対策基準の方がより柔軟にクラウドのプラットフォームを活用できる形に変更されたため、AWSが基準を満たしていると考えました。
その他にも、コスト面で移行するメリットが本当にあるのか試算を出したり、開発スピードがどれくらい上がるか、AWSへ移行することで効率のよい構築や開発が進められるのかという観点でも検証したりしました。
AWSに移行して問題なさそうだと確認できた後は、実際にアプリケーションの開発・検証ができるような環境の構築を行いました。これに関しては、コンテナを利用していたこともあり、そこまで大きな工数はかけずに対応することができました。
ただ、ストレージサービスに関しては移行に伴ってアプリケーションの方に改修作業が必要で、比較的大変でしたが、インフラとアプリケーション開発の担当者が一緒になって対応に当たり問題なく移行できました。
開発スピードが上がり新しいことに取り組む余白ができた
─ AWSに移行してみて、どのようなメリットがありましたか。
まず、当初期待していた以上に、開発スピードが格段に上がりました。
AWSが出す公式なドキュメント以外に、AWSのユーザーが、いろいろなAWSのマネージドサービスの構築手順などをWeb上で公開してくださっています。これまでは隅々まで自分たちで検証していましたが、公開されている事例やノウハウを活用することで、効率よく開発を進められるようになりました。
そして、時間に余裕ができたぶん、新しいことにチャレンジできるようになったことは最大の利点でした。これまでアラート検知の仕組みなどは外部のサービスを利用していましたが、AWS移行後は自分たちで同様の仕組みを構築して、コストを削減できた事例も出てきました。そのような取り組みに時間を使えるようになったことは、メンバーにとってもよい体験になっていると思います。
それ以外に、人材採用の面でもメリットがありました。今後AWSをメインで利用していくため、採用条件を「AWS経験者」にシフトしたのですが、対象となる求職者の数がそれまでの約3倍になったのです。アプローチできる層が広がったことで、採用が進めやすくなりました。
─ 移行する理由の1つにコスト削減がありましたが、実際移行してみていかがですか。
移行前後では載せているアプリケーションも違いますし、それまで外部のサービスを使っていた機能を、AWSのマネージドサービスに置き換えたケースもあって単純に比較することは難しいのですが、コストを下げて運用できていることは事実です。
セキュリティのさらなる強化と運用体制の改善が課題
─ インフラチームが今後取り組んでいこうとしている課題がありましたら教えてください。
まず、プロジェクト増加に伴うメンバーの拡充が組織的な課題です。
取り組むべき大きなテーマとして、セキュリティのさらなる強化があります。AWSに移行し、基本的な構築・運用業務については整理が進んできました。よりセキュアなプロダクトの環境をつくっていくためにどういうサービスを導入するのがよいのかなど、我々インフラチームとしての知見を強化していきたいと考えています。
もう1つ、構築・運用をどのように分担していくのかチーム体制の整備・改善も今後の課題だと認識しています。
現状ではプロジェクトの構築フェーズ終盤で、担当者への負荷が短期的に高まってしまうことがあります。また運用に関しては、構築にアサインされた担当者が運用開始後もそのままそのプロジェクトを担当し、アラートなどに対応している状況です。
インフラチーム、それからアプリケーションの開発チームも含めた24/365の対応を無理なくできる体制づくりに向けて、1つのプロジェクトに複数インフラ担当者を付けることをすでに始めています。また、何か起きた時に担当者以外がサポートできるよう、ドキュメント整備や情報共有の体制をつくっていく動きは、今まさに進めているところです。
1人のエンジニアに頼り切りになるのではなく、チームとしてサポートできる環境を早期につくる意味でも、インフラチームのメンバーの拡充は優先的な課題だと考えています。
─ セキュリティ強化のお話がありましたが、これから入られる方に期待することはありますか。
先進的な取り組みをされている企業で経験を積んできた方、知識を蓄えてきた方にジョインしていただいて知見を共有していただいたり、既存のメンバーと一緒に、環境をいち早く構築していただけると非常にありがたいです。
一般的なWebサービスをやってきた方からすると「普通そこまでやらないだろう」というレベルのセキュアな運用をしていると思いますので、我々のようなミッションクリティカルなサービスを提供するインフラを経験する価値はあると思います。
─ どんな方と一緒に働きたいと思いますか。
自律的にチームに関わっていただける方を歓迎したいですね。
情報共有されたら積極的にキャッチアップする。自分のプロジェクトで何かトピックスがあればチームへ展開する。プロジェクトの担当者が募集されていたら手を挙げる。あるいは学習の面でも、新しいサービスを取り入れる提案をしてほしいですし、何事も率先してくれるような方にチームに入っていただきたいです。