カテゴリー: テクノロジー

SolrCloudのシャーディングとドキュメントルーティング(その2)

はじめに

前回はドキュメントルーターとして”compositeId”を選んだときの挙動を説明しました。今回取り上げるのはもう一つのドキュメントルーター”implicit”です。

implicitルーターの準備

$ cd server/solr/configsets
$ cp -r _default shard_test2
$ ../../scripts/cloud-scripts/zkcli.sh -zkhost localhost:9983 -cmd upconfig -confdir shard_test2/conf -confname shard_test2
$ ../../scripts/cloud-scripts/zkcli.sh -zkhost localhost:9983 -cmd upconfig -confdir shard_test2/conf -confname shard_test2
$ curl 'http://localhost:8983/solr/admin/collections?action=CREATE&router.name=implicit&name=shard_test2&shards=shard1,shard2,shard3,shard4&maxShardsPerNode=8&replicationFactor=1&collection.configName=shard_test2&wt=xml'

compositeIdのときはnumShardsでシャードの数を指定しますが、implicitではshardsパラメータで各シャードの名前を1個ずつ指定します。

データ投入

前回と同じデータを、シャードの指定なしで投入してみます。

$ curl 'http://localhost:8983/solr/shard_test2/update?commit=true&indent=true' --data-binary @data.json -H 'Content-Type: application/json'

どういうシャード分けされたかを確認。

$ for i in {1..4}; do curl -s "http://localhost:8983/solr/shard_test2/select?q=*:*&rows=0&shards=shard${i}"|jq '.response.numFound'; done
0
9236
0
0

分散されずに特定のシャードにすべてのデータが投入されていました。

シャードを指定してのデータ投入

一旦削除して作り直し。

$ curl 'http://localhost:8983/solr/admin/collections?action=DELETE&name=shard_test2'
$ curl 'http://localhost:8983/solr/admin/collections?action=CREATE&router.name=implicit&name=shard_test2&shards=shard1,shard2,shard3,shard4&maxShardsPerNode=8&replicationFactor=1&collection.configName=shard_test2&router.field=area&wt=xml'

投入時にシャードを指定するには、_route_パラメータを利用します。

$ cat d.json
[
{"id":"1","type":"官公庁","area":"住之江区","name":"軽自動車検査協会大阪主管事務所","address":"住之江区南港東3-4-62"}
]
$ curl 'http://localhost:8983/solr/shard_test2/update?commit=true&indent=true&_route_=shard1' --data-binary @d.json -H 'Content-Type: application/json'

d.json は1件だけのデータです。指定したshard1に入ったことを確認します。

$ for i in {1..4}; do curl -s "http://localhost:8983/solr/shard_test2/select?q=*:*&rows=0&shards=shard${i}"|jq '.response.numFound'; done
1
0
0
0

shard2に1件追加

$ cat d.json
[
{"id":"2","type":"官公庁","area":"住之江区","name":"軽自動車検査協会大阪主管事務所","address":"住之江区南港東3-4-62"}
]
$ curl 'http://localhost:8983/solr/shard_test2/update?commit=true&indent=true&_route_=shard2' --data-binary @d.json -H 'Content-Type: application/json'
$ for i in {1..4}; do curl -s "http://localhost:8983/solr/shard_test2/select?q=*:*&rows=0&shards=shard${i}"|jq '.response.numFound'; done
1
1
0
0

shard3に1件追加

$ cat d.json
[
{"id":"3","type":"官公庁","area":"住之江区","name":"軽自動車検査協会大阪主管事務所","address":"住之江区南港東3-4-62"}
]
$ curl 'http://localhost:8983/solr/shard_test2/update?commit=true&indent=true&_route_=shard3' --data-binary @d.json -H 'Content-Type: application/json'
$ for i in {1..4}; do curl -s "http://localhost:8983/solr/shard_test2/select?q=*:*&rows=0&shards=shard${i}"|jq '.response.numFound'; done
1
1
1
0

shard4に1件追加

$ cat d.json
[
{"id":"4","type":"官公庁","area":"住之江区","name":"軽自動車検査協会大阪主管事務所","address":"住之江区南港東3-4-62"}
]
$ curl 'http://localhost:8983/solr/shard_test2/update?commit=true&indent=true&_route_=shard4' --data-binary @d.json -H 'Content-Type: application/json'
$ for i in {1..4}; do curl -s "http://localhost:8983/solr/shard_test2/select?q=*:*&rows=0&shards=shard${i}"|jq '.response.numFound'; done
1
1
1
1

