コネヒト開発者ブログ

コネヒト開発者ブログ

みんなの「知りたい」「知ってる」をおすそ分け!Connehito Marché #1〜Android市〜を開催しました!

こんにちは

こんにちは!Androidエンジニアの富田です。先日、Connehito Marché #1〜Android市〜という勉強会を開催しましたので、そのLT内容を簡単にですがレポートさせていただきます!今回は、「Androidに関することなら何でも発表してOKです!」というテーマで、みなさんの新鮮なネタ(ナレッジやノウハウ)をおすそ分けしていただきました!

f:id:tommy_kw:20180206110633p:plain

LT内容

CDC Testingをためしてみた

katsutomuさんのおすそ分け!

CDC Testingとは、コンシューマドリブンコントラクトテストと呼ばれています。マイクロサービスのテスト手法の一つでサービス間の連携が壊れていないことをテストできます。ConsumerとProviderという登場人物がいて、ConsumerをAndroidクライアント、Providerをサーバサイドと表現してその実行サンプルのデモがありました。

  • CDC Testingでは、Pactツールが有名
  • Pactのモックサーバを利用できる
  • API利用者はリクエストに対して期待するレスポンスをContractファイルに定義できる
  • ContractファイルはJSON形式のファイルで、API提供者にContractファイルを共有できる
  • クライアントの良い点は、実装と仕様が同期できてAPI設計仕様について主体感がある
  • サーバサイドの良い点は、破壊的な変更を検知できる。さらにpact_brokerを使うネットワーク図も作成できる
  • サービスが拡大する中で導入するのは難しいかもしれないので検証が必要

Android Developer Toolsのバグを見つけて直してもらった話

kikuchyさんのおすそ分け!

Android Lintのバグに遭遇。kotlin.collection.Map#forEachが、java.util.Map#forEachと勘違いされる影響でAndroid Lintに怒られるので、Google Issue Trackerデビューをしてバグを直してもらいました。

  • AndroidのIssue Reportについてはこちらを参照
  • 類似のバグ報告を真似すると楽にレポートを作れる
  • Issueに対して星が多いと目に留まりやすく対応してもらえる可能性が高くなる!
  • 問題を再現するために小さなプロジェクトをzip添付すると良い
  • 2018/1/12にバグ修正された!
  • SDKでバグを見つけたら、どんどん報告していきましょう!

Androidでスクレイピングした話

futaboooさんのおすそ分け!

本を読んだ後に記録したい!でも読書管理するためのWeb版読書メーターはあるけど、Androidアプリがない...自分でAndroidアプリを作ってGoogle Playストアに公開しました!

  • なければ作ればいい!
  • BookLifeを作りました!
  • BookLifeのソースコードも公開されています!
  • 利用したツールはPostmanCharlesChrome DevTools
  • ハマったところは突然の仕様変更!新しいセキュリティでリクエストにtokenが必要になって調査に一週間かかった

LiveData❤️ViewModel

tummyさんのおすそ分け!

AACのLiveDataとViewModelがめっちゃいいよ!LiveDataとViewModelの組み合わせについての紹介でした。

  • YAPC::Okinawaにも「GraphQLをプロダクション導入した結果」というテーマで登壇します!
  • LiveDataは監視することができるデータでActivity/Fragment生きているときにアクティブになる
  • ViewModelはUIに関するデータを保持・管理できて空のFragmentを持っていそう
  • LiveDataのObserver#onChangedの引数は、@Nullableから@NonNullになる予定
  • AS3.1でDataBinding + LiveDataサポート!

Firebase Cloud Functionsを使ってみた話

jyeganさんのおすそ分け!

Firebase Cloud Functionsを使ってみたお話。Flamingo社ではエンジニアが二人しかおらず、Firebase Cloud Functionsの利用についての紹介でした。

  • Firebaseとは、Googleが提供しているmBaaSで、モバイルアプリを使う時に便利なサービスが提供されている
  • Firebase Cloud FunctionsはJavaScriptで書いてNode.jsで実行される。Firebaseの他のサービスのイベントをトリガーにできる
  • バックエンドの処理が短時間で実装できる
  • Firebaseのドキュメント充実している
  • JavaScript/TypeScriptで雑に実装していた。エラーハンドリングが難しい
  • Firebase Cloud Functionsはまだベータ版なので、大規模には難しいかも

OkHttp3とRetrofit2そしてコルーチンを組み合わせて非同期通信を実現するお話

Yoshihisaさんのおすそ分け!

APIを叩くAndroidアプリではOkHttp、Retrofit、ReactiveX(Rx)を使うとコールバック地獄に陥りやすい。Coroutineを用いてコールバックから脱したい...こんな感じで書きたい!

