意外と知らないインフラ構築の落とし穴！ 安定した運用のために押さえておくべきポイントとは

―ここ数年、システム開発のエンジニアがインフラ構築を手がけることが多くなったと聞きました。システム開発のエンジニアがインフラ構築を行う機会が増えたことで、どのような相談を受けるようになりましたか？

　10年ほど前からインフラ系の相談を受けることはあったのですが、ここ数年で急激に増えている印象があります。その理由としては、AWSなどのパブリッククラウドを利用することが主流となってきたことが挙げられます。オンプレの場合は、ネットワーク構成からきっちり設計して細かく設定をしていかないとそもそもシステムが稼働しないので、専門知識のあるエンジニアがインフラを構築する必要がありました。それがAWＳのようなパプリッククラウドの場合は、ネットワークなどをあまり気にしなくてもサーバを作成するだけで動くには動くので、専門知識がなくてもインフラ構築ができてしまいます。

　基本的にインフラを構築するのは新たにシステムをつくるときですよね。自社で大勢のエンジニアを抱えている企業でない限りは、外部のエンジニアに開発を委託することが多いと思います。初期構築の段階で「インフラを維持・管理していくためには、まず要件を確認し、そのためにはこういう作業をする必要があり、月々これだけの費用がかかります」と委託されたエンジニアはお客さまとしっかり認識を合わせるべきなのですが、経験や知識が少ないために曖昧な状態で話が進んでしまうことが多いんです。そして発注したお客さまとしては、運用や維持もやってくれるものと思い込んでしまうことが多いです。

　しかし、このようなインフラ構築を伴うシステム開発の場合は、エンジニアとしてはシステム開発がメイン業務なので、インフラに関してはその後の維持・管理を考慮せず、今動くかどうかを優先して構築してしまいがちです。その状態でも数年くらいは問題なく稼働するとは思いますが、その後の運用を考慮していないので、使い続けているうちに更新や修正が必要になったり、セキュリティの問題が出てきたり、保守切れでシステムが上手く稼働しないといった問題が出てくるわけです。そこで調べてみたら、これまで誰もメンテナンスをしていなかったことが分かって、「開発会社にも連絡がつかず、もう自分たちでは手に負えない…」と、私たちに相談をいただくケースが多いですね。

―インフラ構築をシステム開発エンジニアが対応するのは、インフラにあまりコストをかけられないため、費用を抑えられるようにシステム開発とセットで依頼している状況にあるということですか。

　そうですね。インフラの構築や保守・運用にコストをかけてもサービスの売上には直接には繋がらないし、すぐに問題となるわけではないので、できればその費用は最低限にという意識があるのだと思います。インフラは稼働していて当たり前なので、何か問題があるまでは誰も意識しない。でも、いつかはかならず不具合が起きます。何年間もメンテナンスをせずにいたインフラを整備しようとしたら、結局それなりのコストがかかってしまいます。それなら毎月ちゃんとメンテナンスをする方が安全ですし、トータルコストは安くなるのに、と思ってしまいます。

―構築したインフラをきちんと運用していくためにはどうしたらいいのかを教えてください。

　インフラ運用としてやらなければいけないことをきちんと明文化すること、例えば運用設計書をつくることが大切です。アプリケーションを開発する場合は、フローチャートをつくって業務プロセスや業務フローを可視化して管理しますが、運用に関する同じようなレベルの資料は大規模なプロジェクト以外では、ほとんど見たことがありません。設計が記されている資料がないと、「どこの」「誰が」「どこまで」「何をするのか」が曖昧になります。

　例えばセキュリティに詳しい開発エンジニアがプロジェクトの中にいるとします。小規模のプロジェクトの場合はそのエンジニアがセキュリティ担当のような位置付けになります。ただセキュリティといっても、ハードウェア・アプライアンス・ネットワーク・OS・ミドルウェア・データベース・アプリケーションなど、さまざまなレイヤーがあります。しかし開発エンジニアが判断できるのはアプリケーションやデータベースまでで、その他は「えっ？ 私ですか？」という具合で、そこまでは確認もしていないし、判断もできませんよ、というような事態が起こるわけです。
　これは、「どこの」「誰が」「どこまで」「何をするのか」を曖昧にしたまま運用してしまったことが原因です。シートを一枚作っておけばこういったグレーゾーンはできません。この一つ一つが、一枚一枚になり、一冊になると、運用設計書ができあがると思います。とにかくアウトプットが重要だと思います。

