Inquiry icon

START A CONVERSATION

Share your requirements and we'll get back to you with how we can help.

Thank you for submitting your request.
We will get back to you shortly.

企業のDevOps転換を後押し

技術革新に左右されるビジネス業界で成功を収められるかどうかはIT アジリティを備えているかどうかにかかっています。DevOpsコンサルタント企業である当社は、企業がクラウドネイティブ技術や自動化、継続的デリバリーモデルに適合できるよう、また、機敏性を維持できるようサポートします。こういった技術の導入は新興企業にとっては比較的容易でも、従来の企業環境に取り入れるには、より具体的な取り組みが必要です。

利害関係(変化か現状維持か)によって対立する、元々独立したチームによる従来のビジネス機能では、急速に変化し続けるビジネス環境に対応できません。DevOps転換は、このサイロ化されたアプローチを、顧客、デザイン、生産およびリリースと相互に関連する単一のバリューストリームへと、段階的な改善を通して転換していくことを目指すものです。これには、組織構造、企業文化、技術スタックの3つのレベルでの変化が求められます。

DevOpsコンサルティング

DevOpsコンサルタントが、何をどう変えればいいかを明確にするお手伝いをいたします。迅速な評価を行って、変革を始動させましょう。

バリューストリームの特定とマッピング

多くの企業が、開発を加速化して革新を支える必要性を認識しています。また、品質や信頼性、セキュリティを損なうことなくアジリティを獲得するには、長年の仕事のやり方やプロセスを変更する必要があるということにも気づいています。多くの企業がつまずくのが、どこからどのように始めればいいかの見極めです。当社のコンサルタントが、この関門突破をお手伝いします。

当社のDevOpsアーキテクトが、お客様のチームの協力を得、経営陣の方々に情報やご意見を伺いながら、各段階のプロセスや活動を理解していきます。DevOpsアーキテクトは、価値を高めるステップとそうでないステップとを明らかにします。こうした、現状のバリューストリームのマッピングによって、プロセスにおける重要なステップや最適化する必要のある改善点を系統的に可視化できるようになります。

バリューストリームの流れの改善

バリューストリームの現状が分かるようになると、バリューストリームの流れの改善のための無駄の洗い出しも、それらを軽減または排除できる方法を見つけ出すことも容易になります。そうなると、最大限の自動化を可能にし、より短いサイクルでより高品質の完全なソフトウェアをリリースできる、バリューストリームの未来像マッピングの設計へと進めるようになります。

バリューストリームマッピング(VSM)後に、ワークフローの管理および最適化の方法として多くの企業が用いているのが、看板方式といった手法です。ワークフローを可視化することで、全プロセスの統一的な全体像が得られ、各チームが最終製品にどのように貢献しているかが明確に把握できるようになります。

ソフトウェア開発バリューストリームの流れを改善するためのステップ

  • 作業を可視化する(看板を用いるなど)
  • 仕掛品を軽減または制限する
  • チーム間の引継ぎ数を減らす
  • ビルド、テスト、セキュリティチェックおよびデプロイを自動化する
  • 小ロットでリリースする
  • フィードバックを迅速に行う

チーム編成

DevOps転換を図るため、共通の目標、プロセスやツールに基づいてチームを再編成する必要が出てくる場合もあります。開発と運用は、価値を提供できる機敏性に優れたチームとして、相互に機能させる必要があります。こういった編成にすることで、十分な権限が与えられ、自立した機能横断型チームとなります。スケジュールが決まっているプロジェクトを推進する場合に、このようなチームを、さまざまな部署の人材を集めて一時的に結成することも可能です。引継ぎが少なく、同じ目標に向かって進めるこういったチームは、効率的に機能します

アプリケーションを展開・拡張できるようシステムエンジニアがコーディングをしたり、デベロッパーがインフラに関する深い知識を生かせるというように、運用チームに開発が完全に組み込まれたチームは、めったに実現できません。その代わり、開発チームとオペレーションチーム間の緊密な協力に基づくモデルを活用できるかもしれません。2つのチームは、生産環境の継続的モニタリングのため、計画立案の段階から協力し、責任を分担する必要があります。

