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

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

Elasticsearchのバージョンを6.8系から7.5系にアップグレードしました

f:id:t0yohei:20200604122036p:plain

こんにちは、 @t0yohei です。今回は、1つ前のElasticsearchのバージョンを5.6系から6.8系にアップグレードしました のブログに続けて、 Elasticsearch v7.5 系までのアップグレードについて書いていきます。

この記事では、 v6.8 系へのアップグレードの方で書かれていたアップグレードの進め方やタスク管理法には触れず、 v7.5 系へのアップグレードで必要だった対応や課題についてのみ書いていきます。 v6.8 系アップグレード時の進め方がすごくやりやすかったので丸パクリ結果、書くネタがないという。

アップグレード全体に対してや、破壊的変更の一覧については下記の公式ドキュメントをご参照ください(リンク先はこの記事作成時点で最新の v7.7 のドキュメントになっています)。 https://www.elastic.co/guide/en/elasticsearch/reference/7.7/setup-upgrade.html https://www.elastic.co/guide/en/elasticsearch/reference/7.7/breaking-changes.html

目次

  • 目次
  • はじめに
  • タイプレス移行に向けた対応
    • 1. Elasticsearch v6.8 のインスタンスに対して、 include_type_name=true オプションを 付けた 上で index を構築する
    • 2. Elasticsearch v7.5 のインスタンスに対して、 include_type_name=true オプションを 付けた 状態で index を構築する
    • 3. Elasticsearch v7.5 のインスタンスに対して、 include_type_name=true オプションを 外した 状態で index を構築する
  • 対応必要だった breaking changes
    • track_total_hits defaults to 10,000
    • rest_total_hits_as_int
  • 対応した deprecation log
    • random score
  • Elasticsearch アップグレード後に起きた問題とその対応
  • おわりに
  • We are Hiring!!
続きを読む

Elasticsearchのバージョンを5.6系から6.8系にアップグレードしました

f:id:k-waragai:20200603120838p:plain

紹介

混沌に秩序を齎すとして爆誕したチームcosmosに所属している@k-waragaiです。

今回はタイトル通りElasticsearchのアップグレードに関するお話になります。

Version: 5.6.x から Version: 6.8.x までを約1ヶ月で上げきる事が出来ました。

今回はその1ヶ月の間にどのような事を行いどのような手順で上げていったのかを紹介していきます。

障害なども起こしてしまった為、その時に何があったのかなども赤裸々にお話していきますのでご期待ください。

この記事の後には6.8.x系から7.5.x系にアップグレードしたときのお話が投稿される予定です。 そちらも合わせてお読みください!

目次

  • 紹介
  • 目次
  • はじまり
  • Elasticsearch バージョン6アップグレード対応
    • STEP1 ~5.6と6.xのドキュメントを読み漁り、対応すべきところを対応する~
      • インデックス内の複数タイプが利用不可
      • Booleanタイプに指定可能な値がtrueまたはfalseのみ
      • タイプstringの廃止
      • _allフィールドが利用不可
    • STEP2 ~やることの見通しがついたらスケジュールを立てる~
      • ガントチャートを作成しよう
      • タスクを元にTrelloカードを作成しよう
      • タスクを消化したら
    • STEP3 ~ふりかえる~
      • Good
      • Bad
  • 最後に
続きを読む

チーム全員で向き合った「報酬評価機能」の開発プロセス

f:id:pontatanpo:20200424115533p:plain こんにちは、クラウドワークスユーザー体験改善に取り組むチームのteam-atMilcです。 コロナの影響でリモートワークをしているのですが、あまり環境が整っていないせいか、肩が凝ってしんどいみです。ぱおん😢

さて、本ブログでは、ちょうど先日リリースまで漕ぎつけた「報酬評価機能」を例に、主にチーム内の開発プロセス(施策策定からリリースまで)について、ご紹介していきます。チームでのプロダクト作りに悩む方の、何かの参考になれば幸いです。

  • 報酬評価機能について
    • お知らせブログによる告知
    • どんな機能?
    • このような表示がされます!
  • チームの体制
  • リリースまでのプロセスについて
    • 1. POが機能の目的とイメージの叩きを作成
      • 現状のサービスが抱える問題点の洗い出し
      • 問題を解決するためのアイデア出し
      • イデアを実現する機能イメージの作成
    • 2. チームで議論して案をブラッシュアップ
    • 3. 仕様が決まり次第、エンジニアが実装
  • チーム全員で一機能に向き合う姿勢
  • We are hiring!!
続きを読む

新規事業のメディア開発にContentfulを採用した話

はじめまして!飲むヨーグルト飲みすぎてお腹壊してる系エンジニアの ryt_kwzacky です!!

flintチームに加わってから、クラウドリンクスのフロントエンド開発をしたりチームのビジネス課題をエンジニアリングで解決したり飲むヨーグルトを飲んだりしています。

現在flintではハイエンド向け副業プラットフォームクラウドリンクスという事業を作っています。

2020年1月に正式ローンチした本サービスですが、実際にプラットフォーム上でマッチングする例が多々出てきました。

