memo.org

keysession

opening

本会議: 2013年~ (6回目)

特徴

有償化

組織運営を中立的、専門的に継続させるために参加者にも費用負担してもらう

これまでは、宣伝のため無料としていた

openstack Days Tokyo/Cloud Native daysとcloud Nativeがtitleに付与された

様々なOSSを連携する一要素としてのopenstackの下回りという位置を存在づける

アプリも含め市場ニーズを如何に迅速に実現するかを目的とした組織として方向を位置付ける

本会の規模、ターゲット

参加登録者: 1000名以上

ターゲット: Infra開発者多数

Q:利用しているクラウド基盤

A

OpenStack 32.7%AWS 27 %Azure 13.1%GCP: 8.2%

社内活用しているクラウドの種別

Private: 450

Public 200

hybride: 190

hosted: 100

The Evolution of the OpenStack Foundation

Speaker

Jonathan Bryce

OpenStack Foundation

OpenStackの現状

利用状況: 10,000,000 core 稼動中(cpu?)

テレコムキャリア分野のうち71%基盤に活用

アナリスト分析: 61億ドルの潜在価値がある

最新機能

NovaによるvGPUの割り当て可能化

1回のupgradeで複数のバージョンを一度にアップグレード可能

長期期間活用できるLongTermバージョンの提供

活用分野

サイエンス

リテール・製造・銀行

今後の方向

拡張

AI・機械学習

コンテナ

Serverless

アーキテクチャ

x86

FPGA

GPU

協業

OSSの活用数の増大にともない単独開発が困難になるので、コミュニティで活用を推進していく

企業もコニュニティに貢献することで収益につながると認識し投資をおこなっている

チェルンー k8sの1000PJ

戦略: 4つの内容を回していく

ユースケースの収集

啓蒙活動

課題の洗い出し

次に作るものを明らかにする

成果物

whitepaper

注目の適用環境

edge環境リテール製造コネクティドカー

コラボレーション

コミュニティを越えた連携

新技術の開発

ホットな技術

kata container軽量コンテナテナントごとにカーネルを切れるZuulCI/CDのパイプライン管理

開発内容の実践

kubecon openstack summitからみるコンテナ技術の最新トレンド

kube conへの参加理由

言葉の定義

k8s on openstack

openstack on k8s

k8s on openstack on k8s

edge cloud

ネットワーク網の構築nfv

アクセスポイントよりも先

nfv cloud

なぜコンテナにフォーカスするのか

たくさんのものをどう配備するか(edge cloud)

場所の制約(edge cloud)

architecutre

k8s google上でうごく

機能に不足

googlecomputeエンジンがカバーしていた

最新トレンド

cncfのランドスケープ

課題

cloud native networkの選択が難しい

選択肢が多くなやましい 、決定打に欠ける

外部nwからコンテナへの接続のためのソリューションが難しい

fipの指定のようなもの。。

ない

storage apiが用意されたばかり

9ちょんおう nativeappの継続デリバリノウハウが日本で不足している

最新トレンド

cubecon

年3回(GWの時期)

4000人(日本 60名)

app エンジニア対象

googleのイベント感がある

openstack summit vancouver

年2回

opene infrasummitになりそう

container 1/3、nfv 1/3 、openstack 1/3

運用者の課題についてのディスカッションがおもしろい

技術

airship(openstack on k8s)

at&t

under cloud : k8s

1時間放置で構築ができた

v1.0

構築ツールとしてすごい!! これからはこれになる

kata container

軽量コンテナ

だが、hyperviso

hw offloard

コンテナ環境でマルチテナントの実現可能

gvisorはまだまだ

googleのoss

edge cloudにおけるk8sの課題

cloudnative

可視化、高速化今後calico、cilium

外部network

octavia、yahooのtool社内ツール

cloud native storage

cephでいいのか?げんじょう、on-premise

knowhow継続

airshipspinnakerによる継続デリバリ がいい

デモ k8s

spinnaker と k8s

spinnaker

継続的デリバリができる

netflix後、google

なぜ

デプロイの一貫性がない

安全性が低い

デプロイ履歴が管理されない

pipleのguiを簡単に作る

開発環境、本番環境も簡単に認証ができCI/CDを実現できる

ロールバックを簡単にできる

実装が難しかったが、それを簡便にしてくれた

実績管理もできる

現状の可視化

ロールバックの簡便

課題

設計・設定が必要

ナレッジが少ない

マシンリソース

memory 12G

blog記事あり

