こんにちは！師走の2日目ということで、コネヒト Advent Calendar 2018 - QiitaのDay-2です。
何が嬉しいってドリフターズの新刊が出たことです・・・
サーバーサイドやっています、金城(@o0h_)です。今回の話は、not技術です。
コネヒトでは、昼休みを使って「社内LT会」を定期開催しています。先月で30回を迎え、個人的には「よく続いているのかな〜」と感じているところです。
そこで、Advent Calendarに乗じてちょっと何かを書いてみよう！という目論見です。
本記事はコネヒト Advent Calendar 2018の1日目のエントリーです！
こんにちは！Androidエンジニアの富田です。先日DroidKaigi 2019のCfP応募をして、残念ながら不採択だったのですが、実は裏目標を設定していました。それは社内メンバーの1人でも多くCfP応募してもらうことです。今回はその取り組み内容を共有したいと思います。
コネヒトではデザイナー、エンジニア含めて13名いるのですが、デザイナー、エンジニア向けカンファレンスのCfP応募経験者は3割くらいしかいません。僕自身も初めてCfP応募したのが去年のDroidKaigiです。それまでは、「本当に出していいんだろうか？」と興味はあったのですが、なかなかCfP応募まで至りませんでした。この悔しい経験からCfP応募ってもっと身近なもので、チームとして協力し合うことで少しでもCfP応募経験者を増やしたい。延いてはCfPが採択されることによって、有名なカンファレンスに登壇し、プレゼンス向上に繋げたいという狙いがありました。
それでは取り組んだことについて紹介しますが、「よし、支援したい！」と思い立った時、実際に何を支援すればいいんだろうと悩みました。僕はAndroidエンジニアでちょうどDroidKaigi 2019のCfP応募がスタートしていたので、これをきっかけに巻き込んで行く形式に決めました。具体的には以下の項目について取り組みました。
僕の場合は「僕なんかが...」、「登壇緊張する...」と言った心理コストが高く一歩踏み出すのが難しかったです。そのため心理コストを下げるにはどうすればいいんだろうと考えた時に、全て1人で準備するのではなく複数で登壇すればいいのでは？と考えました。DroidKaigi 2019でも少数ではありますが、複数登壇する方がいらっしゃり、複数人でやることによって相乗効果やコスト配分を調整できるメリットがあると思います。
DroidKaigi 2019の募集要項には多くのカテゴリがあり、下記からカテゴリを選択します。
得意なカテゴリを選べば良いと思うのですが、支援してもらうにはわかりやすいテーマで自分ゴト化できるテーマが良いです。今回はエンジニアだけでなく、デザイナーも巻き込みたく、「UI・デザイン」カテゴリを選択しました。カテゴリは決まりましたが、さらに具体的なテーマが必要で、最近興味を持っていたMaterial Themingを選択することによって、デザイナー2名と共にプロポーザル内容を考えていく運びとなりました。
みなさんが使っているアプリケーションや導入した過程で使いづらいところに対してフィードバックを送ってほしい。Google Material ThemingのようにGoodpatch Material Themingがあってもよくて、自社で使うときにカスタマイズしたMaterial Themingを使うのもあり。さらにJapan Material Themingといったような、みんなでデザインシステムを作っていくようなやり方を一緒にできると良いです。
上記の記事はMaterial Themingに関する勉強会のブログで興味を持った一部を抜粋しました。 自社サービスにカスタマイズしたMaterial Themingを利用することでサービスのUI/UX向上に繋がるためこの分野を深掘っていこうと決めました。
コネヒトではドキュメント管理ツールにDocbaseを使用しています。1人でも多くの人たちを巻き込むには取り組みの目的、プロポーザル草案、今後のスケジュールの見える化が大切だと思い、以下のようなドキュメントを作成しました。
この巨大なイベントで「ママリを紹介したい！」、「コネヒトを紹介したい！」と2016年10月から胸に秘めていました...。そろそろ本気で巨大イベント登壇目指しませんか？やりましょう！数百人規模のイベントで登壇する機会って少ないと思いますし、こんな面白そうなことを一人でやるのは勿体無い！ということで今回は関根さんと一緒に複数人登壇します！
このドキュメントに関するポジティブなフィードバックも多く、誰でも状況が把握できる環境を作るのは大切だなと改めて感じました。このドキュメントを事前に共有しておいた結果、後述する全体からフィードバックをいただくフェーズでも比較的スムーズにフィードバックを頂くことができました。
Androidエンジニア2名で考えたプロポーザルは上記になりますが、その後にデザイナー2名、さらに社内メンバーからフィードバックを頂きましたので一部紹介します。
ママリについて知っている人が少ないため、タイトルを「UX、サービスデザイン」に変更した方が良さそう
システマチックになっているので、サービスとマテリアルデザインをコラボさせたい
「こうやって行きたい！」だと実現可能性が低いため、「ちゃんとやった！」やりきった内容にしたい
長文だとパッと読んだ時に頭に入りづらい気がしたので、スライドの大項目になりそうな部分とかandroid開発者に響きそうな部分を抜き出して箇条書きで下に追加してあげるとわかりやすいかもなと思いました。
Custom Material Themingを作るためのサービスデザイン という文章の流れからデザインフローの話をするのかな？と僕は認識していたので、そしたらここはサービスデザインの一環としてCustom Material Themingを取り入れる方法みたいに主従を逆転させた方がいいかな〜と思いました！
運営しているママ向けNo1アプリのママリを用いてMaterial Themingのカスタマイズ → 運営しているママ向けNo1アプリのママリを用いてMaterial Themingのカスタマイズ方法
お二人とも頑張って！応援くらいしかできない
フィードバックを受けた結果、上記のように改善しました。単純に改善コメントをもらうだけでなく、応援コメントもいただきました。嬉しかったですし、こういう支援の仕方もあるんだなと学びでした。
CfPを一緒に考えてくださったデザイナーメンバーと共にMaterial Themingの勉強会を週1回開催しました。この活動の目的は一緒にMaterial Themingについて学習してもらうことでより自分ゴト化するのが目的でした。以下の動画では、簡単にMaterial Designの歴史やMaterial Themingの紹介がされています。こちらの動画を見て、なぜMaterial Themingができたのか理解を深めました。
さらに、Material Themingを知るためには、ベースとなるMaterial Designについてもっと理解を深める必要があります。そのため、Material Designの基礎となる「Material System」、「Material Foundation」、「Material Guidelines」の3つの読書会を週1回開催して情報共有を行いました。
残念ながらDroidKaigi 2019は不採択で、そもそもの目的だった「CfP応募するメンバーを増やす」に対しては、まだ新しくCfP応募しているメンバーはいません。個人でハンドリングすることが難しいのでもうちょっと様子を見たいと思います。ただ社内のメンバーからは、
など「ナイストライ！」とポジティブな意見をもらいました。頂いたコメントの通りなのですが、この活動を継続する必要があります。
カンファレンス開催に依存してしまう問題があるので、結果についてはもうちょっと様子見をしますが、最初の一歩を踏み出せました。まだ振り返りができていないので課題の特定、整理を行い、改善してうまく登壇まで繋がればと思います。引き続き頑張っていきます！
明日のコネヒト Advent Calendar 2018は金城さんのターンです！お楽しみに！
こんにちは。インフラエンジニアの永井(shnagai)です。
今回は、Fargateを本番投入し1ヶ月強が過ぎたので、運用する中で気付いた点について書こうと思います。
以前書いた、Fargateに関する調査のまとめ記事はこちら。
内容はざっくり下記3項目です。
Fargate導入を通して一番感じたのは、新規にコンテナ化するアプリケーションをECSで動かす場合、EC2バックエンドで試験をパス出来る状態まで持っていった後に、最後にFargateで動かすパターンがよさそうということです。
今回のFargateの本番投入では、 EC2で動いているサービスをDockerコンテナ化して新たにFargateでリリースするというものでした。 他のサービスでも同じような作業をしていたので、 Dockerコンテナ化やアプリケーション改修については比較的スムーズに終わりました。
サービス公開前に試験用ECSをFargateで作り、コンテナをデプロイして試験を始めたのですが色々と困りごとが起こりました。 アプリケーションがうまく動かず下記のような会話が繰り広げられました。
docker exec でコンテナに入りデバッグ出来たらすぐに解決出来るような問題ばかりなのですが、Fargateはコンテナに入りデバッグが出来ないのがネックになりました。
初期の環境構築では、どうしても意図せぬ設定漏れ等が出てくることはあり、それを潰すための試験だったのですが、デバッグに時間がかかり非効率になってしまいました。
結局EC2バックエンドで試験環境を作り、試験をパスした状態でFargate用にタスク定義を作り直すというステップを踏むことにしました。
もちろん標準出力は、CloudWatchLogsにはかれるのである程度はデバッグ出来るのですが、NWの問題やOSレイヤのデバッグは少し厳しいなというのが正直な感想です。
本番運用後は、コンテナにログインするような事はないので特に問題ないのですが、開発フェーズではEC2バックエンドでdocker execでデバッグ出来る状態にしたほうが、効率よく作業出来ると思いました。
ここからは、Fargateを導入してよかった点について書いていきます。
Fargateの最大のメリットだなと個人的に感じた点で、 これまで意識しなければならなかったクラスタを構成するEC2側のリソースキャパシティを考慮せずに、 タスク単位で自由に割当リソースの変更が可能となります。
※現状だと1コンテナあたり Memory:0.5〜30GB vCPU 0.25〜4の制限あり
下記図をみていただくとわかりやすいのですが、EC2バックエンドとFargateではコンテナに対するリソース割り当ての考え方が根本的に違います。
何が嬉しいかというと、負荷試験で決めたキャパシティが実際にサービスインしてみると不足していたり逆に少し過剰気味というようなケースやサービスが爆発的に成長してリソース増強が必要になるようなケースで、コンテナに割り当てるリソースの見直しを行うステップが劇的に簡単になります。
1のステップが特に面倒で、リソースを縮退する時には、コンテナがリソース不足で落ちてしまわないように注意を払う必要がありました。
これがFargateになると下記のように簡単なステップでリソースの変更が可能になります
クラスタ側のリソースは考えずに、コンテナに割り当てたいリソース量を変更するだけでOKとなります。
今後、Fargateに関してはリソース容量の増加や様々なアップデートがあるのではと予想していますが、タスク定義を変更するだけで柔軟に設定が変えられるのは大きなメリットだなと思いました。
オートスケーリングについても前述のEC2を意識しないキャパシティプランニングが可能なことと同じ理由で、 シンプルにコンテナあたりのCPU、MemoryもしくはELBでカウントするリクエスト数のしきい値ベースで設定が可能なので設定が簡単になります。
1ヶ月強本番運用している中で、Fargate起因でサービスが落ちたことはないので基盤として安定しているのはとても安心出来ます。 ECSのオートヒーリングがあるので、仮に1コンテナ落ちたとしてもサービス影響は限定的ではあるのですが。
今回一部のサービスをFargate化しましたが、全部を入れ替えるのはまだ先だなと感じたつらいポイントについても書こうと思います。
Fargateにするとホストが固定されないため、Docker Pull時のレイヤキャッシュが効かなくなります。 それが理由でEC2バックエンド時代と比べるとECSサービス更新からコンテナが立ち上がるまでの時間が約1.5〜2分程遅くなりました。 その分デプロイ速度が遅くなってしまいます。
これはDockerイメージのサイズも大きく影響するので一概には言えないですが、アーキテクチャ上仕方ないとは思いつつ、AWSの今後の進化に期待したい部分だと思っています。 Cron的な起動時間が厳格に求められるスケジュールバッチのバックエンドには、FargateでなくEC2バックエンドを使うのが今のところは正解かなと個人的には思っています。
スポットインスタンスやリザーブドインスタンス(RI)を使って、EC2バックエンドでは大幅なコスト削減が可能です。 同じリソースを使った際のオンデマンド料金でも、Fargateの価格設定は少し割高かつRIのような料金プランもないので現状コスト比較をすると分が悪いです。
これは、来週開催されるre:invent かその後かはわからないですが、そのうちRDSのRIのように柔軟なリソース変更に自動適用する形でRIが発表されるのではと期待しています。
先日、パラメータストアに置いた秘匿変数をタスク定義で環境変数に展開する機能がリリースされたり、 ECSでのDockerコンテナ運用は、Dockerイメージ+タスク定義で簡単に出来る世界が徐々に整備されつつあるなと感じる今日このごろでした。
コネヒトではコンテナ周りの基盤を整備したりサービス改善を行うエンジニアを募集しています。 少しでも興味もたれた方は、是非気軽にオフィスに遊びにきていただけるとうれしいです。
こんにちは、サーバーサイドのお仕事してます金城(@o0h_)です。
先日、社内Slackで「面白い漫画、オススメ教えてください！」と投稿したら弊社デザイナー氏から推薦された「舞妓さんちのまかないさん」がとても良かったです。ほっこりして、「なんか・・仕事頑張ろう・・」という気持ちに。
舞妓さんちのまかないさん 1 (1) (少年サンデーコミックススペシャル)
そんな弊社デザイナ、12月に開催されるDesignshipに公募スピーカーとしてお話をするよ！！との事でコネヒトメンバー一同で応援をしております。
前回・前々回と私がこちらに書いた記事がPHPを離れていた事もあり、「そろそろPHPネタを」というエントリーです。
つい先日、新しいPSRが採択されて && そのタイトルが「自分が触れるものに関わってきそう！！」と興味を持ちました。思考の整理がてら情報のシェアしてみたいと思います。
PSR-18: HTTP Client についてです。
こんにちは、サーバーサイドのお仕事してます金城(@o0h_)です。
今更ながら「映画大好きポンポさん」(の2巻)を読みました、めっちゃ良くないですか・・・
本日は、サービスの監視の話です。
コネヒトではエラートラッキングにSentryを用いていますが、CloudWatch Alarmによる定量的なエラー観測も併せて行っています。
「どう使い分けるの」「どうやって観測しているの」というお話をさせていただきます。
こんにちは。 Free! が終わってしまい夏の終わりを感じている @super_mannerです。2020年までは頑張って生きようと思いました。
さて、今回は先日開催されました、ランサーズさんとのランチLT大会についてお伝えできればと思います！
コネヒトでは先日、コネヒトーク というイベントを開催いたしました。
ありがたいことにビジネスサイド、デベロッパーサイド共にたくさんのゲストの方にお越しいただき、楽しんでいただけるイベントとなりました。
そんなコネヒトークの懇親会で出会ったのがまなみんさんです。
同じサーバーサイドエンジニアということもあり、話が盛り上がり
「実はCakePHPを使っている会社の方とゆっくりお話できる機会って結構貴重なのかも？！」
「最近、コネヒトでも社内勉強会、社外勉強会を開催する事が増えてきたし、このあたりで一つ一緒に勉強会を実施するのもおもしろいのかも？！」
というその場の思いつきを口にしたところ、とても良い反応をいただきまして、あれよあれよと合同勉強会の開催決定しました🎉
折角共通の知識ですので、今回のLTテーマは「CakePHPに関すること」として実施することに決定。
また、ランサーズさんは時折ランチでゲストを招いて勉強会を行っているとのことでしたので、今回もその形式でお邪魔することになりました。
コネヒトでもこういった形式での勉強会は初めてなので、当日は発表者である弊社のサーバーサイドエンジニア陣はドキドキしながら伺ったのですが(私が一番ドキドキしていたのは秘密)、明るく迎え入れてくださりランサーズの皆さんの素敵なお人柄をうかがい知ることができました(^^) まずはランチを取りながら自己紹介等でアイスブレイクをした後に、いよいよLTのお時間です。
今回の勉強会は、コネヒトから3名、ランサーズさんから3名の合計6名のLTで執り行いました。
発表者以外にもたくさんのエンジニアの方にご参加いただくことができ、
質疑応答でも毎回何かしら手が挙がる等いい感じに盛り上がり、あっという間にお開きの時間を迎えてしまいました。
私個人といたしましても、扱っているバージョンが違うことや、アプリケーションを取り巻く環境の違いから、私も勉強になることが大変多く楽しませていただきました。
なお、コネヒト側が行ったLTの資料はこちらに上がっておりますので興味がある方は見てみてください！ *1
今回開催するに当たり、お声がけをいただいたまなみんさんをはじめ、広報の宮田さんにも大変尽力いただきました！ 重ねて、LTをしてくださった皆様も本当にありがとうございました 🙏 こうした取り組みも今後増やしていきたいと思いますので、今後共コネヒトをよろしくお願いいたします！
*1:対象の資料タイトルはそれぞれ、 「よいOSSを支える3C」「Bye Bye Magic Number」「雰囲気で使わないjoinメソッド」
