MOBILUS TECH BLOG

MOBILUS TECH BLOG

モビルスのプロダクト開発を支えるメンバーが 日々の開発現場の情報を発信します。

Go製の負荷テストツール「Vegeta」を使ってみた

はじめまして。Platform Development DivisionのWataru.Nと申します!
先日、Next.jsについてブログを書いていた Alek さんと同じチームで開発を行っています。

最近、調査の一環として簡易な負荷テストを行う機会があり、Goで作られた Vegeta というオープンソースのツールを使いました。
(名前についてはリポジトリを開くとわかりますが、あのベジータです)

Vegetaは基本的にはCLIベースでシンプルに使えるものですが、Goのライブラリとしてシナリオを書くこともできます。私が担当しているサービス(Security Suite、CRM Connect)ではバックエンドの開発言語にGoを使用しているため、親和性も考慮して採用してみました。

本記事ではその基本的な使い方を紹介します。

使用例(CLI)

まず、CLIでサクッと使用する例です。 コマンドをベタ書きして実行することも、用途別にファイルを用意してそれを入力とすることもできます。 今回は管理のしやすい後者のやり方で行いたいと思います。

インストール

以下の公式リポジトリに書いてある手順を参考にインストールします。

https://github.com/tsenart/vegeta?tab=readme-ov-file#install

macOSの場合:

$ brew update && brew install vegeta
...

$ vegeta -version
Version: 12.12.0

準備

以下のようなファイルを作成します(各ファイル名は任意です)。

.
├── input.json    # リクエストボディを定義
└── targets.txt   # リクエストを定義

リクエストメソッドおよびURL、ヘッダなどを targets.txt に定義しておき、実行時に input.json からリクエストボディを取得してリクエストを行うという流れになります。

targets.txt

今回は例として、ローカルで起動しているアプリの認証APIを叩くものとします。
※一般公開されているURLに対しては行わないようご注意ください

POST http://localhost:8080/app/auth
Content-Type: application/json
@input.json
input.json

認証APIへのリクエストに使用するリクエストボディを記載します。

{
    "email": "sample@sample.com",
    "password": "samplepassword"
}

実行

以下は、targets.txtファイルで定義した認証APIへのリクエストを 10リクエスト/秒 で 5秒間 投げ続ける例です。

$ vegeta attack -rate=10 -duration=5s -targets=targets.txt > result.bin | vegeta report
Requests      [total, rate, throughput]         50, 10.20, 10.08
Duration      [total, attack, wait]             4.96s, 4.9s, 59.857ms
Latencies     [min, mean, 50, 90, 95, 99, max]  57.258ms, 61.022ms, 59.972ms, 61.551ms, 62.448ms, 99.702ms, 99.702ms
Bytes In      [total, mean]                     8800, 176.00
Bytes Out     [total, mean]                     5300, 106.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:50  
Error Set:
  • 実行は attackコマンド で行います
  • 結果は result.bin に保存され、最後にそれを reportコマンド で読み込んでメトリクスを表示しています

結果の項目の意味については reportコマンド のセクションに記載されています。

今回でいうと

  • Requests[total] より、合計50リクエスト実行されたこと
  • Latencies[mean] より、平均レイテンシは 61.022ms であったこと

などがわかります。

また、plotコマンドを使用することで、結果ファイルから「レイテンシ - 時間経過」のグラフをHTML出力することが可能です。

$ vegeta plot result.bin > plot.html

plot_image
plot_image

使用例(Goライブラリ)

続いて、先程と同様のテストシナリオをGoで作成し、実行してみます。

環境

OS:     macOS Sequoia 15.2
Go:     go1.22.1 darwin/arm64
vegeta: v12.7.0+incompatible

コード

sample.go

package main

import (
    "encoding/json"
    "log"
    "os"
    "time"

    vegeta "github.com/tsenart/vegeta/lib"
)

// ログインリクエストのパラメータ
type LoginRequest struct {
    Email     string `json:"email"`
    Password  string `json:"password"`
}

