当社は2021年、社内システムをクラウドへ移行しました。奇しくも、コロナ禍の環境変化と背中あわせのプロジェクトとなりました。どのような経緯をたどって移行できたのか、概要を紹介します。

背景と課題：ハードウェア更改ラッシュをどうするか

従来のオンプレミス環境においては、一般的な製品の保守期間を考慮して5年毎にハードウェアを更改していました。サーバーを仮想基盤へ集約していたこともあり、2016年には多くの機器が更改対象となりました。

• 業務系システムのSPARCサーバー
• 情報系システムの仮想基盤サーバー・ストレージ
• データセンターのネットワーク機器

全体の規模感としてはハードウェア10数台、VM100台程度なのですが、１年に集中すると更改の作業負荷も小さくありません。ハードウェアや仮想基盤のセットアップから始まり、サーバーの構築、各システムの動作確認と切り替えに至るまで、情報システム部門の要員をかなり割いて対応するので、更改の年は新システムの検討、既存システムの追加開発、運用の改善等が後回しになりがちです。可用性の確保とキャパシティの強化という点では重要ですが、これから先も5年周期でビッグバンのように発生するのでは難題です。

このため、次の更改ラッシュとなる2021年を見据えて、オンプレミスのまま乗り切るか、クラウドへ移行するかが大きな焦点となりました。

分析と検討：次の更改でどこに移行すべきか

2021年のハードウェア更改に向けた検討は、2019年から始まりました。数年間のAWSの試用でクラウドの感触を掴めてきた時期であり、AzureとGCPの試用も始まっていました。システムのクラウド移行が、現実的な選択肢として浮上しました。

移行対象は大きく3系統あり、それぞれ特徴と課題がありました。

業務系システム：OracleDBのままアプリ刷新しやすい環境へ

勤怠・労務管理や案件・原価管理等のアプリケーション群です。商用製品は導入しておらず¹、独自開発しています。CPUはSPARC、OSはSolaris、DBはOracleDB、アプリケーションはJavaで開発という構成で、古いフレームワークからの脱却とアーキテクチャの刷新が長年の課題となっていました。

ハードウェア更改の検討と並行して、アプリケーションやミドルウェアレベルでのリニューアル検討も始まりました。こちらは2021年の更改後に順次書き直していくことを見据えたものでしたが、早い段階で以下の方向性が見えました。

• 近年のオープンソース実装が主にx64系CPUとLinux系OSを中心に充実しており、SPARCとSolarisでは選択肢が限られる。
• アプリケーションは、段階的に改良していけるようにフロントエンドとバックエンドを分離して、コンテナで稼働させる。コンテナ基盤にはKubernetesを採用する。
  • 試金石として、最も規模の小さいシステムでリニューアル開発を進め、2021年の更改時にリリースする。
  • 他のシステムについては、現状のミドルウェア構成のままコンテナ化できるようにして、更改に備える。更改後に、パイロットプロジェクトを参考に順次リニューアルしていく。
• DBはアプリケーションの改修負荷を考慮し、OracleDBを継続する。PostgreSQLへの移行は見送る。

アプリケーションの実行基盤の中核となるKubernetesについては、技術検証を先行して進めていたものの、クラスターの設計やキャパシティを見通せる段階ではありませんでした。世の中のオンプレミスでの構築事例も多いとは言えず、クラウドのマネージドなKubernetesサービスを軸に検討するのが望ましいと判断しました。

さらに、OracleDBの稼働コストの観点で、OCI(Oracle Cloud Infrastructure)への移行が有力となりました。OCIのDBインスタンスはライセンス費用も含まれた料金であるのに対して、他のクラウドではCPUコア数に応じたライセンスを持ち込む必要があり、いわゆるBYOLの費用が割高でした。もし、コア数とメモリのバランスが極端なインスタンスタイプ（例えば1コアで64GBメモリ）があれば、他のクラウドを選んだかもしれません。

情報系システム：多様なサーバーを引っ越し・調整しやすい環境へ

こちらは、Active Directory、ファイルサーバー、メールシステム、Wiki、統合認証基盤、Webプロキシ、リモートアクセスシステムなど多岐に渡ります。独自開発よりも商用製品やオープンソースソフトを導入するケースがほとんどで、OSとしてWindows Serverが多いのも特徴です。

仮想基盤上に集約されており、VMの台数も多いため、既存サーバーのディスクを新しい環境へ簡単に転送できる手段が重要です。また、ワークロードの変化に合わせてサーバースペックを柔軟に変更できる必要もありました。

