kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

Amazon Elastic Beanstalk で t2.micro で Rails をデプロイすると、gem install に失敗する件

Rails AWS Elastic Beanstalk

先に結論

原因

bundle install 時に メモリが不足が原因で native extension のビルドに失敗している

エラーメッセージ

An error occurred while installing nokogiri (1.6.8.1), and Bundler cannot
continue.
Make sure that `gem install nokogiri -v '1.6.8.1'` succeeds before bundling.

eb-activity.log

  Installing nokogiri 1.6.8.1 with native extensions

  Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

      current directory: /opt/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/nokogiri-1.6.8.1/ext/nokogiri
  /opt/rubies/ruby-2.3.1/bin/ruby -r ./siteconf20161205-3296-zuwti1.rb extconf.rb 
  Cannot allocate memory - /opt/rubies/ruby-2.3.1/bin/ruby -r ./siteconf20161205-3296-zuwti1.rb extconf.rb 2>&1

swap を大きくするとか回避する方法もあるけれど、お金を惜しんで手間を掛けるのは、PaaS の精神に反しているとおもったので、お金で解決

HerokuのDBにAmazon Elastic Beanstalkからアクセスする

AWS Elastic Beanstalk Rails heroku

これは何?

Herokuで運用しているアプリを、ふとAmazon Elastic Beanstalkに移行したくなった

けれど、軽く試すためだけのために、DBを移行するの大変

そんな時にお手軽に試す為の方法の記録

Heroku から DB の情報を取得する

heroku では、database.yml に接続するDBの情報を書かなくても良い感じに繋ぐけど、Amazon Elastic Beanstalk から heroku のDBに接続するためには、接続情報が必要

heroku config で調べる場合

$ heroku config

=== ***** Config Vars
DATABASE_URL:             postgres://#{username}:#{password}@#{hostname}:5432/#{db_name}

rails config で調べる場合

$ heroku run rails console

irb(main):001:0> ActiveRecord::Base.connection_config
=> {:adapter=>"postgresql", :pool=>5, :timeout=>5000, :database=>"*****", :username=>"*****", :password=>"*****", :port=>5432, :host=>"*****"}

それぞれ、出てきた情報をメモする

database.yml に設定を追記する

直接書くのはよろしくないので、以下のようにして、環境変数から値を取るようにする

production:
  <<: *default
  database: <%= ENV['DB_NAME'] %>
  username: <%= ENV['USERNAME'] %>
  password: <%= ENV['PASSWORD'] %>
  host: <%= ENV['HOSTNAME'] %>
  port: 5432

Elastic Beanstalk に環境変数を設定する

eb setenv DB_NAME=******
eb setenv USERNAME=******
eb setenv PASSWORD=******
eb setenv HOSTNAME=******.amazonaws.com

以上

slack に書かれた内容を Amazon Polly で読み上げてみた

AWS ruby

この記事は feedforce Advent Calendar 2016の6日目です!!

www.adventar.org

昨日は、tjinjin の ドラッカー風エクササイズをチームで試してみました でした

cross-black777.hatenablog.com

期待マネジメント大事ですね。 ウチのチームも一度やってみたら面白いかもしれないですね...

さて、実用的な記事はやってもらえたので、私の方は技術ネタでお茶を濁したいと思います!

Amazon Polly で遊ぼう!

先日の AWS re:Invent 2016 では、色々なサービスがローンチされてすごかったですね!

今日はその中から、音声読み上げサービスである Amazon Polly で遊んでみようと思います!

Amazon Polly ってなあに?

公式blogに詳しい解説がありました

Amazon Polly – 文章から音声へ、47の声と24の言語 | Amazon Web Services ブログ

特徴をかいつまむとだいたいこんな感じです

  • クラウド音声読み上げサービス
  • 今までの音声読み上げサービスよりも精度が高く、よりネイティブに近い発音なのが特徴
  • 毎月500万文字までは無料(!) 以降は1文字 $0.000004 生成される音声1分あたり$0.004

pollyコンソール で 簡単に試すことができるので、色々遊んでみると良いと思います。 主観ですが、今までの音声読み上げと比べるとだいぶ違和感が減ったなぁと感じました

既に sdk も使えるようですので、なにか面白い使いみちを考えてみましょう...

Amazon Polly の使い道を考える

slackの流れは追っておきたいけれど、そのために作業を中断するのはしたくない。そんな時ありませんか?

そんなときに、そう。読み上げてもらえば...!

でき上がったものがこちらになります

youtu.be

しくみ

ソースコード

こちらになります。 ruby で実装しています。また afplay を使っている関係上 macOS のみで動作します

github.com

ハマったポイント

APIを使ってslackのchannelのメッセージをリアルタイムに取得する方法が分からずにハマりました

  • slack の Real Time Messaging API には Bot 用のAPIキーが必要
  • Botが所属している channel のメッセージしか取れない
    • channel に呼ぶには Bot をメンションする

まとめ

入力した文章が読み上げられるってそれだけで結構楽しいですね!

