iOS/Androidでアプリの申請を自動化できるツール:fastlane

fastlane は、iOS と Android アプリケーションのリリースをするためのツールです。スクリーンショットの生成や電子署名、アプリケーションのリリースなどのタスクをすべて自動化できます。

  • Storeへの新しいリリースの提出、ベータテストの準備にかかる時間を削減します
  • 既存のツールやサービスに統合できます(170アクションが準備済み)
  • MITライセンスで100%オープンソース
  • 数分の準備できる簡単セットアップアシスタント
  • 自分のマシン上で実行できる
  • 全てのメジャーなCIシステムと統合できる
  • iOS、Mac、Androidアプリケーションをサポートしてます
  • 必要に応じてfastlaneを拡張、カスタマイズでき、他の何も依存しません
  • 多くのコマンドを覚える必要はなく、fastlane のみです
  • CIサーバーなどあらゆるコンピューターからデプロイできます

続きを読む “iOS/Androidでアプリの申請を自動化できるツール:fastlane” >

Googleの知見:リトライ処理間隔と優先順位付け

Google Cloud Platform Blog に投稿された「自業自得の DDoS 攻撃から身を守るには : CRE が現場で学んだこと」が興味深く示唆に富む内容でした。
アプリケーションサーバーとアプリ間の通信の負荷分散と、接続エラー時のリトライ処理間隔をどのように設計すべきかというお話です。

  • リトライ感覚を指数的に増やす:1分、2分、4分、16分
  • ジッターを追加する:リトライ間隔をばらすために1分(20%)のランダム秒を追加する
  • リトライ回数で優先順位をつける
  • リトライと通常接続を分けて処理する。通常処理90%、リトライ10%などで正常性復帰を優先する

スライド抜粋:Dockerのコンテナーを大量運用されている方のトラブル話

@sumyapp さんが公開されている「毎日2000個のコンテナをstartする鯖が突然死して僕が驚愕した話」が興味深かったので一部抜粋。

  • Devicemapper を私用しているとディスクがフルじゃないのに、「Docker disk out of space」のエラーが出る
  • Linuxのカーネルバージョンによっては、カーネルパニックを起こして死ぬことがある
    あるタイミングのGoogle Cloud PlatformのKernel version:3.16.0-38-generic で現象が発生し、
    3.13-0-48-generic なら発生しない。

CIサービスの提供をされている方で、CIの実行環境としてアプリからDockerを一日に2000回ぐらい起動して、つぶしてとヘビーにコンテナーをプロダクションで使用されている方の実体験でした。この辺りは、実運用してみないと見えてこない問題なので、情報公開していただけると、すごく参考になりますね。

「CloudSQL 2nd Generation性能評価」の補足

元同僚が書いた「CloudSQL 2nd Generation性能評価」でいくつか疑問形になっていたので、面白がって調べてみたので捕捉したいと思います。

場所

データベースを作成時に、作成場所を選択します。

image

「すべて」という選択肢があります。

説明文に、「データの地域とゾーンを選択します。選択しない場合、ゾーンは「すべて」となり、Cloud SQL によって自動的に選択されます。」と解説があります。

「すべて」を選択すると、地域内にあるゾーンから1つをGoogle側のロジックで選択して、データベースインスタンスを作成してくれるようです。

メンテナンスの時間枠

image

メンテナンスの時間枠は、「メンテナンス時間内にインスタンスが自動的にシャットダウンし、再起動され、アップデートが適用されます。運用環境の更新は、数か月に一度ほどの割合で行われます。」と記載があります。

曜日を選択すると、時間を選択できるようになります。これはUIがちょっと微妙かもしれませんね。

image

ちなみにこのUIに気付いたのは、公式ドキュメントの説明に、「The day and hour when updates to this Cloud SQL instance can be made. 」と記載があったからです。hour選べないじゃん!と思ったけど、まさかね……と思いつつ選んだら、時間選択ウィンドウが表示された(;´・ω・)

メンテナンスは、指定した日時内で基本的には数分で完了します。
ただし、「The restart is not guaranteed to complete before the end of the maintenance window」と記載があるので再起動はメンテナンスウィンドウ内で実行するけど、再起動がこの時間内に完了することを保証してないようです。

料金