Mirantis Cloud Platformが変えるこれからのOpenStack Kubernetes運用

Speaker

会社: mirantis

Nobuchika Kamon

代表取締役

プライベートクラウドにおける運用の課題

mirantis cloud platform

wrap up

intro

仮想化基盤

特徴: リソース活用の有効活用 集約技術

欠点: 管理者による配備までの手間と時間 数日~数時間

クラウド

数秒単位での提供が可能

間の運用管理の省略が可能になる

利点

public コスト制御・ロックイン

しくみ自体の運用から完全開放

ユーザーの使い方に特価した習熟

欠点

ランニングコスト

主張

publiccloudで最新技術を追い続けてpriveteに展開

メリット・デメリットをうまく使い分ける

あたらしいインフラ

public cloudをつかうが、ロックインされない。

先進技術はpublickにする

国内cloudベンダーが実現する技術はプライベートで実現できる

すべてなものはserverless,containerにはならない

あずけないで、自前するコスト低減がありえる

hcihyperconversidinfra

pros

リニアなサイジングが可能

簡単な構築

既存SIerモデルとも違和感なく融合

cons

部分最適の実現が難しい ストレージだけなど一部だけの拡張ができない

大規拡張が難しい

openstack

pros

部分最適の実現がかのう

cons

構築・運用がむずかせいい

小規模な環境には向かない

従来型の管理手法に基づく管理

スプレッドシートなどによる管理から開放されない

従来の課題

うんようの不可・リスクがかわらない

課題

コスト・パフォーマンス

どれぐらいあればいいの

bkどすればいいのとか

多種多様なコンポーネントがありそれをどう使うのかが問題。。。

めんてなんすするための人材育成が難しい

監視をどうする

mirantis cloud platform(mcp)

oss

独自botモデルによる導入

build operate transferをやる

事例

at&t

paypal

wargen

オンプレ上のものをOpenStackに載せる

2ヶ月でやりきる

cloudのslaで契約

サイジング

今までの経験でどれくらい必要かを出す

運用ノウハウを売っていく

物理マシンの構成およびクラスターの構成を提案する

設計済みのテンプレートがありそれを提案する

mcpの構成

k8s openstack

sdn

drive train

cicdでinfrastractureac codeをおこなう

自動化羃等性の実現

運用物理サーバー 10000 台 100人規模

opscare

drivetrain

salt stack 50Mb

service level

汎用もの

system level 10MB

ミランティス推奨の構成

cluster level (顧客管理部分) 200-200kb

利用者の要望の内容code管理 git (作業履歴が残る)コードレビュー gerritテスト9 jenkins自動実行 salt stack

自動化 コードで回すことで恐怖はなくなる

infra のdevopsの実現可能

mcp導入だけでconfigファイルでの管理になる??

考えるところだけ人でやり実行は自動にする

顧客の更新頻度は少ない

コミュニティへの貢献

osの設定など汎用化なものはあげていく

monitoring

監視ポイントが多いもの、どれぐらいで監視すべきかをあらかじめ提供

prometheus

設定ファイルが多い定義するのをやめるsalt stackであるべきすがたを提供する

富士通適用 事例(mirantis 協業)

北大のcloud基盤提供

事項知能、ビッグデータ、IoT

スーパーコンピュータとの結合

性能と柔軟性の使い分けが必要

スタンダードコンフィグ(template)

運用stack right、drive train

container

k8sで動かすようにmicroservicesが動くappを作るものでなければ意味がない

cicd agileによる開発の最大化

mirantis application platform

parformance

microservices appli deploy

speanaker

netflics -> googlemercari商用化して使えるようにしている

IT Automation with OpenStack and Ansible/AWX

speaker

redhat

hideki saito

ansibleのメンテナンス

ansibleの機能(ソリューション)

awxの紹介

web フロントエンド

job管理 システム web ダッシュボードからおこなう

コンテナでうごくapp

ansible + AWSの一歩すすめる自動化

awsが解決する課題

5w1hを残したい

playbookの実行結果をまとめて管理したい

個々人のログになってしまう

playbookの陳腐化

バージョン管理(チームでの作業)

みんな最新化したものを実行したい

work flowの定義

a->b,a->cなどの条件分岐など

ターゲットホストの認証情報の一元管理したい

キャパシティ管理が難しい

フォーク数(並列)の管理はしてくれない

controllホストのリソースをみない

複数のノード実行するとsshなどのメモリ消費する(100MB/1node 実行)

OOM killerに殺される

キャパシティープランニングをしたい!!

