AWS AutoScaling group のインスタンス一覧を ruby で取得する

Oct 7, 2015

require 'aws-sdk-v1'

AWS::config(
  access_key_id: 'xxxxxxxxxxxxxxxxxxx',
  secret_access_key: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
  region: 'ap-northeast-1',
)

auto_scaling = AWS::AutoScaling.new

instance_ids = auto_scaling.groups['staging_web'].auto_scaling_instances.map(&:instance_id).to_a

response = AWS::EC2::Client.new.describe_instances instance_ids:instance_ids
for reservation in response[:reservation_set]
  for instance in reservation[:instances_set]
    puts instance[:dns_name]
  end
end

Kickstarter がベネフィットコーポレーションに

Sep 22, 2015

Kickstarter がベネフィット・コーポレーション（Benefit Corporation）になりました。Benefit Corporation は、日本語で公益法人と訳すこともできますが、概念が違うため、ベネフィット・コーポレーションと呼ぶほうが良いでしょう。

これはアメリカの州法で制定されている法人形態で、2010年にメリーランド州で制定されたのを皮切りに、2015年9月現在では31の州で制定済み、5つの州で制定作業中です。アメリカでは、今、ベネフィットコーポレーションを設立する動きが増えています。

アメリカの営利企業は、株主の利益を最大化することを目的としています。その結果、金銭的な関わりのないステークホルダーに対する貢献がしにくくなっています。公益を果たそうとすれば、どうしても株主利益を毀損しがちになります。従来の CSR は、企業市民として、利益を追求する以前に、社会の中で良き市民であるべきという考え方をしていました。 ベネフィット・コーポレーションは、CSR の先を目指す企業形態で、利益と社会貢献の両方を追求する営利企業です。

典型的には、既存企業をベネフィットコーポレーションに転換するには、株主の議決権の2/3以上の同意が必要です。企業のミッションを決め、定款に定め、株主が同意します。経営者が何か判断を下すときには、そのミッションに基づき決定します。株主利益に反する決断をしても、株主から訴訟を起こされることはありません。

一方、日本の公益法人は、税制優遇を受けるための制度です。まず、一般社団法人、一般財団法人、特定非営利活動法人（NPO法人）のいずれかを設立します。これらの法人が、内閣府、都道府県、政令指定都市などから公益認定を受けると、公益社団法人、公益財団法人、認定特定非営利活動法人（認定NPO法人）になります。

株主訴訟を受けずに公益を果たすためのアメリカのベネフィット・コーポレーションと、税制優遇を受けるための日本の公益法人。制度が生まれる基本的な動機が違っているといえるでしょう。

Kickstarter のベネフィット・コーポレーションとしての憲章（https://www.kickstarter.com/charter）には、毎年2.5%の税引き後利益を芸術や音楽へ、同じく2.5%の税引き後利益を不平等への戦いに寄付すると宣言しています。株主の前で、堂々とこういうことができるのがベネフィット・コーポレーションの魅力です。

Ashley Madison のクレジットカードブランド比率

Sep 5, 2015

> library(RMySQL)
> con <- dbConnect(MySQL(), dbname='creditcard', user='********', password='********')
> rs <- dbSendQuery(con, 'select * from creditcard_transactions')
> data <- fetch(rs, n=-1)
> nrow(data)
[1] 9685921

> data$brand <- factor(data$brand)
> summary(data$brand)
     AM      DC      DI ERROR_B      JC      LA      MC      MD       N    null      SW      VD 
1034597     573  260283      23    4021       5 2721562    2827       2   39012       1     250 
     VE      VI    NA's 
  22914 5599849       2 

> fac_levels = levels(data$brand)
> fac_levels
 [1] "AM"      "DC"      "DI"      "ERROR_B" "JC"      "LA"      "MC"      "MD"      "N"      
 [10] "null"    "SW"      "VD"      "VE"      "VI"     

> o <- order(table(data$brand), decreasing=TRUE)
> data$brand_fac <- with(data, factor(brand, levels=fac_levels[o]))

> summary(data$brand_fac)
     VI      MC      AM      DI    null      VE      JC      MD      DC      VD ERROR_B      LA 
5599849 2721562 1034597  260283   39012   22914    4021    2827     573     250      23       5 
      N      SW    NA's 
      2       1       2 

> options(scipen=5)
> barplot(table(data$brand_fac))

Credit card brands ratio

続きを読む

Passenger が高負荷時に 503 Server Temporarily Unavailable を返すとき

Sep 1, 2015

Apache + Passenger で運用している Rails のサービスにアクセスが集中し、503 Server Temporarily Unavailable が出るようになった。まずはサービスを数分止めてでも復旧させようと、2倍の性能を持つインスタンスに変更してみた。が、それでは足りず。結局、元の8倍の性能を持つ（と思われる）インスタンスに変更して、なんとか画面が表示されるようになった。ELB や autoscale は導入していないサービスなので、インフラ的にはこれが最も手っ取り早かった。

復活はしたものの、じりじりと遅くなっていく感じがする。まずい。すると同僚が「PassengerMaxRequestQueueSize っていうパラメタがあるよ」と教えてくれた。標準的な conf には書かれておらず、設定されていないときのデフォルト値は 100。これは、処理しきれないリクエストをいくつまでキューに貯めておくかという値。100 で足りなきゃ 500 にしてみよう。

症状は良くなったものの、まだ足りない。とはいえサービスは遅いながらも動いているので、いろいろ調べる余裕ができてきた。passenger.conf をじっと見る。そこで目に止まったのが PassengerMaxInstancesPerApp 4 という設定。これって、アプリケーションあたりの passengerプロセスが 4個までってことだ。それじゃ全然足りない。20にしてみた。

すると、劇的に軽くなった。これか！ 今回のケースでは、PassengerMaxPoolSize を大きくすれば、PassengerMaxRequestQueueSize を増やすのは必要なかったかもしれない。キューに入れるというのは、どちらにしても待たせることになるのだから、処理しきれないリクエストを500も抱えても嬉しくない気がする。

AWS Startup Tech 夏のLT大会 at dots.

Sep 1, 2015

http://eventdots.jp/event/567770

Schoo 岩田さん

  • オンプレミスで始めた。
  • RDS read replicat は DNS round robin.
  • 画像サイズの変更は ngix で変換して cloudfront でキャッシュ。
  • バッチは SQS。授業コンテンツの画像変換、メール送信、ランキング。それぞれのサーバが cron で処理を投げる。処理を投げるだけ。SQS が受け取る。スケールさせやすいのではないか。

vivit 小川さん

  • Vue.js採用
  • AWSクレジットをもらったので贅沢な構成にしていたが、クレジットが切れたので、運用費と可用性を天秤に掛けて、お金を取った。今は最小構成で動かしている。

トランスリミット 松下さん

  • スマホアプリ：Brain Dots
  • オフライン前提、可能な限りサーバレス、シェア機能を充実
  • ダウンロードした状態で基本的に全てプレイできる。
  • イベントなど必要なときだけサーバを用意
  • Google Play Saved Games, iCloud KVS でユーザデータを保持。かなり低コスト。
  • デバイスの言語ではなく、アプリ内で言語を切り替えられる。
  • グローバル対応：プッシュ通知を Timezone ベースに。
  • プレイ動画の共有 everyplay を使っている
  • ゲームプラットフォームのログインを推奨。
続きを読む