そこで、発生したマッチング事例を取りまとめメディアとして発信していくことになり、そのメディアを開発する上で採用したHeadlessCMSであるContentfulについて紹介させていただきます。

最終的な結論としては、Contentful + Nuxt.js + Firebaseの構成で自由度の高いメディアをすぐに立ち上げられるよ!ということになります。

記事の内容とターゲット

この記事では、クラウドリンクスのメディアを開発するにあたって採用したContentfulについて述べます。

特に以下のような方々に読んでいただければと思います。

  • HeadlessCMSってそもそも何?という人
  • (Vue.jsやReact.jsなどのフロントエンドの開発ができ、)何かメディアを立ち上げたいと思っている人

前者については、WordPressなどの一般的なCMSと今回紹介するHeadlessCMSの違いについて簡単に掴めると思います。

後者については、コンテンツを管理する際に、noteなどのブログサービスや安直なWordPress以外の選択肢が得られると思います。

逆に、Contentfulの実際の使い方は解説しませんので、詳しい使い方を知りたい方は想定ターゲット外の記事となっています。ご了承ください。

目次

成果物

クラウドリンクス - マッチング事例

f:id:ryt-kwzacky:20200409124107p:plain f:id:ryt-kwzacky:20200409124113p:plain

Contentfulとは?

API-first content platform to build digital experiences | Contentful

f:id:ryt-kwzacky:20200409145643p:plain

Contentfulは、「HeadlessCMS」と呼ばれるAPIベースのCMSです。

APIベースでコンテンツを管理・取得できるため、フロントエンド(表示する側)とバックエンド(管理する側)を完全に切り離すことができます。

表示(フロントエンド)側での制約がなくなり、管理しているコンテンツをマルチデバイス向けに扱うことができるようになりました。

f:id:ryt-kwzacky:20200410115451p:plain
従来のCMS(Wordpress)を使った構成とHeadlessCMS(Contentful)を使った構成の比較図

Contentful採用までの意思決定フロー

1. クラウドリンクス用のメディア開発が決定

まずは、flintでメディアを開発するに至った背景です。

2020年の1月にローンチしたハイエンド向け副業プラットフォームであるクラウドリンクスで、実際にマッチングする例がいくつか出てきました。

そこで、発生したマッチング事例を取りまとめ、メディアとして立ち上げ発信していくことになった、というのが今回の簡単な開発背景です。

2. 既存サービス (noteなど) vs 自前 (CMS, HeadlessCMS)

メディアを立ち上げるにあたって、noteなどのブログサービスを利用することももちろん検討しました。

既存サービスを利用することの主なメリットとして、立ち上げや運用にコストがかからないこと、プラットフォーム自体にユーザーが定着しているためPV数が稼ぎやすいことなどが挙げられます。

しかし、既存サービスを使ってしまうとどうしてもそのサービスの世界観が滲み出てきてしまい、訴求していきたい世界観に多少濁りが出てきてしまうのではないだろうか、ということが懸念されました。

(例えば、同じ記事でもnoteのコンテンツとして読むのと、アメブロのコンテンツとして読むことでは、受ける印象は全く違うと思います。)

また、使用サービス自体を移行する必要性が出てきたときも、使用しているサービス自体のAPIに頼らざるを得なくなり、そこで追加工数が発生してしまうかもしれないということも懸念点としてありました。

これらの要素を比較検討し、既存サービスは使用せずコンテンツは自前で管理する、という意思決定になりました。

3. HeadlessCMS vs (従来の) CMS

そして、自前でコンテンツを管理するにはCMSを導入することが必要になってきます。

CMSというと一般的にはWordPressが第一に思い浮かぶと思いますが、今回flintで採用したものはContentfulというHeadlessCMSです。

従来のCMSではなくHeadlessCMSを採用した大きな理由は、先の説明にもあったようにフロントエンドとバックエンドの切り離しが可能になるためです。これにより

  • デザインが(WordPressに比べて)自由になる
  • 結合度が下がることで保守性が上がる
  • 既にNuxt.jsでSPAを構築していたので取り扱いが楽だった

などの利点が見込めたため、新技術チャレンジという意味も含め、今回は従来のCMSではなくHeadlessCMSを採用するに至りました。

4. Contentful vs microCMS vs GraphCMS

次に、いくつかあるHeadlessCMSの候補の中からなぜContentfulを採用するに至ったかです。 具体的には以下のような候補がありました。

  • Contentful
  • microCMS
  • GraphCMS

これらの中からContentfulを選んだ理由は、(料金)×(機能)で考えたときのコストパフォーマンスが最大になる選択肢だったからです。

無料の範囲で十分な運用ができそうだったことに加え、特に重要だったのが採用検討中2019年11月下旬時点でWebhookが使えたこと(コンテンツのPublishやUpdate時にCIを走らせたかったため)です。これが決め手となりContentfulを採用する意思決定をしました。

ちなみに、現時点で改めて同様の要素で比較をしようとすると判断するのがかなり難しくなっていると思います。なぜならmicroCMSにも2019年末にWebhook機能が追加されたからです。(リンクスメディアの実装がほぼ終わったのと同時に追加されたのは笑いました。)

