このページの本文へ

ここから本文

2022年度 三菱電機ソフトウエア技術レポート

コンテナ技術を活用したID管理システムの開発手法

【執筆者】

FA・ファシリティ事業統括部 稲沢事業所 東京システム技術部 ビルファシリティ技術課
日野 慎一

【概要】

オフィス等の入退室管理を管理する為のID管理システムの開発では、コンテナ型仮想化技術を採用することにより、同一環境を開発環境や試験環境、クラウド上の運用環境やオンプレミス上の運用環境等、別環境に対して効率的に構築が可能である。また、プロジェクト管理やCI/CDツール、ソース管理をクラウド上で共有し、コンテナの特徴を生かすことで設計から成果物の確認までをスムーズに行うことができる。
本稿ではアプリケーションをコンテナとして配布することによるメリットと共に、コンテナ型仮想化技術を活用したID管理システムの開発手法について記載する。

1. まえがき

三菱電機(株)が開発した「カードマネジメントシステム」は、入退室に必要なICカードと利用者の管理を容易にするシステムであり、2016年の発表以来、オフィスビル等で利用する入退室管理システムである”MELSAFETY-G”の入退室管理機能を販売先の物件の様々な運用業務に対応できるよう拡張されてきた (1)
しかしながら、発表から時間も経ち見た目にも古くなってきたこと、クラウド環境上でのサービス提供の必要性等から「ID管理システム」として刷新することとなった。
クラウド環境上でのサービス提供は、物理サーバが必要ないことから初期導入コストが少なくすみ、また、メーカー側での管理も容易となる可能性がある。ただし、これまで通りオンプレミス ※1 での提供も望まれているため、ID管理システムではオンプレミスとクラウドの両方に対応する必要がある。
また、ID管理システムもカードマネジメントシステム同様に物件ごとの様々な運用業務に対応する必要があるため、効率的な開発が必要となる。
本稿ではこれらの問題を解決するため、コンテナ型仮想化技術を用いたID管理システムについてのシステム構成と開発手法について紹介する。

  • ※1 オンプレミス:システム開発やインフラの構築で必要となるサーバやネットワーク機器、あるいはソフトウェアなどを自社で保有し運用するシステムの利用形態

2. ID管理システム

2.1 基本機能

図 1. ID管理システムの構成(オンプレミス時)

ID管理システムはカードマネジメントシステムと同様に、ICカードといった物理的な認証媒体と利用者との関連付けを容易に行うことができる。
関連付けられた認証媒体及び利用者情報を三菱電機の入退室管理システムであるMELSAFETY-Gに配信することで、適切な入退館及び入退室を制御することが可能となる。また、MELSAFETY-Gから通行履歴や警報履歴を受信し一元的に管理することで、それらの履歴をクライアントPC上から参照できるようにしている。ID管理システムの全体構成を図 1に示す。

2.2 システム構成

図 2. サーバ構成(概略)

システム構成としてはWeb技術を用いた、サーバ/クライアント方式であり、クライアントPCから利用者情報や認証情報などを登録することができる。また、専用アプリケーションをインストール・設定することによりブラウザ上で認証媒体を読み取ることもできる。
ID管理システムについては、オンプレミスおよびクラウド環境上でのサービス提供の両方に対応することが前提とされ、同一のアプリケーションで実行できる必要があった。
クラウド環境での提供は、利用規模により、大規模なものに関してはオンプレミスやAmazonEC2 ※2 といった専用環境での提供、小規模なものに関してはAmazonECS ※3 のようなサーバレス構成でマルチテナントでの提供が考えられる。これら複数環境での実行を可能とするために、コンテナ型仮想化技術を用いたシステム構成となっている。
コンテナ型仮想化技術を用いているとは言え、システムのサーバ構成自体は一般的なWebシステムと同様で、フロントエンドのWebサーバ、バックエンド処理のAppサーバ及びバッチ処理とデータベースという構成である。(図 2)

