クラウドネイティブ概説（後編）～クラウドネイティブの要素技術～
クラウドネイティブNow
近年『クラウドネイティブ（Cloud Native）』というキーワードが注目されています。クラウドネイティブが注目される背景には、クラウドを活用したシステムやサービスが一般化したことが挙げられるでしょう。
クラウドが登場する前は、サーバーやソフトウェアなどを自社で保有してシステムを運用するオンプレミスが一般的でした。しかし、2006年から2008年頃にかけてGoogle App EngineやAmazon EC2などの著名なクラウドが登場したことを皮切りに普及し、近年では導入までのハードルが低いことやコストパフォーマンスの高さなどから、あらゆる企業でクラウドへの移行が進んでいます。そんな中、単なるクラウド環境への移行から、より積極的にクラウドの利点を活かす（クラウドネイティブ）という動きも活発になってきています。
一方で、「システムが多すぎる、複雑すぎる」「何から手を付ければ良いのか分からない」「期間が足りない」「費用が掛かりすぎる」などの理由により、「クラウドネイティブなんて自分達のシステムには関係ない」と思う企業も多いことでしょう。
確かに一度に全てをクラウドネイティブへ移行するには敷居が高すぎますが、一度に全てを移行する必要はありません。まずは一部機能からクラウドネイティブ技術を導入し、そこから徐々に適用範囲を広げていくことで、最終的にクラウドネイティブを実現することができます。また、必ずしも全てをクラウドネイティブにしなければならない、ということではありません。ビジネスの目的や要件によっては、オンプレミスのシステムの方が適している場合もあります。こういった判断をするためにも、クラウドネイティブとは何か？その実現には何が必要か？を知っておくことが重要です。
前編では、クラウドネイティブに関する背景や考え方、従来のクラウドとの違い、システムに求められる能力にはどういったものがあるかについて解説しました。後編では、マイクロサービスやコンテナといったクラウドネイティブの要素技術について解説します。
クラウドネイティブを実現するための要素技術や手法・ツール
クラウドネイティブを実現するためには、さまざまな要素技術や手法・ツールを利用します。実現したいシステムに合わせて適切な技術を選択することが非常に重要です。
コンテナ（Container）
「コンテナ」はクラウドネイティブを活用する上で基幹となる重要な要素技術で、アプリケーションの動作環境を仮想的に構築する技術の1つです。著名なものに「Docker（Docker, Inc.）」があります。従来のサーバー仮想化技術（VMware、Hyper-V、Xen、Red Hat Enterprise Virtualizationなど）は、1つのホストOS上に「ゲストOS＋アプリケーション実行環境」を有したVM（Virtual Machine：仮想マシン）を複数構築するものです。対してコンテナ技術は、1つのホストOS上に複数の「独立したアプリケーション実行環境」を構築できます。
コンテナ技術は、ゲストOSが必要ないことやOSへの依存度が低いことが特長です。このため、コンテナ自体は従来の仮想環境より軽く、高速に起動することが可能となります。これにより、環境配備への所要時間を短縮することができ、バージョンアップリリースや障害復旧の高速化、ひいては継続的なシステム改善やシステム回復力が向上します。また、少ないリソースで動作できるため、1つのサーバーでより多くのアプリケーションを実行できます。さらに、負荷に応じてコンテナ単位でスケールができるため、効率的にリソースを活用することができます。加えて、パッケージングされたアプリケーションの実行環境は異なる環境への可搬性が高く、別コンテナ環境への移行が容易です。
コンテナ技術について、より詳細に知りたい方は別特集「コンテナとは？」で分かりやすく解説していますので併せてご覧ください。
イミュータブルインフラストラクチャー（Immutable Infrastructure：不変な基盤）
「イミュータブルインフラストラクチャー」は1度構築した環境は変更を加えずに稼働させるという手法で、クラウドネイティブのメリットを受けるための重要なポイントです。
従来は、バージョンアップやパッチ適用が必要な場合は環境に直接変更を加えるため、環境の設定や状態が複雑化することがありました。イミュータブルインフラストラクチャーでは、バージョンアップやパッチ適用が必要な場合は、環境に変更を加えるのではなく環境を丸ごと置き換えるため、環境を常にクリーンな状態で維持できます。これにより環境の複雑さが起因となるシステムの不具合を減らすことができるのです。
イミュータブルインフラストラクチャーは、コンテナが持つ以下のような特長と非常にマッチします。
- 起動が速いため、切り替え時の環境停止時間を短縮できる
- 新環境で問題が発生した場合、以前の環境に簡単にロールバック（置き換え）できる
- 再起動時に変更が保持されないという特性（揮発性）があるため、クリーンな構成を維持できる
マイクロサービス（Microservices）
「マイクロサービス」とは、小さなサービスの組み合わせによって大きなサービスを実現する手法です。従来のシステムでは、それぞれの機能が密接に連携して1つのシステムとして稼働する形態でした。このようなシステムをモノリシック（一枚岩、ひとかたまり）と言います。
一方、マイクロサービスで構築されたシステムは、それぞれの機能が独立した最小の単位（マイクロサービス）で疎な関係に分かれており、各サービスはそれぞれ独立して稼働するようになっています。
マイクロサービスはサービス同士の依存関係が少ないという特長から、次のような効果が得られます。
| サービス単位にリリース | サービス間におけるリリースサイクルの調整を減らすことができ、システム全体での改修スピードが向上する |
|---|---|
| サービス単位にスケール | 必要な分だけを効率的にスケールでき、負荷の変動に柔軟に対応できる |
| サービス単位に技術決定 | 各サービスに最適な基盤や言語を使えるため、適材適所な技術の選択ができる |
| 影響箇所を局所化 | 特定のサービスが停止してもシステム全体には波及しないため、業務が継続でき可用性が向上する |
マイクロサービスについて、より詳細に知りたい方は別特集「今注目される「マイクロサービス（Microservices）」とは」で分かりやすく解説していますので併せてご覧ください。
また、マイクロサービスを実現する際に効果的な技術として、共に語られる要素技術には以下があります。
サービスディスカバリー（Service Discovery）
サービス起動時に自身の情報をレジストリーに登録しておくことで、そこからサービスを特定する技術です。例えば、呼出し対象のサービスが使用するネットワーク上の位置情報（IPアドレスなど）が、スケールにより動的に変更されてしまうようなシステムの場合、この技術を利用することで位置情報の特定ができるようになります。
分散トレーシング（Distributed Tracing：分散リクエストトレーシング）
エンドツーエンドでリクエストを追跡することで、処理の流れを把握するトレーシング技術です。分散した複数のサービスが連動するようなアプリケーションでは、処理状況の把握やエラー原因の特定が困難となります。この技術を利用することで、アプリケーションへのリクエストやトランザクションの経過を観察して、アプリケーションのパフォーマンスに影響するボトルネックやバグなどを正確に特定できるようになります。
サービスメッシュ（Service mesh）
マイクロサービスごとにプロキシーを配置し、プロキシーを経由して他のサービスと通信させることでサービスの依存関係やトラフィックを制御する技術です。この技術を利用することで、アプリケーションに影響することなく可観測性や回復性などを実現できます。なお、このプロキシーは各サービスから独立しており、サービスと並行して実行されることから「サイドカー」と呼ばれます。
コンテナオーケストレーションツール（Container orchestration tool）
複数のサーバーで実行するコンテナ環境の構築や展開および運用負荷を軽減し、効率的な統合管理を実現するツールです。マイクロサービスは文字どおり小さなサービスをたくさん連結させるために構成が複雑になる場合があります。このため、クラウドネイティブ環境の運用にはコンテナオーケストレーションツールの利用が前提となってきています。著名なものに「Kubernetes（Google LLC / Cloud Native Computing Foundation）」があり、複数のサーバーに配置されたコンテナを一括して管理・運用するためのさまざまな機能が提供されています。
- 負荷状況に応じて、配備に適したサーバーにコンテナを展開する
- 異なるサーバーのコンテナを検出し、コンテナ同士の通信を容易にする
- どのサーバーでどのコンテナが起動しているか管理する
- コンテナのスケールを制御する
- コンテナの死活監視を行い、障害時に自動復旧する
コンテナオーケストレーションツールについて、より詳細に知りたい方は別特集「コンテナオーケストレーションツールとは？」で分かりやすく解説していますので併せてご覧ください。
CI/CD
アプリケーションの変更時に自動でビルド&テストを繰り返し、常に本番リリース可能な状態に保つ、または本番環境にリリースする開発手法で、DevOpsの実現に向けた「リリースの自動化」という技術的なアプローチの一つです。CI/CDとは、開発者がソースコードを変更したときに、ビルド＆テストを自動実行する「Continuous Integration：継続的インテグレーション」、ビルド＆テストが通ったアプリケーションケーションを定期的にテスト環境へ配置して、常に本番環境にリリースできる状態にする「Continuous Delivery：継続的デリバリー」、アプリケーションケーションを自動的に本番環境にリリースする「Continuous Deployment：継続的デプロイメント」の略です。
マイクロサービスを適用したシステムでは、開発対象のサービス数が膨大になるため、CI/CDを導入して自動化を進めることで次のような効果が得られます。
| 開発期間の短縮 | 常に自動でテストを行うことにより不具合の早期検出ができ、影響範囲や手戻りが少ないタイミングで修正が可能となる。また、環境構築にコンテナを活用することで、コンテナ起動の速さによるビルド・テスト時間が短縮できる。 |
|---|---|
| テストの信頼性向上 | イミュータブルインフラストラクチャーにより、クリーンな環境で安定したビルド・テストが実施できるとともに、自動テストにより手動テストでは起こりうるテストの実施漏れや手順ミスを減らすことができる。 |
| 属人性の排除 | 特定メンバーしか実施できないといった作業がなくなり、ボトルネックや暗黙知による障害を減らすことができる。 |
これにより、継続的なシステムの改善と品質向上の両立を実現できます。
DevOps（デブオプス）とは
開発スピードと安定運用の両立を狙いとして、開発（Dev）と運用（Ops）が連携して開発を進める手法です。詳細は別特集「クラウドネイティブアプリケーションの要 ～DevOpsとは？～」で分かりやすく解説していますので併せてご覧ください。
クラウドネイティブのまとめ
DX（Digital Transformation：デジタルトランスフォーメーション）を推進するシステムには、クラウドネイティブの活用が非常に効果的です。また、既存システムにおける従来からの課題にも効果が見込めます。
クラウドネイティブを活用することで、システムに「サービスの改善とリリースを素早く繰り返す」、「素早い回復で障害時にもサービスを止めない」、「自動化で運用負荷を軽減する」といった変革をもたらすことができます。
これにより新しい価値創出にビジネスリソースを集中して素早く柔軟に取り組むことができるようになり、エンドユーザーの体験価値を向上させてビジネスの機会損失を防止するといった変革をもたらすことができるのです。
先が読みづらい不確実な世界において、クラウドネイティブの活用は必要不可欠です。しかし、クラウドネイティブで重要なことは、クラウドネイティブの活用を目的とするのではなく、活用して何を実現したいかを明確にすることです。本記事を参考にクラウドネイティブ活用の第一歩を踏み出してはいかがでしょうか？
関連情報
ハイブリッドクラウドのメリットや導入への5つのステップを解説したホワイトペーパーがダウンロードできます。
関連製品・サービス
当社が提供するDX実現の課題にお応えするハイブリットITサービスの詳細は下記ページをご覧ください。
こちらもおすすめ
- クラウドネイティブ本格化で再確認 ～DXレポート解説（前編）～
- クラウドネイティブ本格化で再確認 ～DXレポート解説（後編）～
- ディスラプター（破壊的企業）に打ち勝て！2025年の崖を乗り越え、企業が成長し続けるために必要なこととは？（前編）
- ディスラプター（破壊的企業）に打ち勝て！2025年の崖を乗り越え、企業が成長し続けるために必要なこととは？（後編）
- クラウドネイティブシフトで、ビジネスのアジリティーとスピードを手に入れ2025年の崖を乗り越えろ！（前編）
- クラウドネイティブシフトで、ビジネスのアジリティーとスピードを手に入れ2025年の崖を乗り越えろ！（後編）
- クラウドネイティブ概説（前編）～クラウドネイティブとは？～
- クラウドネイティブ概説（後編）～クラウドネイティブの要素技術～
本コンテンツに関するお問い合わせ
お電話でのお問い合わせ
Webでのお問い合わせ
当社はセキュリティ保護の観点からSSL技術を使用しております。
