サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
My name is Zhenzhong Xu. IjoinedNetflix in 2015 as a founding engineer on the Real-time Data Infrastructure team and later led the Stream Processing Engines team. I developed an interest in real-time data in theearly 2010s, and ever since believe there is much value yet to be uncovered.Netflix was a fantastic place to be surrounded by many amazing colleagues. I can’t be more proud of everyone
GoogleのSREとSecurityによるBuilding Secure Reliable Systems という本の中で「Zero Touch Production (ZTP) 」という考え方が紹介されていた．これはインフラの権限管理やインフラの構築そのものの指針となる概念であり，自分がそうあるべきだとずっと思ってきた考え方でもある．これはどのような考え方なのか?をこれまでの歴史を踏まえて具体的なツールや事例とともにまとめておく． Zero Touch ProductionBuilding Secure Reliable Systems においてZero Touch Production (ZTP) は以下のように定義されている． The SRE organization atGoogle is working tobuild upon the concept of least
In thisblogpost we’ll talk about the oldNginx-based traffic infrastructure,its pain points, and the benefits we gained by migrating toEnvoy. We’ll compareNginx toEnvoy across many software engineering and operational dimensions. We’ll also briefly touch on the migration process,its current state, and some of the problems encountered on the way. When we moved most of Dropbox traffic toEnvoy
社内勉強会で「ワクワクする！システム監視入門」という発表をした． 今年の3月頃から DevOps の推進をメインで担当していて，技術的負債の解消，運用改善，外部サービスの導入など，様々な施策を進めている中で，監視の強化も頑張っている．個人的には相当良くなったなー！と思っているんだけど，先日の Infrastructure as Code 勉強会で @songmu さんの話を聞いていたら「監視に対する敷居を下げるべき」という話があって，非常に刺さった．基本的に每日メトリクスを追っているのは僕で，もしかしたら敷居が高いのかもしれないなと感じた．もっとメンバーにもメトリクスを見てもらいたいし，アプリケーション開発に活用してもらいたい！というモチベーションが生まれて今回の発表に繋がった． kakakakakku.hatenablog.com 発表資料 （公開するために一部画像を加工してる） 負荷低
ChatGPT関連情報の追い方、個人・業務での使い方、サービスへの組み込み方、 ABEJAでの取り組み4例、ここ2週間のトピックなど行けるところまで
私はここ１週間ほど、同僚の David の一言で Infrastructure as Code について頭が大混乱状態でした。 それは次の一言です。 Chef や Puppet は大体の部分は Infrastructure as Code じゃないよね。ARM (Azure Resource Manager) はそうだけど。 ただ、Chef-Provisioning は Infrastructure as Code だよね。 もう頭が大混乱です。なんとなく言わんとしていることはわかりますが、私は今まで Chef とか、Puppet とか、Ansible とかで やっているようなことが、Infrastructure as Code と思い込んでいましたが、何か間違っていたのでしょうか？そういえば、 Chef はConfiguration Management Toolと紹介されていたなとか頭
はてなエンジニア Advent Calendar 2017の2日目です。 昨日は、id:syou6162 さんによるAWSLambda上で鯖(Mackerel)の曖昧性問題を機械学習で解決しよう - yasuhisa'sblogでした。 この記事は、人工知能学会 合同研究会2017 第3回ウェブサイエンス研究会の招待講演の内容を加筆修正したものです。 講演のテーマは、「自然現象としてのウェブ」ということでそれに合わせて、「自然のごとく複雑化したウェブシステムの運用自律化に向けて」というタイトルで講演しました。 一応、他の情報科学の分野の研究者や技術者に向けて書いているつもりですが、その意図がうまく反映されているかはわかりません。 概要 1. ウェブシステムの信頼性を守る仕事 2. ウェブシステム運用の現状 国内のウェブシステムの運用技術の変遷 クラウド時代 コンテナ型仮想化技術 サーバ
The CNCF Cloud Native Landscape is intended as amap through the previously uncharted terrain of cloud nativetechnologies. This attempts to categorize most of the projects and product offerings in the cloud native space. There are many routes to deploying a cloud native application, with CNCF Projects representing a particularly well-traveled path. This repository contains the data files and imag
ごきげんよう。プレイドの@tik-sonと申します。 みなさんはクラウドプラットフォームを利用していますか？ 弊社のKARTEは 秒間3000イベントをリアルタイムで解析 累計解析ユーザがリリースから2年で12.5億 https://karte.io/infographic/2017.html という規模のサービスになっています。 そこで動いているインフラもそれなりに大規模になっており、インフラをいかに改善していくかが事業進捗に大きく関わってきます。 そのインフラを改善する試みとして半年ぐらい前から、AWSとGCPの２つのクラウドプラットフォームを組み合わせ、マルチクラウドインフラとして利用しています。 PLAID EnginnerBlogでは複数回に渡ってマルチクラウドインフラを作る上で試行錯誤したポイントなどを紹介していこうと思います。 今回は初回ということで概要部分について記載し、
Plants vs thieves: Automated Tests in the World of WebSecurity
Webオペレーションエンジニアのid:y_uukiです。 今日は10月7日にGMOペパボ株式会社さんの福岡支社にて開催しました「ペパボ・はてな技術大会〜インフラ技術基盤〜@福岡」のレポートをお届けします。ペパボさんのレポートはペパボ・はてな技術大会〜インフラ技術基盤〜をペパボ福岡支社で開催しました！ - ペパボテックブログにて公開されています。 ペパボさんとの技術大会は、昨年からの継続的な取り組みとなります。 今回の技術大会では、「Webサービス基盤技術の開発・運用の考え方やビジョンとその実践」をテーマにさせていただけないかと、はてなからペパボさんへお願いしました。 というのも、はてなのWebオペレーションチームでは、基盤システムのビジョンを現在策定しようとしているため、そのアウトプットの場になればという思いがあったからでした。 ペパボさんは、「なめらかなシステム」に代表されるように、We
@egapoolです。今回初めてISUCON7に参加させていただきました。（チーム名：元pyns） 当日やったこととこかはこちらにまとめています。 ISUCON7に参加して予選突破しませんでした。 – そろそろちゃんとやります 今回のお題の一つ目の壁は、いかに画像ファイル（アバターアイコン）をキャッシュさせてサーバーからデータを返さないようにするかでした。 8時間の大部分をこの対応に費やしましたが解決は出来ませんでした。 原因はきっちり304を返すための基礎知識が足りていなかったことです。 ですのでこれを機に勉強しなおしてみました。 304 (Not Modified) 大前提ですが、304ステータスコードは キャッシュの有効無効の確認付きリクエストに対して、有効である場合に返すステータスコード です。 この場合サーバーはリソースデータ(ペイロード)を送信しません。 すなわち，サーバは、［
こんにちは、EC 事業部のフロントエンド・エンジニアのおいちゃん（@inouetakuya）です。先日、社内で Redis の障害を想定した避難訓練を行ったので紹介します。 背景 カラーミーショップ では、以前は Redis を利用していていましたが、ここ一年の間に用途が変わってきました。つまり、以前はコンテンツのキャッシュやセッションの保存先だったものが、いまでは非同期処理のためのキューとして使われるようになり、かつその処理には決済に関わるものも含まれています。 つまり Redis にダウンタイムが発生すれば、それがそのままビジネス面でのダメージに直結します。そこで Redis の自動フェイルオーバーを実現するため、インフラチームとともに Redis Sentinel の導入を進めてきました。 解決したい課題 Redis Sentinel を扱うのははじめてだったので、当初は「本当に自動
この記事はリクルートライフスタイル Advent Calendar 2016の10日目の記事です。 DEPRECATED! [2020/12/05追記] この記事内のコマンドは現在のバージョンの挙動と一部異なっていたり、説明に不正確な部分があります。 例えば公式のチュートリアルなど、信頼できる情報を参照ください。 https://kubernetes.io/ja/docs/tutorials/kubernetes-basics/ 2019/05/30追記 下記内容は若干の不正確を含みますので、軽く読み流して雰囲気を掴んでいただいたあとは https://qiita.com/Kta-M/items/ce475c0063d3d3f36d5d などご参照いただくとよいかと思います。 こんばんは 「sshするときの-p 443ってなんの数字ですか？」ぐらいの素人がインフラ周りを担当し8ヶ月、kub
インフラエンジニアの多分、華形のお仕事の１つであるミドルウェアの性能検証を久々にガッツリやる機会がありましたので、検証作業の基本的な項目について初心から振り返っておきたいと思います。読みやすさ度外視の詰め込み記事注意警報です。 世の中、雑な検証結果もちょいちょい散乱していて、私自身もそうならないよう注意を払っているわけですが、ガチでやると気をつける項目が多くて、自分で忘れたりしないようにと、誰かにやってもらいたい時に基本を抑えてから取り掛かってもらうために、形にして残しておこうと思った次第であります。 目次 なぜ性能検証をするのか 環境の準備 インスタンスの用意 クライアントの用意 サーバーの用意 ボトルネックになりうる項目CPU Utilization MemoryNetworkBandwidth DiskBandwidth Disk IOPS Disk Latency Disk
1年を通してKubernetes で解決したこと新たに出てきた課題をどう立ち向かったを発表しました at JulyTech Festa 2017
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