図 3. 動作イメージ

MELSAFETY-Gへの接続について、AWS(Amazon Web Services) ※4 ではゲートウェイ機器やVPN回線を通じて接続する必要があるが、基本的な構成としてはほぼ同じとなる。
これまでのシステムと異なる点は、Webアプリケーションやバッチといったアプリケーションを直接OSにインストールし実行させるのではなく、それらのアプリケーションをインストールしたコンテナをOS上のコンテナサービスで実行することである。
通常、アプリケーションを実行させるにはランタイム環境やミドルウェアをあらかじめOSにインストールしておく必要があるが(図 3 (a))、コンテナ型仮想化技術を用いた場合にはコンテナ自体にアプリケーションに必要なライブラリ、ミドルウェアなどの環境設定がなされているため、コンテナを実行するだけでアプリケーションを動作させることができる。(図 3(b))

  • ※2 AmazonEC2:AWSサービスの1つでLinuxやWindowsといった仮想サーバをクラウド上に作成できるサービス
  • ※3 AmazonECS:AWSサービスの1つでDockerコンテナをクラウド上に展開、管理できるサービス
  • ※4 AmazonWebService(AWS):Amazonが提供しているクラウドコンピューティングサービスの総称

2.3 ねらい

  • オンプレミス・クラウドへの両対応の容易化
  • インストール・バージョンアップ作業の簡略化

先にも述べたようにコンテナにはアプリケーション実行に必要なライブラリ、ミドルウェアなどの環境設定がなされており、コンテナサービス上であれば問題なく実行される。
そのため、オンプレミスやクラウドのサーバ(AmazonEC2)やクラウド上のコンテナサービス(AmazonECS)に関係なく、コンテナサービス上であれば同じように実行できる。
また、コンテナをアップロードするだけでよく、インストール作業が非常に容易である。
バージョンアップ作業においても、新しいバージョンのコンテナをアップロード後、実行中(古いアプリケーション)のコンテナを停止し、新しいバージョンのコンテナを実行すればよい。
運用中のシステムのミドルウェアやライブラリのバージョンアップ作業は手間と時間がかかることが多い。停止時間が発生したり、動作しているアプリケーションの影響を考慮したりしなければいけない。2021年に発見されたApache Log4j2の脆弱性は、ミドルウェアを含む多くの製品に影響が及んだ。このようなセキュリティリスクは完全に避けることは難しく、アプリケーションだけでなく、利用しているミドルウェアやライブラリ群のセキュリティパッチの適用が今後ますます重要となる。コンテナでの提供はミドルウェアやライブラリを含んだ形で提供されるため、容易に対応できる。

3. 開発手法

図 4. 開発環境

今回、開発にあたり三菱電機グループで利用可能なパブリッククラウド基盤であるMEGCLOUD (2) のAWS内に開発用のサーバを構築した。(図 4)これらのサーバ群についても、すべてコンテナサービス上に構築した。

3.1 チケット駆動の導入

MEGCLOUDのAWS上のサーバを利用することもあり、開発の依頼元である三菱電機ビルソリューションズ(株)と同じサーバにアクセスが可能である。そのため、プロジェクト管理にはRedmine ※5 を用いて、チケット駆動 ※6 での開発を取り入れた。チケット駆動型開発は実施するタスクをチケットと呼ばれる単位に分割し、そのチケットをもとに開発を行うものである。チケット駆動を取りいれ、共有することで、透明性が高く、タスク処理中に発生した問題や課題などに対しも迅速な対応が可能であると考えた。
チケットは機能単位かつ成果物単位で作成することやチケットの遷移方法など、チケットのルールを明確にし、レビュー漏れをなくし、アジャイル ※7 的に開発を行えるようにした。
ただし、アジャイル的開発手法であっても請負での開発となる場合、1つのチケットを発注、請負のそれぞれのユーザで操作することは、偽装請負を指摘されるリスクがある。これらのリスクに関しては厚生労働省が公開している「労働者派遣事業と請負により行われる事業との区分に関する基準(37号告示)関係疑義応答集」 (3) を参考に、チケットから優先度指定の削除を行うなど、設定項目についてカスタマイズし、偽装請負を疑われないようにした。

  • ※5 Redmine:Webベースのプロジェクト管理ソフトウェア
  • ※6 チケット駆動開発:プロジェクト内のタスク(作業)を「一枚のカード」(チケット)とし、チケット単位で処理を行っていく開発手法
  • ※7 アジャイル開発:柔軟で効率的なシステム開発によって、迅速なシステム提供を目ざすというソフトウェア開発手法