try {
    val info = api.getInfo()
} catch (e: Exception) {
    Toast.makeText(this, e.toString(), Toast.LENGTH_LONG).show()
}
  • Coroutineは、中断・再開が可能な関数
  • Coroutineは、現時点ではexperimentalだけど、1.3ではexperimentalが外れる予定
  • gradleにcoroutines-corecoroutines-androidを導入すれば、kotlin.coroutines=enableは不要
  • adapterはJake神のretrofit2-kotlin-coroutines-experimental-adapterを使うと良い
  • Coroutine時代に備えて今から勉強しておこう!

Kotlin Issueを投げてみよう!

富田のおすそ分け!

Android版ママリのPRレビューの指摘からKotlin改善のヒントをもらい、それを基に初めてKotlinのIssueを投げて受理されました。

  • KotlinのIssue管理はYouTrackで行われている
  • Androidアプリ開発でKotlinを触っていると、意外と改善Issueが見つかる
  • 実際に投げたKotlin Issueはこちらです
  • 分からないことがあれば、Kotlin SlackチャンネルやStack Overflowで質問することが一般的なようです
  • Kotlin Issueを投げてみよう!

最後に

コネヒトで初の社外勉強会でしたが、LT(知ってる)枠、オーディエンス(知りたい)枠のご参加のみなさんや運営に協力してくださった方々のおかげで無事開催できました!ありがとうございました!!Connehito Marché はAndroidのテーマだけではなく、いろいろなテーマで継続的に開催していきますので、ご興味があれば立ち寄ってみてください!

【資料公開】X-Tech JAWSに登壇しました!~ 日本のママをコンテナで支える ~

f:id:tatsushim:20180201184240j:plain

こんにちは!

CTOの島田(@tatsushim)です。 先日「X-Tech JAWS 【第2回】~9割のX-Techと1割の優しさで切り拓く未来~」に登壇させていただきました。 xtechjaws.doorkeeper.jp 約100名の参加者が集まり、他の方の発表もとても面白かったです!

発表資料

私の発表資料はこちらにアップロードさせていただきました。
ぜひ以下をご覧いただければと思います。

発表後の会場アンケート

X-Tech JAWSでは会場アンケートをとっていて、登壇するとその発表に対しての感想をいただけます。
発表者としてフィードバックをいただけるのはとても嬉しい仕組みですね。
以下のようなお声をいただき、とても嬉しかったです!

  • 未だにEC2中心のレガシーな構成が多い弊社には刺激的な内容でした
  • スタートアップ立ち上げ時の歴史と苦労点と解決までのアプローチが非常に興味深かった
  • シングルEC2って漢の構成でビジネスをはじめて成功したって、なかなかすごいですね
  • ECSに持って行くまでの現実の困りごとが丁寧に説明されていてとても参考になった
  • コンテナをチームで育てるというのは自分の仕事にも使える考え方に感じました
  • 自身はAWSの販売側の立場なのですが、Consumer向けアプリ業界における課題やその解決策としてAWSの効能について知識を得ることができとても参考になりました
  • 情報共有の話が身にしみた

終わりに

発表資料でも触れましたが、2018年は「インフラエンジニアの仕事をなくす」をテーマにコンテナ・インフラ技術を「チームで育てる」ものにして自分たちの仕事をなくすところまでやり切りたいと思います。
X-Tech JAWS運営の皆様、会場にお越しいただいた皆様、有難うございました!

以上、島田(@tatsushim)がお送りしました!

みんなの「知りたい」「知ってる」をおすそ分け! Connehito Marchéを開催します!

Connehito Marché
活気のあるマルシェのイメージ

おはようございます。こんにちは。こんばんは。

Good morning. Good afternoon. Good evening.

最近毎日Mr.Childrenの「here comes my love」を聴いているサーバーサイドエンジニアの @itosho です。

今日は勉強会のお知らせをさせていただきます。はい、宣伝です。

「なんだ、宣伝か(そっ閉じ)」と思ったそこのあなた!そう、あなたですよ!

取り立てて有益な情報は提供出来ないかもしれませんが、これも何かの縁だと思って最後まで読んでいただけると幸いです。

いつどこでなんの勉強会をやるの?

一言で言うと 2月1日、木曜日、19時から白金高輪にあるコネヒトのオフィスで、Androidの勉強会 を開催します!

勉強会の詳細については、下記のconnpassのページをご覧いただければと思いますが、せっかくなのでここでは、勉強会のタイトルにもある「Connehito Marché」(コネヒトマルシェ)に込めた想いについて、少しお話させていただければと思います。

