AWSでDevOpsを実現する ~ DevOpsとは ~

記事タイトルとURLをコピーする

はじめに

こんにちは。技術5課の孔です。昨日、入社式があり、もう2年目になってしまったのか…と思いながら、これからももっともっと頑張って行かないといけないなと思いました。ブログの更新も頑張っていきますので、よろしくおねがいします。

話が変わりますが、先日、AWS DevOps Proの試験に合格してきました🥰 その勉強をした際にAWSにはDevOps体制を整えるために本当に有用なサービスがたくさん提供されているな、ということを実感し、その内容を共有したいと思います。

結構勉強量が膨大だったので、少し小分けにしてブログを配信したいと思います。以下の順番でブログを配信していきたいと思います。

  1. DevOpsとは
  2. AWSでDevOpsを実現するには

今回話す内容は「DevOpsとは」に関してですが、以下のものをご説明いたします。

  1. DevOpsの概要
  2. DevOpsの登場背景
  3. DevOpsを実現するための原則

それでは、Let's get it!!!

DevOpsの概要

DevOpsは「Development(開発)」と「Operations(運用)」が融合した言葉となります。つまり、開発と運用を同じチームで行う、という考え方になります。従来の一般的な開発・デリバリの体制は、以下の順番となります。

  1. 開発エンジニアがサービスを開発する
  2. 開発が終わったらそのまま運用チームに渡す
  3. 運用チームはそれを受け取り、サービスを不具合ないようにデリバリしていく
  4. 機能追加(開発)・・・(繰り返し)

明確に開発を行うチームと、運用を行うチームが分かれて、それぞれのやる業務を分業して行っていますね。しかし、問題があります。大体の場合、開発者はどんどん新しい機能を追加して、サービスをアップデートしていきたがります。一方、運用側はなるべく安定したサービス、信頼できるサービスを提供することを優先して考えます。このような両者間の考え方の不一致によってサービスをスムーズに提供することに問題が発生していきます。

そこで、このような既存のやり方とは違って、「開発と運用を分けずに、同じチームとしてサービスをデリバリしていく」のがDevOpsの考え方となります。ここで「開発チームと運用チームを分けずに同じチームに入れるだけの体制の話」と理解してしまうと、本当のDevOpsの実現には繋がりません。DevOpsは、この体制を含め、サービス提供における哲学、社内文化、パラダイムシフトを含めた大きな概念となります。

この図を見てみると、左側は開発、右側は運用である事がわかるかと思います。このように開発から運用までを一貫して行い、運用からフィードバックを得てサービスに反映し続けることがDevOpsの核心的な価値となります。

以上のことをしっかり抑えた上で、次に進みましょう。

DevOpsの登場背景

先程DevOpsの「哲学」や「考え方(≒パラダイム)」が大事だという話をさせて頂きました。その哲学や考え方を理解するためには、なぜDevOpsという概念が登場したのか、その歴史を辿っていく必要があります。そのため、まずウォーターフォール方式からアジャイルが登場し、そこからDevOpsが登場した歴史をたどっていきましょう。

ウォーターフォール方式は、開発方式は要件を定義し、抜け目のない開発プランを立て、それに合わせて開発を行いました。そこで開発期間が長く、要件が変わった際に柔軟に対応できないという問題が発生しました。このような問題は今まではそこまで大きい問題ではなかったですね。社会の変化が今のように早くなかったため、十分な期間を投資して要件を満たせたソフトウェアがいいものだと考えられてました。

しかし、時代が変わり、お客様の要件が日々変わる時代になった今ではウォーターフォール方式ではどうしても効率的な開発が難しくなってきました。市場の変化速度がものすごく早くなり、開発期間中に何度も何度も要件を変えないと行けない時代になったんですね。そこでアジャイルが登場し、開発をしながら改善を行い、ビジネスの需要に俊敏に対応できるような体制を整える事ができました。開発者はスプリント期間中に開発したソフトウェアをスプリント毎に提供し、発注者はそれを見てフィードバックを行います。大事なのは開発者と発注者が協業し、より市場の情勢に適したサービスを一緒に作っていくことです。

