Galapagos Tech Blog

株式会社ガラパゴスのメンバーによる技術ブログです。

Sidekiqのプロセスをキューで分ける

ご機嫌よう、ガラパゴスのおとめです。

突然ですがRailsをお使いの皆さんは非同期処理にSidekiqを使ったりしていると思います。それで普通にデプロイするとSidekiqは1プロセスになりますね? 今回はかあるく短く、Sidekiqプロセスを複数にしたいなあ、というお話をしようと思います。

都合によりちょっと記事中のバージョンが古いですがご了承くださいね。

どうして複数プロセスにしたいの?

アプリケーションサーバーも非同期処理も全部一台で動かしているならSidekiqは1プロセスでもいいですが、多くの場合はサーバーを分けたりしているかと思います。

ところで、今時のサーバーならマルチコアですね? でも、1プロセスで動かしている限り、1コアしか使われません。当然ながら他の資源は無駄になります。

また、Rubyのマルチスレッドモデルでは、ブロッキングIOが発生しない限りコンテキストが切り替わりませんので、一つのワーカーで計算ばかり重い処理をしていると、他のワーカーが動かないといったことも起こります。

いやん。

もちろんコンテナで動かすとか資源を有効に活用する方法は他にもあるのですが、ここではとりあえず簡単にすぐにできる方法を試してみましょう。

複数のSidekiqを起動してみる

では、試しに複数起動しちゃってみましょう。必要な設定とかは書いてあるとして。

$ bundle exec sidekiq -C config/sidekiq.yml -L log/sidekiq1.log -d
$ bundle exec sidekiq -C config/sidekiq.yml -L log/sidekiq2.log -d

するとこのように、無事に複数起動するかと思います。

$ ps aux | grep sidekiq
otome  2383   0.0  0.0  4277992    908 s001  S+    9:09AM   0:00.00 grep sidekiq
otome  2377   0.0  1.2  4546588 204840   ??  S     9:09AM   0:09.43 sidekiq 4.0.2 sidekiq-test [0 of 10 busy]
otome  2109   0.0  1.8  4659228 296080   ??  S     9:09AM   0:13.17 sidekiq 4.0.2 sidekiq-test [0 of 10 busy]

もちろん、設定ファイルを分けることで、プロセスによって処理するキューを分けたりワーカー数を変更したりすることもできます。

例えば一方のプロセスで foo キューを処理して、

:pidfile: ./tmp/pids/sidekiq1.pid
:logfile: ./log/sidekiq1.log
:queues:
  - foo

別のプロセスで bar キューを処理するとします。

:pidfile: ./tmp/pids/sidekiq2.pid
:logfile: ./log/sidekiq2.log
:queues:
  - bar

あとはこれを引数に与えるだけですね。

どうやってデプロイするのん?

さて、では本番的な環境に適用しましょう。

大抵の場合はRailsアプリケーションのデプロイにはcapistranoを使われているかと思います。Sidekiqのデプロイにはcapistrano-sidekiqをお使いでしょう。

READMEを眺めてみると「なるほど???」という感じもしますが、例えば以下のようにすることで、複数のプロセスを異なる設定ファイルで起動することができます。

set :sidekiq_processes, 2
set :sidekiq_options_per_process, [
  "--logfile #{release_path}/log/sidekiq1.log --config #{release_path}/config/sidekiq1.yml",
  "--logfile #{release_path}/log/sidekiq2.log --config #{release_path}/config/sidekiq2.yml"
]

もちろんconfigに与える設定ファイルを同じにすれば、同じ設定ファイルで動きます。

早速デプロイしてみると、無事にSidekiqプロセスが複数になっているかと思います。


ところでガラパゴスではエンジニアを募集しています。ご興味をお持ちの方はぜひ弊社の採用ページをご覧ください。

www.glpgs.com

では、ご機嫌よう。

--

この記事は業務の一環として業務時間中に書きました

(完) テスコン(テスト設計コンテスト)2018 決勝戦いってきた

みなさまこんにちは!!テストチームとのの(@tonono2587)です。
前回前々回 に引き続き、完結編としてOPENクラスの振り返りをしていきます!!

gtech.hatenablog.com

gtech.hatenablog.com

OPENクラス 参加チーム

OPENクラスも5チームでの闘いでした。(発表順)

  1. タニタガワー6
  2. 紙印テスト倶楽部
  3. イイてすと
  4. ふわパン
  5. てすにゃんV3

個人的にはタニタガワー6のプレゼンききやすくて好きでした。
ふわパンさんのチーム名の由来聞きました?(チームメンバーの体型が)ふわふわ+パンダ って言ってましたよ?!めちゃくちゃかわいい!!!!!(好き!!)