connehito-marche.connpass.com

Connehito Marchéのコンセプト

タイトルにもある通りConnehito Marchéは、みんなの「知りたい」「知ってる」をおすそ分け!をコンセプトにした参加者が主役の勉強会です。

勉強会をマルシェ(市場)に見立てて、新鮮なネタ(ナレッジやノウハウ)を提供したり、仕入れたりしながら、みんなが和気あいあいと交流出来る活気に満ちた勉強会を目指しています。

ですので、基本的にはLT(Lightning Talks)を勉強会のメインコンテンツとし、参加者の方には普段の業務などで得た学びや苦労をみんなに「おすそ分け」していただきたいと考えています。

そして、また「おすそ分け」された人がまた誰かに「おすそ分け」をすることで、コミュニティが循環していけばいいな、なんてことも考えています。

ちなみに元々は、弊社サーバーサイドエンジニアの金城発案の元、チームのナレッジ共有の場として、お昼休みを利用しながら、社内LTという形で行っていたのですが、このたび、もっとたくさんの人と交流したいと考え、オープンな場として開催することになりました。*1

誰でも参加していいの?

はい、そのテーマに興味がある方でしたら、誰でもOKです!初心者の方も大歓迎ですし、LTの内容も仕事じゃないけど「趣味でこんなことやってます〜」といった内容でも構いません。個人的には、勉強会は話を聴くだけではなく、発表もしたほうが得るものは多いと思っているので、LT枠の方が増えると嬉しいなと思っています。

「こんなの誰でも知ってるだろうし、大したことないだろうなぁ」と思うことでも、あなたの「知ってる」を「知りたい」人は必ずいると思うので、ちょっとでも「LTしてみようかな…」と思った方は、是非LT枠でのご参加をお待ちしています。LT未経験でも全く問題ありません。むしろ、このマルシェをLTの練習に使ってください!*2

とは言え、いきなりLTなんて「怖いよおおお」「無理いいい」って方もいらっしゃると思うので、そういう方は無理せずオーディエンス枠で参加してください。一番寂しいのは人気のないマルシェなので、仕事帰りに「お、やってるやってる」みたいなテンションで、ふらっと気軽に寄っていただければと思います。

毎回Androidがテーマなの?

いえ、テーマは毎回変えます。まだ未定ですが今後は、iOS、Webのフロントエンド、サーバーサイド(アプリケーションレイヤー)、インフラ領域のテーマでも開催させていただく予定です。頻度も検討中ですが、最低でも四半期に1回くらいのペースでやっていきたいと考えています。

意気込み

…とここまで読んで「やっぱり有益な情報ねぇじゃねぇか!」と思ったそこのあなた!勉強会当日はきっと有益な情報だらけだと思うので、是非Connehito Marchéへの参加をお待ちしております!

connehito-marche.connpass.com

*1:余談ですが、都知事の「築地も豊洲も生かす」ではないですが、クローズドなマルシェも継続しています。

*2:社内で開催しているマルシェはLTの練習も兼ねています。

面倒いの抜きでPHPの静的解析「Phan」を使ってみる with Docker

面倒いの抜きでPhanを使ってみる

あけましておめでとうございます!
サーバーサイドやってます金城(@o0h)です。

年末年始は毎年恒例の「ヘルシング全巻読み直し」をしていました。カッコいいですね・・

弊社ではPhanを用いた静的解析を行っております。
今回は、「多分、これが最も1番の最速さでPhanを試す方法になるんじゃないかな?」というお話をいたします。

cf) リファクタリング対象を選ぶ戦略を決めよう - コネヒト開発者ブログ

https://cdn.mamari.jp/authorized/5a522dc0-c5f0-4f0d-8f46-0016ac120004.jpg

tl;dr

  1. cloudflare/phan というイメージがあります
  2. これを使うと、「php7環境の用意」だとか「php-astの用意」とかいった手間を全部すっ飛ばしてPhanの静的解析が実行できます
  3. すぐ使えるようにコマンドがあるので、↑のページの "Getting docker-phan" のセクションを参照してください*1

*1:この記事を書き始めてから見つけたのですが、まさに「コマンドを使う」感覚でPhanを丸ごと実行できる!!というユーザー体験だと思います。すごい。。 → コマンド実行環境としてのDocker // Speaker Deck

続きを読む

アンチフラジャイルなチームを目指して

Merry Christmas
最後のプレゼント(記事)をお届け!

はじめに

本記事はコネヒト Advent Calendar 2017の25日目、つまり、最後のエントリーになります。

メリークリスマス!そして、宮崎あおいさんご結婚おめでとうございます!サーバーサイドエンジニアの @itosho です。

