メインメージ

クラウドネイティブとは?

CNCF

Cloud Native Computing Foundation (CNCF)」はThe Linux Foundationの下で運営されています。クラウドネイティブソフトウェアの持続的なエコシステムの構築を目的とし、コンテナ技術の推進、関連するテクノロジ業界の足並みをそろえるために2015年に創設された財団です。

クラウドネイティブとはクラウドの利点を徹底的に活用することです。「クラウドネイティブ」という単語の捉え方は、人それぞれ理解や解釈が異なる部分もあり、またクラウドサービスの成熟と共に少しずつ変化してきています。現在、最も基本的な考え方としては、「クラウドサービスを利用してソリューションを設計する事」と言われています。クラウドの利点を徹底的に活用する事によって、超高速な開発環境への対応や、高度な運用自動化などを実現する事が可能となります。

クラウドネイティブ化

「クラウドネイティブ」とは、単にクラウドサービスを利用すれば良いという事ではありません。例えば、現在オンプレミスの環境で稼働中のシステムがあったとして、これを単純にクラウドサービス上に移行したとしても、これは「クラウドネイティブ化」とは言えません。「クラウドサービスを利用してソリューションを設計する事」という考え方が基本とされていますが、これは要件のほんの一部でしかなく、真の「クラウドネイティブ化」を目指すには、これまでとは考え方が異なる「クラウドネイティブアーキテクチャ」を採用し、クラウドサービスの特性や利点を最大限に享受できる思想・設計に変更していく必要があります。また、これは技術面に限った話だけではなく、アジャイル開発やDevOps等の概念にて提唱されている通り、運用までのプロセスや組織・文化などにおいても、敏捷性や柔軟性を持たせる事が必要です。

クラウドネイティブに移行するメリット

クラウドネイティブに移行するメリットとしては、以下のようなものがあげられます。

項目 説明
スケーラビリティ アプリケーションをネイティブなクラウドサービス上で稼働させるので、
自動スケーリングや負荷分散機能を直接利用できます。
パフォーマンス パフォーマンスと同様に、自動スケーリングや負荷分散機能など、
クラウドサービス上のネイティブ機能を活用する事により高いパフォーマンスを実現できます。
効率性 基盤リソースを効率良く活用できるようになり、
運用コストの削減やWEBアプリケーション等のパフォーマンスの向上につながります。
コスト 実際の消費リソースに対して課金が発生するクラウドサービスにおいては、
効率性が高まれば、毎月の請求額は少なくなります。

上記以外にも、クラウド利用を前提として設計されたシステムと、敏捷性をもった体制で開発・運用する事により、短期間で確実なリリースが可能となります。

クラウドファーストとクラウドネイティブの違い

「クラウドネイティブ」と似たような単語として、「クラウドファースト」があります。昨今では、「クラウド・バイ・デフォルト」という言葉も良く耳にします。それぞれの用語は一般的には、以下のような意味で使われています。

項目 説明
クラウドファースト システム構築等を行う際、クラウドサービスの利用を「優先」する
クラウド・バイ・デフォルト システム構築等を行う際、クラウドサービスの利用を「第1候補」とする

上記の二つについては、いずれもクラウドを優先的な選択肢としており、同じような思想のもだと理解できます。「クラウドサービスの利点を最大限に活用する」という意味をもつクラウドネイティブの概念とは、異なります。

クラウドネイティブアーキテクチャの定義

クラウドネイティブを実現する為には、クラウドの利点を最大限に活用する思想・技術を採用する必要があります。クラウドネイティブアーキテクチャの定義については、様々なものが発表されていますが、非営利組織として2015年に設立された「Cloud Native Computing Foundation(CNCF)」における定義が一般的に多く引用されています。

クラウドネイティブ技術の定義
クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがあります。これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。
【引用】CNCF Cloud Native Definition v1.0(Github)

