地方エンジニアの学習日記

興味ある技術の雑なメモだったりを書いてくブログ。たまに日記とガジェット紹介。

【Nginx】ログの出力可否

特定UAの場合ログに書き込みたいくないみたいなケースがあってどうにかならないかみていたらaccess_logはifで状態を取れるらしいことに気づいた。

nginx.org

Syntax:  access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];
access_log off;
Default:    
access_log logs/access.log combined;
Context:    http, server, location, if in location, limit_except

サンプル通りやるならmapで変数を使うやり方

map $status $loggable {
    ~^[23]  0;
    default 1;
}

access_log /path/to/access.log combined if=$loggable;

ステータスコードが200系 or 300系ならログに書かないやり方。uaも同じように書けば特定uaだけログに出力しないみたいなことが可能

【AWS】Amazon Web Service 負荷試験入門の読書メモ

概要

Amazon Web Services負荷試験入門 ――クラウドの性能の引き出し方がわかる Software Design plus | 仲川 樽八, 森下 健 | 工学 | Kindleストア | Amazon

この本を読み始めたので気になったところとかをメモしていく

目次

負荷試験PDCAサイクル

負荷試験におけるPDCAはざっくり以下の流れ。一回で終わらせるのではなく回していくのが大事

  • Plan 負荷試験計画の立案
  • Do 負荷試験の準備及び実施
  • Check 計画時に立てた目標値と前提条件をクリアしたか
  • Action 負荷試験レポートの作成、システムの改善

試験なので合否を出してレポートまとめて終了みたいな場合が多くなりそうだが小さなPDCAを継続的に改善していくのが大事。

1章 間違いだらけの負荷試験とWebシステムの失敗事例

間違いだらけの負荷試験負荷試験は試験内容的にも後回しにされがちで最後の最後にさっとやって終わらせるケースが多い。負荷試験で問題が起きるとボトルネック次第では手戻りが大きくなるのできちんとスケジュールを組み込んでおく必要がある。

あとは基礎知識がない状態で負荷試験に挑むとレポートが実は誤りだらけであまり意味のないレポートが出来上がってしまい運用時に困るケースがある。間違った試験に気づかないまま試験完了とならないようにきちんとレビューなりで試験項目やレポートを確認する必要がある。

2章 Webシステムの設計手法

システムの設計手法

オンプレ時代/クラウド時代のwebアーキテクチャの説明とそれぞれの特性の違いなど

可用性に影響する起因

  • ネットワーク
  • 電源
  • ハードウェア

などなど可用性はソフトウェアだけで語れる部分と語れない部分が存在する。可用性の計算はシステムが直列になっている場合はそれぞれの積になる

単一障害点

システムは冗長化することで単一障害点をなくすことができる。別系統であるのが重要とされているが別系統ってみるレイヤ次第でどこまで変える必要があるのかなど考慮点は多いと感じた。(AWSでいうMulti-AZなど)

冗長度は以下の式で求めることができる

1 - (単一機器の利用不能率)^冗長度

冗長度を上げることで可用性が向上する

クラウド時代のシステム構築

ここでのクラウドとはオンプレ時代と違って自社でハードウェアリソースを調達せずにクラウド事業者の所有するリソースを時間単位で借りて利用できるシステム。

(馬鹿でかい会社だとプライベートクラウドのような概念も存在して自社でハードウェアを調達するがアプリケーションエンジニア視点では意識しないのでこの書籍でのクラウドにはプライベートクラウドも該当すると思って読んでいる)

この章はあとは代表的なクラウドデザインパターンの紹介と特性の説明となっていた。以下のサイトも詳しいので補完的に読むのに良さそう。

aws.clouddesignpattern.org

堅牢性とは

可用性と似た言葉に堅牢性という言葉がある。可用性とは違った概念を指していてデータ欠損が発生しない数値を示す。

3章 負荷試験の基本知識

負荷試験の基本知識

クラウド時代の負荷試験の目的

この章がとても刺さった。

クラウド時代の負荷試験はいわゆるオンプレ時代のようなハードウェアの選定や性能改善に必要な数値の割り出しの他にスケール性の評価が重要だということ。スケーラビリティはオンプレではあまり意識することなかったがクラウドはスケールが簡単に行えるので例えば単体サーバでの性能は重要ではあるが重要度はそこまで高くなくてサーバをスケールアウトやアップすることでサービス提供能力が高まることの方が大事。

スループット とレイテンシ

  • スループット -> 単位時間に処理を行う量のこと
  • レイテンシ -> 処理時間

それぞれ明確に意味は異なるがどちらかを改善するともう一方も改善したりと関連性はあったりする。またそれぞれ依存するサブシステムが存在する場合はそこの数値のうち最小値がボトルネックとなり得るので意識する必要がある

悪い負荷試験

  • 試験対象システムに負荷が集中していない
    • 試験対象外の場所に負荷が集中している状態
  • ボトルネックを特定できていない
    • 負荷試験の目的としてどこをスケールさせれば性能が出るかなどを知るためにやったりもするのでこの観点は大事

4 負荷試験のツール