検索

特に指定しなければ、全シャードを対象にした検索になります。

$ curl -s 'http://localhost:8983/solr/shard_test2/select?q=*:*'{
  "responseHeader":{
    "zkConnected":true,
    "status":0,
    "QTime":15,
    "params":{
      "q":"*:*"}},
  "response":{"numFound":4,"start":0,"maxScore":1.0,"docs":[
      {
        "id":"1",
        "type":["官公庁"],
        "area":["住之江区"],
        "name":["軽自動車検査協会大阪主管事務所"],
        "address":["住之江区南港東3-4-62"],
        "_version_":1634782971384823808},
      {
        "id":"2",
        "type":["官公庁"],
        "area":["住之江区"],
        "name":["軽自動車検査協会大阪主管事務所"],
        "address":["住之江区南港東3-4-62"],
        "_version_":1634782988669550592},
      {
        "id":"3",
        "type":["官公庁"],
        "area":["住之江区"],
        "name":["軽自動車検査協会大阪主管事務所"],
        "address":["住之江区南港東3-4-62"],
        "_version_":1634782999227662336},
      {
        "id":"4",
        "type":["官公庁"],
        "area":["住之江区"],
        "name":["軽自動車検査協会大阪主管事務所"],
        "address":["住之江区南港東3-4-62"],
        "_version_":1634783009317060608}]
  }}

シャードを指定しての検索。

$ curl -s 'http://localhost:8983/solr/shard_test2/select?q=*:*&shards=shard4'
{
  "responseHeader":{
    "zkConnected":true,
    "status":0,
    "QTime":4,
    "params":{
      "q":"*:*",
      "shards":"shard4"}},
  "response":{"numFound":1,"start":0,"maxScore":1.0,"docs":[
      {
        "id":"4",
        "type":["官公庁"],
        "area":["住之江区"],
        "name":["軽自動車検査協会大阪主管事務所"],
        "address":["住之江区南港東3-4-62"],
        "_version_":1634783009317060608}]
  }}

implicitルーターが向くデータ

ここまで見てきたように、compositeIdルーターは自動で程よく分散検索を実現させてくれるルーター、implicitルーターは自分で手動で制御したいときに向いたルーターです。今回使ったデータはcompositeIdルーターに向いたデータと言えるでしょう。

implicitルーターに向いているのは、たとえばログデータです。月単位でシャードを分けてシャードを指定しつつデータを投入、新しい月が来たらシャードを追加、といった使い方ができます。

SolrCloudのシャーディングとドキュメントルーティング(その1)

はじめに

SolrCloudの機能の1つにシャーディングがあります。
たとえば4台のノードが利用できるときに、インデックスを4つのシャードに分けることにより、1ノードごとの検索負荷を小さくし、検索速度を向上させることができます。

シャーディングの設定

コレクション作成時に指定することでインデックスをいくつかのシャードに分けることができます。

まずサンプルの _default をコピーして configsets を用意します。

$ cd server/solr/configsets
$ cp -r _default shard_test
$ ../../scripts/cloud-scripts/zkcli.sh -zkhost localhost:9983 -cmd upconfig -confdir shard_test/conf -confname shard_test

4個のシャードからなるコレクションを作成

$ curl 'http://localhost:8983/solr/admin/collections?action=CREATE&router.name=compositeId&name=shard_test&numShards=4&maxShardsPerNode=8&replicationFactor=1&collection.configName=shard_test&wt=xml'

サンプルデータ

サンプルとして大阪の施設情報を利用します。

$ grep -v ^# osaka_shisetsu20140106.txt |head -3
158	34.6164938333333	135.438210722222	http://lodosaka.hozo.jp/class/施設情報	官公庁	国の機関	住之江区	軽自動車検査協会大阪主管事務所	軽自動車検査協会大阪主管事務所	住之江区南港東3-4-62	
157	34.6190439722222	135.442191833333	http://lodosaka.hozo.jp/class/施設情報	官公庁	国の機関	住之江区	大阪陸運支局なにわ自動車検査登録事務所	大阪陸運支局なにわ自動車検査登録事務所	住之江区南港東3-1-14	
381	34.6109641111111	135.491388722222	http://lodosaka.hozo.jp/class/施設情報	官公庁	国の機関	住吉区	住吉税務署	住吉税務署	住吉区住吉2丁目17番37号	http://www.nta.go.jp/osaka/guide/zeimusho/osaka/sumiyoshi/index.htm