そこで更に一歩踏み出したのがDevOpsの概念となります。アジャイルは「ビジネス相手」と「開発者」間での協業であれば、DevOpsは「開発者」と「運用側」の協業と言えます。既存のウォーターフォールの問題は、常に変化するビジネス要件に対して、俊敏に対応できることができないというのが問題でした。それと同じ問題が開発チームと運用チームの間でも発生しており、DevOpsが登場する前に開発チームは「これ作りたい」という要望に対して運用チームは「テストしてからデプロイするの待ってて」と返し、素早くリリースしたいサービスを何ヶ月も待たなければならないケースが多々有り、俊敏性にかけていました。これは市場の変化が早い今の時期に大きな足枷となりました。

また、既存の方式ではサービスの安定性と予測不可能性にも問題があります。開発した人と運用する人が異なるため、どのようなサービスなのかお互い100%理解するのがとても難しくなります。そのため開発側が想定してない問題が運用の段階で発生したりする問題があり、サービスの安定性と予測不可能性に大きな問題を抱えています。

そこで登場するのがDevOpsとなります。開発からデプロイ・運用まで一つのチームで管理することで俊敏性を高め、安定したITサービスを提供できるようになります。従来の方式に存在した、開発側と運用側の壁を壊し、俊敏に市場に対応できるようになったことにより、もっと素早く変化に対応できるような体制を生み出すことができました。

DevOpsを実現するための原則

それでは、DevOpsを実現するための原則を紹介します。DevOpsを実現するためには、DevOpsチームは以下の5つの原則を守る必要があります。

  • Infrastructure as code
  • CI/CD
  • 自動化
  • モニタリング
  • セキュリティ

詳細を見ていきましょう!

Infrastructure as code

DevOpsでは、インフラをコードで管理します。コードの利点は「何度も再現できる」という点です。同じ環境を何度もプロビジョニングでき、安定したビルドを実現することができます。大体インフラをプロビジョニング際には手動で行うことが多くありました。手動プロセスは人的ミスが発生する可能性があり、厳密性において不安がありました。それに対してInfrastructure as codeを実現することで、同一のコードであれば同一の環境をいくらでもプロビジョニング可能となり、環境構築の安定性・再現性・一貫性を保証することが可能になりました。AnsibleやChef、Dockerなどがこの流れで登場したサービスとなります。

CI/CD

DevOpsでリリースのスピードと安定性を上げるための核心となるのがこのCI/CDとなります。コードを開発して、デプロイするまで発生する数多くのテスト・デプロイ手順を自動化し、コードを書くだけで自動的にデプロイされていく構造はDevOpsを採用して開発を行うチームに従来とは比にならないほどのスピードとデプロイの安定性を実現しました。CI/CDを実現するために登場したサービスとしてCircleCIやJenkinsなどがありますね。

自動化

DevOpsにおいて最も重要な戦略は、「手動プロセスをなくす」ことです。手動で行うプロセスをなくすことによって、人的ミスを減らし、一貫したプロセスを経て開発からデプロイ・運用まで行うことによって常に安定・迅速な開発を行うことが可能になります。

手動プロセスをなくすことは、信頼性を上げる側面から見ても大事ですが、もっと大きな価値を提供してくれます。それはエンジニアが本来やるべき業務(より価値のあるクリエイティブな業務)を行えるようになるということです。

モニタリング

DevOpsもアジャイルと同様、フィードバックを重視します。提供しているサービスが問題なく稼働しているかを常にモニタリングを行い、そこから得られたサービス提供状況をモニタリングしてより良いサービスを提供していくためのフィードバック材料として収集します。

セキュリティ

DevOpsは従来と同様、セキュリティももちろん最優先で考えなければなりません。サービスを守ることはサービス提供者の義務であり、それはDevOpsチームにおいても同じことが言えます。

最後に

以上でDevOpsの基本概念、成り立ち、核心となる原則を見ていました。市場が素早く変化していく中で、従来のやり方を守るのはリスクが高いでしょう。従来のやり方がなぜうまく行ったのかを分析し、変わりつつある今の時代だとどのような手法が最適なのかを絶え間なく考えなければなりません。

今回の記事は以上となります。次回の記事では「それでは、このDevOpsの原則をAWSでどのように実現できるのか」を見ていきたいと思います。それでは、またお会いしましょう!