外部システムとの連携をしたいがAPIがない

AWXの機能

WebUIRESTful

ユーザー管理(AD,Google OAuth2)

ターゲットホストの認証情報の一言管理

外部iaasとの連携機能あり(AWS,GCP,Azure ,OpenStack)

Playbookのリビジョン管理(Github/gitlab)

複数のジョブのワークフロー(rundeckのようなもの)

job結果を他のシステムに飛ばせる(slackなど)

logstashなどの外部システムとの連携が可能

multiノードができる(HAでない)

AWXの位置付け

AWXのeterprise Ansible Tower

upstleam

ansible towerへの要望をアウトしたもの

自動化プラットフォーム

Docs

Ansible Towerをみるしかない。。。

インストール

doekcerのインストールとpythonモジュール

ansibleでinstall

codeのclone

構成

5コンテナ

postgresqlに情報集約webtask9memcachedrabbit

demo

/credential(認証情報)

playbookの実行につかう

管理

ansible towerにある。

認証情報(default準備)

openstack

vault

vmware vCenter

API(RESTFUL)

tower-cli(restful cli ver.)

job実行の仕組み(負荷分散に関わる)

docker

Django

nginx

postgresql: 情報の蓄積

rabbitmq

celery :rabbitmqからのとりだし

supervisord: celeryの実行

ansible

k8sでスケールアウトできる

postgresql以外のコンテナを同一Podに格納してスケールアウト

増やせるが、減らせない

減らすと、AWX側でremoveしないといけない 自動で減らせない

アップストリーム版で回収されるだろう

スケールさせると、

memcashed

socketや外部のログ管理機能との連携で使用(記憶させておく)

分散させられるのはplaybook単位

playbookの実行環境をばらすforkの実行をバラスのは難しい、できないコミュニティの結果フットプリントのminiすぐに開放するようにするpython vertial env

jobの流れ

rabbitmqへ

resourceの開きのあるinstanceで ジョブ実行

playbookで実行

callback pluginでdbに書き込み(playbookの独自plubinは使えなくなる)

openstack 連携

dynamicインベントリでリスト作成

cloudymlをつくる

インフラCI/CDの勘所 Azureのアーキテクトが語る

speacker

真壁 徹

日本マイクロソフト株式会社

アジェンダ

インフラのCI/CDの現状

教科書ではなく身近な話

ずばりな答えではないけどヒントになりそうな話

バリバリ系というよりしみじみ系のはなし

Azure以外でもつかえる話し

インフラ

範囲

libpkg、コンテナ、os・vm、infra

ci/cdのパイプライン

インフラ オーナー

設計

優先度づけ

インフラ技術者

開発者

tool

codeかんり

ci

cd

なぜci/cd

コスト削減にはならないかも ない!!

インフラのデリバリが性格に把握されていない

目的があいまいなまま走ることになる

ビジネスが先

困ってなければ、やる必要ない

明日には 配備したいのにできないなどの課題がなければ取り組む必要ない

作業ミスの削減?

コードにバグがあれば、壊れる

実現したときの加点項目にしかならない

でもリーダー次第

リーダーがまとめてやっていけるかいなか

なければ、続かないし実現しない

上はその人をつれてくるのが仕事!!

メリットをつたえないとやってくれないのでは??

みつけて異動する

人と組織

dev/ops

誰がCI/CD パイプラインを作り管理するの??

app/infraの両方にDevOpがある

単純に分けられない

SREのように捉える必要がある

infraが分かるコードを書ける

appの話ができる

toolの目利きができる

パイプラインをつくりながら面倒をみれる人(運用できる人)

SREの組織化が必要

受託開発との相性は微妙 (infraではできないこともある)

少数精鋭すぎる問題

ビジネス側が少数精鋭を期待するのは仕方ない

市場価値があり転職しやすい!! ここ重要

誰かが止めた瞬間にレビューが破綻する

レビューし会えるメンバーが3人以上必要

ツールとtec

流行り廃りが激しい

使ってみて当面信じられると感じたツールを使う

どれを使っても苦労するのは同じ

使う人が決める!!

使う人を巻き込んで購入する

ツールのせいにすると、人の責任になる

git難しい問題

コードでインフラを表現するならばコードの管理は重要!!

gitがデファクトだが難しい

手を動かして覚えないといけない!!

あたたかく向かえないと離れてしまう

branch/flow

チームメンバーが理解できない

みんなで勉強する必要がある!!そしてルールを決めていかないといけない

deploy羃等性の幻滅期