スクリプトを通してJSONに変換します。

{"id":"158","type":"官公庁","area":"住之江区","name":"軽自動車検査協会大阪主管事務所","address":"住之江区南港東3-4-62"},
{"id":"157","type":"官公庁","area":"住之江区","name":"大阪陸運支局なにわ自動車検査登録事務所","address":"住之江区南港東3-1-14"},
{"id":"381","type":"官公庁","area":"住吉区","name":"住吉税務署","address":"住吉区住吉2丁目17番37号"},
  :

データを投入

$ curl 'http://localhost:8983/solr/shard_test/update?commit=true&indent=true' --data-binary @data.json -H 'Content-Type: application/json'

データ件数を確認

$ curl -s 'http://localhost:8983/solr/shard_test/select?q=*:*&rows=0'|jq '.response'
{
  "numFound": 9236,
  "start": 0,
  "maxScore": 1,
  "docs": []
}

特に何も指定しなければ、ドキュメントID(この場合はidフィールド)のハッシュ値に基づいてシャードが割り振られます。シャード毎に何件ずつ入っているかを確認します。

$ for i in {1..4}; do curl -s "http://localhost:8983/solr/shard_test/select?q=*:*&rows=0&shards=shard${i}"|jq '.response.numFound'; done
2379
2360
2207
2290

4つのシャードにだいたい均等に分かれていますね。

ドキュメントルーティング

負荷分散さえできれば良い場合なら上記のようなシャード分けで十分訳に立ちますが、
検索パターンによっては特定のフィールド値を持つレコードが同じシャードに配置される構造になっていると都合が良いことがあります。


たとえばCMSの検索のような場合は、ユーザを指定して検索することが多くなります。この場合、同じユーザのインデックスが同じシャードに配置されるようになっていれば、検索時に特定のシャードにだけクエリを投げれば良く、分散検索に関するオーバーヘッドを抑えることができます

これを実現するのがドキュメントルーティングです。

2つのドキュメントルーター

何らかの値に基づいてレコードを各シャードに割り振るのがドキュメントルーターの役割です。ドキュメントルーターとして以下の2つのどちらかを選ぶことができます。

  • compositeId (デフォルト)
    • ドキュメントIDのフィールド値に基づいて自動的にルーティングする。!区切りで任意の値をルーティング用のキーとして含めることができる
  • implicit
    • レコード毎にどのシャードにインデックスするかを手動で指定する

この記事では compositeId の動作を見て行きます。

compositeId

コレクション作成時にパラメータ router.name を指定しない場合にはデフォルトである compositeId ルータが使われます。(もちろん明示的に router.name=compositeId を指定しても良い)

上の例でも見たように、特に指定しなければドキュメントIDのハッシュ値に基づいてシャードが振り分けられます。何らかの値に基づいてシャードを振り分けたい場合には、その値を!区切りでドキュメントIDに含めます。

(例)
元のドキュメントID: 「1234」
区名に基づいてシャードを分けたいとき: 「中央区!1234」

このルールを使って投入用のJSONデータを少し変更します。

{"id":"住之江区!158","type":"官公庁","area":"住之江区","name":"軽自動車検査協会大阪主管事務所","address":"住之江区南港東3-4-62"},
{"id":"住之江区!157","type":"官公庁","area":"住之江区","name":"大阪陸運支局なにわ自動車検査登録事務所","address":"住之江区南港東3-1-14"},
{"id":"住吉区!381","type":"官公庁","area":"住吉区","name":"住吉税務署","address":"住吉区住吉2丁目17番37号"},
  :

先程投入したデータを全部削除してから新しいデータを投入します。

$ curl -s 'http://localhost:8983/solr/shard_test/update?stream.body=*:*&commit=true'
$ curl -s 'http://localhost:8983/solr/shard_test/update?commit=true&indent=true' --data-binary @data2.json -H 'Content-Type: application/json'

シャードごとに、どの区のデータが何件含まれているかを出力してみます。特定のシャードには特定の区だけが存在していることが分かります。

