2023-05-31

Amazon ECS Execを使ってみた

AWS

はじめに

こんにちは！スタイル・エッジ・グループのKYTです。
現在私はAmazon ECS(以下ECS)のAWS Fargate(以下Fargate)にて、弊社のシステムを運用できないか試行錯誤中です。
今回はそんな中で学んだECS Execについて書きたいと思います。

ECS Execとは

ECS Execは、ECSで実行中のコンテナにログインするための機能です。
この機能の画期的なところは、Fargateではできなかった各コンテナへのログインを可能にした点です。

ECS Execの登場以前、Fargateで起動したコンテナは原則ECSコンソールを駆使して状態を確認することしかできませんでした。
ECS Execの登場でコンテナにログインできるようになり、内部から状態確認ができるようになりました。
トラブル時の解析がより細かなレベルでできることなどから運用において大変心強い機能です。

また、ECS ExecはAWS Systems Manager (SSM) セッションマネージャーを使用して接続することから、セキュリティグループのインバウンドポートを開いたり、SSH キーを管理したりする必要がありません。

Fargateのプラットフォームバージョン1.4.0以降を利用した場合、ユーザーが手作業でSSMエージェントをインストールする必要もなく使いやすいのもこの機能のポイントです。

実際に使ってみる

それでは実際にECS Execでログインするまでの手順を追っていきたいと思います。

今回は、ECR Public Galleryで提供されているApacheのイメージからコンテナをFargate上に作成し、 Amazon Linux 2023の踏み台サーバーから操作を行うという環境で進めます。

Apacheコンテナはすでに作成済みで、 aws configureコマンドにてIAMの認証情報も登録できた状態から進めていきます。

構成を簡単に図でまとめると以下のようになります。

なお、Apacheコンテナの作成は下記のクラスメソッドさんの記事が大変参考になります。

【初心者向け】Amazon ECSでApacheを起動したい~新コンソール版~ | DevelopersIO

それではやっていきましょう！

AWS CLI のセッションマネージャープラグインをインストール

ECS Execはセッションマネージャーを使ってログインをすることから、 AWS CLIにセッションマネージャープラグインをインストールする必要があります。
ということで早速踏み台にインストール！

sudo dnf install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm

ECSからセッションマネージャーにアクセスするためのポリシーの作成

ECSからセッションマネージャーにアクセスするためにIAMポリシーを作成します。
今回はEcsExecPolicyという名前で作ります。中身は以下の通りです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssmmessages:CreateControlChannel",
                "ssmmessages:CreateDataChannel",
                "ssmmessages:OpenControlChannel",
                "ssmmessages:OpenDataChannel"
            ],
            "Resource": "*"
        }
    ]
}

タスクに紐づける実行ロールの作成

続けて、作成したEcsExecPolicyをアタッチするIAMロールを作成します。
今回ロールの名前は、EcsExecRoleとしました。
「信頼されたエンティティを選択」での設定内容は以下の画像の通りです。

次に出てくる「許可を追加」で、EcsExecPolicyをアタッチします。

タスク定義の新しいリビジョンの作成からタスクロールを指定する

ECSのコンソールに移り、Apacheコンテナを動かすタスク定義を選択し、「新しいリビジョンの作成」からタスクロールの選択をします。
ここで、作成したEcsExecRoleを指定し、そのまま作成します。

※タスクへのCPU、メモリの割り当ては最小構成で作成しています。

サービスからタスク定義のリビジョンを最新のものにする

タスクロールの設定に伴い、タスク定義のリビジョンが新しくなりました。
それに合わせて、ECSのコンソールからサービスで紐づけるタスク定義のリビジョンに最新のものを指定しましょう。

※画像では4が最新のリビジョンになっています。

サービスに対するECS Execを有効にする

踏み台に戻りAWS CLIからサービスに対してECS Execの機能を有効にします。
デフォルトだと無効になっているため、有効化しないとECS Execが使用できません。

aws ecs update-service --cluster ｛クラスター名｝ --service ｛サービス名｝ --enable-execute-command

あらためてタスクを起動する

ECS Execの機能が有効になるのは、次に起動するタスクからになります。
ということで、踏み台から以下のコマンドを使い新しくタスクを起こしなおしましょう。

aws ecs update-service --force-new-deployment --cluster ｛クラスター名｝ --service ｛サービス名｝

コンテナにログイン

いよいよ踏み台からコンテナにログインです。新しく起動したタスクのIDをコピーして以下のコマンドを実行してみましょう！

aws ecs execute-command --cluster ｛クラスター名｝ --task ｛タスクID｝ --container ｛コンテナ名｝ --interactive --command "/bin/bash"

問題がなければ

The Session Manager plugin was installed successfully. Use the AWS CLI to start a session.

Starting session with SessionId: ecs-execute-command-…

