OCLS(Oracle Cloud Lift Services)を利用して移行検討した内容を、お伝えできる範囲で提供していきます！

今回のユースケースは・・・・

24h365dで稼働することが求められる通販事業システムの移行先としてOracle Cloud Infrastructure(OCI)を検討したケースです。
サーバレスなOCIのサービスを用いたクラウドへの移行検討の具体的な内容をご紹介いたします。

検討ポイント！！

サーバレスなサービスを用いて業務を効率化したい！けど実際に移行するとなると安定して稼働はしてほしいし、なんだかんだコストは気になるし、、、結局検討事項が多いのがネックなんだよなぁ。。と考えられている方も多いのではないでしょうか。
今回取り扱った案件では通販事業システムのOCIへの移行に、そんなサーバレスなサービスの利用を検討しました。

今回通販事業システムを移行する際に検討したポイントは以下の通りです。

• 安定稼働
  • 通常運用時においてはもちろん、メンテナンス対応時にも安定稼働が必要。
• 管理/運用の工数削減
  • 現行環境で課題になっているインフラの運用負荷を可能な限り削減するすることが必要。
• コスト削減
  • 通販システムの定期的に来るハードウェア老朽化対応（検討、HW交換や構築など）および稼働しているデータセンター費用を削減することが必要。

クラウドの検討理由とOCLSを利用するに至った背景

今回の案件は現在利用しているオンプレミス基盤のEOLが迫ってきており、OCIへの移行を検討したいというものでした。

また課題の中でも、一番優先度が高かったものとして、現行システムのインフラにおける運用面をかなり負担に感じていて、OCIへ移行する際には可能な限りインフラ部分における運用負荷をオフロードしたいというお客様からの強い希望がありました。

そのため、今回は移行にあたりサーバレスによる運用改善が最も合うのでないかということで、以下のOCIのサーバレスを候補として検討してみました。

• AP基盤
  • OKE(Oracle Container Engine for Kubernetes)もしくはOCI Container Instance
• DB基盤
  • Oracle Autonomous Database Serverless

サーバレスなサービスを用いてクラウド移行を行うため、本当に運用負荷の削減や安定稼働は実現できるの？コストも本当に安くなるの？というような不安を、それぞれの製品について正確に知ってらうことで解消し、クラウド移行における正確な判断をしてもらえるように今回OCLS(Oracle Cloud Lift Services)をご利用いただきました。
そしてさらに！Cloud Nativeのスペシャリストである市川氏＆仁井田氏によるハンズオンを実施し、実際にお客様に製品を触ってもらいながらOCIの製品について理解してもらう機会も作ることができました！

いきなり検討結果から！

検討内容をご紹介する前に、まずは今回のクラウド移行における検討結果からお伝えしようと思います。
最終的な検討結果は

• AP基盤
  • OCI Conatiner Instance
• DB基盤
  • Oracle Autonomous Database Serverless

を利用するということになりました。

詳細については後段での説明となりますが、上記の製品において共通していることは、
AP、DB共にコンテナであり、サーバレス化によって運用が自動化できる点です。
APのコンテナはわかるが、DBのコンテナ？となっている方もいるかもしれません。

ここからは各製品を解説しつつ、お客様にとってどのような部分が決め手となったかについてお伝えできればと思います。

3つの検討理由

1.お客様に響いたサーバレスなAP基盤とは？

今回の案件の前提として、クラウド移行に伴いアプリケーションを作り変え、コンテナ化を実施するという要件がありました。そのため、検討前の段階ではAP基盤の部分はOKEもしくはContainer Instanceを利用し、インフラの運用負荷を可能な限りクラウドベンダーへオフロードすることでアプリケーションの作り変えに工数を割きたかったという背景がありました。

そしてそのような要件の中、最終的に選ばれたのはContainer Instanceでした。
なぜOKEではなくConatiner Instanceになったのか。

ここからは本案件の検討ポイントに対して各製品の持つ特徴がどのように活きるのか、そしてその特徴がどのようにお客様に響いたのかについてお伝えしていきます。

