bookmark_borderPrometheusで外部監視(External Monitoring)を行う

研究の実験環境の整備を行う一貫で,Prometheusで外部監視(External Monitoring)を行うことにした.最終的なゴールはHTTPリクエストをあるURLへ送信し,レイテンシ(応答時間)やステータスコードを監視することである.

Blackbox Exporter

外部監視のPrometheus Exporterで有名な実装の1つにBlackbox Exporterがある.このExporterはICMPやTCP, HTTPでヘルスチェックを行い,その結果をエンドポイントでPrometheusに公開する.Blackbox ExporterでHTTPによる外部監視を行うには,アプリケーションにメトリクスを公開するエンドポイント(例: /metrics)を実装する必要となる.今回はアプリケーションへの変更なくヘルスチェック用のHTTPリクエストに関するレイテンシを取得したいため,Blackbox Exporterでは要件を満たせない.

syepes/network_exporter

Prometheus Exporterを探していた際にX(旧Twitter)で@naa0yamaさんに要件を満たせるPrometheus Exporterとしてsyepes/network_exporter (以下Network Exporter)を教えていただいた.実際にUbuntu 22.04.3にインストールした手順を紹介する.このマシンには既にPrometheusを導入済みとする.

インストール手順

(1) Network Exporterをダウンロードする.debパッケージが公開されているためこれを使う.

https://github.com/syepes/network_exporter/releases

$ wget https://github.com/syepes/network_exporter/releases/download/1.7.5/network_exporter_1.7.5_linux_amd64.deb

(2) インストールされたか確認する.

$ which network_exporter
/usr/bin/network_exporter

(3) 起動オプションを確認する.オプション --config を使うと設定ファイルを指定できるとわかる.

$ network_exporter -h
usage: network_exporter [<flags>]

Flags:
  -h, --[no-]help          Show context-sensitive help (also try --help-long and --help-man).
      --web.listen-address=":9427"
                           The address to listen on for HTTP requests
      --config.file="/app/cfg/network_exporter.yml"
                           Exporter configuration file
      --[no-]profiling     Enable Profiling (pprof + fgprof)
      --log.level=info     Only log messages with the given severity or above. One of: [debug, info, warn, error]
      --log.format=logfmt  Output format of log messages. One of: [logfmt, json]
      --[no-]version       Show application version.

(4) 設定ファイル network_exporter.yml を作成する.

conf:
  refresh: 15m
http_get:
  intervals: 1m
  timeout: 5s
targets:
  - name: endpoint1
    host: "https://www.koyama.me/"
    type: HTTPGet

(5) Network Exporterを起動する.

$ network_exporter --config.file="$PWD/network_exporter.yml"
ts=2023-11-19T09:37:08.798Z caller=main.go:56 level=info msg="Starting network_exporter" version=1.7.5
ts=2023-11-19T09:37:08.799Z caller=main.go:58 level=info msg="Loading config"
ts=2023-11-19T09:37:08.799Z caller=main.go:147 level=info msg="Configured default DNS resolver"
ts=2023-11-19T09:37:08.799Z caller=main.go:140 level=info msg="Starting ping exporter" version=1.7.5
ts=2023-11-19T09:37:08.800Z caller=main.go:141 level=info msg="Listening for /metrics on :9427"
ts=2023-11-19T09:37:08.800Z caller=monitor_http.go:104 level=info type=HTTPGet func=AddTargetDelayed msg="Adding Target: endpoint1 (https://www.koyama.me/) in 0s"

(6) CurlでHTTPリクエストを送信して動作を確認する.http_getをプレフィクスにもつメトリクスを返すようになっている.これをPrometheusからポーリングでPullできればよい.