負荷試験を行うためのツールである攻撃やプロファイリング/モニタリーングツールに関しての選定基準など。選定基準には攻撃力についてなんかもためになった

  • 攻撃ツール -> システムに負荷を与えるツール
  • モニタリングツール -> システムのリソース状況を観測し可視化するツール
  • プロファイリングツール -> ミドルウェアやアプリの内部の動作を可視化するツール

(プロファイリングは使ったことないけどflaskとかspringにあるような高機能なものはいつか使ってみたい)

攻撃ツール

モニタリングツール

プロファイリングツール

5 負荷試験の計画

計画の立て方や目標値の設定方法など

6 負荷試験の準備

事前に必要な準備について

7 負荷試験の実施1―試験実施とボトルネックの特定

8 負荷試験の実施2―原因分析とシステムの改善作業

9 負荷試験レポートの作成

10 負荷試験実践のケーススタディ

11 巻末資料

その他

負荷テストの目的

【転職ドラフト】使ってみた感想

概要

転職ドラフトを使って転職したのでサービスについての感想なんかを書いた記事。転職への思いとかは別記事で書くのでこれはあくまでもサービスのユーザとして思ったことがメイン

ちなみにこちらの記事は転職ドラフト体験談投稿キャンペーンに参加しています

job-draft.jp

転職ドラフトに登録したきっかけ

そもそも転職を考えていて転職サイトを色々眺めていたら見つけて面白そうなサービスだなと感じて登録してみた。

あとはどんな人が市場価値が高いのかとか市場の流れ的なものを見たかったという思いも少しあったり。具体的には

  • どんな指名があったのか?
  • どの年齢層が居るのか?
  • どんな技術を持っている人が多いのか?
  • 指名額が高かった人は、どの技術を持っていたか

みたいなのが知れたら面白いかなとか。

転職ドラフトの流れ

  • ① サイトに登録する
  • ② レジュメを書いて審査を出す
  • ③ ②が通ればドラフトへ参加。通らなければフィードバックをもらって再審査
  • ④ 指名が入る
  • ⑤ 指名への返答をする。ここでカジュアル面談をするか面接へ進むかを決めることができる
  • ⑥ ここから先は転職ドラフト外でのやりとりとなる

大まかにこんな感じ。私がもらった指名の会社はどこも面接に進む際にメールなんかでのやりとりが必須になったので転職ドラフトで完結するわけではなかった。(個人情報の取り扱いの同意や履歴書/職務経歴書を登録するページなんかが別にあってその辺を使う必要がある程度)

参加までとドラフト結果

転職ドラフトは参加するための審査があってそもそもそれを通すのが大変的なコメントを多く見た気がするがすんなり1回の審査で通った。(レビュー機能があるのは知っていたのでそれを頼りにとりあえず出そうくらいだった。)

job-draft.jp

指名結果としては合計で17社から指名があった。正直この数が多いのか少ないのかは分からないけど自分にも需要があるんだなというのは感じて少しだけ自信には繋がったりもした。

ただ注意点として指名数=技術力ではなくて年収1000万とかで指名貰っている人は指名数は少ない傾向が見られたので今回の数値で浮かれてはいけないとも思った。(提示年収と指名数の関係性のデータがあったら見たい気がする。)

指名メッセージ/面談から感じたもの

所謂テンプレ的なメッセージでのスカウトはシステム的に禁止しているらしくそれぞれ特徴のあるメッセージを頂けました。特にブログやGitHubでの活動に関しては結構細かく見られた上でカジュアル面談に進んだというのもあってそれぞれの会社さんとのやりとりはとても楽でした。(昔の記事とか読まれたりで少し恥ずかしさはあった気もする。。)

あとは参加者の人たちのレジュメを公開されている部分だけ見ているとGitHubやQiitaやスライドサービスのアカウントがある人が多いなと感じた。「高年収での提示をもらうには」見たいな記事を公式が出したりしているてこれも面白かった。

job-draft.jp

改善要望的なの

  • 通知が非同期

メッセージの通知が非同期なのが辛いです。メールは通知が来るので楽ですがメッセージの確認にサイトへのアクセスが必要なのがちょっと不便かなと感じました。

  • 企業の検索機能をもう少し増やして欲しい

これはシステムの特性的に不要という判断でやってるのかもしれないですが「転職ドラフト見たいな面白いサービスを使って求人している企業はどんなところがあるんだろう」見たいな時に検索機能がもっと細かく使えたりすると良いかなと思いました。

転職ドラフトを使ったことがない方へのメッセージ

年収額の相場を知ることができるのは他にはないサービスですごい良いサービスと感じました。「絶対にここに行きたい!」みたいなのがある場合で使用する転職サイトが決まっている場合でも使ってみて自分の相場を知るのには良いのではと思います。

(Twitterとかみていたらここで提示された額を使って自社に給与交渉している人がいるのを見かけてそんな使い方もあるというのを知って驚き)

最後に

個人的にはこれまでにない転職活動となって新鮮で楽しかったです。従来の転職活動の方法も良いですが併せて使ってみる価値はあると思います。転職予定の方へ少しでも参考になれば幸いです!

登録時に以下のコードを入れていただけると紹介特典が貰えるので是非登録してください!

「YLDJ」

job-draft.jp