ORCA次期フレームワーク開発の現状

株式会社ネットワーク応用通信研究所

2014年10月11日

自己紹介

前田 修吾

株式会社ネットワーク応用通信研究所取締役

一般財団法人Rubyアソシエーション事務局長

Rubyコミッタ

島根県松江市在住

1

現在のORCAの問題点

クラウドに適したアーキテクチャ・ライセンスになっていない

• Webに対応していない

• クライアントソフトウェアが必要

• 独自プロトコルによる通信のため、ネットワーク構成に制限

• マルチテナントに対応していない

• 診療所ごとに独立した環境を用意する必要がありコストが高い

• ライセンスがクラウドに対応していない

• 第三者が改変したものをクラウドで提供してもソースコードの提供義務がない

2

解決策（当初の案）

クラウド対応のためのアーキテクチャの刷新及びライセンス変更

• Web対応

• ブラウザがあれば専用のクライアントは不要

• 標準的なプロトコルの利用で様々なネットワークに対応

• マルチテナント対応

• 運用コストの低減

• ライセンスのクラウド対応

• 改変物をクラウドで提供した場合もソースコード提供義務を

3

Web対応

業務ロジックDB処理 画面定義

次世代フレームワーク

WebサーバDBサーバ

フレームワークで従来互換のインタフェースを提供しアプリケーションコードは従来のものを流用

サーバ

Webブラウザ

HTTPS通信

クライアント

クライアントライブラリ

サーバからJavaScript

クライアントライブラリを配布するため

専用クライアントは不要

4

マルチテナント対応

1台のサーバで複数のテナントに対応する

ことにより運用コストを低減

Webサーバ

DBサーバ

テナント毎に独立したDBを用意し

認証結果によって適切なDBに接続することでセキュリティを確保

DB

5

ライセンスのクラウド対応

従来のライセンスの問題点

• GPLの場合、第三者がソースコードを改変しても、クラウドサービスを提供するだけならソースコードの提供義務がない

クラウドに適したライセンスの採用

• AGPLを採用することで、第三者が改変したソフトウェアをクラウドサービスで提供した場合、ソースコードの提供を義務付けられる

6

ORCA次世代フレームワークの特徴

Rubyの採用

• Webアプリケーション開発に実績のあるRubyを採用

• サーバ増強によるスケールアウトが容易

• プログラム言語Rubyは国際規格（ISO/IEC 30170）

• （一財）Rubyアソシエーションによる保守体制

• 将来に渡って安心して利用できる環境

過去の資産の有効活用

• COBOLによる業務ロジック・SQL・画面定義データなどの過去の資産の有効活用で移行コストを低減

7

Ruby on Railsとの比較

Ruby on Rails ORCA次世代フレームワーク

汎用性高い

（Web全般に対応）低い

（業務システムに特化）

移行コスト高い

（全面的な作り直し）低い

（既存コードの流用）

性能要検討

（DB設計の方針から思想が異なるため）

高い（現在の性能特性＋Rubyのスケールアウト技術）

8

と考えていましたが…

9

Web（HTML）化の問題点

操作性の違い

• キーボード主体 → マウス主体

先行入力の対応が難しい

10

方針の変更

クライアントは現在と同等のものを提供

• Webアプリケーション化は将来検討

ただし、プロトコルはHTTPベースに（クラウドとの親和性）

マルチテナントにも対応

11

サーバ構成

アプリケーションサーバ

DBサーバ

アプリケーションサーバ

アプリケーションサーバ

DBサーバ

クライアント

セッション管理サーバ

12

サーバ構成

セッション管理サーバ

• クライアントからの認証要求を処理し、セッションの管理を行う。

• テナント情報・ユーザ情報などのマスタ情報とセッション情報を保持する。

アプリケーションサーバ

• クライアントからの画面要求・イベント処理要求を処理する。

• クライアントはセッション管理サーバから指定されたアプリケーションサーバに毎回接続する。

DBサーバ

• アプリケーションのデータをテナント毎に別々のDBに保持する。

13

コードネーム

ginbee

• montsuqi（紋付）→ginbee（甚平）

14

開発方針

一般的なRubyのWebシステムと同じミドルウェア構成

• Passenger、Unicorn、Rackなど

既存資産を活用する

• MONTSUQIのライブラリ

• アプリケーションコード

• 画面定義

• 帳票定義

15

開発状況

2013年度

• フレームワークの基本部分の開発を完了

2014年度

• 認証の強化

• 印刷機能

• 日レセAPI対応

• 管理機能

• プログラム更新・マスタ更新

• カスタマイズ対応

16

認証の強化

セキュリティデバイスの利用を検討中

• USBトークン・ICカードなど

懸念事項

• 接続不良

• USBトークンが奥まで差さっていない

• デバイスロックの多発

• PINの誤入力が連続するとロックされる

• 導入費用

• 運用コスト

17

印刷機能

従来の日レセではサーバ側での印刷が多い

サーバ側で出力された印刷データを自動的にクライアントにダウンロードして印刷

18

日レセAPI対応

従来の日レセAPIと互換性のあるAPIを提供

認証などは変更の可能性

他のアプリケーション（クラウドサービス含む）から連携可能

19

管理機能

ベンダ・テナントなどの情報の管理

ベンダ向けの管理機能も提供

20

プログラム更新・マスタ更新

クラウド上で一括してプログラム更新・マスタ更新を行う

ベンダの負担を軽減

21

カスタマイズ対応

マルチテナント対応を考えるとできれば避けたい

NaClがサポートしている医院のカスタマイズ状況

• ほとんどの医院で何らかのカスタマイズをしている

ベンダ毎にカスタマイズした環境を用意し、特定のテナントのアプリケーションはその環境で動作させる対応

22

デモ

23

まとめ

ORCA次期フレームワークginbeeは

• クラウドに適したプロトコル設計

• マルチテナントへの対応

• クラウドに適したライセンスの採用

によって、クラウド環境におけるORCAの利用を促進します

24