EatSmartシステム部ブログ

ウェブサイトの開発や運営に関する情報です。

ImageFluxの導入効果について

以前「ImageFluxの導入について」の記事を掲載しましたが、導入後の効果について報告したいと思います。

eatsmart.hatenablog.com

2018年9月から導入に向けたシステム検証を重ね、本番環境へは2018年10月24日に導入しました。 今回は、導入前・後の1ヶ月間で効果測定してみました。

効果測定条件

効果測定条件は以下の通りです。

  • 測定期間
    変更前 9月23日~10月23日
    変更後 10月24日~11月23日

  • 測定ページ
    240px×240pxのサムネイル画像が8枚表示されているページ

  • 画像の種別
    概ねJPEG(一部pngあり)

  • 1か月のブラウザ利用状況
    safari 50%
    Chrome 25%
    safari(in-app) 10%
    Android Webview 10%
    その他 5%

  • ImageFluxのキャッシュヒット率
    2018年11月のトータルリクエストに対して、キャッシュヒット率は約65%でした。

効果測定結果

上記条件下で、GAにて計測を行ってみました。

ページ速度

導入前・後の1ヶ月間で15%速度改善しました

f:id:eatsmart:20190117210813p:plain

離脱率

導入前・後の1ヶ月間で30%離脱率が改善しました

f:id:eatsmart:20190117205244p:plain

1ヶ月の短期間ですが、グラフからも分かる様にページ速度が向上したことで離脱率が大幅に改善しました。サイトの特性上季節要因等でトラフィックが増減するので、ロングテールでどうなるのか等引き続き検証していきたいと思います。

サーバのディスクを整理した話

あけましておめでとうございます。 本年もEatSmartシステム部ブログをよろしくお願いします。 新年最初の記事としては地味ではありますが、昨年末に行ったサーバのディスク整理について書きたいと思います。

昨年インフラをデータセンターからクラウドへ移行したことは以前書きました。当時のディスク使用量と増加分を見込んで、サーバのスペックの選定を行いました。 年明けからインフラを増強する計画があり、それに伴いディスクの使用量を確認したところ、当初の見込みより増加のペースが早いことがわかりました。 当初の見込みよりペースが早くなった要因は、主に以下の5つでした。

Dockerの不要なイメージ

クラウドへ移行してから、全てのサービスはDockerコンテナで稼働しています。 このため、以前に比べDockerイメージの数が増えたこと、テストや検証に伴いDockerイメージを作成することが増えたことで、ディスク使用量が増えていました。 不要なDockerイメージを削除するため"docker system prune"を実行しました。

docker system prune | Docker Documentation

この作業で、サーバによっては100GB弱の容量を確保することが出来ました。

Jenkinsのビルド履歴

基本的に全てのジョブで"古いビルドの破棄"を指定することにしており、不要なファイルが残らないようにしています。 同様に成果物も保存していません。これはDockerイメージとして残しているためです。 この設定がされていないものがあり、ディスク使用量が増えていました。 正しく設定することで、数GBの容量を確保することが出来ました。

ログの転送漏れ

バッチ処理等で出力されるログファイルは、全てログサーバへ転送し、一定期間が過ぎるとアーカイブされる仕組みになっています。 Dockerコンテナで稼働するバッチ処理で、ログの出力先が以前と変わったために上記の転送対象から外れてしまっていたものがありました。 この他、td-agentで集約するログの対処もされていなかったので、転送と削除を行うようにしました。 これにより、数十GBの容量を確保することが出来ました。

一時ファイルの削除忘れ

各種検証やログ解析のために一時的に作成したファイルが残っていました。 絶対的な量は少ないですが、これも削除しました。

まとめ

サービスは正常に稼働しており、またディスク使用量が閾値より少ない状態だったので、気付くのが遅れてしまいました。 以上の作業で、当初の見込みとほぼ変わらない増加ペースに戻すことが出来ました。

2018年を振り返って

2018年はサービスのシステム開発だけでなく、色々な挑戦や取り組みをした1年でした。 自分にとってどんな1年だったかを振り返ってみたいと思います。

今年やったこと

1月〜3月

iDC移転

今年の前半は何と言ってもiDC移転が一番大きなトピックでした。 計画・準備は2017年後半から取り組んでいたのですが、2018年に入ってからは実行に移すフェーズでした。

eatsmart.hatenablog.com

eatsmart.hatenablog.com

  • DB移行

