はじめに

NTTデータ先端技術株式会社にてアジャイル開発並びに技術調査業務に従事している志田です。業務においては、部内の中で比較的数の少ないインフラのできる技術者としてさまざまな案件のインフラ構築にも携わっています。お客様に対してシステム構築や開発の提案をする際にインフラに関するチェックや見積りを担当することも多いのですが、やはりアプリケーションエンジニアから見たときにインフラというのは少々遠い位置にあるようで、インフラの観点としてどういったことに注意するべきか、どういった点で工夫の余地があるのかといった部分に関しての理解が得られていないなと感じることが多々あります。今回は、システム構築におけるインフラの立ち位置や、いつもどういった観点でインフラ検討をしているのか説明します。

インフラは完全なものが求められやすい

アプリケーションとインフラを比較すると、インフラは比較的プロジェクトの中で早い段階から完全なものが求められる傾向にあります。アプリケーションの開発では基本となる部分を作り、それに追加をしていくことでアプリケーションを発展させていくインクリメンタルなモデルとなりますが、例えばサーバやデータベースがない状態でインフラとしてリリースというのは難しいです。これに関して、私自身が人に説明する際、アプリケーションとインフラの違いとしてインフラは100点から開始するというように表現することが多いです。 Webシステムの開発におけるインフラのリリースは、WebシステムがWeb上で閲覧可能になるその時です。ここで、インフラは常に100点が求められます。100点とはそもそも何か?という話になりますが、以下を満たしている状況を100点だと考えています。

  • インフラ上で稼働するアプリケーションからの要求をすべて満たしている
  • システムが保証するべき非機能要求をすべて満たしている
  • 上記2点を満たしていることを継続的に監査できる

非機能要求の名前が表しているように、Webシステムの開発に対して顧客のインフラに対する要求は通常、発生しません。例えば、製造業や小売業などのエンドユーザから直接「こういったスペックのサーバが欲しい」と言われたり、「このスペックのネットワークが欲しい」といった具体的なの要求が発生することはまずありません。顧客からの要求は必ずもう一段上(またはそれ以上)の抽象度の高い要求となり、発生する業務を規定時間内に終わらせるようにWebシステムを作ってほしい、というような要望です。こういった顧客の要望に応えられる要求は機能要求となり、インフラ単体というよりアプリケーションとインフラとで分担して満たしていくものとなります。通常、インフラは非機能要求の多くの部分を担当することになり、Webシステムの可用性・信頼性や堅牢性といった点をカバーしていきます。 非機能要求はシステムが何をするべきかを定義する機能要求とは異なり、非機能要求はどのようにそれを行うべきかを定義します。一般的には以下のような事項を非機能要求として策定していきます。

  1. パフォーマンス要求: システムの応答時間、処理速度、スループットなど
  2. 信頼性要求: システムのダウンタイム、回復時間、データの整合性など
  3. 可用性要求: システムが利用可能である時間や条件
  4. セキュリティ要求: 認証、認可、データの暗号化など
  5. 拡張性要求: 新しい機能やモジュールを追加する容易さ
  6. 維持性要求: システムの修正やアップデートの容易さ
  7. 移植性要求: 異なるプラットフォームやデバイスでの動作

これを満たすためにはアプリケーション側も考慮が必要ですが、多くの部分はインフラにてカバーする領域です。例えば、信頼性要求などはシステムのダウンタイムをできるだけ短くするため冗長化といった方式が利用されます。これは通常インフラでのサーバ、ネットワークの多重化で実現します。そして、Webシステムがリリースされた後はシステムの機能要求、非機能要求は常に満たされ続けなくてはなりません。そのため、インフラでは常にこの要求が満たされているか、チェックし続けなくてはならないのです。

Webシステムのリリースを行う際、一部の要求が満たされていない、や、サーバやデータベースが足りないといった状態でリリースすることはまずなく、リリースするそのタイミングではインフラはアプリケーションからの要求に答えることが可能な状態であり、非機能要求を充足することでWeb攻撃に対して適切な対策を行い、障害発生時の対応を明確にする必要があります。このため、インフラは常に100点を満たさなくてはいけないという暗黙のルールがあります。

インフラでの改善とは

アプリケーションの開発において、今ではアジャイル開発・繰り返し開発が一般的になっています。アプリケーションの開発を1回のリリースで完遂させるわけではなく、小さな機能改善を何度も積み上げることによって、徐々にブラッシュアップさせていく手法です。インフラの構築もこれに合わせて小さい改善を繰り返していき、その都度リリースするのが望ましいのですが、現実問題としてなかなかアジャイルにインフラ構築をするという場面に出会うことは少ないです。これは前出の通り、インフラは通常リリースしたそのタイミングで100点を満たした状態になっているためです。一部の非機能要求を満たしていない状態でリリースされるといった状況はまずありません。