あるいは、共有サービスを提供するDevOps専属チームを設けて、バージョン管理、継続的インテグレーションやデプロイの自動化といった課題に取り組ませるという選択もあります。ただし、専属チームは機能別組織の1つにすぎないため、そういった組織につきものの危険に配慮する必要があります。

一定の変更を行ったうえで、既存の組織構造(機能構造/部門構造/母体構造)を維持できる場合もあります。当社のDevOpsコンサルタントは、活用可能な人材、チーム間の協力や現在の組織構造の柔軟性を考慮しつつ、お客様が適切な選択を行えるようサポートします。

どのような組織モデルを実行する場合でも、チームの機能性を左右する、次の重要な特性を肝に銘じておく必要があります。

  • ビジョンと目標を共有するだけでなく、解決策の全体像も共有する
  • 着実に価値をもたらす能力
  • 質の高い仕事へのこだわりと仕事に対する誇り
  • 明確な説明責任とフラット構造
  • オープンなコミュニケーションと継続的改善

DevOps転換のための技術スタック

適切なチーム作りとオープンかつ誠実な協力関係の構築に加え、DevOps転換へのさらなる重要な一歩となるのが、ビルド、テスト、デプロイ、インフラの自動化です。必要に応じて、これ以外のプロセスが加わる場合もあります。

継続的インテグレーション(CI)

Continuous Integration

デベロッパーの仕事を早い段階から高頻度で共有リポジトリに統合することで、インテグレーションを早期に発見して、迅速な解決につなげることができます。日々の仕事の一環として小規模なマージを行えば、頻繁にソフトウェアをリリースできます。デベロッパーが活用できるバージョン管理ツールは多数あり、こういったものを使うことで、頻繁なコード変更をメインリポジトリにコミットできます。継続的インテグレーションサーバーは、コード変更のバージョン管理システムをポーリングし、最新のコードを読み出して、ビルドします。

自動化テスト

Automated Testing

継続的インテグレーション環境が整えば、自動化テストが可能です。コードコミットはすべてビルドスクリプトに統合され、自動化テストで検証されます。テストが自動化されなければ、開発速度は上がっても、リリースサイクルがそれに追いつかないということになります。

単体テスト、承認テスト、インテグレーションテスト、ひいては非機能テストまでもが自動化可能です。単体テストと承認テストは、セットアップによって並行実行が可能です。JMeter、NeoLoad、PenQやBrowseraといったツールを活用して、非機能テストを自動化することもできます。

デベロッパーのワークステーションで設定された自動化テストを活用することで、仕事の品質に関するより迅速なフィードバックが得られる場合もあります。たとえば、Foodcriticは、コード構造や構文に関するフィードバックをRubyデベロッパーに提供してくれ、Sonarlintは、テスト自動化エンジニアがSeleniumで作成したテストを分析してくれます。

誤判定は、自動化テストが問題を解決しようとする以上に問題を引き起こす可能性があるため、テストが信頼できるかどうかだけは確認しておく必要があります。当社では、小規模な一連の自動化テストで小規模なテストを実行し、時間をかけてその対象を広げていく方法をおすすめしています。

インフラのセットアップ

Infrastructure Setup

ソフトウェアビルドの自動化と全く同様に、プロビジョニングや環境(開発/テスト、ステージング、生産)の運用も自動化できるはずです。この自動化は、プログラムにる環境のセットアップとコード(コードによるインフラ設定)によるシステム設定管理が可能な、プロビジョニング管理ツールや設定管理ツールで行えます。

設定ドリフトを回避できる、一貫性のある信頼性の高いインフラを構築できるよう、デプロイ後はサーバーの変更ができない、不変のインフラモデルを選択することもできます。こういったモデルの下、変更が必要になった場合には、適切な更新が行われた新たなサーバーを割り当てて、既存のサーバーに置き換えます。

インフラがコードとしてセットアップされている場合は、バージョン管理システムで環境プロビジョニングを管理し、自動化テストを実行して、アプリケーションコードに使われるCI/CDパイプラインに環境プロビジョニングを統合できます。Chef用FoodcriticやPuppet用puppet-lintといったツールは、環境構築用に作成したコードの分析に用いることもできます。さらに、他のセキュリティ強化チェックも、自動化のテストスイートに加えることができます。

