tomcat上のwebアプリケーションをコンテナ化する
アプリケーションの稼働環境をdockerコンテナ化することは、環境の可搬性やネットワークの自由度などとても有用なので、弊社のサービスをコンテナ化しています。
先日、tomcatで動作しているwebアプリケーションをコンテナ化した際にやったことをブログに残したいと思います。
tomcatのwebアプリをコンテナに入れるにあたり、以下のことを行いました。
mavenで構成管理する
もともとビルドのタスク実行はantを使用していたのですが、ライブラリの依存性管理や開発環境構築の利便性のために、mavenで構成管理をすることにしました。
ただ、単純にtomcatのWEB-INF/libフォルダ配下にjarファイルを置いて、全てをクラスパスに追加すれば良かった(もっともそのせいで、ライブラリ同士の依存関係が全く分からなくなっていたのですが…)のが、全てをpom.xmlに定義が必要となりました。
依存関係が管理されていなかったのでバージョンが不明だったり、全てのdependencyを記述するのが大変だったので、
<dependency>
<groupId>jai_codec.jar</groupId>
<artifactId>jai_codec.jar</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${basedir}/src/WEB-INF/lib/jai_codec.jar</systemPath>
</dependency>
のように、元々のWEB-INF/lib配下のjarにsystemスコープで定義しているところもあります。 これでは依存性の解決にはなっていませんが…。
tomcat-maven-pluginでwebアプリを実行する
mavenで構成管理を行うようにしたので、tomcat-maven-plugin(Apache Tomcat Maven Plugin - About Apache Tomcat Maven Plugin)を使ってtomcatもmavenで起動するようにしました。
今回のアプリではDB接続にJNDIを使用しているのですが、JNDI定義はtomcatのcontextファイルに記述しています。 pluginの定義でも指定のcontextファイルを使用するように、configurationのcontextFileで指定します。
また、古いtomcatの頃の名残で、JSPのスクリプトレット内でエスケープ無しにダブルクォートしていたり(Tomcat5.5.27、6.0.18からJSPのスクリプトレットなどの中でクォートを使用する際にエスケープが必要になった - 不会忘記的一天)するので、STRICT_QUOTE_ESCAPINGをfalseに設定します。
結果、pom.xmlに以下の定義を追加しました。 pluginのバージョンが2.1の理由は後述します。
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.1</version>
<configuration>
<contextFile>${project.basedir}/context.xml</contextFile>
<systemProperties>
<org.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING>false</org.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING>
</systemProperties>
</configuration>
</plugin>
これで、mvn tomcat7:runで起動するようになりました。
$ mvn tomcat7:run [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building XXXXXXXXXXXXXXXXXx [INFO] ------------------------------------------------------------------------ [INFO] [INFO] >>> tomcat7-maven-plugin:2.1:run (default-cli) > process-classes @ XXXXXXXX >>> [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ XXXXXXXX --- ・・・ ・・・ [INFO] [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ XXXXXXXX --- [INFO] Changes detected - recompiling the module! ・・・ ・・・ [INFO] <<< tomcat7-maven-plugin:2.1:run (default-cli) < process-classes @ XXXXXXXX <<< [INFO] [INFO] [INFO] --- tomcat7-maven-plugin:2.1:run (default-cli) @ XXXXXXXX --- [INFO] Running war on http://localhost:8080/XXXXXXXX [INFO] Creating Tomcat server configuration at /XXXXXXXX/XXXXXXXX/target/tomcat [INFO] create webapp with contextPath: /XXXXXXXX 8 02, 2018 7:30:37 午後 org.apache.coyote.AbstractProtocol init 情報: Initializing ProtocolHandler ["http-bio-8080"] 8 02, 2018 7:30:37 午後 org.apache.catalina.core.StandardService startInternal 情報: Starting service Tomcat 8 02, 2018 7:30:37 午後 org.apache.catalina.core.StandardEngine startInternal 情報: Starting Servlet Engine: Apache Tomcat/7.0.37 8 02, 2018 7:30:41 午後 org.apache.catalina.core.ApplicationContext log
tomcat-maven-pluginで実行可能jarを作成する
tomcat-maven-pluginを使用して、実行可能jarを作る事ができます。コンテナ構築がjarファイルのコピーで済むと簡単で良いので、実行可能jarを作ってみます。
まず、pluginの定義にexec-war-onlyゴールを追加します。 また、実行するtomcatでJNDIを使うためにはenableNamingの設定が必要なようです(Apache Tomcat Maven Plugin :: Tomcat 7.x - tomcat7:standalone-war)。他にも色々と設定ができるようなので、参考にしてみて下さい。
ここで、以下のようにpluginのバージョン2.2、2.3にはexec-war-onlyが正常に動作しないとのことで、2.1を使用しました。
- [MTOMCAT-263] tomcat7:exec-war can't create .extract/webapps - ASF JIRA
- java - maven-tomcat7-plugin produces corrupted executable JAR - Stack Overflow
で、最終的に、pluginの設定は以下のようになりました。
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.1</version>
<configuration>
<contextFile>${project.basedir}/context.xml</contextFile>
</configuration>
<executions>
<execution>
<id>tomcat-run</id>
<goals>
<goal>exec-war-only</goal>
</goals>
<phase>package</phase>
<configuration>
<path>XXXXX[作成するJARの名前]</path>
<enableNaming>true</enableNaming>
</configuration>
</execution>
</executions>
</plugin>
ここでmvn packageコマンドを実行すると
$ mvn package [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building XXXXXXXX [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ XXXXXXXX --- [INFO] Copying 1 resource ・・・ ・・・ [INFO] [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ XXXXXXXX --- [INFO] Changes detected - recompiling the module! ・・・ ・・・ [INFO] --- maven-war-plugin:2.2:war (default-war) @ XXXXXXXX --- [INFO] Packaging webapp [INFO] Assembling webapp [XXXXXXXX] in [/XXXXXXXX/XXXXXXXX/target/XXXXXXXX] [INFO] Processing war project [INFO] Copying webapp resources [/XXXXXXXX/XXXXXXXX/src/main/webapp] [INFO] Webapp assembled in [3288 msecs] [INFO] Building war: /XXXXXXXX/XXXXXXXX/target/XXXXXXXX.war [INFO] WEB-INF/web.xml already added, skipping [INFO] [INFO] --- tomcat7-maven-plugin:2.1:exec-war-only (tomcat-run) @ XXXXXXXX --- [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 15.023 s [INFO] Finished at: 2018-08-02T19:58:47+09:00 [INFO] Final Memory: 49M/275M [INFO] ------------------------------------------------------------------------
とjarの作成が成功しました。
さらにtargetフォルダの下にできたjarファイルを実行することで
$ java -jar ./target/XXXXXXXX-war-exec.jar 8 02, 2018 8:00:11 午後 org.apache.catalina.core.StandardContext setPath 8 02, 2018 8:00:11 午後 org.apache.coyote.AbstractProtocol init 情報: Initializing ProtocolHandler ["http-bio-8080"] 8 02, 2018 8:00:11 午後 org.apache.catalina.core.StandardService startInternal 情報: Starting service Tomcat 8 02, 2018 8:00:11 午後 org.apache.catalina.core.StandardEngine startInternal 情報: Starting Servlet Engine: Apache Tomcat/7.0.37 8 02, 2018 8:00:18 午後 org.apache.catalina.core.ApplicationContext log 情報: No Spring WebApplicationInitializer types detected on classpath
と、tomcatを使ってwebアプリを起動することができました。
実行可能jarを入れたコンテナを作成する
あとは、javaが動くコンテナ内にjarを入れれば良いのですが、今回は接続先DB等を外部化するために、起動時にパラメータでserver.xmlを指定するようにしてみました。
server.xmlのパスは、javaコマンドで起動時に-serverXmlPathで指定することができます(Apache Tomcat Maven Plugin - Executable War )。
#ビルド時にpom.xmlのserverXml項目で指定することもできます(Apache Tomcat Maven Plugin :: Tomcat 7.x - tomcat7:standalone-war)。
今回は、jarファイル、JNDIのDB定義をしたserver.xmlファイル、コンテナ起動時にtomcatを起動するスクリプトを、コンテナ内の同一フォルダに配置するようにしました。
起動スクリプトは、startup.shという名前で
#!/bin/sh DIR=$1 cd $DIR java -Xmx1024m -jar $DIR/XXXXXXXX-war-exec.jar -serverXmlPath $DIR/server.xml
というファイルを用意し、以下の内容のDockerfileを作りました。
・・・ ・・・ RUN mkdir -p /usr/local/XXXXXXXX ADD ./startup.sh /usr/local/XXXXXXXX/ ADD ./server.xml /usr/local/XXXXXXXX/ ADD ./XXXXXXXX-war-exec.jar /usr/local/XXXXXXXX/ EXPOSE 8080/tcp CMD ["/usr/local/XXXXXXXX/startup.sh","/usr/local/XXXXXXXX"]
あとは、コンテナをbuildして、
$ docker build -t esma/XXXXXXXX ./ Sending build context to Docker daemon 39.85MB ・・・ ・・・ Removing intermediate container 81eaa50676f6 ---> aa9795082fde Step 3/8 : RUN mkdir -p /usr/local/XXXXXXXX ---> Running in 0b34a06c54bd Removing intermediate container 0b34a06c54bd ---> 2d4acc4a17a0 Step 4/8 : ADD ./startup.sh /usr/local/XXXXXXXX/ ---> affd7178601c Step 5/8 : ADD ./server.xml /usr/local/XXXXXXXX/ ---> 836ca962776d Step 6/8 : ADD ./XXXXXXXX-war-exec.jar /usr/local/XXXXXXXX/ ---> b1477fde89e0 Step 7/8 : EXPOSE 8080/tcp ---> Running in 5c77492af7da Removing intermediate container 5c77492af7da ---> 3e656de10f13 Step 8/8 : CMD ["/usr/local/XXXXXXXX/startup.sh","/usr/local/XXXXXXXX"] ---> Running in a61e2cf508ca Removing intermediate container a61e2cf508ca ---> 2c7c01b9d549 Successfully built 2c7c01b9d549 Successfully tagged esma/XXXXXXXX:latest
そして、実行すると
$ docker run -d --name=XXXXXXXX -p 8080:8080 -it esma/XXXXXXXX aef000541e0795693610849743dc0b97835d5b54b9d3de26e31e606eb9bdbc86 $ docker logs XXXXXXXX Aug 02, 2018 3:16:32 PM org.apache.catalina.core.AprLifecycleListener init INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/packages/lib/amd64:/usr/lib/x86_64-linux-gnu/jni:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu:/usr/lib/jni:/lib:/usr/lib Aug 02, 2018 3:16:33 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["http-bio-8080"] Aug 02, 2018 3:16:33 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["ajp-bio-8009"] Aug 02, 2018 3:16:33 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 1104 ms ・・・ ・・・ Aug 02, 2018 3:16:37 PM org.apache.catalina.core.ApplicationContext log INFO: Initializing Spring FrameworkServlet 'dispatcherServlet' Aug 02, 2018 3:16:39 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["http-bio-8080"] Aug 02, 2018 3:16:39 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["ajp-bio-8009"] Aug 02, 2018 3:16:39 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 6363 ms Aug 02, 2018 3:16:49 PM org.apache.naming.NamingContext lookup
と、無事コンテナ内でwebアプリを起動することができました。
Dockerについて
初めまして、EatSmartの新人エンジニアが初ブログを更新したいと思います。
入社してちょうど１ヶ月が経ちました。
現在、社内向けのツールを開発中でその際にdockerで仮想環境を構築しました。
初めてDockerを動かすことになったので調べた内容をまとめてみました。
Dockerとは
コンテナ型の仮想環境を構成、管理するソフトウェアでLinuxカーネルが持つ「コンテナ」機能などを使って実行環境を他のプロセスから隔離しその中でアプリケーションを動作させる技術のこと
VMやVMwareのようなサーバー仮想化との違いは扱う単位がマシンではなくプロセスであること
サーバー仮想化ではホストマシン上でゲストマシンが動き、ゲストマシン内で様々なプロセスが動きます。一方のコンテナ型の仮想化ではホストOS上にコンテナという隔離された空間が作成されその中でプロセスが実行されます
Dockerマシンは何が良いのか
■軽量で高速に起動、停止などが可能であること
DockerはLinuxのコンテナ技術を使ったものでよく仮想マシンを比較させます、Virtualboxなどの仮想マシンではホストマシン上でハイパーバイザを利用しゲストOSを動かしその上でミドルウェアなどを動かす。それに対しコンテナはホストマシンのカーネルを利用しプロセスやユーザーなどを隔離することであたかも別のマシンが動いているかのように動かすことができる
■安定した開発を進めたり、リリースサイクルの改善に役立つ
コード化したもの(Dockerfile)を構成管理し、それをCIツール(JenkinsやCircleCI）でビルド(Dockerイメージの作成)、デプロイ(コンテナの起動)、環境テスト(Serverapec)、画面試験(Selenium)を毎日実行すれば環境面の確認も含めて安心して開発を進められるようになる
Docker登場の背景
アプリ開発者にとってハードウェアの調達やメンテナンスは開発以外での作業工程が増え足かせになっていた
サービスモデルの一つであるlaasをより効率よく活用するために必要最低限のリソースでアプリケーションを実行できる環境を提供するコンテナ型サービスが注目を集めている
Dockerの実行環境について
今回はLinux CentOS 7 64bitを使用しましたがその他にも
Docker for Windows / Docker for Mac などのソフトウェアが開発されている
導入 コマンド
# yum install docker
#chkonfig docker on
#service docker start
Docker操作の基本
Dockerサーバ（コンテナ実行用のエンジン）とクライアント（管理ツール）に分かれたツールである
イメージの取得 → コンテナの起動 → コンテナの停止 → イメージの作成 → コンテナの削除 → イメージの削除 といった順で操作していきます
DockerHubで管理
作成したコンテナイメージはDockerHubといったコンテナイメージ登録や共有ができるサービスサイトで管理ができる。このようなサイトにDockerが構成されたサーバーなどの環境からアクセスできれば作成したコンテナイメージをアップロードやダウンロードし利用できる
参考資料
http://docs.docker.jp/
http://knowledge.sakura.ad.jp/tech/2210/
Postgresql DB移行
インフラの見直しに伴いDB移行を行う事になりましたが、フルダンプの移行だと数日かかることが判明した為、いくつか時間短縮の施策を検討してみました。
移行環境
（移行前）
postgresql8.3.5
※移行前の容量は400G程度
（移行後）
postgresql9.3.5
施策１
まず、フルダンプの移行をやめて、テーブル単位の移行に変更しました。また、テーブルの中でも、変更が発生しないマスター系のテーブルと、変更が発生するトランザクション系のテーブルを精査して、マスター系のテーブルは事前移行する事にし、トランザクション系のテーブルのみをサービス停止して移行する事にしました。
後、トランザクション系のテーブルは、移行の必要が無い不要レコードを出来る限り削除しました。
施策２
「施策１」を実施して、再度移行時間を計測してみましたが、それでも数十時間かかることが判明しました。そこで、その中でも移行に時間がかかるテーブルに着目し、時間短縮できないか検討してみました。
施策3
「施策２」で、エクスポート/インポート/index作成等を細分化して計測してみた所、インデックス作成に時間が掛かっていることが分かりました。
そこで、index作成を高速化できないか調べてみた所、DBのパラータ[maintenance_work_mem]を増やすことで高速化できることが分かりました。
https://www.postgresql.jp/document/9.3/html/populate.html
また、postgresqlの移行高速化方法を調べていく中で、WALの書き込み停止(full_page_writes=false/fsync=false)、pg_dump/pg_restoreを並列で実行するオプション[jobs]が有効であることも分かりました。
WALの書き込み停止
https://www.postgresql.jp/document/9.3/html/runtime-config-wal.html
並列で実行するオプション[jobs]
https://www.postgresql.jp/document/9.3/html/app-pgrestore.html
https://www.postgresql.jp/document/9.3/html/app-pgdump.html
移行リハーサル
「施策３」を一通り実装し移行リハーサルを実施した所、エクスポート/インポートトータルで10時間以内で終える事ができました。
本内容を踏まえ、本番移行の準備を行いました。
本番移行
本番当日、サービス停止している事を考慮し[maintenance_work_mem][jobs]のパラメータの値を増やして実施しました。
エクスポート迄は[jobs]のパラメータの値を増やした影響で、スケジュールより前倒しで完了しました。ところが、インポートの処理が、予定より数時間遅延しました。
原因としては、[maintenance_work_mem]の値を増やしすぎたことにより、swapが発生した事が考えられます。
最後に
スケジュールは遅延しましたが、何度かリハーサルを行っていたので、ある程度の遅延時間の予測が立てれた為、切り戻しを実施せず完了する事が出来ました。改めて、リハーサルの重要性を感じました。
データセンターからクラウドへの移行
これまでイートスマートでは、サービスの大部分をデータセンターを利用して提供してきました。 データセンターの利用を開始してから年月が経つことで、ネットワーク機器・サーバの故障や容量不足が目立つようになりました。 データセンターを利用しているなかで問題となったのは、主に以下の３つです。
- ネットワーク機器・サーバの老朽化によるトラブル
- 上記要因による保守作業の増加
- サーバのリソース不足
ハードウェアの老朽化により、故障が発生するリスクが高くなり、部品の交換にも支障をきたすようになりました。 また、サービスが成長するに伴いサーバのメモリ等の容量不足が目立つようになりました。 そこで昨年から、データセンターからクラウドへの移行を計画しました。
クラウドへの移行計画
移行を計画するにあたり、現状・移行のそれぞれのメリット・デメリット、それに伴うリスクを検討しました。 検討内容を踏まえ、データセンターから既に利用実績のあるさくらインターネットへ移行することになりました。 またこのタイミングで、既に一部のサービスの本番環境で稼働実績のあるDockerを全面的に利用することになりました。 これに伴い、アプリケーションのビルド・デプロイ・監視・ログ収集等の仕組みを作り直しました。
アプリケーションのビルド・デプロイ
アプリケーションのビルド・デプロイには、引き続きJenkinsを利用しました。 これまでは、VCSからチェックアウトしたソースをビルドし、rsyncでデプロイを行っていました。 Dockerを利用するにあたり、ビルド後にDockerイメージを作成し、Docker Registryへpushし、Dockerホストでpull/runを行うようにしました。
監視
監視には、こちらも引き続きZabbixを引き続き利用しました。 Dockerホストを含む各サーバへZabbix Agentを導入し、Zabbixから各種リソース・サービスの状態を取得しました。 Javaアプリを動かすDockerコンテナは、Zabbix Java Gatewayを利用してJMXの状態を取得しました。
ログ
ログはこれまでは各サーバに書き出し、バッチでファイルサーバへ集約していました。 これを、fluentdを利用してほぼリアルタイムでファイルサーバへ集約するようにしました。 これにより、今まで各サーバにsshでログインしていたログの確認が、ファイルサーバで行えるようになりました。
バッチの移植
バッチ処理はこれまで必要なミドルウェアや設定が行われてた専用のサーバで処理を行っていました。 バッチもwebアプリケーションと同様にDockerイメージ化することで、リソース管理が柔軟になりました。 このタイミングでバッチの洗い出しを行いました。移行当日に停止した場合の影響範囲の調査と、手動実行が必要か等を確認しておきます。
データベースのレプリケーション
これまでも一部サービスでは導入していたデータベースのレプリケーションを、全てのサービスで導入しました。
クラウドへの移行準備
移行にあたり、移行先の環境を出来る限り再現したものを用意して検証を行いました。 既存の仕組みをそのまま移行するわけでは無いため、現状の安定性とパフォーマンスを満たすことが出来るかを確認しました。 確認にあたり、主にApache BenchとJMeterを利用しました。 Apache Benchでは、Nginx/Apache/Tomcat等の高負荷状態を作り、安定性の検証を行いました。 JMeterでは、本番環境に近いシナリオを作り、安定性・パフォーマンスの検証を行いました。
検証と並行して、データセンター側の作業も進めました。 移行当日の作業を減らすため、事前にバックエンド系のサービスをクラウドへ移行しました。 また、移行にかかる時間を短縮するため、データの転送に時間がかかるデータベース・ファイルサーバも準備を行いました。 データベースは、事前にベースバックアップを転送し、レプリケーションを行うことが決まりました。 データセンター側をマスタ、クラウド側をスレーブとして移行当日まで運用し、当日にクラウド側をマスタに昇格させることでダウンタイムを短くするためです。 ファイルサーバは、事前にクラウドへ全ファイルの転送を行い、当日まで同期を行うようにしました。
最後に移行テストを実施し、作業内容に見直し等を行いました。
クラウドへの移行実施
移行は３つのフェーズで実施しました。
移行前日
移行当日
移行後
- ログ等からサービスの切り替えの確認
- データセンターのデータのバックアップ
- データセンターの機材の撤収
データセンターを切り替えるための最後の作業を行いました。 準備の段階で大部分の作業を終えているため、前日・当日の作業自体は少なくて済みました。
動作確認が終わりサービスを再開すると、検証時には見つけられなかった問題がいくつか発生しました。 そのなかのひとつが、Dockerホストが不安定になり再起動が必要になってしまったことです。 Swarmモードの利用の停止、Dockerコンテナの再配置、メモリやサービスのチューニングで対処しました。
おわりに
データセンターを利用していて当時の問題は、移行を行うことで解消することが出来ました。 移行直後に一時的に不安定になりましたが、上記の対処を行うことで現在は安定しています。 リソースに余裕が出来たことで、これまで稼働させることが出来なかったものや、冗長構成を取ることが出来るようになりました。 いくつか失敗もしてしまいましたが、普段の業務では出来ない経験をすることが出来ました。
docker buildでURLを指定する
こんにちは。お久しぶりです。
大分長い間ブログを寝かせていましたが、ブログを再開することにしました。 まずはウォーミングアップで、簡単なネタから…。
アプリケーションのビルドとデプロイ
弊社では、ソース管理にgit、アプリケーションの稼働にdockerを使っている環境があります。 (このころdockerを使おうと頑張っていましたね。) eatsmart.hatenablog.com
その環境では、アプリケーションのデプロイには、
- git上のソースをビルド
- dockerコンテナ構築
- デプロイ
という手順を踏むのですが、1について、ビルドサーバー上の適当な場所へgit cloneを行なっていました。
ビルドするための環境
ただ、ビルドサーバー上で"適当な場所"を決めてgit cloneしなければいけないし、それ以前に、実稼働環境のランタイムやライブラリのバージョンがアプリケーションによって異なるので、ビルドサーバー上での環境についてのバージョン管理が複雑になっていました。
ビルド環境のコンテナ化とURL指定
どうにかビルド環境を簡単に管理することができないかと思いながらdockerのドキュメントを見ていたら、
docker build [OPTIONS] PATH | URL | -
URLを指定してdocker buildできることに気づきました。
指定するURLとしてgitのリポジトリを使うことができ、以下のように指定できます。
| 指定リポジトリ | URL | buildのルートフォルダ |
|---|---|---|
| master | myrepo.git | masterブランチのルート |
| ブランチ指定 | myrepo.git#branch | branchブランチのルート |
| ディレクトリ指定 | myrepo.git#:myfolder | masterブランチの/myfolder |
| ブランチ&ディレクトリ指定 | myrepo.git#branch:myfolder | branchブランチの/myfolder |
docker build に渡すURLを切り替えることで、branchについてのコンテナも簡単に作ることができそうです。
最後に
git上にDockerfileを格納し、docker build時にgit上のURLを指定することで、専用の環境でビルドとコンテナ構築をまとめてできるようになりました。
もぐナビの検索をリニューアルしました
10月中旬に、もぐナビの検索をリニューアルしました。
イートスマートのサービスでは、データベースに主にPostgreSQLを利用しています。
これまで検索を行う場合は、PostgreSQLで全文検索を可能にするpg_bigmというモジュールを導入して利用してきました。
今回のリニューアルでは、pg_bigmからElasticsearch+Kuromojiへの移行を行いました。
リニューアルの背景
pg_bigmは名前の通り2-gram(バイグラム)という方法で全文検索を行います。今回のリニューアルでは、2-gramからKuromojiによる形態素解析を利用した全文検索へ変更しました。
2-gramと形態素解析はそれぞれ利点・欠点が挙げられます。今回のリニューアルでは、関係の無いキーワードでヒットすることを減らし検索の精度を上げるために形態素解析の導入を行いました。
もぐナビが扱う商品のメーカー・ブランドには、「ファミリーマート」「ファミマ」や「マクドナルド」「マック」「マクナル」のように複数の呼び方が存在するものがあります。
類義語による検索の実現も、今回のリニューアルで目指しました。
環境構築
今回はdockerを利用して環境を構築しました。
環境の構築には公式から提供されたものを利用しました。
これにKuromojiのインストール等の初期設定を行い、オリジナルのイメージを作成しました。
また、既存の辞書へ、メーカー・ブランド名を元に独自に追加も行いました。
課題
辞書のメンテナンス
日々新たな商品が発売されたりブランドが登場します。
これらは既存の辞書では適切に処理出来なくなる事が予想されるため、継続的な辞書のメンテナンスが必要になります。
これには別途集計している検索ログを活用し、ヒットしなかったキーワードの確認と適切なキーワードの登録を行う仕組みづくりに取り組みます。
ひらがな・カタカナによる検索
例えば「チョココロネ」の商品情報を検索するため「ちょこころね」と入力すると、「ちょこ」「ころね」ではなく「こころ」と分解されます。
これではユーザーは目的の商品を見つける事が出来ません。
フロントエンド改善の取り組み
もぐナビではサイトの閲覧を快適にするために、フロントエンドの改善を継続して行っています。
今回は今まで行ったフロントエンド改善の取り組みを振り返りたいと思います。
参考にしたもの
サイトを高速化するため、まずは以下の本を読みました。
この本に書かれたルールを元に、改修と計測を繰り返しました。
また、改修を行った後の確認には、以下を利用しています。
- PageSpeed Insights
- GTmetrix
- Google Analyticsの「サイトの速度」
行ったこと
1.画像の最適化
もぐナビでは商品画像を初め、クチコミ画像など大量の画像が表示されます。また、ロゴ画像やUIで利用する画像もあります。
HTTPリクエストを減らすため、このうちUIで利用する画像をCSSスプライトにしました。合わせて画像の最適化を行い、容量の低減も行いました。
CSSスプライトの作成にはCSS Sprite Generatorというサイトを利用しました。
画像の最適化にはTinyPNG – Compress PNG images while preserving transparencyというサイトを利用しました。
それ以外の商品画像やクチコミ画像は、jpegtranを利用して最適化を行っています。
これにより、最大60%程度の容量を削減する事が出来ました。
2.JS/CSSの最適化
画像と同様にHTTPリクエストの数を減らすため、JS/CSSの最適化 も行いました。
こちらはYUI Compressorをantを利用したビルドプロセスへ組み込み自動化しています。
これにより、読み込むJS/CSSが最大10個以上ありましたが、半分以下に減らすことが出来ました。
3.JavaScriptの移動
ページの最上部に記述していたJavaScriptの読み込みを、ページの一番下へ移動しました。また、一部はasyncを追加することで非同期にしました。
これにより、ページの読み込みがブロックされる事が無くなり、ページが表示されるまで待たされる時間を短くすることが出来ました。
注意点として、単純にページの下へ移動してしまうと、<head>タグで記述したスクリプトでエラーが発生する事があります。
このため、DOMContentLoadedでの実行するように変更するなどの対応が必要となりました。
4.コンテンツの圧縮
HTMLやJS/CSSの容量を低減を行うため、Apacheでmod_deflateを利用するようにしました。
gzipでコンテンツを圧縮することにより、最大75%程度の容量を削減する事が出来ました。
5.コンテンツの有効期限
クライアント側でキャッシュを有効活用するため、画像/JS/CSSに180日の有効期限を設定しました。
これと合わせ、コンテンツの内容を変更した場合にクライアントが再度ダウンロードを行えるよう、「?ts=xxxx」のようなパラメータを追加しています。
終わりに
以上の改修を行い、Google Analyticsの「サイトの速度」は9秒台から5秒前半まで改善することが出来ました。
実際には上に挙げた以外の改修も行っています。しかし効果が無かったり、逆に悪くなってしまったものもありました。このため、改修を行ったあとは必ず計測を行い、元に戻す事も必要です。
