はじめに 　はじめまして、 ラク スでインフラを担当しているftkenjです。 前回は 「DNSエラーってなに？」その原因と解決方法 を書かせていただきましたが、 今回は「自動化」、その中でもインフラエンジニアの視点に立って紹介させていただこうと思います。 はじめに 自動化とは？ インフラで自動化といえば・・・ 主な使用例 自動化ツールの簡単な紹介 おわりに 参考文献 自動化とは？ 　人間による作業を削減できるテク ノロ ジー を使ってタスクを実行すること。 ただし、一口に「自動化」といっても様々なものがあります。 例を並べると以下になります。 IT 自動化 ビジネスの自動化 ビジネスプロセス自動化 ロボティック・プロセス・オートメーション 産業オートメーション 人工知能 機械学習 ディープラーニング 　一番自動化でイメージしやすいのは「産業オートメーション」でしょうか。 工場などで製品の品質安定や人員の安全のためにロボットによる製作が該当します。 元々はこれがオートメーション(自動化)と呼ばれていたようですが、上記にもあるビジネスの自動化が出現したため混同しないよう「産業オートメーション」となったようです。 　自動化をすることによって生産性の向上が期待できるのはもちろんのことですが、同時に信頼性の向上も期待できます。 機械で繰り返し同じ作業を行うため、テスト時点でほぼ問題ないとなっていればほぼ同じクオリティを出すことが可能です。 (ビジネスプロセス自動化、 ロボティック・プロセス・オートメーション 、産業オートメーションが特に恩恵が大きいのではないかと思います。) インフラで自動化といえば・・・ 　やはりサーバの構成管理となります。(上記でいうと「ITの自動化」にあたります) とはいえ、サーバの構成管理といっても範囲が広いため、もう少し細分化すると以下になります。 OSや ミドルウェア の設定ファイルの一元管理 サーバ構成のコード化 冪等性の担保 　これらをツールを使用して管理と実行の自動化を行っていきます。 そうすることで属人化の防止、人為的ミスの削減、サーバの新規構築や設定変更時の作業時間短縮といったことが見込めます。 　今まで物理サーバを サーバラックへマウント から サービスが提供できる状態 までおおよそ1日はかかると思います。 それを自動化すると数時間まで短縮させることも可能になります。 特に複数のサーバを構築するとなった場合は効果は目に見えて変わりますね。 主な使用例 構成管理 ・使用ツール： Git＋Ansible 、 Git＋Terraform 、 CloudFormation 　サーバのMWやその設定ファイルの管理。 管理している側を正としておき、変更を行うときはGit側に行い常に冪等性を担保できる状態にしておきます。 AnsibleのymlファイルやtemplateなどをGitで管理していきます。 メンテナンス/リリース ・使用ツール： Git＋Ansible＋Rundeck 　Rundeckなしでもansible-playbookコマンドでも管理対象サーバに変更を反映させることはできます。 ですが、Rundeckを使用することであらかじめ作成したジョブを実行させることが可能です。 また設定した時刻に自動実行させることもできます。 (つまり夜間作業でずっと起きている必要がなくなる！) 動作確認 ・使用ツール： Git＋ Selenium 　ブラウザ操作の動作確認などを自動化することが可能。 特に同じ動作確認を複数のサーバで実施するときに一括で行うことができ、基本的に起動後は完了するまで待つだけでよくなります。 Gitは、Ansible同様に Selenium の ソースコード を管理します。 自動化ツールの簡単な紹介 インフラの自動化で使用される主なツールをざっくりと紹介します。 Git 　 分散型 バージョン管理システム 。 今となってはメジャーなツールですね。 サーバ上のファイルを直接変更すると、事前にバックアップとしてコピーを取っていなかった場合、差分の確認もできず最悪もとの正常に状態に戻せないこともあります。 またコミットのコメントも残せるので、いつ・だれが・どういう変更を行ったかを追いやすいのもポイントです。 ただし、チーム内でルールを決めておかないと想定外の変更が入っていたり、リリースするブランチを間違えたりするので注意です。 Ansible 　 Agentlessなインフラ自動化ツール 。 手動で行っていた手順をプログラム化してサーバにプッシュすることが可能です。 ansible playbookは人間が読み取れる「 YAML 形式」で記述でき、様々なモジュールや実行したコマンドの結果で処理を分岐するなどある程度複雑なことも可能です。 デフォルトでは ssh で接続を行い、対象サーバにて上記のansible playbookの処理が行われます。 対象サーバもansible上で管理することができ、タグ付けでグループごとに実行するといったことも可能です。 Ansibleイメージ図 Terraform 　 マルチ クラウド 上のコンピュータやネットワークの構築を自動化するツール 。 IaC(Infrastructure as Code)を実現するために、開発されたツールです。 AWS だけでなくAzure、 GCP と特定のプロバイダーに限定されることなくインフラ構成をコード化することが可能となっています。 こちらもAnsibleと同様にコードをGitでバージョン管理することができます。 ただあくまで、インフラ構成までを管理することができます。 それより上のレイヤーについてはAnsibleを使用することになります。 AWS CloudFormation 　 AWS リソースのモデル化およびセットアップに役立つサービス 。 Terraformと異なり AWS でのみ利用可能です。(頭に AWS とついているので当たり前ですが。。。) AWS 特化のためリソース間の依存関係等については、いい感じに吸収してくれているようですが、コード化しきるまでが大変かつサービスの一部なので無料利用枠を超えてしまうと料金が発生してしまいます。 他にどれだけ AWS のサービスを使用しているかによりますが、どっぷり AWS に浸かっているのであればTerraformよりもこちらの方が良いかもしれませんね。 Rundeck 　 Agentlessなジョブ管理ツール 。 Rundeckを実行するサーバから対象サーバへ、 ssh が可能であれば使用することができます。 ジョブネットを作成することが可能であり、もしジョブAの実行に失敗したらジョブBは実行させずに終了させるなどが可能となっています。 また、cronと同じ要領であらかじめ指定した日時にジョブをスケジュール設定させることも可能です。 失敗時に通利することもできるので、定常作業であればジョブを作りこんでおけば夜間であってもコンソール画面に張り付いて作業を行う必要がなくなります。 夜間でなくても作業日時が決まっている場合スケジュール設定していれば、万が一作業のことを忘れてしまっても安心ですね。 Rundeckのイメージ Selenium 　 Web ブラウザの操作を自動化するための フレームワーク 。 対応ブラウザは Chrome 、 Firefox 、 Internet Explorer などがあり、それぞれのドライバーを実装することで各ブラウザに備わっている自動操作ライブラリを使用することができます。 しかし、ブラウザのバージョンは自動更新されますがドライバーはされないためドライバー管理ソフトウェアを使用する、もしくは 環境変数 にてドライバーを使用している場合は、その都度ドライバーを手動インストールしてくる必要があります。 とはいえ、何度も手でページ遷移を行うよりも Selenium で自動化されている方が断然楽になります。 おわりに 　インフラの運用保守ではリリース作業などで深夜作業が多くなりがちです。 ですが、今回紹介した自動化ツールを使用することで、作業担当者が夜中ずっと起きてPCに張り付いている必要がなくなります。 　それだけでなく、手動実行する場合であっても基本的にツールを実行するだけであり、誰が実行しても同じ結果となります。 そのため特定のメンバーしか作業ができない。。。といった属人化の防止にもつながります。 といいことばかり言っていますが、自動化するにはそれなりに労力と時間がかかるので一筋縄ではいきません。。。 　既存環境を構成管理しようとすると、まずはどこまでの範囲を管理する必要があるのか、今までのリリース手順で自動化する場合、失敗したことを検知できるようエラーハンドリングを十分に行う必要があります。 エラーハンドリングが不十分な状態で自動化してしまうと、失敗したまま処理が進んでしまい取返しのつかないことになりかねないです。 そのためにも、しっかりと現状把握と自動化の準備を行ったうえで検証、動作確認、実装に望むことが大切です。 参考文献 自動化について 【初心者向け】Gitとは何なのか。基本用語やその仕組みをまとめています。 Ansible とは 5分で分かるTerraform（Infrastructure as Code） AWS CloudFormation とは ジョブスケジューラ「Rundeck」を試してみる Seleniumを理解する！初心者でも分かる歴史、特徴、基礎知識などを簡単に解説！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