コンテナ化

Containerization

コードとして設定されているインフラをコンテナと組み合わせることもできます。これによって、アプリケーション環境からインフラ要件を切り離すことができるようになります。

コンテナは、オペレーティングシステムのエレメント(言語ランタイム、ライブラリ、システムファイル)をアプリケーションにバンドルします。これらのエレメントへの変更は、ホストシステムを何ら変更することなく行えるため、特定の開発環境では、毎回セットアップする必要がなくなります。また、コンテナによって環境のクローンも容易になるだけでなく、コンテナは、仮想マシンに比べて軽量です。

デプロイパイプライン

Deployment Pipeline

継続的インテグレーションとテスト自動化の環境が整ったら、次は、デプロイパイプラインの構築です。このパイプラインでは、あらゆる変更がリリース候補です。コードが変更される度に、即デプロイ可能なパッケージを作成するビルドが実行されます。自動化テスト(単体テスト、静的コード分析、承認テスト)が実行され、デベロッパーに迅速にフィードバックされます。これらのテスト(並行して行われる場合もあり)に合格したパッケージは、次の一連のテスト(探索的テスト)を受けられる状態となり、最終的には、製品にデプロイされます。デプロイパイプラインは、変更によって不合格となるビルドが出た場合に、アンドンを引いてすべてのユーザーに警告を発し、エラーが解決されるか、そのコミットがロールバックされて、パイプラインがグリーンビルド状態に復旧されるまで新たな変更を統合できないよう設定することもできます。

継続的デプロイ(CD)

ここまでくると、チームは変更を頻繁にプッシュでき、迅速なフィードバックも得られ、生産環境に信頼性をもって変更をデプロイできるよう、コードベースをいつでも使える状態に保てるようになります。成熟した、継続的デリバリーセットアップなら、必要があればいつでも、1日に複数回コードベースをデプロイできます(グリーン状態)。つまり、バグのないソフトウェアを頻繁にリリースできる状態にあるということです。

継続的デプロイによって、継続的デリバリーパイプラインのさらなる拡張がもたらされ、既存のデプロイが自動化されます。デプロイパイプラインの最終セグメントでは、コードベースは、人の手を借りることなく自動でデプロイできます。このようなシステムなら、新機能を迅速にリリースでき、ユーザーフィードバックも速やかに得られます。

モニタリング

Monitoring

継続的インテグレーション、自動化テストおよび継続的デプロイ環境が整い、DevOps手法によって頻繁なコード変更が可能になると、アプリケーションコード、環境およびオーケストレーション技術の包括的かつリアルタイムのモニタリングが必要となります。生産環境でのアプリケーションの継続的モニタリングには、New Relicといったアプリケーションモニタリングツールを活用できます。開発やテストに生産と同様の環境を用いるようになるにつれ、継続的モニタリングの範囲を、ステージング、テスト、さらには開発環境にまで広げられるようになります。

DevOpsパイプラインの初期段階から自動モニタリングを行うことで、パイプラインの流れを円滑に保つことができます。ビルド(開発状況の節目)、自動化テスト、デプロイ、サーバーの健全性、アプリケーションをモニタリングしながら、これらのデータを中心的な場所に集めて分析し、関連付けることが極めて重要です。得られた指標をグラフで示したり、統計的に分析したりすることで、動向確認、異常検出、機能を停止させるための警告発信などを行えます

DevOps実行のリリースパターン

必要に応じて柔軟にデプロイできるようになるにつれ、新機能を顧客に迅速にリリースする方法を選べるようになります。インフラレベルで実行される環境ベースのリリースパターンを用いることも、コードによって実行可能なアプリケーションベースのパターンを用いることも可能です。

環境ベースのリリースパターンの場合、アプリケーションコードの変更はほとんど必要ありません。複数の環境にデプロイできますが、ライブトラフィックを得られる環境は1つだけです。非ライブ環境にコードをデプロイすることで、リスクとデプロイのリードタイムのどちらも大幅に軽減できます。

ブルーグリーンデプロイ

カナリアデプロイ

クラスターイミューンシステム