$ curl -s 'http://localhost:8983/solr/shard_test/select?facet.field=area_str&facet=on&q=*:*&rows=0&shards=shard1'|jq .facet_counts.facet_fields.area_str
[
  "中央区",
  509,
  "鶴見区",
  310,
  "福島区",
  270
]
$ curl -s 'http://localhost:8983/solr/shard_test/select?facet.field=area_str&facet=on&q=*:*&rows=0&shards=shard2'|jq .facet_counts.facet_fields.area_str
[
  "北区",
  566,
  "住之江区",
  402,
  "東住吉区",
  402,
  "天王寺区",
  349,
  "都島区",
  319,
  "大正区",
  318,
  "東成区",
  318
]
$ curl -s 'http://localhost:8983/solr/shard_test/select?facet.field=area_str&facet=on&q=*:*&rows=0&shards=shard3'|jq .facet_counts.facet_fields.area_str
[
  "淀川区",
  467,
  "住吉区",
  409,
  "生野区",
  401,
  "西淀川区",
  360,
  "西区",
  357,
  "此花区",
  349,
  "旭区",
  274,
  "浪速区",
  236
]
$ curl -s 'http://localhost:8983/solr/shard_test/select?facet.field=area_str&facet=on&q=*:*&rows=0&shards=shard4'|jq .facet_counts.facet_fields.area_str
[
  "平野区",
  610,
  "東淀川区",
  469,
  "城東区",
  449,
  "西成区",
  388,
  "港区",
  322,
  "阿倍野区",
  308,
  "大阪市以外",
  76
]

ドキュメントIDのハッシュ値に基づいて分割した場合にはほぼ均等に割り当てられていましたが、特定のフィールド値に基づいて分割する場合には、そのフィールド値の偏りが分割の偏りとなってしまうことに注意が必要です。

$ for i in {1..4}; do curl -s "http://localhost:8983/solr/shard_test/select?q=*:*&rows=0&shards=shard${i}"|jq '.response.numFound'; done
1089
2674
2853
2622

検索時のドキュメントルーティング

シャードに関するパラメータが無い場合には、すべてのシャードにクエリが投げられます。

$ curl -s 'http://localhost:8983/solr/shard_test/select?debugQuery=on&rows=0&q='`echo "area_str:中央区 AND name:消防署"|jq -s -R -r @uri` |jq '.debug.track.EXECUTE_QUERY|keys'
[
  "http://localhost:8983/solr/shard_test_shard1_replica_n1/",
  "http://localhost:8983/solr/shard_test_shard2_replica_n2/",
  "http://localhost:8983/solr/shard_test_shard3_replica_n4/",
  "http://localhost:8983/solr/shard_test_shard4_replica_n6/"
]

「中央区」が存在するシャードにだけクエリを投げられれば、分散検索に関するオーバーヘッドを抑えることができます。たとえばshards=shard1という風にshardsパラメータでシャードを直接指定できます。

$ curl -s 'http://localhost:8983/solr/shard_test/select?shards=shard1&debugQuery=on&rows=0&q='`echo "area_str:中央区 AND name:消防署"|jq -s -R -r @uri` |jq '.debug.track.EXECUTE_QUERY|keys'
[
  "http://localhost:8983/solr/shard_test_shard1_replica_n1/"
]

ただし、検索対象がどのシャードに属するのかがクエリ作成時には分からない場合がほとんどです。分割の基準となるフィールド値を_route_パラメータで指定することでシャードを指定することができます。たとえば、中央区だけを対象としたい場合には _route_=中央区 を指定します。

$ curl -s 'http://localhost:8983/solr/shard_test/select?debugQuery=on&rows=0&q='`echo "area_str:中央区 AND name:消防署"|jq -s -R -r @uri`'&_route_='`echo 中央区\!|jq -s -R -r @uri` |jq '.debug.track.EXECUTE_QUERY|keys'
[
  "http://localhost:8983/solr/shard_test_shard1_replica_n1/"
]

おわりに

大量の文書をインデックスするにあたってシャーディングの利用は不可欠です。想定される検索シーンのパターンに応じてドキュメントルーティングすることによってリソースを効率よく利用することができます。

Solrでdistinct

はじめに

Solrを使った検索で、特定のフィールドのすべての値を取得したい場合がありました。SQLで言うところのdistnctです。これを実現する方法を調べてみました。

(その1)Facetを使う方法

Solrの得意技であるFacetを使えば特定のフィールドのユニークな値をすべて列挙できます。

弊社から出しているSportareというアプリでは、スポーツ施設の検索にSolrを利用しています。各施設が持っている、実施できるスポーツ名のユニーク値を取得してみます。

