PCをキッチンと考える

こんにちは。開発担当のマットです。

私はプログラミングが好きでパソコンをほぼ毎日触っていますが、パソコンを買う時はどんなパソコンを買えばいいのか悩みます。スペックが複雑でどれを買えば1番良いのか見るだけではすぐにわからないからです。

パソコンに詳しくない方はもっと困るのではないかと思います。

でもパソコンに慣れていない方でもパソコンをキッチンに例えて考えると、それぞれのスペックの意味がわかりやすくなるので、この記事でその考え方を紹介したいと思います。

日常に見慣れているキッチンの光景
日常に見慣れているキッチンの光景

CPU

CPUはコンロです。

CPUのスペックで、重要のはクロックスピードだと思います。(だいたい、「GHz」で表記されるもの)
CPUのスピードが速いほど、パソコンの処理が速い。

料理は弱火で温めるより強火で温める方が速いのと同じです。

ガスコンロです。強火で温めると早く終わります。
ガスコンロです。強火で温めると料理が早く終わります。

なお、購入する時、デュアルコア(2コア)とクアッドコア(4コア)の言葉もよく見ることがあります。(最近は6コアも8コアもあります)
これは、コンロのバーナー(火が出るところ)に例えたら良いと思います。

1つのバーナーしかなければ、作りたい料理を1つずつ調理しなければいけません。
複数のバーナーがあれば、同時に複数の鍋を温めることができるので、その分調理が早く終わります。
しかし、調理と同じく複数のバーナーに分けれるレシピ(プログラム)もあれば、そうでもないものもあります。
使っているレシピ(プログラム)が、複数のバーナーを使えるようになっている場合(コンピューター用語では「スレッディング」と言います)、複数のコアを持った方がいいです。そうではない場合、複数のコアがあっても変わりません。

プラグラムがどれほどスレッディングに対応しているかは開発者がそのプログラムのコードを書く時に決めます。何かのオプションをONに切り替えるものではありません。

*上記でクロックスピードが速いほど処理が速いと言いましたが、厳密にいうと1部の処理を省略できるCPUもありますので、場合によってはクロックスピードが遅いCPUは速いCPUに勝つことはありえます。複雑ですね。

容量

容量(だいたい、「TB」や「GB」で表記されるもの)は冷蔵庫と考えていいと思います。
パソコンは使っているうちに多くの画像ファイル、音楽ファイル、アプリケーションなど段々といっぱいになってきます。
しかし容量が大きいほどパソコンに保存できるものが多くなります。

いっぱいになってしまうと、何かを捨てないといけません。
いっぱいになってしまうと、何かを捨てないといけません。

この容量の媒体はディスクと言います。ディスクは2種類あり、SSDとHDです。

簡単にいうと、SSDの方が最新型の冷蔵庫です。中にある具材(データ)が引き出しやすく、多くのファイル、多くのデータを頻繁に使う方には速くていいと思います。しかし、その分値段が高くなります。HDとSSD、両方入っているパソコンもあります。

メモリー

メモリーは「まな板」です。パワフルなコンロと、大きい冷蔵庫があっても、具材を調理する場所が必要ですよね。

例えば、グリーンサラダを作る時、レタス、トマト、キュウリなどを1つずつ冷蔵庫から出して、準備しないといけません。
しかし、まな板が小さいとスペース不足で同時に材料を切るこができず一時的にその切った材料を冷蔵庫(ディスク)に戻さないといけません。この手間で調理の効率が悪くなります。

手元に多くのものを置けると、仕事が楽になります
手元に多くのものを置けると、仕事が楽になります

なお、レシピ(プログラム)によって、まな板のスペースが足りないと具材がこぼれてしまって、調理が大失敗に終わる場合もあります(メモリー不足エラー)。

メモリーは容量の1種類(まな板も冷蔵庫も具材を置くところ)なので、これもGBで表記されます。

まとめ

もちろん、たくさんの技術的な情報を省略しているため完璧な例えではないですが、上記のようにパソコンの部分をキッチンの部分と思って想像するとなんとなくわかりやすくなると思います。

少しでもパソコンの購入に悩んでいる方の力になれたら嬉しいです。

普通自動車免許(AT)を取得した話

こんにちわ。
リエです。

2020年、プライベートで最も頑張ったこと。
それは〈普通自動車免許(AT)を取得したこと〉です🚗🚙

車の免許※以下免許 は学生時代、取るきっかけがなくそのまま社会人となり、
社会人になると周りに免許を持っている人が多くかつ私の行動範囲的に車を運転できなくても困らなかったので、免許欲しいな〜と思ったことは何回かありつつも特に不自由なかったので行動に移すことはありませんでした。

ではなぜ、免許を取ったかといいますと理由は下記となります。
・コロナ社会の現在、車は運転できたほうがいい
・愛犬がドライブが好きなので、私の運転で一緒にドライブへ行きたい←最大の理由