皆様こんにちは。インフラエンジニアのryuhei55225です！ 前回の記事 は【Kibana 入門】という形で「Elastic Stack」(Kibana+Logstash+Elasticsearch)を Linux サーバにインストールして、簡単なデータのグラフ化を紹介させて頂きました。 こちらの記事では、MWのインストール等のサーバ構築がメインとなってしまい、具体的なElasticsearchへのデータ投入やデータ検索・グラフ化に関しては紹介することが出来ておりませんでした。 （データ検索・グラフ化に関しては、完全に省略しておりました。。） ということで・・・ 今回の記事は「Kibana 基礎」という形で、実際前回構築したサーバのElasticsearchにLogstash経由でデータを投入して、Kibanaにてデータをグラフ化をしていく流れについて、具体的に紹介 していこうと思います。 今回の流れとしては、 まず、Logstashの機能について一般的なことを紹介 その後、実際に今回やってみた内容（データのグラフ化）を紹介 していきます。 なんで、Logstashについてある程度理解されている方は、「実際にやってみた」から見て頂ければと思います。 Logstashを用いたデータの収集・加工・転送 Inputプラグイン Filterプラグイン Outputプラグイン 実際にやってみた データの準備 Logstash設定ファイルの作成 設定の反映と確認 今回作成した設定ファイルについて Inputプラグイン Filterプラグイン Outputプラグイン Kibanaを用いたGUIでのElasticsearchデータ確認 KibanaによるElasticsearchデータのグラフ化 グラフの選択 対象のデータを選択 Y軸の設定 X軸の設定 最後に Logstashを用いたデータの収集・加工・転送 Logstashは、さまざまなデータソースからのログやデータを、収集・加工・転送するためのツールです。 前回の記事では、その中の機能の一部として、 CSV ファイルからデータを収集して、Elasticsearchにデータを転送する形を紹介させて頂きましたが、実際にLogstashで出来ることはたくさんありますので、もう少しその要素（ コンポーネント ）について見ていきたいと思います。 Logstashの設定は、大きく「Input」「Filter」「Output」に分けられます。 「Input」でデータを収集して、「Filter」で加工、「Output」で転送という流れです。 それぞれの プラグイン ごとに、様々なものと連携可能ですので、ざっくり プラグイン について紹介していこうと思います。 Input プラグイン Input プラグイン で対応しているデータの取得対象は数多くあります。 全て紹介することは出来ませんので、今回は前回しようした「file」をもう少し詳細に紹介していこうと思います。 その他にも、「Elasticsearch」を指定することで、Elasticsearchのデータを取得するなんてことも出来ます。 以下サイトに対応している プラグイン の記載がありますので、詳しくはやりたいことにあった プラグイン を調べてもらえればと思います。 www.elastic.co Filter プラグイン Filter プラグイン では、実際にデータの整形を実施していきます。 こちらも様々な プラグイン が存在しますが、今回は実際にInput プラグイン で指定した CSV ファイルを整形するにあたって、よく使う プラグイン や便利な プラグイン について紹介していきます。 こちらも、以下サイトに対応している プラグイン の記載がありますので、もっと勉強したい方はこちらも参考にして頂ければと思います。 www.elastic.co Output プラグイン 最後にOutput プラグイン です。 こちらはデータの出力先となり、様々な プラグイン に対応がありますが、「Elastic Stack」を構成している場合は、ほとんどElasticsearchになるかと思います。 今回も実際に CSV ファイルからInputしたデータを、Filterで整形して、ElasticsearchにOutputする形を紹介していきます。 www.elastic.co 実際にやってみた ということで、早速サンプルデータをLogstash経由でElasticsearchに投入して、Kibanaでグラフ化していく流れを紹介していきます。 データの準備 今回用意したデータは、以下のようにtest-serv01~50のサーバのディスク容量を使用量を残容量に分けて一週間に一度計測したデータを CSV ファイルにしています。 こちらのデータをElasticsearchに投入していこうと思います。 # cat /data/server_disk_check.csv 2021/10/01 00:00:00,test-serv01,DBディスク使用量(GB),51.890850067139 2021/10/01 00:00:00,test-serv01,残DBディスク容量(GB),55.363399505615 2021/10/01 00:00:00,test-serv02,DBディスク使用量(GB),38.047119140625 2021/10/01 00:00:00,test-serv02,残DBディスク容量(GB),49.211036682129 2021/10/01 00:00:00,test-serv03,DBディスク使用量(GB),40.542625427246 2021/10/01 00:00:00,test-serv03,残DBディスク容量(GB),46.715530395508 2021/10/01 00:00:00,test-serv04,DBディスク使用量(GB),37.850318908691 ・ ・ ・ 2021/10/01 00:00:00,test-serv49,DBディスク使用量(GB),24.080196380615 2021/10/01 00:00:00,test-serv49,残DBディスク容量(GB),103.170146942139 2021/10/01 00:00:00,test-serv50,DBディスク使用量(GB),3.631404876709 2021/10/01 00:00:00,test-serv50,残DBディスク容量(GB),83.626750946045 2021/10/08 00:00:00,test-serv01,DBディスク使用量(GB),51.983116149902 2021/10/08 00:00:00,test-serv01,残DBディスク容量(GB),55.271133422852 2021/10/08 00:00:00,test-serv02,DBディスク使用量(GB),38.138965606689 2021/10/08 00:00:00,test-serv02,残DBディスク容量(GB),49.119190216064 ・ ・ ・ 2022/05/27 00:00:00,test-serv49,DBディスク使用量(GB),26.486736297607 2022/05/27 00:00:00,test-serv49,残DBディスク容量(GB),100.763607025146 2022/05/27 00:00:00,test-serv50,DBディスク使用量(GB),13.513370513916 2022/05/27 00:00:00,test-serv50,残DBディスク容量(GB),73.745048522949 Logstash設定ファイルの作成 このデータをElasticsearchに投入するための設定ファイルを以下のように記載します。 これで、 CSV ファイルのデータをそのままElasticsearchに投入可能です。 # cat /etc/logstash/conf.d/server_disk_check.conf input { file { path => "/data/server_disk_check.csv" start_position => "beginning" type => "server_disk_check" } } filter { if [type] == "server_disk_check" { csv { columns => [ "date" , "host" , "item" , "number" ] separator => "," } date { match => [ "date" , "YYYY/MM/dd HH:mm:ss" ] } mutate { convert => { "number" => "float" } } } } output { if [type] == "server_disk_check" { elasticsearch { hosts => ["localhost:9200"] index => "%{type}" } } } 設定の反映と確認 上記ファイルを作成したら、Logstashのサービスを再起動して、Elasticsearchにインデックスが作成されていることを確認します。 # systemctl start logstash.service # curl -XGET 'http://localhost:9200/_cat/indices?' yellow open server_disk_check wKGD-LlKSPqZjHJK8UMa_Q 1 1 3500 0 730.9kb 730.9kb curl でElasticsearchの情報をとってきて、「server_disk_check」のインデックスが作成されていることを確認できれば、一旦OKです。 ※ここでElasticsearchにインデックスが作成されていない場合は、「/var/log/logstash/logstash-plain.log」を確認しましょう。 　設定ファイルの書式間違い等であれば、こちらのログに何が間違えているか記載されていることが多いです。 今回作成した設定ファイルについて では、設定ファイル(/etc/logstash/conf.d/server_disk_check.conf)に話を戻して、詳しく設定内容について確認していきます。 Input プラグイン まずInputからですが、今回は CSV ファイルからのデータ取得ですので、file プラグイン を使用します。 「path」 ここで、読み取る CSV ファイルのパスを指定します。 当たり前ですが、ここで設定しないと、Logstashはどのファイルを読み取ればいいのか、判断つきません。 「start_position」 こちらは、Logstash起動時にファイルの行頭から読むのか末尾から読むのかを指定します。 今回のデータに関しては、タイムスタンプ(date)も同時に出力するので、どちらでも問題はないのですが、通常ファイルの最初からデータを作成するので、作成した順にデータの読み取るよう、「beginning」を指定します。 ※デフォルトは、「end」(末尾から読み取り)になっているようです。 「type」 Logstashで取得するデータが今回のものだけであれば、こちらの設定は不要になりますが、明示的に「type」を設定することで他のLogstashの設定と混ざらないようにします。 ここでは、分かりやすいように、ファイル名=インデックス名=「type」=「server_disk_check」とします。 ※もちろん、それぞれの名前を分けることも可能です。 Filter プラグイン 続いてfilterについて確認していきます。 流れ的にはInputした CSV ファイルからデータを取得して意図した形にデータを整形することになりますが、その前にInputで使用した「type」(server_disk_check)の条件分岐をしてあげます。 ※これを忘れると、他のインデックスに影響を与えてしまします。 「 csv 」 columnsにて カラム名 をしていきます。 見たままですが、今回は左から「タイムスタンプ、サーバ名、対象データ、値」となっておりますので、分かりやすいように 命名 していきます。 「date」 Elasticsearch で「timestamp」として使用するカラムの日時フォーマットを指定します。 CSV ファイルに記載したフォーマットをそのまま記載すればOKです。 「mutate」 CSV ファイルから取得したデータは、デフォルトで文字列として認識されて、Elasticsearchに出力されてしまいます。 そのため、数値については、convertを使用してfloat等にデータ型を変更する必要があります。 mutateについては、convert以外にも使用可能ですが、今回は省略させて頂きます。 Output プラグイン 最後にoutputです。ここは特に難しいことはしておらず、見たままかと思います。 今回は、「type」=インデックス名としたので、インデックスの指定を"%{type}"としています。 Kibanaを用いた GUI でのElasticsearchデータ確認 続いて、Elasticsearchに入れたデータを実際にKibanaで確認してグラフ化していきたいと思いますのが、 その前に、Elasticsearchにどのような形でデータが投入されているかKibanaの GUI 上で確認していこうと思います。 まずは、Kibanaに新しく作成したインデックスをElasticsearchに登録します。 メニューから、「Stack Management」→「Index patterns」と選択して、「Create index pattern」からインデックスをElasticsearchに登録していきます。 ※次の画面で出てくる「Time field」に関しては、「date」を選択してあげます。 インデックスの登録が完了しましたら、実際にどのような形でElasticsearchにデータが投入されているか確認していきます。 今回はKibanaのDiscover画面から確認していきます。 続いての画面で、 ①：今回作成したインデックスを選択 ②：対象期間を選択（今回は一年） ③：表示するカラムを選択※デフォルトだと全て表示されるため、見づらくなります を実施していくと、以下のような形で、実際にElasticsearchにデータが投入されていることが確認できます。 この時点でKibanaのFilterを駆使することで、見たいデータだけを選択することも可能ですが、 今回は「Visualize Library」からElasticsearchのデータをグラフ化する流れについて説明していきます。 KibanaによるElasticsearchデータのグラフ化 ようやくElasticsearchにデータが投入されていることが確認できましたので、ここから実際にグラフ化していきたいと思います。 グラフの選択 グラフ化に関しては、「Visualize Library」という部分から実施していきます。 上記、画面で「Create visualization」を選択して、作成するグラフを選択していきます。 今回は、単純にディスク容量の推移を確認するために、折れ線グラフを使用していきたいと思います。 以下のように、選択して最後に対象インデックスに今回作成したものを選択します。 続いて、 GUI 上からグラフの設定をしていくことで、以下のようなグラフを作成していきます。 今回は、サーバ毎のディスク使用量の推移をグラフ化していきます。 （あくまで参考ですので、自身で実施する際はこちらを参考に、色々設定をいじってみてください。） では、続いてグラフ作成の手順を紹介していきます。 対象のデータを選択 今回Elasticsearchには、「DBディスク使用量(GB)」と「残DBディスク容量(GB)」の2種類が存在しますので、 「DBディスク使用量(GB)」のみが対象になるように、フィルターしてあげます。 フィルターは画面左上の「Add filter」から以下のように設定してあげます。 Y軸の設定 画面右に表示されている設定の「data」から「Metrics」の設定をしていきます。 具体的に言うと、Y軸に何の値をとるか、です。 Aggregation 今回は、サーバ毎にデータが一つしかありませんので、設定はなんでも問題ありません。 もし、全サーバのディスク容量の合計を表示したいとかであれば、こちらを「Sum」にする必要があります。 ※その場合は、グラフの分割方法についても修正する必要があります。 Feild 今回は、実際の値（ディスク容量）を表示したいので、Elasticsearch内のカラム「number」を「Field」に選択します。 Custom label グラフのラベル（Y軸）に何を書くかです。 設定しなくてもグラフ化は可能ですが、設定しておくとグラフが見やすくなります。 X軸の設定 続いて、「Buckets」でX軸の設定をしていきます。 今回は、時系列のグラフを作成するので、X軸に日付を選択していきます。 具体的には、「X-axis」を以下のように設定します。 続いて、「Split series」でグラフの分割方法を選択していきます。 今回はサーバ毎に折れ線を分けたいと思いますので、「Sub aggregation」で「Terms」を選択して、 「Field」で分割する単位である「host.keyword」を選択します。 これで、グラフの設定は以上です。 ここまで設定すれば、初めに見せたグラフが表示されるはずです。 最後に 今回はグラフ化ということで紹介はここまでにさせて頂きますが、Kibanaでは様々なグラフが作成できますので、実際に触っていくと、「こんなこともできるのか」といった発見があるかと思います！！ サーバ毎の推移をグラフ化しましたが、その他にもディスク使用容量の全体の合計値の推移や、単位時間当たりのディスク使用容量の最大値の取得等、データさえ入っていれば、だいたいのことは出来ると覆います。 一般的な監視ツール（ Nagios 、Zabbix、etc...）でも簡単なグラフの作成は可能ですが、Kibanaに比べると対応しているグラフは少ないかと思います。 そんな時は一度Kibanaにデータを移行してあげれば、作成したグラフが簡単に取得できる、なんてこともあるかと思います。 ということで、今回の紹介は以上にさせて頂きたいと思います。 次回も書くことがあれば、「応用編」としてElasticsearchやLogstashの便利な使い方について紹介していこうと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは、弊社サービスのインフラを運用している id:keijiu (ijikeman)です。 今回は、 「Ansible実行を1/3に高速化した話」 を記載します。 目次 目次 背景 1. 実行時間の把握 1-1. Callbackプラグイン[profile_tasks]を有効にする 1-2. CallBack Plugin有効化の確認 2. Ansibleコードチューニング 2-1. 各タスク実行時間の確認 2-2. パッケージインストール処理の見直し 2-2-1. コードの確認 2-2-2. コードの修正 2-3. 動的書き換えの見直し 2-3-1. コードの確認 2-3-2. コードの修正 3. Ansible実行環境チューニング 3-1. 並列実行数の変更 3-2. Pipelining Pipeliningの有効化 Pipelining有効化の確認 3-3. サードパーティ製 Strategy Plugin (Mitogen for Ansible) Mitogen利用時に気付いた点 Mitogenの利用方法 3-4. 上記実行環境毎の実行速度の計測比較結果 実行速度検証総括 4. 高速化の結果 背景 3年ほど前よりAnsible構成管理を推進を開始し、ようやく ラク スの各商材のAnsible化の割合が大幅に増えました。 構成管理対象サーバの増加と構成管理範囲が増えるに伴い、Ansibleの実行完了までの時間が大幅に増えていきました。 また、インフラメンバー各自がAnsibleコードを記載し、テスト実行(--check)等をする回数も増えこの「実行時間の長時間化」が問題となりました。 この問題の改善にあたり、調査・検証し、実際に実行時間を大幅に削減した内容を公開させていただきます。 1. 実行時間の把握 まずはAnsibleの全体の実行時間や各タスク毎の実行時間の把握を行い、時間がかかっている処理がどの処理なのかを把握することが重要です。 各タスクの中で時間がかかりすぎているものを把握することで、処理や環境の見直しによって改善できるものがないかを確認します。 1-1. Callback プラグイン [profile_tasks]を有効にする 各タスクの実行に掛かった実行時間を表示するために、callback プラグイン profile_tasksを有効化します。 $ /etc/ansible/ansible.cfg --- [defaults] callback_whitelist = profile_tasks --- もしくは 実行時にANSIBLE_CALLBACK_WHITELIST='profile_tasks'を設定 ANSIBLE_CALLBACK_WHITELIST='profile_tasks' ansible-playbook ... 1-2. CallBack Plugin有効化の確認 下記の様に各タスクの実行時間が表示され、実行完了後には時間がかかったタスクのTOP20までがリスト表示される様になります。 ... RUNNING HANDLER [os : Install Epel.repo] ***************************************** Sunday 05 June 2022 19:33:32 -0400 (0:00:01.327) 0:00:01.356 ********** skipping: [192.168.0.1] PLAY RECAP ********************************************************************* 192.168.0.1 : ok=34 changed=1 unreachable=0 failed=0 skipped=3 rescued=0 ignored=0 Thursday 05 May 2022 21:09:47 -0400 (0:00:00.058) 0:00:14.804 ********** =============================================================================== os : Install Epel.repo ------------------------------------------ 1.66s os : Install python module for SELinux -------------------------- 1.12s Gathering Facts ------------------------------------------------- 1.07s 2. Ansibleコードチューニング 2-1. 各タスク実行時間の確認 では、実行時間の把握ができるようになったところで、実際のPlaybookを実行しました。 未セットアップの CentOS に対するPlaybookの実行結果は以下のようになりました。(一部伏字) 圧倒的にパッケージのインストール時間が大半でしたので、まずはパッケージインストール処理のコードを確認してみます。 すると 約６割がパッケージインストール処理 でした。 Tuesday 07 June 2022 01:14:14 -0400 (0:00:03.472) 0:05:20.110 ********** common : Install Packages --------------------------------------------- 190.71s common : Copy Scripts ------------------------------------------------- 14.21s os : Server Reboot ------------------------------------------------------- 11.57s os : Server Reboot ------------------------------------------------------- 9.78s os : Install python module ----------------------------------------------- 8.90s os : Install NetworkManager -------------------------------------------- 6.51s ... 2-2. パッケージインストール処理の見直し 2-2-1. コードの確認 実コードは記載できませんが、サンプルコードで説明すると以下の様な処理になっていました。 - set_fact: INSTALL_PACKAGES: - NAME: 'httpd' REPO: 'appstream' - NAME: 'httpd-devel' REPO: 'appstream' - NAME: 'httpd-tools' REPO: 'appstream' - NAME: 'httpd-manual' REPO: 'appstream' - name: Install Packages yum: name: "{{ item.NAME }}" state: 'installed' enablerepo: '{{ item.REPO }}' with_items: "{{ INSTALL_PACKAGES }}" 実際にこのコードを実行すると以下のようになります。 パッケージを１つずつインストールしている為、パッケージ対象が増えれば増えるほど毎回 yum moduleが呼び出され時間がかかる実装になっています。 --- 実行ログ TASK [test : Install Packages] ************************************************ Friday 06 May 2022 01:34:02 -0400 (0:00:00.024) 0:00:07.367 ************ changed: [192.168.0.1] => (item={'NAME': 'httpd', 'REPO': 'appstream'}) changed: [192.168.0.1] => (item={'NAME': 'httpd-devel', 'REPO': 'appstream'}) changed: [192.168.0.1] => (item={'NAME': 'httpd-tools', 'REPO': 'appstream'}) changed: [192.168.0.1] => (item={'NAME': 'httpd-manual', 'REPO': 'appstream'}) ... 2-2-2. コードの修正 以下ansible公式 ansible.builtin.yum module – Manages packages with the yum package manager — Ansible Documentation の yum moduleのサンプルコードにもあるようにパッケージ名は配列にて渡すことができます。 - name: Install a list of packages with a list variable yum: name: "{{ packages }}" vars: packages: - httpd - httpd-tools 以下様に書き換えを行う 「パッケージ名をリスト形式に変更する」 ことで、 yum モジュールの実行回数を大幅に削減することができます。 実際にこのサンプルコードでも実行時間を約半分にすることができました。 - set_fact: INSTALL_PACKAGES: - NAME: - 'httpd' - 'httpd-devel' - 'httpd-tools' - 'httpd-manual' REPO: 'appstream' --- 実行ログ TASK [test : Install Packages] ************************************************ Friday 06 May 2022 01:36:19 -0400 (0:00:00.023) 0:00:03.246 ************ changed: [192.168.0.1] => (item={'NAME': ['httpd', 'httpd-devel', 'httpd-tools', 'httpd-manual'], 'REPO': 'appstream'}) 2-3. 動的書き換えの見直し ラク スで使っているansibleコードテンプレートでは、汎用的な処理を別のタスクファイルにして、 「include_role」や「include_tasks」で動的に読み込み書き換えることで、コードの再利用性を高める取り組みを行っております。 その為、繰り返し処理を行うと毎回コードの動的書き換えと実行が行われる為、処理時間が伸びていきます。 2-3-1. コードの確認 以下のように汎用的な処理を別のロールに集めており $ roles/libraries/tasks/copy.yml --- - name: FILE COPY copy: src: "{{ item.SRC }}" dest: "{{ item.DEST }}" owner: "{{ item.OWNER }}" group: "{{ item.GROUP }}" mode: "{{ item.MODE }}" 呼び出し元からinclude_role等で呼び出して利用しています。 $ roles/test/tasks/main.yml --- - name: Copy files include_role: name: libraries tasks_from: copy.yml with_items: - { SRC: 'test1', DEST: '/tmp/test1', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test2', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test3', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test4', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test5', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test6', OWNER: 'root', GROUP: 'root', MODE: '0644' } 実行すると、毎回copy.ymlが呼ばれる毎に処理が行われる為、毎回TASKが呼ばれます。 TASK [Copy files] ******************** Monday 06 June 2022 02:00:31 -0400 (0:00:01.356) 0:00:01.386 TASK [libraries : FILE COPY] ********* Monday 06 June 2022 02:00:31 -0400 (0:00:00.087) 0:00:01.474 changed: [192.168.0.1] TASK [libraries : FILE COPY] ********** Monday 06 June 2022 02:00:33 -0400 (0:00:01.099) 0:00:02.573 changed: [192.168.0.1] TASK [libraries : FILE COPY] ********** Monday 06 June 2022 02:00:33 -0400 (0:00:00.910) 0:00:03.484 changed: [192.168.0.1] TASK [libraries : FILE COPY] ********** Monday 06 June 2022 02:00:34 -0400 (0:00:00.869) 0:00:04.354 changed: [192.168.0.1] TASK [libraries : FILE COPY] *********** Monday 06 June 2022 02:00:35 -0400 (0:00:00.889) 0:00:05.243 changed: [192.168.0.1] TASK [libraries : FILE COPY] ********* Monday 06 June 2022 02:00:36 -0400 (0:00:00.854) 0:00:06.098 changed: [192.168.0.1] PLAY RECAP ********************************************* 192.168.0.1 : ok=7 changed=6 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Monday 06 June 2022 02:00:37 -0400 (0:00:00.830) 0:00:06.928 *********** =================================================== Gathering Facts --------------- 1.36s libraries : FILE COPY ---------- 1.10s libraries : FILE COPY ---------- 0.91s libraries : FILE COPY ---------- 0.89s libraries : FILE COPY ---------- 0.87s libraries : FILE COPY ---------- 0.85s libraries : FILE COPY ---------- 0.83s Copy files --------------------- 0.09s 2-3-2. コードの修正 動的書き換え(include_*)を使わずに静的処理に変更します。 $ roles/test/tasks/main.yml --- - name: Copy files copy: src: "{{ item.SRC }}" dest: "{{ item.DEST }}" owner: "{{ item.OWNER }}" group: "{{ item.GROUP }}" mode: "{{ item.MODE }}" with_items: - { SRC: 'test1', DEST: '/tmp/test1', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test2', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test3', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test4', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test5', OWNER: 'root', GROUP: 'root', MODE: '0644' } - { SRC: 'test1', DEST: '/tmp/test6', OWNER: 'root', GROUP: 'root', MODE: '0644' } Ansibleを実行するとわずかですが、実行時間が短くなりました。 書き換えを行う回数が増えるほど効果は高くなりますが、変更による効果はそれほど高くない為、「コードの再利用性」とどちらがよいかはで使い分ける必要がありそうです。 TASK [test : Copy files] *********************************** Monday 06 June 2022 02:01:26 -0400 (0:00:01.413) 0:00:01.437 *********** changed: [192.168.0.1] => (item={'SRC': 'test1', 'DEST': '/tmp/test1', 'OWNER': 'root', 'GROUP': 'root', 'MODE': '0644'}) changed: [192.168.0.1] => (item={'SRC': 'test1', 'DEST': '/tmp/test2', 'OWNER': 'root', 'GROUP': 'root', 'MODE': '0644'}) changed: [192.168.0.1] => (item={'SRC': 'test1', 'DEST': '/tmp/test3', 'OWNER': 'root', 'GROUP': 'root', 'MODE': '0644'}) changed: [192.168.0.1] => (item={'SRC': 'test1', 'DEST': '/tmp/test4', 'OWNER': 'root', 'GROUP': 'root', 'MODE': '0644'}) changed: [192.168.0.1] => (item={'SRC': 'test1', 'DEST': '/tmp/test5', 'OWNER': 'root', 'GROUP': 'root', 'MODE': '0644'}) changed: [192.168.0.1] => (item={'SRC': 'test1', 'DEST': '/tmp/test6', 'OWNER': 'root', 'GROUP': 'root', 'MODE': '0644'}) PLAY RECAP ********************************************************************* 192.168.0.1 : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Monday 06 June 2022 02:01:31 -0400 (0:00:05.252) 0:00:06.689 *********** =================================================== test : Copy files --------------------5.25s Gathering Facts -------------------1.41s 3. Ansible実行環境チューニング 3-1. 並列実行数の変更 Ansibleの標準設定では並列で実行するターゲット数が"5"と設定されている為、多くのターゲットに対して実行する場合に時間がかかります。 その為、並列実行数の変更を行います。 FORKS設定はAnsibleの子プロセスを増やす設定の為、増やせば増やすほどCPUへの負荷がかかります。 各CPUの使用率を確認し、不足しているようであればCPU数を増やすことを検討してください。 $ /etc/ansible/ansible.cfg --- [defaults] forks = 5 もしくは 実行時にANSIBLE_FORKS=NUMを設定 ANSIBLE_FORKS=20 ansible-playbook ... 3-2. Pipelining ansibleのデフォルト設定の場合、各タスクを実行する度に以下の例の様にターゲット側の"~{ansible実行ユーザのホーム ディレクト リ}/.ansible/"に python プログラムの展開を行いAnsibleを実行しています。 その為、ターゲットへのデータ転送時間とこれらのファイルの書き込み等により、各タスクの実行に時間がかかります。 /home/ansible_user/.ansible/ansible-tmp-1651804170.1883245-2652826-75480101479031/ 合計 120 drwx------. 2 root root 31 5月 5 22:28 . drwx------. 3 root root 68 5月 5 22:28 .. -rw-------. 1 root root 119155 5月 5 22:28 AnsiballZ_stat.py Pipeliningの有効化 Pipeliningを有効化することで、 ssh のpipeを経由してansibleを実行することで高速化を行うことができます。 $ /etc/ansible/ansible.cfg --- [ssh_connection] pipelining = True ※設定を記載するセクションは[defaults]ではなく[ ssh _connection]であることに注意してください もしくは 実行時にANSIBLE_PIPELINING=True か ANSIBLE_PIPELINING=1を設定 ANSIBLE_PIPELINING=1 ansible-playbook ... 公式ドキュメント Ansible Configuration Settings — Ansible Documentation にもある通り、 requrettyが設定されているユーザでansibleを実行する場合は、sudo設定にて無効にする必要がある為注意が必要です。 Pipelining有効化の確認 Ansible実行時にPipeliningが有効になっているかは、-vvvオプションを付けることで確認することができます。 以下の例の様に "Pipelining is enabled" と出力されていることを確認してください。 ... Pipelining is enabled. <192.168.0.1> ESTABLISH SSH CONNECTION FOR USER: ansible_user ... 3-3. サードパーティ 製 Strategy Plugin (Mitogen for Ansible) Mitogen — Mitogen Documentation Other Toolsとして公式で紹介されているMitogen for Ansibleを使うことで、上記Pipeliningよりも実行速度の高速化を行うことができます。 Mitogenは 実行コードのRAMへのキャッシュ pipelineと同様ターゲットへの書き込み削減 従来のPreforkモデルに加えて、Thread化によるさらなる並列化・高速化 ネットワークコネクションの再利用等 によりAnsibleの実行を高速化することができます。 Mitogen利用時に気付いた点 Mitogen利用時に以下の事象が確認できましたので、利用するには事前に検証が必要です。 現行v0.2.9ではターゲットサーバ側に"/usr/bin/ python "が必要(/usr/bin/python3ではダメ) ansible 2.10以降には未対応 (2022/06/13時点でAnsible v2.10以上に対応するv0.3.xは未リリース 2022/06/13追記) ターゲットの python 環境によっては動かないコードがある include_roleは未対応 CPU使用率がPipeliningよりかなり高い メモリの使用率が高い Pipeliningとの併用はできない どなたかv2.10以降でmitogen for Ansibleが動くよというコメントをいただきましたが、公式ニュースに記載されているように v0.2.xは2.10未満 v0.3.x系は2.10以上 をサポートという風にバージョンが分かれるようです(2022/06/13追記) Release Notes — Mitogen Documentation Mitogenの利用方法 ■Ansible実行環境にMitogenを設置 $ curl -kL -o https://networkgenomics.com/try/mitogen-0.2.9.tar.gz $ tar zxvf mitogen-0.2.9.tar.gz -C /opt/ ■Strategy プラグイン としてmitogenを設定 $ ansible.cfg --- [defaults] strategy_plugins = /opt/mitogen-0.2.9/ansible_mitogen/plugins/strategy ■各playbook毎にstrategyを設定してmitogenを有効化します。(ansible.cfgで全体に適用してもよい) $ playbook.yml --- - name: Test Playbook strategy: mitogen_linear hosts: test-servers ... あるPlaybookの実行時間の差を確認したところ、以下様にかなりの差がありました。 Default状態 ... 0:00:22.399 Pipelining ... 0:00:17.744 Mitogen for Ansible ... 0:00:09.333 3-4. 上記実行環境毎の実行速度の計測比較結果 検証としてターゲットサーバ20台に対し、 ディレクト リ10個作成する処理を行いました。 それぞれの環境毎に5回実行し、一番早い時間と一番遅い時間を除く3回の平均時間を記しています。 [検証結果] AnsibleサーバCPU数 FORK数 CPU使用率 平均実行時間 コメント [Default] 1 5 20 - 40% 01:39 1 10 20 - 70% 01:05 1 20 30 - 100% 00:42 CPUが100%となる場合があり処理待ちが発生 2 5 10 - 20% 01:36 1 vCPUでもCPUに余裕があった為、CPU追加効果なし 2 10 20 - 40% 01:01 1 vCPUでもCPUに余裕があった為、CPU追加効果なし 2 20 15 - 80% 00:36 CPU 100%が解消され処理時間が短縮 [Pipelining] 1 5 30 - 40% 00:40 Pipeliningの効果が高いが若干CPU使用率が上昇 1 10 30 - 70% 00:28 Pipeliningの効果が高いが若干CPU使用率が上昇 1 20 30 - 100% 00:21 Pipeliningの効果が高いが若干CPU使用率が上昇 2 5 15 - 30% 00:38 1 vCPUでもCPUに余裕があった為、CPU追加効果なし 2 10 20 - 40% 00:26 1 vCPUでもCPUに余裕があった為、CPU追加効果なし 2 20 30 - 50% 00:17 CPU 100%が解消され処理時間が短縮 [Mitoge] 1 5 100% 00:18 Pipeliningよりさらに効果が高いがCPU使用率がかなり上昇 1 10 100% 00:16 Pipeliningよりさらに効果が高いがCPU使用率がかなり上昇 1 20 100% 00:16 Pipeliningよりさらに効果が高いがCPU使用率がかなり上昇 2 5 25 - 50% 00:19 CPUに余裕がでたが、CPU追加効果なし 2 10 40 - 60% 00:16 CPUに余裕がでたが、CPU追加効果なし 2 20 30 - 70% 00:14 SWAPが発生 2+2GBメモリ 20 50% 00:14 メモリを追加することでSWAPが解消 実行速度検証総括 Pipelining Ansible標準機能として実装されている為、手軽に利用が可能で効果が高い為、標準で利用できるようにしておくとよい。 Ansible実行側のCPU使用率の上昇が若干見られるが、実行環境の大幅な見直しは必要ない。 並列実行数(ANSIBL_FORKS) 並列実行数を上げて実行する場合はAnsible実行側のCPU使用率を確認して引き上げる必要がある。 Mitogen for Ansible CPUの使用率が高い為、CPUの割り当て数に注意が必要。 並列実行数を増やすAnsible実行サーバのメモリ使用量が上がる為、メモリの割り当てに注意が必要。 初期導入作業が必要だが、Pipelineよりも効果が高い。 4. 高速化の結果 最終的に Mitogen Plugin及び上記コードの改修等を進め 以下の様に 1/3に高速化することができました！！ ■改修前 Tuesday 07 June 2022 01:14:14 -0400 (0:00:03.472) 0:05:20.110 ********** ■改修後 Tuesday 07 June 2022 01:04:01 -0400 (0:00:02.327) 0:01:34.366 ********** 終わり エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに はじめまして。knng1です。 本記事では、AnsibleのRoleの使用方法についてまとめていきたいと思います。 Ansibleを実務で使用する場合、基本的にはRole化されているところが多いと思いますので、 これからAnsibleを触る方 最近Ansibleの勉強を始めた方 の参考になれば幸いです。 はじめに １．Ansible とは ２．Ansible 使用例 ディレクトリ sample.yml 実行ログ ３．Roleについて ディレクトリ sample-role.yml roles/yum/tasks/main.yml roles/template/tasks/main.yml roles/template/handlers/main.yml 実行ログ ４．その他の機能について defaults （roles/<Role名>/defaults/main.yml） サンプル vars （roles/<Role名>/vars/main.yml） files （roles/<Role名>/files/main.yml） meta （roles/<Role名>/meta/main.yml） ５．Ansible Role おまけ ansible-galaxy init １．Ansible とは Ansibleは RedHat 社が開発する OSS の構成管理ツールです。 あらかじめ記述したPlaybookファイル通りにソフトウェアのインストールや設定を自動で行うことができます。 管理対象機器には SSH プロトコル を使用するため、エージェントレスでの導入が可能です。 新規に構築するシステムはもちろん、すでに数十台、数百台を管理しているようなシステムでも容易に導入ができます。 詳細はAnsibleを説明している 公式ドキュメント をご参照ください。 ２．Ansible 使用例 今回は apache のインストール、confファイルの配布、サービスの再起動を行う簡単なPlaybookを作成しました。 ※Playbookの詳細については こちら ディレクト リ ├── ansible.cfg ├── sample.yml ├── templates │ └── httpd.conf.j2 └── test-hosts sample.yml [root@AnsibleServer ansible]# cat sample.yml --- - hosts: test-server gather_facts: false tasks: - name: install apache yum: name: httpd state: installed - name: setup apache template: src: httpd.conf.j2 dest: /etc/httpd/conf/httpd.conf - name: restart apache service: name: httpd state: restarted enabled: yes 実行ログ Playbookを実行すると下記のようなログが出力されます。 changedが表示されていれば、taskの実行によってターゲットのサーバに変更が加えられたことを示しています。 [root@AnsibleServer ansible]# ansible-playbook -i test-hosts sample.yml PLAY [test-server] ************************************************************************************************************************************************************************************************** TASK [install apache] *********************************************************************************************************************************************************************************************** changed: [test-server] TASK [setup apache] ************************************************************************************************************************************************************************************************* changed: [test-server] TASK [restart apache] *********************************************************************************************************************************************************************************************** changed: [test-server] PLAY RECAP ********************************************************************************************************************************************************************************************************** test-server : ok=3 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ３．Roleについて AnsibleのRoleは処理毎にグループ化して分割する機能です。 roles アトリビュート で対象のグループ(Role)を呼び出すと「roles/<Role名>/tasks/main.yml」が読み込まれます。 ※「main.yml」以外の名前ではincludeやimportをしないと読み込んでもらえないのでご注意ください。 また、rolesを使用している場合、handlersを使用することができます。 handlersは「roles/<role名>/tasks/main.yml」内の対象のタスクがchangedステータスで終了した場合に実行される処理です。 ここで実行したい処理は「roles/<role名>/handlers/main.yml」に記述し、tasks配下のmain.ymlで「notify: <タスク名>」を記述して呼び出します。 コンフィグファイルの配布等、サーバに変更が加わった場合のみサービスを再起動したい場合にとても有用な機能です。 サンプルPlaybookをrole化して分割すると、以下のような感じになります。 ディレクト リ ├── roles │ ├── template │ │ ├── handlers │ │ │ └── main.yml │ │ ├── tasks │ │ │ └── main.yml │ │ └── templates │ │ └── httpd.conf.j2 │ └── yum │ └── tasks │ └── main.yml ├── sample-role.yml └── test-hosts sample-role.yml - hosts: test-server gather_facts: false roles: - yum - template roles/ yum /tasks/main.yml --- - name: install apache yum: name: httpd state: installed roles/template/tasks/main.yml --- - name: setup apache template: src: httpd.conf.j2 dest: /etc/httpd/conf/httpd.conf notify: restart apache roles/template/handlers/main.yml --- - name: restart apache service: name: httpd state: restarted enabled: yes 実行ログ [root@AnsibleServer ansible]# ansible-playbook -i test-hosts sample-role.yml PLAY [test-server] ************************************************************************************************************************************************************************************************** TASK [yum : install apache] ***************************************************************************************************************************************************************************************** changed: [test-server] TASK [template : setup apache] ************************************************************************************************************************************************************************************** changed: [test-server] RUNNING HANDLER [template : restart apache] ************************************************************************************************************************************************************************* changed: [test-server] PLAY RECAP ********************************************************************************************************************************************************************************************************** test-server : ok=3 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ４．その他の機能について AnsibleのRoleには前述した「tasks」、「handlers」、「templates」以外にもいろいろな機能があります。 便利に使用できるものが多いので、簡単に説明させていただきます。 defaults （roles/<Role名>/defaults/main.yml） 対象のAnsibleのRoleは、デフォルト変数を定義する機能です。 その他の変数ファイルで定義された場合、ここで定義された変数は上書きされます。 記述方法はその他変数ファイルと同様です。 サンプル --- ansible_user: root package: - { state: installed , name: httpd } - { state: installed , name: tomcat } vars （roles/<Role名>/vars/main.yml） その名の通り、変数を定義する機能です。 ここで定義する変数は最後に読み込まれるため、「defaults」はもちろん「group_vars」や「host_vars」の変数も上書きます。 デフォルト変数はともかく、変数ファイルが複数個所にまたがって配置されると管理が煩雑になるため、 個人的には特別な理由がない限りは「group_vars」や「host_vars」を使用した方が管理しやすいと思います。 files （roles/<Role名>/files/main.yml） Copyモジュールを使用する際にファイルを格納する ディレクト リです。 ここに格納されたファイルはファイル名のみで呼び出し可能です。 meta （roles/<Role名>/meta/main.yml） Ansibleの各Roleの依存関係を定義するファイルです。 「 yum 」のmeta/main.ymlで「template」を指定した場合、下記のように「template」⇒「 yum 」の順に実行されてしまいますので注意が必要です。 [root@AnsibleServer ansible]# ansible-playbook -i test-hosts sample-role.yml PLAY [test-server] ************************************************************************************************************************************************************************************************** TASK [template : setup apache] ************************************************************************************************************************************************************************************** changed: [test-server] TASK [yum : install apache] ***************************************************************************************************************************************************************************************** changed: [test-server] RUNNING HANDLER [template : restart apache] ************************************************************************************************************************************************************************* changed: [test-server] PLAY RECAP ********************************************************************************************************************************************************************************************************** test-server : ok=3 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ５．Ansible Role おまけ ansible-galaxy init AnsibleのRoleの各 ディレクト リは「ansible-galaxy init <Role名>」で簡単に生成できます。 新規でAnsibleのRoleを作成する際に利用してみてください。 [root@AnsibleServer ansible]# ansible-galaxy init roles/test - Role roles/test was created successfully [root@AnsibleServer ansible]# [root@AnsibleServer ansible]# ll roles/test total 4 drwxr-xr-x 1 root root 512 May 29 11:42 defaults drwxr-xr-x 1 root root 512 May 29 11:42 files drwxr-xr-x 1 root root 512 May 29 11:42 handlers drwxr-xr-x 1 root root 512 May 29 11:42 meta -rw-r--r-- 1 root root 1328 May 29 11:42 README.md drwxr-xr-x 1 root root 512 May 29 11:42 tasks drwxr-xr-x 1 root root 512 May 29 11:42 templates drwxr-xr-x 1 root root 512 May 29 11:42 tests drwxr-xr-x 1 root root 512 May 29 11:42 vars エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに JUnitとSpockについて ライフサイクルの定義 テストクラス データドリブンテスト まとめ はじめに こんにちは、ryrkssです。 今回は、今のプロジェクトのテスト フレームワーク に JUnit と Spock が使われているので、 簡単なテストコードでどう書き方が違うのか比較してみようと思います。 また、それぞれ各テストで出てくる アノテーション や検証メソッドについての説明は割愛します。 本記事で使う JUnit は JUnit5 です。 以後 JUnit が多発しますが全て JUnit5 として捉えていただければ幸いです。 JUnit とSpockについて みなさんご存知の方は多いと思いますが「知らないよ」という方に向けてちょっとだけまとめます。 JUnit Java のテスト フレームワーク といえば真っ先に思い浮かぶ有名なテスト フレームワーク です。 Java エンジニアであれば全ての人が通る道ではないでしょうか。 Spock Groovy で動作する Java のテスト フレームワーク です。 Java とは違う言語で書くので「違う言語覚えないといけないのか」と思う人もいるかもしれませんが、 Java とほぼ同じ感覚でコーディングできます。 何よりデータドリブンテストが JUnit と比べて非常に書きやすく可読性も高いです。 あとは、MockAPIが標準で入っていることも嬉しい人には嬉しいと思います。 ※私は使い慣れている Mokito を使っちゃってますが。 JUnit と Spock は共存できるので、是非どちらも試してみてください。 それでは、 JUnit と Spock のテストコードの書き方を比べてみます。 ライフサイクルの定義 良く使いますが JUnit は アノテーション 、 Spock はメソッド名で定義します。 JUnit アノテーション で実行タイミングを表現します。 // 各テストメソッドが実行される前に都度実行 @BeforeEach void init() {} // 各テストメソッドが実行された後に都度実行 @AfterEach void cleanup() {} // テストクラスが実行される前に1度だけ実行 @BeforeAll static void initAll() {} // テストクラスが実行された後に1度だけ実行 @AfterAll static void cleanupAll() {} Spock メソッド名で実行タイミングを表現します。 // 各テストメソッドが実行される前に都度実行 def setup() {} // 各テストメソッドが実行された後に都度実行 def cleanup() {} // テストクラスが実行される前に1度だけ実行 def setupSpec() {} // テストクラスが実行された後に1度だけ実行 def cleanupSpec() {} Spock のメソッド名だけで判別してくれるのは、コードがスッキリして良いですよね。 JUnit はお馴染みの アノテーション 定義です。 見慣れすぎて何も思わないです。 テストクラス JUnit @Test @DisplayName( "文字列結合" ) void combineStringsTest() { var expected = "テスト" ; var actual = sut.combineStrings( "テ" , "ス" , "ト" ); assertEquals(expected, actual); } Spock def "文字列結合" () { setup : def expected = "テスト" when : def actual = sut.combineStrings( "テ" , "ス" , "ト" ) then : actual == expected } 単純なテストを書きましたが、結構違いますね。 JUnit と Spock で目に付く違いは、ブロックの定義です。 JUnit はコードを記述しているだけですが、 Spock には setup: や when: など 記載しているもの以外にもそれぞれのフェーズに応じたブロックがあります。 単なる分かりやすくするためだけのものではないので、ちゃんと状況に応じた使い分けをしましょう。 また、こう見ると JUnit は アノテーション @Test を毎回つけなければならないのが冗長に感じます。 検証メソッドについても JUnit はメソッドを使用する必要がありますが、 Spock は等価 演算子 を使うだけで事足ります。 こちらは比較的万能で配列やリスト、数値なども等価 演算子 で検証できます。 データドリブンテスト こちらもよく使います。 同じようなテストを1つ1つメソッドで分けるのは、テストケースが見えにくく可読性が落ちてしまいますよね。 JUnit は ParameterizedTest で検索すると出てくると思いますが、 渡している値と想定結果の関係性が分かりにくく、同時に書きにくいと感じてしまいました。 その反面 Spock は非常に書きやすく、見やすいので実装している時にパターンを洗い出しやすいです。 またレビュー時もテストケースを考えずとも頭に入ってくる感覚で個人的には中毒になるレベルです。 百聞は一見に如かずということで、早速比較してみたいと思います。 JUnit 例として、3種類の書き方を記載します。 まだパラメータが少ない且つ、型を同一にしているので幾分見え方がましですが、 ②、③についてはパラメータ数が多くなる、色々な型が混じるとなると 本当に何のテストをしているのか分からなくなってきますね…。 /* ① 単一パラメータのみを定義する書き方 引数で定義した型に暗黙的に変換される(サポートされている型は要確認) */ @ParameterizedTest @ValueSource(strings = { " テスト " , " テスト" , "テスト " }) void trimTest1(String target) { var expected = "テスト" ; var actual = sut.trim(target); assertEquals(expected, actual); } /* ② csv形式でパラメータを定義できる書き方 デリミタを変更したり外部ファイルを指定することもできる 例は文字列だけだが他の型も定義できて、引数で定義したそれぞれの型に暗黙的に変換される */ @ParameterizedTest @CsvSource ({ " テスト , テスト" , " テスト, テスト" , "テスト , テスト" , }) void trimTest2(String target, String expected) { var actual = sut.trim(target); assertEquals(expected, actual); } /* ③ 別メソッドにパラメータを定義できる書き方 メソッドで引数を定義するので独自の型をパラメータで与えることができたり、 ただのメソッドなので最終的に返り値の形にしてあげれば何でもできるイメージ */ @ParameterizedTest @MethodSource( "trimArguments" ) void trimTest3(String target, String expected) { var actual = sut.trim(target); assertEquals(expected, actual); } static Stream<Arguments> trimArguments() { return Stream.of( Arguments.of( " テスト " , "テスト" ), Arguments.of( " テスト" , "テスト" ), Arguments.of( "テスト " , "テスト" ), Arguments.of( null , "" ) ) } Spock 例として2種類ありますが、どちらもメソッドに @Unroll をつけて、 where: にパラメータを定義していくだけとなります。 また、文字列だけを扱うテストになってますが、勿論他の型が混じっても問題ありません。 簡単なものしか記載していませんが、 where は色々な使い方ができるようなので興味のある方は調べてみてください。 /* ①データテーブルを使用した書き方 1行目がテスト内の変数にマッピングされ、2行目以降がその変数に入れるデータパターン || をつけることで検証用のデータと想定結果を視覚的に分かりやすくできる */ @Unroll( "文字列前後空白除去 #title" ) def "trimTest1" () { when : def actual = sut.trim(target) then : actual == expected where : title | target || expected "前後空白" | " テスト " || "テスト" "前空白" | " テスト" || "テスト" "後空白" | "テスト " || "テスト" "null" | null || "" } /* ②データパイプを使用した書き方 左シフト演算子で変数とデータ部を接続 */ @Unroll( "文字列前後空白除去 #title" ) def "trimTest2" () { when : def actual = sut.trim(target) then : actual == expected where : [title, target, expected] << [ [ "前後空白" , " テスト " , "テスト" ], [ "前空白" , " テスト" , "テスト" ], [ "後空白" , "テスト " , "テスト" ], [ "null" , null , "" ] ] } まとめ いかがでしたでしょうか？ 簡単な例しか出せておらずイメージがつきにくいかもしれませんが、 テストの可読性・書きやすさだけでいうと JUnit よりも Spock の方が印象として良いのかなと私は感じました。 現在のチームでも新しく作るテストクラスは大体 Spock で作ってたりしてます。 ただし、 JUnit にしかできないこともあります。 例えば、 JUnit のネスト( @Nested )を使ってテストをまとめることが Spock ではできません。 テストも色々な書き方があって奥が深いですね〜 テストの実装はベストプ ラク ティスをあまり深く考えてこなかったのですが、 しっかりと可読性や何が最良なコーディングかを考えていかなくてはいけないな、と感じております。 全体を通してかなり Spock よりの記事になってしまいましたが、 結論 JUnit も Spock もどちらも使いやすいです。 最後に...冒頭でも書かせていただきましたが JUnit と Spock は共存できるので 是非実際にそれぞれでテストを書いてみてください！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに Gather.Townとは？ 導入しようと思ったきっかけ オフィスの作り方 どう使ったか まとめ・感想 はじめに こんにちは。新卒3年目hy094です。 最近はスパイのアニメにハマっています。ファミリーのやつです。 今回は Gather.Town を導入したらリモートワーク中の開発速度が向上した話をしたいと思います。 Zoomが2人の通話でも制限時間が40分になってしまい、代替ツールを探している方もいるかと思いますので、少しでも判断材料になれば嬉しいです。 Gather.Townとは？ 一言で言うと "Pokemon x Zoom thing" ( Notion – The all-in-one workspace for your notes, tasks, wikis, and databases. ) です。 ポケモン とZoomを掛け合わせたかのようなツールで、ゲーム好きの人には親しみやすくかつZoomに近い使い心地で利用できます。(使い方によってはZoomを上回る利便性すら秘めていると思います。） 表題では「リモートオフィス」と表現しましたが、これは私たちの使い方がリモートオフィスに近かったためです。Gather.Townはオフィスに限らず様々な用途に活用できます。 一例として、社内サークルでの活用事例です。 Gather.Townで社内サークル活動の一部をオンライン化しました - Qiita 導入しようと思ったきっかけ 弊社は基本オフィスワークで、緊急事態宣言やまんえん防止等重点措置などが発令されている場合のみ完全リモートワークになる運用でした。 （ここしばらくは落ち着いており出社していますが、現在もおそらく同様です） 皆さんもご存知の通り、発令したり解除したりが繰り返されていたため、私たちも出社とリモートを繰り返していました。 そこで出社した際にリモートの仕事がどうだったか新卒入社の後輩に聞いたところ、 「気軽に相談しにくい」 といった声がありました。 出社時は隣にちょっと声をかけるだけのところを、チャットで連絡→返信待つ→ZoomURLを共有→入室待つ→相談といった流れで、実装で少し詰まったところを聞くだけで15分〜30分かかるといった状態です。 そこで丁度上記の社内サークルでの導入事例を見て、同じ空間にいれば声をかけやすいのでは？と導入してみることにしてみたのです。 オフィスの作り方 導入方法については再掲になりますが、弊社の昨年の アドベントカレンダー に記載があるのでそちらを参照してください。 Gather.Townで社内サークル活動の一部をオンライン化しました - Qiita ここでは、オフィスの作成方法だけお伝えします。 基本は上記の記事の通りで大丈夫なんですが、「Explore social experiences」でそのままテンプレートが選べなくなっていたので、テンプレートまでの道のりも示しておきます。 一番左の「Set up an office or team social」を選択 左の「Remote Office」を選択 オフィスを改造したり増築する予定がない方はこのまま「Confirm Selection」を押してください。 ※「Confirm Selection」で作成されるspaceに床や壁を追加しようとすると、デフォルトでついている背景など全て消え去ってしまうためです。（一度space作り直しました） ※まだ壁と床の追加はベータ版のようなので、いずれ編集できるようになるかもしれません 壁や床を編集しようとすると以下のような警告が出て・・・ Yesを押すと真っ白になってしまいます！ 「Confirm Selection」がある画面の左下に「See other space」というボタンがあるので、それを選択するとテンプレート選択画面に飛べます。 あとは先程の記事の通り作成していただければ問題なく部屋の改築が可能です。 どう使ったか オフィスとしてGather.Townの特性を最大限活かすための使い方はズバリ 「常時ログインし座っておくこと」 です。 他の作業をやっている時も裏で起動しておき、キャ ラク ターを机の前(椅子の上)に置いておきます。 見た目で「出社してる感」があるのはもちろん、通知機能(ログイン中でGather.Townが非アクティブな人に通知を送ることができる)などを使うことで、オフィスでは普通にやっている「すみません、今お時間いいですか？」をリモートで実現することができました。 実際の作業中の風景↓ （ちなみに、後ろ向いてますが青いのが僕です。 ポケモン のアクア団をイメージしました。） また、逆にチャットで悩んでる雰囲気の人を見つけ、教える側の人が突撃することも容易になりました。 相談がしやすくなったことで一人で悩む時間が格段に減り、結果的に開発がスムーズに進むようになりました。 ただ、一つ大きな問題があり・・・ Gather.Townはそこそこ重く、それを常時起動とするとそれなりにメモリを喰ってしまうことです。 導入の際はマシンスペックやコミュニケーションへの課題感と相談していただければと思います。 まとめ・感想 まず、導入して本当によかったです。 オフィスワークと遜色ないレベルでコミュニケーションが取りやすくなり、開発もスムーズに進むので導入前に比べて楽しく開発できました。 また、Gather.Townの導入は当時2年目の私が提案し、導入に至っています。 若手も色々と提案でき、それをやってみることができる環境は個人的にはとても嬉しいです。 Gather.Townには他にもたくさんメリット／デメリットがありましたが、そちらは別途「 ラクス フロントエンドチーム｜note 」の方にまとめました！ 是非ご確認ください。 note.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは、技術広報の yayawowo です。 システム開発 で重要な『開発とテスト』について、 エンジニアの体験談やTipsを覗いてみませんか？ 延べ450名以上の参加申込をいただいた、 『開発×テスト LT会』全2開催分の資料をまとめて紹介します！ イベント詳細はこちらをご確認ください！ ・ 開発×テスト LT会 ・ 開発×テスト LT会 - vol.2 開発×テスト Tips 11選 絶対にテストコードを書かないチームのテストルール 意外とカンタン!?テストコードの改善から始めるシステム開発の効率化 テスト嫌いなプログラマがテストを語る ISTQB/JSTQBシラバスから学ぶAgileTesting 単体テストゼロからテスト文化を醸成させた話 少しずつ手厚くして不具合や仕様漏れを防ぐために CircleCIでtiming dataに基づいたテスト分割をDartで利用できるようにした話 ソフトウェアエンジニアが品質保証を学んでわかったこと 個人開発でテストを書いてみて良かったこと＆伸びしろ UTアンチパターン インシデントゼロを支える技術 最後に 開発×テスト Tips 11選 絶対にテストコードを書かないチームのテストルール 発表者： ヒグ！ さん speakerdeck.com ◆ 発表内容 ・テストコードのいいところ 　→テストを自動化して効率化 　→ 単体テスト を入れることでコードの品質を評価 　→修正して再テストが容易 ・手動テスト/自動テストのメリット/デメリット ・自動テストデータの扱いやすさ、手動テストの柔軟性 　→双方の長所を活かして生産性向上に繋げていきたい 意外とカンタン!?テストコードの改善から始める システム開発 の効率化 発表者： 面川泰明 さん speakerdeck.com ◆ 発表内容 ・テストやっててつらいことはありませんか？ 　→考慮漏れしたテストケースで不具合を発見できない 　→テスト用のドキュメントをいちいち作成/更新するのが面倒 ・今回取り組んだ内容 　① テストコードは適切にケース分けする 　② あえてDRYをやめ、べた書きする ・続けて良かったこと 　エンジニア：テストケースの考慮漏れに気づきやすくなった 　テスター ：テスト用のドキュメントを作成/更新する手間が削減された テスト嫌いな プログラマ がテストを語る 発表者： 白柳隆司 さん speakerdeck.com ◆ 発表内容 ・テストが「嫌い」な プログラマ は多いはず 　→おおっぴらに「嫌い」とも言えない空気感 ・「嫌い」だから遠ざけていいわけではない ・「嫌い」の理由を見つめる 　→そこから出てくる視点を活用する ISTQB/ JSTQB シラバス から学ぶAgileTesting 発表者： Daiki Tanoguchi さん speakerdeck.com ◆ 発表内容 ・品質はチームのもの ・リスク評価は「相対見積もり」でできる ・探索的テストはセッションベースドかつテストチャーターを用いて行おう ・要求エンジニアリングの技法を使ってテストを考えよう 単体テスト ゼロからテスト文化を醸成させた話 発表者： south さん speakerdeck.com ◆ 発表内容 ・やったこと 　→ライブラリ導入（Jest/Testing Library） 　→ドキュメント（ライブラリの主要な API /テスト観点/サンプルコード） 　→モック関数を用意 　→読書&発表 　→ ペアプロ ・モブプロ ・ライブラリを導入して終わりではなくテストが書きやすい環境を整備 ・テストは慣れるしかない！が段階的に慣れていくための支援をしよう 少しずつ手厚くして不具合や仕様漏れを防ぐために 発表者： fumiyasac さん 少しずつ手厚くして不具合や仕様漏れを防ぐために from Fumiya Sakai www.slideshare.net ◆ 発表内容 ・少しずつUnitTestを手厚くして複雑になっても仕様を読み取れる様にする 　①　仕様を良い意味で疑いながら必要な観点を洗い出す 　②　UnitTestがあると以前の仕様の確認もできる 　③　言葉だけでは紛らわしい部分にはテストを手厚く書く様にする CircleCIでtiming dataに基づいたテスト分割を Dart で利用できるようにした話 発表者： operandoOS さん speakerdeck.com ◆ 発表内容 ・ Dart testsでCircleCIのtiming dataを利用して良い感じにテスト分割/並行実行したい…！ 　① Dart testの結果を Junit XML で出力する 　② 出力した Junit XML をテスト メタデータ としてCircleCIに認識させる 　③ テスト実行のコマンドを書き換える ・"No timing found for <ファイル>"というエラーが出た場合 　原因：timing dataのfile keyの値がnull 　対応 　・ dart -junitreportの内部で利用している dart -testreportライブラリの修正 　・ dart -junitreportで Junit XML 出力する際、testcase elementにfile attributeの追加 　・file attributeに記載されたfile pathをCI上で sed コマンドを利用して書き換え ソフトウェアエンジニアが品質保証を学んでわかったこと 発表者： hisaichi5518 さん speakerdeck.com ◆ 発表内容 ・品質を定義するのが重要 ・プロダクト品質を保証するには、品質を作りこむことが大事 ・品質を作り込むには、チーム全員が 開発プロセス をすべてフェーズでテストをする＝Holistic testing ・テストとは、 開発プロセス のフェーズで出来た成果物に対してチーム全員が想定したものか確認すること 個人開発でテストを書いてみて良かったこと＆伸びしろ 発表者： あきお さん akio-blogger.blogspot.com ◆ 発表内容 ・なんで個人開発でテストを書こうと思ったのか？ 　→個人開発では0からテストを書くことができる 　→個人開発だから自由に技術選定ができる 　→若干仕様が複雑な部分がある ・良かったこと 　→テストが開発記録代わりになる 　→最初以外はテストのメンテコストを感じない 　→少し時間はかかるけどチャレンジングなことができる UT アンチパターン 発表者： ryo07 さん UTアンチパターン from ryoheiseki1 www.slideshare.net ◆ 発表内容 ・ アンチパターン 　① 「そもそもテストが存在しない！」 　② 「テスト名が雑！」 　③ 「mock, verify に any を使うな！」 　④ 「テストの中に実装コードを混ぜるな！」 　⑤ 「なにもアサートしていない」 　⑥ 「Null チェックが甘い」 インシデントゼロを支える技術 発表者： Yuji Yamaguchi さん speakerdeck.com ◆ 発表内容 ・フロントエンドテストのつらみ 　→ 単体テスト は問題ないのに手戻りや結合バグが多くなりがち ・testing-libraryの導入で良かったこと/難しかったこと ・testing-libraryを使うと、実態に近い状態でテストをすることができる ・全体仕様を把握するための材料として、テストケースを作成するのもオススメ ・ 単体テスト よりもコストがかかるので、やりすぎないように注意が必要 最後に 『開発×テスト LT会』のまとめはいかがでしたでしょうか？ 参考になる システム開発 /テストのTIpsが1つでもありましたら、幸いです。 また、『開発×テスト LT会 vol.3』が7/20(水)19:00～、開催を予定しております！ rakus.connpass.com 登壇/視聴ともに募集をしておりますので、是非お気軽にご参加ください！ 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