OKEって何がすごいの？

OKE(Oracle Container Engine for Kubernetes)は、オープンソースのKubernetesをOracleが管理しやすいようにマネージド化したサービスです。

主な特徴としては、

• 複雑なKubernetesの構築不要で、開発を即座に開始
• カスタマイズなしのピュアなKubernetesを使用可能
• インフラ管理が不要なワーカー・ノードのオプション機能であるVirtual Nodeの利用が可能

などが挙げられます。

上記の特徴より、今回の検討ポイントである「管理/運用工数の削減」の要件は満たすことができます。
OKEを検討した中で一番のポイントはVirtual Nodeの利用でした。上述の通り、Virtual Nodeはワーカー・ノードの管理が不要で、アップグレードやトラブルシューティングなどの運用を自動化してくれる特徴を持ちます。
今回の案件はアプリケーションの作り変えに伴い、インフラの運用保守には可能な限りリソースを割きたくないという前提があったため、こちらの機能が非常にマッチしました。

Container Instanceって何がすごいの？

OCI Container Instanceはインフラ管理不要のコンテナ実行環境です。

主な特徴として

• コンテナオーケストレーションを必要としないコンテナアプリケーションのデプロイに最適
• ユーザによる仮想マシンの管理、パッチ適用、トラブルシューティングが不要
• コンテナ化されたアプリケーションの即時実行が可能

などが挙げられます。

OKEのVirtual Node同様Conatiner Instanceも仮想マシンの管理、パッチ適用、トラブルシューティングが不要というのが特徴で、OKEの部分でも言及した通り、今回の検討ポイントにマッチしたサービスとなっています。
OKEとの最大の違いはコンテナオーケストレーションを必要としない点、つまりノードの管理やスケールアウトの考慮を必要としないアプリケーションをコンテナ化してサーバレスで運用することに適しています。

Container Instanceを選択した理由

OKEとConatiner Instanceはどちらも今回の検討項目の「管理/運用工数の削減」の要件に非常にマッチするサービスでしたが、結果的にAP基盤はContainer Instanceを選択する形となりました。
大きな理由としては、次期環境ではインスタンスのスケールイン/アウトが発生しないことが分かったためです。そのため、OKEほどの機能は今回は不要で、スケールアウトの考慮を必要としないアプリケーションをコンテナ化する運用に合ったContainer Instanceとなりました。

2.コンテナで運用されるサーバレスなDB基盤とは？

冒頭に紹介したように今回の案件の目的は通販事業システムの移行でした。通販事業システムはお客様が運営されるECサイトに直接関わることとなり、ビジネスを進めていく上で非常に重要なシステムということになります。さらに今回の案件ではインフラの運用管理に割く工数を可能な限り削減し、同時に安定稼働も実現したいという要件がありました。そこで、このようなミッションクリティカルなシステムをサーバレスで運用し、かつ安定稼働の実現を可能にする製品として検討対象となったのが、Autonomous Databaseでした。

Oracle Auntonomous Database Serverlessって何がすごいの？

Autonomous Databaseは完全に自動化された、サーバレスで運用可能なデータベースです。

主な特徴として、

• データベースのプロビジョニング、チューニング、スケーリングを自動化(自律運転)
• データ保護とセキュリティを自動化(自己保護)
• 障害検出、フェイルオーバー、修復を自動化(自己修復)

などが挙げられます。
この特徴により通販事業システムは運用が自動化されつつ、かつ堅牢なセキュリティ及び高い可用性を保ちながら稼働することが可能になります。Autonomous Databaseはこのようなミッションクリティカルなシステムを自動で運用したい場合に最適な選択肢と言えると思います。
これより、Autonomous Databaseは検討ポイントである「運用/管理工数の削減」の要件に非常にマッチするということがわかります。

また、Autonomous Databaseは非常に高性能な Exadata基盤上で稼働しているため、自律型でありながら非常に安定した状態での稼働を実現します。
そして今回移行対象となるのは通販事業システム。お客様のビジネスの大部分を占めるECサイトなどが関わってきますので絶対に止められません。
そのような経緯もあり、Exadata基盤上で稼働するAutonomous Databaseというのは今回の検討ポイントである「安定稼働の実現」にも非常にマッチするものとなりました。