と出てコンテナの操作ができるようになります！

ちょっとした注意事項

以上で無事コンテナには入れるのですが、気をつけないといけないことがあります。
それは、コンテナにpsやtopなど調査で使うコマンドが入っておらず、ログインはできたけど確認ができないという場面に遭遇することです。

※今回使用したApacheのコンテナにもpsやtopコマンドは入っておりません。

実際にFargateを使う場面ではDockerfileで作りこんだイメージを使うことになるでしょうから、その際に調査用のコマンドも忘れずに含めておきましょう！

おわりに

今回はECS Execを使用してログインするまでの手順を紹介いたしました。
Fargateでもコンテナのなかに入れるようになったことで、運用上の安心感が以前より増したなあと個人的には感じております。

今回の記事が少しでも健やかなコンテナライフにつながれば幸いです。

そんなことをしている私が働くスタイル・エッジ・グループでは、一緒に働く仲間を募集しています。

もし興味を持っていただけましたら、採用サイト↓も覗いてみてください！
recruit.styleedge-labo.co.jp

2023-04-28

私のAnsibleのTips

こんにちは、システム事業部のTMです。
普段はシステムの開発・保守やサイトの運用保守をしています。

弊社では、Ansibleでサーバーやシステムの設定管理をしています。
管理している中で見つけたAnsibleのTipsを紹介したいと思います。

変数名

変数名にハイフンを使っていて失敗することがよくありませんか？

FILE-OWNERというハイフンを使った変数を使ったPlaybookの実行例が下記です。 FILE-OWNER という変数名なのにFILEとなっています。変数名のハイフン以降が認識されていません。

fatal: [web]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'FILE' is undefined\n\nThe error appears to be in 以下省略}

Ansibleでは変数名は英字、数字、アンダースコアのみで構成されている必要があります。また変数名は英字から始めなければいけません。
またPythonやPlaybookの予約語は使えません。 https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_variables.html#creating-valid-variable-names

cronの削除

Ansibleでは、cronモジュールを使用してcronジョブを設定することができます。

cron: 
   name: "upload log file to s3"
   minute: 45 
   hour: 8
   job: /usr/local/bin/aws s3 cp /var/log/httpd/access.log s3://log/access.log --no-progress

cronを設定する方法についての紹介記事はよく見かけますが、削除する場合についての記事は見かけません。
削除する必要が出てきた場合、どのようにしたら良いのでしょうか？
削除の場合だけ、crontabコマンドで削除しないといけないのでしょうか？

削除の場合はstateパラメータにabsentを指定します。

cron: 
   name: "upload log file to s3"
   state: absent

stateパラメーターのデフォルト値はpresentなので削除以外の場合は指定しなくても大丈夫です。
これで安全にcronを削除できますね。

暗号化したファイルを見るだけのコマンド

AnsibleのPlaybookはGitでバージョン管理されると思います。
その際、パスワードなどの機密情報を平文のままリポジトリにプッシュするのではなく、
Ansible Vault で暗号化してプッシュできます。

暗号化されたファイルを作成

ansible-vault create 暗号化するファイル

暗号化されていないファイルの暗号化

ansible-vault encrypt 暗号化するファイル

暗号化したファイルの編集

ansible-vault edit 暗号化したファイル

暗号化した内容を見たいだけというシチュエーションはよくあるのではないでしょうか？
ansible-vault editコマンドで確認もできるのですが、内容を確認するだけのコマンドもちゃんとあります。

暗号化されたファイルの中身を内容を確認

ansible-vault view 暗号化したファイル

ドライラン

Ansibleにもドライランがあります。
公式サイトではチェックモードと呼ばれています。

実行方法

ansible-playbook -i inventories/production.ini site.yml --check

--checkをつけて実行すると、リモートへの変更は行わずにPlaybookが正しく実行されるかどうかが確認できます。

おわりに

今回はAnsibleのTipsを紹介しました。
Ansibleを使うときの助けになれば幸いです。

スタイル・エッジ・グループでは一緒に働く仲間を募集しております。興味をお持ちいただけましたら是非とも下記を覗いてみてください！ recruit.styleedge-labo.co.jp

2023-04-24

仕事で行き詰まった時に、やっていること3つ

スタイル・エッジ・グループに入社して5年目のリンです。
社会人歴はそれ以上に長いのに、未だに課題に行き詰まったり
悩んだり改善したりを日々繰り返しています。

今回は、個人的によく行き詰まる課題に対して心掛けていることをまとめました。
職種問わず、誰かの行き詰まりのヒントになればと思います。

最初に「みんなが同じ認識」という状況を作る

コミュニケーション全般に言えることですが、
複数人で話を進めるうちに、話がズレ始めてしまい、いつの間にか迷路に入り込んでしまうことがあります。

