【インフラエンジニアの仕事とは】非機能要求グレードを使って非機能要件を実現する方法を解説 -

1. インフラエンジニアとは

　IT業界におけるインフラエンジニアとは、主にITシステムの非機能要件を満たすために、システム基盤の設計・構築・運用を担う技術者です。「非機能要件」と聞いても、一般にはイメージしづらいかもしれませんが、これは顧客が求める機能そのもの以外の要件を指します。独立行政法人情報処理推進機構（IPA）が示している非機能要件には、以下のようなものがあります。

可用性
性能・拡張性
運用・保守性
移行性
セキュリティ
システム環境

　インフラエンジニアは、これらの非機能要件を満たすために、技術的な工夫と知見を駆使して業務に取り組みます。自社でサービスを提供している組織であれば、自ら非機能要件を明確にし、それに基づいてシステム開発を進めることができます。しかし、顧客から受注してシステムを構築する場合は、そう簡単ではありません。理想的には、顧客が非機能要件を明確に定義し、インフラエンジニアに提示してくれるのが望ましいのですが、機能要件とは異なり、顧客自身が何をどの程度定義すべきか分かっていないケースも多く見受けられます。そのため、インフラエンジニアには、コンサルタント的な視点を持ち、顧客と共に非機能要件を整理・検討し、要件定義を支援する能力も求められます。

　インフラエンジニアの具体的な担当範囲はプロジェクトにより異なりますが、一般にはサーバー、ネットワーク、ストレージといった物理機器に加え、仮想化ソフトウェア、データベース、アプリケーションサーバーなどのミドルウェアも取り扱います。
近年では、クラウドサービスを導入する企業も増えており、クラウドの設計や運用もインフラエンジニアの重要な業務となっています。

　このように、インフラエンジニアは幅広い技術領域をカバーし、常に最新技術を習得する必要があるため、技術に興味がある人にとっては、非常にやりがいのある分野といえるでしょう。

2. 非機能要件とは

　非機能要件とは何かについては、独立行政法人情報処理推進機構（IPA）が提示している「非機能要求グレード」を参考にするのが一般的です。プロジェクト特有で整理した非機能要件がない場合は、非機能要求グレードを使っておけば及第点は取れると思いますので、ぜひ取り入れてもらえればと思います。
参照リンク：IPA 非機能要求グレード

2.1 非機能要求グレード導入の目的

　ITシステムを構築するベンダーと、それを発注する顧客との間で非機能要件を定義・合意しておくことは極めて重要です。なぜなら、システムがある程度完成した段階でベンダーと顧客の認識にずれがあることが発覚すると、手戻りによる追加作業がになる場合があるからです。また、必要なハードウェアのスペックが不足しており、結果的に要件を満たせないという深刻な問題に発展する可能性もあります。しかし、先にも述べましたがITシステム構築が専門ではない顧客にとっては、どのような非機能要件を、どのレベルで提示すればよいか分からないというのが実情です。そこで有効なのが、IPAが提示している「非機能要求グレード」です。このドキュメントを活用することで、ベンダーと顧客が非機能要件について具体的かつ明確に合意を形成できるようになり、後の認識齟齬によるトラブルを未然に防ぐ有効な手段となります。

2.2 非機能要求グレードの概要

　非機能要求グレードは、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つのカテゴリで定義されています。近年ではクラウド上にシステムを構築するケースが増えており、「システム環境・エコロジー」については検討事項が少ない場合もあるかもしれません。しかし、それ以外の項目については適切に検討を行い、ステークホルダー間で合意を得ておく必要がありますので、ご認識ください。

2.3 非機能要求グレードの各項目の説明

前節で説明した非機能要求グレードの大項目ごとに、中項目/小項目をそれぞれ説明していきます。合わせてノウハウも記載しますのでぜひ参考にしてみて下さい。下記のような条件を想定したノウハウとなります。
・ITベンダからの目線
・比較的大規模、ミッションクリティカルなシステム

□可用性

<継続性>
・オンライン処理、バッチ処理など処理方式が複数ある場合は、それぞれについて業務継続の方針を決めておいた方が良い。
・業務継続性の観点から、SPOF（単一障害点）が存在する場合は必ず明記しておきましょう。サーバやスイッチについては、冗長構成により業務継続性を確保するのが一般的です。ただし、例えばストレージ筐体については、単一構成を採用しているシステムも多く見受けられます。
・Active-Standby構成を採用している機器については、切替に要する時間を事前に合意しておきましょう。Active-Standby構成では、トラブル発生時の切替中に一時的な業務エラーが発生する可能性があります。運用開始後にトラブルが発生した際、顧客とのトラブルを避けるためにも、切替時間の目安を明確にしておき、試験により要件を満たしていることを確認しておくことが重要です。
・稼働率については、慎重に顧客と合意を図るようにしましょう。ミッションクリティカルなシステムでは、99.999％（年間で約5分の停止）という高い稼働率が求められることがありますが、オープンシステムでこれを実現するのは非常に難易度が高いと言えます。また、クラウドを利用するシステムにおいては、現時点では99.999％の稼働率を実現するのは困難です。そのため、各クラウドサービスのSLA（サービスレベルアグリーメント）を十分に確認し、全体としての稼働率を慎重に検討・設定することが重要です。

<耐障害性>
・物理機器については、部品レベルで冗長構成になっているかどうかをハードベンダに確認しましょう。

□性能・拡張性

