オンプレからクラウドへの移行の2年半の軌跡 - エス・エム・エスエンジニアテックブログ

技術推進グループの窪です。 SMSでは主にインフラ全般を見ていますが、主な領域はユーザーサービス側のインフラを担当しています。

入社したのは2017年で、当時と比べるとSMSのインフラは大きく変化してきました。入社当時はオンプレでしたが約2年半でクラウドに移行し、開発者それぞれがクラウド環境を利用でき、シームレスにログインできるようになりました。その変遷をご紹介させていただきたいと思います。

入社時はオンプレがメイン

入社した頃はまだオンプレでサービスを運用しており、SMSの中でも介護事業者向けに提供しているカイポケが開発側もインフラ側も課題が大きかったためクラウドに移行する事が急ピッチで進められている印象でした。

当時、私を除いて4名のインフラエンジニアがオンプレを日々運用しており、サーバーやアプライアンスのハードウェアの運用、ネットワークの運用、事業部からくる依頼や調査、オンプレリソースの切り出し、コスト管理などの運用で手一杯で、スキルの継承も難しく属人化が進んでいるように見えました。

私もネットワーク機器やアプライアンスをオペレーションできるスキルがなかったので、インフラを構築してもらいたい時はインフラエンジニアに依頼して待つという状態でした。

このような事もあり全社的にクラウド環境への移行を計画しました。

オンプレからAWSへ移行

クラウドへの移行を進めるにあたり「運用の効率化による持続可能なインフラ体制」を目的とし、以下の方針で進めることとしました。

オンプレの構成を極力変更せずにAWSに移行する。移行後に課題がある部分を改修し、極力クラウドネイティブな形とする。既存以外の新規は全てクラウド上で構築し、構築するものはIaCを用いること。

オンプレをそのまま移行するのは「えっ？」と感じる方も多いと思いますが、SMSではとにかく高い頻度でサービスが作られるため課題を先に改修しても、事業が継続しない可能性もあるためクラウドに移すことでの運用負荷を下げる事に注力しました。

移行先は、オンプレで利用していたVMをインポートできる事や、AWSに慣れているメンバーもいたためAWSにしました。移行の進め方としてはシンプルですが、環境やこれまでのやり方を大きく変えると技術以外の問題も発生しました。

特に課題として大きかったのは関係者の調整が多岐にわたった事と費用面の複雑さでした。当時SMSは外部の委託が多かったため、結合しているシステムでは、社員にわからないことが増えていく負のスパイラルに陥る可能性のある中で進めていくこととなり、移行が完了するまでに2年半近くの時間がかかりました。

AWS移行時の失敗

AWSに移行する際に１つ大きな失敗をした事があります。

SMS全体のインフラを俯瞰した際にカイポケが最も巨大で、それ以外は比較的小規模なインフラ構成でサーバー要件も複雑ではなさそうでした。オンプレでは集約率がコストパフォーマンスに影響し、減価償却の分母も大きくなると各事業部の負担も小さくなります。そのため、SMSも小規模なサービスで似た要件のものは同一サーバーに集約していたのだと思います。後ろ向きな姿勢ではありますが、ブラックボックスが多い中極力変更を加えずにインフラを移行を完了したい事もあり同様の方法で集約して運用するやり方で移行を進めました。具体的には、１つのAWSアカウントにサービスを集約し、それぞれのインスタンスにリソースタグを付け、インフラの集中管理とコスト効率化を維持させようと考えていました。

しかし、このやり方は実際に多くの問題を発生させました。

AWSは従量課金となり、オンプレのように減価償却で定率のコストではないためサービス単位で費用を分割した際に「A事業部はそこまでつかっていないのにコストが高い」などの公平性とコストが不透明になり事業部が正確なコストを把握しづらくなった事。
リソースタグに対応してないサービスがあり、その費用の分配に関する社内手続きが複雑になり請求処理などのコストが大きくなってしまった事。
権限を厳密にしようとすると権限管理が複雑になりポリシーの上限に達するなど、AWSの制約と運用コストが増えた事。