思い立ったら即行動!ということで、自分の通えそうな自動車教習所を探し7月末に入学手続きし8月から教習開始となりました。
ちなみに4月の緊急事態宣言時に教習所も休校していたそうで、その間通えなかった人が後ろ倒しになっており、配車予約が非常に取りづらく卒業まで時間がかかりますと説明を受けました。

コロナ禍の中教習所へ通うのは。。とも少し思いましたが、教習所は感染予防対策をしっかりしてくださっていたので安心して通うことができました。
もちろん私もできる限りの対策をしました!

普通自動車免許(AT)を取得するには以下カリキュラムをこなす必要があります。
①入学説明、運転適性テスト、先行学科1受講
②1段階(所内技能教習12時間以上、学科10時限)
③1段階の修了検定
④2段階(路上技能教習19時間以上、学科16時限)
⑤卒業検定
⑥試験場での学科試験
※それぞれ有効期限があります。

免許取得までかかった期間は約4ヶ月でした。
学科は予約不要だったのでスムーズに受けられましたが、技能(配車予約必須)は最初に説明を受けた通り、予約が全然取れずキャンセル枠を狙うなどスケジュール調整が結構大変でした。

最初に受けたアドバイス

最初に指導員の方から受けたアドバイスは、
・学科を先に終わらしたほうがいい。(受講終わったらすぐに効果測定も受ける)
・技能で補習がついても落ち込まない(補習がつくのは全然普通)
です。

配車予約が全然できなかったので、学科をつめて受講し効果測定もすぐに受けました。
技能はですね、補習つきました。で落ち込みました。。

苦労したこと

