はてなブックマーク

SRE チームの @fohte です。 今回は、社内インフラ環境の AWS 移行を進めるにあたって課題となった、AWS の権限分割を目的とした AWS Organizations を用いた複数 AWS アカウントの設計や運用の話をします。 AWS Organizations とは AWS Organizations は、複数の AWS アカウントを一元管理するサービスです。 AWS Organizations には、以下のようなメリットがあります。 AWS アカウントの作成・管理が容易になる AWS アカウントごとにポリシーを設定できる 請求が一元管理できる 複数の AWS アカウントを簡単に管理できるようになるため、IAM だけの権限制御と比べ権限管理が圧倒的に楽になります。 Organizations 下であれば AWS アカウントの作成もコマンド一発で行えるようになる 1 ため、気軽

こんにちは。最近は動画制作を勉強している、シンクロ・フードの大久保です。 今更なのですが、弊社ではつい最近、Slackを有料のスタンダードプランにアップグレードしました。 すでにスタンダードでSlackを利用している企業は多いと思うのですが、弊社のように「無料版でケチケチ使っていたら、どんどん社員が増えていき、気づいたら90人くらいになっていて、有料化した場合の月額費用がすごいことになってちょっとアップグレードに勇気がいる…」という状態に陥っている企業もいるのではないでしょうか…？ 参考になるかわかりませんが、以下に弊社がフリープランからスタンダードプランに切り替える際にやったことを紹介していきたいと思います。 Slack無料版（フリープラン）の課題 まず、Slackを無料で使い続けることの課題を整理します。 弊社が感じていた課題は、この2つでした。 メッセージが10000件で消えてしまう

こんにちは、シンクロ・フードの大久保です。 今回は実際に弊社で運用しているAWS Lambdaを使ったリアルタイム画像変換APIについてご紹介したいと思います。 リアルタイム画像変換APIについては、あまり詳しく説明しませんが、画像のサイズ変換等をURLパラメータで指定してリアルタイムに変換することです。 弊社の場合はリサイズしか行わないため、画像変換APIというよりは画像リサイズAPI、というほうが適切かもしれません。 リアルタイム画像変換の方法について 弊社の方法をご紹介する前に、リアルタイム画像変換の一般的な実現手法を挙げてみます。 Nginx, ApacheなどのWebサーバのプラグインを用いる CDNとして提供されている機能を用いる 1は、クックパッド社のmod_tofuが有名で、色々企業で実現されている手法です。サーバを用意しなければならない点や、冗長化を考えると弊社ではコスト

基盤チームで CI 職人をやっている @fohte です。 今回は、Jenkins と独自ジョブスクリプトを用いたお手製 CI/CD 環境に無限のつらみが発生していたため、OSS の CI/CD ツールである Drone を使った CI/CD 環境に移行した話をします。 Drone とは？ Drone は、Go 言語で書かれた CI/CD 環境を提供する OSS ツールで、以下のような強みがあります。 YAML で設定を記述できる 全てのジョブが Docker コンテナ上で動作する master-agent 構成で無限にスケールアウトできる また、比較的安くイマドキの Docker コンテナを使ったイミュータブルな CI/CD 環境を構築できるという強みもあり、特に CircleCI が大人の事情で使えないような場合に有力な選択肢になりうると思います。 YAML で設定を記述できる Tra

こんにちは、pubgで全然ドン勝できない、開発部の大久保です。 今回は弊社が調査含め半年ほどかけて実施した、Aurora移行のお話しをしようかと思います。 ただ、Auroraへ移行するための情報自体は世の中に溢れていると思うので、今回は移行する際に失敗したことや想定外だったことをご紹介しようと思います。 具体的な失敗や想定外をお伝えすることで、移行を考えている方のお役に立てれば幸いです。 移行の概要 とはいえ、さすがに大まかにでもどのように移行をしたかをご紹介しないと、失敗も共有できないので、簡単に共有します。 今回弊社が行った移行は、EC2上にホストしているMySQLをAuroraに移行する、というものです。RDSからAuroraに移行する、というものではありません。 では、ものすごく簡素化した移行の図で、移行の全体像をお伝えします。 移行前 なにも行っていない状態はこんな感じでした。

