読者です 読者をやめる 読者になる 読者になる

日記

日々のことと、Python/Django/PHP/Laravel/nodejs などソフトウェア開発のことを書き綴ります

フリーランスになって、2年が過ぎた

Misc

確定申告が終わり、フリーランス 2年目の雑務も完全終了したので、振り返りエントリです。

過去の退職エントリと去年の振り返りはこちら。

お金の話

まずはお金の話から。

収入とか

今年の営業収益は休業時期のあった前年を危なげなく上回りました。

これも理由があって、年初に時雨堂のサービス開発を薄く長く手伝う契約をしており、営業収益が底上げされていたためでした。また、ありがたいことに定期的に異なる会社から仕事を依頼されたので、その面でも2年目は安定して収益を上げられて良かったと思います。ライフラインが複数あるのは凄く大事!今後もお付き合いできますように!!

税金とか

1年目から2年目になり、予定納税の支払いタイミングが増えています。

自治体に寄って支払時期に多少の変動が出てきます。分納できるものも一括で払っていますが、それでも 2月に 1回は何かを支払っていることになります。

あまり貯金しないでフリーランスになった人は、余裕をもって 1年目の収入を貯蓄しておいたほうが良いと思いました。特に 3月、4月のキャッシュフローは気をつけたほうが良さそう。消費税の徴収対象の場合は更に出て行くお金が増えます。

節税のこと

ふるさと納税に申し込んだくらいしかやっていません。更に言えば、ふるさと納税は「節税」にはなっていない…。

なお、4月現在で個人型確定拠出年金は資料を取り寄せたものの申し込むまでには至ってません。

小規模企業共済なども近いうちに入っておきたいと思っています。

2年目の仕事