$ curl -s http://localhost:9427/metrics | grep '^http_'
http_get_content_bytes{name="endpoint1",target="https://www.koyama.me/"} -1
http_get_seconds{name="endpoint1",target="https://www.koyama.me/",type="ContentTransfer"} 0.000182125
http_get_seconds{name="endpoint1",target="https://www.koyama.me/",type="DNSLookup"} 0.00397042
http_get_seconds{name="endpoint1",target="https://www.koyama.me/",type="ServerProcessing"} 0.151319333
http_get_seconds{name="endpoint1",target="https://www.koyama.me/",type="TCPConnection"} 0.150696674
http_get_seconds{name="endpoint1",target="https://www.koyama.me/",type="TLSEarliestCertExpiry"} 1.705613539e+09
http_get_seconds{name="endpoint1",target="https://www.koyama.me/",type="TLSHandshake"} 0.154100303
http_get_seconds{name="endpoint1",target="https://www.koyama.me/",type="TLSLastChainExpiry"} 1.705613539e+09
http_get_seconds{name="endpoint1",target="https://www.koyama.me/",type="Total"} 0.460375409
http_get_status{name="endpoint1",target="https://www.koyama.me/"} 200
http_get_targets 1
http_get_up 1

(7) Prometheusの設定ファイルのscrape_configsセクションを編集し以下を追加する.その後,Prometheusへ設定を適用する.

scrape_configs:
  - job_name: 'network_exporter'
    scrape_interval: 15s
    scrape_timeout: 5s
    metrics_path: /metrics
    scheme: http
    static_configs:
      - targets: ['localhost:9427']

(8) Prometheusにメトリクスが格納されたか確認する.メトリクスが追加された.

クエリ言語PromQLを使いグラフを作成できた.

追記: 2023/11/19

Xで@Kawakami_KentoさんからBlackbox Exporterで出来ると教えていただいた.追試をしてみたところ,Blackbox Exporterだけで設定できた.メトリクスを上手く探せていなかっただけのようだった.

PrometheusのConfigの抜粋

  - job_name: blackbox_all
    metrics_path: /probe
    params:
      module: [ http_2xx ]  # Look for a HTTP 200 response.
    static_configs:
      - targets:
        - https://blog.koyama.me/
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: localhost:9115

  - job_name: 'blackbox_exporter'  # collect blackbox exporter's operational metrics.
    static_configs:
      - targets: ['localhost:9115']

Blackbox ExporterのConfig

modules:
  http_2xx:
    prober: http
    http:
      valid_status_codes: [200, 201, 202]
      method: "GET"
      preferred_ip_protocol: "ip4"

メトリクス probe_duration_seconds として保存されていた.

追試でのCurlした結果

おわりに

サードパーティのPrometheus Exporterをはじめて使ったが便利だった.Prometheusに比べてZabbixは公式でサポートしている機能が豊富であることを改めて感じた.使い慣れたソフトウェアを使うのもよいが,たまには使い慣れないソフトウェアを使う経験も必要だと思った.アウトプットすると理解が深まるだけでなく,フィードバックで知識の誤りに気づけてありがたいと改めて感じた.Prometheusの修行が足りないことを痛感した.

bookmark_border履歴書を支える技術

ギークなエンジニアであれば,履歴書を技術を駆使して作成する経験は一度はあると思います.転職を意識して履歴書をこの記事ではこれまでの履歴書を支えてきた技術を紹介しつつ,新たに作成した履歴書を支える技術を紹介していきます.

*最新のビルド済みの最新版の履歴書はこちらです.

背景:履歴書自作の変遷

v0. MarkdownをMacDownでビルド

Markdownで必要な項目を記述し,それをmacOSで動作するMarkdownエディタであるMacDownでPDF ファイルへビルドしていました.この方法の利点は慣れ親しんだMarkdown形式で履歴書を記述できることです.慣れ親しんだフォーマットであるMarkdownは書きやすく便利でした.

Markdown形式にともなう課題は,レイアウトの表現性が乏しいことです.組版システムではないためA4の1ページに収まるようにレイアウトするには,表現力が足りずCSSやTableを使う必要があります.そのため,新たに後述のv1に置き換えました.

v1. AsciiDocをビルド

asciidocで書いた履歴書をGitLabのCIで自動ビルド – koyama’s blog

