クラウド移行とモダン化をあえてシンプルに考えてみる
※ この記事は、2024年01月15日にQiitaで投稿した記事を移転したものです。
目次
はじめに
最近、クラウド移行について深く考える機会があったので、筆者の頭の整理も兼ねて体系的に書こうと思う。
システム設計にはバリエーションが無数にあるので、かえって混乱している人もいるのではないか。
そのため、ここはあえて網羅性は捨てて、シンプルに説明していく。
なお、この記事では、アプリケーション・ミドルウェア・OSを含んだ集合体のことをシステムと呼称する。
想定する読者
オンプレミスでのアプリケーション設計の経験（又は知識）はある。
AWSなどのクラウドサービスは、ほとんど使ったことがない。
この記事を読むと理解できること
クラウド移行のメリット、方式（5つのR）、ステップ（手順）
アプリケーションのモダン化
クラウドとオンプレミスの違い
クラウド
サーバー、ストレージ、サービスなどを必要に応じてネットワーク経由で利用する形態である。
必要なサービスを必要なだけ利用し、その分の利用料を支払う。
ハードウェアの調達にかかるイニシャルコスト（初期費用）を抑えて、スピーディーに環境を構築することができる。
オンプレミス
調達したサーバーやソフトウェア、集積したデータなどを自社に設置して運用する形態である。
カスタマイズの範囲が広く、自社の環境にあわせて作り込むことができる。
自社でハードウェアの調達、構築、運用を行う必要があるため、イニシャルコストが高く、ランニングコスト（維持管理コスト）がかかる。
クラウド移行のメリット
① コスト（費用）を削減できる
ハードウェアや設備投資のイニシャルコストが不要になる。
サーバーの維持費、運用・監視の人件費が削減できる。
従量課金制が一般的であるため、ランニングコストを調整しやすい。
② 導入にかかる労力と時間を削減できる
クラウド事業者（AWSなど）が既に提供しているサービスを利用するため、導入リードタイム（作業開始から終了までの所要時間）の短縮とユーザーの負荷が削減できる。
③ 運用・保守の負荷を軽減できる
ハードウェアの管理、ミドルウェアやソフトウェアの更新、データのバックアップ作業がユーザー側で必要なくなるため、システム担当者の負担軽減につながる。
④ サーバー増強、システム変更、負荷分散が柔軟にできる
画面から設定を変更するだけで、容量の拡張や負荷分散が柔軟に対応できます。
⑤ 物理的な障害対応をクラウド事業者に任せられる
物理的な障害対応をクラウド事業者に任せることができるため、ユーザーの負担を大幅に軽減できる。
障害の発生防止と復旧作業も含めクラウド事業者側に委ねることができる。
⑥ BCP（事業継続計画）、セキュリティ対策を委託できる。
クラウド事業者は、複数の拠点にデータセンターを保有し、データを分散して保管しているため、災害が発生してもクラウドにあるデータは保護される。
データセンターは、オンプレミスより堅牢性の高いセキュリティで運用されている。
○ 補足
特にコスト削減（TCO）については、移行方式やどの程度クラウド最適化を進めるかによって、その効果が変わってくる。
下図のクラウド最適化の状態を目指して、継続的にコスト削減を意識していく必要がある。
クラウド移行の方式
オンプレミスからクラウドへ移行する方式は、大きく分けて5つ存在する（5つのR）。
提唱者（Gartner、AWS、Azure）によっては呼び方は異なるが、内容に大きな差はない。
① リホスト（Rehost）
既存のアプリケーションを変更せずにクラウドへ移行する方式である。
クラウドのメリットを生かしきれないというデメリットがある。
移行作業に必要な時間やコストが少なく済み、専門知識が不要である。
② リファクタ（Refactor）
既存のアプリケーションの設計は維持したまま、一部をマネージドサービス（運用・保守をクラウド事業者にお任せできるサービス）に置き換える方式である。
典型的なものとしては、データベース（DB）やキャッシュサーバーのマネージドサービスへの置き換え挙げられる。
クラウドのメリットを一部得ることができる。
③ リバイズ（Revise）
既存のアプリケーションの設計をベースに、機能を追加・改修する方式である。
クラウドのスケーラビリティを活用できるように、オートスケール機能などを取り入れる。
移行の手間を削減し、クラウドネイティブのメリットを得ることができる。
リプラットフォーム（Replatform）と呼ばれることもある。
④ リビルド（Rebuild）
既存のアプリケーションを一からクラウドネイティブなアーキテクチャに作り変える方式である。
基本的に新しいアプリケーションの開発と同様であるため、移行コストが高い。
古い技術から脱却することで、クラウド特有の機能やサービスを最大限に活用することができる。
⑤ リプレイス（Replace）
古くなった既存のアプリケーションを破棄し、SaaSやDaaSに置き換える方式である。
エンドユーザーがインターフェース（画面）や操作性に慣れるまでの教育コストはかかる。
移行スピードが早く、移行コストも抑えることができるので、2つのメリットがある。
リパーチェイシング（Repurchasing）と呼ばれることもある。
クラウド移行のステップ
① 課題の把握、移行の目的・予算・スケジュールの検討
以下の観点での検討を行う。
現在のシステム課題の解決につながるか。
事業戦略に合致しているか。
オンプレミスのままではなぜダメなのか。
予算はどのくらい使えるのか。
セキュリティリスクは問題ないか。
ポリシー（方針、施策）やコンプライアンスへの適合性は高いか。
どのシステムを、いつまでに、どの範囲でクラウド移行するか。
② 情報資産の整理と棚卸し
上記①と同時並行で、移行させたいハードウェア、ソフトウェアの稼働状況を把握する。
現状確認がおろそかになると、移行コストが想定以上にかかってしまうことがある。
③ 移行対象システムの選定
クラウドへ移行するシステムは一部か全部か、複数ある場合は移行の順序を検討する。
業務課題の緊急度や影響度などを吟味し移行の優先順位付けを行う。
④ アーキテクチャの検討とクラウドの選定
移行方式の５パターンのうち、どれで行うかを検討する。
要件定義が行った後、必要な機能を兼ね備えたクラウドサービスを選定し、アーキテクチャの設計を行う。
パートナー会社と契約し、要件定義・設計から移行・運用までを支援してもらうことが多い。
⑤ 移行計画＆移行リハーサル
どのシステムやデータから移行していくのか計画を立てる。
移行手順が決まったら、ベンダとともに移行リハーサルを行う。
実際のオペレーションが見積りの範囲内で収まるか、抜け漏れがないかなどの検証を行う。
ここで発見した課題の対策を立てることは、移行作業（本番）のスムーズなオペレーションや甚大なインシデントの防止につながる。
⑥ 移行本番の切り替え
システム切り替え当日の作業手順と関係者の連絡方法をまとめておく。
パートナー会社に作業委託する場合は、役割分担を明確にしておくことが重要である。
移行作業の進捗共有など、クイックなコミュニケーションができない場合、サービス停止時間に大きな影響が出る可能性がある。
移行完了後、各種システムの動作確認を行い、不具合や障害が無いかをチェックする。
アプリケーションのモダン化とは
アプリケーションのモダン化（モダナイゼーション）とは、レガシー（古い）な技術で作られたアプリケーションをモダン（新しい）な技術に更新するプロセスのことを指す。
マイクロサービスアーキテクチャの導入、コンテナ化、DevOpsの採用など、多くの手法や技術が含まれることがある。
モダンなアプリケーションは、柔軟で拡張性があり、新しい機能の追加や変更を素早く行えるため、業務の変化に効果的に対応できる（モダン化の目的）。
リビルドによってクラウド移行する際は、モダン化についても同時に考えたほうがよい。
一度に全ての要素をモダン化することが難しい場合は、段階的にモダン化を進める。
あえてシンプルに考えてみる
ここからは、筆者の個人的な感想である。
一番見解の割れやすいところは、クラウド移行の方式とアプリケーションのモダン化ではないかと思う。
アプリケーションやクラウドサービスの組み合わせは無数に存在するので、移行コストや拡張性などの観点から総合的に判断する必要がある。
しかしながら、あえてシンプルな考え（指針）を提示するとすれば以下のとおり。
小規模なシステム ⇒ リプレイス（又はリビルド）
中規模なシステム ⇒ リビルド（又はリバイズ）
大規模なシステム ⇒ リバイズ（又はリファクタ）
特に、社内で使うような業務アプリについては、インターフェースをリッチにする必要はないため、リプレイスで問題ないように思う。
アプリケーションは、大きく分けると以下の３つの要素から成り立っている。
ユーザーインターフェース（UI）
ビジネスロジック（BL）
データベース（DB）
例えば、これをPowerPlatform（Microsoft）で再構築すると以下のようになると思う。
SaaSでの再構築例
UI…PowerApps
BL…PowerApps、PowerAutomate
DB…Dataverse
一方、対外的なアプリケーションについては、インターフェースが命といっても過言ではないため、リビルドなどを検討する必要がある。
例えば、AWSのマネージドサービスで再構築すると以下のようになると思う。
UI（フロントエンド）とBL（バックエンド）が別アプリになっている場合（疎結合）
UI…S3
BL…ECS（Fargate）、Lambda
DB…RDS、DynamoDB
UIとBLが一体のアプリである場合（密結合）
UI…ECS（Fargate）
BL…ECS（Fargate）
DB…RDS、DynamoDB
Fargateはもちろん、Lambdaも2020年からコンテナに対応したので、アプリケーションごとに自由に仮想環境を構築できるようになった。
ただし、Lambdaは運用コストが激安である代わりに、以下のような制約もあるため、マッチしない場合はFargateを選択したほうがよい。
1回のリクエストに対する実行時間は15分まで（セットでよく使われるAPI Gatewayのタイムアウト時間は29秒）。
メモリは最大10GBまで。
同時実行数は、同一アカウント・同一リージョン内で1,000まで。
一時ストレージは512MBまで。
起動する際の初期化に少し時間がかかる（コールドスタート）。
デプロイする際のパッケージサイズは250MBまで（解凍後のサイズ）。ただし、コンテナイメージの場合は10GBまで。
中にはアプリケーション側を作り込めば回避できるものもあるが、一般的に大規模なアプリケーションやレスポンス速度が求められるアプリケーションには向いていないとされる。
DBについては、既にデータが複数テーブルに入っていて、外部キーを貼っているのであれば、素直にSQL系のDBサービス（AuroraなどのRDS）を使うのが吉だと思う。
そこそこ規模が大きいDBをバラしてNoSQL系（DynamoDBなど）で再構築するなんて、考えただけでも震える。
そもそも両者は使用用途（向いてるケース）が違うので、移行するとなれば、それなりにアプリケーションも改修しなければならない。
筆者は、個人開発ではもっぱら、フロントエンドはS3（Amplify）、バックエンドはLambda、DBはDynamoDBを使っている。
一時期はFargateを使っていたが、毎月発生するECSインスタンスとロードバランサー（ALB）の維持費のダブルパンチに耐えきれなくなって、Lambdaに移行した（円安の影響も含めるとトリプルパンチ）。
激安のLambdaと激安のDynamoDB。速度より料金。乞食アーキテクチャである。
【参考】個人開発の履歴
最後までお読みいただき、ありがとうございました。
参考サイト