クラウドサービスの活用が始まってから10年近くが経過しようとしています。現在では、クラウドの利用を前提としたプロジェクトも数多く見られるようになりました。
クラウドを導入することで得られるシステムの柔軟性は、もはや無視できない要素となっています。
本記事では、クラウドサービスを活用する上で重要な考え方である「クラウドネイティブ」について解説します。他にもメリット・デメリット、構成する技術について詳しく解説しています。
クラウドネイティブとは
クラウドネイティブとは、最初からクラウド環境で動作することを前提にシステムやアプリケーションを開発する考え方を指します。
オンプレミス用に開発されたシステムを単にクラウドに移行するのではなく、クラウドの特性を最大限活用する特徴があります。
例えば、従来の銀行システムをクラウド上に移行しただけのケースは、クラウドネイティブとは呼びません。
最初からコンテナ技術やマイクロサービスを活用して設計されたシステムが、クラウドネイティブに該当します。
CNCFによるクラウドネイティブの定義
「Cloud Native Computing Foundation（CNCF）」は、クラウドネイティブコンピューティング技術を推進する非営利団体です。
CNCFは、クラウドネイティブコンピューティングを以下のように定義しています。
クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミューダブルインフラストラクチャ、および宣言型APIがあります。
CNCFはKubernetesやPrometheusなどのオープンソースプロジェクトの管理・支援、教育プログラムや認証制度の提供などを行っています。
クラウドファーストとの違い
クラウドファーストは、システム構築時にクラウドの利用を優先的に検討する方針を指します。
クラウドファーストの場合、クラウドを優先的に選択しますが、オンプレミスなどの他の選択肢が排除されるわけではありません。
例えば、企業が新しい業務システムを導入する際、まずクラウドベースのソリューション（SaaSやPaaSなど）を検討し、それが要件を満たす場合に採用するというプロセスが考えられます。
クラウドファーストについて詳しく知りたい方はこちらをご覧ください。
クラウド・バイ・デフォルトとの違い
クラウド・バイ・デフォルトとは、システム構築時にクラウド利用を第一候補（デフォルト）として検討する方針です。
日本政府が2018年に策定した「政府情報システムにおけるクラウドサービス利用方針」にも採用されており、公的機関や企業が新しい情報システムを構築する際には、基本的にクラウドサービスを利用することが推奨されています。
クラウドファーストに近い考え方ですが、そもそもクラウドで動くことを前提に考えるクラウドネイティブとは異なります。
クラウド・バイ・デフォルトについて詳しく知りたい方はこちらをご覧ください。
クラウドシフトとは
クラウドシフトとは、オンプレミス環境で運用されているシステムやアプリケーションをクラウド環境へ移行することを指します。
既存システムをそのままクラウドへ移行するだけでなく、新しくクラウドを活用したシステムを構築するケースも含まれます。
クラウドネイティブが注目される背景
クラウドネイティブが注目される背景には、ビジネスのスピードがますます加速し、変化の激しい市場環境に迅速に対応する必要があることがあげられます。
製品やサービスのリリースサイクルは短縮され、柔軟な開発体制が不可欠となっています。
加えて、企業の競争力強化を目的としたDX（デジタルトランスフォーメーション）の推進や、生成AI・ビッグデータを活用した新たなサービスの台頭により、よりスケーラブルなシステム基盤へのニーズを増大させています。
また、アジャイル開発やDevOpsといった先進的な開発手法の普及も、クラウドネイティブの導入を後押ししています。例えば、大手ECサイトではクラウドネイティブ技術を活用することで、アクセス集中に柔軟に対応しています。
アジャイル開発やDevOpsについては、下記の記事もご覧ください。
クラウドネイティブのメリット
次にクラウドネイティブのメリットを解説します。
システム開発スピードの向上
クラウドネイティブアプローチを採用することで、システム開発のスピードが飛躍的に向上します。
従来のアプリケーション開発では、すべての機能が一つの大きなシステムとしてまとめて作られていたため、変更や新機能の追加には多大な時間と労力が必要でした。
しかし、クラウドネイティブでは、アプリケーションを小さな独立したサービス（マイクロサービス）に分割し、それぞれをコンテナ化して管理します。
そのため、各サービスを個別に開発・デプロイでき、全体に影響を与えることなく迅速な更新が可能となります。
例えば、ECサイトにおいて「商品検索」「カート」「決済」などの機能を独立したマイクロサービスとして構築すれば、各機能を並行して開発・改善でき、結果として市場投入までの時間を大幅に短縮できます。
スケーラビリティ（高可用性）
クラウドネイティブアーキテクチャは、需要に応じたリソースの自動調整が可能で、高いスケーラビリティと可用性を実現します。従来のオンプレミス環境では、トラフィックの増加に対応するために物理サーバーの追加が必要で、コストや時間がかかる上、過剰なリソースを抱えるリスクもありました。
一方、クラウドネイティブでは、クラウドプロバイダーのオートスケーリング機能を活用し、アクセスの増減に応じてリソースを動的に増減させることができます。
例えば、オンラインショップがセール期間中にアクセスが急増した場合でも、自動的にサーバーリソースを拡張することで、ユーザーは快適に買い物ができます。
さらに、複数のデータセンターにサービスを分散配置することで、障害発生時にも他のノードが自動的に処理を引き継ぎ、サービスの継続性を確保します。
疎結合であること（アップデートの容易さ）
クラウドネイティブアプローチでは、アプリケーションを構成する各サービスが疎結合で設計されており、これによりアップデートやメンテナンスが容易になります。
疎結合とは、各サービスが独立して機能し、他のサービスへの依存度が低い状態を指します。
例えば、動画配信サービスにおいて、ユーザー認証機能を改善する際、認証サービスのみを更新すれば済み、動画再生や検索機能には影響を及ぼしません。
そのため、システム全体を停止させることなく、部分的なアップデートが可能となり、ユーザーへの影響を最小限に抑えつつ、迅速な改善が行えます。
クラウドネイティブのデメリット
次にクラウドネイティブのデメリットを解説します。
セキュリティや環境設定の難しさ
クラウドネイティブは柔軟性が高い反面、セキュリティや環境設定の範囲が広がるため、とことん突き詰めて設定しようと思えば際限がありません。
クラウドサービスのプラットフォームと社内システムの間でセキュリティ責任の分界点が曖昧になることが多く、どこまで対策を講じるべきか判断が難しい場合があることも設定に際限がなくなる理由です。
例えば、アクセス制御やデータ暗号化などの設定を怠ると情報漏洩のリスクが高まります。
また、クラウドネイティブ環境では頻繁に変更や更新が行われるため、新たな脅威への対応も継続的に求められます。
エンジニアに求められる知識とスキルが多い
クラウドネイティブ環境を効果的に活用するためには、エンジニアに高度な技術力が求められます。
コンテナ技術やマイクロサービス、サービスメッシュなどの新しい概念を理解し、それらを適切に運用できるスキルが必要です。
しかし、こうした知識を持つエンジニアはまだ不足しており、人材確保や育成が課題となっています。
例えば、専門知識を持つエンジニアが退職した場合、その後に引き継ぐ人材がいないため、引き継ぎが難しい場合があります。
また、人材不足により外部委託を余儀なくされ、コスト増加につながるケースもあります。
クラウドネイティブを構成する技術
次にクラウドネイティブを実現するための技術を解説します。
コンテナ
コンテナは、アプリケーションのコードや必要なライブラリを一つのパッケージにまとめ、仮想化する技術です。
従来の仮想マシンと異なり、OS全体ではなく、必要最小限の実行環境だけを仮想化するため、軽量で起動が速く、リソース効率に優れています。
詳しくはこちらの記事をご覧ください。
マイクロサービス
マイクロサービスは、大規模なアプリケーションを小さなサービス単位に分割し、それぞれを独立して開発・デプロイする設計手法です。
特定の機能に問題が発生しても他の部分に影響を与えずに修正や機能追加ができます。
詳しくはこちらの記事をご覧ください。
サービスメッシュ
サービスメッシュは、マイクロサービス間の通信を管理し、安全に連携させる仕組みです。
各サービス間の通信をプロキシで中継し、トラフィック制御や負荷分散、セキュリティ強化などを行います。
宣言型API
宣言型APIは、システムやアプリケーションが「求める状態」を伝え、その状態を自動的に維持する仕組みです。
従来の命令型APIでは手順ごとに操作を指示する必要がありましたが、宣言型APIでは目標状態だけを指定すれば、自律的にその状態へ到達します。
イミュータブルインフラストラクチャ
イミュータブルインフラストラクチャとは、一度構築した環境には変更を加えず、新しい環境を構築して置き換える手法です。
オンプレミス環境では更新のたびにサーバーを廃棄して、手配し直すということは現実的ではありません。
しかし、この方法では常にクリーンな環境で運用できるため安定性が向上します。
例えば、本番サーバーで直接変更する代わりに、新バージョンのサーバーを構築して切り替えて更新作業を行うことができます。
クラウドネイティブを活用した事例
次に実際にクラウドネイティブを活用した事例をご紹介します。
日本コープ共済生活協同組合連合会による共済マイページの開発
＜課題＞
日本コープ共済生活協同組合連合会では、多様な利用者ニーズに応じたアプリケーションを迅速かつ柔軟に提供することが課題となっていました。
従来のWebシステム基盤では、サーバー単位でしか設定変更ができず、変更作業に手間と時間がかかっていたため、開発スピードや拡張性に限界がありました。
＜効果＞
クラウドネイティブ技術を活用し、Red Hat OpenShift Container Platform上にコンテナベースの新たな基盤を構築。
アプリケーションごとにコンテナを分けることで、環境ごとの設定や構成変更が容易となり、自由度が大幅に向上しました。
マルチベンダー体制でも開発スピードが加速し、サービスの立ち上げ期間を大きく短縮。
また、利用状況に応じてリソースを柔軟にスケーリングできるため、アベイラビリティ（可用性）の改善とともに、コスト削減にもつながっています。
Spotifyによる音楽ストリーミングサービス
＜課題＞
世界中で月間2億人以上のユーザーを抱えるSpotifyでは、急激なアクセス増やさまざまな開発ニーズへの対応が求められていました。
従来の自社製コンテナオーケストレーションシステム（Helios）では、インフラ管理に多くの工数がかかっていたため、Spotifyは業界標準であるKubernetesへ移行することに決めました。
＜効果＞
マイクロサービス化されたサービス群を柔軟にスケーリングし、オートスケーリング機能やリソース最適化により、高トラフィックにも自動対応できる体制を整えました。
エンジニアはリソース管理から解放され、機能開発に専念できるようになりました。
また、サービスのデプロイ時間も従来の約1時間から数分に短縮され、開発のスピードと自由度が飛躍的に向上しました。
現在は1秒あたり約1,000万リクエストを処理する大規模サービスも安定稼働しています。
PayPay社によるキャッシュレス決済
＜課題＞
短期間で市場シェアを獲得する必要があったPayPay社は、わずか3ヶ月で3,300万人以上の登録ユーザーを持つQRコード決済サービスの立ち上げを目指しました。
しかし、従来のオンプレミスではこのスピードに対応できず、柔軟性・拡張性に優れた基盤が求められていました。
そこで、同社はAWS上にマイクロサービスアーキテクチャを採用したクラウドネイティブな分散システムを構築。
＜効果＞
60以上のサービスをKubernetesで個別に管理し、多国籍のエンジニアチームが協力して高速開発を実現しました。
その結果、急増するトラフィックにも自動スケーリングで対応でき、安定性と拡張性を両立しました。
出典： 伊藤忠テクノソリューションズ株式会社「C-Native」事例紹介
株式会社スリーシェイク（ブログ）
AWS（アマゾン ウェブ サービス）導入事例
（まとめ）これからの開発はクラウドネイティブに考えて設計しよう
クラウドネイティブは、クラウド環境を活用してビジネススピードの向上と業務効率化ができる考え方です。
コンテナやマイクロサービス、サービスメッシュなどの技術を活用することで、高いスケーラビリティや柔軟性を実現しています。
一方で、高度な技術力が必要であることやセキュリティ管理の課題も存在します。
事例からも分かるように、クラウドネイティブは業界を問わず大きな価値があります。
クラウドネイティブを実現するには従来のシステム開発とは異なるやり方を取り入れることになるので、考え方を変える必要があるでしょう。
TD SYNNEXでは、クラウドネイティブなアプリケーション開発支援を行っております。
詳しくは、お気軽にお問い合わせください。
［筆者プロフィール］
佐々木
テクニカルサポート出身のITライター。Windows Server OS、NAS、UPS、生体認証、証明書管理などの製品サポートを担当。現在は記事制作だけでなく、セキュリティ企業の集客代行を行う。
