ゆーじのろぐスマートフォン用の表示で見るゆーじのろぐこの広告は、90日以上更新していないブログに表示しています。沖縄としてミートアップを開催することとなりました。今回JAUG沖縄のミートアップを開催するということで、非常に多くの方に応援のコメントもいただいたり、一緒にコミュニティを運営していきたいという方が出てきてくれたり、実際にMicrosoftの横井さんにリモートでセッションをしていただいたりと、様々な方にご協力頂きました。圧倒的感謝!!でございます。」というテーマでMicrosoftが提供しているAI系サービスの特徴やそれを利用していくための勘所などを紹介して頂きました。1,2年前ほどに勉強回でAzureのAI系サービスについて話を聞いたことがあったのですが、そこから精度が向上していたり、サービスのラインナップ自体も増えていたりと、この分野は継続的にキャッチアップしてプロダクトにどのように活かしせるか常に考えておくと非常に面白いなと思いました。(個人的にはTranslate系をもっとキャッチアップしておきたい。AppというAzureのPaaSの良さを発表させて頂きました。EBILABという飲食店をデータ駆動で経営改善を支援するBIツールを提供する会社の開発チームから、3人が登壇して頂きました。Azure」というタイトルでそれぞれ発表していただき、EBILABさんの開発の中の構成がすべて見えてくるとても充実した内容でした。EBILABさんの技術選定やアーキテクチャ構成などは一貫して「分業可能にすることで生産性を上げる」というコンセプトが通っていて、その分業可能なアーキテクチャを作る上でAzureの様々なマネージドサービスやServerlessテクノロジーを駆使することで本来大規模開発になるところを少人数でも開発可能にしているようでした。アーキテクチャ選定の思想や紹介してもらった様々なサービス群についてすぐにでも使える情報が多かったので、非常に勉強になりました。Learnを体験してみました。Learnを使ったもくもく会を開催したり、県外からのゲストを招いて様々な事例やAzureの最新動向をキャッチアップできる会を作ったりしていきたいと思いますので、今後ともよろしくお願いします。登壇者、僕が所属する会社であるPaykeはスポンサーとして参加しました!phpcon.okinawa.jp総勢140名近くの方が参加していただく規模のカンファレンスになり、沖縄だとハッカーズチャンプルーに次ぐ規模のカンファレンスになりました。ハッカーズチャンプルーは沖縄の各エンジニアコミュニティが協力して開催しているコミュニティですが、一つのPHPというコミュニティだけでこの規模のカンファレンスができ、しかも多くの県外から参加者も来ていただけたのはすごく良い事例になったと思いますし、参加者としても非常に楽しめたカンファレンスになったと思います!スポンサーとして今回始めての沖縄で開催させるPHPカンファレンスということで、少しばかりの応援としてPaykeもスポンサーさせていただきました。このようなカンファレンスで僕らのロゴが掲載されて、全国から来ていただいたPHPerの方々に少しでも認知していただけたなら嬉しい限りです。弊社CTOの花城はゲストスピーカーとして、「スタートアップにおけるプロダクト開発とエンジニア組織の変遷」と言う内容で登壇しました。沖縄でPaykeぐらいのスピード感で成長するスタートアップ企業はこれまでなかったので、その成長を遂げたエンジニア組織がどのように変化してきたのかという話は多くの方に興味を持っていただけたようで身内として非常に嬉しい限りです。あと弊社CTOの登壇に関する反響として一番多かったのは「CTOイケメンですね!」でした笑(うらやましい。登壇者として今回ボクは「技術基盤/SREの視点で取り組む、サービスの成長を継続し、加速させるためのPHPアプリケーション改善」というタイトルで登壇させていただきました。Paykeの開発組織の中で技術基盤という組織を作り、解決してきた課題の事例を通じてサービスの成長を継続させ、そして成長させていくためにどのようなことを考えながら意思決定しているかを伝えたいと思って今回の登壇内容を作りました。30分枠頂いてたのですが時間オーバーしてしまい、最後のほうは一部省いてしまったのですが、一番伝えたかったのは以下のページに書いた「事業目標を理解し、ボトルネックを解消する」ということです。技術基盤だからといってビジネスのことを考えなくて良いわけでは決してなく、むしろビジネスと事業の成長戦略、そして目標を理解し、その道の先にある技術的ボトルネックを見抜き予めかじめ取り除く、またはその戦略執行をより効率的・効果的に行えるような技術的な武器を整えておく、のようなことがPaykeの技術基盤には求められていて、これまでもそれを意識して意思決定を行ってきました。この登壇を通して「ビジネスを理解して、それを支えかつ強化する技術的な意思決定をすることが重要」ということをうまく伝えたかったのですが、うまくいったのかはあんまり自信がない。人前で話す事自体には最近だいぶなれてきたんですが、うまく伝えられるようになったかというそうでもない気がするので、次からは「伝えたいことを正しく伝える」ということをもっと意識して登壇に望みたいと思います。参加者として今回は運営スタッフとしての役割上、ずっとtrack_aの会場にいました。すべての登壇内容が面白く、かつ勉強になるものばかりで非常に楽しかったのですが、個人的なベストセッションを挙げさせていただくとランチセッションの「小さな機能、大きな仕事」が最高でした。自分もリファクタリングするときやもしくは自分が新規開発するときの基本的な考え方として「小さくシンプルな役割をもったプログラムをまず作り、それを組み合わせることで大きな役割をするプログラムを作る」というのを意識して行っています。それは「UNIXという考え方」という本で学んだことや、Clojureのような関数型言語でプログラムを作るときの作法から影響をうけてそうなっていたのですが、頭の中にぼんやりとあるだけでうまく言語化はできていませんでした。今回のこのセッションでは実際にもう作られて負債化しているシステムの要因分析やそれに対する改善方法のアプローチとして僕が暗黙知的に意識していた「小さなプログラムを組み合わせて大きなプログラムを作る」ということがうまく言語化されていて、登壇中も「あー、そうそう!そういうことなんですよね!!!」とこころの中で首がもげるかというほど頷いてました。フィーチャーとケイパビリティという言葉で「フィーチャー=ユーザーからみた機能(大きな仕事)」と「ケイパビリティ=フィーチャーを実現するための構成要素として必要な能力(小さな機能)」を明確に分けて話されていたのが印象的で、僕の辞書にはその言葉がこれまでなかったので非常に勉強になりました。「登壇内容めっちゃ良かった!」と伝えるのと「ajito.fmのファンでめっちゃ聞いてます!」ということを直接伝えられなかったのが個人的には心残り。スタッフとして今回PHPカンファレンス沖縄は最初はスタッフとして関わる予定ではなかったのですが、実行委員長のカンボさんに直接誘っていただいたのがきっかけでコアスタッフとして途中参加させていただきました。僕がやったことは以下のような感じです。Paykeにスポンサーとして参加してもらう。当日のビデオ撮影(スタッフ用)後片付け今回のイベントは他のコアメンバーがすごく頑張っていて「途中から参加したのにあんまり貢献できていないな~」とちょっと罪悪感的なことも頭の中には浮かんでいたのですが、こういうカンファレンスは小さなことでも自分ができることをやってくれる人達の集合で成り立っているので、ここは罪悪感を忘れて「自分も運営に貢献したぞ!」と自信を持って言いたいと思います。おれも自分のできる範囲で運営がんばったぞー!!!スペシャルサンクス今回のイベントが無事開催できたのは、会場提供してくださった株式会社プロトソリューションさんの全面協力のおかげでした。会場提供だけではなく、会場準備や後片付けにもスタッフを参加させてもらって協力してくれるだけでなく、当日の備品で足りないものが見つかったときに会社にある備品を貸し出してくださったりと非常に多くのサポートをしてくださったことで今回のカンファレンスを無事やり遂げる事ができたと思います。16:20PHPカンファレンス沖縄2019に、個人としては運営スタッフ&登壇者、Paykeはスポンサーとして参加しました!Tweet広告を非表示にするもっと読むコメントを書く2019-09-30会議終了後に必ず作成してもらうアクションサマリー(または議事録)会議は意思決定のためにするもので、かつその意思決定を正しく素早く伝達するために、自分は会議終了後には基本的には必ずアクションサマリーを書いて共有するようにしている。アクションサマリーとは、会議で話して決まった以下の内容を簡単にまとめたものです。「マーケティングとは「組織革命」である。」という本を呼んでいたら、会議後に提供するアクションサマリーについて書いていた。マーケティングとは「組織革命」である。見るこの本によると、アクションサマリーは以下の内容を描く必要があるそうです。)そしてこの内容を会議から24時間以内に全体に公開することが義務付けられれているそうです。これにより、まず会議の関係者に正しい素早くアクションしてもらうためのシステムとして機能するとともに、情報や意思決定の透明性を上げることを組織に浸透させていくという2つの効果があるそうです。これをもとに、僕の組織でも使えるように以下のようなアクションサマリーのテンプレートを作成しました。アクション(誰が、なにを、いつまにするのか?)これでうまく回るか試してみます。それを毎回月曜日と日曜日の日付をカレンダーで調べて書くのが面倒過ぎたのでrubyで簡単なスクリプトを書いた。コードはgistに公開しています。gist.github.comこれでほんのちょっとだけ楽になる。2019/09/16(月)〜2019/09/22(日))を出力するコマンドを書いたTweet広告を非表示にするもっと読むコメントを書く2019-09-02#てらだよしおまつり、沖縄開催でDocker/k8sのハッカソンを2日間行いました!#てらだよしおまつり、沖縄開催でDocker/k8sのハッカソンを2日間行いました!2019年8月24日(土)〜2019年8月25日(日)の2日間、CODEBASEを会場にお借りして、Microsoftの寺田佳央さんを講師にDocker/k8sのハッカソンを開催しました!寺田さんは今回JavaやKubernetesの関連の勉強会で全国ツアーを行うという挑戦を行っており、今回のその全国ツアーのファイナル、沖縄開催を僕がJavaKuecheとして運営させていただくことになりました。Serviceのハックフェストを行っておりました。arakaji.hatenablog.comそこでKubernetes自体やAKSについて学びながら、このコミュニティイベントの打ち合わせもしており、そこで寺田さんから「初級者、中級者で2チームに分けてモブプロ形式で進めたいので、プロジェクターか大きなディスプレイがふたつあるとありがたい」と言われていたので、コミュニティイベントの当日は会場のスタッフと一緒にプロジェクターを2つ用意しておきました。僕は初級者チームと一緒に進めて行きますね!」とおっしゃられて急遽中級者チームのハッカソンをリードすることに!最初は心の準備が出来ておらずうまくできるかどうか不安だったのですが、実際に資料を見ながら進めていくと数日前にやった寺田さんとのハックフェストで学んだことがしっかりと頭と体に染み付いて、思いの外うまくすすめることができました。忘れてしまっていたことなどもいくつか有りましたが、そこは一緒にモブプロしている参加者の人と調べたり、寺田さんに助けて頂いたりすることでアウトプットと復習のサイクルがバンバン回って自分の中で理解がより深まっていきました。ハッカソンも無事終わり、イベント参加者からも「わかりやすかった」、「面白かった」という良い感想を頂いたり、寺田さんや一緒に来ていただいたクラウドアドボケイトチームのマネージャーであるクリスティーナさんにも「ファシリテート素晴らしかった」とお褒めの言葉をたくさん頂いたので、僕自身もたくさん学べて楽しかったし、みなさんも多くを学んで楽しめた良い回に出来たのだろうと満足しています。〜アジャイルとブロックチェーンと日本の政治とマイクロサービス〜ハッカソン最終日の打ち合げで近くの居酒屋をお借りして懇親会を行ったのですが、個人的に面白かった話の流れがあったのでご紹介します。会場では席が二席に分かれていて、まず僕がいる席に寺田さんが座っていて、そこでの話題はアジャイルやマイクロサービスについてでした。いまの世界はビジネス=ソフトウェアの時代であり、そこで勝っていくにはアジャイル、DevOps、そしてその後のマイクロサービスみたいなことを理解して実践していかないといけない。ビジネスを作る人や経営者にとってアジャイルやDevOpsみたいなワードを直接出す必要なくて、新しいバージョンのソフトウェアを速く出せるだとか変化に対応できるだとかの、今抱えている直接的な課題を解決するということだけ理解してもらえば良くて、彼らにとってはそのための手段は別に何でも良い。バリューストリームマッピングをすべて洗い出し、そこで新しいバージョンをリリースするために工数がかかっているボトルネックを洗い出し、それをなにか手法やツールやアーキテクチャによって解決し、それによって工数がどれだけ短縮されるなどを提示するとアジャイルやDevOps、マイクロサービス、A/Bテストなど僕らがやりたいことは直ぐに実行することができるし、逆にいうとそういうメリットがないのであればやる必要もない。ような話をしていました。そのあと、寺田さんと一緒にイベントに来てくれたMicrosoftのクリスティーナさんが席を変わりました。クリスティーナさんはMicrosoftでのクラウドアドボケイトチームのマネージャーという仕事のほかに、ブロックチェーンを用いたデジタルアイデンティティの証明というプロジェクトを行っており、その活動が評価されてForbesの世界に影響を与えるUnder30の30人のうちの一人として選ばれている方です。「新機能を作るけど、リファクタリングやいらない機能の削除とかしてなくて肥大化しているんですね〜。「法律もうまくいくかどうかわからないんだから、まず小さくリリースしてA/Bテストしたいですよね〜。「日本自体が大きなモノリスなアプリケーションになっているからね〜。「全Serviceに必要な機能はアスペクト指向的に横断的関心をマイクロサービス基盤側が用意して各Serviceに注入できるようにする必要があるね。Istio的なものが求められる」など、寺田さんと話していたアジャイルやDevOpsの話を日本の政治の話とつなげて、ソフトウェアエンジニアリングの発想で日本の政治をリアーキテクチャするアイディアが話されていて、面白おかしくありつつも、以外と的を得ているのではないかとおもって非常に印象的でした。最後に今回東京から来ていただいた寺田さんにクリスティーナさん、参加してくれた皆様、会場を提供してくれたCODEBASEさん、本当にありがとうございました!いま僕は仕事でAzureを使っていますが、いま使っていること以上にAzureのテクノロジーを楽しみながらうまく使いこなし、世の中に大きな価値を出すプロダクト作りたいと考えていて、その一環で今後もAzureに関する勉強会などを開催していくと思います。ペアプロした2日間、自社サービスをAKSに乗せる過程で学んだこと2019年8月21日(水)〜22日(木)の2日間、Microsoftのクラウドアドボケイトである寺田佳央さんに弊社に来ていただいてHackfestを開催して頂きました。Hackfestとは、Microsoftのエンジニアの方と自社が抱える課題をテーマとして決め、それを一緒に解決していくというイベントです。今回はAzureを使った基盤をテーマにしていて、Azureを使ったインフラを管理しているのは弊社で基本僕のみのため、寺田さんと2日間がっつりペアプロできるめちゃくちゃ貴重な機会でした。非常に多くの学びが得られる濃密な体験だったため、その学びをブログで共有したいと思います。〜今回Hackfestを開催していただけた経緯が2つあります。1つは僕が自社のサービス基盤としてKubernetesを使うことを考えていて、Kubernetesを学んでいることをTwitterに投稿していたのを寺田さんに見ていただいたこと。ジャパンツアーを行う計画をしており、その沖縄開催を行うので、その数日前にハックフェストをやりますか?という提案を頂いたことでした。Serviceについてのハッカソンをとりあえず始めるという流れになるかな〜と考えていたのですが、寺田さんがまず最初に行ったのは「御社の現状の開発体制やシステム/サービスの構成、そしてなぜKubernetesを使いたいと考えていたのですか?」と僕らの現状と課題をヒアリングするところからでした。寺田さんが今回のハックフェストやその後行ったコミュニティイベントでも終始おっしゃっていたのが、「Kubernetesも課題を解決するための道具でしかない。すべてをKubernetesでやるべきではなくて、Kubernetesが得意でかつ自分達の課題に合っているところだけを使いましょう」ということでした。この姿勢は本当にプラクティカルで、僕も同じような姿勢で仕事しようとはしていますがたまに「この技術が流行っているから導入したい」になってしまうことがあります。エンジニアとして「技術を用いて課題を解決すること」を職務とする以上、この姿勢は見習わないといけないと思いました。寺田さんにヒアリングしてもらった中で整理された現状と、僕がKubernetesで解決したいと考えている課題は以下の通りでした。現時点では数個のサービスが稼働しているだけなのでKubernetesなしでも問題ないただし、今後1年以内にどんどん新しいサービスがリリース、既存サービスのアップデートがされていく可能性が非常に高い製品開発のエンジニアはどんどん採用を強化していくが、SREの方は増えてもあと一人くらい。Serviceに乗せてみて、CI/CD、スケーラビリティの確保、ログ収集・モニタリングの設定などを構築してみる」をテーマにHackfestを行うこととなりました。Portal画面に入ったあとにAKSなどの各種リソースを作成する際、寺田さんからCloudShellというAzureの機能について紹介して頂きました。CloudShellというはAzureのポータルから起動できるShell環境で、ブラウザからそのCloudShellを使うとBashやPowerShellを使った各種コマンドが使えるようになります。Storageに保存されるため、そこにシェルスクリプトを配置して実行するなんてことも可能ですし、CloudShell上から秘密鍵を用いてSSHでVMにログインすることもできます。僕はこのとき初めて知ったのですがAzureのスマホアプリが実はあり、そのスマホアプリ上でCloudShellを起動することが出来ます。コマンドが使える上にもしものときはモバイルからも操作できるので、これは今後もよく使っていこうと思いました。〜イメージのサイズを小さくすること、開発効率向上のためのマルチステージビルド〜実際のアプリケーションをkubernetesに乗せるというテーマだったので、まずアプリケーションのコンテナ化から開始しました。構築しているのでDockerfile自体はすでにあったのですが、それを単純にイメージにすると4GB超えの巨大なイメージになってしまったため、そのスリム化に着手することに。1.4GBほどでまだまだでかい。最終的にこれ以上スリム化するのはアプリケーションの構造やFROMで設定しているイメージの変更など、大幅な変更が必要だと判断して一旦今回はそのまま行くことになりましたが、このイメージ作りの過程で寺田さんか以下の点を教わりました。イメージサイズを小さくしなければいけないのか開発効率を上げるために行うコンテナのマルチステージビルドなぜイメージサイズを小さくしなければいけないのかデプロイやスケールアウトにかかる時間が遅くなるコンテナで作ったアプリケーションをデプロイする、またスケールアウトするためには該当するバージョンのイメージをコンテナレジストリからダウンロードしてからそれを起動する必要があります。イメージのサイズが大きいとその分ダウンロードにかかる時間が増えてしまい、それによってデプロイ・スケールアウトの速度が低下してしまいます。同じサーバー上で同じイメージを使う場合にはキャッシュが効きますが、新しいバージョンのデプロイ、またホストマシンがマネージドサービスの場合などはキャッシュが効かずダウンロードが発生するケースが多いのでイメージサイズの大きさはかなり速度に悪影響を及ぼします。本番環境にデプロイ・スケールアウトするとき以外にもCI/CDを組むと、それらを回すたびにイメージのダウンロードが発生し、その速度がCI/CDの速度の低下、引いては開発速度の低下につながってしまいます。Servicesを使う場合にNodeとして扱うサーバーは仮想マシンになります。仮想マシンなので当たり前ですがディスクサイズの制限があります。ここに大きいサイズのイメージがずっと貯まり続けていくとディスクサイズの圧迫に繋がります。ホストマシンであるNodeに入って不要なイメージを削除することで対応することは出来ますが、それを頻繁に気にしないといけない状態は良くないのでイメージサイズは小さい方がいいです。開発効率向上のためのマルチステージビルドイメージ作成の際、最初はひとつのDockerfileにすべての設定を書いていたのですが、あとからbase-DockerfileとDockerfile2つにファイルを分けてイメージ作成をするようにしました。base-Dockerfileは実行環境に必要なものを作るDockerfileで、ApacheやPHPのインストールや設定などを入れていきます。installなどをしています。このように環境とアプリのDockerfileを分離することで、責任範囲を明確にし、依存の関係もはっきりします。Dockerfileの書き方を変えてキャッシュの効き方を最適化する上でも効率的に作業できるようになりました。Services上からイメージをダウンロードできるようにリモートのコンテナレジストリにプッシュしなければなりません。Registryのサービスがあるので、そちらを利用しました。Registryとプッシュ/プルすることができます。azコマンド経由でレジストリにログインしてプッシュ/プルすることができるのでセキュリティ的にはこっちの方がよさそうです。Serviceを使いながらの基本概念を学ぶ実際にデプロイするイメージを作ったあとは、実際にAKSを使いながらKubernetesの理解を深めていきました。NodeNodeとは、Kuberntesのクラスタが乗るホストマシンの事です。AKSの場合、Azureの仮想マシンをNodeとして使用しています。Nodeとして扱う仮想マシン群は、ひとつの可用性セットという含めることでパッチ適応によるアップデートや物理障害時にすべてのNodeがダウンしないように管理されています。単一リージョン内の可用性セットにNodeが含まれている状態のため、リージョン全体に対する障害などは保護されていません。Managerを配置してルーティングを管理する必要があります。AKSでの事業継続性の担保やディザスタリカバリーについてはAzureドキュメントが用意されているのでそちらを参考にすると良さそうです。docs.microsoft.comPodPodとは、「複数のコンテナを束ねたもの」です。Kuberntesが扱う最小単位がこのPodになります。Podの特徴として、「Podとして束ねられたコンテナは必ず同一ノードにデプロイされる」という特徴があります。PHPアプリケーションのよくある構成として、前段にnginxをおいてリクエストを受け取けから後ろにいるphp-fpmに流してで処理を行うという2段構成になることがあります。その構成においてnginxとphp-fpmが動くNodeが別のNodeになるとマシンを超えたネットワーク通信が発生しパフォーマンスがその分悪化してしまいます。それをPodという単位に束ねることで同一ノードにデプロイされ、通信のオーバヘッドが抑えられる効果があるので、依存関係の強いコンテナ同士はPodにまとめる必要があります。Pod自体は単体で動作しますが、それ自体にKubernetesの特徴として取り上げられる以下のような機能は持っていません。ローリングアップデートヘルスチェック自動修復機能スケール・オートスケールDeployment各Podに対して、ローリングアップデート、ヘルスチェック、自動修復機能、スケール・オートスケールなどを設定しているのがDeploymentです。readiness)、スケール(replicas)などを定義するとKubernetesに反映させることができます。今回のハッカソンでは、yamlレベルではDeploymentを最小単位として操作しました。ServiceServiceとは、「論理的にまとめられたPods群に対する通信ポリシーを定義するもの」です。Kubernetes上にデプロイされたPodは各ノードに配置されそれぞれプライベートのIPアドレスを持っています。新しいバージョンのアプリをリリースするたびに新しいPodが作られ古いPodは削除されていくので、そのIPアドレスに対して通信することは適切ではありません。Serviceは特定のPods群に対する通信を管理し、そのサービスに対してのドメインが自動で割り振られます。そのドメインに対してリクエストを送るとServiceが管理しているPods群に対してリクエストが行くという仕組みになっています。ServiceはあくまでKubernetesクラスタ内部での通信を管理するもののため、Service自体を外部からのリクエストを受けれるように公開することは推奨されていません(Serviceの指定をLoadBalancerにすることで外部公開することができるが、やるべきではない)クラスタ外部からの通信を受けれるようにするには、Ingressというものをつかいます。IngressIngressは外部サービスのリクエストを受けつけ、それをKubernetesクラスタ内部にあるServiceにルーティングする役割をもっています。基本的にnginxをingressとしてAKSクラスタ内にデプロイされ使用します。Balancerというマネージドサービスを使うこともできるようです。Serviceによって何を得られるかがわかってきました。ブルーグリーンデプロイメントにより安全なリリースブルーグリーンデプロイメントとは、新しいバージョンのアプリをリリースする際に既存の環境のソースコードをアップデートするのではなく、新しいバージョンの環境(サーバー)自体を作り、リクエスト向き先を変えることでリリースデプロイを行うことです。これにより、もし新しいバージョンのアプリに不具合があったとしても前の環境をしばらく残しておけば向き先を変えることで即座に復旧することができます。Kubernetesにブルーグリーンデプロイメントを行うには、ブルーとグリーン2つのDeploymentを作り、そこへのリクエストをServiceのフィルタリングで切り替える方法があります。blue-deployment.yamlとgreen-deployment.yamlというファイルを作り、そのファイルのラベル付けでversionというラベルにblueとgreenをそれぞれ設定しておきます。Service上の通信ポリシーではblueのみ通信が行くように設定しておきます。新しいバージョンのアプリをデプロイする際にはgreen-deployment.yamlの方に新しいDockerイメージを名前とラベル(webapp:2.0など)を指定してKubernetesクラスタ上にデプロイします。デプロイが完了したらServiceの通信ポリシーをblueからgreenに変更すると、即座にgreenがリリースされることになります。不具合が発生したらService通信ポリシーをgreenからblueに変更すると、前のバージョンに即戻すことができます。これをさらに応用すると、greenをデプロイしたあと、一般ユーザーに公開しているドメインからのリクエストはblue、開発者用のドメインから来たリクエストはgreenにリクエストを流すという風に設定することで、本番とまったく同じ環境で安全に動作検証をして問題なければリリースと言うフローを作ることも可能になります。このブルーグリーンデプロイメントによる安全なリリースにより、以下の効果があると考えています。簡単に元に戻せることにより、事前のクオリティ担保のためテストを減らしてリリース頻度と速度を高めることができるKubernetesを使わなくても、自分で仕組みを構築するなどすれば出来なくはないですが、それを簡単に作れる仕組みがあるのは非常に魅力的に感じました。Servicesを使った場合のメリットになります。Kubernetesは複数のNodeの上にクラスタを作ってPodを稼働させるため、クラスタに参加しているNodeの合計のリリース量(CPU,メモリ、ディスク)によってPodがスケールアウトできる数に物理的な制限が発生します。あとからNodeを追加することも可能ですが、クラスタへのNodeの追加には非常に時間がかかるため突発的または計画的に急激なアクセスが発生する場合にNodeの数を毎度増減するのには向いていません。Instancesに切り替えるとNodeの制限を超えた数のPodを走らせる事が可能になります。Instancesに切り替えてスケールアウトし、通常に稼働戻ったらまたNodeに戻すことでコストの最適化をしながららスケーラビリティを確保することができます。WebAppを使っている場合と単純なVMを使っているもの、単純なVMを使っているものもAnsibleによって設定がコード化されているものとされていないものなどが乱立している状態です。それらへデプロイフローもそれぞれ違う状態になっています。これをKubernetes化することにより、インフラ環境やデプロイフローなどはKubernetesのyamlファイルでコード化・共通化され、アプリの実行基盤はDockerfileによるコード化されることになります。これによって、サービス毎に作らなければならないインフラやDevOps周りの共通部分を再利用しやすくなり、製品開発チームが増えサービスが増えていくときにSREがボトルネックとなることが防げると考えられました。Kubernetesのデメリットはなにか?今回のハックフェスト通して寺田さんは常に「すべてをKubernetesでやるべきではない。Kubernetesも銀の弾丸ではない」ということをおっしゃっていました。寺田さんが明示的におっしゃっていたことと、僕が考えたことを交えながらKubernetesのデメリットも書いておこうと思います。Kubernetes自体のバージョンアップへの追従Kubernetes自体のバージョンアップが3ヶ月に一度リリースされます。その度に大きな機能追加が発生したり、いま使っているyamlファイルの記法が変わり新しく作り直す必要が発生する可能性があります。Serviceのバージョンポリシーが最新から4バージョンまでをサポートするという方針です。それはつまり、「いま最新バージョンのKubernetesを使っても来年には必ずバージョンアップをしないといけない」ということです。4バージョンのアップデートはかなり大変のため、現実的には3ヶ月または半年に一度はバージョンアップしていくという方針になるでしょう。このバージョンの作業も複雑な構成のクラスタを組めば組むほど、サードパーティのライブラリを入れれば入れるほど困難になっていきます。これをKubernetes上のクラスタに載せた場合、以下のようになります。DB通信経路上にKubernetesが扱っているコンポーネントが登場し、障害発生した場合やパフォーマンスチューニングを行う場合はそれらのコンポーネントをすべて考慮にいれて対応しなければなりません。Kubernetesがもたらした大きな柔軟性とそれによって得られるアジリティはこれらコンポーネント、抽象化の層によってもたらされています。逆に障害時やパフォーマンスチューニング時はその抽象化の層を降りていく必要があり、抽象化の数だけ降りなければいけないのはいわば当然のトレードオフになります。僕が考える、Kubernetesとはなんのための、そして誰のためのソフトウェアかこれも寺田さんがおっしゃったことではなく、あくまで今回のハックフェストを通して僕が考えたことです。僕は今回のハックフェストを通して、Kubernetesは「少人数のSREチームで、たくさんのマシンリソースを効率的に使いながら、たくさんのサービス、そしてそのサービス開発自体を支えるためのソフトウェア」だと理解しました。Kubernetesは、素晴らしい機能群によってインフラに大きな柔軟性をもたらし、それによってデプロイ、復旧、スケールアウト、マルチバージョンのリリースによるABテストなど様々なことを簡単に実現できるようにしてくれます。クラスタ内のNodeに集積してコンテナを稼働させることによって効率的にマシンリソースを使うことも可能にしてくれます。そのトレードオフとして、Kubernetes自体のバージョンアップへの追随やトラブル時にKubernetesの抽象化を理解して降りていく必要性が発生します。Kubernetesを導入する場合、イニシャルコストよりもこのランニングコストの方をよく理解しておいた方が良いと思いました。Appなどのマネージドサービスを使う方がメリットが大きいと思いますKubernetesというソフトウェア自体は面白いですし、今後もキャッチアップを続けていきますが、自分達の事業や開発チームにとってホントに必要なタイミングは見極めた上で導入は検討していきたいと思います。DevOpsというツールを使ってCI/CDのパイプラインを作ることになりました。Pipelineなどが使えます。いうパイプラインを作っていきました。これらのパイプラインを作るのがすべてGUIでタスクを選択して設定を入れていくだけ構築することができ、大体2~3時間程度ですべて構築することができました。このパイプラインはGUIだけでなくyamlで定義することもできます。DevOpsはぜひ導入していきたいと思えました。今回のハックフェストはずっと寺田さんとペアプロする形で進めていたのですが、僕にとって今年一番の集中力が発揮され、2日間のハックフェスト中まったく集中が切れることなくすすめる事ができました。集中力が深く長時間維持できたことでかなり効率よくハックフェストをすすめることができ、当初3日間やる予定だったものが2日間で終わらせることができ、僕も寺田さんもヘロヘロになって「明日は休みましょうw」となる程でした。寺田さんが一緒だったということが非常に大きかったとは思いますが、ペアプロ/モブプロすることにより一人でやるよりも「いまやるべきこと」が明確化され、集中しやすい。予期しないことがあってハマった場合、複数の脳で解決策を探索して議論して素早くトライすることで解決が早い一緒に同じ画面を見て作業することで、予期しない学びが得られる(bashのショートカットやデバックの仕方など)のような効果を身を持って体感することができました。今回はハックフェストでしたが、実際の業務でもペアプロ/モブプロを取り入れてみて生産性が上がるかどうかぜひ試して見たいと思いましたし、僕がこれからコミュニティで勉強会などやるときもペアプロ/モブプロの使ってやってやりたいとおもいます。最後に今回のハックフェストを寺田さんに開催していただいたことで、僕個人としてはAzure/Kubernetesに限らないほどエンジニアとして多くの学びを得る事ができました。Serviceを使うべきかどうかの技術検証を、わずか2日間のハックフェストで実際に動かしながら把握することができたのは非常に投資対効果が大きかったと考えています。今回学んだことを実際の現場に活かして、より良いサービスを作っていきたいと思います。Storageというマネージドサービスがあるのですが、そのQueueStorageをバックエンドとして利用したPHP製のジョブキューライブラリを作りました。Heavyなアプリケーションになっており、ユーザーがプッシュ通知などで大量アクセスするとWebApp側はスケールできてもRDB側がスケールできないという課題がありました。それに加えて、2年程まえに自分達で自作していたジョブキューシステムがあったのですがそれがアプリケーションで使っているRDBをそのままバックエンドとして使用しており、その性能限界により「ジョブ登録が大量に来るとロック待ちが発生し障害の元となる」、「ジョブが詰まったときにワーカーを増やして処理性能をあげたいがRDBのパフォーマンスネックによリこれ以上ワーカーを増やせない」という問題もありました。Storageを用いたジョブキューライブラリを作り、ユーザーからのリクエストで直接RDBに書き込みをするのではなく新しいジョブキュー経由で書き込みをするように変更することでDB負荷の軽減と既存ジョブキューライブラリの課題を解決させたいと考えました。Storageには対応していない状況だったため自分で作りました。インストールできるように公開しているので、以下の内容をプロジェクトのcomposer.jsonに追記してください。自分のJobを定義する以下のように\Backjob\Jobクラスを継承して自分の独自Jobを定義します。}}runメソッドはJobが実行されるときに呼ばれるメソッドです。このrunメソッドの中でこのJobが実行したいタスクの実装を書いていきます。Jobを登録するときにパラメータが渡せるようになっているのですが、そのパラメータは$this->paramsの中に連想配列で入っています。このrunメソッドは必ず定義してください。failメソッドとsuccessメソッドは実装してもしなくても構いません。successメソッドはrunメソッドが正常に実行されたあとに呼ばれるメソッドです。failメソッドはrunメソッド内で例外やエラーが発生したときに呼ばれるメソッドです。それぞれ自分たちのアプリケーションの要件に合わせて利用してください。Jobの登録、そして登録されたジョブの実行の仕方キューへのジョブの登録、そしてキューからジョブを取り出して実行するために利用するBackjobクラスのインスタンスを作ります。Storageの名前、ストレージアカウントのアクセスキーを与えます。makeJobメソッドに引数としてジョブに渡したいパラメータを連想配列で渡し、インスタンス化します。その後、Backjobインスタンスのインスタンスメソッド、queueの引数としてジョブを渡して上げればジョブキューへの登録が完了します。CustomeJob::makeJob($params);$backjob->queue($job);ジョブキューに登録されたジョブを実行するには、Backjobインスタンスのrunメソッドを実行します。runメソッドを実行すると、ジョブキューからひとつのジョブを取り出し、そのジョブをrunメソッドを実行して処理を行います。Backjob'このrunメソッドをcronで叩く、もしくはdaemon化してループで呼び続けるコードをそれぞれ使っているフレームワークの流儀に沿って作っていただければOKです。今後について自分達のプロダクトに必要だったから作ったライブラリなので、今後も必要に応じてアップデートはしていく予定です。Storageを複数設定できるようにして負荷分散に対応する、またqueueへの登録が失敗したときのretry回数やtimeoutの設定できるようにするなどはやりたいと考えています。現時点で一週間で40万件以上のジョブを処理しているので、ちゃんと使えると思います。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。