アーキテクチャ¶
本ページでは、Eponaによって構築される環境のアーキテクチャについて説明します。
Eponaを適用して構築されるアーキテクチャ概要図は以下の通りです。
なお、Eponaはコンテナの利用を前提としています。詳細はこちらを参照してください。
Delivery環境とRuntime環境¶
Eponaを用いて構築される環境には、Runtime環境とDelivery環境の2つがあります。
Runtime環境は、サービスが実際に稼働する環境です。例えば、本番環境、ステージング環境、開発環境が該当します。一般には、1サービスに対して複数環境が配置される構成になります。
Delivery環境は、Runtime環境にアプリケーションをデリバリするための環境です。例えばソースリポジトリやコンテナリポジトリ等、Runtime環境で共通的に利用されるpatternが配置されます。共通的なものを配置すると言う位置づけであるため、サービスに対してDelivery環境は1つのみとなります。
Runtime環境¶
Runtime環境に配置される機能は以下となります。
機能 | 概要 |
---|---|
CDパイプライン | Delivery環境でビルドされた成果物を、サービスが稼働する環境にデプロイします |
モニタリング | サービス、そしてサービスを構成するリソースの正しい状況を捉えます。それによりビジネスやシステムの問題の把握・改善を図ります |
ログ収集 | アプリケーションやリソースから出力されるログを一箇所に集約・集積します。ログの横断検索や解析、保管に利用します |
障害検知 | サービス、システム上も問題をサービスチームに伝え、それに対する対応を迅速に取ることができるようにします |
セキュリティ対策 | サービスを悪意のある第三者の攻撃、そして内部犯行からも守り、ユーザーが安心して使えるようにします。攻撃に対する防御策を実装します |
仮想セキュアルーム | 物理セキュアルームを構築することなく入退室管理等を実現し、本番環境を含むRuntime環境に対しリモートから作業ができるようにします |
Delivery環境¶
Delivery環境に配置される機能は以下となります。
機能 | 概要 |
---|---|
VCS | ソースコード、設定ファイル等の変更履歴を管理します。サービスチームの共同作業を助け、そのハブとなります |
ITS/BTS | 課題管理、バグ管理を行います。これらをワークフローで管理するとともに、履歴を蓄積し、振り返ることができるようにします |
コミュニケーション | サービスチーム内でのオープンで活発なコミュニケーションを促進します。また、サービスの開発・運用に必要な情報を集約するコミュニケーションハブとなります |
コンテナイメージリポジトリ | アプリケーションとその実行環境をパッケージ化したイメージを登録しておき、どの環境でも同じアプリケーションが利用できるようにします |
CIパイプライン | アプリケーションのテスト、ビルドを行い、デプロイ対象となる成果物を作成します |
コンテナの利用¶
Eponaでは、コンテナ化されたアプリケーションの利用を前提としています。
Docker等のコンテナを使うことで、それまではOSの上に実行構築を構築していたアプリケーションを実行環境を含めてパッケージングできます。実行環境が含まれるため、「どの環境でも動作する」という可搬性の実現が可能です。
この可搬性とクラウドサービスが提供するコンテナサービスを組み合わせることで、コンテナの実行をクラウドサービスに任せ、これまで実行環境を支えていたOS等のレイヤーを運用の関心事から切り離します。これは、Eponaが掲げるOperation-Lessという開発コンセプトに合致するものです。
また、コンテナを使用してアプリケーションを実行することで、テスト環境でテストされたアプリケーションと本番環境にデプロイするアプリケーションが完全に同一であることが保証されます。 デプロイ方法やスケーリングについても、個々のアプリケーションの詳細に煩わされることなく、コンテナというパッケージにのみ焦点を合わせて開発・運用できるでしょう。
高速なアプリケーションの開発と実環境への素早い展開と運用の両立が、コンテナおよびコンテナサービスの利用によって可能になります。
※ このドキュメントはクリエイティブコモンズ(Creative Commons) 4.0 の「表示—継承」に準拠しています。
※ このドキュメントに記載されている会社名、製品名は、各社の登録商標または商標です。
© 2021 TIS Inc.