また、クラウドネイティブ化の指針としての、「Cloud Native Trail Map」や、クラウドネイティブなシステムを実現するプロダクトやOSS等を俯瞰した「Cloud Native Landscape」等も、も同じくCNCFから公開されており、実装計画の策定の際には、これらの情報をを参考に進めて行く事が推奨されています。なお、CNCFの情報は更新頻度が早いので最新の情報は以下のリンクから確認できます。
【参考】Trail Map
【参考】CNCF Cloud Native Interactive Landscape

クラウドネイティブアプリケーション開発のアーキテクチャ

クラウドネイティブの実現の為にはアプリケーション中心の設計思想が必要となってきます。コンテナやマイクロサービスなど最適化されたアーキテクチャを考慮して設計・開発されたアプリケーションは、クラウドリソースの利用効率が約70%も向上すると言われています。また、これらの手法を取り入れることにより、アジャイル開発、DevOps等の概念で提唱されている開発高速化の実現や確実なリリース、運用自動化などビジネスのスピードアップにもつながる要素となります。

クラウド環境で開発されたアプリケーション

クラウドネイティブはDevOpsの運用手法やアジャイルなどの開発手法の中で、クラウドの良いところを取り入れ運用効率化や開発最適化を重視して取り組みます。

クラウドネイティブアプリケーションとは?

クラウドネイティブアプリケーションとは、最初からクラウド環境上で動作する事を前提としたアプリケーションを指します。クラウドネイティブな思想・設計・技術を採用する事により、スケーラブルでパフォーマンスが高い、より堅牢なサービスが実現できます。クラウドネイティブアプリケーションの開発においては、従来とは異なるアプロ―チが必要になります。

クラウドネイティブアプリケーション開発

クラウドネイティブなアプリケーションの設計には、いくつかの基本的は考慮事項があります。ここに挙げる項目や方法論は、最終的にすべてを満たさなければならないという訳ではありませんが、より多くの事項を考慮する事により、成熟度の高いシステム構築が可能となります。

項目 内容
測定 通信遅延やシステム障害、リアルタイムでアプリケーションのパフォーマンスを
監視/測定する仕組みなどを追加する必要があります。
測定はシステム設計上、他の考慮事項にも影響するので、最優先でアプリケーションに組み込む事により、
より大きなメリットが享受可能です。
セキュリティ すべてのアプリケーションにクラウドネイティブなセキュリティアーキテクチャを組み込みます。
クラウドベンダーが提供するサービス、サードパーティのサービスなどを利用し、
アプリケーションのセキュリティを強固に保つ事により、悪意のある攻撃やセキュリティ侵害が発生した際の
影響範囲を最小に抑える事が可能です。
並列処理 スケールアップ等が発生した際に必要なパフォーマンスが発揮できるよう、
個別の処理が多数回並行して実行できるアプリケーションを開発する必要があります。
復旧性 システム障害が発生した際に、アプリケーションが如何に規模を縮小せず
実行し続けられるかを考慮した設計・環境で実行する必要があります。
イベント駆動 イベントを分析して次のアクションを実行する仕組みを備えたアプリケーション開発が推奨されます。
障害発生時の復旧の為の処理や、セキュリティ評価、スケーリングなどが挙げられます。
また、イベントをログとしてすべて記録しておく事により、将来のさらなる高度な自動化の実現につながります。
将来の有効性 今後のイノベーションを考慮し、将来に渡ってアプリケーションが
成熟度を増しながら進化し続けられるよう考えておく事が必要です。

クラウドネイティブアーキテクチャ

クラウドネイティブアーキテクチャは「クラウド独特の特徴に合わせてシステムアーキテクチャをどう最適化すべきか」とGoogleCloudでは5つの原則を掲げています。