私が通っていた教習所は、実は大阪で1番技能が難しいと言われている教習所で、技能教習でかなり苦労しました。。
難しいと言われている理由は道で、1段階の所内コースは狭くて素早い判断が必要、2段階の路上コースは交通量が多くかつ路駐や自転車がめちゃくちゃ多いのです。
右左折が私は苦手で1段階でも2段階でも補習がつきました(´;ω;`)
1段階で全然うまくいかず、指導員の方に理不尽に怒られ、もうやめたいと言いかなり周りに迷惑をかけました。。あのとき慰めてもらっていなかったらまじで教習所やめていたと思います。その説はありがとうございました。
やめたいとなったとき、「教習所やめたい」「つらい」「指導員と合わない」とググって、同じような人が沢山いたことにも励まされました。

幸い社会人をやっていると理不尽なことには慣れっこなので、横で色々言われたときはあおり運転の練習をさせてもらっていると考えて乗り切りました。

雑談

正直、技能に関しては指導員の方との相性もあるかと思います。
私は技能へたくそちゃんでしたが、1段階と2段階ですごくわかりやすく教えてくださる指導員の方だったときはスムーズに教習が進みました。
逆に苦手な教え方の指導員の方のときはうまく進まず。。
私はしませんでしたが、指導員の方との相性でしんどい思いをされている方は1回受付の方へ相談してもいいかと思います。

指導員は安全に車の運転をできるよう知識や技術を教えてくださる方なので、教習生を辞めさそうなんて思ってもいないはずです。
教習生も指導員の方に褒められるために教習を受けているわけではないですしね。

補習がついたときは情けないと落ち込みましたが、指導員の方がいる中でたくさん運転練習できてラッキー!と思うようにしました。
免許取得は競争じゃないので早く取れたからえらいとかないし!

私みたいにどんくさい人間でも免許を取ることができたので、もし免許取得に悩んでいる方はチャレンジしてみてはいかがでしょうか😊
ここでは私がお世話になった教習所の名前は公開しませんが、大阪で教習所をお探しの方はこっそりご連絡ください。教習所名をお伝えしてもし通われるのであれば割引券をお渡しします🎫w

個人的なリモートワークの流儀

こんにちは。まだまだコロナ禍の余談が許さない日々が続きますがいかがお過ごしでしょうか。

ビジネスシーンでは、リモートワークが主流になりつつある中、自宅での生産性を如何に整えるかといった新しい働き方を模索することが重要になってきていますね。

ご家庭がある方は「仕事に集中できる自室を設ける」といった物理的に環境をつくることも重要ですし、オンとオフの境界線が曖昧になるので「自分の終業時間」などのマイルールを決めるなどの精神的な環境を決めることも大切です。

私個人的には、どうすれば「体を動かす」ことができるか、運動する時間が作れるかというのをあれこれ試しています。

体を動かすと集中力が高まる

何かを考えたりアイデアを出さないといけない時に、散歩をすると考えがまとまりやすかったりした経験はないでしょうか?

おいしいものを食べる、人と交流する、褒められるなどすると、側坐核からドーパミンが分泌され、報酬系に作用し、快感が生じます。運動も、ドーパミンの分泌量を増加させるもののひとつです。

集中力は、脳内の報酬系にドーパミンが作用して高まるもの。報酬系は快感を生じさせ、今やっていることに集中させます。その状態でほかの課題に取り組むと、高い集中力を発揮できるのです。

出展:じっとしていても集中力は上がらない。頭を動かす前にまず「体を動かす」べき理由|STUDY HACK

適度な運動は集中力を上げるということが科学的に実証されています。

リモートワークをするようになって思うのですが、これまで煩わしかったオフィスへの通勤も実は仕事モードになるために大切なことだったのではないか?適度に歩く、電車に揺られることが気持ちを切り替えたり、その日のタスクだったりを意識的にまたは無意識的に整理していたりしていたのではないかと。

近所の喫茶店などで仕事をする、個人的な仕事用オフィスを借りているケース以外では、リモートワークに「通勤」は発生しません。ですので、自宅で仕事に取り掛かる前やタスクの区切りなどインターバルに運動を取り入れていく必要があると思うのです。

一番簡単に考えつく運動としては、仕事前にラジオ体操をしてみたり、散歩やジョギング、筋トレといったエクスサイズを行うなどでしょうか。室内でできることはそのまま行えばいいと思うのですが、散歩やジョギングってこの酷暑の炎天下でやろうと思わないですよね。逆に体力を消費しすぎて仕事にならない。では、どうしたらいいのか?

仕事の合間に掃除する

外に出ないで運動するにはどうすればいいか?をあれこれ考えた結果、掃除って運動にならないかな?と思ったのがきっかけ。実践してみたら、これがなかなか良いです。例えば、
・食器を洗う
・洗面所の水垢などの掃除をする
・掃除機で床掃除
・キッチンの油汚れをクレンジングする
etc…

反復動作を伴う掃除作業の後って気持ちの切り替えが結構上手くいくみたいで、その後の作業に集中できます。15分~30分程度の掃除をすると当然汗をかきますし軽度な運動を行ったぐらいの感覚を実感できます。洗い物をしながらアイデアを考えたり、その逆何も考えないこともできますし、掃除をすることで部屋も綺麗になるので一石二鳥なんですよね。

仕事のタスクの区切りやちょっとアイデアが煮詰まったりした時に、散歩もいいですが掃除という選択肢を持っておくと、頭の中も部屋の中もスッキリして次の仕事に集中できてお勧めです。

仕事の合間に「掃除という運動」をする隙間時間を作っていく。仕事の流儀というと仰々しいですが(笑)こんなリモートワークのやり方があってもいいかなって思います。

PrometheusとAlertmanagerでSolrの異常を通知する

はじめに

前回の記事では Prometheus と Grafana による可視化を採り上げました。今回はさらに Alertmanager を組み合わせてメール通知を試してみました。

前回の続きで Solr と Prometheus と prometheus-exporter が動いている前提です。

Alertmanager のインストールと起動

$ wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz
$ tar zxf alertmanager-0.21.0.linux-amd64.tar.gz
$ cd alertmanager-0.21.0.linux-amd64
$ ./alertmanager --config.file=alertmanager.yml

今回はメール通知の動作確認用の alertmanager.yml を作成しました。メール以外にも Slack や Pushover など、様々な通知手段が用意されています。

global:
  resolve_timeout: 5m
  smtp_from: 'solr-alert@example.com'
  smtp_smarthost: 'localhost:25'

route:
  receiver: 'mail_test'

receivers:
- name: 'mail_test'
  email_configs:
    - to: 'alert-receiver@example.com'
      require_tls: false

Prometheus の設定

prometheus.yml でルールファイルを設定

rule_files:
  - "alert_rules.yml"

alert_rules.yml の内容

Solr の Ping API が正常応答しなかったら通知する設定です。

groups:
- name: sample_alert
  rules:
  - alert: solr_test_alert
    expr: absent(solr_ping) == 1
    for: 1m
    labels:
      severity: test
      test_type: SampleAlert
    annotations:
      summary: 'Solr Ping Error'

試してみる

正常な状態では、Prometheus の Alerts のページは以下のような表示です。

ここで Solr のプロセスを落としてみます。しばらく待つと異常を検知してPending状態に入ります。

このまま回復しなければメール通知されます。

受信したメールの内容です。

おわりに

簡単な例でメール通知できるところまで設定してみました。

Prometheus と Alertmanager の組み合わせでは、promQL による条件の記述や振り分けルールの設定などを使ってかなり複雑なこともできるようになっており、Solr 自体の監視だけでなく、インデックスの内容に基づいたアラートも可能です。

Solrのprometheus-exporterにメトリクスを追加する

はじめに

prometheus-exporter に付属の設定ファイル(contrib/prometheus-exporter/conf/solr-exporter-config.xml)には様々なメトリクスの設定例が記載されており、これとGrafanaを組み合わせれば、かなり便利なダッシュボードが作れます。

この記事では、デフォルトの設定に無いメトリクスを自分で追加する場合の設定方法を試してみました。

solr-exporter-config.xmlの内容

SolrのどのAPIを使うかに応じて4つのセクションが用意されています。

  • <ping> PingRequestHandler へのリクエストを利用します
  • <metrics> Metrics APIを利用します
  • <collections> Collections APIを利用します
  • <search> 検索リクエストを利用します

たとえば <ping> セクションは以下のように定義されています。

    <ping>
      <lst name="request">
        <lst name="query">
          <str name="path">/admin/ping/</str>
        </lst>
        <arr name="jsonQueries">
          <str>                                                                                                         
            . as $object | $object |                                                                                    
            (if $object.status == "OK" then 1.0 else 0.0 end) as $value |                                               
            {                                                                                                           
              name         : "solr_ping",                                                                               
              type         : "GAUGE",                                                                                   
              help         : "See following URL: https://lucene.apache.org/solr/guide/ping.html",                       
              label_names  : [],                                                                                        
              label_values : [],                                                                                        
              value        : $value                                                                                     
            }                                                                                                           
          </str>
        </arr>
      </lst>
    </ping>

name=”path” でリクエスト先のパスを指定しています。

ping リクエストの応答をどのように加工するのかを指定しているのが、name=”jsonQueries” の下の str タグに囲まれた領域です。jq クエリが使われているので jq コマンドで動作確認できます。

$ curl --user solr:SolrRocks -s 'http://localhost:8983/solr/test_shard1_replica_n1/admin/ping/' |jq '            . as $object | $object |
>             (if $object.status == "OK" then 1.0 else 0.0 end) as $value |
>             {
>               name         : "solr_ping",
>               type         : "GAUGE",
>               help         : "See following URL: https://lucene.apache.org/solr/guide/ping.html",
>               label_names  : [],
>               label_values : [],
>               value        : $value
>             }
> '
{
  "name": "solr_ping",
  "type": "GAUGE",
  "help": "See following URL: https://lucene.apache.org/solr/guide/ping.html",
  "label_names": [],
  "label_values": [],
  "value": 1
}

searchメトリクスを追加してみる

単純な例ですが、全件検索(‘*:*’による検索)のヒット件数をグラフにしてみます。

solr-exporter-config2.xml に以下を追加します。

    <search>
      <lst name="request">
        <lst name="query">
          <str name="collection">wikipedia</str>
          <str name="path">/select</str>
          <lst name="params">
            <str name="q">*:*</str>
            <str name="start">0</str>
            <str name="rows">0</str>
          </lst>
        </lst>
        <arr name="jsonQueries">
          <str>
            .response.numFound as $value |
            {
              name         : "solr_num_wikipedia_entry",
              type         : "GAUGE",
              help         : "number of wikipedia entry",
              label_names  : [],
              label_values : [],
              value        : $value
            }
          </str>
        </arr>
      </lst>
    </search>

ここで指定した内容は、実際には以下のような検索リクエストになります。

$ curl --user solr:SolrRocks -s 'http://localhost:8983/solr/wikipedia/select?q=*:*&start=0&rows=0'
{
  "responseHeader":{
    "zkConnected":true,
    "status":0,
    "QTime":0,
    "params":{
      "q":"*:*",
      "start":"0",
      "rows":"0"}},
  "response":{"numFound":2264810,"start":0,"numFoundExact":true,"docs":[]
  }}

jq クエリによる加工結果は以下の通りです。

$ curl --user solr:SolrRocks -s 'http://localhost:8983/solr/wikipedia/select?q=*:*&start=0&rows=0' |jq '.response.numFound as $value |
>             {
>               name         : "solr_num_wikipedia_entry",
>               type         : "GAUGE",
>               help         : "number of wikipedia entry",
>               label_names  : [],
>               label_values : [],
>               value        : $value
>             }
> '
{
  "name": "solr_num_wikipedia_entry",
  "type": "GAUGE",
  "help": "number of wikipedia entry",
  "label_names": [],
  "label_values": [],
  "value": 2264810
}

prometheus-exporter によって以下のような Prometheus フォーマットに変換されます。

$ curl -s http://localhost:9854/|grep solr_num_wikipedia_entry
# HELP solr_num_wikipedia_entry number of wikipedia entry
# TYPE solr_num_wikipedia_entry gauge
solr_num_wikipedia_entry{zk_host="localhost:9983",} 2264810.0

ここまで来れば、グラフ化するのは簡単です。下の画像は、データインポートハンドラでWikipediaの日本語全記事を投入したときの、記事数の変化をグラフ化したものです。