Markdown形式でレイアウトの表現力にあった課題を解決するため,v1ではAsciiDocを記述形式に採用しました.AsciiDocはMarkdownより書き方は冗長であるものの,Markdownでは不足していたレイアウトの柔軟性が向上しました.AsciiDocはCLIツールでビルドできるため,GitLab CI上にビルドパイプラインを構築しました.スマホからでも履歴書を編集してビルドできるようになりました.

Asciidocで記述した履歴書にも課題がありました.履歴書は頻繁に更新する資料ではないため,履歴書を編集するたびにAsciiDocの文法を調べて記述していました.Markdownで記述していた際には気軽に更新できていた履歴書が,Asciidocに変更してから気軽に更新しにくい状況でした.また,細かな微修正をしたい場合の調整ができないことも課題でした.例えば,1行だけ次のページにはみ出てしまう際に,余白や行間を微修正するのが上手くいかず苦労しました.

v2. 手書きのHTMLをHeadless Chromeでビルド

AsciiDocの表現力の問題を解決するには,細かく指定できるフォーマットや技術が必要だと考えました.LaTeXの採用も検討したものの,LaTeXの処理系が出すエラーへのトライアンドエラーは嫌いなため採用を見送りました.

HTMLは書式を細かく指定でライブラリもあるため表現力が豊富です.これまでHTMLやCSSを使った経験があり編集する際にも記法で困ることがなく適していると考えました.そこで下記のCSSライブラリやアイコンセットを使いHTMLで履歴書を作成しました.

HTMLファイルからPDFファイルをビルドする際にはHeadless Chromeを使いました.たまにFont Aresomeの読み込みに失敗するため,virtual-time-budgetを長めにセットしています.

chrome --headless --disable-gpu --run-all-compositor-stages-before-draw --virtual-time-budget=8000 --print-to-pdf resume.html

GitHub Actions上にCI/CDのパイプラインを構築したため,ビルドからデプロイまでが自動化されています.デプロイ先はGCP上の仮想マシンです.以下はGitHub Actionsの構成ファイルの例です.

name: Build and Deploy
on:
  workflow_dispatch:
  push:
    tags:
      - 20*
jobs:
  build-and-deploy:
    runs-on: ubuntu-20.04
    steps:
      - name: Checkout Code
        uses: actions/checkout@v2
      - name: Setup Chrome
        uses: browser-actions/setup-chrome@latest
      - name: Build pdf with Chrome
        run: |
          chrome --headless --disable-gpu --run-all-compositor-stages-before-draw --virtual-time-budget=8000 --print-to-pdf output.html
          mv output.pdf resume.pdf
      - name: Upload artifacts
        uses: actions/upload-artifact@v2
        with:
          name: Upload CV
          path: resume.pdf
      - name: Install SSH key
        uses: shimataro/ssh-key-action@v2
        with:
          key: ${{ secrets.DEPLOY_SSH_KEY }}
          name: id_ed25519
          known_hosts: ${{ secrets.DEPLOY_SSH_KNOWN_HOSTS }}
          if_key_exists: fail
      - name: rsync over SSH
        run: rsync -avrz -e 'ssh -i ~/.ssh/id_ed25519 -p 2222' resume.pdf user@example.com:/path/to/www

v2ではCSSを使い細かなページのレイアウトや行間を調整できv1の課題が解消しました.一方で,v2で新たな課題が生じました.その課題とは,複数のHTMLタグの修正を手動で個々に行うことです.例えば,職歴リストのデザインの変更に伴いHTMLを変更する必要がある場合を考えます.このとき職歴の要素(職歴)が5件ある場合,5つすべての要素を手動で修正する必要があります.以下のコードは実際のHTMLコードの抜粋です.このように個々の要素の構造がシンプルなHTMLであれば問題ないものの,複雑なタグが入れ子になっている場合,修正に手間がかかりました.

  <div>
    <header class="space-between">
      <strong>ジョブタイトル1</strong>
      <span>2023年1月 - 2023年6月</span>
    </header>
    <span class="org">社名1</span>
    <p>概要</p>
  </div>
  <div>
    <header class="space-between">
      <strong>ジョブタイトル2</strong>
      <span>2023年7月 - 2023年9月</span>
    </header>
    <span class="org">社名2</span>
    <p>概要</p>
  </div>

