• HOME
  • お役立ち記事
  • クラウドネイティブが求められる理由と知っておきたい技術群
main-visual

クラウドネイティブが求められる理由と知っておきたい技術群

2022/09/15

近年注目されている、ソフトウェア開発において「マイクロサービス」「アジャイル開発手法」「DevOps」は重要なキーワードですが、それらと密接に関わる言葉に「クラウドネイティブ」があります。
「クラウド対応」とはどのように異なるかご存じですか?今後は、多くのスタートアップ企業や新規開発の現場で、クラウドネイティブの考え方や、関連する技術への知見が求められます。
この記事では、クラウドネイティブの特徴と関連する技術群の「コンテナ」や「サービスメッシュ」などについて詳しくお話ししていきます。
「スタートアップの案件に参画したい」「エンジニアとして早くスキルアップさせたい」方は、クラウドネイティブについて自分なりの意見を主張できるように整理しておきましょう。

目次

  1. クラウドネイティブとは
  2. なぜ今、クラウドネイティブなのか
  3. クラウドネイティブ技術群
  4. クラウドネイティブ導入のステップ
  5. まとめ

クラウドネイティブとは

クラウドネイティブの定義

クラウドネイティブとは、「クラウドで動作させることを前提とし、クラウドの特性を最大限活かすように設計・開発されたシステムのこと」を指します。
「ネイティブ=本来の、生まれつき」という言葉の通り、最初からクラウドで運用することを指すので、オンプレミスからクラウドへの移行や、一部の工程でクラウドのプラットフォームを活用するといった「クラウド対応」とは別のものとなります。
クラウドネイティブ推進団体「CNCF(Cloud Native Computing Foundation)」によって、以下のように定義付けされています。

<クラウドネイティブの定義>

「クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、
スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。
このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミューダブルインフラストラクチャ、および宣言型APIがあります。」

引用:「CNCF Cloud Native Definition v1.0」

クラウドネイティブに関連する技術群については、後ほど詳しく説明します。

CNCFとは

クラウドネイティブ推進団体「CNCF」は、2015年7月にLinux Foundationのプロジェクトの1つとして創設された財団です。
それまではクラウドの使用を前提とするアーキテクチャについて明確な定義はありませんでしたが、CNCFによって共通認識として広まりました。
IBMやRed Hatなど、多くのコミュニティやベンダーが活動を支援しています。

類語との違い

クラウドネイティブが出てくる以前にも、類似のキーワードは存在しました。それぞれの違いを見てみましょう。

クラウドファースト

システムを構築する際に、クラウドの利用を優先することを「クラウドファースト」と言います。
従来、システムが稼働してからストレージやサーバーに変更を加えることは少なかったためオンプレミスが主流でした。
しかし、サービスを時代の変化に柔軟に順応させる必要が出てからは、迅速に開発を進められ、リソースも豊富なクラウドが優先的に活用されるようになりました。

クラウドバイデフォルト

「デフォルト=初期設定」の意味の通り、クラウドファーストから一歩進んだものとして「システム構築の際には、クラウドの利用を第一候補とすること」という考えがクラウドバイデフォルトです。
2018年6月、政府によって「政府情報システムにおけるクラウドサービスの利用に係る基本方針」にて「クラウド・バイ・デフォルト原則」が発表されました。
内閣府は、 IoT・ビックデータ・AIに代表されるテクノロジー空間と現実空間を融合させることが目指すべき社会として「Society 5.0」を提唱しましたが、実際のクラウド導入にはセキュリティ面を含めて様々な対策が必要になります。
クラウド・バイ・デフォルト原則は、そういった対策について提唱されたものになります。
クラウドネイティブは、クラウドバイデフォルトからさらに踏み込み、クラウドの利点を活かす設計がなされる仕組みとなります。

なぜ今、クラウドネイティブなのか

オンプレからクラウドへの移行の流れ

2000年代半ばのオンプレミスが主流の頃にクラウドが登場し、クラウドへの移行が急速に進んだことで、IaaSやPaaS、SaaSのようなクラウドサービスが多く普及しています。
もはや「クラウドを使うかどうか」ではなく、「クラウドをどう活かすか」に論点が移行しています。

求められるシステムの柔軟性

サービスのSaaS化

オンプレからクラウドへ移行する場合、ハードウェアをクラウド化した後に自社でシステムを構築するケース(IaaS)が多くありました。
サービスに合わせてソフトウェアをカスタマイズできるというメリットがありますが、運用負荷やセキュリティリスクが重くなる懸念があります。
ソフトウェアとハードウェア全てをクラウド化するSaaSでは、初期費用や管理費、維持費が不要なことや自社にインフラを抱える必要がないこと、オンデマンドで必要なリソースを確保できること、といったクラウドの利点を活かした開発が進められます。
オンプレとクラウドを連携させるハイブリッドクラウドや、SaaS同士を連携するAPIを活用すれば、企業や開発したいサービスに合わせて対応が可能です。
SaaSの代表的なものにAWSマネージドサービスがありますが、それについては後ほどご説明します。