原則 概要
設計に自動化を組み込む インフラストラクチャ自動化により人力運用よりも遥かに早くシステムの修復やスケーリング、デプロイが実行可能
状態をスマートに処理する 「スケーリング」「修復」「ロールバック」「ロードバランシング」を基本に
可能な限りコンポーネントをステートレスにする
マネージドサービスを選ぶ 「オープンソースまたはオープンソース互換のマネージドサービス」「運用上のメリットが大きいマネージドサービス」
「それ以外の全て」の3種類からコストだけではなくスキルの観点からも見て、
ポータビリティと運用上のオーバヘッドのどちらを取るかを見極め選定する。
多層防御を実践する インターネット接続されたサービスを起源として外部・内部の区別なく実践する
アーキテクチャを常に考える ITシステムの進化・成長・対応のためには、存続し、息を吹き込み、変化する必要がある

【参考】クラウドネイティブアーキテクチャ、5つの原則(Goolge Cloud)

またクラウドネイティブなアプリケーション開発には、クラウドネイティブなアーキテクチャを積極的に採用する事が必要です。ここでは現在広く利用されているものや、前述のCNCFにて定義されている代表的なものを紹介します。

コンテナ

コンテナとは、コンテナ型仮想化技術を利用し、複数のアプリケーションで同じOS、カーネルを共有し、アプリケーションのプロセスを独立させる方法です。アプリケーションとその依存関係を丸ごとパッケージ化する事により、環境間での移動などが発生した際も変更なしで実行できる為、設定、テスト等に関する作業時間を大幅に削減する事が可能です。
共有のOS、カーネルを複数のアプリケーションで共有するという点が、従来のサーバ型仮想化技術との大きな違いとなります。因みに従来の仮想化技術とコンテナの違いは以下のページで説明をしていますので御覧ください。

サーバ型仮想化とコンテナ型仮想化

コンテナには、以下のような特長があります。

  • OSと分離されている為、起動が迅速(秒単位で起動)
  • サーバ型仮想化と比較するとプロセッサやメモリ等のリソース消費量が少ない
  • 異なる環境への可搬性が高い

また、コンテナ型アプリケーションは、ホストOSの状態が、その上で稼働するすべてのコンテナに影響するので、セキュリティ対策を検討する際には重要な要素になりますので注意が必要です。ここからは、コンテナイメージや、それらの集合体であるコンテナ群の管理に関するソフトウェアや製品についていくつか具体的なものを紹介します。

Docker

Dockerは、2013年にDocker社からリリースされたLinux環境ベースのコンテナ管理ソリューションです。アプリケーションを開発・転送・実行する為のオープンなプラットフォームとして開発者を中心に広まりました。今では、コンテナイメージ管理のデファクトとなっており、コンテナ型仮想化を実現する管理ソフトウェアとして世界的に広く利用されています。Community Edition(CE)は無料で利用する事が出来ます。
【参考】Docker公式サイト:https://www.docker.com/

Kubernetes

KubernetesはDockerコンテナイメージのオーケストレーションツールとして、Google社が設計・開発したオープンソースです。アプリケーションの正常性確認、アプリケーションインスタンスの複製、自動スケーリング、アップデートの展開、負荷分散、リソース監視など、非常に多くの機能を備えています。
【参考】Kubernetes公式サイト:https://kubernetes.io/ja/

OpenShift

OpenShiftは、Kubernetesの機能を拡張し、一般企業等でも簡単に扱えるようにRedHat社によってパッケージされたソフトウェアです。管理者、開発者それぞれにコンテナ技術やKubernetesの深い知識が無くても開発、運用ができるようになっています。一般企業では、Kubernetesをそのまま利用するのではなく、このような製品を活用する事も推奨されています。
【参考】OpenShift公式サイト:https://www.redhat.com/ja/technologies/cloud-computing/openshift

サーバレス

サーバレスとは、サーバの容量を気にする事なくリソースを利用できるサービス形態の事です。インフラを一切考慮する事なく、必要な時にアプリケーションのコードが実行され、起動から停止までの全てをクラウドベンダーが提供するサービスに任せる事が出来ます。クラウドサービスを利用する上で、最もリソース効率が良いのもサーバレスサービスと言われています。代表的なサーバレスサービスには、AWSの「Lambada」や、Azureの「Azure Functions」などがあります。
【参考】AWS Lambada公式サイト:https://aws.amazon.com/jp/lambda/
【参考】Azure Functions公式サイト:https://azure.microsoft.com/ja-jp/services/functions/