v3. テンプレートエンジンで生成したHTMLをHeadless Chromeでビルド

v2の課題を解決するためにテンプレートエンジンを導入し,ViewとDataを分離しました.データ自体は設定ファイルに切り出し,テンプレートエンジンから設定ファイルを呼び出す実装としました.これにより,類似したHTMLタグを繰り返し修正する作業が不要になりました.

Go言語の練習する一環でGo言語を使って実装しました.テンプレートエンジンには標準ライブラリに含まれる text/template を使用しています.テンプレートへ割り当てる入力値はYAML形式のファイルから読み込むように実装しました.YAML形式のデータを扱うために gopkg.in/yaml.v3 を使いました.

以下はYAML形式の設定ファイルの例です.必要に応じてYAMLファイルにデータを追加すると,履歴書が更新できます.

name_en: "Tomoyuki KOYAMA"
name_ja: "小山 智之"
github: "tomoyk"
email: "tomoyuki@koyama.me"
website: "www.koyama.me"
education:
  - school_name: "Graduate School of Computer Science, Tokyo University of Technology"
    title: "Master of Computer Science"
    date_begin: "Apr. 2021"
    date_end: "Mar. 2023"
    description: |-
      He belonged to <a href="https://www.tak-cslab.org/">Cloud and Distributed Systems
      Laboratory</a> (Supervisor: Prof. Takayuki Kushida). <br>His study proposes fast
      log search method for distributed tracing.

以下の構造体 ConfigSchemeはYAMLのスキーマをあらわしています.

type Education struct {
        SchoolName  string `yaml:"school_name"`
        Title       string `yaml:"title"`
        DateBegin   string `yaml:"date_begin"`
        DateEnd     string `yaml:"date_end"`
        Description string `yaml:"description"`
}

type ConfigScheme struct {
	NameEn                      string        `yaml:"name_en"`
	NameJa                      string        `yaml:"name_ja"`
	Github                      string        `yaml:"github"`
	Email                       string        `yaml:"email"`
	Website                     string        `yaml:"website"`
	EducationItems              []Education   `yaml:"education"`
	WorkItems                   []Work        `yaml:"work"`
	PublicationRefereedItems    []Publication `yaml:"publication_refereed"`
	PublicationNonRefereedItems []Publication `yaml:"publication_non_refereed"`
}

以下のようにテンプレートファイルで変数を展開するよう記述しました.テンプレートファイルはv2のHTMLファイルを再利用しました.

<section>
  <h2>Education</h2>
  {{ range .EducationItems }}
  <div>
    <header class="space-between">
      <strong>{{ .Title }}</strong>
      <span>{{ .DateBegin }} - {{ .DateEnd }}</span>
    </header>
    <span class="org"><i class="fas fa-university"></i> {{ .SchoolName }}</span>
    <p>{{ .Description }}</p>
  </div>
  {{ end }}
</section>

関連手法

LaTeXやWord, Google Docsを使うことが一般的なようです.YAMLで記述したデータをPDFにレンダリングする方法もありました.paper.cssを使った履歴書もありました.自作する人々は自分と考えることが似ていました.

bookmark_borderCloudflareの障害に関するポストモーテムを読んだ

Cloudflareの障害に関するポストモーテムが公開されていたので読んでみた.

Post Mortem on Cloudflare Control Plane and Analytics Outage

概要

  • DCの電力供給に原因で障害が発生した.
  • 17分間DC内の電力供給が停止していた.
  • 3箇所あるDCのうち残り2つでも継続動作するHAが組んであった.
  • 基本的に冗長構成を組んでいたが,当該DCに依存したサービスが残っていた.

感想

DCレベルで冗長化していても,実際にDC単位で落として試験しなければわからない問題があることに気付いた.カオスエンジニアリングで障害影響なくテストするかは難しいと思った.Disaster Recoveryの観点でどこまで設計するのか,どのようにテストするのかは課題の一つになると思った.このあたりは研究分野として面白いのかもしれない.

