2023年買ってよかったもの
なんとか間に合った、2023 年の買ってよかったものリストを書きます。 2022年の買ってよかったもの
THR10II
長い間 ZOOM G5n を使っていたが、人生初のエフェクターボードを組む機運がやってきたのでアンプも欲しくなって購入した。 要件は USB で PC に繋げられて、かつ Phone 出力があること。今どきこれくらいの要件を満たすアンプはいくらでもありそうだけど、値段帯とサイズ感がちょうど良いところが気に入っている。 コーラスやフランジャー、リバーブなどのエフェクトも設定できることと、ゲインのモードが何種類かあってアンプ単体でも幅広い音作りができる。宅練であれば正直これ単体で十分だと思う。 上位モデルになればバッテリー駆動やワイヤレス接続などもサポートされるが、自宅に固定して使う想定だったのでそこまでは求めなかった。 今年は音作りもボチボチ頑張り始めたので練習や研究に役立っている、来年も使い倒す予定。
OPENFIT
仕事用に購入した shokz のオープンイヤーイヤホン。ほぼ自宅で仕事をしていて MTG 等で耳を覆っている時間が長いので健康のために購入。 オープンイヤーは音が聞こえにくそうな印象があるが本アイテムはそんなことはなく、かなりバッチリな音量で聞こえる。音質も十分だと感じる。 shokz のイヤホンに対応したアプリを使えばイコライザを設定することもできて、特に高音重視のセッティングにすると音量面の不安は無くなる。流石に屋外では騒音に負けるが屋内では十分だと思う。 何よりつけ心地が抜群で、装着感がほぼ無い。つけたことを本気で忘れて過ごしてしまったことも何回かある。 改善点は shokz 全体に言えるがマルチポイント接続の使い心地が微妙なこと。アプリでサポートされるが、複数台端末を登録している際に意図しない端末に接続したりするなど使い勝手がイマイチ。 また、アプリからイヤホンを認識するのにも10秒前後待つのも改善されると嬉しい。 こういった改善点はあるが、仕事用や普段遣いとしてなかなか良いアイテムだと思う。
KC-N50
シャープの空気清浄機。空気清浄機能もさることながら加湿器として利用したくて購入した。 今住んでいる家の特徴なのか加齢のせいか乾燥がひどく、冬場になると静電気が各所で強烈に発生してそのうち皿とかを割りそうだったので対策 まだ使用して1ヶ月程度だが、常時稼働させているおかげもあり静電気の発生は明確に軽減されている。環境にもよるだろうが掃除も面倒じゃないので24時間稼働で放置しておいても問題なさそう。 改善点は水タンクの取り付けに少しコツがいること。結構奥の方をめがけて挿入しないとなかなか入らず、力任せにやるとロック機構を壊しそう。おそらくシャープの空気清浄機は全部この問題を抱えていそうな気がする。 とはいえ慣れてしまえば大したことがないので、この冬一番良い買い物だったと思う。
Team Geekを読んだ
以前から気になっていた Team Geek を読んだ。
感想
書籍の発行から10年近く経っており触れられる技術は当時感がある ( subversion とか ) が、本題は現代でも全く色褪せない内容で読み応えがあった。エンジニアチームの一員として自分自身がどうしていくべきかが書かれており、ルーキーからベテランまで幅広い層がハッとする内容になっている。内容自体はごく当たり前のことだが、だからこそそれが出来ていない、という気づきを得る人も多いと思う。定期的に読み返すと良さそう。最高ではなくて最善のリーダーを目指す、というどこかで聞いたワードが頭をよぎった。 とても良著だが、個人的には kindle で手に入らない点だけが難点。
抜粋
- エンジニアチームで成功するためには、自分が「謙虚・尊敬・信頼」の原則に基づいて行動できている必要がある
- この3つを指して HRT という
- ソフトウェア開発はチームスポーツ
- 自分が一番重要な人物であるかのように振る舞う人と一緒に仕事をしたくない
- 過去に失敗したことが無いのであれば、革新的でないか、リスクを取っていないか
- 文化は育つことで初めてチームはバリューを生み出すことが出来、文化が貧弱だと新参者などの外来菌に打ち負かされる
- 文化は最初期からいる人が作る。 単体テスト、ドキュメンテーション、コードレビュー、チームランチ、飲み会、etc…
- 文化が弱い場合、強烈な個性を持つ新参者が来ると彼の文化が根付いてしまう。それが良いものであればよいが、おそらくそうではない
- チームリーダーが文化を作る、というのは勘違いでチームメンバーが文化を育てる
- 文化に一致している人を迎え入れたい、素直に面接で聞くのも一つの手段
- 優秀なエンジニアは自分でバスを運転したい。そのため合意ベースのコミュニケーションやマネジメントでなければならない
- コミュニケーションの原則は同期ではなく非同期。出来るだけ多くの人がドキュメントなどから情報を拾い切れることが重要。
- 地理的障害があるチームでも合意ベースを忘れない工夫があれば大丈夫、ただしフェイストゥーフェイスの帯域を過小評価してはいけない
- チームを子供扱いしてはならない、HRTを忘れずに
- マネージャーはどうやって仕事を終わらせるか考える、リーダーは何が出来るかを考える ( How はメンバーに任せる
- チームリーダーは技術的側面だけでなく人間的側面も担当する
- チームの幸せと生産性を高めることがマネジメントの仕事の指標、リーダーはエンジニアとは違ったものを作っていることを忘れるな
- サーバントリーダーの最大の使命は、HRTの空気や文化を作り出しチームに浸透させること
- 自らの手を汚すのがサーバントリーダー
- どうやって成長させるか。足を痛めた人のリハビリのように、一時的なマイクロマネジメントが必要になる。その際に、HRT ( 特に尊敬 ) が前提にあることを忘れてはいけない。
- 期限 ( 2 ~ 3 ヶ月 )を決めて達成したい目標を決めて、少しずつ大きくしていく。毎週会って進捗を確認する。マイルストーンには明確な期待を設定し、成功か失敗かを判断する。
- チームを子供や囚人のように扱えば、チームに信頼していないことが伝わる。マイクロマネジメントしたり、能力をけなしたり、仕事の責任を与えなかったり。これらが必要なシーンが出てくるということは、そもそも採用に失敗している。
- チームリーダーにとって個人のエゴは特に禁物。リーダーの役目はチームの合意形成。エゴを無くすにはまずチームメンバーを信頼すること。質問を歓迎すること。
- リーダーは何でも把握していて全てに正しく回答できる必要があると思いがちだが間違い。逆に信頼を失ってしまう。翻って、その仕事についてリーダーより詳しいメンバーがいる状態が健全。
- ミスをしたときに謝ること。失敗したときに謝罪できるリーダーは尊敬される。何も言わなくてもいずれチームメンバーにミスは露見する。
- あらゆることに楽観的である必要はないが、懐疑的な言葉は慎んだ方が良い
- チームをリードするときは、自分の考えを伝えて平静を保つこと。メンバーは意図しようとしまいとリーダーの反応や行動をみているから。
- リーダーならば問題解決モードに突入するのではなく、エンジニアが彼自身の手で問題解決をすることを手伝うこと 、エンジニア自身の答えを見つけることを手助けすること。そうすることで当事者意識や責任を養うことが出来る。
- リーダーは障害を直接取り除くのではなく、適切な人を知っていることの方が価値がある
- チームに変化を引き起こす方法の一つに、安心感を与えてリスクをとれるようにする方法がある。賢く失敗するためにも、失敗しても良いことをチームに知らせれば良い。断じて、みんなの前で個人を批判してはならない。
- リーダーにとって難しい状況は、自分ならすぐ解決できる問題に若手が時間をかけている状況。自力で学ばせることが重要という前提の上で最も大切なことは、新人がどれだけの支援を必要としているかを適切に読み取る能力。
- リーダーにとってチームの目標を明示することは大事だけども実践されていないテクニックの一つ。同じ方向にトラックを引っ張っているか？
- 褒めのサンドイッチでは、本当に伝えるべきフィードバックが伝わらない可能性がある。メッセージが正しく伝わっているか、相手を防御的にする伝え方をしていないか。オブラートに包まず、それでいて失礼のないように。
- チームを長期的にわたって生産的な状態に保つには、チームの幸福を測る。1on1 の後に「何か必要なものはあるか？」と質問するのが良い。
- オフィスの外にあるチームの幸せにも目を向ける。プライバシーの詮索ではなく、プライベートの状況も勘案する。誰もが考えている長期的な目標を明確化すること。
- 委譲せよ、ただし手は汚せ。たとえ自分がやった方が早くてもチームメンバーに仕事を任せることが、リーダーが正気を保つ唯一の方法。あとは、誰もやらないような仕事を引き受けること。
- 新しいことに挑戦したがるメンバーがいるとした時、やり直しができることなら OK を出してしまう。優秀なリーダーは、取り返しがつくかどうかの判断に優れている。
特定のgithub actionsの実行状況や結果をslack上で通知する
/github subscribe owner/repo workflows:{name:"workflow_name"}
e2e や lighthouse-ci を github actions でバッチ実行しており、その結果を slack に通知して欲しかったので試した結果こうなった。 slack への通知はよく event をフックにして通知する例が紹介されているが、この手のバッチ実行の場合はそれが出来ないので結局 name でひっかけることにした。
バッチ実行の頻度によっては通知うるさいかもなーと思いつつ、今のところは不便なく使えている。
2022年買ってよかったもの
三十路も超えていよいよライフログが重要になってきたので、今年からは簡単にでも残していく。
バイク / 普通自動二輪免許
ついに手を出してしまった。10年ぶりに行く教習所は web 以外の世の中ってこうだよな感があった。教官にドヤされながら乗るバイク、嫌いじゃなかったです。
ともあれ無事に免許を取ってバイクを購入。乗りやすさ扱いやすさを重視して Honda 400X をチョイス。
乗り味は教習車以上にマイルドで低速トルクたっぷり、でも高速走行もしっかりこなせる僕好みの器用貧乏。
欠点はアドベンチャーツアラーなので足つきが良くないところ。 あとはリアブレーキの効きがやや心許ない気がする。
バイクは買ってしまうと本体のオプションやらアクセサリやら保険やらで金がどんどん無くなっていくのでその点恐ろしかった。
あと、土日も仕事をしていたりすると走行距離が全く伸びなくてディーラーに煽られる。ごめんて。
400X はスポーツ走行以外のあらゆる用途についてきてくれるので普段使いからロンツーまで何にでも使える。アドベンチャーツアラーはある程度の悪路も安心。
休日はこいつでスパ銭巡りをすると心身が健康になります。埼玉あたりは結構走った気がする。来年はもうちょっと遠出しようかな。
インカム
関連してインカム。ナビの音声を聞く用途で購入。
AirPods でも代用効くけどたまに耳が痛くなるのとバッテリーの持ちが心配になる瞬間があるので思い切って購入。
メットの内側にスピーカーを貼り付けるので音量を上げれば聞き取りバッチリで安全安心。バッテリーも相当保ちます。
ついでにバイクからスマホを給電出来るようにしておくとなお捗ります。
ぼっちなのでインカムとして使ったことはないです。
電気圧力鍋
以前から興味があったので年始に購入。食材を放り込んでおくと自動でメシを作ってくれる優れ物。
特にこの年末は平日に料理する時間が全然無かったので週末に作り置きを作る用途で大活躍。あとは鶏胸肉をひたすら低温調理にしていた。
カレーとか牛すじ煮込みを毎週末生成してタッパー冷蔵庫コンボに助けられ続けている。
付属のレシピに沿って調理すれば大体は美味しく出来上がる。特に大根を入れると30分ほどの煮込み時間で2日目の味が手に入るのは驚いた。
おでんとかぶり大根を作ると米も酒も無限にいける。
一方でローストビーフはレシピ通りでもイマイチだったかも。YouTube とか参考にしてレシピを探しつつ炊飯器調理が安定かもしれない。
https://www.irisohyama.co.jp/e-pressure-cooker/
Cubasis 3
iOS 向け DAW。iPad で使ってるけど、今の DAW アプリってデスクトップアプリと遜色ないっすね。。
Windows の Cubase を使っているけど使い味がそんなに変わらない。音源の共有とかも出来るので非常に楽。
欠点はショートカットが分かりづらいので作業効率がやや落ちる。でも特にチュートリアルとか無くて知らないと苦戦するのはデスクトップアプリでも一緒か。
買った後そんなに使い込み出来てないので来年頑張る。
https://www.steinberg.net/ja/cubasis/new-features/
Apple Watch
ついに軍門に降ってしまった。健康管理をしたくて購入。でも1番役立ってるのはマスク時のロック解除かも。
キャッシュレス決済も楽に出来るので常に腕に巻いてる気がする。筋トレのインターバル計測にも便利。
つい調子に乗って通知登録をしまくると無限にうるさいデバイスになるところが欠点 ( V の者のファンアートリツイート爆撃で起こされる )
https://www.apple.com/jp/apple-watch-series-8/
衣類圧縮袋
すごい年数ぶりに飛行機に乗るにあたって荷物をコンパクトにしたくて購入。
3日分くらいを7 ~ 8割くらいの体積にして入れられる。便利。
おかげでバックパックひとつで飛行機に乗り込むことが出来て楽ちんでした。
来年は化粧品類をコンパクトに持ち運べる術を探りたい。。コンパクトな詰め替えボトルしか無いかしら。。
https://www.amazon.co.jp/gp/product/B07MTF38GK/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1
深型バット / パイ皿
自炊勢は必ず買った方が良いレベル。
食材の下ごしらえやら重石代わりやらで大活躍。3つずつくらいあると捗ると思う。深型バットは簡単な付け込みとか玉ねぎの辛み取りにすごく便利。
もうこれが無い自炊生活には戻れなさそう。
zshからfishに乗り換えた
zsh から fish に試しで乗り換えたので設定メモ
こんな感じの設定になった。元々の .zshrc はすごい複雑になっていたので、必要そうなところだけ抜粋した。 nodebrew と pyenv の PATH 設定と、少々の alias くらい。
if status is-interactive set -g theme_display_date yes set -g theme_display_git_default_branch yes set -g theme_color_scheme dark set fish_plugins theme peco set -x PATH $HOME/.nodebrew/current/bin:$PATH set -x PYENV_ROOT "$HOME/.pyenv" set -x PATH $PYENV_ROOT/shims:$PATH pyenv init - | source alias n='nvim' alias g='cd $(ghq root)/$(ghq list | peco)' alias f='echo find . -name filename' end function fish_user_key_bindings bind \cr peco_select_history end
良かったところ
ちょっと工夫が必要だったところ
- global alias が使えなかった
- git の current branch name を global alias を使って展開できるようにしていたので、不便
- 代替でよく使うpushコマンドに abbr を設定してみて、今の所はなんとか動いている
- 一時的な環境変数が使えない（らしい）
HOGE=fuga npm run buildみたいなやつ- fish_config に書くしかないっぽい？？
まだ私物のマシンにしか入れてないけど、調子良さそうなら会社のマシンにも設定してみる。 見た目ももう少しこだわりたいな〜
Webを支える技術を読んだ
会社の本棚にあったものを読むことにした。
普段の生活や業務の中で息をするようにHTTPに触れているが、HTTPのことちゃんと理解してないのでは？と思い読み始めた。
RESTやHTTPの成り立ちや基本的なところのおさらい、特にヘッダーまわりについてはちゃんと意識することが無かったので新しい発見があった。一方で、流石に内容の陳腐化も進んでしまっていた。ATOMまわりはぼんやりしか知らなかったのでそれはそれで面白かったが。
以下読書メモ。
REST Webのアーキテクチャスタイル
- アーキテクチャとアーキテクチャスタイルは異なる
- デザインとデザインパターンが異なるのと同様
- RESTはネットワークシステムのアーキテクチャスタイル
- クライアント/サーバーに特に有効
- まさにWeb
- クライアント/サーバーに特に有効
- リソースの名前 = URI
- リソース = Web上の情報
- RESTは、複数のアーキテクチャスタイルを組み合わせて成り立っている
- クライアント/サーバー
- ステートレスサーバー
- クッキーでのセッション管理はこれに反する
- キャッシュ
- 統一インターフェース
- ここでのインターフェースは、GETやPOSTを指している @
- 階層化システム
- コードオンデマンド: プログラムをクライアントにダウンロードして実行する
URI
HTTP
- TCP/IPとは
- インターネットのプロトコルは階層型プロトコル
- ネットワークインターフェース層
- ケーブルとか
- インターネット層
- ネットワークで実際にデータをやり取りする部分
- IPとは、インターネット層のプロトコルのこと
- IPでは、送り出したデータが相手に届くかまでは保証しない
- トランスポート層
- アプリケーション層
- メールやDNS、HTTPSを実現する層
- ソケットとは、TCPでプログラムを用いるときに使うライブラリ
- ネットワークでのやり取りを抽象化したAPI
- 接続、送信、受信、切断など。。。
- WebSocketとの関連はどうなんだろう
- websocketとは: https://qiita.com/south37/items/6f92d4268fe676347160
- リクエスト/レスポンス
HTTPメソッド
- POSTでPUT/DELETEを代用する
- _methodパラメータ
- formの中にtype=hiddenなinput要素を配置し、idを_methodとする
- valueに書いたメソッドが使える
- application/x-www-form-urlencodedの場合にのみ使える
- X-HTTP-Method-Override
- _methodパラメータ
- 条件付きリクエスト
- HTTPメソッドと更新日時などのヘッダを組み合わせて、メソッドの実行可否をキメられる
- If-Modified-Sinceヘッダなど
- 冪等性と安全性
- 冪等性: ある操作を何回行っても結果が同じこと
- 安全: 捜査対象のリソースの状態を変化させないこと
- 変化を与える: 副作用
ステータスコード
- 仕様で定められたステータスコードを正しく使いたい
- 分類
- 1xx: 処理中
- 2xx: 成功
- 3xx: リダイレクト
- 4xx: クライアントエラー
- 5xx: サーバーエラー
HTTPヘッダ
- メタデータ
- 認証やキャッシュなどHTTPの機能はヘッダで実現する
- ヘッダの機能
- 日時
- Date
- Expires
- MIMEメディアタイプ
- Content-Type
- charset(文字エンコーディング)
- 言語タグ
- Content-Langugage: ja-JP
- コンテントネゴシエーション
- Accept
- クライアントが処理できるメディアタイプをサーバーに伝える
- Accept-Charset
- Accept-Language
- Accept
- Contente-Length
- 認証
- Authorization
- キャッシュ
- Pragma
- キャッシュ禁止
- Expires
- Cache-Control
- 詳細なキャッシュ方法の指定
- 前述の指定はここでもできる
- max-ageとか
- 条件付きGET
- If-Modified-Since
- Pragma
- 日時
microformats
- classやrel属性でメタデータを表す
- wordpressでは採用されてる
- microformats は競合する他のメタデータのフォーマットと比較して、古くから存在し、Wordpress などでも採用されていることから、 検索エンジンも採用したのだと考えられます。(他に Yahoo が一部取り入れているようです。)ただし、Google は schema.org の提唱するメタデータを採用するように推奨しています。 schema.org は、Google, Yahoo, Bing(Microsoft) などが共同で管理する団体です。 また schema.org が提唱するメタデータの記述形式、microdata や RDFa フォーマットは、W3C で制定されるフォーマットです。検索エンジンを提供する各社が microformats のサポートを直ぐに止めることは考えられませんが、 今後は schema.org のメタデータを microdata フォーマットでマークアップ(記述)することがスタンダードになっていくと思われます。
- SEOに寄与するかも微妙、標準化競争に負けたように見える
Atom
Web開発者のための大規模サービス技術入門を読んだ
会社の本棚にあったものを読むことにした。
業務ではWebフロントに注力していて、触るとしてもnginxやCDNまわりなのでサービス負荷について考える基準が欲しかったことがモチベーション。
少し古い本なので多少内容が陳腐化している箇所もあったものの、今でも使える基本的な知識や考え方について解説されている。（やむを得ないが）書籍中に出てくるコードはほぼPerlなので読んでなんとなく内容を察する程度で精一杯だった。
OSキャッシュやスケーリングの考え方はあまり詳しく知らなかったところなので良かった。業務外でサーバーを立てる時もスペックは割と適当だったりするので、この辺りの考え方を体得できると業務にも役立てることが出来そう。OSキャッシュの辺りは特に、言われてみれば当たり前だが今までさほど気にしたこともなかった。普段はブラウザ全体のメモリ消費量をなんとなく気にする程度なのだが、アプリケーションのパフォーマンスの観点でもメモリ消費量を気にする癖をつけたい。モニタリングが手軽に出来れば良いのだろうか。
DBまわりも通り一遍というかクエリの書き方を知っている程度なので、サービスに落とし込む際にどういったことを考えるかを知れてよかった。マスタースレーブ構成のクラスタにおいて、マスター間の遅延について考えたこともなかったので新鮮だった。また、これも初歩的な話だがストレージエンジンについて今までほぼシカトしてきていたので知ることができてよかった。
また、アルゴリズムにも興味があった。学生時代に講義で触った記憶はあるものの、ほぼ忘れ去っているからだ。せめてクイックソートくらいは諳んじて書けるようにしたい。結果、書籍中では具体的なアルゴリズムに踏み込んではいなかったが、きっかけにはなった。実践するには競技プログラミングあたりに踏み込むことになるのだろうか。
領域外の知識を吸収する足がかりに出来そうなので、定期的に読み返しておきたい。
以下読書メモ。
オリエンテーション
- スケールアウト時の課題
- ロードバランシング
- データの同期
- ネットワークレイテンシ
- 大規模データ量への対処
- ディスク、メモリ、キャッシュメモリ、CPUの順で速度差がある
- データが小さいうちは処理をメモリで行えるが、大規模になるとそうはいかない
- いかにデータを小さく持つか、複数サーバーに分散させるか、必要なデータを最小限の回数で読み取るか
大規模データ処理入門
- 大規模データとは何か
- 大規模すぎてメモリで処理できない
- メモリはディスクの105 ~ 106倍早い
- SSDは高速だが、バスの性能差故にメモリほどではない
- 負荷の種類
- CPU負荷
- I/O負荷
- ボトルネックを調べるには
- CPU負荷のスケーリングはサーバー台数を増やす
- DBなどI/Oの場合は、データ同期の観点から分散が難しい
OSのキャッシュと分散
- ページ: OSが物理メモリを確保/管理する単位、仮想メモリの最小単位
- プロセスは仮想メモリにしかアクセスできず、ディスクに直接アクセス出来ない
- そのプロセスがアクセス済みになったデータもメモリに残しておく、これがページキャッシュ
- 一度ディスクにアクセスすると、その後のアクセスが早くなる
- LRU: Least Recently Used、一番古いものを破棄して新しいものを残す
- Linuxはメモリがあいていればディスクをキャッシュし続ける
- メモリを増やす = I/O負荷軽減
- キャッシュがI/O対策の基本
- 小さければメモリに載せきれる
- データをキャッシュしきれない規模になったら、複数サーバーでのスケールを考える
- CPUリソース(APIサーバー)が必要な場合は単純に増やせる
- DBの場合は局所性が絡んでくる
- メモリの増設ポイント
- キャッシュ容量と、アプリケーションが扱う有効なデータ量を比較する
- 局所性対策
- アクセスパターンを考慮して分散させて、キャッシュできない領域をなくす
- パーティショニングで実現することが多い
- 負荷分散の学習のためには、OSの動作原理を知ると良い
DBのスケールアウト戦略
- インデックスを正しく運用する
- カラムの型が何で、どれくらいのバイト数で、全体通すとどれくらいのサイズになるのか計算する
- B+木
- O(n) to O(log n)
- MySQLでは、where, order by , group byに指定されたカラムに対してインデックスが使われる
- 明示的に作用したインデックス、プライマリーキー、UNIQUE制約がインデックスとして作用する
- MySQLにおいては、複数カラムがインデックス利用の対象になった場合には、複合インデックスを使う必要がある
- 単一のインデックスの場合は、どちらかのインデックスのみが使われる
- explainコマンドで、インデックスが効いているかどうか確認できる
- レプリケーション
- マスタースレーブ
- マスターが更新系、スレーブが参照系
- 参照系はスケールするが、更新系はスケールさせない
- どうしても更新系をスケールさせる際は、テーブル分割でテーブルサイズを小さくする
- もしくはKVSを使う、RDBMSではなくする
- ポーリング
- マスタースレーブ
- MySQLでは、異なるサーバーにあるテーブルをJOINできない
- クエリを分割して対応する方が良い
- テーブル同士が密結合であれば、同じサーバーにおいてしまう方が良い
- パーティショニングのデメリット
- 運用が複雑になる
- 故障率が上がる
- 冗長化を考えるとマスター1スレーブ3の4台1セットにすると良い
- 故障時のデータコピーのことを考える
- パーティショニングはあくまで切り札として扱う方が良い
大規模データ処理[実践]入門
アルゴリズムの実用化
- 広義のアルゴリズム
- 実装の仕組みなど
- 狭義のアルゴリズム
- 定義された計算問題に対して、定義された計算を行うもの
- 対数的な計算量のアルゴリズムを選びたい
- アルゴリズムとデータ構造はセット
- （私見）アルゴリズムを知っているかどうか、が重要な気がする
- アルゴリズムを用いる場合は、テストファーストで開発を進めると良い
大規模データ処理を支えるサーバー/インフラ入門
- エンタープライズでは信頼性が最重要視され、またトランザクションが多用される傾向にある
- webとエンタープライズではインフラにおける重要ポイントが異なる
- クラウドのメリデメ
- スケーラビリティ
- 各クラウドサービスの独自仕様に対応
- オンプレ
- サーバー/インフラ構成の自由度が高い
スケーラビリティの確保に必要な考え方
- 多くのサービスはサーバー一台で動く
- 4core CPU 8GB: 100万PV/月
- 4core CPU 32GB: 200万PV/月
- 負荷を測るための項目
- ロードアベレージ
- それらのプロセスがいつでも動ける状態なのにCPUが未割り当てで、待ち状態にあるプロセスの平均値
- メモリの割当状態
- ロードアベレージ
- 用途ごとのチューニング
- レスポンスタイム、処理数など何に注力するのか
- 用途が増え、細分化すると管理や異常検知が大変
- だからkubeが人気になったんだよなあ
冗長性の確保、システムの安定化
- 単一故障点の除去
- APサーバーは、台数を並べるのが基本
- ロードバランサのフェイルオーバー、フェイルオーバー
- ロードバランサによるAPサーバーのヘルスチェック
- 落ちたら外して、復帰したら戻す
- ロードバランサのフェイルオーバー、フェイルオーバー
- サーバーが止まる理由は様々
- 人為的な理由
- 物理的な故障
- メモリ異常
- DBサーバー
- マスタースレーブ方式で、一台二台落ちても大丈夫にする
- マスターの冗長化にはマルチマスタ方式を用いる
- 双方が双方のスレーブである
- 片方への更新が、もう片方にも伝搬する
- ミリ秒単位の遅延は避けられない（割り切るか、どうか
- マルチマスタ
- ストレージサーバー
- MogileFS: 分散ストレージサーバー
- システムの安定化
Webサービスとネットワーク
- サービスの成長とネットワークの分岐点
いまどきのWebサービス構築に求められる実践技術
- ジョブキューシステム
- リクエストを非同期にしたい
- 構成要素
- クライアント
- ジョブを投入するもの
- ジョブキュー
- ジョブを蓄えるキュー
- ワーカー
- ジョブキューから未実行のジョブを取り出して実行
- クライアント
- よさそう
- ストレージの選択
- 適切なストレージを選択することは難しい
- アプリケーションからストレージを参照する際のアクセスパターン
- 平均サイズ
- 最大サイズ
- 新規追加頻度
- 更新頻度
- 削除頻度
- 参照頻度
- ストレージの種類
- RDBMS
- 分散key-valueストア
- memcached
- メモリ上で動作
- キャッシュとして使う
- redisと比べて、パフォーマンスに大きく差があるわけではない
- redisに出来て、memcachedに出来ないこと
- データの永続化（ただし永続化設定するとその精密さに応じてパフォーマンスは下がる）
- master/slave構成
- 暗号化
- ソート
- https://qiita.com/robitan/items/2e7f599c4cb1d65f3286
- memcached
- キャッシュシステム
- フォワードプロキシ
- クライアントが外部のサーバー・ネットワークに接続する際に挟むプロキシ
- リバースプロキシ
- 外部のクライアントが内部のサーバー・ネットワークに接続する際に挟むプロキシ
- これらのプロキシでは、リクエストをキャッシュしておくことが出来る
- キャッシュサーバーのメリット
- 平常時に、APサーバーへのリクエストを軽減することが出来る
- サーバーの台数削減に繋がる
- アクセス増加時には、負荷増大によるシステム全体のダウンを予防することが出来る
- アクセスが集中しているコンテンツをキャッシュして返す
- 平常時に、APサーバーへのリクエストを軽減することが出来る
- 分散、冗長化も効果的
- 容量が大きいファイルなどをキャッシュする場合は、キャッシュサーバーを二重化すると良い
- サーバー起動時にはキャッシュが全然ないから注意
- activeにする前に、ウォームアップをしてキャッシュを溜めておこう
- Squid
- リバースプロキシキャッシュサーバー
- 結構歴史がある
- 代替にはnginx, varnishなど。。。
- Varnish
- フォワードプロキシ
- 計算クラスタ
- Hadoop
- Redshift
- 最近のトレンドは。。。？
- BiqQuery?