原因はその時々だとは思いますが、前提として実は
「その場にいる全員の理解・認識のレベルにばらつきが発生していた」というのはよくある話です。

お互いの過去の記憶に頼るよりも、
まず話の最初に理解レベルを揃えるための「おさらい」や「前提」「話し合いのゴール」を説明するだけで、
各自の心理的なハードルが下がり、思った以上に話がスムーズに進みます。

とはいえやっぱり難しいなと思った方は、以下のパターンに当てはめてみるのはどうでしょう。

今日のミーティングはみなさんに◯◯を理解していただくことで、仕事で◯◯に活かしてもらうための会です

前回出た結論（もしくは宿題）は◯◯でした。それを踏まえて、今回は◯◯の議題について話し合い、◯◯の答えを出すことが会のゴールです

大体、このパターンを応用することでなんとかなる…気がします。
会議中、迷路に迷いがちな方はぜひ、試していただければと思います。

タスクに追われる前に、整理する

カレンダーに登録されているミーティングの数や、
チケット管理ツールやタスク管理ツールに記載された「期限付きのタスク」を大量に確認している時に、
ふとタスクに追われている自分に気づけることがあります。
（気づくことがまず大事です）

この時、急いでタスクを完了させねばと焦って走り出したい気持ちを抑えて、
とりあえずコーヒーを入れながら、優先度の整理を行います。

時間管理といえば、このマトリックス図が有名です。
さすがに毎日ここまでしっかり整理はしませんが、上記の図を念頭に軽くタスクを振り分けてみましょう。

この時、たまに「重要度がとても高いが、かなり時間もかかりそうな根深いタスク」に
気づくことがあります。

この課題こそが「業務に追われていると気づけず
ズルズルと抱え続けてしまい、いつまでも解決できないタスクになりがちです。

けれどもし、ここで気づくことができれば、この根深いタスクを
さらに細かいタスクに分解し、計画的に進めるための準備に入ることができるのです。

「仕事に追われる」というのはすなわち「重要なタスクを見逃すこと」と同義なので、
未来の自分のためにも、まずはここから始めたいところです。

「分からない」をそのままにしない

「何が分からないのか、分からない」

目の前に立ちはだかる壁が大きすぎて、その壁の先に崖があるのか、お花畑があるのかすら分からない。

この時の「分からないから、焦りすら感じない」という”無”の状態こそが
目の前のタスクをタスクと認識できていない瞬間と言えます。

そんな時の魔法の言葉は

「この件に詳しい方はいらっしゃいますか？」

です。

この言葉を言うのに、勇気が必要な人もいると思います。相手に「これくらいも知らないの？」と
思われたくないとか、相手の時間を奪ってしまうようで申し訳ないとか…。

けれど、その一言を口にするだけで状況は変化し、
結果「何が分からないのかが、”わかった”」が課題解決の第一歩となるのです。

未来の自分への投資と思って、知らないことがあったら堂々と
「知らない」と言えるメンタルで、時には取り組んでみてはいかがでしょうか。

最後に

スタイル・エッジ・グループでは一緒に働く仲間を募集しております。

興味をお持ちいただけましたら是非とも下記をクリックしてください🌸

recruit.styleedge-labo.co.jp

2023-03-31

エンジニアも知っていると嬉しいデザインの原則

こんにちは！システム事業部のMJです。
もうすぐ新卒4年目、インターンも含めると5年目になり、年次を重ねるごとにさまざまな経験をさせていただいています。
ここ1年ほど新規事業のシステム開発に携わっていますが、その中で特に記憶に残ったのがシステムのデザインを1から担当したことでした。
（この話をすると、毎日Adobe XDと睨めっこしながら、2ヶ月ほどピクセル単位の修正をしていた記憶が蘇ってきます…）

上記のようにシステムのデザインとまではいかなくても、UI設計を行ったり、プレゼン資料を作成したり…とエンジニアがデザインをする機会は想像以上にあり、デザインの経験がなくても知識を身に付けておくだけで役に立つことがあります。
今回は、知っているだけでドキュメントや成果物のアウトプットが向上するデザイン・設計のテクニックをご紹介します！

ペルソナ設計

ペルソナ（Persona）とは、サービス・商品の典型的なユーザ像のことです。マーケティングなどでよく聞くペルソナですが、デザインでも必要になってきます。ペルソナを設定するメリットとしては、

プロジェクトの関係者間で、共通した人物像を形成することができる
ユーザを具体的にイメージしやすくなるため、製品やシステムが実際に使われている場面をイメージしながらデザインができる
その人物像を掘り下げることで需要の高い（低い）コンテンツが見えてくるため、取捨選択など各種判断の材料になる

などが挙げられます。