半分ネタで作ってみたのですが、コンテキストスイッチを乱されずに情報が追えるので、あれ? 意外に実用度高くない...? などと思っているところです

参考リンク

明日は、フィードフォースボドゲ部部長 および 日本酒会会長 の kano-e の 「RailsエンジニアがFacebook広告を出稿してみた」です!

tech.feedforce.jp

Ad業界エンジニア必見!!! あと手書きのスライド資料が温かみがあって良い感じです!

負荷テストについて思ってることをポエムする

ポエム

色々知見が溜まってきたのでポエムします

言いたいこと

  • 「なにをもってゴールとするか?」の合意を取ろう
  • まず実測
  • 本番環境にできうる限り近い環境でやろう
  • 実測ツール紹介
  • 中央値も見よう

「なにをもってゴールとするか?」の合意を取ろう

やろうと思えばどこまでも高速化できてしまうので、最初に、なるべく実際の負荷に近いと思われる条件の元、 どんな条件で、どのような結果ならばOKか? の合意をチーム内で取りましょう

どんな条件での例

  • アクセス方法(どのページにどんな頻度でアクセスするか?なるべく実際のユーザの挙動に近いほうが良い
  • キャッシュの有無(厳密にやるならば、実際のキャッシュヒット率に近くなるようにやるべき。ページキャッシュやら、SQLキャッシュやら

どのような結果ならばOKか? の例

  • 限界テスト : 何アクセス数まで、サーバが落ちないこと
  • 性能テスト : 何アクセス数まで、平均レスポンスタイムがn秒以内であること

まず実測

計算上耐えられる負荷に耐えられることは100%無いです。 何かがボトルネックになって、計算上耐えられる負荷より前にサーバが悲鳴を上げます。本番でそれが起こると目もあてられないので、さっさと実測しましょう。 可能ならば、CIとかに組み込んでメトリクスを取ると更に良いです。

本番環境にできうる限り近い環境でやろう

可能ならば本番サーバでやるのが良いですが、無理ならば 可能な限り本番環境に環境を近づけて測定しましょう。 本番でだけproxyサーバを挟んでいる? それがボトルネックになって、本番環境だと負荷に耐えられないと思いましょう。 最近はAWSとか仮想環境に環境を構築している場合が多いと思うので、面倒臭がらずに同様の環境を1つ用意しましょう。あと、データも本番と同様にね!

実測ツール紹介

簡単に単一URLで負荷試験をしたい場合は、Apache Bench が楽に色々なデータが取れるのでオススメです。

複数URLで負荷試験したい場合は、apachebench-for-multi-url というツールも見つけましたが、自分は使わなかったので、誰か使ってみて下さい。

自分の場合は、色々制約や条件があったので、最終的にrubyで負荷ツールを自作しました。ただ、 自作ツールの場合、ツールそのものがボトルネックになる可能性も否定できない ので気をつけて下さい。

中央値も見よう

実測した結果を見てガッカリする前に、平均値だけでなく中央値も見てみましょう。

中央値 : 有限個のデータを小さい順に並べたとき中央に位置する値

平均値だけ高い場合と、中央値も平均値も高い場合とでは、対策が異なるので、平均値だけ見ていると無駄な努力をする羽目になります。

中央値も平均値も高い場合

  • 全体のレスポンスタイムを下げる施策が必要

平均値だけ高い場合

  • 特定のリクエストの場合のみ遅いのであれば、その原因を調査して取り除く
  • リクエスト数によってタイムアウトや待ちが発生している場所を探す

そんなかんじです。良き計測ライフを!

参考

自分の考えるリファクタリング指針

ポエム

なにこれ?

文書化して明確にしてみよう

目次

  1. 何故リファクタリングをするか?
  2. リファクタリングの優先順位
  3. 性能改善との兼ね合い
  4. どこまでリファクタリングすべきか?

1. 何故リファクタリングをするか?

  • 可読性を上げるため
    • 何故可読性を上げるか?
      • 品質を上げるため
      • 開発速度を上げるため
  • 可読性の高いコードの利点
    • バグを発見しやすい(品質up)
    • 不具合発覚時に修正がし易い(品質up)
    • 機能の追加がしやすい(開発速度up)
    • 再利用しやすい(開発速度up)

ぶっちゃけもう二度と機能追加/修正をしないコードはリファクタリングする必要はない

  • でもなんだかんだ手を入れる事になるんだよね...

2. リファクタリングの優先順位

テスト -> リファクタリング -> 機能追加

3. 性能改善との兼ね合い

  • 可読性を上げたために速度が遅くなった! なんてことはあんまりないので、そこまで気にしなくて良いと思う
    • 理想をいえばCIに性能計測を仕込んで、リファクタリング前後で計測できると良いのだけど...
  • リファクタリングと性能改善は別の作業なので、同時に行わない

4. どこまでリファクタリングすべきか?

個人的な指針なので異論はあると思う

自己満足のリファクタリングはしない

必要に応じたリファクタリングをすべき

リファクタリング前に問うこと

リファクタリングをすべきとき

  • 機能追加の前
    • 積極的にすべき
    • コードを理解するために
    • 追加すべきコードの量を減らすために(品質/生産性up)
  • 機能追加の後
    • コードレビュー時など
    • リファクタリングが行われる最後のチャンスと思っても良いかもしれない
  • 汚いコードを見つけた時
    • ただし、他の作業との優先度は兼ね合うべき
  • 性急な機能追加が一区切りついた時
    • 一区切りつく前に、生産性や品質について課題が発生している場合は絶対にやるべき
    • プロダクトオーナーに了承を取って、一定の期間をリファクタリングに費やす
      • これ以降の生産性や品質が上がります! という形で説得する
      • 課題感を共有できていれば説得できるはず

Serverspec本どくしょかんそうぶん

読書メモ serverspec

Serverspec

Serverspec

読書メモ

かんそう

  • set_property, property 大事
  • set で使える設定の一覧って、公式ドキュメントのどこにあるの?

作者のスタンス

  • テストを実行することに注力していて、どのサーバに行うとか、サーバ毎の違いを吸収するとかは自分でなんとかしてね!
    • その「自分でなんとかしてね」を実現するライブラリっていろいろありそうだけどどうなのだろう
  • 構成管理ツールとの連携はしない
    • サーバの構成のテストはするけど、構成管理ツールが正しく動作しているかは知らない
    • 構成管理ツールの設定をする人が間違えていないか? 意図しない変更を発生させていないか? を保証する

課題

  • linux系で理解が足りていないことが多い
  • Infratasrer, test kitchen 気になる
  • consul 理解が足りていない
  • Dockerも手を付けたい

【持ってきてよかったもの】4泊6日のオーストラリア旅行に行って【持っていった方がよかったもの】

家庭の用事で4泊6日のオーストラリア旅行に行ってきました

次回の備忘のために、持ってきてよかったものと、持って行ったほうが良かったものを記します

良かったもの

ファーストクラスラウンジのチケット

  • ヤフオクで1枚3500円程度で購入
  • ラウンジ以外に、ちょっとしたレストランでディナーが食べれる
  • 親同伴だったので、ちょっとした親孝行風ができて良かったw
  • ラウンジチケットを見せる前に、エコノミーの航空券を提出したら「お前のラウンジはここじゃねえよ」と遠回しに言われて悲しかった...

SIMフリーのモバイルルータ

  • 海外で気兼ねなくネットができるのはすごく良い!
  • GL04Pをジモティーにて5000円弱で購入
  • SIMはOptusを使用。設定方法はSIMが梱包されている紙に書いてある
  • 1日2$で500MBまでのプランがあると、いくつかのblogにあったが、見つけられず(&尋ねても不明だった)
  • 仕方なく1G/10$のプランを選ぶが、何かしらのソフトウェアアップデートが起動し、600M近くを浪費...
  • その後、追加で3G(30$)を購入
  • SMSを使った残額確認や、持ち歩く機器が1個減るので、可能ならSIMフリーのスマートフォンの方が便利

モバイルバッテリー

  • モバイルルータと、iPhoneが1日出歩いてると持たないので必須
  • 多少重くても大容量であればあるだけ良いと思っている
  • 自分は、Anker Astro M3 13000mAhを使用中

iPhone (google Maps!)

  • バス乗車時、目的地と現在地が一発で判断できるのは精神にとても良い
  • 公共交通機関が発達している街の場合、ルート検索がとても便利!
  • ホテルまで迷わず到着
  • あと、現在地の近くの観光地やレストランを一覧表示してくれる機能を初めて知った...

ゴミ袋

  • 100円ショップの20枚位入っているものを1袋
  • 何かと使いみちが
  • 飛行機内等でゴミ袋に
  • 着終わった服入れに
  • おみやげ入れに
  • まるめて割れ物のガードに

歯ブラシ

  • 飛行機に持ち込んで寝る前に使用
  • 後海外のホテルでは大抵歯ブラシが無いので注意!

100円ショップの物干し

  • 靴下や下着は最低限持って行って、洗面台で洗濯して干した
  • あと寝る前にジーンズを干しておくと、後日履くときに少しさっぱり

(シドニー限定)Operlカード

  • suica的なプリペイドSIM
  • 電車、バス、路面電車、フェリーがこれ1枚
  • 駅近くのお店でタダで貰えて、その場でデポジット可能(最低10$
  • 料金キャップ制なのでお得
    • 平日15$、休日2.5$!
    • 空港に電車で行くときは、空港税が別料金
  • 時間によってはバスはOperlカード限定らしい

持ってくれば良かったと思ったもの

スリッパ

  • 機内、ホテル(備え付けが無かった!) であると便利
  • シャワーの後も履くので、サンダル的なものの方がよいかも

給電可能なusbハブ

  • 変換プラグ2個では足りず
  • モバイルルータとモバイルバッテリーと、iPhoneをまとめて充電したかった

長めのUSBケーブル

  • 飛行機の充電ポートが大体変な位置にあるので長いほうが便利

英語力(だいじ

そんな感じでした