この2つの要件は、AWS、Azure、オンプレミスの仮想基盤のどれでも対応可能です。しかし、更改時に余裕をもたせた仮想基盤のキャパシティが足りなくなるリスク、ハイパーバイザーの更新の手間、さらに業務系システムがクラウドに移行する方向性を踏まえて、オンプレミスの仮想基盤が候補から外れ、さらに後述のネットワーク設計の観点からAzureを採用することになりました。

ネットワーク：ファイアウォール中心の構成が組める環境へ

インターネット、DMZ、イントラネットの境界をファイアウォールアプライアンスで制御しており、業務都合で発生するファイアウォールルールを集中管理しています。クラウドサービスのセキュリティグループによる設定だと煩雑になる懸念もあり、従来どおりの管理方法を継続したいところでした。

このため、クラウドへ移行する場合、サブネット間の通信がファイアウォールアプライアンスを必ず経由させることが要件となりました。検討時点では、Azureだけが意図したネットワーク設計を実現できそうでした。AWSでも2021年秋に同様の設計が実現可能になりましたが、当時は実現のメドが立たず候補から外れました。

オンプレミスとクラウドネットワークの接続については、事業所間回線で利用している閉域接続サービスのクラウド接続オプションを利用する方針でした。Azureとの接続は対応していた反面、OCIには非対応だったため、AzureのVNetをハブとする形でのVPN接続を視野に検討することになりました。

以上を踏まえて、ネットワークと情報系システムをAzureに、業務系システムをOCIに移行する方針が固まりました。単純なコスト観点では、オンプレミスのまま更改するほうがたしかに合理的でした。しかし、想定と異なるワークロードやキャパシティの調整が発生した際に柔軟に対応できる点や、今後ハードウェアのライフサイクルに制約されることなく自分たちのペースで改善できる点を重視しました。

検証と準備：コロナ禍の状況でどう進めるか

クラウド移行に向けた検証と準備は、2020年に本格化する予定でした。折しもCOVID-19（新型コロナウイルス感染症）の影響で、リモートワーク環境の強化が全社的な喫緊の課題となっていました。

当社においても、Web会議システムの導入、リモートアクセスシステムの増強、セキュリティや業務プロセスの見直し等が発生しました。全社的に在宅勤務が定着した後には、Web会議やリモートアクセスのトラフィック対策として、社内ネットワークやインターネット回線を強化しています。顧客先常駐だった技術者が「社内」に戻ったことで、様々なシステムの利用が増加しました。このあたりの詳しい話は、パンデミックから１年、リモートワーク環境の継続的改善についてをご参照ください。

クラウド移行プロジェクトは、こうした動きと並行して進めることになりました。在宅勤務にシフトしたプロジェクトメンバーにとって、外部環境やワークスタイルの変化でシステムの負荷が高まっても、可用性とパフォーマンスを確保する重要性を改めて痛感した次第です。このような流れのなかで従来と同じ手段にこだわっている場合ではなく、オンプレミスからクラウドへ移行する方向性はさらに強まりました。

業務系システム：コンテナ化確立後にクラウドで環境構築

OCIの利用開始が遅れたことから、オンプレミスで暫定的に構築したKubernetesでアプリケーションのコンテナ化とCI/CDプロセスの確立を優先的に進めました。COVID-19の余波による苦肉の策でしたが、OCIの利用前にコンテナとDevOpsのノウハウをチーム全体に浸透させることができたので、結果オーライだったと言えます。

OCIの利用開始後は、コンパートメントやVCN等の環境整備、Kubernetesの構築、OracleDBの検証、システム全体としての動作確認を進めていきました。他のクラウドの利用経験から環境整備を短期間で完了し、後工程の期間を確保できた点は幸いでした。

OKE(Oracle Kubernetes Engine)で構築したKubernetesは、8つのシステムの本番・試験環境とCI/CDツールを安定稼働させるため、ワーカーノードに余裕を持たせた大規模な構成となりました。ただ、OCIのVM単価が他のクラウドの3年予約並みの安さであり、コスト的なインパクトには至りませんでした。

OracleDBは最新バージョンにおける挙動や設定・性能調整に苦慮したものの、半年に渡るベンダーの技術相談やサポートのおかげもあって解決できました。最終的には、今後も増え続けるデータや負荷も勘案して、インスタンスサイズを想定より引き上げて稼働させることになりました。

情報系システム：移行ツールでディスクをじっくり転送

Azureでは、サーバー移行ツールとしてAzure Migrateが提供されています。検証の結果、当社の仮想基盤からの移行にも問題なく使えることがわかりました。このため、事業所間回線とAzureの閉域接続の開通後は、イントラネット上のサーバーを先行して順次移行していくことになりました。大きなハードルはなかったのですが、ファイルサーバーやメールボックスなどディスクの大きいサーバーについては、転送が数日から1週間規模となり、社内ネットワークとインターネット回線の帯域にも配慮する必要がありました。