PostgreSQLのバージョンアップと(全サービスで)レプリケーションの構築を行いました。
また、データ移行については、
 ・旧DB→新DBへのWAN越しレプリケーションを構築し、移行時切り替え
 ・事前移行+当日差分移行(Postgresql DB移行 - EatSmartシステム部ブログ)
の2種類の移行を行いました。

  • サービス移行

サービスの環境としては、dockerコンテナ化(swarmモード)という大きなチャレンジをしました。swarmに関しては一部動作が不安定な事があったので、その後使用をやめました。(kubernetesを選んでいたら違っていたかも?)
サーバー筐体もOSも仕組みも全て刷新されるので、安定性と性能のテストはしっかりして、安心できるようにしました。

4月〜6月

移転後環境の安定化

iDCの移転自体は、失敗する事なく完了したのですが、その後の稼働安定化に対応していました。

  • 各サーバーのリソースチューニング

CentOS5からubuntu16+dockerになる事で、今までの知識が単純には使えなかったので、色々と調査しながら対応しました(以前が古すぎただけですが)。

  • 諸々のモニタリング構築

元々zabbixでモニタリングをしていたのですが、OSの変更やdockerコンテナ化などの構成の変化によるメトリクス取得の変更を色々としました。

  • nginxによるリバースプロキシ+swarmのローリングアップデート問題

サービスの入り口にnginxのリバースプロキシを置き、その後ろにswarmでクラスタする事で冗長性と可用性を実現しようとしていたのですが、swarmのローリングアップデート時にリバースプロキシに失敗するという現象がありました。また、本番環境ではないのですが、swarmのマネージャーが無応答になることがあるなど動作に不安があったので、swarmでのクラスタをやめ、アプリケーションサーバーによるクラスタに変更しました。

  • dockerコンテナのpublish portガバガバ問題

dockerコンテナで外部にポートをpublishすると、UFWfirewallを解放するので、今回のさくらインターネットのサーバーのように直接WANへのネットワークインターフェースがある場合、そこのポートも解放されている、という事が発覚しました。
基本的にはdockerネットワークを使用し不要なポートはpublishしていないので、実際に解放されていても大きな問題では無いのですが、とても気持ち悪かったので気付いてよかったです。

7月〜9月

少しづつインフラ以外に着手

同じタイミングではないのですが、さくらインターネットに移転して、サービス利用の簡便さやネットワーク的な利点なども考えて、さくらのコンテンツ配信系サービスを導入してみました。
eatsmart.hatenablog.com

完全https化も実施して、http2利用など配信系の最適化に取り組みました。

  • 新構成でマイクロサービス構築

dockerコンテナでの稼働が基本になったので、インフラ環境を気にせずに新しい構成でのサービスを立てやすくなりました。なので、新しい機能を実装する際には、既存のモノリシックなアプリケーションに実装するのではなく、閉じた機能のマイクロサービスとして構築することに挑戦しています。

eatsmart.hatenablog.com

もともと既存アプリケーションのソースリポジトリとしてsubversionを使用しているのですが、ローカルとリモートのコミット戦略的な所ではgitの方が使いやすいかなと思っていました。今回、新機能をマイクロサービスで構築していくようになったことによって、新ソースのリポジトリをgitを使うようにしました。

新人2名採用

もともと通年で中途の採用活動を行なっていたのですが、応募も少なくなかなか採用に至りませんでした。そこで、経験の浅い新人を採用して業務を通して成長してもらおうという方針にして、2018年は第二新卒の人材紹介を通して採用を行いました。それが実り、2名も(!)採用することができました。

10月〜12月

がっつり機能開発

  • 「カロリーチェックAPI

弊社サービスの「カロリーチェックAPI」に機能追加をするにあたり、spring-bootを使用してRESTサービスを実装しました。

eatsmart.hatenablog.com

  • 「クスパ」の先生向け有料サービス

弊社サービスの 料理教室・パン教室・お菓子教室の総合情報サイト「クスパ」 に、新たな有料サービスの実装を行いました。ここでも、独立した機能についてspring-bootでマイクロサービスを作りました。
久しぶりに大きめのサービス開発だったので、新人含めほとんどのメンバーをアサインして開発しました。

実は上記の2サービスの稼働環境は、前半に移転したサーバーと異なっており、コンテナ化されていません。でも、spring-bootをFully Executable JAR化することで、JARファイルをデプロイするだけで、簡単にサービスを稼働させる事ができました。(サービスのポート番号など可搬性以外の所では、dockerの方が楽ですが。)

