Twitter (X) でデジタル庁が出したnoteについての議論があり、様々な立場からの意見が集まっています。自分が感じたこと考えたことを残しておくと私自身の勉強になりそうなので、このブログでもちょっとまとめてみます。

一応コンテキストとして書いておくと、私はオンプレミスパッケージ製品の開発運用経験がある、クラウドネイティブSaaSのSRE 兼 セキュリティ担当です。

文脈

この情報の初出は今年の2月で、そういう意味では新しい情報ではないでしょう。ガバクラのコストの高さなどに注目が集まったタイミングで拡散しやすいnoteに情報が載った、という文脈が今回の注目量の背景にあると思います。

xtech.nikkei.com

note.com

最近の流れを汲めていない内容になっているのは、2月に決まっていた内容をほぼそのまま載せたから、と考えられそうです。

この定義の着眼点

モダン化に限らず情報システムの評価においては、様々な着眼点というか切り口が存在します。私はこの定義を見て、サービス運用者の目線で書かれているなと思いました。モダンではないサービスの運用現場で何が起こっているかと言うと、私の知る限りでは：

• シングルテナントであり、テナント（顧客）ごとに環境が必要になる
• テナントごとに環境が複数存在する（SAPで言う3-system landscape）
• 環境ごとにサービスのバージョンが異なる
• 更新にサービス停止が必要で、サービスを止められるタイミングは各テナントの都合で決まる
• 環境（サーバ、クライアント共に）のスペックやOSは各テナントの都合で決まる
• 実行ファイル（クライアント）がDBに直接接続しているので、DBスキーマ変更には全クライアントの停止と一括更新が必要になりがち
• 複数のシステムが連携しており、ひとつの失敗が複数のシステムや業務に容易に波及する
• ストレージやメモリなどの増設には顧客の対応と出費が必要で難度が高い
• サーバが状態を持っており水平スケール（スケールアウト）できないので、垂直スケール（スケールアップ）が必要で高スペックマシンが必要になりがち
• サーバは必ずしも設備が整ったサーバ室で実行されているわけではない
• サーバのハードウェアは必ずしも冗長化や管理が行われてはいない
• サービスの実行環境は顧客のものであり、アクセスや変更の手順が重い

たとえば100テナントそれぞれが3環境持っていたらそれだけ300環境になります。それらの環境には少なくても5年前のOSやハードウェアが含まれ、最新のライブラリやフレームワークが使えないことが前提になってきます。またサポートコストを減らすなどの理由から最古のメジャーバージョンのメンテナンスを停止する場合、100以上ある環境それぞれに対してマイグレーション手法やスケジュールを提案し、それぞれに対してオペレーションを適用する必要が出てきます。そんなコストはなかなか払えないので破壊的変更を入れる頻度を下げざるを得ず、魅力的な実装を届けるハードルが上がり、魅力のないマイナーバージョン更新は顧客を惹きつけないので最新のマイナーバージョンを使ってもらえず、在野に放たれるマイナーバージョンが更に増えていきます。

そんな状況でLog4Shellのような緊急度の高い脆弱性が報告されたらどうなるか。サポートしているすべてのマイナーバージョンに対してパッチをあてて動作確認をし、全環境に適用する……というコストが突発的に発生します。スモークテストやリグレッションテストは当然手動ですから、数日から数週間は非常に厳しい状況に陥るでしょう。このような想定があるため、サービスのサポート体制はどうしても厚くせざるを得ません。サポート体制が厚いということは、人件費が高いということです。自動化や効率化のためのITシステムなのに、その維持には人手が必要だという自己矛盾に陥りがちだと言えるでしょう。

ところでデジタル庁のnoteで挙げられているモダン化の利点は、先程挙げた運用現場の課題にそれぞれ対応しているように思われます：

これが私が「サービス運用者の目線によるモダン化」について書かれていると感じる理由です。noteではアーキテクチャと運用のモダン化だとしていますが、アーキテクチャも実行性能やランニングコストではなく「サービス運用の容易性」で選ばれているように感じます（後述しますが、夜間バッチを逐次処理に置き換えるとクラウドでもコストは高くなるため）。この理屈でいうとマルチテナントやclear change processについても言及があってしかるべきではありますが、さすがにすべてがマルチテナントになるべきとはまだ言いにくい*1のかもしれません。

この定義があると誰がどう嬉しいのか

デジタル庁によってこうした定義が提示されると、誰がどう嬉しいのでしょうか。もちろんサービス運用者には溜飲の下がる人が多いかもしれませんが、サービス運用者の意見だけでサービスの実態が変わることはまずありません。サービスのオーナーである企業経営者や、サービスを求める発注者にとっての利点があって、はじめてモダン化の重要性が認められモダン化が進むと思われます。

私はこのモダン化の定義によって、サービスの「モダン化度」を測るチェックリストを作れることが嬉しいのかなと思いました。いまサービスを運営している人が「モダン化にあたり、いまの課題はどこなのか」を専門家である第三者に教えてもらえる、モダン化のためのロードマップが引ける、そして顧客にその必要性を説明できるための素材になるのではないかなと。特にアーキテクチャの具体についてある程度触れることで、工数見積をやりやすくしているのではないかと思います。

これについては色々思うことも無いではないのですが、大号令によって市場を形成してITシステム開発の大勢を変えていく手段としてはアリなのかもしれません。私も情報セキュリティの専門家であることをお客様に伝えるとき、Log4Shell対応などで縦横無尽に活躍したかを語るよりはただひとこと「国家資格持ちです」と言う方が効果的だということを身にしみていますので、やっぱり「難しいのは重々承知してますが、デジタル庁が言ってますんで」のひとことが言えるだけで助かる現場があるんだろうなとは想像するところです。

