要求開発アライアンス　9月定例会議

クラウドにおけるシステムのあり方（例）
株式会社ビッグツリーテクノロジー＆コンサルティング
SI事業部
アーキテクチャG リード
高安厚思

1 2 3 4 5アジェンダ
▌自己紹介
▌1 DXとその背景
▌2 クラウドにおけるシステム基盤
▌3 クラウドにおけるシステム構成
▌4 クラウド時代のアプリケーション構成
▌5 クラウドを意識したDevOps
▌終わりに
Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 2

1 2 3 4 5自己紹介
高安厚思
▌ 活動領域・キーワード
▌ ２０年にわたり、ソフトウエアエンジニアリングを適用したシステム開発やコンサ
ルティングに携わる。
▌ 最新技術を適切に利用した、柔軟なシステム構成の構築、品質管理を中心とし
て技術マネージメントなどを主要テーマとして活動。
▌ 開発方法論、アーキテクチャ設計コンサルティング、システム全体設計を得意分
野とする。
▌ 東京電機大学非常勤講師、SQuBOK設計開発領域検討委員、ITSS-DS検討委
員
▌資格
▌ ネットワークスペシャリスト
▌ アプリケーションエンジニア（現システムアーキテクト）
▌ プロジェクトマネージャ
▌ ITストラテジスト
▌ 情報処理安全確保支援士
▌ AWS Solutions Architect Associate
▌ MCSE＆MCSD