具体的には、システムのメインカラーを決める際に暖色系か寒色系かで自分とステークホルダの意見が割れたのですが、今回設定した主要なペルソナが20代女性で美容クリニック勤務（以下詳細割愛）だったため、それを根拠に議論を重ね、双方納得する色合いでデザインを進めていくことができました。

このように、デザイン決定の判断軸としてペルソナ視点を用いることでスムーズに問題解決ができたときなどは、ペルソナ設定の重要性を痛感しました…

デザインの4原則

わたしが実際にデザインを担当してみるまでは、デザインというと、色や柄などの美しさのイメージが先行していました。
ただ実際にデザインしてみると、色や柄が美しくてもレイアウトが整っていないと、ユーザに情報が的確に伝わらないということがわかりました。

レイアウトを整えるために重要になってくるのが「デザインの4原則」です！

近接
関連する要素をまとめることで、グループ化して情報の整理を行う
整列
要素を意図的に配置してページ上に関連性や統一感を持たせる
反復
ルールに基づいてデザインの要素を繰り返す
対比
異なる要素間でサイズや色の強弱を強め、目立たせたい情報を強調する

この4原則を用いることで、論理的にレイアウトを決めていくことができます。

ただし、顧客管理のようなシステムでは情報過多になるため全体的に項目が詰め込まれる傾向にあり、近接・整列・反復は実現できても対比などは難しく苦労しました…
アクセントカラーを決めたり、アイコンを使用するなどして多くの情報の中でも目を引くよう意識しました！

システム開発時に意識するポイント

上記2つのポイントはデザイン全てにおいて基本となる考えですが、システムを開発する際に意識すべきポイントもあります。

流行りのデザインと使いやすいデザインは違うということ

システム事業部にはデザイナーも在籍しているため、おしゃれなデザインやかっこいいデザインを見せていただく機会も多く、システムにも取り入れたいと思ったことが多々ありました…

流行りのデザインは斬新で魅力的に感じますが、ユーザが日常的に使うシステムの場合、デザインによってはユーザが入力する前に考える時間が増えてしまうことがあります。

例えばボタンをアイコンのみで表現した場合、「このボタンはなんのボタンだっけ…？」と悩む一瞬の時間が積み重なってユーザのストレスに繋がりかねないため、デザイン性と利便性を兼ね備える必要があります。

おそらく、流行りのデザインはユーザにとって馴染みがない、システムで使うには情報が省略されすぎている、などの点から使いやすいと言えない場合があるのだと思います。

ターゲットや場面によって「使いやすいデザイン」が変わってくるので、都度判断していくことが大事になります。（この判断軸としてペルソナを用いることも有効）

ユーザレビューを必ず行うこと

これはシステム開発においてどのフェーズでも必要ですが、特にデザインをしていると、自分のデザインしたシステムが自分の「当たり前」になってしまいます。
自分が使いやすいと思ってデザインをしていても、実はユーザの業務都合上項目の配置はこうがいい、といったケースを何度も経験しました。

それだけでなく、世間的にベターとされている手法や理論でさえも、使い方次第ではユーザに受け入れられない場合もあります。
そういった気づきや学びを得るためにも、ユーザレビューは必ず行うよう心がけていました。

おわりに

今回は自分の経験から「エンジニアも知っていると嬉しいデザインの原則」をご紹介しました。
エンジニアとデザイナーは、別分野として捉えがちですが、知っておいたほうがいい知識がたくさんあります。少しでも興味を持つきっかけになれば幸いです！

実はわたしがシステムデザインを担当したきっかけは、色彩検定を取得したことでデザインに興味を持ち、「やってみたい！」と頼み込んだことでした。
やりたいことがあれば、話を聞き、実践する環境を用意し、気にかけてくれる、そんな社風が弊社の素敵なところだなと感じています…！

☆スタイル・エッジ・グループでは、一緒に働く仲間を募集しています☆
もし興味を持っていただけましたら、採用サイト↓も覗いてみてください！
recruit.styleedge-labo.co.jp

2023-02-28

CDKでCloudFormation StackSetsのデプロイを行ってみる

はじめに

お世話になっております。システム事業部のONです。
前回の執筆からちょうど2年になります。

中途入社して1カ月でアドベントカレンダー書いてと言われ、2~3カ月で技術ブログを書いてと言われ...
どちらもネタがないとオロオロしながら書いた記憶が鮮明に残っています。
そんな今回もネタがなくオロオロしているので試したかったことを実践してみます。

課題発生

ここ半年程、CloudFormationやSAM, CDKを触ることが多くありました。
これらの沼は深く、私はまだまだくるぶしぐらいしか浸かれていない状況です。

そんな最中、同一AWSアカウントの全リージョンにデプロイする内々のCDKを作る必要が発生しました。
当時はリージョンの配列をループさせて、各リージョンにスタックを作成する形で実装を終えたのですが...
後からCloudFormation StackSetsの存在を思い出し、これを利用すればもっとスマートな形にできたのでは...と疑問が出てきました。

