さくらインターネットに再入社した
2015年度の新卒社員としてさくらインターネットに就職、2018年からミクシィ(現 MIXI)で勤務していましたが、2024年7月にさくらインターネットに再入社しました。最近はアルムナイ採用というらしいです。
MIXIでは新規事業(残念ながら未リリースでクローズ)の開発を半年ほど担当した後に、家族アルバムみてねのSREを6年ほど担当し、気づけば6.5年ほど在籍していました。
MIXIはとても居心地が良く職種やポジションに関わらず尊敬できる人が多い会社だったので、大きな不満点はありませんでした。一方で、自分の価値観の変化などもあり「携わる事業を通してどんな価値を生み出したいのか? 自分が本当に力を注ぎたい領域はどこなのか?」を考え、その結果の退職という選択になりました。
さくらインターネットでは2024年下期は主にOSSとして公開されるソフトウェアの開発を担当して、OPAを活用したTerraformの静的チェックツール、さくらのクラウドのTerraform Provider、AppRunという新サービスのGo APIライブラリの開発をしました。
今後は上記のOSS開発とメンテナンスを引き続きやりつつ、ソフトウェア開発メンバーとして次世代ネットワークインフラの開発に携わる予定です。とはいえ、僕はネットワークインフラの開発に関しては経験が浅く不安は大きいですが、面談時に「ネットワークエンジニアとしての修行もやらせてほしい」とお願いしていた結果なので、チャレンジを後押ししてくれる風土に感謝しつつ頑張っていこうと思います。
さくらインターネットというとインフラの会社と思われがちですが、クラウドSDKの開発などソフトウェアエンジニアとして活躍できるポジションも数多くあります。あまり見かけないようなポジションもあり、チャレンジングな課題もあります。興味が湧いた方、ご連絡お待ちしております!
さくらのクラウド - AppRunで画像変換サービスを作ってみた!
さくらインターネットの伊東です。この記事は さくらインターネット Advent Calendar 2024 17日目の記事です。
本エントリーでは、先日リリースされたさくらのクラウドの新サービスである AppRun を一通り使ってみましたので、レポートさせていただきます。
AppRunとは
AppRunは、コンテナ化されたアプリケーションを簡単にデプロイし、自動的にスケーリングを行うサービスです。インフラ管理の複雑さを気にすることなく、開発者が本来の業務であるアプリケーション開発に集中できる環境を提供します。
2024年12月17日時点ではβ版のサービスであり、制約事項があるものの全機能を無料で利用できます。嬉しいですね。
※詳細は https://manual.sakura.ad.jp/cloud/apprun/about.html をご参照ください。
AppRunを使おう
では早速AppRunを使ってみましょう。まずはこれから作るものをざっくりご紹介します。
サンプルアプリケーションとして、オブジェクトストレージに保管された画像を変換するWebアプリケーションを用意します。 このアプリケーションをAppRunでホスティングしてみます。
また、アプリケーションのビルドとデプロイをGitHub Actionsで行い、アプリケーションの更新時に自動でAppRunへデプロイできるようにします。
1. サンプルアプリケーションを作成する
まずはAppRunにデプロイするためのサンプルアプリケーションを用意して、コンテナイメージにまとめます。
nginxで「Test1」といった文字列を表示するだけでは面白みがないため、ちょっとしたアプリケーションを作ってみました。
imagineは、当社の画像変換・配信サービス ImageFlux のごく一部の画像変換機能を自作してみたものです。jpeg, webp, png, gif への画像変換と、width/heightを指定したサイズ変換ができます。
なお、私はImageFluxの実装は見たことがなく、あくまでも雰囲気を真似しただけのサンプルアプリケーションだとご理解ください 🙏
2. 変換元画像を用意する
上記でご紹介したimagineの変換元画像を用意しておきます。今回は 1.jpg
, 2.jpg
, 3.jpg
と3枚の画像を用意しました。
これらの画像を オブジェクトストレージ のバケットに配置します。
3. コンテナレジストリを作成する
サンプルアプリケーションのコンテナイメージをデプロイする先として、コンテナレジストリ を用意します。
このときに、レジストリ自体の公開範囲は「非公開」に設定し、PushとPullの権限を持つユーザーを作っておくのが望ましいです。
4. AppRun Applicationを作成する
前準備はここまでにして、ついにAppRun Applicationを作成します。
4.1. AppRun Applicationの作成手段
Applicationを作成する方法は主に3通りあります。
4.1.1. APIを直接叩く
ひとつめはAppRunが提供する操作用のAPIを直接叩く方法です。
4.1.2. APIライブラリを使う
ふたつめはGoで実装されたAppRunのAPIライブラリを使う方法です。
僕が頑張って作ったので使ってもらえると嬉しいです!!!
4.1.3. Terrafrom SakuraCloud Providerを使う
みっつめは、Terrafromを使う方法です。
内部的に上記で紹介したAPIライブラリを利用してAPIを叩いてコントロールをしていますので、ある意味ではふたつめとの合せ技とも言えます。
こちらも僕が頑張って作ったので使ってもらえると嬉しいです!!!
4.2. TerrafromでAppRun Applicationを作成
本エントリーではTerrafrom SakuraCloud ProviderでAppRun Applicationを作ってみます。
以下のようなtfファイルを作成することでAppRun Applicationを作成できます。
なお、以下の情報を書き換える必要があることに注意してください。(詳細は ドキュメント を参照してください)
container_registry
にコンテナレジストリ自体のイメージ名とホスト名、username
,password
に、で設定したPushとPullの権限を持つユーザーの認証情報AWS_ACCESS_KEY_ID
,AWS_SECRET_ACCESS_KEY
環境変数にオブジェクトストレージのアクセスキーの情報BUCKET_NAME
はオブジェクトストレージに作成したバケット名
また、さくらのクラウドのAPIの認証情報を設定しておく必要があります。詳しくは以下の情報を参照してください。
5. アクセスする
AppRun Applicationが正しく作成されたら、公開用URLが発行されます。
公開用URLはTerraformでdata sourceを利用するか、APIを叩く方法がありますが、せっかくなのでTerraformで取得してみましょう。
以下のようなtfファイルを作成することで、AppRun Applicationの公開用URLが取得できます。
実際に動かしてみると以下のようになります。(idはマスクしてあります)
$ terraform apply data.sakuracloud_apprun_application.imagine: Reading... sakuracloud_apprun_application.imagine: Refreshing state... [id=xxxxxxxxxxxx] data.sakuracloud_apprun_application.imagine: Read complete after 1s [id=xxxxxxxxxxxx] No changes. Your infrastructure matches the configuration. Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed. Apply complete! Resources: 0 added, 0 changed, 0 destroyed. Outputs: imagine = "https://app-6d264259-85f4-4ee7-85dc-77a90a0cadf4.ingress.apprun.sakura.ne.jp"
先程の手順でオブジェクトストレージにアップロードした 1.jpg
をWebP形式・幅を1024にリサイズして取得してみます。
https://app-6d264259-85f4-4ee7-85dc-77a90a0cadf4.ingress.apprun.sakura.ne.jp/f=webp,w=1024/1.jpg
にアクセスすると、AppRun上でホスティングされたアプリケーションにアクセスできるので、ぜひ試してみてください!!
GitHub Actionsでデプロイをしよう
発展して、アプリケーションを更新した際にGitHub Actionsでデプロイをできるようにしてみます。デプロイの流れは以下のようになっています。
- mainブランチにpushされたときに実行
- コンテナイメージのビルド
- ビルドしたコンテナイメージをコンテナレジストリにPush
- コンテナイメージのタグは
latest
とcommit idの短縮表記
のふたつ
- コンテナイメージのタグは
- AppRunのApplicationに新しいコンテナイメージを反映
作成済みのyamlは先程紹介したサンプルアプリケーションのリポジトリに含まれますので参考にしてください。
なお、GitHub リポジトリの Actions secrets and variables
から Repository secrets
に以下のシークレットが登録してある前提となっていますのでご注意ください。
APPLICATION_ID
: AppRun ApplicationのID。公開用URL同様に、APIやTerraformから取得することができます。SAKURACLOUD_ACCESS_TOKEN
: さくらのクラウドのアクセストークン。SAKURACLOUD_ACCESS_TOKEN_SECRET
: さくらのクラウドのアクセストークンシークレット。SAKURACR_USER
: コンテナレジストリのユーザー名SAKURACR_PASSWORD
: コンテナレジストリのパスワード
おわりに
AppRunによるコンテナのホスティングはかなり簡単に行えたので、アプリケーションの実装に注力できてとてもいい感じでした。特に今回サンプルアプリケーションとしてご紹介したようなステートレスなアプリケーションと相性がいいですね。
また、本エントリーでは紹介できませんでしたが、AppRunにはアプリケーションのバージョンを管理する機能があり、バージョン間でトラフィックを分散する機能があります。 この仕組みを使えばカナリアリリースを行うことも可能で、AppRunが正式版としてリリースされれば、実運用にも耐えられると感じました。
AppRun自体の機能や周辺ツールなど「こんな機能があったら便利だな」というアイディアがありましたら、窓口 からフィードバックをお寄せください。
以上、最後まで読んでいただいてありがとうございました!
さくらのクラウドのオブジェクトストレージをaws-sdk-go-v2で使ってみる
どうもこんにちは。今年の7月にさくらインターネットに出戻りしました。 ということでさくらのクラウドで色々と遊ぶために、まずはさくらのクラウドの オブジェクトストレージ を aws-sdk-go-v2 から使ってみましたので、そのやり方をメモしておきます。
ここまででお分かりのとおり、さくらのクラウドのオブジェクトストレージはAWS S3互換です。このため、AWS SDKからバケットやオブジェクトの操作をすることができます。
ちなみに世の中にはこれ以外にもいくつかS3互換オブジェクトストレージが存在しますので、その他のAWS S3互換オブジェクトストレージでも概ね同じような形で扱うことができます。
先にサンプルコードを貼っておきます。 gist.github.com
ポイント
1. BaseEndpointの変更
オブジェクトストレージの サービス仕様 にも記載があるとおり、エンドポイントを変更する必要があります。
aws-sdk-go-v2 s3 packageの NewFromConfig でBaseEndpointを変更することができます。
2. リージョンの変更
環境変数 AWS_REGION
を指定することでregionを jp-north-1
に変更します。
また、コード上で変更したい場合はBaseEndpoint同様にs3 packageのNewFromConfigから変更が可能です。
client := s3.NewFromConfig(cfg, func(options *s3.Options) { options.BaseEndpoint = &baseEndpoint options.Region = "jp-north-1" })
3. アクセスキーIDとシークレットアクセスキーの設定
オブジェクトストレージ サービス基本情報 | さくらのクラウド マニュアル に従って、オブジェクトストレージにアクセスするための アクセスキーID
と シークレットアクセスキー
が作成できます。
環境変数 AWS_ACCESS_KEY_ID
にアクセスキーID、AWS_SECRET_ACCESS_KEY
にシークレットアクセスキーを設定することでAWS SDKがそれぞれの値を使ってくれます。
また、コード上で設定したい場合はcredentials packageの credentials.StaticCredentialsProvider
にアクセスキーIDとシークレットアクセスキーをセットすればOKです。
creds := credentials.NewStaticCredentialsProvider(accessKey, secretAccessKey, "")
cfg, err := config.LoadDefaultConfig(ctx, config.WithCredentialsProvider(creds))
TIPS
ちなみに、aws-sdk-go-v2自体のEndpointResolver 等を利用するエントリーもありますが、これはdeprecatedとなっていますのでご注意ください。詳細についてはパッケージのコメントを参照してください。
2023年 振り返り
今更という感じですが、2023年の活動についてまとめておきます。(1年に1エントリーペースでしか書いてない…)
仕事
一応断っておきますが、以下全て個人の感想です。所属組織の意見を代表するものではありません。
全体を通して
引き続き株式会社MIXIに勤務していまして、家族アルバム みてね のSREをやっています。勤続7年目に突入しました。時が過ぎるのはあっという間。
勤続年数が長くなってきたこともあり、サービスのコアとなるような要素技術にもある程度明るくなってきたのでその知識を使って社内勉強会を開いたり、登壇や執筆を積極的に行った1年でした。このあたりはある程度手応えがあって良かったポイントです。
逆に、部屋の中の象といわれるような問題に対しての改善の提案だったり、わりと大きめのアーキテクチャの変更などは上手くコントロールできず成果を出せなかった反省も多い1年でした。いい意味で大きなストレスなく日々の業務に当たれている一方で新卒の頃のような右も左も分からないけどがむしゃらに仕事に打ち込む熱量を失ってしまったなーと思うこともあり、2024年はもっとチャレンジしていきたいです。
登壇 & 執筆
昨年は4回登壇の機会をいただきました。前職ではわりと登壇の機会が多かった一方で、転職後でこんなに登壇したのは初めてでした。加えて2本記事の執筆もしました。
会社やサービスのブランディング、キャリアアップのためのセルフブランディング、技術コミュニティへの貢献など目的は様々だと思いますが、外部露出は目的を持って狙って動かないと割く時間の割には得られるものが少なくなってしまうと感じる事が多く、改めて目的を意識することの大切さが身に沁みました。
また、反響の有無は、内容の質・分かりやすさ、ワードチョイス、ネタの鮮度(リリースしたばかりの注目度の高いなにかを使ってみたとか)など色々と要因がありそうで、個人的には「めちゃくちゃおもしろい!」と思った内容で全く反響がなかったり、逆に意外と反響が大きかったり、自分の思い通りには全くいかず難しいなと感じることが多かったです。
- 「無料・容量無制限でアップロード」を 支える みてねのコスト削減術 - Speaker Deck
- 「家族アルバム みてね」を支える SREのこれまでとこれから - Speaker Deck
- データベースにまつわるトイル削減の新手法の提案 - Speaker Deck
- Aurora MySQL version 3でTempTable溢れの振り返り - Speaker Deck
- External Secretsから参照しているパラメータの削除忘れを防ぐ - mitene / FamilyAlbum Team
- DBのコストを半額に!〜Amazon Aurora I/O-Optimizedの活用〜 | by hekki | mitene / FamilyAlbum Team
プライベート
家
現在居住中のマンションを売って、郊外に家を建てることにしました。 2023年の春頃から本格的に動き出して、それ以降プライベートの大半は家のことを考えてました。まだまだ全行程完了していないですが、落ち着いたらまとめるぞ。
猫
2023年1月に保護猫を迎え入れました🐈⬛(その後に家の話が出てきてしまい、引っ越しは猫にとってストレスなので申し訳い気持ち。) 元野良猫なので正確な年齢は不明ですが、4歳の黒猫です。ばり可愛い。
英語
学生時代から英語が苦手でのらりくらりとやってきたものの、英語の壁を感じてチャレンジできない機会が何回かありました。
さすがに悔しかったので、今年は英語をやっていく所存です。「グローバル人材に俺はなる!!」みたいな謎の目標だといつまで経っても達成出来ずにダレるので、まずは分かりやすいTOEICのスコアアップを目指します。
「TOEICでハイスコア取っても英語は喋れるようになれない」的なことを言われがちですが、とにかくハイスコアを目指します。ハイスコアを取れるようになって、それでも全然だめだったらそのときに方針転換するつもり。
おわりに
今年はぼんやりと考えてることを言語化する練習のためにもブログを書くぞ!!!!
Macのターミナル環境再構築メモ
Macの調子が悪く、クリーンインストールをしました。
せっかくなので、ターミナル環境の構築メモを残しておきます。
基本的に、デフォルトの設定からなるべく変更しないことを良しとしているので、あまり面白くないかも。
iTerm2
他のターミナルソフトもしらべてみたものの、なんだかんだでiTerm2に落ち着きました。
設定はそれほどいじっていませんが、主な変更点はこちら。
- Color PresetsをJapanesqueに変更。
- FontはMonaco・フォントサイズ15。
- Non-ASCII FontはUbuntu Mono derivative Powerline ・フォントサイズ15。
Homebrew
みんな大好きHomebrew。
fish shell
shellはbash -> zsh -> fish shell という感じで渡り歩いて、fish shellで今の所は落ち着いています。
プラグインマネージャーはfisherを使います。
また、プラグインは下記のプラグインを使っています。
jethrokuan/z
laughedelic/brew-completions
matchai/spacefish
tmux
tmux自体はbrewでインストールしています。
プラグインマネージャーはtpmを使います。
詳細はtmux.confにて。
以上!
AWS Systems Manager Session Manager を使って、手元のマシンから楽してEC2へ接続する
概要
AWS Systems Manager Session Manager(以下Session Manager)を使用している環境でEC2 に接続する場合、色々と面倒なことがわかりました。
面倒事
Session Manager はマネジメントコンソールから利用する場合「マネジメントコンソールにログイン -> 接続先のEC2 インスタンスを探す -> Session Manager を使用して接続」という流れになります。
毎回この手順を踏むのは面倒ですし、SSH のように手元のマシンから接続できないのは不便なので、AWS CLI を使いたくなります。
ただし、AWS CLI + Session Manager の場合でも、接続先のEC2 インスタンスのインスタンスID を調べるためにマネジメントコンソールから確認する必要がありました。
これは非常に面倒なので、この手順をスキップして接続できるように工夫してみます。
本題
前提
手元のマシン
はMac を想定しています。ただし、Windows/Linux など他のOS でも適宜読み替えれば同じことができるはずです。 また、予め以下のようなツールがインストールされている必要があります。
また、aws ssm start-session
や aws ec2 describe-instances
が実行できる権限が付与されたAWS アクセスキーが手元のマシンに登録されている必要があります。
ここでは hoge-profile
という名前付きプロファイルとして、アクセスキーが登録されていることとします。
ツールの用意
下記のシェルスクリプトをパスが通っているディレクトリに作成します。ここではスクリプトのファイル名を awssh
とします。
gist.github.com
使ってみる
このようにしてAWS のプロファイルを指定しつつコマンドを実行します。
$ awssh --profile hoge-profile
コマンドを実行すると起動中のEC2 インスタンスの一覧が表示されるので、接続したいインスタンスを選択すると、そのインスタンスのコンソールにログインすることができます。
これで接続先のEC2 インスタンスのインスタンスID をマネジメントコンソールから確認しなくてもSession Manager を使ってインスタンスのコンソールにログインすることができるようになりました。やったね!
2020年 振り返り
2020年も終わりが近づいてきたので1年の振り返りをする。
今年も去年と同じく、SREというロールで仕事をしていた。 今年の自分のテーマは「ソフトウェア開発スキルの向上」で、とくにかくこれを念頭に置きながら1年過ごした。
2018年の夏に今の部署に異動して、SREというロールで 家族アルバム みてね というスマートフォンアプリのバックエンドの開発や運用をやるようになった。
それまで物理インフラ畑にずっといたからか、最初の1, 2年は特にコーディングの苦手意識がすごくて(苦手意識というか実際にできなかったんだけど…)、重めの開発タスクがあると嫌だなあーと思って避ける事が多かった。
とはいえそのまま避け続けるわけにはいかないし、せっかくなら自分で開発したものをユーザーに使ってほしいのでなんとかしようといろいろやった1年だった。
具体的には次のようなことをやった。
デザインパターンを身につける
トンチンカンな設計をしたままコーディングに進んでしまって、あとあと大きな手戻りが発生する…みたいな経験を何度かしたので、その問題を克服するためにいくつか本を読んだ。

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技
- 作者:ロバート・C・マーチン,Robert C. Martin
- 発売日: 2008/07/01
- メディア: 単行本
どちらもまずはパラパラと一周読み、実際に業務で設計しながら使えそうなところを後で何度もじっくり読むようにして、辞書的に使っている。
はじめからじっくり読んでもイメージが湧きにくいし、読み終えるまでにダレるし、一度だけじっくり読んだってすぐに忘れるので。
フレームワークに馴染む
業務でRails を使っていることもあり、とにかくRails way に乗って素早く・(Rails のお作法的に)正しく・美しく実装ができるようにしたくて、Rails に慣れ親しむのを意識した。
初めの方はRails チュートリアルをじっくりこなしたり、今年の夏にパーフェクト Ruby on Rails の改訂版が出たのでそれを読み進めたりした。
初めてRails を学んだ対象が、それなりに歴史のある大きなRails プロジェクトだったこともあり「よく分からんけどなんか動いてる」といった知識の穴が結構多く、その穴を埋めるのにはとても良かったと思う。とはいえ、未だにRails 知らない機能多いけど。
gem のコードをたくさん読む
これは特になにか意識付けがあったわけではないし、どちらかというとバグ調査などで必要があったから読むことが大半ではあったものの、面倒くさがらずにちゃんと読んで理解するのは結構自分のためにはいい経験だった。
また、danger-rubocop というgem のバグに遭遇し、該当の箇所を読んでみたところ直せそうな雰囲気を感じたのでPR を送ってみたところなんとマージしてもらうこともできた。(OSS 初コントリビュート!) 内容的には些細なバグ修正ではあるものの、自分のスキルの向上を感じれたのでこの経験はかなり嬉しかったし、自信にも繋がった。 github.com
来年は引き続きソフトウェア開発のスキルは伸ばして行きたいなーと思いつつ、kubernetes を本格的に触り始めたのでその辺りの開発・運用もガッチリやっていきたい。 また、サービスの性質上膨大な量の画像・動画を取り扱うので、メディアの基礎的な知識も更に蓄えていかねばという感じ。
来年も引き続き頑張っていきましょう!
宣伝
自分が所属する「家族アルバム みてね」ではエンジニアを大募集中です! medium.com