func main() {
    // 10リクエスト/秒
    rate := vegeta.Rate{Freq: 10, Per: time.Second} 
    // 実行時間 = 5秒間
    duration := 5 * time.Second 

    // リクエストボディの作成
    req := LoginRequest{
        Email:     "sample@sample.com",
        Password:  "samplepassword",
    }
    body, err := json.Marshal(req)
    if err != nil {
        panic(err)
    }

    // targeterを定義
    targeter := vegeta.NewStaticTargeter(vegeta.Target{
        Method: "POST",
        URL:    "http://localhost:8080/app/auth",
        Header: map[string][]string{
            "Content-Type": {"application/json"},
        },
        Body: body,
    })

    // attackerを定義
    attacker := vegeta.NewAttacker()

    // 実行
    var metrics vegeta.Metrics
    for res := range attacker.Attack(targeter, rate, duration, "Login Test") {
        metrics.Add(res)
    }
    metrics.Close()

    // 結果をレポート
    reporter := vegeta.NewTextReporter(&metrics)
    if err := reporter.Report(os.Stdout); err != nil {
        panic(err)
    }
}

コードとしては、CLIの例で作成した targets.txt, input.json の内容を targeter 変数に持たせるようなイメージです。 その情報をもとに、attacker.Attack() で指定された頻度でリクエストを実行します。

Attack() の内部ではセマフォを使用することで並行リクエストを管理しているようです。

実行

上記コードを実行すると、CLIで行った場合と同様に以下のような結果が出力されました。

$ go run sample.go
Requests      [total, rate, throughput]  50, 10.20, 10.08
Duration      [total, attack, wait]      4.961705416s, 4.900639666s, 61.06575ms
Latencies     [mean, 50, 95, 99, max]    65.302604ms, 60.294812ms, 99.862207ms, 169.72579ms, 169.725791ms
Bytes In      [total, mean]              8800, 176.00
Bytes Out     [total, mean]              4350, 87.00
Success       [ratio]                    100.00%
Status Codes  [code:count]               200:50  
Error Set:

まとめ

負荷テストツールVegetaについて、CLIベースでの使い方とGoのライブラリとしての基本的な使い方を紹介しました。
動作が軽量なことに加え、実施したいテストの内容や複雑さによって2パターンの使い分けができる点が良いなと感じました。
シンプルに負荷テストを行いたい方、あるいはGoでテストシナリオを作成してみたい方はぜひ試してみてください!

モビルスでは、一緒に働く仲間を募集中です! 興味のある方は、ぜひ採用情報のページをご覧ください!

SaaSサービス提供開始8年目!インフラ環境の再構築を目指します!

こんにちは。RecruiterのH.Onoです。

 

モビルスは2016年に自社SaaSプロダクト「MOBI AGENT」の提供を開始させ、今では7つのプロダクトを提供するまでに成長しました。

 

「これからのモビルスが目指すこと」を実現するために、プロダクトの屋台骨となるインフラ全体の環境も再構築予定。

 

今回はインフラSectionMgrのC.Junに協力してもらい、インフラが現在抱えている課題や目指す組織の形をまとめました!

 

\こんな方におススメ/

・SaaSサービスの刷新に興味がある方

・インフラ環境の標準化に関心のある方

・新しいチャレンジをしたいSREエンジニアの方

・当社のインフラエンジニアの仕事内容に興味を持った方

・当社のインフラ部門の課題/取り組みを知りたい方

 

お読みいただけると嬉しいです。

現状のインフラ体制

     現在モビルスの全プロダクトはクラウドサーバー(AWSをメインに、MicrosoftAzureやGCPも一部使用)上で運用しています。

     開発者が構成や手順をAWS CloudFormation上で作成して、プロダクトごとのインフラ担当者がリソースの作成、運用レベルでのリリースやモニタリング、バックアップの設定を行っています。

課題

  現在インフラ部門ではサービス運用当時からアーキテクチャの見直しがない状態でインフラの運用だけに集中していました。新しいサービスや機能が追加される時にリソースを追加する形で運用を続けました。そのため、アーキテクチャはレガシーの構成から最新のアーキテクチャまで混在している状況です。一方でサービスインフラ毎にアーキテクチャの標準構成がなく、プロダクトごとに異なるインフラ構成やパイプラインが使用されています。その結果、自身が担当するプロダクト以外のインフラ環境を理解するのが難しく、リソース管理や運用に非効率が生じています。

これから目指すインフラ環境

    これからの3年間で「異なるプロダクトであってもインフラ環境は標準化されている」という状況を目指したいです。そのために3つの事に集中して取り組む予定です。

  1. CI/CDの標準化
  2. インフラアーキテクチャの標準化
  3. IaCの推進

1.CI/CDの標準化 
 現在、開発側から管理しているパイプラインの管理をインフラ部門へ移行して技術スタックの統一と標準パイプライン(GitHub Actions)を準備して既存サービスや新規サービスのCI/CDをインフラメンバー全員が共通認識の上で理解出来るように構成します。

