PR

アプリケーションを頻繁に安定してリリースするには、開発と運用の密連携が欠かせない。DevOpsチームを組織し、運用の自動化やルール策定などに取り組もう。自動化では継続的なインテグレーションやデプロイなど適切な手法を選ぶ。

 今回は、マイクロサービスを導入する際のアプリケーション開発手法を解説します。従来のアプリケーションと同様に、マイクロサービスでもサービスの安定稼働は重要な指標です。ただし、従来型とマイクロサービスではそれを実現するアプローチが異なります。

マイクロサービスを支えるDevOps

 従来型のシステム開発では、開発部門がアプリケーションを開発し、これを運用部門に引き渡して運用するというプロセスが一般的です。開発部門は運用に直接関わらず、障害発生時には運用部門が1次対応を行い、開発部門には2次対応が求められます。

 運用部門ではサービスの安定稼働を実現するため、アプリケーションの品質には業務要件に対する機能面の品質だけではなく、性能、可用性、セキュリティーといった非機能面での品質も重視します。そのため運用部門あるいは品質部門が、リリース前に開発部門に対し品質確保について根拠となる資料の提出を求め、これを承認することでリリースが許可されるというプロセスが取られています。

 こうしたプロセスはウォーターフォール型の長期間で大規模な開発が前提となる場合に有効です。初期リリースをはじめ、大きな機能追加を行う場合、対象機能の確認には十分なテスト期間と移行期間を取り、計画に従って作業を進める必要があります。

 一方、マイクロサービス化の目的は頻繁で継続的なリリースの実現です。そのために、サービスが機能単位に分割されています。改善リリースの開発期間は極端に短くなり、毎週あるいは毎日、場合によっては1日に複数回といった頻繁なリリースが予定されます。こうした場合でも、サービスの安定稼働は変わらずに重要です。ECサイトのようなサービスであれば24時間365日の運用が求められます。こうした状況なのに従来のような「開発部門がアプリケーションを運用部門に引き渡す」というプロセスでは対応しきれません。従来通りの品質レベルを維持するためには時間がかかりすぎ、逆に時間を短縮しようとすれば品質チェックが甘くなります。

 そこで注目されるのがDevOpsです(図1)。DevOpsは、その名の通り開発部門と運用部門、そして品質部門にまたがる活動です。様々な運用作業を自動化することで、サービスの安定稼働を実現したまま、システム開発プロセスの最適化を進めます。運用作業は多岐にわたりますが、今回はリリース作業の自動化を中心に、運用フェーズにおけるログ監視や障害通知について紹介します。

図1●従来型開発とDevOpsのプロセスの違い
図1●従来型開発とDevOpsのプロセスの違い
[画像のクリックで拡大表示]