$ curl 'http://localhost:8983/solr/sportare/select?facet.field=sports&facet.limit=10&facet.offset=0&facet=on&q=*:*&rows=0'
{
(略)
  "facet_counts":{
    "facet_queries":{},
    "facet_fields":{
      "sports":[
        "野球",4644,
        "バレーボール",4420,
        "バドミントン",4365,
        "バスケットボール",4218,
        "フィットネス",4089,
        "卓球",3918,
        "テニス",3493,
        "ソフトボール",3438,
        "サッカー",2711,
        "水泳",2687]},
    "facet_ranges":{},
    "facet_intervals":{},
    "facet_heatmaps":{}}}

sportsフィールドの値でFacetを作っています。facet.limitとfacet.offsetを指定して最初の10件を取得しています。facet.limit=-1と指定すれば全件取れます。

(その2)StatsComponentを使う方法

StatsComponentは、インデックスに含まれるドキュメントの統計情報を扱うコンポーネントです。このコンポーネントにdistinctValuesというパラメータを含めたリクエストを送ることでフィールドのユニーク値を取得できます。

$ curl 'http://localhost:8983/solr/sportare-spots/select?q=*:*&rows=0&stats.field={!countDistinct=true distinctValues=true}sports&stats=true'
{
(略)
  "stats":{
    "stats_fields":{
      "sports":{
        "distinctValues":["",
          "BMX",
          "アイスホッケー",
          "アメリカンフットボール",
          "アルペンスキー",
          "アーチェリー",
          "インディアカ",
          "インラインスケート",
          "ウィンドサーフィン",
          "エアロビクス",
          "オートレース",
          "カヌー",
          "カヤック",
          "カートレース",
          "カーリング",
          "カーレース",
          "キックボクシング",
(略)
          "自転車競技",
          "野球",
          "陸上",
          "陸上競技",
          "馬術"],
        "countDistinct":89}}}}

まとめ

Solrでdistinctを実現する方法を2つ挙げてみましたが、

  • 処理が軽い
  • その値が何件存在するかも同時に出せる
  • 全体の件数が非常に大きい場合に、n件ずつ取得するというページングの処理も簡単

などの利点がFacetにあるため、よほどの理由が無いかぎりはFacetを使うことになるだろうと思います。

SolrCloud 環境におけるスキーマの読み込みと保存について

はじめに

Solr 5.4.1 以降においては、スキーマは schema.xml を使うファイルベースの管理ではなく Schema API を使う管理が推奨されています。
Schema API を利用して設定された内容は managed-schema というファイルに書き込まれますが、このファイルを直接編集しないようにと公式ドキュメントには書かれています。

とはいえ、インデックスの初期設定時にはファイルで設定を与えられた方が便利です。
ManagedIndexSchemaFactory が使われる設定においては、 schema.xml が存在すれば自動的に schema.xml の内容を読み込んで schema.xml.bak にリネームしてから managed-schema ファイルが作られることになっています。
それ以降のスキーマ変更は Schema API を利用する訳です。

SolrCloud 環境においても実際に上記のような動作をするのかどうか、簡単な検証をしてみました。

準備

configsets の準備

_default の configsets をコピーして使います。

$ cd server/solr/configsets
$ cp -r _default/ schema_convert
$ rm schema_convert/conf/managed-schema
$ vi schema_convert/conf/schema.xml
$ cat schema_convert/conf/schema.xml

maganed-schema を削除して、_default/solrconfig.xml との組み合わせでエラーにならない最小限の schema.xml を作成。

<schema name="default-config" version="1.6">
    <field name="_version_" type="plong" indexed="false" stored="false"/>
    <field name="id" type="string" indexed="true" stored="true" required="true" multiValued="false" />
    <field name="key" type="string" indexed="true" stored="true" required="true" multiValued="false" />
    <field name="val" type="pint" indexed="true" stored="true" required="true" multiValued="false" />
    <uniqueKey>id</uniqueKey>
    
    <fieldType name="string" class="solr.StrField" sortMissingLast="true" docValues="true" />
    <fieldType name="pint" class="solr.IntPointField" docValues="true"/>
    <fieldType name="plong" class="solr.LongPointField" docValues="true"/>

    <fieldType name="booleans" class="solr.BoolField" sortMissingLast="true" multiValued="true"/>
    <fieldType name="plongs" class="solr.LongPointField" docValues="true" multiValued="true"/>
    <fieldType name="pdoubles" class="solr.DoublePointField" docValues="true" multiValued="true"/>
    <fieldType name="pdates" class="solr.DatePointField" docValues="true" multiValued="true"/>

    <fieldType name="text_general" class="solr.TextField" positionIncrementGap="100" multiValued="true">
      <analyzer type="index">
        <tokenizer class="solr.StandardTokenizerFactory"/>
        <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />
        <!-- in this example, we will only use synonyms at query time
        <filter class="solr.SynonymGraphFilterFactory" synonyms="index_synonyms.txt" ignoreCase="true" expand="false"/>
        <filter class="solr.FlattenGraphFilterFactory"/>
        -->
        <filter class="solr.LowerCaseFilterFactory"/>
      </analyzer>
      <analyzer type="query">
        <tokenizer class="solr.StandardTokenizerFactory"/>
        <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />
        <filter class="solr.SynonymGraphFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
        <filter class="solr.LowerCaseFilterFactory"/>
      </analyzer>
    </fieldType>