開発側はレポジトリにソースをPush/Mergeだけでパイプラインが適切な承認ラインで自動的にインフラへ反映される形を目指します。

2.インフラアーキテクチャの標準化 
 アーキテクチャ毎に標準テンプレートを準備して、新規プロダクトをローンチする際や既存の環境変更の際に適用していきたいです。標準アーキテクチの導入の理由は一つのアーキテクチャを理解すれば全ての同じアーキテクチャも理解出来ますし、インフラメンバーはサービスを横断して管理が出来ます。加えて、アーキテクチャの改善が発生した場合も一括で対応が出来ます。これは結果としてインフラ管理リソースの効率を上げることにつながります。

3.IaCの推進 
 インフラ構築を全てIaCコード(Terraform)を使用して自動的に行えるようにしたいです。コードで標準テンプレートを準備することで、コードを見ればアーキテクチャの理解が直ぐ出来ますし、コードの共通化でインフラ構築効率をあげることが出来ます。またコード化を推進することで、ドキュメントも常に最新へと更新されるので、ドキュメント管理の手間を省くこともできます。

組織体制

    目指す姿を実現するために、今後は運用を担当する部門とSRE(Site Reliability Engineering)部門に分け、それぞれの役割を明確にする予定です。SRE部門がインフラのアーキテクチャ設計や標準テンプレートの作成を行い、運用チームはそのテンプレートを使用して実際の運用を行う形に変更します。

 SRE部門ではインフラだけではなく、フロントやバックエンド、データベース、ネットワークを総合的に理解して最適な形を開発側に提供できる状態を目指します。SREのメンバーは全員IaCを行う上で、DevSecOpsやネットワークやセキュリティなど、それぞれの専門分野での強みを持って推進する組織にしたいです。

 一方で現在、モビルスが持っているサービスは特定の環境を共有していたり、アーキテクチャ的に分離されてない状況で様々な改善すべき課題を持っています。

 こうした背景があるので新しいアカウント戦略の基盤であるOrganization全般を新たに設計してセキュリティーや効率化を実現していきますし、今後の拡張時期に対応出来るような将来を見越した準備を行っていきます。

現在の進捗状況

 現在は既存の環境を維持しながら、新しい環境への移行準備を進めています。既存のアーキテクチャにレガシーな要素があるので、それを最新化しつつ、全体をコンテナベースに変更する計画です。特にプロダクション、ステージング、デベロップメントなどの各アカウントを分離して、セキュリティや費用の管理を強化させる方向で進めています。

 インフラの再構築は組織にとって大切なことですが、エンジニアにとっても問題解決能力や成長ができる重要な成長機会です。インフラ部門では現在一緒に働く方を探しています。興味がある方は採用ページを御確認ください!

 

最後までお読みいただき、ありがとうございました。

ハイブリッド勤務!!私達が週3日出社している理由。

こんにちは。モビルスRecruiterのH.Onoです。

今回はカジュアル面談や面接で質問いただくことが多い「出社体制」についてお伝えします!モビルスでは週3日以上の出社・残り2日は在宅勤務ができる「ハイブリッド出社」を採り入れていますが、この記事ではそこに至る変遷や背景をご紹介します。

今までの変遷

   
 新型コロナウィルスに対する2021年1月緊急事態宣言に向けた動きをきっかけに、モビルスでもフルリモート体制が敷かれました。当時「モニターを自宅へ送って欲しい!」というエンジニアの方へ、急いで近所のスーパーから段ボールをもらって梱包し発送したのは良い思い出(笑)。
 感染状況を鑑みて、暫くの間はフルリモート体制を継続。その中でも2021年9月には、かねてから目指していた東証マザーズ(現グロース市場)へ上場。2022年10月には五反田オフィスから浜松町オフィスへお引越し。その後は徐々に出社の割合を増やし週3日出社に落ち着きました。

現在の出社体制

 コロナ禍を経てリモートワークのメリットも分かり、現在では出社と在宅のハイブリッド体制を採用しています。

  • 週3日出社 残り週2日は在宅OK ※希望者は週3日以上出社可。
  • 部門単位で曜日を決めて出社
  • 月1回の全社会議日は全員出社※社員は必須。業務委託の方は任意。

上記を現時点(2024年11月現在)社内ルールとしていますが、業務上必要な場合は週3日以上の出社となる場合もあります。

