大規模なコードベースでリファクタリングを省エネ化するためにcodemodを最近調べていて、軽く試行錯誤したのでそのメモ。 やりたいこと 例えば以下のようなTable Driven TestなコードをBEFOREからAFTERに書き換えたい。コード量が多いため人間がやるのは現実的ではなく、codemodで機械的に書き換えたい。 BEFORE package main import ( "slices" "testing" ) func TestContains(t *testing.T) { type args struct { ss []string s string } tests := []struct { name string args args want bool }{ { name: "empty: false", args: args{[]string{}, ""}, wan

前回のapacheでのリバースプロキシ構築の続編です。 今度はバックエンド側でHTTPSのホームページがある場合になります。 この場合クライアント～フロントエンドまではHTTPS(443/tcp)で通信し、フロントエンド～バックエンドはHTTP(80/tcp)で通信する設定となります。つまり、フロントエンドのリバースプロキシにSSLアクセラレータの機能を持たせることになります。 設定についてはそんなに難しくなく、昔むかーしに記事にした、Apache + SSL を見てリバースプロキシ側に証明書を作成します。 /etc/httpd/conf.d/ssl.confは前回のようにVirtualHostディレクティブ内にProxyの設定を記載します。 (省略) <VirtualHost 192.168.xx.xx:443> ErrorLog logs/ssl_error_log T

AWSアドバンスドコンサルティングパートナーの一員として活動する株式会社スタイルズが、AWS導入、移行、開発、セキュリティ、運用保守など、すべてのご相談に乗らせていただきます。 AWSを導入したいが何から始めたらいいかわからない 既存のベンダーが新技術に弱く、良い提案がもらえない クラウドの導入にセキュリティの不安がある AWSをとりあえず導入したが、さらに活用していきたい 社内にAWSの知見を持っている人がいない AWSならではのシステム開発を詳しく知りたい

Raycastを使い始めて1年経ったので、どういうことに使っているかを振り返ってみる。去年書いた AlfredからRaycastに移行した - oinume journal の記事から少し使い方が変わっているところもあるのでメモがてら。 基本的な使い方 Cmd + QをRaycast起動のショートカットとして割り当てている。Pro版は使っていないのでAI機能などは使ったことがない。 ブラウザのブックマーク検索など、よく使うけどHotKeyを割り当てるほどでもないRaycastコマンドはbmのようにAliasを設定している。 Cmd + QでRaycastを起動してbmと入力するとブックマークの検索ができるので楽ちん アプリケーションランチャー機能 アプリケーションを起動するときのランチャーとして使っている。よく使うアプリにはHot Key(ショートカット)を割り当ててる。 Clipboar

いままでリバースプロキシの設定がよくわかっていなくて、すでに動いているサーバの設定を見よう見まねで使い回してきた。ちゃんと理解しようと思って、マニュアルを読み直したらやっとわかった。設定の方法 (How) がわかったこと以上に、なぜそう書く必要があるかという理由 (Why) を理解できたのが嬉しい。久しぶりに「わかった！」と叫びたくなった。感動を忘れないうちに、思い出せるように、書いておく。 mod_proxy - Apache HTTP サーバ バージョン 2.2 が Apache のプロキシ関連のマニュアル。 mod_proxy を使うことになる。 大事なディレクティブは、 ProxyPass と ProxyPassReverse のふたつ。 ProxyPass これがリバースプロキシをする上でのほとんどすべてのことをやってくれる。実は見慣れた (コピペし慣れた) 設定ではこのディレク

画像配信の負荷分散も比較的簡単？（その5）のつづき. 初めての方は画像配信の負荷分散も比較的簡単？（その1）からどうぞ. さて前置きが長くなったが,本題に入ろう. アクセスが特定の画像に集中した場合には問題が出ると思うのですが どのように対応したらよろしいでしょうか？ 例えばある画像が1枚某ブログにウプされて 2ちゃんのいろんなスレに画像への直リンクURLが貼り付けられて祭りになり 1台の画像鯖に負荷が集中しさばききれなくなった場合、 先生の方法ではいくら鯖を増設しても負荷は分散されないし アクセスが集中している画像鯖だけ別にDNATやmod_proxy+mod_rewriteとかその他の方法との併用で 負荷分散はできますけど祭りが起きるたびに毎回毎回特定鯖だけネットワークに手を加えるのも めんどくさいと思うのですがこの辺はどのようにしているのでしょうか？』 特定の画像のアクセスが多くなっ

画像配信の負荷分散も比較的簡単？（その4） のつづき. 初めての方は画像配信の負荷分散も比較的簡単？（その1）からどうぞ. 画像配信の負荷分散も比較的簡単？（その3）にて下記のようなコメントをいただいた. アクセスが特定の画像に集中した場合には問題が出ると思うのですが どのように対応したらよろしいでしょうか？ 例えばある画像が1枚某ブログにウプされて 2ちゃんのいろんなスレに画像への直リンクURLが貼り付けられて祭りになり 1台の画像鯖に負荷が集中しさばききれなくなった場合、 先生の方法ではいくら鯖を増設しても負荷は分散されないし アクセスが集中している画像鯖だけ別にDNATやmod_proxy+mod_rewriteとかその他の方法との併用で 負荷分散はできますけど祭りが起きるたびに毎回毎回特定鯖だけネットワークに手を加えるのも めんどくさいと思うのですがこの辺はどのようにしているのでし

http://d.hatena.ne.jp/yamaz/20060509の続き. 初めての方は画像配信の負荷分散も比較的簡単？（その1）からどうぞ. Googleはimages.google.com 1つで1,187,630,000(11.8億!)の画像を保持している(ように見える).1つの画像が10KBだったとしても12.5TBの画像を保持していることになる. GoogleがこんなことができてるのはGoogleFileSystemがあるからだ. http://labs.google.com/papers/gfs.html GoogleFileSystemは簡単に言うとデータバックアップ機能つきの分散NFSのようなものだ. GoogleFileSystemに関しては上記URLのPDFに詳しいので,そちらを参照してほしいが,基本的な考え方は今まで負荷分散の考え方となんら変ることはない.つまり

画像配信の負荷分散も比較的簡単？（その2）のつづき. 初めての方は画像配信の負荷分散も比較的簡単？（その1）からどうぞ. アクセス/保持データ量ともに多くなってきてどうにもならなくなったらどうするか?お金があるところはサーバを強化したりメモリを増やしたりするのも手だろう.ただもっと安上がりで効果的な方法がある. どうにかなるまで1台あたりのアクセス数と保持データ量を減らせばいいのだ. ずっこけた人がいるかもしれないけど,こっちは大真面目である(笑).別にアクセスが少なくなるまでサービスを縮小させろという意味ではないので,もうちょっと付き合っていただきたい. 下記のような仮想の実装例を考えてみよう. http://i.yimg.jp/images/search/head_050825.gif にアクセスがあったらURLを10で割ってその余りに応じて img0.yimg.jp img1.yim

http://d.hatena.ne.jp/yamaz/20060426 の続き.待ち行列理論に従うと遅延のないサービスを行うためには サーバの単位時間のリクエスト処理能力 > ユーザの単位時間のリクエスト数 という非常に単純なことを行えばいいことになる.「なにをあたりまえのことを...」と思われるかもしれないがもうちょっと付き合っていただきたい. ところでたいていのBlogや画像サービスのサービスURLはこうなってる. http://ホスト名/<ユーザ名>/ http://ホスト名/id?ユーザ名 http://ホスト名/ディレクトリ名/コンテンツ名 例で言うと下記のような感じだ. http://d.hatena.ne.jp/yamaz/ http://mixi.jp/show_friend.pl?id=128497 http://i.yimg.jp/images/search/head

http://d.hatena.ne.jp/naoya/20060407/1144376197 ではてなおやさんがYouTubeの負荷分散について語っておられる. mixiの負荷分散とは質が違うことについてはおおむね同意だけど, YouTube のシステムを見たときにその焦点になるのは、まず第一にネットワーク帯域。第二にストレージをどうしているかというところじゃないかなと思います。動画配信にリソースがいるポイントは、ネットワーク帯域とディスク I/O です。つまり YouTube の負荷分散で気になるところは * ネットワーク帯域 * ストレージ o 容量の管理 o 動画を格納しているストレージサーバーの I/O あたりです。 はちょっと踏み込み足りないなぁという印象なので書いておく.集合知.集合知. 動画配信は通常の画像配信と違って下記の特性を持つ. 画像のように1ページに複数個配信する

30万個ぐらいの静的ファイルを配信するサーバーの選び方 で静的な配信サーバに関することが述べられている. naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 ということらしい.書いてあることはすべて同意だけど, つい3ヶ月くらい前まで 平均15k×1万URL×50億httpアクセス/day 平均4KByte×100万URL×3億HTTPアクセス/day な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分