「明日の認証会議 3」講演用スライド 20141002（配布用）

「明日の認証会議-3」
社会インフラ的大規模サービスを支える
今の認証技術/事例
かもめエンジニアリング株式会社
Copyright©2008-2014 KAMOME Engineering, Inc. All rights reserved.
代表取締役
16:00 〜16:40
潮村剛
2014/10/02

講演者紹介
潮村剛（しおむらたけし）
1990年代半ば、⾷品メーカーから
ソフトウェア業に転身。
以来、国内の主要通信キャリアを中心に、
ネットワーク認証システム案件を数十件
手がける。
オライリー・ジャパンより刊⾏の
『RADIUS – ユーザ認証セキュリティプロトコル』
をプロデュース。
2008年、かもめエンジニアリングを設⽴。
SEと思われることも多いが企画営業ひと筋23年。
Copyright©2008-2014 KAMOME Engineering, Inc. All rights reserved. 1

かもめエンジニアリングの紹介
2008年5月創業
本社… 東京都品川区
主要取引先（法⼈格・敬称略）
伊藤忠テクノソリューションズ
新日鉄住⾦ソリューションズ
富士通/ PFU
科学情報システムズ
ワイモバイル
ネットスター他

認証分野を中心とした自社製品
統合認証基盤サーバ「KFEP」
Diameterサーバ「KFEP-DS」
Daimeter/RADIUS変換サーバ「KFEP-TR」
L2アクセス制御GW 「KNAT」
M2Mモジュール「KAMOME IoT Module」

取扱い/採用実績

今日お話しすること
目次
自己紹介、かもめエンジニアリングの紹介
認証基盤について
安定した認証基盤のために必要な事柄
かもめの取り組み、事例紹介
まとめ

“認証基盤” について

「認証」とは︖
認証
認可
利⽤権限の確認
利⽤状況の確認
利⽤に必要な権限情報の付与
利⽤者から⇒「すべてのサービスの入口」
サービス提供者側から⇒「接点」

「認証」で気にされること
「性能はそこそこ」
「コストは最小」
そこに大きな
落とし⽳があります。

「認証」で⾒落とされがちなポイント
最小規模の最小コスト
近い将来の規模の最小コスト
スモールスタート時のコストの最小化「だけ」を
考えた構成は、
成⻑のボトルネックを「仕込んで」しまう。

「認証」で気を付けるべきポイント
最小規模の最小構成
最大規模でも最適構成
スモールスタート時のシステム構成のまま
拡張できるのが一番いい構成。

よくある構成
サービスA
サービスB
サービスC
サービスD
サービスE
サービスF

⾒落とした結果〜性能問題〜

⾒落とした結果〜拡張性問題〜

事故の例-1

事故の例-2

事故の例-3

事故の例-4

⾒落とした結果〜まとめ〜
「コストと信用」に跳ね返ります。
拡張or 拡張できずに別建て
ライセンス費⽤
再構築費⽤
移⾏費⽤
検討に要する⼈的・時間的コストetc.･･･

安定した認証基盤のために

必要なこと
RDBの役割を上手に限定することで、
大きな効果を手に入れられる。
性能︓並み程度以上
（でも必要な場合は対応したい）
拡張性︓スモールスタートできて、
必要な時に最小単位で素早く拡張したい
セキュリティ︓配慮していること
コスト︓できるだけ低く

考えるポイント
やりたいことの整理
なくてもよいことを捨てる
RDBに求めているものを⾒直す
連結させている機能は分離できないか
考える

分散KVS（Key-Value Store）を使う
「速さ」と「大量処理」を必要とする
最前線の現場で広く使われています。
RDBでは実現できなかった大規模・
高速システムを低コストで実現します。

分散KVSの特⻑
RDBと密連携するアーキテ
クチャなどとは異なり、単
一障害点が存在しない。
情報を一か所に集約するポイントが
存在しない
負荷が全体に均等に分散さ
れるため、負荷の偏りが極
めて発生しにくい。

分散KVSの特⻑
スケールアウト（ノードの
追加）によるシステム全体
を拡張が容易。
冗⻑レベルを保ったまま拡
張でき、システム全体のリ
ニアな性能向上が可能に。
ノードの追加

分散KVS
大規模Webサービスでの事例
分散KVS
Webサービス
Webサービス
Webサービス
Webサービス
１
統合ID基盤
Webサービス

分散KVS
大規模Webサービスでの事例２
Webサービス
Webサービス
Webサービス
認証⽤DB 統合ID基盤
認可コントロール
Proxy
分散KVS
分散KVSにより
認証⽤DBの負荷を大幅に軽減