大切にしていること

 現在社員数は100名になりましたが、人数が増えてきたタイミングで「課題がどの部門のマターなのか分からずに抜け落ちてしまった」という苦い思い出があります。この反省からいざという時に協力できるよう、普段から気軽なコミュニケーションを取れる関係づくりを意識しています。そのための仕掛けの一つが部門単位で曜日を決めた週3出社です。もちろんリモートワークでも関係づくりはできますが、モビルスでは2023年11月に提供開始したオペレーション支援AI「MooA®」の追加機能開発を進めていて、各プロダクトへ順次連携していく重要なタイミング。ユーザーからの評価も高く、ここは皆で力を合わせて前に進みたいところです!

フリードリンクエリアには、お土産やお菓子の差し入れがよく置かれています(この場を借りて、いつもありがとうございます!)皆お菓子大好きなので分速で無くなります(笑)

働く環境

「気軽なコミュニケーションを取れる関係づくり」の仕掛けとしては、他にも部活動制度やシャッフルランチ、月1全社会議後の懇親会などを用意しています。
 いずれも強制ではなく任意参加なので、その時の都合や気分に合わせて参加を決められる自由な感じが個人的には「無理が無くていいな」と感じています。
 出社の際には少しでも快適なオフィス環境を整えたいという想いから、集中して開発を進める事が多いエンジニア部門を中心にアーロンチェアを配備しています。(腰痛の時に座ったら、あっという間に痛みがなくなりました!人生の中でいつか欲しい!)

最後までお読みいただき、ありがとうございました。
この記事を通して少しでもオフィスの雰囲気や働く環境が伝われば嬉しいです。オフィス見学も大歓迎です。ぜひ気軽に遊びに来てくださいね!

モビルスでは、一緒に働く仲間を募集中です! 興味のある方は、ぜひ採用情報のページをご覧ください!

コードが読めない時のつまずきポイント

いよいよ今年も終わろうとしていますね。

1年を振り返ってみて、担当製品のモビキャストでは大きなリファクタリングを乗り越え、個人としても、多くのカンファレンスに参加したり、プログラミング言語の幅を広げたり、AWSのアーキテクチャを勉強したり、とても充実した1年でした。
来年もどうぞよろしくお願いします。

さて、今回から「宮内」あらため、「MIYA.TOMO」として投稿していきます!

ここ1ヶ月、弊社の主要製品の1つであるモビエージェントのプログラムを読んでおりましたが、コードが読めない場面に何度も遭遇しました。

自分なりにコードが読めない原因を分析しましたので、どうぞご一読ください!

コードが読めない原因を分析!

コードが読めないと一口に言っても、そこには様々な原因があります。
今どこでつまずいているかを把握することで、対処法も違ってきます。

プログラミング経験のある人が新しいプロジェクトでコードを読む時に、どういうところでつまずくのか、その解決方法についてまとめてみました。

1. プログラミング言語の構文がわからない

[状況]

そもそも知らない言語なので、何が実行されているのか理解できない。

[症状]

古代メソポタミア語を解読しているようで、ただの文字の羅列に見える。

[解決方法]

  • 読んでいてわからない構文が出てきたらGPTやCopilotに聞く。
  • 聞いた結果、詳しく調べないと理解できないものだったら技術書やネットを調べる。

例) Scalaで、

  val members = susbscribed ++ operators.map(u => u.id).toSet

という実装がわからない場合、Copilotに聞くと「++ はコレクションの要素を結合する」と回答されます。コレクションは他の言語でもよく見る概念ですので、一般的なプログラマであればここまでで十分です。

一方、Scalaの暗黙のパラメータ(implicit)や、Goの並行・並列処理(chanやgoroutine)は言語特有の処理です。 その言語が「初めまして」の場合は詳しく調べてその概念を知る必要があります。その言語の思想に触れるみたいで楽しいです。

2. プログラムのアーキテクチャがわからない

[状況]

modelパッケージとかactionパッケージとか、パッケージ構成がわからない。
アーキテクチャやフレームワークが見えていない。(DDD?MVCモデル?MVVM?クリーンアーキテクチャ?オブジェクト指向?Pub/Sub?CQRS?etc.)

[症状]

とにかく片っ端から参照先に飛びまくって迷子になる。目が回る。

[解決方法]

  • 先駆者に聞く。
  • とにかくコードを読んで規則性やフレームワークを見つける。

アンチパターンとして、この時点で手を止めて、アーキテクチャの本を読み始めたり、アーキテクチャの詳しいサイトを調べ始めたりしてはいけません。アーキテクチャの奥深さを舐めてはいけない。ソースを読むことを後回しにして、アーキテクチャの勉強に多くの時間を費やすと、再開する頃にはすでに読んだコードをキレイサッパリ忘れています。