基盤チームの川井 (@fohte) です。 今回は、monorepo と呼ばれる複数のリポジトリを単一のリポジトリで管理する運用方法の紹介と、実際にその運用に切り替えた話をします。 弊社は GitHub Enterprise を使っており、Git Flow を独自に拡張した master, develop, feature ブランチの 3 種類からなる運用フローを採用しています。 今回はその環境を前提としてお話します。 monorepo とは？ monorepo は、複数リポジトリを単一のリポジトリで管理するという Git リポジトリの運用方法の一つです。 monorepo のメリットとしては以下の点が挙げられます。 密結合なリポジトリの運用が楽になる 複数リポジトリに横断した修正が簡単にできるようになる 例えば、あるリポジトリ A の変更に従って別のリポジトリ B も変更するとき、リポジ

基盤チームの川井 (@fohte) です。 今回は飲食店リサーチというサービスのフロントエンドを Flow で型付けしながら React で開発して得た知見の話をします。 Flow とは？ Flow は Facebook 社が開発した、JavaScript の構文を拡張して静的型解析機能を提供するツールです。 例えば以下のような Flow を使ったコードは、Flow の型チェックによって事前にバグを検出することができます。 /* @flow */ function square(n: number): number { return n * n } square('2') // エラー 嬉しいですね。雑にコードを書いていても Flow が型の不一致を警告してくれるため、書いたコードに対して安心感が生まれます。さらに型解析により定義元ジャンプや補完も効くため、開発効率は大きく向上することでし

こんにちは、シンクロ・フードの大久保です。 今回はあまり社内の業務と関係がないのですが、Irisというキーボードを作成したお話しをしようかと思います。 これがIrisです TL;DR IrisというキーボードはコンパクトなErgoDoxで、作って良かった！ 組み立て式のキーボード制作は思っているよりも簡単 はんだ付けへの抵抗感を無くすのにも良さそう はじめに 僕はErgoDoxという、左右分割型で親指キーがあるキーボードを使っていて、概ね満足はしていたのですが、ErgoDoxは大きく、使わないキーが沢山あるので、もっとスリムにしたいなあ…と思っていました。 いくつか乗り換え先キーボードの選択肢もあったのですが、色々調べた結果、Irisというキーボードを自作しようという結論に達しました。 これがErgoDox。親指キーが特徴です。ErgoDoxEZを使っている人は結構多いのではないでしょうか

はじめまして。今年新卒で入社した基盤チームの川井 (@fohte) です。 最近までは、新卒企画研修として開発した wenu という飲食店向け Web サービスの開発基盤を整えたり、フロントエンド (React) のロジック部分を担当していました。 社内の既存プログラムの問題点 新卒研修終了後に配属され、既存プロジェクトの開発に携わったのですが、古くからあるコードが多く残されており、またコーディングスタイルも統一されていませんでした。 具体的には、以下のような問題がありました。 行末にスペースやタブが残されている ファイルの最後に空行が存在したりしなかったりする インデントがソフトタブだったりハードタブだったりと混在している これらの問題は構文エラーではなく、コンパイルも正常に通るために放置されていました。 しかし、各開発者が編集した際に無駄にスペースが挿入されたり削除されたりと、意味のな

シンクロ・フードでフロントエンドの開発を担当している四之宮です。 今回は、前回のブログで宣言した通り、ReactでLINE風チャット画面を実装してみたことについてお話ししたいと思います。 ReactとCSSがある程度わかることが前提になります。 作成した機能について この機能は、弊社が運営している店舗デザイン.COMのサイト内で提供されるサービスになります。 www.tenpodesign.com 店舗デザイン.COMでは、「店舗の出店や改装を考える方と店舗のデザインや施工をおこなうデザイン会社とを結びつける」ということを行っています。 機能の実装をお話しする前に、簡単にではありますが店舗デザイン.COMの説明をしたいと思います。 まず、店舗の出店や改装を考える方（以後施主と表記）は、店舗のイメージや情報を登録します。 その後、この情報をデザイン会社に配信し、興味を持ったデザイン会社がエン

こんにちは、シンクロ・フードの大久保です。最近はAWSのLambdaを触っています。近々、そのネタもブログにしようと思っています。 さて、今回はTomcatの起動高速化のお話しをしようかと思います。Railsもやっていますが、なんだかんだ言って弊社はTomcatとの付き合いが長いので…。 まず、Tomcatの起動高速化する方法を紹介する記事としては、以下のWikiが有名です。 https://cwiki.apache.org/confluence/display/TOMCAT/HowTo+FasterStartUp 今回はこの記事を軽く紹介していく、という、新しいことが特にあるわけでもない記事です…。 とはいえ、元記事を読んだことが無い方には参考になるかもしれませんので、もしこの記事を読んで興味が湧いたら、元記事を読んでみてください。 尚、弊社の本番環境で運用されているTomcatは、サー