ここまで続いてきたアドベントカレンダーもいよいよフィナーレということで、今日は来年の抱負というかこれからのことを書いてみたいと思います。 あんまり技術的な話は出てこないと思いますが、1mmでも誰かに刺さるといいなぁ…と願いながら書きます。

2018年版僕が考える理想のチーム

僕は昔から個人ではなくチームが成長するために何をするべきか、もしくは組織の中で各人が有機的にワークするにはどうすればいいかを考えたり、実践したりするのが好きなのですが、ここ最近、気に入っているキーワードのひとつに「アンチフラジャイル」という言葉があります。

アンチフラジャイルとは?

ご存知の方もいるかもしれませんが、最初にアンチフラジャイルという言葉の意味について簡単に説明させていただきます。

そもそも、アンチフラジャイルという言葉自体は技術用語ではなく、著書『ブラック・スワン』で有名なNassim Talebさんが考えた造語です。日本では『反脆弱性』というタイトルで書籍が出版されており、分野としては行動経済学に位置づけられているのですが、他の分野でも有効な考えとして広く注目を集めており、ソフトウェアの世界では、特にマイクロサービスやDevOpsの文脈で使われることが多いようです。

また、アンチフラジャイルを理解するためには、まず、フラジャイル・ロバスト・レジリエンスという言葉を知っておく必要があります。

フラジャイル / Fragile

フラジャイルとは、一回の大きな変化で大きな損を生み出すものとして定義されています。 例えば、杜撰な計画をしたウォーターフォール型の開発は、一度大きなトラブルがあると、大きな手戻り(=損)が発生してしまうため、フラジャイルであると言えるでしょう。

そう言えば、Every Little Thingさんの歌にも同じタイトル(発音が違うけど)の曲があると思いますが、だいたいそんな感じです。

ロバスト / Robust

ロバストとは、フラジャイルの逆で、大きな変化を受けても、大きな損を出さないものとして定義されています。 先程の例で言うと、しっかりと計画を練られたウォーターフォール型の開発はロバストであると言えます。また、職業で言うと、サラリーマンはフラジャイルで医者はロバストに分類されるようです。 ただし、ロバストの欠点として、想定していない突発的な事態には対処出来ないことが挙げられます。

レジリエンス / Resilience

レジリエンスとは、ロバストを更に発展させた考えで、変化に強く、回復力が高いという意味を持ちます。 開発モデルで言うと、アジャイル開発はまさにレジリエンス的な考えを反映したものだと思います。 また、突発的な事態が発生しても、被害を最小限に留められるようにすることもレジリエンス的な考えで、具体的にはサーキットブレイカーの仕組みやBCP対策などがこれに当たります。

アンチフラジャイル / Antifragile

そして、お待たせしましたアンチフラジャイルの登場です。アンチフラジャイルの特徴を一言で言うと、アンチフラジャイルは変化に対して、損ではなく利益を生みます。

これまではレジリエンスなシステムであることが良いとされてきましたが、アンチフラジャイルは更にそれを推し進めたのが考えになります。 例えば、これまでは「障害をどう防ぐか」について腐心してきた方が多いと思いますが、「障害は起きる」という前提で動くのが、アンチフラジャイルの基本的な考えになります。

Netflixではいち早くこの概念を導入して、本番環境でわざと障害を起こしたり、Chaos Engineeringの原則を導入したりすることで、変化や障害に対処出来る強いシステムを作り上げることに成功にしています。

失敗から学ぶ、という表現では陳腐過ぎるとは思いますが、アンチフラジャイルは失敗を重ねることで、より強くなっていくものであり、この考え方はソフトウェア工学やアーキテクチャ論に留まらず、もっと会社や組織、チームマネジメント的な分野にも応用出来るのはではないかと僕は考えています。*1

強いチームをつくるために

例えば、チームの成長を止めない方法の一つとして、離職率を下げることが挙げられます。これは当然と言えば当然で、チームが成長するには経験や学び(ラーニング)の蓄積が必要だからです。*2

また、チームは一朝一夕には強くならないので、それを向上させるには小さな成功体験を積み重ねる必要があります。そうすることで、チーム力は徐々に強化されていきます。 加えて、各人が組織として有機的に動けるようするために開発プロセスやフローなどのルールを整備することも大切でしょう。

でも、世界は不確実だ

では、本当にそれだけで良いのでしょうか?

もちろん、離職率を下げることは会社としてとても大切なことですし、一度成功した起業家がそうではない起業家よりも次に成功する確率が高い*3というデータがあるように、成功体験を得ることは重要です。 また、組織が急速に大きくなっていくフェーズでは、大なり小なりルールを整備しないと日々の業務が破綻する可能性があります。