1 2 3 4 5対外活動
最近の著書、訳書
▌ 「システム設計の謎を解く（ソフトバンク）」改訂版
▌ 「StrutsによるWebアプリケーションスーパーサンプル（ソフトバンク）」
▌ 「Seasar入門[（ソフトバンク）」
▌ 「Javaルールブック（エクスメディア）
▌ 「ITアーキテクトのためのシステム設計実践ガイドアーキテクチャ編（日経BP）」など。
連載記事執筆
▌ 日経SYSTEMS誌「Webアーキテクチャ再入門」
講演
▌ SODEC ミッションクリティカル開発
▌ 日本テクノセンターセミナー講師
▌ UML Forum講師
▌ 日経BP社 ITアーキテクトのためのシステム設計フォーラム特別講演講師
▌ Developers Summit 2013 Summer

1 2 3 4 5最初に
Software is eating the world.
Why Software Is Eating The World
Marc Andreessen
The Wall Street Journal
August 20, 2011
https://www.wsj.com/articles/SB10001424053111903
480904576512250915629460

1 2 3 4 5DXの定義
▌IDCの定義が、経産省のDXレポートの定義にもなっているため、紹介する。
企業が外部エコシステム（顧客、市場）の破壊的な変化に対応しつつ、内
部エコシステム（組織、文化、従業員）の変革を牽引しながら、第３のプラッ
トフォーム（クラウド、モビリティ、ビッグデータ／アナリティクス、ソーシャル技術）
を利用して、新しい製品やサービス、新しいビジネス・モデルを通して、ネットとリ
アルの両面での顧客エクスペリエンスの変革を図ることで価値を創出し、競争上
の優位性を確立すること
経産省 DXレポート（http://www.meti.go.jp/press/2018/09/20180907010/20180907010-2.pdf）
Japan IT Market 2018 Top 10 Predictions: デジタルネイティブ企業への変革 - DXエコノミーにおいてイノベーションを飛躍的に拡大
せよ, IDC Japan プレスリリース, 2017年12月14日

1 2 3 4 5デジタルトランスフォーメーション（DX）
▌時代が変化して、資産にもとづくビジネスモデルではなく、資産をプラット
フォーム化したプラットフォームにもとづくビジネスモデルへ変化している
▌BPOやクラウドサービスの組み合わせなど、コアコンピテンシー以外は外部
へアウトソースやエコシステムの利用へ変化していく
人情報
資産
ビジネス
システム
プロセス
販売
人
金
情報
資産
ビジネス
システム
プロセス
販売
プラットフォーム
（API）
顧客
顧客協業
金
API

1 2 3 4 5APIエコノミーの発展
▌Uberの成功事例をはじめとしてシリコンバレーでは、自社システムのAPIを外
部に公開するAPIエコノミーが潮流である。 APIを外部に積極的に公開すべ
き理由として以下がある。
・SoR(*1)とSoE(*2)との開発スピードの差異を吸収
・新規顧客層へのリーチ
・モバイルとIoTの進歩に伴うマルチデバイス対応
・コアコンピタンスに注力
＜APIを外部に積極的に公開すべき理由＞
*1 SoR(Systems of Record)。基幹系、勘定系など安定性・信頼性が求められるシステム。
*2 SoE(Systems of Engagement)。 ECサイトなどユーザの意見を取り入れて素早いリリースが求められるシステム

1 2 3 4 5位置情報サービス（API）
▌室内の位置情報を元にした位置情報サービスを提供しています。
▌ハードが必要です！
10
経路管理
BLE管理経路/
BLE情報
運営者
位置情報
APIs
位置情報
経路情報/
BLE情報
利用者
Copyright (C) 2018 Atsushi Takayasu All Rights Reserved.

1 2 3 4 5FintechでのAPI
▌2017年はFinTechの急速な立ち上がりによって、外部APIが充実してきた。
 三井住友銀、アプリで入出金照会 2社と連携 (2017/7/27)
 千葉銀、アプリ運営会社と提携 (2017/7/27)
 マーケット情報を瞬時にスマホ配信 QUICKが新サービス (2017/6/28)
 常陽銀、個人通帳のアプリ開発年内にも提供へ (2017/6/13)
 みずほ銀など、資産管理アプリと口座を連動安全性より高く (2017/5/22）
 三菱UFJが「API」開放へ（2017/3/12)

1 2 3 4 5IoTによるインダストリ４.0
▌製造業は製造する製品をインターネットと接続し、製品をプラットフォーム化
することでビジネスを再構築しています。（DXの製造業の例）
デバイス（センサー、アクチュエータ）
ベンダー
クラウド
IoTプラットフォーム
（AWS IoTなど）
API
アプリ
認証・認可
デバイスデータの受信（MQTT）
デバイスレジストリ
デバイスシャドウ
製造業は製品として構
築。クラウドまで提供。
インフラはクラウドベン
ダーを利用することが
多い。

1 2 3 4 5情報の取り扱いの変化
▌情報の種類が増えて、取り扱い方が多岐にわたるようになった。
13Copyright (C) 2018 Atsushi Takayasu All Rights Reserved.
多岐にわたる
入力情報
IoTによるデータ取得、AIによる解析結果など
入力情報は今までの業務情報以外の情報取
得が多くなった。
多岐にわたる
参照形態
各データの検索・参照（OLTP）、各データの分
析（BI）、自動的なインサイト（データマイニング、
AI）の取得などデータの取り扱い方も多岐に
わたり、意味がないと思われたデータも保存
する傾向にあり、格納形式は特性に応じて異
なることに（DBMS、NoSQL、ファイルなど）

２クラウドにおけるシステム基盤

1 2 3 4 5コンテナプラットフォーム(サーバレス実行基盤）
▌CNCFによる推進もあり、コンテナ技術が進化。
開発環境からそのまま本番環境へ
15
開発環境
コンテナイメージ
ハブ
イメージプッシュ
検証環境本番環境
イメージデプロイ
イメージデプロイ
環境差異は環境変数で吸収。（12 Factor App /3 設定）
このコンテナを宣言的に書くこともできる。
ビルドすることでイメージとなる。
単一コンテナのみで運用されることは少なく、
これらのオーケストレーションが求められる。
（Kubernetes（k8s)）

1 2 3 4 5
FaaS （Function as a Service）
(サーバレス実行基盤）
▌関数で記述する処理を「サーバレス」で実現する
16
APIの容易な実装とイベントハンドラとしての意味
var aws = require('aws-sdk’);
var s3 = new aws.S3({apiVersion: '2006-03-01’});
var bucketName = 'cloud-btc-thumbnail’;
var prefix = 'images/’
exports.handler = (event, context,callback) => {
var result = {};
var params = { Bucket : bucketName, Prefix : prefix };
s3.listObjects(params, function (error, response){
if(error){
result.status = 'error’;
return result;
}
result.list = [];
response.Contents.forEach(function(item){
if(item.Size != '0’)
result.list.push(item.Key);
});
result.status = 'success’;
callback(null,result); });
};

1 2 3 4 5APIゲートウェイ（API管理基盤）
▌コンテナ＋アプリケーション、FaaSによってAPIを公開するのは容易になった
▌一方でAPIに共通の処理（認証・認可、ログなど）を統一的に行う必要もうま
れた
API
ゲート
ウェイ
コンテナ
＋
アプリ
FaSS
外部サービス
クライ
アント
データ
ストア

1 2 3 4 5クラウド時代の分析基盤
▌いまや、データレイクにもとづく分析基盤とBIは当たり前のアーキテクチャ
18
データ
ソース
データ
レイク
転送
データ
変換
データ
ストア
データ
分析
アプリ
データ変換
サービス

1 2 3 4 5ガバナンス強化のための運用基盤
▌クラウドは部分的に導入するよりも全面的に入れるのが効果的。
19
監査ログ
構成ルール
統制
IAM Amazon
CloudWatch
AWS
CloudTrail
AWS
Config
AWS Trusted
Advisor
AWS
Organizations
監視監視項目の統制および統合監視を実施すること
でシステム全体を自動的に監視対象とする。
ログ出力場所を統制。ログをもとにした運用、改
善、自動化を支援する。
ログ統合
構成変更、システム管理者のオペレーションなど
のログを監査用として利用可能。
構成ルール、運用ルールをチェックし、アラートを
あげることができる。

1 2 3 4 5（参考）システム基盤
▌システム基盤はクラウドに移行することで標準にしたがったいくつかの基盤
の組み合わせで構成される
20
 文字情報基盤
 認証・認可基盤（SAML、OAuth2）
 承認フロー（ワークフロー基盤）
 JOB実行基盤
 インフラ統合基盤（IaaS、セキュリティ（監査など））
 データ統合基盤（MDM、データ配信基盤、DWH、オープンデータ）
 システム連携基盤
 帳票基盤
 リリース基盤
 システム管理基盤（構成管理、インシデント管理、サービスデスク管理など）
 開発基盤（ALMなど）
 ログ統合基盤
 運用基盤（監視、性能分析など）
 情報基盤（ポータル等）
 IoTプラットフォーム
 データ・レイク（AI・BI基盤）

3 クラウドにおけるシステム構成

1 2 3 4 5クラウド時代で何が変わったのか？
▌クラウドが浸透することで何が変わったのでしょう？
インフラの制約がなくなった
データ量の制約
インフラ調達の速度
リソースの制約
構築期間の短期化
コストの適正化
構築コストの低さ
従量課金による合理的なコスト
接続性の向上
自動化
安全かつ無停止の実現
安全な接続
制約がなくなり、アーキテクチャのあり方も変化した

1 2 3 4 5参照処理
▌格納先（データストア）の種類が増えて、取扱も容易になりました。
▌以下の観点で適材適所に選択します
同時アクセスの観点
同時にアクセスする数が多い場合、分散でき
るかどうかを判断する。
検索方式の観点
文字列検索（特に部分一致）、キーアクセスで
きるもの、できないものなどに注目し、適切な
格納先を選ぶ
性能の観点
検索結果を得るまでのレスポンスタイム、転
送時間などを配慮する
データ量の観点データ量が多寡で、適切な格納先を選ぶ。
構造の観点
非構造データ、階層化データなど

1 2 3 4 5更新処理の変化
▌データ更新量が爆発的に増加すると更新に対するアーキテクチャも変化する
サービスＡ
サービスＢ
呼出元
アプリケーション
メッセージキュー
（ストリーミング）
更新ハンドラ
更新ハンドラ
※一部の更新ハンドラで失敗した場合は、結果整合性を担保するた
めに更新とは逆の処理（補正トランザクション）を実施します。
更新処理を実施する場合は、メッ
セージキューを利用して、順序性を
維持する。
（MQTT QoSレベル０，１，２）
同一の更新データに対して、対象データが必要
な場合は、メッセージキューに登録された更新
をイベントとして取得して処理する。

1 2 3 4 5クラウド時代のアーキテクチャ方針
▌更新系と参照系の「CQRSパターン（Command Query Responsible System) 」
と呼ばれる構成を採用する
▌結果整合性を採用し、ACIDの整合性は担保しない
▌すべてのデータはデータ・レイクに複製保存する
▌「one fact in one place」ではなく「one fact has one owner」を採用する
ク
ラ
イ
ア
ン
ト
コマンド
モデル
データ
ストア
データ
ストア
クエリ
モデル
イベント
書き込み
更新
読み取り
CQRSパターン

1 2 3 4 5アーキテクチャの例
▌クラウド時代のアーキテクチャの例を考えました
この例に各クラウドのサービスをあてはめると一つのソリューションができます
IoT
アプリ
IoT
クラウド
ストリーミ
ング
REST
サービス
キュー
イベント
ハブ
更新
ハンドラ
データ
ストア
データ・
レイク
コンテナ
分析分析
サービスデータ
ストア
変換
PG
変換
サービス
（AIなど）
BIなど
DBMS
NoSQL
検索エンジン

４クラウド時代のアプリケーション構成

1 2 3 4 5MSA（Micro Service Architecture）
▌マイクロサービスアーキテクチャはAPIを用いたアプリケーション構成技術の
一つです。
▌アプリケーション一つが機能全体を実現するのではなく、一つの役割だけを
もつ小さい機能単位に分割された独立したモジュール（プロセス、DBが独
立）として構成されます。
但し、基盤としてセキュリティ、トラフィック管理、オーケストレーション、監視、開発者ポータルなどを準備する必要がある。
書籍詳細画面
推薦
サービス
書影
サービス
評価
サービス
価格
サービス
概要
サービス
ソーシャル
サービス
カート
サービス
在庫
サービス
配送
サービス
マーケットプレイス
サービス
ウィッシュリスト
サービス

1 2 3 4 5（参考）MSAと統合の例
▌MSAに基づいたサービスを画面で統合する
①
②
③
④
⑤
⑥
⑦
⑧
⑨
⑩
⑪
【引用元】
https://www.slideshare.net/JayLee1/cf-meetup-in-seoul-spring-cloud-services

1 2 3 4 5マイクロサービスアーキテクチャの利点
▌マイクロサービスアーキテクチャは以下のような利点を持ちます。
30
構成の単純化
（技術多様性の許容）
サービスの特性にあったシステム構成（ミドルウェア）の選定をお
こなうことが可能となる。
データの局地化
データの種類・データ量が全体から部分に変化することで激減す
る。性能上のリスクをあらかじめ減少させることができる
レジリエンスの強化
障害発生時は各サービス単位で停止するため、システム全体は
停止せず、機能的な縮退をおこなうことでサービスダウンがしにく
い構成にでき、性能の適正化がしやすい
配置の最適化
各サービスがプロセスとして動作するため、複数プロセスを負荷
分散させることでリソースを適切に利用できるようになる
デプロイ範囲の局所化
改修した場合に影響範囲が小さく、サービス単位でリリースでき
るためデプロイが容易になる
リプレイス容易性
環境変化によって一部機能が逸脱してもマイクロサービス単位で
あればリプレイスは容易になる
影響範囲・知識の
局所化
開発時の業務知識や変更の際の影響範囲を局所化することが
できる

1 2 3 4 5マイクロサービスアーキテクチャの課題
▌一方でマイクロサービスアーキテクチャにも課題がある
31
障害ポイントの増加機能に対するプロセスが多くなり、プロセス障害に対する数が増加する
障害対応の煩雑さ障害発生ポイントが多くなり、ログの確認、障害発生時の対応が煩雑
となる
呼出のオーバヘッド
サービスを呼出して、機能を実現するためHTTP通信のオーバヘッドが
発生する
バージョンアップ時の影
響
サービスとして呼び出されている箇所を修正する必要があり、サービス
が本格的に利用されてくると把握がしにくくなる
トランザクションの維持
サービスをまたがるトランザクションの維持（更新系）を実現する必要
がある
モジュールの増加
モジュール増加によって関連するモジュールが増加し、構成管理やデ
プロイが煩雑となる

1 2 3 4 5参考）分散ログの取り扱い
▌サービス単位でログを出力するとトラブル時に分析しにくい
32
サービスA
呼出元
アプリケーション
サービスB
サービスC
リクエストIDの採番
リクエストIDの
伝播
ログ
ログ
ログ
ログ
リクエストIDの
伝播
リクエスト
IDの伝播
ログ統合基盤
ログ転送
ログ転送
ログ転送
ログ転送
リクエストIDでログ統合基盤を検索することでリクエスト全体の確認が可能となる。
時刻の比較によってレイテンシの評価などもおこなえる。
（Cf. SpringCloud Sleuth/Zipkin Fluentd(Logstatsh)/ElastsicSearch)

1 2 3 4 5マイクロサービスとアプリ
▌マイクロサービスはアプリではありません。
アプリ
（SPA）
フロント
エンド
サービス
サービス
サービス
サービス
サービス
API
ゲート
ウェイ

5 クラウドを意識したDevOps

1 2 3 4 5DevOpsの考え方
▌DevOpsは最初は必ずカルチャー・組織論。
▌もし、自動化を先にすると最初しか自動化されない。
▌DevOpsは運用を実装する
35
価値観として組織にインストール
されないといけない
DevOpsはITILは両立できる！
DevOpsの実現できた組織であ
れば、運用の改善サイクルは
運用を実装すること。この実装
をマネージすることが必要でこ
れにおいてITILのプロセスフ
レームワークを利用できる。
https://speakerdeck.com/opelab/20171212-automation?slide=20

1 2 3 4 5DevOps/NoOps
▌故障しない構成ではなく、故障を前提にした設計が重要です
▌自動化（インフラ構成、パイプライン）と自律を構成します。
36
インフラ
構築
スクリプト
クラウドAPI
構成管理ツール
ビルドデプロイ
自動
テスト
リリース
ビルドツール
CI
デプロイツール
CD
E2EテストクラウドAPI
障害対応
設計
障害検知
設計
運用
設計
リリース
設計
運
用
設
計

1 2 3 4 5参考）システムリリースの変化
▌Infrastructure as a Codeによって環境の構築が容易になったことで、リリース
の方法も変化がうまれました。
37
BlueGreen Deploy
Canary Release
本番環境（正）
本番環境（新規）
サービスへのアクセス
本番環境（削除）
次のバージョンの
デプロイ
サービスの切替
（リリース）
本番環境（副）
次のバージョンの
デプロイ
一部のユーザのアクセス
（5%など）

1 2 3 4 5リリースプロセスの自動化
▌2016DevOps状況レポートによると業績の良いIT企業は「デプロイ頻度200倍、
リードタイム2555分の1」の差があるとあります。これを実現するためにはリ
リースの自動化とガバナンスが重要になります。
38
自動化する
※人間の判断が必要な場合がある
コード管理
ビルド
検証デプロイ
自動テスト
本番デプロイ
CodeCommit
CodeBuild
CodeDeploy
CodeDeploy
Selenium
CodePipeline

1 2 3 4 5非機能要件について（仮説）
▌非機能要件という言葉がなくなる日が来るのではと思ってます！
クラウドによる
システム構成
DevOps
アプリ構成
クラウドの構成にはパターンがある
そのパターンには特性がある。
（構成を選ぶ基準が非機能要件）
→ 約款のような非機能要件？

1 2 3 4 5終わりに
▌クラウドが浸透し、リソースによる制約がなくなってきました
▌リソースの制約がなくなったことでAI・IoTによる革新的なソリューションが構
成されるようになってきました
▌革新的なソリューションをもとにビジネスが再構築されてきています
技術 ❌ ビジネス
が問われています。
SoEの思想でビジネス・技術の両側面を見られる
アーキテクトが求められています。

要求開発アライアンス　9月定例会議

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 要求開発アライアンス　9月定例会議

Similar to 要求開発アライアンス　9月定例会議 (20)

More from Atsushi Takayasu

More from Atsushi Takayasu (9)