bookmark_borderCloudflare Tunnelで自宅のRaspiに外部からSSH

自宅のインターネットプロバイダでは,マンションであるためグローバルIPアドレスがルータに割り当てられない.そのため,グローバルIPアドレスの割り当てられたマシンとトンネリングが必要であった.今回は,Cloudflare Tunnelを使い自宅のネットワークにSSHする踏み台を構築した.

Cloudflare Tunnelの設定方法にはlocally-managed tunnel (CLI)とremotely-managed tunnel (dashboard)がある.今回は前者の方法を使う.基本的にはドキュメントやZennの記事を読みながすすめればよい.今回はアクセス先のエンドポイントのドメインとして remote.example.com を使う.

手順

(1) Raspberry Piにログインしrootで作業する.(systemdのserviceを作成する都合からrootに昇格している.)

sudo -i

(2) cloudflaredをダウンロードしてインストールする.

wget https://github.com/cloudflare/cloudflared/releases/download/2023.10.0/cloudflared-linux-armhf.deb
sudo apt install ./cloudflared-linux-armhf.deb
cloudflared --version

(3) Cloudflare Tunnelを設定していく.

# トンネルを作成
cloudflared tunnel create shina-tun  
# 外部アクセスのドメインとトンネルをルートとして紐づけ
cloudflared tunnel route dns shina-tun remote.example.com
# 作成したルートの確認
cloudflared tunnel route ip show

(4) Configファイルを作成する.

ホームディレクトリのパス ~/.cloudflared/config.ymlに以下のファイルを作成する.

tunnel: <Tunnel ID>
credentials-file: /root/.cloudflared/<Tunnel ID>.json
ingress:
  - hostname: remote.example.com
    service: ssh://localhost:22
  - service: http_status:404

(5) 動作を検証とサービス化を行う.

# 動作の検証
cloudflared tunnel run shina-tun
# systemdのservice化
cloudflared --config /etc/cloudflared/config.yml service install

(6) Systemd Serviceの起動を確認する.

systemctl status cloudflared
systemctl enable cloudflared

(7) CloudflareのWebからアプリケーションを作成する.

Zero TrustのコンソールからSelf-hostedを選ぶ.

以下のパラメータを設定しておく.

  • Application name: Bastion
  • Application domain: remote.example.com
  • Accept all available identity providers: チェックを外す
  • Identity providers: GitHub (以前に設定済み)
  • <Next>
  • Policy name: Bastion Policy
  • Action: Allow
  • Configure rules > Include
    • Selector: Login Method
    • Value: GitHub
  • <Next>
  • Additional settings > Browser rendering: SSH

(8) エンドポイントにアクセスする.

Webブラウザでアクセスすると以下のような画面が表示されUser/PasswordでSSH出来る.

SSHする場合にはマシンにcloudflaredのCLIツールを導入し,~/.ssh/configに以下のような記述を追加する.今回はhomebrewでcloudflaredをインストールしたためドキュメントとパスが異なる.

Host remote.example.com
  User pi
  ProxyCommand /opt/homebrew/bin/cloudflared access ssh --hostname %h

SSHする際に ssh remote.example.com と入力すると自動でWebブラウザが起動し,認証に成功するとRaspberry PiにSSHできる.

感想

ドキュメントが豊富で設定方法が複数あるため少し混乱したものの設定できた.無料で利用できる点が使いやすく便利だと感じた.インターネットフェイシングなエンドポイントがManaged Service経由で利用できるのは便利だと思った.

参考資料

bookmark_borderRFC 7258 Pervasive Monitoring Is an Attackを読んだ

ネットワークのプライバシーに関する議論がなされていた。改めて気になりRFC 7258を読んでみた。

RFC 7258 – Pervasive Monitoring Is an Attack

Attackの定義

In particular, the term “attack”, used technically, implies nothing about the motivation of the actor mounting the attack. The motivation for PM can range from non-targeted nation-state surveillance, to legal but privacy-unfriendly purposes by commercial enterprises, to illegal actions by criminals.