DMZ上のサーバーは、AzureでのファイアウォールとDMZの構築を待つため、予定どおり2021年に移行していくことになりました。また、DHCPサーバーはVNetの仕様上プロトコルが通らないため、オンプレミスで稼働する例外的なサーバーとなりました。

ネットワーク：社内NWのトラフィック対策後に本格整備

サーバー台数の多い情報系システムの移行の都合から、Azure上でイントラネットを先行して整備した一方で、ファイアウォールとDMZの構築については後回しとなりました。検討段階ではインターネットとの出入り口をAzure側に集約する構想でしたが、Web会議システムやリモートアクセスのトラフィック対策として、主要な事業所にインターネット回線を引いてHTTPSの通信をオフロードすることになりました。このため、社内ネットワークの構成変更が落ち着いてから対応していくことになりました。

なお、この時期には、ネットワーク要件が特殊な独自開発のリモートアクセスシステム（alpha Teleworker）の動作や、VNetをハブとしたOCIとのVPN接続についても見通しが立ちました。後者については、ベンダーの移行支援プログラムで「Azureとして一般的なアプローチとは言えないものの、同じような使い方をするユーザーがいる」というアドバイスを頂けたこともあり、メドがつきました。

移行と今後：これから先の変化にどう向き合っていくか

業務系は一斉に、情報系は順次切り替え

業務系システムは、すべてのシステムが一つの統合DBに接続されている構成です。そのため、クラウド上の新環境へ段階的に切り替えるアプローチを採れませんでした。入念な準備と確認のうえ、2021年夏に一斉に切り替えましたが、幸い大きなトラブルもなく乗り越えることができました。リニューアル開発してリリースされたシステムも含めて、順調に稼働しています。

情報系システムは、2020年度後半から2021年度に渡り、長期間かけて順次移行しました。新規構築したサーバーもありますが、大半は移行ツールでディスクデータを転送・同期して、タイミングを決めて切り替える、を繰り返す形でした。移行後にアクセスパターンの変化で性能が厳しくなったサーバーもあり、インスタンスやディスクタイプの変更・台数増強で対応しました。特にリモートアクセスシステムは、緊急事態宣言やまん延防止等重点措置と連動してユーザー数も変動するため、クラウドの弾力性が存分に発揮されました。

ネットワークは様々な要素に左右されましたが、最終的にファイアウォールを中核にネットワーク境界を集中制御する構成で稼働できました。しかし、感染の第6波が到来したことで、さらなるトラフィック対策としてファイアウォールアプライアンスの性能調整や事業所間回線の強化が課題となっています。

本番環境の移行が落ち着いた後は、DR（災害時復旧）環境もクラウドで構築しています。業務系・情報系ともに、OCIの大阪リージョンを利用する方向です。もっとも、クラウドサービスがリージョン問わず全く使えなくなったり、拠点間回線が長期間ダウンする最悪の事態に備えて、オンプレミスでの復旧手段も用意しておくことになるかもしれません。

変化に合わせて、インフラもアプリも進化しつづける

全体を通して良かったのは、情報システム部門がクラウド移行だけに専念することなく、他のタスクも並行して進められた点です。具体的には、前述のリモートワーク環境やインターネット回線の強化のほか、業務系システムの法改正対応、在宅勤務に対応した勤怠システム改修、新事業所のLAN整備、エンドポイントセキュリティの入れ替えが挙げられます。このうち、法改正対応以外はワークスタイルの変化が少なからず関連しています。

また、クラウドベンダーによる移行支援プログラムのお世話になれたことも幸いでした。通常のサポートだけでは厳しかったかもしれない技術的な懸案²を相談でき、解決の糸口を掴めました。コロナ禍で検証・準備の出足が遅れたなか、大変ありがたいオファーでした。

クラウド移行の2年間は、コロナ禍の環境変化に対応してきた2年間でもあります。もしオンプレミスでの更改を前提としていたなら、両立するのはもっと大変だったかもしれません。様々な改善と対応の余力を確保しつつクラウドへの移行を実施できたことで、インフラ構成の更新とアプリケーションのリニューアルをどう両立していくか、組織としての下地が整ったと言えます。次の5年後にハードウェア更改ラッシュはなく、更新やリニューアルの計画も柔軟になります。

社員のワークスタイルやシステムのワークロードは、これから先も変化していくことでしょう。技術レイヤもライフサイクルも異なる様々なシステムが、当社でも稼働しています。今後も、規模や粒度の異なる改善・変更・更新・リニューアルを継続的に実施することになります。変化に合わせて、システムも進化させていきたいと思います。