まとめ
特に認証分野において、
どうしてもRDBが必要なことは、
実はあまり多くない。
ここが⾒切れれば、
性能、拡張性、コストの削減が手に入る。
疎結合、分散処理

かもめエンジニアリングの
取り組み

かもめの取り組み
サービスA
サービスB
サービスC
サービスD
サービスE
サービスF
KFEP
1
2 3
サービス
A
サービス
B
サービス
C
サービス
D
サービス
E
サービス
F

統合認証基盤サーバ「KFEP」国際
特許取得
分散KVSエンジンを活⽤し、
RDBと密連携しないアーキテクチャを実現
フロントエンドで高速に大量処理を⾏う必要がある
システムにおいて、RDBの性能や運⽤性に引きずら
れない高い耐運⽤性を実現
分散KVS＋コンシステント・ハッシュ方式を採⽤。
スケールアウト方式で拡張性を実現。
Hot Plug方式に対応、1台〜n台を一体として運⽤
可能。

お客さまの⽤途に合わせて
プロフェッショナルサービスを提供
KFEP独自のAPIを利⽤するか、あるいは必要と
なる業務ロジックを内部に組み込み、高性能か
つ拡張性に優れたアプリケーションシステムが
構築可能。
お客さまのご要望により、ノウハウを活かした
機能付加が柔軟に可能（別途有償でのご提供）。

「KFEP」の特⻑・事例など

「KFEP」の特⻑
RDBを削減し、導入・運用負荷を抑制
認証・認可⽤のDB不要サービスオーダやセッションデータを
内部に保持
サービスオーダ⽤の
DBを大幅削減
S/O投入
サービスAA
サービスBB
サービスCC
サービスDD
KFEP
1
2 3
連携
連携
連携
連携
Master
DB
RDB
for S/O
…KFEP導入により
不要となったDB

「KFEP」の特⻑
スケールアウトによる拡張と
サービスの段階的な統合を容易に
サービスA
② システム更改に
合わせ追加導入
サービスB
④ 導入提案中
サービスC
③ 新サービス向け
に追加導入予定
サービスD
KFEP
1
2 3
プロセス数追加
① 初期導入
5 6 4

「KFEP」の特⻑
スケールアウトしても低コスト
大手通信キャリア
基幹サービスシステムへの
導入実例
Bのコストは
システム移⾏分を含め
Aの5分の1以下に抑制された。
既存のレガシーな構成による
A ソリューションの場合
Aからのシステム移⾏に
＋伴うコスト
B KFEPを⽤いた構成による
ソリューションの場合
登録データ/要求処理数
総コスト

「KFEP」の特⻑
どれくらい︖
バックエンドのRDBシステムの
大幅な削減
大手通信キャリア
基幹サービスシステムへの
導入実例
サービス系含め、ラック8本⇒ 0.5本へ削減
新サービス導入のリードタイム短縮に貢献
運⽤トラブル件数の大幅な軽減により、運⽤負荷を軽減
大幅なコスト削減効果を発揮
導入コスト… 既存システム比10分の1以下
運⽤コスト… 既存システム比30分の1以下
拡張コスト… 既存システム拡張比100分の1以下

１
「KFEP」の導入事例
スマートフォン、フィーチャーフォンのサービス利用者認証
キャリアセンター
入替・改修範囲
認証⽤
データ配信⽤
DB
Internet
サービス
認証⽤DB
フィルタ
DB
Web
ゲートウェイ
メール
コンテンツ
ネットワーク
各サービスシステムがサイロ化。連携対応の改変も困難
RDBも乱⽴、運⽤コストは高留まり
処理性能に限界、新サービス導入の足かせに
Before
課題
MVNO
契約者
DB

１
スマートフォン、フィーチャーフォンのサービス利用者認証
A f t e r
MVNO
Internet
Web
ゲートウェイ
メール
コンテンツ
ネットワーク認証を吸収
全サービスシステムの認証機能を
まとめた認証プラットフォーム
S/O配信
プロセス
契約者
DB
KFEP
KFEPに
契約者情報を
ファイルで配信
20万ユーザ対応、秒間3,000処理を実現⇒ 1,000万ユーザへ拡張中
RDBの大幅な削減、導入コスト・運⽤コスト・拡張コストそれぞれ90%〜99%を削減
新サービスの導入対応がシンプル、細かい機能改善も容易に● より精密な認証・接続コントロールを可能に
解決

2
複数サービスの認証を統合、サービス間連携も
Before センター
サービスA
サービスB
サービスC
Master
DB
サービスD
他社サービス
認認証証ササーーババ
（約80台）
・・・・・
・・・・・
（数十種）
更新⽤
DB
SQLサーバがすべてのデータを保持し、
アクセスのつど
問い合わせ・書き込みが発生
収容ユーザ数の限界を超えて運⽤● サービスメニューの増加に対応できない
認証システムが各サービス別に分かれており、サービス間連携や他社サービスとの連携が不可
認証サーバとSQLサーバが密結合しているため、負荷が大きくなり性能低下
課題

