DevOpsの原則に従い管理コストを大幅に下げることができた話　

はじめに

デブオプスリードカンパニーの窪田です。

企業のデジタル変革を表す言葉として近年よく耳にしたDX(デジタルトランスフォーメーション)という言葉はもはや当たり前のように用いられるようになりました。
そんな中、DXの一環として、様々な企業でDevOpsに取り組むようになりました。
そういった背景から、エンジニア界隈にDevOpsという言葉が浸透し始めてきたなと感じます。

本記事では、そのDevOpsを用いて改善活動を行ってきた一例を紹介したいと思います。

DevOpsとは？

「DevOps」とは開発（Development）と運用（Operations）という言葉の組み合わせによる造語です。
それは、1つの開発手法を表す言葉ではなく、システムやソフトウェアの開発者と運用者が密に連携し、柔軟な開発と運用を実現するための考え方や方法論を指します。
この「DevOps」を実現するために重要として定義されている、4つの原則があります。

1. ソフトウェア開発ライフサイクルの自動化
2. コラボレーションとコミュニケーション
3. 継続的な改善と無駄の最小化
4. ユーザーニーズの重視と短いフィードバックループ

参考：https://thinkit.co.jp/article/19985

今回は上記のうち「継続的な改善と無駄の最小化」に従って改善し、自分たちが管理しているコストを大幅に下げることができた話をしていきます。

改善前の状況

私のいるチームは、あるクライアント様のサイトのインフラ管理をやっています。
AWSを利用して、サイトをホスティングするためのネットワークやサーバーなどの構築を行い、インフラの運用をしていました。

サイトのホスティング後は、開発業務やサイト運営の効率化に向けての要望、さらに自分たちの運用効率化や自動化などを目指し、様々なサービスを利用してAWSリソースを作成していきました。
そうしていくうちに、どんどん管理リソースが膨らんでいってしまいました。

そうして追加を重ねた結果、利用していたサービスは以下のとおりです。

• AWS
  • Route53(ドメイン・DNSレコード管理)
  • ACM(SSL証明書)
  • EC2(サーバー用仮想マシン/CentOS)
  • ELB(冗長構成による負荷分散)
  • EFS(primary/secondary間データ同期)
  • RDS(サイトで利用するDB、マルチAZによるクラスター運用)
  • S3(ログ関連保存領域、AWS別アカウントへのレプリケーション設定あり)
  • Cloudwatch(リソース・サーバー監視、アラーム発火、Canaryによる外型監視)
  • Cloudfront(カスタムエラーレスポンスによるソーリーページ処理)
  • Eventbridge・SNS(イベント検知、Lambdaのトリガー)
  • Backup(AMI、スナップショット、サイトコンテンツ)
  • Lambda(バックアップ用AMI更新やEFSモード変更などの自動化用コード)
  • Chatbot(イベントのSlack通知)
  • IAM(各種ロール管理)

サービスごとに見ると、EC2を冗長構成にするためにVPCやサブネットを作る必要があり、細かいリソースもいくつか必要でした。また、サイトをホスティングするためには、必要なミドルウェアやソフトウェアのインストールを実施、定期的なアップデートを行う必要があります。
他にも、同ドメインを利用している別サイトへリバースプロキシの設定を行う必要があったりなど、サーバー維持に必要な作業もありました。
それらを、本番環境・ステージング環境・インフラ改善/不具合調査用環境の3つの環境で管理する必要があり、非常に多くの作業が必要でした。

AWSで構築したリソースはすべてソースコード(Terraform)で管理していましたが、次第に管理するコードはどんどん増えていき、それに伴って自動化できない細かな手作業も増えました。
利用するサービスが増えているので当然費用コストもかさんでいきました。
また、利用サービスが増えてインフラ構成も複雑化し、チームに新しいメンバーを迎えた際の認知負荷も高い状態でした。

私たちはDevOpsの原則にある「ソフトウェア開発とライフサイクルの自動化」を目指して業務効率化を図るべく、いわゆる「足し算」の考え方で色々なサービスを駆使してきました。
もちろん、それによって日々負担となっていた作業の軽減や効率化されたことによって有効的に時間を活用できるようになった、などの恩恵はありました。