</schema>

configsets アップロード

$ ../../scripts/cloud-scripts/zkcli.sh -zkhost localhost:9983 -cmd upconfig -confdir schema_convert/conf -confname schema_convert

検証

コレクション作成

$ curl 'http://localhost:8983/solr/admin/collections?action=CREATE&name=schema_convert&numShards=1&replicationFactor=1&collection.configName=schema_convert&wt=xml'

コレクション作成時に schema.xml が読み込まれたはずです。確認してみましょう。

zookeeper データツリー確認

schema.xml が schema.xml.bak に変更されて managed-schema が作られたことが分かります。

Schema API による変更が managed-schema に反映されるか

変更前

$ curl -s http://localhost:8983/solr/schema_convert/schema/fields |grep name
      "name":"_version_",
      "name":"id",
      "name":"key",
      "name":"val",

Solr の管理画面で確認した managed-schema の内容(抜粋)

変更

curl -X POST -H 'Content-type:application/json' --data-binary '{
  "add-field":{
     "name":"label",
     "type":"string",
     "indexed":true,
     "stored":true }
}' http://localhost:8983/solr/schema_convert/schema

“label” というフィールドを追加しました。

変更後

$ curl -s http://localhost:8983/solr/schema_convert/schema/fields |grep name
      "name":"_version_",
      "name":"id",
      "name":"key",
      "name":"label",
      "name":"val",

Solr の管理画面で確認した managed-schema の内容(抜粋)

確かに変更内容が managed-schema に反映されました。

まとめ

通常の Solr core の環境では Schema API による設定変更は managed-schema の実ファイルに保存されます。

一方、SolrCloud の環境では各種設定ファイルは zookeeper 上にあるものを各ノードで共有する形になっています。schema.xml の読み込みや Schema API による変更の保存などは zookeeper のファイルツリー上で実ファイルと全く同じ内容が実行されることを確認できました。

今更ながらLaravelのバージョンを5.1から5.5にアップグレード

最初は5.1から5.5に一気にあげようかと思いましたが、順次あげていったほうが最終的には早く終わりそうだったので、Laravelのアップグレード手順と他の方の記事を参考にしながらアップグレードを行いました。
せっかくなのと覚書を兼用してつまづいた部分をいくつか紹介します。

5.1 > 5.2

composer updateでエラー

Illuminate\Foundation\ComposerScripts::postUpdate
php artisan optimize
PHP Fatal error: Uncaught ReflectionException: Class log does not exist in vendor/laravel/framework/src/Illuminate/Container/Container.php:734
Stack trace:

原因は.envに定義している配列の書き方がまずかった模様

ALLOW_IPS=[“192.168.111.111”, “192.168.111.123”]

こちらスペースを削除したら問題なく動作しました。

5.2 > 5.3

bladeを拡張していた部分でエラー

(‘aaa’, $bbb->ccc)

これまでblade拡張のdirectiveにて上記のようにパラメータが来ていたが、5.3になってからは下記のように外側の括弧がなくなりマッチせずエラーに

‘aaa’, $bbb->ccc

こちらは括弧がない文字列でマッチ条件を変更

5.3 > 5.4

・使用していたSlackのライブラリが使えなくなった > 別のライブラリに変更
・関数名がリネームされていた > forceSchemaをforceSchemeに書き換え

5.4 > 5.5

・Filesystemのfilesメソッドの挙動がSplFileInfoを返すようになったので、実行前にis_dirで確認を追加しました。
・Requestのhas,onlyメソッドの挙動が少し変わっていたので適宜書き換え

動作確認やアップグレード中に不具合修正が入ったり等で少し時間がかかりましたが、基本的にはアップグレード手順書通り行えばそこまで問題はなさそうです。