これからやりたいこと

2018年にインフラ環境が変わり、技術的自由度が上がり、新人参加によるチーム開発体制に変わりました。そこからの発展と挑戦として、2019年は以下の事などに取り組んでいけたらなあと思っています。

  • gitを使ったチーム開発手法の確立
  • マイクロサービス化の促進
    • ドメインによるサービス分割
    • 現行のモノリシックな構造の分解
    • データも分散化させたい
  • フロントエンドの取り組み
    • モジュール化
    • Vueやらreactやら

あまりまとまっていないですが、今年もありがとうございました。それでは良いお年を。

Apache / Tomcatの基本設定と連携

こんにちは、EatSmartの新人エンジニアです。

弊社サービスであるもぐナビの開発に入るにあたり 環境構築を行いました。ApacheTomcatの導入、基本設定について振り返ってみたいと思います。

WEBサーバー:Apache
APサーバー:Tomcat
言語:Java
IDEeclipse

Tomcatの基本設定(eclipseで起動させる)

eclipseからtomcatを起動できるように設定する

ウィンドウ → ビューの表示→ その他
サーバーを選択 → 新規サーバー
参照ボタンからインストールしたディレクトリを指定する
サーバーから追加される
アイコン「起動」「停止」「再起動」が表示される
f:id:eatsmart:20181219180935p:plain

●インストール完了

ブラウザでlocalhost:8080を開きtomcatの画面が表示されればインストールが完了している

tomcatの設定ファイル(context.xml)

コンテキストにはアプリケーション群の動作に必要なJSP,Servlet,HTML,war,画像などが含まれる

tomcatのログを出力させる

アクセスログ
アクセスログはコンテキストに設定されたJSP,サーブレット,HTMLなどのファイルのアクセス状況を表すログ
・サーバーログ

Apache基本設定

●設定ファイルの位置

Apacheに対する設定はhttpd.conf に記述する
インストールしたディレクトリからファイルの位置を確認する

●Servernameの設定

デフォルトでは既に設定されている
コメントアウトを外す
f:id:eatsmart:20181219180337p:plain

上記はローカル環境で動かしたときの例です

●リクエストを受け付けるときのポート番号の設定

Listen 80
Listen 443(HTTPS通信)
f:id:eatsmart:20181219182017p:plain

ポート番号は複数記述できる

●ServerRootの設定

Apacheがインストールされているディレクトリを指定する

●Includeで必要なファイルを取り込む

f:id:eatsmart:20181219182138p:plain

Apacheをサービスとして起動する

f:id:eatsmart:20181219180815p:plain

Apache httpdTomcatを連携する

●ApahceとTomcatを連携させる

インターネットからのリクエストをhttpdで受け付けて、Javaの動的な処理が必要なページの処理はTomcatで実行させる
そのためにAJPというプロトコルを用いて連携させる

AJP(Apache JServ Protcol)とは

AJPとはTomcatと連携させるプロトコルのこと
Apache httpdが受け付けたリクエストをTomcatに連携させるためにこのAJPプロトコルを用いて通信する
mod_proxy_ajpというモジュールをインストールして使用する

Tomcatで確認

Tomcatのconfディレクトリにあるserver.xmlファイルに設定が記述されている
f:id:eatsmart:20181220190651p:plain

「ポート8080番で HTTP 1.1 の通信を受け付ける」

f:id:eatsmart:20181220190848p:plain

「ポート8009番で AJP 1.3 の通信を受け付ける」

Apache httpdの設定

Apahce httpd の設定を行い連携させる
mod_proxy_ajp と mod_proxyを読み込ませるためにコメントアウトを外し、有効にする

次にどのパスにアクセスされた場合にTomcatと連携するのかを設定する
f:id:eatsmart:20181221093646p:plain

●最後にApacheTomcatを再起動して設定を反映させる

シナリオテストをやってみて

イートスマートの新人エンジニアが、今回はシナリオテストをやってみて学んだことを振り返っていきます。

シナリオテスト実施の背景

弊社が提供する料理教室情報サイト「クスパ」の方で、新たな機能を追加し、リリースさせるという流れがあります。

実施したシナリオテストについて

