みなさんはじめまして！
プラットフォームエンジニアリング部門、サービスインフラグループの見市です。私たちのインフラグループは、年間売上高2700億円を超える事業を支えるインフラ環境をわずか十数名で構築・運用しています。
今回は、インフラ運用の中で避けては通れないOS EOL対応に、私たちがどのように向き合い取り組んでいるのかをご紹介したいと思います。
モノタロウのインフラ構成
モノタロウのインフラ構成は、オンプレミスとマルチクラウドのハイブリッド構成になっています。今は当社のECサイトを支えるサービスがモダナイズ化されつつあり、サーバ上にアプリケーションデプロイする方式は縮小傾向にあります。とは言え、まだまだ多くのサーバが稼働しており、それらの中にはOS EOLを迎えたものが約300台あります。EOLを迎えたサーバをそのまま運用することは、セキュリティリスクや運用負荷の増大につながります。多くの企業のインフラエンジニアの皆さんも同様の課題に直面していることでしょう。OS EOL対応は技術的な問題だけでなく、組織横断的な協力が必要な取り組みです。
従来のOS EOL管理と課題
これまで、OSのディストリビューションやバージョンの情報は厳密に管理されておらず、開発者もOSの情報を強く意識はしていない現状があり、インフラグループでそれらの情報を手動でGoogle スプレッドシート上にまとめた上で半年に1度案内し、状況を確認するという対応を行っていました。この取り組みによって開発者にOS EOLを意識していただけるきっかけになりました。しかし、インフラグループの管理工数が多く、また稼働するサーバ台数が多数存在しているため、手動での管理が限界を迎えていました。
OS情報の収集自動化による課題の解決
上記課題の解決のため、OS情報を自動で収集する仕組みの検討をはじめました。先ほど述べましたとおり、当社のインフラ環境はオンプレミス + マルチクラウドなハイブリッド環境なので、まずはこのハイブリッド環境下で情報を一元管理する方法の検討を始めました。当社ではBigQueryに情報を集約し、Looker Studioで情報を可視化する取り組みがIT組織に関わらず全社的に展開されているので、その仕組みをベースに検討しました。そこで、AWSとオンプレミスのサーバについてはAWSのSystems Manager（以下、SSM）を利用した情報収集を、Google CloudについてはSecurity Command Center（以下、SCC）利用してOS情報を収集し、それらを最終的にBigQueryへ保存し、Looker Studioで可視化することにしました。また、半年毎にEOL対応の進捗を管理するため、JIRAプロジェクトを準備し、新しいサーバ情報がBigQueryに保存されたら、自動でJIRAチケットが起票されチケットの最新コメントがLooker Studio上で表示されるようにしました。
実装の詳細
AWS / オンプレミス
EC2はデフォルトでSSM Agentがインストールされているため、自動でフリートマネージャーへ必要な情報が収集されます。一方で、オンプレミスのサーバには手動でSSM Agentをインストールする必要があります。当社では、OSおよびミドルウェアの設定にAnsibleを用いて構築・運用しています。そこで、オンプレミスのサーバにSSM Agentを導入するためのAnsible Playbookを整備し、自動でSSM Agentが導入できるように対応しました。そして、フリートマネージャーに収集された情報をS3バケットへ出力し最終的にGoogle CloudのBigQueryへエクスポートすることで、情報を集約させました。
Google Cloud
Google Cloudの環境では、セキュリティの観点から以前よりSCCを導入しており必要な情報は収集できており、またそれらの情報はすでにBigQuery上に蓄積されていたので、そちらを利用することにしました。
以下が、簡単な構成図となります。
サーバ毎にJIRAチケットを起票
サーバ毎にEOLの対応状況は異なります。例えば、アプリケーションをコンテナ環境に移行する、別サービスとしてリプレースする、サービスを廃止するなど様々な状況があります。インフラグループだけではそれらの情報をすべて把握することは困難であるため、これまでは手動で管理していたスプレッドシート上で半年に1回開発者の皆さんに状況を記入してもらう運用となっていました。EOLを迎えたサーバが多いとスプレッドシートの管理も煩雑になってきており、この点も自動化したいポイントでした。そこで、上記の仕組みでBigQueryに新規で登録されたサーバについては、自動でOS情報を記載したJIRAチケットが起票され、対象チケットに記載した最新コメントをダッシュボードに表示することで、ダッシュボード上で最新の進捗が確認できるようになりました。以下が、実際のダッシュボードの例となります。
工夫したポイント
本番環境への導入に対する懸念の払拭
開発環境やステージング環境については、大きな懸念などなくAgentのインストールを行えました。しかし、本番環境では、特に新規パッケージ導入などが諸事情により困難なサーバも存在していました。そういったサーバについてはAgentの導入を諦め、BigQueryに直接データを投入することで情報の管理を行うことにしました。運用上どうしてもAgentの導入が必須なわけではなく、またOSの情報は日々変化していくようなデータでもないため、この点はある種割り切って対応しました。
データ転送の安定化
SSM Agentで収集したデータは、S3へ保管後にBigQuery Data Transfer ServiceでデータをBigQueryに転送しています。しかし、必要なデータが一部転送されない問題がありました。当初は原因はわからずクラウドサポートに問合せながら解決の道を探っていましたが、1度ではデータが転送されないことがあるものの複数回試行することで最終的に必要なデータが転送されることが分かったので、転送間隔をある程度確保してデータを収集することにしました。
既存設定の移行
過去にスプレッドシート上で管理していた情報（特に、過去のEOL対応実績）はスプレッドシート上にしか存在しない情報になります。これらのデータは人海戦術で必要な情報をBigQueryへ投入しました。
運用の標準化
自動化の仕組みを作ったあと、構築メンバー以外でも対応可能なように、設計および運用のドキュメントを作成しました。当社では、運用ドキュメントはRunbookと呼んでおり、RunbookでEOL対応を行うための必要な手順を画像付きで整備し、運用の標準化を行いました。
導入効果
これまで半年毎にインフラグループから開発者向けにEOL情報の発信を行っていました。手動で情報をリストアップし開発者にアナウンスを行うまで、他タスクとの兼ね合いもありますが約1ヶ月を要していました。EOLの管理・運用はなにか新しい価値を提供できるような取り組みではなく、負債を解消する取り組みとなり、インフラグループを含め腰の重たいタスクでありますが、今回の取り組みによって手動対応はほぼなくなったため、周知の時期が来ると定例MTGなどでダッシュボードを案内するだけで事足りるようになり、他の価値を生み出すタスクにリソースを割くことができるようになりました。
また、これまでは手動対応となっていたため半年に1度しか情報がアップデートされない運用となっていましたが、自動化することによりリアルタイムに情報を収集でき、より鮮度の高い情報提供ができるようになりました。
今後の展開
現在はOSのバージョン情報など必要最低限の情報収集・可視化にとどめていますが、OS上でインストールされているパッケージなども収集が可能です。それらの情報と脆弱性情報データベースを組み合わせることにより、EOL情報に加えて脆弱性情報なども自動で収集・管理できるようになり、リスクの可視化が可能となります。エンジニアにとっては耳の痛い情報ですが、リスク管理という点では非常に重要な点になりますので、これらの情報を収集・管理していくことで企業のリスク低減に貢献できると考えています。
まとめ
今回は、ハイブリッドな環境でOSのEOL管理を自動化するために、AWSやGoogle Cloudのサービスを組み合わせて可視化した詳細とその効果についてご紹介しました。私が所属しているプラットフォームエンジニアリング部門では、開発者が開発に専念し生産性を向上することで事業へ価値を提供できるため、必要となるプラットフォームの構築・提供を行っています。プラットフォームを運用していく上で避けては通れない負債解消の活動の1つとして、EOLの運用を自動化するという取り組みも実践していることが伝われば幸いです。
このEOL管理の自動化プロジェクトを通じて、私自身もクラウドサービスの活用スキルや大規模システムの運用知識を深めることができました。こうした「現場の課題」を現場のエンジニアが提起し、自ら主導して実装・解決できる環境、文化があります。本記事をお読みいただいているみなさんも、ハイブリッド環境でのインフラ構築・運用を支えながら事業の成長に貢献してみませんか。
私たちと一緒に働くことに興味がある方は、カジュアル面談も実施しております。ぜひご連絡をお願いします。