技術面での攻撃という用語は,実行した人物の動機には意味を持たないと書かれている.Pervasive Monitoringを行う動機の例として,対象を限定しない国民の監視や,営利企業による合法でプライバシーに不適切な目的,犯罪者による違法行為があげられていた.

But those standards generally do not address PM, the confidentiality of protocol metadata, countering traffic analysis, or data minimisation.

Pervasive Monitoringとは位置づけられていない行為には,プロトコルメタデータの機密性やトラフィック分析,データの最小化が紹介されていた.

While PM is an attack, other forms of monitoring that might fit the definition of PM can be beneficial and not part of any attack, e.g., network management functions monitor packets or flows and anti-spam mechanisms need to see mail message content. Some monitoring can even be part of the mitigation for PM, for example, certificate transparency [RFC6962] involves monitoring Public Key Infrastructure in ways that could detect some PM attack techniques. However, there is clear potential for monitoring mechanisms to be abused for PM, so this tension needs careful consideration in protocol design.Making networks unmanageable to mitigate PM is not an acceptable outcome, but ignoring PM would go against the consensus documented here. An appropriate balance will emerge over time as real instances of this Making

Pervasive Monitoringの定義に一致する攻撃に含まれない監視もある.例えば,ネットワーク管理機能が次のものを監視する場合は,Pervasive Monitoringに含まれないという.

  • パケットやフロー
  • メールのメッセージを閲覧する必要のあるアンチスパム機構

一部の監視は,Pervasive Monitoringの軽減策の一部になりうると書かれている.TCertificate Transparency [RFC6962] は一部のPervasive Monitoringの攻撃手法を検出できる方法で,PKIの監視が含まれている.

感想

監視がどのような目的でされているかが重要であることを改めて認識した.IPSやWAFに代表されるネットワークセキュリティのアプライアンスを正当な目的で使う分には,Pervasive Monitoringに含まれないように理解した.プライバシーへの配慮の重要性を改めて理解した.

参考資料

bookmark_border遅いアプリがビジネスに与える影響

入門監視(Mike Julian 著, 松浦 隼人 訳, オライリー・ジャパン, 2019)のp.77に記載のあった遅いアプリケーションがビジネスにあたえる影響を深掘りしてみた.ここではWebアプリケーションを対象としており,遅さはWebブラウザ上にコンテンツが表示されるまでを想定している.

ソースを探すのに苦労したため,備忘録のために残しておく.

Aberdeen Research

書籍の本文では,以下の記載があった.

Aberdeen Researchの2010年の研究によると、ページロード時間が1秒遅くなると、平均でページビューが11%、コンバージョンが7%、顧客満足度が16%下がると言われています。Aberdeenは最適なページロード時間は2秒以下で、5.1秒を超えるとビジネスに影響が出始めるとしています.

Mike Julian 著, 松浦 隼人 訳, “入門監視”, オライリー・ジャパン, 2019, p.77

2010年にAberdeen Researchから公開された資料のうち,確認できた資料に以下の記載があった.対応する箇所を明確に探すことができなかった.

100% of the best performing companies experienced an increase in year over year revenue growth compared with only 11% of Laggards

Chris Houpis, “Sales and Marketing Alignment Collaboration + Cooperation = Peak Performance”, Aberdeen Research (2010)

ShopzillaとAmazon

Shopzillaの事例を本文では次のように紹介している.

