サーバーレス = 自動操縦による運用
自動化とオーケストレーションのためのプラットフォームが必要になります。 サーバーレスはまさにあなたが探していたものかもしれません。
サーバーレス（別名 サービスとしての機能はまだ初期段階にあります。 そして、まだ軌道に乗っていないテクノロジーはどれも、「それは何の役に立つのか？」という疑問に答える必要がある傾向にあります。 これは、ほぼ毎日、私たちの注意を惹きつける新たな開発やテクノロジーが存在する時代には特に当てはまります。
サーバーレスの一般的な使用例は、画像処理やデータマイニングなどの特定の種類のワークロードにクラウドのパワーを活用する能力を中心に展開されます。 しかし、今日では、運用の自動化など、いわゆる魅力のない目的でサーバーレスを使用している組織もあります。
実際、私はサーバーレスがおそらく今日の運用を自動化する最も効率的な手段の 1 つであると主張するかもしれません (そして、私としてはそう主張すると思います)。 運用を自動化するためのプラットフォームとしてサーバーレスを真剣に検討することをお勧めする 4 つの理由を以下に示します。
1. イベント駆動型
イベント駆動型システムでは、アクションによって物事が発生します。 イベント (アクションと呼ばれることもあります) はさまざまな方法でトリガーできますが、ほとんどの場合、コマンド ライン (「curl」など) またはシンプルな Web インターフェースから REST API 呼び出しによって呼び出されます。 これには、サービスのプロビジョニング、構成の更新、ファイアウォール ルールの無効化などのタスクが含まれます。 基本的に、アプリケーションの本番環境への展開、およびそれに続く必要なネットワークとアプリケーション サービスは、一連の「アクション」に分解されます。 パイプライン内の多くのアクションは、前のアクションの完了によってトリガーされます。これは、 OpenWhiskなどのサーバーレス環境の「アクション シーケンス」の概念にうまくマッピングされます。 デプロイメント オーケストレーションとは、結局のところ、多数の小さな個別の自動化タスクで構成されるプロセスの自動化です。 それぞれは、サーバーレス環境への API 呼び出しによって適切に表現され、包括的な API 呼び出しによってシーケンス全体が開始されます。
2. インフラストラクチャをコードとして再利用することを推奨します
テンプレートとスクリプトはコードとしてのインフラストラクチャの概念に適合しますが、サーバーレス ベースのシステムは本質的に基準を満たします。 そうすることで、デプロイメント成果物と構成要素をプロセスに挿入されたコードとしてカプセル化することで、それらの再利用がさらに促進されます。 つまり、時間の経過とともに測定および最適化できる、予測可能で、反復可能で、一貫性のあるプロセスを意味します。 「1 つのタスク、1 つの関数」アプローチは、構成可能性をさらに促進し、動的に生成されたパイプラインに基づいてさまざまな関数を挿入することで簡単に実行できる、より流動的なプロセスの作成を可能にします。
3. 「サーバーレス」です
さて、私たちは皆、サーバーレスが文字通りサーバーなしではないことを知っています。 しかし、基盤となるハードウェア (およびソフトウェア) インフラストラクチャは、それを使用するユーザーにとって「目に見えない」という同じ概念が開発者にとって魅力的であるように、インフラストラクチャとネットワーク運用にとっても魅力的であるはずです。 デプロイメント パイプラインの自動化とオーケストレーションを開始すると、それを管理するためのソフトウェアとシステムが必要になることに注意してください。 つまり、サーバーとソフトウェアのライセンス、保守、管理、拡張、セキュリティ保護が必要になります。 消費者向けアプリの管理がいかに負担が大きいかはすでにご存知でしょうが、運用向けアプリでも同じことが言えると考えてください。 サーバーレス インフラストラクチャは、一度確立されると、基盤となるインフラストラクチャを気にすることなく、任意の数のワークフローを構築できる一貫したプラットフォームを提供します。 つまり、開発者がサーバーレスに惹かれるのと同じメリットが、運用でも実現できるということです。
4. すべてがポリです
それが一体何と関係があるのかと思うかもしれません。 まあ、教えてあげましょう。 異機種混合のインフラストラクチャ上で稼働するデータ センターはなく、単一ベンダーのサブセット内であっても、組織はハードウェアとソフトウェアの複数のモデルとバージョンを同様に稼働しています。 組織が直面する課題の 1 つは、環境全体でさまざまなデバイスとバージョンを管理することです。 ほとんどのサーバーレス環境では、さまざまな言語とツールセット (1 つのアクションは Python で記述でき、別のアクションは node.js で記述できます) に加えて、何でも実行できるコンテナーである「イメージベース」のアクションもすでにサポートされています。 多様なシステムセットを自動化するタスクで構成されるプロセスを調整しようとしている世界では、最も効果的なツール (おそらく唯一のツール) を使用できることは、運用にとって大きなメリットとなります。
問題は、一般ユーザーと企業ユーザーの両方から常にアクセスされ、使用されているほとんどのアプリケーションとは異なり、運用タスクは頻繁に実行されず、場合によっては（認めたくはありませんが）より広範な環境におけるセキュリティや可用性のインシデントへの対応として、ほとんど警告なしに実行されることです。 つまり、サーバーレスのようなイベント駆動型システムが適していると思われます。 運用範囲全体にわたってさまざまなタスクを実行できる「常時オン」のプラットフォームを提供します。 ある瞬間には、ファイアウォール ルールの更新など、セキュリティ関連のタスクが実行される場合があります。 次に、即時の是正が必要なゼロデイ攻撃への対応として、アプリケーションのデータ パスに新しいアプリ サービス (WAF など) を挿入するアクションを起動する可能性があります。 同じプラットフォームで、必要なほぼすべての運用タスクを自動化され、拡張可能な方法で実行するメカニズムを提供できます。
イベントは、チケットの作成や、Slack などの ChatOps 対応システムからのボット コマンドによってトリガーされることもあり、タスクを完了するために適切なアクションが呼び出されると、チケットまたはコマンドから必要な情報が自動的に取得されて使用されます。
サーバーレスは開発者に重点を置いていますが、その基礎となる原則とメカニズムにより、独自の運用オーケストレーション システムを構築したり、独自の統合と運用上の課題を伴う疎結合のシステム セットに依存したりするよりも魅力的な代替手段となります。
運用自動化の取り組みを始めたばかりの場合は、エンタープライズ向けのサーバーレス プラットフォームをじっくり検討し、それがニーズにどれだけ適合するかを確認することをお勧めします。