では、インフラがリリースされた後に全く改善されないか、改善すべきポイントはないかというとそんなことはありません。多くの場面で利用されるQCD(Quality, Cost, Duration)の関係で考えますと非機能要求を充足するという点でQualityは大きく変化することはありませんが、100点を満たしているインフラもコストの点では大きな改善余地を残していることがあります。インフラにおけるコストは大きく以下に分けられます。

  • システムリソース、ランニングコスト
  • システム保守にかかわる作業コスト

システム開発におけるインフラの改善とは多くの場合インフラにかかわるコストを削減する必要があります。インフラを構築すること自体にも当然、インフラの設計であったり実際にサーバ等を導入してネットワークを組んだりとコストがかかります。ただ、クラウドを利用する場合構築にかかわるコストはインフラが占めるコストのほんの一部であり、支配項となるのはリリース後のランニングコストです。システム開発の流れとして要件定義、設計、実装、試験、リリース、運用保守とありますが、インフラのコストがかかるのはこの中の運用保守のフェーズです。この運用保守のフェーズでどのようにコストを下げていくかがインフラの改善ということになります。

  • 図 1 アプリとインフラの改善の意味の違い

    図 1　アプリとインフラの改善の意味の違い

つまり、アプリケーションでは運用保守フェーズでよりシステムを使いやすくするための機能追加が行われていきますが、インフラは今と同じ要求を満たしながらコストを下げていく変更が行われていきます。

インフラコストの削減

インフラコストを削減する方法として多く使われる手法がサーバ低減と集約です。Webシステムを構成するサーバやデータベースのスペックを低減したり、台数を削減したりすることがサーバ低減であり、複数台の仮想サーバをコンテナにして1台の仮想サーバに集約するといった手法がサーバ集約です。また、クラウドサービスを利用している場合は実現するサービスを切り換える方法も採用されることがあります。これらの手法でシステムを稼働させるためのリソースにかかるコストを削っていくことは重要な改善です。

同様に、保守フェーズでは障害に対して何らかの対応をしたり、負荷に備えて動的にリソースを変更したりするため、保守要員が張り付いて対応するのが一般的です。この要員のコストが難しく、問題が発生しない限りは張り付く必要はありませんが、ひとたび障害が発生すると可能な限り迅速に解決しなければならないため常に監視しておく必要があります。この監視を行う部分や障害発生時の対応を自動化することによって、作業コストを削減することも重要です。この作業コストに関しては究極的にはコストゼロで実施できるよう完全に自動化のが目標ですが、現状は発生した障害から何が起こったかを分析するために人員が必要となり、完全自動化までには至っていません。

インフラとシステム運用の今後

インフラはアプリケーションに比べて顧客要望が直接反映される場所ではないため、変化が少なくリリースタイミングで完全なものを提示することを求められます。システムが運用保守のフェーズに入ると、インフラはコスト削減やまだ見ぬ脅威への対策といった観点での改善が求められますが、現時点では作業コストをゼロにするために完全自動化することが難しく、人間の判断が必要です。ここで、生成AIの普及によって現状の人間が判断しなければならない部分において、自動化が実現していくと予想されます。

  • 図 2 システム運用の今後

    図 2 システム運用の今後

生成AIの今のトレンドとして、公開情報だけでなく企業内部の情報やシステムの稼働データなど非公開データを公開データと混ぜ合わせて利用できるようにするという点や、他のAIや機械学習技術と組み合わせて生成AIと数値計算、統計処理を自動で行うというものがあります。これらを活用することで、現状人が判断している点をAIに移譲することが実現されていくでしょう。また、さまざまなサービスがマネージメントサービスとしてインフラのレイヤーはサービスプロバイダが維持管理を行い、アプリケーション開発はインフラのことを意識せずに開発できるようになってきています。

こういった全体の流れはありますが、やはり非機能要求を適切に充足するシステムを開発していくにはインフラの知識も必要不可欠だと考えています。インフラを構築、保守運用するためのコストは低下していきますが、インフラの重要度は変わらずシステムアーキテクチャの根幹を担う技術レイヤーとして、我々エンジニアは今後もインフラの動向を抑えていく必要があるのではないでしょうか。

[PR]提供：エヌ・ティ・ティ・データ先端技術