2020/03/03 に富士通本社で行われた、富士通TechLiveに発表資料です。 コロナウィルスの影響で、リモート発表になりましたが、当日は800人以上の方に同時視聴していただきましたRead less
![DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive](https://cdn-ak-scissors.b.st-hatena.com/image/square/6e33854ce1cffe1f32aa401e3027d6cd49b0b530/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Ffujitsu20200303public-200305112955-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Kubernetesアップデートのツラミから学んだデプロイ手順のユガミ / Challenges Learned from Kubernetes Update
とあるスマートフォン向けMMORPGのプロジェクトで、アプリケーションサーバをほぼすべてGKE(Google Kubernetes Engine)に乗っけて動かしていました。 このゲームは、モバイル向けながら、複数プレイヤ間でそこそこリアルタイム性の高い同時プレイができるものでした。同じフィールドを誰かが歩けば、自分が見ている画面でもほぼ同時にそいつが歩いて横切っていく、同じ敵と皆で一緒に戦えば、誰かが繰り出した攻撃が参加者全員の画面に即同期される、もちろんチャットもできる、そんな具合です。今ではさほど珍しくないのかもしれませんが、PCのオンラインゲームのような機能を搭載した、リアルタイム性の高いモバイルゲームでした。 さて、こうなってくると、オーソドックスなWebサーバのような、HTTP/1でリクエスト/リプライを捌く、というサーバだけでは要件を満たすことができません。 複数プレイヤ間で
ssmjp 2019/03での発表資料です。 「運用自動化の基本原則」シリーズの番外編と位置付けています。 # 運用自動化の基本原則シリーズ - 2019-03-06 「運用自動化」とは: https://speakerdeck.com/opelab/20190306-operation-what-automation - 2019-05-24 運用業務の「構造化」: https://speakerdeck.com/opelab/20190524-structured-operation - 2019-04-18 運用自動化の基本原則1 「引継ぎの原則」: https://speakerdeck.com/opelab/20190418-operation-automation-basis-principle-1 - 2019-05-24 運用自動化の基本原則2「平易化の原則」: https
ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話 / Moving ZOZOTOWN DWH from Redshift to BigQuery
ここから、DevとOpsが協力すればより効率的になる=DevOps、という言葉が生まれました。 当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。 ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか? ハードウェアの時代その昔、産業の主役はハードウェアでした。 そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。 ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。 加えて、大量生産された製品の運用サポート(設置作業員、サポートセンタ)には、大量の人員が必要になってきます。 したがって、組織を研究
SRE Tech Talks ( http://connpass.com/event/34825/ ) でお話した際の資料です
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く