ビジネスアプリケーションを素早く柔軟に投入する為の IT 基盤
【Web アプリケーション自動生成ツール Web Performer とクラウド Google Kubernetes Engine を使用した、システム開発・運用・保守の徹底効率化】
前編

2020-09-09

はじめに

みなさんは Web Performer というツールをご存じでしょうか。Web Performer はキヤノンITソリューションズ株式会社が提供するピュア Java 100% の Web アプリケーションを自動生成するツールです。簡単なマスター管理画面等は一瞬で作成が可能ですし、よほど複雑な仕様でなければ大概の業務アプリケーションの作成が可能です。昨今はこういったツールを活用したアプリケーション開発が主流となりつつあり、その効率化が進んでいます。

またアプリケーション開発だけでは無くアプリケーションを運用、保守する為の技術も進化しています。当社は Google が自社のほぼ全てのサービスのインフラストラクチャに採用しているコンテナ技術に注目しています。Google は 10 年以上も前からコンテナを利用しており、コンテナ技術をベースに Google 検索や Gmail、YouTube 等のサービスを提供しています。そしてそのコンテナによるアプリケーション管理のノウハウを、私達が利用できるように汎用的にして提供されているサービスが Google Cloud Platform(GCP)の Google Kubernetes Engine(GKE) です。

当コラムでは、Web Performer で自動生成したアプリケーションを GKE で稼働させるメリットとその構成例を紹介します。

ゴール

当コラムの前編・後編を通じて、みなさまに到達して頂きたいゴールは以下となります。

  • Web アプリケーション自動生成ツール Web Performer の有用性を知る
  • Google Kubernetes Engine(GKE)の有用性を知る
  • Web Performer と GKE を組み合わせるとビジネスに素早くシステムを導入できる事を知る
  • Web Performer と GKE を組み合わせると開発から運用、保守が飛躍的に効率化される事を知る

Web Performer の有用性

Web Performer

昨今、アプリケーションを自動生成するツールを見聞きする機会が増えました。業務アプリケーションとまではいかない簡易的な自動生成ツールも数えると相当な数に上ると思います。その中でも Web Performer は業務アプリケーションをターゲットにした自動生成ツールです。これまでスクラッチ開発(プログラミング言語を使ってゼロから新たに作る開発)で作成してきたアプリケーションを、ノンプログラミングで開発する事が出来ます。 また、Web Performer は国内メーカーによる国産アプリケーションでサポートもしっかりしており、下位互換を保ちながら進化し続けているツールで安心して使用する事ができます。

自動生成ツールにありがちな融通の利かなさも、Web Performerであれば、Java や JSP 等で処理を書くことによって、比較的柔軟に機能拡張を行う事ができます。これにより、カスタマイズ不要の社内で使う簡単なアプリケーションから、特徴的な UI や特殊なビジネスロジックを必要とする BtoB のアプリケーションも作成できます。

自動生成ツールの利用を検討する際は、この融通が利かない部分、いわゆる制約の多さは一つの指標になります。一般的に、制約の多いツールはより簡単にアプリケーションを生成できる一方で、いざ業務に必要な機能を実装しようとしたときに機能拡張が出来ずにツールの選定から見直す必要が出てきます。逆に制約が少ないとアプリケーションの生成の為に多くの手順を必要としますが、様々な機能を自前で実現できる可能性が広がります。

Web Performer はスクラッチ開発並みに拡張が可能な為、様々な業務を実現する事が出来ますが、拡張開発をやりすぎるとその生産性や保守性等の自動生成のメリットが薄れてしまいます。従って如何に Web Performer の標準機能で業務を実現するかという観点が重要になります。その上で、生産性や保守性を犠牲にしても業務効率が上がるメリットが大きいといった場合に拡張開発を考えます。当社が導入コンサルティングに入る場合や、システム開発を受注した際はこの考え方をお客様に説明しながら設計を行います。