今回行うことになったシナリオテストでは、大きく二つの観点から検証が必要になります。
①料理教室を主催する「先生」の教室管理サイト側
②料理教室を探す「生徒」のユーザーサイト側

以下、実施したテストの一部になります。
・先生側のプラン変更に伴い、利用できるようになった機能のテスト
・生徒と先生の双方向性のあるコミュニケーション機能のテスト
SNS連携を利用した機能、投稿機能のシェアなどに関するテスト

各シナリオについて、デバイス毎(PC、iPhoneAndroid)によってテストを行いました。

シナリオのサンプルを作成してみる

ここで、もう少し具体的にイメージできるように実際のシナリオ形式に近いサンプルを作ってみます。 シナリオは、プロジェクトの管理者や実装するエンジニアなど複数人が見ることになるので、状況を再現しやすいように 記述するのが望ましいかと思います。f:id:eatsmart:20181121174540p:plain
この例では、生徒が料理教室を「お気に入り」登録→「お気に入り」した生徒に対し、先生がイベントを招待→生徒は、イベントの参加に対し、 意思表明ができる→先生は、「参加」を選んだ生徒にのみ「お礼メール」が遅れるというシナリオを想定しています。

スクリプトテストと探索的テスト

テストを実施していく中で、テストの手法としてどんなものがあるのか興味をもったので 調べてみました。

今回行ったシナリオテストは、いわゆるスクリプトテストに属するということがわかりました。あらかじめ設定したテストケース(シナリオ)を用意し、ドキュメントベースで動作確認を行っていきます。おそらく一般的にどこのWeb系企業も行っている手法でしょう。

スクリプトテストと対比される手法として、探索的テストというものがあります。 探索的テストは、あらかじめテストケースを用意せずに、テストを実施していく過程でテストケースを作っていくという手法になります。 メリットしては、膨大なテストケースを予め用意する必要がないこと、テストケースに縛られることなく、バグが潜んでいそうな分野に集中してその都度テスト内容を検討していけるという柔軟性があります。

探索的テストの導入の可能性

今回スクリプトテストを中心に行いましたが、振り返ってみて探索的テストを中心にプロジェクトに導入するというのは難しいと感じました。理由は以下の点になります。

①自分を含めテスターのサービス・機能に対する理解がテスト初期段階で浅かったため
②チェックする機能が広範囲にわたるため、網羅性を担保できない(ゆえに、不具合が潜んでいそうな部分の特定も難しい。)
③テスターとして動員できる人数、リリース時期のスケジュール感の問題

テスト終盤になってくるにつれて、サイトや機能についての理解が深まってきます。そのため、①の問題点は徐々にクリアする余地がでてきます。

まとめると、導入する場合は、スクリプトテストを一巡した後半で、③との兼ね合いを考慮し、同一のテスターが探索テストを実施してみるのはありではないでしょうか。

シナリオテストを実施してみての総括

シナリオテストをやってきて、最初はシナリオってこんなに在庫あるの!?って感じたり、多数のユーザー間の行き来していく中で、いま俺誰アカウントだっけ?となったり、テスターの苦労が少しわかった気がしています。そうすると、既に実施したテストでこういう問題があったから、次のテストもこうなるだろうという予測。あるいは、PCで確認した際に、スマホではどういう見え方になるんだろう?といった疑問が湧いたりします。時には、夢にも出てきます。そういった経験の中で、以前よりもテストの落とし所が見えてきたり、逆に新鮮な発見があったりします。普通に電車でスマホをいじってるだけでは、見過ごすようなものばかりです。

何よりも収穫であったのは、細かい部分に注目してサイトを見るようになるので、自社のサービス自体に詳しくなれたことだと思います。料理教室の先生と生徒双方のサイトを往復し、生徒になったり、先生になったりというような経験は日常でそう作れるものではありません。納期がある以上、テストを手際よくやっていくことも必要ですが、探索的にテストをしてみるという機会も作ってはいかがでしょうか。

以下、参考にした記事になります。 探索的テストについて

ZabbixからTomcatコンテナを監視する

EatSmartではサーバ、サービスの監視にZabbixを利用しています。 利用するテンプレートは、サーバの監視には"Template OS Linux"を、Tomcatの監視には"Template App Generic Java JMX"と独自に拡張したものを利用しています。 これらの構成はデータセンターを利用していた頃から基本的に変わらないのですが、Zabbix Java GatewayTomcatを監視するのに工夫が必要でした。

Tomcatコンテナの設定