StackSetsとCDK

CloudFormation StackSetsは複数のAWSアカウントやリージョンにスタックを作成できるサービスです。
すなわち、1つのテンプレートで複数のAWSアカウントやリージョンへの一括デプロイをしてくれます。
ドキュメントはこちらから。

StackSets の概念 - AWS CloudFormation https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/stacksets-concepts.html#stacksets-concepts-stackset

AWS Organizationsと組み合わせると、特定のOUに対してデプロイできたりメンバーアカウントが増えた際に自動的に反映してくれたりする、より強力な存在となってくれます。

CDKもAWSの各種リソースをデプロイすることができる仕組みです。
内部的にはCloudFormationが動いていますが、各種言語で定義できることが魅力の一つです。
CDKに関しては、当ブログで紹介している記事があるのでよかったらご参照ください！

AWS CDK入門｜準備からサブネットを分けるまで - スタイル・エッジ・グループ技術ブログ https://techblog.styleedge.co.jp/entry/2022/07/19/163825

さて、CDKで定義したリソースを複数のAWSアカウントやリージョンにデプロイするためにStackSetsと連携することはできるのか？というお話ですが...
CDKとStacksetsの連携は残念ながらサポートはされておらず、長い間issueがopenしている状態です。

StackSets Support · Issue #66 · aws/aws-cdk-rfcs · GitHub
https://github.com/aws/aws-cdk-rfcs/issues/66

ただ、このissueのなかでCDKを使ってStackSetsを作成する方法を紹介している方がいらっしゃいました。

https://github.com/aws/aws-cdk-rfcs/issues/66#issuecomment-754599325

せっかくなので、試してみましょう！！

実践編

StackSetsを扱うための準備として、下記2つのIAMロールを作成します。

AWSCloudFormationStackSetExecutionRole
操作するAWSアカウントのAdministratorAccessポリシーを利用できるロール

AWSCloudFormationStackSetAdministrationRole
CloudFormation経由でAWSCloudFormationStackSetExecutionRoleを利用できるロール

作成手順は以下のドキュメントをご参照ください。

Grant self-managed permissions - AWS CloudFormation https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-prereqs-self-managed.html

これらのIAMロールを作成するにあたって「ドキュメントは分割記載されていて分かり辛い！」という方は、CloudFormationのテンプレートも用意されていますのでおすすめです。

https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetAdministrationRole.yml
https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetExecutionRole.yml

それでは、先ほどのissueのコメントにならってCDKの実行ファイルを調整してみます。

調整前のループでスタックを作るコード

// HogeEnvなどをimport(省略)

const app = new cdk.App();

// リージョン毎にスタックを実行(HogeEnvは{ account: xxxx, region: yyyy }の配列)
HogeEnv.forEach(env => {
    new HogeStack(app, 'HogeStack', { env });
});

調整後のStackSetsでスタックを作るコード

// envなどをimport(省略)

const app = new cdk.App();

// デプロイしたいスタックからテンプレート文字列を生成
const stage = new cdk.Stage(app, 'Staging');
new DeployCDKAsAStackSetsStack(stage, 'DeployCDKAsAStackSetsStack', { env });
const stackSetTemplateObj = stage.synth().stacks[0].template;

// StackSetsを作成するためのCloudFormationスタックを作成
const stackSetDeployer = new cdk.Stack(app, 'StackSetDeployer');
// テンプレート文字列を使ってStackSetsを作成
new cdk.CfnStackSet(stackSetDeployer, 'DeployCDKAsAStackSets', {
    permissionModel: 'SELF_MANAGED',
    stackSetName: 'DeployCDKAsAStackSets',
    capabilities: ['CAPABILITY_NAMED_IAM'],
    stackInstancesGroup: [
        {
            deploymentTargets: {
                accounts: [env.account],
            },
            regions: ['デプロイするリージョン', ...],
        },
    ],
    templateBody: JSON.stringify(stackSetTemplateObj),
});

今回は同一AWSアカウント内で複数のリージョンにデプロイするのが目的です。
そのため、デプロイするAWSアカウントはOrganizationsに依存しない形になります。
これらからpermissionModelにはSELF_MANAGEDを設定しました。

StackSetsを作成するためのパラメーターは以下のドキュメントをご参照ください。

class CfnStackSet (construct) · AWS CDK
https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_cloudformation.CfnStackSet.html#autodeployment

デプロイ結果

今回はus-east-1とap-northeast-1の2リージョンを['デプロイするリージョン', ...],に指定します。
実行するとCloudFormationコンソールのStackSetsで2リージョンにスタックが実行されているのが確認できました。

同コンソールのスタック-スタックの詳細ではStackSetsを作成するためのstackSetDeployerスタックが作成され、
その後にStackSets経由で実際にデプロイしたいDeployCDKAsAStackSetsStackスタックが作成・実行されたことがわかります。