標準機能で生成したアプリケーションは ノンプログラミングですのでミスタイプ等の単体試験レベルのバグはほぼ無く、開発者はビジネスロジックの構築に集中することが出来ます。また、開発時の工数の削減もさることながら、保守フェーズに入っても単体試験レベルのバグが無い事から障害対応の頻度が減りますし、 ノンプログラミングである事から障害の修正や仕様の変更等が素早く行えます。属人的な作りになっていない為、開発時とは別の技術者が対応にあたるのも比較的容易になる事もメリットの一つです。

こういった特性を良く理解されているお客様は大変有効に Web Performer を活用されています。ほぼ標準機能だけでアプリケーションを開発し、業務に必要なシステムを従来よりも頻繁に、そして素早くビジネスに投入しています。

当社も「こんなシステムを1週間後に稼働させたいから直ぐに作って。」といったご依頼を何度か頂いたことがあり、対応させて頂きました。このスピード感で当社が対応できたのは、そのお客様とはそれまでの継続的なお取引の中で、お客様のシステム環境を把握している事や、どの様な成果物が求められているのか分かっている事が前提ではありますが、Web Performer を活用することで開発の生産性や運用後の保守性を飛躍的に向上することが出来ます。

Web Performer に関する詳細は こちら

メーカーのキヤノン IT ソリューションズさんも Web Performer を活用する為のコラムを掲載されています。ご興味がある方は是非こちらもご覧ください。

コラム・超高速開発とWeb Performer 第1回~第5回

クラウド利用の有用性

Web Performer を活用するだけでもシステム開発は飛躍的に効率化されるのですが、アプリケーションはプログラムだけでは動かすことが出来ません。アプリケーションを動かすためのインフラストラクチャが必要となります。しかし、サーバ類の調達やネットワークの設定等はアプリケーションの開発に比べてハードルが高いのが一般的です。

例えば、お試しでちょっとしたアプリケーションを作成することは案外ハードルが低いです。外部の業者へ発注する場合はまた別ですが、社内で内製する場合は人的リソースの投資という事になります。これは担当者が時間のやり繰りをしながら、できる範囲で開発を進めていくことが出来ます。投資の余裕がなくなればいつでも作業をストップできます。

対して、サーバ等のハードウェアの調達は数十万から場合によってはそれ以上の出費が事前に発生します。お試しでやってみて、やっぱり止めたとなる可能性を考えると安易には踏み切れません。また、アプリケーションの公開にはネットワークの設定等が伴います。インターネットを経由して使用するようなアプリケーションの場合は DMZ(非武装地帯)の設計やファイアウォールの設定等、大掛かりな対応が必要になります。

アプリケーションの開発自体は人的リソースの投資さえ許されれば(場合によっては勝手に)行うことが出来ますが、ハードウェアの調達やネットワーク設定の変更等は、より上位の承認や申請が伴います。アプリケーションの開発がユーザ部門で行われ、ネットワーク設定が情報システム部門であった場合はより面倒です。作るアプリケーションがちょっとしたものであればある程、お試しでやってみようという試みは実行段階に移る前にとん挫する事になるでしょう。

そんな中、アプリケーションを稼働させるためのインフラストラクチャをクラウドに任せてしまうのは得策です。

先ずハードウェアの調達ですが、クラウドサービスの料金体系は基本的に従量課金ですので、利用した分だけ費用が発生するだけです。お試しであれば利用ユーザも少ないことが考えられますし、最小スペックのサーバで費用を抑えられます。また、使用していないときはシステムを停止しておけば料金は発生しません。いきなり数十万のコストは発生しませんので、月額数千円~数万円のランニングコストでそのアプリケーションの費用対効果を確認することが出来ると思います。

