タグ

ブックマーク / blog.a-know.me (20)

  • 読書メモ・詳解システムパフォーマンス 第4章/可観測性ツール - えいのうにっき

    「詳解システムパフォーマンス」の読書メモシリーズ・第3弾。 詳解システムパフォーマンスを読んでいる話・2章/メソドロジ 読書メモ - えいのうにっき 読書メモ・詳解システムパフォーマンス 第3章/オペレーティングシステム - えいのうにっき 詳解 システム・パフォーマンス 作者: Brendan Gregg,西脇靖紘,長尾高弘出版社/メーカー: オライリージャパン発売日: 2017/02/22メディア: 単行(ソフトカバー)この商品を含むブログ (1件) を見る この回はなんだっかの理由で輪読会に参加できなかったので、前回のような「輪読会の場での話題」みたいなのはなし。スミマセン。 感想 僕自身が システムエンジニア -> PaaS(GAE)エンジニア -> Web アプリケーションエンジニア -> セールスエンジニア(イマココ) 、というキャリアを踏んできたこともあってか、「システムが

    読書メモ・詳解システムパフォーマンス 第4章/可観測性ツール - えいのうにっき
  • Dockerfile の代わりに Packer を使って Docker に再々入門してみている - えいのうにっき

    最近また、Docker に入門しなおしている。今回で3回目。Docker for Mac がずいぶん良いらしいので、DockerRails アプリを動かしてみた - えいのうにっき が前回入門したときの記事。 blog.a-know.me さすがに3回目ともなると「あぁー!はいはい、そうでしたそうでした!」ということも多くて、まぁこれはこれでアリか、と思い直してみたりもしている。 今回の入門にあたっては、「プログラマのためのDocker教科書 インフラの基礎知識&コードによる環境構築の自動化」というを使っている。Docker・コンテナのことのみに留まらず、コンテナを扱うに際しておさえておきたいインフラ・ネットワークについての話などについても触れられていて、まだ読んでる途中ではあるのだけどなかなかいい感じ。 プログラマのためのDocker教科書 インフラの基礎知識&コードによる環境構

    Dockerfile の代わりに Packer を使って Docker に再々入門してみている - えいのうにっき
  • AWS CloudFormation への入門に「Amazon Web Services 基礎からのネットワーク&サーバー構築」を使ってみた - えいのうにっき

    AWS CloudFormation とは、EC2 や VPC といった AWS のクラウドリソースの構成をコード化し、その内容に従って作成、管理、更新を自動で行うための仕組み。もうタイトルの通りなんだけど、今回その CloudFormation への入門のための教材として「Amazon Web Services 基礎からのネットワーク&サーバー構築」を使ってみて、結果的にめちゃめちゃ良かったのでその感謝の気持ちをこのエントリに書きなぐっておく。 Amazon Web Services 基礎からのネットワーク&サーバー構築 作者: 玉川憲,片山暁雄,今井雄太出版社/メーカー: 日経BP社発売日: 2014/07/16メディア: 単行この商品を含むブログ (4件) を見る 経緯 年始に立てた今年の目標として「AWSへのロックイン宣言」を高らかに叫んだのだけど、これ、ちゃんと年始から着々と進

    AWS CloudFormation への入門に「Amazon Web Services 基礎からのネットワーク&サーバー構築」を使ってみた - えいのうにっき
  • Mackerel でみる Linux システムメトリック項目の見方・考え方 - えいのうにっき

    Mackerel について考えない日はないというくらいに Mackerel・Love な僕なわけですが(考えない日はあります)、Mackerel の Web 画面で日頃なにげなく見ている「システムメトリック」、みなさんはどのような意識を持って観察していますでしょうか。 ↑ https://home.a-know.me をホストしているサーバのシステムメトリックのようす。 ここでひとつおさらいをしておくと、「システムメトリック」とは、監視対象のサーバにインストールされた mackerel-agent が、それ単体で収集・投稿するメトリックのことです。一般的な Linux系OS に mackerel-agent をインストールした場合、以下のような項目がシステムメトリックとして Mackerel に投稿されます。 loadavg5 cpu memory disk interface files

    Mackerel でみる Linux システムメトリック項目の見方・考え方 - えいのうにっき
  • 「障害発生時に即座に収集したいサーバの状態・14項目」を実際に収集してみた - えいのうにっき

    僕はインフラエンジニアではないし、そうだったこともないのだけど、いま「インフラエンジニアの教科書2」というを読んでいる。 インフラエンジニアの教科書2 スキルアップに効く技術と知識 作者: 佐野裕出版社/メーカー: シーアンドアール研究所発売日: 2016/08/26メディア: Kindle版この商品を含むブログを見る Twitter かなにかでこのの存在を知り、とりあえず買ってみたものの、しばらくの間積読状態になってしまっていた。...のだけど、最近になってようやくちまちまと読んでいる。関係ないけど、kindleで読めるのはほんとに便利だ。 このの7章「障害対策と障害対応」で、『以下のような項目についてはサーバ障害時に即座に(20秒程度で!)収集できるべき』、とされていた。 メモリの搭載量と使用量 パーティションごとのディスクの使用率と空き容量 CPUの種類とコア数 ディスクのRA

    「障害発生時に即座に収集したいサーバの状態・14項目」を実際に収集してみた - えいのうにっき
  • パイプとソケットでのプロセス間通信を Ruby で再確認した - えいのうにっき

    前回までの続き。 Unixプロセスとリソースの基礎を再確認した - えいのうにっき プロセスとの情報のやりとりについて再確認した - えいのうにっき プロセスの適切な扱い方を再確認した - えいのうにっき Unixプロセスとシグナルの基礎をRubyで再確認した - えいのうにっき 今回は、「パイプ」と「ソケット」を使った複数のプロセス間で情報をやりとりする方法について。「プロセス間通信」(IPC : Inter Process Communication)と呼ばれる分野の話。 パイプを用いたプロセス間での情報のやりとり 「ストリーム」と「メッセージ」、そして「ソケット」 読んでいるのは なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 - 達人出版会 。 tatsu-zine.com パイプを用いたプロセス間での情報のやりとり プロセス間での情報のやりとりを行うための方法のひとつ

    パイプとソケットでのプロセス間通信を Ruby で再確認した - えいのうにっき
  • デーモンプロセスの作り方を通じて色々なことを再確認した - えいのうにっき

    続き。今回はデーモンプロセスについて。 Unixプロセスとリソースの基礎を再確認した - えいのうにっき プロセスとの情報のやりとりについて再確認した - えいのうにっき プロセスの適切な扱い方を再確認した - えいのうにっき Unixプロセスとシグナルの基礎をRubyで再確認した - えいのうにっき パイプとソケットでのプロセス間通信を Ruby で再確認した - えいのうにっき デーモンプロセスについて知るときに前提知識として外せないのが、「プロセスグループ」と「セッショングループ」というふたつの概念らしい。まずはそれについて再確認する。 プロセスグループとセッショングループ プロセスグループ 今までずっとプロセス単体について見てきていたけど、実はプロセスというものは、全てがいずれかの「プロセスグループ」というものに属している。各プロセスグループには、ユニークな整数のIDが振られている

    デーモンプロセスの作り方を通じて色々なことを再確認した - えいのうにっき
  • Unixプロセスとシグナルの基礎をRubyで再確認した - えいのうにっき

    前回までの続き。なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 - 達人出版会をまだ読んでいる。遅読。 Unixプロセスとリソースの基礎を再確認した - えいのうにっき プロセスとの情報のやりとりについて再確認した - えいのうにっき プロセスの適切な扱い方を再確認した - えいのうにっき 今回は、Unixプロセスとシグナルの基礎について再確認していく。 Unixシグナル・事始め Unixシグナルの「いろは」 シグナルを再定義する シグナルハンドリングの注意点 Unixシグナル・事始め 前回、子プロセスの終了を待ち受けるのに用いた Process.wait は、実行するとそこで自身(親プロセス)の処理を止めて子プロセスの終了を待った。これは ブロッキング呼び出し と呼ばれる。 では「親は親で何か別の仕事をしたいとき」はどうするかというと、これから見ていくシグナルを上手に使うと実

    Unixプロセスとシグナルの基礎をRubyで再確認した - えいのうにっき
  • プロセスとの情報のやりとりについて再確認した - えいのうにっき

    前回のつづき。なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 - 達人出版会という読書メモ。前回のが意外なほどに読まれていてビビっている。 今回はプロセスと情報をやりとりする方法についてまとめる。プロセスレベルでの情報のやりとり、について。 「プロセスとプロセスレベルでの情報をやりとりする方法」には、以下のような方法がある。 環境変数 引数 名前 終了コード これをひとつずつ見ていく。 環境変数 日頃よく使っている「環境変数」。キーとバリューが対になっている、プロセスで扱うことのできるデータを保持しているもの。 「プロセスで扱うことができる」とはどういうことか。 すべてのプロセスは自身が生成される際、親プロセスから環境変数を引き継ぐ。環境変数は親プロセスによって設定され、子プロセスに引き継がれる。 環境変数はプロセスごとに存在し、それぞれのプロセス内ではグローバルにアクセス

    プロセスとの情報のやりとりについて再確認した - えいのうにっき
  • プロセスの適切な扱い方を再確認した - えいのうにっき

    プロセスの基礎再確認シリーズもこれで3つめ。 Unixプロセスとリソースの基礎を再確認した - えいのうにっき プロセスとの情報のやりとりについて再確認した - えいのうにっき ここまで見てきた間でも、ターミナルから irb を起動したり、Ruby コードから system メソッドを呼び出したりすることで子プロセスを扱ってきた(結果的に)けれど、自らの手で意図して子プロセスを作り出す、ということはしてこなかった。 今回は、子プロセスのメリットやその作り方、扱い方を中心に再確認したもののメモ、という形になる。項目的には以下。 fork で子プロセスを作る fork が高速なワケ fork で作った子プロセスを待つ 子プロセスの面倒を見る fork で子プロセスを作る fork(2) システムコールを使うことで、実行中のプロセスから新しいプロセスを生成することができる。 生成されたプロセスは

    プロセスの適切な扱い方を再確認した - えいのうにっき
  • Unixプロセスとリソースの基礎を再確認した - えいのうにっき

    前置き 最近、「なるほどUnixプロセス ― Rubyで学ぶUnixの基礎」というを読んでいる。 tatsu-zine.com 僕の所属している会社・はてなでは「メンター制度」というものがある。はてなに所属する全てのエンジニアに、誰かしら(グレード的に自分より上となるエンジニア)をメンターとしてつける、という制度。メンターとメンティーは月に一度、1on1を実施する。 自分はセールスエンジニアという特殊な職種ではあるが、メンターとしてシスプラ(インフラ)部門のエンジニアの方に付いて頂くことになった。このことは僕にとって、とても有り難く、心強い。 というのも、入社から2ヶ月ちょっと、実際にセールスエンジニアとして業務を進めてみて、インフラ周りの基礎知識・ローレイヤーに関しての基礎知識が強く求められるなぁと...、、というか、それを知っているといないとでは、問題や課題についての理解の仕方も違っ

    Unixプロセスとリソースの基礎を再確認した - えいのうにっき
  • rsyslogd と journald の違い・住み分け - えいのうにっき

    最近、ちょっと基礎から見直し中なんだけど。 基礎からやり直す pic.twitter.com/klggTNCben— いのうえ (@a_know) 2016年3月13日 ↑のようなを読みつつ、よくわかんないところは以外でも調べてみて、それでもわかんないところは社内の Qiita:Team に雑に書いてみたり、会社の知ってそうな人(インフラエンジニアさんとか)に聞いてみたりとかしてる。すんごい初歩的な質問をしてもみんな全力で教えてくれるから、もうまじイケメン。 で、今回タイトルの内容についてスッキリしたので、Qiita:Team だけじゃなく、このブログにも書いてみる。 rsyslogd と journald の違い・住み分け このページにある図がわかりやすいっすよ、と、↓の画像を見せてくれた。 コラム - クラウド時代のオープンソース実践活用 | 第56回 RHEL7/CentOS7の

    rsyslogd と journald の違い・住み分け - えいのうにっき
  • Scala + Play framework を始めてみました - えいのうにっき

    突如思い立ったので。こういう新しい言語とかに手を付けるの、思い立ったが吉日っぽいとこあるし。 今回確認したものの各種バージョン↓ Java 1.8.0_74 Scala 2.11.7 typesafe-activator 0.13.8 Play 2.5.0 まずは下調べ まずは Scala について下調べ。僕は普段 Ruby を使っていて、rbenv で便利にバージョン切り替えを行えているので、Scala でも似たようなことをしておいたほうがいいのかな、と。 で、少し調べてみた結果、「そもそもバージョン切り替えをする必要があるかどうかを考えよう」みたいなお言葉を拝見。んーまぁ、今のところは趣味の域だしなぁ、とは思いつつ、そんなに面倒でないならやっておくか、という結論に。 svm のインストール なので、まずは svm とやらのインストール。Ruby でいうところの rbenv みたいなもの

    Scala + Play framework を始めてみました - えいのうにっき
  • BigQuery 上のテーブルを検索するときに頭の片隅に置いておきたい、課金絡みのこと - えいのうにっき

    ぼくが所属している会社のプロダクトチームでは、毎週ふりかえり(KPT)を実施しているのだけど、そのときに「BigQuery に Rails のログを送り始めて、ログの検索をしやすくなって嬉しいは嬉しいのだけど、検索をかけるたびに課金されている実感があって、ヒヤヒヤしている」と、同僚から不安の声があがった。 まぁたしかに、このはなし↓も、まだ記憶に新しい。w qiita.com その不安を払拭(というか、正しく怖がりたいな、というきもち)すべく、BigQuery の query pricing を見返してたら、以前確認したときには見覚えのない記述があったりしたので、改めて一記事としてまとめてみる試み。 ここに書いていることは、2016-02-22 時点での内容です。あしからず。 BigQuery 上のテーブルを検索するときに頭の片隅に置いておきたい、課金絡みのこと $5 / TB ごどるぱー

    BigQuery 上のテーブルを検索するときに頭の片隅に置いておきたい、課金絡みのこと - えいのうにっき
  • いまさらだけど、Nginx が出力したアクセスログ(ltsv形式)を fluentd 経由で BigQuery に送ってみたよ - えいのうにっき

    前回の いまさらだけど fluentd に入門した - えいのうにっき に引き続き、「いまさら fluentd」シリーズ(?)。 blog.a-know.me 事例としてはめちゃくちゃありそうなこの組み合わせ、「自分的にかゆいところ」に手が届いてるかんじの記事がないような気がしたので、それを少しでも増やすことができれば、という思いで、書いてみる。 nginx のアクセスログの形式を ltsv 形式にする まずはこれから。 そのために nginx の conf に手を加える必要がある。たとえばこんな↓かんじかな。 log_format ltsv "local_time:$time_local" "\thost:$remote_addr" "\tforwardedfor:$http_x_forwarded_for" "\treq:$request" "\tstatus:$status" "\t

    いまさらだけど、Nginx が出力したアクセスログ(ltsv形式)を fluentd 経由で BigQuery に送ってみたよ - えいのうにっき
  • いまさらだけど fluentd に入門した - えいのうにっき

    仕事で僕が担当してるプロダクトでも、「そろそろ fluentd を...」という話題が出始めた。 社内の別プロダクトでは既に導入されてるものもあったりして、たぶん会社的にはノウハウも溜まり始めてきてるとは思うんだけど、なにせ僕自身が fluentd について雰囲気しかわかってないままだったので、それじゃイカンなと、いまさらだけどようやく fluentd に入門した。そのついでにメモった内容を晒す。 入門前のイメージ みんな「アプリは何も考えず、とりあえず fluentd に投げとけば幸せになれる」って言ってる なので、そういう感じの存在なんだろうな fluentd は、くらいの理解しかない 具体的にどう幸せになるのかはあんまり想像が付いてない "d" がついてるので、デーモン的な何かかな? ロゴがイカしてる くコ:彡 ゴール 実際に導入するとなったら具体的にどんなことをしなければいけないの

    いまさらだけど fluentd に入門した - えいのうにっき
  • Git(GitHub)の運用で気をつけていること - えいのうにっき

    ある日、 PR の内容を見ずにマージすることを岡島(ピッチャーの)というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね!— そーだい@初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい@初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基

    Git(GitHub)の運用で気をつけていること - えいのうにっき
  • "Google App Engine for Java実践ガイド" を Go で書く! #gcpja - えいのうにっき

    このブログエントリはGoogle Cloud Platform Advent Calendar 2014 の 21日目の投稿です。 他の方の投稿はおそらくものすごくハイレベルな記事ばかりだと思うのですが、こういうのもイイんじゃないかなと思って、勇気を持って投下!(ハイレベルな記事を書けない、とも言うw) いま、GAE を勉強しようと思ったら slim3 quickstart by @sinmetal on @Qiita http://t.co/nUFzxghRRR GAEって、初学の書籍が壊滅的ですよねぇ、、、— れいな@底なし沼の魔女 (@MegaBlackLabel) 2014, 11月 29 @kassy_kz @vvakame shin1さんの以降は、最初から全部説明しているのは無いと思います。 http://t.co/v4rnClxi1b— 真 (@sinmetal) 2014

    "Google App Engine for Java実践ガイド" を Go で書く! #gcpja - えいのうにっき
  • gcp ja night #28 に参加してきたので色々まとめるよ #gcpja - えいのうにっき

    gcp ja night #28 に参加してきたので、色々まとめるよー。スライド資料を見ればわかるようなことは書かない方向で。 懇親会の場で、Googler の佐藤さんに、前から気になってたことをいくつか質問できたので、その内容もこのエントリの最後にメモっとく。 イベントページ gcp ja night #28 - connpass 各種まとめ 2014.09.16 gcp ja night #28 #gcpja - Togetter gcp ja night #28 - 資料一覧 - connpass Managed VMのDocker対応とKubernetes最新動向 @briandorsey by Brian Dorsey, Developer Advocate, Google Inc. 僕の観測範囲では、スライド資料の公開はなし GAE などのような PaaS を使いつつ、IaaS

    gcp ja night #28 に参加してきたので色々まとめるよ #gcpja - えいのうにっき
  • 「Google Compute Engine 入門」を読んで、AWS と GCP の違いをまとめてみた - えいのうにっき

    先日発売されたばかりの「Google Compute Engine 入門」(吉積 礼敏 氏 著)を読んだ。kindle版が出ていたので、買いやすかったし、読みやすかった :) 全体を通しての感想は「GCE(を中心とした、GCP)の紹介みたい」、というかんじ。AWS の現在の状況(隆盛)を考えると、GCP に関しては、このレベルの書籍が今、ようやく出版された段階だということは、厳しいけれどまごうことなき現実なんだよなぁ、と思った。 (ちなみに、gcutil のコマンドリファレンスまであるのはちょっとやり過ぎでは...と思った。Web のリファレンス では不足があるんだろうか?) でも、このを読むまでは「 AWS ではなく GCP をわざわざ選ぶ理由がわからない(デメリットを上回るメリットが感じられない) 」という気持ちしかなかった自分が、読み終わったときには「 課題はいくつかあるけれど、

    「Google Compute Engine 入門」を読んで、AWS と GCP の違いをまとめてみた - えいのうにっき
  • 1