最後に

いかがでしたでしょうか？
2023年2月現在CDKのCloudFormation StackSets連携はサポートはされていませんが、
StackSetsを作成するスタックを定義することでCDKからStackSetsの作成ができることが確認できました。

冒頭のCDK内でループさせてスタックを作る方法だと、各リージョンでcdk bootstrapする必要がありました。
また、デプロイコマンドもcdk deploy --allとなって少々力業な感じが否めません。

StackSetsを作成する方法だと、記述量は増えてしまいますがIAMロールを2つ用意するだけで全リージョンのスタックを作成できるためスッキリとした構成にすることができました。
引き続き改善を進めていきたいと思います！

スタイル・エッジ・グループでは一緒に働く仲間を募集しております。
興味をお持ち頂けましたら是非とも下記をクリックしてください↓↓

recruit.styleedge-labo.co.jp

2023-01-31

WSLアプリを入れてsystemctlを使おう！

ツール

はじめに

こんにちは。システム事業部のTAKです。
私はWindows10内のWSL環境をローカル開発環境として使用しているのですが、従来のWSL環境ではsystemctlが使えなかったため、サービスの登録ができないなど少し残念な思いをしていました。
（なおWindows11&Ubuntu22.04.1であれば、昨年4月頃のWindows Updateにより今回紹介する内容が既に反映されています）

ところが昨年の11月下旬にWSLアプリがMicrosoftストアで正式リリースとなりました。
元々Windowsに入っていたWSLをアプリとして切り出した形になりますが、主に以下のメリットが増えました。

systemdが利用できる
機能追加やバグフィックスがOSアップデートを待たなくて済むようになる

ちなみに、既にWSLを入れていた方は以下メッセージがWSL起動時に表示されているかと思います。

Linux 用 Windows サブシステムが Microsoft Store で入手可能になりました。
'wsl.exe --update' を実行するか、https://aka.ms/wslstorepage にアクセスしてアップグレードできます
Microsoft Store から WSL をインストールすると、最新の WSL 更新がより速く提供されます。
詳細については、https://aka.ms/wslstoreinfo
をご覧ください。

ここまで読んで（察しの良い方はタイトルで）お気づきとは思いますが、Windows環境のみのお話です。
そもそもWSLって何？？という方は、すぐ下に公式ドキュメントのリンクを貼っていますので、先に概要を調べてから戻ってきていただけると助かります。

なお、以下に記載しているインストールから設定までの話は、MicrosoftのWSL公式ドキュメントを読めば詳細にすべて書いてあります。
また、wslコマンドのオプションも豊富にありますので、WSLの理解を深めたい方は本記事を読み終わった後に公式ドキュメントも読まれる事をオススメします。

learn.microsoft.com

それでは始めていきましょう！

インストール＆設定

前提条件

Windows 10 バージョン 2004 以上 (ビルド 19041 以上) または Windows 11

Microsoftストアよりインストール

Windows Subsystem for Linux
上記リンクのストアページよりWSLアプリをインストールします。はい、完了です。
ちなみに、OS同梱版で動かしていた人もこの手順で移行できます。簡単ですね。
（このペンギンのアイコン、微妙にイラっとするのは私だけでしょうか…？）

systemdのサポート設定

WSLアプリを起動（ターミナル等で起動でもOK）すると、新規の場合はUbuntuのインストール、既に利用している人はそのLinuxOSが起動すると思います。
以下コマンドを実行し、systemdのサポート設定を行います。

$ ls /etc/wsl.conf
# 無ければ作成
$ sudo touch /etc/wsl.conf
$ sudo vi /etc/wsl.conf

wsl.confに以下内容を追記

[boot]
systemd=true

WSL再起動のため、PowerShellより以下コマンドを実行。

wsl.exe --shutdown

再起動後、WSLに入ると以下のようにsystemctlコマンドが使えるようになっていると思います。

systemctl list-unit-files --type=service

これでsystemctlが使えるようになりました！！かんたん！！
WSL内にLAMPなどの学習環境を作った際や、Dockerをインストールした際にsystemctlに登録できない！といった悲しみから解放されます！ヤッター！

と、ここまでの設定手順も公式ドキュメントに記載がありますので、細かい部分についてはそちらをご確認ください。
Windowsフォルダの自動マウント設定の書き方などが載っています。

learn.microsoft.com

systemd設定後にちょっとハマった事

Dockerが起動しなくなった

私の環境ではDocker Desktopを使用せず、WSL内にDockerをインストールしていました。
従来のWSLではsystemctlが使えなかったため、Dockerのdaemonを手動起動させるようにしていた（といっても.bashrcに記載していた）のですが、その設定（/etc/docker/daemon.json）が邪魔してうまく動かなくなってしまったようで…
詳しくはDocker公式ドキュメントを参照してみてください。
同様に、systemctlが動作する状態でdaemon.jsonが残ったままDockerの最新化をしようとすると、エラーを吐いてインストールが失敗するのでご注意ください。