2
複数サービスの認証を統合、サービス間連携も
A f t e r センター
全サービスシステムの認証データを
まとめた認証プラットフォーム
Master
DB
更新⽤
DB
S/O配信
プロセス
KFEP
他社サービス
サービスA
サービスB
サービスC
サービスD
・・・・・
（数十種）
S/O配信プロセスが
更新⽤DBのデータを
レプリケーション
KFEPに契約者情報等を
ファイルで配信
統合によりサービス間連携を実現、メンテナンス性も飛躍的に向上● 認証⽤のサーバ数は90%以上削減
マスターDB更新⇒ KFEP反映の所要時間は、5秒以内
1,000万ユーザまで対応可、秒間1,500処理を実現● マスターDB、更新⽤DBは改修不要
解決

スマートフォン、フィーチャーフォンの利用者認証＆利用状況管理
ポータル
メール
サービスシステム
管理DB群
Internet
Web
ゲートウェイ
マスター
DB
利⽤状況
管理システム
3
Before
データの転送遅延が頻発し、サービスに重大な支障が発生
将来のサービス拡大に対応するためのスケールアウトができず、運⽤負荷の軽減も困難
課題

スマートフォン、フィーチャーフォンの利用者認証＆利用状況管理
すべての処理時間を記録し、
障害発生箇所の特定を迅速化
ポータル
メール
Web
ゲートウェイ
存続中の旧システムとも連携、
シームレスな移⾏を可能に
【旧】
管理システム
KFEP
サービスシステム管理DB群
ユーザの利⽤状況データを
処理し、バックエンドのDBへ送信
3
A f t e r
4,500万ユーザ対応
システムの安定稼働を実現すると同時に、秒間15,000処理の要求性能を達成
3台以上のn台構成を可能とし、将来の拡張性を確保
解決
Internet

導入先ご担当者さまコメント
「社内で最も重要なシステムとして認識されています。現在最
も安定して動いているシステムです。」
「RDBベースの他社の伝統的なシステムより堅牢で柔軟、拡張
性に富む。導入以来トラブルもほとんどない」
「とても品質の高いアプリケーションを作成いただき、大変満
足いたしております。
○○○さんによる提案当初は、＊＊＊社の製品で検討しており
ましたが、運⽤機能が貧弱な事が判明し、急遽かもめさんにお
願いする事になりました。
それから期待通りの出来で、さすがだなと大変感心しています。
引き続き、世の為、⼈の為、弊社の為にご尽⼒いただけますと
幸いです。」

かもめの製品の提供方法
SI事業者さまを通じて販売
パッケージ＋
プロフェッショナルサービス提供可
OEMも受けます

１
「KFEP」推奨関連ツール
クロスハブ
S/O（サービスオーダ）配信モジュール「x-HUB」（仮称）
ID情報のシステム間の連携や大量のデータ登録などを一元的に管理し処理を⾏う、データ配信コントローラです。
※ 弊社パートナー企業より提供
基幹システムのS/O投入先はx-HUBだけとなり、構成の簡素化も実現。
基幹システムで⾏っていた各サービス向けのデータ加⼯はx-HUBで⾏うため、基幹システムの負荷が大幅に軽減。
新規サービスが追加されてもS/O投入はx-HUBで⾏うため、基幹システムの改修は不要。
サービスシステム群KFEP
リアルタイムに同期
基幹システム
サービスA
サービスB
サービスC
サービスD
サービスE
x-HUB
CORE
Engine
CORE
Engine
CORE
Engine
Copyright© 2008-2014 KAMOME Engineering, Inc. All rights reserved. 45

まとめ
認証基盤は、
RDBを上手に使う（使わない）と
うまくいく。
KFEPなど、疎結合、分散処理の仕組みは
案外使い勝手がよいかもしれない。

ご清聴ありがとうございました。
ご興味をお持ちの方は
あとでお声掛けください。
詳しくお話を伺うための
ワークショップも開催予定です。
お問い合わせ先
かもめエンジニアリング株式会社営業部
sales@kamome-e.com
03-6420-3177

「明日の認証会議 3」講演用スライド 20141002（配布用）

More Related Content

What's hot

Viewers also liked

Similar to 「明日の認証会議 3」講演用スライド 20141002（配布用）

More from マジセミ by （株）オープンソース活用研究所

「明日の認証会議 3」講演用スライド 20141002（配布用）