オールアバウトTech Blog

株式会社オールアバウトのエンジニアブログです。

新規事業のエンジニアとして意識していること

サービス開発

はじめに

こんにちは、オールアバウトシステム部の@sinpey_g2です。

弊社では今年の7月に、PICUPというサービスをリリースしました。

PICUP（ピカップ） | プロが選ぶお買い物メディア

新規事業のエンジニアとして、私が普段どういうところを意識しているかについて書かせていただきたいと思います。

こちらはAll About Group（株式会社オールアバウト） Advent Calendar 2017 の12日目の記事です。

All About Group（株式会社オールアバウト） Advent Calendar 2017 - Qiita

自己紹介

私は2017年度4月入社の新卒1年目で、8月くらいまでTABLESというiOSアプリを開発していました。

TABLESに関しては、以下の記事も合わせて読んでいただけるとうれしいです。 allabout-tech.hatenablog.com

その後、9月からPICUPという新規メディアのエンジニアをしています。

PICUPについて

PICUPは、専門家がユーザーの「お買い物」をサポートしてくれるお買い物情報メディアです。日用品から、家電、ベビー用品、スポーツ用品など、さまざまなジャンルのモノを専門家が紹介してくれることによって、自分に合った商品を見つけることができます。

詳しくは、以下のリンクよりご覧ください。

picup.allabout.co.jp

新規事業におけるエンジニアの役割とは？

チームメンバーには企画、ディレクター、編集、デザイナーなど様々な職種の人がいますが、開発は私一人でやっています。開発が一名しかいないので、メンバーとのやりとり、課題の設定、工数見積、実装などを全て一人で行っています。もちろん困ったことがあれば、適宜先輩エンジニアに相談しています。

私が今のチームでエンジニアとして一番意識したい役割は、「人と時間という限られたリソースをいかに最大限に発揮させられるか」だと思っています。

例えば、編集が記事を書くために使う社内CMSを使いやすくすることによって、同じ時間でより多くの記事を作ることができるようになれば、記事が増えて売上も伸びます。

このように、とにかく時間を有効活用させることが私の役割だと考えています。

チーム内ではエンジニアという意識をあえて持たない

事業をグロースさせるためにはチーム一丸となる必要があります。よってエンジニアだから、企画だからという意識は持たないようにしています。編集業務やビジネスサイドでわからないことが出てくれば必ず聞くようにしていますし、そのような技術的じゃない話でも意見を言うようにしています。

メンバーとのコミュニケーション

限られたメンバーで行う新規事業では、メンバー間のコミュニケーションが特に大切になってきます。弊社ではチャットツールにSlackを使っていて、進捗の共有や仕様の相談、本番環境にリリースした内容の報告などを行っています。

Slackを使うときに注意していること

Slackを使用するときに注意している点は以下の2つです。

  • 緊急でない場合はなるべく口頭ではなくSlackでやりとりをする。口頭でやりとりした場合も内容をSlackで共有する。
  • プライベートチャンネルや、ダイレクトメッセージでのやりとりは極力行わない。

これらを意識することで、やりとりの可視化をするようにしています。

コミュニケーションコストを下げる

気軽に話せることが仕事の頼みやすさにも関わってくると思うので、お互いのコミュニケーションコストを下げることは最終的にグロースのスピードにもつながると考えています。

一緒にランチに行って仕事以外の話をしたり、オフサイトミーティングとして丸一日社外に出てご飯を食べながらお話をするといった取り組みも行っています。

座席も、弊社では職種に関係なくプロジェクトごとに近い座席配置にしているので、チーム内でコミュニケーションしやすい環境になっています。

開発業務について

ここからは、開発面に焦点をあてていきたいと思います。

システム構成

PICUPのシステム構成をざっくり紹介します。

f:id:allabout-techblog:20171129160150p:plain

CMS(Contents Management System)で記事を作成して、その記事情報をサイトで表示しています。記事のPV数のランキングなどはBatchを使って更新しています。

フレームワークはLaravel5.4を使っていて、CMSではフロントエンドのフレームワークにVue.jsを採用しています。

Vue.jsについては社内LTをした記事があるのでこちらを参照してください。

allabout-tech.hatenablog.com

案件の種類

私の普段の開発案件は大きく3つにわけられます。

1. 新機能の実装