しかし、どうしたって、離職者を0にすることは出来ません。*4 幸いにも、現状コネヒトの離職率はかなり低い状態ですが、1年後どうなっているかは分かりません。もしかしたら、iOSエンジニアがある日突然、全員無人島に行ってしまうかもしれません。そうなって欲しくはないですが、その可能性は0ではありません。その時、これまで通り次の日から業務を続けることが出来るでしょうか?

業界にパラダイムシフトが起きて、これまでの常識が通用しなくなった時、今までの成功体験は本当に役に立つのでしょうか? どんなにルールを整備しても、いずれルールは破られます。何故なら、ルールは破られるために存在するからです。*5 また、ルールの中に生きていると、ルール外のことが起きた時に対処出来なくなったり、ルールの外側にある変化に気付きにくくなったりしてしまう危険性もあります。

目まぐるしく変化するこの不確実な世界で闘うためには従来のレジリエンス的な考え方だけではなく、アンチフラジャイルな考え方をチームに取り入れていくことが、この先を生きのびるためのひとつの方法なのではないかと僕は思います。

僕たちはアンチフラジャイルになれるのか?

とは言え、アンチフラジャイルなチームになることは容易ではありません。 アンチフラジャイルなチームになるためには、前提としてレジリエンスなチームでなければなりませんし、そもそも、レジリエンスなチームに辿り着くにも相当な努力が必要です。

しかし、諦めたらそこで試合終了です。

少しでもアンチフラジャイルに近づくために、最近、僕が意識していることは以下の3つです。

  • 職能・職域に囚われない
  • 小さな失敗を繰り返して成長する
  • ルールなしで自走出来るようにする

言葉にしてみると、至極当たり前のことばかりかもしれませんが、いきなりスーパーマンにはなれないので、まずは自分に出来ることから地道にはじめていくしかないのかなと思っています。

今回参考にさせていただいたアンチフラジャイルの世界という記事の中にアンチフラジャイルのメタファーとして、ドラゴンボールのサイヤ人が登場するのですが、個人的に秀逸な例えだと思っていて、スーパーサイヤ人が集まったチームが出来たら…と想像するだけでわくわくします…!

繰り返しになりますが、アンチフラジャイルなチームをつくることは容易ではありません。しかし、アンチフラジャイルなチームになろうすること、少なくともその態度を示すことがアンチフラジャイルへ繋がる第一歩なのだと僕は考えています。

おわりに

ここまでお付き合いいただきありがとうございました。

長文を書き散らした挙句、結論めいたものもなく恐縮ですが、来年はここに書いたことを意識しながら、サービスをもっと大きく出来るよう、より一層頑張っていく所存でございます。 とは言え、頑張り続けるにはエネルギーが必要なので、素敵なメンバーとわいわい働くことでエネルギーをもらいながら、愉しく頑張っていければ最高ですし、その頑張った成果をまた来年のアドベントカレンダーで報告出来ればもっと最高だなと思っています。

それではよいお年を!

参考文献 / サイト

めっちゃたくさんお世話になりました。

おまけ

www.youtube.com

*1:そもそも、最初にこの概念を利用したと言われる元NetflixのAriel Tseitlinさんもアンチフラジャイルな組織というタイトルの記事を書いています。

*2:ラーニングの蓄積の重要性については、伊藤直也さんの開発組織マネジメントのコツに要点がまとめられています。

*3:DHHさんがいることで有名な37signals(現Basecamp)の書籍である『小さなチーム、大きな仕事――働き方の新スタンダード』の 「失敗から学ぶこと」は過大評価されている の章より引用

*4:出来ることと言えば、せめてネガティブな理由でなくポジティブな理由で去って行くことくらいでしょうか…。

*5:これは極論かもしれませんが、そういう側面もあるかと思います。

Docker運用基盤をECSからFargateにリプレイスした未来について考察してみた

こんにちは。インフラエンジニアの永井(shnagai)です。

この記事はコネヒト & aws-fargate Advent Calendar 2017 22日目の記事です。

※本当は別記事二本書く予定だったのですが、パワー不足で一本にまとめさせてもらいました。

コネヒト Advent Calendar 2017 - Qiita

AWS Fargate Advent Calendar 2017 - Qiita

コネヒトでは、本番環境のほとんどのサービスでDockerを導入し、ECSを使ってサービス運用しているのですが、今回のre:Inventで発表されたFargateにこの環境を置き換えるとどんな未来が待っているかについて、考察してみました。