サーバレスサービスを利用する事により、サーバ構築や管理、運用等に煩わされる事がなくなり、開発者としては、本来の役割であるコードの記述という業務に集中できるというメリットも生まれます。また、コスト的にも一般的なクラウドサービスが消費リソースに対して課金されるのに対して、サーバレスサービスは、コードの実行時間に対して課金されますので、コストを抑えつつ、高可用性でスケーラブルな設計が可能になります。
なお、サーバレスサービスも、前項のコンテナも技術的にはコンテナ型仮想技術が使われていますので、混同される事も多いようですが、概念としては異なるものとなります。

特長 管理対象
コンテナ あくまでもインフラとしての仕組みを提供 コンテナイメージやコンテナ群の管理
サーバレス インフラとは完全に切り離し、プログラムが動く事だけを意識 ソースコードのみ

マイクロサービス

マイクロサービスとは、アプリケーションを構成するサービスや機能を独立可能な単位に分割してデプロイし、API等のネットワーク経由で連結する設計思想の事です。これまでのアプリケーションの一般的な設計パターンは、モノリシック(一枚岩)と呼ばれ、リソース、プログラム、実行環境などがすべて1箇所に集約されていました。この場合、機能追加やテストの実施がしづらく、変更作業にもシステム全体のリスクを考慮する必要があり、現在の高速な開発サイクルには不向きでした。一方で、マイクロサービスの設計思想に基づいたアプリケーションは、機能単位で小さく分割したサービスの集合体なので、開発、テスト、リリースを独立して実施できるようになり、拡張性や敏捷性が大幅に向上します。また、可用性においても、ひとつのサービスに障害が発生したとしても、該当の領域を切り離す事により、システム全体を止める事なくサービス継続可能となります。

モノリシックとマイクロサービス

イミュータブルインフラストラクチャ

イミュータブルインフラストラクチャとは、「不変(イミュータブル)なインフラ」を意味しています。一度構築して稼働を開始したインフラには、一切変更を加えない運用思想を指しています。従来のインフラ運用では、稼働中のインフラに対してバージョンアップやパッチ適用などの変更を実施していましたが、イミュータブルインフラストラクチャは、稼働中のリソースは破棄し、変更済みのリソースに入れ替えるという手法を取ります。イミュータブルインフラストラクチャは、以下のようなメリットがあります。

  • 変更後のリソースについて、独立したテスト環境で十分に検証した上で本番環境に適用可能
  • 変更後に問題が発生した際も、変更前のリソースに容易に差し戻し可能

コンテナ型仮想化技術やサーバレスサービスを採用した設計パターンにする事により、このような運用が可能となります。

クラウド環境の運用とセキュリティ対策

クラウド運用を可視化

クラウドネイティブな分散型のシステム運用は、障害発生箇所や原因の特定を
予測するために、データの可観測性を高めることが重要です

前項のイミュータブルインフラストラクチャの概要のように、クラウドネイティブな設計や、マネージドサービスを積極的に活用する事によってユーザ側にとって負荷が軽減されるメリットは多々ありますが、マイクロサービスやコンテナなどを多用したシステムでは複雑性が増す為、運用やセキュリティ対策について十分に考慮しておかなければいけない点もあります。
従来のモノリシックなサーバ型システムの場合は、構成もシンプルなケースが多く、対象機器の監視や、障害が発生した際の対処も比較的容易に行う事が出来ました。一方で、クラウドネイティブに基づいたシステムの場合、マイクロサービスに代表されるように個別大量の分散要素があり、それらが相互に通信をしているような環境では、障害発生箇所や原因の特定が非常に困難になるケースも見られ、従来型の監視の仕組みだけでは状態を把握するのは難しくなっています。
クラウドネイティブな分散型のシステムにおいては、オブザーバビリティ(可観測性)という考え方が重要になります。オブザーバビリティとは、障害発生の有無には関係なく、システム全体の振る舞いを把握し、万が一の有事の際に、原因の特定や改善に向けての行動に活用できるデータを取得しておく事を指します。適切なモニタリングを設定し、システム障害やセキュリティインシデントに備えておく事は非常に重要です。オブザーバビリティを備えたシステムにする為には、主に以下の3種類のデータを取得・活用できるようにしておきます。