次にネットワーク設定ですが、社内の既存の設定に手を入れる場合は主管部署や情報システム部門等への申請や作業依頼が発生し時間と労力を要すると思います。しかし既存の仕組みと切り離したクラウドで運用するのであれば既存のネットワーク設定を変更する必要もなく、又、 社内の機微な情報資産から切り離されている為、比較的容易にシステム公開が出来ると思います。こういった社内のその他の実運用環境と切り離した環境を持てるのはクラウドの一つのメリットです。若しくは、社内のネットワークと同等に扱える仮想のネットワーク(VPC: Virtual Private Cloud )をクラウドに持つことも出来ます。この場合には従来と同等の申請や作業依頼が必要になるかと思いますが、管理されたネットワークポリシーの下セキュリティが守られることになります。

そしてこれらのインフラストラクチャは今すぐに利用できます。例えばオンプレミスで数百万円から数千万円掛かってしまうようなものも、月額数千円程度から利用することが可能です。この様にクラウドを利用することによって、かつては大規模なデータセンタやスーパーコンピュータが無ければ実現できなかったビジネスも、今は事前の大きな投資は必要なく、先ずは少ない利用から始めて、ビジネスの拡大に応じてクラウドの利用量を増やしたり改めてデータセンタを設けたりしながら誰でもビジネスを展開できるようになりました。

この様にクラウドは、お試し利用のようなシステムのスモールスタートやスピード感があるシステム公開を行う上で最適なプラットフォームです。

コンテナの有用性

以上の様な Web Performer とクラウドの特性を考えると、Web Performer を使ってビジネスに必要となりそうなアプリケーションを先ずは作ってみて、クラウドを利用してビジネスに素早く投入してみたくなるのではないでしょうか。 その際には一般的にはクラウドの仮想マシンを立ち上げ、アプリケーションを配置することになると思います。従来がそうであった様に、これでも十分に目的は果たせますが、仮にアプリケーションの数が増えてきた場合はどうなるでしょうか。

アプリケーション毎にサーバを立ち上げてしまうとそれだけ料金も発生するので、もしお試しで使ってみようという状況であれば、恐らく一つのサーバに相乗りする形でアプリケーションを配置しコストを抑制するのではないでしょうか。その際に、一つのサーバ上に各アプリケーションの為のプログラミング言語ランタイムやライブラリ、設定ファイル等が混在することになります。

この様な状態で、あるアプリケーションに障害が発生した場合、障害の原因はそのアプリケーション自体にあるのか、若しくは、その他のアプリケーションの影響によるものなのか判別が難しくなります。これは複数のアプリケーションを一つのサーバ上に相乗りさせた事による問題で、アプリケーション毎にサーバを立ち上げておけば発生しませんでした。

これを解決するのがコンテナになります。アプリケーション本体と共に、必要となるプログラミング言語ランタイムやライブラリ、設定ファイル等をひとまとめにしたものがコンテナです。このコンテナはコンテナエンジン上でそれ単独で、外部からの影響を受けることなく動作します。仮想マシンとの違いは、コンテナには OS が含まれていないところにあります。一つの OS の上で複数のコンテナが稼働する仕組みでコンテナ自体はコンパクトなものになります。もしアプリケーション毎に仮想マシンを立てた場合、その分 OS が重複するわけですから、一つの OS 上で複数のコンテナを稼働させる方が使用するコンピュータリソースはリーズナブルになるのが分かると思います。

この様に、アプリケーションをコンテナ化しておくことで、一つのサーバ上に複数のアプリケーションを稼働させる事による問題が解決しました。コンテナ化する事のメリットは他にもあります。それらを次にまとめます。

コンテナ化のメリット

冒頭でも述べた通り Google は約20年の歴史の中、10年以上も前からコンテナを活用し、今ではほぼ全てのサービスがコンテナによって動いているそうです。世界規模の大容量のデータやトランザクション処理を扱いながら高速で、且つ、安定的にサービスを提供できているのはこのコンテナ技術の賜物です。

