Elasticsearch on EC2からAmazon Elasticsearch Serviceに 移行してだいぶ楽になった話
![Elasticsearch on EC2からAmazon Elasticsearch Serviceに 移行してだいぶ楽になった話](https://cdn-ak-scissors.b.st-hatena.com/image/square/cec4e5f47d8067e92d9f9d63338947709eeedcc0/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F099c9c8cd85f4cca92c61ea001bb9928%2Fslide_0.jpg%3F6834270)
Elasticsearch on EC2からAmazon Elasticsearch Serviceに 移行してだいぶ楽になった話
概要: 原則として x + y は ::std::ops::Add(x, y) の構文糖衣であるが、型推論で特別扱いされる。 演算子の脱糖 演算子の脱糖は型推論の後、HIRからMIRへの変換のタイミングで行われる。原則として x + y は ::std::ops::Add(x, y) の構文糖衣である。これは *x/x[i] 以外の他の演算子についても同様である。しかし型推論では以下のような特殊扱いがある。 fn main() { use std::ops::Add; let x : i8 = 1 + 1; // OK let x : i8 = Add::add(1, 1); // Error } 下側のコードがエラーになる理由 Rustの演算子はオーバーロード可能であり、型の制約が少ない。具体的には「左辺と右辺の型から、計算結果の型が一意に決まる」ということだけが要請される。そのため型
Cloud Functions for Firebase(以下Cloud Functions)は、Firebase Databaseへの書き込みやHTTPSリクエストなどのイベントをトリガーにして、任意の処理を追加できるサービスです。 例えば Firebase Storageに画像が保存された時にサムネイル画像も生成して保存する Firebase Databaseにレコードが追加された時にPush Notificationを送る HTTPSリクエストのパラメータで渡したURLを短縮URLにして返す といった具合に、様々な処理をJavascriptコードで記述できます。 他にどんなことができるかは、公式のfunctions-samplesにまとまっています。 今回、仕事でCloud Functionsを使って自分にPush Notificationを送るデバッグメニューを作りました。Prod
Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか?プロセッサーがどのくらい忙しいか?違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが
HTTP Guides Resources and URIs Identifying resources on the Web Data URLs Introduction to MIME types Common MIME types Choosing between www and non-www URLs HTTP guide Basics of HTTP Overview of HTTP Evolution of HTTP HTTP Messages A typical HTTP session Connection management in HTTP/1.x Protocol upgrade mechanism HTTP security Content Security Policy (CSP) HTTP Strict Transport Security (HSTS) X-
JSONデータ圧縮方式をzstdに切り替えデータ量を38.3%削減した事例、及びマイクロサービスの無停止アップデート事例について紹介したいと思います。 はじめに JPRゲーム事業本部開発基盤部の池田周平です。先日 Rails5対応についてDeNA techブログに投稿 した@namusyakaと同じチームで働いています。 JSON文字列をRDBに格納する際の圧縮フォーマットをSnappyからzstdに切り替え、データ量を削減した事例を紹介したいと思います。本対応を実施した目的はDB負荷対策です。DBで扱うデータをより小さくすることで、DBサーバのDiskI/O負荷とMaster-Slave間のレプリケーション遅延対策を目的としています。 「Sakasho」は、DeNAが持つモバイルゲームのためのプラットフォームです。複数タイトルのゲームを取り扱っており、一部データはゲーム毎の仕様差を吸収し
はじめに 脆弱性対応のためのアップデート作業というものは頻繁に発生するものですが、本番運用しているシステムではサービスへの影響を最小限にしたいものです。 アップデートした後、出来ることなら必要なプロセスだけリスタートさせることで済ませたいのですが、どのプロセスをリスタートすれば良いのか、そもそもOS再起動しないと反映されないものなのか、判断が付かない場合が少なくありません。 そのような場合のため、再起動が必要なプロセスを見つけたり、OS再起動が必要かどうかアドバイスしてくれるコマンドがあります。 Redhat系 「yum-utils」パッケージに入っている「needs-restarting」コマンドを使います。 # needs-restarting -h Usage: needs-restarting: Report a list of process ids of programs th
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く