Google Cloud料金計算ツール」と頭を突き合わせて調べてみました。

Compute

これは、「インスタンス料金」に記載されているとおりです。利用時間に応じてディスカウントが入るので、実際にいくらディスカウントされるかは計算ツールで確認しましょう。

ちなみに1ヶ月フルに使って、db-f1-microだと次のディスカウントです。

image

(例)0.015ドル/時間×730時間ー0.55-1.09-1.10=7.67ドル/月

リードレプリカ(フェールオーバーレプリカ / High Availability)

これは、作成時にはまったく同じComputeインスタンスが設定されるようなので、お料金は単純に倍。

参考:How configuring an instance for high availability affects your charges

(例)7.67ドル/月×2=15.34ドル/月

ストレージ料金

ストレージ料金」に記載がある通り。

SSDだと、月1GBで0.17ドル。

バックアップ料金

月0.08ドル

フェイルオーバーレプリカ

MySQLの準同期レプリケーションで、オリジナル(Master)とは異なるゾーンにレプリケーションをします。

Masterが置いてあるゾーンが機能停止した場合、Cloud SQLは自動的にフェイルオーバーレプリカにフェイルオーバーし、クライアントへのデータ提供を継続します。First世代では組み込み機能でしたが、Second世代では開発環境のコストを減らせるように、high availabilityオプションとして提供します。

フィルオーバーすると、インスタンスに接続している既存コネクションは切断されます。同じ文字列またはIPアドレスを使用して再接続できるので、フィルオーバーが発生してもアプリケーションを変更せずにすみます。

フェイルオーバーすると、Masterに昇格し、自動的にほかのゾーンに新しいフェイルオーバーレプリカを作成します。

フェイルオーバーレプリカは、マスターからリード操作を減らすために、リードレプリカとして使用できます。フェイルオーバーレプリカは、データベース毎に1つだけ作成できます。さらに追加でリードレプリカを追加できます。ただし、リードレプリカはフェイルオーバーできるようにはなっていません。

レプリカのインスタンスサイズ

インスタンス作成後のレプリカタブで作成できます。

image

リードレプリカは、次のように自由にインスタンスサイズを設定できます。

image

しかい、フェイルオーバーレプリカは、Masterと同じインスタンスサイズが自動的に設定され変更はできない用です。

メンテナンス

https://cloud.google.com/sql/faq#maintenancerestart

We recommend that you design your applications to deal with situations when your instance is not accessible for short periods of time, such as in a maintenance shutdown.

てことで、ちょっとの時間アクセスできないぐらいで停止しないようにアプリケーション設計することを推奨だ!てことですね。メール連絡などについては特に言及なし。

Linuxのファイルディスクリプタ―に関するメモ

ファイルディスクリプタ―は、ある程度の負荷があるWebサイトを運用すると遭遇する問題です。

エラーログなどに「Too many open files」と記録されて、正常に動作しない状態に遭遇するのがLinuxのファイルディスクリプタ―です。
これに対応しようと思って、googleで検索すると、いろいろ記事が出てくるけど、知りたいことズバリと答えてくれる記事がなかなかヒットしない。

ulimit や /etc/security/limits.conf について案内されているけど、反映されないケースがあって、/etc/init.d/の起動スクリプトにも書けetcなどと。

結論

nginx や mysql などのミドルウェアであれば、それぞれのconfigファイル内で定義することで設定をきかせることが可能。

nginx

worker_rlimit_nofileで設定する。ワーカプロセスが開くファイル数の最大限界値(RLIMIT_NOFILE)を変更します。RLIMIT_NOFILEは、プロセスが開くことができるファイルディスクリプタ―数を指定するものです。

worker_rlimit_nofile 10240;

mysql

open_files_limitで設定する。オペレーティングシステムで mysqld が開くことを許可するファイル数。実際の open_files_limit の値は、システム起動時に指定された値 (ある場合) と、max_connections および table_open_cache の値に基づき、式を使用します。

[mysqld_safe]
open_files_limit = 8192

Linux全体

OS全体のファイルディスクリプタ―数は、「/etc/sysctl.conf」で設定する。

設定されている値の確認
cat /proc/sys/fs/file-nr

設定値
fs.file-max = 1232457

参考

外道父の匠:ulimitが効かない不安を無くす設定