現状の自分が認識している情報ベースで書いているので、正確な情報とはいえずツッコミあれば指摘いただけると幸いです。

目次

  • Docker導入で何を目指したかったのか
  • 下記テーマについて、ECS→Fargateにリプレイスした先の未来を考察
    • インフラ的な運用面
    • コスト面
    • 監視周りの話
    • スケジュール系バッチと集計系バッチの話
  • これからの課題
  • まとめ

Docker導入で何を目指したかったのか

そもそもECSやFargateを動かすには、アプリケーションの実行基盤をDocker化する必要があります。 コネヒトでは、約半年かけて開発環境から本番までDocker化を進めてきたのですが、改めて目指していた状況と現在を振り返ってみたいと思います。

【解決したかった課題】

  • 開発環境が不安定

多数のVMにより、ホストに負荷がかかり重くて開発速度に支障が出てきていた

  • 本番/開発環境の乖離

開発、本番それぞれ別環境/オペレーションでOSやミドルウェアのメンテが必要なため必然的に乖離が生じる

tech.connehito.com

【導入後の経過】

  • 開発環境が不安定

Docker for Mac特有の問題が少しあるものの、概ね開発環境への不満はなくなりました。

  • 本番/開発環境の乖離

Dockerfileに全ての情報を集約した為に、開発者自身がDockerfileをメンテナンスしながら日々の開発が行えるようになりました。 よくある、開発者からインフラへの「本番にこれ入れたいんでお願いします」的な話がなくなりました。 これは、アプリケーション実行基盤自体をコードで管理するというDocker化の一番の恩恵なのかなと思っています。

【新たな課題】

当初の目的は達成したのですが、Dockerの実行基盤としてECSを採用した為、今度は、ECSに関するオペレーションが新たな課題として持ち上がってきました。 ECSは、ご存知の通りEC2を束ねたクラスタを組みその上に、Dockerのコンテナを動かすというDockerオーケストレーション層のサービスです。

故に、EC2を強く意識しながら運用することが求められます。

  • キャパプラする時に、ホスト(EC2)側のリソースとタスク(コンテナ)のリソースを計算しながら本番トラフィックを捌ける構成を組む
  • 監視に関しても、コンテナ+ホスト(EC2)に関する二重の監視が必要

なので、インフラレイヤ含めたアプリケーション実行基盤は開発者だけで作れても、ECS上でトラフィックに耐えうるサービスとして動かすところはECSの専門的な知識がないとちょっと難しいという状況が生まれました。 キャパプラ・監視・デプロイ等、ECSのアーキテクチャを理解してないと運用は難しいといった問題が出てきたというところです。

そして、EC2を強く意識する運用から脱却したいなと待ち望んでいたところに、今回のre:InventでFargateというDockerコンテナのマネージドサービスが発表されました。 ここからは、東京リージョンにFargateが来てECSからFargateに乗り変えたらどんな未来が待っているのかというのを、自分が今認識している情報ベースで書き連ねたいと思います。

ECSからFargateに移行するとどうなるか

4つのタームに分けて個人的な考察を書きます。

Fargate実際に触ってみた時の所感はこちら! tech.connehito.com

インフラ的な運用面

現状

①クラスタ内のホスト(EC2)とタスク(コンテナ)を意識しながら、キャパシティプランニングをしないといけない

ECSだとクラスタとタスクを連動して考えないとならず、クラスタのキャパシティを確保した上で、タスク(コンテナ)のリソースを考えないといけない。 これは、オートスケールを組む際も同じで、面倒&事故につながる可能性も高いので今は使いづらい。 ※オートスケールをCPUトリガにしてても、緩やかに上っていくというより一気にしきい値超えてくるような状態多いですよね。だから、結局クラスタに余裕もたせる戦略の方が安全という話

②新規開発時にうまく動かない時は、たまにコンテナにSSHしてデバッグすることがある(あまりやらないようにはしてるけど)

例えば、新しいツールをECS上で動かそうとする時に、意図しない挙動をする事がある。 そんな時は、テスト環境でタスクを立ち上げて、コンテナ内にSSHして何が起きているかデバッグしている。 いくらDockerで開発環境で動いたものを持っていくと言ってもいざという時にデバッグは必要。 トラブル起きてる時に、top叩いてあたりつけたいですよねという話

Fargateになると

①の苦労がなくなる事が、Fargateを導入する一番のメリットになるのではと個人的には思っている。 ECS環境作る時に、裏にいるEC2を強く意識しながらサービスを作っていたからそこから解放されるのは大きい。 オートスケールする時に、まずEC2のリソース確保してからその中でスケール出来るコンテナ数とか考えたくないですよね。

