unbound の prefetch 動作が複雑で難しい - 試行錯誤のおと
DNS による名前解決のオーバヘッドを解決するために DNS キャッシュサーバを導入しても、その上流や権威サーバに対して問合せが頻繁にある場合、応答の遅延が発生する状況があります。 DNS による名前解決がボトルネックとなっている環境のチューニングについて考えるとき、キャッシュサーバのキャッシュにあるレコードの TTL が切れる前にキャッシュサーバが自動的にレコードを更新してくれる機能があれば解決しそうです。 多くのプロバイダでフルリゾルバとして導入されている unbound には prefetch の機能があります。 prefetch という名前からして、キャッシュにあるレコードの TTL が切れる前に unbound 自ら自動的にレコードを更新してくれそうです。 prefetch: <yes or no> (1.4.2-) yesのときには、キャッシュを最新に保つために期限切れにする前
Conky で Github Grass Graph を rsvg で描画する - 試行錯誤のおと
Linux Desktop を使っていない人や興味のない人にはほとんど旨味のない記事です。 毎日コードを書こうと思っていても、モチベーションを維持するのは難しいことが多いなと最近思ってる。 Github の Grass Graph を必然的に見るようにしたかったので、 conky に表示させてみた。 簡単に書くとシェルスクリプトと imlib で画像表示するだけで終わる。 Github の Grass Graph を取得して png に変換するスクリプト #!/bin/sh set -eu ID="kizkoh" curl https://github.com/${ID} | awk '/<svg.+class="js-calendar-graph-svg"/,/svg>/' > grass.svg convert grass.svg grass.png .conkyrc のサンプル ow
私的 CloudFormation ベストプラクティス - 試行錯誤のおと
最近 CloudFormation を触っていて、よくある初期構築のベストプラクティスについて意見がほしいので自分の考える CloudFormation の設計や使い方についての考えを書いた。 CloudFormation のメリット CloudFormation を利用するためメリットはリソースの参照を簡単に記述できることと、べき等性の保証だと思っている。 以前、 EC2 インスタンスのプロビジョニングを Ansible で書いたことがある。 べき等性を確保したく、 サブネットの作成、 EBS のマウント、アンマウント、 EIP の付け替えなどの変更操作を Ansible だけで操作したい + その後のプロビジョニングの操作も Ansible にお任せしたいということを考えたときに、 Ansible の YAML ではなく以下のような Python のコードを書いた。 # ansible
株式会社はてなにジョインしました！ - 試行錯誤のおと
1 月末付けで前職を退職し、 2 月から株式会社はてなで Web オペレーションエンジニアとして働いています。 転職の理由 前職も今と同じようにインフラレイヤの設計、構築、運用を担当していて、業務でやりたいことや技術的に取り組みたいことは自由にやらせてもらっていたり、上司や周りにいる方々も高い技術力を持っていて、かつ運用に対する改善等の考え方も技術的に前向きで働きやすく、特に大きな不満があったわけではありません。 一方で昨年の秋には新卒で入社して 3 年弱が経過しようとしていて、自身のキャリアについて振り返ると転職を考え始める時期かと考え始めていました。 前職は 1 社目ということもあり構築するサービスの内容やそれに応じて要求されているシステム構成の考え方、開発のスピード感、新しい技術に対するモチベーションが鈍ってしまうことが怖いという思いや、自社以外のそれらの様子をまだエンジニアとして若
ISUCON6 本戦の Server-Sent Events を Rust で! - 試行錯誤のおと
この記事は Rust Advent Calendar 2016 - Qiita の 20 日目の記事です。(3 日ぐらい遅れてしまいました。スミマセン><) ISUCON6 本戦 Rust 実装 さて、以前に ISUCON6 で優勝したことを記事に書いたのですが、自分はメンバの中で実装が遅い & プログラミングよりインフラの方が得意ということで実際の競技では肝心のコードは触ってないです。 kizkoh.hatenablog.com そこで、今回は復習と早くも来年の ISUCON7 (未定) に備え、練習も兼ねてアプリのチューニングに挑戦することにしました。 Go でチューニングに挑戦してもよかったのですが、今回は Rust Advent Calendar 2016 のネタと Rust でチューニングしていくためのスタートラインとして、 Rust 実装を用意することにしました。 リポジトリは
ISUCON6 にインフラエンジニアとして参加して優勝した!! - 試行錯誤のおと
ISUCON6 にインフラエンジニアとして参加して優勝してきたので、なにやったかとか感想とか書いてく。 (僕はアプリを触っていない。アプリの話は他の人が書いてくれるはず。) ※ @methane さんが会社ブログに投稿されたので記事を更新 dsas.blog.klab.org 会社で出場してチーム名は「この技術部には問題がある!」、メンバは @methane @mecha_g3 さんと僕。 ちなみに @methane さんと @mecha_g3 さんは兄弟だけど、僕だけ他人です(笑)。 チームメンバ役割 本戦に向けて、会社でチーム練習してたので本戦の役割もできてた。 @methane さんが全体の構成を見てチーム全体をまとめる役割、 @mecha_g3 さんがアプリ、 僕がインフラの役割。@methane さんが戦略をたてて、各自自分で改善できるところは改善してく感じで進めることができた。
Hatena Engineer Seminar #6 〜インフラ編〜 @ Tokyo に参加してきました - 試行錯誤のおと
(最初文で書いてたけど、読みづらかったのでメモに置き換えた〜) 個人的には勉強会に参加したらやっぱり、記事を書くべきだと思ってる。 参加したくても様々な事情で参加できなかった人のためになるし、感想を書くと発表された側、発表を聞いた側のモチベーションにもなると考えてる! 内容と感想 hatena.connpass.com LT も面白かったけど、メモなしで聞く方を重視したので記事で触れるのは通常のトーク 3 つ。 id: wtatsuru さん: はてなのログ運用のこれまでとこれから 前提となるシステム構成 Reverse Proxy -> Application Server -> DB ログの種類 アクセスログ、エラーログ: Reverse Proxy が書き出し アプリケーションログ: Application Server が書き出し ほとんどのサービスで同じような構成をとっているので
Kyoto.なんか #2 で Rust の実践的な話について発表してきました - 試行錯誤のおと
タイムラインをみていると流れてきたので、なんか会社休みだし、なんか実家にいるので Kyoto.なんか #2 で インフラエンジニアのための Rust というタイトルで発表してきた。 atnd.org 今回、発表で話しきれなかったことやうまくいかなかったことを、ブログ記事に発表内容をまとめた。 ※ 発表資料はあとでリンク貼ります。 モチベーション 趣味で Rust を書いていて、 Rust に対するモチベーションをあげたかった話。 Rust というと一般にシステムプログラミング言語で、変数や式の所有権を付与することで安全性や高速性が謳われている。 Hacker News や Reddit を眺めているとほぼ毎日のように Rust の話があって、みんな OS や DNS サーバを実装したり、知見を共有し合っていて楽しそうだなあと思っていた。 趣味のプロダクトだけではなくて、エンタープライズでも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
