運用自動化の原則 ステートレス化について

[CTG-Japan]

1. 自己紹介

吉川慎二こんにちは、日本ヒューレット・パッカード合同会社　コミュニケーションテクノロジー事業本部の吉川　慎二（Yoshikawa Shinji）と申します。通信事業者向けのソフトウェア製品のプリセールスを担当しており、主に コアネットワーク系のソリューションをお客様に紹介しています。

2. はじめに

日本は深刻な人手不足に陥っており、経済産業省の資料（ＩＴ人材需給に関する調査（概要））によるとIT業界では2030年に約79万の人手不足に陥る可能性があるとの試算もあります。近年ではDX（デジタルトランスフォーメーション）の旗のもと様々な業務のシステム化が進められていますが、そのシステムの自動化までにはなかなか至らないケースも見受けられます。実際、私が担当している通信事業者向けの運用業務についてもなかなか自動化が進んでいない印象があります。なぜ、自動化が進まないのでしょうか？それには様々な要因があると思いますが、本記事では通常あまり議論にならない「ステートレス化」の観点から運用自動化について議論していきたいと思います。

3. ステートフルとステートレス

まず、最初にステートフルとステートレスについて解説します。ステートフルとは以下の処理を指します。

• ステートフル処理とは処理をする側が個々の状態（ステート）を覚えていることを前提として処理することです
• 基本的にクライアントは処理の続きを伝えるだけで全体の処理が成立します

例えば、以下のコーヒーショップシステムは店員がオーダーステートを覚えているステートフル処理です。

ステートフル処理の例

そして、ステートレスとは以下の処理を指します。

• ステートレス処理は逆に状態（ステート）を覚えないことを前提として処理することです
• 処理をする側が何も覚えていないので全体の処理を成立させるには誰かがステートを覚えておく必要があります

以下の例は、店員がステートを覚えないのでお客様が覚えることでステートレス処理を成立させています（通常ではありえませんね）。ステートレス処理の例

4. ステートフルは停止をするのが苦手

ステートフル処理は保持しているステートがなくならない限り止めることができません。ステートを無くす方法はいくつか考えられますが、以下が一般的です。

1. 新規の処理を受け付けないようにする
2. 既存の処理がすべて終了するまで待つ

ステートフル処理の止め方

 「ここまで待てばステートが必ず終わっている」という時間があればいいですがそれがわからないケースもあり一般的に人が介在してすべて終了しているのを確認しています。また、終了する時間があったとしてもそれが数日だと、ステートフル処理を落とすのに数日かかることになります

5. ステートフルはロードバランシングが苦手（１）

ステートフル処理では一度ステートができると同じ処理は同じインスタンスで実施する必要があります。そのためロードバランサーにインテリジェンスを求める必要がでてきます。それにはどのようなインテリジェンスが必要なのでしょうか？

ロードバランサーの動き　その１

上記の例で、ロードバランサーに求められる機能は以下になります。

• メッセージをどこに投げたかを覚えておきそれに従って投げるロジック（ダイナミック処理）が必要です
• さらに、転送先がダウンしたことを考慮し、それぞれのInstanceのバックアップ先も情報として持っておく必要があります
• でもその情報をどのように知るのか？という問題もあります！
• また、ロードバランサーの冗長を考えるとこの転送先情報をスタンバイのロードバランサーに同期する必要があります

このようにどんどんシステムが複雑になってきます。

6. ステートフルはロードバランシングが苦手（２）

ロードバランサーをもっとシンプルにしたい！ということで固定ロジック（スタティック処理）で転送する方法を考えます。

ここでは「IDを転送先であるインスタンスの個数で割った余りに投げる」というロジックを考えます。以下の例だと3で割った余りに投げます。（ここでは話を簡単にするためインスタンスの冗長については省略します）

ロードバランサーの動き　その２

例えば、Instance3を増やしたい場合、転送先決定ロジックはインスタンスの数である4で割った余りに変更する必要が出てきます。