すぐに、この方式は止めることにしましたが既に移行してしまったサービスもあり是正するのに3年近くかかることとなりました…

後述するAWSのベストプラクティスを無視した構成であった事も原因の１つですが、事業を運営する上で必要な情報や経理などが必要とする情報をスムーズに提供できるかという観点も抜けていたので、構成や運用を１から検討することにしました。

改善されたSMSのAWS構成

現在SMSは全サービスをクラウド上で運用しており、100以上のAWSアカウントをSSOなどを利用して効率的に管理できるようになり、開発により集中できる環境を提供できているのではないかと思います。

構成

AWSのベストプラクティスにもあるのですが、環境ごとにAWSアカウントを作ることが推奨されています。 SMSでは多数のサービスがあるため、最大でサービスの数 * 環境数(Dev,Stg,Prod)となり110アカウントほど現在はあります。この方式ではAWSアカウントが増えると運用コストも線形に増加しやすい事や、小規模なサービスではオーバースペック気味になるというデメリットもあるのですが、サービス単位で疎結合になりやすい事とインフラの見通しがよくなることで改善に取り掛かりやすくなります。

アカウント運用については、現在はAWS SSOが提供されており運用コストが低くなる構成が作れるのではないかと思います。 SMSは社内でoneloginを利用していたのでoneloginと連携する事で入退社と同時にAWSアカウントへのアクセス制御され、インフラは権限の管理だけに集中する事ができるようになりました。アカウント管理でインフラ側でやることは「誰を」「どの権限」でログインさせるかだけに注意するのみです。

LPやHTMLのみの簡易的なサービスに関してはAWSアカウント単位で分離すると逆に運用の手間が大きくなるため同一VPC内でもサイト間の通信はプライベート通信を使わない事やVPC Peerをさせない事で通信レベルは疎結合を保ち、もしそのサイトが大きくなっても個別にAWSアカウントを作れば移設が容易な構成にしました。

共通リソースの提供

前述の通り、SMSではサービスが高い頻度で作られます。そのため共通で利用するリソースをManageと言われる共通リソースだけを提供するAWSアカウントを用意し、VPC Peerで接続するだけで提供できる形にしています。 Manageの役割は主に踏み台、メールサーバー、ログ収集、監視、監査です。

特に監査はアカウント数が多くなると、監査自体が困難になってしまうのでAWS Config、GuardDutyで全体のガバナンスを保てるようにし、違反があればSlackに通知されます。こうすることで基本的なAWS利用ルールはあるのですが、いつでも気付けるようにすることで制限なしでAWSを利用できるようにしています。

AWS移行を終えて

AWSに移行して運用負担が大きく効率化されたのはもちろんですが、最大のメリットは属人化する要素が少なくなったことと、インフラの透明性が高くなった事で個人への権限の分配がしやすくなったと考えています。まだ試験段階ですが全エンジニアにAWSのサンドボックス環境を個別に提供もできるようになってきました。

オンプレやアプライアンスがあるとどうしても特定の人にスキルが偏ってしまい、スキルの継承もその人のやる気次第となり組織としては常にアンコントローラブルな要素を持つことになり、持続させることが難しくなります。

オンプレと比べると今は複雑さが少ないコスト体系なのでインフラ以外の人もコスト意識を持つことができ、IaCで管理すれば再現性も担保される状態にあるので当初目標にしていた「運用の効率化による持続可能なインフラ体制」に近づけているのではないかと思います。

おわりに

こうして4年近くかけてAWS移行から定着へと進めてきましたが、実際には個別の運用や対応が続いていたり、レガシーシステムをクラウドネイティブに持っていきたいけど工数面などで進んでいなかったり、AWSの布教ができていなかったり、などの課題が多く残っている状態です。

特に事業部によって特性が異なり、個別対応が必要なケースは悩まされますが「インフラをどのように適用すると事業がドライブしやすくなり、SMSが成長し社会に貢献できそうか」と考えながら進められる仲間がほしいなと最近思っています。