goroutineはなぜ軽量なのか - Carpe Diem
概要 以前の記事で christina04.hatenablog.com Goはスレッドよりはるかに軽量なgoroutineでC10K問題を解決する、という話をしましたが、goroutineが軽量なのはなぜか？という理由を深掘りしたことがなかったのでしてみました。 環境 golang 1.11.1 Darwin 17.7.0 軽量と呼ばれる理由は２つ 大きく分けると以下の２つのポイントがあります スレッドに比べてメモリ使用量が低い スイッチングコストが低い それぞれ説明していきます。 goroutineがスレッドに比べてメモリ使用量が低いのはなぜか スタックとヒープのメモリの使い方を理解すると分かります。 ヒープはメモリの下層、プログラムコードのすぐ上にあり、上に向かって成長します。一方スタックは仮想アドレス空間の一番上にあり、徐々に下に成長していきます。 ref: イベントループなしでの
Golangの良いところ - Carpe Diem
概要 Goの良いところってなんだろう？と思ってまとめます。 多分新しいことを知ったら追記していきます。 よく言われるところ コンパイルが速い JavaやC++に比べてかなり高速です。 メモリ安全 GoはC言語に近いですが、C言語で問題になっていたメモリ周りは言語側でちゃんとカバーして使う側が意識する必要がなくなってます。 型安全性 LL言語に比べれば。 標準ライブラリの充実 外部ライブラリを使わずとも標準ライブラリでほぼ何でもできます。 学習コストが低く、可読性が高い 言語の仕様がシンプルなので、他の言語に比べてすぐに一通り理解できます。 gofmt 先程の可読性に関連しますが、フォーマッターがデフォルトで付いているので読みやすくなります。 タブかスペースかといった宗教論争をせずに済みます。 標準ツールの充実 pprofでプロファイリング race detectorでgoroutineによ
GoのSliceを関数の引数に渡した時の挙動 - Carpe Diem
概要 Sliceの構造を始め、関数で呼び出した場合の挙動やappendなどsliceを操作した場合どうなるかをまとめました。 環境 golang v1.9.0 Sliceの構造 Sliceは以下のような３つの要素でなりたっています。 配列へのポインタ length capacity 図示すると以下です。 ref: Go Slices: usage and internals - go.dev 関数の引数として渡した時 Goの関数の引数は基本的に値渡しです。これはsliceも同じです。なので渡した変数のポインタは異なります。 func main() { s := []int{1, 2, 3} fmt.Printf("%p\n", &s) // 0x1040a0b0 someFunc(s) } func someFunc(s []int) { fmt.Printf("%p\n", &s) //
ECSのオートスケール戦略 - Carpe Diem
概要 ECSはコンテナのスケールアウトとインスタンスのスケールアウトのタイミングが重要です。 よく起きる問題としては インスタンスのスケールアウトが遅くてコンテナのスケールアウトも遅くなってしまう しきい値が不適切でインスタンスがスケールアウトせず、コンテナがスケールアウトしたくてもできない で、こういった事が起きないようにしないといけません。 スケールアウトの方針 対象 方針 インスタンス インスタンスの空きリソースがコンテナ１台分だけの状態がｎ分間続いたら コンテナ コンテナの使用率がｎ%を超えたら インスタンスはもう１台もコンテナを追加するリソースがない状況になったら早めにスケールアウトします。 コンテナは一般的なやり方で使用率が高くなったらスケールアウトすればOKです。 スケールインの方針 対象 方針 インスタンス コンテナがｎ分間ずっと１台を下回ったら コンテナ コンテナの使用率
Angularで中身を動的に変えられるModalを作る【基本編】 - Carpe Diem
概要 確認用ダイアログなど、モーダルが必要になるシーンは多々あると思います。 今回はAngular2で実装する方法を紹介します。 環境 angular 2.4.7 angular-cli 1.0.0-beta.32.3 要件 今回満たしているのは以下の項目です。 serviceとしてどこからでも呼べる 中身を好きなcomponentで作ることができる また今回満たしていない要件は以下です。これは次回にやり方を紹介します。 モーダルの中に外から（呼び出しているComponentなどから）何かしらパラメータを渡す 成果物 今回の成果物は以下です。 github.com ブログの説明でよく分からない時は参考にしてください。 フォルダ構造 ├── app.component.css ├── app.component.html ├── app.component.spec.ts ├── app.c
AngularでAsync pipeを使う - Carpe Diem
概要 AngularのPipeの中にはAync PipeというPromiseやObservableな非同期オブジェクトをそのままtemplateで表示できるPipeがあります。 今回はその使い方を紹介します。 環境 angular 2.4.8 rxjs 5.2.0 async pipeのメリット 主なメリットは以下の２つです。 template側に役割を任せられるのでコードがスッキリする コンポーネントが破棄される時に自動でunsubscribeするのでメモリリークを防げる フロントではメモリ管理が大切なので、特に後者は嬉しいメリットですね。 基本的な使い方 @Component({ selector: 'async-pipe', template: '<div>Time: {{ date | async }}</div>' }) export class AsyncPipeCompone
CloudFrontのキャッシュでハマった話 - Carpe Diem
概要 ブラウザのキャッシュ - Carpe Diem を検証している時に期待した挙動をしなくてハマったので、CloudFrontのキャッシュの動作と注意点をまとめます。 CloudFrontのキャッシュ動作 レスポンスヘッダのx-cacheを見ると以下の３つに区別できます。 x-cache CloudFrontのキャッシュ Originへのリクエスト Originのレスポンス Miss from cloudfront なし or あるがTTL切れでOriginに更新あり あり 200でリソース返す Hit from cloudfront あり なし なし RefreshHit from cloudfront あるがTTL切れ あり 304でリソースは返さない この中で注意なのはRefreshHit from cloudfrontです 注意点 RefreshHitはヘッダーを更新しない Or
B TreeとB+ Treeの違い - Carpe Diem
概要 インデックスに対してMongoDBはB Treeを採用し、MySQLのInnoDBはB+ Treeを採用しています。 どうして採用しているアルゴリズムが違うのだろう？と思って調べてみました。 主な違い B+ TreeはほとんどB Treeと同じですが、以下の点が異なります。 リーフノードとリーフノードを結ぶポインタがある データはリーフノードのみに保持する 具体例 言葉だけだと分かりにくいので、Visualizeするツールを使って具体例を表示します。 [1, 2, 3, 4, 5, 6, 8, 10, 15, 18]という数列に対し、Order: 3で作ってみます。 Orderは１ノードから出る枝の数のことです。 B Tree B-Tree Visualization B+ Tree B+ Tree Visualization 先程のB Treeと違って、データはリーフノードに持つの
docker-compose で Kibana 5.x を使う - Carpe Diem
概要 Kibanaを5.xにメジャーアップデートする際、Elastic社公式のdocker imageも用意されたのでdocker-composeでまとめて作ることにしました。 その際調べたこと、ハマったことをまとめます。 環境 docker 17.03.1-ce docker-compose 1.11.2 Elasticsearch 5.3.0 Kibana 5.3.0 docker-compose.yml まずは全体のソースを貼ります。 後ほどポイントを説明します。 version: '2.1' services: elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:5.3.0 container_name: elasticsearch environment: - cluster.name=dev-k
Dockerでのdev, stg, prd環境分け - Carpe Diem
概要 dockerを扱う上で、dev, stg, prdの環境で動かす際の分け方について考えてみました。 環境 docker 1.13.1 docker-compose 1.11.1 主な分け方 思いつくのは以下の５つです。 imageを分ける 全環境のconfigファイルをimageに保持させ、RUN時に指定 templateを埋め込んでおいて、envsubstで環境変数使って書き換える data volumeでconfigをマウントして使用する 環境変数で設定できるように実装し、envを指定する a. imageを分ける まず思いつくのはimageを分ける方法です。 ベースとなるdockerfileをそれぞれ用意してFROMでimageの基礎にし、環境分けのためのconfigの部分を各dockerfileに書く感じです。 メリット 分かりやすい デメリット Dockerの同一性・携帯性
Elasticsearchの前方一致について考える - Carpe Diem
概要 以前Prefix Query の注意 - Carpe Diemで述べたように、PrefixQueryはsearch queryがnot_analyzedになるので意図しない結果になることがあります。 一方で前方一致は検索の利便性を向上させる上でメリットが大きいので、入れておきたい要素でもあります。 今回は前方一致を考える上で何が良いかを調べてみました。 環境 Elasticsearch 5.2.1 Prefix Query メリット 文字通り前方一致のクエリであることが分かる デメリット search analyzerは指定できないので、index時にnormalizeで小文字などにしてしまうと、大文字による検索でヒットしない 内部的にはregexpによる一致なので短いと重い 特に後者は短い文字でも表示する場合だと非常に無駄が多く、 ref:Elasticsearch Queries
Angular2でComponentをまたがったデータのやり取り - Carpe Diem
概要 Angular2でComponent間でデータをやり取りしたい状況が出てくると思います。 例えば「このボタンを押したら外部APIを叩いて状態を更新したい。その状態を他のComponentでも使っているので更新を反映したい」ときなどです。 今回はServiceにデータを保持して、それを各コンポーネントで利用するやり方を紹介します。 環境 angular-cli 1.0.0-beta.25.5 Angular 2.4.3 完成形 今回の成果物はこちら github.com フォルダツリーは以下です。 ├── app.component.css ├── app.component.html ├── app.component.spec.ts ├── app.component.ts ├── app.module.ts ├── child │ ├── child.component.cs
MongoRiverを使う - Carpe Diem
概要 MongoDBのデータをElasticSearchに流し込むMongoDB River Pluginを扱います。 あるデータに対して検索機能を追加したいけど、MongoDBで全文検索はちょっと。。という時に便利です。 環境 Ubuntu 14.04 MongoDB 2.6.7 Java 1.8.0_31 ElasticSearch 1.4.2 MongoRiverPlugin 2.0.5 MapperAttachmentsPlugin 2.4.2 MongoDBとElasticSearchを別環境で立ち上げて説明します。 サービス IP MongoDB 192.168.33.10 ElasticSearch 192.168.33.11 注意点 前提知識や、うまく動作しないケースを先にまとめてみました。 これを知ってるだけで随分進めやすくなると思います。 MongoDBのレプリのopl
Goでのstreamの扱い方を学ぶ - Carpe Diem
概要 結論から言うと、Streamで扱っているものはStreamのまま扱うです。 具体的にはio.Readerを毎回ioutil.ReadAllで[]byteに変換せずにそのまま使いましょうです。 なぜStreamを使うべきか Node.jsの例ですが、こちらで非常に分かりやすく説明されています。 yosuke-furukawa.hatenablog.com それを踏まえて考えてみると、Goの場合以下の２つが大きいと思います。 1. メモリの効率化 ioutil.ReadAllなどで一旦全て[]byteに変換すると、その分メモリを消費しますし、アロケーションやGCに依る速度低下が起きます。 一方io.Readerやio.Writerは各chunkの処理に同じバイトを使いまわすので、メモリの効率が良いです。 2. 標準パッケージの多くがio.Readerをサポートしてる io.Reader、
負荷が低いのにアクセスを捌けきれない時の対応 - Carpe Diem
概要 MongoDBでCPU使用率やロードアベレージが高くないのに処理が詰まっている現象が起きました。 その時間にbatchが動いていてアクセスが急に増えることが原因と言うのは分かっているのですが、負荷的には十分余裕があり不思議な状態でした。 そこでdstatで見るポイント - Carpe Diemでも述べたように、負荷の状態から判断する基準があります。 ロードアベレージを確認する １が高ければCPU、ディスクI/O、メモリにボトルネックがある １が低ければTCPコネクションにボトルネックがある 今回の現象から判断するに、TCPコネクションに原因がありそうです。 原因調査 Too many open filesは出ているか ファイルディスクリプタが足りない場合はコネクション数が足りずに処理が詰まってしまいます。 そしてその場合Too many open filesというエラーが出ます。 し
ldflagsを使おうとしてハマったこと - Carpe Diem
概要 golangではbuild時にldflagsというオプションをつけると、変数に値を埋め込んだ状態でバイナリを生成することができます。 よく使われるのはビルド時のgitのcommitのハッシュを埋め込んで、そのバイナリがどのcommitで作成されたのかを明らかにして「想定したバージョンでビルドができているか」や「複数のサーバ間で同じバージョンを使用できているか」などをチェックしたりします。 今回はそのldflagsを使う上でハマったことを書きます。 環境 go 1.7.4 ハマったこと go 1.5から書き方が変わった 以前はスペースで区切って go build -ldflags "-X パッケージ名.変数 値" でしたが、今は＝を使って go build -ldflags "-X パッケージ名.変数=値" となります。 複数埋め込みたい場合は go build -ldflags "-
ECSでコンテナのrolling update - Carpe Diem
概要 ECS上のコンテナをダウンタイム０で更新（デプロイ）する方法をまとめます。 環境 ALB ECS container agent 1.13.0 Docker 1.11.2 Amazon ECS Container Agent Versions - Amazon EC2 Container Service ポイント minimumHealthyPercentとmaximumPercentを適切に設定する connection drainingを適切な長さにする この２つを意識していればOKです。 minimumHealthyPercentとmaximumPercentを適切に設定する desiredCount: 4、min: 0%、max: 100%の場合 この場合最低０つ(0%)まで縮小し、最高でも４つ(100%)までしか増えない状態で更新するということになります。 つまりダウンタイ
remote_addrとかx-forwarded-forとかx-real-ipとか - Carpe Diem
背景 ECSでNginxのコンテナをプロキシとして立てたところ、APIサーバのアクセスログのクライアントIPがNginxのコンテナIPになっていたのでその修正をしたのがきっかけです。 環境 Nginx 1.10.2 Docker1.12.1 構成 Client -> ELB -> Nginx -> API という構成とします。 ネットでよく見る情報 set_real_ip_from 172.31.0.0/16; real_ip_header X-Forwarded-For; を追加する、とか proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; を追加する、とかどれがどれだか分かりにくいので１つ１つ説明していきます。 用語説明 remote_
dockerのlog周りの対応 - Carpe Diem
概要 dockerを本番運用する際にログの扱いに悩んだので情報をまとめてみました。 環境 docker v1.12.1 コンテナのログは何処に渡すべきか 主に以下の３通りになると思います。 コンテナ内に保存 volume先に指定してに永続保存 log driverを使って転送 a. コンテナ内に保存 何も設定しないとコンテナに保持されます。 メリット 何も設定しなくていい デメリット 当然コンテナが破棄された場合はログファイルがなくなります。 b. volume先に指定してに永続保存 volumeを用いてホストに永続的に保存します。 参照が切れないように-v <host_path>:<container_path>とするか、--volumes-from <container_name>でデータ用コンテナに保持してください。 メリット コンテナを破棄したとしてもvolumeでそこを指定すれば
TerraformでECS環境の構築【オートスケール編】 - Carpe Diem
概要 TerraformでECS環境の構築 - Carpe Diemでは書いてなかったオートスケールについてです。 terraform 0.7からServiceでのオートスケールにも対応したので、それを使って構築します。 環境 Ubuntu 14.04 Terraform 0.7.3 実装 完成形はこちら github.com Autoscale用のIAMの追加 Amazon ECS サービスの Auto Scaling IAM Role - Amazon EC2 Container Serviceを参考に用意します。 まずはJSONでPolicyの用意 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "application-autoscaling.amazo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