②に関しては、マネージドサービスを使う時点で、SSHはまぁ出来ないだろうなという印象。 只、いざというときのデバッグを出来るような仕組みは欲しいなというのが正直なところ。

願望

サービスのオートスケールにAutoScalingGroupにあるようなスケジュールでスケールする機能がついてくるうれしい。サービス毎にピークタイムはもちろん異なると思いますが、予め予測出来ている負荷に対しては準備しておきたい。 これ入ると、かなり動的にコンテナ数を増減しながらコストメリットも出していくような未来的な運用が出来そうだなと思っています。

コスト面

現状

Blue/Greenデプロイを実現するために、必要なコンピューティングリソースの2倍をEC2インスタンスとしてクラスタ内に構えているため、サービスを稼働するために必要なコンピューティングリソースの2倍の金額がかかっている。 が、EC2のリザーブドインスタンスを使ってるので、実質は、オンデマンドインスタンスの四掛くらいの料金がECSでサービスを動かすためのコストとして掛かっている。

Fargateになると

ざっくり、オンデマンドインスタンスとの比較で約2倍の料金設定というレポートがあったので、クラスタで常時動くコンピューティングリソースが半分になると考えるとコスト的には現在と変わらないか、リザーブド値引き分があるので、少しコストが上がるのかなという感覚。 ココらへんは、東京リージョンにローンチされてサービスメニューを見てみないとなんとも言えないので、来たら確認しようと思う。

こちら参考にさせていただきました。http://tech-blog.abeja.asia/entry/fargate-ecs-spotfleet

願望

バッチ的な使い方でなく、Web環境で使うとなるとある程度固定的にコンピューティングリソースを確保しておきたいという要望はかなりあると思うので、コンピューティングリソースのリザーブド的なメニューが出てくるのではと推測しています。裏で動いているのはEC2だと思うので、リソースを予約してコストダウン図れるようにしていけたら幸せだなと思っています。

監視周りの話

現状

  • ECSだと、サービス(同じ役割のDockerコンテナの集合体)単位とクラスタ(EC2インスタンスの集合体)単位で監視をしている
  • ECS関連で取れるメトリクスは、CPU,Memのみで、Web環境に関しては、ALBのUnhealthyHostをコンテナの生存確認としてチェックしている
  • EC2側は、AutoScallingGroupのNWIn/OutとStatusCheckFailだけチェックしている

Fargateになると

監視項目はかなり減りそう(とれるメトリクスがCPU,Memだけなので)

  • CPU,Memをタスク定義で1コンテナあたりに割り当てていくから、今でいうサービスで取れるメトリクスの(CPU,Mem)だけを見ておく状態??
  • Memoryはハードリミット一択になりそうだから、OOMは気をつけないといけない
  • CPU使用率が一番重要なメトリクスになるのは今と変わらない
  • EC2側で気にかけているStatusCheckFailは不要になる

FargateのCPU,MemとALBから取れるメトリクスを組み合わせて監視を作っていく形になるだろう。 只、見るべきポイントが少なくなるのはマネージドサービスの恩恵を受けれる部分で、安定運用しているうちは変に高濃度なメトリクスは取ろうとしないで運用をAWSに任せるのが良いアプローチな気がする

願望

それこそDatadogとかMackerelとか使えよという話だが、プロセス監視とか高濃度メトリクスを手軽に取れるとよさそう。 後は、1台だけにNewRelicのようなミドルウェア入れるみたいな事出来るといいなと。 CloudWatchのメトリクスが何もしなくても値取ってきてくれるイメージで、Fargate(ecs-agent??)に組み込みの形で任意のメトリクスとか取れるといいなと思っています。

スケジュール系バッチと集計系バッチの話

現状

  • スケジュール系、集計系バッチともに、ECS ScheduleTasksを使って実行している
  • 現状起きていないが、集計系の重い処理はホスト側のリソース競合が起きることを念頭に起きながら運用しなければならない

tech.connehito.com

Fargateになると

バッチ系に関しては使い分けが必要と個人的には思っている

集計系バッチ処理

  • 時間への強い制約がないので、Fargateで強めのコンピューティングリソースを使いと従量課金でやるのがよさそう。Lambda的な時間制限もないので、この使い方は普及しそう

スケジュール系バッチ処理

  • 何時何分に動くことに意味があるバッチとかだと、どうしても初回起動の遅さがあるかなというのを危惧している(もちろんDockerイメージのサイズによるところが大きいがホスト固定されない分、Pull時のキャッシュが効かなくなるから)
  • ひとまずは、今のScheduleTaskで運用して様子を見る

願望