理想であるが、信頼できない

プラグインの中身を理解しているのか??

プラグインに依存しているため、信頼できないかもしれない

コードをすべてよめない。。。

内部的にstateをもつもの(terafform)変更すべきか否かをみる

この状態が壊れるため、実行の信頼ができない

破壊的な何かがおこる

そうなったときの策を用意する

戦略

ドキュメント不要論

半分賛成

コードで管理 docいらない??

コードで表現できないことがある。意図とかが表現できない

全体像、依存関係などはdocに残す

issue truckkingとかでかける

commitにbkを書こう

未来の自分へのラブレター

アジレタチエィへの期待

変化を受け入れて継続改善する?

そんなことない

決めることはしっかり決めるnetworkはあとから変更できない 破綻するキャパシティは無限でないlbのinboundは強い(azure)but,snat は限られているどれぐらいのVMを作るのかを考えておく必要がある

アプリCI/CDとの違い

単体テストが難しい

変更に限ったtestが難しい

networkのテストが難しいfilterのテスト全部のappがokになるかの確認が非常に難しい

deployに時間がかかる

失敗したときのリスクがある戻すときのリスクがある(時間が変更以上にかかる可能性あり)

テスト監視の一部とする()

こういう監視項目をみてokか否かでおこなう変更内容で監視項目がエラーになるかをテストしてみる

ネットワークの継続的deployは現実的か

リスクが高いもどらないかのうせいもあるため。。

contanuous delusion at the infrastructure layer (cloudscaling.com/blog/devops/co)

testとシミュレーションにはかなりのコストが必要テストはシミュレータでおこなう何かで実現できるものを作る必要あり

管理単位を分けてみる

dynamicとstaticで分けるdynamic:頻繁に変わる(vm,container)static: network,datastoredeployは手動コードは管理

基盤のアップグレード

openstack,k8sinpreesアップグレード? 信用できない同じ環境でのテストはされない(vendor)有事に誰かの せいにしても、失われたものは戻らない

解決できる戦略

データは王様戦略

新しいものを作って切り替える

外側にdatabaseをつくりまもり、実行環境をつなぐ

エンドポイントだけを切り替えるようにする

inpressアップグレードより信頼をおける

一時的な増設費用だけ

外部とのインターフェイスを絞る(Hub & Spoke戦略)***** hub ネットワークにすべてを集約していく(external <- hub nw <- private nw)

hubネットワークにsubネットワークを追加していく

host名、サービス名をpjに伝える

IPの伝達だと、全変更する必要がでてくる

NetAppでつくる、OpenStackストレージ基盤~ストレージの選定で気をつけるべきポイント~

Speaker

小林慶太

上田雅幸

Yahoo 株式會社 システム統括本部 サイトオペレーション本部

概要

Yahoo: 5年以上、netappのストレージを使っているoepnstack基盤

マニラの導入もおこなった、その問題などについての報告

Openstack ストレージ

インフラのビジネス要求のみたしかた

agenda

インフラ

ストレージの課題と解決

openstack 環境とストレージの取り組み

インフラ

pageview 752億

service 100以上

規模感

論理容量: 65PB (1,5年前 50PB)

ストレージのみを縦に積むと、380mの高さになる

DCの数:西日本3,東2

サーバー数75000台

現象傾向にある

仮想server1200,000

Cinder提供

netappを使っている

netappのOpenStackへの取り組み(三谷)

2011年からOpenStackについて取り組む

cumunityへの貢献

cinder

機能追加 30,25

bug修正14

コード行数

manila

外部ストレージ提供の課題と解決

課題

クラスター作成ごとにストレージが必要になる(外部ストレージの増大)

検証や機能追加による増築に工数が急増する

設備投資が減らない

構築業務がなくならない

構築後の運用作業の増大

解決: ストレージとclusterをわける

集約単位

システムの分岐点

DC,AZなどで分けていく

nwのつくり(りーちほうほう)

L2 -> L3

専用コア・CLOS NW

理解促進活動が必要に。。

ストレージの管理

拡張可能な構成

高性能

ポリシーによる論理分割

NETup

管理単位の提供ができる

ストレージレイヤーでの対応も可能

管理台数の増大(クラスターごと)

集約ストレージ

費用削減

管理性向上

あたらしい

監視体制

拡張のタイミングの見極め

openstackドライバとの互換性

つたえたいこと

ストレージに着目した設計が重要になる

openstack環境ストレージの課題と解決(提供部分のストレージのおはなし)