3.2 CI/CDの導入

CI(継続的インテグレーション)/CD(継続的デリバリー)は、簡単に表現すると自動化の技術である。
CIはビルド済みのアプリケーションの作成までの工程、CDは試験環境含む実行環境へのリリースまでの工程を自動で処理してくれる。
CIの導入は比較的容易なため、採用されているシステムは多いが、CDについては問題点もある。
CDが問題になる理由の1つは、必要なライブラリやミドルウェアといったインストールやアップデートである。単純にアプリケーションのみを配置すれば問題ないというアプリケーションでない限り、ライブラリやミドルウェアについてあらかじめ設定しておく必要があり、それらのインストールやアップデートが発生した場合、対応するのは非常に困難となる。
一方、コンテナは実行するためのライブラリやミドルウェアといった実行環境を含んだ状態で作成されるため、サービスの実行環境へはコンテナさえアップロードすればよいため、導入が容易となる。

3.3 プロトタイプ開発

図 5. クライアント/サーバ間の開発遷移

画面側の開発についてはプロトタイプを取り入れた開発を行った。プロトタイプ開発 ※8 には、仕様確認後に作成したプロトタイプを破棄する「使い捨て型プロトタイプ開発」と、作成したプロトタイプを改良しながら、仕上げていく「進化的プロトタイプ開発」の2種類の手法が存在する。本開発では「進化的プロトタイプ開発」で開発を行った。
プロトタイプ環境では、初回は画面の見た目のみを作成しレイアウト等の確認を実施後、画面からの入力を処理し、画面へその結果を返すバックエンドサーバとしてスタブサーバコンテナを配置し開発を行った。スタブサーバコンテナは、固定値を返却することで、サーバとの通信を考慮した処理の改良や動作確認を実施した。最終的にはスタブサーバコンテナを実際の処理を実施するアプリケーションサーバコンテナに変更することで、実行環境へのスムーズな移行を行った。
本手法については、スタブサーバコンテナを利用することにより、アプリケーションサーバコンテナの開発進捗によらず、画面側を作りこむことが可能となる。ここでのリスクは、実際のアプリケーションサーバとの結合時のインタフェースの不具合だが、これに関しては3.4で述べるOpenAPIを利用することで回避した。

  • ※8 プロトタイプ開発:開発初期に試作を作り、機能や操作性を確認し、ユーザの要求などを本番のシステムに反映して完成させる開発手法

3.4 OpenAPIを用いたAPI設計

図 6. OpenAPI形式ファイルを利用しての開発

ID管理システムではクライアント/サーバ間の通信についてOpenAPI(旧名Swagger)でのAPI設計を行った。OpenAPIはWEBサービスのREST API ※9 を定義するための形式で、以下を含むAPI全体を定義することができる。

  • 利用可能なエンドポイント(URI)及び各エンドポイントでのHTTPMethod
  • 操作毎のパラメータ
  • 認証方法
  • 連絡先情報、ライセンス、仕様条件およびそのほかの情報

またOpenAPI形式のファイルはSwaggerツールを利用することにより、進化型プロトタイプで利用したスタブサーバの実行やコード変換機能によりライブラリの生成を行うことが可能となる。(図 6)

  • ※9 REST API:RESTと呼ばれる設計原則に従って策定されたWeb API