なぜAutonomous Databaseなのか

上記の内容を受け、Autonomous Databaseが今回の検討ポイントにマッチしていることがわかりました。

ではなぜ候補として挙がったのがAutonomous Databaseだったのでしょうか。
自動での運用であればMySQLでも大丈夫なはずなのに。。。と思った方もいらっしゃるかもしれません。

1つ目の理由としては、今回の案件ではクラウド移行対象のDB基盤がOracle Database 11gだったことです。そのためクラウド移行を行う際には、Oracle DatabaseのPaaSであるAutonomous DatabaseがOracle to Oracleということもあり、一番移行がしやすく、更にサーバレスにできるという点がありました。

2つ目の理由としては、Autonomous Databaseがコンテナであることです。Oracle Databaseはバージョン12c以降、マルチテナント・アーキテクチャを採用しており、一つのCDB(大きなデータベース)の中に複数のPDB(小さなデータベース)が入っている構成を取っています。Autonomous DatabaseはそんなPDBの中の1つになります(※ADB-Sの場合)。

この構成はCI/CDに最も向いている構成であり、簡単にコピーなどの実施も可能です。さらに稼働しているのはOracle DatabaseのためData GuardなどのDR構成も取れてしまう！
このように12c以降のOracle Database であればDBのコンテナ化もできてしまうのです。
さらにAutonomous Databaseであればサーバレスで運用することが可能です。

以上がサーバレスなサービスの検討において、Autonomous Databaseを選択した理由になります。

3.最後はコスト面での検討！

AP基盤のConatiner Instance、DB基盤のAutonomous Databaseではお客様の「安定稼働」と、「管理/運用工数の削減」の要件をクリアすることができました。
残りは「コスト削減」の要件ですが、今回の場合は以下のようにOCI利用時の料金体系と先程紹介のあったOCIサービスの観点でクリアすることができます。

3-1.サブスクリプションモデルの活用

サブスクリプションモデルの活用により、利用料に応じた課金体系となりコストの最適化が可能となります。

• 決め手となったポイント
  • ピーク時とピークアウト時に合わせたリソース増減が可能な点
  • Oracle Databaseがライセンス費用込みで利用可能な点

3-2.リソースの最適化によるランニングコストの低減

運用の自動化が可能となるサーバレスなサービスを利用することで、リソースの最適化が可能となり、ランニングコストを低減できます。

• 決め手となったポイント
  • サーバレスなサービスの利用によりリソースの自動スケーリングが可能な点
  • パッチ適用の自動化や機械学習機能による障害の事前予防が可能な点
  • サーバレス化に伴い仮想マシンの管理が不要な点

3-3.障害/メンテナンス工数の削減

運用の自動化が可能なとなるサーバレスなサービスを利用することで、障害/メンテナンス工数の削減が可能となります。

• 決め手となったポイント
  • サーバレスなサービスの利用による物理障害における対応をクラウドベンダにオフロード可能な点
  • 障害の自動検知及び自動修復が実行可能な点
  • パッチ適用及びトラブルシューティングが自動で実行可能な点

以上の観点から「コスト削減」もクリアとなり、すべての要件の検討が終了しました。

最後に

いかがでしたでしょうか。
以下が今回のアーキテクチャ図です。

今回ご紹介したクラウド移行は、APだけでなくDBにおいてもコンテナを用いてサーバレス化を実現できるものとなりました。DBまでもがコンテナとして利用できるのはオラクルならではの技術だと思います。

今回の案件同様、サーバレス化による自動化の恩恵を受けたいと考えられている方には、今回ご紹介した技術は最適なものであると言えます。

今後同じ悩みを持たれている方のご参考になれば幸いです。

参考文献

• OKE(Oracle Contaoner Engine for Kubernetes)関連サイト

• OCI Container Instance関連サイト

• Oracle Autonomous Database関連サイト

• Oracle Exadata Database関連サイト