最後に

WSLにより、Windowsでの開発環境構築は一昔前と比べて飛躍的に便利になりました！まだ使った事がない方も、ちょっと使ってみたけどsystemctlが使えず不便に感じていた方も、この記事をきっかけにチャレンジしてもらえると嬉しいです！

スタイル・エッジ・グループでは一緒に働く仲間を募集しております。興味をお持ち頂けましたら是非とも下記をクリックしてください↓↓

recruit.styleedge-labo.co.jp

2023-01-31

アジャイルソフトウェア開発ってなんなのだ。

チームビルディング

はじめに

こんにちは、新卒で入社してもうすぐ3年目に突入するみのみのです。

ここ半年ほど、担当プロジェクトの新米PMとして奮闘していました！📚
慣れないながらも試行錯誤し、辿り着いたアジャイルソフトウェア開発について書いてみたいと思います。

世の中のPM業をしている方、だけでなく開発者の方にとっても普段のお仕事の改善に繋がるかもしれません。
最後までお付き合い頂けますと幸いです💌

そもそもアジャイルソフトウェア開発って？

アジャイルソフトウェア開発とは、短期間で実装・リリースを繰り返し、顧客満足度の最大化を図るプロジェクト開発手法です。

そして、アジャイルソフトウェア開発を行う上で重視したいマインドセットとして
「アジャイルソフトウェア開発宣言」があります。

アジャイルソフトウェア開発宣言 　
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
　
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
　
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

出典：アジャイルソフトウェア開発宣言

ちょっとわかりにくい表現かもしれませんが、
左記のことがらよりも、右記のことがらを重要視したほうが、不確実な状況下で価値を生み出しやすいというように読み替えるとわかりやすいかもしれません。

また、アジャイルソフトウェア開発宣言の背後には１２の原則があります。

アジャイル宣言の背後にある原則 　
私たちは以下の原則に従う:
　
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
　
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
　
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
　
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
　
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
　
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
　
動くソフトウェアこそが進捗の最も重要な尺度です。
　
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
　
技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
　
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
　
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
　
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。

出典：アジャイル宣言の背後にある原則

ここから読み取れる重要なマインドはなんでしょうか。
簡単そうに見えて、やってみると難しいようなマインドです。
・要求の変更を歓迎する
・短い期間でリリースを繰り返す
・開発者とシステムに携わる人は密に連携を行なう
・現場で使えるソフトウェアであることが価値である
・技術的な妥協はしない
・問題を解決するための方法をチームで考え、決定し、臨機応変に変える

これらのマインドを紐解くことで見えた、システム開発の性質は下記と考えました。
・すばやく届ける必要がある。
・システムとは完成するまで不確実なものである。
　なので、変化に対応できるように準備しておく必要がある。
・100％顧客のニーズを捉えた完璧なものを届けることは不可能だ。
　なので、届けた時点において顧客にとって最大限の価値を発揮することを目指す。
・エンジニアは技術職であるからこそ、顧客との意思疎通が難しいことがある。
　なので、連携をとりながらプロジェクトを進めていく必要がある。

すばやく届けるためのプロジェクト計画

アジャイルでは、イテレーションと呼ばれる一定期間の開発サイクルを繰り返し、細かくリリースをします。
そこで、次のイテレーション期間でなにをどうやるかの計画が大切です。

限られたリソースのなかで、どう優先順位をつけるのか。
・要望▶ほぼ無限
・時間▶有限
・予算▶有限
・品質▶有限

答えは「要望」を調節することです。
ときとして要望は大きな「カタマリ」として訪れます。
しかし、その要望すべてが本当に必要なのでしょうか？

本当に必要なものを見極める

「要件」とは「必要な条件」を意味します。
しかし、分厚い要件定義書に書かれている１～２割の機能さえあれば、
案外想定していた通りのビジネス上の利益を得られるといわれています。
では残りの８割はなんなのでしょうか？
これらは、「要件」とは呼べません。

タスクの見積もり

さて、タスクの調節をしたところで、さっそく見積もりをしてみましょう。

どのように見積もるのがよいでしょうか？

アジャイルでは前提として「見積もりはあてずっぽうである」と考えます。
初期段階の、不確かな情報しかないなかで、正確な見積もりは不可能なのです。

リリース間近になって（検証がある程度おわって）だんだんと確実になっていくのです。

相対見積もりのすゝめ

アジャイルソフトウェア開発の名著といわれているアジャイルサムライでは下記のQ.が例に挙げられています。