個別の要素について

ここまで来ると個別の技術的記載に突っ込むのは野暮な気がしてきますが、自分自身他の方々のご意見を拝見してとても勉強になったので、気になったところをいくつか書いておきます。

非同期APIについて

要件について説明が不足していると感じます。このAPIは少なくとも次のような構成要素を持つはずです：

1. APIを提供し、リクエストパラメータをジョブキューに積むサービス（FaaSっぽいがそれに限られない）
2. ジョブキューから情報を取り出し、その内容を処理する冪等なサービス
3. リクエストした内容がどこまで処理されたかを確認するためのAPIや画面

1つめはAPIの可用性を上げるために重要です。このAPIはリトライすればなんとかなる程度の短いMTTRを実現する必要があるため、できるだけマネージドサービスに寄せて実装を薄くすることが求められます。採番ルールなんて気にせず、粛々とUUIDを返すAPIであるべきです。またファイルや巨大なペイロードを処理するAPIの場合は、ファイルをアップロードする別のAPIが必要でしょう。

2つめは処理の本体です。冪等に実装する必要があり、多くの場合は既存コードの流用は難しいでしょう。モダン化のハードルのひとつだと言えそうです。

またAPIを使った人はその進捗や結果を確認したいことがほとんどなので、3つめも必要になります。数10分かかるとわかっている処理であれば、その進捗度を知りたいというニーズもあるでしょう。1と3はほとんどのサービスで共通の構造になりますが、2の持つ入力や出力の仕様が染み出してくるところがあるため、必ずしも共通基盤として括り出せるかはわかりません。

さてこのように構成要素を整理したうえで、モダン化システムはかならず非同期APIを使うべきか？と問えば、まぁNOでしょう。業務要件によっては同期的なAPIも必要になるからです。

単純に情報を取得するAPI、ファイルをアップロードするAPI、ロックを取得するAPI、ログインやログアウトをするAPIなどはイメージしやすいでしょうか。他にもリクエストパラメータが間違っていることを最初にvalidateして返したいAPIなんかは、システム間連携でも同期APIにしたいかもしれません。非同期APIの使い所として帳票を生成したり複数のシステムを活用するAPIなんかは思いつきましたが、すべてのAPIがそうあるべきとは思いませんでした。

フロントエンド・バックエンドアーキテクチャ

これ自分は「UIもビジネスロジックもひとつの実行ファイルで動かしているパターン」、まぁDelphiなんですけど、を想定して読みました。ので責務を分けるという言葉が単なるプログラミング言語的な意味での開発速度向上ではなく、サーバとクライアントとを独立して保守・更新できるという意味での開発速度向上だと理解しました。

ただ私とは異なる理解をしている方も多かったようなので、仮に私の理解が正しいのであれば、バックエンドが互換性の維持に気を使ったAPIを提供することの重要性や、現在のシステムとして想定しているものが何かをもう少し書くと良かったのかもしれません。

イベントドリブン処理

このあたりの話は、みずほ銀行さんの一件を思い出しますね。結論としては、夜間バッチでも良いと思います。

xtech.nikkei.com

オンライン処理、というか逐次処理にしてしまうと、単純に計算回数が増加します。たとえば勤怠管理のための打刻処理を考えます。その人の勤務時間は退勤時に計算できますので、オンライン処理の場合は退勤時に計算することになります。しかし運用によっては休憩時に退勤手続きを行うこともありますし、無事に退勤したがオンコールで呼び出されてしまった場合などは複数回の出勤・退勤を記録することになりますから、退勤時に走る勤務時間計算処理も2回3回と実行されます。オンライン処理よりも計算回数が増えるわけですね。

また非同期処理のためにメッセージキューやらDBのトリガーやらCloud Tasksやらを導入しますから、構成要素が増えて可用性が下がることも想像できます。たしかに夜間バッチには処理を相対的に計算機資源が空いている夜間にシフトするという物理資源節約の側面もあるのですが、コストや運用の観点からも合理的なことがあるわけです。

オートスケール

オートスケールが嬉しいかどうかは業界というかシステムによりそうです。どちらかといえばローリングアップデートができることの方が、clear change processやコンテナの活用などを念頭に置くと一般的に重要なように思われます。ただランニングコストを下げるという錦の御旗を考えると、スケールダウンできるように作りましょうと言いたいのは理解します。

定型作業を自動化する

これも要件というか「定型作業」の具体が読み手によって異なるために、混乱を生んでいるように思います。年1回しかデプロイしない想定ならデプロイ作業を自動化する意味は薄いですし、1次対応を外注している想定なら自動化によるコストダウンや確実さは重要でしょう。

おわりに

デジタル庁のモダン化の定義は運用現場の課題を解決する道筋を示すチェックリストとしての価値があるのではと感じました。一方で、同期API vs 非同期API、夜間バッチ vs イベントドリブンといった検討は、必ずしも全サービスにそのまま当てはまるわけではありません。各組織や案件ごとに業務要件やリスク許容度を見極め、バランスを取る必要がありそうです。そのバランスが難しいから、ひとまず道を示しているのかもしれませんが……。

今回の議論は私にとって、普段とは違うシステム構成について検討し、私達の今後のシステム開発を考える良いきっかけになりました。業務の効率化はITシステムの開発・保守・活用すべての局面において求められています。私としては、それぞれバランスよく検討できるだけの知恵と経験をつけていきたいです。