クラウド時代のアーキテクチャ

古い資料ですが、SlideShareが使いづらいのでこちらでもアップします。

Transcript

1. クラウドにおけるシステムのあり方（例） 株式会社ビッグツリーテクノロジー＆コンサルティング SI事業部 アーキテクチャG リード 高安 厚思
2. 1 2 3 4 5 アジェンダ ▌自己紹介 ▌1 DXとその背景 ▌2 クラウドにおけるシステム基盤 ▌3 クラウドにおけるシステム構成 ▌4 クラウド時代のアプリケーション構成 ▌5 クラウドを意識したDevOps ▌終わりに Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 2
3. 1 2 3 4 5 自己紹介 高安 厚思 ▌ 活動領域・キーワード ▌２０年にわたり、ソフトウエアエンジニアリングを適用したシステム開発やコンサ ルティングに携わる。 ▌最新技術を適切に利用した、柔軟なシステム構成の構築、品質管理を中心とし て技術マネージメントなどを主要テーマとして活動。 ▌開発方法論、アーキテクチャ設計コンサルティング、システム全体設計を得意分 野とする。 ▌東京電機大学非常勤講師、SQuBOK設計開発領域 検討委員、ITSS-DS検討委 員 ▌資格 ▌ネットワークスペシャリスト ▌アプリケーションエンジニア（現 システムアーキテクト） ▌プロジェクトマネージャ ▌ITストラテジスト ▌情報処理安全確保支援士 ▌AWS Solutions Architect Associate ▌MCSE＆MCSD Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 3
4. 1 2 3 4 5 対外活動 n最近の著書、訳書 ▌ 「システム設計の謎を解く（ソフトバンク）」 改訂版 ▌ 「StrutsによるWebアプリケーション スーパーサンプル（ソフトバンク）」 ▌ 「Seasar入門[（ソフトバンク）」 ▌ 「Javaルールブック（エクスメディア） ▌ 「ITアーキテクトのためのシステム設計実践ガイド アーキテクチャ編（日経BP）」など。 n連載記事執筆 ▌ 日経SYSTEMS誌「Webアーキテクチャ再入門」 n講演 ▌ SODEC ミッションクリティカル開発 ▌ 日本テクノセンター セミナー講師 ▌ UML Forum講師 ▌ 日経BP社 ITアーキテクトのためのシステム設計フォーラム 特別講演 講師 ▌ Developers Summit 2013 Summer Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 4
5. 1 DXとその背景
6. 1 2 3 4 5 最初に Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 6 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
7. 1 2 3 4 5 DXの定義 ▌IDCの定義が、経産省のDXレポートの定義にもなっているため、紹介する。 Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 7 企業が外部エコシステム（顧客、市場）の破壊的な変化に対応しつつ、内 部エコシステム（組織、文化、従業員）の変革を牽引しながら、第３のプラッ トフォーム（クラウド、モビリティ、ビッグデータ／アナリティクス、ソーシャル技術） を利用して、新しい製品やサービス、新しいビジネス・モデルを通して、ネットとリ アルの両面での顧客エクスペリエンスの変革を図ることで価値を創出し、競争上 の優位性を確立すること 経産省 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⽇
8. 1 2 3 4 5 デジタルトランスフォーメーション（DX） ▌時代が変化して、資産にもとづくビジネスモデルではなく、資産をプラット フォーム化したプラットフォームにもとづくビジネスモデルへ変化している ▌BPOやクラウドサービスの組み合わせなど、コアコンピテンシー以外は外部 へアウトソースやエコシステムの利用へ変化していく Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 8 人 情報 資産 ビジネス システム プロセス 販売 人 金 情報 資産 ビジネス システム プロセス 販売 プラットフォーム （API） 顧客 顧客 協業 金 API
9. 1 2 3 4 5 APIエコノミーの発展 ▌Uberの成功事例をはじめとしてシリコンバレーでは、自社システムのAPIを外 部に公開するAPIエコノミーが潮流である。 APIを外部に積極的に公開すべ き理由として以下がある。 Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 9 ・SoR(*1)とSoE(*2)との開発スピードの差異を吸収 ・新規顧客層へのリーチ ・モバイルとIoTの進歩に伴うマルチデバイス対応 ・コアコンピタンスに注力 ＜APIを外部に積極的に公開すべき理由＞ *1 SoR(Systems of Record)。基幹系、勘定系など安定性・信頼性が求められるシステム。 *2 SoE(Systems of Engagement)。 ECサイトなどユーザの意見を取り入れて素早いリリースが求められるシステム
10. 1 2 3 4 5 位置情報サービス（API） ▌室内の位置情報を元にした位置情報サービスを提供しています。 ▌ハードが必要です！ 10 経路管理 BLE管理 経路/ BLE情報 運営者 位置情報 APIs 位置情報 経路情報/ BLE情報 利用者 Copyright (C) 2018 Atsushi Takayasu All Rights Reserved.
11. 1 2 3 4 5 FintechでのAPI ▌2017年はFinTechの急速な立ち上がりによって、外部APIが充実してきた。 Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 11 u 三井住友銀、アプリで入出金照会 2社と連携 (2017/7/27) u 千葉銀、アプリ運営会社と提携 (2017/7/27) u マーケット情報を瞬時にスマホ配信 QUICKが新サービス (2017/6/28) u 常陽銀、個人通帳のアプリ開発 年内にも提供へ (2017/6/13) u みずほ銀など、資産管理アプリと口座を連動 安全性より高く (2017/5/22） u 三菱UFJが「API」開放へ（2017/3/12)
12. 1 2 3 4 5 IoTによるインダストリ４.0 ▌製造業は製造する製品をインターネットと接続し、製品をプラットフォーム化 することでビジネスを再構築しています。（DXの製造業の例） Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 12 デバイス（センサー、アクチュエータ） ベンダー クラウド IoTプラットフォーム （AWS IoTなど） API アプリ 認証・認可 デバイスデータの受信（MQTT） デバイスレジストリ デバイスシャドウ 製造業は製品として構 築。クラウドまで提供。 インフラはクラウドベン ダーを利用することが 多い。
13. 1 2 3 4 5 情報の取り扱いの変化 ▌情報の種類が増えて、取り扱い方が多岐にわたるようになった。 13 Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 多岐にわたる 入力情報 IoTによるデータ取得、AIによる解析結果など 入力情報は今までの業務情報以外の情報取 得が多くなった。 多岐にわたる 参照形態 各データの検索・参照（OLTP）、各データの分 析（BI）、自動的なインサイト（データマイニング、 AI）の取得などデータの取り扱い方も多岐に わたり、意味がないと思われたデータも保存 する傾向にあり、格納形式は特性に応じて異 なることに（DBMS、NoSQL、ファイルなど）
14. ２ クラウドにおけるシステム基盤
15. 1 2 3 4 5 コンテナプラットフォーム(サーバレス実行基盤） ▌CNCFによる推進もあり、コンテナ技術が進化。 開発環境からそのまま本番環境へ 15 開発環境 コンテナイメージ ハブ イメージプッシュ 検証環境 本番環境 イメージデプロイ イメージデプロイ 環境差異は環境変数で吸収。（12 Factor App /3 設定） このコンテナを宣言的に書くこともできる。 ビルドすることでイメージとなる。 単一コンテナのみで運用されることは少なく、 これらのオーケストレーションが求められる。 （Kubernetes（k8s)） Copyright (C) 2018 Atsushi Takayasu All Rights Reserved.
16. 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); }); }; Copyright (C) 2018 Atsushi Takayasu All Rights Reserved.
17. 1 2 3 4 5 APIゲートウェイ （API管理基盤） ▌コンテナ＋アプリケーション、FaaSによってAPIを公開するのは容易になった ▌一方でAPIに共通の処理（認証・認可、ログなど）を統一的に行う必要もうま れた 17 Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. API ゲート ウェイ コンテナ ＋ アプリ FaSS 外部サービス クライ アント データ ストア
18. 1 2 3 4 5 クラウド時代の分析基盤 ▌いまや、データレイクにもとづく分析基盤とBIは当たり前のアーキテクチャ 18 データ ソース データ レイク 転送 データ 変換 データ ストア データ 分析 アプリ データ変換 サービス Copyright (C) 2018 Atsushi Takayasu All Rights Reserved.
19. 1 2 3 4 5 ガバナンス強化のための運用基盤 ▌クラウドは部分的に導入するよりも全面的に入れるのが効果的。 19 監査ログ 構成ルール 統制 IAM Amazon CloudWatch AWS CloudTrail AWS Config AWS Trusted Advisor AWS Organizations 監視 監視項目の統制および統合監視を実施すること でシステム全体を自動的に監視対象とする。 ログ出力場所を統制。ログをもとにした運用、改 善、自動化を支援する。 ログ統合 構成変更、システム管理者のオペレーションなど のログを監査用として利用可能。 構成ルール、運用ルールをチェックし、アラートを あげることができる。
20. 1 2 3 4 5 （参考）システム基盤 ▌システム基盤はクラウドに移行することで標準にしたがったいくつかの基盤 の組み合わせで構成される 20 p 文字情報基盤 p 認証・認可基盤（SAML、OAuth2） p 承認フロー（ワークフロー基盤） p JOB実行基盤 p インフラ統合基盤（IaaS、セキュリティ（監査など）） p データ統合基盤（MDM、データ配信基盤、DWH、オープンデータ） p システム連携基盤 p 帳票基盤 p リリース基盤 p システム管理基盤（構成管理、インシデント管理、サービスデスク管理など） p 開発基盤（ALMなど） p ログ統合基盤 p 運用基盤（監視、性能分析など） p 情報基盤（ポータル等） p IoTプラットフォーム p データ・レイク（AI・BI基盤） Copyright (C) 2018 Atsushi Takayasu All Rights Reserved.
21. 3 クラウドにおけるシステム構成
22. 1 2 3 4 5 クラウド時代で何が変わったのか？ ▌クラウドが浸透することで何が変わったのでしょう？ Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 22 インフラの制約がなくなった データ量の制約 インフラ調達の速度 リソースの制約 構築期間の短期化 コストの適正化 構築コストの低さ 従量課金による合理的なコスト 接続性の向上 自動化 安全かつ無停止の実現 安全な接続 制約がなくなり、アーキテクチャのあり方も変化した
23. 1 2 3 4 5 参照処理 ▌格納先（データストア）の種類が増えて、取扱も容易になりました。 ▌以下の観点で適材適所に選択します 23 Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 同時アクセスの観点 同時にアクセスする数が多い場合、分散でき るかどうかを判断する。 検索方式の観点 文字列検索（特に部分一致）、キーアクセスで きるもの、できないものなどに注目し、適切な 格納先を選ぶ 性能の観点 検索結果を得るまでのレスポンスタイム、転 送時間などを配慮する データ量の観点 データ量が多寡で、適切な格納先を選ぶ。 構造の観点 非構造データ、階層化データなど
24. 1 2 3 4 5 更新処理の変化 ▌データ更新量が爆発的に増加すると更新に対するアーキテクチャも変化する Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 24 サービスＡ サービスＢ 呼出元 アプリケーション メッセージキュー （ストリーミング） 更新ハンドラ 更新ハンドラ ※⼀部の更新ハンドラで失敗した場合は、結果整合性を担保するた めに更新とは逆の処理（補正トランザクション）を実施します。 更新処理を実施する場合は、メッ セージキューを利⽤して、順序性を 維持する。 （MQTT QoSレベル０，１，２） 同⼀の更新データに対して、対象データが必要 な場合は、メッセージキューに登録された更新 をイベントとして取得して処理する。
25. 1 2 3 4 5 クラウド時代のアーキテクチャ方針 ▌更新系と参照系の「CQRSパターン（Command Query Responsible System) 」と呼ばれる構成を採用する ▌結果整合性を採用し、ACIDの整合性は担保しない ▌すべてのデータはデータ・レイクに複製保存する ▌「one fact in one place」ではなく「one fact has one owner」を採用する Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 25 ! " # $ % & コマンド モデル データ ストア データ ストア クエリ モデル イベント 書き込み 更新 読み取り CQRSパターン
26. 1 2 3 4 5 アーキテクチャの例 ▌クラウド時代のアーキテクチャの例を考えました この例に各クラウドのサービスをあてはめると一つのソリューションができます Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 26 IoT アプリ IoT クラウド ストリーミ ング REST サービス キュー イベント ハブ 更新 ハンドラ データ ストア データ・ レイク コンテナ 分析 分析 サービス データ ストア 変換 PG 変換 サービス （AIなど） BIなど DBMS NoSQL 検索エンジン
27. ４ クラウド時代のアプリケーション構成
28. 1 2 3 4 5 MSA（Micro Service Architecture） ▌マイクロサービスアーキテクチャはAPIを用いたアプリケーション構成技術の 一つです。 ▌アプリケーション一つが機能全体を実現するのではなく、一つの役割だけを もつ小さい機能単位に分割された独立したモジュール（プロセス、DBが独 立）として構成されます。 28 Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 但し、基盤としてセキュリティ、トラフィック管理、オーケストレーション、監視、開発者ポータルなどを準備する必要がある。 書籍詳細画面 推薦 サービス 書影 サービス 評価 サービス 価格 サービス 概要 サービス ソーシャル サービス カート サービス 在庫 サービス 配送 サービス マーケットプレイス サービス ウィッシュリスト サービス
29. 1 2 3 4 5 （参考）MSAと統合の例 ▌MSAに基づいたサービスを画面で統合する 29 Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ 【引⽤元】 https://www.slideshare.net/JayLee1/cf-meetup-in-seoul-spring-cloud-services
30. 1 2 3 4 5 マイクロサービスアーキテクチャの利点 ▌マイクロサービスアーキテクチャは以下のような利点を持ちます。 30 構成の単純化 （技術多様性の許容） サービスの特性にあったシステム構成（ミドルウェア）の選定をお こなうことが可能となる。 データの局地化 データの種類・データ量が全体から部分に変化することで激減す る。性能上のリスクをあらかじめ減少させることができる レジリエンスの強化 障害発生時は各サービス単位で停止するため、システム全体は 停止せず、機能的な縮退をおこなうことでサービスダウンがしにく い構成にでき、性能の適正化がしやすい 配置の最適化 各サービスがプロセスとして動作するため、複数プロセスを負荷 分散させることでリソースを適切に利用できるようになる デプロイ範囲の局所化 改修した場合に影響範囲が小さく、サービス単位でリリースでき るためデプロイが容易になる リプレイス容易性 環境変化によって一部機能が逸脱してもマイクロサービス単位で あればリプレイスは容易になる 影響範囲・知識の 局所化 開発時の業務知識や変更の際の影響範囲を局所化することが できる Copyright (C) 2018 Atsushi Takayasu All Rights Reserved.
31. 1 2 3 4 5 マイクロサービスアーキテクチャの課題 ▌一方でマイクロサービスアーキテクチャにも課題がある 31 障害ポイントの増加 機能に対するプロセスが多くなり、プロセス障害に対する数が増加する 障害対応の煩雑さ 障害発生ポイントが多くなり、ログの確認、障害発生時の対応が煩雑 となる 呼出のオーバヘッド サービスを呼出して、機能を実現するためHTTP通信のオーバヘッドが 発生する バージョンアップ時の影 響 サービスとして呼び出されている箇所を修正する必要があり、サービス が本格的に利用されてくると把握がしにくくなる トランザクションの維持 サービスをまたがるトランザクションの維持（更新系）を実現する必要 がある モジュールの増加 モジュール増加によって関連するモジュールが増加し、構成管理やデ プロイが煩雑となる Copyright (C) 2018 Atsushi Takayasu All Rights Reserved.
32. 1 2 3 4 5 参考）分散ログの取り扱い ▌サービス単位でログを出力するとトラブル時に分析しにくい 32 サービスA 呼出元 アプリケーション サービスB サービスC リクエストIDの採番 リクエストIDの 伝播 ログ ログ ログ ログ リクエストIDの 伝播 リクエスト IDの伝播 ログ統合基盤 ログ転送 ログ転送 ログ転送 ログ転送 リクエストIDでログ統合基盤を検索することでリクエスト全体の確認が可能となる。 時刻の比較によってレイテンシの評価などもおこなえる。 （Cf. SpringCloud Sleuth/Zipkin Fluentd(Logstatsh)/ElastsicSearch) Copyright (C) 2018 Atsushi Takayasu All Rights Reserved.
33. 1 2 3 4 5 マイクロサービスとアプリ ▌マイクロサービスはアプリではありません。 33 Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. アプリ （SPA） フロント エンド サービス サービス サービス サービス サービス API ゲート ウェイ
34. 5 クラウドを意識したDevOps
35. 1 2 3 4 5 DevOpsの考え方 ▌DevOpsは最初は必ずカルチャー・組織論。 ▌もし、自動化を先にすると最初しか自動化されない。 ▌DevOpsは運用を実装する 35 価値観として組織にインストール されないといけない DevOpsはITILは両立できる！ DevOpsの実現できた組織であ れば、運用の改善サイクルは 運用を実装すること。この実装 をマネージすることが必要でこ れにおいてITILのプロセスフ レームワークを利用できる。 https://speakerdeck.com/opelab/20171212-automation?slide=20 Copyright (C) 2018 Atsushi Takayasu All Rights Reserved.
36. 1 2 3 4 5 DevOps/NoOps ▌故障しない構成ではなく、故障を前提にした設計が重要です ▌自動化（インフラ構成、パイプライン）と自律を構成します。 36 インフラ 構築 スクリプト クラウドAPI 構成管理ツール ビルド デプロイ 自動 テスト リリース ビルドツール CI デプロイツール CD E2Eテスト クラウドAPI 障害対応 設計 障害検知 設計 運用 設計 リリース 設計 運 用 設 計 Copyright (C) 2018 Atsushi Takayasu All Rights Reserved.
37. 1 2 3 4 5 参考）システムリリースの変化 ▌Infrastructure as a Codeによって環境の構築が容易になったことで、リリー スの方法も変化がうまれました。 37 BlueGreen Deploy Canary Release 本番環境（正） 本番環境（新規） サービスへのアクセス 本番環境（削除） 本番環境（正） サービスへのアクセス 次のバージョンの デプロイ サービスの切替 （リリース） 本番環境（正） 本番環境（副） 次のバージョンの デプロイ サービスへのアクセス 一部のユーザのアクセス （5%など）
38. 1 2 3 4 5 リリースプロセスの自動化 ▌2016DevOps状況レポートによると業績の良いIT企業は「デプロイ頻度200倍、 リードタイム2555分の1」の差があるとあります。これを実現するためにはリ リースの自動化とガバナンスが重要になります。 38 自動化する ※人間の判断が必要な場合がある コード管理 ビルド 検証デプロイ 自動テスト 本番デプロイ CodeCommit CodeBuild CodeDeploy CodeDeploy Selenium CodePipeline Copyright (C) 2018 Atsushi Takayasu All Rights Reserved.
39. 終わりに
40. 1 2 3 4 5 非機能要件について（仮説） ▌非機能要件という言葉がなくなる日が来るのではと思ってます！ 40 Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. クラウドによる システム構成 クラウドによる DevOps クラウドによる アプリ構成 クラウドの構成にはパターンがある そのパターンには特性がある。 （構成を選ぶ基準が非機能要件） → 約款のような非機能要件？
41. 1 2 3 4 5 終わりに ▌クラウドが浸透し、リソースによる制約がなくなってきました ▌リソースの制約がなくなったことでAI・IoTによる革新的なソリューションが構 成されるようになってきました ▌革新的なソリューションをもとにビジネスが再構築されてきています 41 Copyright (C) 2018 Atsushi Takayasu All Rights Reserved. 技術 ❌ ビジネス が問われています。 SoEの思想でビジネス・技術の両側面を見られる アーキテクトが求められています。