1つ目は、売上を伸ばすための新しい施策の実装です。こちらは主にサイトの開発になります。サイトに新しい売上のための導線を追加したり、ABテストで効果があった施策を実装したりします。

事業の売上に直結する最も大切な案件です。

2. メンバーの業務効率の改善

2つ目は、メンバーの業務効率を改善するための実装です。CMSに使いづらいところがあったり、業務フローの変更に伴ってCMSの機能と業務に乖離がある場合には、機能の改善を行います。

これによって、編集や企画メンバーの業務効率があがり、最終的に売上につながるので、非常に重要な案件です。

3. 開発効率の改善

3つ目は、私自身が開発をしやすくするための実装です。例えばJavascriptのコンパイルをCIツールで自動化させたり、リファクタリングしてソースコードの品質を保つことで、開発面での作業効率をあげます。

こちらは優先度はそこまで高くありませんが、上記1と2の案件の合間を見つけて少しずつやっています。

開発の優先度

基本的には上記1、2、3の優先順位で実装していますが、以下の要素でも優先度を決めています。

f:id:allabout-techblog:20171129160613p:plain

上図のような優先度で、だいたい1週間のうち①の低工数で高効果なものを何個かと、②の高工数かつ高効果のものを1つ取り組んでいます。効果が低いものはなるべく切り捨てるようにしています。

取り組みたい施策はたくさんあるのですが、時間が限られているのでとにかく効果が大きいものを優先して実装しています。

今後どうしていきたいか

今後はサイトの速度を改善することで、より使いやすいサイトにしたいと考えています。検索流入がメインのサイトなので、SEOについてはチーム全体で注力しています。速度改善によってSEOにも効果が出るとうれしいです。

また、新機能の開発と並行して、ユニットテストやLintツールを導入して、ソースコードの改善をしていきたいと思います。今後開発メンバーが増えたときにも、初めてコードを見たエンジニアがすぐに開発に入れるような、高品質なプログラムを目指していきたいと思います。

さいごに

以上が、新規事業で一人でエンジニアをしている私が普段意識していることです。よかったら参考にしていただけると幸いです。

最後になりますが、ぜひ皆さんPICUPを利用してみてください。

GKE(Google Kubernetes Engine)を1年間本番利用して

アドベントカレンダー2017 インフラ GCP

SREGの@takkyです。

この記事は All About Group（株式会社オールアバウト） Advent Calendar 2017 8日目の記事です。 (kubernetes ... k8s の8に合わせて8日の08:08に投稿してみました)

12/02に公開した記事ではGCPを1年間利用してどうだったかについてまとめました。 allabout-tech.hatenablog.com

この記事ではGKE(Google Kubernetes Engine)を1年間利用して得られたノウハウについてまとめたいと思います。

前書き

GCPの東京リージョンは2016/11/08にオープンされました。

cloudplatform-jp.googleblog.com

その際にGoogle Container Engine(GKE) も東京リージョンで使えるようになりました。
社内ではまだDockerの導入事例は無かったのですが、本番以降に際して合わせてコンテナ化してKubernetesで動かそうという意図もあり GKEの採用に至っています。

GKEという略称について

本題に入る前にGKEという略称についての歴史を1つ。 GKEは2017/11/14にKubernetes適応認証プログラムに対応したことを受けて Google Container EngineからGoogle Kubernetes Engineへと名前が変わりました*1。
略称はどちらもGKEです。 Google Container Engineの頭文字を取ってGCEと略すとGoogle Compute Engineとか被るからKubernetesのKをとってGKEって言っているんだよみたいなことを社内ハンズオンなどで何回も言った記憶があります。

Docker Imageの運用方針

Dockerリポジトリとしては、Google Container Registry(GCR)を使用しています。
GCRを利用するメリットとしては

  • プライベートなリポジトリが使用可能
  • 料金が安い (Google Cloud Storageの料金+ネットワーク下り)
  • Docker CLIと統合してpushやpullができる
  • GKEであれば特に認証いらずにイメージを使える

があります。 またDocker Imageのレジストリやタグの命名規則としては

アプリケーション名-[環境名]:GitCommitHash

というルールで統一しています。

アプリケーション名とGitCommitHashを付けることでデプロイ中のアプリケーションがどのコミットのものなのかひと目で分かるようになります。
(環境別にイメージを分けるかどうかは賛否両論あると思います。)

このGitCommitHashはCI/CDツールで付与しています。

