こんにちは。データベーステクノロジ 技術部のNです。
先日、弊社インフラエンジニアによる「OCIで学ぶクラウドネイティブ 実践×理論ガイド」の記事を公開しました。今回は、開発エンジニアの視点から、本書について紹介させてもらいたいと思います。
はじめに
普段、私たちはOCI上でSpringBootアプリケーションを開発し、Compute InstanceやMySQL HeatWave、Autonomous Databaseを活⽤したシステム構築を⾏っています。モニタリングやアラートで運⽤監視を⾏い、IPsec VPNでお客様のネットワーク環境と接続するといった開発が中⼼でした。
そんな中、『OCIで学ぶクラウドネイティブ 実践×理論ガイド』をいただき、読む機会に恵まれました。
正直なところ、「クラウドネイティブ」という⾔葉は知っていても、それが具体的に何を意味し、⾃分たちの開発にどう活かせるのかよく理解はできていませんでした。
本書を読み終えた今、率直に感じているのは「これまでの開発スタイルを、もっと良くできる可能性がある」ということです。本稿では、単なる本の紹介ではなく、実際にOCIでシステム開発を⾏っている⽴場から感じた気づきや、今後取り⼊れていきたいと思った点を中⼼にお伝えしたいと思います。
本書の構成
本書は全3部6章で構成されており、400ページにわたる内容ですが、単なる技術解説書ではなく、
⽇本オラクルの現役エンジニアの⽅々が、理論と実践の両⾯からクラウドネイティブを解説されていました。
第1部︓クラウドネイティブを学ぶ
最初の章で、クラウドネイティブとは何か、なぜ今必要とされているのかを丁寧に説明されています。
DevOps、マイクロサービス、Infrastructure as Code、Observabilityといった概念が、具体的にどのような価値を⽣むのかが理解できました。
特に印象的だったのは、クラウドネイティブが単に「クラウドを使う」ことではなく、「クラウドの特性を最⼤限活かす設計思想」だという点です。これまで私たちが⾏ってきた開発は、オンプレミスのシステムをクラウドに持ち込んだような形が多かったのですが、本書を読んで、「クラウドならではの利点をもっと活かせる余地がある」と気づかされました。
第2部︓OCIのクラウドネイティブを学ぶ
OCIの概要や特徴、そしてクラウドネイティブサービスの全体像が体系的に整理されています。
普段使っているComputeやDatabaseだけでなく、OKE（Oracle Kubernetes Engine）、OCI CI(Container Instances)、Functions、API Gateway、DevOps、Streamingなど、多様なサービスが紹介されています。
「こんなサービスもあったんだ」という発⾒が多く、OCIの可能性を改めて認識しました。
特にOKEやDevOpsサービスについては、これまであまり触れてこなかった領域でしたが、本書の解説を読んで「これは使ってみたい」と感じました。
第3部︓ハンズオンで学ぶOCI Cloud Native
最も実践的であったのがこの章です。Terraformを使ったインフラのプロビジョニングから、サンプルアプリケーションのデプロイ、CI/CDパイプラインの構築、監視設定まで、⼀連の流れを体験できる構成になっています。
「理論はわかったけど、実際どうするの︖」という疑問に、具体的な⼿順で答えてくれるのが⾮常にありがたいと思いました。読むだけでなく、実際に⼿を動かすことで理解が深まる作りになっています。
現在の開発課題と、本書から得た気づき
本書を読み進める中で、私たちが⽇々直⾯している開発・運⽤の課題と重なる部分がいくつも⾒つかりました。
Infrastructure as Codeによる構成管理
現在、当社でのインフラ構築は⼿動での作業が中⼼です。
本書で紹介されているOCI Resource Managerは、TerraformをベースにOCIリソースの構築、変更、削除を⾃動化できるサービスです。
興味深かったのは、ソースコードリポジトリのバージョン管理と同期させて環境構築ができる点です。
複数⼈でクラウド環境のリソースをメンテナンスする際に、排他制御やロールバック管理も⾏ってくれるとのことで、安⼼感があります。
また、既存環境からTerraformファイルを作成することもできるようなので、インフラ構築の⾃動化やバージョン管理を始めるハードルが下がりそうだと感じました。これまで「いきなりTerraformで全部書き直すのは⼤変」と思っていましたが、既存環境をベースに始められるなら⼿をつけやすいと思います。
CI/CDプロセスの⾃動化
現在、SpringBootアプリケーションのデプロイは、jarファイルをアップロードしてサービスを再起動する…という⼿動作業が中⼼です。OCI DevOpsサービスを使えば、ソースコードリポジトリにpushすることで、ビルドからテスト実⾏、デプロイまでを⾃動化できます。
OKEやOCI CIを利⽤する際には、リリース時のヒューマンエラーも発⽣しやすそうなので、DevOpsサービスは利⽤する前提で考えたほうが良さそうです。興味深かったのは、DevOpsはコンテナ環境だけでなく、OCIComputeインスタンス等へのデプロイも可能だという点です。 私たちのソース管理環境は、オープンソース版のGitLabをOCI Compute上に構築していますが、そこをトリガーにCI/CDの⾃動化もできるようなので、既存の開発フローに組み込みやすそうでした。
セキュアなビルドプロセス
本書のハンズオンで使⽤されるサンプルアプリケーション「Mushop」では、各マイクロサービス毎にDockerfileが⽤意されており、マルチステージビルドを活⽤しています。これにより、最終的な実⾏環境に不要なファイルやツールを含まないようにしているとのことでした。
イメージの軽量化をすることで、起動やスケーリング時の速度向上、ロールバックの容易さに繋がってくるとのこと。さらにMaven/Gradleの依存関係やソースコードを本番環境に含まないことでセキュリティ⾯でも優れているとのことでした。内部監査で「なぜ本番環境にソースコードが︖」と指摘される可能性もあると思いますので、実施しておくべきだと感じました。
マイクロサービスにおけるセッション管理
マイクロサービスアーキテクチャでは、個々のサービスが独⽴して動作するため、ステートレス（状態を持たない）な設計が基本になると思います。そのため、ログイン状態などのセッション情報は、個別のサービス内ではなく、外部の共通データストアで管理する必要があります。
「セッション管理をどうするんだろう︖」というのが個⼈的に気になっていたポイントでしたが、本書のハンズオンで利⽤するMushopでは、多くのマイクロサービスで利⽤されるオープンソースのインメモリデータストアであるRedisをベースにしたOCI Cacheを使って、各マイクロサービス間でのセッション管理が実現されていました。
これはぜひ実装する際の参考したいと思いました。
認証情報の安全な管理
もう⼀つ気になっていたのが、Autonomous DatabaseなどDBへの接続情報をどう管理するかという点です。
本書では、ADBへの接続情報をセキュアに管理・利⽤する⽅法も紹介されていました。
Autonomous Databaseでは接続情報や資格情報がウォレットファイルとして⽣成でき、これを利⽤することで、ソースコード内から機密情報を排除できます。
また、OCI Vault（キー管理サービス）を活⽤する⽅法もあるとのこと。データベースのパスワードなどの機密情報は、OCI Vaultに「シークレット」として安全に保管ができ、アプリケーションからはシークレットのOCIDなどを参照する設定をすることで、ソースコードや設定ファイルから機密情報を排除できます。
さらに、OKEでの運⽤においては、データベース接続の設定を環境変数やConfigMapなどの外部設定として管理でき、これにより、ソースコードを変更することなく環境に応じた構成の切り替えが可能になるとのこと。
「機密情報や設定情報もOCIの機能でセキュアに管理しつつ、アプリケーションに注⼊できる」という点が確認できました。
データベースサービスの活⽤
フルマネージドサービスとして、Autonomous DatabaseやMySQL HeatWaveを利⽤することで、運⽤コストの低減と可⽤性の向上という点で⼤きなメリットを感じています。これからも引き続き積極的に活⽤していきたいです。
特にAutonomous Databaseは、⼀時的な負荷⾼騰時にも⾃動的にスケールアップして対応してくれるため、運⽤⾯での安⼼感が⼤きいです。
また、本書ではマイクロサービスのトランザクション管理として、MicroTxが紹介されていました。
MicroTxはマイクロサービス間の分散トランザクションを管理する機能で、各マイクロサービス間で⼀貫したトランザクション管理ができるとのこと。OKE & マイクロサービスを採⽤する際には、ぜひ使ってみたい機能だと感じました。
サンプルアプリケーションから学ぶ
本書で使⽤されているMushopは、複数のマイクロサービスからなるシステムで、各マイクロサービスは異なるプログラミング⾔語やフレームワークを使⽤して作成されていました。
書籍前半で説明があったHelidonやMicronautで作成されたサービスに加え、SpringBootやGoで作成されたサービスもあります。マイクロサービスの構成を考える際の参考になり、実際のコードを⾒ることで、理論が具体的にどう実装されるのかイメージしやすかったです。
本書では、マイクロサービスのソースコード管理⼿法として、複数のマイクロサービスを1つのリポジトリで管理するモノレポ⽅式と、各マイクロサービスごとに個別のリポジトリで管理するマルチレポ⽅式が紹介されていました。
Mushopではモノレポ⽅式が採⽤されており、システム全体をまとまって⾒ることができるため把握しやすいと感じました。私たちが開発するシステムの規模感では、少⼈数で全体を⾒ることが多いため、採⽤するならモノレポ⽅式が適していると感じています。もちろん、規模が⼤きくなるとビルドやCI/CDの設定が複雑になる可能性もあるため、状況に応じた判断が必要だとは思います。
お客様へのご提案力向上につながる知見
本書を読んで、お客様への提案の幅も広がりそうだと感じました。
システムの柔軟性と拡張性
お客様の事業成⻑に伴い、システムの負荷が増⼤するケースは珍しくありません。これまでは「スペックの⾼いインスタンスに変更する」「サーバーを増やす」といった対応が中⼼でしたが、クラウドネイティブのアプローチなら、もっと柔軟な対応が可能です。
Kubernetesによる⾃動スケーリングや、マイクロサービスアーキテクチャによる部分的な拡張など、ビジネスの変化に柔軟に対応できるシステムを提案できるようになります。
開発スピード
CI/CDパイプラインの導⼊により、新機能のリリースサイクルを短縮できます。お客様のビジネスニーズに素早く応えられる体制を作ることで、市場での競争⼒強化に貢献できます。
また、Infrastructure as Codeによる環境構築の⾃動化は、新規環境の⽴ち上げ時間を⼤幅に短縮します。
「新しいサービスを試験的に始めたい」といったお客様の要望にも、迅速に対応できるようになります。
運⽤負荷の軽減
Autonomous Databaseなどのマネージドサービスを活⽤すれば、データベースの運⽤作業を⼤幅に削減できます。お客様の運⽤担当者が、定型作業から解放され、より価値の⾼い業務に集中できる環境を提案できます。
また、OKEによるリソースの効率的な配置により、インフラリソースを最適化できます。必要な時に必要なだけリソースを使う、というクラウドネイティブの利点を最⼤限活かせます。
技術的な安定性と保守性
マイクロサービスアーキテクチャは、システムの⼀部に問題が発⽣しても、全体への影響を最⼩限に抑えられます。また、各サービスが独⽴しているため、メンテナンスやアップデートもやりやすくなります。
お客様にとって、「システムを⽌めずに改善を続けられる」ことは⼤きな価値です。ビジネスの継続性を確保しながら、システムを進化させていける提案ができます。
おわりに
『OCIで学ぶクラウドネイティブ 実践×理論ガイド』は、私たちにとって、OCIのサービスをさらに活⽤するための道標となる⼀冊でした。
可⽤性の⾼い、安定したシステム運⽤を⾏うために、OCIの様々なサービスが実例とともに学べました。開発や構築の⼿間を減らすことでお客様のコスト削減にもつながりますし、システムを安定して運⽤することで、お客様の⽇々の業務も安定して進めていただけることにつながります。
本書の価値は、単なる技術解説にとどまりません。「なぜクラウドネイティブが必要なのか」という本質的な問いから始まり、具体的なサービスの使い⽅、実践的なハンズオンまで、⼀貫したストーリーで学べる点が優れています。
クラウドネイティブは、開発の⽣産性を向上させ、運⽤負荷を軽減し、お客様のビジネス価値を⾼めるための、現実的なアプローチだと感じました。今回の書籍から得られた知識を活かして、今後のシステム開発やインフラ構築に取り⼊れていきたいと思います。
OCIでシステム開発を⾏っている技術者の⽅々、特に「クラウドネイティブに興味はあるけど、どこから始めればいいかわからない」という⽅には、ぜひ本書を⼿に取っていただきたいです。理論と実践のバランスが取れた、⾮常に実⽤的な⼀冊になると思います。