クラウド運用で取得・活用する3つのデータ

メトリクス

一定間隔で時系列に取得するデータの数値表現の事です。CPU、メモリ、ディスクの使用率、トラフィックなど、指定したコンポーネントのデータを取得します。メトリクスは集計や相関分析等に利用しやすいデータですが、それだけを見てもシステム全体の状態を把握する事は出来ません。

ログ

発生したイベントのタイムスタンプ付きのレコードの事です。比較的容易に事象の特定ができる為、インシデント発生時には、まずログを確認する事が一般的です。ログは、メトリクスの取得とは異なり、アプリケーションのパフォーマンスに影響を与えたり、大量のログが生成された際に格納先のストレージ容量が逼迫するというデメリットもあります。

トレース

分散型のシステムにおいて、エンド・ツー・エンドでリクエストの処理フローをキャプチャする事です。複数のサービスに跨るリクエストを監視する事により、サービス遅延やリソース消費量の増加などの原因が特定できます。
このようなデータを取得・活用しシステム全体の状況を俯瞰して把握できるようにしておく事が重要です。

クラウド環境のセキュリティ対策

セキュリティ対策についても、クラウドならではのリスクがあります。以前はクラウドサービスの利用そのものにリスクがあると感じている企業も多く、データを社外に預ける事に対する懸念の声も多く聞かれましたが、実際には、クラウドサービスベンダーが管理する領域においてのセキュリティリスクは、それほど大きくありません。クラウドサービスを利用するユーザ側が、安全な設定、構成で利用できているかが重要です。実際、アカウントの管理やインタフェース、APIの設定など、ユーザ側の管理領域の設定ミスに起因する情報漏えい事故なども増えていますので注意が必要です。一方でアプリケーションやコンポーネント単位においては、クラウドネイティブな構成にする事により、開発の初期フェーズから個別にセキュリティ対策を実施する事も可能となっており、「セキュリティのシフト・レフト」と呼ばれる対応も容易に出来るようになってきました。

セキュリティ運用サービス

セキュリティ運用サービスは、お客様と予め設定したスケジュールに沿って、当社が定期的な脆弱性診断を実施し、その結果をご報告いたします。また、お客様側でのシステムの構成変更等があった際には、ご要望に応じて都度診断も承ります。診断結果レポートに基づく対策支援や運用代行も当社エンジニアが対応いたしますので、安心・安全なシステム運用が効率的に実施可能です。また、他のセキュリティサービスと組み合わせ、年間を通してセキュリティコンサルやアセスメントも承ります。

まとめ

クラウドネイティブなアーキテクチャを採用し、クラウドネイティブなアプリケーション、サービスを展開する事は、企業にとってビジネスチャンスを逃さないスピード感のある経営が可能となり、大きなメリットがあります。しかしながら、すべてをクラウドネイティブにすることが正解ではありません。クラウドネイティブなインフラデザインや運用設計、セキュリティ対策の中には専門性をもった人員が必要だったり、組織の体制を見直す必要があったり、どの企業でもすぐに導入できる訳ではありません。何を目的にするかをしっかり見定め、必要に応じてクラウドサービスを活用する事が重要です。
アイティーエムでは、経験豊富なエンジニアが、アセスメントにて現状を可視化し、最適なシステム環境のコンサルティングを実施します。インフラデザインから構築、運用、セキュリティ対策までワンストップでご支援する事が可能です。お困りの事があれば是非ご相談ください。