アジャイル開発手法やDevOpsの浸透

アジャイル開発手法は、短期間で開発から運用までのサイクルを回し、効率的に高品質なサービスを作ることを目指す手法です。
そして、迅速に改善を重ねるには現場の開発担当と運用担当が密に連携を取りながら成果を求めていく必要があり、その考え方をDevOpsといいます。
クラウドネイティブを実践している開発環境では改善や修正をスピーディに行えるため、ビジネスの変化に迅速に対応しなければならないアジャイル開発手法やDevOpsに適していると言えます。

クラウドネイティブ技術群

CNCFの定義では、クラウドネイティブを進める上で必要な技術群として「マイクロサービス」「サービスメッシュ」「宣言型API」「イミュータブルインフラストラクチャ」があるとしています。

マイクロサービスと関連技術

マイクロサービスとは、ソフトウェア全体が大きな1つのモジュールとして開発するモノリシックと違い、小さなサービスに分割させ、それらを連携させて一つの大きなソフトウェアを構築する開発手法です。
実現にはコンテナやオーケストレーター、サービスメッシュなどの技術群の活用が不可欠です。

コンテナ:Docker

従来の仮想マシンと同様に、マイクロサービスを構成する個々のサービスの実行環境として機能するものをコンテナといいます。
仮想マシンではゲストOSやハイパーバイザーが必要でしたが、コンテナはホストOSで直接アプリケーションを実行するため、軽量で物理マシンのCPUやメモリへの負荷が少なく動作ができるので、処理速度が速いというメリットがあります。
また、バージョンやディストリビューションの異なるOS環境も再現できるため、開発環境と本番環境が異なる場合で不具合が生じることも避けられます。
加えて、コンテナ同士はサンドボックスの技術によって分けられるため、多くのユーザーがアクセスする場合でも高いセキュリティ性が保てることも特徴的です。
コンテナの代表例として「Docker」は、聞いたことがある方も多いのではないでしょうか。

オーケストレーター:Kubernetes・OpenShift

複数のコンテナやシステム、アプリケーションなどの管理・調整を行うプラットフォームを「オーケストレーター」といいます。
様々な楽器を演奏する奏者をまとめて調和した音楽になるように指揮する「オーケストラ=管弦楽団」のような役割をすることが、語源の由来となっています。
代表的なものに、Dockerコンテナのアプリケーションのデプロイ、スケール、管理の自動化を担う「Kubernetes」があります。
2017年にDocker社からCNCFに寄贈されてからは、CNCFが管理しています。
Kubernetesは、Googleのプラットフォームで提供されるGKEやAmazonのAWSで提供されるEKS、そしてMicrosoftAzureで提供されるAKSなど世界中のクラウドベンダーに採用されているので、デファクトスタンダードとして認識されています。
一方で、Kubernetesは3か月ごとにマイナーバージョンのリリースを行い、リリース後は9か月でサポートが終了してしまうといった安定性に欠ける懸念があるため、それを解消するシステムとしてRed Hat社の「OpenShift」も注目されています。
脆弱性やセキュリティ性が高く、Kubernetesと併せて検討されることの多い製品です。

サービスメッシュ:Istio

コンテナ間の通信システムをプロキシ(代理接続するサーバー)を通して互いの依存関係やトラフィックを制御・管理するのが「サービスメッシュ」です。
多数のサービスが複雑に網(=メッシュ)上に繋がっているマイクロサービスで、オーバーヘッドや不整合が起こるのを解決する目的があります。
代表的なサービスメッシュ「Istio」は、Google、IBM、Lyftに共同開発されたオープンソースであり、分散システムのモニタリングやネットワーク障害・セキュリティ対策を行います。
Kubernetesがインフラレベルで機能するのに対し、Istioはアプリケーションレベルで機能するものになります。

宣言型API

APIには「命令型のAPI」と「宣言型のAPI」があるのをご存じでしょうか?
命令型とは、具体的に細かくコマンドを命令していくことで目的を達成するのに対し、宣言型では結果だけを掲示し、細かい動きは自動で実行するものになります。
具体例として、「ロボットに引き出しを開けさせる」を依頼するとしましょう。

<APIの働きの具体例>

【命令型API】
1. タンスの前50㎝まで進む
2. 引き出しの取っ手の位置を計測する
3. 引き出しの取っ手に手を両手をかける
4. 秒速1秒で引き出しを手前に引っ張る
5. ・・・続く

【宣言型API】
1. タンスの引き出しを開いた状態に変更

命令型APIでは、細かく指示出しが必要なうえ、何らかの理由で途中で失敗してしまうと進行できなくなるため、開発者は常に監視しなければいけません。
それに比べて宣言型APIは、最終的に得たい結果を掲示すればよいため、どこかで不具合が生じたとしても、APIが自動でコンテナの調整や起動を行います。
システムが自律的に動作するので開発者の負担が軽減し、開発効率の向上に繋がります。

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

