今年も全社巻き込んだ年末LT大会を開催しました
この記事は、All About Group(株式会社オールアバウト) Advent Calendar 2019 25日目の記事です。
こんにちは、@k_shiotaです。
今年のAdvent Calendar 2019の最後は毎年恒例になりつつある年末LT大会の準備から実施までの流れを紹介したいと思います。
年末LT会とは
年末LT会とは、毎年年末に開催されている、その年にあった出来事や技術・趣味に関することなどをライトにトークする会です。
昨年から、全社的に行う方針となっています。
前回の開催についてはこちら↓ allabout-tech.hatenablog.com
目的
開催の目的は下記のように設定しました。
- 技術縛りをせず、みんなでとにかく発表して話すこと
- エンジニア同士や部署を横断した交流
参加人数を記録して数字としても把握します。
企画から開催までのスケジュール
前回同様、社内広報・人事も巻き込んで全社的にやる方針に変わりは有りません。
合計9名の「年末LT会運営チーム」を立ち上げ11月中旬頃から準備をはじめました。
目的を確認し前回の経験を活かしつつ事前にスプレッドシート等で相談したいことを共有してから打ち合わせをするようにしました。
はじめて運営側となった自分にとって前回を知っている方たちは心強かったです。
打ち合わせでは下記のような内容を相談しました。
前回で出た問題点も踏まえて進めました。
- 予算
- 開催日時・場所
- 当日のタイムスケジュール
- 当日の役割
- 参加者の告知方法
前回の経験を生かして
前回はピザが少なかったという意見もあったため、ピザの量を増やし非公式カレー部の料理も提供してもらえました。
そして、コミュニケーションを取りやすくするために立って聴くスペースを多く用意しました。
社内での告知
開催日時などが決定してからは、下記の方法で社内に広報しました。
- 全社メール
- Slack
- ビラ作成
事前に参加者の登録とライトニングトーク発表者の募集用にGoogleフォームを作成し、そのURLをQRコードが読み取れるようなビラを作成して社内のいたるところに貼りました!
発表者はやはり集まりにくいのですが、参加申込みのフォームに誰から話を聞きたいかなどのアンケートを取るようにしました。
- 「この人の話が聞きたい!」があれば、その人の名前を書いて下さい
- 推薦する場合は、その人に話して欲しい内容・テーマなどを自由に書いて下さい
こうしたことで発表の依頼がしやすくなり、無事に増やすことも出来ました。
年末LT会、当日の様子
当日は下記のタイムテーブルで開催され、LTの発表時間は一人あたり5分(時間を過ぎたらタイムキーパーのベルがなります)としました。 食事の用意やカレーの準備も裏で進めています。
当日のLTのテーマは下記の通りでした。発表者は合計12名でした!みなさまありがとうございました!
終始笑いやツッコミが起こる展開で和気藹々とした会場でした。
この発表を聞いてみたいということでしたら、ぜひ遊びに来てください。
振り返ってみて
前回の反省点で上がっていた点が改善されて、前回よりも運営の準備に不足はなかったと思います。
開催時間については週末の夕方となりましたが、時間帯によっても参加者の数に変化がありそうです。(例えばランチの時間とか)
事前に発表内容を共有していたためこの話を聞きたいと思った方はその時だけふらっと聴きにいらっしゃることもありました。
参加者の把握はポストイットに名前を書いてもらってフィードバックの数で把握していましたが、一気にどっと参加者が増えたときに名前がかけなかったりするのでもう少し違った形が良かったかもしれません。
振り返りは時間を取ってやりたいと思っています。
まとめ
前回もそうでしたが、普段あまり関わることのなかった人たちの話を聴くことができました。 部署間やグループ間のつながり、さらには社外とのつながりを増やすべく、来年もいろいろな取り組みをやっていきたいと考えています。
メリークリスマス🎄🎅🛷
【イベント出展レポート】「PHP Conference Japan 2019 」スポンサーとして企業ブースに出展しました!
この記事は、All About Group(株式会社オールアバウト) Advent Calendar 2019 5日目の記事です。
2019年12月1日に開催された「PHP Conference Japan 2019 」に協賛し、企業ブースの出展をしました。 オールアバウトは2015年から毎年スポンサーとして参加し、本イベントならびにPHPの発展を応援しています。 今回は当日のブースの様子や、事前の運営準備の様子をレポートします。
PHPカンファレンスの紹介
PHPカンファレンスは今年で20回目を迎え(おめでとうございます!!)、1500人を超えるPHPerが全国から集う大規模カンファレンスです。 会場ではPHPや関連技術についてのセッションが行われたり、各協賛企業の企業ブース、書籍の販売などが行われ、例年同様の大盛況でした。
オールアバウト企業ブースの紹介
オールアバウトの企業ブースでは「オールアバウトグループに関するクイズ」や「PHPカンファレンス参加者の参加目的アンケート」を行い、来場された方々と様々な交流をすることができました。 クイズの正解者の方にはオリジナルノベルティをプレゼントしたのですが、非常に好評で途中で用意していたノベルティが足りなくなるほどの盛況ぶりでした! ご来場された方々、改めてありがとうございました!!
いつから動き始めたか
本イベントの約2ヶ月前からオールアバウトグループのエンジニア横断チームであるチームテックボール(以下、TTB)を中心に以下のようなことを行いました。
- 昨年の振り返り
- イベント参加の目的
- ブース内で実施する企画
- ノベルティの選定
昨年の振り返りから改めて企業としてイベントに参加する意味や意義を考える事ができました。 チーム内でイベント参加の目的を共有できたのは今思えば非常によかったと感じています。
何をしたかったか
イベント参加の目的についてチーム内で議論した結果、今回の目的は以下のように決定しました。
- モチベーションが高いエンジニアに対して自社のアピール、オールアバウトの技術/環境/サービスに対して「オールアバウトってイイね!」と思ってもらう(オールアバウトのことをカンファレンス来場者に知ってもらう)
- PHPのコミュニティへの還元・発展
上記の目的が決定し、次に具体的な施策としてブースで何を行うか、どうすれば来場者にオールアバウトを知ってもらえるかを話し合いました。 結論までのプロセスは以下のようなイメージでした。
プロセス①:来場者をブースに引き込む施策
ブースに来てもらえないと会社のことは知ってもらえない
→ブースに来てもらうために何かをプレゼントするのは有効
→昨年のチロルチョコも好評だったが、それだけでは弱い気がする
→他のプレゼントについても考えよう
プロセス②:来場者にオールアバウトを知ってもらう施策
ブースに来てもらえてもビラやPCの画面見せても来場者の記憶に残らない
→来場者参加型の企画をしよう
→オールアバウトのことを知ってもらえるようなクイズに参加してもらおう(聞くだけでなく、参加者に思考してもらうことで記憶に残してもらいたい)
→クイズへのモチベーションを上げるために正解者へのプレゼントは別に用意しよう(プロセス①と重なる)
プロセス③:PHPカンファレンスへの還元
企業として参加してるし、普段PHPにはとてもお世話になってるから還元したい
→運営さんに来場者のことを知ってもらおう
→参加者の参加目的とエンジニア歴をまとめたアンケートを取って公表しよう
当日やってみてどうだったか
会場の様子
最初は無機質なボードでしたが、徐々に来場者の方々が集まってくるにつれ、ブースもボードもどんどん盛り上がっていきました!!
クイズボード
当初用意していたクイズ正解者へのノベルティ(スマホスタンド:120個)もおかげ様で品切れとなり、合計で140名以上(来場者全体の10%くらい)の方にクイズにチャレンジしていただけました! 少なくとも140名の方にオールアバウトについて知ってもらえたのはとてもありがたいです!!
アンケートボードの結果
以下、アンケート結果まとめ
目的・エンジニア歴 | ~3年 | 4~5年 | 6~10年 | 10年~20年 | 20年~ | total |
---|---|---|---|---|---|---|
PHPの最新動向 | 21 | 8 | 7 | 4 | 5 | 45 |
設計周りの知見 | 11 | 6 | 5 | 3 | 0 | 25 |
セキュリティ周りの知見 | 7 | 1 | 1 | 3 | 1 | 13 |
DB周りの知見 | 1 | 0 | 1 | 0 | 0 | 2 |
テスト周りの知見 | 3 | 1 | 0 | 0 | 0 | 4 |
他企業の情報/ノウハウ | 11 | 6 | 6 | 2 | 0 | 25 |
技術本 | 0 | 0 | 0 | 0 | 0 | 0 |
その他 | 18 | 5 | 3 | 1 | 2 | 29 |
total | 72 | 27 | 23 | 13 | 8 | 143 |
結果を見ると、3年目以下の若手エンジニアの来場が非常に多かった事が分かりました。 また、1/3の方はPHPカンファレンスに最新技術の動向が気になって来場されているようです。 このアンケートが来年のPHPカンファレンスに何かしらお役に立てれば非常に嬉しく思います。
イベントを終えて
イベントを振り返り、改めてイベントを企画してくださってる運営の方々、来場されていたPHPerの方々ありがとうございました! エンジニアのみなさんの熱量を感じる事ができ、スポンサー企業として参加させていただけた事、大変ありがたかったです。
オールアバウトでは現在、エンジニア採用を新卒中途ともに行なっております。 弊社に興味を持って一緒に働きたいと思った方は是非こちらからお問い合わせください。
また、最後になりますが隣の企業ブースで色々とお世話になったFABRIC TOKYOさんにもお礼申し上げます!!
オールアバウトグループは今後ともPHPの発展のため、貢献してまいります。
第3回 開発合宿@五番地に行ってきました
この記事は、All About Group(株式会社オールアバウト) Advent Calendar 2019 1日目の記事です。
こんにちは、最近購入したAirPods Proのノイズキャンセリング機能に感激した @amymd です。 10/26(土)-10/27(日)に、社内のエンジニアたちで開発合宿に行ってきたので、その報告をしたいと思います! 私は今回開発合宿の運営 兼 参加者として活動を進めていました。
前回の開発合宿については過去のテックブログの記事でも紹介してるので、ぜひご覧ください。 allabout-tech.hatenablog.com allabout-tech.hatenablog.com
今回の合宿先はなんと「山梨県」!(これまでは「静岡県」「千葉県」でした) 大自然に囲まれた合宿地で、一泊二日集中して開発を行うことができました。 また、今回も費用については全額会社が負担する形となり、大変助かりました。
続きを読むPHPカンファレンス2019にオールアバウトがシルバースポンサーとして協賛します!
株式会社オールアバウトは、12月1日(日)に東京・大田区産業プラザ PiOで開催される国内最大のPHPイベント「PHPカンファレンス」にシルバースポンサーとして協賛いたします。
オールアバウトでは2015年から毎年スポンサーとして協賛しており、今年も協賛することになりました!
カンファレンス当日はブースを出展し、弊社の若手エンジニア数名が参加いたします。
この機会に、ぜひブースにいるエンジニアたちに会社で使用してる技術のことなど気軽に質問してみてください!
また、なんと今回のブースでは、素敵なノベルティがもらえるクイズ大会を開催するとか…!?ブースでお待ちしております!
- 日時
- 2019年12月1日(日)10:00~18:00
- 場所
オールアバウトのリリースをよりシンプルに!本番GKEへCircleCIを導入し移行したお話
こんにちは!オールアバウトでSRE(サイト信頼性エンジニア)をしている@numa_numaです。
さて今回は、当社のクラウドネイティブな開発の加速・さらなるDevOps推進を目指し、デプロイツールにCircleCIを採用し移行しましたので、そのお話をご紹介したいと思います。
以前に、2016年くらいまでのオールアバウトでのリリースの歴史をご紹介しております。 興味のある方はぜひご参照ください。
当社では2016〜2017年頃にGKE(Google Kubernetes Engine)を利用しはじめ、Dockerコンテナで本番運用を行うノウハウを確立しました。 また、その時採用したのがWerckerというCIツールでした。
クラウド移行とその後のリリースの変遷
オールアバウトでは、GKE運用を確立するとともに、アプリケーションごとにデータセンター(オンプレミス)のサーバで稼働していたものを、徐々にGKE環境へ移行する形でクラウド化を行ってきました。
そして、2019年6月にクラウド化は完了し、データセンターのサーバ運用を完全に停止しました。 現在、オールアバウトのシステムの大半は、GKE上のサーバ(サーバ単位をPodと呼ぶ)で運用しています。
データセンターを撤退するため、WEBアプリごとに順次クラウド移行を進めましたが結果として、
- オンプレミスのアプリ: Jenkinsなど旧来の方法でリリース
- クラウド移行完了したアプリ: Werckerを利用したリリース
という区分ができていきました。
つまり、Wercker利用の最後期に実装していたのは、GKEのPodへリリースするために作られた仕組みであり、CircleCIでは構造的に同じデプロイを行いたい、というのが今回の移行のポイントでした。
Werckerを使い続ける上で生じた問題
Werckerを何か他のCIツールに代えた方が良い、というのは2017年くらいから社内であった議論でした。 理由としては、以下のようなことが挙げられていました。
- 安定性が低い・デプロイが低速(2017年当初)
- Dockerfileのビルドができない(ツールの仕様)
- Kubernetesに合った他のCIツールが充実してきた
当社では、ソースコードのリポジトリとしてBitbucketを採用しており、BitbucketとKubernetesに対応した唯一のCIツールだった(当時)というのがWercker採用の大きな決め手となりました。
Werckerの安定性が低かったのは当初の話で、運営サーバの品質が良くなかった(表示遅延/デプロイが途中で止まる)ようで、一時期しばしば問題が出ていました。 しばらく経つとツールの品質が徐々に改善され、安定性が低い・デプロイが低速という点はあまり気にならなくなっていきます。 そんな中で、当社での移行を決定的にさせたのは、OracleによりWerckerが買収されたことでした。
WerckerはOracleクラウドの一部となり、機能も強化されましたが契約体系の変更からかなりの費用増となる見込みでした。 また、当社ではアプリがデプロイできる以外でOracleクラウドを利用する予定は当面なかったため、利用ツールとして総じてWerckerが適切ではなくなってしまったことが、移行の最後の一押しとなりました。
CircleCIの選定
ここでは、当社が様々なデプロイツールの中からCircleCIをメインツールとして選定した理由について、ごく簡単に触れたいと思います。
ざっと書くと、
- GithubだけでなくBitbucketに対応していること(当社ではBitbucketを利用)
- 広く使われており、開発言語を選ばないこと
- GoogleインフラとGKEへの対応
- アカウントのセキュリティ管理の適切さ
- スケールが簡単で課金体系が分かりやすいこと
などの要件を満たしたバランスの良いツールだったためです。
社内的にはもっと細かい要求があったのですが、もともと全てを満たすものはなかったので結果的にバランス感で選んだ形です。 ちなみに、全部で20程度のツールを比較対象としていました。
CircleCIでのリリースフロー
ここまで、オールアバウトでの最近までのリリースの変遷とCircleCIの導入理由をご紹介してきました。
ここからは、CircleCIで実際どのようにリリースしているのか、一部Werckerとの比較を交えながら技術的な要点を見ていきたいと思います。
WerckerではDockerfileのビルドができないことから、Jenkinsを併用したりいろいろと運用方法が複雑になっていました。 その点、CircleCIでは1ツールで解決できるためリリースフローを単純化することができました。
CircleCIとWerckerの違い
CircleCIもWerckerもCIの実現を目的としたSaaSツールであるため、実現できる機能はおよそ同じです。 ただし、ツールとしての仕様が異なるため、実装の仕方を一部工夫する必要がありました。
CircleCIの特長
- 総じて処理が高速
- ビルド時にキャッシュすることが可能で、さらに高速化できる
- アカウント管理はGitHub/Bitbucket連携となっており、独自管理ではない
Werckerの特長
- デプロイしたコンテナにログインし、操作するワークフローが構成できる
- 過去のワークフローを再実行することで、コンテナを以前の状態に戻せる
- アカウント管理はサイト独自のものを使用
Dockerfileの移行
特にWerckerを使用していた時はコンテナにログインする機能を最大限活用していたため、移行時はDockerfileの書換えが必要となりました。 だいたい以下のような変更イメージです。
- Wercker利用時のDockerfile
FROM asia.gcr.io/gcp-project/allabout_common_image:latest # Apacheの設定 ADD dockerfile/${ENVIRONMENT}/apache/ /etc/httpd/conf.d/ # アプリ名のENVは予め、別途実行されたJenkinsビルドで付与されるためここでは不要 # アプリを使えるようにする最後のビルドは、コンテナにログインしてコマンド実行する # Expose ports EXPOSE 80
- CircleCI利用時のDockerfile
FROM asia.gcr.io/gcp-project/allabout_common_image:latest # Apacheの設定 ADD dockerfile/${ENVIRONMENT}/apache/ /etc/httpd/conf.d/ # ENVでアプリ名を定義する ENV APPNAME "allabout-pc-front" # アプリを使えるようにする最後のビルドを記述する(コンテナログインできないので、ここで処理) COPY . /app/${APPNAME} RUN cd /app/${APPNAME} \ && php /usr/local/src/composer.phar install --no-interaction # Expose ports EXPOSE 80
※ 概念を分かりやすくするため、ともに少々単純化/省略しています。
※ 当社では開発の主としてPHP(Laravel)を採用しており、アプリケーションのビルドは "composer.phar install" を実行することで行われます。
CircleCIを利用したGKEデプロイの流れ
当社でのWEBアプリケーションデプロイの大まかな流れは、以下のようになります。
- Bitbucketからソースコードをチェックアウト
- CircleCIのコンテナ上で、最初のビルド(composer.phar install)実行
- ビルドされたソースにテストを実施
- この後の処理のために、Google認証を通しておく
- docker buildを行う
- docker buildされたコンテナイメージをGCR(Google Container Registry)に格納(push)する
- Kubernetesのマニュフェストファイル群をもとに、アプリをGKEにデプロイする
以降では、これらのうちから鍵になるポイントをピックアップしながらご紹介します。
CircleCIのキャッシュ機能を活用する
ここでは、CircleCIを利用する利点でもあるビルド時のキャッシングについてご紹介します。 CircleCIではマニュアルも次々と日本語化されており、キャッシュの説明はすでに日本語化完了しているようです。
CircleCI公式:依存関係のキャッシュ https://circleci.com/docs/ja/2.0/caching/
当社でCircleCIの設定ファイル(.circleci/config.yml)から、当該箇所の定義を抜粋(コメントを追加)すると下記の通りです。
commands: # 〜中略〜 # composer_install: steps: # 前回のキャッシュを復元 - restore_cache: name: restore composer cache keys: - composer-v1-{{ checksum "composer.lock" }} - composer-v1- - run: # ビルド処理 name: composer install command: php /usr/local/src/composer.phar install --no-interaction # ビルド結果をもとに、キャッシュを保存 - save_cache: name: save composer cache key: composer-v1-{{ checksum "composer.lock" }} paths: - ./vendor
まず、キャッシュするパスですが、
paths: - ./vendor
このように定義されています。アプリケーションのディレクトリが/app/であるとすると、composer.phar installは以下のディレクトリで実行され、記載の条件でインストール結果が保持されます。
アプリ名の例: allabout-pc-front コンテナでのアプリ配置の絶対パス: /app/allabout-pc-front ビルド(composerインストール)内容の保持ディレクトリ: /app/allabout-pc-front/vendor
キャッシュされたものを使用するかの判定はcomposer.lockファイルのハッシュ値を比較して行なっています。 仮にファイルに差異があっても、vendorディレクトリは前回の内容が復元されるのでビルド時間が大幅に短縮できます。
当社の標準的なアプリですと、初回のビルドと2回目以降のビルドでのかかる時間差はおよそ下記のような違いがありました。
初回のビルド : 2分30秒 2回目以降のビルド : 5〜10秒 ※ 追加のcomposerモジュールインストールがない場合
当社の場合は主にコンテナですが、VMでも似たような結果となりました。 CircleCIを利用する場合は、ぜひビルド時のキャッシュを有効活用した方が良いでしょう。
CircleCIでのGKEへのデプロイ
次に、CircleCIを利用してのdocker buildを実施〜GKEへのデプロイまでの処理を行う箇所をご紹介します。
ここでは以下の要件でデプロイを行う例を記載します。
アプリ名: allabout-pc-front GCPプロジェクト名: gcp-project GCP利用ゾーン: asia-east-1a (台湾Aゾーン) GKEクラスタ名: allabout-stg01
CircleCIのビルトイン(定義済み)変数を利用することで、リポジトリ名(アプリ名)を得ることができます。
${CIRCLE_PROJECT_REPONAME} => allabout-pc-front
なお、Kubernetesのマニュフェストファイルなどは、リポジトリの以下パスに格納されているものとします。 マニュフェストファイルの内容については、本項の趣旨と異なるため割愛します。
dockerfile/Dockerfile … Dockerfile yaml_files/deployment-stg-allabout-pc-front.yaml … deployment.yaml yaml_files/svc-stg-allabout-pc-front.yaml … svc.yaml
※ サービスを稼働させるための最低限のマニュフェストのみを紹介しています。 スモールサービスでない限り、当社の標準的なアプリケーションなら実際には他のKubernetesリソースもデプロイします。
CircleCIの設定ファイル(.circleci/config.yml)の記載は、以下のようになります。
jobs: # 〜中略〜 # deploy_staging: # ステージングのGKEクラスタにデプロイする docker: # Google認証するので、google/cloud-sdkのイメージを利用 - image: google/cloud-sdk working_directory: ~/workspace steps: - attach_workspace: at: ~/workspace # dockerコマンドを使う時は必要 - setup_remote_docker - run: # Google認証を通す処理 → 割愛します # Googleのサービスアカウントを使って "Kubernetesクラスタ管理者" 相当の権限を持たせます name: Google Authentication (STG) command: echo "dummy" - run: # docker buildとGCRへのpush name: Docker build and push image to GCR (STG) command: | docker build \ --file=dockerfile/Dockerfile \ --build-arg ENVIRONMENT=staging \ -t ${CIRCLE_PROJECT_REPONAME} . docker tag ${CIRCLE_PROJECT_REPONAME} asia.gcr.io/gcp-project/${CIRCLE_PROJECT_REPONAME}-stg:${CIRCLE_SHA1} docker push asia.gcr.io/gcp-project/${CIRCLE_PROJECT_REPONAME}-stg:${CIRCLE_SHA1} - run: # GCPのプロジェクト/ゾーン/GKEクラスタを選択 name: Select GKE Cluster (STG) command: | gcloud config set core/project gcp-project gcloud config set compute/zone asia-east-1a gcloud container clusters get-credentials allabout-stg01 - run: # deploymentとsvcをGKEクラスタにデプロイ name: Deploy to Kubernetes (STG) command: | kubectl apply -f yaml_files/deployment-stg-${CIRCLE_PROJECT_REPONAME}.yaml kubectl apply -f yaml_files/svc-stg-${CIRCLE_PROJECT_REPONAME}.yaml
※ 概念を分かりやすくするため、ともに単純化/省略しています。またコメントを多数追加しています。
ちなみに、
${CIRCLE_SHA1}
というCircleCIビルトイン変数は、ビルド時の最終コミットのハッシュ値が自動で設定されます。 これをイメージに付加することで、GCRのpushイメージを一意にすることができます。
ややこしく見えますが、認証や準備がほとんどで実際の処理の本質は以下のみです。
kubectl apply -f yaml_files/deployment-stg-allabout-pc-front.yaml kubectl apply -f yaml_files/svc-stg-allabout-pc-front.yaml
システム管理者が手運用でKubernetesクラスタにPodデプロイを行うことと、何ら変わりません。 コンテナの世界ではこの操作でドラスティックな変更が加わるため、常に安全に実行するためCIで自動化します。
まとめ
- CircleCIは高速であり、キャッシュを活用することでさらに高速化を実感できる
- SaaS→SaaSへのCIツール移行は、アーキテクチャの理解があればハードルは高くない
- CircleCIからGKEへのデプロイは、docker/Kubernetesの基本に従って実装可能
品質が安定した後のWerckerも良いツールでしたが、CircleCIは高速な処理が行える高品質なツールという印象が強かったです。 CircleCIの機能的特徴によって、結果的にオールアバウトのデプロイ基盤はコンテナの基本に忠実なものへ整理することができました。