また、実際の運用では社内の標準的なミドルウェア入りの共通DockerImage (PHP+Apache+etc...)を作成して毎回PHPのインストールからは行わないようにしています。

CI/CDツール

werckerというCI/CDツールを使っています。
Oracleに買収されたことで日本でも有名になったかと思います。

以下は PHP(Laravel)アプリケーション入りのDockerImageを作成して docker push / GKEへデプロイする一例になります。
(抽象化しているので実運用で使用しているものと一部異なります)

deploy_staging:
    box:
        id: gcr.io/project/allabout_common_image
        username: _json_key
        password: $PASSWORD
        registry: https://gcr.io
        tag: php56
    steps:
    - script:
      name: application placement
      code: |-
          cp -R $WERCKER_SOURCE_DIR /app/$WERCKER_APPLICATION_NAME
    # composerinstall
    - script:
        name: composer install
        code: |-
            cd /app/$WERCKER_APPLICATION_NAME
            php /usr/local/src/composer.phar install --no-interaction --no-dev
    # temporaryディレクトリに書き込み権限追加
    - script:
        name: chmod 777
        code: |-
            cd /app/$WERCKER_APPLICATION_NAME
            chmod -R 777 storage
    # docker push
    - internal/docker-push:
        registry: https://gcr.io/v2
        username: _token
        password: $GCR_AUTH_TOKEN
        repository: gcr.io/project/$WERCKER_APPLICATION_NAME-stg
        tag: $WERCKER_GIT_COMMIT
        cmd: /usr/sbin/httpd -D FOREGROUND
    - bash-template:
        cwd: /app/$WERCKER_APPLICATION_NAME/yaml_files/staging
    - kubectl:
        cwd: /app/$WERCKER_APPLICATION_NAME/yaml_files/staging
        debug: true
        command: "apply -f deployment-stg-${WERCKER_APPLICATION_NAME}.yaml"

werckerで特徴的なのはDockerfileのビルドができないという点です。 そのため、現在実行中のコンテナをinternal/docker-push というstepで pushする必要があります。
またエコシスステムとして werckerや一般ユーザが作ったstepも使用することが出来るので、使用しています。
bash-template や kubectlなどが上記の例にあたります。

DockerベースでBitbucketにも対応していますし、 GCRの継続的デリバリーツールの統合にも記載されているので良いCIツールであると思います。
欠点としてはVirtual Private Pipelines(VPP)だと $350/月で3並列実行と他のCI/CDツールとくらべ若干コストがかかる点やたまにVPPでもキューづまりが起きサポートに解決して貰う必要がある点など問題点もあります。

GKEクラスタ自体の管理

GKEクラスタを立てる方法として、Webコンソールで行う方法やgcloudコマンドで行う方法などがありますが弊社では基本的に作成はterraformで行っています。
現在約10-20クラスタ稼働しており、クラスタ当たりのNode数は4-5程度にしています。サービスや開発G毎にクラスタを分けているイメージです。
1クラスタあたりのNode数を5以下にしていたのはクラスタ管理料金として6Node以上は課金対象だったという背景があるのですが、 2017/11/28の発表でクラスタ管理料金がかからなくなったので気にする必要がなくなりました。
また、一部クラスタではMulti-Available Zoneとして配置している物もあります。

Replication Controller(RC)とDeployments

Podの配置方法としてRCとDeployments2種類方法があるかと思います。
導入当初はRCで行っていたのですが、Deploymentsでデプロイしている記事も多くGoogleのサンプルなどでもDeploymentsが用いられているためDeploymentsにしています。

DeploymentsにすることでmaxSurgeやmaxUnavailableなどにより複数podを一気にrolling update出来るのでデプロイ速度の向上が行えています。

ServiceとLB

本来であればIngressで行いたいところですが、現状外部に公開する際にはService:NodePort でPortをマッピングして
その上にGoogle Load Balancerを紐付けて公開する形を取っています。
ここはあまり良くないところなので改善したい所ですね。

監視について

ログは全て標準出力に出力しGoogle fluentdでStackDriverLoggingに転送しています。
StackDriverLoggingにはエクスポートの機能があるため、BigQueryとGoogle Cloud Storage(GCS)へ転送しています。
BigQueryは主に開発者がログを確認する用途として使用しています。
また、StackDriverLoggingはGKE標準のものをoffにして、別途 daemonsetsでデプロイしたgoogle fluentdを使用しています。
主にアクセスログをAppEngine風にしたり、アプリケーションのログレベルをStackDriver上で判別しやすくするように付与したりする用途で使用しています。
GKE自体のリソース監視はStackDriverを使っています。

