サーバーレス＝運用の自動化

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

自動化とオーケストレーションには、プラットフォームが必要になります。サーバーレスは、まさに求めていたものかもしれません。

サーバーレス（別名Function as a Service）は、まだ黎明期にあります。登場したばかりのテクノロジーには、「何に役立つのか」という問いへの答えが求められがちです。ほぼ毎日のように新たな開発やテクノロジーが登場し、注目を集めようとする今の時代では、なおさらです。

サーバーレスの一般的なユースケースは、画像処理やデータマイニングなど、特定の種類のワークロードにクラウドの力を活用できる点を中心としています。しかし現在では、運用の自動化など、いわば地味な用途にサーバーレスを活用している組織もあります。

実際、サーバーレスは、現在の運用自動化において最も効率的な手段の1つかもしれません。少なくとも私はそう主張したいと思います（何しろ私ですから）。運用自動化のプラットフォームとしてサーバーレスを真剣に検討することをお勧めする4つの理由をご紹介します。

1. イベント駆動型であること

イベント駆動型システムでは、アクションによって処理が実行されます。イベント（アクションと呼ばれることもあります）はさまざまな方法でトリガーできますが、多くの場合、コマンドライン（「curl」など）またはシンプルなWebインターフェースからREST APIを呼び出すことで実行されます。これには、サービスのプロビジョニング、構成の更新、ファイアウォールルールの無効化などのタスクが含まれます。基本的に、アプリケーションを本番環境にデプロイし、続いて必要なネットワークサービスとアプリケーションサービスをデプロイするプロセスは、一連の「アクション」に分解されます。パイプライン内の多くのアクションは、先行するアクションの完了を契機にトリガーされます。これは、OpenWhiskなどのサーバーレス環境における「アクションシーケンス」の概念とよく合致します。結局のところ、デプロイメントオーケストレーションとは、個別に自動化された多数の小さなタスクで構成されるプロセスを自動化することです。各タスクはサーバーレス環境へのAPI呼び出しとして適切に表現でき、上位のAPI呼び出しによってシーケンス全体を開始できます。

2. Infrastructure as Codeと再利用を促進

テンプレートとスクリプトはInfrastructure as Codeの概念に適合しますが、サーバーレスベースのシステムは、その存在自体がこの基準を満たします。デプロイメントの成果物や構成要素をコードとしてカプセル化し、プロセスに組み込むことで、再利用がさらに促進されます。その結果、予測可能で反復可能かつ一貫性のあるプロセスを実現し、継続的に測定、最適化できます。また、「1つのタスクに1つの関数」というアプローチにより、構成可能性がさらに高まります。動的に生成されたパイプラインに応じて異なる関数を組み込むことで、プロセスを容易に制御し、より柔軟に構築できます。

3. 「サーバーレス」であること

もちろん、サーバーレスが文字どおりサーバーを使用しないわけではないことは、誰もが理解しています。しかし、基盤となるハードウェア（およびソフトウェア）インフラストラクチャを利用者から「見えなくする」という考え方は、開発者だけでなく、インフラストラクチャやネットワークの運用担当者にとっても魅力的なはずです。デプロイパイプラインの自動化とオーケストレーションを始めると、その管理に必要なソフトウェアやシステムも必要になります。つまり、ライセンスの取得、保守、管理、スケーリング、セキュリティ確保が必要なサーバーやソフトウェアが増えるということです。コンシューマー向けアプリの管理がどれほど大変かはご存じでしょう。運用向けアプリでも同じことが起こると考えてみてください。サーバーレスインフラストラクチャを一度構築すれば、基盤となるインフラストラクチャを意識することなく、いくつものワークフローを構築できる一貫したプラットフォームが得られます。つまり、開発者をサーバーレスに引き付けるのと同じメリットを、運用部門も享受できます。

4. あらゆるものが「ポリ」化

それが一体何の関係があるのか、と思われるかもしれません。では、ご説明しましょう。異種混在ではないインフラストラクチャで稼働するデータセンターはありません。単一ベンダーの製品に限っても、組織ではハードウェアとソフトウェアの両方で複数のモデルやバージョンが使用されています。環境全体に存在する多種多様なデバイスやバージョンの管理は、組織が直面する課題の1つです。ほとんどのサーバーレス環境は、すでに多様な言語やツールセット（あるアクションはPythonで、別のアクションはnode.jsで記述できます）に加え、「イメージベース」のアクションにも対応しています。これは、実質的に何でも実行できるコンテナです。このように多様なシステムを自動化するタスクで構成されたプロセスをオーケストレーションする場合、最適なツール（場合によっては唯一のツール）を使用できることは、運用上の大きな利点となります。

重要なのは、一般消費者や企業ユーザーが常時アクセスして利用する大半のアプリケーションとは異なり、運用タスクの実行頻度は低く、より広範な環境で発生したセキュリティや可用性のインシデントへの対応として、時には（認めたくはありませんが）ほとんど予告なく実行されるという点です。そのため、サーバーレスのようなイベント駆動型システムは適していると考えられます。運用全般にわたる多種多様なタスクを実行できる「常時稼働」のプラットフォームを提供します。ある時は、ファイアウォールルールの更新といったセキュリティ関連のタスクを実行し、次の瞬間には、早急な対処が必要なゼロデイエクスプロイトへの対応として、WAFなどの新しいアプリケーションサービスをアプリケーションのデータパスに組み込むアクションを開始することもあります。同じプラットフォームで、必要となるほぼすべての運用タスクを自動化された拡張可能な方法で実行する仕組みを提供できます。

SlackのようなChatOps対応システムでチケットを作成したり、ボットコマンドを実行したりすることでイベントがトリガーされる場合もあります。タスクの完了に必要なアクションが呼び出されると、チケットやコマンドから必要な情報が自動的に取得され、使用されます。

Serverlessは開発者を主な対象としていますが、その基盤となる原則と仕組みにより、運用オーケストレーションシステムを独自に構築したり、統合や運用に固有の課題を伴う疎結合のシステム群に依存したりする方法に代わる、魅力的な選択肢となります。

運用自動化への取り組みを始めたばかりであれば、エンタープライズ向けサーバーレスプラットフォームがニーズにどの程度適しているか、じっくり検討することをお勧めします。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事