アーキテクチャを学ぶことは大変良いことです。実装コードが目の前にあれば理解も深まり勉強になります。
ただ、ソースを読むのを止めてまですることではない、という趣旨です。

3. 業務の流れやシンボル(変数名や関数名など)の意味がわからない

[状況]

PrivateRoomって何?このテーブルってどう使うの?

[症状]

膨大なプログラムのどこから読んだらいいのかわからず絶望する。

[解決方法]

  1. マニュアルを読む。

  2. debugログを入れて主なシナリオをローカル環境で動かす。

  3. 気になったところは設計書、Slack、社内Wikiなどを調べ、わからなかったら先駆者に聞く。(時間がない場合はいきなり聞いてもOK。ただし、調べることで周辺の知識も自然と目にするようになり、思わぬところで知識とプログラムが結びつくことがあります。点じゃなくて面で学ぶ姿勢が意外と重要です。)

最速でコードを読む方法!

SIerをやっていて色々なコードを見る機会があったので、経験則ですが、

すでに言語を習得していれば1. は通過できます。
プログラムのアーキテクチャを学んでいる人ならば、2. も予想しながら読めるため時短になります。

つまり普段から意欲的に学習している人は、1. と2. をショートカットできるのです。
これが最速でコードを読む方法です。

しかし、どんな熟練のプログラマであっても、3. はショートカットできません。最後は、シンプルに、コードに触れた時間=コードの理解となります。

泥臭く時間をかけるしかありません。これに尽きます。

こうなったら勝ち(ゴール)!

1. や2. を通過すると、

  • コードを読む怖さがなくなる。
  • フレームワークが理解できる。(これを実現するならここに実装する、がわかる)

3. を通過すると、

  • よく使われるプログラムがどれかを区別できる。
  • メソッド名と引数、戻り値で処理内容が想像できる。
  • コードを書いた人の思考が推察できる。(ゾーンに入るとコードを書いた人と対話している気持ちになる。)

慣れてくると読まなくていいコードの見分けがついてきます。全部を読もうとするから全体像を掴むまでに時間がかかる。
例えば、writeDebugText()というメソッドが呼ばれているとすると、名前からしてログ関連の処理だけで副作用もなさそうなので、直近で中身を知る必要がなければスルーします。

まとめ

普段からプログラミング言語やアーキテクチャを学ぶことで、最初の壁を素早く乗り越えることが可能です。

一方、いくら熟練のプログラマであっても、製品知識を持たずして、正確にプログラムを読み解くことは困難です。
(処理の流れを読んで意味の推測も可能ですが、大規模なシステムでは時間がかかりすぎるため非現実的です。)

先駆者には敬意を持って接し、色々聞き出しましょう。
あとはひたすらコードを読むべし、読むべし、、、そのコードのよき理解者になりましょう!

最後に

最後までお読みいただき、ありがとうございました。
モビルスでは、一緒に働く仲間を募集中です!
興味のある方は、ぜひ採用情報のページをご覧ください!

Next.jsの特徴について

こんにちはPlatform Development DivisionのAlek.Sと申します!
フルスタックエンジニアとしてSecurity Suite, CRM Connect for Salesforceなどの開発を行っております。
この記事は、CRM Connectの新製品開発で採用したNext.jsについて紹介します。
そもそもReactとNext.jsって何、どのようなメリットがあるかについてまとめました。

続きを読む

AWSのSSM パラメータストアを一発でCSV出力する方法

Written by Tomotaka Miyauchi

9月に入ってもまだまだ暑いし夏だなぁ〜、と思っていたら急に秋になりましたね。
どうも、SaaS Product Divisionの宮内です。

背景

この前、AWS SSM パラメータストアの値を整理しようと思い立ちました。

登録済みのパラメータ一覧が欲しくなりましたが、コンソール上から拾ってくるのはエンジニアらしくないので、AWS CLIを使って一覧をズバッと取得しようと思いました。

ただ、意外とネット上にドンピシャの答えがなかったので、(GitHub Copilot Chatに助けを借りながら)これが最適解かな、と思うコマンドを導き出したので紹介します。

コマンド

最初に結論です。ドンッ

$ export AWS_PROFILE=dev
$ aws ssm get-parameters-by-path --with-decryption --path "/" --recursive --query "Parameters[?contains(Name,'develop')].{Name:Name,Value:Value}" | jq -r 'sort_by(.Name) | .[] | [.Name, .Value] | @csv' > parameter_store.csv