結果

内容が入ってこなくてすみません。結果は以下です。

【優勝】てすにゃんV3 【準優勝】ふわパン

おめでとうございます!

ASTER-テスト設計コンテスト'18-OPENクラス 決勝戦

講評/総評でどんな感じだったのか振り返ります。

講評

タニタガワー6】

  • USAを提唱
  • 「かっこいい」と自分たちで言っていた
  • シンプルでわかりやすいと思います。
  • なぜ4つでいいのか、なぜそれがでてきたのか、を詰めていくとよいのでは

【紙印テスト倶楽部】

  • テストの取り組みは受け身になりがちだが、今回の発表は能動的にテストから仕掛けていく取り組みが内包されていてよかった
  • いままでの経験を積み重ねている
  • 最多出場で必ず*1決勝に残っている(すごい)

  • 継続する力がすごいし、しかも毎年新しいことを仕掛けている

  • アウトプットするし、たくさんの人に知らせている姿勢◯
  • そのフィードバックを次につなげる循環がよい◯

【イイてすと】

  • 特別枠だった、予選からレベルアップしていた
  • 業務フロー業務分析*2につかったりするものをテストにつかう
  • 見える化する」ことが大事
  • あれ自体が業務フローをあらわすものなので、それをテストに適応させていきたい
  • 質疑応答タイムで言っていた「テストに適用できると証明したい!」という熱い思いをはじめからだしたほうがよかった

【ふわパン】

  • 他チームが新しい技を出してきた中で、普通のテスト設計をしてきた
  • それがちゃんとできていた
  • こういうテストありだよな~と思った
  • オーソドックスにテストしていて、メンバーにこういう人がいたら安心できる内容だった
  • この基本は守って向上していってほしい
  • ただ、「言葉」(用語)が方言っぽくなっている (テスト技法→テストタイプ、テストポイント→テスト条件、など)
  • 非機能テストからやる→やっていることは王道だが表現が違った
  • 可視化して説明してほしい

【てすにゃんV3】
(すみません、てすにゃんの講評ありました?聴き逃してしまいました 汗) どんな内容だったかだけメモ載せときます

  • 製品のリリースを止めるバグを許容範囲までなくす
  • bugspots(よみ:バグスポッツ)を利用
  • 製品のリリースを止める事象およびバグをどう特定するか
  • フォルトツリーズを用いた事象の分解
  • テストで対処する/しない事象はどのように決めるか →被害金額とリスク値から決める
  • 対処するためにどんなテストをどのくらいやるか? →テストタイプのリスク低減表による許容範囲の調節

f:id:glpgsinc:20180227204505p:plain:w300 にゃ~

総評

  • テスコンがはじまってから2、3年はテスコンの次の活動がなかった。 いまは審査員になったり、次の活動に繋がったりしている
  • 卒業して、より広い活動、レベルの高い活動へ>次の世代が同じように追いかけていく→全体が右肩上がりしている

  • 審査員はフェアにみている →だれがつくったかは全く気にしないで成果物をみて、審査している

  • ひろくみて、いろんな関係をフラットにみて、だんだん落とし込む王道をいったのがふわパン

  • それは関係をモデリングして、落とし込んでいって…→これは難しいこと
  • 他4チームは何かほかの考え方に寄せている→こうすれば考えるのが楽になるのでは?
  • 考え方の違いなのでどっちがいいとかはない
  • (例えば円柱があったとして、)円をモデリング>長方形をモデリング>… 全部捉えようとしてしまったら扱いきれなくなってしまう
  • トレードオフですね
  • ほとんどのチームが何かに寄せて安心してしまったので点数が拮抗していた
  • 全部捉えようとしてしまったらほうは、扱いきれなくなってしまっていた感じ

  • 表せるものはなにで表せないものは何で、を理解した上でケースに落とし込む →その理解をどっち側からやるかが問題

  • 模範解答はない

  • 正解はない。100点の成果物はつくりようがない

  • 業務だと納期があり、深く深く考えるには限界がある

  • 一方テスコンは仕事の納期に比べれば考え抜く余裕がある
  • 考え抜いたものを見せてください!
  • テストとは何か考えたり

  • プレゼンがみんな似ているのでおもしろくない〜

  • 独自のプレゼンテーション がみたい!
  • 型ができて「型通りやると決勝いける」みたいになってきたらつまらないよね。