4/16に ラク スに入社しました、技術広報の飯野です。 入社して1ヶ月と少し経ちましたので入社エントリを書いてみることにしました。 本投稿は社外の方はもちろんですが社内メンバーにも自己紹介の絶好の機会ですので、社内外を問わず読み物としてお楽しみいただければと思います。 「技術広報って何をしているの？」「なぜエンジニアから技術広報に？」という方から「 ラク スってどんな会社か知りたい！」という方にまで幅広く読んでいただければ幸いです。 目次 経歴 転職のきっかけ 入社の決め手 ラクスの技術広報とは 入社後やっていること 社内の雰囲気 入社後の課題感 まとめ 経歴 大学 文学部日本文学科を卒業しており、生粋の文系です。 入社1社目の常駐先で「好きな古文は 源氏物語 です」と言ったところ、大層変わった子扱いをされていました。（そんなに変わった人間ではないです。） 1社目 前述の中小 SIer に新卒で入社し、SES（客先常駐）の形態で約4年働いていました。 Web広告代理店、宝くじ、 クラウド サービス、ネット証券等の現場でエンジニア経験を積ませていただきました。 SESあるあるかと思いますが（6年前の情報なので今とは違うかもしれません）、 常駐先によって待遇がかなり変わること 完全な ウォーターフォール だと一部工程にしか携われず自分が何を作っているのかすらよく分からない現場もあったこと 会社同士の契約のため来月自分がどこに居ることになるかすら分からなかったこと 等々、働き方について疑問を抱くようになり転職を決めました。 ただし、いろいろな現場に行って様々な業種のプロダクトを社外のエンジニアと毎回違う言語や フレームワーク で開発していたことは、間違いなくわたしのエンジニアスキルの土台になっています。 2社目 Web広告代理店で約6年働いていました。 自社のエンジニアと自社システムを作りたかった（エンジニアが99%内製でした）のと、入社時から新規プロダクトの開発に従事できるということで入社を決めました。 上述の、新規プロダクトであるクライアントが使用する広告発注システムの構築や、営業の売上と粗利をデイリーで管理するデータ分析基盤の実装、計上ツールの保守等、様々なプロダクトに携わりました。 また、この会社で アジャイル について学び、 スクラム 開発を実践していました。 エンジニア リングマ ネージャー（一般用語で言うところの課長レイヤーにあたるかと思います）兼開発チームのエンジニアを約5年、＋ スクラム マスターというやりたがりが溢れ出たロールを担当していました。 2020年2月からはフルリモートで働いていました。 上記の通り、 ラク スが3社目で転職経験は2回です。 転職のきっかけ 前職はとても居心地のよい会社で、働きやすく、かつ人もよく、とても恵まれた環境であったと言えます。 「やりたい」と声を上げれば大抵のことはやらせてもらえましたし、価値が見出せないものやあまりにも短納期な要望は「やりたくない」と正直に言っていました。 （※ここは個人の性格によるところが大いにあります、全員が全員そう言っていたわけではないです。） 若い時からどんどんチャレンジさせてもらえて、新卒入社2年目で課長職になっている社員もいました。 実成果云々ではなく「やりたい」と言った社員へ挑戦機会を多く与える、といった風土です。（もちろん素質があればこそです。） そんな恵まれた環境に身を置いていたわけですが、だんだんと自分の市場価値について考えるようになりました。 立場上裁量も大きく、言い方がよくないかもしれませんが大体のことは言えばなんとかなっていた感覚があり、周りのメンバーからも「飯野が言うなら」といった空気を感じていました。 また、入社してからずっと同じプロダクト/チームに携わっていたため、他の環境に行った際にどのくらい太刀打ちできるものなのかが全く分からず、変化を求めている状態が続いていました。 とは言え「絶対に転職したい」という強い願望はなく、とりあえず手っ取り早く市場価値を知りたかったので、 ヘッドハンティング 型の転職サイトに登録しました。 ありがたいことにスカウトはそれなりにいただいていたのですが、同じようなポジションで同じような働き方なのであれば無理に会社を離れる必要はないと思っており、求人情報を見るだけの日々を過ごしていました。 そして転職サイト登録後半年を経過した頃、「技術広報」というポジションで ラク スからスカウトをいただきました。 入社の決め手 そもそもスカウトを貰うまで「技術広報」というポジションをよく知らなかったわたし。 カジュアル面談で開発部の組織体制や技術広報の業務内容について話を聞き、 これまで培ってきたエンジニアリングを土台に新しい分野で活躍できること 横断組織のため関わりを持つ社員がとても多いこと 対外的な組織 ブランディング に携われること に心惹かれて選考に進みました。 もともとコミュニケーションを取りながらチームで成果を上げることが好きだったので、より多くの人と関わり、プロダクトやチームを横断して組織のために働ける環境が魅力でした。 また、エンジニアから完全に離れることには不安もあったので、オファー面談の際に「もし技術広報が合わなければエンジニアでも」と言ってもらえたのも大きかったです。 ということで、転職活動は完全受け身で ラク ス1社のみエントリーし、ご縁がありまして入社に至りました。 内定をいただいてからも採用課の方も含め何度も話を聞いていただき（週1の頻度で電話 or Web面談で連絡を取り、オファー面談の際にも「現場のエンジニアと話したい」というわがままも聞いてもらいました）会社の制度面についてや、どういった人がいるのか、どういった人がカルチャーマッチしているか、という話を根掘り葉掘り教えていただきました。 納得いくまで悩む時間とサポートをくださったことで、安心して入社を決めることができました。 転職活動をほとんど行っていないので他社と比較しづらいですが、かなり手厚い方なのではないかと思います。 ラク スの技術広報とは 前述の通りですが、 ラク スの技術広報は 開発組織の ブランディング 、認知拡大 を行うことで、最終的には開発組織の 採用強化 を図ることを目的としています。 具体的な業務内容としては、 ラク ステックブログの運営 社外向け技術イベントの企画・運営 外部イベントの発掘・情報収集 上記取り組みによる集計作業・分析 の4点が挙げられます。 もちろん技術広報だけで全てを賄うことはできないので、現場のエンジニア/デザイナー、マネージャーの皆さまの力をお借りして活動を行っています。 より具体的な活動内容は こちらの投稿 をぜひご覧ください。 tech-blog.rakus.co.jp 入社後やっていること 出勤 2年ぶりのオフィス出勤なので、まずは通勤に慣れるところから始めましたw （※ ラク スは対面でのコミュニケーションを重視しており、緊急事態宣言等の要請がない限りは基本的にオフィス出勤となります。） 始めは電車に乗るのも緊張していたのですが、転職したてのわたしにとって対面コミュニケーションは関係構築をするにあたりかなり有効に働いていると思います。 もちろんリモートでも関係構築は可能です。 が、やはりリモートに比べてコミュニケーション量（雑談含む）が全く違います。 困ったときの「ちょっといいですか？」も2秒でできます、すごい。 「あの席にいるあの人にXXについて聞きたい」も歩いて行って5秒でできます、すごい。 業務外だけど誰かに話したいくだらないこともすぐに言えます、すごい。 リモートでは必須と思われる「場作りをしてから雑談をする」という必要性がなくなり、気軽にコミュニケーションが取れるようになりました。 副次的な効果としては、圧倒的に運動量が増えなんと体重も減りました。歩くの大事。 イベント企画・運営 わたしは4月中旬入社のため、入社時点で今期の計画はほぼ出来上がっている状態でした。 が、社外向け技術イベントを追加するにあたり、わたしも入社1週目からさっそく企画に携わることとなりました。 6月〜8月にかけて行われるLT会のうち、6本のイベント企画をさせていただいております。 「初めはお試しと思ってとりあえずやってみよう」というご厚意によりたくさん採択していただいて、嬉しいやら緊張やらです。 直近ですと6月中旬に「 アジャイルについてゆるく語りたい！ 」（LT会）を開催予定です。 アジャイル 開発での取り組みやプロダクトの開発手法について聞いてみたい！という方はぜひご視聴ください！ rakus.connpass.com 集計作業の自動化 技術広報はブログやイベント等の数値を扱っており、改善サイクルを回すために集計作業が必須です。 集計作業を行うにあたり、これまでは手作業でやっていた定型業務を少しずつ自動化しています。 「集計が速くなった！楽になって嬉しい！」と言ってもらえるとにんまりします。（これまでのエンジニア経験も活かせていますね！） チームビルディング 入社後は毎日1on1の時間を30分取っていただいていて、雑談や現状困っていること等をチームのリーダーと話しています。 入社3日目の1on1で「メンバーも増えましたし（自分のことですが）チームビルディングのワークがやりたいです」と言ったところ「どうぞどうぞ」と快諾していただいたのでさっそくやってみました。 技術広報チームではチームビルディングの経験があるメンバーは少なかったので、まずはチームビルディングの目的と効果について認識合わせを行いました。 チームビルディングを行うことで、 コミュニケーションの円滑化 心理的 安全性が高くなる チームに一体感が生まれる＝生産性が向上 といった効果を期待できる、という話をしました。 ドラッカー 風エクササイズ 技術広報チームの初ワークには前職でも行っていた ドラッカー 風エクササイズを採用しました。 「 ドラッカー 風エクササイズ」とは、 アジャイルサムライ の著者であるJonathan Rasmusson氏が書籍やブログで紹介しているチームビルディングの手法 4つの質問にチーム全員が答えることで、相互理解の促進と期待値のすりあわせという効果があり、特にプロジェクトの開始時や新メンバーを迎えるときに効果的 と言われているワークです。 主にソフトウェア開発をしているチームで取り組むことが多い（と思われる）ので、開発外のチームで行ったのは初めてでした。 ドラッカー 風エクササイズでは参加メンバーの得意なことや大切にしている価値観を知ることができるので、自己開示を目的としているワークの場合に有効な選択肢だと思います。 実際にやってみて、参加メンバーからの感想も貰いました。 期待値の擦り合わせは良かった。 期待値の得点づけで4-5が多いあたり、対人の気遣いができるメンバー達なのだなと思った反面、 心理的 安全性はまだ低いのかなとも考えた。 一緒に仕事をする上で、チームの得意・不得意、価値観などが詳細にきけて良かったです。 今後仕事をする上で、期待値の相互理解ができたことはとても良いと思いました。 関わっている期間が長い人/短い人とで、期待値の変化が起こると思うので、期が変わる頃にもやってみたいなーと思いました。 改めてコミュニケーション、自己客観視の機会が持ててよかったと思う。 チームの現状やメンバーの得意なことが大きく伝わってきて理解が深まった。 自分へのコメントがいただけることで、自分の位置や目指していく方向わかりやすくなったと思う。 今後いい意味で変化できたらと思いました！ プロダクト開発のチーム以外で行ったのは初めてでしたが、ポジティブなFBが多く貰えました。 「 心理的 安全性はまだ低いのかな」という意見もあり、メンバーが増員したばかりということももちろんあるでしょうし、まだお互いに気は遣っている状態ということがこういったワークを通して明るみになった点もよかったと思います。 社内の雰囲気 情報共有の文化 チャット上での交流がとても活発に行われていて、社外の技術イベントのレポートやおすすめの記事、ネットニュース、美味しいランチ情報が流れてくるチャンネルもあります。 （※ ラク スの開発部門では「Mattermost」をチャットツールとして採用しています。） こういった情報発信ってリアクションがないと切ないですよね。 わたしも技術広報活動の一環で社内報を流す機会が多いのですが、絵文字で反応をいただけるととてもありがたいです！ また、有志での集まりも盛んな印象です。 技術広報主導ではない社外向けイベントがあったり、読書会が開かれたりと、主体性を持つ社員によってチームを横断した活動が行われています。 わたしも読書会に参加予定なので楽しみです！ フラットで柔軟な社員が多い 技術広報では社外向け技術イベントの企画・運営をしていますが、その一環で社内のエンジニアやデザイナーに登壇依頼をする機会があります。 わたしも入社してから何名かの方に「登壇いかがですか？」と声を掛けさせていただきましたが、「お誘いありがとうございます！」「発表内容考えておきます！」とさくっと快諾いただけることが多く感動しました。 社内でこういったアウトプットの文化を作るのはすごく難しいと思います。 前職でも「ブログ書いてよ」と言うのも言われるのもなんだかハードルが高いなと感じていました。（実際にはそんなことはないのですが。） ラク スでは年間のブログ計画を技術広報と開発部内で連携して作成しています。 この計画ブログだけでも大変にありがたいのですが「LT会に向けてブログを執筆したのでアップしてほしい」「連載物を書きたい」等の飛び込み執筆者がいらっしゃいます。 強制ではなくこういった形でブログを書いてくださる方が増えると、日頃のインプットを気軽にアウトプットする流れが根付きそうですね。 技術広報としてもそういった社員のアウトプットの場をどんどん増やしていければと思っています。 入社後の課題感 人力の作業を自動化したい 集計作業や管理業務にはまだまだ手作業が多い状況です。 なんでもかんでも自動化すればいいってものでもないですが、完全にルーチン化していて人がやる必要のない作業はなるべく人力を減らして、より企画や分析等のクリエイティブな箇所に注力していきたいですね。 技術広報として会社のことをもっと知りたい まだ入社して日が浅いこともありますが、会社に関するインプットの日々が続いています。 プロダクトも社員も多く、それぞれのプロダクト毎の技術スタックや開発手法、日々の取り組み等まだまだ分からないことだらけです。 が、技術広報は横断組織のため関わる社員は本当に多いです！ 前職までは業務で関わりのあるエンジニアやデザイナーはかなり限られていたので、横断組織ならではの特色だと思います。 日々少しずつですが、関わりを通してプロダクトや組織毎の特色を学び、組織 ブランディング に活かせるような企画に繋げていきたいです。 ラク ス社員の皆さま、今後ともよろしくお願いいたします！ まとめ 以上、エンジニアから技術広報に ジョブチェンジ した話でした。 入社して一ヶ月と少しですが、すでにいろいろな機会をいただけているなと改めてふりかえることができました。 まだまだ技術広報としては ひよっこ ですが、組織の認知拡大目指して邁進します！ 最後までお読みいただき、ありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

