2024年版 Colorkrew 自社サービスのインフラ業務の現状
こんにちは。Azure Cloud Solution Architect 兼 DevOps Engineer の秋山です。 自社サービスのインフラリードを担当しています。 前回書いたブログが2年前になってしまいましたので、ここで最近のインフラの状況についてまとめてみます。 自社サービス Mamoru Biz で AKS 導入1周年で振り返る プロダクト開発チームの増加に伴う効率化 最も大きい変化はこれです。 2年前は自社サービスイコール Mamoru Biz(現在の Colorkrew Biz) でしたが、現在は「Colorkrew ID」「Colorkrew Intra」「AI Chatシステム」や開発中のプロダクトなど多岐にわたります。 いずれの製品もクラウドインフラを活用しているため、新しいシステムのインフラ構築を効率的に行う必要があります。 自社サービスのインフラチームは私を含めて現在4人、全員受託案件など他の業務と兼任しています。 直近の1,2年ではおおまかに以下の内容を進めることで、インフラ業務が滞らない状況を作り上げてきました。 プロダクト開発チームからの依頼テンプレート化 インフラ・デプロイコードのモジュール化 最新技術のトライアンドエラーとフィードバック 本エントリではこれらを順に説明します。 プロダクト開発チームからの依頼テンプレート化 弊社ではソースコード管理に GitHub を利用しています。 新しいプロダクトの開発が始まるタイミングや既存プロダクトで新たなクラウドインフラが必要になったときに、GitHub Issue に内容をインフラチームが自身でまとめるようにしました。 そしてそれが大体パターン化されてきたため、 Issue テンプレートを用意して、プロダクト開発チームに記載してもらうようにしました。 ref: リポジトリ用に Issue テンプレートを設定する 内容は以下です 必要なクラウドインフラリソース(DB, Storage, …etc) Kubernetes リソース(Pod, CronJob, …etc) デプロイフロー 環境別の期日(Debug は ASAP, Prod は2か月後, …etc) チャットのラリーで必要な情報を埋めていくのは非効率なため、一度で大半の情報を網羅できるのは効率的です。 また、プロダクト開発チームは別のプロダクトのインフラ依頼内容を参考にすることで、サイロ化を防ぎ横のつながりや理解にもわずかながらつながるという副次的な効果も見えています。...自社サービス Mamoru Biz で AKS 導入1周年で振り返る
こんにちは。Azure Cloud Solution Architect の秋山です。 今回の記事では自社サービスで AKS 導入を始めて1年が経ち、どうやってきたか、何が変化したのかについて書きます。 1年前に書いた Azure Kubenetes Service(以下 AKS) 移行の記事は以下です。 Vol.1 App Service から AKS へ移行の決断 Vol.2 AKS(k8s) 移行の下準備 Vol.3 AKS(k8s) 移行 AKS クラスターバージョンの更新管理 AKS では最新バージョンから２世代前までのマイナーバージョンをサポート対象としているため、 4-5カ月周期でリリースされるマイナーバージョンをキャッチアップする必要があります。 参考:AKS Kubernetes リリース予定表 Mamoru Biz では AKS クラスターをインプレースアップグレードと呼ばれる手法で更新しています。 システムが利用中のクラスターのバージョンをアップグレードし、ノードを順にアップグレードする方法です。 参考:Azure Kubernetes Service (AKS) クラスターのアップグレード もう一つ Blue/Green デプロイメントと呼ばれる手法も検討しましたが、利用していません。 下の図のように、現行クラスターに加えて新バージョンのクラスターを用意し、Front Door や Traffic Manager などで切り替える方法です。...自分自身で34,560人に直接価値を提供するか、自分のプロダクトで億人に価値を提供するか。 プロダクトオーナーとはそういう仕事。
はじめに : なぜ、プロダクトを作るのか。 社会人生活が22歳から始まり70歳で引退とするならば1営業日に3人出会って何かしらの価値を提供したとして、48年×240営業日×3人 =34,560人に影響を与えられることになります。 この数字も実際には非現実的なので実際にはどんなに多くとも1万人〜数千人といった感じでしょうか。 自分自身だけで仕事を通じて価値を提供するという選択をした瞬間に時間的な制約が発生してしまいます。 一方で自分が創り出したプロダクトは、時間的な制約を回避し、場所の制約を回避し、成功できるかにもよりますが億人に価値を提供することさえも可能です。 だから私はプロダクトを作っています。 私は、今Mamoruシリーズのプロダクトオーナーをしています。 Mamoruシリーズには、プッシュ通知&QR認証サービス 「Mamoru PUSH」と、この認証技術をDX推進に活かした ビジネスコンシェルジュツール 「Mamoru Biz」の2つがあります。 特に、このブログではMamoru Bizを絡めた説明をしていきます。 プロダクトオーナーとは何なのか プロダクトオーナーの仕事を一言で言うならば、プロダクトに関わる全役割の頭脳を持った指揮者です。 プロダクトを0→1で作る際には、法令違反していないか、他社特許に抵触していないか、規約はどうするのがベストかといった法務視点。 収益構造はどうなっているか、何年後にどの程度の事業になるのか、自社経営資源を有効活用できているのか、自社の市場価値を上げられるかなどの経営視点。 その他、営業、カスタマーサクセス、マーケティング、UI/UX/グラフィック、フロントエンド/バックエンド/インフラといった領域に関して考慮し最終的な意思決定者である必要があります。 とカッコつけたいところですが、実際の仕事はかなり泥臭くバリューチェーンの中で課題があれば埋めにいく方が多いです。 時には、各役割間で揉めていた際に仲裁に入るとかそんな感じです。そんな仕事の中で最も大事にしていることは、プロダクトとしての価値をブラさず磨き貫くことです。 プロダクトを作って展開するといろんなことが起きます。 その時々で軸をブラさずに時にはやることを選択し、時にはやめる決断をしていかなくてはいけません。 Mamoru Bizの話をすると、Mamoru Bizは ”名もなき仕事を減らすビジネスコンシェルジュツール” というコンセプトを大事にしています。 Mamoru Bizのプロダクトの価値としては、いかに働く方の名もなき仕事をビジネスコンシェルジュのようにツールが減らせるかということにあります。 そのこだわりこそが価値となり、プロダクトに宿るのです。 私は魂を込める作業と言っています。 ちょっと宗教ぽく感じる方もいるかもしれませんが、プロダクトに魂を込めると、プロダクトが勝手に成長したり性格を持っていきます。 そこまで育てあげられると大体のプロダクトは成功します。 プロダクトオーナーMamoru Bizを語る。 Mamoru Bizは、おかげさまで上場企業を中心に導入500社を突破し、メイン機能である座席表の座席管理というカテゴリーにおいては市場における存在感を示せるようになってきました。 中でも東京都庁、東京大学、放送局といった国の基盤を支えている組織に導入いただいており常に気を引き締めてプロダクト作り、運営をしております。 そんなMamoru Bizの他社との差は 魂を込めている価値でありコンセプト部分ですが、その他にはシリーズで培ったMamoru PUSHの認証やセキュリティー技術によって大企業の皆様にも安心してご利用いただいてる点、そして何よりインターナショナルでカラフルなメンバーで開発、デザイン、営業をしていることにあると思っています。 今後の展望としては、まず日本市場で受け入れられた後、今はブラジルでだけ展開していますが海外に展開して海外ならではの名もなき仕事を解決していきたいと思います。 最後に、 我々Colorkrewでは、”Color Your Work with Excitement” のビジョンに向けて今後どんどんプロダクトを作って発信していきたいと思っています。...自社サービスで Azure App Service から Azure Kubernetes Service に移行した話 vol.3
こんにちは。 Azure Cloud Solution Architect の秋山です。 今回は前回に引き続き弊社の Mamoru Biz で k8s に移行した話について書きます。 Vol.1 App Service から AKS へ移行の決断 Vol.2 AKS(k8s) 移行の下準備 Vol.3 AKS(k8s) 移行 <- 本記事 移行をどのように進めたかについて書きます。 まずは移行のスコープの検討です。 移行の進め方 今回の移行では Azure インフラの置き換えが主であり、例えばアプリケーションが動作している Docker コンテナについてはこれまでのものをそのまま k8s 上で動かすことにしました。 (Mamoru Biz では Docker イメージを管理しているのは基本的にアプリケーションエンジニアです。) これは、できる限りインフラエンジニアがコントロール可能な範囲で移行を進めるための措置です。 (実際には k8s 上で動くようになった後に App Service 向けにカスタマイズしていた Docker コンテナを修正する、ということも追って対応しました。)...自社サービスで Azure App Service から Azure Kubernetes Service に移行した話 vol.2
こんにちは。 Azure Cloud Solution Architect の秋山です。 今回は前回に引き続き弊社の Mamoru Biz で k8s に移行した話について書きます。 Vol.1 App Service から AKS へ移行の決断 Vol.2 AKS(k8s) 移行の下準備 <- 本記事 Vol.3 AKS(k8s) 移行 Vol.2 AKS(k8s) 移行の下準備 前回の記事 で移行することは決めました。 次のステップは移行を始めるためのリソースの確保とチームへの説明です。 リソース確保 前回の記事に書いたとおり、インフラエンジニアは兼任です。 Azure のレイヤーは自分でどうにかするとして、 k8s, DevOps レイヤーを実装できるメンバが必要でした。 このプロジェクトでは、 DevOps 領域で仕事をしている ジェホ さんとともに取り組むことにしました。 AKS(k8s) 移行のようなプロジェクトでは DevOps 環境の整備はマストです。 自社の SaaS ビジネスとはいえ受託ビジネスのくらまねとやることは大差ありません。 参考: サーバーレス/コンテナ導入支援 | くらまね...自社サービスで Azure App Service から Azure Kubernetes Service に移行した話 vol.1
こんにちは。 Azure Cloud Solution Architect の秋山です。 今回は弊社の Mamoru Biz で k8s に移行した話について書きます。 思ったよりも長くなりそうなので以下のように記事を分けます。 Vol.1 App Service から AKS へ移行の決断 <- 本記事 Vol.2 AKS(k8s) 移行の下準備 Vol.3 AKS(k8s) 移行 App Service 移行した話の前に、 Mamoru Biz チームと App Service の関係について書きます。 Microsoft の App Service は簡単に Web アプリを公開できる、スタートアップに適したサービスです。 Mamoru Biz を始めた頃はまさにスタートアップで、私が受託ビジネス くらまね の片手間に短時間でインフラ構築をする必要があり、経験のある App Service を導入しました。...どうやって英語をうまく話せない日本人が、 サッカー大国出身者が集まったグローバルチームをリードしているのか。
チーム紹介 リベロ（プロジェクトリーダー）日本人 FW（担当営業）日本人、イタリア人、ブラジル人×２ MF（UI/UX フロントエンジニア）日本人×２、ドイツ人 DF（バックエンドエンジニア、インフラ）日本人×3、ドイツ人、オランダ人、韓国 GK（カスタマーサクセス）日本人(Kumiko) 私は、サッカーを強くするためにサッカー大国のメンバーを集めたわけではなく、「世界のシゴトをたのしくする」サービスを作るために活動していたら、いつしかグローバルなチームのリーダーになっていました。 このチームでは、プッシュ通知&QR認証サービス Mamoru PUSHと、その認証技術を活かしたビジネスコンシェルジュツールMamoru Bizを展開しています。 自己紹介 軽く私、前澤俊樹の紹介をします。 私は英語が苦手です。ISAO（現Colorkrew）に入った直後に受けたTOEICは400点。 英語嫌い。留学経験はもちろんなし！ そんな状態だったのに、今ではグローバルなチームをリードしています。 今このブログを読んでいるあなたも、きっとある日突然グローバルチームを率いていかないといけない日が来るはずです。そんな日が突然きても対処できるように、少しでも役に立てれば幸いです。 このあとの流れです。長いので目次にしておきます。 目次 序章：英語は突然やってくる 1章：カオスな状態でも英語の会議を続けてみた 2章：英語ミーティングにボイコットし始める日本人プレイヤー 3章：粘り強くやってたら、徐々に光が見えてきた 4章：更に新メンバーが追加し、会議以外も英語化 5章：今後の展望 序章：英語は突然やってくる はじまりは突然やってきます。 Colorkrewの代表KEIJIさんの名言の一つ、”英語は突然やってくる。”。 2019年4月に、英語しか話せないドイツ人のLuisa、ブラジル人のDaniel・Thiagoがチームに加入しました。 それまでは「一応グローバル目指しているし、会議も英語でやってみるか。だけどうまく説明できないものは日本語でいいよ。」という感じで、ゆるく英語にトライしてました。 この時点では、英語が話せないメンバーはそのルールも無視して、全部日本語で説明している状態でした。 その状況が、新メンバーの加入によって大きく変わります。 1章：カオスな状態でも英語の会議を続けてみた 新メンバー加入後、ドイツ語やポルトガル語で話すくらいなら英語で話すしかないので、一気に会議を英語化しました。 最初はカオスです。 英語が話せるグループと、英語が分からないグループと、英語を分かったふりして司会する私に分かれました。 ぶっちゃけると、全体の30%くらいしか理解していませんでしたが、天性の気持ちを汲み取る力でなんとか会議をしていました。 当時の会議を振り返ると恐ろしくて、みんなよく我慢してついてきてくれたなーと思います。 一度決めたことはやりきりたいタイプだったので、日本語で話してしまうメンバーには、「Could you try to speak in English again？」と何度も言い、諦めませんでした。 2章：英語ミーティングにボイコットし始める日本人プレイヤー しかし、そんなことを続けている時です。日本人メンバーのボイコットがはじまります。 しかもそのボイコットは静かに行われます。ブーイングのような反抗的な態度は一切見せてきません。みんな大人です。 人間、不快なことからは逃げたいものです。 なにかとアポがあるやら、忙しいやら理由をつけて、週に1回の大事な定例に参加しない日本人が増えてきました。...