感想

  • 「USA」について、ユーザーストーリーマッピングがベースのテストということで、どんなテストをするのかわかりやすかった気がします。
  • 一方で、それで足りているかとか、安心かどうかを考えるにはプレゼン時間はあっという間すぎてついていけませんでした(´・_・`)話がわかるようになってきたらそこまで考えられるのかな。。
  • 紙印テスト倶楽部の、テストを考える前に仕様(テストベース)に対してフィードバックをする方法はすごくしっくりきました。
  • 「テストベースをテスト設計成果物へ変換する」ところで、いま知識が足りなかったりもやったりしているような気がする
  • bugspots、知らなかったのでぐぐりました

SHANON Engineer's Blog: Google のバグ予測アルゴリズムと bugspots の導入

  • コードに手を加えられているところほどあやしい、からそこを狙え、ということでしょうか?
  • ぐーぐる先生が言うなら信用できる!みたいなイメージをもちました
  • 正解がないぶん考えたなりに自信をもって「こうやって正解出しました!」と言えないと大人はうんと言わないですよね。がんばりどころのヒントになりそうです。

もやもや晴れた?

前々回で整理した、わたしのもやもやは。。

  • 考えた内容(設計)がうまく表現できない
  • 伝わるもっといい書き表し方があるはずだ
  • テスト分析してるけどなんか足りてないかもという不安感
  • テスト分析にはもっといい方法があるのでは?!

→聴講を通してヒントはあったように思います!

  • 全体を捉えるような視点で振り返るとよさそう
  • 何かに寄せて考えてみたり、全体から落とし込んでいったり、やり方がいろいろある
  • レベリング

昨年決勝戦にきたときは、正直ほとんど話についていけず、成果物の展示をみても 「字がいっぱい〜。。。」くらいにしか思えませんでした。

gtech.hatenablog.com

※ただモチベーションはものすごくあがった

今回も「字がいっぱい〜。。。」とは思いましたが(おいー)、
なんの話をしているかはわかるようになったなと思いました。

とくにU-30での発表内容やフィードバックは、自分に置き換えてみていくと実務に適用できそうなところがありました。 来年はもっと話のスピード感についていけるようになりたいです。

さいごに

参加者のみなさんお疲れさまでした!
このレポートをとおして観戦してくれたみなさまも、おつきあいありがとうございました。
テスト界ではテスコンのようないろんなイベントがありますので、どこかでまたお会いできたらうれしいです!とののでした。(^_^)/~






ガラパゴスからのお知らせ〜
ガラパゴスでは、ただいまサーバーサイドエンジニア、Androidアプリエンジニアを募集しております。
詳しくは公式HPをご覧ください。

SERVER ENGINEER | 株式会社ガラパゴス iPhone/iPad/Androidのスマートフォンアプリ開発

*1:必ずではなかったとご指摘いただいたので確認し訂正しました。2018/03/06

*2:教えていただいて修正しました。2018/03/06

(続) テスコン(テスト設計コンテスト)2018 決勝戦いってきた

みなさまこんにちは!!テストチームとのの(@tonono2587)です。
先日テスコン決勝戦にいってきました!
テスコンとは?を整理した 前回 に引き続き今回はU-30クラスの模様をお伝えできればと思います。

gtech.hatenablog.com

U-30クラス 参加チーム

参加チームは5チームでした。(発表順)

  1. あんだーズ
  2. チームT研
  3. 新米
  4. T.B.D
  5. いんプレオ

審査後、結果発表より前の休憩時間に審査員から各チームへフィードバックの時間があったのですが、
これがめちゃくちゃおもしろかったです。
うっかりしていたらはじまっていたので途中からしか聞けませんでした。。(とても残念)
わたしが聞いたなかでは、以下のようなフィードバックがありました。

あんだーず

  • どういう情報がほしくて、このインプットを選んでいるのかが足りない
  • そのためコンセプトを実現しようとしている感がなくてモヤる
  • おそらくあたまの中で変換があった。そこが成果物にでていない
  • 意図が表現できてないかも?
  • ISO25010出してるけど、コンセプトで触れていた「品質」を定義しているわけではない。。
  • 「なぜこれが必要なのか」の説明は一生懸命やってたからとてもよかった

T研

  • 「一意に定まる」というのはどう評価すればよかったのでしょう?? →そもそも一意に定まらない、難しい。。
  • 曖昧なもの(ここでは要求定義書?)をボールペン入れたからって一意に定めるのは難しい
  • 状態遷移図に力を入れていたのがよくわかったけど、質があんまりよくなかった
  • 例えばUMLドメインモデルを書くと状態がわかると思う。そうすると状態遷移図が書きやすくなる
  • 次は状態遷移「表」もかけるようになるのかな
  • 状態遷移ではカバーしきれないので、状態遷移図で網羅できないところを考えたら、テストの全体像がみえたのでは?

いんプレオ

  • 「やったことリスト」ではいけない(足りない)
  • 書いてないことをどうがんばってテストするか
  • ティラミスはエンプラむけ?なので組み込みでつかうの難しいのでは?
  • ラルフチャートのほうがつかいやすいかも
  • 成果物が読み解きづらかった

よかったところは?悪かったところは?ここが難しかった、どうすればよかったか、などなど、成果物を囲みながら発表者からの質問に審査員が口頭で答える、という形式でした。
審査員の方々はだめなところをきっぱりはっきり隠さず指摘してくれるのですが、 発表者側もまわりで聞いている参加者もとても前向きな空気でした。 もちろん、よかったところもはっきり言ってくれていました。(^^)
めちゃくちゃ真剣にフィードバックをくれるので横で聞いていてすごい羨ましかったです。
わたしは普段の業務でちゃんとフィードバックをもらえていると思っていましたが、こんなにいろんな人に見てもらえる機会はあんまりないのではないでしょうか!いいな!!

結果

U-30の結果はこうなりました〜

【優勝】T.B.D 【準優勝】新米

おめでとうございます!

ASTER-テスト設計コンテスト'18-U-30クラス 決勝戦

講評

  • 「どうつくったか」などいろいろ考えている様子がある
  • ただ、「Why」の部分が薄い
  • いいこと考えてるのに伝わらない
  • 技術要素を扱い切れていない、理解していないように思える →腹落ちさせてからつかいましょう
  • コンセプトとやろうとしていることがちぐはぐになっています。 (風呂敷を広げすぎてたためてないとか)
  • 全体の一貫性をもったドキュメントとプロセスがほしい
  • いいテストケースをつくりたいから設計するのに、その最終的なアウトプット(テストケース)がちょっと残念になってしまっている
  • 経験が少ないぶん、poorなテスト観点になってしまうかもしれない。それでもきちんと考慮された結果として成果物を出さなけれればならない
  • そこをがんばる!

総評

  • 前回と比べて格段にレベルアップしている!!

【一貫性、全体をみる姿勢】

  • 成果物全体をみる妥当性の視点が必要
  • (温泉旅館みたいな)継ぎ足しで拡張したようなものが多い
  • ちぐはぐしていて全体がひとつにまとまっていない
  • 市場調査や要求分析はしている
  • アーキテクチャはしっかりしているがテストケースが不足している
  • 上流と下流で矛盾がある
  • 最後に全体をみて、違和感があればなおすことが必要
  • 確認の時間を最後にレビューの工程をもつとよいと思います

【習慣的に技術を高めてほしい】

  • 技術の基礎不足
  • 使っているアピールはあるが使えてない
  • ファッション的に技法の名前を上げてもバレます!笑(HAYST法難しいですよね)
  • 日頃からつかえば使えるようになる
  • テスト技法は、日頃から実践して身につけるものだと思います(例えばドラクエのように、鍛えたらレベルアップできる!)
  • テスト技術をガンガンつかっていきましょう!!
  • OPENでもいける!頑張っていきましょう!

f:id:glpgsinc:20180227181625p:plain:w300

感想

テスト分析のところでは「三色ボールペン法」がかなり使われていました。
それほど難しくないし、効果的な手なのかなと思いました。
仕様に対して、「気になる」といえるように、ここでいうとペンを入れられるように、いま社内で少しずつトレーニングしてみているので、
やっていることは間違いじゃなさそうだと安心しました(^^)

講評、総評であったように、テスト設計全体をとおして「一貫性をもたせる」ことがわたしの実務においてもヒントになりそうです。
「伝わること」は、論理的であるとそれに近くなるのでは、と思いました。
プレゼンをきいていて、「ちぐはぐな感じ」が理解できたことは、昨年の聴講から成長できたところではないかなと自分で思います!!(^o^)/

話がわかってきたところで、レベリングはまだまだです。。
身近な技から身につけるのが早そうということもわかりましたが、スマホアプリのテストにおける身近な技ってどのへんからだろう…??
テスト界の技マップみたいのあるんですかね?ひとつ技を身につけたところで(ククク…奴はテスト技法四天王の中でも最弱…) みたいのやりたくありません?(え?)

次回予告

ここまでU-30クラスを振り返りました。
フィードバックはほんとに他のチームのもききたかった。。
OPENクラスでも、おもしろいお話ありましたよ〜!
次回へつづきます(^o^)/






ガラパゴスからのお知らせ〜
ガラパゴスでは、ただいまサーバーサイドエンジニア、Androidアプリエンジニアを募集しております。
詳しくは公式HPをご覧ください。

APP ENGINEER | 株式会社ガラパゴス iPhone/iPad/Androidのスマートフォンアプリ開発