このコマンドでは、AWS Systems Managerのパラメータストアにある全てのパラメータのうち、名前に"develop"が含まれるものを抽出しています。 暗号化されているパラメータもデコードして出力します。

また、パラメータの名前を"/[製品名]/[環境名]"のようにサブディレクトリで定義している場合は、以下のコマンドでも取得可能です。

$ export AWS_PROFILE=dev
$ aws ssm get-parameters-by-path --with-decryption --path "/[製品名]/[環境名]/" --recursive --query "Parameters[].{Name:Name,Value:Value}" | jq -r 'sort_by(.Name).[] | [.Name, .Value] | @csv' > parameter_store.csv

では、解説していきます。

前提条件

  • 実行環境はMacです。
  • jqをインストールしておきます。※
  • AWS CLI v2をインストールしておきます。
  • AWS CLI v2のプロファイルを設定しておきます。(AWS_PROFILE=devの部分を指します)

    jqはコンソール上でJSON形式を加工するためのパッケージです。Macの場合、Homebrewからもインストールできます。

    $ brew install jq
    $ jq -V
    

解説

大枠のつくり

パイプラインで繋がっているだけで、このコマンドは次のように分解することができます。

  1. AWS CLIでパラメータストアからパラメータを抽出します。
  2. 抽出したデータをjqコマンドで JSON → CSV の形式へ変換します。
  3. 変換したCSVをファイルに出力します。

具体的には以下の通りです。

$ aws ssm get-parameters-by-path --with-decryption --path "/" --recursive --query "Parameters[?contains(Name,'develop')].{Name:Name,Value:Value}"

で、AWS CLIを使ってパラメータストアのデータをjson形式で取得し、

$ jq -r 'sort_by(.Name) | .[] | [.Name, .Value] | @csv' [前段パイプラインの出力結果]

で、jqを使ってCSVの形式に編集し、

$ [出力結果] > parameter_store.csv

で、編集したCSVの内容をファイルに出力します。

1. パラメータの抽出

$ aws ssm get-parameters-by-path --with-decryption --path "/" --recursive --query "Parameters[?contains(Name,'develop')].{Name:Name,Value:Value}"
[
    {
        "Name": "/myapp/develop/config",
        "Value": "some-value"
    },
    {
        "Name": "/myapp/develop/secret",
        "Value": "another-value"
    }
]
  • aws ssm get-parameters-by-path

    パラメータストアからパラメータを取得します。 get-parameters-by-pathは、指定されたパス以下のすべてのパラメータを取得するためのサブコマンドです。

  • --with-decryption

    暗号化されたパラメータの値をデコードして取得します。

  • --path "/"

    取得するパラメータのパスを指定します。サブディレクトリを指定する場合は、こちらに設定します。

  • --recursive

    指定されたパス以下のすべてのパラメータを再帰的に取得します。これにより、サブディレクトリ内のパラメータも含まれます。

  • --query "Parameters[?contains(Name,'develop')].{Name:Name,Value:Value}"

    aws ssm get-parameters-by-pathで取得されるデータは以下のフォーマットです。
    そのため、Parameters属性に対してクエリを実行します。

    {
      "Parameters": [
          {
              "Name": "/myapp/develop/config",
              "Type": "String",
              "Value": "some-value",
              "Version": 1,
              "LastModifiedDate": 1530018761.888,
              "ARN": "arn:aws:ssm:us-east-1:111222333444:parameter/site/newyork/department/marketing"
          },
          {
              "Name": "/myapp/develop/secret",
              "Type": "String",
              "Value": "another-value",
              "Version": 1,
              "LastModifiedDate": 1530018823.429,
              "ARN": "arn:aws:ssm:us-east-1:111222333444:parameter/site/newyork/department/infotech"
          },
          ...
      ]
    }
    

    パラメータ名(.Name)に "develop" が含まれるものをフィルタリングします。フィルタリング結果から名称(.Name)と値(.Value)フィールドを抽出します。

2. CSV形式に変換

$ jq -r 'sort_by(.Name) | .[] | [.Name, .Value] | @csv' [前段パイプラインの出力結果]
"/myapp/develop/config","some-value"
"/myapp/develop/secret","another-value"
  • -r

    jqの出力を生の文字列(raw output)として表示します。引用符が取り除かれ、CSV形式の出力が得られます。

  • sort_by(.Name)

    JSONデータをNameフィールドに基づいてソートします。

  • .[]

    ソートされた配列の各要素に対して処理を行います。以下のように配列の1要素ごとに以降の処理を行います。

    {
      "Name": "/myapp/develop/config",
      "Value": "some-value"
    }
    {
      "Name": "/myapp/develop/secret",
      "Value": "another-value"
    }
    
  • [.Name, .Value]

    各要素のNameとValueフィールドを抽出します。これは、配列の各要素から特定のフィールドを選択するためのフィルタです。

  • @csv

    抽出したフィールドをCSV形式に変換します。