<業務処理量>
・一般的なWebシステムにおいては、大量のアクセスからシステムを保護するため、同時アクセス数に制限を設けるのが一般的です。ロードバランサーやWebサーバーなど、複数の箇所で流量制御を設定することが望ましいため、どの機器でどのような制御を行うかを事前に検討しておくことを推奨します。
・オンラインリクエスト件数については、単位時間を明確に定義しておくことが重要です。たとえば、バーストトラフィックに対応するために「1,000件／秒」に耐えられるシステム構成を組むとなると、オーバースペックになる可能性があります。要件としては「10,000件／分」程度に設定し、バーストトラフィックが発生した場合でも、1分単位で見れば要件を満たしていると言えるようにしておく方がITベンダからしたら安全な要件となります。顧客と十分に議論し、合意を得ておくことを意識してください。
・業務量がどの程度増加する可能性があるのか、事前に明確にしておきましょう。特に、オンプレミス環境で構築しているシステムの場合、リソース拡張に上限があるケースもあるため、あらかじめ留意しておく必要があります。

<リソース拡張性>
・CPUやメモリの使用率を評価する際は、測定に用いる単位時間を事前に決めておくことが重要である。特にCPU使用率は瞬間的に大きく変動することがあるため、単位時間を短くしすぎると、リソースを過剰に見積もってしまう可能性がある点に注意が必要となります。
・サーバの処理能力を増強する方針として、スケールアップにするのかスケールアウトにするのかを、サーバの種別ごとにあらかじめ決めておくことが重要です。特に物理サーバの場合は、CPUやメモリ、ディスクなどの部品が販売終了になったり、スロットが埋まっていてスケールアップができなくなることがありますので、注意が必要です。
・HWリソースを占有する対象を決めておきましょう。例えばシステムの根幹となるDBサーバは占有機器として構築し、他のサーバの影響を受けないようにしておくことが一般的です。
・スパイク負荷発生時にもシステムが全面サービス停止とならないような設計を考えておきましょう。DDoS対策の製品を導入するといった選択肢も検討してみて下さい。

□運用・保守性

<通常運用>
・バックアップの世代数や保存期間は、事前に明確に決めておきましょう。これらはディスク容量の見積もりに大きく影響する重要な要素であり、場合によっては後からディスクを追加購入する必要が生じる可能性がありますので注意してください。また、バックアップ対象のデータが複数ある場合は、それぞれについて要件を明確にしておきましょう。
・運用監視は非常に重要な要素であるため、何の項目をどのくらいの間隔で情報取得するかを十分に検討してください。たとえば、CPU使用率の取得間隔が5分では、トラブル発生時に原因を特定できない場合があります。重要な項目については、システムリソースに影響を与えない範囲で、取得間隔を短くすることを検討しましょう。また、項目によっては標準のコマンドでは取得できず、スクリプトを作り込んで監視する必要がある場合もありますので、ご留意ください。

<保守運用>
・パッチ適用の方針や適用頻度をあらかじめ明確に定めておきましょう。パッチ適用に際しては、影響範囲の確認やエージングを含む試験の実施など、多くの手間と時間がかかる作業が伴います。そのため、緊急の脆弱性対応やサービス全体の停止につながる深刻なバグへの対応を除き、通常のパッチについては、ある程度長期的なスパンでの定期的な適用を推奨します。
・パッチ適用の対象は、OSやミドルウェアに限らず、機器のファームウェアも含めるようにしましょう。また、機器ベンダーから定期的に情報提供を受けられるような場を設け、早期の情報収集に努めることが重要です。
・活性保守ができない対象については、あらかじめ明確にしておきましょう。ローリングアップデートに対応したコンポーネントは活性保守が可能ですが、たとえばActive-Standby構成のコンポーネントでは、切り替え時に瞬断が発生する場合があります。また、データベースのテーブル構造を変更する際には、システムの停止が必要となることがあり、これらは活性保守の対象外です。このように、活性保守が困難なケースも少なくないため、後々の顧客とのトラブルを避けるためにも、事前にその旨を説明・共有しておくことが重要です。

<運用環境>
・可能な限り本番環境と同等の開発環境を用意できるよう、顧客と交渉しておきましょう。開発環境で十分な試験が実施できなかったために本番環境でトラブルが発生するケースは少なくありません。
あとで後悔しないように、必要性を具体的かつ明確に説明して理解を得ることが重要です。

<サポート体制>
・ハードウェアおよびソフトウェアの保守契約を念入りに確認しておきましょう。システムのライフサイクル中に、通常サポート期間が終了してしまうことは少なくありません。そのため、延長サポートの有無や、終了後のサポート内容（対応範囲・サービスレベルなど）について、あらかじめ明確にしておくことが重要です。

□移行性

<移行時期>
移行スケジュールについては、十分な検討が必要です。顧客としては、可能な限りサービス停止期間を短縮したいと考えていますが、ITベンダーとしては現実的かつ実行可能なスケジュールを提案し、可能な限りリスクを低減すること重要です。

□セキュリティ

＜ネットワーク対策＞
・最近はDDoS攻撃による被害が多発していますので何かしら対策を講じた方が良いです。AkamaiやCloudflareなどの外部サービスを利用することも検討ましょう。

□システム環境・エコロジー

3. さいごに

インフラエンジニアの仕事は非機能要件を満たすことにある、ということで非機能要求グレードについて説明してきました。検討すべき事項が多いため、すべての項目について最初から顧客と合意するのは難しいプロジェクトもあるかもしれません。しかし、少なくとも重要な項目については事前に検討し、議論を重ねておくことが大切だと考えています。非機能要求グレードを有効活用して要件定義をしっかり行うことで、後工程における顧客との認識のずれによるトラブルを防いでいただければと思います。最後まで読んでくださってありがとうござました。