以前は一つのサーバに複数のTomcatをインストールしていたので、JMXが利用するポートが重複しないよう分けていました。 Dockerコンテナで可動するTomcatも同様にコンテナごとに重複しないようにポートは分けるようにしました。 当初、setenv.shと起動時のコマンドは以下のようにしました。

setenv.sh

CATALINA_OPTS="${CATALINA_OPTS} \
  -Dcom.sun.management.jmxremote=true \
  -Dcom.sun.management.jmxremote.port=12345 \
  -Dcom.sun.management.jmxremote.rmi.port=12345\
  -Dcom.sun.management.jmxremote.local.only=false \
  -Dcom.sun.management.jmxremote.authenticate=false \
  -Dcom.sun.management.jmxremote.ssl=false"

export CATALINA_OPTS

run.sh

docker run -d \
  --name tomcat-mog \
  -p 38080:8080 \
  -p 32345:12345 \
  esma/tomcat

このTomcatコンテナは各サービスで共通で利用することを想定しています。 そのため、コンテナ自体は8080/12345という固定のポートを利用し、必要に応じて実行時にポートフォワードさせます。 "tomcat-mog"という名前のこのコンテナは、外部に38080/32345の2つのポートを開放しています。 ZabbixからはZabbix Java Gatewayを経由して32345ポートを利用すれば良いと考えていました。

しかし、この設定では監視ができませんでした。 調査した結果、Zabbixが指定したIPアドレス/ポート(Dockerホストのもの)と自身のIPアドレス/ポート(Dockerコンテナのもの)が異なるため、Zabbix Agentはメトリクスを返していませんでした。

設定の変更

原因がわかったので解消するための設定を行います。

setenv.sh

CATALINA_OPTS="${CATALINA_OPTS} \
  -Dcom.sun.management.jmxremote=true \
  -Dcom.sun.management.jmxremote.port=${JMX_PORT} \
  -Dcom.sun.management.jmxremote.rmi.port=${JMX_PORT} \
  -Dcom.sun.management.jmxremote.local.only=false \
  -Dcom.sun.management.jmxremote.authenticate=false \
  -Dcom.sun.management.jmxremote.ssl=false \
  -Djava.rmi.server.hostname=${HOST_IP_ADDRESS}"

export CATALINA_OPTS

run.sh

HOST_IP_ADDRESS=`hostname -I`

docker run -d \
  --name tomcat-mog \
  -p 38080:8080 \
  -p 32345:32345 \
  --env="JMX_PORT=32345" \
  --env="HOST_IP_ADDRESS=${HOST_IP_ADDRESS}" \
  esma/tomcat

Dockerホストとコンテナ間のIP/ポートを同一にすることは出来ないので、ホストの設定をコンテナ起動時に渡すようにしました。 コンテナではその値を参照して、JMXの値を設定しています。 以上の変更で、無事ZabbixからTomcatコンテナを監視することができるようになりました。

Spring Bootのサービス稼働環境

弊社では食品の検索に対してXMLで結果を返すRESTfulのAPIを運営しているのですが、今回、機能追加やJSONでの返却を可能にするバージョンアップを計画しています。

今まではJSP+Servletでの実装だったんですが、今回はSpring Bootで実装してみました。 Spring BootではFully Executable JARで簡単にサービス稼働環境を作ることができたので、ここで紹介します。

Fully Executable JARとは

Spring Bootでは、作成したJARファイルをjava -jarで起動することができますが、UNIX環境でより簡単に起動することができる仕組みです。 詳しくは Spring Boot Reference Guide をどうぞ。

JARファイルの作成

APIのプロジェクトはmavenで構成管理をしているのですが、mavenのpluginで簡単にFully Executable JARを作ることができました。

まず、pom.xmlのspring-boot-maven-plugin定義に<executable>true</executable>を追加します。

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
+   <configuration>
+       <executable>true</executable>
+   </configuration>
</plugin>

次に、maven packageでビルドします。

$ mvn package
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building XXXXXXXX
[INFO] ------------------------------------------------------------------------
...
[INFO] --- maven-jar-plugin:3.0.2:jar (default-jar) @ xxxx ---
[INFO] Building jar: /xxx/xxx/target/XXXXXXXX.jar
[INFO]
[INFO] --- spring-boot-maven-plugin:2.0.3.RELEASE:repackage (default) @ xxxx ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 10.709 s
[INFO] Finished at: 2018-11-09T13:03:46+09:00
[INFO] Final Memory: 42M/290M
[INFO] ------------------------------------------------------------------------
$