同一の2つの環境(ブルーとグリーン)だが、ライブトラフィックを得るのは1つ(ここではブルー)のみ。 変更は、余剰環境(グリーン)でのテスト・検証を経て、ライブトラフィック処理に切り替えられる。 デプロイ後、ブルーは新たなステージングに移り、グリーンは、ライブトラフィックの役目を負う。 ダウンタイムのない、シンプルかつ容易なワンステップデプロイ。 ロールバックを素早く実行する方法。不具合があれば、トラフィックをブルーに切り替える。

ブルーグリーンシステムに比べ、新たな変更がもたらされるリスが大幅に軽減される 変更は、ユーザーの一部に対して有効となる(ランダムサンプルまたは地理/人口統計に基づいて選択)。 新バージョンをすべてのユーザーに段階的にリリースし、旧版を廃止する。 段階的なロールアウトによって、新バージョンの容量テストが可能。 問題が検出された場合、ユーザーは、旧バージョンに切り替えられる。

自動デプロイとロールバックプロセス。このシステムは、カナリアデプロイメントを拡張したもの。 変更を段階的にデプロイ。クラスターおよびビジネス指標はリアルタイムでモニタリングされる。 SLAが満たされない場合、そのプロセスは自動的に変更を取り消す。 性能低下の検出および応答にかかる時間が少ない。 問題が調査・解決されるまで、さらなるデプロイは停止される。

アプリケーションベースのリリースパターンの場合、わずかな設定変更でアプリケーション機能を選択的に公開できるため、非常に高い柔軟性が得られます。こういったリリースパターンはコード変更が必要となるため、導入には開発サポートが必要です。

フィーチャートグル

ダークローンチ

製品にコードをデプロイすることなく、機能の有効/無効が可能。 ユーザーのセグメントに対して有効な機能をコントロール。 トグル設定を変更して、問題を引き起こす機能を迅速にロールバック。 柔軟に性能をダウングレード。ユーザーに提供するリリース機能数を少なくし、サービスの不具合が全体に及ぶのを回避。

ダークローンチによって、フィーチャートグルを拡張。 ユーザーに対して機能を有効にすることなく、機能を製品にデプロイ。 生産と同様の負荷で、大幅な変更やリスクの高い変更を安全にテスト。 変更を取り消す場合には、影響を受ける数を最小にするため、ユーザーのごく一部に対して機能を段階的にロールアウト。

DevOpsモデルのソフトウェアアーキテクチャ

ソフトウェアアーキテクチャは、DevOps目標達成において重要な役割を果たします。小規模な独立採算チームを考慮したアーキテクチャは常に求められています。サービスとゆるい結びつきを持つサービス指向アーキテクチャなら、リスクの低い軽微な変更を行え、生産性、テスト容易性およびセキュリティを向上させることができます。

調整経費がかかるうえにビルトにも時間を取られ、規模の拡大にも対応できない場合が多い、純粋な単体構造に比べ、モジュール式のマイクロサービスアーキテクチャでは、独立したテスト、デプロイおよび規模拡大が考慮されています。ストラングラーアプリケーションなどを徐々に導入して実行し、必要に応じて、単体システムを、サービス指向のより高いアーキテクチャに徐々に置き換えていくことができます。

サービスとしてのDevOps - 移行を実現

サービスとしてのDevOpsは、新たなモデルを活用できるよう、チームをサポートします。当社のコンサルタントとDevOpsアーキテクトが、インフラとCI/CDパイプラインの評価、導入および維持によって、お客様の移行を終始サポートいたします。また、次のいずれかに対応するDevOpsコンサルティングサービスをご利用いただくことも可能です。

  • CI/CDパイプラインの導入
  • インフラの再設計/コードによるインフラのセットアップ
  • 設定管理
  • サーバーオーケストレーション
  • コンテナ化
  • リリース管理
  • クラウドマイグレーション(AWS、Azure、GCP)
  • マイクロサービスアーキテクチャ

DevOpsに至る道は、常に評価し、継続的改善を行いながら、理想的な状態への到達を目指して着実に成熟していくための道のりです。当社のDevOpsコンサルティングサービスおよび導入サービスは、組織の成熟度を問わず、お客様の発展をサポートいたします。今すぐ、DevOpsエンジニアにご相談ください。