Q.　8枚のクッキーと10枚のクッキーを食べるのにかかる時間はどのくらいでしょうか？
　　1枚のクッキーを食べるのに10秒かかります。

・・・これなら、大体予想がつきますね。
外れたとしても、大幅に外れることはなさそうです。

では、こちらはどうでしょうか？

Q.　風船を６つ膨らませるのにかかる時間は？

Q.　１組のトランプから足りない１枚を探し出せる時間は？

Q.　２つのサイコロを振ってぞろ目を出すのにかかる時間は？

うーん・・なかなかイメージしづらいですね。

このように、人間は相対見積もりならある程度うまくこなせるのです。
「相対サイズで見積もる」というシンプルな原則がアジャイルな見積もりと計画づくりの真髄なのです。

何も基準がないところで、お肉の重さ100gを測るのでは一般人はお肉のプロには勝てませんが
基準のお肉があれば、相対的なお肉の重さを測るとなると、一般人でもプロに劣らない正確さになるそうです。

アジャイルな計画のつくりかた

必要なもの：チームのベロシティ
　　　　　　タスクの相対見積もり

タスクを優先順に並べて、チームで相対見積もりをしてみましょう。
工数ではなく、相対で見積もるのです。
基準となるタスクを１つ掲げて、それにくらべて大きいか、小さいか、どのくらいの規模感のタスクなのかをざっくりと考えてみます。

私たちのチームではポイント（pt）という単位を使って見積もりをしています。
タスクごとにフィボナッチ数列を使って、プランニングポーカー形式で数字を出し合っています。
プランニングポーカーとは、各自の思うタスクの規模を「せーの」で一斉に提示する工数見積もり手法です。

意見が分かれたら話し合いを行い、最終的なポイントを決めます。
このとき、誰も責めたり、否定したりしてはいけません。
ざっくりとした見積もりのなかで、その人が何を考え、何が見えたのか、素直にきくのです。

こうして見積もったタスクたちを優先順ですすめていきます。

毎月続けると、チームが１イテレーション期間で何ポイントぐらい達成できるか、わかってきます。
１イテレーション期間で達成できる範囲のことを「ベロシティ」といいます。

ベロシティの算出と、相対見積もりができるようになれば、プロジェクト計画が上手につくれるようになります。

プロジェクト計画時のポイント

ベロシティ＝プロジェクト計画　とするのは危険です。
想定外のタスクや、定型業務のことも見積もりにいれなければなりません。
そうすると、大体プロジェクト計画時はベロシティの４～５割を達成目標とするのがちょうどいいといわれています。

プロジェクト計画がうまくいくために

現在、プロジェクトは計画通り順調に進んでいるのだろうか？
計画ができたら、進捗を把握する必要があります。

進捗を把握するためには、プロジェクトの状況を可視化する必要があります。
可視化の有名な手法としては「カンバン」がありますね。

カンバンは、トヨタ自動車株式会社の生産管理から発祥した管理方式です。
プロジェクト管理においては、チーム全体で個人のタスクを共有して管理する方法として使用され、
「作業前」「作業中」「作業完了」などといったステータスに各タスクを貼り付けて表示します。

私たちのチームでも、各タスクの状態をチーム全員が常に見える状態にし、チームの進捗状況を日々確認するようにしています。
こうすることで、タスクの進捗を調整したり、早い段階で技術的な相談やリリース日の相談、調整ができるようになります。

おわりに

今回は「アジャイルソフトウェア開発」について特にプロジェクト計画部分を紹介しました。

しかし、これらを実践・導入したからといってそのプロジェクトはアジャイル開発手法である、とは言えません。
アジャイルソフトウェア開発の各イベントを実施しているからアジャイル開発なのか？　テストを先に書けばテスト駆動開発なのか？　そうではないですよね。

アジャイルはあくまでも思想であり、その思想に基づくプラクティスが用意されているだけにすぎません。
世界に同じプロジェクトは２つとないのですから、自分の頭で考え続け、改善を繰り返し続けていくことこそが、アジャイルソフトウェア開発手法のマインドセットだといえます。

参考文献

アジャイルサムライ − 達人開発者への道
著者：Jonathan Rasmusson 著／西村直人・角谷信太郎監訳／近藤修平・角掛拓未訳

SCRUM BOOT CAMP THE BOOK【増補改訂版】スクラムチームではじめるアジャイル開発
著／西村直人 (著)・永瀬美穂 (著)・吉羽龍太郎

弊社の風土として

私は、タスク管理業務をしていくうえで、なにかうまいやり方はないかと思い、アジャイルソフトウェア開発に辿り着きました。
提案し、実際に導入していくことができ、日々試行錯誤しながら、よりよいプロジェクトを目指すという経験ができました。

自ら学び、実際に提案し、学んだことを実践してみたい、そんな若手の背中を押してくれる先輩たちがいます😊