3. ファイルに出力

$ [出力結果] > parameter_store.csv

変換した結果をCSVファイルに出力します。
標準出力をファイルに出力する、お馴染みのコマンドですね。

おまけ

このコマンドをそのまま使うことはないと思います。

実行して「動かない?」場合は、aws ssm get-parameters-by-path 〜の部分だけを実行して、コンソール上にJSON形式で出力されることを確認しましょう。

モビルスでは、一緒に働く仲間を募集中です!
興味のある方は、ぜひ採用情報のページをご覧ください!

育休で気が付いたらQAしていた件

はじめまして、モビルスで品質保証を担当しているQA Section所属の倉持です。

モビルスでは女性・男性共に育児休業(以降、育休)を取得することが可能です。 社内ではライフステージの変化を迎える方も増えてきていて、 今秋以降も複数の男性メンバーが育休取得予定。

自分も昨年子供が生まれたので、この度育休を取得しました。
今回は育休で感じたことや実体験を男性側の視点でお届けします。
タイトルは最後にえいやー!で回収します。笑

1.背景

取得理由

育休を取った理由はざっくり以下になります。

  • なんとなく取るものだと思っていた
  • 世の中的にはまだ男性の取得が目立っていない印象
  • 自分の友人らが取得していて、「よかった!」というのを聞いていた

まず取得する際、当時の上長に相談したところ
「休みではないからね~。実際休む暇はないと思うけれど★」みたいなことを言われた記憶があります。
今思うと、本当にその通りで休みはないです...が、それ以上に子の成長を
日々実感できるのが何よりも大きいです。

育休・子育ての前提としては妻側を「手伝う」ではなく、お互いが「主体」の立場
だといい流れを作ることができる気がします。

取得期間

2024年3月頃~2024年7月31日
大体4か月ほど取得しました。

書類関連

育休を取得するにあたってたくさんの書類提出が控えています。
思ったより時間がかかったので大変でしたが、社内Wikiや人事の方のフォローもあり
特に問題はありませんでした。
ただ、ご自身でも調べておくことを推奨します。笑
例)育休の条件、育休中の手当

引継ぎについて

育休前最終日はバタついたもののチームへ引継ぐ情報は前々から
整理できていたので、早めに相談してよかったと思ってます。

また、見込みでいいので復帰後の大体のタスクも記載しておくと、後々スムーズです👍
自分の場合メモを残しておいたので、よかったと感じています。

2.育休スタート ~3・4月編~

まずは覚える

初日からすぐに、修業期間として1週間ほどワンオペでやってみました。笑
当時の1日のスケジュールは大体以下です。

時間 やること 所感
7:00~9:00 ミルク・おむつ替え 朝一は吐き戻しが多いので注意
12:00前後 ミルク・おむつ替え お昼食べたい・・・
15:00~16:00 お風呂・ミルク・おむつ替え 準備であたふた&自分たちの夕食も準備
19:00~20:00 ミルク・おむつ替え 自分もお風呂入りたい・・・
23:00前後 ミルク・おむつ替え ここで吐き戻しあると大変
2:00~5:00 ミルク・おむつ替え 場合によってはもう寝ることは不可

ミルク・おむつ替え後の各間、寝てくれると他のことができるのですが
各間でかなり差があったと思います。また、他のこと、といっても次やることの
準備でほぼ終わっていた記憶があります。笑
ミルクやおむつ替えといっても、実は細かい工程がいくつもあることを知りました🧐

この時期の具体的な成長としては首がまだ据わりかけでしたが、嬉しさの感情が
出てきたのかニコニコしてくれました。

<4月頃>

修業後

大分鍛えられたのか、1人でもこなせるようになりました。
今後の担当について妻と話し合った結果、以下のように割り振ることにしました。
もちろん、子供のことで何か気がついた時はお互い担当関係なく、やるようにしてました。

  • 1日ずつ下記の①と②を交代していく
    • ①おむつとミルク担当、②その日の夕食、お風呂担当
  • 友人に会う等の外出予定がある時
    • 例)出かける側が①を事前に2日連続でやり、残る側が当日1人でやりきる