大ざっぱに書くと、2年目は次のような仕事をやりました。

  • Ansible Playbook の作成
  • 時雨堂サービスのサーバの管理 Anzu Sora
  • リアルタイムバックエンドの設計(主にチャットルーム)
  • 音声チャットの調査と設計(twilio をマイグレーション
  • スマホゲームの公式サイトをクラウドネイティブにマイグレーション
  • Electron アプリの開発 (Electron + React + Alt)
  • Kubernetes (GKE) のインフラ管理のお手伝い

公開できない案件もあるので、差し支えないと思える範囲で書いていきます。

Ansible Playbook のお仕事

時雨堂 の仕事で 2016 年は元々違う作業の想定で契約はしてたのですが、急な追加でのお手伝いでした。

Ansible Playbook の作成は具体的には、デプロイするディレクトリの構成変更と Ansible Playbook の全面書き直しをしました。Ansible は以前から使っていましたが、レビュワーとして ツキノワ@r_rudi が入っていたので、レビューしてもらいながら書き換えを進め、Ansible 力がかなり上がりました。

Ansible Playbook の書き換えは具体的に次のようなことをしました。

  • task を整理して role に分割する(ロールが作られて無かった)
  • task の name を定義する
  • 共通になるべき部分を変数に切り出す。使用するライブラリのバージョン番号なども同じく変数にする。
  • 冪等性を担保するために command を使っていた task をモジュールに置き換える。task 自体を調整する。
  • Anzu のリニューアルに備えた task の変更

既にある playbook の書き直しは task の name も定義が無かったため状態を把握するのも大変で、安請負した感は満載でした。その後も定期的に仕事をもらえているので良しとしよう…。

ちなみに Ansibleはオライリーの「初めての Ansible」なども読んでますが、読むのに時間が掛かるし、この本を読み進めてもベストプラクティスにたどり着くまでが長いです。ゼロからの導入出れば、宣伝抜きにして ツキノワの Ansible セミナー を受けてしまうと導入までが早いと思います。その後にオライリーの本を読んでも良いと思いました。

スマホゲームの公式サイトのインフラ切り替え

ランキング上位の某スマホゲームで公式サイトにアクセスが集中したときにサーバの負荷が酷いから助けてくれとの相談でした。

静的コンテンツなのにサーバ負荷?という状況だったので、現状調査から入り次のことが分かりました。

  • メディアファイル(画像、CSSJavascript)は CloudFront を設定されたドメイン名でアクセスしている
  • それでもアクセスが増えるとサーバが死ぬ (サーバは確か ELB の後ろに EC2の m3.xlargeを 2台)
  • EC2 に置かれたコンテンツのキャッシュは行っていない(varnish などは使っていない)
  • 他のサーバのファイルを取得するために EC2 インスタンスからリバースプロキシで取得
  • .html ファイルに PHPのコードが書かれており、サーバ上の .htmlファイルは全ファイル PHPとして処理されている(←!!!!)

そんなわけで要望を加味し、次のような方針を立てました。

  • 基本方針
    • なるべく早く、本番運用に移せる対策で行う
    • インフラ担当者が少ないので、管理するサーバは少ない方が良い。
    • ファイル管理を Git に移動する
    • 本番環境とは別の環境を用意する

対応の中身としては次のようなことをしました。運営側にも理解いただいて、サーバ側の PHP の処理やコンテンツ内の JavaScript の調整まで行っています。

  • コンテンツ管理と CDのフロー作り
    • コンテンツは GitHub管理
    • コンテンツは CircleCIから S3にデプロイ
  • コンテンツの変更
    • php コマンドを呼び出して、HTMLファイルを生成できるように処理内容を変更
    • ホスト名を含むアクセスは削除する(複数環境を用意する準備)
    • 他のサーバからリバースプロキシしていたコンテンツは CloudFrontで解決
  • その他、運営の責任者との調整
    • サイトマップを作り、使い終わったコンテンツの削除
    • インフラの切り替え時に困らないよう、キャンペーンサイトなどは他のドメインでファイルを置いてもらう

結果として EC2インスタンス 2台と ELB、さらにインスタンス監視のコストが削減され、インスタンスが重くなることも無いので運営側の精神衛生上の負担も軽減されたと思っています。今のところ運営上も順調そうに見えます。

なお、同じ会社から年末に WordPress で管理している別サイトを同じような方式にしたいと相談を受けて、つい最近サイトの切り替えが終わりました。追加の発注、ありがとうございました!!

似たような話で困っている起業からの相談もお待ちしております!

Kubernetes (GKE) のインフラ管理のお手伝い

アカツキのお仕事で @seizans からオファーがあって、年末から参加しました。年内はキャッチアップのための契約で、翌年からが本格的に参加ということになりました。(と言っても、100%アサインではない)

アカツキというとゲーム開発が有名ですが、上場後にライブエクスペリエンス事業部(LX事業部)というものが立ち上がり、レジャー予約サイトの そとあそび や、今回参加させてもらった Wowful というサービスの運営もしています。

Wowful は 2016年末にベータサービスとしてローンチされたばかり。これから育てたいサービスということで、次のようなものを使い技術的にもチャレンジしていました。

  • プラットフォームは GCPを使い、サービスを GKE上で動作させている
  • アプリケーションは、React + Redux + SSRでページを作り、Backend for Frontendを使って API サーバにアクセスするような仕組み
  • マイクロサービスアーキテクチャで、機能拡張はサービスをポコポコ追加する形で拡張していきたい。

Wowful のアプリケーション面のアーキテクチャは Wowful 開発のリードである @shinpeiws が、昨年のアドベントカレンダーで詳細を書いてます。

また開発体制は、開発チームとSREチームと分かれており、開発はスクラムで取り組んでいました。

さてインフラ管理の手伝いの最初の依頼としては次のような感じでした。

  • seizans がゲーム開発に異動となるので人手が足りない
  • インフラできる人いない、つらい
  • アサインは SRE チームで @apstndb と一緒に動く
  • GCP を勉強しつつ手伝ってほしい
  • インフラの一般的なところでもサポートを期待してる

実際にやったことは次のようなこと。

  • Wowful アーキテクチャのキャッチアップ
  • Terraform 導入の取っかかりを作る
  • kube-lego 証明書更新の問題調査
  • asia-east1 に残ったサービスの asia-northeast1 への引越
  • Kubernetes Eviction の挙動を調査して、ノードのバージョンアップ
  • インフラの一般的なところでの問題解決(ベータとはいえ、サービスインしてるし…と思ったけど設定漏れとかあるもんですね)

GCP はアグレッシブに仕様変更が入るため、追従どころか変更を把握するだけでも実は大変です。Wowful では @apstndb が非常に優秀で GCP の変更を追いかけつつ、開発サイドが困らないように・CD のフローが止まらず円滑に進むように先回りして対応しているのが印象的でした。

個人的には GCPの認証方式や GKEにも慣れてきたところでしたが、人事異動絡みでインフラを開発チーム側で引き継ぐ話が本格化し、3月いっぱいでお役御免となりました。Wowful を運営する LX 事業部では、まだまだ開発体制を強化のため採用を続けているようです。GKE のインフラの問題というのは減ってきていますが、CI と CD の改善をしながら、GKE と Kubernetes のことを知りたい人や、React + Redux さらにマイクロサービスアーキテクチャを使った Web アプリを作りたい人は話を聞きに行ってみると良いと思います。

そして噂には聞いてましたが、4月から @mizchi がフロントエンドの改善に入っているようです。

まとめ

お仕事の受注的には順調なものの、2年目はインフラ寄りの仕事と既存システムのマイグレーションの案件が多い印象でした。 アプリケーションとインフラの中間部分をやる人が居なくて、あちこちで苦しんでいる感じです。実際のところ本当に人が居ないんだろうなぁ…。

3年目に入って、ちらほら開発系のお仕事もあるにはあるんですが、もうちょっとバランス良く仕事が受けられたら良さそうだなぁと考えています。が… 3年目は見込み案件の発注があれば埋まってしまう感じなので、自己学習で開発系のことは進めるしかなさそう。出来る範囲でがんばりたいと思います。

GKE はどこかでブログにまとめたいと思いつつ、まとまった時間の確保が難しいまま出来ず。この4月、5月は多少空きができるので、忘れないうちにアウトプットしておきたいところです。がんばろう…。記事は忘れたころにアップするかもしれません。