クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

実録:「えっ、このシステム何ですか?」から始まる小さな引継ぎのおはなし。

はじめに

みなさまこんにちは。なんとか生き延びております、たかのです。

いきなり本題ですが、事業を長く続けていると、サービスの中核のシステムは肥大化します。 複雑さが増せば、理解も運用も大変になってきます。

そんな複雑さを回避するために、小さい単位で機能を分割し、別システムに切り出すことはよくあることです。 クラウドワークスにも、中核のシステムを支える小さなシステムがたくさんあります

生きているからこそ、お世話がつづくのです

システムは生き物です。(そうは思えないかもしれませんが、そんなものと思ってみてください!*1

稼働はしていても拡張や整理の判断ができず、「属人化」どころかその進化系で、作った人が退職して詳しい人が誰もいなくなってしまったもの。 そんな状態を、わたしたちの職場では「無人」と呼んでいたりします。

こうした状況は望ましくないので、メンテナンスを仕組み化し、チームで分担して取り組むようにしています。

さて、わたしたちのチームも、この「無人化」対応のタスクを1つ担当することとなりました。 その際のあれこれや学びについて、わたしの「 余技 」をふまえてお伝えします。

見積もりするよ!

  • はじめに
    • 生きているからこそ、お世話がつづくのです
  • 無人化システムをひきうけるよ!!
  • まずは読み解こう!
  • あれれ?検証環境で動かない!?
  • いよいよ本番も入れかえ!
  • 継続メンテは可能?まずやってみよう!
  • インフラも学んでいこう!
  • やってみての学び
  • まとめ
  • We're hiring!

*1:お母さんが言うんだから間違いありません!

続きを読む

Amazon LinuxのEOLに伴いバッチをサーバレス化しFargateに移行した話

f:id:bayashi_ok:20200721132149p:plain

はじめまして、2020年3月に中途入社したSREチームの @bayashiok です。

今回は入社後、Fargateでサーバレスバッチ基盤を構築した話を書いていきます。

目次

  • 目次
  • 経緯
  • Fargateを選んだ理由
    • 1. リソースの見積もりがCPU/Memoryだけですむ
    • 2.スケーリングを考えなくて良くなる
    • 3. セキュリティレベルの向上につながり管理負荷が減る
  • 現行システムで発生している問題点の解消
  • 構成
  • FargateのトリガーとしてRundeckを採用
    • 理由1: バッチ実行が行われる場所でログを見たかった
    • 理由2: ジョブ失敗やSlack通知の仕組み、リトライ方法やジョブ連携などの作り込みを簡単にしたかった
    • ecs-taskとの連携について
  • デプロイ
    • 1. wrapperコンテナのデプロイ
    • 2. バッチのデプロイ
  • Fargateタスク実行について
  • 移行後の総括
    • よかった点
    • 悪かった点
    • 苦労した点
    • 今後の課題
  • 最後に
  • We Are Hiring!

経緯

日々のSREチームのタスクの中で、EOLとなるソフトウェアの状況を定期的にチェックしているのですが、今回 Amazon Linuxが2020 年 12 月 31 日にEOLを迎えるということで、Amazon Linux上に設置されているシステムを移行する必要がありました。

Amazon Linux2に移行するという案もあるのですが、このままでは負債(後述記載)が残ってしまうためAmazon Linux上に置いてあるバッチの整理と移行バッチのFargate化を行いました。

Fargateを選んだ理由

Fargate化することのメリットは次のようなものがあげられます。

続きを読む

クラウドワークスを退職します。

オフィス
お世話になったオフィス

こんにちは、@ysk_118 です。
実は2020/06/30をもって退職することになりました。
2015/05/18に入社していますので5年とちょっと在籍していたことになります。

時系列とKPTでこの5年を振り返ります。

  • whoami
  • やってきたこと
    • 2015年
    • 2016年
    • 2017年
    • 2018年
    • 2019年
    • 2020年
  • KPT
    • Keep
    • Problem
    • Try

whoami

この5年で非常に多くのことに携わりましたので、まず軽くやってきたことを振り返りながら何者なのか知っていただけたらと思います。

  • 2015/05〜2016/03: 開発Div. エンジニア
  • 2016/04〜2017/02: プロダクトDiv. 新規事業開発グループ チームリーダー
  • 2017/02〜2018/03: プロダクトDiv. エンジニア -> スクラムマスター -> プロダクトオーナー
  • 2018/04〜2019/04: プロダクトDiv. エンジニアリング部 部長
  • 2019/05〜2020/06: 執行役員, エンジニアリングDiv. GM, 人事兼務1

クラウドワークスに入社した当時は新卒3年目でまだ経験的にも浅く、エンジニアとしてしっかりキャリアを積んでいきたいという一心でいろいろな会社を受けていたところ、運良く拾ってもらえたので非常にうれしかったです。

そこから2年ほどエンジニアとして様々なプロジェクトに関わり、その後スクラムマスターやプロダクトオーナーとしてプロダクトや組織そのものへアプローチを1年ほど。さらにその後組織全体をみていくポジションに手をあげ、マネージャーや執行役員として会社全体の中でのエンジニアリングを考える役割を2年ほどやってきました。

こうしてみると自分で手を動かすよりもマネジメント寄りのことをしている時間のほうが若干上回っていそうです。当初の目的であったエンジニアとしてのキャリアを突き詰めるよりかはなんだかんだジェネラリストを極めた結果になってしまいましたw


  1. Div.=Division(部署) GM=General Manager(部門責任者)

続きを読む

Rollbar による快適通知生活 (フロントエンド編)

こんにちは、エンジニアの Bugfire です。

自分の前の記事 でも Rollbar について書きましたが、今回はフロントエンド編です。

無法地帯

バックエンド(Rails)では、Rollbar による通知は便利に活用されており、対応したりみなかったことにしていたわけですが、フロントエンドでは以下の状況にありました。

  • あまりにもエラーが多い
  • エラーが多すぎて課金がすごいことになるのでかなり厳しめの RateLimit をかけていた
  • エラーが多すぎて slack 通知していない
  • 結局エラーを誰もみていない
  • SourceMap が登録されていないので、いざ登録されたエラーをみても分析が難しい

問題は、エラーが多すぎる件と SourceMap がないの二点です。それぞれ対応していきます。

目次

  • 無法地帯
  • Rollbar の設定
  • SourceMap
    • Webpacker 編
      • webpack の設定変更
      • AssetSync の設定変更
      • Rollbar へのアップロード
      • Source linking
    • Sprockets 編
      • SourceMap 生成部分の追加
        • lib/sprockets/uglifier_compressor.rb
        • uglify_with_source_maps
      • Rollbar へのアップロード
      • 問題点
  • 「エラーが多すぎる件」対策
    • XXX is not defined
    • 外部ライブラリに起因するケース
    • ブラウザ側のプラグイン等に起因するケース
    • Rollbar で特定エラーを無視する設定
      • botにより発生したエラーのケース
      • 例外以外のエラーのケース
      • 手がかりが全くないケース
      • 未知の Schema が存在するケース
      • 外部スクリプトのケース
      • スクリプトロードエラーのケース
      • 謎の Injection エラーのケース
  • 最後に
  • We Are Hiring!
続きを読む

イニシエのコードをモダンJS化

こんにちは。D&Aチームです。

クラウドワークスではユーザーの皆様により良い体験をしていただけるよう、クラウドワークス 安心安全宣言の取り組みを進めています!

そんな中、私たちのチームでは、ほぼ初めてのフロントエンドの開発に関わることになりました。 新規での開発ではなく、既存の実装からの更新という形となるのですが、それは古の時代のCoffeeScriptで書かれたものでした。

今回のブログはフロントエンドモダン化までの流れについて書いていこうと思います。

目次

続きを読む

© 2016 CrowdWorks, Inc., All rights reserved.