1年間運用して改善が必要だと感じた所 / 改善した所

Docker Image肥大化

最初はDockerに関して0ベースから始めたので、オンプレ環境で使用していたchefのレシピをそのままDockerfile化して作ったようなイメージでした。
そのため不要なパッケージやライブラリなどが多く、DockerImageとしては3GBとかなり大きくデプロイ時間やポータビリティという面で問題がありました。
また1コンテナ1プロセスではなく、起動用scriptを叩きその中で apache,cron,fluentdなどなど起動していたため開発時にも使いにくいイメージとなっていました。
2017年の4月に刷新し、不要なパッケージの削除やyumのcache削除,ソースインストール時の中間ファイルの削除などを行い1GB程度のイメージにすることができました。
php:7-apacheが約400MB程度とまだまだ大きいイメージですが、依存ライブラリなどを考えるとちょうど良いぐらいのイメージなのかなと思います。

werckerの安定性

3ヶ月に1回度ぐらいキューづまりが発生し、サポートに問い合わせつつ手動でコマンドでデプロイするような運用が発生するので、CI/CDツールの移行は考えるべきなのかなと思っています。
少なくてもDockerfileのBuildはGoogle Container Builderに移譲して、後はコマンドでデプロイ出来るようにしておくような体制を整えておくことが必要なのかなと思います。

社内標準Docker Image

公式のCentOSをベースにPHPとApacheをインストールしたイメージになっているのでPHPのバージョンアップの度にイメージの作成を行うのは運用負荷が高いのかなと思います。
最近では新規案件に関しては公式のPHPのDocker Imageを使用して検証を行いたいと考えています。

まとめ

Kubernetes自体概念がちょっと複雑なので学習コストは高いです。 しかしながら、DockerがKubernetesをネイティブでサポートし始めたり、2017/11/30にAmazon Elastic Container Service for Kubernetes(EKS)が発表されるなど、
今後の開発者にとってKubernetesは必須スキルになってくるのかなと思います。
そのためワークショップやハンズオンを通して社内には広めていきました。
また、GKEのようなマネジメントサービスを利用することで、MasterNodeの管理はGoogleに任せてWorker Nodeのみに集中することができます。
Nodeの自動アップグレードや自動復旧等を上手く使えばインフラ運用の手間を低減することができます。
その他にもログをtailするwercker/sternやkubectlコマンドを補完するkube-promptなどのツールを使うことで開発・運用工数が上がるのかなと思います。

来年にかけてkubernetes周りは更に盛り上がっていくと思うので今から楽しみにしています。

*1:https://cloudplatform.googleblog.com/2017/11/introducing-Certified-Kubernetes-and-Google-Kubernetes-Engine.html

オールアバウトではなぜGCPを選択したか

アドベントカレンダー2017 インフラ GCP

SREGの@takkyです。

この記事は All About Group（株式会社オールアバウト） Advent Calendar 2017 2日目の記事です。

GCPの東京リージョンがオープンされて、約1年経ちました。 オールアバウトでもGCPの東京リージョンオープンに合わせてGCPをメインクラウドとして使い始めました。
この記事ではオールアバウトではなぜ、GCPを選択したか / GCPをどう活用しているかについてお伝えしたいと思います。

続きを読む

技術推進ユニットのこれまでとこれから

こんにちは！ 2017年10月から技術推進ユニットリーダーを拝命した@C058です。

All About Group（株式会社オールアバウト） Advent Calendar 2017 - Qiita

の1日目の記事は
私が所属する技術推進ユニットの活動について紹介をします(｀・ω・´)

続きを読む

障害対応、Google Home、AIについて社内LT会で発表しました！

LT 勉強会 Google Home

こんにちは、スプラトゥーン2の大規模アップデートがとても楽しみなエンジニアの@amymdです。

以前このブログでも紹介したとおり、弊社では定期的にエンジニアで社内ワークショップを行っています。

allabout-tech.hatenablog.com

先日も学生を招待した社内LT会を開催しましたので、その内容を報告したいと思います！ 発表タイトルは、下記のとおりです。

1. 障害を発生させないために
2. AIを使うことになった時に知っておいたら良いこと
3. Google Homeが家にやってきた

続きを読む