という流れで、targetフォルダ下にJARファイルが作成されます。

起動のしかた

Fully Executable JARができると、起動はそのJARファイル自身を実行するだけです。例えば、JARファイルをapp.jarで作ったとすると、

$ cd target/
$ ./app.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v2.0.3.RELEASE)

2018-11-09 13:51:58.709  INFO 11707 --- [           main] xxx.Application           : Starting Application v2.0 on xxx with PID 11707 (app.jar started by xxx in /xxx/xxx/xxx/target)
2018-11-09 13:51:58.721  INFO 11707 --- [           main] xxx.Application           : No active profile set, falling back to default profiles: default
2018-11-09 13:51:58.886  INFO 11707 --- [           main] ConfigServletWebServerApplicationContext : Refreshing org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext@12f40c25: startup date [Fri Nov 09 13:51:58 JST 2018]; root of context hierarchy

という感じで、簡単に起動できます。

全てのライブラリはJARファイル内に含まれていますので、JARファイルを好きなところに配置して起動することができます。 先ほどの公式ドキュメントでは、init.dやsystemdのサービスとして起動する方法も書いてありました。

設定のしかた

Fully Executable JARでは、JARファイルと同じフォルダに、JARと同じ名前の.confファイルを作ることで、起動時の設定を行うことができます。

今回、Spring Bootを使うにあたり、JSP+Servletのシステムと異なるバージョンのJAVAを使用します。 また、アプリケーションサーバーのポート番号や、環境に応じたプロファイルの選択をしたいと思っています。

そのため、app.jarと同じフォルダに、以下の内容のapp.confというファイルを作成しました。

export JAVA_HOME=/usr/java/jre1.8.0_192
export JAVA_OPTS="-Dserver.port=8080 -Dlog4j.configuration=log4j-production.properties"
export SPRING_PROFILES_ACTIVE=production
export MODE="service"

JREは、既存の環境の/usr/javaフォルダ配下に展開だけして、デフォルトでの使用はしないようにしていますが、app.jarの起動時にJAVA_HOMEを指定して使用しています。

アプリケーションサーバーのポートやlog4jのプロパティは、JAVA起動オプションで指定して、Springのプロファイルも環境変数で与えています。

MODEはserviceを指定することで、start,stop等を使い、デーモンとして起動できます。

起動用の様々なオプションはこちら Spring Boot Reference Guide

Spring Bootの様々なオプションはこちら Appendix A. Common application properties

を参考にして下さい。

なぜ動くの?

なぜJARファイル自身を実行して、このようなことができるのでしょうか?

少し調べてみたところ、JARファイル自身の先頭に細工があるようです。

JARファイルの中身を見てみると

$ less app.jar

#!/bin/bash
#
#    .   ____          _            __ _ _
#   /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
#  ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
#   \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
#    '  |____| .__|_| |_|_| |_\__, | / / / /
#   =========|_|==============|___/=/_/_/_/
#   :: Spring Boot Startup Script ::
#

### BEGIN INIT INFO
# Provides:          caloriecheck-api
# Required-Start:    $remote_fs $syslog $network
# Required-Stop:     $remote_fs $syslog $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: XXXXXXXX
# Description:       Parent pom providing dependency and plugin management for applications built with Maven
# chkconfig:         2345 99 01
### END INIT INFO

[[ -n "$DEBUG" ]] && set -x

# Initialize variables that cannot be provided by a .conf file
WORKING_DIR="$(pwd)"
# shellcheck disable=SC2153
[[ -n "$JARFILE" ]] && jarfile="$JARFILE"
[[ -n "$APP_NAME" ]] && identity="$APP_NAME"
...

となっており、JARファイルの先頭がサービス起動のシェルスクリプトになっています。 そういえば、JARパッケージ時にspring-boot-maven-plugin:2.0.3.RELEASE:repackageと、何かの処理をされていたようです。

JARファイルというのは、実体はZIPファイル(拡張子を.zipに変更するとunzipできる)なのですが、こちらのブログ( Spring Boot の Fully Executable Jar はなぜ動くのか - RAMBO )によると、ZIPの解凍はファイルの後ろ側から処理をしていくために、先頭にスクリプトを載せても動くようです。

面白いことをするなあと感心しました。