AR ホームベーカリー

オイラのアウトプット用ホームベーカリー!

Go のインストール

Go なのか Golang なんかどっちなんね。

ロケ地:EC2 t2.micro ( CentOS7 )

インストール

ダウンロード

# cd /usr/local/src
# wget https://storage.googleapis.com/golang/go1.7.3.linux-amd64.tar.gz

展開

# tar -xzvf go1.7.3.linux-amd64.tar.gz
# mv ./go/ /usr/local/bin/

環境変数の登録

# mkdir ~/.go/
# vi ~/.bash_profile

環境に併せて書き換えてください。 今回 $GOPATH ( go get とかするとインストールされる先)は ~/.go/ としています。

GOPATH=$HOME/.go
GOROOT=/usr/local/bin/go
PATH=$PATH:$HOME/bin:$GOPATH/bin:$GOROOT/bin

export GOPATH
export GOROOT
export PAATH

環境変数の反映

# source
# go version
go version go1.7.3 linux/amd64

ちゃーんと go version〜〜 が出力されたらオッケーです! warning も出てないので、go get も使えるはずです!

gox インストール

せっかくなので、gox をインストールしてみます。

インストール

# go get github.com/mitchellh/gox
# which gox
/root/.go/bin/gox

わぁぃ。

AWS CLI でルートテーブルのつけかえ

c9katayama.hatenablog.com

おっできるんか!と思ってまず aws コマンドから、ルーティングの変更を試すことに。

削除

aws ec2 delete-route --route-table-id ルートテーブルID --destination-cidr-block 送信先
  • ルートテーブル ID
    • VPC ダッシュボードから確認出来るルートテーブルの ID
  • 送信先
    • IP/CIDR 形式、ルートテーブルを選択したあと、「ルート」タブから確認する

http://docs.aws.amazon.com/cli/latest/reference/ec2/delete-route.html

追加

aws ec2 create-route --route-table-id ルートテーブルID --destination-cidr-block 送信先 --network-interface-id ターゲット
  • ルートテーブル ID
    • VPC ダッシュボードから確認出来るルートテーブルの ID
  • 送信先
    • IP/CIDR 形式、ルートテーブルを選択したあと、「ルート」タブから確認する
  • ターゲット
    • eni- から始まる Elastic Network Interface
    • --gateway-id や --instance-id を指定するとそれらを対象にできるようですね

http://docs.aws.amazon.com/cli/latest/reference/ec2/create-route.html

なんで

なんで削除も return 返してくれないのか。

CPAN のダウンロード先が国外を向いてる

めっちゃダウンロード遅くてなにこれ、と思ってよくみたら「.au」とかいうドメインだった。オーストラリアやんけ!

国内なら公式のミラーリストにある「http://ftp.nara.wide.ad.jp/pub/CPAN/」を登録しておけばいいと思います!

登録されているミラー一覧

CPAN[1]> o conf urllist 

一覧から削除

CPAN[1]> o conf urllist pop URL

一覧に追加

CPAN[1]> o conf urllist push URL

作業内容を反映する

CPAN[1]> o conf commit

マルチバイトのダミーデータを作る

ダウンロードする。

なんちゃって個人情報

CSV → INSERT文に変換する。

CSV→INSERT文変換

適当な RDBMS で食べる。

UTF8 の設定忘れてて読み込めない(ここまでワンセット)。

AWSで新たなVPCを作る時

めっちゃ忘れまくってたのでメモ。

プライベートIPアドレスの帯域

  • クラスA
  • 10.0.0.0~10.255.255.255 ( 10.0.0.0/8 )
  • クラスB
  • 172.16.0.0~172.31.255.255 ( 172.16.0.0/12 )
  • クラスC
  • 192.168.0.0~192.168.255.255 ( 192.168.0.0/16 )

VPN を乗り入れたりしない場合は、特に深く考える必要はない。 が、後々そういうことが微粒子レベルでも存在してるならクラスCはなるべく使わないほうがいい、事故りやすい。

VPC ・サブネットの作成

適当に作ってもおk、名前はわかるようにしておこう。 VPC の CIDR ブロックを /23 にしておくとサブネット作成時にわかりやすい。

作成例

CIDR ブロックは 10.1.0.0/23

ap-northeast-1a

  • 10.1.0.0/24
  • サブネット名:ほんにゃかふんにゃか-1a

ap-northeast-1c

  • 10.1.1.0/24
  • サブネット名:ほげふが-1c

もちろんもっと IP アサインしたい環境の場合は増やしていい。 テナンシーは普通は専有しなくておk。

インターネットゲートウェイ・ルートテーブル作成

VPC とサブネット作ったままだと、EC2 インスタンス作成時に割当は出来るけど、ルートがなくてインターネット経由で接続できない。 インターネットゲートウェイを適当な名前で作成して、ルートテーブルの「ルート」タブから 0.0.0.0/0 を割り当てる。 デフォルトの VPC と見比べると良いと思います。

ここまでの作業だと、EC2 インスタンスにパブリック DNS が付与されない

VPC 作成後に「DNS ホスト名:いいえ」のままインスタンスを作成すると付与されない模様。 DNS ホスト名を「はい」に変更すれば利用できるようになるらしい。 どうせなので ElasticIP を割り当ててしまったほうが良いと思っている。

S3のパフォーマンスの考慮

大体以下の値に達するまでには、何も考えずに適当に使っても大丈夫っぽい。

  • 毎秒 100 回の PUT/LIST/DELETE リクエスト
  • 毎秒 300 回の GET リクエスト

これを超えるような場合は、3〜4文字程度のランダムな値を付与したプレフィクスをつけたり、CloudFrontを導入しろ、ってことらしい。

docs.aws.amazon.com

1秒あたりのリクエスト数が30〜40すると一ヶ月(30日)で大体1億リクエストになるので、毎秒100回のリクエストだと、一ヶ月(30日)で3億リクエストぐらいまでは、何も考えなくてもS3だけでさばける計算になりますね。 これを超えたらCloudFront配置する、と考えたらよさそう。

RDSをスケールアップする

スケールアップ(上のプラン)にしたいとき。

docs.aws.amazon.com

m3.db.mediumからm3.db.largeにスケールアップしたけど20分かからないくらいだったよ。 ストレージは40Gbyte設定してました。