私はインフラエンジニアとして、データベースのクラウド移行に伴う関係サーバーの移行プロジェクトに参加しました。移行先はAWSではなく、Oracle Cloud Infrastructure（OCI）です。
担当したのはプロジェクト全体ではなく、セキュリティ部分、Terraformによる構築の自動化、バックアップ設計です。工程としては、調査・設計・構築に携わりました。
この記事では、担当範囲を限定して正直に記載したうえで、オンプレミスからOCIへ移行するときに難しかったことや、転職面接でどのように説明したかを紹介します。
※本記事は個人の経験を一般化したものです。顧客名、システム名、具体的な構成、設定値などの機密情報は記載していません。
移行プロジェクトの概要
プロジェクトの中心はデータベースの移行でした。それに伴い、データベースと関係するサーバーもオンプレミス環境からOCIへ移行する必要がありました。
私はデータベース本体の移行を担当したわけではありません。関係サーバーのうち、次の領域を担当しました。
- セキュリティに関する機能の調査・設計・構築
- Terraformによるインフラ構築の自動化
- 移行後のネットワークを考慮したバックアップ設計
担当範囲は絞られていましたが、オンプレミスとクラウドの違いを理解しながら、新しい構成を検討する経験になりました。
担当した工程は調査・設計・構築
調査
最初に、オンプレミスで利用していた機能をOCIへ移行した場合、どのような機能やサービスで実現できるかを調べました。
単純に既存構成を置き換えるだけではなく、クラウドで新しく利用できる機能も調査しました。公式ドキュメントを確認し、要件に合うか、既存環境へどのような影響があるかを整理しました。
設計
調査結果をもとに、セキュリティ機能とバックアップの設計を行いました。特に、クラウドへの移行によってネットワーク構成が変わるため、バックアップデータをどの経路で取得するか、必要な通信が可能かを検討しました。
「バックアップを取得できる」という機能面だけでなく、移行後のネットワークで継続的に運用できる構成にする必要がありました。
構築
設計したインフラの一部はTerraformを使って構築しました。手作業で設定するのではなく、構成をコードとして定義し、同じ内容を再現できる形にしました。
Oracleの公式ドキュメントでも、OCI Terraform Providerを利用するとOCIリソースをコードで管理できると説明されています。仕様や対応リソースは更新されるため、実際に利用するときはOCI Terraform Providerの公式ドキュメントを確認してください。
特に難しかったこと
クラウドにしかない機能を調査・設計したこと
オンプレミスで使っていた機能をそのまま移すだけでなく、クラウドで新しく利用できる機能を取り入れる必要がありました。
既存の設計を参考にできない部分では、サービスの仕様、制約、他の機能との関係を一から調査しました。「利用できるか」だけではなく、セキュリティ要件を満たせるか、運用時に確認しやすいかまで考えて設計しました。
クラウドサービスは機能の更新があるため、過去の知識だけで判断せず、設計時点の公式情報を確認する大切さを実感しました。
変更後のネットワークでバックアップを設計したこと
クラウドへ移行すると、サーバーの配置や通信経路がオンプレミス時代と変わります。以前と同じバックアップ方法をそのまま使えるとは限りません。
移行後のネットワークを整理し、バックアップに必要な通信、接続先、取得方法を検討しました。ネットワークとバックアップを別々に考えるのではなく、一つの構成として確認する必要があった点が難しかったです。
Terraformによる自動化で学んだこと
Terraformを使うことで、インフラの構成をコードとして残せます。設定内容を確認しやすくなり、同じ構成を再現するときにも役立ちます。
一方で、コードを書けば自動的に正しい環境ができるわけではありません。変数、依存関係、実行順序、変更時の影響などを考える必要があります。実際のリソースとTerraformの管理状態がずれないように扱うことも重要です。
この経験を通じて、クラウドサービスの知識だけでなく、Infrastructure as Code（IaC）を前提とした設計・構築の考え方を学べました。
OCIへ移行して感じたこと
私は移行後の運用を継続して担当していないため、運用負荷やコストが実際にどれだけ改善したかは判断できません。そのため、「クラウドへ移行すれば必ず運用が楽になる」といった断定はしません。
設計・構築時に感じたのは、コンソール上で機器やリソースの状態を確認しやすく、セキュリティに関する情報も把握しやすいことです。ただし、どこまで確認できるかは、利用するサービスや設定によって異なります。
クラウドには可視化や自動化に役立つ機能がありますが、それを生かすには監視方法や権限、運用手順まで設計する必要があります。
転職面接での説明方法
転職面接では、プロジェクト全体を担当したようには説明せず、自分の担当範囲がセキュリティ、Terraform、バックアップに絞られていたことを伝えました。
そのうえで、調査・設計・構築の各工程で何を考え、どのような課題に対応したかを説明しました。特にTerraformについては、面接官が興味を持って質問してくれたと感じています。
クラウド移行の経験を伝えるときは、単に「OCI移行を経験した」と話すより、次の項目に分けると説明しやすくなります。
- 移行対象とプロジェクト全体の目的
- 自分が担当した範囲
- 担当した工程
- 難しかったことと調べた方法
- 自動化や設計で工夫したこと
担当範囲が狭くても、その範囲でどのように考えて行動したかを具体的に話すことで、経験を正確に伝えられます。
この経験がクラウド転職で役立った理由
移行経験を通じて、オンプレミスの構成を理解するだけでなく、クラウド固有の機能、ネットワーク変更、IaCを含めて考える機会がありました。
AWSとOCIではサービス名や仕様が異なりますが、要件を調査し、クラウドに合う構成を設計し、コードで構築する考え方は、別のクラウドを扱うときにも役立ちます。
私がインフラエンジニアからクラウドエンジニアへ転職した理由や、転職後の変化は、こちらの転職体験記事で紹介しています。
まとめ
- データベースのOCI移行に伴う関係サーバーの移行に参加した
- 担当範囲はセキュリティ、Terraform、バックアップだった
- 調査・設計・構築の工程を担当した
- クラウド固有機能の新規設計と、変更後のネットワークを考慮したバックアップ設計が難しかった
- 移行後の運用は担当していないため、効果は断定しない
- 面接では担当範囲を正直に伝え、Terraformの経験に関心を持ってもらえた
クラウド移行経験を転職で伝えるときは、クラウド名だけでなく、自分の担当範囲、工程、課題への対応を具体的に整理することが大切です。