microCMSは日本製なので日本人にとってかなりとっつきやすく何ができるか簡潔に分かりますし、Webhook以外にも日々機能も増えてきているので非常におすすめのHeadlessCMSです。

microCMS | APIベースの日本製ヘッドレスCMS

また、ContentfulとGraphCMSの比較はこちらの記事が非常に参考になります。

【邦訳】GraphCMSとContentfulの比較 - Qiita

(極極) 簡単な使い方

簡単な実装コードを載せようと思いますが、検索すれば丁寧に解説してくれている下記のような良記事が数多くありますので、細かい使い方はそちらを参照してください。

Contentfulの料金と使い方を整理しつつ、Nuxt.jsと組み合わせてブログを作る - Qiita

Nuxt.jsとContentfulでブログ作ってみた - Qiita

コンテンツを表示するコード

// _slug.vue

<template>
  <div class="posts">
    <div v-for="(post, index) in posts" :key="index">
      {{ post.fields.title }}
    </div>
  </div>
</template>

<script>
import client from '~/plugins/contentful'

export default {
  asyncData() {
    return client
      .getEntries({
        content_type: 'post',
        order: '-sys.createdAt'
      })
      .then((entries) => {
        return { posts: entries.items }
      })
      .catch((e: any) => console.log(e))
  }
}
</script>

コンテンツを静的ファイルとして生成するコード

// nuxt.config.ts

generate: {
  routes() {
    return client
      .getEntries({ content_type: "post" })
      .then((entries: any) => {
        return entries.items.map((entry: any) => {
          return {
            route: "/articles/" + entry.fields.slug,
            payload: entry,
          }
        })
      })
  },
},

Contentful管理画面

f:id:ryt-kwzacky:20200409125718p:plain
コンテンツ一覧

f:id:ryt-kwzacky:20200409125648p:plain
コンテンツ詳細①

f:id:ryt-kwzacky:20200409125654p:plain
コンテンツ詳細②

今後のクラウドリンクス構成

これまでの内容を踏まえて、参考までにContentfulを組み込んだクラウドリンクスの全体的な構成を簡単に紹介して締めとしようと思います。

f:id:ryt-kwzacky:20200415150946p:plain

クラウドリンクスはモノリシックリポジトリ(モノレポ、monorepo)で運用しています。

GitHubにプッシュするとそれを検知してCIが走り変更点を検証し、問題がなければ自動的にビルド、Firebaseへのデプロイが行われ変更を反映できるようになっています。

Contentfulの機能として備わっているWebhookを使用することで、新コンテンツをパブリッシュしたときやコンテンツに変更を加えたときCircleCIに通知することで、GitHub上のコードは変更されておらずとも再ビルド・アップロードを行うことができ、コンテンツの変更を反映できるようになります。

なお、図中のCloud Functionsは現在Kotlinに置き換え中です。

おわりに

Contentful + Nuxt.js + Firebaseですぐにクラウドリンクス仕様のメディアを作ることができました。完全に0からでも表面的な実装をするだけなら1週間もかかりません。

HeadlessCMSを採用するメリットとしては、自由度が高いこと、保守性が高いことです。 デメリットとしては、既存サービスを利用することに比べ工数がかかること、そもそもフロントエンドの開発技術が必要なことです。 まとめると、メディアを作る際に自由度の高いことが望まれ、かつVue.jsやReact.jsなどのフロントエンドの技術があればHeadlessCMSを採用することは第一候補になり得ます。

その他の使い方としては、画像ペライチのLPを管理して、LPページを量産することもできるのでは?というようなこともチーム内で軽く話しています。 このように、工夫して使うことでさらに可能性が見えてきそうです。

We are Hiring!!

クラウドワークス では、成長し続けたいエンジニアを募集しています! www.wantedly.com

東京都 新型コロナウイルス対策サイトにアクセシビリティ視点でコントリビュートしてみた

腹筋ローラーしろよ。

はじめまして。2019年10月に中途入社したフロントエンドエンジニアの yamanoku と申します。

デザインシステムの開発チームとして入社して、現在はマーケティングチームと連携したフロントエンド開発をメインに行っております。個人的に社内や外部勉強会などでアクセシビリティ*1にまつわる啓蒙活動なども行ったりしています。

2020年3月現在、新型コロナウィルスの脅威は依然続いており、弊社でも一時的に全拠点在宅勤務(テレワーク)が行われる*2など対策を講じていたり、個人でも社会でも常に身の回りの危険を配慮しなければならない予断を許さない状況です。

色々と自粛が続き苦しい状況ですが、今回はそんな新型コロナウィルスに関連するOSSプロジェクトに、私がアクセシビリティの観点でコントリビュートしたことについて紹介させていただきます。

*1:アクセシビリティとは「アクセスしやすさ」とも訳され、どんな人でも共通に情報にたどり着けるようにする目的・考え方です。

*2:https://crowdworks.jp/press/?p=9767 , https://crowdworks.jp/press/?p=9790

続きを読む

© 2016 CrowdWorks, Inc., All rights reserved.