開発者と運用者の役割
ここでは、Java によるエンタープライズ Web アプリケーションを例に DevOps を導入した場合の開発者と運用者の役割について考えてみました。
初期の頃のオンプレミスで実行される Web アプリケーションを概略図で示すと下図のようになっていました。
一般的に、開発者の職務と運用者の職務は分離され、開発者は最終成果物のアプリケーションの設計、開発、テストと ear や war などにパッケージングするところまでを担当し、運用者は、ファイアウォール、ロードバランサなどのネットワークインフラストラクチャーの構築、アプリケーションサーバなどの実行環境の構築、データベースインフラストラクチャーの構築や、さらには監視や開発者から受け取ったパッケージをアプリケーションサーバにインストールすることなど、さまざまな事を担当してきました。
サービス指向アーキテクチャ (SOA) の時代を経て、さらにクラウドネイティブな時代となった今では、これまでのように、必要な非機能要件 (認証、認可、ログ、トレーシング等) やデータベースへのリソースアクセスのコードを含むパッケージングされたアプリケーション (fat-jar やもう見かけることも少なくなった ear や war) とするアーキテクチャ以外に、これまでインフラストラクチャーとみなされていた、ファイアウォールやロードバランサ、アプリケーションサーバ (下の図の proxy) で機能するものを採用できるようになり、またデータベースもこれまでのようなリレーショナルデータベースだけでなく、さまざまなデータストレージも登場しています。
さらには、仮想コンピューティング (VM やコンテナ、クラウドサービスなど) の進化により、インフラストラクチャーと考えられてきたネットワークやサーバでさえ、IaC のようにコードにより調達、変更、廃棄が可能となりました。
インフラストラクチャーがこのように変化したとき、開発者の役割は、アーキテクチャ設計においてインフラストラクチャーを無視できず、この領域にまたがるとともに、運用者の役割もまたアプリケーションの実行のために必要な情報がより増えることを意味します。
DevOps ムーブメントにより、初期の頃に比べればはるかに複雑な構成になったとはいえ、IaC も含む継続的インテグレーションや継続的デリバリーにより、インフラストラクチャーの構築を開発者で行うことも可能となっています。
このような状況下で、開発者はアプリケーションにフォーカスし、運用者はインフラストラクチャーにフォーカスするという役割のままでよいのか、またアプリケーションとインフラストラクチャーの境界線がどこにあり、役割をそのままとするのであれば、相互にまたがった場合の調整コストをどうするのかという課題があると考えています。
コンプライアンスの観点からは、参考資料「トラストをともに駆ける―― DevOpsにおけるコンプライアンス対応の要所」がとても優れたドキュメントでぜひ読んでいただきたいと思います。