システムの運用時にインフラにパッチ管理を行ったり、設定を変更したりする場合、従来はその都度OSのアップデートや設定変更を行い、再起動を行っていました。
このアップデートをするために稼働中のサービスが中断されたり、アップデートを繰り返したことによる動作不具合が生じたりすることもあります。
そういった懸念を防ぐため、新しいインフラに乗せ替えることで不変の(=イミューダブル)、常に最適な状態をキープできるインフラの活用が進んでいます。
イミューダブルインフラはクラウドに存在し、起動した段階から手を加える必要がありません。アップデートや変更が必要な時には、それを適用済のOSを新規に立ち上げ、本番環境の切り替えと乗せ替えを行います。
古いインフラは破棄され、新しいインフラを稼働させられるので、アプリケーションに無駄な負荷がかかることなくアップデートが可能ということです。
クラウド上にあるからこそ、必要に応じてリソースを確保したり破棄したりできるといった融通性が優れている点が特徴的です。

合わせて覚えておきたい関連技術

CI/CD

マイクロサービスのメリットを活用し、複雑なアプリケーションのビルドやテスト、デプロイは自動化させることが推奨されます。
継続的にビルドやテストを自動化させる「CI=継続的インティグレーション」と、本番環境にデプロイ・リリースまで行う「CD=継続的デリバリー・デプロイ」のパイプラインを構築することで迅速かつ効率的に開発を進めることができます。
具体的には、オンプレミス型CI/CDツールでは「Jenkins」やクラウド型の「CircleCI」、そしてロポジトリツールでは「GitHub」が代表的です。

AWSマネージドサービス

クラウドサービスのIaaS・PaaS・SaaSを活用するに当たって、マネージドサービスの検討は欠かせません。
「マネージドサービス」とは、ソフトウェア・ハードウェアを管理するために必要な回線の接続からストレージの提供、ミドルウェアのインストール、アプリケーションの提供などの管理業務をクラウドサービスに任せることを指します。PaaS・SaaSがそれに該当します。
「アンマネージドサービス」では、ハードウェアの構築はクラウドに依頼しソフトウェアの部分は利用者自身が行うことを指し、IaaSが該当します。
開発したいサービスへの影響度合を考慮しつつ、どこまで依頼するかを検討するといいでしょう。
クラウドサービスの代表格としてAWSの「Amazon Lambda」があります。AWSのマネージドサービスは、セキュリティが強固で情報のブラックボックス化を防げることや、変更に柔軟に対応できるといったメリットがあります。

クラウドネイティブ導入のステップ

クラウドネイティブを定義づけしたCNCFは、導入するまでのステップを「Cloud Native Trail Map」に示しています。

<Cloud Native Trail Map>

1. コンテナ化
2. CI/CD
3. オーケストレーションとアプリケーションの定義
4. 観測性と分析
5. サービスプロキシ、ディスカバリ、メッシュ
6. ネットワーク、ポリシー、セキュリティ
7. 分散データベース/分散ストレージ
8. ストリーミング&メッセージング
9. コンテナレジストリ&ランタイム
10. ソフトウェアディストリビューション

※引用:landscape/README.md at master · cncf/landscape · GitHub

導入にあたって、ステップ1から3まではクラウドネイティブの前提として必要になりますが、それ以降は必要に応じて導入していくものになり、順番も固定的ではありません。
サービスの特性を見極め、「いかに効率的に管理して開発を進められるか」を考慮して進めるといいでしょう。

まとめ

クラウドネイティブは、マイクロサービスやアジャイル開発手法・DevOpsと密接に関わっているため、互いに関連付けて理解する必要があります。
効率性とスピード、そして高品質なサービスの提供には、クラウドのメリットを最大限に活かすクラウドネイティブの考え方は欠かせませんが、それには開発者にも高い技術力が求められます。
マイクロサービスと同様、サービスに合ったクラウドツールを検討するには、開発から運用まで対応できる高スペックなエンジニアが必要になります。
今後は、クラウドネイティブの知識があることはもちろん、導入に関わったことがある方やクラウドを活用した現場に携わった経験が豊富なエンジニアが求められます。
AWSを活用した案件に携わったことがない方でも、特徴を理解しサービスとの相性を判断できるようになっておくとキャリアアップに繋がります。
「具体的にどんなスキルがあれば活躍できるのか知りたい」「クラウドネイティブを意識している企業で働きたい」と思ったら、ぜひエージェントに相談してみてくださいね。

お役立ち記事一覧へ

・フリーランスだけど安定して働いていきたい
・年収アップするためにはどうしたらいいのだろう

気になることは、どんな些細なことでも
お気軽にご相談ください。

IT業界において経験豊富な弊社キャリアサポーターが、1対1でお話をさせていただきます。フリーランスの皆様のスキル、過去のご経験を元に今後のキャリアプランを一緒に築いていくためのご提案させていただきます。
今後のキャリアや、技術面において不安な事もお気軽にご相談下さい。

オンライン相談をしてみる

無料会員登録

60秒で登録完了!

  • HOME
  • お役立ち記事
  • クラウドネイティブが求められる理由と知っておきたい技術群