しかしその反面、管理コストは重くなっていき、しだいにチーム全体で管理がしんどくなっていくという負の連鎖に入っていることに気づきました。

改善に向けて

これを改善すべく、足してダメなら引きましょう、という方針に。EC2などを使って行っているサイトのホスティングをやめ、外部のマネージドサービスを利用することにしました。
管理しているサイトはCMSにWordPressを用いているので、WordPressマネージドサービスを利用する方向で検証を重ねました。
私たちの問題点を照らし合わせた結果、WordPressマネージドサービスを利用することで以下のようなメリットがあることがわかりました。

WordPressマネージドサービスを利用するメリット

• サイトの維持に利用していたサービスのほとんどが不要になる
• サービスが不要になった分、ソースコード(Terraform)が少なくなり、管理が簡易になる
• 負荷分散などに利用していたELB・RDS・EFSなどのネットワーク管理を自分達の責任範囲から手放すことができる
• バックアップやステージング環境などの環境複製はWordPressマネージドサービスの機能により簡単に作成可能
• AWSで利用していたほとんどのサービスが不要となることで、結果的に費用コストが大きく下がる
• EC2内で利用していたサーバーにインストールしていた様々なミドルウェアやソフトウェアのバージョンアップなどの管理作業も合わせて手放すことができるので、インフラの運用負荷が大きく下がる

そしてWordpressマネージドサービスを利用するようになり、結果的に現在利用しているAWSサービスは以下のようになりました。

• Route53(ドメイン・DNSレコード管理)
• Cloudwatch(Canaryによる外型監視)
• Cloudfront(サーバーに設定していたリバースプロキシの代替)
• IAM(各種ロール管理)

このように箇条書きにすると、様々な部分で負荷が大きく下がったなと改めて実感します。
ということで、サイトの移行も無事済ませ、WordPressマネージドサービスで現在運用中です。
ですが、Wordpressマネージドサービスで運用してみてデメリットも見えてきました。

WordPressマネージドサービスを利用するデメリット

• Wordpressマネージドサービス起因のインシデントなどで予期せぬ障害が発生する可能性がある
• ホスティングするためのサーバーのコンフィグはユーザーの権限では行えず、WordPressマネージドサービスのサポートに依頼して設定してもらう必要がある
• サーバーのコンフィグがユーザー権限で行えないので、サポートを通して設定したコンフィグの内容をこちらで把握しづらい

特にデメリットと感じているのは「サーバーの設定をユーザー権限で行うことができない」というところです。
サーバーの細かなチューニングをする度、サポートに依頼し、設定してもらう必要があるのでこの部分の作業は負担に感じています。
上記に付随して、サーバーのコンフィグファイルの内容をこちらで見ることができないのも合わせて負担に感じています。

一度、サーバーのコンフィグへの新たな設定の投入を依頼しましたが、サポートとチャットベースでコンフィグの内容をやりとりしながら設定したため、そこそこ時間もかかり、なかなか苦労しました。
サーバーのコンフィグ設定はそこまで頻度の高い作業ではないこともあり、依頼時の一時の負担と考えればそこまで大きくはないですが、なかなか難しいと感じています。
それでも、サーバーの管理に関する作業はほぼ自分達の手から離すことができたので、このデメリットを勘案してもWordpressマネージドサービスを利用するメリットの方が大きかったです。

さいごに

一口に「インフラ運用に関わる改善」といっても、アプローチは様々だと思います。
自分達が有するクラウドなどの資源を使いながら改善していくのはもちろんですが、それ以外のサービスを利用することで大きく改善できることがわかったのは、今回の大きな学びとなりました。
ただ、運用方法そのものを見直すことは私たちのチーム内だけで完結する話ではなく、インフラを利用している開発者や各種サービスの経理担当など、様々なチームの協力が必要不可欠です。

これもDevOpsの原則にある「コラボレーションとコミュニケーション」が非常に大事だと実感した次第です。
協力していただいた関係者の方々に感謝です。
もちろん、移行して終わりではなく、大事なのは「継続的な改善」なので、これからも引き続き業務効率化を目指して日々取り組んでいこうと思います。

それでは。