2019-07-23 CloudNative Days Tokyo 2019 / OpenStack Days Tokyo 2019 Day2 #CNDT2019 #OSDT2019
2019/07/23 に開催された CloudNative Days Tokyo 2019 / OpenStack Days Tokyo 2019 Day2 のイベントレポートです。
■Day1の様子
■決済システムの内製化への旅
SB PaymentService
●内製化に至る道のり
・2016
開発はすべてベンダ
-> 運用効率化を自分たちで
支援ツールを内製
spring boot
selenium/selenide
エンジニア 3名入社！
・2017
サービス監視の質を高める
ｰ> ElasticStack
開発プロジェクトの支援
古いアーキテクチャ
-> spring boot, cloud
・2018
決済システムの内製化
加盟店 -> 決済システム -> 決済機関
●ベンダに頼り切っていてはスピード感が出せない
・継続的な改善へ
-> Pivotal Cloud Foundry
・リリースの改善
リリース時間の短縮
ゼロダウンタイムリリース
ワンクリックリリース
人的ミスの撲滅
・クラウドのフル活用
スケーラブル
セルフヒーリング
●Kubernetes or PaaS
・エンジニアとしては興味がある
・すでに確立されたプラットフォームがほしい
●Public PaaS or Private PaaS
・エンプラなのでPrivate
-> Pivotal Application Service
Java/Spring親和性
サポート
cf pushコマンドでアプリリリース
Buildpackにbuild, tag, pushをお任せ
・プラットフォーム、アプリそれぞれのチームは役割に集中
しばりは12factor appだけ
●アーキテクチャ
加盟店
-> API Gateway
-> ServiceA
サーキットブレーカー
コントロール不可能な外部サービス間の
障害影響の伝播を抑止
-> 決済機関A
●CI/CD
・concourseを採用
●Observability
・metrics
grafana
VM、コンテナ、CFコンポーネント、ミドルウェア
開発時は意識不要
・logging
kibana
必要な観点で確認できるダッシュボードを用意
開発時はstdoutするだけ
・tracing
zipkin
どのサービスが遅いか、調査に便利だった
●metrics, logging, tracing + Biz
・サービス目線でのモニタリング
決済手段ごとのOK/NG数
決済数、取扱高、前日比、傾向
など
■金融領域におけるOpenStack導入事例の紹介
YJFX
●YJFX
・Yahooジャパンの子会社
・事業の会社
開発はベンダーに委託していた
ここ数年で内製化
・外貨ex
一般投資家 <-> 為替差益 <-> 銀行
・投資家の設けは時価の差分
5,000 回/秒 で変化
22 通貨ペア
10+ 銀行
-> max 1,000,000 回/秒
●システム規模
・口座数 : 35万+
・ノード数: 500+
・システム: 40+
●システム構成
trader
-> channels
-> customer
-> front ★
-> analyze ★
-> bank
●背景
・開発/stg環境をpublic cloudを持っていた
・コスト面
上がる一方で減ることはなかった
・デリバリ面
アプリチームは設定を触るノウハウがない
インフラチームがクラウドを設定
稟議を上げないと、クラウドリソースを払い出せなかった
-> OpenStack導入へ
●良かったポイント
・うまくいったシステムは ansibleを活用できた
物理サーバを使っていても、作り直すスタンスへ
ペットではなく家畜
-> 100サーバを30minで
●苦労したポイント
・ansibleを活用できないシステムの移行
イメージが大きい
・トラブルシューティング
サポートの問い合わせは待てない
ドキュメントを読む、結局ソースを読む
簡単ではない継続した対応が必要
●導入効果
・RedHat Summit 2019で登壇
・レガシー固執メンバ、経営層から認められた
-> 小さなチャレンジが認められた
●今後の展望
・金融業界を取り巻く状況
インターネット企業の金融参入
規制・監査への対応
-> 不確実性への対応
・Cloud Nativeになっていく
単にクラウドにサーバを載せているだけ
クラウド前提でアーキテクチャ刷新
レガシーシステムのモダナイズ
-> 経営課題を解決するAgilityを得る
・組織文化の醸成
Bestを探し続ける
-> Betterし続ける
大きい変化・刷新
-> 小さい変化の積み重ね
システムは手段
-> システムは事業成長エンジン
変わることがリスク
-> 変わらないことは緩やかな死
■Change the Game, Change the World
Red Hat
●Platform on Platform
・2017？ Google Next
k8sはクラウドのlinuxになる
・最近は変わってきた
k8sはplatformをつくるためのplatform
●Platform Strategy
・書籍: プラットフォーマー
在庫を持ったり製造したりするものではなく
コミュニティの力で製品を推し進めていくのが原則
・プラットフォームとは
他の製品/サービス/情報と一緒になって初めて価値を持つ
ポイント加盟店 <-> ポイントサービス <-> 利用者
・Airbnb ビジネスモデル
ホスト <-> Arirbnb <-> ビジター
ホスト、ビジター双方にメリットが必要
どんな部屋だったらビジターが楽しめるか
ランクが上がった部屋にはビジターが増える
・Network Effect
利用するメリット > 利用するコスト
相互ネットワーク効果
ユーザーとユーザをつなげる
双方にメリットが必要
外部ネットワーク効果
外のコミュニティからの流入
・k8s はクラウドのlinux
velocity, self-healing, abstraction
プラットフォーマーへの依存がなくせる
・k8sはプラットフォーム
運用者
どれだけプラットフォームに任せられるか
開発者
ユーザー影響をさいしょうに
簡単にデプロイできるか
どう動いているのか、などの心配が大きい
まだコストの方が大きい
学ばないといけないところは
どうしたって学ばないといけない
●+Native
・運用工数を下げるポイントが、既存と大きく変わるという意識改革
・自分たちがどうやってクラウドのメリットを得るか、を考える
●Operator
・運用の知見をコード化
アプリであればk8sに任せられる
statefulなサーバ、backupなど が入ってしまったサーバはOperator
・知見をコンテナに閉じ込めて、運用を自動化
・k8sはプラットフォームをつくるためのプラットフォーム
Operatorは他のプレイヤーの存在や価値を前提にしている
●OperatorHub.io
・Operatorの認定
・コミュニティから上がって、RedHutのテストを通ったら出てくる
-> Red Hat Cerified Operators
●Operator Framework
・SDK
・Lifecycle Manager
・Metering
●learn.openshift.com
・katacodaで試せる
・https://learn.openshift.com/operatorframework/
●Cloud + Native
プラットフォームをつくる側なのか、活用する側なのか
を意識して、価値を生むためにどう利用していくかを考える
■OpenStackを用いたパブリッククラウドの国内事例と課題
GMO Internet
●GMOのサービス
・OSSのOpenStackを利用してきた
2012 Diablo
2013 Glizzly
2014 Havana
2015 Junoをカスタマイズ
●OpenStackに携わったきっかけ
・2014 ネットワークエンジニア
やり方が決まっていて知識欲を刺激するものがない
-> OpenStackが流行
・当時のメンバー
ジャンルの垣根を意識しない
枠にとらわれない
動かないものをどうやったら使えるか
・米国のクラウド勢に負けないパブリッククラウドサービス
納期、仕様はfix
OpenStackではまともに動かないものも実現が必要だった
安定稼働させる分野が多かった
・2015〜2018
規模起因の改修
・2019
デスクトップクラウド
OpenStackなしで独自実装
●OpenStackを採用しているモチベーション
・コスト、工数短縮
・拡張性、操作API
・社員をつなぐ
●OSS x メーカー製品
・OSSだけにこだわるより、うまく使い分ける方が品質・効率は上がる
・難しいことを作り込むと、運用が大変になる
・はやりの技術ネタにつきものの時間泥棒
●OpenStackは楽になったが、それなりの体制や人を維持が必要
規模が小さいとメリットがない
規模が大きいと運用が難しくなる
■いつもニコニコあなたの隣に這い寄るカオスエンジニアリング！
小倉 真人 さん [NTTコミュニケーションズ]
●カオスエンジニアリングとは
・Netflixがはじめた
2010年ごろから
・意図的にシステムに障害を起こして
より強いものにしていく
・疫学、予防医学に近い
病気の伝播
予防注射
●resilience
・難しい状況や出来事の後に、より良くなるための能力
●なぜカオスエンジニアリング？
・すべての状態を把握するのは不可能
・Netflix
失敗を避けるための一番良い方法は
失敗し続けること
・Microservices
どこで問題を把握することは無理
●カオスエンジニアリング≒障害試験？
・failure testing
故障時に正しく動くこと
・fault injection
障害時の状態をテストするためのアプローチ
・chaos engineering
新しい情報を作り出すためのアプローチ
resilienceの確認ではない
●想定外はいつもそばに
・障害発生時の指摘
なぜ想定外を想定できない？
・ジョハリの窓
問題を知る
解決することでResilienceを得る
・システムに関係するすべてのものが障害を起こす原因になる
本当は恐ろしい分散システムの話
●カオスエンジニアリングをはじめる前に
・関連サービス障害やNW遅延に耐えられますか？
-> まず対処しましょう
・システムの現在の状態が把握できますか？
-> 把握できる状態にしてからはじめましょう
●カオスエンジニアリングのはじめかた
・CHAOS IN PRACTICE
定常状態を定義
対照群、実験群の両方で定常状態が続く想定
実際に起きうる障害を注入
対照群と実験群の違いを探す
-> 仮説検証
・定常状態から仮説を構築
スループット、エラーレート、レイテンシのパーセンタイルなど
ブラックボックス的
・実世界のイベントを反映
ハード故障、ソフト故障、スパイク
影響度合いや推定頻度から優先度を決める
・本番環境のトラフィックで直接検証
Netflixでは本番環境の5%程度なのだそう
sandboxで試してみるべきという話もある
参考: Netflix
500マイクロサービス
故障しても、お互いに波及しない
動画配信だから、人名には影響しない
バッファが効いている間に対処できれば良い
・検証は自動化し、継続して実行
自動化しておかないと、継続的に実施できない
GameDays
・影響範囲を局所化する
一時的に障害が起きる
一時的にユーザに苦痛が起きる
長期的に見たらより良くなる
苦痛を最小限に抑えましょう
●実現するツール
・ChaosMonkey
NetflixがOSS公開
AWSのインスタンスを落とすやつ
最近はSpinnaker連携でAWS,GCE,Azure,k8sで使える
k8s部分はGoogleが担当
命名規則のバッティングらしい
Similian Armyは引退したそう
・kube-monkey
Cluster内のPodをランダムに削除
・Pumba
コンテナを壊す、止める
NWのエミュレーション（遅延、パケットロス/重複/破損）
Dockerのsocketを掴んでいる様子
・Envoy
実はfault injectionの機能がある
エラーレスポンス
NW遅延
・Resilience as a Service
Gremlin
無料だとシャットダウン、プロセスkillくらい
ちょっとはじめてみるなら良さそう
serverlessなら
アプリケーション内にfault-injectionのしくみをつくる
・OpenStack Eris
負荷をかけていってテストフレームワークやテストスイートをつくる
開発中？
動画があるらしい
・クラウド事業者のカオスエンジニアリング（想像）
GCP : Preemptible VM
AWS : Spot Instance
Azure: low-priority VMs
-> カオスエンジニアリングの検証環境に見える！
●関連情報
・ChaosEngineering
無料本がある
・Chaos Engineering Slack
直近で起きた有名な障害の情報も流れてくる
・Awesome Chaos Engineering
各種情報がまとまっている
・Chaos Toolkit
カオスエンジニアリングのためのOpenAPIとToolkit
各サービス向けのエクステンションがある
■〈みずほ〉におけるAWS・Kubernetesを活用したリアルタイム為替予測のアプリケーション開発
板谷 悟 さん [みずほ情報総研]
●みずほ
・クラウド上でAI、ビッグデータの活用を進めている
・機械学習でリアルタイムの為替相場から予測
●アプリの紹介
・数分のディレイで、120min先までを予測
・背景
必要なリソースを必要な分だけ確保
DataCenter->AWS
モダンなアーキテクチャ
モノリス->SPA & マイクロサービス
・技術要素
k8sで可動させる
できるだけマネージド・サービス
EKSは使わず、KOPSで
helm管理
●アーキテクチャ
・FeedAgent
Refinitivからマーケットデータを取得
websocket
kinesis data streamsへ
・convert streaming
S3
kinesis data streamsへ
・realtime processing
予測モデルへ流し込むための加工
1分足、5分足
予測モデル
rabbitMQへ
-> visualization
・前処理
spark->S3
・学習処理
夜間バッチ
jupyter notebook
・CD
Spinnaker
●AWSネットワーク設計
・VPC
・AZ
・public
・private
・k8s
●k8sクラスタ
・KOPS
AWS上でk8sクラスタを構築
Terraformのスクリプト生成もできる
-> Terraformから作成した
S3に設定情報を保存
・クラスタ作成
kops create cluster ${NAME}
--node-count=0: 明示的に指定しないと2で作られる
・インスタンスグループ
worker node
インスタンスタイプを3つに分けた
minSize, maxSize -> AWS target group がこの範囲でautoscale
yaml管理も、terraformに追記もできる
kops update cluster
rolling-upgradeもできる
●ストリーミング処理
・Spark
データの抽出、加工で利用
spark on kubernetes
driverとexecutorそれぞれがPodとして稼働
clientからspark-submitするとkubectlが流れるイメージ
-> CDしにくい
・今回はspark-submitのclientもPodで
起動時に spark-submit
停止時に kubectlでPodを削除
・チェックポイントの保存先はEFS
●分析環境
・考慮したポイント
JupyterHubで複数データサイエンティストがアクセスできるように
CPU/GPUを選べるように
・Jupyterhub with Kubernetes
ユーザに紐づくEBSが割り当てられるように
helmでインストール
Kubespawner
ユーザーごとのPod
PV, PVC作成
ログイン後にCPU/GPUを選択
●CDパイプライン
・背景
CodeCommit
CodeBuild
ソースのビルド
Docker Build
ECR
pushされるとhelmでデプロイ
・Spinnaker
Build webhook -> CodeBuild
Bake -> helm chartをbase64変換
deploy -> helm cahrtをデプロイ
・パイプライン
CodeCommit -> Lambda -> Spinnaker
Spinnaker.Build(POST) -> Lambda -> CodeBuild
Spinnaker.Build(GET) -> Lambda -> CodeBuild
Spinnaker.Deploy -> k8s
●アプリの課題
・MasterNodeの運用コスト
-> EKSへ
・Podごとの権限管理
-> kiam, kube2iam
・監視やログ、メトリクス収集のしくみ
-> EKSなら、CloudWatch Container Insights
・GPUのJupyter Notebookが起動に時間がかかる
-> 高いので、インスタンスを止めてある。
●パイプラインの課題
・アーキテクチャが複雑
CodeCommitとSpinnakerの相性が良くない
-> CodePipeline
k8sだと工夫が必要
・開発環境でビルドしたDocker Imageのタグを、本番に伝えられない
CodeCommitのコミットハッシュを渡している
別のパイプラインに引き継ぐ方法がない
■サーバレス・ネイティブ が お伝えする、フルサーバレス開発の魅力
江藤 武司 さん [Riotz.works]
●アイデアを即、形にできる魅力
・開発を高速にする
・ハッカソンの事例
ラップ、タップ、アップ
3人チーム 24時間の中
アーキテクチャ
REST API
API Gateway
Lambda
DynamoDB
通知
firebase
動画配信
SkyWay
・IoTの見守りシステムの事例
基本機能は 2人 2ヶ月で完成
●アプリの開発に専念できる魅力
・実行ランタイムを手軽に扱える
様々なランタイムが用意されている
カスタムランタイムも
周辺システムとも統合されている
オートスケール、監視、ログなど
・IoTバックエンド開発プロジェクトでの事例
既存のオンプレシステムとバッチで連携してほしい
工場、販売、配送
既存がjavaだったのでjavaで作成
シンプルな構成だったがIoT向けに追加
VPC Lambdaでホワイトリスト化
タイムアウトが多発
-> 分割しすぎ
-> コールドスタートに当たる確率が上がった
気づいたのはS-in 1ヶ月前
-> 実行ランタイム Node.js に変えた
当時 Javaの起動時間は遅かった
CPU高負荷時は Node.jsの性能が良かった
※現在は、java x コールドスタートでも 1秒くらいで起動
つなぎはそのまま、ロジックだけ言語に合わせればOK
ミドル、スケール、監視、それを扱える人は？
●ピタゴラ装置を組み立てる魅力
・多様な機能と様々なサービスから組み立てられる
クラウド内に多様な機能が用意されている
マルチクラウドで、各クラウドの強みを引き出して組み立て
SaaS連携で更に様々な機能も
・ピタゴラ装置例
マネージドサービスのイベントを利用して、functionはシンプルに
●JAMStakなサイト管理の魅力
・JAMStack
クライアントサイドJavaScript
再利用可能なAPI
構築済みのマークアップ
・アーキテクチャ
BuildToolで静的な、構築済みのHTMLをCDNに置く
JavaScriptでAPIを叩いて
・メリット
パフォーマンス
CDN活用
HTML生成なし
より安価で簡単なスケーリング
CDNのスケーラビリティ
セキュリティ
WebAPIに局所化
開発者エクスペリエンス
APIはエンジニア
BuildToolを使ってHTML生成するのはデザイナ
・ウェブサイトの場合
contentsをmarkdownで作成
Gridsomeでhtml化 -> GitHub pages
・Shifter
概要
Serverless WordPress
編集はWordpressコンテナ
生成 -> lambda -> CDNにpublish
より高いパフォーマンス
より高いセキュリティ
より安価で簡単なスケーリング
より良質な開発者エクスペリエンス
Shifter webhhooks -> StaticSiteGenerator
GatsbyやGridsome、Nuxtにインポート
10/22 に ServerlessDays Tokyo 2019開催！
■スタートアップサービスでもやれる!Kubernetesを使ったセキュアWebアプリの構築と運用
藤原 涼馬 さん [リクルートテクノロジーズ]
●リクルートグループ
・1960 大学新聞広告社からスタート
60年近い歴史があるんですね
・まだ、ここにない出会いを提供する
ライフイベント領域
ライフスタイル領域
●藤原さん
・RancherによるKubernetes活用ガイド 出版！
●Webアプリケーションセキュリティ
1. アプリケーションそのものを堅牢にする
セキュアコーディングで脆弱性の少ないコード
JPCERT CC
徳丸本
・ヒトは必ず実装ミスをする
・脆弱性は簡単に根本対策できない
コードがコントロール外など
2. アプリケーションを別の方法で保護する
WAF
Webアプリケーションファイアウォール
Webアプリケーションに特化
リクエストのヘッダ・ボディの内容をチェック
IDS
不正侵入検知システム
ネットワークにおける怪しい挙動がないかを検知
ポートスキャン、syn floodなどの検知
WAFに近い挙動をすることも
外向けの通信を確認する製品も
●今日のスコープ
・WAF/IDSは特効薬ではない
出てきた問題を防ぐもの
カスタムもできるが流通しているルールも沢山
すぐには修正できない脆弱性を見つけた
-> WAFでワークアラウンド
セキュアコーディングすることが前提
・k8sとパブリッククラウドでWAF/IDSの導入、運用を楽にするには
●導入と運用
1. WAF/IDSのデプロイ
2. 検知ルールの運用
基本ルールのアップデート
不要なルールの除外
カスタムルールの追加
3. 検知・監査と通知
●WAFの導入と運用
・ModSecurity-nginxを採用
OSS
システム構成を変更なしで品質の向上できそう
システムの規模と運用負荷が比例していまいがち
・登り方
1. WAFを知る
modsecurity + OWASP CRS
2. サポート取得
modsecurity + Nginx や SpiderLabsなど
3. CDN上のWAF活用
システムが大きくなってきたら
fastly + WAF
modsecurity互換
-> すべてmodsecurityベースなので、ノウハウを引き継げる
・課題
ルールのアップデート
ルールの管理
アラートのしくみ
・ルールのアップデート、管理 への対応
rule-updaterをサイドカーで定義
1. 最新ルールを取得して配置
2. カスタルールをアップデート
CustomRule: ConfigMap
3. nginxで再読み込み
・アラートのしくみ への対応
検知ログファイル
-> Stackdriver
何かあれば、まずここを見る場所をつくる
-> アラート
●IDSの導入と運用
・Suricata
oinkmasterでルールアップデート
・デプロイ方法
1. k8sのノードにインストール
2. Podとして動かす
hostNetwork: true
k8sノード側ネットワークをPodに見せる
DaemonSet
・課題はModSecurityと同様
対応も同様
●k8sを活用したWebアプリケーションセキュリティ実装
・低コストではじめることはできる
・WAF/IDSは必須
・導入より運用に手がかかる
●k8sの外側のセキュリティは？
・情報を溜め込んでいる場所を守りたい
オブジェクトストレージ
RDB
KVS
・予防
アクセス制御をがんばる
・監査
各種ログ
-> stackdriver logging
-> アクセスログ格納バケット
-> CloudFunctionで分析
●まとめ
・低コストにはじめられる
・サービスのスケールに合わせたセキュリティ品質の登り方
・セキュリティの取り組みはすべてのサービスで必要
やるやらないではなく、どこまでやるか
・k8sと蔵合うどサービスで手間は少なく構築できる
運用をどうしていくか
■感想
・Bestを探し続ける から Betterし続ける へ
・プラットフォームは、NetworkEffectを起こす
・問題を知り、解決することでResilienceを得る
・サービスの成長に合わせた、運用の登り方
など「なるほど！」をたくさん頂けました。
JAMStack 初めて知りましたが、すごい発想ですね！
・DOMの構築に時間がかかるなら
事前に組み立ててhtml化してしまえば良い
・APIで提供するデータには更新頻度がある
頻度によっては事前にhtml化してしまうこともできる
・事前に静的なファイルにすることで
CDNを活かせる
役割を明確化できる
SPAもそうですが、CMSの記事は、改めて考えるとぴったりな運用ですね。
2日間を通して、たくさんの学びと共感をいただきました！
登壇者の皆さん、運営の皆さん ありがとうございました！！
この記事が参加している募集
いつも応援していただいている皆さん支えられています。