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 などで切り替える方法です。...データ基盤向けPaaS『Azure Databricks』の費用を知ろう
こんにちは、Azure担当の原です。 今日は、最近お勧めする機会の増えたデータ基盤向けPaaS『Azure Databricks』の料金体系をご案内します。 Azure Databricksは機能面、性能面とも優れたお勧めのサービスです。 料金体系を把握することで、安心してより積極的にご活用頂けるのではないでしょうか。 ※文中に掲載した価格は2022年3月～4月時点のものです。 Azure Databricksそのものについては公式ドキュメントをご覧下さい Azure Databricks とは | Microsoft Docs Azure Databricks利用料金の全体像 Azure Databricksの利用料金は、大きく分けて①Azureリソース利用料、②Databricksソフトウェア利用料、の二つで構成されます。 Azureリソース利用料について Azure Databricksを利用する際には、下図のようなリソースがAzure上に展開されます。 図の左側「データレイク」は、Azure Databricks固有のリソースではなく、利用者が保有するデータを蓄えるストレージアカウントを指します。 右側の「Databricksワークスペース」の枠内が、Azure Databricks利用時に生成されるリソースです。 「利用者のSubscription」が利用者から見える場所に生成されるリソースです。 Azure Databricksによって自動で生成・削除されますが、リソースそのものは通常の仮想マシンやディスク、ストレージなどで、Azureの価格表に沿った金額が課金されます。 「Microsoft管理Subscription」に存在するリソースは利用者から見えず、明示的な課金対象にもなりません。 出典： 仮想ネットワークを管理する - Azure Databricks | Microsoft Docs Azure Databricksソフトウェア利用料について Azureリソースの他に、Databricksソフトウェアの料金が発生します。 単位は「Databricks Units(DBU)」で、1DBUのノードを1時間動かした場合の価格は以下のようになっています。 実際の課金は秒単位で計算されます。 クラスター料金を計算してみる それでは料金を計算してみましょう。 Azure Databricksのデータ処理はクラスターで行います。 クラスターにもいくつかのタイプがありますが、ここではSQL Compute用途のクラスターを用います。 SQL Computeクラスターはサイズとワーカーノード数の組み合わせが下表のようにプリセットされています。...地方在住エンジニア Colorkrewに入社して2か月がたちました
はじめまして！ 2021年11月にチームMSPメンバーとして中途入社した望月です。 現在は福岡に住んでいるため基本的にリモートワークですが、月に1回オフィスへ出社をしています。 今日はColorkrewに入社した経緯や、チームの雰囲気などをご紹介したいと思います。 入社の経緯と決め手 前職は日系のSIerで、オンプレのネットワークエンジニアをしていました。 職務内容としては、お客様に要件をヒアリングしたり、詳細設計の作成や構築・導入作業を実施したりしていました。 業務の傍ら個人的な取り組みとしてAWSの勉強を始めたことがきっかけでクラウドインフラに魅力を感じ、業務でも扱ってみたいと考えるようになりAWS SAAの資格を取得したものの、当時いた部署ではクラウドインフラの取り扱いがなく、また、社内の異動がなかなか見込めなかったため転職を考えるようになりました。 そんな時にOpenWork（企業の口コミサイト）でクラウドインフラを扱う求人を見ていてColorkrewを見つけました。 バリフラットを採用していたり、いろんな情報を社内でオープンにしていたり、面白そうな会社だと思ったので求人にいいねを付けていたところ、MSPプロジェクトリーダーの赤川さんからスカウトメッセージをいただき、カジュアル面談を経て面接へと進んだのちに内定をいただきました。 面談・面接は、堅苦しい採用面接という雰囲気は一切なく、会話をしているようなリラックスした雰囲気でお話しすることができました。 また、面接前に運用チームの鈴木さんと面談の機会を設けていただけたことで、チーム内の雰囲気や働き方などを具体的に把握できたのが良かったです。 （質問事項をたくさん用意しすぎて、こちらが面接しているような状態になってました。笑） 「なんでも聞いていいよ」と言われていたので面談・面接でたくさん質問させていただきましたが、NGな質問は特にありませんでした。 今後応募を検討されている方には、積極的になんでも質問することをオススメしておきたいです。 私がColorkrewに入社を決めた要因は大きく以下の4点です。 情報発信/チャレンジを評価してくれる Azure/AWS/GCPを扱う機会や、IaCに取り組む機会があることで技術力向上が見込める 受託業務だけでなく、自社プロダクトにも関われる機会がある リモートワークでも安心して働けそうなチームの雰囲気である 前職にいた頃からQiitaで記事を書いたり、AWS関連の書籍出版に携わったりしていたのですが、こうした情報発信や新しいことへの取り組みを評価していただけました。 また、社内外のプロジェクトで使用している技術領域が多岐にわたることから、自分のスキルを伸ばすことができ、GoalousやMamoru Bizなどの自社プロダクトへの貢献も可能であるという点も魅力的でした。 オンボーディング 入社初日は全社の朝会にて日本語と英語の両方で自己紹介をし、 その後は社内制度について説明を受けたり、PCのセットアップをしたりしました。 また、社内SNSのGoalousを使ってオンボーディング用の目標を立てて、活動を投稿する体験も行いました。 2日目からは、会社への理解を深めるために各プロジェクトの説明を受けたり、チームメンバーと1対1でお話したりもしました。 入社1週目・1か月目・3か月目のタイミングでは人事担当者との面談があり、近況報告や困りごとの相談、オンボーディングの改善点を伝えることができます。 ちなみにColorkrewの働き方はリモートワークが中心ですが、実は最初の1週間は毎日オフィスに出社していました。 いきなりオンラインで仕事を始めるよりも、関係性がある程度できてからリモートに切り替えるほうがスムーズにいくのでは、という会社の考えから出社の提案を受けたのです。 私もその方が距離が近づくような気がしたので、1週間弱を会社付近のビジネスホテルで過ごすことにしました。（出社時の交通費・宿泊費は会社が負担してくれます） 結果として、オフィスではプロジェクト関係なく毎日様々な人と顔を合わせることができたので、行って良かったなと思っています。 特に、業務後にJoyful Studioという交流スペースで歓迎会を開いて頂けたのが嬉しかったです。 多くの方と直接お話しができたおかげで、早い段階でチームに馴染むことができました。 そのほかにも、社内にランチ制度というものがあるので、出社した際にはこちらの制度を口実に積極的にコミュニケーションを取るようにしています。 社員の交流を促進する制度があるのはとてもありがたいです。 不安だったコミュニケーションケーション不足 私は現在MSP運用チームで主に仕事をしており、お客様のクラウドインフラの運用監視や改善提案をしています。 チームには色々な人がいますが、共通している特徴としてはいい意味で**“おせっかい”**な人たちだと思っています。 持っている情報をチーム内で共有してくれたり、困っているときにサポートしてくれたり、一緒に悩んでくれたりするのでとても頼りになります。 チームでは毎朝10時から朝会を実施しており、案件状況や社内情報の共有などを行なっています。 毎日メンバーと話す機会があるので、リモートワークでも孤独を感じることは特にありません。 また、社内連絡ツールのTeamsでメンバーそれぞれが分報を投稿しているので、誰が何をやっているのか分かります。 ちょっとした困りごとを書いていると誰かしら反応してくれたり、通話で相談に乗ってくれたりするのでコミュニケーション不足を感じたことは今のところありません。 自分の知っていることを積極的に共有したり、他の人がやっていることに首を突っ込んであれこれアドバイスしたりするような“おせっかい”な人にはチームMSPはもってこいな環境だと思います。 会社全体でのコミュニケーションについても、同様に不足を感じることはありません。 毎週月曜日の全社での朝会や、英語/日本語でのsmall talkが週に2回あったり、金曜日には代表の圭志さんと話す機会があったりします。...MSP運用チームの日常～振り返り編～
こんにちは！採用担当の小柴です。 ブログを通してもっとColorkrewの普段の様子を伝えたいと思う今日この頃。 クラウドインフラの運用をしている鈴木さんに相談したところ、若手2人と一緒に振り返りを行ったときのことをまとめて会話形式で送ってくれました。 ということで今回はMSP運用チームの振り返りをご紹介します！ ＜登場人物＞ 鈴木。釣りが本業、仕事は趣味。運用チームの頼れるリーダー。 ブログ「ITの力で働く人をハッピーに！埋もれる仕事も拾って輝くSRE」 堤。昨年の新卒。夏休みを利用したインターンでは会社の制度をフル活用しランチを食べまくった。 ブログ「1か月のインターン中に毎日「勇気ランチ」してみたら…」 河野。昨年の新卒。メガネの有無でその日の気分を表すルーキー。 ブログ「新卒で入社して1年。振り返ってみたら結構いろんなことにチャレンジしていた」 会話内容 堤：ひとまずお疲れ様でした。ありがとうございました。 鈴木：よかった点といえば、web/ビジネスロジック/インフラが結構完璧に疎結合できているところはいい感じでした。 河野：結合時もそんなに困らず、webの実装としてもやりやすかったです。 堤：プロジェクトで詰まった時に有識者に聞けたのはすごくよかったと思います。 河野：webは色々できるなかで、技術選定とかバランス感覚がうまくとれてよかったと思います。 鈴木：技術選定ってどう言うところで選んだんですか？ 河野：ページが少ないことはわかったので、node.jsベースの簡易構成で考えました。 front側はデザインを考えているうちにDrag&Dropできた方がいいとか、簡易的にシングルベースアプリケーションにした方がいいなと思い vue.jsのフレームワーク使った感じですね。 自分の知見の範囲内であるがうまく考えられたと思います。 お客さんから技術側の選定はお任せだったから、色々考えられてよかったです。 堤：いやぁー文句ないっすねー。 自分が考えるプロブレムについては、当初の思い描いていた設計と大きくずれた点があった点でしたね。 鈴木：自分がボトルネックになってしまったところがあったので、多いに反省します。構成などを考える部分たりてなかったと認識しております。 河野：顧客対応部分やっていたから許そう。 堤：そんなに悪くなかったと思うよ。 鈴木：配慮いただき、ありがとうございます。 堤：パイプライン側でも実装を十分に考えられてなかった部分があったかも。 ドキュメントつくるか、プロトタイプ作るかをやはり早めにやっておかないと後半で困る部分が見えてきたかも……。 河野：小さなプロジェクトだったので上手くいきましたが、細かい要件の違いが後からわかって修正するパターンが幾つかあったので、危なかったかもしれないですね。 鈴木：僕らの方から不明点や怪しい点を要件定義書かチケットで、こっちからこうしたいといった意見をどんどんお客さんに合意をもらっていくのがいいかもしれないですね。 堤：で、結局儲かったのかな？ 鈴木：運用+開発トータルで見てみると30%ぐらいの利益みたい！いい感じです！ 堤：良い週末を迎えられそうで良かったです。今後ともどうぞよろしくお願いします。 河野： え、これで終わりですか？鈴木さんこの話オチがなくないですか？ 鈴木： 世の中、なんでもオチがあると思ったら大間違いだ！わかったか！若造ども！ ～完～ 真面目な振り返り Keep (堤)過去の知識が役立った&鈴木さんのサポート&遼二君のいい感じのフロントの実装のおかげで無事に終了した (堤)実装に詰まったときに、有識者に急いで相談してどうにか前に進めようとした (鈴木) frontとpipelineを疎結合にできたのはかなりいい設計だったと思った (河野) Web側の構成はかなり小さめだったが工数・予算感との兼ね合いはいい感じ (河野) 新規案件での技術スタックの選定を実装者も含めて考える (河野) 三人の分担がよかった Problem (堤)実装の前の設計をあまりやっていなかったせいで、最初思い描いていた実装と大幅に変更することになり焦った (鈴木)自分の稼働を考えていなくて工程通りに行かなかった ->二人が僕の稼働分も巻き取ってくれた。特にインフラスペシャリスト河野くん Try (堤)実装の量が少なくても設計という作業自体は行う(きっちりとしたドキュメントに残さなくてもいい) -> ある程度の設計を行っていれば、確認しないといけないことを事前に把握できたのではないか ->もっとプロトタイピングの速度を早める施策はあるかも (河野) 要件定義をしっかり全て行った後に実装を始める このようにクラウドインフラのチームでは仲良く楽しく振り返りをしながら日々改善を行っております。 チームメンバーは随時募集中ですので、興味をお持ちいただけた方は下記のバナーからお気軽にご連絡ください！...Microsoft Japan Digital Days 開催中！
こんにちは。 Azure Cloud Solution Architect の原です。 ただいま絶賛開催中のオンラインイベント『Microsoft Japan Digital Days』にて、2つのセッションで登壇させて頂きました。 Microsoft Japan Digital Days https://www.microsoft.com/ja-jp/events/top/digital-days ブレイクアウトセッション： ”世界のシゴトをたのしくする” をビジョンにクラウド事業を手掛ける Colorkrew が D365 Business Central の導入で実現したこと 2021年10月13日(水) 14:35 - 15:00のBusiness Applicationsトラックにて、弊社のDynamics 365 Business Central導入事例について、株式会社パシフィックビジネスコンサルティングの吉島さん＆スペシャルゲストでお話しさせていただきました。 もともと販売管理システムの老朽化をきっかけに始まった弊社内のリニューアルプロジェクトがD365BCと出会ってどうなったか、そして「ノンカスタマイズ」での導入をどうやって実現したか、Power Platformとどのように連携したのか、と言ったことをご紹介いたしました。 プロジェクト中には何度か「これはちょっと厳しいかな？」という局面もありましたが、関係者で知恵と技術を持ち寄ってクリアできた経験は、いま振り返ると「チームColorkrew」にとっても大きな財産になったと感じています。 弊社も100名ちょっとの所帯で、当初は「ERP導入なんて理念先行過ぎて過剰投資になっていないだろうか？」と悩む時期もありましたが、進めて良かったと思えるプロジェクトになりました。導入プロジェクトを支えていただき、また事例発表という形で振り返りの機会を頂いた株式会社パシフィックビジネスコンサルティング様、ありがとうございました。改めてお礼申し上げます。 国内/海外へのERP導入をサポート | 株式会社パシフィックビジネスコンサルティング https://www.pbc.co.jp/ 特別編集版を後日イベントサイトにて配信しますので、詳しいことが分かりましたら改めてご案内いたします。 パートナーセッション： DX実現の礎～クラウドで実現するデータ基盤構築事例のご紹介 一方、パートナーセッション会場の『Industry Innovation ～インダストリー DX～』にて、弊社くらまね『データ分析基盤構築支援』の事例をご紹介しております。 データ分析基盤構築支援 | くらまね https://kuramane....CI/CD の推進について ～ Azure Data Factory ～
こんにちは。 Azure Cloud Solution Architect の秋山です。 今回は推進している CI/CD の取り組みについて、 Azure Data Factory(以下、ADF) を取り上げて紹介します。 ADF そのものの紹介については今回は触れません。少し古いですが以前ハンズオンしたときの記事がありますので、参考にしてください。 Azure Data Factory 入門ハンズオンの資料を公開します なぜ CI/CD を推進しているのか みなさんは時間を持て余してますか？ 私はいつももっと欲しいと思うことが多いです。 もし時間が袋詰めで売ってたら買いたいくらいです。 そんな有限で平等なリソースである時間を有効活用するためにも、 CI/CD の推進は重要です。 開発/検証/本番環境の3環境があるプロジェクトにおいて、開発環境より後述の環境に対しては、開発環境と同じ成果物を自動的にデプロイしたい、というニーズがあります。 その背景は、開発環境で修正したバグが検証/本番環境で発生してしまうといったつまらない問題を回避したい、というものです。 もしも人が3環境を手動でデプロイしていると、こういったつまらない問題がかなりの頻度で発生してしまいます。 人はミスをする生き物なので、避けがたい問題に時間を費やすのではなく、価値を生み出すことに時間を割きたいものです。 Azure Data Factory の CI/CD 構築例 構成イメージとしては以下のとおりです。 開発者は開発環境の ADF の開発ポータルを操作して開発します 開発者は開発の区切りで publish を行います publish を行うと、 ARM Template が Azure Repos に Commit されます Commit によって Azure Pipelines がトリガーされると、ARM Template を使って検証/本番環境の ADF にリソースをデプロイします 開発者は環境差異を ARM Template Parameter で管理して適宜更新します 参考: https://docs....ITの力で働く人をハッピーに！埋もれる仕事も拾って輝くSRE
こんにちは！ クラウドマネジメントサービスを提供しているチームMSPで、運用全般を担当している鈴木です。 2020年6月からColorkrewで働いており、寄稿時にちょうどColorkrewでの一周年を迎えました。 奇しくもColorkrewへ社名変更したのと同時タイミングの入社です。 今日はお仕事紹介と、普段どんなことを考えて仕事をしているかを、Colorkrewの特徴と合わせてご紹介したいと思います。 これまでの経緯 これまでのキャリアをざっくり説明すると、SIer子会社で10年ぐらい勤務して、インフラ、アプリのBtoBの基礎を育て、外資コンサルに転職して2年ほど大規模な案件の運用を行い、今のColorkrewに至ります。 Colorkrewへの転職を決断するとき、別の大手外資コンサルから内定をいただいていたのですが、せっかくなら違うことやろうと思って、チャレンジングなColorkrewを選びました。 一年で馴染んで評価も上がって、今のところ（？）その判断は大成功だったと言えそうです。 僕にとって、会社のマインドとか社訓って結構大事で、自分が大切にしているものとそれがマッチしているか会社を選ぶ時に重要視しました。 僕は**「ITの力で働く人をハッピーにする」**という使命をもって働いているのですが、Colorkrewのビジョンと共感するところが大いにありました。 余談ですが、大きな決断をして失敗したことがないんですよね。 「きっとうまくいく」という映画が好きで、しっかりと勉強すること、死ぬ以外のすごく悩む選択はどっち選んでも大した差はないこと、過去の後悔ではなく得た経験とこれからの未来をみていくみたいなのを徹底すると、選択に失敗はなくなることを学びました。 Colorkrewへの入社 チームMSPにおいて、お客様のクラウド環境を広く運用していくロールに参画しました。 お客さんのクラウド環境の運用や改善を一緒に考えたり、より良いシステム運用を作るお手伝いをしたり、チームメンバーと一緒に成長したり、採用面接したり、営業したり事業メニューを考えたりしています。 改善が大好きだったので、採用ではその点が評価していただけたみたいです。 リモート化が進んでいた最中で、面接はフルリモートで入社日に初めて会社に行きました。 会社に行ってみると、オフィスにビリヤード台やキッチンがあり、想像上のおしゃれなベンチャー企業のそれでとてもびっくりしました。 Colorkrewの他の会社との違い 仕事をOpenにする仕組みがあり、Goulousを利用していることはとても大きいと感じます。 入社後その仕組みが好きで頻繁に投稿していたのですが、運用は目立たない裏方の業務が多いのですが、そういったものも日の目を浴びて会社の他のメンバーにもそれが伝わり、コミュニケーションのきっかけや僕自身を知ってもらうきっかけになりました。 また、チャレンジに対して非常に手厚いサポートがある会社だと思います。 自らこれをやりたい！これを変えたい！という強い意志があってそれをOpenにすることで賛同者や協力者がわらわらと湧いてくるそんな会社です。 Colorkrewと他社の違いをロボット製造に例えると この会社は、管理職がいないです。 その仕組みがフルリモートと非常にマッチしていると思います。 誰かに管理してもらうのではなく、自律的に自分がすべき行動をしていくことでトータルの成果を出していくエコシステムが根底にあります。 勘違いされがちなのは、各人が勝手に仕事している、と思われますがこれは全く違います。 仕事はそれぞれ繋がっており、各々役割があります。 その役割を各人が認識して、成果をリアルタイムでOpenにすることで仕事が完成します。 [caption id="" align=“alignnone” width=“800”] 社内SNSGoalousを使って活動をシェア[/caption] ロボットを作る仕事に例えると（会社でロボットは作りませんがｗ）一般的な会社は管理職が設計図を眺めて、「◯◯さんは手足を作って、◯◯さんは胴体、◯◯さんはAIね。」という指示を出します。 Colorkrewは、手足を作るのが得意な器用な人、胴体の専門家、AIのスペシャリストなんかがそれぞれいて、みんながロボット作りたいという共通の思いを持っていて**「自分はこれをすべき」を自分で理解して、それを「俺これやります」って言う環境**なのかなと考えています。 運用の仕事なら、IaaS運用が得意な人、k8sに詳しい人、監視設定が得意な人、整理や折衝が得意な人がいて、お客様のシステムを安定稼働させるという一つの思いを持っていてそれに向かってやっていくというのができているのが、うちの運用の強みと思っています。 だからフルリモートでも、メンバーの監視とか管理ってのが存在しないんですよね。 目立たない仕事で目立てるColorkrew 自分はIT業界の経験が長いのでいろんなことができます。 ただすごく得意とか誰にも負けないみたいなのはあんまりないんですよね。 人の話を聞く、友達を作る、釣りは結構得意です。 スペシャリストが集まって自発的に「俺これやります！」っていう仕事のやり方は高い成果があがるのですが、どうしても誰もやらなかった部分をケアする仕事が残ります。 そこが自分の広く浅いカバレッジが効く能力とうまくマッチできていると考えています。 やりたいこと、やりたくないこと、いろんな経験してきましたが、全部繋がって、今、会社や僕に多くのメリットをもたらしていると考えると面白いですね。 普通の会社だとそういう仕事は埋もれて目立たないのですが、Colorkrewだと自分から「こんなことしたぜ！」ってアピールできるのでいいですね。笑 今後も、目立つ仕事ではないけど、それぞれ個性のあるメンバーが自分の能力を存分に発揮できる場を提供できるようにしていきたいです。...自社サービスで 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 を導入しました。...日本での仕事は楽しいですか？- 外国人が感じたColorkrewの魅力-
こんにちは。私はMSPチームでエンジニアとして働いているユンジェホです。 寒い冬が過ぎて、華やかな桜が咲くような暖かさを感じることができ、春が訪れてきたことが実感できるようです。 卒業シーズンが過ぎて4月になると大学、会社などの多くの場所で心配半分、期待半分の心で新しい生活が始まります。 私も2年前、日本という新しいと生活にときめいて眠れなかった記憶があります。 韓国で大学を卒業しより広い場所で自分の可能性を試したいと思い、日本での就職活動を始めました。 多くの企業に応募し、面接を受けるなか、Colorkew(カラクル)という会社に魅力を感じてここに入社しました。 今日は僕がColorkrew入社した２年間を含めてのColokrewの魅力を語りたいと思います。 1. 自由 Colokrerの魅力その1は、自由とオープンです。 私は堅苦しいことが苦手です。 スーツより半袖が好きで、きっちり編まれたスケジュールより即興で自由に動く日程が好みです。 私が日本に来た時の一番の心配は日本企業の固い社風でした。 私の中での日本は上下関係が厳しく、決められたスケジュールどおりに忙しく動かないといけない印象でした。 日本に行って、「あのような環境に上手く溶け込むことができるか」、「あそこで幸福になれるのか」などの心配が多く、可能なら自由な雰囲気をもっている会社で働きたいと思いました。 その意味でColorkrewは、面接からその気配を感じました。 ミッション・ビジョン・スピリッツといったカルチャーや制度の話はもちろん、面接官が友人のように横に座って話すのを見て、明らかにほかの企業との違いを感じ、Colorkrewは色々な角度でものを見ようとする会社だという印象を受けました。 いまでもドレッドヘアの面接官の姿は忘れません。 面接だけでなく、仕事でも、自分の意見を尊重して新入社員研修のカリキュラムを調整してもらえたり、必要に応じて自由に工数の使い方を決められる柔軟な働き方ができる会社でした。 もちろん、自由に任せるということは同時に責任と義務が生じますし、指示に従って動きたい人には少し合わないかもしれません。 しかし自分にとって、Colorkrewのこの自由なあり方は「この会社で仕事をしてみたい」と思わせる魅力がありました。 2. チャンス Colorkrewの魅力その2は、チャンスです。 仕事で、自分がやりたいことをやるのは一般的には難しいことだと思います。 やりたいことがあっても周りの環境や自分の状況によってチャレンジできないことが社会人には多いと思います。 私はプログラマとしてこの業界に入りましたが、実はColorkrewに入るまえからクラウドとインフラをやりたいと思っていました。 研修期間中に、クラウドをしたいという自分の意見を会社のSNSに投稿したところ、クラウドの仕事をしているエンジニアの方からクラウドとDevopsの仕事に誘っていただきました。 現在、私はMSPというチームの中でCloud solution architetureとDevopsエンジニアを目指して働いています。 「クラウドで働きたい」、「Devopをしたい」という思いを表現した結果、思わぬところから機会を得て、今では仕事をしながら学ぶことができているのです。 このように、Colorkrewでは自分がやりたいと強く思えば、そこにチャレンジできるチャンスが多いです。 技術的なチャレンジだけではなく、事業や職種の変更なども含めて自分がやりと思うことに対して会社もチャレンジをサポートしてくれます。 運用監視からアイデアを膨らませてセキュリティー事業にチャレンジする人もいれば、情シスからエンジニアに改めてチャレンジする人もいます。 他にも、Alexa事業やPowerBI事業は昔からColorkrewにあったわけではなく、それをやりたいと動いた人のチャレンジが事業にまで繋がった例です。 もちろん、目の前にある仕事ややらなければならない仕事もあり、自分のやりたいことだけをやれる環境とは言えませんが、やりたいことにも挑める環境が私にとっては魅力です。 3. グローバルを目指す仲間 Colorkrewの魅力その3は、グローバルを目指す仲間です。 外国人として、働くうえで一番心配になるのはやはり文化の違いと言語です。 母国語と異なる言語でコミュニケーションしようとすると気を付けないといけないところがたくさんあります。 「私が使っている表現が正しいのか」、「いま私の意見がちゃんと伝われているのか」などを考えないといけないので、簡単な質問をしたり資料を作成する時にも、他の人より時間がかかります。 事実、これらの言語障壁は多くの外国人が不安に感じる部分だと思います。 その点、Colorkrewはグローバル企業を目指しているので、Colokrewの価値観に共感できる人であれば日本語のスキルが足りなかったとしても積極的に外国人を採用してます。 このような会社の方針は外国人に大きいメリットだと思います。 英語を共通言語としてコミュニケーションできるように、Colokrewの多くのメンバーが英語を使おうとして頑張ってます。 今のところ、まだ英語が流ちょうに話せるメンバーはまだ多いとは言えませんが、外国人メンバーのために英語で打ち合わせをしたり、会社のドキュメントを英語で作成してます。 だから、言語によるストレスは思ったより大きくありませんでした。 会社は将来的に社員全員が英語で話せる状態を目指しており、そのためのサポートを惜しまないので、将来的には言語障壁が更に減りもっと仕事に集中できるようになると思います。...仕組み化したらまた次へ！粛々と改善を続ける運用監視のプロ
こんにちは！人事＆ブランディングプロジェクトの小柴です！ ISAOのエンジニアにインタビューしてみよう、第5弾！ 今回もサーバーの設計・運用・監視のサービスをお客様に提供しているMSPチームからの紹介です。 インタビューした布施さんは、監視チームからスタートし、現在は運用チームで活躍されているインフラエンジニアです。 パチスロで身についた相手の意図をくむ意識 小柴：ダーツ姿イケてますね～。ダーツお好きなんですか？ 布施：いえ、そういうわけではなく動きを出してみたいとカメラマンから要望がありまして。 小柴：そういうことでしたか。笑 布施：僕が好きなのはパチスロです。 小柴：パチスロ？！ 布施：はい、もともとは趣味で始めたんですけどそのうち本気でやりたくなって専門学校にまで通いました。 小柴：なぜそこまで！？ 布施：うーん、伝えるのも難しいですし共感してもらうのも難しいかも。笑 小柴：いやいや、気になるので教えてください！笑 布施：パチスロって負ける台ばかりだとお客さんは来なくなってしまうので、魅せ台を作ったりするんですね。 そういう店側の意図をくんで良い台に座るには、というシミュレーションをしていくうちに、自分がホールを運営して利益をだしてみたくなったんです。 小柴：そんな裏側があったんですね！知らなかったです。 布施：実際働いていた時期もありますが、インカムに耳がやられてしまって、長く続けることは諦めました。 良いものはみんなで共有してチームを強くしたい 小柴：ISAOでのキャリアは監視チームからスタートして、現在は運用チームのお仕事をされているんですよね。 布施：はい。監視チームの業務で学べることもありますが、そこだけに長く居続けてもステップアップが難しいので、運用にも手を出し始めました。 小柴：運用の仕事をやり始めたのは昨年の10月頃でしたっけ？ 布施：それくらいですね。なので今はエスカレの一次受けは全部自分がやる、というチャレンジをしています。 小柴：全部？！ 布施：どういうときにどういう対応をするかまだ完全に理解していないので、実際の業務を通して経験したいなと。絶賛有言実行中です。 小柴：ストイックですねー！ 布施：それと同時に、やり辛いところがあったら改善していってます。そうすると監視チームでもできることが増えるはずなんです。結果、業務効率がUP、自分のスキルもUP。 小柴：監視チームを知ってるからこその視点ですね。 布施：そういう意味では粕谷さんは設計～運用～監視を考えてうまく組み立てられる人だと思います。だから設計チームにそのいいやり方をどんどん共有していってもらいたいです。 小柴：粕谷さんも監視チーム経験者ですもんね。 布施：ISAOはスペシャリストな人が多く全部自分でやってしまったり、人によってやり方が違う場合もあるのですが、それだと冗長化の問題がありますよね。 監視チームはそこの仕組み化が得意なので、自分もMSP全体に展開していきたいと思っています。 小柴：なるほど。 布施：スペシャリストとして入った人たちとどううまく融合してチームを強くできるか、ということを考えるとワクワクします。 だから、チームで働くという意識があって高い専門性を持った人がISAOに入ってくれると嬉しいです。 小柴：お話を聞いているとチームを意識されてるなあという印象を受けたんですが、現在チームで取り組んでいることって何かありますか？ 布施：いま運用チームでは、KPTというフレームワークを使って、週次で振り返りを行っています。 Keepは良かったことや今後も続けること、 Problemは悪かったことや今後はやめること、Tryは次に挑戦すること、を指していて、みんなで話し合いながら改善しています。 小柴：あ、それGoalous(社内SNS)の投稿で見ました！ [caption id="" align=“alignnone” width=“483”] 実際の投稿。勢いがありすぎたのか布施さん以外ブレブレ。[/caption] 布施：KPTを行うまでは、何か問題としてあがっても一部置き去りにしがちだったんですが、それをちゃんと問題として表面化して解決していこうという文化ができました。 この振り返りを通じて、今までよりチーム一体となって業務が出来るようになってきたと感じています。 小柴：いいいですね！ 目の前にあることを普通のテンションでやるのみ 小柴：そのほかに仕事で大事にしていることってありますか？...クラウドネイティブを推進、オープンマインドの体現者
こんにちは！人事＆ブランディングプロジェクトの小柴です。 ISAOのエンジニアにインタビューしてみよう、第4弾！ 前回インタビューに引き続き、今回もMSPチームからご紹介。プログラマ出身のクラウドソリューションアーキテクト、秋山さんにお話を伺いました。 秋山さんは Microsoft Azure のクラウドネイティブな技術を扱う案件を中心に、クラウドの設計や構築を行っています。 Amazon Dash Button で作成したシステムの光と闇 小柴：秋山さんといえば私の中で**Amazon Dash Button の人**というイメージです！ 秋山：あーそういえば作りましたね。 [caption id="" align=“alignnone” width=“800”] 備品を補充する Dash Button。このボタンを押すだけで自動で注文できるのだ。便利！[/caption] 小柴：どうして作ろうと思ったんですか？ 秋山：すごくHow思考なんですけど、当時 Dash Button が発売されたニュースを見て、これを使って何か社内の問題解決をしてみたいと思ったんです。 小柴：おお～実際に作りたくなっちゃったんですね。 秋山：最初に作ったのは、「今キッチンで飲んでるよ」という通知が社内の人たちに届くというものでした。でもあんまり受けが良くなかったんですよね～。 [caption id="" align=“alignnone” width=“800”] キッチンにあるボタン。こちらもまだ現役です。押したら社内のみんながやってくるかも。[/caption] 秋山：備品補充なら本来の用途に近くて使ってもらえそうとだと思ってもう一つ作ってみたら、こちらは活用されていて。満足しました。笑 小柴：普段からそういう情報には敏感なんですか？ 秋山：うーん、どういう技術用語を最近よく聞くか、情勢は掴むようにしています。ものによっては自分で手を動かして試してみたりしますね。 小柴：エンジニアさんっぽい！ 秋山：今は仕事で使わない技術でも、1年後とか後になってからそれを使う機会に出会って繋がっていくんですよ。これはITで働いていておもしろい点です。 小柴：最近興味があるのはどんなことですか？ 秋山：Azureのクラウドネイティブに大別される技術全般が好きで、常に情報を集めたりしてますね。GitHub Actions というCI/CDのツールを試したり、パーツをマーケットプレイスに公開してます。 小柴：ほんとに好きなんですね。 秋山：性格的にも合ってるんだと思います。前職ではアプリ開発をしていましたが、それよりも、DevOps の環境を整備して チームメンバーがうまく働ける状況を作ってみんなの効率をあげるとか、そういう方が好きなんです。 受託の魅力は様々な経験を積めること 小柴：前職の話がちらっとでましたが、転職される前は静岡に住んでらっしゃったとか？...