―運用設計書はどのようなものをつくればいいのでしょうか。

　先程の話の通り、設計書といっても大げさに考える必要はありません。検討したことについて、こういう方針で運用をやりますよという内容をドキュメントとしてまとめるくらいでもいいですし、powerpointで図をつくるという方法でもいい。何が考慮されていることで、何を考慮していないのかがわかるだけでも良いです。そういった簡単な資料があるだけでも、運用やその後の改善が円滑になると思います。また更新も重要です。
　特定のエンジニアがそのシステムの運用が終わるまで運用・管理をするのであれば、設計書の作成も更新も必要ないかもしれませんが、レアなケースですし、想定できるものではありません。次の人が設計書を見て、今まで何をしていたかが分かり、今後何をすればよいのかをイメージできる、そういう運用設計書をつくってほしいですね。

　最近はオンプレやプライベートクラウドの保守が切れるタイミングで、システムをAWSなどのクラウドサーバに移行する案件が増えています。OSやミドルウェアが変わることによる影響などはわかりやすいのですが、他の部門で実施している業務や外部との連携などは設計書に記載がないと、移行後に考慮不足・作業漏れとなり、実行後に追加調査や追加作業などで費用がかさんでいきます。費用を抑えて移行する方法として、仮想化してそのままAWSに持っていくという方法もありますが、これは問題を先延ばしにしているだけなので、数年後にはまた同じ問題が起きてしまいます。
　今は大丈夫でも、運用を意識していないといつかは大きなトラブルになるのがインフラだということは常に意識しておくべきだと思います。

―今、インフラ管理をしているエンジニアは、どういうことを意識し運用・管理すればいいですか。

　インフラエンジニアの数が減っていることもあって、管理者がいないインフラを手探りで立て直すケース、少人数で大量のインフラを管理するケースなど、日常的に地雷に囲まれているような環境が増加傾向にある、と仲間内で話しています。そのようなシステムを正常状態に戻すには時間もコストも掛かるので、なるべく早めにアウトソーシングを行い、日頃からリスクヘッジをするのがBetterだと思います。トラブルが起きたときに「火中の栗を拾ってくれる人」がいればよいですが、そのような人がすぐには見つからない場合は、常に相談できるサービスを契約しておくことは有効だと考えています。
　僕自身もシステム管理者という立場なので分かるんですけど、自分だけですべて判断し、対処しなくてはいけない状態というのは、結構しんどいです。「こういう方法はどう思う？」「どういうリスクが想定される？」「他にどんな方法がありそう？」と、気軽に相談できる先を持っておくのはすごく助けになりますし、いざトラブルが起きてから頼る先を探したり、業務全てをアウトソーシングしたりするよりはコストは低く、効率的だと思います。

―リンクではインフラ運用をサポートするサービス『ベアサポート』を提供しているそうですが、詳しく教えてください。

　ベアサポートは、AWSやAzureなどのクラウドサーバやオンプレなどインフラの環境を問わず、お客さまのシステムを24時間365日監視するMSP（マネージド・サービス・プロバイダ）サービスです。一般的な監視・運用サービスと大きく違うのは、ベアサポートは技術支援としてインフラ、システム運用に知見のあるエンジニアに相談できるという点です。「インフラ構築でここが分からないから教えてほしい」とか、「こんなトラブルが起きたんだけど改善方法を教えてほしい」といったお問い合わせにも対応しています。まさに気軽に相談できる窓口としての役割を担っています。

　その他に通常の監視・障害対応の作業とは別にエンジニアを10時間分、自由に使っていただけるサービスも展開しています。例えば監視・運用の設計やドキュメントの整備から、システムのアカウント管理、ミドルウェアのチューニングや、適切なサーバの構成やサイジングの提案など、実際の作業からコンサルティングのような内容まで、10時間分お客さまの要望に応じてエンジニアが対応しますというものなので、さまざまな用途でご利用いただいています。

―これからインフラをつくる必要があったり、今の運用に悩んでいるという場合にはぴったりのサービスですね。

　そうですね。リンクはサーバホスティングのイメージが強く、リンクのサーバを利用していないとベアサポートを利用できないと思われている方が多いのですが、AWSなどの他のクラウドサーバやオンプレにも対応していますので、ぜひ多くの方に利用していただきたいですね。今インフラで困っていることがある方は、ぜひ相談をしていただければと思います。