シンクロ・フードでフロントエンドの開発を担当している四之宮です。 最近は、ReactでLine風のやりとり機能を実装しました。 近々こちらについても、ご紹介できたらと思います。 では、本題に入っていきたいと思います。 タイトルには入っていないですが、レガシーシリーズもこれが最後だと思います。 Sass+Compassについて 弊社ではSass+Compassでcssのコーディングを行っています。 今では、「Compassは終焉を迎えた」などと言われていますが当時はこれがテッパンだっと思います。 ベンダープレフィックス対応はCompassが提供する各mixin、スプライト画像の対応もCompassが提供するsprite-map、これらを使用してコーディングしました。 その後、ベンダープレフィックス対応はautoprefixerが主流となりました。 www.npmjs.com スプライト画像に

こんにちは、シンクロ・フードの大久保です。 10年以上運用しているWebサービスだと、文字コードがShift_JIS、という状況は多いのではないでしょうか。 弊社もそうだったのですが、昨年、自社で運用するWebサイトすべての文字コードをShift_JISからUTF-8に変更しました。 今回はこの対応について実施したことをご紹介したいと思います。 前提条件 WebサーバはApache、WebアプリケーションサーバはTomcat、DBサーバはMySQL5.6を利用しています。 Webサイトは全部で6サイト、すべてJavaで書かれたWebアプリケーションで、その中のメインである飲食店.COMのJavaファイル数は約2000ファイル、cssやjs、htmlファイルなどを含めると約10000ファイルくらいです。Webアプリケーションですとそこそこ大きい部類だと思います。 なぜUTF-8にするのか S

シンクロ・フードでフロントエンドの開発を担当している四之宮です。 今回は、「cssとjavascriptのキャッシュクリアの自動化に対応していないフレームワークでのキャッシュクリア自動化」についてについてお話したいと思います。 ここでいうキャッシュクリアとは、ハッシュ値をファイルに付与することで、強制的にブラウザキャッシュを無効化するキャッシュクリアのことです。 お話する前に、なぜこのような記事を書こうと思ったのかを弊社のシステム構成を交え、ご説明したいと思います。 システム構成 弊社のシステム構成に関しては以前にご紹介した通り、新サービスの開発ではRuby on Rails、既存サービスの開発はSeasar2となっています。 シンクロ・フードのサービスとシステム構成 もちろん既存サービスに関しても、少しずつRuby on Railsへの載せ替えを行っていますが、まだSeasar2で開発し

シンクロ・フードの越森です。 今回は、Tomcatのクラスタリング環境でのセッションレプリケーションについてお話したいと思います。 弊社ではAWS移行したことをきっかけにTomcatのセッションレプリケーションを見直すことになったのですが、中々これといったやり方を決めることができず試行錯誤したため、皆さんの参考になればと思い公開します。 ※現段階でも、運用でカバーしている問題は残っていますが...。 何故セッションレプリケーションが必要なのか？ セッションレプリケーションとはTomcatなどのアプリケーションサーバーを複数台並列で稼働させるクラスタリング環境において、各アプリケーションサーバー上のセッションを共有する方法です。 セッションを共有することで、アプリケーションサーバーが1台落ちた場合でもユーザーには影響を与えず、別のアプリケーションサーバーでサイトを運用することができます。 T

シンクロ・フードの五十嵐です。 今回は、私たちの開発フローについてお話したいと思います。 特にGitのブランチ運用については皆さん頭を悩ませる部分だと思いますので、弊社の紆余曲折した経緯も踏まえて公開します。 Gitへの移行を検討している方などの参考になれば嬉しいです。 リリース頻度 お話の前提として、弊社のリリース頻度を紹介します。 平日は、ほぼ毎日リリースをしています。一日数回リリースする日もあります。 月間で捌くチケット数（≒featureブランチ数）の平均は約170です。 それなりの規模になってきたため、開発フローの安定化や効率化は全体の生産性に直結すると考えており、現在も改良し続けています。 GitHub Enterprise の利用 バージョン管理はGitで行っており、GitHub Enterpriseを利用し、プルリクベースで開発を行っています。 全てのプルリクは必ずコードレ