クラスターの一部にストレージがある

cinder volume

問題

filestorageの需要

openstack manila

privae環境

hv障害のdowntimeの短縮

イノジーネイバー

高いdisk性能

all cinderrvolume boot

manila

cinderのfile

shared file system

nfs smbの提供

backendにいろいろなstorageをつかえる

クラスターごとのボリュームを管理したくない

複数のopenstackclusterから利用可能なもの

拠点/セキュリティ要件単位でアクセス

必要に応じてbkストレージを拡張

色々なストレージをつかえるように

注意点

機能面: ストレージの機能として期待どおりの機能をするか

ドライバの実行でうごかないかのうせいがある

shareを削除してもストレージ内に実態が残る

ここのきのうは動くがくみあわせると使えない

動作面:

デフォルトの動作がことなる場合がある

manilaからshareをつくったときにowerがかえられるか？

デフォルト設定/APIで設定可能か

apiでたたくので、そこが動けば意図どおりに動かせるようになる

Netup

機能

manilaの異能の大部分の提供をしている動作に問題なしuserからの動作apiまわりの提供ができていたので拡張できた

今後

拡張/別拠点展開のため他のvendorも確認中

openstack cinder

cinder boot

vmの稼動中にたのhvへいどうできるlivemigration

hv障害時に復旧をまたずに別のhvでVMを起動できる

vmが稼動するので、性能、容量が必要

costがたかい

sds(software defined storage)のけんとう

さまざまな要因のため安定提供ができなかった(半年でclose)

性能は十分だが、提供がこんなん

新たなsdsの選定検証中

sdsの検証

製品とあぷらいあんす製品の検証

安定性そうていどおりに動かないことが多い本番と同じ環境での検証が重要nw設計/設定が重要ストレージ通信が外内部の通信が外にでるので設計missで通信がうまくいかないnetworkエンジニアとの連携が必要ベンダ対応リクエストへの対応修正 リリースの速さかならずbug はっせい するのでその対応がどうなっているかの確認をみきわめておくひつようがあるsdsベンダの対応範囲の広さ何を保証するのかを明確化しておく

sdsの検証結果

まだ実用化には至らなかったflexcloneをつかったsnapshot vmの展開は優秀cost 削減が必要

sds製品の検証は継続

物理ストレージ環境管理が煩雑化netappストレージで集約クラウドストレージmanilaとallcindervolumebootのストレージ検討netappストレージの採用別製品の検討は継続中

netappのsds

openstack component

ontap select 検証ができる

課題

nodeついかじのしょうがいとりばらんす

性能劣化の検討が必要

そこを検討した設計が必要

whitepaperがある

cinderのもんだい

iscsiだと上限がでてくる

snapshotの劣化

overwriteで劣化するが、それがない

snapshot volumeのclone

filecloneされるだけ

扱いが簡便

完了までの時間がみじかい

制約をのこさない

途中経路のsnapshotの削除が可能

manila サービス

共有ファイルシステムサービス

クラウド間の自由な移動

2日目のkeynoteセッション

概要

CloudNativeにフォーカスした講演

Cloud nativeによるglobalな破壊的な変革

speaker

桂島

ガートナー

概要: 現在のクラウドの適用状況についてと企業がcloud nativeの適用にあたり考慮すべきことはなにか

現状

コンテナの利用状況

ガートナー顧客へのアンケート: 40%(半数程度)が活用

活用状況: 一部分への適用(大規模化はまだ)

技術トレンド

disappearing inder datacenter: 企業のDCがなくなる

onpreのサーバー(workload): 右肩下り(70%@2018 ->30% @2024)

off-Premises,Cloud(workload): 増加(20% @2018 -> 40,50% @ 2024)

すべてがクラウド化ではないが、社内のDC、機器類は減少する

onpreへの提供・cloud運用企業は淘汰される

cloud fast

ITの設計がcloudでのdeployをまず考え、不可能であれば自社(onpre)との設計になる

今までのサイクルが逆転する

収益が最大となるポイントでの運用を考慮して設計する能力が求められる

containerとserverless

cloud shiftで生まれた新たな技術

仮想化/container・Serverless の違い

仮想化

目的

リソースの集約

container・Serverless

目的

開発速度の向上

既存開発の持ち出し(lift and shift)レファクタリングmicroservices化して連携、管理の簡便化k8sコンテナのオーケストレーション化をおこない運用コストを下げる

クラウドのメリットの最大化

OSkernelの共有化起動速度の短縮

AP開発者と連携しての設計が必要