3.5 コンテナ特性を生かした試験実施

図 7. データベースコンテナを利用した試験

データベースを利用したシステムで試験の際に問題となるのは、同じ画面、同じアクションを実行してもデータベース内の値により表示や処理内容が変化することである。当たり前のことだが、同一の結果を得るためには、試験時にデータベースの値を合わせる必要があり、その作業に多くの時間がとられる。毎回、人が確認するのであればデータが異なっていてもそれを理解していればよいが、回帰試験を自動で実施する場合、同じ画面、同じアクションを実行した際に同じ結果になる必要がある。
ID管理システムの開発においては、本番用と試験用のデータベースコンテナを用意し上記の問題を解決した。本番用コンテナについてはデータを永続化させるためデータベースのデータ領域をコンテナ外のストレージにマウントしているが、テーブル構成などは同一のものとし、データの内容のみテスト用データとしている。逆に、試験用のデータベースはデータ領域をコンテナ内に持つことで、コンテナが破棄され、再作成された場合、それまでの操作で変更されたデータは破棄され、初期状態となる。
ID管理システムはコンテナ作成時に本番用と試験用に複数のデータベースコンテナを作成し、それぞれの用途や試験内容に合わせたデータベースコンテナを配置し、試験を実施した(図 7)。試験用データベースに登録されているデータは固定化されているため、誰が実施しても同じアクションなら、同じ結果となる。再度試験を実施する際も、試験用のデータベースコンテナを再配置することで、データベースは前回と同じ状態になるため、試験結果は同じになるべきである。

4. むすび

今回、ID管理システムについてはオンプレミス及びクラウドへの対応と開発の効率化を目的とし、コンテナ型仮想化技術を用いたシステム構成とした。
コンテナを利用することにより、オンプレミス・クラウド環境のどちらであっても動作が保証でき、2重開発の必要がなくなった。これは、コンテナがアプリケーションのみでなく、ライブラリやミドルウェアといった実行環境をすべて持っている為であり、それによりインストールやバージョンアップについても容易となった。また、これらの特性を開発や評価に生かすことにより、プロトタイプ開発やCI/CD、試験の自動化を開発、評価に取り入れることができた。
コンテナは、その特性を利用した開発を行うことにより、効率化、自動化を容易にする可能性を持っている。
今回の開発では初めてコンテナ型仮想化技術を用いるということもあり、最適化されていない部分もまだまだ存在すると思う。アプリケーションをコンテナ型仮想化技術に最適化していくことで、より堅牢に、保守性の良いものとなっていくと思うので、コンテナ仮想化技術を生かせるよう今後も開発を行っていきたいと思う。

【商標】

Javaは、オラクル アメリカ、インコーポレーテッドの登録商標である。
MELSAFETY及びMEGCLOUDは、三菱電機株式会社の登録商標である。
Amazon Web Services、AmanzonEC2及びAmazonECSはアマゾン テクノロジーズ インコーポレイテッドの登録商標である。
GitLabはギットラブ ビー. ブイ.の登録商標である。
OpenAPI™は、The Linux Foundationの登録商標である。
Dockerは、 ドッカー、インコーポレーテッドの登録商標である。

【参考文献】
  • (1) 西田武司、中林 智:カードマネジメントシステムの機能拡張とソリューション、三菱電機 技報、91、No.03、192~195(2017)
  • (2) 板倉建太郎、久保田雄大、木村チエ:三菱電機グループでのパブリック クラウド活用を支援するグループクラウド、三菱電機 技報、92、No.12、694~697 (2018)
  • (3) 厚生労働省:労働者派遣事業と請負により行われる事業との区分に関する基準(37号告示)関係疑義応答集
    https://www.mhlw.go.jp/bunya/koyou/gigi_outou01.html

筆者紹介

■ 日野 慎一

2014年入社 情報システム開発等に従事。
現在、東京システム技術部ビルファシリティ技術課 グループリーダー