3.うまくはいかない時もある~5・6・7月編~

離乳食がスタート

5月くらいからは離乳食が始まりました。
大分余裕が出てきたものの...やはり準備・計画が大事だと実感しました。

時間 やること 所感
7:00~9:00 ミルク・おむつ替え・離乳食 食べる量間違えないように
~11:00前後 お散歩 近所を歩いたり、雨の日は絵本を読む
12:00前後 ミルク・おむつ替え ここで寝てくれるとその後動きやすい
15:00~16:00 お風呂・ミルク・おむつ替え お風呂は好きみたいで機嫌はよかった
19:00~20:00 ミルク・おむつ替え ミルク前後で泣くことが多かった時間帯
23:00前後 ミルク・おむつ替え スヤスヤタイムに入れば...🙌

離乳食はアレルギーとかあるので慎重に進めました。
7月頃からは2回食にして、お昼にも離乳食を与えていました。
具体的な成長についてはハイハイしたり、つかまり立ちしたり...等で
考えることがより増えた時期でもありました。

<7月頃>

定着はしたものの...

流れがルーティン化してきて、気分転換に趣味の陸上の練習・記録会に出ていました。
ただ、どうしても寝かしつけがうまくいかない時が多く、悩んだ時期でもありました😔

特に6月頃からは暑くなってきて、以下のようになってしまいました。

  1. 泣いたので抱っこしてみる
  2. 密着するのでお互い暑い ※赤ちゃんの体温は元々が高いため汗をかきやすい
  3. 暑いせいか余計泣く
  4. 一度床に置いてみる
  5. (以下ループ...)

このようにどうしようもない時もあるので、精神論でなんとかやってました。笑
とはいえ寝顔を見てからは不思議とがんばれた気がします!

4.復帰してみて~子の成長と時の流れは早い~

気が付いたらもう8月

本当にあっという間に月日は流れて、気が付いたら約4か月間の育休が終了していました。
むしろ、もう少し長く育休を取得してもよかったかもしれません。笑

振り返ってみると育休開始時は本当にバタバタして実はもう記憶がほぼないくらいです。
成長具合で言うと、寝返りができたかどうかくらいだったと思います。
ですが、今はつかまり立ちをしたり、後追いされたりで、毎日成長しているんだな~
と感じています。自分はもう退化する一方なのに...。笑

いろいろありましたが8月1日に無事に復帰できました🙌
初日は久々のオフィスで少し懐かしさもありつつ、チームメンバーや他部署の方も
元気に迎えてくれてとても安心感がありました。

5.最後に

子育てはまるでQAの活動みたいでした

結果的に育休は取得してよかったです。普段と今後の生活の見直しにもなりました。
子育ては振り返ってみると、これまで普段やってきたQA活動のように感じました。

子育て QA活動
お風呂、離乳食等の準備 テスト計画、テスト観点出し
ミルク量や離乳食の種類を考えて調整する テストケース数見積り、作成、追加
ミルクや離乳食を与える、おむつを替える テスト実行
お昼寝や睡眠・笑顔等日々の成長 無事リリース、お疲れさまでした
- 振り返りしつつ、改善点を次回実践する。

なんとなくですが、全体的に流れが決まってくるとリグレッションテスト※1を
やっているような感じになりました。笑
ただ、難しいのが手順や期待値に決まりはなく、何か問題があった時は自身の
「改善」として捉えていく必要があると考えています。

…そんなわけで子育てはQA(以下略、ここでタイトル回収)。笑

最後になりますが、育休に関してご理解くださった会社・部署・チームメンバーには
改めて感謝しております。ありがとうございました🙇

育休は取れる時に取っておくと、後々自分にとってもプラスになるのかなと思うので
迷っている方はぜひ相談・取得してみてほしいです。

育休に対してはキャリアへの不安もあるかもしれませんが、むしろ見つめ直すいい機会でもあります。
世の中的にはまだまだ男性の育休取得率は決して高くはないかもしれません。
近い将来、今よりも増えているといいな~と感じています。

以上になります。
ここまで読んでいただいた方、ありがとうございました。

※1…「回帰テスト」とも呼ばれる。今回は本題と異なるので正しい定義は省きますが、ここでは「新しいことを追加しても、大体同じ流れで
繰り返し実行して、いつも通り問題ないよね」くらいのイメージで捉えてもらえると幸いに存じます。

モビルスでは、一緒に働く仲間を募集中です! 興味のある方は、ぜひ採用情報のページをご覧ください!