特になくて色々なユースケースが集まってくるといいなと思っています。

これからの課題

コネヒトの今見えているDocker周りに関する課題について、書いておこうと思います。

  • Docker導入を優先してやってきたので、Dockerイメージのリファクタ等に手をつけられておらず、イメージスリム化しないとFargateだと起動が遅くなるだろうからそこに着手
  • デプロイフローをECSありきで組んだので、Fargateにフィットさせるべく改良
  • すぐに使うことはないけど、k8sの情報も追いかけながら最適なDockerのサービス運用環境を探っていく(最近の話だと、マイクロサービス化した時の内部通信(例えばAPI間通信とか)はk8sのプロキシスタイルのほうが優秀なのかなと思ってる)

まとめ

今思ってることを書き連ねてみたが、Fargateを導入することで運用コストを下げてコンテナをサービス運用する、幸せにそうな未来が見えてきたので、早く東京リージョンに来て色々とやっていきたい。

手元で開発したコンテナを、あまり何も考えずにサービスとして動かせる未来が近づいてきている感じがした。(最初にオートスケール等を組んで運用にのせれば)

テーマ ECS Fargate 補足
インフラ的な運用面 EC2管理からの解放!!SSHは出来ないだろうけどそこはマネージドサービスと割り切る
コスト面 Fargateの方が少し高くなるのかも??(未知)
監視周りの話 気にかけるべきメトリクスが減るのは良いこと
スケジュール系バッチと集計系バッチの話 Fargateはコンテナ起動速度が少し気になる(Dockerイメージサイズ次第)

明日のコネヒトアドベントカレンダーは、katsutomu さんによる、記事です。 お楽しみに!

コネヒトではコンテナ周りの基盤を整備したりサービス改善を行うエンジニアを募集しています。 少しでも興味もたれた方は、是非気軽にオフィスに遊びにきていただけるとうれしいです。

www.wantedly.com

【資料公開】PHP Way #1 に登壇しました!~ コネヒトが考える技術選択の仕方について ~

f:id:tatsushim:20171220171449j:plain

この記事はコネヒトアドベントカレンダーの20日目の記事です。 qiita.com

こんにちは!

CTOの島田(@tatsushim)です。 昨日BASE社が主催する「PHP Way #1」に登壇させていただきました。 base.connpass.com #phpwayがトレンドに上がるなどイベントとしてはとても盛り上がりました。 今回は発表した内容の要旨を大きく3つに分けてお伝えしたいと思います。

発表内容

サービスの0→1で意識したこと

サービスの0→1ではユーザーに早く価値を届けることが最も大事だと考えています。
今回、勉強会の中で最初の質問として「なぜPHPを利用しているのか?」という問いがあったのですが、 ママリにおいてPHPを利用している理由は、当時のメンバー構成で最も早くアプリケーションを世の中に出すためにCakePHPを選択したからです。

コネヒトが考える技術選択の仕方

前述のように、コネヒトでは目的に合わせた技術選択を心がけています。
あくまで、技術はユーザーに良い体験を届けるための手段です。
例えば課題の解決に取り組む際に、その課題がバージョンアップで対応可能なのか、それとも新技術を導入する必要なのかを検討します。 その上で、目的によって最適な解を選択します。その結果、以下のような技術選択を行ってきました。

Before After
PHP5 PHP7
CakePHP2 CakePHP3
Objective-C Swift
Java Kotlin
Vagrant, Chef Docker

繰り返しになりますが、ユーザーに良い体験を届けることが第一目的だと考えています。

技術選択とOSSの関係

OSSへの貢献は将来への大きなリスクヘッジだと考えています。
コミットできるくらい使い倒したり、最新のリリースや今後の開発方針などを把握していることは次の技術選択のとても有益な情報になります。
現在、社内にはCakePHPのコントリビューターが
3人います。 先日富田さんのブログにもありましたが、彼は日本でも数人しかいないKotlinのコントリビューターになってくれました! このように、OSSへコミットしたり、PlugInを公開しているメンバーがいるのはとても心強いことです。

発表資料

詳細な内容についてはぜひ以下の発表資料をご覧いただければと思います。

終わりに

1人の参加者としてもとても有意義な時間でした。
会場提供のBASEさん、一緒に登壇してくださったえふしんさん、白井さん、準備してくださった方々、お越しいただいた皆様有難うございました!

以上、島田(@tatsushim)がお送りしました! 明日のコネヒトアドベントカレンダーは伊藤(@itosho)さんのターンです!

追記

一緒に登壇してくださったお二人がブログを挙げてくださったのでご紹介します。

devblog.thebase.in

ameblo.jp