Shopzillaのページロード時間が6秒から1.2秒に短くなった(https://www.youtube.com/watch?v=Y5n2WtCXz48)ことで、売上げが12%増え、ページビューも25%増えたとしています。またAmazonはロード時間が100ms改善するごとに売上げが1%増えることを突き止めました(http://bit.ly/2y494hq)。

Mike Julian 著, 松浦 隼人 訳, “入門監視”, オライリー・ジャパン, 2019, p.77

Shopzillaに関するYouTubeにアップロードされた動画は以下にあった.動画内の1:21から説明しているスライドでConversion Rate(CVR)が7% – 12%増加したことが説明されており,本文の内容と一致している.スライドの中で6秒から1.2秒に短くなったことやページビューの25%増加は確認できなかった.

Amazonの事例はリダイレクト先のリンクが切れていた.同様の記述は以下の記事にあった.

bookmark_border春から博士後期課程に進学します

はじめに

2023年4月からサポートエンジニアとして働いています.修士卒で新卒入社した社会人1年目です.先日,博士後期課程の入試を受験し合格しました.2024年4月から社会人学生として博士後期課程へ入学します.

分野はコンピュータサイエンス(特にクラウドコンピューティング,ログマネジメント)です.

学部から修士までの間で以下の業績がありました.

  • 査読つき国際会議(英文) 2編
  • 査読つき論文誌(和文) 1編
  • 査読なし研究報告(和文) 2編

主な動機

主な動機は2つあります.それぞれを以降で述べます.

(1) 博士前期(修士)でやり残したことがある.

博士前期で研究活動に取り組み,次第に自分の未熟さに気づくようになりました.関連研究の調査を通じて最先端(state-of-the-art)を知るほど,自分の研究内容がいかに不足しているか次第にわかるようになりました.独創性のある斬新(novel)な研究を目指したいと思いつつ,そのためのスキルが不足していることにもどかしさを感じていました.博士前期課程の2年間では不足を埋めるための時間が圧倒的に足らないことに気づきました.博士前期課程でやり残した研究内容の不足を埋めて,最先端の研究に太刀打ちできるクオリティの研究をしたいという思いから進学しようと決断しました.

(2) 世界的にみれば専門性を高めるうえで博士号は珍しいことではない.

博士前期を修了する直前の3月に国際会議に現地参加し,海外の博士課程の学生が高いモチベーションで研究に取り組んでいることを知りました.彼らの中には,研究者ではなくソフトウェアエンジニアを目指している人もいました.海外の学生と話す機会を通じて,博士号は研究者だけに必要なものではなく,それ以外の仕事をする人にとっても価値のあるものだと気づきました.

その他の理由

指導教員から勧められた.

学部〜博士前期の指導教員から博士後期を博士前期の修了直前にすすめられました.このことがきっかで進学を考えるようになりました.指導教員は,グローバル企業のインドやアメリカにある拠点で仕事をした経験があり,その勧めに説得力がありました.

周囲に博士課程へ進学した方がいた.

会社の同期や一緒にイベントを運営しているメンバー,Twitterで見かけるエンジニアの方々,インターンやアルバイトでお世話になった方々に博士号を取得されている方がいました.そのため,進学することが決してめずらしいことではないという考え方ができました.

FAQ

博士前期(修士)から博士後期へ進学しなかった理由は?

修士1年の終わり頃でその決断ができずにいました.就職活動も修士1年の2月に終えたので,そのまま就職しました.国際会議でもっと早く刺激を受けていれば,そのまま進学していた気がします.

仕事との両立はどうするのか?

しばらく仕事を続けながら研究に取り組む予定です.会社からは研究に対して制限/支援は無さそうなので,業務外の時間に個人として取り組む予定です.進学するにあたりグローバルの法務部門へ利益相反がないかは確認をとりました.

学費はどうするのか?

幸いなことにも会社の給与で学費が捻出できているため,いまのところ金銭面での問題はなさそうです.仕事をやめた場合は奨学金を借りるかもしれません.

進学先はどう決めたか?

学部と博士前期(修士)に在籍していた研究室にしました.当時の指導教員の在任期間が2年しかないため,別の先生に指導教員になっていただきました.

おわりに

博士前期に比べて博士後期は困難が数多くあることが知られています.辛くモチベーションが下がったときに,進学を決意したときの気持ちを思い出すためにもこの記事を書いています.また,博士後期を目指そうと思うどなたかの役に立てば幸いだと思っています.

付録

博士後期課程への進学の参考になったリンクを貼っておきます.

bookmark_border初めて論文が引用された体験

修士2年の最後に書いた論文をGoogle Scholarで検索したところ,被引用数が1になっていた.

Citation: 1 (出典 Google Scholar)

今までに自分の書いた論文が引用される経験がなかった為,引用されたことに驚いた.それと同時に自分の成果が世界中からアクセスでき,第三者から参照されることを改めて実感した.最近,被引用数のスコアであるH-Indexを知っただけに,初めて論文が被引用された経験は嬉しかった.

bookmark_border修士課程を終えて

自己紹介

東京工科大学に学部と大学院をあわせて6年通いました.所属していた研究室はクラウド・分散システム研究室です.高校生ぐらいからネットワークやサーバをはじめとした分散システムに興味があり,個人的にLinuxでWebサーバやDNSサーバを構築していました.大学の入学後もセキュリティ・キャンプやイベントNOCチームへ参加していました.

大学の入学当初

学部1年の入学当初から早く大学を卒業して就職するつもりでした.なぜなら,第一志望でなく浪人して入学したためです.入学当初は大学の良さが分からずにいました.就職を意識していたこともあり, 学部1年から3年まではいくつかの企業でインターンシップやアルバイトに勤しんでいました.特にヤフーでの黒帯インターンシップは自分の目標とするエンジニアに出会えた良い経験でした.企業でのインターンシップやアルバイトの経験を通じて自らの技術力を把握できました.また,就職する際のイメージを具体的にできました.

研究室への配属

ネットワークや分散システムに興味があるため,クラウド・分散システム研究室を選びました.指導教員は企業から大学に着任されたこともあり,グローバルで働いた経験や専門性で尊敬できる方でした.一方で要求されるレベルの高さに配属当初は苦労しました.研究室では個人ごとに半期に1本のテクニカルレポート(2段組み,6-8ページ)の執筆が要求されます.配属されるまで6-8ページにおよぶ技術的なレポートを執筆した経験がなく当初は戸惑いました.振り返るとテクニカルレポートの作成は良い経験だと思います.特に文章や図で的確に説明する能力は向上しました.

大学院(修士課程)への進学

ある程度実務の経験があるため,学部卒である程度のIT企業には就職できる自信がありました.自分の実力を伸ばすために時間とお金を費やして大学院に進学するのも良い良い気がしました.経緯や参考になった書籍は下記の記事で紹介しています.

就職すべきか進学すべきか、それが問題だ | クラウド・分散システム研究室

大学院(修士課程)を振り返り

大学院への進学はとても良い選択でした.特に英語力や専門性,論理的な思考力や精神的な強さが進学前に比べて格段に向上しました.いつも”苦労しながら障壁を超える経験”を繰り返し,成功体験や自信を重ねてきた結果だと思います.

研究のテーマ決めや論文執筆,実験やデータ解析は苦労の連続でした.特に英語で論文を執筆する作業は基礎的な英語のスキルが足らずに苦労した記憶があります.3時間で数行しか書けず挫けそうになったことをよく覚えています.足りない実力は時間でカバーしようと休日も含めて最大限に時間を費やしました.何事も出来ないままにせず,出来るように努力することが大切だと思いました.

インドにあるAmity University Mumbaiの学生との研究プロジェクトも苦労した経験でした.英会話をする経験が少なく最初は大変でした.一方でこのプロジェクトで英語での会話をする機会があったおかげか,ポルトガルで開催された国際会議では英会話への抵抗感がまったくなかったです.インドの学生から学ぶこともありました.インドの学生は成果を残そうとするモチベーションの高いです.彼らはたとえ大学へ進学しても成果物がなければ良い仕事につけないそうです.IT業界のグローバル企業でインド出身者が多い理由が分かった気がしました.

今後の展望

2023年3月に大学院を修了し,2023年4月からAWS Japanに新卒で入社しました.仕事でも分散システムやクラウドに触れていく予定です.大学院でやり残したことはあるため,社会人大学院への進学を考えています.自分が納得いくクオリティの成果を出したい気持ちがあります.ご飯や呑みの機会があればぜひ声をかけていただけると幸いです.

干し芋リスト