技術広報の yayawowo です。 いつも ラク スのエンジニアブログをお読みいただき、ありがとうございます！ 今回は2022年度最初の ラク スMeetup、 『 技術刷新の課題取り組み - 共通基盤/k8s/技術ロードマップ - 』 の発表内容について紹介させていただきます！ テーマは『先行技術検証の事例』です。 当社の技術課題解決に向け、新技術の導入検証に取り組む専門組織のマネージャー/メンバーたちが登壇させていただきました！ なお、本イベントは以下のような方にオススメとなっております。 ◆ こんな方にオススメ！ ・時代の変化/ビジネス要求に合わせて システム開発 したい ・5年10年続いたサービスをさらにこれから10年維持したい方 ・ ラク スの技術ロードマップ運用が気になる ・現実的な技術検証の取り組みを知りたい ・技術検証組織に興味がある ・ SaaS 開発に携わるエンジニアの話が聞きたい ・当社で働くことに興味がある 発表の紹介 横断部門としての取り組み紹介（研究開発、共通基盤開発） Kubernetes導入に備えたGitOpsなCI/CDを構築する サービスを陳腐化させない組織だった技術刷新 　ラクスのエンジニアと話をしてみたい方へ 終わりに 発表の紹介 それではここから各発表内容と資料を共有させていただきます！ イベントの詳細は以下をご確認ください。 rakus.connpass.com 横断部門としての取り組み紹介（研究開発、共通基盤開発） 登壇：堀内 泰秀 [所属：技術推進課 マネージャー] speakerdeck.com まずは、技術推進課マネージャーの堀内からの組織についてご紹介させていただきました！ 術推進課は技術的な横断部門として活動しており、各サービス開発部門が手をつけられない領域にチャレンジする組織となっています。 例えば サービス開発のチームでは取り組めないテク ノロ ジー の研究開発 各サービスを横断する機能の開発 開発部門だけでなくビジネス部門への技術情報提供 など様々です。 本発表では、以下ポイントについてお話しさせていただきました。 技術推進課の取り組み 研究開発成果の一例のご紹介 研究開発を組織化して行う意義 組織が抱える課題　 Kubernetes 導入に備えたGitOpsなCI/CDを構築する 登壇：岡本 拓也 [所属：技術推進課] speakerdeck.com 続いて、岡本より検証事例をご紹介しました！ ラク スのサービスのほとんどはオンプレミスで構築し運用していますが、コンテナ技術を生かした開発の需要の高まりやECSで運用しているサービスのオンプレミスへの移行に備え、 Kubernetes での運用を視野に入れています。 そのため、 Kubernetes 導入に備え従来のCI/CDをIaCの特徴を活かしたものに変化させる必要があります。 今回はGitOpsを採用して ラク スの技術スタックに沿った Kubernetes ネイティブなCI/CDを考案、構築したお話をさせていただきました。 ◆ 関連ブログ tech-blog.rakus.co.jp サービスを陳腐化させない組織だった技術刷新 登壇：鈴木 勇 [所属：技術推進課 speakerdeck.com 最後は、鈴木の発表です。 数年どころか、数ヶ月も持たずに消えていくシステムがある一方、上手く軌道に乗ると10年以上運用されるものもあります。 ラク スでは長く続いているサービスを複数抱えていますが、長く続くサービスの悩みといえば「技術的負債」と「仕組みの陳腐化」です。 今回は仕組みの陳腐化に対してどのような取り組みを行っているのかをご紹介しました。 長く続くサービスにありがちな「システム面では陳腐化しているが、ビジネス面では問題となっていない」というよくあるシチュエーションに対してどのようなアプローチを行っているのかという話をさせていただきました。 ちなみに予想通りか、期待外れか、 銀の弾丸 になるような話ではなく地道な努力となります。 ◆ 関連ブログ tech-blog.rakus.co.jp 　 ラク スのエンジニアと話をしてみたい方へ 今回登壇した技術推進課では、東京/大阪開発拠点にて 『プロダクト共通基盤開発チーム（立ち上げメンバー）』 を積極的に募集しております！ ラク スのプロダクトを複数契約されているお客様に、複数契約ならでの付加価値を提供するため開発チームです。 立ち上げ組織のため、ご経験に応じて下記ポジションをお任せしたいと考えております。 エンジニア リングマ ネージャー PdM（プロダクトマネージャー） 開発エンジニア ◆ 東京開発拠点 career-recruit.rakus.co.jp ◆ 大阪開発拠点 career-recruit.rakus.co.jp career-recruit.rakus.co.jp 「まだ応募する段階では…」 という方は、是非 カジュアル面談 もご検討ください！ 【こんな方におすすめ】 ポジションが経験にマッチするか確認したい 働き方/環境・体制/事業・プロダクト/文化/制度を詳しく知りたい 応募前に選考の概要を聞きたい（人物像、基準など） エンジニア・デザイナーの人となりを知りたい 以下申込フォームとなります。 rakus.hubspotpagebuilder.com 「イベントで登壇していた●●さんとお話をしたい・・・」 などご要望がありましたらその旨をご記入の上、お申込みください！ お気軽にどうぞ 😊 終わりに 『技術刷新の課題取り組み - 共通基盤/ k8s /技術ロードマップ -』はいかがでしたでしょうか？ 今回初めて、技術課題解決に向けて新技術の導入検証に取り組む専門組織をご紹介させていただきました！ 実際、検証からサービスへの反映までは3～4年ほどの期間がかかります。 そんな技術ロードマップを検討、技術検証をしてくれる当社の技術推進課は当社にとって重要なポジションとなっております。 また、採用を強化しているサービス共通基盤開発も大変大きな役割を担っていきます。 そんな重要組織の一員として一緒に働いてくれる方を大大募集中でございます！ 今回ご紹介した3名の発表を通じ、大規模 SaaS の開発に携わっている方や、同様の課題と向き合っている方の一助となれば幸いです。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに こんにちは。mst_78710と申します。 今回は、初見では発音の仕方が分からない" kubernetes "について書いてみようと思います。 今となってはご存じの方も多いと思いますが、発音は「クバネティス」や「クーベネティス」でいいようです。 また「 k8s 」とも表現され、「k + 8 文字(ubernete) + s」から取ったとのことで、なかなかユニークな表現ですね。 さて、その kubernetes ですが、内容が膨大でブログの一記事では到底収まりきらないです。 なので、今回は kubernetes の概要と特徴の一部(主にPod)について、一例を交えながら説明できればと思います。 この記事のターゲットとしては、以下のような方が対象になります。 ・ kubernetes って聞いたことはあるけど詳しくは知らない ・ちょっと調べてみたけど複雑でイメージがわかない 少しでも kubernetes についての理解の補助になれば幸いです。 それではいきましょう。 目次 はじめに 目次 これまでとどう違うのか kubernetesとは 宣言的な構成管理と自動化を促進 コンテナ化されたワークロードやサービスを管理する ポータブルで拡張性のある Kubernetesの特徴 具体例 まとめ 参考情報 これまでとどう違うのか まず、これまでとどう違うかをざっくりと理解するため、 一般的なサーバと kubernetes をすごく簡略化した図にしてみました。 一般的なサーバの方は説明するまでもないかと思います。 kubernetes 側で"master"と"node"という言葉がありますが、仮想サーバを表しています。( AWS 環境であれば、EC2になります。) masterでは、 kubernetes を動かすために必要な機能が稼働します。 詳細な機能を書いてしまうと長くなってしまうので、公式にお任せします。 Kubernetesのコンポーネント | Kubernetes 一方のnodeでは、アプリケーションが"Pod"という枠で稼働します。 こちらは後ほど説明します。 簡単なまとめとして、 kubernetes ではmaster上で稼働する管理機能を利用して、node上でアプリを稼働させることになりそうですね。 kubernetes とは 公式でさらっと書かれているこの一言を掘り下げて、 kubernetes の概要を説明していこうと思います。 Kubernetes は、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のある オープンソース のプラットフォームです。 Kubernetesとは何か？ | Kubernetes わかったようで結局よくわからない感じですね。分解してみましょう。 宣言的な構成管理と自動化を促進 構成管理と自動化はお馴染みかもしれないですが、"宣言的"という言葉はそれほど使わないかもしれないですね。 これまでのサーバ構築であれば、一般的にはサーバを構築して ミドルウェア やアプリケーションなどのインストール、設定をしたうえで稼働させていたと思います。 kubernetes では、 マニフェスト と呼ばれるファイルを作成し、それを kubernetes に読み込ませることで ミドルウェア などを設定・実行させることができます。 この「 マニフェスト 」ですが、英単語の意味としては以下のような意味があります。 明らかにする、明示する manifestの意味・使い方・読み方｜英辞郎 on the WEB つまり、 kubernetes で稼働させるアプリや ミドルウェア の設定などを明示して(① マニフェスト 作成)、 kubernetes に「明示した通りに稼働させて」と宣言すると(② マニフェスト 実行)、 kubernetes 上で想定通りにアプリや ミドルウェア を稼働させることができる(③Pod作成)ということです。 コマンド実行したり、 シェルスクリプト を流して結果確認などして設定していたのが、 マニフェスト というファイルを作ればアプリや ミドルウェア を効率的に設定して稼働させることができるようになる、ということになります。 図にすると以下のようになります。 ① マニフェスト 作成 ここでは、nginxのPodを2個作成するという マニフェスト を作成しています。 (記載している内容は例としているだけなので、実際には正しい記載方法があります。) ② マニフェスト 実行 kubernnetesに マニフェスト 通りに稼働させるよう宣言します。 ③Pod生成 マニフェスト に記載された内容でPodを生成します。 Podの設定を変更したければ、 マニフェスト を編集して kubernetes に宣言すると変更内容が反映されます。 マニフェスト をバージョン管理することで、戻したい内容の マニフェスト を実行すれば kubernetes が即座に自動でその通りに再作成してくれるので、万が一トラブルがあった際にも最小限の被害で対応できそうですね。 コンテナ化されたワークロードやサービスを管理する ワークロードという言葉は kubernetes ではどういう意味で使われるのか、調べてみます。 ワークロードとは、 Kubernetes 上で実行中のアプリケーションです。ワークロードが1つの コンポーネント からなる場合でも、複数の コンポーネント が協調して動作する場合でも、 Kubernetes ではそれらはPodの集合として実行されます。 ワークロード | Kubernetes kubernetes の世界ではワークロードという言葉を使っていますが、いわゆるアプリケーションのことを表していて、アプリケーションは先ほど出てきた"Pod"として管理します。 "複数の コンポーネント が協調して動作する場合でも"という言葉について少し補足すると、 同じPodでも、アプリケーションとして稼働させるもの以外に、LBの役割やcronのjob実行などで稼働させることも可能です。 ものすごくざっくり言うと、 kubernetes では"Pod"という形式にすることで様々な機能を持ったコンテナをまとめて管理できる、ということになりそうです。 管理というと曖昧になってしまうので、例えばPodの状態確認とするとわかりやすくなるかもしれません。 上記でNginxのPodを作成したので、その状態確認を実施すると以下のようになります。 ※ kubernetes 用の コマンドライン ツール"kubectl"で確認します。 $ kubectl get pod NAME READY STATUS RESTARTS AGE Nginx1 1/1 Running 0 2m Nginx2 1/1 Running 0 2m このように作成したPodが一覧で表示され、状態確認ができます。 項目 詳細 READY 準備が完了しているかどうかを表します。1/1となっているので正常稼働しています。 STATUS Podの作成状況を表します。Runningとなっているので、正常稼働しています。 RESTART Podが再起動した回数を表示します。 AGE 作成されてどれくらい時間が経過したかを表します。上記では、2分前に作成されたことがわかります。 ここで他のPodも作成してみることにします。 LBとcronのPodを作成する マニフェスト を新しく作り、実行したとします。 $ kubectl get pod NAME READY STATUS RESTARTS AGE Nginx1 1/1 Running 0 5m Nginx2 1/1 Running 0 5m lb1 1/1 Running 0 3m cronjob1 1/1 Completed 0 1m LBのPodが新たに作成されていることが分かります。 また、cronのPodも新たに作成されていますが、STATUSが他のPodとは異なっています。 定期実行の設定がされたPodは、指定した実行時間にのみ起動されます。 Completedの場合はcron実行されて処理が終わった状態を示しています。 このように、 kubernetes ではPodという単位にすることで、様々な機能をまとめて管理することが可能となります。 ポータブルで拡張性のある こちらは上記の"宣言的"という言葉にも少し関連してきます。 例えば、上記で例に挙げたとおり「このアプリケーションをPod2個で稼働させて」と kubernetes に宣言すると、その通りに稼働します。 稼働させているうちにさらに2個Podが必要になった場合、「このアプリケーションをPod4個で稼働させて」と宣言すると、 即座にPodが2個追加され、4個のPodが稼働するようになります。 Pod追加時に、 kubernetes がこの時点でのnodeのリソース状態を確認し、よりリソースの少ないnodeを選んで、 全体のnodeのリソースが均等になるようにPodを作成してくれます。 さらに、運用上でPodを毎日再起動する必要があったりすると、その都度各nodeに分散させてPodを再作成します。 また、Pod自体のリソース(メモリなど)も指定することができ、同様に宣言すれば kubernetes が変更してくれます。 このように、 マニフェスト を実行することで、Podを簡単に稼働させることができたり、node上でのPod配置もその時に応じて変わったり、リソースの拡張や縮小も可能になります。 "ポータブルで拡張性のある"という言葉の持つイメージが湧いてきたかと思います。 Kubernetes の特徴 kubernetes の特徴について、公式の以下のリンクを確認してみます。 Kubernetesとは何か？ | Kubernetes サービス ディスカバリー と負荷分散 ストレージ オーケストレーション 自動化されたロールアウトと ロールバック 自動ビンパッキング 自己修復 機密情報と構成管理 今回は、上記で説明した内容とも関わってくる"自動化されたロールアウトと ロールバック "と"自己修復"について見てみましょう。 自動化されたロールアウトと ロールバック Kubernetes を使うとデプロイしたコンテナのあるべき状態を記述することができ、制御されたスピードで実際の状態をあるべき状態に変更することができます。例えば、アプリケーションのデプロイのために、新しいコンテナの作成や既存コンテナの削除、新しいコンテナにあらゆるリソースを適用する作業を、 Kubernetes で自動化できます。 自己修復 Kubernetes は、処理が失敗したコンテナを再起動し、コンテナを入れ替え、定義したヘルスチェックに応答しないコンテナを強制終了します。処理の準備ができるまでは、クライアントに通知しません。 Podについて自動作成したりできるのは、何となくイメージがついたかと思います。 ただ、 マニフェスト に記載して宣言すればPodが作成されるようだけど、実際はどのように動いているのかという疑問が浮かんでくると思います。 具体例 AWS 環境を例として、Podを作成するまでの段取りも含めて見てみましょう。 ①dockerfileからdocker imageを作成 →自動で色々やってくれる kubernetes ですが、元となるものはやはり必要です。なので、稼働させたいdocker imageを作成します。 ②作成したdocker imageをECRにpushして格納 →ECRはdocker imageの保存場所です。 ③格納したdocker imageを利用するよう マニフェスト に記載して、 kubernetes に宣言 → マニフェスト にECRのどの リポジトリ にあるどの名前のdocker imageを利用するのかを明示して、 kubernetes に宣言します。 ④ kubernetes が マニフェスト に従って、ECRに格納しているdocker imageをpullしPodを作成 → マニフェスト に記載されたdocker imageを利用して、Podを作成します。 マニフェスト にどのdocker imageを使うのか明示しておくことで、 kubernetes は指定されたdockerを利用し、 マニフェスト に記載された通りに動作させようとしてくれます。 この時に、"自動化されたロールアウトと ロールバック "が効果を発揮します。 新規作成したい時や変更を加えたい時など、対象のdocker imageで新しいPodを作成しつつ、古いPodがあれば自動で削除してくれます。 また、稼働させていたPodに何らかのトラブルが発生し、正常に稼働できなくなったとしても、 kubernetes の自己修復機能によって、問題のあるPodを削除して、同じdocker imageで新しいPodを作成してくれます。 kubernetes の特徴である"自動化されたロールアウトと ロールバック "と"自己修復"を利用してうまく運用すれば、比較的障害に強いシステムを作ることができそうですね。 まとめ "宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のある オープンソース のプラットフォーム"という言葉の意味や kubernetes の特徴やPodについて、少しでもイメージできたでしょうか？ 今回の内容はほんの一部分なので kubernetes を理解したということにはならないのですが、何かのお役に立てば幸いです。 最後までお読みいただき、ありがとうございました。 参考情報 Kubernetesドキュメント | Kubernetes KubernetesのWorkloadsリソース（その1） | Think IT（シンクイット） エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに 本記事では Python ライブラリ「Keras」を用いたレビューデータの２値分類用の ニューラルネットワーク モデルの作成についてまとめます。Kerasについてはインターネット上で多くの情報を手に入れられますが、本記事ではKerasによるモデルの作成に加えて、パラメータ最適化 フレームワーク 「Optuna」を用いた一部パラメータの自動最適化の試みについても紹介します。 はじめに Kerasとは Optunaとは Kerasによるニューラルネットワークモデルの作成の流れ Pythonのバージョンと利用ライブラリ データの入手 実行ディレクトリの整備 データの前処理 文字列の整形 データの読み込みと分割 文字列のベクトル化 Kerasによるニューラルネットワークモデルの定義 モデル作成・訓練・評価実行用クラスの定義 Optunaによる最適なパラメータの探索 最適なパラーメータの探索とニューラルネットワークモデルの作成・訓練の実施 作成したニューラルネットワークモデルの利用 結果と考察 全体スクリプト Kerasとは Kerasは オープンソース の ニューラルネットワーク /深層学習ライブラリです。 ニューラルネットワーク モデルを作成するためのライブラリにはKeras以外にも、TensorFlowやPytorchなどいくつか種類がありますが、Kerasは簡潔な記述で ニューラルネットワーク を作成できるといわれています。実際にKerasでは十数行で ニューラルネットワーク モデル周りの スクリプト を記述できます。 Keras公式サイト(日本語) keras.io Optunaとは Outunaはハイパーパラメータ自動最適化 フレームワーク です。専門用語を使わずに簡単に説明すると、Optunaは「人が自ら調整する必要があった 機械学習 モデル等のパラメータの最適値を自動的に見つけてくれるツール」です。 ニューラルネットワーク モデルでは隠れ層のユニット数など一部のパラメータの最適化を人が行うことになりますが、Optunaを使うとそれらのパラメータの最適化を自動化できます。 www.preferred.jp 　 Kerasによる ニューラルネットワーク モデルの作成の流れ 今回は以下の流れで ニューラルネットワーク モデルを作成します。 　　　　 Python のバージョンと利用ライブラリ 利用した Python のバージョンは「 Python 3.9.9 」です。 今回の ニューラルネットワーク モデル作成に際し、以下の外部ライブラリを利用しています。 KerasはTensorflowのtensorflow.kerasモジュールを通して利用します。 pandas cleantext scikit-learn tensorflow optuna データの入手 今回は英語のレビュー投稿に対し、内容が肯定的か否定的かを予測する ニューラルネットワーク モデルの作成を試みます。そのために必要なデータをKaggleから入手することにします。 Kaggleについて詳しくは公式サイトや紹介記事を参照して下さい。 www.kaggle.com ai-kenkyujo.com 今回は、こちらのTrip Advisor Hotel Reviewsという英語のホテルのレビュー投稿のデータを使います。 www.kaggle.com このデータは行毎にレビュー本文とレーティング(肯定的か否定的かの指標になります)がセットになっている形式のため、モデルの訓練用として使いやすいと思います。 　　　　 *Alam, M. H., Ryu, W.-J., Lee, S., 2016. Joint multi-grain topic sentiment: modeling semantic aspects for online reviews. Information Sciences 339, 206–223. ※　レビュー本文を見てみると文法的に？な英文が結構ありますが、今回はそのまま使うことにします。(公開用に匿名化処理をした影響なのかもしれません。) 実行 ディレクト リの整備 予め以下のような構造で実行 ディレクト リを整備しておきます。実行用のpyファイル、ダウンロードしたレビューの csv ファイル、Tensorboardに表示するデータの保存先となるフォルダを配置します。 　　　 データの前処理 レビューデータはそのまま使わず、文字列の整形やデータの分割、文字列のベクトル化といった前処理を行います。まずはそのための関数をいくつか定義します。 文字列の整形 レビュー本文は英語のため、それほど複雑な処理は必要ないと思います。今回は、 Python の前処理ライブラリのclean-textと組み込み関数のみで前処理を実施します。 Clean-text pypi.org ※ インストール時にはハイフンありのものを指定してください。「cleantext」という別のライブラリもあるので注意してください。 　　 pip install clean-text ※　 Python の スクリプト を掲載する際には、なるべく説明のコメントを入れ、関数には Google スタイルのdocstringライクな説明をつけるようにします。 def normalize_doc (text, no_digits= False , no_numbers= False , to_ascii= False ): """訓練データ正規化 訓練用データ(テキスト)を正規化します。 Args: text (str): 正規化したいテキスト no_digits (bool, optional): 桁数を維持したまま全ての数字を0に変換するかどうか(123は000に、5678は0000に変換されます) no_numbers (bool, optional): 桁数を残さず数字を全て指定した文字列(今回は0に設定しています)に変換するかどうか(123は0に5678も0に変換されます) to_ascii (bool, optional): 非アスキー文字をアスキー文字に変換するかどうか (日本語は非アスキー文字なため、日本語を含むテキストにはFalseを設定) Returns: str: 正規化済テキスト """ # テキストの最初と最後の余分なスペースを除去します。 text = text.strip() # 正規化用ライブラリを使ってデータを正規化します。ここではunicode errorの除去とアルファベットの小文字化のみを行っています。 text = cleantext.clean(text, no_digits=no_digits, to_ascii=to_ascii, no_numbers=no_numbers, replace_with_number= "0" ) return text データの読み込みと分割 CSV ファイルを読み込み、レーティングのつけ直しとデータ数の学習用と評価用への分割を行います。 レーティングのつけ直しでは、今回の予測を「レビューがポジティブかネガティブか」の2値予測(2値分類)とするため、レーティング1と2を「0」(ネガティブ)、レーティング４と５は「1」(ポジティブ)につけ直します。どちらとも取れそうなレーティング３は除外することにします。 また、データを学習用とモデルの評価用に分割する処理も行います。このとき、ポジティブレビューとネガティブレビューそれぞれで学習用と評価用に分割し、その後に学習用のポジティブレビューとネガティブレビュー同士、評価用のポジティブレビューとネガティブレビュー同士を結合します。 (全体の8割を学習用とした場合、すべてのネガティブレビューが学習用となり、評価用にはポジティブレビューしか含まれなくなることを防ぐためです。2番目の図で示す処理を行います。) 　　　　 def load_data (path): """訓練データ、正解ラベルの加工と訓練用。評価用への分割 CSVファイルから訓練データと正解ラベルを取り出し、正解ラベルの2値への変換と データの学習用と評価用への分割を行います。 訓練用データのデータフレームと評価用データのデータフレームを返します。 Args: path (str): レビュー本文とレーティングのCSVファイルのパス :Returns: pandas.DataFrame: 学習データのデータフレーム pandas.DataFrame: 評価用ラベルのデータフレーム """ # レビュー本文とレーティングのCSVファイルをデータフレーム形式で読み込みます。 review_df = pd.read_csv(path, header= 0 ) # データフレームの列を参照するときに便利なので列ラベルを取得しておきます。 columns = review_df.columns # レビューを「ポジティブ」、「ネガティブ」の2値で予測するため、レーティング1-2は0(ネガティブ)に、4-5は1(ポジティブ)に変換します。 # 今回中間の3は無視します。(3はポジティブともネガティブともとれる場合がありそうなため) mapping = { 1 : 0 , 2 : 0 , 3 : 3 , 4 : 1 , 5 : 1 } review_df[columns[ 1 ]] = review_df[columns[ 1 ]].map(mapping) # ネガティブレビューのみでフィルターをかけます。 negative_review_df = review_df[review_df[columns[ 1 ]] == 0 ] # ポジティブレビューのみでフィルターをかけます。 positive_review_df = review_df[review_df[columns[ 1 ]] == 1 ] # ネガティブレビュー、ポジティブレビューそれぞれを学習用と評価用に分割します。今回は学習用8割、評価用2割に分割します。 # 分割にはsklearnのtrain_test_splitを利用します。 # レビュー本文の前処理を同時に行うためにいったんデータをリスト形式に変えています。 xn = [normalize_doc(review_body) for review_body in negative_review_df[columns[ 0 ]]] yn = list (negative_review_df[columns[ 1 ]]) xp = [normalize_doc(review_body) for review_body in positive_review_df[columns[ 0 ]]] yp = list (positive_review_df[columns[ 1 ]]) xn_train, xn_test, yn_train, yn_test = train_test_split( xn, yn, test_size= 0.2 , random_state= 42 , ) xp_train, xp_test, yp_train, yp_test = train_test_split( xp, yp, test_size= 0.2 , random_state= 42 , ) # ネガティブレビューとポジティブレビューデータを結合し、学習用データのデータフレームと評価用データのデータフレームを作成します。 x_train = xn_train + xp_train x_test = xn_test + xp_test y_train = yn_train + yp_train y_test = yn_test + yp_test # 学習用データのデータフレーム train = list () for x, y in zip (x_train, y_train): train.append([x, y]) train_df = pd.DataFrame(train, columns=[ "Review" , "Rating" ]) # 評価用データのデータフレーム test = list () for x, y in zip (x_test, y_test): test.append([x, y]) test_df = pd.DataFrame(test, columns=[ "Review" , "Rating" ]) # 関数の戻り値としてデータフレームをセットする際に「.sample(frac =1).reset_index(drop=True)」でデータをシャッフルしインデックスをふり直します。 return train_df.sample(frac= 1 ).reset_index(drop= True ), test_df.sample(frac= 1 ).reset_index(drop= True ) 文字列のベクトル化 モデルの訓練の際、テキストデータをそのまま入力とすることができません。 ベクトル化というテキストを数値列に変換する作業が必要になります。そこで今回は「TF-IDF」というテキスト内の単語の重要性を反映した数値列によるベクトル化を行ってみます。 また、今回は「 ストップワード 」という頻度単語のフィルタを使わない代わりに、SklearnのTfidfVectorizerのパラメータの「max_df」を設定し、重要ではない単語の除去を試みます。 Tf-idfについて atmarkit.itmedia.co.jp Sklearnの公式ドキュメント scikit-learn.org def get_vectorizer (corpus_x_train, corpus_x_test): """テキストのTF-IDFによるベクトル化 レビュー本文データをtfidfによってベクトル化します。ベクトライザー(ベクトルへの変換器)はデータのうち モデルの訓練に使うデータのみで訓練します。評価用データは学習データで訓練したベクトライザーを使いベクトル化します。 Args: corpus_x_train (iterator): データのうち訓練用に分割した部分 corpus_x_test (iterator): データのうち評価用に分割した部分 Returns: sklearn.feature_extraction.text.TfidfVectorizer: 訓練後のTF-IDFベクトライザー ndarray: ベクトル化の対象となった語彙のリスト (ndarray of str objects) ndarray: ベクトル化した訓練用データ ndarray: ベクトル化した評価用データ ベクトライザー、ベクトル化の対象となった語彙のリスト、ベクトル化した訓練用データ、ベクトル化した評価用データ """ # ベクトライザーを作成します。max_dfの値を設定すると指定した値の割合以上の文書に含まれる語彙はベクトル化の対象とならなくなります。 # max_dfの値を0.3に設定していますが、データの実情に合わせて調整が必要です vectorizer = TfidfVectorizer(max_df= 0.3 ) # 訓練用データを使ってベクトライザーを訓練し、同時に訓練用データのベクトル化も行います。 vec_corpus_x_train = vectorizer.fit_transform(corpus_x_train) # 訓練したベクトライザーで評価用データのベクトル化を行います。 vec_corpus_x_test = vectorizer.transform(corpus_x_test) return vectorizer, vectorizer.get_feature_names_out(), vec_corpus_x_train.toarray(), vec_corpus_x_test.toarray() Kerasによる ニューラルネットワーク モデルの定義 データの前処理用関数の定義が終わったので、Kerasを使い ニューラルネットワーク モデルを定義していきます。 今回は次のような ニューラルネットワーク モデルを定義していきます。 　　　 ※　中間層が2層ある ニューラルネットワーク モデルは深層学習モデルともみなせますが、本記事では「 ニューラルネットワーク モデル」と呼ぶことにします。 テキスト(今回はレビュー本文)のベクトルデータを入力とし、入力層→中間層1→中間層2→出力層と処理を行っていきます。 今回はKerasのFunctionalモデルを使いこのモデルを定義します。Kerasでは、モデルの定義に「Functional API 」と「Sequentialモデル」が使えますが、複数入力、複数出力をするような複数なモデルを定義する際にはFuncitional API を使います。(今回はベクトル1つを入力とするので複数入力ではありませんが、将来的な発展の可能性も考えて、Functional API を選んでいます。) KerasはTensorflowのtensorflow.kerasモジュールからインポートして使います。 keras.io keras.io Kerasでモデルを定義する際は、keras.layers.Inputやkeras.layers.Denseを使い各層のユニット数や活性化関数を定義していきます。 上の図では省略していますが、中間層1と中間層２の間、中間層2と出力層の間にDropout層(keras.layers.Dropout)を追加し 過学習 対策をします。(上の図では省略) deepage.net 最後にkeras.Modelのcompileメソッドを使い、モデルの損失関数や オプティマ イザを指定します。 def create_model (n_vocab, unit): """Kerasによるニューラルネットワークの定義 KerasのFuncitional APIを使いニューラルネットワークモデルを定義します。 Args: n_vocab (int): 入力として渡すデータの次元数です。入力層のユニット数となります。(ベクトライザーから取得する語彙のリスト内の要素数とします。) unit (int): 中間層のユニット数です。任意の数を設定できますが、今回はOptunaによる最適な値(整数)を自動で設定します。 Returns: tensorflow.keras.Model: ニューラルネットワークモデル(オブジェクト) """ # 入力層を追加します。ユニット数はvocabと同じです。 input_ = keras.layers.Input(shape=(n_vocab,)) # 中間層(全結合層)とドロップアウト層を追加します。ユニット数は引数unitで指定します。 x = keras.layers.Dense(unit, activation= "relu" )(input_) x = keras.layers.Dropout( 0.8 )(x) # 2層目の中間層(全結合層)とドロップアウト層を追加します。ユニット数は引数unitで指定します。 x = keras.layers.Dense(unit, activation= "relu" )(x) x = keras.layers.Dropout( 0.5 )(x) # 出力層を追加します。 ソフトマックス関数を使う2値分類のためユニット数は2です。 output = keras.layers.Dense( 2 , activation= "softmax" )(x) # モデル(オブジェクト)を作成します。 model = keras.Model(inputs= input , outputs=output) # パラメータの更新や損失関数、評価関数に何を使うかを設定します。変更する必要はないかと思います。 model.compile( optimizer= "adam" , loss= "sparse_categorical_crossentropy" , metrics=[ "accuracy" ] ) # モデルの概要を出力します。 print (model.summary()) return model モデル作成・訓練・評価実行用クラスの定義 Kerasによる ニューラルネットワーク モデルの定義ができたので、次に「モデル(のオブジェクト)を作成し、そのモデルの訓練を行うクラス」を作成します。 これまでに作成した前処理関数を使い、学習データを整え、 ニューラルネットワーク もですの作成、訓練から評価までを行うクラスとしてみます。 class NnModel : """ニューラルネットワーク作成・訓練・評価用クラス ニューラルネットワークモデルオブジェクトの作成、訓練、評価を行うためのクラスです。 Attributes: vec_x_train (ndarray): ベクトル化済の訓練用データ x_test (pandas.Series): ベクトル化前の評価用データ vec_x_test (ndarray): ベクトル化済の評価用データ y_train (pandas.Series): モデルの訓練時に使う正解ラベル y_test (pandas.Series): モデルの評価時に使う正解ラベル model (tensorflow.keras.Model): model_fit実行時に作成されるニューラルネットワークオブジェクト """ def __init__ (self, path): # CSVファイルから訓練データと正解データを取得します。 train_df, test_df = load_data(path) columns = train_df.columns x_train = train_df[columns[ 0 ]] self.x_test = test_df[columns[ 0 ]] self.y_train = train_df[columns[ 1 ]] self.y_test = test_df[columns[ 1 ]] # 訓練データをベクトル化します。 self.vectorizer, self.vocab, self.vec_x_train, self.vec_x_test = get_vectorizer(x_train, self.x_test) # 後で訓練後のモデルを利用する際に必要になるので、ベクトライザーのオブジェクトをpickleファイルに保存しておきます。 with open ( "my_vectorizer.pickle" , "wb" ) as f: pickle.dump(self.vectorizer, f) def model_fit (self, unit, logdir, validation_split= 0.2 , epochs= 20 , batch_size= 32 ): """ニューラルネットワークモデル (tensorflow.keras.Model)の作成と用意した訓練データでの訓練 ニューラルネットワークモデルオブジェクトを作成し、用意した訓練データで訓練します。 Optunaとの連携のため、ニューラルネットワークオブジェクトはこのメソッドで作成します。 Args: unit (int): 中間層のユニット数です。今回はoptunaによって最適な値を設定します。 logdir (str): 訓練時の学習ログを保存するフォルダを指定します。(tensorboardを使う場合にこのフォルダ内のログを参照します。) validation_split (float): 訓練時(keras.Modelのfitメソッド実行時)の各エポックで検証用に使う訓練データの割合を指定します。 epochs (int): 訓練データを繰り返して学習させる回数を指定します。 batch_size (int): 何件の訓練データ毎にパラメータの更新を行うかを指定します。 Returns: float: モデルの評価用データでの損失値 """ # ニューラルネットワークモデル(オブジェクト)を作成します。 self.model = create_model( len (self.vocab), unit) # 学習の進行状況の可視化や精度が向上しなくなった際の学習の早期終了を行う関数をコールバックにまとめます。 tensorboard = keras.callbacks.TensorBoard(log_dir=logdir) early_stopping = keras.callbacks.EarlyStopping(monitor= 'val_loss' , patience= 3 ) model_name = "my_neural_model.h5" modelCheckpoint = keras.callbacks.ModelCheckpoint( filepath=model_name, monitor= 'val_loss' , verbose= 1 , save_best_only= True , save_weights_only= False , mode= 'min' , period= 1 ) callbacks = [tensorboard, early_stopping, modelCheckpoint] # モデルの訓練を実施します。 self.model.fit( self.vec_x_train, self.y_train, validation_split=validation_split, epochs=epochs, batch_size=batch_size, callbacks=callbacks # 上で定義したコールバック関数のリストを指定します。 ) # my_neural_model.h5に保存されている(各エポックのうち最も精度の良かった)モデルを読み込んでテスト用データで精度を算出します。 model = keras.models.load_model(model_name) pred = model.evaluate(self.vec_x_test, self.y_test) # ニューラルネットワークモデルの隠れ層の最適ユニット数の推定のため、今回はテストデータでの損失値を学習メソッドの戻り値としておきます。 return pred[ 0 ] def model_predict (self): """ニューラルネットワークモデルの性能評価 train_test_splitで分割したデータのうち評価用のデータを使い、 model_fitで訓練したモデルの性能を評価します。 Returns: list: モデルの予測結果のリスト(予測ラベルのリスト) """ # (keras.Modelの)predictメソッドに評価用のデータを渡します。 y_pred = self.model.predict(self.vec_x_test) # 予測結果のうち、「1」(あり)、「０」(なし)のうち予測数値が高かった方をリストに追加します。 y_pred = [p.argmax() for p in y_pred] # sklearnのスコア算出用の各関数に予測ラベルと正解ラベルを渡しモデルの性能を評価します。 print ( "result" ,f "accuracy: {accuracy_score(self.y_test, y_pred)}" , f "precision: {precision_score(self.y_test, y_pred)}" , f "recall: {recall_score(self.y_test, y_pred)}" , sep= " \r\n " ) return y_pred Optunaによる最適なパラメータの探索 Kerasを使った ニューラルネットワーク モデルの作成から評価までを行うクラスが定義できたので、実行して結果を得ることもできるのですが、今回は中間層の最適なユニット数を「Optuna」を使って自動最適化してみます。 Optunaを使う際には、最適化したいパラメータとそのデータ型、ある値が最適かどうかを判断するための指標に何を使うかを指定します。今回は: 最適化したいパラメータとそのデータ型: 中間層のユニット数　整数(int)型 最適かどうかの指標: 指定したパラメータでのモデル訓練後の損失値 という条件でパラメータの自動最適化を実施します。 keras.io keras.io def objective (trial): """Optunaでパラメータ推定を行う際の処理内容 Optunaでパラメータ推定を行うための関数です。 目的のパラメータを変更した際の精度の指標となる数値が戻り値となるようにしておく必要があります。 (値が改善すればより良いパラーメータ値とみなします。) Args: trial: OptunaのStudyオブジェクトが設定します。 :Returns: float: Optunaがパラメータを設定した作成したモデルの損失値(精度指標) """ # 今回はニューラルネットワークモデルの中間層のユニット数の自動推定を試みます。 # 指定した数値(今回は2-30)の間で最も精度が高くなる数値を最適なユニット数とみなします。 # 推定する数値は後で参照するために"unit"と指定しておきます。 unit = trial.suggest_int( "unit" , 2 , 30 ) loss = nn_model.model_fit(unit, r"logs" , epochs= 100 ) return loss 最適なパラーメータの探索と ニューラルネットワーク モデルの作成・訓練の実施 これまで定義してきた関数とクラス、Optunaを使い、最適なユニット数の探索と最適なユニット数を設定したモデルの作成を行います。 処理の流れは次のようになります。 ニューラルネットワーク モデル作成用オブジェクトの作成(学習/評価用データの前処理) OptunaのStudyオブジェクトを作成、最適なユニット数を探索 探索完了後にStudyオブジェクトからユニット数の数値を取得 ニューラルネットワーク モデル作成用オブジェクト(keras.Model)のモデル作成/訓練メソッド(fit)に最適なユニット数を渡してモデルを作成/訓練 評価用データでモデルを評価 # ニューラルネットワークモデル作成用オブジェクトを作成します。 target_data = r"tripadvisor_hotel_reviews.csv" nn_model = NnModel(target_data) def main (): """実行用関数 これまでに作成してきた関数とクラスを使い最適な中間層ユニット数の推定から モデルの定義、訓練、評価までを実行します。 Returns: None """ # oputunaで最適なユニット数を見つけます。最後にBest unitとして出力されます。 # directionは損失関数の場合はminimizeを指定します。(正解率を精度指標とする場合にはmaxizeを指定します。) study = optuna.create_study(direction= "minimize" ) # 最適なユニット数を見つけるために何度試行するかを指定し、自動推定を実行します。 study.optimize(objective, n_trials= 10 ) # 最適なユニット数はこの変数から　best_params["unit"]　とすると取得できます。ディレクトリ型の参照と同じです。 best_params = study.best_params print (f "Best unit: {best_params}" ) # 最適な数値を中間層のユニット数に指定し、モデルの定義と訓練、評価を行います。 nn_model = NnModel(target_data) nn_model.model_fit(best_params[ "unit" ], r"logs" , epochs= 100 ) nn_model.model_predict() if __name__ == "__main__" : main() 今回作成したモデルの評価結果は以下のようになりました。 　　　　 Accuracy: 0.9555 　　　　 Precision: 0.9609 　　　　 Recall: 0.9861 かなり良い数値ですが、Tensorboardでモデル損失のグラフを確認してみると、2エポック以降減少が見られません。対策はしていましたが 過学習 をしてしまったようです。 (濃い青の線が学習データでの損失値、水色の線が評価用データでの損失値) 　　　　 (Tensorboardでは学習データでモデルを繰り返し訓練する中で、どのように性能が変化していったかを確認することができます。) (model_fitメソッドのtensorboard = keras.callbacks.TensorBoard(log_dir=logdir)の行でtensorboardの設定を行っています。) www.tensorflow.org deepage.net 作成した ニューラルネットワーク モデルの利用 最後に作成したモデルを使って、未知のデータでの予測を行うための関数を作成してみます。 モデル作成時に使った ベクトラ イザーと保存した ニューラルネットワーク モデルを読み込み、それらに予測を行いたいデータ(テキスト)を渡して予測結果の確率を出力します。 保存したモデルは、tensorflow.keras.models.load_modelで読み込みます。 def model_load_predict (x, model_h5, vec_pickle): """ニューラルネットワークモデルを利用した未知データに対する予測用関数 作成・保存したニューラルネットワークモデルを利用して、未知データの予測を行います。 Args: x (str): テキストデータ(レビュー本文と同じ形式) model_h5 (str): 作成したニューラルネットワークモデルのh5ファイルのパス vec_pickle (str): 保存したベクトライザーのpickleファイルのパス Returns: int: 予測ラベルの整数値(入力したテキストをネガティブと予測した場合は0,、ポジティブと予測した場合は1) """ # モデルとベクトライザーを読み込みます。 model = keras.models.load_model(model_h5) with open (vec_pickle, 'rb' ) as f: vectorizer = pickle.load(f) # 入力データの正規化とベクトル化を行います。 x = normalize_doc(x) vec_x = vectorizer.transform([x]).toarray() # 入力データに対して予測を行い、結果を出力します。 pred = model.predict(vec_x) print ( "== Result ==" ) print ( "Positive" ) if pred[ 0 ][ 1 ] > pred[ 0 ][ 0 ] else print ( "Negative" ) print (f "Positive: {pred[0][1]}, Negative: {pred[0][0]}" ) return pred.argmax() if __name__ == "__main__" : x = input ( ">>>" ) model_h5 = "my_neural_model.h5" vec_pickle = "my_vectorizer.pickle" res = model_load_predict(x, model_h5, vec_pickle) print ( "予測ラベル: " , res) 関数を実行し「>>>」と表示されたら、ネガティブかポジティブかを予測したいテキストを入力します。テキスト入力後に「enter」を押すと予測結果が出力されます。(予測結果の前に警告が表示されることがありますが、今回は無視します。) 　　　　 　　　　 結果と考察 KerasとOptunaを使い、実際に予測を行うことができる ニューラルネットワーク モデルを作成することができました。 このモデルは評価結果の数値を見ると悪くないように見えるのですが、未知のレビューデータに対する予測性能が高いとは言えません。一目でポジティブとわかる内容のレビューに対して、99％ネガティブという予測をすることもありました。 今回の反省点としては、 データの質が良くなかった。 　　→　今回は文法的に怪しい英文もそのまま使いました。これが良くなかったのかもしれません。 　　→　非常に長いレビュー本文を持つレコードが含まれていましたが、この手のレコードは「いい点もあった。が、しかし…」という流れでポジティブな側面とネガティブな側面を持っている可能性があり、どちらかに分類するには容易ではないのかもしれません。 データが足りなかった。 　　→　2万レコードでは足りなかったのかもしれません。 ベクトル化の方法が良くなかった。 　　→ TF-IDFよりも単語の意味を反映するとされる分散表現の方がよかったのかもしれません。 別のハイパーパラメータもOptunaで最適化すべきだった。 　　→ ユニット数以外にも学習率やバッチサイズも最適な値をOptunaで設定するとよかったのかもしれません。 モデルの アーキテクチャ が適切でなかった。 　　→ 今回のような ニューラルネットワーク モデルよりもリカレント ニューラルネットワーク モデルの方がテキスト分類には適しているのかも知れません。 といったことが考えられます。このモデルを改善する際や新たなモデルを作成する際には、上記の反省点を踏まえる必要があると感じています。 特にデータに関しては、大量のデータが必要になるため、ある試行でうまくいかなかった際に、簡単に代替のデータを用意できるとは限りません。 自前でデータを用意する際には、最初から質の高いデータが揃うようにデータ収集作業を行う必要があると思います。 全体 スクリプト 最後に、今回の ニューラルネットワーク モデル作成の試みに関わる スクリプト 全体をまとめておきます。 テキストデータの分類であれば、少しの編集でいろいろなデータを扱えると思います。ぜひ、ご自身のデータで予測モデルを作成してみてください。 # coding: utf-8 import pandas as pd import pickle import cleantext import optuna from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.model_selection import train_test_split from sklearn.metrics import accuracy_score, precision_score, recall_score from tensorflow import keras def normalize_doc (text, no_digits= False , no_numbers= False , to_ascii= False ): text = text.strip() text = cleantext.clean(text, no_digits=no_digits, to_ascii=to_ascii, no_numbers=no_numbers, replace_with_number= "0" ) return text def load_data (path): review_df = pd.read_csv(path, header= 0 ) columns = review_df.columns mapping = { 1 : 0 , 2 : 0 , 3 : 3 , 4 : 1 , 5 : 1 } review_df[columns[ 1 ]] = review_df[columns[ 1 ]].map(mapping) negative_review_df = review_df[review_df[columns[ 1 ]] == 0 ] positive_review_df = review_df[review_df[columns[ 1 ]] == 1 ] xn = [normalize_doc(review_body) for review_body in negative_review_df[columns[ 0 ]]] yn = list (negative_review_df[columns[ 1 ]]) xp = [normalize_doc(review_body) for review_body in positive_review_df[columns[ 0 ]]] yp = list (positive_review_df[columns[ 1 ]]) xn_train, xn_test, yn_train, yn_test = train_test_split( xn, yn, test_size= 0.2 , random_state= 42 , ) xp_train, xp_test, yp_train, yp_test = train_test_split( xp, yp, test_size= 0.2 , random_state= 42 , ) x_train = xn_train + xp_train x_test = xn_test + xp_test y_train = yn_train + yp_train y_test = yn_test + yp_test train = list () for x, y in zip (x_train, y_train): train.append([x, y]) train_df = pd.DataFrame(train, columns=[ "Review" , "Rating" ]) test = list () for x, y in zip (x_test, y_test): test.append([x, y]) test_df = pd.DataFrame(test, columns=[ "Review" , "Rating" ]) return train_df.sample(frac= 1 ).reset_index(drop= True ), test_df.sample(frac= 1 ).reset_index(drop= True ) def get_vectorizer (corpus_x_train, corpus_x_test): vectorizer = TfidfVectorizer(max_df= 0.3 ) vec_corpus_x_train = vectorizer.fit_transform(corpus_x_train) vec_corpus_x_test = vectorizer.transform(corpus_x_test) return vectorizer, vectorizer.get_feature_names_out(), vec_corpus_x_train.toarray(), vec_corpus_x_test.toarray() def create_model (n_vocab, unit): input_ = keras.layers.Input(shape=(n_vocab,)) x = keras.layers.Dense(unit, activation= "relu" )(input_) x = keras.layers.Dropout( 0.8 )(x) x = keras.layers.Dense(unit, activation= "relu" )(x) x = keras.layers.Dropout( 0.5 )(x) output = keras.layers.Dense( 2 , activation= "softmax" )(x) model = keras.Model(inputs= input , outputs=output) model.compile( optimizer= "adam" , loss= "sparse_categorical_crossentropy" , metrics=[ "accuracy" ] ) print (model.summary()) return model class NnModel : def __init__ (self, path): train_df, test_df = load_data(path) columns = train_df.columns x_train = train_df[columns[ 0 ]] self.x_test = test_df[columns[ 0 ]] self.y_train = train_df[columns[ 1 ]] self.y_test = test_df[columns[ 1 ]] self.vectorizer, self.vocab, self.vec_x_train, self.vec_x_test = get_vectorizer(x_train, self.x_test) with open ( "my_vectorizer.pickle" , "wb" ) as f: pickle.dump(self.vectorizer, f) def model_fit (self, unit, logdir, validation_split= 0.2 , epochs= 20 , batch_size= 32 ): self.model = create_model( len (self.vocab), unit) tensorboard = keras.callbacks.TensorBoard(log_dir=logdir) early_stopping = keras.callbacks.EarlyStopping(monitor= 'val_loss' , patience= 3 ) model_name = "my_neural_model.h5" modelCheckpoint = keras.callbacks.ModelCheckpoint( filepath=model_name, monitor= 'val_loss' , verbose= 1 , save_best_only= True , save_weights_only= False , mode= 'min' , period= 1 ) callbacks = [tensorboard, early_stopping, modelCheckpoint] self.model.fit( self.vec_x_train, self.y_train, validation_split=validation_split, epochs=epochs, batch_size=batch_size, callbacks=callbacks ) model = keras.models.load_model(model_name) pred = model.evaluate(self.vec_x_test, self.y_test) return pred[ 0 ] def model_predict (self): y_pred = self.model.predict(self.vec_x_test) y_pred = [p.argmax() for p in y_pred] print ( "result" , f "accuracy: {accuracy_score(self.y_test, y_pred)}" , f "precision: {precision_score(self.y_test, y_pred)}" , f "recall: {recall_score(self.y_test, y_pred)}" , sep= " \r\n " ) def objective (trial): unit = trial.suggest_int( "unit" , 2 , 30 ) loss = nn_model.model_fit(unit, r"logs" , epochs= 100 ) return loss target_data = r"tripadvisor_hotel_reviews.csv" nn_model = NnModel(target_data) def main (): study = optuna.create_study(direction= "minimize" ) study.optimize(objective, n_trials= 10 ) best_params = study.best_params print (f "Best unit: {best_params}" ) nn_model = NnModel(target_data) nn_model.model_fit(best_params[ "unit" ], r"logs" , epochs= 100 ) nn_model.model_predict() def model_load_predict (x, model_h5, vec_pickle): model = keras.models.load_model(model_h5) with open (vec_pickle, 'rb' ) as f: vectorizer = pickle.load(f) x = normalize_doc(x) vec_x = vectorizer.transform([x]).toarray() pred = model.predict(vec_x) print ( "== Result ==" ) print ( "Positive" ) if pred[ 0 ][ 1 ] > pred[ 0 ][ 0 ] else print ( "Negative" ) print (f "Positive: {pred[0][1]}, Negative: {pred[0][0]}" ) return pred.argmax() if __name__ == "__main__" : main() x = input ( ">>>" ) model_h5 = "my_neural_model.h5" vec_pickle = "my_vectorizer.pickle" res = model_load_predict(x, model_h5, vec_pickle) print (res) エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

【目次】 PdM とは PM（プロジェクトマネージャー）との違い PdM/PMの役割表 PdM に必要なスキル おすすめの書籍/勉強会 ラクスのPdMとして活躍してみませんか？ 終わりに 技術広報の yayawowo です。 昨今、PdM（プロダクトマネージャー）という言葉を耳にすることが増えたのではないでしょうか？ しかしながら… 「実際何をしている人かわからない！」 「PdMを目指しているけど、必要なスキルって…？」 と不明点もあると思います。 本記事では、PdM（プロダクトマネージャー）の基本や必要なスキル等を紹介させていただきます。 ◆ 関連ブログも合わせてご確認ください！ ・ プロジェクトマネジメント とは 【まとめ】 ・ PMBOK とは【まとめ】 ・ 要件定義 とは【まとめ】 ・ プロジェクトマネジメントTips 20選　～現場から語るプロマネの極意～ PdM とは PdMとは、プロダクトマネージャーのことを指します。 経営方針や企業戦略、ビジネスサイド側の販売計画に基づく顧客要求の分析、要求分析/定義を行い、「プロダクト（製品・商品・サービス）」を成功に導く責任者をPdMと呼びます。 またプロダクトとは、一般的にお客様へ販売する製品のことを言いますが、ソフトウェア・データ等も含まれます。 元々、製造業で使われていた言葉でしたが、昨今はIT/Web業界にまで派生し、注目を集めています。 当社PdM（プロダクトマネージャー）は、製品企画を行う「製品力会議」から参加します。 「製品力会議」では、ビジネスサイドの部長やカスタマーサクセスと顔を合わせるため、開発ロードマップにPdM（プロダクトマネージャー）としての声を反映させることができます！ 　 また、PdM（プロダクトマネージャー）の類似職種として、PM（プロジェクトマネージャー）があります。 以下にて、職種の違いを解説します。 PM（プロジェクトマネージャー）との違い PM（プロジェクトマネジャー）とは、期間が定められたプロジェクトの達成/成功に向けて進捗、品質、コストを管理しコン トロール する人のことを指します。 担当プロジェクトに対し、責任をもって管理することが求められる職種です。 プロジェクトマネジメントを解説している記事も是非ご参考ください。 tech-blog.rakus.co.jp PdM/PMの役割表 職種 役割 PdM 経営方針や企業戦略、ビジネスサイド側の販売計画に基づく顧客要求の分析、要求分析/定義を行い、「プロダクト（製品・商品・サービス）」を成功に導く責任を担う PM 期間が定められたプロジェクトの達成/成功に向けて進捗、品質、コストの管理責任を担う PdM、PMとの役割が異なることをご理解いただけたでしょうか？ PdM に必要なスキル ◆ マネジメント面 ・ コミュニケーション力 ・ 進捗管理 能力 ・ 課題解決力 プロダクトマネージャーという名前の通り、マネジメント面でのスキルは重要です。 上記3点は、特に必要となるスキルセットとなります。 ◆ ビジネス面 ・ マーケティング 力 ・ 業界知識 市場調査を行い、分析することで市場ニーズを把握することが必要です。 プロダクトを開発にするにしても、市場のニーズに合っていないものを開発するのは会社としてもメリットがありません。 マーケティング 力と業界知識は、PdM（プロダクトマネージャー）にとって大切なスキルと言えるでしょう。 ◆ テク ノロ ジー 面 ・ UI/UXデザイン ・ 開発スキル お客様にシステムを長く使ってもらうには、使いやすいデザイン、構成となっているのが大切です。 お客様に選ばれるプロダクトにするためには、UI/UXのスキルを深めておくことが大切となります。 また、デザイン性だけでなくプロダクト設計も同様のことが言えますので、ある程度の開発スキルがあることは好ましいと思います。 おすすめの書籍/勉強会 おすすめの書籍と勉強会をご紹介いたします！ ◆ 書籍 PdM（プロダクトマネージャー）におすすめの書籍を並べてみました。 学習の一助となれば幸いです。 『 プロダクトマネジメント のすべて 事業戦略・IT開発・UXデザイン・ マーケティング からチーム・組織運営まで』 タイトルの通り、まさに プロダクトマネジメント の決定版といえる書籍です。 180点超の図版で分かりやすく解析しています。 また、 ケーススタディ もついているので、実践的に学ぶことができます。 『INSPIRED 熱狂させる製品を生み出す プロダクトマネジメント 』 シリコンバレー で実施している プロダクトマネジメント の手法がまとめられている書籍です。 例えば、 Google 、 Apple 、 Facebook 、 Netflix 、Tesla、 Amazon 等の手法を学ぶことが出来ます。 『 プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』 プロダクトマネジメント で必要な情報が一通り書かれている一冊です。 マネジメント手法において必要な戦略や、組織、プロセスについてを論じています。 ◆ 勉強会 当社主催の技術イベントに「PdM TIps LT会」がございます。 rakus.connpass.com 2021年3月に開催した際は、以下発表テーマがありました。 【発表テーマ】 ・ アラフィフの開発者が プロダクトマネジメント をはじめてみた ・ ジョブ理論とプロダクト開発 ・ oVice着想から初有料ユーザーを獲得するまでのPMビハインドストーリー ・ PMが「開発を巻き込んだ施策相談会」で工夫したポイント ・ 私たち“プロダクト主導組織”になれてるかな？を問う自問自答Tips ・ LabTech企業の初代PMになってやってきたこととこれから ・ PdM忙しい問題どうします？ -80点以上のプロダクトを目指したら緩和されてきた話- ・ PjM→PdMになった1年目の失敗とTips vol.2も今年の夏ごろに開催を予定しております。 ご興味ありましたら connpass 又は TECH PLAY を定期的にご確認いただけますと幸いです！ ラク スのPdMとして活躍してみませんか？ 当社 ラク スでは、プロダクトマネージャーを積極的に募集しております！ PdM（プロダクトマネージャー）組織は2021年8月からスタートし、サービス全体の視点を持って働ける環境が備わっております。 ビジネスサイドを通じてお客様の課題把握、プロダクトの開発部隊へ抜けもれなく効率的に要求を落とし込み、開発側へ連携するために当社ではPdMというポジションを置いております。 そのため、当社PdMは以下スキルを重要視しております。 Webサービス で開発知識 RFP 、要求仕様策定の実務経験 ステークホルダー との折衝・調整経験 そんな ラク スのPdM特徴は以下の通りです！ ラク スのPdM 開発スタイル ベスト・オブ・ブリード （異なるフェーズのマルチプロダクト） 組織 プロダクト単位でコミット 案件 顧客課題・案件単位のコミット 当社PdM（プロダクトマネージャー）の面白さは、挑戦の裁量と規模です。 当社最大のプロダクトについてサービス全体の視点を持って動けること 新しいチームで、PdMの役割そのものを立ち上げていけること 上記の内容にピンっ！ときた方は、以下の求人内容を是非ご確認ください！ career-recruit.rakus.co.jp 「まずは、会社説明を聞いてみたい！」というのも大歓迎です。 以下フォームより申し込みをお願いいたします！ rakus.hubspotpagebuilder.com 終わりに PdM（プロダクトマネージャー）のまとめ記事はいかがでしたでしょうか？ 年々、社会全体としてPdMポジションは重要となってきております。 今後PdMを目指す方にとって、本記事の内容が少しでもお役に立てれば幸いです！ もし当社PdMに少しでもご興味をお持ちになりましたら、定期的に行っているイベントもございます。 是非ご参加ください！ ◆ イベント情報 < connpass > rakus.connpass.com < TECH PLAY > techplay.jp PdM Tips LT会 - vol.2の開催が決定！ ご興味ありましたら以下より、ご登壇/ご視聴の申込をお願いいたします！ techplay.jp rakus.connpass.com お気軽にどうぞ。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは、弊社サービスのインフラを運用している id:keijiu (ijikeman)です。 今回は、「Knative on minikubeでServing & Eventing Helloworldを動かすまで(構築編)」を記載します。 [対象読者] Knative Eventing環境を自分で作ってみたい人 Knative EventingでサンプルコードHelloworldを動かしたい人 Knative Eventingの構成を理解したい人 [記事を読んでわかること] knative Cli [kn] を使ってminikube上でKnative Eventingを構築 [構築環境情報] CPU 4 Memory 4GB OS Alma Linux 8.5 minikube version 1.23.4 minikube Driver docker Knative v1.4.0 目次 目次 1. docker-ceのセットアップ docker-ceリポジトリのセットアップ docker-ceのインストールと起動 docker-ceの起動を確認 2. minikube CLIのセットアップ minikube CLIコマンドのセットアップ minikubeの動作確認 minikube用アカウントを用意する k8sユーザに変更し、minikubeクラスタを構築する 3. Knativeのセットアップ kubectlコマンドの設置 knative Cli(kn) + Knative quickstart pluginによる構築 knativeのバージョン指定 kn(Knative cli)の設置 Knative Quickstart Pluginの設置 Knative(Serving + Eventing)のセットアップ Knative環境の動作状況を確認する 1. docker-ceのセットアップ minikubeを動作させる為にはいくつかのDriverをあらかじめセットアップしておく必要があります。 参考: Drivers | minikube から今回はdocker-ceを選択します。 Docker-CEのセットアップは以下の情報を元にセットアップを行います。 Docker CE の入手（CentOS 向け） — Docker-docs-ja 20.10 ドキュメント docker-ce リポジトリ のセットアップ # sudo yum install -y yum-utils \ device-mapper-persistent-data \ lvm2 # sudo yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo docker-ceのインストールと起動 # sudo yum install -y docker-ce # sudo systemctl enable docker # sudo systemctl start docker docker-ceの起動を確認 # sudo systemctl status docker --- ● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2022-05-25 23:56:00 EDT; 2s ago Docs: https://docs.docker.com Main PID: 26493 (dockerd) Tasks: 9 Memory: 35.2M CGroup: /system.slice/docker.service └─26493 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --- 2. minikube CLI のセットアップ 参考: minikube start | minikube 今回は RPM を使ってセットアップします。 ※ご自身の環境に合わせて選択肢を変更してください。 minikube CLI コマンドのセットアップ # sudo curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-latest.x86_64.rpm # sudo rpm -Uvh minikube-latest.x86_64.rpm minikubeの動作確認 以下の様にroot権限のアカウントではminikubeは起動できませんので専用アカウントを用意します。 確認の為にminikube Driverにdockerを指定してminikube clusterを構築します。 # sudo minikube start --driver=docexitker --- * Rocky 8.5 (amd64) 上の minikube v1.25.2 * ユーザーの設定に基づいて docker ドライバーを使用します * 「docker」ドライバーは root 権限で使用すべきではありません。 * If you are running minikube within a VM, consider using --driver=none: * https://minikube.sigs.k8s.io/docs/reference/drivers/none/ X DRV_AS_ROOT が原因で終了します: 「docker」ドライバーは root 権限で使用すべきではありません。 --- minikube用アカウントを用意する minikube構築用に k8s グループとユーザを作成し、dockerグループに付属させます。 # groupadd k8s # useradd k8s -g k8s -s /bin/bash -d /home/k8s # sudo usermod -aG docker k8s && newgrp docker dockerグループに付属していることを確認 # egrep docker /etc/group --- docker:x:987:k8s --- k8s ユーザに変更し、minikube クラスタ を構築する # su - k8s -c 'minikube start --driver=docker' --- * Rocky 8.5 (amd64) 上の minikube v1.25.2 * 既存のプロファイルを元に、docker ドライバーを使用します * minikube クラスター中のコントロールプレーンの minikube ノードを起動しています * ベースイメージを取得しています... * docker 「 minikube 」 container がありません。再生成します。 * docker container (CPUs=2, Memory=2200MB) を作成しています... * Docker 20.10.12 で Kubernetes v1.23.3 を準備しています... - kubelet.housekeeping-interval=5m - 証明書と鍵を作成しています... - コントロールプレーンを起動しています... - RBAC のルールを設定中です... * Kubernetes コンポーネントを検証しています... - gcr.io/k8s-minikube/storage-provisioner:v5 イメージを使用しています * 有効なアドオン: storage-provisioner, default-storageclass * kubectl が見つかりません。kubectl が必要な場合、'minikube kubectl -- get pods -A' を試してください * 完了しました！ kubectl が「"minikube"」クラスタと「"default"」ネームスペースを使用するよう構成されました --- minikube clusterの作成が可能であることが確認できましたので、作成したminikube clusterを削除しておきます # su - k8s -c 'minikube delete' --- * docker の「minikube」を削除しています... * コンテナー「minikube」を削除しています... * /home/k8s/.minikube/machines/minikube を削除しています... * クラスター「minikube」の全てのトレースを削除しました。 --- 3. Knativeのセットアップ ここまでこればKnative環境を構築するのは簡単です。 Knative環境の構築方法は以下2種類あります。 knative Cli (kn) + Knative quickstart plugin こちらはKnative ServingとKnative Eventingの両方をセットアップしてくれます。 動作が保証された状態でセットアップできることから、環境構築に手間をかけたくない。とりあえずKnative触ってみたいといった人に向いています。 kubectl + YAML こちらはKnativeのInstallページに沿ってKnativeのBrokerやTriggerなど各 コンポーネント をセットアップしていきます。 Knative Serving環境だけ作りたい人や、BrokerやTrigger等の コンポーネント において複数種のソリューションの選択が可能ですので、上記基本セットアップ以外の環境で動かしたい人に向いています。 kubectlコマンドの設置 どちらの構築方法を選択してもkubectlコマンドの設置が必要となりますので、実施します。 # sudo curl -L -o /usr/local/bin/kubectl "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl" # sudo chmod +x /usr/local/bin/kubectl knative Cli (kn) + Knative quickstart pluginによる構築 公式サイトに書かれている方法構築していきます。 Install Knative using quickstart - Knative knativeのバージョン指定 Knativeのバージョンを指定します。 KNATIVE_VERSION='1.4.0' kn(Knative cli )の設置 上記指定したバージョンにてknコマンドを設置します。 # sudo curl -LO https://github.com/knative/client/releases/download/knative-v${KNATIVE_VERSION}/kn-linux-amd64 # sudo mv kn-linux-amd64 /usr/local/bin/kn # sudo chmod +x /usr/local/bin/kn Knative Quickstart Pluginの設置 次にquickstart plugin用コマンドを設置します。 # sudo curl -LO https://github.com/knative-sandbox/kn-plugin-quickstart/releases/download/knative-v${KNATIVE_VERSION}/kn-quickstart-linux-amd64 # sudo mv kn-quickstart-linux-amd64 /usr/local/bin/kn-quickstart # sudo chmod +x /usr/local/bin/kn-quickstart Knative(Serving + Eventing)のセットアップ 一旦 k8s ユーザに切り替えます。 # su - k8s いよいよKnativeのセットアップを行います。 下記ログより minikube clusterの構築 kubectlコマンドの参照先をknative クラスタ を参照させる Knative Servingのセットアップ Kourier Netowrk Layerのセットアップ Knative Eventingのセットアップ をそれぞれ実施しています。 k8s$ kn quickstart minikube --- Running Knative Quickstart using Minikube Minikube version is: v1.25.2 ☸ Creating Minikube cluster... Using the standard minikube driver for your system If you wish to use a different driver, please configure minikube using minikube config set driver <your-driver> * Rocky 8.5 (amd64) 上の [knative] minikube v1.25.2 ! Specified Kubernetes version 1.23.4 is newer than the newest supported version: v1.23.4-rc.0 * docker ドライバーが自動的に選択されました ! あなたの cgroup ではメモリーの設定ができません。 - 追加情報: https://docs.docker.com/engine/install/linux-postinstall/#your-kernel-does-not-support-cgroup-swap-limit-capabilities X 要求された 3072MiB のメモリー割当は、システムのオーバーヘッド (合計システムメモリー: 3684MiB) に十分な空きを残しません。安定性の問題に直面するかも知れません。 * 提案: Start minikube with less memory allocated: 'minikube start --memory=3072mb' * knative クラスター中のコントロールプレーンの knative ノードを起動しています * ベースイメージを取得しています... * Kubernetes v1.23.4 のダウンロードの準備をしています > preloaded-images-k8s-v17-v1...: 505.67 MiB / 505.67 MiB 100.00% 35.55 Mi * docker container (CPUs=3, Memory=3072MB) を作成しています... * Docker 20.10.12 で Kubernetes v1.23.4 を準備しています... - kubelet.housekeeping-interval=5m - 証明書と鍵を作成しています... - コントロールプレーンを起動しています... - RBAC のルールを設定中です... * Kubernetes コンポーネントを検証しています... - gcr.io/k8s-minikube/storage-provisioner:v5 イメージを使用しています * 有効なアドオン: default-storageclass, storage-provisioner * 完了しました！ kubectl が「"knative"」クラスタと「"default"」ネームスペースを使用するよう構成されました 🍿 Installing Knative Serving v1.4.0 ... CRDs installed... Core installed... Finished installing Knative Serving 🕸️ Installing Kourier networking layer v1.4.0 ... Kourier installed... Ingress patched... Finished installing Kourier Networking layer 🕸 Configuring Kourier for Minikube... Domain DNS set up... Minikube tunnel... Finished configuring Kourier 🔥 Installing Knative Eventing v1.4.0 ... CRDs installed... Core installed... In-memory channel installed... Mt-channel broker installed... Example broker installed... Finished installing Knative Eventing 🚀 Knative install took: 3m25s 🎉 Now have some fun with Serverless and Event Driven Apps! --- Knative環境の動作状況を確認する まずは、namespace情報を確認します knative-eventing, knative-serving, kourier-systemができていることが確認できます。 ※kube-node-lease, kube-public, kube-systemはminikubeのnamespaceです。 k8s$ kubectl get namespaces NAME STATUS AGE default Active 9m26s knative-eventing Active 7m27s knative-serving Active 8m26s kourier-system Active 8m1s kube-node-lease Active 9m28s kube-public Active 9m28s kube-system Active 9m28s 次に各deploymentの状況を確認します。全てREADY 1/1となっているか確認します。 ※pingsourceは0/0で問題ありません。 knative-eventingの コンポーネント です。 ChannelはIn Memory Channel(imc-*)が選択されています。 BrokerはMT-Channel-based(mt-broker-*)が選択されています。 $ kubectl get deployment --namespace knative-eventing --- NAME READY UP-TO-DATE AVAILABLE AGE eventing-controller 1/1 1 1 13m eventing-webhook 1/1 1 1 13m imc-controller 1/1 1 1 12m imc-dispatcher 1/1 1 1 12m mt-broker-controller 1/1 1 1 12m mt-broker-filter 1/1 1 1 12m mt-broker-ingress 1/1 1 1 12m pingsource-mt-adapter 0/0 0 0 13m --- knative-servingの コンポーネント です。 networkにkourier network layerが選択されています。 $ kubectl get deployment --namespace knative-serving --- NAME READY UP-TO-DATE AVAILABLE AGE activator 1/1 1 1 16m autoscaler 1/1 1 1 16m controller 1/1 1 1 16m domain-mapping 1/1 1 1 16m domainmapping-webhook 1/1 1 1 16m net-kourier-controller 1/1 1 1 16m webhook 1/1 1 1 16m --- $ kubectl get deployment --namespace kourier-system --- NAME READY UP-TO-DATE AVAILABLE AGE 3scale-kourier-gateway 1/1 1 1 16m --- 環境構築は以上で終了です。 続はいよいよ 構築したKnative on minikubeでServing & Eventing Helloworldを動かすまで(実行編) にて Knative ServingのHelloworldの動作確認 Knative Eventing Helloworldの動作確認 Knative Serving + Eventingを組み合わせたHelloworld を行います。お楽しみに！！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに こんにちは、 id:FM_Harmony です。 ラク スの一部サービスでは iOS 向けのアプリを提供していますが、 今回はそれに関連して、 iOS アプリ開発 のCI/CDについてまとめてみました。 これから iOS アプリ開発 のプロジェクトを始められる方、 既にあるプロジェクトにCI/CDを導入する方の参考になれば幸いです。 なお、「CI/CDとは？」といった部分に関しては、過去の記事に詳しいものがあるため、 そちらをご一読いただいてからこの記事を読まれますと、より理解が深まるかと思います。 tech-blog.rakus.co.jp 目次 はじめに 目次 Bitriseとは fastlaneとは 実例紹介 CI / CD環境について CIの取り組み CI戦略 具体例 CDの取り組み CD戦略 具体例 おわりに Bitriseとは 公式サイトの説明 によればBitriseとは、 Bitriseは、モバイルアプリ開発（iOS、Android、React Native、Flutterなど）に主に焦点を当てたサービスとしての継続的インテグレーションおよびデリバリー（CI / CD）プラットフォーム（PaaS）です。 これは、ソフトウェアプロジェクトの開発と自動化を支援するツールとサービスのコレクションです。 とのことです。 つまり、 スマートフォン 向けアプリでCI/CDを行うための環境を提供してくれるサービス という事です。 他にもCI/CD環境を提供するサービスはありますが、コスト面やワークフロー *1 の作り易さから、 Bitriseの採用に至っています。 ラク スにおけるBitriseの利用についても、過去の記事がありますので、 よろしければ併せてご一読ください。 tech-blog.rakus.co.jp fastlaneとは こちらも 公式サイトの説明 によれば、fastlaneとは、 fastlane is the easiest way to automate beta deployments and releases for your iOS and Android apps. It handles all tedious tasks, like generating screenshots, dealing with code signing, and releasing your application. とのことです。 つまり、 スマートフォン 向けアプリのリリースに関するタスクを自動化するためのツール という事です。 リリースだけでなく、自動テストやレポーティングといった機能も備えています。 BitriseだけでもCI/CDは行えるのですが、Bitriseがトラブルで利用できないときや、 コミット前にローカルでテストを動かしたいときを考え、 ビルドツールとしてfastlaneを使う ビルド環境としてBitriseを使う というように使い分けをしています。 実例紹介 CI / CD環境について 以下は、ある スマートフォン 向け アプリ開発 におけるCI / CDの環境構成の例になります。 図1：CI/CD環境 プロジェクトは社内のGitLabで管理しており、開発者がコードのプッシュ等を行うと、 Bitriseでビルド用の 仮想マシン が作成されます。 その 仮想マシン にプロジェクトの ソースコード をクローンして、 fastlaneでのテストやビルドを行うといった構成です。 ビルドの終了時にはGitLabのPipelineに成功/失敗が通知されますが、 同時に社内のチャットツール（mattermost）にも通知されるようにしています。 これにより、開発者がGitLabを確認せずともCIの完了を把握できるようにしています。 図2：チャットツールへの通知例 では、具体的にCI / CDとしてどういったことを行っているか紹介します。 CIの取り組み CI戦略 CIとしては、例えばfastlaneで以下を実行しています。 SwiftLint による静的解析 XCTest による ユニットテスト ユニットテスト については、 Xcov でその カバレッジ を集計するようにしています。 基本的にはGitLabのマージリク エス ト（MR）が作成、MRへコミットがプッシュされたタイミングで、 上記を行うようにしています。 というのも、2022年5月現在で利用しているBitriseのプランは、 同時に1ワークフローのみ実行可能なものであるためです。 Bitriseを利用しているプロジェクトはいくつか存在し、プッシュされるたびにワークフローを実行すると、 他プロジェクトのワークフローが待ち状態になることがあります。 それを避けるため、ワークフローの実行は必要最小限にしています。 ただし、masterブランチやリリース用のブランチは デグレード が発生した場合に速やかに修正する必要があるため、 コミットのプッシュごとにCIを実行しています。 図3：GitのブランチとCI戦略の関係 具体例 では、CIの実行例を見てみましょう。 CIが行われたとき、fastlaneにより実行結果のレポートが作成されます。 これにより、CIが失敗したときにその失敗理由を確認することが出来ます。 また、CIが失敗した際は Danger により、失敗した箇所がMRにコメントされます。 fastlaneにより作成されたレポートはBitriseに保存されるのですが、Dangerも利用することで、 原因が簡単に分かるものは、MRのコメントを基にコードを修正する 詳細な原因を知りたいものは、Bitriseに保存されたレポートを基にコードを修正する というようにでき、簡単なものであればBitriseとGitLabを行ったり来たりしなくても済むようにしています。 図4：Dangerによる静的解析のコメント例 さらに、 ユニットテスト の カバレッジ もDangerによるコメントを行っています。 これにより、 ここはカバーできているのでOK ここはこういった理由でカバーしなくてもOK といった情報を、MRのコメントでレビュワーに伝えています。 図5：Dangerによる カバレッジ のコメント例 CDの取り組み CD戦略 CDとしては、例えばfastlaneで以下を行っています。 アプリのバージョン番号変更 Test Flightへのアプリアップロード ただし、以下の理由により必要なタイミングでのみ実行出来た方が都合がよいため、 CIと違って自動実行ではなく、手動でBitriseのワークフローを実行しています。 バージョン番号変更はファイルのコミットを伴う アップロードに伴って変更されたビルド番号も含めた状態で、プロジェクトにタグを打つ運用になっている また、事前にリリース時期の社内調整が必要なことがほとんどであるため、 アップロードしたアプリの公開も手動で行っています。 具体例 こちらも具体例を見てみましょう。 あるプロジェクトではそのバージョンの開発が完了すると、 成果物がコミットされたmasterブランチをreleaseブランチへマージし、 バージョン番号を変更するという運用を行っています。 バージョン番号変更においては、 fastlane-plugin-versioning を利用しています。 以前はInfo.plistに設定された値を修正してバージョン番号を更新していたのですが、 Xcode 11よりBuild Settingに設定を行うようになりました。 fastlane-plugin-versioningはバージョン番号を渡すと、その辺りを考慮して適切に設定値を更新してくれるため、 バージョン番号変更に利用しています。 その後、プロジェクト全体の 結合テスト 等を経てリリース準備が完了すると、 releaseブランチでビルドしたアプリを署名してTest Flightへアップロードし、審査に提出しています。 このアプリビルドやアップロードについては、fastlaneで用意された機能を利用しています。 具体的には、 ビルド： gym 署名： match アップロード： Pilot を利用するといった構成です。 また、アップロードに App Store Connect API を利用することで、 2段階認証を行うことなくBitriseからのアプリアップロードを行えるようにしています。 おわりに いかがでしたでしょうか。 個人的な感想になりますが、CI/CD環境の整備により、 実装コードに対する安心感が向上する アプリビルドやアップロードの間もローカルマシンで別のことを行える といった点で、それまでと比べて開発環境が改善されたと感じています。 今回の記事が iOS アプリでCI/CDを行う際の一案として、みなさまの参考になれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com *1 : Jenkinsのジョブのようなもの

こんにちは、negimixです。 ファイルやデータベースなど、各所に散らばっているデータをデータベースに集約して活用したいなぁと漠然と思っていました。 単純にデータを読み込んで、データベースに登録するプログラムを作ればいいんですが、今回はEmbulkを使ってみたので、Embulkの利用方法を紹介したいと思います。 　 【目次】 Embulkとは Embulk環境構築 サンプル実行 データをデータベースに登録 まとめ Embulkとは Embulkは、さまざまなストレージ、データベース、NoSQL、 クラウド サービス間のデータ転送を支援する並列バルクデータローダーです。 必要に応じて プラグイン を利用することで自由に拡張することが可能です。 Embulk環境構築 環境は以下の状態からはじめました。 OS Rocky Linux release 8.5 Java openjdk version "1.8.0_332" https://www.embulk.org/ Embulk公式ページの　 Quick Start 　をそのまま実行します。 curl --create-dirs -o ~/.embulk/bin/embulk -L " https://dl.embulk.org/embulk-latest.jar " chmod +x ~/.embulk/bin/embulk echo ' export PATH="$HOME/.embulk/bin:$PATH" ' >> ~/.bashrc source ~/.bashrc 0.9.24 　がインストールされました。 embulk --version embulk 0 . 9 . 24 サンプル実行 Embulkにはサンプルが付属されているので、すぐに動作確認が行えます。 ※ CSV ファイルを読み込み、その結果を画面に出力します。 https://www.embulk.org/ こちらも、Embulk公式ページの　 Next steps 　をそのまま実行します。 embulk example ./try1 embulk guess ./try1/seed.yml -o config.yml embulk preview config.yml embulk run config.yml 各コマンドでやっている内容は、概ね以下のとおりです。 1行目：サンプルの展開 ■展開後 tree ./try1 ./try1 ├── csv │ └── sample_01.csv.gz └── seed.yml 1 directory, 2 files 2行目：seed.ymlを元にconfig.ymlを生成 seed.ymlの　 path_prefix 　のファイルの中身を参照してconfig.ymlを作成してくれます。 ■seed.yml in : type : file path_prefix : './try1/csv/sample_' out : type : stdout ■config.yml ※サンプルではいい感じにconfig.ymlが生成されていますが、実データでは上手く生成されない場合があります。 　例) 参照したファイルに列名が無い場合 　その際は、config.ymlを直接編集する必要があります。 　また、追加で設定が必要な場合もconfig.ymlを直接編集してください。 in : type : file path_prefix : ./try1/csv/sample_ decoders : - { type : gzip } parser : charset : UTF-8 newline : LF type : csv delimiter : ',' quote : '"' escape : '"' null_string : 'NULL' trim_if_not_quoted : false skip_header_lines : 1 allow_extra_columns : false allow_optional_columns : false columns : - { name : id, type : long } - { name : account, type : long } - { name : time, type : timestamp, format : '%Y-%m-%d %H:%M:%S' } - { name : purchase, type : timestamp, format : '%Y%m%d' } - { name : comment, type : string } out : { type : stdout } 3行目：config.ymlを使ってプレビュー表示 config.ymlの設定があっているか、プレビューで確認します。 ■プレビュー表示 +---------+--------------+-------------------------+-------------------------+----------------------------+ | id:long | account:long | time:timestamp | purchase:timestamp | comment:string | +---------+--------------+-------------------------+-------------------------+----------------------------+ | 1 | 32,864 | 2015-01-27 19:23:49 UTC | 2015-01-27 00:00:00 UTC | embulk | | 2 | 14,824 | 2015-01-27 19:01:23 UTC | 2015-01-27 00:00:00 UTC | embulk jruby | | 3 | 27,559 | 2015-01-28 02:20:02 UTC | 2015-01-28 00:00:00 UTC | Embulk "csv" parser plugin | | 4 | 11,270 | 2015-01-29 11:54:36 UTC | 2015-01-29 00:00:00 UTC | | +---------+--------------+-------------------------+-------------------------+----------------------------+ ※Embulk自体のログは省略しています。 4行目：config.ymlを使って実行 ■実行結果 ※出力先(out)が　 stdout 　になっているので画面に実行結果が出力されます。 1,32864,2015-01-27 19:23:49,20150127,embulk 2,14824,2015-01-27 19:01:23,20150127,embulk jruby 3,27559,2015-01-28 02:20:02,20150128,Embulk "csv" parser plugin 4,11270,2015-01-29 11:54:36,20150129, ※Embulk自体のログは省略しています。 データをデータベースに登録 サンプルでは、 CSV ファイルを読み込み、その結果を画面に出力しました。 ここでは、結果をデータベースに登録したいと思います。 データベースは、普段利用している PostgreSQL を利用します。 環境は以下のとおりです。 PostgreSQL psql ( PostgreSQL ) 12.9 実施する作業 Embulkに postgreSQL 出力用 プラグイン を導入 プラグイン は、 embulk-output- postgresql を使います。 embulk gem install embulk-output-postgresql postgreSQL 出力用config.ymlを作成 サンプルで利用したconfig.ymlを利用して postgreSQL 出力用config.ymlを作成します。 ファイル名は、config_ postgresql .ymlにしました。 出力先(out)の設定を PostgreSQL 用に変更しています。 詳しい設定内容については、embulk-output- postgresql の　 README 　を参照ください。 https://github.com/embulk/embulk-output-jdbc/tree/master/embulk-output-postgresql ■config.yml と config_ postgresql .ymlの差分 diff -u config.yml config_postgresql.yml --- config.yml +++ config_postgresql.yml @@ -15,10 +15,19 @@ skip_header_lines: 1 allow_extra_columns: false allow_optional_columns: false + default_timezone: Asia/Tokyo columns: - {name: id, type: long} - {name: account, type: long} - {name: time, type: timestamp, format: '%Y-%m-%d %H:%M:%S'} - {name: purchase, type: timestamp, format: '%Y%m%d'} - {name: comment, type: string} -out: {type: stdout} +out: + type: postgresql + host: localhost + user: postgres + password: {パスワード} + database: embulk + table: embulk_postgresql_sample + default_timezone: Asia/Tokyo + mode: truncate_insert ※登録時に、timezoneの違いにより、日時がずれるため　 default_timezone 　を追加しています。 Embulkを実行 ■Embulk実行前( PostgreSQL ) embulk = # \ d リレーションが見つかりませんでした。 embulk = # ■Embulk実行 embulk run config_postgresql.yml ■Embulk実行後( PostgreSQL ) テーブルが作成されています。 ※事前にテーブルを作成して、データを登録することも可能です。 embulk = # \ d リレーション一覧 スキーマ | 名前 | 型 | 所有者 ----------+--------------------------+----------+---------- public | embulk_postgresql_sample | テーブル | postgres ( 1 行 ) embulk = # embulk = # \ d embulk_postgresql_sample テーブル " public .embulk_postgresql_sample " 列 | 型 | 照合順序 | Null 値を許容 | デフォルト ----------+--------------------------+----------+---------------+------------ id | bigint | | | account | bigint | | | time | timestamp with time zone | | | purchase | timestamp with time zone | | | comment | text | | | embulk = # データも登録されています。 embulk = # select * from embulk_postgresql_sample; id | account | time | purchase | comment ----+---------+------------------------+------------------------+---------------------------- 1 | 32864 | 2015 - 01 - 27 19 : 23 : 49 + 09 | 2015 - 01 - 27 00 : 00 : 00 + 09 | embulk 2 | 14824 | 2015 - 01 - 27 19 : 01 : 23 + 09 | 2015 - 01 - 27 00 : 00 : 00 + 09 | embulk jruby 3 | 27559 | 2015 - 01 - 28 02 : 20 : 02 + 09 | 2015 - 01 - 28 00 : 00 : 00 + 09 | Embulk " csv " parser plugin 4 | 11270 | 2015 - 01 - 29 11 : 54 : 36 + 09 | 2015 - 01 - 29 00 : 00 : 00 + 09 | ( 4 行 ) embulk = # まとめ 環境構築からデータベースへの登録を紹介しました。 今回は、 プラグイン を1つだけ利用しましたが、他にも入出力、フィルタ等の プラグイン が用意されています。 https://plugins.embulk.org/ 拡張性もあり、大量のデータ処理にも向いているため、今後より活用できる機会を探っていけたらと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

プロジェクトマネジメント とは Quality：品質マネジメント Cost：費用マネジメント Delivery：納期マネジメント プロジェクトマネージャーに必要な3つのスキル ①. 管理スキル ②. コミュニケーションスキル ③. 問題解決スキル プロジェクトマネジメント 関連資格 プロジェクトマネージャ試験（PM） PMP（Project Management Professional） おすすめ書籍 終わりに 技術広報の yayawowo です。 PM（プロジェクトマネージャー）という言葉を聞いたことがある人は多いと思います。 では、具体的に何をしているのかを説明できますでしょうか？ 本記事では、プロジェクトマネジメントの基本的な内容をはじめ、 プロジェクトマネジメントに必要なスキル・関連資格や書籍をご紹介させていただきます！ ◆ 関連ブログも合わせてご確認ください！ ・ 仕様書 とは 【まとめ】 ・ PMBOK とは【まとめ】 ・ 要件定義 とは【まとめ】 ・ プロジェクトマネジメントTips 20選　～現場から語るプロマネの極意～ ・ PdM （プロダクトマネージャー）とは 【まとめ】 プロジェクトマネジメント とは プロジェクトマネジメントとは、期間が定められたプロジェクトの達成/成功に向けて進捗、品質、コストを管理しコン トロール していくことです。 重要となる役割の方がプロジェクトマネージャー（PM）や、プロジェクトマネジメントオフィス（PMO）、プロジェクトリーダー（PL）等が挙げられます。 また、プロジェクトマネジメントをする上で重要となるのがQCDです。 Q（Quality：品質マネジメント） C（Cost：費用マネジメント） D（Delivery：納期マネジメント） QCDについて簡単に触れてみましょう。 Quality：品質マネジメント QCDの中でも重要とされているのが、「Quality：品質マネジメント」です。 ユーザーから要求された品質を担保していない成果物は、ユーザー満足度・信頼度の低下を招いてしまいます。 クオリティファーストという言葉があるように、優先して達成すべき指標となります。 Cost：費用マネジメント プロジェクトを進める中で、計画外の無駄なコスト発生は言語道断です。 また、大規模プロジェクトを担当する場合は多数の ステークホルダー と長期的な関係を築くため、慎重な費用計画と管理が必要となります。 費用を適切に管理しながら、高い品質の成果物を作成できるかが重要となります。 Delivery：納期マネジメント 納期内に成果物を納品することもプロジェクトマネジメントの上では、大切なことです。 もし納期内に収めることが出来ない場合は、ユーザーからの信頼度の低下や会社間のトラブルを引き起こしてしまう可能性があります。 計画を行う上では、各工程内での遅延リスクを考慮しつつ、余裕を持った計画を練ることが必要です。 プロジェクトマネージャーに必要な3つのスキル ①. 管理スキル プロジェクトマネージャーは前述したQCDの通り、スケジュールや予算を管理する能力が求められます。 プロジェクトを遂行する中で、全体スケジュールの把握は重要であり、作業時間・作業人数などを想定し、各工程の 進捗管理 を行っていきます。 スケジュールや 進捗管理 を整理する際、良く利用されているのが WBS （Work Breakdown Structure）です。 プロジェクト完了までの全作業を出来るだけ抜け漏れなく洗い出し、 進捗管理 を怠らないようにしましょう。 また、限られた予算内でプロジェクト完遂且つ、可能な限りの利益を出すための予算管理スキルも求められます。 ②. コミュニケーションスキル プロジェクトマネージャーは、コミュニケーションスキルも欠かせません。 プロジェクトオーナーやチームメンバーが意見を出しやすくするための環境づくりだけでなく、チームメンバーの育成もプロジェクトを遂行していく中ではとても大切です。 密なコミュニケーションをとり、プロジェクトの成功に結び付けましょう。 ③. 問題解決スキル プロジェクトマネージャーは、プロジェクト遂行時に発生する問題に立ち向かうため、問題解決スキルが重要となります。 長期的なプロジェクトであれば、トラブル発生はつきものです。 トラブルを軽減するための リスク管理 も重要ではありますが、発生した場合はプロジェクトマネージャーが冷静に原因分析、解決方法を提案する決断力も必要となります。 常日頃から合理的な判断ができるよう、問題解決スキルを身につけておくと良いと思います。 プロジェクトマネジメント 関連資格 プロジェクトマネージャ試験（PM） IPA 独立行政法人 情報処理推進機構 が運営している試験です。 www.jitec.ipa.go.jp 年1回秋期に実施が予定されており、プロジェクトマネージャーを目指す方に最適な資格となります。 対象者像は以下の通りです。 １．対象者像 高度IT人材として確立した専門分野をもち、 システム開発 プロジェクトの目標の達成に向けて、責任をもって、プロジェクト全体計画（プロジェクト計画及びプロジェクトマネジメント計画）を作成し、必要となる要員や資源を確保し、予算、スケジュール、品質などの計画に基づいてプロジェクトを実行・管理する者 　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　引用元： IPA - プロジェクトマネージャ試験(PM) 情報処理の基本をはじめ、プロジェクトマネジメントの実務レベルの幅広い知識が問われるため、プロジェクトマネジメントのスキル指標として受験されてみてはいかがでしょうか？ PMP （Project Management Professional） プロジェクトマネジメント協会（Project Management Institute, Inc.）、通称PMIが資格認定を行うプロジェクトマネジメントに関する国際資格です。 www.pmi-japan.org 本資格習得に伴い、期待できる効果は以下の通りです。 PMP ® 取得により期待できる効果 ● スキルアップ 体系的な仕事の進め方が身につくため、飛躍的に業務の効率化が図れます。 また、ご自分の経験を体系的なプロジェクトマネジメントの方法論として再整理できます。 ●キャリアアップ この資格の取得によって社内外に対してプロジェクトマネジメントの専門性を証明できます。 資格認定後は、名刺への資格名称の記載が可能となります。 ●人的ネットワークの拡大 PMのコミュニティでの活動を通して、人的なネットワークを広げることも可能です。 　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　引用元： PMI Japan - PMI® 試験・資格について プロジェクトマネジメントの国際資格を取得してみたい！という方は、是非ご検討ください！ おすすめ書籍 初心者向けのプロジェクトマネジメントのおすすめ書籍を並べてみました。 学習の一助となれば幸いです。 『マンガでわかるプロジェクトマネジメント』 漫画で読みやすくプロジェクトマネジメントについてまとめられています。 基本となる手法や用語が分かりやすく解説されております！ これから学習を始めたい！という方にオススメの一冊です。 『「プロジェクトマネジメント」実践講座』 こちらもプロジェクトマネージャーをご担当された際、読んでおきたい1冊です。 「目標設定」「計画」「実行」の3つの視点でまとめられており、図解が多いといった特徴があります。 『プロジェクトマネジメント知識体系ガイド PMBOK (R) ガイド 第7版』 PMBOK とは、プロジェクトマネジメントで必要とされる知識や手法を体系的にまとめた世界標準となります。 2021年11月に第7版が出版され、最新化されました！ 専門的な内容となり量も多いため、プロジェクトマネジメントの辞書として利用することをおすすめします。 ◆ 当社エンジニアマネージャーがまとめた以下記事も是非ご参考ください！ tech-blog.rakus.co.jp 終わりに プロジェクトマネジメントのまとめ記事はいかがでしたでしょうか？ 今回は基本的なことから、必要なスキル等と幅広い内容でまとめさせていただきました。 プロジェクトの成功に向けて、本記事が初めてマネジメントを経験する方や、再度学習される方の一助となれば幸いです。 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

TimescaleDBの特徴 TimescaleDBの機能とライセンス TimescaleDBの開発状況 TimescaleDBのデータ管理 こんにちはヤマウチです。 ラク スではいろいろなサービスで PostgreSQL を使っていますが、ログのような時系列データを PostgreSQL で効率的に管理する方法について調査しました。 ログのような時系列データには以下のような特徴があります。 追記と削除のみで更新は必要ない 時間が経過するにつれデータ量が増える 一方、リレーショナルデータベースには以下の特徴があります。 トランザクション などデータを確実に更新する機能がある 一つのテーブルに大量のデータを保存するとデータの追加や検索が遅くなる 上記のことから時系列データをリレーショナルデータベースで管理すると機能過多かつ処理が遅くなることがあり、代わりにNoSQLが使われることが多くあります。 このような時系列データを PostgreSQL で効率的に扱うための拡張であるTimescaleDBを調査しました。 TimescaleDBの特徴 TimescaleDBは PostgreSQL で時系列データを扱うための 拡張機能 で アメリ カのTimescale社が開発しています。 データ量の多い時系列データを扱うために以下の機能を持っています。 日時カラムでのパーティショニング 古い パーティション の圧縮 また、 PostgreSQL の 拡張機能 として開発されているため以下の特徴があります。 SQL をそのまま使える 圧縮したデータも含めてダンプ・リストアが可能 PostgreSQL の レプリケーション にも対応 TimescaleDBの機能とライセンス TimescaleDBは オープンソース 機能とコミュニティ機能に分かれており、それぞれ Apache License 2.0 と Timescale ライセンスの元で使えるようになっています。 それぞれのライセンスとできることをまとめると、以下のようになっています。 機能 ライセンス できること オープンソース 機能 Apache License 2.0 ・日時カラムでのパーティショニング コミュニティ機能 Timescale License ・圧縮機能 ・ パーティション の並び替え、移動 Timescale License の元で使えるコミュニティ機能は TimescaleDBの機能を使った Database-as-a-Service を提供する場合を除き自由に使えるようになっています。 実際にTimescaleDBを使用する場合はライセンスの原文を確認するようお願いいたします。 TimescaleDB License Agreement | Timescale TimescaleDBの開発状況 OSS を利用する際には開発が活発に行われており、継続して利用できるかが重要となります。 このブログを書いている 2022-04-28 時点のリリース状況は以下のようになっており、活発に開発されていることが分かります。 バージョン リリース日 2.6.1 2022-04-11 2.6.0 2022-02-16 2.5.2 2022-02-09 2.5.1 2021-12-01 2.5.0 2021-10-28 また、v2.5.0ではPostgreSQL14にも対応しており、開発が止まって使えなくなるという心配は当面なさそうです。 Release notes | Timescale Docs TimescaleDBのデータ管理 TimescaleDBでは以下のようにハイパーテーブルとチャンクで時系列データを管理します。 TimescaleDBの アーキテクチャ 実際のデータはチャンクに格納されますが、データの追加や検索をハイパーテーブルに行うことでTimescaleDBが自動的に適切なチャンクに振り分けてくれます。 TimescaleDBでは上記の機能を PostgreSQL の継承によるパーティショニングを使って実現しており、継承によるパーティショニングとの関係は以下のようになっています。 TimescaleDBでの呼び方 継承によるパーティショニングでの呼び方 ハイパーテーブル 親テーブル チャンク 子テーブル また、一定期間を過ぎたチャンクを自動的に圧縮する設定が可能となっています。 圧縮しているかどうかでチャンクに対して実施できる更新操作が変わります。 チャンク 実施できるデータ更新操作 圧縮していないチャンク ・INSERT ・UPDATE ・DELETE 圧縮したチャンク ・INSERT ※UPDATE、DELETEは不可 圧縮したチャンクにはUPDATEはできませんが、ログのような時系列データを格納する場合は更新処理は実施しないため問題となりません。 また、DELETEもできませんが代わりに drop _chunks() という関数が用意されており古くなって不要になったデータはチャンクごと削除する仕組みとなっています。 drop_chunks | Timescale Docs drop _chunks() は内部的に DROP TABLE を実行するのと同じであるため、古いログをDELETEで削除したときのような不要領域が発生せず、かつ高速に処理が行われます。 今後TimescaleDBを使ったログ管理を検証していく予定です。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに 皆さん初めましてseahoseTです。 今回はコンピュータプログラムの記述・編集を行うための ソースコード エディタの一つ『 Visual Studio Code 』、通称『 VSCode 』の最新のインストール事情について紹介していこうと思います。 VSCode のインストールについての過去の記事は Visual Studio Code のインストールと日本語化まとめ をご覧ください。 もくじ はじめに VSCodeとは ここがすごいよVScode ソースコードエディタの歴史 Vim Sublime Text Atom VSCode VSCodeをインストールしてみる(Windows) VSCodeの日本語化 webバージョンのVSCode おわりに VSCode とは VSCode とは Microsoft 社が提供している ソースコード エディタです。 Windows だけでなく、 MacOS や Linux にも対応しておりはたまたweb版もリリースされており開発環境に関わらず使用することが出来ます。 また、 オープンソース なので無料で入手してインストールすることが可能です。 VSCode の最大の利点はその拡張性の高さに有ります。 インストールの初期段階では機能が必要最低限となっており、非常に軽量となっています。 そこに膨大な 拡張機能 の中から好みのテーマやキーボードショートカットを選ぶことが出来、環境設定や使用したい機能を追加することで自分自身独自の ソースコード エディタにカスタマイズすることが出来ます。 また、2019年の調査では数多の ソースコード エディタの中での使用率が最も高い51%が観測されています。 これは二位以下に二倍以上の差をつけており一歩抜き出た人気を持っていることが伺えます。 この人気の秘密は前述した拡張性の高さに起因しているのではないでしょうか。 引用元「 Stack Overflow 」 ここがすごいよ VScode ソースコード エディタの歴史 VSCode の凄さと利便性を語る上で ソースコード エディタの歴史を外すことは出来ません。 なぜこんなにも VSCode のシェアが高く愛用されているのか語っていきます。 (長いので必要のない方は インストール までどうぞ) Vim 多くの GUI ソースコード エディタが存在する中 コマンドライン ベースで動作する『 Vim 』は開発から30年近く経っているのにも関わらず多くの開発者に使用されている ソースコード エディタです。 その特徴は、 高い互換性 にあります。 下位互換性が高いため多くのシステムに採用でき、どこででも利用できること可能です。 　 デメリットとしてもその下位互換性に有ります。 Vim で出来ることは他の ソースコード エディタでもほとんど可能です。 リリース当時と比べPCの性能が向上し当時は無駄としてそぎ落としていた部分が現在ではメリットとしての価値の方が大きくなり、評価されるようになったのです。 また、操作方法に関しては現在の インターフェイス とあまりに乖離があるため、新たに使い始めるにはハードルが高いのが現状です。 Sublime Text 2008年にリリースされた Sublime Text は Linux 、 MacOS 、 Windows で動作する クロスプラットフォーム の先駆けとなる ソースコード エディタです。 クロスプラットフォーム により、これまでにリリースされてきた ソースコード エディタに比べて多くのユーザーを取り込むことに成功しました。 そんな Sublime Textの最大の魅力はその拡張性です。 初期機能は少ないのですが、様々な プラグイン を使用して自分好みにカスタマイズすることが出来ます。この拡張性は VSCode も影響を受けています。 しかし、この ソースコード エディタにもデメリットが存在します。 まず日本語に公式が対応していないことです。この記事を読んでいる方の多くは困ることになるでしょう。 二つ目は追加の 拡張機能 を プラグイン をインストールするためのパッケージマネージャを外部に別のツールとして準備する必要があり、単体で簡潔していないことです。わざわざ二つのアプリを使い分けるのは面倒ですよね。 そして最も大きなデメリットは、プライグイン等々の 拡張機能 が Python でのみ作成することが可能となっている点です。 Python 自体は現在目にすることも多いと思いますが、現存する言語の中で多くのシェアを占めているとは言い切れません。 ポピュラーといった意味ではHTML、 CSS 、 JavaScript の三種が現存する言語の中では最もポピュラーなものとして扱われており、この三種を外すことは 拡張機能 の作成のハードルを上げる一端となってしまいます。追加の 拡張機能 をとしてインストールしようにも作成者がいないのであれば自身で作成するほかなく、手軽さが失われ魅力である拡張性が生かされることはありません。このように専門性が要求されてしまい、魅力である拡張性に関しては将来改良する余地を残していました。 Atom Atom は2014年に Github からリリースされました。 Atom は完成度がとても高く、上記の二つの ソースコード エディタの問題点をカバーしています。 機能追加のためのパッケージマネージャが内部に搭載され、 Atom 自体は JavaScript で作成されています。 拡張機能 はHTML、 CSS 、 JavaScript で作成することが出来、 Sublime Textの問題点であった Python に比べ 拡張機能 を作成する際の参入のハードルが大幅に低くなっています。しかし、そんな Atom も大きな問題を抱えていました。パフォーマンスの悪さです。起動は遅くメモリの消費量がとても多いです。置換処理を行うととても時間が掛かってしまいます。このような点から機能面では他を圧倒していたにも関わらず結果としてはトップシェアを奪うことは叶いませんでした。 VSCode 2015年満を持して登場しましたのが本記事の主題 VSCode です。 VSCode は Atom の問題点を克服しており、現存する ソースコード エディタの中では最終系と言えるでしょう。 設計には Atom と同様にElectronという フレームワーク が採用されており、 拡張機能 の作成にはHTML、 CSS 、 JavaScript が使用可能です。パッケージマネージャは内部に搭載されており利便性はとても高いです。 Sublime Textと同様に初期の機能を少なくすることで軽量化も果たしています。 機能の少なさをカバーするための拡張性の高さ、これを実現する 拡張機能 は Sublime Textから改善されより作成がしやすく流通しやすいようにブラッシュアップされています。 VSCode をインストールしてみる( Windows ) 1. VSCode のダウンロード 「 https://code.visualstudio.com/Download 」からダウンロードが行えます。 自身の環境に合ったものをダウンロードしましょう。 Windows でとくにこだわりが無ければ「 Windows 」を選択でOKです。 下の項目が気になる方のために簡単に各項目の説明を記載しておきます。 64/32bit OSの処理機能別の VSCode インストーラ です。 自身のPCの性能に合わせてお選び下さい。 「 Windows 」を選択すれば自動で判別してくれるので何か特別な意図が無い限りは選択する必要はありません。 ARM スマートフォン ・ タブレット などの携帯端末用で VSCode のインストールを行うための インストーラ です。 User Installer 「User Installer」を用いてインストールを行うと現在使用しているユーザーアカウントでのみ VSCode が使用可能になります。 System Installer 「User Installer」を用いてインストールを行うとPC内全てのアカウントで VSCode が使用可能になります。 インストールには管理者権限が必要です。 .zip 所謂ポケット版です。 VSCode をインストール不要で使用することが可能ですが、アップデートなどの機能が無いので VSCode の最新版は都度ダウンロードを行う必要があります。 他の環境の方は Windows の右にあるアイコンから、 Linux は真ん中のアイコン Mac は右のアイコンの下を選択してダウンロード、インストールをしてください。 2. VSCode のインストール 1.ランチャーを起動して同意を選択する 2.インストール先を指定する VSCode のインストール先を決定します。特に何か問題がなければデフォルトでOKです。 3.スタートメニューにプログラムのショートカットを作成 スタートメニューに VSCode のショートカットを作成します。 作成したくない場合は「 スタートメニューフォルダーを作成しない(D )」へチェックを入れましょう。 4.オプションの選択 VSCode をインストールする時に適用したいオプションを設定します。 「 PATHへの追加(再起動後に使用可能 )」の部分は必ずチェックを入れましょう。残りはお好みでどうぞ。 5.インストール設定確認 設定に問題が無いかを確認して VSCode のインストールを開始しましょう。 6.インストール完了 インストール完了です。これからは自由に思い存分 VSCode 生活を堪能してください。 VSCode の日本語化 VSCode は使用している言語を最適に設定してくれる機能があります。 起動した時に出る右下の案内に従って簡単に日本語化が可能です。 VSCode 上右下の「インストールして再起動」を選択すると画面が遷移して自動で日本語の設定を導入、再起動してくれます。再起動後は無事日本語になっています。 一応手動での言語設定の方法も記載しておきます。 1.「Ctrl」+「Shift」+「P」もしくはメニュー欄の「View」から「Coomand Palette」を選択。 2.「Configure Display Language」を選択 「Coomand Palette」に「Configure Display Language」を打ち込んで検索、設定を行います。 2.「Install Additional Language」を選択して使用言語を追加 3.日本語のインストール 4.インストール終了後「Restart」を選択 インストール終了後「Restart」を選択し。再起動が完了すると無事日本語化に成功。 webバージョンの VSCode 実は VSCode はWeb上で使用することが可能です。 インストールが不要で スマホ や タブレット で使用することが出来ます。 各端末で自由に好きなタイミングで ソースコード を書くことが可能です。 下記のURLにアクセスすれば今すぐにでも利用可能です。 https://vscode.dev/ ・・・しかし、世界はそんなに甘くありません。 webバージョンにはアプリケーションとは異なるデメリットが多数存在します。 その中からいくつかご紹介します。 5つのデメリット 1.フォルダが開けないブラウザがある webバージョンの VSCode の場合Edgeと Chrome に関しては問題無く自身のフォルダを利用することが出来るのですが FireFox などでは未対応でフォルダを開くことが出来ません。 2. 拡張機能 が少なく、動作が遅い アプリケーションバージョンとwebバージョンの VSCode は同じ 拡張機能 を使用することが出来ます。 しかし、ほとんどの 拡張機能 はwebバージョンには対応していないのです。 VSCode の魅力である拡張性の高さを活かすことが全くできていません。 また、webバージョンの VSCode の場合アプリケーションバージョンと比較すると明らかに動作が遅いことを感じます。 3.Terminal機能が無い アプリケーションバージョンの VSCode の場合ターミナル上で Windows PowerShell を使用することが可能で python ファイルなどを実行させることなどが可能ですが、webバージョンの VSCode ではこの機能が丸ごと抜け落ちていて使用することが出来ません。 4. webブラウザ の キーバインド と重なってしまう VSCode のショートカットキーを使用しようとするとブラウザ側で別の何かの機能に割り当てられており、うまく動作しないことが多々あります。 5.IntelliSenseの対応パターンが少ない IntelliSenseとはいわゆるオートコンプリートやオートコレクトなどの入力支援機能です。 webバージョンの VSCode はアプリケーションバージョンと比べると対応している用語が非常に少ないです。 また、アプリケーションバージョンだとマウスを合わせるだけで入力支援してくれるがアプリケーションバージョンにはこの機能は存在していません。 細かな箇所を上げればきりがないですが、不便な点がそこそこ目立ちます。 しかし、お手軽さや VSCode のアプリケーションバージョンが利用できない環境においては有用な選択肢であるため覚えておくと後々役に立つかもしれません。 おわりに 今回はソースエディタの VSCode のインストールについて執筆させていただきました。 コードを書こうにも何を使ったらよいかわからない、といった人の助けになればと思います。 ご高覧ありがとうございました。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

技術広報の yayawowo です。 皆様、 「 PMBOK 」 という言葉を聞いたことがありますでしょうか？ プロジェクトマネジメントに携わる方は必ずと言っていいほど聞いたことがあるかもしれません。 初めて聞いた！という方は、是非この機会に覚えていただけますと幸いです。 今回は、プロジェクト達成のための世界標準知識、 「 PMBOK 」 についてご紹介します。 また、 PMBOK の中で重要と言われる 「5つのプロセス」 と 「10の知識エリア」 についても分かりやすくまとめさせていただきましたので、是非ご参考ください！ ◆ 関連ブログも合わせてご確認ください！ 仕様書 とは 【まとめ】 ・ 要件定義 とは【まとめ】 ・ プロジェクトマネジメントTips 20選　～現場から語るプロマネの極意～ ・ PMBOKとは？知識エリアとプロセスの解説 ・ プロジェクトマネジメント とは 【まとめ】 ・ PdM （プロダクトマネージャー）とは 【まとめ】 ■ 目次 プロジェクトマネジメントとは PMBOKとは PMBOKの目標 5のプロセス ① 立ち上げ ② 計画 ③ 実行 ④ 監視・コントロール ⑤ 終結 PMBOK 10の知識エリア 統合マネジメント スコープマネジメント スケジュールマネジメント コストマネジメント 品質マネジメント 資源マネジメント コミュニケーションマネジメント リスクマネジメント 調達マネジメント ステークホルダーマネジメント PMBOK 関連資格「PMP」 終わりに プロジェクトマネジメントとは プロジェクトマネジメントとは、決められた納期に向けて計画を立て、 プロジェクトを成功に導く（コン トロール する）ことを言います。 　 これらのコン トロール を担うのが、プロジェクトマネージャーです。 プロジェクトメンバーだけでなく、スケジュール・リスク・品質など数多くのコン トロール するものがあるため、 プロジェクトマネージャーはとても重要な役割と言えます。 PMBOK とは PMBOK とは、プロジェクトマネジメントで必要とされる知識や手法を体系的にまとめた参考書のようなものです。 云わば、プロジェクトマネジメントの フレームワーク と理解していただければよいと思います。 また、 PMBOK は「Project Management Body of Knowledge」の略称で通称は「ピンボック」と言います。 アメリ カのPMI（Project Management Institute、プロジェクトマネジメント協会）という 非営利団体 が、プロジェクトマネジメントの普及のために作り、現在はプロジェクトマネジメントの世界標準となっております。 PMBOK の目標 PMBOK の目標は、QCDの管理です。 Q（Quality：品質） C（Cost：費用） D（Delivery：納期） QCDを管理するということは、納期を守りながら、高品質で低コストを目的に計画を立て、プロジェクト遂行を行うことを指します。QCD管理を成功させるため、PBMOKでは「5のプロセス」を実行し、「10の知識エリア」を理解することを重要な要素としております。 では、次章にて「5のプロセス」と「10の知識エリア」をご説明していきます！ 5のプロセス PMBOK では、プロジェクト開始～ 終結 までを以下の5プロセスにて定義しています。一つ一つ見ていきましょう。 ① 立ち上げ ② 計画 ③ 実行 ④ 監視・コン トロール ⑤ 終結 ① 立ち上げ プロジェクト開始前に、プロジェクトの認可を得る段階です。 プロジェクトの目的、目標、予算や成果などを定義した上で、 ステークホルダー （利害関係者）から認可を得ます。 ② 計画 プロジェクトの具体的な計画立てを行う段階です。 プロジェクトの目的、目標達成に向けて計画を行い、実行すべきタスクや要員を明らかにします。 ③ 実行 「② 計画」に従い、リソース調達やプロジェクト作業を実行する段階です。 実行プロセスは、計画したリソースを消費する段階であるため結果に応じて計画を再検討する必要があります。 ④ 監視・コン トロール 計画と実態の差異を継続的にチェックし、差異がある場合には解消を図る段階です。 ⑤ 終結 プロセス完了を確認する段階です。 成果物の受け入れだけでなく、次のプロジェクトに向けてプロジェクト遂行中に蓄積されたノウハウや経験を貯めることも重要です。 PMBOK 10の知識エリア 次は、「10の知識エリア」について説明したいと思います。 前述した5のプロセスにて全て必要な知識エリアもあれば、一部のプロセルで必要な知識エリアもあります。 各プロセスにおける必要有無も簡単ではありますがまとめておりますので、是非ご参考ください。 10の知識エリア ①立ち上げ ②計画 ③実行 ④監視・コン トロール ⑤ 終結 統合マネジメント ○ ○ ○ ○ ○ スコープマネジメント - ○ - ○ - スケジュールマネジメント - ○ - ○ - コストマネジメント - ○ - ○ - 品質マネジメント - ○ ○ ○ - 資源マネジメント - ○ ○ ○ - コミュニケーションマネジメント - ○ ○ ○ - リスクマネジメント - ○ - ○ - 調達マネジメント - ○ ○ ○ ○ ステークホルダーマネジメント ○ ○ ○ ○ - 別記事にて PMBOK の詳細版があります。合わせてご確認ください！ tech-blog.rakus.co.jp 統合マネジメント 統合マネジメントとは、プロジェクトの方針決めや、調整を行う分野です。 統合マネジメント以外の9の知識エリアを統合し、マネジメントします。 スコープマネジメント スコープマネジメントとは、プロジェクトの作業範囲（スコープ）を明らかにする分野です。 作業範囲の中に必要な成果物やタスクがあり、プロジェクトの成功に影響するとても重要な分野とされています。 スケジュールマネジメント スケジュールマネジメントとは、 ガントチャート などによりスケジュール管理を行う分野です。 2017年に PMBOK 第6版のリリースに伴い、「 タイムマネジメント 」→「スケジュールマネジメント」に名称が変わりました。 コストマネジメント コストマネジメントとは、プロジェクトにて発生するコストを計画見積もりや予算設定等、費用に関わることを管理をする分野です。 品質マネジメント 品質マネジメントとは、プロジェクトの成果物の品質を管理する分野です。 品質は、作成した成果物の内容がユーザー要求を満たしているかが重要となります。 資源マネジメント 資源マネジメントとは、プロジェクトの成功に向けて、ヒトやモノの資源の調達や管理を遂行できるチームを組織する分野です。2017年の PMBOK 第6版のリリースに伴い、「人的資源マネジメント」→「資源マネジメント」に名称と内容が変わりました。 コミュニケーションマネジメント コミュニケーションマネジメントとは、 ステークホルダー （利害関係者）とのコミュニケーションを円滑化、管理する分野です。単に情報伝達するだけではなく、問題点を解消するために相手の理解を得るところまで求められます。 リスクマネジメント リスクマネジメントとは、プロジェクトを進める中で生じる可能性があるトラブルを予測し、対策を立てる分野です。脅威となるリスクを予防、コン トロール しながら管理/調整することが大切です。 調達マネジメント 調達マネジメントとは、 仕入 れ先や委託先を選定・管理し、調達を行う分野です。 調達の多くは契約が必要となりますが、契約のみが目的ではありません。 仕入 れ先や委託先の選定から納品スケジュールの管理/研修に至るまで調達に関わる全てを管理します。 ステークホルダー マネジメント ステークホルダー マネジメントとは、 ステークホルダー （利害関係者）と重要な情報を管理、伝達する分野です。 2012年に公表された PMBOK ガイド第5版により、「 ステークホルダー マネジメント」は「コミュニケージョンマネジメント」から独立して新しく設定された知識エリアになります。 PMBOK 関連資格「 PMP 」 プロジェクトマネジメントを学習した方が、その評価指標として受験している資格「 PMP （Project Management Professional）」があります。 PMP の試験内容や概要は、以下のPMI本部Webサイトをご参考ください。 PMI本部Webサイト 是非、スキル証明のために受験されてはいかがでしょうか？ 終わりに PMBOK について知識は深まりましたでしょうか？ PMBOK はプロジェクトマネジメントの フレームワーク となりますが、変化が激しい IT技術 の中で PMBOK だけでは対処できない課題も増えてきています。 あくまでも PMBOK は、プロジェクト成功に向けた参考スキルとして捉えていただき、ご自身の経験や会社として蓄積しているノウハウを活用して、効率的なプロジェクト管理を目指していただければ幸いです！ ◆ 当社エンジニア リングマ ネージャがおすすめする書籍 tech-blog.rakus.co.jp 最後までお読みいただきありがとうございました！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 a rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに みなさんこんにちはa_renrenです。 日々、サーバを運用される方であれば、サーバの動作が遅くなったり、不具合が発生した場合、原因を特定するためにコマンドでサーバのリソース状況を確認するかと思います。 リソース状況を確認するコマンドは、topやfreeなど色々コマンドがありますが、今回は、リソース状況の確認でよく使用するsarコマンドについて少しまとめてみました。 はじめに sar コマンドとは sar [ オプション ] <時間間隔> <回数> よく使うオプション リソース状況の確認 CPUの確認 メモリの確認 スワップの確認 ネットワーク情報の確認 ディスクI/Oの確認 まとめ 参考文献 Linux の理解をより深めたい方へ以下関連おすすめブログ ・ ls コマンド 【使い方 まとめ】 ・ find コマンド 【使い方 まとめ】 ・ iptables まとめ【Linux ファイアウォール】 ・ sed コマンド【使い方 まとめ】 ・ vi コマンド【使い方まとめ】 ・ Linuxのファイル操作でよく使うLinuxコマンド ・ 初心者のためのawkコマンド ・ 実務で使える！基本的なシェル（Linux）コマンドの話 ～forとsed～ ・ 【Linux】今振り返りたい、プロセスって何？ 　・ iptables まとめ【Linux ファイアウォール】 sar コマンドとは sarコマンドはとても多機能なコマンドで、CPUやメモリ、ディスクI/O、パケット数、 ロードアベレージ などのさまざまなシステム統計情報を確認することができます。 また、ほかのコマンドと違い、sarコマンドでは現状のリソース状況に加え、過去のリソース状況についても確認することができます。 sarコマンドは、以下のような書式となっています。 sar [ オプション ] <時間間隔> <回数> また、sarコマンドには様々なオプションが用意されており、オプションを使い分けることで一つのコマンドで確認できる情報が変わってきます。 よく使うオプション オプション 説明 -A 全ての項目を表示する -b ディスクの入出力と転送レート情報を表示する -c プロセスの生成回数を表示する -f ログファイルを指定する -n DEV ネットワーク関連の情報を表示する -n EDEV ネットワーク関連のエラー情報を表示する -r メモリと スワップ 関連の情報を表示する -u CPU関連の情報を表示する (オプションがない場合と同様) -P id/ALL CPUごとの情報を表示する -S スワップ の情報を表示する 実際にsarコマンドを使用してリソース状況の確認を行ってみたいと思います。 ※コマンドは CentOS Linux release 8.3.2011の環境で実行しています リソース状況の確認 CPUの確認 CPUの確認では、sar -P ALL オプションをよく使用します。 実際に使用すると以下のように、当日の0時からsarコマンドを使用した時間までのCPUの情報を表示してくれます。 デフォルトでは、10分おきに記録されるようになっているため、10分毎の情報が出力されています。 こちらの記録間隔は /usr/lib/systemd/system/sysstat-collect.timer の OnCalendar=*:00/10 の値を変更することによって変えることができます。 [root@test ~]# sar -P ALL Linux 4.18.0-193.14.2.el8_2.x86_64 (test) 2022年04月06日 _x86_64_ (1 CPU) 00時00分04秒 CPU %user %nice %system %iowait %steal %idle 00時10分04秒 all 0.20 0.00 0.36 0.01 0.01 99.42 00時10分04秒 0 0.20 0.00 0.36 0.01 0.01 99.42 00時10分04秒 CPU %user %nice %system %iowait %steal %idle 00時20分00秒 all 0.14 0.00 0.30 0.00 0.01 99.55 00時20分00秒 0 0.14 0.00 0.30 0.00 0.01 99.55 : 省略 : 16時10分00秒 CPU %user %nice %system %iowait %steal %idle 16時20分00秒 all 0.13 0.00 0.30 0.00 0.02 99.56 16時20分00秒 0 0.13 0.00 0.30 0.00 0.02 99.56 16時20分00秒 CPU %user %nice %system %iowait %steal %idle 16時30分00秒 all 0.12 0.00 0.30 0.01 0.02 99.55 16時30分00秒 0 0.12 0.00 0.30 0.01 0.02 99.55 平均値: CPU %user %nice %system %iowait %steal %idle 平均値: all 0.15 0.01 0.32 0.00 0.02 99.50 平均値: 0 0.15 0.01 0.32 0.00 0.02 99.50 表示されている項目の内容は、以下の通りです。 項目 説明 %user ユーザ(アプリケーション)が使用しているCPU使用率 %nice nice 値が変更されたプロセスがCPUを使用した時間の割合 %system カーネル がCPUを使用している時間の割合 %iowait ディスクI/O待ちの時間の割合 %steal 仮想環境を使用している環境においてゲスト OPS がCPUを割り当てられなかった時間の割合 %idle CPUが処理待ちの状態の時間の割合 過去(今月)の日にちの情報を確認するには、 -f /var/log/sa/sa02 のようにログファイルを指定します。 sa02の 02 は日付を表していますので、こちらの値を 10 にすれば当月の10日の情報を確認することができます。 [root@test ~]# sar -P ALL -f /var/log/sa/sa02 Linux 4.18.0-193.14.2.el8_2.x86_64 (test) 2022年04月02日 _x86_64_ (1 CPU) 00時00分04秒 CPU %user %nice %system %iowait %steal %idle 00時10分05秒 all 0.22 0.00 0.38 0.01 0.02 99.38 00時10分05秒 0 0.22 0.00 0.38 0.01 0.02 99.38 00時10分05秒 CPU %user %nice %system %iowait %steal %idle 00時20分06秒 all 0.15 0.00 0.31 0.00 0.02 99.53 00時20分06秒 0 0.15 0.00 0.31 0.00 0.02 99.53 : 省略 : 23時30分01秒 CPU %user %nice %system %iowait %steal %idle 23時40分02秒 all 0.16 0.00 0.30 0.00 0.01 99.53 23時40分02秒 0 0.16 0.00 0.30 0.00 0.01 99.53 23時40分02秒 CPU %user %nice %system %iowait %steal %idle 23時50分02秒 all 0.15 0.00 0.30 0.00 0.02 99.53 23時50分02秒 0 0.15 0.00 0.30 0.00 0.02 99.53 平均値: CPU %user %nice %system %iowait %steal %idle 平均値: all 0.16 0.01 0.32 0.00 0.02 99.49 平均値: 0 0.16 0.01 0.32 0.00 0.02 99.49 リアルタイムの情報を確認する場合は、以下のようにコマンドの最後に時間間隔を指定すると、その時間間隔でこちらが止めるまで情報を出力してくれます。 回数を指定すると、その回数までリアルタイムの情報を出力してくれます。 以下は、時間間隔を 2 で指定しているため、2秒ごとにCPUの情報を出力しています。 表示に変化をつけるため、sarコマンドを実行した数秒後に、CPUを使用するコマンドを裏側で実行してみました。 すると以下のように、 %idle の割合が減っていき、 %user と %system の割合が増えていっていることが確認でき、リアルタイムの情報を出力していることがわかります。 [root@test ~]# sar -P ALL 2 Linux 4.18.0-193.14.2.el8_2.x86_64 (test) 2022年04月06日 _x86_64_ (1 CPU) 17時12分27秒 CPU %user %nice %system %iowait %steal %idle 17時12分29秒 all 0.00 0.00 0.50 0.00 0.00 99.50 17時12分29秒 0 0.00 0.00 0.50 0.00 0.00 99.50 17時12分29秒 CPU %user %nice %system %iowait %steal %idle 17時12分31秒 all 47.00 0.00 32.50 0.00 0.00 20.50 17時12分31秒 0 47.00 0.00 32.50 0.00 0.00 20.50 17時12分31秒 CPU %user %nice %system %iowait %steal %idle 17時12分33秒 all 58.21 0.00 41.79 0.00 0.00 0.00 17時12分33秒 0 58.21 0.00 41.79 0.00 0.00 0.00 17時12分33秒 CPU %user %nice %system %iowait %steal %idle 17時12分35秒 all 56.72 0.00 43.28 0.00 0.00 0.00 17時12分35秒 0 56.72 0.00 43.28 0.00 0.00 0.00 : : Ctrl + C でコマンドを止めるまで続く メモリの確認 メモリの確認では、sar -r オプションを使用します。 CPUの時と同様、過去情報やリアルタイム情報を確認することができます。 [root@test ~]# sar -r 2 2 Linux 4.18.0-193.14.2.el8_2.x86_64 (test) 2022年04月06日 _x86_64_ (1 CPU) 17時27分06秒 kbmemfree kbavail kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 17時27分08秒 867808 1172680 884240 50.47 3184 428640 3281076 119.25 401436 220864 0 17時27分10秒 867840 1172712 884208 50.47 3184 428640 3281076 119.25 401436 220864 0 平均値: 867824 1172696 884224 50.47 3184 428640 3281076 119.25 401436 220864 0 [root@test ~]# 表示されている項目の内容は以下の通りです。 項目 説明 kbmemfree 空きメモリの容量(KB) kbavail 利用可能なメモリの容量(KB) kbmemused 使用中のメモリの容量(KB) %memused メモリの使用率 kbbuffers バッファの使用量(KB) kbcached キャッシュの使用量(KB) kbcommit システムの動作に必要な事前に確保されているメモリ %commit 総メモリ容量に対する、システムの動作に必要なメモリの割合 kbactive 最近使用されたメモリで、必要のない限り再利用されないメモリの容量(KB) kbinact 最近使用されたメモリで、ほかに用途があれば再利用されるメモリの容量(KB) kbdirty ディスクに書き戻されるのを待機しているメモリの容量(KB) 実際のメモリ使用量は、kbmemused - ( kbbuffers + kbcached ) で求めることができます。 上記の実例の平均では、884,224 - ( 3,184 + 428,640 ) = 452,400KBが実際のメモリの使用量になります。 スワップ の確認 スワップ の確認では、sar -S オプションを使用します。 [root@test ~]# sar -S 2 2 Linux 4.18.0-193.14.2.el8_2.x86_64 (test) 2022年04月07日 _x86_64_ (1 CPU) 13時21分59秒 kbswpfree kbswpused %swpused kbswpcad %swpcad 13時22分01秒 999420 0 0.00 0 0.00 13時22分03秒 999420 0 0.00 0 0.00 平均値: 999420 0 0.00 0 0.00 [root@test ~]# 表示されている項目の内容は以下の通りです。 項目 説明 kbswpfree スワップ 領域の空き容量(KB) kbswpused スワップ 領域の使用量(KB) %swpused スワップ 領域の使用率 kbswpcad スワップ 領域のキャッシュの使用量(KB) %swpcad スワップ 領域のキャッシュの使用率 基本的にメモリに余裕があれば、 スワップ が使用されることはなく、 kbswpused の値が0となります。 恒常的に kbswpused の値が高い状態だと、メモリの容量が足りない可能性が高いため、メモリの見直し等が必要になってくるでしょう。 ネットワーク情報の確認 ネットワークの確認では、sar -n DEV オプションを使用します。 また、sar -n EDEV とするとネットワーク関連のエラー情報を表示することができます。 [root@test ~]# sar -n DEV 2 2 Linux 4.18.0-193.14.2.el8_2.x86_64 (test) 2022年04月08日 _x86_64_ (1 CPU) 11時39分28秒 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 11時39分30秒 virbr0-nic 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11時39分30秒 lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11時39分30秒 virbr0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11時39分30秒 eth0 12.50 0.50 0.73 0.05 0.00 0.00 0.00 0.00 11時39分30秒 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 11時39分32秒 virbr0-nic 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11時39分32秒 lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11時39分32秒 virbr0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11時39分32秒 eth0 18.00 0.50 1.07 0.09 0.00 0.00 0.00 0.00 平均値: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 平均値: virbr0-nic 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 平均値: lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 平均値: virbr0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 平均値: eth0 15.25 0.50 0.90 0.07 0.00 0.00 0.00 0.00 [root@test ~]# 表示されている項目の内容は以下の通りです。 項目 説明 rxpck/s 1秒間当たりの受信パケット数 txpck/s 1秒間当たりの送信パケット数 rxkB/s 1秒間当たりの受信パケットサイズ(KB) txkB/s 1秒間当たりの送信パケットサイズ(KB) rxcmp/s 1秒間当たりの受信圧縮パケット数 txcmp/s 1秒間当たりの送信圧縮パケット数 rxmcst/s 1秒間当たりの受信 マルチキャスト パケット数。 %ifutil ネットワークインタフェースの利用率 ディスクI/Oの確認 ディスクI/Oの確認では、sar -b オプションを使用します。 [root@test ~]# sar -b 2 2 Linux 4.18.0-193.14.2.el8_2.x86_64 (test) 2022年04月08日 _x86_64_ (1 CPU) 12時02分59秒 tps rtps wtps bread/s bwrtn/s 12時03分01秒 0.00 0.00 0.00 0.00 0.00 12時03分03秒 0.00 0.00 0.00 0.00 0.00 平均値: 0.00 0.00 0.00 0.00 0.00 [root@test ~]# 表示されている項目の内容は以下の通りです。 項目 説明 tps 1秒間当たりのI/Oリク エス ト数 rtps 1秒間当たりの読み込みI/Oリク エス ト数 wtps 1秒間当たりの書き込みI/Oリク エス ト数 bread/s 1秒間当たりの読み込みブロック数 bwrtn/s 1秒間当たりの書き込みブロック数 まとめ 今回は、リソース状況の確認でよく使用するsarコマンドについてまとめてみました。 sarコマンドはオプションを使い分けることによって、様々なリソース状況を確認することができ、また、リアルタイム情報に加えて、過去情報も確認できる便利なコマンドということをわかっていただけたかと思います。 sarコマンド以外にもリソース状況を確認できるコマンドはたくさんありますので、ほかのコマンドと今回ご紹介したsarコマンドを合わせて使用して、より必要な情報を得ていただければと思います。 最後までお読みいただき有難うございました。 参考文献 Manpage of SAR sar ファイルの各項目について、改めて調査してみました | SIOS Tech. Lab sarコマンドの使い方 - Qiita エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com