まだ一般企業のエンタープライズアプリケーションの世界ではあまり浸透していないコンテナ技術ですが、ここ数年で利用が広まってきており近い将来は確実に浸透していくものと思われます。当社でもお客様に紹介し、採用してくださったお客様からはご好評を頂いています。

そのコンテナ化の、エンタープライズアプリケーションにおける主なメリットは次の通りです。

コンピュータリソースを有効活用できる

コンテナはそれぞれのアプリケーションを局所化するので、他のアプリケーションに与える影響を考慮する必要が無くなります。大してリソースを消費しないアプリケーションや、一時的にしか使われないアプリケーション等、一つのサーバ上に複数のアプリケーションを配置することが出来る様になる為、コンピュータリソースを有効活用できます。

また、そのサーバ上の OS は一つですからライセンスも一つですし、その他ウィルスソフト等のライセンスも一つで済みコスト削減に繋がります。同じく、OS のパッチ作業等も一回で済みますし人的コストも抑制できます。

新技術の採用が容易

これまでのシステムは全体で一つの塊として構築されていました。いわゆるモノリシックサービス、モノリシックなアプリケーションと言われるものです。この場合、もし一部の機能に最新のライブラリを使いたい為プログラミング言語ランタイムから最新化する必要がある場合、システム全体のマイグレーションが必要となってしまいます。

対してコンテナ化されている場合は、それぞれのコンテナの中にプログラミング言語ランタイムも含むので、その対象となるコンテナだけマイグレーションするだけで済みます。これにより世の中の革新的な技術を素早くビジネスに取り込むことが出来るようになります。 ただ、一つのコンテナの中にシステム全体を一つの塊として入れてしまっていた場合は部分的な変更が出来ない為、予め機能毎にコンテナ化しておくといった設計が必要になります。

ソフトウェア開発の生産性が向上

アプリケーションがどこに配置されても環境に左右されず一貫性をもって動作することはソフトウェア開発技術者にとってもメリットがあります。開発環境と本番環境の環境差異に悩むこともなく、またそれら影響による障害の調査に時間をとられる事もありません。

アプリケーションの配置場所の変更が容易

ベースとなる OS が同じ必要があるという前提はありますが、コンテナの移動は非常に簡単です。プログラミング言語ランタイムからひとまとめに格納されているので基本的にそのコンテナを移動先に持っていけばアプリケーションは動作します。

これは開発環境から本番環境へのコンテナの移動もそうですが、クラウド環境からオンプレミス環境へ移動させる場合も同様です。例えば、お試しアプリケーションをクラウド上で検証し、実運用すると決めた時に、実運用ではランニングコストが嫌なのでオンプレミス環境にそのアプリケーションを持ってくるといったことが容易に行えます。またクラウド間で、別クラウドベンダーへコンテナを移動することも容易です。

コンテナ化のデメリット

併せてコンテナ化のデメリットを挙げようと思ったのですが、正直思い浮かびません。強いて言えば、コンテナ化のメリットがユーザ部門に理解され難いというところかと思います。

コンテナ化のメリットの直接的な恩恵を受けるその殆どは情報システム部門やシステム開発部門です。勿論ユーザ部門としても、コストが安くなった、障害復旧が早くなった、AI 等の最新技術がビジネスアプリケーションに取り入れられた等といった恩恵を受けるわけですが、その背景にコンテナ化があるのだとは中々理解してもらえません。

ですので、既存システムを他の理由も無くただ単にコンテナ化するというのは難しいと思います。しかしこれから新たに作られるシステムにおいてはコンテナ化しない理由が見つかりません。

後編へ続く

Google Kubernetes Engine(GKE)

後編ではこのコンテナをより効率的に活用するための Google Kubernetes Engine(GKE)の説明と、その GKE と Web Performer を組み合わせた具体的な構成について紹介します。

後編は こちら

Web Performerは、キヤノンITソリューションズ株式会社の登録商標です。
Google、Google Cloud、Google Cloud Platform、および、GCP は Google LLC の商標です。