ここで、急に転送ロジックを変更すると、ID:9さんのメッセージはInstance1に転送されてしまいますが、そこには9さんのステートはありませんのでエラーになります。

この状況を回避するには、ステートの場所をロジック変更の前と後で記憶しておくなど、結局複雑な処理が必要になってきます。

ロードバランサーの動き　その３

7. 運用自動化とステートフル処理

以上のようにステートフル処理は構成変更が苦手であることがわかりました。

ここで運用自動化の話に戻りますが、本記事では運用自動化を以下のように定義します。

1. 自動的にシステムの状態を検知して
2. 自動的に何をするべきか判断して
3. 自動的に構成変更などのアクションを行う

ここで問題なのが3です。果たして、

ステートフル処理に置いて「自動的に構成変更」は本当に可能なのでしょうか？

ここで構成変更とは何を指すのかについて以下に整理します。

構成変更とは

そうです。先の議論の通りこれらすべてステートフルでは苦手な処理であり、現状どうしても人手を介在させる必要がある処理になります。つまり、

ステートフルが自動化を妨げている大きな要因の一つ

と言えます。

一方、これがステートレスだとどうでしょう？ステートレスだと何も覚えていないので以下の通りとても構成変更は簡単な処理と言えます。

ステートレスにおける構成変更

結論、

運用の自動化をするにはアプリケーションのステートレス化が必須

となります。

8. ステートフル処理をステートレス化

先の議論により「運用の自動化をするにはアプリケーションのステートレス化が必須」となりましたが、では具体的にどうすればいいのでしょうか？

その答えの一つが「ステートを外に出してしまえばいい」になります（下図）。このようにすることでアプリケーション側（下図ではInstance側）はステートレスになり、構成変更の課題は解決します。

ステートフルをステートレス化

一方、ステートを保持する「Session Store」はどうなんでしょうか？

こちらはステートフルになるので構成変更の課題が残ってしまうのでは？と思われた方もいらっしゃると思いますが、このSession Storeの使われ方に注目します。

このSession SotreはSession ID(Key)からSession情報(Value）を一発検索するというシンプルな動きだけを行います。

先の議論の通り、複雑なアプリケーションがステートを持つといろいろ面倒なことが発生しますが、このようなシンプルに動きであれば構成変更にあるスケーリングや修復（耐障害性）に優れ、ロードバランサを必要としないものがあります。

それは分散KVSと呼ばれるDBです。この分散KVSをSession Storeに利用することで、ロールバック以外の構成変更には対応可能になります。

ロールバック、つまりアップグレード作業については分散KVSでも手軽にとはいかないのですが、そもそも機能が単純なSession Store自体に機能追加を期待していないですし、安定バージョンを使うことでアップグレード作業自体を極力発生させなくさせることができます。

この方式はアプリケーション開発側にもメリットをもたらします。Session Storeを使う前提であれば、アプリケーション開発者は冗長化について何も考える必要がなくビジネスロジックにのみ注力して開発すればよくなります。これにより開発内容がよりシンプルになり不具合の減少や開発期間の短縮の効果が期待できます。

9. モバイルネットワークの世界の話（UDSFの紹介）

さて、Session Storeを使うことが運用自動化に必須であることを説明してきましたが、複数あるアプリケーションがそれぞれ独自のSession Storeを持つとSession Storeの種類も増えてしまい結局運用に負荷がかかってしまうことが懸念されます。

そして、それを解決するためには一つのSession Storeが複数のアプリケーションで共通で使えるようにSession Storeインターフェイスの共通化（標準化）が必要になります。

実は、モバイルネットワークの世界(3GPP)ではこの課題を解決するための標準インターフェイスを実装したNetwork Functionが定義されています。それが3GPP UDSF(Unstructured Data Storage Function)になります。

UDSFの詳しい解説についてはHPEブログの「3GPP UDSFを学ぼう！」を見ていただきたいですが、このUDSFがまさにSessio Storeとして唯一標準化された仕様で、ステートレス化を目的に策定されものになります。

最後にHPE UDSFの紹介をして本記事を締めくくらせていただきます。

HPE UDSF