クラウドの先輩企業から学ぶ教訓 (その魅力と現実)ジョルダン (株) 東寺様、松本様、佐藤様
インタビュアー 小髙 太郎 / 松崎 剛
1 | 2
「乗換案内」で著名なジョルダン株式会社では、XML が産声をあげて間もなくから乗換案内の Web サービス (乗換案内 .NET XML Edition) に着手し、特にここ数年では劇的に利用数を増やしています。
「クラウド」や「REST」を主張するのは、Web 上でサービスを展開する欧米企業ばかりではありません。日本企業であるジョルダン株式会社では、こうした言葉が現在のようにメジャーになるずっと以前から、REST と同等の考えに基づくサービスを実装し、OS は Windows Server、Web サーバーとして Internet Information Services (IIS)、アプリケーション実行環境に .NET Framework 2.0 を採用し、構築 / 運用をおこなってきました。
今回は、ジョルダン株式会社の東寺 浩様、松本 佳子様、そして実際の開発をご担当されている佐藤 真一様に、同方式を採用した経緯 (なぜプレーンな XML であったのか ?)、こうしたサービス運用の苦労やポイント、さらにはジョルダン株式会社から見て「クラウド」とは何かといった点について、現実の視点 (ビジネスの視点) などを踏まえ、お話を伺いました。
質問) なぜ、リソース指向のXML を採用しているのでしょうか ?
(左から) 東寺様、佐藤様、松本様
このサービスをはじめたのは、約 10 年ほど前 (= XML が出て間もなく) でした。続けたのは開発側の意向です。
1 つの理由はデータの持ち方です。乗換案内では時間軸も含む多次元な情報構成が必要ですが、XML ではフレックスな状態も含むさまざまな定義の形を表現することができるという点が、この形式を採用した大きな理由でした。
また、「SOAP のアクセス手順でお願いします」と依頼すると疑問/質問が返ってくることがしばしばありました。PHP や JAVA など、より幅広い環境からの接続を考えた場合、従来の SOAP 形式だけではなく、HTTP のメソッド (GET, POST など) をそのまま使用したリソース情報の交換方式を採用すべきであると考えました。
もともと SOAP 形式のサービスは、ActiveX によるクライアント-サーバー間での通信を目的に開発されたサービスを原点として開発されていましたが、ビジネスの観点でも、こうした開発は非常に足が長い (= すべての完成までに長い期間が必要な) ビジネスになっており、こうした理由でも非同期な形でのサービスが必要とされました。最終的には検討を重ねて、この XML の形式になりました。
さらに、これは .NET 固有の理由ですが、当時、SOAP を使用した場合にはパフォーマンスが遅く、特に .NET Framework 1.0 の頃には非常に苦労しました。SOAP プロトコルによる Web サービスは、.NET Framework のバージョン1.1 ではじめて使い物になったと記憶しています。
こうしたデータの相互環境どうしでの可搬性、現実のパフォーマンス面といったいくつかの観点から、当初は研究所や公共機関系を中心に REST 方式のサービスが採用されていました。
質問) 現実の運用では何が問題になるのでしょうか ?
サービスを経由した API の問い合わせは、サラリーマンの帰宅時、週末など、曜日や時間帯によってピークがありますが、概ね 1 秒間に 400 - 1000 件の処理をおこなっています。このため、現実のインフラ/システムの面の運用においては、一般的な手法では解決できないようなトラブルに遭遇します。例えば、Windows OS のプリミティブなレベルのプロセスに障害が発生すると、そのプロセスを終了して回避することは不可能になります。障害監視においても、生存確認やインジケーターの上では問題がなくても、実際には内部で障害が発生しているケースがあります。物理マシンの性能をあげると不安定になり、性能を下げると安定するケースなどもありました。さらに .NET については、ガベージコレクションに関する特徴や、スレッドの親子関係の影響などで停止できないケースなどセキュリティ/権限上の制約などを理解して対処しなければならないケースもありました。
現在では、こうしたさまざまな経験を考慮した自動制御 (= 回避策の自動実行/事前実行、など) のための仕組みや、一般のツールでは検知できない監視の仕組みなど、ノウハウを満載に組み込んだサーバー環境に成長しました。
また実装面 (= 設計/プログラミングの側面) でのノウハウ/アイデアも数多くありました。例えば、乗換案内では渡したデータを 2 次利用する必要がありますが、データを再度渡す方式ではなく、独自な仕組みを使って実装をおこなっています。また処理は非同期に実行をおこなっているため、機能間の継承 (例 : ある処理の結果を受けて次の処理を実行する、など) ができません。こうした点についても、処理の依存関係を維持する独自のノウハウを採用しています。
また、フレックスな情報で処理するためのデータの格納方法や、乗換案内ではワークフローも扱うため、こうしたデータの扱い方も独自の方法で実装されています . . . (実装方法についての詳細は省略します . . .)
現在の完成に近い形になったのは、約 7 年前になります。
ここに掲載されている記事は、マイクロソフト認定パートナープログラムやトレーナー向け認定制度をはじめとするプログラムや資格とは関係がありません。